Este site utiliza cookies

Utilizamos cookies para melhorar sua experiência de navegação, personalizar conteúdo e analisar nosso tráfego. Ao clicar em 'Aceitar', você concorda com o uso de cookies conforme nossa Política de Privacidade.

Virtualização

Preenchendo a Lacuna (.Local): Um Design de Domínio Dividido para Implantação do VMware Cloud Foundation

VMware
20 de abril de 2026
6 min de leitura
Compartilhar:
Preenchendo a Lacuna (.Local): Um Design de Domínio Dividido para Implantação do VMware Cloud Foundation

No cenário em constante evolução da nuvem privada, a dívida técnica frequentemente se esconde nos lugares mais fundamentais, como sua convenção de nomenclatura DNS. Por muitos anos, .local foi o Top-Level Domain (TLD) preferido para ambientes internos do Active Directory. No entanto, de acordo com a RFC 6762, .local agora está oficialmente reservado para Multicast DNS (mDNS) e não é mais recomendado para DNS unicast em ambientes corporativos. À medida que evoluímos o VMware Cloud Foundation (VCF), estamos implementando salvaguardas mais rigorosas para alinhar com esses padrões globais, incentivando uma mudança para TLDs válidos, roteáveis ou não conflitantes.

O Desafio: O Endurecimento do VCF

Como parte de nosso compromisso com a segurança e estabilidade da plataforma, iniciamos o "endurecimento" da pilha VCF. Isso significa que vários componentes modernos estão perdendo o suporte para TLDs .local para evitar conflitos de resolução e vulnerabilidades de segurança.

Onde .local não é mais suportado:

  • VCF Identity Broker (VIDB): A espinha dorsal de autenticação moderna para VCF 9.x.
  • VCF Automation: Capacidades modernas de gerenciamento de nuvem.
  • vSphere Supervisor: Essencial para o consumo de Kubernetes e entrega de aplicações modernas.

Onde .local ainda é suportado (por enquanto):

Para fornecer uma janela de transição, os componentes da infraestrutura central ainda permitem a configuração .local:

  • VCF Operations
  • vCenter Server
  • VCF Networking (NSX)
  • SDDC Manager

Cenário de Design: A Estratégia de Transição

Entendemos que migrar a infraestrutura DNS de uma empresa inteira não é uma tarefa da noite para o dia. Se seus componentes VCF centrais (vCenter, NSX, SDDC Manager) já estão vinculados a um domínio .local e você não está pronto para uma renomeação em larga escala, você precisa de um design DNS híbrido para consumir serviços VCF modernos.

O Padrão de Design Recomendado

Para preencher a lacuna, recomendamos uma abordagem de "Zona de Transição". Enquanto seus componentes de gerenciamento centrais permanecem em .local, você deve introduzir um TLD em conformidade com os padrões (por exemplo, corp.vcf.com ou vcf.internal ou Green.NET) para os serviços modernos que deseja implantar.

O design proposto aborda o desafio de modernizar um ambiente VMware Cloud Foundation (VCF) que ainda depende de um Top-Level Domain (TLD) .local legado. Como os componentes modernos estão cada vez mais "endurecidos" contra o uso de .local devido aos padrões RFC, este design implementa uma arquitetura de domínio dividido para preencher a lacuna entre a infraestrutura central legada e os serviços de consumo modernos.

Arquitetura de Domínio Dividido

O design divide o ambiente em duas zonas lógicas distintas com base em seus requisitos técnicos e suportabilidade:

Zona de Infraestrutura Legada (Blue.LOCAL): Esta zona serve os componentes da infraestrutura central do VCF que ainda suportam .local para compatibilidade com versões anteriores.

  • vCenter Server: vCenter.Blue.local
  • VCF Operations: ops.Blue.local
  • NSX Manager: nsx.Blue.local

Zona de Consumo Moderna (Green.NET): Esta zona utiliza um TLD em conformidade com a RFC para serviços mais novos onde .local é estritamente não suportado.

  • VCF Automation (VCFA): VCFA.green.net
  • Supervisor / VMware vSphere Kubernetes Service (VKS): sup.green.net ou vks.green.net
  • VCF Identity Broker (VIDB): vidb.green.net

Opções de Implementação para Interoperabilidade

Para permitir que essas duas zonas se comuniquem e funcionem como uma plataforma unificada, o design propõe dois métodos de integração primários:

RecursoOpção 1: Trust de FlorestaOpção 2: Domínios Distintos
ConectividadeEstabelece um Trust de Floresta Bidirecional entre Blue.LOCAL e Green.NET.Mantém os domínios como Entidades completamente Distintas.
Estratégia DNSIdentidade e registros DNS compartilhados em toda a floresta.Utiliza o Encaminhamento DNS para resolver consultas entre os dois domínios.

Requisitos Críticos de Configuração

Para garantir a implantação bem-sucedida e a funcionalidade de Single Sign-On (SSO), as seguintes salvaguardas de configuração devem ser seguidas:

  • Alinhamento do Provedor de Identidade (IdP): A configuração de SSO deve reconhecer tanto Green.NET quanto Blue.local como Provedores de Identidade válidos para permitir que usuários de qualquer domínio acessem a plataforma.
  • Domínios de Pesquisa: Ao implantar componentes, é obrigatório configurar tanto Green.NET quanto Blue.LOCAL na lista de domínios de pesquisa DNS. Isso garante que os serviços na zona moderna possam localizar e se comunicar corretamente com a infraestrutura central legada.

Etapas de Implementação

  1. Mantenha o Core: Mantenha seus VCF Operations, vCenter, NSX e SDDC Manager existentes no domínio .local para evitar renomeações disruptivas.
  2. Estabeleça um Novo Domínio: Crie um novo domínio DNS em conformidade com a RFC (como .net ou .internal) em seu ambiente.
  3. Implante Serviços Modernos na Nova Zona: Ao implantar VIDB, VCF Automation ou vSphere Supervisor, use os novos FQDNs.
  4. Resolução Cross-Zone: Garanta que seus servidores DNS possam resolver tanto a zona .local legada quanto a nova zona moderna para permitir a comunicação entre componentes.

Para que este design híbrido funcione corretamente, duas etapas de configuração específicas são obrigatórias durante a implantação:

  • Domínios de Pesquisa Duplos: Ao implantar qualquer componente (especialmente na zona Green.NET), você deve configurar AMBOS Green.NET e Blue.LOCAL na lista de domínios de pesquisa DNS. Isso garante que um serviço moderno como o VKS possa encontrar o vCenter legado do qual depende.
  • Identidade SSO Unificada: O Provedor de Identidade (IdP) deve ser configurado para reconhecer os domínios Green.NET e Blue.local. Isso permite que usuários de ambos os domínios se autentiquem em cada componente.

Este design de domínio dividido oferece um caminho estratégico para os clientes VCF adotarem novas capacidades e recursos sem o ônus imediato e custoso de uma migração de domínio .local em larga escala. Ao alavancar uma arquitetura de zona dupla e configuração essencial entre domínios, as empresas podem garantir a estabilidade da plataforma, a conformidade de segurança e o acesso a todas as capacidades de próxima geração do VCF hoje.

Descubra mais no Blog VMware Cloud Foundation (VCF) Assine para receber as últimas publicações em seu e-mail. Digite seu e-mail… Assinar


Como parceira certificada, a VirtuAllIT pode auxiliar sua empresa na avaliação, planejamento e implementação de estratégias de modernização do VMware Cloud Foundation, garantindo uma transição suave e a otimização de sua infraestrutura.

Precisa de ajuda com suas soluções de TI?

A VirtuAllIT Solutions oferece consultoria especializada em virtualização, cloud computing e infraestrutura tecnológica.