הגדרת קבוצות זמינות תמיד של SQL Server מאפס

אנו מתכננים ומיישמים Always On AG עבור לקוחות מאפס. בפועל, הבעיה הראשונה בעת הגדרה עצמאית: אשכול WSFC פעיל, SQL Server מותקן על שני הצמתים, ה-AG נוצר — אך failover אוטומטי אינו מתרחש. הסיבה היא לרוב תצורת קולות קוורום שגויה או העובדה ש-SQL Server Agent על העותק המשני אינו עוקב אחר מצב הבריאות של ה-listener. ואז מתברר שהיישום משתמש במחרוזת חיבור עם שם השרת ישירות. אנו מבטיחים שאחרי הפריסה שלנו, הפתעות כאלה לא יקרו. קבלו ייעוץ עם מהנדס לביקורת של התשתית שלכם.

למה failover לא עובד? — ms sql setup

הסיבות הנפוצות ביותר: קוורום לא מוגדר (ללא witness), העותק המשני לא במצב סינכרוני, או שה-listener לא נוסף. WSFC מצפה לקולות מכל המשתתפים, ואם צומת אחד אובד, האשכול עלול לעצור אם חסר witness. הפתרון — השתמשו ב-Cloud Witness (Azure Blob Storage) או ב-file share witness.

איך מגדירים קוורום ו-listener?

ראשית, צרו WSFC עם פרמטר -NoStorage, ולאחר מכן הוסיפו witness. Cloud Witness מוגדר דרך Set-ClusterQuorum. לאחר מכן, ה-listener נוצר כ-IP וירטואלי עם רשומת DNS — היישום מתחבר אליו, לא ישירות לצומת. מחרוזת החיבור עבור לקוחות .NET חייבת לכלול MultiSubnetFailover=True. מידע נוסף על הארכיטקטורה ניתן למצוא בתיעוד על Always On Availability Groups.

מצב סינכרוני מספק אפס אובדן נתונים, אך אסינכרוני מהיר ב-30–50% — מתאים לעותקים מרוחקים גיאוגרפית.

מה זה direct seeding ואיך זה מפשט את האתחול?

Direct seeding הוא אתחול אוטומטי של עותק משני ללא גיבוי ושחזור ידני. SQL Server מעביר נתונים דרך ה-endpoint. זה נוח למאגרי נתונים קטנים (עד 200–300 GB), אך עבור מאגרי נתונים גדולים זה עלול לקחת זמן. במקרים כאלה, עדיף seed ידני דרך SMB או גיבוי/שחזור.

איך AG עובד מתחת למכסה המנוע?

Always On AG רץ על גבי WSFC. כל צומת מקבל קול, וה-witness מוסיף קול שלישי לקוורום. ברמת מאגר הנתונים, AG משתמש בקבוצות זמינות עם עותק ראשי אחד ומספר עותקים משניים. עבור failover אוטומטי, העותקים חייבים להיות במצב סינכרוני ו-WSFC חייב להיות פעיל.

הכנת WSFC ו-SQL Server

לפני יצירת האשכול, בדקו תאימות צמתים: גרסאות Windows זהות, תחום AD יחיד, מתאמי רשת נפרדים ל-heartbeat, SQL ותעבורת לקוחות. יצירת אשכול ללא אחסון משותף:

Test-Cluster -Node SQL01, SQL02 -Include "Inventory","Network","Storage"
New-Cluster -Name SQLCLUSTER -Node SQL01, SQL02 -StaticAddress 10.0.1.10 -NoStorage
Set-ClusterQuorum -CloudWitness -AccountName "sqlwitness" -AccessKey "base64key=="

הפעל Always On על כל צומת:

Enable-SqlAlwaysOn -ServerInstance "SQL01" -Force Enable-SqlAlwaysOn -ServerInstance "SQL02" -Force 

יצירת קבוצת זמינות

מאגר הנתונים חייב להיות במצב שחזור FULL ובעל גיבוי מלא לפני ההוספה. השתמשו ב-direct seeding לאתחול אוטומטי:

CREATE AVAILABILITY GROUP [AG_Production]
WITH
(
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    FAILURE_CONDITION_LEVEL = 3,
    HEALTH_CHECK_TIMEOUT = 30000
)
FOR DATABASE [AppDB], [AuditDB]
REPLICA ON
    N'SQL01' WITH
    (
        ENDPOINT_URL = N'TCP://SQL01.corp.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = NO)
    ),
    N'SQL02' WITH
    (
        ENDPOINT_URL = N'TCP://SQL02.corp.local:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SEEDING_MODE = AUTOMATIC,
        SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)
    );
ALTER AVAILABILITY GROUP [AG_Production]
ADD LISTENER N'AG-Listener' (WITH IP ((N'10.0.1.20', N'255.255.255.0')), PORT = 1433);

בצומת המשני, בצעו:

ALTER AVAILABILITY GROUP [AG_Production] JOIN; ALTER AVAILABILITY GROUP [AG_Production] GRANT CREATE ANY DATABASE; 

ניתוב לקריאה בלבד

לאנליטיקה על העותק המשני, הגדירו רשימת ניתוב:

ALTER AVAILABILITY GROUP [AG_Production] MODIFY REPLICA ON N'SQL01' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'SQL02')));
ALTER AVAILABILITY GROUP [AG_Production] MODIFY REPLICA ON N'SQL02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQL02.corp.local:1433'));

בעיות תפעול נפוצות

• סטיית סנכרון: אם העותק המשני מציג SYNCHRONIZING, בדקו את Test-Cluster -Node SQL01, SQL02 -Include "Inventory","Network","Storage" New-Cluster -Name SQLCLUSTER -Node SQL01, SQL02 -StaticAddress 10.0.1.10 -NoStorage Set-ClusterQuorum -CloudWitness -AccountName "sqlwitness" -AccessKey "base64key==" . השדה Enable-SqlAlwaysOn -ServerInstance "SQL01" -Force Enable-SqlAlwaysOn -ServerInstance "SQL02" -Force יצביע על הפיגור. סיבות — עומס רשת או עסקאות כבדות.
• Failover ללא מעבר: היישום מחזיק מאגר חיבורים ל-SQL01 — לאחר failover, שאילתות נכשלות. פתרון — השתמשו רק ב-listener וב-CREATE AVAILABILITY GROUP [AG_Production] WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY, FAILURE_CONDITION_LEVEL = 3, HEALTH_CHECK_TIMEOUT = 30000) FOR DATABASE [AppDB], [AuditDB] REPLICA ON N'SQL01' WITH (ENDPOINT_URL = N'TCP://SQL01.corp.local:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE (ALLOW_CONNECTIONS = NO)), N'SQL02' WITH (ENDPOINT_URL = N'TCP://SQL02.corp.local:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [AG_Production] ADD LISTENER N'AG-Listener' (WITH IP ((N'10.0.1.20', N'255.255.255.0')), PORT = 1433); .
• גיבוי על העותק המשני: הגדירו משימות עם בדיקת ALTER AVAILABILITY GROUP [AG_Production] JOIN; ALTER AVAILABILITY GROUP [AG_Production] GRANT CREATE ANY DATABASE; , אחרת הגיבוי יהיה על כל הצמתים או על אף אחד.

מה כלול בעבודה?

• ביקורת תשתית נוכחית ועיצוב טופולוגיית AG.
• פריסת WSFC עם קוורום (witness) והפעלת Always On.
• יצירת AG עם direct seeding, הגדרת listener וניתוב לקריאה בלבד.
• בדיקת failover תחת עומס עם מדידת RTO (בדרך כלל מתחת ל-30 שניות).
• תיעוד runbooks והדרכה לצוות שלכם.
• אחריות תצורה ותמיכה לחודש אחד לאחר הפריסה.

הניסיון שלנו — מעל 8 שנים ב-DevOps ו-SQL Server, מעל 50 פרויקטים על Always On AG. אם אתם נתקלים בבעיות failover או רוצים לתכנן ארכיטקטורה עמידה לתקלות, הזמינו ביקורת תשתית.

לוח זמנים: 3 עד 5 ימים לתצורה סטנדרטית (2 צמתים, עד 10 מאגרי נתונים). עבור עותק DR במרכז נתונים אחר — עד שבועיים. העלות מחושבת באופן אישי לאחר הביקורת. קבלו עמידות לתקלות ברמה ארגונית — צרו קשר לייעוץ.