1. Implantar um sistema de arquivos escalável e distribuído usando GlusterFS
  2. Implantar um Sistema de Arquivos Escalável e Distribuído Usando GlusterFS

Implantar um Sistema de Arquivos Escalável e Distribuído Usando GlusterFS

Um sistema de arquivos de rede distribuído e escalável é adequado para tarefas com uso intensivo de dados, como processamento de imagens e streaming de mídia. Quando usado em ambientes de computação de alto desempenho (HPC), GlusterFS oferece acesso de alto desempenho a grandes conjuntos de dados, especialmente arquivos imutáveis.

Arquitetura

Essa arquitetura de referência contém os componentes de infraestrutura necessários para um sistema de arquivos de rede distribuído. Ele contém três instâncias bare metal, que é o mínimo necessário para configurar alta disponibilidade para GlusterFS.

Em uma configuração de três servidores, pelo menos dois servidores devem estar on-line para permitir operações de gravação no cluster. Os dados são replicados em todos os nós, conforme mostrado no diagrama.

Veja a seguir a descrição da ilustração glusterfs-oci.png
Descrição da ilustração glusterfs-oci.png

glusterfs-oci-oracle.zip

  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominados domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou continentes).

  • Domínio de disponibilidade

    Os domínios de disponibilidade são data centers independentes e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou resfriamento ou a rede interna de domínios de disponibilidade. Portanto, não é possível afetar os outros domínios de disponibilidade na região.

  • Domínio de falha

    Domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falhas físicas do servidor, manutenção do sistema e falhas de alimentação dentro de um domínio de falha.

  • Rede virtual na nuvem e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes de data center tradicionais, as VCNs permitem controle total sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você poderá alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter como escopo uma região ou um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não são sobrepostos com as outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

    Esta arquitetura usa duas sub-redes: uma sub-rede pública para criar o DMZ e hospedar o servidor bastion, e uma sub-rede privada para hospedar os nós GlusterFS.

  • Grupo de segurança de rede (NSG)

    Os NSGs atuam como firewalls virtuais para seus recursos de nuvem. Com o modelo de segurança de confiança zero do Oracle Cloud Infrastructure, todo o tráfego é negado e você pode controlar o tráfego de rede dentro de uma VCN. Um NSG consiste em um conjunto de regras de segurança de entrada e saída que se aplicam somente a um conjunto especificado de VNICs em uma única VCN.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que devem ser permitidos dentro e fora da sub-rede.

  • GFS-nodes

    Esses são os headends GlusterFS, com 1 TB de armazenamento em blocos anexado a cada instância.

  • /gfs-data

    Na arquitetura de referência, o cliente monta o volume GlusterFS no ponto de montagem /gfs-data, por meio do qual seu aplicativo acessa o sistema de arquivos. Vários servidores podem acessar os nós de headend em paralelo.

  • Bastion host

    O bastion host é uma instância de computação que serve como um ponto de entrada seguro e controlado para a topologia de fora da nuvem. O bastion host é provisionado tipicamente em uma zona desmilitarizada (DMZ). Ele permite que você proteja recursos confidenciais colocando-os em redes privadas que não podem ser acessadas diretamente de fora da nuvem. A topologia tem um único ponto de entrada conhecido que você pode monitorar e auditar regularmente. Portanto, você pode evitar a exposição dos componentes mais confidenciais da topologia sem comprometer o acesso a eles.

Recomendações

Os requisitos podem diferir da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.

  • Arquitetura GlusterFS

    Essa arquitetura usa volumes GlusterFS replicados; os dados são replicados em todos os nós. Essa configuração fornece a maior disponibilidade de dados, mas também usa a maior quantidade de espaço. Conforme mostrado no diagrama de arquitetura, quando File1 é criado, ele é replicado entre os nós.

    GlusterFS suporta as seguintes arquiteturas. Selecione uma arquitetura adequada às suas necessidades:
    • Volumes distribuídos

      Essa arquitetura é a configuração padrão GlusterFS e é usada para obter o tamanho máximo do volume e escalabilidade. Não há redundância de dados. Portanto, se um bloco no volume falhar, ele levará a uma perda completa dos dados.

    • Volumes replicados

      Essa arquitetura é mais usada onde a alta disponibilidade é fundamental. Problemas de perda de dados decorrentes de falhas de tijolos são evitados replicando dados em dois ou mais tijolos. Essa arquitetura de referência usa a configuração de volumes Replicados.

    • Volumes replicados distribuídos

      Esta arquitetura é uma combinação de volumes distribuídos e replicados e é usada para obter maiores tamanhos de volume do que um volume replicado e maior disponibilidade do que um volume distribuído. Nesta configuração, os dados são replicados em um subconjunto do número total de tijolos. O número de tijolos deve ser um múltiplo da contagem de réplicas. Por exemplo, quatro tijolos de 1 TB cada um darão a você um espaço distribuído de 2 TB com uma replicação de duas partes.

    • Volumes divididos

      Essa arquitetura é usada para arquivos grandes que serão divididos em partes menores e cada bloco é armazenado em um bloco. A carga é distribuída entre os tijolos e o arquivo pode ser extraído mais rápido, mas não há redundância de dados disponível.

    • Volumes distribuídos

      Essa arquitetura é usada para arquivos grandes com distribuição em mais de tijolos. O trade-off com essa configuração é que, se você quiser aumentar o tamanho do volume, deverá adicionar blocos em múltiplos da contagem de faixas.

  • Formatos de computação

    Essa arquitetura usa uma forma bare metal (BM.Standard2.52) para todos os nós GlusterFS. Essas instâncias de computação bare metal têm duas NICs físicas que podem enviar tráfego a 25 Gbps cada uma. A segunda NIC física é dedicada para o tráfego GlusterFS.

  • Armazenamento em bloco

    Essa arquitetura usa 1 TB de armazenamento em blocos. Recomendamos que você configure um LVM (Logical Volume Manager) para permitir que o volume cresça se precisar de mais espaço. Cada volume em blocos é configurado para usar o desempenho balanceado e fornece 35K de IOPS e 480 MB/s de throughput.

  • Rede virtual na nuvem (VCN)

    Quando você cria uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no Oracle Cloud Infrastructure, seu data center local ou outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere seu fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos dentro de uma camada ou função específica à mesma sub-rede, que pode servir como limite de segurança.

  • Grupos de Segurança de Rede (NSGs)

    Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos usar NSGs em vez de listas de segurança, porque os NSGs permitem separar a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo. Na arquitetura de referência, toda a comunicação de rede é controlada por meio de NSGs.

  • Listas de segurança

    Use listas de segurança para definir regras de entrada e saída que se aplicam à sub-rede inteira.

Considerações

  • Desempenho

    Para obter o melhor desempenho, use NICs dedicados para comunicação do aplicativo para seus usuários e para os headends GlusterFS. Use o NIC principal para comunicação entre seu aplicativo e os usuários. Use o NIC secundário para comunicação com os headends GlusterFS. Você também pode alterar o desempenho do volume para armazenamento em blocos para aumentar ou diminuir o IOPS e o throughput do disco.

  • Disponibilidade

    Os domínios de falha fornecem a melhor resiliência dentro de um domínio de disponibilidade. Se você precisar de maior disponibilidade, considere o uso de vários domínios de disponibilidade ou várias regiões. Para cargas de trabalho de missão crítica, considere o uso de volumes GlusterFS distribuídos.

  • Custo
    O custo da sua implantação GlusterFS depende dos seus requisitos de desempenho e disponibilidade do disco:
    • Você pode escolher entre as seguintes opções de desempenho: alto desempenho, desempenho equilibrado e baixo custo.
    • Para maior disponibilidade, você precisa de um número maior de nós e volumes GlusterFS.

Implantar

O código necessário para implantar esta arquitetura de referência está disponível no GitHub. Você pode colocar o código no Oracle Cloud Infrastructure Resource Manager com um único clique, criar a pilha e implantá-la. Como alternativa, faça download do código do GitHub para seu computador, personalize o código e implante a arquitetura usando a CLI do Terraform.

  • Implante usando o Oracle Cloud Infrastructure Resource Manager:
    1. Clique em Implantar no Oracle Cloud

      Se você ainda não estiver conectado, informe a tenancy e as credenciais do usuário.

    2. Revise e aceite os termos e condições.
    3. Selecione a região na qual você deseja implantar a pilha.
    4. Siga os prompts na tela e as instruções para criar a pilha.
    5. Após criar a pilha, clique em Ações do Terraform e selecione Planejar.
    6. Aguarde a conclusão do job e revise o plano.

      Para fazer alterações, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação Plano novamente.

    7. Se nenhuma alteração adicional for necessária, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
  • Implante usando a CLI do Terraform:
    1. Vá para GitHub.
    2. Clone ou faça download do repositório no computador local.
    3. Siga as instruções no documento README.

Explorar Mais

Alterar Log

Este log lista alterações significativas: