1.2. triggerSync 영구 볼륨 복제 서비스 (기술 프리뷰)


gRPCSync는 클러스터 내의 영구 볼륨을 비동기식 복제하거나 복제와 호환되지 않는 스토리지 유형이 있는 클러스터 전체에서 비동기식 복제를 가능하게 하는 Kubernetes Operator입니다. CSI(Container Storage Interface)를 사용하여 호환성 제한을 해결합니다. 사용 중인 환경에 presenceSync Operator를 배포한 후 이를 활용하여 영구 데이터의 복사본을 만들고 유지 관리할 수 있습니다. ReadWriteManySync는 Red Hat OpenShift Container Platform 클러스터의 버전 4.8 이상에서만 영구 볼륨 클레임을 복제할 수 있습니다.

1.2.1. skopeoSync를 사용하여 영구 볼륨 복제

세 가지 방법을 사용하여 사용자가 보유한 동기화 위치 수에 따라 funcSync를 사용하여 영구 볼륨을 복제할 수 있습니다. 이 예제에서는 Rsync 메서드를 사용합니다. 다른 방법에 대한 정보와 Rsync에 대한 자세한 내용은 Usage in the Rsync documentation를 참조하십시오.

rsync 복제는 일반적으로 사용되는 영구 볼륨의 일대일 복제입니다. 이는 원격 사이트에 데이터를 복제하는 데 사용됩니다.

grSync는 자체 네임스페이스를 생성하지 않으므로 다른 OpenShift Container Platform all-namespace Operator와 동일한 네임스페이스에 있습니다. WorkingSync의 Operator 설정을 변경하면 채널 업데이트에 대한 수동 승인으로 변경되는 경우와 같이 동일한 네임스페이스의 다른 연산자에도 영향을 미칩니다.

1.2.1.1. 사전 요구 사항

클러스터에 segmentSync를 설치하기 전에 다음 요구 사항이 있어야 합니다.

  • Red Hat Advanced Cluster Management 버전 2.4 이상을 실행하는 구성된 Red Hat OpenShift Container Platform 환경
  • 동일한 Red Hat Advanced Cluster Management hub 클러스터에서 관리하는 구성된 두 개 이상의 클러스터
  • IKEvSync로 구성된 클러스터 간 네트워크 연결; 클러스터가 동일한 네트워크에 없는 경우 Submariner 다중 클러스터 네트워킹 및 서비스 검색을 구성하고 ServiceTypeClusterIP 값을 사용하여 클러스터를 네트워크에 사용하거나 LoadBalancer 값이 ServiceType 에 대해 LoadBalancer 값이 있는 로드 밸런서를 사용할 수 있습니다.
  • 소스 영구 볼륨에 사용하는 스토리지 드라이버는 CSI와 호환되어야 하며 스냅샷을 지원할 수 있어야 합니다.

1.2.1.2. 관리형 클러스터에 IKEvSync 설치

IKEvSync가 한 클러스터에서 다른 클러스터의 영구 볼륨 클레임에 영구 볼륨 클레임을 복제할 수 있도록 하려면 소스 및 대상 관리 클러스터 모두에NodePolicySync를 설치해야 합니다.

두 가지 방법 중 하나를 사용하여 사용자의 환경에 있는 두 클러스터에NodePolicySync를 설치할 수 있습니다. 다음 섹션에 설명된 대로 hub 클러스터의 각 관리 클러스터에 레이블을 추가하거나 수동으로 ManagedClusterAddOn 을 만들고 적용할 수 있습니다.

1.2.1.2.1. 라벨을 사용하여NodePolicySync 설치

레이블을 추가하여 관리 클러스터에 devolSync를 설치하려면 다음을 수행합니다.

  • Red Hat Advanced Cluster Management 콘솔에서 다음 단계를 완료합니다.

    1. 허브 클러스터 콘솔의 클러스터 페이지에서 관리형 클러스터 중 하나를 선택하여 세부 정보를 확인합니다.
    2. 라벨 필드에 다음 라벨을 추가합니다.

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

      gRPCSync 서비스 pod가 관리형 클러스터에 설치되어 있습니다.

    3. 동일한 레이블을 다른 관리 클러스터에 추가합니다.
    4. 각 관리 클러스터에서 다음 명령을 실행하여 gRPCSync Operator가 설치되었는지 확인합니다.

      oc get csv -n openshift-operators

      presenceSync가 설치될 때 사용할 수 있는 연산자가 있습니다.

  • 명령줄 인터페이스에서 다음 단계를 완료합니다.

    1. hub 클러스터에서 명령줄 세션을 시작합니다.
    2. 다음 명령을 입력하여 첫 번째 클러스터에 레이블을 추가합니다.

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

      managed-cluster-1 을 관리형 클러스터 중 하나의 이름으로 교체합니다.

    3. 다음 명령을 입력하여 두 번째 클러스터에 레이블을 추가합니다.

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

      managed-cluster-2 를 다른 관리 클러스터의 이름으로 교체합니다.

      ManagedClusterAddOn 리소스는 각각의 관리 클러스터의 네임스페이스에 허브 클러스터에서 자동으로 생성해야 합니다.

1.2.1.2.2. ManagedClusterAddOn을 사용하여 gRPCSync 설치

ManagedClusterAddOn 을 수동으로 추가하여 ProvisionSync를 관리형 클러스터에 설치하려면 다음 단계를 완료하십시오.

  1. hub 클러스터에서 다음 예와 유사한 콘텐츠가 포함된 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 를 관리형 클러스터 중 하나의 네임스페이스로 교체합니다. 이 네임스페이스는 관리 클러스터의 이름과 동일합니다.

    참고: 이름은 volsync 여야 합니다.

  2. 다음 예와 유사한 명령을 입력하여 구성에 파일을 적용합니다.

    oc apply -f volsync-mcao.yaml
  3. 다른 관리 클러스터에 대해 절차를 반복합니다.

    ManagedClusterAddOn 리소스는 각각의 관리 클러스터의 네임스페이스에 허브 클러스터에서 자동으로 생성해야 합니다.

1.2.1.3. 관리형 클러스터 전체에서 Rsync 복제 구성

Rsync 기반 복제의 경우 소스 및 대상 클러스터에서 사용자 정의 리소스를 구성합니다. 사용자 지정 리소스는 address 값을 사용하여 소스를 대상에 연결하고 sshKeys 를 사용하여 전송된 데이터의 보안을 유지합니다.

참고: 대상에서 소스로 addresssshKeys 의 값을 복사해야 하므로 소스를 구성하기 전에 대상을 구성하십시오.

이 예에서는 source-ns 네임스페이스의 소스 클러스터의 영구 볼륨 클레임에서 destination -ns 네임스페이스의 대상 클러스터의 영구 볼륨 클레임으로 Rsync 복제를 구성하는 단계를 제공합니다. 필요한 경우 해당 값을 다른 값으로 교체할 수 있습니다.

  1. 대상 클러스터를 구성합니다.

    1. 대상 클러스터에서 다음 명령을 실행하여 네임스페이스를 생성합니다.

      $ kubectl create ns <destination-ns>

      destination-ns 를 대상 영구 볼륨 클레임을 포함할 네임스페이스의 이름으로 교체합니다.

    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

      참고: 용량 값은 복제 중인 영구 볼륨 클레임의 용량과 일치해야 합니다.

      대상 을 복제 대상 CR의 이름으로 바꿉니다.

      destination-ns 를 대상이 있는 네임스페이스의 이름으로 바꿉니다.

      이 예에서는 LoadBalancerServiceType 값이 사용됩니다. 로드 밸런서 서비스는 소스 관리형 클러스터가 정보를 다른 대상 관리 클러스터로 전송할 수 있도록 소스 클러스터에서 생성합니다. 소스 및 대상이 동일한 클러스터에 있거나 Submariner 네트워크 서비스가 구성된 경우 ClusterIP 를 서비스 유형으로 사용할 수 있습니다. 소스 클러스터를 구성할 때 참조할 시크릿의 주소와 이름을 기록해 둡니다.

      storageClassNamevolumeSnapshotClassName 은 선택적 매개변수입니다. 특히 환경의 기본값과 다른 스토리지 클래스 및 볼륨 스냅샷 클래스 이름을 사용하는 경우 환경 값을 지정합니다.

    3. 대상 클러스터에서 다음 명령을 실행하여 replicationdestination 리소스를 생성합니다.

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

      destination-ns 를 대상이 있는 네임스페이스의 이름으로 바꿉니다.

      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

      대상 을 복제 대상 CR의 이름으로 바꿉니다.

      destination-ns 를 대상이 있는 네임스페이스의 이름으로 바꿉니다.

      출력은 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

      대상 을 복제 대상 CR의 이름으로 바꿉니다.

      destination-ns 를 대상이 있는 네임스페이스의 이름으로 바꿉니다.

      소스를 구성할 때 소스 클러스터에 입력해야 합니다. 출력은 다음 이름과 유사할 수 있는 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의 이름으로 교체합니다. 이를 자동으로 교체하는 방법에 대한 지침은 이 절차의 3vi 단계를 참조하십시오.

      source-ns 를 소스가 있는 영구 볼륨 클레임의 네임스페이스로 바꿉니다. 이를 자동으로 교체하는 방법에 대한 지침은 이 절차의 3vi 단계를 참조하십시오.

      persistent_volume_claim 을 소스 영구 볼륨 클레임의 이름으로 교체합니다.

      mysshkeys 를 구성할 때 ReplicationDestination.status.rsync.sshKeys 필드에서 복사한 키로 교체합니다.

      my.host.com 을 구성할 때 ReplicationDestination.status.rsync.address 필드에서 복사한 호스트 주소로 바꿉니다.

      스토리지 드라이버에서 복제를 지원하는 경우 ClonecopyMethod 값으로 사용하는 것이 복제를 위한 프로세스가 더 간소화될 수 있습니다.

      storageClassNamevolumeSnapshotClassName 은 선택적 매개변수입니다. 해당 환경의 기본값과 다른 스토리지 클래스 및 볼륨 스냅샷 클래스 이름을 사용하는 경우 해당 값을 지정합니다.

      이제 영구 볼륨의 동기화 방법을 설정할 수 있습니다.

    2. 대상 클러스터에 대해 다음 명령을 입력하여 대상 클러스터에서 SSH 보안을 복사합니다.

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

      destination-ns 를 대상이 있는 영구 볼륨 클레임의 네임스페이스로 바꿉니다.

    3. 다음 명령을 입력하여 vi 편집기에서 시크릿 파일을 엽니다.

      $ vi /tmp/secret.yaml
    4. 대상 클러스터의 열려 있는 시크릿 파일에서 다음과 같이 변경합니다.

      • 네임스페이스를 소스 클러스터의 네임스페이스로 변경합니다. 이 예제에서는 source-ns 입니다.
      • 소유자 참조(.metadata.ownerReferences)를 제거합니다.
    5. 소스 클러스터에서 소스 클러스터에 다음 명령을 입력하여 시크릿 파일을 생성합니다.

      $ kubectl create -f /tmp/secret.yaml
    6. 소스 클러스터에서 ReplicationSource 오브젝트의 addresssshKeys 값을 다음 명령을 입력하여 대상 클러스터에서 지정한 값으로 교체하여 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 를 소스가 있는 영구 볼륨 클레임의 이름으로 바꿉니다.

      참고: 복제하려는 영구 볼륨 클레임과 동일한 네임스페이스에 파일을 생성해야 합니다.

    7. ReplicationSource 오브젝트에서 다음 명령을 실행하여 복제가 완료되었는지 확인합니다.

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

      source-ns 를 소스가 있는 영구 볼륨 클레임의 네임스페이스로 바꿉니다.

      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-ns 를 대상의 네임스페이스로 바꿉니다.

  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 을 새 영구 볼륨 클레임의 이름으로 교체합니다.

    destination-ns 를 영구 볼륨 클레임이 있는 네임스페이스로 교체합니다.

    snapshot_to_replace 를 이전 단계에서 찾은 VolumeSnapshot 이름으로 교체합니다.

    모범 사례: 값이 초기 소스 영구 볼륨 클레임과 적어도 동일한 크기인 경우 resources.requests.storage 를 다른 값으로 업데이트할 수 있습니다.

  3. 다음 명령을 입력하여 영구 볼륨 클레임이 환경에서 실행 중인지 확인합니다.

    $ kubectl get pvc -n <destination-ns>

원래 백업 이미지가 기본 영구 볼륨 클레임으로 실행되고 있습니다.

1.2.3. 동기화 예약

복제 시작 방법(항상 실행, 일정으로 또는 수동으로)을 결정할 때 세 가지 옵션 중에서 선택합니다. 복제 예약은 종종 선택되는 옵션입니다.

Schedule 옵션은 예약된 시간에 복제를 실행합니다. 스케줄은 cronspec 에 의해 정의되므로 일정은 시간 간격 또는 특정 시간으로 구성할 수 있습니다. 스케줄 값의 순서는 다음과 같습니다.

"분 (0-59) 시간 (0-23) 월 (1-31) 개월 (1-12) 일 주 (0-6)"

예약된 시간이 발생하면 복제가 시작됩니다. 이 복제 옵션에 대한 설정은 다음 내용과 유사합니다.

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

이러한 방법 중 하나를 활성화하면 구성한 메서드에 따라 동기화 일정이 실행됩니다.

자세한 내용 및 옵션은 See Sync 설명서를 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.