섀도우 마이그레이션 이해

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

그림 5-11  섀도우 마이그레이션

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

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

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

다음은 섀도우 소스에 대한 제한 사항을 나열합니다.

• 데이터를 올바르게 마이그레이션하기 위해 소스 파일 시스템 또는 디렉토리는 *읽기 전용*이어야 합니다. 파일 소스에서 변경한 사항은 타이밍을 기준으로 전파되거나 전파되지 않을 수 있으며, 디렉토리 구조에서 변경한 사항은 어플라이언스에 복구할 수 없는 오류를 발생시킬 수 있습니다.

• 섀도우 마이그레이션은 NFS 소스에서만 마이그레이션을 지원합니다. NFSv4 공유는 최상의 결과를 생성합니다. NFSv2 및 NFSv3 마이그레이션도 가능하지만 ACL이 프로세스 중에 손실되며, NFSv2의 경우 너무 큰 파일은 해당 프로토콜을 사용하여 마이그레이션할 수 없습니다. SMB 소스로부터의 마이그레이션은 지원되지 않습니다.

• LUN의 섀도우 마이그레이션은 지원되지 않습니다.

마이그레이션 동안 클라이언트가 아직 마이그레이션되지 않은 파일이나 디렉토리에 액세스할 경우에는 동작에 따른 효과를 관찰할 수 있습니다. 다음은 섀도우 파일 시스템 의미를 나열합니다.

• 디렉토리의 경우 전체 디렉토리가 마이그레이션될 때까지 클라이언트 요청이 차단됩니다. 파일의 경우 요청된 파일의 일부만 마이그레이션되며, 여러 클라이언트가 동시에 파일의 다른 부분을 마이그레이션할 수 있습니다.

• 파일 및 디렉토리는 마이그레이션 프로세스에 영향을 주지 않고 섀도우 파일 시스템에서 임의로 이름을 바꾸거나 제거하거나 덮어쓸 수 있습니다.

• 하드 링크인 파일의 경우 마이그레이션이 완료될 때까지 하드 링크 개수가 소스와 일치하지 않을 수 있습니다.

• 파일 속성의 대다수는 디렉토리를 만들 때 마이그레이션되지만 온디스크 크기(UNIX stat 구조의 st_nblocks)는 파일에서 읽기 또는 쓰기 작업이 완료될 때까지 사용할 수 없습니다. 논리적 크기는 올바르지만 파일 내용이 실제로 마이그레이션될 때까지 du(1) 또는 기타 명령이 크기 0을 보고합니다.

• 어플라이언스를 재부트하면 마이그레이션이 원래 중단되었던 위치부터 다시 시작됩니다. 데이터를 다시 마이그레이션하지 않지만 로컬 파일 시스템의 이미 마이그레이션된 일부를 순회해야 할 수 있으므로 중단으로 인해 총 마이그레이션 시간에 영향을 줄 수 있습니다.

• 데이터 마이그레이션은 파일의 확장된 개인 속성을 활용합니다. 이는 파일 시스템의 루트 디렉토리에서나 스냅샷을 통해서가 아니면 일반적으로 관찰할 수 없습니다. SUNWshadow로 시작하는 확장된 속성을 추가, 수정 또는 제거하면 마이그레이션 프로세스가 정의되지 않은 영향을 받으며 불완전 또는 손상 상태에 이르게 됩니다. 또한 파일 시스템 차원의 상태가 파일 시스템의 루트에 있는 .SUNWshadow 디렉토리에 저장됩니다. 이 컨텐츠에 대한 모든 수정은 비슷한 영향을 받습니다.

• 파일 시스템이 마이그레이션을 완료하면 경보가 게시되고 해당되는 메타 데이터와 함께 섀도우 속성이 제거됩니다. 이 시점 이후에는 파일 시스템을 일반 파일 시스템과 구분할 수 없습니다.

• 데이터는 NFSv4 자동 클라이언트 마운트("미러 마운트"라고도 함) 또는 중첩 로컬 마운트를 사용하여 여러 파일 시스템에서 단일 파일 시스템으로 마이그레이션할 수 있습니다.

다음 규칙을 사용하여 ACL을 비롯한 파일에 대한 ID 정보를 마이그레이션할 수 있습니다.

• 마이그레이션 소스 및 대상 어플라이언스에는 동일한 이름 서비스 구성이 있어야 합니다.

• 마이그레이션 소스 및 대상 어플라이언스에는 동일한 NFSv4 mapid 도메인이 있어야 합니다.

• 마이그레이션 소스가 NFSv4를 지원해야 합니다. NFSv3도 사용할 수 있지만 일부 정보가 손실될 수 있습니다. 기본 ID 정보(소유자 및 그룹) 및 POSIX 권한이 보존되지만 ACL은 손실됩니다.

• 마이그레이션 소스는 어플라이언스에 대한 루트 권한과 함께 내보내야 합니다.

"nobody"가 소유하는 파일이나 디렉토리를 발견할 경우 어플라이언스에서 이름 서비스가 올바로 설정되지 않았거나 NFSv4 mapid 도메인이 다르다는 뜻일 수 있습니다. 파일 시스템을 순회하는 동안(오류가 없으면 클라이언트가 액세스할 수 있는 파일 시스템) '사용 권한 거부' 오류가 나타나는 경우 루트 권한으로 마이그레이션 소스를 내보내지 못한 것이 문제일 가능성이 큽니다.