19. Inicialização do cluster de administrador raiz

Tempo estimado para a conclusão: 7 horas

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

Perfil de habilidade: engenheiro de implantação

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

19.1. Configurar a configuração de roteamento

Confirme se a rota estática foi adicionada durante a instalação do servidor Bootstrapper. Se a rota estática estiver faltando, adicione uma ao bootstrap:

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}

Essa rota fornece acesso ao servidor da API do cluster de administrador raiz da interface do plano de dados no bootstrapper. Para mais informações sobre servidores de API no GDC, consulte Servidores de API globais e zonais.

19.2. Criar cluster de administrador raiz

O comando a seguir cria um cluster de administrador raiz com três nós do plano de controle. O modo padrão é o multilocatário.

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

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

A criação do cluster de administrador raiz requer um arquivo de configuração para o CR do cluster. A configuração é gerada automaticamente por padrão. Também é possível personalizar a configuração do cluster definindo a flag --generate-admin-yaml como false e especificando --admin-yaml-path para apontar para o caminho da configuração de destino.

Depois que a instalação do cluster de administrador raiz for concluída, o kubeconfig dele será armazenado em /root/release/root-admin/root-admin-kubeconfig.

Observação: o protocolo de Internet versão 6 (IPv6) está disponível para o cluster de administrador raiz por padrão após a conclusão do bootstrapping.

O URL da interface do usuário (UI) do administrador do usuário é impresso após a instalação do cluster. Lembre-se dele para usar em operações posteriores. Também é possível recuperá-lo usando o seguinte comando:

gdcloud system admin-cluster describe

19.3. Implantar componentes no cluster de administrador raiz

O comando a seguir implanta 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. Configurar flags de recursos para administrador raiz

Aviso: siga as instruções nesta seção somente se você definir um limite de estágio de recurso diferente de production.

Se você tiver um limite de estágio de recurso diferente de production, atualize seus flags de recursos de acordo com o limite, seguindo OOPS-P0072.

19.5. Configurar o resolvedor stub no bootstrap

Use o comando a seguir para configurar o resolvedor stub de DNS no bootstrap. Esse resolvedor stub é necessário para acessar o console.

gdcloud system dns install

Essa configuração garante que todos os nomes de domínio das organizações possam ser resolvidos pelo bootstrapper, conforme mostrado no diagrama a seguir:

19.6. Definir endereços IP do iLO

As etapas a seguir definem os endereços IP do ILO como static para nós de administrador.

  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 do cluster. Execute o comando a seguir 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. Redefina o gerenciador do 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. Verifique se as configurações de Ethernet foram aplicadas. Se a resposta estiver travada, a redefinição não foi concluída. Cancele o comando curl atual, aguarde 20 segundos e tente de novo.

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

Confirme o sucesso verificando se o retorno HTTP de cada etapa corresponde ao resultado esperado.

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

19.7. Estabelecer a rede do OI e a conectividade com isolamento físico do Google Distributed Cloud (GDC)

Esta seção descreve como provisionar arquivos de configuração que a infraestrutura da Operations Suite (OI) e as redes do Distributed Cloud usam para estabelecer conectividade.

Essas etapas exigem acesso a alguns arquivos do Distributed Cloud, além de conectividade com o cluster de administrador raiz da instância do Distributed Cloud para que as informações de rede de tempo de execução sejam recuperadas.

Importante: se você não trabalhou com o inicializador do Distributed Cloud, talvez seja necessário receber ajuda de um engenheiro de implantação do Distributed Cloud para ter acesso ao inicializador e garantir o acesso à API Kubernetes do cluster de administrador raiz.

19.7.1. Antes de começar

Nesta etapa do processo de implantação, as seguintes condições precisam ser verdadeiras:

1. Os dois switches OIR estão conectados por cabo, ligados, atualizados para a versão adequada e têm configurações de base e ACL aplicadas.

2. Os dois firewalls OIF estão conectados por cabo, ligados, atualizados para a versão adequada, ativados para o modo FIPS-CC e têm a configuração básica aplicada.

3. Para concluir todo o provisionamento de conectividade do Distributed Cloud, a instância precisa ter concluído o bootstrap de rede e ter saído do cluster kind para o cluster de administrador raiz.

Importante: as etapas que exigem o uso dos arquivos cellcfg ainda precisam ser concluídas, mesmo que a etapa 3 ainda não esteja totalmente concluída, mas o cellcfg esteja disponível. Isso permite que os switches sejam configurados e fiquem prontos para a conectividade do Distributed Cloud. Quando o cluster estiver pronto e totalmente disponível, será necessário realizar mais uma etapa para gerar e aplicar as políticas de segurança do firewall.

19.7.2. Prepare o ambiente

Prepare o ambiente para as próximas etapas coletando as seguintes informações e definindo as variáveis de ambiente.

O OI pode ser conectado de duas maneiras: local ou remota. Uma conexão local conecta o OI ao Distributed Cloud diretamente usando conexões de fibra entre racks no mesmo data center. Uma conexão remota se conecta a um local diferente usando transporte de longa distância. Essa especificação pode ser fornecida no arquivo interconnect.yaml, que é necessário para provisionar configurações de interconexão do Distributed Cloud. Esse arquivo contém todas as informações necessárias para configurar as interconexões do GDC.

19.7.2.1. Especificação YAML da interconexão

Attribute	Descrição	Exemplo
zones [ ] map	Informações sobre a célula do Distributed Cloud a que a implantação do OI precisa se conectar. Para se conectar a uma lista de células do Distributed Cloud, especifique uma lista de zones com informações de cada célula do Distributed Cloud 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 arquivo interconnect.yaml:

Attribute	Descrição	Uso
zoneName string	A abreviação da célula do Distributed Cloud a que a implantação da OI precisa se conectar.	zones: - zoneName: kb
uplinkSpeed uint32	(Opcional) Fornece a velocidade de uplink da conexão: (10 ou 100).	Valores:10, 100 Padrão: 10 uplinkSpeed: 100
localInstance int	O InstanceID do site de implantação do OI no arquivo ocit.yaml. Uma conexão local conecta o site do rack principal da infraestrutura da Suite de operações (OIR) ao Distributed Cloud diretamente usando conexões de fibra entre racks no mesmo data center.	zones: - zoneName: kb localInstanceIDs: 1
remoteInstance [ ] int	InstanceID(s) do site de implantação do OI no arquivo ocit.yaml Uma conexão remota se conecta a um ou mais locais diferentes usando transporte de longa distância. É possível fornecer uma lista de valores remoteInstance para que as configurações de todos os sites do OIR sejam geradas para se conectar a determinadas células do Distributed Cloud.	zones: - zoneName: kb remoteInstanceIDs: - 1 zones: - zoneName: kb remoteInstanceIDs: - 1 - 2 - 3

Se for uma conexão local, configure o arquivo interconnect.yaml da seguinte maneira:

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

Se for uma conexão remota, configure o arquivo interconnect.yaml da seguinte maneira:

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

Para implantações de OI em vários sites, especifique o arquivo interconnect.yaml como:

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

Aviso: conclua estas etapas e use os caminhos completos adequados ou o não será executado corretamente.

19.7.3. Gerar configurações de switch

Essas etapas geram configurações de patch para aplicar aos dispositivos de rede e provisionar a conectividade com o Distributed Cloud.

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

Isso gera os seguintes arquivos de configuração para cada site:

Arquivos de configuração	Dispositivo	Função
occoresw101.incremental	occoresw101	Configuração para corrigir o dispositivo para conectividade com a instância do Distributed Cloud
occoresw101.acl	occoresw101	Configuração para corrigir as ACLs para aplicação de tráfego com as redes do Distributed Cloud.
occoresw102.incremental	occoresw102	Configuração para corrigir o dispositivo para conectividade com a instância do Distributed Cloud
occoresw102.acl	occoresw102	Configuração para corrigir as ACLs para aplicação de tráfego com as redes do Distributed Cloud.
ocsw101.incremental	ocs1w01	Configuração para corrigir o dispositivo para conectividade com a instância do Distributed Cloud
ocsw101.acl	ocsw101	Configuração para corrigir as ACLs para aplicação de tráfego com as redes do Distributed Cloud.
ocsw102.incremental	ocsw102	Configuração para corrigir o dispositivo para conectividade com a instância do Distributed Cloud
ocsw102.acl	ocsw102	Configuração para corrigir as ACLs para aplicação de tráfego com as redes do Distributed Cloud.

Observação: para implantações de infraestrutura (OI) da Operations Suite em vários sites, uma configuração é gerada para cada site mencionado no arquivo interconnect.yaml. Identifique os arquivos gerados para cada site usando o InstanceID. Os arquivos gerados têm um prefixo com o seguinte formato: <segment_type><device_type><InstanceID><device_id>

19.7.4. Gerar políticas de firewall

Para gerar as regras de firewall, o occonfigtool precisa acessar a API Kubernetes do cluster de administrador raiz. Verifique se 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 comando:

occonfigtool generate fwrules -o ${OCIT_CONFIG_FILE:?}

Arquivos de configuração	Dispositivo	Função
firewall-rules.base	occorefw01	Configuração para corrigir o dispositivo para conectividade com a instância do Distributed Cloud

19.7.5. Aplicar configurações

Usando os arquivos de saída, aplique a configuração aos respectivos dispositivos de rede usando o mesmo procedimento da etapa anterior para switches e firewalls.

19.8. Atualizar recursos do Distributed Cloud RoutePolicy

O Distributed Cloud usa a política de roteamento para aplicar quais redes podem ser divulgadas na tabela de roteamento.

Ao adicionar o OI como uma rede externa, precisamos atualizar os CRs RoutePolicy para esperar as novas redes.

Isso requer o acesso ao root-admin-cluster usando kubectl. Verifique se a variável KUBECONFIG apropriada está definida:

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

Para confirmar, faça o seguinte:

kubectl get routepolicy -n gpc-system

A seguinte saída, ou algo parecido, vai aparecer:

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

Nestas etapas, vamos nos concentrar em networkoperationcenter-routepolicy e mgmtnetworkoperationcenter-routepolicy.

19.8.1.1. Adicionar patch às políticas de rotas de rede de dados

Na ocinfo.opscenter.local.txt, recupere as seguintes sub-redes (incluindo a rede e o tamanho do prefixo).

Observação: para implantação de OI em vários sites, repita esta etapa para todos os sites. Use as sub-redes do arquivo ocinfo.opscenter.local.txt dos sites listados.

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

Use esses valores para ajustar as políticas de roteamento preenchendo as seguintes variáveis:

export OCCORE_SERVERS_NET=$OCCORE_SERVERS_NET
export OC_WORKSTATIONS_NET=$OC_WORKSTATIONS_NET

Exemplo:

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

Depois que as variáveis de ambiente forem definidas, 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 rota de rede de gerenciamento de patches

Na ocinfo.opscenter.local.txt, recupere as seguintes sub-redes (incluindo a rede e o tamanho do prefixo).

Observação: para implantações de OI em vários sites, repita esta etapa para todos os sites. Use as sub-redes dos arquivos ocinfo.opscenter.local.txt da lista de sites.

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

Use esses valores para ajustar as políticas de roteamento preenchendo as seguintes variáveis:

export OCCORE_JUMPHOSTS_NET=$OCCORE_JUMPHOSTS_NET
export OCCORE_ILOS_NET=$OCCORE_ILOS_NET

Exemplo:

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

Depois que as variáveis de ambiente forem definidas, 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. Validar a conectividade de rede do OI Distributed Cloud

Importante: conclua as etapas de validação em Estabelecer a rede OI e a conectividade do Distributed Cloud antes de validar as conexões do Distributed Cloud. Se as configurações de incremental realizadas na etapa anterior já tiverem sido aplicadas, as validações nessa etapa podem não corresponder exatamente.

Neste ponto da implantação, as seguintes condições precisam ser verdadeiras:

• occoresw101 e occoresw102 são configurados com os arquivos de configuração base, acl, incremental e incremental-acl.
• ocsw101 e ocsw102 são configurados com arquivos de configuração base, acl, incremental e incremental-acl.
• occorefw101 e occoref102 são configurados com arquivos de configuração base e firewall-rules.base.
• Os uplinks entre o data center e o centro de operações estão conectados e operacionais.
• Os uplinks físicos entre o Distributed Cloud são verificados.

Observação: para implantações de infraestrutura (OI) da Operations Suite em vários sites, os arquivos de configuração são gerados e aplicados a cada site.

Se alguma das condições anteriores não for verdadeira, a saída a seguir poderá ser muito diferente, dependendo do estado atual, e provavelmente não vai produzir o comportamento esperado em produção.

19.9.1. Resposta esperada

Os snippets a seguir mostram a saída de um ambiente bom conhecido dos seguintes comandos:

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

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

Esses snippets podem servir como uma comparação com um ambiente de produção usando os mesmos comandos.

19.9.2. Validações de chaves

Confira a seguir os principais elementos a serem procurados nas saídas:

• Nenhuma sessão do BGP está no estado Idle, Active ou Closing.
• Todas as sessões do BGP mostram um valor State/PrxRcd maior que 0.
• Todas as sessões do BGP mostram um timer Up/Down que aumenta continuamente.
• O prefixo externalCIDR do Distributed Cloud (encontrado no CIQ) está presente nas tabelas de roteamento e BGP das VRFs GDCH-DATA, GDCH-DATA-TRANSIT, OC-WORKSTATIONS e OCCORE-SERVERS.
• O oobManagementCIDRs do Distributed Cloud (encontrado no CIQ) está presente nas tabelas de roteamento e BGP das VRFs GDCH-MGMT, GDCH-MGMT-TRANSIT e HW-INFRA.

19.9.3. OCCORESW

A tabela a seguir mostra a saída esperada em cada occore switch para as interconexões do Distributed Cloud. É necessário concluir todas as validações de rede antes desta etapa. Os vizinhos e as rotas do BGP discutidos aqui precisam estar presentes junto com os vizinhos e as rotas do BGP mencionados anteriormente. Valide a saída em todas as chaves.

VRF	Vizinho do BGP	Rotas esperadas recebidas do vizinho do BGP	Rotas esperadas anunciadas para o vizinho do BGP
GDCH-DATA-TRANSIT	AGGSW01	Endereço de resumo agregado com sub-rede /19 para célula do Distributed Cloud	Prefixo OCCORE-SERVERS Prefixo OC-WORKSTATION
GDCH-DATA-TRANSIT	AGGSW02	Endereço de resumo agregado com sub-rede /19 para célula do Distributed Cloud	Prefixo OCCORE-SERVERS Prefixo OC-WORKSTATION
GDCH-DATA-TRANSIT	Sessão do BGP com hairpin usando OCCOREFW para OC-DATA VRF	Endereço de resumo agregado (com sub-rede /19) para célula do Distributed Cloud
OC-DATA	Sessão do BGP OCSW01	Endereço de resumo agregado (com sub-rede /19) para célula do Distributed Cloud
OC-DATA	Sessão do BGP OCSW02	Endereço de resumo agregado (com sub-rede /19) para célula do Distributed Cloud
OC-DATA	Sessão do BGP OCCORESW	Endereço de resumo agregado (com sub-rede /19) para célula do Distributed Cloud
GDCH-MGMT-TRANSIT	MGMTAGGSW01	Agrega endereços de resumo (com sub-rede /24) de toda a rede de gerenciamento fora de banda do GDCH.	Prefixo OCCORE-JUMPHOSTS Prefixo OCCORE-ILOS
GDCH-MGMT-TRANSIT	MGMTAGGSW02	Agrega endereços de resumo (com sub-rede /24) de toda a rede de gerenciamento OOB do Distributed Cloud	Prefixo OCCORE-JUMPHOSTS Prefixo OCCORE-ILOS
GDCH-MGMT-TRANSIT	Sessão do BGP com hairpin usando OCCOREFW para VRF HW-INFRA	Agrega endereços de resumo (com sub-rede /24) de toda a rede de gerenciamento OOB do Distributed Cloud

19.9.4. OCSW

A tabela a seguir mostra a saída esperada em cada oc switch após a execução do procedimento de interconexão do Distributed Cloud. É necessário concluir todas as validações de rede antes desta etapa. Os vizinhos e as rotas do BGP discutidos aqui precisam estar presentes junto com os vizinhos e as rotas do BGP mencionados anteriormente. Valide a saída em todas as chaves.

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

O snippet de comando de saída pode ser encontrado em Comando Distributed Cloud validations show.

Observação: a seção a seguir aborda a validação em implantações em vários sites. Você pode ignorar esta seção se sua implantação não for em vários sites.

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

A seção a seguir detalha como validar implantações multissite com várias células do Distributed Cloud interconectadas. Nesta etapa, a topologia com dois sites fica assim:

• As conexões azuis mostram o site 1 conectado às células 01 e 02 do Distributed Cloud.
• As conexões vermelhas mostram o site 2 conectado às células 01 e 02 do Distributed Cloud.
• As conexões verdes mostram a interconexão do site 1 e do site 2.

Para todos os sites em todas as chaves, conclua as etapas listadas nestas seções:

1. Validações de rede.
2. Validações multissite de rede.
3. Validações de nuvem distribuída de rede.

19.10. Realizar as etapas finais da rede de OI

Nesta etapa, todas as configurações precisam ter sido geradas e aplicadas a todos os dispositivos.

As listas de acesso à rede estão em um estado que permite fluxos específicos esperados, mas também tem uma regra padrão que permite todo o tráfego.

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

Depois que as operações aceitam a implantação, é tarefa delas trabalhar nas ACLs e proteger totalmente os fluxos de tráfego de rede.

Os runbooks operacionais são fornecidos para realizar essas tarefas.

19.11. Fazer upgrade do armazenamento de objetos

Durante o bootstrap do armazenamento de objetos, os nós foram instalados com a versão secundária mais recente compatível do StorageGRID. No entanto, talvez seja necessário atualizar a versão de destino para a versão mais recente do patch de hotfix.

Determine a versão de destino do StorageGRID nos metadados da versão com o comando a seguir:

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

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

19.12. Possíveis problemas

Importante: esses problemas podem ocorrer ao instalar a versão 1.9.x do Distributed Cloud.

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

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

Problema: depois de criar o cluster de administrador raiz, o recurso de máquina virtual de armazenamento não é reconciliado e mostra 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 esse problema.

Alternativa:

Conecte-se ao serial ou ao cluster de armazenamento usando SSH e execute:

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

Depois de se conectar, o recurso de máquina virtual de armazenamento poderá fazer a conciliação.

19.12.2. Falha na inicialização na instalação do certificado do servidor TLS do firewall

Você pode encontrar uma falha de TLSServerCertification ao realizar a tarefa de inicialização do plano de controle de administrador raiz descrita na etapa 20.

Alternativa:

Para tentar instalar novamente o certificado do servidor de firewall, consulte as instruções listadas no manual de serviço de E/S FW-R1008. Depois de concluir uma instalação bem-sucedida, use o comando gdcloud com o comando --start-phase para continuar a inicialização do administrador raiz.