פריסה במספר אזורים ב-Compute Engine

Last reviewed 2025-08-11 UTC

במאמר הזה מוצגת ארכיטקטורת הפניה לאפליקציה מרובת-שכבות שפועלת במכונות וירטואליות ב-Compute Engine באזורים שונים ב- Google Cloud. אתם יכולים להשתמש בארכיטקטורת העזר הזו כדי להעביר (lift and shift) ביעילות אפליקציות מקומיות לענן, עם שינויים מינימליים באפליקציות. במסמך מתוארים גם גורמי העיצוב שכדאי לקחת בחשבון כשבונים ארכיטקטורה רב-אזורית לאפליקציות בענן. קהל היעד של המסמך הזה הוא אדריכטי ענן.

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורה של אפליקציה שפועלת במצב פעיל-פעיל במערכים מבודדים שנפרסים בשני אזורים של Google Cloud . בכל אזור, האפליקציה פועלת באופן עצמאי בשלושה תחומים. הארכיטקטורה תואמת לGoogle Cloud ארכיטיפ של פריסה מרובת אזורים, וכך מבטיחה שהטופולוגיה שלכם תהיה חסינה מפני הפסקות חשמל באזורים ובאזורים, ושתספק זמני אחזור נמוכים למשתמשי האפליקציה. Google Cloud

ארכיטקטורה רב-אזורית באמצעות מאזן עומסים גלובלי

הארכיטקטורה מבוססת על מודל הענן של תשתית כשירות (IaaS). אתם מקצים את משאבי התשתית הנדרשים (מחשוב, רשת ואחסון) ב- Google Cloud, ושומרים על שליטה מלאה במערכת ההפעלה, בתוכנת הביניים ובשכבות הגבוהות יותר של מחסנית האפליקציות, ועל האחריות עליהן. מידע נוסף על IaaS ומודלים אחרים של ענן זמין במאמר PaaS לעומת IaaS לעומת SaaS לעומת CaaS: מה ההבדלים?

התרשים שלמעלה כולל את הרכיבים הבאים:

רכיב מטרה
מאזן עומסים גלובלי חיצוני

מאזן העומסים הגלובלי החיצוני מקבל בקשות ממשתמשים ומפיץ אותן לאפליקציה. מאזן העומסים הגלובלי החיצוני מפרסם כתובת IP אחת של anycast, אבל הוא מיושם כמספר גדול של שרתי proxy בממשקי קצה של Google‏ (GFE). בקשות של לקוחות מופנות ל-GFE שהכי קרוב ללקוח.
קבוצות אזוריות של מופעי מכונה מנוהלים (MIG) לשכבת האינטרנט

שכבת האינטרנט של האפליקציה נפרסת במכונות וירטואליות של Compute Engine ששייכות לקבוצות אזוריות של מכונות מנוהלות (MIG). קבוצות ה-MIG האלה הן קצה עורפי של מאזן העומסים הגלובלי.

כל קבוצת MIG מכילה מכונות וירטואליות של Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית כזו מארחת מופע עצמאי של שכבת האינטרנט של האפליקציה.
מאזני עומסים פנימיים אזוריים

מאזן העומסים הפנימי בכל אזור מפזר את התנועה ממכונות וירטואליות בשכבת האינטרנט למכונות וירטואליות בשכבת האפליקציה באותו אזור.
קבוצות אזוריות של מכונות וירטואליות בניהול (MIG) לרמת האפליקציה

שכבת האפליקציה נפרסת במכונות וירטואליות של Compute Engine שמהוות חלק מקבוצות אזוריות של מכונות מנוהלות (MIG). ה-MIG בכל אזור הוא הבק-אנד של מאזן העומסים הפנימי באותו אזור.

כל קבוצת MIG מכילה מכונות וירטואליות של Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית מארחת מופע עצמאי של רמת האפליקציה.
מסד נתונים של צד שלישי שנפרס במכונות וירטואליות ב-Compute Engine

הארכיטקטורה שמוצגת במסמך הזה כוללת מסד נתונים של צד שלישי (כמו PostgreSQL) שנפרס במכונות וירטואליות ב-Compute Engine בשני האזורים. אתם יכולים להגדיר שכפול בין אזורים עבור מסדי הנתונים, ולהגדיר את מסד הנתונים בכל אזור כך שיעבור למסד הנתונים באזור השני במקרה של כשל. היכולות של השכפול והמעבר לגיבוי תלויות במסד הנתונים שבו אתם משתמשים.

התקנה וניהול של מסד נתונים של צד שלישי דורשים מאמץ נוסף ועלות תפעולית לשכפול, להחלת עדכונים, למעקב ולהבטחת זמינות. כדי להימנע מהתקנה וניהול של מסד נתונים של צד שלישי, אפשר להשתמש במסד נתונים מנוהל כמו מופע Spanner במספר אזורים, וליהנות מתכונות מובנות של זמינות גבוהה (HA).
רשת של ענן וירטואלי פרטי (VPC) ותת-רשתות

כל Google Cloud המשאבים בארכיטקטורה משתמשים ברשת 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מספקת.

זמינות גבוהה למשתמשים שמפוזרים גיאוגרפית

אנחנו ממליצים על פריסה במספר אזורים לאפליקציות שהן קריטיות לעסק, ושבהן זמינות גבוהה ועמידות מפני הפסקות חשמל באזור הן חיוניות. אם אזור מסוים לא זמין מסיבה כלשהי (גם אם מדובר בשיבוש בקנה מידה גדול שנגרם מאסון טבע), המשתמשים באפליקציה לא יחוו השבתה. התנועה מנותבת לאפליקציה באזורים הזמינים האחרים. אם הנתונים משוכפלים באופן סינכרוני, יעד זמן ההתאוששות (RTO) הוא כמעט אפס.

זמן טעינה קצר למשתמשי האפליקציה

אם המשתמשים שלכם נמצאים באזור גיאוגרפי ספציפי, כמו יבשת, אתם יכולים להשתמש בפריסה רב-אזורית כדי להשיג איזון אופטימלי בין זמינות לבין ביצועים. כשאחד מהאזורים מושבת, מאזן העומסים הגלובלי שולח בקשות שמקורן באותו אזור לאזור אחר. המשתמשים לא מרגישים השפעה משמעותית על הביצועים כי האזורים נמצאים באזור גיאוגרפי אחד.

חלופה לעיצוב

הארכיטקטורה שלמעלה משתמשת במאזן עומסים גלובלי, שתומך בתכונות מסוימות לשיפור המהימנות של הפריסות, כמו שמירה במטמון קצה באמצעות Cloud CDN. בקטע הזה מוצגת ארכיטקטורה חלופית שמשתמשת במאזני עומסים אזוריים וב-Cloud DNS. הארכיטקטורה החלופית הזו תומכת בתכונות הנוספות הבאות:

  • סיום Transport Layer Security ‏ (TLS) באזורים שצוינו.
  • אפשרות להציג תוכן מהאזור שציינתם. עם זאת, יכול להיות שהאזור הזה לא יהיה האזור עם הביצועים הכי טובים בזמן נתון.
  • מגוון רחב יותר של פרוטוקולי חיבור אם משתמשים במאזן עומסי רשת להעברת סיגנל ללא שינוי.

מידע נוסף על ההבדלים בין מאזני עומסים אזוריים לבין מאזני עומסים גלובליים זמין במאמרים איזון עומסים גלובלי לעומת איזון עומסים אזורי ומצבי פעולה.

ארכיטקטורה רב-אזורית באמצעות מאזני עומסים אזוריים ו-DNS.

הארכיטקטורה האלטרנטיבית בתרשים שלמעלה חסינה מפני הפסקות חשמל באזורים ובתחומים. אזור ציבורי של Cloud DNS מעביר בקשות של משתמשים לאזור המתאים. מאזני עומסים חיצוניים אזוריים מקבלים בקשות ממשתמשים ומפיצים אותן בין המכונות בשכבת האינטרנט של האפליקציה בכל אזור. שאר הרכיבים בארכיטקטורה הזו זהים לרכיבים בארכיטקטורה שמבוססת על מאזן עומסים גלובלי.

שיקולים בתכנון

בקטע הזה מוסבר איך להשתמש בארכיטקטורת ההפניה הזו כדי לפתח ארכיטקטורה שעונה על הדרישות הספציפיות שלכם לגבי עיצוב המערכת, אבטחה, אמינות, יעילות תפעולית, עלות וביצועים.

Google Cloud

כשיוצרים ארכיטקטורה לעומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות שמפורטות בGoogle Cloud Well-Architected Framework.

עיצוב המערכת

בקטע הזה מוסבר איך לבחור Google Cloud אזורים לפריסה במספר אזורים ואיך לבחור Google Cloud שירותים מתאימים. Google Cloud

בחירת אזור

כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, חשוב לקחת בחשבון את הגורמים והדרישות הבאים:

יכול להיות שחלק מהגורמים והדרישות האלה יחייבו פשרות. לדוגמה, יכול להיות שהאזור הכי חסכוני לא יהיה האזור עם טביעת הרגל הפחמנית הכי נמוכה. למידע נוסף, ראו שיטות מומלצות לבחירת אזורים ב-Compute Engine.

תשתית מחשוב

הארכיטקטורה לדוגמה במאמר הזה משתמשת במכונות וירטואליות של Compute Engine עבור רמות מסוימות של האפליקציה. בהתאם לדרישות של האפליקציה, אפשר לבחור מבין שירותי מחשוב אחרים של Google Cloud :

  • קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine‏ (GKE). ‫GKE הוא מנוע לתזמור קונטיינרים שמבצע אוטומטית פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
  • Serverless: אם אתם מעדיפים להתמקד בנתונים ובאפליקציות שלכם במקום בהגדרה ובהפעלה של משאבי תשתית, אתם יכולים להשתמש בשירותים serverless כמו Cloud Run.

ההחלטה אם להשתמש במכונות וירטואליות, במאגרי מידע או בשירותים ללא שרתים כרוכה בפשרה בין גמישות ההגדרה לבין מאמץ הניהול. מכונות וירטואליות וקונטיינרים מספקים גמישות רבה יותר בהגדרות, אבל אתם אחראים לניהול המשאבים. בארכיטקטורה ללא שרת (serverless), אתם פורסים עומסי עבודה בפלטפורמה שהוגדרה מראש ודורשת מינימום מאמץ ניהולי. מידע נוסף על בחירת שירותי מחשוב מתאימים לעומסי העבודה ב-Google Cloudזמין במאמר אירוח אפליקציות ב- Google Cloud.

שירותי אחסון

בארכיטקטורות שמוצגות במסמך הזה נעשה שימוש בדיסקים לאחסון מתמיד אזורי בכל הרמות. דיסקים לאחסון מתמיד (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 לא תומך בדרישות ההגדרה שלכם, או אם אתם צריכים גישה למערכת ההפעלה, אתם יכולים לפרוס מכונה של אשכול יתירות כשל (FCI) של Microsoft SQL Server. בתרחיש הזה, אפשר להשתמש ב-Google Cloud NetApp Volumes, שירות מנוהל לחלוטין, כדי לספק אחסון SMB עם זמינות רציפה (CA) למסד הנתונים.

כשמתכננים את האחסון לעומסי העבודה, צריך לקחת בחשבון את המאפיינים הפונקציונליים, את דרישות העמידות, את ציפיות הביצועים ואת יעדי העלות. מידע נוסף זמין במאמר בנושא תכנון אסטרטגיית אחסון אופטימלית לעומס העבודה בענן.

שירותי מסדי נתונים

בארכיטקטורת ההפניה במסמך הזה נעשה שימוש במסד נתונים של צד שלישי שנפרס במכונות וירטואליות של Compute Engine. התקנה וניהול של מסד נתונים של צד שלישי כרוכים במאמץ ובעלויות של פעולות כמו החלת עדכונים, מעקב והבטחת זמינות, ביצוע גיבויים והתאוששות מכשלים.

כדי להימנע מהמאמץ ומהעלות של התקנה וניהול של מסד נתונים של צד שלישי, אפשר להשתמש בשירות מנוהל של מסד נתונים כמו Cloud SQL,‏ AlloyDB ל-PostgreSQL,‏ Bigtable,‏ Spanner או Firestore. שירותי מסד הנתונים האלה מספקים הסכמי רמת שירות (SLA) לזמן פעולה, והם כוללים יכולות ברירת מחדל למדרגיות ולניטור. Google Cloud

אם עומס העבודה שלכם צריך מסד נתונים של 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 בארכיטקטורה שלכם, כדאי להטמיע את Identity-Aware Proxy‏ (IAP) ואת Cloud OS Login API. ‫IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). ‫Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.

הצפנת דיסק

כברירת מחדל, הנתונים שמאוחסנים בדיסקים לאחסון מתמיד מוצפנים באמצעותGoogle-owned and Google-managed encryption keys. כדי להוסיף שכבת הגנה נוספת, אתם יכולים להצפין את Google-owned and managed key באמצעות מפתחות שבבעלותכם ושאתם מנהלים ב-Cloud Key Management Service‏ (Cloud KMS). מידע נוסף זמין במאמרים בנושא הצפנת דיסקים לכרכים של Hyperdisk והצפנת נתונים באמצעות מפתחות הצפנה בניהול הלקוח.

אבטחת רשת

כדי לשלוט בתעבורת הרשת בין המשאבים בארכיטקטורה, צריך להגדיר מדיניות מתאימה של Cloud Next Generation Firewall (NGFW).

שיקולים לגבי מיקום הנתונים

אתם יכולים להשתמש במאזני עומסים אזוריים כדי לבנות ארכיטקטורה רב-אזורית שתעזור לכם לעמוד בדרישות של מיקום אחסון הנתונים. לדוגמה, יכול להיות שבמדינה באירופה יש דרישה שכל נתוני המשתמשים יאוחסנו ויהיו נגישים במרכזי נתונים שנמצאים פיזית באירופה. כדי לעמוד בדרישה הזו, אפשר להשתמש בארכיטקטורה שמבוססת על איזון עומסים אזורי. באדריכלות הזו, האפליקציה פועלת בGoogle Cloud אזורים באירופה, ואתם משתמשים ב-Cloud DNS עם מדיניות ניתוב מוגבלת גיאוגרפית כדי לנתב את התעבורה דרך מאזני עומסים אזוריים. כדי לעמוד בדרישות של מיקום אחסון הנתונים ברמת מסד הנתונים, כדאי להשתמש בארכיטקטורה מפוצלת במקום ברפליקציה בין אזורים. בגישה הזו, הנתונים בכל אזור מבודדים, אבל אי אפשר להטמיע זמינות גבוהה ומעבר לגיבוי בעת כשל במסד הנתונים בין אזורים.

שיקולי אבטחה נוספים

כשמפתחים את הארכיטקטורה של עומס העבודה, כדאי להביא בחשבון את השיטות המומלצות וההמלצות לאבטחה ברמת הפלטפורמה שמפורטות בתוכנית לניהול יסודות האבטחה בארגון ובGoogle Cloud מסגרת Well-Architected: אבטחה, פרטיות ותאימות.

אמינות

בקטע הזה מתוארים גורמים שצריך לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לבנות ולתפעל תשתית אמינה לפריסות במספר אזורים ב- Google Cloud.

עמידות בפני הפסקות חשמל בתשתית

בארכיטקטורת פריסה רב-אזורית, אם רכיב כלשהו במערך התשתית נכשל, האפליקציה יכולה לעבד בקשות אם קיים לפחות רכיב אחד מתפקד עם קיבולת מספקת בכל רמה. לדוגמה, אם מופע של שרת אינטרנט נכשל, מאזן העומסים מעביר את בקשות המשתמשים למופעים אחרים של שרת אינטרנט שזמינים. אם מכונה וירטואלית שמארחת מופע של שרת אינטרנט או שרת אפליקציות קורסת, קבוצת ה-MIG יוצרת מחדש את המכונה הווירטואלית באופן אוטומטי.

אם מתרחש שיבוש בשירות באזור מסוים, מאזן העומסים לא מושפע כי הוא משאב אזורי. יכול להיות שהפסקת חשמל באזור תשפיע על מכונות וירטואליות ספציפיות ב-Compute Engine. אבל האפליקציה ממשיכה להיות זמינה ומגיבה כי המכונות הווירטואליות נמצאות ב-MIG אזורי. קבוצת MIG אזורית מבטיחה שמכונות וירטואליות חדשות ייווצרו באופן אוטומטי כדי לשמור על המספר המינימלי של מכונות וירטואליות שהוגדר. אחרי ש-Google תפתור את הבעיה בהפסקת הפעילות של האזור, תצטרכו לוודא שהאפליקציה פועלת כמצופה בכל האזורים שבהם היא נפרסה.

אם יש הפסקת חשמל בכל האזורים באחד מהאזורים, או אם מתרחשת הפסקת חשמל בכל האזור, האפליקציה באזור השני נשארת זמינה ומגיבה. מאזן העומסים החיצוני הגלובלי מפנה את התעבורה לאזור שלא מושפע מההשבתה. אחרי ש-Google תפתור את הבעיה באזור, תצטרכו לוודא שהאפליקציה פועלת כצפוי באזור שבו הייתה הבעיה.

אם יש הפסקות זמניות בשני האזורים בארכיטקטורה הזו, האפליקציה לא תהיה זמינה. צריך להמתין עד ש-Google תפתור את ההשבתה, ואז לוודא שהאפליקציה פועלת כצפוי.

התאמה אוטומטית לעומס (autoscaling) של MIG

כשמריצים את האפליקציה על כמה קבוצות של מכונות וירטואליות לניהול מופעים (MIG) באזורים שונים, האפליקציה נשארת זמינה במהלך הפסקות חשמל באזורים מבודדים או באזורים. היכולת של קבוצות MIG ללא מצב (stateless) לבצע שינוי גודל אוטומטי מאפשרת לשמור על זמינות וביצועים של האפליקציה ברמות צפויות.

כדי לשלוט בהתנהגות של שינוי הגודל האוטומטי של קבוצות ה-MIG חסרות הסטטוס, אפשר לציין מדדי ניצול משאבים של יעד, כמו ניצול ממוצע של המעבד. אפשר גם להגדיר שינוי גודל אוטומטי מבוסס-תזמון לקבוצות MIG ללא שמירת מצב. אי אפשר להגדיר קנה מידה אוטומטי לקבוצות MIG עם שמירת מצב. מידע נוסף זמין במאמר בנושא קבוצות של מופעים עם שינוי גודל אוטומטי.

מגבלת הגודל של MIG

כשמחליטים על הגודל של קבוצות ה-MIG, צריך לקחת בחשבון את מגבלות ברירת המחדל והמגבלות המקסימליות על מספר המכונות הווירטואליות שאפשר ליצור בקבוצת MIG. מידע נוסף זמין במאמר הוספה והסרה של מכונות וירטואליות מקבוצת מופעי מכונה מנוהלים (MIG).

תיקון אוטומטי של מכונות וירטואליות

יכול להיות שהמכונות הווירטואליות שמארחות את האפליקציה פועלות וזמינות, אבל יש בעיות באפליקציה עצמה. יכול להיות שהאפליקציה תקפא, תקרוס או שלא יהיה לה מספיק זיכרון. כדי לוודא שאפליקציה מגיבה כמצופה, אפשר להגדיר בדיקות תקינות מבוססות-אפליקציה כחלק ממדיניות התיקון האוטומטי של קבוצות ה-MIG. אם האפליקציה במכונה וירטואלית מסוימת לא מגיבה, קבוצת ה-MIG מבצעת תיקון אוטומטי של המכונה הווירטואלית. מידע נוסף על הגדרת תיקון אוטומטי זמין במאמר מידע על תיקון מכונות וירטואליות לזמינות גבוהה.

מיקום ה-VM

בארכיטקטורה שמתוארת במסמך הזה, רמת האפליקציה ורמת האינטרנט פועלות במכונות וירטואליות של Compute Engine שמפוזרות על פני כמה אזורים. ההפצה הזו מבטיחה שהאפליקציה שלכם תהיה עמידה בפני הפסקות חשמל באזורים.

כדי לשפר את החוסן של הארכיטקטורה, אפשר ליצור מדיניות למיקום מרווח ולהחיל אותה על תבנית ה-MIG. כשקבוצת ה-VM המנוהלת יוצרת מכונות וירטואליות, היא ממקמת את המכונות הווירטואליות בכל אזור בשרתים פיזיים שונים (שנקראים מארחים), כך שהמכונות הווירטואליות עמידות בפני כשלים של מארחים ספציפיים. מידע נוסף זמין במאמר בנושא יצירה והחלה של מדיניות בנושא מיקום מודעות במכונות וירטואליות.

תכנון הקיבולת של מכונות וירטואליות

כדי לוודא שהקיבולת של מכונות וירטואליות ב-Compute Engine תהיה זמינה כשצריך להקצות מכונות וירטואליות, אפשר ליצור שמירת מקום. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שתבחרו. אפשר להגדיר הזמנה לפרויקט ספציפי, או לשתף אותה בין כמה פרויקטים. מידע נוסף על הזמנות זמין במאמר בחירת סוג הזמנה.

אחסון שומר מצב (Stateful)

שיטה מומלצת בתכנון אפליקציות היא להימנע מהצורך בדיסקים מקומיים עם שמירת מצב. אבל אם הדרישה קיימת, אתם יכולים להגדיר את הדיסקים המתמידים כך שיהיו בעלי מצב כדי להבטיח שהנתונים יישמרו כשמכונות ה-VM יתוקנו או ייצרו מחדש. עם זאת, מומלץ להשאיר את דיסקי האתחול בלי שמירת מצב, כדי שתוכלו לעדכן אותם לתמונות העדכניות ביותר עם גרסאות חדשות ותיקוני אבטחה. מידע נוסף זמין במאמר בנושא הגדרת דיסקים קשיחים מתמידים עם שמירת מצב בקבוצות של מכונות וירטואליות לניהול מופעים (MIG).

עמידות הנתונים

אתם יכולים להשתמש ב-Backup and DR כדי ליצור גיבויים של מכונות וירטואליות ב-Compute Engine, לאחסן אותם ולנהל אותם. שירות Backup and DR מאחסן נתוני גיבוי בפורמט המקורי שניתן לקריאה על ידי האפליקציה. כשנדרש, אתם יכולים לשחזר את עומסי העבודה שלכם לסביבת הייצור באמצעות נתונים מאחסון גיבוי לטווח ארוך, בלי שתצטרכו להכין או להעביר נתונים.

‫Compute Engine מספק את האפשרויות הבאות כדי לעזור לכם לוודא שהנתונים שמאוחסנים בכרכים של Persistent Disk יהיו עמידים:

זמינות מסד הנתונים

כדי להטמיע מעבר לגיבוי במקרה של כשל (failover) בין אזורים במסד נתונים שנפרס במכונה וירטואלית ב-Compute Engine, צריך מנגנון לזיהוי כשלים במסד הנתונים הראשי ותהליך למעבר לגיבוי למסד הנתונים המשני. הפרטים הספציפיים של מנגנון המעבר לגיבוי תלויים במסד הנתונים שבו אתם משתמשים. אתם יכולים להגדיר מופע של observer כדי לזהות כשלים במסד הנתונים הראשי ולתזמן את המעבר לגיבוי. כדי להימנע ממצב של פיצול מוח ולמנוע מעבר גיבוי מיותר, צריך להגדיר את כללי היתירות כשל בצורה מתאימה. לדוגמאות לארכיטקטורות שאפשר להשתמש בהן כדי להטמיע יתירות כשל למסדי נתונים של PostgreSQL, אפשר לעיין במאמר ארכיטקטורות לזמינות גבוהה של אשכולות PostgreSQL ב-Compute Engine.

שיקולים נוספים בנושא מהימנות

כשיוצרים את ארכיטקטורת הענן של עומס העבודה, כדאי לעיין בשיטות המומלצות ובהמלצות שקשורות למהימנות, שמפורטות במסמכים הבאים:

הוזלת עלויות

בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרה והפעלה של טופולוגיה Google Cloud רב-אזורית שנוצרת באמצעות ארכיטקטורת ההפניה הזו.

סוגי מכונות וירטואליות

כדי לעזור לכם לייעל את השימוש במשאבים של המכונות הווירטואליות, Compute Engine מספק המלצות לגבי סוגי מכונות. אפשר להשתמש בהמלצות כדי לבחור סוגי מכונות שתואמים לדרישות החישוב של עומס העבודה. אם אתם יכולים לחזות את השימוש שלכם במשאבים בעומסי העבודה, אתם יכולים להתאים אישית את סוג המכונה לצרכים שלכם ולחסוך כסף באמצעות סוגי מכונות בהתאמה אישית.

מודל הקצאת הרשאות למכונות וירטואליות

אם האפליקציה שלכם סובלת תקלות, מכונות וירטואליות זמניות יכולות לעזור לכם להפחית את העלויות של Compute Engine עבור המכונות הווירטואליות בשכבות האפליקציה והאינטרנט. העלות של מכונות Spot VM נמוכה משמעותית מזו של מכונות וירטואליות רגילות. עם זאת, יכול להיות ש-Compute Engine יפסיק את הפעילות של מכונות וירטואליות מסוג Spot או ימחק אותן באופן יזום כדי לפנות קיבולת.

מכונות וירטואליות מסוג Spot מתאימות לעבודות באצווה שיכולות לעמוד בדרישות של קדימות ולא דורשות זמינות גבוהה. מכונות וירטואליות מסוג Spot מציעות את אותם סוגי מכונות, אפשרויות וביצועים כמו מכונות וירטואליות רגילות. עם זאת, אם קיבולת המשאבים באזור מוגבלת, יכול להיות שקבוצות MIG לא יוכלו להגדיל את מספר המכונות הווירטואליות באופן אוטומטי לגודל היעד שצוין עד שהקיבולת הנדרשת תהיה זמינה שוב.

ניצול משאבים של מכונות וירטואליות

היכולת של קבוצות MIG ללא מצב (stateless) לבצע התאמה אוטומטית לעומס מאפשרת לאפליקציה לטפל בעלייה בתנועה בצורה חלקה, ועוזרת לצמצם את העלויות כשהצורך במשאבים נמוך. אי אפשר להגדיר קנה מידה אוטומטי לקבוצות MIG עם שמירת מצב.

רישוי של צד שלישי

כשמעבירים עומסי עבודה של צד שלישי אל Google Cloud, אפשר להוזיל את העלויות באמצעות שימוש ברישיונות קיימים (BYOL). לדוגמה, כדי לפרוס מכונות וירטואליות של Microsoft Windows Server, במקום להשתמש באימג' פרימיום שכולל עלות נוספת לרישיון של צד שלישי, אפשר ליצור ולהשתמש באימג' מותאם אישית של Windows BYOL. לאחר מכן משלמים רק על תשתית המכונה הווירטואלית שבה משתמשים ב- Google Cloud. האסטרטגיה הזו עוזרת לכם להמשיך להפיק ערך מההשקעות הקיימות שלכם ברישיונות של צד שלישי. אם תחליטו להשתמש בגישת BYOL, ההמלצות הבאות עשויות לעזור לכם להקטין את העלות:

  • אפשר להקצות את מספר ליבות המעבד הנדרש בנפרד מהזיכרון באמצעות סוגי מכונות בהתאמה אישית. כך מגבילים את עלות הרישוי של הצד השלישי למספר ליבות המעבד שדרושות לכם.
  • מפחיתים את מספר המעבדים הווירטואליים לכל ליבה מ-2 ל-1 על ידי השבתה של ריבוי נימים סימולטני (SMT).

אם פורסים מסד נתונים של צד שלישי כמו Microsoft SQL Server במכונות וירטואליות של Compute Engine, צריך לקחת בחשבון את עלויות הרישיון של תוכנת הצד השלישי. כשמשתמשים בשירות מסד נתונים מנוהל כמו Cloud SQL, עלויות הרישיון של מסד הנתונים כלולות בחיובים על השירות.

שיקולי עלות נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.

יעילות תפעולית

בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן ולבנות טופולוגיה של Google Cloud multi-region שאפשר להפעיל ביעילות.

עדכוני הגדרות של מכונות וירטואליות

כדי לעדכן את ההגדרה של המכונות הווירטואליות בקבוצת 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) של חומרה יחידה. כברירת מחדל, שני מעבדים וירטואליים חולקים ליבה פיזית של מעבד. ביישומים שכוללים פעולות מקבילות מאוד או שמבצעים חישובים של נקודה צפה (כמו ניתוח רצף גנטי ומידול של סיכונים פיננסיים), אפשר לשפר את הביצועים על ידי הקטנת מספר השרשורים שפועלים בכל ליבת CPU פיזית. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.

יכול להיות שלרישיון של תוכנות מסוימות של צד שלישי, כמו מסדי נתונים, יש השלכות על ריבוי הליכי משנה במכונה וירטואלית. מידע נוסף זמין במסמכי התיעוד בנושא רישוי של תוכנות צד שלישי.

Network Service Tiers

מסלולי שירות הרשת מאפשרים לכם לבצע אופטימיזציה של עלות הרשת והביצועים של עומסי העבודה. אתם יכולים לבחור במסלול פרימיום או במסלול רגיל. במסלול הפרימיום, תעבורת הנתונים עוברת דרך תשתית הפרימיום הגלובלית של Google כדי להשיג איבוד מינימלי של מנות וזמן אחזור נמוך. במסלול הרגיל, תעבורת הנתונים מועברת באמצעות קישור בין רשתות שכנות (peering), ספקי אינטרנט (ISP) או רשתות העברה בנקודת קצה PoP שהכי קרובה לאזור שבו פועלת עומס העבודה שלכם Google Cloud . כדי לשפר את הביצועים, מומלץ להשתמש במסלול פרימיום. כדי לבצע אופטימיזציה של העלות, מומלץ להשתמש במסלול הרגיל.

ביצועי הרשת

עבור עומסי עבודה שנדרש בהם זמן אחזור נמוך ברשת בין מכונות וירטואליות בשכבות של האפליקציה והאינטרנט, אפשר ליצור מדיניות מיקום קומפקטית ולהחיל אותה על תבנית ה-MIG שמשמשת לשכבות האלה. כשקבוצת ה-MIG יוצרת מכונות וירטואליות, היא ממקמת אותן בשרתים פיזיים שקרובים זה לזה. מדיניות מיקום קומפקטית עוזרת לשפר את ביצועי הרשת בין מכונות וירטואליות, ומדיניות מיקום מפוזרת יכולה לעזור לשפר את הזמינות של המכונות הווירטואליות, כמו שמתואר בהמשך. כדי להשיג איזון אופטימלי בין ביצועי הרשת לזמינות, כשיוצרים מדיניות מיקום קומפקטית, אפשר לציין את המרחק המינימלי בין מכונות וירטואליות. מידע נוסף זמין במאמר סקירה כללית על מדיניות בנושא מיקומי מודעות.

ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב הפס של הרשת ליציאה. המגבלה הזו תלויה בסוג המכונה של המכונה הווירטואלית ובשאלה אם התנועה מנותבת דרך אותה רשת VPC כמו המכונה הווירטואלית של המקור. כדי לשפר את ביצועי הרשת של מכונות וירטואליות עם סוגי מכונות מסוימים, אפשר להפעיל רשת Tier_1 ולקבל רוחב פס מקסימלי גבוה יותר של תעבורת נתונים יוצאת.

שמירה במטמון

אם האפליקציה שלכם מציגה נכסי אתר סטטיים והארכיטקטורה שלכם כוללת מאזן עומסים חיצוני של אפליקציות (ALB), אתם יכולים להשתמש ב-Cloud CDN כדי לשמור במטמון תוכן סטטי שמתבצעת אליו גישה באופן קבוע, במיקום קרוב יותר למשתמשים. ‫Cloud CDN יכול לעזור לשפר את הביצועים עבור המשתמשים, לצמצם את השימוש במשאבי התשתית בקצה העורפי ולהפחית את עלויות המסירה ברשת. מידע נוסף זמין במאמר בנושא שיפור הביצועים של אתרים והגנה משופרת על אתרים לצורך איזון עומסים.

שיקולי ביצועים נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: Performance optimization.

המאמרים הבאים

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: