Chubascos tecnológicos para quitarnos la neblina de las tecnologías de la nube! Viva la lluvia!
Llevo un tiempo siguiendo desde la barrera la evolución de la solución de VMware para una Infraestructura convergente donde se simplifica la gestión del almacenamiento de manera brutal.
Más allá de entrar en detalles de su funcionamiento, esta tecnologia nos va a llevar a poder crear cubos de virtualización, sin tener que desplegar una SAN para albergar los datos de manera compartida. Esto simplificará la gestión de los entornos de virtualización al tener una administración de todos los componentes (computación, red y almacenamiento) desde un único punto central: vCenter.
La revolución del almacenamiento conocido hasta ahora
A dia de hoy nadie se plantea poder poner ningún servicio de producción (ni siquiera de PRE) en un almacenamiento que no esté respaldado por un RAID. VSAN rompe radicalmente con esto.
De entrada, la existencia de RAIDs con este sistema no es necesaria, ya que la información de una máquina virtual está almacenada en otros hosts ESXi del cluster VSAN. Esto nos lleva a que podemos tolerar (como mínimo) el fallo de un host en nuestro clúster y no tendremos pérdida de datos.
Cabe tener presente que esta tecnologia replica los datos entre varios hosts para tolerancia a fallos, pero esto a la vez nos da también una mejora en el rendimiento del almacenamiento, gracias al uso de «caches» SSD y de la distribución de la información en varios hosts, pudiendo obtener unos rendimientos mucho mayores que con una cabina SAN.
¿A donde nos lleva todo esto junto con el Software Defined Datacenter?
Bien, con este modelo de almacenamiento, que además está gestionado a nivel de hypervisor, nos lleva a poder aprovisionar cualquier servidor basado en los SLAs definidos para ese servicio.
¿Y como? Tan sencillo como definir plantillas de niveles de servicio. Un ejemplo:
Plantilla servicio crítico
– réplica en 2 hosts (seria el simil al RAID)
– Rendimiento: Alto
Con ello, al desplegar cualquier VM, seleccionaremos que nivel de servicio le queremos dar y el sistema automáticamente hará la mágia en el almacenamiento. ¿Genial, no?
Esto, junto con las grandes automatizaciones que ya disponemos a día de hoy, gracias a soluciones como vCloud Automation Center y vCloud Director, nos permitirá de manera sencilla crear «blueprints» para ciertos servicios y que el despliegue de una VM vaya alineado con los SLAs que de ese servicio se esperan. Y todo ello en muy pocos clicks.
Espero que os haya gustado mi «pequeña» reflexión.
Saludos y nos vemos por las nubes!
Sergi de la Torre
Hola,
Quinta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.
Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.
Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
*Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.*
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como «re-firma» me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento «profil-driven».
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.
Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV
Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop
Contenido:
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Bien, entramos de lleno en un tema más que interesante y que por el detalle que requiere se suele pasar por alto o dimensionar «más o menos a ojo y a base de experiencia».
Como ya se habló en otro post de la serie, cada tipo de RAID viene acompañado de algún tipo de penalización en el momento de escribir. Esta penalización puede ser de 1-1 IOPS (penalización nula o dicho de otra forma, que no hay penalización) o como es el caso más conocido, el del RAID 5, el cual es 4-1 IOPS. Donde por cada operación de I/O que le sea solicitada a nuestro RAID, se generarán 4 IOPS.
Bien, determinar el nivel apropiado de RAID para los distintos tipos de cargas en las VMs primero y sobre todo, implica que conozcamos el tipo de carga de nuestra VM. Esto se refiere a:
– Porcentaje de lecturas
– Porcentaje de escrituras
– Frecuencia de acceso a la información
– Cantidad de información actual y previsión de crecimiento
– Tipo de operaciones (secuenciales o aleatorias)
– Picos y utilización media
Esto sólo para empezar! Para seguir con lo de «nivel apropiado de RAID», también habría que conocer cómo calcular el impacto de cada tipo de RAID en determinados tipos de carga. Esto básicamente se reduce a una fórmula muy sencilla en la cual se consideran los porcentajes de lectura y de escritura así como la penalización por el tipo de RAID y también la cantidad de IOPS para las que estamos dimensionando el RAID.
Por último podríamos también hablar de la infraestructura en sí. Desde donde viajarán los datos (HBA), el tipo de protocolo que utilizaremos, el recorrido que harán y finalmente las características físicas y configuraciones que tengamos en nuestro storage…desde tipos de procesador hasta tipos de interconexión de los discos. Nada más imaginaos dimensionar un storage para soportar una cantidad altísima de operaciones pero lo conectamos todo a través de un cable a 1Gbps.
Como veréis, no son pocas las variables y sí es poco el conocimiento que se tiene del impacto REAL Y MEDIBLE de cada una de ellas. Evidentemente escribir un libro para calcular un RAID no es la idea (como lo de las HCL que comentábamos en otra entrada) por lo que veremos más en profundidad lo que a mi entender es más relevante.
Por favor, si os parece que me dejo algún aspecto relevante fuera del estudio, avisadme para poder valorar su inclusión en el post.
Tendremos en cuenta:
– Espacio necesario
– Porcentaje de lecturas
– Porcentaje de escrituras
– IOPS de la VM
Espacio necesario
Lo primero será obtener la información de la ocupación actual de la VM y la previsión de crecimiento. Esto es demasiado fácil como para tener que explicarlo 🙂 Pero basta con mirar la información de la VM desde el propio S.O. en todas sus particiones/puntos de montaje y mirar un poco el histórico de crecimiento además de preguntar si habrá algún tipo de cambio importante. Por ejemplo, que en un servidor de correo se desee ampliar la cuota de los buzones, que en un servidor de ficheros se piense comenzar a almacenar otro tipo de información como videos, fotos, etc por las mismas necesidades de negocio…vamos, cualquier cosa que pueda «romper» el histórico de crecimiento.
IOPS y distribución entre lecturas y escrituras
Esto ya tiene un poco más de miga (un poco) y podemos decir que hay muchas formas de verlo. Por ejemplo, con vcOPS. Esta herramienta ya nos presentará la información (TPS=Transacciones por segundo) desglozadas en lecturas y escrituras desde donde podremos obtener los porcentajes.
Utilizando esxtop o resxtop (la variante de esxtop que se usa desde vMA), podremos identificar las IOPS. Bastará con ir a la vista de las VMs (presionando «v») y ver el número que nos muestra el campo CMDs de comandos por segundo. Normalmente este campo es igual al número de IOPS, salvo que algunas veces puede estar un poco hinchado por otro tipo de datos que no está demás contar como las reservas SCSI. «READS/s y WRITES/s» son la cantidad de inodos que se ven afectados ante las vibraciones de nuestro storage y la posición relativa del sol y la luna….que no! era para ver si estabais despiertos 😀 Evidentemente se trata de las lecturas y escrituras y la suma de estos dos valores dan como resultado los «CMDs» del primer campo.
esxtop no sería mi primera opción ya que se trata de una herramienta para diagnosticar problemas y las circunstancias que los causan (root cause analisys). Sin embargo, se puede ejecutar esxtop de forma que guarde la información en un fichero y lugo la podamos «graficar» con un excel. Marco Broeken lo explica detalladamente en su blog http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/
Existe una versión gráfica de esxtop que podréis descargar desde los labs de VMware. Es un «fling» muy útil y fácil de usar.
http://labs.vmware.com/flings/visualesxtop
En lo personal suelo utilizar la versión opensource de Hyperic ya que además de analizar IOPS, me permite relacionar esas IOPS con otros factores como las consultas SQL, el número de usuarios conectados a una aplicación, bbdd, etc.
http://www.hyperic.com/hyperic-open-source-download
Las cuentas claras, conservan la amistad
Ahora sólo falta hacer números. Es MUY sencillo y no guarda ningún misterio. La fórmula con las modificaciones que Duncan Epping hizo para contemplar la penalización en las escrituras de los tipos de RAID, es la siguiente:
( IOPS de la VM × % lecturas ) + (( IOPS de la VM × % escrituras ) × Penalización RAID)
Por tanto, en caso de que nuestro estudio previo nos haya dado como resultado que nuestra VM necesita 1000 IOPS (aquí entra en factor un aspecto de diseño importante…diseñaremos para los picos de carga o diseñaremos para el consumo medio lo que resultará en ahorre de costes y cuellos de botella esporádicos. Aunque esto mejor dejarlo cuando vayamos por el VCAP-DCD 🙂 ) de los cuales el 40% son escrituras y el otro 60% son lecturas. La fórmula quedaría:
IOPS de la VM = 1000
% lecturas = 60%
% escrituras = 40%
( 1000 IOPS x 0,6 ) + (( 1000 IOPS x 0,4) * Penalización RAID) =
600 IOPS + ( 400 IOPS * Penalización RAID) =
Ahora toca jugar un poco con los RAIDs y recordar las penalizaciones para cada uno de ellos. Sobran las tablas por internet que muestran estas penalizaciones así que simplemente supondremos que queremos ver cómo nos quedaría con un RAID 5.
600 IOPS + ( 400 IOPS * 4 IOPS ) =
600 IOPS + 1600 IOPS = 2200 IOPS
Vemos así cómo para una VM con 1000 IOPS necesitaremos un RAID 5 de 2200 IOPS ya que cada una de las IOPS de escritura y sólo de escritura, tendrá una penalización de 4 IOPS por c/u de escritura.
Aquí se puede jugar mucho pero otra vez nos iríamos a la parte de diseño más que VCAP-DCA. Cuando tengamos que diseñar un storage, básicamente en este punto se tratará de un equilibrio entre IOPS y espacio que se necesita. De forma que la tarea se reduzca a encontrar la combinación que cubra las necesidades de IOPS y espacio con el menor coste posible. En este sentido, los discos de estado sólido están rompiendo las reglas del juego ya que para lo que antes podíamos necesitar barbaridades de discos, ahora con 4 o 5 discos de estado sólido lo conseguimos y a un mejor precio!
Algunas cosas que quiero comentar antes de dar por finalizado el post:
Lecturas – Si bien las escrituras sólo pueden quedarse igual o empeorar según el tipo de RAID que utilicemos, las escrituras sólo pueden mejorar. En este caso los cálculos son muy sencillos, basta con sumar las IOPS de los discos que forman el RAID y ya sabremos las IOPS de lectura que tenemos. Hay muchos debates en internet de «qué RAID es el mejor en lecturas»…la respuesta es fácil, mientras de más discos se pueda leer la información, mejor. Supongamos que un fichero de 10 MB está distribuido en 5 discos y que la controladora es capaz de leer de todos a la vez (a cada disco le toca leer 2MB)…mejor que si sólo tenemos el fichero en 2 discos (a cada disco le toca leer 5MB).
IOPS = La cantidad de operaciones de entrada/salida por segundo. Normalmente utilizada para medir los accesos aleatorios de escritura y lectura de bloques pequeños. Cargas habituales OLTP. Se puede calcular:
IOPS = throughput / block size
Throughput = La cantidad de información que se puede transmitir por segundo. Normalmente se utiliza para medir accesos aleatorios de bloques más grandes (64K). Se puede calcular:
Throughput = IOPS * block size
Block size = La cantidad de datos que se transmite en una operación de entrada/salida. Se puede calcular:
Block size = IOPS / Throughput
Frecuencia de acceso a la información = Casi todas las cabinas traen más o menos caché. Algunas con funcionalidades de tiering ponen en esta caché la información más utilizada por lo que es muy posible que cuando estemos realizando operaciones, muchas de ellas se valgan de la caché de nuestro storage. Por esto también es importante contrastar las fuentes de nuestra información. Una cosa es medir desde dentro del entorno virtual, otra es hacerlo a nivel de hipervisor y otra es hacerlo a nivel de storage. Como recomendación, si es posible, contrastar todas las fuentes para depurar la información en la que basaréis el diseño.
Bueno, otro post que se nos fue. Espero que esta información os sea útil y por favor dejad vuestros comentarios que hará ilusión leerlos 🙂
Saludos,
Sebastián Greco
Bibliografía utilizada para escribir este post:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008205
http://www.yellow-bricks.com/esxtop/
http://labs.vmware.com/flings/visualesxtop
https://communities.vmware.com/thread/456397
http://labs.vmware.com/flings/io-analyzer
http://goo.gl/t9Hl0Y
http://www.lucd.info/2011/04/22/get-the-maximum-iops/
http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/
http://www.hyperic.com/hyperic-open-source-download
http://wintelguy.com/2013/20130406_disk_perf.html
http://www.yellow-bricks.com/2009/12/23/iops/
http://www.tomshardware.co.uk/forum/251893-32-raid-raid#.
http://wintelguy.com/raidperf.pl
http://www.dataram.com/blog/?p=112
http://es.wikipedia.org/wiki/OLTP
http://es.wikipedia.org/wiki/OLAP
Hola,
Vamos con la cuarta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.
Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.
Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
*Determinar los requerimientos y configurar NPIV.*
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como «re-firma» me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento «profil-driven».
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.
Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV
Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop
Contenido:
Determinar los requerimientos y configurar NPIV.
En un fabric se encuentran varios tipos de puertos. Entre ellos los N_port, E_port, U_port y F_port. Los puertos que nos ocupan, los N_port, utilizados en los nodos que se conectan a un switch de fibra o a otro N_port en una conexión punto a punto, se identifican con una especie de MAC address que se llama «world wide name» de las siglas WWN. Al igual que una MAC address, este ID es único para cada port dentro del fabric. Una de las capacidades del protocolo Fibre Channel (alguna vez escuché que se escribe «Fibre» para distingirlo de una conexión que va por fibra «fiber» aunque si lo busco en el traductor aparecen las dos como válidas) es que permite virtualizar este ID, de forma que podamos asignar más de un ID a un mismo N_port físico. Por esto veremos que a veces uno habla del WWN del nodo o del port. Los puertos virtuales se crean y eliminan cada vez que uno enciende y apaga la VM. Para las operaciones de vMotion, este puerto (VPORT) se borra del host origen y «viaja con la máquina» para volver a ser creado en el host destino. A todos los efectos se comporta dentro de nuestro fabric como un puerto más de tipo N. Para los casos en que a una VM no le asignemos un VPORT, la misma utilizará el WWN del nodo para identificarse dentro de nuestro fabric.
vSphere permite aprovechar esta funcionalidad para que podamos presentarle a nuestras VMs, HBAs virtuales con distintos IDs y puertos. Cormac Hogan en su blog (la referencia a este blog está en la bibliografía) no termina de ver claro para qué se puede querer algo así. Leí una vez en el libro de vSphere Design Best Practices al cual ya no tengo acceso, que uno de los usos para este tipo de tecnología podía ser realizar zonings y/o maskings ya que este tipo de consideraciones era pertinente en la fase de diseño del storage y de los hosts (tipos y número de HBAs).
Vemos los requerimientos de esta tecnología:
– Sólo trabaja con discos RDM.
– HBAs compatibles con NPIV.
– Las HBAs de un host que accedan a la misma LUN deben ser de un único fabricante.
– Si un host utiliza paths de varias HBAs físicas para acceder al storage, la VM que utilice NPIV deberá estar en todas esas zonas. Esto es un requerimiento para soportar multipathing.
– Las HBA físicas del host deben tener acceso a las LUNs que queramos que nuestras VMs con los NPIV configurados tengan acceso.
– Los switches en el fabric tienen que soportar NPIV.
– Asegurarse que el NPIV ID configurado en LUN sea el de el NPIV ID del target que le queremos configurar.
Capacidades o funcionalidades soportadas por NPIV:
– vMotion. La VM retiene el WWN virtual asignado. También se puede hacer vMotion de esa VM a un host con HBAs que no soporten NPIV. En este caso la VM utilizaría el WWN del nodo (el WWN de la HBA física). Perderíamos zonnings y maskings hechos a la NPIV_ID. Para poder hacer vMotion, el RDM tiene que estar en el mismo datastore que el fichero de configuración (.vmx) de la VM.
– Para storages activo/activo que soporten I/O concurrentes, los I/Os concurrentes de 2 puertos NPIV también están soportados.
Limitaciones:
– Es necesario que la HBA física esté conectada a un switch de fibra. Dicho de otra forma no soporta DAS.
– Cuando se clona una VM o se despliega una desde una plantilla, el WWN asignado no persiste.
– Storage vMotion no está soportado.
– Deshabilitar y volver a habilitar la funcionalidad de NPIV en un switch puede provocar un fallo en el link y que por tanto se detengan las I/Os…supongo que esto según como puede llegar a estropear datos.
Si queréis ver cómo se configura, os recomiendo este link. http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html
Yo no lo puedo probar en mi lab que lo tengo todo por red…el tema fibra evidentemente se me iba de presupuesto 🙂
No obstante, estos son los pasos según la documentación de VMware.
Asignar WWNs a las VMs en el cliente Web de vSphere:
– Seleccionar y editar la VM.
– Dentro de VM Options, expandir las opciones de «Fibre Channel NPIV» para ver las opciones.
– Deseleccionar el checkbox «Temporarily Disable NPIV for this virtual machine» .
– Seleccionar «Generate new WWNs».
– Especificar el número de WWNNs (World Wide Node Name o el que se asigna a la VM) y WWPNs (World Wide Port Name o los que se asignan a cada WWNN). Se necesitan un mínimo de 2 WWPN para soportar failover con NPIV.
– Dar de alta los WWNs en el switch y configurar los zoning/masking deseados.
– Asignar las LUNs deseadas a los WWNs creados.
En estos pasos no consta la creación previa de un disco de tipo RDM…recordad que es condición necesaria para poder utilizar NPIV. En este link veréis una guía que sí contempla los pasos incluidos la creación de la VM con el RDM http://goo.gl/rNUccr
El post de hoy ha sido particularmente corto pero no he tenido tiempo para más. Espero que os sea de utilidad. Si os gustan estos posts y creéis que a alguien más le pueden ser de utilidad, por favor compartid el enlace :).
Saludos,
Sebastián Greco
Bibliografía utilizada para escribir este post:
http://goo.gl/uDboJR
http://en.wikipedia.org/wiki/Fibre_Channel#Ports
http://en.wikipedia.org/wiki/NPIV
http://www.valcolabs.com/2012/05/12/objective-1-1-implement-and-manage-complex-storage-solutions/
http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html
http://blog.scottlowe.org/2009/11/27/understanding-npiv-and-npv/
Hola,
En esta entrada nos meteremos de lleno en «Capacidad y habilidades del objetivo 1.1. A ver hasta donde llegamos hoy.
Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.
Capacidad y habilidades para:
*Determinar los casos de uso y configurar VMware DirectPath I/O.*
Determinar los requerimientos y configurar NPIV.
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como «re-firma» me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento «profil-driven».
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.
Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV
Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop
Contenido:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Empezaremos por ver qué es VMware DirectPath I/O. Me sería imposible sintetizar más la propia descripción que VMWare hace de esta característica por lo que traduciré su definición y agregaré algunas líneas.
DirectPath I/O permite a las VMs acceder a las funciones de los dispositivos PCI de forma directa, en plataformas que dispongan de una unidad de gestión de I/O de memoria o de sus siglas en inglés «IOMMU», habilitada en la BIOS.
Para AMD es AMD-Vi y para Intel es VT-d. Realmente quien permite este acceso directo es el hardware…DirectPath I/O en VMware es la característica que permite aprovechar esta funcionalidad del hardware.
Las siguientes funcionalidades no están disponibles para las VMs que tengan DirectPath I/O:
– Añadir o quitar dispositivos virtuales en caliente (Hot add).
– Operaciones de suspend/resume.
– Operaciones de record/play.
– Fault tolerance.
– High availability.
– vMotion (cambio lo que pone el doc. de VMware ya que no mencionan en esta sección lo de vMotion, sino que aquí ponen DRS).
– Snapshots.
Las siguientes funcionalidades están sólo disponibles para las VMs que tengan DirectPath I/O configurado en UCS de Cisco con switches distribuidos VM-FEX.
– vMotion
– Añadir o quitar dispositivos virtuales en caliente (Hot add).
– Operaciones de suspend/resume.
– High availability.
– DRS (venga va…lo ponemos 🙂 ).
– Snapshots.
Una limitación que no vi en el link que os comento (en la bibliografía están todos los links de donde saco la info) es que un dispositivo con DirectPath I/O no puede ser presentado a más de una VM por con DirectPath I/O (sí se podría presentar a otra VM mediante emulación/paravirtualización aunque parece que da problemas). Tampoco mencionan NIOC. Aunque sea obvia, está bien mencionarla creo.
Adicionalmente, en los configurations maximums vemos los máximos soportados de esta tecnología (ojo que mezcla DirectPath I/O con SR-IOV que veremos más adelante).
»
VMDirectPath PCI/PCIe devices per host 8
SR-IOV Number of virtual functions 64 (43 en NICs Intel soportadas y 64 en NICs Emulex)
SR-IOV Number of 10G pNICs 8
VMDirectPath PCI/PCIe devices per virtual machine 4 (hasta 6 si 2 de ellos son Teradici)
»
Creo que este tipo de lista es importante prestarle atención…me late a mi que se pueden esperar preguntas del tipo «configura DRS en el cluster» y que luego resulta que hay máquinas que tienen DirectPath I/O habilitado y uno se vuelva loco buscando el motivo por el cual esas VMs no migran. Esas preguntillas que a uno tanto le gustan en un test jejeje!
Ok…hasta aquí la definición pero no es lo que pedía el bluprint. Por tanto, cuáles son los casos de uso de una tecnología del estilo y más aun sabiendo que tiene tantas limitaciones excepto en los UCS?
La respuesta parece fácil: RENDIMIENTO.
Como sabréis, vSphere ofrece a las VMs 3 formas de gestionar los I/Os de red. Mediante emulación (e1000 por ejemplo), paravirtualización (vmxnet3 por ejemplo) y accediendo directamente al dispositivo (ahí entra DirectPath I/O). Sabido es también que el rendimiento de una vmxnet3 es muy alto y soporta perfectamente cargas de más 10Gbs sin problemas. Entonces ¿DirectPath qué es lo que aporta? Lo que aporta esta tecnología es descargar a nuestro micro de la tarea de tener que gestionar una carga tan elevada de I/Os y LATENCIAS más bajas en las comunicaciones. Además de RENDIMIENTO, también pueden existir ciertas características físicas de nuestras NICs que serán aprovechadas por nuestras VMs si pueden hablar directamente con la NIC. Este es el caso de TCP offload engine para algunas HBA/S.O.s o SSL offload.
El secreto de cuándo utilizar DirectPath I/O y cuándo no, es cuando queremos obtener el máximo rendimiento de una VM que deberá gestionar un número muy elevado de paquetes IP. Estamos hablando en el orden de los 300.000 por segundo! Para cargas de unas 8.000, el rendimiento es el mismo que con una NIC paravirtual y en casos como los de servidores de base de datos donde pueden haber muchos menos paquetes pero de tamaños mayores, el rendimiento es MEJOR en tarjetas virtuales que en una con DirectPath I/O!!! 🙂 Esto no lo sabía yo jejeje! Si estáis preparando el examen del VCAP-DCA, repito, no os quedéis con lo que yo escribo aquí ya que se trata de un resumen de las cosas que leí. Id a las fuentes. En este caso podréis ver las gráficas de rendimiento y las cargas que VMware testeó. Adicionalmente y de forma explícita, VMware recomienda este tipo de adaptadores para cargas muy sensibles a las latencias y cita el caso de las aplicaciones de «stock traiding». Existe una diferencia de unos 10microsegundos (no confundir con ms) en las latencias de un test de round-trip.
Vamos a configurar DirectPath I/O
1. Desde el vSphere WebClient (no utilizaré el cliente instalable para nada…limitaré el estudio al Cliente Web. Adaptarse o morir 🙂 )
Home > Hosts and Clusters > Seleccionar el host > Manage > Advanced y hasta aquí llego porque recibo el mensaje de «DirectPath I/O Not supported». Si no fuera así, se listarían los dispositivos que soportan esta tecnología.
Un icono verde significa que el dispositivo está activado y habilitado para DirectPath I/O.
Un icono naranja significa que el estado del dispositivo ha cambiado y que el host debe ser reiniciado para poder utilizar el dispositivo.
Como nota al margen, VMware requiere que antes de quitar un dispositivo que se utiliza para DirectPath I/O, se deshabilite el mismo ANTES de quitarlo. Si nos queremos ahorrar el reinicio, una forma poco ortodoxa de deshabilitar DirectPath I/O podría ser descargar el módulo. Para ello se podría ejecutar: /usr/lib/vmware/vmkmod/vmkload_mod -u vtd
Ahora que está el dispositivo habilitado en el host, es hora de configurarlo en una VM.
Home > VM and Templates > Seleccionar la VM (no sé si ha de estar apagada o puede estar encendida, en cualquier caso supongo que deberá reiniciarse puesto que DirectPath I/O no soporta Hot Add > Manage > VM Hardware > Edit > New device > PCI Device y hasta aquí llego sin dispositivos que lo soporten en mi lab. En la bibliografía veréis que hay un link con alguien que sí lo configura y muestra las capturas de pantalla.
Al añadir este tipo de dispositivo, se creará de forma automática una reserva de memoria igual al tamaño de la RAM de la VM.
Para configurar DirectPath I/O para que la VM soporte vMotion. Aquí simplemente copio y pego los pasos de la guía oficial de VMware.
»
You can enable DirectPath I/O with vMotion for virtual machines in a datacenter on a Cisco UCS system that has at least one supported Cisco UCS Virtual Machine Fabric Extender (VM-FEX) distributed switch.
Prerequisites
Enable high performance network I/O on at least one Cisco UCS port profile on a supported Cisco VM-FEX distributed switch. For supported switches and switch configuration, see Cisco’s documentation at http://www.cisco.com/go/unifiedcomputing/b-series-doc.
Power off the virtual machine.
Procedure
1 Log in to the vSphere Client and select the VMs and Templates inventory view.
2 Right-click the virtual machine to modify and click Edit Settings.
3 On the Resources tab, select Memory.
4 Select Unlimited.
5 On the Hardware tab, select the network adapter to configure as a passthrough device.
6 Select a port profile with high performance enabled from the network label drop-down menu, and click OK.
7 Power on the virtual machine.
After the virtual machine is powered on, DirectPath I/O appears as Active on the Hardware tab of the virtual machine properties dialog box.»
»
Bibliografía utilizada en este post:
http://goo.gl/veuhRb
http://en.wikipedia.org/wiki/X86_virtualization
http://goo.gl/nQQ6Z1
http://goo.gl/wWxl5
Haz clic para acceder a vsphere-55-configuration-maximums.pdf
http://goo.gl/mOvPdd
http://goo.gl/RYSwws
http://goo.gl/rkRu1K
http://theithollow.com/2012/07/vmdirectpath-io-basic-setup/
Haz clic para acceder a network-io-latency-perf-vsphere5.pdf
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805
http://en.wikipedia.org/wiki/Round-trip_delay_time
http://infrastructureadventures.com/tag/directpath-io/
Haz clic para acceder a vsp_4_vmdirectpath_host.pdf
http://www.vm-help.com/esx40i/VMDirectPath/fix_config_issues.php
http://www.valcolabs.com/2012/05/12/objective-1-1-implement-and-manage-complex-storage-solutions/
Hubiera querido tratar más temas en el post pero creo que por hoy es suficiente 🙂 Por favor, dejad vuestros comentarios, sugerencias y aportaciones que serán bienvenidos!
Hasta la próxima,
Sebastián Greco
Hola,
Segunda parte del estudio para la preparación del VCAP-DCA. En la parte 1 ya vimos la información correspondiente a Identificar tipos de RAID. Lamento no poner dibujitos y esas cosas 🙂 aunque en los links que se referencian hay dibujos de sobras! Recordad que esto es sólo una guía de estudio personal que comparto y que os recomiendo que además de leer este fantástico blog 😉 vayáis a las fuentes y esto sirva más bien a modo de resumen. Como dijo el filósofo «The Truth Is Out There»
Para seguir un mismo guión, y darle cierta consitencia a los posts iré dejando constancia de los conocimientos, habilidades y herramientas que hay en el blueprint del VCAP-DCA así como el contenido escrito por mi y los puntos a tratar en el post, enmarcados por asteriscos «*».
Conocimiento:
Identificar tipos de RAID.
*Identificar tipos de HBA soportadas.*
*Identificar formatos de discos virtuales.*
Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como «re-firma» me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento «profil-driven».
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.
Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV
Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop
Contenido:
Identificar tipos de HBA soportadas
Las HBA o Host Bus Adapter son tarjetas con conectores que van en nuestros servidores. Los hay de varios tipos:
– FC
– iSCSI
– SCSI
– SAS
– SATA
– eSATA
– etc
Normalmente, uno en el mundillo de la virtualización se refiere a HBA cuando está hablando de tarjetas con conectividad FC. Las de iSCSI aunque también son HBAs, uno se suele referir a ellas como «tarjetas de red» con o sin TCP offload.
Las HBAs pueden ser físicas o virtuales siendo las HBA físicas encargads de empaquetar los I/O según las reglas del protocolo en cuestión (FC, SCSI, NFS, etc) y de transmitir la señal a la SAN. Cuando las HBA son virtuales, sobra decir que quien se encarga de estas tareas es nuestro micro. Aquí está la diferencia entre las tarjetas con TCP offload y las que no lo tienen. Las tarjetas de red con TCP offload descargan al micro de todas estas tareas y son ellas quienes asumen la carga. Existen 3 tipos de offload siendo el más común entre las HBA iSCSI la de «HBA full offload» que también se encarga de las tareas típicas del «initiator».
En cuanto a recomendaciones de buenas prácticas, he escuchado de todo. Hay quien sostiene que no se recomienda mezclar distintos tipos de HBA en un mismo HOST y hay quien sostiene que sí, puesto que en caso de tener algún problema con un driver de esa HBA afectará sólo a una…este «debate» lo dejo abierto aunque en la documentación oficial de VMware lo deja bastante claro «Do not mix FC HBAs from different vendors in a single host. Having different models of the same HBA is supported, but a single LUN cannot be accessed through two different HBA types, only through the same type.»
Sí que hay que tener en cuenta el número máximo de HBAs que se pueden tener en un host. En el documento de «Configuration Maximums» se ve claramente que hay un máximo de 8 HBAs y de 16 puertos.
Tras esta brevísima introducción a las HBAs, veamos ahora cuáles son los tipos de HBA soportados por vSphere y su identificación.
La lista sería interminable, basta con buscar en la HCL de VMware para darnos cuenta que «enumerarlas» no será una pregunta 🙂 Entonces…clasificarlas? Creo que la mejor opción sería limitar el estudio a las que aparecen en el espacio de nombres del comando «esxcli storage san»:
Available Namespaces:
fc IO Device Management operations to the FC adapters on the system.
fcoe IO Device Management operations to the FCoE adapters on the system.
iscsi IO Device Management operations to the Software iSCSI adapters on the system.
sas IO Device Management operations to the SAS adapters on the system.
Y los CNA? Son los «fcoe». Creo que esta pequeña lista es un buen punto de referencia porque repito, sería absurdo conocerse la lista de HBAs en la HCL y no creo que algo parecido sea objeto de examen.
Empezaremos por las CNA. Cuando conectamos una y vSphere la ve, la reconocerá (si tenemos el driver instalado) y mostrará 1 FC (vmhba) por un lado y el componente ethernet (vmnic) por otro. Por tanto, aunque este tipo de HBA esté soportado de forma nativa, lo gestionaremos como si se tratase de 2 tipos de HBA distintos. Se verá también que aunque muestre «vmhba», en la descripción mostrará que se trata de FCoE. Es importante desde un punto de vista de diseño, entender que la HBA sigue siendo una y que por tanto, networking de datos y de storage van por el mismo cable, invalidando para la mayoría de los casos el «datastore heartbeat» de HA.
Una nueva característica de vSphere 5.5 es la capacidad de gestionar NICs de hasta 40 Gb. Para FC, nos encontramos con el tope de 16Gb. También nuevo en la versión 5.5 que estos 16Gb sean end-to-end ya que en versiones anteriores de vSphere aunque los 16GB también se soportaban, había que «caparlos» a 8Gb. FCoE 10Gb e iSCSI 10Gb.
Para escoger un tipo de arquitectura u otro, normalmente el precio suele ser determinante. También es importante ver distancias y latencias…no sólo la cantidad de «Gb». Otro factor a tener en cuenta es el «coste» de la encapsulación y las repercusiones de un tipo u otro de protocolo. El ejemplo más claro y el que más había que tener en cuenta hasta la aparición de las «ATS», eran los locks a nivel de LUN de las reservas SCSI. Estas consideraciones simplemente las menciono y no entro en detalle porque no me quiero ir mucho de tema…el «conocimiento» requerido en este punto, a mi entender, ya estaría más que cubierto con la información aquí puesta.
Identificar formatos de discos virtuales
Este es un tema que me gusta bastante 🙂 y del cual tomo bastantes consideraciones a la hora de diseñar una o varias VMs.
Al igual que tantas cosas en virtualización, tener este conocimiento es genial ya que no solo aplica a VMware…con distintos nombres también aplica a otras tecnologías de virtualización. Para no estirar más el tema, los formatos de discos virtuales con vSphere son 3:
Thin
Thick EagerZero
Thick LazyZero
Thin
Este formato de disco permitirá hacer «overprovision» de amlacenamiento. Digamos que nos permite «mentirle» a la VM diciéndole que tiene un disco de un determinado tamaño (20GB por ejemplo) cuando en realidad sólo estará consumiendo el espacio que haya utilizado.
Aquí hay que hacer una pequeña pausa y explicar bien. Primero con un ejemplo el funcionamiento de Thin Privisioning de disco:
1 VM con un disco duro virtual de 20GB en formato Thin. Si le instalamos un Windows 7 y un par de programitas básicos, lo normal sería que consumiera de nuestro storage unos 5-6 GB. Aunuqe la VM crea que le hemos dado 20GB.
Puede darse el caso de que una VM que muestre desde el propio S.O. una ocupación de 6GB por ejemplo, esté ocupando los 20GB en nuestro storage. Esto se debe a que Thin Provisioning funciona de forma tal que una vez que cambia un bloque en el disco, el bloque queda «ocupado» con o sin información, pero queda ocupado. Por este motivo, inclusive borrando información desde la propia VM, el disco (.vmdk) no reducirá su tamaño. Por esto es importante entender que «defragmentar» un disco duro virtual en Thin Provisioning puede traer consecuencias negativas y que hacer un «Thin provisioning» para luego formatear (no con el formato rápido…con el otro lento que no usa nadie 🙂 )el disco no tiene sentido porque escribiremos en todos los sectores del mismo y el provisionamiento «Thin» perderá sentido.
Para reducir la ocupación de un disco en Thin Provisioning como el del ejemplo (6GB de información pero 20GB de ocupación en nuestro storage). VMware implementó con la ayuda de los fabricantes de storage las VAAI. Una de las funciones de estas VAAI es la de hacer un «Thin Provisioning Block Space Reclamation» mediante una «primitiva» denominada «UNMAP». Mediante este mecanismo vSphere informa al storage que que cierta información se borró o movió de determinado .vmdk, una vez hecho esto, el storage sería capaz de volver a marcar como «vacío» ese espacio. Esta funcionalidad al principio era automática (vSphere 5.0). Como daba problemas VMware recomendó que se deshabilitara esta funcionalidad y luego mediante parches, ya se encargaron de deshabilitarla ellos. Cuando finalmente solucionaron los problemas, el automatizmo siguió deshabilitado y había que trabajar con vmkftools para reclamar el espacio. Actualmente en la versión 5.5 y aunque siga sin ser un mecanismo automático, se puede reclamar el espacio mediante esxcli.
esxcli storage vmfs unmap (-l si queremos especificar el nombre del volumen o -u si queremos especificar el uuid).
Si queréis más info al respecto de UNMAP, Jason Boche en su blog hace un muy buen trabajo explicándolo. http://goo.gl/JaqjoZ
La forma normalmente utilizada es la de hacer un «Storage vMotion» ya que esta operación también reduce el .vmdk a su ocupación más mínima posible.
Por suerte, ya desde la versión 5.0 se incluyen alertas que monitorizan el crecimiento de los discos en ThinProvisioning y alertan antes de que se llene un datastore. Además, otra mejora es que si actualmente se llena un datastore, se ponen en «pause» las máquinas que quieren escribir en el mismo y no pueden. Las otras siguen trabajando con normalidad. Esto antes no era así…si se llenaba un datastore se pausaban todas las VMs que estaban en él.
Thin Provisining tiene la ventaja también de que es un tipo de disco muy rápido de crear y la desventaja de que mientras se «expande», dará un rendimiento más pobre a nuestra VM ya que además de escribir la información que queremos que se escriba en disco, se tendrán que actualizar los metadatos del mismo e inicializar el sector donde se quiere escribir la información. Este efecto desaparece una vez el .vmdk alcanza su tamaño máximo (en nuestro ejemplo de 20GB).
Thick Eager Zero
Los tipos de disco «Thick», reservan el espacio con el que creamos el .vmdk en nuestro storage y lo muestran ocupado. Por tanto, si creamos un disco thick de 20GB, en nuestro storage veremos que hay 20GB menos disponibles. Que el disco sea «Eager Zero», quiere decir que al momento de crear el .vmdk, vSphere escribirá 0s en todos los bloques de este disco para inicializarlo. Esto hace que su creación sea mucho más lenta (aunque ahora hay VAAIs que aceleran mucho el proceso) pero que su rendimiento sea óptimo. También evita sorpresas y sustos como los que uno puede tener con discos de tipo «thin» donde un crecimiento de los mismos sin control, puede ocasionar caídas a nivel de datastore.
Thick Lazy Zero
Para los entendidos en inglés, «lazy» que quiere decir perezoso y un disco «Lazy Zero» a diferencia de un «Eager Zero» NO escribe 0s en todos los bloques del mismo. Esto tiene un impacto directo en el tiempo que tarda en crearse este disco (será mucho más rápida su creación) y también en que no será tan rápido a la hora de «trabajar» como un disco «Eager Zero» puesto que al momento de escribir por primera vez en un bloque, deberá inicializarlo.
Un tema interesante por ver pero que queda fuera de este estudio, es si utilizar Thin Provisioning desde vSphere, desde el Storage o desde ambos. En este sentido, Cormac Hogan, gurú en temas de storages y además un tipo de lo más simpático, escribió en su blog un artículo más que interesante y casi de lectura obligada http://blogs.vmware.com/vsphere/2012/03/thin-provisioning-whats-the-scoop.html
Bibliografía utilizada para este post:
http://en.wikipedia.org/wiki/Host_adapter
http://en.wikipedia.org/wiki/TCP_offload_engine
Haz clic para acceder a Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf
http://goo.gl/gj9vJ4
http://goo.gl/cdY5E1
http://goo.gl/ll0689
http://blogs.vmware.com/vsphere/2013/09/a-summary-of-whats-new-in-vsphere-5-5.html
http://blogs.vmware.com/vsphere/tag/iscsi
http://www.mikelaverick.com/2013/09/vmworld-2013-whats-new-in-vsphere5-5-storage/
http://blogs.vmware.com/vsphere/2011/12/vmwares-software-fcoe-adapter.html
http://blogs.vmware.com/vsphere/2011/12/vmwares-software-fcoe-adapter.html
http://blogs.vmware.com/vsphere/2012/03/thin-provisioning-whats-the-scoop.html
http://goo.gl/JaqjoZ
Hasta aquí el post de hoy. Espero que os haya gustado. Tened en cuenta que esto es un guía de estudio y que en todos los aspectos me considero un estudiante por lo que si tenéis algo que queráis aportar, será más que bienvenida vuestra participación 🙂
Saludos,
Sebastián Greco
Hola,
Empieza mi aventura para obtener el VCAP-DCA…a ver si llego! Puesto que normalmente tomo notas de lo que estudio y la mejor forma de aprender para mi es «hacerlo con cabeza de luego tener que explicarlo», intentaré en la medida de lo posible, ir agregando posts con los distintos objetivos del blueprint. Como mi amigo @pipoe2h me recomendó por twitter: «blueprint y ármate un laboratorio con 2 hosts y vCenter y a seguir el blueprint» 🙂 Ya que sabe de lo que habla y además lo hace desde la experiencia puesto que tiene el VCAP-DCA y el VCAP-DCD…habrá que hacerle caso 🙂
No entraré en detalle de las distintas certificaciones que VMware tiene disponibles ni dónde entra el VCAP-DCA de vSphere. Si alguien quiere info al respecto, este es el link
http://mylearn.vmware.com/portals/certification/
Al lío pues y a ver qué sale.
Intentaré ir haciendo entradas en el blog según los objetivos del blueprint del examen. Para obtener el blueprint hay que registrarse (gratuito) y descargarlo desde el link correspondiente en la «Página oficial de VCAP-DCA».
Nota: Esto es parte de mi estudio personal en el cual me valgo de recursos oficiales y de la ayuda que ponen a disposición en la web otros profesionales. Referenciaré cada uno de los recursos utilizados por mi o bien en «links de interés» o dentro del mismo cuerpo de esta guía. No invento nada y posiblemente no aporte nada nuevo salvo mi forma de entender y explicar algunas cosas. De todas formas, espero que este material de estudio le sea de utilidad a alguien más 🙂
Sección 1 – Objetivo 1.1 – Implementar y gestionar soluciones complejas de almacenamiento
Conocimiento:
*Identificar tipos de RAID.*
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.
Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como «re-firma» me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento «profil-driven».
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.
Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV
Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop
Contenido:
Identificar tipos de RAID
Un RAID o redundant array of independent disks es una tecnología que permite agrupar 2 o más discos duros para obtener distintos niveles de rendimiento y/o redundancia (RAID 0 no ofrece redundancia). Escoger correctamente el tipo de RAID es imprescindible en el momento de diseñar una infraestructura ya que no solo afectará al rendimiento de la misma sino que también tiene una repercusión directa en los costes. Muy simplificado, esto sería: «Más rendimiento y más redundancia implican más o MUCHOS más discos».
Hay varios tipos de niveles de RAID y como es el objetivo en este punto, la idea es poder identificarlos.
Digamos que existen niveles de RAID que no merece la pena estudiar puesto que a efectos prácticos no se utilizan: RAID 2 y RAID 3 (obsoletos), RAID 4 muy raro de ver salvo en NetApp donde es más normal ver «RAID DP» (hace mucha gracia en los concursos públicos donde «no se pueden mencionar fabricantes» que describan una cabina con «RAID DP»…vamos, que no se nota! 😛 ) RAID DP así como otros tipos de RAID específicos de fabricantes (Hadoop, SHR, etc) tampoco los estudiaremos. RAIDs que sí son estandard pero que es difícil encontrar como los que mezclan un tipo de RAID con el RAID 0, también conocidos como «nested», tampoco los veremos a excepción de RAID 10 (RAID 0 y RAID 1). Lo importante de este último tipo de RAID es que combina lo mejor y peor de 2 tipos de RAID en cuanto a rendimiento, capacidad y redundancia.
También es importante entender que RAID se puede hacer tanto por hardware como por software. Como nota personal, ojo a las descripciones de los fabricantes de servidores ya que muchas veces las controladoras que soportan RAIDs y que vienen integradas en placa, soportan RAIDs pero por software, algo que para un host con vSphere no vale si es donde se quiere instalar ESXi. Asimismo, muchos tipos de RAID, necesitarán que se añadan componentes como baterías para las caché de las controladoras, etc.
Para todos los RAIDs veremos:
Penalización escritura: Cantidad de IOPS que son necesarias por cada operación de escritura. Menos es mejor.
Tolerancia a fallos: Cantidad de discos que el RAID se puede permitir perder. Más es mejor.
Nº mín. de discos: Cantidad mínima de discos necesarios para formar el RAID.
Nº de discos de redundancia: Cantidad de discos que utilizan su capacidad para mantener información redundante. La capacidad de estos discos, no suman a la capacidad «utilizable» por el usuario del volumen.
Aplicaciones típicas: Casos en los que se suele ver el tipo de RAID en cuestión.
Vale la pena destacar aquí para no tener que hacerlo en cada tipo de RAID, que si uno mezcla distintos tipos de HDD en un mismo RAID, cuando se tenga que leer/escribir información en el disco lento, el rendimiento será peor. Por tanto, un RAID puede llegar a ser tan bueno como su disco más malo.
Como último punto antes de ir a la descripción de cada tipo de RAID, creo importante entender que en términos de almacenamiento: latencia, buffers, interfaces, tipo de IOPS (lectura o escritura), tipos y cantidad de discos, procesadores de almacenamiento y una lista interminable de elementos más, determinan un funcionamiento óptimo o poco óptimo de nuestro almacenamiento…no todo se reduce en tipos de RAID.
RAID 0
Es un tipo de RAID que no ofrece redundancia. La forma más fácil de explicarlo es que se trata de una forma de hacer que varios discos sean visibles a nivel de S.O. como si fueran un único disco. Lo que hace es distribuir la información en 2 o más discos (todos los que formen el RAID). Si se agregan a un mismo RAID 0 discos de distintas capacidades, sumarán al RAID 0 la capacidad igual a la del disco más pequeño. Por esto, si hiciéramos un RAID 0 con 1 disco de 73GB y otro disco de 600GB, tendríamos un RAID 0 con 146GB.
En principio es un tipo de RAID que se utiliza o bien para disponer de un «disco» grande donde se suma de la capacidad de los discos que forman el, o para aumentar la performance de nuestro almacenamiento. Aunque según el tipo de información y la forma en que es accedida, esta mejora en la performance no siempre es perceptible ni real. El handicap más importante en este RAID es que basta que falle un (1) disco del RAID para que perdamos la información de todos los discos (existen herramientas que permiten recuperar parte de la información).
P. escritura: 1
Tolerancia a fallos: 0
Nº mín. de discos: 2
Nº de discos de redundancia: 0
Aplicaciones típicas: Workstations de diseñadores gráficos/Autocad, logging, equipos dedicados a la edición de video…también a los gamers les suele gustar este tipo de RAID 🙂
RAID 1
También conocido como «mirroring», este tipo de RAID «replica» la información de un disco o conjunto de discos (según lo que la controladora permita hacer) en todos los discos que forman el RAID. Como buena práctica general, lo ideal sería tener un disco o dataset en controladoras diferentes y que estas soporten hacer lecturas en paralelo para obtener mayor rendimiento en las lecturas.
P. escritura: 2
Tolerancia a fallos: n-1 o dicho de otra forma, «un dataset tiene que quedar en pie». Para el caso de un RAID 1 con 2 HDD, tolera que falle un disco. Si hay un RAID 1 con 3 HDD, tolera que fallen 2 discos y así.
Nº mín. de discos: 2
Nº de discos de redundancia: Al menos 50% del RAID.
Aplicaciones típicas: Bases de datos transaccionales, discos de sistema.
RAID 5
Este tipo de RAID es el más extendido ya que ofrece tolerancia a fallos a un bajo coste. También conocido como «distribuido con paridad» (sólo los muy frikis utilizan este término), este RAID distribuye la información de paridad (la que utiliza para reconstruir información en caso de pérdida de algún disco) entre todos los discos del RAID. Para generar esta información de paridad, RAID 5 debe realizar cálculos que son los que hacen que al escribir, haya una penalización tan alta. Es más, si se somete a un RAID 5 a operaciones de escrituras múltiples y pequeñas (más pequeñas que su tamaño de stripe), se sufrirá mucho más de esta penalización puesto que aumentará considerablemente el número de cálculos que se deban realizar.
A tener especial cuidado con este tipo de RAID en caso de cortes de luz, cuelgues en el sistema que está accediendo al RAID, etc. Si bien existen medidas que nos protegen de errores como los SAIs de las cabinas que permiten que lo que está en caché se escriba a disco, etc. existe el riesgo de que se pierda la consistencia en la paridad…de esta pérdida de consistencia no seremos conscientes hasta que se pierda un disco y se tenga que reconstruir la información. Por eso es importante monitorizar las alarmas de la cabina y reparar cualquier error que aparezca.
P. escritura: 4
Tolerancia a fallos: 1
Nº mín. de discos: 3
Nº de discos de redundancia: «0» La redundancia se distribuye entre todos los discos del RAID.
Aplicaciones típicas: Backup a disco, archiving, discos con ficheros (file servers)…también es «tipical spanish» utilizarlos para meter toda la infraestructura virtual sobre ellos por tema costes, aunque desde un punto de vista idealista y purista, no es lo recomendado.
RAID 6
Al igual que RAID 5, se utiliza un sistema de paridad distribuido simplemente que en este caso es doble. Digamos que almacena el doble de información de paridad en cada disco que un RAID 5. Esto ofrece ventajas como una mayor tolerancia a fallos (2 discos) inclusive durante operaciones de reconstrucción de un disco dañado aunque la penalización de escritura sea mayor (dije que no iba a hablar pero hay que mencionarlo, RAID DP es una especie de RAID 6 pero que es mucho más rápido gracias a una tecnología patentada denominada WAFL).
P. escritura: 6
Tolerancia a fallos: 2
Nº mín. de discos: 4
Nº de discos de redundancia: «0». La redundancia se distribuye entre todos los discos del RAID.
Aplicaciones típicas: Aplicaciones críticas, presentación de storage «grande» a servidores.
RAID 10
También conocido como RAID 1+0, es uno de los RAIDs tipo «nested» más utilizados, sino el que más. Básicamente combina el RAID 1 con RAID 0 de la siguiente forma conocida como «división de espejos»:
Exisitirá un único RAID 0 formado por RAIDs 1 en lugar de discos «sueltos». Parecido aunque no lo mismo que un RAID 01 del cual no se habla en este documento. No se han de confundir aunque se preste a la confusión.
P. escritura: 2
Tolerancia a fallos: Un disco por RAID 1 tiene que estar en pie.
Nº mín. de discos: 4
Nº de discos de redundancia: Al menos 50% del RAID.
Aplicaciones típicas: Bases de datos con mucha carga, servidores de aplicaciones con mucha carga.
Bueno, como esto está haciendo más largo de lo que me esperaba, «partiré» este objetivo en más de un post.
Aquí os dejo la bibliografía utilizada por mi para escribir lo que escribí y «no morir en el intento» 🙂
Links de interés:
Página oficial de VCAP-DCA – http://goo.gl/SHpUkS
http://wintelguy.com/raidcalc.pl
Guías de estudio:
http://www.vexperienced.co.uk/vcap5-dca/
http://www.valcolabs.com/vcap5-dca/
http://thefoglite.com/vcap-dca5-objective/
http://paulgrevink.wordpress.com/the-vcap5-dca-diaries/
http://www.seancrookston.com/blog/vcap-dca/
Bibliografía utilizada para este post (además de las ya mencionadas guías de estudio y links a docs de VMware):
http://en.wikipedia.org/wiki/RAID
http://en.wikipedia.org/wiki/Standard_RAID_levels
http://en.wikipedia.org/wiki/IOPS
http://es.wikipedia.org/wiki/RAID
http://www.yonahruss.com/architecture/raid-10-vs-raid-5-performance-cost-space-and-ha.html
http://shanibasha.blogspot.com.es/2011/02/all-about-iops-and-write-penalty.html
http://www.accs.com/p_and_p/RAID/BasicRAID.html
http://www.enhance-tech.com/press/raid-comparison-and-storage-systems.html
http://www.datarecovery.net/articles/raid-level-comparsion.html
http://www.adaptec.com/en-us/_common/compatibility/_education/raid_level_compar_wp.htm
http://www.netapp.com/us/communities/tech-ontap/tot-back-to-basics-raid-dp-1110.aspx
http://theithollow.com/2012/03/understanding-raid-penalty/
http://www.synology.com/en-us/support/tutorials/512
http://wintelguy.com/2013/20130406_disk_perf.html
http://wintelguy.com/raidperf.pl
Hasta la próxima!
Sebastián Greco
El post de hoy va dedicado a los requisitos y la instalación de vCloud Director y todos los servicios necesarios para ponerlo en marcha.
vCloud Director es la solución que nos proporciona VMware para poder ofrecer IaaS (Infraestructura entregada como un servicio) a los distintos clientes internos o externos que nos demanden este tipo de recursos. Como veremos a continuación, este tipo de solución necesita de productos adicionales que nos brinden la abstracción de los distintos recursos de computación, almacenamiento y servicios de red, y según el tipo de despliegue podremos automatizar en mayor o menor medida la provisión de los recursos de infraestructura virtuales necesarios. VMware ya se ha encargado que todos estos productos adicionales necesarios estén incluidos en el licenciamiento de su vCloud Suite.
Para poder desplegar vCloud Director necesitaremos tener desplegados:
Las buenas prácticas de VMware nos indican que siempre que podamos despleguemos un clúster de vSphere para ubicar los servidores de gestión del entorno (vCenter Server, vShield Manager, vCloud Director Cells, etc.) y uno o más clústers utilizados como granjas de computación y destinados a ubicar las cargas desplegadas dentro del entorno de Cloud. Podemos ver un ejemplo a continuación:
Esta configuración garantizará que en caso que haya algún problema en las granjas de computación, esto no afecte a los distintos servicios de gestión del entorno de Cloud.
Las vCloud Cells son las encargadas de, por un lado, proveer de un portal web de autoservicio y por otro lado de hacer de director de orquesta comunicándose con vShield Manager para la automatización del despliegue y destrucción de las redes creadas en este entorno, y con vSphere (vCloud y los hosts ESXi) para el despliegue de VMs, operaciones de encendido, apagado, snapshots, etc.
Las vCloud Cells necesitan de ciertos servicios adicionales que per-sé no proveen:
Load Balancer
Como bien hemos comentado, las vCloud Cells son servidores web, y por tanto si queremos ofrecer redundancia y además evitar que ninguna de nuestras Cells se sobrecargue necesitaremos balancear la carga. Para ello podemos utilizar cualquier producto existente en el mercado, como por ejemplo los balanceadores de F5, Riverbed, etc. aunque podemos también buscar una opción comercial y además gratuita para nuestro entorno: vShield Edge.
vShield Edge, para el entorno de vCloud viene licenciado dentro del recientemente renombrado paquete «vCloud Networking and Security» y entro otros servicios típicos de un Firewall (VPN IPSec, SNAT, DNAT, DHCP, etc) también nos puede ofrecer balanceo de carga y podemos aprovecharlo para balancear también nuestras vCloud Cells. Cabe destacar que también, a partir de vCloud 5.1, se puede configurar este balanceo de carga desde el Web GUI de vCloud Director.
Share NFS
En caso que queramos desplegar más de una vCloud Cell (Entiendo que en 99,9% de los casos que queramos entrar en producción) necesitaremos de un recurso compartido NFS que será donde guardaremos los datos comunes a los que necesitan acceder las distintas vCloud Cells. En este share NFS se ubicarán:
Ojo, la gestión y guardado de los archivos mencionados es realizado por vCloud, así que no deberemos copiar manualmente las ISOs ni plantillas en este recurso compartido, sino deberemos hacerlo a través de vCloud Director.
Aunque no necesario, también es recomendable ubicar en este recurso compartido:
La recomendación de ubicar también estos archivos es debido a que cada vez que debamos añadir una nueva vCloud Cell, necesitaremos de estos archivos, y de esta manera evitaremos tener que ir copiando archivos a las Cells a través de ssh y los tendremos ubicados en un almacenamiento visible por todas las Cells.
Base de Datos
Por último, el ingrediente que nos falta para tener las vCloud Cells totalmente funcionales es un servidor de Base de Datos. vCloud soporta 2 tipos de bases de datos desde la versión 5.1: Oracle DB y Microsoft SQL Server. No entraremos más en detalle respecto a estos tipos de servicios, que son ya de sobras conocidos. Tan solo a nivel de puntualización, comentar que al contrario que otros productos de VMware donde tenemos un asistente «siguiente, siguiente», para la creación de nuestra base de datos deberemos lanzar unos cuantos scripts contra nuestra BBDD proporcionados por VMware y que harán un poco más tediosa nuestra instalación.
Seguiremos en los próximos posts con los distintos tipos de redes que nos encontramos en vCloud, tipos de Network Pools, Virtual DataCenters, etc. Manteneros atentos!
Saludos,
Sergi de la Torre
Hola amigos!
Como algunos de vosotros habréis visto, nuestro laboratorio no cuenta con discos duros locales en los hosts, con lo que hay que buscar otras alternativas para la ejecución del hypervisor en los mismos.
Para quienes lo hayáis hecho anteriormente, seguramente se trate de un procedimiento que no ofrece ningún desafío. Sin embargo, para quienes no lo habéis hecho o tenéis dudas de su funcionamiento, veréis que es fácil y puede ser muy cómodo además de económico (servidores sin disco duro pueden resultar en un ahorro nada despreciable).
Antes de ir al lío, unas consideraciones generales del sistema y la BIOS:
– Se deben cumplir los requerimientos mínimos de hardware de cada uno de los fabricantes.
– Activar virtualización ahí donde sea posible 🙂 (EPT, RVI, VT-x, etc).
– Deshabilitar dispositivos que no se van a utilizar es otra buena idea…por ejemplo puertos paralelos.
– Se recomiendan configurar los modos de ahorro de energía a “OS Controlled Mode” o similar, así como asegurarse que están todos los cores habilitados.
– Ambos sistemas son “NUMA aware” por lo que casi mejor activarlo en la BIOS. Normalmente suele ser una configuración llamada “Node interleaving” que hay que dejar en estado “Disabled”. “Enabled” significa que está en modo UMA de Uniform Memory Access.
– Si es posible, habilitar Hyperthreading y/o Turbo Boost.
– Ya que la idea es “arrancar” desde un USB, el orden de arranque es importante. Comprobad que USB esté primero o en su defecto, utilizar las opciones de arranque para seleccionar el FBD (First boot device).
Empezaremos por la configuración de un USB con vSphere, como bien explica Bolo Álvarez en su blog – http://mecongratula.es/, el procedimiento es el siguiente:
vSphere (4 pasos extremadamente simples)
1) Descargar y ejecutar UNetbootin – http://unetbootin.sourceforge.net/
2) Descargar la ISO de ESXi – https://my.vmware.com/web/vmware/evalcenter?p=free-esxi5&lp=default (necesitaréis crearos una cuenta en caso que no dispongáis de una)
3) Formatear el USB en FAT32.
4) Ejecutar UNetbootin y “planchar” la ISO del ESXi en el USB. Precaución, esto borrará los datos del dispositivo que escojáis como destino. Aseguraos que el destino seleccionado es el USB que queréis.
HyperV Server (12 pasos basándome en esta guía http://technet.microsoft.com/en-us/library/ee731893(WS.10).aspx)
1) Crear un VHD y montarlo.
– Lanzar un cmd y ejecutar las siguientes líneas:
– mkdir c:\hvvhd
– diskpart
– create vdisk file=c:\hvvhd\hyperV.vhd maximum=12288 type=fixed
– select vdisk file=c:\hvvhd\hyperV.vhd
– attach disk
– create partition primary
– assign letter=r
– format quick fs=ntfs label=hyperV
– exit
En este primer paso se creará un directorio de nombre “hvvhd” y desde la utilidad de “diskpart” se creará un disco virtual de nombre “hyperV.vhd” dentro del directorio “hvvhd” que se creó anteriormente. Este disco virtual tendrá un tamaño fijo de 12288 KB (para nuestro chubascos lab utilizamos 6144 puesto que nuestros USB son de 8 GB), lo que equivale a 12 GB. Dentro de este disco virtual se creará una partición de nombre “r” y se la formateará con un formato “rápido”, un file system de tipo “ntfs” y se le dará el nombre “hyperV”.
2) Descargar e instalar Windows AIK (necesitaréis una cuenta para descargaros algunos elementos de esta guía)
http://go.microsoft.com/fwlink/?LinkId=136976
Esta guía hace referencia a la ruta de instalación por defecto de este software.
3) Descargar y montar la imagen de Windows Hyper-V Server
http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx
Nota: El archivo .wim al que se hará referencia en el siguiente punto está en la carpeta “sources” de esta ISO.
4) Aplicar el archivo install.wim en la partición del VHD que se creó en el paso 1 de esta guía.
Para ello, lanzar el cmd como usuario “Administrador” y ejecutar las siguientes lineas:
Ruta_Windows_AIK\Windows AIK\Tools\arquitectura\imagex.exe /apply path_al_wim 1 r:\
5) Desmontar el disco virtual
Para ello, ejecutar los siguientes comandos en el cmd.
– diskpart
– select vdisk file=c:\hvvhd\hyperV.vhd
– detach vdisk
– exit
6) Preparar el USB
Primero, identificar el disco con los siguientes commandos.
– diskpart
– list disk
Siguiente, limpiarlo, particionarlo y formatearlo.
– select disk número_del_USB_que_nos_devolvió_el “list disk”
– clean
– create partition primary
– select partition 1
– active
– format quick fs=ntfs label=hyperV
– assign letter=z
7) Copiar el .vhd al USB
8) Compatibilizar el USB con Bootmgr
ruta_Windows_AIK\Tools\PETools\arquitectura\bootsect.exe /nt60 x: /force /mbr
9) Montar el .vhd del USB
– diskpart
– select vdisk file=z:\HyperV.vhd
– attach vdisk
– exit
10) Hacer el USB booteable
ruta_Windows_AIK\tools\arquitectura\bcdboot letra_partición_VHD\windows /s letra_partición_USB
11) Deshabilitar paging (la fresa en la nata)
Esto es por temas de performance, podéis probar sin hacerlo pero funciona mejor siguiendo esta recomendación de Microsoft.
Para ello hay que cargar el hive del registro del VHD del USB y configurar las entradas necesarias de las Page Files.
– reg load HKLM\HyperVTemp r:\windows\system32\config\system
– reg add «HKLM\HyperVTemp\ControlSet001\Control\Session Manager\Memory Management» /v PagingFiles /t REG_MULTI_SZ /d «» /f
– reg delete «HKLM\HyperVTemp\ControlSet001\Control\Session Manager\Memory Management» /v ExistingPageFiles /f
– reg unload HKLM\HyperVTemp
12) Desmontar el VHD y quitar el USB
– diskpart
– select vdisk file=x:\hyperV.vhd
– detach vdisk
– exit
Sí, el proceso de creación de este USB puede resultar más largo para HyperV Server y en mi experiencia personal, más complicado. Otra alternativa es intentar utilizar esta herramienta para facilitar el proceso.
http://archive.msdn.microsoft.com/BootHVSR2FromUSB. No la he probado y por lo que vi tiene algunas limitaciones que podrían hacer que no valiera para una instalación de la versión 2012 y menos en castellano. Pero bueno, a veces estas cosas aunque no lo especifiquen sí funcionan…todo es cuestión de probar.
Espero que os haya gustado esta pequeña guía que reúne en un único post, algo de lo que normalmente no se habla en las comparativas tipo “checklist” que tanto me disgustan.
En futuros posts intentaremos comentar un poco cómo se consigue levantar el hypervisor desde estos dispositivos USB y controlarlo remotamente.
Si este post ha sido de vuestro agrado o creéis que pueden resultar de interés para otros, por favor compartidlo en vuestras redes sociales 🙂 Si además tenéis algo que decir o aportar, por favor dejad un comentario!
Gracias por leernos,
Sebastián Greco
Muy buenas a todos,
Mi nombre es Sergi de la Torre y vamos a dedicar el post de hoy a un producto que parece que este año va a dar mucho que hablar, en concreto nos referimos a VMware Horizon Mirage.
Muchos de vosotros lo conoceréis, y tal vez muchos será la primera vez que escucháis al respecto de este producto. Horizon Mirage no es un nuevo software recién sacado del horno por VMware sino que se trata del software de la compañía Wanova que el año pasado VMware adquirió y que actualmente ha integrado dentro de su portfolio dirigido a las soluciones de EUC (End User Computing) y que como bien he comentado dará mucho que hablar.
¿Qué es VMware Horizon Mirage?
Horizon Mirage se trata una de las soluciones que proporciona VMware para reducir de manera dramática el OpEx (Operational Expenses) consiguiendo reducir los recursos necesarios para mantener nuestra infraestructura de microinformática.
¿Cómo explicar de manera rápida, y sencilla que és Mirage? Bien, la manera más resumida para dar una idea clara de que es Mirage cuando alguien me pregunta es: “¿Conoces la virtualización de escritorios? ¿Conoces las ventajas que proporciona a nivel de gestión centralizada de los desktops? ¿Los ahorros en OpEx que te facilita? Bien, pues Horizon Mirage te ofrece la misma facilidad y ahorros en OpEx pero sin ningún tipo de virtualización, es decir, la ejecución del Sistema Operativo y las aplicaciones sigue siendo en local, en el dispositivo final del usuario”
¿Cómo funciona Horizon Mirage?
Para poder explicar el funcionamiento de la solución, explicaremos como segmenta las distintas partes de un desktop/laptop y como se gestionan en nuestro servidor.
Mirage trabaja con un conjunto de capas claramente diferenciadas y nos permite poder intercambiar estas capas desde nuestro servidor central sin ningún tipo de intervención del usuario (miento aquí, el usuario deberá reiniciar su equipo para aplicar los cambios de capa. Complicado, eh!?). Podemos ver a continuación las distintas capas que gestiona el sistema:
Podemos ver 2 categorías claras: las capas gestionadas por el usuario y las capas gestionadas por el personal de TI.
Las capas gestionadas por el usuario son sus propios datos, su configuración (fondo de pantalla, favoritos, etc) así como las aplicaciones que él mismo se instale sobre su equipo
En cambio, las capas gestionadas por TI son:
Arquitectura de la solución
¿Que mejor explicación para la arquitectura que una imagen?
Como podéis ver, el despligue de Horizon Mirage consta de distintos elementos. Pasamos a detallar estos elementos a continuación:
– Storage Volumes. Se trata de los volumenes donde se almacenarán los distintos datos tales como las imagenes base, las capas de aplicación, la librería de drivers, los datos de usuario,e tc. Estos Storage Volumes será recomendable presentarlos como un recurso compartido a través de CIFS para poder ser usados por varios Mirage Server, ya que esto nos permitirá poder redundar y balancear la carga entre distintos servidores, aunque en cualquier caso están soportados los almacenamientos tipo SAN, NAS y almacenamiento local.
– Mirage Servers. Se trata de el/los servidores/es encargados de la transferencia de los ficheros y de la comunicación con los dispositivos finales. Deberemos desplegar varios de servidores con este rol cuado nos interese proporcionar toleráncia a fallos o bien si necesitamos escalar para poder dar servicio a un número mayor de dispositivos finales. Recordemos que cada Mirage Server soporta 1.500 dispositivos gestionados (si se trata de un servidor físico) o 300 dispositivos gestionados (servidor virtual). El número máximo de serivodres en el clúster es de 10 nodos.
– Mirage Management Server. Este servidor es el encargado de la gestión y administración de nuestro clúster de Servidores de Mirage. Un único nodo gestionará los distintos Mirage Servers que tengamos. Necesita de un servidor de base de datos, en concreto una BBDD de Microsoft SQL Server
– Mirage Management Console. No se trata de un servidor en si, pero será el punto desde el que gestionaremos el entorno. Se trata del entorno gráfico que nos proporcionan para el Mirage Management Server. Esta consola se instala como un Snap-In de MMC.
A nivel de conectividad desde los clientes hacia el/los servidor/es de Mirage podemos ver que podemos conectar desde la mayoría de tipos de conexión: LAN, WAN e Internet. Es importante mencionar que Mirage dispone además de la deduplicación que hemos comentado anteriormente en almacenamiento, deduplicación a la hora de enviar los bloques, con lo cual, antes de enviar ningún bloque a través de la red realiza las siguientes optimizaciones:
Con esto el sistema consigue reducir enormemente el tráfico necesario a enviar. Así mismo, no se enviará ningún archivo que ya resida en el servidor a la hora de realizar la cópia. En caso que ese archivo ya se encuentre en el servidor, en su lugar se almacenará un apuntador hacia el archivo existente, con lo cual también tendremos una reducción del espacio en disco.
En cuanto a las oficinas remotas, también existe una funcionalidad muy interesante llamada Branch Reflector. Esta funcionalidad permite seleccionar un equipo cliente como servidor dentro de la sede. Este equipo seguirá siendo usado por un usuario, pero a la vez será el repositorio de las imagenes y dónde accederán a descargar las nuevas capas los distintos equipos que se encuentren en esa sede. Esto consigue que las imágenes solo sean descargadas una única vez desde la sede hacia el Branch Reflector y este las distribuya entre los distintos equipos de manera local.
Todo esto es muy bonito y interesante pero, ¿Para que puedo usar Mirage?
Mirage es un producto que podemos usar para el dia a dia en la administración de los dispositivos finales, pero los casos de uso más claros tratamos de exponerlos a continuación:
a) Migración de Windows XP a Windows 7
Como hemos comentado, Mirage nos segmenta cada una de las maquinas en distintas capas que podemos intercambiar sin ningún problema. Una de estas capas es la de sistema operativo, con lo cual nos permite migrar de manera muy fácil nuestro parque de Windows XP hacia Windows 7.
b) Disaster Recovery
Un usuario pierde su portátil en el aeropuerto, o bien el disco duro muere, o se le ha caído el café encima… Todos sabemos que pueden pasar mil cosas! Bien, como hemos comentado todos los datos del equipo del cliente están guardados en nuestro servidor Mirage, desde el S.O., las aplicaciones, sus datos, sus configuraciones… Mirage dispone de un asistente para que en caso que ocurra cualquiera de estas desgracias poder mover estos datos hacia otro equipo y el equipo esté exactamente igual que el anterior, con sus datos, configuración, apps, etc.
c) Cambio de equipos PC
Como os podéis imaginar este caso es exactamente igual que el anterior, así que no hay ningún problema en hacerlo.
d) Entrega/actualización de aplicaciones de manera centralizada
Al poder entregar distintas capas de manera centralizada, podemos hacer llegar nuevas aplicaciones o bien actualizaciones de aplicaciones que tiene el usuario sin que el administrador se tenga que levantar de su mesa. Bueno… dejémosle que se levante a tomar un café al menos y lance el despliegue 😉
¿Es Horizon Mirage competencia de Horizon View?
La respuesta es: ¡Rotundamente No!
La apuesta de VMware por este producto es para poder ofrecer una solución completa para la gestión del parque de microinformática para todas las distintas necesidades y distintos perfiles que podemos encontrar dentro de una empresa.
Uno de los mensajes que suelo lanzar cuando tengo una conversación respecto a virtualización de escritorios es: “Si alguien te dice que puedes virtualizar el 100% de tus escritorios, huye, esa persona te está mintiendo”. De la misma manera usaría el mismo mensaje en cuanto a Horizon Mirage. Debemos tener en cuenta que según las necesidades de cada usuario será necesario ir hacia una solución u otra, o incluso la combinación de ambas soluciones.
En este sentido creo que el movimiento de VMware en su aproximación hacia una solución global para los dispositivos de usuario final es muy acertada, y con ello han sacado la llamada Horizon Suite.
Horizon Suite no es más que un paquete que incluye los distintos productos tales como: View, Mirage y Horizon Workspace, consiguiende ofrecer una solución global a los problemas actuales de la informática de usuario. Obviamente es posible que no necesitemos todos los productos o realicemos una aproximación por fases, en ese caso todos los productos se pueden seguir adquiriendo por separado.
Bien, esto es todo por hoy respecto a Mirage. Espero veros pronto con los siguientes posts de Mirage enfocados a su instalación, administración y casos de uso.
Saludos!!
Sergi
Hola amigos,
En esta nueva entrada hablaremos sobre uno de los aspectos que más confusión crea a la hora de virtualizar Oracle sobre vSphere, el licenciamiento.
Antes de ir al lío, permitidme ahorrar la lectura del artículo entero a quien simplemente quiera respuesta a la eterna pregunta:
¿Tengo que licenciar todos los procesadores físicos del host si únicamente presento 1 vCPU a la VM con Oracle?
La respuesta rápida es “SÍ”.
La respuesta un poco más larga es “Sí, para todos los servidores en los que se vaya a ejecutar Oracle y en caso de utilizar un modelo de licenciamiento por procesador y no por usuario además de utilizar una tecnología de virtualización distinta a Oracle VM configurado de la siguiente forma:
http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf
Veréis que en el documento antes mencionado se habla de la capacidad de ofrecer “hard partitioning” con Oracle VM gracias a su funcionalidad de “pinning” que a primera vista y sin conocer en profundidad su funcionamiento, se parece mucho (por no decir que es lo mismo) a las funcionalidades conseguidas con la afinidad de CPU de VMware. Dicho esto, Oracle tilda su tecnología como “hard partitioning” y la de VMware como “soft partitioning”. Soft partitioning no ofrece ninguna ventaja a efectos de licenciamiento con Oracle y hard partitioning sí.
Eso sí, recordad que si bien Oracle VM permite realizar “hard partitioning”, lo hace bajo ciertas condiciones:
Live migration of CPU pinned virtual machines to another Oracle VM Server is not permitted under the terms of the hard partitioning license. Consequently, for Oracle VM 3, DRS (Distributed Resource Scheduler) and DPM (Distributed Power Management) policies should not be enabled for server pools containing CPU pinned guests.
Sobre el licenciamiento:
– ¿Qué dice VMware al respecto?
– Existe un tipo de licenciamiento llamado “Named User Plus”. Para este tipo de licenciamiento no hay ningún impacto en utilizar vSphere.
http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf
Este licenciamiento lo utilicé una única vez en la que necesité licenciar Oracle para albergar únicamente la base de datos del propio vCenter y Update Manager y en la que se utilizaría un único usuario para trabajar con las bases de datos tanto de forma directa como indirecta. Opción mucho más económica que otro modelo de licenciamiento para este escenario.
– La mayoría de las tecnologías de Oracle se licencian por socket físico o core sobre el cual se “instala” o ejecuta. Este es el tipo de licenciamiento sobre el cual se discute generalmente. Lo de “instala” lo pongo entre comillas porque es la definición que utiliza el propio Oracle y la quería dejar reflejada, aunque desconozco y dudo que exista la posibilidad de “instalar” software en un procesador…
Sobre este tipo de licenciamiento, estas son algunas características:
http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf
Digo lo de “en líneas generales” porque existen ciertas excepciones.
| Funcionalidad VMware | Requerimiento de licencia en primario | Requerimiento de licencia en secundario |
|
HA |
SÍ |
Con storage compartido en el mismo site, NO hasta 10 días por año |
|
vMotion |
SÍ |
NO hasta 10 días por año |
|
Fault Tolerance |
SÍ |
SÍ |
|
SRM |
SÍ |
SÍ, si se replican los ejecutables de Oracle. NO si se utiliza backup. |
Para obtener información más exhaustiva, seguir el siguiente link:
http://www.oracle.com/us/corporate/pricing/sig-070616.pdf
En la página 20 está lo de los 10 días.
Adicionalmente a lo ya comentado, se pueden ver los registros para comprobar los movimientos de las VMs.
Sobre las ediciones:
Poco podré decir que no diga el propio Oracle en su página Web.
http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html
Sin embargo me gustaría destacar algunas cosas:
– Oracle Database Standard Edition:
En cuanto a Oracle XE, explico en una entrada de mi blog personal de la VMware Community porqué no es válido para ejecutar sobre él, las bases de datos de vCenter ni siquiera para entornos de prueba/laboratorio.
Reducción del número de licencias en entornos de recuperación ante desastres
En el siguiente diagrama se enseña un modelo de Disaster Recovery utilizando VMware Site Recovery Manager y en el que se intenta evitar “sobre-licenciar” la infraestructura. Por lo menos hasta que ocurra un desastre y haya que hacer un failover.
La idea es simple:
1) Replicación asíncrona de las bases de datos (no de los ejecutables).
Con esto tendremos a resguardo y disponible la información.
2) Pruebas de recuperación de las copias en los hosts licenciados en el site primario.
Simplemente para verificar que lo que estamos copiando, es recuperable. En este escenario las pruebas se realizan utilizando la WAN que nos une al site secundario, con el impacto correspondiente en el rendimiento. Pero bueno, se trata de probar la fiabilidad del sistema y el rendimiento no es un factor relevante en este tipo de pruebas.
3) En caso de tener que realizar un failover, habrá que licenciar los nodos en el site secundario según se vayan a utilizar.
Resumiendo:
Existen varias formas de licenciar y varias ediciones de Oracle siendo el licenciamiento por socket el más debatido.
VM 3 de Oracle es el único hipervisor que permite no tener que licenciar todos los procesadores físicos sino los procesadores virtuales que la máquina virtual que ejecuta Oracle utiliza. Existen ciertas condiciones que se deben cumplir para que esto sea así.
Existen formas de reducir el número de licencias necesarias incluso con VMware, si se diseña el entorno aprovechando al máximo las capacidades de las soluciones de VMware y conociendo los modelos de licenciamiento de ambos fabricantes.
Cualquier host de VMware ha de contar con todos sus procesadores físicos cubiertos por el licenciamiento de Oracle. Esto también permite que se puedan crear n máquinas virtuales que ejecuten Oracle sobre ese host.
Espero haber aclarado algunas cosas y haber dejado en un post, si bien no toda la información al respecto, una guía bastante completa a efectos de licenciamiento de Oracle sobre vSphere y en la cual existen los links oficiales a la información que no incluí en este post.
La multa por violar el acuerdo de licenciamiento puede llegar a ser extremadamente alta (he visto ejemplos que hablaban de millones de dólares…), tanto en entornos virtualizados como físicos. Cualquier precaución está más que justificada y cualquier pregunta debería ser más que bienvenida tanto por parte de fabricantes como por parte de sus canales de distribución. Os animo a que preguntéis siempre todas vuestras dudas y agradeceré cualquier información que podáis añadir a lo ya escrito en este post J
Si os gustó el post, por favor compartid el link en vuestras redes sociales. Tal vez también le sea de utilidad a otros y así también nos estaréis echando un cable en dar a conocer este blog!
Saludos y gracias por leernos!!!
Chubascos Blog 