W jednym z naszych , poświęconej planowaniu infrastruktury przy wdrażaniu Zimbra Collabortion Suite w przedsiębiorstwie, stwierdzono, że głównym ograniczeniem w działaniu tego rozwiązania jest szybkość wejścia/wyjścia urządzeń dyskowych w magazynach poczty. Rzeczywiście, w czasach, gdy kilkuset pracowników przedsiębiorstwa jednocześnie korzysta z tego samego magazynu poczty, szerokość kanału do zapisu i odczytu informacji z dysków twardych może nie wystarczyć do responsywnego działania usługi. A jeśli w przypadku małych instalacji Zimbry nie będzie to szczególnym problemem, to w przypadku dużych przedsiębiorstw i dostawców SaaS wszystko to może prowadzić do braku odpowiedzi na e-mail, a w rezultacie do spadku wydajności pracowników, a także do naruszenia umów SLA. Dlatego też projektując i obsługując wielkoskalowe instalacje Zimbra, należy zwrócić szczególną uwagę na optymalizację wydajności dysków twardych w przechowywaniu poczty. Przyjrzyjmy się dwóm przypadkom i spróbujmy dowiedzieć się, jakie metody optymalizacji obciążenia pamięci dyskowej można zastosować w każdym z nich.
1. Optymalizacja przy projektowaniu instalacji Zimbry na dużą skalę
Na etapie projektowania instalacji Zimbra o dużym obciążeniu administrator będzie musiał dokonać wyboru, którego systemu pamięci masowej użyć. Aby podjąć decyzję w tej kwestii, powinieneś wiedzieć, że główne obciążenie dysków twardych pochodzi z systemu DBMS MariaDB zawartego w pakiecie Zimbra Collaboration Suite, wyszukiwarki Apache Lucene i magazynu obiektów typu blob. Dlatego też, aby móc korzystać z tego oprogramowania w warunkach dużego obciążenia, konieczne jest użycie szybkiego i niezawodnego sprzętu.
W normalnych warunkach Zimbrę można zainstalować zarówno na dyskach twardych RAID, jak i na pamięci masowej podłączonej za pomocą protokołu NFS. W przypadku bardzo małych instalacji Zimbrę można zainstalować na zwykłym dysku SATA. Jednak w kontekście dużych instalacji wszystkie te technologie wykazują różne wady w postaci zmniejszonej prędkości zapisu czy niskiej niezawodności, co jest nie do przyjęcia ani dla dużych przedsiębiorstw, ani zwłaszcza dla dostawców SaaS.
Dlatego w dużych infrastrukturach Zimbra najlepiej jest używać sieci SAN. To właśnie ta technologia jest obecnie w stanie zapewnić największą przepustowość urządzeniom magazynującym, a jednocześnie dzięki możliwości podłączenia dużej ilości pamięci podręcznej jej wykorzystanie praktycznie nie stwarza znaczących zagrożeń dla przedsiębiorstwa. Dobrym pomysłem jest użycie pamięci NVRAM, która jest używana w wielu sieciach SAN w celu przyspieszenia zapisu. Lepiej jednak wyłączyć buforowanie zapisanych danych na samych dyskach, ponieważ może to prowadzić do nieodwracalnego uszkodzenia nośnika i utraty danych w przypadku problemów z zasilaniem.
Jeśli chodzi o wybór systemu plików, najlepszym wyborem byłoby użycie standardowego systemu Linux Ext3/Ext4. Głównym niuansem związanym z systemem plików jest to, że należy go zamontować za pomocą parametru -noatime. Opcja ta wyłączy funkcję rejestrowania czasu ostatniego dostępu do plików, co oznacza znaczne zmniejszenie obciążenia przy odczycie i zapisie. Ogólnie rzecz biorąc, podczas tworzenia systemu plików ext3 lub ext4 dla Zimbry należy użyć następujących parametrów narzędziowych mke2fs:
-j — Aby utworzyć dziennik systemu plików: Utwórz system plików z dziennikiem ext3/ext4.
-L NAZWA - Aby utworzyć nazwę woluminu do użycia w pliku /etc/fstab
-O indeks_katalogu - Aby użyć zaszyfrowanego drzewa wyszukiwania, aby przyspieszyć wyszukiwanie plików w dużych katalogach
-m 2 — Aby zarezerwować 2% woluminu w dużych systemach plików dla katalogu głównego
-J rozmiar = 400 — Aby stworzyć duży magazyn
-b 4096 — Aby określić rozmiar bloku w bajtach
-ja 10240 - W przypadku przechowywania wiadomości to ustawienie powinno odpowiadać średniemu rozmiarowi wiadomości. Należy zwrócić szczególną uwagę na ten parametr, gdyż jego wartości nie można później zmienić.
Zalecane jest również włączenie synchronizacja katalogowa do przechowywania obiektów blob, przechowywania metadanych wyszukiwania Lucene i przechowywania kolejek MTA. Należy to zrobić, ponieważ Zimbra zwykle korzysta z tego narzędzia fsync dla gwarantowanego zapisu obiektu BLOB z danymi na dysku. Jednakże, gdy magazyn pocztowy Zimbra lub MTA utworzy nowe pliki podczas dostarczania wiadomości, konieczne staje się zapisanie na dysku zmian zachodzących w odpowiednich folderach. Dlatego nawet jeśli plik został już zapisany na dysku za pomocą fsync, zapis o jego dodaniu do katalogu może nie zdążyć zapisać się na dysku i w efekcie może zostać utracony w wyniku nagłej awarii serwera. Dzięki zastosowaniu synchronizacja katalogowa tych problemów można uniknąć.
2. Optymalizacja przy działającej infrastrukturze Zimbra
Często zdarza się, że po kilku latach korzystania z Zimbry liczba jej użytkowników znacząco wzrasta, a usługa z dnia na dzień staje się coraz mniej responsywna. Wyjście z tej sytuacji jest oczywiste: wystarczy dodać do infrastruktury nowe serwery, aby usługa znów działała tak szybko, jak wcześniej. Tymczasem nie zawsze możliwe jest od razu dodanie nowych serwerów do infrastruktury w celu zwiększenia jej wydajności. Menedżerowie IT często muszą spędzać dużo czasu na koordynowaniu zakupu nowych serwerów z działem księgowości lub bezpieczeństwa, ponadto często zawodzą ich dostawcy, którzy mogą dostarczyć nowy serwer z opóźnieniem lub nawet dostarczyć nieodpowiedni produkt.
Oczywiście najlepiej jest budować swoją infrastrukturę Zimbra z rezerwą, aby zawsze mieć rezerwę na jej rozbudowę i nie być od nikogo zależnym, jednak jeśli już został popełniony błąd, menadżer IT może jedynie załagodzić jego skutki w miarę jak najbardziej. Na przykład menedżer IT może osiągnąć niewielki wzrost produktywności, tymczasowo wyłączając usługi systemu Linux, które podczas działania regularnie uzyskują dostęp do dysków twardych i dlatego mogą negatywnie wpłynąć na wydajność Zimbry. Możesz więc tymczasowo wyłączyć:
autofs, netfs — Usługi zdalnego wykrywania systemu plików
kubki — Usługa drukowania
xinetd, vsftpd - Wbudowane usługi *NIX, których prawdopodobnie nie będziesz potrzebować
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Usługi zdalnego wywoływania procedur, które są zwykle używane w połączeniu z sieciowymi systemami plików
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplikaty głównych narzędzi zawartych w pakiecie Zimbra Collaboration Suite
zlokalizuj/zaktualizowanob - Ponieważ Zimbra przechowuje każdą wiadomość w osobnym pliku, codzienne uruchamianie usługi updateb może powodować problemy, dlatego też można to zrobić ręcznie przy najmniejszym obciążeniu serwerów
Oszczędność zasobów systemowych w wyniku wyłączenia tych usług nie będzie bardzo znacząca, ale nawet to może być bardzo przydatne w warunkach bliskich działaniu siły wyższej. Po dodaniu nowego serwera do infrastruktury Zimbra zaleca się ponowne włączenie wcześniej wyłączonych usług.
Można także zoptymalizować działanie Zimbry przenosząc usługę syslog na osobny serwer, aby podczas pracy nie obciążała dysków twardych magazynów poczty. Do tych celów nadaje się prawie każdy komputer, nawet tanie jednopłytkowe Raspberry Pi.
Źródło: www.habr.com