Distributed Cloud 接続ストレージを構成する

このページでは、Distributed Cloud Connected クラスタのストレージを構成する方法について説明します。内容は次のとおりです。

• Rakuten Symcloud Storage
• ローカル ストレージ スキーマ
• トラブルシューティング

Symcloud Storage 用に Distributed Cloud Connected を構成する

Distributed Cloud Connected ノードは、ローカル ストレージをワークロードに直接公開しません。代わりに、Distributed Cloud Connected は Rakuten Symcloud Storageを使用します。 これは、各 Distributed Cloud Connected ノードで実行されるローカル ストレージ抽象化レイヤとして機能するサードパーティ ソリューションで、ローカル ストレージを クラスタ内のすべての Distributed Cloud Connected ノードで実行されるワークロードで使用できるようにします。

Container Storage Interface （CSI）は、Kubernetes がコンテナ化されたワークロードに任意のストレージ システムを公開でき、多くの大手ストレージ ベンダーがサポートするオープン スタンダード API です。Distributed Cloud Connected では、Symcloud Storage がサポートおよび管理される CSI ストレージ ソリューションです。Symcloud Storage が有効になると、必要な Kubernetes StorageClasses が構成されます。その後、適切なストレージ クラスを使用するようにワークロードを構成できます。

Symcloud Storage は Google Cloud Marketplace からデプロイされ、そこに記載されている条件が適用されます。Google は、Distributed Cloud Connected での Symcloud Storage の使用に対して限定的なサポートを提供しており、サードパーティ プロバイダに支援を求める場合があります。Symcloud Storage のソフトウェア アップデートは、Distributed Cloud Connected ソフトウェア アップデートに含まれています。

このリリースの Distributed Cloud Connected には、Symcloud Storage 6.0.0-226 が同梱されており、 サポートされています 。 このリリースの Distributed Cloud Connected では、他のバージョンの Symcloud Storage はサポートされていません。

Symcloud Storage ライセンスを取得する

Google Cloud Marketplace から YAML 形式で Symcloud Storage ライセンスを取得する必要があります。

Marketplace に移動

前提条件

始める前に、次の手順を完了してください。

1. ターゲットの Distributed Cloud Connected プロジェクトのロギングと モニタリング を構成します。
2. ターゲットの Distributed Cloud Connected クラスタを作成します。 プロビジョニングの進行状況を モニタリングできます。
3. ターゲットの Distributed Cloud Connected クラスタ内の Pod が データセンターに 到達できるように、Distributed Cloud ネットワークを構成します。 Google Cloud
4. Symcloud Storage で抽象化しない各 Distributed Cloud ノードの各 local-block 永続ボリュームをバインドします。バインドされた local-block 永続ボリュームのバインドを解除すると、Symcloud Storage をインストールすると、その永続ボリュームの内容が消去されます。手順については、 Kubernetes ドキュメントの バインディングをご覧ください。

Distributed Cloud Connected ノードに Symcloud Storage をインストールする

Distributed Cloud Connected ノードに Symcloud Storage をインストールする手順は次のとおりです。

1. 次のコマンドを使用して、Symcloud Storage ライセンスをクラスタに適用します。LICENSE_FILE は、Symcloud Storage ライセンス ファイルのフルパスと名前に置き換えます。

   kubectl apply -f LICENSE_FILE -n robin-admin
   

2. 次のコマンドを使用して、RobinCluster サービスとすべての Symcloud Storage ノードのステータスを確認します。

   kubectl describe robinclusters -n robinio
   

   このコマンドでは、次のような出力が返されます。

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

   サービスとノードの想定されるステータスは Ready です。

Symcloud Storage をデフォルトのストレージ クラスとして設定する

次のコマンドを使用して、Distributed Cloud Connected クラスタのデフォルトのストレージ クラスとして Symcloud Storage を設定します。 STORAGE_CLASS は、 Symcloud Storage クラスのいずれかに置き換えます。

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

デフォルトのストレージ クラスの設定の詳細については、Kubernetes ドキュメントの デフォルトの StorageClass を変更する をご覧ください。

Symcloud Storage クラス

このセクションでは、Symcloud Storage が Distributed Cloud Connected クラスタで有効にできるストレージ クラスについて説明します。Distributed Cloud Connected の Symcloud Storage は、robin-rwx ストレージ クラスと、カスタム構成された RWX ファイル システム モード ボリュームをサポートしていません。 Symcloud Storage クラスの詳細については、Kubernetes での Robin CNS の使用をご覧ください。

robin ストレージ クラス

robin ストレージ クラスは、基本的な Read Write-Once（RWO）ストレージ クラスです。次の例は、クラスのインスタンス化を示しています。

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

警告: この単一レプリカ ストレージ クラスを使用すると、ノード障害が発生した場合に冗長性が確保されないため、データが失われる 可能性があります。少なくとも 3 つのレプリカで冗長性を提供するストレージ クラスを使用することを強くおすすめします。

robin-immediate ストレージ クラス

robin-immediate ストレージ クラスは、対応する 永続ボリューム要求の作成直後に永続ボリュームが作成される点を除き、robin と同じです。次の例は、クラスのインスタンス化を示しています。

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

警告: この単一レプリカ ストレージ クラスを使用すると、ノード障害が発生した場合に冗長性が確保されないため、データが失われる 可能性があります。少なくとも 3 つのレプリカで冗長性を提供するストレージ クラスを使用することを強くおすすめします。

robin-repl-3 ストレージ クラス

robin-repl-3 は、複数の Distributed Cloud ノードにまたがる 3 つのレプリカを持つ RWO ストレージ クラスです。次の例は、クラスのインスタンス化を示しています。

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

ワークロード用に抽象化された Symcloud Storage ボリュームを構成する

このセクションでは、Symcloud Storage クラスを使用して、Distributed Cloud Connected ワークロードの抽象化ストレージを構成する方法の例を示します。Symcloud Storage ボリュームの構成の詳細については、 Kubernetes での Robin CNS の使用をご覧ください。

ファイル システム モードで ext4 RWO ボリュームを構成する

次の例は、ext4 ファイル システムを使用して、ファイル システム モードの RWO ボリュームの永続ボリューム要求を構成する方法を示しています。 STORAGE_CLASS は、 Symcloud Storage クラスのいずれかに置き換えます。

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

ブロックモードで RWO ボリュームを構成する

次の例は、ブロックモードで RWO ボリュームの永続ボリューム要求を構成する方法を示しています。STORAGE_CLASS は、Symcloud Storage クラスのいずれかに 置き換えます。

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

既存のボリュームの構成を変更する

次の例は、アノテーションを使用して、既存の Symcloud Storage LZ4 圧縮 RWO ボリュームの構成を変更する方法を示しています。 STORAGE_CLASS は、Symcloud Storage クラスのいずれかに置き換えます。

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

次の例は、アノテーションを使用して、xfs ファイル システムを使用する既存の Symcloud Storage RWO ボリュームの構成を変更する方法を示しています。 STORAGE_CLASS は、Symcloud Storage クラスのいずれかに置き換えます。

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 クライアントを構成する

Symcloud Storage には、Symcloud Storage 構成の管理に使用できるコマンドライン インターフェース（CLI）クライアントが用意されています。Distributed Cloud Connected クラスタでクライアントを構成する手順は次のとおりです。

1. Distributed Cloud Connected クラスタにデプロイされた RobinCluster サービス インスタンスで使用される Symcloud Storage イメージパスを取得し、環境変数を次のように設定します。

   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. 次の内容で robincli リソースを作成します。

   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"
   

   ROBIN_CNS_IMAGE は、ステップ 1 で取得したイメージのリポジトリのフルパスと名前に置き換えます。

3. robincli リソースを Distributed Cloud Connected クラスタに適用します。

4. 最初のインストール時に、Symcloud Storage はランダムなパスワードを使用して robinio 名前空間に default-admin-user シークレットを生成します。次のコマンドを使用して、これらのログイン認証情報を取得します。

   1. ユーザー名を取得します。

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

   2. パスワードを取得します。

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

5. 新しく作成した Pod にログインして、クライアントを実行します。

   kubectl exec -it robincli -- bash
   

StatefulSet でストレージ クラスを参照する

次の例は、 StatefulSet ワークロードで Symcloud ストレージ クラスを参照する方法を示しています。

この例では、事前構成済みの robin-repl-3 ストレージ クラスを使用していることを前提としています。このクラスは、高可用性を実現するために、3 つの異なるワーカーノードにレプリケートされたボリュームを提供します。

高可用性用に StatefulSet を構成する場合は、構成に次のベスト プラクティスを含めます。

• Headless Service: StatefulSet には、コンパニオン Headless Service が、serviceName フィールドと一致する必要があります。Headless Service は、clusterIP: None のサービスです。このサービスは、セット内の各 Pod に安定した DNS ホスト名を割り当てます。
• Pod のアンチアフィニティ: robin-repl-3 などのレプリケートされたストレージ クラスを使用すると、データは複数のワーカーノードに安全にミラーリングされます。 ただし、Kubernetes がすべてのアプリケーション Pod を同じワーカーノードにスケジュールすると、単一ノードの停止によってアプリケーションが停止する可能性があります。 Pod のアンチアフィニティを構成すると、Pod が個別のワーカーノードに分散され、コンピューティングの可用性とストレージの冗長性が一致します。

次の例は、Headless Service（nginx）と、robin-repl-3 ストレージ クラスを参照する Pod アンチアフィニティで構成された StatefulSet を含む完全な構成を示しています。ワークロードのストレージ要件が時間とともに増加する場合は、PersistentVolumeClaim でストレージ リクエストを編集して、ボリュームのサイズを動的に変更できます。

注: 事前構成済みの Symcloud Storage クラスは volumeBindingMode: WaitForFirstConsumerを使用します。これにより、Pod がスケジュールされるまでボリュームのプロビジョニングが遅延します。そのため、Pod のスケジューリングが完了するまで、PersistentVolumeClaims は Pending 状態または waiting for first consumer のままになります。これは想定される動作です。

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

Symcloud Storage の制限事項

Distributed Cloud Connected で Symcloud Storage を使用する場合、高可用性を実現できるのは、Distributed Cloud Connected クラスタが 3 つ以上の Distributed Cloud Connected ノードで構成されている場合のみです。

クラスタから Symcloud Storage を使用するノードを削除する

Symcloud Storage ボリューム レプリカは、Distributed Cloud Connected クラスタ内のワーカーノードに保存されます。 クラスタからノードを削除すると、そのノードに保存されている Symcloud Storage ボリューム データが使用できなくなります。これを防ぐには、次のいずれかを行う必要があります。

• クラスタ全体を破棄する場合は、クラスタ自体を破棄する前に、ワークロードとその対応する Symcloud Storage 永続ボリュームを削除します。
• クラスタから特定のノードを削除する場合は、クラスタからノードを削除する前に、それらのノードに保存されているワークロード データを移行する必要があります。手順については、 ディスクからボリュームを退避させるをご覧ください。

ローカル ストレージ スキーマを構成する

ストレージ スキーマは、1 つ以上のパーティションの論理グループです。各パーティションは、論理的に独立したストレージ単位です。パーティションは、物理ディスク容量がなくなるまで、クラスタに順番に作成されます。各ストレージ スキーマには、それを識別する一意の名前があります。

Distributed Cloud Connected クラスタの新しいローカル ストレージ スキーマを作成するには、Google にリクエストする必要があります。スキーマをテストしてクラスタに作成したら、gcloud CLI を使用して適用できます。

スキーマをクラスタに適用した後は変更できません。既存のスキーマを変更するには、Google に既存のスキーマの削除をリクエストし、新しいスキーマの作成をリクエストして置き換える必要があります。

ローカル ストレージ スキーマのパーティションを定義する

ローカル ストレージ スキーマをリクエストする前に、まずそのスキーマのパーティションを定義する必要があります。

パーティションには次のプロパティがあります。

• サイズ。パーティション サイズをバイナリ バイトで指定するか、ローカル ディスクの残りのすべてのスペースを使用するように指定できます。
• タイプ。パーティションは、Kubernetes 永続ボリューム（PV）またはローカル ディスク上の Linux ローカル ボリュームとして構成できます。
• モード。パーティションに保存されているボリュームは、ブロック ボリュームまたはファイル システム ボリュームとして構成できます。永続ボリューム パーティションの場合、パーティションのストレージ クラスはそれぞれ local-block または local-disks です。ローカル ボリューム パーティションの場合は、含まれているファイル システムのバインド ポイントとマウント ポイントを指定できます。

ローカル ストレージ スキーマをリクエストする

Distributed Cloud Connected クラスタの新しいローカル ストレージ スキーマをリクエストするには、 Google サポートにお問い合わせください。スキーマに作成する各パーティションのサイズ、 タイプ、モード、必要に応じてマウント ポイントとバインド ポイントを指定してください。

リクエストを受け取ると、スキーマの堅牢性を確保するための一連のテストが実行され、Distributed Cloud Connected クラスタに作成されます。

デフォルトのローカル ストレージ スキーマ

Distributed Cloud Connected には、次のデフォルトのローカル ストレージ スキーマが付属しています。

• default_control_plane_node 。このスキーマでは、次のパーティションが定義されます。

  • ファイル システム モードの 100 GB のローカル ボリューム パーティション。
  • 残りの空きディスク容量を占有するブロックモードの永続ボリューム パーティション。

• default_worker_node 。このスキーマでは、ブロックモードの 410 GB の永続ボリューム パーティションが定義されます。

ローカル ストレージ スキーマをクラスタに適用する

ローカル ストレージ スキーマを Distributed Cloud Connected クラスタに適用するには、次のいずれかを行います。

• ローカル ストレージ スキーマをクラスタのコントロール プレーン ノードに適用するには、クラスタの作成時に --control-plane-node-storage-schema フラグを使用します。詳細については、クラスタを作成するをご覧ください。

• ローカル ストレージ スキーマをクラスタのワーカーノードに適用するには、クラスタのノードプールを作成するときに --node-storage-schema を使用します。詳細については、ノードプールを作成するをご覧ください。

Distributed Cloud Connected は、クラスタまたはノードプールが正常に作成されると、ローカル ストレージ スキーマで定義されたパーティションを作成します。

トラブルシューティング

PersistentVolumeClaims が予期せず保留中のままになる場合や、ワークロードでボリュームをアタッチできない場合は、このセクションの手順に沿ってトラブルシューティングを行います。

PersistentVolumeClaims が保留中のままになる

PersistentVolumeClaims が Pending 状態のままの場合は、ストレージ クラスの volumeBindingMode を確認します。事前構成済みの Symcloud Storage クラスは volumeBindingMode: WaitForFirstConsumer を使用します。これにより、要求を参照する Pod がスケジュールされるまでボリュームのプロビジョニングが遅延します。ワークロード Pod が正常にスケジュールされていることを確認します。

Pod のスケジューリングが完了しても要求が保留中のままになる場合や、ボリュームのアタッチに失敗する場合は、Symcloud Storage コントロール プレーンとノードレベルのデーモンの正常性を確認します。

コントロール プレーンの正常性を確認する

Symcloud Storage コントロール プレーンが正常で、ボリュームをプロビジョニングする準備ができていることを確認するには、 コマンドを実行して RobinCluster カスタム リソースのステータスを確認します。

kubectl describe robinclusters -n robinio

コマンド出力で、Phase が Ready であることを確認します。

ストレージ デーモンの正常性を確認する

すべてのノードレベルのストレージ デーモン Pod が実行されていることを確認するには、 kubectl get コマンドを実行します。

kubectl get pods -n robinio

コマンド出力で、すべての Pod が Running 状態であることを確認します。ストレージ デーモン Pod が失敗したノードでワークロードがスケジュールされると、中央の RobinCluster ステータスに関係なく、ボリュームのアタッチがハングします。

サポートに問い合わせる

Symcloud Storage コントロール プレーンのステータスが Ready でない場合や、ストレージ デーモン Pod が Running 状態でない場合は、 Google サポートにお問い合わせください。 サポート チケットを送信する際は、実行したトラブルシューティング コマンドの出力を提供してください。