Architektura usługi Azure Managed Redis (wersja zapoznawcza)
Usługa Azure Managed Redis (wersja zapoznawcza) 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 informacji na temat sposobu tworzenia architektury usługi Azure Managed Redis, w tym informacji, które mogą być przydatne dla użytkowników siły.
Ważne
Usługa Azure Managed Redis jest obecnie dostępna w wersji zapoznawczej. Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
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 usługi Redis ma kilka znaczących ograniczeń, w tym pojedynczy wątek zgodnie z projektem. 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 do węzła repliki w celu zapewnienia kopii zapasowej podczas konserwacji, skalowania lub nieoczekiwanego błędu. Każdy węzeł może uruchamiać tylko jeden proces serwera Redis ze względu na jednowątkowy projekt usługi 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 procesorów wirtualnych na każdej maszynie wirtualnej i wyższą 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 w obu węzłach. 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 proces serwera proxy o wysokiej wydajności do zarządzania fragmentami, obsługi zarządzania połączeniami i wyzwalania samonaprawiania.
Ta architektura zapewnia zarówno wyższą wydajność, jak i zaawansowane funkcje, takie jak aktywna replikacja geograficzna
Klastrowanie
Ponieważ usługa Redis Enterprise może używać wielu fragmentów na węzeł, każde wystąpienie usługi Azure Managed Redis jest wewnętrznie skonfigurowane do używania klastrowania we wszystkich warstwach i jednostkach SKU. Obejmuje to mniejsze wystąpienia, które są skonfigurowane tylko do używania pojedynczego fragmentu. Klastrowanie to sposób dzielenia danych w wystąpieniu usługi Redis na wiele procesów Usługi Redis, nazywanych również "fragmentowaniem". Usługa Azure Managed Redis oferuje dwie zasady klastra, które określają, który protokół jest dostępny dla klientów usługi Redis na potrzeby nawiązywania połączenia z wystąpieniem pamięci podręcznej.
Zasady klastra
Usługa Azure Managed Redis oferuje dwie opcje zasad klastrowania: system operacyjny i przedsiębiorstwo. 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 usługa Redis w wersji Community Edition. Interfejs API klastra Redis umożliwia klientowi Usługi Redis bezpośrednie łączenie się z fragmentami w każdym węźle usługi Redis, minimalizowanie opóźnienia i optymalizowanie przepływności sieci, co umożliwia skalowanie niemal liniowo przepływności w miarę wzrostu liczby fragmentów i procesorów wirtualnych. 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 również używać zasad klastrowania systemu operacyjnego z modułem RediSearch.
Zasady klastrowania przedsiębiorstwa to prostsza konfiguracja, która korzysta z jednego punktu końcowego dla wszystkich połączeń klientów. Za pomocą zasad klastrowania przedsiębiorstwa kieruje wszystkie żądania do pojedynczego węzła Usługi Redis, który jest następnie używany jako serwer proxy, wewnętrznie rozsyłając żądania do poprawnego węzła w klastrze. Zaletą tego podejścia jest to, że usługa Azure Managed Redis wygląda nieklastrowane dla użytkowników. Oznacza to, że biblioteki klienckie redis nie muszą obsługiwać klastrowania Redis, aby uzyskać niektóre zalety wydajności usługi Redis Enterprise, zwiększając zgodność z poprzednimi wersjami i upraszczając połączenie. Wadą jest to, że serwer proxy pojedynczego węzła może być wąskim gardłem w przypadku wykorzystania zasobów obliczeniowych lub przepływności sieci. Zasady klastrowania przedsiębiorstwa to jedyna, która może być używana z modułem RediSearch. Chociaż zasady klastra przedsiębiorstwa sprawiają, że wystąpienie usługi Azure Managed Redis wydaje się być nieklastrowane użytkownikom, nadal ma pewne ograniczenia dotyczące poleceń wielokluczesowych.
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 w górę (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 w celu zmaksymalizowania procesorów wirtualnych i pamięci. 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ą, mogą być widoczne CROSSSLOT wyjątki w poleceniach, 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 miejscach z klastrowaniem przedsiębiorstwa: DEL, MSET, MGET, EXISTS, UNLINK i TOUCH.
W bazach danych aktywny-aktywny polecenia zapisu z wieloma klawiszami (DEL, MSET, UNLINK) mogą być uruchamiane tylko na klawiszach, które znajdują się w tym samym gnieździe. Jednak następujące polecenia wieloklawiszowe są dozwolone w różnych miejscach w bazach danych aktywny-aktywny: MGET, EXISTSi 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, fragmentów równolegle. Relacja między wydajnością przepływności, liczbą fragmentów i liczbą procesorów wirtualnych 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 nie są w stanie uruchomić poleceń, ponieważ żadne procesory wirtualne nie są dostępne do wykonywania poleceń, wydajność może rzeczywiście 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
Liczba fragmentów i procesorów wirtualnych używanych w każdej jednostce SKU może ulec zmianie wraz z upływem czasu, ponieważ wydajność jest zoptymalizowana przez zespół usługi Azure Managed Redis.
| Warstwy | Zoptymalizowane pod kątem Flash | Optymalizacja 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/1 | 4/2 |
| 6 | - | - | 2/1 | 4/2 |
| 12 | - | 2/1 | 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 | - | - | - |
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 bez wysokiej dostępności poza scenariuszami tworzenia i testowania. 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 go nie ma. Ponieważ wystąpienie działające bez wysokiej dostępności używa mniejszej liczby maszyn wirtualnych/węzłów, procesory wirtualne nie mogą być używane jako wydajne, 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 innych niżcache, takich jak replikacja podczas pracy w trybie failover i aktywny bufor replikacji geograficznej. Ten bufor pomaga zwiększyć wydajność pamięci podręcznej i zapobiegać głodowaniu pamięci.
Skalowanie w dół
Skalowanie w dół nie jest obecnie obsługiwane w usłudze Azure Managed Redis. Aby uzyskać więcej informacji, zobacz Wymagania wstępne/ograniczenia skalowania usługi Azure Managed Redis.
Warstwa Zoptymalizowana pod kątem flash
Warstwa Zoptymalizowana pod kątem flash korzysta zarówno z magazynu NVMe Flash, jak i pamięci RAM. Ponieważ magazyn flash jest niższy koszt, użycie warstwy Zoptymalizowane pod kątem flash pozwala zmniejszyć wydajność pod kątem wydajności cen.
W przypadku wystąpień zoptymalizowanych pod kątem flash 20% miejsca w pamięci podręcznej znajduje się w pamięci RAM, podczas gdy 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ż usługa Redis optymalizuje najlepszą wydajność, wystąpienie najpierw wypełnia dostępną pamięć RAM przed dodaniem elementów do magazynu Flash. Wypełnienie pamięci RAM najpierw ma kilka konsekwencji dla wydajności:
- Lepszą wydajność i mniejsze opóźnienia mogą wystąpić podczas testowania przy niskim użyciu pamięci. Testowanie za pomocą pełnego wystąpienia pamięci podręcznej może przynieść niższą wydajność, ponieważ w fazie testowania użycia pamięci jest używana tylko 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 warstwy Zoptymalizowane pod kątem flash
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 z nazwami kluczy. (Ponieważ nazwy kluczy są zawsze przechowywane w pamięci RAM, duże wartości mogą stać się wąskim gardłem wzrostu pamięci).
Obciążenia, które nie są odpowiednie dla warstwy Zoptymalizowane pod kątem flash
Niektóre obciążenia mają cechy dostępu, które są mniej zoptymalizowane pod kątem projektowania warstwy Zoptymalizowane pod kątem flash:
- Zapisywanie 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.