Disponibilidade de aplicações em AKS em Azure Stack HCI

AKS on Azure Stack HCI é uma plataforma de contentores totalmente suportada onde você pode executar aplicações nativas da nuvem em Kubernetes, que é baseada na plataforma de orquestração de recipientes Kubernetes. A arquitetura suporta a execução de cargas de Windows e Linux em cima do Azure Stack HCI e Windows Server 2019 Datacenter.

A arquitetura atual da AKS on Azure Stack HCI é construída com agrupamento de failover e migração ao vivo automaticamente ativada para clusters alvo (carga de trabalho). Durante vários eventos de interrupção, as máquinas virtuais que acolhem cargas de trabalho dos clientes são livremente movidas sem tempo de inatividade percebido para a aplicação. Isto significa que um cliente empresarial tradicional que está a levantar e a mudar uma aplicação antiga como singleton para AKS em Azure Stack HCI obterá um tempo de uptime semelhante (ou melhor) do que o que é experimentado atualmente ao executar uma aplicação antiga em VMs.

Este tópico descreve alguns conceitos fundamentais para utilizadores que pretendem executar aplicações contentorizadas em AKS em Azure Stack HCI com migração ao vivo habilitada a garantir que as aplicações estão disponíveis durante uma interrupção. A terminologia de Kubernetes, como perturbação voluntária e perturbação involuntária,é usada para se referir ao tempo de inatividade de uma aplicação em execução numa vagem.

O que é migração ao vivo?

A migração ao vivo é uma funcionalidade Hiper-V que permite mover máquinas virtuais de um anfitrião Hiper-V para outro sem tempo de inatividade percebido. O principal benefício da migração ao vivo é a flexibilidade; as máquinas virtuais em execução não estão ligadas a uma única máquina hospedeira. Isto permite ações como drenar um grupo específico de máquinas virtuais antes de desativar ou atualizar o hospedeiro. Quando emparelhada com Windows Failover Clustering, a migração ao vivo permite a criação de sistemas altamente disponíveis e tolerantes a falhas.

A arquitetura atual da AKS em Azure Stack HCI assume que os clientes têm migração viva ativada no seu ambiente agrupado Azure Stack HCI. Nesse caso, todos os VMs de nó de trabalhadores kubernetes serão criados com migração viva configurada. Estes nós podem ser movidos em torno de anfitriões físicos em caso de perturbação para garantir que a plataforma está altamente disponível.

Diagrama mostrando AKS em Azure Stack HCI com Clustering Failover habilitado

Para um cliente que executa uma aplicação antiga como singleton em cima de Kubernetes, esta arquitetura irá atender às suas necessidades de alta disponibilidade. A Kubernetes vai gerir o agendamento de cápsulas nos nós de trabalhadores disponíveis, enquanto a migração ao vivo vai gerir o agendamento de VMs de nó de trabalhadores em anfitriões físicos disponíveis.

Diagrama mostrando um exemplo de aplicação de legado correndo como um singleton

Cenários de interrupção de aplicações

Um estudo comparativo dos tempos de recuperação das aplicações em execução em VMs em AKS on Azure Stack HCI mostra claramente que há um impacto mínimo na aplicação quando ocorrem eventos comuns de perturbação. Três cenários de perturbação de exemplo incluem:

  • Aplicação de uma atualização que resulta num reinício da máquina física.
  • Aplicação de uma atualização que envolve a recriação do nó do trabalhador.
  • Falha de hardware não planeada de uma máquina física.

Nota

Estes cenários pressupõem que o proprietário da aplicação ainda utiliza afinidade de Kubernetes e configurações anti-afinidade para garantir o agendamento adequado de cápsulas através dos nós dos trabalhadores.

Evento de interrupção Execução de aplicações em VMs em Azure Stack HCI Execução de aplicações em VMs em AKS em Azure Stack HCI
Aplicação de uma atualização que resulta num reboot da máquina física Sem impacto Sem impacto
Aplicação de uma atualização que envolve recriar o nó do trabalhador (ou reiniciar o VM) Sem impacto Varia
Falha de hardware não planeada de uma máquina física 6-8 minutos 6 -8 minutos

Aplicação de uma atualização que resulta num reboot da máquina física

Durante um evento de manutenção física do anfitrião, como a aplicação de uma atualização que resulta no reinício de uma máquina hospedeira, não é esperado qualquer impacto para aplicações que sejam executando no cluster. O administrador do cluster drenaria o hospedeiro e garantiria que todos os VMs são migrados ao vivo antes de aplicar a atualização.

Aplicação de uma atualização que envolve recriar o nó do trabalhador

Este cenário envolve derrubar um vM de nó de trabalhador para realizar a manutenção de rotina. Para se preparar para a atualização, o administrador do cluster drenaria e isolaria o nó, para que todas as cápsulas fossem despejadas para um nó de trabalhador disponível antes de aplicar atualizações. Uma vez concluída a atualização, o nó do trabalhador será reencontrado e disponibilizado para agendamento.

Nota

A disponibilidade de uma aplicação variará, uma vez que incluiria o tempo necessário para descarregar a imagem do contentor base, especialmente para imagens maiores armazenadas na nuvem pública. Por isso, recomenda-se a utilização de pequenas imagens de recipientes de base, e para Windows recipientes, recomenda-se a utilização da nano server imagem base.

Falha de hardware não planeada de uma máquina física

Neste cenário, ocorre um evento de perturbação involuntária a uma máquina física que hospeda um recipiente/pod de aplicação legado num dos VMs do nó do trabalhador. O agrupamento de failover colocará o hospedeiro em estado isolado, e depois de um período de 6 a 8 minutos, iniciará o processo de migração ao vivo destes VMs para os hospedeiros sobreviventes. Neste caso, o tempo de inatividade da aplicação é o equivalente ao tempo necessário para reiniciar os VMs de hospedeiro e de nó de trabalhador.

Conclusão

AKS on Azure Stack HCI e as tecnologias de clustering failover são ambas concebidas para garantir que os ambientes de computação estão altamente disponíveis e tolerantes a falhas. No entanto, o proprietário da aplicação ainda tem de configurar implementações para utilizar funcionalidades de Kubernetes, como, por DeploymentsAffinity MappingRelicaSets exemplo, para garantir que as cápsulas são resistentes em cenários de perturbação.