Отстраняване на неизправности AlwaysOn – Понякога са необходими много групи очи

Преди няколко седмици започнах да конфигурирам демо среда с множество конфигурации на AlwaysOn Availability Groups. Имах WSFC клъстер с 5 възела – всеки възел имаше самостоятелен наименуван екземпляр на SQL Server 2012, а също така имаше два екземпляра на отказен клъстер (FCI), които бяха настроени върху тези възли. Бърза диаграма:

Така че можете да видите, че има 5 самостоятелни наименувани екземпляра (.\AGDEMO на всеки възел), а след това два FCI – един с възможни собственици VM-AARON-1 и VM-AARON-2 (AGFCI1\AGFCI1 ), а след това един с възможни собственици VM-AARON-3, VM-AARON-4 и VM-AARON-5 (AGFCI2\AGFCI2 ). Сега, ръчното диаграмиране на това ще трябва да стане значително по-сложно (повече за това по-късно), така че ще го избегна по очевидни причини. По същество изискването беше да има множество типове конфигурации на AG:

• Основно на FCI с реплика на един или повече самостоятелни екземпляри
• Основно на FCI с реплика на различен FCI
• Основно за самостоятелен екземпляр с реплика на един или повече FCI
• Основно на самостоятелен екземпляр с реплика на един или повече самостоятелни екземпляри
• Основно на самостоятелен екземпляр с реплики както на самостоятелни екземпляри, така и на FCI

И след това комбинации (където е възможно) от синхронен срещу асинхронен комит, ръчно срещу автоматично преминаване при отказ и вторични елементи само за четене. Има някои технически ограничения, които биха ограничили възможните пермутации тук, например:

• Ръчното преминаване на отказ е необходимо с всяка реплика, която е на FCI
• Нито един WSFC възел не може да хоства – или дори да бъде евентуален собственик на – множество екземпляри, независимо дали са самостоятелни или клъстерни, които участват в една и съща група за наличност. Получавате това съобщение за грешка:Неуспешно създаване, присъединяване или добавяне на реплика към групата за наличност 'MyGroup', тъй като възелът 'VM-AARON-1' е възможен собственик както за репликата 'AGFCI1\AGFCI1' и 'VM-AARON-1\ AGDEMO“. Ако една реплика е екземпляр на клъстер за преодоляване на отказ, премахнете припокриващия се възел от възможните му собственици и опитайте отново. (Microsoft SQL Server, грешка:19405)

Повечето от сценариите, които се опитвах да представя, не са практични в реални сценарии, но до голяма степен и теоретично са възможни . Ако не сте се досетили досега, тази среда се настройва изрично за тестване на нова функционалност около групите за наличност, които планираме да предложим в бъдеща версия на SQL Sentry. Дадохме кратък поглед върху някои от тази технология по време на нашата основна реч с Fusion-io на неотдавнашната конференция на SQL Intersection в Лас Вегас.

Препятствие №1

Създаването на групи за наличност с помощта на съветника в SSMS е доста лесно. Освен ако например нямате хетерогенни пътеки на файлове. Помощникът има валидиране, което гарантира, че във всички реплики съществуват едни и същи пътеки за данни и журнал. Това може да е проблем, ако използвате пътя на данните по подразбиране за два различни наименувани екземпляра или ако имате различни конфигурации на буквата на устройството (което често се случва, когато участват FCI).

Следните папки не съществуват на сървърния екземпляр, който хоства вторична реплика VM-AARON-1\AGDEMO:

P:\MSSQL11.AGFCI2\MSSQL\DATA;
(Microsoft.SqlServer.Management.HadrTasks)

Сега трябва да се разбира, че не искате да настройвате този сценарий в каквато и да е среда, която трябва да издържи теста на времето. Нещата ще се развият много бързо, ако например по-късно добавите нов файл към една от базите данни. Но за тестова/демо среда, доказателство за концепция или среда, която очаквате да бъде стабилна за значително време, не се притеснявайте:все още можете да направите това без съветника.

За съжаление, за да добавите обида към нараняването, съветникът не ви позволява да го напишете. Не можете да преминете през грешката при валидиране и няма Script бутон:

Така че това означава, че трябва да го кодирате сами (тъй като DDL не извършва никаква "полезна" проверка за вас). Ако имате други случаи, в които съществуват същите пътища, можете да направите това, като следвате същия съветник, преминете през екрана за валидиране и след това щракнете върху Script вместо Finish , и променете името(ата) на сървъра и добавете с WITH MOVE опции за първоначално възстановяване. Или можете просто да напишете своя собствена от нулата, нещо подобно (скриптът предполага, че вече имате конфигурирани крайни точки и разрешения и всички екземпляри имат активирана функция Групи за наличност):

-- Използвайте режим SQLCMD и разкоментирайте командите :CONNECT-- или просто стартирайте двата сегмента поотделно / променете връзката-- :CONNECT Server1 СЪЗДАЙТЕ ГРУПА НА НАЛИЧНОСТ [GroupName] С (AUTOMATED_BACKUP_PREFERENCE =SECONDARY) ЗА БАЗА ДАННИ1] --База данни , ... REPLICA ON -- първичен:N'Server1' С (ENDPOINT_URL =N'TCP://Server1:5022', FAILOVER_MODE =РЪЧНО, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, ВТОРИЧЕН_КОНТРОЛЕН) - вторичен:N'Server2' С (ENDPOINT_URL =N'TCP://Server2:5022', FAILOVER_MODE =РЪЧНО, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SECONDARY_ROLE(ALLSOW_CONNECTION)); ПРОМЕНИ ГРУПАТА НА НАЛИЧНОСТ [Име на група] ДОБАВЯНЕ НА СЛУШАТЕЛ N'Име на слушателя' (С IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433); РЕЗЕРВНА БАЗА ДАННИ База данни1 КЪМ ДИСК ='\\Server1\Share\db1.bak' С INIT, COPY_ONLY, COMPRESSION; BACKUP LOG Database1 TO DISK ='\\Server1\Share\db1.trn' С INIT, КОМПРЕСИЯ; -- :CONNECT Server2ALTER ГРУПА НА НАЛИЧНОСТ [GroupName] ПРИСЪЕДИНЯВАНЕ; ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ База данни1 ОТ ДИСКА ='\\Server1\Share\db1.bak' СЪС ЗАМЯНА, БЕЗ ВЪЗСТАНОВЯВАНЕ, NOUNLOAD, ПРЕМЕСТВАНЕ 'data_file_name' КЪМ 'P:\path\file.mdf', ПРЕМЕСТВАНЕ 'log_file_name:\pa' КЪМ 'P:\path\file.mdf' \file.ldf'; ВЪЗСТАНОВЯВАНЕ НА дневника база данни1 ОТ ДИСК ='\\Server1\Share\db1.trn' С NORECOVERY, NOUNLOAD; ALTER DATABASE Database1 SET HADR AVAILABILITY GROUP =[GroupName];

Препятствие №2

Ако имате няколко екземпляра на един и същ сървър, може да откриете, че и двата екземпляра не могат да споделят порт 5022 за своята крайна точка на огледално отразяване на базата данни (която е същата крайна точка, която се използва от групите за наличност). Това означава, че ще трябва да пуснете и да създадете отново крайната точка, за да я настроите на наличен порт вместо това.

ИЗПУСКАНЕ НА КРАЙНА ТОЧКА [Hadr_endpoint];СЪЗДАДЕТЕ КРАЙНА ТОЧКА [Hadr_endpoint] СЪСТОЯНИЕ =ЗАПОЧНАЛО КАТО TCP ( LISTENER_PORT =5023 ) ЗА ОТРАЖДАНЕ НА DATABASE_MIRRORING (РОЛЯ =ВСИЧКИ);

Сега мога да посоча екземпляр с крайна точка на ServerName:5023 .

Препятствие №3

Въпреки това, след като направих това, когато стигнах до последната стъпка в скрипта по-горе, след точно 48 секунди – всеки път – ще получа това безполезно съобщение за грешка:

Това ме накара да преследвам всички видове потенциални проблеми – да проверявам защитните стени и SQL Server Configuration Manager, например, за всичко, което би блокирало портовете между екземпляри. Нада. Открих различни грешки в регистъра за грешки на SQL Server:

Опитът за влизане с огледално копиране на база данни е неуспешен с грешка:„Ръкостискането на връзката не бе успешно. Неуспешно извикване на ОС:(80090303) 0x80090303 (Посочената цел е неизвестна или недостижима). Състояние 66.'.

Възникна изчакване на връзката при опит за установяване на връзка с реплика на наличност „VM-AARON-1\AGDEMO“ с идентификатор [5AF5B58D-BBD5-40BB-BE69-08AC50010BE0]. Или съществува проблем с мрежата или защитната стена, или адресът на крайната точка, предоставен за репликата, не е крайната точка за огледално отразяване на базата данни на екземпляра на хост сървъра.

Оказва се (и благодарение на Thomas Stringer (@SQLife)), че този проблем е причинен от комбинация от симптоми:(a) Kerberos не е настроен правилно и (b) алгоритъмът за криптиране за hadr_endpoint, който създадох, е по подразбиране към RC4. Това би било добре, ако всички самостоятелни екземпляри също използваха RC4, но не бяха. Накратко, изоставих и създадох отново крайните точки отново , във всички случаи. Тъй като това беше лабораторна среда и всъщност нямах нужда от поддръжка на Kerberos (и тъй като вече бях инвестирал достатъчно време в тези проблеми, че не исках да преследвам и проблемите с Kerberos), настроих всички крайни точки да използвам Преговаряне с AES:

ПРОСТЪПНЕТЕ КРАЙНА ТОЧКА [Hadr_endpoint];СЪЗДАВАЙТЕ КРАЙНА ТОЧКА [Hadr_endpoint] СЪСТОЯНИЕ =ЗАПОЧНАЛО КАТО TCP ( LISTENER_PORT =5023 ) ЗА ОГРАЖДАНЕ НА DATABASE_MIRRORING ( АВТЕНТИКАЦИЯ =WINDOWS DOGOTIATE, ENCRYPTION =ROCHORITHLE ИЗИСКВА ВСИЧКИ ИЗИСКВАНЕ); 

 (Тед Крюгер (@onpnt) наскоро също публикува блог за подобен проблем.)
 

 Сега най-накрая успях да създам групи за наличност с всички различни изисквания, които имах, между възли с разнородни файлови пътеки и използвайки множество екземпляри на един и същ възел (само не в една и съща група). Ето един поглед към това как ще изглежда един от нашите изгледи за управление на AlwaysOn (щракнете, за да увеличите за много по-добър преглед):
 

 
 

 Сега, това е само малко закачка и е напълно умишлено. През следващите седмици ще пиша повече за тази функция!
 
Заключение
 

 Когато прекарвате достатъчно време в разглеждане на проблем, можете да пренебрегнете някои доста очевидни неща. В този случай имаше някои очевидни проблеми, скрити от някои направо неинтуитивни съобщения за грешки. Искам да благодаря на Джо Сак (@JosephSack), Алън Хърт (@SQLHA) и Томас Стрингер (@SQLife) за изоставянето на всичко, за да помогнат на колега от общността в нужда.