In uno dei nostri , dedicato alla pianificazione dell'infrastruttura durante l'implementazione di Zimbra Collabortion Suite in un'azienda, è stato affermato che la limitazione principale nel funzionamento di questa soluzione è la velocità di I/O dei dispositivi disco negli archivi di posta. Infatti, in un momento in cui diverse centinaia di dipendenti di un'azienda accedono contemporaneamente allo stesso archivio di posta, la larghezza del canale per scrivere e leggere le informazioni dai dischi rigidi potrebbe non essere sufficiente per il funzionamento reattivo del servizio. E se per le piccole installazioni di Zimbra questo non sarà un problema particolare, nel caso delle grandi imprese e dei fornitori SaaS, tutto ciò può portare a e-mail che non rispondono e, di conseguenza, a una diminuzione dell'efficienza dei dipendenti, nonché a una violazione degli SLA. Ecco perché, quando si progettano e si gestiscono installazioni Zimbra su larga scala, è necessario prestare particolare attenzione all'ottimizzazione delle prestazioni dei dischi rigidi nell'archiviazione della posta. Consideriamo due casi e proviamo a scoprire quali metodi per ottimizzare il carico sullo spazio di archiviazione su disco possono essere applicati in ciascuno di essi.
1. Ottimizzazione durante la progettazione di un'installazione Zimbra su larga scala
Durante la fase di progettazione di un'installazione Zimbra ad alto carico, l'amministratore dovrà scegliere quale sistema di storage utilizzare. Per decidere su questo problema, dovresti sapere che il carico principale sui dischi rigidi proviene dal DBMS MariaDB incluso in Zimbra Collaboration Suite, dal motore di ricerca Apache Lucene e dall'archiviazione BLOB. Ecco perché per far funzionare questi prodotti software in condizioni di carico elevato è necessario utilizzare apparecchiature affidabili e ad alta velocità.
In condizioni normali, Zimbra può essere installato sia su RAID di dischi rigidi che su storage collegati tramite protocollo NFS. Per installazioni molto piccole, puoi installare Zimbra su una normale unità SATA. Tutte queste tecnologie, però, nel contesto di grandi installazioni presentano diversi svantaggi sotto forma di velocità di registrazione ridotta o bassa affidabilità, il che non è accettabile né per le grandi imprese né, soprattutto, per i fornitori SaaS.
Ecco perché nelle infrastrutture Zimbra di grandi dimensioni è meglio utilizzare una SAN. È questa tecnologia che attualmente è in grado di fornire il massimo throughput per i dispositivi di archiviazione e allo stesso tempo, grazie alla possibilità di connettere una grande quantità di cache, il suo utilizzo praticamente non comporta rischi significativi per l'azienda. È una buona idea utilizzare la NVRAM, utilizzata in molte SAN per velocizzare le operazioni durante le scritture. Ma è meglio disabilitare la memorizzazione nella cache dei dati registrati sui dischi stessi, poiché ciò può causare danni irreparabili ai supporti e perdita di dati in caso di problemi di alimentazione.
Per quanto riguarda la scelta del file system, la scelta migliore sarebbe quella di utilizzare lo standard Linux Ext3/Ext4. La principale sfumatura associata al file system è che dovrebbe essere montato con il parametro -noatime. Questa opzione disabiliterà la funzione di registrazione dell'ora dell'ultimo accesso ai file, il che significa che ridurrà notevolmente il carico di lettura e scrittura. In generale, quando si crea un file system ext3 o ext4 per Zimbra, è necessario utilizzare i seguenti parametri dell'utilità moglie2fs:
-j — Per creare un journal del file system: creare il file system con un journal ext3/ext4.
-L NOME - Per creare un nome di volume da utilizzare poi in /etc/fstab
-O dir_index - Utilizzare un albero di ricerca con hash per velocizzare le ricerche di file in directory di grandi dimensioni
-m2 — Per riservare il 2% del volume nei file system di grandi dimensioni per la directory root
-Taglia J=400 — Creare una grande rivista
-b4096 — Per determinare la dimensione del blocco in byte
-io 10240 - Per l'archiviazione dei messaggi, questa impostazione dovrebbe corrispondere alla dimensione media dei messaggi. Dovresti prestare molta attenzione a questo parametro, poiché il suo valore non può essere modificato in seguito.
Si consiglia inoltre di abilitare disincrona per l'archiviazione BLOB, l'archiviazione dei metadati di ricerca Lucene e l'archiviazione delle code MTA. Questo dovrebbe essere fatto perché Zimbra solitamente utilizza l'utilità fsync per la scrittura garantita di un BLOB con dati su disco. Tuttavia, quando l'archivio di posta Zimbra o l'MTA creano nuovi file durante la consegna dei messaggi, diventa necessario scrivere su disco le modifiche che si verificano nelle cartelle corrispondenti. Ecco perché, anche se il file è già stato scritto su disco utilizzando fsync, la registrazione della sua aggiunta alla directory potrebbe non avere il tempo di essere scritta sul disco e, di conseguenza, potrebbe andare persa a causa di un improvviso guasto del server. Grazie all'uso disincrona questi problemi possono essere evitati.
2. Ottimizzazione con infrastruttura Zimbra in esecuzione
Accade spesso che dopo diversi anni di utilizzo di Zimbra, il numero dei suoi utenti aumenti in modo significativo e il servizio diventi ogni giorno sempre meno reattivo. La via d'uscita da questa situazione è ovvia: basta aggiungere nuovi server all'infrastruttura affinché il servizio funzioni di nuovo con la stessa rapidità di prima. Nel frattempo, non è sempre possibile aggiungere immediatamente nuovi server all'infrastruttura per aumentarne le prestazioni. I responsabili IT spesso devono dedicare molto tempo al coordinamento dell'acquisto di nuovi server con il reparto contabilità o sicurezza; inoltre, vengono spesso delusi dai fornitori che possono consegnare un nuovo server in ritardo o addirittura consegnare la cosa sbagliata.
Naturalmente è meglio costruire la propria infrastruttura Zimbra con una riserva per avere sempre una riserva per la sua espansione e non dipendere da nessuno, tuttavia, se è già stato commesso un errore, il responsabile IT può solo appianarne le conseguenze come quanto più possibile. Ad esempio, un responsabile IT può ottenere un piccolo aumento di produttività disabilitando temporaneamente i servizi del sistema Linux che accedono regolarmente ai dischi rigidi durante il funzionamento e possono quindi avere un impatto negativo sulle prestazioni di Zimbra. Quindi, puoi disabilitare temporaneamente:
autofs, netfs - Servizi di rilevamento del file system remoto
tazza — Servizio di stampa
xinetd, vsftpd - Servizi *NIX integrati di cui probabilmente non avrai bisogno
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servizi di chiamata di procedura remota, solitamente utilizzati insieme ai file system di rete
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicati delle principali utilità incluse in Zimbra Collaboration Suite
slocate/aggiornatob - Poiché Zimbra memorizza ogni messaggio in un file separato, l'esecuzione quotidiana del servizio aggiornatob può causare problemi, quindi è possibile farlo manualmente durante il minor carico sui server
Il risparmio di risorse di sistema derivante dalla disabilitazione di questi servizi non sarà molto significativo, ma anche questo può essere molto utile in condizioni prossime a cause di forza maggiore. Una volta aggiunto il nuovo server all'infrastruttura Zimbra, si consiglia di riattivare i servizi precedentemente disabilitati.
Puoi 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 degli archivi di posta. Quasi tutti i computer sono adatti a questi scopi, anche un economico Raspberry Pi a scheda singola.
Fonte: habr.com