העברת מכונה

בדף הזה מוסבר איך להעביר מכון ב-Spanner.

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

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

למה כדאי להעביר את המכונה של Spanner?

היתרונות של העברת המכונה כוללים:

• זמינות גבוהה יותר: זמינות של 99.999% ללא זמן השבתה אחרי העברה מאזור אחד לשני אזורים או למספר אזורים.
• צמצום זמן האחזור: צמצום זמן האחזור והגדלת הכיסוי הגיאוגרפי באמצעות רפליקות נוספות לקריאה בלבד, על ידי העברה מאזור לשני אזורים או למספר אזורים, או ממספר אזורים למספר אזורים.
• הפחתת עלויות: הפחתת העלויות השעתיות על ידי מעבר מהגדרה של שני אזורים או של מספר אזורים להגדרה של אזור אחד.
• מיקום משותף של מסד הנתונים: מיקום משותף של מסד הנתונים ב-Spanner עם אפליקציית הלקוח, על ידי העברת המכונה למיקום אופטימלי יותר.

תמחור

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

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

מגבלות

• כדי להעביר את המכונה, צריך להיות בה לפחות צומת אחד (1,000 יחידות עיבוד).
• אי אפשר להעביר את המכונה בין פרויקטים או חשבונות Google Cloud .
• אי אפשר להעביר מכונה שמשתמשת במהדורת Standard ישירות ממערך של מכונה אזורית למערך של מכונה בשני אזורים או במספר אזורים. קודם צריך לשדרג את המהדורה של המכונה למהדורת Enterprise Plus, ורק אז להעביר את המכונה.
• אם יש לכם בקשות פעילות שמשתמשות בנקודת קצה של שירות אזורי באחד ממשאבי המכונה, העברת המכונה משפיעה על כל הבקשות שמשתמשות בנקודת הקצה האזורית, כי האכיפה האזורית חוסמת את הגישה למכונות באזורים שונים. בקשות שמשתמשות בנקודת קצה גלובלית לא מושפעות.
• הגיבויים ולוחות הזמנים לגיבוי של Spanner הם ספציפיים להגדרת המכונה, ולא נכללים כשמעבירים מכונה. לפני שמתחילים בהעברה, צריך למחוק את כל הגיבויים הקיימים ואת כל תזמוני הגיבויים במכונה. מידע נוסף זמין במאמר גיבויים ותזמוני גיבויים.
• ממשקי ה-API הבאים מושבתים במהלך העברת מכונה:
  • InstanceAdmin.DeleteInstance
  • InstanceAdmin.UpdateInstance
  • InstanceAdmin.CreateInstancePartition
  • InstanceAdmin.UpdateInstancePartition
  • InstanceAdmin.DeleteInstancePartition
  • DatabaseAdmin.CreateDatabase
  • ‫DatabaseAdmin.UpdateDatabaseDdl (מושבת אם default_leader צוין בבקשה).
  • DatabaseAdmin.RestoreDatabase
  • DatabaseAdmin.CreateBackup
  • DatabaseAdmin.CreateBackupSchedule
  • DatabaseAdmin.CopyBackup
• אם למסד נתונים יש מנהיג ברירת מחדל ששונה, הבחירה נשמרת אם היא מציינת אזור קריאה-כתיבה בהגדרת המכונה של היעד, וההגדרה הזו היא במספר אזורים. אם הגדרת היעד היא אזורית, או שהיא לא כוללת את האזור בעל השם לקריאה ולכתיבה, בחירת ברירת המחדל של ה-leader נמחקת.
• העברת מכונה משנה את מאפיין ההגדרה של המכונה. אם אתם מנהלים את המשאבים של Spanner באמצעות אוטומציה, חשוב שתתכוננו ותטפלו בכל חוסר עקביות שעלול להיווצר.
  • לדוגמה, אם אתם משתמשים ב-Terraform כדי לנהל את המכונות ומסדי הנתונים של Spanner, ומפעילים את terraform apply --auto-approve כדי לשמור על סנכרון המשאבים, כל המכונות והמשאבים הצאצאים נמחקים כשאנחנו מעבירים את המכונה. כדי למנוע מחיקה ואובדן נתונים, צריך לעדכן את ההגדרות בהתאם. למידע נוסף על הפקודה apply, קראו את המאמר Terraform Apply Options.
• בזמן העברת המכונה, יכול להיות שבתרשימים ובמדדי המעקב של Spanner יוצגו נתונים גם במכונה במקור וגם במכונה ביעד, או שהם ישקפו רק את הביצועים במכונה אחת.
• אם הגדרתם את הכלי Autoscaler בקוד פתוח, אתם לא צריכים להשבית אותו. הפעולה נכשלת כי ההגדרה InstanceAdmin.UpdateInstance (שמשמשת לשינויים בצומת וביחידת העיבוד) מושבתת.
• אי אפשר להעביר מכונה אם התכונה Spanner managed autoscaler מופעלת בה. לפני שמעבירים את המכונה, צריך להעביר אותה מניהול התאמה לעומס (autoscaling) להקצאה ידנית עם מספיק צמתים או יחידות עיבוד כדי לתמוך בשיא השימוש ב-CPU (לדוגמה, על ידי הפעלת gcloud spanner instances update INSTANCE_ID --nodes=PEAK_NODES). אחרי שההעברה מסתיימת, אפשר להפעיל מחדש את מידרוג אוטומטי.
• אי אפשר להעביר מכונה של Spanner לתקופת ניסיון בחינם. אפשר להעביר את המכונה אחרי שדרוג למכונה בתשלום.
• אם במכונה נעשה שימוש בחלוקה למחיצות במיקומים שונים, העברת המכונה תעביר רק את מחיצת ברירת המחדל של המכונה, ולא מחיצות נוספות של המכונה.

שיקולי ביצועים

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

לדוגמה, כדי שההעברה תסתיים תוך 24 שעות, המכונה צריכה לעמוד בדרישות הבאות לפני ההעברה ובמהלכה:

• ניצול מעבד (CPU) בעדיפות גבוהה: פחות מ-40% בהגדרות של מכונת המקור. מידע נוסף זמין במאמר ניצול המעבד (CPU).
• אחסון לכל צומת: פחות מ-Tebibyte‏ (TiB) אחד לכל צומת.

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

גיבויים ותזמוני גיבויים

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

אם יש גיבויים בהגדרות המקוריות של המכונה שאתם צריכים לשמור, מומלץ להעתיק את הגיבויים לשתי מכונות זמניות קטנות (100 PU),‏ placeholder-source ו-placeholder-dest:

• ‫placeholder-source: מכונה עם אותה הגדרת מכונה כמו ההגדרה המקורית של המכונה שמועברת. כך תוכלו לשחזר את הגיבויים להגדרות המקוריות אם תצטרכו לבטל את ההעברה.

• ‫placeholder-dest: מכונה עם אותה הגדרת מכונה כמו הגדרת מכונת היעד. כך יהיה לכם גיבוי זמין בתצורה החדשה מיד אחרי שההעברה תסתיים.

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

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

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

איך מעבירים מכונה

אפשר להעביר מכונה באמצעות מסוף Google Cloud או ה-CLI של gcloud. כדי להכין, להפעיל, לעקוב ולסיים את העברת המכונה, צריך לבצע את ארבעת השלבים הבאים:

• שלב 1: הכנת המכונה להעברה
• שלב 2: התחלת העברת המכונה
• שלב 3: מעקב אחרי העברת המכונה
• שלב 4: השלמת המשימות שאחרי המעבר

שלב 1: הכנת המכונה למעבר

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

1. בדיקת ההרשאות, המהדורה והמכסה ביעד:

   • מוודאים שלמפעיל שמבצע את ההעברה יש את הרשאת ה-IAM spanner.instances.update במכונה שמועברת.
   • מוודאים שבפרויקט יש מספיק מכסת צמתים בהגדרת המכונה ביעד כדי לתמוך בקיבולת שיא. מידע נוסף זמין במאמר מכסות ומגבלות של Spanner.
   • אם אתם מעבירים מכונה במהדורת Standard מהגדרה אזורית להגדרה של שני אזורים או של כמה אזורים, קודם צריך לשדרג את המהדורה למהדורת Enterprise Plus.

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

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

3. מעבר מהתאמה אוטומטית מנוהלת להקצאה ידנית ולגודל ידני לצורך ההעברה:

   • כדי שההעברה תסתיים תוך 24 שעות וכדי לצמצם את ההשפעה של זמן האחזור, הקצו מספיק קיבולת מחשוב כך ששיא ניצול המעבד (CPU) בעדיפות גבוהה יהיה פחות מ-40% והאחסון לכל צומת יהיה פחות מ-1TiB במהלך ההעברה. בודקים את התרשימים CPU utilization ו-Total storage ב-System insights כדי לקבוע את מספר הצמתים שנדרשים לעומס העבודה בשיא. מכיוון ש-Spanner משתמש ב-CPU פנוי כדי להעביר נתונים, הגדלת קיבולת המחשוב מגבירה את מהירות ההעברה של המכונה. כדי לוודא מהי קיבולת המחשוב האידיאלית לעומס העבודה, אפשר לבדוק את המעבר בסביבת טרום-ייצור או בסביבת Staging.

   • אם המידרוג האוטומטי המנוהל מופעל במכונה, צריך להעביר את המכונה להקצאה ידנית לפני שמתחילים בהעברה, באמצעות מספר הצמתים שקבעתם שנדרשים כדי לשמור על שימוש ב-CPU בעדיפות גבוהה מתחת ל-40%:

     gcloud spanner instances update INSTANCE_ID \
       --nodes=PEAK_NODES
     

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

   • יוצרים את המכונות הזמניות placeholder-source ו-placeholder-dest שמוזכרות בקטע גיבויים ותזמוני גיבויים, ומעתיקים אליהן את הגיבויים הקריטיים באמצעות הפקודה gcloud spanner backups copy:

     gcloud spanner backups copy \
       --source-instance=INSTANCE_ID \
       --source-backup=SOURCE_BACKUP_ID \
       --destination-instance=PLACEHOLDER_INSTANCE_ID \
       --destination-backup=DESTINATION_BACKUP_ID \
       --expiration-date=EXPIRATION_DATE
     

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

     gcloud spanner operations list \
       --instance=PLACEHOLDER_INSTANCE_ID \
       --type=BACKUP
     

   • מוחקים את כל הגיבויים הקיימים ומוחקים את כל לוחות הזמנים של הגיבויים בכל מסד נתונים במכונה שמעבירים:

     gcloud spanner backups delete BACKUP_ID \
       --instance=INSTANCE_ID
     

     gcloud spanner backup-schedules delete SCHEDULE_ID \
       --instance=INSTANCE_ID \
       --database=DATABASE_ID
     

5. ייצוא תגים של Data Catalog, השהיית האוטומציה והקפאת שינויים בסכימה ובמכונה:

   • כשמעבירים מכונה, נמחקים כל התגים של המכונה שיצרתם ב-Data Catalog. כדאי לייצא את התגים לפני המעבר כדי שתוכלו לייבא אותם אחריו. מידע נוסף זמין במאמר ייצוא וייבוא של תגים.
   • בודקים את תהליכי העבודה של CI/CD, את המשימות המתוזמנות או את מאגרי GitOps של צינורות עיבוד נתונים אוטומטיים של תשתית (כמו הפעלות מתוזמנות של terraform apply --auto-approve) שמנהלים את המשאבים של Spanner, ומשהים אותם כדי שלא יתנגשו עם ההעברה שמתבצעת.
   • מודיעים לארגון שצריך להשהות את השינויים במכונה ובסכימה (כולל עדכונים של מספר הצמתים, עדכוני DDL, יצירה או מחיקה של מסדי נתונים ופעולות גיבוי) עד שההעברה תסתיים.

6. מסדי נתונים עם CMEK בלבד: אימות אזורי היעד ומפתחות Cloud Key Management Service (Cloud KMS):

   • בודקים את ההגדרות של מכונת היעד כדי לזהות את כל האזורים שמרכיבים אותה, כולל אזורי קריאה וכתיבה, אזורי קריאה בלבד ואזורי עדים:

     gcloud spanner instance-configs describe TARGET_CONFIG
     

   • ודאו שהקציתם מפתחות Cloud KMS בכל אזור שמרכיב את הגדרת היעד, ושהענקתם לסוכן השירות של Spanner את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter בניהול הזהויות והרשאות הגישה (IAM) בכל מפתח יעד.

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

שלב 2: התחלת ההעברה של המכונה

מסוף Google Cloud

הערה: אי אפשר להעביר מכונות שמכילות מסדי נתונים שמופעל בהם CMEK באמצעות מסוף Google Cloud . מעבירים את המכונה באמצעות ה-CLI של gcloud.

1. נכנסים לדף Instances במסוף Google Cloud .

   מכונות

2. בוחרים את המופע שרוצים להעביר.

3. בדף הסקירה הכללית של המכונה, לצד Configuration, לוחצים על Move instance to a new configuration.

4. בחלונית Move database to new configuration, בוחרים את הגדרת המכונה החדשה למכונה שלכם.

5. לוחצים על Save.

‫CLI של gcloud

משתמשים בפקודה gcloud spanner instances move כדי להעביר את המכונה.

gcloud spanner instances move INSTANCE_ID \
--target-config=TARGET_CONFIG

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

• ‫INSTANCE_ID: המזהה הקבוע של המכונה שרוצים להעביר.
• ‫TARGET_CONFIG: מזהה קבוע של הגדרת המכונה שאליה רוצים להעביר את המכונה. המיקום הגיאוגרפי החדש של המכונה. זו יכולה להיות הגדרת מכונה אזורית, בשני אזורים או במספר אזורים (לדוגמה, nam3,‏ regional-us-central1 או custom-nam3-us-west2).

לדוגמה, כדי להעביר את המכונה test-instance מהמערך הנוכחי של הגדרות המכונה אל nam3, מריצים את הפקודה הבאה:

  gcloud spanner instances move test-instance --target-config=nam3

אופציונלי: אם רוצים להוסיף רפליקה לקריאה בלבד באזור us-west2 להגדרת המכונה הבסיסית באזור nam3, מבצעים את הפעולות הבאות:

1. משכפלים את הגדרת הבסיס ומוסיפים את הרפליקה לקריאה בלבד להגדרת המכונה החדשה בהתאמה אישית custom-nam3-us-west2:

   gcloud spanner instance-configs create custom-nam3-us-west2 \
   --clone-config=nam3 --add-replicas=location=us-west2, type=READ_ONLY
   

2. מעבירים את המכונה test-instance מההגדרות הנוכחיות שלה להגדרות החדשות של המכונה custom-nam3-us-west2:

   gcloud spanner instances move test-instance --target-config=custom-nam3-us-west2
   

אופציונלי: העברת מכונה עם מסדי נתונים שמופעל בהם CMEK

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

• אם יש לכם כמה מסדי נתונים עם CMEK במכונה שאתם רוצים להעביר, אתם צריכים לציין את --target-database-move-configs לכל אחד מהם. אפשר להשתמש באותם מפתחות לכל מסד נתונים, אבל צריך לציין את המפתחות לכל מסד נתונים שמופעל בו CMEK.
• המפתחות צריכים לכסות את כל האזורים בהגדרת המכונה של היעד, ולסוכן השירות של Spanner צריך להיות תפקיד ה-IAM‏ roles/cloudkms.cryptoKeyEncrypterDecrypter בכל מפתח יעד. לדוגמה, אם הגדרת המכונה של היעד נמצאת ב-nam3, צריך להגדיר מפתחות ב-us-east4, ב-us-east1 וב-us-central1.
• אי אפשר להגדיר מפתחות Cloud KMS למסדי נתונים שלא מופעל בהם CMEK בזמן העברת המכונה.
• בזמן העברת המכונה, אל תשביתו, תשמידו, תחליפו או תבטלו את הרשאות ה-IAM במפתחות ה-CMEK בהגדרות של מכונת המקור או מכונת היעד. הפעולה הזו תעכב את ההעברה ועלולה לנעול את הגישה למסד הנתונים.

כדי להעביר מכונה עם מסדי נתונים שמופעל בהם CMEK, משתמשים בפקודה gcloud spanner instances move. אתם צריכים לכלול בפקודה את הדגל --target-database-move-configs ואת ערכי המפתחות של Cloud KMS, או להגדיר קובץ JSON או YAML עם המפתחות הנדרשים של Cloud KMS:

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=^:^database-id=DATABASE_ID_1:kms-key-names=KMS_KEY_1[, KMS_KEY_2 ... ] \
  [--target-database-move-configs=^:^database-id=DATABASE_ID_2:kms-key-names=KMS_KEY_1 ... ]

או

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=CONFIG_FILE_PATH

מגדירים את הקובץ CONFIG_FILE_PATH עם מזהי מסד הנתונים ומפתחות Cloud KMS. בדוגמה הבאה של קובץ תצורה, יש מפתחות Cloud KMS לשני מסדי נתונים, database-1 ו-database-2, עם אותם מפתחות ב-us-east4, ב-us-east1 וב-us-central1 כדי לכסות את כל האזורים ב-nam3:

[
  {
    "database-id": "database-1",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  },
  {
    "database-id": "database-2",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  }
]

שלב 3: מעקב אחרי העברת המכונה

אתם יכולים להשתמש ב-gcloud spanner operations describe ובלוח בקרה בהתאמה אישית של Cloud Monitoring כדי לעקוב אחרי ההתקדמות של העברה או ביטול של מכונה.

איך בודקים את ההתקדמות של פעולות ההעברה והביטול

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

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

   gcloud spanner operations list --instance="INSTANCE_ID"
   

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

   • ‫INSTANCE_ID: המזהה הקבוע של המכונה שרוצים להעביר.

   בפלט מוצגת רשימה של פעולות ממושכות, כולל פעולת העברת המכונה.

2. מריצים את הפקודה gcloud spanner operations describe כדי לראות את אחוז ההתקדמות והסטטוס:

   gcloud spanner operations describe OPERATION_ID --instance=INSTANCE_ID
   

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

   • ‫OPERATION_ID: מזהה הפעולה של העברת המכונה שרוצים לבדוק.
   • ‫INSTANCE_ID: המזהה של המכונה שרוצים לבדוק.

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

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

התרשימים Total storage ו-Total database storage by databases בלוח הבקרה עוזרים לעקוב אחרי התקדמות ההעברה. אפשר לראות שנפח האחסון בהגדרת המקור יורד בהדרגה, בעוד שנפח האחסון בהגדרת היעד עולה.

מסוף Google Cloud

1. מורידים את הקובץ move-instance-dashboard.json. הקובץ הזה מכיל את המידע שנדרש כדי לאכלס לוח בקרה בהתאמה אישית ב-Monitoring.

2. נכנסים לדף  Dashboards במסוף Google Cloud :

   כניסה לדף Dashboards

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

3. בדף Dashboards Overview, לוחצים על Create dashboard.
4. בסרגל הכלים של מרכז הבקרה, לוחצים על התפריט הנפתח Dashboard settings. בוחרים באפשרות JSON ואז באפשרות עורך JSON.
5. בחלונית JSON Editor, מעתיקים את התוכן של קובץ ה-move-instance-dashboard.json שהורדתם ומדביקים אותו בכלי העריכה.
6. כדי להחיל את השינויים על מרכז הבקרה, לוחצים על Apply changes. אם אתם לא רוצים להשתמש במרכז הבקרה הזה, חזרו לדף סקירה כללית של מרכזי בקרה.
7. אחרי שיוצרים את מרכז הבקרה, לוחצים על Add Filter. אחר כך בוחרים באפשרות project_id או instance_id כדי לעקוב אחרי התקדמות ההעברה של המכונה.

‫CLI של gcloud

1. מורידים את הקובץ move-instance-dashboard.json. הקובץ הזה מכיל את המידע שנדרש כדי לאכלס לוח בקרה בהתאמה אישית ב-Monitoring.

2. כדי ליצור מרכז בקרה בפרויקט, משתמשים בפקודה gcloud monitoring dashboards create:

   gcloud monitoring dashboards create --config-from-file=move-instance-dashboard.json
   

   למידע נוסף, עיינו במאמרי העזרה של gcloud monitoring dashboards create.

שלב 4: השלמת המשימות שאחרי המעבר

אחרי שפעולת ההעברה הארוכה מסתיימת (done: true), משלימים את רשימת המשימות הבאה כדי לשחזר את ההגדרות התפעוליות:

1. הפעלה מחדש של ההתאמה האוטומטית המנוהלת לעומס: אם לפני המעבר עברתם מהתאמה אוטומטית מנוהלת לעומס להקצאה ידנית, הפעילו מחדש את ההתאמה האוטומטית המנוהלת לעומס עם הגבולות המינימליים והמקסימליים של קיבולת המחשוב (לדוגמה, על ידי הפעלת gcloud spanner instances update INSTANCE_ID עם הדגלים של ההתאמה האוטומטית לעומס או במסוף Google Cloud ).
2. יצירה מחדש של לוחות זמנים לגיבוי ויצירת גיבוי: יוצרים מחדש את לוחות הזמנים לגיבוי ויוצרים גיבוי חדש למסדי הנתונים בהגדרת המכונה של היעד.
3. ייבוא תגי Data Catalog: אם ייצאתם תגי Data Catalog לפני ההעברה, ייבאו אותם בחזרה למכונה שהועברה.
4. עדכון הגדרות האוטומציה, מיקום הלקוח ועומסי העבודה במורד הזרם:
   • אם אתם מנהלים את המשאבים של Spanner באמצעות כלים אוטומטיים כמו Terraform, עדכנו את קובצי התצורה כך שישקפו את הגדרת המכונה החדשה של היעד לפני שתפעילו מחדש את הפריסות האוטומטיות.
   • אם האזור הראשי השתנה אחרי המעבר, צריך לפרוס את אפליקציות הלקוח או לנתב אותן בתוך האזור הראשי החדש או קרוב אליו (או לשנות את האזור הראשי שמוגדר כברירת מחדל במסד הנתונים אם משתמשים בהגדרה של שני אזורים או של מספר אזורים) כדי לצמצם את זמן האחזור של הכתיבה, ולוודא את הקישוריות וזמן האחזור באפליקציות ובצינורות עיבוד הנתונים במורד הזרם.
5. מחיקת מופעים זמניים של פלייסהולדרים: אחרי שמאמתים את המופע שהועבר ויוצרים גיבויים חדשים בהגדרת היעד, מוחקים את המופעים הזמניים של placeholder-source ו-placeholder-dest אם לא צריך יותר את הגיבויים שהועתקו.

איך מבטלים העברה של מכונה

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

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

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

1. מריצים את הפקודה הבאה כדי לקבל את מזהה הפעולה:

   gcloud spanner operations list --type=INSTANCE --instance="INSTANCE_ID"
   --filter="done:False AND metadata.@type:MoveInstanceMetadata"
   

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

   • ‫INSTANCE_ID: המזהה הקבוע של המכונה שרוצים להעביר.

   בפלט מוצגת רשימה של פעולות העברת מכונות שנמצאות בתהליך.

2. מריצים את הפקודה gcloud spanner operations cancel כדי לבטל את העברת המכונה:

   gcloud spanner operations cancel OPERATION_ID
   

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

   • ‫OPERATION_ID: מזהה הפעולה של העברת המכונה שרוצים לבטל.

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

• מידע נוסף על הגדרות אזוריות, הגדרות של שני אזורים והגדרות של מספר אזורים ב-Spanner
• Google Cloud מידע נוסף על אזורים ותחומים