Architektura zarządzanej usługi Redis platformy Azure

Usługa Azure Managed Redis działa na stosie Redis Enterprise , który oferuje znaczne korzyści w porównaniu z wersją Community Edition usługi Redis. Poniższe informacje zawierają więcej szczegółowych danych na temat sposobu, w jaki usługa Azure Managed Redis jest zaprojektowana, w tym informacje, które mogą być przydatne dla zaawansowanych użytkowników.

Porównanie z usługą Azure Cache for Redis

Warstwy Podstawowa, Standardowa i Premium usługi Azure Cache for Redis zostały utworzone w wersji Community Edition usługi Redis. Ta wersja społecznościowa Redis ma kilka znaczących ograniczeń, w tym to, że jest jednowątkowa. Znacznie zmniejsza to wydajność i sprawia, że skalowanie jest mniej wydajne, ponieważ więcej procesorów wirtualnych nie jest w pełni wykorzystywane przez usługę. Typowe wystąpienie usługi Azure Cache for Redis używa architektury podobnej do następującej:

Zwróć uwagę, że dwie maszyny wirtualne są używane — podstawowa i replika. Te maszyny wirtualne są również nazywane "węzłami". Węzeł podstawowy przechowuje główny proces usługi Redis i akceptuje wszystkie operacje zapisu. Replikacja jest przeprowadzana asynchronicznie na węzeł repliki w celu zapewnienia kopii zapasowej podczas konserwacji, skalowania lub nieoczekiwanej awarii. Każdy węzeł może uruchamiać tylko jeden proces serwera Redis ze względu na projekt jednowątkowy Redis społeczności.

Ulepszenia architektury usługi Azure Managed Redis

Usługa Azure Managed Redis korzysta z bardziej zaawansowanej architektury, która wygląda mniej więcej tak:

Istnieje kilka różnic:

• Każda maszyna wirtualna (lub "węzeł") uruchamia wiele procesów serwera Redis (nazywanych "fragmentami") równolegle. Wiele fragmentów umożliwia bardziej wydajne wykorzystanie wirtualnych jednostek centralnych (vCPU) na każdej maszynie wirtualnej oraz zwiększa wydajność.
• Nie wszystkie podstawowe fragmenty usługi Redis znajdują się na tej samej maszynie wirtualnej/węźle. Zamiast tego fragmenty podstawowe i repliki są rozproszone pomiędzy oboma węzłami. Ponieważ podstawowe fragmenty korzystają z większej liczby zasobów procesora NIŻ fragmenty repliki, takie podejście umożliwia równoległe uruchamianie większej liczby podstawowych fragmentów.
• Każdy węzeł ma wysokowydajny proces proxy do zarządzania fragmentami, zarządzania połączeniami i uruchamiania samoleczenia.

Ta architektura zapewnia zarówno wyższą wydajność, jak i zaawansowane funkcje, takie jak aktywna replikacja geograficzna

Klastrowanie

Każde wystąpienie usługi Azure Managed Redis jest wewnętrznie skonfigurowane do używania klastrowania we wszystkich warstwach i jednostkach SKU. Usługa Azure Managed Redis jest oparta na usłudze Redis Enterprise, która może używać wielu fragmentów na węzeł. Obejmuje to mniejsze wystąpienia, które są skonfigurowane tylko do używania pojedynczego fragmentu. Klastrowanie to sposób dzielenia danych w instancji Redis na wiele procesów Redis, nazywanych również "fragmentami". Platforma Azure Managed Redis oferuje trzy polityki klastrowania, które określają, który protokół jest dostępny dla klientów Redis do połączenia z instancją pamięci podręcznej.

Zasady klastra

Usługa Azure Managed Redis oferuje trzy zasady klastrowania: OSS, Enterprise i bez klastrowania (wersja zapoznawcza). Zasady klastra systemu operacyjnego są zalecane w przypadku większości aplikacji, ponieważ obsługują wyższą maksymalną przepływność, ale istnieją zalety i wady każdej wersji.

Zasady klastrowania systemu operacyjnego implementują ten sam interfejs API klastra Redis co warstwy usługi Azure Cache for Redis. Interfejs klastrowy Redis API pozwala klientowi Redis bezpośrednio łączyć się z shardami na każdym nodzie Redis, co minimalizuje opóźnienia i optymalizuje przepływność sieciową, pozwalając na niemal liniowe skalowanie przepływności w miarę wzrostu liczby shardów i vCPU. Zasady klastrowania systemu operacyjnego ogólnie zapewniają najlepsze opóźnienia i wydajność przepływności. Jednak zasady klastra systemu operacyjnego wymagają biblioteki klienta do obsługi interfejsu API klastra Redis. Obecnie prawie wszyscy klienci usługi Redis obsługują interfejs API klastra Redis, ale zgodność może być problemem ze starszymi wersjami klienta lub wyspecjalizowanymi bibliotekami.

Nie można używać zasad klastrowania systemu operacyjnego z modułem RediSearch.

Protokół klastrowania OSS wymaga, aby klient nawiązał poprawne połączenia shardów. Początkowe połączenie odbywa się za pośrednictwem portu 10000. Nawiązywanie połączenia z poszczególnymi węzłami odbywa się przy użyciu portów w zakresie 85XX. Porty 85xx mogą się zmieniać w czasie i nie powinny być zakodowane w aplikacji. Klienci usługi Redis, którzy obsługują klastrowanie, używają polecenia CLUSTER NODES, aby określić dokładne porty używane dla podstawowych i replikowych fragmentów oraz nawiązać połączenia z fragmentami.

Zasady klastrowania przedsiębiorstwa to prostsza konfiguracja, która korzysta z jednego punktu końcowego dla wszystkich połączeń klientów. Korzystanie z polityki klastrowania Enterprise kieruje wszystkie żądania do pojedynczego węzła Redis, który jest następnie używany jako serwer proxy, kierując żądania wewnętrznie do poprawnego węzła w klastrze. Zaletą tego podejścia jest to, że usługa Azure Managed Redis wygląda bez klastrowania dla użytkowników. Oznacza to, że biblioteki klienckie usługi Redis nie muszą obsługiwać klastrowania Redis, aby uzyskać niektóre zalety wydajności usługi Redis Enterprise. Użycie pojedynczego punktu końcowego poprawia zgodność wsteczną i upraszcza połączenie. Wadą jest to, że pojedynczy węzeł proxy może być wąskim gardłem w przypadku wykorzystania zasobów obliczeniowych lub przepustowości sieci.

Polityka klastrowania Enterprise jest jedyną polityką, która może być używana z modułem RediSearch. Chociaż polityka klastra Enterprise powoduje, że instancja Azure Managed Redis wydaje się nie być klastrowana dla użytkowników, nadal ma pewne ograniczenia w przypadku komend wielokluczowych.

Zasady klastrowania bez klastrowania (wersja zapoznawcza) przechowują dane w każdym węźle bez fragmentowania. Dotyczy tylko pamięci podręcznych o rozmiarze 25 GB i mniejszych. Scenariusze korzystania z zasad klastrowania bez klastra (wersja zapoznawcza) obejmują:

• Podczas migracji ze środowiska Redis, które nie jest podzielone na fragmenty. Na przykład nieuparte na fragmenty topologie jednostek SKU w warstwie Podstawowa, Standardowa i Premium usługi Azure Cache for Redis.
• Podczas częstego uruchamiania poleceń krzyżujących sloty i dzielenia danych na fragmenty mogą wystąpić błędy. Na przykład komendy MULTI.
• Podczas używania usługi Redis jako brokera komunikatów i bez potrzeby fragmentacji.

Zagadnienia dotyczące korzystania z zasad innych niż klastrowane (wersja zapoznawcza) to:

• Dotyczy to tylko warstw usługi Azure Managed Redis, które są mniejsze lub równe 25 GB.
• Nie jest tak wydajne, jak inne zasady klastrowania, ponieważ procesory CPU mogą korzystać z wielowątkowości z oprogramowaniem Redis Enterprise Software tylko wtedy, gdy pamięć podręczna jest dzielona na fragmenty.
• Jeśli chcesz zwiększyć skalę pamięci podręcznej Azure Managed Redis Cache, musisz najpierw zmienić zasady klastra.
• Jeśli przenosisz się z nieklastrowanej topologii podstawowej, standardowej lub Premium, rozważ użycie klastrów OSS w celu zwiększenia wydajności. Konfiguracje nieklaterowane powinny być używane tylko wtedy, gdy aplikacja nie może obsługiwać topologii systemu operacyjnego lub przedsiębiorstwa.

Skalowanie w górę lub dodawanie węzłów

Podstawowe oprogramowanie Redis Enterprise umożliwia skalowanie w górę (przy użyciu większych maszyn wirtualnych) lub skalowanie poziome (przez dodanie większej liczby węzłów/maszyn wirtualnych). Ostatecznie każda akcja skalowania osiąga to samo — dodanie większej ilości pamięci, większej liczby procesorów wirtualnych i większej liczby fragmentów. Ze względu na tę nadmiarowość usługa Azure Managed Redis nie oferuje możliwości kontrolowania określonej liczby węzłów używanych w każdej konfiguracji. Ten szczegół implementacji jest abstrakcyjny dla użytkownika, aby uniknąć nieporozumień, złożoności i nieoptymalnych konfiguracji. Zamiast tego każda jednostka SKU jest zaprojektowana z konfiguracją węzła, aby maksymalnie wykorzystać vCPU i pamięć. Niektóre jednostki SKU usługi Azure Managed Redis używają tylko dwóch węzłów, a niektóre używają więcej.

Polecenia wieloklawiszowe

Ponieważ wystąpienia usługi Azure Managed Redis są zaprojektowane z konfiguracją klastrowaną, można zauważyć CROSSSLOT wyjątki podczas wykonywania poleceń, które działają na wielu kluczach. Zachowanie różni się w zależności od używanych zasad klastrowania. Jeśli używasz zasad klastrowania systemu operacyjnego, polecenia wieloklawiszowe wymagają mapowania wszystkich klawiszy do tego samego gniazda.

Mogą również występować błędy CROSSSLOT związane z zasadami klastrowania przedsiębiorstwa. Tylko następujące polecenia wieloklawiszowe są dozwolone w różnych slotach z klastrowaniem na poziomie korporacyjnym: DEL, MSET, MGET, EXISTS, UNLINK i TOUCH.

W bazach danych Active-Active, polecenia zapisu z wieloma kluczami (DEL, MSET, UNLINK) mogą być uruchamiane tylko na kluczach, które znajdują się w tym samym slocie. Jednak następujące polecenia wieloklawiszowe są dozwolone w różnych przedziałach w bazach danych Aktywny-Aktywny: MGET, EXISTS i TOUCH. Aby uzyskać więcej informacji, zobacz Klastrowanie baz danych.

Konfiguracja fragmentowania

Każda jednostka SKU usługi Azure Managed Redis jest skonfigurowana do uruchamiania określonej liczby procesów serwera Redis, czyli fragmentów, działających równolegle. Relacja między wydajnością przepustowości, liczbą shardów i liczbą vCPU dostępnych w każdym wystąpieniu jest skomplikowana. Dodawanie fragmentów zwykle zwiększa wydajność, ponieważ operacje usługi Redis mogą być uruchamiane równolegle. Jeśli jednak fragmenty danych nie mogą wykonywać poleceń, ponieważ brak jest dostępnych procesorów wirtualnych do wykonywania tych poleceń, wydajność może faktycznie spaść. W poniższej tabeli przedstawiono konfigurację fragmentowania dla każdej jednostki SKU zarządzanej usługi Redis platformy Azure. Te fragmenty są mapowane w celu zoptymalizowania użycia poszczególnych procesorów wirtualnych podczas rezerwowania cykli procesorów wirtualnych dla serwera proxy usługi Redis Enterprise, agenta zarządzania i systemu operacyjnego, które również wpływają na wydajność.

Uwaga / Notatka

Usługa Azure Managed Redis optymalizuje wydajność w czasie, zmieniając liczbę fragmentów i procesorów wirtualnych używanych w każdej jednostce SKU.

Ważne

Wszystkie warstwy pamięci korzystające z ponad 120 GB miejsca do magazynowania są dostępne w publicznej wersji zapoznawczej, w tym zoptymalizowane pod kątem pamięci M150 i wyższe; zrównoważone B150 i wyższe; oraz zoptymalizowane pod kątem obliczeń X150 i wyższe. Wszystkie te warstwy i wyższe są dostępne w publicznej wersji zapoznawczej.

Wszystkie warstwy zoptymalizowane pod kątem technologii Flash są w publicznej wersji zapoznawczej.

Poziomy	Zoptymalizowane dla pamięci flash (przegląd)	Zoptymalizowane pod kątem pamięci	Zrównoważone	Zoptymalizowane pod kątem obliczeń
Rozmiar (GB)	Procesory wirtualne/podstawowe fragmenty	Procesory wirtualne/podstawowe fragmenty	Procesory wirtualne/podstawowe fragmenty	Procesory wirtualne/podstawowe fragmenty
0,5	-	-	2/1	-
1	-	-	2/1	-
3	-	-	2/2	4/2
6	-	-	2/2	4/2
12	-	2/2	4/2	8/6
24	-	4/2	8/6	16.12
60	-	8/6	16.12	32/24
120	-	16.12	32/24	64/48
180 *	-	24/24	48/48	96/96
240 *	8/6	32/24	64/48	128/96
360 *	-	48/48	96/96	192/192
480 *	16.12	64/48	128/96	256/192
720 *	24/24	96/96	192/192	384/384
960 *	32/24	128/192	256/192	-
1440 *	48/48	192/192	-	-
1920 *	64/48	256/192	-	-
4500 *	144/96	-	-	-

* Te warstwy są dostępne w publicznej wersji zapoznawczej.

Uruchamianie bez włączonego trybu wysokiej dostępności

Można uruchomić bez włączonego trybu wysokiej dostępności (HA). Oznacza to, że wystąpienie usługi Redis nie ma włączonej replikacji i nie ma dostępu do umowy SLA dotyczącej dostępności. Nie zalecamy uruchamiania w trybie nie-HA poza scenariuszami deweloperskimi i testowymi. Nie można wyłączyć wysokiej dostępności w wystąpieniu, które zostało już utworzone. Możesz jednak włączyć wysoką dostępność w wystąpieniu, które jej nie ma. Ponieważ wystąpienie działające bez wysokiej dostępności używa mniejszej liczby maszyn wirtualnych/węzłów, wirtualne CPU nie mogą być używane tak wydajnie, więc wydajność może być niższa.

Pamięć zarezerwowana

W każdym wystąpieniu usługi Azure Managed Redis około 20% dostępnej pamięci jest zarezerwowane jako bufor dla operacji niebuforowych, takich jak replikacja w trybie failover i bufor aktywnej replikacji geograficznej. Ten bufor pomaga zwiększyć wydajność pamięci podręcznej i zapobiegać głodowaniu pamięci.

Zmniejszanie

Skalowanie w dół nie jest obecnie obsługiwane w usłudze Azure Managed Redis. Aby uzyskać więcej informacji, zobacz Ograniczenia skalowania usługi Azure Managed Redis.

Warstwa zoptymalizowana dla flash

Warstwa zoptymalizowana dla pamięci flash korzysta zarówno z magazynu flash NVMe, jak i pamięci RAM. Ponieważ magazyn flash jest tańszy, użycie warstwy zoptymalizowanej pod kątem Flash pozwala na kompromis między wydajnością a efektywnością kosztową.

W przypadku instancji zoptymalizowanych pod kątem Flash 20% miejsca w pamięci podręcznej znajduje się w pamięci RAM, a pozostałe 80% używa pamięci Flash. Wszystkie klucze są przechowywane w pamięci RAM, podczas gdy wartości mogą być przechowywane w magazynie flash lub pamięci RAM. Oprogramowanie Redis inteligentnie określa lokalizację wartości. Gorące wartości, do których często uzyskuje się dostęp, są przechowywane w pamięci RAM, podczas gdy wartości zimne , które są rzadziej używane, są przechowywane w pamięci Flash. Zanim dane zostaną odczytane lub zapisane, należy przenieść je do pamięci RAM, stając się gorącymi danymi.

Ponieważ Redis optymalizuje wydajność, instancja najpierw wypełnia dostępną pamięć RAM przed dodaniem elementów do pamięci Flash. Wypełnienie pamięci RAM najpierw ma kilka konsekwencji dla wydajności:

• Można osiągnąć lepszą wydajność i mniejsze opóźnienia podczas testowania przy niskim użyciu pamięci. Testowanie z pełnym wystąpieniem pamięci podręcznej może skutkować niższą wydajnością, ponieważ w fazie testowania używana jest jedynie pamięć RAM.
• Podczas zapisywania większej ilości danych w pamięci podręcznej odsetek danych w pamięci RAM w porównaniu z pamięcią Flash spada, zazwyczaj powodując spadek opóźnienia i wydajności przepływności.

Obciążenia odpowiednie dla zoptymalizowanej pod kątem technologii flash warstwy

Obciążenia, które mogą działać dobrze w warstwie Flash Optimized, często mają następujące cechy:

• Odczyt jest ciężki, z wysokim współczynnikiem poleceń odczytu do zapisu poleceń.
• Dostęp koncentruje się na podzestawie kluczy, które są używane znacznie częściej niż reszta zestawu danych.
• Stosunkowo duże wartości w porównaniu do nazw kluczowych. (Ponieważ nazwy kluczy są zawsze przechowywane w pamięci RAM, duże wartości mogą powodować ograniczenia w rozwoju pamięci).

Obciążenia, które nie są odpowiednie dla warstwy zoptymalizowanej pod kątem pamięci flash

Niektóre obciążenia mają cechy dostępu, które są mniej zoptymalizowane pod kątem projektowania warstwy zoptymalizowanej dla technologii Flash.

• Wykonywanie dużych obciążeń.
• Losowe lub jednolite wzorce dostępu do danych w większości zestawu danych.
• Długie nazwy kluczy o stosunkowo małych rozmiarach.

Treści powiązane

• Skalowanie instancji Azure Managed Redis