Jakie są najlepsze rozwiązania dla warstw Enterprise i Enterprise Flash
Poniżej przedstawiono najlepsze rozwiązania dotyczące korzystania z warstw Enterprise i Enterprise Flash usługi Azure Cache for Redis.
Nadmiarowość stref
Zdecydowanie zalecamy wdrożenie nowych pamięci podręcznych w konfiguracji strefowo nadmiarowej . Nadmiarowość stref zapewnia, że węzły usługi Redis Enterprise są rozmieszczone między trzema strefami dostępności, zwiększając nadmiarowość awarii na poziomie centrum danych. Użycie nadmiarowości strefy zwiększa dostępność. Aby uzyskać więcej informacji, zobacz Umowy dotyczące poziomu usług (SLA) dla usług online.
Nadmiarowość strefy jest ważna w warstwie Enterprise, ponieważ wystąpienie pamięci podręcznej zawsze używa co najmniej trzech węzłów. Dwa węzły to węzły danych, które przechowują dane, i węzeł kworum. Zwiększenie pojemności skaluje liczbę węzłów danych w przyrostach parzystycznych.
Istnieje również inny węzeł nazywany węzłem kworum. Ten węzeł monitoruje węzły danych i automatycznie wybiera nowy węzeł podstawowy, jeśli wystąpił tryb failover. Nadmiarowość strefy zapewnia równomierną dystrybucję węzłów w trzech strefach dostępności, co minimalizuje potencjalną utratę kworum. Klienci nie są naliczani opłat za węzeł kworum i nie są naliczane żadne inne opłaty za używanie nadmiarowości strefy poza opłatami za przepustowość wewnątrz strefy.
Skalowanie
W warstwach Enterprise i Enterprise Flash usługi Azure Cache for Redis zalecamy ustalanie priorytetów skalowania w górę przez skalowanie w poziomie. Określanie priorytetów skalowania w górę, ponieważ warstwy Enterprise są oparte na usłudze Redis Enterprise, która umożliwia korzystanie z większej liczby rdzeni procesora CPU na większych maszynach wirtualnych.
Z drugiej strony przeciwne zalecenie dotyczy warstw Podstawowa, Standardowa i Premium, które są oparte na usłudze Redis typu open source. W tych warstwach w większości przypadków zaleca się ustalanie priorytetów skalowania w poziomie przez skalowanie w górę .
Fragmentowanie i wykorzystanie procesora CPU
W warstwach Podstawowa, Standardowa i Premium usługi Azure Cache for Redis określenie liczby używanych procesorów wirtualnych (procesorów wirtualnych) jest proste. Każdy węzeł usługi Redis jest uruchamiany na dedykowanej maszynie wirtualnej. Proces serwera Redis jest jednowątkowy, wykorzystując jeden procesor wirtualny w każdym węźle podstawowym i każdym węźle repliki. Inne procesory wirtualne na maszynie wirtualnej są nadal używane do innych działań, takich jak koordynacja przepływu pracy dla różnych zadań, monitorowanie kondycji i obciążenie protokołu TLS, między innymi.
W przypadku korzystania z klastrowania efekt polega na rozłożeniu danych między więcej węzłów przy użyciu jednego fragmentu na węzeł. Zwiększając liczbę fragmentów, liniowo zwiększasz liczbę używanych procesorów wirtualnych na podstawie liczby fragmentów w klastrze.
Z drugiej strony usługa Redis Enterprise może używać wielu procesorów wirtualnych dla samego wystąpienia usługi Redis. Innymi słowy, wszystkie warstwy usługi Azure Cache for Redis mogą używać wielu procesorów wirtualnych na potrzeby zadań w tle i monitorowania, ale tylko warstwy Enterprise i Enterprise Flash mogą korzystać z wielu procesorów wirtualnych na maszynę wirtualną dla fragmentów usługi Redis. W tabeli przedstawiono liczbę efektywnych procesorów wirtualnych używanych dla każdej jednostki SKU i pojemności (czyli skalowania w poziomie).
W tabelach przedstawiono liczbę procesorów wirtualnych używanych dla podstawowych fragmentów, a nie fragmentów repliki. Fragmenty nie mapują jednego na jeden do liczby procesorów wirtualnych. Tabele ilustrują tylko procesory wirtualne, a nie fragmenty. Niektóre konfiguracje używają większej liczby fragmentów niż dostępnych procesorów wirtualnych, aby zwiększyć wydajność w niektórych scenariuszach użycia.
E5
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 6 |
| 100 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 6 |
| 100 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 2 | 60 |
| 100 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Wydajność | Skuteczne procesory wirtualne |
|---|---|
| 3 | 30 |
| 9 | 90 |
Klastrowanie w przedsiębiorstwie
Warstwy Flash dla przedsiębiorstw i przedsiębiorstwa są z natury klastrowane, w przeciwieństwie do warstw Podstawowa, Standardowa i Premium. Implementacja zależy od wybranych zasad klastrowania. Warstwy przedsiębiorstwa oferują dwie opcje dla 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 typu open source. Interfejs API klastra Redis umożliwia klientowi usługi Redis bezpośrednie łączenie się z każdym węzłem Usługi Redis, minimalizowanie opóźnienia i optymalizowanie przepływności sieci. W rezultacie skalowalność niemal liniowa jest uzyskiwana podczas skalowania klastra z większą ilością węzłów. Zasady klastrowania systemu operacyjnego ogólnie zapewniają najlepsze opóźnienia i wydajność przepływności, ale wymaga, aby biblioteka kliencka obsługiwała klastrowanie usługi Redis. 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 biblioteki klienckie usługi Redis nie muszą obsługiwać klastrowania Redis, aby korzystać z wielu węzłów. 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.
Polecenia wieloklucze
Ponieważ warstwy przedsiębiorstwa używają konfiguracji klastrowanej, 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 wieloklucze wymagają mapowania wszystkich kluczy na to samo miejsce skrótu.
Mogą również występować CROSSSLOT błędy związane z zasadami klastrowania przedsiębiorstwa. Tylko następujące polecenia wieloklucza są dozwolone w różnych miejscach z klastrowaniem przedsiębiorstwa: DEL, , MSET, MGETEXISTS, 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 miejscu. Jednak następujące polecenia wielokluczowe są dozwolone w różnych miejscach w bazach danych Active-Active: MGET, EXISTSi TOUCH. Aby uzyskać więcej informacji, zobacz Klaster baz danych.
Najlepsze rozwiązania dotyczące programu Flash w przedsiębiorstwie
Warstwa Flash w przedsiębiorstwie korzysta zarówno z magazynu NVMe Flash, jak i pamięci RAM. Ponieważ pamięć masowa Flash jest niższa, użycie warstwy Flash Enterprise pozwala zmniejszyć wydajność pod kątem wydajności cen.
W przypadku wystąpień pamięci flash w przedsiębiorstwie 20% miejsca w pamięci podręcznej znajduje się w pamięci RAM, podczas gdy pozostałe 80% używa magazynu Flash. Wszystkie klucze są przechowywane w pamięci RAM, podczas gdy wartości mogą być przechowywane w magazynie flash lub pamięci RAM. Lokalizacja wartości jest określana inteligentnie przez oprogramowanie Redis. Wartości "Gorąca", do których 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ę danymi "Gorąca".
Ponieważ usługa Redis zdecyduje się na najlepszą wydajność, wystąpienie najpierw wypełni dostępną pamięć RAM przed dodaniem elementów do magazynu flash. Ma to kilka konsekwencji dla wydajności:
- Podczas testowania przy niskim użyciu pamięci wydajność i opóźnienie mogą być znacznie lepsze niż w przypadku wystąpienia pełnej pamięci podręcznej, ponieważ jest używana tylko pamięć RAM.
- Podczas zapisywania większej ilości danych w pamięci podręcznej proporcja danych w pamięci RAM w porównaniu z magazynem flash będzie się zmniejszać, co zwykle powoduje spadek opóźnienia i wydajności przepływności.
Obciążenia odpowiednie dla warstwy Flash przedsiębiorstwa
Obciążenia, które mogą działać dobrze w warstwie Flash przedsiębiorstwa, 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, może to stać się wąskim gardłem wzrostu pamięci).
Obciążenia, które nie są odpowiednie dla warstwy Flash przedsiębiorstwa
Niektóre obciążenia mają charakterystyki dostępu, które są mniej zoptymalizowane pod kątem projektowania warstwy Flash:
- Zapisywanie dużych obciążeń.
- Losowy lub jednolity dostęp do danych ojców w większości zestawu danych.
- Długie nazwy kluczy o stosunkowo małych rozmiarach.
Obsługa scenariuszy w dół regionu przy użyciu aktywnej replikacji geograficznej
Aktywna replikacja geograficzna to zaawansowana funkcja umożliwiająca znaczne zwiększenie dostępności w przypadku korzystania z warstw przedsiębiorstwa usługi Azure Cache for Redis. Należy jednak wykonać kroki, aby przygotować pamięci podręczne w przypadku awarii regionalnej.
Rozważmy na przykład następujące porady:
- Zidentyfikuj z wyprzedzeniem, do której innej pamięci podręcznej w grupie replikacji geograficznej przełączy się na region, jeśli region ulegnie awarii.
- Upewnij się, że zapory są ustawione tak, aby wszystkie aplikacje i klienci mogli uzyskać dostęp do zidentyfikowanej pamięci podręcznej kopii zapasowych.
- Każda pamięć podręczna w grupie replikacji geograficznej ma własny klucz dostępu. Określ sposób przełączania aplikacji na różne klucze dostępu podczas określania wartości docelowej pamięci podręcznej kopii zapasowej.
- Jeśli pamięć podręczna w grupie replikacji geograficznej ulegnie awarii, kompilacja metadanych zacznie występować we wszystkich pamięciach podręcznych w grupie replikacji geograficznej. Metadanych nie można odrzucić, dopóki zapisy nie zostaną ponownie zsynchronizowane ze wszystkimi pamięciami podręcznymi. Możesz zapobiec kompilacji metadanych, wymuszając odłączanie pamięci podręcznej, która nie działa. Rozważ monitorowanie dostępnej pamięci w pamięci podręcznej i odłączanie go, jeśli istnieje wykorzystanie pamięci, szczególnie w przypadku obciążeń z dużym obciążeniem zapisu.
Można również użyć wzorca wyłącznika. Użyj wzorca, aby automatycznie przekierowywać ruch z pamięci podręcznej, w której występuje awaria regionu, oraz do pamięci podręcznej kopii zapasowej w tej samej grupie replikacji geograficznej. Użyj usług platformy Azure, takich jak Azure Traffic Manager lub Azure Load Balancer , aby włączyć przekierowywanie.
Trwałość danych a kopia zapasowa danych
Funkcja trwałości danych w warstwach Flash enterprise i Enterprise została zaprojektowana tak, aby automatycznie zapewnić szybki punkt odzyskiwania danych, gdy pamięć podręczna ulegnie awarii. Szybkie odzyskiwanie jest możliwe dzięki przechowywaniu pliku RDB lub AOF na dysku zarządzanym zainstalowanym w wystąpieniu pamięci podręcznej. Pliki trwałości na dysku nie są dostępne dla użytkowników.
Wielu klientów chce używać trwałości do wykonywania okresowych kopii zapasowych danych w pamięci podręcznej. Nie zalecamy używania trwałości danych w ten sposób. Zamiast tego użyj funkcji importu/eksportu . Kopie danych pamięci podręcznej można eksportować bezpośrednio do wybranego konta magazynu i wyzwalać eksport danych tak często, jak jest to wymagane. Eksportowanie można wyzwolić z portalu lub przy użyciu interfejsu wiersza polecenia, programu PowerShell lub narzędzi zestawu SDK.