Vamos falar sobre os pontos que devemos levar em conta ao projetar um ambiente constituído por vários sites no VMware Horizon View.
Primeiro, é preciso entender a arquitetura de blocos e pools de desktops (Pods, desktop pools) recomendada para o VMware Horizon View, devido à sua modularidade e escalabilidade:
*O armazenamento pode ser de qualquer fornecedor (o 3par é somente para referência)
Um Pod é constituído por N quantidade de blocos que atendem à capacidade de computação necessária para cumprir os contratos de nível de serviço (SLAs, service level agreements) definidos em nosso ambiente e hospedar os usuários projetados. Todos os blocos necessários para atender à determinada quantidade de usuários compartilharão o armazenamento. Podemos isolar os diferentes blocos em diferentes repositórios de dados. Entretanto, por questões de gerenciamento, convém que o mesmo armazenamento sirva a cada bloco agregado. Em termos de rede, utilizaremos o switch virtual distribuído (vDS, Virtual Distributed Switch), um por bloco. Convém lembrar que esse tipo de switch não pode ser expandido entre data centers virtuais, nem entre vCenter Servers.
Outro ponto a ser observado é o caso das instâncias do vCenter. Será necessária uma instância por bloco. Os ambientes do VMware Horizon View podem tornar-se bastante ativos conforme o projeto. Por exemplo, caso precisem ser atualizadas toda vez que os usuários terminarem suas sessões, as VMs do VCenter estarão armazenadas no cluster de gerenciamento para não consumirem recursos dedicados aos desktops. Da mesma forma, teremos, pelo menos, dois View Connection Servers por bloco para poder atender à alta disponibilidade e balancear as sessões entre os servidores, mesmo que o máximo permitido por Connection Server seja de 2.000 sessões, com uma configuração de quatro CPUs virtuais (vCPUs, virtual CPUs) e 10 GB de RAM.
Por último, temos o cluster de gerenciamento, onde serão executadas todas as VMs de serviço e de infraestrutura, como vCenters dos blocos, View Connection Servers, View Transfer Servers, View Security Servers, vShield Manager (vCNS), etc.
Uma vez entendidos os conceitos básicos de um projeto em “POD”, devemos conhecer as respectivas limitações:
- Os PODs não devem ser expandidos geograficamente porque podem apresentar problemas com a replicação do modo de aplicativo do Active Directory (ADAM, Active Directory Application Mode), via serviço de mensagens Java (JMS, Java Messaging Service), entre servidores de conexão e suas réplicas.
- Se usarmos o sistema de arquivos de máquina virtual (VMFS, Virtual Machine File System), teremos, no máximo, oito hosts. No caso do sistema de arquivos de rede (NFS, Network File System), o limite será de 32 hosts.
- Devemos levar em conta que, no caso de balanceamento de carga, a técnica de Round Robin DNS (RRDNS) não deve ser utilizada, pois não seria possível assegurar a persistência da sessão. O resultado poderia ser a entrega de um novo desktop por outro agente.
Dependendo do projeto, é possível que existam ainda outras limitações, mas vimos aquelas que são mais importantes para o VMware Horizon View. Já que usamos o vSphere, as considerações e linhas gerais de projeto dessa plataforma de virtualização se aplicam igualmente à camada referida.
Vamos revisar alguns pontos específicos:
- Balanceamento global de carga entre sites (GSLB, Global Site Load Balancing) – Como existem vários sites envolvidos neste tipo de projeto, devemos contar com um mecanismo para balancear a carga das sessões para que ela seja distribuída geograficamente. Uma vez direcionada a sessão ao data center em questão, os balanceadores locais serão usados para distribuir a carga entre View Connection Servers. Todos os balanceadores que participam devem assegurar a persistência da sessão entre sites e View Connection Servers. Isso é vital para eventos de desconexão. Esse tipo de configuração não pode ser usado para desktops persistentes porque eles estão localizados somente em um único data center.
|
Benefícios |
Contradições |
|
Um único URL para conectar-se ao ambiente do VMware Horizon View no caso de desktops persistentes. |
Alguns fabricantes exigem que seus balanceadores sejam autorizados (authoritative). |
|
Oferece melhor balanceamento para desktops não persistentes devido ao seu balanceamento geográfico e interno. |
Não tem como foco desktops persistentes |
|
Ao contrário de Round Robin, o GLSB não direciona sessões de desktops a sites offline. |
Pode resultar em algo complexo devido à sequência entre sites e sessões. |
- Balanceamento de carga em nível de data center ou site (Site Load Balancing) – Neste caso, tal qual no balanceamento global, devemos garantir a persistência em cada uma das sessões. Além disso, se não fizermos o balanceamento global, a sobrecarga administrativa será maior porque a distribuição de sessões entre sites ou data centers será feita manualmente, atribuindo usuários a cada URL (site/data center).
|
Benefícios |
Contradições |
|
Ideal para ambientes onde temos desktops persistentes, já que os usuários estão “casados” com um site. |
A menos que se use RRDNS ou reconfiguração via protocolo DHCP (seria necessário ter uma versão da concessão de DHCP), se ocorrer uma falha no data center ou no site, os clientes deverão ser configurados manualmente. |
|
Existem zero clients (clientes zero) que suportam sua própria reconfiguração com opções no nível de DHCP, permitindo redirecioná-la a outro site. |
Uma distribuição equitativa de sessões ativas pode não ser devidamente balanceada. |
Escrito por Agustín Malanco, vExpert e Channel Systems Engineer na VMware México. Agustín possui as certificações VCP 3/4/5, VCI, VCAP4-DCA/DCD, VCP4/5-DT e MCP. Na realidade, ele é apaixonado por tudo o que se refere à virtualização.
