© Josep Ros. Con la tecnología de Blogger.

Todo lo que quisiste preguntar sobre vSphere 5.1 y no te atreviste a preguntar

Como muchos de vosotros sois tímidos y no os atrevéis a preguntar ya tenemos a nuestro colega Jesús M. Rodríguez, desde Lugo, que lo hace por vosotros y me lanza 'esta' pregunta:

Buenas Josep, sigo tu blog desde que profesionalmente me he visto envuelto en temas de virtualización (hace ya muchos meses de eso) y he visto que respondes amablemente a cuestiones que te plantean, supongo que realmente te enviarán muchas y haces algún tipo de selección, bueno en cualquier caso felicitarte por tu blog y paso a hacerte una serie ("eterna") de cuestiones, he intentando concretarlas para que te sean fáciles de responder (no es plan enviar 50 dudas y encima supergenerales):

Gracias por leer el blog. Me alegra mucho que te ayude profesionalmente porque quiere decir que lo que escribo no son tonterías y, realmente son de utilidad para alguien :-)

Almacenamiento (están enfocadas sobretodo para el uso de SAN que es nuestro caso particular):

A - Ofrece alguna ventaja el uso de gestores de volúmenes (LVM o los discos dinámicos de Microsoft)? Agregan una capa de complejidad y una lígera pérdida de rendimiento, no se si pueden ofrecer algún beneficio a cambio.

Si hablamos de que tienes un entorno con vSphere olvídate de LVM ni de discos dinámicos de Microsoft. Una SAN es obligada en cualquier empresa a partir de, pongamos 20 usuarios. Te va a permitir simplicidad total en la gestión de los datos y una robustez que jamás vas a poder tener con servidores independientes.

B - El sistema ideal es crear un disco por cada partición del sistema para facilitar el crecimiento de las mismas y poder incluso teniendo datastores de diferentes características usar uno u otro (hablo de tener en una SAN discos de 15krpm junto a nearline sas, de este modo para por ejemplo un servidor de ficheros de gran tamaño puedes tirar de los nearline mientras que el SO lo dejas en los de alto rendimiento)? Presenta algún problema con las snapshots?

Siempre he sido partidario de la simplicidad en el uso de las TIC. Hay mil virguerías que podemos hacer y lo más inteligente en muchas ocasiones es no hacerlas.

Yo no pondría nada en producción en discos SATA (llámales Nearline SAS, llámales NL SAS, llámales SATA vestidos de lagarterana...)

La tendencia actual de la mayoría de fabricantes serios de almacenamiento es ir a entornos con discos SAS de 10K que son realmente muy económicos (600GB por 350€ y 900GB por 400 y pico) y muy baratos de ampliar (todavía más importante). Ponlo todo en SAS y no te compliques la vida.

Respondiendo estrictamente a tu pregunta te diré que, efectivamente la virtualización nos permite crear un VMDK por cada unidad: C: D: E: etc. Mi consejo genérico es poner siempre todos los VMDK y el VMX de una VM en un mismo Datastore (queda dentro de una carpeta en ese Datastore). Así reduces la posibilidad de que la VM caiga (si la tienes repartida en varias LUNS o Datastores si cae cualquiera de ella te quedas sin VM.

C - Puede valer la pena montar Raids para máquinas especialmente importantes (lo digo con el sentido de poner un raid entre dos discos que estén situados separados en la SAN por ejemplo en dos raids distintos).

Si se trata de una BD de Oracle o SQL o DB2, por ejemplo con altísimas necesidades de iOPS, podemos separarla en diversas LUNS, aunque lo más apropiado será poner muchos discos en el entorno donde se crean las LUNS. De ese modo tendremos muchos más cabezales leyendo y escribiendo y, al fin y al cabo, más iOPS o KM/H que es lo que suele interesar. Poner discos SSD puede ser prohibitivo en muchos escenarios.

D - A la hora de formatear los datastores se debe ir de cabeza al tamaño de bloque máximo?

En vSphere 5.1 yo te diría que si. Recuerda que en la mayoría de versiones de VMFS si creas una LUN formateada con bloque asignado a 250GB no vas a poder crear un archivo mayor a ese tamaño.

E - Existe alguna recomendación respecto al tamaño/nº de LUNs? tiene sentido cuando partimos de cero montar datastores que agrupen varias LUNs o esto puede perjudicar el rendimiento? En este sentido creo que me faltan conocimiento a como se traduce la LUN a nivel hardware, es decir si tienes una lun con 10 discos de 500 gigas en raid 1 y creas 5 luns de 500 supone que cada lun va a un par de discos? no sé si debe hacerse alguna consideración entre el hardware y las luns que se crean…

Mi consejo sería que crees LUNS de entre 300GB y 1 ó 2TB y que pongas varias VMs (pocas) en cada LUN para repartir la carga. Obviamente no pondremos un SQL y un Oracle en la misma LUN, como no pondremos un Exchange y un SQL tampoco en la misma LUN.

F - Qué tamaño mínimo recomendarías para una VM con windows 2008r2 (he visto que de cara a actualizaciones y demás hay gente que comenta que tiene carpetas del sistema con decenas y decenas de GBs)? Cuando puede compensar crear una segunda partición para separar algo: BDs, Directorios, Fileserver, algo más?

En un entorno virtual con SAN en la que tenemos centenares de GB, la cosa más absurda del mundo es ir con mentalidad del mundo físico y crear unos discos super pequeños y encontrarnos que nuestro Windows 2008 R2 ó Windows 2012 llena el disco del sistema y estamos jodidos por culpa de... nosotros mismos. Nos hemos metido los 10 dedos por el orto como dirían mis amigos argentinos :-)

Hay unos maravillosos discos de autocrecimiento que siempre recomiendo. Pon 100GB para la C: o lo que te apetezca, pero que tienda más a infinito que a 10 ó 15GB que seguro que acabas pringando :-)

Efectivamente el sistema y los datos (archivos, BD, etc.) en otro DISCO, ojo, NO PARTICIÓN. Open your mind. Los discos son gratis! puedes crear tantos VMDK como necesites para una VM (sin pasarse, eh?)

G - Compensa en algún caso el uso de Thick? he pensado que si se ajusta todo para abajo y se montan los sistemas de manera que crezcan fácilmente (separando las particiones en discos y tal) o cuando el tamaño del sistema está muy controlado podría valorarse el uso de thick (nosotros por norma montamos Thin)… Cuanto se nota a nivel rendimiento?

Bajo mi punto de vista la virtualización es una balanza y siempre tienes que mirar pros y contras de las opciones que existen. Si pones discos fijos vas a tener algo más de rendimiento y vas a estar más limitado a nivel de espacio en disco, ocupando un espacio que probablemente no ocuparás jamás. Por contra si lo pones en autocrecimiento pierdes un poco de rendimiento pero, para mi, compensa sobradamente.

H - Cómo se debe manejar el tema del alineamiento tanto a nivel datastores como a la hora de formatear las máquinas virtuales al instalar los huespedes? es algo que en entornos físicos nos suele preocupar pero en virtual y con SAN parece olvidarse… ( http://www.tcpdump.com/kb/virtualization/vmware-esx-server/vmware-disk-alignment/intro.html <- a="a" dejo="dejo" el="el" enlace="enlace" font="font" mano="mano" que="que" sobre="sobre" tema="tema" tengo="tengo" un="un">

Esa misma URL que comentas me parece genial y estaría bien hacerlo. No obstante te diría que si tenemos una porquería de SAN con 4 discos SATA ya puedes alinear todas las estrellas del universo que aquello no va a ir ni para atrás. ¿Me explico? Hay que perder el tiempo en ir a ver al jefe y partirnos la cara con él para que entienda que su empresa funciona sobre una SAN (¿sólo una?) mejor DOS y que tenemos que dejarnos ahí la pasta, pues es el motor de la empresa.

Licencias:

Lo primero aclarar que el VDA me parece que dificulta que salgan las cuentas en relación a tu reciente post.

Muy cierto.

I - He leido que las empresas pueden requerir licenciamiento para el cluster entero aunque solo lo tengas instalado en una VM en un host, en concreto hablo de Oracle que incluso he llegado a leer por foros que el hecho de tenerlo "fuera" del DRS y sin reinicio automático no les es bastante y en una auditoría te pedirían igualmente una licencia por cada host del cluster. ¿Qué información pueden requerir empresas como Oracle o Microsoft de cara a justificar la presencia de sus productos en determinados hosts¿ ¿Cómo obtener una auditoría de los movimientos entre máquinas productos de ha, de drs, manuales y por entradas de hosts en mantenimiento? Alguna vez has tenido problemas en este sentido?

Los fabricantes hacen un tipo de licenciamiento que, hay que recordar, es agnóstico de hipervisor. Tanto da que tengas vSphere, Hyper-V, OracleVM, KVM, etc. Por tener un hipervisor gratis no te ahorras tener que pagar las licencias de Microsoft ni las de Oracle.

En el ejemplo de Microsoft lo más cómodo es licenciar los hosts con licencias Datacenter (una licencia por cada procesador físico) y nadie te puede rechistar. Si sólo tienes una licencia de Datacenter y tienes 3 hosts, cada uno con una CPU física pues sólo podrías tener VMs en un host y, desde luego, no tendrían que estar en un clúster.

Si miras el global de un entorno virtualizado al final las licencias Datacenter tampoco es que sean nada exorbitante.

Otros:

J - Acostumbras a poner de first boot de las VMs el hd? (esto es más curiosidad por saber lo tikismikis que eres más que por otra cosa)

En la línea de lo que te he ido respondiendo: frikis y tikismikis a la hoguera. Muy simple todo y muy fácil que ya el Murphy se encarga de buscarnos el orto y meter un dedito y luego toda la mano. Las VMs en la LUN y sin demasiadas complicaciones.

K - En vuestras implantaciones como lograis estados consolidados de bds o directorios en las snaps del veeam? he visto el whitepaper para mysql de veeam pero sigue sin convencerme mucho eso de parar el servicio… en windows tienes VSS pero en el mundo Linux yo esperaba que la gente usara algún tipo de script manual para simularlo (es decir algún tipo de script que se asegurara de consolidar la bd y ponerla en algún tipo de modo de lectura o similar)

Veeam es Dios. Y su CEO ya ni te digo. Si hubieses estado en la fiesta de Veeam del VMworld me entenderías lo que te digo.

Hay que seguir los consejos de Veeam en ese sentido y cero problemas. Es cierto que el mundo Linux, respecto a Veeam, como a otros fabricantes, suele ir un paso por detrás de Windows pero vamos, es ver qué situación hay, los aplicativos implicados y hablar con el especialista en Linux y que nos aconseje :-)

L - Has utilizado veeam en máquina virtual? los backups los envias a un disco virtual no-snapshoteable (vaya palabro acabo de inventar) o 'remoto' (iSCSI, SAN directa, etc)?

Siempre en virtual el Veeam y también el vCenter. No hacemos backups, hacemos réplicas y siempre contra una SAN o una NAS, ya sea vía iSCSI o FC. De lujo. Suelen fallar las primeras versiones menores de cada versión mayor, pero en pocas semanas se resuelve y festival del humor. A vivir y a disfrutar del paisaje. Hay que salir y buscar setas: Níscalos, rovellones o esclatasags y lo que te ahorras en el supermercado! :-)

M - Usando veeam en máquina física que sistemas de backup de la propia máquina soléis utilizar? algo de acronis? symantec? tiráis de cosas más manuales?

Cuando lo hacíamos así utilizábamos el Symantec Exec System Recovery y hacíamos imagen del disco C: que es básicamente donde estaba el bacalao. Mejor en una VM el Veeam.

N - Scripts de apagado para entornos virtuales: Te comento nuestro enfoque por si le ves algún fallo/mejora, se recorre el cluster desde un script en la máquina win con el vcenter y el apcns y se apagan las máquinas con tools de manera ordenada, y las sin tools forzada, finalmente se revisa por si alguna ordenada no apagó y se la fuerza, finalmente y todo con tiempos en cuenta se envían apagados con delays a los esx (service console) antes de apagar la propia máquina. Como mejora habíamos pensado en poner un parámetro en cada máquina con valores de 1 a 10 y hacer rondas de apagado para asegurarnos no apagar máquinas en orden equivocado.

Mola. Hay otras formas como coger el programa del SAI y aplicarlo, pero vuestra fórmula no me parece nada mal.

Y para finalizar una divagación, creo que el DRS+HA debería permitir establecer ante el número de nodos caídos las máquinas que han de estar funcionando es decir, que le dijeras que al caerse un nodo apague tales máquinas (entorno de for por ejemplo), que ante la caída del segundo apague otras (entorno de pre por ejemplo), y en la caída del tercero apague las otras que son 'admisibles' (osea máquinas de pro con servicios no fundamentales), para todos los casos además debería iniciar aquellas de los entornos que han de mantenerse activos para ese número de hosts perdidos. <- a="a" bote="bote" conste="conste" dise="dise" el="el" en="en" font="font" me="me" mejor="mejor" no="no" o="o" parecer="parecer" pronto="pronto" que="que" s="s" trabajas="trabajas" vmware="vmware" xd="xd" y="y">

Me parece guapa la reflexión. Jugando con los Resource Pools se puede conseguir algo similar. Aunque tienes que tener en cuenta que HA no tiene nada que ver con DRS. Mientras HA está en la mayoría de versiones (de Essentials Plus para arriba) el DRS sólo en las enterprise.

Gracias por anticipado y perdón por el 'acoso' (entiendo que es un claro abuso preguntarte todas estas cosas (sin pagar xD) pero espero que veas interesante al menos alguna y puedas elaborar un post relacionado o similar).

Jesús M. Rodríguez Núñez

Nada, a mandar! Creo que todas las preguntas valían la pena ser contestadas pues son dudas que todos tenemos y muchos colegas de profesión las podrán aprovechar. Por supuesto mi respuesta sólo es una opinión. Contrástala con otras personas y llega a tus propias conclusiones.

Me debes una cerveza (bueno digamos 3) :-) cuando nos veamos eh? ;-)


2 comentarios:

Jesús Manuel Rodríguez Núñez dijo...

Buenas, yo soy el Preguntador, espero que al resto de lectores les parecería interesante al menos alguna de las preguntas y agradecer a Josep su ayuda desinteresada, paso a dejar algunas notas y demás sobre las fantásticas respuestas:

A- Me refería dentro del guest <- nosotros fuimos de 'listos' y como creabamos un solo disco en la VM pensamos... jue para poder ampliar-reducir las particiones bien lo mejor será poner LVM... o discos dinámicos de microsoft… nos pasamos de inteligentes me temo
B- Entonces por ejemplo vosotros si creas un guest linux le ponéis 5 discos como medida habitual? en plan uno por cada punto de montaje de interés (los linuxeros más puristas pondrían separado como mínimo: /, /tmp, /var/log, swap, /boot, aunque es cierto que esto es genérico y depende de la función de la VM)
C- Ok como sistema 'artificial' para ganar iops puede ser un buen truquito, y como medida de seguridad con Raid1? es un poco lo que comentas en el apartado B pero al revés, es decir si tienes reflejadas los discos virtuales en dos LUN's que no comparten raidgroup ante la caida de un raidgroup no te pasaría nada... supongo que pienso en esto porque soy un paranóico... aquí cada enclosure de la cabina son 12 discos y hay raids 6 de 11 discos o 1+0 de 10 que siendo realistas es difícil que se peten pero tampoco son infalibles…
E - Este tema de la SAN me lo voy a remirar quizás con el tiempo te agobie más pero en dicho caso prometo poner dibujitos con colorines y todo xD, además me van a pegar el resto de lectores por acaparte
J- Jajajaja yo soy el mayor frikismikis pero ya estoy muy quemado no es necesario enviarme a la hoguera!!
I- Pones al final una frase: "y, desde luego, no tendrían que estar en un clúster.", eso es lo que más me preocupa a mi, es decir ni deshabilitando la máquina a nivel HA y DRS, y auditando los movimientos podríamos justificar ante Oracle o Microsoft que esas máquinas no se han movido de los hosts licenciados a otros no-licenciados del mismo cluster? he leido de todo al respecto en la web donde en el caso concreto de Oracle parece existir un debate brutal (algunos enlaces son partes de varios, y muchos enlazan a otros a su vez):
http://blogs.flexerasoftware.com/elo/2012/09/oracle-database-licensing-in-a-vmware-virtual-environment-part-1-of-3.html
http://oraclestorageguy.typepad.com/
http://up2v.nl/2012/03/22/drs-host-affinity-rules-can-be-used-to-run-oracle-on-a-subset-of-the-hosts-within-a-cluster/
http://longwhiteclouds.com/2012/07/21/fight-the-fud-oracle-licensing-and-support-on-vmware-vsphere/
Este tema me parece muy interesante (hay unos cuantos euros en juego), y me encanta el debate que existe pero está claro que al final creo que lo mejor para evitar sustos será obtener confirmación por mail con en este caso Oracle, Microsoft o la empresa de turno.
L- Entonces tendéis a usas Raw Device Mapping (physical) para los casos de destino SAN FC y Passthrough SCSI Device para los robots de cintas? No es un problema tenerla virtualizada para tener acceso directo a SAN's FC? (en este tema estoy muy verde tenía pendiente mirarlo de cara al futuro...)

Jesús Manuel Rodríguez Núñez dijo...

Jue no me cabía todo en un comentario!!!

Notas (esto es por si así me expresara mejor, nada más):
N- No sé actualmente si con APC habrá alternativas en plan gratis actualmente pero nosotros digamos que vimos que había dos opciones (sin pagar) o poner el software de apc en toda máquina virtual (LOCURAZA) o ponerlo en el vCenter y lanzar un script donde centralizar el apagado de todos los sistemas (VMs y hosts ESX básicamente, incluso algún hardware a mayores...). Usando el tema del orden de apagado yo diría que puede ser considerado incluso por delante de soluciones que impliquen instalar un agente en cada host esx/esxi y se encarguen del resto (el mismo script te vale para un ordenado apagado del cluster).
Divagación HA+DRS: Debí poner solo HA, lo que pasa es que yo suelo pensar en ambas cosas como un conjunto (error, lo sé), el tema es que la reserva de nodos o recursos porcentuales o tal... me parecen un mal sistema, creo que estaría bien marcar a nivel máquina/carpeta si debe estar apagada o encendida en función de cuantos hosts se nos han caido (o incluso se podría marcar un atributo de prioridad y el sistetma asegurarse en arrancar todas las que tengan más prioridad y 'quepan' en el cluster actual apagando a su vez las de menos… vamos yo podría hacerlo en un script pero el tema sería que se lanzara con las caídas de los hosts).
El tema de los resource pools lo tengo totalmente pendiente al no usarse aquí aunque algún día terminaré el libro de epping-duncan HA-DRS technical deepdive que la verdad está muy bien la parte que he mirado...

Consulta Técnica

[Consulta Técnica][bleft]

Virtualización

[Virtualización][twocolumns]

Naturaleza

[Naturaleza][grids]