6. Redefinir se estiver fazendo rebootstrap

Tempo estimado para a conclusão: 4 dias

Proprietário do componente operacional: HW

Perfil de habilidade: engenheiro de implantação

Conclua as tarefas a seguir para redefinir os dispositivos e sistemas em execução no ambiente isolado do Google Distributed Cloud (GDC).

6.1. Índice

  1. Visão geral do procedimento de redefinição
  2. Redefinição do servidor HPE
  3. Redefinição do NetApp StorageGRID
  4. Redefinição do NetApp ONTAP
  5. Redefinição do HSM da Thales
  6. Redefinição de firewalls da Palo Alto
  7. Redefinição de switches da Cisco
  8. Additional Resources

6.2. Pré-requisitos e segurança

6.2.1. Acesso necessário

  • Acesso físico: acesso à sala do data center com equipamentos de crashcart
  • Acesso à rede: conectividade da interface de gerenciamento ou acesso ao console
  • Credenciais: acesso de administrador a todos os sistemas
  • Backups: backup completo de todos os secrets e dados de configuração

6.2.2. Lista de verificação de segurança

  • [ ] Acesso físico à infraestrutura
  • [ ] Os secrets de emergência foram protegidos off-line
  • [ ] Backup da infraestrutura (se necessário)

6.3. Visão geral do procedimento de redefinição

O procedimento de redefinição de uma zona de célula do GDC tem como objetivo liberar todos os aparelhos de hardware de qualquer dependência e reverter para o estado de fábrica.

6.3.1. Dependências de infraestrutura

Os componentes têm as seguintes interdependências que determinam a ordem de redefinição:

  1. Servidores, NetApp ONTAP e NetApp StorageGrid dependem dos dispositivos HSM da Thales, que fornecem as chaves de criptografia para ILOs, discos, locatários e buckets.
  2. Os dispositivos HSM da Thales dependem da conectividade de firewalls de IDP/perímetro e switches da Cisco.
  3. Os firewalls de perímetro/IDP dependem da infraestrutura de rede dos switches Cisco.
  4. Os switches da Cisco precisam ser redefinidos como último recurso, já que a conectividade será interrompida após a redefinição.

6.3.2. Reset Order (Critical)

Siga esta ordem exata para evitar bloqueios do sistema:

  1. Servidores HPE: remova primeiro as dependências do HSM
  2. NetApp StorageGRID: limpar a criptografia e redefinir nós
  3. NetApp ONTAP: desativar o HSM e redefinir o cluster
  4. HSM da Thales: redefinição de fábrica e limpeza da raiz de confiança
  5. Firewalls: redefinição de fábrica para a configuração padrão
  6. Switches Cisco: redefina o último (isso vai interromper a conectividade).

Visão geral

6.4. Exclusão segura da Hewlett Packard Enterprise

Há três tipos de operações de redefinição disponíveis, cada uma servindo como um método alternativo para limpar a configuração do iLO Key Manager. O objetivo principal é remover a dependência do módulo de segurança de hardware (HSM).

Em geral, a redefinição de fábrica do ILO é suficiente para limpar a configuração do KMS. No próximo bootstrap, o processo de bootstrap do servidor vai inicializar os parâmetros do BIOS de configuração do servidor, apagar os discos e reinicializar o servidor.

Esta seção aborda como realizar três tipos de exclusões:

  1. Uma redefinição de fábrica do iLO

  2. Redefinição manual do iLO

  3. Apagamento seguro

Esses scripts de exclusão usam um exemplo de arquivo CSV chamado example.csv. Antes de continuar, prepare o seguinte arquivo CSV:

    root@example-bootstrapper:/home/ubuntu/md# cat example.csv
    ip,passd
    10.251.248.62,XXXXXXXX
    10.251.248.64,XXXXXXXX
    10.251.248.66,XXXXXXXX
    10.251.248.68,XXXXXXXX
    10.251.248.70,XXXXXXXX
    10.251.248.72,XXXXXXXX
    10.251.248.74,XXXXXXXX
    10.251.248.76,XXXXXXXX

6.4.1. Redefinição de fábrica do iLO

Conclua uma redefinição de fábrica normal do iLO:

  1. Crie um arquivo chamado serversreset.py e adicione o seguinte script Python:

    import csv
import argparse
import requests
import urllib3
import json
urllib3.disable_warnings()
PARSER = argparse.ArgumentParser(prog='serversreset.py', \
    description='reset ilo to factory settings')
PARSER.add_argument('-csv', '--file', help='choose the csv file', type=str)
ARGS = vars(PARSER.parse_args())
headers = {'content-type': 'application/json'}
payload = {'ResetType': 'Default'}
url = '/redfish/v1/Managers/1/Actions/Oem/Hpe/HpeiLO.ResetToFactoryDefaults/'
with open(ARGS['file'], encoding="utf8", mode='r') as csv_file:
    CSV_READER = csv.DictReader(csv_file)
    for row in CSV_READER:
      try:
        system = requests.post('https://'+row['ip']+url,data=json.dumps(payload),headers=headers,verify=False,auth=('administrator',row['passd']))
        systemData = system.json()
        print(systemData)
      except Exception as err:
        print(err)

  2. Execute o comando a seguir e substitua example.csv pelo arquivo CSV:

    python3 serversreset.py -csv example.csv

    A saída será parecida com esta:

    {'error': {'code': 'iLO.0.10.ExtendedInfo', 'message': 'See @Message.ExtendedInfo for more information.', '@Message.ExtendedInfo': [{'MessageId': 'iLO.2.15.ResetInProgress'}]}}
{'error': {'code': 'iLO.0.10.ExtendedInfo', 'message': 'See @Message.ExtendedInfo for more information.', '@Message.ExtendedInfo': [{'MessageId': 'iLO.2.15.ResetInProgress'}]}}
{'error': {'code': 'iLO.0.10.ExtendedInfo', 'message': 'See @Message.ExtendedInfo for more information.', '@Message.ExtendedInfo': [{'MessageId': 'iLO.2.15.ResetInProgress'}]}}

6.4.2. Outras etapas manuais do iLO

Faça uma redefinição manual do iLO usando a UI do iLO:

  1. Selecione iLO > Administração > Gerenciador de chaves > Excluir configurações.

  2. No console da BIOS, selecione Utilitários do sistema > Configuração do sistema > RAID incorporado > Administração > Redefinir para o padrão.

  3. Defina as interfaces para netboot apenas para LOM1. Todos os nós de GPU NÃO têm placas LOM1, mas sim placas Intel.

  4. Defina a rede iLO como DHCP.

6.4.3. Redefinição do BIOS

Siga estas etapas para fazer uma redefinição da BIOS:

  1. Crie um arquivo chamado biosreset.py e adicione o seguinte script Python:

    import csv
import argparse
import requests
import urllib3
import json
urllib3.disable_warnings()
PARSER = argparse.ArgumentParser(prog='biosreset.py', \
    description='reset BIOS to factory settings')
PARSER.add_argument('-csv', '--file', help='choose the csv file', type=str)
ARGS = vars(PARSER.parse_args())
headers = {'content-type': 'application/json'}
payload = {}
with open(ARGS['file'], encoding="utf8", mode='r') as csv_file:
    CSV_READER = csv.DictReader(csv_file)
    for row in CSV_READER:
      try:
        system = requests.post('https://'+row['ip']+'/redfish/v1/systems/1/bios/Actions/Bios.ResetBios/',data=json.dumps(payload),headers=headers,verify=False,auth=('administrator',row['passd']))
        systemData = system.json()
        print(systemData)
      except Exception as err:
        print(err)

  2. Execute o comando a seguir e substitua example.csv pelo arquivo CSV:

    python3 biosreset.py -csv example.csv

    A saída será parecida com esta:

    {'error': {'code': 'iLO.0.10.ExtendedInfo', 'message': 'See @Message.ExtendedInfo for more information.', '@Message.ExtendedInfo': [{'MessageId': 'iLO.2.15.SystemResetRequired'}]}}

  3. Depois de executar o comando, os servidores ficam em um estado de ativação. Execute o script a seguir para desligar todos os servidores:

    import csv
import argparse
import requests
import urllib3
import json
urllib3.disable_warnings()
PARSER = argparse.ArgumentParser(prog='power-ilo.py', \
    description='power off server')
PARSER.add_argument('-csv', '--file', help='choose the csv file', type=str)
ARGS = vars(PARSER.parse_args())
headers = {'content-type': 'application/json'}
payload = {'ResetType': 'PushPowerButton'}
with open(ARGS['file'], encoding="utf8", mode='r') as csv_file:
    CSV_READER = csv.DictReader(csv_file)
    for row in CSV_READER:
        try:
            system = requests.post(
                'https://' + row['ip'] +
                '/redfish/v1/systems/1/Actions/ComputerSystem.Reset/',
                data=json.dumps(payload),
                headers=headers,
                verify=False,
                auth=('administrator', row['passd']))
            systemData = system.json()
            if 'Success' in systemData['error']['@Message.ExtendedInfo'][0][
                    'MessageId']:
                print(f"ilo with ip {row['ip']} succeeded")
                #print(systemData)
            else:
                print(f"ilo with ip {row['ip']} failed")
                print(systemData)
        except Exception as err:
            print(err)

    Desligue os servidores manualmente:

    python3 power-ilo.py -csv ~/servers.csv
    1. (Opcional) Para verificar o status, use o seguinte script:
    import csv
import argparse
import requests
import urllib3
import json
urllib3.disable_warnings()
PARSER = argparse.ArgumentParser(prog='ilostatus.py', \
description='check power status of server')
PARSER.add_argument('-csv', '--file', help='choose the csv file', type=str)
ARGS = vars(PARSER.parse_args())
headers = {'content-type': 'application/json'}
with open(ARGS['file'], encoding="utf8", mode='r') as csv_file:
    CSV_READER = csv.DictReader(csv_file)
    for row in CSV_READER:
      try:
        system = requests.get('https://'+row['ip']+'/redfish/v1/Systems/1',headers=headers,verify=False,auth=('administrator',row['passd']))
        systemData = system.json()
        print(f"ilo with ip {row['ip']} has power status of {systemData['PowerState']}")
        if 'Success' in systemData['error']['@Message.ExtendedInfo'][0]['MessageId']:
            print(f"ilo with ip {row['ip']} succeeded")
            print(systemData)
        else:
            print(f"ilo with ip {row['ip']} failed")
            print(systemData)
      except Exception as err:
        pass

    Execute este comando:

    python3 ilostatus.py -csv ~/servers.csv

    A saída será parecida com esta:

    ilo with ip 172.22.112.96 has power status of Off
ilo with ip 172.22.112.97 has power status of Off
ilo with ip 172.22.112.98 has power status of Off
ilo with ip 172.22.112.100 has power status of Off
ilo with ip 172.22.112.101 has power status of Off
ilo with ip 172.22.112.102 has power status of Off

    6.4.4. Limpeza segura

  1. Pressione F10 na tela POST do servidor. Isso inicia o provisionamento inteligente.

  2. Depois que o Intelligent Provisioning for iniciado, clique na seta para baixo ao lado de Assistente de configuração inicial para pular o assistente.

  3. Pule a solicitação do assistente e clique em Sim.

  4. Clique em Realizar manutenção.

  5. Clique em Apagamento seguro com um botão.

  6. Uma mensagem indica que você não tem privilégios suficientes. Clique em Fazer login e insira as credenciais de administrador.

  7. Clique em Concluído.

  8. Clique em Enviar.

  9. Confirme que você quer fazer a exclusão segura e digite ERASE.

  10. Clique em APAGAR.

  11. Clique em Sim para confirmar.

  12. Clique em Iniciar agora na seção "Fila de jobs".

  13. Em cerca de dois minutos ou menos, siga a solicitação para clicar em OK.

  14. A máquina será reinicializada. Não toque em nada por cerca de 10 a 15 minutos.

  15. Depois que a exclusão segura for concluída, volte ao BIOS clicando em F9 durante a inicialização do POST.

  16. Navegue até Embedded Applications > Integrated Management Log (IML) > View IML > OK. A mensagem Apagamento seguro com um botão concluído é exibida:

Exclusão segura com um botão concluída

  1. Crie um arquivo chamado serversreset.py e adicione o seguinte script Python:

    import csv
import argparse
import requests
import urllib3
import json
urllib3.disable_warnings()
PARSER = argparse.ArgumentParser(prog='secureerase.py', \
    description='reset ilo to factory settings')
PARSER.add_argument('-csv', '--file', help='choose the csv file', type=str)
ARGS = vars(PARSER.parse_args())
headers = {'content-type': 'application/json'}
payload = {'SystemROMAndiLOErase': True , 'UserDataErase': True}
with open(ARGS['file'], encoding="utf8", mode='r') as csv_file:
    CSV_READER = csv.DictReader(csv_file)
    for row in CSV_READER:
      try:
        system = requests.post('https://'+row['ip']+'/redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase/',data=json.dumps(payload),headers=headers,verify=False,auth=('administrator',row['passd']))
        systemData = system.json()
        print(systemData)
      except Exception as err:
        print(err)

  2. Execute o comando a seguir e substitua example.csv pelo arquivo CSV:

    python serversreset.py -csv example.csv

  3. Depois de executar o comando, os servidores ficam desligados. Você precisa ligar o servidor manualmente.

6.5. Redefinir o dispositivo NetApp StorageGRID

6.5.1. Pré-requisitos

Antes de redefinir o dispositivo NetApp StorageGRID, leia o seguinte: - Se o sistema foi ativado com criptografia de nó e/ou de unidade, siga as etapas descritas em Desativar a criptografia de site do HSM. Caso contrário, redefina o sistema StorageGRID.

6.5.2. Desativar a criptografia do site do HSM do StorageGRID nos nós do controlador de armazenamento

Para receber os IPs dos nós do controlador de armazenamento (dois IPs para cada nó de armazenamento):

$ kubectl get objectstoragestoragenodes -n gpc-system -o custom-columns="NAME:metadata.name,COMPUTE_NODEA_IP:.spec.network.controllerAManagementIP,COMPUTE_NODEB_IP:.spec.network.controllerBManagementIP"
NAME           COMPUTE_NODEA_IP    COMPUTE_NODEB_IP
ak-ac-objs01   172.22.210.166/24   172.22.210.167/24
ak-ac-objs02   172.22.210.170/24   172.22.210.171/24
ak-ac-objs03   172.22.210.174/24   172.22.210.175/24

Se o sistema StorageGRID foi ativado anteriormente com HSM, a criptografia precisa ser removida antes de prosseguir com a redefinição de fábrica. Siga estas etapas para cada nó de armazenamento antes de redefinir o dispositivo. Se isso não for feito, os discos e o sistema poderão ser bloqueados.

  1. Faça login no site do Object Storage e navegue até a lista de nós na barra lateral.

  2. Clique no nome do nó de armazenamento.

  3. Acesse a guia SANtricity System Manager.

  4. Acesse Configurações > Sistema > Gerenciamento de chaves de segurança.

    Acesso do gerenciador do sistema StorageGRID UI Santricitry

  5. Selecione Desativar o gerenciamento de chaves externas e digite a senha para fazer o download da chave reserva.

6.5.3. Redefinição de fábrica do nó de administrador do StorageGRID e do nó de computação do Storage

Para acessar os IPs dos nós de administrador:

$ kubectl get objectstorageadminnodes -n gpc-system
NAME              SITE NAME       MANAGEMENT IP       READY   AGE
ak-ac-objsadm01   ak-obj-site-1   172.22.210.160/24   True    12d
ak-ac-objsadm02   ak-obj-site-1   172.22.210.162/24   True    12d

Para acessar os IPs dos nós de computação do Storage:

$ kubectl get objectstoragestoragenodes -n gpc-system
NAME           SITE NAME       MANAGEMENT IP       READY   AGE
ak-ac-objs01   ak-obj-site-1   172.22.210.164/24   True    12d
ak-ac-objs02   ak-obj-site-1   172.22.210.168/24   True    12d
ak-ac-objs03   ak-obj-site-1   172.22.210.172/24   True    12d

Para fazer a redefinição de fábrica do dispositivo StorageGRID, siga estas etapas em cada nó (de armazenamento e de administrador) no site:

  1. Extraia os IPs de gerenciamento de cada nó. Isso pode ser obtido no cell.yaml, procurando ObjectStorageStorageNode e ObjectStorageAdminNode. Eles também podem ser encontrados nos recursos de nó do cluster de administrador raiz.

  2. Extraia a senha e conecte-se ao nó usando SSH:

    • Se o nó não tiver o StorageGRID instalado, use admin/bycast ou root/netapp1! como nome de usuário e senha, respectivamente. Use a porta SSH 8022 se o ssh não funcionar.

    • Se o nó tiver o StorageGRID instalado, mas não tiver uma configuração de site, use admin/bycast ou root/bycast como nome de usuário e senha, respectivamente.

    • Se o site estiver configurado e o nó fizer parte dele:

      1. Extraia a senha longa de provisionamento. Ele é armazenado em um secret chamado grid-secret, que pode ser encontrado no arquivo cell.yaml. Como opção, execute o comando a seguir. Não se esqueça de decodificar a senha em base64:

        echo $(kubectl get secret -n gpc-system grid-secret -ojsonpath="{.data.grid-management-provisioning-password}" | base64 -d)

      2. Na interface do site do Object Storage, acesse Manutenção > Sistema > Pacote de recuperação para baixar o pacote depois de inserir a senha de provisionamento.

        Pacote de recuperação de download da interface do StorageGRID

      3. Depois de fazer o download, extraia o arquivo tar. Ele vai conter outra tarball: GIDXXXXX_REV1_SAID.zip. Extraia o tarball para encontrar o arquivo Passwords.txt. Use a Password para acesso SSH e root e ignore a SSH Access Password.

        Arquivo de amostra:

        Password Data for Grid ID: 546285, Revision: 1
Revision Prepared on: 2022-06-13 20:49:56 +0000

Server "root" and "admin" Account Passwords
Server Name            Password          SSH Access Password
____________________________________________________________
alatl14-gpcstgeadm01   <removed>     <removed>
alatl14-gpcstgeadm02   <removed>     <removed>
alatl14-gpcstgecn01    <removed>     n/a
alatl14-gpcstgecn02    <removed>     n/a
alatl14-gpcstgecn03    <removed>     n/a

  3. Abra um console serial para o nó ou conecte-se a ele usando SSH:

    ssh -o ProxyCommand=None -o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null admin@<node-management-ip>

  4. Digite as credenciais para fazer login. Para conseguir privilégios de sudo, digite su - e insira a senha de root obtida na segunda etapa.

  5. Digite o comando sgareinstall e pressione y para continuar redefinindo o dispositivo.

  6. Se a criptografia estiver ativada no dispositivo, siga estas etapas após a conclusão da redefinição para excluir os pools de disco e o cache SSD.

6.5.4. Excluir pools de disco e cache SSD nos nós do controlador de armazenamento

Para receber os IPs dos nós do controlador de armazenamento (dois IPs para cada nó de armazenamento):

$ kubectl get objectstoragestoragenodes -n gpc-system -o custom-columns="NAME:metadata.name,COMPUTE_NODEA_IP:.spec.network.controllerAManagementIP,COMPUTE_NODEB_IP:.spec.network.controllerBManagementIP"
NAME           COMPUTE_NODEA_IP    COMPUTE_NODEB_IP
ak-ac-objs01   172.22.210.166/24   172.22.210.167/24
ak-ac-objs02   172.22.210.170/24   172.22.210.171/24
ak-ac-objs03   172.22.210.174/24   172.22.210.175/24

Se a criptografia estiver ativada no dispositivo e os nós tiverem sido redefinidos após seguir a última seção, os pools de disco precisarão ser excluídos junto com a exclusão das unidades. Isso precisa ser feito antes de reinicializar o site para que ele possa criar novos pools de disco. Siga estas etapas para cada nó de armazenamento (controlador de armazenamento e2860) no site (também conhecido como controllerAManagementIP):

  1. Abra um navegador da Web para acessar https://<storage-node-controller-ip>:8443 e insira as credenciais. Se você não tiver acesso às credenciais do SANtricity, siga estas etapas.

  2. Acesse Armazenamento > Pools e grupos de volumes.

  3. Excluir cache de SSD:

    1. Selecione o cache de SSD para destacar.

    2. Selecione o menu suspenso Tarefas incomuns e clique em Excluir.

    Excluir cache de SSD da interface do Santricity

  4. Exclua o pool de discos:

    1. Selecione o pool de discos para destacar.

    2. Selecione o menu suspenso Tarefas incomuns e clique em Excluir.

    Excluir pool de disco da interface do usuário do Santricity

  5. Tente criar um novo pool de discos. Uma caixa de diálogo aparece, bloqueando a criação e pedindo para apagar as unidades.

    Como as unidades seguras não atribuídas não podem ser usadas para a criação de pools, é preciso excluí-las primeiro. Clique no botão de opção Sim, quero selecionar as unidades que quero apagar para a operação e selecione todas as unidades que serão apagadas. Confirme a operação de exclusão e clique em OK. Não crie um novo pool.

  6. Siga as etapas descritas na seção de remoção da criptografia de nós.

6.5.5. Remover a criptografia de nós nos nós de administrador e de computação do StorageGRID

Para acessar os IPs dos nós de administrador:

$ kubectl get objectstorageadminnodes -n gpc-system
NAME              SITE NAME       MANAGEMENT IP       READY   AGE
ak-ac-objsadm01   ak-obj-site-1   172.22.210.160/24   True    12d
ak-ac-objsadm02   ak-obj-site-1   172.22.210.162/24   True    12d

Para acessar os IPs dos nós de computação do Storage:

$ kr get objectstoragestoragenodes -n gpc-system
NAME           SITE NAME       MANAGEMENT IP       READY   AGE
ak-ac-objs01   ak-obj-site-1   172.22.210.164/24   True    12d
ak-ac-objs02   ak-obj-site-1   172.22.210.168/24   True    12d
ak-ac-objs03   ak-obj-site-1   172.22.210.172/24   True    12d

Se a criptografia estiver ativada no dispositivo e os nós tiverem sido redefinidos depois de seguir estas etapas e os pools de disco e o cache SSD tiverem sido excluídos com estas etapas, siga as etapas abaixo em cada nó para remover a criptografia:

  1. Acesse a interface do usuário do instalador do appliance StorageGRID.

  2. Acesse Configurar hardware > Criptografia de nós.

  3. Clique em Limpar chave do KMS e excluir dados. Interface do instalador do appliance: limpar chave do KMS e excluir dados

  4. Depois que a limpeza for acionada, o controle será reiniciado, o que pode levar cerca de 15 minutos.

6.5.6. Reinstalar o StorageGRID

  1. Reinicie cada nó manualmente.

  2. Abra um console serial no nó, acesse o menu do carregador de inicialização GRUB e selecione StorageGRID Appliance: Force StorageGRID reinstall.

    Reinstalação forçada do carregador de inicialização do StorageGRID

6.5.7. Receber credenciais do SANtricity

  1. Abra um console serial para qualquer um dos controladores do SANtricity.

  2. Use as seguintes credenciais para fazer login:

    • username: spri
    • senha: SPRIentry

  3. Depois de fazer login, você vai ver um menu como este:

    
Service Interface Main Menu
==============================
1)Display IP Configuration
2)Change IP Configuration
3)Reset Storage Array Administrator Password
4)Display 7-segment LED codes
5)Disable SAML
6)Unlock remote admin account
Q)Quit Menu
Enter Selection: 3
Are you sure that you want to reset the Storage Array Password ? (Y/N): Y
Storage Array Password reset successful

  4. Faça login nos controladores do SANtricity para que a redefinição de senha fique disponível.

6.6. Redefinir dispositivo NetApp ONTAP

6.6.1. Pré-requisitos

Antes de redefinir o dispositivo NetApp ONTAP, leia o seguinte:

  • Se o sistema foi ativado anteriormente com um módulo de segurança de hardware (HSM), siga as etapas descritas em Desativar o módulo de segurança de hardware antes de redefinir os sistemas ONTAP.

  • Essa é uma operação destrutiva que apaga todos os dados do CipherTrust Manager, incluindo, entre outros, chaves, backups, chaves de backup e registros do sistema.

  • Verifique se você tem um backup válido do CipherTrust Manager de todos os dados e chaves de backup.

  • Se um HSM incorporado estiver disponível, ele não será redefinido como parte dessa operação.

  • Opcional: é altamente recomendável reinicializar um HSM incorporado após essa operação para configurá-lo como a raiz de confiança.

  • Se um dispositivo de entrada de PIN (PED) remoto foi usado, ele precisa ser reconectado após a conclusão.

  • Essa operação pode levar até 15 minutos. Verifique se você tem um backup de energia.

6.6.2. Desativar o módulo de segurança de hardware

Se o sistema foi ativado anteriormente usando um HSM, siga estas etapas antes de redefinir os sistemas ONTAP. Se isso não for feito, os discos e o sistema poderão ser bloqueados. Execute os seguintes comandos no cluster ONTAP:

  1. Defina o nível de privilégio como avançado:

    set -privilege advanced

  2. Liste a chave de dados do disco e as chaves de autenticação do Federal Information Processing Standards (FIPS) que ele está usando:

    storage encryption disk show

  3. Para cada disco no sistema, defina o ID da chave de autenticação de dados e FIPS do nó de volta para o MSID padrão 0x0:

    storage encryption disk modify -disk * -fips-key-id 0x0
storage encryption disk modify -disk * -data-key-id 0x0

  4. Confirme se a operação foi bem-sucedida com o seguinte:

    storage encryption disk show-status

  5. Repita o comando show-status até receber Disks Begun == Disks Done. Essa saída significa que a operação foi concluída.

    
cluster1:: storage encryption disk show-status
            FIPS    Latest   Start               Execution   Disks   Disks Disks
Node        Support Request  Timestamp           Time (sec)  Begun   Done  Successful
-------     ------- -------- ------------------  ---------- ------ ------  ----------
cluster1    true    modify   1/18/2022 15:29:38    3           14     5         5
1 entry was displayed.

  6. Remova a configuração do gerenciador de chaves externas:

    1. Se a conexão do HSM estiver ativa, vá direto para a etapa f. Se a conexão do HSM estiver inativa, vá para a etapa b.

      cluster1::> security key-manager external show-status

    2. Acesse o modo diag executando set -priv diag.

    3. Execute o comando a seguir para mostrar todas as chaves de criptografia de volume. debug smdb table kmip_external_key_cache_mdb_v2 show.

    4. Colete a propriedade vserver-id.

    5. Execute o comando a seguir em todos os servidores de chaves para excluir as chaves: debug smdb table kmip_external_key_cache_mdb_v2 delete -vserver-id <vserver-id> -key-id * -key-server <key-server endpoint>.

    6. Exclua todos os volumes usando a interface do usuário (UI) do ONTAP ou exclua manualmente os volumes do console.

      1. Se você estiver excluindo do console, ignore os volumes raiz dos nós. Eles geralmente têm o nome vol0 e um dos nós como vserver. Em geral, não é permitido excluir volumes com um nó como vserver.

      2. Se outros volumes que não sejam vol0, da etapa anterior, não puderem ser excluídos da UI, tente usar a CLI:

        cluster1::> vol offline -volume volume_to_be_deleted -vserver vserve-id
cluster1::> vol delete -volume volume_to_be_deleted -vserver vserver-id

      3. Para fazer login em um cluster de armazenamento na UI, extraia o nome de usuário e a senha do secret com os comandos a seguir, substituindo CELL_ID pelo ID exclusivo da célula que você está instalando:

        kubectl get secret -n gpc-system ontap-CELL_ID-stge-clus-01-credential -o jsonpath='{.data.netapp_username}' | base64 --decode
kubectl get secret -n gpc-system ontap-CELL_ID-stge-clus-01-credential -o jsonpath='{.data.netapp_password}' | base64 --decode

        Em seguida, acesse Volumes, selecione todos e clique em Excluir. É preciso repetir várias vezes para cada página. Observação: você pode ignorar com segurança um erro de falha na exclusão de um volume. Consulte a base de conhecimento da NetApp para mais detalhes.

        ag-stge-clus-01::*> vol show
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
ag-ad-stge01-01 vol0   aggr0_ag_ad_stge01_01 online RW 151.3GB    84.97GB   40%
ag-ad-stge01-02 vol0   aggr0_ag_ad_stge01_02 online RW 151.3GB    86.69GB   39%
ag-ad-stge02-01 vol0   aggr0_ag_ad_stge02_01 online RW 151.3GB    83.62GB   41%
ag-ad-stge02-02 vol0   aggr0_ag_ad_stge02_02 online RW 151.3GB    85.97GB   40%
ag-ad-stge03-01 vol0   aggr0_ag_ad_stge03_01 online RW 151.3GB    89.19GB   37%
ag-ad-stge03-02 vol0   aggr0_ag_ad_stge03_02 online RW 151.3GB    88.74GB   38%

    7. Depois de excluir todos os volumes, execute o comando a seguir para limpar a recovery-queue: recovery-queue purge-all -vserver <vserver>.

    8. Execute o comando a seguir para excluir o gerenciador de chaves externo: clusterl::> security key-manager external remove-servers -vserver <CLUSTER_NAME> -key-servers <IP1:PORT,IP2:PORT,...>. Depois dessa etapa, você pode receber o seguinte erro:

      Error: command failed: The key server at "172.22.112.192" contains authentication keys that are
     currently in use and not available from any other configured key server.

      Esse erro indica que há chaves restantes. Para excluir as chaves restantes, siga estas etapas:

    9. Para listar as chaves restantes, execute o seguinte comando:

      security key-manager key query

      A resposta será semelhante a:

                     Node: ag-ad-stge01-01
            Vserver: ag-stge-clus-01
        Key Manager: 172.22.112.192:5696
   Key Manager Type: KMIP
 Key Manager Policy: -
Key Tag                               Key Type Encryption   Restored
------------------------------------  -------- ------------ --------
ag-ad-stge01-01                       NSE-AK   AES-256      true
    Key ID: 00000000000000000200000000000100454007f1854b3e3f5c90756bc5cfa6cc0000000000000000

    10. Anote o valor do ID da chave da saída anterior. Use o comando security key-manager key delete -key-id + o valor do ID da chave para excluir as chaves restantes:

      security key-manager key delete -key-id 00000000000000000200000000000100454007f1854b3e3f5c90756bc5cfa6cc0000000000000000

    11. Repita as etapas i e j para excluir as chaves restantes. Quando você terminar, a saída será semelhante ao exemplo a seguir:

      ag-stge-clus-01::*> security key-manager key query
No matching keys found.

      6.6.3. Redefinir nós do ONTAP

Para redefinir nós do ONTAP:

  1. Reinicie o nó para acessar o menu de inicialização usando o comando system node reboot no prompt do sistema. Observação: você pode ignorar os avisos de reinicialização do sistema com segurança.

    Exemplos:

    ag-stge-clus-01::> system reboot -node ag-ad-stge03-02
Warning: Are you sure you want to reboot node "ag-ad-stge03-02"? {y|n}: y
Error: Could not migrate LIFs away from node: Failed to migrate one or more LIFs away from node "ag-ad-stge03-02". Use the "network interface show -curr-node ag-ad-stge03-02" command to
        identify LIFs that could not be migrated off that node. Use the "network interface migrate" command to manually migrate the LIFs off the node.
        Reissue the command with "-skip-lif-migration-before-reboot" to skip the migration and continue with takeover.
ag-stge-clus-01::> system reboot -node ag-ad-stge03-02 -skip-lif-migration-before-reboot
Warning: Are you sure you want to reboot node "ag-ad-stge03-02"? {y|n}: y
Connection to 172.22.115.134 closed.

    ag-stge-clus-01::> system reboot -node ag-ad-stge02-02
Error: command failed: Taking node "ag-ad-stge02-02" out of service might result in a data service failure and client disruption for the entire cluster. If possible, bring an additional node
   online to improve the resiliency of the cluster and to ensure continuity of service. Verify the health of the node using the "cluster show" command, then try the command again, or
   provide "-ignore-quorum-warnings" to bypass this check.
ag-stge-clus-01::> system reboot -node ag-ad-stge02-02  -ignore-quorum-warnings
Warning: Are you sure you want to reboot node "ag-ad-stge02-02"? {y|n}: y
Error: Could not migrate LIFs away from node: Failed to migrate one or more LIFs away from node "ag-ad-stge02-02". Use the "network interface show -curr-node ag-ad-stge02-02" command to
       identify LIFs that could not be migrated off that node. Use the "network interface migrate" command to manually migrate the LIFs off the node.
       Reissue the command with "-skip-lif-migration-before-reboot" to skip the migration and continue with takeover.
ag-stge-clus-01::> system reboot -node ag-ad-stge02-02  -ignore-quorum-warnings -skip-lif-migration-before-reboot
Warning: Are you sure you want to reboot node "ag-ad-stge02-02"? {y|n}: y
Connection to 172.22.115.132 closed.

  2. Se você estiver no menu LOADER, digite boot_ontap para continuar com a reinicialização. Durante o processo de reinicialização, pressione Ctrl-C para mostrar o menu de inicialização quando solicitado. O nó mostra as seguintes opções para o menu de inicialização:

    (1) Normal Boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Clean configuration and initialize all disks.
(5) Maintenance mode boot.
(6) Update flash from backup config.
(7) Install new software first.
(8) Reboot node.
(9) Configure Advanced Drive Partitioning
Selection (1-9)?

  3. Selecione a opção (9) Configure Advanced Drive Partitioning. O nó mostra as seguintes opções:

    * Advanced Drive Partitioning Boot Menu Options *
*************************************************
(9a) Destroy aggregates, unpartition all disks and remove their ownership information.
(9b) Clean configuration and initialize node with partitioned disks.
(9c) Clean configuration and initialize node with whole disks.
(9d) Reboot the node.
(9e) Return to main boot menu.
(9f) Remove disk ownership.

  4. Selecione a opção 9a e digite no quando for solicitada a rescisão. O nó mostra a seguinte opção novamente após 9a:

     (9a) Unpartition all disks and remove their ownership information.
 (9b) Clean configuration and initialize node with partitioned disks.
 (9c) Clean configuration and initialize node with whole disks.
 (9d) Reboot the node.
 (9e) Return to main boot menu.
 ```

  5. Execute a operação 9a para todos os nós de armazenamento no cluster antes de continuar.

  6. Para cada nó, execute a opção 9b e digite yes para confirmar.

    (9a) Unpartition all disks and remove their ownership information.
(9b) Clean configuration and initialize node with partitioned disks.
(9c) Clean configuration and initialize node with whole disks.
(9d) Reboot the node.
(9e) Return to main boot menu.

    1. Se houver um par de alta disponibilidade, a seguinte mensagem será exibida. Verifique se todos os nós do cluster concluíram a etapa 9a antes de executar a etapa 9b.

      Selection (9a-9f)?: 9b
9b
Option (9a) MUST BE COMPLETED on BOTH nodes in an HA pair (and DR/DR-AUX partner nodes if applicable)
prior to starting option (9b).
Has option (9a) been completed on all the nodes (yes/no)? yes
yes

  7. Quando a mensagem Welcome to the cluster setup wizard aparecer, a redefinição estará concluída.

6.7. Redefinir o Thales k570

Para redefinir o Thales k570, comece com a redefinição de fábrica do CipherTrust Manager e siga com a redefinição do próprio HSM Luna.

6.7.1. Redefinição de fábrica do sistema

  1. Crie um diretório de trabalho temporário para as credenciais do HSM:

    TMPPWDDIR=/run/user/$(id --user)/hsm
mkdir -p $TMPPWDDIR
chmod 700 $TMPPWDDIR

  2. Estabeleça uma conexão SSH com o HSM:

    export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $TMPPWDDIR/hsm-ssh-privatekey
chmod 0600 $TMPPWDDIR/hsm-ssh-privatekey
ssh -i $TMPPWDDIR/hsm-ssh-privatekey ksadmin@$HSM_MGMT_IP

    Se isso não for possível, conecte usando um cabo serial do computador à porta do console. Execute o comando a seguir em outra guia para receber a senha do ksadmin.

    export KSADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[]metadata.name | tr -d '"' | grep "ksadmin"`
kubectl get secret $KSADMIN_SECRET_NAME \
 --namespace=hsm-system \
 --output jsonpath='{.data.password}' \
  | base64 --decode

    Depois de fazer login na porta serial, você vai ver um prompt de login. Digite o nome de usuário como ksadmin e cole a senha do comando anterior.

  3. Antes de executar o comando factory-reset:

    • Evite reiniciar o sistema durante esse período, já que a reconexão envolve uma reinicialização de vários sistemas e não pode ser desfeita.

    • Verifique se você tem um backup de energia.

    Execute o comando a seguir para fazer a redefinição de fábrica:

    sudo /opt/keysecure/ks_reset_to_factory.sh

    O processo de redefinição leva cerca de 10 minutos para ser concluído.

6.7.2. Redefinição do HSM Luna

A redefinição de configuração original do sistema não limpa a raiz de confiança dos HSMs. Execute os comandos a seguir para redefinir o HSM Luna:

  1. No host do CipherTrust Manager, por SSH ou console serial, execute o seguinte comando:

    /usr/safenet/lunaclient/bin/lunacm

    lunacm:> hsm factoryReset

  2. Exclua o diretório de trabalho temporário do bootstrap:

    rm $TMPPWDDIR

6.8. Redefinir firewalls

Para instruções sobre como redefinir os firewalls para as configurações originais, consulte Redefinição de fábrica do firewall.

6.9. Redefinir switches da Cisco

Siga estas etapas para redefinir os switches da Cisco. Essas instruções também se aplicam a chaves de armazenamento, como stgesw.

  1. Faça login nos switches.

  2. Escreva, apague e recarregue as chaves:

    write erase
reload

  3. Se as chaves foram configuradas anteriormente e você tem um diretório cellcfg disponível, siga Limpeza de pré-voo.

  4. Verifique se os switches estão no provisionamento automático de energia (POAP, na sigla em inglês).

    Se a chave for redefinida corretamente, o seguinte comando vai aparecer ao se conectar a ela usando o servidor do console:

    Abort Power On Auto Provisioning [yes - continue with normal setup, skip - bypass password and basic configuration, no - continue with Power On Auto Provisioning] (yes/skip/no)[no]:

6.10. Outros recursos sobre o processo de redefinição

Para mais informações sobre o processo de redefinição, consulte os seguintes recursos:

  • https://docs.netapp.com/us-en/ontap/system-admin/manage-node-boot-menu-task.html
  • https://docs.netapp.com/us-en/ontap/encryption-at-rest/return-seds-unprotected-mode-task.html