Udostępnij za pośrednictwem

Szybki start: wdrażanie klastra kontenerów programu SQL Server na platformie Azure lub Red Hat OpenShift

Dotyczy:programu SQL Server — Linux

W tym przewodniku szybkiego startu pokazano, jak skonfigurować wystąpienie programu SQL Server o wysokiej dostępności w kontenerze z trwałym magazynem w usłudze Azure Kubernetes Service (AKS) lub Red Hat OpenShift. Jeśli instancja SQL Server zakończy się niepowodzeniem, orchestrator automatycznie utworzy ją ponownie w nowym zasobniku. Usługa klastrowania zapewnia również odporność na awarię węzła.

W tym przewodniku Szybki Start używane są następujące narzędzia wiersza polecenia do zarządzania klastrem.

Usługa klastrowania Narzędzie wiersza polecenia
Azure Kubernetes Service (AKS) kubectl (interfejs wiersza polecenia Kubernetes)
Azure Red Hat OpenShift oc (interfejs wiersza polecenia platformy OpenShift)

Warunki wstępne

  • Kubernetes
  • OpenShift

Utwórz hasło SA

Konto administratora systemu (sa) musi być zabezpieczone przy użyciu silnego hasła. Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.

  • Kubernetes
  • OpenShift

  1. Utwórz hasło sa w klastrze Kubernetes. Platforma Kubernetes może zarządzać poufnymi informacjami o konfiguracji, takimi jak hasła jako sekrety .

  2. Aby utworzyć sekret w Kubernetes o nazwie mssql, który przechowuje wartość <password> dla MSSQL_SA_PASSWORD, uruchom następujące polecenie. Zastąp <password> złożonym hasłem.

    Ważny

    Zmienna środowiskowa SA_PASSWORD jest przestarzała. Zamiast tego użyj MSSQL_SA_PASSWORD.

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="<password>"

Tworzenie magazynu

  • Kubernetes
  • OpenShift

W przypadku bazy danych w klastrze Kubernetes należy użyć magazynu utrwalonego. Aby skonfigurować wolumin trwały oraz żądanie zasobów w klastrze Kubernetes, można wykonać następujące kroki:

  1. Utwórz manifest, aby zdefiniować klasę magazynu i żądanie trwałego woluminu. Manifest określa aprowizatora magazynu, parametry i politykę odzyskiwania. Klaster Kubernetes używa tego manifestu do utworzenia magazynu trwałego.

  2. Poniższy przykład YAML definiuje klasę przechowywania i żądanie trwałego wolumenu. Provisioner klasy przechowywania to azure-disk, ponieważ ten klaster Kubernetes znajduje się w Azure. Typ konta magazynu to Standard_LRS. Żądanie trwałego woluminu nosi nazwę mssql-data. Metadane żądania trwałego wolumenu zawierają adnotację odwołującą się z powrotem do klasy pamięci masowej.

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mssql-data
  annotations:
    volume.beta.kubernetes.io/storage-class: azure-disk
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

    Zapisz plik (na przykład pvc.yaml).

  3. Utwórz żądanie trwałego woluminu w Kubernetes, gdzie <path to pvc.yaml file> to lokalizacja, w której zapisano plik.

    kubectl apply -f <path to pvc.yaml file>

    Trwały wolumin jest tworzony automatycznie jako konto magazynu Azure i powiązany z żądaniem trwałego woluminu.

    storageclass "azure-disk" created
persistentvolumeclaim "mssql-data" created

  4. Sprawdź żądanie trwałego wolumenu, w którym <persistentVolumeClaim> jest nazwą żądania trwałego wolumenu.

    kubectl describe pvc <persistentVolumeClaim>

    W poprzednim kroku żądanie trwałego wolumenu nosi nazwę mssql-data. Aby wyświetlić metadane dotyczące żądania stałego woluminu, uruchom następujące polecenie:

    kubectl describe pvc mssql-data

    Zwrócone metadane zawierają wartość o nazwie Volume. Ta wartość odpowiada nazwie obiektu blob.

    Name:          mssql-data
Namespace:     default
StorageClass:  azure-disk
Status:        Bound
Volume:        pvc-d169b88e-f26d-11e7-bc3e-0a58ac1f09a4
Labels:        ‹none>
Annotations:   kubectl.kubernetes.io/last-applied-configuration-{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"volume.beta.   kubernetes.io/storage-class":"azure-disk"},"name":"mssq1-data...
               pv.kubernetes.io/bind-completed-yes
               pv.kubernetes.io/bound-by-controller=yes
               volume.beta.kubernetes.io/storage-class=azure-disk
               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/azure-disk
Capacity:      8Gi
Access Modes:  RWO
Events:        <none>

    Wartość woluminu odpowiada części nazwy obiektu blob w portalu Azure.

  5. Sprawdź wolumin persystentny.

    kubectl describe pv

    kubectl zwraca metadane dotyczące woluminu trwałego, który został automatycznie utworzony i powiązany z żądaniem zasobu woluminu.

Utwórz wdrożenie

  • Kubernetes
  • OpenShift

Kontener hostujący wystąpienie programu SQL Server jest opisany jako obiekt wdrożenia platformy Kubernetes . Wdrożenie tworzy zestaw replik. Zestaw replik tworzy pod.

Tworzysz manifest, aby opisać kontener na podstawie obrazu Docker mssql-server-linux dla SQL Server.

  • Manifest odwołuje się do żądania trwałego wolumenu mssql-server oraz tajemnicy mssql, które już zastosowałeś do klastra Kubernetes.
  • W manifeście również opisano usługę . Ta usługa jest modułem równoważenia obciążenia. Moduł równoważenia obciążenia gwarantuje, że adres IP jest zachowany po odzyskaniu wystąpienia programu SQL Server.
  • W manifeście opisano żądania zasobów i limity . Są one oparte na minimalnych wymaganiach systemowych .

  1. Utwórz manifest (plik YAML), aby opisać wdrożenie. W poniższym przykładzie opisano wdrożenie, w tym kontener oparty na obrazie kontenera SQL Server.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql-deployment
spec:
  replicas: 1
  selector:
     matchLabels:
       app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      terminationGracePeriodSeconds: 30
      hostname: mssqlinst
      securityContext:
        fsGroup: 10001
      containers:
      - name: mssql
        image: mcr.microsoft.com/mssql/server:2022-latest
        resources:
          requests:
            memory: "2G"
            cpu: "2000m"
          limits:
            memory: "2G"
            cpu: "2000m"
        ports:
        - containerPort: 1433
        env:
        - name: MSSQL_PID
          value: "Developer"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql
              key: MSSQL_SA_PASSWORD
        volumeMounts:
        - name: mssqldb
          mountPath: /var/opt/mssql
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: mssql-data
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-deployment
spec:
  selector:
    app: mssql
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
  type: LoadBalancer

    Skopiuj powyższy kod do nowego pliku o nazwie sqldeployment.yaml. Zaktualizuj następujące wartości:

    • MSSQL_PID value: "Developer": ustawia kontener do uruchamiania wersji SQL Server Developer. Wersja developer nie jest licencjonowana na dane produkcyjne. Jeśli wdrożenie jest używane w środowisku produkcyjnym, ustaw odpowiednią wersję (Enterprise, Standardlub Express). Aby uzyskać więcej informacji, zobacz How to license SQL Server.

    • persistentVolumeClaim: Ta wartość wymaga wpisu dla claimName:, który odwołuje się do nazwy używanej dla żądania trwałego wolumenu. W tym samouczku używamy mssql-data.

    • name: MSSQL_SA_PASSWORD: konfiguruje obraz kontenera w celu ustawienia hasła sa zgodnie z definicją w tej sekcji.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Gdy Kubernetes wdraża kontener, odwołuje się do tajemnicy o nazwie mssql, aby uzyskać wartość hasła.

    • securityContext: definiuje ustawienia uprawnień i kontroli dostępu dla zasobnika lub kontenera. W takim przypadku jest określony na poziomie zasobnika, więc wszystkie kontenery są zgodne z tym kontekstem zabezpieczeń. W kontekście zabezpieczeń definiujemy fsGroup wartością 10001, czyli identyfikator grupy (GID) dla grupy mssql. Ta wartość oznacza, że wszystkie procesy kontenera są również częścią dodatkowej GID 10001 (mssql). Właścicielem woluminu /var/opt/mssql i wszystkich plików utworzonych w tym woluminie będzie GID 10001 (grupa mssql).

    Ostrzeżenie

    Przy użyciu typu usługi LoadBalancer wystąpienie programu SQL Server jest dostępne zdalnie (za pośrednictwem Internetu) na porcie 1433.

    Zapisz plik. Na przykład sqldeployment.yaml.

  2. Stwórz wdrożenie, przy czym <path to sqldeployment.yaml file> oznacza lokalizację, w której zapisano plik.

    kubectl apply -f <path to sqldeployment.yaml file>

    Zostanie utworzone wdrożenie i usługa. Wystąpienie SQL Servera znajduje się w kontenerze, połączonym z trwałą pamięcią masową.

    deployment "mssql-deployment" created
service "mssql-deployment" created

    Zostanie utworzone wdrożenie i usługa. Wystąpienie SQL Servera znajduje się w kontenerze, połączonym z trwałą pamięcią masową.

    Aby wyświetlić status poda, wpisz kubectl get pod.

    NAME                                READY    STATUS    RESTARTS   AGE
mssql-deployment-3813464711-h312s   1/1      Running   0          17m

    Zasobnik ma stan Running. Ten stan wskazuje, że kontener jest gotowy. Po utworzeniu wdrożenia może upłynąć kilka minut, zanim pod będzie widoczny. Opóźnienie jest spowodowane tym, że klaster ściąga obraz mssql-server-linux z rejestru artefaktów Microsoft. Po pierwszym ściągnięciu obrazu, późniejsze wdrożenia mogą przebiegać szybciej, jeśli wdrożenie odbywa się na węźle, który ma już przechowywany obraz w pamięci podręcznej.

  3. Sprawdź, czy usługi są uruchomione. Uruchom następujące polecenie:

    kubectl get services

    To polecenie zwraca uruchomione usługi oraz wewnętrzne i zewnętrzne adresy IP dla usług. Zanotuj zewnętrzny adres IP usługi mssql-deployment. Użyj tego adresu IP, aby nawiązać połączenie z programem SQL Server.

    NAME               TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
kubernetes         ClusterIP      10.0.0.1      <none>          443/TCP          52m
mssql-deployment   LoadBalancer   10.0.113.96   52.168.26.254   1433:30619/TCP   2m

    Aby uzyskać więcej informacji na temat stanu obiektów w klastrze Kubernetes, uruchom następujące polecenie. Pamiętaj, aby zastąpić <MyResourceGroup> i <MyKubernetesClustername> nazwą grupy zasobów i klastra Kubernetes:

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>

  4. Możesz również sprawdzić, czy kontener działa jako inny niż root, uruchamiając następujące polecenie, gdzie <nameOfSqlPod> jest nazwą zasobnika programu SQL Server:

    kubectl.exe exec <nameOfSqlPod> -it -- /bin/bash

    Możesz zobaczyć nazwę użytkownika jako mssql, jeśli uruchomisz whoami. mssql jest użytkownikiem niebędącym użytkownikiem głównym.

    whoami

Połącz się z wystąpieniem SQL Server

Możesz nawiązać połączenie z aplikacją spoza sieci wirtualnej platformy Azure przy użyciu konta sa i zewnętrznego adresu IP usługi. Użyj hasła, które skonfigurowałeś jako tajemnicę OpenShift.

Aby nawiązać połączenie z wystąpieniem programu SQL Server, możesz użyć następujących aplikacji.

Nawiązywanie połączenia za pomocą narzędzia sqlcmd

Aby nawiązać połączenie z sqlcmd, uruchom następujące polecenie.

sqlcmd -S <External IP address> -U sa -P "<password>"

Zastąp <External IP address> adresem IP usługi mssql-deployment i <password> złożonym hasłem.

Ostrożność

Hasło powinno być zgodne z domyślnymi zasadami haseł programu SQL Server. Domyślnie hasło musi mieć długość co najmniej ośmiu znaków i zawierać znaki z trzech z następujących czterech zestawów: wielkie litery, małe litery, cyfry podstawowe-10 i symbole. Hasła mogą mieć długość maksymalnie 128 znaków. Używaj haseł, które są tak długie i złożone, jak to możliwe.

Weryfikacja niepowodzenia i procesu odzyskiwania

  • Kubernetes
  • OpenShift

Aby sprawdzić awarię i odzyskiwanie, możesz przeprowadzić usunięcie podu, wykonując następujące czynności:

  1. Wyświetl listę podów uruchomionych z SQL Server.

    kubectl get pods

    Zapisz nazwę zasobnika, na którym działa SQL Server.

  2. Usuń zasobnik.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 jest wartością zwróconą z poprzedniego kroku dla nazwy podu.

Kubernetes automatycznie ponownie tworzy zasobnik w celu odzyskania instancji SQL Server i łączy się z magazynem trwałym. Użyj kubectl get pods, aby sprawdzić, czy nowy pod jest wdrożony. Użyj kubectl get services, aby sprawdzić, czy adres IP nowego kontenera jest taki sam.

Czyszczenie zasobów

Jeśli nie planujesz uczestniczenia w następnych samouczkach, wyczyść niepotrzebne zasoby. Użyj polecenia az group delete, aby usunąć grupę zasobów, usługę kontenera i wszystkie powiązane zasoby. Zastąp <MyResourceGroup> nazwą grupy zasobów zawierającej klaster.

az group delete --name <MyResourceGroup> --yes --no-wait

Powiązana zawartość

  • Last updated on