Archivo para julio, 2009
Sobre el tamaño de las LUN & los Datastores en entornos VMware
Todo administrador de un entorno virtualizado (entendiendo que se entiende con ello, que dispone de almacenamiento consolidado), se plantea la disyuntiva del tamaño de las LUNs y el número de VMs que alojar en cada porción de disco.
Lo mas fácil es ir al extremo y definir una LUN “enorme”, de X terabytes en la que almacenaremos todas las máquinas virtuales.
Este sistema tiene una ventaja, y es que a menor cantidad de LUNs, menor cantidad de trabajo a gestionar tanto en cabina, como a nivel de masking, zoning y por último a nivel de Datastore* el administrador disminuye un área de gestión importante en todo centro de datos.
*Datastore: De forma simplificada podemos decir que es la nomenclatura utulizada por VMware para designar a cada una de las LUNs visibles, si bien esto tiene ciertos matices que van más allá del objeto de este artículo).
Por contra, con este planteamiento, aparecen diversos problemas, unos menores, otros no tanto que se resuelven o minimizan con un tratamiento del almacenamiento diferente.
Vista de vCenter en el apartado de gestión de Datastores
Según algunos whitepapers de VMware, lo recomendable en general son LUNs de no más de 500 GB, si bien este dato dicho en frío tiene mucho de discutible.
Cuando VMware crea un sistema de archivos sobre cierta LUN, pasamos a denominar a esta como “Datastore” y es a partir de dicho momento en el que podemos hacer uso de la misma.
El sistema de archivos creado se denomina VMFS, y es un tipo de filesystem con capacidad de clustering, acceso múltiple y concurrente por varias máquinas. Esto permite que en un solo datastore, residan, lean y escriban en un mismo momento varias máquinas virtuales y por tanto convivan de forma “pacífica”.
Lo que hay detrás, es que como consecuencia, el sistema de archivos tiene que disponer de un sistema de bloqueos muy desarrollado adapado a dicho tipo de acceso y preparado para un conjunto de máquinas con una fuerte carga de transacciones de disco que incluso puede poner en serios apuros al sistema de disco.
Es por ello que un solo datastore , con un gran número de máquinas virtuales conlleva un mayor número de bloqueos y operaciones concurrentes y por tanto en ciertos “micro-momentos” habrá VMs, a la espera de su tiempo de atención de disco y/o desbloqueo de cierta área del mismo.
Como consecuencia, el rendimiento del sistema de disco con las máquinas virtuales que corren sobre él, se ve decrementado y alguien empieza a pensar que la red SAN no es tan “galáctica” como aquel comercial se empeñaba en aseverar antes de su adquisición.
Otros pensarán que todo es culpa de la capa de virtualización y el modelo tradicional de “una máquina por servidor físico” es totalmente irremplazable.
Es por ello que también hay quien apunta una regla, de forma general, que dicta que en un datastore no se deben acumular más de 10 VMs (y con ello limitar hasta cierto punto el número de colisiones de disco por área de almacenamiento).
¿Es entonces el tamaño del datastore o el número de VMs, lo que limita el rendimiento del sistema?, como el lector podrá suponer, ni todo es blanco…
Una mezcla de ambos componentes es lo que determina un correcto acceso a disco (prescindiendo en este pequeño examen, el tipo de almacenamiento, rendimientos, tipos de RAID y tecnología de disco, canal de acceso, caches de controladoras, y muchas otras variables a considerar en un proyecto real).
Podría pensarse que si utilizamos LUNs de menos de 500 GB y menos de 10 VMs por LUN, nos acercamos a un modelo simple de acción, pero creo que estamos de acuerdo si preciso que no aporta la misma carga, el servidor Oracle del ERP corporativo que un servidor de impresión, y por tanto será preciso medir las necesidades de acceso a disco de cada servidor y/o aplicación en cada caso para decidir el número de LUNS, las VMs que pueden ser vecinas de piso o aquellas que deben ser realojadas en lugares diferentes y mas “exclusivos” de nuestra red de almacenamiento.
Digamos que la norma a seguir pasa por no rebasar, siempre que sea factible, un 80% del rendimiento del sistema de disco por LUN, y asociar en cada una un conjunto de VMs que en su acceso total medio no sobrepase un el límite de operaciones por segundo o requerimientos de MB/Seg por encima de la regla de negocio definida.
La contrapartida es cierta y es en la que estás pensando: Hay que crear, administrar y gestionar mas LUNs en el sistema, pero todo sea porque la aplicación de gestión de incidencias no aumente su carga con las de tipo “esto me va lento…”
¿Que porcentaje a reservar para instantáneas en cabina?, ¿disminución de rendimiento asociada a asignación ligera de disco por VM? y ¿como repercute todo lo anterior en el sistema de backup?
Será obejeto de otro artículo , porque este acaba de terminar…;-)
Estándar abierto en Grid Computing
GridCOMP, proyecto financiado por la UE para el desarrollo de software de computación distribuida
Son varios, los fabricantes de software, que ofertan productos para repartir la distribución de las cargas de trabajo entre varios equipos.
Lo interesante de la noticia reside en que los componentes del proyecto GridCOMP, han elaborado un software que permite realizar esto mismo independientemente del hardware, fabricante o tecnología que resida bajo cada uno de los nodos de computación del “grid”.
Siendo además un software de código abierto, permite la adecuación y mejora del mismo por parte de cualquier entidad que lo utilice.
Característica de especial mención, es aquella por la que el software monitoriza continuamente la red por la que se distribuyen los nodos, para evitar la sobrecarga de cualquier enlace entre los mismos, con lo que dicho aplicativo puede ser utilizado con bjo impacto para el resto de funciones que desempeñe el conjunto de sistemas.
Teóricamente, posibilita que varios ISP (por poner un ejemplo), se unan para ofrecer servicios en la nube (cloud computing) mas robustos, fiables y distribuidos o que varias universidades unan la capacidad de sus servidores para obtener mayor capacidad de cómputo y mejorar sus proyectos de investigación.
Amazon y la confianza perdida
Perdida por todos aquellos que han comprado libros en formato electrónico en Amazon y han podido comprobar como la compañía ha decidido que “Rebelión en la granja” y “1984″ no debían seguir residiendo en los dispositivos Kindle de sus clientes.
¿Solución?
Amazón entró en dichos dispositivos remotamente y eliminó esos textos.
Vamos que es algo asi como si tu librero de confianza entra, a escondidas, en tu casa a quitarte el libro que ayer obtuviste de su establecimiento…
Lógicamente, esto ha hecho que los clientes hayan puesto el grito en el cielo y no es para menos.
Amazon ha abierto la caja de los truenos y será dificil que los usuarios vuelvan a ofrecerle su confianza.
VMware DPM+DRS…una característica “GREEN” de verdad
Hasta que no ha pasado un tiempo tras haber desplegado una solución, no se obtienen datos, cuantitativos, reales, sobre ciertos supuestos beneficios de la misma.
Uno de esos beneficios es la reducción de consumo eléctrico gracias a DPM.
DPM es una característica, ya en modo “full support” en vSphere, por la que se monitoriza la carga (cantidad de VMs, requeirmientos de CPU, Memoria, Disco, Red…) del sistema y por ende, calcula el número de servidores necesario para soportarla y mantener las reglas de negocio marcadas. De ese modo en los tiempos de caga menores, VMware es capaz de apagar servidores completos e ir encendiéndolos conforme la carga aumenta y se requiere de sus servicios.
Es por ello, que muchas empresas en las que incluso se trabaja a tres turnos (24horas al día), el personal de oficina así como otras áreas nunca es el mismo durante el turno de noche. Por tanto la carga sobre el sistema se reduce al control de cadena, y ciertos servicios críticos.
En casos reales he podido comprobar una reducción de consumo eléctrico de un 25% al utilizar esta característica lo que casí por si solo es argumento para migrar a la nueva versión (en VI3 esta característica estaba en modo experimental y por tanto no fiable al 100%).
Cuando una VM se ejecuta sobre un servidor y VMware considera éste es el optimo para su apagado, el sistema DRS, por medio de vMotion cambia la ejecución de la/s máquina/s virtual/es a otro/s de los servidores (tras calcular cual será la nueva y óptima localización de la misma), y todo sin parada de servicio.
Los cálculos referentes a ROI & TCO se mejoran así frente al mismo despliegue de la misma plataforma sobre VI3.
Posiblemente lo primero que viene a la cabeza al leer este artículo, es que esto se cumplirá para entornos con decenas o centenas de servidores pero es posible comprobarlo sobre entornos con menos de 10 servidores físicos, lo que entra dentro del nuestro típico entorno SMB (PYME).
VMware Studio (facilitando la creación de virtual appliances)
Los Virtual Appliances han irrumpido en el entorno IT, con el mismo auge que la tecnología que los soporta (la virtualización).
La facilidad de importar una máquina virtual, con todo lo necesario (aplicaciones, bases de datos, medidas de seguridad,configuraciones específicas al efecto de cada elemento e incluso usuarios de prueba ya predefinidos en algunos casos) ya preconfigurados y listos para funcionar, permite poner en marcha una máquina de pruebas en menos de 5 minutos con la solución a testear o utilizar.
Los grandes fabricantes de software, servicios así como algunas comunidades del entorno Open Source, ya hace tiempo que distribuyen virtual appliances a fin de distribuir y hacer mas sencilla la inclusión de los nuevos lanzamientos por parte de los departamentos TIC de sus posibles clientes.
Ahora con VMware Studio 2.0 (Aun en fase Beta), la creación de estos elementos se facilita, automatiza al máximo y permite una menor pérdida de tiempo con respecto a la anterior versión.
Será el momento de que las pequeñas empresas de desarrollo apuesten por distribuir sus demos o aplicaciones con los mismos medios que los Top One de la industria del software?
Por lo menos es una posibilidad a considerar, para acercar mas facilmente sus productos a su mercado potencial.
IOPS, MB/s y otras formas de medir el rendimiento de los sistemas de disco.
Hace uno días, unos alumnos, me preguntaban algo así como:
-¿Que tipo de disco es el mejor, en proporción a su precio?
Bien, la verdad es que la respuesta facilona, sin pensar (y dejando de lado la variable “precio”), consistiría en indicar: los discos de Fibra de 15Krpm.
Puntualizando a continuación:
-Si bien los SSD, en un tiempo (ahora no ofrecen ni capacidad ni un iempo de vida tan largo), posiblemente se apoderen del mercado High-End y vayan extendiéndose a gamas cada vez mas modestas, por su excelente rendimiento y menor consumo.
Claro, en el momento en el que la variable precio entra en la ecuación… la respuesta no puede ser tan concisa.
Los sistemas de disco a menudo ocupan varios Racks
Realmente, la pregunta correcta sería algo así como:
-¿Es proporcional la diferencia de precio entre los discos SATA, SAS y FC al aumento de prestaciones de los mismos?
Obviamente, depende del entorno en el que van a instalarse y por tanto, lo que se espera/necesita del sistema de disco.
Por ello creo mas efectivo, indicar algunos parámetros sencillos de medición de rendimiento y que la respuesta la decida cada cual, en función del entorno para el que pensó la cuestión.
En principio lo trivial es pensar en la tasa de transferencia (“Megas”, que un disco es capaz de leer y escribir por segundo). Aunque se suele hablar de dos tipos de tasas: La sostenida y la pico (un disco puede ofrecer una determinada tasa de transferencia muy alta en un pequeño instante pero ofrecer realmente otra mucho mas baja de forma sostenida).
Otro parámetro, tambien relacionado con el anterior, es la velocidad de rotación del disco (las revoluciones por minuto). Si bien este parámetro indice sobre todo el resto de datos, que ofrezca el disco en cuanto a rendimiento (sin ser el único ni el mas importante).
Como último como dato básico, tambien es necesario hablar de IOPS (Operaciones de entrada/salida por segndo), que es capaz de soportar/ofrecer el disco (Tal vez sea este el dato mas importante en muchos entornos, incluso por encima de la tasa de transferencia).
La tasa de transferencia (como casi todo) se incrementa con el precio del disco pero no en la misma proporción. En general un disco SAS de 15Krpm tiene un coste bastante mayor que un SATA a 7.2Krpm (siempre comparando a mismo tamaño y en gama de disco Enterprise), y la tasa de transferencia sostenida no aumenta al mismo ritmo que el precio
¿Significa eso, que no es rentable el disco SAS frente al SATA?. No, en absoluto.
El disco SAS, en transferencias por ráfaga es mucho mas rápido que el SATA, pero sobre todo en lo que es clarísimamente superior, es en terminos de IOPS.
Así en un entorno en que tengamos que copiar grandes ficheros para almacenarlos, el disco SATA, puede obtener unos ratios de transferencia aceptablemente buenos.
En entornos con alto tráfico y en los que se precisa realizar gran número de transsacciones por segundo (bases de datos con alta actividad, sistemas de ficheros de servidores, sistemas de cálculo con grandes necesidades de aceso a disco), los discos SAS (y no digamos los FC), sacan a relucir sus prestaciones para ofrecer los datos de todas esas operaciones por segundo, mientras que los SATA empezarán a flaquear.
Es por ello, que coloquialmente se habla de disco rápido/ caro y disco lento/económico pensando en *FC/SAS vs SATA.
Además, la mayor cache de los discos caros, las mayores velocidades de rotación y una vida normalmente mas larga, hacen que los entornos de disco tiendan a disponer de un pool de discos rápidos y otra serie de discos lentos entre los cuales (los diferentes pools) se suele ir moviendo la información en función del uso que se le da, la cantidad de veces que se accede a ella, o la aplicación que hace uso de la misma.
¿Son costosos los discos de Fibra?
Si pensamos que una Aplicación & BBDD , debe responder las consultas de 10.000 usuarios concurrentes y la tecnología de disco puede reducir hasta en 200 veces el tiempo de respuesta en este tipo de entornos…podemos afirmar que su precio está mas que justificado (ya solo con el tiempo que dichos usuarios no pierden por cada consulta).
Si esos mismos discos se utilizan para que el hijo del Director general almacene las fotos de sus vacaciones…efectivamente, se estará tirando el dinero que cuestan esos dispositivos.
Por tanto, la conclusión y respuesta a la pregunta formulada al princpio se transforma en otra:
Cada disco está diseñado para un mercado/uso/necesidad y por tanto no podemos afirmar que éste o aquel son mejores en términos de relación calidad /precio. Lo que si es verdad es que en la mayoría de sistemas se suelen utilizar varios tipos de discos simultáneamente para disponer de cada tipo de información con un nivel de acceso (velocidad, cantidad de veces que se solicita o escribe cierto dato, criticidad de la aplicación que usa los datos…) para asegurar que cada dato reside en un tipo de disco (y coste asociado al mismo) acorde a lo que se espera de dicho dato y sistema.
Notas:
FC: Fiber Channel
SATA: Serial ATASAS: Serial Attached SCSI
SSD: Solid State Drive (Discos sin partes móviles)
