Esta página foi traduzida pela API Cloud Translation.

Faça uma expansão dinâmica

Esta página descreve o processo de expansão dinâmica do seu sistema através da incorporação de mais recursos de armazenamento e computação. São fornecidas instruções para os seguintes tipos de expansão:

Expansão horizontal do rack do servidor: adiciona um novo rack à zona. Este rack inclui nós de computação, uma consola, comutadores Top-of-Rack (ToR) e comutadores de gestão (MGMT).
Expansão vertical do servidor: adiciona blocos de expansão do servidor a racks com ranhuras de expansão vazias.
Expansão vertical de ficheiros e armazenamento de blocos: adiciona nós de armazenamento a racks com ranhuras de expansão vazias num cluster de armazenamento existente. Os nós de armazenamento anexados ao mesmo comutador de armazenamento fazem parte do mesmo cluster.

Para mais informações sobre os diferentes tipos de expansão dinâmica, consulte o artigo Vista geral da expansão dinâmica.

Antes de começar

Tem de ter o seguinte em vigor antes de fazer alterações à zona:

Faça uma inspeção de hardware e aprove-a junto do OEM . Siga as instruções em Inspeção de prateleiras.
Siga a geração de KUBECONFIG para gerar o KUBECONFIG para o cluster de administrador do nó do plano de controlo. Use o ficheiro de configuração KUBECONFIG gerado para todos os passos kubectl neste guia.
Verifique se a versão atual do Google Distributed Cloud (GDC) com isolamento de ar no cluster raiz é, pelo menos, a versão 1.13.1:
```
kubectl --kubeconfig $KUBECONFIG get org root -n gpc-system
```
Transfira o ficheiro TAR do GDC. Para mais informações, consulte o artigo Transferir ficheiros.
Prepare o firmware de novos eletrodomésticos:
1. Os dispositivos de comutação de pacotes no hardware do GDC. Para mais informações, consulte o artigo Interruptores.
2. Atualize o armazenamento de ficheiros e blocos do ONTAP seguindo as instruções em Atualização manual do ONTAP.
Valide se o sistema GDCH está em bom estado através de gdcloud system doctor. Se o comando gdcloud system doctor não estiver disponível, use o método alternativo em Validação da instalação de rede.

Realize a expansão horizontal do rack do servidor

Adicione um novo rack composto por nós de computação, a consola e comutadores de gestão e ToR à zona através de uma expansão horizontal do rack de servidores. Os passos descritos nesta secção destinam-se a um único suporte. Se tiver vários suportes, aplique estes passos a cada um deles.

Realizar operações de reposição

Tem de repor o seguinte equipamento de forma segura:

Efetue uma reposição segura do servidor da consola de série. Contacte a Google para receber estas instruções, uma vez que cada implementação pode ter consolas de série diferentes.
Faça uma reposição segura na unidade de distribuição de energia (PDU) da Raritan:
1. Ligue o cabo USB-b à PDU da Raritan a partir do controlador do sistema.
2. Na consola série local, reponha as predefinições de fábrica da PDU através do comando: reset factorydefaults.
3. A PDU está agora definida como admin/legrand.
Faça uma reposição segura, atualize o firmware e reponha os comutadores ToR e MGMT para o aprovisionamento automático de ligação (POAP) seguindo as instruções em Apagar seguramente.
Ligue-se a cada servidor e faça a eliminação segura manualmente.

Prepare artefactos

Siga estes passos para aplicar os ficheiros de configuração e os recursos personalizados necessários:

Gere o ficheiro ZonalExpansion YAML, o hardware CustomResources e os recursos de hardware SubcomponentOverride com o comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Substitua FILE_PATH por cada um dos ficheiros usados. Tenha em atenção que este caminho pode ser diferente se cada ficheiro estiver numa localização diferente.

O recurso personalizado ZonalExpansion acompanha todos os objetos adicionados e comunica o estado de todos os objetos.

Use as seguintes orientações ao rever o ZonalExpansionficheiro YAML:

O campo name tem de ser descritivo, como az-ae-expansion.
O campo assets tem de incluir todos os novos eletrodomésticos no novo rack de expansão.

Segue-se um exemplo de um recurso ZonalExpansion:

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Use ferramentas de infraestrutura como código (IAC) para aplicar o recurso personalizado ZonalExpansion. Para mais informações, consulte o artigo Configuração da infraestrutura como código. Em alternativa, siga o manual de procedimentos IAM-R0004 e use kubectl para o fazer.
Verifique se os recursos ZonalExpansion e NonCompliantDeviceSet foram criados:
1. Verifique o estado do recurso ZonalExpansion:
```
kubectl --kubeconfig $KUBECONFIG get -A zonalexpansion -o yaml
```
  A verificação prévia deve falhar nesta fase com o motivo: ReasonAssetsNotExisted.
2. O recurso NonCompliantDeviceSet tem de existir com o nome com o prefixo noncompliantassets-.
3. A lista de recursos tem de ser igual ao campo assets no recurso personalizado ZonalExpansion.
Siga as instruções em OLT-R0003 para atualizar os recursos.
Ligue os switches ToR e MGMT no novo rack ao switch de agregação no rack existente.
Ligue fisicamente os interruptores aos racks de base.

Conclua o arranque do servidor

Esta fase é maioritariamente automática, mas são necessários alguns passos. Tem de monitorizar o progresso da inicialização e processar todos os casos de falha:

O controlador inicia automaticamente o procedimento de arranque assim que a condição PreflightCheck=True for cumprida.
Verifique se a condição NetworkBootstrapSucceed=True está publicada no recurso personalizado ZonalExpansion. Esta condição encontra-se na localização ZonalExpansion.Status.PNETBootstrapStatus.
Verifique se os interruptores foram removidos da lista NonCompliantDeviceSet:
```
kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A -o yaml
```
Substitua EXPANSION_NAME pelo nome do recurso personalizado de expansão zonal.

Verifique se os comutadores não estão no campo Spec.Assets do ficheiro YAML devolvido. Esta remoção permite que o GDC atualize as ACLs de rede para permitir outros procedimentos de arranque do dispositivo. As duas ACLs de rede atualizadas são quarantine-mgmt-switch-acl e quarantine-data-switch-acl.

Apresente uma lista de todos os endereços IP do Baseboard Management Controller (BMC) para o servidor e verifique se os endereços IP do iLO estão atribuídos à nova máquina bare metal e se o arranque pode ser iniciado:

kubectl --kubeconfig $KUBECONFIG get servers -n gpc-system -o=custom-columns=SERVER:.metadata.name,BMC_IP:.spec.bmc.ip

Exemplo de saída:

 SERVER       BMC_IP
 yz-aa-bm01   10.128.136.2
 yz-aa-bm02   10.128.136.3
 yz-aa-bm03   10.128.136.4
 yz-ab-bm01   10.128.136.66
 yz-ab-bm02   10.128.136.67
 yz-ab-bm03   10.128.136.68
 yz-ac-bm01   10.128.136.130
 yz-ac-bm02   10.128.136.131
 yz-ac-bm03   10.128.136.132
 yz-ac-bm04   10.128.136.133
 yz-ac-bm05   10.128.136.134
 yz-ac-bm06   10.128.136.135
 yz-ac-bm07   10.128.136.136
 yz-ac-bm08   10.128.136.137
 yz-ac-bm09   10.128.136.138
 yz-ac-bm10   10.128.136.139
 yz-ac-bm11   10.128.136.140
 yz-ac-bm12   10.128.136.141
 yz-ac-bm13   10.128.136.142
 yz-ac-bm14   10.128.136.143
 yz-ac-bm15   10.128.136.144
 yz-ac-bm16   10.128.136.145
 yz-ac-bm17   10.128.136.146
 yz-ac-bm18   10.128.136.147

O GDC inicia os servidores em paralelo para realizar a eliminação segura, a validação, a atualização da definição do BIOS e outros procedimentos de arranque.

Verifique se a condição ServerBootstrapSucceeded=True foi publicada no recurso personalizado ZonalExpansion. Esta condição encontra-se na localização ZonalExpansion.Status.SERVBootstrapStatus:
- O estado do anfitrião bare metal do servidor entra num estado de Available ou Provisioned após o arranque ser bem-sucedido.
- A um nível de detalhe da CLI de quatro, vê registos como "Not all servers in the ZonalExpansion are bootstrapped" com uma lista de servidores que ainda não estão prontos.

Verifique se os servidores foram removidos da lista NonCompliantDeviceSet:

kubectl --kubeconfig $KUBECONFIG get noncompliantdevicesets -n gpc-system "noncompliantassets-EXPANSION_NAME" -o yaml

Verifique se a condição ExpansionSucceeded=True foi publicada no recurso personalizado ZonalExpansion. Esta condição encontra-se na localização ZonalExpansion.Status.Conditions.

Verifique se a lista NonCompliantDeviceSet foi eliminada:

kubectl --kubeconfig $KUBECONFIG get noncompliantdeviceset noncompliantassets-EXPANSION_NAME -A

Resultado esperado:

`Error from server (NotFound): noncompliantdevicesets.system.private.gdc.goog "noncompliantassets-EXPANSION_NAME" not found`

Faça a expansão vertical do servidor

Adicione blocos de expansão de servidores em racks com ranhuras de expansão vazias através de uma expansão vertical de servidores. Muitas das instruções para esta expansão são semelhantes à expansão de computação horizontal. Siga estes passos para fazer uma expansão vertical do rack de servidor:

Instale fisicamente o bloco de servidor padrão que ocupa seis nós de capacidade ou o bloco de servidor de GPU que consome três nós de capacidade. Pode adicionar vários blocos por suporte. Aviso: não ligue cabos aos interruptores mgmtsw ou aggsw. Para mais informações, consulte o artigo Interruptores.
Não faça nenhuma cablagem, exceto a da fonte de alimentação. Este passo permite que o processo de arranque do servidor verifique se o servidor não está offline à chegada.

Gere o ficheiro ZonalExpansionYAML e o recurso de hardwareSubcomponentOverride com o comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af

Substitua FILE_PATH por cada um dos ficheiros usados. Tenha em atenção que este caminho pode ser diferente se cada ficheiro estiver numa localização diferente.

Use as seguintes orientações ao rever o ZonalExpansionficheiro YAML:

O campo name tem de ser descritivo, como az-ae-expansion.
O campo assets tem de incluir todos os novos eletrodomésticos no novo rack de expansão.

Segue-se um exemplo de um recurso ZonalExpansion:

apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
  name: file
  namespace: gpc-system
spec:
  assets:
  - kind: ManagementSwitch
    name: az-ae-mgmtsw01
  - kind: ManagementSwitch
    name: az-ae-mgmtsw02
  - kind: TORSwitch
    name: az-ae-torsw01
  - kind: TORSwitch
    name: az-ae-torsw02
  - kind: TORSwitch
    name: az-ae-bm01

Aplique o recurso personalizado ZonalExpansion que acabou de criar ao cluster.
Verifique se os recursos ZonalExpansion e NonCompliantDeviceSet foram criados:
1. Verifique o estado do recurso ZonalExpansion. A verificação prévia deve falhar nesta fase com o motivo: ReasonAssetsNotExisted.
2. O recurso NonCompliantDeviceSet tem de existir com o nome com o prefixo noncompliantassets-.
3. A lista de recursos tem de ser igual ao campo assets no recurso personalizado ZonalExpansion.
Siga as instruções em OLT-R0003 para atualizar os recursos.
Verifique se a ACL do interruptor de quarentena está em execução seguindo o manual de instruções OLT-R0001.
Ligue os cabos dos servidores, se ainda não o tiver feito. Siga o ficheiro de cablagem fornecido pela Hewlett Packard Enterprise (HPE).
Verifique se o processo de arranque do servidor é iniciado e concluído com êxito. Para mais informações, consulte o artigo Conclua o arranque do servidor.

Realize a expansão vertical do armazenamento de ficheiros e blocos

Estas instruções incluem os passos necessários para realizar uma expansão vertical ou de um único rack do nó de armazenamento. A expansão do nó de armazenamento é realizada quando são adicionados novos nós de armazenamento ONTAP para expandir as capacidades de armazenamento de um rack existente. As instruções de cablagem para os novos dispositivos de armazenamento não são fornecidas aqui, apenas os procedimentos para apagar, atualizar e adicionar novos nós de armazenamento a um cluster existente.

Realize a configuração para a expansão do nó de armazenamento

Siga estes passos para preparar o cluster para a expansão do nó de armazenamento:

Siga a geração de KUBECONFIG para gerar o KUBECONFIG para o cluster de administrador do nó do plano de controlo. Use o ficheiro de configuração KUBECONFIG gerado para todos os passos kubectl neste guia:

Aplique um recurso SubcomponentOverride para desativar os reconciliadores de armazenamento enquanto realiza a configuração inicial para a expansão de nós:

kubectl --kubeconfig $KUBECONFIG apply -f - <<EOF
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: file-storage-sub-override
    namespace: root
spec:
    subComponentRef: "file-storage"
    backend:
        operableParameters:
            controller:
                enableReconcilers: ""
                disableReconcilers: "*"
EOF

Verifique se a substituição funcionou e se os reconciliadores file-storage foram desativados:
```
kubectl --kubeconfig $KUBECONFIG describe deployment file-storage -n
file-system | grep reconcilers
```
Tem de ver o seguinte:
```
--enable-reconcilers=
--disable-reconcilers=*
```
Se não vir este estado, aguarde vários minutos para permitir que o recurso SubcomponentOverride seja aplicado e faça esta verificação novamente. Se o SubcomponentOverride ainda não tiver sido aplicado após alguns minutos, contacte o apoio técnico de engenharia do GDC.

Gere o ficheiro ZonalExpansion YAML e o recurso de SubcomponentOverride hardware através do comando gdcloud system assets add:

gdcloud system assets add \
--kubeconfig $KUBECONFIG \
--license-dir FILE_PATH/licenses/ \
--secrets FILE_PATH/secrets.yaml \
--devices FILE_PATH/devices.csv \
--cables FILE_PATH/cables.csv \
--include-cellcfg \
--name az-ae-expansion \
--output ./outputs/af
```
Replace FILE_PATH for each of the files used. Note, this path might be different if each file is in a different location.

Use the following guidance when reviewing the `ZonalExpansion` YAML file:

The `name` field must be descriptive, such as aj-ad-expansion.
The `assets` field must include all new appliances in the new expansion rack.
Here is an example of a `ZonalExpansion` resource:

```sh
apiVersion: system.private.gdc.goog/v1alpha1
kind: ZonalExpansion
metadata:
name: file
namespace: gpc-system
spec:
assets:
- kind: StorageNode
    name: aj-ad-stge03-01
- kind: StorageNode
    name: aj-ad-stge03-02
```

Aplique o recurso personalizado ZonalExpansion que acabou de criar ao cluster.
Verifique se os recursos ZonalExpansion e NonCompliantDeviceSet foram criados:
1. Verifique o estado do recurso ZonalExpansion. A verificação prévia deve falhar nesta fase com o motivo: ReasonAssetsNotExisted.
2. O recurso NonCompliantDeviceSet tem de existir com o nome com o prefixo noncompliantassets-.
3. A lista de recursos tem de ser igual ao campo de recursos no recurso personalizado ZonalExpansion.
Aplique os seguintes recursos de recursos de hardware SubcomponentOverride ao cluster de administrador raiz usando ferramentas de IaC.
- file/file-storage.yaml
- inv/inv-core.yaml
Nota: o SubcomponentOverride gerado não inclui substituições já aplicadas ao cluster. Capture os SubcomponentOverride atuais e adicione-os ao SubcomponentOverride gerado respetivo para garantir que não se perdem substituições.

Confirme que os novos nós são adicionados ao cluster:

kubectl --kubeconfig $KUBECONFIG get storagenodes -n gpc-system

Deverá ver os novos recursos personalizados de nós adicionados com um valor de idade mais recente:

  NAME              MGMTIP           INTERCONNECTIP   MODEL      AGE
  aj-ad-stge01-01   172.22.243.129   169.254.0.1      AFF-A250   37d
  aj-ad-stge01-02   172.22.243.130   169.254.0.3      AFF-A250   37d
  aj-ad-stge03-01   172.22.243.133   169.254.0.9      AFF-A400   20d
  aj-ad-stge03-02   172.22.243.134   169.254.0.11     AFF-A400   20d

Use o comando describe para obter informações sobre ambos os nós, uma vez que contêm informações necessárias para passos posteriores.

kubectl --kubeconfig $KUBECONFIG describe storagenode NODE_NAME -n gpc-system

Substitua NODE_NAME pelo nome de cada nó criado.