Zimbra Cluster ile Yüksek Erişilebilirlik Kurulumu

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

Bir mail sunucusu çökerse ne olur? Kullanıcılar IT’yi arar, IT müdürü sizi arar, genel müdür IT müdürünü arar ve siz o sırada sunucunun başında ter dökersiniz. Zimbra gibi kurumsal bir mail altyapısında bu senaryoyu yaşamamak için yüksek erişilebilirlik (HA) kurulumu artık lüks değil, zorunluluk. Bu yazıda, gerçek bir üretim ortamında Zimbra Cluster nasıl kurulur, hangi tuzaklara dikkat etmek gerekir, bunları konuşacağız.

Mimariye Genel Bakış

Zimbra HA kurulumunda temel olarak iki yaklaşım vardır: aktif-pasif ve aktif-aktif. Aktif-aktif teoride güzel görünür ama Zimbra’nın lisans modeli ve replikasyon mekanizması göz önüne alındığında, üretimde çoğu zaman aktif-pasif daha sağlıklı çalışır. Ben bu yazıda aktif-pasif cluster yapısını anlatacağım çünkü yıllarca bunu sahadaki gerçek ortamlarda koşturdum.

Minimum bileşenler şunlar:

  • Node 1 (Primary): Aktif Zimbra sunucusu, tüm servislerin çalıştığı ana makine
  • Node 2 (Secondary): Pasif Zimbra sunucusu, failover anında devreye giren yedek
  • Shared Storage: Her iki node’un erişebildiği ortak depolama alanı (NFS, SAN veya DRBD)
  • Virtual IP (VIP): Kullanıcıların bağlandığı, failover sırasında otomatik geçiş yapan IP adresi
  • Cluster Manager: Corosync + Pacemaker ikilisi

Donanım gereksinimleri konusunda gerçekçi olun. Test ortamında 4 GB RAM ile Zimbra ayağa kalkar ama üretimde her node için en az 16 GB RAM, 4 vCPU ve SSD tabanlı depolama şart. Shared storage için network gecikmesi kritik; aynı veri merkezinde, tercihen 10 Gbps bağlantı üzerinde çalışın.

Ortam Hazırlığı

Her iki sunucuda da başlamadan önce temel OS ayarlarını yapmanız gerekiyor. Ben genellikle Ubuntu 20.04 LTS veya CentOS 7/8 üzerinde çalışıyorum. Bu örnekte CentOS 7 kullanalım.

Hostname ve /etc/hosts Ayarları

# Node 1'de
hostnamectl set-hostname zimbra-node1.sirket.com.tr

# Node 2'de
hostnamectl set-hostname zimbra-node2.sirket.com.tr

# Her iki node'da /etc/hosts dosyasına ekleyin
cat >> /etc/hosts << 'EOF'
192.168.10.10   zimbra-node1.sirket.com.tr zimbra-node1
192.168.10.11   zimbra-node2.sirket.com.tr zimbra-node2
192.168.10.20   zimbra-vip.sirket.com.tr zimbra-vip
EOF

Virtual IP adresini DNS’e de kaydetmeniz gerekiyor. MX kaydınız, A kaydınız ve SPF kaydınız VIP’i göstermeli. Bunu atlayanların failover sonrası mail akışının durduğunu gördüm.

Firewall Kuralları

# Her iki node'da Zimbra ve cluster portlarını açın
firewall-cmd --permanent --add-port=25/tcp      # SMTP
firewall-cmd --permanent --add-port=465/tcp     # SMTPS
firewall-cmd --permanent --add-port=587/tcp     # Submission
firewall-cmd --permanent --add-port=110/tcp     # POP3
firewall-cmd --permanent --add-port=995/tcp     # POP3S
firewall-cmd --permanent --add-port=143/tcp     # IMAP
firewall-cmd --permanent --add-port=993/tcp     # IMAPS
firewall-cmd --permanent --add-port=80/tcp      # HTTP
firewall-cmd --permanent --add-port=443/tcp     # HTTPS
firewall-cmd --permanent --add-port=7071/tcp    # Admin Console
firewall-cmd --permanent --add-port=2224/tcp    # Pacemaker
firewall-cmd --permanent --add-port=5405/udp    # Corosync
firewall-cmd --reload

DRBD ile Shared Storage Kurulumu

NFS veya SAN erişiminiz yoksa DRBD mükemmel bir alternatif. Ağ üzerinden blok cihaz replikasyonu yapıyor, Zimbra’nın mail store dizinini iki node arasında senkronize tutuyorsunuz.

# Her iki node'da DRBD kurulumu (CentOS 7)
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum install -y drbd90-utils kmod-drbd90

# DRBD kaynak konfigürasyonu - her iki node'da /etc/drbd.d/zimbra.res
cat > /etc/drbd.d/zimbra.res << 'EOF'
resource zimbra-store {
    protocol C;
    
    disk {
        on-io-error detach;
        disk-barrier no;
        disk-flushes no;
    }
    
    net {
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
        rr-conflict disconnect;
    }
    
    on zimbra-node1.sirket.com.tr {
        device    /dev/drbd0;
        disk      /dev/sdb;
        address   192.168.10.10:7789;
        meta-disk internal;
    }
    
    on zimbra-node2.sirket.com.tr {
        device    /dev/drbd0;
        disk      /dev/sdb;
        address   192.168.10.11:7789;
        meta-disk internal;
    }
}
EOF

DRBD’yi ilk kez başlatırken dikkatli olun. İlk senkronizasyon disk boyutuna göre saatler sürebilir ve bu süreçte IO performansı ciddi ölçüde düşer.

# Her iki node'da DRBD başlat
drbdadm create-md zimbra-store
systemctl enable drbd
systemctl start drbd

# Sadece Node 1'de primary olarak tanımla ve formatla
drbdadm primary --force zimbra-store
mkfs.ext4 /dev/drbd0
mkdir -p /opt/zimbra
mount /dev/drbd0 /opt/zimbra

# Senkronizasyon durumunu izle
watch -n2 cat /proc/drbd

/proc/drbd çıktısında ds:UpToDate/UpToDate görene kadar beklemeniz gerekiyor. Bunu atlamak split-brain senaryolarına davetiye çıkarmak demek.

Corosync ve Pacemaker Kurulumu

Cluster manager olarak Corosync + Pacemaker kombinasyonunu tercih ediyorum. Hem olgun bir proje, hem de Zimbra ile birlikte kullanımı için toplulukta iyi belgelenmiş kaynaklar mevcut.

# Her iki node'da kur
yum install -y corosync pacemaker pcs fence-agents-all

# pcs kullanıcı şifresi belirle (her iki node'da aynı şifre)
passwd hacluster

# Her iki node'da pcsd servisini başlat
systemctl enable pcsd
systemctl start pcsd

Corosync Konfigürasyonu

# Sadece Node 1'de cluster'ı authenticate et ve oluştur
pcs cluster auth zimbra-node1.sirket.com.tr zimbra-node2.sirket.com.tr 
    -u hacluster -p 'GuvenliSifre123!'

pcs cluster setup --name zimbra-cluster 
    zimbra-node1.sirket.com.tr 
    zimbra-node2.sirket.com.tr 
    --transport udpu

pcs cluster start --all
pcs cluster enable --all

# Cluster durumunu kontrol et
pcs status
crm_verify -L -V

Eğer crm_verify herhangi bir hata döndürürse, STONITH (fencing) ile ilgili uyarı göreceksiniz. Üretim ortamında STONITH’i mutlaka yapılandırın. Test ortamında geçici olarak devre dışı bırakabilirsiniz:

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

Zimbra Kurulumu

Shared storage mount noktasına dikkat ederek Zimbra kurulumunu sadece Node 1’de yapın. Node 2’de Zimbra kurulumu yapılmaz; çünkü shared storage üzerindeki kurulum her iki node tarafından kullanılacak.

# Node 1'de Zimbra kurulum paketini indir
cd /tmp
wget https://files.zimbra.com/downloads/8.8.15_GA/zcs-8.8.15_GA_4179.RHEL7_64.20211014040539.tgz
tar xzvf zcs-8.8.15_GA_4179.RHEL7_64.20211014040539.tgz
cd zcs-8.8.15_GA_4179.RHEL7_64.20211014040539

# Kurulumu başlat (/opt/zimbra'nın mount edilmiş olduğundan emin ol)
df -h /opt/zimbra  # DRBD mount'ını doğrula
./install.sh

Kurulum sırasında önemli bir nokta: hostname sorulduğunda VIP hostname’ini değil, node1’in hostname’ini girin. VIP yapılandırması Pacemaker tarafından yönetilecek.

Zimbra kurulumu tamamlandıktan sonra servisleri durdurun:

su - zimbra -c "zmcontrol stop"
systemctl stop zimbra 2>/dev/null || true
umount /opt/zimbra

Pacemaker Kaynaklarının Tanımlanması

Bu kısım cluster’ın beyni. Üç temel kaynak tanımlamamız gerekiyor: DRBD, filesystem mount ve VIP. Sıralama (ordering) ve colocation kısıtlamalarını doğru yapılandırmazsanız failover sırasında tutarsız durumlar oluşabilir.

# DRBD kaynağı
pcs resource create zimbra-drbd ocf:linbit:drbd 
    drbd_resource=zimbra-store 
    op monitor interval=30s

pcs resource master zimbra-drbd-clone zimbra-drbd 
    master-max=1 master-node-max=1 
    clone-max=2 clone-node-max=1 
    notify=true

# Filesystem kaynağı
pcs resource create zimbra-fs Filesystem 
    device=/dev/drbd0 
    directory=/opt/zimbra 
    fstype=ext4 
    op monitor interval=20s

# Virtual IP kaynağı
pcs resource create zimbra-vip IPaddr2 
    ip=192.168.10.20 
    cidr_netmask=24 
    nic=eth0 
    op monitor interval=10s

# Zimbra servisi kaynağı
pcs resource create zimbra-service lsb:zimbra 
    op monitor interval=30s timeout=60s 
    op start timeout=120s 
    op stop timeout=120s

# Sıralama kısıtlamaları
pcs constraint order promote zimbra-drbd-clone 
    then start zimbra-fs

pcs constraint order zimbra-fs 
    then zimbra-vip

pcs constraint order zimbra-vip 
    then zimbra-service

# Colocation kısıtlamaları
pcs constraint colocation add zimbra-fs 
    with master zimbra-drbd-clone INFINITY

pcs constraint colocation add zimbra-vip 
    with zimbra-fs INFINITY

pcs constraint colocation add zimbra-service 
    with zimbra-vip INFINITY

Zimbra LSB Servis Scripti

Pacemaker’ın Zimbra’yı yönetebilmesi için /etc/init.d/zimbra dosyasının doğru yapılandırılmış olması gerekiyor. Aşağıdaki scripti her iki node’a da kopyalayın:

cat > /etc/init.d/zimbra << 'SCRIPT'
#!/bin/bash
### BEGIN INIT INFO
# Provides:          zimbra
# Required-Start:    $network $syslog
# Required-Stop:     $network $syslog
# Default-Start:     
# Default-Stop:      
# Short-Description: Zimbra Mail Server
### END INIT INFO

ZIMBRA_USER=zimbra
ZIMBRA_HOME=/opt/zimbra

case "$1" in
    start)
        echo "Zimbra baslatiliyor..."
        su - $ZIMBRA_USER -c "zmcontrol start"
        ;;
    stop)
        echo "Zimbra durduruluyor..."
        su - $ZIMBRA_USER -c "zmcontrol stop"
        ;;
    status)
        su - $ZIMBRA_USER -c "zmcontrol status"
        ;;
    restart)
        $0 stop
        sleep 5
        $0 start
        ;;
    *)
        echo "Kullanim: $0 {start|stop|status|restart}"
        exit 1
        ;;
esac
exit 0
SCRIPT

chmod +x /etc/init.d/zimbra

Failover Testi

Kurulum tamamlandıktan sonra mutlaka kapsamlı bir failover testi yapın. Bunu üretim öncesinde uygulamak sonradan büyük acıları önler.

# Mevcut cluster durumunu kontrol et
pcs status

# Node1'i simüle ederek cluster'dan çıkar
pcs node standby zimbra-node1.sirket.com.tr

# Failover sürecini izle (ayrı bir terminal'de)
watch -n2 pcs status

# VIP'in Node2'ye geçtiğini doğrula
ip addr show | grep 192.168.10.20  # Bu komutu Node2'de çalıştır

# Zimbra'nın Node2'de çalıştığını doğrula
su - zimbra -c "zmcontrol status"  # Node2'de

# Node1'i geri getir
pcs node unstandby zimbra-node1.sirket.com.tr

Failover süresi kritik bir metrik. İyi yapılandırılmış bir cluster’da 60-90 saniye arası gerçekçi bir hedef. Bunun üzerindeyseniz monitor interval değerlerini ve Zimbra start timeout değerlerini gözden geçirin.

İzleme ve Günlük Yönetimi

Cluster’ı kurup bırakmak olmaz. Aktif izleme şart.

# Cluster olay loglarını takip et
journalctl -u corosync -f
journalctl -u pacemaker -f

# DRBD senkronizasyon durumu
drbdadm status

# Zimbra kuyruk durumu
su - zimbra -c "zmqueue"

# Mail akışı istatistikleri
su - zimbra -c "zmmailstats"

# Corosync ring durumu
corosync-cfgtool -s

Prometheus + Grafana kullanıyorsanız, node_exporter ile temel sistem metriklerini toplayabilirsiniz. Zimbra için ise zimbra_exporter adında topluluk tarafından geliştirilen bir exporter mevcut, ancak üretimde kullanmadan önce iyi test edin.

Split-Brain Senaryosu ve Kurtarma

Cluster yönetiminin en korkulan senaryosu split-brain: her iki node da kendini primary zanneder ve DRBD üzerinde farklı yazma işlemleri yapar. STONITH tam olarak bunu önlemek için var.

Eğer split-brain yaşandıysa ve DRBD StandAlone/StandAlone durumundaysa:

# Hangi node'un güncel veri olduğuna karar verin
# Genellikle en son aktif olan primary'dir

# Secondary node'da (veri kaybını kabul ediyorsunuz)
drbdadm secondary zimbra-store
drbdadm connect --discard-my-data zimbra-store

# Primary node'da
drbdadm connect zimbra-store

# Senkronizasyonu izle
watch -n2 cat /proc/drbd

Split-brain kurtarmasında yanlış node seçmek veri kaybı demek. Bu yüzden karar vermeden önce her iki node’daki /opt/zimbra/store altındaki dosyaların timestamp’lerini karşılaştırın.

Sık Karşılaşılan Sorunlar

Sahadan gelen notlar:

  • DRBD senkronizasyonu takılması: drbdadm disconnect && drbdadm connect genellikle çözer. Çözmezse network switch’i kontrol edin; yüksek gecikmeli ağlarda DRBD protokol C zaman aşımına uğrayabiliyor.
  • Pacemaker kaynağının failed durumda kalması: pcs resource cleanup zimbra-service komutu çoğu zaman işe yarıyor. Cleanup sonrası log’lara bakarak root cause’u mutlaka bulun.
  • VIP failover sonrası ARP tablosu sorunu: Bazı switch konfigürasyonlarında VIP geçişi sonrası eski ARP kaydı kullanılabiliyor. arping ile gratuitous ARP gönderilmesini Pacemaker kaynak parametrelerinde etkinleştirin.
  • Zimbra start timeout: Büyük mail store’larında Zimbra başlangıcı uzun sürebilir. op start timeout=120s değerini ortamınıza göre artırmaktan çekinmeyin, 180 saniye hatta 240 saniye gerekebilir.
  • SELinux ve Pacemaker çatışması: CentOS/RHEL’de SELinux enforcing modunda çeşitli izin hataları çıkabiliyor. audit2allow ile gerekli policy’leri oluşturun; tamamen devre dışı bırakmak kolay yol ama güvenlik açısından tavsiye edilmez.

Yedekleme Stratejisi

Cluster kurulumu yapılmış olması yedekleme ihtiyacını ortadan kaldırmaz. DRBD replikasyon, veri koruması değil, erişilebilirlik sağlar. Bir kullanıcı mailini silerse, bu silme işlemi anında secondary’e de yansır.

# Zimbra yedekleme - cron job olarak yapılandırın
cat > /etc/cron.d/zimbra-backup << 'EOF'
0 2 * * * zimbra /opt/zimbra/bin/zmbackup -f -a all 2>&1 | logger -t zimbra-backup
EOF

# Yedek durumunu kontrol et
su - zimbra -c "zmbackupquery -lb"

Yedekleri mutlaka cluster dışında bir lokasyonda saklayın. Aynı fiziksel rack’taki bir NAS yeterli değil; yangın, su baskını, elektrik arızası gibi senaryolarda tüm altyapıyı kaybedebilirsiniz.

Sonuç

Zimbra Cluster kurulumu, tek tek adımları uygulamak kadar bu adımların birbirleriyle nasıl etkileştiğini anlamayı gerektiriyor. DRBD, Corosync, Pacemaker ve Zimbra’nın her biri kendi başına karmaşık sistemler; bunları birlikte doğru çalıştırmak hem sabır hem de deneyim istiyor.

Kurulum sonrası yapmanız gerekenler listesi kısaca:

  • Failover testini belgelenmiş bir prosedürle düzenli aralıklarla tekrarlayın (en az 3 ayda bir)
  • VIP geçiş sürelerini ölçüp bir baseline oluşturun; bu sürenin uzaması altyapıda bir şeylerin kötüye gittiğinin habercisi
  • Cluster log’larını merkezi log sistemine (ELK, Graylog vb.) gönderin
  • Disaster recovery planınızda cluster’ın tamamen çöktüğü senaryoyu da ele alın; tek node’dan nasıl restore yapacağınızı bilmek zorundasınız

Yüksek erişilebilirlik bir hedef değil, sürekli korunması gereken bir durum. Kurulumu bitirince değil, düzenli testler ve izleme ile bu durumu yaşatmaya devam edince gerçek anlamda HA sahibi olmuş olursunuz.

Bir yanıt yazın

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