O blog da AWS
Amazon WorkSpaces – The Subnet in which the WorkSpace was launched does not have an available private IP Address
Por Caio Ribeiro César e Matheus Arrais
Recentemente, fomos informados que ao escalar o ambiente, algumas organizações estavam recebendo o erro “The Subnet in which the WorkSpace was launched does not have an available” (a sub-rede na qual o WorkSpace foi iniciado não possui um recurso disponível). Neste post, iremos discutir como resolver este problema quando a organização possui um ambiente de AWS WorkSpaces utilizando o AD Connector para direcionar solicitações de diretório para o Microsoft Active Directory local (sem armazenar nenhuma informação em cache na nuvem).
O Amazon WorkSpaces é uma solução de desktop como serviço (DaaS) gerenciada e segura.
Você pode usar o Amazon WorkSpaces para provisionar desktops Windows ou Linux em apenas alguns minutos e escalar rapidamente para oferecer milhares de desktops para funcionários em todo o mundo. O Amazon WorkSpaces ajuda a eliminar a complexidade do gerenciamento de inventário de hardware, versões e patches de SO e infraestrutura de desktops virtuais (VDI), simplificando a estratégia de entrega de desktops.
Com o Amazon WorkSpaces, os usuários obtêm um desktop rápido e responsivo à sua escolha que pode ser acessado em qualquer lugar, a qualquer momento, de qualquer dispositivo compatível. Confira aqui se seu dispositivo é compatível.
O Amazon WorkSpaces usa diretórios para armazenar e gerenciar informações para seus WorkSpaces e usuários. Para seu diretório, você pode escolher entre:
- Simple Active Directory (não disponível na Regiao São de Paulo).
- Active Directory Connector.
- AWS Directory Service para o Microsoft Active Directory, também conhecido como “Managed AD”
- Diretórios externos, como o Azure Active Directory Domain Services.
Neste cenário, seguimos os passos recomendados do artigo “Ativar um WorkSpace usando o AD Connector”.
Parte 1 – Identificando o problema
Iniciamos identificando o problema. As WorkSpaces iniciam, porém recebíamos uma mensagem de erro na console informando que a subnet não possuía um IP disponível:
 |
Continuamos com a investigação, ao coletar as informações da VPC em que os WorkSpaces estavam sendo criados e posteriormente suas subnets:
VPC onde estão as Workspaces e consequentemente o AD Conector:
 |
Subnet1:
 |
Subnet2:
 |
Confirmamos no AD Connector que estas subnets estavam sendo utilizadas:
 |
AD Connector utiliza os gateways de comunicação com o Active Directory local nos IPs 10.0.5.139 e 10.0.6.202 em duas subnets /24, e para essa comunicação utiliza uma conta de serviço “directory”.
Tendo em conta a informação “Available IPv4” em cada subnet, somamos a disponibilidade de 500 IPs, o que explica o erro já que que nesse caso temos subir um numero maior do que 500 WorkSpaces criadas no ambiente. Lembrando que cada subnet do AWS VPC consome cinco endereços IP sendo os quatro primeiros e o último endereço IP para fins de gerenciamento, saiba mais a respeito acessando este link para a documentação. Além disso, cada AD Connector consome um endereço IP em cada sub-rede em que existir.
Parte 2 – Desenvolvimento da solução
Iniciamos a etapa de análise para uma possível solução, considerando os pontos abaixo:
a) Alterar o CIDR das subnets: não era uma possibilidade, já que subnets devem ser recriadas para esta alteração.
b) Alterar as subnets diretamente no WorkSpaces: não existe tal configuração.
c) Alterar o AD Connector que o WorkSpaces utiliza: não era uma possibilidade, tendo em conta que para alterar o diretório, devemos efetuar o “Deregister” e consequentemente remover os WorkSpaces do diretório, como era um ambiente em produção essa opção foi descartada e reforçada pela imagem abaixo que indica a mensagem “Na Error Has Ocurred. Directory can only be removed if there are no Workspaces assigned”.
 |
d) Alterar as subnets do AD Connector: não existe tal opção para modificar a subnet de um AD Connector já criado.
e) Criar um novo AD Connector e utilizar duas novas subnets com um novo diretório para o WorkSpaces – esta seria a solução, desde que consideradas as melhores práticas para que o usuário da conta do AD Connector seja diferente do usuário configurado para o AD Connector já existente.
Parte 3 – A solução
Partindo então da opção “e” do item anterior, temos a seguinte solução: criar novas subnets e um novo AD Connector para servir os desktops virtuais criados a partir de agora.
 |
a) Criamos duas novas subnets, tendo em vista que a alta utilização de recursos se deu devido ao aumento inesperado no número de usuários precisando de virtual desktops do WorkSpaces nesta subnet. Então, utilizamos duas novas subnets /24:
 |
b) Criamos um novo AD Connector, apontando para estas subnets (lembrando que a conta de serviço deve ser diferente do outro AD Connector sendo utilizado nesta rede).
 |
AD Connector utilizando os gateways de comunicação com o Active Directory local nos IPs 10.0.2.140 e 10.0.7.222 em duas subnets /24, e para essa comunicação utiliza uma conta de serviço “c4iocesar”.
 |
c) Agora no WorkSpaces
- Selecionamos o novo diretório.
 |
- Opção “Actions” > “Register”.
 |
- Selecionamos as novas subnets.
 |
 |
 |
- Finalmente podemos utilizar as WorkSpaces neste novo diretório.
 |
Conforme imagem abaixo, é possível verificar que foram lançadas novas Workspaces:
 |
Conclusão
Neste post, discutimos como escalar seu WorkSpaces ainda que tenham esgotado os endereços IP das suas subnets. Os WorkSpaces são executados em instâncias do Amazon EC2 hospedadas na VPC. A comunicação entre o EC2 e o cliente é gerenciada pelo protocolo PCoIP (PC sobre IP). A conexão do cliente deve permitir conexões de saída TCP e UDP na porta 4172, juntamente com conexões de saída TCP na porta 443. Para mais informações sobre o WorkSpaces, visite https://thinkwithwp.com/pt/workspaces/.
Sobre os autores
Matheus Arrais é Arquiteto de Soluções para Parceiros. Seu foco é em ferramentas de governanças e estratégia de múltiplas contas. Trabalha junto com parceiros de todo o Brasil ajudando-os a trilharem uma jornada de sucesso dentro da parceria da AWS e a entregar a melhor solução para seus clientes.
Caio Ribeiro César atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 13 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.