1.2. VolSync 永続ボリュームレプリケーションサービス (テクノロジープレビュー)
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 マルチクラスターネットワークとサービス検出 を設定し、
ServiceType
のClusterIP
値を使用してクラスターをネットワーク化するか、ServiceType
のLoadBalancer
値でロードバランサーを使用できます。 - ソース永続ボリュームに使用するストレージドライバーは、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 コンソールから以下のステップを実行します。
-
詳細を表示するには、ハブクラスターコンソールの
Clusters
ページからマネージドクラスターの 1 つを選択します。 Labels フィールドに、次のラベルを追加します。
addons.open-cluster-management.io/volsync=true
VolSync サービス Pod はマネージドクラスターにインストールされます。
- 他のマネージドクラスターに同じラベルを追加します。
各マネージドクラスターで次のコマンドを実行して、VolSync Operator がインストールされていることを確認します。
oc get csv -n openshift-operators
インストール時に VolSync の Operator がリストされています。
-
詳細を表示するには、ハブクラスターコンソールの
コマンドラインインターフェイスから次の手順を実行します。
- ハブクラスターでコマンドラインセッションを開始します。
次のコマンドを入力して、最初のクラスターにラベルを追加します。
oc label managedcluster <managed-cluster-1> "addons.open-cluster-management.io/volsync"="true"
managed-cluster-1
をマネージドクラスターの 1 つの名前に置き換えます。次のコマンドを入力して、ラベルを 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 をマネージドクラスターにインストールするには、次の手順を実行します。
ハブクラスターで、次の例のようなコンテンツを含む
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
である必要があります。次の例のようなコマンドを入力して、ファイルを設定に適用します。
oc apply -f volsync-mcao.yaml
他のマネージドクラスターに対して手順を繰り返します。
ManagedClusterAddOn
リソースは、対応する各マネージドクラスターの namespace 内のハブクラスターに自動的に作成される必要があります。
1.2.1.3. マネージドクラスター間での Rsync レプリケーションの設定
Rsync ベースのレプリケーションの場合は、ソースクラスターおよび宛先クラスターでカスタムリソースを設定します。カスタムリソースは、address
値を使用してソースを宛先に接続し、sshKeys
を使用して転送されたデータがセキュアであることを確認します。
注記: address
および sshKeys
の値を宛先からソースにコピーし、ソースを設定する前に宛先を設定する必要があります。
この例では、source-ns
namespace の source
クラスターの永続ボリューム要求から destination-ns
namespace の destination
クラスターの永続ボリューム要求に Rsync レプリケーションを設定する手順を説明します。必要に応じて、これらの値を他の値に置き換えることができます。
宛先クラスターを設定します。
宛先クラスターで次のコマンドを実行して、ネームスペースを作成します。
$ kubectl create ns <destination-ns>
destination-ns
を、オンサイトのボリューム要求ごとに宛先が含まれる namespace の名前に置き換えます。以下の 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 の名前に置き換えます。この例では、
LoadBalancer
のServiceType
値が使用されます。ロードバランサーサービスはソースクラスターによって作成され、ソースマネージドクラスターが別の宛先マネージドクラスターに情報を転送できるようにします。ソースと宛先が同じクラスター上にある場合、または Submariner ネットワークサービスが設定されている場合は、サービスタイプとしてClusterIP
を使用できます。ソースクラスターを設定するときに参照するシークレットのアドレスと名前をメモします。storageClassName
およびvolumeSnapshotClassName
は任意のパラメーターです。特に、環境のデフォルト値とは異なるストレージクラスおよびボリュームスナップショットクラス名を使用している場合は、環境の値を指定してください。宛先クラスターで以下のコマンドを実行し、
replicationdestination
リソースを作成します。$ kubectl create -n <destination-ns> -f replication_destination.yaml
destination-ns
は、宛先の namespace の名前に置き換えます。replicationdestination
リソースが作成されると、以下のパラメーターおよび値がリソースに追加されます。パラメーター 値 .status.rsync.address
送信元クラスターと宛先クラスターが通信できるようにするために使用される宛先クラスターの IP アドレス。
.status.rsync.sshKeys
ソースクラスターから宛先クラスターへの安全なデータ転送を可能にする SSH キーファイルの名前。
以下のコマンドを実行して、ソースクラスターで使用する
.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
以下のコマンドを実行して、シークレットの名前および
.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
複製するソース永続ボリュームクレームを特定します。
注記: ソース永続ボリューム要求は CSI ストレージクラスにある必要があります。
ReplicationSource
アイテムを作成します。以下の 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
はオプションのパラメーターです。ご使用の環境のデフォルトとは異なるストレージクラスおよびボリュームスナップショットクラス名を使用している場合は、それらの値を指定してください。永続ボリュームの同期方法を設定できるようになりました。
宛先クラスターに対して次のコマンドを入力して、宛先クラスターから SSH シークレットをコピーします。
$ kubectl get secret -n <destination-ns> $SSHKEYS -o yaml > /tmp/secret.yaml
destination-ns
を、宛先が置かれている永続ボリューム要求の namespace に置き換えます。以下のコマンドを入力して、
vi
エディターでシークレットファイルを開きます。$ vi /tmp/secret.yaml
宛先クラスターのオープンシークレットファイルで、次の変更を行います。
-
名前空間をソースクラスターの名前空間に変更します。この例では、
source-ns
です。 -
所有者の参照を削除します (
.metadata.ownerReferences
)。
-
名前空間をソースクラスターの名前空間に変更します。この例では、
ソースクラスターで、ソースクラスターで次のコマンドを入力してシークレットファイルを作成します。
$ kubectl create -f /tmp/secret.yaml
ソースクラスターで、以下のコマンドを入力して
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 にファイルを作成する必要があります。
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. 複製されたイメージを使用可能な永続的なボリュームクレームに変換
複製されたイメージを使用してデータを回復するか、永続的なボリュームクレームの新しいインスタンスを作成する必要がある場合があります。イメージのコピーは、使用する前に永続的なボリュームクレームに変換する必要があります。複製されたイメージを永続的なボリュームクレームに変換するには、次の手順を実行します。
レプリケーションが完了したら、以下のコマンドを入力して
ReplicationDestination
オブジェクトから最新のスナップショットを特定します。$ kubectl get replicationdestination <destination> -n <destination-ns> --template={{.status.latestImage.name}}
永続的なボリュームクレームを作成するときの最新のスナップショットの値に注意してください。
destination
は、レプリケーション先の名前に置き換えます。destination-ns
は、宛先の namespace に置き換えます。以下の例のような
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
を異なる値で更新できます。次のコマンドを入力して、永続ボリュームクレームが環境で実行されていることを確認します。
$ 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 のドキュメントを参照してください。