Planification et présentation des clusters ODH

Avant de créer des clusters Big Data Service, vous devez planifier et comprendre les clusters, les types et les formes d'instance, ainsi que les profils de cluster.

Pour plus d'informations, reportez-vous aux rubriques suivantes :

Planification de la disposition, de la forme et du stockage du cluster

Avant de lancer le processus de création d'un cluster, vous devez planifier sa structure, la forme de ses noeuds et son stockage.

Disposition du cluster

Les noeuds et les services sont organisés différemment sur les clusters, selon que le cluster est hautement disponible et sécurisé ou non.

A propos de l'utilisation de clusters hautement disponibles

Utilisez des clusters hautement disponibles pour les environnements de production. Ils sont requis à des fins de résilience et de réduction du temps d'inactivité.

Dans cette version, un cluster doit être à la fois hautement disponible et sécurisé, ou aucun des deux.

Types de noeud

Les types de noeud sont les suivants :

  • Les noeuds maître ou utilitaire comprennent les services requis pour le fonctionnement et la gestion du cluster. Ces noeuds ne stockent ni ne traitent de données.
  • Les noeuds de processus actif stockent et traitent les données. La perte d'un noeud de processus actif n'a aucune incidence sur le fonctionnement du cluster, bien qu'elle puisse avoir un impact sur ses performances.
  • Les noeuds de processus actif de calcul uniquement traitent les données. La perte d'un noeud de processus actif de calcul uniquement n'a aucune incidence sur le fonctionnement du cluster, bien qu'elle puisse avoir un impact sur ses performances.
  • Les noeuds en périphérie sont des noeuds étendus au cluster sur lesquels seuls des clients sont installés. Vous pouvez installer des packages supplémentaires et exécuter des applications supplémentaires dans ce noeud plutôt que des noeuds de processus actif/de calcul/maître pour éviter les conflits de classpath et les problèmes de ressources avec les services de cluster.

Disposition d'un cluster à haute disponibilité

Un cluster hautement disponible comporte deux noeuds maître, deux noeuds utilitaire, trois noeuds de processus actif ou plus, et aucun, un ou plusieurs noeuds de processus actif de calcul uniquement.

Type de noeud Services sur ODH
Premier noeud maître
  • Moniteur de mesures Ambari
  • Client HDFS
  • HDFS JournalNode
  • HDFS NameNode
  • HDFS ZKFailoverController
  • Client Hive
  • Client Kerberos
  • Client MapReduce2
  • Client Spark3
  • Spark3 Serveur d'historique
  • Client YARN
  • YARN ResourceManager
  • Serveur ZooKeeper
Deuxième noeud maître
  • Moniteur de mesures Ambari
  • Client HDFS
  • HDFS JournalNode
  • HDFS NameNode
  • HDFS ZKFailoverController
  • Client Kerberos
  • Client MapReduce2
  • MapReduce2 Serveur d'historique
  • Client Spark3
  • Client Tez
  • Client YARN
  • DNS de registre YARN
  • YARN ResourceManager
  • Service de chronologie YARN V1.5
  • Serveur ZooKeeper
Premier noeud utilitaire
  • Moniteur de mesures Ambari
  • Serveur Ambari
  • Client HDFS
  • HDFS JournalNode
  • Métastore Hive
  • HiveServer2
  • Client Kerberos
  • Client MapReduce2
  • Serveur Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • Client ZooKeeper
  • Serveur ZooKeeper
Second noeud utilitaire
  • Collecteur de mesures Ambari
  • Moniteur de mesures Ambari
  • Client HDFS
  • Client Hive
  • Client Kerberos
  • Client MapReduce2
  • Client Spark3
  • Client YARN
noeuds de processus actif (au moins)
  • Moniteur de mesures Ambari
  • HDFS DataNode
  • Client HDFS
  • Client Hive
  • Client Kerberos
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Spark3 Serveur Thrift
  • Client Tez
  • Client YARN
  • YARN NodeManager
  • Client ZooKeeper
Noeuds de processus actif de calcul uniquement
  • Moniteur de mesures Ambari
  • Client HDFS
  • Client Hive
  • Client Kerberos
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • YARN NodeManager
  • Client ZooKeeper
noeuds d'axe
  • Moniteur de mesures Ambari
  • Client HDFS
  • Client Hive
  • Client Kerberos
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • Client ZooKeeper

Disposition minimale (nonHA) du cluster

Un cluster non haute disponibilité comporte un noeud maître, un noeud utilitaire, trois noeuds de processus actif ou plus, et aucun, un ou plusieurs noeuds de processus actif de calcul uniquement.

Type de noeud Services sur ODH
noeud maître
  • Moniteur de mesures Ambari
  • Client HDFS
  • HDFS NameNode
  • Client Hive
  • Client MapReduce2
  • Client Spark3
  • Spark3 Serveur d'historique
  • Client YARN
  • DNS de registre YARN
  • YARN ResourceManager
  • Serveur ZooKeeper
Noeud utilitaire
  • Collecteur de mesures Ambari
  • Moniteur de mesures Ambari
  • Serveur Ambari
  • Client HDFS
  • Secondaire HDFS NameNode
  • Métastore Hive
  • HiveServer2
  • Client MapReduce2
  • MapReduce2 Serveur d'historique
  • Serveur Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • Service de chronologie YARN V1.5
  • Client ZooKeeper
  • Serveur ZooKeeper
noeuds de processus actif
  • Moniteur de mesures Ambari
  • HDFS DataNode
  • Client HDFS
  • Client Hive
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Spark3 Serveur Thrift
  • Client Tez
  • Client YARN
  • YARN NodeManager
  • Client ZooKeeper
  • Serveur ZooKeeper
Noeuds de processus actif de calcul uniquement
  • Moniteur de mesures Ambari
  • Client HDFS
  • Client Hive
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • YARN NodeManager
  • Client ZooKeeper
noeuds d'axe
  • Client HDFS
  • Client Hive
  • Client MapReduce2
  • Client Oozie
  • Client Spark3
  • Client Tez
  • Client YARN
  • Client ZooKeeper
Formes de noeud prises en charge

La forme de noeud décrit les ressources de calcul allouées au noeud.

Les formes utilisées pour les noeuds maître/utilitaire et les noeuds de processus actif peuvent être différentes. Toutefois, tous les noeuds maître/utilitaire doivent avoir la même forme, tout comme l'ensemble des noeuds de processus actif.

Le tableau suivant indique les formes pouvant être utilisées pour les différents types de noeud. Pour plus d'informations, reportez-vous à Formes de calcul.

Pour obtenir la liste des ressources fournies par chaque forme, reportez-vous aux sections suivantes :

Type de noeud Formes disponibles Nombre requis de cartes d'interface réseau virtuelles
Maître ou utilitaire

VM.Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5Champ flexible

VM.Standard.E4. Champ flexible *

VM.Standard3. Champ flexible*

VM.Optimized3Champ flexible*

VM.DenseIO.E4. Champ flexible*

VM.DenseIO.E5. Champ flexible*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseIO2.52

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

3 valeur minimale

Utilisées pour le sous-réseau du cluster, le sous-réseau d'accès au plan de données et le sous-réseau du client

* vous devez indiquer au moins 3 OCPU et 32 Go de mémoire.

Processus actif

VM.Standard2.1*

VM.Standard2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5Champ flexible

VM.Standard.E4. Champ flexible *

VM.Standard3. Champ flexible*

VM.Optimized3Champ flexible*

VM.DenseIO.E4. Champ flexible*

VM.DenseIO.E5. Champ flexible*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52.

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

2 valeur minimale

Utilisées pour le sous-réseau du cluster et le sous-réseau

Processus actif de calcul uniquement

VM.Standard2.1*

VM.Standard2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5Champ flexible

VM.Standard.E4. Champ flexible *

VM.Standard3. Champ flexible*

VM.Optimized3Champ flexible*

VM.DenseIO.E4. Champ flexible*

VM.DenseIO.E5. Champ flexible*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52.

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

2 valeur minimale

Utilisées pour le sous-réseau du cluster et le sous-réseau

Bordure

VM.Standard2.1*

VM.Standard2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5Champ flexible

VM.Standard.E4. Champ flexible *

VM.Standard3. Champ flexible*

VM.Optimized3Champ flexible*

VM.DenseIO.E4. Champ flexible*

VM.DenseIO.E5. Champ flexible*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52.

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

2 valeur minimale

Utilisées pour le sous-réseau du cluster et le sous-réseau du client

Remarque : le noeud Edge étant spécifique aux cas d'utilisation d'application client, choisissez la forme requise par l'application.

* VM.Standard2.1 et VM.Standard2.2 sont de petites formes qui ne prennent pas en charge l'exécution de charges globales volumineuses. Pour VM.Standard.E4. Champ flexible, VM.Standard3. Champ flexible, VM.Standard.E5. Flex et VM.Optimized3. Flex vous devez indiquer au moins 1 OCPU et 16 Go de mémoire.

Les formes ne sont pas toutes disponibles par défaut. Pour connaître les formes disponibles par défaut via la console cloud, reportez-vous à Recherche de limites de location. Pour soumettre une demande d'augmentation des limites de service, reportez-vous à Demande d'augmentation de limite de service.

Formes de noeud de stockage par bloc

Les noeuds reposant sur des formes de machine virtuelle standard utilisent un stockage de blocs attaché au réseau.

Remarque

Le stockage de blocs n'est pas pris en charge pour les noeuds reposant sur des formes DenseIO et HPC.

Tous les noeuds disposent d'un volume d'initialisation de 150 Go.

Option Limites/Consignes
Stockage de blocs initial minimal 150 GB
Stockage de blocs initial par défaut* 150 GB
Stockage de blocs supplémentaire minimal 150 GB
Stockage de blocs supplémentaire par défaut* 1 To
Palier d'incrémentation du stockage de blocs (initial et supplémentaire) 50 Go
Stockage de blocs maximal pour un seul noeud

48 To

La quantité totale de 48 To correspond à 12 volumes de 4 To chacun.

Si vous ajoutez du stockage de blocs plusieurs fois, le stockage maximal reste de 48 To, mais il peut être réparti sur plus de 12 volumes.

Taille maximale de volume de blocs

4 To

Si vous indiquez un stockage maximal de 48 To, 12 lecteurs de 4 To chacun sont créés.

Si vous indiquez un nombre inférieur, un nombre suffisant de lecteurs de 4 To sont créés. Des lecteurs supplémentaires sont créés lorsque vous ajoutez du stockage.

Vous ne pouvez pas ajouter davantage de stockage de blocs aux noeuds maître ou utilitaire. Par conséquent, les figures suivantes montrent uniquement les tailles initiales.

Option Limites/Consignes
Stockage de blocs initial minimal 150 GB
Stockage de blocs initial par défaut 1 To
Stockage de blocs supplémentaire minimal 150 GB
Stockage de blocs supplémentaire par défaut 1 To
Palier d'incrémentation du stockage de blocs (initial et supplémentaire) 50 Go
Stockage de blocs maximal pour un seul noeud 32 To
Taille maximale de volume de blocs 32 To
Position de MySQL Pour les noeuds utilitaire, déplacez /var/lib/mysql vers /u01 et créez un lien symbolique. Cela évite de remplir le volume d'initialisation.
Option Règles
Stockage de blocs initial par défaut 2 To
Stockage de blocs initial minimal 150 GB

Le stockage du serveur de requête est utilisé pour le tablespace temporaire afin d'effectuer des opérations JOIN et GROUP BY volumineuses. Un stockage de 2 To est recommandé pour les traitements standard. Pour les environnements de petite taille, par exemple ceux de développement, ce nombre peut être réduit.

Pour obtenir des performances optimales, tenez compte des facteurs suivants :

  • Débit d'E/S
  • Configuration réseau entre le dispositif de calcul et le dispositif de stockage de blocs.

Reportez-vous à Performances de Block Volume dans la documentation Oracle Cloud Infrastructure.

Le tableau suivant explique comment Big Data Service affecte du stockage de volume de blocs pour des noeuds de différentes tailles.

Eléments concernés Montant
Allocation de volume initiale pour les noeuds maître/utilitaire 1 volume de grande taille
Allocation de volume pour du stockage de blocs supplémentaire destiné à des noeuds maître/utilitaire 1 volume de grande taille
Allocation de volume initiale pour les noeuds de processus actif
  • Stockage : inférieur à 12 To.

    Taille du volume : 1 To. Le dernier volume peut être inférieur à 1 To.

  • Stockage : entre 12 et 48 To.

    Taille de volume : répartition égale en 12 volumes d'au moins 1 To chacun.

  • Stockage : supérieur à 48 To.

    Taille de volume : non autorisé.

Allocation de volume pour du stockage de blocs supplémentaire destiné à des noeuds de processus actif

Nombre minimal de volumes pouvant contenir la taille de stockage, avec une taille de volume maximale de 4 To par volume. (Le dernier volume peut être inférieur à 4 To.)

Nous vous recommandons d'utiliser des noeuds d'axe pour la préparation.

Présentation des formes et types d'instance

Les noeuds de cluster Big Data Service sont exécutés dans des instances de calcul (serveurs) Oracle Cloud Infrastructure.

Lorsque vous créez un cluster, vous devez choisir un type d'instance, qui détermine si l'instance est exécutée directement sur l'instance Bare Metal du matériel ou dans un environnement virtuel. Vous devez également choisir une forme, qui configure les ressources affectées à l'instance.

A propos des types d'instance
  • Bare Metal : une instance de calcul bare metal utilise un serveur physique dédié pour le noeud afin d'obtenir des performances optimales et un isolement le plus fort.

  • Machine virtuelle : grâce à la virtualisation, une instance de calcul de machine virtuelle peut héberger plusieurs noeuds isolés exécutés sur une même machine Bare Metal physique. Les instances de machine virtuelle sont moins coûteuses que les instances Bare Metal. Elles sont adaptées à la création de clusters moins exigeants qui ne nécessitent pas les performances et les ressources (UC, mémoire, bande passante réseau, stockage) d'une machine physique complète pour chaque noeud.

Les instances de machine virtuelle sont exécutées sur le même matériel que les instances Bare Metal : le microprogramme, la pile logicielle et l'infrastructure réseau sont identiques.

Pour plus d'informations sur les instances de calcul, reportez-vous à Présentation de Compute.

A propos des formes

La forme détermine le nombre d'UC, la quantité de mémoire et les autres ressources alloués à l'instance de calcul qui héberge le noeud de cluster. Reportez-vous à Planification de la disposition, de la forme et du stockage du cluster dans la documentation Oracle Cloud Infrastructure pour connaître les formes disponibles.

Les formes des noeuds de processus actif et des noeuds maître Big Data Service ne doivent pas nécessairement correspondre. Toutefois, les formes de tous les noeuds maître doivent correspondre entre elles, ainsi que celles de tous les noeuds de processus actif.

Présentation des profils de cluster

Les profils de cluster permettent de créer des clusters optimaux pour une charge globale ou une technologie spécifique. Après avoir créé un cluster avec un profil de cluster spécifique, vous pouvez ajouter d'autres services Hadoop au cluster.

Types de profil de cluster

Oracle Big Data Service vous permet de créer des clusters pour de nombreux types de profil de cluster.

Profil du cluster Composants (sécurité et haute disponibilité) Composants
HADOOP_EXTENDED1 Hive, Spark, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Ranger, Hue, Oozie, Tez Hive, Spark, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Hue, Oozie, Tez
HADOOP HDFS, fil, ZooKeeper, MapReduce2, mesures Ambari, Ranger, teinte HDFS, fil, ZooKeeper, MapReduce2, mesures Ambari, teinte
VIH Hive, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Ranger, Hue, Tez Hive, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Hue, Tez
SPARK Spark, Hive2, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Ranger, Teinte Spark, Hive2, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Teinte 2
HBASE HBase, HDFS, Yarn, ZooKeeper, MapReduce2, Mesures Ambari, Ranger, Teinte HBase, HDFS, Yarn, ZooKeeper, MapReduce2, mesures Ambari, Teinte
TRINO Trino, Hive3, HDFS, ZooKeeper, mesures Ambari, Ranger, Teinte Trino, Hive3, HDFS, ZooKeeper, mesures Ambari, Teinte
KAFKA Kafka Broker, HDFS, ZooKeeper, mesures Ambari, Ranger, Teinte Broker Kafka, HDFS, ZooKeeper, mesures Ambari, Teinte

1 HADOOP_EXTENDED est composé de composants que vous avez créés des clusters avant que les profils de cluster ne soient disponibles.

2Le composant de metastore Hive du service Hive est utilisé pour gérer les métadonnées dans Spark.

3Le composant de metastore Hive du service Hive est utilisé pour gérer les entités de métadonnées Hive dans Trino.

Versions d'Apache Hadoop dans les profils de cluster

Le tableau suivant répertorie les versions de composant Hadoop incluses dans les profils de cluster correspondant à la version ODH.

ODH 1.x

Profil du cluster Version
HADOOP_EXTENDED HDFS 3.1, Hive 3.1, Spark 3.0.2
HADOOP HDFS 3.1
VIH Hive 3.1
SPARK Spark 3.0.2
HBASE HBase 2.2
TRINO Trino 360
KAFKA Kafka 2.1.0

ODH 2.x

Profil du cluster Version
HADOOP_EXTENDED HDFS 3.3, Hive 3.1, Spark 3.2
HADOOP HDFS 3.3
VIH Hive 3.1
SPARK Spark 3.2
HBASE HBase 2.2
TRINO Trino 389