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

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

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

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

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

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