דוגמאות להגדרות שכפול

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

בדף הזה מוסבר גם איך להחליט באילו הגדרות להשתמש בתרחישי שימוש אחרים.

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

לפני הוספת אשכולות למופע, עליך להיות מודע למגבלות החלות בעת שינוי מדיניות איסוף אשפה בטבלאות משוכפלות.

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

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

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

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

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

כדי לבודד שני עומסי עבודה:

  1. יצירת מכונה עם שני אשכולות.

  2. יוצרים שני פרופילים של אפליקציות, אחד בשם live-traffic ואחד בשם batch-analytics.

    אם מזהי האשכולות הם cluster-a ו-cluster-b, פרופיל האפליקציה live-traffic צריך לנתב בקשות אל cluster-a, ופרופיל האפליקציה batch-analytics צריך לנתב בקשות אל cluster-b. ההגדרה הזו מספקת עקביות של קריאה-כתיבה לאפליקציות שמשתמשות באותו פרופיל אפליקציה, אבל לא לאפליקציות שמשתמשות בפרופילים שונים של אפליקציות.

    במקרה הצורך, אפשר להפעיל עסקאות בשורה אחת בפרופיל האפליקציה live-traffic. אין צורך להפעיל טרנזקציות של שורה אחת בפרופיל האפליקציה של batch-analytics, בהנחה שתשתמשו בפרופיל האפליקציה הזה רק לקריאות.

  3. משתמשים בפרופיל של אפליקציית live-traffic כדי להריץ עומס עבודה של תנועה בזמן אמת.

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

כדי לבודד שני עומסי עבודה קטנים מעומס עבודה גדול יותר:

  1. יוצרים מכונה עם שלושה אשכולות.

    השלבים האלה מניחים שהאשכולות שלכם משתמשים במזהים cluster-a, cluster-b ו-cluster-c.

  2. יוצרים את פרופילי האפליקציות הבאים:

    • live-traffic-app-a: ניתוב של מקבץ יחיד מהאפליקציה אל cluster-a
    • ‫live-traffic-app-b: ניתוב של קלאסטר יחיד מהאפליקציה אל cluster-b
    • ‫batch-analytics: ניתוב של עבודת ניתוח הנתונים באצווה מאשכול יחיד אל cluster-c

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

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

יצירת זמינות גבוהה (HA)

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

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

ההגדרות הבאות יכולות לשפר את הזמינות.

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

    הגדרה לדוגמה:

    • ‫cluster-a באזור us-central1-a באיווה
    • cluster-b באזור europe-west1-d בבלגיה
    • ‫cluster-c באזור asia-east1-b בטייוואן

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

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

    הגדרה לדוגמה:

    • ‫cluster-a בטווח australia-southeast1-a בסידני
    • ‫cluster-b בטווח australia-southeast1-b בסידני

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

    החיוב הוא על רפליקציה של פעולות כתיבה בין אזורים.

    הגדרה לדוגמה:

    • cluster-a באזור asia-northeast1-c בטוקיו
    • cluster-b באזור asia-east2-b בהונג קונג

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

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

    הגדרה לדוגמה:

    • cluster-a באזור europe-west1-b בבלגיה
    • cluster-b באזור europe-west1-d בבלגיה
    • cluster-c באזור europe-north1-c בפינלנד

גיבוי כמעט בזמן אמת

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

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

כדי להטמיע את ההגדרה הזו:

  1. משתמשים בפרופיל אפליקציה עם ניתוב לאשכול יחיד כדי להריץ עומס עבודה.

  2. משתמשים במסוף Google Cloud כדי לעקוב אחרי האשכולות של המופע ולוודא שרק אשכול אחד מטפל בבקשות נכנסות.

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

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

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

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

  4. חשוב להמשיך לעקוב אחרי המופע. אפשר לראות שהאשכול השני מטפל בבקשות נכנסות.

שמירה על זמינות גבוהה ועמידות אזורית

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

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

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

כדי להגדיר את המופע לתרחיש השימוש הזה:

  1. יוצרים מופע Bigtable עם ארבעה אשכולות: שניים באזור א' ושניים באזור ב'. קלאסטרים באותו אזור צריכים להיות באזורים שונים.

    הגדרה לדוגמה:

    • ‫cluster-a באזור asia-south1-a במומבאי
    • ‫cluster-b באזור asia-south1-c במומבאי
    • cluster-c באזור asia-northeast1-a בטוקיו
    • cluster-d באזור asia-northeast1-b בטוקיו

  2. ממקמים שרת אפליקציות ליד כל אזור.

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

אפשרות ניתוב לאשכול יחיד

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

כדי להטמיע את ההגדרה הזו, צריך ליצור לפחות פרופיל אפליקציה אחד שמשתמש בניתוב של אשכול יחיד לכל אפליקציה ששולחת בקשות למופע. אתם יכולים להפנות את פרופילי האפליקציות לכל אשכול במופע Bigtable. לדוגמה, אם יש לכם שלוש אפליקציות שפועלות במומבאי ושש בטוקיו, אתם יכולים להגדיר פרופיל אפליקציה אחד לאפליקציה במומבאי שינותב ל-asia-south1-a ושני פרופילים שינותבו ל-asia-south1-c. באפליקציית טוקיו, מגדירים שלושה פרופילים של אפליקציות שמובילים ל-asia-northeast1-a ושלושה שמובילים ל-asia-northeast1-b.

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

אפשרות ניתוב מרובה אשכולות

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

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

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

אחסון נתונים קרוב למשתמשים

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

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

כדי להגדיר את המופע לתרחיש השימוש הזה:

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

  2. ממקמים שרת אפליקציות ליד כל אזור.

  3. יוצרים פרופילים של אפליקציות שדומים לפרופילים הבאים:

    • ‫clickstream-us: ניתוב לאשכול יחיד בארצות הברית
    • ‫clickstream-eu: ניתוב לאשכול יחיד באשכול באירופה
    • ‫clickstream-asia: ניתוב לאשכול יחיד לאשכול באסיה

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

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

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

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