miércoles, 30 de marzo de 2011

Tiering en la Nube

Almacenamiento en Tiempos de Crisis
Disponer de una infraestructura homogénea es casi un sueño en época de crisis, y el almacenamiento no es una excepción. Es por eso que he acabado dando un repaso a los sistemas de archivos distribuidos y concretamente a Gluster.

Touring OSCONLos sistemas de archivos distribuidos permiten acceder a almacenamiento externo como si estuviera conectado a nuestro equipo de forma local. Esto supone un ahorro ya que aunque nuestros sistemas pueden crecer mas allá de sus posibilidades con una mínima inversión.

Además, sobre el almacenamiento podemos añadir funcionalidades como:
  • Mirroring
  • Tolerancia a fallos
  • Striping
  • Balanceo de carga
Y ésto es lo que nos permite GlusterFS, el sistema de archivos distribuido base de la plataforma Gluster de gestión de almacenamiento, con una interfaz que tiene muy buena pinta. Además de  la posibilidad de contratarlo como servicio en el EC2 de Amazon.

Lustre
Lustre que adquirió Oracle al comprar Sun, que a su vez hizo suyo al comprar Cluster File Systems, Inc.

Parece que fue el que marcó la tendencia con su arquitectura (se puede ver algo parecido en MooseFS), pero Oracle dejó de lado el proyecto. Y aunque habría estado bien ver la funcionalidades de Lustre en el ZFS de Sun (muy de moda), ha propiciado varios forks como Whamcloud o OpenSFS.

Ventajas del software libre... =)

Tiering en la Nube
Pero si hay algo que me ha gustado es una funcionalidad de Ceph y es la de añadir como parte de nuestro almacenamiento espacio en el S3 de Amazon.

EMC, entre otros, vende una tecnología de tiering automático de almacenamiento (FAST), donde la información más accedida se moverá automáticamente a los discos más rápidos (SSD) y el histórico a los discos más baratos (SATA). El resto estarían en discos SAS.

Y si juntamos las dos cosas, añadimos una capa de almacenamiento en la nube, transparente a nuestros sistemas y ampliable a golpe de click... A mi me parece muy interesante, casi "innovador" =) además de útil tanto para pequeños y como grandes sistemas; tanto por ahorro de costes como por flexibilidad de gestión...

¿Y a vosotros?

Imagen: Touring OSCON

lunes, 28 de marzo de 2011

El Día en el que Sobraba Memoria (Hugepages)

Disponer de equipos con mucha memoria es una ventaja, pero solo si la sabemos gestionar. Pero antes, un poco de teoría (en caso de error se agradecerán aportaciones):

Entropy ≥ Memory . Creativity ²Los procesos no trabajan directamente con la memoria física, sino que lo hacen con la memoria virtual. Esto supone muchas ventajas (no entraré en detalles) pero también un coste extra de conversión, entre la memoria física y la virtual.

Para la conversión cada proceso dispone de una tabla de conversión, y como lo que contiene son direcciones de pagina, se llama tabla de paginación. En aplicaciones con mucho consumo de memoria, donde además la información cambia constantemente (por ejemplo, una base de datos), el acceso a la tabla de paginación es constante.




Por suerte existe la "Translation Lookaside Buffer", una pequeña cache con parte de la tabla de paginación. El problema es que la TLB es de tamaño fijo, y como normalmente guardamos direcciones de páginas de 4 KBytes; el total de memoria al que nos da acceso la TLB no es muy grande.

¿Qué supone ésto?

Tal y como se puede leer en el blog de Pythian con:
  • "Utilización intermitente y muy alta de la CPU en modo kernel"
  • "Durante los parones, todas las CPUs usaban el modo kernel dejando la base de datos inutilizable. Incluso entrar y lanzar una simple consulta SELECT * from DUAL; se tomaba su tiempo."
¿Cuál es la solución?

Utilizar tamaños mayores de página o Hugepages (el caso más habitual 2 MBytes). Esto supone acceder a una mayor cantidad de memoria con las mismas entradas (PTE) en la tabla de paginación. Reduciendo así el consumo de CPU.

Los pasos a seguir son:
  1. Definir el límite memlock para el usuario del servicio que estamos configurando, con un valor algo menor de la memoria disponible (/etc/sysctl.conf).
  2. Iniciar el servicio que consume la memoria.
  3. Calcular el número de hugepages que queremos utilizar en función de la memoria consumida por nuestro proceso (en el caso de Oracle hay un script en la Nota 401749.1)
  4. Definir el parámetro del kernel vm.nr_hugepages= en el archivo /etc/security/limits.conf
  5. Reiniciar el servidor.
  6. Revisar el valor: $ grep Huge /proc/meminfo
Detalles sobre su uso, especialmente con Oracle:
  • Si las páginas totales son iguales a las libres, nuestro servicio no aprovecha las Hugepages por lo que estamos desperdiciando memoria, mejor desconfigurarlas.
  • No son compatibles con la AMM (Automatic Memory Management) en 11g
  • Hay un bug con Grid Infraestructure 11g, donde no se utiliza el límite memlock tal y como hemos definido: Bug 9251136 "INSTANCE WILL NOT USE HUGEPAGE IF STARTED BY SRVCTL"
También lo puedes leer en prinsepac.

Imagen: Entropy ≥ Memory . Creativity ²