Propriedades-chave da camada de plataforma

Na arquitetura do Private Cloud Appliance, a camada da plataforma é a parte que fornece uma infraestrutura padronizada para serviços de nuvem on-premises. Controla a camada de hardware, ativa a camada de serviços e estabelece uma interface segura que permite que essas camadas interajam de maneira uniforme e centralizada. Componentes e recursos comuns da camada de serviços de infraestrutura são incorporados à plataforma, simplificando e acelerando a implantação desses microsserviços.

Serviços Básicos

Para cumprir sua função principal de fornecer a infraestrutura base para implementar serviços de nuvem on-premises, a plataforma conta com um conjunto próprio de serviços internos fundamentais.

Gerenciamento de Hardware

Quando um sistema é inicializado, os componentes de plataforma de baixo nível orquestram o provisionamento do cluster de nós de gerenciamento e dos nós de computação. Durante esse processo, todos os nós, inclusive os controladores do ZFS Storage Appliance, são conectados às redes de dados e administração necessárias. Quando nós de computação adicionais são instalados em um estágio posterior, o mesmo mecanismo de provisionamento integra o novo nó à configuração do sistema global. Bandejas de disco adicionais também são automaticamente integradas pelos controladores de armazenamento.

O primeiro passo no gerenciamento do hardware é criar um inventário dos componentes do rack. O inventário é um banco de dados separado que contém especificações e detalhes de configuração dos componentes instalados no rack. Ele mantém um histórico de todos os componentes que foram apresentados ao sistema e é atualizado continuamente com as informações mais recentes capturadas dos componentes do sistema ativo.

A camada de serviços e vários componentes do sistema precisam dos detalhes do inventário de hardware para que possam interagir com o hardware. Por exemplo, um processo de atualização de componente ou implantação de serviço precisa enviar instruções para a camada de hardware e receber respostas. Da mesma forma, quando você cria uma instância de computação, uma série de operações precisa ser executada no nível dos nós de computação, componentes de rede e appliance de armazenamento para ativar a instância e seus recursos de rede e armazenamento associados.

Todas as instruções destinadas à camada de hardware são centralizadas em um serviço de gerenciamento de hardware, que atua como um gateway para a camada de hardware. O serviço de gerenciamento de hardware usa a API de plataforma dedicada e altamente segura para executar os comandos necessários nos componentes de hardware: ILOMs de servidor, controladores de armazenamento ZFS e assim por diante. Essa API é executada diretamente no sistema operacional do nó de gerenciamento. Ele é separado do ambiente de orquestração de contêineres no qual os microsserviços são implantados.

Implantação do Serviço

O Private Cloud Appliance segue um modelo de desenvolvimento granular baseado em serviços. A funcionalidade é logicamente dividida em microsserviços separados, que existem nas camadas arquitetônicas e representam uma visão vertical do sistema. Os serviços têm funções internas e externalizadas e interagem entre si em diferentes camadas.

Esses microsserviços são implementados em contêineres Kubernetes. O ambiente de runtime do contêiner, bem como o registro, são hospedados no cluster de gerenciamento de três nós. O Oracle Cloud Native Environment fornece a base para a orquestração de contêineres, que inclui a implantação, a configuração e a inicialização automatizadas dos contêineres de microsserviços. Por design, todos os microsserviços consistem em várias instâncias espalhadas por diferentes nós e pods do Kubernetes. Além da alta disponibilidade, o design do Kubernetes também oferece balanceamento de carga entre as instâncias de cada microsserviço.

A conteinerização simplifica as atualizações de serviço e os aprimoramentos funcionais. Os serviços são totalmente integrados, mas não monolíticos, permitindo atualizações individuais, desde que os requisitos de compatibilidade sejam respeitados. Uma nova versão de um microsserviço é publicada no registro de contêiner e automaticamente propagada para os nós e pods do Kubernetes.

Componentes de Serviço Comuns

Alguns componentes e mecanismos operacionais são exigidos por muitos ou todos os serviços, por isso é mais eficiente construí-los na plataforma. Os microsserviços podem consumir esses componentes comuns e seus recursos essenciais quando são implementados na plataforma.

  • Transporte de mensagens

    Todos os componentes e serviços estão conectados a uma camada de transporte comum. É um broker de mensagens que permite aos componentes enviar e receber mensagens gravadas em um formato padronizado. Este serviço de transporte de mensagens é implantado como um cluster de três instâncias para alta disponibilidade e throughput, e usa TLS para autenticação e criptografia de tráfego.

  • Serviço Secreto

    Segredos usados de forma programática em todo o sistema, como credenciais de login e certificados, são gerenciados centralmente pelo serviço secreto. Todos os componentes e serviços são clientes do serviço secreto: após a autenticação bem-sucedida, o cliente recebe um token para uso em cada operação que tenta executar. As políticas definidas no serviço secreto determinam quais operações o cliente está autorizado a executar. Os segredos não são armazenados de forma estática; eles têm uma vida útil limitada e são criados e gerenciados dinamicamente.

    Durante a inicialização do sistema, o serviço de segredo é lacrado e preparado para uso. Ele é implantado como um cluster ativo/em espera nos nós de gerenciamento, dentro de um contêiner na camada da plataforma, mas fora do ambiente de microsserviços do Kubernetes. Isso permite que o serviço secreto ofereça sua funcionalidade à camada da plataforma na inicialização, antes que os microsserviços estejam disponíveis. Todos os componentes da plataforma e microsserviços devem estabelecer sua relação de confiança com o serviço secreto antes de serem autorizados a executar qualquer operação.

  • Log

    A plataforma fornece registro unificado em todo o sistema. Para isso, todos os serviços e componentes se integram ao coletor de dados Fluentd. O Fluentd coleta dados de um conjunto pré-configurado de arquivos de log e os armazena em um local central. Os logs são capturados dos componentes do sistema, da camada da plataforma e do ambiente de microsserviços e disponibilizados por meio do sistema de agregação de logs Loki para rastreabilidade e análise.

  • Monitoramento

    Para fins de monitoramento, a plataforma conta com a Prometheus para coletar dados de métricas. Como o Prometheus é implantado no ambiente Kubernetes, ele tem acesso direto às métricas de microsserviços. Componentes fora do Kubernetes, como componentes de hardware e instâncias de computação, fornecem seus dados de métrica à Prometheus por meio da rede interna e do balanceador de carga. Os nós de gerenciamento e o próprio Kubernetes podem se comunicar diretamente com a Prometheus.

  • Análise

    Os dados de registro e monitoramento são destinados a administradores de infraestrutura. Eles podem consultar os dados por meio da IU da Web do Serviço, em que várias consultas integradas para parâmetros de integridade e desempenho são visualizadas em um painel. Os alertas são enviados quando um limite de chave é excedido, para que as contramedidas apropriadas possam ser tomadas.

  • Banco de Dados

    Todos os serviços e componentes armazenam dados em um banco de dados central comum. É um banco de dados de cluster MySQL com instâncias implantadas nos três nós de gerenciamento e em execução no bare metal. A disponibilidade, o balanceamento de carga, a sincronização de dados e o clustering são controlados por componentes internos do cluster MySQL. Para obter um desempenho ideal, o armazenamento de dados é fornecido por LUNs no ZFS Storage Appliance, diretamente conectados a cada um dos nós de gerenciamento. O acesso ao banco de dados é estritamente controlado pelo serviço secreto.

  • Load Balancing

    Os nós de gerenciamento formam um cluster de três nós ativos, o que significa que todos eles são capazes de receber simultaneamente conexões de entrada. O tráfego de entrada é controlado por um balanceador de carga configurado estaticamente que faz listening em um endereço IP flutuante e distribui o tráfego entre os três nós de gerenciamento. Uma instância do balanceador de carga é executada em cada um dos nós de gerenciamento.

    Da mesma forma, todos os microsserviços em contêiner são executados como vários pods no ambiente de orquestração de contêiner no cluster do nó de gerenciamento. O Kubernetes fornece o balanceamento de carga para o tráfego de entrada para os microsserviços.