19. Inicialização do cluster de administrador raiz

Tempo estimado até à conclusão: 7 horas

Proprietário do componente acionável: KUB/SERV/OBJ/FILE/PNET

Perfil de competências: engenheiro de implementação

Este guia cria um cluster de administrador raiz que serve como plano de controlo para o cluster interno e os clusters de infraestrutura da organização.

19.1. Configure a configuração de encaminhamento

Confirme se a rota estática foi adicionada durante a instalação do servidor Bootstrapper. Se a rota estática estiver em falta, adicione uma rota estática ao programa de arranque:

DATA_CIDR=$(kubectl get cidrclaim -n gpc-system instance-external-cidr -o jsonpath={.spec.ipv4Spec.staticCidrBlocks[0]})
DATA_GATEWAY=$(kubectl get subnetclaims -n root control-plane-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway})
ip route replace ${DATA_CIDR} via ${DATA_GATEWAY}

Esta rota fornece acesso ao servidor da API do cluster de administrador raiz a partir da interface do plano de dados no programa de arranque. Para mais informações sobre os servidores da API no GDC, consulte o artigo Servidores da API globais e zonais.

19.2. Crie um cluster de administrador raiz

O comando seguinte cria um cluster de administrador raiz com três nós do plano de controlo. O modo de inquilino predefinido é o modo multi-inquilino.

gdcloud system admin-cluster install -v=3 \
  --tenant-mode=multi \
  --root-admin-node-count=3 \
  --generate-admin-yaml \
  --addon-manager-manifests-set harbor.postgresqlHA.enabled=true \
  --addon-manager-manifests-set harbor.productionEnvironment.enabled=true \
  --addon-manager-manifests-set storage.mode=ontap \
  --addon-manager-manifests-set gpuFeature.enabled=true \
  --addon-manager-manifests-set rootAdmin.controller.adminLBPoolSize=23 \
  --addon-manager-manifests-set rootAdmin.controller.systemLBPoolSize=60 \
  --addon-manager-manifests-set network.noInternalSubnet=false \
  --addon-manager-manifests-set minStage=FEATURE_THRESHOLD

Nota: o parâmetro --addon-manager-manifests-set minStage=FEATURE_THRESHOLD não é necessário se o limite de funcionalidades for production. O valor de FEATURE_THRESHOLD tem de ser o mesmo que foi definido para a implementação geral.

A criação do cluster de administrador raiz requer um ficheiro de configuração para o CR do cluster. Por predefinição, a configuração é gerada automaticamente. A configuração de clusters personalizada também é permitida definindo a flag --generate-admin-yaml como false e especificando --admin-yaml-path para apontar para o caminho de configuração de destino.

Após a conclusão da instalação do cluster de administrador raiz, o kubeconfig do cluster de administrador raiz é armazenado em /root/release/root-admin/root-admin-kubeconfig.

Nota: a versão 6 do Protocolo de Internet (IPv6) está disponível para o cluster de administrador raiz por predefinição após a conclusão do arranque.

O URL da interface do utilizador (IU) do administrador do utilizador é impresso após a instalação do cluster. Lembre-se de o usar em operações posteriores. Também pode obtê-lo através do seguinte comando:

gdcloud system admin-cluster describe

19.3. Implemente componentes no cluster de administrador raiz

O comando seguinte implementa modelos de ciclo de vida de componentes operáveis no cluster de administrador raiz.

gdcloud system component deploy --kubeconfig KUBECONFIG --names=* --pivot-from=/root/.kube/config

19.4. Configure gates de funcionalidades para o administrador principal

Aviso: siga as instruções nesta secção apenas se tiver definido um limite de fase da funcionalidade diferente de production.

Se tiver um limite de fase de funcionalidade diferente de production, tem de atualizar os seus Feature Gates em conformidade para corresponder ao limite, seguindo OOPS-P0072.

19.5. Configure o resolvedor de stub no bootstrapper

Use o seguinte comando para configurar o resolvedor stub de DNS no bootstrapper. Este resolvedor de stub é necessário para aceder à consola.

gdcloud system dns install

Esta configuração garante que os nomes de domínio de todas as organizações são resolvidos a partir do bootstrapper, conforme mostrado no diagrama seguinte:

19.6. Defina endereços IP iLo

Os passos seguintes definem os endereços IP da ILO para static para nós de administração.

  ADMIN_NODE=NODE NAME
  RACK=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.metadata.labels.system\.private\.gdc\.goog/rack-name}')
  ILO_IP=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.ip}')
  ILO_GATEWAY=$(kubectl --kubeconfig KUBECONFIG get subnetclaims -n root $RACK-mgmtsw01-server-bmc-subnet -o jsonpath='{.status.ipv4SubnetStatus.gateway}')
  BMC_CREDS=$(kubectl --kubeconfig KUBECONFIG get servers -n gpc-system $ADMIN_NODE -o jsonpath='{.spec.bmc.credentialsRef.name}')
  ILO_USER=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.username}' | base64 --decode)
  ILO_PASS=$(kubectl --kubeconfig KUBECONFIG get secrets -n gpc-system $BMC_CREDS -o jsonpath='{.data.password}' | base64 --decode)

  echo Target Server: $ADMIN_NODE
  echo ILO IP: $ILO_IP
  echo ILO Gateway: $ILO_GATEWAY
  echo ILO Username: $ILO_USER
  echo ILO Password: $ILO_PASS

Verifique se as informações anteriores estão corretas com base nas informações no cluster. Execute o comando seguinte se as informações anteriores estiverem corretas.

1. Desative o DHCP.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"DHCPv4": {"DHCPEnabled": false}}' | jq '.'
   

   Resultado esperado:

   MessageId: iLO.2.15.ResetRequired

2. Configure o endereço IP e o gateway.

   curl -k -u ${ILO_USER}:${ILO_PASS} -H "Content-Type: application/json" -H "OData-Version: 4.0" -X PATCH https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 --data '{"IPv4Addresses":[{"Address":"'${ILO_IP}'","Gateway":"'${ILO_GATEWAY}'","SubnetMask":"255.255.255.0"}],"IPv4StaticAddresses": [{"Address": "'${ILO_IP}'", "Gateway": "'${ILO_GATEWAY}'", "SubnetMask": "255.255.255.0"}]}' | jq .
   

   Resultado esperado:

   MessageId: Base.1.4.Success

3. Reponha o gestor iLO.

   curl -k -u ${ILO_USER}:${ILO_PASS}  -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq .
   

   Resultado esperado:

   MessageId: iLO.2.15.ResetInProgress

4. Confirme se as definições de Ethernet foram aplicadas. Se a resposta estiver pendente, significa que a reposição não foi concluída. Cancele o comando curl atual, aguarde 20 segundos e tente novamente.

   curl --insecure -u ${ILO_USER}:${ILO_PASS} https://${ILO_IP}/redfish/v1/Managers/1/EthernetInterfaces/1 -X GET | jq .
   

Confirme o êxito verificando se o retorno HTTP de cada passo corresponde ao resultado esperado.

Repita os passos anteriores para todos os nós de administrador raiz presentes no cluster.

19.7. Estabeleça a rede OI e a conetividade isolada do Google Distributed Cloud (GDC)

Esta secção descreve como aprovisionar ficheiros de configuração que as redes de infraestrutura (OI) e nuvem distribuída do Operations Suite para estabelecerem a conetividade.

Estes passos requerem acesso a alguns ficheiros do Distributed Cloud, bem como conectividade ao cluster de administrador principal da instância do Distributed Cloud para que as informações de rede de tempo de execução sejam obtidas.

Importante: se não tiver trabalhado com o programa de arranque do Distributed Cloud, pode precisar da ajuda de um engenheiro de implementação do Distributed Cloud para aceder ao programa de arranque e garantir o acesso à API Kubernetes do cluster de administrador raiz.

19.7.1. Antes de começar

Nesta fase do processo de implementação, têm de se observar as seguintes condições:

1. Ambos os comutadores OIR estão ligados por cabo, ligados, atualizados para a versão adequada e têm as configurações de base e ACL aplicadas.

2. Ambas as firewalls OIF estão ligadas por cabo, ligadas à fonte de alimentação, atualizadas para a versão adequada, ativadas para o modo FIPS-CC e têm a configuração base aplicada.

3. Para concluir o aprovisionamento da conetividade da nuvem distribuída, a instância da nuvem distribuída tem de ter concluído o arranque da rede e ter sido movida do cluster do tipo para o cluster de administrador raiz.

Importante: os passos que requerem a utilização dos ficheiros cellcfg têm de ser concluídos mesmo que o passo 3 ainda não esteja totalmente concluído, mas o ficheiro cellcfg esteja disponível. Isto permite que os comutadores sejam configurados e estejam prontos para a conetividade da nuvem distribuída. Assim que o cluster estiver em funcionamento e totalmente pronto, é necessário um passo adicional para gerar e aplicar as políticas de segurança da firewall.

19.7.2. Prepare o ambiente

Prepare o ambiente para os passos seguintes reunindo as seguintes informações e definindo as variáveis de ambiente.

A OI pode ser ligada de duas formas: localmente ou remotamente. Uma ligação local liga o OI à Distributed Cloud diretamente através de ligações de fibra entre racks no mesmo centro de dados. Uma ligação remota liga-se a uma localização diferente através de transporte de longa distância. Esta especificação pode ser fornecida no ficheiro interconnect.yaml, que é necessário para aprovisionar configurações de interligação do Distributed Cloud. Este ficheiro contém todas as informações necessárias para configurar as interconexões do GDC.

19.7.2.1. Especificação YAML da interligação

Atributo	Descrição	Exemplo
zones [ ] mapa	Informações sobre a célula da nuvem distribuída à qual a implementação do OI tem de se ligar. Para estabelecer ligação a uma lista de células da nuvem distribuída, especifique uma lista de zones com informações de cada célula da nuvem distribuída em cada zona. Opções de zona	Exemplo: zones: - zoneName: kb - uplinkSpeed: 10 localInstanceIDs: 2 remoteInstanceIDs: - 1 - cellCfg: path/to/cellcfg - zoneName: ah - uplinkSpeed: 100 localInstanceIDs: 3 - cellCfg: path/to/cellcfg

19.7.2.2. Opções de zona

Contém informações sobre uma célula do Distributed Cloud no ficheiro interconnect.yaml:

Atributo	Descrição	Utilização
zoneName string	Abreviatura da célula da nuvem distribuída à qual a implementação da OI tem de se ligar.	zones: - zoneName: kb
uplinkSpeed uint32	(Opcional) Indica a velocidade de carregamento da ligação: (10 ou 100).	Valores:10, 100 Predefinição: 10 uplinkSpeed: 100
localInstance int	O InstanceID do site de implementação da OI a partir do ficheiro ocit.yaml. Uma ligação local associa o site do rack principal da infraestrutura do Operations Suite (OIR) ao Distributed Cloud diretamente através de ligações de fibra entre racks no mesmo centro de dados.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) do site de implementação da OI a partir do ficheiro ocit.yaml Uma ligação remota liga-se a uma ou mais localizações diferentes através de transporte de longa distância. Pode ser fornecida uma lista de valores remoteInstance, de modo que as configurações de todos os sites de OIR sejam geradas para estabelecer ligação às células do Distributed Cloud fornecidas.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

Se for uma ligação local, configure o ficheiro interconnect.yaml da seguinte forma:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    cellCfg: /path/to/cellcfg

Se for uma ligação remota, configure o ficheiro interconnect.yaml da seguinte forma:

zones:
  - zoneName: ah
    uplinkSpeed: 100
      remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Para implementações de OI em vários sites, especifique o ficheiro interconnect.yaml da seguinte forma:

zones:
  - zoneName: ah
    uplinkSpeed: 100
    localInstanceID: 1
    remoteInstanceIDs:
      - 2
    cellCfg: /path/to/cellcfg

Aviso: conclua estes passos e use os caminhos adequados completos ou o comando não será executado com êxito.

19.7.3. Gere configurações de comutador

Estes passos geram configurações de patch a aplicar aos dispositivos de rede para aprovisionar a conetividade ao Distributed Cloud.

occonfigtool generate cell config -c /path/to/interconnect.yaml -o path/to/ocit.yaml

Isto gera os seguintes ficheiros de configuração para cada site:

Ficheiros de configuração	Dispositivo	Função
occoresw101.incremental	occoresw101	Configuração para aplicar patches ao dispositivo para a conetividade à instância do Distributed Cloud
occoresw101.acl	occoresw101	Configuração para aplicar patches às ACLs para a aplicação do tráfego com as redes da nuvem distribuída.
occoresw102.incremental	occoresw102	Configuração para aplicar patches ao dispositivo para a conetividade à instância do Distributed Cloud
occoresw102.acl	occoresw102	Configuração para aplicar patches às ACLs para a aplicação do tráfego com as redes da nuvem distribuída.
ocsw101.incremental	ocs1w01	Configuração para aplicar patches ao dispositivo para a conetividade à instância do Distributed Cloud
ocsw101.acl	ocsw101	Configuração para aplicar patches às ACLs para a aplicação do tráfego com as redes da nuvem distribuída.
ocsw102.incremental	ocsw102	Configuração para aplicar patches ao dispositivo para a conetividade à instância do Distributed Cloud
ocsw102.acl	ocsw102	Configuração para aplicar patches às ACLs para a aplicação do tráfego com as redes da nuvem distribuída.

Nota: para implementações de infraestrutura (OI) do Operations Suite em vários sites, é gerada uma configuração para cada site mencionado no ficheiro interconnect.yaml. Identifique os ficheiros gerados para cada site através do InstanceID. Os ficheiros gerados têm um prefixo com o seguinte formato: <segment_type><device_type><InstanceID><device_id>

19.7.4. Gere políticas de firewall

Para gerar as regras da firewall, o occonfigtool tem de aceder à API Kubernetes para o cluster de administrador principal. Certifique-se de que a variável de ambiente KUBECONFIG está definida como root-admin-kubeconfig:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
export OCIT_CONFIG_FILE=/path/to/ocit.yaml

Gere as regras de firewall executando o seguinte:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Ficheiros de configuração	Dispositivo	Função
firewall-rules.base	occorefw01	Configuração para aplicar patches ao dispositivo para a conetividade à instância do Distributed Cloud

19.7.5. Aplique configurações

Usando os ficheiros de saída, aplique a configuração aos dispositivos de rede respetivos através do mesmo procedimento que no passo anterior para comutadores e firewalls.

19.8. Atualize os recursos do Distributed Cloud RoutePolicy

A nuvem distribuída usa a política de rotas para aplicar as redes que podem ser anunciadas na tabela de encaminhamento.

Quando adicionamos a OI como uma rede externa, temos de atualizar os RoutePolicyCRs para que esperem as novas redes.

Isto requer o acesso ao root-admin-cluster através do kubectl. Certifique-se de que a variável KUBECONFIGadequada está definida:

export KUBECONFIG=/root/deploy/root-admin/root-admin-kubeconfig

Para confirmar, faça o seguinte:

kubectl get routepolicy -n gpc-system

Deve ver o seguinte resultado ou semelhante:

NAME                                     AGE
customerpeering-routepolicy              19d
datacenter-routepolicy                   19d
mgmtnetworkoperationcenter-routepolicy   19d
networkoperationcenter-routepolicy       19d

Para estes passos, vamos concentrar-nos no networkoperationcenter-routepolicy e no mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Aplique patches às políticas de encaminhamento da rede de dados

A partir de ocinfo.opscenter.local.txt, obtenha as seguintes sub-redes (incluindo o prefixo de rede e o comprimento).

Nota: para a implementação de OI em vários locais, repita este passo para todos os locais. Use as sub-redes do ficheiro ocinfo.opscenter.local.txt dos sites indicados.

• OCCORE-SERVERS, usado no exemplo seguinte como $OCCORE_SERVERS_NET
• OC-WORKSTATIONS, usado no exemplo seguinte como $OC_WORKSTATIONS_NET

Use estes valores para ajustar as políticas de rotas preenchendo as seguintes variáveis:

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Por exemplo:

export OCCORE_SERVERS_NET=172.21.0.0/24
export OC_WORKSTATIONS_NET=172.21.32.0/24

Depois de definir as variáveis de ambiente, execute os seguintes comandos kubectl:

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_SERVERS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/networkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OC_WORKSTATIONS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Exemplo de saída:

routepolicy.system.private.gdc.goog/networkoperationcenter-routepolicy patched

19.8.1.2. Políticas de encaminhamento de rede de gestão de patches

A partir de ocinfo.opscenter.local.txt, obtenha as seguintes sub-redes (incluindo o prefixo de rede e o comprimento).

Nota: para implementações de OI em vários locais, repita este passo para todos os locais. Use as sub-redes dos ficheiros ocinfo.opscenter.local.txt da lista de sites.

• OCCORE-JUMPHOSTS, usado no exemplo seguinte como $OCCORE_JUMPHOSTS_NET
• OCCORE-ILOS, usado no exemplo seguinte como $OCCORE_ILOS_NET

Use estes valores para ajustar as políticas de rotas preenchendo as seguintes variáveis:

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Por exemplo:

export OCCORE_JUMPHOSTS_NET=172.21.2.0/27
export OCCORE_ILOS_NET=172.21.2.32/27

Depois de definir as variáveis de ambiente, execute os seguintes comandos kubectl:

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_JUMPHOSTS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

kubectl patch routepolicy/mgmtnetworkoperationcenter-routepolicy -n gpc-system \
  --type=json -p="[
    {
        'op': 'add',
        'path': '/spec/in/ipPrefixList/0',
        'value': {
            'action': 'Permit',
            'ipPrefix': '${OCCORE_ILOS_NET:?}',
            'prefixLengthMatchers': [
                {
                    'operator': 'LE',
                    'prefixLength': 32
                }
            ]
        }
    }
]"

Exemplo de saída:

routepolicy.system.private.gdc.goog/mgmtnetworkoperationcenter-routepolicy patched

19.9. Valide a conetividade de rede do OI Distributed Cloud

Importante: conclua os passos de validação em Estabeleça a ligação de rede da OI e da Distributed Cloud) antes de validar as ligações da Distributed Cloud. Tenha em atenção que, se as configurações incrementalefetuadas no passo anterior já tiverem sido aplicadas, as validações nesse passo podem não corresponder exatamente.

Neste ponto da implementação, o seguinte tem de ser verdadeiro:

• Ambos os dispositivos occoresw101 e occoresw102 são reconfigurados com os ficheiros de configuração base, acl, incremental e incremental-acl.
• O ocsw101 e o ocsw102 estão configurados com ficheiros de configuração base, acl, incremental e incremental-acl.
• Ambos os dispositivos occorefw101 e occoref102 estão configurados com ficheiros de configuração base e firewall-rules.base.
• As ligações de carregamento entre o centro de dados e o centro de operações estão ligadas e operacionais.
• As ligações físicas entre a nuvem distribuída são validadas.

Nota: para implementações de infraestrutura (OI) do Operations Suite em vários sites, os ficheiros de configuração são gerados e aplicados a cada site.

Se alguma das condições anteriores não se observar, a saída seguinte pode diferir substancialmente consoante o estado atual e é provável que não produza o comportamento esperado na produção.

19.9.1. Resultado esperado

Os seguintes fragmentos mostram o resultado de um ambiente conhecido como bom dos seguintes comandos:

• show ip bgp summary vrf all
• show ip bgp vrf all
• show ip route vrf all
• show lldp neighbors

Nota: anexe | no-more ao final de cada comando para evitar a paginação, por exemplo, show ip bgp vrf all | no-more.

Estes fragmentos podem funcionar como uma comparação com um ambiente de produção através dos mesmos comandos.

19.9.2. Validações de chaves

Seguem-se os principais aspetos a procurar nas seguintes saídas:

• Nenhuma sessão de BGP está no estado Idle, Active ou Closing.
• Todas as sessões BGP mostram um valor State/PrxRcd superior a 0.
• Todas as sessões de BGP mostram um temporizador Up/Down que aumenta continuamente.
• O prefixo externalCIDR da nuvem distribuída (encontrado no CIQ) está presente nas tabelas de encaminhamento e nas tabelas BGP das VRFs GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS e OCCORE-SERVERS.
• A nuvem distribuída oobManagementCIDRs (encontrada no CIQ) está presente nas tabelas de encaminhamento e nas tabelas BGP das VRFs GDCH-MGMT, GDCH-MGMT-TRANSIT e HW-INFRA.

19.9.3. OCCORESW

A tabela seguinte mostra o resultado esperado em cada occore switch para as interligações da nuvem distribuída. Tem de concluir todas as validações de rede antes deste passo. Os pares e os trajetos BGP abordados aqui devem estar presentes juntamente com os pares e os trajetos BGP mencionados anteriormente. Valide a saída em todos os comutadores.

VRF	BGP Neighbor	Rotas esperadas recebidas do vizinho BGP	Rotas esperadas anunciadas ao vizinho BGP
GDCH-DATA-TRANSIT	AGGSW01	Endereço de resumo agregado com sub-rede /19 para célula Distributed Cloud	Prefixo OCCORE-SERVERS Prefixo OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Endereço de resumo agregado com sub-rede /19 para célula Distributed Cloud	Prefixo OCCORE-SERVERS Prefixo OC-WORKSTATION
GDCH-DATA-TRANSIT	Sessão de BGP com hairpinning a usar OCCOREFW para OC-DATA VRF	Endereço de resumo agregado (com sub-rede /19) para a célula Distributed Cloud
OC-DATA	Sessão de BGP OCSW01	Endereço de resumo agregado (com sub-rede /19) para a célula Distributed Cloud
OC-DATA	Sessão de BGP OCSW02	Endereço de resumo agregado (com sub-rede /19) para a célula Distributed Cloud
OC-DATA	Sessão de BGP OCCORESW	Endereço de resumo agregado (com sub-rede /19) para a célula Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Endereços de resumo agregados (com sub-rede /24) de toda a rede de gestão OOB do GDCH	Prefixo OCCORE-JUMPHOSTS Prefixo OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Agregue endereços de resumo (com sub-rede /24) de toda a rede de gestão OOB da Distributed Cloud	Prefixo OCCORE-JUMPHOSTS Prefixo OCCORE-ILOS
GDCH-MGMT-TRANSIT	Sessão de BGP com hairpinning a usar OCCOREFW para HW-INFRA VRF	Agregue endereços de resumo (com sub-rede /24) de toda a rede de gestão OOB da Distributed Cloud

19.9.4. OCSW

A tabela seguinte mostra o resultado esperado em cada oc switch após a execução do procedimento de interconexão da nuvem distribuída. Tem de concluir todas as validações de rede antes deste passo. Os pares e os trajetos BGP abordados aqui devem estar presentes juntamente com os pares e os trajetos BGP mencionados anteriormente. Valide a saída em todos os comutadores.

VRF	BGP Neighbor	Rotas esperadas recebidas do vizinho BGP
OC-DATA	Sessão de BGP OCCORESW01	Endereço de resumo agregado (com sub-rede /19) para a célula do GDCH
OC-DATA	Sessão de BGP OCCORESW02	Endereço de resumo agregado (com sub-rede /19) para a célula do GDCH

Pode encontrar o fragmento do comando de saída em Distributed Cloud validations show command.

Nota: a secção seguinte aborda a validação em implementações em vários sites. Pode ignorar esta secção com segurança se a sua implementação não for multisite.

19.9.5. Validações de implementação de OI em vários sites

A secção seguinte detalha como validar implementações em vários sites com várias células da Distributed Cloud interligadas. Nesta fase, a topologia com dois sites tem o seguinte aspeto:

• As ligações azuis mostram o site 1 ligado à célula 01 e à célula 02 da nuvem distribuída.
• As ligações vermelhas mostram o site 2 ligado à célula 01 e à célula 02 da nuvem distribuída.
• As ligações verdes mostram a interligação entre o site 1 e o site 2.

Para todos os sites em todos os comutadores, tem de concluir os passos indicados nestas secções

1. Validações de rede.
2. Validações em vários sites da rede.
3. Validações do Distributed Cloud de rede.

19.10. Execute os passos finais da rede OI

Nesta fase, todas as configurações têm de ter sido geradas e aplicadas a todos os dispositivos.

As listas de acesso à rede encontram-se agora num estado que permite fluxos específicos esperados, mas também têm uma regra predefinida que permite todo o tráfego.

Agora, tem de transferir a implementação para as operações. A Operational Suite varia em função, implementação e serviços fornecidos entre os clientes. Como resultado, tem requisitos de tráfego variáveis.

Depois de as operações aceitarem a implementação, é da sua responsabilidade trabalhar com as ACLs e proteger totalmente os fluxos de tráfego de rede.

São fornecidos manuais de procedimentos operacionais para realizar estas tarefas.

19.11. Atualize o armazenamento de objetos

Durante o arranque do armazenamento de objetos, os nós foram instalados com a versão secundária suportada mais recente do StorageGRID. No entanto, a versão de destino pode ter de ser atualizada para a versão mais recente da correção rápida.

Determine a versão de destino do StorageGRID a partir dos metadados de lançamento com o seguinte comando:

kubectl get releasemetadata -o jsonpath='{.items[0].spec.infraComponents.objectStorage.storageGridOSImageVersion}'

Se a versão atual do StorageGRID não for a versão de destino, faça uma atualização do armazenamento de objetos com a versão de destino.

19.12. Potenciais problemas

Importante: pode ter estes problemas ao instalar a versão 1.9.x da nuvem distribuída.

19.12.1. A máquina virtual de armazenamento não está a ser reconciliada

TLDR: a máquina virtual de armazenamento não fica pronta durante a criação do cluster de administrador principal.

Problema: após criar o cluster de administrador raiz, o recurso da máquina virtual de armazenamento não é reconciliado e apresenta um evento de aviso, como:

StorageVirtualMachine Reconcile error, retrying: SVM status update failed,
error: failed to get network interface info: Get
"https://172.22.147.128/api/network/ip/interfaces?fields=%2A%2A&max_records=4096&svm.name=root-admin":
EOF

Uma configuração incorreta no cluster de armazenamento que impede o SSL por motivos de segurança pode causar este problema.

Solução alternativa:

Ligue-se à série ou ligue-se ao cluster de armazenamento através de SSH e execute:

security ssl modify -server-enabled true -client-enabled true -vserver
CELL_ID-stge-clus-01

Após a associação, o recurso da máquina virtual de armazenamento consegue fazer a conciliação.

19.12.2. O arranque falhou na instalação do certificado do servidor TLS da firewall

Pode ocorrer uma falha TLSServerCertification ao executar a tarefa de arranque do plano de controlo do administrador principal descrita no passo 20.

Solução alternativa:

Para tentar novamente a instalação do certificado do servidor da firewall, consulte as instruções indicadas no manual de serviço de E/S FW-R1008. Depois de concluir uma instalação com êxito, use o comando gdcloud com o comando --start-phase para continuar o arranque do administrador principal.