במאמר הזה מוצגת ארכיטקטורת הפניה לאפליקציה מרובת-שכבות שפועלת במכונות וירטואליות של Compute Engine בכמה אזורים בתוך אזור Google Cloud. אתם יכולים להשתמש בארכיטקטורת העזר הזו כדי לבצע אירוח מחדש (lift and shift) של אפליקציות מקומיות בענן בצורה יעילה, עם שינויים מינימליים באפליקציות. במסמך מתוארים גם גורמי העיצוב שכדאי לקחת בחשבון כשבונים ארכיטקטורה אזורית לאפליקציות בענן. המסמך הזה מיועד לאדריכלי ענן.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה של אפליקציה שפועלת במצב פעיל-פעיל במערכים מבודדים שנפרסים בשלושה אזורי זמינות שלGoogle Cloud באזור מסוים. הארכיטקטורה תואמת לארכיטיפ הפריסה האזורית.
הארכיטקטורה מבוססת על מודל הענן של תשתית כשירות (IaaS). אתם מקצים את משאבי התשתית הנדרשים (מחשוב, רשת ואחסון) ב- Google Cloud. השליטה המלאה בתשתית נשארת בידיים שלכם, ואתם אחראים למערכת ההפעלה, לתוכנת הביניים ולשכבות הגבוהות יותר של מחסנית האפליקציות. מידע נוסף על IaaS ועל מודלים אחרים של ענן זמין במאמר PaaS לעומת IaaS לעומת SaaS לעומת CaaS: מה ההבדלים?.
התרשים שלמעלה כולל את הרכיבים הבאים:
| רכיב | מטרה |
|---|---|
| מאזן עומסים חיצוני אזורי |
מאזן העומסים החיצוני האזורי מקבל ומפיץ בקשות של משתמשים למכונות הווירטואליות בשכבת האינטרנט. משתמשים בסוג מאזן עומסים מתאים בהתאם לסוג התנועה ולדרישות אחרות. לדוגמה, אם הבק-אנד מורכב משרתי אינטרנט (כפי שמוצג בארכיטקטורה הקודמת), צריך להשתמש במאזן עומסים של אפליקציות כדי להעביר תעבורת HTTP(S). כדי לאזן עומסים של תנועת TCP, צריך להשתמש במאזן עומסי רשת. מידע נוסף זמין במאמר בנושא בחירת מאזן עומסים. |
| אזורי קבוצת מופעי מכונה מנוהלים (MIG) לשכבת האינטרנט |
שכבת האינטרנט של האפליקציה נפרסת במכונות וירטואליות של Compute Engine ששייכות לקבוצת מופעים מנוהלת (MIG) אזורית. ה-MIG הוא הבק-אנד של מאזן העומסים החיצוני האזורי. ה-MIG מכיל מכונות וירטואליות ב-Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית כזו מארחת מופע עצמאי של רמת האינטרנט של האפליקציה. |
| מאזן עומסים פנימי אזורי |
מאזן העומסים הפנימי האזורי מפזר את תעבורת הנתונים מהמכונות הווירטואליות בשכבת האינטרנט למכונות הווירטואליות בשכבת האפליקציה. בהתאם לדרישות שלכם, אתם יכולים להשתמש במאזן עומסים פנימי אזורי של אפליקציות (ALB) או במאזן עומסי רשת (NLB). מידע נוסף זמין במאמר בנושא בחירת מאזן עומסים. |
| קבוצת MIG אזורית לשכבת האפליקציה |
שכבת האפליקציה נפרסת במכונות וירטואליות ב-Compute Engine שהן חלק מקבוצת MIG אזורית, שהיא העורף של מאזן העומסים הפנימי. ה-MIG מכיל מכונות וירטואליות ב-Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית מארחת מופע עצמאי של רמת האפליקציה. |
| מסד נתונים של צד שלישי שנפרס במכונה וירטואלית ב-Compute Engine |
הארכיטקטורה שמוצגת במסמך הזה כוללת מסד נתונים של צד שלישי (כמו PostgreSQL) שנפרס במכונה וירטואלית של Compute Engine. אתם יכולים לפרוס מסד נתונים במצב המתנה באזור אחר. היכולות של שכפול מסד הנתונים ומעבר אוטומטי לגיבוי תלויות במסד הנתונים שבו אתם משתמשים. התקנה וניהול של מסד נתונים של צד שלישי כרוכים במאמץ נוסף ובעלויות תפעוליות לצורך החלת עדכונים, מעקב והבטחת זמינות. כדי להימנע מהתקורה של התקנה וניהול של מסד נתונים של צד שלישי, תוכלו להשתמש בשירות מנוהל של מסד נתונים כמו Cloud SQL או AlloyDB ל-PostgreSQL. כך תוכלו ליהנות מתכונות מובנות של זמינות גבוהה (HA). מידע נוסף על אפשרויות של מסדי נתונים מנוהלים זמין בהמשך המדריך, בקטע שירותי מסדי נתונים. |
| רשת של ענן וירטואלי פרטי (VPC) ו תת-רשת |
כל Google Cloud המשאבים בארכיטקטורה משתמשים ברשת VPC אחת ובתת-רשת אחת. בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות VPC או בכמה רשתות משנה. מידע נוסף זמין במאמר שיטות מומלצות ודוגמאות לארכיטקטורות לתכנון VPC, בקטע בנושא יצירת כמה רשתות VPC. |
| קטגוריה של Cloud Storage בשני אזורים |
גיבויים של אפליקציות ומסדי נתונים מאוחסנים בקטגוריה של Cloud Storage באזור כפול. אם מתרחשת הפסקה זמנית בשירות באזור או באזור, האפליקציה והנתונים שלכם לא יאבדו. אפשר גם להשתמש ב שירות Backup and DR כדי ליצור גיבויים של מסד הנתונים, לאחסן אותם ולנהל אותם. |
המוצרים שהשתמשו בהם
ארכיטקטורת ההפניה הזו כוללת את המוצרים הבאים Google Cloud :
- Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור מכונות וירטואליות ולהריץ אותן בתשתית של Google.
- Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים, בעלי ביצועים גבוהים וניתנים להתאמה.
- Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לה, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . VPC כולל קישור בין רשתות VPC שכנות (peering), Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
תרחישים לדוגמה
בקטע הזה מתוארים תרחישי שימוש שבהם פריסה אזורית ב-Compute Engine היא בחירה מתאימה.
העברה יעילה של אפליקציות מקומיות
אתם יכולים להשתמש בארכיטקטורת ההפניה הזו כדי ליצור Google Cloud טופולוגיה להעברה מחדש (lift and shift) של אפליקציות מקומיות לענן עם שינויים מינימליים באפליקציות. כל הרמות של האפליקציה בארכיטקטורת ההפניה הזו מתארחות במכונות וירטואליות של Compute Engine. הגישה הזו מאפשרת לכם להעביר ביעילות אפליקציות מקומיות לענן וליהנות מיתרונות העלות, האמינות, הביצועים והפשטות התפעולית ש-Google Cloud מספקת.
אפליקציה עם זמינות גבוהה למשתמשים באזור גיאוגרפי מסוים
אנחנו ממליצים על ארכיטקטורת פריסה אזורית לאפליקציות שצריכות להיות חסינות מפני הפסקות חשמל באזורים, אבל יכולות לעמוד בהשבתה מסוימת שנגרמת כתוצאה מהפסקות חשמל באזורים. אם חלק כלשהו במערך האפליקציה נכשל, האפליקציה ממשיכה לפעול אם קיים לפחות רכיב אחד מתפקד עם קיבולת מספקת בכל רמה. אם מתרחשת הפסקה זמנית בשירות באזור, מחסנית האפליקציות ממשיכה לפעול באזורים האחרים.
זמן טעינה קצר למשתמשי האפליקציה
אם כל המשתמשים באפליקציה נמצאים באזור גיאוגרפי אחד, כמו מדינה אחת, ארכיטקטורת פריסה אזורית יכולה לעזור לשפר את הביצועים של האפליקציה מנקודת המבט של המשתמש. כדי לבצע אופטימיזציה של זמן האחזור ברשת לבקשות של משתמשים, כדאי לפרוס את האפליקציה באזור הקרוב ביותר למשתמשים. Google Cloud
רשת עם זמן אחזור נמוך בין רכיבי האפליקציה
ארכיטקטורה של אזור יחיד יכולה להתאים לאפליקציות כמו עיבוד באצווה שדורשות חיבורים לרשת עם זמן אחזור נמוך ורוחב פס גבוה בין צמתי החישוב. כל המשאבים נמצאים באותו אזור Google Cloud, כך שתעבורת הנתונים ברשת בין המשאבים נשארת באזור. זמן האחזור ברשת בין המשאבים נמוך, ולא חלים חיובים על העברת נתונים בין אזורים. עדיין חלות עלויות שימוש ברשת בתוך האזור.
עמידה בדרישות לגבי מיקום הנתונים
אתם יכולים להשתמש בארכיטקטורה של אזור יחיד כדי ליצור טופולוגיה שתעזור לכם לעמוד בדרישות של שמירת נתונים. לדוגמה, יכול להיות שבמדינה באירופה יש דרישה שכל נתוני המשתמשים יאוחסנו ושתהיה אליהם גישה במרכזי נתונים שנמצאים פיזית באירופה. כדי לעמוד בדרישה הזו, אפשר להפעיל את האפליקציה באזורGoogle Cloud באירופה.
שיקולים לגבי העיצוב
בקטע הזה מוסבר איך להשתמש בארכיטקטורת ההפניה הזו כדי לפתח ארכיטקטורה שעונה על הדרישות הספציפיות שלכם לגבי עיצוב המערכת, אבטחה ותאימות, אמינות, יעילות תפעולית, עלות וביצועים.
עיצוב המערכת
בקטע הזה מוסבר איך לבחור Google Cloud אזורים לפריסה אזורית ואיך לבחור Google Cloud שירותים מתאימים. Google Cloud
בחירת אזור
כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, חשוב לקחת בחשבון את הגורמים והדרישות הבאים:
- זמינות השירותים בכל אזור. Google Cloud מידע נוסף זמין במאמר זמינות המוצרים לפי מיקום.
- זמינות של סוגי מכונות ב-Compute Engine בכל אזור. מידע נוסף זמין במאמר אזורים ותחומים.
- דרישות לזמן האחזור של משתמשי הקצה.
- העלות של Google Cloud המשאבים.
- עלויות של העברת נתונים בין אזורים.
- דרישות רגולטוריות.
- דרישות בנושא קיימוּת.
יכול להיות שחלק מהגורמים והדרישות האלה יחייבו פשרות. לדוגמה, יכול להיות שאזור שבו העלות היא הכי נמוכה לא יהיה האזור עם טביעת הרגל הפחמנית הכי נמוכה. למידע נוסף, ראו שיטות מומלצות לבחירת אזורים ב-Compute Engine.
תשתית מחשוב
בארכיטקטורת ההפניה שבמסמך הזה נעשה שימוש במכונות וירטואליות של Compute Engine עבור רמות מסוימות של האפליקציה. בהתאם לדרישות של האפליקציה, אפשר לבחור מבין שירותי מחשוב אחרים: Google Cloud
- קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine (GKE). GKE הוא מנוע לתזמור קונטיינרים שמבצע אוטומטית פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
- Serverless: אם אתם מעדיפים להתמקד בנתונים ובאפליקציות שלכם במקום בהגדרה ובהפעלה של משאבי תשתית, אתם יכולים להשתמש בשירותי Serverless כמו Cloud Run.
ההחלטה אם להשתמש במכונות וירטואליות, במאגרי מידע או בשירותים ללא שרתים כרוכה בפשרה בין גמישות ההגדרה לבין מאמצי הניהול. מכונות וירטואליות וקונטיינרים מספקים גמישות רבה יותר בהגדרות, אבל אתם אחראים לניהול המשאבים. בארכיטקטורה ללא שרת (serverless), אתם פורסים עומסי עבודה בפלטפורמה שהוגדרה מראש ודורשת מינימום מאמץ ניהולי. מידע נוסף על בחירת שירותי מחשוב מתאימים לעומסי העבודה ב-Google Cloudזמין במאמר אירוח אפליקציות ב- Google Cloud.
שירותי אחסון
הארכיטקטורה שמוצגת במסמך הזה משתמשת בנפחי אחסון מתמיד (persistent disks) אזוריים לכל הרמות. דיסקים לאחסון מתמיד (persistent disks) מספקים שכפול סינכרוני של נתונים בין שני אזורים באותו אזור.
Google Cloud Hyperdisk מספק ביצועים טובים יותר, גמישות ויעילות בהשוואה ל-Persistent Disk. עם Hyperdisk Balanced, אתם יכולים להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את נפח האחסון למגוון רחב של עומסי עבודה.
כדי לקבל אחסון בעלות נמוכה שמשוכפל בכמה מיקומים, אפשר להשתמש בקטגוריות אזוריות, בקטגוריות בשני אזורים או בקטגוריות במספר אזורים ב-Cloud Storage.
- הנתונים בקטגוריות אזוריות משוכפלים באופן סינכרוני באזורים.
- נתונים בקטגוריות של שני אזורים או מספר אזורים מאוחסנים ביתירות בשני מיקומים גיאוגרפיים נפרדים לפחות. מטא-נתונים נכתבים באופן סינכרוני באזורים שונים, והנתונים משוכפלים באופן אסינכרוני. בקטגוריות של שני אזורים, אפשר להשתמש ברפליקציה בקצב טורבו, שמבטיחה שאובייקטים ישוכפלו בין זוגות של אזורים, עם יעד להתאוששות מאסון (RPO) של 15 דקות. מידע נוסף זמין במאמר בנושא זמינות ועמידות של נתונים.
כדי לאחסן נתונים שמשותפים בין כמה מכונות וירטואליות באזור מסוים, למשל בין כל המכונות הווירטואליות בשכבת האינטרנט או בשכבת האפליקציה, אפשר להשתמש במופע אזורי של Filestore. הנתונים שמאוחסנים במופע אזורי של Filestore משוכפלים באופן סינכרוני בשלושה אזורים בתוך האזור. השכפול הזה מבטיח זמינות גבוהה ועמידות בפני הפסקות חשמל באזור. אתם יכולים לאחסן קובצי הגדרה משותפים, כלים ושירותים נפוצים ויומנים מרכזיים במופע Filestore, ולצרף את המופע למספר מכונות וירטואליות. כדי להבטיח עמידות במקרה של הפסקות חשמל באזור מסוים, אפשר לשכפל מופע Filestore לאזור אחר. מידע נוסף מופיע במאמר בנושא שכפול מופעים.
אם מסד הנתונים שלכם הוא Microsoft SQL Server, מומלץ להשתמש ב-Cloud SQL ל-SQL Server. בתרחישים שבהם Cloud SQL לא תומך בדרישות ההגדרה שלכם, או אם אתם צריכים גישה למערכת ההפעלה, אתם יכולים לפרוס מכונה של Microsoft SQL Server failover cluster instance (FCI). בתרחיש הזה, אפשר להשתמש ב-Google Cloud NetApp Volumes, שירות מנוהל לחלוטין, כדי לספק אחסון SMB עם זמינות רציפה (CA) למסד הנתונים.
כשמתכננים את האחסון של עומסי העבודה, צריך לקחת בחשבון את המאפיינים הפונקציונליים, דרישות העמידות, ציפיות הביצועים ויעדי העלות. מידע נוסף זמין במאמר בנושא תכנון אסטרטגיית אחסון אופטימלית לעומס העבודה בענן.
שירותי מסדי נתונים
בארכיטקטורת ההפניה במסמך הזה נעשה שימוש במסד נתונים של צד שלישי שנפרס במכונות וירטואליות של Compute Engine. התקנה וניהול של מסד נתונים של צד שלישי כרוכים במאמץ ובעלויות של פעולות כמו החלת עדכונים, מעקב והבטחת זמינות, ביצוע גיבויים והתאוששות מכשלים.
כדי להימנע מהמאמץ ומהעלות של התקנה וניהול של מסד נתונים של צד שלישי, אפשר להשתמש בשירות מנוהל של מסד נתונים כמו Cloud SQL, AlloyDB ל-PostgreSQL, Bigtable, Spanner או Firestore. שירותי מסד הנתונים האלה של Google Cloud מספקים הסכמי רמת שירות (SLA) לזמן פעולה, והם כוללים יכולות ברירת מחדל למדרגיות ולניטור.
אם עומס העבודה שלכם צריך מסד נתונים של Oracle, אתם יכולים לפרוס את מסד הנתונים במכונה וירטואלית של Compute Engine או להשתמש ב-Oracle Database@Google Cloud. מידע נוסף זמין במאמר בנושא עומסי עבודה של Oracle ב- Google Cloud.
עיצוב רשת
חשוב לבחור עיצוב רשת שעונה על הדרישות העסקיות והטכניות שלכם. אתם יכולים להשתמש ברשת VPC אחת או בכמה רשתות VPC. מידע נוסף זמין במאמרי העזרה הבאים:
אבטחה, פרטיות ותאימות
בקטע הזה מתוארים גורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן ולבנות טופולוגיה אזורית ב-Google Cloud שעומדת בדרישות האבטחה, הפרטיות והתאימות של עומסי העבודה.
הגנה מפני איומים חיצוניים
כדי להגן על האפליקציה מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצות אבטחה XSS (cross-site scripting), אפשר להשתמש במדיניות אבטחה של Google Cloud Armor. כל מדיניות היא קבוצת כללים שמפרטת תנאים מסוימים שצריך לבדוק ופעולות שצריך לבצע כשהתנאים מתקיימים. לדוגמה, כלל יכול לציין שאם כתובת ה-IP של המקור של התנועה הנכנסת תואמת לכתובת IP ספציפית או לטווח CIDR, אז צריך לדחות את התנועה. אפשר גם להחיל כללים מוגדרים מראש של חומת אש לאפליקציות אינטרנט (WAF). מידע נוסף זמין במאמר סקירה כללית של מדיניות האבטחה.
גישה חיצונית למכונות וירטואליות
בארכיטקטורת ההפניה שמתוארת במסמך הזה, המכונות הווירטואליות ב-Compute Engine לא צריכות גישה נכנסת מהאינטרנט. לא מקצים כתובות IP חיצוניות למכונות הווירטואליות. Google Cloud משאבים שיש להם רק כתובת IP פנימית פרטית עדיין יכולים לגשת לשירותים ולממשקי Google API מסוימים באמצעות Private Service Connect או גישה פרטית ל-Google. מידע נוסף זמין במאמר אפשרויות גישה פרטיות לשירותים.
כדי להפעיל חיבורים יוצאים מאובטחים מ Google Cloud משאבים שיש להם רק כתובות IP פרטיות, כמו המכונות הווירטואליות של Compute Engine בארכיטקטורת ההפניה הזו, אפשר להשתמש ב-Secure Web Proxy או ב-Cloud NAT.
הרשאות בחשבון שירות
במקום להשתמש בחשבונות השירות שמוגדרים כברירת מחדל, מומלץ ליצור חשבונות שירות ייעודיים למכונות הווירטואליות של Compute Engine בארכיטקטורה ולציין את המשאבים שלחשבון השירות תהיה גישה אליהם. לחשבון השירות שמוגדר כברירת מחדל יש מגוון רחב של הרשאות, כולל הרשאות שאולי לא נחוצות. אתם יכולים להתאים חשבונות שירות ייעודיים כך שיהיו להם רק ההרשאות החיוניות. מידע נוסף זמין במאמר הגבלת ההרשאות של חשבון שירות.
אבטחת SSH
כדי לשפר את האבטחה של חיבורי SSH למכונות וירטואליות של Compute Engine בארכיטקטורה שלכם, כדאי להטמיע שרת proxy לאימות זהויות (IAP) וממשק API של Cloud OS Login. IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.
אבטחת רשת
כדי לשלוט בתעבורת הנתונים ברשת בין המשאבים בארכיטקטורה, צריך להגדיר מדיניות מתאימה של Cloud Next Generation Firewall (NGFW).
שיקולי אבטחה נוספים
כשמפתחים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות וההמלצות לאבטחה ברמת הפלטפורמה שמפורטות בתוכנית לניהול יסודות האבטחה בארגון ובGoogle Cloud מסגרת Well-Architected: יסודות האבטחה, הפרטיות והתאימות.
אמינות
בקטע הזה מתוארים גורמים עיצוביים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לבנות ולהפעיל תשתית אמינה לפריסות אזוריות ב- Google Cloud.
הפסקות זמניות בתשתית
בארכיטקטורה אזורית, אם רכיב מסוים במערך התשתית נכשל, האפליקציה יכולה לעבד בקשות אם קיים לפחות רכיב אחד מתפקד עם קיבולת מספקת בכל רמה. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים מעביר את בקשות המשתמשים למופעים אחרים של שרת אינטרנט שזמינים. אם מכונה וירטואלית שמארחת מופע של שרת אינטרנט או שרת אפליקציות קורסת, קבוצת ה-MIG יוצרת מחדש את המכונה הווירטואלית באופן אוטומטי.
אם מתרחשת הפסקה זמנית בשירות באזור, מאזן העומסים לא מושפע כי הוא משאב אזורי. יכול להיות שהפסקת חשמל באזור תשפיע על מכונות וירטואליות ספציפיות ב-Compute Engine. אבל האפליקציה ממשיכה להיות זמינה ומגיבה כי המכונות הווירטואליות נמצאות בקבוצת MIG אזורית. קבוצת MIG אזורית מבטיחה שמכונות וירטואליות חדשות ייווצרו באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. אחרי ש-Google תפתור את הבעיה בהפסקה זמנית בשירות באזור, תצטרכו לוודא שהאפליקציה פועלת כצפוי בכל האזורים שבהם היא נפרסה.
אם יש הפסקה זמנית בשירות בכל האזורים בארכיטקטורה הזו, או אם יש הפסקה זמנית בשירות באזור, האפליקציה לא תהיה זמינה. צריך להמתין עד ש-Google תפתור את ההפסקה הזמנית בשירות, ואז לוודא שהאפליקציה פועלת כמצופה.
כדי לצמצם את זמן ההשבתה שנגרם כתוצאה מהפסקות זמניות בשירות באזור מסוים, אפשר לשמור רפליקה פסיבית (יתירות כשל) של ערימת התשתית באזור אחר. Google Cloudאם מתרחשת הפסקה זמנית בשירות באזור הראשי, אפשר להפעיל את מחסנית הנתונים באזור היתירות כשל ולשימוש במדיניות ניתוב DNS כדי לנתב את התעבורה למאזן העומסים באזור היתירות כשל.
באפליקציות שנדרשת בהן עמידות גבוהה מפני הפסקות חשמל באזור, כדאי להשתמש בארכיטקטורה במספר אזורים. מידע נוסף זמין במאמר בנושא פריסה מרובת אזורים ב-Compute Engine.
התאמה אוטומטית לעומס (autoscaling) של MIG
כדי לשלוט בהתנהגות של התאמה אוטומטית לעומס של קבוצות ה-MIG בלי שמירת מצב, אפשר לציין מדדי ניצול של יעד, כמו ניצול ממוצע של המעבד. אפשר גם להגדיר התאמה אוטומטית לעומס מבוססת-תזמון לקבוצות MIG בלי שמירת מצב. אי אפשר להגדיל או להקטין את הגודל של קבוצות מנוהלות עם שמירת מצב באופן אוטומטי. מידע נוסף זמין במאמר בנושא קבוצות של מופעים עם שינוי גודל אוטומטי.
מגבלת הגודל של MIG
כשמחליטים על הגודל של קבוצות ה-MIG, צריך לקחת בחשבון את מגבלות ברירת המחדל והמגבלות המקסימליות על מספר המכונות הווירטואליות שאפשר ליצור בקבוצת MIG. מידע נוסף זמין במאמר הוספה והסרה של מכונות וירטואליות מקבוצת מופעי מכונה מנוהלים (MIG).
תיקון אוטומטי של מכונות וירטואליות
יכול להיות שהמכונות הווירטואליות שמארחות את האפליקציה פועלות וזמינות, אבל יש בעיות באפליקציה עצמה. יכול להיות שהאפליקציה תקפא, תקרוס או שלא יהיה לה מספיק זיכרון. כדי לוודא שאפליקציה מגיבה כמצופה, אפשר להגדיר בדיקות תקינות מבוססות-אפליקציה כחלק ממדיניות התיקון האוטומטי של קבוצות ה-MIG. אם האפליקציה במכונה וירטואלית מסוימת לא מגיבה, קבוצת ה-MIG מבצעת תיקון אוטומטי של המכונה הווירטואלית. מידע נוסף על הגדרת תיקון אוטומטי זמין במאמר מידע על תיקון מכונות וירטואליות לזמינות גבוהה.
מיקום ה-VM
בארכיטקטורה שמתוארת במסמך הזה, רמת האפליקציה ורמת האינטרנט פועלות במכונות וירטואליות של Compute Engine שמפוזרות על פני אזורים רבים. ההפצה הזו מבטיחה שהאפליקציה שלכם תהיה עמידה בפני הפסקות חשמל באזורים.
כדי לשפר את החוסן של הארכיטקטורה, אפשר ליצור מדיניות למיקום מרווח ולהחיל אותה על תבנית ה-MIG. כשקבוצת ה-MIG יוצרת מכונות וירטואליות, היא ממקמת אותן בכל אזור בשרתים פיזיים שונים (שנקראים מארחים), כך שהמכונות הווירטואליות עמידות בפני כשלים של מארחים ספציפיים. מידע נוסף זמין במאמר בנושא יצירה והחלה של מדיניות בנושא מיקום מודעות במכונות וירטואליות.
תכנון הקיבולת של מכונות וירטואליות
כדי לוודא שהקיבולת של מכונות וירטואליות ב-Compute Engine תהיה זמינה כשצריך להקצות מכונות וירטואליות, אפשר ליצור שמירת מקום. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שתבחרו. אפשר להגדיר הזמנה לפרויקט ספציפי, או לשתף אותה בין כמה פרויקטים. מידע נוסף על הזמנות זמין במאמר בנושא בחירת סוג הזמנה.
אחסון עם שמירת מצב
שיטה מומלצת בתכנון אפליקציות היא להימנע מהצורך בדיסקים מקומיים עם שמירת מצב. אבל אם הדרישה קיימת, אפשר להגדיר את הדיסקים המתמידים כך שיהיו בעלי מצב (stateful) כדי להבטיח שהנתונים יישמרו כשמכונות וירטואליות מתוקנות או נוצרות מחדש. עם זאת, מומלץ להשאיר את דיסקי האתחול בלי שמירת מצב, כדי שתוכלו לעדכן אותם לתמונות העדכניות ביותר עם גרסאות חדשות ותיקוני אבטחה. מידע נוסף זמין במאמר בנושא הגדרת דיסקים קשיחים מתמידים עם שמירת מצב בקבוצות של מכונות וירטואליות לניהול מופעים (MIG).
עמידות הנתונים
אתם יכולים להשתמש ב-Backup and DR כדי ליצור גיבויים של מכונות וירטואליות ב-Compute Engine, לאחסן אותם ולנהל אותם. שירות Backup and DR מאחסן נתוני גיבוי בפורמט המקורי שניתן לקריאה על ידי האפליקציה. כשנדרש, אתם יכולים לשחזר את עומסי העבודה שלכם לסביבת הייצור באמצעות נתונים מאחסון גיבוי לטווח ארוך, בלי שתצטרכו להכין או להעביר נתונים.
Compute Engine מספק את האפשרויות הבאות כדי לעזור לכם לוודא שהנתונים שמאוחסנים בכרכים של Persistent Disk יהיו עמידים:
- אתם יכולים להשתמש בתמונות מצב כדי לתעד את המצב של דיסקים לאחסון מתמיד בנקודת זמן מסוימת. התמונות האלה מאוחסנות באופן יתירני בכמה אזורים, עם בדיקות סכום אוטומטיות כדי להבטיח את שלמות הנתונים. צילומי מצב הם מצטברים כברירת מחדל, ולכן הם תופסים פחות מקום באחסון ואתם חוסכים כסף. תמונות המצב מאוחסנות במיקום ב-Cloud Storage שאפשר להגדיר. המלצות נוספות לשימוש בתמונות מצב ולניהול שלהן זמינות במאמר שיטות מומלצות לשימוש בתמונות מצב של דיסקים ב-Compute Engine.
- כדי לוודא שהנתונים ב-Persistent Disk יישארו זמינים אם תתרחש הפסקה זמנית בשירות באזור, אפשר להשתמש ב-Regional Persistent Disk או ב-Hyperdisk Balanced High Availability. הנתונים בסוגי הדיסקים האלה משוכפלים באופן סינכרוני בין שני אזורים באותו אזור. מידע נוסף זמין במאמר מידע על שכפול דיסקים סינכרוני.
אם אתם משתמשים בשירות מנוהל של מסד נתונים כמו Cloud SQL, הגיבויים מתבצעים באופן אוטומטי על סמך מדיניות שמירת נתונים שהגדרתם. כדי לעמוד בדרישות רגולטוריות, בדרישות של תהליכי עבודה או בדרישות עסקיות, אפשר להוסיף לגיבויים הפיזיים גיבויים לוגיים.
אם אתם משתמשים במסד נתונים של צד שלישי ואתם צריכים לאחסן גיבויים של מסד הנתונים ויומני עסקאות, אתם יכולים להשתמש בקטגוריות אזוריות של Cloud Storage. קטגוריות אזוריות של Cloud Storage מספקות אחסון גיבוי בעלות נמוכה עם יתירות בין אזורים.
זמינות מסד הנתונים
אם משתמשים בשירות מנוהל של מסד נתונים כמו Cloud SQL בתצורת זמינות גבוהה, אז במקרה של כשל במסד הנתונים הראשי, Cloud SQL מבצע מעבר אוטומטי למסד הנתונים המשני. אין צורך לשנות את כתובת ה-IP של נקודת הקצה של מסד הנתונים. אם אתם משתמשים במסד נתונים מצד שלישי בניהול עצמי שנפרס במכונה וירטואלית ב-Compute Engine, אתם צריכים להשתמש במאזן עומסים פנימי או במנגנון אחר כדי לוודא שהאפליקציה יכולה להתחבר למסד נתונים אחר אם מסד הנתונים הראשי לא זמין.
כדי להטמיע יתירות כשל בין אזורים למסד נתונים שפרוס במכונה וירטואלית ב-Compute Engine, צריך מנגנון לזיהוי כשלים במסד הנתונים הראשי ותהליך למעבר לגיבוי למסד הנתונים המשני. הפרטים הספציפיים של מנגנון המעבר לגיבוי תלויים במסד הנתונים שבו אתם משתמשים. אתם יכולים להגדיר מופע של observer כדי לזהות כשלים במסד הנתונים הראשי ולתזמר את היתירות כשל. כדי להימנע ממצב של פיצול מוח ולמנוע מעבר מיותר לגיבוי, צריך להגדיר את כללי המעבר לגיבוי בצורה מתאימה. לדוגמאות לארכיטקטורות שאפשר להשתמש בהן כדי להטמיע יתירות כשל במסדי נתונים של PostgreSQL, אפשר לעיין במאמר ארכיטקטורות לזמינות גבוהה של אשכולות PostgreSQL ב-Compute Engine.
שיקולים נוספים בנושא מהימנות
כשיוצרים את ארכיטקטורת הענן של עומס העבודה, כדאי לעיין בשיטות המומלצות ובהמלצות שקשורות למהימנות, שמופיעות במסמכים הבאים:
- Google Cloud מדריך לאמינות התשתית
- תבניות לאפליקציות עמידות שניתנות להרחבה
- תכנון מערכות חסינות
- Google Cloud Well-Architected Framework: אמינות
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלויות הכרוכות בהגדרה ובהפעלה של טופולוגיה אזורית Google Cloud שיוצרים באמצעות ארכיטקטורת ההפניה הזו.
סוגי מכונות וירטואליות
כדי לעזור לכם לייעל את השימוש במשאבים של המכונות הווירטואליות, ב-Compute Engine יש המלצות לסוגי מכונות. אפשר להשתמש בהמלצות כדי לבחור סוגי מכונות שתואמים לדרישות החישוב של עומס העבודה. אם אתם יכולים לחזות את הצורך שלכם במשאבים בעומסי העבודה, אתם יכולים להתאים אישית את סוג המכונה לצרכים שלכם ולחסוך כסף באמצעות סוגי מכונות בהתאמה אישית.
מודל הקצאת הרשאות ל-VM
אם האפליקציה שלכם סובלת תקלות, מכונות וירטואליות זמניות יכולות לעזור לכם לצמצם את העלויות של Compute Engine עבור המכונות הווירטואליות בשכבות של האפליקציה והאינטרנט. העלות של מכונות Spot VM נמוכה משמעותית מזו של מכונות וירטואליות רגילות. עם זאת, יכול להיות ש-Compute Engine יפסיק או ימחק מכונות וירטואליות מסוג Spot באופן יזום כדי לפנות קיבולת.
מכונות וירטואליות במודל Spot מתאימות למשימות באצווה שיכולות לעמוד בהפסקה זמנית ואין להן דרישות לזמינות גבוהה. מכונות וירטואליות במודל Spot מציעות את אותם סוגי מכונות, אפשרויות וביצועים כמו מכונות וירטואליות רגילות. עם זאת, אם קיבולת המשאבים באזור מוגבלת, יכול להיות שקבוצות MIG לא יוכלו להגדיל את מספר המכונות הווירטואליות באופן אוטומטי לגודל היעד שצוין עד שהקיבולת הנדרשת תהיה זמינה שוב.
ניצול משאבים של מכונות וירטואליות
היכולת של קבוצות MIG ללא מצב (stateless) לבצע התאמה אוטומטית לעומס מאפשרת לאפליקציה לטפל בעלייה בתנועה בצורה חלקה, ועוזרת לצמצם את העלויות כשאין צורך במשאבים. אי אפשר להגדיל או להקטין את הגודל של קבוצות מנוהלות עם שמירת מצב באופן אוטומטי.
רישוי צד שלישי
כשמעבירים עומסי עבודה של צד שלישי אל Google Cloud, יכול להיות שאפשר יהיה להוזיל את העלויות באמצעות שימוש ברישיונות משלכם (BYOL). לדוגמה, כדי לפרוס מכונות וירטואליות של Microsoft Windows Server, במקום להשתמש באימג' פרימיום שכולל עלות נוספת לרישיון של צד שלישי, אפשר ליצור ולהשתמש באימג' BYOL מותאם אישית של Windows. לאחר מכן משלמים רק על תשתית המכונה הווירטואלית שבה משתמשים ב- Google Cloud. האסטרטגיה הזו עוזרת לכם להמשיך להפיק ערך מההשקעות הקיימות שלכם ברישיונות של צד שלישי. אם תבחרו להשתמש בגישת BYOL, ההמלצות הבאות עשויות לעזור לכם להקטין את העלויות:
- אפשר להקצות את מספר ליבות המעבד הנדרש בנפרד מהזיכרון באמצעות סוגי מכונות בהתאמה אישית. כך מגבילים את עלות הרישוי של הצד השלישי למספר ליבות ה-CPU שדרושות לכם.
- כדי להקטין את מספר יחידות ה-vCPU לכל ליבה מ-2 ל-1, משביתים את הריבוי נימים סימולטני (SMT).
אם אתם פורסים מסד נתונים של צד שלישי כמו Microsoft SQL Server במכונות וירטואליות של Compute Engine, אתם צריכים לקחת בחשבון את עלויות הרישיון של תוכנת הצד השלישי. כשמשתמשים בשירות מסד נתונים מנוהל כמו Cloud SQL, עלויות הרישיון של מסד הנתונים כלולות בחיובים על השירות.
שיקולי עלות נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.
יעילות תפעולית
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן ולבנות טופולוגיה אזורית Google Cloudשאפשר להפעיל ביעילות.
עדכוני הגדרות של מכונות וירטואליות
כדי לעדכן את ההגדרה של ה-VMs בקבוצת MIG (למשל סוג המכונה או אימג' של דיסק האתחול), יוצרים תבנית של הגדרות מכונה חדשה עם ההגדרה הנדרשת ואז מחילים את התבנית החדשה על קבוצת ה-MIG. ה-MIG מעדכן את מכונות ה-VM באמצעות שיטת העדכון שתבחרו: אוטומטית או סלקטיבית. בוחרים שיטה מתאימה על סמך הדרישות שלכם לגבי זמינות ויעילות תפעולית. מידע נוסף על שיטות העדכון האלה של MIG זמין במאמר החלת הגדרות חדשות של מכונות וירטואליות ב-MIG.
תמונות VM
במקום להשתמש בתמונות ציבוריות שסופקו על ידי Google, מומלץ ליצור מכונות וירטואליות ולהשתמש בתמונות של מערכת הפעלה בהתאמה אישית שמכילות את ההגדרות והתוכנות שהאפליקציות שלכם צריכות. אתם יכולים לקבץ את התמונות המותאמות אישית למשפחת תמונות מותאמת אישית. משפחת תמונות תמיד מצביעה על התמונה העדכנית ביותר במשפחה, כך שתבניות וסקריפטים של מופעים יכולים להשתמש בתמונה הזו בלי שתצטרכו לעדכן הפניות לגרסה ספציפית של תמונה. חשוב לעדכן באופן קבוע את התמונות המותאמות אישית כדי לכלול את עדכוני האבטחה והתיקונים שמסופקים על ידי ספק מערכת ההפעלה.
תבניות של הגדרות מכונה דטרמיניסטיות
אם תבניות המופעים שבהן אתם משתמשים ב-MIG כוללות סקריפטים להפעלה כדי להתקין תוכנה של צד שלישי, ודאו שהסקריפטים מציינים במפורש פרמטרים של התקנת תוכנה, כמו גרסת התוכנה. אחרת, כשה-MIG יוצר את המכונות הווירטואליות, יכול להיות שהתוכנה שמותקנת במכונות הווירטואליות לא תהיה עקבית. לדוגמה, אם תבנית של הגדרות מכונה שלכם כוללת סקריפט לטעינה בזמן ההפעלה להתקנת Apache HTTP Server 2.0 (החבילה apache2), צריך לוודא שהסקריפט מציין את הגרסה המדויקת של apache2 שצריך להתקין, כמו גרסה 2.4.53. מידע נוסף זמין במאמר תבניות דטרמיניסטיות של מכונות וירטואליות.
שיקולים תפעוליים נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לקחת בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: Operational excellence.
אופטימיזציה של הביצועים
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן ולבנות טופולוגיה אזורית ב-Google Cloud שעומדת בדרישות הביצועים של עומסי העבודה.
ביצועי מחשוב
Compute Engine מציע מגוון רחב של סוגי מכונות מוגדרים מראש וניתנים להתאמה אישית לעומסי העבודה שאתם מריצים במכונות וירטואליות. בוחרים סוג מכונה מתאים בהתאם לדרישות הביצועים. מידע נוסף זמין במאמר השוואה בין משפחות של מכונות ומשאבים.
ריבוי שרשורים ב-VM
כל מעבד וירטואלי (vCPU) שמוקצה למכונה וירטואלית ב-Compute Engine מיושם כריבוי נימים (multithreading) של חומרה יחידה. כברירת מחדל, שתי ליבות וירטואליות של מעבד (vCPU) חולקות ליבה פיזית של מעבד. באפליקציות שכוללות פעולות מקבילות מאוד או שמבצעות חישובים של נקודות צפות (כמו ניתוח רצפים גנטיים ומודלים של סיכונים פיננסיים), אפשר לשפר את הביצועים על ידי הקטנת מספר השרשורים שפועלים בכל ליבת CPU פיזית. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.
לריבוי הליכי משנה במכונה וירטואלית עשויות להיות השלכות על הרישוי של תוכנות מסוימות של צד שלישי, כמו מסדי נתונים. מידע נוסף זמין במסמרי העזרה בנושא רישוי של תוכנות צד שלישי.
Network Service Tiers
מסלולי שירות הרשת מאפשרים לכם לבצע אופטימיזציה של העלות והביצועים של עומסי העבודה ברשת. אתם יכולים לבחור במסלול פרימיום או במסלול רגיל. במסלול הפרימיום, תעבורת הנתונים עוברת דרך תשתית הפרימיום הגלובלית של Google כדי להשיג איבוד מינימלי של מנות וזמן אחזור נמוך. במסלול הרגיל, תעבורת הנתונים מועברת באמצעות קישור בין רשתות שכנות (peering), ספקי אינטרנט (ISP) או רשתות העברה בנקודת קצה PoP שהכי קרובה לאזור שבו פועלת עומס העבודה שלכם Google Cloud . כדי לבצע אופטימיזציה של הביצועים, מומלץ להשתמש במסלול פרימיום. כדי לבצע אופטימיזציה של העלות, מומלץ להשתמש במסלול הרגיל.
ביצועי הרשת
עבור עומסי עבודה שנדרש בהם זמן אחזור נמוך ברשת בין מכונות וירטואליות בשכבות האפליקציה והאינטרנט, אפשר ליצור מדיניות מיקום קומפקטית ולהחיל אותה על תבנית ה-MIG שמשמשת לשכבות האלה. כשקבוצת ה-MIG יוצרת מכונות וירטואליות, היא ממקמת אותן בשרתים פיזיים שקרובים זה לזה. מדיניות מיקום קומפקטית עוזרת לשפר את ביצועי הרשת בין מכונות וירטואליות, ומדיניות מיקום מפוזרת יכולה לעזור לשפר את הזמינות של מכונות וירטואליות, כפי שמתואר קודם. כדי להשיג איזון אופטימלי בין ביצועי הרשת לזמינות, כשיוצרים מדיניות מיקום קומפקטית, אפשר לציין את המרחק המינימלי בין המכונות הווירטואליות. מידע נוסף זמין במאמר סקירה כללית על מדיניות בנושא מיקומי מודעות.
ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב הפס ברשת של תעבורת נתונים יוצאת. המגבלה הזו תלויה בסוג המכונה של המכונה הווירטואלית ובשאלה אם התנועה מנותבת דרך אותה רשת VPC כמו המכונה הווירטואלית של המקור. כדי לשפר את ביצועי הרשת של מכונות וירטואליות עם סוגי מכונות מסוימים, אפשר להגדיל את רוחב הפס המקסימלי של תעבורת הנתונים היוצאת (egress) על ידי הפעלת רשת Tier_1.
שיקולי ביצועים נוספים
כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: Performance optimization.
המאמרים הבאים
- מידע נוסף על המוצרים שבהם נעשה שימוש בארכיטקטורת ההפניה הזו:
Google Cloud
- סקירה כללית על Cloud Load Balancing
- קבוצות של מכונות
- איך מתחילים להעביר את עומסי העבודה אל Google Cloud
- כדאי לעיין בארכיטיפים של פריסות ולבחור מתוכם כדי לבנות ארכיטקטורות לעומסי העבודה בענן.
- כדאי לעיין באפשרויות הארכיטקטורה לתכנון תשתיות מהימנות לעומסי העבודה שלכם ב- Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Samantha He | Technical Writer
תורמי תוכן אחרים:
- Ben Good | Solutions Architect
- Carl Franklin | Director, PSO Enterprise Architecture
- Daniel Lees | Cloud Security Architect
- Gleb Otochkin | Cloud Advocate, Databases
- מארק שלגנהוף | כותב טכני, רישות
- Pawel Wenda | Group Product Manager
- שון דרינגטון | מנהל קבוצת מוצרים, אחסון
- Sekou Page | Outbound Product Manager
- Simon Bennett | Group Product Manager
- Steve McGhee | Reliability Advocate
- Victor Moreno | Product Manager, Cloud Networking