הגדרה של אשכול SQL Server ב-Linux עם קבוצות זמינות Always On ו-Pacemaker

במדריך הזה מוסבר איך לפרוס מערכת מסדי נתונים של Microsoft SQL Server ב-Linux באמצעות קבוצת זמינות Always On ‏ (AOAG) ו-Pacemaker כפתרון לזמינות גבוהה (HA) ולהתאוששות מאסון (DR). לצורך המסמך הזה, אסון הוא אירוע שבו מסד נתונים ראשי נכשל או הופך ללא זמין.

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

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

מטרות

פריסת SQL Server ב-Linux
יצירת קבוצת זמינות Always On לזמינות גבוהה ולתוכנית התאוששות מאסון (DR)
התקנה והגדרה של Pacemaker לניהול יתירות כשל של אשכול SQL Server
הגדרת מאזן עומסים להעברת תנועה לקבוצת הזמינות עם SQL Server
הגדרת גידור STONITH (Shoot The Other Node In The Head) כדי להבטיח את שלמות ה-HA
ביצוע בדיקת מעבר לגיבוי (failover) כדי לוודא שאשכול SQL Server פועל כמצופה

עלויות

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

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

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

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

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
Verify that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
הכנת הפרויקט והרשת

כדי להכין את פרויקט Google Cloud ו-VPC לפריסה של קבוצות זמינות של SQL Server Always On, מבצעים את הפעולות הבאות:
1. במסוף Google Cloud , לוחצים על הלחצן Activate Cloud Shell כדי לפתוח את Cloud Shell.
  
  כניסה ל Google Cloud מסוף
2. מגדירים את מזהה הפרויקט שמוגדר כברירת מחדל:
```
gcloud config set project PROJECT_ID
```
  מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .
3. הגדרת אזור ברירת המחדל:
```
gcloud config set compute/region REGION
```
  מחליפים את REGION במזהה האזור שבו רוצים לבצע פריסה.
4. הגדרת אזור ברירת המחדל:
```
gcloud config set compute/zone ZONE
```
  מחליפים את ZONE במזהה של האזור שבו רוצים לבצע פריסה. התחום צריך להיות תחום תקין באזור שצוין בשלב הקודם.
יצירת מכונות וירטואליות של Linux

כדי להשיג זמינות גבוהה (HA) וקוורום עבור אשכול SQL Server, פורסים שלוש מכונות וירטואליות (VM) של Linux לאירוח אשכול SQL Server.
1. מאתחלים את המשתנים הבאים:
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```
2. יוצרים את מכונות ה-VM של Linux:
```
gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-a/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-b/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-c/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write
```
  מחליפים את SUBNET_NAME בשם של רשת המשנה של ה-VPC.
3. מעדכנים את קובץ המארחים ב-node-1, ב-node-2 וב-node-3:
  
  הערה: לשימוש בסביבת ייצור, רזולוציית הדומיין צריכה להיות מנוהלת על ידי שרת DNS ייעודי.
  1. מתחברים לכל אחת מהמכונות הווירטואליות באמצעות SSH. מידע נוסף זמין במאמר בנושא התחברות למכונות וירטואליות של Linux.
  2. פותחים את קובץ המארחים לעריכה.
    sudo vi /etc/hosts
  3. מוצאים את כתובת ה-IP הפנימית של כל מכונת Linux וירטואלית ומצרפים את רשומות המארחים לתחתית הקובץ.
    
    מעבר אל Compute Engine
    NODE1_INTERNAL_IP node-1 NODE2_INTERNAL_IP node-2 NODE3_INTERNAL_IP node-3
    מחליפים את NODE1_INTERNAL_IP, NODE2_INTERNAL_IP ו-NODE3_INTERNAL_IP בכתובת ה-IP הפנימית של כל מכונת Linux וירטואלית.
4. בודקים את התקשורת בין המכונות הווירטואליות. כל המכונות הווירטואליות שמשתתפות בקבוצת הזמינות Always On צריכות להיות מסוגלות לתקשר עם מכונות וירטואליות אחרות:
  1. חוזרים לכל מכונת VM של Linux, מריצים את הפקודות מכל מכונת VM ומוודאים שכל מכונות ה-VM יכולות לתקשר ביניהן.
    ping -c 4 node-1 ping -c 4 node-2 ping -c 4 node-3
התקנה והגדרה של SQL Server

מורידים, מתקינים ומגדירים את מנוע SQL Server בשלוש מכונות וירטואליות של Linux שישתתפו בקבוצת הזמינות Always On.
1. מתחברים ל-SSH אל node-1, node-2 ו-node-3 ומבצעים את השלבים הבאים:
  1. מייבאים את המפתחות של המאגר הציבורי.
    wget -qO- https://packages.microsoft.com/keys/microsoft.asc \ | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
  2. רושמים את מאגר SQL Server Ubuntu.
    sudo add-apt-repository \ "$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"
  3. מעדכנים את קובצי אינדקס החבילות ומתקינים את SQL Server.
    sudo apt-get update sudo apt-get install -y mssql-server
2. מגדירים את SQL Server:
  1. מריצים את הכלי mssql-conf.
    sudo /opt/mssql/bin/mssql-conf setup
  2. בוחרים במהדורת Developer של SQL Server ומאשרים את הסכם הרישיון.
    
    מהדורת המפתחים כוללת את כל התכונות של מהדורת Enterprise, אבל אפשר להשתמש בה רק בסביבות שאינן סביבות ייצור. מידע נוסף זמין על מהדורות SQL Server ועל רישיונות Microsoft.
    
    הערה: לכל מכונת VM נדרש רישיון ל-SQL Server. אם אתם מפעילים שרתי אפליקציות של מיקרוסופט, ניוד רישיונות באמצעות Software Assurance עוזר לכם לעבור אל Google Cloud. מידע נוסף זמין במאמר שימוש בניוד רישיונות עם אפליקציות שרת של מיקרוסופט. אם אתם לא מביאים רישיון משלכם ורוצים לרכוש רישיון דרך Google (תשלום לפי שימוש), אתם צריכים לפעול לפי השלבים במאמר הוספת רישיון ל-SQL Server לדיסק אתחול כדי לוודא שאתם רוכשים רישיון לכל מופע של מכונה וירטואלית.
  3. מציינים סיסמה לחשבון SA.
  4. מוודאים ששירות mssql-server פועל.
    systemctl status mssql-server --no-pager
3. אם הפעלתם חומת אש במכונות הווירטואליות, אתם צריכים לפתוח את חומת האש עבור SQL Server:
  1. מריצים את הפקודה הבאה כדי לבדוק אם Uncomplicated Firewall מותקן ומופעל.
    sudo ufw status
  2. אם הסטטוס הוא active, מריצים את הפקודות הבאות כדי לפתוח את היציאות.
    sudo ufw allow 1433 sudo ufw allow 5022 sudo ufw reload
    הערה: אם אתם משתמשים ביציאות אחרות עבור SQL Server או עבור נקודת הקצה של קבוצת הזמינות, צריך לשנות את כללי חומות האש בהתאם.
התחברות ל-SQL Server

בשלב הזה, SQL Server מותקן. כדי להתחבר אליו, יוצרים מכונת Windows באותו VPC, מתקינים את SQL Server Management Studio ‏ (SSMS) כדי להתחבר למופע SQL Server שנוצר לאחרונה במכונות הווירטואליות:
1. יוצרים מכונה וירטואלית של Windows:
  1. חוזרים אל Cloud Shell ומריצים את הפקודה הבאה.
    gcloud compute instances create node4 \ --project=PROJECT_ID \ --zone ZONE \ --subnet SUBNET_NAME \ --machine-type=n2-standard-4 \ --create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced
2. מתחברים למכונה הווירטואלית של Windows ב-node-4 באמצעות Remote Desktop:
3. מעדכנים את קובץ המארחים ב-node-4:
  1. פותחים את פנקס הרשימות במצב אדמין.
  2. לוחצים על קובץ > פתיחה ופותחים את קובץ המארחים.
    c:\Windows\System32\drivers\etc\hosts
  3. מוסיפים את רשומות המארח לתחתית הקובץ.
    NODE1_INTERNAL_IP node-1 NODE2_INTERNAL_IP node-2 NODE3_INTERNAL_IP node-3
    מחליפים את NODE1_INTERNAL_IP, NODE2_INTERNAL_IP ו-NODE3_INTERNAL_IP בכתובות ה-IP הפנימיות המתאימות של כל מכונה וירטואלית.
  4. שומרים ויוצאים.
4. מאמתים את הקישוריות למכונות ה-VM של Linux:
  1. מתחברים ל-VM של Windows ב-node-4
  2. לוחצים על הלחצן התחלה ומזינים powershell בסרגל החיפוש.
  3. לוחצים כדי לפתוח את אפליקציית Windows PowerShell ISE.
  4. בודק את הקישוריות על ידי הפעלת הפקודות הבאות.
    ping node-1 ping node-2 ping node-3
5. כדי להתקין את Microsoft SQL Server Management Studio‏ (SSMS), מבצעים את השלבים הבאים:
  1. מתחברים למכונת Windows הווירטואלית ב-node-4 באמצעות Remote Desktop.
  2. במהלך סשן RDP, מצמצמים את כל החלונות ומפעילים את אפליקציית Windows PowerShell ISE.
  3. בשורת הפקודה של PowerShell, מורידים ומריצים את קובץ ההתקנה של SSMS.
    Start-BitsTransfer ` -Source "https://aka.ms/ssmsfullsetup" ` -Destination "$env:Temp\ssms-setup.exe" & $env:Temp\ssms-setup.exe
  4. בתוכנת ההתקנה של SSMS, לוחצים על Install (התקנה).
  5. מאשרים את ההנחיה כדי לאפשר ביצוע שינויים.
  6. בסיום ההתקנה, לוחצים על הפעלה מחדש כדי להפעיל מחדש את המחשב המרוחק. הפעולה הזו תסגור את סשן ה-RDP.
6. מתחברים למכונה של SQL Server בצומת node-1:
  1. חוזרים אל node-4 VM באמצעות RDP.
  2. פותחים את SSMS ומתחברים אל node-1 באמצעות הפרמטרים הבאים.
    Server name: node-1 Authentication: SQL Server Authentication Login: sa
    מידע נוסף זמין במאמר חיבור למופע SQL Server באמצעות מאמרי העזרה של SQL Server Management Studio.
  3. מזינים את הסיסמה של חשבון SA שנוצר במהלך ההתקנה.
  4. בוחרים באפשרות Trust server certificate (הוספת אישור שרת לרשימת האישורים המהימנים).
  5. לוחצים על Connect.
הפעלה של קבוצת זמינות Always On

ב-Linux, צריך קודם ליצור קבוצת זמינות כדי להוסיף אותה כמשאב לניהול על ידי Pacemaker:
1. מפעילים את התכונה Always On availability group (קבוצת זמינות Always On) בכל מופע של SQL Server שמשתתף בקבוצת הזמינות. מריצים את הפקודות הבאות ב-node-1, ב-node-2 וב-node-3:
  
  הערה: כדי שהשינויים ייכנסו לתוקף, צריך להפעיל מחדש את השירות mssql-server.
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
2. מתחברים למופע שהוא המארח הראשי בקבוצת הזמינות באמצעות SSMS:
  
  טיפ: מומלץ לבחור ב-node-1 כמארח הראשי.
  1. פותחים חלון חדש של שאילתה.
  2. מריצים את קטע הקוד הבא כדי ליצור מפתח הצפנה, אישור ומפתח פרטי.
    
    טיפ: חשוב לבחור סיסמאות חזקות למפתח ההצפנה ולמפתח הפרטי. חשוב לזכור את הסיסמאות האלה כי תצטרכו להשתמש בהן בהמשך.
    הערה: הסיסמה צריכה להיות באורך של 8 תווים לפחות, ולכלול תווים משלוש מתוך ארבע הקבוצות הבאות: אותיות רישיות, אותיות קטנות, ספרות בבסיס 10 וסמלים.
    USE MASTER; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD'; CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert'; BACKUP CERTIFICATE my_ag_certificate TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/my_ag_certificate.pvk', ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD' );
    מחליפים את ENCRYPTION_KEY_PASSWORD ואת PRIVATE_KEY_PASSWORD בסיסמאות של מפתח ההצפנה והמפתח הפרטי.
העברה של קובצי האישור והמפתח

צריך להעביר את קובצי האישור והמפתח שנוצרו בשלבים הקודמים לצמתים המשניים של SQL Server. יש כמה שיטות להעברת קובצי האישור והמפתח לצמתים המשניים ב-node-2 וב-node-3.

אפשרויות העברה נוספות מפורטות במאמר העברת קבצים למכונות וירטואליות של Linux

העברת קובצי האישור והמפתח באמצעות Cloud Storage

יוצרים Cloud Storage כדי להעביר קבצים מהצמתים הראשיים של האשכול לצמתים המשניים.
1. יוצרים קטגוריה של Cloud Storage:
  1. חוזרים אל Cloud Shell ומריצים את הפקודה הבאה:
    gcloud storage buckets create gs://BUCKET_NAME \ --project=PROJECT_ID \ --location=REGION \ --public-access-prevention
    מחליפים את BUCKET_NAME בשם הקטגוריה שרוצים ליצור. מחליפים את PROJECT_ID במזהה הפרויקט ואת REGION במזהה האזור שבו רוצים לפרוס את הקטגוריה. Google Cloud
  למידע נוסף, ראו יצירת קטגוריות.
2. חוזרים ל-SSH ב-node-1, ב-node-2 וב-node-3 כדי להפעיל את Google Cloud CLI:
  1. מריצים את הפקודה הבאה כדי לאתחל את Google Cloud CLI.
    gcloud init
  2. בוחרים באפשרות option [1] כדי להשתמש בחשבון השירות שהותקן מראש.
  3. מזינים את שם הפרויקט.
  4. מזינים n לשאלה כדי להגדיר את אזור ברירת המחדל ואת האזור.
3. חוזרים אל node-1 כדי להעתיק את הקבצים ל-Cloud Storage:
  1. מעלים את שני הקבצים החדשים שנוצרו ל-Cloud Storage באמצעות הפקודות הבאות.
    sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/ sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
    מחליפים את BUCKET_NAME בשם הקטגוריה שנוצרה.
4. חוזרים אל node-2 ואל node-3 כדי להעתיק את הקבצים מהאחסון בענן:
  1. מורידים את שני הקבצים מ-Cloud Storage אל node-2.
    sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/ sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
    מחליפים את BUCKET_NAME בשם הקטגוריה שנוצרה.
  2. כדי לשנות את הבעלות על הקבצים ב-node-2 וב-node-3, מריצים את הפקודה במעטפת root.
    chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.* chmod 660 /var/opt/mssql/data/my_ag_certificate.*
    טיפ: זכור לצאת ממעטפת השורש לאחר הפעלת הפקודות.
הגדרת נקודת קצה של שיקוף מסד נתונים

בקטע הזה תיצרו את נקודת הקצה של מסד הנתונים באמצעות מפתח הצפנה ואישור שמשותפים לכל צומת באשכול SQL Server, כדי להבטיח שכפול מאובטח של הנתונים.
1. חוזרים למכונה הווירטואלית של Windows ב-node-4 כדי ליצור את נקודות הקצה של שיקוף מסד הנתונים:
  1. מתחברים למסדי הנתונים של SQL Server ב-node-1, ב-node-2 וב-node-3 באמצעות SSMS. פועלים לפי השלבים שבקטע התחברות ל-SQL Server באמצעות node-1, node-2 ו-node-3 כשם השרת והסיסמאות המתאימות שהגדרתם לחשבון SA.
  2. יוצרים את האישור במכונות הווירטואליות המשניות node-2 ו-node-3 מהקבצים שהועתקו. משתמשים בסיסמאות שסיפקתם כשנוצר האישור והמפתח בצומת הראשי.
    USE MASTER; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD'; CREATE CERTIFICATE my_ag_certificate FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/my_ag_certificate.pvk', DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD' );
    מחליפים את ENCRYPTION_KEY_PASSWORD ואת PRIVATE_KEY_PASSWORD בסיסמאות של מפתח ההצפנה והמפתח הפרטי.
  3. חוזרים ל-SSMS כדי ליצור נקודות קצה של שיקוף מסד נתונים על ידי הפעלת פקודת T-SQL עבור node-1,‏ node-2 ו-node-3.
    
    הערה: יציאת ההאזנה שמוגדרת כברירת מחדל היא 5022, אבל אפשר להשתמש בכל יציאה אחרת שזמינה.
    CREATE ENDPOINT [my_ag_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING ( ROLE = ALL, AUTHENTICATION = CERTIFICATE my_ag_certificate, ENCRYPTION = REQUIRED ALGORITHM AES ); ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
יצירה והגדרה של קבוצת הזמינות Always On

לאחר מכן, יוצרים את קבוצת הזמינות Always On של SQL Server באמצעות SQL Server Management Studio ומשתמשים בנקודות הקצה שנוצרו קודם לשכפול.

הערה: כדי ליצור קבוצת זמינות Always On, צריך מסד נתונים לשכפול. במדריך הזה תיצרו מסד נתונים לדוגמה בשם bookshelf. אחרי שיוצרים את קבוצת הזמינות AlwaysOn, אפשר להוסיף או להסיר ממנה מסדי נתונים נוספים.
1. חוזרים למכונת ה-VM של Windows ופותחים את SSMS:
  1. מתחברים למנוע מסד הנתונים של SQL Server ב-node-1 ופותחים חלון שאילתה חדש.
2. יוצרים מסד נתונים ומגבים אותו לקראת יצירת רפליקה:
```
USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';
```
3. יוצרים את קבוצת הזמינות Always On:
  1. מריצים את פקודת T-SQL הבאה ב-SSMS ב-node-1, ב-node-2 וב-node-3. כך תוכלו לוודא שנקודות הקצה מופעלות ושרת SQL בכל צומת מוכן לשכפול נתונים.
    IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0 BEGIN ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED END GO IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health') BEGIN ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON); END IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health') BEGIN ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START; END GO
  2. מריצים את פקודת T-SQL הבאה ב-node-1 כדי ליצור את קבוצת הזמינות.
    USE [master] GO CREATE AVAILABILITY GROUP [aoag1] WITH ( AUTOMATED_BACKUP_PREFERENCE = SECONDARY, DB_FAILOVER = OFF, DTC_SUPPORT = NONE, CLUSTER_TYPE = EXTERNAL, REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0 ) FOR DATABASE [bookshelf] REPLICA ON N'node-1' WITH ( ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)), N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)), N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO) ); GO
  3. מריצים את פקודת T-SQL הבאה ב-node-2 וב-node-3 לכל מופע של SQL Server כדי להצטרף לקבוצת הזמינות החדשה.
    ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL); GO ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE; GO
  יצרתם מסד נתונים חדש בשם bookshelf והוספתם אותו לקבוצת זמינות חדשה בשם aoag1 במופע של SQL Server שפועל ב-node-1. המופעים Node-2 ו-node-3 נוספו לקבוצת הזמינות, והנתונים במסד הנתונים bookshelf ישוכפלו באופן סינכרוני במופעים של SQL Server בכל שלושת הצמתים.
התקנה והגדרה של Pacemaker

‫Pacemaker היא תוכנה לניהול משאבים של זמינות גבוהה בקוד פתוח, שמשמשת עם מנוע האשכול Corosync. בקטע הזה מתקינים ומגדירים את Pacemaker בכל אחת מהמכונות הווירטואליות.

יצירת התחברות ל-SQL Server עבור מנהל האשכולות של Pacemaker

בקטע הזה יוצרים חשבון חדש ב-SQL Server כדי ש-Pacemaker יוכל להתחבר לכל מופע של SQL Server ולנהל את קבוצת הזמינות.
1. מריצים את פקודת T-SQL הבאה ב-node-1, ב-node-2 וב-node-3:
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
  מחליפים את PACEMAKER_LOGIN_PASSWORD בסיסמה לחשבון של קוצב הלב.
2. מריצים את פקודת T-SQL כדי להעניק לקבוצת הזמינות את הרשאות הכניסה של Pacemaker:
```
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO
```
3. חוזרים ל-SSH ב-node-1, ב-node-2 וב-node-3 כדי להריץ את הפקודות לשמירת פרטי הכניסה והסיסמה של Pacemaker בתיקיית הסודות של SQL Server:
```
echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd
```
  מחליפים את PACEMAKER_LOGIN_PASSWORD בסיסמה של חשבון קוצב הלב.
התקנה של Pacemaker

לאחר מכן, מתקינים את Pacemaker ומגדירים חשבון כניסה בכל המכונות הווירטואליות של Linux לניהול משאבים.
1. פותחים יציאות בחומת האש עבור Pacemaker:
  1. כדי לבדוק אם Uncomplicated Firewall מותקן ומופעל, מריצים את הפקודה הבאה ב-node-1, ב-node-2 וב-node-3.
    sudo ufw status
  2. אם ufw מופעל, פותחים את היציאות של חומת האש ב-node-1, ב-node-2 וב-node-3.
    sudo ufw allow 2224/tcp sudo ufw allow 3121/tcp sudo ufw allow 5405/udp sudo ufw allow 21064/tcp sudo ufw allow 1433/tcp sudo ufw allow 5022/tcp sudo ufw reload
    הערה: אם אתם משתמשים ביציאות אחרות עבור SQL Server או עבור נקודת הקצה של קבוצת הזמינות, צריך לשנות את כללי חומת האש בהתאם
2. מתקינים את Pacemaker ב-node-1, ב-node-2 וב-node-3:
```
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs
```
3. מגדירים סיסמה חדשה למשתמש hacluster ב-node-1, ב-node-2 וב-node-3:
  
  הערה: צריך להגדיר את אותה סיסמה בכל שלושת הצמתים. תצטרכו את הסיסמה הזו בהמשך ההגדרה.
```
sudo passwd hacluster
```
הגדרת Corosync

עכשיו צריך להגדיר את Corosync כדי לנהל את החברות באשכול ואת העברת ההודעות באשכול.
1. יוצרים מפתח אימות ל-Corosync ב-node-1:
```
sudo corosync-keygen
```
2. משנים את קובץ התצורה של Corosync:
  1. חוזרים אל node-1 ומשנים את הקובץ corosync.conf.
    sudo vi /etc/corosync/corosync.conf
  2. מעדכנים את הקטעים המסומנים. אחרי העריכה, הקובץ צריך להיראות כמו בדוגמה הבאה.
    # Please read the corosync.conf.5 manual page totem { version: 2 # Corosync itself works without a cluster name, but DLM needs one. # The cluster name is also written into the VG metadata of newly # created shared LVM volume groups, if lvmlockd uses DLM locking. cluster_name: my_agcluster # crypto_cipher and crypto_hash: Used for mutual node authentication. # If you choose to enable this, then do remember to create a shared # secret with "corosync-keygen". # enabling crypto_cipher, requires also enabling of crypto_hash. # crypto works only with knet transport transport: udpu crypto_cipher: none crypto_hash: none } logging { # Log the source file and line where messages are being # generated. When in doubt, leave off. Potentially useful for # debugging. fileline: off # Log to standard error. When in doubt, set to yes. Useful when # running in the foreground (when invoking "corosync -f") to_stderr: yes # Log to a log file. When set to "no", the "logfile" option # must not be set. to_logfile: yes logfile: /var/log/corosync/corosync.log # Log to the system log daemon. When in doubt, set to yes. to_syslog: yes # Log debug messages (very verbose). When in doubt, leave off. debug: off # Log messages with time stamps. When in doubt, set to hires (or on) #timestamp: hires logger_subsys { subsys: QUORUM debug: off } } quorum { # Enable and configure quorum subsystem (default: off) # see also corosync.conf.5 and votequorum.5 provider: corosync_votequorum } nodelist { # Change/uncomment/add node sections to match cluster configuration node { # Hostname of the node name: node-1 # Cluster membership node identifier nodeid: 1 # Address of first link ring0_addr: NODE1_INTERNAL_IP # When knet transport is used it's possible to define up to 8 links #ring1_addr: 192.168.1.1 } node { name: node-2 nodeid: 2 ring0_addr: NODE2_INTERNAL_IP } node { name: node-3 nodeid: 3 ring0_addr: NODE3_INTERNAL_IP } # ... }
    מחליפים את NODE1_INTERNAL_IP, NODE2_INTERNAL_IP ו-NODE3_INTERNAL_IP בכתובות ה-IP הפנימיות של כל צומת.
העברת קובצי ההגדרות באמצעות Cloud Storage
1. מעלים את מפתח האימות שנוצר ואת קובצי התצורה של corosync מ-node-1 לקטגוריה של Cloud Storage:
```
sudo gcloud storage cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gcloud storage cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
  מחליפים את BUCKET_NAME בשם הקטגוריה שיצרתם קודם.
2. מורידים את קובצי ה-Authkey והתצורה אל node-2 ו-node-3:
```
sudo gcloud storage cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gcloud storage cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
  מחליפים את BUCKET_NAME בשם הקטגוריה שאליה הועברו קובצי ההגדרות של Corosync.
3. מעדכנים את ההרשאות של הקבצים ב-node-2 וב-node-3:
```
sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf
```
הפעלה מחדש ואימות של התקשורת בין הצמתים
1. מפעילים מחדש את שירותי Pacemaker ו-Corosync ב-node-1, ב-node-2 וב-node-3:
```
sudo systemctl restart pacemaker corosync
```
2. מריצים את הפקודה ב-node-1 כדי לאשר את הסטטוס של האשכול:
```
sudo crm status
```
  כל שלושת הצמתים צריכים להיות במצב אונליין.
הגדרת האשכול

בשלב הבא, תגדירו את אשכול Pacemaker על ידי יצירת משאב חדש לקבוצת הזמינות SQL Server Always On.
1. מריצים את הפקודה הבאה ב-node-1 כדי להגדיר את מאפייני האשכול:
```
sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true
```
  מידע נוסף מופיע במאמר בנושא אפשרויות של אשכול.
2. מריצים את הפקודה ב-node-1 כדי לתת הרשאה לצמתים באשכול. להשתמש בסיסמה שהוגדרה בעבר לחשבון hacluster:
```
sudo pcs cluster auth -u hacluster
```
  כל שלושת הצמתים צריכים להיות מאושרים.
3. מתקינים סוכן משאבים של SQL Server לשילוב עם Pacemaker ב-node-1, ב-node-2 וב-node-3:
```
sudo apt-get install mssql-server-ha
```
4. חוזרים אל node-1 ויוצרים משאב של קבוצת זמינות באשכול:
  1. מריצים את Cluster Resource Manager.
    sudo crm
  2. מקלידים configure כדי להיכנס לתפריט ההגדרות.
  3. מזינים את ההגדרה הבאה.
    primitive aoag1-cluster \ ocf:mssql:ag \ params ag_name="aoag1" \ meta failure-timeout=60s \ op start timeout=60s \ op stop timeout=60s \ op promote timeout=60s \ op demote timeout=10s \ op monitor timeout=60s interval=10s \ op monitor timeout=60s on-fail=demote interval=11s role="Master" \ op monitor timeout=60s interval=12s role="Slave" \ op notify timeout=60s ms ms-ag1 aoag1-cluster \ meta master-max="1" master-node-max="1" clone-max="3" \ clone-node-max="1" notify="true"
  4. מקלידים commit כדי לשמור את השינויים.
    
    הערה: תוצג אזהרה שלא הוגדר כלל גידור. אפשר להתעלם מההודעה הזו. בשלב מאוחר יותר נגדיר כלל גידור.
  5. מקלידים exit כדי לצאת ממנהל המשאבים של האשכול.
  6. מאמתים את ההגדרה.
    sudo crm status
    אפשר לראות ש-node-1 קודם לצומת הראשי. צריך להגדיר את Node-2 ו-node-3 כצמתים משניים.
הגדרת מאזן עומסים ומאזין של קבוצת זמינות

בקטע הזה יוצרים כתובת IP וירטואלית ומשאב לבדיקת תקינות באשכול באמצעות מאזן עומסים פנימי מסוג TCP passthrough, שמנתב את התנועה לקבוצת הזמינות.
1. חוזרים ל-Cloud Shell ושומרים כתובת IP סטטית שתשמש ככתובת ה-IP של האשכול:
```
gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value$address$) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"
```
  מחליפים את REGION ואת SUBNET_NAME באזור וברשת המשנה שבהם נפרסות המכונות הווירטואליות של Linux.
  
  הערה: חשוב לשמור את כתובת ה-IP השמורה, כי תצטרכו להשתמש בה בשלב מאוחר יותר.
2. יוצרים קבוצות של מופעי מכונה לא מנוהלים לכל אחד מצמתי האשכול, ומקצים אותן לקבוצת המופעים שנוצרה. מריצים את הפקודות הבאות ב-Cloud Shell:
```
gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3
```
  מחליפים את REGION באזור שבו פרוסות מכונות וירטואליות של Linux.
3. יוצרים בדיקת תקינות של TCP. מאזני עומסים משתמשים בבדיקות תקינות כדי לקבוע אילו מופעי קצה עורפי מגיבים בצורה תקינה לתנועת נתונים.
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
  בוחרים ומחליפים את HEALTH_CHECK_PORT בערך של יציאה פנויה בטווח הפרטי 49152-65535 . לדוגמה, 60000.
  
  מידע נוסף מופיע במאמר סקירה כללית על בדיקות תקינות.
4. מוסיפים תגי רשת לצמתי האשכול. תג הרשת משמש את כלל חומת האש לבדיקת התקינות:
```
gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c
```
  מחליפים את NETWORK_TAG_NAME בשם של תג הרשת.
5. יוצרים כלל חומת אש שמאפשר לבדיקות התקינות להגיע לצמתי האשכול על סמך שם התג:
```
gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT
```
  מידע נוסף זמין במאמר בנושא כללים של חומת האש לבדיקות תקינות.
6. יוצרים את השירות לקצה העורפי של מאזן העומסים:
```
gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks
```
7. מוסיפים את שלוש קבוצות המופעים הלא מנוהלות לשירות ה-Backend:
```
gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION
```
8. מגדירים כלל העברה למאזן העומסים. כלל העברה מציין את הפרוטוקול והיציאות שבהם מאזן העומסים מקבל תנועה:
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
  מחליפים את CLUSTER_ADDRESS בכתובת ה-IP שהוזמנה קודם.
  
  טיפ: אם אתם רוצים שהלקוחות יוכלו לגשת לאשכול בכל אזור ברשת ה-VPC או ברשת מחוברת, אתם צריכים לכלול את --allow-global-access בהגדרה של כלל ההעברה.
  
  מידע נוסף זמין במאמר בנושא כללי העברה.
9. כדי להשלים את ההגדרה ולבדוק אם מאזן עומסי הרשת מוגדר בצורה נכונה, מתקינים ומגדירים את HAProxy tcp listener ב-node-1, ב-node-2 וב-node-3:
  1. מתקינים את HAProxy.
    sudo apt-get install haproxy
  2. בוחרים באפשרות Y כדי להשלים את ההתקנה.
  3. עורכים את קובץ haproxy.cfg.
    sudo vi /etc/haproxy/haproxy.cfg
  4. בקטע ברירות המחדל של haproxy.cfg file, משנים את המצב לtcp.
  5. מוסיפים את הקטע הבא בסוף הקובץ haproxy.cfg
    #--------------------------------------------------------------- # Set up health check listener for SQL Server Availability Group #--------------------------------------------------------------- listen healthcheck bind *:HEALTH_CHECK_PORT
    מחליפים את HEALTH_CHECK_PORT ביציאת בדיקת תקינות שנבחרה קודם. לדוגמה, 6000.
  6. מפעילים את השירות כדי לוודא שהוא מוגדר בצורה נכונה:
    sudo systemctl start haproxy.service sudo systemctl enable haproxy.service sudo systemctl restart haproxy.service
  7. נכנסים לדף Load balancing ולוחצים על מאזן העומסים. מתבוננים בשלוש קבוצות המופעים הלא מנוהלות, עכשיו הן אמורות להיות מסומנות כפעילות.
    
    כניסה לדף איזון עומסים
    - לחלופין, אפשר להריץ את הפקודה הבאה ב-Cloud Shell כדי לראות את הסטטוס של שירות לקצה העורפי.
      
      gcloud compute backend-services get-health aoag1-backend \ --region REGION
      
      מחליפים את REGION באזור שבו פרוסות מכונות וירטואליות של Linux.
  8. אחרי ששלושת קבוצות המופעים הלא מנוהלות מדווחות על תקינות, ממשיכים לשלב הבא.
    
    הערה: אם קבוצת המופעים הלא מנוהלת לא מדווחת על תקינות, יכול להיות שתצטרכו להפעיל מחדש את haproxy.service מהצומת הרלוונטי.
    sudo systemctl restart haproxy.service
10. יוצרים את משאב בדיקת התקינות ב-Pacemaker:
  1. מתחברים ל-node-1 באמצעות SSH ויוצרים משאב לבדיקת תקינות לשירות HAProxy באשכול pacemaker:
    sudo pcs resource create aoag1-healthcheck \ service:haproxy \ op monitor interval=10s timeout=20s
  2. בודקים שמשאב הבריאות מופעל בצומת הראשי node-1:
    sudo crm status
  3. אם משאב בדיקת התקינות לא מופעל בצומת הראשי, מעבירים אותו באמצעות הפקודות הבאות:
    sudo pcs resource move aoag1-healthcheck node-1 sudo pcs resource clear aoag1-healthcheck
    בבדיקת התקינות של מאזן העומסים יופיע שהמצב תקין רק עבור node-1.
    
    כניסה לדף איזון עומסים
11. יוצרים משאב של כתובת IP וירטואלית באשכול Pacemaker:
  1. חוזרים ל-SSH ב-node-1 ומחפשים את השם של ממשק הרשת של הצומת. תצטרכו אותו בשלב הבא.
    ip -c link
  2. יוצרים את משאב כתובת ה-IP הווירטואלית.
    sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \ ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \ op monitor interval=3600s timeout=60s
    מחליפים את NIC_NAME בשם של ממשק הרשת מהשלב הקודם ואת CLUSTER_ADDRESS בכתובת ה-IP השמורה.
  3. בודקים שהמשאב של כתובת ה-IP הווירטואלית מופעל במארח הראשי.
    sudo crm status
  4. אם משאב כתובת ה-IP הווירטואלית לא מופעל בצומת הראשי, מעבירים אותו באמצעות הפקודות הבאות.
    sudo pcs resource move aoag1-vip node-1
  5. מקבצים את המשאבים של בדיקת התקינות ושל כתובת ה-IP הווירטואלית.
    sudo pcs resource group add aoag1-group \ aoag1-healthcheck aoag1-vip
  6. יוצרים אילוץ שמאתר את הקבוצה החדשה באותו צומת כמו הקבוצה הראשית.
    sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
יצירת מאזין לקבוצת הזמינות של SQL Server

בחיבורים ל-SQL Server עם קבוצות זמינות, צריך להשתמש בשם של מאזין קבוצת הזמינות במקום בשם השרת. אם מתרחש יתירות כשל, מאזין יפנה אוטומטית את החיבורים לצומת הראשי החדש באשכול.
1. חוזרים ל-SSMS ומתחברים למסד הנתונים node-1.
2. מריצים את השאילתה הבאה:
```
ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO
```
  מחליפים את CLUSTER_ADDRESS בכתובת ה-IP השמורה.
הגדרה של גדר STONITH

STONITH היא אסטרטגיית גידור לשמירה על שלמות הצמתים באשכול HA. שירות STONITH פועל ברמת הצומת ומגן על האשכול מפני צמתים שלא מגיבים או שנמצאים במצב לא ידוע. אנחנו ממליצים על fence_gceמכשיר גידור שמתמחה ב-Compute Engine ב- Google Cloud.

הגדרת מכשירי גידור
1. בודקים אם fence_gce – סוכן הגידור ל-Compute Engine מותקן ב-node1:
```
sudo pcs stonith list | grep fence_gce
```
  למידע נוסף:
  - Fence agent for Google Compute Engine.
  - כדי לראות את הפרמטרים שמשויכים להרצת הסוכן.
    sudo pcs stonith describe fence_gce
2. ב-node-1, יוצרים את משאבי סוג הגידור fence_gce לכל אחד מהצמתים המשתתפים:
```
sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"
```
  מחליפים את REGION באזור שבו נפרסו מכונות ה-Linux הווירטואליות, ואת PROJECT_ID במזהה הפרויקט.
3. כדי לבדוק את הסטטוס של סוכני הגידור, מריצים את פקודת הסטטוס:
```
sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c
```
4. כדי לוודא שהמכשירים לגידור גיאוגרפי פועלים רק במופעים המיועדים, צריך ליצור הגבלות מיקום עבורם:
```
sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3
```
5. מפעילים את הגידור באשכול Pacemaker ומגדירים את הזמן הקצוב לתפוגה של הגידור באשכול:
```
sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"
```
6. בודקים את הסטטוס של האשכול:
```
sudo crm status
```
בדיקת מכשירי הגידור

אחרי שמגדירים את מכשירי הגידור, מומלץ לבדוק אותם באמצעות השלבים הבאים.
1. עצירת הגדר ב-node-2:
  1. מתחברים אל node-1 ומריצים את הפקודה הבאה כדי לבדוק את מכשיר הגידור שמשויך אל node-2 מהאשכול.
    fence_gce -o off -n node-2 --zone=REGION-b
  2. בודקים את הסטטוס של האשכול.
    sudo crm status
  3. בנוסף, תראו שהאפשרות node-2 מושבתת ב-Compute Engine.
    
    מעבר אל Compute Engine
2. הפעלה מחדש של הגדר הווירטואלית בתאריך node-2:
  1. חוזרים אל node-1 ומפעילים מחדש את המופע על ידי הרצת הפקודה הבאה.
    fence_gce -o on -n node-2 --zone=REGION-b
  2. בודקים את הסטטוס של האשכול ב-Pacemaker וב-Compute Engine. אחרי זמן קצר, תראו ש-node-2 חזר למצב אונליין.
    sudo crm status
הגדרת Corosync להפעלה מחדש מושהית

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

מידע נוסף זמין במאמר הזה במאגר הידע של Red Hat.
1. יוצרים קובץ drop-in של systemd שמגדיר השהיה של הפעלת שירות Corosync ב-node-1, ב-node-2 וב-node-3:
  1. פותחים את corosync.service לעריכה.
    sudo systemctl edit corosync.service
  2. מוסיפים את השורות הבאות, שומרים את הקובץ ויוצאים מהעורך.
    [Service] ExecStartPre=/bin/sleep 60
  3. טוענים מחדש את מנהל השירות ובודקים אם ההגדרה נלקחת בחשבון.
    sudo systemctl daemon-reload systemctl status corosync.service --no-pager
    אם הקטע Drop-In מופיע, סימן שההגדרות בקובץ ה-Drop-In נלקחו בחשבון.
בדיקת מעבר לגיבוי (failover)

עכשיו אפשר לבדוק אם המעבר לגיבוי פועל כמצופה.
1. מתחברים למכונה הווירטואלית של Windows ב-node-4 באמצעות Remote Desktop:
2. פותחים סשן PowerShell:
3. מריצים את הסקריפט הבא:
```
while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}
```
  מחליפים את CLUSTER_ADDRESS בכתובת ה-IP של המאזין ואת SA_PASSWORD בסיסמה של חשבון SA ב-SQL Server.
  
  כל 2 שניות, הסקריפט מתחבר ל-SQL Server באמצעות מאזין קבוצת הזמינות או מאזין ה-DNN, ושולח שאילתה לגבי שם השרת.
  
  משאירים את הסקריפט פועל.
4. חוזרים ל-SSH ב-node-1 ומריצים את הפקודות כדי להפעיל מעבר לגיבוי ולשיקום ב-node-2:
```
sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2
```
5. חוזרים לסשן PowerShell ב-node-4:
  1. בודקים את הפלט של הסקריפט הפועל ורואים ששם השרת משתנה מ-node-1 ל-node-2 כתוצאה ממעבר הגיבוי האוטומטי.
6. חוזרים אל node-1 ומפעילים מעבר חזרה ל-node-1:
```
sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1
```
7. חוזרים אל Powershell ב-node-4 ומפסיקים את הסקריפט על ידי לחיצה על Ctrl+C.
הסרת המשאבים

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

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

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך.

כדי למחוק את הפרויקט:
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.

הגדרה של אשכול SQL Server ב-Linux עם קבוצות זמינות Always On ו-Pacemaker קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מטרות

עלויות

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

הכנת הפרויקט והרשת

יצירת מכונות וירטואליות של Linux

התקנה והגדרה של SQL Server

התחברות ל-SQL Server

הפעלה של קבוצת זמינות Always On

העברה של קובצי האישור והמפתח

העברת קובצי האישור והמפתח באמצעות Cloud Storage

הגדרת נקודת קצה של שיקוף מסד נתונים

יצירה והגדרה של קבוצת הזמינות Always On

התקנה והגדרה של Pacemaker

יצירת התחברות ל-SQL Server עבור מנהל האשכולות של Pacemaker

התקנה של Pacemaker

הגדרת Corosync

העברת קובצי ההגדרות באמצעות Cloud Storage

הפעלה מחדש ואימות של התקשורת בין הצמתים

הגדרת האשכול

הגדרת מאזן עומסים ומאזין של קבוצת זמינות

יצירת מאזין לקבוצת הזמינות של SQL Server

הגדרה של גדר STONITH

הגדרת מכשירי גידור

בדיקת מכשירי הגידור

הגדרת Corosync להפעלה מחדש מושהית

בדיקת מעבר לגיבוי (failover)

הסרת המשאבים

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

הגדרה של אשכול SQL Server ב-Linux עם קבוצות זמינות Always On ו-Pacemaker