מיקום גיאוגרפי ואזורים

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

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

נסו בעצמכם

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

מתחילים לעבוד בלי לשלם

אזורים ותחומים

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

חלק ממרכזי הנתונים האלה הם בבעלות Google ומופיעים בדף המיקומים, וחלק מושכרים מספקי צד שלישי של מרכזי נתונים.Google Cloud באישור ISO/IEC 27001 תוכלו לראות את רשימת המיקומים המלאה של מרכזי הנתונים של Google Cloud. אנחנו תמיד בוחרים את מרכז הנתונים של Google Cloud ומתכננים את התשתית כדי לספק רמה אחידה של ביצועים, אבטחה ואמינות, בין שמרכז הנתונים הוא בבעלותנו ובין שהוא מושכר. Google Cloud

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

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

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

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

אנחנו משתדלים להציע לפחות שלושה אזורי זמינות (שנבדלים זה מזה מבחינה פיזית ולוגית) בכל אזור לשימוש כללי.Google Cloud

מאמרי עזרה קשורים בנושא מיקום

משאבים של תחום מוגדר

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

משאבים אזוריים

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

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

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

לשירותים הבאים יש מיקומים במספר אזורים, בנוסף לכל מיקום אזורי:

  • Artifact Registry
  • Bigtable
  • Sensitive Data Protection
  • Cloud Healthcare API
  • Cloud KMS
  • Container Registry
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Datastore
  • Firestore

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

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

שירותים גלובליים

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

שירותים פנימיים

מאחורי שירותים רבים של Google Cloud ללקוחות עומדים מגוון שירותים פנימיים מוכחים שנותנים להם גב, כמו Spanner‏, Colossus, ‏Brog ו-Chubby. Google Cloud

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

אפשר להריץ את השירותים הפנימיים הגלובליים או לבצע להם רפליקה באזורים הבאים בענן:

אמריקה

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

אירופה

  • europe-north1
  • europe-west1
  • europe-west4

אסיה

  • asia-east1
  • asia-southeast1

יחסי תלות בין שירותים

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

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

‫Google Cloud מספקת ללקוחות Google Cloud הנחיות ברורות בקשר לתכנון הארכיטקטורה של האפליקציות שלהם בהתאם לרמת העמידות הנדרשת, במיוחד במוצרים נפוצים של Google Cloud כמו‏ Compute Engine, ‏BigQuery, ‏Pub/Sub ושירותים אחרים. באתר הציבורי שלנו אנחנו מספקים ללקוחות Google Cloud הנחיות ברורות בקשר לתכנון הארכיטקטורה של האפליקציות שלהם בהתאם לרמת העמידות הנדרשת, במיוחד במוצרים נפוצים של Google Cloud כמו‏ Compute Engine, ‏BigQuery, ‏Pub/Sub ושירותים אחרים. Google Cloud

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

יחסי תלות נפוצים בין כל השירותים

  • מישור הנתונים של הזהות לאימות ולהרשאות
  • שירותים פנימיים שמאפשרים כניסה לחשבון, אחסון מטא-נתונים וניהול תהליכי עבודה
  • הגישה לממשקי API תלויה ב-DNS, במאזני עומסים שמופצים גלובלית וב-point of presence (‏PoP). Google Cloud
  • ההגדרות של משאבים גלובליים: לדוגמה, כללי המדיניות של IAM, הכללים הגלובליים של חומת האש, ההגדרות הגלובליות של מאזן העומסים והנושאים ב-Pub/Sub שמאוחסנים ברפליקות של מסדי נתונים
  • כשנשלחת בקשה משירותי Google Cloud לנקודות קצה שבשליטת הלקוח, לדוגמה, אחזור מפתחות לקוח ב-Cloud EKM או מסירת הודעות ב-Pub/Sub, הבקשות האלה תלויות בתשתית הרשת הגלובלית שלנו לצורך גישה לנקודות הקצה שבשליטת הלקוח.

שירותים עם יחסי תלות נוספים

  • שירותי Compute Engine
    • מישורי הנתונים של Google Cloud VM ושל Persistent Disk תלויים ברמה פרטנית יותר בשירותי Compute Engine ו-Cloud Storage, כמו Borg ו-Colossus
  • ‫Google Cloud ושירותי אחסון התשתית, כמו Spanner, ‏Bigtable ו-Cloud Storage תלויים:
    • בתשתית ההצפנה וניהול המפתחות ללקוח (Cloud KMS או Cloud EKM) ובתשתית הפנימית למפתחות שבבעלות Google
    • בשירותים פנימיים לאפשרויות כניסה לחשבון ובקרת הגישה לנתונים
    • בשירותים פנימיים של רפליקות נתונים, כשהנתונים צפויים להיות זמינים במספר אזורים
    • גיבויים שהוגדרו מפורשות ורפליקות לאזורים אחרים תלויים ביכולת החיבור ברשת בין אזורים
  • שירותי העברת הודעות
    • שירותי Pub/Sub תלויים בתשתית הרשת הגלובלית שלנו לצורך גישה לנקודות הקצה שבשליטת הלקוח
  • שירותי רשתות
    • השירותים של איזון העומסים הגלובלי, DNS ויתירות כשל בין אזורים תלויים בתשתית הפיזית של הרשתות
    • היכולת למנוע התקפות DDos והתקפות דומות תלויה ברמה פרטנית יותר בתשתית של Compute Engine
  • שירותים מנוהלים ומתארחים, כמו GKE ו-Cloud SQL
    • השירותים האלה תלויים ב-Compute Engine וב-Container Registry או ב-Artifact Registry לתמונות של מכונות וירטואליות
  • תשתית עצמאית פרטנית יותר
    • מישור הבקרה הפנימי שלנו ברמת האשכולות, כולל Borg ומארגי רשתות
    • אחסון ברמת האשכולות, כמו Colossus
    • תשתית להצפנה ולניהול מפתחות

תחזוקה ושיפור הזמינות והעמידות

Site Reliability Engineering‏ (SRE) הוא הארגון הפנימי של Google שמיועד לעבודה על זמינות, זמן אחזור, ביצועים וקיבולת. הפסקות זמניות בשירות וחוסר זמינות של שירותים קשורים לפריסת קוד חדש או לשינויים בסביבה. אנחנו משתמשים בשיטות המומלצות בתחום ב-SRE כדי לאזן בין הצורך להפיץ תוכנות חדשות לבין שמירה על סביבות מאובטחות, מתוך הבנה שהשינויים הנדרשים האלה עלולים לגרום לזמני השבתה.

שותפויות עם הלקוחות ליצירת שירותים עמידים

אם יש לכם צרכים קריטיים ואתם זקוקים לארכיטקטורה עם עמידות ויכולת התאוששות מאסון, צוותי ה-SRE/CRE וה-PSO שלנו יוכלו לעזור לכם לתכנן את הארכיטקטורה של האפליקציות כדי לגשר בין מספר אזורים ותחומים (zones), ולסייע לכם בתכנון מערכות עם זמינות גבוהה (HA).

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

Point of presence (PoP)

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

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

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

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

שיקולים בפריסת אפליקציות

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

מומלץ להשתמש במשאבים הבאים:

כדי ליצור אפליקציות עם יכולת התאוששות מאסון שימשיכו לפעול במקרה של תקלה ממושכת באזורים שלמים

לנתונים, מומלץ ליישם לפחות אחת מהאסטרטגיות הבאות:

  • להשתמש בשירותי אחסון המנוהלים במספר אזורים, כמו Cloud Storage, ‏Datastore, ‏Firestore ו-Spanner
  • להשתמש במשאבים אזוריים או של תחום מוגדר, אבל ליצור קובץ snapshot של הנתונים במשאב המנוהל במספר אזורים, כמו Cloud Storage, ‏Datastore, ‏Firestore ו-Spanner.
  • להשתמש במשאבים אזוריים או של תחום מוגדר, אבל לנהל את הנתונים שלכם עם רפליקות באזורים נוספים.

למחשוב, מומלץ ליישם את האסטרטגיה הבאה:

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

למידע נוסף על יחסי תלות בין שירותים תוכלו לפנות לצוות המכירות.

מדריכים ופתרונות נוספים

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

תבניות לאפליקציות עמידות שניתנות להרחבה

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

יצירת מאזן עומסים ב-HTTPS

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

תכנון מערכות עמידות

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

גיבוי ושחזור של נתוני Cassandra באמצעות Cloud Storage

כאן תלמדו איך מוסיפים תוכנית בסיסית להתאוששות מאסון (DR) להתקנה של Cassandra, על ידי גיבוי הנתונים ב-Cloud Storage ושחזור הנתונים מ-Cloud Storage.

מדריך להכנת תוכנית התאוששות מאסון

כאן תקראו עקרונות כלליים להכנה ולבדיקה של תוכנית התאוששות מאסון באמצעות Google Cloud.