Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

מטרות

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

עלויות

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

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

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

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

בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
- יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

כניסה לדף לבחירת הפרויקט
מוודאים שהחיוב מופעל בפרויקט Google Cloud .
במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

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

כדי להכין את פרויקט Google Cloud ו-VPC לפריסה של קבוצות זמינות Always On של SQL Server, צריך לבצע את הפעולות הבאות:

במסוף Google Cloud , לוחצים על הלחצן Activate Cloud Shell כדי לפתוח את Cloud Shell.

כניסה ל Google Cloud מסוף
מגדירים את מזהה הפרויקט שמוגדר כברירת מחדל:
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט. Google Cloud
הגדרת אזור ברירת המחדל:
```
gcloud config set compute/region REGION
```
מחליפים את REGION במזהה האזור שבו רוצים לבצע פריסה.
הגדרת אזור ברירת המחדל:
```
gcloud config set compute/zone ZONE
```
מחליפים את ZONE במזהה של האזור שבו רוצים לבצע פריסה. הוא צריך להיות אזור תקין באזור שצוין בשלב הקודם.

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

כדי להשיג זמינות גבוהה (HA) וקוורום עבור אשכול SQL Server, פורסים שלוש מכונות וירטואליות (VM) של Linux לאירוח אשכול SQL Server.

מאתחלים את המשתנים הבאים:
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

יוצרים את מכונות ה-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.

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

מתחברים ל-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
```
מגדירים את SQL Server:
1. מריצים את הכלי mssql-conf.
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. בוחרים במהדורת Developer של SQL Server ומאשרים את הסכם הרישיון.
  
  מהדורת המפתחים כוללת את כל התכונות של מהדורת Enterprise, אבל אפשר להשתמש בה רק בסביבות שאינן סביבות ייצור. מידע נוסף זמין על מהדורות SQL Server ועל רישיונות של מיקרוסופט.
  
  הערה: לכל מכונת VM נדרש רישיון ל-SQL Server. אם אתם מריצים שרתי אפליקציות של מיקרוסופט, ניוד הרישיונות באמצעות Software Assurance עוזר לכם לעבור אל Google Cloud. מידע נוסף זמין במאמר שימוש בניוד רישיונות עם אפליקציות שרת של מיקרוסופט. אם אתם לא מביאים רישיון משלכם וצריכים לרכוש רישיון דרך Google (תשלום לפי שימוש), אתם צריכים לפעול לפי השלבים במאמר הוספת רישיון ל-SQL Server לדיסק אתחול כדי לוודא שאתם רוכשים רישיון לכל מופע של מכונה וירטואלית.
3. מציינים סיסמה לחשבון SA.
4. מוודאים שהשירות mssql-server פועל.
```
systemctl status mssql-server --no-pager
```
אם הפעלתם חומת אש במכונות הווירטואליות, צריך לפתוח את חומת האש עבור 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 שנוצר לאחרונה במכונות הווירטואליות:

יוצרים מכונה וירטואלית של Windows:

חוזרים אל 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

מתחברים למכונת Windows הווירטואלית ב-node-4 באמצעות Remote Desktop:
מעדכנים את קובץ המארחים ב-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. שמירה ויציאה.
מאמתים את הקישוריות למכונות ה-VM של Linux:
1. מתחברים ל-VM של Windows ב-node-4
2. לוחצים על הלחצן התחל ומזינים powershell בסרגל החיפוש.
3. לוחצים כדי לפתוח את אפליקציית Windows PowerShell ISE.
4. בודק את הקישוריות על ידי הפעלת הפקודות הבאות.
```
ping node-1
ping node-2
ping node-3
```
כדי להתקין את 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.
מתחברים למכונה של SQL Server בצומת node-1:
1. חוזרים למכונה הווירטואלית node-4 באמצעות 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:

מפעילים את התכונה 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
```
מתחברים למופע שהוא המארח הראשי בקבוצת הזמינות באמצעות 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 להעברת קבצים מהצמתים הראשיים של האשכול לצמתים המשניים.

יוצרים קטגוריה של 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
מידע נוסף זמין במאמר בנושא יצירת קטגוריות.
חוזרים ל-SSH ב-node-1, ב-node-2 וב-node-3 כדי להפעיל את Google Cloud CLI:
1. מריצים את הפקודה הבאה כדי לאתחל את Google Cloud CLI.
```
gcloud init
```
2. בוחרים באפשרות option [1] כדי להשתמש בחשבון השירות שהותקן מראש.
3. מזינים את שם הפרויקט.
4. מזינים n בשאלה כדי להגדיר את אזור ברירת המחדל ואת האזור.
חוזרים אל 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 בשם הקטגוריה שנוצרה.
חוזרים אל 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, כדי להבטיח שכפול מאובטח של הנתונים.

חוזרים למכונה הווירטואלית של 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

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

חוזרים למכונת ה-VM של Windows ופותחים את SSMS:
1. מתחברים למנוע מסד הנתונים של SQL Server ב-node-1 ופותחים חלון חדש של שאילתה.

יוצרים מסד נתונים ומגבים אותו לקראת יצירת רפליקה:

USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

יוצרים את קבוצת הזמינות Always On:

מריצים את פקודת 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

מריצים את פקודת 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

מריצים את פקודת 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 ולנהל את קבוצת הזמינות.

מריצים את פקודת T-SQL הבאה ב-node-1, ב-node-2 וב-node-3:
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
מחליפים את PACEMAKER_LOGIN_PASSWORD בסיסמה לחשבון של קוצב הלב.

מריצים את פקודת T-SQL כדי להעניק את הרשאות הכניסה של Pacemaker לקבוצת הזמינות:

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

חוזרים ל-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 לניהול משאבים.

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

מתקינים את 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

הגדרת סיסמה חדשה למשתמש hacluster ב-node-1, ב-node-2 וב-node-3:

הערה: צריך להגדיר את אותה סיסמה בכל שלושת הצמתים. תצטרכו את הסיסמה הזו בהמשך ההגדרה.
```
sudo passwd hacluster
```

הגדרת Corosync

עכשיו צריך להגדיר את Corosync כדי לנהל את החברות באשכול ואת ההודעות באשכול.

יוצרים מפתח אימות ל-Corosync ב-node-1:
```
sudo corosync-keygen
```

משנים את קובץ ההגדרות של Corosync:

חוזרים אל node-1 ומשנים את הקובץ corosync.conf.
```
sudo vi /etc/corosync/corosync.conf
```

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

# 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

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

מעדכנים את ההרשאות של הקבצים ב-node-2 וב-node-3:

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

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

מפעילים מחדש את שירותי Pacemaker ו-Corosync ב-node-1, ב-node-2 וב-node-3:
```
sudo systemctl restart pacemaker corosync
```
מריצים את הפקודה ב-node-1 כדי לאשר את סטטוס האשכול:
```
sudo crm status
```
שלושת הצמתים אמורים להיות במצב אונליין.

הגדרת האשכול

בשלב הבא, תגדירו את אשכול Pacemaker על ידי יצירת משאב חדש לקבוצת הזמינות SQL Server Always On.

מריצים את הפקודה הבאה ב-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
```
מידע נוסף זמין במאמר בנושא אפשרויות של אשכול.
מריצים את הפקודה ב-node-1 כדי לתת הרשאה לצמתים באשכול. להשתמש בסיסמה שהוגדרה בעבר לחשבון hacluster:
```
sudo pcs cluster auth -u hacluster
```
אפשר לראות שכל שלושת הצמתים מורשים.
מתקינים סוכן משאבים של SQL Server לשילוב עם Pacemaker ב-node-1, ב-node-2 וב-node-3:
```
sudo apt-get install mssql-server-ha
```
חוזרים אל 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, שמנתב תנועה לקבוצת הזמינות.

חוזרים ל-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 השמורה, כי תצטרכו להשתמש בה בשלב מאוחר יותר.

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

יוצרים בדיקת תקינות של 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.

מידע נוסף מופיע במאמר סקירה כללית על בדיקות תקינות.

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

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 בשם של תג הרשת.

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

יוצרים את השירות לקצה העורפי של מאזן העומסים:

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

מוסיפים את שלוש קבוצות המופעים הלא מנוהלות לשירות ה-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

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

מידע נוסף זמין במאמר בנושא כללי העברה.
כדי להשלים את ההגדרה ולבדוק אם איזון העומסים ברשת מוגדר בצורה נכונה, מתקינים ומגדירים את 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 ולוחצים על מאזן העומסים. מתבוננים בשלוש קבוצות המופעים הלא מנוהלות, עכשיו הן אמורות להיות מסומנות כקבוצות תקינות.
  
  כניסה לדף Load balancing
  - לחלופין, אפשר להריץ את הפקודה הבאה ב-Cloud Shell כדי לראות את הסטטוס של שירות לקצה העורפי.
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    מחליפים את REGION באזור שבו נפרסו מכונות וירטואליות של Linux.
8. אחרי ששלושת קבוצות המופעים הלא מנוהלות מדווחות על תקינות, ממשיכים לשלב הבא.
  
  הערה: אם קבוצת המופעים הלא מנוהלת לא מדווחת על תקינות, יכול להיות שתצטרכו להפעיל מחדש את haproxy.service מהצומת הרלוונטי.
```
sudo systemctl restart haproxy.service
```
יוצרים את משאב בדיקת התקינות ב-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.
  
  כניסה לדף Load balancing
יוצרים משאב של כתובת 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 עם קבוצות זמינות, צריך להשתמש בשם של מאזין קבוצת הזמינות במקום בשם השרת. אם מתרחשת יתירות כשל, מאזין יפנה אוטומטית את החיבורים לצומת הראשי החדש באשכול.

חוזרים ל-SSMS ומתחברים למסד הנתונים node-1.

מריצים את השאילתה הבאה:

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.

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

בודקים אם הסוכן fence_gce - Fence ל-Compute Engine מותקן ב-node1:
```
sudo pcs stonith list | grep fence_gce
```
למידע נוסף:
- Fence agent for Google Compute Engine.
- כדי לראות את הפרמטרים שמשויכים להרצת הסוכן.
```
sudo pcs stonith describe fence_gce
```

ב-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 באזור שבו מכונות ה-VM של Linux נפרסות, ואת PROJECT_ID במזהה הפרויקט.

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

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

כדי לוודא שהמכשירים שלכם פועלים רק במופעים המיועדים, צריך ליצור הגבלות מיקום עבורם:

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

מפעילים את הגידור באשכול קוצבי הלב וקובעים את הזמן הקצוב לתפוגה של הגידור באשכול:
```
sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"
```
בודקים את הסטטוס של האשכול:
```
sudo crm status
```

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

אחרי שמגדירים את מכשירי הגידור, מומלץ לבדוק אותם באמצעות השלבים הבאים.

עצירת הגדר ב-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
הפעלה מחדש של הגדר הווירטואלית בתאריך 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.

יוצרים קובץ 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)

עכשיו אפשר לבדוק אם הגיבוי למקרה של כשל פועל כמצופה.

מתחברים למכונה הווירטואלית של Windows ב-node-4 באמצעות Remote Desktop:
פותחים סשן PowerShell:

מריצים את הסקריפט הבא:

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, ושולח שאילתה לגבי שם השרת.

משאירים את הסקריפט פועל.

חוזרים ל-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
```
חוזרים לסשן PowerShell ב-node-4:
1. בודקים את הפלט של הסקריפט הפועל ורואים ששם השרת משתנה מ-node-1 ל-node-2 כתוצאה מהמעבר לגיבוי.

חוזרים אל 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

חוזרים אל Powershell ב-node-4 ומפסיקים את הסקריפט על ידי לחיצה על Ctrl+C.

הסרת המשאבים

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

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

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

כדי למחוק את הפרויקט:

זהירות: כשמוחקים פרויקט:

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

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

במסוף Google Cloud , נכנסים לדף Manage resources.
כניסה לדף Manage resources
ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.