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

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

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

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

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

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

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

איור 1. ארכיטקטורה סטנדרטית של התאוששות מאסון (DR) עם 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 מתחיל כשאי אפשר לגשת לאזור מסוים, ומסד הנתונים הראשי עובר למצב failover כדי להמשיך את העיבוד באזור פעיל אחר. תהליך ה-DR קובע את השלבים התפעוליים שצריך לבצע, באופן ידני או אוטומטי, כדי לצמצם את ההשפעה של הכשל באזור ולהקים מופע ראשי פעיל באזור זמין.

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

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

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

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

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

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

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

1. האזור הראשון (R1), שבו פועל מופע מסד הנתונים הראשי, הופך ללא זמין.
2. צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
3. אם נדרש מעבר לגיבוי, מופעלת יצירת מופע של מסד הנתונים המשני באזור השני (R2) בתור המופע הראשי.
4. מופע משני נוסף, מופע ההמתנה החדש, נוצר ומופעל ב-R2 ומתווסף למופע הראשי. מופע ההמתנה נמצא באזור אחר מזה של המופע הראשי. מסד הנתונים הראשי כולל עכשיו שני מופעים (ראשי וגיבוי) שזמינים מאוד.
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
• 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) שמוטמעת במדריך הזה.

הוספת מופע משני לשחזור לאחר אסון

לאחר מכן מגדירים מופע שלישי של 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. במסוף Cloud de Confiance , נכנסים לדף Compute Engine.

      מעבר אל Compute Engine

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

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

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

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

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

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

   2. לוחצים על 'כן' כדי לאשר את ההודעה על העלאת הרשאות.

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

      Add-Computer -Domain DOMAIN -Restart
      

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

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

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

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

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. לוחצים על הרשימה הנפתחת Connect (קישור).
   3. בוחרים באפשרות מנוע מסד נתונים.
   4. מהרשימה הנפתחת שם השרת, בוחרים באפשרות node-1. אם האשכול לא מופיע ברשימה, מזינים אותו בשדה.

9. לוחצים על שאילתה חדשה.

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 High Availability ואז מרחיבים את הצומת Availability Groups.

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

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

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

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

16. בדף Select Data Synchronization (בחירת סנכרון נתונים), בוחרים באפשרות Automatic seeding (הוספה אוטומטית של נתונים).

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

17. פועלים לפי ההנחיות של אשף ההגדרה.

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

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

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

בקטע הזה נבדוק את ארכיטקטורת ההתאוששות מאסון (DR) של המדריך הזה, ונציג יישומי 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
      

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 שמשכפלת עסקאות באופן מלא

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

בתרחיש הזה, אפשר ליצור מחדש ארכיטקטורת 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, מוסיפים את שני השרתים במצב asynchronous-commit:

      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 כמשני. המערכת חוזרת למצב שהיה לפני הכשל.

מעבר אוטומטי לגיבוי (failover)

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

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

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

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

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

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

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

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

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

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

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