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

스토리지 쉘프를 폐기할 때 MetroCluster FC에서 MetroCluster IP로 중단 없이 전환(ONTAP 9.8 이상)

기여자

ONTAP 9.8부터 2노드 MetroCluster FC 구성을 4노드 MetroCluster IP 구성으로 중단 없이 전환하고 기존 스토리지 쉘프를 폐기할 수 있습니다. 이 절차에는 기존 드라이브 쉘프에서 새로운 구성으로 데이터를 이동한 다음 이전 쉘프를 폐기하는 단계가 포함됩니다.

  • 이 절차는 기존 스토리지 쉘프를 폐기하고 MetroCluster IP 구성의 새 쉘프로 모든 데이터를 이동할 때 사용됩니다.

  • 기존 스토리지 쉘프 모델은 새로운 MetroCluster IP 노드에서 지원해야 합니다.

  • 이 절차는 ONTAP 9.8 이상을 실행하는 시스템에서 지원됩니다.

  • 이 절차는 중단을 따릅니다.

  • 이 절차는 2노드 MetroCluster FC 구성에만 적용됩니다.

    4노드 MetroCluster FC 구성이 있는 경우 를 참조하십시오 "전환 절차 선택".

  • 모든 요구 사항을 충족하고 절차의 모든 단계를 따라야 합니다.

콘솔 로깅을 활성화합니다

NetApp은 사용 중인 장치에서 콘솔 로깅을 사용하도록 설정하고 이 절차를 수행할 때 다음 작업을 수행할 것을 적극 권장합니다.

기존 쉘프를 폐기할 때 필요한 전환 요구 사항

전환 프로세스를 시작하기 전에 기존 MetroCluster FC 구성이 요구사항을 충족하는지 확인해야 합니다.

  • 2노드 패브릭 연결 또는 확장 MetroCluster 구성이어야 하며 모든 노드에서 ONTAP 9.8 이상을 실행해야 합니다.

    새로운 MetroCluster IP 컨트롤러 모듈은 동일한 버전의 ONTAP 9.8을 실행해야 합니다.

  • 기존 플랫폼과 새 플랫폼의 조합은 전환이 지원되는 조합이어야 합니다.

  • MetroCluster 설치 및 구성 가이드 _ 에 설명된 대로 모든 요구 사항 및 케이블 연결을 충족해야 합니다.

새 구성은 다음 요구 사항도 충족해야 합니다.

  • 새로운 MetroCluster IP 플랫폼 모델은 이전 스토리지 쉘프 모델을 지원해야 합니다.

  • 기존 쉘프에서 사용 가능한 스페어 디스크에 따라 추가 드라이브를 추가해야 합니다.

    추가 드라이브 쉘프가 필요할 수 있습니다.

    각 컨트롤러에 대해 14~18개의 드라이브를 추가해야 합니다.

    • 풀 0 드라이브 3개

    • 풀 1 드라이브 3개

    • 스페어 드라이브 2개

    • 시스템 볼륨용 드라이브 6개~10개

  • 새 노드를 포함한 구성이 드라이브 수, 루트 애그리게이트 크기 용량 등을 포함하여 구성에 대한 플랫폼 제한을 초과하지 않도록 해야 합니다

    이 정보는 에서 각 플랫폼 모델에 대해 사용할 수 있습니다 "NetApp Hardware Universe를 참조하십시오"

절차에 따라 MetroCluster 사이트에서 6개 노드 모두에 대해 원격 콘솔 액세스 권한이 있거나 사이트 간 이동 계획이 있어야 합니다.

데이터를 이동하고 오래된 스토리지 쉘프를 폐기할 때 시스템 중단을 야기하는 전환 워크플로우

성공적인 전환을 위해서는 특정 워크플로우를 따라야 합니다.

전환을 준비할 때 사이트 간 여행을 계획하십시오. 원격 노드가 랙에 설치되고 케이블이 연결된 후에는 노드에 대한 직렬 터미널 액세스가 필요합니다. 노드가 구성될 때까지 서비스 프로세서 액세스를 사용할 수 없습니다.

워크플로 2n 데이터 이동을 새로운 쉘프로 변환

구성을 전환하는 중입니다

자세한 전환 절차를 따라야 합니다.

이 작업에 대해

다음 단계에서는 다른 절차로 이동합니다. 각 참조 절차의 단계를 지정된 순서대로 수행해야 합니다.

단계
  1. 의 단계를 사용하여 포트 매핑을 계획합니다 "MetroCluster FC 노드의 포트를 MetroCluster IP 노드로 매핑".

  2. 의 단계를 사용하여 MetroCluster IP 컨트롤러를 준비합니다 "MetroCluster IP 컨트롤러 준비".

  3. MetroCluster FC 구성의 상태를 확인합니다.

    의 단계를 수행합니다 "MetroCluster FC 구성의 상태 확인".

  4. MetroCluster FC 구성에서 정보를 수집합니다.

  5. 필요한 경우 Tiebreaker 모니터링을 제거합니다.

  6. 기존 MetroCluster FC 노드를 준비하고 제거합니다.

    의 단계를 수행합니다 "MetroCluster FC 노드 전환".

  7. 새 MetroCluster IP 노드를 연결합니다.

    의 단계를 수행합니다 "MetroCluster IP 컨트롤러 모듈 연결".

  8. 새 MetroCluster IP 노드를 구성하고 전환을 완료합니다.

    의 단계를 수행합니다 "새 노드 구성 및 전환 완료".

루트 애그리게이트 마이그레이션

전환이 완료되면 MetroCluster FC 구성에서 남은 기존 루트 애그리게이트를 MetroCluster IP 구성의 새 쉘프로 마이그레이션할 수 있습니다.

이 작업에 대해

이 작업은 node_A_1-FC 및 node_B_1-FC의 루트 애그리게이트를 새 MetroCluster IP 컨트롤러가 소유하는 디스크 쉘프로 이동합니다.

단계
  1. 새 로컬 스토리지 쉘프에 있는 풀 0 디스크를 마이그레이션할 루트가 있는 컨트롤러에 할당합니다(예: node_A_1-FC의 루트가 마이그레이션되는 경우 새 셸프의 풀 0 디스크를 node_A_1-IP에 할당).

    migration_은 루트 mirror_를 제거하고 다시 생성하지 않으므로 migrate 명령을 실행하기 전에 풀 1 디스크를 할당할 필요가 없습니다

  2. 권한 모드를 고급으로 설정합니다.

    'et priv advanced'

  3. 루트 애그리게이트 마이그레이션:

    'system node migrate-root-node-name-disklist disk-id1, disk-id2, diskn-raid-type RAID-type'

    • node-name은 루트 애그리게이트를 마이그레이션할 노드입니다.

    • disk-id는 새 쉘프의 풀 0 디스크를 식별합니다.

    • RAID 유형은 일반적으로 기존 루트 애그리게이트의 RAID 유형과 동일합니다.

    • 'job show -idjob -id -instance' 명령을 사용하여 마이그레이션 상태를 확인할 수 있습니다. 여기서 job-id는 migrate-root 명령이 실행될 때 제공되는 값입니다.

      예를 들어, node_A_1-FC의 루트 애그리게이트가 RAID_DP의 디스크 3개로 구성된 경우 다음 명령을 사용하여 루트를 새 쉘프 11로 마이그레이션합니다.

    system node migrate-root -node node_A_1-IP -disklist 3.11.0,3.11.1,3.11.2 -raid-type raid_dp
  4. 마이그레이션 작업이 완료되고 노드가 자동으로 재부팅될 때까지 기다립니다.

  5. 원격 클러스터에 직접 연결된 새 쉘프의 루트 애그리게이트에 대해 풀 1 디스크를 할당합니다.

  6. 마이그레이션된 루트 애그리게이트를 미러링합니다.

  7. 루트 애그리게이트 재동기화가 완료될 때까지 기다립니다.

    storage aggregate show 명령을 사용하여 애그리게이트의 동기화 상태를 확인할 수 있습니다.

  8. 다른 루트 애그리게이트에 대해 이 단계를 반복합니다.

데이터 애그리게이트 마이그레이션

새 쉘프에서 데이터 애그리게이트를 생성하고 볼륨 이동을 사용하여 데이터 볼륨을 이전 쉘프에서 새 쉘프의 애그리게이트로 전송합니다.

  1. 데이터 볼륨을 새 컨트롤러의 aggregate로 한 번에 하나씩 이동합니다.

폐기 쉘프가 node_A_1-FC 및 node_A_2-FC에서 이동되었습니다

기존 스토리지 쉘프를 원래 MetroCluster FC 구성에서 제거합니다. 이 쉘프는 원래 노드_A_1-FC 및 노드_A_2-FC에 의해 소유되었습니다.

  1. 삭제해야 하는 cluster_B의 이전 쉘프에서 애그리게이트를 식별합니다.

    이 예제에서 다음 데이터 애그리게이트는 MetroCluster FC cluster_B에 의해 호스팅되므로 aggr_data_a1과 aggr_data_a2를 삭제해야 합니다.

    참고 쉘프의 데이터 애그리게이트를 파악하고, 오프라인 및 삭제하기 위한 단계를 수행해야 합니다. 이 예는 하나의 클러스터에만 해당됩니다.
    cluster_B::> aggr show
    
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    aggr0_node_A_1-FC
               349.0GB   16.83GB   95% online       1 node_A_1-IP      raid_dp,
                                                                       mirrored,
                                                                       normal
    aggr0_node_A_2-IP
               349.0GB   16.83GB   95% online       1 node_A_2-IP      raid_dp,
                                                                       mirrored,
                                                                       normal
    ...
    8 entries were displayed.
    
    cluster_B::>
  2. 데이터 애그리게이트에 MDV_AUD 볼륨이 있는지 확인하고 Aggregate를 삭제하기 전에 이를 삭제하십시오.

    이동할 수 없으므로 MDV_AUD 볼륨을 삭제해야 합니다.

  3. 각 애그리게이트를 오프라인 상태로 전환하고 삭제합니다.

    1. Aggregate를 오프라인 상태로 전환:

      'Storage aggregate offline-aggregate aggregate-name'을 선택합니다

      다음 예는 오프라인이 되는 Aggregate node_B_1_aggr0을 보여줍니다.

      cluster_B::> storage aggregate offline -aggregate node_B_1_aggr0
      
      Aggregate offline successful on aggregate: node_B_1_aggr0
    2. 애그리게이트 삭제:

      '스토리지 집계 삭제-집계 집계-이름'

      메시지가 표시되면 플렉스를 폐기할 수 있습니다.

      다음 예에서는 삭제 중인 Aggregate node_B_1_aggr0을 보여줍니다.

    cluster_B::> storage aggregate delete -aggregate node_B_1_aggr0
    Warning: Are you sure you want to destroy aggregate "node_B_1_aggr0"? {y|n}: y
    [Job 123] Job succeeded: DONE
    
    cluster_B::>
  4. 모든 애그리게이트를 삭제한 후, 전원을 끄고 연결을 끊고 쉘프를 제거합니다.

  5. 위의 단계를 반복하여 cluster_a 쉘프를 폐기합니다.

전이를 완료하는 중입니다

이전 컨트롤러 모듈을 제거한 상태에서 전환 프로세스를 완료할 수 있습니다.

단계
  1. 전환 프로세스를 완료합니다.