במדריך הזה מוסבר איך להפעיל שכפול אסינכרוני של דיסקים קשיחים (PD Async Replication) בשני אזורי Google Cloud כפתרון להתאוששות מאסון (DR), ואיך להפעיל את מופעי ה-DR במקרה של אסון.
לצורך המסמך הזה, אסון הוא אירוע שבו אשכול של מסד נתונים ראשי בזמינות גבוהה (HA) נכשל או הופך ללא זמין. מסד נתונים ראשי עלול להיכשל אם האזור שבו הוא ממוקם נכשל או הופך ללא נגיש.
המדריך הזה מיועד למומחי ארכיטקטורת מסדי נתונים, לאדמינים ולמהנדסים.
מטרות
- הפעלת שכפול אסינכרוני של Persistent Disk לכל הצמתים של אשכול קבוצת הזמינות של SQL Server AlwaysOn שפועלים ב- Google Cloud.
- מדמים אירוע אסון ומבצעים תהליך מלא של התאוששות מאסון כדי לאמת את ההגדרה של התאוששות מאסון.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.
כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.
לפני שמתחילים
במדריך הזה תצטרכו פרויקט Google Cloud . אפשר ליצור פרויקט חדש או לבחור פרויקט שכבר יצרתם:
-
בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
-
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (
roles/resourcemanager.projectCreator), שכולל את ההרשאהresourcemanager.projects.create. איך מקצים תפקידים
-
במסוף Google Cloud , מפעילים את Cloud Shell.
התאוששות מאסון ב- Google Cloud
ב- Google Cloud, התאוששות מאסון (DR) היא מתן המשכיות של העיבוד, במיוחד כשקורה כשל באזור או כשאין גישה לאזור. יש כמה אפשרויות לפריסת אתר DR, והן ייקבעו לפי הדרישות של יעד נקודת ההתאוששות (RPO) ויעד משך ההתאוששות (RTO). במדריך הזה נסביר על אחת מהאפשרויות שבהן דיסקים של מכונות וירטואליות (VM) משוכפלים מהאזור הראשי לאזור DR.
תוכנית התאוששות מאסון (DR) לשכפול אסינכרוני של Persistent Disk
רפליקציה אסינכרונית של דיסקים לאחסון מתמיד (PD Async Replication) מספקת רפליקציה של אחסון בלוקים עם RPO ו-RTO נמוכים להתאוששות מאסון (DR) פעילה-פסיבית בין אזורים.
שכפול אסינכרוני של נתונים (PD Async Replication) הוא אפשרות אחסון שמספקת שכפול אסינכרוני של נתונים בין שני אזורים. במקרה הלא סביר של הפסקה זמנית בשירות באזור, רפליקציה אסינכרונית של PD מאפשרת לבצע מעבר לגיבוי בעת כשל של הנתונים לאזור משני ולהפעיל מחדש את עומסי העבודה באזור הזה.
רפליקציה אסינכרונית של PD משכפלת נתונים מדיסק שמצורף לעומס עבודה פעיל שנקרא הדיסק הראשי, לדיסק נפרד שנמצא באזור אחר. הדיסק שמקבל את הנתונים המשוכפלים נקרא הדיסק המשני.
כדי לוודא שהעותקים של כל הדיסקים שמצורפים לכל צומת של SQL Server יכילו נתונים מאותה נקודת זמן, הדיסקים מתווספים לקבוצת עקביות. קבוצות עקביות מאפשרות לכם לבצע DR ובדיקות DR בכמה דיסקים.
ארכיטקטורה של תוכנית התאוששות מאסון (DR)
בתרשים הבא מוצגת ארכיטקטורה מינימלית של PD Async Replication שתומכת בזמינות גבוהה של מסד נתונים באזור ראשי, וברפליקציה של דיסקים מהאזור הראשי לאזור DR.
איור 1. ארכיטקטורה של תוכנית התאוששות מאסון (DR) עם Microsoft SQL Server ו-PD Async Replication
הארכיטקטורה הזו פועלת באופן הבא:
- שני מופעים של Microsoft SQL Server, מופע ראשי ומופע בהמתנה, הם חלק מקבוצת זמינות וממוקמים באותו אזור (R1) אבל באזורים שונים (אזורים A ו-B). שני המקרים ב-R1 מתאמים את המצבים שלהם באמצעות מצב של ביצוע פעולות באופן סינכרוני. השימוש במצב סינכרוני נובע מהתמיכה שלו בזמינות גבוהה ומהשמירה על מצב נתונים עקבי.
- דיסקים משני צמתי ה-SQL מתווספים לקבוצות עקביות ומשוכפלים לאזור DR R2. הנתונים משוכפלים באופן אסינכרוני על ידי התשתית הבסיסית.
- רק דיסקים משוכפלים לאזור R2. במהלך DR, נוצרות מכונות וירטואליות חדשות והדיסקים המשוכפלים הקיימים מצורפים למכונות הווירטואליות כדי להפעיל את הצמתים.
תהליך התאוששות מאסון (DR)
תהליך ה-DR מתחיל כשאזור הופך ללא זמין. תהליך ה-DR קובע את השלבים התפעוליים שצריך לבצע, באופן ידני או אוטומטי, כדי לצמצם את ההשפעה של הכשל באזור ולהקים מופע ראשי פעיל באזור זמין.
תהליך בסיסי של DR למסד נתונים כולל את השלבים הבאים:
- האזור הראשון (R1), שבו פועל מופע מסד הנתונים הראשי, הופך ללא זמין.
- צוות התפעול מזהה את האסון ומאשר אותו באופן רשמי, ומחליט אם נדרשת יתירות כשל.
- אם נדרש מעבר לגיבוי, שכפול הדיסק מהאזור הראשי לאזור DR מופסק. מכונה וירטואלית חדשה נוצרת מההעתקים של הדיסק ומופעלת.
- מסד הנתונים הראשי החדש באזור DR (R2) עובר אימות ומועבר למצב אונליין, מה שמאפשר קישוריות.
- המשתמשים ממשיכים את העיבוד במסד הנתונים הראשי החדש ומקבלים גישה למופע הראשי ב-R2.
למרות שהתהליך הבסיסי הזה יוצר שוב מסד נתונים ראשי תקין, הוא לא יוצר ארכיטקטורת זמינות גבוהה מלאה, שבה למסד הנתונים הראשי החדש יש צומת המתנה.
איור 2. פריסת SQL Server אחרי תוכנית התאוששות מאסון (DR) באמצעות שכפול אסינכרוני של דיסק מתמשך
חזרה לאזור משוחזר
כשאזור הראשי (R1) חוזר למצב אונליין, אפשר לתכנן ולהפעיל את תהליך החזרה למצב תקין. תהליך החזרה למצב תקין כולל את כל השלבים שמפורטים במדריך הזה, אבל במקרה הזה, R2 הוא המקור ו-R1 הוא אזור השחזור.
בחירה של מהדורת 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 עם זמינות גבוהה, ומספיק לכם מופע יחיד של מסד נתונים כראשי, אתם יכולים להשתמש בגרסאות הבאות של 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 פעם אחת לכל אזור כדי לוודא שהיא תישאר זמינה אם אזור אחר לא יהיה זמין.
הגדרת התאוששות מאסון (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.
הפעלת שכפול אסינכרוני של דיסקים
אחרי שיוצרים ומגדירים את כל המכונות הווירטואליות, צריך ליצור קבוצת עקביות לכל הדיסקים שמצורפים למכונות הווירטואליות כדי להפעיל העתקה של דיסקים בין אזורים. הנתונים מועתקים מדיסקים של מקור לדיסקים ריקים חדשים באזור המיועד.
יוצרים קבוצת אפליקציות עקביות גם לצומתי ה-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
מוסיפים את הדיסקים מהמכונות הווירטואליות הראשיות וממכונות ההמתנה לקבוצות העקביות המתאימות.
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
יצירת דיסקים משניים ריקים באזור המקביל
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
מתחילים לשכפל את הדיסק. הנתונים משוכפלים מהדיסק הראשי לדיסק הריק החדש שנוצר באזור 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 ומצרפים אליהן את הדיסקים המשוכפלים. כדי לפשט את המעבר לגיבוי, אפשר להשתמש בענן וירטואלי פרטי (VPC) אחר באזור DR לצורך שחזור, כדי להשתמש באותה כתובת IP.
לפני שמתחילים בגיבוי בעת כשל, מוודאים ש-node-1 הוא הצומת הראשי עבור קבוצת הזמינות AlwaysOn שיצרתם. כדי למנוע בעיות בסנכרון הנתונים, צריך להפעיל את בקר הדומיין ואת הצומת הראשי של SQL Server, כי שני הצמתים מוגנים על ידי שתי קבוצות עקביות נפרדות.
כדי לדמות הפסקת חשמל, פועלים לפי השלבים הבאים:
יוצרים 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
הפסקת שכפול הנתונים.
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
מפסיקים את המכונות הווירטואליות של המקור באזור הראשי.
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
יצירת מכונות וירטואליות באזור 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
אחרי שיוצרים מכונות וירטואליות, צריך לוודא שהמסד נתונים שוחזר בהצלחה ושהשרת פועל כמצופה. כדי לבדוק את מסד הנתונים, מריצים שאילתת בחירה ממסד הנתונים ששוחזר.
- מתחברים למכונת ה-SQL Server הווירטואלית באמצעות Remote Desktop.
- פותחים את SQL Server Management Studio.
- בתיבת הדו-שיח 'התחברות לשרת', מוודאים ששם השרת מוגדר ל-
NODE-1ולוחצים על התחברות. בתפריט הקובץ, בוחרים באפשרות קובץ > חדש > שאילתה עם החיבור הנוכחי.
USE [bookshelf]; SELECT * FROM Books;
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה:
מחיקת הפרויקט
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
המאמרים הבאים
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.