Entendendo a alta disponibilidade e a recuperação de desastre para o Red Hat OpenShift on IBM Cloud
Alta disponibilidadeA capacidade de um serviço ou carga de trabalho de resistir a falhas e continuar fornecendo capacidade de processamento de acordo com algum nível de serviço predefinido. (HA) é a capacidade de um serviço permanecer operacional e acessível na presença de falhas inesperadas. A recuperação de desastresA capacidade de um serviço ou carga de trabalho de se recuperar de incidentes raros e importantes e de falhas em larga escala, como a interrupção do serviço. Isso inclui um desastre físico que afeta toda uma região, a corrupção de um banco de dados ou a perda de um serviço que contribui para uma carga de trabalho. O impacto excede a capacidade do projeto de alta disponibilidade de lidar com ele. é o processo de recuperação da instância de serviço para um estado de funcionamento.
Red Hat OpenShift on IBM Cloud é um serviço regional ou zonal altamente disponível, projetado para disponibilidade durante uma interrupção regional ou zonal. O Red Hat OpenShift on IBM Cloud foi projetado para atender aos Objetivos de Nível de Serviço (SLO) com o plano Standard.
Para obter mais informações sobre a região disponível e os locais do data center, consulte Disponibilidade de serviço e infraestrutura por local.
Arquitetura de alta disponibilidade
Red Hat OpenShift on IBM Cloud a arquitetura cria alta disponibilidade nos níveis regional, de zona e de cluster.
- Disponibilidade de região
- Cada região é configurada com um balanceador de carga altamente disponível que seja acessível por meio do terminal de API específico da região. O balanceador de carga roteia as solicitações recebidas e de saída para os clusters nas zonas regionais. A probabilidade de uma falha regional integral é baixa. No entanto, para considerar essa falha, é possível configurar diversos clusters em diferentes regiões e conectá-los usando um balanceador de carga externo. Se uma região inteira falhar, o cluster da outra região poderá assumir a carga de trabalho.
- Disponibilidade de cluster e zona
- Uma falha de zona afeta todos os hosts de cálculo físico e armazenamento NFS. As falhas incluem energia, resfriamento, rede ou indisponibilidades de armazenamento e desastres naturais, como inundações, terremotos e furacões. Para proteger contra uma falha de zona, deve-se ter clusters em duas zonas diferentes que são balanceadas por carga por um balanceador de carga externo. Crie um cluster em um local com várias zonas, que distribui o mestre entre as zonas. Ou considere a possibilidade de configurar um segundo cluster em outra zona.
- Disponibilidade de várias zonas
- Os clusters de várias zonas distribuem cargas de trabalho em vários nós de trabalho e zonas, criando proteção adicional contra falhas de zona. Os nós de trabalho são implantados automaticamente com três réplicas espalhadas por várias zonas. Se uma zona inteira sofrer uma interrupção, sua carga de trabalho será agendada para nós de trabalho nas outras zonas, protegendo seu aplicativo da interrupção.
- Balanceamento de carga global
- Para proteger seu aplicativo contra uma falha do mestre ou para clusters clássicos que devem residir em uma das regiões de várias zonas compatíveis, você pode criar vários clusters em diferentes zonas de uma região e conectá-los a um balanceador de carga global.
Distribuição de recursos para alta disponibilidade.
Seus usuários são menos propensos a experienciar o tempo de inatividade quando você distribui seus apps em diversos nós do trabalhador, zonas e clusters. Recursos integrados, como balanceamento de carga e isolamento, aumentam a resiliência com relação a potenciais falhas com hosts, redes ou apps. Revise estas potenciais configurações de cluster que são ordenadas com graus crescentes de disponibilidade. Para obter mais informações sobre como os recursos do IBM Cloud são distribuídos entre zonas e regiões geográficas, consulte a documentação de Locais.
- Clusters de zona única
- Somente clássico
- Os clusters de zona única têm nós de trabalho que são distribuídos em hosts físicos separados dentro da mesma zona. Essa opção protege contra determinadas interrupções, como durante uma atualização principal, e é mais simples de gerenciar. No entanto, ele não protege seus aplicativos se toda uma zona sofrer uma interrupção.
- Clusters de várias zonas
- Clássico VPC
- Os clusters de várias zonas têm nós de trabalho implantados automaticamente com três réplicas espalhadas por várias zonas. Se uma zona inteira sofrer uma interrupção, sua carga de trabalho será agendada para nós de trabalho nas outras zonas, protegendo seu aplicativo da interrupção.
- Vários clusters vinculados a balanceadores de carga
- Clássico VPC
- Vários clusters podem ser configurados na mesma zona ou em zonas diferentes e conectados por meio de um balanceador de carga global. Essa opção é útil se você precisar provisionar um cluster em uma região de zona única, mas ainda quiser os benefícios da disponibilidade de várias zonas.
Recursos de alta disponibilidade
Analise os recursos disponíveis para fornecer alta disponibilidade para seus aplicativos e serviços.
| Recursos | Descrição |
|---|---|
| Opções de antiafinidade | Use regras de antiafinidade para distribuir a implantação de pods pelos nós de trabalho em vez de restringir a implantação a nós específicos. Isso proporciona mais flexibilidade para sua carga de trabalho. |
| Conjuntos de réplicas | Para aumentar a disponibilidade de seu app, é possível especificar um conjunto de réplicas em sua implementação. Se uma instância do app fica inativa, o Kubernetes acelera automaticamente uma nova instância de seu app para manter o número especificado de instâncias do app. |
| Balanceamento de carga em várias zonas (Clássico) | Quando você cria um cluster clássico de várias zonas, um balanceador de carga de várias zonas é criado automaticamente em cada zona em que o cluster reside para lidar com todas as solicitações de entrada para seus aplicativos e balancear as solicitações entre os balanceadores de carga de aplicativos (ALBs) nas zonas do cluster. Ele também permite verificações de funcionamento para os endereços IP públicos do Ingress. |
| Balanceamento de carga de VPC (VPC) | Quando você cria um cluster de VPC, um balanceador de carga de VPC é criado automaticamente para lidar com todas as solicitações de entrada para seus aplicativos e balancear as solicitações entre os balanceadores de carga de aplicativos (ALBs) nas zonas do cluster. Ele também permite verificações de funcionamento para os endereços IP públicos do Ingress. |
| Cluster Autoscaler | O complemento autoscaler de cluster dimensiona automaticamente os pools de trabalho em seu cluster para aumentar ou diminuir o número de nós de trabalho no pool de trabalho com base nas necessidades de dimensionamento de suas cargas de trabalho programadas. |
Recursos de recuperação de desastres
A estratégia geral para recuperação de desastres é configurar o armazenamento e os backups de seus dados com soluções como Portworx.
Red Hat OpenShift on IBM Cloud oferece suporte aos seguintes recursos de recuperação de desastres:
| Recursos | Descrição |
|---|---|
| Portworx | Uma solução de armazenamento definida por software de terceiros e altamente disponível que você pode usar para gerenciar o armazenamento local persistente para seus bancos de dados em contêineres e outros aplicativos com estado, ou para compartilhar dados entre pods em várias zonas. Revisar os pré-requisitos |
| OpenShift Recuperação de desastres regional do Data Foundation(ODF) | Uma solução de recuperação de desastres que oferece uma recuperação automatizada com "um clique" se houver um desastre regional. Os aplicativos são automaticamente reimplantados em um site designado OpenShift Container Platform com um cluster ODF disponível em outra região. |
| Cloud Object Storage (COS) | Uma opção de armazenamento persistente e altamente disponível que é montada em seus aplicativos, disponível como um plug-in. Analise as limitações. |
| Recuperação automática | O sistema de Recuperação automática usa várias verificações para consultar o status de funcionamento do nó do trabalhador. Se a Recuperação automática detectar um nó do trabalhador não funcional com base nas verificações configuradas, ela acionará uma ação corretiva, como reinicializar um nó do trabalhador VPC ou recarregar o sistema operacional em um nó do trabalhador clássico. |
| Portabilidade de dados com o Velero | Uma opção de terceiros para exportar dados do seu cluster para uma instância do IBM COS ou outro provedor s3. |
Portabilidade de dados usando a CLI do kubectl |
Exporte dados usando a CLI do kubectl. |
Analise as opções adicionais de exportação de dados, como rclone ou OADP.
Objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO)
| Recursos | RTO e RPO | Considerações |
|---|---|---|
| Portworx | RTO = <60s, RPO = <60s- 15m | Os valores diferem entre as configurações assíncronas e síncronas (também conhecidas como Metro DR). Para obter mais informações, consulte Configurando recuperação de desastres com Portworx. |
| Recuperação de desastres regionais do ODF | RTO = 0, RPO = 0 | Esses valores se aplicam somente ao nível do cluster. O DR regional e metropolitano não está disponível no momento. |
| Cloud Object Storage | Consulte os documentos sobre armazenamento de objetos. |
Como o site IBM® ajuda a garantir a recuperação de desastres
IBM® toma medidas específicas de recuperação para Red Hat OpenShift on IBM Cloud se ocorrer um desastre.
Como o IBM se recupera de falhas
Se houver uma falha regional ou de zona, o site IBM será responsável pela recuperação dos componentes. IBM tentará restaurar o cluster na mesma região com base no último estado no armazenamento persistente interno. IBM atualiza e recupera componentes operacionais dentro do cluster, como o balanceador de carga do aplicativo Ingress e o plug-in de armazenamento de arquivos.
IBM também oferece a capacidade de integração com outros serviços do IBM Cloud, como provedores de armazenamento, para que seja possível fazer backup e restaurar os dados. É sua responsabilidade implementar essas integrações.
Como o site IBM mantém os serviços
Todos os upgrades seguem as práticas recomendadas de serviço do site IBM, incluindo planos de recuperação e processos de reversão. A manutenção regular pode causar interrupções curtas, atenuadas pela lógica de nova tentativa de disponibilidade do cliente. As alterações são implementadas sequencialmente, região por região e zona por zona dentro de uma região. O site IBM reverte as atualizações ao primeiro sinal de defeito.
As alterações complexas são ativadas e desativadas com sinalizadores de recursos para controlar a exposição.
As alterações que afetam as cargas de trabalho dos clientes são detalhadas nas notificações do site IBM Cloud. Para obter mais informações sobre manutenção planejada, anúncios e notas de versão que afetam esse serviço, consulte Monitoramento de notificações e status.
Suas responsabilidades pela alta disponibilidade e recuperação de desastres
É sua responsabilidade testar continuamente seu plano de HA e DR.
Podem ocorrer interrupções na conectividade da rede e curtos períodos de indisponibilidade de um serviço. É sua responsabilidade garantir que o código-fonte do aplicativo inclua a lógica de nova tentativa de disponibilidade do cliente para manter a alta disponibilidade do aplicativo.
Você é responsável por configurar seu cluster para atingir o nível adequado de disponibilidade para seus aplicativos e serviços. O nível de disponibilidade configurado para o seu cluster impacta a sua cobertura nos termos do acordo de nível de serviço de HA da IBM Cloud. Por exemplo, para receber cobertura completa de HA sob os termos do SLA, deve-se configurar um cluster multizona com um total de pelo menos seis nós do trabalhador, sendo dois nós do trabalhador por zona distribuídos uniformemente em três zonas.
Você é responsável pela recuperação das cargas de trabalho que executam o cluster e os dados do aplicativo. Para obter mais informações sobre suas responsabilidades em relação à recuperação de desastres, consulte Suas responsabilidades ao usar Red Hat OpenShift on IBM Cloud.
Gerenciamento de mudanças
O gerenciamento de alterações inclui tarefas como upgrades, alterações de configuração e exclusão. Tenha em mente os seguintes pontos para reduzir o tempo de inatividade ou a perda de dados de sua carga de trabalho.
-
Recomenda-se conceder aos usuários e processos as funções e ações do IAM com o mínimo de privilégio necessário para o trabalho deles. Por exemplo, limitar a capacidade de excluir recursos de produção.
-
Use as ferramentas de API, CLI ou console para aplicar as atualizações de nós de trabalho fornecidas que incluem patches de sistema operacional ou para solicitar que os nós de trabalho sejam reinicializados, recarregados ou substituídos.
-
Use a API, a CLI ou as ferramentas de console para aplicar as informações fornecidas Kubernetes atualizações do mestre e major, minor e atualizações do nó de trabalho de patches. Certifique-se de revisar as informações e os requisitos de cada atualização de versão para evitar problemas ou tempo de inatividade.
-
Certifique-se de que os nós de trabalho do cluster executem a versão mais recente do Ubuntu mais recente.
-
Certifique-se de entender os cronogramas de lançamento de todos os complementos que você executa no seu cluster.
Considerações sobre a implantação de aplicativos e serviços
A forma como você configura o cluster afeta o nível de disponibilidade que você obtém para seus aplicativos e serviços. Quanto mais amplamente você distribui a configuração entre diversos nós do trabalhador e clusters, menos provável que os usuários tenham que experimentar tempo de inatividade com seu app.
Revise as potenciais configurações de app a seguir que são ordenadas com graus crescentes de disponibilidade.
- Uma implantação com n+2 pods que são gerenciados por um conjunto de réplicas em um único nó.
- Uma implementação com n+2 pods que são gerenciados por um conjunto de réplicas e distribuídos em diversos nós (antiafinidade) em um cluster de zona única.
- Uma implementação com n+2 pods que são gerenciados por um conjunto de réplicas e distribuídos entre diversos nós (antiafinidade) em um cluster de diversas zonas entre zonas.
Consulte a documentação a seguir para obter informações sobre a criação de uma carga de trabalho altamente disponível.