Estudio e implementación de una plataforma de explotación de un gestor de contenido multientidad, para los portales web municipales de la provincia de Valencia
Full text
1 ESTUDIO E IMPLANTACIÓN DE UNA PLATAFORMA DE EXPLOTACIÓN DE UN GESTOR DE CONTENIDO MULTIENTIDAD, PARA LOS PORTALES WEB MUNICIPALES DE LA PROVINCIA DE VALENCIA PROYECTO FIN DE CARRERA Ingeniería Informática CURSO 2010-2011 ALEJANDRO MIRAGALL ARNAL
2
3 ÍNDICE DE CONTENIDO ÍNDICEDECONTENIDO........................................................................ 3 I.CONTEXTODELPROYECTO................................................................. 7 I.1PROYECTOPORTALESMUNICIPALES................................................................7 I.2OBJETIVOS................................................................................................9 I.3GESTORESDECONTENIDOYDRUPAL.............................................................10 I.3.1GESTORESDECONTENIDO....................................................................................... 11 I.3.2INTRODUCCIÓNADRUPAL ...................................................................................... 13 I.3.3CARACTERÍSTICASDEDRUPAL.................................................................................. 14 CaracterísticasGenerales............................................................................................... 14 Gestióndeusuarios........................................................................................................ 15 Gestióndecontenido..................................................................................................... 15 Blogging.......................................................................................................................... 16 Plataforma...................................................................................................................... 17 AdministraciónyAnálisis ............................................................................................... 17 Característicasdecomunidad........................................................................................ 18 Rendimientoyescalabilidad .......................................................................................... 18 I.3.4ESTRUCTURADEDRUPAL ........................................................................................ 18 Core(Núcleo) ................................................................................................................. 18 Módulos ......................................................................................................................... 19 Temas............................................................................................................................. 20 II.SISTEMADEEXPLOTACIÓNGESTORDECONTENIDOSMULTIENTIDAD ....... 22 II.1MULTIENTIDAD.......................................................................................22 II.2MULTIENTIDADENDRUPAL .......................................................................24 II.2.1INTRODUCCIÓN.................................................................................................... 24 II.2.2RESUMENDEALTERNATIVAS ................................................................................... 25 II.2.3MULTIENTIDADNATIVAENDRUPAL .......................................................................... 27 Basesdedatosdistintas................................................................................................. 30 Basededatoscompartida.............................................................................................. 32 Basededatosmixta ....................................................................................................... 36 II.3SISTEMADEEXPLOTACIÓN .........................................................................38 II.4AEGIR...................................................................................................38
4 II.4.1UNPOCODEHISTORIA........................................................................................... 40 II.4.2OBJETIVOSDEAEGIR............................................................................................. 40 II.4.3ESTRUCTURADEAEGIR.......................................................................................... 41 Front‐end ....................................................................................................................... 42 Back‐end......................................................................................................................... 44 II.5.INSTALACIÓN,USO,YAMPLIACIÓNDELASFUNCIONESDEEXPLOTACIÓN .............46 II.5.1INSTALACIÓN....................................................................................................... 46 Descargaralgunospaquetesnecesarios........................................................................ 46 Crearunnuevousuario.................................................................................................. 47 ConfigurarnuestroservidorApache.............................................................................. 47 ConfigurarnuestraBasedeDatos.................................................................................. 48 DescargarficherosdeAegiryejecutarscript ................................................................ 48 Instalaciónenlaweb...................................................................................................... 49 II.5.2GUÍADEUSO ...................................................................................................... 50 Crearnuevaplataforma ................................................................................................. 50 Crearnuevositio ............................................................................................................ 53 Migracióndeunsitio...................................................................................................... 56 Hacerbackupsdelossitios ............................................................................................ 61 Validarunsitio ............................................................................................................... 62 Clonarunsitio ................................................................................................................ 64 III.VALIDACIÓNDELAPLATAFORMA.RENDIMIENTO............................... 68 III.1.OBJETIVOS ...........................................................................................68 III.2.DESCRIPCIÓNDELMONTAJEDEPRUEBA ......................................................68 III.2.1HARDWARE........................................................................................................ 68 III.2.2LAREDDEPRUEBAS ............................................................................................. 74 III.2.3PLATAFORMADEVIRTUALIZACIÓN–VMWAREVSPHERE .............................................. 75 III.2.4SOFTWARESERVIDOR........................................................................................... 77 SistemaOperativo‐LinuxCentOS5.3 ........................................................................... 77 Apache2.2.3................................................................................................................... 77 MySQL5.0.77 ................................................................................................................. 78 PHP5.2.10...................................................................................................................... 78 eAccelerator2.2.0.......................................................................................................... 79 MódulosBoost6.x‐1.18yAuthcaché ............................................................................. 79 III.2.5WEBDEPRUEBAS ................................................................................................ 79 III.2.6SOFTWARECLIENTE: ............................................................................................ 81 III.3DESCRIPCIÓNDELAPRUEBA......................................................................81
5 III.3.1MECANISMOSDEACELERACIÓNDELGESTORDECONTENIDOS ....................................... 84 CachéDrupal .................................................................................................................. 86 AceleradordePHP–Eaccelerator ................................................................................. 87 MóduloBoost................................................................................................................. 90 MóduloAuthcaché:........................................................................................................ 92 III.4RESULTADOSDELAPRUEBA.......................................................................93 III.5.CONCLUSIONES .....................................................................................95 IV.CONCLUSIONES........................................................................... 98 V.BIBLIOGRAFÍA............................................................................ 100 VI.ANEXOS .................................................................................. 102 VI.1RESULTADODELASPRUEBASDERENDIMIENTOALCOMPLETO.........................102 VI.1.1CABECERACOMÚNATODASLASPRUEBAS.............................................................. 102 VI.1.2BOOST+EACCELERATOR..................................................................................... 102 VI.1.3EACCELERATOR+CACHÉDRUPAL ......................................................................... 103 VI.1.4CACHÉDRUPAL................................................................................................. 104 VI.1.5SINCACHÉDRUPAL............................................................................................ 105 VI.1.6SINCACHÉDRUPAL+EACCELERATOR .................................................................... 106 VI.2FICHERODECONFIGURACIÓNDEMYSQL(MY.CNF) .....................................107 VI.3FICHERODECONFIGURACIÓNDEAPACHE(/ETC/HTTPD/CONF/HTTPD.CONF).....114 VIIAPÉNDICE................................................................................ 116 VII1ILUSTRACIONES....................................................................................116 VII2TABLAS..............................................................................................119
6
i.1 Proyecto Portales Municipales 7 I. CONTEXTO DEL PROYECTO I.1 PROYECTO PORTALES MUNICIPALES El 22 de junio de 2007, se pone en vigor la ley 11/2007. En ella se reconoce el derecho del ciudadano a relacionarse con las Administraciones Públicas por medios electrónicos y regula aspectos básicos de la utilización de las tecnologías de la información en la actividad administrativa, en las relaciones entre las Administraciones Públicas, así como en las relaciones de los ciudadanos con las mismas con la finalidad de garantizar sus derechos. Así, esta ley exige que las distintas Administraciones Públicas garanticen la disponibilidad, el acceso, la integridad, la autenticidad, la confidencialidad y la conversación de los datos, informaciones y servicios que gestionen. El adecuarse a esta nueva ley, incluye un esfuerzo económico de los que muchos municipios con menos recursos no son capaces de hacer frente. Para ello existe actualmente el sistema Pista Administración Local, en el que la mayoría de entidades locales (EELL) basan sus portales. Este sistema permite a estos municipios tener presencia en la red por un coste reducido. Ahora mismo este sistema ha sido superado en funcionalidad y estética por los desarrollos más actuales. Así mismo, la Generalitat y las tres Diputaciones Valencianas, han desarrollado una Carpeta Ciudadana que desarrolla el derecho de los ciudadanos para relacionarse con las administraciones públicas municipales a través de medios electrónicos. Esta plataforma se apoya en el proyecto de administración local SOA de la diputación de Valencia, y en un buen número de otros desarrollos de e-Administración desarrollados por distintas administraciones, como el sellado de tiempo y verificación de firma electrónica de la Autoritat de Certificació de la Comunitat Valenciana, la plataforma unificada del perfil del contratante, el registro electrónico cv-Registro, etc.
i.1 Proyecto Portales Municipales 8 La Administración General del Estado, a través del Centro de Transferencia de Tecnología, proporciona el mecanismo de @firma, así como un servicio de portafirmas y valija electrónica. También proporciona a través del plan Avanza, el sistema gestor de contenidos LocalWeb y el sistema de información geográfica LocalGIS. La diputación de Valencia convoca un concurso para la implantación y puesta en marcha de todas estas tecnologías para las Administraciones Locales de la Provincia de Valencia, desarrollando para cada una de ellas su Sede Electrónica tal como se establece en la ley 11/2009 y se desarrolla en su reglamento. En respuesta a este concurso, nace el proyecto Portales Municipales (ilus. 1) que pretende, como ya se ha comentado, la implantación y puesta en marcha de una plataforma de portales municipales y que incluye la migración y la actualización de todos los portales Pista de la provincia de Valencia. Ilustración 1 - Logo Proyecto Portales Municipales Esta plataforma va a contener cientos de sitios de los distintos municipios que van a tener en común todo un sistema base, el código del gestor de contenidos de nuestra plataforma debe ser multientidad. Por el peso de este proyecto y la necesidad de que estos servicios estén disponibles las 24 horas del día, la plataforma necesitará también un sistema de tolerancia a fallos. Participamos en este proyecto y vamos a intentar garantizar tanto la multientidad como la estabilidad de la plataforma. Para ello vamos a buscar las herramientas necesarias para validar la plataforma y testearla ante distintas cantidades de tráfico, probando a su vez distintas configuraciones para así encontrar la más óptima. La presente memoria del proyecto está estructurada en tres partes. En primer lugar, explicaremos tanto el contexto como los objetivos del proyecto, así como una descripción del concepto de gestor de contenido. En este caso especificaremos las
i.2 Objetivos 9 características de Drupal. En una segunda parte, definiremos la plataforma de explotación, para lo que definiremos el concepto de multientidad y estudiaremos las distintas alternativas posibles para su implementación en esta plataforma, seleccionando la más adecuada. En último lugar, realizaremos el análisis de rendimiento (profiling) de la plataforma, con el fin de encontrar la configuración hardware y software, óptima de la misma. I.2 OBJETIVOS Planteamos cuatro objetivos: Estudiar, seleccionar e implantar un sistema de administración para la plataforma “Portales Municipales”. Realizar manuales de usuario adecuados para el sistema de administración. Diseño de pruebas de rendimiento bajo varias configuraciones sobre el entorno de producción. Trabajar en el entorno profesional de la empresa. Además, el sistema multientidad debe ser accesible remotamente a través de una interfaz web y debe permitir administrar los portales de la plataforma de forma centralizada, permitiendo como mínimo las siguientes operaciones: Creación o eliminación de portales. Backup de portales. Actualización de los portales (Control de versiones). Validación de Portales. Los portales de la plataforma están construidos en base al gestor de contenido (o CMS) Drupal. Este CMS (Content Management System) es de código libre, está
i.3 Gestores de contenido y Drupal 16 También permite mantener comentarios sobre los sucesivos cambios o deshacer los cambios recuperando una versión anterior. Enlaces permanentes. (Permalinks) Todo el contenido creado en Drupal tiene un enlace permanente asociado a él para que pueda ser enlazado externamente sin temor de que el enlace falle en el futuro. Objetos de Contenido. (Nodos) El contenido creado en Drupal es, funcionalmente, un objeto (Nodo). Esto permite un tratamiento uniforme de la información, como una misma cola de moderación para envíos de diferentes tipos, promocionar cualquiera de estos objetos a la página principal o permitir comentarios -o nosobre cada objeto. Plantillas. (Templates) El sistema de temas de Drupal separa el contenido de la presentación permitiendo controlar o cambiar facilmente el aspecto del sitio web. Se pueden crear plantillas con HTML y/o con PHP. Sindicación del contenido. Drupal exporta el contenido en formato RDF/RSS para ser utilizado por otros sitios web. Esto permite que cualquiera con un 'Agregador de Noticias', tal como NetNewsWire o Radio UserLand visualice el contenido publicado en la web desde el escritorio. Blogging Agregador de noticias. Drupal incluye un potente Agregador de Noticas para leer y publicar enlaces a noticias de otros sitios web. Incorpora un sistema de cache en la base de datos, con temporización configurable. Soporte de Blogger. API La API de Blogger permite que un sitio Drupal sea actualizado utilizando diversas herramientas, que pueden ser 'herramientas web' o 'herramientas de escritorio' que proporcionen un entorno de edición más manejable.
i.3 Gestores de contenido y Drupal 17 Plataforma Independencia de la base de datos. Aunque la mayor parte de las instalaciones de Drupal utilizan MySQL, existen otras opciones. Drupal incorpora una 'capa de abstracción de base de datos' que actualmente está implementada y mantenida para MySQL y PostgresSQL. Multiplataforma. Drupal ha sido diseñado desde el principio para ser multiplataforma. Puede funcionar con Apache o Microsoft IIS como servidor web y en sistemas como Linux, BSD, Solaris, Windows y Mac OS X. Por otro lado, al estar implementado en PHP, es totalmente portable. Múltiples idiomas y Localización. Drupal está pensado para una audiencia internacional y proporciona opciones para crear un portal multilingüe. Todo el texto puede ser fácilmente traducido utilizando una interfaz web, importando traducciones existentes o integrando otras herramientas de traducción como GNU ettext. Administración y Análisis Administración via Web. La administración y configuración del sistema se puede realizar enteramente con un navegador y no precisa de ningún software adicional. Análisis, Seguimiento y Estadísticas. Drupal puede mostrar en las páginas web de administración informes sobre referrals (enlaces entrantes), popularidad del contenido, o de cómo los usuarios navegan por el sitio. Registros e Informes. Toda la actividad y los sucesos del sistema son capturados en un 'registro de eventos', que puede ser visualizado por un administrador.
i.3 Gestores de contenido y Drupal 18 Características de comunidad Comentarios enlazados. Drupal proporciona un potente modelo de comentarios enlazados que posibilita seguir y participar fácilmente en la discusión sobre el comentario publicado. Los comentarios son jerárquicos, como en un grupo de noticias o un foro. Encuestas. Drupal incluye un módulo que permite a los administradores y/o usuarios crear encuestas on-line totalmente configurables. Foros de discusión. Drupal incorpora foros de discusión para crear sitios comunitarios vivos y dinámicos. Libro Colaborativo. Esta característica es única de Drupal y permite crear un proyecto o "libro" a ser escrito y que otros usuarios contribuyan contenido. El contenido se organiza en páginas cómodamente navegables. Rendimiento y escalabilidad Control de congestión. Drupal incorpora un mecanismo de control de congestión que permite habilitar y deshabilitar determinados módulos o bloques dependiendo de la carga del servidor. Este mecanismo es totalmente configurable y ajustable. Sistema de Cache. El mecanismo de cache elimina consultas a la base de datos incrementando el rendimiento y reduciendo la carga del servidor. I.3.4 ESTRUCTURA DE DRUPAL Core (Núcleo)
i.3 Gestores de contenido y Drupal 19 El core de Drupal es la instalación básica de Drupal la cual puede opcionalmente ser extendida. Por defecto, el contenido de una página web Drupal puede ser modificado por un usuario registrado o por uno anónimo (a elección del administrador). El core de Drupal también incluye un sistema de taxonomías que nos permite categorizar y etiquetar el contenido mediante el uso de palabras clave para un fácil acceso. El core incluye también módulos que pueden ser activados por el administrador para extender sus funcionalidades. Módulos En Drupal podemos ampliar sus funcionalidades mediante extensiones llamadas módulos programados por su comunidad de usuarios. Entre los más importantes que no están incluidos en la distribución oficial, podemos destacar: Views. Esencialmente, es un constructor de consultas a base de datos inteligente. Permite generar las consultas, ejecutarlas y mostrar los resultados en vistas personalizadas. Content Construction Kit (CCK). Permite al usuario generar nuevos tipos de contenido personalizados. Pathauto. De forma automática genera rutas amigables a los contenidos de Drupal. FileField. Módulo que mejora el sistema de subida de archivos del core de Drupal. Entre otras funciones permite la subida masiva de ficheros. Administration menu. Añade a la interfaz gráfica de administración una barra de menú con accesos directos a las principales funcionalidades de Drupal. ImageField. Módulo similar a filefield pero centrado en la subida a la web de ficheros de imagen.
i.3 Gestores de contenido y Drupal 20 ImageAPI. Mejoras para el tratamiento de imágenes en Drupal. Varios módulos importantes de Drupal son dependientes de este. ImageCache. Mejora el sistema de cache de imágenes en disco. Temas Los temas, nos van a permitir modificar la apariencia de un sitio Drupal. Por defecto ya viene con varios temas pero en la práctica se suelen utilizar otros ya sea o bien desarrollados para el proyecto en cuestión o descargados de la red y creados por terceros. Están formados por un conjunto de hojas de estilo y fichero php.
i.3 Gestores de contenido y Drupal 21
ii.1 Multientidad 22 II.SISTEMA DE EXPLOTACIÓN GESTOR DE CONTENIDOS MULTIENTIDAD En esta parte, vamos a ver primero cómo funciona una aplicación multientidad y el porque necesitamos de esta característica en nuestra plataforma. Después nos vamos a centrar en las distintas formas de conseguir la multientidad en el CMS que hemos usado, Drupal. En segundo lugar, veremos que es un sistema de explotación y nos centraremos en el que hemos utilizado, Aegir. Hemos realizado también los manuales de instalación y de uso de este sistema. II.1 MULTIENTIDAD Una aplicación multientidad es aquella que con una única copia o instalación nos va a permitir atender las necesidades de distintas entidades, manteniendo un nivel de aislamiento suficiente entre cada entidad que es atendida (ilus. 3). En caso contrario, tendríamos que tener una instalación de la aplicación por cada entidad de la misma que necesitemos. (ilus. 4)
ii.1 Multientidad 23 Ilustración 3 - Aplicación Multientidad En el caso que nos ocupa estamos buscando una configuración del gestor de contenido Drupal multientidad que permita sobre una única instalación o plataforma servir los portales web de distintos municipios, cada uno de ellos con sus propios usuarios y permisos, contenidos independientes, y completamente aislados entre ellos. Vamos a ver las ventajas y desventajas que nos puede brindar una aplicación multientidad y que han hecho que busquemos esta característica para nuestra plataforma. Ilustración 4 - Aplicación sin multientidad.
ii.2 Multientidad en Drupal 24 Ventajas: Tiempo. Economía de licencias, y equipamiento. El hecho de usar una sola instalación de los programas en algunos casos debería suponer un ahorro económico. Centralización de las actividades de explotación. Todas las entidades se configuran de forma centralizada. Ahorro de recursos. Desventajas Aumento de la complejidad. Esta desventaja se puede presentar pero no es necesaria. II.2 MULTIENTIDAD EN DRUPAL II.2.1 INTRODUCCIÓN En este apartado, veremos las diferentes alternativas que nos ofrece Drupal como plataforma multientidad y también analizaremos cuáles son los diferentes elementos que podemos compartir o no. El propio core de este gestor de contenidos en su versión 6 ya permite la multientidad. En la carpeta “sites” podemos crear carpetas con el nombre de dominio de nuestro nuevo sitio y Drupal las reconoce como instalaciones diferentes del mismo.
ii.2 Multientidad en Drupal 25 Sin embargo, hay algunas funcionalidades que el core por sí solo no nos centraliza: actualizaciones de los distintos módulos (en el caso de que impliquen actualizar la/s base/s de datos), la instalación de las diferentes entidades. Es por esto que también se han desarrollado algunos módulos que facilitan estas labores. Aunque dependerá de las necesidades que tengamos el utilizarlos o no. Principalmente estos módulos los vamos a utilizar cuando tengamos una gran cantidad de entidades que administrar, como es el caso que nos ocupa. También tendremos que analizar qué es lo que realmente queremos compartir, ya que hay que tener en cuenta que compartimos el código del core de Drupal entre todas las entidades que queramos pero también podemos compartir los temas, los módulos y/o la base de datos, según las necesidades. En principio, lo que siempre vamos a querer compartir por motivos de espacio y de organización es el código base de Drupal, el cual va a ser idéntico para cualquiera de nuestros sitios. Pero también se puede dar el caso de que queramos compartir nuestra base de datos, ya sean todas las tablas o sólo algunas. II.2.2 RESUMEN DE ALTERNATIVAS En esta sección vamos a comentar los principales métodos para crear un multisitio con Drupal. - Multientidad sólo usando el core de Drupal Bases de datos independientes. Para cada sitio web vamos a disponer de una base de datos distinta. Base de datos compartida. Se comparte una base de datos entre varios sitios web. Vamos a ver más adelante que hay tres formas diferentes de base de datos compartida.
ii.2 Multientidad en Drupal 32 $base_url = 'http://sitio2.com'; Base de datos compartida En este caso, elegimos usar una base de datos común para todos nuestros sitios (o para algunos). Vamos a tener tres opciones, la primera va a ser no compartir ninguna tabla mediante el uso de prefijos. La segunda sería compartir todas las tablas entre los distintos sitios aunque cómo ya veremos no es recomendable. Y la tercera nos va a permitir compartir sólo algunas tablas que queremos que sean comunes como por ejemplo las relativas a los usuarios o a las taxonomías (tipos de documento). Así conseguiremos por ejemplo que si un usuario se registra en uno de nuestros sitios, tenga acceso a todo el resto o que si creamos un tipo de documento en un sitio, no haya que repetir el proceso en otro sitio. Vamos a aunar la segunda y tercera opción en un mismo apartado pues son muy similares. Tablasdistintasparacadasitio Este método de instalación es el idóneo en caso de que dispongamos únicamente de una base de datos pero queramos tener un nivel de aislamiento alto.
ii.2 Multientidad en Drupal 33 Ilustración 8 - Tablas independientes En este caso, vamos a estructurar todo como antes pero a la hora de instalar cada sitio vamos a poner la misma base de datos para todos. Además un prefijo diferente para nuestras tablas en cada uno de las instalaciones. Por ejemplo en el sitio1 ponemos el prefijo “sitio1_” y en el sitio2 ponemos “sitio2_”. Con esto conseguimos que todas las tablas del sitio1 comiencen por un prefijo y las del sitio2 por otro, por lo tanto no se va a compartir información entre las 2 instalaciones pese a estar en la misma base de datos. Los ficheros “settings.php” van a ser en este caso muy similares: Para el sitio1 tendremos: // en /sites/misitio1.com/settings.php $db_url = ‘mysqli://user1:contraseña@localhost/base_de_datos’; $db_prefix = array(
ii.2 Multientidad en Drupal 34 ‘default’ => ‘sitio1_’); Y para el sitio 2: // en /sites/misitio2.com/settings.php $db_url = ‘mysqli://user1:contraseña@localhost/base_de_datos’; $db_prefix = array( ‘default’ => ‘sitio2_’); Compartiralgunastablasentrelosdistintossitios Este tipo de instalación suele resultar útil cuando nuestros sitios pertenecen a la misma persona o están muy relacionados entre ellos. Utilizando este método podemos por ejemplo compartir la tabla de usuarios entre varios sitios, manteniendo el resto de tablas aisladas. (ilus. 9) De esta forma, un usuario que entre en el sitio1 y se registre, podría acceder con los mismo credenciales al sitio2. Ilustración 9 - Tablas compartidas
ii.2 Multientidad en Drupal 35 Va a ser muy similar al anterior pero en este caso vamos a tener que modificar antes de instalar los sitios “settings.php". Para el sitio1 tendremos: // en /sites/misitio1.com/settings.php $db_url = ‘mysqli://user1:contraseña@localhost/base_de_datos’; $db_prefix = array( ‘default’ => ‘sitio1_’, ‘users’ => ‘shared_’, ‘sessions’ => ‘shared_’, ‘role’ => ‘shared_’, ‘authmap’ => ‘shared_’, ); Y para el sitio2: // en /sites/misitio2.com/settings.php $db_url = ‘mysqli://user1:contraseña@localhost/base_de_datos’; $db_prefix = array( ‘default’ => ‘sitio2_’, ‘users’ => ‘shared_’, ‘sessions’ => ‘shared_’, ‘role’ => ‘shared_’, ‘authmap’ => ‘shared_’, );
ii.2 Multientidad en Drupal 36 En este ejemplo como hemos comentado anteriormente, estamos compartiendo las tablas necesarias para tener usuarios comunes a los diferentes sitios, pero podríamos compartir otras tablas (incluso todas) si fuese necesario1. Base de datos mixta Este método es una combinación de las alternativas que hemos visto. Consiste en tener bases de datos distintas para cada sitio y a su vez tener otra base de datos más para compartir los usuarios de los sitios (u otras tablas). (ilus. 10) Ilustración 10 - Base de datos mixta Por ejemplo tenemos la “base_de_datos1” que contiene las tablas de misitio1.com, la “base_de_datos2” que contiene las tablas de misitio2.com y una tercera base de datos (“base_de_datos_users”) donde vamos a meter las tablas comunes a ambos sitios. Otra vez tenemos que modificar los ficheros “settings.php”: 1 Por motivos de seguridad se recomienda compartir el mínimo número de tablas.
ii.2 Multientidad en Drupal 37 Para el sitio1 tendremos: // en /sites/misitio1.com/settings.php $db_url = ‘mysqli://user1:contraseña1@localhost/base_de_datos1’; $db_prefix = array( ‘default’ => ‘’, ‘users’ => ‘base_de_datos_users.shared_’, ‘sessions’ => ‘base_de_datos_users.shared_’, ‘role’ => ‘base_de_datos_users.shared_’, ‘authmap’ => ‘base_de_datos_users.shared_’, ); Y en el sitio2: // en /sites/misitio2.com/settings.php $db_url = ‘mysqli://user2:contraseña2@localhost/base_de_datos2’; $db_prefix = array( ‘default’ => ‘’, ‘users’ => ‘base_de_datos_users.shared_’, ‘sessions’ => ‘base_de_datos_users.shared_’, ‘role’ => ‘base_de_datos_users.shared_’, ‘authmap’ => ‘base_de_datos_users.shared_’,
ii.3 Sistema de explotación 38 II.3 SISTEMA DE EXPLOTACIÓN Hemos visto que Drupal en su propio núcleo da soporte a una instalación multientidad pero en nuestro caso esto no va a ser suficiente ya que este CMS por sí solo no dispone de un sistema integrado de explotación, un sistema que en la fase de producción nos facilite todas las tareas de administración y mantenimiento. Buscamos un sistema capaz de permitirnos distintas tareas sobre todas nuestras entidades (sitios webs) desde una interfaz centralizada. Esto va a permitirnos mejorar la eficiencia y rentabilidad de nuestra plataforma. Tareasrequeridas Las tareas que queremos que facilite el sistema de explotación son: Creación de un nuevo sitio. Modificación de un sitio. Actualización de un sitio. Comprobación del estado de un sitio. Explorando por la web oficial vimos que existe un sistema de explotación para este CMS llamado Aegir que cumplía todas nuestras expectativas. Este sistema aporta todo lo que necesitamos en nuestra plataforma. II.4 AEGIR Aegir es un sistema distribuido administrador de instancias Drupal. (ilus.12) Nos va a permitir administrar de forma centralizada todas las plataformas Drupal que queramos las cuales a su vez van a poder alojar cientos de sitios cada una.
ii.4 Aegir 39 Ilustración 11 - Diagrama Aegir Además en las últimas versiones, Aegir maneja plataformas alojadas en servidores distintos por lo que podemos hablar de sistema distribuido. Toda la administración se va a hacer desde un portal basado en Drupal. (ilus. 11) Ilustración 12 - Logo de Aegir
ii.4 Aegir 40 II.4.1 UN POCO DE HISTORIA Aegir es versión del original Hostmaster desarrollado por AdrianRossouw. La primera versión ha estado funcionando durante casi 4 años en http://bryght.com durante casi 4 años, alojando miles de sitios, incluidos los de grandes clientes. Originalmente, el sistema sólo conseguía una única instancia de Drupal, en un único servidor web con un único servidor de bases de datos y como los requisitos en funcionalidad crecieron (ejecutar al mismo tiempo varias versiones de Drupal con diferentes módulos cada uno y más tarde tener que administrar varios servidores) también lo hizo la complejidad del sistema. Hubieron varias decisiones que acarrearon algunos problemas, tales como la elección de Python y PostgreSQL para el back-end y el no plantearlo como un proyecto puramente GPL , limitaron el número de desarrolladores que se sentían atraídos por el mismo. Otro fallo también podría ser la dificultad para instalarlo por los usuarios noveles. El nuevo sistema fue diseñado con todos estos problemas en mente y se pueden ver los objetivos que tiene en el próximo apartado. Aegir a día de hoy ya supera en funcionalidad ampliamente al antiguo HostMaster y está siendo utilizado para multitud de proyectos del mundo real. II.4.2 OBJETIVOS DE AEGIR Facilidad. Tanto para el usuario como para el desarrollador. o Para el usuario: intentar que el sistema sea fácilmente instalable y que sea también de fácil manejo a la hora de administrarlo. El sistema busca autodocumentarse, por ejemplo proporcionando una ayuda ante fallos. o Para los desarrolladores se intenta mantener una implementación clara, simple y concisa y utilizar los mínimos recursos externos a Drupal. También se busca crear una documentación extensa para el programador.
ii.4 Aegir 41 Usabilidad. El sistema busca servir para mantener sitios Drupal no solo en el momento de instalación sino durante todo su ciclo de vida. Seguridad. Seguridad entre los diversos sitios Drupal, por ejemplo el administrador de un sitio no debe poder modificar el contenido de otro sitio ajeno al suyo. Sistema Distribuido. o Como extensión del sistema de backup/restauración el sistema va a permitir mover sitios entre distintos servidores o También será capaz de cambiar de servidores de bases de datos, sencillamente desde el front-end de usuario. Diagnósticos. o El sistema va a generar completos logs de todo lo que ocurra en el mismo así como reportar cualquier error que ocurra mediante una notificación. Va a hacer verificaciones antes y después de realizar cualquier tarea. Antes, para comprobar que es capaz de realizarla y después para comprobar que ha sido bien realizada. o Cuando ocurre algún error en una tarea va a ser capaz de volver atrás dejando el sistema en un estado anterior al error, con el fin de proteger nuestros sitios. Flexible. El sistema busca ser tan flexible como el propio Drupal. II.4.3 ESTRUCTURA DE AEGIR Aegir principalmente está formado por 2 módulos (hosting y provision) y un perfil de instalación. También podemos decir que Aegir tiene 2 componentes, el front-end y el backend. En diseño de software el front-end es la parte del software que interactúa con el o
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 48 aegir ALL=NOPASSWD: /usr/sbin/apache2ctl Configurar nuestra Base de Datos Vamos a realizar la configuración básica de nuestro servidor MySQL. Todos los comandos los vamos a tener que ejecutar como superusuario (root) de este. Es decir lo primero sería entrar en el gestor MySQL con el siguiente comando. mysql –u root –p Los nombres tanto de la base de datos y de los usuarios que vamos a crear se pueden cambiar por los que le convengan al administrador siempre que luego se tenga en cuenta cuando estemos rellenando el formulario web de instalación de Aegir. Creamos una base de datos, en nuestro caso vamos a llamarla “aegir”. CREATE DATABASE aegir; Creamos un usuario con los privilegios suficientes para administrar esa base de datos, en nuestro caso vamos a llamarlo también “aegir”. GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, \ CREATE TEMPORARY TABLES, LOCK TABLES ON aegir.* TO \ 'aegir'@'localhost' IDENTIFIED BY 'XXXXXXXX'; Aegir va a necesitar crear bases de datos nuevas por lo que necesitamos un usuario con permisos para ello. Creamos este usuario y lo llamamos “aegir_root”. GRANT ALL PRIVILEGES ON *.* TO 'aegir_root'@'localhost' IDENTIFIED \ BY 'XXXXXXXX' WITH GRANT OPTION; Descargar ficheros de Aegir y ejecutar script
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 49 Vamos a descargar ahora de la siguiente dirección un script que nos permitirá instalar fácilmente Aegir. El enlace que mostramos aquí es el de la versión 0.4 alpha8 de Aegir. Lo vamos a descargar a la carpeta /var/aegir de nuestro servidor. http://git.aegirproject.org/?p=provision.git;a=blob_plain;f=ins tall.sh.txt;hb=provision-0.4-alpha8 Abriendo el script veremos que disponemos de varias variables que podemos modificar. Podemos por ejemplo descargar otra versión de aegir, otra versión de drush, cambiar la ruta de instalación (por defecto /var/aegir) o cambiar el dominio donde va a estar disponible nuestra página web de administración (aegir.example.com). En este caso vamos a dejar intactas las variables por defecto y pasaremos directamente a la ejecución del script. El script debe ser ejecutado por el usuario UNIX que creamos anteriormente llamado “aegir” y bajo el shell sh así que puesto que ahora mismo estamos identificados como supersusuarios del sistema tendremos que ejecutarlo con la siguiente orden. su -s /bin/shaegir -c "sh install.sh.txt" Este proceso de instalación hace modificaciones en la configuración de los vhosts de Apache por lo que después de ejecutarlo vamos a reiniciarlo. /etc/init.d/apache2 restart Instalación en la web Abrimos nuestro explorador web y entramos en nuestra web de administración. Por defecto tendremos que entrar en http://aegir.example.com /install.php Aquí, lo primero que tendremos que hacer es elegir el perfil de instalación hostmaster y seguir paso por paso los formularios. Tendremos que introducir el nombre de la base de
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 50 datos los 2 usuarios que hemos creado para administrar nuestro servidor MySQL con sus respectivas contraseñas. El propio formulario en un momento dado también nos pedirá que introduzcamos un par de instrucciones en la línea de comandos para completar la instalación. Después de seguir estos formularios tendremos listo nuestro sistema Aegir para empezar a administrarlo. II.5.2 GUÍA DE USO Esta parte pretende informar de los pasos necesarios para administrar correctamente Aegir. Éste dispone de un menú bastante intuitivo para administrar nuestros sitios pero algunas de las operaciones las tendremos que hacer manualmente. Explicaremos cómo realizar funciones tales como crear un sitio, migrar, renombrar (su dominio principal y sus alias), hacer un backup y restaurarlo (volver al estado del último backup), validar el sitio (comprobar el sitio). Crear nueva plataforma Como hemos visto previamente, una plataforma no es más que un código base de Drupal o similar con algun/os perfil/es de instalación, temas y módulos. Para instalar una vamos a tener que hacerlo en dos pasos, el primero es a través del Shell de Linux y el segundo ya de forma gráfica desde nuestro portal Aegir. Prepararplataformadesdeelservidor 1) Lo primero que debemos hacer es descargar este código base. Para ello disponemos de los módulos de Drush4 que nos facilitan esta tarea, eso si debemos obligatoriamente hacerlo vía shell de linux. 4 una "interfaz de linea comandos"(CLI) que nos permite realizar tareas rutinas de mantenimiento del sitio
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 51 2) Para tener una buena organización de nuestro sistema estaría bien crear en nuestra carpeta raíz de Aegir una carpeta “platforms” o “plataformas” donde vamos a tener todas las plataformas que creemos. Esto permitirá tener siempre localizados los ficheros de nuestros sitios en un futuro. Todo este proceso se debería hacer identificado como el usuario aegir y no como root. 3) Por lo tanto nos logueamos con shell sh: su –s /bin/shaegir Creamos la carpeta “platforms” en /var/aegir. mkdir /var/aegir/platforms 4) Ahora dentro de la carpeta platforms vamos a descargar el código base drupal, Drush nos facilita el trabajo. Por ejemplo para descargar la versión 6.17 de drupal utilizaríamos el siguiente comando: /var/aegir/drush/drush.php dl drupal-6.17 También podemos usar otros métodos propios de Linux como wget o CVS por ejemplo. 5) Lo siguiente ya es configurar este código base desde nuestra web de administración, por lo tanto entramos en nuestro portal Aegir y seguimos los siguientes pasos. ConfigurarlaplataformadesdeAegir En el menú principal hacemos clic sobre Content Management >> Create Content >> Platform. (ilus. 15)
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 52 Ilustración 15 - Menú superior Aegir Ahora nos aparece una nueva pantalla tenemos que darle un nombre a nuestra plataforma, y la ruta dentro de nuestro servidor dónde está el código base que acabamos de instalar. (si hemos seguido todos los pasos anteriores será “/var/aegir/platforms/drupal-6.17”) Podemos seleccionar si queremos que sea nuestra plataforma por defecto. Si hacemos clic sobre esta opción todos los sitios que creemos a partir de ahora de “forma rápida” (ver sección Crear nuevo Sitio) serán instalados en esta plataforma. Ilustración 16 - Pantalla "Crear plataforma"
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 53 Luego también podemos modificar parámetros propios de todos los contenidos de Drupal. (Información de revisión, información de autoría u opciones de publicación) Crear nuevo sitio Tenemos 2 formas de crear un nuevo sitio, tenemos una forma rápida, en la que no podemos elegir la plataforma ni el perfil de instalación pero podemos asignar como cliente un cliente inexistente hasta el momento y otra forma más lenta en la que podremos personalizar más parámetros pero a cambio tendremos que haber creado antes el cliente. FormaRápida 1) Hacemos clic en “Sign-up for a Site” disponible en el menú lateral derecho. (ilus. 17)
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 54 Ilustración 17 - Menú lateral Aegir 2) Accederemos a un menú dónde elegimos el nombre del dominio, el lenguaje (solo los disponibles en tu plataforma por defecto pues no podemos elegir otra), el mail del administrador (tendremos que confirmarlo), el nombre del cliente y su organización. 3) Hacemos clic en Sign up (ilus. 18)
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 55 Ilustración 18 - Formulario nuevo sitio FormaPersonalizada 1) En el menú de administración, vamos a hacer clic en Content Management >> Createcontent >> CreateSite. (ilus. 19) Ilustración 19 - Menú superior Aegir (2) 2) Primero tendremos que poner el dominio de nuestro nuevo sitio, previamente deberemos haber configurado el DNS del dominio, para que apunte a nuestro servidor.
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 56 3) Seguidamente, tenemos que elegir nuestro cliente. Este debemos haberlo creado antes. 4) Después elegimos tanto los diferentes alias que puede tener nuestro sitio, la plataforma en la que lo instalaremos, el idioma y el perfil de instalación. 5) Hacemos clic en Aceptar. (ilus. 20) Ilustración 20 - Pantallazo Aegir (Crear Sitio) 6) Nuestro cliente recibirá un mail en su correo que le permitirá entrar en su nuevo sitio para poder empezar de inmediato a administrarlo. Migración de un sitio Migrar un sitio nos va a permitir mover nuestro sitio de una plataforma a otra. Con el fin normalmente de mantenerlo actualizado, por ejemplo para mejorar la seguridad de nuestros sitios. Por ejemplo, pongamos que tenemos 100 sitios web basados en Drupal alojados en nuestro servidor en la plataforma 6.15 y aparece la nueva versión de Drupal 6.17 que resuelve algunos problemas de seguridad, mediante la migración podremos con un solo clic migrar nuestras 100 webs a la nueva plataforma. Pero no solo sirve para
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 57 actualizar el código base de nuestras webs, también puede servir para dar acceso a nuevos módulos o temas. Por ejemplo en el caso de una empresa que tiene un tipo de cliente al que ofrece el servicio básico que solo da derecho al uso de los temas y los módulos básicos de Drupal y otro al que ofrece un servicio más caro llamado avanzado que tiene muchos más temas y módulos para elegir. Si el cliente decide mejorar su contrato podremos cambiarle de plataforma para que tenga más posibilidades con un solo clic. HacerunBackup 1) Antes de hacer una migración se debería siempre hacer un backup del sitio para poder recuperar la información de este en el caso de que la migración falle o nuestro sitio no funcione como esperamos en la nueva plataforma. Los sitios los podemos migrar individualmente o conjuntamente, de forma muy similar. Esto veremos cómo hacerlo en esta misma guía de uso. Verificarquelaplataformadestinoseacompatible 2) Vamos a la página principal de Aegir, seleccionamos el sitio que queremos migrar, o en el caso de que queramos migrar varios sitios de una plataforma, seleccionamos esta desde el menú plataformas situado en la barra lateral derecha. (ilus. 21)
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 64 Ilustración 27 - Resultado verificación de un sitio Clonar un sitio Esta función de Aegir nos permite clonar nuestro sitio en la plataforma que queramos y asignándole el dominio que queramos. 1) Entramos en la página de administración de nuestro sitio como en los procesos anteriores. Y hacemos clic sobre Run en la pestaña “Clone”. (ilus. 28).
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 65 Ilustración 28 - Menú tareas 2) Nos aparecerá una pantalla dónde podemos decidir en qué plataforma queremos clonar nuestro sitio. Tenemos que tener en cuenta que antes habría que comparar las plataformas. Cómo hemos visto anteriormente en la sección “Migración de un sitio”. Para este fin, al lado de cada plataforma nos aparece la opción “Compare Platforms”. Podemos también cambiar el nombre del dominio de nuestro sitio por el que deseemos y añadir los alias de dominio que necesitemos. (ilus. 29)
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 66 Ilustración 29 - Formulario para clonar un sitio
ii.5. Instalación, Uso, y Ampliación de las funciones de explotación 67
iii.1. Objetivos 68 III. VALIDACIÓN DE LA PLATAFORMA. RENDIMIENTO En este apartado, principalmente vamos a buscar la configuración hardware y software óptima para nuestra plataforma. Para ello empezaremos describiendo los objetivos que buscamos, describiendo el montaje de prueba que hemos realizado, para luego tomar una cantidad de resultados y analizarlos. III.1. OBJETIVOS Tenemos que tener en cuenta que la plataforma “Portales Municipales” va a albergar un número creciente de páginas web. En un principio serán “sólo” 200 páginas pero en un futuro la necesidad puede aumentar. En esta parte del proyecto se persigue validar la configuración óptima de nuestra plataforma. Buscamos que esta sea escalable pues no se sabe la cantidad de sitios que podrían haber en un futuro por lo que buscamos saber cómo evolucionará el rendimiento de esta ante cambios en el hardware y el software de la misma. III.2. DESCRIPCIÓN DEL MONTAJE DE PRUEBA III.2.1 HARDWARE Para comprobar el correcto funcionamiento de nuestra plataforma de Portales Municipales hemos utilizado 2 servidores.
iii.2. Descripción del montaje de prueba 69 Uno, con el sistema operativo Linux CentOS 5 de 64 bits nos ha servido para realizar las pruebas de rendimiento. Mediante el programa ApacheBench nos ha permitido testear nuestro servidor web a diferentes cargas. En el otro hemos instalado un sistema de virtualización ya que en la práctica contendrá diversas máquinas virtuales. Una de ellas es nuestro servidor web de pruebas. El sistema de virtualización empleado es VMwarevSphere 4.1 por lo tanto nuestro servidor físico tiene instalado ESXivSphere 4.1. El hecho de utilizar una plataforma de virtualización nos ha permitido probar el rendimiento de nuestro servidor con diferentes configuraciones de hardware fácil y económicamente. Además en el entorno final de producción se usa este mismo sistema de virtualización.
iii.2. Descripción del montaje de prueba 70 Máquina con Apache Benchmark (Simulador de clientes) Máquina con VMWarevSphere (Host del servidor web) Equipo Fabricante: HP Placa Base: HP Proliant DL160 G6 CPU Cores: 4 CPU cores a 2.0 GHz Tipo de procesador: Intel® Xeon® E5504, 4MB de caché, 2000 MHz, QPI de 4.8 GT/s Memoria RAM: 4092 MB DDR3-1330 Disco Duro: 2 * 250 GB SATA2 en RAID 0+1 Fabricante: BULL Modelo: R410 CPU Cores: 4 CPU cores a 2.4 GHz Tipo de procesador: Intel® Xeon® CPU X3220 a 2.40 GHz, 2*2MB de cache, FSB 1066 Memoria RAM: 4092 MB DDR2-667 MHz Disco Duro: 250 GB SATA2 7200RPM Sistema Operativo Linux CentOS 5.3 - 64 bits vSphereESXi 4.1 (host de vmWarevCenter) Herramienta de pruebas ApacheBenchVersion 2.0.40dev Tabla 1 - Tabla de Hardware Ahora pasamos a detallar el sistema operativo, software y configuración hardware por defecto de nuestro servidor virtual. Cabe mencionar que ya que hemos probado el servidor virtual con diferentes configuraciones. Se ha probado el rendimiento para 1, 2 y 4 cores.
iii.2. Descripción del montaje de prueba 71 Máquina Virtual (Servidor Web) Características CPU: 2 CPU cores a 2.4 Ghz Memoria RAM: 2048 MB Disco duro: 50 GB Sistema Operativo Linux CentOS 5.3 – 64 bits Software Servidor Web: Apache 2.0 Versión PHP: 5.2.10 Acelerador PHP: eAccelerator v0.9.5.2 Tabla 2 - Configuración Máquina Virtual del Servidor Durante las pruebas tuvimos que utilizar un tercer servidor (ver figura) para realizar pruebas, al que instalamos Windows 7 Ultimate de 64 bits y en el que instalamos la aplicación webstress server 7.2. Finalmente viendo que a grandes cantidades de tráfico el cliente era el factor limitante decidimos utilizar el otro servidor con webstress.
iii.2. Descripción del montaje de prueba 72 Máquina de pruebas con WebStress Server Características Fabricante: Dell Modelo: Dell Poweredge 1950 CPU: 2 CPU's Intel Xeon 5160 con cores cada uno Tipo Procesador: Intel Xeon 5160, doble core a 3GHz, 2*2MB de memoria cache, FSB 1333MHz Memoria RAM: 12 GB DDR2-667 Sistema Operativo Windows 7 Ultimate 64 bits Software Webstress Server 7.2 Tabla 3 - Configuración Máquina de Pruebas Adjuntamos los resultados de benchmarking de los procesadores que hemos utilizado según la web cpubenchmark.net a 4 de octubre de 2010 comparados con los 10 mejores procesadores del momento. (ilus. 30, 31 y 32)
iii.2. Descripción del montaje de prueba 73 Ilustración 30 - Benchmarking Intel Xeon E5504 Ilustración 31 - Benchmarking Intel Xeon X3220
iii.2. Descripción del montaje de prueba 80 consideramos cumple el rendimiento medio que tendrán las webs finales, es la web del Ayuntamiento de Cheste. (ilus. 35) Los resultados obtenidos provienen de hacer peticiones al home del sitio, pues es la página web del sitio que más recursos requiere (imágenes, consultas a bases de datos, applets) Ilustración 35 - Web de Pruebas del Ayuntamiento de Cheste (www.cheste.es)
iii.3 Descripción de la prueba 81 III.2.6 SOFTWARE CLIENTE: Hablamos de los clientes para hablar de las 2 máquinas que nos sirven para testear nuestro servidor web virtual. Durante las pruebas, hemos utilizado principalmente 2 aplicaciones dedicadas a medir el rendimiento de nuestro servidor. Primero, optamos por probar una aplicación gráfica bajo el sistema operativo Microsoft Windows, WebStress Server Tools 7.2 debido a la simplicidad del mismo y el hecho de que nos sacaba gráficas de manera muy cómoda. Para las pruebas en las que no se usaba ningún tipo de caché o solo la caché por defecto que aporta Drupal, el rendimiento del programa era óptimo. Sin embargo, cuando añadimos a nuestro servidor web un acelerador de PHP y el módulo Boost de Drupal, el cliente se tornó en el factor limitante de las pruebas por lo que nos era imposible sacar el rendimiento máximo del servidor para estas configuraciones. Aunque intentamos, repetir las pruebas utilizando una máquina física más potente, los resultados fueron similares, lo cuál hizo que tuviésemos que cambiar nuestra forma de proceder. Decidimos que debíamos cambiar la herramienta de test. Y optamos por la herramienta que nos proporciona Apache para este fin, Apache Benchmark. Esta aplicación a diferencia de la primera esta solo disponible en modo gráfico. Para las prueabs de rendimiento con ab hemos instalado en la máquina cliente el sistema operativo Linux CentOS. 5.3 III.3 DESCRIPCIÓN DE LA PRUEBA La prueba ha consistido en generar a través de programas de testeo una carga controlada sobre el servidor web de portales municipales sobre el que se había configurado un portal modelo. La carga se realiza sobre una página única siendo esta la portada de la web.
iii.3 Descripción de la prueba 82 La carga se ha ido aumentando progresivamente hasta alcanzar la capacidad máxima del servidor. Hemos identificado esta situación por el aumento de los tiempos medios de respuesta más allá de 1 segundo para más del 1% de las consultas. Se ha verificado en todos los casos que no se aplicaba limitación alguna ni en la memoria ram utilizada, ni en el ancho de banda (salvo en el último caso como se verá). Se han configurado los servidores con memoria ram suficiente para que no fuera un factor limitante de las pruebas. Se han realizado las pruebas para 3 configuraciones del servidor virtual diferentes, con 1 core, 2 cores y 4 cores. Se han tomado 3 medidas consecutivas sin periodo de descanso y se ha tomado la última obtenida, considerando correcta la prueba si la desviación entre medidas calculada fuera inferior al 10% de la media. Al ser las pruebas consecutivas, a efectos del servidor ha sido una prueba 'triple'. En todos los casos también se ha realizado una prueba de carga superior para confirmar que la carga era máxima y el rendimiento se deterioraba a partir de las medidas tomadas. Inicialmente se utilizó el software Webstress del que no se pudieron obtener datos fiables, al ser en muchos casos la carga del cliente muy superior a la del servidor. No se probó la configuración para varios cliente 'atacando' el servidor al no disponer de equipamiento suficiente. Las pruebas se han realizado con el software ab utilizando el comando. ab -n numero_de_peticiones -c numero_de_peticiones_concurrentesurl Por ejemplo, para uno de nuestros casos: ab -n 10000 -c 400 http://www.pruebascheste.com/index.php
iii.3 Descripción de la prueba 83 Se le indican dos parámetros, el número de peticiones y el número de clientes (peticiones concurrentes). El número de clientes es parámetro de esfuerzo debiendo ser el número de peticiones lo suficiente grande para generar un estado de estabilidad en la carga por parte de todo el sistema. (ilus. 36) Concurrency Level Time taken for tests seconds Complete requests Failed requests Write errors Total transferred bytes HTML transferred bytes Requests per second [#/sec] (mean) Time per request [ms] (mean) Time per request [ms] (mean, across all concurrent requests) Transfer rate [Mbytes/sec] received Connection Times (ms) Connect Processing Waiting Total Percentage of the requests served within a certain time (ms) Ilustración 36 - Datos de los resultados de los informes La prueba tiene el objeto de determinar la relevancia de los parámetros de cpu y de distintas mecanismos de aceleración sobre el rendimiento de la plataforma de portales municipales.
iii.3 Descripción de la prueba 84 El parámetro que hemos intentado maximizar es el de peticiones atendidas por segundo, para así poder extrapolar el número máximo de peticiones aceptadas por hora de servicio del servidor. III.3.1 MECANISMOS DE ACELERACIÓN DEL GESTOR DE CONTENIDOS Para poder describir los mecanismos de aceleración del gestor de contenidos (Drupal 6) que hemos utilizado, es necesario definir el concepto de caché. Una caché es un conjunto de datos duplicados de otros más difíciles de obtener. Cuando se accede por primera vez a un dato que requiere de un proceso costoso para obtenerlo, por ejemplo múltiples consultas a una base de datos, se almacena. En los siguientes accesos al contenido se devuelve la copia ya guardada anteriormente, comprobando antes que no se haya modificado. De aquí, se deduce que será más eficiente el uso de la caché en un sitio que se actualice pocas veces, por ejemplo una web meramente informativa que en un sitio que este en constante cambio, como por ejemplo una red social o un foro. De forma genérica podríamos definir un sistema de caché con el siguiente diagrama. (ilus. 37)
iii.3 Descripción de la prueba 85 Ilustración 37 - Mecanismo de funcionamiento de un sistema de Caché Según el sistema de caché que utilicemos podemos almacenar estas copias de contenido en distintos sitios del sistema, en memoria primaria (memoria RAM), en memoria secundaria (disco) o en la propia base de datos (aunque pueda parecer que no haya una mejora de rendimiento por el hecho de hacer una consulta a la base de datos, hay que tener en cuenta que en este caso sacamos todo el contenido de la página en una sola consulta a esta mientras que sin sistema de caché tendremos que hacer múltiples consultas) En el caso de Drupal, el gestor de contenido que nos interesa, podemos guardar bloques, variables, filtros, formularios, menús o páginas completas. Este factor puede llegar a ser muy importante en el sistema de caché que utilicemos. Los usuarios anónimos de un sitio suelen limitarse a leer contenidos, normalmente no interactúan pues la mayoría de funcionalidades que proporcionan interacción requieren de una cuenta de usuario. En actividades de interacción podríamos mencionar: comentar, valorar un contenido, buscar, agregar contactos, etc. dependiendo de los módulos que estén instalados en Drupal puede haber cientos de formas de interacción que se tienen que efectuar en tiempo real y que harían que un contenido se modifique muy a menudo, por lo que sería inviable guardar una copia en caché porque en breve quedaría desfasada de su contenido real. Afortunadamente en la mayoría de sitios de
iii.3 Descripción de la prueba 86 contenidos, la distribución de usuarios será 80% anónimos y 20% autenticados como máximo por lo que la masa crítica verá la página cacheada y no tendrá bloques con contenido personalizado. Aún así existen métodos para mejorar también el rendimiento en sitios muy dinámicos. Caché Drupal Drupal tiene una función en el núcleo que permite activar la cache por página (ilus. 38), esto quiere decir que cada vez que se solicita un contenido por primera vez Drupal hace cientos de consultas, procesa esta información y la renderiza guardando ese HTML final en un motor de caché, esta copia será utilizada para servir el contenido a un coste menor de procesamiento en la siguientes peticiones de los usuarios anónimos. La caché de página no sirve para usuarios autenticados porque los bloques de contenido personalizados (por ejemplo el saludo de usuario “Hola Juan”) no tendrían sentido para otro usuario. En ese caso hay otras soluciones como la carga de los bloques personalizados de forma dinámica con una petición AJAX que se sobrepone al contenido cacheado.
iii.3 Descripción de la prueba 87 Ilustración 38 - Formulario de configuración de la caché del core de Drupal Un gran problema de la caché del núcleo de Drupal es que no tiene reglas configurables de caché, si necesitas cachear solo ciertas páginas u omitir otras, o cachear todo pero exceptuando ciertas páginas, olvídalo, es imposible con la función del núcleo. Afortunadamente existen otros módulos que permiten añadir estas funcionalidades a la caché de Drupal. Acelerador de PHP – Eaccelerator Para explicar que es un acelerador de PHP, primero debemos tener en cuenta que PHP es un lenguaje de programación interpretado. Es decir, por cada petición de una página PHP, el servidor primero traduce/compila PHP, en un lenguaje intermedio (bytecode) que finalmente es interpretado por un intérprete de PHP o máquina virtual (ZendEngine) que ejecuta el código y nos proporciona el código estático HTML final. (ilus. 39)
iii.3 Descripción de la prueba 88 Ilustración 39 - Proceso de compilación de PHP Un acelerador de PHP (ilus. 18) utiliza un sistema de caché para almacenar en memoria los scripts en código bytecode, ahorrándonos el realizar la fase de traducción/compilación para cada petición de la web en PHP. Cada vez que el servidor recibe una petición de un script de php, (ilus. 40)
iii.3 Descripción de la prueba 89 Ilustración 40 - Mecanismo de funcionamiento de un acelerador de PHP Si el script de php que se nos solicita esta en caché y no ha sido modificado desde que se almacenó se carga de la caché, en caso contrario se compila y se sirve. En el caso de que el script incluya otros scripts se sigue el mismo proceso para todos ellos recursivamente.
iii.5. Conclusiones 96 Tabla 6 - Peticiones atendidas en una hora Para usuarios identificados, donde no se puede aplicar la de Boost ni la configuración de Cache de Drupal, la configuración de eAccelerator no ha mostrado ninguna mejoría y el rendimiento esperable es el del sistema sin aceleración. En este caso el rendimiento vendrá fijado por la potencia del hardware del servidor. Existen algunas soluciones estudiadas en este informe como el módulo AuthCache el cuál hemos comentado previamente y que nos aumentarían el rendimiento para usuarios autentificados que aunque no hemos podido comprobar debería acelerar el proceso de forma a similar a como lo hace Boost.
iii.5. Conclusiones 97
iii.5. Conclusiones 98 IV. CONCLUSIONES Como conclusión a este proyecto podemos decir que hemos llevado a cabo la elección y validación de un sistema de explotación multientidad para el proyecto Portales Municipales de la Diputación de Valencia con éxito. Aunque en un principio nos planteábamos el diseño y desarrollo del mismo, durante el estudio de requisitos del proyecto nos dimos cuenta de que existían ya alternativas para llevar a cabo las tareas que necesitábamos. En este caso el programa Aegir nos ha sido de gran ayuda ya que aúna la mayoría de características buscadas para nuestra plataforma de explotación. Con esta aplicación desarrollada por terceros a mano sólo necesitábamos validar la plataforma además de crear los manuales de usuario necesarios para un correcto manejo de la misma. Al iniciar el proyecto además de validar el rendimiento de la plataforma también pensábamos que sería necesario crear un sistema de recuperación ante fallos pero gracias a las herramientas de virtualización de las que hace uso la Diputación no nos ha sido necesario centrarnos en ese problema pues ya vienen soluciones integradas en estas herramientas. Así que lo único problemático ha sido el buscar una configuración software y hardware óptima para nuestra plataforma. Además como conclusiones personales podemos sacar que en mi caso ha sido la primera vez que hemos podido participar en un proyecto llevado a cabo en una empresa por lo cual nos ha aportado una experiencia que no teníamos. Resaltamos cómo positivo que este proyecto nos ha permitido por primera vez trabajar en el entorno profesional de la empresa. Además de esto también nos ha permitido profundizar en materias que no se tocan mucho en la facultad de informática. En este sentido, hemos aprendido a preparar la documentación de nuestra plataforma, también hemos cogido bastantes conocimientos en cuanto a administrar la plataforma de virtualización vmware vSphere y finalmente destacaríamos que hemos aprendido a preparar un entorno para realizar pruebas de rendimiento (profiling)
iii.5. Conclusiones 99 Cómo conclusión podemos decir que los objetivos tanto de trabajo, es decir el proyecto que tenía que cumplir la empresa, cómo personales se han cumplido satisfactoriamente.
iii.5. Conclusiones 100 V. BIBLIOGRAFÍA http://szeged2008.drupalcon.org/program/sessions/deploying-and-maintaining-drupalsites-using-aegir-hosting-system, [consultado el 01/08/2010] http://drupal.groups.com, [consultado el 01/08/2010] http://szeged2008.drupalcon.org/files/aegir.pdf, [consultado el 03/08/2010] http://sf2010.drupal.org/conference/sessions/aegir-hosting-system-one-drupal-rulethem-all, [consultado el 01/08/2010] http://www.boe.es/aeboe/consultas/bases_datos/doc.php?id=BOE-A-2007-12352, [consultado el 20/09/2010] http://es.wikipedia.org/wiki/Cache, [consultado el 01/08/2010] http://www.tratonera.com/?q=node/58, [consultado el 03/09/2010] http://cambrico.net/drupal/cache-en-el-desarrollo-de-drupal-6, [consultado el 01/08/2010] http://community.aegirproject.org/notebook, [consultado el 18/08/2010] http://www.drupblue.com/blog/instalando-aegir, [consultado el 09/08/2010] http://groups.drupal.org/node/23712, [consultado el 01/09/2010] http://info.vmware.com/content/9270_SP_Gen?src=PaidSearch_Google_PaidSearch_G oogle_EMEASouth_SpanIB_VI_General_VMware_Search&gclid=CPCplLOQhKsCFUEMfAod3Wr A3g, [consultado el 10/08/2010]
iii.5. Conclusiones 101
vi.1 Resultado de las pruebas de rendimiento al completo 102 VI. ANEXOS VI.1 RESULTADO DE LAS PRUEBAS DE RENDIMIENTO AL COMPLETO VI.1.1 CABECERA COMÚN A TODAS LAS PRUEBAS ServerSoftware Apache/2.2.3 ServerHostname www.pruebascheste.com ServerPort 80 DocumentPath / DocumentLengthbytes 66195bytes VI.1.2 BOOST + EACCELERATOR BOOST1CORE2GB BOOST2CORES2GB BOOST4CORE2GB 75 250 400 13,15 42 41,53 10000 50000 50000 00 0 00 0 668841856 3344879704 3345438632 664921464 3325268336 3325824912 760,54 1202,49 1203,99 98,61 208 332,23 1,32 0,83 0,83 48,51 76,72 76,83 01231.0132999 040218.8279027 02291.2203032 438514.583344 7166172.41188590 113052747.08638887 12815.62871 540124.4292486 62242724.12237724 Total 439732.6963046 7206278.51459279 113282747.510438893 50%96 50%145 50%104 66%98 66%168 66%106 75%99 75%173 75%110 80%100 80%201 80%121 90%110 90%280 90%140 95%123 95%425 95%179 98%140 98%611 98%483 99%143 99%849 99%813 Hardware ConcurrencyLevel Timetakenfortestsseconds Completerequests Failedrequests Writeerrors Totaltransferredbytes HTMLtransferredbytes Requestspersecond[#/sec](mean) Timeperrequest[ms](mean) Timeperrequest[ms](mean,acrossallconcurrentrequests) Transferrate[Mbytes/sec]received ConnectionTimes(ms) minmean[+/‐sd]medianma x minmean[+/‐sd]median minmean[+/‐sd]medianmax Connect Processing Waiting Percentageoftherequestsservedwithinacertaintime(ms) 100%3046(longestrequest) 100%9279(longestrequest) 100%38893(longestrequest)
vi.1 Resultado de las pruebas de rendimiento al completo 103 VI.1.3 EACCELERATOR + CACHÉ DRUPAL eAccelerator1Core2GB eAccelerator2Cores2GB eAccelerator4Cores2GB ConcurrencyLevel 20 30 40 Timetakenfortestsseconds 226.429462seconds 25.497656seconds 16.616276seconds Completerequests 50000 10000 10000 Failedrequests 00 0 Writeerrors 00 0 Totaltransferredbytes 3333900000 666780000 666780000 HTMLtransferredbytes 3309750000 661950000 661950000 Requestspersecond[#/sec](mean) 220,82 392,19 601,82 Timeperrequest[ms](mean) 90,57 76,49 66,47 Timeperrequest[ms](mean,acrossallc o 4,53 2,55 1,66 Transferrate[Kbytes/sec]received 14378,7 25537.72[Kbytes/sec]received 39187,6 ConnectionTimes(ms) ConnectionTimes(ms) ConnectionTimes(ms) minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax Connect 011.409000.705000.406 Processing 788430.44833125 675283.7467303 76565.850773 Waiting 374421.53532445 456234.7367274 44951.339740 Total 790430.44933125 775283.7467303 86565.950773 PercentageoftherequestsservedwithinacertainPercentageoftherequestsservedwithinaPercentageoftherequestsservedwithinace r 50%49 50%46 50%50 66%85 66%62 66%64 75%111 75%75 75%76 80%133 80%86 80%85 90%187 90%130 90%118 95%238 95%180 95%166 98%310 98%263 98%263 99%389 99%348 99%369 100%33125(longestrequest) 100%7303(longestrequest) 100%773(longestrequest)
vi.1 Resultado de las pruebas de rendimiento al completo 104 VI.1.4 CACHÉ DRUPAL Hardware Caché2Cores2GB Caché4Cores2GB ConcurrencyLevel 51015 Timetakenfortestsseconds 123.604721seconds 64.577020seconds 69.696272seconds Completerequests 5000 5000 10000 Failedrequests 000 Writeerrors 000 Totaltransferredbytes 333390000bytes 333390000bytes 666840816bytes HTMLtransferredbytes 330975000bytes 330975000bytes 662010333bytes Requestspersecond[#/sec](mean) 40,45 77,43 143,48 Timeperrequest[ms](mean) 123,61 129,15 104,54 Timeperrequest[ms](mean,acrossallcon c 24.721[ms](mean,acrossallconcurrentrequests) 12.915[ms](mean,acrossallconcurrentrequests) 6.970[ms](mean,acrossallconcurrentrequests) Transferrate[Kbytes/sec]received 2634.01[Kbytes/sec]received 5041.67[Kbytes/sec]received 9343.56[Kbytes/sec]received ConnectionTimes(ms) ConnectionTimes(ms) ConnectionTimes(ms) minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax Connect 001.2012 001.809001.708 Processing 2412229.1121735 25127296.811716635 2810364.3983036 Waiting 219826.198727 2298204.89111123 238050.5762816 Total 2412229.1121735 25128296.711816635 2810364.3993036 Percentageoftherequestsservedwithinacertaintime(Percentageoftherequestsservedwithinacertaintime(ms) Percentageoftherequestsservedwithinacertaintime(ms) 50%121 50%118 50%99 66%127 66%130 66%111 75%131 75%138 75%119 80%134 80%143 80%125 90%143 90%161 90%142 95%151 95%176 95%159 98%173 98%205 98%185 99%197 99%264 99%219 100%735(longestrequest) 100%16635(longestrequest) 100%3036(longestrequest)
vi.1 Resultado de las pruebas de rendimiento al completo 105 VI.1.5 SIN CACHÉ DRUPAL Hardware SinCaché1Core2GB SinCaché1Core2GB SinCaché1Core2GB ConcurrencyLevel 1 2 4 Timetakenfortestsseconds 93.789976seconds 51.65208seconds 27.481037seconds Completerequests 100 100 100 Failedrequests 0 0 0 Writeerrors 000 Totaltransferredbytes 6669300 6669300 6669300 HTMLtransferredbytes 6619300 6619300 6619300 Requestspersecond[#/sec](mean) 1,07 1,96 3,64 Timeperrequest[ms](mean) 937.900[ms](mean) 1021.304[ms](mean) 1099.241[ms](mean) Timeperrequest[ms](mean,acrossallc o 937,9 510,65 274,81 Transferrate[Kbytes/sec]received 69,43 127,52 236,96 ConnectionTimes(ms) ConnectionTimes(ms) ConnectionTimes(ms) minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax minmean[+/‐sd]medianmax Connect 000.000000.201000.301 Processing 90793724.49341069 966102032.010161107 1043108531.710791221 Waiting 86589422.68921011 90795631.19501044 968100928.310051128 Total 90793724.49341069 966102032.010161107 1043108531.710791221 PercentageoftherequestsservedwithinacertaPercentageoftherequestsservedwithinacertaintiPercentageoftherequestsservedwithin a 50%934 50%1016 50%1079 66%946 66%1033 66%1094 75%949 75%1042 75%1104 80%951 80%1046 80%1110 90%957 90%1066 90%1127 95%968 95%1081 95%1152 98%1053 98%1105 98%1159 99%1069 99%1107 99%1221 100%1069(longestrequest) 100%1107(longestrequest) 100%1221(longestrequest)
vi.2 Fichero de configuración de MySQL (my.cnf) 112 #log-bin=mysql-bin # Point the following paths to different dedicated disks #tmpdir = /tmp/ #log-update = /path-to-dedicated-directory/hostname # Uncomment the following if you are using BDB tables #bdb_cache_size = 384M #bdb_max_lock = 100000 # Uncomment the following if you are using InnoDB tables #innodb_data_home_dir = /var/lib/mysql/ #innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend #innodb_log_group_home_dir = /var/lib/mysql/ #innodb_log_arch_dir = /var/lib/mysql/ # You can set .._buffer_pool_size up to 50 - 80 % # of RAM but beware of setting memory usage too high #innodb_buffer_pool_size = 384M #innodb_additional_mem_pool_size = 20M # Set .._log_file_size to 25 % of buffer pool size #innodb_log_file_size = 100M #innodb_log_buffer_size = 8M #innodb_flush_log_at_trx_commit = 1 #innodb_lock_wait_timeout = 50
vi.2 Fichero de configuración de MySQL (my.cnf) 113 [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash # Remove the next comment character if you are not familiar with SQL #safe-updates [isamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 8M write_buffer = 2M [myisamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 8M write_buffer = 2M [mysqlhotcopy]
vi.3 Fichero de configuración de Apache (/etc/httpd/conf/httpd.conf) 114 interactive-timeout VI.3 FICHERO DE CONFIGURACIÓN DE APACHE (/ETC/HTTPD/CONF/HTTPD.CONF) Soloadjuntamoslaspartesquehemostenidoqueirmodificandodelficherosegúnel tipodepruebaquerealizábamos,elrestoquedapordefecto. # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule prefork.c> StartServers 8 MinSpareServers 20 MaxSpareServers 20 ServerLimit 400 MaxClients 400 MaxRequestsPerChild 10000
vi.3 Fichero de configuración de Apache (/etc/httpd/conf/httpd.conf) 115 </IfModule> Hemosdebidomodificardurantelaspruebastantoelnúmeromáximodeclientes, debiendotambiénenalgunoscasosaumentarServerLimitpuessiempredebeser superioroigual.Porotroladohemosmodificadosegúnlapruebalosparámetros “StartServers”,“MinSpareServers”,“MaxSpareServers”contaldeoptimizarel rendimientodelaprueba.
vii 1 Ilustraciones 116 VII APÉNDICE VII 1 ILUSTRACIONES Ilustración 1 - Logo Proyecto Portales Municipales............................................... 8 Ilustración 2 - Logo Drupal....................................................................................11 Ilustración 3 - Aplicación Multientidad................................................................ 23 Ilustración 4 - Aplicación sin multientidad............................................................. 1 Ilustración 5 - Estructura directorios de Drupal 6 (1)........................................... 28 Ilustración 6 - Estructura de directorios de Drupal 6 (2) ...................................... 29 Ilustración 7 - Bases de datos independientes....................................................... 31 Ilustración 8 - Tablas independientes.................................................................... 33 Ilustración 9 - Tablas compartidas ........................................................................ 34 Ilustración 10 - Base de datos mixta..................................................................... 36 Ilustración 11 - Diagrama Aegir............................................................................ 39 Ilustración 12 - Logo de Aegir.............................................................................. 39 Ilustración 13 - Componentes de Aegir................................................................. 42 Ilustración 14 - Entidades presentes en Aegir....................................................... 45 Ilustración 15 - Menú superior Aegir.................................................................... 52 Ilustración 16 - Pantalla "Crear plataforma"......................................................... 52
vii 1 Ilustraciones 117 Ilustración 17 - Menú lateral Aegir....................................................................... 54 Ilustración 18 - Formulario nuevo sitio................................................................ 55 Ilustración 19 - Menú superior Aegir (2).............................................................. 55 Ilustración 20 - Pantallazo Aegir (Crear Sitio)...................................................... 56 Ilustración 21 - Página principal Aegir................................................................... 1 Ilustración 22 - Pantalla administración de un sitio en Aegir............................... 59 Ilustración 23 - Menú migrar................................................................................ 59 Ilustración 24 - Pantalla de confirmación............................................................. 60 Ilustración 25 - Cola de tareas Aegir..................................................................... 62 Ilustración 26 - Menú tareas.................................................................................. 63 Ilustración 27 - Resultado verificación de un sitio................................................ 64 Ilustración 28 - Menú tareas.................................................................................. 65 Ilustración 29 - Formulario para clonar un sitio ................................................... 66 Ilustración 30 - Benchmarking Intel Xeon E5504................................................ 73 Ilustración 31 - Benchmarking Intel Xeon X3220................................................ 73 Ilustración 32 - Benchmarking Intel Xeon 5160................................................... 74 Ilustración 33 - Diagrama de la Red de pruebas definitiva................................... 75 Ilustración 34 - Ejemplo de Plataforma VMWare vSphere vCenter 4.1............... 77 Ilustración 35 - Web de Pruebas del Ayuntamiento de Cheste (www.cheste.es) .. 80 Ilustración 36 - Datos de los resultados de los informes....................................... 83 Ilustración 37 - Mecanismo de funcionamiento de un sistema de Caché............. 85
118 Ilustración 38 - Formulario de configuración de la caché del core de Drupal...... 87 Ilustración 39 - Proceso de compilación de PHP.................................................. 88 Ilustración 40 - Mecanismo de funcionamiento de un acelerador de PHP........... 89 Ilustración 41 - Mecanismo de funcionamiento del módule Boost de Drupal...... 91 Ilustración 42 - Módulo de Drupal para aceleración de usuarios autenticados..... 93
vii 2 Tablas 119 VII 2 TABLAS Tabla 1 - Tabla de Hardware................................................................................. 70 Tabla 2 - Configuración Máquina Virtual del Servidor......................................... 71 Tabla 3 - Configuración Máquina de Pruebas....................................................... 72 Tabla 4 - Tabla rendimiento según el número de núcleos..................................... 94 Tabla 5 - Máximas peticiones concurrentes.......................................................... 95 Tabla 6 - Peticiones atendidas en una hora ........................................................... 96