En uno de nuestros , dedicado a la planificación de la infraestructura para la implementación de Zimbra Collaboration Suite en una empresa, se mencionó que la principal limitación para el funcionamiento de esta solución es la velocidad de entrada y salida de los dispositivos de almacenamiento en los buzones de correo. Y de hecho, en el momento en que varios cientos de empleados de la empresa acceden al mismo buzón de correo, el ancho de banda para la lectura y escritura de información desde los discos duros puede no ser suficiente para un funcionamiento ágil del servicio. Y si para instalaciones pequeñas de Zimbra esto no será un problema importante, en el caso de grandes empresas y proveedores de SaaS, todo esto puede llevar a un funcionamiento poco receptivo del correo electrónico y, como consecuencia, a una disminución de la efectividad de los empleados, así como a violaciones del SLA. Es por eso que al diseñar y operar instalaciones a gran escala de Zimbra, se debe prestar especial atención a la optimización del funcionamiento de los discos duros en los buzones de correo. Vamos a considerar dos casos y tratar de averiguar qué métodos de optimización de la carga en el almacenamiento de discos se pueden aplicar en cada uno de ellos.
1. Optimización en el diseño de una instalación a gran escala de Zimbra
En la etapa de diseño de una instalación de Zimbra con alta carga, el administrador debe decidir qué sistema de almacenamiento de datos usar. Para abordar esta cuestión, es importante saber que la carga principal en los discos duros es generada por las bases de datos MariaDB, el sistema de búsqueda Apache Lucene, así como el almacenamiento de objetos BLOB que forman parte de Zimbra Collaboration Suite. Por eso, para el funcionamiento de estos productos de software bajo alta carga, es necesario utilizar hardware rápido y confiable.
En condiciones normales, Zimbra se puede instalar tanto en RAID de discos duros como en almacenamiento conectado a través del protocolo NFS. En el caso de instalaciones muy pequeñas, se puede instalar Zimbra en un disco SATA convencional. Sin embargo, en grandes instalaciones, todas estas tecnologías demuestran diversas desventajas, como la velocidad de escritura reducida o la baja confiabilidad, lo cual es inaceptable tanto para grandes empresas como, aún más, para proveedores de SaaS.
Por eso, en el contexto de infraestructuras a gran escala, lo mejor sería utilizar SAN para Zimbra. En este momento, puede ofrecer la mayor capacidad de rendimiento para dispositivos de almacenamiento y, gracias a la posibilidad de conectar una gran cantidad de caché, su uso prácticamente no representa riesgos significativos para la empresa. Una buena idea es utilizar NVRAM, que se usa en muchos SAN para acelerar el rendimiento durante las escrituras. Sin embargo, es mejor desactivar la caché de datos escritos en los propios discos, ya que esto puede causar daños irreparables a los dispositivos y pérdida de datos en caso de problemas con la energía.
En cuanto a la elección del sistema de archivos, la mejor opción es usar Ext3/Ext4, estándar en Linux. El principal matiz relacionado con el sistema de archivos es que debe montarse con el parámetro -noatime. Este parámetro desactivará la función de registro de la última vez que se accedió a los archivos, lo que reducirá significativamente la carga en las operaciones de lectura y escritura. En general, al crear un sistema de archivos ext3 o ext4 para Zimbra, se deben utilizar los siguientes parámetros en la utilidad mke2fs:
-j — Para crear un registro del sistema de archivos, crear el sistema de archivos con un registro ext3/ext4.
-L NOMBRE — Para asignar un nombre al volumen, que luego se utilizará en /etc/fstab.
-O dir_index — Para utilizar un árbol de búsqueda hash para acelerar la búsqueda de archivos en grandes directorios.
-m 2 — Para reservar el 2% del volumen en grandes sistemas de archivos para el directorio raíz.
-J size=400 — Para crear un gran registro.
-b 4096 — Para definir el tamaño del bloque en bytes.
-i 10240 — Para el almacenamiento de mensajes, este parámetro debe corresponder al tamaño promedio de los mensajes. Se debe tener cuidado con este parámetro, ya que posteriormente no se podrá cambiar su valor.
Además, se recomienda habilitar dirsync para el almacenamiento de objetos BLOB, el almacenamiento de metadatos de búsqueda de Lucene y el almacenamiento de colas MTA. Esto se debe a que generalmente Zimbra utiliza la utilidad. fsync para garantizar la escritura de un blob de datos en el disco. Sin embargo, cuando el almacenamiento de correo Zimbra o el MTA crean nuevos archivos durante la entrega de mensajes, surge la necesidad de escribir en el disco los cambios realizados en las carpetas correspondientes. Por eso, incluso si el archivo ya ha sido escrito en el disco mediante fsync, el registro de su adición en el directorio puede no llegar a escribirse en el disco y, como resultado, puede perderse debido a una falla súbita del servidor. Gracias al uso de dirsync se pueden evitar estos problemas.
2. Optimización en una infraestructura Zimbra en funcionamiento
A menudo ocurre que después de varios años de operación, el número de usuarios de Zimbra aumenta significativamente y el servicio se vuelve cada día menos y menos receptivo. La solución a esta situación es evidente: solo hay que agregar nuevos servidores a la infraestructura para que el servicio vuelva a funcionar tan rápido como antes. Sin embargo, no siempre existe la posibilidad de agregar inmediatamente nuevos servidores a la infraestructura para mejorar su rendimiento. A menudo, los gerentes de TI tienen que pasar mucho tiempo coordinando la adquisición servidores con contabilidad o el departamento de seguridad; además, a menudo los proveedores decepcionan, quienes pueden entregar un nuevo servidor tarde o incluso entregar algo que no se necesita.
Por supuesto, lo mejor es construir su infraestructura Zimbra con un margen, para siempre tener un excedente para su expansión y no depender de nadie, pero si ya se cometió un error, el gerente de TI solo puede suavizar al máximo sus consecuencias. Por ejemplo, el gerente de TI puede lograr un pequeño aumento en el rendimiento al utilizar la desactivación temporal de los servicios del sistema Linux que, en funcionamiento, acceden regularmente a los discos duros y, como resultado, pueden afectar negativamente la velocidad de Zimbra. Así, se pueden desactivar temporalmente:
autofs, netfs — Servicios de detección de sistemas de archivos remotos
cups — Servicio de impresión
xinetd, vsftpd — Servicios integrados de *NIX que probablemente no necesitará
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Servicios de llamada a procedimientos remotos que generalmente se utilizan en combinación con sistemas de archivos de red
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Duplicados de las utilidades principales que forman parte de Zimbra Collaboration Suite
slocate/updatedb — Dado que Zimbra almacena cada mensaje en un archivo separado, la ejecución diaria del servicio updatedb puede generar problemas, por lo que se puede hacer manualmente durante los momentos de menor carga en los servidores.
El ahorro de recursos del sistema al desactivar estos servicios no será muy significativo, pero incluso eso puede ser de gran utilidad en circunstancias cercanas a situaciones de emergencia. Después de que se agregue un nuevo servidor a la infraestructura de Zimbra, se recomienda volver a habilitar los servicios que se desactivaron anteriormente.
También se puede optimizar el funcionamiento de Zimbra al trasladar el servicio syslog a un servidor separado, para que durante su funcionamiento no sobrecargue los discos duros de los almacenes de correo. Para estos fines, prácticamente cualquier computadora servirá, incluso una económica como una Raspberry Pi.
Fuente: habr.com
