내 서버에 며칠 안에 가득 차는 특정 파티션(/var)이 있습니다. 나는 모든 사용자 메일이 전송되는 바쁜 메일 서버를 운영하고 있습니다.
하지만 이제는 더 많은 이메일을 수용하기 위해 저장 공간을 늘려야 합니다.
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 796M 556K 796M 1% /run
/dev/sda6 254G 32G 209G 14% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 4.0K 5.0M 1% /run/lock
none 3.9G 80K 3.9G 1% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda1 188M 66M 114M 37% /boot
/dev/sda7 1.6T 1.2T 364G 76% /var
그래서 온라인에서 많은 정보를 확인하고 몇 가지 제안을 받았습니다.
내가 처음 접한 것은 LVM 파티셔닝을 사용하는 것이었습니다. 따라서 서버에 두 번째 하드 드라이브를 추가한 다음 LVM을 사용하여 두 하드 드라이브를 하나의 논리 파티션으로 병합할 수 있습니다. 이 작업을 정확히 수행하는 방법을 읽는 동안 드라이브 하나에 오류가 발생하면 데이터가 손실되고 쉽게 복구할 수 있는 방법이 없다는 내용을 읽었습니다. 이로 인해 두 번째 옵션을 찾게 되었습니다.
두 번째는 여러 디렉터리를 하나로 병합할 수 있는 통합 파일 시스템을 사용하는 것입니다. 지금까지 저는 Unionfs, aufs, mhddfs 및 overlayfs 구현을 접했습니다. 이 경우 두 번째 하드 드라이브를 부팅하거나 루트 디렉터리처럼 인구가 적은 파티션에서 일부 공간을 빌릴 수 있습니다.
주류 Linux 커널에 추가된 이후 로컬 호스트에서 overlayfs를 사용해 보았습니다.
많은 옵션이 있으며 프로덕션에 중요한 메일 서버에서 어떤 솔루션을 선택해야 할지 잘 모르겠습니다. 몇 가지 조언을 듣고 싶습니다. 감사해요.
답변1
우선, 여기서 파일 시스템 덮어쓰기/결합은 정답이 아닙니다. 이는 대부분의 데이터를 포함하는 읽기 전용 파일 시스템이 있고 쓰기 가능한 파일 시스템 위에 일부 제한된 사용자 정의가 필요한 상황입니다. 예를 들어 LiveCD는 오버레이 파일 시스템을 사용하여 쓰기 가능한 파일 시스템의 느낌을 허용합니다. 또는 미디어가 읽기 전용임에도 불구하고).
LVM은 여러분이 원하는 것이 거의 확실하며 반드시 신뢰할 수 없는 것은 아닙니다(복제를 통해 RAID 설정을 수행할 수 있음). 또는 새(더 큰) 하드 드라이브를 넣고 /var
맨 위에 놓을 수도 있습니다. 하지만 /var/mail
기본 메일 저장 디렉터리를 여기에 두고 나머지는 그대로 두는 것이 좋습니다.
이상적으로는 동일한 크기의 하드 드라이브를 여러 개 가져와서 /var/mail
상단 하드 드라이브에서 RAID10 또는 RAID5/6을 실행한 다음 사용자에게 오래된 이메일이 들어 있는 하드 드라이브를 정리하도록 하는 작업을 고려해야 합니다. 서버(이 상황은 대부분의 메일 제공업체가 서버의 메일 저장 용량에 제한을 두는 이유 중 일부입니다.)
답변2
가장 좋은 방법은 최소 2개의 대형 드라이브(예: 4TB 이상)를 추가하고 일종의 RAID-1 또는 RAID-10을 사용하는 것입니다. "미션 크리티컬" 서비스에 스토리지 중복성이 없는 경우 다음을 수행할 수 있습니다. 틀렸어.
두 개의 드라이브만 추가하는 경우 RAID-1을 사용하십시오. 4개 이상인 경우 RAID-10을 사용하십시오. 메일 저장에는 많은 I/O 대역폭이 필요하고 RAID-5는 RAID-1/RAID-10보다 훨씬 느리기 때문에 메일에는 RAID-5 또는 RAID-6을 사용하지 않는 것이 좋습니다(RAID-6은 훨씬 더 느림).
mdadm
, 및 를 포함하여 RAID-1/RAID-10을 구현하는 방법에는 여러 가지가 있습니다 lvm
. 이들 중 하나를 사용하여 RAID 어레이를 생성하고 원하는 파일 시스템으로 포맷한 다음 에 마운트할 수 있습니다 /var/mail
. 파일 시스템이 확장을 지원하는 한 나중에 필요에 따라 더 많은 드라이브를 추가할 수도 있습니다(예: xfs에는 있고 xfs_growfs
ext2/3/4에는 있습니다 resize2fs
).
또 다른 옵션은 를 사용하는 것입니다 btrfs
. RAID와 유사한 기능을 기본적으로 지원하며 더 많은 스토리지 드라이브를 추가하면 파일 시스템이 자동으로 확장됩니다. 또한 오류 감지 및 수정, 스냅샷, 하위 볼륨, 투명한 파일 압축 등을 지원합니다.
ZFS는 btrfs(제가 개인적으로 사용하는)와 비슷한 기능을 가지고 있지만, 메인라인 커널의 일부가 아니라는 것이 단점입니다(아마도 CDDL과 GPL 사이의 라이센스 비호환성으로 인해 발생하지 않을 것입니다). 패치 또는 DKMS 모듈로만 사용할 수 있습니다. 요즘에는 큰 문제가 아니지만 더 많은 작업을 수행해야 합니다.
내 제안은 btrfs 또는 zfs를 사용하는 것입니다. IMO 요즘에는 이미 사용하고 있고 해당 기술에 대한 많은 경험과 투자가 없다면 평범한 오래된 mdadm이나 lvm을 사용할 이유가 없습니다.
이 사이트에는 mdadm, lvm, btrfs 및/또는 zfs 등을 설정하는 방법을 자세히 설명하는 많은 질문과 답변이 있습니다.
그럼에도 불구하고 RAID 또는 RAID와 유사한 파일 시스템을 구현하는 방법에 관계없이 가동 중지 시간을 최소화하면서 오래된 메일을 새 파일 시스템으로 전송해야 합니다. 모든 경우에 프로세스는 다음과 유사합니다.
새 드라이브를 설치합니다. 핫 스왑 가능한 베이가 없으면 약간의 가동 중지 시간이 필요합니다.
새로운 RAID 및/또는 파일 시스템 설정
다음과 같이 설치하세요.
/var/mail.new
동기화
/var/mail/
대상/var/mail.new/
이 프로세스를 완료할 시간이 있을 때까지(가급적 근무 시간 외) 4단계를 필요한 만큼 반복할 수 있습니다. 1단계에서 발생할 수 있는 가동 중지 시간을 제외하고는 지금까지 사용자에게 표시되는 가동 중지 시간이 없어야 합니다. 기껏해야
rsync
작업이 실행될 때 시스템이 평소보다 약간 느리다는 것을 알아차렸을 것입니다.MTA(sendmail, exim, postfix 또는 기타) 및 pop/imap 데몬 및 기타 쓰기를 중지합니다
/var/mail/
. 메일을 읽기 위해 쉘에 로그인하는 사용자가 있는 경우(예: mutt 사용) 로그아웃하도록 지시합니다. 완료되면 이전에 다시 로그인하지 못하게 하세요.즉, 쓰기를 중지해야 하며
/var/mail
나중에 13단계에서 다시 시작해야 합니다.마지막 실행 이후의 모든 변경 사항을 동기화하려면 최종
rsync
from/var/mail/
to를 실행하세요./var/mail.new/
mv /var/mail /var/mail.old
mkdir /var/mail
마운트를 해제했다
/var/mail.new
가 다시 마운트합니다/var/mail
(아마도mount --move /var/mail.new /var/mail
Austin Hemmelgarn이 언급한 대로).소유권과 권한을 확인 하고 정확히 동일한지
/var/mail.old
확인하세요 ./var/mail
이는 다음을 통해 쉽게 수행할 수 있습니다.
chmod --reference=/var/mail.old /var/mail
( Linux에서는 표준인
--reference
GNU 버전이 필요합니다 .)chmod
재부팅 후 항상 새 파일 시스템을 마운트
/etc/fstab
하도록 편집되었습니다 ./var/mail
이제 MTA, pop 및 imap 서비스를 다시 시작하고 사용자가 다시 로그인하도록 허용할 수 있습니다. 제대로 작동하는지 면밀히 모니터링하세요.
여가 시간에 새 설정이 제대로 작동하고 이전 메일 디렉토리가 더 이상 필요하지 않다고 확신하면 해당 메일 디렉토리
/var/mail.old
와 해당 내용을 모두 삭제할 수 있습니다.
그건 그렇고, 이 작업을 수행하면 1TB 이상의 여유 공간이 확보됩니다 /var
. 이는 필요한 것보다 많을 수 있습니다.