15. Inicialização do armazenamento de objetos

Tempo estimado até à conclusão: 7 horas

Proprietário do componente acionável: OBJ

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

Nota: nem todas as configurações do Google Distributed Cloud (GDC) air-gapped incluem um sistema StorageGRID. Uma instância da nuvem distribuída com o StorageGRID tem um rack que contém dispositivos do StorageGRID com números de modelo que começam por SG. Os dispositivos AFF ONTAP não estão abrangidos nesta secção.

15.1. Requisitos de rede

Consulte a imagem seguinte para ver um diagrama de cablagem do SG1000 e do SG6060 para configurar as redes GRID, Admin e Client:

15.1.1. Admin Node SG1000

Tem de ter, pelo menos, dois nós de administrador no SG1000.

Para cada nó de administrador, tem de ter um total de quatro endereços IP, um endereço em cada um dos seguintes:

• BMC Network.
• Rede de administração.
• Rede de cliente.
• Rede de grelha.

Tem de ter três sub-redes para o seguinte:

• Rede de administração.
• BMC Network.

A rede de cliente e a rede de grelha, bem como cada sub-rede, têm de ter uma máscara de sub-rede de, no máximo, 30 bits.

15.1.2. Nós de armazenamento SG6060 e SG6000

Tem de ter, pelo menos, três nós de armazenamento para os modelos SG6060 e SG6000.

Para cada nó de armazenamento, tem de ter um total de cinco endereços IP, um endereço em cada um dos seguintes:

• BMC Network(mgmt).
• Rede de administração(gestão).
• Rede de grelha.
• Rede do controlador de armazenamento (mgmt). Nota: a rede do controlador de armazenamento tem de ter dois endereços IP.

Tem de ter duas sub-redes para cada um dos seguintes elementos:

• BMC Network.
• Rede de administração.
• Rede de controlador de armazenamento.
• Rede de grelha.

A tabela seguinte indica o número de endereços IP para os nós de administração e armazenamento:

N. º de IPs necessários	Rede de administração	Rede de clientes	Rede de grelha
Nó de administração	2	1	1
Nó de armazenamento	4	0	1

Tem de ter as seguintes três sub-redes:

• Rede de administração.
• Rede de cliente.
• Rede de grelha.

Cada sub-rede tem de ter uma máscara de sub-rede de, no máximo, 30 bits.

15.1.3. Detalhes da rede

15.1.3.1. Rede do plano de gestão da Distributed Cloud:

A rede de gestão fora da banda (OOB) da nuvem distribuída contém a rede do controlador de gestão da placa base (BMC) de armazenamento de objetos e a rede de administração. A rede liga-se a mgmtsw.

Tem de ter o endereço IP do BMC OOB em cada um dos seguintes elementos:

• SG1000
• SG6000

Tem de ter o endereço IP de gestão OOB em cada um dos seguintes elementos:

• SG1000
• SG6000
• SG6060

15.1.3.2. Rede do plano de dados da Distributed Cloud

A rede do plano de dados é composta pelo LIF do cliente StorageGRID (SG1000) externo e pela rede do cliente no NetApp.

Nota: se ainda não o fez, siga a nota em Crie cellconfig para agregar o cellconfig gerado num único ficheiro.

• Siga os passos abaixo para identificar o SubnetClaim em cada um dos seguintes elementos:

  • Ponto final da API S3:
  1. No ficheiro cellconfig, pesquise external-objectstorage-client-lif-subnet.
  2. Identifique o SubnetClaim correspondente que especifica o endereço IP CIDR/gateway atribuído.

  • Pontos finais do dispositivo de rede de grelha SG1000:

    1. No ficheiro cellconfig, pesquise objectstorage-admin-nodes-lif-subnet.
    2. Identifique o SubnetClaim correspondente que especifica o endereço IP CIDR/gateway atribuído.

• Pontos finais do dispositivo de rede de grelha SG6060:

  1. No ficheiro cellconfig, pesquise objectstorage-storage-nodes-lif-subnet.
  2. Identifique o SubnetClaim correspondente que especifica o endereço IP CIDR/gateway atribuído.

15.2. Preparação

15.2.1. Recolha informações

Tempo estimado: 5 a 10 minutos

Antes de continuar esta secção, certifique-se de que o arranque e a configuração da rede concluem a instância da nuvem distribuída e que o operador tem acesso ao ficheiro cellconfig mais preciso ou mais recente disponível, ou acesso ao arranque.

15.2.1.1. Recolha informações de dispositivos de hardware de armazenamento

As instâncias da nuvem distribuída seguem uma convenção de nomenclatura fixa para identificar dispositivos de hardware em racks. Especificamente, para os seguintes dispositivos de armazenamento de objetos:

• Nó de administração(SG1000): <cell>-<rack>-objsadm[node-number]. Por exemplo: af-ae-objsadm01 representa um nó de administrador.
• Nó do controlador de computação de armazenamento (SG6000-CN): <cell>-<rack>-objs[node-number]. Por exemplo: af-ae-objs01.
• Prateleira do controlador de armazenamento(E2860): <cell>-<rack>-objs[node-number]-s1. Por exemplo: af-ae-objs01-s1
• Controladores do nó de armazenamento(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Por exemplo: af-ae-objs01-s1-01 e af-ae-objs01-s1-02

15.2.1.2. Recolha informações da rede do plano de gestão

Durante a inicialização e a configuração da rede, o operador tem de criar uma sub-rede para o plano de gestão. O sistema de armazenamento de objetos requer as seguintes informações durante o processo de arranque:

1. Sub-rede de gestão.
2. Endereço IP do gateway de gestão.
3. 16 endereços IP reservados na sub-rede de gestão, dois endereços IP para cada nó de administrador e quatro endereços IP para cada nó de armazenamento.

Encontre o endereço IP do gateway de gestão a partir do SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. O <cell> e o <rack> são iguais aos identificados no passo "Recolha informações de dispositivos de hardware de armazenamento" Por exemplo: af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Armazene o valor do comando em MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Recolha informações da rede do plano de dados

Antes de continuar, certifique-se de que aprovisionou três sub-redes para o sistema de armazenamento de objetos durante o arranque e a configuração da rede.

Verifique se existem as seguintes sub-redes:

• objectstorage-admin-nodes-lif-subnet
• objectstorage-storage-nodes-lif-subnet
• external-objectstorage-client-lif-subnet

Execute o seguinte comando com os nomes dos SubnetClaim:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Vê o seguinte resultado:

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Verifique se os seguintes campos estão presentes:

1. VLAN
2. READY: True
3. VLANREADY: True

15.2.1.4. Recolha informações de dependências

O sistema de armazenamento de objetos baseia-se nos seguintes serviços principais e infraestrutura na nuvem distribuída:

• NTP
• Módulos de segurança de hardware (HSM)
• DNS

15.2.1.5. Atualize os campos TO-BE-FILLED

Verifique se existem valores TO-BE-FILLED no ficheiro obj-cellobj.yaml e atualize-os.

Execute o seguinte para garantir que o valor não existe no ficheiro YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Rede de gestão de configuração através da ligação local

Tempo estimado: 30 a 45 minutos

Esta subsecção configura a rede de gestão para cada nó do dispositivo StorageGRID. Assim que a rede de gestão estiver configurada, os nós do StorageGRID são acedidos a partir do bootstrapper através do IP na rede de gestão.

Siga estes passos para todos os dispositivos ObjectStorage:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

Para iniciar os dispositivos StorageGRID, ligue-se a cada dispositivo, incluindo dois nós de administração e três nós de armazenamento, com um carrinho de emergência na porta 6 da rede de administração e aceda a https://169.254.0.1:8443 para configurar os endereços IP de administração na rede de gestão.

1. Ligue um carrinho de emergência diretamente à porta RJ-45 mais à direita no dispositivo de serviços através de um cabo Ethernet. Os diagramas seguintes mostram a porta 6 para nós de administração e armazenamento como exemplo:

   

   

2. Abra um navegador de Internet no carrinho de emergência.

3. Navegue para https://169.254.0.1:8443 em cada máquina.

   Nota: se não conseguir aceder à página inicial, experimente alterar a máscara de sub-rede do carrinho de emergência para 255.255.255.0 e tente novamente. Se ainda não conseguir aceder através de uma ligação local, configure o endereço IP do carrinho de emergência como 169.254.0.2 e tente novamente.

4. Na barra de menu do instalador do dispositivo StorageGRID, clique em Configurar Rede > Configuração de links. Verifique se a rede de administração está ativada.

   

5. Para configurar o endereço IP da rede de administração, selecione Configurar Rede > Configuração de IP.

6. Desloque a página para baixo até à secção Rede de administração e, em Atribuição de IP, selecione Estático e introduza os endereços IP de gestão correspondentes, managementIP, para o nó. Pode encontrar o IP de gestão de cada nó no ficheiro obj-cellobj.yaml. Por exemplo:

   • ObjectStorageAdminNode (SG1000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageAdminNode
     metadata:
       creationTimestamp: null
       name: af-ae-objsadm01
     spec:
       network:
         bmcIP: 10.251.188.11/24
         clientIP: 10.251.113.2/28
         dataIP: 10.1.0.66/26
         managementIP: 10.251.188.10/24
       siteName: objectstorage-site
     

   • ObjectStorageStorageNode (SG6000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageStorageNode
     metadata:
       creationTimestamp: null
       name: af-ae-objs01
     spec:
       network:
         bmcIP: 10.251.243.34/24
         controllerAManagementIP: 10.251.243.35/24
         controllerBManagementIP: 10.251.243.36/24
         dataIP: 10.1.0.132/26
         managementIP: 10.251.243.33/24
       siteName: objectstorage-site
     

   Nota: configure a rede apenas para a rede de administrador. Não tem de configurar outros endereços IP.

   Defina o gateway como MANAGEMENT_SWITCH_GATEWAY.

   A imagem de exemplo seguinte mostra a configuração para af-ae-objs01 através do endereço IP de gestão atribuído no ficheiro obj-cellobj.yaml:

   

7. Clique em Guardar e verifique se o endereço IP é atualizado.

8. Envie um ping para o endereço IP de gestão a partir do bootstrapper para se certificar de que está acessível.

   1. Envie um ping para o endereço IP de gestão a partir do bootstrapper para se certificar de que está acessível.
   2. Assim que todos os nós tiverem um endereço IP na rede de administração, aceda à GUI de instalação do nó do StorageGRID através do respetivo endereço IP de gestão.

Resolução de problemas:

Se um nó não for pingável:

1. Aceda à IU de instalação do nó do StorageGRID a partir do passo 3 anterior e verifique se existem erros apresentados num banner de caixa de diálogo. Tente resolver os erros. Contacte os engenheiros, se necessário.
2. Aceda a Configurar rede > Configuração de IP. Verifique se a secção de rede de administração correta está configurada com o IP estático e o gateway corretos. Por vezes, o nó do StorageGRID não regista totalmente a configuração da rede de gestão após a confirmação.
3. Execute novamente os passos 5 a 8 e valide a rede do nó de administrador.

O acesso à GUI de instalação do nó do StorageGRID em cada nó é necessário para continuar a instalação do sistema de armazenamento de objetos.

15.2.3. Atualize o StorageGRID

Tempo estimado: 1 a 1,5 horas

Importante: tem de verificar a versão em todos os nós de computação de armazenamento de objetos. Isto inclui os nós de administração (SG1000) e os nós de armazenamento (SG6060).

Nota: tem de fazer a desatualização para a versão de instalação especificada se a versão atual do StorageGRID for superior à versão fornecida.

Antes de atualizar o StorageGRID, verifique a versão do software StorageGRID. Navegue para Avançadas > Carregar software StorageGRID. É apresentada a versão atual do StorageGRID.

Verifique a versão de instalação do StorageGRID incluída:

gdcloud artifacts tree oci | grep object-storage/os

O resultado de exemplo é semelhante ao seguinte:

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

A versão está etiquetada no artefacto, neste exemplo, como 11.8.0:

Armazene o valor da versão em SG_INSTALL_VERSION.

Verifique a versão do firmware do StorageGRID incluído:

gdcloud artifacts tree oci | grep object-storage/firmware

O resultado de exemplo é semelhante ao seguinte:

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

A versão está etiquetada no artefacto, neste exemplo, como 3.8.1:

Armazene o valor da versão em SG_FIRMWARE_VERSION.

Se a versão no nó não for SG_INSTALL_VERSION, continue para os passos seguintes para atualizar ou alterar para uma versão anterior a versão de instalação do StorageGRID. Se a versão atual for SG_INSTALL_VERSION, avance para a secção Atualize o SANtricity.

15.2.3.1. Atualize o firmware

Siga estes passos para todos os nós do StorageGRID:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

1. Obtenha a imagem de firmware do pacote:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz
   

   O ficheiro está disponível em storagegrid_firmware_install/.

2. Navegue para o instalador do dispositivo StorageGRID no nó do StorageGRID. Escolha Avançadas > Atualizar firmware. Carregue a imagem do firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 e a soma de verificação storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 para a versão do firmware selecionada. Após o carregamento, o StorageGRID inicia automaticamente a validação dos ficheiros. Normalmente, a validação demora cerca de cinco a dez minutos.

   

3. Depois de aparecerem duas marcas de verificação verdes, clique em Atualizar partição inativa.

   

   Depois de receber a mensagem Successfully updated the firmware on the inactive partition, certifique-se de que a partição inativa é efetivamente a versão correta consultando a secção Firmware atual.

   Clique em Reiniciar e Trocar partições duas vezes.

   Nota: durante os processos de reinício e troca, pode perder temporariamente a ligação ao nó. Este processo demora cerca de 20 a 30 minutos a ser concluído. Se não perder a ligação com o nó, pode ter de clicar em Reiniciar e Trocar partições duas vezes para garantir que o pedido é transmitido.

4. Depois de o nó terminar o reinício, repita os passos um e dois para atualizar o firmware da outra partição. A partição ativa é a versão escolhida, enquanto a partição inativa contém a versão mais antiga.

   

15.2.3.2. Atualize o software StorageGRID

Quando a atualização do firmware em todos os nós estiver concluída para a versão correta, atualize o software para a versão selecionada nos dois nós de administração. Não é necessário atualizar os nós de armazenamento, uma vez que imitam e extraem o software nos nós de administração.

Siga estas instruções nos nós de administração do SG1000:

• af-ae-objsadm01
• af-ae-objsadm02

1. Obtenha a imagem de instalação do pacote:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/os.tar.gz
   

   Os ficheiros estão disponíveis em storagegrid_os_install/.

2. Navegue para Avançadas -> Carregar software StorageGRID. Clique em Remover para remover o software atual e carregue o novo pacote de software storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb e a soma de verificação correspondente storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5, conforme mostrado:

   

3. Quando o carregamento do software estiver concluído, certifique-se de que o software do nó foi atualizado para a versão selecionada:

   

15.2.4. Atualize o SANtricity

Tempo estimado: 1 a 1,5 horas

Importante: tem de realizar a verificação da versão em todos os SANtricity de armazenamento de objetos.

Antes de atualizar o SANtricity, verifique a versão do software SANtricity. Navegue até à IU do SANtricity e clique em Suporte > CENTRO DE ATUALIZAÇÃO > Iniciar atualização. É apresentada a versão atual do SANtricity.

Verifique a versão de instalação do SANtricity incluída:

gdcloud artifacts tree oci | grep object-storage/santricity

O resultado de exemplo é semelhante ao seguinte:

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

A versão está etiquetada no artefacto, neste exemplo, como 11.70.5R1.

Armazene o valor da versão em SANTRICITY_OS_VERSION.

Se a versão do SANtricity for inferior a SANTRICITY_OS_VERSION, avance para os passos seguintes para atualizar a versão do SO SANtricity. Caso contrário, avance para a secção Instalação.

Importante: se a sua versão atual for anterior à 11.70.5R1 e a versão de destino for posterior à 11.70.5R1, tem de atualizar primeiro para esta versão.

15.2.4.1. Atualize o SANtricity OS

Siga estas instruções na IU do SANtricity para cada nó de armazenamento:

1. Obtenha a imagem de instalação do pacote:

   gdcloud artifacts extract oci santricity \
       --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION
   
   tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz
   

   O ficheiro de atualização está disponível em santricity/SANTRICITY_OS_VERSION/.

2. Navegue para Apoio técnico > CENTRO DE ATUALIZAÇÃO. Clique em Iniciar atualização em Atualização do software do SO SANtricity. Selecione o ficheiro do software SANtricity OS clicando em Procurar. Carregue o novo pacote de software RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp, conforme mostrado:

   

3. Clique em Iniciar e confirme que quer realizar a operação.

4. Após a conclusão da atualização, verifique se a versão foi atualizada:

   

15.3. Instalação

15.3.1. Crie Secrets

Tempo estimado: 15 a 30 minutos

Para obter valores para criar segredos, use o diretório cellcfg:

1. Obtenha os nomes dos objectstoragestoragenodes:

   $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   

   Exemplo de saída:

   # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   ah-ac-objs01
   ah-ac-objs02
   ah-ac-objs03
   

2. Obtenha o endereço IP da BMC para o nó de armazenamento:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443
   

3. Inicie sessão no gestor do sistema SANtricity a partir do link no resultado do comando anterior. Se não definiu a palavra-passe anteriormente, crie uma palavra-passe e inicie sessão:

   

   1. Se a palavra-passe do SANtricity tiver sido perdida, reponha-a através da consola série do StorageGRID E2860. Para se ligar à porta de série da matriz de discos E2860, as definições do terminal são 115200 8N1.

4. Configure os endereços do servidor NTP no SANtricity System Manager para ambos os controladores:

   

   1. Obtenha os endereços do servidor NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      

   2. Selecione Hardware no gestor do sistema SANtricity.

   3. Se o gráfico mostrar as unidades, clique em Mostrar parte posterior da prateleira. O gráfico muda para mostrar os controladores em vez das unidades.

   4. Clique no controlador que quer configurar. É apresentado o menu de contexto do comando.

   5. Selecione Configurar servidor NTP. É aberta a caixa de diálogo Configurar servidor de Protocolo NTP (Network Time Protocol).

   6. Selecione Quero ativar o NTP no controlador (A ou B). São apresentadas seleções adicionais na caixa de diálogo.

   7. Selecione Especificar manualmente os endereços do servidor NTP. Introduza o endereço do servidor NTP principal com um dos IPs obtidos pelo comando anterior.

   8. Clique em Guardar.

5. Atualize os segredos que contêm credenciais do SANtricity para cada um dos nós de armazenamento no ficheiro cell.yaml. Se os segredos não existirem, adicione-os seguindo este modelo:

   apiVersion: v1
   kind: Secret
   metadata:
     creationTimestamp: null
     name: <STORAGE_NODE_NAME>-santricity
     namespace: gpc-system
   stringData:
     password: 'PASSWORD'
     username: 'admin'
   type: Opaque
   

6. Crie os segredos para cada um dos nós de armazenamento indicados no passo anterior:

   kubectl create secret generic \
      --namespace=gpc-system STORAGE_NODE_NAME-santricity \
      --from-literal=username=admin \
      --from-literal=password=PASSWORD
   

Validação:

1. Execute o seguinte comando com cada nó de armazenamento indicado no passo anterior. Imprime o nome de utilizador do Santricity definido no passo anterior. Valide o administrador:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
   

2. Execute o seguinte comando com cada nó de armazenamento indicado no passo anterior. Imprime a palavra-passe do Santricity:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
   

3. Execute o seguinte comando para obter o URL da IU de gestão do Santricity. Inicie sessão no Santricity com o nome de utilizador e a palavra-passe:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
   

Resolução de problemas:

Se os segredos não forem encontrados quando executar o passo de validação 1 ou 2, execute novamente o passo kubectl create secret.

Se não conseguir iniciar sessão na IU de gestão do Santricity:

1. Reponha a credencial de administrador através da consola serial do StorageGRID E2860.
2. Realize todos os passos anteriores, exceto o último.

3. Elimine o segredo do Santricity existente de cada nó:

   kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
   

4. Execute o último passo para recriar o segredo da Santricity.

15.3.2. Inicialize o armazenamento de objetos

O processo de arranque do armazenamento de objetos varia entre a primeira zona e as zonas de junção. Consulte a secção relevante com base na sua situação específica.

IMPORTANTE: verifique se a zona de âncora concluiu o arranque da API global antes de continuar.

15.3.2.1. Inicialize o armazenamento de objetos na primeira zona

Execute o seguinte comando para iniciar o armazenamento de objetos:

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

Nota: omita a flag --enable-objectstorage-hsm se o ambiente não estiver a ser inicializado com o HSM.

Nota: se inicializar manualmente um ambiente anterior, pode ocorrer um erro quando enviar um CertificateSigningRequest para o Kubernetes. Remova o CertificateSigningRequest e tente reenviar. Se isto acontecer, corrija o problema rodando os certificados do HSM. Para alternar, siga as instruções em HSM Toil 0012, na secção Alternar certificados KMIP.

15.3.2.2. Inicialize o armazenamento de objetos na zona de junção

Resolução de problemas:

1. Quando os comandos da CLI do Google Cloud expiram ou devolvem erros, resolva os problemas devolvidos.
2. Consulte o pod gpc-system/obj-infra-cluster-cm-backend-controller de início de sessão para ver mais detalhes sobre o erro.

15.3.2.3. Inicialize o armazenamento de objetos na zona de junção

Tempo estimado: 30 a 60 minutos

A inicialização do armazenamento de objetos numa zona de junção requer a coordenação entre os reconciliadores do armazenamento de objetos na zona de âncora e na zona de junção. Uma vez que não existe um canal de comunicação seguro e controlado entre duas zonas para reconciliadores durante o tempo de arranque, o IO tem de facilitar manualmente a comunicação segura para reconciliadores de armazenamento de objetos entre duas zonas.

1. Conceda a si mesmo a função predefinida Cluster Admin no cluster zonal root-admin e no cluster global na zona de ancoragem. Consulte o runbook do IAM para ver detalhes.

Em alternativa, aplique estas duas associações de funções na zona de âncora:

Na API global:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

No cluster de administrador raiz:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

1. Execute o comando na zona de âncora para obter o IP do servidor DNS e anote-o para utilização posterior: sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

2. Configure o resolvedor de stub DNS da zona de junção para estabelecer ligação com a zona de âncora:

   1. Desative e pare o systemd-resolved sh systemctl disable systemd-resolved.service --now

   2. Elimine o ficheiro resolv.conf, se existir sh rm -f /etc/resolv.conf

   3. Escreva o IP do servidor DNS da zona de âncora no resolv.conf da zona de junção sh vim /etc/resolv.conf Exemplo de conteúdos do ficheiro /etc/resolv.conf: sh nameserver 10.200.40.0

3. Crie um ficheiro YAML TokenRequest na zona de junção.

   gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH
   

   Substitua JOINING_ZONE_NAME pelo nome da zona do questionário de admissão de clientes, conforme descrito na nota no final da secção.

4. Transfira o ficheiro YAML TokenRequest para a zona de âncora.

   scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
   

5. Aplique o YAML TokenRequest ao cluster global root-admin na zona de âncora.

   kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
   

6. Crie o ficheiro YAML do token na zona de âncora.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
   

7. Transfira o ficheiro YAML do token para a zona de associação.

   scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
   

8. Aplique o YAML do token ao cluster KIND na zona de junção.

   kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
   

9. Crie o ficheiro YAML ObjectStorageBootstrap na zona de âncora.

   gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
   

10. Transfira o ficheiro YAML ObjectStorageBootstrap para a zona de associação.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

11. Aplique o ficheiro YAML ObjectStorageBootstrap ao cluster KIND na zona de junção.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

12. Inicie o armazenamento de objetos na zona de associação.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5
    

    Nota: omita a flag --enable-objectstorage-hsm se o ambiente não estiver a ser inicializado com o HSM.

Nota: se inicializar manualmente um ambiente anterior, pode ocorrer um erro quando enviar um CertificateSigningRequest para o Kubernetes. Nesse caso, remova o CertificateSigningRequest e tente reenviar. Se isto acontecer, corrija o problema rodando os certificados do HSM. Para rodar, siga as instruções em HSM Toil 0012, na secção Rote os certificados KMIP.

Nota: é esperado que objectstorageadminnode, objectstoragestoragenode e objectstoragesite não estejam num estado Pronto no cluster KIND.