נקודות קצה אזוריות וגלובליות

בדף הזה מוסבר על נקודות קצה (endpoints) של Bigtable, מה צריך לקחת בחשבון לפני שמשתמשים בהן ואיך מגדירים נקודת קצה באמצעות cbt CLI.

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

לפני שקוראים את המסמך הזה, כדאי להכיר את המושגים Instances, clusters, and nodes ו-App profiles.

מושגי המפתח כוללים את הדברים הבאים:

  • נקודת קצה של שירות: כתובת URL בסיסית שמציינת את כתובת הרשת של שירות API. ל-Bigtable יש נקודות קצה גלובליות ואזוריות.

  • נקודת קצה גלובלית: מאפשרת ל-Bigtable לאחסן את הנתונים במופע Bigtable ולנתב אותם לכל אזור שמכיל אחד מהאשכולות של המופע. נקודת הקצה הגלובלית של Cloud Bigtable API (Data API) היא bigtable.googleapis.com. נקודת הקצה (endpoint) של Data API שמוגדרת כברירת מחדל ניגשת לנקודת הקצה הגלובלית.

  • נקודת קצה אזורית: אוכפת הגבלות אזוריות, כדי להבטיח ש-Bigtable יאחסן ויעבד נתונים באזור מסוים. אפשר להשתמש בנקודות קצה אזוריות רק עם Cloud Bigtable API (Data API). ‫Bigtable לא תומך בנקודות קצה אזוריות עבור Cloud Bigtable Admin API.

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

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

אבל נקודות קצה אזוריות לא תומכות ב-Data Boost או ב-Cloud Bigtable Admin API. בנוסף, אי אפשר להגדיר את Bigtable כך שישיג אחוז זמינות חודשי של ‎>=99.999% ‎ כשמשתמשים בנקודות קצה אזוריות. מידע נוסף מופיע בקטע שיקולים לשימוש בנקודת קצה אזורית במסמך הזה.

מתי כדאי להשתמש בנקודות קצה גלובליות

כדאי להשתמש בנקודת קצה גלובלית במקרים הבאים:

  • אין לכם דרישות להגבלות אזוריות שמחייבות שימוש בנקודת קצה אזורית.
  • צריך להשתמש ב-Data Boost.
  • צריך להשתמש ב-Cloud Bigtable Admin API.
  • אתם צריכים אחוז זמינות חודשי של 99.999% לפחות.

שיקולים לשימוש בנקודת קצה אזורית

אם משתמשים בנקודת קצה אזורית, חשוב לשים לב לגורמים הבאים:

מיקומים באשכול

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

אפשר להשתמש רק בנקודת קצה אזורית ששייכת לאזור שבו רוצים לבודד את הנתונים. לדוגמה, אם אשכול נמצא באזור us-central1, אי אפשר להשתמש ב-bigtable.us-west1.rep.googleapis.com כדי להציג בקשות.

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

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

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

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

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

נניח שאתם שולחים בקשות באמצעות פרופיל אפליקציה שהוגדר לניתוב מרובה אשכולות למופע שיש לו אשכולות ב-us-west1-a (אורגון), us-west1-b (אורגון) ו-us-central1-a (איווה). אם שולחים את הבקשות האלה לנקודת הקצה האזורית bigtable.us-central1.rep.googleapis.com, כל הבקשות מטופלות על ידי us-central1-a גם אם לא מגדירים מחדש את פרופיל האפליקציה. בקשות שלא ניתן לטפל בהן באמצעות us-central1-a נכשלות.

שכפול

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

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

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

זמינות

כשמשתמשים בנקודות קצה אזוריות, אי אפשר להגדיר את Bigtable כך שישיג אחוז זמינות חודשי של ‎99.999%‎ ומעלה. כדי להשיג זמן פעולה חודשי של ‎>=99.999%‎, צריך מעבר אוטומטי לגיבוי (failover) של בקשות מעבר לגבולות אזוריים. נקודת קצה אזורית מונעת מעבר גיבוי אוטומטי (failover) כי היא מגבילה את כל הבקשות לאזור אחד. מידע נוסף על אחוזים חודשיים של זמן פעולה תקינה מופיע בהסכם רמת השירות (SLA) של Bigtable.

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

נקודת קצה אזורית היא בפורמט bigtable.REGION.rep.googleapis.com, כאשר REGION הוא שם אזור, כמו northamerica-northeast2. Google Cloud

לדוגמה, אם רוצים לבודד את הנתונים באזור איווה, מכיוון ששם האזור של איווה הוא us-central1, כתובת ה-URL של נקודת הקצה האזורית לאזור איווה היא bigtable.us-central1.rep.googleapis.com.

ציון נקודת קצה אזורית

אפשר לציין נקודת קצה אזורית של Bigtable באמצעות cbt CLI או ספריות הלקוח של Cloud Bigtable.

cbt

כדי לציין נקודת קצה אזורית ולבטל את נקודת הקצה הגלובלית באמצעות ה-CLI של cbt, אפשר להשתמש באפשרות --data-endpoint בבקשה, או להוסיף את השורה הבאה לקובץ ‎~/.cbtrc. מידע נוסף על יצירת קובץ ‎~/.cbtrc זמין במאמר בנושא הפניה ל-CLI של cbt.

data-endpoint = https://bigtable.REGION.rep.googleapis.com/

מחליפים את REGION באזור שבו רוצים להגדיר נקודת קצה אזורית, כמו us-central1 או europe-west1.

לדוגמה, כדי להגדיר את נקודת הקצה האזורית כ-us-central1, מוסיפים את השורה הבאה לקובץ ‎~/.cbtrc:

data-endpoint = https://bigtable.us-central1.rep.googleapis.com/

ציון נקודת הקצה הגלובלית

cbt

כדי לציין את נקודת הקצה הגלובלית, שולחים את הבקשה בלי להשתמש באפשרות --data-endpoint. אם הוספתם בעבר data-endpoint שורה לקובץ ‎~/.cbtrc, מחקו אותה.

הגבלת השימוש בנקודת קצה ל-API גלובלית

כדי לאכוף את השימוש בנקודות קצה אזוריות, אפשר להשתמש באילוץ constraints/gcp.restrictEndpointUsage של מדיניות הארגון כדי לחסום בקשות לנקודת קצה ל-API גלובלית. מידע נוסף מופיע במאמר בנושא הגבלת השימוש בנקודות קצה.

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