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

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

הערה: במדריך הזה נעשה שימוש ב-Hyperdisk של Google Cloud, שהוא אחסון בלוקים עמיד ומומלץ ל-Google Cloud. כדי לפרוס SQL Server עם סדרת מכונות שלא תומכת ב-Hyperdisk, אפשר לעיין בהוראות במאמר הפעלת התאוששות מאסון (DR) עבור Microsoft SQL Server עם Persistent Disk.

‫Microsoft SQL Server Failover Cluster Instances ‏(FCI) הוא מופע יחיד של SQL Server עם זמינות גבוהה, שנפרס במספר צמתים של Windows Server Failover Cluster ‏ (WSFC). בכל נקודת זמן, אחד מצמתי האשכול מארח באופן פעיל את מופע ה-SQL. במקרה של הפסקה זמנית בשירות אזורית או בעיה ב-VM, ‏WSFC מעביר באופן אוטומטי את הבעלות על המשאבים של המופע לצומת אחר באשכול, וכך מאפשר ללקוחות להתחבר מחדש. כדי ש-SQL Server FCI יוכל לגשת לנתונים בכל צמתי ה-WSFC, הנתונים צריכים להיות ממוקמים בדיסקים משותפים.

כדי להבטיח שה-Deployment (פריסה) של SQL Server יוכל לעמוד בהפסקה זמנית בשירות אזורית, יש ליצור רפליקציה של נתוני הדיסק באזור הראשי באזור משני על ידי הפעלת רפליקציה אסינכרונית. במדריך הזה נעשה שימוש בדיסקים של Hyperdisk Balanced High Availability multi-writer כדי להפעיל שכפול אסינכרוני בשני אזורים של Google Cloud כפתרון לשחזור אחרי אסון (DR) עבור SQL Server FCI, ומוסבר איך להפעיל את מכונות ה-DR במקרה של אסון. במסמך הזה, אסון הוא אירוע שבו אשכול של מסד נתונים ראשי נכשל או הופך ללא זמין כי האזור של האשכול הופך ללא זמין, אולי בגלל אסון טבע.

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

מטרות

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

עלויות

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

• Compute Engine
• Asynchronous Replication Protection

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

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

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

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

1. כדי לבצע את המדריך הזה, צריך פרויקט 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.
      Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

      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

   4. מגדירים את אשכול SQL Server באזור הראשי לפי השלבים במדריך הגדרת אשכול SQL Server FCI במצב קריאה וכתיבה מרובים של Hyperdisk Balanced High Availability. אחרי שמגדירים את האשכול, חוזרים למדריך הזה כדי להפעיל את DR באזור המשני.

   5. הרשאות מתאימות בפרויקט בענן שלכם ב-Google Cloud וב-SQL Server לביצוע גיבויים ושחזורים.

   תוכנית התאוששות מאסון (DR) ב- Google Cloud

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

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

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

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

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

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

   

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

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

   • שני מופעים של Microsoft SQL Server, מופע ראשי ומופע בהמתנה, הם חלק מאשכול FCI, והם ממוקמים באזור הראשי (R1), אבל באזורים שונים (אזורים A ו-B). שתי המכונות הווירטואליות חולקות דיסק Hyperdisk Balanced High Availability, כך ששתיהן יכולות לגשת לנתונים. הוראות מפורטות זמינות במאמר הגדרת אשכול FCI של SQL Server עם מצב קריאה/כתיבה מרובה של Hyperdisk Balanced High Availability
   • דיסקים משני צמתי ה-SQL מתווספים לקבוצות עקביות ומשוכפלים לאזור ההתאוששות מאסון, R2. ‫Compute Engine משכפל את הנתונים מ-R1 ל-R2 באופן אסינכרוני.
   • רפליקציה אסינכרונית מעתיקה רק את הנתונים בדיסקים אל R2, ולא מעתיקה את המטא-נתונים של המכונה הווירטואלית. במהלך התאוששות מאסון, נוצרות מכונות וירטואליות חדשות והדיסקים המשוכפלים הקיימים מצורפים למכונות הווירטואליות כדי להפעיל את הצמתים.

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

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

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

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

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

   

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

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

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

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

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

   • ‫SQL Server 2016 Enterprise ו-Standard Edition
   • ‫SQL Server 2017 Enterprise ו-Standard Edition
   • ‫SQL Server 2019 Enterprise ו-Standard Edition
   • מהדורות Enterprise ו-Standard של SQL Server 2022

   המדריך משתמש במופע של אשכול מעבר לגיבוי בענן של SQL Server עם דיסק Hyperdisk Balanced High Availability.

   אם אתם לא צריכים תכונות של SQL Server Enterprise, אתם יכולים להשתמש במהדורת Standard של SQL Server:

   בגרסאות 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.

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

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

   כדי להגדיר רפליקציה של דיסקים ל-SQL Server בין שני אזורים, צריך קודם ליצור אשכול HA עם שני מופעים באזור מסוים. מופע אחד משמש כראשי, והמופע השני משמש כגיבוי. כדי לבצע את השלב הזה, פועלים לפי ההוראות במאמר הגדרת אשכול FCI של SQL Server עם מצב גישה מרובה לקריאה וכתיבה של Hyperdisk Balanced High Availability. במדריך הזה נעשה שימוש ב-us-central1 לאזור הראשי R1. אם פעלתם לפי השלבים במאמר הגדרת אשכול FCI של SQL Server עם מצב כתיבה מרובה של Hyperdisk Balanced High Availability, יצרתם שני מופעים של SQL Server באותו אזור (us-central1). פרסתם מופע ראשי של SQL Server‏ (node-1) ב-us-central1-a ומופע במצב המתנה (node-2) ב-us-central1-b.

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

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

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

      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
      
      gcloud compute resource-policies create disk-consistency-group multiwriter-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-2 \
      --zone=$REGION-b \
      --resource-policies=node-2-disk-const-grp
      
      gcloud compute disks add-resource-policies mw-datadisk-1 \
      --region=$REGION \
      --resource-policies=multiwriter-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-2-replica \
        --zone=$DR_REGION-b \
        --size=50 \
        --primary-disk=node-2 \
        --primary-disk-zone=$REGION-b
      
      gcloud compute disks create multiwriter-datadisk-1-replica \
        --replica-zones=$DR_REGION-a,$DR_REGION-b \
        --size=$PD_SIZE \
        --type=hyperdisk-balanced-high-availability \
        --access-mode READ_WRITE_MANY \
        --primary-disk=multiwriter-datadisk-1 \
        --primary-disk-region=$REGION
      
      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-2 \
        --zone=$REGION-b \
        --secondary-disk=node-2-replica \
        --secondary-disk-zone=$DR_REGION-b
      
      gcloud compute disks start-async-replication multiwriter-datadisk-1 \
        --region=$REGION \
        --secondary-disk=multiwriter-datadisk-1-replica \
        --secondary-disk-region=$DR_REGION
      
      gcloud compute disks start-async-replication witness \
        --zone=$REGION-c \
        --secondary-disk=witness-replica \
        --secondary-disk-zone=$DR_REGION-c
      

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

   סימולציה של תוכנית התאוששות מאסון (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/multiwriter-disk-const-grp \
      --zone=$REGION-c
      
      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. משנים את השם של מכונות ה-VM הקיימות כדי למנוע שמות כפולים בפרויקט.

      gcloud compute instances set-name witness \
      --new-name=witness-old \
      --zone=$REGION-c
      
      gcloud compute instances set-name node-1 \
      --new-name=node-1-old \
      --zone=$REGION-a
      
      gcloud compute instances set-name node-2 \
      --new-name=node-2-old \
      --zone=$REGION-b
      

   5. יצירת מכונות וירטואליות באזור DR באמצעות הדיסקים המשניים. למכונות הווירטואליות האלה יהיה כתובת ה-IP של המכונה הווירטואלית המקורית.

      NODE1IP=$(gcloud compute instances describe node-1-old --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
      NODE2IP=$(gcloud compute instances describe node-2-old --zone $REGION-b --format=value\(networkInterfaces[0].networkIP\))
      WITNESSIP=$(gcloud compute instances describe witness-old --zone $REGION-c --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=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional
      
      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
      
      gcloud compute instances create node-2 \
        --zone=$DR_REGION-b \
        --machine-type $MACHINE_TYPE \
        --network=$DRVPC_NAME \
        --subnet=$DRSUBNET_NAME \
        --private-network-ip $NODE2IP\
        --disk=boot=yes,device-name=node-2-replica,mode=rw,name=node-2-replica \
        --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional
      
      

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

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

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

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

   4. בתפריט הקובץ, בוחרים באפשרות קובץ > חדש > שאילתה עם החיבור הנוכחי.

      USE [bookshelf];
      SELECT * FROM Books;
      

   הסרת המשאבים

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

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

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