検索

1.2. VolSync 永続ボリュームレプリケーションサービス (テクノロジープレビュー)

download PDF

VolSync は、レプリケーションの互換性がないストレージタイプが指定されたクラスター全体、または 1 つのクラスター内の永続ボリュームの非同期レプリケーションを有効にする Kubernetes Operator です。これは Container Storage Interface (CSI) を使用して互換性の制限を解消します。VolSync オペレーターを環境にデプロイした後、それを活用して永続データのコピーを作成および保守できます。VolSync は、バージョン 4.8 以降の Red Hat OpenShift Container Platform クラスターでのみ永続的なボリュームクレームを複製できます。

1.2.1. VolSync を使用した永続ボリュームの複製

VolSync を使用して永続ボリュームを複製するには、3 つの方法を使用できます。これは、使用している Synchronization の場所の数により異なります。この例では、Rsync メソッドが使用されます。他の方法や Rsync の詳細情報は、VolSync ドキュメントの 使用方法 を参照してください。

rsync レプリケーションは、永続ボリュームの一般的に使用される 1 対 1 のレプリケーションです。これは、リモートサイトにデータを複製するために使用されます。

VolSync は独自の名前空間を作成しないため、他の OpenShift Container Platform のすべての namespace オペレーターと同じ名前空間にあります。VolSync のオペレーター設定に加えた変更は、チャネル更新の手動承認に変更した場合など、同じ namespace 内の他のオペレーターにも影響します。

1.2.1.1. 前提条件

クラスターに VolSync をインストールする前に、以下の要件が必要です。

  • Red Hat Advanced Cluster Management バージョン 2.4 以降のハブクラスターで実行中で、設定済みの OpenShift Container Platform 環境。
  • 同じ Red Hat Advanced Cluster Management ハブクラスターが管理する 2 つ以上のクラスター。
  • VolSync で設定しているクラスター間のネットワーク接続。クラスターが同じネットワーク上にない場合は、Submariner マルチクラスターネットワークとサービス検出 を設定し、ServiceTypeClusterIP 値を使用してクラスターをネットワーク化するか、ServiceTypeLoadBalancer 値でロードバランサーを使用できます。
  • ソース永続ボリュームに使用するストレージドライバーは、CSI 互換であり、スナップショットをサポートできる必要があります。

1.2.1.2. マネージドクラスターへの VolSync のインストール

VolSync が 1 つのクラスターの永続ボリューム要求を別のクラスターの Persistent Volume Claims に複製できるようにするには、ソースとターゲットの両方のマネージドクラスターに VolSync をインストールする必要があります。

2 つの方法のいずれかを使用して、環境内の 2 つのクラスターに VolSync をインストールできます。次のセクションで説明するように、ハブクラスター内の各マネージドクラスターにラベルを追加するか、ManagedClusterAddOn を手動で作成して適用することができます。

1.2.1.2.1. ラベルを使用した VolSync のインストール

ラベルを追加して、マネージドクラスターに VolSync をインストールします。

  • Red Hat Advanced Cluster Management コンソールから以下のステップを実行します。

    1. 詳細を表示するには、ハブクラスターコンソールの Clusters ページからマネージドクラスターの 1 つを選択します。
    2. Labels フィールドに、次のラベルを追加します。

      addons.open-cluster-management.io/volsync=true

      VolSync サービス Pod はマネージドクラスターにインストールされます。

    3. 他のマネージドクラスターに同じラベルを追加します。
    4. 各マネージドクラスターで次のコマンドを実行して、VolSync Operator がインストールされていることを確認します。

      oc get csv -n openshift-operators

      インストール時に VolSync の Operator がリストされています。

  • コマンドラインインターフェイスから次の手順を実行します。

    1. ハブクラスターでコマンドラインセッションを開始します。
    2. 次のコマンドを入力して、最初のクラスターにラベルを追加します。

      oc label managedcluster <managed-cluster-1> "addons.open-cluster-management.io/volsync"="true"

      managed-cluster-1 をマネージドクラスターの 1 つの名前に置き換えます。

    3. 次のコマンドを入力して、ラベルを 2 番目のクラスターに追加します。

      oc label managedcluster <managed-cluster-2> "addons.open-cluster-management.io/volsync"="true"

      managed-cluster-2 を他のマネージドクラスターの名前に置き換えます。

      ManagedClusterAddOn リソースは、対応する各マネージドクラスターの namespace 内のハブクラスターに自動的に作成される必要があります。

1.2.1.2.2. ManagedClusterAddOn を使用した VolSync のインストール

ManagedClusterAddOn を手動で追加して VolSync をマネージドクラスターにインストールするには、次の手順を実行します。

  1. ハブクラスターで、次の例のようなコンテンツを含む volsync-mcao.yaml という YAML ファイルを作成します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: volsync
      namespace: <managed-cluster-1-namespace>
    spec: {}

    managed-cluster-1-namespace を、マネージドクラスターの 1 つの namespace に置き換えます。この namespace は、マネージドクラスターの名前と同じです。

    注: 名前は volsync である必要があります。

  2. 次の例のようなコマンドを入力して、ファイルを設定に適用します。

    oc apply -f volsync-mcao.yaml
  3. 他のマネージドクラスターに対して手順を繰り返します。

    ManagedClusterAddOn リソースは、対応する各マネージドクラスターの namespace 内のハブクラスターに自動的に作成される必要があります。

1.2.1.3. マネージドクラスター間での Rsync レプリケーションの設定

Rsync ベースのレプリケーションの場合は、ソースクラスターおよび宛先クラスターでカスタムリソースを設定します。カスタムリソースは、address 値を使用してソースを宛先に接続し、sshKeys を使用して転送されたデータがセキュアであることを確認します。

注記: address および sshKeys の値を宛先からソースにコピーし、ソースを設定する前に宛先を設定する必要があります。

この例では、source-ns namespace の source クラスターの永続ボリューム要求から destination-ns namespace の destination クラスターの永続ボリューム要求に Rsync レプリケーションを設定する手順を説明します。必要に応じて、これらの値を他の値に置き換えることができます。

  1. 宛先クラスターを設定します。

    1. 宛先クラスターで次のコマンドを実行して、ネームスペースを作成します。

      $ kubectl create ns <destination-ns>

      destination-ns を、オンサイトのボリューム要求ごとに宛先が含まれる namespace の名前に置き換えます。

    2. 以下の YAML コンテンツをコピーし、replication_destination.yaml という名前の新規ファイルを作成します。

      ---
      apiVersion: volsync.backube/v1alpha1
      kind: ReplicationDestination
      metadata:
        name: <destination>
        namespace: <destination-ns>
      spec:
        rsync:
          serviceType: LoadBalancer
          copyMethod: Snapshot
          capacity: 2Gi
          accessModes: [ReadWriteOnce]
          storageClassName: gp2-csi
          volumeSnapshotClassName: csi-aws-vsc

      注記: capacity の値は、レプリケートされる永続ボリューム要求 (PVC) の容量と一致する必要があります。

      destination は、宛先 CR の名前に置き換えます。

      destination-ns は、宛先の namespace の名前に置き換えます。

      この例では、LoadBalancerServiceType 値が使用されます。ロードバランサーサービスはソースクラスターによって作成され、ソースマネージドクラスターが別の宛先マネージドクラスターに情報を転送できるようにします。ソースと宛先が同じクラスター上にある場合、または Submariner ネットワークサービスが設定されている場合は、サービスタイプとして ClusterIP を使用できます。ソースクラスターを設定するときに参照するシークレットのアドレスと名前をメモします。

      storageClassName および volumeSnapshotClassName は任意のパラメーターです。特に、環境のデフォルト値とは異なるストレージクラスおよびボリュームスナップショットクラス名を使用している場合は、環境の値を指定してください。

    3. 宛先クラスターで以下のコマンドを実行し、replicationdestination リソースを作成します。

      $ kubectl create -n <destination-ns> -f replication_destination.yaml

      destination-ns は、宛先の namespace の名前に置き換えます。

      replicationdestination リソースが作成されると、以下のパラメーターおよび値がリソースに追加されます。

      パラメーター

      .status.rsync.address

      送信元クラスターと宛先クラスターが通信できるようにするために使用される宛先クラスターの IP アドレス。

      .status.rsync.sshKeys

      ソースクラスターから宛先クラスターへの安全なデータ転送を可能にする SSH キーファイルの名前。

    4. 以下のコマンドを実行して、ソースクラスターで使用する .status.rsync.address の値をコピーします。

      $ ADDRESS=`kubectl get replicationdestination <destination> -n <destination-ns> --template={{.status.rsync.address}}`
      $ echo $ADDRESS

      destination は、宛先 CR の名前に置き換えます。

      destination-ns は、宛先の namespace の名前に置き換えます。

      出力は、Amazon Web Services 環境の次の出力のように表示されます。

      a831264645yhrjrjyer6f9e4a02eb2-5592c0b3d94dd376.elb.us-east-1.amazonaws.com
    5. 以下のコマンドを実行して、シークレットの名前および .status.rsync.sshKeys の値として提供されるシークレットの内容をコピーします。

      $ SSHKEYS=`kubectl get replicationdestination <destination> -n <destination-ns> --template={{.status.rsync.sshKeys}}`
      $ echo $SSHKEYS

      destination は、宛先 CR の名前に置き換えます。

      destination-ns は、宛先の namespace の名前に置き換えます。

      ソースの設定時に、ソースクラスターで入力する必要があります。出力は、SSH キーシークレットファイルの名前である必要があります。これは、次の名前のようになります。

      volsync-rsync-dst-src-destination-name
  2. 複製するソース永続ボリュームクレームを特定します。

    注記: ソース永続ボリューム要求は CSI ストレージクラスにある必要があります。

  3. ReplicationSource アイテムを作成します。

    1. 以下の YAML コンテンツをコピーして、ソースクラスターに replication_source.yaml という名前の新規ファイルを作成します。

      ---
      apiVersion: volsync.backube/v1alpha1
      kind: ReplicationSource
      metadata:
        name: <source>
        namespace: <source-ns>
      spec:
        sourcePVC: <persistent_volume_claim>
        trigger:
          schedule: "*/3 * * * *"
        rsync:
          sshKeys: <mysshkeys>
          address: <my.host.com>
          copyMethod: Snapshot
          storageClassName: gp2-csi
          volumeSnapshotClassName: gp2-csi

      source は、レプリケーションソース CR の名前に置き換えます。これを自動的に置き換える方法については、この手順のステップ 3-vi を参照してください。

      source-ns をソースが置かれている Persistent Volume Claim の namespace に置き換えます。これを自動的に置き換える方法については、この手順のステップ 3-vi を参照してください。

      persistent_volume_claim は、ソース永続ボリューム要求の名前に置き換えます。

      mysshkeys は、設定時に ReplicationDestination.status.rsync.sshKeys フィールドからコピーしたキーに置き換えます。

      my.host.com は、設定時に ReplicationDestination.status.rsync.address フィールドからコピーしたホストアドレスに置き換えます。

      ストレージドライバーがクローン作成をサポートする場合は、copyMethod の値に Clone を使用すると、レプリケーションのより効率的なプロセスになる可能性があります。

      storageClassName および volumeSnapshotClassName はオプションのパラメーターです。ご使用の環境のデフォルトとは異なるストレージクラスおよびボリュームスナップショットクラス名を使用している場合は、それらの値を指定してください。

      永続ボリュームの同期方法を設定できるようになりました。

    2. 宛先クラスターに対して次のコマンドを入力して、宛先クラスターから SSH シークレットをコピーします。

      $ kubectl get secret -n <destination-ns> $SSHKEYS -o yaml > /tmp/secret.yaml

      destination-ns を、宛先が置かれている永続ボリューム要求の namespace に置き換えます。

    3. 以下のコマンドを入力して、vi エディターでシークレットファイルを開きます。

      $ vi /tmp/secret.yaml
    4. 宛先クラスターのオープンシークレットファイルで、次の変更を行います。

      • 名前空間をソースクラスターの名前空間に変更します。この例では、source-ns です。
      • 所有者の参照を削除します (.metadata.ownerReferences)。
    5. ソースクラスターで、ソースクラスターで次のコマンドを入力してシークレットファイルを作成します。

      $ kubectl create -f /tmp/secret.yaml
    6. ソースクラスターで、以下のコマンドを入力して ReplicationSource オブジェクトの address および sshKeys の値を、宛先クラスターから書き留めた値に置き換えて replication_source.yaml ファイルを変更します。

      $ sed -i "s/<my.host.com>/$ADDRESS/g" replication_source.yaml
      $ sed -i "s/<mysshkeys>/$SSHKEYS/g" replication_source.yaml
      $ kubectl create -n <source> -f replication_source.yaml

      my.host.com は、設定時に ReplicationDestination.status.rsync.address フィールドからコピーしたホストアドレスに置き換えます。

      mysshkeys は、設定時に ReplicationDestination.status.rsync.sshKeys フィールドからコピーしたキーに置き換えます。

      source を、ソース が置かれている永続ボリューム要求の名前に置き換えます。

      注記: 複製する永続ボリューム要求と同じ namespace にファイルを作成する必要があります。

    7. ReplicationSource オブジェクトで以下のコマンドを実行して、レプリケーションが完了したことを確認します。

      $ kubectl describe ReplicationSource -n <source-ns> <source>

      source-ns を、ソースが置かれている Persistent Volume Claim の namespace に置き換えます。

      source は、レプリケーションソース CR の名前に置き換えます。

      レプリケーションが成功した場合、出力は次の例のようになります。

      Status:
        Conditions:
          Last Transition Time:  2021-10-14T20:48:00Z
          Message:               Synchronization in-progress
          Reason:                SyncInProgress
          Status:                True
          Type:                  Synchronizing
          Last Transition Time:  2021-10-14T20:41:41Z
          Message:               Reconcile complete
          Reason:                ReconcileComplete
          Status:                True
          Type:                  Reconciled
        Last Sync Duration:      5m20.764642395s
        Last Sync Time:          2021-10-14T20:47:01Z
        Next Sync Time:          2021-10-14T20:48:00Z

      Last Sync Time に時間がリストされていない場合は、レプリケーションが完了していません。

元の永続ボリュームのレプリカがあります。

1.2.2. 複製されたイメージを使用可能な永続的なボリュームクレームに変換

複製されたイメージを使用してデータを回復するか、永続的なボリュームクレームの新しいインスタンスを作成する必要がある場合があります。イメージのコピーは、使用する前に永続的なボリュームクレームに変換する必要があります。複製されたイメージを永続的なボリュームクレームに変換するには、次の手順を実行します。

  1. レプリケーションが完了したら、以下のコマンドを入力して ReplicationDestination オブジェクトから最新のスナップショットを特定します。

    $ kubectl get replicationdestination <destination> -n <destination-ns> --template={{.status.latestImage.name}}

    永続的なボリュームクレームを作成するときの最新のスナップショットの値に注意してください。

    destination は、レプリケーション先の名前に置き換えます。

    destination-ns は、宛先の namespace に置き換えます。

  2. 以下の例のような pvc.yaml ファイルを作成します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: <pvc-name>
      namespace: <destination-ns>
    spec:
      accessModes:
        - ReadWriteOnce
      dataSource:
        kind: VolumeSnapshot
        apiGroup: snapshot.storage.k8s.io
        name: <snapshot_to_replace>
      resources:
        requests:
          storage: 2Gi

    pvc-name は、新規の永続ボリューム要求 (PVC) の名前に置き換えます。

    destination-ns を、永続ボリューム要求 (PVC) が置かれている namespace に置き換えます。

    snapshot_to_replace を、直前の手順で確認した VolumeSnapshot 名に置き換えます。

    ベストプラクティス: 値が少なくとも最初のソース永続ボリュームクレームと同じサイズである場合は、resources.requests.storage を異なる値で更新できます。

  3. 次のコマンドを入力して、永続ボリュームクレームが環境で実行されていることを確認します。

    $ kubectl get pvc -n <destination-ns>

元のバックアップイメージは、メインの永続ボリューム要求として実行されています。

1.2.3. 同期のスケジューリング

レプリケーションの開始方法を決定するときは、常に実行する、スケジュールどおりに実行する、または手動で実行するという 3 つのオプションから選択します。レプリケーションのスケジュールは、よく選択されるオプションです。

スケジュール オプションは、スケジュール時にレプリケーションを実行します。スケジュールは cronspec で定義されるため、スケジュールを時間間隔または特定の時間として設定できます。スケジュールの値の順序は次のとおりです。

"minute (0-59) hour (0-23) day-of-month (1-31) month (1-12) day-of-week (0-6)"

レプリケーションはスケジュールされた時間に開始されます。このレプリケーションオプションの設定は、以下の内容のようになります。

spec:
  trigger:
    schedule: "*/6 * * * *"

これらの方法のいずれかを有効にしたら、設定した方法に従って同期スケジュールが実行されます。

追加情報およびオプションについては、VolSync のドキュメントを参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.