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

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

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

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

מטרות

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

עלויות

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

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

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

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

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

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

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

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

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

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

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

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

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

    מופעים ראשיים ומופעי המתנה ממוקמים בשני אזורים באזור R1, ומופע משני ממוקם באזור R2.

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

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

    • שני מופעים של Microsoft SQL Server (מופע ראשי ומופע במצב המתנה) ממוקמים באותו אזור (R1), אבל באזורים שונים (אזור A ואזור B). שני המקרים ב-R1 מתאמים את המצבים שלהם באמצעות מצב אישור סינכרוני. השימוש במצב סינכרוני נובע מהתמיכה שלו בזמינות גבוהה ומהשמירה על מצב נתונים עקבי.
    • מופע אחד של 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 במסד נתונים, המופע המשני באזור R2 הופך למופע הראשי, ומופע משני חדש נוצר באזור R3.

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

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

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

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

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

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

    אם אזור R1 ישוחזר בזמן, ייצרו מופעים משניים באזור 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
    • 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. לוחצים לחיצה ימנית על לחצן ההתחלה (או מקישים על 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 high availability:

      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. עוברים אל סייר האובייקטים.
      2. בוחרים באפשרות קישור מהתפריט הנפתח.
      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 (הוספה אוטומטית של נתונים).

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

    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 הוא השרת הראשי והצמתים האחרים הם משניים, כמו שמוצג בדיאגרמה הבאה.

    ב-Object Explorer מוצגות קבוצות הזמינות.

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

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

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

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

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

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

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

    שני המופעים המשניים ממוקמים באזורים נפרדים באזור R2.

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

    אחרי המעבר לגיבוי, אחת מהמכונות המשניות באזור R2 הופכת למכונת גיבוי.

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

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

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

    הסרת המשאבים

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

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

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

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

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