Partilhar via

Problemas conhecidos da plataforma dos Clusters de Big Data do SQL Server 2019

  • Artigo

Aplica-se a: SQL Server 2019 (15.x)

Importante

O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.

Problemas conhecidos

Cópia do HDFS de arquivos grandes usando azdata com falhas aleatórias

  • Versões afetadas: CU14

  • Problema e efeito no cliente: esse era um bug que causava falhas aleatórias em comandos azdata bdc cp entre os caminhos do HDFS. O bug afeta cópias de arquivos maiores com mais frequência.

  • Solução: atualizar para a CU15 (atualização cumulativa 15).

Segurança do log4j

  • Versões afetadas: nenhuma

  • Problema e efeito no cliente: após uma avaliação completa da base de código de Clusters de Big Data do SQL Server 2019, nenhum risco associado à vulnerabilidade de log4j relatada em dezembro foi identificado. A CU15 inclui uma versão atualizada do log4j (2.17) para a instância do ElasticSearch no plano de controle a fim de garantir que os alertas de verificação de imagem não sejam disparados pela análise de código estático dos contêineres do Cluster de Big Data.

  • Solução: mantenha o cluster de Big Data sempre atualizado com a versão mais recente.

Não há suporte para a atualização de cluster de uma versão CU8 e anterior para uma versão pós-CU9

  • Versões afetadas: versões CU8 e anteriores

  • Problema e impacto para o cliente: na atualização direta de um cluster com a versão CU8 ou anterior para qualquer versão acima da CU9, a atualização falha na fase de monitoramento.

  • Solução: atualize primeiro para a CU9. Em seguida, atualize da CU9 para a última versão.

Plataformas do Kubernetes com uma API do Kubernetes versão 1.21+

  • Versões afetadas: todas as versões

  • Problema e efeito no cliente: A API do Kubernetes 1.21 ou superior não é uma configuração testada dos Clusters de Big Data do SQL Server da CU12 em diante.

Pacotes do MicrosoftML nos Serviços de Machine Learning do SQL Server

  • Versões afetadas: CU10, CU11, CU12 e CU13

  • Problema e impacto para o cliente: alguns pacotes MicrosoftML R/Python nos Serviços de Machine Learning do SQL Server não estão funcionando. Isso afeta todas as instâncias mestras do SQL Server.

Falha ao conectar-se à instância remota do SQL Server 2016 ou mais antigo

  • Versões afetadas: CU10
  • Problema e impacto para o cliente: ao usar o PolyBase em Clusters de Big Data do SQL Server 2019 da CU10 para se conectar a uma instância do SQL Server que esteja usando um certificado para criptografia de canal criado com o algoritmo SHA1, o seguinte erro poderá ocorrer:

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 .

  • Solução: como o Ubuntu 20.04 tem requisitos de segurança mais rígidos do que a versão da imagem base anterior, não é permitida a conexão remota de um certificado que use o algoritmo SHA1. O certificado autoassinado padrão das versões 2005-2016 do SQL Server usava o algoritmo SHA1. Para obter mais informações sobre essa alteração, veja as alterações feitas em certificados autoassinados no SQL Server 2017. Na instância remota do SQL Server, use um certificado criado com um algoritmo que use pelo menos 112 bits de segurança (por exemplo, SHA256). Para ambientes de produção, recomendamos obter um certificado confiável de uma autoridade de certificação. Para fins de teste, o certificado autoassinado também pode ser usado. Para criar um certificado autoassinado, confira o cmdlet do PowerShell New-SelfSignedCertificate ou o comando certreq. Confira as instruções para instalação de um novo certificado na instância remota do SQL Server em Habilitar conexões criptografadas com o Mecanismo de Banco de Dados

Perda parcial de logs coletados no ElasticSearch após a reversão

  • Versões afetadas: afeta os clusters existentes quando uma atualização com falha para a CU9 resulta em uma reversão ou quando o usuário emite um downgrade para uma versão mais antiga.

  • Problema e impacto para o cliente: a versão do software usada para o ElasticSearch foi atualizada com a CU9, e a nova versão não é compatível com versões anteriores de metadados/formatos de log. Se o componente ElasticSearch for atualizado com sucesso, mas uma reversão posterior for disparada, os logs coletados entre a atualização do ElasticSearch e a reversão serão perdidos permanentemente. Se você emitir um downgrade para a versão mais antiga do Clusters de Big Data do SQL Server 2019 (não recomendado), os logs armazenados em Elasticsearch serão perdidos. Se você atualizar novamente para a CU9, os dados serão restaurados.

  • Solução alternativa: Se necessário, você poderá solucionar problemas usando os logs coletados com o comando azdata bdc debug copy-logs.

Métricas de pods e de contêiner ausentes

  • Versões afetadas: Clusters novos e existentes após a atualização para CU9

  • Problema e efeito no cliente: como resultado da atualização da versão do Telegraf usada para monitorar os componentes na CU9, ao atualizar o cluster para a versão CU9, você notará que as métricas de pods e contêineres não são coletadas. Isso ocorre porque um recurso adicional é necessário na definição da função de cluster usada para o Telegraf como um resultado da atualização de software. Se o usuário que está implantando o cluster ou executando a atualização não tiver permissões suficientes, a implantação/a atualização continuará com um aviso e terá sucesso, mas as métricas de nó e de pod não serão coletadas.

  • Solução alternativa: você pode pedir a um administrador para criar ou atualizar a função e a conta de serviço correspondente (antes ou depois da implantação/atualização) e o cluster de Big Data as usará. Este artigo descreve como criar os artefatos necessários.

A emissão de azdata bdc copy-logs não resulta na cópia dos logs

  • Versões afetadas: CLI de Dados do Azure (azdata) versão 20.0.0

  • Problema e impacto para o cliente: a implementação do comando copy-logs supõe que a ferramenta do cliente kubectl versão 1.15 ou superior esteja instalada no computador cliente do qual o comando é emitido. Se o kubectl versão 1.14 for usado, o comando azdata bdc debug copy-logs será concluído sem falhas, mas os logs não serão copiados. Durante a execução com o sinalizador --debug, você poderá ver este erro na saída: a origem '.' é inválida.

  • Solução alternativa: instale a ferramenta kubectl versão 1.15 ou superior no mesmo computador cliente e emita novamente o comando azdata bdc copy-logs. Confira aqui as instruções de como instalar o kubectl.

As funcionalidades do MSDTC não podem ser habilitadas para a instância mestra do SQL Server

  • Versões afetadas: todas as configurações de implantação de cluster de Big Data, independentemente da versão.

  • Problema e efeito no cliente: com o SQL Server implantado no cluster de big data como a instância mestra do SQL Server, o recurso MSDTC não pode ser habilitado. Não há nenhuma solução alternativa para esse problema.

Rotação do criptografador de chave de Criptografia de Banco de Dados SQL Server de HA

  • Versões afetadas: todas as versões até a CU8. Resolvido na CU9.

  • Problema e impacto para o cliente: com o SQL Server implantado com HA, a rotação do certificado falha para o banco de dados criptografado. Quando o seguinte comando é executado no pool mestre, uma mensagem de erro é exibida:

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

    Não há nenhum impacto, o comando falha e a criptografia do banco de dados de destino é preservada usando o certificado anterior.

Habilitar o suporte a zonas de criptografia HDFS na CU8

  • Versões afetadas: esse cenário ocorre ao atualizar especificamente da versão CU6 ou anterior para a versão CU8. Isso não acontecerá em novas implantações da versão CU8 ou posterior ou ao atualizar diretamente para a CU9. As versões CU10 ou superiores não são afetadas.

  • Problema e efeito no cliente: o suporte às zonas de criptografia HDFS não é habilitado por padrão neste cenário e precisa ser configurado por meio das etapas fornecidas no guia de configuração.

Esvaziar trabalhos do Livy antes de aplicar atualizações cumulativas

  • Versões afetadas: todas as versões até CU6. Resolvido para CU8.

  • Problema e impacto para o cliente: durante uma atualização, o sparkhead retorna o erro 404.

  • Solução alternativa: antes de atualizar o cluster de Big Data, verifique se não há sessões ativas do Livy ou trabalhos em lotes. Siga as instruções em Atualização de versão com suporte para evitar isso.

    Se o Livy retornar um erro 404 durante o processo de atualização, reinicie o servidor Livy em ambos os nós sparkhead. Por exemplo:

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

Expiração da senha para contas de serviço geradas pelo cluster de Big Data

  • Versões afetadas: Todas as implantações de cluster de Big Data com integração do Active Directory, independentemente da versão

  • Problema e impacto para o cliente: durante a implantação do cluster de Big Data, o fluxo de trabalho gera um conjunto de contas de serviço. Dependendo da política de expiração de senha definida no Controlador de Domínio, as senhas dessas contas podem expirar (o padrão é 42 dias). No momento, como não há um mecanismo para alternar as credenciais de todas as contas no cluster de big data, ele se torna inoperante quando o período de expiração é atingido.

  • Solução alternativa: atualize a política de expiração das contas de serviço em um cluster de Big Data para "A senha nunca expira" no controlador de domínio. Para ter uma lista completa dessas contas, confira Objetos do Active Directory gerados automaticamente. Essa ação pode ser realizada antes ou depois do tempo de término. No último caso, o Active Directory reativa as senhas expiradas.

Credenciais para acessar serviços por meio do ponto de extremidade do gateway

  • Versões afetadas: Novos clusters implantados, começando com a CU5.

  • Problema e efeito no cliente: para os novos clusters de big data implantados usando a CU5 dos Clusters de Big Data do SQL Server, o nome de usuário do gateway não é root. Se o aplicativo usado para conexão com o ponto de extremidade do gateway estiver usando as credenciais erradas, você verá um erro de autenticação. Essa alteração é um resultado da execução de aplicativos no cluster de Big Data como um usuário não raiz (um novo comportamento padrão que começa com a versão CU5 dos clusters de Big Data do SQL Server): quando você implanta um novo cluster de Big Data usando a CU5, o nome de usuário do ponto de extremidade do gateway é baseado no valor passado pela variável de ambiente AZDATA_USERNAME. É o mesmo nome de usuário usado para os pontos de extremidade do controlador e do SQL Server. Isso afeta apenas novas implantações. Os clusters de big data existentes implantados com qualquer uma das versões anteriores continuam a usar root. Não há nenhum impacto nas credenciais quando o cluster é implantado para usar a autenticação do Active Directory.

  • Solução alternativa: o Azure Data Studio lida com a alteração de credenciais de maneira transparente para a conexão feita com o gateway a fim de habilitar a experiência de navegação do HDFS no Pesquisador de Objetos. Você precisa instalar a versão mais recente do Azure Data Studio, que inclui as alterações necessárias que abordam esse caso de uso. Para outros cenários em que você precisa fornecer credenciais para acessar o serviço por meio do gateway (por exemplo, fazer logon com CLI de Dados do Azure (azdata) ou acessar painéis da Web para Spark), é preciso verificar se as credenciais corretas são usadas. Se o destino for um cluster existente implantado antes da CU5, você continuará usando o nome de usuário root para se conectar ao gateway, mesmo depois de atualizar o cluster para a CU5. Se você implantar um novo cluster usando o build da CU5, entre fornecendo o nome de usuário correspondente à variável de ambiente AZDATA_USERNAME.

Métricas de pods e de nós não sendo coletadas

  • Versões afetadas: clusters novos e existentes que estão usando imagens da CU5

  • Problema e efeito no cliente: como resultado de uma correção de segurança relacionada à API que telegraf estava usando para coletar as métricas do pod e hospedar as métricas do nó, os clientes podem perceber que as métricas não são coletadas. Isso é possível em implantações novas e existentes do Clusters de Big Data do SQL Server 2019 (após a atualização para a CU5). Como resultado da correção, o Telegraf agora requer uma conta de serviço com permissões de função para todo o cluster. A implantação tenta criar a conta de serviço necessária e a função de cluster. No entanto, se o usuário que está implantando o cluster ou realizando a atualização não tiver permissões suficientes, a implantação/atualização continuará com um aviso e será bem-sucedida, mas as métricas de pod e nó não serão coletadas.

  • Solução alternativa: é possível pode pedir a um administrador para criar a função e a conta de serviço (antes ou depois da implantação/atualização) e o cluster de Big Data as usará. Este artigo descreve como criar os artefatos necessários.

Falha no comando azdata bdc copy-logs

  • Versões afetadas: CLI de Dados do Azure (azdata) versão 20.0.0

  • Problema e impacto para o cliente: a implementação do comando copy-logs supõe que a ferramenta do cliente kubectl esteja instalada no computador cliente do qual o comando é emitido. Se você estiver emitindo o comando em um cluster de Big Data instalado no OpenShift por meio de um cliente no qual apenas a ferramenta oc estiver instalada, você receberá um erro: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Solução alternativa: instale a ferramenta kubectl no mesmo computador cliente e emita novamente o comando azdata bdc copy-logs. Confira aqui as instruções de como instalar o kubectl.

Implantação com repositório privado

  • Versões afetadas: GDR1, CU1, CU2. Resolvido para CU3.

  • Problema e impacto para o cliente: a atualização por meio do repositório privado tem requisitos específicos

  • Solução alternativa: se você usar um repositório privado para extrair previamente as imagens para implantação ou atualização do cluster de big data, verifique se as imagens de compilação atuais e as imagens de compilação de destino estão no repositório privado. Isso permitirá a reversão bem-sucedida, caso ela seja necessária. Além disso, se você tiver alterado as credenciais do repositório privado depois da implantação original, atualize o segredo correspondente no Kubernetes antes de atualizar. A CLI de dados do Azure (azdata) não dá suporte à atualização das credenciais por meio das variáveis de ambiente AZDATA_PASSWORD e AZDATA_USERNAME. Atualize o segredo usando kubectl edit secrets.

Não há suporte para a atualização usando repositórios diferentes para compilações atuais e de destino.

A atualização pode falhar devido ao tempo limite

  • Versões afetadas: GDR1, CU1, CU2. Resolvido para CU 3.

  • Problema e impacto para o cliente: uma atualização pode falhar devido ao tempo limite.

    O seguinte exemplo de código mostra como poderia ser a falha:

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

    É mais provável que esse erro aconteça quando você atualiza o Clusters de Big Data do SQL Server 2019 no AKS (Serviço de Kubernetes do Azure).

  • Solução alternativa: Aumente o tempo limite para a atualização.

    Para aumentar os tempos limite de uma atualização, edite o mapa de configuração da atualização. Para editar o mapa de configuração da atualização:

    1. Execute o comando a seguir:

      kubectl edit configmap controller-upgrade-configmap

    2. Edite os seguintes campos:

      O controllerUpgradeTimeoutInMinutes designa o número de minutos que deverão ser aguardados para que o controlador ou o banco de dados do controlador conclua a atualização. O padrão é 5. Atualize para pelo menos 20.

      totalUpgradeTimeoutInMinutes: designa a quantidade combinada de tempo em que o controlador e o banco de dados do controlador concluem a atualização (atualização do controller + controllerdb). O padrão é 10. Atualize para pelo menos 40.

      componentUpgradeTimeoutInMinutes : designa a quantidade de tempo em que cada fase subsequente da atualização precisa ser concluída. O padrão é 30. Atualize para 45.

    3. Salve e saia.

    O seguinte script Python é outra maneira de definir o tempo limite:

    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)

O envio de trabalho do Livy do ADS (Azure Data Studio) ou da ondulação falha com o erro 500

  • Problema e impacto para o cliente: em uma configuração de HA, os recursos compartilhados sparkhead do Spark são configurados com várias réplicas. Nesse caso, você pode encontrar falhas com o envio de trabalho do Livy do ADS (Azure Data Studio) ou curl. Para verificar, curl para qualquer pod do sparkhead resulta em uma conexão recusada. Por exemplo, curl https://sparkhead-0:8998/ ou curl https://sparkhead-1:8998 retorna um erro 500.

    Isso acontece dos seguintes cenários:

    • Os pods ou processos de cada instância do ZooKeeper, são reiniciados algumas vezes.
    • Quando a conectividade de rede não é confiável entre o pod do sparkhead e os pods do ZooKeeper.

  • Solução alternativa: Reiniciar ambos os servidores 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

Criar uma tabela com otimização de memória quando a instância mestra está em um grupo de disponibilidade

  • Problema e efeito no cliente: não é possível usar o ponto de extremidade primário exposto para conectar-se a bancos de dados de grupo de disponibilidade (ouvinte) a fim de criar tabelas com otimização de memória.

  • Solução alternativa: para criar tabelas com otimização de memória quando a instância mestra do SQL Server for uma configuração de grupo de disponibilidade, conecte-se à instância do SQL Server, exponha um ponto de extremidade, conecte-se ao banco de dados do SQL Server e crie as tabelas com otimização de memória na sessão criada com a nova conexão.

Inserir no modo de autenticação do Active Directory de tabelas externas

  • Problema e impacto para o cliente: quando a instância mestra do SQL Server está no modo de autenticação do Active Directory, uma consulta que seleciona apenas de tabelas externas, em que pelo menos uma das tabelas externas está em um pool de armazenamento e insere em outra tabela externa, a consulta retorna:

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.

  • Solução alternativa: Modifique a consulta de uma das maneiras a seguir. Ingresse a tabela do pool de armazenamento em uma tabela local ou insira-a primeiro na tabela local e depois leia da tabela local para inseri-la no pool de dados.

As funcionalidades de Transparent Data Encryption não podem ser usadas com bancos de dados que fazem parte do grupo de disponibilidade na instância mestra do SQL Server

  • Problema e efeito para o cliente: em uma configuração de HA, os bancos de dados com criptografia habilitada não podem ser usados após um failover, pois a chave mestra usada para criptografia é diferente em cada réplica.

  • Solução alternativa: não há nenhuma solução alternativa para esse problema. É recomendável não habilitar a criptografia nessa configuração até que uma correção esteja em vigor.

Conteúdo relacionado

Para obter mais informações sobre Clusters de Big Data do SQL Server 2019, confira Apresentamos os Clusters de Big Data do SQL Server.