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

בדומה למופעי אשכולות למעבר אוטומטי לגיבוי ב-SQL Server, קבוצות זמינות Always On משתמשות באשכולות למעבר אוטומטי לגיבוי ב-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. Google Cloud, אבל לא מתייחס להודעות ARP. לכן, אתם צריכים להטמיע אחת משתי האפשרויות הבאות: שימוש במאזן עומסים פנימי ובשם רשת מבוזר (DNN). במאמר הזה מניחים שכבר פרסתם את Active Directory ב- Google Cloud ושאתם מכירים את המושגים הבסיסיים של SQL Server,‏ Active Directory ו-Compute Engine. מידע נוסף על Active Directory ב- Google Cloudזמין בקטע 'התחלה'