Implantar Elasticsearch e Kibana

Elasticsearch é uma fonte aberta, motor de busca de nível empresarial. Acessível por meio de uma extensa API, o Elasticsearch pode impulsionar pesquisas rápidas que suportam seus aplicativos de descoberta de dados. Ele pode dimensionar milhares de servidores e acomodar petabytes de dados. Sua grande capacidade resulta diretamente de sua arquitetura elaborada e distribuída.

Os casos de uso mais comuns para Elasticsearch são análises usando extrações de dados super-rápidas de fontes de dados estruturadas e não estruturadas, e pesquisa de texto completo alimentada por uma extensa linguagem de consulta e preenchimento automático.

Arquitetura

Esta arquitetura de referência mostra uma implantação em cluster do Elasticsearch e do Kibana.

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

elk-oci.zip

Essa arquitetura tem os seguintes componentes:

  • Domínios de disponibilidade

    Os domínios de disponibilidade são data centers independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos 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 de domínio de disponibilidade interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.

  • Domínios com falha

    Um 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 energia dentro de um domínio de falha.

  • Host Bastion

    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 bastião hospedeiro é normalmente provisionado 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. Assim, você pode evitar expor os componentes mais sensíveis da topologia sem comprometer o acesso a eles.

  • Balanceador de carga

    As operações de índice de saldos do balanceador de carga para os nós de dados e o acesso do Kibana aos nós mestres. Ele usa dois listeners, um para Kibana e outro para acesso a dados de índice, usando back-ends de nó mestre e back-ends de nó de dados. O balanceador de carga está em uma sub-rede pública com um endereço IP público.

  • Nós mestres

    Nós mestres executam tarefas de gerenciamento de cluster, como criar índices e reequilibrar shards. Eles não armazenam dados. Três nós mestres (recomendados para clusters maiores) são implantados em três domínios de falha para garantir alta disponibilidade.

  • Nós de dados

    Três nós de dados são implantados em três domínios de falha para alta disponibilidade. Recomendamos instâncias do serviço Compute otimizadas para memória porque o Elasticsearch depende da quantidade de memória disponível. Cada nó de dados é configurado com um armazenamento em bloco 200 GiB. Além das VMs, o Oracle Cloud Infrastructure oferece instâncias bare metal avançadas que estão conectadas em clusters a uma infraestrutura de rede de 25 Gb sem sobrescrita. Essa configuração garante baixa latência e alto throughput, que fornecem cargas de trabalho de streaming distribuídas de alto desempenho.

  • Kibana

    Como os nós mestres, o Kibana tem requisitos de recursos relativamente leves. A maioria dos cálculos é enviada para Elasticsearch. Nesta implantação, o Kibana é executado nos nós mestres.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.

  • VCN

    Ao criar 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.

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

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

    Usar sub-redes regionais.

  • 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 o uso de NSGs em vez de listas de segurança, porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos requisitos de segurança da sua aplicação. Na arquitetura de referência, toda a comunicação de rede é controlada por NSGs.

  • Armazenamento em bloco

    Esta arquitetura usa 200 GB de armazenamento em bloco. Recomendamos que você configure um gerenciador de volume lógico (LVM) para permitir que o volume cresça se precisar de mais espaço. Cada volume em blocos é configurado para usar desempenho balanceado e fornece 35K IOPS e 480 MBps de throughput.

  • Formas de Computação

    Esta arquitetura usa uma forma de máquina virtual (VM.Standard2.24) para todos os nós de dados. Essas instâncias de computação podem enviar tráfego a 25 Gbps e fornecer 320 GB de RAM.

Considerações

  • Desempenho

    Elasticsearch depende da quantidade de memória disponível. Para obter o melhor desempenho, use formas de computação que forneçam uma boa quantidade de memória. Você pode usar formas bare metal, onde pode obter até 768 GB de RAM.

  • Disponibilidade

    Os domínios com falha fornecem a melhor resiliência dentro de um domínio de disponibilidade. Se precisar de maior disponibilidade, considere usar vários domínios de disponibilidade ou várias regiões para sua implantação.

  • Escalabilidade

    Embora você possa escalar nós mestre e de dados manualmente, recomendamos o uso do dimensionamento automático para minimizar a chance de que os serviços fiquem sem recursos em cargas altas. Uma estratégia de dimensionamento automático deve considerar nós mestre e de dados.

  • Custo

    O custo da implantação do Elasticsearch depende dos requisitos de memória e disponibilidade. As formas do serviço Compute escolhidas têm um impacto maior nos custos associados a essa arquitetura.

Implantar

O código necessário para implantar esta arquitetura de referência está disponível no GitHub. Você pode inserir 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 o seu computador, personalize-o e implante a arquitetura usando a CLI do Terraform.

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

      Se você ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.

    2. Revise e aceite os termos e condições.
    3. Selecione a região em que deseja implantar a pilha.
    4. Siga os prompts e instruções na tela para criar a pilha.
    5. Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
    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 outra alteração 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 o GitHub.
    2. Baixe ou clone o código para o computador local.
    3. Siga as instruções em cluster/single-ad/README.md.

Alterar Log

Este log lista apenas as alterações significativas: