Strategie równoważenia obciążenia dla replik odczytu Amazon RDS dla SQL Server w celu skalowania obciążeń odczytu i zmniejszenia opóźnień

Usługa Amazon Relational Database Service (Amazon RDS) dla SQL Server ułatwia konfigurowanie, obsługę i skalowanie wdrożeń SQL Server w chmurze AWS. Usługa ta pozwala administratorom baz danych skupić się na zadaniach o wysokiej wartości, takich jak optymalizacja zapytań, tworzenie zapytań i projektowanie schematów, zamiast na czasochłonnych zadaniach związanych z administrowaniem bazą danych, w tym udostępnianiem, kopiami zapasowymi, łataniem oprogramowania, monitorowaniem i skalowaniem sprzętu.

Repliki odczytu Amazon RDS zwiększają wydajność i trwałość instancji baz danych RDS. Dane z podstawowej instancji DB są asynchronicznie replikowane do replik odczytu w czasie zbliżonym do rzeczywistego, umożliwiając skalowanie poza ograniczenia pojemności pojedynczej instancji DB dla obciążeń wymagających dużego odczytu. Można utworzyć jedną lub więcej replik danej źródłowej instancji DB i obsługiwać duży ruch odczytu aplikacji z wielu kopii danych. Dodatkowo można utworzyć do 15 replik odczytu w regionie i między regionami (ograniczenia) w celu skalowania Amazon RDS dla SQL Server.

W tym poście pokazujemy, jak równoważyć obciążenie i elastycznie skalować obciążenia odczytu za pomocą replik odczytu z Amazon RDS for SQL Server i Amazon Route 53.

Przegląd rozwiązania

Poniższy diagram przedstawia ogólny przegląd Amazon RDS for SQL Server w konfiguracji Multi-AZ przy użyciu grup dostępności Always On z jedną repliką odczytu w regionie i jedną repliką odczytu między regionami. Podstawowa instancja i replika odczytu w regionie są hostowane w różnych strefach dostępności w regionie, podczas gdy replika odczytu między regionami jest hostowana w innym regionie. Zmiany danych w podstawowej instancji DB są replikowane synchronicznie do rezerwowej instancji DB i asynchronicznie do replik odczytu.

Aby zarządzać dystrybucją ruchu między replikami odczytu w regionie i między regionami, używamyprywatnej strefy hostowanej przez Route 53 z zasadami routingu. Dodatkowo używamy rekordów CNAME prywatnej strefy hostowanej Route 53 do przechowywania punktów końcowych RDS dla SQL Server. Aplikacja łączy się z bazą danych za pomocą tych punktów końcowych rekordów CNAME.

Jeśli użytkownicy aplikacji są rozproszeni geograficznie, można wykorzystać repliki odczytu między regionami, aby zmniejszyć opóźnienia w sieci. Kierując użytkowników do punktu końcowego aplikacji znajdującego się najbliżej nich, ich zapytania są obsługiwane z regionu, który znajduje się bliżej ich lokalizacji. Pomaga to zminimalizować opóźnienia dla użytkowników wchodzących w interakcję z aplikacją, jednocześnie umożliwiając jej globalne skalowanie.

Możesz użyć ważonej polityki Route 53 do dystrybucji żądań odczytu między replikami odczytu. W ramach strefy dostępności hostowanej przez Route 53 można utworzyć indywidualne zestawy rekordów (takie jak CNAME) dla każdego punktu końcowego repliki odczytu DNS i nadać im taką samą wagę. Umożliwia to wysyłanie bezpośrednich żądań do wybranego punktu końcowego repliki odczytu.

Podczas tworzenia replik odczytu kopiowane są istniejące loginy, niestandardowe role serwera i zadania SQL w podstawowych instancjach DB. Jest to jednorazowa operacja podczas tworzenia repliki odczytu; wszelkie późniejsze zmiany lub nowe obiekty na poziomie serwera muszą być replikowane ręcznie, ponieważ nie są replikowane do replik w regionie lub między regionami. Jeśli którykolwiek ze skopiowanych obiektów poziomu serwera nie jest wymagany na replikach odczytu, należy go wyłączyć lub usunąć.

Przeanalizujmy trzy różne przypadki użycia, z których każdy wykorzystuje inną politykę routingu (routing ważony, routing opóźnień i routing geolokalizacji) w celu zrównoważenia obciążenia tylko do odczytu.

Używamy następujących szczegółów konfiguracji, aby wdrożyć to rozwiązanie równoważenia obciążenia przy użyciu Amazon RDS dla SQL Server i routingu Route 53:

• Podstawowa instancja musi być Multi-AZ z wersją Enterprise Edition, aby można było tworzyć repliki odczytu, a repliki odczytu są również w wersji Enterprise Edition.

• Potrzebujemy co najmniej dwóch replik odczytu, które mogą być w regionie, między regionami lub kombinacją. W naszym przykładzie mamy replikę odczytu w regionie w us-east-1 i replikę odczytu między regionami w ap-south-1.

W tym przykładzie używamy następujących punktów końcowych RDS dla SQL Server:

• Podstawowy - crrr-primary01.ckwu95yj2jxd.us-east-1.rds.amazonaws.com
• Replika w regionie - crrr-irreplica01.ckwu95yj2jxd.us-east-1.rds.amazonaws.com
• Replika międzyregionalna - crrr-xrreplica02.cxfvmitq9dpk.ap-south-1.rds.amazonaws.com

Tworzenie strefy hostowanej przez Route 53 dla aplikacji

Aby utworzyć strefę hostowaną przez Route 53 za pośrednictwem konsoli AWS Management Console, wykonaj następujące kroki:

1. W konsoli Route 53 wybierz Hosted zones w panelu nawigacji.
2. Wybierz opcję Utwórz strefę hostowaną.
3. Wprowadź nazwę domeny (na przykład com).
4. Określ typ jako Prywatna strefa hostowana.
5. Dodaj Regiony i odpowiadające im VPC zawierające repliki.
6. Wybierz opcję Utwórz strefę hostowaną.

Przypadek użycia 1: Równoważenie obciążenia przy użyciu prywatnych rekordów CNAME hostowanych przez Route 53 z routingiem ważonym

W naszym pierwszym przypadku użycia chcemy skalować poza ograniczenia pojemności pojedynczej instancji DB dla obciążeń bazy danych o dużym obciążeniu odczytem. Można użyć wielu replik odczytu danej źródłowej instancji DB i obsługiwać duży ruch odczytu aplikacji z wielu kopii danych, zwiększając w ten sposób zagregowaną przepustowość odczytu.

Utwórz hostowany rekord CNAME z ważonym routingiem, wykonując następujące kroki:

1. W konsoli Route 53 przejdź do utworzonej strefy hostowanej.
2. Wybierz opcję Utwórz rekord.
3. W polu Nazwa rekordu wprowadź nazwę (na przykład weightedread).
4. Jako typ rekordu wybierz CNAME.
5. Wprowadź jeden z punktów końcowych repliki odczytu usług RDS.
6. W polu Zasady routingu wybierz opcję Ważony.
7. W polu TTL wprowadź wartość 0.
8. Aby uzyskać równą dystrybucję sesji, można podzielić 100 przez liczbę replik odczytu (na przykład wprowadzić jeden z punktów końcowych repliki odczytu RDS).
9. W polu ID rekordu wprowadź unikatowy identyfikator (na przykład crrr-weightedread01).
10. Wybierz opcję Utwórz rekord.
11. Powtórz te kroki dla każdej repliki odczytu (zachowaj tę samą nazwę rekordu i ustawienia oraz podaj nazwę punktu końcowego repliki w polu wartości).

Powinieneś zobaczyć ważone rekordy, jak pokazano na poniższym zrzucie ekranu.

Podczas konfigurowania ciągu połączenia w aplikacji można użyć utworzonej wcześniej nazwy CNAME jako nazwy serwera. W poniższym kodzie uruchamiamy zapytanie SQL, aby wybrać nazwę serwera i bieżącą datę / godzinę i odczekać 1 minutę, aby zasymulować obciążenie aplikacji za pomocą sqlcmd:

sqlcmd -S weightedread.myapplication.com -d master -M -U admin -P <SQLLogin_Password> -Q „set nocount on Select @@Servername as [ServerName],Getdate() as [CollectionDate]; waitfor delay »00:01:00«;” -W

Teraz po uruchomieniu wielu sesji obciążenia sesje są dystrybuowane między replikami odczytu. Na przykład, można uruchomić łącznie 15 poleceń sqlcmd przy użyciu ważonego DNS, następujący fragment kodu za pośrednictwem pliku wsadowego:

@echo off

set loopcount=15

loop

sqlcmd -S weightedread.myapplication.com -d master -M -U admin -P „<SQLLogin_Password>” -Q „SET NOCOUNT ON SELECT @@Servername AS [ServerName], GETDATE() AS [CollectionDate]; WAITFOR delay »00:00:05«;” -W

set /a loopcount=loopcount-1

if %loopcount%==0 goto exitloop

goto loop

exitloop

pauza

Śledzenie liczby połączeń można wykonać, uruchamiając następujące zapytanie na każdej replice lub uruchamiając zapytanie wieloserwerowe na zarejestrowanych serwerach dla wszystkich replik odczytu:

--Connection Count Tracking 

select count(1) as [ConnectionCount] from sys.dm_exec_sessions where login_name='admin' and program_name='SQLCMD';

Widzimy, że obciążenie odczytu jest rozłożone na wiele replik odczytu.

Przypadek użycia 2: Równoważenie obciążenia przy użyciu prywatnych rekordów CNAME hostowanych przez Route 53 z routingiem opóźnień

Jeśli użytkownicy aplikacji są rozproszeni po całym świecie, można wykorzystać międzyregionalne repliki odczytu do obsługi zapytań odczytu dla dowolnego regionu hostującego replikę odczytu w oparciu o opóźnienie sieciowe tego użytkownika końcowego do regionu.

Aby utworzyć hostowany rekord CNAME z polityką routingu opóźnień, wykonaj następujące kroki:

1. W konsoli Route 53 przejdź do utworzonej strefy hostowanej.
2. Wybierz Utwórz rekord.
3. W polu Nazwa rekordu wprowadź nazwę (na przykład latencyread).
4. Jako typ rekordu wybierz CNAME.
5. Wprowadź punkt końcowy repliki odczytu usług RDS.
6. W polu Zasady routingu wybierz opcję Opóźnienie.
7. W polu TTL wprowadź wartość 0.
8. W polu Region wybierz region odpowiadający replice odczytu.
9. W polu ID rekordu wprowadź unikatowy identyfikator (na przykład crrr-latencyread01).
10. Wybierz opcję Utwórz rekord.
11. Powtórz te kroki dla każdej repliki odczytu (zachowaj tę samą nazwę rekordu i ustawienia oraz podaj nazwę punktu końcowego repliki w polu wartości).

Podczas konfigurowania ciągu połączenia w aplikacji można teraz użyć utworzonej wcześniej nazwy CNAME jako nazwy serwera. W poniższym przykładzie uruchamiamy zapytanie SQL, aby wybrać nazwę serwera i bieżącą datę / godzinę i odczekać 1 minutę, aby zasymulować obciążenie aplikacji za pomocą sqlcmd:

sqlcmd -S latencyread.myapplication.com -d master -M -U admin -P <SQLLogin_Password> -Q „set nocount on Select @@Servername as [ServerName],Getdate() as [CollectionDate]; waitfor delay »00:01:00«;” -W

Teraz uruchommy wiele sesji obciążenia odczytu z serwera aplikacji w różnych regionach, każdy bliżej innej repliki odczytu. W poniższym kodzie można uruchomić łącznie 15 poleceń sqlcmd (możemy dostosować zmienną dla większej liczby wykonań) przy użyciu ważonego DNS :

@echo off

set loopcount=15

loop

sqlcmd -S latencyread.myapplication.com -d master -M -U admin -P „<SQLLogin_Password>” -Q „SET NOCOUNT ON SELECT @@Servername AS [ServerName], GETDATE() AS [CollectionDate]; WAITFOR delay »00:00:05«;” -W

set /a loopcount=loopcount-1

if %loopcount%==0 goto exitloop

goto loop

exitloop

pauza

Aby śledzić liczbę połączeń, uruchom następujące zapytanie na każdej replice lub uruchom zapytanie wieloserwerowe na zarejestrowanych serwerach dla wszystkich replik odczytu:

--Connection Count Tracking 

select count(1) as [ConnectionCount] from sys.dm_exec_sessions where login_name='admin' and program_name='SQLCMD';

Zauważamy, że sesje są obsługiwane przez replikę odczytu znajdującą się w pobliżu serwera aplikacji, na którym uruchomiono obciążenie odczytu.

1) Wykonywanie obciążenia odczytu z serwera aplikacji w US-East-1

2) Wykonywanie obciążenia z serwera aplikacji w AP-South-1

Przypadek użycia 3: Równoważenie obciążenia przy użyciu prywatnych rekordów CNAME hostowanych przez Route 53 z routingiem geolokalizacyjnym

Jeśli użytkownicy aplikacji są rozproszeni po całym świecie, możesz chcieć zrównoważyć obciążenie w punktach końcowych w przewidywalny sposób, który jest łatwy w zarządzaniu, tak aby każde żądanie użytkownika było konsekwentnie kierowane do tego samego punktu końcowego i zapewniało przetwarzanie i przechowywanie danych w pożądanych granicach geograficznych, pomagając zachować zgodność z wymogami suwerenności danych. Zasad routingu geolokalizacji można używać do obsługi żądań odczytu z repliki odczytu RDS, która znajduje się w tym samym regionie.

Utwórz hostowany rekord CNAME z polityką routingu geolokalizacji, wykonując następujące kroki:

1. W konsoli Route 53 przejdź do utworzonej strefy hostowanej.
2. Wybierz opcję Utwórz rekord.
3. W polu Nazwa rekordu wprowadź nazwę (na przykład georead).
4. Jako typ rekordu wybierz CNAME.
5. Wprowadź punkt końcowy repliki odczytu RDS.
6. Dla zasady routingu wybierz Geolokalizacja.
7. W polu TTL wprowadź wartość 0.
8. W polu Lokalizacja wybierz odpowiednią lokalizację odpowiadającą replice odczytu (na przykład Ameryka Północna dla us-east-1).
9. W polu ID rekordu wprowadź unikatowy identyfikator (na przykład crrr-georead01).
10. Wybierz opcję Utwórz rekord.
11. Powtórz te kroki dla każdej repliki odczytu (zachowaj tę samą nazwę rekordu i ustawienia oraz podaj nazwę punktu końcowego repliki w polu wartości).

Podczas konfigurowania ciągu połączenia w aplikacji można teraz użyć utworzonej wcześniej nazwy CNAME jako nazwy serwera. W poniższym kodzie uruchamiamy zapytanie SQL, aby wybrać nazwę serwera i bieżącą datę / godzinę i odczekać 1 minutę, aby zasymulować obciążenie aplikacji za pomocą sqlcmd:

sqlcmd -S georead.myapplication.com -d master -M -U admin -P <SQLLogin_Password> -Q „set nocount on Select @@Servername as [ServerName],Getdate() as [CollectionDate]; waitfor delay »00:01:00«;” -W

Teraz uruchommy wiele sesji obciążenia odczytu z serwera aplikacji w różnych regionach, każdy w tej samej geolokalizacji, co inna replika odczytu. W poniższym kodzie można uruchomić łącznie 15 poleceń sqlcmd (możemy dostosować zmienną do większej liczby wykonań) przy użyciu ważonego DNS:

@echo off

set loopcount=15

loop

sqlcmd -S georead.myapplication.com -d master -M -U admin -P „<SQLLogin_Password>” -Q „SET NOCOUNT ON SELECT @@Servername AS [ServerName], GETDATE() AS [CollectionDate]; WAITFOR delay »00:00:05«;” -W

set /a loopcount=loopcount-1

if %loopcount%==0 goto exitloop

goto loop

exitloop

pauza

W celu śledzenia liczby połączeń można uruchomić następujące zapytanie na każdej replice lub uruchomić zapytanie wieloserwerowe na zarejestrowanych serwerach dla wszystkich replik odczytu:

--Connection Count Tracking 

select count(1) as [ConnectionCount] from sys.dm_exec_sessions where login_name='admin' and program_name='SQLCMD';

Zauważamy, że sesje są obsługiwane przez replikę odczytu w tej samej geolokalizacji co serwer aplikacji, na którym uruchomiono obciążenie odczytu.

1) Obciążenie wykonywane z serwera aplikacji w Stanach Zjednoczonych

2) Wykonywanie obciążenia z serwera aplikacji w Indiach

Poniższy zrzut ekranu pokazuje rekordy dla wszystkich trzech zasad routingu wyjaśnionych w przykładzie (routing ważony, routing opóźnień i routing geolokalizacji) w celu osiągnięcia równoważenia obciążenia tylko do odczytu.

Czyszczenie

Aby uniknąć przyszłych opłat, usuń zasoby utworzone w ramach tego postu:

1. Aby usunąć Amazon RDS for SQL Server, zapoznaj się z sekcją Zakończ instancję RDS.
2. Aby usunąć instancję EC2, zapoznaj się z sekcją Zakończ instancję EC2.
3. Aby usunąć Route 53 , zapoznaj się z Zakończ prywatną strefę hostowaną

Podsumowanie

W tym poście opisaliśmy strategie równoważenia obciążenia aplikacji odczytem przy użyciu replik odczytu Route 53 i RDS dla SQL Server. Omówiliśmy przypadki użycia dla każdej strategii, pokazując, jak wykorzystać różne zasady routingu strefy hostowanej prywatnie Route 53, aby kierować ruch do odpowiednich punktów końcowych bazy danych. Rozwiązanie to zapewnia spójny, wspólny punkt końcowy dla aplikacji bez konieczności wprowadzania zmian w konfiguracji aplikacji w oparciu o lokalizację użytkownika końcowego.

Wypróbuj to rozwiązanie na swoim koncie AWS. Jeśli masz jakieś uwagi lub pytania, zostaw je w sekcji komentarzy.

Źródło: AWS