15. Bootstrap dell'archiviazione di oggetti

Tempo stimato per il completamento: 7 ore

Operable component owner: OBJ

Profilo delle competenze: ingegnere del deployment

15.1. Requisiti di rete

Per configurare le reti GRID, Admin e Client, consulta la seguente immagine per un diagramma di cablaggio di SG1000 e SG6060:

Configurazione del rack di storage

15.1.1. Admin Node SG1000

Devi avere almeno due nodi di amministrazione in SG1000.

Per ogni nodo amministratore, devi avere un totale di quattro indirizzi IP, uno per ciascuno dei seguenti:

  • BMC Network.
  • Admin Network.
  • Rete client.
  • Grid Network.

Devi avere tre subnet per quanto segue:

  • Admin Network.
  • BMC Network.

La rete client e la rete di distribuzione e ogni subnet devono avere una maschera di subnet di al massimo 30 bit.

15.1.2. Nodi di archiviazione SG6060 e SG6000

Devi avere almeno tre nodi di archiviazione per i modelli SG6060 e SG6000.

Per ogni nodo di archiviazione, devi avere un totale di cinque indirizzi IP, uno per ciascuno dei seguenti elementi:

  • BMC Network(mgmt).
  • Admin Network(mgmt).
  • Grid Network.
  • Storage Controller Network (mgmt). Nota: la rete del controller di archiviazione deve avere due indirizzi IP.

Devi avere due subnet per ciascuno dei seguenti elementi:

  • BMC Network.
  • Admin Network.
  • Storage Controller Network.
  • Grid Network.

La tabella seguente elenca il numero di indirizzi IP per i nodi di amministrazione e di archiviazione:

Numero di IP necessari Admin Network Rete client Rete a griglia
Nodo amministratore 2 1 1
Nodo di archiviazione 4 0 1

Devi disporre delle seguenti tre subnet:

  • Admin Network.
  • Rete client.
  • Grid Network.

Ogni subnet deve avere una subnet mask di massimo 30 bit.

15.1.3. Dettagli rete

15.1.3.1. Rete del control plane di gestione di Distributed Cloud:

La rete di gestione out-of-band (OOB) di Distributed Cloud contiene la rete Baseboard Management Controller (BMC) di Object Storage e la rete di amministrazione. La rete si connette a mgmtsw.

Devi avere l'indirizzo IP BMC OOB su ciascuno dei seguenti elementi:

  • SG1000
  • SG6000

Devi avere l'indirizzo IP di gestione OOB su ciascuno dei seguenti elementi:

  • SG1000
  • SG6000
  • SG6060

15.1.3.2. Rete del piano dati di Distributed Cloud

La rete del piano dati è costituita dall'interfaccia LIF client e dalla rete client in NetApp.

  • Segui i passaggi riportati di seguito per identificare SubnetClaim su ciascuno:

    • Endpoint API S3:
    1. Nel file cellconfig, cerca external-objectstorage-client-lif-subnet.
    2. Identifica il SubnetClaim corrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.
    • Endpoint dell'appliance di rete SG1000:

      1. Nel file cellconfig, cerca objectstorage-admin-nodes-lif-subnet.
      2. Identifica il SubnetClaim corrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.
  • Endpoint dell'appliance di rete della griglia SG6060:

    1. Nel file cellconfig, cerca objectstorage-storage-nodes-lif-subnet.
    2. Identifica il SubnetClaim corrispondente che specifica l'indirizzo IP CIDR/gateway assegnato.

15.2. preparazione

15.2.1. Raccogliere informazioni

Tempo stimato: 5-10 minuti

Prima di continuare questa sezione, assicurati che il bootstrap e la configurazione di rete completino l'istanza di Distributed Cloud e che l'operatore abbia accesso al file cellconfig più preciso o più recente disponibile oppure al bootstrap.

15.2.1.1. Raccogliere informazioni sui dispositivi hardware di archiviazione

Le istanze Distributed Cloud seguono una convenzione di denominazione fissa per identificare i dispositivi hardware nei rack. In particolare, ai seguenti dispositivi di archiviazione di oggetti:

  • Nodo di amministrazione(SG1000): <cell>-<rack>-objsadm[node-number]. Ad esempio: af-ae-objsadm01 rappresenta un nodo amministratore.
  • Nodo controller di computing dello spazio di archiviazione (SG6000-CN): <cell>-<rack>-objs[node-number]. Ad esempio: af-ae-objs01.
  • Ripiano del controller di archiviazione(E2860): <cell>-<rack>-objs[node-number]-s1. Ad esempio: af-ae-objs01-s1
  • Controller dei nodi di archiviazione(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Ad esempio: af-ae-objs01-s1-01 e af-ae-objs01-s1-02

15.2.1.2. Raccogliere informazioni sulla rete del management plane

Durante il bootstrap e la configurazione della rete, l'operatore deve creare una subnet per il piano di gestione. Il sistema di archiviazione di oggetti richiede le seguenti informazioni durante la procedura di bootstrapping:

  1. Subnet di gestione.
  2. Indirizzo IP del gateway di gestione.
  3. 16 indirizzi IP riservati nella subnet di gestione, due indirizzi IP per ogni nodo amministratore e quattro indirizzi IP per ogni nodo di archiviazione.

Trova l'indirizzo IP del gateway di gestione da SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. <cell> e <rack> sono uguali a quelli identificati nel passaggio "Raccogli informazioni sui dispositivi hardware di archiviazione" Ad esempio: 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}'

Memorizza il valore del comando in MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Raccogliere le informazioni di rete del piano dati

Prima di continuare, assicurati di aver eseguito il provisioning di tre subnet per il sistema di archiviazione degli oggetti durante il bootstrapping e la configurazione della rete.

Controlla se esistono le seguenti subnet:

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

Esegui questo comando con i nomi dei SubnetClaim:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Viene visualizzato l'output seguente:

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

Verifica se sono presenti i seguenti campi:

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

15.2.1.4. Raccogliere informazioni sulle dipendenze

Il sistema di archiviazione di oggetti si basa sui seguenti servizi e infrastrutture di base in Distributed Cloud:

  • NTP
  • Moduli di sicurezza hardware (HSM)
  • DNS

15.2.1.5. Aggiorna i campi TO-BE-FILLED

Controlla il file obj-cellobj.yaml per eventuali valori TO-BE-FILLED e aggiornali.

Esegui il comando seguente per assicurarti che il valore non esista nel file YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Rete di gestione della configurazione tramite connessione locale

Tempo stimato: 30-45 minuti

Questa sottosezione configura la rete di gestione per ogni nodo dell'appliance StorageGRID. Una volta configurata la rete di gestione, si accede ai nodi StorageGRID dal bootstrapper utilizzando l'IP nella rete di gestione.

Segui questi passaggi per tutti i dispositivi ObjectStorage:

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

Per eseguire il bootstrap dei dispositivi StorageGRID, connettiti a ogni dispositivo, inclusi due nodi di amministrazione e tre nodi di archiviazione, con un carrello di emergenza sulla porta 6 della rete di amministrazione e visita https://169.254.0.1:8443 per configurare gli indirizzi IP di amministrazione sulla rete di gestione.

  1. Collega un carrello di emergenza direttamente alla porta RJ-45 più a destra dell'appliance di servizi utilizzando un cavo Ethernet. I seguenti diagrammi mostrano la porta 6 per i nodi di amministrazione e di archiviazione come esempio:

    Porta 6 per i nodi di amministrazione

    Porta 6 per i nodi di archiviazione

  2. Apri un browser web sul carrello di emergenza.

  3. Vai a https://169.254.0.1:8443 su ogni macchina.

  4. Dalla barra dei menu di StorageGRID Appliance Installer, fai clic su Configure Networking > Link Configuration. Controlla se la rete amministrativa è attiva.

    Attiva la rete dell&#39;amministratore

  5. Per configurare l'indirizzo IP per la rete di amministrazione, seleziona Configura Networkinge > Configurazione IP.

  6. Scorri verso il basso fino alla sezione Admin Network e, in IP Assignment, seleziona Static e inserisci gli indirizzi IP di gestione corrispondenti, managementIP, per il nodo. Puoi trovare l'IP di gestione per ogni nodo nel file obj-cellobj.yaml. Ad esempio:

    • 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
      

    Imposta il gateway come MANAGEMENT_SWITCH_GATEWAY.

    L'immagine di esempio seguente mostra la configurazione per af-ae-objs01 utilizzando l'indirizzo IP di gestione allocato nel file obj-cellobj.yaml:

    Configura la rete amministrativa

  7. Fai clic su Salva e verifica se l'indirizzo IP viene aggiornato.

  8. Invia un ping all'indirizzo IP di gestione dal bootstrapper per assicurarti che sia raggiungibile.

    1. Invia un ping all'indirizzo IP di gestione dal bootstrapper per assicurarti che sia raggiungibile.
    2. Una volta che tutti i nodi hanno un indirizzo IP sulla rete di amministrazione, accedi alla GUI di installazione del nodo StorageGRID utilizzando il suo indirizzo IP di gestione.

Risoluzione dei problemi:

Se un nodo non è pingabile:

  1. Accedi all'interfaccia utente di installazione del nodo StorageGRID dal passaggio 3 precedente e controlla se sono presenti errori visualizzati in un banner di dialogo. Tenta di risolvere gli errori. Contatta gli ingegneri, se necessario.
  2. Vai a Configura rete > Configurazione IP. Verifica che la sezione Rete amministrativa corretta sia configurata con IP statico e gateway corretti. A volte, il nodo StorageGRID non registra completamente la configurazione della rete di gestione dopo la conferma.
  3. Esegui di nuovo i passaggi da 5 a 8 e verifica la rete del nodo amministratore.

Per continuare l'installazione del sistema di archiviazione degli oggetti, è necessario l'accesso alla GUI di installazione del nodo StorageGRID su ogni nodo.

15.2.3. Esegui l'upgrade di StorageGRID

Tempo stimato: 1-1,5 ore

Prima di eseguire l'upgrade di StorageGRID, controlla la versione del software StorageGRID. Vai a Avanzate > Carica software StorageGRID. Viene visualizzata la versione attuale di StorageGRID.

Controlla la versione di installazione di StorageGRID inclusa:

gdcloud artifacts tree oci | grep object-storage/os

L'output di esempio è simile al seguente:

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

La versione è taggata nell'artefatto, in questo esempio, come 11.8.0:

Archivia il valore della versione in SG_INSTALL_VERSION.

Controlla la versione del firmware StorageGRID in bundle:

gdcloud artifacts tree oci | grep object-storage/firmware

L'output di esempio è simile al seguente:

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

La versione è taggata nell'artefatto, in questo esempio, come 3.8.1:

Archivia il valore della versione in SG_FIRMWARE_VERSION.

Se la versione sul nodo non è SG_INSTALL_VERSION, continua con i passaggi successivi per eseguire l'upgrade o il downgrade della versione di installazione di StorageGRID. Se la versione attuale è SG_INSTALL_VERSION, vai alla sezione Esegui l'upgrade di SANtricity.

Controllare la versione di StorageGRID

15.2.3.1. Eseguire l'upgrade del firmware

Segui questi passaggi per tutti i nodi StorageGRID:

  • af-ae-objsadm01
  • af-ae-objsadm02
  • af-ae-objs01
  • af-ae-objs02
  • af-ae-objs03
  1. Recupera l'immagine del firmware dal bundle:

    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
    

    Il file è disponibile in storagegrid_firmware_install/.

  2. Vai a StorageGRID Appliance Installer sul nodo StorageGRID. Scegli Avanzate > Aggiorna firmware. Carica l'immagine del firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 e il checksum storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 per la versione del firmware selezionata. Dopo il caricamento, StorageGRID inizia automaticamente a convalidare i file. In genere la convalida richiede circa 5-10 minuti.

    Carica l&#39;immagine del firmware

  3. Quando vengono visualizzati due segni di spunta verdi, fai clic su Esegui l'upgrade della partizione inattiva.

    Eseguire l&#39;upgrade della partizione inattiva

    Dopo aver ricevuto il messaggio Successfully updated the firmware on the inactive partition, assicurati che la partizione inattiva sia effettivamente la versione corretta esaminando la sezione Firmware attuale.

    Fai clic su Riavvia e Scambia partizioni due volte.

  4. Dopo il riavvio del nodo, ripeti i passaggi 1 e 2 per aggiornare il firmware dell'altra partizione. La partizione attiva è la versione scelta, mentre la partizione inattiva contiene la versione precedente.

    Esegui l&#39;upgrade dell&#39;altra partizione inattiva

15.2.3.2. Eseguire l'upgrade del software StorageGRID

Una volta completato l'upgrade del firmware su tutti i nodi alla versione corretta, esegui l'upgrade del software alla versione selezionata sui due nodi di amministrazione. Non è necessario eseguire l'upgrade dei nodi di archiviazione perché imitano ed estraggono il software sui nodi di amministrazione.

Segui queste istruzioni sui nodi amministratore per SG1000:

  • af-ae-objsadm01
  • af-ae-objsadm02
  1. Recupera l'immagine di installazione dal bundle:

    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
    

    I file sono disponibili in storagegrid_os_install/.

  2. Vai a Advanced (Avanzate) -> Upload StorageGRID Software (Carica software StorageGRID). Fai clic su Rimuovi per rimuovere il software corrente e carica il nuovo pacchetto software storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb e il checksum corrispondente storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5 come mostrato di seguito:

    Carica il pacchetto StorageGRID

  3. Una volta completato il caricamento del software, assicurati che il software per il nodo sia stato aggiornato alla versione selezionata:

    Controllare la versione di StorageGRID

15.2.4. Esegui l'upgrade di SANtricity

Tempo stimato: 1-1,5 ore

Prima di eseguire l'upgrade di SANtricity, controlla la versione del software SANtricity. Vai all'interfaccia utente SANtricity e fai clic su Supporto > CENTRO AGGIORNAMENTI > Inizia aggiornamento. Viene visualizzata la versione attuale di SANtricity.

Controlla la versione di installazione di SANtricity inclusa:

gdcloud artifacts tree oci | grep object-storage/santricity

L'output di esempio è simile al seguente:

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

La versione è taggata nell'artefatto, in questo esempio, come 11.70.5R1.

Archivia il valore della versione in SANTRICITY_OS_VERSION.

Se la versione di SANtricity è precedente a SANTRICITY_OS_VERSION, continua con i passaggi successivi per eseguire l'upgrade della versione del sistema operativo SANtricity. In caso contrario, vai a Installazione.

Controllare la versione di SANtricity

15.2.4.1. Esegui l'upgrade di SANtricity OS

Segui queste istruzioni nell'interfaccia utente SANtricity per ogni nodo di archiviazione:

  1. Recupera l'immagine di installazione dal bundle:

    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
    

    Il file di upgrade è disponibile in santricity/SANTRICITY_OS_VERSION/.

  2. Vai a Assistenza > CENTRO AGGIORNAMENTI. Fai clic su Inizia l'upgrade da Aggiornamento software del sistema operativo SANtricity. Seleziona il file del software SANtricity OS facendo clic su Sfoglia. Carica il nuovo pacchetto software RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp come mostrato:

    Carica pacchetto SANtricity

  3. Fai clic su Avvia e conferma di voler eseguire l'operazione.

  4. Al termine dell'upgrade, verifica che la versione sia stata aggiornata:

    Controllare la versione di SANtricity

15.3. Installazione

15.3.1. crea i Secret

Tempo stimato: 15-30 minuti

Per ottenere i valori per la creazione dei secret, utilizza la directory cellcfg:

  1. Recupera i nomi di 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}'
    

    Esempio di output:

    # 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. Recupera l'indirizzo IP BMC per il nodo di archiviazione:

    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. Accedi a SANtricity System Manager dal link nell'output del comando precedente. Se non hai impostato la password in precedenza, crea una password ed esegui l'accesso:

    Accedi a SANtricity System Manager.

    1. Se la password di SANtricity è stata persa, reimpostala tramite la console seriale StorageGRID E2860. Per connetterti alla porta seriale dell'array di dischi E2860, le impostazioni del terminale sono 115200 8N1.
  4. Configura gli indirizzi del server NTP in SANtricity System Manager per entrambi i controller:

    Configura gli indirizzi dei server NTP

    1. Recupera gli indirizzi del server NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      
    2. Seleziona Hardware in SANtricity System Manager.

    3. Se la grafica mostra le unità, fai clic su Mostra retro del supporto. L'immagine cambia e mostra i controller anziché le unità.

    4. Fai clic sul controller che vuoi configurare. Viene visualizzato il menu contestuale del controller.

    5. Seleziona Configura server NTP. Si apre la finestra di dialogo Configura server Network Time Protocol (NTP).

    6. Seleziona Voglio attivare NTP sul controller (A o B). Nella finestra di dialogo vengono visualizzate altre selezioni.

    7. Seleziona Specifica manualmente gli indirizzi del server NTP. Inserisci l'indirizzo del server NTP principale utilizzando uno degli IP recuperati dal comando precedente.

    8. Fai clic su Salva.

  5. Aggiorna i secret che contengono le credenziali SANtricity per ciascuno dei nodi di archiviazione nel file cell.yaml. Se i secret non esistono, aggiungili seguendo questo modello:

    apiVersion: v1
    kind: Secret
    metadata:
      creationTimestamp: null
      name: <STORAGE_NODE_NAME>-santricity
      namespace: gpc-system
    stringData:
      password: 'PASSWORD'
      username: 'admin'
    type: Opaque
    
  6. Crea i secret per ciascuno dei nodi di archiviazione elencati nel passaggio precedente:

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

Convalida:

  1. Esegui il comando seguente con ogni nodo di archiviazione elencato nel passaggio precedente. Stampa il nome utente Santricity impostato nel passaggio precedente. Convalida l'amministratore:

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
    
  2. Esegui il comando seguente con ogni nodo di archiviazione elencato nel passaggio precedente. Viene stampata la password di Santricity:

    kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
    
  3. Esegui questo comando per ottenere l'URL della GUI di gestione Santricity. Accedi a Santricity utilizzando il nome utente e la password:

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

Risoluzione dei problemi:

Se i secret non vengono trovati durante l'esecuzione del passaggio di convalida 1 o 2, esegui di nuovo il passaggio kubectl create secret.

Se non riesci ad accedere alla GUI di gestione Santricity:

  1. Reimposta le credenziali di amministratore tramite la console seriale StorageGRID E2860.
  2. Esegui tutti i passaggi precedenti tranne l'ultimo.
  3. Elimina il secret Santricity esistente di ogni nodo:

    kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
    
  4. Esegui l'ultimo passaggio per ricreare il secret Santricity.

15.3.2. Bootstrap Object Storage

Il processo di bootstrapping di Object Storage varia tra la prima zona e le zone di unione. Fai riferimento alla sezione pertinente in base alla tua situazione specifica.

IMPORTANTE: prima di procedere, verifica che il bootstrapping dell'API globale della zona di ancoraggio sia terminato.

15.3.2.1. Bootstrap dell'archiviazione di oggetti nella prima zona

Esegui questo comando per avviare l'object storage:

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

15.3.2.2. Bootstrap dell'archiviazione di oggetti nella zona di unione

Risoluzione dei problemi:

  1. Quando i comandi Google Cloud CLI scadono o restituiscono errori, risolvi i problemi restituiti.
  2. Controlla il pod gpc-system/obj-infra-cluster-cm-backend-controller di accesso per ulteriori dettagli sull'errore.

15.3.2.3. Bootstrap dell'archiviazione di oggetti nella zona di unione

Tempo stimato: 30-60 minuti

Il bootstrapping di Object Storage in una zona di unione richiede il coordinamento tra i riconciliatori di Object Storage nella zona di ancoraggio e nella zona di unione. Poiché durante il bootstrapping non esiste un canale di comunicazione protetto e controllato tra due zone per i riconciliatori, l'IO deve facilitare manualmente la comunicazione protetta per i riconciliatori Object Storage tra due zone.

  1. Concedi a te stesso il ruolo predefinito Amministratore cluster nel cluster di zona root-admin e nel cluster globale nella zona di ancoraggio. Per i dettagli, consulta il runbook IAM.

In alternativa, applica questi due binding dei ruoli nella zona di ancoraggio:

Nell'API globale:

  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: fop-cluster-admin@example.com

Nel cluster di amministrazione principale:

  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: fop-cluster-admin@example.com
  1. Esegui il comando nella zona di ancoraggio per ottenere l'IP del server DNS e annotalo per un utilizzo successivo: 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. Configura il resolver stub DNS della zona di unione in modo che si colleghi alla zona di ancoraggio:

    1. Disattiva e arresta systemd-resolved sh systemctl disable systemd-resolved.service --now

    2. Elimina il file resolv.conf se esiste sh rm -f /etc/resolv.conf

    3. Scrivi l'IP del server DNS della zona di ancoraggio nel file resolv.conf della zona di unione sh vim /etc/resolv.conf Contenuto del file /etc/resolv.conf di esempio: sh nameserver 10.200.40.0

  3. Crea il file YAML TokenRequest nella zona di unione.

    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
    

    Sostituisci JOINING_ZONE_NAME con il nome della zona del questionario di acquisizione del cliente, come descritto nella nota alla fine della sezione.

  4. Trasferisci il file YAML TokenRequest nella zona di ancoraggio.

    scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
    
  5. Applica il file YAML TokenRequest al cluster globale root-admin nella zona di ancoraggio.

    kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
    
  6. Crea il file YAML del token nella zona di ancoraggio.

    gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
    
  7. Trasferisci il file YAML del token alla zona di unione.

    scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
    
  8. Applica il file YAML del token al cluster KIND nella zona di unione.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
    
  9. Crea il file YAML ObjectStorageBootstrap nella zona di ancoraggio.

    gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    
  10. Trasferisci il file YAML ObjectStorageBootstrap nella zona di unione.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    
  11. Applica il file YAML ObjectStorageBootstrap al cluster KIND nella zona di unione.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    
  12. Esegui il bootstrap dell'archiviazione di oggetti nella zona di unione.

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