Конфигуриране на специална мрежа за групова комуникация за наличност

Групите за наличност на SQL Server 2012 AlwaysOn изискват крайна точка за огледално отразяване на база данни за всеки екземпляр на SQL Server, който ще хоства реплика на група за наличност и/или сесия за огледално копиране на база данни. Тази крайна точка на екземпляр на SQL Server след това се споделя от една или повече реплики на групи за достъпност и/или сесии за огледално отразяване на база данни и е механизмът за комуникация между първичната реплика и свързаните вторични реплики.

В зависимост от работните натоварвания за промяна на данни на първичната реплика, изискванията за пропускателна способност за групови съобщения за наличност могат да бъдат нетривиални. Тази дейност също е чувствителна към трафика от едновременна групова дейност за липса на наличност. Ако пропускателната способност страда поради влошена честотна лента и едновременен трафик, може да помислите за изолиране на трафика на групата за наличност към неговия собствен специален мрежов адаптер за всеки екземпляр на SQL Server, хостващ реплика за наличност. Тази публикация ще опише този процес и също така накратко ще опише какво може да очаквате да видите при сценарий с влошена производителност.

За тази статия използвам виртуален гост Windows Server Failover Cluster (WSFC) с пет възела. Всеки възел в WSFC има свой собствен самостоятелен екземпляр на SQL Server, използващ несподелено локално хранилище. Всеки възел също има отделен виртуален мрежов адаптер за обществена комуникация, виртуален мрежов адаптер за WSFC комуникация и виртуален мрежов адаптер, който ще посветим на комуникацията на групата за достъпност. За целите на тази публикация ще се съсредоточим върху информацията, необходима за специалните мрежови адаптери на групата наличност на всеки възел:

Създаването на група за наличност с помощта на специален NIC е почти идентично с процеса на споделен NIC, само за да „свържа“ групата за достъпност към конкретна NIC, първо трябва да посоча LISTENER_IP аргумент в CREATE ENDPOINT команда, използвайки гореспоменатите IP адреси за моите специални NIC. По-долу е показано създаването на всяка крайна точка в петте WSFC възела:

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

След като създам тези крайни точки, свързани със специалната NIC, останалите ми стъпки в настройката на топологията на групата за наличност не се различават от тази в сценария за споделен NIC.

След като създам моята група за наличност, ако започна да управлявам натоварването за промяна на данни спрямо основните бази данни за наличност на реплика, мога бързо да видя, че комуникационният трафик на групата за наличност протича в специалната NIC, използвайки Task Manager в раздела за работа в мрежа (първият раздел е пропускателната способност за специалната NIC група за достъпност):

И мога също да проследявам статистиката, използвайки различни броячи на производителността. На изображението по-долу Inetl[R] PRO_1000 MT Network Connection _2 е моята специална NIC за група за достъпност и има по-голямата част от трафика на NIC в сравнение с другите две NIC:

Сега наличието на специална NIC за групов трафик за наличност може да бъде начин за изолиране на активността и теоретично подобряване на производителността, но ако вашият специален NIC има недостатъчна честотна лента, както бихте очаквали, производителността ще пострада и здравето на топологията на групата за достъпност ще се влоши.

Например, промених специалната група за достъпност NIC на основната реплика на 28,8 Kbps изходяща честотна лента за трансфер, за да видя какво ще се случи. Излишно е да казвам, че не беше добре. Пропускателната способност на NIC на групата за достъпност намаля значително:

В рамките на няколко секунди здравето на различните реплики се влоши, като няколко от репликите се преместиха в състояние „не синхронизиране“:

Увеличих специалната NIC на основната реплика до 64 Kbps и след няколко секунди имаше и първоначален скок на наваксване:

Въпреки че нещата се подобриха, станах свидетел на периодични прекъсвания и здравни предупреждения при тази по-ниска настройка на пропускателната способност на NIC:

Какво ще кажете за свързаните статистики за чакане на първичната реплика?

Когато имаше много честотна лента на специалната NIC и всички реплики на наличност бяха в изправно състояние, видях следното разпределение по време на зареждането на данни за период от 2 минути:

HADR_WORK_QUEUE представлява очаквана фонова работна нишка, която чака нова работа. HADR_LOGCAPTURE_WAIT представлява друго очаквано изчакване, за да станат достъпни нови записи в дневника и според Books Online се очаква, ако сканирането на регистрационния файл бъде наваксано или се чете от диск.

Когато намалих пропускателната способност на NIC достатъчно, за да доведа групата за достъпност до нездравословно състояние, разпределението на типа на чакане беше както следва:

Вече виждаме нов тип най-голямо чакане, HADR_NOTIFICATION_DEQUEUE . Това е един от онези типове изчакване „само за вътрешна употреба“, както е дефинирано от Books Online, представляващи фонова задача, която обработва WSFC известия. Интересното е, че този тип изчакване не сочи директно към проблем и въпреки това тестовете показват, че този тип чакане се издига до върха във връзка с влошената пропускателна способност за групови съобщения за наличност.

Така че в крайна сметка изолирането на вашата групова дейност за наличност към специална NIC може да бъде от полза, ако осигурявате мрежова пропускателна способност с достатъчна честотна лента. Въпреки това, ако не можете да гарантирате добра честотна лента дори с помощта на специална мрежа, здравето на топологията на вашата група за достъпност ще пострада.