Configurazione di `multipath.conf` per Netezza Performance Server con nodi connettore

Opzioni di distribuzione: Netezza Performance Server per Cloud Pak for Data System

Cloud Pak for Data System 2.0.2.0 è la prima release che viene fornita con una versione di Red Hat OpenShift con supporto di produzione per la configurazione di multipath con il sistema online.

Imparare a configurare multipath.conf se si è su Cloud Pak for Data System 2.0.2.0 o successivo per Netezza Performance Server per apportare modifiche alla configurazione.

Nelle versioni precedenti si modificavano i file di configurazione con ssh e vi. Con Cloud Pak for Data System 2.0.2.0 e successivi, viene introdotta una nuova procedura perché Red Hat OpenShift 4.X con Red Hat CoreOS non consente la modifica dei file di configurazione direttamente sui nodi e richiede invece l'uso degli aggiornamenti di machineconfig.

Prima di iniziare

Cloud Pak for Data System 2.0.X con nodi connettore è preconfigurato con le impostazioni multipath per due famiglie di prodotti IBM che sono comunemente testati e utilizzati con Cloud Pak for Data System 2.0.X. Le famiglie sono:

IBM FlashSystem
IBM Storwize

Se si dispone di un prodotto di archiviazione appartenente a queste famiglie, potrebbe non essere necessario configurare il file multipath.conf.

Raccogliere le impostazioni multipath richieste per quel prodotto di archiviazione e verificare se vendor e product corrispondono alle seguenti impostazioni.

Se vendor e product corrispondono, saltare questa procedura.

devices {
    device {
        vendor "IBM"
        product "FlashSystem-9840"
        path_selector "service-time 0"
        path_grouping_policy multibus
        path_checker tur
        rr_min_io_rq 4
        rr_weight uniform
        no_path_retry fail
        failback immediate
    }
    device {
         vendor "IBM"
         product "2145"
         path_grouping_policy "group_by_prio"
         path_selector "service-time 0"
         prio "alua"
         path_checker "tur"
         failback "immediate"
         no_path_retry fail
         rr_weight uniform
         rr_min_io_rq "1"
    }
}

Informazioni su questa attività

Durante la procedura, nel passaggio 5, Netezza Performance Server viene interrotto per 1-2 ore perché viene applicata una nuova configurazione e i nodi designati per i pod host di Netezza Performance Server vengono riavviati.

È possibile completare i passaggi da 1 a 4 in qualsiasi momento prima di dover arrestare Netezza Performance Server.

Suggerimento: se si utilizza attivamente l'istanza in produzione, pianificare la configurazione in anticipo per tenere conto dell'interruzione del sistema (circa 2 ore).

Procedura

Raccogliere e salvare le impostazioni del dispositivo multipath specifiche del fornitore in un file di testo da un sistema Mako o da un altro PureData System for Analytics esistente.
- Se si dispone già di un sistema PureData System for Analytics o di un'altra famiglia di sistemi a cui fare riferimento, le informazioni si trovano nel file /etc/multipath.conf che funzionava con l'apparecchiatura SAN desiderata o con la stessa famiglia di apparecchiature SAN.
- Se le informazioni non sono disponibili, raccogliere le impostazioni di multipath necessarie o consigliate dalla documentazione del fornitore o da un suo contatto.
Preparare una directory di lavoro per la procedura:
1. ssh a e1n1.
```
ssh e1n1
```
2. Creare una directory /root/multipath_work.
```
mkdir -p /root/multipath_work
```
3. Cambiare le directory in /root/multipath_work.
```
cd /root/multipath_work
```
Modificare il file newmultipath.conf :
1. Creare una copia del file /etc/multipath.conf.
```
cp /etc/multipath.conf /root/multipath_work/newmultipath.conf
```
  newmultipath.conf specifica il nome di un file temporaneo utilizzato per la modifica.
2. Aprire il file newmultipath.conf in un editor.
```
vi /root/multipath_work/newmultipath.conf
```
3. Nella sezione Devices, aggiungere un device che rappresenti le impostazioni consigliate dal fornitore di storage SAN.
  Importante:
  Non rimuovere nulla dal file. Aggiungete la struttura device dopo le strutture esistenti nella sezione Devices.
4. Codificare le modifiche in modo da poter utilizzare le informazioni nelle fasi successive.
```
base64 /root/multipath_work/newmultipath.conf | tr -d \\n > /root/multipath_work/base64multipath1.txt
```

Modificare il file /root/multipath_work/multipath-mcp.yaml :

Aprire un nuovo file chiamato multipath-mcp.yaml con l'editor vi e accedere alla modalità di inserimento.
```
vi /root/multipath_work/multipath-mcp.yaml
```

Copiate e incollate nel file le seguenti informazioni.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: nps-shared
  name: nps-shared-multipathing
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
         source: data:text/plain;charset=utf-8;base64,<--multipath_conf_file_data_base64_encoded-->
        filesystem: root
        mode: 420
        path: /etc/multipath.conf
    systemd:
      units:
      - name: iscsid.service
        enabled: true
      - name: multipathd.service
        enabled: true

Sostituire la sezione <--multipath_conf_file_data_base64_encoded--> con il contenuto del file /root/multipath_work/base64multipath1.txt.
Uscire dalla modalità di inserimento e scrivere-quit per salvare il file e uscire dalla sessione vi.

Arrestare Netezza Performance Server :

oc -n NPS_NAMESPACE exec -it pod/ipshost-0 -c ipshost -- bash

```
su - nz
```
```
nzstop
```
```
exit
```
```
exit
```

oc -n NPS_NAMESPACE scale sts/ipshost --replicas=0

Netezza Performance Server viene interrotto e si torna a e1n1.

Disattivare il pool nps-shared machineconfig in modo che i passaggi futuri non si blocchino.

oc patch mcp nps-shared --type json --patch '[{"op": "replace", "path": "/spec/paused", "value": false}]'

Esempio:

oc patch mcp nps-shared --type json --patch '[{"op": "replace", "path": "/spec/paused", "value": false}]'
machineconfigpool.machineconfiguration.openshift.io/nps-shared patched

Avviare la riconfigurazione del multipath.
```
oc create -f /root/multipath_work/multipath-mcp.yaml
```
Questo comando innesca un riavvio continuo, chiamato machineconfig update e gestito da Red Hat OpenShift. Il riavvio avviene in un ordine non deterministico tra i nodi del pool nps-shared, compreso il nodo connettore.

Monitorare il riavvio fino a quando tutti i campi della colonna UPDATED mostrano True.

oc get mcp

Il riavvio potrebbe richiedere 5-15 minuti per ogni nodo del pool nps-shared.

Esempio:

Innanzitutto, lo stato cambia in UPDATING = True e il ruolo del nodo nps-shared cambia in SchedulingDisabled.

oc get mcp
NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-d8537132ffb6d789ce8b2a7257833bf9       True      False      False      3              3                   3                     0                      14d
nps-shared   rendered-nps-shared-053d2105bc50eeb67b4cb50614e9a0da   False     True      False       3              0                   0                     0                      8d
unset        rendered-unset-442d08db52ce65c62d60b906718744f6        True      False      False      0              0                   0                     0                      14d
worker       rendered-worker-442d08db52ce65c62d60b906718744f6       True      False      False      3              3                   3                     0                      14d

oc get nodes
NAME                STATUS   ROLES               AGE   VERSION
e1n1-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n2-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n3-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n4.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n1.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n2.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n3.fbond          Ready    nps-shared,worker   14d   v1.21.8+ee73ea2
e2n4.fbond          Ready,SchedulingDisabled  nps-shared,worker   14d   v1.21.8+ee73ea2
e5n1.fbond          Ready    nps-shared,worker   13d   v1.21.8+ee73ea2

Successivamente, lo stato del nodo nps-shared cambia in NotReady :

oc get nodes
NAME                STATUS   ROLES               AGE   VERSION
e1n1-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n2-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n3-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n4.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n1.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n2.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n3.fbond          Ready    nps-shared,worker   14d   v1.21.8+ee73ea2
e2n4.fbond          NotReady,SchedulingDisabled    nps-shared,worker   14d   v1.21.8+ee73ea2
e5n1.fbond          Ready    nps-shared,worker   13d   v1.21.8+ee73ea2

Poi, lo stato torna a Ready :

[root@gdlyos18 ~]# oc get nodes
NAME                STATUS   ROLES               AGE   VERSION
e1n1-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n2-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n3-master.fbond   Ready    master              14d   v1.21.8+ee73ea2
e1n4.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n1.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n2.fbond          Ready    worker              14d   v1.21.8+ee73ea2
e2n3.fbond          Ready    nps-shared,worker   14d   v1.21.8+ee73ea2
e2n4.fbond          Ready,SchedulingDisabled    nps-shared,worker   14d   v1.21.8+ee73ea2
e5n1.fbond          Ready    nps-shared,worker   13d   v1.21.8+ee73ea2

Il ciclo si ripete per gli altri nodi del pool nps-shared.

Al termine dell'aggiornamento, UPDATING cambia in False :

oc get mcp
NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-d8537132ffb6d789ce8b2a7257833bf9       True      False      False      3              3                   3                     0                      14d
nps-shared   rendered-nps-shared-053d2105bc50eeb67b4cb50614e9a0da   True      False      False      3              3                   3                     0                      8d
unset        rendered-unset-442d08db52ce65c62d60b906718744f6        True      False      False      0              0                   0                     0                      14d
worker       rendered-worker-442d08db52ce65c62d60b906718744f6       True      False      False      3              3                   3                     0                      14d

SSH al nodo connettore e verificare le impostazioni di multipath.

Importante:
Non modificate alcun file durante una sessione di ssh. Se si desidera modificare i file, è necessario eseguire gli aggiornamenti di machineconfig.

Cloud Pak for Data System 2.0.X funziona su Red Hat OpenShift 4.X con Red Hat CoreOS come sistema operativo per i nodi. Con CoreOS, il file system principale e tutti i file di configurazione sono immutabili. Tutte le modifiche apportate manualmente durante una sessione di ssh vengono cancellate automaticamente da CoreOS in momenti imprevedibili.

Inoltre, qualsiasi modifica apportata durante una sessione di ssh potrebbe causare una mancata sincronizzazione del sistema operativo con lo stato del cluster Red Hat OpenShift e impedire il completamento di operazioni future (ad esempio, gli aggiornamenti di Cloud Pak for Data System ).
- Se il nodo connettore è e5n1.fbond
  1. Su Cloud Pak for Data System, da e1n1, ssh in e5n1.fbond
```
ssh core@e5n1
```
  2. ```
  sudo su
```
3. Verificare che le impostazioni siano state modificate correttamente:
```
  cat /etc/multipath.conf
```
  Assicurarsi che tutte le LUN configurate per l'uso siano presenti nell'output del comando multipath -ll e che tutti i percorsi siano Active Ready Running.
  multipath -ll
  Suggerimento:
  Se non si vedono i dispositivi multipath, verificare i seguenti elementi:
  
  Le LUN sono configurate correttamente e hanno accesso ai WWN delle schede Fibre Channel sul nodo connettore.
  
  Le connessioni FC sono cablate fisicamente tra il dispositivo di archiviazione SAN e lo switch o gli switch SAN e tra lo switch o gli switch SAN e il nodo o i nodi connettore.
  
  Le porte pertinenti degli switch SAN sono abilitate e mostrano un collegamento.
  
  Le impostazioni di multipath, in particolare path_checker, sono corrette.
  
  In caso di problemi, contattare l'assistenza IBM e i fornitori delle apparecchiature SAN di proprietà del cliente.

Mettere in pausa il pool nps-shared machineconfig per riportarlo allo stato desiderato.

Il pool nps-shared è in pausa, ad eccezione di alcuni momenti selezionati, per evitare un'interruzione involontaria.

oc patch mcp nps-shared --type json --patch '[{"op": "replace", "path": "/spec/paused", "value": true}]'

Esempio:

oc patch mcp nps-shared --type json --patch '[{"op": "replace", "path": "/spec/paused", "value": true}]'
machineconfigpool.machineconfiguration.openshift.io/nps-shared patched

Riavviare Netezza Performance Server :
1. ```
oc -n NPS_NAMESPACE scale sts/ipshost --replicas=1
```
  Attendere la nascita del pod ipshost e verificare che sia su un nodo connettore. Se il pod non si alza entro 5 minuti, verificare che non vi siano problemi.
```
watch "oc -n NPS_NAMESPACE get pods -o wide | grep ipshost"
```
2. ```
oc -n NPS_NAMESPACE exec -it pod/ipshost-0 -c ipshost -- bash
```

Operazioni successive

Distribuzione delle impostazioni di backup e ripristino

Configurazione di multipath.conf per Netezza Performance Server con nodi connettore

Prima di iniziare

Informazioni su questa attività

Procedura

Operazioni successive

Configurazione di `multipath.conf` per Netezza Performance Server con nodi connettore