Поделиться через

Краткое руководство. Развертывание кластера контейнеров SQL Server в Azure или Red Hat OpenShift

  • Статья

Область применения: SQL Server — Linux

В этом кратком руководстве показано, как настроить экземпляр SQL Server с высоким уровнем доступности в контейнере с постоянным хранилищем на Службе Azure Kubernetes (AKS) или Red Hat OpenShift. Если экземпляр SQL Server завершается ошибкой, оркестратор автоматически воссоздает его в новом pod. Служба кластера также обеспечивает устойчивость к сбою узла.

В этом кратком руководстве используются следующие средства командной строки для управления кластером.

Служба кластеров Программа командной строки
Служба Azure Kubernetes (AKS) kubectl (Интерфейс командной строки Kubernetes)
Azure Red Hat OpenShift oc (OpenShift CLI)

Предварительные требования

Создание пароля SA

Учетная запись системного администратора (sa) должна быть защищена с помощью надежного пароля. Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

  1. sa Создайте пароль в кластере Kubernetes. Kubernetes может управлять конфиденциальными сведениями о конфигурации, например паролями, в качестве секретов.

  2. Чтобы создать в Kubernetes секрет с именем mssql, который содержит значение <password> для MSSQL_SA_PASSWORD, выполните указанную ниже команду. Замените <password> на сложный пароль.

    Внимание

    Переменная среды SA_PASSWORD является нерекомендуемой. Вместо этого используйте MSSQL_SA_PASSWORD.

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

Создать хранилище

Для базы данных в кластере Kubernetes необходимо использовать постоянное хранилище. В кластере Kubernetes можно настроить постоянный том и запрос на выделение постоянного тома, используя следующие шаги:

  1. Создайте манифест для определения класса хранилища и запроса на постоянный том. В манифесте указаны провиженер хранилища, параметры и политика возврата. Кластер Kubernetes использует этот манифест для создания постоянного хранилища.

  2. Пример ниже на языке YAML определяет класс хранения и запрос на выделение постоянного тома. Подготовщик класса хранилища — azure-disk, так как этот кластер Kubernetes размещен в Azure. Тип учетной записи хранения — Standard_LRS. Запрос на постоянный том называется mssql-data. Метаданные запроса на постоянный том содержат аннотацию, связывающую его с классом хранения.

    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

    Сохраните файл (например, pvc.yaml).

  3. Создайте запрос на постоянный том в Kubernetes, где <path to pvc.yaml file> является расположением, в котором вы сохранили файл.

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

    Постоянный том создается автоматически как учетная запись хранилища Azure и связывается с запросом на постоянный том.

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

  4. Проверьте запрос на выделение постоянного тома, где <persistentVolumeClaim> — это имя запроса на выделение постоянного тома.

    kubectl describe pvc <persistentVolumeClaim>

    На предыдущем шаге запрос на выделение постоянного тома называется mssql-data. Чтобы просмотреть метаданные о запросе на постоянный том, выполните следующую команду:

    kubectl describe pvc mssql-data

    Возвращаемые метаданные содержат значение с именем Volume. Это значение сопоставляется с именем 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>

    Значение для объёма соответствует части имени BLOB на портале Azure.

  5. Проверьте персистентный том.

    kubectl describe pv

    kubectl возвращает метаданные постоянного тома, который был автоматически создан и связан с запросом на постоянный том.

Создайте развертывание

Контейнер, в котором размещен экземпляр SQL Server, описан как объект развертывания Kubernetes. При развертывании создается набор реплик. Набор реплик создает pod.

Вы создаете манифест для описания контейнера на основе образа Docker SQL Server mssql-server-linux.

  • Манифест ссылается на запрос на выделение постоянного тома mssql-server и секрет mssql, который вы уже применили к кластеру Kubernetes.
  • Манифест также описывает службу. Эта служба является подсистемой балансировки нагрузки. Балансировщик нагрузки гарантирует, что IP-адрес будет сохранен после восстановления инстанции SQL Server.
  • В манифесте описываются запросы и ограничения для ресурсов. Они учитывают минимальные требования к системе.

  1. Создайте манифест (YAML-файл) для описания развертывания. В следующем примере описывается развертывание, включая контейнер, основанный на образе контейнера 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

    Скопируйте приведенный выше код в новый файл с именем sqldeployment.yaml. Измените следующие значения:

    • value: "Developer"MSSQL_PID. Задает контейнер для запуска выпуска SQL Server Developer. Выпуск Developer Edition не лицензирован для рабочих данных. Если развертывание предназначено для использования в рабочей среде, задайте соответствующий выпускEnterprise (Standard или Express). Дополнительные сведения см. в статье о лицензировании SQL Server.

    • persistentVolumeClaim: Для этого значения требуется элемент, который claimName: соотносится с именем, используемым для запроса на постоянный том. В этом учебнике используется mssql-data.

    • name: MSSQL_SA_PASSWORD: настраивает образ контейнера для задания sa пароля, как определено в этом разделе.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Когда Kubernetes развертывает контейнер, он обращается к секрету с именем mssql, чтобы получить значение пароля.

    • securityContext: Определяет настройки управления привилегиями и доступом для pod или контейнера. В этом случае он указан на уровне pod, поэтому все контейнеры соответствуют этому контексту безопасности. В контексте безопасности мы определяем fsGroup со значением 10001, которое является идентификатором группы (GID) для группы mssql. Это значение означает, что все процессы контейнера также являются частью дополнительного идентификатора GID 10001 (mssql). Владелец тома /var/opt/mssql и все файлы, созданные в этом томе, будут иметь GID 10001 (группа mssql).

    Предупреждение

    При использовании типа службы LoadBalancer экземпляр SQL Server будет доступен удаленно (через Интернет) через порт 1433.

    Сохраните файл. Например, sqldeployment.yaml.

  2. Создайте развертывание, где <path to sqldeployment.yaml file> является расположением, в котором сохранен файл:

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

    Развертывание и служба будут созданы. Экземпляр SQL Server находится в контейнере, подключенном к постоянному хранилищу.

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

    Развертывание и служба будут созданы. Экземпляр SQL Server находится в контейнере, подключенном к постоянному хранилищу.

    Для просмотра состояния модуля Pod введите kubectl get pod.

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

    Модуль pod имеет состояние Running. Это состояние указывает, что контейнер готов. После создания развертывания может пройти несколько минут, прежде чем будет виден модуль. Задержка вызвана тем, что кластер извлекает образ mssql-server-linux из реестра артефактов Microsoft. После первого извлечения образа последующие развертывания могут выполняться быстрее, если развертывание выполняется на узле, где уже есть кэшированный образ.

  3. Убедитесь в том, что службы запущены. Выполните следующую команду:

    kubectl get services

    Эта команда возвращает службы, которые выполняются, а также внутренние и внешние IP-адреса этих служб. Запишите внешний IP-адрес для службы mssql-deployment. Используйте этот IP-адрес для подключения к 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

    Чтобы получить дополнительные сведения о состоянии объектов в кластере Kubernetes, выполните указанную ниже команду. Не забудьте заменить <MyResourceGroup> и <MyKubernetesClustername> вашей группой ресурсов и именем кластера Kubernetes:

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

  4. Вы также можете проверить, что контейнер работает как некорневой контейнер, выполнив следующую команду, где <nameOfSqlPod> является именем модуля pod SQL Server:

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

    Вы можете видеть имя пользователя как mssql, если выполняете whoami. mssql не является корневым пользователем.

    whoami

Подключение к экземпляру SQL Server

Вы можете подключиться к приложению за пределами виртуальной сети Azure, используя учетную запись sa и внешний IP-адрес службы. Используйте пароль, настроенный в качестве секрета OpenShift.

Затем можно использовать следующие приложения для подключения к экземпляру SQL Server.

Подключение с помощью sqlcmd

Чтобы подключиться к sqlcmd, выполните следующую команду.

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

Замените <External IP address> IP-адресом службы mssql-deployment и <password> сложным паролем.

Внимание

Пароль должен соответствовать политике паролей по умолчанию SQL Server. По умолчанию пароль должен быть не короче восьми символов и содержать три вида символов из следующих: прописные буквы, строчные буквы, десятичные цифры, специальные символы. Пароли могут иметь длину до 128 символов. Рекомендуется использовать максимально длинные и сложные пароли.

Проверка сбоя и восстановление

Чтобы проверить сбой и восстановление, можно удалить модуль pod с помощью следующих шагов:

  1. Перечислите Pod, в которых работает SQL Server.

    kubectl get pods

    Запишите имя модуля, на котором работает SQL Server.

  2. Удалите модуль.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 — это значение, возвращенное на предыдущем шаге для имени модуля pod.

Kubernetes автоматически повторно создает модуль pod для восстановления экземпляра SQL Server и подключения к постоянному хранилищу. Используйте kubectl get pods для проверки развертывания нового Pod. Используйте kubectl get services для проверки того, что IP-адрес контейнера не изменился.

Очистка ресурсов

Если вы не планируете проходить следующие учебные материалы, удалите ненужные ресурсы. az group delete Используйте команду, чтобы удалить группу ресурсов, службу контейнеров и все связанные ресурсы. Замените <MyResourceGroup> именем группы ресурсов, содержащей кластер.

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

Связанный контент