In uno dei nostri , dedicato alla pianificazione dell'infrastruttura durante l'implementazione di Zimbra Collaboration Suite in azienda, si è detto che la principale limitazione nell'utilizzo di questa soluzione è la velocità di input-output dei dispositivi di archiviazione negli archivi di posta. E in effetti, quando diverse centinaia di dipendenti accedono contemporaneamente allo stesso archivio di posta, la larghezza di banda per la scrittura e la lettura delle informazioni dai dischi rigidi potrebbe non essere sufficiente per garantire un servizio reattivo. Se per installazioni di piccole dimensioni di Zimbra questo non rappresenta un grosso problema, nel caso di grandi aziende e fornitori di SaaS, tutto ciò può portare a un funzionamento non reattivo della posta elettronica e, di conseguenza, a una riduzione dell'efficienza dei dipendenti, oltre a violazioni del SLA. Proprio per questo motivo, nella progettazione e gestione di installazioni di Zimbra su larga scala è fondamentale prestare particolare attenzione all'ottimizzazione del funzionamento dei dischi rigidi negli archivi di posta. Esaminiamo due casi e cerchiamo di capire quali metodi di ottimizzazione del carico sugli archivi di dati possono essere applicati in ciascuno di essi.
1. Ottimizzazione nella progettazione di un'installazione su larga scala di Zimbra
Nella fase di progettazione di un'installazione ad alto carico di Zimbra, l'amministratore deve scegliere quale sistema di archiviazione dati utilizzare. Per determinare questo aspetto, è importante sapere che il maggior carico sui dischi rigidi è generato dai database MariaDB, dal sistema di ricerca Apache Lucene e dallo storage di oggetti BLOB che fanno parte di Zimbra Collaboration Suite. Per garantire il corretto funzionamento di questi prodotti software in condizioni di alto carico, è necessario utilizzare attrezzature veloci e affidabili.
In condizioni normali, Zimbra può essere installato sia su RAID di dischi rigidi che su archivi collegati tramite protocollo NFS. In caso di installazioni realmente piccole, è possibile installare Zimbra su un disco SATA comune. Tuttavia, nelle grandi installazioni, tutte queste tecnologie presentano vari svantaggi come una ridotta velocità di scrittura o bassa affidabilità, che non sono accettabili né per le grandi aziende né, tantomeno, per i fornitori di SaaS.
Ecco perché nelle infrastrutture su larga scala, Zimbra funziona meglio con SAN. Al momento, è in grado di offrire la massima larghezza di banda per i dispositivi di archiviazione e, grazie alla possibilità di collegare un gran numero di cache, il suo utilizzo non comporta rischi significativi per l'azienda. È una buona idea utilizzare la NVRAM, che è impiegata in molte SAN per accelerare la scrittura. Tuttavia, è meglio disattivare la memorizzazione nella cache dei dati scritti sui dischi, poiché potrebbe portare a danni irreversibili ai supporti e alla perdita di dati in caso di problemi di alimentazione.
Per quanto riguarda la scelta del file system, la scelta ottimale è utilizzare i normali Ext3/Ext4 per Linux. Il principale aspetto da considerare con il file system è che deve essere montato con il parametro -noatime. Questo parametro disabilita la funzione di registrazione del tempo dell'ultimo accesso ai file, riducendo notevolmente il carico di lettura e scrittura. In generale, quando si crea un file system ext3 o ext4 per Zimbra, è consigliabile utilizzare i seguenti parametri dell'utilità mke2fs:
-j — Per creare un journal per il file systemCreate the file system with an ext3/ext4 journal.
-L NOME — Per creare un nome per il volume, in modo da poterlo utilizzare in /etc/fstab
-O dir_index — Per utilizzare un albero di ricerca hash per velocizzare la ricerca di file in directory di grandi dimensioni
-m 2 — Per riservare il 2% dello spazio nelle grandi file system per la root
-J size=400 — Per creare un grande journal
-b 4096 — Per definire la dimensione del blocco in byte
-i 10240 — Per lo storage dei messaggi, questo parametro deve corrispondere alla dimensione media dei messaggi. È importante prestare attenzione a questo parametro, poiché successivamente il suo valore non potrà essere modificato
Inoltre, è consigliabile abilitare dirsync per lo storage degli oggetti BLOB, lo storage dei metadati di ricerca Lucene e lo storage della coda MTA. Questo è necessario perché solitamente Zimbra utilizza l'utilità fsync per garantire la registrazione di un blob di dati su disco. Tuttavia, quando lo storage email Zimbra o il MTA creano nuovi file durante la consegna dei messaggi, sorge la necessità di registrare su disco le modifiche avvenute nelle cartelle corrispondenti. Ecco perché anche nel caso in cui il file sia già stato scritto su disco tramite fsync, la registrazione della sua aggiunta nella directory potrebbe non aver tempo di essere scritta su disco e, di conseguenza, potrebbe andare persa a causa di un'improvvisa rottura del server. Grazie all'uso di dirsync questi problemi si possono evitare.
2. Ottimizzazione con infrastruttura Zimbra operativa
Spesso capita che, dopo alcuni anni di utilizzo di Zimbra, il numero dei suoi utenti aumenti notevolmente e il funzionamento del servizio diventi giorno dopo giorno sempre meno reattivo. L'uscita da questa situazione è ovvia: è necessario semplicemente aggiungere nuovi server all'infrastruttura, affinché il servizio torni a funzionare con la stessa velocità di prima. Tuttavia, non sempre è possibile aggiungere immediatamente nuovi server all'infrastruttura per migliorare le sue prestazioni. Spesso i responsabili IT devono negoziare a lungo l'acquisto di di nuovi server con la contabilità o il dipartimento di sicurezza; inoltre, spesso i fornitori non rispettano le scadenze, consegnando un nuovo server in ritardo o portando addirittura qualcosa di diverso da ciò di cui si ha bisogno.
È chiaro che sarebbe meglio costruire la propria infrastruttura Zimbra con un margine, in modo da avere sempre la possibilità di espanderla senza dipendere da nessuno, ma se l'errore è già stato commesso, il responsabile IT deve solo cercare di mitigare al massimo le conseguenze. Ad esempio, il responsabile IT può ottenere un lieve aumento delle prestazioni disattivando temporaneamente i servizi di sistema Linux, che durante il funzionamento accedono regolarmente ai dischi rigidi e, di conseguenza, possono influire negativamente sulla velocità di funzionamento di Zimbra. Pertanto, si possono disattivare temporaneamente:
autofs, netfs — Servizi di rilevamento dei file system remoti
cups — Servizio di stampa
xinetd, vsftpd — Servizi integrati *NIX, che probabilmente non ti serviranno
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servizi di chiamata remota di procedure, generalmente utilizzati in combinazione con i file system di rete
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicati delle principali utility incluse nella Zimbra Collaboration Suite
slocate/updatedb Poiché Zimbra memorizza ogni messaggio in un file separato, l'esecuzione quotidiana del servizio updatedb potrebbe causare problemi, pertanto è consigliabile eseguirlo manualmente durante i periodi di minor carico sui server.
Il risparmio delle risorse di sistema derivante dalla disattivazione di questi servizi non sarà molto significativo, ma anche questo potrebbe essere molto utile in situazioni di emergenza. Dopo aver aggiunto un nuovo server all'infrastruttura Zimbra, è consigliabile riattivare i servizi precedentemente disattivati.
È possibile ottimizzare le prestazioni di Zimbra spostando il servizio syslog su un server dedicato, in modo che durante il funzionamento non sovraccarichi i dischi rigidi dei archivi di posta. A questo scopo, praticamente qualsiasi computer, fino a un economico Raspberry Pi, può andare bene.
Fonte: habr.com
