Roberto Ferrero

Distributed Power Management es el nombre de la tecnología que incluye VMware ESX y que permite “recolocar” las máquinas virtuales entre nuestros host físicos consiguiendo la mayor eficiencia energética. Esta tecnología permite mantener apagados aquellos host que no son necesarios cuando la carga de trabajo de las máquinas virtuales se reduce ( por ejemplo por la noche o durante los fines de semana ).

Este vídeo que he encontrado en el blog de Josep Ros lo explica muy bien:

Acabo de realizar un pedido del libro “El Manifiesto Cluetrain” después de enterarme a través de Microsiervos de que en e-Deusto.com lo ofrecen a 0,01€ (más gastos de envío) para celebrar los 10 años de su publicación.

Parece ser que este libro es casi de lectura obligada para quien tenga proyectos en Internet y mantiene su vigencia después de tantos años desde su publicación. Después de leer “El arte de Empezar” de Guy Kawasaki tal vez ésta sea otra lectura recomendada.

Los log de transacciones son ficheros de 5MB que Exchange Server almacena como paso previo a la gestión de los mensajes en la base de datos. Exchange Server 2003 permite gestionar los logs de transacciones de forma que se sobrescriban periódicamente, es el conocido como “loggin circular“. Este tipo de gestión de los logs ocupa menos espacio y teóricamente hace que el servidor Exchange se ejecute de una forma más rápida, pero por el contrario impide la recuperación de los mensajes de correo a medio plazo (días, semanas) en caso de error en la base de datos.

Lo ideal es no activar el loggin circular y planificar una estrategia de borrado de los logs de transacciones de forma periódica. Los logs de transacciones no se deben borrar ni mover de forma manual, esto ocasionaría la pérdida de datos y/o la corrupción de la base de datos de Exchange Server.

Microsoft, a través de la herramienta ntbackup nos permite realizar el mantenimiento de los logs de transacciones de Exchange Server. Cuando configuramos una tarea de backup de Exchange con Ntbackup (con Exchange arrancado en todo momento), al finalizar la copia de las bases de datos el propio Ntbackup se encarga de ir borrando los logs de transacciones y de ir aplicando consistencia a la base de datos.

¿Son importantes los logs de transacciones?

Si, son una pieza fundamental para Exchange. Además de dotar de consistencia a la base de datos agiliza el tratamiento de la información al fraccionarla en pequeños archivos de 5MB fácilmente gestionables por el sistema. Además, en caso de fallo en la base de datos (por ejemplo, por un corte de corriente) podremos recuperar el estado de la base de datos.

Cuando la base de datos está dañada y no podemos montar los almacenes de información el comando eseutil nos ayudará con la recuperación. Para trabajar con eseutil tenemos que marcar la base de datos de Exchange con permiso de actualización. Esto se hace desde la consola de Exchange, en los almacenes de datos/propiedades/base de datos/permitir la actualización de los ficheros de base de datos.

En primer lugar ejecutaremos eseutil /mh “ruta del fichero de base de datos Exchange” para que nos diga el estado de la base de datos. Normalmente, después de una caída del sistema la base de datos se encontrará en estado “dirty shutdown”.

A continuación ejecutaremos eseutil /p “ruta del fichero de base de datos Exchange” para que, a partir del log de transacciones se reconstruya la base de datos y pase a estado “clean shutdown”.

De este modo podremos montar los almacenes de información y Exchange volverá a funcionar correctamente.

Uno de los principales quebraderos de cabeza que he encontrado al instalar ESXi en los servidores HP Proliant es que la consola de administración no era capaz de detectar los problemas de hardware que pudieran producirse en la máquina host a nivel de controladora de discos o discos duros ( smart array ). Era muy frustrante encontrar que el monitor del sistema era capaz de indicarte la temperatura del servidor en todos los sensores, el estado y velocidad de los ventiladores, etc… pero si un disco duro “cascaba” el sistema no se enteraba y seguía funcionando con el RAID degradado sin notificar la incidencia.

Parece ser que HP ya está trabajando en unos agentes para ESXi que notifiquen el estado de las Smart Array, hasta ese momento deberemos tener los ojos bien puestos en los displays luminosos de nuestros servidores. La otra solución implica prescindir de la versión gratuita del hipervisor de VMware y adentrarnos en la versión de pago ESX, mucho más completa (nos permite jugar con la consola linux del sistema) y hacernos con los agentes HP Insight Manager para ESX.

Con este paquete instalado en nuestro ESX podremos comunicar con HP Insight Manager a través de traps SNMP que nos notificará las incidencias de hardware en nuestros equipos tales como daños en una fuente de alimentación, tarjeta de red, ventiladores y por supuesto discos duros. Insight Manager nos enviará un e-mail o un aviso por SMS si así lo configuramos cada vez que se produzca una de estas incidencias y nos notificará si alquien se ha puesto ya a solucionarla o si la incidencia ya ha sido resuelta.