Citrix DaaS

Criar um catálogo do Google Cloud Platform

September 5, 2023

Contribuição de:

Criar catálogos de máquinas descreve os assistentes que criam um catálogo de máquinas. As informações a seguir abrangem detalhes específicos dos ambientes de nuvem do Google.

Nota:

Antes de criar um catálogo do Google Cloud Platform (GCP), você precisa concluir a criação de uma conexão com o GCP. Consulte Conexão com ambientes de nuvem do Google.

Preparar uma instância de VM mestre e um disco permanente

Dica:

Disco permanente é o termo do Google Cloud para disco virtual.

Para preparar a sua instância de VM mestre, crie e configure uma instância de VM com propriedades que correspondam à configuração desejada para as instâncias do VDA clonadas no seu catálogo de máquinas planejado. A configuração não se aplica somente ao tamanho e ao tipo da instância. Também inclui atributos de instância, como metadados, tags, atribuições de GPU, marcas de rede e propriedades da conta de serviço.

Como parte do processo, o MCS usa sua instância de VM mestre para criar o modelo de instância do Google Cloud. O modelo de instância é então usado para criar as instâncias do VDA clonadas que compõem o catálogo de máquinas. As instâncias clonadas herdam as propriedades (exceto as propriedades de VPC, sub-rede e disco permanente) da instância de VM mestre a partir da qual o modelo de instância foi criado.

Depois de configurar as propriedades da instância de VM mestre de acordo com suas especificações, inicie a instância e prepare o disco permanente para a instância.

Recomendamos que você crie manualmente um instantâneo do disco. Isso permite que você use uma convenção de nomenclatura significativa para controlar as versões, oferece mais opções para gerenciar versões anteriores da sua imagem mestre e economiza tempo na criação do catálogo de máquinas. Se você não criar o seu próprio instantâneo, o MCS cria um instantâneo temporário para você (que é apagado no final do processo de provisionamento).

Criar um catálogo de máquinas

Nota:

Crie os seus recursos antes de criar um catálogo de máquinas. Use as convenções de nomenclatura estabelecidas pelo Google Cloud ao configurar catálogos de máquinas. Consulte Diretrizes de nomenclatura de bucket e objeto para obter mais informações.

Siga as orientações em Criar catálogos de máquinas. A descrição a seguir é exclusiva para os catálogos do Google Cloud.

Em Manage > Full Configuration, selecione Machine Catalogs no painel esquerdo.
Selecione Create Machine Catalog na barra de ações.
Na página Machine Type, selecione Multi-session OS e, em seguida, selecione Next.
- O Citrix DaaS também oferece suporte a SO de sessão única.
Na página Machine Management, selecione as opções Machines that are power managed e Citrix Machine Creation Services e selecione Next. Se houver vários recursos, selecione um no menu.
Na página Master Image, complete as etapas conforme necessário e clique em Next.
1. Selecione um instantâneo ou uma VM como a imagem mestre. Se você quiser usar a funcionalidade de locação única, certifique-se de selecionar uma imagem cuja propriedade de grupo de nós esteja configurada corretamente. Consulte Habilitar a seleção de zona.
2. Para usar uma VM existente como perfil de máquina, selecione Use a machine profile e depois selecione a VM.
  
  Nota:
  
  Atualmente, as VMs desse catálogo herdam as configurações de ID do conjunto de criptografia de disco, tamanho da máquina, tipo de armazenamento e zona do perfil da máquina.
3. Selecione o nível funcional mínimo do catálogo.
Na página Storage, selecione o tipo de armazenamento usado para conter o sistema operacional desse catálogo de máquinas. Cada uma das opções de armazenamento a seguir tem características únicas de preço e desempenho. (Um disco de identidade é sempre criado usando o disco permanente padrão por zona.)
- Disco permanente padrão
- Disco permanente balanceado
- Disco permanente SSD
Para obter detalhes sobre as opções de armazenamento do Google Cloud, consulte https://cloud.google.com/compute/docs/disks/.
Na página Virtual Machines, especifique quantas VMs você deseja criar, confira a especificação detalhada das VMs e selecione Next. Se você usar grupos de nós de locatário único para catálogos de máquinas, certifique-se de selecionar apenas as zonas em que os nós de locatário único reservados estão disponíveis. Consulte Habilitar a seleção de zona.
Na página Disk Settings, você pode definir as seguintes configurações:
- Escolha se deseja ativar o cache de write-back. Depois de ativar o cache de write-back, você pode fazer o seguinte:
  - Configurar o tamanho do disco e da RAM usados para armazenar dados temporários em cache. Para obter mais informações, consulte Configurar cache para dados temporários.
  - Selecionar o tipo de armazenamento para o disco de cache de write-back. As seguintes opções de armazenamento estão disponíveis para uso no disco de cache de write-back:
    - Disco permanente padrão
    - Disco permanente balanceado
    - Disco permanente SSD
    Para obter detalhes sobre as opções de armazenamento do GCP, consulte https://cloud.google.com/compute/docs/disks/.
  - Selecione o tipo para o disco de cache de write-back.
    - Use non-persistent write-back cache disk. Se selecionado, o disco de cache de write-back não persistirá para as VMs provisionadas. O disco é excluído durante os ciclos de energia e todos os dados redirecionados para o disco serão perdidos.
    - Use persistent write-back cache disk. Se selecionado, o disco de cache de write-back persistirá para as VMs provisionadas. Habilitar essa opção aumenta os custos de armazenamento.
- Quando a otimização de armazenamento MCS (MCS I/O) está habilitada, você pode escolher se deseja reter os discos do sistema para VDAs durante os ciclos de alimentação de energia. Para obter mais informações, consulte Ativar atualizações de otimização de armazenamento MCS.
- Escolha se deseja usar sua própria chave para proteger o conteúdo do disco. Para usar o recurso, você deve primeiro criar suas próprias chaves de criptografia gerenciadas (CMEKs). Para obter mais informações, consulte Usar chaves de criptografia gerenciadas pelo cliente (CMEK).
  
  Nota:
  
  Ele está disponível somente na interface Manage > Full Configuration.
  
  Depois de criar as chaves, você pode selecionar uma das chaves na lista. Você não pode alterar a chave depois de criar o catálogo. O Google Cloud não é compatível com a rotação de chaves em imagens ou discos permanentes existentes. Portanto, depois de provisionar um catálogo, o catálogo é vinculado a uma versão específica da chave. Se essa chave for desabilitada ou destruída, as instâncias e os discos criptografados com ela ficam inutilizáveis até que a chave seja reativada ou restaurada.
Na página Machine Identities, selecione uma conta do Active Directory e, em seguida, selecione Next.
- Se você selecionar Create new Active Directory accounts, selecione um domínio e insira a sequência de caracteres que representa o esquema de nomenclatura para as contas de computador de VMs provisionadas criadas no Active Directory. O esquema de nomenclatura de conta pode conter de 1 a 64 caracteres e não pode conter espaços em branco ou caracteres não ASCII ou especiais.
- Se você selecionar Use existing Active Directory accounts, selecione Browse para navegar até as contas de computador existentes do Active Directory para as máquinas selecionadas.
Na página Domain Credentials, selecione Enter credentials, digite o nome de usuário e a senha, selecione Save e selecione Next.
- A credencial digitada deve ter permissões para realizar operações na conta do Active Directory.
Na página Scopes, selecione escopos para o catálogo de máquinas e, em seguida, selecione Next.
- Você pode selecionar escopos opcionais ou selecionar custom scope para personalizar os escopos conforme necessário.
Na página Summary, confirme as informações, especifique um nome para o catálogo e selecione Finish.

Nota:

O nome do catálogo pode conter de 1 a 39 caracteres e não pode conter apenas espaços em branco ou os caracteres \ / ; : # . * ? = < > | [ ] { } " ' ( ) ' ).

A criação do catálogo de máquinas pode levar muito tempo para ser concluída. Quando concluída, o catálogo será listado. Você pode verificar se as máquinas foram criadas nos grupos de nós de destino no console do Google Cloud.

Usar PowerShell para criar um catálogo com disco de cache de write-back persistente

Para configurar um catálogo com disco de cache de write-back persistente, use o parâmetro do PowerShell New-ProvScheme CustomProperties.

Dica:

Use o parâmetro PowerShell New-ProvScheme CustomProperties somente para conexões de hospedagem baseadas em nuvem. Se você deseja provisionar máquinas usando um disco de cache de write-back persistente para uma solução local (por exemplo, Citrix Hypervisor), o PowerShell não é necessário porque o disco persiste automaticamente.

Esse parâmetro suporta uma propriedade extra, PersistWBC, usada para determinar como o disco de cache de write-back persiste para máquinas provisionadas MCS. A propriedade PersistWBC só é usada quando o parâmetro UseWriteBackCache é especificado, e quando o parâmetro WriteBackCacheDiskSize é definido para indicar que um disco foi criado.

Nota:

Esse comportamento se aplica ao Azure e ao GCP, em que o disco de cache de write-back padrão do MCSIO é excluído e recriado durante o ciclo de energia. Você pode optar por manter o disco para evitar a exclusão e a recriação do disco de cache de write-back do MCSIO.

Exemplos de propriedades encontradas no parâmetro CustomProperties antes do suporte a PersistWBC incluem:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
</CustomProperties>
<!--NeedCopy-->

Nota:

Esse exemplo só se aplica ao Azure. As propriedades são diferentes no ambiente do GCP.

Ao usar essas propriedades, considere que elas contêm valores padrão se as propriedades forem omitidas do parâmetro CustomProperties. A propriedade PersistWBC tem dois valores possíveis: true ou false.

Definir a propriedade PersistWBC como true não exclui o disco de cache de write-back quando o administrador do Citrix Virtual Apps and Desktops desliga a máquina por meio da interface de gerenciamento.

Definir a propriedade PersistWBC como false exclui o disco de cache de write-back quando o administrador do Citrix Virtual Apps and Desktops desliga a máquina por meio da interface de gerenciamento.

Nota:

Se a propriedadePersistWBC for omitida, o padrão da propriedade será false e o cache de write-back será excluído quando a máquina for desligada por meio da interface de gerenciamento.

Por exemplo, uso do parâmetro CustomProperties para definir PersistWBC como true:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistWBC" Value="true" />
</CustomProperties>
<!--NeedCopy-->

Importante:

A propriedade PersistWBC só pode ser definida usando o cmdlet New-ProvScheme do PowerShell. Tentar alterar CustomProperties em um esquema de provisionamento após a criação não tem impacto no catálogo da máquina e na persistência do disco de cache de write-back quando uma máquina é desligada.

Por exemplo, definir New-ProvScheme para usar o cache de write-back ao definir a propriedade PersistWBC como true:

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistWBC`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

Melhorar o desempenho de inicialização com o MCSIO

Você pode melhorar o desempenho de inicialização dos discos gerenciados do Azure e do GCP quando o MCSIO estiver habilitado. Use a propriedade personalizada do PowerShell PersistOSDisk no comando New-ProvScheme para configurar esse recurso. As opções associadas a New-ProvScheme são:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="Resource<!--NeedCopy-->
``````<!--NeedCopy-->
````````Groups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistOsDisk" Value="true" />
</CustomProperties>
<!--NeedCopy-->

Para ativar esse recurso, defina a propriedade personalizada PersistOSDisk como true. Por exemplo:

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistOsDisk`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

Criar um catálogo de máquinas usando um perfil de máquina

Ao criar um catálogo para provisionar máquinas usando o Machine Creation Services (MCS), você pode usar um perfil de máquina para capturar as propriedades de hardware de uma máquina virtual e aplicá-las às VMs recém-provisionadas no catálogo. Quando o parâmetro MachineProfile não é usado, as propriedades do hardware são capturadas da VM da imagem mestre ou do instantâneo. Algumas propriedades que você define explicitamente, por exemplo, StorageType, CatalogZones e CryptoKeyIs, são ignoradas do perfil da máquina.

Para criar um catálogo com um perfil de máquina, use o comando New-ProvScheme. Por exemplo, New-ProvScheme –MachineProfile “path to VM”. Se você não especificar o parâmetro MachineProfile, as propriedades de hardware serão capturadas da VM da imagem mestre.
Para atualizar um catálogo com um novo perfil de máquina, use o comando Set-ProvScheme. Por exemplo, Set-ProvScheme –MachineProfile “path to new VM”. Esse comando não altera o perfil da máquina das VMs existentes no catálogo. Somente as VMs recém-criadas adicionadas ao catálogo têm o novo perfil de máquina.
Você também pode atualizar a imagem mestre; no entanto, quando você atualiza a imagem mestre, as propriedades do hardware não são atualizadas. Se você quiser atualizar as propriedades de hardware, você precisa atualizar o perfil da máquina usando o comando Set-ProvScheme. Essas alterações só se aplicarão às novas máquinas no catálogo. Para atualizar as propriedades de hardware de uma máquina existente, você pode usar o comando Set-ProvVMUpdateTimeWindow com os parâmetros -StartsNow e -DurationInMinutes -1.
Nota:
- StartsNow indica que a hora de início programada é a hora atual.
- DurationInMinutes com um número negativo (por exemplo, —1) indica que não há limite superior na janela de tempo do cronograma.

Criar um catálogo de máquinas com perfil de máquina como modelo de instância

Você pode selecionar um modelo de instância do GCP como uma entrada para o perfil da máquina. Os modelos de instância são recursos leves no GCP, portanto, são muito econômicos.

Para criar um novo catálogo de máquinas com perfil de máquina como um modelo de instância usando comandos do PowerShell:

Abra uma janela do PowerShell.
Execute o comando asnp citrix* para carregar os módulos do PowerShell específicos da Citrix.

Encontre um modelo de instância em seu projeto do GCP usando o seguinte comando:

cd XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder
<!--NeedCopy-->

Crie um novo catálogo de máquinas com perfil de máquina como modelo de instância usando o comando NewProvScheme:

New-ProvScheme -ProvisioningSchemeName <CatalogName>  -HostingUnitName <HostingUnitName> -IdentityPoolName <identity pool name> -MasterImageVM
XDHyp:\HostingUnits<HostingUnitName> \Base.vm\Base.snapshot -MachineProfile XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder\mytemplate.template
<!--NeedCopy-->

Para obter mais informações sobre o comando New-ProvScheme, consulte https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/New-ProvScheme/.

Conclua a criação do catálogo de máquinas usando os comandos do PowerShell.

Para alterar o perfil da máquina de um catálogo de máquinas existente para ser um modelo de instância:

Abra uma janela do PowerShell.
Execute o comando asnp citrix* para carregar os módulos do PowerShell específicos da Citrix.
Execute o seguinte comando:
```
Set-ProvScheme -ProvisioningSchemeName  <CatalogName> -MachineProfile XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder<TemplateName>.template

```
Para obter informações sobre o comando Set-ProvScheme, consulte https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/Set-ProvScheme/.

Usar o PowerShell para criar um catálogo com VM protegida

Você pode criar um catálogo de máquinas MCS com propriedades de VM protegida. Uma máquina virtual protegida é reforçada por um conjunto de controles de segurança que fornecem integridade verificável das instâncias do Compute Engine usando recursos avançados de segurança de plataforma, como reinicialização segura, Trusted Platform Module virtual, firmware UEFI e monitoramento de integridade.

O MCS suporta a criação do catálogo usando o fluxo de trabalho do perfil da máquina. Se você usar o fluxo de trabalho do perfil de máquina, deverá habilitar as propriedades de VM protegida de uma instância de VM. Em seguida, você pode usar essa instância de VM como uma entrada de perfil de máquina.

Para criar um catálogo de máquinas MCS com VM protegida usando o fluxo de trabalho do perfil da máquina.

Ative as opções de VM protegida de uma instância de VM no console do Google Cloud. Consulte Guia de início rápido: ativar opções de VM protegida.
Crie um catálogo de máquinas MCS com fluxo de trabalho de perfil de máquina usando a instância de VM.
1. Abra uma janela do PowerShell.
2. Execute o comando asnp citrix* para carregar os módulos do PowerShell específicos da Citrix.
3. Crie um pool de identidades se ainda não tiver sido criado.
4. Execute o comando New-ProvScheme. Por exemplo:
```
New-ProvScheme -ProvisioningSchemeName <catalog-name>
-HostingUnitName gcp-hostint-unit
-MasterImageVM XDHyp:\HostingUnits\gcp-hostint-unit\catalog-vda.vm
-MachineProfile XDHyp:\HostingUnits\gcp-hostint-unit\catalog-machine.vm

```
Conclua a criação do catálogo de máquinas.

Para atualizar o catálogo de máquinas com um novo perfil de máquina:

Execute o comando Set-ProvScheme. Por exemplo:

Set-ProvScheme -ProvisioningSchemeName <catalog-name>
-MasterImageVM XDHyp:\HostingUnits<hostin-unit>\catalog-vda.vm
-MachineProfile "DHyp:\HostingUnits<hostin-unit>\catalog-machine.vm
<!--NeedCopy-->

Para aplicar a alteração feita em Set-ProvScheme às VMs existentes, execute o comando Set-ProvVMUpdateTimeWindow.

Execute o comando Set-ProvVMUpdateTimeWindow. Por exemplo:

Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <List-Of-Vm-Names> -StartsNow -DurationInMinutes -1
<!--NeedCopy-->

Reinicie as VMs.

Importar máquinas do Google Cloud criadas manualmente

Você pode criar uma conexão com o Google Cloud e a seguir criar um catálogo contendo máquinas do Google Cloud. Em seguida, você pode ligar e desligar manualmente as máquinas do Google Cloud por meio do Citrix DaaS. Com esse recurso, você pode:

Importar máquinas com SO multissessão do Google Cloud criadas manualmente para um catálogo de máquinas do Citrix Virtual Apps and Desktops.
Remover as máquinas com SO multissessão do Google Cloud criadas manualmente de um catálogo do Citrix Virtual Apps and Desktops.
Usar os recursos existentes de gerenciamento de energia do Citrix Virtual Apps and Desktops para gerenciar a energia das máquinas com SO multissessão Windows do Google Cloud. Por exemplo, defina um agendamento de reinicialização para essas máquinas.

Essa funcionalidade não requer alterações no fluxo de trabalho de provisionamento existente do Citrix Virtual Apps and Desktops nem a remoção de qualquer recurso existente. Recomendamos que você use o MCS para provisionar máquinas na interface Full Configuration do Citrix DaaS, em vez de importar máquinas do Google Cloud criadas manualmente.

Nuvem privada virtual compartilhada

Nuvens privadas virtuais compartilhadas (VPCs) compreendem um projeto host, a partir do qual as sub-redes compartilhadas são disponibilizadas, e um ou mais projetos de serviço que usam o recurso. As VPCs compartilhadas são boas opções para instalações maiores porque fornecem controle, uso e administração centralizados dos recursos corporativos compartilhados do Google Cloud. Para obter mais informações, consulte o site de documentação do Google.

Com esse recurso, o MCS (Machine Creation Services) oferece suporte ao provisionamento e ao gerenciamento de catálogos de máquinas implantados em VPCs compartilhadas. Esse suporte, que é funcionalmente equivalente ao suporte fornecido atualmente nas VPCs locais, difere em duas áreas:

Você deve conceder permissões extras para a conta de serviço usada para criar a conexão de host. Esse processo permite que o MCS acesse e use os recursos da VPC compartilhada.
Você deve criar duas regras de firewall, uma para entrada e outra para saída. Essas regras de firewall são usadas durante o processo de masterização de imagens.

Novas permissões necessárias

É necessária uma conta de serviço do Google Cloud com permissões específicas ao criar a conexão do host. Essas permissões adicionais devem ser concedidas a todas as contas de serviço usadas para criar conexões de host baseadas em VPC compartilhada.

Dica:

Essas permissões adicionais não são novas no Citrix DaaS. Elas são usadas para facilitar a implementação de VPCs locais. Com as VPCs compartilhadas, essas permissões adicionais permitem o acesso a outros recursos de VPC compartilhadas.

No máximo quatro permissões extras devem ser concedidas à conta de serviço associada à conexão de host para aceitar à VPC compartilhada:

compute.firewalls.list – Essa permissão é obrigatória. Permite que o MCS recupere a lista de regras de firewall presentes na VPC compartilhada.
compute.networks.list – Essa permissão é obrigatória. Permite que o MCS identifique as redes VPC compartilhadas disponíveis para a conta de serviço.
compute.subnetworks.list – Essa permissão é opcional, dependendo de como você usa as VPCs. Permite que o MCS identifique as sub-redes nas VPCs compartilhadas visíveis. Essa permissão já é necessária ao usar VPCs locais, mas também deve ser atribuída no projeto host da VPC compartilhada.
compute.subnetworks.use – Essa permissão é opcional, dependendo de como você usa as VPCs. É necessário usar recursos de sub-rede nos catálogos de máquinas provisionadas. Essa permissão já é necessária para usar VPCs locais, mas também deve ser atribuída no projeto host da VPC compartilhada.

Ao usar essas permissões, considere que existem abordagens diferentes com base no tipo de permissão usada para criar o catálogo de máquinas:

Permissão no nível do projeto:
- Permite o acesso a todas as VPCs compartilhadas dentro do projeto host.
- Requer que as permissões 3 e 4 sejam atribuídas à conta de serviço.
Permissão no nível da sub-rede:
- Permite o acesso a sub-redes específicas dentro da VPC compartilhada.
- As permissões 3 e 4 são intrínsecas à atribuição de nível de sub-rede e, portanto, não precisam ser atribuídas diretamente à conta de serviço.

Selecione a abordagem que corresponde às suas necessidades organizacionais e aos padrões de segurança.

Dica:

Para obter mais informações sobre as diferenças entre as permissões no nível do projeto e no nível da sub-rede, consulte a documentação do Google Cloud.

Regras de firewall

Durante a preparação de um catálogo de máquinas, uma imagem de máquina é preparada para servir como o disco do sistema de imagem mestre para o catálogo. Quando esse processo ocorre, o disco é conectado temporariamente a uma máquina virtual. Essa VM deve ser executada em um ambiente isolado que impeça todo o tráfego de rede de entrada e de saída. Isso é feito por meio de um par de regras de firewall deny-all: uma para tráfego de entrada e outra para tráfego de saída. Ao usar os VCPs locais do Google Cloud, o MCS cria esse firewall na rede local e o aplica à máquina para masterização. Após a conclusão da masterização, a regra de firewall é removida da imagem.

Recomendamos manter um número mínimo de novas permissões necessárias para usar VPCs compartilhadas. As VPCs compartilhadas são recursos corporativos de nível superior e normalmente têm protocolos de segurança mais rígidos. Por esse motivo, crie um par de regras de firewall no projeto host nos recursos da VPC compartilhada, uma para entrada e outra para saída. Atribua a maior prioridade a elas. Aplique uma nova tag de destino a cada uma das regras, usando o seguinte valor:

citrix-provisioning-quarantine-firewall

Quando o MCS cria ou atualiza um catálogo de máquinas, ele procura regras de firewall que contenham essa tag de destino. Em seguida, ele examina as regras quanto à sua exatidão e as aplica à máquina usada para preparar a imagem mestre para o catálogo. Se as regras de firewall não forem encontradas ou se as regras forem encontradas, mas as regras ou suas prioridades estiverem incorretas, uma mensagem semelhante à seguinte será exibida:

"Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC <name> in project <project>. " Please ensure you have created 'deny all' firewall rules with the network tag ‘citrix-provisioning-quarantine-firewall' and proper priority." "Refer to Citrix Documentation for details."

Configurar a VPC compartilhada

Antes de adicionar a VPC compartilhada como uma conexão de host na interface Full Configuration do Citrix DaaS, conclua as etapas a seguir para adicionar contas de serviço do projeto que você pretende provisionar:

Crie uma função do IAM.
Adicione a conta de serviço usada para criar uma conexão de host CVAD à função do IAM do projeto host da VPC compartilhada.
Adicione a conta de serviço do Cloud Build do projeto que você pretende provisionar à função do IAM do projeto host da VPC compartilhada.
Crie regras de firewall.

Crie uma função do IAM

Determine o nível de acesso da função — acesso no nível do projeto ou um modelo mais restrito usando o acesso no nível da sub-rede.

Acesso no nível do projeto para a função do IAM. Para a função do IAM no nível do projeto, inclua as seguintes permissões:

compute.firewalls.list
compute.networks.list
compute.subnetworks.list
compute.subnetworks.use

Para criar uma função do IAM no nível do projeto:

No console do Google Cloud, navegue para IAM & Admin > Roles.
Na página Roles, selecione CREATE ROLE.
Na página Create Role, especifique o nome da função. Selecione ADD PERMISSIONS.
1. Na página Add permissions, adicione permissões à função, individualmente. Para adicionar uma permissão, digite o nome da permissão no campo Filter table. Selecione a permissão e, em seguida, selecione ADD.
2. Selecione CREATE.

Subnet-level IAM role. Essa função omite a adição das permissões compute.subnetworks.list e compute.subnetworks.use depois de selecionar CREATE ROLE. Para esse nível de acesso do IAM, as permissões compute.firewalls.list e compute.networks.list devem ser aplicadas à nova função.

Para criar uma função do IAM no nível da sub-rede:

No console do Google Cloud, navegue para VPC network > Shared VPC. A página Shared VPC é exibida, mostrando as sub-redes das redes VPC compartilhadas que o projeto host contém.
Na página Shared VPC, selecione a sub-rede que deseja acessar.
No canto superior direito, selecione ADD MEMBER para adicionar uma conta de serviço.
Na página Add members, conclua estas etapas:
1. No campo New members, digite o nome da sua conta de serviço e selecione a sua conta de serviço no menu.
2. Selecione o campo Select a role e depois Compute Network User.
3. Selecione SAVE.
No console do Google Cloud, navegue para IAM & Admin > Roles.
Na página Roles, selecione CREATE ROLE.
Na página Create Role, especifique o nome da função. Selecione ADD PERMISSIONS.
1. Na página Add permissions, adicione permissões à função, individualmente. Para adicionar uma permissão, digite o nome da permissão no campo Filter table. Selecione a permissão e, em seguida, selecione ADD.
2. Selecione CREATE.

Adicionar uma conta de serviço à função do IAM do projeto host

Depois de criar uma função do IAM, siga estas etapas para adicionar uma conta de serviço ao projeto host:

No console do Google Cloud, navegue até o projeto host e vá para IAM & Admin > IAM.
Na página IAM, selecione ADD para adicionar uma conta de serviço.
Na página Add members:
1. No campo New members, digite o nome da sua conta de serviço e selecione a sua conta de serviço no menu.
2. Selecione um campo de função, digite a função do IAM que você criou e, em seguida, selecione a função no menu.
3. Selecione SAVE.

Agora, a conta de serviço já está configurada para o projeto host.

Adicionar a conta de serviço do Cloud Build à VPC compartilhada

Cada assinatura do Google Cloud tem uma conta de serviço que tem, como nome, o número do ID do projeto, seguido por cloudbuild.gserviceaccount. Por exemplo: 705794712345@cloudbuild.gserviceaccount.

Você pode determinar qual é o número do ID do projeto selecionando Home e Dashboard no console do Google Cloud:

Painel de navegação do console do Google Cloud

Na tela, procure Project Number abaixo da área Project Info.

Execute as etapas a seguir para adicionar a conta de serviço do Cloud Build à VPC compartilhada:

No console do Google Cloud, navegue até o projeto host e vá para IAM & Admin > IAM.
Na página Permissions, selecione ADD para adicionar uma conta.
Na página Add members, conclua estas etapas:
1. No campo New members, digite o nome da conta de serviço do Cloud Build e selecione a sua conta de serviço no menu.
2. Selecione o campo Select a role, digite Computer Network User e, em seguida, selecione a função no menu.
3. Selecione SAVE.

Criar regras de firewall

Como parte do processo de masterização, o MCS copia a imagem da máquina selecionada e a usa para preparar o disco do sistema de imagem mestre para o catálogo. Durante a masterização, o MCS anexa o disco a uma máquina virtual temporária, que executa scripts de preparação. Essa VM deve ser executada em um ambiente isolado que proíba todo o tráfego de rede de entrada e saída. Para criar um ambiente isolado, o MCS exige duas regras de firewall deny all (uma regra de entrada e uma regra de saída). Portanto, crie duas regras de firewall em Host Project da seguinte forma:

No console do Google Cloud, navegue até o projeto host e, em seguida, para VPC network > Firewall.
Na página Firewall, selecione CREATE FIREWALL RULE.
Na página Create a firewall rule, preencha estes dados:
- Name. Digite um nome para a regra.
- Network. Selecione a rede VPC compartilhada à qual a regra de firewall de entrada se aplica.
- Priority. Quanto menor for o valor, maior será a prioridade da regra. Recomendamos um valor pequeno (por exemplo, 10).
- Direction of traffic. Selecione Ingress.
- Action on match. Selecione Deny.
- Targets. Use o padrão, Specified target tags.
- Target tags. Digite citrix-provisioning-quarantine-firewall.
- Source filter. Use o padrão, IP ranges.
- Source IP ranges. Digite um intervalo que corresponda a todo o tráfego. Digite 0.0.0.0/0.
- Protocols and ports. Selecione Deny all.
Selecione CREATE para criar a regra.
Repita as etapas de 1 a 4 para criar outra regra. Em Direction of traffic, selecione Egress.

Adicionar uma conexão

Depois de adicionar as interfaces de rede à instância do Cloud Connector, adicione uma conexão.

Habilitar a seleção de zona

O Citrix DaaS oferece suporte à seleção de zona. Com a seleção de zona, você especifica as zonas nas quais deseja criar as VMs. Com a seleção de zona, os administradores podem colocar nós de locatário único nas zonas de sua escolha. Para configurar a locação única, você deve fazer o seguinte no Google Cloud:

Reservar um nó de locatário único no Google Cloud
Criar a imagem mestre do VDA

Como reservar um nó de locatário único no Google Cloud

Para reservar um nó de locatário único, consulte a documentação do Google Cloud.

Importante:

Um modelo de nó é usado para indicar as características de desempenho do sistema reservado no grupo de nós. Essas características incluem o número de vGPUs, a quantidade de memória alocada para o nó e o tipo de máquina usado para máquinas criadas no nó. Para obter mais informações, consulte a documentação do Google Cloud.

Criar a imagem mestre do VDA

Para implantar máquinas no nó de locatário único com sucesso, você precisa executar etapas extras ao criar uma imagem de VM mestre. As instâncias de máquina no Google Cloud têm uma propriedade chamada node affinity labels. As instâncias usadas como imagens mestre para catálogos implantados no nó de locatário único exigem um node affinity label que corresponda ao nome do target node group. Para isso, tenha em mente o seguinte:

Para uma nova instância, defina o rótulo no console do Google Cloud ao criar uma instância. Para obter detalhes, consulte Definir um rótulo de afinidade de nó ao criar uma instância.
Para uma instância existente, defina o rótulo usando a linha de comando gcloud. Para obter detalhes, consulte Definir um rótulo de afinidade de nó para uma instância existente.

Nota:

Se você pretende usar a locação única com uma VPC compartilhada, consulte Nuvem privada virtual compartilhada.

Definir um rótulo de afinidade de nó ao criar uma instância

Para definir o rótulo de afinidade do nó:

No console do Google Cloud, navegue até Compute Engine > VM instances.
Na página VM instances, selecione Create instance.
Na página Instance creation, digite ou configure a informação necessária e selecione management, security, disks, networking, sole tenancy para abrir o painel de configurações.
Na guia Sole tenancy, selecione Browse para visualizar os grupos de nós disponíveis no projeto atual. A página Sole-tenant node é exibida, mostrando uma lista de grupos de nós disponíveis.
Na página Sole-tenant node, selecione o grupo de nós aplicável na lista e selecione Select para voltar à guia Sole tenancy. O campo de rótulos de afinidade do nós é preenchido com as informações selecionadas. Essa configuração garante que os catálogos de máquinas criados a partir da instância sejam implantados no grupo de nós selecionado.
Selecione Create para criar a instância.

Definir um rótulo de afinidade de nó para uma instância existente

Para definir o rótulo de afinidade do nó:

Na janela de terminal do Google Cloud Shell, use o comando gcloud compute instances para definir um rótulo de afinidade de nó. Inclua as seguintes informações no comando gcloud:
- Nome da VM. Por exemplo, use uma VM existente chamada s*2019-vda-base.*
- Nome do grupo de nós. Use o nome do grupo de nós que você criou anteriormente. Por exemplo, mh-sole-tenant-node-group-1.
- A zona em que a instância reside. Por exemplo, a VM reside em *us-east-1b* zone.
Por exemplo, digite o seguinte comando na janela do terminal:
- gcloud compute instances set-scheduling "s2019-vda-base" --node-group="mh-sole-tenant-node-group-1" --zone="us-east1-b"
Para obter mais informações sobre o comando gcloud compute instances, consulte a documentação do Google Developer Tools em https://cloud.google.com/sdk/gcloud/reference/beta/compute/instances/set-scheduling.
Navegue até a página VM instance details da instância e verifique se o campo Node Affinities é preenchido com o rótulo.

Criar um catálogo de máquinas

Depois de definir o rótulo de afinidade do nó, configure o catálogo de máquinas.

Usar chaves de criptografia gerenciadas pelo cliente (CMEK)

Você pode usar chaves de criptografia gerenciadas pelo cliente (CMEK) para catálogos do MCS. Ao usar essa funcionalidade, você atribui a função CryptoKey Encrypter/Decrypter do serviço Key Management Service do Google Cloud ao agente de serviço do Compute Engine. A conta Citrix DaaS deve ter as permissões corretas no projeto em que a chave está armazenada. Consulte Ajudar a proteger recursos usando chaves do Cloud KMS para obter mais informações.

Seu agente de serviço do Compute Engine está no seguinte formato: service-<Project _Number>@compute-system.iam.gserviceaccount.com. Esse formulário é diferente da conta de serviço padrão do Compute Engine.

Nota:

Essa conta de serviço do Compute Engine talvez não apareça na tela IAM Permissions do Google Console. Nesse caso, use o comando gcloud conforme descrito em Ajudar a proteger recursos usando chaves do Cloud KMS.

Atribuir permissões à conta Citrix DaaS

As permissões do Google Cloud KMS podem ser configuradas de várias maneiras. Você pode fornecer permissões de KMS no nível do projeto ou permissões de KMS no nível do recurso. Consulte Permissões e funções para obter mais informações.

Permissões no nível do projeto

Uma opção é fornecer à conta Citrix DaaS permissões no nível do projeto para navegar pelos recursos do Cloud KMS. Para isso, crie uma função personalizada e adicione as seguintes permissões:

cloudkms.keyRings.list
cloudkms.keyRings.get
cloudkms.cryptokeys.list
cloudkms.cryptokeys.get

Atribua essa função personalizada à sua conta Citrix DaaS. Isso permite que você navegue pelas chaves regionais no projeto relevante no inventário.

Permissões de nível do recurso

Na outra opção, de permissões no nível do recurso, no console do Google Cloud, navegue até a cryptoKey que você usa para o provisionamento de MCS. Adicione uma conta Citrix DaaS a um keyring ou chave que você usa para provisionamento de catálogo.

Dica:

Com essa opção, você não pode procurar chaves regionais para o seu projeto no inventário porque a conta do Citrix DaaS não tem permissões de lista de nível do projeto nos recursos do Cloud KMS. No entanto, você ainda pode provisionar um catálogo usando o CMEK especificando o cryptoKeyId correto nas propriedades personalizadas ProvScheme, como descrito abaixo.

Provisionar com CMEK usando propriedades personalizadas

Ao criar o seu esquema de provisionamento via PowerShell, especifique uma propriedade CryptoKeyId em ProvScheme CustomProperties. Por exemplo:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="<yourCryptoKeyId>" />
</CustomProperties>'
<!--NeedCopy-->

cryptoKeyId deve ser especificada no seguinte formato:

projectId:location:keyRingName:cryptoKeyName

Por exemplo, se você quiser usar a chave my-example-key no keyring my-example-key-ring na região us-east1 e no projeto com ID my-example-project-1, suas configurações personalizadas ProvScheme serão semelhantes a:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:us-east1:my-example-key-ring:my-example-key" />
</CustomProperties>'
<!--NeedCopy-->

Todas as imagens e discos provisionados do MCS relacionados a esse esquema de provisionamento usam essa chave de criptografia gerenciada pelo cliente.

Dica:

Se você usar chaves globais, o local das propriedades do cliente deverá indicar global e não o nome da região, que no exemplo acima é us-east1. Por exemplo: <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:global:my-example-key-ring:my-example-key" />.

Rotação de chaves gerenciadas pelo cliente

O Google Cloud não é compatível com a rotação de chaves em imagens ou discos permanentes existentes. Depois que uma máquina é provisionada, ela é vinculada à versão da chave em uso no momento em que foi criada. No entanto, uma nova versão da chave pode ser criada, e essa nova chave é usada para máquinas recém-provisionadas ou recursos criados quando um catálogo é atualizado com uma nova imagem mestre.

Considerações importantes sobre keyrings

Os keyrings não podem ser renomeados ou excluídos. Além disso, você pode incorrer em encargos imprevistos ao configurá-los. Ao excluir ou remover um keyring, o Google Cloud exibe uma mensagem de erro:

Sorry, you can't delete or rename keys or key rings. We were concerned about the security implications of allowing multiple keys or key versions over time to have the same resource name, so we decided to make names immutable. (And you can't delete them, because we wouldn't be able to do a true deletion--there would still have to be a tombstone tracking that this name had been used and couldn't be reused).
We're aware that this can make things untidy, but we have no immediate plans to change this.
If you want to avoid getting billed for a key or otherwise make it unavailable, you can do so by deleting all the key versions; neither keys nor key rings are billed for, just the active key versions within the keys.
<!--NeedCopy-->

Dica:

Para obter mais informações, consulte Editing or deleting a key ring from the console.

Compatibilidade de acesso uniforme no nível do bucket

O Citrix DaaS é compatível com a política de controle de acesso uniforme no nível do bucket no Google Cloud. Essa funcionalidade aumenta o uso da política do IAM que concede permissões a uma conta de serviço para permitir a manipulação de recursos, incluindo buckets de armazenamento. Com controle de acesso uniforme no nível do bucket, o Citrix DaaS permite que você use uma lista de controle de acesso (ACL) para controlar o acesso a buckets de armazenamento ou objetos armazenados neles. Consulte Acesso uniforme no nível do bucket para obter informações gerais sobre o acesso uniforme no nível do bucket no Google Cloud. Para obter informações de configuração, consulte Requerer acesso uniforme no nível do bucket.

Google Cloud Marketplace

Você pode navegar e selecionar imagens oferecidas pela Citrix no Google Cloud Marketplace para criar catálogos de máquinas. Atualmente, o MCS suporta somente o fluxo de trabalho de perfil de máquina para esse recurso.

Para pesquisar o produto Citrix VDA VM no Google Cloud Marketplace, acesse https://console.cloud.google.com/marketplace/.

Você pode usar uma imagem personalizada ou uma imagem pronta da Citrix no Google Cloud Marketplace para atualizar uma imagem de um catálogo de máquinas.

Nota:

Se o perfil da máquina não contiver informações sobre o tipo de armazenamento, o valor será derivado das propriedades personalizadas.

As imagens compatíveis do Google Cloud Marketplace são:

Windows 2019 Single Session
Windows 2019 Multi Session
Ubuntu

Exemplo de uso de uma imagem pronta da Citrix como fonte para criar um catálogo de máquinas:

New-ProvScheme -ProvisioningSchemeName GCPCatalog \
-HostingUnitName GcpHu -IdentityPoolName gcpPool -CleanOnBoot \
-MasterImageVM XDHyp:\HostingUnits\GcpHu\images.folder\citrix-daas-win2019-single-vda-v20220819.publicimage \
-MachineProfile XDHyp:\HostingUnits\GcpHu\Base.vm
<!--NeedCopy-->

O que fazer a seguir

Se este for o primeiro catálogo criado, você será guiado para criar um grupo de entrega.
Para revisar todo o processo de configuração, consulte Planejar e criar uma implantação.
Para gerenciar catálogos, consulte Gerenciar catálogos de máquinas e Gerenciar um catálogo do Google Cloud Platform.

Mais informações

A versão oficial deste conteúdo está em inglês. Parte do conteúdo da documentação da Cloud Software Group é traduzida automaticamente para sua conveniência. A Cloud Software Group não tem controle sobre o conteúdo traduzido automaticamente, que pode conter erros, imprecisões ou linguagem inadequada. Nenhuma garantia de qualquer tipo, expressa ou implícita, é fornecida quanto à precisão, confiabilidade, adequação ou correção de quaisquer traduções feitas do original em inglês para qualquer outro idioma, ou quanto à conformidade do seu produto ou serviço Cloud Software Group com qualquer conteúdo traduzido automaticamente, e nenhuma garantia fornecida sob o contrato de licença de usuário final aplicável ou os termos de serviço, ou qualquer outro contrato com a Cloud Software Group, de que o produto ou serviço esteja em conformidade com qualquer documentação será aplicável na medida em que essa documentação tenha sido traduzida automaticamente. A Cloud Software Group não se responsabiliza por quaisquer danos ou problemas que possam surgir em decorrência do uso de conteúdo traduzido automaticamente.

Isso foi útil?

Criar um catálogo do Google Cloud Platform

September 5, 2023

Contribuição de:

September 5, 2023

Contribuição de:

Neste artigo

Preparar uma instância de VM mestre e um disco permanente
Criar um catálogo de máquinas
Criar um catálogo de máquinas usando um perfil de máquina
Criar um catálogo de máquinas com perfil de máquina como modelo de instância
Usar o PowerShell para criar um catálogo com VM protegida
Importar máquinas do Google Cloud criadas manualmente
Nuvem privada virtual compartilhada
Habilitar a seleção de zona
Usar chaves de criptografia gerenciadas pelo cliente (CMEK)
Compatibilidade de acesso uniforme no nível do bucket
Google Cloud Marketplace
O que fazer a seguir
Mais informações

Isso foi útil?