Zimbra’da Kapasite Planlaması ve Boyutlandırma

Yazar:komut.io ekibi Zimbra Mail Sunucusu Kurulum ve Yönetimi
0 Yorum

Zimbra kurulumunu bitirdiniz, kullanıcılar mail atmaya başladı, her şey güzel gidiyor. Sonra bir gün sabah 7’de telefonunuz çalıyor: “Mail sunucusu çalışmıyor.” Disk dolmuş, ya da sistem o kadar yavaşlamış ki kimse mail gönderemiyor. İşte bu senaryoyu yaşamamak için kapasite planlaması var. Zimbra’da bu işi doğru yapmak, hem sistemi ayakta tutmak hem de gereksiz harcamaların önüne geçmek demek.

Neden Kapasite Planlaması Bu Kadar Kritik

Zimbra, monolitik yapısı nedeniyle birçok bileşeni aynı sunucuda ya da birbirine bağlı birkaç sunucuda çalıştırır: LDAP, MTA, mailbox, proxy, spell, archiving. Herhangi birinde kaynak tıkanıklığı yaşandığında etki domino taşları gibi diğerlerine yayılır. Özellikle Türkiye’deki kurumsal ortamlarda gördüğüm klasik hata şu: Sunucu 500 kullanıcı için kurulmuş, iki yıl sonra 1200 kullanıcı o sistemde çalışıyor. Kimse kapasiteyi güncellemeyi aklına getirmemiş.

İyi bir kapasite planı şu soruları yanıtlamalı:

  • Kaç kullanıcı aktif olacak ve bu sayı nasıl büyüyecek
  • Kullanıcı başına ortalama mailbox boyutu ne olacak
  • Günlük mail hacmi ve tepe saatler ne zaman
  • Yedekleme ve arşivleme gereksinimleri sistemi nasıl etkiliyor
  • Üç yıllık büyüme projeksiyonu nedir

Mevcut Ortamı Doğru Okumak

Eğer mevcut bir Zimbra sistemi varsa, planlamaya oradan başlamak en mantıklısı. Sıfırdan kuruyorsanız bile aşağıdaki komutları kurulumdan birkaç ay sonra düzenli çalıştırmak alışkanlık edinmeniz gereken bir şey.

Mevcut kullanıcı ve mailbox bilgilerini toplamak için:

# Toplam kullanıcı sayısı
su - zimbra -c "zmprov -l gaa | wc -l"

# Aktif kullanıcıları listele
su - zimbra -c "zmprov -l gaa -v | grep zimbraAccountStatus | grep -c active"

# Mailbox boyutlarını kullanıcı bazlı sırala
su - zimbra -c "zmmailbox -z -m [email protected] gms" 2>/dev/null || 
mysql -u root -e "SELECT account_id, size_checkpoint FROM zimbra.mailbox ORDER BY size_checkpoint DESC LIMIT 20;"

Disk kullanımını ve büyüme trendini anlamak için:

# Zimbra store dizininin boyutu
du -sh /opt/zimbra/store/
du -sh /opt/zimbra/store/0/

# Her mailbox için disk kullanımı (büyükten küçüğe)
du -sh /opt/zimbra/store/0/* | sort -rh | head -20

# Blob dizinlerinin dağılımı
find /opt/zimbra/store -maxdepth 2 -type d -exec du -sh {} ; | sort -rh | head -30

Disk büyüme trendi için basit bir script yazalım, bunu cron’a ekleyip log tutabilirsiniz:

#!/bin/bash
# /usr/local/bin/zimbra_disk_tracker.sh
LOGFILE="/var/log/zimbra_disk_usage.log"
DATE=$(date '+%Y-%m-%d %H:%M')
STORE_SIZE=$(du -sb /opt/zimbra/store/ 2>/dev/null | awk '{print $1}')
INDEX_SIZE=$(du -sb /opt/zimbra/index/ 2>/dev/null | awk '{print $1}')
DB_SIZE=$(du -sb /opt/zimbra/db/data/ 2>/dev/null | awk '{print $1}')
TOTAL_DISK=$(df -B1 /opt/zimbra | awk 'NR==2{print $2}')
USED_DISK=$(df -B1 /opt/zimbra | awk 'NR==2{print $3}')

echo "$DATE | store=$STORE_SIZE | index=$INDEX_SIZE | db=$DB_SIZE | total=$TOTAL_DISK | used=$USED_DISK" >> $LOGFILE

Bu logu 30-60 gün tuttuktan sonra aylık büyüme miktarını hesaplayabilirsiniz.

Boyutlandırma Hesapları

Disk Kapasitesi

Burada gerçekçi olmak çok önemli. Vendor’ların verdiği “kullanıcı başına 1GB yeter” gibi bilgiler genellikle ofis ortamını yansıtmıyor. Türkiye’deki muhasebe, hukuk ve mühendislik firmalarında kullanıcı başına 5-15GB mailbox görmek sıradan bir durum.

Disk hesabı yaparken şu bileşenleri ayrı ayrı hesaplayın:

  • Mail store: Kullanıcı sayısı x kullanıcı başına ortalama mailbox boyutu x 1.3 (sıkıştırma ve overhead)
  • Index dizini: Store boyutunun genellikle yüzde 10-15’i
  • MySQL veritabanı: Aktif kullanıcı başına yaklaşık 50-100MB
  • MTA kuyruğu: Yoğun saatler için en az 10-20GB ayrı bir alan
  • Log dizinleri: /opt/zimbra/log için aylık 2-5GB
  • Yedekleme alanı: Eğer aynı sunucuda tutuyorsanız store boyutunun en az 2 katı
  • Büyüme tamponu: Hesaplanan toplam değerin yüzde 30-40 fazlası

Örnek hesap: 500 kullanıcı, kullanıcı başına 10GB mailbox, 3 yıllık büyüme projeksiyonu:

# Basit hesaplama scripti
python3 << 'EOF'
kullanici = 500
kullanici_basi_gb = 10
buyume_yuzde_yillik = 20  # her yil %20 kullanici artisi
plan_yili = 3
overhead_carpan = 1.35
index_oran = 0.12
yedek_carpan = 2.0

yil3_kullanici = kullanici * ((1 + buyume_yuzde_yillik/100) ** plan_yili)
store_gb = yil3_kullanici * kullanici_basi_gb * overhead_carpan
index_gb = store_gb * index_oran
mysql_gb = yil3_kullanici * 0.1  # 100MB per user
mta_gb = 20
log_gb = 60  # 3 yil

toplam_raw = store_gb + index_gb + mysql_gb + mta_gb + log_gb
toplam_yedekli = (store_gb * yedek_carpan) + index_gb + mysql_gb + mta_gb + log_gb

print(f"3 yil sonra tahmini kullanici: {yil3_kullanici:.0f}")
print(f"Store alani: {store_gb:.0f} GB")
print(f"Index alani: {index_gb:.0f} GB")
print(f"MySQL: {mysql_gb:.0f} GB")
print(f"Toplam (yedeksiz): {toplam_raw:.0f} GB")
print(f"Toplam (yedekli): {toplam_yedekli:.0f} GB")
EOF

CPU ve RAM Boyutlandırması

Zimbra’nın en çok kaynak tüketen bileşeni mailbox servisi ve Jetty’dir. Bunu yanlış boyutlandırırsanız sistemin genel performansı yerle bir olur.

RAM için pratik hesap:

  • JVM heap (mailbox): Aktif kullanıcı başına 3-5MB, minimum 4GB, maksimum 16GB
  • JVM heap (proxy/MTA): 512MB-2GB
  • MySQL innodb_buffer_pool: Veritabanı boyutunun yüzde 70-80’i, minimum 2GB
  • İşletim sistemi ve cache: 4-8GB sabit
  • Yedek (ani yük artışları için): Toplam hesabın yüzde 20-25’i
# Mevcut JVM ayarlarini kontrol et
su - zimbra -c "zmlocalconfig mailboxd_java_heap_size"
su - zimbra -c "zmlocalconfig mailboxd_java_heap_memory_percent"

# Mevcut bellek kullanimi
su - zimbra -c "zmcontrol status"
ps aux | grep java | grep -v grep | awk '{print $6/1024 " MBt" $11}'

# MySQL buffer pool durumu
mysql -u root -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
mysql -u root -e "SHOW STATUS LIKE 'Innodb_buffer_pool_%';"

Heap boyutunu güncellemek için:

# Yeni heap boyutunu ayarla (GB cinsinden, MB giriyoruz)
su - zimbra -c "zmlocalconfig -e mailboxd_java_heap_size=8192"

# Degisikligi uygula
su - zimbra -c "zmcontrol restart"

# Dogrula
su - zimbra -c "zmlocalconfig mailboxd_java_heap_size"

CPU konusunda şunu söyleyeyim: Zimbra CPU’ya RAM kadar aç değil ama tam metin arama, arşivleme ve toplu mail işlemleri anlık CPU spike’larına yol açabiliyor. Kullanıcı başına 0.1-0.15 CPU core hesabı yapın, sonra en az 4 core ekleyin overhead için. 500 kullanıcılı bir sistem için 8-12 core makul bir başlangıç.

MySQL Optimizasyonu ve Kapasite

Zimbra’nın MySQL konfigürasyonu varsayılan kurulumda genellikle yetersiz gelir. Özellikle büyük ortamlarda bu ayarları mutlaka gözden geçirin:

# Zimbra MySQL konfig dosyasi
cat /opt/zimbra/conf/my.cnf

# Onemli parametreleri kontrol et
mysql -u root -e "SHOW VARIABLES LIKE 'max_connections';"
mysql -u root -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
mysql -u root -e "SHOW VARIABLES LIKE 'innodb_log_file_size';"
mysql -u root -e "SHOW VARIABLES LIKE 'query_cache_size';"

my.cnf üzerinde yapmanız gereken temel ayarlamalar:

# /opt/zimbra/conf/my.cnf dosyasina eklenecekler
# Zimbra'yi durdurup duzenlemeniz gerekiyor

su - zimbra -c "zmcontrol stop"

cat >> /opt/zimbra/conf/my.cnf << 'EOF'

[mysqld]
# 16GB RAM li sunucu icin ornek degerler
innodb_buffer_pool_size = 8G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
max_connections = 500
thread_cache_size = 50
table_open_cache = 4000
tmp_table_size = 256M
max_heap_table_size = 256M
query_cache_size = 0
query_cache_type = 0
EOF

su - zimbra -c "zmcontrol start"

MTA Kuyruğu ve Mail Akışı Boyutlandırması

Postfix tabanlı MTA bileşeni için kuyruk yönetimi ayrı bir dikkat gerektiriyor. Özellikle yoğun sabah saatlerinde (08:00-09:30 arasında Türkiye’de klasik bir spike görürsünüz) kuyruk boyutunun patlamasını önlemek için:

# Mevcut kuyruk durumu
su - zimbra -c "mailq | tail -1"

# Kuyruk boyutu detayli
su - zimbra -c "postqueue -p | grep -c '^[A-F0-9]'"

# Saatlik mail trafigi analizi (son 24 saat)
su - zimbra -c "grep 'status=sent' /opt/zimbra/log/maillog | 
  awk '{print $3}' | cut -d: -f1 | sort | uniq -c | sort -k2n"

# MTA queue directory boyutu
du -sh /opt/zimbra/data/postfix/spool/

MTA konfigürasyonunda throughput artırmak için:

# Postfix worker sayisini artir
su - zimbra -c "zmlocalconfig -e postfix_smtp_destination_concurrency_limit=40"
su - zimbra -c "zmlocalconfig -e postfix_default_destination_concurrency_limit=20"
su - zimbra -c "postfix reload"

# Mevcut degerleri goster
su - zimbra -c "zmlocalconfig | grep postfix_smtp"

Kullanıcı Kotaları ile Büyümeyi Kontrol Altına Almak

Kapasite planlamasının sadece donanım boyutu olmadığını anlamak lazım. Kullanıcı davranışını da yönetmek gerekiyor.

# Tum kullanicilara 10GB kota tanimla (domain bazli)
su - zimbra -c "zmprov modifyDomain domain.com zimbraMailQuota 10737418240"

# Belirli bir kullanicinin kotasini guncelle
su - zimbra -c "zmprov modifyAccount [email protected] zimbraMailQuota 5368709120"

# Kota kullanim raporunu al
su - zimbra -c "zmprov -l gaa | while read user; do 
  quota=$(zmprov ga $user zimbraMailQuota | grep zimbraMailQuota: | awk '{print $2}'); 
  used=$(zmmailbox -z -m $user gms 2>/dev/null | grep -i size | awk '{print $2}'); 
  echo "$user | quota:$quota | used:$used"; 
done" 2>/dev/null | head -50

Kota aşımı uyarı eşiklerini ayarlamak:

# Kotanin %80'ine ulasinca uyari gonder
su - zimbra -c "zmprov modifyDomain domain.com zimbraMailQuotaWarnPercent 80"
su - zimbra -c "zmprov modifyDomain domain.com zimbraMailQuotaWarnInterval 1d"
su - zimbra -c "zmprov modifyDomain domain.com zimbraQuotaWarnMessage 'Posta kutunuz dolmak uzere'"

Monitoring ve Erken Uyarı Sistemi

Kapasite planlaması tek seferlik bir iş değil. Sürekli izleme olmadan planınız kağıt üzerinde kalır. En basit haliyle bile şunu yapın:

#!/bin/bash
# /usr/local/bin/zimbra_capacity_alert.sh
# Cron: */30 * * * * /usr/local/bin/zimbra_capacity_alert.sh

ALERT_EMAIL="[email protected]"
DISK_THRESHOLD=85
QUEUE_THRESHOLD=500

# Disk kullanimi kontrolu
DISK_USAGE=$(df /opt/zimbra | awk 'NR==2{gsub(/%/,""); print $5}')
if [ "$DISK_USAGE" -gt "$DISK_THRESHOLD" ]; then
    echo "UYARI: Zimbra disk kullanimi %${DISK_USAGE} seviyesine ulasti!" | 
    mail -s "[ZIMBRA ALERT] Disk Dolu Uyarisi" $ALERT_EMAIL
fi

# MTA kuyrugu kontrolu
QUEUE_COUNT=$(su - zimbra -c "postqueue -p 2>/dev/null | grep -c '^[A-F0-9]'" 2>/dev/null || echo 0)
if [ "$QUEUE_COUNT" -gt "$QUEUE_THRESHOLD" ]; then
    echo "UYARI: MTA kuyruğunda ${QUEUE_COUNT} mail birikti!" | 
    mail -s "[ZIMBRA ALERT] MTA Kuyruk Uyarisi" $ALERT_EMAIL
fi

# Servis durumu kontrolu
STOPPED=$(su - zimbra -c "zmcontrol status" 2>/dev/null | grep -i "stopped" | wc -l)
if [ "$STOPPED" -gt 0 ]; then
    su - zimbra -c "zmcontrol status" | grep -i stopped | 
    mail -s "[ZIMBRA ALERT] Servis Durdu" $ALERT_EMAIL
fi

Çok Sunuculu Mimari Ne Zaman Gerekir

Tek sunucu üzerinde ne kadar optimize ederseniz edin, belirli bir noktadan sonra bileşenleri ayırmanız gerekir. Kaba bir kural:

  • 1000 kullanıcıya kadar: Tek sunucu yönetilebilir (doğru boyutlandırılmışsa)
  • 1000-3000 kullanıcı: Ayrı MTA + ayrı mailbox sunucusu düşünün
  • 3000+ kullanıcı: LDAP replication, birden fazla mailbox sunucusu, ayrı proxy katmanı

Eğer büyüme hızlı bekleniyor ya da yüksek erişilebilirlik gerekiyorsa bu eşikleri daha düşük tutun. Multi-server kurulumda mailbox sunucusu sayısını artırmak, Zimbra’nın account’ları farklı mailbox sunucularına dağıtmasına olanak verir, bu hem disk hem CPU yükünü horizontal ölçekler.

Yedekleme Kapasitesinin Planlamaya Dahil Edilmesi

Yedekleme hem disk hem zaman kaynağı tüketiyor. Zimbra’nın built-in backup’ı incremental çalışıyor ama uzun süre biriktiğinde boyut patluyor:

# Mevcut backup boyutunu kontrol et
du -sh /opt/zimbra/backup/

# En buyuk backup dosyalarini bul
find /opt/zimbra/backup -name "*.gz" -exec du -sh {} ; | sort -rh | head -10

# Backup retain suresini ayarla (30 gun)
su - zimbra -c "zmlocalconfig -e zimbra_backup_retention_days=30"

# Full backup kac gunun verisi kapliyor
ls -la /opt/zimbra/backup/sessions/ | head -20

Yedekleme penceresinin kapasite planlamasına etkisi: Eğer full backup 6 saat sürüyorsa ve bu sürede IO performansı düşüyorsa, ya daha hızlı disk almanız ya da yedekleme zamanlamasını yoğun olmayan saatlere (gece 02:00-06:00) çekmeniz gerekiyor. SAN ya da NFS mount üzerine backup gönderiyorsanız bu trafiği de ağ bant genişliği hesabınıza katın.

Sonuç

Zimbra’da kapasite planlaması, kurulum gününde bitip biten bir iş değil. Bunu bir süreç olarak düşünmek lazım: başlangıçta doğru ölçeklemek, büyüme trendini düzenli izlemek, belirti vermeden önce müdahale etmek.

En çok karşılaştığım sorunların büyük çoğunluğu, “ilk kurulumda yeterli görünüyordu, büyüme hesaba katılmadı” kategorisinde. Disk dolunca sistem yavaşlamaz, Zimbra’nın bir kısmı ya çöker ya da mail kabul etmeyi reddeder. Bu noktada panik modunda işlem yapmak hem riskli hem stresli.

Bu yazıda paylaştığım scriptleri cron’a ekleyip düzenli çalıştırın, logları tutun, ayda bir bakın. Üç ay sonra büyüme trendini görmek için yeterli veri elinizde olacak. Kapasite artırımı için yönetime bütçe talep etmek zorunda kaldığınızda da somut rakamlarla gidebilirsiniz, tahminle değil. Bir sysadmin’in en güçlü argümanı veriye dayalı konuşmaktır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir