Question Stratégie de sauvegarde et de reprise en charge HDFS Hadoop


Nous nous préparons à mettre en œuvre notre premier cluster Hadoop. En tant que tel, nous commençons petit avec une configuration à quatre nœuds. (1 nœud maître et 3 nœuds de travail) Chaque nœud aura 6 To de stockage. (6 disques de 1 To) Nous avons opté pour un châssis SuperMicro à 4 nœuds afin que les quatre nœuds partagent un seul boîtier 4U.

Nous examinons maintenant comment sauvegarder cette solution pour la reprise après sinistre. (Pensez à la perte de rack ou de site, pas à la perte de lecteur) La meilleure solution semble être une copie cluster à cluster. Bien que j'ai également entendu parler de personnes copiant des données d'un partage NAS ou SMB. De plus, nous allons sauvegarder le nœud maître via des moyens de sauvegarde traditionnels. Je ne suis préoccupé que par les données HDFS. Voici mes questions:

1) Pour la copie de cluster à cluster, puis-je configurer un cluster de nœuds SINGLE avec une grande quantité de stockage pour qu'il serve de réplica hors site? Je me fiche de ses performances, mais simplement de son existence et de sa capacité à contenir l’ensemble de données. (Les temps de restauration ne sont pas un problème, car ce groupe n'est pas critique pour les missions.) La copie peut-elle être planifiée pour ne fonctionner qu'une fois par jour, etc.?

2) Comment cela fonctionne-t-il pour l'option SMB ou NAS? Le disque cible doit-il être formaté HDFS? Dois-je sauvegarder chacun des trois nœuds de travail dans leur intégralité? Ou existe-t-il un script intelligent capable de sauvegarder le jeu de données sans la parité? Je ne connais pas très bien cette solution et je n’ai vu que des références en ligne. Je n'ai pas eu beaucoup de chance pour trouver des ressources ou des informations.

Je suis également ouvert à toutes les autres options de reprise après sinistre pour Hadoop HDFS. Notre objectif est d'obtenir une copie complète du jeu de données HDFS afin de pouvoir l'utiliser pour récupérer un rack ou une perte de site.

Merci!


7
2017-08-13 23:32


origine




Réponses:


Pour l'option 1, vous pouvez utiliser distcp copier d'un cluster à un autre. Le cluster de sauvegarde pourrait certainement être un serveur à un seul nœud, à condition qu’un nom de code et un code de données soient exécutés. Fondamentalement, vous envisagez de courir dans mode pseudo distribué. Pour exécuter la distribution périodiquement,

Pour ce faire périodiquement, je créerais un script shell qui ressemblerait à ceci:

  1. rechercher un fichier de verrouillage
  2. si le fichier de verrouillage existe, renvoyez-le (et vous envoyez éventuellement une alerte si le fichier de verrouillage dure trop longtemps - cela signifierait qu'une distcp précédente a mal quitté et ne s'est pas déverrouillée ou que la distcp précédente prend plus longtemps que prévu ).
  3. s'il n'existe pas, touchez le fichier de verrouillage.
  4. lancez la distcp.
  5. vérifiez l'état du travail distcp pour vous assurer qu'il s'est terminé correctement.
  6. ouvrir.

Je suggère l'utilisation d'un fichier de verrouillage parce que vous ne voulez pas exécuter plusieurs distcp dans cette configuration particulière. Vous finirez par maîtriser votre cluster pseudo distribué. Je voudrais également définir le facteur de réplication par défaut à 1 sur la configuration de cluster pseudo distribué. Pas besoin de doubler les blocs si vous n'en avez pas besoin (cependant, je ne me souviens pas si un pseudo-cluster le fait par défaut; YMMV).

distcp peut fonctionner comme un rsync stupide, ne copiant que ce qui change.

Pour l'option 2, vous pouvez utiliser hadoop fs -copyToLocal. L'inconvénient, c'est qu'il s'agit d'une copie complète à chaque fois. Si vous copiez /, vous copiez tout à chaque exécution.

Pour les métadonnées hadoop, vous souhaiterez copier le fichier fsimage et edits. Ce blog a un aperçu assez raisonnable de ce qu'il faut faire. Il est destiné à l'utilisation de Cloudera, mais devrait être fondamentalement le même pour tous les clusters Hadoop 1.0 ou 2.0.


1
2017-08-20 04:52





Hdfs est, par sa conception, répliqué, généralement sur 3 nœuds minimum. Ainsi, si vous avez 3 nœuds, les données sont déjà répliquées sur les trois.

Bien entendu, ces nœuds doivent se trouver sur différents serveurs physiques. Ensuite, il est peu probable qu’il échoue ou tous les 3 doivent échouer en même temps.

Pour répliquer vos fichiers hdfs actuels, vous pouvez simplement ajouter des nœuds au service hdfs sur d'autres serveurs et les données seront répliquées. Pour vous assurer que les données sont répliquées sur plus de 3 nœuds d'origine, augmentez le paramètre de tolérance aux pannes à 4 nœuds ou plus. Thrn Fermez les autres noeuds de la même unité et vos données seront sur tous les noeuds laissés actifs.


1
2017-11-28 17:48



Bien que ce soit une idée fausse commune, le la réplication n'est pas une sauvegarde. Il est uniquement conçu pour accroître l'efficacité et garantir la continuité en cas de défaillance du matériel. - Un exemple simple expliquant pourquoi ce n’est pas une sauvegarde appropriée: si vous supprimez des fichiers par inadvertance, ils seront supprimés sur tous les nœuds et vous ne pourrez pas les récupérer normalement. - Dennis Jaheruddin