SQL Server AlwaysOn Availability Groups е най-новата технология на Microsoft за посрещане на нуждите от висока наличност и аварийно възстановяване на организации, използващи SQL Server. Едно голямо предимство на AlwaysOn е способността да се адресира както HA, така и DR в една реализация. Основните предимства на AlwaysOn, които изпитахме, са следните:
Можем да групираме свързани бази данни като част от една група за наличност и да ги накараме да преминат при отказ заедно в случай на такава нужда. Това е особено полезно за приложения, които зависят от повече от една база данни, като например Microsoft Office SharePoint, Microsoft Lync или Sage.
В сравнение с екземпляри на клъстер при отказ на SQL Server, откриваме, че съхранението като единична точка на отказ е елиминирано, тъй като на всеки екземпляр, който представлява реплика, е присвоено собствено хранилище.
С AlwaysOn е възможно да конфигурирате HA и DR наведнъж. Това се постига чрез създаване на многосайтови Windows отказоустойчиви клъстери като основа на вашата AlwaysOn конфигурация. Извършването на превключване на ролята при използване на AlwaysOn е значително по-лесно, отколкото при използване на доставка на дневник на транзакциите.
Зависимостта на WSFC
Когато използвате SQL Server AlwaysOn AG за висока наличност и аварийно възстановяване, първо трябва да конфигурирате клъстер за отказ на Windows. AlwaysOn AG зависят от WFCS за управление на AlwaysOn AG като роля, която се състои от такива клъстерни ресурси като името на групата за наличност, името на споделяния файл, името на слушателя и IP адреса.
Фиг. 1 AlwaysOn AG като клъстер ресурс
Кворум
Кворумът е минималният брой гласове, необходим за мнозинство в клъстер при отказ. Кворумът определя колко повреди на възли може да издържи клъстерът. Чрез частната мрежа на порт 3343 всички възли на клъстера комуникират здравословното състояние и информация за мониторинг на ресурсите. В случай на неуспех гласовете показват кои възли имат статус „Нагоре“ и ресурсите на кои възли трябва да бъдат включени онлайн.
От Windows Server 2012 максималният брой поддържани възли на клъстер е шестнадесет. Въпреки това, в повечето среди, с които съм запознат, клъстерите с два възела са често срещани. Клъстер с два възела представлява малък проблем по отношение на постигането на кворум, тъй като всеки възел има един глас и ако има проблем с комуникацията между двата, всеки може да приеме, че другият не е здрав. Това се нарича сценарий с разделен мозък. Сценариите с разделен мозък са причината за конфигуриране на тайбрейка, като например диск или споделяне на файлове.
Ако имате нечетен брой възли, не е необходимо да конфигурирате тайбрейка. Динамичната конфигурация на кворума и динамичното свидетелство бяха въведени съответно в Windows Server 2012 и Windows Server 2012 R2. С помощта на тези технологии Windows автоматично преразпределя гласовете в клъстер, така че броят на възлите в клъстер да няма значение при установяване на кворум. Гласуването на възел на клъстер се премахва чрез задаване на свойството на клъстера „NodeWeight“ на 0. Тези функции са активирани по подразбиране.
Фиг. 2 Получаване на всички свойства на клъстера с помощта на PowerShell
Фиг. 3 разпределени гласа в клъстер с два възела
Използване на PowerShell
Командата Get-Cluster на PowerShell може да се използва за проверка на конфигурацията на кворума в клъстер на Windows. Фиг. 4 показва как да проверите всички свойства на клъстера, свързани с кворума в клъстер, а фиг. 5 изобразява свойствата на File Share Witness. Има много други команди на PowerShell за проверка и управление на клъстерите на Windows.
Get-Cluster | Format-List –Property *Quorum*
Фиг. 4 PowerShell команда за проверка на свойствата, свързани с кворума
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Фиг. 5 PowerShell команда за проверка на подробностите за свойствата на свидетел на споделяне на файлове
Режими на кворум
Клъстер за отказ на Windows Server позволява конфигуриране на до четири режима. Режимите на кворума са по същество опции, които избирате, за да определите как клъстерът ще се справя с повредите на възли.
1. Мнозинство на възела
Този режим на кворум може да поддържа повреди на до (n/2)-1 възли. Препоръчва се за клъстери с нечетен брой възли. Например в клъстер с пет възела ще е необходим отказ на два възела, за да причини повреда на клъстера.
2. Мнозинство на възли и диски
Може да поддържа откази на до половината от броя на възлите на клъстера, докато свидетелят на диска (наричан още кворум диск) остава онлайн.
3. Мнозинство за споделяне на възли и файлове
Този режим на кворум може да поддържа откази на до половината от броя на възлите на клъстера, докато споделянето на файлове остава достъпно. От Windows Server 2012 R2 Microsoft препоръчва винаги да се конфигурира свидетел (диск или споделяне на файлове) при изграждане на клъстер.
4. Без мнозинство
Това е режим само за диск. Този режим може да поддържа откази на всички възли с изключение на един, докато дискът е онлайн. Този режим не се препоръчва, тъй като дискът се превръща в единична точка на повреда.
Съвети за конфигуриране на мнозинство на споделяне на възли и файлове
Групите за наличност на AlwaysOn поддържат само два от тези режима на кворум:мнозинство на възел и мнозинство за споделяне на възли и файлове. Когато създавате клъстер на SQL Server AlwaysOn Availability Group, има няколко точки, които DBA трябва да има предвид:
1. Използване на физически сървъри
Когато конфигурирате клъстер с два възела за AlwaysOn, вашите възли трябва да се намират в различни физически стелажи. Сървърът, който хоства споделеното ви файлове, трябва да се намира в трета стойка.
2. Използване на виртуални сървъри
Когато конфигурирате клъстер с два възела за AlwaysOn, вашите виртуални машини трябва да се намират на отделни хостове. Виртуалната машина, която хоства вашия файлов споделен ресурс, трябва да се намира на трети хост.
3. Групиране на няколко сайтаа
Когато конфигурирате клъстер с множество възли за AlwaysOn в центрове за данни, в идеален сценарий файловият сървър, хостващ вашия файлов споделен ресурс, трябва да се намира в трети център за данни.
4. Разрешения за споделяне на файлове
Обектът име на клъстера трябва да има разрешения за споделяне на файлове, използвано като свидетел на кворума. Без това обикновено ще имате грешки при опит за конфигуриране на Quorum Witness.
Фиг. 6 Разрешения за споделяне на файлове
5. Онлайн конфигурацията
Режимите на кворума могат да бъдат конфигурирани, докато клъстерът е онлайн. Така че, в случай че сървърът за споделяне на файлове не успее или трябва да бъде преконфигуриран, уверете се, че бързо преконфигурирате, за да гарантирате, че няма неочаквани повреди, особено в клъстер с два възела.
Случай на реална употреба
Диаграмата на фиг. 7 изобразява истински многосайтов клъстер AlwaysOn AG. Това е клъстер с четири възела с два възела на един сайт и два други на отдалечен DR сайт. Файловият сървър, който хоства споделянето на файлове, използвано като посредник, се хоства в трети център за данни. В настоящия случай файловият сървър се намира в същия град като основния център за данни, но ако можете да си го позволите, би било идеално да имате файлов сървър в друг град. Комуникацията между трите страни трябва да бъде с добро качество, за да се избегнат фалшиви положителни резултати.
Например, при първоначалното ни внедряване на този клъстер използвахме „Синхронна репликация с автоматично отказване“ в сайтовете на живо и DR. Повече от един път изпитахме проблем в комуникацията, който задейства автоматично превключване при отказ към сайта за DR и разкри недостатък в нашата конфигурация. Това накара името на слушателя да се разреши към свързаните IP адреси в сайта на DR и клиентите вече не можеха да се свържат, тъй като комуникацията с този нов IP адрес не беше разрешена на защитните стени на мрежата. Просто не успяхме да се върнем към основния сайт, за да смекчим проблема и променихме конфигурацията на „Асинхронна репликация с ръчно отказване“ за възли, намиращи се в центрове за данни. Планираме да покрием аспекта на разделянето на имената в следващата ни статия „AlwaysOn“.
Фиг. 7 Случай на реална употреба
Заключение
Функцията AlwaysOn Availability Groups е въведена в SQL Server 2012 и е най-новата технология на Microsoft за посрещане на нуждите както от висока наличност, така и от аварийно възстановяване. Конфигурирането на групи за наличност на AlwaysOn зависи силно от услугата за отказ на клъстер на Windows. От своя страна отказоустойчивите клъстери зависят много от правилната конфигурация на кворума. Когато изграждате AlwaysOn върху многосайтови клъстери, латентността между вашите възли в различните сайтове и споделянето на файлове, използвано като арбитър, наистина има значение. Уверете се, че конфигурацията на кворума ви винаги е в добра форма, за да избегнете неочаквано поведение с групите за наличност.
Препратки
Общ преглед на групите за наличност на AlwaysOn
Клъстер при отказ на Windows със SQL Server
Документация на PowerShell
Разбиране на кворума за отказ на клъстер за Windows Server
