스토리지 쉘프를 폐기할 때 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은 사용 중인 장치에서 콘솔 로깅을 사용하도록 설정하고 이 절차를 수행할 때 다음 작업을 수행할 것을 적극 권장합니다.
-
유지 관리 중에는 AutoSupport를 활성화된 상태로 둡니다.
-
유지 관리 전후에 유지 관리 AutoSupport 메시지를 트리거하여 유지 관리 활동 기간 동안 케이스 생성을 비활성화합니다.
기술 자료 문서를 "예약된 유지 보수 기간 동안 자동 케이스 생성을 억제하는 방법"참조하십시오.
-
모든 CLI 세션에 대해 세션 로깅을 설정합니다. 세션 로깅을 활성화하는 방법에 대한 지침은 기술 자료 문서의 "로깅 세션 출력" 섹션을 "ONTAP 시스템에 대한 최적의 연결을 위해 PuTTY를 구성하는 방법"참조하십시오.
기존 쉘프를 폐기할 때 필요한 전환 요구 사항
전환 프로세스를 시작하기 전에 기존 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개 노드 모두에 대해 원격 콘솔 액세스 권한이 있거나 사이트 간 이동 계획이 있어야 합니다.
데이터를 이동하고 오래된 스토리지 쉘프를 폐기할 때 시스템 중단을 야기하는 전환 워크플로우
성공적인 전환을 위해서는 특정 워크플로우를 따라야 합니다.
전환을 준비할 때 사이트 간 여행을 계획하십시오. 원격 노드가 랙에 설치되고 케이블이 연결된 후에는 노드에 대한 직렬 터미널 액세스가 필요합니다. 노드가 구성될 때까지 서비스 프로세서 액세스를 사용할 수 없습니다.
구성을 전환하는 중입니다
자세한 전환 절차를 따라야 합니다.
다음 단계에서는 다른 절차로 이동합니다. 각 참조 절차의 단계를 지정된 순서대로 수행해야 합니다.
-
의 단계를 사용하여 포트 매핑을 계획합니다 "MetroCluster FC 노드의 포트를 MetroCluster IP 노드로 매핑".
-
의 단계를 사용하여 MetroCluster IP 컨트롤러를 준비합니다 "MetroCluster IP 컨트롤러 준비".
-
MetroCluster FC 구성의 상태를 확인합니다.
의 단계를 수행합니다 "MetroCluster FC 구성의 상태 확인".
-
MetroCluster FC 구성에서 정보를 수집합니다.
의 단계를 수행합니다 "전환 전에 기존 컨트롤러 모듈에서 정보를 수집합니다".
-
필요한 경우 Tiebreaker 모니터링을 제거합니다.
의 단계를 수행합니다 "Tiebreaker 또는 기타 모니터링 소프트웨어에서 기존 구성 제거".
-
기존 MetroCluster FC 노드를 준비하고 제거합니다.
의 단계를 수행합니다 "MetroCluster FC 노드 전환".
-
새 MetroCluster IP 노드를 연결합니다.
의 단계를 수행합니다 "MetroCluster IP 컨트롤러 모듈 연결".
-
새 MetroCluster IP 노드를 구성하고 전환을 완료합니다.
의 단계를 수행합니다 "새 노드 구성 및 전환 완료".
루트 애그리게이트 마이그레이션
전환이 완료되면 MetroCluster FC 구성에서 남은 기존 루트 애그리게이트를 MetroCluster IP 구성의 새 쉘프로 마이그레이션할 수 있습니다.
이 작업은 node_A_1-FC 및 node_B_1-FC의 루트 애그리게이트를 새 MetroCluster IP 컨트롤러가 소유하는 디스크 쉘프로 이동합니다.
-
새 로컬 스토리지 쉘프에 있는 풀 0 디스크를 마이그레이션할 루트가 있는 컨트롤러에 할당합니다(예: node_A_1-FC의 루트가 마이그레이션되는 경우 새 셸프의 풀 0 디스크를 node_A_1-IP에 할당).
migration_은 루트 mirror_를 제거하고 다시 생성하지 않으므로 migrate 명령을 실행하기 전에 풀 1 디스크를 할당할 필요가 없습니다
-
권한 모드를 고급으로 설정합니다.
'et priv advanced'
-
루트 애그리게이트 마이그레이션:
'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
-
-
마이그레이션 작업이 완료되고 노드가 자동으로 재부팅될 때까지 기다립니다.
-
원격 클러스터에 직접 연결된 새 쉘프의 루트 애그리게이트에 대해 풀 1 디스크를 할당합니다.
-
마이그레이션된 루트 애그리게이트를 미러링합니다.
-
루트 애그리게이트 재동기화가 완료될 때까지 기다립니다.
storage aggregate show 명령을 사용하여 애그리게이트의 동기화 상태를 확인할 수 있습니다.
-
다른 루트 애그리게이트에 대해 이 단계를 반복합니다.
데이터 애그리게이트 마이그레이션
새 쉘프에서 데이터 애그리게이트를 생성하고 볼륨 이동을 사용하여 데이터 볼륨을 이전 쉘프에서 새 쉘프의 애그리게이트로 전송합니다.
-
데이터 볼륨을 새 컨트롤러의 aggregate로 한 번에 하나씩 이동합니다.
폐기 쉘프가 node_A_1-FC 및 node_A_2-FC에서 이동되었습니다
기존 스토리지 쉘프를 원래 MetroCluster FC 구성에서 제거합니다. 이 쉘프는 원래 노드_A_1-FC 및 노드_A_2-FC에 의해 소유되었습니다.
-
삭제해야 하는 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::>
-
데이터 애그리게이트에 MDV_AUD 볼륨이 있는지 확인하고 Aggregate를 삭제하기 전에 이를 삭제하십시오.
이동할 수 없으므로 MDV_AUD 볼륨을 삭제해야 합니다.
-
각 애그리게이트를 오프라인 상태로 전환하고 삭제합니다.
-
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
-
애그리게이트 삭제:
'스토리지 집계 삭제-집계 집계-이름'
메시지가 표시되면 플렉스를 폐기할 수 있습니다.
다음 예에서는 삭제 중인 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::>
-
-
모든 애그리게이트를 삭제한 후, 전원을 끄고 연결을 끊고 쉘프를 제거합니다.
-
위의 단계를 반복하여 cluster_a 쉘프를 폐기합니다.
전이를 완료하는 중입니다
이전 컨트롤러 모듈을 제거한 상태에서 전환 프로세스를 완료할 수 있습니다.
-
전환 프로세스를 완료합니다.
의 단계를 수행합니다 "시스템을 정상 작동 상태로 되돌리기".