IBM Lotus Domino, Linux, virtualización, escalabilidad: ya no son términos mutuamente excluyentes

¿Ya está cansado de hacer un ajuste forzado de IBM® Lotus® Domino® en su infraestructura? Con la última versión de 64 bits de Lotus Domino sobre Linux® y mediante la virtualización, ahora se pueden implementar entornos empresariales a gran escala con Lotus Domino sobre Linux en una sola superficie. El presente artículo documenta los bancos de pruebas que se han realizado y los resultados de los usuarios pioneros de esta solución, y le indica la manera de ajustar y hacer crecer su infraestructura con Lotus Domino.

Wu W Huang, Software Engineer, IBM

Wu W Huang es miembro del equipo Lotus Domino Performance y su orientación principal es System z. Comuníquese con Wu Huang a wuhuang@us.ibm.com.



Mike Wojton, IT 专家, IBM, Software Group

Mike Wojton es Analista informático técnico senior en el Washington Systems Center y su orientación principal es Lotus Domino sobre System z. Comuníquese con Mike a mwojton@us.ibm.com.



Armelle Chevé Creuzet , Lotus Domino on System z Sizings and Presales Support, IBM

Armelle Chevé Creuzet es miembro del Advanced Technical Support System z New Technology Center de Francia. Provee estudios de dimensionamiento y consolidación de IBM Lotus Domino sobre System z para Europa, Medio Oriente y África. Comuníquese con Armelle a armelle_creuzet@fr.ibm.com.



Richard Lewis, Senior Consulting I/T Specialist , IBM

Richard Lewis es Especialista informático de consultoría senior en el Washington Systems Center y su orientación principal es z/VM y Linux para System z. Comuníquese con Richard a rflewis@us.ibm.com.



05-05-2009

La palabra virtualización está de moda en la industria de la computación, y, como sucede con este tipo de palabras, es conveniente enfocarla con cuidado. Además de los beneficios que genera la virtualización, también pueden presentarse ciertos problemas inherentes a toda nueva tecnología. Este artículo demuestra que es posible implementar Lotus Domino en un entorno virtualizado (VM) con un huésped Linux y alcanzar un alto nivel de escalabilidad en un entorno de producción. Trataremos los resultados de bancos de pruebas recientes y un ejemplo de producción real que demuestra una gran escalabilidad de Lotus Domino en un entorno Linux virtualizado. Se presentarán los resultados de un banco de pruebas reciente en el que pudimos alcanzar 102 K usuarios de correo NRPC de Lotus Domino en un núcleo Linux activo en VM.

También trataremos las capacidades de algunos de los varios entornos virtualizados que existen actualmente en el mercado, así como los beneficios que estos pueden generar en Lotus Domino. Explotando estas nuevas capacidades, usted podrá rediseñar su entorno Lotus Domino y generar ahorros hoy mismo.

Virtualización y Lotus Domino: ¿cuál es la ventaja?

Los beneficios que se pueden obtener al ejecutar un entorno virtualizado dependerán de la tecnología de virtualización elegida. No todas las tecnologías de virtualización tienen las mismas capacidades ni producen los mismos beneficios. Si usted comprende las capacidades y los beneficios de su entorno, podrá evitar las limitaciones inherentes que posee cada una de estas tecnologías.

Por ejemplo, en el entorno actual, si se está ejecutando Lotus Domino en un hardware dedicado, y uno de los servidores se queda sin recursos, ¿qué debemos hacer? En primer lugar, debemos adquirir e instalar un nuevo hardware, lo cual puede demorar un tiempo. Luego debemos adquirir e instalar una nueva licencia de Lotus Domino. Más tarde debemos generar un nuevo servidor Lotus Domino. Por último, debemos migrar parte de la carga de trabajo del servidor con recursos limitados al nuevo servidor. Por el contrario, en un mundo virtual, solamente será necesario habilitar capacidad disponible o agregar más capacidad al hardware existente y reconfigurar las imágenes virtuales para los nuevos recursos. No hay necesidad de administrar y manipular los servidores Lotus Domino si los recursos son un límite. La virtualización permite que su infraestructura se adapte a las necesidades de su entorno Lotus Domino, y no que su entorno Lotus Domino se adapte a los límites de su infraestructura.

Otra ventaja del entorno virtual es la capacidad de reducir costos mediante la consolidación de servidores y las reducciones de infraestructura. La posibilidad de ampliar los nuevos recursos de manera dinámica en el mundo virtual permite diseñar un entorno Lotus Domino que explote estas capacidades. Por ejemplo, al ejecutar múltiples servidores Lotus Domino en una imagen única de Linux como huésped en VM, se puede eliminar la exigencia de contar con conexiones de hardware físico entre los servidores. Según el nivel de consolidación, será posible además reducir o eliminar la actual infraestructura de soporte que rodea los servidores físicos.

Reduciendo la complejidad del entorno Lotus Domino, usted podrá reducir el número de servidores necesarios para la ejecución. Esta reducción de la complejidad está directamente relacionada con una reducción de los costos de administración (instalación y actualización) y de soporte (procesos de determinación de problemas, rendimiento, capacidad) de su entorno. Como se puede apreciar, si usted sale de los esquemas tradicionales y no se limita a migrar imágenes existentes a su mundo virtual, los costos de ejecución de su infraestructura Lotus Domino se reducirán de manera significativa.

La figura 1 muestra un ejemplo de traslado de una infraestructura Lotus Domino física distribuida a una infraestructura Lotus Domino virtual centralizada.

Figura 1. Ejemplo de implementación de virtualización
Virtualization deployment example

En este ejemplo, pasamos de 18 sistemas de hardware, imágenes de sistema operativo y servidores de correo Lotus Domino a 6 servidores de correo Lotus Domino en 2 huéspedes Linux en una VM.

Esta implementación presupone que la VM y el hardware elegidos tienen la capacidad requerida para soportar esta carga de trabajo. Como los huéspedes Linux se ejecutan en la misma superficie física, pueden explotar tecnologías LAN virtuales (VLAN). Esta capacidad elimina la necesidad de contar con un servidor concentrador; además, VLAN permite que los servidores Lotus Domino se comuniquen entre sí a velocidades de memoria, y no a velocidades de LAN. Asimismo, mediante esta capacidad, ya no será necesario que una red troncal administre el tráfico de servidor a servidor (correo, clúster, replicación, administración).


Aviones, trenes y autos: la virtualización no siempre se crea de igual manera

Como indica el título de este apartado, existen diferentes medios de transporte, y cada uno de ellos tiene características únicas, como la velocidad, la capacidad y la distancia. De igual manera, en la actualidad existen diferentes formas de llevar a cabo la virtualización. Algunas veces esta se llevará a cabo en el hardware; otras, en el firmware; y otras, en el software. Además, es posible efectuar la virtualización mediante una combinación de estos métodos. La configuración dependerá de los productos de virtualización y del software, firmware y hardware de soporte elegidos.

Sin embargo, no todas estas tecnologías de virtualización abordan las mismas necesidades empresariales ni generan los mismos beneficios. Según la tecnología de virtualización utilizada y la manera de implementarla, podrán variar las características de rendimiento que ofrece este tipo de tecnología. Cuanto mayor sea la sobrecarga de una virtualización determinada, más recursos se necesitarán para ejecutar esa implementación.

La virtualización no es un concepto nuevo; por el contrario, existe desde hace más de 40 años. La virtualización fue presentada por primera vez como un producto en 1967 con CP-67. Los proveedores de esta tecnología tienen diferentes historias y experiencias, y una agitada actividad en los últimos años. IBM tiene más de 40 años de experiencia de mejoras en entornos virtuales.

Los diferentes aspectos de la virtualización pueden tener diferentes costos asociados. Por ejemplo, la capacidad de virtualizar subprocesos en un procesador puede tener un costo asociado diferente del costo de virtualizar la E/S. Esto significa que es necesario tener en cuenta todos los costos del entorno virtual, incluido el procesador, la memoria y la E/S, para poder apreciar el costo total que implica ejecutar ese entorno virtual. Como Lotus Domino puede causar un impacto significativo en los procesadores, la memoria y la E/S, según las características y funciones habilitadas, es necesario comprender cómo funcionan estos componentes para poder apreciar los costos de virtualización con Lotus Domino.

Como puede verse en la figura 2, existen diferentes métodos de implementar la virtualización en el servidor, entre los que se encuentran las particiones de hardware, el hipervisor nativo y el hipervisor alojado.

Figura 2. Enfoques de la virtualización básica de servidores
Basic server virtualization approaches

También es importante que el usuario comprenda cómo la virtualización genera la implementación del hipervisor. Como se demuestra en la figura 3, todas las implementaciones tienen sus beneficios y sus problemas.

Figura 3. Métodos de implementación del hipervisor
Hypervisor implementation methods

Al comprender cómo se implementa la virtualización, usted podrá hacer una mejor explotación de sus capacidades. El Libro Rojo de IBM "IBM Systems Virtualization: Servers, Storage, and Software", publicado en abril de 2008 (REDP-4396), brinda una descripción detallada de las diferentes tecnologías de virtualización, así como de sus beneficios y sus problemas.


102 K usuarios de Lotus Domino en un núcleo único Linux en VM

En el cuarto trimestre de 2008 se lanzó una versión nativa de 64 bits de Lotus Domino para Linux. Se creó un banco de pruebas con dos objetivos:

  • Establecer el impacto de la escalabilidad de Lotus Domino en un servidor único de partición Lotus Domino cuando se utiliza el nuevo código nativo de 64 bits, en comparación con el antiguo código de 32 bits.
  • Establecer hasta qué punto se puede insertar un núcleo Linux virtualizado en un entorno de sistema operativo de 64 bits que ejecuta Lotus Domino en VM.

El banco de pruebas se realizó en el Washington System Center, en Gaithersburg, Maryland, y se utilizó un sistema z10 EC 2097-764. Este sistema tenía 64 procesadores generales (sin incluir los procesadores de E/S, repuestos, etc.) y 1,52 TB de memoria. Solamente una porción de este sistema fue asignada al banco de pruebas. Se generó una partición lógica (LPAR) en el sistema con una configuración inicial de 4 procesadores y 48 GB de memoria. En esta LPAR generamos una imagen del sistema operativo VM y después un núcleo Linux en VM, con acceso a los cuatro motores y 10 GB de memoria. En esta configuración inicial de 4 procesadores centrales (CP) o motores y 10 GB se ejecutarían las pruebas iniciales del servidor único de partición Lotus Domino.

Debe tenerse en cuenta que este sistema no estaba dedicado a este banco de pruebas para Lotus Domino, sino que además ejecutaba otras cargas de trabajo de manera simultánea. Aparte del banco de pruebas de Lotus Domino, se estaban ejecutando otros dos bancos de pruebas al mismo tiempo y en el mismo hardware físico. Uno de estos bancos de pruebas se realizaba para un cliente del sector de seguros; el otro era para un cliente del sector bancario. Cada uno de estos bancos de prueba tenía su propia LPAR y virtualización dentro del mismo hardware físico. Además de estas cargas de trabajo, también se ejecutaban en el sistema otras LPAR más pequeñas.

El dispositivo de almacenamiento de acceso directo (DASD) total vinculado a este sistema físico, a través de sus diversos canales de fibra, superaba ampliamente los 200 TB. Con relación a la carga de trabajo de Lotus Domino, terminamos con unos 20 TB de DASD vinculados a este núcleo Linux, definidos como dispositivos de datos de clave de recuento extendidos (ECKD). Muchas veces surge la pregunta respecto de si es conveniente usar números de unidad lógica (LUN) SCSI vinculados al Protocolo Fibre Channel (FCP) o DASD ECKD. Las dos opciones tienen pros y contras. El uso más eficaz de los LUN SCSI vinculados a FCP en el entorno Linux se verifica mediante subcanales FCP dedicados y no mediante dispositivos emulados z/VM®.

En este caso, la pila SCSI de Linux se utiliza para administrar, leer y escribir datos en los LUN de destino. El inconveniente de esta configuración es que los dispositivos de disco de destino no son visibles desde el entorno del Sistema de supervisión conversacional (CMS), por lo que no se pueden utilizar herramientas y procesos z/VM para ayudar a administrar estos dispositivos. Al ser solamente visibles desde adentro del entorno Linux, deben administrarse desde adentro de ese contexto. Estudios de rendimiento realizados por el IBM Boeblingen Lab indican que la utilización de LUN SCSI y subcanales FCP dedicados trae aparejado un mayor rendimiento en función de la cantidad de megabytes transferidos por segundo. Asimismo, esta solución tiende a producir la menor sobrecarga del procesador desde una perspectiva z/VM ya que es posible utilizar hardware qioassist (disponible para z9® y z10) porque el proceso de E/S se basa en qdio en vez de iniciar subcanal. Para obtener una descripción más detallada de qdio, consulte el documento “Queued Direct I/O (QDIO)” en la parte de referencia.

El inconveniente que presenta esta solución es que el subsistema de canal de System z® no provee un soporte automático de múltiples rutas a los dispositivos de almacenamiento de destino. Todas las opciones de múltiples rutas deben efectuarse definiendo manualmente una configuración de múltiples rutas dentro de Linux y utilizando el soporte de asignado de dispositivos para la configuración de múltiples rutas.

La ventaja de utilizar dispositivos DASD ECKD es que son visibles desde el entorno CMS z/VM y, por lo tanto, pueden administrarse fácilmente desde un entorno de programación de sistemas z/VM típico. Un beneficio adicional es que la administración de múltiples rutas hacia el subsistema de almacenamiento de destino está incluida íntegramente en el subsistema de canal del hardware y no requiere ninguna intervención manual por parte de Linux. El problema es que la arquitectura de E/S de System z especifica que solo puede estar activa una operación de E/S en cualquier momento en un dispositivo de destino determinado (UCB o subcanal DASD). Esta restricción puede salvarse utilizando volúmenes de acceso paralelo (PAV). Con el nuevo soporte disponible en las últimas versiones del driver DASD de Linux y mediante la función DS8300 hyperpav, usted podrá usar PAV con Linux sobre System z de una manera eficaz y alcanzar tasas de rendimiento similares a las del entorno FCP dedicado que se menciona anteriormente.

Nuestro entorno constaba de dispositivos ECKD asignados como dispositivos 3390 modelo 27. Utilizamos dispositivos ECKD porque, a diferencia del entorno SCSI FCP, son de fácil disponibilidad.

Para el primer conjunto de pruebas, le dimos a Lotus Domino 4 segundos de CP y 10 GB de memoria para establecer la línea de base para ejecutar un servidor único Lotus Domino en un huésped Linux. En esta serie de pruebas insertamos esta instancia de Lotus Domino hasta donde fue posible antes que se produjera un bloqueo. Este método nos permitió escalar hacia arriba esta instancia de Lotus Domino y comprobar hasta dónde podía llegar con recursos ilimitados. Como queríamos comparar bancos de pruebas de versiones anteriores, reconstruimos sus entornos, configuraciones y cargas de trabajo. Esta fue la definición básica del banco de pruebas:

  • Sin registro de transacciones
  • Cargas de trabajo R6Mail
  • Un servidor Lotus Domino en un huésped Linux en VM

La carga de trabajo R6Mail se simula utilizando operaciones de correo y de calendario desde el cliente Lotus Notes hasta las acciones del servidor. Envía 4,67 mensajes por usuario por hora. Para obtener más información acerca de esta carga de trabajo, consulte el artículo de developerWorks®: "The new Domino 6 Notesbench workloads: Heavier by request!".

Como puede verse en la figura 4, pudimos alcanzar de 19 a 20 K usuarios de referencia en una instancia única de Lotus Domino antes del error.

Figura 4. Usuarios conectados/activos por 15 minutos durante prueba de servidor único de partición Domino (DPAR)
Connected/active 15-minute users during a single Domino PARrtition (DPAR) server test

Como puede verse en la figura 5, para estas mediciones empleamos segundos de CP utilizados en lugar de tasas de ocupación del procesador.

Figura 5. Segundos de CP utilizados durante prueba de DPAR única
CP seconds used during a single DPAR test

La tasa de ocupación del procesador es un cálculo del recurso utilizado (segundos de CP) dividido por el recurso disponible. Históricamente, este cálculo se efectuaba con un numerador aleatorio (uso de segundos de CP) dividido por un denominador estático (recurso de procesador físico disponible). Dado que la mitad de esta ecuación era estática y cambiaba solo cuando una unidad se actualizaba o se remplazaba, la tasa de ocupación del procesador era un buen indicador de los recursos utilizados. En el mundo virtual, sin embargo, el denominador también puede constituir un valor aleatorio.

Hace ya más de cinco años que el número de procesadores en un entorno virtual determinado puede cambiar cada 10 segundos en un hardware empresarial de gran tamaño. Con estas configuraciones, el número de procesadores disponibles en las mediciones es en la actualidad un número fraccionario, ya que en cualquier intervalo de un minuto puede cambiar muchas veces. Por ejemplo, el número de procesadores en un minuto determinado puede ser de 4,5 y pasar en el minuto siguiente a 5,166. Esta variación implica que la tasa de ocupación del procesador tiene un denominador aleatorio y un numerador aleatorio, por lo que este valor es de poca utilidad en un mundo virtual de producción. Al medir los segundos de CP, se puede saber la cantidad de recursos de procesador que utiliza el entorno, pero no la cantidad disponible en un entorno virtual que puede cambiar de manera constante.

En nuestras mediciones utilizamos un intervalo de recolección de 10 minutos. Este intervalo supone que en 600 segundos de CP (10 minutos x 60 segundos), se utiliza el equivalente de un motor completo de capacidad de procesador.

Otra desventaja que presenta el mundo virtual es que la tasa de ocupación del procesador puede inducir a error en cuanto a la capacidad restante. Si usted tiene un sistema con dos procesadores físicos y define dos imágenes de sistema operativo con dos procesadores lógicos cada una, esta configuración dará un total de cuatro procesadores lógicos. Si las dos imágenes de sistema operativo son tratadas y gestionadas de igual manera por la tecnología de virtualización, cuando las dos imágenes tengan una tasa de ocupación de procesador del 50 %, la ocupación del sistema físico será del 100 % y ya no habrá capacidad restante. Al comprender el número de recursos (segundos de CP) que utiliza, en lugar de un porcentaje de un número de capacidad virtual, usted se encontrará en una mejor posición para gestionar y supervisar su entorno.

Además de evaluar los recursos utilizados, estudiamos el costo de ejecución de los usuarios de referencia. En la figura 6 puede verse el costo de procesador de los usuarios activos durante 15 minutos de Lotus Domino. Esta representación se obtiene dividiendo el número de segundos de procesador utilizados por la instancia de servidor Lotus Domino por el número de usuarios activos de cada período de muestra.

Figura 6. Costo de procesador por usuario activo durante 15 minutos
Processor cost per active 15-minute user

La figura 6 muestra una tendencia que, si bien estaba prevista, no deja de ser interesante. El mayor costo por usuario se da al comienzo del banco de pruebas. Al estar los usuarios iniciando sesión y validando su autorización, la sobrecarga de procesamiento se asocia con este elevado costo. Por ejemplo, si se reinicia un servidor en medio de un turno con mucho trabajo, será necesario preparar recursos de procesador adicionales para el momento en que todos los usuarios se vuelvan a conectar al servidor. El costo real en estado estable es menor una vez que los usuarios se hayan autenticado con el servidor y hayan establecido las correspondientes sesiones de comunicación.

Por este motivo, es habitual que los bancos de prueba vuelvan a escalar el tiempo de carga del último grupo de usuarios si estos llevan el procesador al máximo, así como que dejen pasar un tiempo razonable antes de medir el estado estable. También, puede observarse que el costo por usuario se disparó al final de la ejecución, antes que se produjera el error del servidor, lo cual indica que el servidor ya empezaba a sobrecargarse incluso antes del error. Al consistir esta prueba en una única ejecución DPAR con todo el correo entregado de manera local, consideramos que el costo por usuario aumentaría si se utilizaran múltiples DPAR y hubiera que entregar tanto correo local como remoto.

Uno de los cuatro objetivos de este banco de pruebas era determinar si era posible superar 100 K usuarios de referencia en un huésped Linux. Sobre la base de las pruebas de servidor único de partición Lotus Domino, calculamos que sería necesario ejecutar 17 K usuarios de referencia en cada uno de los seis servidores de partición Lotus Domino en un huésped Linux. Se agregaron cinco servidores de partición Lotus Domino para darle a este huésped Linux seis servidores de partición Lotus Domino. Además, se agregaron cuatro CP, se llevó la memoria a 26 GB, y se incorporaron nuevos DASD para soportar la carga de usuarios completa.

A cada DPAR se le asignó su propio directorio notesdata y cuatro directorios únicos de correo en la ruta /notesdatax/mail. Se distribuyeron los DASD para los buzones de correo entre estos puntos de montaje. Se definió cada servidor de partición Lotus Domino de manera que se ejecute en una de usuario separada y a cada uno se le asignó una dirección IP única. Como todos estos servidores de partición Lotus Domino residían en la misma superficie física, pudimos utilizar VLAN y transferir datos entre los servidores de partición Lotus Domino a velocidades de memoria (transferencia de búfer TCP/IP a búfer TCP/IP) sin necesidad de enviar el tráfico de servidor a servidor a una red troncal física.

Nuestra primera prueba de 100 K se definió de manera de alcanzar 60 K a la misma tasa que la prueba de servidor único y luego ir disminuyendo la cantidad de usuarios que se agregaban. Sin embargo, al llegar a 50 K usuarios, empezamos a observar problemas con la ejecución. El correo comenzó a acumularse, y los tiempos de respuesta del cliente comenzaron a alargarse. Al analizar los datos de Lotus Domino y de la plataforma, detectamos un cuello de botella de E/S. Mientras que los tiempos de respuesta del DS8000® y la VM eran menores de 2 MS, observamos que los tiempos de respuesta del núcleo Linux eran superiores a 80 MS.

Durante la investigación de este problema, efectuamos diversas pruebas para determinar si era posible sortear este cuello de botella de E/S. A lo largo de varias ejecuciones de pruebas, realizamos las siguientes acciones:

  • Reducción de la cantidad de datos escritos en log.nsf
  • Aumento de la memoria del huésped Linux hasta 48 GB
  • Aumento del tamaño del NSF_Buffer_Pool
  • Traslado de mail.box(es) (cada DPAR tenía seis) a un disco RAM
  • Traslado de names.nsf a un disco RAM
  • Traslado de log.nsf a un disco RAM
  • Traslado de mail.box(es), log.nsf y names.nsf a un disco RAM
  • Cambio de número de mail.box(es)
  • Cambio de número de subprocesos en la tarea de servidor
  • Cambio de número de subprocesos en la tarea de router para la entrega local y remota de correo
  • Actualización del servidor Lotus Domino al código GA nivel dorado
  • Configuración Mail Leave Sessions Open=1

Si bien ninguno de estos cambios solucionó los problemas del cuello de botella y de escalabilidad que se presentaron, la configuración del parámetro notes.ini MailLeaveSessionsOpen en 1 marcó una diferencia apreciable en los recursos de procesador utilizados. Observamos que el costo de procesador por usuario activo durante 15 minutos pasó de 0,07 a 0,05 segundos de procesador, lo cual implica una reducción aproximada de un 28% en la ejecución de las mismas cargas de trabajo. Este parámetro le ordena a Lotus Domino dejar abierta la sesión para entregar correo entre los diversos servidores. Antes de configurar este parámetro, Lotus Domino debía establecer una sesión a un servidor de correo hacia el cual se estuviera transfiriendo un mensaje, autenticar, enviar el mensaje y abandonar la sesión. Al dejar la sesión abierta, Lotus Domino pudo reutilizar las sesiones existentes en lugar de restablecerlas constantemente.

Finalmente se determinó que el problema de E/S se debía, por un lado, a la manera en que los volúmenes ECKD eran soportados en Linux y, por el otro, a la manera en que se ponían en cola las solicitudes a nivel de dispositivo lógico. Actualmente existe la entrega de una corrección para los volúmenes de acceso paralelo (PAV) en SLES 11, pero esta corrección no estaba disponible para su utilización al momento de la realización del banco de pruebas. Se reconfiguró el subsistema de E/S de manera de dividir los volúmenes en drives lógicos más pequeños (3 GB), creando más drives lógicos con la misma cantidad de DASD. Esta configuración nos permitió contar con más drives lógicos para Linux, por lo que pudimos expandir la E/S a los mismos sistemas DS8000.

Después de reconfigurar el DASD, pudimos escalar a unos 85 K usuarios antes de quedarnos sin capacidad en los ocho CP. Agregamos cuatro nuevos CP para que nuestra VM y el huésped Linux tuvieran hasta 12 CP para las siguientes ejecuciones. El huésped virtual y los servidores Lotus Domino reciben un incremento del 50% en el número de CP disponibles sin necesidad de reconstruir, redistribuir o realizar cambios en Lotus Domino para tener capacidad adicional.

Con esta capacidad adicional pudimos alcanzar un estado estable de 17 K usuarios en cada una de las seis DPAR para un estado estable total de 102 K usuarios en un huésped Linux que se ejecutaba en VM. En la figura 7 se puede observar el número de usuarios activos durante 15 minutos y de usuarios conectados de cada una de estas ejecuciones.

Figura 7. Número de usuarios durante la ejecución de 102 K
User count during the 102K run

Durante el estado estable de la ejecución, obtuvimos un promedio aproximado de 1,5 millones de transacciones Lotus Domino cada 10 minutos durante la prueba, o de 9 millones de transacciones Lotus Domino por hora, como indica la figura 8.

Figura 8. Tasas de transacciones Lotus Domino
Lotus Domino transaction rates

Durante estas ejecuciones, la carga de trabajo total de E/S en este huésped Linux único alcanzó su nivel máximo de menos de 27 K E/S por segundo. Pudimos alcanzar un promedio de tiempo de respuesta menor de 2 ms en el DS8000s, la VM y el núcleo Linux. Durante estas ejecuciones, las restantes cargas de trabajo mencionadas se encontraban activas en este mismo servidor, por lo que el número total de E/S por segundo en este servidor era mucho mayor que los 27 K de la carga de trabajo de Lotus Domino.

Durante las diversas ejecuciones con diferentes números de usuarios, el costo de procesador por usuario permaneció estable hasta que se alcanzó la marca de 80 K usuarios. En este punto, el costo por usuario comenzó a crecer cuando se agregaron los últimos 20 K usuarios. Este crecimiento no se observó en la prueba de DPAR única de 17 K usuarios, ni en la prueba de 51 K usuarios que se documenta en el siguiente apartado, en la que se ejecutaron múltiples servidores Lotus Domino con 17 K usuarios. Aparentemente, este crecimiento en el costo de procesador por usuario se relaciona con la sobrecarga en el propio núcleo Linux.

En este banco de pruebas, así como en otras mediciones, observamos una sobrecarga aproximada del 10% para el primer huésped en VM. Además, existe una sobrecarga de 1-2% por cada huésped VM adicional (no para el servidor de partición Lotus Domino). Esta sobrecarga del 10% dividida en las seis instancias del servidor Lotus Domino implica que para esta configuración se ejecutó una sobrecarga aproximada del 2% para cada servidor Lotus Domino en el ambiente virtual de este banco de pruebas. Sin embargo, debe tenerse en cuenta que no todas las plataformas y tecnologías de virtualización pueden alcanzar este nivel de escalabilidad, rendimiento y escasa sobrecarga en una única superficie física. Por lo tanto, estas cifras no deben utilizarse para implementaciones virtuales Lotus Domino diferentes a la descripta en este artículo.


Escalabilidad Vertical y horizontal

Si usted desea migrar a un entorno virtual para su infraestructura Lotus Domino, es importante analizar su actual infraestructura. La manera más rápida y sencilla es mover los servidores Lotus Domino existentes a su nuevo entorno. Por lo general, este enfoque no permite explotar o utilizar de manera completa el nuevo entorno virtual. Una de las mediciones que se efectuaron consistía en determinar cuál era la diferencia al ejecutar una determinada carga de trabajo en dos configuraciones diferentes. Para medir esta diferencia ejecutamos cargas de trabajo idénticas en las mismas configuraciones con una diferencia: el número de servidores de partición Lotus Domino.

En el primer caso, ejecutamos un banco de pruebas de 51 K usuarios en tres DPAR y determinamos el costo por usuario. Después ejecutamos el mismo banco de pruebas en seis DPAR con la misma configuración virtual y volvimos a determinar el costo por usuario. La figura 9 muestra los resultados de estas pruebas.

Figura 9. Comparación de los costos de procesador por usuario
Comparison of processor costs per user

Como puede observarse, el costo de procesador fue un 20% menor por usuario cuando se consolidó la carga de trabajo en un número menor de servidores de partición Lotus Domino. También se han observado este tipo de reducciones en entornos de clientes y de producción de IBM cuando se pudo efectuar una consolidación de servidores. Si la infraestructura Lotus Domino se escala verticalmente (ver, p. ej., la figura 1), no solo se ahorran recursos para ejecutar ese entorno, sino que también se ahorran costos de administración al existir menos servidores que hay que administrar, actualizar y soportar.

La clave para una explotación completa de los beneficios virtuales es contar con una implementación física /virtual que permita incorporar recursos a su entorno para crecer de manera vertical sin necesidad de reconstruir el entorno de manera horizontal.


No solo en los bancos de prueba, sino también en la realidad

Usted debe estar pensando: "Todo esto suena bien, pero ¿cómo se aplica a la producción?". IBM ya ha trabajado con un cliente en la migración de 14 K usuarios de producción a dos núcleos Linux. Cada huésped Linux en VM soporta unos 8 TB de DASD. Existen aproximadamente 7 K usuarios de producción en cada uno de los núcleos, y cada huésped ejecuta múltiples DPAR. Además de los servidores de correo, existen servidores de nombre y un servidor administrativo dentro de estos huéspedes Linux para un total de cuatro DPAR en cada huésped. Esta configuración fue realizada con Lotus Domino 7 antes del advenimiento del código de 64 bits Lotus Domino versión 8.5 que actualmente permite una mayor consolidación de servidores. Este cliente experimentó una reducción del número de las instancias Lotus Domino que administraba en su configuración de infraestructura.

No solo los clientes están implementando Lotus Domino sobre Linux en entornos de larga escala, sino que también lo hace IBM. Esta empresa se encuentra en la actualidad en un proceso de traslado de sus cargas de trabajo de producción a Lotus Domino sobre Linux para System z. El documento "Consolidation of Lotus Domino and Lotus Notes to Linux on System z" es un resumen de la actividad que ya ha tenido lugar durante esta migración. El documento incluye una descripción de la mudanza de 103 sistemas de hardware con 35.100 aplicaciones Lotus Domino a Lotus Domino sobre Linux para System z. Usted podrá consultar más documentos cuando este trabajo se extienda al entorno de correo.


Salir de los esquemas tradicionales con la virtualización

Como ya hemos analizado, una de las ventajas que tiene la virtualización es su capacidad de extender la infraestructura de manera dinámica para soportar el entorno Lotus Domino. Esta ventaja, junto con la capacidad del hardware empresarial de cambiar dinámicamente e incrementar su configuración al instante, puede llevarlo a descubrir nuevas y diferentes maneras de ejecutar su entorno Lotus Domino.

En la actualidad, la mayoría de los clientes que utilizan clústeres ejecutan una configuración activa/activa. Esta configuración supone que la carga de trabajo se encuentra equilibrada en ambos lados del clúster y que los recursos se utilizan de un modo igualitario. La otra manera de ejecutar el clúster Lotus Domino es a través de una configuración activa/pasiva, en la cual toda la carga de trabajo se encuentra del lado activo del clúster y solo la carga de trabajo necesaria para mantener la sincronización se encuentra del lado pasivo. La principal desventaja de esta configuración es que uno de los servidores parece estar vacío porque está ahí "por las dudas".

El inconveniente que tiene la configuración activa/activa es que la carga de trabajo total es la suma de las dos mitades. En caso de error, toda la carga de trabajo de un lado se desplaza hacia el otro lado. Si bien la mayoría de las configuraciones tienen el tamaño adecuado en un comienzo, con el tiempo ambos lados del clúster se incrementan. ¿Está seguro de que toda la carga sigue entrando en uno de los lados del clúster? ¿Ha deshabilitado la mitad del clúster durante el turno principal para validar que la carga de trabajo siga entrando? Además, no todos los cuellos de botella son cuellos de botella del procesador... ¿usted cuenta con el ancho de banda de E/S y de red para soportar las cargas de trabajo máximas de conmutación por error? Si usted no prueba y valida los clústeres durante las cargas máximas, cuando se produzca un error, el lado de conmutación por error puede verse restringido y entregar tiempos de respuesta insuficientes o incluso fallar.

En el mundo virtual, es posible ejecutar el clúster Lotus Domino activo/pasivo y conocer qué recursos se requieren para ejecutar toda la carga de trabajo de un lado porque esta ya está de un lado del clúster. En el mundo virtual, existen diversas opciones con respecto al lado pasivo. El usuario puede reutilizar los recursos del lado pasivo para las cargas de trabajo de prioridad inferior (prueba, desarrollo y otras cargas de trabajo ajenas a Lotus Domino) que está dispuesto a sacrificar durante un error. También puede recurrir a una solución de capacidad a petición. Esta clase de solución permite prever el error de un porcentaje de su población (errores de servidores individuales), activando la capacidad adicional restante en caso de error total. La ventaja de una solución de capacidad a petición es que ya no es necesario adquirir el 100% del hardware pasivo hasta su uso. La elección de reutilizar los recursos o adquirirlos cuando fuera necesario está en sus manos, pero ya no necesitará contar con la capacidad de reserva "por las dudas".


Conclusión

No todas las tecnologías de virtualización generan los mismos beneficios ni tienen los mismos costos. Algunas tecnologías de virtualización (como la que ejecutamos) existen desde hace más de 40 años y presentan numerosas mejoras. IBM ejecuta Lotus Domino en entornos virtuales desde Lotus Domino 4.5.1 y ha consolidado la mayoría de sus servidores de aplicaciones Lotus Domino en Linux para System z en VM. También ha anunciado planes de migración de su servidor de correo a este entorno.

Si bien el entorno que utilizamos en el banco de pruebas de este artículo tiene una sobrecarga acumulativa menor de 2% para cada instancia de servidor Lotus Domino, este banco de pruebas no es el habitual en la mayoría de las tecnologías de virtualización. El conocimiento de su entorno virtual resulta fundamental para generar una implementación virtual exitosa. Además, los bajos costos asociados a la capacidad de virtualizar las cantidades masivas de E/S de estos ejemplos (banco de pruebas y producción) pueden permitir obtener una escalabilidad vertical y generar ahorros.

La virtualización de su entorno Lotus Domino puede ayudarlo de manera considerable a simplificar y reducir el costo total de propiedad (TCO). Si bien el traslado de los servidores existentes puede generar ahorros, los verdaderos ahorros derivan de la posibilidad de consolidar sus servidores (reducir la complejidad de su entorno) para alcanzar una escalabilidad vertical. Asimismo, se pueden obtener ahorros en los costos de administración y gestión perfeccionando su entorno y reduciendo la complejidad (menos servidores Lotus Domino para administrar, actualizar y soportar) de su implementación Lotus Domino. Finalmente, la posibilidad de que su infraestructura se ajuste a Lotus Domino, y no que Lotus Domino se ajuste a su infraestructura, puede reducir su TCO y brindarle la capacidad de reaccionar más rápidamente y con mayor flexibilidad frente a las necesidades de su empresa.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Lotus, Rational
ArticleID=392072
ArticleTitle=IBM Lotus Domino, Linux, virtualización, escalabilidad: ya no son términos mutuamente excluyentes
publish-date=05052009