Nun dos nosos , dedicada á planificación da infraestrutura ao implementar Zimbra Collaboration Suite nunha empresa, dicíase que a principal limitación no funcionamento desta solución é a velocidade de E/S dos dispositivos de disco nos almacenamentos de correo. De feito, nun momento no que varios centos de empregados dunha empresa acceden simultáneamente ao mesmo almacenamento de correo, o ancho da canle para escribir e ler información dos discos duros pode non ser suficiente para o funcionamento sensible do servizo. E se para pequenas instalacións de Zimbra este non será un problema particular, entón no caso das grandes empresas e provedores de SaaS, todo isto pode levar a que o correo electrónico non responda e, como resultado, unha diminución da eficiencia dos empregados, así como unha violación. de SLA. É por iso que, ao deseñar e operar instalacións de Zimbra a gran escala, debe prestarse especial atención á optimización do rendemento dos discos duros no almacenamento de correo. Vexamos dous casos e intentemos descubrir que métodos para optimizar a carga no almacenamento en disco se poden aplicar en cada un deles.
1. Optimización ao deseñar unha instalación Zimbra a gran escala
Durante a fase de deseño dunha instalación de alta carga de Zimbra, o administrador terá que escoller que sistema de almacenamento utilizar. Para decidir sobre este problema, debes saber que a carga principal dos discos duros provén do DBMS MariaDB incluído no Zimbra Collaboration Suite, o motor de busca Apache Lucene e o almacenamento de blobs. É por iso que para operar estes produtos de software en condicións de alta carga é necesario utilizar equipos fiables e de alta velocidade.
En condicións normais, Zimbra pódese instalar tanto en RAID de discos duros como en almacenamento conectado mediante o protocolo NFS. Para instalacións moi pequenas, pode instalar Zimbra nunha unidade SATA normal. Non obstante, no contexto das grandes instalacións, todas estas tecnoloxías demostran diversas desvantaxes en forma de velocidade de gravación reducida ou baixa fiabilidade, o que non é inaceptable nin para as grandes empresas nin, especialmente, para os provedores de SaaS.
É por iso que en infraestruturas de Zimbra a gran escala é mellor utilizar unha SAN. É esta tecnoloxía a que actualmente é capaz de proporcionar o maior rendemento para os dispositivos de almacenamento e, ao mesmo tempo, grazas á posibilidade de conectar unha gran cantidade de caché, o seu uso practicamente non supón ningún risco significativo para a empresa. É unha boa idea usar NVRAM, que se usa en moitas SAN para acelerar as cousas durante as escrituras. Pero é mellor desactivar o almacenamento en caché dos datos gravados nos propios discos, xa que pode provocar danos irreparables aos medios e perda de datos se ocorren problemas de alimentación.
En canto á elección dun sistema de ficheiros, a mellor opción sería utilizar o estándar Linux Ext3/Ext4. O principal matiz asociado ao sistema de ficheiros é que debería montarse co parámetro -noatime. Esta opción desactivará a función de gravar a hora do último acceso aos ficheiros, o que significa que reducirá moito a carga de lectura e escritura. En xeral, ao crear un sistema de ficheiros ext3 ou ext4 para Zimbra, debes usar os seguintes parámetros de utilidade mke2fs:
-j — Para crear un diario do sistema de ficheiros Cree o sistema de ficheiros cun diario ext3/ext4.
-L NOME - Para crear un nome de volume para despois usar en /etc/fstab
-O dir_index - Para usar unha árbore de busca hash para acelerar as buscas de ficheiros en directorios grandes
-m 2 — Para reservar o 2% do volume en grandes sistemas de ficheiros para o directorio raíz
-Tamaño J = 400 — Crear unha revista grande
-b 4096 — Para determinar o tamaño do bloque en bytes
-eu 10240 - Para o almacenamento de mensaxes, esta configuración debería corresponder ao tamaño medio da mensaxe. Debe prestar moita atención a este parámetro, xa que o seu valor non se pode cambiar máis tarde.
Tamén se recomenda activar sincronización de directorios para almacenamento de blobs, almacenamento de metadatos de busca de Lucene e almacenamento de cola MTA. Isto debería facerse porque Zimbra normalmente usa a utilidade fsync para garantir a escritura dun blob con datos no disco. Non obstante, cando a tenda de correo de Zimbra ou o MTA crean novos ficheiros durante a entrega da mensaxe, faise necesario escribir no disco os cambios que se produzan nos cartafoles correspondentes. É por iso que, mesmo no caso de que o ficheiro xa foi escrito no disco usando fsync, o rexistro da súa adición ao directorio pode non ter tempo para escribirse no disco e, como resultado, pode perderse debido a un fallo repentino do servidor. Grazas ao uso sincronización de directorios estes problemas pódense evitar.
2. Optimización coa infraestrutura Zimbra en execución
Adoita ocorrer que despois de varios anos de uso de Zimbra, o número dos seus usuarios aumenta significativamente e o servizo faise cada vez menos sensible cada día. A saída desta situación é obvia: só tes que engadir novos servidores á infraestrutura para que o servizo volva a funcionar tan rápido como antes. Mentres tanto, non sempre é posible engadir inmediatamente novos servidores á infraestrutura para aumentar o seu rendemento. Os xestores de TI a miúdo teñen que dedicar moito tempo a coordinar a compra de novos servidores co departamento de contabilidade ou de seguridade; ademais, adoitan ser decepcionados por provedores que poden entregar un novo servidor tarde ou incluso entregar o material equivocado.
Por suposto, o mellor é construír a túa infraestrutura Zimbra cunha reserva para ter sempre unha reserva para a súa expansión e non depender de ninguén, non obstante, se xa se cometeu un erro, o responsable de TI só pode suavizar as súas consecuencias xa que na medida do posible. Por exemplo, un xestor de TI pode conseguir un pequeno aumento da produtividade desactivando temporalmente os servizos do sistema Linux que acceden regularmente aos discos duros durante o funcionamento e, polo tanto, poden afectar negativamente o rendemento de Zimbra. Entón, podes desactivar temporalmente:
autofs, netfs - Servizos de detección de sistemas de ficheiros remotos
vasos - Servizo de impresión
xinetd, vsftpd - Servizos *NIX integrados que probablemente non necesitarás
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servizos de chamadas de procedementos remotos, que adoitan utilizarse en conxunto cos sistemas de ficheiros de rede
pombal, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicados das principais utilidades incluídas no Zimbra Collaboration Suite
situar/actualizarb - Dado que Zimbra almacena cada mensaxe nun ficheiro separado, executar o servizo updatedb todos os días pode causar problemas e, polo tanto, é posible facelo manualmente durante a menor carga dos servidores.
O aforro de recursos do sistema como consecuencia da desactivación destes servizos non será moi significativo, pero mesmo isto pode ser moi útil en condicións próximas á forza maior. Unha vez que se engade o novo servidor á infraestrutura de Zimbra, recoméndase volver habilitar os servizos previamente desactivados.
Tamén pode optimizar o funcionamento de Zimbra movendo o servizo syslog a un servidor separado para que durante o funcionamento non cargue os discos duros dos almacenamentos de correo. Case calquera ordenador é axeitado para estes propósitos, incluso un Raspberry Pi barato de placa única.
Fonte: www.habr.com