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


Развертывание SQL Server Кластеры больших данных в Kubernetes

Область применения: SQL Server 2019 (15.x)

Внимание

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

Кластер больших данных SQL Server развертывается в виде контейнеров Docker в кластере Kubernetes. Здесь описаны этапы настройки.

  • Настройте кластер Kubernetes на одной виртуальной машине, в кластере виртуальных машин, в службе Azure Kubernetes (AKS), в Red Hat OpenShift или в Azure Red Hat OpenShift (ARO).
  • Установите средство настройки кластера Azure Data CLI (azdata) на клиентском компьютере.
  • Разверните кластер больших данных SQL Server в кластере Kubernetes.

Проверенные конфигурации

Полный список платформ Kubernetes, проверенных для развертывания кластеров больших данных SQL Server, см. в разделе Проверенные конфигурации.

Выпуски SQL Server

Выпуск Примечания.
Функции корпоративного уровня
Стандартные
разработчик.
Выпуск кластера больших данных определяется выпуском основного экземпляра SQL Server. Во время развертывания выпуск Developer развертывается по умолчанию. После развертывания выпуск можно изменить. См. Настройка основного экземпляра SQL Server.

Kubernetes

Настройка кластера Kubernetes

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

Вы можете развернуть Kubernetes указанными ниже способами.

Расположение развертывания Kubernetes Description Ссылка
Службы Azure Kubernetes (AKS) Управляемая служба контейнеров Kubernetes в Azure. Инструкции
Один или несколько компьютеров (kubeadm) Кластер Kubernetes, развернутый на физических компьютерах или виртуальных машинах с помощью kubeadm Инструкции
Azure Red Hat OpenShift Управляемое предложение OpenShift, выполняемое в Azure. Инструкции
Red Hat OpenShift Гибридное облако, корпоративная платформа приложений Kubernetes. Инструкции

Совет

Вы также можете создать скрипт для развертывания AKS и кластера больших данных за один шаг. Дополнительные сведения о том, как это сделать, см. в скрипте Python или в записной книжке Azure Data Studio.

Проверка конфигурации Kubernetes

Выполните команду kubectl, чтобы просмотреть конфигурацию кластера. Убедитесь, что kubectl указывает на правильный контекст кластера.

kubectl config view

Внимание

При развертывании в кластере Kubernetes с несколькими узлами, начальная загрузка которого выполняется с помощью kubeadm. Перед развертыванием кластера больших данных необходимо убедиться, что часы во всех узлах Kubernetes, участвующих в развертывании, синхронизированы. Кластер больших данных имеет встроенные свойства обеспечения работоспособности разных служб, которые зависят от времени, поэтому любые отклонения во времени могут привести к неправильной работе системы.

После настройки кластера Kubernetes можно перейти к развертыванию нового кластера больших данных SQL Server. Если вы обновляете предыдущий выпуск, ознакомьтесь с тем, как обновить SQL Server Кластеры больших данных.

Убедитесь, что хранилище настроено

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

  • При развертывании в AKS настройка хранилища не требуется. AKS предоставляет встроенные классы хранения с динамической подготовкой. Вы можете настроить класс хранения (default или managed-premium) в файле конфигурации развертывания. Встроенные профили используют класс хранения default.
  • При развертывании в кластере Kubernetes, развернутом с помощью kubeadm, необходимо убедиться в наличии достаточного объема хранилища для кластера, доступного для требуемого масштабирования и настроенного для использования. Если вы хотите настроить использование хранилища, сделайте это перед продолжением. См. раздел Сохраняемость данных при использовании кластера больших данных SQL Server в Kubernetes.

Установка средств для работы с большими данными SQL Server 2019

Перед развертыванием кластера больших данных SQL Server 2019 установите средства для работы с большими данными.

Общие сведения о развертывании

Большинство параметров кластера больших данных определяется в файле конфигурации развертывания JSON. Вы можете использовать профиль развертывания по умолчанию для кластеров AKS и Kubernetes, созданных с помощью kubeadm, или настроить собственный файл конфигурации развертывания для использования во время установки. По соображениям безопасности параметры проверки подлинности передаются через переменные среды.

Следующие разделы содержат дополнительные сведения о настройке развертываний кластера больших данных, а также примеры распространенных настроек. Кроме того, вы всегда можете изменить пользовательский файл конфигурации развертывания в редакторе, таком как VS Code.

Конфигурации по умолчанию

Параметры развертывания кластера больших данных определяются в файлах конфигурации JSON. Вы можете начать настройку развертывания кластера из встроенных профилей развертывания, доступных в Azure Data CLI (azdata).

Примечание.

Образы контейнеров, необходимые для развертывания кластера больших данных, размещаются в реестре контейнеров Microsoft (mcr.microsoft.com) в репозитории mssql/bdc. По умолчанию эти параметры уже включены в файл конфигурации control.json в каждом из профилей развертывания, включенных в Azure Data CLI (azdata). Кроме того, тег образа контейнера для каждого выпуска также предварительно заполняется в том же файле конфигурации. Если необходимо извлечь образы контейнеров в собственный частный реестр контейнеров и изменить параметры реестра контейнеров или репозитория, следуйте инструкциям в статье Автономная установка.

Выполните следующую команду, чтобы найти доступные шаблоны:

azdata bdc config list -o table 

В SQL Server 2019 CU5 доступны следующие шаблоны.

Профиль развертывания Среда Kubernetes
aks-dev-test Развертывание кластера больших данных SQL Server в службе Azure Kubernetes (AKS)
aks-dev-test-ha Развертывание кластера больших данных SQL Server в службе Azure Kubernetes (AKS). Критически важные службы, такие как основной экземпляр SQL Server и узел имен HDFS, настроены для обеспечения высокой доступности.
aro-dev-test Развертывание кластера больших данных SQL Server в Azure Red Hat OpenShift для разработки и тестирования.

Впервые представлено в SQL Server 2019 CU5.
aro-dev-test-ha Развертывание кластера больших данных SQL Server с высоким уровнем доступности в кластере Red Hat OpenShift для разработки и тестирования.

Впервые представлено в SQL Server 2019 CU5.
kubeadm-dev-test Развертывание кластера больших данных SQL Server в кластере Kubernetes, созданном с помощью kubeadm на одной или нескольких физических или виртуальных машинах.
kubeadm-prod Развертывание кластера больших данных SQL Server в кластере Kubernetes, созданном с помощью kubeadm на одной или нескольких физических или виртуальных машинах. Используйте этот шаблон, чтобы включить интеграцию служб кластеров больших данных с Active Directory. Критически важные службы, такие как основной экземпляр SQL Server и узел имен HDFS, настроены для обеспечения высокой доступности.
openshift-dev-test Развертывание кластера больших данных SQL Server в кластере Red Hat OpenShift для разработки и тестирования.

Впервые представлено в SQL Server 2019 CU5.
openshift-prod Развертывание кластера больших данных SQL Server с высоким уровнем доступности в кластере Red Hat OpenShift.

Впервые представлено в SQL Server 2019 CU5.

Кластер больших данных можно развернуть, выполнив команду azdata bdc create. Вам будет предложено выбрать одну из конфигураций по умолчанию, а затем выполнить развертывание, следуя указаниям.

При первом запуске Azure Data CLI (azdata) необходимо включить --accept-eula=yes для принятия лицензионного соглашения конечного пользователя (EULA).

azdata bdc create --accept-eula=yes

В этом сценарии вам будет предложено ввести параметры, не входящие в конфигурацию по умолчанию, например пароли.

Внимание

Имя кластера больших данных по умолчанию — mssql-cluster. Это важно знать, чтобы выполнить любую из команд kubectl, задающих пространство имен Kubernetes с параметром -n.

Пользовательские конфигурации

Кроме того, можно настроить развертывание специально для выполнения нужных вам рабочих нагрузок. Нельзя изменить масштаб (число реплик) или параметры хранилища для служб кластеров больших данных после развертывания, поэтому необходимо тщательно спланировать конфигурацию развертывания, чтобы избежать проблем с емкостью. Чтобы настроить развертывание, выполните следующие действия:

  1. Начните с одного из стандартных профилей развертывания, соответствующих вашей среде Kubernetes. Для их перечисления можно использовать команду azdata bdc config list:

    azdata bdc config list
    
  2. Чтобы настроить развертывание, создайте копию профиля развертывания с помощью команды azdata bdc config init. Например, следующая команда создает копию файлов конфигурации развертывания aks-dev-test в целевом каталоге custom:

    azdata bdc config init --source aks-dev-test --target custom
    

    Совет

    --target указывает каталог, содержащий файлы конфигурации bdc.json и control.json, на основе параметра --source.

  3. Чтобы настроить параметры в профиле конфигурации развертывания, можно изменить этот файл в средстве, которое подходит для редактирования JSON-файлов, например VS Code. Для автоматизации на основе скриптов можно также изменить пользовательский профиль развертывания с помощью команды azdata bdc config. Например, следующая команда изменяет пользовательский профиль развертывания, чтобы изменить имя развернутого кластера с используемого по умолчанию (mssql-cluster) на test-cluster.

    azdata bdc config replace --config-file custom/bdc.json --json-values "metadata.name=test-cluster"
    

    Совет

    Вы также можете передать имя кластера во время развертывания с помощью параметра --name для azdata create bdc команды. Параметры в команде имеют приоритет над значениями в файлах конфигурации.

    Полезным инструментом для поиска путей JSON является JSONPath Online Evaluator.

    Кроме передачи пар "ключ — значение", можно также указать встроенные значения JSON или передать файлы исправлений JSON. Дополнительные сведения см. в статье Настройка параметров развертывания для ресурсов и служб кластеров больших данных.

  4. Передайте пользовательский файл конфигурации в azdata bdc create. Обратите внимание, что требуется задать необходимые переменные среды, в противном случае терминал предложит ввести эти значения:

    azdata bdc create --config-profile custom --accept-eula yes
    

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

Параметр imagePullPolicy в файле control.json для профиля развертывания должен иметь значение "Always".

Дополнительные сведения о структуре файла конфигурации развертывания см. в справочнике по файлу конфигурации развертывания. Дополнительные примеры конфигурации см. в статье Настройка параметров развертывания для кластеров больших данных.

Переменные среды

Указанные ниже переменные среды используются для параметров безопасности, которые не хранятся в файле конфигурации развертывания. Обратите внимание, что параметры Docker, за исключением учетных данных, можно задать в файле конфигурации.

Переменная среды Требование Description
AZDATA_USERNAME Обязательное поле Имя пользователя администратора кластера больших данных SQL Server. Данные для входа sysadmin с тем же именем создаются в основном экземпляре SQL Server. В целях безопасности учетная запись sa отключена.

Начиная с SQL Server 2019 (15.x) CU 5 при развертывании нового кластера с базовой проверкой подлинности всех конечных точек, включая использование AZDATA_USERNAME шлюза и AZDATA_PASSWORD. Конечные точки в кластерах, которые обновлены до накопительного пакета обновления 5, продолжают использовать root в качестве имени пользователя для подключения к конечной точке шлюза. Это изменение не применяется к развертываниям, в которых используется проверка подлинности с помощью Active Directory. Подробные сведения см. в заметках о выпуске в разделе Учетные данные для доступа к службам через конечную точку шлюза.
AZDATA_PASSWORD Обязательное поле Пароль для учетной записи пользователя, созданной выше. В кластерах, развернутых до версии SQL Server 2019 CU5, один и тот же пароль используется для пользователя root, для защиты шлюза Knox и HDFS.
ACCEPT_EULA Требуется для первого использования Azure Data CLI (azdata) Выберите "Да". При установке в качестве переменной среды она применяет EULA как к SQL Server, так и к Azure Data CLI (azdata). Если параметр не задан в качестве переменной среды, можно включить --accept-eula=yes при первом использовании команды Azure Data CLI (azdata).
DOCKER_USERNAME Необязательно Имя пользователя для доступа к образам контейнера в случае, если они хранятся в частном репозитории. Дополнительные сведения о том, как использовать частный репозиторий Docker для развертывания кластеров больших данных, см. в разделе Автономные развертывания.
DOCKER_PASSWORD Необязательно Пароль для доступа к указанному выше частному репозиторию.

Эти переменные среды необходимо задать до вызова команду azdata bdc create. Если какая-либо из переменных не задана, вам будет предложено ввести ее.

В следующем примере показано, как задать переменные среды для Linux (bash) и Windows (PowerShell).

export AZDATA_USERNAME=admin
export AZDATA_PASSWORD=<password>
export ACCEPT_EULA=yes
SET AZDATA_USERNAME=admin
SET AZDATA_PASSWORD=<password>

Примечание.

В кластерах, развернутых до версии SQL Server 2019 CU5, для шлюза Knox необходимо использовать пользователя root с указанным выше паролем. root — это единственный пользователь, поддерживаемый этим методом обычной проверки подлинности (имя пользователя и пароль).

Начиная с SQL Server 2019 (15.x) CU 5 при развертывании нового кластера с базовой проверкой подлинности всех конечных точек, включая использование AZDATA_USERNAME шлюза и AZDATA_PASSWORD. Конечные точки в кластерах, которые обновлены до накопительного пакета обновления 5, продолжают использовать root в качестве имени пользователя для подключения к конечной точке шлюза. Это изменение не применяется к развертываниям, в которых используется проверка подлинности с помощью Active Directory. Подробные сведения см. в заметках о выпуске в разделе Учетные данные для доступа к службам через конечную точку шлюза.

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

После задания переменных среды нужно запустить azdata bdc create, чтобы активировать развертывание. В этом примере используется профиль конфигурации кластера, созданный ранее.

azdata bdc create --config-profile custom --accept-eula yes

Нужно учитывать следующее.

  • Заключите пароль в двойные кавычки, если он содержит специальные символы. Вы можете задать для AZDATA_PASSWORD любое значение, но убедитесь, что пароль достаточно сложен и не содержит символы !, & или '. Обратите внимание, что разделители в виде двойных кавычек работают только в командах bash.
  • Учетная запись AZDATA_USERNAME обладает правами системного администратора на главном экземпляре SQL Server, создаваемом во время установки. После создания контейнера SQL Server указанную вами переменную среды AZDATA_PASSWORD можно обнаружить, запустив echo $AZDATA_PASSWORD в контейнере. В целях безопасности измените пароль.

Автоматическая установка

Для автоматического развертывания нужно задать все необходимые переменные среды, использовать файл конфигурации и вызвать команду azdata bdc create с параметром --accept-eula yes. Примеры в предыдущем разделе демонстрируют синтаксис для автоматической установки.

Мониторинг развертывания

Во время начальной загрузки кластера командное окно клиента возвращает состояние развертывания. В процессе развертывания вы увидите ряд сообщений об ожидании pod контроллера.

Waiting for cluster controller to start.

В течение 15–30 минут вы должны получить уведомление о том, что pod контроллера работает.

Cluster controller endpoint is available at 11.111.111.11:30080.
Cluster control plane is ready.

Внимание

Полное развертывание может занять много времени из-за временных затрат на скачивание образов контейнеров для компонентов кластера больших данных. Однако это не должно занять несколько часов. Если у вас возникли проблемы с развертыванием, см. статью "Мониторинг и устранение неполадок с SQL Server Кластеры больших данных".

После завершения развертывания выходные данные указывают на успешное выполнение.

Cluster deployed successfully.

Совет

Именем по умолчанию для развернутого кластера больших данных является mssql-cluster, если только оно не изменено в пользовательской конфигурации.

Получение конечных точек

После успешного завершения скрипта развертывания можно получить адреса внешних конечных точек для кластера больших данных, выполнив указанные ниже действия.

  1. После развертывания найдите IP-адрес конечной точки контроллера либо в стандартных выходных данных развертывания, либо в выходных данных EXTERNAL-IP следующей команды kubectl.

    kubectl get svc controller-svc-external -n <your-big-data-cluster-name>
    

    Совет

    Если вы не изменили имя по умолчанию во время развертывания, используйте -n mssql-cluster в предыдущей команде. mssql-cluster — это имя по умолчанию для кластера больших данных.

  2. Войдите в кластер больших данных с помощью azdata login. Задайте для параметра --endpoint значение внешнего IP-адреса конечной точки контроллера.

    azdata login --endpoint https://<ip-address-of-controller-svc-external>:30080 --username <user-name>
    

    Укажите имя пользователя и пароль, настроенные для администратора кластера больших данных (AZDATA_USERNAME и AZDATA_PASSWORD) во время развертывания.

    Совет

    Если вы являетесь администратором кластера Kubernetes и имеете доступ к файлу конфигурации кластера (файл конфигурации kube), можно настроить текущий контекст так, чтобы он указывал на целевой кластер Kubernetes. В этом случае можно выполнить вход с помощью azdata login -n <namespaceName>, где namespace — имя кластера больших данных. Вам будет предложено ввести учетные данные, если они не указаны в команде login.

  3. Выполните команду azdata bdc endpoint list, чтобы получить список с описанием каждой конечной точки и соответствующими значениями IP-адреса и порта.

    azdata bdc endpoint list -o table
    

    Следующий список содержит пример выходных данных этой команды.

    Description                                             Endpoint                                                   Ip              Name               Port    Protocol
    ------------------------------------------------------  ---------------------------------------------------------  --------------  -----------------  ------  ----------
    Gateway to access HDFS files, Spark                     https://11.111.111.111:30443                               11.111.111.111  gateway            30443   https
    Spark Jobs Management and Monitoring Dashboard          https://11.111.111.111:30443/gateway/default/sparkhistory  11.111.111.111  spark-history      30443   https
    Spark Diagnostics and Monitoring Dashboard              https://11.111.111.111:30443/gateway/default/yarn          11.111.111.111  yarn-ui            30443   https
    Application Proxy                                       https://11.111.111.111:30778                               11.111.111.111  app-proxy          30778   https
    Management Proxy                                        https://11.111.111.111:30777                               11.111.111.111  mgmtproxy          30777   https
    Log Search Dashboard                                    https://11.111.111.111:30777/kibana                        11.111.111.111  logsui             30777   https
    Metrics Dashboard                                       https://11.111.111.111:30777/grafana                       11.111.111.111  metricsui          30777   https
    Cluster Management Service                              https://11.111.111.111:30080                               11.111.111.111  controller         30080   https
    SQL Server Master Instance Front-End                    11.111.111.111,31433                                       11.111.111.111  sql-server-master  31433   tcp
    HDFS File System Proxy                                  https://11.111.111.111:30443/gateway/default/webhdfs/v1    11.111.111.111  webhdfs            30443   https
    Proxy for running Spark statements, jobs, applications  https://11.111.111.111:30443/gateway/default/livy/v1       11.111.111.111  livy               30443   https
    

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

kubectl get svc -n <your-big-data-cluster-name>

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

После развертывания можно проверить состояние кластера с помощью команды azdata bdc status show.

azdata bdc status show

Совет

Чтобы выполнить команды состояния, нужно сначала войти в систему с помощью команды azdata login, которая была приведена в предыдущем разделе о конечных точках.

Ниже приведен пример выходных данных этой команды.

Bdc: ready                                                                                                                                                                                                          Health Status:  healthy
 ===========================================================================================================================================================================================================================================
 Services: ready                                                                                                                                                                                                     Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Servicename    State    Healthstatus    Details

 sql            ready    healthy         -
 hdfs           ready    healthy         -
 spark          ready    healthy         -
 control        ready    healthy         -
 gateway        ready    healthy         -
 app            ready    healthy         -


 Sql Services: ready                                                                                                                                                                                                 Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 master          ready    healthy         StatefulSet master is healthy
 compute-0       ready    healthy         StatefulSet compute-0 is healthy
 data-0          ready    healthy         StatefulSet data-0 is healthy
 storage-0       ready    healthy         StatefulSet storage-0 is healthy


 Hdfs Services: ready                                                                                                                                                                                                Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 nmnode-0        ready    healthy         StatefulSet nmnode-0 is healthy
 storage-0       ready    healthy         StatefulSet storage-0 is healthy
 sparkhead       ready    healthy         StatefulSet sparkhead is healthy


 Spark Services: ready                                                                                                                                                                                               Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 sparkhead       ready    healthy         StatefulSet sparkhead is healthy
 storage-0       ready    healthy         StatefulSet storage-0 is healthy


 Control Services: ready                                                                                                                                                                                             Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 controldb       ready    healthy         -
 control         ready    healthy         -
 metricsdc       ready    healthy         DaemonSet metricsdc is healthy
 metricsui       ready    healthy         ReplicaSet metricsui is healthy
 metricsdb       ready    healthy         StatefulSet metricsdb is healthy
 logsui          ready    healthy         ReplicaSet logsui is healthy
 logsdb          ready    healthy         StatefulSet logsdb is healthy
 mgmtproxy       ready    healthy         ReplicaSet mgmtproxy is healthy


 Gateway Services: ready                                                                                                                                                                                             Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 gateway         ready    healthy         StatefulSet gateway is healthy


 App Services: ready                                                                                                                                                                                                 Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 appproxy        ready    healthy         ReplicaSet appproxy is healthy

Можно также получить более подробные сведения о состоянии с помощью следующих команд.

  • Команда azdata bdc control status show возвращает состояние работоспособности для всех компонентов, связанных со службой управления.
azdata bdc control status show

Образец вывода:

Control: ready                                                                                                                                                                                                      Health Status:  healthy
 ===========================================================================================================================================================================================================================================
 Resources: ready                                                                                                                                                                                                    Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 controldb       ready    healthy         -
 control         ready    healthy         -
 metricsdc       ready    healthy         DaemonSet metricsdc is healthy
 metricsui       ready    healthy         ReplicaSet metricsui is healthy
 metricsdb       ready    healthy         StatefulSet metricsdb is healthy
 logsui          ready    healthy         ReplicaSet logsui is healthy
 logsdb          ready    healthy         StatefulSet logsdb is healthy
 mgmtproxy       ready    healthy         ReplicaSet mgmtproxy is healthy
  • azdata bdc sql status show возвращает состояние работоспособности для всех ресурсов со службой SQL Server
azdata bdc sql status show

Образец вывода:

Sql: ready                                                                                                                                                                                                          Health Status:  healthy
 ===========================================================================================================================================================================================================================================
 Resources: ready                                                                                                                                                                                                    Health Status:  healthy
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Resourcename    State    Healthstatus    Details

 master          ready    healthy         StatefulSet master is healthy
 compute-0       ready    healthy         StatefulSet compute-0 is healthy
 data-0          ready    healthy         StatefulSet data-0 is healthy
 storage-0       ready    healthy         StatefulSet storage-0 is healthy

Внимание

При использовании параметра --all выходные данные этих команд содержат URL-адреса панелей мониторинга Kibana и Grafana для более подробного анализа.

Помимо использования Azure Data CLI (azdata), вы также можете использовать Azure Data Studio для поиска конечных точек и сведений о состоянии. Дополнительные сведения о просмотре состояния кластера с помощью Azure Data CLI (azdata) и Azure Data Studio см. в статье "Просмотр состояния кластера больших данных".

Подключение к кластеру

Дополнительные сведения о подключении к кластеру больших данных см. в статье Подключение к кластеру больших данных SQL Server с помощью Azure Data Studio.

Следующие шаги

Дополнительные сведения о развертывании кластера больших данных SQL Server см. в следующих статьях.