컨텍스트: 우리는 온-프레미스 NFS 파일 시스템과 Azure NFS 기반 파일 공유 간의 데이터 동기화와 관련된 데이터 마이그레이션 프로젝트를 진행하고 있습니다. 목표는 데이터 무결성과 효율성을 유지하면서 온-프레미스 환경에서 Azure로 원활하게 전환하는 것입니다.
배경:
출처: 온프레미스 NFS 파일 시스템.
대상: Azure NFS 기반 파일 공유.
데이터 크기: 약 350GB.
도구 사용법:
AzCopy(지원되지 않음): 처음에는 데이터 마이그레이션에 AzCopy를 사용하려고 시도했지만 Azure NFS 파일 시스템에서는 지원되지 않는다는 것을 발견했습니다.
Rsync(스토리지 증가 문제): 그런 다음 데이터 동기화를 위해 Rsync를 사용했습니다. 그러나 Azure 대상에서 스토리지가 크게 증가하여 프로세스가 완료되지 않았습니다. 뚜렷한 이유 없이 스토리지가 계속 늘어나서 Rsync 프로세스를 포기해야 했습니다.
Fpsync(성공적인 첫 번째 시도): 스토리지 증가 문제를 해결하기 위해 데이터 동기화를 Fpsync로 전환했습니다. 첫 번째 시도에서는 초기 동기화를 성공적으로 완료해 가능성을 보였다.
문제: 설명할 수 없는 스토리지 증가: 주요 과제는 Azure NFS 대상, 특히 Rsync의 경우 스토리지 사용률이 설명할 수 없이 증가한다는 것입니다. 소스 데이터 크기가 동일하게 유지되더라도 대상 스토리지가 크게 늘어나 프로세스를 관리하기 어려워집니다.
목표: 우리는 이러한 스토리지 증가 문제를 해결하는 데 도움이 되는 통찰력, 조언 또는 솔루션을 커뮤니티로부터 찾고 있습니다. 우리의 목표는 Azure 대상에서 효율적인 데이터 동기화와 최소한의 스토리지 사용량을 보장하는 것입니다.
추가 정보: 숨겨진 파일 및 디렉터리를 포함한 소스 데이터의 형식과 이름이 올바르게 지정되었습니다.
동기화 중에 권한이 유지됩니다.
첫 번째 동기화를 위해 Fpsync를 사용하여 초기에 성공했지만 후속 동기화에서는 여전히 스토리지 증가 문제가 나타났습니다. 이 문제와 관련된 제안, 통찰력 또는 경험을 주시면 감사하겠습니다. 우리는 이 문제를 해결하고 Azure NFS로의 성공적인 데이터 마이그레이션을 보장하기 위해 노력하고 있습니다.
업데이트:
이제 rclone 유틸리티를 사용했는데 동일한 문제가 발생했습니다.
답변1
주의 깊게 읽으십시오 man rsync. --dry-run --itemize-changes 정확히 어떤 작업이 수행되는지 확인하려면 몇 가지 옵션을 사용해 보세요 .
삭제 옵션을 제공하지 않으면 소스에서 삭제해도 대상에 반영되지 않습니다. 보관 사용 사례에는 적합하지만 날짜 스탬프가 찍힌 로그 파일과 같이 보존 기간이 제한된 파일에는 적합하지 않습니다. 또한 매뉴얼 페이지에 따라 파일을 삭제하려면 * 와일드카드를 사용하지 마십시오.
--delete
This tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending
side), but only for the directories that are being synchronized. You must have asked rsync to send
the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory's contents
(e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer
individual files, not the files' parent directory.
"기본 동작은 연결된 대상 파일과 동일한 디렉터리에 각 임시 파일을 만드는 것입니다." 이러한 임시 파일을 사용하면 전송을 중단할 수 있지만 상당한 추가 공간이 필요합니다. 보수적으로 모든 것을 업데이트해야 하는 최악의 시나리오에서는 소스 크기가 두 배라고 가정합니다. 이 동작을 변경하는 방법 중 아마도 가장 공격적인 방법은 --inplace파일을 직접 덮어쓰는 것입니다. 위험: 대상에서 사용 중인 파일이 손상되며 활성/활성 사용 사례에는 해당되지 않습니다.
성능과 관련하여 로컬 및 원격 시스템 모두에서 제한 요소가 무엇인지 찾아보세요. 최악의 경우를 계산해 보면 100 IOPS 느린 스핀들에 있는 백만 개의 파일이 파일 목록을 열거하고 비교하는 데만 몇 시간이 걸릴 수 있습니다. 그러나 파일 데이터를 복사할 때 병목 현상은 네트워크 대역폭과 SSH 및 압축을 위한 CPU로 전환될 수 있습니다.
파일 동기화 도구가 아닌 초기 복사본에 대한 대체 계획을 생각해 보십시오. 예를 들어 공유의 로컬 백업을 수행하고 해당 NFS가 탑재된 Azure의 호스트로 복원합니다. 증분 파일 동기화에 비해 네트워크를 통해 아카이브(.tar 등)를 복사하고 모두 추출하는 것이 더 빠르고 간단합니다.
말하자면, rsync는 초기 복사 후 상황을 따라잡기 위한 증분으로 유용할 수 있습니다. 비교하는 데 여전히 시간이 좀 걸리지만, 변경률이 낮고 복사할 내용이 많지 않으면 훨씬 더 빠릅니다.