Condividi tramite

Usare azdata distcp per eseguire lo spostamento dati tra cluster Big Data di SQL Server

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

Questo articolo descrive come usare azdata per eseguire copie di dati distribuite ad alte prestazioni tra cluster Big Data di SQL Server.

Prerequisiti

  • Azure Data Studio
  • azdata 20.3.8 o versioni successive
  • Due cluster Big Data di SQL Server CU13 o versioni successive

Introduzione alle copie di dati distribuite in cluster Big Data di SQL Server

Hadoop HDFS DistCP è uno strumento da riga di comando usato per eseguire copie parallele distribuite di file e cartelle da un cluster HDFS a un altro. La copia parallela distribuita favorisce il trasferimento veloce di file e cartelle a livello di data lake tra due cluster diversi, consentendo migrazioni, la creazione di ambienti segmentati, disponibilità elevata e scenari ripristino di emergenza.

Hadoop HDFS DistCP usa un processo MapReduce interno per espandere un elenco di file e directory nell'input a più attività di mapping, ognuna delle quali copia nella destinazione una partizione dei file specificati nell'elenco di origine. In questo modo, più nodi dati nel cluster di origine possono inviare direttamente dati a più nodi dati nei cluster di destinazione, creando uno scenario di copia parallela veramente distribuita.

Nei cluster Big Data di SQL Server CU13 e versioni successive la funzionalità di copia distribuita è integrata nel prodotto e viene esposta tramite il comando azdata bdc hdfs distcp. Il comando è un'operazione asincrona, che viene restituita immediatamente durante l'esecuzione in background del processo di copia. Monitorare il processo di copia usando azdata o le interfacce utente di monitoraggio fornite.

Come origini e destinazioni sono supportati solo cluster Big Data di SQL Server.

I cluster possono essere distribuiti sia in modalità abilitata per Active Directory sia nelle modalità di sicurezza di base. È possibile eseguire copie tra qualsiasi combinazione di modalità di sicurezza. I cluster abilitati per Active Directory devono trovarsi nello stesso dominio.

In questa guida verranno presentati gli scenari di copia dei dati seguenti:

  • Tra due cluster abilitati per Active Directory
  • Da un cluster con sicurezza di base a un cluster abilitato per Active Directory
  • Tra due cluster con sicurezza di base

Passaggi necessari per tutti gli scenari

Sono necessari certificati per creare una relazione attendibile tra i cluster di origine e di destinazione. Questi passaggi sono necessari una sola volta per ogni combinazione di cluster di origine e di destinazione.

Importante

Se un cluster Big Data di SQL Server con autenticazione di base (non Active Directory) viene aggiornato direttamente alla versione CU13 o successive, la funzionalità distcp richiede l'attivazione. Questo non influisce sulle nuove distribuzioni di cluster CU13+ con autenticazione di base.

Per abilitare la funzionalità distcp in questo scenario, eseguire i passaggi aggiuntivi seguenti una volta:

kubectl -n $CLUSTER_NAME exec -it nmnode-0-0 -- bash
export HADOOP_USER_NAME=hdfs
hadoop fs -mkdir -p /tmp/hadoop-yarn/staging/history
hadoop fs -chown yarn /tmp/hadoop-yarn
hadoop fs -chown yarn /tmp/hadoop-yarn/staging
hadoop fs -chown yarn /tmp/hadoop-yarn/staging/history
hadoop fs -chmod 733 /tmp/hadoop-yarn
hadoop fs -chmod 733 /tmp/hadoop-yarn/staging
hadoop fs -chmod 733 /tmp/hadoop-yarn/staging/history

I notebook necessari nei passaggi successivi fanno parte dei notebook operativi per cluster Big Data di SQL Server. Per altre informazioni su come installare e usare i notebook, vedere Notebook operativi

Passaggio 1 - Creazione e installazione dei certificati

Connettersi al cluster di origine usando Azure Data Studio. È da qui che verranno copiati i dati. Procedi come segue:

  1. Creare un nuovo certificato radice nel cluster di origine usando il notebook cer001-create-root-ca.ipynb

  2. Scaricare il nuovo certificato radice del cluster nel computer usando cer002-download-existing-root-ca.ipynb

  3. Installare il nuovo certificato radice nel cluster di origine usando cer005-install-existing-root-ca.ipynb. Questo passaggio richiederà 10-15 minuti.

  4. Generare un nuovo certificato Knox nel cluster di origine usando cer021-create-knox-cert.ipynb

  5. Firmare il nuovo certificato Knox con il nuovo certificato radice usando cer031-sign-knox-generated-cert.ipynb

  6. Generare il nuovo certificato Knox nel cluster di origine usando cer041-install-knox-cert.ipynb

    Importante

    I comandi di generazione del certificato creeranno il file CA radice (cluster-ca-certificate.crt) e il file del certificato Knox (cacert.pem) in "C:\Users\{Username}\AppData\Local\Temp\1\mssql-cluster-root-ca\" in Windows e in "/tmp/mssql-cluster-root-ca/ in Unix.

Passaggio 2 - Installazione del certificato nella destinazione

Connettersi al cluster di destinazione usando Azure Data Studio. È qui che verranno copiati i dati. Procedi come segue:

Avviso

Se si usa Azure Data Studio in computer diversi per eseguire queste attività, copiare i file cluster-ca-certificate.crt e cacert.pem generati nel passaggio 1 nella posizione corretta nell'altro computer prima di eseguire il notebook nel passaggio successivo.

  1. Installare il nuovo certificato radice dal cluster di origine al cluster di destinazione usando cer005-install-existing-root-ca.ipynb. Questo passaggio richiederà 10-15 minuti.

Passaggio 3 - Creazione del file keytab

È necessario creare un file keytab se uno dei cluster è abilitato per Active Directory. Il file eseguirà l'autenticazione per consentire l'esecuzione della copia.

Creare il file keytab usando ktutil. Esempio: Assicurarsi di definire o sostituire le variabili di ambiente DOMAIN_SERVICE_ACCOUNT_USERNAME, DOMAIN_SERVICE_ACCOUNT_PASSWORD e REALM con i valori appropriati.

ktutil
> add_entry -password -p $DOMAIN_SERVICE_ACCOUNT_USERNAME@$REALM -k 1 -e arcfour-hmac-md5
$DOMAIN_SERVICE_ACCOUNT_PASSWORD
> add_entry -password -p $DOMAIN_SERVICE_ACCOUNT_USERNAME@$REALM -k 1 -e aes256-cts
$DOMAIN_SERVICE_ACCOUNT_PASSWORD
> add_entry -password -p $DOMAIN_SERVICE_ACCOUNT_USERNAME@$REALM -k 1 -e aes256-cts-hmac-sha1-96
$DOMAIN_SERVICE_ACCOUNT_PASSWORD
> wkt /tmp/$DOMAIN_SERVICE_ACCOUNT_USERNAME.keytab
> exit

Passaggio 4 - Copiare il keytab nel percorso di HDFS

Questo passaggio è necessario solo se uno dei cluster è abilitato per Active Directory.

Assicurarsi di definire o sostituire la variabile di ambiente DOMAIN_SERVICE_ACCOUNT_USERNAME con il valore appropriato.

Caricare il keytab nella destinazione (cluster sicuro):

azdata bdc hdfs mkdir -p /user/$DOMAIN_SERVICE_ACCOUNT_USERNAME
azdata bdc hdfs cp -f /tmp/$DOMAIN_SERVICE_ACCOUNT_USERNAME.keytab -t /user/$DOMAIN_SERVICE_ACCOUNT_USERNAME/$DOMAIN_SERVICE_ACCOUNT_USERNAME.keytab

Scenari di copia dei dati

Scenario 1 - Tra due cluster abilitati per Active Directory

  1. Esportare la variabile di ambiente DISTCP_KRB5KEYTAB necessaria:

    export DISTCP_KRB5KEYTAB=/user/$DOMAIN_SERVICE_ACCOUNT_USERNAME/$DOMAIN_SERVICE_ACCOUNT_USERNAME.keytab

  2. Definire o sostituire le variabili CLUSTER_CONTROLLER, DESTINATION_CLUSTER_NAMESPACE e PRINCIPAL con i valori appropriati. Usare quindi azdata per eseguire l'autenticazione nel cluster di destinazione:

    azdata login --auth ad --endpoint $CLUSTER_CONTROLLER --namespace $DESTINATION_CLUSTER_NAMESPACE --principal $PRINCIPAL

  3. Eseguire la copia di dati distribuita:

    azdata bdc hdfs distcp submit -f https://knox.$CLUSTER_NAME.$DOMAIN:30443/file.txt -t  /file.txt

Scenario 2 - Da un cluster con sicurezza di base a un cluster abilitato per Active Directory

  1. Esportare le variabili di ambiente DISTCP_KRB5KEYTAB, DISTCP_AZDATA_USERNAME e DISTCP_AZDATA_PASSWORD necessarie:

    export DISTCP_KRB5KEYTAB=/user/$DOMAIN_SERVICE_ACCOUNT_USERNAME/$DOMAIN_SERVICE_ACCOUNT_USERNAME.keytab
export DISTCP_AZDATA_USERNAME=<your basic security bdc username> 
export DISTCP_AZDATA_PASSWORD=<your basic security bdc password>

  2. Definire o sostituire le variabili CLUSTER_CONTROLLER, DESTINATION_CLUSTER_NAMESPACE e PRINCIPAL con i valori appropriati. Usare quindi azdata per eseguire l'autenticazione nel cluster di destinazione:

    azdata login --auth ad --endpoint $CLUSTER_CONTROLLER --namespace $DESTINATION_CLUSTER_NAMESPACE --principal $PRINCIPAL

  3. Eseguire la copia di dati distribuita

    azdata bdc hdfs distcp submit --from-path https://$SOURCE_CLUSTER_IP:30443/file.txt --to-path /file.txt

Scenario 3 - Tra due cluster con sicurezza di base

  1. Esportare le variabili di ambiente DISTCP_AZDATA_USERNAME e DISTCP_AZDATA_PASSWORD necessarie:

    export DISTCP_AZDATA_USERNAME=<your basic security bdc username> 
export DISTCP_AZDATA_PASSWORD=<your basic security bdc password>

  2. Usare azdata per eseguire l'autenticazione nel cluster di destinazione

  3. Eseguire la copia di dati distribuita

    azdata bdc hdfs distcp submit --from-path https://$SOURCE_CLUSTER_IP:30443/file.txt --to-path /file.txt

Monitoraggio del processo di copia distribuita

Il comando azdata bdc hdfs distcp submit è un'operazione asincrona, che viene restituita immediatamente durante l'esecuzione in background del processo di copia. Monitorare il processo di copia usando azdata o le interfacce utente di monitoraggio fornite.

Elencare tutti i processi di copia distribuita

azdata bdc hdfs distcp list

Prendere nota dell'elemento job-id del processo di cui si vuole tenere traccia. Tutti gli altri comandi dipendono da questo.

Ottenere lo stato di un processo di copia distribuita

azdata bdc hdfs distcp state [--job-id | -i] <JOB_ID>

Ottenere lo stato completo di un processo di copia distribuita

azdata bdc hdfs distcp status [--job-id | -i] <JOB_ID>

Ottenere i log di un processo di copia distribuita

azdata bdc hdfs distcp log [--job-id | -i] <JOB_ID>

Hint per la copia distribuita

  1. Per copiare intere directory e il loro contenuto, terminare l'argomento del percorso con una directory, senza '/'. L'esempio seguente copia l'intera directory sourceDirectories nella destinazione HDFS radice:

    azdata bdc hdfs distcp submit --from-path https://$SOURCE_CLUSTER_IP:30443/sourceDirectories --to-path /

  2. Il comando può contenere opzioni, supportando i modificatori --overwrite, --preserve, --update e --delete. Il modificatore deve essere posizionato subito dopo la parola chiave submit, come mostrato di seguito:

    azdata bdc hdfs distcp submit {options} --from-path https://$SOURCE_CLUSTER_IP:30443/sourceDirectories --to-path /

Passaggi successivi

Per altre informazioni, vedere Introduzione ai cluster Big Data di SQL Server.

Per informazioni di riferimento complete sul nuovo comando, vedere azdata bdc hdfs distcp.