W jednej z naszych , poświęconej planowaniu infrastruktury przy wdrażaniu Zimbra Collaboration Suite, powiedziano, że głównym ograniczeniem przy pracy tego rozwiązania jest szybkość wejścia-wyjścia urządzeń dyskowych w magazynach pocztowych. I rzeczywiście, w czasie, gdy kilka setek pracowników jednocześnie korzysta z tego samego magazynu pocztowego, przepustowość kanału do zapisu i odczytu danych z dysków twardych może być niewystarczająca dla responsywnej pracy usługi. A jeśli dla mniejszych instalacji Zimbra nie stanowi to szczególnego problemu, to w przypadku dużych przedsiębiorstw i dostawców SaaS może prowadzić do nieodpowiedniej pracy poczty elektronicznej i w konsekwencji do obniżenia wydajności pracowników, a także do naruszenia SLA. Z tego powodu projektując i eksploatując rozbudowane instalacje Zimbra, należy szczególnie zwrócić uwagę na optymalizację pracy dysków twardych w magazynie pocztowym. Przyjrzyjmy się dwóm przypadkom i spróbujmy ustalić, jakie metody optymalizacji obciążenia magazynów dyskowych można zastosować w każdym z nich.
1. Optymalizacja przy projektowaniu rozbudowanej instalacji Zimbra
Na etapie projektowania wysokowydajnej instalacji Zimbra, jej administrator musi podjąć decyzję, jaki system przechowywania danych wykorzystać. Aby podjąć tę decyzję, należy wiedzieć, że główne obciążenie dla dysków twardych generują bazy danych MariaDB, wyszukiwarka Apache Lucene oraz magazyn obiektów BLOB, które wchodzą w skład Zimbra Collaboration Suite. Dlatego, aby te programy mogły pracować w warunkach wysokiego obciążenia, konieczne jest użycie szybkiego i niezawodnego sprzętu.
W normalnych warunkach Zimbra można zainstalować zarówno na macierzy RAID z dysków twardych, jak i na magazynach podłączonych protokołem NFS. W przypadku bardzo małych instalacji można zainstalować Zimbra na zwykłym dysku SATA. Jednak w przypadku dużych instalacji wszystkie te technologie wykazują różne wady, takie jak zmniejszona prędkość zapisu lub niska niezawodność, co jest niedopuszczalne ani dla dużych przedsiębiorstw, ani tym bardziej dla dostawców SaaS.
Dlatego w przypadku rozbudowanych infrastruktur Zimbra najlepszym rozwiązaniem będzie zastosowanie SAN. Obecnie jest to technologia, która może zapewnić najwyższą przepustowość dla urządzeń pamięci masowej, a dzięki możliwości podłączenia dużej ilości pamięci podręcznej, jej wykorzystanie nie wiąże się praktycznie z żadnym istotnym ryzykiem dla przedsiębiorstwa. Dobrym pomysłem będzie użycie NVRAM, która jest stosowana w wielu SAN do przyspieszenia operacji zapisu. Z kolei, lepiej wyłączyć buforowanie zapisywanych danych na samych dyskach, ponieważ może to prowadzić do nieodwracalnych uszkodzeń nośników i utraty danych w przypadku problemów z zasilaniem.
Jeśli chodzi o wybór systemu plików, optymalnym wyborem będzie zastosowanie standardowych dla Linuxa Ext3/Ext4. Głównym punktem związanym z systemem plików jest to, że należy go zamontować z parametrem -noatime. Parametr ten wyłączy funkcję zapisywania czasu ostatniego dostępu do plików, co znacznie zmniejszy obciążenie operacjami odczytu i zapisu. Ogólnie rzecz biorąc, przy tworzeniu systemu plików ext3 lub ext4 dla Zimbra należy użyć następujących parametrów narzędzia mke2fs:
-j — Aby stworzyć dziennik systemu plików Stwórz system plików z dziennikiem ext3/ext4.
-L NAZWA — Aby stworzyć nazwę woluminu, która będzie potem używana w /etc/fstab
-O dir_index — Aby użyć zhaszowanego drzewa wyszukiwania do przyspieszenia wyszukiwania plików w dużych katalogach
-m 2 — Aby zarezerwować 2% objętości w dużych systemach plików dla katalogu głównego
-J size=400 — Aby stworzyć duży dziennik
-b 4096 — Aby określić rozmiar bloku w bajtach
-i 10240 — Dla przechowywania wiadomości ten parametr powinien odpowiadać średniemu rozmiarowi wiadomości. Należy zwrócić szczególną uwagę na ten parametr, ponieważ później jego wartości nie można będzie zmienić
Ponadto zaleca się włączenie dirsync dla przechowywania obiektów BLOB, przechowywania danych metadanych wyszukiwania Lucene i przechowywania kolejki MTA. Należy to zrobić, ponieważ zazwyczaj Zimbra korzysta z narzędzia fsync dla gwarantowanego zapisania bloba z danymi na dysk. Jednak gdy magazyn pocztowy Zimbra lub MTA tworzą nowe pliki podczas dostarczania wiadomości, pojawia się potrzeba zapisu na dysk zmian, które miały miejsce w odpowiednich folderach. Dlatego nawet w przypadku, gdy plik został już zapisany na dysku przy pomocy fsync, wpis o jego dodaniu do katalogu może nie zdążyć zapisać się na dysku i w rezultacie może zostać utracony z powodu nagłego awarii serwera. Dzięki wykorzystaniu dirsync tych problemów można uniknąć.
2. Optymalizacja w działającej infrastrukturze Zimbra
Często bywa tak, że po kilku latach eksploatacji Zimbra liczba jej użytkowników znacznie wzrasta, a działanie usługi staje się z dnia na dzień coraz mniej responsywne. Wyjściem z tej sytuacji jest oczywiste: należy po prostu dodać nowe serwery do infrastruktury, aby usługa znów działała tak szybko jak wcześniej. Tymczasem nie zawsze istnieje możliwość natychmiastowego dodania nowych serwerów do infrastruktury, aby zwiększyć jej wydajność. Często menedżerowie IT muszą długo uzgadniać zakup nowych serwerów z działem księgowości lub działem bezpieczeństwa, a także często zawodzą dostawcy, którzy mogą dostarczyć nowy serwer z opóźnieniem lub w ogóle nie przynieść tego, co jest potrzebne.
Oczywiście najlepiej budować swoją infrastrukturę Zimbra z zapasem, aby zawsze mieć możliwość jej rozszerzenia i nie zależeć od nikogo, jednak jeśli błąd już został popełniony, menedżer IT może jedynie starać się maksymalnie złagodzić jego skutki. Na przykład menedżer IT może uzyskać niewielki wzrost wydajności, korzystając z tymczasowego wyłączenia systemowych usług Linux, które podczas pracy regularnie korzystają z dysków twardych i w rezultacie mogą negatywnie wpłynąć na prędkość działania Zimbry. Na przykład, na chwilę można wyłączyć:
autofs, netfs — Usługi wykrywania zdalnych systemów plików
cups — Usługa druku
xinetd, vsftpd — Wbudowane usługi *NIX, które raczej nie będą potrzebne
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Usługi zdalnego wywołania procedur, które zazwyczaj są używane w połączeniu z sieciowymi systemami plików
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplikaty głównych narzędzi wchodzących w skład Zimbra Collaboration Suite
slocate/updatedb Ponieważ Zimbra przechowuje każdą wiadomość w osobnym pliku, codzienne uruchamianie usługi updatedb może doprowadzić do problemów, dlatego można to robić ręcznie w czasie najmniejszego obciążenia serwerów.
Oszczędność zasobów systemowych z tytułu wyłączenia tych usług nie będzie zbyt znacząca, ale nawet to może być bardzo przydatne w warunkach zbliżonych do siły wyższej. Po dodaniu nowego serwera do infrastruktury Zimbry zaleca się ponowne włączenie wcześniej wyłączonych usług.
Można również zoptymalizować działanie Zimbry, przenosząc usługę syslog na oddzielny serwer, aby w trakcie pracy nie obciążała dysków twardych skrzynek pocztowych. Do tych celów nadaje się praktycznie każdy komputer, nawet tani jednopłytkowiec Raspberry Pi.
Źródło: habr.com
