Distributed Cloud Connected Storage konfigurieren

Auf dieser Seite wird beschrieben, wie Sie den mit Distributed Cloud verbundenen Speicher konfigurieren, einschließlich:

Distributed Cloud connected für Symcloud Storage konfigurieren

Bei mit Distributed Cloud verbundenen Knoten wird der lokale Speicher nicht direkt für Ihre Arbeitslasten verfügbar gemacht. Stattdessen wird Symcloud Storage von Rakuten verwendet. Dabei handelt es sich um eine Drittanbieterlösung, die als Abstraktionsebene für den lokalen Speicher fungiert. Sie wird auf jedem mit Distributed Cloud verbundenen Knoten ausgeführt und stellt den lokalen Speicher für Arbeitslasten zur Verfügung, die auf allen mit Distributed Cloud verbundenen Knoten in einem Cluster ausgeführt werden.

Symcloud Storage wird über Google Cloud Marketplace bereitgestellt und unterliegt den dort angegebenen Bedingungen. Google bietet nur eingeschränkten Support für die Verwendung von Symcloud Storage mit Distributed Cloud connected und wendet sich möglicherweise an den Drittanbieter, um Unterstützung zu erhalten. Softwareupdates für Symcloud Storage sind in den Softwareupdates für Distributed Cloud connected enthalten.

Diese Version von Distributed Cloud connected wird mit Symcloud Storage 5.4.18 ausgeliefert und unterstützt diese Version. Keine andere Version von Symcloud Storage wird in dieser Version von Distributed Cloud connected unterstützt.

Symcloud Storage-Lizenz erwerben

Sie müssen eine Symcloud Storage-Lizenz im YAML-Format über Google Cloud Marketplace erwerben:

Marketplace aufrufen

Symcloud Storage-Klassen

In diesem Abschnitt werden die Speicherklassen beschrieben, die Symcloud Storage in Ihrem mit Distributed Cloud verbundenen Cluster aktivieren kann. Symcloud Storage in Distributed Cloud connected unterstützt weder die Speicherklasse robin-rwx noch benutzerdefinierte RWX-Dateisystemmodus-Volumes. Weitere Informationen zu Symcloud Storage-Klassen finden Sie unter Robin CNS in Kubernetes verwenden.

Speicherklasse robin

Die Speicherklasse robin ist eine einfache RWO-Speicherklasse (Read Write-Once). Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Speicherklasse robin-immediate

Die Speicherklasse robin-immediate ist mit robin identisch, mit dem Unterschied, dass das nichtflüchtige Volume sofort nach dem Erstellen des entsprechenden Anspruchs auf ein nichtflüchtiges Volume erstellt wird. Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

Speicherklasse robin-repl-3

robin-repl-3 ist eine RWO-Speicherklasse mit drei Replikaten, die sich über mehrere Distributed Cloud-Knoten erstrecken. Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

Vorbereitung

Führen Sie vor Beginn die folgenden Schritte aus:

  1. Konfigurieren Sie Logging und Monitoring für das Zielprojekt von Distributed Cloud connected.
  2. Erstellen Sie den Zielcluster von Distributed Cloud connected.
  3. Konfigurieren Sie Ihr Distributed Cloud-Netzwerk so dass Pods im Zielcluster von Distributed Cloud connected das Rechenzentrum erreichen können. Google Cloud
  4. Binden Sie jedes nichtflüchtige local-block-Volume auf jedem Distributed Cloud-Knoten, der nicht von Symcloud Storage abstrahiert werden soll. Wenn Sie die Bindung eines gebundenen nichtflüchtigen local-block-Volumes aufheben, werden bei der Installation von Symcloud Storage die Inhalte dieses nichtflüchtigen Volumes gelöscht. Eine Anleitung finden Sie in der Kubernetes-Dokumentation unter Bindung.

Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten installieren

So installieren Sie Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten:

  1. Wenden Sie die Symcloud Storage-Lizenz mit dem folgenden Befehl auf Ihren Cluster an. Ersetzen Sie LICENSE_FILE durch den vollständigen Pfad und Namen der Symcloud Storage-Lizenzdatei.

    kubectl apply -f LICENSE_FILE -n robin-admin

  2. Verwenden Sie den folgenden Befehl, um den Status des Dienstes RobinCluster und aller Symcloud Storage-Knoten zu prüfen:

    kubectl describe robinclusters -n robinio

    Die Ausgabe des Befehls sieht in etwa so aus:

    [...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]

    Der erwartete Status für den Dienst und die Knoten ist Ready.

Symcloud Storage als Standardspeicherklasse festlegen

Verwenden Sie den folgenden Befehl, um Symcloud Storage als Standardspeicherklasse in Ihrem mit Distributed Cloud verbundenen Cluster festzulegen. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Weitere Informationen zum Festlegen der Standardspeicherklasse finden Sie in der Kubernetes-Dokumentation unter Standard-StorageClass ändern.

Abstrakte Symcloud Storage-Volumes für Arbeitslasten konfigurieren

In diesem Abschnitt finden Sie Beispiele für die Verwendung von Symcloud Storage-Klassen zum Konfigurieren des abstrakten Speichers für Ihre mit Distributed Cloud verbundenen Arbeitslasten. Weitere Informationen zum Konfigurieren von Symcloud Storage-Volumes finden Sie unter Robin CNS in Kubernetes verwenden.

ext4-RWO-Volume im Dateisystemmodus konfigurieren

Das folgende Beispiel veranschaulicht, wie Sie einen Anspruch auf ein nichtflüchtiges Volume für ein RWO-Volume im Dateisystemmodus mit dem ext4-Dateisystem konfigurieren. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

RWO-Volume im Blockmodus konfigurieren

Das folgende Beispiel veranschaulicht, wie Sie einen Anspruch auf ein nichtflüchtiges Volume für ein RWO-Volume im Blockmodus konfigurieren. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

Konfiguration eines vorhandenen Volumes ändern

Das folgende Beispiel veranschaulicht, wie Sie die Konfiguration eines vorhandenen mit LZ4 komprimierten RWO-Volumes von Symcloud Storage mithilfe von Annotationen ändern. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Das folgende Beispiel veranschaulicht, wie Sie die Konfiguration eines vorhandenen RWO-Volumes von Symcloud Storage mit dem xfs-Dateisystem mithilfe von Annotationen ändern. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Symcloud Storage-CLI-Client konfigurieren

Symcloud Storage bietet einen CLI-Client (Befehlszeilenschnittstelle), mit dem Sie Ihre Symcloud Storage-Konfiguration verwalten können. So konfigurieren Sie den Client in Ihrem mit Distributed Cloud verbundenen Cluster:

  1. Rufen Sie den Symcloud Storage-Imagepfad ab, der von der RobinCluster-Dienstinstanz verwendet wird, die in Ihrem mit Distributed Cloud verbundenen Cluster bereitgestellt wurde, und legen Sie Ihre Umgebungsvariablen so fest:

    image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

  2. Erstellen Sie eine robincli-Ressource mit folgendem Inhalt:

    kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

    Ersetzen Sie ROBIN_CNS_IMAGE durch den vollständigen Repository-Pfad und Namen des Images, das Sie in Schritt 1 abgerufen haben.

  3. Wenden Sie die robincli-Ressource auf Ihren mit Distributed Cloud verbundenen Cluster an.

  4. Bei der Erstinstallation generiert Symcloud Storage ein default-admin-user-Secret im Namespace robinio mit einem zufälligen Passwort. Verwenden Sie die folgenden Befehle, um diese Anmeldedaten abzurufen:

    1. Nutzername abrufen:

      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d

    2. Passwort abrufen:

       
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d

  5. Melden Sie sich im neu erstellten Pod an und führen Sie den Client aus:

    kubectl exec -it robincli -- bash

Einschränkungen von Symcloud Storage

Wenn Sie Symcloud Storage mit Distributed Cloud connected verwenden, können Sie nur dann Hochverfügbarkeit erreichen, wenn Ihr mit Distributed Cloud verbundener Cluster aus mindestens drei mit Distributed Cloud verbundenen Knoten besteht.

Knoten, die Symcloud Storage verwenden, aus einem Cluster entfernen

Symcloud Storage-Volume-Replikate werden auf Worker-Knoten in Ihrem mit Distributed Cloud verbundenen Cluster gespeichert. Wenn Sie einen Knoten aus dem Cluster entfernen, sind die auf diesem Knoten gespeicherten Symcloud Storage-Volume-Daten nicht mehr verfügbar. Führen Sie einen der folgenden Schritte aus, um das zu vermeiden:

  • Wenn Sie den gesamten Cluster entfernen, entfernen Sie die Arbeitslasten und die entsprechenden nichtflüchtigen Symcloud Storage-Volumes, bevor Sie den Cluster selbst entfernen.

  • Wenn Sie bestimmte Knoten aus dem Cluster entfernen, müssen Sie die auf diesen Knoten gespeicherten Arbeitslastdaten migrieren, bevor Sie die Knoten aus dem Cluster entfernen. Eine Anleitung finden Sie unter Volumes von einem Laufwerk entfernen.

Schemas für lokalen Speicher konfigurieren

Ein Speicherschema ist eine logische Gruppierung einer oder mehrerer Partitionen. Jede Partition ist eine logisch unabhängige Speichereinheit. Partitionen werden sequenziell in Ihrem Cluster erstellt, bis der physische Speicherplatz auf dem Laufwerk erschöpft ist. Jedes Speicherschema hat einen eindeutigen Namen, der es identifiziert.

Wenn Sie ein neues Schema für lokalen Speicher für Ihren mit Distributed Cloud verbundenen Cluster erstellen möchten, müssen Sie es bei Google anfordern. Sobald wir das Schema getestet und in Ihrem Cluster erstellt haben, können Sie es mit der gcloud-Befehlszeile anwenden.

Ein Schema kann nicht mehr geändert werden, nachdem es auf einen Cluster angewendet wurde. Wenn Sie ein vorhandenes Schema ändern möchten, müssen Sie bei Google die Löschung des vorhandenen Schemas und dann die Erstellung eines neuen Schemas anfordern, das das vorhandene Schema ersetzt.

Partitionen für ein Schema für lokalen Speicher definieren

Bevor Sie ein Schema für lokalen Speicher anfordern können, müssen Sie zuerst die Partitionen für dieses Schema definieren.

Eine Partition hat die folgenden Eigenschaften:

  • Größe Sie können entweder eine Partitionsgröße in Binär-Byte angeben oder den gesamten verbleibenden Speicherplatz auf dem lokalen Laufwerk verwenden.
  • Typ Sie können eine Partition entweder als nichtflüchtiges Kubernetes-Volume (PV) oder als lokales Linux-Volume auf dem lokalen Laufwerk konfigurieren.
  • Modus Sie können das in der Partition gespeicherte Volume entweder als Block-Volume oder als Dateisystem-Volume konfigurieren. Bei Partitionen für nichtflüchtige Volumes ist die Speicherklasse der Partition entweder local-block oder local-disks. Bei Partitionen für lokale Volumes können Sie die Bindungs- und Bereitstellungspunkte für die enthaltenen Dateisysteme angeben.

Schema für lokalen Speicher anfordern

Wenn Sie ein neues Schema für lokalen Speicher für Ihren mit Distributed Cloud verbundenen Cluster anfordern möchten, wenden Sie sich an den Google-Support und geben Sie die Größe, den Typ, den Modus und optional die Bereitstellungs- und Bindungspunkte für jede Partition an, die Sie im Schema erstellen möchten.

Wenn wir Ihre Anfrage erhalten, führen wir eine Reihe von Tests durch, um die Robustheit des Schemas zu gewährleisten, und erstellen es dann in Ihrem mit Distributed Cloud verbundenen Cluster.

Standardschemas für lokalen Speicher

Distributed Cloud connected wird mit den folgenden Standardschemas für lokalen Speicher ausgeliefert:

  • default_control_plane_node : Dieses Schema definiert die folgenden Partitionen:

    • Eine 100 GB große Partition für lokale Volumes im Dateisystemmodus.
    • Eine Partition für nichtflüchtige Volumes im Blockmodus, die den verbleibenden freien Speicherplatz auf dem Laufwerk belegt.

  • default_worker_node : Dieses Schema definiert eine 410 GB große Partition für nichtflüchtige Volumes im Blockmodus.

Schema für lokalen Speicher auf einen Cluster anwenden

Führen Sie einen der folgenden Schritte aus, um ein Schema für lokalen Speicher auf Ihren mit Distributed Cloud verbundenen Cluster anzuwenden:

  • Wenn Sie ein Schema für lokalen Speicher auf die Knoten der Steuerungsebene des Clusters anwenden möchten, verwenden Sie beim Erstellen des Clusters das Flag --control-plane-node-storage-schema. Weitere Informationen finden Sie unter Cluster erstellen.

  • Wenn Sie ein Schema für lokalen Speicher auf die Worker-Knoten des Clusters anwenden möchten, verwenden Sie beim Erstellen eines Knotenpools für den Cluster das Flag --node-storage-schema. Weitere Informationen finden Sie unter Knotenpool erstellen.

Distributed Cloud connected erstellt die in Ihrem Schema für lokalen Speicher definierten Partitionen, nachdem der Cluster oder Knotenpool erfolgreich erstellt wurde.