Comparteix a través de

Problemas conocidos de la plataforma Clústeres de macrodatos de SQL Server 2019

  • Article

Se aplica a: SQL Server 2019 (15.x)

Importante

El complemento Clústeres de macrodatos de Microsoft SQL Server 2019 se va a retirar. La compatibilidad con Clústeres de macrodatos de SQL Server 2019 finalizará el 28 de febrero de 2025. Todos los usuarios existentes de SQL Server 2019 con Software Assurance serán totalmente compatibles con la plataforma, y el software se seguirá conservando a través de actualizaciones acumulativas de SQL Server hasta ese momento. Para más información, consulte la entrada de blog sobre el anuncio y Opciones de macrodatos en la plataforma Microsoft SQL Server.

Problemas conocidos

Copia de HDFS de archivos grandes mediante azdata con errores aleatorios

  • Versiones afectadas: CU14

  • Problema y efecto del cliente: se trata de un error que provocaba errores aleatorios en los comandos azdata bdc cp entre las rutas de acceso de HDFS. El error afecta a las copias de archivos más grandes con más frecuencia.

  • Solución: Actualización a la actualización acumulativa 15 (CU15).

Seguridad de Log4j

  • Versiones afectadas: ninguna

  • Problema y efecto del cliente: después de una evaluación exhaustiva del código base de clústeres de macrodatos de SQL Server 2019, no se ha identificado ningún riesgo asociado a la vulnerabilidad log4j notificada en diciembre. CU15 incluye una versión actualizada de log4j (2.17) para la instancia de ElasticSearch en el plano de control a fin de asegurarse de que el análisis de código estático de contenedores de clústeres de macrodatos no desencadena alertas de análisis de imágenes.

  • Solución: mantenga siempre actualizado el clúster de macrodatos a la versión más reciente.

No se admite la actualización del clúster desde una versión CU8 y versiones anteriores a una versión posterior a CU9

  • Versiones afectadas: versiones CU8 y anteriores

  • Problema y efecto para el cliente: al actualizar directamente un clúster en la versión CU8 o anterior a cualquier versión anterior a CU9, se produce un error en la actualización de la fase de supervisión.

  • Solución: actualice primero a CU9. Después, actualice de CU9 a la versión más reciente.

Plataformas de Kubernetes con la API de Kubernetes versión 1.21 y posteriores

  • Versiones afectadas: todas las versiones

  • Problema y efecto para el cliente: Kubernetes API 1.21 o superior no es una configuración probada de Clústeres de macrodatos de SQL Server a partir de la CU12.

Paquetes de MicrosoftML en SQL Server Machine Learning Services

  • Versiones afectadas: CU10, CU11, CU12 y CU13

  • Problema y efecto para el cliente: algunos paquetes de R/Python de MicrosoftML en SQL Server Machine Learning Services no funcionan. Esto afecta a todas las instancias maestras de SQL Server.

No se pudo conectar a la instancia remota de SQL Server 2016 o anterior

  • Versiones afectadas: CU10
  • Problema y efecto para el cliente: al usar PolyBase en Clústeres de macrodatos de SQL Server 2019 CU10 a fin de conectarse a una instancia de SQL Server existente que usa un certificado para el cifrado de canal que se ha creado mediante el algoritmo SHA1, podría observar el error siguiente:

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 .

  • Solución: debido a los requisitos de seguridad mejorados de Ubuntu 20.04 relativos a la versión anterior de la imagen base, no se permite la conexión remota para un certificado que use el algoritmo SHA1. El certificado autofirmado predeterminado de las versiones de SQL Server 2005 a 2016 usaba el algoritmo SHA1. Para obtener más información sobre este cambio, consulte cambios realizados en los certificados autofirmados en SQL Server 2017. En la instancia de SQL Server remota, use un certificado creado con un algoritmo que use al menos 112 bits de seguridad; por ejemplo, SHA256. En los entornos de producción, se recomienda obtener un certificado de confianza emitido por una entidad de certificación. Con fines de prueba, también se puede usar un certificado autofirmado. Para crear un certificado autofirmado, consulte el cmdlet de PowerShell New-SelfSignedCertificate o el comando certreq. Para obtener instrucciones sobre cómo instalar un nuevo certificado en la instancia de SQL Server remota, consulte Habilitación de conexiones cifradas al Motor de base de datos.

Pérdida parcial de registros recopilados en ElasticSearch tras la reversión

  • Versiones afectadas: clústeres existentes cuando una actualización a CU9 con error provoca una reversión, o bien el usuario emite una degradación a una versión anterior.

  • Problema y efecto para el cliente: la versión de software que se usa para la búsqueda elástica se ha actualizado con CU9 y la nueva versión no es compatible con versiones anteriores con los metadatos ni el formato de los registros anteriores. Si el componente ElasticSearch se actualiza correctamente, pero se desencadena una reversión posterior, los registros recopilados entre la actualización de ElasticSearch y la reversión se pierden de forma permanente. Si emite un cambio a una versión anterior de Clústeres de macrodatos de SQL Server 2019 (algo que no se recomienda), se perderán los registros almacenados en Elasticsearch. Si vuelve a actualizar a CU9, los datos se restauran.

  • Solución alternativa: si es necesario, puede solucionar el problema mediante registros recopilados con el comando azdata bdc debug copy-logs.

Pods y métricas de contenedor no disponibles

  • Versiones afectadas: clústeres nuevos y existentes tras la actualización a CU9

  • Problema y efecto para el cliente: como resultado de la actualización de la versión de Telegraf que se usa para los componentes de supervisión en la CU9, al actualizar el clúster a la versión CU9, observará que no se recopilan los pods ni las métricas de contenedor. Esto se debe a que se necesita un recurso adicional en la definición del rol de clúster que se usa para Telegraf como resultado de la actualización de software. Si el usuario que implementa el clúster o realiza la actualización no tiene permisos suficientes, la implementación o la actualización continúa con una advertencia y se realiza correctamente, pero no se recopilarán las métricas de nodos ni los pods.

  • Solución alternativa: puede pedir a un administrador que cree o actualice el rol y la cuenta de servicio correspondiente (antes o después de la implementación o actualización), para que se usen en el clúster de macrodatos. En este artículo se describe cómo crear los artefactos necesarios.

Registros no copiados tras la emisión de azdata bdc copy-logs

  • Versiones afectadas: CLI de datos de Azure (azdata) versión 20.0.0

  • Problema y efecto para el cliente: la implementación del comando copy-logs asume que la versión 1.15 o posterior de la herramienta cliente kubectl está instalada en el equipo cliente desde el que se emite el comando. Si se usa la versión 1.14 de kubectl, el comando azdata bdc debug copy-logs se completa sin errores, pero no se copian los registros. Cuando se ejecuta con la marca --debug, puede ver este error en la salida: el origen "." no es válido.

  • Solución alternativa: instale la versión 1.15 o posterior de la herramienta kubectl en el mismo equipo cliente y vuelva a emitir el comando azdata bdc copy-logs. Vea estas instrucciones sobre cómo instalar kubectl.

Imposibilidad de habilitar las funcionalidades de MSDTC para la instancia maestra de SQL Server

  • Versiones afectadas: todas las configuraciones de implementación de clúster de macrodatos, independientemente de la versión.

  • Problema y efecto para el cliente: con SQL Server implementado en el clúster de macrodatos como instancia maestra de SQL Server, no se puede habilitar la característica MSDTC. No hay ninguna solución alternativa para este problema.

Rotación del tipo de sistema de cifrado de claves de las claves de cifrado de bases de datos SQL Server de alta disponibilidad

  • Versiones afectadas: todas las versiones hasta CU8. Resuelto para CU9.

  • Problema y efecto para el cliente: con SQL Server implementado con alta disponibilidad, se produce un error en la rotación de certificados para la base de datos cifrada. Cuando se ejecuta el comando siguiente en el grupo maestro, aparece un mensaje de error:

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

    No hay ningún efecto, se produce un error en el comando y el cifrado de la base de datos de destino se conserva con el certificado anterior.

Habilitación de la compatibilidad con las zonas de cifrado de HDFS en CU8

  • Versiones afectadas: este escenario se muestra al realizar la actualización específicamente a la versión CU8 desde CU6 o una versión anterior. Esto no sucederá en las nuevas implementaciones de CU8 y versiones posteriores o al hacerlo directamente a CU9. No se ve afectada la CU10 o versiones superiores.

  • Problema y efecto para el cliente: la compatibilidad con las zonas de cifrado de HDFS no está habilitada de manera predeterminada en este escenario y se debe configurar mediante los pasos proporcionados en la guía de configuración.

Trabajos de Livy vacíos antes de aplicar las actualizaciones acumulativas

  • Versiones afectadas: todas las versiones hasta CU6. Resuelto para CU8.

  • Problema y efecto para el cliente: durante una actualización, sparkhead devuelve el error 404.

  • Solución alternativa: antes de actualizar el clúster de macrodatos, asegúrese de que no haya trabajos por lotes ni sesiones de Livy activos. Siga las instrucciones de Actualización desde una versión compatible para evitar esto.

    Si Livy devuelve un error 404 durante el proceso de actualización, reinicie el servidor Livy en ambos nodos sparkhead. Por ejemplo:

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

Expiración de contraseñas de cuentas de servicio generadas por el clúster de macrodatos

  • Versiones afectadas: todas las implementaciones de clústeres de macrodatos con la integración de Active Directory, independientemente de la versión.

  • Problema y efecto para el cliente: durante la implementación del clúster de macrodatos, el flujo de trabajo genera un conjunto de cuentas de servicio. En función de la directiva de expiración de contraseñas establecida en el controlador de dominio, las contraseñas de estas cuentas pueden expirar (el valor predeterminado es de 42 días). En este momento, no hay ningún mecanismo para girar las credenciales de todas las cuentas del clúster de macrodatos, por lo que el clúster deja de funcionar cuando se cumple el período de expiración.

  • Solución alternativa: actualice la directiva de expiración de las cuentas del servicio en un clúster de macrodatos a "La contraseña nunca expira" en el controlador de dominio. Para ver una lista completa de estas cuentas, consulte Objetos de Active Directory generados automáticamente. Esta acción se puede realizar antes o después de la fecha de expiración. En el último caso, Active Directory reactiva las contraseñas expiradas.

Credenciales para acceder a los servicios a través del punto de conexión de puerta de enlace

  • Versiones afectadas: clústeres nuevos implementados a partir de CU5.

  • Problema y efecto para el cliente: para los nuevos clústeres de macrodatos implementados mediante Clústeres de macrodatos de SQL Server CU5, el nombre de usuario de puerta de enlace no es root. Si la aplicación que se usa para conectarse al punto de conexión de puerta de enlace usa las credenciales incorrectas, verá un error de autenticación. Este cambio es el resultado de la ejecución de aplicaciones en el clúster de macrodatos como un usuario distinto de root (un nuevo comportamiento predeterminado a partir de la versión Clústeres de macrodatos de SQL Server CU5; cuando se implementa un nuevo clúster de macrodatos con CU5, el nombre de usuario del punto de conexión de puerta de enlace se basa en el valor que se pasa mediante la variable de entorno AZDATA_USERNAME). Es el mismo nombre de usuario que se usa para los puntos de conexión del controlador y SQL Server. Esto solo afecta a las nuevas implementaciones. En los clústeres de macrodatos existentes implementados con cualquiera de las versiones anteriores se sigue usando root. No se produce ningún efecto en las credenciales cuando el clúster se implementa para usar la autenticación de Active Directory.

  • Solución alternativa: Azure Data Studio controla de forma transparente el cambio de credenciales para la conexión realizada a la puerta de enlace a fin de habilitar la experiencia de exploración de HDFS en el Explorador de objetos. Debe instalar la versión más reciente Azure Data Studio que incluya los cambios necesarios que solucionan este caso de uso. Para otros escenarios en los que debe proporcionar credenciales para acceder al servicio a través de la puerta de enlace (por ejemplo, el inicio de sesión con CLI de datos de Azure (azdata) o el acceso a los paneles web de Spark), tendrá que asegurarse de que se usen las credenciales correctas. Si el destino es un clúster existente implementado antes de la CU5, seguirá usando el nombre de usuario root para conectarse a la puerta de enlace, incluso después de actualizar el clúster a CU5. Si implementa un nuevo clúster mediante la compilación CU5, inicie sesión con el nombre de usuario correspondiente a la variable de entorno AZDATA_USERNAME.

Métricas de pods y nodos no recopiladas

  • Versiones afectadas: clústeres nuevos y existentes en los que se usan imágenes de CU5

  • Problema y efecto para el cliente: como resultado de una corrección de seguridad relacionada con la API que usaba telegraf para recopilar métricas de pods y nodo de host, es posible que los clientes vean que no se recopilan métricas. Esto es posible en implementaciones nuevas y existentes de Clústeres de macrodatos de SQL Server 2019 (después de la actualización a CU5). Como resultado de la corrección, ahora en Telegraf se necesita una cuenta de servicio con permisos de rol en la totalidad del clúster. La implementación intenta crear la cuenta de servicio y el rol de clúster necesarios, pero si el usuario que implementa el clúster o realiza la actualización no tiene permisos suficientes, la implementación o la actualización continúa con una advertencia y se realiza correctamente, pero no se recopilarán las métricas de nodos y pods.

  • Solución alternativa: puede pedir a un administrador que cree el rol y la cuenta de servicio (antes o después de la implementación o actualización), para que se usen en el clúster de macrodatos. En este artículo se describe cómo crear los artefactos necesarios.

Error del comando azdata bdc copy-logs

  • Versiones afectadas: CLI de datos de Azure (azdata) versión 20.0.0

  • Problema y efecto para el cliente: la implementación del comando copy-logs asume que la herramienta cliente kubectl está instalada en el equipo cliente desde el que se emite el comando. Si emite el comando en un clúster de macrodatos instalado en OpenShift, desde un cliente donde solo está instalada la herramienta oc, obtendrá un error: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Solución alternativa: instale la herramienta kubectl en el mismo equipo cliente y vuelva a emitir el comando azdata bdc copy-logs. Vea estas instrucciones sobre cómo instalar kubectl.

Implementación con repositorio privado

  • Versiones afectadas: GDR1, CU1, CU2. Resuelto para CU3.

  • Problema y efecto para el cliente: la actualización del repositorio privado tiene requisitos específicos.

  • Solución alternativa: si usa un repositorio privado para la extracción previa de las imágenes a fin de implementar o actualizar el clúster de macrodatos, asegúrese de que las imágenes de compilación actuales, y las de compilación de destino, se encuentran en el repositorio privado. Esto permite una reversión correcta, si es necesario. Además, si cambió las credenciales del repositorio privado desde la implementación original, actualice el secreto correspondiente en Kubernetes antes de la actualización. La CLI de datos de Azure (azdata) no admite la actualización de las credenciales mediante las variables de entorno AZDATA_PASSWORD y AZDATA_USERNAME. Actualice el secreto mediante kubectl edit secrets.

No se admite la actualización con otros repositorios privados para compilaciones actuales y de destino.

Puede generarse un error de actualización debido a un tiempo de espera

  • Versiones afectadas: GDR1, CU1, CU2. Resuelto para CU3.

  • Problema y efecto para el cliente: puede generarse un error de actualización debido a un tiempo de espera.

    En el código siguiente se muestra el aspecto del error:

    > 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.

    Es más probable que este error se produzca al actualizar Clústeres de macrodatos de SQL Server 2019 en Azure Kubernetes Service (AKS).

  • Solución alternativa: aumente el tiempo de espera de la actualización.

    Para aumentar los tiempos de espera de una actualización, edite la asignación de configuración de la actualización. Para editar la asignación de configuración de la actualización:

    1. Ejecute el siguiente comando:

      kubectl edit configmap controller-upgrade-configmap

    2. Edite estos campos:

      controllerUpgradeTimeoutInMinutes designa el número de minutos que se esperará a que finalice la actualización del controlador o de la base de datos del controlador. El valor predeterminado es 5. Actualice al menos a 20.

      totalUpgradeTimeoutInMinutes: designa la cantidad de tiempo para que el controlador y la base de datos del controlador terminen de actualizarse (actualización controller + controllerdb). El valor predeterminado es 10. Actualice al menos a 40.

      componentUpgradeTimeoutInMinutes : designa la cantidad de tiempo en que se debe completar cada fase posterior de la actualización. El valor predeterminado es 30. Actualice a 45.

    3. Guarde y salga.

    El script de Python siguiente es otra manera de establecer el tiempo de espera:

    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)

Error 500 al enviar el trabajo de Livy desde Azure Data Studio (ADS) o curl

  • Problema y efecto para el cliente: en una configuración de alta disponibilidad, los recursos compartidos de Spark sparkhead se configuran con varias réplicas. En este caso, es posible que experimente errores con el envío del trabajo de Livy desde Azure Data Studio (ADS) o curl. Para comprobarlo, la ejecución de curl en cualquier pod de sparkhead da como resultado una conexión rechazada. Por ejemplo, curl https://sparkhead-0:8998/ o curl https://sparkhead-1:8998 devuelve el error 500.

    Esto sucede en los escenarios siguientes:

    • Los pods de Zookeeper o los procesos de cada instancia de Zookeeper se reinician varias veces.
    • Cuando la conectividad de red no es confiable entre el pod de sparkhead y los pods de Zookeeper.

  • Solución alternativa: reinicie los dos servidores de 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

Creación de una tabla optimizada para memoria cuando la instancia maestra está en un grupo de disponibilidad

  • Problema y efecto para el cliente: no se puede usar el punto de conexión principal expuesto para conectarse a las bases de datos del grupo de disponibilidad (cliente de escucha) a fin de crear tablas optimizadas para memoria.

  • Solución alternativa: para crear tablas optimizadas para memoria cuando la instancia maestra de SQL Server es una configuración de grupo de disponibilidad, conéctese a la instancia de SQL Server, exponga un punto de conexión, conéctese a la base de datos SQL Server y cree las tablas optimizadas para memoria en la sesión creada con la nueva conexión.

Inserción en el modo de autenticación de Active Directory en tablas externas

  • Problema y efecto para el cliente: cuando la instancia maestra de SQL Server está en el modo de autenticación Active Directory, una consulta que selecciona solo en tablas externas, donde al menos una está en un grupo de almacenamiento, e inserta en otra tabla externa, devuelve lo siguiente:

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.

  • Solución alternativa: modifique la consulta de una de las maneras siguientes. Puede unir la tabla de bloque de almacenamiento a una tabla local, o bien insertar primero en la tabla local y después leer desde la tabla local para insertar en el grupo de datos.

Las funcionalidades de Cifrado de datos transparente no se pueden usar con las bases de datos que forman parte del grupo de disponibilidad en la instancia maestra de SQL Server

  • Problema y efecto para el cliente: en una configuración de alta disponibilidad, las bases de datos que tienen habilitado el cifrado no se pueden usar después de una conmutación por error, ya que la clave maestra usada para el cifrado es distinta en cada réplica.

  • Solución alternativa: no hay ninguna solución alternativa para este problema. Se recomienda no habilitar el cifrado en esta configuración hasta que se realice una corrección.

Contenido relacionado

Para obtener más información sobre Clústeres de macrodatos de SQL Server 2019, vea Presentación de Clústeres de macrodatos de SQL Server.