Vamos a hablar sobre las consideraciones que debemos de tener al diseñar un ambiente constituido por múltiples sitios para VMware Horizon View.
Comenzemos por entender la arquitectura de Pods y Bloques recomendada para VMware Horizon View debido a su modularidad y escalabilidad:
*El almacenamiento puede ser de cualquier vendor, 3par solo es por referencia
Un Pod esta constituido por N cantidad de bloques que satisfacen la capacidad de computo necesario para cumplir los SLAs definidos en nuestro ambiente y poder alojar a los usuarios proyectados. Todos los bloques que se requieran para poder dar servicio a la cantidad de usuarios necesarios van a estar compartiendo almacenamiento, podemos aislar los distintos bloques en distintos datastores pero por cuestiones de gestión es mejor que el mismo almacenamiento provea servicio para cada bloque que agreguemos. En cuestiones de red, estaremos utilizando vDS teniendo uno por bloque, recordemos que los vDS no se pueden expandir entre DCs virtuales o entre vCenter Servers.
Otro punto que pueden notar es el caso de las instancias de vCenter, vamos a necesitar una instancia por cada bloque, los ambientes de VMware Horizon View pueden llegar a ser bastante activos dependiendo de el diseño, ej. En el caso de requerir operaciones de refresh cada que los usuarios terminan su sesión, las VMs de vCenter estarán residiendo en el cluster de management para no consumir recursos dedicados a los escritorios. De igual manera tendremos al menos 2 View Connection Servers por bloque para poder cumplir con alta disponibilidad y poder balancear las sesiones entre ellos, aunque el máximo soportado de un connection server sea de 2000 sesiones con una configuración de 4 vCPUs y 10GB de RAM.
Por último tenemos el cluster de management donde se estarán ejecutando todas las VMs de servicio e infraestructura como vCenters de los bloques, View Connection Servers, View Transfer Servers, View Security Servers, vShield Manager (vCNS),etc.
Una vez entendidos los conceptos básicos de un diseño en “POD” debemos de conocer las limitantes que tenemos al diseñarlo:
- Los PODs no deben de estar expandidos geográficamente, esto es debido a que pueden llegar a presentarse problemas con la replicación de ADAM (a través de JMS) entre Connection Servers y sus replicas.
- Tenemos un máximo de 8 hosts por cluster en el caso de utilizar VMFS y 32 hosts en el caso de NFS.
- Es importante considerar en el caso de balanceo de cargas que DNS Round-Robin no debe de ser utilizado ya que no podriamos asegurar la persistencia de la sesión y esto podría resultar en la entrega de un nuevo escritorio por otro broker.
Puede llegarse a dar el caso que se tengan otras limitantes dependiendo del diseño en cuestión, pero estas son las principales que debemos de considerar para VMware Horizon View, ya que utilizamos vSphere las consideraciones y lineamientos de diseño de la misma aplican de igual manera a dicha capa.
Vamos a revisar algunos puntos en específico:
- Balanceo de cargas global entre sitios (Global Site Load Balancing, GSLB) – En este tipo de diseños que existen entre múltiples sitios debemos de contar con un mecanismo para balancear las cargas de las sesiones y que estas sean distribuidas geográficamente una vez que la sesión ha sido direccionada al DC en cuestión se contarán con balanceadores locales para distribuir las cargas entre View Connection Servers.
Todos los balanceadores que participan deben de asegurar la persitencia de sesión entre sitios y view connection servers, esto es de vital importancia para eventos de desconexión.Los escritorios persistentes no pueden ser utilizados en este tipo de configuración debido a que estos existirán en un solo datacenter.
|
Beneficios |
Contradicciones |
|
Una única URL para conectarse al ambiente de VMware Horizon View en el caso de escritorios no persistentes. |
Algunos fabricantes requieren que sus balanceadores sean autorizados (authoritative). |
|
Ofrece el mejor balanceo para escritorios no persistentes debido a su balanceo geográfico e interno. |
No esta pensado para escritorios persistentes |
|
A diferencia de Round-robin no direccionará sesiones de escritorios a sitios fuera de línea. |
Puede resultar algo compleja debido a el seguimiento entre sitios y sesiones. |
- Balanceo de cargas a nivel DC o sitio (Site Load Balancing) – En este caso al igual que en el balanceo global debemos de asegurarnos de la persistencia en cada una de las sesiones, en este caso si no estamos haciendo balanceo global el overhead de administración es mayor debido a que la distribución de sesiones entre sitios o DCs será manualmente asignando usuarios a cada URL (sitio/DC).
|
Beneficios |
Contradicciones |
| Ideal para ambientes donde tenemos escritorios persistentes, ya que los usuarios estan “casados” con un sitio. |
A menos que se utilice Roud-Robin DNS o reconfiguración a través de DHCP (se necesitaría tener un release de el lease) si atravesamos una falla de el DC/sitio los clientes deberán ser configurados manualmente. |
|
Existen Zero-clients que soportan la reconfiguración de el mismo a través de opciones en el scope de DHCP, permitiendo redireccionarlas a un sitio alterno. |
Una distribución equitativa de sesiones activas puede no balancearse de manera efectiva. |
Escrito por Agustín Malanco, vExpert y Channel Systems Engineer en VMware México. Agustín es VCP 3/4/5, VCI, VCAP4-DCA/DCD, VCP4/5-DT, MCP y en realidad un apasionado con todo lo que tenga que ver con virtualización.
