Бөлісу құралы:

Известные проблемы с платформой SQL Server 2019 Кластеры больших данных

  • Мақала

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

Внимание

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

Известные проблемы

При копировании больших файлов в HDFS с помощью azdata возникают случайные сбои

  • Затронутый выпуск: CU14

  • Проблема и влияние на клиентов: эта ошибка приводила к случайным сбоям при выполнении команд azdata bdc cp между путями HDFS. Ошибка чаще затрагивает копии больших файлов.

  • Решение: установите накопительный пакет обновления версии 15 (CU15).

Безопасность Log4j

  • Затронутый выпуск: нет

  • Проблема и влияние на клиентов: мы провели тщательную оценку базы кода Кластеров больших данных SQL Server 2019, но риски, связанные с уязвимостью log4j, о которой нам сообщили в декабре, не были обнаружены. CU15 включает обновленную версию log4j (2.17) для экземпляра ElasticSearch в плоскости управления, чтобы гарантировать, что оповещения сканирования изображений не активируются статическим анализом кода контейнеров кластера больших данных.

  • Решение. Всегда выполняйте на кластере больших данных обновление до последнего выпуска.

Обновление кластера с выпусков CU8 и ниже до выпусков выше CU9 не поддерживается

  • Затронутые выпуски: CU8 и более ранние выпуски.

  • Проблема и влияние на клиентов: при обновлении кластера с CU8 или более ранним выпуском напрямую до любого выпуска новее CU9 обновление завершится сбоем на этапе мониторинга.

  • Решение: сначала выполните обновление до выпуска CU9. Затем выполните обновление с выпуска CU9 до последней версии.

Платформы Kubernetes с API Kubernetes версии 1.21 и более поздней версии

  • Затронутые выпуски: все выпуски

  • Проблема и влияние клиента: API Kubernetes 1.21 или более высокий не является проверенной конфигурацией SQL Server Кластеры больших данных с накопительным пакетом обновления 12 (CU12).

Пакеты MicrosoftML в Службах машинного обучения SQL Server

  • Затронутые выпуски: CU10, CU11, CU12 и CU13

  • Проблема и влияние на клиентов: некоторые пакеты MicrosoftML R/Python в Службах машинного обучения SQL Server не работают. Это влияет на все главные экземпляры SQL Server.

Не удалось подключиться к удаленному экземпляру SQL Server 2016 или более ранней версии

  • Затронутый выпуск: CU10
  • Проблема и влияние клиента: при использовании PolyBase в SQL Server 2019 Кластеры больших данных CU10 для подключения к существующему экземпляру SQL Server, использующему сертификат для шифрования каналов, созданного с помощью алгоритма SHA1, может возникнуть следующая ошибка:

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • Решение. Из-за более строгих требований к безопасности в Ubuntu 20.04 по сравнению с предыдущей версией базового образа удаленное подключение с использованием сертификата на базе алгоритма SHA1 не разрешено. Самозаверяющий сертификат SQL Server выпусков 2005–2016 по умолчанию использовал алгоритм SHA1. Дополнительные сведения об изменениях, внесенных в самозаверяющие сертификаты в SQL Server 2017, см. в этой записи блога. В удаленном экземпляре SQL Server используйте сертификат, который создан с помощью алгоритма, имеющего по крайней мере 112-битный уровень безопасности (например, SHA256). Для рабочих сред рекомендуется получить доверенный сертификат из центра сертификации. В целях тестирования можно использовать самозаверяющие сертификаты. Чтобы создать самозаверяющий сертификат, см. раздел о командлете PowerShell New-SelfSignedCertificate или команде certreq. Инструкции по установке нового сертификата в удаленном экземпляре SQL Server см. в разделе Включение зашифрованных соединений для ядра СУБД.

Частичная потеря журналов, собранных в ElasticSearch, после отката

  • Затронутые выпуски: существующие кластеры в случае, если сбой обновления до CU9 приводит к откату или пользователь инициирует переход на более раннюю версию.

  • Проблема и влияние клиента: версия программного обеспечения, используемая для эластичного поиска, была обновлена с накопительным пакетом обновления 9 (CU9), а новая версия не совместима с предыдущими файлами журнала или метаданными. Если компонент ElasticSearch успешно обновляется, но последующий откат активируется, журналы, собранные между обновлением ElasticSearch и откатом, окончательно теряются. Если вы инициируете переход на более раннюю версию Кластеров больших данных SQL Server 2019 (не рекомендуется), хранящиеся в Elasticsearch журналы будут утеряны. При обновлении до CU9 данные восстанавливаются.

  • Решение. При необходимости можно устранить неполадки с помощью журналов, собранных с помощью azdata bdc debug copy-logs команды.

Отсутствие метрик модулей pod и контейнеров

  • Затронутые выпуски: существующие и новые кластеры после обновления до CU9

  • Проблема и влияние клиента. В результате обновления версии Telegraf, используемой для компонентов мониторинга в CU9, при обновлении кластера до выпуска CU9 вы заметите, что модули pod и метрики контейнеров не собираются. Это связано с тем, что в определении роли кластера, используемой для Telegraf в результате обновления программного обеспечения, требуется дополнительный ресурс. Если пользователь, который развертывает кластер или выполняет обновление, не имеет нужных разрешений, то отобразится предупреждение, после чего развертывание или обновление будет выполнено, однако метрики модулей pod и узлов собираться не будут.

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

Выдача azdata bdc copy-logs не приводит к копированию журналов

  • Затронутые выпуски: Azure Data CLI (azdata) версии 20.0.0

  • Проблема и влияние на клиентов: для выполнения команды copy-logs предполагается, что на клиентском компьютере, с которого была запущена команда, установлено клиентское средство kubectl версии 1.15 или более поздней. Если kubectl используется версия 1.14, azdata bdc debug copy-logs команда завершается без сбоев, но журналы не копируются. При запуске с флагом --debug в выходных данных может отобразиться следующая ошибка: source '.' is invalid (источник "." недопустим).

  • Возможное решение. Установите средство kubectl версии 1.15 или выше на тот же клиентский компьютер и повторите команду azdata bdc copy-logs. Инструкции по установке kubectl см. здесь.

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

  • Затронутые выпуски: все конфигурации развертывания кластера больших данных независимо от выпуска.

  • Проблема и влияние клиента. При развертывании SQL Server в кластере больших данных в качестве главного экземпляра SQL Server функция MSDTC не может быть включена. Для этой проблемы обходного решения не существует.

Смена шифратора ключа шифрования базы данных SQL Server с высоким уровнем доступности

  • Затронутые выпуски: все версии до накопительного пакета обновления 8. Устранено для накопительного пакета обновления 9.

  • Проблема и влияние на клиентов: при развертывании SQL Server с высоким уровнем доступности происходит сбой смены сертификата для зашифрованной базы данных. При выполнении следующей команды в главном пуле появится сообщение об ошибке:

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

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

Включение поддержки зон шифрования HDFS в CU8

  • Затронутые выпуски: этот сценарий касается обновления с версии накопительного пакета обновления 6 или более ранней до версии 8. Он не затрагивает новые развертывания накопительного пакета обновления 8 или более поздней версии либо прямое обновление до накопительного пакета обновления 9. Выпуски CU10 или более поздних версий не затрагиваются.

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

Пустые задания Livy перед применением накопительных обновлений

  • Затронутые выпуски: все версии до cu6. Разрешено для CU8.

  • Проблема и влияние на клиентов: во время обновления sparkhead возвращает ошибку 404.

  • Возможное решение. Перед обновлением кластера больших данных убедитесь, что активные сессии Livy и пакетные задания отсутствуют. Чтобы избежать этого, следуйте инструкциям в разделе Обновление поддерживаемого выпуска.

    Если Livy возвращает ошибку 404 во время процесса обновления, перезапустите сервер Livy на обоих узлах sparkhead. Например:

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

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

  • Затронутые выпуски: все развертывания кластера больших данных с интеграцией Active Directory независимо от выпуска

  • Проблема и влияние на клиентов: во время развертывания кластера больших данных рабочий процесс создает набор учетных записей служб. В зависимости от политики истечения срока действия паролей, заданной на контроллере домена, срок действия паролей для этих учетных записей может истечь (срок по умолчанию — 42 дня). В настоящее время нет механизма смены учетных данных для всех учетных записей в кластере больших данных, поэтому кластер становится неработоспособным после завершения срока действия.

  • Возможное решение. В контроллере домена измените политику срока действия для учетных записей службы в кластере больших данных на "Срок действия пароля не ограничен". Полный список этих учетных записей см. в статье Автоматически созданные объекты Active Directory. Это действие можно выполнить до или после истечения срока действия. В последнем случае Active Directory повторно активирует пароли с истекшим сроком действия.

Учетные данные для доступа к службам через конечную точку шлюза

  • Затронутые выпуски: новые кластеры, развернутые начиная с накопительного пакета обновления 5 (CU5).

  • Проблема и влияние клиента. Для новых кластеров больших данных, развернутых с помощью SQL Server Кластеры больших данных CU5, имя пользователя шлюза не rootявляется. Если приложение, применяемое для подключения к конечной точке шлюза, использует неверные учетные данные, выводится ошибка проверки подлинности. Это изменение приводит к запуску приложений в кластере больших данных как не корневого пользователя (новое поведение по умолчанию, начиная с выпуска SQL Server Кластеры больших данных CU5, при развертывании нового кластера больших данных с помощью CU5 имя пользователя для конечной точки шлюза основано на значении, передаваемом через AZDATA_USERNAME переменную среды. Это то же имя пользователя, которое используется для контроллера и конечных точек SQL Server. Это влияет только на новые развертывания. Существующие кластеры больших данных, развернутые с любым из предыдущих выпусков, продолжают использовать root. При развертывании кластера, использующего проверку подлинности на основе Active Directory, учетные данные остаются прежними.

  • Обходной путь. Azure Data Studio прозрачно обрабатывает учетные данные, внесенные в шлюз, чтобы включить просмотр HDFS в обозреватель объектов. Необходимо установить последнюю версию Azure Data Studio, которая включает в себя необходимые изменения, устраняющие этот вариант использования. Для других сценариев, в которых необходимо предоставлять учетные данные для доступа к службе через шлюз (например, для входа с помощью Azure Data CLI (azdata) и доступа к веб-панелям мониторинга Spark), необходимо убедиться, что используются правильные учетные данные. Если вы используете существующий кластер, развернутый до накопительного пакета обновления 5, вы продолжите использовать root имя пользователя для подключения к шлюзу, даже после обновления кластера до CU5. При развертывании нового кластера с помощью сборки CU5 войдите, указав имя пользователя, соответствующее AZDATA_USERNAME переменной среды.

Метрики для модулей pod и узлов не собираются

  • Затронутые выпуски: новые и существующие кластеры, использующие образы CU5

  • Проблема и влияние клиента. В результате исправления безопасности, связанного с API, telegraf который использовался для сбора метрик pod и метрик узла узла, клиенты могут заметить, что метрики не собираются. Это возможно как в новых, так и в существующих развертываниях Кластеров больших данных SQL Server 2019 (после обновления до версии CU5). В результате этого исправления для Telegraf теперь требуется учетная запись службы с разрешениями роли в масштабе кластера. Развертывание пытается создать необходимую учетную запись службы и роль кластера, но если пользователь развертывает кластер или выполняет обновление не имеет достаточных разрешений, развертывание и обновление продолжается с предупреждением и успешно, но метрики pod и узлов не будут собраны.

  • Возможное решение. Попросите администратора создать роль и учетную запись службы (до или после развертывания либо обновления), чтобы кластер больших данных использовал их. В этой статье описано, как создать необходимые артефакты.

сбой команды azdata bdc copy-logs

  • Затронутые выпуски: Azure Data CLI (azdata) версии 20.0.0

  • Проблема и влияние на клиентов: для выполнения команды copy-logs предполагается, что на клиентском компьютере, с которого была запущена команда, установлено клиентское средство kubectl. Если команда выполняется в кластере больших данных, установленном в OpenShift, с клиента, на котором установлено только средство oc, то выдается следующая ошибка: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified (При сборе журналов произошла ошибка: [WinError 2] система не может найти указанный файл).

  • Возможное решение. Установите средство kubectl на тот же клиентский компьютер и повторите команду azdata bdc copy-logs. Инструкции по установке kubectl см. здесь.

Развертывание в частном репозитории

  • Затронутые выпуски: GDR1, CU1, CU2. Устранено для CU3.

  • Проблема и влияние на клиентов: к обновлению из частного репозитория предъявляются особые требования.

  • Решение. Если вы используете частный репозиторий для предварительного извлечения образов для развертывания или обновления кластера больших данных, убедитесь, что текущие образы сборки и целевые образы сборки находятся в частном репозитории. Так вы сможете при необходимости успешно выполнить откат. Кроме того, если вы изменили учетные данные частного репозитория с момента первоначального развертывания, обновите соответствующий секрет в Kubernetes, прежде чем выполнять обновление. Azure Data CLI (azdata) не поддерживает обновление учетных данных с помощью AZDATA_PASSWORD переменных среды и AZDATA_USERNAME среды. Создайте секрет с помощью kubectl edit secrets.

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

Обновление может завершиться ошибкой из-за времени ожидания

  • Затронутые выпуски: GDR1, CU1, CU2. Устранено для CU3.

  • Проблема и влияние клиента: обновление может завершиться ошибкой из-за времени ожидания.

    В приведенном ниже коде показано, как может выглядеть ошибка:

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    Эта ошибка чаще всего возникает при обновлении Кластеров больших данных SQL Server 2019 в службе Azure Kubernetes (AKS).

  • Обходное решение. Увеличьте время ожидания обновления.

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

    1. Выполните следующую команду:

      kubectl edit configmap controller-upgrade-configmap

    2. Измените следующие поля:

      controllerUpgradeTimeoutInMinutes — указывает количество минут ожидания завершения обновления базы данных контроллера или контроллера. Значение по умолчанию — 5. Используйте значение не ниже 20.

      totalUpgradeTimeoutInMinutesОпределяет совокупный интервал времени, в течение которого контроллер и база данных контроллера должны завершить обновление (обновление controller + controllerdb). Значение по умолчанию — 10. Используйте значение не ниже 40.

      componentUpgradeTimeoutInMinutes: указывает время завершения каждого последующего этапа обновления. Значение по умолчанию — 30. Замените на 45.

    3. Сохраните и закройте.

    Время ожидание также можно задать с помощью следующего скрипта Python:

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

Сбой отправки задания Livy из Azure Data Studio (ADS) или выполнения команды curl с ошибкой 500

  • Проблема и влияние на клиентов: в конфигурации высокой доступности общие ресурсы Spark sparkhead настраиваются с несколькими репликами. В этом случае могут возникать сбои при отправке задания Livy из Azure Data Studio (ADS) или curl. Для проверки выполните команду curl в отношении любых результатов sparkhead pod в отклоненном подключении. Так, curl https://sparkhead-0:8998/ или curl https://sparkhead-1:8998 возвращает ошибку 500.

    Это происходит в следующих случаях:

    • Группы pod Zookeeper или процессы для каждого экземпляра Zookeeper несколько раз перезапускаются.
    • Между pod sparkhead и группами pod Zookeeper нестабильное сетевое подключение.

  • Обходное решение. Перезапуск обоих серверов Livy.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

Создание таблицы, оптимизированной для памяти, когда главный экземпляр находится в группе доступности

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

  • Возможное решение. Чтобы создать таблицы, оптимизированные для памяти, когда главный экземпляр SQL Server используется в конфигурации с группой доступности, подключитесь к экземпляру SQL Server, предоставьте конечную точку, подключитесь к базе данных SQL Server и используйте сеанс, созданный в новом подключении, для создания нужных таблиц.

Укажите для внешних таблиц режим проверки подлинности с Active Directory

  • Проблема и влияние на клиентов: если основной экземпляр SQL Server находится в режиме проверки подлинности с Active Directory, запрос, который выбирает элемент исключительно из внешних таблиц, где хотя бы одна из внешних таблиц находится в пуле носителей, и вставляет режим проверки подлинности в другую внешнюю таблицу, возвращает следующее:

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

  • Обходное решение. Измените запрос одним из следующих способов. Присоедините таблицу пулов носителей к локальной таблице или сначала вставьте ее в локальную таблицу, а затем выполните чтение из локальной таблицы, чтобы вставить элемент в пул данных.

Функции прозрачного шифрования данных не могут использоваться с базами данных, которые являются частью группы доступности в главном экземпляре SQL Server

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

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

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

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