Configurar DNS de um SDDC de Solução VMware Oracle Cloud

Este artigo mostra como obter a resolução do nome de DNS ao implantar o SRM e o vSphere Replication na Solução Oracle Cloud VMware.

A Solução VMware Oracle Cloud é uma implantação SDDC VMware com um clique da Console do Oracle Cloud Infrastructure. A automação da Solução VMware Oracle Cloud implanta definições padrão para VMware vSphere, NSX-T e VSAN, como nomes de host padrão, VLANS, grupos de segurança de rede (NSGs), tabelas de rota, listas de segurança e assim por diante. Para implantar e configurar o VMware SRM para implementação de recuperação de desastres, você deve modificar essas definições default.

A resolução de nomes dentro da infraestrutura virtual é um requisito chave para validação funcional de componentes do VMware. Falha ao atender este requisito pode levar a uma implementação SRM malsucedida para recuperação de desastres.

A Solução VMware do Oracle Cloud implanta o vCenter Server com modo incorporado com o domínio vsphere.local padrão do Single Sign-On/Platform Services Controller. Os outros produtos VMware e suas extensões são sempre integrados com o serviço de pesquisa do vCenter Server. Dessa forma, é importante que o appliance VMware SRM e vSphere Replication possa se comunicar com o vCenter Server usando o nome de domínio totalmente qualificado default (FQDN). Ao mesmo tempo, a implementação local do SRM também deve se comunicar com a implementação do SRM no Oracle Cloud VMware Solution for site pairing, replicação e outra configuração de recuperação de desastres.

O DNS da Solução VMware do Oracle Cloud é gerenciado pelo Oracle e não permite adicionar mais registros DNS no mesmo domínio em que os registros vCenter e NSX são criados por padrão. Isso também significa que o appliance SRM e vSphere Replication não pode se comunicar com o vCenter, Controlador Platform Service ou NSX do VMware usando FQDN.

Para superar este desafio, recomendamos que você crie um servidor DNS para hospedar a zona com o mesmo nome do domínio padrão do Oracle Cloud VMware Solution. Isso permite criar registros DNS adicionais necessários para implementação de recuperação de desastres usando o SRM e o vSphere Replication. Essa etapa é necessária para ter a resolução de nome DNS para todos os componentes implantados dentro e entre os sites.

Observação:

A implementação completa da recuperação de desastres poderia usar endereços IP, mas recomendamos a implementação do SRM e do vSphere Replication com FQDN.

Usar DNS Personalizado no Ambiente

Antes de começar, certifique-se de que os dois sites estejam conectados na rede e de que possam se comunicar entre si por endereços IP. Para obter pré-requisitos de rede e detalhes de conectividade do site, consulte a seção para cada modelo de implantação posteriormente nesse playbook.

Observação:

Essas etapas são necessárias para todos os clusters do Oracle Cloud VMware Solution que você implantar. Talvez você queira ter ambos os ambientes em execução no Oracle Cloud VMware Solution com SRM e vSphere Replication para implementação de recuperação de acidentes. Este playbook descreve todos os modelos de implantação para recuperação de desastres usando o SRM e o vSphere Replication. Para os modelos de implantação 2 e 3, você deve ter um servidor DNS dedicado para cada implantação da Solução VMware do Oracle Cloud.

Criar um Servidor DNS Local para a Solução Oracle Cloud VMware

Implemente o DNS personalizado para cada implantação da Solução VMware do Oracle Cloud seguindo as etapas abaixo.

Observação:

Este procedimento usa o Modelo de Implantação 1 para ilustração. Você deve seguir o mesmo procedimento para Modelos de Implantação 2 e 3.

Implante uma instância de computação do Windows Server no Oracle Cloud Infrastructure na mesma VCN em que a Solução Oracle Cloud VMware está implantada.
Execute a instalação padrão do Controlador de Domínio de DNS e do Active Directory.
Crie zonas de consulta posteriores e invertidas que usem o mesmo nome do domínio padrão do Oracle Cloud VMware Solution.
Crie entradas de pesquisa posteriores e reversas para o appliance vCenter Server, NSX Manager, SRM e vSphere Replication na zona sddc.xxx.oci.oraclecloud.com (em que xxx é o código da região; por exemplo, lhr). Atualize os registros PTR associados em x.xx.xx.in-addr.arpa (onde x.xx.xx representa o octeto inverso 3 do endereço IP) inverta a zona de pesquisa que pertence à implantação do Oracle Cloud VMware Solution.
Crie uma zona que se refira ao nome de domínio local. É obrigatório para ambos os sites para comunicação usando FQDN.
Crie as entradas de pesquisa posteriores e reversas necessárias na implementação local, como vCenter, Platform Service Controller (se for externo), SRM, vSphere Replication appliance e NSX Manager (se fizer parte da implementação) na zona acme.local. Atualize os registros PTR associados em x.xx.xx.in-addr.arpa (em que x.xx.xx representa o octeto reverso 3 do endereço IP). Esta etapa assegura que a comunicação possa trabalhar da Solução VMware do Oracle Cloud para componentes locais usando FQDN.
Faça log-in no seu servidor DNS local e crie uma zona de pesquisa de encaminhamento e inversa para implantação do Oracle Cloud VMware Solution.
Crie as entradas de pesquisa posteriores e reversas necessárias na implantação da Solução VMware do Oracle Cloud, como vCenter, SRM, appliance de Replicação vSphere e NSX Manager—under sddc.xxx.oci.oraclecloud.com para zonas de pesquisa progressivas e x.xx.xx.in-addr.arpa para zonas de pesquisa inversas.
Use o endereço do servidor DNS do Oracle Cloud VMware Solution ao implantar o appliance SRM and vSphere Replication no Oracle Cloud VMware Solution. Para os modelos de implantação 2 e 3, o ambiente Oracle Cloud VMware Solution de cada site usa um servidor DNS dedicado.
Repita as etapas de implantação e configuração do DNS para os modelos de implantação 2 e 3. Substitua o ambiente on-premises pelo Oracle Cloud VMware Solution onde os sites principal e de recuperação estão implantados no Oracle Cloud VMware Solution.

As etapas anteriores garantem que ambos os sites possam se comunicar um com o outro usando FQDN. Validar usando um teste de ping para ver se os componentes de recuperação de desastres de cada site podem se comunicar um com o outro usando FQDN para todos os modelos de implantação.