SRM 8.2 and SRA Hands-on

안녕하세요. 최근에 Site Recovery Manager 와 연동해서 쓰는 SRA (Site Replication Adapter) 에 대한 문의가 조금 있는편이여서, 아래와 같이 실습을 좀 해보았으니 구성에 참고하시기 바랍니다.

 

참고로 본 환경은 vSphere 6.7U3 + SRM8.2 환경이고 스토리지로 EMC Unity VSA 를 사용합니다. 물론 SRA 도 Unity SRA 입니다.

Unity VSA 를 사용한 이유는 그냥 제가 편하기 때문이고, 커뮤니티에디션으로 프리 라이센스를 통해 복제까지 수행할 수 있기 때문에 선택한 것이니, 각자가 편하신 스토리지(?) 를 사용하시면 되겠습니다.

 

일단 Unity 설치 자체 과정은 넘어가겠습니다. 일반 VM ova 과 설치는 크게 다른점은 없으나, Unisphere License 를 따로 받으셔야 한다는 것만 유의하시면 됩니다.  혹시나 설치 과정이 필요하신 분은 따로 코멘트 남겨주시면 추후에 한번 포스팅 해보겠습니다.

 

SRA 를 설치하시기 전에 유의하실 부분은 먼저 내가 사용할 SRA 가 SRM 의 어떤 버전 및 종류와 호환되는지를 확인하셔야 합니다.

특히 SRM 이 8.2 버전부터 Photon OS 기반의 Appliance 타입으로 설치가 가능하기 때문에, 내가 사용할 SRA 가 Windows 버전의 SRM 과 호환이 되는지 Appliance 타입의 SRM 과 호환이 되는지에 대한 확인이 먼저 필요합니다.

 

어디서 하느냐? VMware VCG 에서 하시면 됩니다. 아래 예에서는 제가 사용할 Unity SRA 를 확인해보겠습니다.

 

Windows 타입과 Appliance 타입 둘다 지원하는 것으로 나오네요

 

 

참고로 EMC SRDF SRA 의 경우에는 Windows 버전만 지원함으로 유념하시기 바랍니다. 어제 vSphere 7 이 GA 되면서 SRM 8.3 버전도 나왔는데요, vSphere 7 에서는 SRM 8.3 만 지원하오니 참고 하시기 바랍니다. 반대로 SRM 8.3 은 vSphere 6.0U3 이상과 호환됩니다. 만약 지금 환경을 vSphere 7 으로 변경한다 라고 하면 SRM 과 VR(사용하는경우) 의 업그레이드가 선행되어야 하겠죠. 여기서는 SRA 까지도요!

 

그럼 복제방식으로 vSphere Replication 을 사용하는 경우와 SRA 를 사용하는 경우 가장 큰 차이가 무엇이냐? 라고 물어보신다면 저는 복제 단위와 RDM 지원여부 라고 할 것 같습니다. VR 의 복제단위는 개별 VM 이고 SRA 의 복제단위는 Datastore Group 입니다. 그럼 시작해보죠.

 

SRA 설치

첫번째로 할일은 SRA 을 설치하는 것인데, 사실 이건 나중에 해도 상관은 없습니다. SRA 가 필요한 시점은 스토리지 레벨에서의 복제가 구성된 이후 이기 때문입니다.

 

Unity SRA 를 다운로드 받고 압축을 불편 tar.gz 파일이 하나 나옵니다.

 

SRM 의 관리페이지 (5480) 포트로 접속합니다. 왼쪽 하단에 보면 Storage Replication Adpaters 라는 항목이 있습니다.

 

클릭 후 New Adapter 를 클릭해서 다운로드 받았던 tar.gz 파일을 선택해 줍니다. 설치가 끝나면 아래와 같이 나옵니다.

 

 

Protected Site 및 Recovery Site 의 SRM 에 모두 설치하여 줍니다. 다음 Site Recovery Page 로 넘어가서 SRA 가 정상적으로 인식되는지 확인하여 줍니다. Rescan 을 수행해야 보일것입니다. 두개의 사이트에서 모두 보이는지 확인합니다.

 

 

그뒤에 Array Pairs 맺습니다.

 

1. SRA 선택

 

 

2. Local Array Manager 입력, Protected Site 에서 사용하는 스토리지 정보 입니다.

 

본 예의 경우에서는 Unity 의 Unisphere 접속시에 사용하는 스토리지 Management IP 를 입력하여 주시면 됩니다. 만약 여기서 추가가 정상적으로 안된다면 SRM 을 한번 Reboot 하시고 진행하시는 것을 권장합니다.

 

3. Remote Array Manager 는 DR 쪽의 스토리지 정보를 넣어주시면 되겠죠.

 

위 과정들이 확인되면 다음과 같이 보입니다. Array Pair 에는 스토리지의 시리얼 넘버가 보이고, Array Manager Pair 에서는 위에서 입력한 Array Manager 이름이 보입니다.

 

아래 그림에서는 이미 디바이스 정보들이 보이는데, 스토리지에서 복제 설정을 하기 전에는 Device 가 안보입니다. 그리고 스토리지에서 복제 설정을 한 이후에는 Discover Devices 를 수행을 해야 복제 수행중인 디바이스들이 정상적으로 보입니다.

 

 

스토리지에서 복제를 설정하는 과정은 생략하겠습니다. 여기까지 하면 SRA 를 사용하기 위한 사전작업은 끝입니다.

복제 방향은 참고로 Unity01 에서 Unity02 로 되어있습니다.

 

 

Protection Group 생성

저의 경우는 두가지 경우를 가지고 테스트를 진행했습니다.

 

1. RDM 이 없는 VM (Datastore : Unity01_VMFS) / VM 이름 SRM_CentOS

2. RDM 이 있는 VM  (Datastore : Unity00_VMFS) + RDM00  / VM 이름 : SRM_CentOS_RDM

 

Device 라는 관점에서 보면 실제로 복제가 수행되고 있는 Device 는 3개인 셈이죠. VMFS Datastore 2개 + RDM Device 1개

 

여기서 한가지 유의하실점은 Protected Site 에서는 복제가 수행되고 있는 디바이스 3개가 ESXi 호스트에서 인식이 된 상태여야 합니다.

반면 Recovery Site 에서는 디바이스가 인식되기 전의 상태만 되면 됩니다. 무슨 의미냐면 iSCSI 를 사용할 경우에는 Software iSCSI 에 타겟 정보까지만 입력이 되어 있으면 됩니다. 스토리지에서 Recovery Site 로의 Device 할당은 안해도 됩니다. 즉 평소에는 디바이스가 있다고 인식하지 않는 상태이면 됩니다. 잘 이해가 안되실수도 있는데 아래 그림으로 보여드리겠습니다. 만약 FC 라면 Zoning 까지만 되어있으면 될것 같습니다. 본 예에서는 iSCSI 를 사용합니다.

 

저도 처음에 이걸 할당을 해야되나 말아야 되나 깅가밍가 했는데, 테스트 결과로는 SRM + SRA 가 알아서 한다 입니다. 나중에 보여드리겠습니다.

 

Protected Site iSCSI Adapter

 

위의 2개가 VMFS, 아래 1개가 RDM 용 디바이스 입니다. 스토리지상에서도 당연히 할당이 되어있겠죠.

 

 

Recovery Site 타겟 정보는 있으나 인식중인 볼륨은 없습니다.

 

 

Unity Storage 상에서도 디바이스는 있으나, 해당 디바이스들은 Recovery 사이트 쪽 호스트에 할당이 안되어있습니다.

 

자 Protection Group 생성 시작해보겠습니다.

 

1. 이름입력 및 방향 선택

 

 

2. 타입선택. SRA 를 사용하는 경우라면 Datastore Group 을 선택해야 합니다. VR 일 경우에는 Indivisual VMs 를 고르구요.

 

 

3. Datastore Group 선택.

이번 예에서는 RDM 있는 VM 과 없는 VM 를 구분하기 위해서 제가 Datastore 를 분리해 놓았습니다. 만약 RDM 유무과 관계없에, VM 들이 복제대상 Datastore 에 들어가있으면 별도 선택은 불가능합니다.

 

SRM_CentOS (RDM 없는 VM)

 

 

SRM_CentOS_RDM (RDM 있는 볼륨) – RDM 볼륨이 같이 선택됩니다.

 

 

만약 RDM 이 붙어있는 VM 인데 RDM 이 복제되지 않고 있다면 마지막에 에러메세지가 출력됩니다. 이 이야기는 바꿔말하면 특정 볼륨만 때서 복제할 수는 없다는 이야기 입니다.(DATA 만 복제하고 싶어요.. 라던가..)

 

– Operation Failed Unable to protect VM ‘SRM_CentOS_RDM’ due to unresolved devices

 

마찬가지로 VMFS 볼륨이 복제되지 않고 있다면 또 에러메세지가 뜨겠죠.

 

일단 둘다 넣고 만들어보겠습니다. 기존의 SRM 내의 인벤토리 매핑작업은 이미 완료된 상태여서 생략하겠습니다.

 

 

생성은 잘 되었네요.

 

 

자 그럼 잘 되나 테스트 Failover 한번 해보겠습니다.

그전에 Recovery Site 에서 한번 보면, 아래와 같이 Placeholder VM 으로 보입니다. Power on 등은 불가능한 상태입니다.

 

 

간혹 이 복제 대상 VM 들을 Power on 할 수 있냐 라는 문의가 있는데… 안됩니다..

스토리지 레벨에서 보면 복제 대상 Device 들은 Target 쪽이 일반적으로 Read-only 이기 때문에.. VM 을 Power on 할 수 없는 상태인거죠. Write 가 안되니까요.. 아래 그림을 보시면 전부 Gray 처리가 되어서 어떤 오퍼레이션도 안됍니다.

 

 

자 그럼 한번 해보죠. Recovery Plan 의 경우 크게 보면 Test Failover 와 Planned Migration 그리고 Disaster Recovery 로 구분할 수 있습니다.

 

Test Recovery Plan

 

Test Recovery Plan 과 다른 방식의 차이점은 Recovery Site 로 복제중인 볼륨을 가져다 쓰는게 아니고 Writable Snapshot 을 만들어서 테스트 한다는 것입니다. 그럼 실제로 복제중인 LUN 은 사용할 필요가 없죠. 이게 왜필요하느냐, 위에서 말씀드린바와 같이 복제중인 볼륨은 Read-only 상태이고, Read-only 중인 볼륨을 Write 가 가능하게 만들려면 복제 솔루션마다 좀 차이는 있으나, 보통 둘중에 하나입니다.

 

1. 복제를 아에 끊거나 (주로 Midrange 급 스토리지) –> 복제를 다시 할때 풀 복제 필요

2. 복제를 잠시 중지한상태에서 Write 가능하게 만들어주거나 (주로 Highend 급 스토리지) –> 복제를 다시 할때 풀 복제 필요없음

 

테스트할때마다 매번 풀복제를 걸수는 없으니 복제중인 볼륨은 냅두고 해당 볼륨의 스냅샷을 찍는거죠. 그 과정을 SRA 가 해준다고 보시면 되겠습니다.

 

 

아래 옵션은 Test failover 시에 마지막으로 복제로 싱크를 맞출것이냐라는 질문입니다. 

 

 

복제가 Sync 방식의 복제라면 굳이 필요하지 않을 것이고, Async 라면 테스트전에 한번 더 맞춰보겠다, 아니면 RPO 에 맞춰서 뭐 한 30분 전의 복제데이터를 가지고 하겠다 등등의 필요요건에 따라 하시면 되고요, 전 굳이 필요없으니까 체크 풀고 해보겠습니다.

 

위에서 말씀드린 Writable 한 스냅샷을 찍는 과정입니다.

 

 

 이 과정을 스토리지에서 보면 다음과 같이 SRM-TEST-Failover 라는 스냅샷이 생성된 것을 확인할 수 있습니다.

 

 

그리고 이 스냅샷 볼륨들은 Read/Write 가 가능한 상태로 Recovery Site 의 호스트에 할당되구요.

 

 

Test Recovery Plan 이 잘 수행되면 아까 Placeholder VM 들이 Power on 되어있는것을 볼 수 있습니다.

 

 

그리고 호스트에 보면 스냅샷 볼륨들이 마운트 되어있습니다.

 

 

보시면 Datastore 이름이 snap-xxxxx 로 시작된게 보이시죠. 이렇게 변경되는 이유는 이전의 Snapshot LUN 에 대한 포스트를 보신 분들이라면 짐작하시겠지만 해당 볼륨에 대한 Resignature 작업이 진행됐기 때문입니다. 그걸 해야되는이유는 저걸 안하고 붙이면 Snapshot LUN 으로 인식하게 되어서 제약사항이 생기기 때문이죠. SRM+SRA 가 없는 상태에서는 사람이 수동으로 해야하는데, 있는 환경에서는 자동으로 해주는 것입니다.

 

VM 도 잘 동작하는것이 확인되었습니다. 그럼 테스트를 종료하겠습니다.

 

 

VM 들이 다시 Power off 되고, 호스트에 붙어있던 볼륨들이 다 사라집니다.

 

 

스토리지에서도 생성되었던 Snapshot 이 삭제된것을 볼 수 있습니다.

 

그럼 Test Recovery Plan 은 종료되었습니다. 다음은 Planned Migration 입니다.

 

Planned Migration

 

 

Planned Migration 을 선택합니다.  Planned Migration 은 Protected Site <-> Recovery Site 간 통신이나 연결이 정상적인 경우에만 사용할 수 있습니다. 만약 어느한쪽이라도 연결이 안된다면, Disaster Recovery 만 가능합니다.

 

 

이때에는 싱크를 맞추기 위한 복제 과정이 무조건 들어갑니다.(두번 들어갑니다. VM Power off 하기전 한번, Power off 한 후 한번. 그리고 Protected Site 의 VM 들도 Power off 되고, Protected Site 에 있던 VM 들이 Placeholder VM 이 됩니다.

 

 

자 복구가 Recovery Complete 메세지가 확인 됍니다.

 

아까와 마찬가지로 호스트에서는 볼륨들이 자동으로 연결됍니다.

 

반대로 원래의 Protected Site 에서는 볼륨들이 다 떨어져 나간것을 확인할 수 있습니다. (Detached 상태) – Rescan 하면 없어집니다.

 

아까 Test 시와 조금 차이점이 있죠. 그외에 차이점은 스토리지에서 봤을때 Snapshot 이 없다는 것입니다. 왜냐면 복제하고 있는 볼륨 자체를 붙인것이니까요.

스토리지의 복제 상태는 Failover 로 변경됩니다.

 

 

Failover 자체는 잘 끝난것이죠.

 

이 때, 다시 Failover 된 VM 들을 다시 보호하겠다 라고 하면 Reprotect 를 선택하면 됩니다.

 

그럼 어떻게 되느냐, VM 의 복제방향이 역방향으로 바뀝니다. 스토리지에서 보면 알 수 있습니다. (Unity01 –> Unity02 였던 복제방향이 Unity02 –> Unity01 로 변경)

 

 

처음 상태로 돌릴려면 다시 Recovery Plan 을 RUN 하고 Reprotect 해주면 됩니다. 마지막에 Datastore 이름들을 원래대로 변경해주시면 되겠습니다. 이거는 안해주더라고요.

 

Disaster Recovery 는 다음시간에.. 글이 너무 길어져서.. ^^