Egyikünkben A Zimbra Collabortion Suite vállalati bevezetésekor az infrastruktúra tervezésének szentelve azt mondták, hogy ennek a megoldásnak a működésének fő korlátja a levéltárolókban lévő lemezeszközök I/O sebessége. Valójában olyan időszakban, amikor egy vállalat több száz alkalmazottja egyszerre éri el ugyanazt a levéltárat, előfordulhat, hogy a merevlemez-meghajtók információinak írására és olvasására szolgáló csatornaszélesség nem elegendő a szolgáltatás reszponzív működéséhez. És ha a Zimbra kis telepítéseinél ez nem jelent különösebb problémát, akkor a nagyvállalatok és a SaaS-szolgáltatók esetében mindez nem válaszoló e-mailekhez, és ennek eredményeként az alkalmazottak hatékonyságának csökkenéséhez, valamint jogsértéshez vezethet. az SLA-k közül. Éppen ezért a nagyméretű Zimbra-telepítések tervezésénél és üzemeltetésénél különös figyelmet kell fordítani a merevlemezek teljesítményének optimalizálására a levéltárolásban. Nézzünk meg két esetet, és próbáljuk meg kideríteni, hogy mindegyikben milyen módszerek alkalmazhatók a lemeztár terhelésének optimalizálására.
1. Optimalizálás nagyméretű Zimbra telepítés tervezésekor
A nagy terhelésű Zimbra telepítés tervezési szakaszában az adminisztrátornak kell választania, hogy melyik tárolórendszert használja. A kérdés eldöntéséhez tudnia kell, hogy a merevlemezek fő terhelése a Zimbra Collaboration Suite-ban található MariaDB DBMS-ből, az Apache Lucene keresőmotorból és a blob-tárolóból származik. Éppen ezért ahhoz, hogy ezeket a szoftvereket nagy terhelés mellett üzemeltethessük, nagy sebességű és megbízható berendezéseket kell használni.
Normál körülmények között a Zimbra telepíthető mind a merevlemezek RAID-re, mind az NFS protokollon keresztül csatlakoztatott tárolókra. Nagyon kis telepítések esetén telepítheti a Zimbra-t egy normál SATA-meghajtóra. Azonban a nagy telepítésekkel összefüggésben ezek a technológiák különféle hátrányokat mutatnak a csökkentett rögzítési sebesség vagy az alacsony megbízhatóság formájában, ami elfogadhatatlan sem a nagyvállalatok, sem különösen a SaaS-szolgáltatók számára.
Ez az oka annak, hogy a nagyméretű Zimbra infrastruktúrákban a legjobb SAN-t használni. Ez a technológia jelenleg a legnagyobb átviteli sebességet képes biztosítani a tárolóeszközök számára, ugyanakkor a nagy mennyiségű gyorsítótár csatlakoztathatóságának köszönhetően használata gyakorlatilag nem jelent jelentős kockázatot a vállalkozás számára. Célszerű az NVRAM használata, amelyet sok SAN-ban használnak az írás közbeni felgyorsításra. De jobb, ha letiltja a rögzített adatok gyorsítótárazását magukon a lemezeken, mivel ez az adathordozó helyrehozhatatlan károsodásához és adatvesztéshez vezethet, ha áramellátási problémák lépnek fel.
Ami a fájlrendszer kiválasztását illeti, a legjobb választás a szabványos Linux Ext3/Ext4 használata. A fájlrendszerhez kapcsolódó fő árnyalat az, hogy a paraméterrel együtt kell felcsatolni -noatime. Ez az opció letiltja a fájlokhoz való utolsó hozzáférés időpontjának rögzítésének funkcióját, ami azt jelenti, hogy nagymértékben csökkenti az olvasási és írási terhelést. Általában, amikor ext3 vagy ext4 fájlrendszert hoz létre a Zimbra számára, a következő segédprogram paramétereket kell használnia felesége2fs:
-j — Fájlrendszer napló létrehozása Hozzon létre egy fájlrendszert ext3/ext4 naplóval.
-L NÉV - Kötetnév létrehozása az /etc/fstab fájlban
-O dir_index - Kivonatos keresési fa használata a fájlkeresések felgyorsítására nagy könyvtárakban
-m 2 — Nagy fájlrendszerekben a kötet 2%-ának lefoglalása a gyökérkönyvtár számára
-J méret = 400 — Nagy folyóirat létrehozása
-b 4096 — A blokk méretének meghatározása bájtokban
-én 10240 - Üzenettárolás esetén ennek a beállításnak meg kell felelnie az átlagos üzenetméretnek. Erre a paraméterre nagyon oda kell figyelni, mert értéke később nem módosítható.
Engedélyezése is javasolt dirsync a blob tároláshoz, a Lucene keresési metaadattárhoz és az MTA várólista tároláshoz. Ezt azért kell megtenni, mert a Zimbra általában a segédprogramot használja fsync az adatokat tartalmazó blob garantált lemezre írásához. Amikor azonban a Zimbra levelezőtár vagy az MTA új fájlokat hoz létre az üzenetkézbesítés során, szükségessé válik a megfelelő mappákban bekövetkező változások lemezre írása. Éppen ezért, még akkor is, ha a fájlt már lemezre írták a használatával fsync, előfordulhat, hogy a könyvtárhoz való hozzáadásának rekordjának nincs ideje a lemezre írni, és ennek következtében hirtelen szerverhiba miatt elveszhet. A használatnak köszönhetően dirsync ezek a problémák elkerülhetők.
2. Optimalizálás a Zimbra infrastruktúrával
Gyakran előfordul, hogy a Zimbra több éves használata után jelentősen megnő a felhasználóinak száma, és napról napra kevésbé reagál a szolgáltatás. A kiút ebből a helyzetből nyilvánvaló: csak új szervereket kell hozzáadnia az infrastruktúrához, hogy a szolgáltatás olyan gyorsan működjön, mint korábban. Mindeközben nem mindig lehetséges azonnal új szervereket hozzáadni az infrastruktúrához annak érdekében, hogy növelje a teljesítményét. Az IT-menedzsereknek gyakran sok időt kell tölteniük azzal, hogy az új szerverek beszerzését egyeztetjék a könyvelési vagy biztonsági részleggel, ráadásul gyakran cserbenhagyják őket a beszállítók, akik késve szállítanak új szervert, vagy akár rossz dolgot is szállíthatnak.
Természetesen a legjobb, ha tartalékkal építi ki Zimbra infrastruktúráját, hogy mindig legyen tartaléka a bővítésére, és ne függjön senkitől, azonban ha már történt hiba, annak következményeit az informatikai vezető csak elsimíthatja. amennyire csak lehetséges. Például egy IT-menedzser kismértékű termelékenységnövekedést érhet el, ha ideiglenesen letiltja azokat a Linux rendszerszolgáltatásokat, amelyek működés közben rendszeresen hozzáférnek a merevlemezekhez, és ezért negatívan befolyásolhatják a Zimbra teljesítményét. Tehát ideiglenesen letilthatja:
autofs, netfs - Távoli fájlrendszer-felderítési szolgáltatások
csészék — Nyomtatási szolgáltatás
xinetd, vsftpd - Beépített *NIX szolgáltatások, amelyekre valószínűleg nem lesz szüksége
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Távoli eljáráshívási szolgáltatások, amelyeket általában hálózati fájlrendszerekkel együtt használnak
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — A Zimbra Collaboration Suite fő segédprogramjainak másolatai
slocate/updatedb - Mivel a Zimbra minden üzenetet külön fájlban tárol, az updatedb szolgáltatás napi futtatása problémákat okozhat, így ez manuálisan is megtehető a szerverek legkisebb terhelése alatt
A rendszer erőforrásainak megtakarítása ezen szolgáltatások letiltása miatt nem lesz túl jelentős, de még ez is nagyon hasznos lehet vis maiorhoz közeli körülmények között. Miután az új szervert hozzáadták a Zimbra infrastruktúrához, ajánlott újra engedélyezni a korábban letiltott szolgáltatásokat.
A Zimbra működését úgy is optimalizálhatja, hogy a syslog szolgáltatást külön szerverre helyezi át, így működés közben nem tölti be a levéltárak merevlemezeit. Szinte minden számítógép alkalmas erre a célra, még egy olcsó egylapos Raspberry Pi is.
Forrás: will.com