Remarques concernant le déploiement de Hadoop sur Oracle Cloud Infrastructure

Déploiement

Lorsque vous vous abonnez à l'infrastructure d'Oracle en tant que service (IaaS), vous avez accès à tous les services de calcul, de stockage et réseau qui lui sont associés. Les déploiements sur Oracle Cloud Infrastructure sont tout comme les déploiements sur site. En effet, les mêmes versions et fonctionnalités sont disponibles pour chaque distribution Hadoop.

Teraforme et gestionnaire ressources

Des équipes d'ingénierie Oracle Cloud Infrastructure ont établi des partenariats avec chaque ISV Hadoop afin de permettre le déploiement d'un système Terraform. Terraform vous permet de déployer une infrastructure en tant que code (IaC), et cela inclut tous les aspects d'un écosystème Hadoop, du réseau (réseaux cloud virtuels, sous-réseaux, VNIC) et des listes de contrôle d'accès de sécurité, pour calculer et stocker le provisionnement. Terraform est flexible, hautement évolutif et standard parmi de nombreux fournisseurs cloud.

Vous pouvez choisir d'utiliser ces modèles en tant que structure pour le déploiement de Hadoop sur Oracle Cloud Infrastructure ou de conserver les outils de déploiement existants que vous avez utilisés on-premise. Les deux méthodes sont valides.

Si vous voulez utiliser Terraform pour déployer Hadoop, envisagez d'utiliser Oracle Resource Manager. Tenez compte des principaux avantages que présente l'utilisation du gestionnaire des ressources :

Les métadonnées d'état Terraform sont conservées dans un emplacement hautement disponible.
L'accès à Resource Manager peut être géré avec les mêmes outils de sécurité et d'audit que ceux des autres services Oracle Cloud Infrastructure.
Resource Manager élimine la complexité associée à la configuration de Terraform pour le déploiement sur Oracle Cloud Infrastructure.

L'interface du gestionnaire de ressources prend en charge les fichiers de schéma basés sur YAML remplis avec les valeurs attendues pour les variables de pile. Vous pouvez ainsi définir les formes, les versions logicielles et d'autres paramètres autorisés pour chaque variable de la pile.

Description de l'illustration resource-manager-ui.png

Une fois le fichier de schéma rempli, les valeurs sont affichées dans une interface utilisateur facile à utiliser. Le fichier de schéma vous permet de disposer de listes déroulantes avec ces valeurs, ainsi que de champs de saisie personnalisés dans lesquels les utilisateurs peuvent saisir ou coller des entrées.

Les champs du fichier de schéma peuvent également comporter des dépendances, de sorte que si un utilisateur choisit une valeur dans un champ, d'autres champs sont affichés ou masqués en fonction de ce choix.

Topologie du service de cluster

Lors du déploiement de Hadoop, tenez compte de la correspondance suivante entre la topologie de service de cluster et les rôles de noeud :

Type de noeud	Rôle Hadoop	Services Hadoop
Bordure de réseau	Accès utilisateur à partir du perimiter	Bibliothèques client, Oozie
Utilitaire	Gestion de cluster	Cloudera Manager, ambari, base de données de métadonnées
Maître	Services de cluster principal	Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Job History, Resource Manager, HTTPFS, SOLR
Travailleur	Exécution de charge globale, Stockage des données	HDFS, NodeManager, Region Server, Kafka Broker, Spark Executor, Map/Reduce

Lorsque vous choisissez les formes de calcul à utiliser pour ces rôles, les meilleures pratiques sont décrites plus loin dans cette solution. Prenez également en compte les critères suivants :

Combien d'utilisateurs simultanés utiliseront le cluster ?
Les noeuds de bordure doivent être mis à l'échelle à la fois dans la quantité et dans OCPU en fonction du nombre d'utilisateurs simultanés. Il est conseillé de donner deux utilisateurs simultanés par OCPU, pour un thread par utilisateur. Les noeuds de bordure supplémentaires sur les domaines de pannes assurent également la redondance.
Disposez-vous d'exigences spécifiques en mémoire pour le serveur de régions Spark ou HBase ?
Ces besoins ont un impact direct sur la quantité et la composition des noeuds de salarié. Le dimensionnement pour HBase requiert une compréhension de l'application sous-jacente et varie. La plupart des clients connaissent déjà leurs exigences en matière de déploiement HBase, notamment le nombre de serveurs de région et la mémoire alloués par serveur. De même, les charges de travail Spark possèdent une cible de mémoire agrégée qui est obtenue en tenant compte du nombre de noeuds actifs multiplié par la mémoire disponible par chaque processus actif.
Disposez-vous d'une exigence de capacité HDFS spécifique ?
La plupart des clients disposent de cette exigence. Toutefois, avant d'évoluer à l'échelle sur un grand nombre de noeuds de travail DenseIO Bare Metal, pensez au fait que NVMe-backed HDFS peut être augmenté en fonction des volumes de blocs pour obtenir la densité HDFS requise, comme décrit plus loin dans cette solution. Oracle recommande de comprendre les exigences HDFS, mais également de prendre en compte les exigences de charge globale, afin de disposer de la "taille appropriée” sur le cluster pour atteindre les deux cibles tout en minimisant les coûts.

Migration

Lorsque les clients exécutant Hadoop décident de déployer vers Oracle Cloud Infrastructure, ils disposent généralement d'un volume important de données à migrer. La majorité de ces données est présente dans HDFS, avec les métadonnées de cluster prises en charge présentes dans une base de données.

La copie de données HDFS directement sur Internet peut être difficile pour plusieurs raisons :

Le volume de données est trop important ou la bande passante disponible est trop contrainte, afin de prendre en charge la copie de données sur réseau dans une période définie.
Les données sont sensibles et la copie sur Internet n'est pas autorisée par la gouvernance ou les exigences réglementaires.
Les ressources de cluster sur site sont limitées et la copie des données a une incidence sur la charge de travail en cours.

Plusieurs approches de la migration des données sont prises en charge. Ils sont définis par le type de données en cours de migration.

Migration des données HDFS

Il existe trois méthodes courantes de copie des données HDFS dans Oracle Cloud Infrastructure :

Copier directement les données d'un cluster on-premise vers Object Storage dans une région Oracle Cloud Infrastructure à l'aide d'un VPN via Internet ou avec FastConnect. Une fois ce processus terminé, un cluster Oracle Cloud Infrastructure peut être réhydraté avec les données d'Object Storage.
Copier directement les données depuis un cluster sur site vers un cluster Oracle Cloud Infrastructure via Internet ou à l'aide de FastConnect.
Copier des données vers une instance Data Transfer Appliance, déployée vers le centre de données client, remplies avec des données, puis envoyées à Oracle et téléchargé vers Object Storage. Un cluster Oracle Cloud Infrastructure peut alors être réhydraté avec ces données.

Les détails techniques sur chacune de ces méthodes sont présentés plus loin dans cette solution.

Migration des métadonnées

Les métadonnées du cluster sont généralement plus petites que les données HDFS et elles existent dans une base de données dans le cluster on-premise.

La migration des métadonnées de cluster dépend de deux facteurs : la distribution Hadoop dans le cluster source et la base de données utilisée pour stocker les métadonnées. Le transfert de ces données est simple et propre à chaque distribution Hadoop.

Cette solution offre des indications sur chaque distribution Hadoop.

Sécurité

La sécurité dans le cloud est particulièrement importante pour Hadoop. Il existe de nombreuses manières de garantir la sécurité du déploiement sur Oracle Cloud Infrastructure.

Voici d'abord certains contrôles de sécurité propres à Oracle Cloud Infrastructure :

Utilisez Identity and Access Management (IAM) pour contrôler qui a accès aux ressources cloud, quel type d'accès au groupe d'utilisateurs et pour quelles ressources spécifiques. Cette architecture peut fournir les résultats suivants :
- Isoler de manière sécurisée les ressources de cloud en fonction de la structure organisationnelle
- Authentifier les utilisateurs pour accéder aux services cloud par le biais d'une interface de navigateur, d'une API REST, d'un SDK ou d'une CLI.
- Autoriser des groupes d'utilisateurs à effectuer des actions sur les ressources cloud appropriées
- Fédération avec les fournisseurs d'identités existants
- Activer un fournisseur de services gérés ou un intégrateur de systèmes (SI) pour gérer les ressources d'infrastructure tout en permettant aux opérateurs d'accéder aux ressources
- Autoriser les instances d'application à effectuer des appels d'API par rapport aux services cloud
Auditez les listes de sécurité pour tous les réseaux du réseau cloud virtuel (VCN). Faites en sorte que ces règles soient aussi restrictives que possible et autorisez uniquement le trafic de confiance dans les sous-réseaux Internet.
Activez les pare-feu hôtes sur des hôtes en contact avec Internet et n'autorisez que le trafic nécessaire.
Envisagez d'utiliser régulièrement l'audit de sécurité.

Le chiffrement est également une bonne option pour les données au repos et les données en mouvement. Tenez compte des ressources suivantes :

Mécanismes de cryptage Cloudera
Hortonworks
- Cryptage HDFS au reste
- Chiffrement en simultané
Chiffrement MapR

Les autres considérations de sécurité propres à Hadoop sont les suivantes :

Déployer des clusters sur des sous-réseaux avec des adresses IP privées, qui présente uniquement les API ou interfaces utilisateur nécessaires pour les sous-réseaux Internet.
Exécuter Hadoop à l'aide de la sécurité du cluster
Utilisez les noeuds de bord pour accéder aux services de cluster via le tunneling SSH. Cela est même plus facile sur Mac ou Linux.
Tirez parti d'Apache Knox pour sécuriser les adresses d'API.
Utiliser le navigateur Apache Sentry ou Cloudera pour l'accès basé sur les rôles aux données et métadonnées de cluster.

Sécurité du réseau

Compte tenu de la nature ouverte de Hadoop et des considérations de sécurité, la plupart des clients préfèrent déployer leur cluster Hadoop dans un sous-réseau privé. L'accès aux services de cluster est alors disponible uniquement via les noeuds de bord, l'équilibrage de charge pour les interfaces utilisateur, les API et les tableaux de bord des services, ou via un accès direct via un VPN FastConnect ou un tunneling SSH via un proxy de bord.

Les sous-réseaux publics augmentent le déploiement du cluster pour les noeuds de bordure et d'utilitaire, qui exécutent les services en réseau Internet (tels que Cloudera Manager ou Ambari). Elle est entièrement facultative. Vous pouvez choisir d'utiliser le VPN FastConnect et d'exécuter l'intégralité de votre déploiement en tant qu'extension de votre topologie réseau on-premise. Cela nécessite seulement un segment IP privé routable par le client, qui est associé au niveau VCN puis fractionné en sous-réseaux appropriés dans Oracle Cloud Infrastructure. L'accès est contrôlé à l'aide de listes de sécurité, qui s'appliquent au niveau du sous-réseau. La meilleure pratique consiste à regrouper les ressources ayant des exigences d'accès similaires dans les mêmes sous-réseaux.

Topologie de sous-réseau

VCN couvre un seul bloc IPv4 CIDR contigu de votre choix. Dans VCN, des sous-réseaux IPv4 individuels peuvent être déployés pour des hôtes de cluster. L'accès à chaque sous-réseau est contrôlé par des listes de sécurité. La sécurité supplémentaire est contrôlée au niveau de l'hôte par les pare-feu.

La pratique recommandée consiste à séparer les ressources de cluster Hadoop en un sous-réseau privé qui n'est pas directement accessible à partir d'Internet. L'accès au cluster doit être contrôlé via des hôtes supplémentaires de sous-réseaux publics et sécurisés à l'aide des règles de liste de sécurité appropriées pour régir le trafic entre les segments de réseau public et privé. Ce modèle fournit la meilleure sécurité pour votre cluster Hadoop.

Les sous-réseaux publics peuvent être utilisés pour les noeuds d'axe (accès utilisateur) et pour tous les services devant exposer une interface utilisateur ou une API (telle que Cloudera Manager ou Ambari) pour un accès externe.
Les sous-réseaux privés doivent être utilisés pour les hôtes du cluster (maître, salarié) et ne sont pas directement accessibles à partir d'Internet. Ils nécessitent plutôt un hôte intermédiaire dans un sous-réseau public pour l'accès, un équilibreur de charge ou un accès direct par VPN, FastConnect ou proxy SSH.

Listes de sécurité

Les listes de sécurité contrôlent le trafic entrant et sortant au niveau du sous-réseau. Pour Hadoop, il est préférable d'avoir un accès bidirectionnel complet entre les sous-réseaux avec des hôtes de cluster pour le trafic TCP et UDP. Les sous-réseaux publics doivent disposer de listes de sécurité très restrictives pour que seuls les ports de confiance (et même les adresses IP source) puissent accéder aux API et aux interfaces utilisateur.

Haute disponibilité

Hadoop propose des méthodes intégrées pour la haute disponibilité et celles-ci ne sont pas couvertes ici. Voici les meilleures pratiques pour tirer parti d'Oracle Cloud Infrastructure for Hadoop pour atteindre HA.

Sélection de région

Chaque région d'Oracle Cloud Infrastructure comprend entre un et trois domaines de disponibilité. Chaque domaine de disponibilité est également composé de trois domaines de pannes. Choisissez une région d'accueil proche de votre organisation et de vos ressources fonctionnelles (comme votre centre de données). La composition de la région que vous choisissez détermine si vous pouvez utiliser un déploiement à un seul domaine disponible ou un déploiement à plusieurs domaines.

Déploiement à un seul domaine

Oracle recommande le déploiement à un seul domaine pour les déploiements Hadoop sur Oracle Cloud Infrastructure. Pour les déploiements MapR, cette architecture est la seule prise en charge. Ce modèle de déploiement est le plus performant d'un point de vue du réseau car le trafic intracluster est contenu dans des segments du réseau local, qui maintient une latence faible et un débit élevé. Les ressources du domaine de disponibilité sont entrelacées entre les domaines de pannes afin d'atteindre la haute disponibilité de l'infrastructure physique.

Un domaine de pannes est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité contient trois domaines de pannes. Les domaines de pannes vous permettent de distribuer vos instances de sorte qu'elles ne se trouvent pas sur le même matériel physique au sein d'un seul domaine de disponibilité. Une panne matérielle ou une maintenance matérielle du calcul affectant un domaine de pannes n'affecte pas les instances des autres domaines de pannes.

Déploiement à plusieurs domaines disponibles

Les déploiements à plusieurs domaines disponibles (couvrant les domaines de disponibilité) sont pris en charge uniquement par Cloudera et Hortonworks, mais ils le sont également via Apache Hadoop.

Tenez compte toutefois des avertissements suivants pour le domaine de disponibilité qui couvre :

La connectivité intracluster doit parcourir les segments WAN, ce qui augmente la latence et réduit le débit optimal. Cela a un impact mesurable sur les performances, en particulier avec les noeuds de travail Bare Metal. Pour les noeuds de salarié de plus petite taille, l'impact sur les performances est moins notable.
Ce modèle n'est pas pris en charge par toutes les régions Oracle Cloud Infrastructure.

Le diagramme suivant illustre l'impact mesuré sur les performances lors de l'utilisation de TeraSort 10-TB dans un domaine de disponibilité unique par rapport à un domaine de disponibilité couvrant un cluster composé de cinq noeuds actifs et de trois noeuds maîtres :

Description de la comparaison - vailability-domain-spanning.png

Description de l'illustration comparison-availability-domain-spanning.png

Le domaine de disponibilité couvrant n'assure pas la redondance supplémentaire des services de cluster dans une même région. Les ressources de cluster peuvent également tirer parti des domaines de pannes dans chaque domaine de disponibilité pour obtenir une “topologie de rack” logique supplémentaire. Chaque domaine de pannes est considéré comme un “rack” pour la sensibilisation aux racks. Les avantages sont illustrés ci-dessous.

Image architecture-multiple-availability-domains.png

Description de l'illustration architecture-multiple-availability-domains.png

Restauration après sinistre

La récupération après sinistre dans Oracle Cloud Infrastructure dépend directement de vos besoins en matière d'objectif de point de récupération (RPO) et d'objectif de délai de récupération (RTO).

Si le RPO ou le RTO est quasiment en temps réel, votre seule option pour Hadoop consiste à créer un cluster de récupération après sinistre dans un autre domaine de disponibilité ou une autre région, puis à répliquer les données entre les clusters de production et de récupération après sinistre. Si les exigences de RPO et RTO sont plus flexibles, nous vous recommandons d'utiliser Object Storage comme cible de sauvegarde pour HDFS et les métadonnées de cluster. Programmez le processus de copie aussi souvent que nécessaire pour atteindre votre cible de RPO, en transmettant les données dans Object Storage à l'aide d'un outil tel que DistCp (copie distribuée). Vous pouvez également sauvegarder les bases de données (Oracle, MySQL) dans des buckets Object Storage ou effectuer une réplication vers des instances de base de données supplémentaires dans d'autres domaines de disponibilité ou régions.

Si les exigences en matière de récupération après sinistre indiquent la géoredondance pour les données qu'une région unique ne peut pas fournir, vous pouvez également copier des données dans Object Storage entre régions. Dans le cas d'un sinistre, envisagez d'utiliser Terraform pour provisionner rapidement des ressources dans un autre domaine de disponibilité (dans la même région ou dans une autre région) et réhydrater le cluster de récupération après sinistre à partir des données dans Object Storage.

Cost Management

De manière détaillée dans le reste de cette solution, il existe plusieurs façons de “définir à droite” les exigences de calcul et de stockage pour réduire les coûts de votre infrastructure. Oracle Cloud Infrastructure dispose d'outils supplémentaires pour vous aider à gérer le coût associé à un déploiement Hadoop :

Vous pouvez utiliser le balisage pour vos déploiements afin de faciliter le suivi de la consommation.
Vous pouvez définir des quotas au niveau du compartiment pour limiter la consommation selon différents secteurs d'activité. Envisagez d'utiliser plusieurs compartiments pour gérer des environnements de production, de qualité et de développement et limiter les quotas selon vos besoins.

L'exploitation de la nature dynamique du cloud est également valable pour les environnements qui n'ont peut-être pas besoin d'être persistants. Si vous utilisez Object Storage en tant que sauvegarde (ou lac de données) pour vos données, il est facile de créer des environnements lorsque vous en avez besoin à l'aide de Terraform, réhydrate HDFS avec des données provenant d'Object Storage et détruisez l'environnement lorsque vous n'en avez plus besoin.

Les environnements de machine virtuelle avec des volumes de blocs peuvent également être mis en pause pour arrêter la facturation Compute, et vous êtes facturé uniquement pour la consommation du stockage.