Implementação de zona única

Em implementações de zona única, várias instâncias de aplicativos são implementadas em uma zona. Se uma instância de aplicativo for executada em um único servidor virtual, os Placement Groups permitirão que esses servidores virtuais sejam provisionados em hosts físicos separados. O VPC Autoscale pode ser usado para permitir o ajuste dinâmico da capacidade com base nas alterações da carga de trabalho. As implementações de zona única oferecem soluções econômicas com 99.9 disponibilidade de infraestrutura. Essa implementação pode ser apropriada para ambientes de não produção ou aplicativos não essenciais aos negócios. No entanto, as implementações de zona única não oferecem proteção contra interrupções de zona.

Ao utilizar esse modelo de implantação, uma boa prática é evitar desequilíbrios zonais. Um desequilíbrio zonal ocorre quando a capacidade — por exemplo, as Instâncias de Servidor Virtual (VSIs) do VPC — não está distribuída uniformemente entre as zonas. Considere um exemplo em que uma carga de trabalho seja implantada com 70% de sua capacidade de VSI na zona 1, 20% na zona 2 e 10% na zona 3. Caso a zona 1 falhe, a carga de trabalho poderá continuar disponível, mas com apenas 30% de sua capacidade. Uma solução é alocar mais recursos caso ocorra uma interrupção na zona 1, mas essa interrupção pode causar um pico anormal na demanda de capacidade nas demais zonas. Uma solução melhor é eliminar o desequilíbrio e garantir que a capacidade necessária seja distribuída entre as zonas, com uma margem adicional de cerca de 17% em cada zona para compensar a perda de qualquer uma delas. Isso garante que a carga de trabalho permaneça disponível e possa operar em plena capacidade, caso ocorra a perda de uma zona.

Implementação em várias zonas e em uma única região

Em uma implementação de várias zonas e uma única região, várias instâncias de aplicativos são implementadas em duas ou mais zonas de disponibilidade dentro da região. Implantações multizona em uma única região podem oferecer até 99.99 % de disponibilidade da infraestrutura quando o aplicativo é implantado em três zonas de disponibilidade. Essa implantação protege o aplicativo contra falhas de zona e é adequada para cargas de trabalho corporativas em ambiente de produção com requisitos de disponibilidade > 99.9 %. A disponibilidade real do aplicativo depende do projeto de alta disponibilidade do aplicativo.

Ao utilizar esse modelo de implantação, evite desequilíbrios entre as zonas. Ocorre um desequilíbrio zonal quando a capacidade — por exemplo, os servidores de IBM Cloud® Virtual Servers for Virtual Private Cloud (VSIs) — não está distribuída uniformemente entre as zonas. Considere um exemplo em que uma carga de trabalho seja implantada com 70% de sua capacidade de VSI na zona 1, 20% na zona 2 e 10% na zona 3. Se a zona 1 falhar, a carga de trabalho poderá permanecer disponível, mas com apenas 30% de sua capacidade. Você poderia alocar mais recursos quando ocorrer uma interrupção, mas uma interrupção pode causar um pico anormal na demanda de capacidade nas demais zonas. Em vez disso, elimine o desequilíbrio distribuindo a capacidade necessária uniformemente entre as zonas, com uma margem adicional de aproximadamente 17% por zona para compensar a perda de qualquer uma delas. Isso garante que a carga de trabalho permaneça disponível e possa operar em plena capacidade caso uma zona falhe.

Implementação em várias zonas e regiões

Uma implementação em várias zonas e regiões oferece proteção contra interrupções na região. Essa implementação é recomendada para aplicativos de missão crítica com requisitos de disponibilidade contínua ou quase contínua. Essa implementação também oferece suporte à recuperação de desastres e à continuidade dos negócios fora da região para aplicativos com requisitos de distância geográfica cruzada ou de separação específica.

As implementações em várias zonas dependem da replicação de dados com reconhecimento de aplicativos entre as zonas de disponibilidade e oferecem suporte a padrões de arquitetura ativo-ativo e ativo-reserva. As implementações em várias zonas e regiões suportam padrões de arquitetura para aplicativos corporativos com disponibilidade contínua e requisitos sempre ativos. As tabelas a seguir mostram uma comparação das diferentes opções de implementação e o uso recomendado.

A Estrutura de Arquitetura a seguir fornece considerações de projeto e decisões de arquitetura para a implementação de aplicativos resilientes na infraestrutura IBM Cloud Virtual Private Cloud (VPC). Ele abrange os seguintes aspectos e domínios da solução:

• Redes: Balanceamento de carga, sistema de nomes de domínio
• Segurança: Segurança de dados
• Resiliência: Alta disponibilidade, Backup e restauração, Recuperação de desastres
• Gerenciamento de serviços: Monitoramento, registro, auditoria, alerta

A Estrutura de Projeto de Arquitetura oferece uma abordagem consistente para projetar soluções de nuvem, abordando os requisitos em um conjunto de aspectos e domínios. Os domínios são áreas arquitetônicas que precisam ser consideradas em qualquer solução empresarial, independentemente da tecnologia.

Lógica de nova tentativa do cliente para aplicativos altamente disponíveis

Você é responsável por criar aplicativos clientes que possam lidar com erros temporários de forma eficaz. Os erros temporários incluem erros de rede e falhas temporárias que são introduzidas pela implementação de alta disponibilidade de um serviço, como quando um serviço regional se recupera de uma falha zonal. Para obter mais informações sobre serviços específicos IBM Cloud, consulte a documentação do serviço para alta disponibilidade e recuperação de desastres.

Muitos dos IBM Cloud SDKs são criados com base no IBM Cloud SDK Common, que oferece suporte a novas tentativas automáticas projetadas para lidar com erros HTTP específicos, como os erros 429 e 503. O SDK não trata todos os erros automaticamente. Para tirar proveito da lógica de repetição, você deve configurar o SDK corretamente.

Alguns serviços IBM Cloud suportam protocolos de código aberto, e pode ser apropriado usar SDKs de código aberto. Examine esses SDKs para determinar se eles são úteis para seu aplicativo e se oferecem funções de repetição adequadas.

A lógica de repetição varia de acordo com o tipo de serviço IBM Cloud e o tipo de operação. Algumas operações com falha produzem códigos de status que permitem a repetição e outras produzem códigos de status que não permitem a repetição. As operações de leitura e HTTP GET com falha geralmente podem ser repetidas usando backoff exponencial com um período de tempo fixo. O backoff exponencial é uma estratégia de nova tentativa para gerenciar novas tentativas após uma operação com falha, como uma solicitação de rede ou uma chamada de API. Ele aumenta gradualmente o atraso entre as novas tentativas em um padrão exponencial, o que reduz o risco de sobrecarga do sistema. As falhas que devem ser repetidas dependem do tipo de falha e do serviço específico IBM Cloud. Para obter mais informações, consulte a documentação e o SDK de cada serviço IBM Cloud.

Falhas de gravação, HTTP PUT, POST, DELETE e outras operações provavelmente não podem ser recuperadas com o uso de um mecanismo simples de repetição, a menos que esteja claro que a operação não foi concluída e que a lógica documentada do cliente indique que uma nova tentativa é apropriada. Quando uma operação que altera o estado de um sistema, como a criação de um recurso, falha, geralmente não fica claro o que causou a falha. Devido a essa incerteza, você não pode confiar em uma lógica simples de repetição para corrigir o problema. Em vez disso, use métodos mais avançados que foram projetados especificamente para o serviço IBM Cloud.

A repetição do cliente melhora a disponibilidade de um único cliente, e as cargas de trabalho podem ser compostas por muitos clientes. O registro de falhas de clientes em um serviço de registro centralizado, como IBM Cloud Logs, permite a análise de falhas e disponibilidade de toda a carga de trabalho.