Always On (aktif-aktif küme)

Birden çok posta sunucusu aynı veriye bağlı çalışır; bir sunucu düşerse proxy istemciyi canlı sunucuya yönlendirir, hesap taşıma veya devralma gerekmez.

Global yönetici ve rootYönetici konsolu › Araçlar ve Geçiş › Profelis Always On

Kurulum: Always On kurulumu.

Küme durumu

1. Araçlar ve Geçiş › Profelis Always On'u açın. Üst bantta küme kimliği, ZooKeeper durumu, Canlı düğüm x / y, bu sunucu, yönlendirme, Eşitleme (tüm düğümler eşitse yeşil hepsi eşit, değilse kırmızı N sorun) ve Depolama türü (Ceph, Garage, S3 veya NFS) görünür. Altta düğüm listesi: Düğüm, ZooKeeper, LDAP, MaxScale, Depolama, Bu sunucu, Sunucu ID (ilk 8 karakter; tamamı imleç üzerindeyken). Sunucu kümeye katılmamışsa kırmızı bir uyarı çıkar ve liste boş kalır.
   • LDAP: Eşit (çoklu ana sunucular aynı noktada; 60 saniyeye kadar fark normal), Geride (bu sunucu diğerinin değişikliklerini almıyor) veya Kapalı.
   • MaxScale: veritabanı sunucusunun MaxScale'deki rolü: Master, Slave, Eşit (Galera eşit), Donor, Katılıyor, Bakım ya da Kapalı. Galera durumu ve küme boyutu imleç üzerindeyken görünür.
   • Depolama: düğümün S3 uç noktası (yerel RGW/Garage) yanıt veriyorsa Tamam, sorun varsa Bozuk veya Kapalı. NFS'te yalnız bu sunucunun ortak dizini denetlenir.
   • Denetimler 10 saniyede bir yenilenir; bir denetim yanıt vermezse hücrede ? görünür, düğüm listesi çalışmaya devam eder.
2. Otomatik Yenile açıkken bir sunucu durursa en geç 10 saniye içinde kapalı görünür.
3. Önbellekleri Temizle küme genelinde önbelleği temizler (aşağıya bakın).

Profelis Always On: iki düğümlü küme, 2/2 canlı düğüm

Küme geneli önbellek temizliği

Önbellekleri Temizle tüm düğümlerde önbelleği temizler (ör. COS değişikliğinden sonra). Tek sunucuda çalışan zmprov flushCache diğer düğümleri etkilemez.

Bakım için düğümü devreden çıkarmak

Root olarak (Kurulum /usr/local/sbin altına bir bağlantı koyar; tam yol /opt/profelis-alwayson/bin/profelis-alwayson-companion):

profelis-alwayson-companion drain --reason bakim
profelis-alwayson-companion status
profelis-alwayson-companion undrain

Drain süresince yeni oturumlar ve posta teslimi diğer düğümlere gider; mevcut oturumlar kesilmez. Yardımcı bileşen sağlık izler: ardışık üç hatada düğümü kendisi devreden çıkarır, düzelince geri alır.

Sıralı yeniden başlatma

mailboxd yeniden başlatması gerektiren bir ayar değiştiğinde düğümleri tek tek elle yeniden başlatmayın. Herhangi bir düğümde root olarak:

profelis-alwayson-companion rolling-restart

Düğümler sırayla devreden çıkarılır, süren istekler için 30 saniye beklenir, mailboxd yeniden başlatılır, sağlık kontrolleri geçince düğüm geri alınır ve sıradakine geçilir. Küme bu sırada hizmet vermeye devam eder. Yalnız bulunduğunuz düğüm için profelis-alwayson-companion restart-self.

• Canlı düğüm ikiden azsa komut başlamaz; aynı anda kümede tek bir yeniden başlatma çalışır.
• Bir düğüm yeniden başlatmadan sonra sağlıklı açılmazsa devreden çıkarılmış kalır ve işlem durur; diğer düğümlere dokunulmaz. Sorunu giderip profelis-alwayson-companion undrain.
• Önce planı görmek için rolling-restart --dry-run.

Profelis Always On ekranındaki bilgi satırı da bu komutu hatırlatır.

Tam HA kümesinde durum denetimi

Tanıklı kümede (kurulum) her sunucuda root olarak:

scripts/alwayson/alwayson-install --phase verify

Doğrulama Galera (2 sunucu + hakem = 3), ZooKeeper (lider/izleyici), OpenSearch (3 düğüm), LDAP çoğaltma, ileti deposu (Ceph HEALTH_OK/HEALTH_WARN veya Garage) ve S3 bucket erişimini denetler. Ceph durumu: ceph --id profelis -s; S3 erişimi: zmjava com.profelis.store.s3.S3Check (zimbra kullanıcısı, EXT_JAR_PATH=/opt/zimbra/lib/ext/com_profelis_s3store/com_profelis_s3store.jar).

Bir sunucu kapandığında hiçbir şey yapmanız gerekmez: kalan sunucu okuma ve yazmaya devam eder (Ceph HEALTH_WARN gösterir). Sunucu döndüğünde veritabanı, dizin, arama indeksi ve ileti deposu kendiliğinden eşitlenir.

Dizin (LDAP) çoğaltma denetimi

Her posta sunucusunda zimbra kullanıcısıyla:

/opt/zimbra/libexec/zmreplchk
/opt/zimbra/libexec/zmldapmmrtool -q

Beklenen: iki sunucuda contextCSN aynı ve durum "In Sync". ldap_url iki sunucuyu da listeler (yerel sunucu önde); biri düşerse mailboxd diğerine geçer. ldap_url değiştikten sonra mailboxd yeniden başlatması gerekir (bkz. sıralı yeniden başlatma).

LDAP parola döndürme

Yedi LDAP parolası (ldap_root_password, ldap_replication_password, zimbra_ldap_password, ldap_postfix_password, ldap_amavis_password, ldap_nginx_password, ldap_bes_searcher_password) kümede elle çalıştırılan aşamayla döndürülür:

alwayson-install --yes --phase ldap-passwd

Aşama çoklu ana sunucu çoğaltmasını (MMR) bilir. Tek başına zmldappasswd -l MMR yapılandırmasındaki çoğaltma tüketici kimlik bilgilerini güncellemez; aşama bunları da düzeltir (olcDatabase={3}mdb), böylece çoğaltma Invalid credentials (49) ile durmaz. Sonrasında zmreplchk ile doğrulayın.

MaxScale yönetici hesabı alwayson-install --yes --phase maxscale-admin ile sıkılaştırılır.

Always On yönetim ekranı (1.0.7) düğüm başına LDAP, MaxScale ve Depolama eşitleme sütunlarını ve bir "Eşitleme" satırını gösterir; böylece geri kalan düğüm bir bakışta görülür.

İleti deposu (S3) yük devri

Profelis S3 Zimbra PFE 10 gerektirir (Zimbra 9'da yoktur).

S3 deposu her çağrıda önce yerel uç noktayı, başarısız olursa diğer sunucunun uç noktasını dener (profelis_s3_endpoints). Bir RGW düşerse yazma ve okuma kesilmeden diğerine geçer; LMTP 250 ancak yazma onaylandıktan sonra döner, yazılamazsa MTA yeniden dener. Yeni ileti kaybı olmaz, yalnız o anda süren tek bir istek gecikebilir.

Yük devri beklentileri (tek makine kaybı):

Olay	Beklenen	Ölçülen
Posta sunucusu kapandı	Canlı düğüm listesinden düşer, giriş/teslimat diğer sunucuda sürer	İkinci sunucu: girişlerin %95'i, posta 30/30; Galera katılımı yaklaşık 5 sn, Ceph HEALTH_OK yaklaşık 4 dk
Birinci sunucu kapandı	Aynı; veritabanı yazmaları MaxScale ile diğer düğümde sürer	216/216 giriş, posta 20/20; Ceph HEALTH_OK yaklaşık 6 dk
Tanık kapandı	Etki yok; Galera/ZooKeeper çoğunluğu 2/3	Girişlerin %91-93'ü, posta 118/118; ZooKeeper lideri değişir, katılım yaklaşık 2 dk
Yalnız RGW durdu	S3 istekleri diğer uç noktaya geçer	girişlerin yaklaşık %97'si, 72/72; S3 deposu aynı PUT içinde diğer uç noktaya geçer

Hiçbir senaryoda posta kaybı olmadı. Tam tablo: Yük devri davranışı.

Bilinen boşluk

Yardımcı bileşen (companion) S3/RGW sağlığını izlemez; Ceph ile blob_mount denetimi anlamsızdır. Ceph/RGW durumunu alwayson-install --phase verify ve ceph --id profelis -s ile ayrıca izleyin.

Kapsam

Aynı posta kutusuna aynı anda iki yazıcı yoktur; yazma hakkı dağıtık kilitle sıraya konur. Paylaşılan depolama ve veritabanı kümesinin sağlığı ayrıca izlenmelidir.