Egy korábbi cikkünkben , említettük, hogy a megoldás működésének legfőbb korlátja a levelezési tárolók diszkek bemeneti-kimeneti sebessége. Valóban, amikor a vállalat néhány száz dolgozója egyszerre fér hozzá ugyanahhoz a levelezési tárolóhoz, a merevlemezek írási és olvasási sebessége nem biztos, hogy elegendő a szolgáltatás zökkenőmentes működéséhez. Ha kisebb Zimbra telepítéseknél ez nem jelent különösebb problémát, akkor a nagyobb vállalatok és SaaS-szolgáltatók esetében ez a levélkezelés lelassulásához vezethet, amely csökkenti a munkavállalók hatékonyságát és megsérti a SLA-t. Ezért nagy léptékű Zimbra telepítések tervezése és üzemeltetése során különös figyelmet kell fordítani a levelezési tárolók merevlemezeinek működésének optimalizálására. Nézzünk meg két esetet, és próbáljunk meg kideríteni, milyen tárolóterhelés-optimalizáló módszerek alkalmazhatóak mindkettőben.
1. Optimalizálás a nagy terhelésű Zimbra telepítés tervezésénél
A nagy teherbírású Zimbra telepítés tervezési szakaszában az adminisztrátornak választania kell, milyen adattároló rendszert használjon. Annak érdekében, hogy döntést hozhasson, tudnia kell, hogy a legnagyobb terhelést a Zimbra Collaboration Suite részeként működő MariaDB adatbázis, az Apache Lucene keresőrendszer, valamint a BLOB-objektumok tárolója generálja. Ezért ezen szoftvertermékek működéséhez nagy terhelés mellett gyors és megbízható berendezéseket kell használni.
Hagyományos körülmények között a Zimbát RAID merevlemezeken vagy NFS protokollal csatlakoztatott tárolókra lehet telepíteni. Nagyon kis telepítések esetén a Zimbra normál SATA lemezen is telepíthető. Azonban a nagyobb telepítések esetén mindezek a technológiák különböző hátrányokat mutatnak, mint például csökkent írási sebesség vagy alacsony megbízhatóság, ami sem nagyvállalatok, sem még inkább SaaS-szolgáltatók számára nem elfogadható.
Ezért a Zimbra nagyszabású infrastruktúráinak használatakor a SAN az ideális megoldás. Jelenleg ez képes biztosítani a legnagyobb átviteli sebességet a tárolóeszközök számára, és a nagy mennyiségű gyorsítótár csatlakoztatásának lehetősége miatt szinte nincs lényeges kockázata a vállalat számára. Jó ötlet lehet NVRAM használata, amelyet sok SAN-nál használnak a írási műveletek felgyorsítására. A rögzítő adatok gyorsítótárazását a lemezeken azonban érdemes letiltani, mivel ez visszafordíthatatlan károkat és adatvesztést okozhat áramellátási problémák esetén.
A fájlrendszer választását illetően az optimális választás a Linux szabványos Ext3/Ext4 használata. A fájlrendszerrel kapcsolatos fő szempont az, hogy azt a következő paraméterrel kell csatolni: -noatime. Ez a paraméter letiltja a fájlokhoz való legutolsó hozzáférés időpontjának rögzítését, így jelentősen csökkenti a beolvasás és írás terhelését. Általában, amikor ext3 vagy ext4 fájlrendszert hozunk létre a Zimbra számára, az alábbi paramétereket kell használni a mke2fs:
-j — A fájlrendszer naplózásának létrehozásához. Hozza létre a fájlrendszert ext3/Ext4 naplóval.
-L NÉV — A kötet nevének létrehozása, amelyet később az /etc/fstab-ban lehet használni.
-O dir_index — A fájlok nagy könyvtárakban való keresésének felgyorsításához használt hashfás keresőfa alkalmazására.
-m 2 — A gyökérkönyvtár számára a nagy fájlrendszerek 2%-ának fenntartására.
-J size=400 — Nagy napló létrehozásához.
-b 4096 — A blokk méretének byte-ban történő meghatározásához.
-i 10240 — Az üzenettároló esetében ennek a paraméternek meg kell felelnie az üzenetek átlagos méretének. Ezt a paramétert körültekintően kell kezelni, mivel később az értéke nem módosítható.
Ezen kívül ajánlott bekapcsolni a dirsync a BLOB-objektum tárolásához, a Lucene metaadat-kereső tárolásához és az MTA sor tárolásához. Ezt azért szükséges megtenni, mert általában a Zimbra eszközként használja. fsync a garantált blob fájlok lemezre írásához. Azonban amikor a Zimbra levelezőtár vagy az MTA új fájlokat hoz létre az üzenetek kézbesítése során, szükség van a megfelelő mappákban bekövetkezett változások lemezre írására. Ezért még akkor is, amikor a fájl már lemezre került írásra fsync, a könyvtárba való hozzáadásáról szóló bejegyzés elképzelhető, hogy nem elég gyorsan íródik le a lemezre, és így hirtelen szerverhiba miatt elveszhet. dirsync Ezeket a problémákat el lehet kerülni.
2. Optimalizálás Zimbra működő infrastruktúrájánál
Gyakran előfordul, hogy Zimbra több éves használata után a felhasználók száma jelentősen megnő, és a szolgáltatás minden nap egyre kevésbé válik reagálóképessé. A helyzet megoldása nyilvánvaló: új szervereket kell hozzáadni az infrastruktúrához, hogy a szolgáltatás újra olyan gyorsan működjön, mint korábban. Azonban nem mindig van lehetőség új szervereket azonnal hozzáadni az infrastruktúrához a teljesítmény javítása érdekében. Gyakran az IT-vezetők hosszú ideig tartanak a beszerzés jóváhagyásával új szerverek a könyveléssel vagy a biztonsági osztállyal, ráadásul gyakran a szolgáltatók is problémásak, akik késve hozhatják el az új szervert, vagy éppen az, amire szükség van, helyett mást szállítanak.
Nyilvánvaló, hogy a legjobb az, ha Zimbra infrastruktúráját tartalékkal építjük fel, hogy mindig legyen hely a bővítésre és elkerüljük a függőségeket, azonban ha a hiba már megtörtént, az IT-vezetőnek csak a következmények maximális enyhítésére van lehetősége. Például az IT-vezető elérhet egy kis teljesítménynövekedést, ha ideiglenesen leállítja a Linux rendszerfolyamatokat, amelyek működés közben rendszeresen hivatkoznak a merevlemezekre, és ezzel negatívan befolyásolják a Zimbra működését. Így például ideiglenesen leállítható:
autofs, netfs — Távoli fájlrendszerek felfedezéséért felelős szolgáltatások
cups — Nyomtatási szolgáltatás
xinetd, vsftpd — Olyan beépített *NIX szolgáltatások, amelyek valószínűleg nem szükségesek
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Olyan távoli eljáráshívó szolgáltatások, amelyeket általában a hálózati fájlrendszerekkel használnak együtt
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — A Zimbra Collaboration Suite fő szolgáltatásainak duplikátumai
slocate/updatedb Mivel a Zimbra minden üzenetet külön fájlban tárol, a daily updatedb szolgáltatás futtatása problémákat okozhat, ezért azt manuálisan érdemes elvégezni a szerverek legkisebb terhelése idején.
A leállított szolgáltatásokból származó rendszerforrás-megtakarítás nem lesz jelentős, de még ez is hasznos lehet vészhelyzet közeli körülmények között. Miután az új szerver bekerült a Zimbra infrastruktúrába, ajánlott újra aktiválni a korábban leállított szolgáltatásokat.
A Zimbra működésének optimalizálása érdekében a syslog szolgáltatást érdemes külön szerverre áthelyezni, hogy ne terhelje a levelezési tárolók merevlemezeit. Ezekhez a feladatokhoz szinte bármelyik számítógép megfelel, egészen az olcsó Raspberry Pi-ig.
Forrás: habr.com
