‫Microsoft SQL Server Always On availability groups ‏(AG) מאפשרים לשכפל מסדי נתונים בכמה מופעים של SQL Server Enterprise.

בדומה למופעי אשכולות למעבר אוטומטי לגיבוי (Failover) של SQL Server, קבוצות זמינות Always On משתמשות באשכולות למעבר אוטומטי לגיבוי (Failover) של Windows Server ‏(WSFC) כדי להטמיע זמינות גבוהה. אבל יש כמה הבדלים בין שתי התכונות, כולל:

	קבוצות זמינות Always On	מופעים של אשכולות מעבר לגיבוי בעת כשל
היקף המעבר לגיבוי	קבוצה של מסדי נתונים	Instance
אחסון	לא בשיתוף	משותף

השוואה מפורטת יותר זמינה במאמר השוואה בין מופעי אשכולות של מעבר לגיבוי בעת כשל לבין קבוצות זמינות.

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

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

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

בסביבת Windows Server Failover Clustering מקומית, הודעות ARP מפעילות מעבר לגיבוי (failover) של כתובת IP. Cloud de Confiance, אבל לא מתייחס להודעות על ARP. לכן, אתם צריכים להטמיע אחת משתי האפשרויות הבאות: שימוש במאזן עומסים פנימי ובשם רשת מבוזר (DNN). ההנחה במאמר הזה היא שכבר פרסתם את Active Directory ב- Cloud de Confiance by S3NS , ושיש לכם ידע בסיסי ב-SQL Server, ב-Active Directory וב-Compute Engine. מידע נוסף על Active Directory ב- Cloud de Confianceזמין בקטע 'תחילת העבודה'