Zimbra Collaboration Suite에서 메일 저장 최적화

우리 중 하나에서 이전 기사는 기업에서 Zimbra Collabortion Suite를 구현할 때 인프라 계획을 전담하는 것으로, 이 솔루션 운영의 주요 제한 사항은 메일 저장소에 있는 디스크 장치의 I/O 속도라고 합니다. 실제로 수백 명의 기업 직원이 동일한 메일 저장소에 동시에 액세스하는 경우 하드 드라이브에서 정보를 쓰고 읽는 데 필요한 채널 폭이 서비스의 응답 운영에 충분하지 않을 수 있습니다. Zimbra의 소규모 설치의 경우 이것이 특별한 문제가 되지 않는다면 대기업 및 SaaS 제공업체의 경우 이 모든 것이 이메일 응답이 없어 결과적으로 직원 효율성이 저하되고 위반이 발생할 수 있습니다. SLA의 그렇기 때문에 대규모 Zimbra 설치를 설계하고 운영할 때 메일 저장소의 하드 드라이브 성능을 최적화하는 데 특별한 주의를 기울여야 합니다. 두 가지 사례를 살펴보고 각 사례에 디스크 스토리지의 로드를 최적화하기 위해 어떤 방법을 적용할 수 있는지 알아보겠습니다.

1. 대규모 Zimbra 설치 설계 시 최적화

부하가 높은 Zimbra 설치의 설계 단계에서 관리자는 사용할 스토리지 시스템을 선택해야 합니다. 이 문제를 결정하려면 하드 드라이브의 주요 로드가 Zimbra Collaboration Suite에 포함된 MariaDB DBMS, Apache Lucene 검색 엔진 및 Blob 저장소에서 발생한다는 점을 알아야 합니다. 그렇기 때문에 이러한 소프트웨어 제품을 고부하 조건에서 작동하려면 고속의 안정적인 장비를 사용해야 합니다.

정상적인 조건에서 Zimbra는 하드 드라이브의 RAID와 NFS 프로토콜을 통해 연결된 스토리지 모두에 설치할 수 있습니다. 소규모 설치의 경우 일반 SATA 드라이브에 Zimbra를 설치할 수 있습니다. 그러나 대규모 설치 환경에서 이러한 모든 기술은 녹화 속도 감소 또는 낮은 신뢰성이라는 형태의 다양한 단점을 보여주며 이는 대기업이나 특히 SaaS 제공업체 모두에게 용납될 수 없습니다.

이것이 대규모 Zimbra 인프라에서는 SAN을 사용하는 것이 가장 좋은 이유입니다. 현재 저장 장치에 대해 최대의 처리량을 제공할 수 있는 것이 바로 이 기술이며 동시에 많은 양의 캐시를 연결할 수 있는 기능 덕분에 이 기술을 사용해도 실제로 기업에 심각한 위험을 초래하지 않습니다. 쓰기 작업 속도를 높이기 위해 많은 SAN에서 사용되는 NVRAM을 사용하는 것이 좋습니다. 그러나 디스크 자체에 기록된 데이터 캐싱을 비활성화하는 것이 더 좋습니다. 전원 문제가 발생할 경우 미디어에 복구할 수 없는 손상이 발생하고 데이터가 손실될 수 있기 때문입니다.

파일 시스템을 선택할 때 가장 좋은 선택은 표준 Linux Ext3/Ext4를 사용하는 것입니다. 파일 시스템과 관련된 주요 차이점은 매개변수를 사용하여 마운트해야 한다는 것입니다. -noatime. 이 옵션은 파일에 대한 마지막 액세스 시간을 기록하는 기능을 비활성화하므로 읽기 및 쓰기 작업 부하가 크게 줄어듭니다. 일반적으로 Zimbra용 ext3 또는 ext4 파일 시스템을 생성할 때 다음 유틸리티 매개변수를 사용해야 합니다. mke2fs:

-j — 파일 시스템 저널을 생성하려면 ext3/ext4 저널을 사용하여 파일 시스템을 생성합니다.
-L 이름 - /etc/fstab에서 사용할 볼륨 이름을 생성하려면
-O dir_index - 해시된 검색 트리를 사용하여 대규모 디렉터리에서 파일 검색 속도를 높이려면
-m 2 — 대규모 파일 시스템 볼륨의 2%를 루트 디렉토리용으로 예약합니다.
-J 사이즈=400 — 큰 매거진을 만들려면
-b 4096 — 블록 크기를 바이트 단위로 결정하려면
-나는 10240 - 메시지 저장의 경우 이 설정은 평균 메시지 크기와 일치해야 합니다. 이 매개변수는 나중에 값을 변경할 수 없으므로 주의해야 합니다.

또한 활성화하는 것이 좋습니다. 디렉터리 동기화 Blob 저장소, Lucene 검색 메타데이터 저장소 및 MTA 대기열 저장소용입니다. Zimbra는 일반적으로 유틸리티를 사용하기 때문에 이 작업을 수행해야 합니다. fsync 데이터가 포함된 Blob을 디스크에 쓰기 보장합니다. 그러나 Zimbra 메일 저장소나 MTA가 메시지 전달 중에 새 파일을 생성하면 해당 폴더에서 발생하는 변경 사항을 디스크에 기록해야 합니다. 그렇기 때문에 파일이 이미 다음을 사용하여 디스크에 기록된 경우에도 마찬가지입니다. fsync, 디렉토리에 추가된 기록은 디스크에 기록될 시간이 없을 수 있으며 결과적으로 갑작스러운 서버 장애로 인해 손실될 수 있습니다. 이용덕분에 디렉터리 동기화 이러한 문제를 피할 수 있습니다.

2. Zimbra 인프라 실행 최적화

Zimbra를 몇 년 동안 사용한 후 사용자 수가 크게 증가하고 서비스의 응답 속도가 매일 점점 느려지는 경우가 종종 있습니다. 이 상황에서 벗어날 수 있는 방법은 분명합니다. 서비스가 이전처럼 빠르게 다시 작동하도록 인프라에 새 서버를 추가하기만 하면 됩니다. 한편, 성능을 높이기 위해 인프라에 새 서버를 즉시 추가하는 것이 항상 가능한 것은 아닙니다. IT 관리자는 종종 회계 또는 보안 부서와 함께 새 서버 구매를 조정하는 데 오랜 시간을 소비해야 하며, 새 서버를 늦게 배송하거나 심지어 잘못된 것을 배송할 수 있는 공급업체에 의해 실망하는 경우도 많습니다.

물론, 항상 확장을 위한 여유분을 확보하고 누구에게도 의존하지 않으려면 여유분을 가지고 Zimbra 인프라를 구축하는 것이 가장 좋습니다. 그러나 이미 실수가 발생한 경우 IT 관리자는 다음과 같이 그 결과를 완화할 수 있습니다. 가능한 한 많이. 예를 들어, IT 관리자는 작동 중에 정기적으로 하드 드라이브에 액세스하여 Zimbra의 성능에 부정적인 영향을 미칠 수 있는 Linux 시스템 서비스를 일시적으로 비활성화하여 약간의 생산성 향상을 얻을 수 있습니다. 따라서 다음을 일시적으로 비활성화할 수 있습니다.

오토프스, 넷프스 - 원격 파일 시스템 검색 서비스
컵 — 인쇄 서비스
xinetd, vsftpd - 아마도 필요하지 않은 내장 *NIX 서비스
포트맵, rpcsvcgssd, rpcgssd, rpcidmapd — 일반적으로 네트워크 파일 시스템과 함께 사용되는 원격 절차 호출 서비스
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite에 포함된 주요 유틸리티의 중복
위치/업데이트DB - Zimbra는 각 메시지를 별도의 파일에 저장하기 때문에,updateb 서비스를 매일 실행하면 문제가 발생할 수 있으므로 서버 부하가 가장 적은 시간에 수동으로 수행하는 것이 가능합니다.

이러한 서비스를 비활성화하여 시스템 리소스를 절약하는 것은 그다지 중요하지 않지만 불가항력에 가까운 상황에서는 매우 유용할 수 있습니다. 새 서버가 Zimbra 인프라에 추가되면 이전에 비활성화된 서비스를 다시 활성화하는 것이 좋습니다.

또한 작동 중에 메일 저장소의 하드 드라이브를 로드하지 않도록 syslog 서비스를 별도의 서버로 이동하여 Zimbra 작동을 최적화할 수도 있습니다. 저렴한 단일 보드 Raspberry Pi를 포함하여 거의 모든 컴퓨터가 이러한 목적에 적합합니다.

출처 : habr.com