섀도우 마이그레이션

그림 14-1  섀도우 마이그레이션

섀도우 마이그레이션은 삽입을 사용하지만 ZFSSA에 통합되며 별도의 물리적 시스템을 필요로 하지 않습니다. 공유를 만든 후에 필요에 따라 로컬로 또는 NFS를 통해 기존 디렉토리를 "섀도우" 처리할 수 있습니다. 이 시나리오에서는 작동 중지 시간이 한 번 예약되었습니다. 즉, 소스 ZFSSA X를 읽기 전용 모드에 놓고 섀도우 등록 정보 세트로 공유를 만들었으며 클라이언트가 Sun Storage 7000 ZFSSA의 새 공유를 가리키도록 업데이트되었습니다. 그러면 클라이언트가 읽기/쓰기 모드에서 ZFSSA에 액세스할 수 있습니다.

섀도우 등록 정보를 설정하면 백그라운드로 데이터가 소스 ZFSSA에서 로컬로 투명하게 마이그레이션됩니다. 아직 마이그레이션하지 않은 파일에 대해 클라이언트에서 요청을 보내면 요청에 응답하기 전에 ZFSSA가 이 파일을 로컬 서버로 자동 마이그레이션합니다. 이로 인해 일부 클라이언트 요청에 대해 초기 대기 시간이 발생할 수 있지만 파일을 마이그레이션하고 나면 모든 액세스가 ZFSSA에 대해 로컬로 이루어지고 고유의 성능을 갖추게 됩니다. 파일 시스템의 현재 작업 세트가 총 크기보다 훨씬 작은 경우가 많으므로 이 작업 세트를 마이그레이션한 후에도 소스의 총 고유 크기에 관계없이 성능이 받는 영향은 감지되지 않습니다.

섀도우 마이그레이션의 단점은 데이터 마이그레이션이 끝나기 전에 커밋이 필요하다는 점인데, 이는 삽입 방법에 해당되는 내용입니다. 마이그레이션 중에 일부 데이터는 두 위치에 존재하므로 백업이 더 복잡해질 수 있고 스냅샷이 불완전하거나 하나의 호스트에만 존재할 수 있습니다. 이 때문에 두 호스트 간 마이그레이션을 먼저 철저히 테스트하여 ID 관리와 액세스 제어가 올바로 설정되어 있는지 확인하는 것이 중요합니다. 전체 데이터 마이그레이션을 테스트할 필요는 없지만 읽을 수 없는 파일이나 디렉토리가 올바로 마이그레이션되고 ACL(있는 경우)이 보존되고 ID가 새 시스템에 올바로 나타나는지 확인해야 합니다.

섀도우 마이그레이션은 파일 시스템 내 온디스크 데이터를 사용하여 구현되므로 외부 데이터베이스가 없으며 데이터가 스토리지 풀 외부에 로컬로 저장되지 않습니다. 풀이 클러스터에서 페일오버되거나 두 시스템 디스크 모두 장애가 발생하고 새 헤드 노드가 필요할 경우 중단 없이 섀도우 마이그레이션을 계속하는 데 필요한 모든 데이터가 스토리지 풀과 함께 유지됩니다.