Considerações sobre Desempenho e Forma
Há considerações significativas sobre o preço e o desempenho da execução do Hadoop no Oracle Cloud Infrastructure. Você também deve considerar como seus requisitos afetam as formas de implantação.
Análise Comparativa
A Oracle Cloud Infrastructure oferece vantagens em termos de desempenho e custo para empresas interessadas em executar clusters Hadoop no Oracle Cloud.
O TeraSort é um benchmark comum para Hadoop porque utiliza todos os elementos do cluster (computação, memória, armazenamento, rede) para gerar, mapear/reduzir e validar um conjunto de dados aleatório.
Um cluster normalizado de análise comparativa do Oracle Cloud Infrastructure em 300 OCPU e volumes em blocos usados para armazenamento HDFS. Essa análise específica descobriu que o Oracle Cloud Infrastructure foi executado três vezes mais rápido e fornecido em um custo inferior a 80% do que uma implantação compensível na nuvem do concorrente.
O gráfico a seguir demonstra o desempenho geral de várias formas Oracle Cloud Infrastructure ao executar esse 10TB TeraSort no tamanho de cluster normalizado:
Descrição da ilustração comparison-terasort-phase-cpu.png
O Oracle Cloud Infrastructure fornece instâncias de computação bare metal padrão com CPUs Intel e AMD, bem como uma opção HPC especializada. Conforme o gráfico mostra, os clusters HPC especializados foram executados mais rapidamente do que os equivalentes Intel e AMD, mesmo que essas instâncias tenham contagens de núcleo inferiores. Este resultado ocorreu principalmente porque este cluster usa mais nós para alcançar a mesma contagem de OCPU normalizada, o que afeta diretamente o throughput de agregação HDFS geral, aumentando o desempenho.
As configurações do HPC também se beneficiam de um recurso de rede 100-GBps, o que permite uma transferência mais rápida de dados entre clusters.
A figura a seguir compara o desempenho de colaboradores baseados em VMs com volumes em blocos e o bare metal NVMe, executando a Cloudera e normalizados como 10 nós de trabalhadores no cluster:
Descrição da ilustração comparison-terasort-vm-bm-performance.png
O ganho de desempenho de duplicar o tamanho da VM do trabalhador de 8 a 16 núcleos está prestes duas vezes mais eficiente, o que faz sentido porque o throughput da rede da VM é um compartilhamento fracionário da NIC física subjacente. As vantagens do bare metal com NVMe local também são aparentes. O cluster aproveita a alta velocidade do armazenamento NVMe local, combinado com a interface de rede 25-Gbps.
A decisão de quais formas de aproveitar a computação em um cluster Hadoop é consistente entre Hadoop ISVs.
Seleção da Instância de Computação
Esta seção fornece as melhores práticas ao selecionar uma forma para cada função do nó.
Nós Mestres
Os nós mestres são aplicáveis apenas às distribuições Cloudera, Hortonworks e Apache Hadoop. Por padrão, o MapR não segrega os serviços de cluster dos nós do colaborador. Na prática, a Oracle recomenda o uso de uma boa densidade de memória nos nós mestre para suportar o overhead do gerenciamento de cluster e serviço. Os nós mestres executam os serviços Zookeeper, NameNode, JournalNode, Resource Manager, HBase, Spark e cluster management (Cloudera Manager e Ambari).
- Forma mínima: VM.Standard2.8
- Forma recomendada: VM.Standard2.24
Nós do Worker
Os nós worker são consistentes entre todos os Hadoop ISVs e também com o Apache. Dimensione a forma para o nó do colaborador conforme apropriado para atender aos requisitos de carga de trabalho. Isso é aplicável aos requisitos de computação e memória porque muitos clientes estão procurando a memória agregada a ser usada com cargas de trabalho baseadas em disco. As cargas de trabalho de mapa tradicional também se beneficiam de um alcance de memória aumentada nos nós do colaborador.
- Forma mínima: VM.Standard2.8
- Forma recomendada: BM.DenseIO2.52
Nós de Suporte
A infraestrutura de suporte inclui nós de borda ou outros nós que podem estar executando serviços de cluster auxiliares ou código de aplicação personalizada. Os requisitos desses nós variam, dependendo da escala e do caso de uso. Para nós de borda, recomendamos um tamanho mínimo do VM.Standard2.2. Ampliar isso dependendo do número de usuários por nó de borda. Recomendamos vários nós de borda para HA entre domínios de falha e para criar vários caminhos para que os usuários interajam com o cluster.
Considerações de Rede
O Hadoop é muito grande dependendo da rede do tráfego entre clusters. Assim, as formas que você escolher para implantar para cada atribuição na topologia do cluster têm impacto direto sobre a conectividade entre clusters.
Ao usar configurações bare metal, os hosts de computação podem usar placas de interface de rede virtual (VNICs) completas de 25-GB. As configurações de VM são escalonadas em relação ao seu tamanho de computação.
Quando você usa volumes em blocos para capacidade HDFS, lembre-se de que o tráfego de E/S de um volume em blocos compartilha a mesma VNIC que o tráfego da aplicação (por padrão). Uma forma de otimizar isso ao usar configurações bare metal é criar uma VNIC secundária a ser usada para conectividade de cluster, na segunda interface física. Isso reserva a VNIC principal apenas para o tráfego de volume em blocos, otimizando assim a utilização da rede.
O diagrama a seguir demonstra este conceito:
Descrição da ilustração architecture-vnic.png
Ao usar volumes em blocos, também considere que a agregação de E/S HDFS está diretamente relacionada à quantidade e ao tamanho dos volumes em blocos associados a cada nó do colaborador. Para atingir a capacidade HDFS necessária, a Oracle recomenda escalar um número maior de volumes por colaborador, em vez de um número pequeno de volumes maiores.
Considerações de Armazenamento
Para implantações do Hadoop, dois tipos de armazenamento podem ser usados para capacidade HDFS: formas do DenseIO que têm o NVMe local e volumes em blocos. Para implantações do MapR, um único tipo de armazenamento deve ser escolhido para nós do colaborador (homogêneo), a menos que você tenha licenciamento para a Camada de Dados. Outros Hadoop ISVs suportam armazenamento heterogêneo (misturando o DenseIO NVMe e volumes em blocos) sem custos adicionais de licenciamento.
Configurações de Armazenamento Suportadas pelo Fornecedor
A Cloudera e o Hortonworks suportam todas as formas de armazenamento no Oracle Cloud Infrastructure para uso com o Hadoop:
- NVMe Local nas configurações do DenseIO
- Volumes em blocos
- Armazenamento de Objetos (Usando a compatibilidade S3)
A Cloudera suporta camadas de dados (armazenamento heterogêneo) para implantações que consistem em volumes locais de bloco e NVMe para HDFS.
As implantações do MapR podem aproveitar o NVMe local em configurações do DenseIO ou em volumes em blocos para implantação.
- Armazenamento de Objetos: Consulte a Camada de Objetos XD do MapR.
- O MapR não suporta armazenamento heterogêneo sem licenciamento adicional.
DenseIO NVMe
O DenseIO NVMe é a opção de armazenamento mais funcional do Hadoop no Oracle Cloud Infrastructure. As unidades do NVMe local de alto espaço para uso com HDFS estão disponíveis nas configurações bare metal e de máquina virtual.
Ao usar o NVMe local, a Oracle recomenda definir a replicação de DFS para três réplicas para garantir a redundância dos dados.
Como alternativa, para clusters do Cloudera, considere a utilização da codificação de Tem certeza para aumentar a eficiência do armazenamento para tipos específicos de dados.
Volumes em Blocos
Os volumes em blocos do Oracle Cloud Infrastructure são uma opção de alto desempenho e fornecem configuração flexível para capacidade HDFS. Os volumes em blocos são um armazenamento anexado à rede e, como eles usam a largura de banda da VNIC para E/S. Os volumes em blocos também são escalados em IOPS e MB/s com base em seu tamanho configurado (por GB). O throughput de volume de bloco individual se encontra em 320 MB/s para 700GB ou volumes maiores.
A tabela a seguir mostra o escalonamento de throughput para um único nó de trabalhador usando volumes de 700GB:
| Volumes em Blocos | Throughput agregado (GB/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 |
A Oracle encontrou que, após 11 volumes em blocos, a adição de volumes em blocos adicionais resultou na diminuição de ganhos de throughput.
Quando você usa VMs como colaboradores, lembre-se de que o tráfego de volume em blocos compartilha o mesmo tráfego da VNIC que o Hadoop (aplicativo). A tabela a seguir mostra o máximo de volumes em blocos recomendado e a largura de banda da VNIC medida para uma seleção de formas Oracle Cloud Infrastructure, permitindo instâncias suficientes de largura de banda adicional para suportar o tráfego da aplicação no topo de E/S de disco:
| Forma do Oracle Cloud Infrastructure | Largura de Banda da VNIC | Máximo de Volumes em Blocos Sugeridos para 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 |
Quando você usa volumes em blocos para capacidade HDFS, recomendamos o uso de um número maior de volumes em blocos pequenos, em vez de um número menor de volumes em blocos grandes por colaborador para atingir a capacidade alvo HDFS.
Usando o mínimo de três nós worker como um exemplo, com o tamanho do volume de bloco 700GB para HDFS:
Descrição da ilustração block-volume-hdfs-capacity-chart.png
Observe que três volumes em blocos por colaborador são o requisito mínimo. A Oracle recomenda escalar a quantidade e o tamanho do volume em blocos para otimizar a capacidade HDFS necessária, sabendo que mais volumes em blocos por colaborador aumentam a largura de banda HDFS agregada geral disponível. Isso é especialmente importante para cargas de trabalho de alto throughput grandes, que requerem E/S mais agregada no cluster.
Também é importante para clusters persistentes manter o overhead adicional para crescimento ou refatoração.
Log e Dados de Aplicativos
Ao usar volumes em blocos para HDFS, você precisa reservar alguns volumes em blocos para uso com logs do Hadoop e dados do aplicativo (metadados de Parcelas do Cloudera, do NameNode e do Diário). Embora o volume do SO possa ser expandido para acomodar esses dados, é melhor usar volumes em blocos dedicados para essa finalidade. Os volumes em blocos oferecem mais portabilidade se você quiser alterar o tipo de instância dos seus nós mestres e mais flexibilidade se precisar de mais desempenho de E/S para um local de dados específico. Adicionar mais volumes em blocos à instância, criar um array RAID e migrar os dados existentes é mais fácil quando você possui anexos de volume sobressalentes a serem usados.
O mesmo é verdadeiro para HDFS. A sobrecarga para adição de mais volumes em blocos pode ser mais fácil do que a descontinuação de colaboradores, reconstruindo-os com discos maiores, adicionando-os de volta ao cluster e o rebalanceamento de HDFS. Ambos os métodos são válidos; trata-se apenas de sua carga de trabalho de cluster exigir um complemento total de volumes em blocos para suportar o throughput de dados. Se esse for o caso, considere trocar colaboradores para configurações bare metal Dense IO com armazenamento NVMe mais rápido e utilizar um modelo de armazenamento heterogêneo com camadas de dados.
Armazenamento de Objetos
A integração do Object Storage é possível com todos os Hadoop ISVs, incluindo Apache Hadoop. O Oracle Cloud Infrastructure tem um Conector HDFS nativo compatível com o Apache Hadoop. A lista Hadoop ISVs (Cloudera, Hortonworks e MapR) permitiu pontos finais externos para a integração do Object Storage e requer o uso da Compatibilidade S3 para que a integração do Object Storage funcione corretamente.
Uma advertência é que a Compatibilidade S3 funciona apenas com a região inicial da tenancy. Isso significa que, para qualquer integração feita com o Object Storage, os clusters Hadoop também devem ser implantados na mesma região (home).
Outra advertência é que quando você usa o Object Storage para enviar ou extrair dados para dentro ou fora do cluster, o HDFS não é usado como uma camada de cache. De fato, o sistema de arquivos do SO é onde OS dados são armazenados em cache, conforme eles são transferidos entre o Object Storage e o HDFS. Se um grande volume de dados estiver se movendo para frente e para trás entre o cluster HDFS e o Object Storage, recomendamos a criação de uma camada de cache de volume em blocos no SO para suportar essa movimentação de dados.
A figura a seguir mostra um diagrama de partição típico para suportar movimentação de dados S3, junto com camadas de dados para nós do colaborador.
Descrição da ilustração object-storage-partitioning-throughput.png
Camada de Dados
Você pode combinar todas as opções de armazenamento precedentes ao usar Apache Hadoop, Cloudera ou Hortonworks para criar um modelo de armazenamento de camadas de dados robustas (heterogêneas). Você também pode usar o gerenciamento do ciclo de vida de dados para enviar dados de um nível de armazenamento para outro, como por exemplo, para otimizar custos de armazenamento HDFS.
Descrição da ilustração data-lifecycle-tiering.png
Codificação de Erasure
A partir do Hadoop 3.0, a codificação de banco de dados (EC) é suportada nas implantações do HDFS. EC reduz os requisitos de armazenamento para dados HDFS locais armazenando dados com uma única cópia aumentada por células de paridade. A topologia HDFS pode ser marcada como EC, o que permite esta funcionalidade para quaisquer dados armazenados nessa localização marcada. Isso reduz efetivamente o requisito de armazenamento bruto para dados HDFS de EC-tagged, permitindo maior eficiência do armazenamento.
Há algumas notificações relacionadas a EC:
- O número mínimo de nós de trabalhadores é obrigatório para ativar a EC.
- A Localidade dos Dados foi perdida para os dados marcados em EC.
- EC é apropriado para arquivos de tamanho médio que são acessados sem muita frequência. É ineficiente para arquivos pequenos e para arquivos acessados com frequência.
- EC aumenta o número de objetos de bloco presentes nos Metadados do Nó de Nome em comparação com dados semelhantes à replicação tradicional (3x).
- A recuperação de dados EC requer o cálculo do cluster (reconstrução de paridade). Esse tempo de recuperação é maior que os dados replicados tradicionais (3x).
Monitorando o Desempenho
O serviço Oracle Cloud Infrastructure Monitoring permite monitorar de forma ativa e passiva seus recursos de nuvem usando as funcionalidades Métricas e Alarmes. Definir alarmes para notificar quando você atingir o desempenho ou os limites de capacidade é uma ótima maneira de aproveitar as ferramentas nativas do Oracle Cloud Infrastructure para gerenciar sua infraestrutura
Arquiteturas de Referência
Este tópico fornece material de referência para cada Hadoop ISV. As seguintes arquiteturas de referência e faturas de materiais refletem um footprint mínimo necessário para implantação suportada pelo fornecedor de Hadoop no Oracle Cloud Infrastructure.
Como um projeto de código-fonte aberto, a implantação do Apache Hadoop não tem um rodapé mínimo necessário fornecido pelo fornecedor. A Oracle recomenda o uso da implantação Hortonworks mostrada aqui como um guia razoável para uma implantação mínima do Apache.
Cloudera
Descrição da ilustração architecture-cloudera.png
Os requisitos mínimos para a implantação do Hadoop usando o Cloudera são:
| Atribuição | Quantidade | Forma de Computação Recomendada |
|---|---|---|
| Borda | 1 | VM.Standard2.4 |
| Cloudera Manager | 1 | VM.Standard2.16 |
| Nó-mestre | 2 | VM.Standard2.16 |
| Nó do Colaborador | 3 | BM.DenselO2.52 |
Nesta implantação mínima, o nó Cloudera Manager também executa serviços mestre.
Você deve trazer sua própria licença para implantar o Cloudera no Oracle Cloud Infrastructure; todo o suporte a software é através do Cloudera.
Hortonworks
Descrição da ilustração architecture-hortonworks.png
Os requisitos mínimos para a implantação do Hadoop usando Hortonworks são:
| Atribuição | Quantidade | Forma de Computação Recomendada |
|---|---|---|
| Borda | 1 | VM.Standard2.4 |
| Amarelo | 1 | VM.Standard2.16 |
| Nó-mestre | 2 | VM.Standard2.16 |
| Nó do Colaborador | 3 | BM.DenselO2.52 |
Nesta implantação mínima, o nó Ambari também executa serviços mestre.
Você deve trazer sua própria licença para implantar o Hortonworks no Oracle Cloud Infrastructure; todo o suporte ao software é através do Hortonworks.
MapR
Descrição da ilustração architecture-mapr.png
Os requisitos mínimos para implantação do Hadoop usando o MapR são:
| Atribuição | Quantidade | Forma de Computação Recomendada |
|---|---|---|
| Borda | 1 | VM.Standard2.4 |
| Nó de Dados | 3 | BM.DenselO2.52 |
Você deve trazer sua própria licença para implantar o MapR no Oracle Cloud Infrastructure; todo o suporte ao software é através do MapR.
Implantações do Terraform
Você pode encontrar modelos Terraform para cada Hadoop ISV na seção Código de Download desta solução.
Os repositórios Cloudera e Hortonworks têm modelos compatíveis com o Oracle Resource Manager. Observe que são específicos do Gerenciador de Recursos. A ramificação base (mestra) contém um modelo Terraform stand-alone. Os modelos do Resource Manager para Cloudera e Hortonworks também contêm um esquema YAML que preenche facilmente as variáveis Terraform de cada modelo. Isso fornece uma seleção drop-down de IU para variáveis, que você pode personalizar para seus casos de uso, preenchendo essencialmente cada modelo com opções de formato permitidas e definições de segurança/configuração.