Proteja Suas Máquinas Virtuais No Azure De Quedas

Proteja Suas Máquinas Virtuais No Azure De Quedas

O Azure opera em vários datacenters no mundo inteiro. Esses datacenters estão agrupados em regiões geográficas, oferecendo a você a flexibilidade de escolher onde rodar seus aplicativos e cargas de trabalho críticas. É importante entender como e onde as VMs (máquinas virtuais) operam no Azure, juntamente com suas opções para provisionar a disponibilidade e a redundância para atender quaisquer requisitos de conformidade ou legais.

O portal do Azure é hiperdinâmico, mudando rapidamente para se adaptar às necessidades contínuas emergentes da infraestrutura como serviço (IaaS). Existem três cenários que podem afetar a operação ou a atividade da máquina virtual do Azure: manutenção de hardware não planejada, tempo de inatividade inesperado e manutenção planejada.

Para reduzir o impacto do tempo de inatividade devido a qualquer um desses eventos, recomendamos fazer uso das seguintes opções para proteger aplicativos de missão crítica:

Conjunto de Disponibilidade: proteção de falhas em Hardware do datacenter. O Azure garante que as VMs colocadas em um Conjunto de disponibilidade sejam executadas em vários servidores físicos, racks de computação, unidades de armazenamento e comutadores de rede. Embora colocar suas máquinas virtuais em um conjunto de disponibilidade não proteja seu aplicativo de falhas de sistema operacional e nem específicas de aplicativo; isso limita o impacto das potencias falhas físicas de hardware, panes de rede ou interrupções de energia.

O Azure Fabric Controller (FC) é o componente da Plataforma de Serviços Azure responsável para provisionar e monitorar a condição das instâncias de computação do Azure. O Fabric Controller verifica o status do hardware e do software das instâncias do host e da máquina guest. Quando detecta uma falha, impõe os SLAs ao realocar automaticamente as instâncias da VM. O FC manipula automaticamente as falhas resultantes do hardware subjacente ou do software do sistema operacional na máquina virtual do host. O Azure cria uma instância da função em um servidor em funcionamento e a adiciona à rotação do balanceador de carga. Se o número de instâncias de função for maior que um, o Azure mudará o processamento para as outras instâncias de função em execução ao substituir o nó com falha.

Para cada camada de aplicativo, coloque várias instâncias de VM no mesmo conjunto de disponibilidade e coloque um balanceador de carga na frente das VMs configurando o HealthProbe que indique se a instância VM está íntegra. A investigação deve verificar se as funções críticas estão respondendo corretamente. Se houver falha com o HealthProbe, o balanceador de carga interromperá o envio de novas conexões para a instância não íntegra.

Use Discos Gerenciados Sempre: Os discos são automaticamente colocados em unidades de escala de armazenamento diferentes (Stamps). Se um Stamp falhar devido a uma falha de hardware ou de software, somente as instâncias da VM com discos nesses stamps falharão. Por exemplo, vamos supor que você tenha um aplicativo em execução em cinco VMs, e que as VMs estejam em um Conjunto de Disponibilidade. Os discos dessas VMs não serão armazenados no mesmo stamp, portanto, se um stamp ficar inativo, as outras instâncias do aplicativo continuarão em execução. Além de mais, Azure garante um SLA de 99,999%. Saiba que você tem três réplicas dos seus dados predeterminadamente com este serviço, o que proporciona alta durabilidade. Se uma ou duas réplicas apresentarem problemas, as réplicas restantes ajudarão a garantir a persistência dos seus dados e a alta tolerância contra falhas. 

Backup de VMs: o Backup do Azure fornece cópias de segurança consistentes com o aplicativo para cargas de trabalho da Microsoft. Ele usa o serviço shadow copy para garantir que os dados são gravados corretamente no armazenamento. Para VMs Linux, somente backups consistentes com os arquivos são possíveis, pois o Linux não tem uma funcionalidade equivalente ao serviço de sombra de volume. Para VMs Windows, Um Snapshot é tirado em conjunto com o serviço shadow copu para obter um snapshot consistente dos discos na máquina virtual sem precisar desligá-la. A extensão de backup na VM libera todas as gravações antes de tirar um snapshot consistente de todos os discos. Depois de tirar o snapshot, os dados são transferidos pelo Backup do Azure para o cofre de backup. Para tornar o processo de backup mais eficiente, o serviço identifica e transfere apenas os blocos de dados que foram alterados após o último backup.

Para restaurar, exiba os backups disponíveis por meio do Backup do Azure e, em seguida, inicie uma restauração.

Para VMs Linux, confira aqui.

Para proteger os aplicativos e dados contra falhas do datacenter, temos a oferta de Zonas de Disponibilidade: são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. Para garantir a resiliência, há um mínimo de três zonas separadas em todas as regiões habilitadas. É possível replicar os aplicativos e dados de maneira síncrona usando Zonas de Disponibilidade em uma região do Azure para alta disponibilidade.


Para proteção de recuperação de desastre regional total, faça uso da replicação assíncrona com o serviço de regiões emparelhadas mediante o serviço Site Recovery: Cada região do Azure é emparelhada com outra região na mesma área geográfica, formando juntas um par regional. A exceção é o Sul do Brasil, que está associado a uma região fora de sua área geográfica.

O Azure Site Recovery orquestra essa replicação e o failover sem afetar a produção de aplicações. Os dados replicados são armazenados no armazenamento do Azure, que fornece resiliência. Quando o failover ocorre, as VMs do Azure são criadas com base nos dados replicados.

O Azure Site Recovery fornece replicação com a freqüência de 30 em 30 segundos para o Hyper-V e continuamente para o VMware. Você pode definir limites de RPO para controlar as vezes que os pontos de recuperação de dados são criados, e você pode reduzir os RTOs com o Azure Site Recovery processo de recuperação automatizado, pois predeterminadamente ele é manual. A galeria do Azure Automation Runbook provê scritps para production-ready, application-specific que podem ser baixados e integrados com o Azure Site Recovery.

RESUMO

Crie um plano totalmente testado e aceito para a recuperação de qualquer tipo de falha que possa afetar a disponibilidade do sistema. Escolha uma arquitetura de recuperação de desastres em vários locais para os aplicativos de missão crítica. Identifique um proprietário específico do plano de recuperação de desastres, incluindo automação e testes.Certifique-se de que o plano esteja bem documentado e automatize o processo tanto quanto possível. Estabeleça uma estratégia de backup para todos os dados de referência e transacionais e teste a restauração desses backups regularmente. Treine a equipe de operações para executar o plano e executar regularmente simulações de desastres para validar e aprimorar o plano.

Entre para ver ou adicionar um comentário

Outros artigos de Milady Masís

Outras pessoas também visualizaram

Conferir tópicos