Notas de la versión de la plataforma Clústeres de macrodatos de SQL Server 2019

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 14 de enero 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.

Las notas de la versión siguientes se aplican a Clústeres de macrodatos de SQL Server 2019. Este artículo se divide en secciones para cada versión en la que se describen los cambios de CU. En el artículo también se enumeran los problemas conocidos para las versiones más recientes de Clústeres de macrodatos de SQL Server 2019.

Configuraciones probadas

Clústeres de macrodatos de SQL Server 2019 es una solución totalmente en contenedores orquestada por Kubernetes. A partir de SQL Server 2019 (15.x) CU12, cada versión de Clústeres de macrodatos de SQL Server se prueba con una configuración fija de componentes. La configuración se evalúa con cada versión y se realizan ajustes para mantenerse en línea con el ecosistema a medida que Kubernetes sigue evolucionando.

Importante

Kubernetes es un ecosistema de ritmo rápido. Es fundamental mantener actualizada la plataforma para que sea segura y tener una configuración probada para Clústeres de macrodatos de SQL Server.

Advertencia

En la actualización acumulativa 15 de  SQL Server 2019 (15.x), el orden de actualización es crucial. Actualice el clúster de macrodatos a la CU15 antes de actualizar el clúster de Kubernetes a la versión 1.21. Si el clúster de Kubernetes se actualiza a la versión 1.21 antes de que BDC se actualice a CU14 o CU15, el clúster terminará en estado de error y la actualización del BDC no se realizará correctamente. En este caso, tendrá que revertir la versión de Kubernetes a la 1.20 para corregir el problema.

La tabla siguiente contiene la matriz de configuraciones probadas para cada versión de Clústeres de macrodatos de SQL Server 2019:

Release SO de contenedor API de Kubernetes Tiempo de ejecución Almacenamiento de datos Almacenamiento de registros
CU18 Ubuntu 20.04 LTS 1.23.1 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU17 Ubuntu 20.04 LTS 1.23.1 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU16 GDR Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU16 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU15 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU14 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
Solo bloque Solo bloque
CU13 Ubuntu 20.04 LTS 1.20 containerd 1.4.6
CRI-O 1.20.0
Solo bloque Solo bloque
CU12 Ubuntu 20.04 LTS 1.20 containerd 1.4.3
Docker 20.10.2
CRI-O 1.20.0
Solo bloque Solo bloque

Restricciones:

  • Clústeres de macrodatos de SQL Server 2019 se admite como carga de trabajo. Microsoft solo proporciona compatibilidad con los componentes de software en los contenedores instalados y configurados por Clústeres de macrodatos de SQL Server 2019. El equipo de soporte técnico no admite el propio Kubernetes y otros contenedores que pueden influir en el comportamiento de Clústeres de macrodatos de SQL Server 2019. Para obtener soporte técnico de Kubernetes, póngase en contacto con el proveedor de la distribución de Kubernetes certificado.
  • Clústeres de macrodatos de SQL Server 2019 necesita almacenamiento en bloques para todos los volúmenes persistentes. La operación de administración sobre los volúmenes persistentes creados y usados por un clúster de macrodatos es una funcionalidad que depende del proveedor de almacenamiento, como las operaciones para expandir volúmenes persistentes (PVS). Consulte la documentación específica del proveedor de almacenamiento de CSI o las arquitectura de referencia de los asociados y notas del producto.
  • Los componentes de código abierto incluidos por Clústeres de macrodatos de SQL Server 2019 son fijos para esa versión concreta y no se deben actualizar ni modificar.
  • Las imágenes de contenedor se proporcionan "tal cual". No se admiten las características de composición de Kubernetes. No se admite el cambio del conjunto de imágenes de una versión de Clústeres de macrodatos de SQL Server 2019 ni personalizar los contenedores.

La arquitectura de referencia y las notas del producto para Clústeres de macrodatos de SQL Server se pueden encontrar en las páginas siguientes:

Historial de versiones

En la tabla siguiente, se muestra la lista del historial de versiones de Clústeres de macrodatos de SQL Server 2019. Para más información, vea Historial de actualizaciones acumulativas de los clústeres de macrodatos SQL Server 2019.

Versión 1 Versión de Clústeres de macrodatos de SQL Server 2019 CLI de datos de Azure (azdata) versión 2 Fecha de la versión
CU18 15.0.4261.1 20.3.12 28 de septiembre de 2022
CU17 15.0.4249.2 20.3.12 11 de agosto de 2022
CU16 GDR KB 5014356 15.0.4236.7 20.3.12 14 de junio de 2022
CU16 15.0.4223.1 20.3.11 2 de mayo de 2022
CU15 15.0.4198.2 20.3.10 27 de enero de 2022
CU14 15.0.4188.2 20.3.9 22 de nov. de 2021
CU13 15.0.4178.15 20.3.8 9 de sep. de 2021
CU12 15.0.4153.13 20.3.7 4 de ago. de 2021
CU11 15.0.4138.2 20.3.5 10 de jun. de 2021
CU10 15.0.4123.1 20.3.2 6 de abr. de 2021
CU9 15.0.4102.2 20.3.0 11 de feb. de 2021
CU8-GDR 15.0.4083.2 20.2.6 12 de ene. de 2021
CU8 15.0.4073.23 20.2.2 19 de oct. 2020
CU6 15.0.4053.23 20.0.1 4 de ago. de 2020
CU5 15.0.4043.16 20.0.0 22 de jun. de 2020
CU4 15.0.4033.1 15.0.4033 31 de mar. de 2020
CU3 15.0.4023.6 15.0.4023 12 de mar. de 2020
CU2 15.0.4013.40 15.0.4013 13 de feb. de 2020
CU1 15.0.4003.23 15.0.4003 7 de ene. de 2020
GDR1 15.0.2070.34 15.0.2070 4 de nov. de 2019

1 CU7 no está disponible para Clústeres de macrodatos de SQL Server 2019.

La versión 2 de CLI de datos de Azure (azdata) refleja la versión de la herramienta en el momento de la versión de CU. La versión de azdata también puede ser independientemente de la versión del servidor, por lo que podría obtener versiones más recientes al instalar los paquetes más recientes. Las versiones más recientes son compatibles con las versiones anteriores de CU.

Instalación de las actualizaciones

Para instalar las actualizaciones, consulte Cómo actualizar Clústeres de macrodatos de 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 para asegurarse de que el análisis de código estático de contenedores de clústeres de macrodatos no desencadena las 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, puede 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 la CU9, y la nueva versión no es compatible con versiones anteriores con los metadatos y 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 perderán 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 restaurarán.

  • 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 completará sin errores, pero no se copiarán 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 ejecute el comando siguiente en el grupo maestro, aparecerá 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 ven afectados 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 debe configurarse 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 rotar las credenciales de todas las cuentas del clúster de macrodatos, por lo que el clúster dejará de funcionar cuando se cumpla 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 reactivará 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 (raíz). 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 implementaciones nuevas; en los clústeres de macrodatos existentes implementados con cualquiera de las versiones anteriores se seguirá 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 controlará 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 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 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 extraer previamente las imágenes para implementar o actualizar el clúster de macrodatos, asegúrese de que las imágenes de compilación actuales, así como las imágenes 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. CLI de datos de Azure (azdata) no admite la actualización de las credenciales a través de las variables de entorno AZDATA_PASSWORD y AZDATA_USERNAME. Actualice el secreto mediante kubectl edit secrets.

No se admite la actualización mediante distintos 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 (agente 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.

Pasos siguientes

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.