תכנון הארכיטקטורה של עומסי העבודה

Last reviewed 2024-07-24 UTC

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

המסמך הזה הוא חלק מסדרה:

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

המאמר הזה יעזור לכם:

  1. הכנת אזור הנחיתה
  2. הכנת עומסי העבודה להעברה בין אזורים
  3. הכנת משאבי המחשוב
  4. הכנת משאבי אחסון הנתונים
  5. הכנה להוצאה משימוש של סביבת המקור

הכנת אזור הנחיתה

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

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

שיקולים לארגונים

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

ניהול זהויות והרשאות גישה

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

  • תכנון הצוותים: בחברות מסוימות יש מבנה שבו צוותים שונים מטפלים במשאבים שונים. כשמעבירים עומס עבודה לאזור אחר, בגלל שינוי במבנה המשאבים, יכול להיות שצוות אחר יהיה המועמד הכי מתאים להיות אחראי על משאבים מסוימים. במקרה כזה, צריך לשנות את ההרשאות בהתאם.
  • מוסכמות מתן שמות: יכול להיות שמוסכמות מתן שמות לא ישפיעו על הפונקציות מבחינה טכנית, אבל צריך לקחת אותן בחשבון אם יש משאבים שמוגדרים עם מוסכמות מתן שמות שמתייחסות לאזור ספציפי. דוגמה אופיינית היא כשכבר יש כמה אזורים משוכפלים, כמו מכונות וירטואליות (VM) של Compute Engine, שהשם שלהן מתחיל באזור, למשל, europe-west1-backend-1. במהלך תהליך ההעברה, כדי למנוע בלבול או, גרוע מכך, שיבוש של צינורות שמתבססים על מוסכמת שמות ספציפית, חשוב לשנות את השמות כך שישקפו את האזור החדש.

קישוריות ורשתות

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

חשוב לזכור שקישוריות מקומית עם Google Cloud היא אחד מהגורמים שצריך להעריך מחדש בתהליך ההעברה, כי היא יכולה להיות מתוכננת באופן ספציפי לאזור מסוים. דוגמה לגורם כזה היא Cloud Interconnect, שמחובר ל- Google Cloud דרך צירוף ל-VLAN לאזורים ספציפיים. כדי למנוע תנועה מאזור לאזור, צריך לשנות את האזור שאליו מצורף ה-VLAN לפני שמבטלים את האזור הזה. גורם נוסף שכדאי לקחת בחשבון הוא שאם אתם משתמשים ב-Partner Interconnect, העברת האזור יכולה לעזור לכם לבחור מיקום פיזי אחר שאליו תוכלו לחבר את קבצים מצורפים של VLAN‏ Google Cloud. השיקול הזה רלוונטי גם אם משתמשים ב-Cloud VPN ומחליטים לשנות את כתובות רשתות המשנה בהעברה: צריך להגדיר מחדש את הנתבים כדי לשקף את הרשת החדשה.

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

מידע נוסף על בניית בסיס ב- Google Cloudזמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.

הכנת עומסי העבודה להעברה בין אזורים

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

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

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

הכנת משאבי המחשוב

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

במסמך הזה אנחנו מתמקדים במוצרי מחשוב Google Cloud הבאים:

Compute Engine

‫Compute Engine הוא השירות של Google Cloudשמספק מכונות וירטואליות ללקוחות.

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

מה אתם יכולים לעשות?

  • בדיקת משאבי מחשוב: אחת המגבלות הראשונות שאתם עלולים להיתקל בהן כשאתם משנים את אזור האירוח של מכונה וירטואלית היא הזמינות של פלטפורמת המעבד באזור היעד החדש. אם צריך לשנות את סדרת המכונות במהלך ההעברה, צריך לוודא שמערכת ההפעלה של המכונה הווירטואלית הנוכחית נתמכת בסדרה. באופן כללי, הבעיה הזו יכולה להתרחש בכל שירות מחשוב (יכול להיות שבאזורים חדשים מסוימים לא יהיו שירותים כמו Cloud Run או Cloud GPU), ולכן לפני שתתכננו את ההעברה, ודאו שכל שירותי המחשוב שאתם צריכים זמינים באזור היעד. Google Cloud
  • הגדרת איזון עומסים ושינוי גודל: ‏ Compute Engine תומך באיזון עומסים של תעבורת נתונים בין מופעי Compute Engine ובשינוי גודל אוטומטי כדי להוסיף או להסיר מכונות וירטואליות מקבוצות של מכונות מנוהלות (MIG), בהתאם לביקוש. מומלץ להגדיר איזון עומסים ושינוי גודל אוטומטי כדי לשפר את המהימנות והגמישות של הסביבות, וכך להימנע מנטל הניהול של פתרונות בניהול עצמי. מידע נוסף על הגדרת איזון עומסים ושינוי גודל ב-Compute Engine זמין במאמר איזון עומסים ושינוי גודל.
  • שימוש בשמות DNS אזוריים: כדי לצמצם את הסיכון להפסקות שירות חוצות-אזורים, מומלץ להשתמש בשמות DNS אזוריים כדי לזהות באופן ייחודי מכונות וירטואליות באמצעות שמות DNS בסביבות שלכם. Google Cloud משתמש בשמות DNS אזוריים למכונות וירטואליות של Compute Engine כברירת מחדל. מידע נוסף על אופן הפעולה של ה-DNS הפנימי של Compute Engine זמין במאמר סקירה כללית על DNS פנימי. כדי להקל על העברה עתידית בין אזורים, וכדי שההגדרה תהיה קלה יותר לתחזוקה, מומלץ להתייחס לשמות ה-DNS האזוריים כפרמטרים של הגדרה שאפשר לשנות בעתיד.
  • שימוש באותה תבנית של קבוצות של מופעי מכונה מנוהלים (MIG): ב-Compute Engine אפשר ליצור קבוצות MIG אזוריות שמקצות באופן אוטומטי מכונות וירטואליות בכמה אזורים באזור מסוים. אם אתם משתמשים בתבנית באזור הישן, אתם יכולים להשתמש באותה תבנית כדי לפרוס את קבוצות ה-MIG באזור החדש.

GKE

‫Google Kubernetes Engine‏ (GKE) עוזר לכם לפרוס עומסי עבודה בקונטיינרים, לנהל אותם ולהתאים אותם לעומס ב-Kubernetes.

כדי להכין את עומסי העבודה ב-GKE להעברה, כדאי לשקול את נקודות התכנון הבאות ואת התכונות של GKE:

  • ‫Cloud Service Mesh: הטמעה מנוהלת של Istio mesh. שימוש ב-Cloud Service Mesh באשכול מאפשר לכם לשלוט טוב יותר בתעבורת הרשת שנכנסת לאשכול. אחת התכונות המרכזיות של Cloud Service Mesh היא האפשרות ליצור רשת שירותים בין שני אשכולות. אתם יכולים להשתמש בתכונה הזו כדי לתכנן את ה-מיגרציה מאזור אחד לאזור אחר. לשם כך, צריך ליצור את אשכול GKE באזור החדש ולהוסיף אותו ל-Service mesh. באמצעות הגישה הזו, אפשר להתחיל לפרוס עומסי עבודה באשכול החדש ולהפנות אליהם תנועה בהדרגה. כך אפשר לבדוק את הפריסה החדשה וגם לשחזר את הפריסה הקודמת על ידי עריכת ניתוב הרשת.
  • ‫סנכרון תצורות: שירות GitOps שמבוסס על ליבה בקוד פתוח, שמאפשר למפעילים של אשכולות ולאדמינים של פלטפורמות לפרוס הגדרות ממקור יחיד. ‫סנכרון תצורות יכול לתמוך באשכול אחד או בכמה אשכולות, וכך מאפשר לכם להשתמש במקור אמת יחיד כדי להגדיר את האשכולות. אתם יכולים להשתמש בפונקציה הזו של סנכרון תצורות כדי לשכפל את ההגדרה של האשכול הקיים באשכול עבור האזור החדש, ואולי להתאים אישית משאב ספציפי לאזור.
  • גיבוי ל-GKE: התכונה הזו מאפשרת לגבות את הנתונים הקבועים של האשכול באופן תקופתי ולשחזר את הנתונים לאותו אשכול או לאשכול חדש.

Cloud Run

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

VMware Engine

‫Google Cloud VMware Engine הוא שירות מנוהל מלא שמאפשר להפעיל את פלטפורמת VMware ב- Google Cloud. סביבת VMware פועלת באופן מקורי בתשתיתGoogle Cloud bare metal במיקומים Google Cloud שונים, כולל vSphere, ‏ vCenter, ‏ vSAN, ‏ NSX-T, ‏ HCX וכלים תואמים.

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

בנוסף, כשמתכננים את המעבר, כדאי לקחת בחשבון את ה-DNS ואת איזון העומסים בסביבות Compute Engine. ‫VMware Engine משתמש ב-Google Cloud DNS, שהוא שירות מנוהל לאירוח DNS שמספק אירוח DNS סמכותי שמתפרסם באינטרנט הציבורי, אזורים פרטיים שגלויים לרשתות VPC, והעברת DNS וקישור בין רשתות שכנות (peering) לניהול של המרת שמות ברשתות VPC. תוכנית ההעברה יכולה לתמוך בבדיקה של איזון עומסים במספר אזורים ושל תצורות DNS.

הכנת משאבי אחסון הנתונים

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

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

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

במסמך הזה מתוארים השירותים המנוהלים הבאים:

במסמך הזה אנחנו מניחים שפתרונות האחסון שבהם אתם משתמשים הם מופעים אזוריים שממוקמים יחד עם משאבי מחשוב.

Cloud Storage

‫Cloud Storage מציע את Storage Transfer Service, שמאפשר להעביר קבצים ממערכות שונות ל-Cloud Storage באופן אוטומטי. אפשר להשתמש בו כדי לשכפל נתונים לאזור אחר לצורך גיבוי, וגם להעברה מאזור לאזור.

Cloud SQL

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

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

Filestore

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

Bigtable

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

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

האפשרות האחרונה היא ייצוא טבלאות, למשל ב-Cloud Storage. הייצוא הזה יאחסן את הנתונים בשירות אחר, והנתונים יהיו זמינים לייבוא למופע באזור.

Firestore

יכול להיות שהמיקומים של Firestore קשורים לנוכחות של App Engine בפרויקט שלכם, ובתרחישים מסוימים זה מחייב את מופע Firestore להיות מרובה אזורים. בתרחישי מיגרציה כאלה, צריך גם לקחת בחשבון את App Engine כדי לתכנן את הפתרון הנכון ל-Firestore. למעשה, אם כבר יש לכם אפליקציית App Engine עם מיקום של us-central או europe-west, מסד הנתונים שלכם ב-Firestore נחשב למסד נתונים רב-אזורי.

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

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

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

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

  • בדיקות בסביבה חדשה: לפני שמעבירים את התנועה מהסביבה הישנה לסביבה החדשה, אפשר לבצע בדיקות כדי לוודא שהאפליקציות פועלות בצורה תקינה. בנוסף לבדיקות היחידה הקלאסיות ולבדיקות השילוב שאפשר לבצע באפליקציות שעברו מיגרציה לאחרונה, יש אסטרטגיות שונות לבדיקה. אפשר להתייחס לסביבה החדשה כאל גרסה חדשה של התוכנה, וליישם את העברת התנועה באמצעות תבניות נפוצות כמו בדיקות A/B שמשמשות לאימות. גישה נוספת היא לשכפל את התנועה הנכנסת בסביבת המקור ובסביבה החדשה כדי לבדוק שהפונקציות נשמרות.
  • תכנון זמן השבתה: אם בוחרים באסטרטגיית מיגרציה כמו blue-green, שבה מעבירים את התנועה מסביבה אחת לסביבה אחרת, כדאי לשקול להשתמש בזמן השבתה מתוכנן. זמן ההשבתה מאפשר מעקב טוב יותר אחרי המעבר ומניעת שגיאות בלתי צפויות בצד הלקוח.
  • חזרה לגרסה קודמת: בהתאם לאסטרטגיות שנקבעו להעברת התנועה, יכול להיות שיהיה צורך לחזור לגרסה קודמת במקרה של שגיאות או הגדרה שגויה של הסביבה החדשה. כדי שתוכלו לבטל את השינויים בסביבה, צריכה להיות לכם תשתית מעקב שתאפשר לכם לזהות את הסטטוס של הסביבה החדשה.

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

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

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

שותפים ביצירת התוכן

Author: Valerio Ponza | Technical Solution Consultant

תורמי תוכן אחרים: