Bizimkilerden birinde Zimbra Collabortion Suite'i bir kuruluşta uygularken altyapı planlamasına adanmış olan bu çözümün çalışmasındaki ana sınırlamanın, posta depolarındaki disk cihazlarının I/O hızı olduğu söylendi. Aslında, bir işletmenin birkaç yüz çalışanının aynı posta deposuna aynı anda eriştiği bir zamanda, sabit disklerden bilgi yazmak ve okumak için kanal genişliği, hizmetin duyarlı çalışması için yeterli olmayabilir. Zimbra'nın küçük kurulumları için bu özel bir sorun olmayacaksa, büyük işletmeler ve SaaS sağlayıcıları söz konusu olduğunda, tüm bunlar e-postaların yanıt vermemesine ve bunun sonucunda çalışanların verimliliğinde azalmaya ve ihlallere yol açabilir. SLA'lar. Bu nedenle, büyük ölçekli Zimbra kurulumlarını tasarlarken ve çalıştırırken, posta depolama alanındaki sabit sürücülerin performansını optimize etmeye özel dikkat gösterilmelidir. İki duruma bakalım ve her birinde disk depolamadaki yükü optimize etmek için hangi yöntemlerin uygulanabileceğini bulmaya çalışalım.
1. Büyük ölçekli bir Zimbra kurulumu tasarlarken optimizasyon
Yüksek yüklü bir Zimbra kurulumunun tasarım aşamasında, yöneticinin hangi depolama sistemini kullanacağı konusunda bir seçim yapması gerekecektir. Bu konuya karar vermek için, sabit disklerdeki ana yükün Zimbra Collaboration Suite'te bulunan MariaDB DBMS'den, Apache Lucene arama motorundan ve blob depolamadan geldiğini bilmelisiniz. Bu nedenle bu yazılım ürünlerinin yüksek yük koşullarında çalıştırılabilmesi için yüksek hızlı ve güvenilir ekipmanların kullanılması gerekmektedir.
Normal koşullar altında Zimbra, hem sabit sürücülerin RAID'ine hem de NFS protokolü aracılığıyla bağlanan depolamaya kurulabilir. Çok küçük kurulumlar için Zimbra'yı normal bir SATA sürücüsüne kurabilirsiniz. Bununla birlikte, büyük kurulumlar bağlamında, tüm bu teknolojiler, düşük kayıt hızı veya düşük güvenilirlik gibi çeşitli dezavantajlar sergilemektedir; bu, ne büyük işletmeler ne de özellikle SaaS sağlayıcıları için kabul edilemez.
Bu nedenle büyük ölçekli Zimbra altyapılarında SAN kullanmak en iyisidir. Şu anda depolama aygıtları için en yüksek verimi sağlayabilen bu teknolojidir ve aynı zamanda büyük miktarda önbellek bağlama yeteneği sayesinde kullanımı pratik olarak işletme için herhangi bir önemli risk oluşturmaz. Yazma sırasında işleri hızlandırmak için birçok SAN'da kullanılan NVRAM'ı kullanmak iyi bir fikirdir. Ancak, disklerde kayıtlı verilerin önbelleğe alınmasını devre dışı bırakmak daha iyidir, çünkü bu, güç sorunları meydana gelirse medyada onarılamaz hasara ve veri kaybına yol açabilir.
Dosya sistemi seçimine gelince, en iyi seçim standart Linux Ext3/Ext4'ü kullanmak olacaktır. Dosya sistemiyle ilgili ana nüans, parametreyle bağlanması gerektiğidir. -noatime. Bu seçenek, dosyalara son erişim zamanını kaydetme işlevini devre dışı bırakacaktır; bu, okuma ve yazma yükünü büyük ölçüde azaltacağı anlamına gelir. Genel olarak Zimbra için ext3 veya ext4 dosya sistemi oluştururken aşağıdaki yardımcı program parametrelerini kullanmalısınız mke2fs:
-j — Bir dosya sistemi günlüğü oluşturmak için Dosya sistemini bir ext3/ext4 günlüğüyle oluşturun.
-L ADI - Daha sonra /etc/fstab'da kullanılacak bir birim adı oluşturmak için
-O dizin_index - Büyük dizinlerdeki dosya aramalarını hızlandırmak için karma bir arama ağacı kullanmak
-m2 — Büyük dosya sistemlerinde birimin %2'sini kök dizine ayırmak için
-J boyutu=400 — Büyük bir dergi oluşturmak için
-b 4096 — Bayt cinsinden blok boyutunu belirlemek için
-ben 10240 - Mesaj depolama için bu ayar ortalama mesaj boyutuna karşılık gelmelidir. Değeri sonradan değiştirilemeyeceği için bu parametreye çok dikkat etmelisiniz.
Ayrıca etkinleştirmeniz önerilir dizin senkronizasyonu blob depolama, Lucene arama meta veri depolama ve MTA kuyruk depolama için. Bunun yapılması gerekiyor çünkü Zimbra genellikle bu yardımcı programı kullanıyor fsync veri içeren bir blobun diske garantili yazılması için. Ancak Zimbra posta deposu veya MTA mesaj teslimi sırasında yeni dosyalar oluşturduğunda, ilgili klasörlerde meydana gelen değişikliklerin diske yazılması gerekli hale gelir. Bu nedenle, dosya zaten kullanılarak diske yazılmış olsa bile fsyncdizine eklendiği kaydın diske yazılması için zaman olmayabilir ve bunun sonucunda ani bir sunucu arızası nedeniyle kaybolabilir. Kullanım sayesinde dizin senkronizasyonu bu sorunların önüne geçilebilir.
2. Zimbra altyapısı çalışırken optimizasyon
Çoğu zaman Zimbra'yı birkaç yıl kullandıktan sonra kullanıcı sayısının önemli ölçüde arttığı ve hizmetin her geçen gün daha az yanıt verdiği görülür. Bu durumdan çıkış yolu açıktır: Hizmetin eskisi kadar hızlı çalışabilmesi için altyapıya yeni sunucular eklemeniz yeterlidir. Bu arada performansını artırmak için altyapıya hemen yeni sunucular eklemek her zaman mümkün olmuyor. BT yöneticileri genellikle yeni sunucuların satın alınmasını muhasebe veya güvenlik departmanıyla koordine etmek için uzun zaman harcamak zorunda kalır; buna ek olarak, yeni bir sunucuyu geç teslim edebilen, hatta yanlış şeyi teslim edebilen tedarikçiler tarafından sıklıkla hayal kırıklığına uğratılırlar.
Tabii ki, Zimbra altyapınızı bir rezerv ile inşa etmek, genişlemesi için her zaman bir yedeğe sahip olmak ve kimseye bağlı olmamak için en iyisidir, ancak zaten bir hata yapılmışsa, BT yöneticisi bunun sonuçlarını ancak şu şekilde düzeltebilir: mümkün olduğu kadar. Örneğin, bir BT yöneticisi, çalışma sırasında sabit sürücülere düzenli olarak erişen Linux sistem hizmetlerini geçici olarak devre dışı bırakarak küçük bir üretkenlik artışı sağlayabilir ve bu nedenle Zimbra'nın performansını olumsuz yönde etkileyebilir. Böylece geçici olarak devre dışı bırakabilirsiniz:
autof'lar, netf'ler - Uzaktan Dosya Sistemi Keşif Hizmetleri
bardaklar — Yazdırma hizmeti
xinetd, vsftpd - Muhtemelen ihtiyaç duymayacağınız yerleşik *NIX hizmetleri
port haritası, rpcsvcgssd, rpcgssd, rpcidmapd — Genellikle ağ dosya sistemleriyle birlikte kullanılan uzaktan prosedür çağrısı hizmetleri
güvercinlik, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite'te yer alan ana yardımcı programların kopyaları
yerini değiştir/güncellendib - Zimbra her mesajı ayrı bir dosyada sakladığından, updateb servisinin her gün çalıştırılması sorunlara neden olabilir ve bu nedenle sunucuların en az yüklendiği dönemde bunu manuel olarak yapmak mümkündür.
Bu hizmetlerin devre dışı bırakılması sonucunda sistem kaynaklarından tasarruf edilmesi çok önemli olmayacaktır ancak mücbir sebeplere yakın durumlarda bu bile çok faydalı olabilir. Yeni sunucu Zimbra altyapısına eklendikten sonra daha önce devre dışı bırakılan hizmetlerin yeniden etkinleştirilmesi önerilir.
Ayrıca sistem günlüğü hizmetini ayrı bir sunucuya taşıyarak Zimbra'nın çalışmasını optimize edebilirsiniz, böylece çalışma sırasında posta depolarının sabit disklerini yüklemez. Hemen hemen her bilgisayar bu amaçlara uygundur, hatta ucuz tek kartlı Raspberry Pi bile.
Kaynak: habr.com