Diese Seite wurde von der Cloud Translation API übersetzt.

9.. Bootstrapper-Serverinstallation

Geschätzte Dauer: 3 Stunden

Eigentümer der betriebsbereiten Komponente: OLT/Knoten

Kompetenzprofil: Bereitstellungsingenieur

Die Bootstrapper-Maschine ist das erste Informationssystem (IS), das in einer Air-Gap-Zelle von Google Distributed Cloud (GDC) installiert wird. Sie wird verwendet, um die verbleibenden Distributed Cloud-Informationssysteme zu booten. Die Maschine wird nach Preflight-Prüfungen als Worker-Clusterknoten neu installiert.

Verwenden Sie den ersten Standardserver im dritten Rack für den Bootstrapper. Für die Laborüberprüfung verwenden wir beispielsweise xx-ac-bm15. Das ist der oberste Server im dritten Rack AC, dessen Asset-Tag nicht „base“ enthält. Der Bootstrapper kann zwar eine beliebige Maschine im Rack sein, da es keine besonderen Anforderungen an den Bootstrapper gibt, aber für diesen Zweck wird eine bestimmte Maschine standardisiert. Sie sollten jedoch keinen der Server mit base im Namen in den ersten drei Racks verwenden, da diese für Root-Admin- und Operations-Cluster verwendet werden.

9.1 Betriebssystem installieren

Schließen Sie einen Monitor und eine Tastatur an den Bootstrapper-Computer an.
Legen Sie die IP-Adresse im dedizierten iLO-Netzwerkport fest. Verwenden Sie eine Adresse im Management-IP-Bereich mit 160 als letztes Oktett.
Stellen Sie die IP-Adresse der Workstation auf eine beliebige andere Adresse im selben Subnetz ein und stellen Sie vorübergehend eine Verbindung zum Ethernet-Port auf der Rückseite über ein Crossover-Ethernetkabel her.

9.1.1. Installation über Workstation mit lokaler ISO-Datei

Stellen Sie über den Browser der Offline-Workstation eine Verbindung zur iLO-Konsole des Bootstrapper-Computers her und rufen Sie im Navigationsbaum das Menü Remote Console & Media (Remote-Konsole und ‑Medien) auf. Verwenden Sie keine Remote-Medien über USB iLO.
Klicken Sie auf Virtual Media (Virtuelle Medien) und geben Sie die URL für virtuelle Medien in Connect CD/DVD-ROM (CD/DVD-ROM verbinden) an.
Optional: Wählen Sie Beim nächsten Zurücksetzen booten aus. Wenn Beim nächsten Zurücksetzen booten ausgewählt ist, wird der Server nur beim nächsten Neustart des Servers mit diesem Image gebootet. Das Image wird beim zweiten Serverneustart automatisch ausgeworfen, damit der Server nicht zweimal mit diesem Image startet. Wenn dieses Kästchen nicht angekreuzt ist, bleibt das Bild verbunden, bis es manuell ausgeworfen wird.
Klicken Sie auf Medien einfügen, um die Auswahl zu bestätigen.
Damit der Bootstrapper-Computer vom .iso-Image gebootet wird, müssen Sie den Computer zurücksetzen:
1. Klicken Sie in der iLO-Konsole auf Power & Thermal – Server Power (Stromversorgung & Wärme – Serverstromversorgung).
2. Klicken Sie auf Zurücksetzen. Sie können die virtuelle Konsole öffnen, um den Reset der Maschine und den Start der .iso-Datei zu überwachen.
Nachdem der Bootstrap-Vorgang abgeschlossen ist, geben Sie den Log-in und das Passwort für die Verbindung zum Bootstrapper-Computer (Root-Konto) an. Der Bootstrapper wird mit einer von Google erstellten ISO-Datei gebootstrapped. Daher gibt Google ein Standard-Root-Passwort an.

Als Betreiber haben Sie Zugriff auf das Passwort und können bei Bedarf einen weiteren Nutzer erstellen.

Die Bootstrapper-ISO enthält bereits alle erforderlichen Tools wie docker und kubectl, sodass Sie diese nicht separat installieren müssen.

9.1.2. Installation über ISO-Datei auf USB-Speicher

9.1.2.1. ISO auf USB-Speicher brennen

Der Systemcontroller verwendet ein Rocky-Image, sodass Sie entweder den Befehl „dd“ oder die Benutzeroberfläche „Disks“ verwenden können.
Über die Benutzeroberfläche „Laufwerke“:
1. Schließen Sie einen USB-Stick an.
2. Klicken Sie im Navigationsmenü auf USB-Laufwerk und dann in der Menüleiste auf das Dreistrich-Menü. Klicken Sie auf Laufwerk-Image wiederherstellen und verweisen Sie auf den Bootstrapper, der das ISO heruntergeladen hat.
Mit „dd“:
1. Führen Sie den folgenden Befehl aus, um zu ermitteln, welches Laufwerk das USB-Laufwerk ist: sudo fdisk -l
2. Verwenden Sie die Datenträgergröße, um festzustellen, ob es sich um den USB-Stick handelt. Merken Sie sich den Gerätenamen für die nächsten Schritte.
3. Laufwerk anhand des Gerätenamens einbinden, wie im vorherigen Schritt angegeben: sudo umount <device name>
4. Formatieren Sie das Laufwerk: sudo mkfs.vfat <device name>
5. Kopieren Sie die ISO-Datei auf das Laufwerk: sudo dd bs=4M if=<path to ISO file> of=<device name> status=progress

9.1.2.2. Über USB-Bootlaufwerk starten

Stecken Sie einen USB-Stick in den vorderen USB-Anschluss (nicht in den mit iLO gekennzeichneten).
Wählen Sie in der iLO-Schnittstelle Momentary Press (Kurzes Drücken) auf der Ein/Aus-Taste aus. Warten Sie, bis die virtuelle Schaltfläche gelb wird. Das bedeutet, dass das Gerät ausgeschaltet wurde.
Wählen Sie Administration (Verwaltung) und dann Boot Order (Bootreihenfolge) aus.
Wählen Sie im Abschnitt One-Time Boot Status > Select One-Time Boot die Option USB drive aus.
Wählen Sie in der iLO-Schnittstelle Momentary Press (Kurzes Drücken) auf der Ein/Aus-Taste aus und prüfen Sie, ob die virtuelle Taste grün wird. Die Betriebssysteminstallation erfolgt automatisch, ebenso der Neustart. Sobald in der Konsole die Eingabeaufforderung bootstrapper login angezeigt wird, ist die Bootstrapper-Installation abgeschlossen.
Entfernen Sie den USB-Speicher.

9.1.3. Audit-Logging installieren

So installieren und aktivieren Sie das Bootstrapper-Audit-Logging manuell:

Kopieren Sie den folgenden Block in eine neue Datei unter /etc/bash.bootstrapper_audit.sh.

function log_previous_cmd() {
rc=$? ; [[ "$rc" -eq 130 ]] && return
line="rc=${rc};;pwd=$(pwd);;ppid=${PPID}"
line="${line};;started=$(history 1|awk 'NR==1{$0=gensub(/^.{0,7}([^ ]*) /,"\\1;;cmd=","g",$0)}1')"
logger --priority local6.info --id="$$" "${line}"
}
export PROMPT_COMMAND='log_previous_cmd'
export HISTTIMEFORMAT='%G-%m-%dT%T '

Hängen Sie diese Zeile an das Ende von /etc/bash.bashrc an.
```
[ -f /etc/bash.bootstrapper_audit.sh ] && . /etc/bash.bootstrapper_audit.sh
```
Sobald diese Änderungen gespeichert sind, werden für alle neuen Shells Audit-Logeinträge im Systemjournal aufgezeichnet.

Hinweis :Die aktuelle Shell übernimmt diese Änderung nicht. Aktivieren Sie das Audit-Logging in der aktuellen Shell mit source /etc/bash.bashrc.

(Optional) Prüfen, ob das Audit-Logging funktioniert

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Audit-Logs erfolgreich aufgezeichnet werden, und prüfen Sie, ob eine ähnliche Ausgabe erfolgt:

USER@bootstrapper:~$ echo 'a command'
USER@bootstrapper:~$ sudo journalctl -eo short-iso -p info SYSLOG_FACILITY=22
2024-10-12T00:30:24+0000 bootstrapper USER[96558]: rc=0;;pwd=/root;;ppid=96479;;started=2024-10-12T00:30:24;;cmd=date
2024-10-12T00:30:47+0000 bootstrapper USER[96558]: rc=0;;pwd=/root;;ppid=96479;;started=2024-10-12T00:30:47;;cmd=echo 'a command'

Audit-Logging deaktivieren (optional)

Im unwahrscheinlichen Fall, dass das Audit-Logging andere Bootstrapper-Vorgänge beeinträchtigt, kann die Funktion in der aktuellen Shell schnell deaktiviert werden:
```
USER@bootstrapper:~$ unset PROMPT_COMMAND
```
Wenn Sie sicher sind, dass das Audit-Logging keine Auswirkungen hat, aktivieren Sie es in der aktuellen Shell mit folgendem Befehl wieder: source /etc/bash.bashrc

9.2 Verwaltungsschnittstelle und ‑route einrichten

In diesem Abschnitt werden die Verwaltungsschnittstelle und die für den Bootstrapping-Prozess erforderliche Route eingerichtet.

9.2.1. Management-IP, CIDR und Gateway-Adresse ermitteln

Suchen Sie in der Datei cellcfg/serv-core.yaml nach der Verwaltungs-IP des Bootstrappers:

yq eval -r 'select(.metadata.annotations."system.private.gdc.goog/bootstrapper" == "true") | .spec.managementNetwork.ips[0]' PATH_TO_SERV_CORE_FILE

Ersetzen Sie PATH_TO_SERV_CORE_FILE durch den Pfad zur Datei cellcfg/serv-core.yaml.

Der Bootstrapper wird durch die Annotation system.private.gdc.goog/bootstrapper: "true" identifiziert. Die Management-IP-Adresse in spec.managementNetwork.ips[0] ist im Beispiel 172.22.80.76:

apiVersion: system.private.gdc.goog/v1alpha1
kind: Server
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
    system.private.gdc.goog/bootstrapper: "true"
  creationTimestamp: null
  labels:
    system.private.gdc.goog/rack-name: mb-aa
  name: mb-aa-bm13
  namespace: gpc-system
spec:
  bmc:
    credentialsRef:
      name: bmc-credentials-mb-aa-bm13
      namespace: gpc-system
    ip: 172.22.80.108
    mac: 5c:ba:2c:42:a9:68
    protocol: redfish
    redfish:
      systemPath: /redfish/v1/Systems/1
  dataplaneNetwork: {}
  encryptDisk: true
  firmwareInstall: true
  secureErase: true
  luks:
    enable: false
  managementNetwork:
    ips:
    - 172.22.80.76
    link: LOM1

Suchen Sie den CIDR-Adressbereich, der zum Festlegen der IP-Adresse der Verwaltungsschnittstelle erforderlich ist. Diese Informationen sind im CIQ-Fragebogen verfügbar.

Beispiel für eine CIQ:
```
oobManagementCIDRs:
- ipFamily: IPv4
  ipv4: 172.23.16.0/24
- ipFamily: IPv4
  ipv4: 172.23.17.0/24
- ipFamily: IPv4
  ipv4: 172.23.18.0/24
- ipFamily: IPv4
  ipv4: 172.23.19.0/24
```
In diesem Beispiel deckt der CIDR-Bereich 172.23.16.0/22 alle aufgeführten CIDR-Adressen für die Verwaltung ab.

Suchen Sie die Gateway-Adresse, die vom Bootstrapper für die Kommunikation mit dem Verwaltungsnetzwerk verwendet wird. Wenn sich der Bootstrapper im Rack ac befindet, ermitteln Sie den Namen der CIDRClaim-Ressource mit dem Befehl:

grep -A 10 -B 10 "ac-mgmtsw01-server-os-cidr" cellcfg/pnet-core.yaml`.

Die Ausgabe sieht so aus:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
  labels:
    cidrclaims.system.private.gdc.goog/cidr-category: internal
    cidrclaims.system.private.gdc.goog/cidr-org: root
    cidrclaims.system.private.gdc.goog/node-type: leaf
    network.private.gdc.goog/mgmtnw-device-category: server-os
    network.private.gdc.goog/mgmtsw: ag-ac-mgmtsw01
  name: ag-ac-mgmtsw01-server-os-cidr
  namespace: root
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 172.28.120.128/26
  parentCidrClaimName: server-os-mgmt-network-cidr

Mit dem 172.28.120.128/26, das sich in ipv4Spec.staticCidrBlocks der CIDRClaim-Ressource mit dem Namen ag-ac-mgmtsw01-server-os-cidr befindet, ist die Gateway-Adresse die erste IP-Adresse in 172.28.120.128/26, nämlich 172.28.120.129.

9.2.2. IP-Adresse der Verwaltungsschnittstelle konfigurieren

ip address add dev MGMT_INTERFACE MGMT_IP/MGMT_SUBNET_PREFIX

Ersetzen Sie Folgendes:

MGMT_INTERFACE: Ein Beispiel für einen Namen der Verwaltungsschnittstelle ist ens15f0. Verwenden Sie die MAC-Adresse in cellcfg/serv-core.yaml, um zu ermitteln, welche Schnittstelle für das Verwaltungsnetzwerk verwendet wird.
MGMT_IP: die Management-IP-Adresse, die Sie im Abschnitt Management-IP und CIDR finden finden.
MGMT_SUBNET_PREFIX: Das CIDR-Subnetzpräfix für die Verwaltung (z. B. 22 für 172.23.16.0/22 aus dem vorherigen Beispiel). Weitere Informationen finden Sie unter Management-IP und CIDR finden.

Führen Sie das Skript dann auf dem Bootstrapper aus. Mit diesem Skript wird der Verwaltungsschnittstelle die IP-Adresse zugewiesen und eine Standardroute für den Verwaltungs-CIDR-Bereich erstellt.

9.2.3. Verwaltungsoberfläche aktivieren

In diesem Abschnitt finden Sie eine Anleitung zum Aktivieren der Verwaltungsoberfläche. Ermitteln Sie die Verwaltungsschnittstelle, indem Sie die MAC-Adresse der Verwaltungsschnittstelle auf dem Bootstrapper im cellcfg/serv-core.yaml suchen und diese MAC-Adresse mit der ip a-Ausgabe auf dem Bootstrapper abgleichen.

In diesem Beispiel ist der Wert der Verwaltungsschnittstelle ens15f0. Verwenden Sie Ihren eigenen Wert, wenn Sie dieser Anleitung folgen. Fügen Sie die IP-Adresse mit der Management-IP-Adresse aus der Datei cellcfg/serv-core.yaml hinzu:

apiVersion: system.private.gdc.goog/v1alpha1
kind: Server
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
    system.private.gdc.goog/bootstrapper: "true"
  creationTimestamp: null
  labels:
    system.private.gdc.goog/rack-name: ma-ac
  name: ma-ac-bm15
  namespace: gpc-system
spec:
  bmc:
    credentialsRef:
      name: bmc-credentials-ma-ac-bm15
      namespace: gpc-system
    ip: 172.29.8.208
    mac: 5c:ba:2c:42:28:2e
    protocol: redfish
    redfish:
      systemPath: /redfish/v1/Systems/1
  dataplaneNetwork: {}
  encryptDisk: true
  firmwareInstall: true
  secureErase: true
  luks:
    enable: false
  managementNetwork:
    ips:
    - 172.29.24.147
    link: LOM1
  provider: external
  serverHardware:
    bmhNetworkRef:
      name: ma-ac-bm15
    dataplaneNICPorts:
    - mac: 5c:ba:2c:61:83:90
      name: s1p1
    - mac: 5c:ba:2c:61:83:98
      name: s1p2
    machineClassName: o1-standard1-64-gdc-metal
    managementNICPort:
      mac: 98:f2:b3:28:0b:70
      name: LOM1
    portBond:
      name: s1p1-s1p2
      networkBondModeType: 802.3ad
      nicPortNames:
      - s1p1
      - s1p2
status: {}

In dieser YAML-Beispieldatei lautet die Management-IP-Adresse 172.29.24.147. Eine Präfixlänge von /26 wird verwendet, da der CIDR-Block in Verwaltungs-IP-, CIDR- und Gateway-Adresse suchen /26 ist.

Fügen Sie der Verwaltungsschnittstelle die Verwaltungs-IP-Adresse hinzu:

sudo ip addr add 172.29.24.147/26 dev ens15f0,

Legen Sie dann die Schnittstelle mit diesem ip-Befehl fest:

ip link set ens15f0 up

Mit ip link show ens15f0 können Sie prüfen, ob die Schnittstellenkonfiguration erfolgreich war:

ip link show ens15f0

Die Ausgabe sieht etwa so aus. Die Meldung UP weist auf einen erfolgreichen Vorgang hin:

6: ens15f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 98:f2:b3:28:0b:70 brd ff:ff:ff:ff:ff:ff
    inet 172.29.24.147/26 brd 172.29.24.191 scope global ens15f0
       valid_lft forever preferred_lft forever
    inet6 fe80::9af2:b3ff:fe28:b70/64 scope link
       valid_lft forever preferred_lft forever

9.2.4. Routingkonfiguration einrichten


MGMT_GATEWAY=MGMT_GATEWAY
MGMT_CIDR=MGMT_CIDR
MGMT_INTERFACE=MGMT_INTERFACE

ip route add $MGMT_CIDR via $MGMT_GATEWAY dev $MGMT_INTERFACE proto static"

Ersetzen Sie Folgendes:

MGMT_GATEWAY: die Gateway-IP-Adresse, die Sie im Abschnitt Management-IP-, CIDR- und Gateway-Adresse finden finden.
MGMT_CIDR: Das Verwaltungs-CIDR stammt von CIQ. Weitere Informationen finden Sie im Abschnitt Management-IP-, CIDR- und Gateway-Adresse ermitteln.
MGMT_INTERFACE: Ein Beispiel für einen Namen der Verwaltungsschnittstelle ist ens15f0. Anhand der MAC-Adresse in cellcfg/serv-core.yaml kann ermittelt werden, welche Schnittstelle für das Verwaltungsnetzwerk verwendet wird.

Führen Sie das Skript dann auf dem Bootstrapper aus.

9.3 Uhr des Bootstrappers konfigurieren

Zu diesem Zeitpunkt sind noch keine NTP-Server vorhanden. Wir müssen die Uhr des Bootstrappers manuell auf eine einigermaßen genaue Zeit (innerhalb einer Sekunde der Echtzeit) in UTC einstellen. Verwenden Sie „AM“ oder „PM“, es sei denn, Sie verwenden das 24-Stunden-Format. Eine falsch eingestellte Uhr hat irreparable Auswirkungen in späteren Phasen.

date --set "DATE_TIME_UTC"

Ersetzen Sie DATE_TIME_UTC durch das Datum und die Uhrzeit in UTC, z. B. 2023-03-21 01:14:30 AM UTC.

Wenn Sie vom Bootstrapper-Server abgemeldet sind, können Sie sich am physischen Standort des Bootstrapper-Computers oder über den Systemcontroller wieder anmelden.

Melden Sie sich von der physischen Maschine aus auf dem Bootstrapper-Server an:

Schließen Sie eine Tastatur, eine Maus und einen Monitor an den Bootstrapper-Computer an.
Melden Sie sich mit dem Standardnutzernamen und ‑passwort auf dem Computer an.

Melden Sie sich mit dem Systemcontroller auf dem Bootstrapper-Server an:

Gehen Sie mit dem Systemcontroller zum Crash Cart.
Führen Sie dazu diesen Befehl aus:
```
ssh ubuntu@BOOTSTRAPPER_IP_ADDRESS
```
Ersetzen Sie BOOTSTRAPPER_IP_ADDRESS durch die IP-Adresse des Bootstrapper-Servers.

9.5. Dateistruktur

Alle nachfolgenden Vorgänge werden als Root-Nutzer ausgeführt. Die folgende Verzeichnisstruktur wird empfohlen, ist aber nicht erforderlich.

    root
    ├── kubeconfigs/ - recommend creating this directory to keep track of the many kubeconfigs
    └── .kube/config - location of bootstrap(KIND) cluster kubeconfig
    └── full-release-y.y.y-gdch.yyy - Extraction of the gdch tar from step download-files
        ├── bootstrapper.iso
        ├── docs
        ├── examples
        ├── gdcloud
        ├── harbor
        ├── oci
        └── operations_center
        └── root-admin/root-admin-kubeconfig - where the root-admin kubeconfig will be put after root-admin creation
    └── full-release-y.y.y-gdch.yyy-hotfix - if necessary, hotfixes will be extracted to another folder
        ├── README - explains how to apply the hotfix
        ├── oci - directory containing the hotfix
    ├── config - this is for the output of the "create configuration files" step
        ├── output/cellcfg - initial CRs applied to the bootstrap cluster
        ├── output/assets
        ├── devices.csv - HW file useful to have for debugging
        ├── cables.csv - HW file useful to have for debugging
        ├── ciq.yaml - HW file useful to have for debugging