Storage Configuration

Pojęcia dotyczące przechowywania w Kubernetes

Platforma Kubernetes udostępnia warstwę abstrakcji infrastruktury na bazowym stosie technologicznym wirtualizacji (opcjonalnie) i sprzęcie. The way that Kubernetes abstracts away storage is through Storage Classes. Podczas przydzielania zasobnika można określić klasę pamięci masowej dla każdego woluminu. At the time the pod is provisioned, the storage class provisioner is called to provision the storage, and then a persistent volume is created on that provisioned storage and then the pod is mounted to the persistent volume by a persistent volume claim.

Platforma Kubernetes umożliwia dostawcom infrastruktury magazynu podłączenie sterowników (nazywanych również "Addons"), które rozszerzają platformę Kubernetes. Dodatki magazynu muszą być zgodne ze standardem interfejsu magazynu kontenera. Istnieje kilkadziesiąt dodatków, które można znaleźć na tej niejednoznacznej liście sterowników CSI. Określony sterownik CSI, którego używasz, zależy od czynników takich jak to, czy korzystasz z zarządzanej usługi Kubernetes hostowanej w chmurze, czy od wybranego dostawcy OEM dla swojego sprzętu.

Aby wyświetlić klasy magazynu skonfigurowane w klastrze Kubernetes, uruchom następujące polecenie:

kubectl get storageclass

Przykładowe dane wyjściowe z klastra usługi Azure Kubernetes Service (AKS):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Aby uzyskać szczegółowe informacje o klasie magazynu, uruchom następujące polecenie:

kubectl describe storageclass/<storage class name>

Example:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Możesz zobaczyć aktualnie dostępne woluminy trwałe i roszczenia dotyczące woluminów trwałych, uruchamiając następujące polecenia:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Przykład przedstawiający woluminy trwałe:

kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Przykład przedstawiający żądania trwałego wolumenu:

kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Czynniki, które należy wziąć pod uwagę podczas wybierania konfiguracji magazynu

Wybranie odpowiedniej klasy magazynu jest ważne dla odporności i wydajności danych. Wybranie niewłaściwej klasy magazynu może spowodować ryzyko całkowitej utraty danych w przypadku awarii sprzętu lub spowodować mniej optymalną wydajność.

Zazwyczaj istnieją dwa typy magazynów:

• Local storage - storage provisioned on local hard drives on a given node. Ten rodzaj magazynu może być idealny pod względem wydajności, ale wymaga specjalnego projektowania pod kątem nadmiarowości danych przez replikowanie danych na wielu węzłach.
• Zdalny, udostępniony magazyn — magazyn aprowizowany na niektórych zdalnych urządzeniach magazynujących — na przykład usługa SAN, NAS lub magazynu w chmurze, na przykład EBS lub Azure Files. Ten rodzaj magazynu zwykle zapewnia nadmiarowość danych automatycznie, ale nie jest tak szybki, jak magazyn lokalny może być.

Klasy magazynu oparte na systemie plików NFS

W zależności od konfiguracji serwera NFS i dostawcy obsługi administracyjnej klasy magazynu może być konieczne ustawienie supplementalGroups w konfiguracjach zasobnika dla wystąpień bazy danych i może być konieczne zmianę konfiguracji serwera NFS w celu używania identyfikatorów grup przekazanych przez klienta (w przeciwieństwie do wyszukiwania identyfikatorów grup na serwerze przy użyciu przekazanego identyfikatora użytkownika). Skontaktuj się z administratorem systemu plików NFS, aby ustalić, czy tak jest.

Właściwość supplementalGroups przyjmuje tablicę wartości, które można ustawić we wdrożeniu. Kontroler danych usługi Azure Arc stosuje je do wszystkich tworzonych wystąpień bazy danych.

Aby ustawić tę właściwość, uruchom następujące polecenie:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Konfiguracja magazynu kontrolera danych

Niektóre usługi w usłudze Azure Arc dla usług danych zależą od skonfigurowania do korzystania ze zdalnego magazynu udostępnionego, ponieważ usługi nie mają możliwości replikowania danych. Te usługi znajdują się w kolekcji podów kontrolera danych.

W momencie aprowizacji kontrolera danych przeznaczona do użycia klasa pamięci dla każdego z tych woluminów trwałych jest określana przez przekazanie parametru --storage-class | -sc do polecenia az arcdata dc create lub poprzez ustawienie klas pamięci w pliku szablonu wdrożeniowego control.json, który jest używany. Jeśli używasz witryny Azure Portal do utworzenia kontrolera danych w trybie bezpośrednio połączonego, wybrany szablon wdrożenia ma wstępnie zdefiniowaną klasę magazynu w szablonie lub możesz wybrać szablon, który nie ma wstępnie zdefiniowanej klasy magazynu. Jeśli szablon nie definiuje klasy przechowywania, portal poprosi o jej podanie. Jeśli używasz niestandardowego szablonu wdrażania, możesz określić klasę magazynu.

Szablony wdrażania, które są dostarczane wraz z pakietem, mają domyślnie określoną klasę pamięci masowej, która jest odpowiednia dla środowiska docelowego, ale można ją przesłonić podczas wdrażania. Zobacz szczegółowe kroki tworzenia niestandardowych szablonów konfiguracji, aby zmienić konfigurację klasy przechowywania dla kontenerów kontrolera danych podczas wdrażania.

Jeśli ustawisz klasę magazynu przy użyciu parametru --storage-class lub -sc, ta klasa magazynu jest używana zarówno dla klas magazynu dzienników, jak i danych. Jeśli ustawisz klasy magazynu w pliku szablonu wdrożenia, możesz określić różne klasy magazynu dla dzienników i danych.

Ważne czynniki, które należy rozważyć podczas wybierania klasy pamięci masowej dla zasobników kontrolera danych:

• You must use a remote, shared storage class in order to ensure data durability and so that if a pod or node dies that when the pod is brought back up it can connect again to the persistent volume.
• Dane zapisywane w wystąpieniu SQL kontrolera, bazie danych metryk i bazie danych dzienników są zwykle dość małej objętości i nie są wrażliwe na opóźnienia, więc magazyn o bardzo szybkiej wydajności nie ma krytycznego znaczenia. Jeśli masz użytkowników, którzy często korzystają z interfejsów Grafana i Kibana oraz masz dużą liczbę wystąpień bazy danych, może być korzystne zastosowanie szybszych technologii przechowywania dla tych użytkowników.
• Wymagana pojemność magazynu jest zmienna z liczbą wdrożonych wystąpień bazy danych, ponieważ dzienniki i metryki są zbierane dla każdego wystąpienia bazy danych. Dane są przechowywane w dziennikach i bazie danych metryk przez dwa (2) tygodnie przed ich przeczyszczeniem.
• Zmiana klasy magazynu po wdrożeniu jest trudna, nie udokumentowana i nieobsługiwana. Pamiętaj, aby poprawnie wybrać klasę magazynu w czasie wdrażania.

Konfiguracja pamięci wystąpienia bazy danych

Każde wystąpienie bazy danych ma dane, dzienniki i kopie zapasowe woluminów trwałych. Klasy magazynu dla tych trwałych woluminów można określić w czasie wdrażania. Jeśli nie określono żadnej klasy magazynu, zostanie użyta domyślna klasa magazynu.

Podczas tworzenia wystąpienia przy użyciu metody az sql mi-arc create lub az postgres server-arc create, istnieją cztery parametry, których można użyć do ustawiania klasy przechowywania.

W poniższej tabeli wymieniono ścieżki wewnątrz kontenera usługi Azure SQL Managed Instance zamapowanego na trwały wolumin dla danych i dzienników:

Każde wystąpienie bazy danych ma oddzielny trwały wolumin dla plików danych, dzienników i kopii zapasowych. Oznacza to, że istnieje separacja operacji wejścia/wyjścia dla każdego z tych typów plików, w zależności od sposobu, w jaki aprowizator woluminów przydziela pamięć masową. Każde wystąpienie bazy danych ma własne żądania trwałych woluminów i woluminy trwałe.

Jeśli w danej instancji bazy danych znajduje się wiele baz danych, wszystkie korzystają z tego samego trwałego żądania woluminu, trwałego woluminu i klasy magazynowej. Wszystkie kopie zapasowe — zarówno różnicowe kopie zapasowe, jak i pełne kopie zapasowe używają tego samego żądania trwałego wolumenu i trwałego wolumenu. Żądania trwałego wolumenu dla kontenerów wystąpienia bazy danych są pokazane poniżej.

Ważne czynniki, które należy wziąć pod uwagę podczas wybierania klasy magazynu dla podów instancji bazy danych:

• Starting with the February, 2022 release of Azure Arc data services, you need to specify a ReadWriteMany (RWX) capable storage class for backups. Learn more about access modes. Jeśli dla kopii zapasowych nie określono żadnej klasy pamięci masowej, zostanie użyta domyślna klasa pamięci masowej w Kubernetes. Jeśli ta klasa nie posiada zdolności RWX, wdrożenie zarządzanego wystąpienia usługi Azure SQL może zakończyć się niepowodzeniem.
• Wystąpienia bazy danych można wdrożyć w wzór pojedynczego zasobnika lub wielu zasobników. Przykładem pojedynczej jednostki jest warstwa cenowa o ogólnym przeznaczeniu zarządzane wystąpienie SQL usługi Azure. Przykładem wzorca wielu podów jest wystąpienie zarządzane usługi Azure SQL o wysokiej dostępności w warstwie cennowej Biznes Krytyczny. Database instances deployed with the single pod pattern must use a remote, shared storage class in order to ensure data durability and so that if a pod or node dies that when the pod is brought back up it can connect again to the persistent volume. Z kolei zarządzane wystąpienie Azure SQL o wysokiej dostępności używa grup dostępności Always On do replikacji danych między wystąpieniami zarówno synchronicznie, jak i asynchronicznie. Szczególnie w przypadku, gdy dane są replikowane synchronicznie, zawsze istnieje wiele kopii danych — zwykle trzy kopie. W związku z tym można użyć magazynu lokalnego lub zdalnych klas magazynu udostępnionego dla plików danych i dzienników. Jeśli korzystasz z magazynu lokalnego, dane są nadal zachowywane nawet w przypadku awarii zasobnika, węzła lub sprzętu magazynu, ponieważ istnieje wiele kopii danych. Biorąc pod uwagę tę elastyczność, możesz użyć magazynu lokalnego w celu uzyskania lepszej wydajności.
• Wydajność bazy danych jest w dużej mierze funkcją przepływności we/wy danego urządzenia magazynowego. Jeśli baza danych ma duże obciążenie operacjami odczytu lub zapisu, należy wybrać klasę przechowywania z sprzętem zaprojektowanym specjalnie dla tego typu obciążenia. Jeśli na przykład baza danych jest używana głównie do zapisu, możesz wybrać magazyn lokalny z macierzą RAID 0. Jeśli baza danych jest używana głównie do odczytu niewielkiej ilości "gorących danych", ale istnieje duża całkowita ilość magazynowania zimnych danych, możesz wybrać urządzenie SAN obsługujące magazyn warstwowy. Wybór odpowiedniej klasy magazynu nie różni się od wyboru typu magazynu, który ma być używany dla dowolnej bazy danych.
• Jeśli używasz lokalnego aprowizera woluminów pamięci masowej, upewnij się, że lokalne woluminy przydzielone na potrzeby danych, dzienników i kopii zapasowych są przypisane do różnych bazowych urządzeń magazynujących, aby uniknąć konfliktu przy wykonywaniu operacji we/wy na dyskach. System operacyjny powinien również znajdować się na woluminie zainstalowanym na osobnych dyskach. To zasadniczo takie same wskazówki, jak dla instancji bazy danych na sprzęcie fizycznym.
• Ponieważ wszystkie bazy danych w danym wystąpieniu współużytkują trwałe oświadczenie woluminu i trwały wolumin, pamiętaj, aby nie przenosić zajętych wystąpień bazy danych w tym samym wystąpieniu bazy danych. Jeśli to możliwe, należy oddzielić zajęte bazy danych na własne wystąpienia bazy danych, aby uniknąć rywalizacji o we/wy. Ponadto użyj etykietowania węzłów w celu rozmieszczenia wystąpień bazy danych na oddzielnych węzłach, aby rozłożyć ogólny ruch wejścia/wyjścia między wieloma węzłami. Jeśli używasz wirtualizacji, rozważ dystrybucję ruchu We/Wy nie tylko na poziomie węzła, ale także łączną aktywność We/Wy maszyn wirtualnych na węzłach na danym hoście fizycznym.

Szacowanie wymagań dotyczących magazynu

Każdy zasobnik zawierający dane stanowe używa co najmniej dwóch trwałych woluminów — jednego trwałego woluminu dla danych i innego trwałego woluminu dla dzienników. W poniższej tabeli wymieniono liczbę woluminów trwałych wymaganych dla pojedynczego kontrolera danych i wystąpienia zarządzanego usługi Azure SQL:

W poniższej tabeli przedstawiono łączną liczbę woluminów trwałych wymaganych do wdrożenia przykładowego:

To obliczenie może służyć do planowania przechowywania dla klastra Kubernetes na podstawie dostawcy zasobów pamięci masowej lub środowiska. Jeśli na przykład lokalny program aprowizacji magazynu jest używany dla klastra Kubernetes z pięcioma węzłami (5), w przypadku przykładowego wdrożenia powyżej każdego węzła wymagany jest co najmniej magazyn dla 10 woluminów trwałych. Podobnie podczas aprowizowania klastra usługi Azure Kubernetes Service (AKS) z pięcioma węzłami (5) wybierając odpowiedni rozmiar maszyny wirtualnej dla puli węzłów, tak aby można było dołączyć 10 dysków danych, ma kluczowe znaczenie. More details on how to size the nodes for storage needs for AKS nodes can be found here.

Wybór odpowiedniej klasy przechowywania

Lokalizacje lokalne i brzegowe

Firma Microsoft i jej partnerzy OEM, OS i Kubernetes mają program weryfikacji usług danych Azure Arc. Ten program zapewnia porównywalne wyniki testu z zestawu narzędzi do testowania certyfikacji. Testy oceniają zgodność funkcji, wyniki testów obciążeniowych oraz wydajność i skalowalność. Wyniki testu wskazują używany system operacyjny, używana dystrybucja Kubernetes, używana funkcja HW, używany dodatek CSI i używane klasy magazynu. Pomaga to klientom wybrać najlepszą klasę magazynu, system operacyjny, dystrybucję Kubernetes i sprzęt dla swoich wymagań. More information on this program and test results can be found here.

Chmura publiczna, zarządzane usługi Kubernetes

W przypadku usług Kubernetes opartych na chmurze publicznej możemy wprowadzić następujące zalecenia: