Cambio de disco en una cabina de discos HP Modular Smart Array (MSA 2000)

No es la primera vez, ni será la última. Puedes gastarte un dineral en comprar los dispositivos más fiables del mercado, intentar que las condiciones de funcionamiento sean las mejores (UPS, refrigeración, etc) pero al final sabes que se romperán.

Los administradores de sistemas tenemos la obligación de ser paranoicos dentro de las posibilidades económicas de la empresa y las de que nuestra salud mental, por eso en cada intervención delicada en uno de nuestros sistemas debemos, al menos:

1. Ponernos al día sobre la actuación leyendo el material recomendado por el fabricante, foros explicando procedimientos similares
2. Documentar el estado actual del sistema, para poder reproducirlo después del cambio: versiones del software, opciones de configuración más importantes, etc
3. Ensayar la actuación en un sistema de pre-producción
4. Hacer copias de seguridad
5. Si es posible tener un sistema "gemelo" montado aunque sea en máquinas menos potentes o virtuales para usar como "plan B" en caso de que las cosas se compliquen
6. Hacer copias de seguridad... ¿Lo he puesto antes? Da igual, no está de más decirlo otra vez

Presento el sistema. Matriz de discos HP MSA Modular:

Los sistemas de gama empresarial normalmente sintonizan con nuestra paranoia. Algo tan aparentemente leve como que uno de los discos tarde un poco más en girar (spin-up time) o se detecte alguna anomalía eléctrica hace que se disparen las alarmas y el disco pase a ser "no confiable". Ahora entran en juego dos conceptos muy importantes en sistemas de este tipo.

RAID y SPARE

• RAID. Algunas configuraciones de RAID son tolerantes a fallos, de manera que aunque perdemos espacio de almacenamiento ganamos seguridad. Por ejemplo, un conjunto de discos configurados en RAID 5 utiliza el espacio de almacenamiento de un disco como espacio de redundancia, de manera que si perdemos un disco, no se pierden datos. Se puede sustituir por otro disco y el sistema reconstruirá el conjunto.
• Discos SPARE (hotspare) o "discos reserva". Además podemos definir dentro de la cabina discos que no se utilizan, pero están preparados para sustituir a otro que falle inmediatamente, sin intervención nuestra.

En sistemas de este nivel SIEMPRE se utiliza algún sistema de redundancia que variará para maximizar la seguridad, la velocidad de escritura, la velocidad de lectura, etc.,  y, por supuesto, discos spare.

Por ejemplo, los sistemas RAID 1 (mirror) acelera las lecturas ya que se puede leer de dos discos al mismo tiempo, en cambio, la escritura lleva un tiempo similar a sistemas de disco único. Usamos la mitad de la capacidad total en datos de redundancia. Aquí somos tolerantes a fallos siempre que el disco o discos se encuentren en el mismo conjunto del espejo.

Otros niveles de RAID, como RAID5, hacen que se pierda menos espacio. Si tenemos n discos, el espacio total será el de n-1 discos ya que uno se usa como disco redundante. Aquí no se gana tanto rendimiento de lectura como en RAID1 pero aún así, bajo ciertas circunstancias, se acelera la lectura respecto a sistemas de disco único. La escritura se ve penalizada al tener que calcular el contenido del bloque de paridad, que ya no es un proceso tan inmediato como hacer una copia del bloque en otro disco. Este nivel RAID tolera fallos en un sólo disco. RAID6, es similar a RAID5, pero usa dos discos para redundancia, por lo que se tiene tolerancia a fallos en dos discos.

Las combinaciones de niveles RAID están permitidas. Es decir, se puede hacer RAID5+0.

Frío y Calor

Hay sistemas capaces de implementar RAID en software, pero lo interesante es tener una controladora de discos que lo soporte en hardware y así hacerlo menos dependiente del sistema operativo. Éste es el caso de las controladoras de discos que estamos viendo.

Suponiendo una configuración RAID5 con spare, en el momento que falle un disco, la cabina lo detecta, lo tacha como "no confiable" y usa el disco spare como nuevo disco en el conjunto RAID. Este proceso puede hacerse en frío, si necesitamos reiniciar el sistema o dar la orden de resconstrucción y esperar el tiempo necesario para que se reconstruya; o en caliente, si la controladora es capaz de seguir dando servicio mientras el disco spare se reconstruye y además no necesita que intervengamos en el proceso.

Rompiendo un disco

Lo que voy a hacer es reproducir el proceso de sustitución de un disco en fallo en una cabina en la que todos los discos están bien. Extraeré uno de los discos del array para simular en fallo. 

Primero vamos a ver el estado de la cabina:

En la imagen vemos que hay ocho discos, siete forman un conjunto RAID6 y uno de ellos configurado como SPARE. Podrían romperse dos discos del conjunto RAID6 y aún no perderíamos datos. Además, como veremos, en el momento que falle uno de ellos el disco SPARE intentará sustituirlo.

Otra vista, pero esta vez voy a insertar un disco nuevo en la cabina. Como no hemos dicho para qué debe utilizar ese nuevo disco lo define como "disponible". Este disco no se utilizará para nada hasta que no se defina su función de forma explícita. Vemos el disco spare (VDISKSP).

Sacamos un disco y a ver que pasa.

Reconstrucción de un VDISK (RAID 6)

Si pinchamos en el estado de la MSA vemos que ha empezado a reconstruir el RAID6 inmediatamente. El proceso tardará unas horas dependiendo del tamaño del VDISK, la configuración RAID y el grado de utilización de los datos de la cabina mientras se hace la reconstrucción ya que la cabina seguirá activa para lectura y escritura.

En la figura anterior tenemos varios campos relacionados con la salud (health). Vemos que la cabina está degradada aunque aún es tolerante a fallos. En la parte inferior vemos en current job que el disco se está reconstruyendo.

En el esquema gráfico de la cabina se puede ver que hemos vuelto "pinchar" el disco en su lugar. La MSA sabe qué disco es, sabe que ha estado pinchado con anterioridad y por algún motivo ha fallado, así que lo marca como LEFTOVR (descartado). No usará este disco más a no ser que la "hagamos olvidar".

Una vez reconstruido el disco tenemos esta estructura.

El disco 1.8 que antes estaba como SPARE pasa a formar parte del VDISK.

Ahora para recuperar el disco que hemos sacado debemos borrar sus metadatos. Esto se puede hacer desde la opción clear disk metadata, como vemos en la imagen siguiente.

Borrando los metadatos el disco volverá a estar disponible (AVAIL). Por último modificamos los discos SPARE de la MSA para incluir estos discos disponibles no usados.

En el menú provisioning la opción Manage Global Spares donde podemos definir los discos que se podrán usar como SPARE en cualquier VDISK de la MSA. También podríamos definir discos SPARE reservados para un VDISK determinado.

Este sería el estado final donde se ve el primer disco que retiramos de la cabina como Global Spare. Y el VDISK totalmente reconstruido.

Todo correcto :D

Load Testing Moodle con Jmeter

Jmeter es una herramienta muy útil para hacer test de carga de distintas aplicaciones. Es tan flexible puede servir para poner a prueba tanto una aplicación web, como un servidor de base de datos o incluso un servicio tipo SOAP.

La potencia de Jmeter radica en la capacidad para simular la actividad de usuarios o las peticiones a un determinado servicio o aplicación, de forma concurrente. Estas pruebas nos pueden ayudar en el dimensionamiento del servidor, posibles fallos o problemas derivados de la concurrencia, etc.

Otra característica muy interesante de la herramienta es que puede "grabar" la actividad del navegador para después lanzar una determinada cantidad de usuarios o "hebras" que ejecuten esta misma actividad. Esto se realiza creando un proxy en jmeter al que debemos apuntar nuestro navegador. Jmeter se encargará de ir almacenando todas las peticiones que se realicen. Para encontrar más información podéis buscar "jmeter proxy record" o términos similares.

Obviamente cualquier prueba de carga nunca debería ser ejecutada en un servicio/servidor de producción.

Para ponerse al día con la herramienta lo mejor es pasar por su documentación y buscar algún ejemplo en concreto e ir modificándolo para adaptarlo a nuestras necesidades. Esto mismo es lo que he hecho yo, basándome en un plan de pruebas existente en los foros de moodle.org (todos los agradecimientos a su autor). A partir de este plan de pruebas he ido parametrizando algunos procedimientos y adaptando su funcionamiento a los cambios de Moodle v2.5.

Las tareas que he incluido en el plan son:

• Abrir la página principal de Moodle
• Login en Moodle
• Entrar en el curso
• Acciones del usuario en orden aleatorio:
• Actividad de texto
• Mensaje en el chat
• Mensaje en el foro y contestar a un mensaje en el foro
• Subir un fichero a archivos privados
• Enviar un fichero a una actividad (implica subir fichero)
• Salir de Moodle

Peticiones y respuestas

La forma de proceder para cada una de las tareas de nuestro test será la siguiente:

1. Realizar una petición al servidor web con una serie de parámetros
2. Recibir la respuesta del servidor y comprobar que se ha realizado con éxito
3. Capturar nuevos parámetros que nos serán útiles en peticiones posteriores
4. Realizar una pausa aleatoria antes de llevar a cabo la siguiente petición y así adaptar el test a los tiempos que emplearía un operador humano.

Pero... ¿Cómo sabemos si una petición ha sido correcta? Lo más indicado es seguir los pasos "manualmente" en el navegador y así ver (directamente en pantalla o abriendo el código fuente devuelto) cual es la respuesta de la plataforma a cada clic. De esta manera podemos ir identificando los textos que se presentarán después de cada petición y utilizarlos en Jmeter.

Bien, ya hemos considerado dos de los elementos más importantes en el diálogo que se establece entre nosotros (o nuestro navegador) y el servidor web: peticiones y respuestas. Pero hay un elemento que aún falta y que es imprescindible si queremos simular ese diálogo: las cookies!! 

Como ya sabéis prácticamente todas las aplicaciones web utilizan cookies. Moodle también necesita crear una cookie en el navegador del usuario para mantener la sesión. En Jmeter dispondremos de un objeto que hará de gestor de cookies de manera que "cada usuario virtual" pueda mantener una sesión con el servidor.

El plan

Variables globales

Definir las "variables globales" del experimento. Como por ejemplo el host al que accederemos y el path dentro de ese host que aloja la plataforma. Esto no es obligatorio, pero siempre está bien para poder cambiar la máquina o la ruta de forma fácil. Si no parametrizamos estos datos tendremos que modificar cada petición cuando queramos probar contra otra máquina o si ha habido cambios en la ruta.

Estas variables no varían durante toda la ejecución del plan, por lo que podemos definirlas a nivel de "Test Plan".

Si llamamos a las variables host y path, cada vez que hagamos una petición podremos utilizar la ruta ${host}${path}. Supongo que queda claro que para hacer referencia al valor de una variable debemos utilizar la forma ${variable}.
Además de estas variables también he definido una ruta para el almacenamiento de los resultados de los tests, donde utilizo la expresión ${__time(yyyyMMdd_HHmm)} que devuelve la fecha y hora en la que se realizó el test.

Grupo de hilos

El siguiente elemento a definir es nuestro grupo de hilos (cuantos hilos y cuantas veces queremos repetir cada hilo). Este elemento será el que contendrá el resto de objetos de nuestro plan. Dentro de este objeto definimos elementos para cada una de las hebras (usuarios) que lanzamos. Esto queda claro si nos detenemos en el elemento UserParameters que contiene una serie de variables que distintas para cada hebra. Por ejemplo, cada hebra accederá con un usuario/contraseña distintos, para ello se sortea  un número del 1 al 10 con la función __Random y se añade al prefijo de usuario y al prefijo de contraseña (UsernameHead y PasswordHead respectivamente). También se tienen los nombres de los objetos de Moodle a los que accederemos: jmeter course, jmeter text assignment, jmeter forum, etc. Estos objetos, así como los usuarios deben estar creados previamente en la instalación de Moodle sobre la que estamos trabajando.

Interacciones con la plataforma

Analizaremos sólo una de las peticiones/respuestas, por ejemplo, la de login. El resto de peticiones son muy similares. Como se ve en la imagen, definimos las variables de la petición en el espacio Parameters. Estos parámetros construyen usando las variables que hemos definido en el grupo de hilos. En la parte superior de la ventana se da el host y el path completo de la petición.

Y ahora podemos comprobar si es usuario se ha identificado correctamente en la plataforma buscando la cadena "you are logged in as", que aparece en cualquier página de Moodle una vez que el usuario se ha identificado. Para ello añadimos un elemento del tipo Response Assertion y la configuramos para que busque la cadena en la respuesta del servidor.

De la respuesta que nos da el servidor también debemos extraer más cosas. Moodle necesita en muchas de las llamadas un id de session sesskey y además nosotros necesitamos el id del curso al que queremos acceder para realizar la próxima llamada que será del tipo

${host}${path}/course/view.php?id=${courseid}

Para obtener el id del curso, por ejemplo, configuramos un elemento de tipo Xpath Extractor que revisará la respuesta del servidor y buscará el id del curso. La expresión que se ha usado es:

substring-after(//*/a[text()='${course_name}']/@href,'=')

Explicación breve:

La función substring-after busca un carácter dentro de una cadena y devuelve la subcadena que hay después de ese carácter.

Lo que hay dentro de la función es una expresión xpath. Estamos diciendo que busque un enlace (tag "a" de HTML) en cualquier parte del documento que tenga como texto el nombre del curso (recordad que lo tenemos definido en las variables) y devuelva el valor de su atributo href. Si el enlace en cuestión es

<a class="" href="http://host/path/course/view.php?id=33">jmeter course</a>

La función devolverá lo que hay después del "=", dentro del atributo href, es decir, 33.

Después se incluyen dos elementos, en elemento de retardo para simular la interacción humana y otro que irá construyendo un gráfico con todas los valores obtenidos en cuando los usuarios ejecuten la tarea en cuestión.

Controladores lógicos

Después de entrar a la plataforma programaremos una serie de tareas que deberán realizar todos los usuarios. Para ello vamos a incluir un controlador lógico de orden aleatorio... ¿Qué quiere decir esto? Las tareas que se incluyen dentro de este controlador serán ejecutadas por las hebras de forma desordenada. Unas hebras entregarán la actividad primero, otras postearán en el foro, etc. Todo para intentar que la actividad sea todo lo "caótica" que podría ser en un periodo de alta actividad en el servidor web.

Subida de ficheros

Además de los parámetros típicos, ya sean vía metodos GET o POST del servidor podemos utilizar ficheros para que sean subidos a la plataforma. En un objeto Request se pueden incluir ficheros dando la ruta al fichero en la sección Send files with the request. Además del MIME/Type y el nombre del parámetro con que se enviará el mismo.

Esto es muy útil cuando estamos probando aplicaciones que previsiblemente recibirán ficheros de cierto tamaño mientras siguen respondiendo a peticiones de otros usuarios.

Depurado

Para intentar detectar fallos en nuestro plan o fallos en nuestra aplicación tenemos dos herramientas básicas que nos ayudarán: El debug sampler y el objeto View Result Tree. Con el primero tendremos acceso a todas las variables y parámetros que hemos definido en el plan. Con el segundo podremos ver el diálogo entre el cliente y el servidor a bajo nivel, es decir, las cabeceras de la petición HTTP, los parámetros que se han enviado y la respuesta del servidor en HTML, los mensajes de error del servidor en caso de que los hubiera, etc. Como vemos en la figura muestra las el resultado de las assertions que hemos definido, para que detectemos fácilmente errores en el script. Si alguna respuesta del servidor no verifica la condición que hemos establecido, en lugar del triángulo verde mostraría un símbolo rojo informando del fallo.

Resultados

Los datos que genera Jmeter serán normalmente el tiempo que ha llevado cada petición contando desde que se ha enviado la misma hasta que se ha recibido la respuesta al completo. Para visualizar estos datos tenemos muchas opciones aunque las más interesantes son el simple data writer que generará un archivo con los datos en crudo para poder ser procesados posteriormente con otra herramienta o cualquiera de las opciones gráficas o de resumen que dan algunas medidas estadísticas. Todas estas opciones pueden ser utilizadas simultáneamente añadiéndolas desde la sección Listeners. Además cualquiera de estos informes pueden ser salvados a fichero para un posterior análisis en un fichero en disco.
En un post siguiente mostraré los resultados de una ejecución contra varias instalaciones de Moodle y lo más interesante y complejo: cómo interpretar los resultados... Pero para eso aún me faltan conos y bastones que quemar.

Descargar fichero de test