Problemi noti della piattaforma dei cluster Big Data di SQL Server 2019

  • Articolo

Si applica a: SQL Server 2019 (15.x)

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Problemi noti

Copia HDFS di file di grandi dimensioni con azdata con errori casuali

  • Versioni interessate: CU14

  • Problema ed effetto sul cliente: si tratta di un bug che causa errori casuali sui comandi azdata bdc cp tra i percorsi HDFS. Il bug influisce sulle copie di file più grandi più spesso.

  • Soluzione: aggiornamento all'aggiornamento cumulativo 15 (CU15).

Sicurezza log4j

  • Versioni interessate: nessuna

  • Problema e effetto sul cliente: dopo una valutazione approfondita del codebase del cluster Big Data di SQL Server 2019, non è stato identificato alcun rischio associato alla vulnerabilità log4j segnalata a dicembre. CU15 include una versione aggiornata di log4j (2.17) per l'istanza di ElasticSearch nel piano di controllo per garantire che gli avvisi di analisi delle immagini non vengano attivati dall'analisi statica del codice dei contenitori del cluster Big Data.

  • Soluzione: mantenere sempre aggiornato il cluster Big Data all'ultima versione.

L'aggiornamento del cluster da una versione CU8 e precedente a una versione post-CU9 non è supportata

  • Versioni interessate: versioni CU8 e versioni precedenti

  • Problema ed effetto sul cliente: quando si esegue direttamente l'aggiornamento di un cluster nella versione CU8 o precedente a qualsiasi versione precedente a CU9, l'aggiornamento genera un errore dalla fase di monitoraggio.

  • Soluzione: eseguire prima l'aggiornamento a CU9. Eseguire quindi l'aggiornamento da CU9 alla versione più recente.

Piattaforme Kubernetes con API Kubernetes versione 1.21+

  • Versioni interessate: tutte le versioni

  • Problema ed effetto sul cliente: l'API Kubernetes 1.21 o superiore non è una configurazione testata dei cluster Big Data di SQL Server a partire da CU12.

I pacchetti MicrosoftML in Machine Learning Services per SQL Server

  • Versioni interessate: CU10, CU11, CU12 e CU13

  • Problema ed effetto sul cliente: alcuni pacchetti MicrosoftML R/Python in SQL Server Machine Learning Services non funzionano. Influisce su tutte le istanze master di SQL Server.

Impossibile connettersi all'istanza remota di SQL Server 2016 o versione precedente

  • Versioni interessate: CU10
  • Problema ed effetto sul cliente: quando si usa PolyBase nei cluster Big Data di SQL Server 2019 CU10 per connettersi a un'istanza di SQL Server esistente che usa un certificato per la crittografia del canale creata usando l'algoritmo SHA1, è possibile che venga osservato l'errore seguente:

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 .

  • Soluzione: a causa degli elevati requisiti di sicurezza di Ubuntu 20.04 rispetto alla versione precedente dell'immagine di base, non è consentita la connessione remota per un certificato usando l'algoritmo SHA1. Il certificato autofirmato predefinito delle versioni di SQL Server 2005-2016 ha usato l'algoritmo SHA1. Per altre informazioni su questa modifica, vedere le modifiche apportate ai certificati autofirmati in SQL Server 2017. Nell'istanza di SQL Server remota usare un certificato creato con un algoritmo che usa almeno 112 bit di sicurezza, ad esempio SHA256. Per gli ambienti di produzione, è consigliabile usare un certificato attendibile emesso da un'autorità di certificazione. A scopo di test, è anche possibile usare i certificati autofirmati. Per creare un certificato autofirmato, vedere il cmdlet di PowerShell New-SelfSignedCertificate o il comando certreq. Per istruzioni su come installare un nuovo certificato nell'istanza di SQL Server remota, vedere Abilitare le connessioni crittografate nel motore di database

Perdita parziale dei log raccolti in ElasticSearch al ripristino dello stato precedente

  • Versioni interessate: influisce sui cluster esistenti, quando un aggiornamento a CU9 non è riuscito genera un ripristino dello stato precedente o un utente genera un downgrade a una versione precedente.

  • Problema ed effetto sul cliente: la versione software usata per Elastic Search è stata aggiornata con CU9 e la nuova versione non è compatibile con il formato/metadati dei log precedenti. Se il componente ElasticSearch viene aggiornato correttamente, ma viene attivato un ripristino dello stato precedente successivo, i log raccolti tra l'aggiornamento di ElasticSearch e il ripristino dello stato precedente verranno persi definitivamente. Se si rilascia un downgrade alla versione precedente dei cluster Big Data di SQL Server 2019 (non consigliato), i log archiviati in Elasticsearch verranno persi. Se si esegue l'aggiornamento a CU9, i dati verranno ripristinati.

  • Soluzione alternativa: se necessario, è possibile risolvere i problemi usando i log raccolti usando il comando azdata bdc debug copy-logs.

Pod mancanti e metriche del contenitore

  • Versioni interessate: i cluster esistenti e nuovi al momento dell'aggiornamento a CU9

  • Problema ed effetto sul cliente: a seguito dell'aggiornamento della versione di Telegraf usata per il monitoraggio dei componenti in CU9, quando si aggiorna il cluster alla versione CU9, si noterà che i pod e le metriche dei contenitori non vengono raccolti. Ciò avviene perché è necessaria una risorsa aggiuntiva nella definizione del ruolo del cluster usato per Telegraf come risultato dell'aggiornamento software. Se l'utente che distribuisce il cluster o esegue l'aggiornamento non ha autorizzazioni sufficienti, la distribuzione o l'aggiornamento continuerà con un avviso e avrà esito positivo, ma le metriche di pod e nodi non verranno raccolte.

  • Soluzione alternativa: è possibile chiedere a un amministratore di creare o aggiornare il ruolo e l'account del servizio corrispondente (prima o dopo la distribuzione/aggiornamento) e il cluster Big Data li utilizzerà. Questo articolo descrive come creare gli artefatti necessari.

L'emissione di azdata bdc copy-logs non comporta la copia dei log

  • Versioni interessate: interfaccia della riga di comando di Azure Data (azdata) versione 20.0.0

  • Problema ed effetto sul cliente: l'implementazione del comando copy-logs presuppone che lo strumento client kubectl nella versione 1.15 o superiore sia installato nel computer client da cui viene eseguito il comando. Se viene usato kubectl nella versione 1.14, il comando azdata bdc debug copy-logs verrà completato senza errori, ma i log non vengono copiati. Quando viene eseguito con il flag --debug, è possibile visualizzare questo errore nell'output: l'origine '.' non è valida.

  • Soluzione alternativa: installare kubectl nella versione 1.15 o successiva nello stesso computer client e ripetere il comando azdata bdc copy-logs. Vedere qui le istruzioni su come installare kubectl.

Non è possibile abilitare le funzionalità MSDTC per l'istanza master di SQL Server

  • Versioni interessate: tutte le configurazioni di distribuzione di cluster Big Data, indipendentemente dalla versione.

  • Problema ed effetto sul cliente: con SQL Server distribuito all'interno del cluster Big Data come istanza master di SQL Server, la funzionalità MSDTC non può essere abilitata. Non esiste alcuna soluzione per questo problema.

Rotazione del componente di crittografia della chiave di crittografia del database SQL Server a disponibilità elevata

  • Versioni interessate: tutte le versioni fino a CU8. Risolto per CU9.

  • Problema ed effetto sul cliente: con SQL Server distribuito con la disponibilità elevata, la rotazione dei certificati per il database crittografato ha esito negativo. Quando si esegue il comando seguente nel pool master, viene visualizzato un messaggio di errore:

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

    Non si produce alcun effetto. Il comando ha esito negativo e la crittografia del database di destinazione viene mantenuta usando il certificato precedente.

Abilitare il supporto delle zone di crittografia HDFS in CU8

  • Versioni interessate: questo scenario viene visualizzato quando si esegue l'aggiornamento in modo specifico alla versione CU8 da CU6 o precedente. Questa operazione non si verifica nelle nuove distribuzioni di CU8+ o quando si esegue l'aggiornamento direttamente a CU9. Le versioni CU10 o superiori non sono interessate.

  • Problema ed effetto sul cliente: il supporto delle zone di crittografia HDFS non è abilitato per impostazione predefinita in questo scenario e deve essere configurato usando i passaggi forniti nella guida alla configurazione.

Svuotare i processi Livy prima di applicare gli aggiornamenti cumulativi

  • Versioni interessate: tutte le versioni fino a CU6. Risolto per CU8.

  • Problema ed effetto sul cliente: durante un aggiornamento, sparkhead restituisce l'errore 404.

  • Soluzione alternativa: prima di aggiornare i cluster Big Data, verificare che non siano presenti sessioni Livy o processi batch attivi. Per evitare questo problema, seguire le istruzioni riportate in Aggiornamento dalla versione supportata.

    Se Livy restituisce un errore 404 durante il processo di aggiornamento, riavviare il server Livy in entrambi i nodi sparkhead. Ad esempio:

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

Scadenza della password per l'account del servizio generate dal cluster Big Data

  • Versioni interessate: tutte le distribuzioni di cluster Big Data con integrazione di Active Directory, indipendentemente dalla versione

  • Problema ed effetto sul cliente: durante la distribuzione del cluster Big Data, il flusso di lavoro genera un set di account del servizio. In base ai criteri di scadenza delle password impostati nel controller di dominio, le password per questi account possono scadere (l'impostazione predefinita è 42 giorni). A questo punto, non è disponibile alcun meccanismo di rotazione delle credenziali per tutti gli account dei cluster Big Data, quindi il cluster diventa inutilizzabile quando viene raggiunta la scadenza.

  • Soluzione alternative: aggiornare i criteri di scadenza per gli account del servizio del cluster Big Data impostandoli su "La password non scade mai" nel controller di dominio. Per un elenco completo di questi account, vedere Oggetti di Active Directory generati automaticamente. Questa azione può essere eseguita prima o dopo la scadenza. Nel secondo caso, Active Directory attiverà nuovamente le password scadute.

Credenziali per l'accesso ai servizi tramite l'endpoint gateway

  • Versioni interessate: nuovi cluster distribuiti a partire dalla versione CU5.

  • Problema e impatto sul cliente: per i nuovi cluster Big Data distribuiti con i cluster Big Data di SQL Server CU5, il nome utente del gateway non è root. Se l'applicazione usata per la connessione all'endpoint gateway usa credenziali errate, verrà visualizzato un errore di autenticazione. Questa modifica è il risultato dell'esecuzione di applicazioni all'interno del cluster Big Data come utente non ROOT. Come nuovo comportamento predefinito a partire dai cluster Big Data di SQL Server CU5, quando si distribuisce un nuovo cluster Big Data tramite la versione CU5, il nome utente per l'endpoint gateway è basato sul valore passato tramite la AZDATA_USERNAME variabile di ambiente. Si tratta dello stesso nome utente usato per il controller e gli endpoint SQL Server. Questo influisce solo sulle nuove distribuzioni. I cluster Big Data esistenti distribuiti con qualunque versione precedente continuano a usare root. Non vi è alcun effetto per le credenziali quando il cluster viene distribuito in modo da usare l'autenticazione di Active Directory.

  • Soluzione alternativa: Azure Data Studio gestirà la modifica delle credenziali in modo trasparente per la connessione effettuata al gateway, in modo da consentire l'esperienza di esplorazione di HDFS in ObjectExplorer. È necessario installare la versione più recente di Azure Data Studio, che include le modifiche necessarie per la risoluzione di questo caso d'uso. Per altri scenari in cui è necessario fornire credenziali per l'accesso al servizio tramite il gateway, ad esempio l'accesso con l'interfaccia della riga di comando di Azure Data (azdata) o l'accesso a dashboard Web per Spark, è necessario assicurarsi che vengano usate le credenziali corrette. Se la destinazione è un cluster esistente distribuito prima della versione CU5, si continuerà a usare il root nome utente per la connessione al gateway, anche dopo l'aggiornamento del cluster a CU5. Se si distribuisce un nuovo cluster tramite la build CU5, accedere specificando il nome utente corrispondente alla AZDATA_USERNAME variabile di ambiente.

Mancata raccolta di metriche di pod e nodi

  • Versioni interessate: cluster nuovi ed esistenti che usano immagini CU5

  • Problema ed effetto sul cliente: come risultato di una correzione per la sicurezza relativa all'API usata da telegraf per raccogliere metriche di pod e nodi host, gli utenti possono aver notato che le metriche non vengono raccolte. Questo problema può avvenire in distribuzioni nuove ed esistenti dei cluster Big Data di SQL Server 2019 (dopo l'aggiornamento alla versione CU5). Come risultato della correzione, Telegraf richiede ora un account di servizio con autorizzazioni del ruolo a livello di cluster. La distribuzione tenta di creare l'account di servizio e il ruolo del cluster necessari, ma se l'utente che distribuisce il cluster o esegue l'aggiornamento non ha autorizzazioni sufficienti, la distribuzione o l'aggiornamento continuerà con un avviso e avrà esito positivo, ma le metriche di pod e nodi non verranno raccolte.

  • Soluzione alternativa: è possibile chiedere a un amministratore di creare il ruolo e l'account di servizio, prima o dopo la distribuzione o l'aggiornamento, perché vengano usati dal cluster Big Data. Questo articolo descrive come creare gli artefatti necessari.

errore del comando azdata bdc copy-logs

  • Versioni interessate: interfaccia della riga di comando di Azure Data (azdata) versione 20.0.0

  • Problema ed effetto sul cliente: l'implementazione del comando copy-logs presuppone che lo strumento client kubectl sia installato nel computer client da cui viene eseguito il comando. Se si esegue il comando su un cluster Big Data installato su OpenShift da un client in cui è installato solo lo strumento oc, si riceve un errore: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Soluzione alternativa: installare lo strumento kubectl nello stesso computer client e ripetere il comando azdata bdc copy-logs. Vedere qui le istruzioni su come installare kubectl.

Distribuzione con repository privato

  • Versioni interessate: GDR1, CU1, CU2. Risolto per CU3.

  • Problema ed effetto sul cliente: l'aggiornamento da un repository privato presenta requisiti specifici

  • Soluzione alternativa: Se si usa un repository privato per eseguire preventivamente il pull delle immagini per la distribuzione o l'aggiornamento del cluster Big Data, verificare che le immagini di compilazione correnti e le immagini di compilazione di destinazione si trovino nel repository privato. Questo consente di ripristinare correttamente lo stato precedente, se necessario. Se le credenziali del repository privato sono state modificate dopo la distribuzione originale, poi, aggiornare il segreto corrispondente in Kubernetes prima di eseguire l'aggiornamento. L'interfaccia della riga di comando di Azure Data (azdata) non supporta l'aggiornamento delle credenziali tramite AZDATA_PASSWORD e le variabili di ambiente AZDATA_USERNAME. Aggiornare il segreto tramite kubectl edit secrets.

L'aggiornamento tramite repository diversi per le compilazioni correnti e di destinazione non è supportato.

Possibile esito negativo dell'aggiornamento a causa di un timeout

  • Versioni interessate: GDR1, CU1, CU2. Risolto per CU3.

  • Problema ed effetto sul cliente: l'aggiornamento può avere esito negativo a causa di un timeout.

    Il codice seguente illustra il possibile aspetto dell'errore:

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

    Questo errore si verifica con maggiore probabilità quando si aggiorna un cluster Big Data di SQL Server 2019 nel servizio Azure Kubernetes.

  • Soluzione alternativa: aumentare il timeout per l'aggiornamento.

    Per aumentare i timeout per un aggiornamento, modificare la mappa di configurazione dell'aggiornamento stesso. Per modificare la mappa di configurazione dell'aggiornamento:

    1. Esegui questo comando:

      kubectl edit configmap controller-upgrade-configmap

    2. Modificare i campi seguenti:

      controllerUpgradeTimeoutInMinutes Indica il numero di minuti di attesa del completamento dell'aggiornamento del controller o del database del controller. Il valore predefinito è 5. Per l'aggiornamento impostare almeno il valore 20.

      totalUpgradeTimeoutInMinutes: designa la quantità di tempo combinata per il completamento dell'aggiornamento (aggiornamento controller + controllerdb) da parte del controller e del database del controller. Default is 10. Per l'aggiornamento impostare almeno il valore 40.

      componentUpgradeTimeoutInMinutes: definisce la quantità di tempo disponibile per il completamento di ogni fase successiva dell'aggiornamento. L'impostazione predefinita è 30. Per l'aggiornamento impostare su 45.

    3. Salvare e uscire.

    Lo script Python seguente rappresenta un altro metodo per l'impostazione del timeout:

    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)

L'invio di un processo Livy da Azure Data Studio (ADS) o curl ha esito negativo con l'errore 500

  • Problema ed effetto sul cliente: in una configurazione a disponibilità elevata, le risorse condivise Spark sparkhead sono configurate con più repliche. In questo caso, è possibile che si verifichino errori durante l'invio di un processo Livy da Azure Data Studio (ADS) o curl. A scopo di verifica, se si usa il comando curl per qualsiasi pod sparkhead, la connessione viene rifiutata. Ad esempio, curl https://sparkhead-0:8998/ o curl https://sparkhead-1:8998 restituisce l'errore 500.

    Ciò accade negli scenari seguenti:

    • I pod ZooKeeper o i processi per ogni istanza di ZooKeeper vengono riavviati alcune volte.
    • La connettività di rete tra il pod sparkhead e i pod ZooKeeper non è affidabile.

  • Soluzione alternativa: riavviare entrambi i server 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

Creare una tabella ottimizzata per la memoria quando l'istanza master si trova in un gruppo di disponibilità

  • Problema ed effetto sul cliente: non è possibile usare l'endpoint primario esposto per la connessione ai database del gruppo di disponibilità (listener) per creare tabelle ottimizzate per la memoria.

  • Soluzione alternativa: per creare tabelle ottimizzate per la memoria quando l'istanza master di SQL Server è in una configurazione di un gruppo di disponibilità, connettersi all'istanza di SQL Server, esporre un endpoint, connettersi al database di SQL Server e creare le tabelle ottimizzate per la memoria nella sessione creata con la nuova connessione.

Eseguire l'inserimento in tabelle esterne in modalità di autenticazione di Active Directory

  • Problema e impatto per i clienti: quando l'istanza master di SQL Server è in modalità di autenticazione di Active Directory, una query che seleziona solo da tabelle esterne, dove almeno una delle tabelle esterne si trova in un pool di archiviazione, ed esegue l'inserimento in un'altra tabella esterna, restituisce:

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.

  • Soluzione alternativa: modificare la query in uno dei modi seguenti. Unire la tabella del pool di archiviazione a una tabella locale oppure eseguire prima l'inserimento nella tabella locale, quindi leggere dalla tabella locale per eseguire l'inserimento nel pool di dati.

Non è possibile usare le funzionalità Transparent Data Encryption con i database che fanno parte del gruppo di disponibilità nell'istanza master di SQL Server

  • Problema ed effetto sul cliente: in una configurazione a disponibilità elevata, non è possibile usare database con crittografia abilitata dopo un failover, perché la chiave master usata per la crittografia è diversa per ogni replica.

  • Soluzione alternativa: non è disponibile alcuna soluzione alternativa per questo problema. È consigliabile evitare di abilitare la crittografia in questa configurazione fino a quando non verrà resa disponibile una correzione.

Contenuto correlato

Per ulteriori informazioni sui cluster Big Data di SQL Server 2019, vedere Introduzione ai cluster Big Data di SQL Server.