Zonas

Las implementaciones que incluyen ubicaciones muy alejadas, conectadas mediante una red WAN, pueden presentar problemas debido a la latencia de la red y la confiabilidad. Existen dos opciones para mitigar esos problemas:

  • Implementar varios sitios, cada uno con su propia base de datos SQL Server del sitio.

Se recomienda esta opción para implementaciones de empresa de gran tamaño. Se trata de varios sitios que se administran por separado, y cada uno necesita su propia base de datos SQL Server del sitio. Cada sitio es una implementación independiente de XenApp.

  • Configurar varias zonas en un único sitio.

Configurar zonas puede ayudar a los usuarios de regiones remotas a conectarse a recursos sin que las conexiones recorran necesariamente grandes segmentos de red WAN. Utilizar zonas permite una administración efectiva de sitios desde una única consola de Citrix Studio, Citrix Director y la base de datos del sitio. Esto disminuye los costes de implementación, personal, licencias y operación de otros sitios que contienen bases de datos separadas en ubicaciones remotas.

Las zonas pueden resultar útiles en implementaciones de todos los tamaños. Puede usar zonas para mantener las aplicaciones y los escritorios más cerca de los usuarios finales, lo que mejora el rendimiento. Una zona puede tener uno o varios Controllers instalados localmente por redundancia y resistencia, pero no es necesario.

La cantidad de Controllers configurados en el sitio puede afectar al rendimiento de algunas operaciones, como agregar nuevos Controllers al sitio mismo. Para evitar este problema, se recomienda limitar la cantidad de zonas en su sitio de XenDesktop o XenApp a no más de 50 zonas.

Nota:

Si la latencia de red de las zonas es superior a 250 milisegundos RTT, se recomienda implementar varios sitios en lugar de varias zonas.

En este artículo, el término “local” se refiere a la zona que se analiza. Por ejemplo, “un VDA se registra en el Controller local” significa que el VDA se registra en un Controller de la zona donde está situado el VDA.

Las zonas de esta versión son similares (pero no idénticas) a las zonas de XenApp 6.5 o versiones anteriores. Por ejemplo, en esta implementación de zonas, no hay recopiladores de datos. Todos los Controllers de un sitio se comunican con una base de datos del sitio situada en la zona principal. Además, la conmutación por error y las zonas favoritas funcionan de otra forma en esta versión.

Tipos de zona

Un sitio siempre tiene una zona principal. También puede tener una o varias zonas satélite. Las zonas satélite se pueden usar para: recuperación ante desastres, centros de datos geográficamente alejados, sucursales, una nube o la zona de disponibilidad de una nube.

Zona principal

La zona principal tiene el nombre predeterminado “Principal” y contiene la base de datos SQL Server del sitio (y servidores SQL de alta disponibilidad, si los hay), Studio, Director, Citrix StoreFront, el servidor de licencias Citrix y NetScaler Gateway. La base de datos del sitio debe estar siempre en la zona principal.

La zona principal también debe tener al menos dos Controllers para la redundancia. Asimismo, puede tener uno o varios VDA con aplicaciones estrechamente ligadas a la base de datos y la infraestructura.

Zona satélite

Una zona satélite contiene uno o varios VDA, Controllers, servidores StoreFront y servidores NetScaler Gateway. En condiciones normales, los Controllers de una zona satélite se comunican directamente con la base de datos situada en la zona principal.

Una zona satélite, especialmente una grande, también puede contener un hipervisor que se usa para aprovisionar y/o almacenar máquinas de esa zona. Al configurar una zona satélite, puede asociarle una conexión de hipervisor o servicio de nube. (Compruebe que los catálogos de máquinas que utilizan esa conexión están en la misma zona.)

Un sitio puede tener zonas satélite con distintas configuraciones, en función de sus necesidades concretas y su entorno. En la siguiente imagen, se representa una zona principal y ejemplos de zonas satélite.

Zonas

  • La zona principal contiene dos Controllers, Studio, Director, StoreFront, el servidor de licencias y la base de datos del sitio (además de implementaciones de alta disponibilidad de SQL Server). La zona principal también contiene varios VDA y un NetScaler Gateway.

  • Zona satélite 1. Agentes VDA con Controller

La zona satélite 1 contiene un Controller, agentes VDA y un servidor StoreFront. Los VDA de esta zona satélite se registran en el Controller local. El Controller local se comunica con la base de datos del sitio y el servidor de licencias situados en la zona principal.

Si se produce un error en la red WAN, la función de concesión de conexiones permite que el Controller de la zona satélite siga actuando como broker en conexiones a los VDA de esa zona. Una implementación así puede ser adecuada en una oficina donde los trabajadores utilicen un sitio local de StoreFront y el Controller local para acceder a sus recursos locales incluso aunque falle el vínculo WAN que conecta su oficina a la red de la empresa.

  • Zona satélite 2. Agentes VDA con Controllers redundantes

La zona satélite 2 contiene dos Controllers, agentes VDA y un servidor StoreFront. Este es el tipo de zona más resistente. Ofrece protección contra errores simultáneos de red WAN y uno de los Controllers locales.

Dónde se registran los VDA y dónde conmutan por error los Controllers

En un sitio que contiene zonas principal y satélite, con agentes VDA como mínimo de la versión 7.7:

  • Un VDA de la zona principal se registra en un Controller de la zona principal. Un VDA de la zona principal no intentará nunca registrarse en un Controller de una zona satélite.
  • Un VDA de una zona satélite se registra en el Controller local, si es posible. (Este se considera el Controller favorito.) Si no hay Controllers locales disponibles (por ejemplo, debido a que no pueden aceptar más registros de VDA o porque se ha producido un error en ellos), el VDA intentará registrarse en un Controller de la zona principal. En este caso, el VDA permanecerá registrado en la zona principal incluso aunque un Controller de la zona satélite vuelva a estar disponible. Un VDA de una zona satélite no intentará nunca registrarse en un Controller de otra zona satélite.
  • Cuando está habilitada la actualización automática para la detección de Controllers por parte de los VDA y se especifica una lista de direcciones de Controller durante la instalación de VDA, se selecciona aleatoriamente un Controller de esa lista para el registro inicial (independientemente de la zona en que resida ese Controller). Una vez se reinicie la máquina que contiene el VDA, ese VDA empezará el registro en un Controller de su zona local.
  • Si falla un Controller de una zona satélite, si puede, conmutará por error a otro Controller local. Si no hay Controllers locales disponibles, se producirá una conmutación por error a un Controller de la zona principal.
  • Si se mueve un Controller dentro o fuera de una zona y su actualización automática está habilitada, los VDA de ambas zonas recibirán listas actualizadas que indicarán qué Controllers son locales y cuáles están en la zona principal, para que los VDA sepan en cuál se pueden registrar y de cuál pueden aceptar conexiones.
  • Si se mueve un catálogo de máquinas a otra zona, los VDA de ese catálogo volverán a registrarse en los Controllers de la zona a la que se haya movido el catálogo. (Si se mueve un catálogo a una zona mal conectada a la zona actual (por ejemplo, a través de una red de alta latencia o poco ancho de banda), también debe mover cualquier conexión de host asociada a la misma zona.)
  • Los Controllers de la zona principal conservan datos de concesión de conexiones para todas las zonas. Los Controllers de las zonas satélite conservan datos de concesión de conexiones de su propia zona y la zona principal, pero no disponen de datos para las demás zonas satélite.

Si fallan todos los Controllers de la zona principal:

  • Studio no puede conectarse al sitio.
  • No se puede establecer conexiones con los VDA de la zona principal.
  • El rendimiento del sitio se degradará cada vez más hasta que los Controllers de la zona principal vuelvan a estar disponibles.

En caso de sitios que contienen versiones de VDA anteriores a 7.7:

  • Un VDA en una zona satélite aceptará solicitudes de Controllers de su zona local y la zona principal. (A partir de la versión 7.7, los agentes VDA pueden aceptar solicitudes de Controller de otras zonas satélite.)
  • Un VDA de una zona satélite se registrará en un Controller de la zona principal o de la zona local de forma aleatoria. (A partir de la versión 7.7, los agentes VDA prefieren la zona local.)

Preferencia de zonas

Importante:

Para usar la funcionalidad Preferencia de zonas, debe utilizar como mínimo StoreFront 3.7 y NetScaler Gateway 11.0-65.x.

En un sitio de varias zonas, la funcionalidad Preferencia de zonas ofrece más flexibilidad al administrador para controlar qué VDA se utiliza para iniciar una aplicación o un escritorio.

Cómo funciona la preferencia de zonas

Existen tres preferencias distintas de zonas. Es posible que prefiera utilizar un VDA en una zona particular, en función de:

  • Dónde se almacenan los datos de la aplicación. Esto se conoce como zona particular de la aplicación.
  • La ubicación de los datos principales del usuario (por ejemplo, un perfil o un directorio particular en un recurso compartido de red). Esto se conoce como zona particular del usuario.
  • La ubicación actual del usuario (dónde se está ejecutando Citrix Receiver). Esto se conoce como ubicación del usuario.

En el gráfico siguiente, se muestra un ejemplo de configuración de varias zonas.

Preferencias de zonas

En este ejemplo, los VDA están distribuidos en tres zonas satélite, pero pertenecen todos al mismo grupo de entrega. Por lo tanto, el intermediario (broker) puede elegir qué VDA usar cuando un usuario lanza una solicitud de inicio. En este ejemplo, se indican varios lugares donde los usuarios pueden ejecutar sus puntos finales de Citrix Receiver: el usuario A usa un dispositivo con Citrix Receiver en la zona satélite 1; el usuario B usa un dispositivo en la zona satélite 2. Los documentos de los usuarios pueden almacenarse en una serie de ubicaciones; por ejemplo: ambos usuarios, A y B, utilizan un recurso compartido en la zona satélite 1, mientras que el usuario C usa un recurso de la zona satélite C. Además, una de las aplicaciones publicadas utiliza una base de datos que se encuentra en la zona satélite 1.

Para asociar un usuario o una aplicación a una zona, configure una zona particular específica para ese usuario o esa aplicación. A partir de ahí, el broker que se encuentra en el Delivery Controller usa esas asociaciones para seleccionar la zona donde se iniciará una sesión, si los recursos están disponibles. A usted le corresponde:

  • Configurar la zona particular de un usuario agregándolo a una zona.
  • Configurar la zona particular de una aplicación modificando las propiedades de esta.

Un usuario o una aplicación pueden tener solo una zona particular en un momento dado. (Puede darse una excepción para los usuarios cuando hay varias pertenencias a zonas porque esos usuarios forman parte de grupos de usuarios; consulte la sección “Otras consideraciones” para resolverla. Sin embargo, incluso en este caso, el broker utiliza una sola zona particular.)

Aunque se puedan configurar las preferencias de zonas para usuarios y aplicaciones, el broker selecciona una sola zona preferida para el inicio. El orden predeterminado de prioridad para seleccionar la zona preferida es: zona particular de la aplicación > zona particular del usuario > ubicación del usuario. (Puede restringir la secuencia siguiendo las indicaciones de la sección siguiente.) Cuando un usuario inicia una aplicación:

  • Si la aplicación tiene configurada una asociación de zona (es decir, una zona particular de la aplicación), entonces la zona preferida es la zona particular de esa aplicación.
  • En cambio, si la aplicación no tiene configurada una asociación de zona pero el usuario sí la tiene (una zona particular de usuario), entonces la zona preferida es la zona particular del usuario.
  • Si ni la aplicación ni el usuario tienen configurada una asociación de zona, entonces la zona preferida es la zona donde el usuario ejecuta la instancia de Citrix Receiver (la ubicación del usuario). Si esa zona no está definida, se seleccionan un VDA y una zona aleatorios. El equilibrio de carga se aplica a todos los VDA de la zona preferida. Si no hay ninguna zona preferida, el equilibrio de carga se aplica a todos los VDA del grupo de entrega.

Adaptar la preferencia de zonas

Al configurar (o quitar) la zona particular de un usuario o una aplicación, puede limitar más cómo se utilizará (o no) la preferencia de zonas.

  • Uso obligatorio de la zona particular del usuario. En un grupo de entrega, puede especificar que una sesión deba iniciarse en la zona particular del usuario (si la tiene), sin conmutación por error a otra zona si los recursos no estuvieran disponibles en esa zona particular. Esta restricción es útil para evitar el riesgo de copia de perfiles o archivos de datos grandes entre las zonas. En otras palabras, cuando se prefiere negar el inicio de una sesión a iniciarla en otra zona.
  • Uso obligatorio de la zona particular de la aplicación. Del mismo modo, cuando configure la zona particular de una aplicación, puede indicar que la aplicación deba iniciarse solo en esa zona, sin conmutación por error a otra zona aunque los recursos no estuvieran disponibles en la zona particular de la aplicación.
  • Sin zona particular de aplicación, e ignorar la zona particular configurada del usuario. Si no especifica ninguna zona particular para una aplicación, también puede indicar que no se tenga en cuenta ninguna zona de usuario configurada para iniciar esa aplicación. Por ejemplo, si prefiere que los usuarios ejecuten una aplicación concreta en un VDA cercano a la máquina que están usando (donde Citrix Receiver se está ejecutando), puede indicarlo mediante la preferencia de zona “ubicación del usuario” aunque algunos usuarios tengan otra zona particular.

Cómo afecta la preferencia de zonas al uso de sesiones

Cuando un usuario inicia una aplicación o un escritorio, el broker prefiere usar la zona preferida en lugar de usar una sesión existente.

Si el usuario que inicia la aplicación o escritorio ya tiene una sesión apropiada para el recurso que se va a iniciar (por ejemplo, una que puede usar la función de compartir sesiones para una aplicación, o bien una sesión que ya ejecuta el recurso que se va a iniciar), pero esa sesión se está ejecutando en un VDA que se encuentra en otra zona, no la preferida de la aplicación o el usuario, el sistema puede crear una nueva sesión. Con lo que el inicio se produce en la zona correcta (si tiene capacidad disponible), en vez de reconectarse a una sesión en una zona menos ventajosa para los requisitos de sesión del usuario.

Para que no exista una sesión “huérfana” con la que ya no se pueda establecer conexión, se permite volverse a conectar a las sesiones desconectadas incluso aunque estén en una zona no preferida.

El orden de preferencia para elegir una sesión para el inicio es:

  1. Reconectarse a una sesión existente en la zona preferida.
  2. Reconectarse a una sesión desconectada existente en una zona que no sea la preferida.
  3. Iniciar una sesión nueva en la zona preferida.
  4. Reconectarse una sesión conectada existente en una zona que no sea la preferida.
  5. Iniciar una sesión nueva en una zona que no sea la preferida.

Otras consideraciones de preferencia de zonas

  • Si configura la zona particular de un grupo de usuarios (por ejemplo, un grupo de seguridad), los usuarios de ese grupo (por pertenencia directa o indirecta) se asocian a la zona especificada. No obstante, un usuario puede pertenecer a varios grupos de seguridad y, por lo tanto, puede tener otras zonas particulares configuradas por pertenecer a otros grupos. En tales casos, la determinación de la zona particular de ese usuario puede ser ambigua.

Si un usuario tiene configurada una zona particular que no adquirió por pertenecer a grupos, esa es la zona que se usa para la preferencia de zonas. Se ignoran las asociaciones de zona que se adquieran por pertenecer a grupos.

Si el usuario tiene varias asociaciones de zonas que adquirió únicamente por pertenecer a grupos, el broker escoge una zona aleatoria de entre ellas. Tras la elección del broker, se utiliza la misma zona para los inicios subsiguientes de sesión hasta que cambie la pertenencia del usuario a los grupos.

  • La preferencia de zona “ubicación del usuario” requiere que el Citrix NetScaler Gateway a través del que el dispositivo de punto final se conecta detecte Citrix Receiver en ese dispositivo de punto final. El dispositivo NetScaler debe estar configurado para asociar rangos de direcciones IP a zonas concretas, y la identidad de la zona detectada debe transferirse a través de StoreFront al Controller.

Para obtener más información acerca de la preferencia de zonas, consulte Zone Preference Internals.

Requisitos, consejos y consideraciones

  • Puede colocar los siguientes elementos en una zona: Controllers, catálogos de máquinas, conexiones de host, usuarios y aplicaciones. Si un catálogo de máquinas usa una conexión de host, el catálogo y la conexión deben estar en la misma zona a fin de que la conexión entre ambos tenga una latencia baja y alto ancho de banda.
  • Colocar elementos en una zona satélite afecta al modo en que el sitio interactúa con ellos y con otros objetos relacionados con esos elementos.
    • Cuando se colocan máquinas de Controller en una zona satélite, se presupone que esas máquinas tienen una buena conexión (local) con hipervisores y máquinas VDA en la misma zona satélite. Por tanto, se utilizan preferentemente los Controllers de esa zona satélite en lugar de Controllers de la zona principal para la gestión de esos hipervisores y esas máquinas VDA.
    • Cuando se coloca una conexión de hipervisor en una zona satélite, se presupone que todos los hipervisores administrados a través de esa conexión de hipervisor también residen en esa zona satélite. Por tanto, se utilizan preferentemente los Controllers de esa zona satélite en lugar de Controllers de la zona principal para la comunicación por esa conexión de hipervisor.
    • Cuando se coloca un catálogo de máquinas en una zona satélite, se presupone que todas las máquinas VDA de ese catálogo están en la zona satélite. Se utilizan preferentemente Controllers locales (en lugar de Controllers de la zona principal) cuando los VDA intentan registrarse en el sitio, después de que se haya activado el mecanismo de actualización automática de los Controllers tras el primer registro de cada VDA.
    • También se puede asociar instancias de NetScaler Gateway con zonas. A diferencia de los demás elementos que se describen aquí, esto se realiza como parte de la configuración del enrutamiento óptimo de HDX de StoreFront, en lugar de hacerlo como parte de la configuración del sitio de XenApp o XenDesktop. Cuando se asocia un NetScaler Gateway a una zona, se utiliza preferentemente ese NetScaler Gateway cuando se utilizan las conexiones HDX a las máquinas VDA de esa zona.
  • Cuando se crea un sitio de producción y, luego, se crean el primer catálogo de máquinas y el primer grupo de entrega, todos esos elementos se encuentran en la zona principal: no se pueden crear zonas satélite hasta después de completar la configuración inicial. (Si crea un sitio vacío, la zona principal contendrá inicialmente solo un Controller, por lo que puede crear zonas satélite antes o después de crear un catálogo de máquinas y un grupo de entrega.)
  • Cuando crea la primera zona satélite con uno o varios elementos, todos los demás elementos de su sitio siguen estando en la zona principal.
  • La zona principal se denomina “Principal” de forma predeterminada, y usted puede cambiar ese nombre. Aunque la pantalla de Studio indica cuál es la zona principal, se recomienda usar un nombre de fácil identificación para la zona principal. Puede reasignar la zona principal (es decir, puede convertir otra zona en la zona principal), pero esta debe contener siempre la base de datos del sitio y los servidores de alta disponibilidad.
  • La base de datos del sitio debe estar siempre en la zona principal.
  • Después de crear una zona, puede mover elementos de una zona a otra. Tenga en cuenta que esta flexibilidad permite llegar a separar elementos que funcionan mejor en cercanía; por ejemplo, mover un catálogo de máquinas a otra zona que la conexión (host) que crea las máquinas del catálogo podría afectar al rendimiento. Por lo tanto, tenga en mente los posibles efectos imprevistos antes de mover elementos entre zonas. Mantenga el catálogo y la conexión de host que éste usa en la misma zona o en zonas bien conectadas (por ejemplo, conectadas a través de una red de baja latencia y alto ancho de banda).
  • Para obtener un rendimiento óptimo, instale Studio y Director solo en la zona principal. Si quiere otra instancia de Studio en una zona satélite (por ejemplo, si una zona satélite que contiene Controllers se usa para la conmutación por error en caso de que la zona principal deje de ser accesible), ejecute Studio como una aplicación publicada localmente. Asimismo, puede acceder a Director desde una zona satélite porque se trata de una aplicación Web.
  • Preferiblemente, NetScaler Gateway de una zona satélite debe usarse para conexiones de usuario provenientes de otras zonas o ubicaciones externas, aunque puede usarse para conexiones desde dentro de la zona.
  • Recuerde: Para usar la función Preferencia de zonas, debe utilizar como mínimo StoreFront 3.7 y NetScaler Gateway 11.0-65.x.
  • Para obtener información más técnica y consideraciones de rendimiento, consulte Zones Deep Dive.

Límites a la calidad de conexión

Los Controllers de la zona satélite llevan a cabo interacciones SQL directamente con la base de datos del sitio. Eso impone algunos límites en la calidad del enlace entre la zona satélite y la zona principal que contiene la base de datos del sitio. Los límites concretos dependen de la cantidad de agentes VDA y sesiones de usuario en esos VDA que se implementan en la zona satélite. Por lo tanto, zonas satélite con pocos VDA y pocas sesiones pueden funcionar con una conexión de peor calidad a la base de datos que las zonas satélite que tengan grandes cantidades de agentes VDA y muchas sesiones.

Para obtener más información, consulte Latency and SQL Blocking Query Improvements.

Impacto de latencia en la intermediación de rendimiento

Aunque las zonas permiten a los usuarios estar en los enlaces de mayor latencia, siempre que haya un broker local, la latencia adicional influye inevitablemente en la experiencia del usuario final. Para la mayor parte de las tareas, los usuarios experimentan lentitud provocada por viajes de ida y vuelta entre los Controllers de la zona satélite y la base de datos del sitio.

En el inicio de aplicaciones, se producen demoras extras mientras el proceso de intermediación de sesiones identifica al VDA adecuado al que enviar las solicitudes de inicio de sesión.

Crear y administrar zonas

Un administrador total puede realizar todas las tareas de creación y administración de zonas. Sin embargo, también se puede crear un rol personalizado que permita crear, modificar o eliminar una zona. Mover elementos entre zonas no requiere permisos de zonas (excepto el permiso de lectura de zonas). Sin embargo, debe tener permiso para modificar los elementos que esté moviendo. Por ejemplo, para mover un catálogo de máquinas de una zona a otra, debe tener el permiso de modificar ese catálogo de máquinas. Para obtener más información, consulte el artículo Administración delegada.

Si utiliza Provisioning Services. La consola Provisioning Services Console que se incluye en esta versión no reconoce zonas, por lo que Citrix recomienda usar Studio para crear catálogos de máquinas que quiera colocar en zonas satélite. Use el asistente de Studio para crear el catálogo y especificar la zona satélite correspondiente. A continuación, utilice la consola de Provisioning Services para aprovisionar las máquinas de ese catálogo. (Si crea el catálogo mediante el asistente de Provisioning Services, este se colocará en la zona principal y deberá usar Studio para moverlo posteriormente a la zona satélite.)

Crear una zona

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio.
  2. Seleccione Crear zona en el panel Acciones.
  3. Escriba un nombre para la zona y una descripción (opcional). El nombre debe ser único dentro del sitio.
  4. Seleccione los elementos que se van a colocar en la nueva zona. Puede filtrar o buscar la lista de elementos de la que seleccionarlos. También puede crear una zona vacía. Para ello, simplemente no seleccione ningún elemento.
  5. Haga clic en Guardar.

Como alternativa a este método, puede seleccionar uno o varios elementos en Studio y, a continuación, seleccionar Crear zona en el panel Acciones.

Cambiar el nombre o la descripción de una zona

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio.
  2. Seleccione una zona en el panel central y, a continuación, seleccione Modificar zona en el panel Acciones.
  3. Cambie el nombre y/o la descripción de la zona. Si cambia el nombre de la zona principal, tenga en cuenta que la zona debe ser fácilmente identificable como zona principal.
  4. Haga clic en Aceptar o en Aplicar.

Mover elementos de una zona a otra

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio.
  2. Seleccione una zona en el panel central y, a continuación, seleccione uno o varios elementos.
  3. Arrastre los elementos a la zona de destino o seleccione Mover elementos en el panel Acciones y, a continuación, especifique la zona a la que moverlos.

Aparecerá un mensaje de confirmación con una lista de los elementos seleccionados y preguntará si quiere moverlos a todos.

Recuerde: Si un catálogo de máquinas usa una conexión de host a un hipervisor o un servicio de nube, ambos (el catálogo y la conexión) deben estar en la misma zona. De lo contrario, el rendimiento puede verse afectado. Si mueve un elemento, mueva el otro.

Eliminar una zona

Una zona debe estar vacía antes de que se pueda eliminar. No se puede eliminar la zona principal.

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio.
  2. Seleccione una zona en el panel central.
  3. Seleccione Eliminar zona en el panel Acciones. Si la zona no está vacía (contiene elementos), se le pedirá que seleccione la zona a la que se moverán los elementos.
  4. Confirme la eliminación.

Agregar una zona particular a un usuario

Configurar la zona particular de un usuario también se conoce como agregar un usuario a una zona.

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio y, a continuación, seleccione una zona en el panel central.
  2. Seleccione Agregar usuarios a la zona en el panel Acciones.
  3. En el cuadro de diálogo Agregar usuarios a la zona, haga clic en Agregar y, a continuación, seleccione los usuarios y los grupos de usuarios que quiera agregar a la zona. Si especifica usuarios que ya tienen su zona particular, aparecerá un mensaje con dos opciones: , que equivale a agregar solo a los usuarios especificados que no tengan ninguna zona particular; No, que equivale a volver al diálogo de selección de usuarios.
  4. Haga clic en Aceptar.

Para los usuarios que tengan una zona particular configurada, puede definir que las sesiones se inicien solo desde su zona particular correspondiente:

  1. Cree o edite un grupo de entrega.
  2. En la página Usuarios, marque la casilla Las sesiones deben iniciarse en la zona particular del usuario, si está configurada.

Todas las sesiones que inicie un usuario de ese grupo de entrega deberán iniciarse desde las máquinas que se encuentren en la zona particular de ese usuario. Si un usuario del grupo de entrega no tiene configurada una zona particular, este parámetro no tiene ningún efecto.

Eliminar la zona particular de un usuario

Este procedimiento también se conoce como quitar un usuario de una zona.

  1. Seleccione Configuración > Zonas en el panel de navegación de Studio y, a continuación, seleccione una zona en el panel central.
  2. Seleccione Quitar usuarios de la zona en el panel Acciones.
  3. En el cuadro de diálogo Agregar usuarios a la zona, haga clic en Quitar y, a continuación, seleccione los usuarios y los grupos que quiera quitar de la zona. Tenga en cuenta que esta acción solo quita a los usuarios de la zona; esos usuarios siguen formando parte de los grupos de entrega y los grupos de aplicaciones.
  4. Confirme la eliminación cuando se le solicite.

Administrar zonas particulares de aplicaciones

Configurar la zona particular de una aplicación también se conoce como agregar una aplicación a una zona. De forma predeterminada, en un entorno de varias zonas, una aplicación no tiene ninguna zona particular.

La zona particular de una aplicación se especifica en las propiedades de la aplicación. Puede configurar las propiedades de una aplicación cuando la agregue a un grupo o más adelante. Para ello, deberá seleccionar la aplicación en Studio y modificar sus propiedades.

En la página Zonas de las propiedades o ajustes de la aplicación:

  • Si quiere que la aplicación tenga una zona particular:
    • Marque el botón de opción Usar la zona seleccionada para determinar donde se inicia esta aplicación y, a continuación, seleccione la zona de la lista desplegable.
    • Si quiere que la aplicación solo se inicie desde la zona seleccionada (ninguna otra), marque la casilla situada debajo de la selección de zonas.
  • Si no quiere que la aplicación tenga una zona particular:
    • Seleccione la opción No configurar una zona particular para esta aplicación.
    • Si no quiere que el broker tenga en cuenta ninguna de las zonas de usuario configuradas cuando se inicie esta aplicación, marque la casilla situada bajo el botón de opción. En ese caso, no se utilizará ninguna zona particular de aplicación o usuario para determinar dónde iniciar esta aplicación.

Otras acciones que implican especificar zonas

Cuando se agrega una conexión de host o se crea un catálogo de máquinas (aparte del momento en que se crea un sitio), se puede especificar una zona a la que se asignará el objeto, si ya se ha creado al menos una zona satélite.

En la mayoría de los casos, la zona principal es la opción predeterminada. Si utiliza Machine Creation Services para crear un catálogo de máquinas, se selecciona automáticamente la zona que esté configurada para la conexión de host.

Si el sitio no contiene zonas satélite, se presupone la selección de la zona principal y el cuadro de selección de zonas no aparece.