.png)
iSCSI 디스크 배열에 파일을 저장하는 NFS 서버(Linux)가 있습니다. 이 서버는 생산 중입니다. 서버와 어레이가 매우 오래되어 곧 교체해야 합니다(어레이는 이미 심각한 문제에 처해 있습니다).
다른 네트워크에 교체 서버와 어레이가 준비되어 있습니다.
나는 공유를 재동기화한 다음 다시 수행하여 데이터를 동기화하는 것에 대해 생각해 왔습니다. 데이터 불일치가 발생할 수 있는지는 모르겠습니다... 공유가 lvm 위에 마운트되어 있으므로 먼저 스냅샷을 만들 수 있을까요?
질문:
모든 데이터를 마이그레이션하는 가장 좋은 방법은 무엇입니까? 조언이 있나요?
답변1
두 번째 rsync 전에 어레이에 쓰기를 비활성화하려는 경우 접근 방식은 괜찮습니다. 그러면 깨끗한 복사본이 생성됩니다.
상황에 따라 가동 중지 시간을 최소화하려면 삼중 rsync를 수행하세요.
- 소스 서버가 있는 그대로 실행되는 동안 파일 시스템을 rsync합니다. 이 작업은 시간이 좀 걸리고 대략적인 사본을 얻을 수 있으며 아마도 많은 불일치가 있을 수 있습니다.
- (선택 사항) #1이 시간이 오래 걸리고 그 동안 쓰기 작업이 많은 경우, 그대로 실행 중인 원본 서버와 다시 rsync하십시오. 이 단계는 시간이 덜 걸리므로 훨씬 더 나은 복사본을 얻을 수 있습니다(실행 중 발생하는 쓰기 횟수가 적음).
- 소스 노드에 대한 쓰기를 중지합니다. 가장 좋은 방법은 돌이 제안한 대로 읽기 전용으로 마운트하는 것입니다. 그러나 서비스를 종료하거나 단일 사용자 모드를 사용하는 것도 가능합니다.
- 마지막으로 다시 동기화하세요. 이번에는 좀 빨라야 할 것 같습니다. 불일치가 많지 않아야 하므로(2단계는 #1보다 훨씬 짧음) 동기화할 것이 많지 않습니다.
- 확인을 수행하고 이전 서버 대신 새 서버를 시작하십시오.
하지만 몇 가지 참고할 사항이 있습니다.
- 작은 파일(수백만 개)이 많으면 모든 rsync에 시간이 좀 걸립니다. (느린 회선, 느리거나 저하된 저장소 등의 경우에도 마찬가지입니다.)
- 소스 스토리지에 이미 문제가 있는 경우(드라이브 장애 또는 볼륨을 읽을 수 없게 만드는 기타 요인) #3부터 시작하세요. 가동 중지 시간이 길어지지만 전송 중에 실패할 위험을 최소화할 수 있습니다.
- 방금 전체 장치를 재동기화하고 파일 시스템이 상주한다는 미친 아이디어를 얻었습니다. 대상이 소스보다 크면 작동할 수 있습니다. 하지만 직접 시도해본 적이 없기 때문에 권장하지는 않습니다.
답변2
Rsync+rsync 또는 snapshot+rsync는 실제로 큰 차이를 만들지 않습니다. 추가 명령을 사용할 필요 없이 전송 중에 결국 데이터를 압축/암호화할 수 있기 때문에 rsync가 더 편리할 수 있습니다. 두 경우 모두 아직 전송 중인 부분 파일을 포함하여 마지막 rsync 이후 사용자가 공유에 복사한 내용을 영원히 따라잡으려고 노력하게 됩니다. 솔직히 제가 여러분에게 추천하고 싶은 것은 사용량이 적은 기간에 rsync를 사용하여 첫 번째 복사본을 만드는 것입니다. 그런 다음 필요한 유지 관리로 인해 약간의 중단이 있을 것이라고 사용자에게 경고합니다. 디스크에 서비스 쓰기를 중지합니다. 읽기 전용 모드로 이전 공유를 다시 마운트하고 최종 rsync를 수행한 다음 이전 nfs 공유를 새 공유로 완전히 교체합니다. 원하거나 가능하다면 해당 기간 동안 고객에게 읽기 전용 액세스 권한을 부여할 수 있습니다. 100% 가용성은 순수한 꿈이며, 손실/손상된 데이터 및 애플리케이션 충돌에 대한 끝없는 불만을 쫓아다니는 것보다 고객을 1시간 동안 멈추는 것이 더 낫습니다.