Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule przedstawiono podsumowanie kroków wdrażania usługi Valkey, magazynu danych klucza/wartości typu open source (BSD) o wysokiej wydajności w usłudze Azure Kubernetes Service (AKS). Wdrożenie Valkey koncentruje się na wykorzystaniu replik i stref dostępności w celu zapewnienia wysokiej dostępności i odporności. Udostępniamy również wskazówki dotyczące testowania odporności wdrożenia Valkey przy użyciu struktury testowania obciążenia Locust.
Ważne
Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Oprogramowanie, które wdrażasz, jest wykluczone z umów na poziomie usług AKS, ograniczonej gwarancji oraz wsparcia technicznego Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.
Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje posiadanie pełnej własności procesu kompilacji, skanowania, podpisywania, weryfikowania i poprawek oraz kontroli nad plikami binarnymi na obrazach kontenerów. Aby uzyskać więcej informacji, zobacz zarządzanie podatnościami dla AKS i zakres wsparcia dla AKS.
Co to jest Valkey?
Valkey to rozwidlenie projektu Redis, który zachowuje oryginalną licencję typu open source. Valkey to baza danych o wysokiej wydajności, która obsługuje magazyn danych typu klucz-wartość, i można ją używać do buforowania, przechowywania sesji, kolejek komunikatów oraz wielu innych zastosowań. Klaster Valkey ma wiele węzłów odpowiedzialnych za hostowanie magazynów danych Valkey. Valkey dzieli dane na mniejsze części i dystrybuuje je między węzłami. W uproszczonym klastrze Valkey składającym się z trzech węzłów podstawowych jeden węzeł repliki obsługuje każdy węzeł w celu włączenia podstawowych funkcji trybu failover. Dane są dystrybuowane między węzłami, umożliwiając klastrowi kontynuowanie działania, nawet jeśli jeden z węzłów ulegnie awarii.
Aby uzyskać więcej informacji, zobacz dokumentację Valkey.
Omówienie rozwiązania Valkey
To rozwiązanie wdraża trzy podstawowe zasobniki Valkey w dwóch strefach dostępności, a w trzeciej strefie umieszczone są po jednym zasobniku repliki dla każdego podstawowego, uruchomionych na Standard_E64_v5 węzłach jednostki SKU. Tworzymy dwa odrębne StatefulSet zasoby z regułami zapewniającymi spec.affinity dystrybucję stref w celu zapewnienia wysokiej dostępności. Celem tego rozwiązania jest wdrożenie Valkey na AKS z tym samym poziomem usługi jak warstwa Premium usługi Azure Cache for Redis.
W poniższej tabeli wymieniono kluczowe funkcje warstwy Premium usługi Azure Cache for Redis i proponowane rozwiązanie Valkey:
| Warstwa Premium w usłudze Azure Cache for Redis | Rozwiązanie Valkey |
|---|---|
| Pamięć do 1,2 TB | Używanie trzech węzłów głównych działających na Standard_E64_v5 SKU. |
| Replikacja | Dodawanie co najmniej jednego zasobnika repliki na zasobnik podstawowy. |
| Nadmiarowość strefowa | Umieszczanie zasobników podstawowych i replik w różnych strefach dostępności. |
Tworzymy dwa odrębne StatefulSet zasoby: jeden dla zasobników podstawowych Valkey i jeden dla zasobników repliki.
spec.affinity Interfejs StatefulSet API umieszcza podstawowe zasobniki w dwóch różnych strefach dostępności i zasobnikach repliki w innej trzeciej strefie dostępności.
Uwaga
Należy pamiętać, że rozwiązanie sugerowane w tym artykule różni się od dokumentacji valkey, w której zasobniki klastra należą do pojedynczego StatefulSetelementu , i spec.affinity zapewnia, że zasobniki są umieszczane w różnych węzłach. Automatyczne inicjowanie klastra Valkey opisane w dokumentacji Valkey nie gwarantuje, że podstawowe i replikowane zasobniki dla tego samego fragmentu są umieszczane w odrębnych strefach dostępności.
Następny krok
Współautorzy
Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:
- Nelly Kiboi | Inżynier usługi
- Saverio Proto | Główny inżynier środowiska klienta
- Don High | Główny inżynier klienta
- LaBrina Loving | Główny inżynier usługi
- Ken Kilty | Główny TPM
- Russell de Pina | Główny Menedżer Programów Technicznych TPM
- Colin Mixon | Menedżer produktu
- Ketan Chawda | Starszy inżynier klienta
- Naveed Kharadi | Inżynier środowiska klienta
- Erin Schaffer | Content Developer 2