In uno dei nostri , dedicata alla pianificazione dell'infrastruttura per l'implementazione di Zimbra Collaboration Suite, è stato detto che la principale limitazione di questa soluzione è la velocità di input-output dei dispositivi di archiviazione. Infatti, quando 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 mantenerne la reattività. Se per piccole installazioni di Zimbra ciò non rappresenta un problema significativo, per grandi aziende e fornitori di SaaS questo potrebbe portare a un servizio email non reattivo, con conseguente riduzione dell'efficienza dei dipendenti e violazione degli SLA. Per questo motivo, nella progettazione e gestione di grandi installazioni di Zimbra, è fondamentale prestare particolare attenzione all'ottimizzazione delle prestazioni dei dischi nell'archivio di posta. Analizziamo due casi e vediamo quali metodi di ottimizzazione del carico sugli archivi disco possono essere applicati in ciascuno di essi.
1. Ottimizzazione nella progettazione di un'installazione scalabile di Zimbra
Nella fase di progettazione di un'installazione Zimbra ad alto carico, l'amministratore deve decidere quale sistema di archiviazione utilizzare. È fondamentale sapere che il carico principale sui dischi rigidi è generato dai database MariaDB inclusi nel Zimbra Collaboration Suite, dal sistema di ricerca Apache Lucene e dallo storage degli oggetti BLOB. Per garantire il corretto funzionamento di questi prodotti software in condizioni di alta pressione, è necessario utilizzare attrezzature ad alta velocità e affidabili.
In condizioni normali, è possibile installare Zimbra sia su un'array RAID di dischi rigidi che su archiviazioni collegate tramite protocollo NFS. Per installazioni molto piccole, Zimbra può essere installato su un disco SATA convenzionale. Tuttavia, nelle installazioni di grandi dimensioni, tutte queste tecnologie presentano vari svantaggi, come una velocità di scrittura ridotta o bassa affidabilità, il che è inaccettabile sia per le grandi imprese che, tantomeno, per i fornitori di SaaS.
È proprio per questo che, in un contesto di infrastrutture scalabili, è consigliabile utilizzare un SAN con Zimbra. Attualmente, è in grado di garantire la massima capacità di trasmissione per i dispositivi di memorizzazione e, grazie alla possibilità di collegare un gran numero di cache, il suo utilizzo non comporta rischi significativi per l'azienda. È opportuno considerare l'uso di NVRAM, che è presente in molti SAN per accelerare le operazioni di scrittura. Tuttavia, è meglio disattivare la memorizzazione nella cache dei dati scritti sui dischi stessi, poiché potrebbe causare danni irreparabili ai supporti e perdita di dati in caso di problemi di alimentazione.
Per quanto riguarda la scelta del file system, l'opzione ottimale è l'uso degli standard Ext3/Ext4 per Linux. Il principale aspetto da tenere presente riguardo al file system è che deve essere montato con il parametro -noatime. Questa opzione disabiliterà la funzione di registrazione dell'ultimo accesso ai file, riducendo notevolmente il carico di lettura e scrittura. In generale, durante la creazione di un file system ext3 o ext4 per Zimbra, è consigliabile utilizzare i seguenti parametri dell'utilità mke2fs:
-j — Per creare un file system con un registro ext3/ext4.
-L NOME — Per creare un nome di volume, da utilizzare in /etc/fstab
-O dir_index — Per utilizzare un albero di ricerca hashato per accelerare la ricerca di file in directory grandi
-m 2 — Per riservare il 2% dello spazio nelle grandi file system per la directory root
-J size=400 — Per creare un grande registro
-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. È necessario prestare particolare attenzione a questo parametro poiché il suo valore non potrà essere modificato in seguito
Inoltre, è consigliato attivare dirsync per lo storage degli oggetti BLOB, lo storage dei metadati di ricerca Lucene e lo storage della coda MTA. Questo dovrebbe essere fatto perché di solito Zimbra utilizza l'utilità fsync per garantire la registrazione di un blob di dati su disco. Tuttavia, quando lo storage di posta Zimbra o il MTA creano nuovi file durante la consegna dei messaggi, si rende necessario registrare su disco le modifiche apportate nelle cartelle corrispondenti. È proprio per questo che anche nel caso in cui il file sia già stato registrato su disco attraverso fsync, la registrazione della sua aggiunta nella directory potrebbe non riuscire a essere scritta su disco e, di conseguenza, potrebbe andare persa a causa di un'improvvisa interruzione del server. Grazie all'utilizzo di dirsync è possibile evitare questi problemi.
2. Ottimizzazione dell'infrastruttura Zimbra in funzione
Spesso accade che, dopo alcuni anni di utilizzo, il numero di utenti di Zimbra aumenti significativamente, e il servizio diventa via via meno reattivo. L'uscita da questa situazione è ovvia: è sufficiente aggiungere nuovi server all'infrastruttura affinché il servizio torni a funzionare con la stessa rapidità di prima. Tuttavia, non sempre è possibile aggiungere immediatamente nuovi server all'infrastruttura per migliorare le sue prestazioni. Spesso, gli IT manager devono negoziare per lungo tempo l'acquisto di nuovi server con la contabilità o il dipartimento di sicurezza; inoltre, i fornitori a volte deludono, arrivando a consegnare un nuovo server in ritardo o addirittura il modello sbagliato.
È chiaro che è meglio costruire la propria infrastruttura Zimbra con un margine di sicurezza, in modo da avere sempre una possibilità di espansione e non dover dipendere da nessuno. Tuttavia, se l'errore è stato già commesso, il manager IT deve cercare di attenuarne le conseguenze il più possibile. Ad esempio, il manager IT può ottenere un leggero aumento delle prestazioni disattivando temporaneamente i servizi di sistema Linux che, durante il loro funzionamento, accedono regolarmente ai dischi rigidi e, di conseguenza, possono influenzare negativamente la velocità di Zimbra. I seguenti servizi possono essere disattivati 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, solitamente utilizzati con i file system di rete
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicati delle utilità principali incluse nella Zimbra Collaboration Suite
slocate/updatedb — Poiché Zimbra memorizza ogni messaggio in un file separato, l'esecuzione quotidiana del servizio updatedb può causare problemi, quindi è meglio farlo manualmente durante i periodi di minore carico sui server.
Il risparmio di risorse di sistema derivante dalla disattivazione di questi servizi non sarà molto significativo, ma anche questo può tornare utile in condizioni vicine a situazioni di emergenza. Una volta che il nuovo server è stato aggiunto all'infrastruttura Zimbra, è consigliabile riattivare i servizi precedentemente disattivati.
Si può anche ottimizzare il funzionamento di Zimbra spostando il servizio syslog su un server separato, in modo che durante il funzionamento non carichi i dischi rigidi dei depositi di posta. A questo scopo, può andar bene praticamente qualsiasi computer, incluso un economico Raspberry Pi.
Fonte: habr.com
