Устранение неполадок доступа, приема и работы кластера Azure Data Explorer в виртуальной сети

Статья
03/28/2023

Важно!

Рассмотрите возможность перехода на решение на основе частной конечной точки Azure для реализации сетевой безопасности с помощью Azure Data Explorer. Оно менее подвержено ошибкам и обеспечивает равенство функций.

В этом разделе описывается, как устранять неполадки подключения, эксплуатации и создания кластеров, развернутых в виртуальной сети.

Проблемы с доступом

Если у вас возникли проблемы при доступе к кластеру с помощью общедоступной (cluster.region.kusto.windows.net) или частной (private-cluster.region.kusto.windows.net) конечной точки и вы подозреваете, что они связаны с настройкой виртуальной сети, выполните следующие действия для устранения проблемы.

Проверка TCP-подключения

Первый шаг предусматривает проверку TCP-подключения с помощью ОС Windows или Linux.

Windows
Linux

Скачайте TCping на компьютер, подключающийся к кластеру.
Проверьте связь исходной виртуальной машины с местом назначения с помощью следующей команды:
```
C:\> tcping -t yourcluster.kusto.windows.net 443
** Pinging continuously.  Press control-c to stop **
Probing 1.2.3.4:443/tcp - Port is open - time=100.00ms
```

Установите netcat на компьютере, подключающемся к кластеру.
```
apt-get install netcat
```
Проверьте связь исходной виртуальной машины с местом назначения с помощью следующей команды:
```
$ netcat -z -v yourcluster.kusto.windows.net 443
Connection to yourcluster.kusto.windows.net 443 port [tcp/https] succeeded!
```

Если проверка не выполнена успешно, перейдите к следующим шагам. Если проверка прошла успешно, проблема не связана с TCP-подключением. Чтобы устранить неполадки, перейдите в раздел Проблемы с работоспособностью.

Проверка правил для группы безопасности сети (NSG)

Убедитесь, что NSG, подключенная к подсети кластера, содержит правило входящего трафика, которое разрешает доступ с IP-адреса клиентского компьютера для порта 443.

Проверьте, настроена ли таблица маршрутизации, чтобы не возникали проблемы с доступом

Если в подсети кластера настроено принудительное туннелирование всего входящего интернет-трафика к вашему брандмауэру (подсеть с таблицей маршрутизации, содержащей маршрут по умолчанию 0.0.0.0/0), убедитесь, что IP-адрес компьютера включает маршрут с типом следующего прыжка к VirtualNetwork/Интернет. Этот маршрут необходим для предотвращения проблем с асимметричными маршрутами.

Проблемы приема

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

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

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

Проверка правил безопасности в ресурсах источников данных

Если метрики указывают, что события не обрабатывались из источника данных (метрика Обработанные события для Центров событий или Интернета вещей), убедитесь, что ресурсы источников данных (Центры событий или служба хранилища) разрешают доступ из подсети кластера в правилах брандмауэра или конечных точках служб.

Проверка правил безопасности, настроенных в подсети кластера

Убедитесь, что в подсети кластера есть NSG и UDR, а правила брандмауэра правильно настроены. Кроме того, проверьте сетевое подключение для всех зависимых конечных точек.

Проблемы при создании и эксплуатации кластера

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

Проверка конфигурации "DNS-серверы"

Для настройки частной конечной точки требуется настройка DNS. Мы поддерживаем только настройку частной зоны DNS Azure. Пользовательская настройка DNS-сервера не поддерживается. Убедитесь, что записи, которые были созданы в рамках частной конечной точки, зарегистрированы в Частной зоне DNS Azure.

Диагностика виртуальной сети с помощью REST API

Чтобы вызвать REST API с помощью командлетов PowerShell, вам потребуется ARMClient.

Выполните вход с помощью ARMClient
```
armclient login
```

Вызов операции диагностики

$subscriptionId = '<subscription id>'
$clusterName = '<name of cluster>'
$resourceGroupName = '<resource group name>'
$apiversion = '2019-11-09'

armclient post "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Kusto/clusters/$clusterName/diagnoseVirtualNetwork?api-version=$apiversion" - verbose

Проверьте ответ

HTTP/1.1 202 Accepted
...
Azure-AsyncOperation: https://management.azure.com/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationResults/{operation-id}?api-version=2019-11-09
...

Ожидание завершения операции

armclient get https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Kusto/locations/{location}/operationResults/{operation-id}?api-version=2019-11-09

{
  "id": "/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationresults/{operation-id}",
  "name": "{operation-name}",
  "status": "[Running/Failed/Completed]",
  "startTime": "{start-time}",
  "endTime": "{end-time}",
  "properties": {...}
}

Дождитесь, пока свойство status не будет отображаться как Completed, а затем в поле properties должно отобразиться следующее:

{
  "id": "/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationresults/{operation-id}",
  "name": "{operation-name}",
  "status": "Completed",
  "startTime": "{start-time}",
  "endTime": "{end-time}",
  "properties": {
    "Findings": [...]
  }
}

Если свойство Findings показывает пустой результат, это означает, что все проверки сети успешно пройдены и подключения работают нормально. Если отображается ошибка Outbound dependency '{dependencyName}:{port}' might be not satisfied (Outbound) (Исходящая зависимость {имя_зависимости}:{порт}, возможно, не выполняется (исходящие данные)), кластер не может получить доступ к зависимым конечным точкам служб. Выполните следующие действия.

Проверка правил NSG

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

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

Если в подсети кластера настроено принудительное туннелирование всего входящего интернет-трафика к вашему брандмауэру (подсеть с таблицей маршрутизации, содержащей маршрут по умолчанию 0.0.0.0/0), убедитесь, что IP-адреса управления и IP-адреса мониторинга работоспособности имеют маршрут с типом следующего прыжкаИнтернет, а также префикс исходного адресаmanagement-ip/32 и health-monitoring-ip/32. Этот маршрут необходим для предотвращения проблем с асимметричными маршрутами.

Проверьте правила брандмауэра.

Если вы применяете принудительное туннелированние исходящего трафика подсети к брандмауэру, убедитесь, что все полные доменные имена зависимостей (например, .blob.core.windows.net) разрешены в конфигурации брандмауэра, как описано в разделе Защита исходящего трафика с помощью брандмауэра.

Проблемы с приостановкой кластера

Если не удается приостановить работу кластера, убедитесь, что сетевые ресурсы в подписке не заблокированы.

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