פריסת Microsoft SQL Server לצורך התאוששות מאסון (DR) בכמה אזורים

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

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

המדריך הזה מיועד לאדריכלים, לאדמינים ולמהנדסים של מסדי נתונים.

מטרות

• פריסת סביבה להתאוששות מאסון במספר אזורים ב-Google Cloud באמצעות קבוצות זמינות AlwaysOn של Microsoft SQL Server.
• מדמים אירוע אסון ומבצעים תהליך מלא של התאוששות מאסון כדי לאמת את הגדרת ההתאוששות מאסון.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Compute Engine
• SQL Server VMs

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

במדריך הזה תצטרכו פרויקט Google Cloud . אפשר ליצור פרויקט חדש או לבחור פרויקט שכבר יצרתם:

1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

   התפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
   הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שקשורים אליו.

   כניסה לדף לבחירת הפרויקט

2. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

3. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

הסבר על תוכנית התאוששות מאסון (DR)

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

תוכנית התאוששות מאסון (DR) למערכת מסד נתונים

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

ארכיטקטורה של תוכנית התאוששות מאסון (DR)

בתרשים הבא מוצגת ארכיטקטורה מינימלית של Microsoft SQL Server שתומכת ב-DR של מסד נתונים.

איור 1. ארכיטקטורה רגילה של התאוששות מאסון עם Microsoft SQL Server.

הארכיטקטורה הזו פועלת כך:

• שני מופעים של Microsoft SQL Server (מופע ראשי ומופע במצב המתנה) ממוקמים באותו אזור (R1) אבל באזורים שונים (אזור A ואזור B). שני המופעים ב-R1 מתאמים את המצבים שלהם באמצעות מצב synchronous-commit. מצב סינכרוני משמש לתמיכה בזמינות גבוהה ולשמירה על מצב נתונים עקבי.
• מופע אחד של Microsoft SQL Server (המופע המשני או המופע לשחזור אחרי אסון) ממוקם באזור שני (R2). לצורך DR, המכונה המשנית ב-R2 מסתנכרנת עם המכונה הראשית ב-R1 באמצעות מצב asynchronous-commit. השימוש במצב אסינכרוני נובע מהביצועים שלו (הוא לא מאט את עיבוד השמירה במופע הראשי).

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

• המופע הראשי
• המכונה במצב המתנה (אחרי כשל באזור)
• המכונה המשנית (אחרי כשל באזור ואחרי שהמכונה המשנית הופכת למכונה הראשית החדשה)

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

תהליך בסיסי של התאוששות מאסון (DR)

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

תהליך בסיסי של DR למסד נתונים כולל את השלבים הבאים:

1. האזור הראשון (R1), שבו פועל מופע מסד הנתונים הראשי, לא זמין.
2. צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
3. אם נדרש מעבר לגיבוי בעת כשל, המכונה המשנית של מסד הנתונים באזור השני (R2) הופכת למכונה הראשית החדשה.
4. הלקוחות ממשיכים את העיבוד במסד הנתונים הראשי החדש ויש להם גישה למופע הראשי ב-R2.

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

השלמת תהליך ההתאוששות מאסון (DR)

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

איור 2. תוכנית התאוששות מאסון (DR) עם אזור ראשי לא זמין (R1).

ארכיטקטורת ה-DR המלאה של מסד הנתונים פועלת באופן הבא:

1. האזור הראשון (R1), שבו פועל מופע מסד הנתונים הראשי, לא זמין.
2. צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
3. אם נדרש מעבר לגיבוי, מופעלת יצירת מופע משני של מסד הנתונים באזור השני (R2) והוא הופך למופע הראשי.
4. מכונה משנית נוספת, מכונה במצב המתנה חדשה, נוצרת ומופעלת באזור R2 ומתווספת למכונה הראשית. המופע במצב המתנה נמצא באזור אחר מהמופע הראשי. מסד הנתונים הראשי כולל עכשיו שתי מכונות (primary ו-standby) עם זמינות גבוהה.
5. באזור שלישי (R3), נוצרת מופע חדש של מסד נתונים משני (במצב המתנה) ומופעל. המופע המשני הזה מחובר באופן אסינכרוני למופע הראשי החדש ב-R2. בשלב הזה, הארכיטקטורה המקורית של תוכנית ההתאוששות מאסון נוצרת מחדש ומוכנה לפעולה.

חזרה לאזור משוחזר

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

התרשים הבא מציג את הארכיטקטורה אם R1 הופך לזמין בזמן.

איור 3. התאוששות מאסון אחרי שאזור R1 שנכשל חוזר להיות זמין.

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

בחירה של מהדורת SQL Server

המדריך הזה תומך בגרסאות הבאות של Microsoft SQL Server:

• SQL Server 2016 Enterprise Edition
• SQL Server 2017 Enterprise Edition
• ‫SQL Server 2019 Enterprise Edition
• SQL Server 2022 Enterprise Edition

במדריך הזה נעשה שימוש בתכונה AlwaysOn Availability Groups ב-SQL Server.

אם אתם לא צריכים מסד נתונים ראשי של Microsoft SQL Server עם זמינות גבוהה (HA), ומספיק לכם מופע אחד של מסד נתונים בתור מסד הנתונים הראשי, אתם יכולים להשתמש בגרסאות הבאות של SQL Server:

• ‫SQL Server 2016 Standard Edition
• SQL Server 2017 Standard Edition
• SQL Server 2019 Standard Edition
• SQL Server 2022 Standard Edition

בגרסאות 2016,‏ 2017,‏ 2019 ו-2022 של SQL Server,‏ Microsoft SQL Server Management Studio מותקן בקובץ האימג', כך שאין צורך להתקין אותו בנפרד. עם זאת, בסביבת ייצור מומלץ להתקין מופע אחד של Microsoft SQL Server Management Studio במכונה וירטואלית נפרדת בכל אזור. אם מגדירים סביבת זמינות גבוהה, צריך להתקין את Microsoft SQL Server Management Studio פעם אחת לכל אזור כדי לוודא שהיא תישאר זמינה אם אזור אחר לא יהיה זמין.

הגדרה של Microsoft SQL Server להתאוששות מאסון (DR) בכמה אזורים

בקטע הזה נעשה שימוש בתמונות הבאות עבור Microsoft SQL Server:

• ‫sql-ent-2016-win-2016 ל-Microsoft SQL Server 2016 Enterprise Edition
• ‫sql-ent-2017-win-2016 ל-Microsoft SQL Server 2017 Enterprise Edition
• ‫sql-ent-2019-win-2019 ל-Microsoft SQL Server 2019 Enterprise Edition
• ‫sql-ent-2022-win-2022 ל-Microsoft SQL Server 2022 Enterprise Edition

רשימה מלאה של תמונות זמינה במאמר בנושא תמונות.

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

כדי להגדיר ארכיטקטורת DR של מסד נתונים רב-אזורי ל-SQL Server, קודם צריך ליצור אשכול של זמינות גבוהה (HA) עם שני מופעים באזור. מופע אחד משמש כראשי והמופע השני משמש כמשני. כדי לבצע את השלב הזה, פועלים לפי ההוראות במאמר הגדרת קבוצות זמינות של SQL Server AlwaysOn. במדריך הזה נעשה שימוש באזור הראשי us-central1 (שנקרא R1). לפני שמתחילים, חשוב לשים לב לנקודות הבאות:

• אם פעלתם לפי השלבים במאמר בנושא הגדרת קבוצות זמינות של SQL Server AlwaysOn, יצרתם שתי מכונות של SQL Server באותו אזור (us-central1). פרסתם מכונה ראשית של SQL Server‏ (node-1) ב-us-central1-a ומכונה במצב המתנה (node-2) ב-us-central1-b.

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

איור 4. ארכיטקטורה סטנדרטית של התאוששות מאסון (DR) שמוטמעת במדריך הזה.

הוספת מכונה משנית לתוכנית התאוששות מאסון (DR)

לאחר מכן מגדירים מכונה שלישית של SQL Server (מכונה משנית בשם node-3) ומגדירים את הרשת באופן הבא:

1. יוצרים סקריפט מיוחד לצומתי Windows Server Failover Cluster. הסקריפט מתקין את התכונה הנדרשת של Windows ויוצר כללי חומת אש עבור WSFC ו-SQL Server. הוא גם מגדיר את הפורמט של דיסק הנתונים ויוצר תיקיות של נתונים ויומנים ל-SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. מאתחלים את המשתנים הבאים:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   כאשר:

   • ‫VPC_NAME: השם של ה-VPC
   • ‫SUBNET_NAME: השם של תת-הרשת באזור us-east1

3. יוצרים מכונה של SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. מגדירים סיסמה ל-Windows עבור מכונת SQL Server החדשה:

   1. במסוף Google Cloud , נכנסים לדף Compute Engine.

      מעבר אל Compute Engine

   2. בעמודה Connect של אשכול Compute Engine‏ node-3, בוחרים את הרשימה הנפתחת Set windows password.

   3. מגדירים את שם המשתמש והסיסמה. כדאי לרשום אותם כדי להשתמש בהם בהמשך.

5. לוחצים על RDP כדי להתחבר למופע node-3.

6. מזינים את שם המשתמש והסיסמה מהשלב הקודם ולוחצים על OK.

7. מוסיפים את המופע לדומיין Windows:

   1. לוחצים לחיצה ימנית על Start (או מקישים על Win+X) ואז לוחצים על Windows PowerShell (Admin).

   2. מאשרים את בקשת ההרשאה בלחיצה על "כן".

   3. מצטרפים עם המחשב לדומיין Active Directory ומפעילים מחדש:

      Add-Computer -Domain DOMAIN -Restart
      

      מחליפים את DOMAIN בשם ה-DNS של הדומיין ב-Active Directory.

      מחכים כדקה עד שההפעלה מחדש תסתיים.

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

בשלב הבא, מוסיפים את המופע המשני (node-3) לאשכול המעבר לגיבוי בעת כשל ב-Windows:

1. מתחברים למכונות node-1 או node-2 באמצעות RDP ונכנסים בתור משתמש עם הרשאת אדמין.

2. פותחים חלון PowerShell כמשתמש אדמין ומגדירים משתנים לסביבת האשכול במדריך הזה:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   מחליפים את SQLSRV_CLUSTER בשם של אשכול SQL Server.

3. מוסיפים את המופע המשני לאשכול:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

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

4. בצומת, מפעילים את התכונה AlwaysOn זמינות גבוהה:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

הצומת הוא עכשיו חלק מאשכול יתירות הכשל.

הוספת המופע המשני לקבוצת הזמינות הקיימת

בשלב הבא, מוסיפים את המופע של SQL Server (המופע המשני) ואת מסד הנתונים לקבוצת הזמינות:

1. מתחברים אל node-3 באמצעות Remote Desktop. נכנסים באמצעות חשבון המשתמש בדומיין.

2. פותחים את SQL Server Configuration Manager.

3. בחלונית הניווט, בוחרים באפשרות SQL Server Services (שירותי SQL Server).

4. ברשימת השירותים, לוחצים לחיצה ימנית על SQL Server (MSSQLSERVER)‎ ובוחרים באפשרות Properties.

5. בקטע כניסה בתור, משנים את החשבון:

   • שם החשבון: DOMAIN\sql_server כאשר DOMAIN הוא השם של NetBIOS של הדומיין שלך ב-Active Directory.
   • סיסמה: מזינים את הסיסמה שבחרתם קודם לחשבון הדומיין של sql_server.

6. לוחצים על OK.

7. כשמופיעה בקשה להפעלה מחדש של SQL Server, בוחרים באפשרות כן.

8. באחד משלושת צמתי המכונות node-1, node-2 או node-3, פותחים את Microsoft SQL Server Management Studio ומתחברים למכונה הראשית – node-1.

   1. עוברים אל Object Explorer.
   2. לוחצים על התפריט הנפתח קישור.
   3. בוחרים באפשרות מנוע מסד נתונים.
   4. בתפריט הנפתח Server Name, בוחרים באפשרות node-1. אם האשכול לא מופיע ברשימה, מזינים אותו בשדה.

9. לוחצים על New Query.

   הערה: אם השתמשתם בשם רשת מבוזר כדי להגדיר את קבוצת הזמינות AlwaysOn, אתם לא צריכים לבצע את שלבים 9 ו-10.

10. מדביקים את הפקודה הבאה כדי להוסיף כתובת IP למאזין שמשמש את הצומת, ואז לוחצים על Execute (ביצוע):

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    מחליפים את LOAD_BALANCER_IP_ADDRESS בכתובת ה-IP של מאזן העומסים באזור us-east1.

11. ב-Object Explorer, מרחיבים את הצומת AlwaysOn זמינות גבוהה ואז מרחיבים את הצומת Availability Groups.

12. לוחצים לחיצה ימנית על קבוצת הזמינות שנקראת bookshelf-ag ואז בוחרים באפשרות הוספת עותק משוכפל.

13. בדף Introduction, לוחצים על הצומת AlwaysOn זמינות גבוהה ואז על הצומת Availability Groups.

14. בדף Connect to Replicas (חיבור לרפליקות), לוחצים על Connect (חיבור) כדי להתחבר לרפליקה המשנית הקיימת node-2.

15. בדף Specify Replicas (ציון רפליקות), לוחצים על Add Replica (הוספת רפליקה) ואז מוסיפים את הצומת החדש node-3. אל תבחרו באפשרות יתירות כשל אוטומטית כי יתירות כשל אוטומטית גורמת לביצוע שמירה סינכרונית. הגדרה כזו חוצה גבולות אזוריים, ואנחנו לא ממליצים על כך.

16. בדף Select Data Synchronization, בוחרים באפשרות Automatic seeding.

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

17. מבצעים את השלבים באשף.

מצב המעבר לגיבוי עבור node-1 ו-node-2 הוא אוטומטי, אבל עבור node-3 הוא ידני. ההבדל הזה הוא דרך אחת להבחין בין זמינות גבוהה לבין תוכנית התאוששות מאסון (DR).

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

הדמיה של תוכנית התאוששות מאסון (DR)

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

הדמיה של הפסקת שירות והפעלה של מעבר לגיבוי (failover) לצורך התאוששות מאסון (DR)

1. סימולציה של כשל או הפסקת חשמל באזור הראשי:

   1. ב-Microsoft SQL Server Management Studio ב-node-1, מתחברים אל node-1.

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

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. ב-Cloud Shell, משביתים את שני השרתים באזור הראשי us-central1:

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

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

2. ב-Microsoft SQL Server Management Studio ב-node-3, מתחברים אל node-3.

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

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   אפשר להמשיך את תהליך העיבוד. node-3 היא עכשיו המופע הראשי.

4. (אופציונלי) יוצרים טבלה חדשה ב-node-3. אחרי שמסנכרנים את העותקים עם העותק הראשי החדש, בודקים אם הטבלה הזו משוכפלת בעותקים.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

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

(אופציונלי) יצירה מחדש של ארכיטקטורת DR שמשכפלת את העסקאות באופן מלא

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

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

• חזרה לשרת הראשי המקורי ולשרת הגיבוי המקורי (אם הם זמינים).
• יוצרים מכשיר משני חדש ומכשיר חדש במצב המתנה בשביל node-3, למקרה שהמכשיר הראשי המקורי והמכשיר המקורי במצב המתנה לא יהיו זמינים.

גישה 1: חזרה לשרת הראשי ולשרת ההמתנה המקוריים

1. ב-Cloud Shell, מפעילים את המכונה הראשית המקורית (הישנה) ואת המכונה במצב המתנה:

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. ב-Microsoft SQL Server Management Studio, מוסיפים שוב את node-1 ואת node-2 כעותקים משניים:

   1. ב-node-3, מוסיפים את שני השרתים במצב של אישור אסינכרוני:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. בתאריך node-1, מתחילים לסנכרן מחדש את מסדי הנתונים:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. בתאריך node-2, מתחילים לסנכרן מחדש את מסדי הנתונים:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. להגדיר שוב את node-1 כראשי:

   1. ב-node-3, משנים את מצב הזמינות של node-1 ל-synchronous-commit. המכונה node-1 הופכת שוב למכונה הראשית.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. ב-node-1, משנים את node-1 כך שיהיה ראשי, ואת שני הצמתים האחרים כך שיהיו משניים:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

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

גישה 2: הגדרה של שרת ראשי חדש ושרת גיבוי

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

איור 5. תוכנית התאוששות מאסון (DR) עם אזור ראשי מקורי R1 שלא זמין.

כדי להטמיע את התכונה הזו, צריך לבצע את הפעולות הבאות:

• השארת node-3 כאמצעי התשלום הראשי ב-us-east1.

• מוסיפים מכונה חדשה במצב המתנה (node-4) באזור אחר ב-us-east1. השלב הזה מבטיח שהפריסה החדשה תהיה עם זמינות גבוהה.

• יוצרים מכונה משנית חדשה (node-5) באזור נפרד, לדוגמה, us-west2. בשלב הזה מגדירים את הפריסה החדשה לצורך התאוששות מאסון. הפריסה הכוללת הושלמה. ארכיטקטורת מסד הנתונים תומכת באופן מלא בזמינות גבוהה (HA) ובאפשרות לשחזור מאסון (DR).

(אופציונלי) ביצוע גיבוי כשחסרות עסקאות

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

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

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

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

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

כדי להוסיף את node-1 כמופע משני, אפשר לפעול לפי אותם השלבים להוספת node-3 שצוינו קודם (ראו הוספת המופע המשני לאשכול הגיבוי האוטומטי), עם ההבדל הבא: node-3 הוא עכשיו המופע הראשי, ולא node-1. צריך להחליף כל מופע של node-3 בשם השרת שמוסיפים לקבוצת הזמינות. אם משתמשים שוב באותה מכונה וירטואלית (node-1 ו-node-2), לא צריך להוסיף את השרת ל-Windows Server Failover Cluster, אלא רק להוסיף את מופע SQL Server בחזרה לקבוצת הזמינות.

בשלב הזה, node-3 הוא הראשי, ו-node-1 ו-node-2 הם המשניים. עכשיו אפשר לחזור ל-node-1, להגדיר את node-2 כגיבוי ואת node-3 כמשני. המערכת נמצאת עכשיו באותו מצב שבו הייתה לפני הכשל.

יתירות כשל אוטומטית

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

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

ארכיטקטורת פריסה חלופית

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

איור 6. ארכיטקטורה סטנדרטית של התאוששות מאסון באמצעות Microsoft SQL Server.

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

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

איור 7. ארכיטקטורה סטנדרטית של תוכנית התאוששות מאסון (DR) עם שני מכונות משניות.

איור 8. ארכיטקטורה סטנדרטית של תוכנית התאוששות מאסון (DR) עם שני מכונות משניות אחרי יתירות כשל.

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

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

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה:

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:
• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.
1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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

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