가동 중지 시간을 최소화하면서 한 서버에서 다른 서버로 데이터를 마이그레이션하는 방법은 무엇입니까?

가동 중지 시간을 최소화하면서 한 서버에서 다른 서버로 데이터를 마이그레이션하는 방법은 무엇입니까?

나는 상당히 큰 사용자 기반(약 10,000명의 사용자)을 갖고 있고 각 사용자의 할당량이 약 GB인 maildir 형식을 사용하여 dovecot을 실행하는 서버를 가지고 있습니다.

실제 메일 디렉토리는 NFS를 통해 이메일 서버에 마운트된 별도의 스토리지 시스템에 저장됩니다.

스토리지 시스템의 성능 문제로 인해 새로운 스토리지 시스템으로 업그레이드하고 있습니다. 이전 시스템에서 새 시스템으로 데이터를 직접 동기화했지만 프로세스에는 여전히 꽤 오랜 시간이 걸립니다(16시간 이상).

우리의 계획은 rsync를 지속적으로 실행하고 두 번째 작업이 완료되자마자 메일 서버에서 dovecot/qmail/etc를 삭제하고 설치 위치를 새 시스템으로 전환한 후 이메일을 복원하는 것입니다. 운이 좋다면 가동 중지 시간은 총 1~2분에 불과합니다. 문제는 마지막으로 rsync가 실행되었을 때 온 이메일이 여전히 복사되지 않는다는 것입니다. 따라서 이를 완화하기 위해 전환 후 일반적으로 사용하는 --delete 플래그를 사용하지 않고 다시 rsync를 수행합니다. 여기에는 몇 가지 문제가 있지만 내 관점에서 가장 큰 문제는 사용자가 전환 직전에 가지고 있던 이메일에 액세스할 수 없다는 것입니다.

가동 중지 시간을 최소화하고 시간을 낭비하지 않고 이 작업을 수행하는 방법에 대한 제안이 있는 사람이 있습니까? 이전 스토리지 시스템은 NetApp이었고, 새 시스템은 큰 산이 연결된 freebsd 상자일 뿐이며, 이메일 서버는 Ubuntu입니다.

마이그레이션이 완료될 때까지 사용자 관점에서 스토리지 시스템을 중첩할 수 있는 방법이 있어야 할 것 같은데, 어떻게 해야 할지 모르겠습니다(가능하다면).

답변1

당신은 다음과 같은 것으로 이것을 할 수 있습니다오브또는연합 파일 시스템.

두 파일 시스템 모두 "공동" 파일 시스템입니다. 당신은 다음과 같은 일을 할 것입니다

  • 기존 NAS를 설치하세요./mnt/old
  • 새 NAS를 다음 위치에 설치하세요./mnt/new
  • 여기 /mnt/nas에 통합 파일 시스템을 마운트합니다 ./mnt/new/mnt/old
  • 해당 쌍에 대한 모든 액세스는 /mnt/nas/foo/bar먼저 조회되며 /mnt/new/foo/bar존재하지 않는 경우 다시 대체됩니다 /mnt/old/foo/bar. 파일을 수정하면 원본 파일을 복사 /mnt/old/mnt/new다음 수정된 /mnt/new버전을 복사합니다.
  • rsync통합 파일 시스템을 마운트한 후 from 에서 까지 /mnt/old실행할 수 있습니다 /mnt/new. 이는 시스템이 실행되는 동안 수행될 수 있습니다. rsync가 파일을 저장하면 Access가 /mnt/nas파일을 선택하기 시작합니다 ./mnt/new

답변2

다음과 같이 계속하는 것은 어떻습니까?

  1. 첫 번째 동기화
  2. 421 Service not available, closing transmission channel배너에서 큐메일 답장 만들기
  3. 두 번째 동기화
  4. 큐메일의 원래 구성을 복원합니다(또는 다른 서버로 전환합니다. 해당 부분이 있는지 확실하지 않습니다)

이렇게 하면 고객이 나중에 이메일을 다시 보내려고 시도할 것이라고 믿을 수 있습니다.

답변3

스토리지 백엔드를 변경할 때 많은 다운타임을 피할 수는 없을 것 같지만 몇 가지 옵션이 있습니다. 그러나 최선의 선택은 귀하의 필요와 상황에 맞게 조정될 것입니다.

메시지를 임의로 삭제하지 않으려면 421, 450 또는 452로 응답하여 스토리지 시스템에 쓰기를 중지해야 합니다. 개인적으로 저는 450 "사용자 이메일을 사용할 수 없음"을 선택하겠습니다.

그래서 Rsync를 수행하고 450을 반환한 다음 rsync를 수행하고 마지막으로 변경 사항을 저장합니다.

이메일은 신뢰할 수 있는 것이 아니라는 점을 기억하세요. 그것이 바로 우리가 그것을보아야하는 방법입니다. 메시지를 수락할 수 없다는 것은 메시지를 보낸 서버가 다시 시도해야 함을 의미합니다. 일반적으로 이는 24시간 동안 4시간마다 수행되지만 이는 규칙이 아닌 "정상"일 뿐입니다.

그런데, NFS를 사용하지 않는 경우(또는 이와 같은 NFS 서버에 액세스할 수 있는 경우) 스토리지를 일종의 클러스터에 넣은 다음 새 스토리지를 클러스터에 추가하고 이전 스토리지를 제거할 수 있습니다. 이는 일종의 RAID(동일 머신에 있는 경우) 또는 DRBD와 같은 것을 사용하여 수행할 수 있습니다. 아이디어는 클러스터에 새 서버를 추가하는 일반적인 서버 업그레이드 경로를 따르고 "따라잡을" 시간을 준 다음 이전 서버를 제거한다는 것입니다.

관련 정보