Remarques concernant les performances et la forme
Il existe des éléments importants concernant les prix et les performances lors de l'exécution de Hadoop sur Oracle Cloud Infrastructure. Vous devez également tenir compte de la façon dont vos exigences influent sur les formes de déploiement.
Analyse comparative
Oracle Cloud Infrastructure offre à la fois des avantages aux performances et aux coûts pour les entreprises qui souhaitent exécuter des clusters Hadoop sur Oracle Cloud.
TeraSort est un test d'évaluation commun pour Hadoop car il utilise tous les éléments du cluster (calcul, mémoire, stockage, réseau) pour générer, mapper/réduire et valider un ensemble de données aléatoire.
Une analyse comparative avec des clusters Oracle Cloud Infrastructure normalisés à 300 OCPU et des volumes de blocs utilisés pour le stockage HDFS. Une analyse particulière visant à identifier qu'Oracle Cloud Infrastructure a exécuté trois fois plus rapidement et à offrir un coût inférieur de 80% à un déploiement concurrentiel sur le cloud d'un concurrent.
Le graphique suivant illustre les performances globales de différentes formes Oracle Cloud Infrastructure lors de l'exécution de cette instance TeraSort 10TB à la taille de cluster normalisée :
Description de l'illustration comparison-terasort-phase-cpu.png
Oracle Cloud Infrastructure fournit des instances de calcul Bare Metal standard avec des UC Intel et AMD, ainsi qu'une option HPC spécialisée. Comme le graphique indique, les clusters HPC spécialisés ont été exécutés plus rapidement que les compteurs Intel et AMD, même si ces instances ont des nombres de coeurs moins élevés. Ce résultat s'est produit principalement car ce cluster utilise plus de noeuds pour obtenir le même nombre d'OCPU normalisées, ce qui a une incidence directe sur le débit agrégé HDFS global, ce qui augmente les performances.
Les formes HPC bénéficient également d'une fonctionnalité réseau 100-GBps qui permet un transfert de données intracluster plus rapide.
La figure suivante compare les performances des travailleurs basés sur des machines virtuelles avec des volumes de blocs et un système NVMe Bare Metal, exécutant Cloudera et normalisé vers 10 noeuds de travail dans le cluster :
Description de l'illustration comparison-terasort-vm-bm-performance.png
La baisse des performances de doublage de la taille de machine virtuelle du salarié de 8 à 16 coeurs est d'autant plus efficace que le double, car le débit du réseau VM est une part fractionnaire de la carte d'interface réseau physique sous-jacente. Les avantages de Bare Metal avec NVMe local sont également visibles. Le cluster tire parti de la grande vitesse de stockage NVMe local combinée à l'interface réseau 25Gb/s.
La distinction des formes à utiliser pour le calcul dans un cluster Hadoop est cohérente entre les fournisseurs de logiciels Hadoop.
Sélection d'instance de calcul
Cette section fournit les meilleures pratiques lors de la sélection d'une forme pour chaque rôle de noeud.
Noeuds maître
Les noeuds maîtres ne s'appliquent qu'aux distributions Cloudera, Hortonworks et Apache Hadoop. Par défaut, MapR ne distingue pas les services de cluster des noeuds de travail. En pratique, Oracle recommande d'utiliser une densité de mémoire importante sur les noeuds maîtres pour prendre en charge la surcharge de la gestion des clusters et des services. Les noeuds maîtres exécutent les services Zookeeper, NameNode, JournalNode, Resource Manager, HBase, Spark et de gestion des clusters (Cloudera Manager et Ambari).
- Forme minimale : VM.Standard2.8
- Forme recommandée : VM.Standard2.24
Noeuds actifs
Les noeuds de processus actif sont cohérents entre tous les fournisseurs de services Internet Hadoop et Apache. Adapter la forme du noeud de salarié selon vos besoins en charge de travail. Ceci s'applique aux exigences de calcul et de mémoire, car de nombreux clients recherchent une mémoire agrégée à utiliser avec les charges de travail Spark. La carte traditionnelle/réduction des charges de travail tire également parti d'une empreinte de mémoire accrue sur les noeuds de travail.
- Forme minimale : VM.Standard2.8
- Forme recommandée : BM.DenseIO2.52
Noeuds de prise en charge
Une infrastructure de prise en charge inclut des noeuds de bord ou d'autres noeuds qui pourraient exécuter des services de cluster auxiliaires ou du code d'application personnalisé. Les exigences pour ces noeuds varient selon l'échelle et le cas d'emploi. Pour les noeuds de bordure de réseau, nous recommandons une taille minimale de VM.Standard2.2. Augmentez cette valeur en fonction du nombre d'utilisateurs par point nodal d'axe. Nous recommandons l'utilisation de plusieurs noeuds de bord pour la haute disponibilité entre les domaines de pannes et la création de plusieurs chemins d'accès pour que les utilisateurs interagissent avec le cluster.
Remarques concernant le réseau
Hadoop dépend fortement du réseau pour le trafic intracluster. Les formes choisies pour le déploiement de chaque rôle dans la topologie de cluster ont donc un impact direct sur la connectivité intracluster.
Lors de l'utilisation de formes Bare Metal, les hôtes de calcul peuvent utiliser des cartes d'interface réseau virtuelle (VNIC) 25-GB complètes. Les formes de machine virtuelle sont mises à l'échelle par rapport à leur taille de calcul.
Lorsque vous utilisez des volumes de blocs pour la capacité HDFS, n'oubliez pas que le trafic d'E/S pour un volume de blocs partage la même VNIC que le trafic d'application (par défaut). Une façon d'optimiser cette situation lors de l'utilisation de formes Bare Metal consiste à créer une VNIC secondaire à utiliser pour la connectivité du cluster, sur la seconde interface physique. Cela permet de réserver la VNIC principale pour le trafic des volumes de blocs, ce qui optimise l'utilisation du réseau.
Le diagramme suivant illustre ce concept :
Description de l'illustration architecture-vnic.png
Lorsque vous utilisez des volumes de blocs, considérez également que les E/S HDFS agrégées concernent directement la quantité et la taille des volumes de blocs associés à chaque noeud de salarié. Pour atteindre la capacité HDFS requise, Oracle recommande de mettre à l'échelle un plus grand nombre de volumes par processus actif plutôt qu'un petit nombre de volumes plus grands.
Remarques concernant le stockage
Pour les déploiements Hadoop, deux types de stockage peuvent être utilisés pour la capacité HDFS : les formes DenseIO avec NVMe local et les volumes de blocs. Pour les déploiements MapR, vous devez choisir un type de stockage unique pour les noeuds de travail (homogènes), sauf si vous disposez d'une licence pour la couche de données. D'autres associations de sécurité Hadoop prennent en charge des systèmes de stockage hétérogènes (qui associent DenseIO NVMe et des volumes de blocs) sans frais de licence supplémentaires.
Configurations de stockage prises en charge par le fournisseur
Cloudera et Hortonworks prennent en charge toutes les formes de stockage sur Oracle Cloud Infrastructure pour une utilisation avec Hadoop :
- NVMe local sur formes DenseIO
- Volumes de blocs
- Object Storage (avec compatibilité S3)
Cloudera prend en charge le niveau de données (stockage hétérogène) pour les déploiements qui se composent de volumes de blocs et NVMe locaux pour HDFS.
Les déploiements MapR peuvent tirer parti du service NVMe local sur des formes DenseIO ou des volumes de blocs pour le déploiement.
- Object Storage : reportez-vous à MapR XD Object Tiering.
- MapR ne prend pas en charge le stockage hétérogène sans licence supplémentaire.
DenseIO NVMe
DenseIO NVMe est l'option de stockage la plus performante de Hadoop sur Oracle Cloud Infrastructure. Les lecteurs NVMe locaux haute vitesse à utiliser avec HDFS sont disponibles dans les formes de machine virtuelle et Bare Metal.
Lors de l'utilisation de la mémoire NVMe locale, Oracle recommande de définir la réplication DFS sur trois répliques pour garantir la redondance des données.
Pour les clusters Cloudera, vous pouvez également envisager d'utiliser le codage d'effacement afin d'améliorer l'efficacité du stockage pour des types de données spécifiques.
Volumes de blocs
Les volumes de blocs sur Oracle Cloud Infrastructure sont une option performante et offrent une configuration flexible pour la capacité HDFS. Les volumes de blocs sont un stockage connecté au réseau, et par conséquent, ils utilisent la bande passante VNIC pour les E/S. Les volumes de blocs sont également mis à l'échelle en E/S par seconde et en Mo/s en fonction de leur taille configurée (par Go). Le débit de volume de blocs individuels dépasse 320 Mo/s pour les volumes 700Go ou plus volumineux.
Le tableau suivant présente la mise à l'échelle du débit pour un noeud actif unique à l'aide de volumes 700GB :
| Volumes de blocs | Débit agrégé (Go/s) |
|---|---|
| 3 | 0.94 |
| 4 | 1.25 |
| 5 | 1.56 |
| 6 | 1.88 |
| 7 | 2.19 |
| 8 | 2.50 |
| 9 | 2.81 |
| 10 | 3.13 |
| 11 | 3.44 |
Oracle a détecté qu'après 11 volumes de blocs, l'ajout de volumes de blocs supplémentaires a entraîné une réduction des gains de débit.
Lorsque vous utilisez des machines virtuelles comme salariés, n'oubliez pas que le trafic de volume de blocs partage la même VNIC que le trafic Hadoop (application). Le tableau suivant indique les volumes de blocs et la bande passante de VNIC mesurée recommandés pour une sélection de formes Oracle Cloud Infrastructure, ce qui permet à des instances suffisamment de bande passante supplémentaire pour prendre en charge le trafic d'applications au-dessus des E/S de disque :
| Forme Oracle Cloud Infrastructure | Bande passante de la carte VNIC | Nombre maximal de volumes de blocs suggérés pour HDFS |
|---|---|---|
| BM.DenseIO2.52 | 25Gbps | 11 |
| BM.Standard2.52 | 25Gbps | 11 |
| VM.Standard2.24 | 24.6Gbps | 6 |
| VM.Standard2.16 | 16.4Gbps | 4 |
| VM.Standard2.8 | 8.2Gbps | 3 |
Lorsque vous utilisez des volumes de blocs pour la capacité HDFS, nous vous recommandons d'utiliser un plus grand nombre de petits volumes de blocs plutôt qu'un plus petit nombre de volumes de blocs par processus actif pour atteindre la capacité cible HDFS.
Utilisation du minimum de trois noeuds de processus actifs comme exemple, avec une taille de volume de blocs 700Go pour HDFS :
Description de l'illustration block-volume-hdfs-capacity-chart.png
Notez que le nombre minimum de volumes de blocs requis par processus actif est de trois. Oracle recommande de redimensionner la quantité et la taille des volumes de blocs pour optimiser la capacité HDFS requise, en sachant que davantage de volumes de blocs par salarié augmentent la bande passante HDFS agrégée disponible. Ceci est particulièrement important pour les charges de travail volumineuses, nécessitant des E/S plus agrégées dans le cluster.
Il est également important pour les clusters persistants de laisser davantage de temps système pour la croissance ou la refactorisation.
Journalisation et données d'application
Lorsque vous utilisez des volumes de blocs pour HDFS, vous devez réserver certains volumes de blocs à utiliser avec les journaux et les données d'application Hadoop (les parcelles Cloudera, NameNode et les métadonnées de journal). Bien que les volumes de système d'exploitation puissent être étendus pour contenir ces données, il est préférable d'utiliser des volumes de blocs dédiés dans ce but. Les volumes de blocs vous offrent une meilleure portabilité si vous souhaitez modifier le type d'instance de vos noeuds maître et plus de souplesse si vous avez besoin de plus de performances d'E/S pour un emplacement de données particulier. Il est plus facile d'ajouter quelques volumes de blocs à l'instance, de créer une baie RAID et de migrer les données existantes lorsque des volumes de rechange lui sont associés.
Cette option est également valable pour HDFS. L'ajout de volumes de blocs supplémentaires peut être plus facile que la mise hors service des salariés, la recréation avec des disques de plus grande taille, l'ajout de ceux-ci au cluster et le rééquilibrage d'HDFS. Les deux approches sont valides, c'est-à-dire que votre charge de travail de cluster requiert un complément complet des volumes de blocs pour prendre en charge le débit des données. Si c'est le cas, envisagez de basculer des salariés vers des formes Bare Metal Dense IO avec un stockage NVMe plus rapide, et d'utiliser un modèle de stockage hétérogène avec un niveau de données.
Object Storage
L'intégration d'Object Storage est possible avec toutes les ISV Hadoop, y compris Apache Hadoop. Oracle Cloud Infrastructure dispose d'un connecteur HDFS natif compatible avec Apache Hadoop. Les listes ISV (Cloudera, Hortonworks et MapR) de Hadoop autorisent les adresses externes pour l'intégration Object Storage et exigent l'utilisation de la compatibilité S3 pour que l'intégration Object Storage fonctionne correctement.
L'un des avertissements est que la compatibilité S3 fonctionne uniquement avec la région du répertoire de base de location. Cela signifie que pour toute intégration effectuée avec Object Storage, les clusters Hadoop doivent également être déployés dans la même région (répertoire de base).
En revanche, si vous utilisez Object Storage pour propager ou extraire des données dans le cluster, HDFS n'est pas utilisé en tant que couche de mise en mémoire cache. En fait, le système de fichiers OS est dans lequel les données sont mises en mémoire cache lorsqu'elles sont placées entre Object Storage et HDFS. Si un volume important de données transite entre le cluster HDFS et Object Storage, nous vous recommandons de créer une couche de mise en cache de volume de blocs sur le système d'exploitation pour prendre en charge ce déplacement de données.
La figure suivante présente un diagramme de partition standard pour la prise en charge du mouvement des données S3, ainsi que l'organisation des données pour les noeuds de travail.
Description de l'illustration object-storage-partitioning-throughput.png
Niveau de données
Vous pouvez combiner toutes les options de stockage précédentes lorsque vous utilisez Apache Hadoop, Cloudera ou Hortonworks pour créer un modèle de stockage robuste entre plusieurs niveaux de données (hétérogènes). Vous pouvez également utiliser la gestion du cycle de vie des données pour transmettre les données d'un niveau de stockage à un autre sous forme de données, afin d'optimiser les coûts de stockage HDFS.
Description de l'illustration data-lifecycle-tiering.png
Codage de l'Erasure
A partir de Hadoop 3.0, l'encodage d'effacement (EC) est pris en charge sur les déploiements HDFS. EC réduit les exigences de stockage pour les données HDFS locales en stockant les données avec une seule copie supplémentaire par les cellules de parité. HDFS Topologie peut être marqué comme EC, ce qui active cette fonctionnalité pour toutes les données stockées dans cet emplacement balisé. Ainsi, les besoins en stockage brut pour les données HDFS avec balisage ECC sont réduits afin d'améliorer l'efficacité du stockage.
Voici quelques remarques concernant la communauté européenne :
- Le nombre minimal de noeuds de processus actif est requis pour l'activation de l'EC.
- La localité des données est perdue pour les données balisées EC.
- EC est approprié pour les fichiers de taille moyenne qui sont consultés rarement. Il n'est pas assez efficace pour les petits fichiers et pour les fichiers fréquemment ouverts.
- EC augmente le nombre d'objets de bloc présents dans les métadonnées de noeud de nom par rapport aux données similaires de la réplication traditionnelle (3x).
- La récupération des données EC nécessite un calcul depuis le cluster (reconstruction de parité). Cette durée de récupération est plus longue que les données répliquées traditionnelles (3x).
Surveillance des performances
Le service Oracle Cloud Infrastructure Monitoring vous permet de surveiller de façon active et passive vos ressources cloud à l'aide des fonctionnalités de mesures et d'alarmes. La définition d'alarmes à notifier lorsque vous atteignez des performances ou des seuils de capacité est un bon moyen d'utiliser les outils natifs Oracle Cloud Infrastructure pour gérer votre infrastructure
Architectures de référence
Cette rubrique fournit du matériel de référence pour chaque ISV Hadoop. Les architectures de référence et les nomenclatures suivantes reflètent une empreinte minimale requise pour le déploiement pris en charge par le fournisseur de Hadoop sur Oracle Cloud Infrastructure.
En tant que projet open source, le déploiement Apache Hadoop ne dispose pas d'une empreinte minimale requise fournie par le fournisseur. Oracle recommande d'utiliser le déploiement Hortonworks indiqué ici en tant que guide raisonnable pour un déploiement Apache minimal.
Cloudera
Description de l'illustration architecture-cloudera.png
Les exigences minimales pour le déploiement de Hadoop à l'aide de Cloudera sont les suivantes :
| Rôle | Quantité | Forme de calcul recommandée |
|---|---|---|
| Bordure de réseau | 1 | VM.Standard2.4 |
| Cloudera Manager | 1 | VM.Standard2.16 |
| Noeud maître | 2 | VM.Standard2.16 |
| Noeud actif | 3 | BM.DenselO2.52 |
Dans ce déploiement minimal, le noeud Cloudera Manager exécute également les services maîtres.
Vous devez utiliser votre propre licence pour déployer Cloudera sur Oracle Cloud Infrastructure ; l'ensemble du logiciel est pris en charge via Cloudera.
Hortonworks
Description de l'illustration Architect ure-hortonworks.png
Les conditions minimales requises pour le déploiement de Hadoop à l'aide d'Hortonworks sont les suivantes :
| Rôle | Quantité | Forme de calcul recommandée |
|---|---|---|
| Bordure de réseau | 1 | VM.Standard2.4 |
| Ambari | 1 | VM.Standard2.16 |
| Noeud maître | 2 | VM.Standard2.16 |
| Noeud actif | 3 | BM.DenselO2.52 |
Dans ce déploiement minimal, le noeud Ambari exécute également les services maîtres.
Vous devez utiliser votre propre licence pour déployer Hortonworks sur Oracle Cloud Infrastructure ; l'ensemble du logiciel prend en charge Hortonworks.
MapR
Description de l'illustration architecture-mapr.png
La configuration minimale requise pour le déploiement de Hadoop à l'aide de MapR est la suivante :
| Rôle | Quantité | Forme de calcul recommandée |
|---|---|---|
| Bordure de réseau | 1 | VM.Standard2.4 |
| Noeud de données | 3 | BM.DenselO2.52 |
Vous devez utiliser votre propre licence pour déployer MapR sur Oracle Cloud Infrastructure ; l'ensemble du support logiciel est à l'aide de MapR.
Déploiements Terraform
Vous pouvez trouver des modèles Terraform pour chaque ISV Hadoop dans la section Code de téléchargement de cette solution.
Les référentiels Cloudera et Hortonworks disposent de modèles conformes à Oracle Resource Manager. Ils sont propres au gestionnaire de ressources. Le branchement de base (maître) contient un modèle Terraform autonome. Les modèles de gestionnaire de ressources pour Cloudera et Hortonworks contiennent également un schéma YAML qui renseigne facilement les variables Terraform pour chaque modèle. Vous disposez ainsi d'une sélection d'interface utilisateur déroulante pour les variables, que vous pouvez personnaliser selon vos cas d'emploi, en utilisant essentiellement chaque modèle avec des options de forme autorisées et des paramètres de sécurité/configuration.