Considerações para Implantação do Hadoop no Oracle Cloud Infrastructure

Implantação

Ao se inscrever na infraestrutura da Oracle como um serviço (IaaS), você tem acesso a todos os serviços de computação, armazenamento e rede associados a ele. As implantações do Oracle Cloud Infrastructure são como implantações locais, nas quais as mesmas versões e recursos estão disponíveis para cada distribuição do Hadoop.

Teraform e Gerenciador de Recursos

As equipes de engenharia da Oracle Cloud Infrastructure têm parceria com cada Hadoop ISV para permitir a implantação que utiliza o Terraform. O Terraform permite implantar a infraestrutura como código (IaC) e isso inclui todos os aspectos de um ecossistema Hadoop, de rede (redes virtuais na nuvem, sub-redes, VNICs) e listas de controle de acesso de segurança, para calcular e provisionar armazenamento. O Terraform é flexível, altamente escalável e um padrão entre muitos provedores de nuvem.

Você pode escolher se deseja usar esses modelos como uma estrutura para implantar o Hadoop no Oracle Cloud Infrastructure ou pode permanecer com ferramentas de implantação existentes utilizadas localmente. Ambos os métodos são válidos.

Se quiser usar o Terraform para implantar o Hadoop, considere usar o Oracle Resource Manager. Considere os principais benefícios de usar o Resource Manager:

Os metadados de estado do Terraform são mantidos em um local altamente disponível.
O acesso ao Resource Manager pode ser gerenciado com as mesmas ferramentas de segurança e auditoria incluídas em outros serviços Oracle Cloud Infrastructure.
O Resource Manager remove a complexidade associada à configuração do Terraform para implantação no Oracle Cloud Infrastructure.

A interface do Gerenciador de Recursos suporta arquivos de esquema baseados em YAML preenchidos com valores esperados para variáveis de pilha. Isso permite definir as formas, as versões de software e outros parâmetros que são permitidos para cada variável na pilha.

A descrição de resource-manager-ui.png é mostrada a seguir

Descrição da ilustração resource-manager-ui.png

Após o arquivo de esquema ser preenchido, os valores são mostrados em uma IU fácil de usar. O arquivo de esquema permite que você tenha listas drop-down com esses valores, bem como campos de entrada personalizados em que os usuários podem digitar ou colar entrada.

Os campos no arquivo de esquema também podem ter dependências, de modo que se um usuário escolher um valor em um campo, outros campos serão mostrados ou ocultados com base nessa opção.

Topologia do Serviço de Cluster

Ao implantar o Hadoop, considere o seguinte mapeamento da topologia do serviço de cluster para as atribuições do nó:

Tipo de Nó	Atribuição do Hadoop	Serviços Hadoop
Borda	Acesso do usuário do periador	Bibliotecas do Cliente, Oozie
Utilitário	Gerenciamento de Cluster	Cloudera Manager, Ambari, banco de dados de Metadados
Mestre	Serviços do Cluster Principal	Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Histórico de Jobs, Gerenciador de Recursos, HTTPFS, SOLR
Colaborador	Execução da Carga de Trabalho, Armazenamento de Dados	HDFS, NodeManager, Region Server, Kafka Broker, Executor Spark, Mapa/Reduzir

Ao escolher quais configurações de computação serão usadas para essas funções, as melhores práticas serão descritas posteriormente nesta solução. Também considere os seguintes critérios:

Quantos usuários concorrentes usarão o cluster?
Os nós limite devem ser escalados em quantidade e OCPU com base no número de usuários concorrentes. Dois usuários concorrentes por OCPU são uma boa diretriz, permitindo um thread por usuário. Nós de borda adicionais em domínios de falha também fornecem redundância.
Você tem requisitos de memória do servidor de regiões Spark ou HBase específicos?
Esses requisitos afetam diretamente a quantidade e a composição dos nós do colaborador. O dimensionamento do HBase requer uma compreensão da aplicação subjacente e varia. A maioria dos clientes já sabe seus requisitos para a implantação do HBase, especificamente o número de servidores de região e a memória alocada por servidor. As cargas de trabalho do Spark têm um alvo de memória agregado que é obtido fatorando o número de nós do colaborador multiplicado pela memória disponível por colaborador.
Você tem um requisito de capacidade HDFS específico?
A maioria dos clientes tem esse requisito. No entanto, antes de expandir um grande número de nós de trabalho bare metal DenseIO, considere que o HDFS com economia do NVMe pode ser ampliado pelos volumes em blocos para alcançar a densidade HDFS necessária, conforme descrito posteriormente nesta solução. A Oracle recomenda que você entenda os requisitos de HDFS, mas também fatore os requisitos de carga de trabalho para que você possa “tamanho correto” do cluster para atingir ambos os alvos ao minimizar o custo.

Migração

Quando os clientes que executam o Hadoop decide implantar no Oracle Cloud Infrastructure, eles geralmente têm um grande volume de dados para migrar. O alto volume desses dados está presente no HDFS, com suporte aos metadados de cluster presentes em um banco de dados.

A cópia de dados do HDFS diretamente pela internet pode ser desafiante por vários motivos:

O volume de dados é muito grande ou a largura de banda disponível é muito restrita, para suportar a cópia de dados excedentes em qualquer período significativo.
Os dados são confidenciais, e copiá-los pela Internet talvez não sejam permitidos por requisitos governamentais ou regulatórios.
Os recursos de cluster local são restritos, e a cópia de dados impactaria a carga de trabalho em andamento.

Várias abordagens na migração de dados são suportadas. Eles são definidos pelo tipo de dados que está sendo migrado.

Migração de Dados HDFS

Há três formas comuns de copiar dados do HDFS para o Oracle Cloud Infrastructure:

Copie dados diretamente de um cluster local para o Object Storage em uma região do Oracle Cloud Infrastructure usando VPN na Internet ou com o FastConnect. Depois que esse processo for concluído, um cluster do Oracle Cloud Infrastructure pode ser reabilitado com os dados do Object Storage.
Copie dados diretamente de um cluster local para um cluster do Oracle Cloud Infrastructure pela internet ou usando o FastConnect.
Copie dados para um Data Transfer Appliance, que é implantado no centro de dados do cliente, preenchido com dados e depois remetido para o Oracle e transferido por upload para o Object Storage. Um cluster do Oracle Cloud Infrastructure pode então ser reabilitado com esses dados.

Detalhes técnicos sobre cada um desses métodos são discutidos posteriormente nesta solução.

Migração de Metadados

Os metadados de cluster geralmente são muito menores do que os dados HDFS e existem em um banco de dados no cluster local.

A migração dos metadados do cluster depende de dois fatores: a distribuição do Hadoop no cluster de origem e qual banco de dados está sendo usado para armazenar metadados. A transferência desses dados é direta e específica para cada distribuição do Hadoop.

Informações específicas sobre cada distribuição do Hadoop são apresentadas posteriormente nesta solução.

Segurança

A segurança na nuvem é especialmente importante para o Hadoop e há muitas maneiras de garantir que a sua implantação no Oracle Cloud Infrastructure permaneça segura.

Primeiramente, considere alguns controles de segurança específicos da Oracle Cloud Infrastructure:

Aproveite o Identity and Access Management (IAM) para controlar quem tem acesso aos recursos da nuvem, que tipo de acesso a um grupo de usuários tem e para quais recursos específicos. Essa arquitetura pode fornecer os seguintes resultados:
- Isola de forma segura os recursos da nuvem com base na estrutura organizacional
- Autenticar usuários para acessar serviços de nuvem em uma interface de browser, API REST, SDK ou CLI
- Autorizar grupos de usuários para executar ações nos recursos de nuvem apropriados
- Federação com provedores de identidade existentes
- Ative um provedor de serviços gerenciado (MSP) ou um integrador de sistemas (SI) para gerenciar ativos de infraestrutura, permitindo que seus operadores acessem recursos
- Autorizar instâncias do aplicativo para fazer chamadas de API em relação aos serviços de nuvem
Auditar listas de segurança para todas as redes na rede virtual na nuvem (VCN). Torne essas regras o mais restritivo possível e permita somente o tráfego confiável em sub-redes com acesso à Internet.
Ative firewalls de host em hosts com interface de rede e permita apenas o tráfego necessário.
Considere usar auditoria de segurança regularmente.

A criptografia também é uma boa opção para dados em repouso e dados em movimento. Considere os seguintes recursos:

Mecanismos de criptografia Cloudera
Hortonworks
- Criptografia HDFS em armazenamento
- Criptografia remota
Criptografia do MapR

Outras considerações de segurança de Hadoop-specific incluem:

Implante clusters em sub-redes com endereços IP privados, que expõe somente as APIs ou as UIs necessárias para sub-redes com interface de internet.
Execute o Hadoop usando a segurança do cluster
Use nós de borda para acessar serviços de cluster por meio do tunelamento SSH. Isso é ainda mais fácil no Mac ou Linux.
Utilize o Apache Knox para proteger pontos finais de API.
Aproveite o Apache Sentry ou o Cloudera Navigator para obter acesso baseado em função aos dados e metadados do cluster.

Segurança de Rede

Devido à natureza aberta do Hadoop e às considerações de segurança, a maioria dos clientes prefere implantar seu cluster Hadoop em uma sub-rede privada. O acesso aos serviços de cluster só fica disponível usando nós de borda, acesso de balanceamento de carga a UIs, APIs e painéis de controle de serviço, ou por acesso direto por meio do tunelamento de VPN ou SSH da FastConnect por meio de um proxy de borda.

As sub-redes públicas aumentam a implantação de cluster para nós de borda e de utilitário, que executam serviços voltados para internet (como Cloudera Manager ou Ambari). Isso é totalmente opcional. Você pode optar por aproveitar a VPN do FastConnect e executar toda a implantação como uma extensão de sua topologia de rede local. Isso requer apenas um segmento de IP privado que pode ser direcionado ao cliente, que é associado no nível de VCN e, em seguida, dividido em sub-redes apropriadas no Oracle Cloud Infrastructure. O acesso é controlado com o uso de listas de segurança, que se aplicam ao nível da sub-rede. A melhor prática é agrupar recursos que têm requisitos de acesso semelhantes nas mesmas sub-redes.

Topologia de Sub-rede

A VCN abrange um único bloco CIDR contíguo do IPv4 de sua escolha. Na VCN, é possível implantar sub-redes IPv4 individuais para hosts de cluster. O acesso em cada sub-rede é controlado por listas de segurança. A segurança adicional é controlada no nível do host por firewalls.

A melhor prática é separar recursos de cluster Hadoop em uma sub-rede privada que não esteja diretamente acessível pela internet. O acesso ao cluster deve ser controlado por meio de hosts adicionais em sub-redes voltadas para o público e protegido usando as regras apropriadas de lista de segurança para controlar o tráfego entre os segmentos de rede públicos e privados. Este modelo fornece a melhor segurança para seu cluster do Hadoop.

As sub-redes públicas podem ser usadas para nós de borda (acesso do usuário) e para qualquer serviço que precise expor uma UI ou API (como Cloudera Manager ou Ambari) para acesso externo.
As sub-redes privadas devem ser usadas para hosts de cluster (mestre, colaborador) e não podem ser acessadas diretamente pela Internet. Em vez disso, eles requerem um host intermediário em uma sub-rede pública para acesso, um balanceador de carga ou acesso direto pela VPN, FastConnect ou proxy SSH.

Listas de Segurança

Listas de segurança controlam o tráfego de entrada e saída no nível da sub-rede. No Hadoop, é melhor ter acesso bidirecional total entre sub-redes com hosts de cluster para tráfego TCP e UDP. As sub-redes públicas devem ter listas de segurança altamente restritivas para permitir que somente portas confiáveis (e até mesmo endereços IP de origem) acessem APIs e UIs.

Alta Disponibilidade

O Hadoop tem métodos integrados para alta disponibilidade (HA) e os não são abordados aqui. Veja a seguir as melhores práticas para aproveitar o Oracle Cloud Infrastructure for Hadoop para obter alta disponibilidade.

Seleção da Região

Cada região do Oracle Cloud Infrastructure consiste de um a três domínios de disponibilidade. Cada domínio de disponibilidade também consiste em três domínios de falha. Escolha uma região inicial que esteja próxima a você e seus recursos de negócios (como seu centro de dados). A composição da região escolhida determina se você pode usar uma implantação de domínio de disponibilidade única ou uma implantação de vários domínios.

Implantação de Domínio de Disponibilidade Única

A Oracle recomenda a implantação de domínio de disponibilidade única para implantações do Hadoop no Oracle Cloud Infrastructure. Para implantações do MapR, esta arquitetura é a única suportada. Este modelo de implantação é o mais executor de uma perspectiva de rede porque o tráfego entre clusters está contido em segmentos de rede locais, que mantém baixa latência e alto throughput. Os recursos no domínio de disponibilidade são divididos entre os domínios de falha para atingir HA da infraestrutura física.

Um domínio de falha é um agrupamento de hardware e infraestrutura em um domínio de disponibilidade. Cada domínio de disponibilidade contém três domínios de falha. Os domínios de falha permitem distribuir suas instâncias para que elas não fiquem no mesmo hardware físico dentro de um único domínio de disponibilidade. Uma falha de hardware ou manutenção de hardware computacional que afeta um domínio de falha não afeta instâncias em outros domínios de falha.

Implantação Multiple-Availability-Domínio

As implantações com vários domínios de disponibilidade (extensão do domínio de disponibilidade) só são suportadas por Cloudera e Hortonworks, mas também são possíveis com o Apache Hadoop.

No entanto, considere as seguintes notificações do domínio de disponibilidade:

A conectividade entre clusters deve passar por segmentos WAN, o que aumenta a latência e diminui o throughput ideal. Isso tem um impacto mensurável sobre o desempenho, especialmente com nós de trabalhador bare metal. Para nós menores de trabalhadores de VM, o impacto no desempenho é menos perceptível.
Nem todas as regiões do Oracle Cloud Infrastructure suportam este modelo.

O diagrama a seguir mostra o impacto medido no desempenho ao usar o TeraSort 10-TB em um domínio de disponibilidade único em comparação com o domínio de disponibilidade que consiste em cinco nós do colaborador e três nó-mestre:

A seguir, descrição de comparison-availability domain-spanning.png

Descrição da ilustração comparison-availabiliy-domain-spanning.png

O domínio de disponibilidade que se estende fornece redundância adicional dos serviços do cluster em uma única região. Os recursos de cluster também podem aproveitar domínios de falha em cada domínio de disponibilidade para “topologia de rack” lógica adicional; cada domínio de falha é considerado um “rack” para conhecimento do rack. Esses benefícios são ilustrados pelo seguinte diagrama.

A descrição de architecture-multiple-availabiliy-domains.png é mostrada a seguir

Descrição da ilustração architecture-multiple-availabiliy-domains.png

Recuperação de Desastres

A recuperação de desastres (DR) no Oracle Cloud Infrastructure depende diretamente dos requisitos de RPO (Recovery Point Objective) e RTO (Recovery Time Objective).

Se a RPO ou o RTO estiver próximo em tempo real, sua única opção de Hadoop será criar um cluster de DR em outro domínio ou região de disponibilidade e, em seguida, replicar dados entre os clusters de produção e de DR. Se os requisitos de RPO e RTO forem mais flexíveis, recomendamos utilizar o Object Storage como um alvo de backup para metadados de HDFS e cluster. Programe o processo de cópia conforme necessário para atender ao alvo RPO, enviando dados para o Armazenamento de Objetos usando uma ferramenta como o DistCp (cópia distribuída). Você também pode fazer backup de bancos de dados (Oracle, MySQL) em buckets do Object Storage ou replicar para instâncias adicionais do banco de dados em outros domínios ou regiões de disponibilidade.

Se seus requisitos de DR especificam redundância geográfica para dados que uma única região não pode fornecer, você também poderá copiar dados no Object Storage entre regiões. Se ocorrer um desastre, considere usar o Terraform para provisionar recursos rapidamente em outro domínio de disponibilidade (seja na mesma região ou em uma região diferente) e reabilite a reabilitação do cluster DR dos dados no Object Storage.

Gerenciamento de Custos

Conforme detalhado no restante desta solução, há várias maneiras de “dimensionar com o botão direito” os requisitos de computação e armazenamento para reduzir os custos da infraestrutura. O Oracle Cloud Infrastructure tem ferramentas adicionais para ajudá-lo a gerenciar o custo associado a uma implantação do Hadoop:

É possível aproveitar a marcação de suas implantações para facilitar o rastreamento do consumo.
Você pode definir cotas no nível do compartimento para limitar o consumo por diferentes linhas de negócios. Considere usar vários compartimentos para gerenciar ambientes de produção, QA e desenvolvimento e restringir as cotas conforme apropriado.

A utilização da natureza dinâmica da nuvem também é ótima para ambientes que talvez não precisem ser persistentes. Se você estiver usando o Object Storage como backup (ou data lake) para seus dados, será fácil criar ambientes quando precisar deles usando o Terraform, readydrate HDFS com dados do Object Storage e destruir o ambiente quando não for mais necessário.

Os ambientes de VM com volumes em blocos também podem estar pausados para interromper o faturamento do Compute e você só será cobrado pelo consumo de armazenamento.