Arquitecturas en Alfresco

alfresco_repository_architecture_diagram1_coloredCon este post me gustaría hacer una pequeña introducción a los diferentes diseños de arquitecturas que podemos llevar a cabo con Alfresco dependiendo del uso, usuarios, rendimiento, concurrencia y almacenamiento requerido.

Alfresco es un producto que acaba de cumplir 5 años, tras pasar por varias etapas con versiones más o menos estables, podemos decir, que desde hace un tiempo contamos con un producto confiable, robusto, estable y escalable. Preparado para pequeños proyectos con decenas de usuarios y unos cuantos miles de contenidos y para entornos con miles de usuarios y millones de contenidos. Y cada vez nos encontramos más y más instalaciones consolidadas.

Algo muy común que veo en las implantaciones de Alfresco, salvo casos muy concretos, es que muchas veces se instala la aplicación, base de datos y content store en la misma máquina, tanto para un piloto, desarrollo, test o producción. Para un piloto y desarrollo o incluso test es válido, o para producción si los requisitos no son demasiado exigentes. Teniendo todas las capas de la aplicación en la misma máquina (física o virtual), cuando el entorno pasa a producción y empieza a crecer considerablemente en número de usuarios y contenidos se suele experimentar un problema de rendimiento. Tiempos de respuesta elevados en el acceso, reglas, workflows, etc.

Vamos a ver, de forma resumida, algunos conceptos a tener en cuenta a la hora de hacer despliegues de Alfresco que nos permita crecer tanto horizontal como verticalmente.

Antes de seguir, para entender bien todo esto, veamos los componentes de la infraestructura que debemos conocer y diferenciar para diseñar una correcta arquitectura:

  • Repositorio Alfresco: hablamos de la aplicación principal de Alfresco (alfresco.war) que gestiona todo el repositorio (contenidos) y el core, así como las diferentes interfaces de acceso como CIFS, FTP, WebServices, Alfresco Explorer y muchas otras más.
  • Alfresco Share: aplicación (share.war) que es interfaz web de Alfresco y nos permite acceder al repositorio una interfaz ligera y potente para gestión de contenidos y colaboración. Mediante Share podemos activar sitios favoritos para su posterior acceso por IMAP. Este componente puede estar en una capa diferente al repositorio y escalar de forma separada tanto vertical como horizontalmente.
  • Aplicaciones de terceros: nos referimos a las aplicaciones que necesita Alfresco para funcionar al 100% como OpenOffice, ImageMagik y Pdftools. Recuerda que desde la versión 3.2, OpenOffice funciona como un subsistema y podemos instalarlo en una máquina diferente al repositorio.
  • Base de datos: será el motor de base de datos a usar por el software, como ya sabemos, pueden ser de varios tipos y “sabores” como MySQL, MS SQL Server, PostgreSQL, Oracle, etc. Alfresco almacena en la base de datos toda la información (metadatos, reglas, permisos… todo) excepto los índices y los ficheros físicos. Dicho esto, podemos adivinar que el uso de base de datos que hace Alfresco es importante.
  • Almacén de contenido o content store: será el sistema de ficheros, directorio o directorios del sistema operativo donde Alfresco deposita los ficheros que maneja, los ordena por diferentes niveles de directorios (año/mes/dia/hora/minuto). Por defecto se almacena dentro de alf_data/contentstore. En contentstore.deleted tendremos los ficheros borrados, tras 15 días de ser eliminados, y audit.contentstore que será la información extra que genera la aplicación si activamos las auditorías.
  • Índices: hablamos de la información que genera el motor de indexación y búsqueda que incorpora Alfresco, Lucene. Esta información se almacena en un directorio del sistema operativo llamado lucene-indexes dentro de alf_data por defecto. Diariamente a las 3 AM se genera un backup automático de los índices en el directorio alf_data/lucene-indexes.backup. Como decía, ahí se almacenan todos los índices de los contenidos del repositorio y tendrá un puntero a los mismos desde la base de datos. Podemos imaginar que cuanto más rápido sea el disco o discos donde residan los índices, más rápido funcionará nuestro sistema a nivel general.

Dicho lo anterior y conociendo el funcionamiento de Alfresco, podemos averiguar donde tenemos los cuellos de botella en las implantaciones.

Por ejemplo, tener el content store y la base de datos en la misma máquina sobre el mismo disco duro supone que cada vez que subimos un fichero o realizamos alguna acción con el mismo se escribe simultáneamente en base de datos y content store; moraleja: el disco duro debe escribir al mismo tiempo en varios sitios diferentes = sistema lento. Claro está, esto nos pasará si estamos haciendo un uso intensivo del sistema.

Todos esos componentes los podemos implementar de diferentes formas, dependiendo de la ubicación de cada componente hablaremos de diferentes capas o niveles.

  • Una capa única: es el despliegue por defecto que podemos realizar con los instaladores bundle de Alfresco. Todos los elementos de la infraestructura los tendríamos en la misma máquina. ¿Para qué es válido este tipo de despliegue? Para pruebas piloto, desarrollos o incluso pequeñas instalaciones orientadas a departamentos. Por supuesto, este tipo de despliegues no se recomiendan para sistemas críticos o con grandes expectativas por razones obvias de escalabilidad y rendimiento.
  • Dos capas: en este despliegue podemos empezar a usar una arquitectura realmente empresarial y escalable. Aquí separaremos en capas independientes:

Capa de contenidos: repositorio, Share, índices y aplicaciones de terceros que necesita Alfresco.
Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.

Esta arquitectura permite más escalabilidad y rendimiento, configuración simple y la gestión del crecimiento del contenido es transparente para la aplicación. Si añadimos que en este caso los índices estarán en la capa de contenidos tendremos como resultado un entorno que imprima un rendimiento considerable para entornos de tipo medio que incluso pueden ponerse en alta disponibilidad, pero ojo, si crecen mucho los contenidos también crecerán los índices y en ese casos podríamos necesitar hacer cambios en la infraestructura o en la configuración de los servidores (asignar más almacenamiento, etc.).

  • Tres capas distribuidas: en versiones 3.X podemos separar en varias capas componentes de la capa web de Alfresco, es decir, separar Alfresco Share del repositorio. Este caso será el más escalable y nos permitirá implementar entornos con una gran carga y altas exigencias en cuanto a rendimiento. Esta arquitectura añade a la de dos capas la distribución de la capa web. Las capas serían las siguientes:

Capa web: donde tendríamos Alfresco Share o/y otras aplicaciones frontales que podamos tener para trabajar con Alfresco (Liferay, Joomla, Drupal, etc.) u otras hechas desde cero y opcionalmente un servidor web que proteja al servidor de aplicaciones vía mod_proxy, Varnish o similares.

Capa de contenidos: repositorio, índices y aplicaciones de terceros que necesita Alfresco.

Capa de almacenamiento: Base de datos en una máquina dedicada a la que accede la aplicación vía JDBC y content store en una SAN o NAS.

Podríamos añadir una capa extra entre la capa web y capa de contenidos que nos permita hacer caché, control de acceso o balanceo de carga. Como vemos, esta es la mejor forma de ofrecer el máximo rendimiento tanto de lectura como de escritura, que además podemos configurar en alta disponibilidad en todas las capas. Este tipo de arquitectura no es recomendada para pequeños despliegues departamentales y necesita un alto grado de conocimiento de Alfresco, sistemas y redes en general. Salvo uso de software específico, no se recomienda separar cada una de las capas de forma geográfica ya que una alta latencia entre capas puede influir negativamente en el rendimiento.

Alfresco Hack: cómo sacar un informe rápido de los contenidos del repositorio

Ya lo vi hace tiempo en Think Alfresco y sabía que algún día lo iba a necesitar, ahora quiero compartirlo con vosotros. Sabemos lo que ocupa el repositorio, sería tan fácil como hacer un du -sh contentstore, pero ¿qué tipo de archivos almacena ese repositorio y cuantos de cada tipo? Saber ese dato es importante al hacer migraciones, optimizar Lucene, etc. Es tan fácil como ejecutar el siguiente comando desde el directorio superior al contentstore de turno:

$ find ./contentstore -type f -exec file -inb {} \;| sort |uniq -c|sort -nr

Este comando nos dará como resultado algo parecido a lo siguiente:

    378 application/msword
    147 application/pdf
     72 text/plain; charset=us-ascii
     58 text/x-c++; charset=iso-8859-1
     12 text/plain; charset=utf-8
      8 text/html
      2 application/x-zip
      2 text/plain; charset=iso-8859-1
      2 image/jpeg
      2 application/x-empty
      2 text/x-c; charset=utf-8
      1 text/x-c++; charset=utf-8
      1 image/png

Fácil ¿no? Claro que también se puede hacer con un JavaScript y ejecutarlo como acción pero pienso que así es más rápido, además es el “Sys Admin way”.

Archiving en Alfresco 3.2

image_archivingActualización 25/Feb/2010: ver demo-config-files para configuración más cómoda incluso desde Share, reglas y demás (doc calentito que me han enviado desde Alfresco, Gracias Paul!!).

¿Que es el archiving/archivado? Un archivo en gestión documental es una colección de documentos históricos, así como el lugar donde se encuentran. Pues bien, vamos a ver como se configura Alfresco para poder almacenar los contenidos en diferentes sistemas de ficheros, particiones o filesystem (como quieras llamarlo). Cada filesystem puede ser de diferente naturaleza, es decir, los contenidos que se trabajan actualmente deberán estar en los discos más rápidos (discos locales o en una SAN) y los contenidos históricos o de acceso poco frecuente pero debemos mantener, podemos almacenarlos en discos más lentos/baratos o por ejemplo en una NAS.

Todo esto se consigue en Alfresco gracias al Content Store Selector. El Content Store Selector ofrece un mecanismo de control que relaciona el contenido lógico con un fichero físico y su ubicación. Usando el aspecto cm:storeSelector y asignándole una propiedad cm:storeName podemos mover el contenido de un Store a otro de forma totalmente transparente tanto para el usuario como para la aplicación a la hora de mostrar los contenidos, claro que previamente tenemos que definirlos. Esto nos permitirá declarar políticas para controlar la capa de almacenamiento y el uso que de ella hace Alfresco en base a regales de negocio.

Veamos como se configura en base al siguiente escenario:

El repositorio y los ficheros de uso diario, los más usados, los tenemos en /opt/alfresco/alf_data/contentstore, supongamos que ese filesystem corresponde a los discos más rápidos. También tenemos un disco local más lento montado en /opt/alfresco/alf_data/storeA, e incluso podemos tener un filesystem de tipo NAS para los datos que ya no usamos pero necesitamos almacenar montado en /opt/alfresco/alf_data/storeB.

¿Cómo lo configuramos?

Creamos un fichero llamado “sample-content-store-selector-context.xml” en shared/classes/alfresco/extension con el siguiente contenido, lee los comentarios para entender la configuración:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http:// www.springframework.org/dtd/spring-beans.dtd'>
<!-- Define the new file stores -->
<beans>
        <bean id="firstSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
                <constructor-arg>
                        <value>${dir.root}/storeA</value>
                </constructor-arg>
        </bean>
        <bean id="secondSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
                <constructor-arg>
                        <value>${dir.root}/storeB</value>
                </constructor-arg>
        </bean>
<!-- Declare the mapping between store names and store instances -->
        <bean id="storeSelectorContentStore" parent="storeSelectorContentStoreBase">
                <property name="defaultStoreName">
                        <value>default</value>
                </property>
                <property name="storesByName">
                        <map>
                                <entry key="default">
                                        <ref bean="fileContentStore" />
                                </entry>
                                <entry key="storeA">
                                        <ref bean="firstSharedFileContentStore" />
                                </entry>
                                <entry key="storeB">
                                        <ref bean="secondSharedFileContentStore" />
                                </entry>
                        </map>
                </property>
        </bean>
<!-- Point the ContentService to the 'selector' store -->
        <bean id="contentService" parent="baseContentService">
                <property name="store">
                        <ref bean="storeSelectorContentStore" />
                </property>
        </bean>
<!-- Add the other stores to the list of stores for cleaning -->
        <bean id="eagerContentStoreCleaner" class="org.alfresco.repo.content.cleanup.EagerContentStoreCleaner" init-method="init">
                <property name="eagerOrphanCleanup" >
                        <value>${system.content.eagerOrphanCleanup}</value>
                </property>
                <property name="stores" >
                        <list>
                                <ref bean="fileContentStore" />
                                <ref bean="firstSharedFileContentStore" />
                                <ref bean="secondSharedFileContentStore" />
                        </list>
                </property>
                <property name="listeners" >
                        <ref bean="deletedContentBackupListeners" />
                </property>
        </bean>
</beans>

Si te fijas en los dos primeros beans, los valores que se especifican están relacionados con la ubicación de los dos Stores adicionales que estamos creando, en esta caso, relativos a ${dir.root} que es un atributo declarado en alfresco-global.properties. Si nuestros nuevos filesystems no están dentro de dir.root podemos poner la ruta absoluta, por ejemplo <value>/mnt/storeA</value>.

Para poder usar los nuevos contentStores debemos configurar el web-client (Alfresco Explorer) y declararlo como aspecto. Editamos web-client-config-custom.xml y añadimos las siguientes lineas:

<!-- Configuring in the cm:storeSelector aspect -->
        <config evaluator="aspect-name" condition="cm:storeSelector">
                <property-sheet>
                        <show-property name="cm:storeName" />
                </property-sheet>
        </config>
        <config evaluator="string-compare" condition="Action Wizards">
                <aspects>
                        <aspect name="cm:storeSelector"/>
                </aspects>
        </config>

Hecho lo anterior ya podemos reiniciar el servidor de aplicaciones para que los cambios surtan efecto.

Ahora vamos a ver como empezar a usarlo. Recuerda que el aspecto, aunque pueden aplicarlo todos los usuarios, sólo el usuario administrador podrá especificar el store correspondiente y sólo es aplicable a contenidos (no a espacios). En este ejemplo veremos como hacerlo de forma manual, para sistemas en producción deberíamos hacer un script que modifique dicho metadato automáticamente en base a las necesidades que tengamos, por ejemplo los que estén dentro de un espacio concreto, los que tengan más de N años en el repositorio, etc. El procedimiento sería el siguiente:

  • Localizamos el fichero con el que queremos probar (lo moveremos al storeA).
  • Vamos a “Ver detalles” de dicho fichero y pinchamos en “Ejecutar una acción”
  • Seleccionamos “Agregar aspecto al contenido” -> “ContentStore Selector” -> Aceptar -> Finalizar
  • En las propiedades del fichero ya veremos un nuevo metadato llamado “Store Name”.
    propiedades
    Editamos las propiedades y en Store Name especificamos: storeA
    storea
    Cuando pinchemos en Aceptar, automáticamente el contenido se moverá de forma transparente al filesystem alf_data/storeA/2010/2/17/22/50/4365380f-daf1-494c-b79d-db11480cb171.bin correspondiente, en mi ejemplo, a un fichero pdf.

¿Interesante no?

ACTUALIZACIÓN: para automatizar la clasificación por “Stores” podemos hacer un script en Java Script llamado, por ejemplo, action_storeA.js o B según el sitio donde queramos colocar los ficheros, con el contenido:

document.properties["cm:storeName"]="storeA";
document.save();

Lo guardamos y subimos a Diccionario de datos -> Scripts. Hecho esto podemos ejecutar una acción sobre el fichero de turno y seleccionamos “Ejecutar un script” -> Seleccionamos nuestro script “action_storeA.js” y listo. También podemos incluirlo en una regla y hacer el proceso de forma automática, cuando entren los ficheros a un espacio concreto, o incluso clasificar si son vídeos, imágenes, pdf, cad, etc.

Nagios plugin for Alfresco released!!

I’ve just released the version 1.0 of the new Nagios Plugin for Alfresco, which can be used with Icinga too. I have employed Enterprise JMX capabilities to extract and check information from Alfresco. It has been tested in Alfresco Enterprise 3.2.

Nagios is an Open Source network monitoring tool that can be configured to monitor services on a network. Icinga is a new fork of Nagios. They are both used extensively in enterprise environments.

You can download it here http://forge.alfresco.com/projects/nagios4alfresco/

nagios_plugin_for_alfresco_screenshot

UPDATED! Version 1.1 released. Added “performance data” support. Now you can graph all checks with pnp4nagios.

It checks the following services:

  • PING
  • SSH
  • Alfresco Application Server
  • Alfresco Web Server – proxy
  • Alfresco VTI Share Point – Jetty
  • Alfresco FTP Server
  • Alfresco CIFS Server – NetBIOS
  • Alfresco CIFS Server – SMB
  • Alfresco RMI – JMX
  • Alfresco IMAP Server
  • Alfresco SMTP Server – incoming
  • Alfresco – Heap Memory Usage –
  • Alfresco – System Load Average
  • Alfresco – Thread Count
  • Alfresco – Number of Total Users
  • Alfresco – Number of Total Groups
  • Alfresco – Connection Pool
  • Alfresco – ContentStore Size
  • Alfresco – ContentStore Deleted Size
  • Alfresco – Audit Store Size
  • Alfresco – Hibernate Connect Count
  • Alfresco – Lucene Indexes SpacesStore Used
  • Alfresco – Lucene Indexes SpacesStore Num
  • Alfresco – Repo Sessions
  • Alfresco – Repo Users Connected
  • Alfresco – Total Memory Used
  • Alfresco – Free Memory
  • Alfresco – Max Memory
  • Alfresco – Cache Size

You can find it at Nagios Exchange or Monitoring Exchange

Mejorando la velocidad de Alfresco con Varnish

En la charla que di en el Meetup de Alfresco en Madrid, comenté, entre otras cosas, cómo acelerar Alfresco, en este punto se hablaba de Varnish.

Varnish

Varnish es un proxy caché, acelerador web y balanceador de servidores web que funciona sobre Linux, Mac y *BSD, básicamente usa opciones del kernel y un almacén de la caché para acelerar las peticiones de páginas, es decir, un sustituto a mod_proxy, mod_proxy_balancer o mod_proxy_ajp.

En este artículo os dejo un manual sobre como implementar Varnish por delante de Alfresco para acelerar la experiencia del usuario y funcionamiento en general de la aplicación, tanto Alfresco Explorer como Alfresco Share u otras aplicaciones que desarrollemos sobre Alfresco, reduce los tiempos de conexión de forma considerable y libera de algunas peticiones al servidor de aplicaciones.

En este caso explicaré como instalar y configurar Varnish 2.0.5 en CentOS 5 mediante un RPM aunque también se puede compilar, todo en menos de 5 minutos. La lectura de esta web me ha ayudado para escribir el artículo.

Read More

Adios Nagios, hola Icinga.

nagiosLos que me conocen saben que soy un enamorado de Nagios, lo conozco desde hace años, desde que se llamaba Netsaint, lo he montado siempre que he podido para demostrar que no tiene nada que envidiar a software propietario y caro que se ve por las grandes compañías de todo el mundo. Me consta que sigue montado en sitios por los que he pasado, no diré más pistas ;).

En los últimos años, a Nagios le han salido muchos competidores en el mundo del Open Source: Zenoss, Hyperic, Pandora, OpenNMS, Zabbix, Centreon y Groundwork, estos dos últimos basados en Nagios. Lo cierto es que tenía la sensación de que Nagios estaba siendo adelantado por sus competidores. El problema principal es que, a pesar de la gran comunidad que existe en torno a Nagios, el core sólo lo desarrolla una persona en USA y parece ser que era un cuello de botella para otros desarrolladores y los usuarios finales. Esto no ha caído en saco roto y la comunidad se ha puesto manos a la obra para que el proyecto pueda seguir creciendo como se merece. Así que la gente de nagios-portal.org, NagVis, NagTrap, PNP4Nagios, icingacheck_multi, NagiosGrapher y NETWAYS han realizado un fork llamado Icinga, que significa en Zulú “explorar o examinar”.

Es la grandeza del Software Libre, y gracias a la libretad de adaptar, modificar, publicar podemos tener noticias como esta. Como ellos mismos indican en su FAQ ya ha ocurrido esto otras veces, por ejemplo con Mambo->Joomla o con XFree86->X.org.

Todo esto está muy bien, pero ¿ganará la comunidad con este cambio? A tenor de lo que la gente de Icinga promete, estoy seguro que si, y mucho. Veamos:

  • Soportará características y plugins de Nagios y será facil migrar desde Nagios.
  • Soportará extensiones y desarrollos e integraciones gracias a una API.
  • Tendrá una nueva interfaz web basada en PHP.
  • Tendrá como addons: PNP, NagVis, Grapher V2 y NagTrap.
  • Nueva interfaz NDO con soporte para ser almacenado en ficheros o en base de datos permitiendo el acceso a esos datos desde la API con PHP o desde WebServices.
  • ReportDesigner para realizar informes personalizados y se podrán configurar envíos automáticos de informes cada cierto tiempo.
  • También se contemplan mejoras para grandes instalaciones.

Por ahora toca esperar, parece que la primera versión de Icinga saldrá el próximo 20 de Mayo. Habrá que estar atento, yo ya he puesto una nota en mi calendario.

Proxmox VE: una alternativa libre a la gestión de la virtualización

logo_pveYa tengo muchas máquinas en casa y poco tiempo para dedicarle al hardware y el cacharreo por lo que hace ya un mes que adquirí en Hetzner un nuevo servidor para mi laboratorio, Hetzner es ISP alemán y sudafricano que permite alquilar máquinas físicas a un precio aceptable, ancho de banda de sobra y con un servicio magnífico comprobado a lo largo de más de un año con otros servidores que uso a titulo profesional. No conozco muchos ISP de la magnitud de Hetzner para poder haceros comparativas en cuanto a servicios/precio, pero son rápidos y en caso de problemas (tanto de sistema operativo, de red como físicos) están ahí para ayudar con un servicio 24×7 excelente incluido en el precio. La única pega es que el panel de control que ofrecen a los clientes está en alemán pero es sencillo y con Google Translator en unos minutos lo tenía dominado.

Hecha la “cuñita” publicitaria sin ánimo de nada a Hezner (cuando algo funciona también hay que decirlo). Paso a contaros qué infraestructura he configurado para gestionar este servidor.

Actualmente, gracias al furor “Cloud” y teniendo en cuenta que la virtualización forma parte del paradigma aunque no obligatoriamente, he estado mirando diferentes fórmulas o aplicaciones para gestión de la virtualización de forma sencilla, cómoda y rápida, por supuesto en Software Libre. Conocía desde hace tiempo Enomalism o actualmente AbiCloud* que es muy interesante y otras muchas soluciones web que permiten gestionar máquinas virtuales y aprovisionarlas, pero a la hora de la verdad la mayoría de estas aplicaciones de gestión de la virtualización no rinden como se espera, me refiero por ejemplo a la clusterización, migración de máquinas virtuales entre físicas y acciones afines o en algunos casos hay que pasar por caja para conseguir funcionalidades extra que generalmente no son Open Source. Los amigos de la Fundación I+D del Software Libre llevan usando Proxmox VE unos cuantos meses. Así que tras documentarme me lancé a la aventura y solicité a mi ISP que me montaran una máquina con Proxmox VE 1.1.

*AbiCloud no es sólo un gestor de máquinas virtuales sino que también puede gestionar máquinas físicas de una nube.

Proxmox VE es una plataforma de virtualización de código libre (GPLv2) realizada por la compañía alemana Proxmox Server Solutions GmbH, especializados en appliances virtuales empresariales.

¿Por qué usar Proxmox VE?

  • Porque hace gala del principio KISS, es simple y funciona.
  • Porque permite desplegar máquinas virtuales en cuestión de segundos ya sea desde las plantillas disponibles o desde 0.
  • Porque permite crear contenedores gracias a OpenVZ, permite virtualizar y paravirtualizar gracias a KVM, por lo que no hecho de menos ni VMware ni Xen.
  • Porque permite descargar plantillas con aplicaciones instaladas y configuradas listas para usar desde aquí.
  • Porque se pueden tener varios servidores físicos en cluster y migrar en vivo máquinas virtuales de un servidor a otro de forma rápida y sencilla. Permitiéndo aprovechar al máximo el hardware y alta disponibilidad de mis sistemas operativos virtualizados.
  • Porque permite hacer backup a otros discos de forma totalmente desatendida y controlar gráficamente el estado y consumo de cada una de las máquinas virtuales.
  • Porque puedes acceder por VNC a cualquiera de las máquinas desplegadas aún sin red configurada.
  • Porque se descarga en ISO, basada en Debian y se instala directamente en el servidor anfitrión, una vez instalado todo lo demás se hace vía web.

800px-screen-startpage-with-cluster

Y por muchas razones más. Pero no es oro todo lo que reluce, he echado de menos más información sobre el consumo de red y recursos. Aunque se muestran datos básicos, no hay acumulados y gráficas históricas que son importantes para adelantarse a los problemas. Realmente con ntop y Cacti se soluciona este problema. En cuanto a documentación y comunidad no está mal, ya que tanto OpenVZ como KVM además del propio ProxmoxVE cuentan con un importante número de colaboradores y manuales.

Para instalarlo mira este fantástico manual que nos ofrecen los amigos de Howtoforge.

Lo tengo claro, para montar un entorno corporativo o personal de virtualización ya tengo una solución Open Source que cubre mis necesidades: Proxmox VE.

Monitorización del sistema con el comando “sar”

[Otro trocito extraído de mi libro] La monitorización del sistema es una tarea importante para cualquier técnico o administrador de sistemas, vamos a ver unos comandos muy útiles para saber el estado de la máquina en todo momento. Para ello instalaremos el paquete sysstat que contiene comandos como sar e iostat que nos permiten monitorizar el uso de discos, red y otros procesos de entrada y salida:

[root@amanita ~]# yum -y install sysstat

El comando sar almacena los datos en ficheros dentro del directorio /var/log/sa/.

La ejecución de sar es bien sencilla, aquí vemos un ejemplo:

Read More