Развертывание 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 установите средства для работы с большими данными.
- Azure Data CLI (
azdata) kubectl- Azure Data Studio
- Расширение Data Virtualization для Azure Data Studio
- Azure CLI, при развертывании в AKS
Общие сведения о развертывании
Большинство параметров кластера больших данных определяется в файле конфигурации развертывания 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.
Пользовательские конфигурации
Кроме того, можно настроить развертывание специально для выполнения нужных вам рабочих нагрузок. Нельзя изменить масштаб (число реплик) или параметры хранилища для служб кластеров больших данных после развертывания, поэтому необходимо тщательно спланировать конфигурацию развертывания, чтобы избежать проблем с емкостью. Чтобы настроить развертывание, выполните следующие действия:
Начните с одного из стандартных профилей развертывания, соответствующих вашей среде Kubernetes. Для их перечисления можно использовать команду
azdata bdc config list:azdata bdc config listЧтобы настроить развертывание, создайте копию профиля развертывания с помощью команды
azdata bdc config init. Например, следующая команда создает копию файлов конфигурации развертыванияaks-dev-testв целевом каталогеcustom:azdata bdc config init --source aks-dev-test --target customСовет
--targetуказывает каталог, содержащий файлы конфигурацииbdc.jsonиcontrol.json, на основе параметра--source.Чтобы настроить параметры в профиле конфигурации развертывания, можно изменить этот файл в средстве, которое подходит для редактирования 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. Дополнительные сведения см. в статье Настройка параметров развертывания для ресурсов и служб кластеров больших данных.
Передайте пользовательский файл конфигурации в
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, если только оно не изменено в пользовательской конфигурации.
Получение конечных точек
После успешного завершения скрипта развертывания можно получить адреса внешних конечных точек для кластера больших данных, выполнив указанные ниже действия.
После развертывания найдите IP-адрес конечной точки контроллера либо в стандартных выходных данных развертывания, либо в выходных данных EXTERNAL-IP следующей команды
kubectl.kubectl get svc controller-svc-external -n <your-big-data-cluster-name>Совет
Если вы не изменили имя по умолчанию во время развертывания, используйте
-n mssql-clusterв предыдущей команде.mssql-cluster— это имя по умолчанию для кластера больших данных.Войдите в кластер больших данных с помощью 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.Выполните команду 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 см. в следующих статьях.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по