Lorsque vous copiez ou déplacez des données entre des systèmes de stockage distincts, par exemple entre différents clusters Apache HDFS ou entre HDFS et Cloud Storage, il est recommandé d'effectuer un certain type de validation pour garantir l'intégrité des données. Cette validation est essentielle pour s'assurer que les données n'ont pas été modifiées lors du transfert.
Même si plusieurs mécanismes garantissent déjà l'intégrité point à point des données en transit (comme TLS pour toutes les communications avec Cloud Storage), la validation explicite de l'intégrité des données de bout en bout offre une couche de protection supplémentaire pour les cas susceptibles d'échapper aux mécanismes de validation en transit classiques. Cela peut vous aider à détecter une corruption potentielle des données pouvant être causée par des liens réseau bruyants, des erreurs de mémoire sur les ordinateurs serveurs et les routeurs le long du chemin, ou des bugs logiciels (par exemple, dans une bibliothèque utilisée par les clients).
Pour Cloud Storage, cette validation est effectuée automatiquement côté client via des commandes telles que gsutil cp et rsync. Ces commandes calculent les sommes de contrôle du fichier local, qui sont ensuite validées par rapport aux sommes de contrôle calculées par Cloud Storage à la fin de chaque opération. Si les sommes de contrôle ne correspondent pas, gsutil supprime les copies non valides et affiche un message d'avertissement.
Dans le cas très improbable d'une erreur de correspondance, vous pouvez retenter l'opération.
Aujourd'hui, il est également possible d'effectuer automatiquement une validation de bout en bout côté client dans Apache Hadoop sur des systèmes de fichiers hétérogènes compatibles avec Hadoop, tels que HDFS et Cloud Storage. Cet article explique comment comparer avec efficacité et précision les sommes de contrôle des fichiers à l'aide de la nouvelle fonctionnalité.
Comment HDFS calcule les sommes de contrôle des fichiers
HDFS utilise le hachage CRC32C, un contrôle de redondance cyclique (CRC) 32 bits basé sur le polynôme de Castagnoli, pour préserver l'intégrité des données dans différents contextes :
- Au repos, Hadoop DataNodes vérifie les données en continu par rapport aux CRC stockés afin de détecter et de réparer la dégradation des données.
- En transit, les DataNodes envoient des CRC connus, accompagnés des données groupées correspondantes. Les bibliothèques clientes HDFS calculent ensuite de manière coopérative les CRC par fragments afin de les comparer avec les CRC envoyés par les DataNodes.
- Dans le cadre de l'administration de HDFS, les sommes de contrôle au niveau du bloc sont utilisées pour les vérifications manuelles de l'intégrité de bas niveau effectuées sur les différents fichiers de blocs sur DataNodes.
- Pour les cas d'utilisation arbitraires au niveau de la couche d'application, l'interface
FileSystemdéfinitgetFileChecksum, et la mise en œuvre de HDFS exploite ses CRC stockés ultraprécis pour définir une somme de contrôle au niveau du fichier.
Pour la plupart des utilisations courantes, les CRC sont utilisés de manière transparente par rapport à la couche d'application. Les seuls CRC utilisés sont les CRC32C par fragments, qui sont déjà précalculés et stockés dans des fichiers de métadonnées, en même temps que les données de blocs. La taille des fragments est définie par dfs.bytes-per-checksum, avec une valeur par défaut de 512 octets.
Limitations de la somme de contrôle des fichiers par défaut de Hadoop
Par défaut, lorsque vous utilisez Hadoop, toutes les sommes de contrôle exposées par l'API prennent la forme d'un hachage MD5 résultant d'une concaténation de fragments CRC32C, que ce soit au niveau du bloc via le protocole de bas niveau DataTransferProtocol, ou au niveau du fichier via l'interface de haut niveau FileSystem. Une somme de contrôle au niveau du fichier est définie comme étant le hachage MD5 de la concaténation de toutes les sommes de contrôle de bloc, chacune d'entre elles étant un hachage MD5 d'une concaténation de fragments CRC. Ainsi, cette somme de contrôle est nommée MD5MD5CRC32FileChecksum. En réalité, il s'agit d'un arbre de Merkle à trois couches et à la demande.
Cette définition de la somme de contrôle au niveau du fichier est sensible aux détails concernant la structure des données et la mise en œuvre de HDFS, à savoir la taille du fragment (par défaut, 512 octets) et la taille du bloc (par défaut, 128 Mo). Cette somme de contrôle des fichiers par défaut n'est donc pas adaptée dans les situations suivantes :
- Lorsqu'il existe deux copies différentes des mêmes fichiers dans HDFS, mais avec une configuration différente de la taille des blocs par fichier.
- Lorsqu'il existe deux instances différentes de HDFS avec une configuration différente de la taille des blocs ou des fragments.
- Lorsqu'il existe une combinaison des systèmes de fichiers compatibles avec Hadoop HDFS et non-HDFS, comme Cloud Storage.
Le schéma suivant montre comment un même fichier peut se retrouver avec plusieurs sommes de contrôle différentes en fonction de la configuration du système de fichiers :
Vous pouvez afficher la somme de contrôle par défaut d'un fichier dans HDFS à l'aide de la commande Hadoop fs -checksum :
hadoop fs -checksum hdfs:///user/bob/data.bin
Dans un cluster HDFS dont la taille de bloc est de 64 Mo (dfs.block.size=67108864), cette commande affiche un résultat semblable à celui-ci :
hdfs:///user/bob/data.bin MD5-of-131072MD5-of-512CRC32C 000002000000000000020000e9378baa1b8599e50cca212ccec2f8b7
Pour le même fichier d'un autre cluster dont la taille de bloc est de 128 Mo (dfs.block.size=134217728), vous obtenez un résultat différent :
hdfs:///user/bob/data.bin MD5-of-0MD5-of-512CRC32C 000002000000000000000000d3a7bae0b5200ed6707803a3911959f9
Ces exemples montrent bien qu'un même fichier peut présenter deux sommes de contrôle différentes.
Fonctionnement de la nouvelle somme de contrôle pour le fichier CRC composite de Hadoop
Pour résoudre ces problèmes, un nouveau type de somme de contrôle, suivi dans HDFS-13056, a été publié dans Apache Hadoop 3.1.1. Ce nouveau type, configuré par dfs.checksum.combine.mode=COMPOSITE_CRC, définit de nouveaux blocs CRC composites et fichiers CRC composites pour établir un CRC composé de manière mathématique, sur les fragments CRC stockés. En plus d'éviter l'utilisation d'un MD5 des composants CRC pour calculer un seul CRC, représentant l'ensemble des blocs ou des fichiers, ce type n'est pas concerné par le niveau inférieur de précision des fragments CRC.
La composition du CRC présente de nombreux avantages. Elle est efficace, ce qui permet aux sommes de contrôle résultantes d'être complètement indépendantes des blocs/fragments. Elle permet également de comparer des fichiers entrelacés et des fichiers répliqués, différentes instances HDFS entre elles, ou encore HDFS et d'autres systèmes de stockage externes. (Vous pouvez obtenir plus d'informations sur l'algorithme CRC dans ce téléchargement au format PDF).
Le schéma suivant montre que la somme de contrôle d'un fichier reste cohérente après un transfert entre des configurations de système de fichiers hétérogènes :
Cette fonctionnalité est peu invasive. Elle peut être ajoutée sur place pour être compatible avec les métadonnées de blocs existantes, et ne nécessite pas de modifier le chemin d'accès à la vérification des fragments. En outre, cela signifie que même les déploiements HDFS préexistants de grande envergure peuvent adopter cette fonctionnalité pour synchroniser les données de manière rétroactive. Pour en savoir plus, téléchargez le document complet au format PDF.
Utiliser le nouveau type de somme de contrôle pour le fichier CRC composite
Pour utiliser le nouveau type de somme de contrôle pour le fichier CRC composite dans Hadoop, définissez la propriété dfs.checksum.combine.mode sur COMPOSITE_CRC (pour remplacer la valeur par défaut MD5MD5CRC). Lorsqu'un fichier est copié d'un emplacement à un autre, le type de somme de contrôle au niveau du fragment (soit la propriété dfs.checksum.type, définie sur CRC32C par défaut) doit également correspondre sur les deux emplacements.
Vous pouvez afficher le nouveau type de somme de contrôle d'un fichier dans HDFS en transmettant l'argument -Ddfs.checksum.combine.mode=COMPOSITE_CRC à la commande Hadoop fs -checksum :
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -checksum hdfs:///user/bob/data.bin
Indépendamment de la configuration de la taille de bloc du cluster HDFS, vous obtenez le même résultat, semblable à ce qui suit :
hdfs:///user/bob/data.bin COMPOSITE-CRC32C c517d290
Pour Cloud Storage, vous devez en outre définir explicitement la propriété fs.gs.checksum.type du connecteur Cloud Storage sur CRC32C. Sinon, la valeur par défaut de cette propriété est NONE, ce qui entraîne la désactivation par défaut des sommes de contrôle de fichiers. Ce comportement par défaut du connecteur Cloud Storage est une mesure préventive visant à éviter un problème qui survient avec distcp, qui génère une exception, au lieu d'échouer normalement, si les types des sommes de contrôle ne correspondent pas. La commande se présente comme suit :
hadoop fs -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C -checksum gs://[BUCKET]/user/bob/data.bin
La commande affiche le même résultat que dans l'exemple précédent sur HDFS :
gs://[BUCKET]/user/bob/data.bin COMPOSITE-CRC32C c517d290
Vous pouvez voir que les sommes de contrôle CRC composites renvoyées par les commandes précédentes correspondent toutes, quelle que soit la taille des blocs. Il en va de même pour HDFS et Cloud Storage. À l'aide des sommes de contrôle CRC composites, vous pouvez désormais garantir la préservation de l'intégrité des données lors du transfert de fichiers parmi tous les types de configurations des clusters Hadoop.
Si vous exécutez distcp, comme dans l'exemple suivant, la validation est effectuée automatiquement :
hadoop distcp -Ddfs.checksum.combine.mode=COMPOSITE_CRC -Dfs.gs.checksum.type=CRC32C hdfs:///user/bob/* gs://[BUCKET]/user/bob/
Si distcp détecte une erreur de correspondance pour la somme de contrôle d'un fichier entre la source et la destination lors de la copie, l'opération échoue et renvoie un avertissement.
Accéder à la fonctionnalité
La nouvelle fonctionnalité de somme de contrôle CRC composite est disponible dans Apache Hadoop 3.1.1 (consultez les notes de version). Des rétroportages vers les versions 2.7, 2.8 et 2.9 sont en préparation. Elle est incluse par défaut dans les versions de correction de Cloud Dataproc 1.3 depuis fin 2018.