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

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

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

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

נסו בעצמכם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Artifact Registry
  • BigQuery
  • Bigtable
  • Cloud DLP
  • Cloud Healthcare API
  • Cloud Key Management Service
  • Container Registry
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Datastore
  • Firestore

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

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

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

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

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

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

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

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

אמריקה

  • 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 כמו‏ Compute Engine, ‏BigQuery, ‏Pub/Sub ושירותים אחרים.

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

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

  • מישור הנתונים של הזהות לאימות ולהרשאות
  • שירותים פנימיים שמאפשרים כניסה לחשבון, אחסון מטא-נתונים וניהול תהליכי עבודה
  • הגישה ל-Google Cloud APIs תלויה ב-DNS, במאזני עומסים שמופצים גלובלית וב-point of presence (‏PoP)
  • ההגדרות של משאבים גלובליים: לדוגמה, כללי המדיניות של 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.