Planejando e Entendendo Clusters ODH

Antes de criar clusters do Big Data Service, você deve planejar e entender clusters, tipos e formas de instância e perfis de cluster.

Para obter mais informações, consulte:

Planejando o Layout, a Forma e o Armazenamento do Cluster

Antes de iniciar o processo para criar um cluster, planeje o layout do cluster, as formas dos nós e o armazenamento.

Layout do Cluster

Os nós e serviços são organizados de forma diferente em clusters, com base em se o cluster é altamente disponível (HA) e seguro ou não.

Sobre a utilização de clusters HA

Use clusters HA para ambientes de produção. Eles são necessários para resiliência e para minimizar a indisponibilidade.

Nesta release, um cluster deve ser HA e seguro ou nenhum deles.

Tipos de nós

Os tipos de nós são estes:

Os nós principais ou do utilitário incluem os serviços necessários para a operação e o gerenciamento do cluster. Esses nós não armazenam nem processam dados.
Os nós de trabalho armazenam e processam dados. A perda de um nó de trabalho não afeta a operação do cluster, embora possa afetar o desempenho.
Dados do processo de nós de trabalho somente para computação. A perda de um nó de trabalho somente para computação não afeta a operação do cluster, embora possa afetar o desempenho.
Os nós de borda são nós estendidos para o cluster que têm apenas clientes instalados. Você pode instalar pacotes adicionais e executar aplicativos adicionais neste nó em vez de nós worker/compute/master para evitar conflitos de classpath e problemas de recursos com serviços de cluster.

Layout do cluster de alta disponibilidade (HA)

Um cluster de alta disponibilidade tem dois nós principais, dois nós de utilitário, três ou mais nós de trabalho e zero ou mais nós de trabalho somente para computação.


Tipo de nó	Serviços no ODH
Primeiro nó principal	Monitor de Métricas Ambari Cliente HDFS JournalNode do HDFS NameNode do HDFS HDFS ZKFailoverController Cliente Hive Cliente Kerberos Cliente MapReduce2 Cliente Spark3 Spark3 Servidor de Histórico Cliente YARN YARN ResourceManager Servidor ZooKeeper
Segundo nó principal	Monitor de Métricas Ambari Cliente HDFS JournalNode do HDFS NameNode do HDFS HDFS ZKFailoverController Cliente Kerberos Cliente MapReduce2 MapReduce2 Servidor de Histórico Cliente Spark3 Cliente Tez Cliente YARN DNS de Registro do YARN YARN ResourceManager Serviço de Linha do Tempo do YARN V1.5 Servidor ZooKeeper
Primeiro nó do utilitário	Monitor de Métricas Ambari Servidor Ambari Cliente HDFS JournalNode do HDFS Metastore do Hive HiveServer2 Cliente Kerberos Cliente MapReduce2 Servidor Oozie Cliente Spark3 Cliente Tez Cliente YARN Cliente ZooKeeper Servidor ZooKeeper
Segundo nó do utilitário	Coletor de Métricas Ambari Monitor de Métricas Ambari Cliente HDFS Cliente Hive Cliente Kerberos Cliente MapReduce2 Cliente Spark3 Cliente YARN
Nós de trabalho (no mínimo 3)	Monitor de Métricas Ambari HDFS DataNode Cliente HDFS Cliente Hive Cliente Kerberos Cliente MapReduce2 Cliente Oozie Cliente Spark3 Spark3 Servidor Thrift Cliente Tez Cliente YARN YARN NodeManager Cliente ZooKeeper
Nós de trabalho somente para computação	Monitor de Métricas Ambari Cliente HDFS Cliente Hive Cliente Kerberos Cliente MapReduce2 Cliente Oozie Cliente Spark3 Cliente Tez Cliente YARN YARN NodeManager Cliente ZooKeeper
Nós de borda	Monitor de Métricas Ambari Cliente HDFS Cliente Hive Cliente Kerberos Cliente MapReduce2 Cliente Oozie Cliente Spark3 Cliente Tez Cliente YARN Cliente ZooKeeper

Layout de Cluster Mínimo (nonHA)

Um cluster sem alta disponibilidade tem um nó principal, um nó de utilitário, três ou mais nós de trabalho e zero ou mais nós de trabalho somente para computação.


Tipo de nó	Serviços no ODH
Nó principal	Monitor de Métricas Ambari Cliente HDFS NameNode do HDFS Cliente Hive Cliente MapReduce2 Cliente Spark3 Spark3 Servidor de Histórico Cliente YARN DNS de Registro do YARN YARN ResourceManager Servidor ZooKeeper
Nó do utilitário	Coletor de Métricas Ambari Monitor de Métricas Ambari Servidor Ambari Cliente HDFS NameNode Secundário do HDFS Metastore do Hive HiveServer2 Cliente MapReduce2 MapReduce2 Servidor de Histórico Servidor Oozie Cliente Spark3 Cliente Tez Cliente YARN Serviço de Linha do Tempo do YARN V1.5 Cliente ZooKeeper Servidor ZooKeeper
Nós de trabalho	Monitor de Métricas Ambari HDFS DataNode Cliente HDFS Cliente Hive Cliente MapReduce2 Cliente Oozie Cliente Spark3 Spark3 Servidor Thrift Cliente Tez Cliente YARN YARN NodeManager Cliente ZooKeeper Servidor ZooKeeper
Nós de trabalho somente para computação	Monitor de Métricas Ambari Cliente HDFS Cliente Hive Cliente MapReduce2 Cliente Oozie Cliente Spark3 Cliente Tez Cliente YARN YARN NodeManager Cliente ZooKeeper
Nós de borda	Cliente HDFS Cliente Hive Cliente MapReduce2 Cliente Oozie Cliente Spark3 Cliente Tez Cliente YARN Cliente ZooKeeper

Formas de Nó Suportadas

A forma do nó descreve os recursos de computação alocados para o nó.

As formas usadas para nós principais/do utilitário e nós de trabalho podem ser diferentes. Mas todos os nós principais/do utilitário devem ter a mesma forma e todos os nós de trabalho devem ter a mesma forma.

A tabela a seguir mostra quais formas podem ser usadas para os diferentes tipos de nó. Consulte Formas de Computação para obter informações mais detalhadas.

Para obter uma lista dos recursos fornecidos por cada forma, consulte:


Tipo de Nó	Formas Disponíveis	Número Necessário de VNICs (Placas de Interface de Rede Virtual)
Principal ou utilitário	VM.Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flex VM.Standard.E4. Flex * VM.Standard3. Flex* VM.Optimized3. Flex* VM.DenseIO.E4. Flex* VM.DenseIO.E5. Flexível* 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*	No mínimo 3 Usadas para a sub-rede do cluster, a sub-rede de acesso DP e a sub-rede do cliente ^*Especifique no mínimo 3 OCPU e 32 GB de memória.
Trabalho	VM.Standard2.1^* VM.Standard2.2^* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flex VM.Standard.E4. Flex * VM.Standard3. Flex* VM.Optimized3. Flex* VM.DenseIO.E4. Flex* VM.DenseIO.E5. Flexível* 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*	No mínimo 2 Usadas para a sub-rede do cluster e a sua sub-rede
Trabalho somente para computação	VM.Standard2.1^* VM.Standard2.2^* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flex VM.Standard.E4. Flex * VM.Standard3. Flex* VM.Optimized3. Flex* VM.DenseIO.E4. Flex* VM.DenseIO.E5. Flexível* 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*	No mínimo 2 Usadas para a sub-rede do cluster e a sua sub-rede
Edge	VM.Standard2.1^* VM.Standard2.2^* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flex VM.Standard.E4. Flex * VM.Standard3. Flex* VM.Optimized3. Flex* VM.DenseIO.E4. Flex* VM.DenseIO.E5. Flexível* 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*	No mínimo 2 Usadas para a sub-rede do cluster e a sub-rede do cliente Observação: Como o nó Edge é específico para casos de uso do aplicativo cliente, escolha a forma conforme exigido pelo aplicativo.

^*Lembre-se de que as formas VM.Standard2.1 e VM.Standard2.2 são pequenas e não suportam a execução de cargas de trabalho grandes. Para VM.Standard.E4. Flex, VM.Standard3. Flex, VM.Standard.E5. Flex e VM.Optimized3. No Flex, especifique no mínimo 1 OCPU e 16 GB de memória.

Nem todas as formas estão disponíveis por padrão. Para ver quais formas estão disponíveis por padrão por meio da Console do Cloud, consulte Localizando Limites de Tenancy. Para enviar uma solicitação para aumentar os limites de serviço, consulte Solicitando um Aumento do Limite de Serviço.

Formas de Nó de Armazenamento em Blocos

Os nós baseados em formas de VM padrão usam o armazenamento em blocos anexado à rede.

Observação

Não há suporte para o armazenamento em blocos em nós com base nas formas DenseIO e HPC.

Todos os nós têm um volume de inicialização de 150 GB.


Opção	Limites/Diretrizes
Armazenamento em blocos inicial mínimo	150 GB
Armazenamento em blocos inicial padrão *	150 GB
Armazenamento em blocos adicional mínimo	150 GB
Armazenamento em bloco adicional padrão *	1 TB
Etapa incremental para armazenamento em blocos (inicial e adicional)	50 GB
Armazenamento em blocos máximo para um único nó	48 TB O total de 48 TB resulta de 12 volumes de 4 TB cada. Se você adicionar armazenamento em blocos várias vezes, o máximo permanecerá 48 TB, mas poderá ser distribuído entre mais de 12 volumes.
Tamanho máximo do volume em blocos	4 TB Se você especificar o máximo de 48 TB, serão criadas 12 unidades de 4 TB cada. Se você especificar um número menor, serão criados dispositivos suficientes de 4 TB para esse valor, e mais dispositivos serão criados à medida que você adicionar mais armazenamento.

Não é possível adicionar mais armazenamento em blocos aos nós principais ou do utilitário. Portanto, os números a seguir mostram apenas tamanhos iniciais.


Opção	Limites/Diretrizes
Armazenamento em blocos inicial mínimo	150 GB
Armazenamento em blocos inicial padrão	1 TB
Armazenamento em blocos adicional mínimo	150 GB
Armazenamento de blocos adicional padrão	1 TB
Etapa incremental para armazenamento em blocos (inicial e adicional)	50 GB
Armazenamento em blocos máximo para um único nó	32 TB
Tamanho máximo do volume em blocos	32 TB
MySQL posicionamento	Para nós do utilitário, mova `/var/lib/mysql` para `/u01` e crie um link simbólico. Isso impede o preenchimento do volume de inicialização.


Opção	Diretrizes
Armazenamento em blocos inicial padrão	2 TB
Armazenamento em blocos inicial mínimo	150 GB

O armazenamento do servidor de consulta é usado para o espaço da tabela temporária para executar operações JOIN e GROUP BY. Recomenda-se 2 TB para processamento típico. Para ambientes pequenos, por exemplo, desenvolvimento, esse número pode ser ajustado para baixo.

Para obter melhor desempenho, considere estes fatores:

Throughput de E/S
A rede entre o dispositivo de computação e o dispositivo de armazenamento em blocos.

Consulte Desempenho do Serviço Block Volume na documentação do Oracle Cloud Infrastructure.

A tabela a seguir descreve como o Big Data Service aloca armazenamento de volumes em blocos para nós de diferentes tamanhos.


Quais	Quantidade
Alocação de volume inicial para nós principais e nós do utilitário	1 volume grande
Alocação de volume para armazenamento em blocos adicional para nós principais e do utilitário	1 volume grande
Alocação de volume inicial para nós de trabalho.	Armazenamento: Menos de 12 TB. Tamanho do volume: 1 TB O último volume pode ser menor que 1 TB. Armazenamento: 12 TB a 48 TB. Tamanho do volume: Divida igualmente em 12 volumes, cada um com pelo menos 1 TB. Armazenamento: Maior que 48 TB. Tamanho do volume: Não permitido.
Alocação de volume para armazenamento em blocos adicional de nós de trabalho	O número mínimo de volumes que podem acomodar o tamanho do armazenamento, com um tamanho de volume máximo de 4 TB por volume. (O último volume pode ser menor que 4 TB.)

Recomendamos que você use nós de borda para preparação.

Noções Básicas de Tipos e Formas de Instância

Os nós do cluster do Big Data Service são executados em instâncias de computação (servidores) do Oracle Cloud Infrastructure.

Ao criar um cluster, você escolhe um tipo de instância que determina se a instância é executada diretamente na instância bare metal do hardware ou em um ambiente virtualizado. Você também escolhe uma forma que configura os recursos designados à instância.

Sobre Tipos de Instância

Bare metal: Uma instância de computação bare metal usa um servidor físico dedicado para o nó, para um melhor desempenho e melhor isolamento.
Máquina Virtual (VM): Por meio da virtualização, uma instância de computação de VM pode hospedar vários nós isolados executados em uma única máquina bare metal física. As instâncias de VM são menos dispendiosas que as instâncias bare metal e são úteis para criar clusters menos exigentes, que não exijam o desempenho e os recursos (CPU, memória, largura de banda de rede, armazenamento) de uma máquina física inteira para cada nó.

As instâncias de VM são executadas no mesmo hardware das instâncias bare metal, com o mesmo firmware, pilha de software e infraestrutura de rede.

Para obter mais informações sobre instâncias de computação, consulte Visão Geral do Serviço Compute.

Sobre Formas

A forma determina o número de CPUs, a quantidade de memória e outros recursos alocados para a instância de computação que hospeda o nó do cluster. Consulte Planejando o Layout, a Forma e o Armazenamento do Cluster na documentação do Oracle Cloud Infrastructure para obter as formas disponíveis.

As formas dos nós principais e dos nós de trabalho do Big Data Service não precisam coincidir. Mas as formas de todos os nós principais devem corresponder umas às outras e as formas de todos os nós de trabalho devem corresponder umas às outras.

Noções Básicas de Perfis de Cluster

Os perfis de cluster permitem que você crie clusters ideais para uma carga de trabalho ou tecnologia específica. Depois de criar um cluster com um perfil de cluster específico, mais serviços do Hadoop podem ser adicionados ao cluster.

Tipos de Perfil do Cluster

O Oracle Big Data Service permite que você crie clusters para vários tipos de perfil de cluster.


Perfil do cluster	Componentes (seguro e altamente disponível)	Componentes
HADOOP_EXTENDED¹	Hive, Spark, HDFS, Yarn, ZooKeeper, MapReduce2, Ambari Metrics, Ranger, Hue, Oozie, Tez	Hive, Spark, HDFS, Yarn, ZooKeeper, MapReduce2, Ambari Metrics, Hue, Oozie, Tez
HADOOP	HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Ranger, Hue	HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Hue
HIVE	Hive, HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Ranger, Hue, Tez	Hive, HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Hue, Tez
ESCARREGAR	Spark, Hive², HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Ranger, Hue	Spark, Hive², HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Hue ²
HBASE	HBase, HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Ranger, Hue	HBase, HDFS, Yarn, ZooKeeper, MapReduce2, Métricas do Ambari, Hue
TRINO	Trino, Hive³, HDFS, ZooKeeper, Métricas do Ambari, Ranger, Hue	Trino, Hive³, HDFS, ZooKeeper, Métricas do Ambari, Hue
KAFKA	Kafka Broker, HDFS, ZooKeeper, Métricas do Ambari, Ranger, Hue	Kafka Broker, HDFS, ZooKeeper, Métricas do Ambari, Hue

¹ HADOOP_EXTENDED consiste em componentes que você criou clusters antes que os perfis do cluster estivessem disponíveis.

²O componente de metastore do Hive do serviço Hive é usado para gerenciar os metadados no Spark.

³O componente de metastore do Hive do serviço Hive é usado para gerenciar as entidades de metadados do Hive no Trino.

Versões do Apache Hadoop em Perfis de Cluster

A tabela a seguir lista as versões do componente do Hadoop incluídas em perfis de cluster correspondentes à versão do ODH.

ODH 1.x


Perfil do cluster	Versão
HADOOP_EXTENDED	HDFS 3.1, Hive 3.1, Spark 3.0.2
HADOOP	HDFS 3.1
HIVE	Hive 3.1
ESCARREGAR	Spark 3.0.2
HBASE	HBase 2.2
TRINO	Trino 360
KAFKA	Kafka 2.1.0

ODH 2.x


Perfil do cluster	Versão
HADOOP_EXTENDED	HDFS 3.3, Hive 3.1, Spark 3.2
HADOOP	HDFS 3.3
HIVE	Hive 3.1
ESCARREGAR	Spark 3.2
HBASE	HBase 2.2
TRINO	Trino 389

Documentação do Oracle Cloud Infrastructure