Considerações de continuidade de negócio para cargas de trabalho do Azure Virtual Desktop
Este artigo aborda a área de design de continuidade de negócio de uma carga de trabalho do Azure Virtual Desktop. Para fortalecer a implementação do Azure Virtual Desktop da sua organização e ajudar a manter os dados seguros, deve implementar uma estratégia de continuidade de negócio e recuperação após desastre. Uma boa estratégia ajuda a manter as suas aplicações e cargas de trabalho em funcionamento durante o serviço planeado e não planeado ou as falhas do Azure.
Para ajudar a garantir que os seus utilizadores se conseguem ligar durante uma indisponibilidade da região do Azure, poderá ter de replicar máquinas virtuais pessoais (VMs) para uma região do Azure diferente, a sua localização secundária. Durante as interrupções, a região primária faz a ativação pós-falha para as VMs replicadas na localização secundária. Os utilizadores podem continuar a aceder a aplicações a partir da localização secundária sem interrupções. Além de replicar VMs, também tem de garantir que as identidades de utilizador estão acessíveis na localização secundária. Pode utilizar contentores de perfil para tornar as identidades acessíveis. Como alternativa à replicação de VMs, pode utilizar vários conjuntos de anfitriões agrupados com aprovisionamento automatizado entre regiões.
Importante
Este artigo faz parte da série de cargas de trabalho do Azure Well-Architected Framework do Azure Virtual Desktop . Se não estiver familiarizado com esta série, recomendamos que comece com O que é uma carga de trabalho do Azure Virtual Desktop?.
Serviço Azure Virtual Desktop
Impacto: Fiabilidade
No serviço Azure Virtual Desktop, a Microsoft gere algumas áreas de responsabilidade e o cliente gere outras.
- A Microsoft controla metadados como conjuntos de anfitriões, grupos de aplicações e áreas de trabalho. Os metadados estão sempre disponíveis. Não é necessário que o cliente efetue uma configuração adicional para replicar dados ou configurações do conjunto de anfitriões. A infraestrutura de gateway que liga as pessoas aos anfitriões de sessão foi concebida para ser um serviço global e altamente resiliente que a Microsoft gere.
- As áreas geridas pelo cliente envolvem as VMs que o Azure Virtual Desktop utiliza e as definições e configurações que são exclusivas da implementação do cliente.
A tabela seguinte fornece informações detalhadas sobre as áreas que cada parte gere:
Gerida pela Microsoft | Gerido pelo cliente |
---|---|
Balanceador de carga | Rede |
Mediador de sessões | Anfitriões de sessões |
Gateway | Armazenamento |
Diagnóstico | Dados do perfil de utilizador |
Plataforma de identidade da cloud | Identidade |
Recomendações
- Tenha em atenção as suas responsabilidades no âmbito do modelo de responsabilidade partilhada.
- Certifique-se de que a sua organização gere ativamente áreas que estão sob a responsabilidade do cliente. Os exemplos incluem as VMs que o Azure Virtual Desktop utiliza, os dados do perfil de utilizador e as definições que são exclusivas do seu ambiente.
Conjuntos de anfitriões
Impacto: Fiabilidade, Otimização de Custos
Se conjuntos distintos de utilizadores tiverem diferentes requisitos de continuidade de negócio e recuperação após desastre, recomendamos que utilize vários conjuntos de anfitriões com configurações diferentes. Por exemplo, os utilizadores com uma aplicação crítica para a empresa podem utilizar um conjunto de anfitriões totalmente redundante com capacidades de recuperação após desastre geográfico. Contudo, os utilizadores de desenvolvimento e teste podem utilizar um conjunto de anfitriões separado sem qualquer recuperação após desastre.
Para cada conjunto de anfitriões do Azure Virtual Desktop, pode basear a sua estratégia de continuidade de negócio e recuperação após desastre num modelo ativo-ativo ou ativo-passivo.
Cenários ativos-ativos
A configuração recomendada para um cenário ativo-ativo utiliza dois conjuntos de anfitriões, um conjunto de anfitriões por região. Não é necessária nenhuma intervenção de administrador para a ativação pós-falha. Tal como acontece durante as operações normais, o conjunto de anfitriões secundário fornece aos utilizadores recursos do Azure Virtual Desktop. Os utilizadores têm de ter uma boa compreensão das capacidades que o Azure Virtual Desktop oferece e como utilizá-las.
Cada conjunto de anfitriões tem a sua própria conta de armazenamento para perfis de utilizador persistentes. Se os planos de recuperação após desastre exigirem que os perfis persistam, terá de utilizar a funcionalidade de cache na cloud do FSLogix para sincronizar perfis entre regiões. Para evitar conflitos de perfis, não permita que os utilizadores acedam a ambos os conjuntos de anfitriões ao mesmo tempo.
Para obter mais informações, veja Continuidade de negócio multi-região e recuperação após desastre (BCDR) para o Azure Virtual Desktop.
Cenários ativos-passivos
Num cenário ativo-passivo, a implementação do anfitrião é semelhante à configuração num cenário ativo-ativo. Para cada conjunto de anfitriões na região primária, é implementado outro conjunto de anfitriões na região secundária. Mas num cenário ativo-passivo, menos recursos de computação estão ativos na região secundária do que na região primária. É possível que nenhum recurso de computação esteja ativo na região secundária. Normalmente, o número de recursos ativos depende do orçamento disponível. Tenha em atenção que a capacidade do Azure não é garantida durante as indisponibilidades regionais quando os recursos inativos têm de ser ativados. A capacidade só é garantida se as VMs estiverem ativas. Considere utilizar reservas de capacidade a pedido para reservar a capacidade do Azure para cenários de recuperação após desastre. Para obter mais informações, veja Reserva de capacidade a pedido.
Tenha também em atenção os seguintes pontos sobre modelos ativos-passivos:
- Cada conjunto de anfitriões tem as suas próprias contas de armazenamento para perfis de utilizador persistentes.
- Se os perfis têm de persistir entre regiões, pode utilizar a funcionalidade de cache na cloud para sincronizar perfis.
Se planear utilizar um conjunto de anfitriões pessoal, pode utilizar o Azure Site Recovery para replicar anfitriões de sessão da região primária para a região secundária. Para seguir esta abordagem, tem de ter a infraestrutura adequada implementada.
Recomendações
- Utilize vários conjuntos de anfitriões se tiver conjuntos distintos de utilizadores com diferentes requisitos de recuperação após desastre de continuidade de negócio.
- Avalie a funcionalidade de cache na cloud do FSLogix para sincronizar perfis entre regiões se os perfis precisarem de ser protegidos.
- Informe os utilizadores sobre a utilização adequada dos recursos se utilizar uma configuração ativa-ativa.
- Utilize Site Recovery para replicar anfitriões de sessão da região primária para a região secundária quando utiliza um conjunto de anfitriões pessoal.
Planeamento de capacidade
Impacto: Fiabilidade, Otimização de Custos
O Azure Virtual Desktop funciona dentro das restrições dos limites de capacidade do Azure.
Por exemplo, o Azure impõe limites ao nível da subscrição ao número de VMs que pode implementar no Azure Virtual Desktop. Por exemplo, uma subscrição pode ter um limite de 25 000 VMs. Para ajudar a garantir operações suaves, tem de estar ciente deste limite e planear implementações em conformidade. O dimensionamento para além deste limite pode exigir subscrições adicionais ou estratégias alternativas, o que pode ter implicações de custos.
Outro exemplo são os anfitriões de sessão num conjunto de anfitriões. No Azure Virtual Desktop, cada conjunto de anfitriões tem os seus próprios limites no número de anfitriões de sessão que podem acomodar sessões de utilizador. A série de VMs e o tamanho que selecionar para o conjunto de anfitriões determinam o número máximo de anfitriões de sessão que pode utilizar. Para otimizar o desempenho e a experiência do utilizador, tem de considerar estes limites ao conceber a sua implementação.
Para obter mais informações sobre as restrições da plataforma, veja Limitações do Azure Virtual Desktop.
Recomendações
- Monitorizar e planear limites de subscrição. Monitorize de perto as implementações do Azure Virtual Desktop e controle a utilização de recursos na sua subscrição. Ao monitorizar proativamente a capacidade, pode identificar potenciais desafios no início e pode tomar medidas adequadas para evitar atingir limites.
- Considere dimensionar várias subscrições se for necessário um dimensionamento adicional ou trabalhar com suporte do Azure para ajustar os limites com base nos seus requisitos empresariais.
- Dimensione horizontalmente para uma procura elevada. Para lidar com um grande número de utilizadores, considere dimensionar horizontalmente ao criar vários conjuntos de anfitriões.
Perfis FSLogix e Anexação de Aplicações
Impacto: Fiabilidade, Otimização de Custos
Para minimizar a quantidade de dados nos perfis de utilizador, redirecione os dados do utilizador para uma solução de armazenamento. Quando minimiza os dados nos perfis de utilizador, também minimiza a proteção que precisa de fornecer para os perfis. Uma estratégia de recuperação sem perfil diminui a sobrecarga, mas pode afetar a experiência do utilizador em cenários de recuperação após desastre.
Em alguns casos, o conteúdo do contentor de perfil precisa de uma solução separada de continuidade de negócio e recuperação após desastre, uma vez que os requisitos do contentor de perfil diferem dos requisitos de contentor do Office. Nesta situação, pode separar os dois e gerir cada um de forma independente.
Para perfis FSLogix e Anexação de Aplicações, é melhor considerar três cenários:
Os danos locais de dados, metadados ou recursos. Neste caso, pode utilizar Azure Backup:
- Se utilizar Ficheiros do Azure armazenamento, pode configurar a Cópia de Segurança para Ficheiros do Azure.
- Se utilizar Azure NetApp Files para armazenamento, pode configurar a Cópia de Segurança para instantâneos de Azure NetApp Files.
Em alternativa, pode utilizar o serviço de cópia de segurança para proteger ficheiros e pastas em VMs de servidor.
A falha de um único datacenter de uma zona de disponibilidade numa região do Azure. Neste cenário, pode utilizar Ficheiros do Azure com armazenamento com redundância entre zonas premium para tirar partido do suporte para zonas de disponibilidade. Os perfis FSLogix e os discos rígidos virtuais (VHDs) anexados da Aplicação permanecem disponíveis durante as interrupções do datacenter.
Uma indisponibilidade da região do Azure. Se tiver uma implementação de várias regiões, pode utilizar a funcionalidade de cache na cloud do FSLogix para ajudar a proteger os perfis de utilizador ao replicar entre regiões.
Recomendações
- Considere utilizar uma estratégia de recuperação sem perfil para minimizar a necessidade de proteger perfis.
- Utilize a Cópia de Segurança para criar cópias de segurança de perfis FSLogix que armazena no Ficheiros do Azure ou no Azure NetAppFiles.
- Utilize o armazenamento com redundância entre zonas para replicar dados de forma síncrona entre zonas de disponibilidade do Azure.
- Utilize a funcionalidade de cache na cloud do FSLogix para replicar perfis entre regiões.
Redes virtuais
Impacto: Fiabilidade, Otimização de Custos
As redes virtuais são serviços geridos que não são afetados por:
- Os danos locais de dados, metadados ou recursos.
- A falha de um único datacenter de uma zona de disponibilidade numa região do Azure.
O Azure Rede Virtual fornece um bloco de endereços IP privado que pode utilizar para implementar os seus recursos para conectividade privada. Em seguida, pode proteger esses recursos dentro de um limite. Como resultado, uma rede virtual não é inativa ou ocorre uma falha se ocorrer uma falha local de recursos num único datacenter.
Quando toda uma região do Azure sofrer uma falha, as redes virtuais são afetadas. As falhas regionais também afetam os serviços implementados nas redes virtuais. Para ajudar a proteger os seus recursos, tem de planear uma rede virtual na sua região secundária para permitir a replicação de VMs do conjunto de anfitriões pessoais ou espaço para a implementação de anfitriões de sessão. Também pode utilizar Site Recovery para configurar a rede virtual na região de ativação pós-falha e preservar as definições da rede primária. Num ambiente do Azure Virtual Desktop ligado à sua rede no local, deve configurar a rede virtual na região secundária com conectividade à rede no local.
Recomendações
- Configure uma rede virtual na sua região secundária para ativação pós-falha.
- Utilize Site Recovery para configurar uma rede virtual na região de ativação pós-falha.
Imagens douradas
Impacto: Fiabilidade, Otimização de Custos
Para imagens douradas, é melhor considerar três cenários:
- Os danos locais de dados, metadados ou recursos. Neste caso, pode utilizar a Galeria de Computação do Azure para armazenar e partilhar imagens que utiliza no Azure Virtual Desktop. Por predefinição, a Galeria de Computação utiliza o armazenamento localmente redundante.
- A falha de um único datacenter de uma zona de disponibilidade numa região do Azure. Neste cenário, pode utilizar o armazenamento com redundância entre zonas para distribuir cópias de imagens entre zonas de disponibilidade. Quando o armazenamento com redundância entre zonas estiver disponível, utilize-o para elevada disponibilidade.
- Uma indisponibilidade da região do Azure. A Galeria de Computação é um recurso regional. Para ajudar a proteger contra falhas regionais, tem de criar uma galeria de computação secundária numa região secundária. Também precisa de ter várias réplicas da mesma imagem na galeria de computação primária.
Recomendações
- Utilize a Galeria de Computação para armazenar imagens.
- Utilize o armazenamento com redundância entre zonas para distribuir cópias de imagens entre zonas de disponibilidade.
- Crie uma galeria de computação secundária numa região secundária.
Passos seguintes
Agora que examinou as considerações de continuidade do negócio, veja como otimizar considerações de desempenho e custos ao selecionar soluções de armazenamento para a sua carga de trabalho.
Utilize a ferramenta de avaliação para avaliar as suas escolhas de estrutura.