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 á escolla do sistema de ficheiros, a opción óptima sería usar os estándar para Linux Ext3/Ext4. O principal matiz asociado co sistema de ficheiros é que debe 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
A miúdo ocorre que despois de varios anos de uso de Zimbra, o número dos seus usuarios aumenta significativamente e o servizo vólvese cada vez menos receptivo. A solución a esta situación é obvia: simplemente engadir novos servidores á infraestrutura para restaurar a velocidade do servizo. Non obstante, non sempre é posible engadir inmediatamente novos servidores á infraestrutura para mellorar o seu rendemento. Os xestores de TI adoitan ter que dedicar moito tempo a coordinar a compra. novos servidores Ademais, os provedores a miúdo non entregan un novo servidor tarde ou mesmo entregan o artigo incorrecto, mesmo cos departamentos de contabilidade ou seguridade.
Por suposto, é mellor construír a túa infraestrutura de Zimbra cunha reserva, para que sempre teñas espazo para a expansión e non teñas que depender de ninguén. Non obstante, se xa se cometeu un erro, o xestor de TI só pode mitigar as súas consecuencias na medida do posible. Por exemplo, un xestor de TI pode conseguir unha pequena mellora do rendemento desactivando temporalmente os servizos do sistema. Linux, que acceden regularmente aos discos duros durante o funcionamento e, como resultado, poden afectar negativamente ao rendemento de Zimbra. Por exemplo, 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
