הפעלת התאוששות מאסון (DR) עבור Persistent Disk של Microsoft SQL Server

במדריך הזה מוסבר איך להפעיל שכפול אסינכרוני של Persistent Disk (שכפול אסינכרוני של PD) בשני אזורים של Google Cloud כדי ליצור פתרון להתאוששות מאסון (DR), ואיך להפעיל את מופעי ה-DR במקרה של אסון.

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

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

מטרות

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

עלויות

במסמך הזה משתמשים ברכיבים הבאים של 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

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

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

    רפליקציה אסינכרונית של Persistent Disk‏ (PD Async Replication) מספקת רפליקציה של אחסון בלוקים עם RPO ו-RTO נמוכים עבור DR פעיל-סביל בין אזורים.

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

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

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

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

    בתרשים הבא מוצגת ארכיטקטורה מינימלית של PD Async Replication שתומכת בזמינות גבוהה של מסד נתונים באזור ראשי, וברפליקציה של דיסקים מהאזור הראשי לאזור DR.

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

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

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

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

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

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

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

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

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

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

    איור 2. פריסת SQL Server אחרי תוכנית התאוששות מאסון (DR) באמצעות שכפול אסינכרוני של Persistent Disk

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

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

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

    הגדרת התאוששות מאסון (DR) עבור Microsoft SQL Server

    במדריך הזה נעשה שימוש בתמונה sql-ent-2022-win-2022 של Microsoft SQL Server Enterprise.

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

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

    כדי להגדיר שכפול של דיסק לאזור 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.

    הפעלת שכפול אסינכרוני של דיסקים

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

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

      gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \
      --region=$REGION
      
      gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \
      --region=$REGION
      
      gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \
      --region=$REGION
      
    2. מוסיפים את הדיסקים מהמכונות הווירטואליות הראשיות וממכונות ההמתנה לקבוצות העקביות המתאימות.

      gcloud compute disks add-resource-policies node-1 \
      --zone=$REGION-a \
      --resource-policies=node-1-disk-const-grp
      
      gcloud compute disks add-resource-policies node-1-datadisk \
      --zone=$REGION-a \
      --resource-policies=node-1-disk-const-grp
      
      gcloud compute disks add-resource-policies node-2 \
      --zone=$REGION-b \
      --resource-policies=node-2-disk-const-grp
      
      gcloud compute disks add-resource-policies node-2-datadisk \
      --zone=$REGION-b \
      --resource-policies=node-2-disk-const-grp
      
      gcloud compute disks add-resource-policies witness \
      --zone=$REGION-c \
      --resource-policies=witness-disk-const-grp
      
    3. יצירת דיסקים משניים ריקים באזור המקביל

      DR_REGION="us-west1"
      gcloud compute disks create node-1-replica \
        --zone=$DR_REGION-a \
        --size=50 \
        --primary-disk=node-1 \
        --primary-disk-zone=$REGION-a
      
      gcloud compute disks create node-1-datadisk-replica \
        --zone=$DR_REGION-a \
        --size=$PD_SIZE \
        --primary-disk=node-1-datadisk \
        --primary-disk-zone=$REGION-a
      
      gcloud compute disks create node-2-replica \
        --zone=$DR_REGION-b \
        --size=50 \
        --primary-disk=node-2 \
        --primary-disk-zone=$REGION-b
      
      gcloud compute disks create node-2-datadisk-replica \
        --zone=$DR_REGION-b \
        --size=$PD_SIZE \
        --primary-disk=node-2-datadisk \
        --primary-disk-zone=$REGION-b
      
      gcloud compute disks create witness-replica \
        --zone=$DR_REGION-c \
        --size=50 \
        --primary-disk=witness \
        --primary-disk-zone=$REGION-c
      
    4. מתחילים לשכפל את הדיסק. הנתונים משוכפלים מהדיסק הראשי לדיסק הריק החדש שנוצר באזור DR.

      gcloud compute disks start-async-replication node-1 \
        --zone=$REGION-a \
        --secondary-disk=node-1-replica \
        --secondary-disk-zone=$DR_REGION-a 
      
      gcloud compute disks start-async-replication node-1-datadisk \
        --zone=$REGION-a \
        --secondary-disk=node-1-datadisk-replica \
        --secondary-disk-zone=$DR_REGION-a 
      
      gcloud compute disks start-async-replication node-2 \
        --zone=$REGION-b \
        --secondary-disk=node-2-replica \
        --secondary-disk-zone=$DR_REGION-b 
      
      gcloud compute disks start-async-replication node-2-datadisk \
        --zone=$REGION-b \
        --secondary-disk=node-2-datadisk-replica \
        --secondary-disk-zone=$DR_REGION-b 
      
      gcloud compute disks start-async-replication witness \
        --zone=$REGION-c \
        --secondary-disk=witness-replica \
        --secondary-disk-zone=$DR_REGION-c 
      

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

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

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

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

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

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

    1. יוצרים VPC לשחזור.

      DRVPC_NAME="default-dr"
      DRSUBNET_NAME="default-recovery"
      
      gcloud compute networks create $DRVPC_NAME \
      --subnet-mode=custom
      CIDR = $(gcloud compute networks subnets describe default \
      --region=$REGION --format=value\(ipCidrRange\))
      
      gcloud compute networks subnets create $DRSUBNET_NAME \
      --network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION
      
    2. הפסקת שכפול הנתונים.

      PROJECT=$(gcloud config get-value project)
      gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \
      --zone=$REGION-a
      
      gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \
      --zone=$REGION-b
      
      gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \
      --zone=$REGION-c
      
    3. מפסיקים את המכונות הווירטואליות של המקור באזור הראשי.

      gcloud compute instances stop node-1 \
        --zone=$REGION-a
      
      gcloud compute instances stop node-2 \
        --zone=$REGION-b
      
      gcloud compute instances stop witness \
        --zone=$REGION-c
      
    4. יצירת מכונות וירטואליות באזור DR באמצעות רפליקות של דיסקים. למכונות הווירטואליות האלה יהיה כתובת ה-IP של המכונה הווירטואלית המקורית.

      NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
      NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
      WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
      
      gcloud compute instances create node-1 \
        --zone=$DR_REGION-a \
        --machine-type $MACHINE_TYPE \
        --network=$DRVPC_NAME \
        --subnet=$DRSUBNET_NAME \
        --private-network-ip $NODE1IP\
        --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \
        --disk=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica
      
      gcloud compute instances create witness \
        --zone=$DR_REGION-c \
        --machine-type=n2-standard-2 \
        --network=$DRVPC_NAME \
        --subnet=$DRSUBNET_NAME \
        --private-network-ip $WITNESSIP \
        --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica
      

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

    אימות הקישוריות ל-SQL Server

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

    1. מתחברים למכונה הווירטואלית של SQL Server באמצעות Remote Desktop.
    2. פותחים את SQL Server Management Studio.
    3. בתיבת הדו-שיח 'התחברות לשרת', מוודאים ששם השרת מוגדר ל-NODE-1 ולוחצים על התחברות.
    4. בתפריט הקובץ, בוחרים באפשרות קובץ > חדש > שאילתה עם החיבור הנוכחי.

      USE [bookshelf];
      SELECT * FROM Books;
      

    הסרת המשאבים

    כדי להימנע מחיובים בחשבון 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.