Zonas
Nota:
Você pode gerenciar sua implantação do Citrix Virtual Apps and Desktops™ usando dois consoles de gerenciamento: Web Studio (baseado na web) e Citrix Studio (baseado em Windows). Este artigo aborda apenas o Web Studio. Para obter informações sobre o Citrix Studio, consulte o artigo equivalente no Citrix Virtual Apps and Desktops 7 2212 ou anterior.
Implantações que abrangem locais amplamente dispersos conectados por uma WAN podem enfrentar desafios devido à latência e confiabilidade da rede. Existem duas opções que mitigam esses desafios:
-
Implante vários sites, cada um com seu próprio banco de dados de site do SQL Server.
Esta opção é recomendada para grandes implantações corporativas. Vários sites são gerenciados separadamente, e cada um requer seu próprio banco de dados de site do SQL Server. Cada site é uma implantação separada do Citrix Virtual Apps™.
-
Configure várias zonas dentro de um único site.
A configuração de zonas pode ajudar usuários em regiões remotas a se conectar a recursos sem necessariamente forçar suas conexões a atravessar grandes segmentos da WAN. O uso de zonas permite o gerenciamento eficaz do site a partir de um único console do Web Studio, Citrix Director e do banco de dados do site. Isso economiza os custos de implantação, pessoal, licenciamento e operação de mais sites contendo bancos de dados separados em locais remotos.
As zonas podem ser úteis em implantações de todos os tamanhos. Você pode usar zonas para manter aplicativos e desktops mais próximos dos usuários finais, o que melhora o desempenho. Uma zona pode ter um ou mais Controllers instalados localmente para redundância e resiliência, mas isso não é obrigatório.
O número de Controllers configurados no site pode afetar o desempenho de algumas operações, como adicionar novos Controllers ao próprio site. Para evitar isso, recomendamos que você limite o número de zonas em seu site Citrix Virtual Apps ou Citrix Virtual Desktops™ a no máximo 50.
Quando a latência da rede de suas zonas for superior a 250 ms RTT, recomendamos que você implante vários sites em vez de zonas.
Ao longo deste artigo, o termo local se refere à zona em discussão. Por exemplo, “Um VDA se registra em um Controller local” significa que um VDA se registra em um Controller na zona onde o VDA está localizado.
As zonas nesta versão são semelhantes, mas não idênticas às zonas no XenApp versão 6.5 e anteriores. Por exemplo, nesta implementação de zonas, não há coletores de dados. Todos os Controllers no site se comunicam com um banco de dados do site na zona primária. Além disso, o failover e as zonas preferenciais funcionam de forma diferente nesta versão.
Tipos de zona
Um site sempre tem uma zona primária. Ele também pode, opcionalmente, ter uma ou mais zonas satélite. As zonas satélite podem ser usadas para recuperação de desastres, data centers geograficamente distantes, filiais, uma nuvem ou uma zona de disponibilidade em uma nuvem.
Zona primária:
A zona primária tem o nome padrão “Primary”. Esta zona contém o banco de dados do site do SQL Server (e servidores SQL de alta disponibilidade, se usados), Web Studio, Director, Citrix StoreFront™, Citrix License Server e Citrix Gateway. Mantenha sempre o banco de dados do site na zona primária.
A zona primária deve ter pelo menos dois Controllers para redundância. A zona primária pode ter VDAs com aplicativos que estão fortemente acoplados ao banco de dados e à infraestrutura.
Zona satélite:
Uma zona satélite contém um ou mais VDAs, Controllers, servidores StoreFront e servidores Citrix Gateway. Em operações normais, os Controllers em uma zona satélite se comunicam diretamente com o banco de dados na zona primária.
Uma zona satélite, particularmente uma grande, também pode conter um hypervisor que é usado para provisionar e armazenar máquinas para essa zona. Ao configurar uma zona satélite, você pode associar um hypervisor ou outra conexão de serviço a ela. (Certifique-se de que todos os catálogos que usam essa conexão estejam na mesma zona.)
Um site pode ter zonas satélite de diferentes configurações, com base em suas necessidades e ambiente exclusivos. A figura a seguir ilustra uma zona primária e exemplos de zonas satélite.
Na ilustração:
-
Zona primária: Contém dois Controllers, Web Studio, Director, StoreFront, License Server e o banco de dados do site (além de implantações de SQL Server de alta disponibilidade). A zona primária também contém vários VDAs e um Citrix Gateway.
-
Zona satélite 1: VDAs com Controller: A zona satélite 1 contém um Controller, VDAs e um servidor StoreFront. Os VDAs nesta zona satélite se registram no Controller local. O Controller local se comunica com o banco de dados do site e o servidor de licenças na zona primária.
Se a WAN falhar, o recurso Local Host Cache permite que o Controller na zona satélite continue a intermediar conexões para VDAs nessa zona. Tal implantação pode ser eficaz em um escritório onde os trabalhadores usam um site StoreFront local e o Controller local para acessar seus recursos locais.
-
Zona satélite 2: VDAs com Controllers redundantes: A zona satélite 2 contém dois Controllers, VDAs e um servidor StoreFront. Este é o tipo de zona mais resiliente, oferecendo proteção contra uma falha simultânea da WAN e de um dos Controllers locais.
Onde os VDAs se registram e onde os Controllers fazem failover
Em um site contendo zonas primárias e satélite, com VDAs na versão mínima 7.7:
- Um VDA na zona primária se registra em um Controller na zona primária. Um VDA na zona primária nunca tenta se registrar em um Controller em uma zona satélite.
- Um VDA em uma zona satélite se registra em um Controller local, se possível. (Este é considerado o Controller preferencial.) Se nenhum Controller local estiver disponível (por exemplo, porque não podem aceitar mais registros de VDA ou falharam), o VDA tentará se registrar em um Controller na zona primária. Neste caso, o VDA permanece registrado na zona primária, mesmo que um Controller em uma zona satélite se torne disponível novamente. Um VDA em uma zona satélite nunca tenta se registrar em um Controller em outra zona satélite.
- Quando a atualização automática está habilitada para a descoberta de Controllers por VDA, e você especifica uma lista de endereços de Controller durante a instalação do VDA, um Controller é selecionado aleatoriamente dessa lista para o registro inicial (independentemente da zona em que o Controller reside). Após a reinicialização da máquina com esse VDA, o VDA começará a preferir se registrar em um Controller em sua zona local.
- Se um Controller em uma zona satélite falhar, ele faz failover para outro Controller local, se possível. Se nenhum Controller local estiver disponível, ele faz failover para um Controller na zona primária.
- Se você mover um Controller para dentro ou para fora de uma zona, e a atualização automática estiver habilitada, os VDAs em ambas as zonas recebem listas atualizadas indicando quais Controllers são locais e quais estão na zona primária, para que saibam com quem podem se registrar e de quem podem aceitar conexões.
- Se você mover um catálogo para outra zona, os VDAs nesse catálogo se registrarão novamente nos Controllers na zona para onde você moveu o catálogo. (Ao mover um catálogo para outra zona, certifique-se de que esta zona e a zona com a conexão de host associada estejam bem conectadas. Se houver largura de banda limitada ou alta latência, mova a conexão de host para a mesma zona que contém o catálogo de máquinas associado.)
Se todos os Controllers na zona primária falharem:
- O Web Studio não pode se conectar ao site.
- As conexões com VDAs na zona primária não podem ser feitas.
- O desempenho do site degrada até que os Controllers na zona primária se tornem disponíveis.
Para sites contendo versões de VDA anteriores à 7.7:
- Um VDA em uma zona satélite aceita solicitações de Controllers em sua zona local e na zona primária. (VDAs na versão mínima 7.7 podem aceitar solicitações de Controller de outras zonas satélite.)
- Um VDA em uma zona satélite se registra em um Controller na zona primária ou na zona local aleatoriamente. (VDAs na versão mínima 7.7 preferem a zona local.)
Preferência de zona
Para usar o recurso de preferência de zona, você deve estar usando no mínimo StoreFront 3.7 e Citrix Gateway 11.0-65.x.
Em um site multi-zona, o recurso de preferência de zona oferece ao administrador mais flexibilidade para controlar qual VDA é usado para iniciar um aplicativo ou desktop.
Como funciona a preferência de zona
Existem três formas de preferência de zona. Você pode preferir usar um VDA em uma zona específica, com base em:
- Onde os dados do aplicativo estão armazenados. Isso é conhecido como application home.
- A localização dos dados de origem do usuário, como um perfil ou compartilhamento doméstico. Isso é conhecido como user home.
- A localização atual do usuário (onde o aplicativo Citrix Workspace™ está sendo executado). Isso é conhecido como user location.
O gráfico a seguir mostra um exemplo de configuração multi-zona.
Neste exemplo, os VDAs estão espalhados por três zonas satélite, mas todos estão no mesmo Delivery Group. Portanto, o broker pode ter uma escolha de qual VDA usar para uma solicitação de inicialização do usuário. Este exemplo indica que existem vários locais onde os usuários podem estar executando seus endpoints do aplicativo Citrix Workspace:
- O Usuário A está usando um dispositivo com o aplicativo Citrix Workspace na zona satélite 1.
- O Usuário B está usando um dispositivo na zona satélite 2.
-
Os documentos de um usuário podem ser armazenados em vários locais.
- Os Usuários A e B usam um compartilhamento baseado na zona satélite 1.
- O Usuário C usa um compartilhamento da zona satélite C.
- Um dos aplicativos publicados usa um banco de dados localizado na zona satélite 1.
Você associa um usuário ou aplicativo a uma zona configurando uma zona de origem para o usuário ou aplicativo. O broker no Delivery Controller™ então usa essas associações para ajudar a selecionar a zona onde uma sessão será iniciada, se houver recursos disponíveis. Você pode:
- Configurar a zona de origem para um usuário adicionando um usuário a uma zona.
- Configurar a zona de origem para um aplicativo editando as propriedades do aplicativo.
Um usuário ou um aplicativo pode ter apenas uma zona de origem por vez. (Uma exceção para usuários pode ocorrer quando várias associações de zona ocorrem devido à associação a grupos de usuários; consulte a seção “Outras considerações”. No entanto, mesmo neste caso, o broker usa apenas uma zona de origem.)
Embora as preferências de zona para usuários e aplicativos possam ser configuradas, o broker seleciona apenas uma zona preferencial para uma inicialização. A ordem de prioridade padrão para selecionar a zona preferencial é application home > user home > user location. Você pode restringir a sequência; consulte Personalizando a preferência de zona. Quando um usuário inicia um aplicativo:
- Se esse aplicativo tiver uma associação de zona configurada (uma application home), a zona preferencial será a zona de origem para esse aplicativo.
- Se o aplicativo não tiver uma associação de zona configurada, mas o usuário tiver uma associação de zona configurada (uma user home), a zona preferencial será a zona de origem para esse usuário.
- Se nem o aplicativo nem o usuário tiverem uma associação de zona configurada, a zona preferencial será a zona onde o usuário está executando uma instância do aplicativo Citrix Workspace (a user location). Se essa zona não for definida, uma seleção aleatória de VDA e zona será usada. O balanceamento de carga é aplicado a todos os VDAs na zona preferencial. Se não houver zona preferencial, o balanceamento de carga é aplicado a todos os VDAs no Delivery Group.
Personalizando a preferência de zona
Ao configurar (ou remover) uma zona de origem para um usuário ou um aplicativo, você também pode restringir ainda mais como a preferência de zona é usada.
- Uso obrigatório da zona de origem do usuário: Em um Delivery Group, você pode especificar que as sessões sejam iniciadas na zona de origem do usuário (se configurada), sem failover para outra zona se a zona de origem não tiver recursos disponíveis. Essa restrição é útil quando você deve evitar o risco de copiar grandes perfis ou arquivos de dados entre zonas. Em outras palavras, você preferiria negar o início de uma sessão a iniciar a sessão em uma zona diferente.
- Uso obrigatório da zona de origem do aplicativo: Da mesma forma, ao configurar uma zona de origem para um aplicativo, você pode indicar que o aplicativo seja iniciado apenas nessa zona, sem failover para uma zona diferente se os recursos não estiverem disponíveis na zona de origem do aplicativo.
- Nenhuma zona de origem do aplicativo e ignorar a zona de origem do usuário configurada: Se você não especificar uma zona de origem para um aplicativo, também pode indicar que nenhuma zona de usuário configurada seja considerada ao iniciar esse aplicativo. Por exemplo, você pode preferir que os usuários executem um aplicativo em um VDA próximo ao seu dispositivo, usando a preferência de zona de localização do usuário, mesmo que alguns usuários possam ter uma zona de origem diferente.
Como as zonas preferenciais afetam o uso da sessão
Quando um usuário inicia um aplicativo ou desktop, o broker prefere usar a zona preferencial em vez de usar uma sessão existente.
Se o usuário que inicia um aplicativo ou desktop já tiver uma sessão adequada para o recurso que está sendo iniciado (por exemplo, que pode usar o compartilhamento de sessão para um aplicativo, ou uma sessão que já está executando o recurso que está sendo iniciado), mas essa sessão estiver sendo executada em um VDA em uma zona diferente da zona preferencial para o usuário/aplicativo, o sistema poderá criar uma nova sessão. Isso satisfaz o lançamento na zona correta (se tiver capacidade disponível), antes de reconectar a uma sessão em uma zona menos preferencial para os requisitos de sessão desse usuário.
Para evitar uma sessão órfã que não pode mais ser alcançada, a reconexão é permitida para sessões desconectadas existentes, mesmo que estejam em uma zona não preferencial.
A ordem de desejabilidade para as sessões satisfazerem um lançamento é:
- Reconectar a uma sessão existente na zona preferencial.
- Reconectar a uma sessão desconectada existente em uma zona diferente da zona preferencial.
- Iniciar uma nova sessão na zona preferencial.
- Reconectar a uma sessão existente conectada em uma zona diferente da zona preferencial.
- Iniciar uma nova sessão em uma zona diferente da zona preferencial.
Outras considerações sobre a preferência de zona
- Se você configurar uma zona de origem para um grupo de usuários (como um grupo de segurança), os usuários desse grupo (por meio de associação direta ou indireta) serão associados à zona especificada. No entanto, um usuário pode ser membro de vários grupos de segurança e, portanto, pode ter uma zona de origem diferente configurada por meio de outra associação de grupo. Nesses casos, a determinação da zona de origem desse usuário pode ser ambígua.
Se um usuário tiver uma zona de origem configurada que não foi adquirida por meio de associação a grupo, essa zona será usada para a preferência de zona. Quaisquer associações de zona adquiridas por meio de associação a grupo são ignoradas.
Se o usuário tiver várias associações de zona diferentes adquiridas exclusivamente por meio de associação a grupo, o broker escolherá aleatoriamente entre as zonas. Uma vez que o broker faça essa escolha, essa zona será usada para lançamentos de sessão subsequentes, até que a associação do usuário ao grupo mude.
- A preferência de zona de localização do usuário requer a detecção do aplicativo Citrix Workspace no dispositivo endpoint pelo Citrix Gateway através do qual esse dispositivo está se conectando. O Citrix Gateway deve ser configurado para associar intervalos de endereços IP a zonas específicas, e a identidade da zona descoberta deve ser passada através do StoreFront para o Controller.
Para obter mais informações sobre a preferência de zona, consulte Zone preference internals.
Considerações, requisitos e melhores práticas
-
Você pode colocar os seguintes itens em uma zona: Controllers, catálogos de máquinas, conexões de host, usuários e aplicativos. Se um catálogo usa uma conexão de host, certifique-se de que o catálogo e a conexão estejam na mesma zona. (No entanto, com uma conexão de baixa latência e alta largura de banda disponível, eles podem estar em zonas diferentes.)
-
Quando você coloca itens em uma zona satélite, isso afeta como o site interage com eles e com outros objetos relacionados a eles.
- Quando os Controllers são colocados em uma zona satélite, presume-se que essas máquinas tenham boa conectividade (local) com hypervisors e VDAs na mesma zona. Os Controllers nessa zona satélite são então usados em preferência aos Controllers na zona primária para lidar com esses hypervisors e máquinas VDA.
- Quando uma conexão de hypervisor é colocada em uma zona satélite, presume-se que todos os hypervisors gerenciados por meio dessa conexão de hypervisor também residam nessa zona satélite. Os Controllers nessa zona satélite são então usados em preferência aos Controllers na zona primária ao se comunicar com essa conexão de hypervisor.
- Quando um catálogo de máquinas é colocado em uma zona satélite, presume-se que todas as máquinas VDA nesse catálogo estejam na zona satélite. Os Controllers locais são usados em preferência aos Controllers na zona primária ao tentar se registrar no site, depois que o mecanismo de atualização automática da lista de Controllers for ativado após o primeiro registro de cada VDA.
- As instâncias do Citrix Gateway também podem ser associadas a zonas. Isso é feito como parte da configuração do StoreFront Optimal HDX™ Routing, e não, como para os outros elementos descritos aqui, como parte da configuração do site. Quando um Citrix Gateway é associado a uma zona, ele é preferencialmente usado quando as conexões HDX para máquinas VDA nessa zona são utilizadas.
-
Ao criar um site de produção e, em seguida, criar o primeiro catálogo e Delivery Group, todos os itens estão na zona primária – você não pode criar zonas satélite até concluir essa configuração inicial. (Se você criar um site vazio, a zona primária inicialmente conterá apenas um Controller. Você pode criar zonas satélite antes ou depois de criar um catálogo e um Delivery Group.)
-
Ao criar a primeira zona satélite contendo um ou mais itens, todos os outros itens em seu site permanecem na zona primária.
-
A zona primária é nomeada ‘Primary’ por padrão; você pode alterar esse nome. Embora o Web Studio indique qual zona é a zona primária, é uma boa prática usar um nome facilmente identificável para a zona primária. Você pode reatribuir a zona primária (ou seja, tornar outra zona a zona primária), mas ela deve sempre conter o banco de dados do site e quaisquer servidores de alta disponibilidade.
-
Mantenha sempre o banco de dados do site na zona primária.
-
Depois de criar uma zona, você pode mover itens de uma zona para outra posteriormente. Essa flexibilidade permite que você separe potencialmente itens que funcionam melhor em proximidade. Por exemplo, mover um catálogo para uma zona diferente da conexão (host) que cria as máquinas no catálogo pode afetar o desempenho. Considere os possíveis efeitos não intencionais antes de mover itens entre zonas. Mantenha um catálogo e a conexão de host que ele usa na mesma zona, ou em zonas que estejam bem conectadas (por exemplo, por meio de uma rede de baixa latência e alta largura de banda).
-
Para um desempenho ideal, instale o Web Studio e o Director apenas na zona primária. Você pode acessar o Web Studio e o Director de uma zona satélite (por exemplo, uma zona satélite contendo Controllers para usar como failover se a zona primária se tornar inacessível) porque eles são aplicativos web.
-
Idealmente, o Citrix Gateway em uma zona satélite é usado para conexões de usuários que chegam a essa zona de outras zonas ou locais externos, embora você possa usá-lo para conexões dentro da zona.
-
Lembre-se: Para usar o recurso de preferência de zona, você deve estar usando no mínimo StoreFront 3.7 e Citrix Gateway 11.0-65.x.
Limites de qualidade da conexão
Os Controllers na zona satélite realizam interações SQL diretamente com o banco de dados do site. Isso impõe alguns limites à qualidade do link entre a zona satélite e a zona primária que contém o banco de dados do site. Os limites específicos são relativos ao número de VDAs e sessões de usuário nesses VDAs que são implantados na zona satélite. Assim, zonas satélite com apenas alguns VDAs e sessões podem funcionar com uma conexão de pior qualidade com o banco de dados do que zonas satélite com grande número de VDAs e sessões.
Para obter mais informações, consulte Latency and SQL Blocking Query Improvements.
O impacto da latência no desempenho de intermediação
Embora as zonas permitam que os usuários estejam em links de maior latência, desde que haja um broker local, a latência adicional inevitavelmente afeta a experiência do usuário final. Para a maioria do trabalho que os usuários fazem, eles experimentam lentidão causada por viagens de ida e volta entre os Controllers na zona satélite e o banco de dados do site.
Para iniciar aplicativos, ocorrem atrasos extras enquanto o processo de intermediação de sessão identifica VDAs adequados para enviar solicitações de inicialização de sessão.
Criar e gerenciar zonas
Um Administrador Completo pode realizar todas as tarefas de criação e gerenciamento de zonas. No entanto, você também pode criar uma função personalizada que permite criar, editar ou excluir uma zona. Mover itens entre zonas não requer permissões relacionadas a zonas (exceto permissão de leitura de zona); no entanto, você deve ter permissão de edição para os itens que está movendo. Por exemplo, para mover um catálogo de uma zona para outra, você deve ter permissão de edição para esse catálogo. Para obter mais informações, consulte Administração delegada.
Se você usa Citrix Provisioning™: O console do Citrix Provisioning não está ciente das zonas, por isso recomendamos usar o Web Studio para criar catálogos para zonas satélite. Crie o catálogo no Web Studio, especificando a zona satélite correta. Em seguida, use o console do Citrix Provisioning para provisionar máquinas nesse catálogo. (Se você criar o catálogo usando o assistente do Citrix Provisioning, o catálogo será colocado na zona primária. Você deve usar o Web Studio para movê-lo para a zona satélite posteriormente.)
Criar uma zona
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo.
- Selecione Create Zone na barra de ações.
- Insira um nome para a zona e uma descrição (opcional). O nome deve ser exclusivo dentro do site.
- Selecione os itens a serem colocados na nova zona. Você pode filtrar ou pesquisar a lista de itens dos quais pode selecionar. Você também pode criar uma zona vazia; simplesmente não selecione nenhum item.
- Clique em Save.
Como alternativa a este método, você pode selecionar um ou mais itens no Web Studio e, em seguida, selecionar Create Zone na barra de ações.
Alterar o nome ou a descrição de uma zona
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo.
- Selecione uma zona no painel central e, em seguida, selecione Edit Zone na barra de ações.
- Altere o nome da zona, a descrição ou ambos. Se você alterar o nome da zona primária, certifique-se de que a zona permaneça facilmente identificável como a zona primária.
- Clique em Save ou Apply.
Mover itens de uma zona para outra
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo.
- Selecione uma zona no painel central e, em seguida, selecione um ou mais itens.
- Arraste os itens para a zona de destino ou selecione Move Items na barra de ações e, em seguida, especifique para qual zona movê-los.
Uma mensagem de confirmação lista os itens selecionados e pergunta se você tem certeza de que deseja mover todos eles.
Lembre-se: Quando um catálogo usa uma conexão de host para um hypervisor ou outro serviço, coloque o catálogo e a conexão na mesma zona. Caso contrário, o desempenho pode ser afetado. Se você mover um, mova o outro também.
Excluir uma zona
Uma zona deve estar vazia antes de poder ser excluída. Você não pode excluir a zona primária.
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo.
- Selecione uma zona no painel central.
- Selecione Delete Zone na barra de ações. Se a zona não estiver vazia (contém itens), você será solicitado a escolher a zona para onde esses itens serão movidos.
- Confirme a exclusão.
Adicionar uma zona de origem para um usuário
Configurar uma zona de origem para um usuário também é conhecido como adicionar um usuário a uma zona.
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo e, em seguida, selecione uma zona no painel central.
- Selecione Add Users to Zone na barra de ações.
- Na caixa de diálogo Add Users to Zone, clique em Add e, em seguida, selecione os usuários e grupos de usuários a serem adicionados à zona. Se você especificar usuários que já têm uma zona de origem, uma mensagem oferece duas opções: Yes = adicionar apenas os usuários especificados que não têm uma zona de origem; No = retornar à caixa de diálogo de seleção de usuário.
- Clique em OK.
Para usuários com uma zona de origem configurada, você pode exigir que as sessões sejam iniciadas apenas de sua zona de origem:
- Crie ou edite um delivery group.
- Na página Users, selecione a caixa de seleção Sessions must launch in a user’s home zone, if configured.
Todas as sessões iniciadas por um usuário nesse delivery group devem ser iniciadas a partir de máquinas na zona de origem desse usuário. Se um usuário no delivery group não tiver uma zona de origem configurada, essa configuração não terá efeito.
Remover uma zona de origem para um usuário
Este procedimento também é conhecido como remover um usuário de uma zona.
- Faça login no Web Studio.
- Selecione Zones no painel esquerdo e, em seguida, selecione uma zona no painel central.
- Selecione Remove Users from Zone na barra de ações.
- Na caixa de diálogo Add Users to Zone, clique em Remove e, em seguida, selecione os usuários e grupos a serem removidos da zona. Esta ação remove os usuários apenas da zona; esses usuários permanecem nos delivery groups e application groups aos quais pertencem.
- Confirme a remoção quando solicitado.
Gerenciar zonas de origem para aplicativos
Configurar uma zona de origem para um aplicativo também é conhecido como adicionar um aplicativo a uma zona. Por padrão, em um ambiente multi-zona, um aplicativo não tem uma zona de origem.
A zona de origem de um aplicativo é especificada nas propriedades do aplicativo. Você pode configurar as propriedades do aplicativo ao adicioná-lo a um grupo ou posteriormente.
- Ao criar um Delivery Group, criar um Application Group ou adicionar aplicativos a grupos existentes, selecione Properties na página Applications do assistente.
- Para alterar as propriedades de um aplicativo depois que ele for adicionado, selecione Applications no painel esquerdo. Selecione um aplicativo e, em seguida, selecione Edit Application Properties na barra de ações.
Na página Zones das propriedades/configurações do aplicativo:
- Se você quiser que o aplicativo tenha uma zona de origem:
- Selecione o botão de rádio Use the selected zone to decide e, em seguida, selecione a zona.
- Se você quiser que o aplicativo seja iniciado apenas da zona selecionada (e não de qualquer outra zona), selecione a caixa de seleção abaixo da seleção da zona.
- Se você não quiser que o aplicativo tenha uma zona de origem:
- Selecione o botão de rádio Do not configure a home zone.
- Se você não quiser que o broker considere nenhuma zona de usuário configurada ao iniciar esse aplicativo, selecione a caixa de seleção abaixo do botão de rádio. Neste caso, nem as zonas de origem do aplicativo nem as do usuário são usadas para determinar onde iniciar este aplicativo.
Outras ações que incluem a especificação de zonas
Depois de criar pelo menos uma zona satélite, você pode especificar uma zona ao adicionar uma conexão de host ou criar um catálogo.
Normalmente, a zona primária é a padrão. Ao usar o Machine Creation Services™ para criar um catálogo, a zona configurada para a conexão de host é selecionada automaticamente.
Se o site não contiver zonas satélite, a zona primária é assumida e a caixa de seleção de zona não aparece.