Utiliser azdata distcp pour effectuer le déplacement des données entre les clusters Big Data SQL Server

Article
03/21/2023

S’applique à : SQL Server 2019 (15.x)

Important

Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.

Cet article explique comment utiliser azdata pour effectuer des copies de données distribuées hautes performances entre Clusters Big Data SQL Server.

Prérequis

Azure Data Studio
azdata version 20.3.8 ou supérieure
Deux clusters Big Data SQL Server CU13 ou supérieur

Présentation des copies de données distribuées sur les Clusters Big Data SQL Server

Hadoop HDFS DistCP est un outil en ligne de commande utilisé pour effectuer des copies parallèles distribuées de fichiers et de dossiers d’un cluster HDFS sur un autre. La copie parallèle distribuée permet de transférer rapidement des fichiers et des dossiers à l’échelle du lac de données entre deux clusters différents, pour permettre les migrations, la création d’environnements segmentés, la haute disponibilité et les scénarios de reprise d’activité.

Hadoop HDFS DistCP utilise un travail MapReduce interne pour étendre une liste de fichiers et de répertoires comme entrée de plusieurs tâches de mappage, dont chacune d’elles copie une partition des fichiers spécifiés de la liste source vers la destination. Cela permet à plusieurs nœuds de données du cluster source d’envoyer des données directement à plusieurs nœuds de données des clusters de destination, créant ainsi un véritable scénario de copie parallèle distribuée.

Sur les Clusters Big Data SQL Server CU13 et ultérieur, la fonctionnalité de copie distribuée est intégrée au produit et exposée avec la commande azdata bdc hdfs distcp. La commande est une opération asynchrone qui retourne immédiatement une réponse pendant que le travail de copie s’exécute en arrière-plan. Supervisez le travail de copie à l’aide de azdata ou des interfaces utilisateur de supervision fournies.

Seules les sources et les destinations de Clusters Big Data SQL Server sont prises en charge.

Les clusters peuvent être déployés en mode Active Directory ou en mode de sécurité de base. Les copies peuvent être effectuées entre n’importe quelle combinaison de modes de sécurité. Pour les clusters Active Directory, ils doivent se trouver dans le même domaine.

Dans ce guide, nous abordons les scénarios de copie de données suivants :

Cluster Active Directory vers cluster Active Directory
Cluster de sécurité de base vers cluster Active Directory
Cluster de sécurité de base vers cluster de sécurité de base

Étapes nécessaires pour tous les scénarios

Des certificats sont nécessaires pour créer une relation approuvée entre les clusters source et de destination. Ces étapes sont nécessaires une seule fois par combinaison de clusters source/de destination.

Important

Si un cluster Big Data SQL Server avec authentification de base (et non AD) est directement mis à niveau vers CU13 ou une version ultérieure, une activation est nécessaire pour la fonctionnalité distcp. (Cela n’affecte pas les nouveaux déploiements de clusters CU13 et versions ultérieures avec authentification de base.)

Pour activer la fonctionnalité distcp dans ce scénario, exécutez les étapes supplémentaires suivantes une fois :

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

Les notebooks nécessaires dans les étapes suivantes font partie des Notebooks opérationnels des Clusters Big Data SQL Server. Pour plus d’informations sur l’installation et l’utilisation des notebooks, consultez Notebooks opérationnels

Étape 1 : Création et installation d’un certificat

Connectez-vous à votre cluster source à l’aide d’Azure Data Studio. C’est là que se trouvent les fichiers à copier. Procédez comme suit :

Créez un certificat racine de cluster dans le cluster source à l’aide du notebook cer001-create-root-ca.ipynb
Téléchargez le nouveau certificat racine de cluster sur votre machine avec cer002-download-existing-root-ca.ipynb
Installez le nouveau certificat racine sur le cluster source avec cer005-install-existing-root-ca.ipynb. Cette étape prend environ 10-15 minutes.
Générez un nouveau certificat Knox sur le cluster source avec cer021-create-knox-cert.ipynb
Connectez-vous avec le nouveau certificat Knox avec cer031-sign-knox-generated-cert.ipynb
Installez le nouveau certificat Knox sur le cluster source avec cer041-install-knox-cert.ipynb

Important

Les commandes de génération de certificat créent le fichier AC racine (cluster-ca-certificate.crt) et le fichier de certificat Knox (cacert.pem) dans "C:\Users\{Username}\AppData\Local\Temp\1\mssql-cluster-root-ca\" sur Windows et "/tmp/mssql-cluster-root-ca/ sur Unix.

Étape 2 : Installation du certificat sur la destination

Connectez-vous à votre cluster de destination à l’aide d’Azure Data Studio. C’est là où sont copiés les fichiers. Procédez comme suit :

Avertissement

Si vous utilisez Azure Data Studio sur différentes machines pour effectuer ces tâches, copiez les fichiers cluster-ca-certificate.crt et cacert.pem générés à l’étape 1 dans les emplacements appropriés sur l’autre machine avant d’exécuter le notebook de l’étape suivante.

Installez le nouveau certificat racine du cluster source sur le cluster de destination avec cer005-install-existing-root-ca.ipynb. Cette étape prend environ 10-15 minutes.

Étape 3 : Création d’un fichier keytab

Vous devez créer un fichier keytab si un des clusters utilise Active Directory. Le fichier effectue l’authentification pour permettre l’exécution de la copie.

Créez le fichier keytabl avec ktutil. Un exemple suit. Veillez à définir ou remplacer les variables d’environnement DOMAIN_SERVICE_ACCOUNT_USERNAME, DOMAIN_SERVICE_ACCOUNT_PASSWORD et REALM par les valeurs appropriées.

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

Étape 4 : Copier le fichier keytab à l’emplacement HDFS

Cette étape est obligatoire uniquement si un des clusters utilise Active Directory.

Veillez à définir ou remplacer la variable d’environnement DOMAIN_SERVICE_ACCOUNT_USERNAME par la valeur appropriée.

Charger le fichier keytab vers la destination (cluster sécurisé) :

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

Scénarios de copie de données

Scénario 1 : Cluster Active Directory vers cluster Active Directory

Exportez la variable d’environnement nécessaire DISTCP_KRB5KEYTAB :

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

Vous pouvez définir ou remplacer les variables CLUSTER_CONTROLLER, DESTINATION_CLUSTER_NAMESPACE et PRINCIPAL par les valeurs appropriées. Utilisez ensuite azdata pour vous authentifier sur le cluster de destination :
```
azdata login --auth ad --endpoint $CLUSTER_CONTROLLER --namespace $DESTINATION_CLUSTER_NAMESPACE --principal $PRINCIPAL
```

Exécutez la copie de données distribuée :

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

Scénario 2 : Cluster de sécurité de base vers cluster Active Directory

Exportez les variables d’environnement nécessaires DISTCP_KRB5KEYTAB, DISTCP_AZDATA_USERNAME et DISTCP_AZDATA_PASSWORD :

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>

Vous pouvez définir ou remplacer les variables CLUSTER_CONTROLLER, DESTINATION_CLUSTER_NAMESPACE et PRINCIPAL par les valeurs appropriées. Utilisez ensuite azdata pour vous authentifier sur le cluster de destination :
```
azdata login --auth ad --endpoint $CLUSTER_CONTROLLER --namespace $DESTINATION_CLUSTER_NAMESPACE --principal $PRINCIPAL
```

Exécutez la copie de données distribuées

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

Scénario 3 : Cluster de sécurité de base vers cluster de sécurité de base

Exportez les variables d’environnement nécessaires DISTCP_AZDATA_USERNAME et DISTCP_AZDATA_PASSWORD :

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

Utilisez azdata pour vous authentifier sur le cluster de destination

Exécutez la copie de données distribuées

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

Supervision du travail de copie distribuée

La commande azdata bdc hdfs distcp submit est une opération asynchrone qui retourne immédiatement une réponse pendant que le travail de copie s’exécute en arrière-plan. Supervisez le travail de copie à l’aide de azdata ou des interfaces utilisateur de supervision fournies.

Lister tous les travaux de copie distribuée

azdata bdc hdfs distcp list

Notez le job-id du travail que vous voulez suivre. Toutes les autres commandes en dépendent.

Obtenir l’état d’un travail de copie distribuée

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

Obtenir l’état complet d’un travail de copie distribuée

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

Obtenir les journaux d’un travail de copie distribuée

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

Conseils pour la copie distribuée

Pour copier des répertoires entiers et leur contenu, terminez l’argument path par un répertoire, sans « / ». L’exemple suivant copie l’intégralité du répertoire sourceDirectories à la racine HDFS de la destination :
```
azdata bdc hdfs distcp submit --from-path https://$SOURCE_CLUSTER_IP:30443/sourceDirectories --to-path /
```
La commande peut contenir des options qui prennent en charge les modificateurs --overwrite, --preserve, --update et --delete. Le modificateur doit être placé juste après le mot clé submit, comme ci-dessous :
```
azdata bdc hdfs distcp submit {options} --from-path https://$SOURCE_CLUSTER_IP:30443/sourceDirectories --to-path /
```

Étapes suivantes

Pour plus d’informations, consultez Présentation des Clusters Big Data SQL Server.

Pour des informations de référence complètes sur la nouvelle commande, consultez azdata bdc hdfs distcp.

Partager via