Usar Replicação de Bloco Síncrona Remota no Oracle Cloud Infrastructure
Forneça tolerância a falhas de volumes em blocos usando replicação em blocos síncrona remota.
Os desafios típicos de muitas empresas incluem: aplicativos em execução em cima de um banco de dados, aplicativos que acessam dispositivos de bloco subjacentes e um requisito de negócios para atrasos zero nos serviços.
Tome empresas de processamento de pagamentos, por exemplo. Como um atraso no processamento de pagamentos afeta negativamente a reputação e a marca aos olhos de seus clientes, eles precisam ter tecnologia de alta disponibilidade para fornecer verdadeira tolerância a falhas (ou seja, zero interrupções de serviço em caso de falha de um único componente).
Arquitetura
Essa arquitetura implementa um dispositivo de bloco altamente disponível na Oracle Cloud Infrastructure (OCI), totalmente tolerante a uma falha no nível da aplicação de negócios. Use essa arquitetura para aplicativos sensíveis ao desempenho que exigem continuidade ao mesmo tempo.
Essa arquitetura fornecerá um dispositivo de bloco iSCSI de entidade única aos usuários. Este dispositivo estará sempre disponível, independentemente de falhas de componente único. Qualquer outro componente da arquitetura será ocultado dos usuários. A arquitetura é totalmente automatizada em caso de falha ou switchover. O único efeito que os usuários notarão em caso de falha ou switchover será a degradação do desempenho do dispositivo iSCSI em cerca de 50% por um ou dois segundos.
A implementação de um único dispositivo de bloco sempre disponível requer o seguinte:
- Três instâncias de computação, máquinas virtuais ou bare metal (BM). Este último pode ser preferível, pois tem desempenho estável.
- Duas VCNs: uma pública, outra privada.
- Dois volumes em blocos do seu dispositivo de destino sempre disponível.
- (Recomendado) Ter os volumes em blocos pelo menos 10 VPU. Você pode querer considerar um nível ainda mais alto de IOPS, dependendo da agressividade de seu throughput de E/S e da distância entre os hosts espelhados (e volumes em blocos).
Portanto, o custo de implementação de um dispositivo de bloco sempre disponível é três vezes o custo da instância de computação mais duas vezes o custo do próprio dispositivo.
O diagrama a seguir ilustra essa arquitetura de referência.
diagrama de replicação de bloco sincronizado remoto-oracle.zip
A arquitetura tem os seguintes componentes:
- Dispositivo de Bloco Replicado Distribuído
O DRBD (Dispositivo de Bloco Replicado Distribuído) é um driver do kernel do Linux que mantém a conexão de rede entre dois dispositivos de bloco em instâncias remotas do Linux e replica as operações de E/S da instância de origem para a instância de destino.
- Marca-passo
Pacemaker é um gerenciador de recursos de cluster de alta disponibilidade de código aberto, comumente usado em ambientes Linux. Ele garante que aplicativos, serviços ou recursos sejam executados continuamente com tempo de inatividade mínimo, detectando falhas e reiniciando ou realocando automaticamente os serviços em outros nós de um cluster.
- Corosync
O Corosync é um produto de software de código aberto que estende o Pacemaker com semântica de restauração no caso de cérebro dividido.
- Iniciador e destino de iSCSI
iSCSI é um componente de software cliente e servidor que fornece um dispositivo SCSI através de uma rede.
Recomendações
- 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.
Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no Oracle Cloud Infrastructure, em seu data center local ou em 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 seus requisitos de fluxo de tráfego e segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.
- Cloud Guard
Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas de detector e respondedor. Essas receitas permitem que você especifique que tipo de violações de segurança geram um aviso e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública.
Aplique o Cloud Guard no nível da tenancy para cobrir o escopo mais amplo e reduzir a carga administrativa de manutenção de várias configurações.
Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.
- Zonas de Segurança
Para recursos que exigem segurança máxima, a Oracle recomenda o uso de zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita de políticas de segurança definida pela Oracle baseada nas melhores práticas. Por exemplo, os recursos de uma zona de segurança não devem ser acessíveis por meio da internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você criar e atualizar recursos em uma zona de segurança, o Oracle Cloud Infrastructure validará as operações de acordo com as políticas na receita de zona de segurança e negará as operações que violam qualquer uma das políticas.
- 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 do seu aplicativo.
- Largura de banda do balanceador de carga
Ao criar o balanceador de carga, você pode selecionar uma forma predefinida que forneça uma largura de banda fixa ou especificar uma forma personalizada (flexível), na qual você define uma faixa de largura de banda e permite que o serviço dimensione a largura de banda automaticamente com base nos padrões de tráfego. Com qualquer uma das abordagens, você pode alterar a forma a qualquer momento após criar o balanceador de carga.
Considerações
Considere o seguinte ao implantar essa arquitetura de referência.
- Desempenho
Você deve planejar duas vezes N de IOPS nominais em seu dispositivo sempre disponível para fornecer N IOPS aos seus usuários. Isso é causado pelo fato de que metade do desempenho é gasto em espelhamento em tempo real.
- Segurança
É altamente recomendável isolar os detalhes da implementação, dividindo a solução para redes públicas e privadas.
- Disponibilidade
Recomendamos implementar o dispositivo sempre disponível, pois o iSCSI para essa tecnologia é independente do sistema operacional, para que OS usuários possam desfrutar de verdadeira tolerância a falhas, quer executem Linux ou Windows em suas máquinas.
Todos os componentes de software da solução estão disponíveis publicamente como produtos de código aberto. Em particular, o driver DRBD é um componente integral do kernel baunilha do Linux e está disponível em qualquer distribuição do Linux.