Konfigurowanie sieci dedykowanej do komunikacji w grupie dostępności

Grupy dostępności AlwaysOn programu SQL Server 2012 wymagają punktu końcowego dublowania bazy danych dla każdego wystąpienia programu SQL Server, które będzie obsługiwać replikę grupy dostępności i/lub sesję dublowania bazy danych. Ten punkt końcowy wystąpienia programu SQL Server jest następnie współużytkowany przez co najmniej jedną replikę grupy dostępności i/lub sesję dublowania bazy danych i stanowi mechanizm komunikacji między repliką podstawową a skojarzonymi replikami pomocniczymi.

W zależności od obciążeń modyfikacji danych w replice podstawowej wymagania dotyczące przepływności komunikatów grupy dostępności mogą być nietrywialne. Ta aktywność jest również wrażliwa na ruch z równoczesnej aktywności grupy braku dostępności. Jeśli przepływność jest słaba z powodu obniżonej przepustowości i współbieżnego ruchu, można rozważyć wyizolowanie ruchu grupy dostępności do własnej dedykowanej karty sieciowej dla każdego wystąpienia programu SQL Server obsługującego replikę dostępności. W tym poście opiszemy ten proces, a także pokrótce opiszemy, czego można się spodziewać w scenariuszu z obniżoną przepustowością.

W tym artykule używam pięciowęzłowego wirtualnego gościa Windows Server Failover Cluster (WSFC). Każdy węzeł w WSFC ma własną autonomiczną instancję programu SQL Server korzystającą z nieudostępnianego magazynu lokalnego. Każdy węzeł ma również oddzielną wirtualną kartę sieciową do komunikacji publicznej, wirtualną kartę sieciową do komunikacji WSFC oraz wirtualną kartę sieciową, którą poświęcimy komunikacji z grupami dostępności. Na potrzeby tego postu skupimy się na informacjach potrzebnych dla dedykowanych kart sieciowych dla grupy dostępności w każdym węźle:

Konfigurowanie grupy dostępności przy użyciu dedykowanej karty sieciowej jest prawie identyczne z procesem współużytkowanej karty sieciowej, tylko aby „powiązać” grupę dostępności z konkretną kartą sieciową, najpierw muszę wyznaczyć LISTENER_IP argument w CREATE ENDPOINT polecenie, używając wyżej wymienionych adresów IP dla moich dedykowanych kart sieciowych. Poniżej przedstawiono tworzenie każdego punktu końcowego w pięciu węzłach 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...

Po utworzeniu tych punktów końcowych skojarzonych z dedykowaną kartą sieciową pozostałe moje kroki w konfigurowaniu topologii grupy dostępności nie różnią się od scenariusza ze współużytkowaną kartą sieciową.

Po utworzeniu mojej grupy dostępności, jeśli zacznę sterować ładowaniem modyfikacji danych w bazach danych dostępności repliki podstawowej, mogę szybko zobaczyć, że ruch komunikacyjny grupy dostępności przepływa na dedykowanej karcie sieciowej za pomocą Menedżera zadań na karcie sieci (pierwsza sekcja to przepustowość dla dedykowanej karty sieciowej grupy dostępności):

Mogę też śledzić statystyki za pomocą różnych liczników wydajności. Na poniższym obrazku Inetl[R] PRO_1000 MT Network Connection _2 to moja dedykowana karta sieciowa grupy dostępności i ma większość ruchu sieciowego w porównaniu z dwiema innymi kartami sieciowymi:

Teraz posiadanie dedykowanej karty sieciowej dla ruchu grup dostępności może być sposobem na wyizolowanie aktywności i teoretycznie poprawę wydajności, ale jeśli dedykowana karta sieciowa ma niewystarczającą przepustowość, można się spodziewać, że ucierpi wydajność i stan topologii grupy dostępności ulegnie pogorszeniu.

Na przykład zmieniłem dedykowaną kartę sieciową grupy dostępności w replice podstawowej na przepustowość transmisji wychodzącej 28,8 Kb/s, aby zobaczyć, co się stanie. Nie trzeba dodawać, że nie było dobrze. Przepustowość karty sieciowej grupy dostępności znacznie spadła:

W ciągu kilku sekund kondycja różnych replik uległa pogorszeniu, a kilka replik przeszło w stan „brak synchronizacji”:

Zwiększyłem dedykowaną kartę sieciową w replice podstawowej do 64 Kb/s i po kilku sekundach nastąpił również początkowy skok nadrabiania zaległości:

Chociaż sytuacja się poprawiła, zauważyłem okresowe rozłączenia i ostrzeżenia zdrowotne przy tym niższym ustawieniu przepustowości karty sieciowej:

A co z powiązanymi statystykami oczekiwania w replice podstawowej?

Gdy na dedykowanej karcie sieciowej było dużo przepustowości, a wszystkie repliki dostępności były w dobrym stanie, podczas ładowania danych w ciągu 2 minut zauważyłem następujący rozkład:

HADR_WORK_QUEUE reprezentuje oczekiwany wątek roboczy w tle oczekujący na nową pracę. HADR_LOGCAPTURE_WAIT reprezentuje kolejne oczekiwane oczekiwanie na udostępnienie nowych rekordów dziennika i według Books Online jest oczekiwane, jeśli skanowanie dziennika zostanie przechwycone lub jest odczytywane z dysku.

Kiedy zmniejszyłem przepustowość karty sieciowej na tyle, aby doprowadzić grupę dostępności do złego stanu, dystrybucja typu oczekiwania wyglądała następująco:

Widzimy teraz nowy typ oczekiwania, HADR_NOTIFICATION_DEQUEUE . Jest to jeden z tych typów oczekiwania „tylko do użytku wewnętrznego” zdefiniowanych przez Books Online, reprezentujący zadanie w tle, które przetwarza powiadomienia WSFC. Co ciekawe, ten typ oczekiwania nie wskazuje bezpośrednio na problem, a jednak testy pokazują, że ten typ oczekiwania wznosi się na szczyt w związku z obniżoną przepustowością przesyłania komunikatów grupowych o dostępności.

Podsumowując, izolowanie aktywności grupy dostępności do dedykowanej karty sieciowej może być korzystne, jeśli zapewniasz przepustowość sieci o wystarczającej przepustowości. Jeśli jednak nie możesz zagwarantować dobrej przepustowości nawet przy użyciu sieci dedykowanej, ucierpi stan topologii grupy dostępności.