Сега, когато групите за наличност стават все по-разпространени, реших да покрия тема, която може да бъде пренебрегната по време на първоначалното планиране и инсталиране на SQL Server в този тип среда. За да имате наистина устойчива на грешки конфигурация, трябва да се замислите и планирате в настройката на свързаността с базата данни.
Няма да навлизам в подробностите за настройката на вашата AlwaysOn среда в тази публикация, но за допълнителна помощ ви предлагам да разгледате публикацията на Aaron Bertrand „Отстраняване на неизправности AlwaysOn – Понякога отнема много групи очи“. След като вашата среда е конфигурирана, следващата стъпка в осигуряването на свързаност към базата данни е да създадете слушател на групата наличност с помощта на SQL Management Studio или T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
низове за свързване на слушател на AG
Вашето виртуално мрежово име (VNN) е регистрирано в DNS и винаги е собственост на екземпляра на SQL Server, където се намира основната реплика. Всички IP адреси, които се предоставят при конфигурирането на AG Listener, се регистрират в DNS под едно и също име на виртуална мрежа.
След като създадете своя AG Listener, трябва да се уверите, че вашите клиенти могат да се свързват. Връзката с приложението ви работи по същия начин, както винаги, но вместо да насочвате към конкретен сървър във вашия низ за връзка, вие сочите към AG Listener.
Слушателите на AG могат да бъдат свързани само с TCP и се разрешават от вашия локален DNS към списъка с IP адреси и TCP портове, които са съпоставени с VNN. Вашият клиент ще се опита да се свърже с всеки от IP адресите на свой ред, докато не получи връзка или докато достигне изтичане на времето за изчакване на връзката. Важен параметър на низ за свързване, който трябва да обмислите използването, е MultiSubnetFailover. Ако този параметър е зададен на true, клиентът ще опита паралелно свързване, позволявайки по-бърза свързаност и, ако е необходимо, по-бързо преминаване при отказ на клиента:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Когато възникне отказ, клиентските връзки се нулират и собствеността върху AG Listener се премества към екземпляра на SQL Server, който поема ролята на основната реплика. След това крайната точка на VNN е обвързана с новите IP адреси и TCP портове на новата първична копия. В зависимост от клиента ще се случи автоматично повторно свързване към AG или може да се наложи потребителят да рестартира ръчно засегнатото приложение или връзка.
Намерение на приложението
Една от най-големите причини за внедряване на Групи за наличност е предоставянето на възможност за използване на вашите среди за архивиране или възстановяване след бедствие, за да разтоварите работата от вашата производствена среда. Тези сървъри вече могат да се използват за архивиране, анализ, ad-hoc заявки и отчитане или всяка друга операция, при която е достатъчно копие на базата данни само за четене.
За да осигурите достъп само за четене до вашите вторични реплики, се използва параметърът ApplicationIntent низ за връзка. За всяка реплика може да бъде конфигуриран допълнителен списък за маршрутизиране само за четене от крайни точки на SQL Server. Този списък се използва за пренасочване на заявки за свързване на клиенти, които използват параметъра ApplicationIntent=ReadOnly, към първата налична вторична реплика, която е конфигурирана с подходящ филтър за намерение на приложението.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Филтриране на намеренията на приложението
За да се улесни намерението на приложението от клиентите, свързващи се с вашата група за наличност, всеки екземпляр на SQL Server в групата трябва да бъде конфигуриран с подходящ филтър за намерение на приложението. Филтърът определя кои типове връзки ще приеме всяка реплика.
Основна реплика, която е конфигурирана да има връзки в Основна роля на „Разрешаване на всички връзки“, ще приема всички връзки, направени чрез AG Listener. Основна реплика, конфигурирана като „Разрешаване на връзки за четене/запис“, ще отхвърли всяка връзка, която посочва „ApplicationIntent=ReadOnly“.
Когато конфигурирате реплики, вие също трябва да дефинирате дали всяка от тях ще бъде Четем вторичен. Реплика, която е конфигурирана като „Не“, ще откаже всички връзки. Предполага се, че тази реплика ще се използва само за преодоляване на срив в ситуация на възстановяване след бедствие. Ако вторичната реплика е конфигурирана като „Да“, всички връзки ще бъдат разрешени, но само за достъп за четене, дори ако „ApplicationIntent=ReadOnly“ не е посочено. И накрая, ако вторичният е конфигуриран като „намерение само за четене“, само клиенти, които посочат „ApplicationIntent=ReadOnly“, ще имат право да се свързват.
Маршрутизация само за четене
Сега, когато знаем как да конфигурираме Application Intent на екземпляри на сървъра и да създадем необходимите низове за връзка, трябва да конфигурираме маршрутизиране само за четене на Availability Group. Когато се свържете с AG Listener, като използвате низа за свързване, както е дефиниран по-горе, слушателят отправя заявка към първичния екземпляр на реплика и определя дали връзката трябва да бъде осъществена към първичния (четене/запис) или към вторичен само за четене. За да се постигне това, трябва да се създаде списък за маршрутизиране за ВСЯКА реплика за наличност, която се използва, ако и когато репликата поеме ролята на първична. Обикновено най-добрата практика е да включите всеки URL адрес за маршрутизиране само за четене за всяка вторична реплика само за четене с URL адреса на локалната реплика в края на списъка. Заявките за връзка с намерение за четене се насочват към първия наличен за четене вторичен ресурс в списъка с маршрути, няма балансиране на натоварването между вторичните.
Първо, модифицирайте всяка реплика, за да предоставите маршрутизиращия URL адрес само за четене:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
Второ, модифицирайте всяка реплика, за да предоставите списъка за маршрутизиране само за четене, който да се използва, когато дадената реплика е в основната роля:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); URL адресът за маршрутизиране трябва да бъде под формата на „TCP://:“. За помощ при определянето на вашия URL адрес вижте този блог и скрипт, създаден от Matt Neerincx.
Заключение
С конфигурираната ви маршрутизация само за четене, създаден AG Listener и вашите клиентски приложения, използващи правилните низове за връзка, трябва да имате напълно устойчива на грешки връзка за вашата група за наличност. Уверете се, че сте отделили известно време, за да тествате вашата свързаност и способността на вашите приложения да следват сървърите ви, когато те се провалят.
