16. Bootstrap für Datei- und Blockspeichercluster

Geschätzte Dauer: 3 Stunden

Eigentümer der bedienbaren Komponente: FILE

Kompetenzprofil: Bereitstellungsingenieur

Auf dieser Seite finden Sie eine Anleitung zum Einrichten von Datei- und Blockspeicher für den Cluster mit NetApp ONTAP.

16.1. ONTAP-Cluster-Switches konfigurieren

  1. Suchen Sie nach den Passwörtern switch-xx-ad-stgesw01-admin und switch-xx-ad-stgesw02-admin (sie haben denselben Wert). Wenn die Passwörter nicht vorhanden sind, initialisieren Sie die Anmeldedaten und generieren Sie ein neues zufälliges Passwort. Melden Sie sich über die Console am Switch an, um das Administratorpasswort festzulegen:

    # configure terminal
# username ADMIN_USER password PASSWORD
# exit
# copy running-config startup-config

  2. Anmeldedaten in einem Secret speichern und an cell.yaml anhängen

    apiVersion: v1
kind: Secret
metadata:
  name: netapp-ontap-cluster-switch-credential
  namespace: gpc-system
type: Opaque
stringData:
  username: ADMIN_USER
  password: PASSWORD

  3. Führen Sie den folgenden Befehl aus, um die Namen der Speicherschalter abzurufen:

    kubectl get storageswitch -n gpc-system

    Die Ausgabe sollte in etwa so aussehen:

    NAME             AGE   MANAGEMENTIP
kb-ab-stgesw01   10d   192.0.2.0
kb-ab-stgesw02   10d   192.0.2.1

    Führen Sie für jeden Switch die folgenden Schritte aus und verwenden Sie den Namen des Switches.

  4. Führen Sie den folgenden Befehl aus, um die Switch-Konfiguration aus dem switchstaticconfig-CR abzurufen:

    kubectl get switchstaticconfigs -n gpc-system $SWITCH_NAME-static-config -o yaml | /root/release/scripts/yq_linux_amd64 '.spec.config'

    Die Ausgabe sollte in etwa so aussehen:

    banner motd !
******************************************************************************
* NetApp Reference Configuration File (RCF)
*
* Switch   : Nexus N9K-C9336C-FX2
* Filename : Nexus-9336C-RCF-v1.8-Cluster.txt
* Date     : 11-01-2021
* Version  : v1.8
*
* Port Usage:
* Ports  1- 3: Breakout mode (4x10G) Intra-Cluster/HA Ports, int e1/1/1-4, e1/2/1-4, e1/3/1-4
* Ports  4- 6: Breakout mode (4x25G) Intra-Cluster/HA Ports, int e1/4/1-4, e1/5/1-4, e1/6/1-4
* Ports  7-34: 40/100GbE Intra-Cluster/HA Ports, int e1/7-34
* Ports 35-36: Intra-Cluster ISL Ports, int e1/35-36
*
* Dynamic breakout commands:
* 10G: interface breakout module 1 port <range> map 10g-4x
* 25G: interface breakout module 1 port <range> map 25g-4x
*
* Undo breakout commands and return interfaces to 40/100G configuration in config mode:
* no interface breakout module 1 port <range> map 10g-4x
* no interface breakout module 1 port <range> map 25g-4x
* interface Ethernet <interfaces taken out of breakout mode>
* inherit port-profile CLUSTER
* priority-flow-control mode auto
* service-policy type qos type input ROCE_QOS
* exit
*
* This RCF supports Clustering, HA, RDMA, and DCTCP using a single port profile.
*
******************************************************************************
!
conf t
!
interface breakout module 1 port 1-3 map 10g-4x
interface breakout module 1 port 4-6 map 25g-4x
!
feature lacp
feature lldp
feature ssh
feature sftp-server
feature scp-server
!
vlan 17,18
exit
!
cdp enable
cdp advertise v1
cdp timer 5
system default switchport
no system default switchport shutdown
snmp-server community cshm1! group network-operator
errdisable recovery interval 30
port-channel load-balance src-dst ip-l4port-vlan
no ip domain-lookup
logging console 1
!
!
class-map type qos match-any HA
match dscp 40
match cos 5
!
class-map type qos match-any RDMA
match dscp 16
match cos 2
!
class-map type qos match-any CT
match dscp 0
match cos 0
!
policy-map type qos ROCE_QOS
class type qos HA
  set qos-group 5
class type qos RDMA
  set qos-group 2
class type qos class-default
  set qos-group 0
!
class-map type network-qos HA_NETQOS
match qos-group 5
!
class-map type network-qos RDMA_NETQOS
match qos-group 2
!
class-map type network-qos CT_NETQOS
match qos-group 0
!
policy-map type queuing ROCE_QUEUING
class type queuing c-out-8q-q7
  priority level 1
class type queuing c-out-8q-q6
  bandwidth remaining percent 0
class type queuing c-out-8q-q5
  bandwidth remaining percent 43
  random-detect threshold burst-optimized ecn
class type queuing c-out-8q-q4
  bandwidth remaining percent 0
class type queuing c-out-8q-q3
  bandwidth remaining percent 0
class type queuing c-out-8q-q2
  random-detect threshold burst-optimized ecn
  bandwidth remaining percent 28
class type queuing c-out-8q-q1
  bandwidth remaining percent 0
class type queuing c-out-8q-q-default
  bandwidth remaining percent 28
  random-detect threshold burst-optimized ecn
!
policy-map type network-qos NETQOS
class type network-qos HA_NETQOS
  pause pfc-cos 5
  mtu 9216
class type network-qos RDMA_NETQOS
  pause pfc-cos 2
  mtu 9216
class type network-qos CT_NETQOS
  mtu 9216
!
system qos
service-policy type network-qos NETQOS
service-policy type queuing output ROCE_QUEUING
!
copp profile strict
!
!
!********** Port Profiles **********
!
port-profile type ethernet CLUSTER
description 10/25/40/1000GbE Intra-Cluster/HA Nodes
switchport mode trunk
switchport trunk allowed vlan 1,17-18
spanning-tree port type edge trunk
spanning-tree bpduguard enable
mtu 9216
state enabled
exit
!
!
!********** Interfaces **********
!
interface e1/1/1-4, e1/2/1-4, e1/3/1-4, e1/4/1-4, e1/5/1-4, e1/6/1-4, e1/7-34
inherit port-profile CLUSTER
priority-flow-control mode auto
service-policy input ROCE_QOS
exit
!
!********** Intra-Cluster ISL ports **********
!
interface Ethernet1/35
description Intra-Cluster Switch ISL Port 1/35 (port channel)
priority-flow-control mode auto
switchport mode trunk
switchport trunk allowed vlan 1
mtu 9216
channel-group 1 mode active
no shutdown
!
interface Ethernet1/36
description Intra-Cluster Switch ISL Port 1/36 (port channel)
priority-flow-control mode auto
switchport mode trunk
switchport trunk allowed vlan 1
mtu 9216
channel-group 1 mode active
no shutdown
!
interface port-channel1
service-policy input ROCE_QOS
priority-flow-control mode auto
switchport mode trunk
switchport trunk allowed vlan 1
mtu 9216
no shutdown
!
!********** Set management ip **********
!
interface mgmt0
ip address 172.28.2.10/29
!
vrf context management
ip route 0.0.0.0/0 mgmt0 172.28.2.9
!
hostname kb-ad-stgesw01
!
end
!
!********** Save config *******
copy run start
!

  5. Stellen Sie die erhaltene Switch-Konfiguration auf dem Switch bereit, indem Sie den Inhalt über ein serielles Kabel oder einen Konsolenserver in den Switch kopieren und einfügen.

    Bei dieser Konfiguration wird von Folgendem ausgegangen:

    • A250: e0c/e0d auf dem Speichergerät ist über ein Breakout-Kabel mit Port 4–6 verbunden.
    • A400: e3a/e3b auf dem Speichergerät ist über ein 40‑GbE- oder 100‑GbE-Kabel (nicht Breakout) mit Port 7–34 verbunden.
    • A800: e0a/e1a auf dem Speichergerät ist über ein 40‑GbE- oder 100‑GbE-Kabel (nicht Breakout) mit Port 7–34 verbunden.

    Das ist aber nicht immer der Fall. In vielen Installationen ist das Speichergerät mit den Ports 4 bis 6 verbunden, auch wenn es sich um ein A400- oder A800-Gerät handelt. Wenn ein A400 oder A800 an die Ports 4–6 angeschlossen ist, passen Sie die Switch-Konfiguration an, um die folgenden Zeilen zu entfernen, bevor Sie die Konfiguration anwenden:

      interface breakout module 1 port 1-3 map 10g-4x
  interface breakout module 1 port 4-6 map 25g-4x

    Ersetzen Sie dann diese Zeile:

      interface e1/1/1-4, e1/2/1-4, e1/3/1-4, e1/4/1-4, e1/5/1-4, e1/6/1-4, e1/7-34

    durch diesen Codeblock:

      interface e1/1-34

    Durch diese Änderungen werden die Ports 1 bis 34 alle für 40‑GbE- oder 100‑GbE-Kabel (nicht Breakout) konfiguriert.

    Entfernen Sie außerdem die folgenden Zeilen aus dem MOTD-Bannerteil der Konfiguration, um mögliche Verwirrung in der Zukunft zu vermeiden:

    
  * Ports  1- 3: Breakout mode (4x10G) Intra-Cluster/HA Ports, int e1/1/1-4, e1/2/1-4, e1/3/1-4
  * Ports  4- 6: Breakout mode (4x25G) Intra-Cluster/HA Ports, int e1/4/1-4, e1/5/1-4, e1/6/1-4
  * Ports  7-34: 40/100GbE Intra-Cluster/HA Ports, int e1/7-34

    Ersetzen Sie diese Zeilen durch:

      * Ports  1-34: 40/100GbE Intra-Cluster/HA Ports, int e1/1-34

  6. Bestätigen Sie die CR des ManagementSwitch-Objekts.

    Sehen Sie sich das ManagementSwitch-Objekt des Bootstrap-KIND-Clusters an und suchen Sie nach der richtigen benutzerdefinierten Ressource, die den Switch darstellt, der das Speichergerät enthält. Ermitteln Sie die physischen Switchports auf dem Management-Switch, die physisch mit den Storage-Switches verbunden sind, und prüfen Sie, ob diese Verbindungen im ManagementSwitch CR in „lacpGroups“ vorhanden sind.

    Wenn beispielsweise die Verwaltungsverbindung zum Speicherswitch mit den Ports 10 und 11 des Verwaltungsswitch verbunden ist, prüfen Sie, ob die folgenden Informationen vorhanden sind:

    kind: ManagementSwitch
spec:
  ...
  serverNetwork:
    ...
    lacpGroups:
    - - 10
    - - 11

    Verwenden Sie den folgenden Befehl, um die lacpGroups abzurufen:

    kubectl get ManagementSwitchinternal <switch-name> --namespace=gpc-system -o=jsonpath='{.spec.serverNetwork.lacpGroups}'

    Eine Beispielausgabe sollte so aussehen, damit Sie bestätigen können, dass die Ports vorhanden sind:

    [[1],[2],[3],[4],[5],[6]]

16.2. ONTAP-Appliances initialisieren

Wiederholen Sie die folgenden Schritte für jeden Controller auf den AFF250/400/800-Systemen. Jedes System hat zwei Steuerungen oder Knoten.

  1. Verwenden Sie die serielle Konsole und den Standardnutzernamen admin, um eine Verbindung zum Speicherknoten herzustellen.

  2. Prüfen Sie die Version des NetApp ONTAP-Systems.

    • Führen Sie den Befehl version aus:
    • Die NetApp ONTAP-Systemversion muss 9.15.1 sein. Wenn die Version älter als 9.15.1 ist, führen Sie ein Upgrade der Knoten auf 9.15.1 durch, bevor Sie den Administratorcluster der Organisation booten. Weitere Informationen finden Sie im Upgrade-Leitfaden.

  3. Legen Sie die IP-Adressen der IP-Schnittstelle für die Clusterverbindung fest.

    Suchen Sie zuerst in der cellcfg nach dem erwarteten .spec.network.clusterInterconnectIP-Wert für die aktuelle StorageNode.

    # Note, this command relies on yq, which can be downloaded from https://github.com/mikefarah/yq.
# If you do not want to install yq, you can manually inspect cellcfg/*-storage.yaml to determine the IPs.
cat cellcfg/*-storage.yaml | /root/release/scripts/yq_linux_amd64 'select(.kind == "StorageNode") | (.metadata.name, .spec.network.clusterInterconnectIP)'

    Wenn Sie den vorherigen Befehl ausführen, werden die Namen aller StorageNodes und ihre .spec.network.clusterInterconnectIP-Werte ausgegeben. Beispiel:

    aa-ad-stge01-01
169.254.0.1
---
aa-ad-stge01-02
169.254.0.3
---
aa-ad-stge02-01
169.254.0.5
---
aa-ad-stge02-02
169.254.0.7
---
aa-ad-stge03-01
169.254.0.9
---
aa-ad-stge03-02
169.254.0.11

    Im vorherigen Beispiel werden für den Knoten aa-ad-stge03-01 in den folgenden Schritten die IPs 169.254.0.9 und 169.254.0.10 verwendet. Das liegt daran, dass 169.254.0.9 die in der cellcfg für den Knoten aa-ad-stge03-01 definierte IP-Adresse ist und 169.254.0.10 die nächste IP-Adresse (numerisch) nach 169.254.0.9 ist.

    Prüfen Sie als Nächstes die tatsächlichen Cluster-Interconnect-IP-Werte für den aktuellen Knoten.

    network interface show

    Es sollten zwei Netzwerkschnittstellen angezeigt werden, die mit 169.254 beginnen, ähnlich wie in der folgenden Ausgabe:

    ::> net int show
   (network interface show)
             Logical    Status     Network            Current       Current Is
 Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
 ----------- ---------- ---------- ------------------ ------------- ------- ----
 Cluster
             clus1        up/up    169.254.19.166/16  localhost     e3a     true
             clus2        up/up    169.254.19.167/16  localhost     e3b     true

    Wenn die Adresse für die clus1-Schnittstelle mit dem in der cellcfg definierten Wert übereinstimmt und die Adresse für die clus2-Schnittstelle die nächste IP-Adresse nach der clus1-Adresse ist (numerisch), können Sie den Rest dieses Schritts überspringen und mit dem nächsten Schritt fortfahren.

    Wenn Sie nur eine Schnittstelle für den Cluster-VServer sehen, führen Sie net port show aus, um zu prüfen, ob der zweite Port aktiv ist. Wenn das der Fall ist, haben Sie eine der Schnittstellen übersehen. Sie haben zwei Möglichkeiten, das Problem zu beheben:

    • Option 1: Fügen Sie die Interconnect-IP mit dem folgenden Befehl manuell hinzu:

        net interface create -vserver Cluster -lif clus2 -role cluster -address <interconnect-ip> -netmask 255.255.0.0 -home-node localhost -home-port <port>

      • interconnect-ip: Wählen Sie die nächste IP-Adresse (numerisch) nach der Cluster-Interconnect-IP aus, die in der cellcfg für den aktuellen Knoten angegeben ist. Wenn die im cellcfg für den aktuellen Knoten angegebene IP-Adresse für die Clusterverbindung beispielsweise 169.254.0.3 ist, wählen Sie 169.254.0.4 aus.

      • Port: Je nach ONTAP-Modell kann der Port unterschiedlich sein. Wählen Sie den Port aus, für den in der vorherigen Ausgabe keine Schnittstelle angezeigt wird.

        • Für A250: Wählen Sie zwischen e0c und e0d aus.
        • Für A400: Wähle zwischen e3a und e3b aus.
        • A800: Wählen Sie zwischen e0a und e1a aus.

    • Option 2: Zurücksetzen des ONTAP-Knotens auf die Werkseinstellungen (dazu sind die Konfigurationen 9a und 9b im ONTAP-Bootmenü erforderlich). Führen Sie den Befehl nach dem Zurücksetzen noch einmal aus, um zu prüfen, ob zwei IPs vorhanden sind. Wir empfehlen, zuerst Option 1 auszuprobieren und nur dann auf Option 2 zurückzugreifen, wenn etwas nicht richtig funktioniert.

    Aktualisieren Sie als Nächstes die clus1-Verbindungs-IP auf den clusterInterconnectIP-Wert, der für den aktuellen Knoten in der cellcfg angegeben ist.

    net int modify -vserver Cluster -lif clus1 -address <interconnect-ip>
    • interconnect-ip: Der clusterInterconnectIP-Wert, der in der cellcfg für den aktuellen Knoten angegeben ist.

    Aktualisieren Sie als Nächstes die clus2-Interconnect-IP auf die nächste IP-Adresse (numerisch) nach dem clusterInterconnectIP-Wert, der für den aktuellen Knoten in der cellcfg angegeben ist.

    net int modify -vserver Cluster -lif clus2 -address <next-interconnect-ip>
    • next-interconnect-ip: Wählen Sie die nächste IP-Adresse (numerisch) nach der Cluster-Interconnect-IP aus, die in der cellcfg für den aktuellen Knoten angegeben ist. Wenn beispielsweise die in der cellcfg für den aktuellen Knoten angegebene IP-Adresse für die Clusterverbindung 169.254.0.3 ist, wählen Sie 169.254.0.4 aus.

    Prüfen Sie schließlich, ob die tatsächlichen Cluster-Interconnect-IP-Werte für den aktuellen Knoten mit den in der cellcfg erwarteten Werten übereinstimmen.

    network interface show

    Es sollten zwei Netzwerkschnittstellen angezeigt werden, die mit 169.254 beginnen, ähnlich der folgenden Ausgabe. Die Adresse für die clus1-Schnittstelle sollte mit dem in der cellcfg definierten Wert übereinstimmen. Die Adresse für die clus2-Schnittstelle sollte die nächste IP-Adresse nach der clus1-Adresse sein (numerisch).

    ::> net int show
   (network interface show)
             Logical    Status     Network            Current       Current Is
 Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
 ----------- ---------- ---------- ------------------ ------------- ------- ----
 Cluster
             clus1        up/up    169.254.0.1/16  localhost     e3a     true
             clus2        up/up    169.254.0.2/16  localhost     e3b     true

    Optional: Intercluster-Konnektivität prüfen

    ping -lif clus2 -vserver Cluster -destination <interconnect-ip-other-node>

    interconnect-ip-other-node: Wählen Sie eine Intercluster-IP von anderen Knoten aus. Wenn eine Verbindung besteht, sollte der Ping beantwortet werden.

  4. Legen Sie das Administratorpasswort fest. Es sollte auf allen Knoten identisch sein und wird verwendet, wenn Sie das Passwort eingeben. Achten Sie darauf, dass das Passwort den Komplexitätsanforderungen entspricht. Andernfalls wird eine Warnung zu nicht konformen Nutzerkonten angezeigt.

     ::> security login password

 Enter your current password: Current password is empty, press Enter
 Enter a new password: Enter NEW_PASSWORD
 Enter it again: Enter NEW_PASSWORD

  5. Legen Sie die Management-IP und das Gateway fest. Unten finden Sie eine Anleitung dazu, wie Sie die erforderlichen Informationen erhalten.

    ::> cluster setup

Type yes to confirm and continue: yes
Enter the node management interface port: e0M
Enter the node management interface IP address: IP_ADDRESS
for this node
Enter the node management interface netmask: NETMASK for
this IP
Enter the node management interface default gateway:
GATEWAY

    Beenden Sie den Einrichtungsassistenten für den Cluster, nachdem Sie das Standardgateway festgelegt haben, indem Sie ctrl+c eingeben.

    Führen Sie den folgenden Befehl aus, um die Subnetzinformationen abzurufen:

    # cat cellcfg/*-storage.yaml | /root/release/scripts/yq_linux_amd64 'select(.kind == "StorageCluster") | (.spec.network.clusterManagement.netmask)'

    Die Ausgabe sollte in etwa so aussehen:

    203.0.113.0

    Führen Sie den folgenden Befehl aus, um die Gateway-Informationen abzurufen:

    kubectl get subnetclaim -n root kb-ad-mgmtsw01-stge-os-subnet -o jsonpath={.status.ipv4SubnetStatus.gateway} ; echo

    Die Ausgabe sollte in etwa so aussehen:

    203.0.113.1

    Hier ein Beispiel für das Abrufen von IP-Informationen:

    # cat cellcfg/*-storage.yaml | /root/release/scripts/yq_linux_amd64 'select(.kind == "StorageNode") | (.metadata.name, .spec.network.managementIP)'
kb-ad-stge01-01
203.0.113.0
---
kb-ad-stge01-02
203.0.113.0
---
kb-ad-stge02-01
203.0.113.0
---
kb-ad-stge02-02
203.0.113.0

  6. Aktivieren Sie SSH für den Administratornutzer:

      security login create -user-or-group-name admin -application ssh -authentication-method password -role admin

  7. Benennen Sie den Knoten in den Namen um, der in cell.yaml angegeben ist.

    system node rename -node localhost -newname NODE_NAME

  8. Prüfen Sie, ob die Festplatten richtig konfiguriert sind.

    1. Führen Sie storage aggregate show -fields uses-shared-disks aus und prüfen Sie, ob aggr0 „true“ zurückgibt. Beispielausgabe:

      ::> storage aggregate show -fields uses-shared-disks
aggregate uses-shared-disks
--------- -----------------
aggr0     true

    2. Führen Sie run -node * sysconfig -r aus und prüfen Sie, ob Gerätenamen vorhanden sind, die mit P3 enden. So wird sichergestellt, dass die Festplatten drei Partitionen haben. Beispielausgabe:

      ::> run -node * sysconfig -r
1 entry was acted on.

Node: localhost
Aggregate aggr0 (online, raid_dp) (block checksums)
  Plex /aggr0/plex0 (online, normal, active, pool0)
    RAID group /aggr0/plex0/rg0 (normal, block checksums)

      RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)
      --------- ------  ------------- ---- ---- ---- ----- --------------    --------------
      dparity   0n.18P3 0n    0   18         0 SSD-NVM   N/A 63849/16345536    63857/16347584
      parity    0n.19P3 0n    0   19         0 SSD-NVM   N/A 63849/16345536    63857/16347584
      data      0n.20P3 0n    0   20         0 SSD-NVM   N/A 63849/16345536    63857/16347584
      data      0n.21P3 0n    0   21         0 SSD-NVM   N/A 63849/16345536    63857/16347584
      data      0n.22P3 0n    0   22         0 SSD-NVM   N/A 63849/16345536    63857/16347584

    3. Führen Sie run -node local disk show -n aus, um zu prüfen, ob die Festplattenpartitionen Not Owned sind und ob es 2 * <number of disks> Partitionen gibt. In diesem Beispiel sind 24 Partitionen ohne Eigentümer für 12 Festplatten zu sehen.

      ::> run -node local disk show -n
  DISK       OWNER                    POOL   SERIAL NUMBER         HOME                    DR HOME
------------ -------------            -----  -------------         -------------           -------------
0n.21P1      Not Owned                  NONE   S5Y0NA0T100941NP001
0n.21P2      Not Owned                  NONE   S5Y0NA0T100941NP002
0n.22P1      Not Owned                  NONE   S5Y0NA0T100944NP001
0n.22P2      Not Owned                  NONE   S5Y0NA0T100944NP002
0n.18P1      Not Owned                  NONE   S5Y0NA0T101588NP001
0n.18P2      Not Owned                  NONE   S5Y0NA0T101588NP002
0n.20P1      Not Owned                  NONE   S5Y0NA0T100947NP001
0n.20P2      Not Owned                  NONE   S5Y0NA0T100947NP002
0n.3P1       Not Owned                  NONE   S5Y0NA0T100942NP001
0n.3P2       Not Owned                  NONE   S5Y0NA0T100942NP002
0n.1P1       Not Owned                  NONE   S5Y0NA0T100943NP001
0n.1P2       Not Owned                  NONE   S5Y0NA0T100943NP002
0n.5P1       Not Owned                  NONE   S5Y0NA0T101314NP001
0n.5P2       Not Owned                  NONE   S5Y0NA0T101314NP002
0n.2P1       Not Owned                  NONE   S5Y0NA0T100946NP001
0n.2P2       Not Owned                  NONE   S5Y0NA0T100946NP002
0n.23P1      Not Owned                  NONE   S5Y0NA0T100939NP001
0n.23P2      Not Owned                  NONE   S5Y0NA0T100939NP002
0n.19P1      Not Owned                  NONE   S5Y0NA0T101608NP001
0n.19P2      Not Owned                  NONE   S5Y0NA0T101608NP002
0n.0P1       Not Owned                  NONE   S5Y0NA0T100873NP001
0n.0P2       Not Owned                  NONE   S5Y0NA0T100873NP002
0n.4P1       Not Owned                  NONE   S5Y0NA0T101609NP001
0n.4P2       Not Owned                  NONE   S5Y0NA0T101609NP002

    4. Wenn einer dieser Schritte fehlschlägt, setzen Sie das System auf die Werkseinstellungen zurück.

16.3. NTP (Network Time Protocol) einrichten

Rufen Sie die NTP-Server-IPs für die NTP-Relays ab, die im Bootstrap-Cluster ausgeführt werden:

  kubectl get ntpservers -n ntp-system -o jsonpath='{.items[*].status.managementIP}{"\n"}'

Führen Sie für jeden der NTP-Server den folgenden Befehl auf dem ersten ONTAP-Knoten aus:

  cluster time-service ntp server create -server NTP_SERVER_IP

Wenn Ihre ONTAP-Knoten beispielsweise kb-ad-stge01-01, kb-ad-stge01-02, kb-ad-stge02-01 und kb-ad-stge02-02 sind, führen Sie den Befehl auf dem Knoten kb-ad-stge01-01 aus.

16.4. Ordner „cellcfg“ prüfen

Wenn Sie die Werte für Nutzernamen und Passwort für den Speicher abrufen möchten, verwenden Sie die Datei des Hardwareanbieters, die für den Speicher vorgesehen ist, z. B. WO15_SO7100911835-2_GDCH-4d-A250-A400_DD-010223.xlsx.

16.4.1. Administratorpasswort bestätigen

Suchen Sie in /CELLCFG/file-storage.yaml nach dem ONTAP-Secret-Namen, auf den nach StorageCluster.spec.adminSecretName verwiesen wird.

Suchen Sie das entsprechende Secret und prüfen Sie, ob die Werte ausgefüllt sind. Falls nicht, ersetzen Sie den Administratornutzernamen und das Passwort:

  apiVersion: v1
  kind: Secret
  metadata:
    name: SECRET_NAME
    namespace: gpc-system
  type: Opaque
  stringData:
    netapp_username: admin
    netapp_password: PASSWORD

16.4.2. ONTAP-Lizenzen prüfen

Ihre ONTAP-Softwarelizenzen müssen vom Hardwareanbieter bereitgestellt worden sein.

Suchen Sie im Ordner /cellcfg/af-storage.yaml nach dem Feld StorageCluster.spec.licenses und prüfen Sie, ob die Lizenzen eingetragen sind. Falls nicht, füllen Sie die Felder mit den Lizenzen aus:

  apiVersion: ontap.netapp.storage.private.gdc.goog/v1alpha1
  kind: StorageCluster
  metadata:
    creationTimestamp: null
    name: zl-stge-clus-01
    namespace: gpc-system
  spec:
  ...
    licenses:
      - LICENSE_1
      - LICENSE_2
      - LICENSE_3

Zur Referenz sehen Sie hier ein Beispiel dafür, wie die Lizenzeinträge in der Zellenkonfiguration aussehen sollten:

  licenses:

  ABGITNWODUEVQELPECCAAAAAAAAA
  AHJJWYTTTXKZOFKVBTBAAAAAAAAA
  AHZTHBPQACAAAAKVBTBAAAAAAAAA
  ALTXOYXSVDDCMADPECCAAAAAAAAA
  ANWFPBPQACAAAAKVBTBAAAAAAAAA
  APLKENWODUEVQELPECCAAAAAAAAA
  ARIHVQFAHJMIWBDPECCAAAAAAAAA
  AXFTCRFAHJMIWBDPECCAAAAAAAAA

16.5. Preflight-Validierung

Führen Sie den Validierungsbefehl aus:

gdcloud system check-config --config PATH_TO_CELL_CONFIG --artifacts-directory PATH_TO_ARTIFACTS \
    --scenario FileBlockStorage

Wenn im Log Fehler enthalten sind, folgen Sie den Meldungen, um das Problem zu beheben, und führen Sie die Validierung noch einmal aus.

16.5.1. Mögliche Probleme

In diesem Abschnitt werden mögliche Probleme beschrieben, die bei der Vorabvalidierung der Dateiblockspeicher-Appliances auftreten können.

16.5.1.1. NumDisks für StorageAggregate

Ignorieren Sie die Validierungsfehler bei einer falschen Anzahl von Festplatten, prüfen Sie aber den Wert von NumDisks im StorageAggregate CR manuell. Die StorageAggregate ist in der Datei xx-storage.yaml definiert.

Die Gesamtzahl der für StorageAggregates konfigurierten Festplatten für ein File Block-Gerät muss mit der Anzahl der im Gerät vorhandenen Festplatten abzüglich der Anzahl der Ersatzfestplatten übereinstimmen. Es hat sich bewährt, für jeweils 12 Laufwerke ein Ersatzlaufwerk zu reservieren.

Verwenden Sie die folgende Formel, um den Wert von NumDisks zu berechnen:

NumDisks = (Total_Disks/2) - ceil(Total_Disks/12)

NumDisks entspricht 10, wenn Sie die Formel auf das in diesem Abschnitt beschriebene Beispiel für (24/2) - ceil(24/12) anwenden.

16.6. Installation ausführen

Führen Sie den Installationsbefehl aus:

  gdcloud system storage install -v 3 --config PATH_TO_CELL_CONFIG

Mit diesem Befehl wird Folgendes ausgeführt:

  • Richtet den NetApp-Cluster ein und fügt verfügbare Knoten hinzu
  • Erstellt die Aggregate
  • Richtet LACP und VLANs auf den Datenports ein
  • Lizenzen einrichten
  • Monitoring konfigurieren
  • Externe Schlüsselverwaltung konfigurieren

Führen Sie nach Abschluss des Jobs node show in der ONTAP-Konsole aus, um sicherzustellen, dass keine Warnungen wie die folgenden angezeigt werden:

kb-stge-clus-01::> node show
Node      Health Eligibility Uptime        Model       Owner    Location
--------- ------ ----------- ------------- ----------- -------- ---------------
kb-ad-stge01-01
          true   true         5 days 02:49 AFF-A250
kb-ad-stge01-02
          true   true         6 days 18:24 AFF-A250
kb-ad-stge02-01
          true   true         5 days 01:52 AFF-A800
kb-ad-stge02-02
          true   true         5 days 01:52 AFF-A800
kb-ad-stge03-01
          true   true         7 days 00:15 AFF-A400
kb-ad-stge03-02
          true   true         7 days 00:26 AFF-A400

Warning: Cluster operation (cluster join) for node "kb-ad-stge03-01" is not complete and the node is not fully functional.
         Run "cluster join" on that node to complete the operation.
6 entries were displayed.

Falls ja, folgen Sie der Anleitung, melden Sie sich auf diesen Knoten an und führen Sie den entsprechenden cluster join-Befehl aus, um sicherzustellen, dass er nach dem Vorgang verschwindet.

16.7. Sicherheitseinstellungen aktualisieren

  1. Anmeldebanner festlegen:

    security login banner modify -vserver <cluster name> -message "<banner>"

  2. Zeitlimit für CLI-Sitzungen auf zehn Minuten begrenzen:

    system timeout modify 10

  3. Passwortkomplexität und maximale Anmeldeversuche für die Administratorrolle erzwingen:

    security login role config modify -vserver CLUSTER_NAME -role admin -passwd-minlength 15 -passwd-min-special-chars 1 -passwd-min-lowercase-chars 1 -passwd-min-uppercase-chars 1 -passwd-min-digits 1 -disallowed-reuse 25 -max-failed-login-attempts 3

  4. Zeitüberschreitung für UI-Sitzungen auf zehn Minuten begrenzen:

    ::> set diag

Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

::> cluster application-record create -name sysmgr.inactivitytimeout -value 10 -vserver <cluster name>

  5. Einstellungen für die Nutzersperrung anpassen:

    ::> security login role config modify -vserver * -max-failed-login-attempts 3 -lockout-duration 1 -role *
::> security ssh modify -vserver * -max-authentication-retry-count 3

  6. USB-Anschlüsse deaktivieren (Neustart erforderlich, damit die Änderungen wirksam werden):

    ::> set diag
::*> system node usb-ports modify -node * -is-disabled-next-boot true

  7. Entfernen Sie das Bootstrap-Zertifikat.

    1. Suchen Sie das bootstrap-web-ca-Zertifikat:

        ::> security certificate show-user-installed

      Die Ausgabe sieht so aus, wenn das Bootstrap-Web-CA-Zertifikat vorhanden ist:

      Vserver    Serial Number   Certificate Name                       Type
---------- --------------- -------------------------------------- ------------
aa-aa-stge01
          45B86E1B5CF1CC144B874C80A39D2A99
                          bootstrap-web-ca                       server-ca
    Certificate Authority: bootstrap-web-ca
          Expiration Date: Mon Feb 19 22:55:03 2029

  8. Wenn Sie die Knoten neu starten möchten, starten Sie sie einzeln mit dem folgenden Befehl neu:

    ::> system node reboot -node <node-name> -inhibit-takeover true

16.8. Notfallzugriffsnutzer speichern

Vier Breakglass-Konten werden automatisch erstellt und bei der Einrichtung als die folgenden Kubernetes-Secrets gespeichert.

  • storage-root-level1
  • storage-root-level1-backup
  • storage-root-level2
  • storage-root-level2-backup

Bewahren Sie Ihre Anmeldedaten für storage-root-level2 und storage-root-level2-backup wie vorgeschrieben auf Papier auf und schützen Sie sie:

  1. Rufen Sie den Nutzernamen und das Passwort aus dem Secret mit den folgenden Befehlen ab und ersetzen Sie SECRET_NAME durch das Secret, das Sie verwenden möchten:

    kubectl get secret -n gpc-system SECRET_NAME -o jsonpath='{.data.username}' | base64 --decode
kubectl get secret -n gpc-system SECRET_NAME -o jsonpath='{.data.password}' | base64 --decode

  2. Rufen Sie den Namen des ONTAP-Clusters ab:

      ::> cluster identity show

  3. Prüfen Sie, ob es unerwartete Nutzer mit Administratorberechtigungen gibt:

      ::> useradmin user list
    1. Optional: Löschen Sie sie mit Genehmigung des Infrastrukturbetreibers. Immer für Produktions- und Kundenarbeitslasten ausführen:
          ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application amqp

      ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application console

      ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application http

      ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application ontapi

      ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application service-processor

      ::> security login delete -user-or-group-name <username> -vserver <Cluster Name> -authentication-method password -application ssh
  ```

  4. Löschen Sie den im vorherigen Schritt erstellten NetApp-Administratornutzer.

        ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application amqp

    ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application console

    ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application http

    ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application ontapi

    ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application service-processor

    ::> security login delete -user-or-group-name admin -vserver <Cluster Name> -authentication-method password -application ssh

  5. Der verantwortliche Infrastrukturbetreiber notiert den Nutzernamen und das Passwort für jedes Gerät gut lesbar auf separaten Zetteln. Sie falten die Papiere so, dass der Inhalt nicht sichtbar ist, beschriften sie z. B. mit „Root-Anmeldedaten für TOR-Switch 1“ und übergeben sie zur sicheren Aufbewahrung an einen L1-Techniker.

  6. Unter Aufsicht des IO-Leiters bewahrt der L1-Techniker die Dokumente in einem physischen Safe auf.

  7. Der IO fügt den Secrets eine Annotation hinzu, um zu kennzeichnen, dass das Secret im Safe gespeichert wurde.

    kubectl annotate secrets storage-root-level2 -n gpc-system disk.gdc.goog/persisted=''

    16.9. NTP-Server aktualisieren

Führen Sie diese Schritte nach der Installation des Administratorclusters aus:

  1. Rufen Sie die neuen NTP-Server-IPs für die NTP-Relays ab, die im Administratorcluster ausgeführt werden:

    kubectl get ntpservers -n gpc-system

  2. Löschen Sie in ONTAP alle vorhandenen NTP-Server:

    cluster time-service ntp server show
cluster time-service ntp server delete -server NTP_SERVER_IP

  3. Fügen Sie die neuen NTP-Server zu ONTAP hinzu:

    cluster time-service ntp server create -server NTP_SERVER_IP