Servicios Virtualización y Cloud Computing

Sobre el autor

Jose Maria Gris

José María Gris es Socio Director de Orbal, empresa especializada en ecosistemas basados en VMware, con más de 25 años de experiencia en el sector de IT. Tiene amplia experiencia en VMware (VCP310 y VCP410), Datacore (DCIE), Veeam y Vkernel entre otros.

Artículos Relativos

10 Comentarios

  1. 1

    Jose Maria Gonzalez

    Hola Tocayo,

    Antes de nada, felicitarte por tu estupendo post.

    Si no importa, me gustaría añadir un tema muy importante adicional a lo ya expuesto por ti tan magistralmente en tu post.

    Es con relación a la alta disponibilidad que mencionas – o la falta de ella – en la versión ESXi embebida – tanto la instalable como la versión flash- :

    La versión VMware ESXi comparte el mismo VMkernel y VMM que el ESX pero con algunas connotaciones importantes:

    1. Extensiones VMkernel: Mientras que en la versión clásica de VMware ESX tu podías instalar agentes y drivers de empresas de terceras partes, en ESXi solo se permite instalar extensiones en el VMkernel que hayan sido previamente firmados digitalmente por VMware. Esta restricción ayuda mucho a asegurar el entorno y mantener el código seguro en el VMkernel.

    2. Muchos de los agentes y deamons que se ejecutaban en el Service Consolo en la version clásica de ESX han sido convertidos y embebidos para correr directamente en el VMkernel del ESXi.

    3. La imagen del sistema en ESXi – system image – es una imagen bootable que es cargada directamente en memoria física. El propio “installer” usa esa misma imagen de sistema para copiar los ficheros en un disco local para futuros arranques.

    Y poque la imagen del sistema es cargada en memoria, el ESXi no necesariamente necesita un disco local cuando este se esta ejecutando. Esto significa que el disco local podría fallar pero sin embargo nuestro VMkernel continuaría ejecutandose.

    4. La partición scratch. Es una partición de 4GB virtual y de tipo FAT (VFAT) la cual es creada por defecto en el primer disco local del servidor ESXi, si este tiene discos locales, claro!. Si el servidor no tiene disco local, esta partición no existira pero se “rediccionara” el directorio scratch a una partición de tipo ramdisk llamada /tmp. Esto significa que el contenido de esta partición scratch no “sobrevivirá” a un reboot del servidor ESXi. Esto significa, también, que el servidor ESXi puede necesitar hasta 4GB de memoria RAM para almacenar esta partición!

    5 Y por ultimo pero no por ello menos importante, tenemos la partición bootbank: Esta partición contiene la imagen del sistema sobre un sistema de archivos. Si hay un disco local al cual ESXi pueda escribir, este almacena dos copias del bootbank. Pero Ojo, solo una es montada en la estructura del sistema de archivos del ESXi en el directorio /bootbank. La segunda copia es usada solo durante actualizaciones para mantener una segunda copia como backup en caso de problemas.

    Espero haberte ayudado.

    Rgds,
    J.

    Responder
  2. 2

    Miguel Angel

    Hay servidores que ya incorporan doble tarjeta de SD para dar redundancia, como el Dell PE R810 que en sus carácteristicas pone “Mejora continua de la redundancia con funciones como los dos módulos para tarjetas SD internas, que proporcionan failover en el nivel del hipervisor”

    Saludos.

    Responder
  3. 3

    Miguel Angel

    Es un excelente post, y muy aclarativo.. sin embargo hay que mencionar algunas otras cosas… como por ejemplo que al no tener consola esta limitado a un troughtput de 20Mb/s, eso no ayuda mucho al hace los respaldos.. Sin ir mas lejos un respaldos de un VM de 100GB podria demorar dias!!! inclusive… sobre todo si estan haciendo backup con aplicaciones de terceros que usan la service console de ESX. Con esto, hay que replantear las solcuiones de app’s que podrian utilizarse en ESXi… por mi parte veo que VMware esta cerrando lo que en un principio predico era libre, la service console.. ha visto que salen muchas app’s qeu se cuelgan de ahi y no quiere preder esas lukita$… en otras palabras se esta convirtiendo en un Microsoft cualquiera.

    Responder
    1. 3.1

      Jose Maria Gonzalez

      Hola Miguel,

      Podrías aclararnos mas lo que comentas sobre la limitación del throughput a 20Mb/s? Lo de que no tiene Service Console esta mas que claro, pero esta limitación no la encuentro por ningún lado :(, aunque corregidme si me equivoco.

      Gracias,
      Rgds,
      J.

      Responder
  4. 4

    Jose Maria Gris

    jejejeje Cuanto curro esta noche para contestar…. ;)

    Responder
  5. 5

    Jose Maria Gris

    Hola a todos.

    Este es de aquellos posts que me gusta ver, en los que hay tanta o mas informacion en los comentarios que en post mismo. Gracias.

    @tocayo
    Perfecto chico, mi vision/explicacion es mas conceptual pero con el complemento tecnico tuyo, chief editor, queda “completo”. Lo de que al cargar la imagen en memoria me lo apunto, no era consciente, y lo voy a probar en breve. Que me fío, que sí, pero a meter el dedo en la llaga….

    Sobre tu punto 2, totalmente de acuerdo pero deseará añadir que estas implementaciones tendrian que estar mejor integradas. Pasar estos CIM a la capa mas baja del hipervisor ha dado algun quebradero de cabeza a soporte (ver post sobre ello)

    Sobre el resto de los puntos, pues nada, pristino.

    @Miguel Angel. Lo de la doble tarjeta SD me lo apunto. Mañana estoy dando la brasa a mi preventa en Dell. Me extraña que no me haya comentado nada porque hace dias estabamos configurando y no me dijo nada. Me comento las nuevas tarjetas controladoras con flash no volatil (no pierden el dato que no ha grabado), pero no me comentó nada. Mañana hablo y comento.

    Sobre el tema troughput. Copio datos de un backup que se ha efectuado hace una hora en un ESXi. “268.02 GB Copiados a 80 MB/s menos de sesenta minutos” ;) . Como? Usando Veeam backup en modo SAN y con deduplicacion. El ratio es de copia, no es de transferencia (quede claro). Es cierto, esta configuracion tan solo usa las APIs de la Console de forma esporadica (saber donde estan las VM, etc) pero como ves, con ESXi se puede hacer backups con un rendimiento muy optimo si lo configuras “con fundamento” como dice Arguiñano. Me sorprende el dato que ofreces que desconozco totalmente, por favor, comentanos al respecto. Creo recordar algo en los foros de Veeam pero no recuerdo bien.

    Mañana contare el chiste, si quereis….

    Responder
  6. 6

    Jose Maria Gris

    Bien bien….
    No he podido contactar con mi buen amigo Rafa de Dell para que me comente el tema de las doble SD, pero los amigos de Dell no dejan de sorprenderme por su buen trato (sorpresa por desconocimiento). Acabo de hablar con Christian y me ha comentado el tema.

    Miguel Angel, es exactamente lo que comentas. El R810 tiene doble SD para que puedas hacer lo que estabamos comentando. el R610 y el R510 hoy por hoy no disponen de este dispositivo pues Dell, con buen criterio, esta mirando como evoluciona en el mercado este dispositivo. Quedo a la espera…. ;)

    Desde aqui un saludo al equipo de Dell. Salud chic@s

    Responder
  7. 7

    Javier Teran

    Saludos,

    Tengo una duda con respecto a las imagenes OEM personalizadas, que ventajas tengo y como puedo comprobarlo una ves instalado? la respuesta obvia seria drivers para estos equipos, pero contando un poco de mi experiencia, he hecho instalacoines OEM y genericas en equipos DELL, IBM, HP y actualmente en equipos UCS de Cisco, y no he notado una diferencia sustancial entre la instalacion OEM y la generica ya que la generica trae casi en su totalidad los controladores para la mayoria todos estos servidores, en mi opnion (corrijanme si me equivoco al respecto o si se me escapa algun otro detalle) por lo que he podido observar es mas efectivo hacer instalaciones con la imagen generica del ESXi ya que por lo general esta mas actualizada y se nota mayormente las ventajas de estos updates, por otra parte pienso que estas imagenes OEM se justifican mas en equipos mas legados o antiguos, donde los controladores se han ido eliminando en las nuevas imagenes de ESXi para conservar el espacio de instalacion.

    Gracias

    Responder
  8. 8

    Javier Teran

    Sobre las instalaciones “empotradas” creo que hay mas ventajas en hacer este tipo de instalaciones que hacerlo de manera tradicional, me explico:

    – en primer lugar partiendo de la premisa que una infraestructura “decente” las maquinas virtuales ejecutarian en una NAS o una SAN por el tema de alta diponibilidad.

    – si deseo usar una buena practica deberia como bien mencionas tener al menos 2 discos en raid 1 para el arranque del hypervisor, lo cual me parece en terminos de costo excesivo usarlo solo para el booteo donde no se va a usar ni el 1% del disco en la instalacion del hypervisor, el resto por lo general se va a desperdiciar ya que las VM y los respaldos no deberian estar almacenados en el host

    – estas memorias (bien sea flash, usb, sd, etc..) no usan piezas moviles por lo cual escogiendo una de buena calidad es menos probable que se deterioren

    – del punto anterior, si colocase discos de estado solido, volveria a los terminos de costo, creo que es preferible invertir estos discos en la SAN/NAS a colocarlos en el host donde se van a subtilizar

    – en el caso de que la memoria falle y el host se detenga y haciendo mencion del comentario de J. Maria, el hypervisor se ha cargado totalmente en RAM por lo cual la falla podra ser observada solamente en el momento del arranque del host, de ser asi en este momento las VM o no estan en produccion o las maquinas virtuales ya han sido migradas con anterioridad a otro host (ya que el host se deberia estar reiniciando durante una ventana de mantenimento) o las VM estan reiniciandose en otro host por HA (alta disponibilidad), por lo cual no afectaria el tiempo de operatividad en produccion.

    – siguiendo el caso de que esta memoria falle, en el caso de no tener host profile, bien podria tener o una imagen de la memoria clonada de respaldo, o en el peor de los casos reinstalar el hypervisor lo cual no deberia llevar mas de 1 hora si la configuracion es muy complicada (vlans, storages, etc..)

    En mi opinion creo que el valor costo/efectividad con respecto a una instalacion empotrada es mejor, poniendolo mas claro, en una ifraestructura de 3 hosts y una san,

    en el caso de una instalacion tradicional deberia invertir al menos 6 discos para booteo del hypervisor, que van a ser subutilizados, a 200$ aproximadamente cada disco digamos que de 150Gb SAS (sin mencionar SSD) es un total de 1200$

    contra la perdida de 1 hora de operatividad en un host sin afectar el entorno de producccion (por el HA), invirtiendo unos 20$ por memoria en total 120$ si tengo un respaldo de c/u, y con los 1200$ que tenia para adquirir discos se los incvierto a la SAN/NAS agregando 1Tb o 500Gb aproximadamente donde van a ser mas utiles.

    Atte.

    Responder
  9. 9

    Jose Maria Gris

    Javier

    Gracias por tu aportacion. Tu “feeling” lo comparto, me ha pasado lo mismo. No veo (hoy por hoy) ganancia de instalar la version del Vendor y si, mi feeling de nuevo, me da que la version de VMware esta mas actualizada.

    Sobre tu segundo post, hoy por hoy prefiero tener un par de discos (cada maestrillo su librillo ;) )

    Responder

Deja un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Una Web de JMG Virtual Consulting, especialistas en Soluciones de Virtualización y Formación Oficial VMware y OpenStack | Copyrights © 2017