Skip to main content
NetApp Backup and Recovery
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

검색 및 복원 카탈로그 저장소를 ONTAP NFS로 마이그레이션

기여자 netapp-mwallis
PDF

NetApp Console 로컬 배포 환경에서 검색 및 복원 성능을 향상시키려면 카탈로그 인덱스 스토리지를 클러스터의 기본 스토리지 클래스에서 ONTAP 기반 NFS 공유로 마이그레이션하십시오. 카탈로그 인덱스는 검색 및 복원을 지원하며, ONTAP 기반 NFS를 사용하면 상당한 성능 향상을 얻을 수 있습니다.

시작하기 전에

시작하기 전에 다음 사항을 준비했는지 확인하십시오.

  • 클러스터에 구성된 ONTAP NFS StorageClass 및 ONTAP 시스템의 충분한 용량.

  • 리소스를 가져오고, 생성하고, 적용하고, 실행하고, 패치하고, 확장하고, 삭제할 수 있는 권한이 있는 클러스터 관리자 자격 증명입니다.

  • 원본 PVC에 있는 데이터의 유효성이 검증된 백업본(마이그레이션 전에 스냅샷을 찍거나 다른 곳에 복사해 두십시오).

작업자 수를 줄입니다

워커 배포 목록을 작성하고 각 워커의 복제본 수를 0으로 줄입니다.

  1. 카탈로그 워커 배포 목록을 모두 나열합니다.

    kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'

  2. 모든 워커 배포를 복제본 수 0개로 축소합니다.

    for d in $(kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'); do
  kubectl scale "$d" --replicas=0 -n cbs
done

  3. 남아 있는 워커 포드가 없는지 확인하십시오.

    kubectl get pods -n cbs | grep cloudmanager-cbs-catalog-worker- || echo "no worker pods running"
NetApp Console 로컬 배포에 ONTAP 볼륨을 마운트하고 Pod에서 데이터를 복사합니다

  1. ONTAP NFS 내보내기를 NetApp Console 로컬 배포 OVA를 배포할 때 생성된 VM의 로컬 마운트 지점에 마운트합니다.

  2. 실행 중인 코디네이터 파드의 데이터를 중간 디렉터리 없이 ONTAP 마운트 위치로 복사합니다. 코디네이터는 반드시 실행 중이어야 합니다.

    참고 내용을 하위 디렉터리가 아닌 볼륨 루트에 복사하십시오. ONTAP 볼륨이 새 /opt/netapp/cbs/catalog/shared 디렉터리입니다. 데이터는 앱이 동일한 경로(예: /opt/netapp/cbs/catalog/shared/cbs/<DATASET_NAME>/…​)에서 찾을 수 있도록 볼륨 루트에 있어야 합니다. 다음 명령에서 tar 명령 형식은 디렉터리 내용(dotfiles 포함)을 중첩된 shared 폴더를 거치지 않고 마운트 루트에 스트리밍합니다.

  3. ONTAP NFS 내보내기를 NetApp Console 로컬 배포 환경의 로컬 마운트 지점에 마운트합니다. 나중에 pv.yaml 파일에서 사용할 것과 동일한 서버/경로를 사용하십시오.

    sudo mkdir -p /mnt/ontap_nfs_vol
sudo mount -t nfs 10.x.x.x:/my_nfs_vol /mnt/ontap_nfs_vol   # ONTAP SVM data LIF IP : junction path

  4. Pod의 공유 볼륨을 ONTAP 마운트 위치로 복사합니다.

    POD=$(kubectl get pod -n cbs -l app=cloudmanager-cbs-catalog -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n cbs "$POD" -- tar cf - -C /opt/netapp/cbs/catalog/shared . \
  | sudo tar xf - -C /mnt/ontap_nfs_vol

  5. 포드 ID와 일치하도록 소유권을 설정합니다.

    sudo chown -R 10001:10001 /mnt/ontap_nfs_vol

  6. 데이터가 볼륨 루트에 복사되었는지 확인하십시오(마운트 바로 아래에 중첩된 "shared/" 폴더가 아닌 "cbs" 폴더가 있어야 합니다).

    ls -la /mnt/ontap_nfs_vol

  7. 복사본을 확인한 다음 마운트를 해제하십시오(나중에 pod가 PVC를 통해 마운트합니다).

    sudo umount /mnt/ontap_nfs_vol

  8. 코디네이터를 축소합니다. 예를 들면 다음과 같습니다.

    kubectl scale deployment cloudmanager-cbs-catalog --replicas=0 -n cbs
kubectl rollout status deployment/cloudmanager-cbs-catalog -n cbs
기존 PVC 및 PV를 삭제합니다.

  1. 연결된 PV에 대한 정보를 캡처한 다음 기존 PVC 및 PV를 삭제합니다.

    PV=$(kubectl get pvc cloudmanager-cbs-catalog-shared-pvc -n cbs -o jsonpath='{.spec.volumeName}')
kubectl delete pvc cloudmanager-cbs-catalog-shared-pvc -n cbs
kubectl delete pv "$PV"
정적 ONTAP PV 및 PVC를 생성합니다.

  1. 다음 PV 및 PVC YAML 오브젝트를 생성합니다.

    pv.yaml

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: ontap-manual-pv
  labels:
    volume: ontap-nfs-share # Used by the PVC selector to find this exact volume
spec:
  capacity:
    storage: 50Gi # Match or remain under the actual ONTAP volume size
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany # Allows multiple Pods to share the NFS mount
  persistentVolumeReclaimPolicy: Retain # Retains ONTAP data if the PVC is deleted
  storageClassName: "" # Leave blank for manual/static provisioning
  nfs:
    server: 10.x.x.x # Replace with your ONTAP SVM data LIF IP address
    path: /my_nfs_vol # Replace with your ONTAP junction path

    pvc.yaml

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloudmanager-cbs-catalog-shared-pvc
  annotations:
    "helm.sh/resource-policy": keep
spec:
  accessModes:
    - ReadWriteMany # Must match the PV's access mode
  resources:
    requests:
      storage: 50Gi # Must be <= the PV capacity (50Gi)
  storageClassName: "" # Explicitly matches the empty StorageClass on the PV
  selector:
    matchLabels:
      volume: ontap-nfs-share # Forces binding to the specific PV above

  2. YAML 객체를 적용할 때는 먼저 PV를 적용한 다음 PVC를 적용합니다(PVC의 레이블 선택기가 바인딩되려면 PV가 존재해야 합니다). 그런 다음 PVC 클레임이 바인딩되었는지 확인합니다.

    kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml -n cbs
kubectl get pvc cloudmanager-cbs-catalog-shared-pvc -n cbs   # expect STATUS: Bound

  3. 코디네이터를 1개 복제본으로 확장합니다.

    kubectl scale deployment cloudmanager-cbs-catalog --replicas=1 -n cbs
kubectl rollout status deployment/cloudmanager-cbs-catalog -n cbs

  4. 작업자를 수동으로 축소했는데 자동으로 해제되지 않은 경우, 수동으로 다시 확대하십시오(작업자는 일반적으로 자동으로 프로비저닝되므로 이 작업이 필요하지 않을 수 있습니다).

    for d in $(kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'); do
  kubectl scale "$d" --replicas=1 -n cbs
done

  5. 마운트 및 데이터 상태를 확인하십시오. 데이터가 존재하고 사용자 및 그룹 10001:10001의 소유인지 확인하십시오.

    POD=$(kubectl get pod -n cbs -l app=cloudmanager-cbs-catalog -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n cbs "$POD" -- mount | grep /opt/netapp/cbs/catalog/shared
kubectl exec -n cbs "$POD" -- ls -la /opt/netapp/cbs/catalog/shared
참고

  • 반환 정책 Retain: PVC를 삭제해도 ONTAP 데이터는 지워지지 않습니다. 재프로비저닝을 수행해야 하는 경우, 해제된 PV는 수동으로 정리해야 합니다.

  • Helm을 동기화 상태로 유지: PVC는 일반적으로 차트에 의해 렌더링되므로 향후 helm upgrade`이(가) 이를 다시 생성하거나 수정하려고 시도할 수 있습니다. 이 수동 ONTAP PVC를 유지하려면 동일한 값 (`storageClass: ""(크기/액세스 모드 일치)을 차트에 지정하거나 릴리스에서 공유 PVC를 제외하십시오.

  • 수동으로 `helm uninstall`을 실행한 후 다시 설치하려고 하면 PV가 동일한 이름으로 설치되어 이름 충돌이 발생합니다.