בדף הזה מוסבר על תוכנית התאוששות מאסון (DR) ב-Cloud SQL.
סקירה כללית
ב- Google Cloud, תוכנית התאוששות מאסון (DR) של מסד נתונים נועדה לספק המשכיות של העיבוד, במיוחד כשאזור נכשל או לא זמין. Cloud SQL הוא שירות אזורי (כש-Cloud SQL מוגדר לזמינות גבוהה (HA)). לכן, אם האזור שמארח את מסד הנתונים ב-Cloud SQL לא זמין, גם מסד הנתונים ב-Cloud SQL לא זמין. Google Cloud
כדי להמשיך בעיבוד, צריך להפוך את מסד הנתונים לזמין באזור משני בהקדם האפשרי. בתוכנית ה-DR צריך להגדיר עותק לקריאה בלבד באזור אחר ב-Cloud SQL. אפשר גם לבצע יתירות כשל שמבוססת על ייצוא/ייבוא או גיבוי/שחזור, אבל הגישה הזו נמשכת זמן רב יותר, במיוחד במסדי נתונים גדולים.
התרחישים העסקיים הבאים הם דוגמאות שמצדיקות הגדרה של יתירות כשל בין אזורים:
- הסכם רמת השירות של האפליקציה העסקית גדול יותר מהסכם רמת השירות האזורי של Cloud SQL (זמינות של 99.99% בהתאם למהדורת Cloud SQL). כדי לצמצם את ההשפעה של הפסקת השירות, אתם יכולים להעביר את הגיבוי לאזור אחר.
- כל השכבות של האפליקציה העסקית כבר פרוסות במספר אזורים, ויכולות להמשיך לפעול גם אם יש הפסקה זמנית בשירות באחד מהאזורים. הגדרת יתירות כשל בין אזורים עוזרת לתמוך בזמינות המתמשכת של מסד הנתונים.
- היעד הנדרש לזמן ההתאוששות (RTO) והיעד הנדרש להתאוששות מאסון (RPO) נמדדים בדקות ולא בשעות. מעבר לאזור אחר במקרה של כשל מהיר יותר מיצירה מחדש של מסד נתונים.
באופן כללי, יש שתי גרסאות לתהליך ה-DR:
- מסד נתונים עובר למצב של מעבר לגיבוי בעת כשל (failover) באזור משני. אחרי שמסד הנתונים מוכן ומשמש את האפליקציה, הוא הופך למסד הנתונים הראשי החדש ונשאר כזה.
- מסד נתונים עובר למצב של מעבר לגיבוי בעת כשל באזור משני, אבל חוזר לאזור הראשי אחרי שהאזור הראשי מתאושש מהכשל.
בסקירה הכללית הזו של תוכנית התאוששות מאסון (DR) במסד נתונים של Google Cloud SQL מתוארת האפשרות השנייה – כשמסד נתונים שנכשל משוחזר וחוזר לאזור הראשי. הגרסה הזו של תהליך ה-DR רלוונטית במיוחד למסדי נתונים שחייבים לפעול באזור הראשי בגלל זמן אחזור ברשת, או בגלל שחלק מהמשאבים זמינים רק באזור הראשי. בגרסה הזו, מסד הנתונים פועל באזור המשני רק למשך ההפסקה באזור הראשי.
שני מדריכים משויכים למסמך הזה בנושא התאוששות מאסון:- תוכנית התאוששות מאסון (DR) ב-Cloud SQL ל-MySQL: תהליך מלא של מעבר לגיבוי בעת כשל וחזרה למצב תקין
- תוכנית התאוששות מאסון (DR) ב-Cloud SQL ל-PostgreSQL: תהליך מלא של מעבר לגיבוי בעת כשל וחזרה למצב תקין
ארכיטקטורה של תוכנית התאוששות מאסון (DR)
בתרשים הבא מוצגת הארכיטקטורה המינימלית שתומכת בהתאוששות מאסון של מסד נתונים במכונה של Cloud SQL עם זמינות גבוהה:
הארכיטקטורה פועלת באופן הבא:
- שני מופעים של Cloud SQL (מופע ראשי ומופע במצב המתנה) נמצאים בשני אזורים נפרדים בתוך אזור אחד (האזור הראשי). המכונות מסונכרנות באמצעות דיסקי אחסון מתמיד אזוריים.
- מכונה אחת של Cloud SQL (הרפליקה לקריאה בין אזורים) נמצאת באזור השני (האזור המשני). לצורך DR, הרפליקה לקריאה בלבד באזור אחר מוגדרת לסנכרון (באמצעות רפליקציה אסינכרונית) עם המכונה הראשית באמצעות הגדרת רפליקה לקריאה בלבד.
המכונה הראשית והמכונה במצב המתנה חולקות את אותו דיסק אזורי, כך שהמצבים שלהן זהים.
מכיוון שההגדרה הזו משתמשת ברפליקציה אסינכרונית, יכול להיות שהרפליקה לקריאה בלבד בין אזורים תפגר אחרי המכונה הראשית. כתוצאה מכך, כשמתרחש יתירות כשל, סביר להניח שה-RPO של הרפליקה לקריאה חוצת-אזורים הוא לא אפס.
תהליך של תוכנית התאוששות מאסון (DR)
תהליך ההתאוששות מאסון (DR) מתחיל כשהאזור הראשי לא זמין. כדי להמשיך את העיבוד באזור משני, מפעילים יתירות כשל של המכונה הראשית על ידי קידום של רפליקה לקריאה בלבד באזור אחר. תהליך ה-DR קובע את השלבים התפעוליים שצריך לבצע, באופן ידני או אוטומטי, כדי לצמצם את הכשל באזור ולהגדיר מכונה ראשית שפועלת באזור משני.
בתרשים הבא מוצג תהליך ה-DR:
תהליך ה-DR כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל המכונה הראשית, לא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש מעבר לגיבוי בעת כשל, תוכלו לקדם את הרפליקה לקריאה חוצת-אזורים באזור המשני (R2) למכונה הראשית החדשה.
- החיבורים של הלקוחות מוגדרים מחדש כדי להמשיך את העיבוד במכונה הראשית החדשה ולגשת למכונה הראשית ב-R2.
התהליך הראשוני הזה יוצר שוב מסד נתונים ראשי פעיל. עם זאת, היא לא יוצרת ארכיטקטורת DR מלאה, שבה למכונה הראשית החדשה עצמה יש מכונה במצב המתנה ורפליקה לקריאה באזורים שונים.
תהליך DR מלא מבטיח שהמופע היחיד, הראשי החדש, מופעל לזמינות גבוהה ויש לו רפליקה לקריאה חוצת-אזורים. תהליך DR מלא כולל גם חזרה לפריסה המקורית באזור הראשי המקורי.
מעבר לאזור משני במקרה של כשל
תהליך DR מלא מרחיב את תהליך ה-DR הבסיסי על ידי הוספת שלבים ליצירת ארכיטקטורת DR מלאה אחרי יתירות כשל. התרשים הבא מציג ארכיטקטורת DR מלאה של מסד נתונים אחרי יתירות כשל:
תהליך ה-DR המלא של מסד הנתונים כולל את השלבים הבאים:
- האזור הראשי (R1), שבו פועל מסד הנתונים הראשי, לא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש מעבר ליתירות כשל, תוכלו להעלות בדרגה את הרפליקה לקריאה חוצת-אזורים באזור המשני (R2) כדי שתהיה המכונה הראשית החדשה.
- חיבורי הלקוחות מוגדרים מחדש כדי לגשת למכונה הראשית החדשה (R2) ולעבד בה.
- מכונה חדשה במצב המתנה נוצרת ומופעלת ב-R2, ונוספת למכונה הראשית. המכונה במצב המתנה נמצאת באזור שונה מהמכונה הראשית. המכונה הראשית זמינה עכשיו עם זמינות גבוהה כי נוצרה בשבילה מכונה במצב המתנה.
- באזור שלישי (R3), נוצרת רפליקה חדשה לקריאה בין אזורים, שמצורפת למכונה הראשית. בשלב הזה, ארכיטקטורה מלאה של תוכנית התאוששות מאסון נוצרת מחדש ומופעלת.
אם האזור הראשי המקורי (R1) יהיה זמין לפני שמיישמים את שלב 6, אפשר להציב את הרפליקה לקריאה באזור R1 במקום באזור R3 באופן מיידי. במקרה כזה, החזרה לאזור הראשי המקורי (R1) פחות מורכבת ודורשת פחות שלבים.
מניעת מצב של פיצול מוח (split-brain)
אם האזור הראשי (R1) נכשל, זה לא אומר שהמכונה הראשית המקורית והמכונה במצב המתנה שלה מושבתות, מוסרות או הופכות ללא נגישות באופן אוטומטי כש-R1 הופך לזמין שוב. אם R1 יהפוך לזמין, יכול להיות שהלקוחות יקראו ויכתבו נתונים (אפילו בטעות) במכונה הראשית המקורית. במקרה כזה, יכול להיווצר מצב של פיצול מוח, שבו לקוחות מסוימים ניגשים לנתונים ישנים במסד הנתונים הראשי הישן, ולקוחות אחרים ניגשים לנתונים חדשים במסד הנתונים הראשי החדש, מה שמוביל לבעיות בעסק.
כדי למנוע מצב של פיצול, צריך לוודא שהלקוחות לא יכולים יותר לגשת למכונה הראשית המקורית אחרי ש-R1 הופך לזמין. באופן אידיאלי, כדאי להפוך את המכונה הראשית המקורית ללא נגישה לפני שהלקוחות מתחילים להשתמש במכונה הראשית החדשה, ואז למחוק את המכונה הראשית המקורית מיד אחרי שהיא הופכת ללא נגישה.
הגדרת גיבוי ראשוני אחרי יתירות כשל
כשמקַדמים את העותק לקריאה בלבד באזור אחר כדי שיהיה המכונה הראשית החדשה במקרה של יתירות כשל, יכול להיות שהעסקאות במכונה הראשית החדשה לא יהיו מסונכרנות באופן מלא עם העסקאות מהמכונה הראשית המקורית. לכן, הטרנזקציות האלה לא זמינות במכונה החדשה.
מומלץ לגבות מיד את המכונה הראשית החדשה בתחילת תהליך המעבר לגיבוי במקרה של כשל, ולפני שהלקוחות ניגשים למסד הנתונים. הגיבוי הזה מייצג מצב עקבי וידוע בנקודת יתירות הכשל. גיבויים כאלה יכולים להיות חשובים למטרות רגולטוריות או לשחזור למצב ידוע אם הלקוחות נתקלים בבעיות בגישה למכונה הראשית החדשה.
חזרה לאזור הראשי המקורי
כפי שצוין קודם, במסמך הזה מפורטים השלבים לחזרה לאזור המקורי (R1). יש שתי גרסאות שונות לתהליך החלופי.
- אם יצרתם את הרפליקה החדשה לקריאה חוצת-אזורים באזור שלישי (R3), אתם צריכים ליצור עוד רפליקה לקריאה חוצת-אזורים (שנייה) באזור הראשי (R1).
- אם יצרתם את הרפליקה החדשה לקריאה חוצת-אזורים באזור הראשי (R1), אתם לא צריכים ליצור עוד רפליקה לקריאה חוצת-אזורים ב-R1.
אחרי שנוצרת רפליקה לקריאה באזור R1, מכונה של Cloud SQL יכולה לחזור ל-R1. מכיוון שהמעבר למצב החלופי מופעל באופן ידני ולא מבוסס על הפסקה, אתם יכולים לבחור יום ושעה מתאימים לפעילות התחזוקה הזו.
לכן, כדי להשיג DR מלאה עם רפליקה לקריאה ראשית, בהמתנה ובין אזורים, צריך שתי יתירות כשל. המעבר הראשון ליתירות כשל מופעל על ידי ההפסקה (יתירות כשל אמיתית), והמעבר השני ליתירות כשל יוצר מחדש את הפריסה הראשונית (חלופה).
כדי לחזור לאזור הראשי המקורי (R1), מבצעים את השלבים הבאים:
- מקַדמים את הרפליקה החדשה שנוצרה באזור הראשי המקורי (R1).
- אם המכונה שקודמה לא נוצרה במקור כרפליקת HA, צריך להפעיל HA במכונה כדי להגן עליה מפני כשלים אזוריים.
- מגדירים מחדש את האפליקציות כך שיתחברו למכונה הראשית החדשה.
- יוצרים רפליקה חוצת-אזורים למכונה הראשית החדשה באזור ה-DR (R2).
- (אופציונלי) כדי להימנע מהפעלה של כמה מכונות ראשיות עצמאיות, מנקים את המכונה הראשית באזור ה-DR (R2).
תוכנית התאוששות מאסון (DR) מתקדמת
אם אתם משתמשים במהדורת Cloud SQL Enterprise Plus, אתם יכולים להשתמש ב-DR מתקדם. DR מתקדם מפשט את השחזור ואת החזרה למצב הקודם אחרי מעבר לגיבוי בעת כשל בין אזורים. כמו שמתואר בתהליך של תוכנית התאוששות מאסון (DR), כשמפעילים את תוכנית ה-DR, מסירים את החיבור בין האזור שנכשל במכונה הראשית הישנה לבין האזור התפעולי במכונה הראשית החדשה. עם DR, כדי לשחזר את החיבורים לאזור הפריסה המקורי ולהחזיר את המכונה הראשית הישנה, עליך לבצע סדרה של שלבי חזרה ידניים.
ב-DR מתקדם, אם יש כשל באזור, אתם יכולים להפעיל יתירות כשל של רפליקה. במעבר ליתירות כשל של רפליקה, אתם מעלים בדרגה רפליקה לקריאה בלבד באזורים שונים, בדומה לביצוע של DR רגיל, אבל אתם מעלים בדרגה את הרפליקה הייעודית להתאוששות מאסון (DR). הקידום של הרפליקה של DR הוא מיידי.
במקום להסיר את המכונה הראשית הישנה, המכונה נשארת חלק מהטופולוגיה של הרפליקציה האסינכרונית של Cloud SQL. המופע הראשי הישן (מופע א') הופך בסופו של דבר לרפליקה של רפליקת ה-DR שלו (מופע ב'), אחרי שרפליקת ה-DR קודמה למופע הראשי החדש.
אחרי שהמכונה הראשית הישנה (A) הופכת לרפליקה, אפשר לבצע את השלב האחרון של התאוששות מתקדמת מאסון (DR). אפשר להחזיר את פריסת Cloud SQL למצב המקורי שלה ולשחזר את המכונה הראשית הישנה (A) לתפקיד הקודם שלה כמכונה הראשית, בלי לאבד נתונים. כדי לבצע את השחזור הזה של המכונה הראשית הישנה (A) ללא אובדן נתונים, אתם יכולים להשתמש בפעולת המעבר. כשמבצעים העברה, לא מאבדים נתונים כי המכונה הראשית (B) נשארת במצב קריאה בלבד עד שהרפליקה הייעודית להתאוששות מאסון (A) מתעדכנת בהתאם למכונה הראשית (B). אחרי שהרפליקה להתאוששות מאסון (A) מקבלת את כל עדכוני הרפליקציה, היא מקבלת את התפקיד של המכונה הראשית, והמכונה הראשית הקודמת (B) מוגדרת מחדש באופן אוטומטי כרפליקה להתאוששות מאסון של המכונה הראשית הנוכחית (A). המכונות חוזרות לתפקידים המקוריים שלהן, וכך הטופולוגיה חוזרת למצב המקורי שלה לפני DR ויתירות כשל של הרפליקה.
במהלך התאוששות מתקדמת מאסון, כל המכונות שמעורבות בפעולות של יתירות כשל והחלפה של רפליקות שומרות על כתובות ה-IP שלהן.
אתם יכולים גם להשתמש בפעולת המעבר של התאוששות מתקדמת מאסון כדי לבצע תרגילי DR שגרתיים, לבדוק ולהכין את הטופולוגיה של Cloud SQL ליתירות כשל חוצת-אזורים לפני שמתרחש אסון. אם מתרחש אסון בפועל, תוכלו לבצע את יתירות הכשל של הרפליקה חוצת האזורים שכבר בדקתם.
רפליקה של תוכנית התאוששות מאסון (DR)
כחלק מהדרישות של התאוששות מתקדמת מאסון, לרפליקה של ה-DR יש את המאפיינים הבאים:
- רפליקת DR היא רפליקה לקריאה בלבד שמקושרת ישירות בין אזורים.
- אפשר לשנות את הייעוד של הרפליקה להתאוששות מאסון כמה פעמים.
- אפשר לשנות את הייעוד של הרפליקה להתאוששות מאסון בכל שלב, חוץ מבזמן פעולת מעבר או יתירות כשל של הרפליקה.
בנוסף, כדי לצמצם את ה-RTO אחרי שימוש ב-DR מתקדם, מומלץ:
- מגדירים את הרפליקה של ה-DR באותו גודל כמו המכונה הראשית.
- אם במכונה הראשית מופעלת זמינות גבוהה, מומלץ להפעיל זמינות גבוהה גם ברפליקה להתאוששות מאסון. כדי לעשות את זה, קודם צריך לוודא שהזמינות הגבוהה מופעלת במכונה הראשית. לאחר מכן, מבצעים את המעבר לרפליקה של ה-DR. אחרי שהמעבר מסתיים, מפעילים את הזמינות הגבוהה במכונה הראשית החדשה. אחר כך אפשר לחזור למכונה הראשית הישנה. הרפליקה של ה-DR שומרת על הגדרת הזמינות הגבוהה שלה גם אחרי שהיא הופכת שוב לרפליקה.
יתירות כשל של רפליקה
לסיכום, מעבר לגיבוי בעת כשל של רפליקה מורכב מהאירועים הבאים:
- אתם יוצרים ומקצים רפליקה של DR.
- האזור הראשי לא זמין.
- אתם מבצעים את יתירות הכשל של הרפליקה לרפליקה של ה-DR.
- נקודת הקצה לכתיבה מתעדכנת ומתחילה להצביע על המכונה הראשית החדשה.
- כשהמכונה הראשית המקורית חוזרת למצב אונליין, היא הופכת לרפליקה לקריאה בלבד של המכונה הראשית החדשה.
- אתם יכולים להשתמש בפעולת המעבר כדי לשחזר את הפריסה לטופולוגיה המקורית שלה.
כדי לראות את הפרטים והתרשימים של פעולת מעבר לגיבוי בעת כשל של רפליקה, לחצו על הכרטיסיות הבאות.
הקצאת רפליקת DR
לפני שמבצעים מעבר לגיבוי בעת כשל של רפליקה, מקצים רפליקת DR למכונה הראשית, ואולי גם בודקים את התהליך על ידי ביצוע החלפה.
הפסקת חשמל
האזור הראשי, שבו פועל מסד הנתונים הראשי, לא זמין.
יתירות כשל של רפליקה
אחרי שקובעים שנדרשת תוכנית התאוששות מאסון, מבצעים יתירות כשל של רפליקה לרפליקה הייעודית של תוכנית ההתאוששות מאסון באזור אחר.
הרפליקה להתאוששות מאסון שמוגדרת באזור אחר הופכת מיד למכונה הראשית ומתחילה לקבל פעולות קריאה וכתיבה נכנסות. נקודת הקצה לכתיבה מתעדכנת ומתחילה להצביע על המכונה הראשית החדשה.
הראשי המקורי הופך לרפליקה
אחרי שהרפליקה קודמה, Cloud SQL בודק מדי פעם אם המכונה הראשית המקורית חזרה לפעול. אם המכונה הראשית המקורית מחוברת לאינטרנט, Cloud SQL יוצר מחדש את המכונה הראשית הישנה כרפליקה של המכונה שקודמה. המכונה הראשית הישנה שומרת על כתובת ה-IP שלה.
חזרה למקור במקרה של כשל
אחרי שמבצעים מעבר לגיבוי בעת כשל של רפליקה, אפשר לשחזר את המכונה הראשית באזור המקורי על ידי ביצוע פעולת המעבר, תוך היפוך של אותה רפליקה להתאוששות מאסון ושל זוג המכונות הראשיות.
מעבר
לסיכום, פעולת המעבר כוללת את האירועים הבאים:
- אתם יוצרים ומקצים רפליקה של DR.
- אתם מתחילים את המעבר.
- כשההשהיה ברפליקציה מגיעה לאפס, המכונה הראשית החדשה מתחילה לקבל חיבורים נכנסים.
- המופע הראשי הישן הופך לרפליקה לקריאה בלבד.
- אם משתמשים בנקודת קצה לכתיבה ב-DNS, נקודת הקצה לכתיבה ב-DNS מתעדכנת כך שתצביע על המכונה הראשית החדשה.
כדי לראות את הפרטים והתרשימים של פעולת המעבר, לוחצים על הכרטיסיות הבאות.
הקצאת רפליקת DR
לפני שמתחילים את פעולת ה *מעבר*, צריך להקצות רפליקת DR למכונה הראשית.
מוודאים שהמכונה הראשית תקינה. אפשר לבצע מעבר רק כשגם המכונה הראשית וגם הרפליקה להתאוששות מאסון נמצאות במצב אונליין.
התחלת המעבר
אתם מתחילים את המעבר. כשמפעילים את המעבר, המכונה הראשית מפסיקה לקבל פעולות כתיבה והופכת למכונה לקריאה בלבד. Cloud SQL ממתין להעתקה של יומני העסקאות ל-Cloud Storage. הרפליקה הייעודית להתאוששות מאסון מתעדכנת בהתאם למכונה הראשית.
כשהפיגור ברפליקציה יורד לאפס, הרפליקה של ה-DR מקודמת למכונה הראשית החדשה. המכונה הראשית החדשה מתחילה לקבל חיבורים נכנסים, כולל קריאות וכתיבות של אפליקציות.
נקודת הקצה עודכנה
אחרי שהרפליקה של DR מקודמת למכונה הראשית החדשה, נקודת הקצה של הכתיבה ב-DNS מתעדכנת ומתחילה להצביע על המכונה הראשית החדשה. אם אתם לא משתמשים בנקודת קצה לכתיבה ב-DNS, אתם צריכים להגדיר את האפליקציות כך שיפנו לכתובת ה-IP של המכונה הראשית החדשה.
המכונה הראשית הישנה מוגדרת מחדש כרפליקה לקריאה בלבד.
התכונה PITR מופעלת באופן אוטומטי במכונה הראשית החדשה. אפשר לבצע PITR רק אחרי הגיבוי האוטומטי הראשון.
נקודת קצה לכתיבה
נקודת קצה לכתיבה היא שם גלובלי של שירות שמות דומיין (DNS) שמתורגם באופן אוטומטי לכתובת ה-IP של המכונה הראשית הנוכחית. נקודת הקצה הזו מפנה אוטומטית חיבורים נכנסים למכונה הראשית החדשה במקרה של פעולת יתירות כשל או מעבר של רפליקה. אפשר להשתמש בנקודת הקצה לכתיבה במחרוזת חיבור של SQL במקום בכתובת IP. שימוש בנקודת קצה לכתיבה מאפשר לכם להימנע משינויים בחיבור של האפליקציה כשיש הפסקה זמנית בשירות באזור.
כדי להשתמש בנקודת קצה לכתיבה, צריך להפעיל את Cloud DNS API בפרויקט שבו יוצרים או שבו נמצא המכונה הראשית הקיימת של Cloud SQL Enterprise Plus מהדורת Plus. כשיוצרים מכונה של Cloud SQL Enterprise Plus עם כתובת IP פרטית ורשתות מורשות, Cloud SQL יוצר באופן אוטומטי נקודת קצה לכתיבה בשביל המכונה. אם כבר יש לכם מכונה ראשית של Cloud SQL Enterprise Plus, המערכת של Cloud SQL יוצרת את נקודת הקצה לכתיבה כשאתם יוצרים את הרפליקה להתאוששות מאסון (רפליקה חוצת-אזורים שאתם מקצים למכונה הראשית). אם המכונה הראשית משתנה בגלל פעולת מעבר או יתירות כשל של רפליקה, Cloud SQL מקצה את נקודת הקצה לכתיבה לרפליקת ה-DR כשהיא הופכת למכונה הראשית החדשה.
מידע נוסף על שימוש בנקודת קצה לכתיבה כדי להתחבר למכונה זמין במאמר התחברות למכונה באמצעות נקודת קצה לכתיבה.
המאמרים הבאים
- שימוש בתוכנית התאוששות מאסון (DR) מתקדמת.
- כדאי לעיין במדריך בנושא תוכנית התאוששות מאסון (DR) ב-Cloud SQL ל-MySQL.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים, מדריכים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.