Está en la página 1de 1064

#VMwarePorvExperts www.vmwareporvexperts.

org
¡Descarga gratuita
sin registro!

El Libro de VMware
VMware
por vExperts
por Bloggers
Versión 1.0

14 Bloggers unidos por un Proyecto solidario.


Todo el dinero recaudado gracias a nuestros Sponsors va
a ser donado a dos causas solidarias.

Miguel Angel Alonso • Xavier Caballé • Patricio Cerda • Federico Cinalli • Jorge de la Cruz •
Xavier Genestos • Hector Herrero • Ricard Ibáñez • Gorka Izquierdo • Leandro Ariel Leonhardt
• Miquel Mariano • Daniel Romero • Ariel Sánchez • Raúl Unzué
Prólogo por Duncan Epping
VMware por vExperts

© 2019 - Autores libro

Reservados todos los derechos. Esta publicación está protegida por las leyes de propiedad intelectual.

No se permite distribuir ni parcialmente, ni totalmente, la publicación a través de cualquier medio,


soporte, sin autorización expresa de los autores.

Todas las marcas, nombres propios, que aparecen en el libro son marcas registradas de sus respectivos
propietarios, siendo su utilización realizada exclusivamente a modo de referencia.

Los autores del libro no se hacen responsables de los problemas que pueda causar en su infraestructura,
siendo responsabilidad de los administradores de sistemas realizar las copias de seguridad, planes de
contingencia y laboratorio de pruebas previo antes de aplicar cualquier cambio en los servidores de
producción.

#VMwarePorvExperts 3
Los vExperts

#VMwarePorvExperts 4
Miguel Ángel Alonso
Hola, me llamo Miquel Ángel Alonso y soy Consultor y Arquitecto en soluciones de virtualización y
Cloud Computing en JMG VirtualConsulting.

En lo profesional, cuento con unos 15 años de experiencia en el ámbito de sistemas y en los últimos
años 10 me centré en la virtualización y automatización del datacenter y en estos últimos 5 en Cloud
Computing, HCI y SDN. También me encanta la docencia y trabajo dando cursos como instructor de
VMware VCI desde el año 2011:

• Diseño, implementación y administración de grandes entornos VMware vSphere


• Instalación, configuración y administración de almacenamiento EMC, DELL y NETAPP
• Instalación, configuración y administración de NUTANIX (NPP)
• Instalación, configuración y administración de vCloud Director, AWS y NSX para entornos Cloud.
• Disaster Recovery con VMware SRM y Veeam Backup & Replication.
• Experto en VDI con VMware Horizon Suite
• Soy VMWARE vExpert 2015,2016,2017,2019 y VMWARE vExpert 2018 NSX

Blog http://www.josemariagonzalez.es/author/miguel-angel-alonso-pomar
Twitter @miguelaalonso
Iinkedin https://www.linkedin.com/in/miguel-angel-alonso-5a54a730/

Agradecimientos

La verdad es que tengo muchos y no sabría por dónde empezar con lo que lo haré de uno en uno para
no olvidarme de ninguno.

Quiero dar las gracias a José María González y mi empresa JMG VirtualConsulting por darme la
continua posibilidad de aprender en estos 10 últimos años y el tiempo para realizar el libro.

A Fede, Hector, Leo y demás Bloggers que han escrito el libro, por su dedicación, sus buenas intenciones
y maravillosos conocimientos.

¡¡Y cómo no!! Y de manera muy especial a mi suegra que tiene por desgracia la enfermedad de
Alzheimer y que es uno si no el más importante de los motivos por el cual me he sentido más atraído a
escribir este libro y poder ayudar a todos aquellos que están inmersos en tan mala experiencia.

Y por último pero no menos importante a mi mujer e hijo por estar siempre a mi lado en los buenos y
malos momentos…. ¡¡¡Mil Gracias!!!

#VMwarePorvExperts 5
Xavier Caballé
Mi nombre es Xavier Caballé, soy administrador de sistemas informáticos desde hace más de veinte
años. Mi trabajo está orientado al soporte técnico, mantenimiento e instalación de infraestructuras de
red.

Entre mis labores habituales, se encuentran la administración y mantenimiento de


entornos basados en un dominio de Active Directory, y todos los servicios asociados a él. Como
pueden ser, los servidores DNS, DHCP, servicios de impresión, directivas de grupo, y los servidores
de ficheros.

También me dedico a la instalación y gestión de servidores de correo electrónico basados en Microsoft


Exchange server o Office 365 con Exchange OnLine.

En la actualidad, una gran parte de mi tiempo laboral lo consume la configuración y administración de


entornos de VMWare.

Tampoco podemos olvidar la gestión y programación de tareas de copia de seguridad con distintos
productos de backup. Como pueden ser, VEEAM, ARCServe o BackupExec.

Soporte técnico de Hardware de servidores y dispositivos de almacenamiento de grandes marcas


como HP, DELL, IBM, Fujitsu.

En lo personal, dedico gran parte de mi tiempo libre a la fotografía paisajística y estar al aire libre con
mi familia. También soy el autor de un blog dedicado a la tecnología de la información http://www.
pantallazos.es y del canal de YouTube https://www.youtube.com/c/pantallazoses

Agradecimientos

En primer lugar, me gustaría agradecer de a Fede, Héctor, y Xavi la oportunidad que me han brindado
ofreciéndome poder colaborar en este proyecto solidario. Ha sido una aventura muy enriquecedora.

También, me gustaría agradecer a mi mujer y mi hija, a las que tantas horas he robado, para poder
dedicarlas al proyecto de pantallazos.es. Sin ellas, nada sería posible.

Por último, me gustaría decir que todos los que escribimos un blog o simplemente compartimos algún
conocimiento por Internet, lo hacemos llevados por un impulso de querer aportar algo al resto de la
comunidad.

La gran mayoría de nosotros, la única recompensa que conseguimos después de invertir un gran
número de horas a la creación de nuevo contenido, es el sentimiento de haber hecho algo bueno para
otra persona a la que ni siquiera conoces.

En alguna ocasión, nuestro trabajo nos permite sentir el agradecimiento de alguien a quien has ayudado
y este alguien siente la necesidad de escribir un comentario positivo o un agradecimiento. En estas
contadas ocasiones, el sentimiento de alegría es muy grande.

Con todo esto me gustaría agradecer también, a todos los patrocinadores que se han unido al proyecto
y también a los que se unirán en el futuro. Por el inmenso orgullo que nos han hecho sentir, a todos
los coautores del libro, al permitirnos ayudar a las dos ONG’s seleccionadas de una forma que ha
superado con creces la mejor de nuestras expectativas.

#VMwarePorvExperts 6
Patricio Cerda
Hola, mi nombre es Patricio Cerda, y actualmente trabajo como consultor independiente tanto en
Europa como para Latinoamérica.

Comencé mi carrera profesional por allá por el año 2001, cuando comencé trabajando como
desarrollador por poco más de 1 año. Luego de pasar algunos años deambulando por muchas ramas
de la informática, incluyendo unos años trabajando con soluciones de seguridad (Firewalls, IDS/IPS),
así como también con soluciones Microsoft (AD, Exchange y Sharepoint), finalmente me encontré
un día haciendo pruebas con VMware Server 1, creando mi primera máquina virtual para simular
un entorno de producción. Era el año 2006 y sin saberlo comenzaba mi aventura en el mundo de la
virtualización.

Muchos años han pasado desde aquello, y en el camino me he ido especializando en múltiples
soluciones y tecnologías, comenzando con soluciones VMware como NSX, Virtual SAN y vRealize
Suite, asi como de otros fabricantes como Veeam, Nutanix, Brocade y Dell EMC. Durante este proceso
además me convertí en instructor oficial VMware (VCI) el año 2014, para 3 años más tarde convertirme
también en instructor oficial Veeam (VMCT).

Creo profundamente en compartir mis experiencias y conocimientos con la comunidad, para poder así
retribuir lo que la comunidad me ha aportado en mi formación profesional. Pensando en eso es que
comencé con mi blog el año 2009, y también esto fue lo que me llevó a dar el paso de convertirme en
instructor.

Además de la tecnología, soy un aficionado a la fotografía, hobbie que adopté luego de que mi labor
como consultor me llevara a visitar múltiples países. Ahora tomo cada uno de estos viajes como una
oportunidad para recorrer nuevas ciudades y poder así retratarlas con mi cámara.

Me pueden encontrar en mi blog y en redes sociales:

• Blog: https://patriciocerda.com
• Twitter: https://twitter.com/patote83
• LinkedIn: https://www.linkedin.com/in/prcerda/
• Instagram: https://www.instagram.com/patricio.rcc/

Agradecimientos

En primer lugar, agradecer a Federico Cinalli por permitirme ser parte de este proyecto. Cuando Fede
nos propuso la idea de escribir este libro, no dude ni un instante en sumarme a este esfuerzo conjunto,
el cual además de ser un aporte a la comunidad, nos permite llevar a cabo una labor solidaria.

Un agradecimiento especial además a Dagoberto Araya, amigo desde mis tiempos de Universidad.
El me abrió la puerta a una enorme oportunidad profesional 11 años atrás, que finalmente me ha
permitido llegar a donde estoy ahora.

Agradecer a mi familia, a mi madre y a mis amigos. Casi todos ellos están a miles de kilómetros de
distancia, pero son mi constante apoyo y un pilar fundamental en mi vida. La distancia no disminuye
ni un centímetro el amor que siento por ellos.

Finalmente agradecer a los sponsors que han creído en este proyecto, y en el espíritu solidario del
mismo. Gracias a todos los lectores de este libro, espero que lo disfruten!!!

#VMwarePorvExperts 7
Federico Cinalli
Soy instructor oficial de VMware dictando cursos oficiales para los clientes de la propia compañía en
la zona de EMEA como instructor externo.

Formo parte del equipo de Cloud Solutions Architects de Adistec para las divisiones AEC (Adistec
Enterprise Cloud) y APS (Adistec Professional Services).

Participo en proyectos de diseño, sizing, implementaciones y health checks para soluciones de


vSphere, vSAN y la Suite vRealize en Europa, Oriente Medio y América.

Suelo colaborar con sesiones en vBrownBag, VMUG’s y presentaciones de diferente tipo tanto para
fabricantes como, sobre todo, para la comunidad.

Cuando el tiempo me lo permite encuentro la paz trabajando con madera y elaborando cerveza
artesanal.

Cuento actualmente con las certificaciones VCIX6-DCA, VCAP5-DCA, VCAP5-DCD, VCP6-CMA,


VCP6-NV, VCP7-DT, VCI L2 y el reconocimiento VMware vExpert desde el año 2014.

Agradecimientos

Quiero agradecer ante todo, y de forma muy especial, a mis 13 compañeros, ya que sin ellos no
hubiera sido posible este proyecto. Cada uno de ellos robó tiempo a su familia para colaborar de forma
totalmente desinteresada con este proyecto.

Como no podía ser de otra manera también quiero agradecer a mi propia familia, mi mujer y mis dos
hijas, la comprensión y paciencia infinita que permitieron que dedicara muchas horas a este proyecto.

Por último y no menos importante quiero agradecer a los sponsors. Entre los autores del libro y los
sponsors estamos ayudando a dos nobles causas benéficas, además de compartir de forma gratuita
un gran contenido para muchos lectores en su propio idioma.

Quiero dedicar este libro a mi mujer Roxana y a mis hijas Chiara y Olivia a quienes amo profundamente.

#VMwarePorvExperts 8
Jorge de la Cruz
Mi nombre es Jorge de la Cruz, actualmente trabajo como Systems Engineer para la empresa Veeam,
en Reino Unido, mi experiencia en la informática se remonta al año 2005, donde comencé como
Administrador de Sistemas para un ciber-café, posteriormente desarrollé medio año en Java para
Vector Software y comencé pasado este tiempo en el mundo de la consultoría de sistemas.

Recuerdo todavía cómo fue mi primera incursión con VMware ESX 3.0 y VirtualCenter 2.0, y el posterior
3.5 y las increíbles novedades presentadas en vSphere 4.0. Comencé desplegando un single-node
con almacenamiento en una HP MSA y ese entorno escaló a múltiples VNX con cientos de VMs
ofreciendo servicio de Hosting.

Una de las experiencias más bonitas que tengo de mi tiempo como consultor fue en Anadat Consulting,
para los que nos lo conozcáis Anadat es una empresa ubicada en Rivas-Vaciamadrid. Anadat Consulting
ofrece todo tipo de servicios de virtualización, consultoría de sistemas, despliegues de entornos,
Hiperconvergencia, Software-Defined Datacenter, y mucho más. Una empresa que me formó como
profesional, y en la que tuve la oportunidad de conocer a muchos profesionales del sector, entre ellos
Christiam, Óscar, Marcos, Héctor, Bernardo, etc.

Me uní posteriormente a la solución open source de correo electrónico y colaboración, Zimbra, donde
estuve cuatro años creando contenido de todo tipo, Wikis (https://wiki.zimbra.com), blogs (https://blog.
zimbra.com/author/jcruz) e incluso tuve la suerte de dirigir la estrategia de Product Marketing y Product
Management.

Mis competencias profesionales se basan alrededor de la virtualización de centro de datos, esto es


desde la Infraestructura como es Compute, Storage y Networking, hasta la capa de virtualización y
abstracción del Hardware, pasando por monitorización usando herramientas open source y comerciales
y seguridad incluyendo Cisco, SonicWall, FortiGate y PaloAlto.

Actualmente escribo desde hace muchos años en https://jorgedelacruz.es donde tengo la suerte de
contar con unos 3000 lectores cada día, más datos y formas de contactarme:

• Blog: https://jorgedelacruz.es
• Twitter: https://twitter.com/jorgedlcruz
• Linkedin: https://www.linkedin.com/in/jorgedelacruzmingo/
• YouTube: https://www.youtube.com/user/jorgedlcruz23
• Email: Jorge.delacruz@jorgedelacruz.es
• Teléfono: +1 202 738 4705

Agradecimientos

No puedo dejar de agradecer a mi mujer Irina y mi hija Victoria el tiempo que no dedico a ellas porque lo
dedico a seguir aprendiendo, trabajar o crear contenido, incluido este libro. Al lado de todos nosotros,
tenemos muchas personas que nos entregan todo sin pedirnos nada a cambio, mis humildes capítulos
se los dedico a ellas.

También agradecer a Federico Cinalli dejarme participar en el proyecto, y por supuesto a todos los
profesionales que han participado en este libro, yo ya me he leído sus capítulos y es lo mejor que he
leído sobre VMware en toda mi vida.

Por último, agradecer a todos los patrocinadores que han contribuido al proyecto para las causas
solidarias de CEAFA y Banani.

#VMwarePorvExperts 9
Xavier Genestós
• Administrador de sistemas: Entornos Microsoft, GNU/Linux, VMware, entre otros. (Año 2001 hasta
la actualidad).
• Formador IT: Cursos prácticos sobre VMware, Active Directory, Exchange, GPOs, Linux, etc. (Año
2006 hasta la actualidad).
• Escritor de libros de IT: 12 libros publicados: (Año 2012 hasta la actualidad).

WS2012LABS - Windows Server 2012


EX2013ADM - Exchange Server 2013
WFS - Windows File Server
GPOIT - Group Policy Objects para administradores de IT
ADIT - Active Directory para administradores de IT
LinuXe - Linux para empresas
VBESXi - Veeam Backup sobre ESXi
EX2016ADM - Exchange Server 2016
WS2016LABS - Windows Server 2016
RDSIT - Remote Desktop Services para administradores de IT
WIN10IT – Windows 10 para administradores de IT
WS2019LABS - Windows Server 2019

• Blogger en https://www.SYSADMIT.com: (Año 2013 hasta la actualidad)

Enlaces

Blog:

https://www.sysadmit.com

Linkedin:

https://es.linkedin.com/in/xaviergenestos

Grupo SYSADMIT en Linkedin:

https://www.linkedin.com/groups/8550757

Twitter:

https://twitter.com/sysadmit

Agradecimientos

Quería aprovechar este fragmento para agradecer al resto de bloggers su gran trabajo y dedicación
en este proyecto, también a la familia y amigos por su apoyo y por supuesto a todos los que habéis
decidido dedicar vuestro tiempo a leer esta publicación conjunta: ¡Seguro que os gustará!

#VMwarePorvExperts 10
Héctor Herrero
¡Hola! Soy Héctor Herrero, un bilbaíno pura cepa. Tengo 37 años y desde los 19 años en este sector
dando guerra. Actualmente trabajo y soy responsable de Open Services IT, una empresa orientada a los
servicios TIC especializados, donde mimamos y cuidamos de nuestros clientes, ahí realizo proyectos,
consultorías o formaciones entre otros.

Aunque seguramente alguno que otro igual me conoce del Blog Bujarra.com, que desde hace la tira de
años voy escribiendo manuales y How To’s de todo con lo que he ido descubriendo. Ya lo sabéis, me
encantan las Raspberry Pi, por todo lo que nos pueden aportar en el negocio y en el hogar, haciéndolo
todo más inteligente.

Un apasionado de las tecnologías, últimamente con más profundidad en el mundo de la monitorización


con Centreon, Grafana, NagVis o Stack de ELK entre otros. Como sabéis otro de los pilares es la
virtualización, tanto de infraestructuras con productos de VMware cómo virtualización de aplicaciones
y escritorios con la familia de Citrix. Heredero del mundo Microsoft, donde he vencido batallas desde
Windows NT o migraciones de Exchange hasta hoy Office 365.

Mentalidad Open,

Compañía: www.openservices.eus
Blog: www.bujarra.com
Twitter: @nheobug
Linked In: https://www.linkedin.com/in/hectorherrero/

Agradecimientos

Quería agradecer a cada autor de este libro el poner su granito, el tiempo que ha dedicado para
que hayamos podido obtener la gran recompensa de asegurarnos la finalización del hospital en Mali.
Gracias a todos los que habéis donado y por supuesto a las ONGs que llevan a cabo el trabajo que
los demás no hacemos.

Y por supuesto dedicarle mis capítulos a mi txabala Seila y mi recién hijo, Leo. ¡Gracias por vuestra
paciencia y amor!

¡Compartir y ser felices!

#VMwarePorvExperts 11
Ricard Ibáñez
Administrador de sistemas y especialista en soluciones VMware y Microsoft con más de 10 años de
experiencia.

Apasionado de mi familia, a la cual, le intento dedicar todo mi tiempo libre, menos las horas de escribir
el capítulo de este libro.

Me encanta la tecnología desde que tengo memoria y, sobre todo, los gadgets que simplifican la vida
o a veces hasta me la complican.

Llevo en el mundo tecnológico, hace ya más de 10 años. He pasado por casi todas las fases IT, desde
dar soporte Helpdesk a usuarios, dar soporte avanzado a departamentos de IT de clientes, diseñar e
implementar soluciones tecnológicas VMware, Microsoft y Veeam, entre otras, para clientes de ámbito
nacional. También he ejercido de profesor de tecnologías Microsoft y VMware, e incluso, he tenido
que pelearme con presupuestos y gestión del departamento IT. Este camino, me ha dado mucha
perspectiva de mi profesión e intento aplicar todo lo aprendido en mi día a día, además de seguir
aprendiendo de los que me rodean.

Soy Blogger hace más de 7 años, escribiendo sobre todo tipo de tecnologías de una manera muy
práctica, documentando procesos que simplifiquen las tareas a los administradores de sistemas y he
sido recompensado con cuatro estrellitas vExpert 16/17/18/19.

Blog: www.cenabit.com
Twitter @ricardibanez
LinkedIn: Ricard Ibáñez

Dedicatoria/Agradecimientos

Desde el primer momento que me propusieron colaborar con la escritura de un capítulo, para un
libro puramente técnico, el cual tenía tantos y tan buenos colaboradores, no pasó ni 1 segundo que
ya quería empezar a escribir y aún era más motivador saber que colaborar con este libro, ayudaba
directamente en proyectos solidarios.

Este libro, no existiría sin Xavi, Héctor y Fede, los cuales han conseguido motivar a 14 cracks de IT
para sacar adelante el proyecto y agradecer a todos y cada uno de estos cracks por dedicar este
tiempo, que lo tenemos que robar de otras tareas, normalmente familiares.

También agradecer a todos los Sponsors del libro, los cuales han conseguido más de 25.000€ para los
proyectos solidarios con los que colaboramos, que es la base de este proyecto.

Le dedico esta pequeña porción de conocimiento a mi familia por aguantar ausencias en los momentos
críticos de mi profesión y a todos los lectores interesados en aprender cada día.

#VMwarePorvExperts 12
Gorka Izquierdo
Hola, soy Gorka Izquierdo Bizkarrondo y trabajo el en Dpto. de Datacenter en vSolutions-SomosCloud.

Aparte de la tecnología que es una de mis pasiones, me gusta aprovechar los fines de semanas para ir
a mi pueblo a dar vueltas por el monte y de paso volar un Drone que tengo, un Phantom 3 Advanced,
volarlo entre las montañas y el rio Irati del Pirineo Navarro es uno de mis mejores momentos, hace que
por un momento desconecte de todo el estrés producido durante la semana.

Antes de meterme en el mundo de la tecnología pase 12 años trabajando por diferentes empresas
del sector del metal, donde trabaje como soldador, prensista, operario en cadenas de producción,
haciendo remolques de camión etc. Hasta que un día tuve la oportunidad de empezar a estudiar un
área totalmente desconocida para mí, la informática (a veces me arrepiento de esto).

Todos estos años en un continuo autoaprendizaje he sacado las siguientes certificaciones:

LPIC-1 y LPIC-2, MCSA Microsoft Windows Server 2003, MCP Server 2012 ,VCP5-DCV, VCP6-DCV,
VCP6.5-DCV de VMware, VMCE de Veeam Backup , ITIL v3

Y donde gracias a escribir en un blog he recibido los siguientes galardones:

• VMware vExpert, por cuatro años seguidos


• Veeam Vanguard en el año 2016

Me podéis seguir en mi blog https://aprendiendoavirtualizar.com


Linkedin https://www.linkedin.com/in/gorkaizquierdobizkarrondo/
Twitter https://twitter.com/vGorkon
Facebook https://www.facebook.com/aprendiendoavirtualizar/

Agradecimientos

Sin duda, a la primera persona que mas quiero dar las gracias es a Fede por todo lo que ha hecho
y se ha movido, también a Héctor y Xavier Genestós porque junto a Fede tuvieron la idea de este
gran proyecto con fines solidarios y en el que no dude en ningún momento en poder aportar mis
conocimientos, gracias por contar y confiar en mí, por eso he intentado hacer lo mejor posible mi
trabajo y espero que haber dado la talla.

Agradecer a los Sponsors su ayuda y donaciones, sin ellos este proyecto no hubiese sido posible.
Gracias a sus donaciones, muchas personas podrán mejorar su calidad de vida.

Gracias a mi mujer y mi hija por la paciencia y por no haberme echado de casa, gracias a todos mis
compañeros de este proyecto por el duro trabajo y haberlo dado todo y un poco más. Por último, dar
las gracias a vSolutions-SomosCloud por su ayuda desinteresada.

#VMwarePorvExperts 13
Leandro Ariel Leonhardt
Hola, mi nombre es Leandro Ariel Leonhardt, me encanta la informática y la música electrónica, en mis
ratos libres, desconecto de la rutina y del mundo virtual “haciendo/mezclando” música.

Desempeño la función de ingeniero/consultor de sistemas en una gran empresa, Sothis.

Ex instructor oficial de VMware, impartí más de 30 cursos en casi dos años, desde la instalación
y configuración de centro de datos virtuales, virtualización del almacenamiento, optimización &
escalabilidad, resolución de problemas y gestión de recuperación de desastres, cursos oficiales tales
como VMware Virtual SAN, Optimize & Scale, ICM, Fast Track, What’s New, Troubleshooting & Site
Recovery Manager.

Autor de los cursos en Udemy: Nutanix y VMware vSAN

Algunas de mis certificaciones y acreditaciones:

Ex VMware VCI, VCAP-DCA, VCP-DCV & VCP-NV. Nutanix NPP 5.0 & 4.5, NSEC, NSES, NSEN
& Nutanix Technology Champions (NTC) 2017/2018. Nombrado vExpert Pro y vExpert por VMware
desde el año 2013, vExpert vSAN 2019/18/17/16 & vExpert Cloud 2017.

Más información sobre mi trayectoria en: http://www.leandroleonhardt.com y en el blog: https://www.


blogvmware.com

Twitter: https://twitter.com/leonhardtla
Linkedin: https://www.linkedin.com/in/leonhardtla/

Dedicatoria/Agradecimientos

En primer lugar, quiero agradecer a mi mujer y a mi hijo, por apoyarme no sólo en este proyecto, en
todo lo que me propongo.

A mi familia, padres y hermanos, muy orgullos de mi por colaborar con este proyecto caritativo.

A mis compañeros/amigos de profesión, Juan Vicente, Mario, Diego, Nacho’s, Sean, por compartir sus
conocimientos y aprender de los mejores, día a día.

Agradezco a todos los autores del libro, por la profesionalidad, por el tiempo y esfuerzo que hicimos en
sacar este proyecto adelante, con la ilusión de ayudar a mucha gente, tanto en lo económico (ONG)
como en lo profesional, para la comunidad.

Por último, a todos los patrocinadores, que hicieron posible progresar con los objetivos de las ONG
gracias al dinero recaudado.

#VMwarePorvExperts 14
Miquel Mariano
Hola, me llamo Miquel Mariano Ramis y soy Consultor TI en Ncora

Aparte de la tecnología, me encanta el deporte al aire libre. Aunque viva en una isla como Mallorca, soy
mas de montaña que de playa, así que es fácil encontrarme por el monte haciendo MTB, corriendo o
simplemente practicando algo de senderismo.

En lo profesional, cuento con mas de 10 años de experiencia en el ámbito de sistemas y en los


últimos años he centrado mi trayectoria profesional especializándome en todo lo relacionado con la
virtualización y automatización del datacenter:

• Diseño, implementación y administración de grandes entornos VMware vSphere


• Instalación, configuración y administración de almacenamiento Hitachi HUS, VSP Gx00, EMC
VNXe, IBM Storwize, QNAP
• Instalación, configuración y administración de SAN con Brocade FC Switches
• Amplios conocimientos en protocolos de almacenamiento: iSCSI, FC, NFS, SMB/CIFS
• Instalación, configuración y administración de servidores Dell PowerEdge, HP Proliant, Hitachi
Compute Blade
• Disaster Recovery, Veeam Backup & Replication y continuidad de negocio
• Análisis de carga de trabajo, performance y dimensionamiento de máquinas virtuales
• Automatización con Ansible, scripting con PowerCLI, bash, …
• Monitorización con PRTG Network Monitor

He tenido la suerte de poder sacarme algunas certificaciones de VMWare y en estos últimos 4 años,
VMWare me ha nombrado #vExpert

Agradecimientos

En primer lugar, quiero agradecer profundamente a los mentores de este proyecto Fede, Héctor y
Xavi. Sin ellos nada de esto hubiera sido posible. Agradecer que pensaran en mí para contribuir en el
contenido y agradecer a todos los blogguers implicados en el proyecto, su dedicación y esfuerzo para
crear contenido de calidad y cumplir los plazos que nos marcamos desde el inicio.

En segundo lugar, quiero hacer un agradecimiento especial a mi actual empresa, www.ncora.com, sin
ellos nunca hubiera tenido la oportunidad de crecer tanto a nivel profesional y nunca hubiera estado en
las quinielas para participar en este libro.

En tercer lugar, a mi familia. Al final ellas, mi mujer y mi hija han sido las grandes afectadas y las que
han visto mermadas sus horas de dedicación en beneficio del proyecto.

Y para finalizar, como no, a todos los sponsors que han creído en el proyecto desde el minuto 0 y a
todos los lectores que han decidido dedicar su tiempo en leer nuestro libro.

¡Gracias a todos!

#VMwarePorvExperts 15
Daniel Romero
Hola, soy Daniel Romero Sánchez y actualmente trabajo como CTO en ilusia®

A nivel profesional llevo más de catorce años dedicados al sector TI. Comencé mi andadura profesional
como administrador de sistemas centrándome en el mundo de la monitorización, entendiendo las
arquitecturas de sistemas y desarrollando scripts para monitorizalas.

Con el paso de los años comienza mi pasión sobre el mundo de la virtualización y el cloud computing,
de ahí mi especialización en VMware, AWS o OpenStack.

Durante casi toda mi carrera he tenido siempre claro que no hay que realizar tareas repetitivas. Y como
siempre he tenido bastante curiosidad por el desarrollo, he creado decenas de scripts para automatizar
despliegues y tareas, liberando a los equipos de desarrollo de labores fuera de su alcance.

Estar en continuo contacto con la programación me ha llevado a aprender como diseñar arquitecturas
de aplicaciones ya sean monolíticas o basadas en microservicios.

Ahora gestiono a un equipo de TI, a la vez que superviso la infraestructura, políticas de seguridad o
nuevas tecnologías adaptables a nuestros servicios.

Me considero una persona autodidacta que no puede parar de conocer cómo funcionan las tecnologías
emergentes. Todos mis conocimientos los plasmo en el blog www.dbigcloud.com.

BLOG: www.dbigcloud.com
Twitter: @drsromero
Linkedin: Daniel Romero

Dedicatoria / Agradecimientos

Llegar hasta aquí no ha sido fácil, han sido muchos años de formación y trabajo, pero no estaría
escribiendo estas líneas si no hubiese sido por mi hermano que fue quien me abrió las puertas de este
mundillo. ¡Gracias!

He tenido siempre la suerte de rodearme de gente que me ha aportado conocimiento. A todas y todos
con los que he trabajado, compartido charlas, momentos e incluso discusiones, gracias. Algunas y
algunos me habéis ayudado a entender mejor esta profesión, otras y otros me habéis enseñado a
escribir un poco mejor e incluso animarme a seguir haciéndolo. Sinceramente muchísimas gracias.

También quiero agradecer a todas y todos los bloggers que comparten su conocimiento y tiempo de
forma desinteresada, en especial a todos los que han hecho posible este proyecto. Por último, a los
patrocinadores que han puesto su granito de arena aportando recursos a las causas solidarias de
CEAFA y Banani.

#VMwarePorvExperts 16
Ariel Sánchez Mora
Soy costarricense, viviendo actualmente en EEUU. Soy ingeniero electrónico pero mi pasión es la
tecnología de información y especialmente VMware.

Tengo certificaciones como VCIX-DCV y VCP-NV, y he sido aceptado como vExpert desde el 2015.
Participo en las subespecialidades de vExpert NSX y PRO. Trabajo actualmente como Senior Technical
Account Manager para VMware. Algún día, tendré el VCDX!

Soy miembro de @vBrownBag así como host de @vBrownBagLATAM. He presentado en VMworld


y en múltiples grupos locales de VMUG en los EE.UU., y ayudo a @pghvmug como miembro de su
comité.

Mi twitter es @arielsanchezmor y ahí me encanta interactuar con otros miembros de la comunidad. Te


pido que hagas una cuenta y te nos unas.

Agradecimientos

Agradezco a los valientes co-autores de este libro, que desde el momento que se les ofreció, no
dudaron en participar. De ellos, quiero recalcar que Federico Cinalli es un ángel que camina entre
nosotros, tiene paciencia infinita y siempre nos alentó a dar lo mejor de cada uno. Cuando sea grande
quiero ser como él; @FCinalliP es su Twitter.

Agradezco también a los sponsors que están hoy, y los que vendrán en siguientes publicaciones. Esta
es una situación donde todos ganan y podemos hacer aún más.

También agradezco a cada lector, porque van a crear la siguiente versión de este documento - hay
varios más expertos latinos que querrán participar. Cada vez que ayudas a alguien por internet o en
un VMUG en tu idioma, estas ayudado a que todos los que hablamos español mejoremos. Somos una
comunidad unida, lo veo cada VMworld.

Finalmente, agradezco a Dios por esta vida tan linda.

Al escribir este libro en español recordaba comúnmente la ortografía y gramática que me enseñaron
mis padres Dennis y Glenda, y mi tía Zuray, que es filóloga. Estoy seguro que ellos tres van a ayudarme
a encontrar varias mejoras, y los amo por ello.

Todo lo que hago es para mi esposa Amy. Te amo.

#VMwarePorvExperts 17
Raúl Unzué
Hola, soy Raúl Unzué Pulido. Administrador de sistemas desde hace casi 20 años, y ahora puedo
decir, co-autor de un “libro”. jeje!!

A nivel profesional me he especializado en virtualización, pero lo que realmente me atrae es poder


trabajar con cualquier tecnología.

Los últimos 10 años diseño y ejecuto proyectos tanto en empresas privadas como en entidades
gubernamentales. Ayudo con todo el proceso (diseño comunicaciones, soluciones de backup, hardening
infraestructura,…) hasta la entrega del proyecto al cliente final.

VMware vExpert desde el año 2013 por el blog “El Blog de Negu” del cual me siento muy orgulloso.

Aunque he trabajado muchos años con VMware, en la actualidad también me he especializado en


otras tecnologías de virtualización como las soluciones Citrix(más de 10 años de experiencia), Hyper-V
o Containers

Actualmente, soy Analista de sistemas e Infraestructuras IT. Disfruto siendo la “navaja Suiza”,
gestionando proyectos en clientes de diferentes tamaños.

En lo personal, me gusta la montaña, viajar, el deporte, la música y estar con mi familia haciendo las
dos primeras.

https://www.maquinasvirtuales.eu

TWITTER: @elblogdenegu

LINKEDIN: https://www.linkedin.com/in/raúl-unzué-pulido-b11a4b48/

Dedicatoria / Agradecimientos

Difícil saber a quién agradecer algo como un libro, para alguien que no se considera escritor.

Pero tanto este proyecto como el blog, no podrían ser posibles sin la ayuda de mi familia, que aguanta
mis largas noches en vela, y en este caso, los fines de semana creando el contenido, la web, los labs...
También se lo dedico a mi padre, que estoy seguro, habría estado orgulloso.

A Roberto Orayen por ser unos de mis mentores todos estos años, y ayudarme con sus anotaciones.

Y gracias a Héctor, Fede y Xavi, porque desde el primer momento que nos conocimos tuve la sensación
que algo grande iba a llegar. Gracias por invitarme a participar.

“Si aquello que entregas nació de corazón, allí donde lo deposites será bien recibido”

#VMwarePorvExperts 18
VMware por vExperts
Este libro es producto de mucho tiempo y esfuerzo por parte de 14 Bloggers de habla hispana. El
objetivo principal fue regalar un libro a toda la comunidad hispanohablante que pueda ser leído en
lengua materna, basado en el Software Defined Data Center de VMware y productos relacionados.

Evidentemente no es un libro convencional como los escritos por uno, dos o hasta tres autores. En
estas páginas vas a encontrar diferentes estilos y formas de transmitir conocimientos como cada uno
de los autores está acostumbrado a hacer en su propio Blog.

Este libro trata además de la comunidad, de compartir, de aportar sin pedir nada a cambio y de colaborar
con los que más necesitan.

Por estos motivos es que decidimos que el libro sea electrónico y gratuito con el fin de que en cualquier
lugar del mundo alguien pueda descargarlo sin importar su ubicación geográfica y sus recursos
económicos.

También subimos la apuesta involucrando a varios Sponsors para ayudar a dos causas sociales a las
que, feliz y orgullosamente, podemos decir que hemos sido capaces de poder recaudar más de 27.000
€.

Esta es la primera versión del libro y esperamos con ansias recibir tu feedback constructivo a través
de Twitter con el hashtag #VMwarePorvExperts, Linkedin o email para poder mejorar en las próximas
versiones, las cuales contarán seguramente con una mayor cantidad de autores de habla Hispana.

Finalmente, después de muchísimo esfuerzo y con toda la ilusión del mundo deseamos que disfrutes
del libro, que lo leas y lo vuelvas a leer, que lo compartas, lo recomiendes a un amigo o amiga, que te
ayude en tu día a día a mejorar, tal vez a prosperar y que te prepares para la próxima edición que será,
sin lugar a dudas, mejor que esta.

#VMwarePorvExperts 19
AMAFESTIVAL. CASA DE MATERNIDAD DE BANANI, MALI, ÁFRICA.

El presente proyecto nació en el año 2008. Varias personas, entre ellas un abogado de derechos
humanos, Martí Cànaves, realizaron un viaje por el llamado País Dogón, lugar situado en el corazón
de Mali, África.

Después de convivir en distintas zonas se estableció una relación especial con el poblado de Bananí,
este pequeño lugar tiene una población estimada entre 3.000 y 5.000 habitantes, la mayoría niños, y
el propio Consejo de Ancianos pidió a estos viajeros ayuda. Para ellos era fundamental y una cuestión
de supervivencia de su cultura poder tener un centro de salud y maternidad, ya que los hospitales
más cercanos se encuentran a varios km y el acceso hasta allí es muy difícil, hay que caminar por
un terreno muy abrupto, una falla llena de piedras, pendientes y dificultades. El problema se agrava
cuando alguna persona tiene problemas de movilidad o en embarazos de riesgo, habituales sobre todo
por problemas de desnutrición y hambruna; en consecuencia muchas mujeres no llegan al hospital y
pierden el feto o mueren.

De esta manera nació AMAFESTIVAL, se creó una asociación sin ánimo de lucro en Pollença,
Mallorca, Asociación Amics de Cala Carbó, y se organizó un festival de carácter anual de acción
social y cultural dedicado a las mujeres. A lo largo de estos años se han celebrado distintas ediciones
en Mallorca, Tarragona, Almería y Cantabria. Además de festivales, y con el objetivo de recaudar
fondos, se han hecho todo tipo de actos culturales, exposiciones, mercados, participación en otros
eventos, merchandising, y sobre todo aportaciones económicas personales de miembros y personas
cercanas a la mencionada Asociación. El nombre de Ama se decidió por considerar que amar es la
mejor herramienta contra cualquier tipo de violencia y para hacer un homenaje a la mujer y denunciar
la violencia machista, grave lacra que azota nuestras sociedades.

#VMwarePorvExperts 20
Nuestros objetivos son:

• Promover la participación de la sociedad para que todas aquellas personas que quieran lanzar un
mensaje a favor del amor, el respeto y la comunicación entre los seres humanos, puedan hacerlo
conjuntamente.

• Reivindicar y aportar ejemplos de la importantísima contribución de las mujeres a la sociedad.

• Provocar la reflexión entorno al maltrato machista y promover todo tipo de acciones para acabar
con ella.

El fin principal de Amafestival es construir la Casa de Maternidad del poblado de Banani y otro proyecto
paralelo a favor de la eliminación de prácticas rituales de escisión genital femenina con el máximo
respeto hacia la diversidad cultural, así como proteger una cultura milenaria en riesgo de desaparición.

Desde su comienzo y hasta el día de hoy se han realizado distintas prospecciones médico-sanitarias
en la zona, de salud buco dental, de riesgos asociados a la escisión genital femenina, diseño
arquitectónico, etapas, costes, construcción de un pozo, corte de piedra, fundición,… estando en la
actualidad en un estado avanzado de construcción.

Todo el trabajo se ha realizado directamente con el poblado, sin intermediarios y ellos están totalmente
involucrados en el proyecto, participando y dirigiendo cada fase.

Ama es un proyecto homenaje a la mujer, para su empoderamiento y donde se busca la igualdad


entre los géneros; un proyecto de desarrollo comunitario, basado en construir un centro de maternidad
digno, de calidad, con durabilidad, que mejore su vida y además aumente su autoestima.

Muchas gracias a todos los colaboradores que están haciendo que esta necesidad deje de ser una
utopía para convertirse en una realidad. Un mundo mejor es necesario.

Si quieren colaborar pueden hacerlo:

Colonya - Caixa de Pollensa


IBAN ES98-2056-0008-2241-0200-0083
Beneficiario: Asociació Amics de Cala Carbó

Enlaces:

www.amafestival.org
https://www.facebook.com/amafestivalbanani/

#VMwarePorvExperts 21
Patrocinadores

GOLD

SILVER

BRONZE

#VMwarePorvExperts 22
Prólogo por Duncan Epping

Prólogo
When Federico contacted me in February and asked me if I would be willing to write a foreword for
a book my immediate response was: YES. I always applaud community efforts, and as this book is
written by 14 bloggers from Spain and Latin America it even felt more special. Some of you may not
know this, but the very first book I wrote was a collaboration between six bloggers. I know how much
work is involved, and it may sound like things will be easier when you are producing content with more
people, but it is the opposite. A lot of coordination needs to happen to ensure everyone sticks to the
same standards and delivers the same quality of work. Challenging, yet awesome.

If that wasn’t enough to convince me, Federico mentioned that the idea behind this project was to get
the book sponsored and donate all proceeds to charity. I think this is very noble, and I appreciate the
fact that people in our community try to help when and where ever they can. How could I say no? I hope
the book will be a huge success and the authors raise a significant amount for the Banani Project (a
children’s hospital in the Dogon Country) and the CEAFA Alzheimer’s organization.

The book covers many different topics, and personally I view it as the perfect introduction to all different
aspects of the software-define data center by the world’s top experts. It all begins with VMware vSphere
and then takes you in to the trenches of software-defined storage (vSAN) and software-defined
networking (NSX). That is not where it ends, the book also covers monitoring, automation and even
VMware Cloud on AWS and various types of workloads like containers and Horizon View.

I believe that the book demonstrates how the world of IT has changed in the past 10 years, but also
what will be on your list of projects to complete in the upcoming years. Some of you may have already
seen the light and have adopted software defined networking or storage, some of you may have dipped
their toes in the cloud native ocena, reality is that most of you reading this book are still on your journey
towards the software-define data center.

The question which then rises is what the most challenging aspect will be on this journey? I believe
that the most challenging aspect is going to be the transformation which is required from a people and
process point of view. Books like these will prepare you for the technical aspect of the transformation,
but as an IT team, as a company, crucial steps will need to be made to allow you to take advantage of
the flexibility and agility a software-defined data center offers. Do your change process for instance align
with this new way of deploying workloads? Is your organization structure ready for this level of integration
between infrastructure components? In other words, how often do you talk to the storage administrators
or the network administrators? Or are you the virtualization, network and storage administrator? Either
way, this book is a great starting point for your journey towards the software-defined data center.

Enjoy the 1000+ pages of content, and if you have the opportunity please consider donating to charity
on behalf of the authors. They have spent a lot of time and effort on writing this book, their reward is the
satisfaction of #GivingBack to the community.

Duncan Epping
Chief Technologist @ VMware
Blogger @ Yellow-Bricks.com

#VMwarePorvExperts 23
Índice de capítulos

Capítulo 1 - Introducción (Xavier Genestós).......................................................................................25

Capítulo 2 - vCenter, ESXi’s y VMs (Gorka Izquierdo)........................................................................44

Capítulo 3 - Instalación, Configuración y Actualización (Xavier Caballé)..........................................149

Capítulo 4 - Redes en vSphere (Miguel Ángel Alonso).....................................................................222

Capítulo 5 - NSX (Miguel Ángel Alonso)...........................................................................................251

Capítulo 6 - Almacenamiento en vSphere (Leandro Ariel Leonhardt)...............................................282

Capítulo 7 - vSAN (Federico Cinalli).................................................................................................302

Capítulo 8 - Alta Disponibilidad (Leandro Ariel Leonhardt)................................................................360

Capítulo 9 - Backup y Réplicas (Patricio Cerda)...............................................................................399

Capítulo 10 - Monitorización de vSphere (Jorge de la Cruz)............................................................489

Capítulo 11 - Monitorización con Centreon (Héctor Herrero)............................................................544

Capítulo 12 - VDI con Horizon View (Ricard Ibáñez)........................................................................612

Capítulo 13 - Citrix en vSphere (Héctor Herrero)..............................................................................721

Capítulo 14 - vRealize Orchestrator (Federico Cinalli)......................................................................770

Capítulo 15 - PowerCLI (Miquel Mariano).........................................................................................807

Capítulo 16 - vRealize Automation (Federico Cinalli)........................................................................844

Capítulo 17 - Automatizando vSphere con Ansible (Miquel Mariano)...............................................894

Capítulo 18 - vSphere y Containers (Raúl Unzué)............................................................................932

Capítulo 19 - VMware Code - API (Daniel Romero)..........................................................................987

Capítulo 20 - VMware Cloud on AWS (Jorge de la Cruz)................................................................1009

Capítulo 21 - Consejos para equipos que administran VMware (Ariel Sánchez Mora)..................1049

#VMwarePorvExperts 24
Capítulo 1
Introducción

Xavier Genestós

#VMwarePorvExperts 25
Capítulo 1 - Introducción Xavier Genestós

1. Introducción

1.1 ¿Qué es la virtualización?

La virtualización establece una capa de abstracción entre el hardware y el sistema operativo de una
máquina virtual.

Esta capa de abstracción permite disponer de varios equipos virtuales dentro de un equipo físico.

La capa de abstracción entre el hardware y el sistema operativo de una máquina virtual nos la
proporciona el hipervisor.

El equipo donde se instala el hipervisor se le llama: host, mientras que el sistema operativo de la
máquina virtual, se le denominará: guest.

El sistema operativo de una máquina virtual (guest) verá el hardware presentado por el hipervisor.

El hardware presentado por el hipervisor (host) a las máquinas virtuales (guests) no será igual al
hardware físico.

Las máquinas vituales (guests) verán lo que configuremos en el hipervisor (host).

Será el hipervisor el que regulará los recursos demandados por las máquinas virtuales.

1.2 Tipos de hipervisor

Podríamos dividir los hipervisores en dos grandes tipos, los hipervisores de tipo 1 y los de tipo 2.

Tipos de hipervisor
Tipo 1 Tipo 2

Fuente de la foto: https://es.wikipedia.org/wiki/Hipervisor

#VMwarePorvExperts 26
Capítulo 1 - Introducción Xavier Genestós

Vemos las diferencias entre ambos tipos de hipervisor:

Tipo1:

• Se instala directamente en el hardware físico.

• El hipervisor debe detectar los distintos elementos del hardware físico como las tarjetas de red, la
controladora de disco, etc..

• ­El rendimiento es superior a los hipervisores de tipo 2.

• Es el tipo de hipervisor adecuado para un entorno de producción.

• Ejemplos: VMware ESXi, Citrix XenServer, Microsoft Hyper-V.

Tipo2:

• Se instala en un equipo con un sistema operativo ya instalado en el hardware físico.

• El hipervisor debe ser compatible con el sistema operativo instalado en el hardware físico.

• El rendimiento es inferior a los hipervisores de tipo 1.

• Es el tipo de hipervisor adecuado para un entorno de laboratorio.

• Ejemplos: VMware Workstation, VMware Player, Virtualbox.

1.3 Extensiones CPU

Cuando aparece por primera vez la virtualización en el mercado, las CPU no estaban diseñadas para
ello.

En 2005 y 2006, Intel, en sus nuevos modelos de CPU añade extensiones de virtualización a la
arquitectura de sus CPUs y le llama: Intel VT (Intel Virtualization Technology), mientras que AMD hace
lo propio y le llama: AMD-V (AMD Virtualization).

El soporte para la virtualización: Intel VT o AMD-V puede activarse o desactivarse en la BIOS del
sistema.

Más adelante, se introduce Intel VT-x y AMD-V-x, que permite al hipervisor iniciar máquinas virtuales
con sistemas operativos de 64bits.

En CPUs Intel, podemos verificar si VT-x está activado utilizando: “Intel® Processor Identification
Utility”.

https://downloadcenter.intel.com/product/5982/Intel-Processor-Identification-Utility

Vista de la herramienta para Windows donde podemos ver si está activado Intel VT-x:

#VMwarePorvExperts 27
Capítulo 1 - Introducción Xavier Genestós

A día de hoy es imprescindible que estén habilitadas las extensiones de VT en la BIOS del sistema
para instalar un hipervisor.

1.4 Servidores virtuales VS servidores físicos

Trabajar con servidores virtuales en vez de servidores físicos, nos permitirá:

• Ahorro y mayor utilización de los recursos físicos

Al compartir los distintos recursos de hardware: CPUs, RAM, red, entre distintas máquinas virtuales
conseguiremos que no hayan servidores con muy poca carga y otros con mucha carga, por tanto
necesitaremos menos recursos físicos para ofrecer los mismos servicios.

También ahorraremos espacio y energía. Ya no necesitamos para cada servidor un hardware


dedicado. Al compartir el hardware, se requieren menos servidores físicos, por tanto, menos
espacio y menos consumo de energía.

• Copias de seguridad y recuperación de desastres

Las copias de seguridad pueden realizarse utilizando el hipervisor y se pueden respaldar máquinas
virtuales sea cual sea el estado del sistema operativo de su interior.

Podemos hacer copias de seguridad de máquinas virtuales apagadas, que se estén reiniciando en
el momento de la copia, de cualquier sistema operativo.

El respaldo de todos los datos se simplifica notablemente.

Por otro lado, está la recuperación. La recuperación al no depender del hardware físico se simplifica
notablemente y el tiempo se reduce.

Este hecho, también abre la puerta a disponer de planes de recuperación de desastres mucho más
simples, rápidos y fiables.

#VMwarePorvExperts 28
Capítulo 1 - Introducción Xavier Genestós

• Provisionado mucho más rápido

Provisionar una máquina virtual e instalar el sistema operativo es mucho más rápido que provisionar
un servidor físico e instarle el sistema operativo.

También tenemos herramientas como la clonación de máquinas virtuales que nos reducen el
tiempo de provisionado.

• Administración más rápida

Mover una máquina virtual, iniciarla, apagarla, todas estas operaciones son mucho más rápidas
si trabajamos con máquinas virtuales. La administración también se centraliza. El reinicio de las
máquinas es más rápido.

• Alta disponibilidad

Se ofrecen ciertas herramientas que nos ofrecen la posibilidad de ofrecer alta disponibilidad a nivel
de servicio como la puesta en marcha automática de una máquina virtual en otro host caso de
caída o la réplica de máquinas virtuales.

1.5 VMware Compatibility Guide

Como hemos visto en un punto anterior, VMware ESXi es un hipervisor de tipo 1 y por tanto se instalara
directamente en el hardware, sin instalar un sistema operativo previo.

El hardware sobre el cual instalaremos VMware ESXi ha de ser compatible.

Es por este motivo que hemos de verificar la compatibilidad del hardware antes de instalar.

Dependiendo de la versión de VMware ESXi a instalar, funcionará o no en un hardware.

La lista de compatibilidad va variando y un hardware donde funcionaba VMware ESXi 6.5, puede que
no funcione con VMware ESXi 6.7.

La URL para verificar la compatibilidad es la siguiente:

https://www.vmware.com/resources/compatibility/search.php

#VMwarePorvExperts 29
Capítulo 1 - Introducción Xavier Genestós

Vista web VMware Compatibility Guide

Además de de verificar si el hardware es compatible con la versión de VMware ESXi que vamos
a instalar, también podemos ver para cada versión de VMware ESXi, los sistemas operativos que
podemos instalar por cada máquina virtual, así como la compatibilidad con otros productos de VMware.

1.6 FAQ básico sobre la virtualización

1. Tengo máquinas físicas que acceden a dispositivos USB. ¿Las puedo virtualizar?

Existe opción de configurar “USB passthrough”.

Con “USB passthrough” podemos mapear un dispositivo USB físico conectado a un host a una
máquina virtual.

Con esta opción tendremos el problema que si movemos la máquina virtual de host perderemos la
visibilidad con el dispositivo.

También hay hardware físico que permite pasar de USB a Ethernet y así hacer visible el dispositivo
USB por la red.

Es importante tener en cuenta que es necesario realizar las pruebas antes de realizar cambios en
producción.

2. ¿Puedo utilizar los snapshots (instantáneas) como método de copias de seguridad?

No. Los snapshots no son copias de seguridad.

Los discos correspondientes a los snapshots se guardan en la misma ubicación donde están
situados los discos de la máquina virtual.

Cuando una VM está funcionando con un snapshot, requiere igualmente de los discos VMDK
originales.

#VMwarePorvExperts 30
Capítulo 1 - Introducción Xavier Genestós

El rendimiento de una VM con un snapshot es menor si la VM tiene algún snapshot.

Se recomienda utilizar los snapshots de forma que la VM esté funcionando con un snapshot el
mínimo tiempo posible.

3. No puedo instalar ESXi en un servidor físico. ¿Cómo resuelvo el problema?

Algunos errores típicos en la instalación de ESXi son:

• El hardware donde estas instalando VMware ESXi no está certificado por VMware: Revisa que
exista una correspondencia entre el servidor físico y la versión de ESXi que quieres instalar en:
“VMware Compatibility Guide”

• Revisa en la BIOS del servidor físico que tengas habilitado el VT en las opciones de CPU.

• Revisa que tengas acceso al storage donde quieres instalar VMware ESXi, por ejemplo, si se
trata de un RAID en storage local, tendrás que crear el volumen virtual primero antes de instalar.

4. ¿Existe perdida de rendimiento al virtualizar un servidor físico?

Sí, pero la pérdida a día de hoy, en hipervisores de tipo 1 es muy pequeña.

En hipervisores de tipo 2, la perdida de rendimiento es mucho mayor que los hipervisores de tipo 1.

La clave para evitar problemas de rendimiento es dimensionar correctamente la infraestructura


virtual.

5. Tengo Windows Server instalado en un equipo físico: ¿Puedo conservar la licencia si lo virtualizo?

Depende del tipo de licencia.

Si disponemos licencia OEM o ROK y la hemos adquirido asociada a un servidor físico que
pretendemos virtualizar a otro servidor físico donde está instalado el hipervisor, no podremos
hacerlo a nivel legal, sí a nivel técnico.

Las licencias OEM o ROK van asociadas a un hardware físico.

Podemos utilizar licencias OEM o ROK en entornos virtuales siempre y cuando las adquiramos de
forma conjunta con el host donde tenemos instalado el hipervisor.

Existen licencias de Microsoft que no van asociadas a la compra de un hardware físico como las
licencias por volumen, en este caso podemos pasar de físico a virtual a nivel técnico y legal.

6. No puedo instalar Windows Server ROK en una máquina virtual.

El problema al instalar puede ocurrir debido al aislamiento que por defecto aplica el hipervisor a las
máquinas virtuales.

El hipervisor “esconde” cierta información ubicada en la BIOS física del servidor donde se encuentra
instalado VMware ESXi.

Cuando iniciamos una instalación de Windows Server con una licencia ROK, el instalador va a
buscar en la BIOS del sistema si el equipo es DELL, HPE, etc...

Una ISO de Windows Server con licencia ROK subministrado por DELL, solo podrá ser instalado
en un servidor DELL.

Si el instalador, no puede realizar la verificación, aparece un error.

#VMwarePorvExperts 31
Capítulo 1 - Introducción Xavier Genestós

Aquí la solución:

https://www.sysadmit.com/2018/09/VMware-instalar-windows-server-rok.html

7. Licenciamiento Microsoft de Windows Server: ¿Existe un ahorro si licenciamos máquinas virtuales


en vez de máquinas físicas?

Sí.

Por cada edición “Standard” se pueden licenciar dos máquinas virtuales.

Por cada edición “Datacenter” se pueden licenciar infinitas máquinas virtuales por cada socket de
CPU físico del hipervisor.

8. El hardware de una máquina virtual no corresponde con el hardware del host físico donde está
instalado el hipervisor. ¿Es correcto?

Sí. El hipervisor muestra a las VMs hardware que no existe físicamente.

Vista parcial de un administrador de dispositivos de Windows (devmgmt.msc) de una máquina


virtual (guest): Aquí podemos ver cómo el modelo de la VGA y NIC del equipo donde está instalado
el hipervisor (host) no corresponden con los modelos de VGA y NIC que hay en una máquina
virtual.

Vista parcial de un administrador de dispositivos de Windows (devmgmt.msc)

9. ¿Qué son las VMware Tools?

Las VMware Tools son los drivers que se instalan en las máquinas virtuales (guest).

Además instalan un servicio para que el hipervisor pueda comunicar con las mismas y reciba un
feedback de los recursos que les va ofreciendo.

#VMwarePorvExperts 32
Capítulo 1 - Introducción Xavier Genestós

Vista asistente para la instalación VMware Tools en Windows

10. ¿Qué es un DataStore?

Un DataStore es donde se guardan los ficheros relacionados con cada máquina virtual.

Los DataStores pueden ser presentados por NAS (almacenamiento de ficheros) o por SAN
(almacenamiento por bloques).

En el caso SAN, el sistema de ficheros utilizando será VMFS.

#VMwarePorvExperts 33
Capítulo 1 - Introducción Xavier Genestós

Diagrama conceptual: Ejemplo de VMs y datastores

Fuente imagen: https://www.vmware.com/pdf/vi_architecture_wp.pdf

11. ¿Qué es Virtual Center?

Virtual Center es una herramienta para administrar varios hosts VMware ESXi y así poder realizar
ciertas operaciones.

Por ejemplo, utilizando Virtual Center, podremos mover máquinas virtuales en caliente utilizado la
tecnología vMotion si el licenciamiento adquirido nos lo permite.

Hasta la versión 6.7, es posible instalar Virtual Center sobre sistemas operativos Windows o bien
también es posible deplegar un appliance virtual llamado: VCSA (vCenter Server Appliance).

12. ¿Qué es la hardware version?

La “hardware version” de una máquina virtual indica las características de hardware virtual
compatibles de la máquina virtual.

Las características de hardware virtual incluyen la BIOS y EFI, ranuras PCI virtuales disponibles,
número máximo de CPU, memoria RAM máxima entre otros.

13. En una VM: ¿Se permite añadir o quitar hardware virtual en caliente?

Sí, es posible añadir hardware virtual de una VM siempre y cuando cumplamos los siguientes
requisitos:

• La hardware version mínima admitida es la: 7

• La funcionalidad no es compatible si la VM está siendo replicada con Fault Tolerance.

• Solo encontraremos la funcionalidad en la edición Enterprise Plus de vSphere.

#VMwarePorvExperts 34
Capítulo 1 - Introducción Xavier Genestós

• No puedes quitar hardware en caliente, solo añadir. Por ejemplo: Para quitar RAM en caliente,
será necesario detener la VM.

• El sistema operativo debe permitir añadir hardware en caliente. En el caso de Windows Server,
se permite a partir de Windows Server 2003.

14. ¿Qué es un cluster?

Un cluster es una agrupación de hosts VMware ESXi.

Cuando se agrega un host a un clúster, los recursos del host se convierten en parte de los recursos
del clúster.

El clúster gestiona los recursos de todos los hosts dentro de él.

Los clústeres habilitan las funcionalidades de: vSphere High Availability (HA) y vSphere Distributed
Resource Scheduler (DRS).

15. ¿Qué es un resource pool?

Un resource pool, permite limitar el uso de CPU y memoria RAM para las VMs que definamos.

16. ¿Que es un snapshot?

Realizar un snapshot de una máquina virtual significa guardar el estado de la máquina virtual para
que en el futuro poder retroceder el estado de la misma al punto donde se ha realizado el snapshot.

Un snapshot no es un backup, ya que una máquina virtual que funciona con un snapshot requiere
los ficheros del estado anterior para poder funcionar.

1.7 VMware historia y sus productos

La compañía VMware fue fundada en 1998 y en su segundo año de vida, en 1999 lanzó su primer
producto: VMware Workstation y en 2001 lanzo VMware GSX Server y VMware ESX.

En 2003 introdujo la tecnología vMotion y Virtual Center para administrar los hosts de forma centralizada.

Se introduce el soporte para 64 bits en 2004.

A partir de aquí, son muchas las adquisiciones que va realizando VMware y son muchos los productos
que va lanzando.

1.7.1 Productos básicos entorno de laboratorio


Todos ellos son hipervisores de tipo 2.

• VMware Workstation: Software de pago. Aplicación para sistemas operativos Windows o Linux
que permite crear, iniciar máquinas virtuales.

• VMware Fusion: Software de pago. Igual que VMware Workstation pero para sistemas operativos
MacOSX.

• VMware Player: Software gratuito. Permite la ejecución, de máquinas virtuales creadas con

#VMwarePorvExperts 35
Capítulo 1 - Introducción Xavier Genestós

VMware Workstation. La nomenclatura player, es vigente hasta la versión 7 del producto y pasa a
llamarse: VMware Workstation Player, siendo un producto de pago, solo será gratuito en entornos
educativos o para uso particular. Más información, en este enlace:

https://www.sysadmit.com/2017/07/VMware-player-vs-workstation-diferencias.html

Hemos de verificar la compatibilidad de cada versión de Workstation, Fusion o Player con la versión
del sistema operativo donde vamos a instalar el producto (host).

También la compatibilidad de los sistemas operativos guest se amplia con cada nueva versión.

Por ejemplo, la compatibilidad con sistemas operativos guest: Windows Server 2019 se introduce con
la versión de VMware Workstation: 15.0.2

1.7.2 Productos básicos entorno de producción


• VMware GSX // VMware Server: Software gratuito. Su nombre inicial era VMware GSX Server y
en 2006 pasa a llamarse VMware Server 1.0. Se lanza la versión 2 de VMware Server y el producto
queda discontinuado en 2011. Es un hipervisor de tipo 2.

Uno de los problemas de este hipervisor es que al ser de tipo 2, el rendimiento para entornos
productivos no era muy bueno.

• VMware ESX // VMware ESXi: Software de pago, todo y que existe una licencia gratuita con
limitaciones.

Es un hipervisor de tipo 1, por tanto debe instalarse directamente en el hardware físico.

El hardware físico debe ser compatible con la versión de hipervisor instalada.

En un inicio existía la versión ESX (Elastic Sky X), disponía un kernel propio: VMKernel y era
administrado por un sistema operativo llamado Service Console.

Más adelante, en la versión 3 de ESX, VMware lanza ESXi (Elastic Sky X Integrated), se elimina la
service console y se integra todo en uno: el kernel y la administración.

Es con ESXi, aparece la Direct Console User Interface (DCUI) para administrar el servidor y la
instalación de ESXi es mucho más rápida que la instalación de ESX.

Igualmente, el administrador, puede elegir si instalar ESX o ESXi hasta la versión 5, que solo queda
ESXi.

• VMware Virtual Center: Software de pago. Permite añadir varios hosts ESXi y así poder realizar
distintas operaciones entre ellos, por ejemplo, mover máquinas virtuales entre los host ESXi, entre
otros.

• VMware Converter: Software gratuito. Permite convertir máquinas físicas a virtuales y también
permite convertir distintos formatos de máquinas virtuales: de Hyper-V a ESXi, de VMware
Workstation a ESXi, etc..

#VMwarePorvExperts 36
Capítulo 1 - Introducción Xavier Genestós

1.7.3 Productos avanzados


Todos los productos listados a continuación son de pago:

• VMware Horizon View: Permite crear y administrar un entorno VDI (Virtual Desktop Infrastructure).

• VMware vRealize: Suite de productos que, complementados con vSphere, vSAN y NSX, son la
base del Software Defined Datacenter de VMware.

• VMware NSX: Virtualización del networking.

• VMware vSAN: Solución de almacenamiento distribuido, orientado a objetos y embebido en


VMware ESXi.

• VMware Site Recovery Manager: Permite automatizar la recuperación de las máquinas virtuales
en otro entono mediante reglas configurables.

1.8 ESXi: Tecnologías básicas

En este punto enumeraremos y realizaremos una descripción de distintas tecnologías disponibles en


el hipervisor de tipo 1: VMware ESXi.

En otros puntos del libro, se explicarán los requisitos técnicos de cada tecnología y su correcta
configuración.

Es conveniente entender las distintas tecnologías disponibles de cara al licenciamiento, es importante


no sobrelicenciar, es decir, no elegir ediciones que tengan más funcionalidades que las necesitemos.

Todas estas tecnologías, al ser necesaria la interacción entre más de un host VMware ESXi, requieren
de Virtual Center.

1.8.1 vMotion
Existen tres tipos de vMotion: vMotion, svMotion y evMotion.

Todos los tipos tienen en común:

• No se produce reinicio de la VM.

• La pérdida de conectividad es mínima o inexistente.

• No se necesita que las VMs estén dentro de un Clúster, excepto si se requiere activar EVC para
vMotion.

• No tiene nada que ver con el servicio HA (High Availability).

• Es buena idea dedicar un segmento de red para este tipo de tráfico.

• Requiere Virtual Center para poder realizar el proceso.

#VMwarePorvExperts 37
Capítulo 1 - Introducción Xavier Genestós

A- vMotion

• Mover VMs de host ESXi sin ser detenidas (en caliente).

• Los ficheros de las VMs no se mueven. Los ficheros de las VMs residen y se mantienen en un
storage compartido accesible entre origen y destino.

B- sVMotion (Storage vMotion)

• Mueve los ficheros de las VMs entre storages compartidos en caliente.

• Los storage compartidos deben poderse ver entre origen y destino.

• No se permite mover de DAS (Direct Attached Storage) a DAS.

C- evMotion (enhanced vMotion):

• Se introduce en ESXi 5.1.

• Permite mover una VM de host y de storage a la vez, en caliente.

• Se permite mover de DAS (Direct Attached Storage) a DAS: Sin visibilidad directa del storage en
el host ESXi destino.

1.8.2 HA (High Availability)


A - HA

• HA permite que si cae un host, sus VMs pasan a iniciarse en otro host.

• La VM sufre un “PowerOff no ordenado” y un PowerOn.

• Actúa siempre y cuando hayan recursos disponibles para levantar las VM.

• Requiere Virtual Center.

• Requiere Storage compartido.

• Requiere que las VM estén dentro de un clúster.

• No usa VMotion.

B- HA proactivo

• Introducido a partir de ESXi 6.5.

• Es capaz de leer los sensores de hardware del host ESXi y actúa según la configuración que
realicemos.

• Por ejemplo, fallo de una fuente de alimentación de un host con doble fuente de alimentación
redundada, vMotion de todas las VMs a otro host ESXi.

• Se requiere que el hardware físico del host VMware ESXi sea compatible con el HA proactivo.

#VMwarePorvExperts 38
Capítulo 1 - Introducción Xavier Genestós

1.8.3 FT (Fault Tolerance)


• FT consiste en una réplica de una VM en otro host: Cuando cae el host con la VM protegida con FT
entra en marcha la VM que estaba siendo replicada. “Un RAID-1” de una VM.

• No se produce reboot de la VM (a diferencia de HA).

1.8.4 DRS (Distributed Resource Scheduler)


A- DRS

• DRS consiste en una monitorización del uso de recursos (CPU/RAM) de las máquinas virtuales de
un clúster y de la reubicación (vMotion) de las máquinas virtuales en otros hosts. La idea es repartir
la carga de CPU/RAM entre los distintos hosts de forma automática.

B- Storage DRS

• La idea de Storage DRS es la misma que con el DRS tradicional (CPU/RAM) pero a nivel de
datastore, de esta forma se reparte la carga de storage entre datastores.

1.9 Licenciamiento VMware: Características generales

Para verificar el licenciamiento se recomienda consultar la web de VMware y así revisar los distintos
cambios que VMware efectúa.

En este apartado veremos distintos conceptos básicos sobre el licenciamiento que funcionan de la
misma manera en todas las versiones del producto:

1. Existe una versión de ESXi gratuita (ESXi Free).

La versión gratuita de ESXi, si repasamos las limitaciones que tiene, veremos que no es apta para
entornos de producción ya que por ejemplo, no dispone de las Vsphere APIs para el backup a nivel
de hipervisor, ni tampoco permite añadir el host a un Virtual Center, por tanto no podremos utilizar
vMotion, HA, etc…

Podemos ver las limitaciones de ESXi gratuito aquí:

https://www.sysadmit.com/2016/03/VMware-esxi-gratuito-limitaciones.html

A nivel conceptual, para licenciar VMware ESXi, hemos de tener en cuenta lo siguiente:

2. Licenciar todos los sockets de todos host

Es necesario licenciar todos los sockets de todos los host con VMware ESXi instalado. El coste
de licenciar un host VMware ESXi con 1 socket es inferior a licenciar un host VMware ESXi con 2
sockets.

#VMwarePorvExperts 39
Capítulo 1 - Introducción Xavier Genestós

3. No se licencia por RAM instalada en los host

No hay límites a nivel de licenciamiento para RAM, o cores: El coste de licenciar un host VMware
ESXi con 128GB de RAM es el mismo que con 256GB de RAM.

4. No se licencia por número de VMs

No hay límites a nivel de licenciamiento para máquinas virtuales: El coste de licenciar un host VMware
ESXi con 20 VMs es el mismo que con 100 VMs. Cuidado, después tenemos el licenciamiento a
nivel de sistema operativo de cada VM, por ejemplo, si vamos a instalar VMs con Windows Server,
deberemos adquirir licenciamiento Microsoft.

5. Virtual Center se licencia por separado

Virtual Center (VC) se licencia a parte, sin embargo hay Kits que lo incorporan. Un Kit es la suma
de cierta edición de ESXi y Virtual Center.

6. Versión de evaluación

Al instalar un host VMware ESXi este se licenciará de forma automática en modo de evaluación.
El modo evaluación permite usar todas las funcionalidades del producto durante 60 días. Los
días solo cuentan si tenemos los hosts ESXi encendidos. Cuando estamos instalando un sistema
productivo, es importante licenciar después de instalar, de esta forma evitamos dejarnos ningún
host ESXi funcionando en modo evaluación.

7. Evita sobrelicenciar

Revisa las tecnologías que necesitas y elige la edición adecuada.

Algunos ejemplos:

Tecnología A partir de la edición


vMotion Essentials Plus
sVMotion/evMotion Standard
HA (High Availability) Essentials Plus
Proactive HA (Proactive High Availability) Enterprise Plus
FT (Fault Tolerance) Standard
DRS (Distributed Resource Scheduler) Enterprise Plus
Storage DRS (Storage Distributed Resource Scheduler) Enterprise Plus

1.10 ESXi y VCenter: Herramientas GUI de administración

Para administrar un solo host VMware ESXi, no utilizaremos Virtual Center, en cambio cuando
dispongamos de mas de un host VMware ESXi y queramos realizar operaciones que interactuen entre
ellos, necesitaremos Virtual Center.

Las herramientas para administrar un solo host VMware ESXi o bien Virtual Center, varian segun la
versión utilizada.

#VMwarePorvExperts 40
Capítulo 1 - Introducción Xavier Genestós

• Para administrar un host VMware ESXi:

La forma mas sencilla de ver la herramienta o herramientas disponibles que podemos utilizar
cuando disponemos de un host VMware ESXi, es situando la dirección IP en navegador web.

Dependiendo de la versión de VMware ESXi, tendremos una serie de herramientas u otras


disponibles.

Algunos ejemplos:

VMware ESXi 6.0 Update 2:

Si accedemos vía web a la dirección IP del host VMware ESXi, veremos que se permite: “vSphere
Client for Windows” o bien “Vmware Host Client” (administración web basada en HTML5).

VMware ESXi 6.5 y 6.7:

Nos aparecerá directamente el formulario para iniciar sesión en “Vmware Host Client”, siendo este
el único método de administración posible.

• Para administrar Virtual Center:

De la misma forma que cuando disponemos de un host VMware ESXi, disponemos de varias
herramientas que varian con el transcurso de las versiones, ocurre de la misma forma cuando
disponemos de Virtual Center.

En las primeras versiones, Virtual Center era administrable vía “vSphere Client for Windows”.

Es la versión 6.0 de Virtual Center, la última que permite la conexión con “vSphere Client for
Windows”.

Es en la versión 6.5 donde se introduce una alternativa en HTML5 a la versión web basada en
Flash.

#VMwarePorvExperts 41
Capítulo 1 - Introducción Xavier Genestós

#VMwarePorvExperts 42
Capítulo 2
vCenter, ESXi’s y VMs

Gorka Izquierdo

#VMwarePorvExperts 44
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Conceptos de VMware

Antes de empezar a administrar y gestionar una infraestructura VMware es muy importante tener
claros una serie conceptos y nomenclaturas, por lo menos las más utilizadas.

vCenter: Seguramente el componente más importante, es el servidor de VMware que gestiona de


forma centralizada todos los Hosts y sus recursos. Aporta tecnologías como vMotion, svMotion, HA,
FT, DRS y demás que únicamente funcionan sobre un vCenter Server.

VCSA: vCenter Server Appliance, es la versión Linux de vCenter

Plugin vCenter: aplicación que se integra con la consola de gestión del servidor de vCenter Server.
Existen cientos de plugins que permiten gestionar ciertas funcionalidades de forma centralizada desde
el vCenter

Cluster: Conjunto de dos o más Hosts ESXi que funcionan en grupo para proporcionar sistemas de
Alta Disponibilidad y tolerancia a fallos.

Datastore: Almacenamiento de un Host ESXi de VMware para almacenar Máquinas Virtuales, Plantillas
e ISOs. Utiliza el sistema de archivos VMFS (Virtual Machine File System), los Datatores pueden en
NFS y VMFS

Host ESXi: Hypervisor propietario de VMware que se ejecuta en un servidor físico.

High Availability (HA): Sistema de Alta Disponibilidad que agrupa en un clúster de Hosts ESXi
Máquinas Virtuales y en caso de error o caída de un Host ESXi las Máquinas Virtuales se reinician en
el otro.

VMFS: Virtual Machine File System, sistema de archivos propietario de VMware, optimizado para
clustering (para que dos o más host ESXi accedan al mismo sistema de ficheros concurrentemente sin
que se corrompa el sistema de ficheros.

NFS: Network File System, sistema de fichero de red, en VMware permite las versiones NFS v3 y NFS
4.1

ISCSI: Protocolo de almacenamiento vía eed Ethernet (encapsula información SCSI sobre tramas
Ethernet).

Máquina virtual: Una máquina virtual es un software que simula un hardware de un equipo físico y
está compuesta por un conjunto de archivos: Configuración, discos, etc..

vSwitch Standard: Switch virtual que se crea a nivel de Host ESXi para ofrecer conectividad de red a
los host ESXi y las máquinas virtuales.

vSwitch Distribuido: Switch Virtual que se establece en el vCenter y donde la configuración se


propaga por todos los host ESXi asociados con el vSwitch. Dispone de ventajas adicionales sobre los
switches Standard.

Portgroup: puerto lógico de un vSwitch.

Snapshot: Un Snapshot es un una “foto” que conserva el estado y los datos de la Máquina Virtual en
el momento que crea el Snapshot.

#VMwarePorvExperts 45
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Clon: Copia exacta de una máquina virtual

DRS: Distributed Resource Scheduler, utilidad que equilibra las cargas de trabajo con los recursos
disponibles en un entorno virtualizado.

Plantilla: Imagen maestra de una Máquina Virtual.

Update Manager: Herramienta que permite la administración centralizada y automatizada de parches


y versiones para VMware vSphere.

vMotion: Utilidad que permite mover en caliente una máquina virtual encendida a otro Host ESXi.

Storage vMotion: Utilidad que permite mover en caliente las máquinas virtuales y los ficheros que la
componen entre Datastores.

vSphere Web Client: Versión web basada en Flash de vSphere Client.

vSphere Client HTML5: Versión web basada en HTML5 de vSphere Client.

DCUI: Direct Console User Interface, consola de gestión del host ESXi.

Pool de recursos: Utilidad que permite asignar y reservar recursos a Máquinas Virtuales.

Virtual Appliance: Máquina virtual empaquetada y preparada para importar y desplegar en el


inventario. Utiliza formato. OVA y OVF. Más información:https://www.sysadmit.com/2013/12/vmware-
formatos-ova-y-ovf.html

#VMwarePorvExperts 46
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

1. Instalación de Licencias de vCenter y ESXi

Cuando disponemos de un solo host VMware ESXi, podemos administrarlo de forma directa vía web a
partir de la versión ESXi 6.0 Update 2.

En versiones anteriores, la administración se realizaba utilizando un cliente de Windows.

Para instalar un host VMware ESXi, podemos verlo en el capítulo 3 de este libro:

“Instalación y configuración de vCenter y ESXi”

Cuando disponemos de más de un host VMware ESXi y queremos realizar ciertas acciones entre los
distintos hosts VMware ESXi, necesitaremos Virtual Center, por ejemplo: mover máquinas virtuales
entre los distintos hosts.

Virtual Center solo tiene sentido cuando disponemos de más de un host VMware ESXi.

Virtual Center es una herramienta de administración, por tanto, en caso de caída, las máquinas virtuales
de los hosts VMware ESXi, seguirán funcionando con normalidad.

Con la versión 6.7 se permite desplegar virtual Center en forma de appliance virtual y en forma máquina
virtual de Windows (En la próxima versión no incluirá vCenter Server para Windows https://blogs.
vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html).

El acceso a vCenter Server Appliance (VCSA) para administrar las máquinas virtuales se realiza vía
web, utilizando el vSphere Client HTML5 o el cada vez más en desuso vSphere Web Client (Flash),
que se elminará completamente en la siguiente versión.

Por defecto, cuando realizamos la primera instalación del vCenter Server Appliance y de los ESXi
disponemos de un periodo de prueba de 60 días, pasado este tiempo si no instalamos las licencias
correspondientes, los hosts ESXi se desconectarán, las máquinas apagadas ya no se podrán encender
y las VMs encendidas, seguirán en ese estado hasta que se apaguen, una vez apagadas tampoco se
podrán encender.

Una vez adquiridas las licencias las tendremos que instalar, para eso nos conectaremos vía vSphere
Client HTML5 a nuestro vCenter e iremos a la pestaña Administración del menú principal.

#VMwarePorvExperts 47
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Nos dirigimos al apartado: “Licencias” y le damos a “Agregar nuevas licencias”. Las licencias las
podemos descargar una vez compradas y habiendo creado una cuenta en VMware.

Escribimos las claves de licencias tanto las de vCenter como las de ESXi en diferentes líneas.

Es importante tener en cuenta que el número de serie para licenciar un host VMware ESXi es distinto
al número de serie de un Virtual Center.

#VMwarePorvExperts 48
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Editamos los nombres de las licencias y les ponemos uno descriptivo.

Finalizamos el asistente de instalación de licencias.

#VMwarePorvExperts 49
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez instaladas las licencias nos quedará asignarlas a su correspondiente producto.

Empezaremos por el vCenter Server Appliance, vamos a la pestaña Activos --- Asignar licencia.

#VMwarePorvExperts 50
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos la licencia y aceptamos.

Ahora asignaremos la licencia a los Host ESXi seleccionándolos todos a la vez.

#VMwarePorvExperts 51
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Asignamos la licencia a los ESXi.

Terminada la asignación de licencias comprobaremos que todo está correcto viendo las instancias y
las CPU en uso. También podremos ver en el menú inferior las características según el tipo de licencia
que hayamos adquirido.

#VMwarePorvExperts 52
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

2. Autenticación e integración con Directorio Activo

Los orígenes de identidad te permiten adjuntar uno o más dominios a vCenter Single Sign-On. Un
dominio al final no es más que un repositorio de usuarios y grupos que el servidor de inicio de sesión
de vCenter usa para la autenticación de usuarios. La integración con directorio Activo y un dominio
Windows por ejemplo, nos puede ser muy útil para que determinados usuarios de un grupo, puedan
administrar la infraestructura o parte de ella, con ciertos roles y permisos.

2.1 Que es un origen de identidad


Un origen de identidad es un conjunto de datos de usuarios y grupos, estos datos de usuario y grupos
se almacenan en el directorio activo, OpenLDAP o localmente en el sistema operativo de la máquina
donde está instalado vCenter Single Sign-On.

Cuando haces la primera instalación, la instancia de vCenter Single Sign-On tiene el origen de identidad
del sistema operativo local como vsphere.local, este es un dominio interno.

2.2 Tipos de Orígenes de Identidad


• vCenter Single Sign-On: Cuando instalamos vCenter Single Sign-On, el origen de identidad por
defecto es el dominio vsphere.local (se le puede cambiar el nombre en la instalación), el usuario
con máximos privilegios que nos crea por defecto es el de administrator@vsphere.local.. Este
usuario se utiliza para acceder al vSphere Client y es el de mayores privilegios.

• Directorio Activo (autenticación integrada de Windows), vCenter Single Sign-On te permite


configurar con un dominio de Directorio activo como origen de identidad y utilizar usuario y grupos
de este.

• Directorio Activo como LDAP: Se utiliza para compatibilidad de versiones antiguas

• Open LDAP: Opción para configurar un origen de identidad con LDAP

• Sistema operativo local del Servidor SSO: Se muestra como LocalOS y no está disponible
en instalaciones de vCenter con varias instancias ya que es un origen de identidad del sistema
operativo local. El usuario root pertenece este origen de identidad.

2.3 Configurar integración con Directorio Activo


Si queremos utilizar los usuarios de nuestro domino Windows para administrar y gestionar los objetos
del vCenter, necesitaremos integrarlo con el Directorio Activo.

Importante:

• VCSA debe tener conectividad con alguno de los controladores de dominio (DC) que tenemos en
la infraestructura.

• El cliente DNS de VCSA apuntar a alguno de los servidores DNS de Active Directory.

#VMwarePorvExperts 53
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Para poder ejecutar este procedimiento, necesitaremos hacer login con el usuario administrator@
vsphere.local en el vSphere Client.

Para ello vamos a Menú ---- Administración

Hacemos clic en configuración --- Orígenes de identidad --- Agregar origen de identidad. Si nos fijamos,
veremos los orígenes de identidad que tenemos actualmente y que se crearon al hacer la instalación.

#VMwarePorvExperts 54
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Si no lo hemos unido el vCenter a ningún dominio previamente, nos saldrá este mensaje, por lo que
primero tendremos que unirlo al dominio.

Para eso vamos a la pestaña Dominio de Active Directory, seleccionaremos el vCenter y haremos clic
en Unirse a AD.

Nos pedirá rellenar unos campos,

• Dominio

• Unidad organizativa (opcional)

• Nombre de usuario

• Contraseña

#VMwarePorvExperts 55
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Añadidos estos datos, hacemos clic en unirse, nos pedirá reiniciar para que se apliquen los cambios.

Reiniciado el vCenter podremos continuar con el paso de Agregar origen de identidad.

Seleccionamos el tipo de origen de identidad que será Active Directory (autenticación integrada de
Windows), nombre del dominio y seleccionamos la opción de usar cuenta de equipo. Clic en Agregar.

#VMwarePorvExperts 56
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez agregado, veremos nuestro dominio de Windows junto a los otros.

A partir de aquí, ya podremos comenzar a jugar con los permisos y los usuarios de Directorio Activo,
podemos añadir usuario y grupos, darles los permisos o roles que veamos convenientes. Por ejemplo,
añadiendo al usuario administrador del dominio y dándole permisos solo de lectura de toda la
infraestructura y objetos del vCenter.

Para eso no posicionamos en el primero objeto del inventario que es el vCenter ---- permisos ---- clic
en el “+”

#VMwarePorvExperts 57
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos el dominio, usuario administrador de este domino y en función le diremos que solo de
lectura. Aceptamos.

Una vez añadido, lo veremos en la lista.

Si queremos configurar la autenticación de Active Directory y disponemos de versiones de Virtual


Center anteriores a la 6.7 o bien queremos realizar el procedimiento vía PowerCLI, podemos utilizar
el siguiente enlace:

https://www.sysadmit.com/2016/05/vmware-anadir-esxi-al-dominio-de-active-directory.html

#VMwarePorvExperts 58
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

A continuación, instalaremos el completo de autenticación mejorada, el complemento de autenticación


mejorada de VMware ofrece autenticación integrada en Windows y funcionalidad de tarjeta inteligente
basada en Windows.

Descargamos el complemento de autenticación mejorada el instalamos este plugin.

Comenzará el asistente de instalación.

#VMwarePorvExperts 59
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Y una vez instalado este plugin pasaremos a instalar el plug-in de servicio, que comenzará la instalación
una vez acabado el anterior.

#VMwarePorvExperts 60
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez instalado, marcaremos el check y le diremos conectar.

Desmarcamos el check “Always ask before allowing this site” para que no nos pregunte siempre y
hacemos clic en “Allow”.

Accederemos automáticamente al vSphere Client HTML5 y si intentamos encender, apagar la VM,


moverla o cualquier otra operación, no nos dará opción al tener solo permisos de lectura con el usuario
administrador del dominio.

#VMwarePorvExperts 61
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

#VMwarePorvExperts 62
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

3. Roles y permisos

En infraestructuras administradas por más de un administrador de sistemas, puede que nos interese
configurar roles y permisos.

Hay una serie de mejores y buenas prácticas de roles y permisos para mejorar la seguridad y la
administración de un entorno de vCenter Server.

VMware recomienda una serie de buenas prácticas con los roles y permisos:

• Cuando sea posible, asignar un rol a un grupo en lugar de a usuarios individuales, nos facilitará la
administración.

• Asignar permisos solo sobre los objetos donde lo necesiten, y asignar privilegios solo a los usuarios
o grupos necesarios. Usar la cantidad mínima de permisos para que sea más fácil de entender y
administrar.

• Usar carpetas para agrupar objetos, por ejemplo, crear una carpeta para máquinas virtuales según
S.O, otra carpeta para plantillas, otra según servicios que tenga la máquina virtual… de esta manera
la asignación de permisos será más fácil de administrar.

• No asignar un permiso restrictivo a un grupo, puede que en ese grupo haya un usuario administrador
y luego tenga problemas de permisos.

• Tener cuidado al agregar un permiso a los objetos raíz de vCenter Server, se puede dar demasiados
permisos.

• Cuidado con habilitar la propagación cuando asigne permisos a un objeto. Por ejemplo, si damos
permiso sobre una carpeta con varias VMs y añadimos otra nueva, tendremos que tener en cuenta
que se propagarán los permisos e igual no nos interesa que se tengan sobre esa nueva VM.

Todo ya dependerá de lo que quieras complicarte o el nivel de seguridad que quieras tener.

Para ver o configurar un nuevo Rol, vamos a Menú ---- Funciones, ahí veremos los roles que vienen
configurados por defecto. Como ejemplo vamos a clonar uno nuevo haciendo clic en el símbolo
después del signo “+”

#VMwarePorvExperts 63
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Como buena práctica, es bueno no modificar los que vienen por defecto, de ahí el que se utilice la
clonación.

Como información, si hacemos clic en cualquiera de los Roles, podremos ver la descripción, el uso y
los privilegios.

Una vez clonado el Rol, pasaremos a editarlo a nuestro gusto y según necesidades.

En este ejercicio he clonado el Rol solo lectura, porque solo quiero que tengan permisos de lectura
para toda la jerarquía, menos para una función, encender una máquina virtual.

#VMwarePorvExperts 64
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Editamos el Rol y en el menú de la izquierda, nos movemos hasta donde pone “Máquina Virtual”, la
seleccionamos y a la derecha nos mostrará todos los privilegios posibles. Como el Rol que hemos
clonado era solo de lectura, todos estos privilegios vendrán sin marcar.

Como solo queremos que pueda encender máquinas virtuales para esta prueba, seleccionamos el
privilegio de Máquina Virtual Encender.

#VMwarePorvExperts 65
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Editamos el nombre y la descripción del Rol por uno con más sentido.

Pasamos a la práctica, queremos que un grupo del domino con el Rol que hemos clonado, pueda
encender las máquinas virtuales de determinada carpeta. Así que seleccionando la carpeta vamos a la
pestaña Permisos y hacemos clic en el signo “+”.

#VMwarePorvExperts 66
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos de que dominio añadiremos los usuarios o grupos, y buscaremos un grupo del dominio
de Windows llamado Admin_vCenter, este grupo lo hemos creado anteriormente desde la consola de
usuarios y equipos de Directorio Activo de nuestro controlador de dominio, este grupo tiene 2 usuarios,
user01 y user02. Para terminar, marcamos el check de propagar a objetos secundarios ya que, si no
lo marcamos, no veríamos lo que hay de carpeta para abajo, aceptar.

Lo añadimos y cerramos sesión con el usuario que estamos.

#VMwarePorvExperts 67
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Accedemos con el usuario user01 y podremos comprobar que no veremos nada en la pantalla principal,
esto lógicamente es porque no tenemos permisos para estos objetos.

Para eso vamos al icono de Máquinas Virtuales y plantillas, donde solamente veremos la carpeta de la
que tenemos permisos, si nos fijamos la carpeta de plantillas no la vemos, pues es porque no tenemos
permisos.

#VMwarePorvExperts 68
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Si damos botón derecho sobre una Máquina Virtual veremos que solo nos deja encender

Una vez encendida, si intentamos apagar, suspender, reiniciar… veremos que no podremos hacerlo
al carecer de permisos necesarios. Como podéis ver podemos jugar bastante con roles y permisos y
podemos ajustar bastante el tema de seguridad, ya que en muchos sitios no utilizan estas ventajosas
características y siempre van por lo fácil y no seguro.

#VMwarePorvExperts 69
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

#VMwarePorvExperts 70
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

4. Introducción de Biblioteca de Contenido

Las bibliotecas de contenido son unos objetos que se utilizan para guardar plantillas de máquinas
virtuales, de vApp y otros tipos de archivos como imágenes ISO, de forma más centralizada, todo este
contenido se almacena en el Datastore. Unas de las ventajas de las bibliotecas de contenido es que
pueden compartir entre otras instancias de vCenter de la misma o diferente ubicación.

4.1 Tipos de Biblioteca de contenido


4.1.1 Biblioteca Local
La biblioteca local solo se usa para almacenar objetos en una única instancia de vCenter, aunque
podemos publicarla para que los usuarios de otras instancias de vCenter se puedan suscribir a ella.

4.1.2 Biblioteca suscrita


Las bibliotecas suscritas se originan de otras bibliotecas publicadas, se pueden crear en la misma
instancia o en otra diferente, este tipo de biblioteca se sincroniza automáticamente con la biblioteca de
origen para garantizar que el contenido este actualizado.

4.2 Creación de una biblioteca de Contenido


Para crear una biblioteca de contenido vamos a la pestaña menú --- Bibliotecas de contenido

Se abrirá el asistente donde rellenaremos los siguientes campos tales como nombre, notas y
seleccionaremos el vCenter donde queremos instalar la Biblioteca de contenido, de haber varios
utilizaremos el desplegable.

#VMwarePorvExperts 71
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionaremos el tipo de Biblioteca de contenido local, sin publicar externamente.

Seleccionaremos el Datastore donde irá la ubicación de almacenamiento para el contenido de la


Biblioteca

#VMwarePorvExperts 72
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Para finalizar revisaremos la configuración por si queremos cambiar algún parámetro.

#VMwarePorvExperts 73
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez creada la Biblioteca de contenido y dándole con el botón derecho sobre este, podremos
seleccionar varias opciones, tales como importar elemento, editar configuración, editar notas, cambiar
nombre, añadir etiquetas y eliminar.

Seleccionaremos importar elemento para empezar a cargar ISOS. Seleccionamos archivo local y le
damos a CARGAR ARCHIVO para subir nuestra primera ISO, si vemos conveniente podemos añadir
una descripción en el campo notas y finalizaremos dándole a importar.

#VMwarePorvExperts 74
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez subidas las ISOS que vayamos a utilizar, podremos usarlas para crear las máquinas virtuales.
Vamos a editar configuración y en Unidad de CD/DVD le diremos que añada la ISO desde Archivo ISO
de biblioteca de contenido.

Y Seleccionamos la ISO y aceptamos. Llegados hasta aquí ya será cuestión de crear una máquina
virtual, iniciar la VM con la ISO de Gparted para administrar discos y/o particiones o cualquiera de las
funciones que tengan el resto de ISOS de la Biblioteca.

#VMwarePorvExperts 75
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Otro de los usos que podemos dar a la biblioteca de contenido es la de almacenar plantillas clonando
una máquina virtual como plantilla de biblioteca. Botón derecho sobre la máquina virtual --- Clonar
como plantilla en biblioteca.

Comenzará el asistente donde la diremos la información básica, hay 2 tipos de plantilla.

• Plantilla de máquina Virtual

• Plantilla OVF

Estos 2 tipos de plantillas tienen sus pros y sus contras, pero actualmente la que mejores opciones da
es la Plantilla OVF, de lo que explicaré más adelante.

Seleccionamos OVF, ponemos un nombre a la plantilla y añadimos una descripción al campo notas.

#VMwarePorvExperts 76
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Creada la plantilla podemos desplegamos desde el clúster una nueva máquina virtual, botón derecho
Nueva máquina virtual.

Seleccionamos Implementar desde plantilla y siguiente.

#VMwarePorvExperts 77
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Al haber creado anteriormente la plantilla con formato OVF, nos aparecerá en la biblioteca de contenido
a la hora de seleccionar una plantilla, no así cuando la hacemos en formato de plantilla de máquina
virtual. Seguimos el proceso completando los pasos que nos pide el asistente hasta terminar.

#VMwarePorvExperts 78
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

También una de las diferencias entre una plantilla en formato OVF o plantilla de máquina virtual, es las
diferentes opciones que te da. Si nos fijamos las opciones que nos da con una plantilla de máquina
virtual son las de crear nueva máquina virtual desde plantilla, editar notas, cambiar nombre, etiquetas
y eliminar.

En cambio, una plantilla en formato OVF nos ofrece una mayor variedad de opciones, desde crear una
nueva máquina virtual hasta actualizarla, exportarla, Clonar, editar notas, cambiar nombre, etiquetas
y eliminar.

#VMwarePorvExperts 79
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

#VMwarePorvExperts 80
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

5. Update Manager

Update Manager es la herramienta que permite la administración centralizada y automatizada de


parches y versiones para VMware vSphere, donde ofrece soporte para hosts ESXi, máquinas virtuales
y virtual appliances.

Con VMware Update Manager, se pueden realizar las siguientes tareas:

• Actualizar y parchear los hosts ESXi.

• Instalar y actualizar software de terceros en los hosts.

• Actualizar las VMware Tools y el Hardware virtual de las máquinas virtuales y los virtual appliances.

Hay una serie de condiciones de Update Manager a tener en cuenta:

• Para que VMware Update Manager pueda funcionar es necesaria conectividad con VMware
vCenter Server.

• Cada instalación de Update Manager debe estar asociada y registrada con una única instancia de
vCenter Server.

• Puede usar Update Manager con vCenter Server que se ejecuta en Windows o con vCenter Server
Appliance

• El módulo de Update Manager consta de un componente de servidor y de un componente de


cliente.

• El Update Manager se incluye como un servicio en el vCenter Server Appliance

• En un servidor vCenter con Windows, el componente se puede instalar en el mismo servidor de


vCenter o en uno diferente.

5.1 Actualizar hosts ESXi con Update Manager


Pasaremos a la práctica actualizando los hosts ESXi con Update Manager. Si nos fijamos en la imagen
el host ESXi es la versión 6.7.0, 8169922 y la ISO que vamos a descargar es para la v6.7.0, 10302608.
La ISO descargaremos desde la Web de VMware con la cuenta que tengamos, y si no la tenemos, la
creamos.

NOTA: Un punto a tener en cuenta es que, dependiendo de la marca de servidor como HP, DELL …
tendremos que descargar la ISO personalizada de estos. Esto no quiere decir que no podamos hacer
la instalación con la ISO de VMware, pero lo recomendado es hacerlo con la ISO correspondiente del
fabricante si el modelo de hardware es muy reciente.

#VMwarePorvExperts 81
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

El método que vamos a utilizar es subiendo la ISO de VMware ESXi 6.7 Update 1 que hemos
descargado, para eso iremos a Menú --- Update Manager

Dentro de Update Manager vamos a imágenes ESXi --- Importar, seleccionamos la ISO de VMware
ESXi y una vez que le damos a importar, comenzará a subir la ISO.

#VMwarePorvExperts 82
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez que termina de subir podremos visualizarla y seguido crearemos una Nueva Línea Base

Comenzará el asistente de creación de nueva línea de Base, ponemos nombre y descripción.

En el campo contenido, nos marcará automáticamente el tipo de contenido, que es “Actualización”

#VMwarePorvExperts 83
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos la ISO que acabamos de subir y siguiente.

Comprobaremos que todo está correctamente y finalizar.

#VMwarePorvExperts 84
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Ahora asociaremos la línea de Base a los Host ESXi, podemos hacerlo también por Clúster, pero solo
para 2 host ESXi lo voy a hacer uno por uno.

Asociamos la línea de base al Host ESXi.

#VMwarePorvExperts 85
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Y le haremos clic en Corregir.

Aceptamos el Eula.

#VMwarePorvExperts 86
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Y confirmamos el proceso con “Corregir”.

Comenzará el proceso y veremos cómo va aplicando la actualización, el proceso funciona de esta


manera: hace vMotion de las VMs a otro host, pone el host en modo mantenimiento, aplicar la
actualización, reinicia y lo saca del modo mantenimiento.

#VMwarePorvExperts 87
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Finalizado el proceso de actualización, comprobaremos la versión del hypervisor ESXi en el panel de


la derecha.

Update Manager también nos permite el poder actualizar las VMware tools. Si nos dirigimos a
Actualizaciones --- VMware Tools, veremos el estado de las VMware Tools. Para rescan en qué estado
están, haremos clic en Examinar ahora.

#VMwarePorvExperts 88
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Terminado el rescan, podremos ver si tenemos alguna actualización disponible o si están instaladas o
no.

Podemos programar la actualización de las VMware Tools, o en su defecto decirle que las instale la
próxima vez que se encienda la Máquina Virtual.

Podemos hacer lo mismo con la actualización del Hardware de Máquina Virtual.

Dentro del menú, está la parte Hardware de máquina virtual, donde si le damos a examinar ahora, no
hará un rescan y nos dirá el estado del Hardware Virtual de las Máquinas Virtuales.

Haciendo clic en Actualizar para coincidir con el host es una de las diferentes maneras que podemos
actualizar el Hardware Virtual de una Máquina Virtual.

#VMwarePorvExperts 89
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos la máquina virtual a actualizar y le hacemos clic en Actualizar para coincidir con el host.

#VMwarePorvExperts 90
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

6. Actualización de vCSA 6.7

Desde que salió por primera vez el vCenter versión Linux appliance hemos podido comprobar lo fácil
que es actualizar sin tener que pasar por todo tipo de sufrimientos.

Existen 2 tipos de actualización:

• Descargando los parches desde un repositorio de VMware

• Descargando una iso con todos los parches acumulativos desde la web de VMware https://
my.vmware.com/group/vmware/patch#search

Recordar que estos procedimientos de actualización son para actualizar con parches de la misma
versión, es decir, solo podremos actualizar desde la primera versión de la 6.7 hasta la última de esta
misma. Por ejemplo, para actualizar de la reléase 6.5 a la 6.7 tendremos que hacer una Actualización
con la ISO de instalación.

6.1 Descargando los parches desde un repositorio de VMware


Por defecto la URL del repositorio está configurada, pero si por lo que sea no nos funciona se puede
modificar y poner una que si funcione.

Para eso vamos al menú de Actualizar y le damos a configurar

Podemos cambiar varios parámetros como:

• Buscar actualizaciones automáticamente.

• Usar el repositorio predeterminado

• Usar repositorio personalizado.

#VMwarePorvExperts 91
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Pero lo dejaremos con la configuración predeterminada del repositorio.

6.2 Descargando una ISO con todos los parches acumulativos desde la
web de VMware
Este es el segundo método, seleccionando la versión y descargamos la ISO con los parches desde la
web VMware https://my.vmware.com/group/vmware/patch#search. Una vez descargado mapeamos la
ISO en la VM de vCSA desde el vSphere Client.

Descargada y añadida la ISO a la VM de vCSA, en comprobar actualizaciones, seleccionaremos


“comprobar CD-ROM”. Más información:

https://aprendiendoavirtualizar.com/actualizar-vcsa-v6-7-desde-iso/

#VMwarePorvExperts 92
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Pero como vamos a utilizar el procedimiento más rápido, fácil y cómodo, seleccionamos comprobar
CD-ROM y URL, para que por defecto nos descargue e instale los últimos parches necesarios

Una vez que termina la búsqueda dependiendo del tiempo que lleve sin actualizar nos mostrará la
revisión actual y las anteriores. Al ser las actualizaciones acumulativas, bastará con que actualicemos
con la versión más actual.

#VMwarePorvExperts 93
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Iniciaremos el proceso de actualización dándole a “Realizar copias intermedias e instalar”

Aceptamos los términos de licencia de usuario final y siguiente.

#VMwarePorvExperts 94
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Lógicamente antes actualizar se supone que hemos hecho una copia de seguridad de la configuración
el vCSA, un Snapshot o una copia de seguridad de la VM con una aplicación de terceros.

#VMwarePorvExperts 95
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Comienza el proceso de actualización.

Finalizado el proceso, comprobamos viendo el Numero de compilación.

#VMwarePorvExperts 96
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

7. Backups programados de vCSA 6.7

Con la llegada de VMware vSphere 6.5, VMware incluyó la característica de poder realizar una Copia
de Seguridad de nuestro vCenter Server Appliance, más conocido como vCSA.

¿De qué datos podemos hacer Copia de Seguridad? Del inventario, la configuración y opcionalmente
las estadísticas y los eventos.

Con esta nueva característica, podemos hacer Copias de Seguridad programadas y/o Copias de
Seguridad aleatorios e independientes.

7.1 Copia de Seguridad programada


Para poder configurar las Copias de Seguridad programadas, vamos a “configurar”,

Se abrirá la ventana de configuración de Copia de Seguridad, donde rellenaremos los siguientes


campos:

• Ubicación de la copia: protocolo://ruta_de_destino

• Credenciales del servidor de Copia de Seguridad: usuario y contraseña

• Programación: periodicidad

• Cifrar copia de Seguridad (opcional): contraseña

• Cantidad de Copias de Seguridad que se conservaran: sin límite o “x” últimas copias

• Por último, de que datos hacer la copia, inventario y configuración que ya viene marcado por
defecto y como opcional, eventos y estadísticas

#VMwarePorvExperts 97
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez configurada la Copia de Seguridad Programada, nos mostrará la tarea en el panel y se
ejecutará según la programación configurada.

Una vez ejecutada y finalizada la copia de seguridad, el registro de esta tarea se verá en la ventana
de Actividad.

#VMwarePorvExperts 98
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

7.2 Copia de Seguridad Manual


Podemos hacer una copia de Seguridad esporádica, bastará con que pinchemos en “Realizar copia
de seguridad ahora”

y rellenemos los mismos campos que el Backups programado.

NOTA: La tarea de Copia de Seguridad no se queda guardada.

#VMwarePorvExperts 99
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

8. Usuarios, Roles y permisos en Host ESXi

En ESXi, podemos crear usuarios y asignarles Roles para otorgarles permisos a diversos objetos
como una máquina virtual o un Host ESXi. Los permisos dan a los usuarios el derecho de realizar
actividades específicas por el rol en el cual se le asigna el rol.

Si el host ESXi está administrado por un vCenter, no es recomendable crear y asignar roles y permisos
en el host ESXi, ya que se puede crear mucha confusión o conflictos con los administrados por el
vCenter, Esto sería más lógico para un host ESXi Standalone. Lo que sí es recomendable y buena
práctica, es crear otro usuario administrador como el de root para poder administrar el ESXi y no utilizar
este último.

Nos conectamos al Host ESXi a través del VMware Host Client https://ip_o_fqdn

Para crear un usuario local en el host ESXi vamos a administrar --- Seguridad y usuarios --- usuarios,
hacemos clic en agregar usuario.

#VMwarePorvExperts 100
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Le ponemos un nombre de usuario, una Descripción (opcional) y una contraseña.

Seguido vamos a Funciones y hacemos clic en Agregar función. Por defecto vienen ya varias funciones
o Roles creados por defecto y que no se pueden editar.

#VMwarePorvExperts 101
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Como yo quiero crear una Función más personalizada seleccionaré una serie de privilegios. Cuando
nos aparecen los privilegios, seleccionaremos el que nos interese, por ejemplo, seleccionaré el de
VirtualMachine.

Al hacer clic sobre ese privilegio, nos aparecerán otros, selecciono el de State, y dentro del privilegio
State, están los privilegios sobre Snapshots. Selecciono el de crear Snapshot y el de remover Snapshot.
Le ponemos un nombre a la función creada.

#VMwarePorvExperts 102
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez creado el usuario y la función, vamos a dar permisos al objeto, en este caso es el Host ESXi,
botón derecho sobre el ESXi --- permisos.

Hacemos clic sobre Administrar permisos y desde los desplegables seleccionamos el usuario y la
función creada y hacemos clic en Agregar usuario.

#VMwarePorvExperts 103
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Entramos al ESXi con el nuevo usuario creado y veremos como no tenemos la opción de reiniciar o
apagar la VM.

#VMwarePorvExperts 104
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

En cambio, nos dejará crear un Snapshot, pero no nos dejará revertirlo, tal como le hemos indicado al
crear la nueva función.

#VMwarePorvExperts 105
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

9. Poner un host ESXi en modo mantenimiento, reinicio


y apagado

Un host se pone en modo de mantenimiento cuando se deben realizar tareas de mantenimiento en


él, por ejemplo, para cambiar una controladora, disco … El host entra en este modo o sale de él solo
mediante la solicitud del administrador y de modo manual, el objetivo del modo mantenimiento es el de
un apagado ordenado. El modo mantenimiento también se utiliza en VMware Update Manager, pero
de modo automático.

Las máquinas virtuales que se están ejecutando en un host ESXi y que va a entrar en modo mantenimiento
deberán migrarse a otro host manualmente o si tienes DRS automáticamente. El Host ESXi se quedará
entrando en modo mantenimiento mientras no se hayan migrado las máquinas virtuales a otro host
ESXi o en caso de haber un solo host ESXi hasta que se apaguen las máquinas virtuales. Tampoco se
podrán migrar Máquinas virtuales a este Host ESXi, ni se podrán encender.

9.1 Poner Host ESXi en modo mantenimiento


Vamos a verlo mejor en la práctica. Para poder poner un Host ESXi en modo mantenimiento clic con el
botón derecho sobre el host --- modo mantenimiento --- Entrar en modo mantenimiento.

Nos avisará que el modo manteamiento no finaliza hasta que todas las VMs que están encendidas se
migren a otro host o se apaguen, aceptamos.

#VMwarePorvExperts 106
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Al aceptar ya nos muestra una advertencia y nos dice bien claro que hay una o más máquinas virtuales
encendidas en los hosts y que no continuará hasta que se migre o se apague. Aceptamos para continuar.

Si nos fijamos en la imagen, ha entrado en modo mantenimiento, pero la barra de progreso se queda
en un 2%, además, si intentamos encender una de las VMs apagadas, no nos dará la opción.

#VMwarePorvExperts 107
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Así que necesitaremos apagar o migrar la VMs para que el modo mantenimiento pueda continuar.

Una vez apagada la VM, el modo mantenimiento continua, por lo que ya podemos reiniciar o apagar
el Host ordenadamente.

#VMwarePorvExperts 108
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Para apagar o reiniciar es necesario poner un motivo o escribir algo.

#VMwarePorvExperts 109
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

10. Servicios y Firewall de Host ESXi

10.1 Servicios
En un Host ESXi existen una serie de servicios predeterminados, algunos, por defecto vienen iniciados
y otros parados, podemos cambiar el estado de estos servicios según necesidad, pero con mucho
cuidado ya que pueden afectar a la seguridad del host, no habilitar un servicio a no ser que sea
realmente necesario.

En una instalación predeterminada vienen instalados los servicios de la siguiente imagen. Podemos
añadir más instalando un .vib, que es un paquete de software que se instala en un Host ESXi, entre
otras cosa contiene drivers, firmwares…

Servicios predeterminados

Los servicios de un Host ESXi se pueden modificar desde el VMware host Client o desde el vSphere
Client HTML5. Si queremos iniciar o parar un servicio como por ejemplo el de SSH, haremos clic con
el botón derecho sobre este y detener.

#VMwarePorvExperts 110
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Automáticamente si estamos conectados a una sesión SSH, esta sesión se parará o si queremos
iniciar una nueva, nos rechazará la conexión.

10.2 Firewall
Desde el VMware Host Client también podemos configurar las reglas del Firewall, nos permite abrir
y cerrar puertos para cada servicio o como por ejemplo admitir la conexión SSH desde ciertas IPs.
Además de poder configurar vía web, podemos configurar las reglas del Firewall desde la línea de
comandos con ESXCLI.

Para configurar el Firewall, vamos a Reglas de Firewall --- Redes, nos mostrará todas las reglas
disponibles.

#VMwarePorvExperts 111
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Si queremos editar la regla del Firewall Servidor SSH, haremos clic sobre ella y editar configuración,
en la ventana de configuración, seleccionaremos la opción de “Solo permitir conexiones de las redes
siguientes” y le pondremos una IP, un rango de red, IPv4 o IPv6.

Si estamos conectados al Host ESXi con una sesión SSH y le cambiamos la regla del Firewall para que
solo se pueda conectar de otra con diferente rango.

#VMwarePorvExperts 112
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Automáticamente nos tirará de la sesión.

Configurar el Firewall y los servicios, también lo podemos hacer desde la interfaz vSphere Client
HTML5.

#VMwarePorvExperts 113
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

11. Archivos y componentes de una Máquina Virtual

11.1 Archivos de una máquina virtual


Una máquina virtual es un software que simula el hardware un equipo físico, está compuesta por un
conjunto de archivos de configuración y tienen una serie de dispositivos virtuales que funcionan como
los de un equipo físico.

Una máquina virtual se compone de varios archivos, entre los más importantes está el de configuración
(vmx), el de disco virtual (-flat.vmdk), el de configuración de NVRAM (nvram) y el de registro (log)

• .vmx Archivo de configuración de la máquina virtual

• .vmxf Archivo de configuración de la máquina virtual adicional

• .vmdk Archivo de características del disco virtual

• -flat.vmdk Archivo de datos del disco virtual

• .nvram Archivo de configuración de la BIOS o EFI de la máquina virtual

• .vmsd Archivo de Snapshot de la máquina virtual.

• .vmsn Archivo de datos de Snapshot de la máquina virtual

• .vswp Archivo de intercambio de la máquina virtual

• .vmss Archivo de suspensión de la máquina virtual

• .log Archivos de registro de la máquina virtual.

• .vmtx Archivo de plantilla, reemplaza el archivo .vmx al convertir la Máquina virtual


en plantilla.

Ejemplo de composición de una máquina virtual desde la shell.

#VMwarePorvExperts 114
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Vista desde vSphere Client.

11.2 Componentes de una máquina virtual


Las máquinas virtuales disponen de un sistema operativo, las VMware Tools que se instalan como
un componente casi imprescindible, recursos virtuales y Hardware virtual. Estos componentes se
administran del mismo modo que los de un equipo físico.

Sistema operativo: un sistema operativo invitado que se instala igual que un equipo físico, puede ser
Windows, Linux….

VMware Tools: VMware Tools es un conjunto de utilidades que mejora el rendimiento y la administración
del sistema operativo invitado de la máquina virtual. Incluye los controladores de dispositivos y otro
software que es esencial para la máquina virtual.

#VMwarePorvExperts 115
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Dispositivos de Hardware: como en un equipo físico, los dispositivos de hardware como CPU, RAM,
Disco… de una máquina virtual cumplen la misma función. Podemos añadir o quitar según necesidades.

#VMwarePorvExperts 116
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Hardware virtual: Al crear o actualizar una máquina virtual existente, se usa la funcionalidad de
compatibilidad de máquinas virtuales para seleccionar las versiones de host ESXi en las que puede
ejecutarse la máquina virtual. La configuración de compatibilidad determina el hardware virtual
disponible para la máquina virtual, que corresponde al Hardware físico disponible en el host. El
Hardware virtual incluye BIOS y EFI, las ranuras de PCI virtuales disponibles, la cantidad máxima de
CPU, la configuración máxima de memoria y otras características.

#VMwarePorvExperts 117
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

12. Administrar Máquinas Virtuales

12.1 Creación de una Máquina Virtual


Hay muchas maneras de crear una máquina virtual, pero la más conocida y fácil de implementar es a
través del asistente de nueva máquina virtual. Este asistente lo podemos iniciar haciendo clic con el
botón derecho desde la parte Clúster, desde un Host ESXi, desde el DataCenter, carpeta etc etc.

En tipo de creación seleccionaremos Crear una nueva máquina virtual, siguiente.

#VMwarePorvExperts 118
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

En nombre y carpeta escribiremos un nombre único para la máquina virtual y seleccionaremos una
carpeta como ubicación.

#VMwarePorvExperts 119
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionaremos el recurso informático, en este caso un host ESXi, si tenemos configurado DRS,
el mismo nos seleccionará el ESXi que mejor este de recursos. Si hubiese algún problema de
compatibilidad nos mostraría una alerta en el panel inferior.

#VMwarePorvExperts 120
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos el almacenamiento, lo mismo que en el paso anterior, Si hubiese algún problema de


compatibilidad nos mostraría una alerta en el panel inferior.

En seleccionar compatibilidad seleccionamos la última, ya que todos nuestros ESXi son ESXi 6.7 y
superior. De tener en vuestro DataCenter algún ESXi con una versión inferior, no la creéis con una
versión superior que pueda luego daros problemas hacer pasarlo a un host ESXi con versión inferior.

#VMwarePorvExperts 121
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos la familia del sistema operativo invitado (Linux) y la versión del sistema operativo
invitado (CentOS 7 – 64 bits). Es importante seleccionar correctamente el sistema operativo invitado ya
que influye en los dispositivos compatibles, al seleccionar un sistema operativo invitado, se selecciona
la BIOS o EFI de forma predeterminada, según el firmware que admita el sistema operativo.

Al seleccionar la familia y versión del sistema operativo nos deja unos valores por defecto acordes
al seleccionado, pero si queremos cambiar algún parámetro como por ejemplo el disco o la RAM
podemos hacerlo en este paso o una vez finalizado el asistente. También podemos añadir la ISO de
instalación del sistema operativo.

#VMwarePorvExperts 122
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Al final del asistente siempre queda el paso del resumen de todos los pasos del asistente, que viene
muy bien para repasar y cambiar algo que hayas podido hacer mal en algún paso.

Finalizada la creación de la Máquina virtual podemos iniciarla, pero yo recomiendo utilizar la Remote
Console, ya que funciona muy bien y te deja editar las opciones de la Máquina Virtual.

#VMwarePorvExperts 123
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Se abrirá la Remote Console y haremos clic en el triángulo verde para iniciar la máquina virtual.

Como hemos tenemos la ISO montada comenzara la instalación del sistema operativo invitado.

#VMwarePorvExperts 124
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una vez terminada la instalación del sistema operativo invitado, nos quedará instalar las VMware Tools
para su correcto funcionamiento. Si no lo instaláis os lo recordará con un aviso de color amarillo.

En las máquinas virtuales con sistemas operativos Linux, VMware recomienda que usemos e instalemos
las open-vm-tools en vez de las suyas nativas. Para instalar las open-vm-tools, nos conectamos por un
cliente SSH o directamente desde la Remote Console e instalamos con yum install open-vm-tools, si
es en Ubuntu o derivados utilizaremos apt-get.

Una vez instaladas las VMware Tools, el warning desaparecerá y comprobaremos que estén
funcionando correctamente.

#VMwarePorvExperts 125
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

En el siguiente en enlace podemos ver cómo crear una Máquina Virtual y optimizarla al máximo.

https://www.jorgedelacruz.es/2014/05/06/crear-una-vm-y-optimizarla-al-maximo/

12.2 Clonar una Máquina Virtual Existente


Cuando clonamos una Máquina virtual lo que hacemos es una copia exacta de la VM original, la nueva
VM tendrá el mismo software instalado, mismo hardware virtual y misma configuración internamente
en el sistema operativo invitado.

Normalmente hacemos un clon cuando queremos hacer una serie pruebas y no queremos o podemos
utilizar la VM original, por posibles tiempos de parada o simplemente por no romperla.

Para crear un clon hacemos clic derecho sobre la VM que queremos clonar --- Clonar --- Clonar a
Máquina Virtual.

Comienza el asistente y seleccionamos la ubicación y el nombre de la VM. Un dato a tener en cuenta


es que el nombre que le pongamos influirá en el nombre de la carpeta y los archivos de la Máquina
virtual.

#VMwarePorvExperts 126
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos el recurso informático que son el o los Host ESXi, también podemos seleccionar el
Clúster si tenemos DRS activado, el mismo nos ubicará la VM en cualquiera de los Host ESXi.

#VMwarePorvExperts 127
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Seleccionamos el almacenamiento, un Datastore con espacio suficiente. En la opción de configurar


por disco, podemos cambiar el formato de disco de thin a thick y viceversa.

En las opciones de clonación podemos personalizar el sistema operativo, personalizar el Hardware


virtual o encender la Máquina Virtual tras la creación, esta última no es recomendable que podría crear
conflictos con la VM original.

#VMwarePorvExperts 128
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Resumen por si queremos echar el último vistazo y finalizamos

En el inventario veremos la nueva Máquina Virtual creada.

12.3 Clonar Máquina Virtual a Plantilla


Una Máquina Virtual la podemos clonar para hacer una plantilla. Las plantillas son copias maestras de
las máquinas virtuales y las podemos utilizar para desplegar muevas Máquinas Virtuales, las plantillas
nos pueden ahorrar mucho trabajo. Algo muy común es, crear una VM desde la plantilla, instalar o
actualizar el software que tenga y volver a clonar esa VM a plantilla, de esta manera podemos guardar
versiones de plantillas.

Clic derecho sobre la VM que queremos clonar ---- Clonar a plantilla.

#VMwarePorvExperts 129
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

El asistente de Clonar a plantilla no varía mucho respecto al de Clonar Máquina Virtual, lo único que
no tiene es el paso de seleccionar recurso informático.

También está la Opción de Clonar como plantilla de biblioteca de contenido, pero esto ya lo expliqué
en el Capítulo “Biblioteca de Contenido”

Una vez finalizado iremos a Máquinas Virtuales y plantillas del inventario y veremos la nueva plantilla
creada.

#VMwarePorvExperts 130
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

12.4 Nueva Máquina Virtual desde esta Plantilla


El crear una nueva máquina virtual desde una plantilla, es crear una Máquina Virtual igual que la
plantilla, donde el software, hardware virtual y demás que se configuraron en el momento de crear la
plantilla serán los mismos.

Desde Máquinas Virtuales y plantillas, clic derecho sobre la plantilla --- Nueva máquina Virtual desde
esta plantilla

Igual que los demás procedimientos y sin variar mucho, Nombre de la Máquina Virtual y ubicación,
selección de recurso informático, selección de almacenamiento y finalizar.

#VMwarePorvExperts 131
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

12.5 Clonar Plantilla a Plantilla


También está la opción de Clonar una plantilla en otra plantilla, quizá nos interese tener una plantilla
maestra y las demás para nuestras pruebas.

El procedimiento igual que los demás, clic derecho sobre la plantilla --- Clonar a plantilla.

El asistente igual, nombre y ubicación, recurso informático y almacenamiento. Ya tenemos la plantilla


clonada.

#VMwarePorvExperts 132
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

12.6 Convertir Plantilla en Máquina Virtual


Esta la opción de convertir en Máquina virtual una plantilla, clic derecho sobre la plantilla --- Convertir
en Máquina Virtual.

En el asistente a lo único que nos da opción es a cambiar el recurso informático, que el almacenamiento,
nombre y ubicación, son los mismos que tenía cuando era plantilla.

#VMwarePorvExperts 133
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

13. Crear, eliminar, restaurar y administrar Snapshots

13.1 Que es un Snapshot


Un Snapshot es una llamémosle “foto” que conserva el estado y los datos de la Máquina Virtual en el
momento que crea el Snapshot. Los Snapshots son muy útiles cuando necesitas volver a un estado
anterior, por ejemplo, cuando quieres aplicar un parche de Windows y no sabes cómo le va a afectar,
lo correcto y recomendado es hacer un Snapshot y aplicar el parche, de esta forma, si falla en unos
segundos podemos volver atrás a un punto que la máquina virtual funcionaba correctamente.

Hay que dejar muy claro, que un Snapshot no es un Backup y que es solo útil a corto plazo, imaginar
lo que se perdería de datos revirtiendo un Snapshot un mes atrás, esto lo comento por hay gente que
todavía lo piensa. Además, VMware, recomienda no tener un Snapshot 24/48 horas, tener en cuenta
que un Snapshot puede crecer mucho en este tiempo dependiendo del tipo de operaciones que esté
haciendo internamente el Sistema operativo invitado.

13.2 Limitaciones y recomendaciones de las Snapshots


• Los Snapshot no son Backups, si la Máquina virtual se corrompe a nivel de los archivos que la
componen (vmdk, vmx...) los Snapshots que tenga no te valdrán para nada.

• No se pueden hacer Snapshots de discos RDM físicos y Sistemas operativos que tengan un disco
a través de un iniciador iSCSI

• No se puede hacer Snapshots de discos independientes.

• Los dispositivos PCI de vSphere DirectPath I/O no son compatibles con los Snapshots.

• VMware solo permite 32 Snapshots por máquina virtual. A más Snapshots concurrentes más
escrituras en disco simultaneas por cada byte que escribas en la máquina virtual, esto puede
ralentizar muchísimo la máquina virtual y añadir mucha carga extra a las cabinas o disco de
almacenamiento, lo que afectaría al resto de máquinas virtuales.

13.3 Crear un Snapshot


Crear un Snapshot no tiene ningún misterio, pero en algún momento sí que puede afectar el proceso de
creación o borrado del Snapshot a la Máquina Virtual “congelando” durante algún segundo el sistema
operativo invitado.

Seleccionamos la Máquina Virtual de la que queremos hacer el Snapshot, clic derecho ---- Snapshots
---- Crear Snapshot.

#VMwarePorvExperts 134
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Le ponemos nombre y una descripción (opcional, pero muy recomendado).

Podemos seleccionar una de las 2 opciones o ninguna,

Snapshots creados con memoria

Viene marcada por defecto y cuando comienza el proceso de creación del Snapshot, captura el estado
de la memoria de la Máquina Virtual en un momento preciso.

Snapshots en modo inactivo

Las VMware Tools ponen en modo inactivo al sistema de ficheros de la Máquina Virtual. Ponerlo
en modo inactivo se garantiza que el disco de la Snapshot se quede en un estado coherente de los
sistemas de ficheros invitados.

Sin marcar ninguna de las opciones

El proceso de creación del Snapshot es mucho más rápido, pero al revertir el Snapshot, nos
encontraremos con el estado de la máquina virtual apagada.

#VMwarePorvExperts 135
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

13.4 Archivos de los Snapshots.


Cuando creas un Snapshot te genera una serie ficheros dentro de la carpeta de la Máquina Virtual.

Archivos de base de datos

Es el archivo con extensión. vmsd, que contiene la información del Snapshot, el archivo contiene las
relaciones entre los Snapshots y los discos secundarios de los Snapshots.

Archivo de memoria

Es el archivo con extensión .vmsn que incluye el estado activo de la máquina virtual, y pertenece a
los Snapshots creadas con memoria, permite revertir el Snapshot a un estado con la máquina virtual
encendida. Se genera un fichero vmsn cada vez que se crea un Snapshot.

Archivos de disco delta

El disco delta es la diferencia entre el estado actual del disco virtual VMDK y el estado que tenía en el
momento de crear el Snapshot, cuando se crea el Snapshot el sistema operativo deja de escribir datos
en él y crea el disco delta para continuar escribiendo los datos en él, el fichero tiene una extensión
vmdk, que para diferenciarlo del primario utiliza la siguiente sintaxis vm_name-000001.vmdk.

13.5 Restaurar Snapshots


Cuando se restaura un Snapshot, la memoria de la máquina virtual, los discos, configuración … vuelven
al estado en el que se encontraba en el momento que se hizo la Snapshot, se perderían los datos entre
el estado actual y el momento de la creación del Snapshot

Desde el administrador de Snapshots podemos ver toda la jerarquía de Snapshots para ver a cuál nos
interesa revertir. Es muy importante poner un nombre y una descripción cuando creamos el Snapshot,
el poner test1, test2 , prueba3 y todos estos nombres pueden llevarnos a confusión y a ejecutar una
restauración errónea.

#VMwarePorvExperts 136
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Podemos revertir el Snapshot directamente desde la Máquina virtual, clic derecho --- Revertir al último
Snapshot, restauraría un nivel hacia arriba desde la posición Usted está aquí. Si nos fijamos en la
imagen anterior iríamos al Snapshot llamado “cambio de credenciales”.

Con la opción Revertir A dentro del administrador de Snapshots podemos seleccionar cualquiera de
los Snapshots de la jerarquía.

Vamos a probar, seleccionamos la Snapshot y revertir A

#VMwarePorvExperts 137
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Se ha hecho un viaje en el tiempo y nos hemos ido al momento de la creación del primer Snapshot.

Ahora realizaremos otro Snapshot desde el punto en el que nos encontramos.

Al crear un nuevo Snapshot a partir del primer punto al que hemos revertido, nos generará una nueva
rama del árbol de Snapshots.

#VMwarePorvExperts 138
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

13.6 Eliminar Snapshots


Al eliminar una o todos los Snapshots, estas se quitan del Administrador de Snapshots. Los archivos
del Snapshot se consolidan y escriben en el disco de Snapshot primario, seguido, se combinan con el
disco base de la máquina virtual.

Atención al eliminar un Snapshot que lleve mucho tiempo y que hay crecido bastante, puede que en el
momento de eliminar el Snapshot y consolidar los discos, el sistema operativo invitado se pueda ver
afectado en lo que a rendimiento se refiere.

Podemos eliminar los Snapshots de uno en uno o todas de golpe, con las opciones de Eliminar.

#VMwarePorvExperts 139
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Y Eliminar todo.

13.7 Consolidar Snapshots


El consolidar Snapshots lo que hacer es buscar los discos delta de la Máquina virtual y combinarlos sin
perder la dependencia de datos.

Si nos fijamos en los eventos, cuando eliminamos los Snapshots, comienza un proceso de consolidación
de discos.

Este proceso puede que en alguna ocasión no funcione correctamente y al eliminar los Snapshots
nos deje algún disco delta sin combinar. Cuando ocurre esto, en el vCenter puede que nos aparezca
un warning avisándonos que los discos necesitan consolidación. Cuando nos ocurra esto tenemos la
opción de consolidar manualmente.

#VMwarePorvExperts 140
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Clic derecho sobre la Máquina Virtual --- Snapshots --- Consolidar.

Si esto no funciona, sería cuestión de investigar un poco más a fondo y probar otras vías para
solucionarlo.

#VMwarePorvExperts 141
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

14. VMware Remote Console y consola Web

Desde el vSphere Client y el VMware Host Client podemos acceder a las Máquinas Virtuales mediante
una serie de consolas.

14.1 Consola Web


La consola Web con todos los respetos, no vale prácticamente para nada, quizá para hacer login si
tienes un password sin símbolos, ya que el teclado español no está disponible e intentar introducir un
password pude ser un dolor.

14.2 VMware Remote Console


La Remote Console es una consola que funciona de maravilla. Es una aplicación independiente que
tenemos que descargar e instalar. Con esta consola podemos instalar el sistema operativo invitado,

#VMwarePorvExperts 142
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

configurar el hardware virtual…

Para instalar la Remote Console, hacemos clic sobre la admiración que está a la derecha de “iniciar
Remote Console”, y en el bocadillo, le damos a descargar.

Nos redirigirá a la web de VMware, donde necesitaremos una cuenta activa en VMware para descargarlo.

Una vez descargada, la instalamos, siguiente, siguiente.

Una vez instalada, la ejecutamos, desde la consola podemos actualizar o instalar las VMware tools,
mapear ISOS, reiniciar etc

#VMwarePorvExperts 143
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Una opción interesante es la de poder conectar una ISO desde el cliente del que nos conectamos a la
consola, de esta manera evitar subir ISOS al Datastore o a la Biblioteca de contenido.

#VMwarePorvExperts 144
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

Desde el menú donde está el nombre de usuario con el que hemos hecho login, podemos cambiar la
preferencia de la consola de la Máquina Virtual. Hacemos clic en Change VM Console Preference.

Y nos saltará la ventana de configuración de preferencia de consola, no hace falta que repita que
utilicéis la VMware Remote Console.

#VMwarePorvExperts 145
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

También podemos usar la Consola Web y la Remote console desde VMware host Client del ESXi.

#VMwarePorvExperts 146
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo

#VMwarePorvExperts 147
Patrocinadores

GOLD

SILVER

BRONZE

#VMwarePorvExperts 148
Capítulo 3
Instalación, Configuración y
Actualización

Xavier Caballé

#VMwarePorvExperts 149
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Instalación, Configuración y Actualización


Bienvenidos al capítulo de instalación, configuración y actualización de un entorno de virtualización de
VMware.

En este capítulo encontrareis toda la información necesaria para poder realizar una instalación básica
de un entorno de virtualización basado en tecnologías VMware.

El entorno más básico que nos permitirá aprovechar todas las ventajas que nos proporciona la
virtualización sistemas operativos usando VMware como por ejemplo él VMware High Availability,
deberá estar formado por un mínimo de dos servidores físicos y un servidor de vCenter.

El servidor de vCenter de nuestro entorno, puede ser desplegado en dos formatos distintos. En forma
de máquina virtual, ya sea usando un equipo Microsoft Windows o directamente un servidor virtual
Appliance, o podemos utilizar un servidor físico que tenga un sistema operativo Windows instalado.

Veremos paso a paso como desplegar nuestro entorno y configurar la información básica de cada uno
de los sistemas que lo componen, como puede ser, Nombres, direcciones IP, DNS, etc..

#VMwarePorvExperts 150
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

1. Consideraciones previas a la instalación o actualización


de un host

Antes de empezar la instalación o actualización de un servidor host de VMware es de obligado


cumplimiento comprobar que el hardware de nuestro servidor físico es 100% compatible con la nueva
versión de VMware vSphere que pretendemos desplegar.

Si nuestro entorno ya dispone de otros servidores host en producción, también es una buena práctica
comprobar que la nueva versión de VMware que desplegaremos en el nuevo servidor, sea actualizable
a todos host que actualmente se encuentran productivos en nuestro entorno.

También, tenemos que verificar que todos los host son compatibles entre sí con alguno de los modos
de Enhaced vMotion Capability (EVC). Si no pudiéramos configurar EVC por incompatibilidad de
alguno de los servidores, sería imposible usar vMotion.

Usando Enhanced vMotion Compatibility, eliminaremos todos los problemas de compatibilidad


que pueda haber entre las CPU de nuestros servidores que pertenezcan a distintas generaciones de
procesador, cuando usamos la tecnología vMotion.

EVC configurará de forma automática los distintos procesadores de nuestros servidores host usando
las tecnologías Intel FlexMigration o AMD-V Extended Migration, dependiendo de cada fabricante,
para que estas sean compatibles entre sí.

Después de activar EVC en un clúster de vCenter Server, todos los hosts que lo componen estarán
configurados para presentar idénticas características de procesador, de este modo, lograremos
garantizar la compatibilidad entre las distintas CPU de nuestros host cuando usamos vMotion.

Para realizar las comprobaciones, usaremos la herramienta VMware Matrix Compatibility Guide.
Podéis ver unos ejemplos de uso en los enlaces que mostramos a continuación.

#VMwarePorvExperts 151
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

VMware EVC: Entornos que tienen servidores con distintos modelos de CPU.

https://www.pantallazos.es/2016/10/vmware-evc-entornos-con-distintos-cpu.html

VMware Enhanced vMotion Compatibility: Activar EVC.

https://www.pantallazos.es/2017/02/VMware-Enhanced-vMotion-Compatibility-Activar-EVC.html

#VMwarePorvExperts 152
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

2. Instalar un nuevo servidor host

El proceso de instalación de un nuevo servidor ESXi, no varía mucho en cualquiera de las versiones
de VMware vSphere que pretendamos instalar, de hecho podríamos decir que es exactamente igual.

Para instalar un nuevo servidor host, en primer lugar, deberemos descargar la imagen ISO del producto
de la página oficial de VMware.

En la página de descargas de VMware encontraremos disponibles imágenes personalizadas para


servidores de marcas como pueden ser HP, Lenovo, Fujitsu, CISCO y Hitachi.

Otros fabricantes como DELL, por ejemplo, nos ofrecerán sus imágenes de instalación personalizadas
directamente desde su propia página web oficial.

Una vez descargado el archivo ISO que corresponda a la versión del producto que queremos instalar
tendremos que montar la imagen en nuestro servidor, ya sea pasándola a un soporte USB o CD y
usando el soporte que hayamos elegido directamente en nuestro servidor o, otra posibilidad sería
usar la tarjeta ILO de HP o la iDRAC de DELL por ejemplo, para montar la imagen ISO del sistema
operativo hypervisor directamente a nuestro hardware.

Una vez montado el soporte de instalación de VMware, arrancaremos desde la imagen y aparecerá
el Boot Menú del instalador, seleccionaremos la primera opción mostrará la versión del producto que
hemos elegido instalar terminará con la palabra Installer.

Hecho esto, empezará el proceso de carga de la instalación del producto, en nuestro laboratorio
instalaremos la versión 6.7.0. 

En primer lugar, nos aparecerá la pantalla de bienvenida del asistente de instalación.

Pulsaremos la tecla Enter del teclado conectado al servidor para continuar con el asistente de

#VMwarePorvExperts 153
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

instalación del producto, y seguidamente, deberemos aceptar la End User License Agreement o
EULA pulsando la tecla F11.

Seguidamente entraremos en materia, el asistente nos pedirá que seleccionemos el dispositivo de


disco en el que deseamos instalar nuestro sistema operativo.

En nuestro laboratorio de ejemplo disponemos de un volumen de disco de 40 GB para poder realizar


la instalación, lo seleccionaremos y presionaremos una vez más la tecla Enter.

Hemos de prestar la máxima atención a este punto si tuviéramos un volumen SAN conectado a nuestro
host o si servidor dispone de algún otro volumen de disco local además del destinado a la instalación
del hypervisor. Si no seleccionamos el volumen de disco correcto destinado a la instalación, podríamos
tener perdida de datos.

Seguidamente, el asistente de instalación del producto nos hará definir el idioma de nuestro teclado.
Escogeremos el que más se adecue a nuestras necesidades y presionaremos Enter para continuar.

#VMwarePorvExperts 154
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Terminaremos la configuración del instalador, asignando una contraseña segura al nuevo usuario Root
de nuestro nuevo servidor VMware vSphere.

ESXi aplicará por defecto los requisitos de contraseña para el acceso desde la interfaz de usuario de
la consola directa, ESXi Shell, SSH o VMware host client.

Cuando creemos la nueva contraseña deberemos incluir una combinación de como mínimo tres de las
cuatro clases distintas de caracteres que mostramos a continuación:

• Letras en minúscula.

• Letras en mayúscula.

• Números.

• Caracteres especiales (como por ejemplo el guion bajo (_), el guion (-), el asterisco (*),
símbolo más (+))

De forma predeterminada, la longitud de la contraseña debe tener más de 7 caracteres y menos de 40.

Las contraseñas no pueden contener una palabra de diccionario o parte de una palabra de diccionario.

#VMwarePorvExperts 155
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Una vez tengamos configuradas todas las opciones, para proceder con la instalación del nuevo
producto, deberemos confirmar pulsando la tecla F11 de nuestro teclado.

Una vez hayamos presionado la tecla F11 en nuestro teclado, el asistente lanzará automáticamente la
instalación. Deberemos esperar pacientemente a su culminación, al terminar el proceso de instalación,
aparecerá una nueva ventana donde se nos informará del éxito de la nueva instalación, y también, de
la necesidad de reiniciar el nuevo host VMware vSphere ESXi. Presionaremos por última vez la tecla
Enter para reiniciar el servidor.

#VMwarePorvExperts 156
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Arrancaremos por primera vez nuestro host ESXi y podremos comenzar con las tareas de configuración
del nuevo servidor.

VIDEO - VMware ESXi 6.7.0: Instalar un nuevo servidor host.

https://www.youtube.com/watch?v=P9su4iSv7mU

VMware ESXi 6.7.0: Instalar un nuevo servidor host.

https://www.pantallazos.es/2019/01/vmware-esxi-6-instalar-host.html

#VMwarePorvExperts 157
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

3. Configurar Management Network

Adaptadores de red.

Una vez tengamos instalado el nuevo sistema operativo hypervisor en el hardware que hayamos
escogido, el paso siguiente será la configuración básica del producto. A continuación, vamos a
configurar algunas opciones de la Management Network en el nuevo servidor host VMware ESXi.

La red de administración o Management Network es la red que usaremos para gestionar nuestros
host. La usaremos para conectar a los servidores de VMware vCenter o para gestionar directamente
los servidores host ESXi. Al designar una red de administración específica, podremos aislar las
conexiones a los recursos de vSphere de la red pública.

A continuación veremos cómo usar el menú System Customization (Modo texto) de nuestro host,
para agregar varios adaptadores de red a nuestra Management Network y así conseguir redundar la
red de administración del servidor host.

Todos los menús que encontrareis a continuación pertenecen a la versión 6.5.0 de VMware vSphere
ESXi pero son prácticamente iguales para todas las versiones disponibles del producto.

Cuando iniciamos un servidor VMware ESXi vSphere, la pantalla de la consola que tengamos
conectada físicamente a nuestro servidor host nos mostrará la imagen que tenemos a continuación.

En ella aparecerá información básica del sistema como pude ser, la versión de VMware ESXi y release
del vmKernel que tenemos instalados, la CPU física instalada en nuestro host, la memoria RAM física
disponible o parámetros de configuración de red configurados.

Para empezar la configuración, pulsaremos la tecla F2 de nuestro teclado. De este modo, accederemos
a la opción llamada <F2> Customize System/View Logs.

Nos aparecerá una ventana emergente, donde nos solicitará las credenciales de acceso a nuestro
servidor. Introduciremos las credenciales de acceso de nuestro usuario root y, seguidamente,
pulsaremos la tecla Enter.

#VMwarePorvExperts 158
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En el menú de la pantalla System Customitzation, usaremos las flechas del teclado conectado a
nuestro servidor host para descender a la opción del menú lateral llamada, Configure Management
Network.

El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de configuración
de la red de administración (Management Network).

Para configurar los adaptadores físicos asignados a la red de administración, seleccionaremos la


primera de las opciones de menú de la sección Configure Management Network, llamada Network
Adapters.

Aparecerá una pequeña ventana emergente, donde podremos seleccionar usando el teclado conectado
a nuestro servidor, los adaptadores que formarán parte del grupo de Management Network.

De este modo, podremos redundar la conexión de administración de nuestros servidores.

Finalizada la configuración, pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de los adaptadores de red.

#VMwarePorvExperts 159
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

VMware 6.5.0: Configure Management Network - Adaptadores de red.

https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-adaptadores-red.html

#VMwarePorvExperts 160
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

4. Configuración IPv4

A continuación tendremos que configurar la dirección IPv4 de nuestro nuevo servidor host VMware
vSphere ESXi.

En este apartado veremos cómo usar el menú Customize System (Modo texto) de nuestro host para
configurar opciones como IP, mascara de red y puerta de enlace, en el grupo de tarjetas de red que
componen la Management Network.

En la pantalla System Customitzation usaremos de las flechas de nuestro teclado para descender a
la opción del menú lateral llamada Configure Management Network.

El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de Configuración
de la red de administración (Management Network).

Para configurar de dirección IPv4 asignada a la red de administración, seleccionaremos la tercera de


las opciones del menú que aparecerá en la sección Configure Management Network, llamada IPv4
Configuration.

Aparecerá una pequeña ventana emergente llamada IPv4 Configuration, donde podremos configurar
todas las opciones de red de nuestra tarjeta de red.

• Dirección IPv4.

• Mascara de subred.

• Puerta de enlace.

Finalizada la configuración pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de la IPv4 de los adaptadores de red.

#VMwarePorvExperts 161
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

VMware 6.5.0: Configure Management Network - Configuración IPv4.

https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-ipv4.html

#VMwarePorvExperts 162
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

5. Configuración de los servidores de nombres (DNS)

A continuación veremos configurar los servidores de nombres (DNS) usando el menú Customize
System (Modo texto) de nuestro.

En la pantalla System Customitzation usaremos de las flechas de nuestro teclado para descender a
la opción del menú lateral llamada Configure Management Network.

El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de Configuración
de la red de Administración (Management Network).

Para configurar los servidores de DNS de la red de administración de nuestro host, seleccionaremos
la quinta de las opciones de menú de la sección Configure Management Network, llamada DNS
Configuration.

Aparecerá una pequeña ventana emergente llamada DNS Configuration, donde podremos introducir
las direcciones IP de los servidores de nombres de nuestra red.

También nos permitirá asignar un nombre a nuestro servidor host.

#VMwarePorvExperts 163
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

VMware 6.5.0: Configure Management Network - Configuración DNS.

https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-configuracion-dns.
html

#VMwarePorvExperts 164
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

6. Configuración IPv6

Por ultimo vamos a descubrir como configurar la dirección IPv6 en un host VMware vSphere ESXi.

Por defecto IPv6 estará activado en la instalación de un nuevo host de VMware, si nuestro entorno no
dispone de direccionamiento IPv6 es una buena práctica deshabilitar el apartado de IPv6 Configuration
de nuestro host.

En la pantalla System Customitzation usaremos de las flechas de nuestro teclado para descender a
la opción del menú lateral llamada Configure Management Network.

El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de Configuración
de la red de Administración (Management Network).

Para configurar de dirección IPv6 asignada a la red de administración, seleccionaremos la cuarta de


las opciones de menú de la sección Configure Management Network, llamada IPv6 Configuration.

Aparecerá una pequeña ventana emergente llamada IPv6 Configuration, donde podremos configurar
las opciones de nuestra tarjeta de red.

Podemos elegir entre tres opciones:

• Deshabilitar IPv6.

• Configurar IPv6 usando un servidor de DHCP.

• Configurar IPv6 de forma manual.

#VMwarePorvExperts 165
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Finalizada la configuración pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de los adaptadores de red.

Terminada la configuración presionaremos la tecla Esc de nuestro teclado para salir del menú Configure
Management Network.

Nos aparecerá una última ventana emergente para que confirmemos todos los cambios que hemos
realizado durante la configuración de las tarjetas de red de nuestro host VMware ESXi vSphere.

Si hemos realizado cambios en la red de administración del host. La aplicación de estos cambios
puede ocasionar una breve interrupción de la red, desconectar el software de administración remota y
afectar la ejecución de máquinas virtuales. En caso de que hayamos habilitado o deshabilitado IPv6 el
reinicio de nuestro servidor host será necesario.

Confirmaremos que todo es correcto pulsando la tecla Y y nuestro servidor host reiniciará.

#VMwarePorvExperts 166
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Una vez termine el reinicio del servidor aparecerá el menú principal System Customization donde
podremos comprobar todos los cambios ya aplicados.

Pulsaremos una vez más la tecla Esc en el teclado de nuestro host para volver a la pantalla de
bienvenida de VMware ESXi vSphere.

VMware 6.5.0: Configure Management Network - Configuración IPv6.

https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-ipv6.html

VIDEO - VMware 6.5.0: Configure Management Network.

https://youtu.be/fLXc7eocmPY

#VMwarePorvExperts 167
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

7. Actualizar un servidor host VMware vSphere ESXi

En este capítulo veremos, como actualizar un servidor host VMware vSphere ESXi.

En nuestro ejemplo, actualizaremos un servidor que se encuentra en producción con la versión ESXi
6.0.0 a la versión ESXi 6.7.0, pero el procedimiento es básicamente una tarea similar para todas las
versiones del producto.

Para actualizar un nuevo servidor host, en primer lugar, deberemos descargar la imagen ISO de la
nueva versión de ESXi, compatible con el hardware de nuestro equipo, a la que queremos actualizar
nuestro servidor.

Recortemos que antes de empezar la actualización de un servidor host de VMware comprobaremos


que el hardware de nuestro servidor es 100% compatible con la versión de VMware vSphere que
pretendemos desplegar.

Como hemos comentado en el apartado de la instalación de un nuevo servidor host, podremos descargar
imágenes personalizadas para servidores de marcas como pueden ser HP, Lenovo, Fujitsu, CISCO,
Hitachi o DELL. Una vez descargado el soporte de instalación de VMware lo montaremos en nuestro
hardware para empezar la actualización del producto.

Seguidamente, tenemos que mover todas las máquinas virtuales, que dependen del servidor Host
que queremos actualizar, a otro Host de nuestra granja de VMware. Si solo disponemos de un único
servidor VMware vSphere ESXi tendremos que parar las máquinas virtuales.

Una vez hayamos movido o apagado todas las máquinas virtuales que dependen del host que queremos
actualizar, montaremos el soporte de instalación de VMware vSphere y arrancaremos desde la imagen.
Aparecerá el Boot Menú del instalador, en el que seleccionaremos la primera opción. Especificará la
versión del producto que hemos elegido para actualizar terminará con la palabra Installer.

#VMwarePorvExperts 168
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Hecho esto, empezará el proceso de carga de la instalación del producto, en nuestro laboratorio
instalaremos la versión 6.7.0.

En primer lugar, aparecerá la pantalla de bienvenida del asistente de instalación. Pulsaremos la tecla
Enter del teclado conectado al servidor para continuar con el asistente de instalación del producto, y
seguidamente, deberemos aceptar la End User License Agreement o EULA pulsando la tecla F11.

A continuación, el asistente de actualización nos permitirá seleccionar el disco duro, donde tenemos
instalado actualmente el sistema operativo del hypervisor,

En nuestro laboratorio de ejemplo disponemos de un volumen de disco de 40 GB en el cual tenemos


instalado el antiguo sistema operativo de VMware, lo seleccionaremos y presionaremos una vez más
la tecla Enter.

Hemos de prestar la máxima atención a este punto si tuviéramos un volumen SAN conectado a nuestro
host o si servidor dispone de algún otro volumen de disco local además del disco del sistema operativo
del hypervisor. Si no seleccionamos el volumen de disco correcto, podríamos tener perdida de datos.

Seguidamente, aparecerá una nueva ventana emergente que nos permitirá decidir que queremos
hacer con el volumen VMFS existente. Seleccionaremos la primera de las opciones llamada Upgrade
ESXi, preserve VMFS datastore, de este modo, solo actualizaremos el operativo sin cambiar ninguna
configuración y no perderemos ningún dato.

#VMwarePorvExperts 169
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La última sección del asistente de actualización de VMware ESXi será la confirmación de las selecciones
realizadas durante el asistente. Confirmaremos, que queremos proceder a realizar el Upgrade de la
versión de VMware vSphere ESXi 6.0.0 a la versión ESXi 6.7.0, para ello, presionaremos F11.

Esperaremos a que termine de actualizar el sistema operativo.

#VMwarePorvExperts 170
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Terminada la actualización de nuestro sistema operativo hypervisor, reiniciaremos el servidor ESXi.

Cuando el servidor arranque, comprobaremos que hemos actualizado a la nueva versión de ESXi.

VMware ESXi 6.7.0: Actualizar un servidor host de la versión 6.0.0.

https://www.pantallazos.es/2019/01/vmware-esxi-6-actualizar-servidor-host.html

VIDEO - VMware ESXi 6.7.0: Actualizar un servidor host de la versión 6.0.0.

https://youtu.be/E1pDfRaeiio 

#VMwarePorvExperts 171
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

8. Introducción vCenter Server

VMware vCenter Server nos permitirá gestionar nuestro entorno de vSphere desde una única consola
centralizada. Desplegaremos un servidor de vCenter en entornos de virtualización con más de un host
ESXi, no tiene sentido asumir el consumo de recursos que el despliegue de un vCenter supone si solo
tenemos un único host en nuestro entorno.

Hay alguna función, como por ejemplo la creación de plantillas a partir de una máquina virtual, que
solo podremos usar desde un servidor de vCenter. En estos casos también estaremos obligados a
desplegar vCenter Server.

Podremos optar varios tipos distintos de instalación para el mismo producto. Podremos elegir entre
instalar un servidor Windows y desplegar el instalador de vCenter en el sistema operativo de
Microsoft o también podemos usar el Appliance virtual empaquetado y optimizado por VMware, que
nos facilitará en gran medida la instalación y mantenimiento del producto.

En las últimas versiones del producto, el cliente de vSphere está basado en HTML5 y nos permitirá
gestionar todas las funciones de desde cualquier navegador de internet.

También, nos permitirá asignar funciones a distintos tipos de usuario dependiendo de las tareas
concretas que tengan que realizar en nuestra consola de gestión.

Desde la consola de vCenter Server dispondremos de visibilidad y control de todas nuestras máquinas
virtuales, servidores host y almacenes de datos.

vCenter nos permitirá usar API’s de servicios web para conseguir integrar nuestro servidor con otros
productos de gestión de sistemas existentes en nuestra red.

Podremos usar vCenter server para realizar tareas como vMotion, Snapshot que simplificarán en
gran medida el mantenimiento de nuestros servidores, o simplemente proteger nuestro entorno y todos
sus servicios usando la alta disponibilidad nativa y conseguir un Tiempo objetivo de recuperación
(RTO) inferior a los 10 minutos. 

#VMwarePorvExperts 172
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

9. Instalación de un nuevo servidor vCenter Appliance

9.1 Stage 1 Deploy vCenter Appliance

El capítulo que empezamos a continuación, está dedicado a la instalación y configuración de un nuevo


servidor de vCenter Appliance de la versión 6.7.0.

Antes de empezar con el proceso de despliegue del producto, vamos a ver algunas de las novedades
de las que disfrutaremos usando un servidor de vCenter Server de la versión 6.5.0 en adelante.

En el propio instalador de vCenter Server Appliance, tiene varias herramientas incorporadas que nos
permitirán actualizar o realizar una migración desde un servidor vCenter antiguo a una versión más
moderna del producto.

La herramienta de migración, presenta varias mejoras con respecto a la versión que se suministraba
con la versión 6.0.0 Update 2. Gracias a estas mejoras de la herramienta de migración, nos permitirá
realizar una selección granular de todos los datos que queremos que sean migrados al nuevo vCenter
server.

• Configuration.

• Configuration, events, and tasks.

• Configuration, events, tasks, and performance metrics.

VMware Update Manager o VUM ahora formará parte de vCenter Server Appliance. Si ya hemos
migrado a vCenter Server Appliance de la versión 6.0, el proceso de actualización, migrará nuestras
VUM baselines y las actualizaciones al nuevo servidor vCenter Server Appliance. Durante el
proceso de migración, los datos de configuración, inventario y alarmas de vCenter se moverán de
forma predeterminada.

Otra característica de vCenter Server Appliance es la mejora de las capacidades de administración de


dispositivos. La nueva interfaz de usuario ahora muestra estadísticas de red, base de datos, espacio en
disco, estado de salud, además, de estadísticas de CPU y memoria. Lo que disminuye la dependencia
del uso de una interfaz de línea de comandos para la motorización y tareas operacionales.

vCenter Server 6.5.0 tiene una nueva solución nativa de alta disponibilidad que está disponible
exclusivamente para vCenter Server Appliance. Esta solución consiste en tener varios nodos activos,
pasivos y Witness que son clonados a partir del servidor vCenter original. Creando una solución de
failover HA cuando se pierde uno de los nodos por completo. Cuando configuramos una solución de
alta disponibilidad desde nuestro servidor de vCenter y este cae, toda la solución funcionará aun con
la pérdida del servidor de vCenter.

Otra nueva característica de vCenter Server es la copia de seguridad y restauración integrada en


vCenter Server Appliance. Esta nueva funcionalidad out-of-the-box permite a los clientes hacer
copias de seguridad del servidor vCenter y Platform Services Controller directamente desde Virtual
Appliance Management Infrastructure (VAMI) o API.

Con vCenter, también tenemos una versión del cliente vSphere basado en HTML5 que se ejecuta
junto con vSphere Web Client.

VSphere Client está integrado en vCenter Server tanto para Windows como con el virtual Appliance

#VMwarePorvExperts 173
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

y está habilitado de forma predeterminada, pero todavía no tiene todas las características completas.

En primer lugar vamos a descargar la imagen ISO desde la página oficial de VMware. Encontraremos
que el instalador estará disponible para realizar el despliegue del nuevo Appliance desde sistemas
operativos Windows.

Una vez hayamos descargado la imagen en nuestro equipo, ejecutaremos el instalador. En nuestro
laboratorio ejecutaremos el instalador para Windows que se encuentra en la carpeta:

[CD/DVD]:\VCSA-UI-INSTALLER\WIN32\INSTALLER.EXE

Aparecerá una nueva ventana llamada vCenter Server Appliance 6.7 Installer, en ella pulsaremos
la opción Install.

Descubriremos en el menú principal que también tenemos disponibles las opciones que anteriormente
hemos mencionado, para poder realizar una actualización de un antiguo servidor de vCenter o para
migrar un antiguo servidor de virtual center a una nueva máquina virtual Appliance.

#VMwarePorvExperts 174
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La primera ventana del asistente será la Introduction, donde nos describirá el proceso de instalación
del producto.

El proceso total de despliegue estará formado por dos escenarios, el primero será el despliegue o
Deploy de nuestro nuevo vCenter Appliance y el segundo escenario será el Setup o configuración
del mismo. Seguidamente presionaremos el el botón Next para comenzar el Stage 1 o despliegue del
nuevo Appliance. Pulsaremos el botón Next para continuar.

Seguidamente, nos encontraremos en la sección llamada End user License Agreement. En


ella deberemos aceptar la End User License Agreement o EULA de VMware y, a continuación,
presionaremos el botón Next para continuar con el asistente.

#VMwarePorvExperts 175
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En la siguiente sección del asistente de instalación llamada Select Deployment Type, tendremos dos
modos disponibles para realizar la instalación:

• vCenter Server With Embedded Platform Services Controller: instalará Platform Services
Controller dentro de la propia máquina virtual de VMware vCenter Server Appliance. Es la opción
recomendada para entornos pequeños con solo un único servidor de vCenter.

• vCenter Server With External Platform Services Controller. Instalará un servidor de vCenter
en un equipo y Platform Services Controller en un Appliance virtual separado. Esta opción
nos permitirá controlar varios servidores de vCenter Server desde un mismo punto. Nos permitirá
crear una instalación distribuida de nuestro entorno. Es la opción recomendada para entornos
grandes con más de un servidor de vCenter.

Una vez hayamos elegido el modo para nuestro despliegue pulsaremos el botón Next para avanzar
en el asistente.

#VMwarePorvExperts 176
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Seguidamente, nos encoraremos en la ventana llamada Appliance deployment target, en esta nueva
sección deberemos rellenar el formulario con los datos de uno de nuestros servidores host ESXi, será
el servidor host donde queremos desplegar nuestro nuevo vCenter Appliance.

• Dirección IP o FQDN de nuestro servidor host.

• Puerto HTTPS.

• Nombre de usuario.

• Contraseña de acceso.

Una vez hayamos cumplimentado todo el formulario, pulsaremos el botón Next para avanzar a la
siguiente sección del asistente de despliegue de vCenter Appliance.

#VMwarePorvExperts 177
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La siguiente sección será Set up appliance VM, en ella vamos a definir el nombre de la nueva máquina
virtual y la contraseña que queremos asignar en el usuario root del servidor de virtual center.

La nueva contraseña definida en este formulario la usaremos para poder realizar las tareas de gestión
desde la UI.

La ruta para acceder a la consola de gestión será la siguiente:

https://IP_o_FQDN:5480

#VMwarePorvExperts 178
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Una vez hayamos pulsado el botón Next, nos encoraremos en la sección Select deployment
size. Donde, mediante unos sencillos menús desplegables, conseguiremos definir el tamaño de
infraestructura que soportará nuestro nuevo servidor de virtual center.

Para seleccionar el tamaño del vCenter Appliance, tendremos que tener en cuenta cuántas máquinas
virtuales y servidores host ESXi tendrá que gestionar. En nuestro laboratorio, hemos seleccionado la
opción minúscula o Tiny, ya que en nuestro entorno solo tenemos dos servidores host y menos de 100
máquinas virtuales.

Dependiendo de nuestras selecciones, el tamaño de los recursos necesarios para nuestro nuevo
servidor de vCenter variará.

No tener No tener Default Large X-Large


Número
más más VM Memoria Storage Storage Storage
de vCPUs
hosts de de Size Size Size
Entorno
10 100 2 10 GB 250 GB 775 GB 1650 GB
Tiny
Entorno
100 1.000 3 16 GB 290 GB 820 GB 1700 GB
Small
Entorno
400 4.000 4 24 GB 425 GB 925 GB 1805 GB
Medium
Entorno
1.000 10.000 16 32 GB 640 GB 990 GB 1870 GB
Large
Entorno
2.000 35.000 24 49 GB 980 GB 1030 GB 1910 GB
X-Large

#VMwarePorvExperts 179
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La siguiente sección del asistente será Select datastore, en ella tendremos que seleccionar un
Datastore con espacio suficiente para albergar nuestro nuevo servidor de vCenter Appliance 6.7.

Una vez seleccionado, presionaremos una vez más el botón de siguiente para avanzar en el asistente
de despliegue del producto.

Llegaremos a la sección llamada Configure Network settings, donde configuraremos los ajustes de
red de nuestro nuevo servidor de vCenter.

Los parámetros a cumplimentar del formulario serán los siguientes:

• Network: Seleccionaremos la red virtual donde queremos conectar nuestro nuevo servidor de
vCenter.

• IP Version: IPv4 o IPv6.

• IP Assignment: Tipo de asignación de direcciones IP estática o Dinámica.

• System Name: Nombre FQDN de nuestro nuevo servidor de vCenter.

• IP address: Direción IP que asignaremos de forma estática a nuestro nuevo servidor de vCenter.

• Subnet mask o prefix lenght: Máscara de red asignada a nuestro nuevo servidor de vCenter.

• Defaut Gateway: Puerta de enlace de nuestra infraestructura de red.

• DNS Servers: Servidores de nombres de nuestra infraestructura de red.

Es muy recomendable que nos aseguremos que la configuración de nuestro servidor de nombres sea
correcta.

Debemos asegurarnos de tener previamente configuradas las entradas de DNS correspondientes a


nuestro nuevo servidor de virtual center. De no ser así, las configuraremos antes de avanzar más en el
asistente de despliegue, si no, corremos el riesgo que la segunda parte del asistente llamada Stage 2
Setup vCenter Server Appliance falle en el inicio de su ejecución.

#VMwarePorvExperts 180
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Después de presionar el botón siguiente, nos encontraremos en la sección Ready to complete stage
1, comprobaremos en el resumen y si todas las configuraciones realizadas durante el asistente son
correctas, seguidamente podremos presionar Finish.

El proceso de despliegue tardará más o menos, dependiendo de los recursos disponibles en nuestro
host ESXi, en nuestro laboratorio tardó unos veinte minutos en finalizar.

Una vez terminado el despliegue de la nueva máquina virtual, podremos acceder a la gestión de la
misma usando puerto 5480.

La ruta para acceder a la consola de gestión será la siguiente:

https://IP_o_FQDN:5480

También, podremos presionar el botón Continue y acceder a la segunda fase del asistente Stage 2
Setup vCenter Server Appliance.

#VMwarePorvExperts 181
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

9.2 Stage 2 Setup vCenter Server Appliance

Seguidamente, aparecerá una nueva ventana emergente con el asistente de Stage 2 Setup vCenter
Server Appliance, el cual nos dará acceso a la configuración de nuestro nuevo vCenter Appliance.
Pulsaremos el botón next para saltar la ventana llamada Introduction.

#VMwarePorvExperts 182
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Nos encontraremos en la sección Appliance configuration, dónde se nos permitirá seleccionar la


configuración de nuestros servidores de tiempo NTP. En nuestro laboratorio, hemos seleccionado que
queremos sincronizar los servicios de tiempo con el propio servidor host de ESXi.

También, podremos habilitar o deshabilitar el acceso SSH, para las futuras configuraciones.

Seguidamente, nos aparecerá la sección llamada SSO Configuration, dónde encontraremos un


formulario que nos permitirá configurar un nuevo dominio de Single Sign-on. En nuestro laboratorio,
hemos dejado las opciones de dominio que vienen sugeridas por defecto:

• SSO domain name.

#VMwarePorvExperts 183
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

• SSO User name

• SSO Password.

• Confirm password.

• Site Name.

Podéis configurar cada una de estas opciones, con los parámetros que más se adecuen a vuestras
necesidades empresariales. Pulsaremos nuevamente el botón siguiente para continuar.

La contraseña predeterminada del administrador de vCenter Single Sign-On, administrator@


vsphere.local, se especifica en la directiva de contraseñas de vCenter Single Sign-On. De manera
predeterminada, esta contraseña debe cumplir con los siguientes requisitos:

• Tener al menos ocho caracteres

• Tener al menos un carácter en minúscula

• Tener al menos un carácter numérico

• Tener al menos un carácter especial

La contraseña de este usuario no puede superar los 20 caracteres. A partir de vSphere 6.0, se permiten
caracteres que no son ASCII. Los administradores pueden cambiar la directiva de contraseñas
predeterminada.

La siguiente sección será Configure CEIP, el programa Customer Experience Improvement


Program o CEIP de VMware facilita información que ayudará a VMware a mejorar sus productos y
servicios, a solucionar problemas y también a asesorará sobre la mejor forma de implementar y utilizar
sus productos.

Podremos seleccionar si queremos unirnos al programa de mejora de VMware, o por lo contrario,


queremos desactivar CEIP.

#VMwarePorvExperts 184
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La última sección del Stage 2 Setup vCenter Server Appliance 6.7 será Ready to complete, si todos
los parámetros que hemos configurado durante el asistente son correctos, estaremos en disposición
de presionar Finish para configurar nuestra nueva máquina virtual de vmware vCenter Appliace 6.7.

El proceso de configuración tardará unos diez minutos. Una vez haya completado el proceso, ya
podremos tener acceso a nuestro vCenter Web client.

vSphere Web Client:

https://IP_o_FQDN:443/vsphere-client

Appliance Getting Started Page:

https://IP_o_FQDN:443/

Podremos ver que tenemos acceso al cliente usando HTML5.

#VMwarePorvExperts 185
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

#VMwarePorvExperts 186
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

10. Instalación vCenter para Windows

En primer lugar vamos a descargar la imagen ISO desde la página oficial de VMware, el instalador
estará disponible para realizar diferentes tipos de despliegue. Como puede ser, el VMware vCenter
Server Appliance, el caso que hemos visto en el apartado anterior y para instalar en un sistema
operativo Microsoft Windows que es la opción que veremos a continuación.

Cuando optamos por la instalación de vCenter Server para Windows, hemos de tener en cuenta que
la versión de Windows que instalada en el servidor que pretendemos usar, sea compatible con los
requisitos mínimos necesarios de vCenter Server.

Una vez hayamos descargado el archivo comprimido con el software para realizar la instalación en
nuestro equipo, ejecutaremos el instalador. En nuestro laboratorio ejecutaremos el instalador para
Windows que se encuentra en la carpeta:

[CD/DVD]:\autorun.EXE

#VMwarePorvExperts 187
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En primer lugar, aparecerá la pantalla de bienvenida del asistente de instalación de vCenter Server
para Windows. Presionaremos el botón llamado Next> para continuar con el asistente de instalación
del producto, y seguidamente, deberemos aceptar la End User License Agreement o EULA y pulsar
nuevamente Next> para comenzar con la configuración.

En la siguiente sección del asistente de instalación llamada Select Deployment Type, tendremos dos
modos disponibles para realizar la instalación:

• Instalar vCenter Appliance con el Platfrom Services Controller o PSC en un mismo servidor.

• Instalar vCenter Appliance solamente, y desplegar un Appliance independiente con los

#VMwarePorvExperts 188
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Platform Services Controller.

Una vez hayamos elegido el modo para nuestro despliegue pulsaremos el botón Next> para avanzar
en el asistente.

La siguiente sección del asistente de instalación de vCenter server se llamará System Network
Name.

Escribiremos el nombre del servidor que usaremos para administrar el sistema local. El nombre del
servidor que especifiquemos se codificará en el certificado SSL del nuevo servidor de vCenter para
que todos los componentes puedan comunicarse entre sí utilizando el nombre del servidor.

Tenemos que usar un fully-qualified domain name (FQDM), pero si el servidor de nombres (DNS)
de nuestra organización no está disponible, podemos escribir una dirección IP estática en lugar de un
nombre (FQDM).

#VMwarePorvExperts 189
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Seguidamente, nos aparecerá la sección llamada SSO Configuration, dónde encontraremos un


formulario que nos permitirá configurar un nuevo dominio de Single Sign-on.

• SSO domain name.

• SSO User name

• SSO Password.

• Site Name.

Podéis configurar cada una de estas opciones, con los parámetros que más se adecuen a vuestras
necesidades empresariales. Pulsaremos nuevamente el botón siguiente para continuar.

La contraseña predeterminada del administrador de vCenter Single Sign-On, se especifica en la


directiva de contraseñas de vCenter Single Sign-On. De manera predeterminada, esta contraseña
deberá cumplir con los siguientes requisitos:

• Tener al menos ocho caracteres

• Tener al menos un carácter en minúscula

• Tener al menos un carácter numérico

• Tener al menos un carácter especial

La contraseña de este usuario no puede superar los 20 caracteres. A partir de la versión vSphere

#VMwarePorvExperts 190
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

6.0, se permiten caracteres que no son ASCII. Los administradores pueden cambiar la directiva de
contraseñas predeterminada según sus necesidades particulares.

A continuación tendremos que definir la cuenta de usuario con la que se van a iniciar los servicios de
nuestro servidor de vCenter.

Por defecto los servicios de vCenter arrancaran con la cuenta de sistema local de Windows, si
queremos iniciar los servicios de vCenter con otra cuenta cambiaremos el botón selector a la opción
llamada Especificar una cuenta de usuario de servicio y definiremos el nombre de usuario y la
contraseña que deseemos.

#VMwarePorvExperts 191
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

vCenter Server requiere una base de datos para almacenar los datos del servidor.

Cada instancia de vCenter Server debe disponer de su propia base de datos. En un entorno con hasta
20 hosts y 200 máquinas virtuales, podemos usar la base de datos de VMware Postgres que viene
incluida con la instalación vCenter. Podremos instalar este tipo de base de datos, durante el proceso
del asistente de instalación del producto.

Una instalación más grande requiere una base de datos externa al servidor de vCenter que sea
compatible con el tamaño de nuestro entorno.

vPostgres se basa en la base de datos de código abierto llamada PostgreSQL. En la versión de


vCenter Server 6.0 se incluyó la versión de base de datos PostgreSQL 9.3 y, a medida que vCenter
Server aumentaba su versión, también se ha actualizado la versión de PostgreSQL.

PostgreSQL, es posiblemente el sistema de gestión de bases de datos relacionales de código abierto


más potente que existe y admite múltiples plataformas, como pueden ser, Windows, SUSE Linux
Enterprise Server y Red Hat, HPUX y UNIX, por ejemplo.

VMware ha mejorado el rendimiento de la base de datos en comparación con PostgreSQL estándar.

Las bases de datos PostgreSQL precisan de un mantenimiento periódico para conseguir recuperar el
espacio en disco perdido a causa los datos eliminados, actualización de las estadísticas usadas por el
planificador de consultas de PostgreSQL o proteger la base de datos contra la pérdida de información.

VMware ha configurado el proceso de mantenimiento de forma automática para que se ejecuten de


forma desatendida en nuestro servidor de vCenter.

#VMwarePorvExperts 192
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

El registro de escritura, permite que se realicen copias de seguridad sin tener que detener la base de
datos de vCenter. El registro de escritura, registra todos los cambios realizados en los archivos de la
base de datos y se puede usar para restaurar la coherencia de la base de datos.

Este mecanismo es lo que permite que se realicen copias de seguridad sin preocuparse por la
corrupción o el apagado de los servicios. Esto también hace que no sea necesario realizar una copia
de seguridad manual de vPostgres.

Una vez hayamos pulsado el botón siguiente, nos encontraremos en la sección dedicada a la
configuración de los puertos de red. Podremos personalizar los puertos comunes, Pataform Services
Controller y finalmente los puertos para el servidor de vCenter.

Por defecto los puertos son:

Common Ports

Http port: 80

Https port: 443

Syslog Service Port: 514

Syslog Service TLS Port: 1514

Pataform Services Controller

Secure Token Service Port: 7444

#VMwarePorvExperts 193
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

vCenter Server Ports

Auto Deploy Management Port: 6502

Auto Deploy Service Port: 6502

ESXi Dump Collector Port: 6500

ESXi Heartbeat Port: 902

vSphere web Client Port 9443

Finalizaremos la configuración basada en el asistente estableciendo la ruta de nuestro disco duro


local, donde queremos ubicar los directorios de instalación del producto.

#VMwarePorvExperts 194
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La última sección del asistente será Ready to Install, si todos los parámetros que hemos configurado
durante el asistente son correctos, estaremos en disposición de presionar Install para empezar el
proceso de instalación de vCenter server.

#VMwarePorvExperts 195
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Finalizado el proceso de instalación de vCenter server, pulsaremos el botón llamado Launch vSphere
Web Client.

Aparecerá la nueva ventana de inicio de vSphere Web Client, Podremos ver que tenemos acceso
usando HTML5.

#VMwarePorvExperts 196
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

11. Actualizar ESXi 5.X a 6.X usando VMware Sphere


Update Manager

Otra forma que existe para realizar la actualización de un servidor host es usar VMware Sphere
Update Manager, a continuación vamos a ver el proceso a seguir para realizar una actualización de
un host ESXi usando VMware Sphere Update Manager, en esta ocasión actualizaremos un host de
la versión 5.5 a la versión 6.0.

Usaremos el proceso de actualización mediante VMware Sphere Update Manager cuando tenemos
que actualizar un gran número de host y pretendemos realizar actualizaciones de host de manera
simultánea.

Con VMware vSphere Update Manager, podemos automatizar la gestión de parches y a la vez,
conseguiremos eliminar la tediosa tarea de tener que realizar un seguimiento de las actualizaciones
para la posterior aplicación, de forma manual de las mismas, en todos servidores hosts y máquinas
virtuales de nuestra infraestructura de virtualización.

VMware vSphere Update Manager realiza una comparación del estado actual de los servidores host
con los parámetros de referencia y, posteriormente, aplica las actualizaciones garantizando el estado
actual.

Con el panel centralizado de vSphere Update Manager tendremos una visibilidad general del estado de
las actualizaciones en toda nuestra la infraestructura virtual. Además, podremos agendar y programar
la instalación de las nuevas actualizaciones en nuestros equipos.

También podremos definir paquetes de actualizaciones que se descargarán directamente desde la


página web de VMware.

Durante el proceso de aplicación manual de las actualizaciones, sin usar vSphere Update Manager,
pueden aparecer problemas de compatibilidad que nos obligarán a tomar decisiones para su solución.

Con el uso de VMware vSphere Update Manager, conseguiremos disminuir los errores producidos
por problemas de compatibilidad detectándolos antes de que estos se produzcan, de este modo, no
perderemos tiempo restaurando versiones anteriores del producto o revisando información técnica de
VMware para la solución de problemas.

VMware vSphere Update Manager funciona junto con vSphere Distributed Resource Scheduler
(DRS), de éste modo permitirá la aplicación de las actualizaciones, sin interrupción en los hosts en el
momento de reparar un clúster.

También usará DRS, para poner nuestros servidores hosts en modo de mantenimiento y nos permitirá
migrar en directo las máquinas virtuales a otros servidores hosts durante el proceso de actualización.
Moverá de forma automática, todas las máquinas virtuales a otros hosts que se encuentren conectados
a nuestra infraestructura durante la aplicación de las actualizaciones y, posteriormente, devolverá las
máquinas virtuales a su ubicación original al finalizar el proceso.

#VMwarePorvExperts 197
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

12. Instalación del PlugIn de VMware Sphere Update


Manager en un servidor vCenter Server Appliance

A continuación, vamos a ver el proceso de instalación de VMWare Sphere Update Manager en un


servidor Virtual Center Server Appliance 6.0.

Durante la instalación de un nuevo servidor de vCenter, de la versión Appliance 6.0, no tendremos la


posibilidad de instalar el VMware Sphere Update Manager.

Como observareis en la imagen siguiente, no tenemos disponible la sección Update manager en


nuestros servidores host ni en nuestro vCenter Server Appliance.

Para poder instalar el PlugIn de Sphere Update Manager en nuestro vCenter Server Appliance,
tendremos que hacerlo directamente desde el soporte de instalación de vCenter server de Windows.

Si tuviéramos un servidor de virtual Center de windows, podremos instalar sPhere Update Manager
fácilmente al terminar de la instalación de nuestro servidor de vCenter, pero en el caso de tener un
servidor vCenter Appliance el procedimiento se nos complicará un poco más.

El primer paso será, descargar de la página web oficial de VMware la imagen del instalador de VMware
vCenter Server, en nuestro laboratorio será la 6.0 Update 2 para Windows.

Una vez tengamos descargada nuestra imagen, montaremos el DVD y ejecutaremos el instalador.
En la ventana principal de menú del instalador de VMware vCrenter, buscaremos en el menú lateral
izquierdo la sección vSphere Update Manager y pulsaremos la opción Servidor.

Seleccionaremos la opción, Usar Microsoft SQL Server 2012 Express como la base de datos
integrada y seguidamente pulsaremos el botón Instalar.

#VMwarePorvExperts 198
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Esperaremos pacientemente a que se instalen todos los servicios de la base de datos de SQL Server
2012, al finalizar la instalación de la base de datos, de forma automática, aparecerá la ventana inicial
de VMWare Update Manager, donde nos permitirá seleccionare el idioma del asistente.

#VMwarePorvExperts 199
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Una vez iniciado el asistente de instalación de VMWare vSphere Update Manager, nos encontraremos
con la ventana de bienvenida, que saltaremos presionando el botón Siguiente.

Seguidamente nos encontraremos en la ventana del contrato de licencia, aceptaremos los términos de
la licencia y, de nuevo, pulsaremos el botón Siguiente.

En la ventana Información de soporte técnico, aparecerá seleccionada por defecto la opción, Descargue
actualizaciones de orígenes predeterminados inmediatamente después de la instalación. Por el
momento desmarcaremos ésta opción, con el fin de revisar los orígenes antes de realizar ninguna
descarga. Presionaremos por tercera vez el botón Siguiente.

#VMwarePorvExperts 200
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Nos encontraremos en la ventana llamada Información de vCenter Server, donde deberemos


introducir todos los datos que necesitará el asistente para establecer la conexión con nuestro servidor
de vCenter Server Appliance, terminada la introducción de las credenciales pulsaremos nuevamente
el botón Siguiente para continuar con el asistente.

En la sección llamada Configuración de puertos de VMware vSphere Updare Manager, no cambiaremos


nada dejando todas las opciones por defecto y presionaremos nuevamente Siguiente.

Dejaremos también tal cual, la configuración las carpetas de instalación del producto que viene
preconfigurada por defecto y seguidamente, aceptaremos la advertencia que nos aparecerá en una
nueva ventana emergente, referente espacio disponible en la unidad de disco. Esta advertencia solo

#VMwarePorvExperts 201
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

aparecerá si estamos instalando el producto en una unidad con menos de 120GB.

El espacio libre de la unidad seleccionada es inferior a 120GB. Utilice el estimador de tamaño de


VMware vSphere Update Manager a fin de asegurarse contar con espacio libre suficiente para
el sistema de la implementación. Encontrará el estimador de tamaño para todas las versiones
principales en

http://www.vmware.com/support/pubs/vum_pubs.html

Llegados a este punto, presionaremos el botón Instalar para proceder a la instalación. Solo nos faltará
esperar pacientemente a que termine el proceso, al finalizar la instalación, cerraremos el asistente
pulsando el botón Finalizar.

#VMwarePorvExperts 202
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Abriremos la consola de nuestro servidor de vCenter Server Appliance y, en el menú superior de la


ventana, accederemos a la sección Complementos.

Aparecerá una nueva ventana emergente llamada, Administrador de complementos. Moveremos la


barra de desplazamiento hacia abajo hasta encontrar la Extensión de VMware vSphere Update
Manager, pulsaremos encima del enlace Descargar e instalar... para desencadenar el proceso de
instalación del complemento.

Nos aparecerá una ventana emergente, preguntándonos si queremos ejecutar el archivo de instalación
de VMware vSphere Update Manager Client, aceptaremos la ejecución pulsando el botón Ejecutar.

En la ventana inicial del asistente de instalación VMware vSphere Update Manager Client podremos
seleccionar el idioma del asistente que más nos interese y seguidamente presionaremos el botón
Aceptar.

El procedimiento de instalación posterior es muy sencillo y no tiene ninguna opción que podamos
variar, básicamente es ir pulsando el botón Siguiente hasta finalizar la instalación.

La única opción que nos permitirá variar, será la aceptación del contrato de licencia para el usuario
final, que deberemos aceptar.

#VMwarePorvExperts 203
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Finalizado el asistente, nos aparecerá una nueva ventana emergente con la típica advertencia de
seguridad del certificado de nuestro servidor de vCenter Appliance.

Un certificado SSL que no es de confianza está instalado en “vCenter” y no se puede garantizar


la comunicación segura. En función de su directiva de seguridad, es posible que este problema
no suponga una preocupación relativa a la seguridad. Es posible que necesite instalar un
certificado SSL de confianza en el servidor para evitar que aparezca esta advertencia.

El certificado recibido desde “vCenter” se emitió para “VMware default certificate”. No se


puede garantizar la comunicación segura con “vCenter”. Asegúrese de que el nombre de
dominio completo en el certificado coincida con la dirección del servidor al que está intentando
conectarse.

#VMwarePorvExperts 204
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Haga clic en Omitir para continuar utilizando el certificado SSL actual.

Presionaremos el botón Omitir, para usar el certificado actual y continuar. Comprobaremos que
la extensión de VMware vSphere Update Manager se ha instalado y habilitado con normalidad,
cerraremos la ventana del Administrador de complementos haciendo uso del botón Cerrar, situado en
la parte inferior derecha de la ventana.

También podemos verificar, que habrá aparecido una nueva sección en nuestro servidor de vCenter
llamada Update Manager.

vCenter Server Appliance 6.0: Instalación VMWare Sphere Update Manager - Parte 1

https://www.pantallazos.es/2016/06/instalacion-vmware-sphere-update-Manager-parte1.html

vCenter Server Appliance 6.0: Instalación VMWare Sphere Update Manager - Parte 2

https://www.pantallazos.es/2016/06/instalacion-vmware-sphere-update-Manager-parte2.html

Una vez tengamos instalado el PlugIn de Sphere Update Manager en nuestro vCenter Server
Appliance estaremos en disposición de poder actualizar nuestros servidores host.

#VMwarePorvExperts 205
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En primer lugar, descargaremos la imagen del hypervisor de VMware de la página oficial del fabricante.
Como en los casos anteriores hemos de tener en cuenta, que tendremos disponibles imágenes
personalizadas para nuestros servidores de marca HP, DELL, LENOVO, etc...

Estableceremos una conexión con el servidor de VMware vCenter que esté gestionando el host que
queremos actualizar. Una vez tengamos abierta la consola de vCenter seleccionaremos en el árbol
de menú lateral, situado en la parte izquierda de la ventana, el servidor host que queremos actualizar.

En nuestro ejemplo, el servidor físico ya no tiene máquinas virtuales que dependen de él. Es una
buena práctica vaciar el servidor antes de la actualización, de este modo agilizaremos el proceso de
actualización del sistema operativo del host.

Habiendo seleccionado el servidor host, accederemos a la sección Update Manager, situada en el


menú superior, en ella, buscaremos el enlace llamado Vista de Administrador.

Una vez estemos en la ventana de Administrador de Update Manager para..., buscaremos en el


menú superior de la ventana, la sección llamada Imágenes ESXi. Seguidamente, accederemos a la
sección y pulsaremos en el enlace llamado Importar Imagen ESXi...

#VMwarePorvExperts 206
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Nos aparecerá una nueva ventana emergente mostrándonos el inicio del asistente para Importar
imagen ESXi. En la sección llamada Seleccionar imagen ESXi, pulsaremos el botón Examinar...
situado en el centro de la ventana.

Seleccionaremos la imagen que hemos descargado de la página oficial de VMware en los pasos
anteriores, y pulsaremos el botón Abrir.

#VMwarePorvExperts 207
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Una vez tengamos seleccionada la imagen del sistema operativo al que queremos actualizar nuestro
servidor host, presionaremos el botón Siguiente, situado en la parte inferior derecha de la ventana.

Nos aparecerá una nueva ventana emergente con la típica advertencia de seguridad del certificado de
nuestro servidor de virtual center.

Un certificado SSL que no es de confianza está instalado en “vCenter” y no se puede garantizar

#VMwarePorvExperts 208
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

la comunicación segura. En función de su directiva de seguridad, es posible que este problema


no suponga una preocupación relativa a la seguridad. Es posible que necesite instalar un
certificado SSL de confianza en el servidor para evitar que aparezca esta advertencia.

El certificado recibido desde “vCenter” se emitió para “VMware default certificate”. No se


puede garantizar la comunicación segura con “vCenter”. Asegúrese de que el nombre de
dominio completo en el certificado coincida con la dirección del servidor al que está intentando
conectarse.

Pulsaremos el botón Omitir, y esperaremos pacientemente a que la totalidad de la imagen, haya


subido a nuestro servidor.

Una vez terminado el proceso de carga de la imagen ISO de la nueva versión de VMware ESXi, en
nuestro laboratorio se trata de la versión 6.0 Update 2, avanzaremos en el asistente presionando
nuevamente el botón Siguiente.

#VMwarePorvExperts 209
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

La siguiente sección del asistente será Nombre de la línea base, donde procederemos a crear una
nueva línea base. Asignaremos un nombre para poder identificar la nueva línea base en los pasos
posteriores del proceso de actualización y si queremos también nos permitirá introducir una breve
descripción.

Hecho esto, terminaremos el asistente presionando el botón Finalizar.

#VMwarePorvExperts 210
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Terminado el asistente, comprobaremos que tenemos disponible la nueva imagen del sistema operativo
al que queremos actualizar nuestro servidor host en la sección de Imágenes ESXi importadas de
nuestro VMware Sphere Update Manager.

Una vez tengamos importado nuestro nuevo soporte destinado a la actualización en la consola de
VMware Sphere Update Manager, procederemos a actualizar o corregir nuestro servidor.

#VMwarePorvExperts 211
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En nuestro ejemplo, tenemos instalado un servidor VMware ESXi 5.5.0 Build 1331820, y pretendemos
actualizar el sistema operativo a la versión VMware ESXi 6.0.0 Build 3620759.

Abriremos nuestro cliente de vSphere y estableceremos una conexión con nuestro servidor de virtual
center, una vez tengamos establecida la conexión, seleccionaremos el servidor host que queremos
actualizar.

Nos dirigiremos al menú superior de la división derecha de la ventana y accederemos nuevamente a


la sección Update Manager.

Seguidamente, asociaremos nuestra recién creada línea base usando el enlace llamado Asociar...

Nos aparecerá una nueva ventana emergente llamada Asociar línea base o grupo, en ella,
seleccionaremos la línea base que hemos creado en los pasos anteriores y presionaremos el botón
Aceptar.

La ventana llamada Asociar línea base o grupo se cerrará y nos devolverá a la ventana de Update
Manager donde podremos comprobar que todas nuestras selecciones han sido actualizadas, solo nos
faltará presionar el botón Corregir.

#VMwarePorvExperts 212
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Aparecerá la ventana inicial del asistente para Corregir, en la sección Selección de correcciones
verificaremos que todas las selecciones que vienen configuradas por defecto, son correctas y se
adecuen a la actualización que deseamos aplicar.

Si todo es correcto, pulsaremos el botón Siguiente para pasar a la siguiente sección del asistente.

En la sección del Contrato de licencia de usuario final, solo tendremos que aceptar los términos y el
contrato de licencia y, nuevamente presionaremos en el botón Siguiente para continuar.

#VMwarePorvExperts 213
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Seguidamente, nos aparecerá una advertencia, avisándonos que después de la actualización de


nuestro sistema operativo, no será posible la vuelta atrás a la versión origen.

En caso de una actualización de la versión ESXi 5.x a la versión ESXi 6.x, terminado el proceso de
actualización no podremos revertir los cambios realizados a la instancia anterior de la versión ESXi
5.x.

Si quisiéramos omitir las advertencias sobre dispositivos de hardware no compatibles y almacenes


de datos de VMFS que ya no se admiten, activaremos el cuadro selector situado en la parte inferior
de la ventana. Debemos tener en cuenta las implicaciones que supone omitir estas advertencias.

#VMwarePorvExperts 214
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En ciertas ocasiones, al omitir las advertencias sobre dispositivos de hardware no compatibles


y almacenes de datos de VMFS que ya no se admiten, podríamos crear entornos de instables o
directamente desembocar ante la imposibilidad de arrancar el host que hemos actualizado.

Seleccionadas las opciones necesarias, presionaremos el botón Siguiente del asistente para continuar.

La siguiente sección será la denominada Programar, donde podremos especificar en qué momento
exacto es cuando queremos actualizar nuestro servidor host.

En nuestro laboratorio, especificaremos que queremos lanzar el proceso de actualización


Inmediatamente. Hecho esto, pulsaremos el botón Siguiente para pasar a la próxima sección del
asistente.

Antes de proceder a la corrección de los servidores host, los ESXi deberán entrar en modo
mantenimiento y todas las máquinas virtuales que dependan del servidor host afectado, deberán ser
movidos o apagados.

En la sección Opciones de corrección de hosts podremos elegir como deben actuar los servidores
host con las máquinas virtuales que hospeden, en el momento que tengan que entrar en el modo de
mantenimiento.

Nos permitirá elegir las opciones de energía de cada una las máquinas virtuales que se encuentren
encendidas en el host objetivo de la actualización. Podemos elegir entre las opciones siguientes:

• Apagar máquinas virtuales.

#VMwarePorvExperts 215
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

• Suspender máquinas virtuales.

• No cambiar el estado de energía de la VM.

Por defecto, tendremos seleccionada la opción No cambiar el estado de energía de la VM, no


cambiaremos a ninguna otra de las opciones y presionaremos el botón Siguiente para continuar.

Teniendo seleccionada la opción No cambiar el estado de energía de la VM, en caso de que hayamos
olvidado de migrar alguna máquina virtual, el proceso se detendrá y esperará a que la migremos o la
apaguemos.

La siguiente sección será Opciones de corrección de hosts, en esta sección, hemos de tener
en cuenta que el host objetivo de la actualización no puede pertenecer a un clúster activo de High
Abailability, Distributed Power Manaement o Fault Tolerance. Por lo que deberemos sacar el
servidor físico del clúster del que depende, o marcar en esta sección las opciones necesarias para que
los servicios sean deshabilitados.

También podríamos configurar cuántos hosts se podrán actualizar de forma simultánea durante la
tarea de corrección. Pulsaremos el botón Siguiente para continuar.

#VMwarePorvExperts 216
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

En la sección Listo para finalizar, comprobaremos que todas las selecciones realizadas durante
el asistente son correctas y presionaremos el botón Finalizar para terminar el asistente y lanzar el
proceso de actualización.

La actualización pondrá nuestro host en modo mantenimiento sin problemas, ya que hemos movido
todas las máquinas virtuales con anterioridad. Solo tendremos que esperar a que todo el proceso
termine.

#VMwarePorvExperts 217
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Si accedemos a la vista de la consola de nuestro host. Comprobaremos, que el proceso de Upgrade


avanza sin problemas, al término de la actualización, nos advertirá que es necesario actualizar también
las licencias de nuestro servidor host para equipararlas a la nueva versión del producto, presionaremos
la tecla Enter de nuestro teclado para reiniciar el servidor.

#VMwarePorvExperts 218
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

Solo deberemos esperar a que arranque nuestro servidor host, para poder comprobar que todo está
en orden y correctamente configurado.

VMware Sphere Update Manager: Actualizar Host ESXi - Parte 1

https://www.pantallazos.es/2016/06/actualizar-host-esxi-Update-Manager-parte1.html

VMware Sphere Update Manager: Actualizar Host ESXi - Parte 2

https://www.pantallazos.es/2016/06/actualizar-host-esxi-Update-Manager-parte2.html

#VMwarePorvExperts 219
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé

#VMwarePorvExperts 220
Patrocinadores

GOLD

SILVER

BRONZE

#VMwarePorvExperts 221
Capítulo 4
Redes en vSphere

Miguel Ángel Alonso

#VMwarePorvExperts 222
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Introducción

Uno de los aspectos clave en un centro de datos es sin lugar a dudas las redes y comunicaciones que
hacen posible que nuestras aplicaciones y sistemas puedan operar entre ellos ofreciéndonos un sinfín
de posibilidades y servicios a nuestras empresas o clientes.

En este capítulo voy a daros los conceptos clave para conseguir poder realizar la interconexión a
nivel de redes de nuestras Máquinas Virtuales (VMs) o contenedores (Dockers) entre ellos bajo
redes internas LAN (Local área Network) o hacia red de área extensa WAN (Wide área Network) e
Internet dentro del mundo de VMware vSphere.

Partiremos de un pequeño repaso y breve resumen con el que pretendo darte una ligera introducción
al concepto de networking informático, seguiremos con la información detallada y en profundidad pero
muy clara de los diferentes dispositivos que vSphere nos da para poder comunicar nos a través de
la red LAN o Internet y finalmente como colofón del capítulo os daré nociones muy interesantes de
como abordar un diseño generalista de una empresa (tipo) con un caso simulado para dar un enfoque
más práctico con lo que tendremos una visión muy completa desde el principio hasta el final de como
las redes deben de ser estructuradas e integradas en una infraestructura de VMware vSphere para
el correcto funcionamiento de nuestras Máquinas Virtuales o contenedores.

#VMwarePorvExperts 223
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

1. Networking (Redes y su concepto)

A grandes rasgos y después de buscar por internet para intentar conseguir encontrar el concepto
más claro posible se podría decir que bajo el nombre de Networking identificamos las soluciones
de electrónica de red que se encargan de aportar a la red de datos corporativa la calidad, control y
seguridad que precisan las comunicaciones de datos que circulan por ella.

El valor de una red de datos corporativa viene dado por el nivel de servicios que podemos ofrecer sobre
la misma con las máximas garantías de calidad. Las soluciones de networking son capaces de dar
respuesta a los requerimientos de estas aplicaciones de valor, en aspectos tales como conmutación,
acceso, ancho de banda, monitorización, redundancia… La electrónica de red es, por tanto, un elemento
importante en redes de datos tradicionales, pero totalmente crítico en redes de datos multiservicio. Su
diseño, implantación y mantenimiento pasan a ser, por tanto, fundamentales.

#VMwarePorvExperts 224
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

2. Dispositivos de red

Los equipos informáticos descritos necesitan de una determinada tecnología que forme la red en
cuestión. Según las necesidades se deben seleccionar los elementos adecuados para poder completar
el sistema. Por ejemplo, si queremos unir los equipos de una oficina entre ellos debemos conectarlos
por medio de un conmutador (Switch) si además hay uno o varios portátiles con tarjetas de red Wi-
Fi debemos conectar un punto de acceso inalámbrico para que recoja sus señales y pueda enviarles
las que les correspondan, a su vez el punto de acceso estará conectado al conmutador por un cable.
Si todos ellos deben disponer de acceso a Internet, se interconectarán por medio de un router, que
podría ser ADSL, ethernet sobre fibra óptica, etc.

Los elementos de la electrónica de red más habituales son:

Conmutador de red (Switch), Capa 2

Imagen de redestelematicas.com

Enrutador (Router) Capa 3

#VMwarePorvExperts 225
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

3. Protocolos de red

Existen diversos protocolos, estándares y modelos que determinan el funcionamiento general de las
redes. Destacan el modelo OSI y el TCP/IP. Cada modelo estructura el funcionamiento de una red de
manera distinta. El modelo OSI cuenta con siete capas muy definidas y con funciones diferenciadas; el
TCP/IP con cuatro capas diferenciadas pero que combinan las funciones existentes en las siete capas
del modelo OSI. Los protocolos están repartidos por las diferentes capas, pero no están definidos como
parte del modelo en sí sino como entidades diferentes de normativas internacionales, de modo que el
modelo OSI no puede ser considerado una arquitectura de red, y de hecho es sólo una abstracción
teórica.

Como podéis ver en la imagen de arriba podemos ver el modelo lógico de las siete capas del modelo
OSI para poder entenderlas mejor.

En los próximos apartados veremos como VMware ha conseguido mediante switches virtuales que
emulan a la perfección la mayoría de las funcionalidades de un Switch físico para poder trabajar en
capa 2 y conectar todas nuestras máquinas virtuales entre ellas y recibir o enviar tráfico hacia o desde
Internet.

#VMwarePorvExperts 226
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

4. Redes en vSphere

4.1 Switches Virtuales

VMware nos da una serie de dispositivos llamados switches virtuales que más adelante vamos a
clasificar en dos tipos claramente diferenciados, standard y distribuidos.

Los conmutadores (switches) virtuales proporcionan la conectividad entre las máquinas virtuales dentro
de un mismo host (ESXi) o entre hosts diferentes. Los conmutadores virtuales o switches también
admiten el acceso a la red de VMkernel para la gestión de los hosts, vSphere vMotion, iSCSI y NFS.

4.2 Componentes de un Switch Virtual

Un conmutador virtual tiene tres tipos de conexión (redes) específicos:

• Redes de máquinas virtuales (Virtual Machine Network). Estos serían equivalentes a las
conexión o tráficos de las máquinas virtuales entre ellas o hacia Internet. Exclusivamente tráfico

• Puerto VMkernel: para almacenamiento por IP, Migraciones en caliente de Vms con vSphere
vMotion, tolerancia a fallos (Fault Tolerance) de VMware vSphere, vSAN, VMware vSphere®
Replication ™ y la red de administración ESXi o Management Network. En definitiva, tráfico de
VMware para características específicas como las ya mencionadas en estas líneas.

• Puertos de enlace ascendente o UPLINKs los cuales son una representación de las NIC físicas
de nuestros hosts ESXi que son los que conectan con nuestra circuitería externa de red (Física).

imagen de blog.aodbc.es

#VMwarePorvExperts 227
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Diferentes tipos de redes pueden coexistir bajo el mismo Switch o pueden hacerlo separándolas entre
diferentes switches tal y como os muestro en el gráfico de abajo.

Imagen de VMware

Aquí debería de decir que, de cara al diseño, mientras la opción de arriba no necesita tener tantos
uplinks físicos, pero si puede adolecer de un ancho de banda más limitado respecto a la opción de
abajo. Eso sí, la opción de abajo nos va a consumir muchos más UPLINKs (NIC físicas) por host
teniendo en cuenta que VMware da soporte a un máximo de 12 NIC por ESXi no deberemos de
rebasar nunca este número para así cumplir con las mejores prácticas de rendimiento y gestión del
hipervisor (ESXi).

En la siguiente imagen puedes ver cómo se ven los switches virtuales de vSphere representados
desde la consola de gestión de VMware WebClient (Flash) el cual va a desaparecer en vSphere 7.0 o
vSphere Client (HTML5) que será la consola que se quede con nosotros definitivamente.

#VMwarePorvExperts 228
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

#VMwarePorvExperts 229
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

5. VLANs (802.1Q)

Como no podía ser de otra manera el uso de etiquetado con VLANs es casi una necesidad imperiosa
para la segmentación del tráfico de todas las redes que llegan a nuestro entorno virtualizado de VMware
y sus hipervisores, por ende VMware nos facilita este etiquetado y segmentación de la red con la cual
vamos a añadir una capa de seguridad adicional a nuestro entorno de networking, eliminación de una
gran parte del tráfico broadcast y finalmente la eliminación de la necesidad de usar una NIC por
tráfico para segmentar (una idea inviable en la mayoría de los casos).

Como puedes ver una VLAN es casi un mecanismo imprescindible y más en entornos virtualizados
donde un gran número de redes conviven en los hosts de VMware (ESXi).

5.1 Tipos de VLAN Tagging en vSphere

VMware nos da 3 tipos de etiquetado para trabajar con las VLAN.

• Virtual switch tagging (VST): este es el modo de etiquetado más utilizado en infraestructuras
VMware, nuestros switches virtuales se encargan de hacer el etiquetado de los paquetes. Nosotros
definimos portgroups (redes o tráficos) para nuestras máquinas virtuales y definimos un tag de
vlan para cada uno de ellos, solo es cuestión de conectar nuestras VMs a los portgroups indicados
según las vlans que requieran cada uno de ellos.

• External switch tagging (EST): el etiquetado de los paquetes se realiza una vez que llega al
puerto del switch físico.

#VMwarePorvExperts 230
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

• Virtual machine guest tagging (VGT): el etiquetado de los paquetes con el número de VLAN es
realizado por el sistema operativo, con esto logramos quitar la limitación que tenemos en cuanto a
número de VLANs. Tenemos que tener en cuenta el hecho de un mayor consumo de CPU debido a
el etiquetado de paquetes dentro del sistema operativo del cliente. Por defecto solo las VMXNET3
están preparadas para ello. E1000 y E1000e pueden trabajar añadiendo el software de Intel dentro
del sistema operativo para poder etiquetar en el adaptador virtual de la VM.

Esta opción es muy utilizada cuando hay software para esnifar tráfico (SNIFFER) y hacer debbuging
de este. Ej: Wireshark

5.2 Cómo configurar las VLAN en vSphere

Para terminar finalmente con las VLAN hay que tener en cuenta 2 cosas fundamentales:

• Deberemos de configurar en nuestros switches físicos todas las VLANs que queremos ver desde
nuestro entorno virtual. Debemos tener en cuenta que las VLANs son finitas y son etiquetadas
desde el 0 a la 4094 inclusive, lo que hace un total de 4095 posibles VLAN. La VLAN 0 está por
defecto en todos los portgroups y significa que no hay VLAN etiquetada.

• Poner los puertos físicos de nuestros switches en modo TRUNK para que estas (VLAN) sean
vistas desde cualquier NIC de los ESXi y así poder etiquetarlas dentro nuestros switches virtuales
o máquinas virtuales si así lo estimamos oportuno.

Ejemplo de etiquetado de la VLAN 154 en el portgroup llamado Test (VLAN)

#VMwarePorvExperts 231
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

#VMwarePorvExperts 232
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

6. Tipos de switches virtuales en VMware

Una red virtual admite los siguientes tipos de switches virtuales:

• Switch estándar:

La configuración del Switch virtual se realiza única y exclusivamente a nivel de un solo host (ESXi).
Con lo que hay que crear todos los portgroups (tráficos), vlans y demás configuraciones de manera
repetida e individualizada de ESXi en ESXi.

• Switch distribuidos:

La configuración de un Switch virtual está configurado para un centro de datos completo. La


configuración se realiza a nivel de vCENTER y no de host.

Esquema Swich standard VS stwich distribuido

#VMwarePorvExperts 233
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

7. Políticas y configuración de un SWITCH en vSphere

Hay tres grandes políticas dentro de un Switch en VMware:

• Políticas de seguridad

• Políticas de conformación del tráfico (Traffic Shaping)

• Políticas de balanceo y alta disponibilidad (FailOver)

7.1 Políticas de seguridad

Modo promiscuo: Permite que un switch virtual o grupo de puertos reenvíe todo el tráfico
independientemente del destino.

MAC Address Change: Acepta o rechaza el tráfico entrante cuando el invitado (VM o appliance)
modifica la dirección MAC.

Forged Transmit: Acepta o rechaza el tráfico saliente cuando el invitado (VM o appliance) modifica la
dirección MAC.

Un ejemplo del uso de Forged Transmit o MAC Address Change puede ser el uso de ESXi Nested
o anidados para propósitos de laboratorios. Este tipo de ESXI es representado en formato de máquina
virtual y nunca deben ser usados para fines de producción ya que VMware no les da ningún soporte.

7.2 Políticas de configuración del tráfico (Traffic Shaping)

La configuración del tráfico (Traffic Shaping) de red es un mecanismo para limitar el consumo de una
máquina virtual del ancho de banda disponible.

• La configuración del tráfico está deshabilitada por defecto.

• En un Switch Standard, la configuración del tráfico controla solo el tráfico saliente, es decir, el
tráfico que viaja desde las máquinas virtuales al Switch virtual y hacia la red física.

• Los parámetros se aplican a cada NIC virtual de las VM en el Switch Standard.

Esta política se aplica a nivel de portgroup (red o tráfico) dentro de un Switch standard o distribuido.

Los 3 mecanismos que se usan para controlar el tráfico son:

• Average Bandwith (MEDIA)

• Peak Bandwith (Pico Máximo)

• Burst SIZE (Tamaño de la ráfaga)

#VMwarePorvExperts 234
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Valores predefinidos por defecto en cada portgroup.

¡¡¡Ojo!!! Porque la modificación que se realice aquí afectará a todas las máquinas virtuales que estén
conectadas a dicho portgroup.

7.3 Políticas de balanceo y alta disponibilidad

Como puedes observar en esta última política podemos ver cuatro parámetros importantes que se
pueden configurar para ayudar en la mejor manera de ayudar al tráfico a fluir (balanceo) o recuperarse
en caso de problemas (FailOver)

7.4 Balanceo de Carga (Load Balancing)

Tenemos tres posibilidades de configuración para el balanceo del tráfico:

#VMwarePorvExperts 235
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

7.4.1 Route based on originating virtual port


Esta política está basada en el algoritmo de balanceo ROUND ROBIN donde se distribuyen las
peticiones entre las NIC físicas de los ESXi cada vez que una máquina virtual envía o recibe tráfico,
pero no necesariamente el ancho de banda.

7.4.2 Mac Hash


Esta política asocia el tráfico de una máquina virtual a la dirección MAC de una de las NIC físicas del
ESXi yendo por esta cada vez que haga peticiones. Su algoritmo es muy liviano, pero muy efectivo
en el ahorro de recursos liberando al kernel del ESXi de procesos laboriosos de balanceo del tráfico.

7.4.3 IP Hash
Esta última política tiene dos características que la diferencian y mucho de las anteriores. La primera
es que el tráfico de una máquina virtual puede ir o volver por más de una NIC física del ESXi con el más

#VMwarePorvExperts 236
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

que considerable aumento de rendimiento de las máquinas virtuales si estas son capaces de poder
usarlo. Y sí, cuando digo esto es porque no todas las máquinas virtuales disponen de aplicaciones
instaladas que sean capaces de enviar y recibir tráfico por más de un camino (NIC Física). Un ejemplo
claro de aplicación capaz de aprovechar esta política de balanceo es un servidor Web o de base de
datos.

La segunda característica que la hace diferente es que deberemos de realizar configuraciones extra en
los switches físicos activando tecnología de LAG (agregación de enlaces) tal y como pueda ser Cisco
Etherchannel para ponerte un ejemplo.

7.5 Detección de fallos de red (Network failure detection)

En esta configuración nos encontramos con las opciones Link Status Only y Beacon Probing las
cuales tienen como naturaleza de trabajo el poder detectar fallos, como desconexiones de cables
y errores de alimentación eléctrica del Switch físico en nuestra red física.

En el caso de Beacon Probing este envía y escucha sus propios paquetes de test en todas las NIC
físicas del equipo. En un UPLINK en Teaming, los paquetes se enviarán a través de cada NIC física.

• VMware recomienda tres o más NIC físicas en Teaming

• VMware no recomienda múltiples conexiones físicas de NIC al mismo Switch físico

#VMwarePorvExperts 237
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Imagen de VMware

7.6 Notificación de Switches (Notify Switch)

El objetivo de esta configuración es el envío de frames (tramas) para asegurarse de que los switches
físicos en la red conozcan la ubicación de las máquinas virtuales. Un Switch físico realiza este
aprendizaje al observar cada trama entrante y tomar nota del campo denominado Dirección MAC de
origen. Basándose en esa información, los switches crean tablas con asignaciones entre las direcciones
MAC y el puerto del Switch donde se puede encontrar esta dirección.

Hay al menos tres ocasiones diferentes en las que el ESXi envía estos mensajes:

1. Cuando una máquina virtual sea encendida, el host ESXi se asegurará de que la red esté al tanto
de esta nueva máquina virtual y su dirección MAC, así como de su ubicación física (puerto del
switch).

2. Cuando vMotion mueva una Máquina Virtual a otro host, será muy importante notificar rápidamente
a la red física la nueva ubicación del servidor virtual.

3. Si una NIC física en el host pierde la conexión, pero tuvimos al menos dos VMNIC (NIC Físicas)
como UPLINKs en el vSwitch, todo el tráfico de las máquinas virtuales se “moverá” a la interfaz
restante. También en esta situación, el host ESXi debe informar muy rápidamente a la red del
nuevo UPLINK correcto para llegar a la VM.

Nota: Por defecto está habilitado y solo se recomienda deshabilitar lo en el caso de que haya
máquinas virtuales con NLB en modo Unicast. Esto se puede resolver dedicando dos NIC físicas
para las máquinas con NLB en Unicast para no afectar al resto de máquinas virtuales o dedicar
ESXi a este tipo de máquinas con NLB Unicast.

#VMwarePorvExperts 238
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

7.7 Failback

Donde tenemos 2 opciones claras:

Si o No (Yes or NO)

Si: El tráfico está fijado sobre una NIC física, pero si esta NIC cae el tráfico es redirigido a otra NIC
hasta que la predefinida se recupera de nuevo.

NO: a diferencia de la anterior el tráfico conmuta en caso de fallo, pero no hay NIC predefinida con lo
que el tráfico no volverá a la NIC anterior hasta que haya un nuevo caso de error.

#VMwarePorvExperts 239
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

8. Protocolos de descubrimiento

vSphere admite los siguientes protocolos de descubrimiento:

• Cisco Discovery Protocol (CDP)

• Link Layer Discovery Protocol (LLDP)

CDP está disponible para los Switches Standard de vSphere y distribuidos conectados a los switches
físicos de Cisco.

LLDP es un protocolo independiente del proveedor que está disponible solo para switches distribuidos.

8.1 Modos de operación de los protocolos de descubrimiento:

• Escucha (listen): Se recibe información de los switches físicos.

• Publicación (Advertise): la información se envía a los switches físicos.

• Ambos (Both): La información se envía y recibe desde y hacia los switches físicos.

#VMwarePorvExperts 240
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

9. Switches Distribuidos

La configuración de un Switch virtual está configurado para un centro de datos completo. La


configuración se realiza a nivel de vCENTER. y no a nivel de ESXi con lo cual todos los ESXi suscritos
a este switches son susceptibles de recibir los cambios de un único punto de manera mucho más
rápida y segura evitando tener que hacer cambios eternizados en entornos grandes con muchos ESXi.

Se pueden conectar hasta 2.000 hosts (al mismo switch distribuido (vSphere 6.7).

La configuración es consistente en todos los hosts adjuntos al switch.

Los hosts deben tener una licencia Enterprise Plus o pertenecer a un clúster vSAN.

Ambos tipos de switches son elásticos: los puertos se crean y eliminan automáticamente.

9.1 Funcionalidades Switch standard vs distribuido

Imagen de cloudpathsala.com

#VMwarePorvExperts 241
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Como puedes cuando queremos tener funcionalidades avanzadas como PVLANs, NetFlow o Port
Mirroring entre otros deberemos de rascarnos el bolsillo e irnos a la licencia Enterprise Plus donde
podremos hacer uso de los switches distribuidos.

Además, en la tecnología VMware NSX (hipervisor de redes de VMware) en el que hablaremos en otro
capítulo necesita trabajar con switches distribuidos de manera obligatoria.

9.2 Funcionalidades TOP de un Switch distribuido

• PVLAN: Tecnología que permite una doble encapsulación dentro de una VLAN y que es muy
utilizada en las DMZ para proteger a las Máquinas Virtuales de ataques externos. Existen 3 tipos:
Promiscuas, Communites y Aisladas.

• NetFlow: Tecnología que permite redirigir el tráfico de uno o varios portgroup de un Switch
distribuido (dvs) a un servidor de NetFlow para recopilar información de como se está haciendo
uso de la red mediante gráficos de columnas o tipo tarta. Quien y qué está emitiendo o recibiendo
por esas redes.

• Port Mirroring: Tecnología que permite redirigir el tráfico (en tiempo real) a otra máquina virtual
o dispositivo con capacidad para esnifar ese tráfico y replicarlo pudiendo de esta manera como
ejemplo poder cortar y analizar un ataque.

• Política de balanceo NIC Load Base Teaming: esta política a diferencia de las políticas mostradas
durante el capítulo de Switch estándar (véase pagina 12) es la única que es capaz de equilibrar
la carga a nivel de ancho de banda por todos los puertos. Esta política actúa como el llenado
de una vasija y al llegar al 75% del ancho de banda de la NIC redirige las peticiones a otra NIC
realizando la misma acción de manera sucesiva. Como veis la gran diferencia con Route based
on originating virtual port es que no se balancean peticiones sino ancho de banda.

• NIOC (Netwotk I/O Control): Tecnología que nos va a permitir categorizar y priorizar los tráficos
de nuestra empresa basándonos en el SLA de nuestra empresa y cuando tengamos contención en
nuestra red dando prioridad a ciertos tráficos por encima de otros. Hay dos mecanismos que nos
permitirán realizar dichas acciones como son los SHARES (valor numérico) que se le puede dar a
un tráfico de nuestro entorno como pueda ser Virtual Machines, vMotion, Faul Tolerance, vSAN,
etc. Contra mayor sea ese valor mayor es la prioridad de acceso al tráfico y actuará como un policía
en caso de contención parando y dejando pasar ese tráfico para cumplir con el SLA determinado.

La otra opción de priorización o categorización del tráfico viene dada por dos mecanismos de calidad
de servicio como son QoS (tráfico en capa 2) o DSCP (tráfico en capa 3) el cual dentro de un tráfico
como el de máquinas virtuales podemos dar prioridad como ejemplo al video antes que, al audio,
etc.….

Además, podremos crear normas de marcaje, permitir o bloquear el tráfico basado en las etiquetas
(tags) de calidad de servicio.

#VMwarePorvExperts 242
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

10. Caso práctico

Una empresa desea crear un entorno virtualizado aprovechando todas las características principales
de redes de VMware tal y como es vMotion además de migrar todas sus redes incluyendo el acceso
al almacenamiento y a la vez cumpliendo con las mejores prácticas de VMware.

Esta empresa comprende las siguientes redes:

• Compras, Ventas y RRHH cada una segmentada por una VLAN (17,18 y 19 respectivamente) para
tener la mayor seguridad entre ellas.

• Además, al crear su nuevo entorno de virtualización han comprado una cabina iSCSI para albergar
todas sus máquinas virtuales.

• Y por supuesto quieren aprovechar las ventajas de la virtualización y poder migrar las máquinas
virtuales entre los ESXi sin parada de servicio.

Dado este escenario os mostraré los pasos esenciales para crear vuestro entorno de manera visual y
clara cumpliendo con todas las premisas anteriormente nombradas.

10.1 Primer paso (creación de redes de producción)

Lo primero que haremos es crear en cada uno de nuestros ESXi las mismas redes (muy importante)
ya que tecnologías como vMotion, Fault Tolerance o DRS necesitan encontrar en origen y destino de
la máquina virtual las mismas redes para su correcto funcionamiento.

Aquí podemos ver los 4 pasos necesarios para crear una nueva red.

#VMwarePorvExperts 243
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Aquí elegiremos la opción marcada para crear tráfico de máquinas virtuales

En este paso seleccionamos sobre que switch deseamos crear la red de Compras (Switch0).

Y finalmente damos el nombre “Compras” y la VLAN “17”.

#VMwarePorvExperts 244
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Repetiremos los mismos pasos anteriores para crearnos la red de Ventas y RRHH con sus respectivas
VLAN. Por supuesto esto deberá ser realizado en cada ESXi de nuestro entorno. Aunque la parte física
no se vea se deben de tener configuradas las VLANs en el o los switches físicos y activada la opción
TRUNK en los puertos físicos.

Ejemplo de Trunking por cada puerto del switch.

10.2 Segundo paso (creación de redes de almacenamiento)

En este paso os mostraré como crear las redes necesarias y sus pasos para conectar a una cabina
iSCSI cumpliendo las mejores prácticas de VMware.

#VMwarePorvExperts 245
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Seleccionamos la opción VMKernel para cualquier tráfico de VMware que no sea de máquina virtual.
En este caso tráfico iSCSI a cabina de almacenamiento.

Se le da un nombre descriptivo y no se marca ninguna opción ya que es tráfico iSCSI, esto valdría de
igual manera para NFS o FCoE.

Se le da un direccionamiento IP que esté dentro del rango de la cabina iSCSI

#VMwarePorvExperts 246
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Finalmente os muestro 2 VMKernel iSCSI y dos NIC Físicas para conseguir tener alta disponibilidad y
balanceo de tráfico hasta la cabina de almacenamiento. Todo esto que da más detallado en el capítulo
de almacenamiento de VMware.

10.3 Tercer paso (creación de las redes de vMotion)

Seleccionamos VMKernel desde Añadir red (Add Networking) ya que es tráfico de VMware y no de
máquina virtual la red de vMotion.

#VMwarePorvExperts 247
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

Le damos un nombre descriptivo y marcamos la opción de vMotion para que esta red sea utilizada para
la migración en caliente de máquinas virtuales de ESXi a ESXi.

Una IP y mascara de una red que se vea de manera interna entre todos los ESXi. Una red privada y
aislada de las demás.

Y finalmente así quedará la red de vMotion que deberemos crear en cada ESXi dando una IP del
mismo rango como pudiera ser la 192.168.40.102 para el ESXi02 y así sucesivamente.

Llegados a este punto deberíamos tener una red funcional y preparada para poner en marcha nuestro
entorno de virtualización cubriendo el almacenamiento de nuestras máquinas virtuales, su tráfico LAN
e Internet y la migración en caliente entre hosts (ESXi).

En el siguiente capítulo y siguiendo con el mundo de las redes en VMware pasaremos a ver VMware
NSX (hipervisor de redes) con el cual se lleva al mundo de redes virtuales a otro nivel superior y que
os mostraré de la menara más sencilla de entender.

#VMwarePorvExperts 248
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso

#VMwarePorvExperts 249
Patrocinadores

GOLD

SILVER

BRONZE

#VMwarePorvExperts 250
Capítulo 5
NSX

Miguel Ángel Alonso

#VMwarePorvExperts 251
Capítulo 5 - NSX Miguel Ángel Alonso

Introducción
En este capítulo voy a daros los conceptos clave para conseguir poder realizar la interconexión a nivel
de redes de nuestras Máquinas Virtuales (VMs) dentro de un entorno de vSphere con NSX y además
os mostraré durante todo este capítulo cómo empezar a trabajar con NSX con un paso a paso de todos
sus componentes y defiendo cómo funcionan y su orden de instalación. Esta solución de VMware tiene
una gran inclinación por su naturaleza a trabajar con entornos Multi-tenant (multiples propietarios)
como son los entornos de Cloud Computing y más en particular en Iaas (Infraestructura como servicio)
ofreciendo una solución de auto aprovisionamiento para los usuarios finales en la nube combinándola
con vCloud Director; otras soluciones como vSphere y vRealize Automation se integran también de
manera ideal con NSX.

Partiremos de un pequeño repaso y breve resumen con el que pretendo darte una ligera introducción
al concepto de hipervisor de redes, seguiremos con la información detallada y en profundidad pero
muy clara de los diferentes dispositivos que NSX nos da para poder comunicar nos a través de la red
LAN o Internet y finalmente como colofón del capítulo os daré nociones muy interesantes de cómo
abordar un diseño generalista de una empresa (tipo) con un caso simulado para dar un enfoque más
práctico con lo que tendremos una visión muy completa desde el principio hasta el final de como
las redes deben de ser estructuradas e integradas en una infraestructura de VMware NSX para el
correcto funcionamiento de nuestras Máquinas Virtuales.

#VMwarePorvExperts 252
Capítulo 5 - NSX Miguel Ángel Alonso

1. ¿Qué es NSX-V?

NSX es una plataforma de virtualización de red que le permite implementar una amplia gama de
servicios lógicos de red.

Imagen de VMware

Esta solución está integrada dentro de la solución SDDC de VMware (Centro de datos definido por
software) donde la creación de las redes se realizará por software creando switches (vxlan) como
switches distribuidos y routers como máquinas virtuales y que permitirá la creación de switching,
routing y firewalling con micro-segmentación para separar cada uno de nuestros entornos por
clientes o secciones dando salida hacia o desde internet e interconexión entre ellas sin necesidad de
dedicar hardware específico por cada cliente como pudiera ser un Router, Switch, balanceador, etc….

Y además, todo manejado desde una única consola e integrado con las soluciones más importantes
de creación de máquinas virtuales como son VMware vSphere y vCloud Director. También se integra
perfectamente con la solución de automatización vRealize Automation Center para de manera
programática crear entornos de NSX con diferentes hipervisores y sus redes integradas en minutos u
horas y listos para trabajar en producción.

#VMwarePorvExperts 253
Capítulo 5 - NSX Miguel Ángel Alonso

2. ¿Cómo trabaja NSX-V?

Trabaja aprovechando el hardware que existe dentro de nuestros centros de datos. Los hosts ESXi, los
switches virtuales y los switches distribuidos se ejecutan en el hardware.

VMware NSX gestiona los datos en todos los switches virtuales:

Imagen de VMware

#VMwarePorvExperts 254
Capítulo 5 - NSX Miguel Ángel Alonso

3. Funciones principales de VMware NSX-V

• Conmutación lógica: Nivel 2 sobre nivel 3, desvinculada de la red física.

• Enrutamiento lógico: Enrutamiento entre redes virtuales sin abandonar el host.

• Cortafuegos lógico: Cortafuegos distribuido, kernel integrado y un alto rendimiento (20 GBps de
backplane de comunicación entre los ESXi)

• Balanceador de carga lógico: Balanceo de carga de las aplicaciones por medio de software.

• Red privada virtual (VPN) lógica: VPN para el acceso remoto y de sitio a sitio por medio de
software. VPN Ipsec, L2VPN y VPN SSL.

• VMware NSX API: API basada en REST que puede integrarse en cualquier plataforma de gestión
de la cloud.

• Ecosistema de partners (Integración con los partners de seguridad y networking más importante
del mercado) TrendMicro, Bitdefender, Kaspersky, F5, Palo Alto, etc….

#VMwarePorvExperts 255
Capítulo 5 - NSX Miguel Ángel Alonso

4. Instalación y requisitos de VMware NSX-V

4.1 Requisitos relativos al sistema de gestión y al navegador:

• Un navegador web compatible:

• Internet Explorer.

• Mozilla Firefox.

• Google Chrome.

• vSphere Web Client.

• Tener activadas las cookies en el navegador utilizado para las tareas de gestión.

4.2 Requisitos del entorno:

• Configuración de DNS correcta para los hosts ESXi añadidos por nombre.

• Permisos de usuario para añadir y encender máquinas virtuales.

• Permisos para añadir archivos al datastore de las máquinas virtuales.

Hay varios elementos necesarios para hacer funcionar NSX pero hay un elemento principal desde el
cual además se debe empezar la integración. Se ofrece en formato de Appliance virtual (OVA) y su
nombre es NSX Manager.

Su gestión se realiza vía WEB:

En este ejemplo puede verse el apartado de integración con vSphere para poder gestionar todo el

#VMwarePorvExperts 256
Capítulo 5 - NSX Miguel Ángel Alonso

entorno de NSX-V finalmente desde el cliente WEB de vCenter.

Plugin de NSX-V registrado en el cliente WEB de Flash aunque trabaja también perfectamente con el
cliente HTML5 desde la versión 6.7 Update 1 de vSphere o 6.5 U2 tal y como puedes observar en
la siguiente imagen.

#VMwarePorvExperts 257
Capítulo 5 - NSX Miguel Ángel Alonso

5. Protocolo y funcionamiento de Transporte de NSX-V

5.1 ¿Qué es VXLAN y VTEP y cómo funcionan?

Imagen de VMware

Un Virtual Tunnel End Point (VTEP) es una entidad que encapsula una trama Ethernet en una trama
de VXLAN, o que des encapsula una trama VXLAN y reenvía la trama Ethernet interna. Este viene
representado como un VMkernel en el Switch Distribuido y abarca a todos los ESXi que tengamos
dentro de los cluster de las Zonas de Transporte.

Un proxy VTEP es un VTEP que reenvía el tráfico de VXLAN a su segmento local recibido desde otro
VTEP situado en un segmento remoto.

Una zona de transporte define los miembros o los VTEP de la red overlay VXLAN:

• Puede incluir hosts ESXi de diferentes cluster de VMware vSphere.

• Un cluster puede formar parte de múltiples zonas de transporte.

Un identificador de red de VXLAN (VNI) es un número de 24 bits que se añade a la trama de VXLAN:

• El VNI identifica de forma única el segmento al que pertenece la trama Ethernet interna actuando
de una manera muy parecida a como lo haría una VLAN.

• En una misma zona de transporte pueden existir varios VNI.

• VMware NSX for vSphere empieza por el VNI 5000.

#VMwarePorvExperts 258
Capítulo 5 - NSX Miguel Ángel Alonso

5.2 Modos de replicación de VXLAN en NSX for vSphere

Existen tres modos de replicación del tráfico: dos de ellos se basan en VMware NSX Controller,
mientras que el tercero se basa en el plano de datos.

• El modo unicast lleva a cabo la replicación completa por medio de unicast.

• El modo híbrido consiste en una replicación local gracias a la red física, y en una replicación
remota por medio de unicast.

• El modo de multicast requiere IGMP para una topología de capa 2 y enrutamiento de multicast
para una topología de capa 3.

Todos los modos requieren, como mínimo, una MTU de 1600 bytes.

5.3 Replicación VXLAN (Plano de Control)

En los modos de unicast e híbrido, la instancia de NSX Controller selecciona un VTEP en cada uno
de los segmentos remotos de su tabla de asignación de VTEP como proxy. Esta selección se realiza
por VNI (equilibra la carga entre los VTEP que actúan como proxy).

• En el modo unicast, este proxy se denomina Unicast Tunnel End Point (UTEP).

• En el modo híbrido, este proxy se denomina Multicast Tunnel End Point (MTEP).

• Esta lista de proxies UTEP o MTEP se sincroniza con todos los VTEP.

Si un UTEP o un MTEP abandona un VNI, la instancia de NSX Controller selecciona un nuevo proxy
en el segmento y actualiza los VTEP participantes:

• Informe de VTEP

#VMwarePorvExperts 259
Capítulo 5 - NSX Miguel Ángel Alonso

• Fallo de VTEP

Dibujo de los VTEP XYZ en cada cluster para el trasporte de las VXLAN y sus encapsulado y
desencapsulado.

#VMwarePorvExperts 260
Capítulo 5 - NSX Miguel Ángel Alonso

6. Planos de trabajo de NSX-V

Imagen de VMware

• Plano de Gestión: Único punto de configuración y API basada en REST e interfaz de usuario.

Plano de control: Gestiona las redes lógicas, estado de tiempo de ejecución, no forma parte de la
ruta de datos y es por supuesto el protocolo del plano de control.

• Plano de datos: NSX Virtual Switch, Edge de red distribuida (DLR) tráfico este-oeste,
rendimiento de velocidad de línea, NSX Edge Gateway, Plano de datos para el tráfico norte-sur
(Internet o WAN), Enrutamiento, servicios avanzados y finalmente la Seguridad del Switch.

#VMwarePorvExperts 261
Capítulo 5 - NSX Miguel Ángel Alonso

7. Elementos principales de NSX-V

7.1 NSX Manager (Plano de Gestión):

Principal elemento de configuración en NSX-V el cual nos proporciona:

• Proporciona la IU (interfaz de usuario) de gestión y NSX API.

• Instala el User World Agent, la VXLAN, el enrutamiento distribuido y los módulos del kernel del
cortafuegos distribuido.

• Configura los hosts a través de un bus de mensajes.

• Genera certificados para garantizar las comunicaciones del plano de control.

• Configura el cluster de NSX Controller a través de una API basada en REST.

7.2 NSX Controller (Plano de Control):

• Distribución de VXLAN e información sobre la red de enrutamiento lógico a los hosts ESXi. Info de
las tablas de MAC, ARP y VTEP (esta última es del encapsulado de VXLAN)

• Agrupación en clusters para ofrecer escalabilidad horizontal y alta disponibilidad.

• Distribución de la carga de trabajo dentro de un cluster de NSX Controller.

• Eliminación de la dependencia del enrutamiento de multicast y de PIM en la red física.

• Supresión del tráfico broadcast de ARP en las redes VXLAN.

Los nodos de NSX Controller se implementan como máquinas virtuales.

Cada máquina virtual consume 4 vCPU y 4 GB de RAM.

Se recomienda utilizar un cluster de NSX Controller con tres nodos para disponer de HA (protocolo
Paxos)

#VMwarePorvExperts 262
Capítulo 5 - NSX Miguel Ángel Alonso

Los hosts ESXi y las máquinas virtuales obtienen del router lógico (VM) de NSX-V la información de
la red y la envían al NSX Controller a través del User World Agent (UWA).

Imagen de VMware

7.3 UWA User World Agent (Plano de Control):

El User World Agent tiene las siguientes características:

• Se ejecuta como un demonio de servicios denominado netcpa.

• Utiliza SSL para comunicarse con NSX Controller en el plano de control.

• Ejerce como mediador entre NSX Controller y los módulos del kernel del hipervisor, excepto el
cortafuegos distribuido.

• Recupera información de NSX Manager a través del Message Bus Agent.

Los módulos del kernel del cortafuegos distribuido se comunican directamente con NSX
Manager a través del demonio de servicios vsfwd.

#VMwarePorvExperts 263
Capítulo 5 - NSX Miguel Ángel Alonso

8. Orden de instalación de VMware NSX-V

Imagen de VMware

8.1 Instalando NSX Manager

Descargamos la OVA de NSX Manager desde VMware y la implementamos en vSphere.

8.2 Configurando NSX Manager

Apuntando a la IP o FQDN de NSX Manager con nuestro navegador y por https con el usuario admin
y el password introducido durante la importación de la appliance entraremos en la parte del registro
con vCenter para gestionar NSX desde el cliente WEB mediante un plugin.

#VMwarePorvExperts 264
Capítulo 5 - NSX Miguel Ángel Alonso

8.3 Gestión de NSX desde vSphere (WebClient)

8.3.1 Instalación de los Controllers


Una vez registrado y desde el cliente web de Flash o HTML5 si estamos en versiones 6.5 Ux o 6.7
Ux podremos empezar a configurar la creación de los Controllers. En un entorno de producción el
número ideal para montar un cluster de Controllers son tres y no más.

8.3.2 Instalación de los módulos de kernel de NSX (Switching, Routing y Firewall)


Una vez tenemos los controllers corriendo y en verde (OK) el siguiente paso es instalar los paquetes
de firewall, switching y routing en cada ESXi de nuestro/s cluster/s desde la pestaña Host Preparation.
Desde aquí se instalarán los paquetes en los ESXi y se le dará un Pool de IPs para que NSX cree los
VTEP en cada uno de los ESXI.

#VMwarePorvExperts 265
Capítulo 5 - NSX Miguel Ángel Alonso

8.3.3 Creación del rango de VNI para las VXLAN


En este paso vamos a dar un rango de identificadores (VNI) para ser consumidos por las VXLAN los
cuales actúan como los números o identificadores de una VLAN.

En la captura puede verse un rango de IP MULTICAST que solo son necesarios si se va a implementar
vCloud Director.

vSphere trabajará en modo UNICAST si se usa con NSX para segmentar las redes o crear Zonas de
Transporte.

#VMwarePorvExperts 266
Capítulo 5 - NSX Miguel Ángel Alonso

8.3.4 Creación de las Zonas de Transporte


Este es último y definitivo paso para la instalación total de NSX y poder trabajar con este en nuestro
entorno. Se trata de la creación de la zona o zonas de transporte que queremos dentro de nuestro
entorno. La zona mínima debe corresponder a un solo Cluster. Se puede abracar más de un cluster
para crear diferentes zonas de transporte y luego utilizarlas en función de cómo deseemos que nuestras
redes abarquen el entorno del que disponemos.

#VMwarePorvExperts 267
Capítulo 5 - NSX Miguel Ángel Alonso

9. Preparando una Red y su Routing (Switch y Router


Lógicos)

En los siguientes pasos y tras terminar el apartado de instalación, preparación y actualizaciones de


NSX pasamos a crear Switches lógicos (VXLANs) y Edges (Routers).

Recuerda que en NSX siempre la instalación empieza de arriba abajo y de izquierda a derecha desde
el Dashboard de NSX para resultar lo más intuitivo y fácil posible durante su integración.

9.1 Logical Switches


Aquí se configuran las redes (VXLANs) que actúan como segmentos de una VLAN para conectar
nuestras máquina virtuales.

Estos son los pasos para crear un switch lógico o los que necesitemos para finalmente conectarlos a
un router si se necesita enrutar el tráfico de los switches lógicos.

#VMwarePorvExperts 268
Capítulo 5 - NSX Miguel Ángel Alonso

Estos se ven representados como un switch distribuido dentro de nuestro entorno de vSphere

9.2 NSX Edges (Routing)

Dividos en dos clases de router bien diferenciadas.

ESG (Edge Services Gateway) como tráfico Norte-Sur (hacia o desde internet).

DLR (Distributed Logical Router) como routers tráfico Este-Oeste.

En las siguientes imágenes voy a mostraros el paso a paso de la creación de un router. En este

#VMwarePorvExperts 269
Capítulo 5 - NSX Miguel Ángel Alonso

ejemplo será un DLR al cual le conectaré el switch lógico creado anteriormente y llamado Compras.

Aquí se le da un nombre descriptivo y se decide sobre la posibilidad de poner en Alta disponibilidad el


router DLR. Esta opción duplicaría el router en un modo activo-pasivo para soportar la caída del DLR
principal.

En este paso introduciremos el password del usuario admin para poder gestionar por el SHELL o SSH
el router DLR.

#VMwarePorvExperts 270
Capítulo 5 - NSX Miguel Ángel Alonso

Ejecutamos la opción dos de añadir un Edge Appliance VM y en la captura siguiente veréis los datos
necesarios para crear dic ha VM como representación del router.

Aquí se ven los datos necesarios donde crear el DLR con VM que se puede claramente en el paso 3
tal y como son el esxi, datastore, etc..

#VMwarePorvExperts 271
Capítulo 5 - NSX Miguel Ángel Alonso

Elegimos la opción de añadir una red al router y darle un direccionamiento en formato CIDR y Gateway.

Aquí se puede ver la red 172.10.10.0/24 y su Gateway 172.10.10.1 para conectar las VMs de este
switch lógico a esta red y Gateway si queremos enrutar con otras patas del switch más adelante si es
necesario.

#VMwarePorvExperts 272
Capítulo 5 - NSX Miguel Ángel Alonso

Finalmente nos pedirá el Gateway y la red sobre la que iré este Gateway para enrutar las patas que
vayamos añadiendo al router.

Finalmente, y una vez creado el DLR podemos entrar en este desde el panel de Edges en NSX
con doble click y configurar las opciones que os muestro en la captura de arriba. Con esto quedaría
montado nuestro primer router y switch lógico de nuestro quedando solo el hecho de conectar nuestras
máquinas virtuales en el switch lógico o segmento VXLAN.

Diagrama final de una infraestructura de Edges, DLR y Switches Lógicos

#VMwarePorvExperts 273
Capítulo 5 - NSX Miguel Ángel Alonso

Imagen de lostdomain

#VMwarePorvExperts 274
Capítulo 5 - NSX Miguel Ángel Alonso

10. ¿Qué es NSX-T y en qué casos debemos implementarlo?

NSX-T (Transformers) está diseñado para abordar muchos de los casos de uso para los que no se
diseñó NSX-V, como los multihipervisores. NSX-T es una pila SDN con reconocimiento de múltiples
hipervisores que se ha traído para vSphere, KVM, OpenStack, Kubernetes y Docker.

Está diseñado para abordar los marcos de aplicaciones emergentes y las arquitecturas que tienen
puntos de conexión heterogéneos entre los ya indicados. Uno de los principales casos de uso de
NSX-T es con contenedores. En la virtualización actual, estamos viendo que más y más aplicaciones
se ejecutan en entornos fuera de las máquinas virtuales.

También es importante considerar la compatibilidad con múltiples hipervisores el hecho de que NSX-T
se ha desacoplado de VMware vCenter Server. NSX-T es una solución independiente para entornos
con vCenter y vSphere, pero también puede admitir KVM, nube pública, contenedores (DOCKERS)
y también se puede integrar con soluciones como Red Hat OpenShift, Pivotal y otros.

Uno de los principales cambios en el enfoque que verás al comparar los dos productos es que NSX-T
está más centrado en dar funcionalidades en busca de dar servicios de red en la nube.

También permite a las organizaciones más flexibilidad en la elección de la solución que mejor se
adapte a su caso de uso, ya sea que incluya hipervisores, contenedores, bare-metal y nubes públicas.

VMware NSX-T se integra con la plataforma VMware Photon , que es el sistema operativo propietario
de VMware y que desarrolló desde cero desde el cual soluciones como vCenter o los NSX-Controller
de NSX-V llevan integrados como S.O.

NSX-T también contiene el complemento de interfaz de red de contenedores (CNI) de NSX-T que
permitirá a los desarrolladores configurar la conectividad de red para las aplicaciones de contenedores
(Dockers) y que nos ayudarán a entregar la infraestructura como un servicio.

10.1 Cambios en la arquitectura

Curiosamente, con NSX-T VMware ha pasado de la encapsulación basada en VXLAN que es utilizada
por NSX-V, y ha adoptado la nueva encapsulación “Geneve”. Esta diferencia en arquitectura hace que
NSX-T y NSX-V sean incompatibles en este momento.

¿Cuál es la posición del modo de Encapsulación estándar de GENEVE en contraposición a VXLAN


cuando especialmente hay una gran cantidad de dispositivos de hardware en el mercado que soportan
VXLAN?

Geneve es una encapsulación recién acuñada Co-escrita por VMware, Microsoft, Red Hat e Intel.
Geneve combina lo mejor de los protocolos de encapsulación actuales como VXLAN, STT y NVGRE
en un único protocolo. Mucho se ha aprendido de los protocolos de virtualización de red actuales y
como NSX ha madurado, la necesidad de ir más lejos con el protocolo de encapsulación extensible
ha salido a la luz. Geneve permite insertar metadatos como campos TLV que se pueden utilizar para
nuevas funciones según sea necesario.

#VMwarePorvExperts 275
Capítulo 5 - NSX Miguel Ángel Alonso

Otros cambios en la arquitectura de NSX-T a tener en cuenta:

• Los controladores NSX-T Manager y NSX-T se pueden implementar como máquinas virtuales en
ESXi o KVM

• No es estrictamente necesario el uso de vCenter

• Hay un nuevo (hostswitch) que se utiliza para el soporte de multi-hypervisores. Esta es una
variante de VMware vSwitch y Open Virtual Switch para KVM

• Utiliza la encapsulación de Geneve, el MTU de 1600 todavía se recomienda para el encabezado


de encapsulación

• Cambios de enrutamiento: NSX-T utiliza el enrutamiento optimizado de última generación que está
basado en varios niveles con separación lógica entre el enrutador del proveedor (Tier0 router) y la
función de enrutador del Tenant (TIER1 router)

• Interfaz estándar de HTML5 para configuración y gestión

10.2 En resumen

VMware NSX está evolucionando sin duda, especialmente con la introducción de VMware NSX-T.
VMware está demostrando su compromiso con la plataforma de NSX que se mueve más allá de los
entornos de vSphere e incluye KVM, OpenStack y varias nubes públicas. Este desacoplamiento
de vSphere ciertamente atraerá a otros a la siempre popular plataforma de virtualización de red de
VMware.

#VMwarePorvExperts 276
Capítulo 5 - NSX Miguel Ángel Alonso

11. ¿Cómo monitorizar NSX?

11.1 vRealize Operations Management Pack para NSX para vSphere

Amplía la monitorización de contenido en las áreas del centro de datos virtual (VDC) y Redes.

Este paquete para vROPS (vRealize Operations Manager) es una herramienta extraordinaria para la
monitorización de nuestro entorno basado en NSX y nos ofrece como más destacadas las siguientes
características:

• Visibilidad de todos los servicios de red de NSX implementados en cada clúster de vSphere,
incluido NSX Manager, Los Controllers de NSX y los servicios del plano de datos de NSX, como
son el switch lógico, routers (Edge o DLR), firewalls, etc. Se utilizan varios widgets predefinidos
para representar los servicios de NSX.

• Visibilidad de los hosts de vSphere en las zonas de transporte de NSX, en o entre varios clústeres
de vSphere, para ver el la movilidad y los intervalos de enrutamiento.

• Busca y navega por las funciones para obtener el estado de las operaciones de los objetos de NSX
implementados.

• Búsqueda del origen de las dependencias y relaciones entre las redes lógicas y físicas para alertar
de problemas y su resolución buscando su causa raíz. Esta característica incluye la detección y
alerta de la configuración de NSX, conectividad y problemas de salud (Health). Todas las alertas se
consolidan en la interfaz de alertas de un vRealize Operations (vROPs).

• Actúa como una extensión del motor de análisis y riesgos de vRealize Operations con la inclusión
de indicadores clave de rendimiento y salud en los objetos de VMware NSX.

• Nos da la posibilidad de dibujar topologías de red lógicas de extremo a extremo entre dos máquinas
virtuales seleccionadas. Los objetos de NSX ayudan a proporcionar visibilidad en la conectividad

#VMwarePorvExperts 277
Capítulo 5 - NSX Miguel Ángel Alonso

lógica. Esta vista nos va a ayudar a aislar los problemas en la red lógica o física.

• Capacidades avanzadas de resolución de problemas, como comprobar la conectividad entre dos


VTEP (Virtual Tunnel End Point) ejecutando un ping entre dos hosts.

• Plantillas de informes para generar informes de los objetos de NSX for vSphere.

11.2 vRealize Network Insight (vRNI)

Es sin duda alguna mi herramienta favorita de monitorización de NSX, vRNI es un producto para la
entrega de operaciones inteligentes en un entorno de red definido por software SDN (especialmente
NSX). En resumen, es un vRealize Operations pero solo para entornos SDN. Con la ayuda de este
producto puedes optimizar el rendimiento y la disponibilidad de la red con visibilidad y análisis en redes
virtuales y físicas.

#VMwarePorvExperts 278
Capítulo 5 - NSX Miguel Ángel Alonso

Proporciona planificación y recomendaciones para implementar la seguridad de la microsegmentación


en tu entorno dándote una visibilidad e idea muy concisas de como hacerlo, además de vistas operativas
para administrar y escalar rápidamente y con confianza la implementación de VMware NSX.

Video en español para conocer de primera mano las principales funcionalidades de la herramienta.

https://www.youtube.com/watch?v=D9tElYASNjU&feature=youtu.be

Llegados a este punto solo queda que con la orientación dada en este capítulo podamos afrontar sin
temor la implementación de la tecnología de NSX en nuestro entorno buscando un siguiente nivel
de networking y seguridad en nuetsros centro de datos para así estar a la altura de los nuevos retos
que nos van a venir en los próximos años y en un futuro que ya está aquí nada mas dar la vuelta a la
esquina.

#VMwarePorvExperts 279
Capítulo 5 - NSX Miguel Ángel Alonso

#VMwarePorvExperts 280
Capítulo 6
Almacenamiento en vSphere

Leandro Ariel Leonhardt

#VMwarePorvExperts 282
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

1. Introducción al almacenamiento

Los almacenes de datos, dicho también “datastores”, son contenedores lógicos que puede utilizar
espacio de disco de un dispositivo físico (cabina de disco - Storage) para poder almacenar máquinas
virtuales, ficheros, ISOs, etc. VMware ofrece varios mecanismos de protección y optimización a nivel
de VMFS (sistema de archivos de VMware), sin embargo, la configuración, el nivel de RAID y la
tecnología que usemos en el Storage, influye mucho en diseño y performance de la infraestructura.

VMware vSphere es compatible con cuatro tipos de sistemas de archivos: VMFS, NFS, vSAN y vSphere
Virtual Volumes.

1.1 Tipos de almacenamiento y tecnología

Dependiendo del tipo de almacenamiento y configuración, podemos crear LUNs con VMFS u optar
por un formato de sistema de archivos que se comparte mediante el protocolo NFS, en algunos casos,
ambos sistemas de archivos en un mismo entorno vSphere.

Los hosts ESXi del entorno vSphere son compatibles con varias tecnologías de almacenamiento:

• DAS: almacenamiento interno o externo conectado a los hosts mediante una conexión directa en
lugar de una conexión de red. El almacenamiento es presentado a los hosts ESXi como VMFS.

• Fibra: protocolo de transporte de alta velocidad que se utiliza para SAN. Un switch (core) interconecta
varios nodos ESXi con visibilidad al almacenamiento para crear la estructura de una red de fibra. El
almacenamiento es presentado a los hosts ESXi como VMFS y/o NFS.

• FCoE: el tráfico se encapsula sobre Ethernet (FCoE). Estas tramas FCoE convergen con otros
tipos de tráfico de la red Ethernet. El almacenamiento es presentado a los hosts ESXi como VMFS
y/o NFS.

• iSCSI: protocolo de transporte SCSI que permite el acceso a dispositivos de almacenamiento y


al cableado en redes TCP/IP estándar. El almacenamiento es presentado a los hosts ESXi como
VMFS.

• NAS: almacenamiento compartido en redes TCP/IP estándar a nivel del sistema de archivos.
El almacenamiento NAS se utiliza para montar datastores de tipo NFS. El almacenamiento es
presentado a los hosts ESXi como NFS.

1.2 Introducción a VMFS6

VMFS (Virtual Machine File System) es el sistema de archivos propietario de VMware que permite el
acceso simultáneo de múltiples nodos ESXi para leer y escribir de manera simultánea.

Puede ampliarse de manera dinámica, usa tamaño de bloques de 1 MB y 512 MB, adecuado para
almacenar archivos de discos virtuales grandes. Para archivos pequeños, el tamaño de bloque
secundario es de 8 KB.

#VMwarePorvExperts 283
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

VMFS es un sistema de archivo de clúster, lo que posibilita el uso de otras características de VMware
como:

• Migración de máquinas virtuales en caliente desde un host ESXi a otro sin tiempo de inactividad.

• Reinicio de máquinas virtuales (vSphere High Availability) en otros hosts ESXi si se produce un
fallo en el host.

• Clúster de máquinas virtuales corriendo en diferentes servidores físicos, etc.

Un volumen VMFS puede ampliarse dinámicamente sin interrupción y sin evacuación de datos
(máquinas virtuales, templates, iSO, etc). Este proceso tiene dos fases, ampliar el datastore desde la
propia cabina de disco y crecer el espacio en VMware (Increase) desde vSphere Web Client.

Para incrementar un volumen, nos dirigimos al datastore (previamente crecemos la LUN desde el
storage y hacemos un rescan de storage a nivel de clúster VMware) y en configure podemos observar
la capacidad total, el espacio aprovisionado y el espacio libre, en este ejemplo, pasaremos de tener 1
TB de capacidad a 1,5 TB:

Ahora seleccionamos la LUN (debemos de asegurarnos de que es la LUN que crecimos desde el
Storage, para ello podemos ver el WWN tanto desde el Storage como desde VMware):

#VMwarePorvExperts 284
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Seguimos el asistente y observamos que el espacio disponible para crecer es de 512 GB:

Continuamos y verificamos que la información es correcta:

#VMwarePorvExperts 285
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Al finalizar el asistente, podemos ver que el almacenamiento ha incrementado su capacidad y pasó de


disponer 1 TB a 1,5 TB:

Otra manera de ampliar, pero no recomendada, sería juntando dos o más datastores VMFS con
diferentes WWN (es el mismo asistente que acabamos de ver), se puede “concatenar” hasta 32
volúmenes, pero no es nada recomendado, un problema a nivel de almacenamiento sobre esos
volúmenes, podría provocar la pérdida de toda la información.

El volumen VMFS, también conocido como LUN (Logical Unit Number), no puede superar los 62 TB,
es decir, ampliando desde el almacenamiento o concatenando LUNs, no debe de superar los 62 TB
soportados por VMware.

Otra característica de VMFS es que proporciona bloqueo distribuido a nivel de bloque para garantizar
que una máquina virtual no se encienda en varios servidores a la vez. En caso de fallo en el servidor
ESXi, se libera el bloqueo para que pueda encenderse/reiniciarse en otro host.

#VMwarePorvExperts 286
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

1.3 Factores a tener en cuenta

Para lograr un buen rendimiento, debemos de considerar:

• Tamaño de la LUN: un datastore “grande” permite gestionar menos volúmenes VMFS, proporciona
más flexibilidad para crecer o ampliar los discos virtuales sin necesidad de expandir la LUN y más
flexibilidad para crear nuevas máquinas virtuales.

• Ancho de banda (HBA): tarjetas de red a 1 GB o 10 GB para tráfico iSCSI, o FC de 8/16 Gb o más.

• IOPS capaz de gestionar la cabina (dependerá de la cabina, tipo de discos, nivel de raid, cache, si
deduplica y comprime, etc).

• Zoning y Enmascaramiento (LUN MASK), usar una zonificación de un solo iniciador o una
zonificación de un solo iniciador y un solo target.

• Asignación de LUN para todos los hosts de un clúster, es decir, que todos los hosts de un clúster
vean la misma cantidad de datastores.

• Cabinas de discos activas-activas, o activas-pasivas (acceso a las controladores de manera


consecutiva o secuencial).

1.4 Compatibilidad con las tecnologías de VMware

Compatibilidad Compatibilidad Compatibilidad Compatibilidad Compatibilidad


Protocolo
con BFS con vMotion con HA con DRS con disco RAW
Fibra √ √ √ √ √
FCoE √ √ √ √ √
iSCSI √ √ √ √ √
NFS √ √ √
DAS * √ √
Virtual Volumes √ √ √
vSAN √ √ √

* Si la conexión DAS se realiza con almacenamiento externo, será compatible también con vMotion,
alta disponibilidad y DRS.

1.5 Creación de un volumen VMFS

Una vez que hayamos creado el volumen en la cabina de almacenamiento, o en caso de que sea
DAS, un disco local, nos posicionamos sobre host o clúster y con botón derecho —> Storage —> New
Datastore:

#VMwarePorvExperts 287
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Elegimos un nombre para el datastore, una buena práctica es usar el mismo nombre que se estableció
en la cabina de disco.

Como se puede apreciar en la imagen, vemos que identificador (Name), el LUN ID (56), la capacidad
(100 GB), si soporta aceleración por hardware (VAAI) y el tipo de disco, Flash.

Elegimos la versión, VMFS 6 o VMFS 5, en este ejemplo, VMFS 6:

#VMwarePorvExperts 288
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

En la siguiente vista, sí utilizaremos los 100 GB, el tamaño de bloque y el Space Reclamation Priority
(nuevo en VMFS6), relacionado con la recuperación de bloques en los datastores creados como “thin
provisioning”.

1.6 Introducción a vSphere Storage APis Array Integration

Antes de terminar esta breve introducción a VMFS, me gustaría comentaros la funcionalidad del VAAI,
básicamente, el VAAI lo que hace es “descargar” cargas de trabajos de los ESXi (CPU, red, memoria,
etc), para que lo ejecutara directamente la propia cabina.

Para saber si tu almacenamiento soporta funcionalidades de VAAI, te puedes conectar a un host ESXi
y ejecutas: esxcli storage core device list.

#VMwarePorvExperts 289
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Como puedes apreciar en esa imagen, VAAI Status está soportado, pero el VAAI tiene cuatro
características: ATS, Clone, Zero y Delete.

Para desglosar las funcionalidades del VAAI y averiguar si el almacenamiento con el que estamos
trabajando soporta esas 4 funcionalidades mencionadas, ejecutamos: esxcli storage core device vaai
status get.

#VMwarePorvExperts 290
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Como puedes ver en ese ejemplo, el almacenamiento que sirve volúmenes a VMware soporta las
cuatro funcionalidades del VAAI:

ATS: todo lo referente al metadato del sistema de archivo, power on, power of de VMs, vMotion,
snapshots. etc.

Clone Status: Cuando se realiza “clones” desde VMware, clone de máquinas virtuales o despliegues
desde plantillas, en lugar de hacer el trabajo el kernel de ESXi, VMware le pasa los comandos APis a
la cabina y es la cabina quien realiza el proceso de clonado.

Zero Status: Para la creación de discos virtuales en thick, en lugar de procesar el hipervisor la creación
de discos thick, ESXi pasa las “instrucciones” APis a la cabina y es la cabina quien crea el disco en
thick, quitándole trabajo al ESXi y optimizando los recursos.

Delete Status: Aquí es cuando entra VMFS6 y le saca mayor partido, ya que en versión VMFS 5,
teníamos que ejecutar este proceso a mano o mediante un software de terceros. Si tenemos soportada
esta funcionalidad a nivel de VAAI y trabajamos con VMFS6, el autoreclaim de bloques que se liberan
desde los sistemas operativos, serán recuperados automáticamente para los volúmenes thin.

1.7 Algoritmos de Multipathing

Tal como he mencionado en “factores a tener en cuenta”, existen cabinas de discos que permiten el
acceso a sus controladores (SP) de forma Activo-Activo o Activo-Pasivo.

De nada nos valdría tener un almacenamiento Activo-Activo y que solo pudiéramos acceder a las
controladoras para el acceso a las LUN por un único HBA o adaptador.

VMware ofrece mecanismos nativos de selección de rutas, equilibrio de carga y de conmutación por
error.

Hay fabricantes que ofrecen sus propios algoritmos de balanceos, proporcionan un rendimiento y
detección de fallos diseñado específicamente para su almacenamiento.

La mayoría de los fabricantes no lo ofrecen, por que los mecanismos nativos de VMware son suficiente
y altamente eficientes para dotar de alta disponibilidad y rendimiento al entorno:

• Round Robin (RR): el host usa un algoritmo de selección de ruta que alterna entre todas las rutas
disponibles. Además de la conmutación por error, la política Round Robin permite el equilibrio de
carga entre las rutas (I/O) simultáneo.

• Fixed: el host siempre utiliza la ruta preferida al disco en caso de que esté disponible. Si el host no

#VMwarePorvExperts 291
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

puede acceder al disco mediante la ruta preferida, prueba las rutas alternativas. Esta política es la
predeterminada para los dispositivos de almacenamiento activo-activo.

• Most Recently Used (MRU): el host utiliza la última ruta al disco hasta que deja de estar disponible.
Es decir, el host no cambia a otra ruta hasta que esta deja de estar disponible. Cuando esto ocurre,
se realiza una conmutación por error a una ruta nueva. Cuando la ruta original vuelve a estar
disponible, el host no conmuta a la ruta original. MRU es la política predeterminada y obligatoria
para los dispositivos de almacenamiento activo-pasivo.

Antes de aplicar una política, asegúrate con el fabricante o leyendo la documentación del modelo del
almacenamiento, que soporta Round Robin, Fixed o MRU.

#VMwarePorvExperts 292
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

2. Introducción al almacenamiento NFS

2.1 Acerca de NFS

NFS es un protocolo de uso compartido de archivos que usan los hosts ESXi para comunicarse con
un dispositivo NAS.

Al igual que en VMFS, NFS ofrece también la posibilidad de guardar archivos, plantillas e imágenes
ISO de máquinas virtuales, lo que permite migrar máquinas virtuales entre host con la característica
de vMotion.

Los hosts ESXi no utilizan el protocolo “Network Lock Manager”, que es el protocolo estándar para
permitir el bloqueo de archivos en los archivos NFS montados. VMware tiene su propio protocolo de
bloqueo. Los bloqueos NFS se realizan creando archivos de bloqueo en el servidor NFS. Los archivos
de bloqueo reciben el nombre .lck-fileid, donde fileid es el valor del campo fileid. Cuando se crea un
archivo de bloqueo, se envía una actualización periódica al archivo de bloqueo para informar a los
demás hosts ESXi de que el bloqueo sigue activo.

Inicialmente VMware vSphere sólo admitía NFS versión 3, pero a partir de vSphere 6.0 empezó a dar
soporte a la versión 4.1.

2.2 Sobre NFS v4.1 en vSphere

El soporte de NFS 4.1 en vSphere 6 permitió superar varias limitaciones de la versión 3, las cuales
mencionaremos a continuación.

Es posible usar ambas versiones, pero sin mezclar los protocolos, es decir, si creamos un recurso
compartido con v4.1, debemos de montar ese recurso en todos los servidores con la misma versión.

NFS v4.1 proporciona las siguientes mejoras frente a NFS v3:

• Multipathing nativo y trunking de sesión: NFS v4.1 proporciona multipathing nativo para servidores
que admiten trunking de sesión (múltiples direcciones IPs para acceso a recursos NFS).

• Autenticación Kerberos: NFS v4.1 introduce la autenticación Kerberos además del método
tradicional AUTH_SYS utilizado por NFS v3.

• Bloqueo de archivos integrado mejorado.

• Recuperación de errores mejorada para atenuar la caída del servidor y la conectividad.

• Menos sobre carga en el protocolo, lo que mejora la eficiencia y el rendimiento.

• Controles de errores mejorado ya que se realiza desde el servidor.

#VMwarePorvExperts 293
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Las principales “diferencias” entre NFS 3 y NFS 4.1 son:

NFS v3 NFS v4.1


Multipath gestionado por ESXi Multipath y trunk nativo
Autenticación AUTH_SYS (raíz) Autenticación por Kerberos (opcional)
Bloqueo de archivo por VMware Bloqueo de archivo integrado
Control de errores en el cliente Control de errores en el servidor

2.3 Requisitos de un datastore NFS

Si trabajamos sobre TCP/IP, es imprescindible crear un puerto de tipo VMkernel dedicado


específicamente para este tráfico.

Para obtener el máximo rendimiento y mayor seguridad, debemos separar la red NFS de la red iSCSI
(tráficos independientes).

Para crear un datastore NFS desde vSphere Web Client debemos introducir la siguiente información:

• Versión NFS: v3 o v4.1

• Nombre del datastore (recomendado usar el mismo que se proporcionó en el NAS/Storage).

• Nombre o dirección IP del servidor NFS.

• Carpeta del servidor NFS, por ejemplo /vols/vol0/librovExpert-01

• Servidores en los que se montará el recurso NFS.

• Si el sistema de archivos NFS se debe montar en modo de solo lectura.

• Parámetros de autenticación.

2.4 Montaje de un volumen NFS en vSphere

Una vez que hayamos realizado la configuración oportuna en el NAS/Storage (creación del recurso
compartido, lista de servidores que podrán montar, permisos del recurso, etc.) debemos de montar el
recurso compartido en los hosts ESXi a los que se les permitió desde el NAS/Storage.

Sobre el hosts o Clúster VMware, botón derecho, New Datastore —> seleccionamos “NFS”

#VMwarePorvExperts 294
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Ahora elegimos el tipo de versión NFS, en mi ejemplo, v4.1

Ahora introducimos el nombre del datastore, el “folder” que no más que el recurso compartido
configurado desde el NAS/Storage y el servidor NFS desde donde servimos el recurso.

#VMwarePorvExperts 295
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Tal como ya comentamos, en NFS 4.1 es posible usar kerberos como método de autenticación, en este
ejemplo, dejaré la opción por defecto.

#VMwarePorvExperts 296
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

En el paso 5, seleccionamos los hosts a los que le presentaremos el NFS (esta opción aparece por que
hice botón derecho —> New Datastore a nivel de clúster).

Por último, confirmamos que la información introducida durante el asistente es correcta y finalizamos.

Si los datos introducidos en el asistente, así como la configuración de la cabina es correcta, tendremos
un datastore NFS listo para alojar máquinas virtuales, template, ISOs, etc.

2.5 Factores a tener en cuenta (kerberos con NFS)

Debemos de tener en cuenta el UID y el GID de los archivos:

• En NFS v3, UID y GID son los del usuario raíz.

• Debemos crear una cuenta en Active Directory para el acceso de NFS v4.1, activar el cifrado AES
de Kerberos y que la contraseña nunca expire.

• Configurar que el almacenamiento o NAS utilicen Kerberos.

• Si usamos Kerberos, que siempre sobre NFS v4.1, sobre todo para evitar errores de permisos en
ficheros creados en NFS v3.

Debemos utilizar el mismo usuario de Active Directory en todos los hosts ESXi/recursos NFS v4.1:

• vSphere vMotion podría fallar si los hosts autenticados con dominio (requisito obligatorio de
kerberos) usan cuentas de usuario diferentes, para evitar esto, podemos utilizar “host profile”.

• Para que la autenticación de Kerberos se efectúe correctamente, debemos asegurarnos que la


hora está sincronizada (usar el mismo servidor NTP para toda la infraestructura).

#VMwarePorvExperts 297
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

Kerberos debe estar configurado en los servidores NFS y en los hosts ESXi antes de crear un datastore
NFS.

2.6 Compatibilidad con las tecnologías de VMware

A continuación, podemos ver diferentes tecnologías de VMware y la compatibilidad de cada una de


ellas con las diferentes versiones de NFS soportadas por vSphere.

Tecnologías VMware NFS v3 NFS v4.1


vSphere vMotion y vSphere Storage vMotion Si Si
vSphere HA Si Si
vSphere Fault Tolerance Si Si
vSphere DRS y vSphere DPM Si Si
Stateless ESXi y Host Profile Si Si
vSphere Storage DRS y Storage I/O control Si No
Site Recovery Manager Si No
vSphere Virtual Volumes Si No

2.7 Recomendaciones para trabajar con NFS

• Lo primero, configurar que el almacenamiento o NAS permita un solo protocolo NFS.

• Para montar el mismo recurso compartido NFS en todos los hosts ESXi, utilizar una única versión,
NFS v3 o NFS v4.1.

• Si montamos un datastore con la versión 3 y en otro host con la versión 4.1, podría provocar que
las máquinas virtuales, template o ISOs se dañen.

#VMwarePorvExperts 298
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt

#VMwarePorvExperts 299
H O S T E D P R I VAT E C L O U D

El camino más
rápido al cloud

OVH le ofrece la posibilidad de tener su propio Hosted Private Cloud: una infraestructura dedicada y físicamente
aislada para obtener un rendimiento óptimo. Su escalabilidad permite abarcar todas las necesidades empresariales,
desde las más básicas hasta las más avanzadas, disfrutando de todas las ventajas del alojamiento on-premises sin
una gran inversión de capital. Al estar administrada por OVH, usted podrá centrarse en la gestión de su negocio.

S O F T WA R E H A R D WA R E RED
Integración completa Acceso inmediato a una Red mundial de fibra óptica
en su sistema informático, infraestructura dedicada con ancho de banda
con vCenter y vSphere basada en los últimos garantizado, tráfico ilimitado
as a service. procesadores de Intel. y sin costes ocultos.

Lo mejor de la tecnología VMware


Construido sobre la misma plataforma que usted utiliza
actualmente en sus instalaciones, incluyendo vSphere, vCenter,
NSX y vSAN.
Basado en la tecnología Software-Defined Datacenter de VMware.
Con los mejores servicios que ya conoce, más la nueva opción
para desplegar entornos híbridos Hybrid Cloud Extension (HCX).

OVH.COM
PROMOVIENDO TU
TRANSFORMACIÓN
DIGITAL
Capítulo 7
vSAN

Federico Cinalli

#VMwarePorvExperts 302
Capítulo 7 - vSAN Federico Cinalli

1. Introducción y Casos de Uso

VMware presentó Virtual SAN (vSAN de aquí en adelante) durante el VMworld de 2013 (En USA)
aunque el GA recién estuvo disponible en Marzo de 2014 a partir de vSphere 5.5 U1.

Si bien en aquella época todavía no hablábamos de hiperconvergencia, sí que comenzábamos a hacer


referencia al Centro de Datos definido por Software mientras que NSX 6.0, en su primera versión, hacía
su presentación en Octubre de 2013 y comenzaba a patear el tablero de la virtualización de redes. En
aquellos meses estaba naciendo el tándem vSAN-NSX que sería la base, junto con vSphere, sobre la
que se sostiene el SDDC de VMware.

vSAN aporta una robusta solución de Almacenamiento definido por Software utilizando discos locales,
embebida en el Hypervisor, sin dependencia de ninguna pieza de Hardware en concreto ni ninguna
máquina virtual por Host.

Es un producto complementario a vSphere que, al igual que HA o DRS, se configura a nivel de


Cluster y se administra principalmente con vSphere Client aunque también es posible gestionarlo con
herramientas como PowerCLI, vRealize Orchestrator o incluso a través de API.

Las diferentes opciones de protección, capacidad y rendimiento se definen a nivel de objeto utilizando
las políticas de almacenamiento de Máquinas Virtuales en vCenter.

De la mano de vSphere 6.0 llegó también vSAN 6, siempre alineándose con la versión del Hypervisor.
El aporte más significativo fue la introducción de vSAN All Flash, lo que permitía comenzar a considerar
el producto como un serio candidato para dar soporte de almacenamiento a aplicaciones críticas.

Los primeros casos de uso de vSAN fueron entornos de VDI con la Suite Horizon, siendo el Cluster
Híbrido el uso más común. No obstante, a medida que VMware actualizaba vSphere hacía lo propio
con vSAN añadiendo más funcionalidades como la deduplicación y compresión, Stretched Cluster,
Encriptación y UNMAP entre otras. Según se libera una nueva versión de vSAN disponemos de una
plataforma cada vez más madura y estable si cabe, lo que permite ser considerado hoy en día, sin
lugar a dudas, como una gran solución de Almacenamiento definido por Software para aplicaciones
críticas.

Hoy en día, debido al descenso en los precios de los discos SSD e incluso NVMe, la gran mayoría de
los nuevos Clusters de vSAN son All-Flash permitiendo dar soporte a prácticamente cualquier tipo de
carga de trabajo.

Si bien es cierto que vSAN encaja a la perfección en infraestructuras HCI, no estamos hablando de una
solución exclusiva para ese tipo de hardware como sí lo son otros tipos de almacenamiento definidos
por software del mercado.

Es posible ver vSAN funcionando en producción sobre los servidores clásicos de 2U’s aportando una
capacidad importante de espacio disponible a la vez que aporta una escalabilidad tremenda en cuanto
a capacidad de almacenamiento.

En los datacenters en los que se despliega un Cluster de Management también vemos cada día más y
más Clusters de vSAN permitiendo un aislamiento en cuanto a capacidad, rendimiento y disponibilidad
respecto al almacenamiento utilizado para producción.

Existen no obstante determinadas aplicaciones o sistemas que tal vez no sean el ideal para vSAN
como pueden ser las soluciones de gestión documental que requieren grandes cantidades de
almacenamiento.

#VMwarePorvExperts 303
Capítulo 7 - vSAN Federico Cinalli

Debido a requerimientos de licencias podemos ver clusters de bases de datos desplegadas en hosts
físicos que necesiten acceso a un almacenamiento compartido. Si bien vSAN ofrece la posibilidad
de compartir LUNs a través de iSCSI para dar servicio a esos requerimientos no lo solemos ver en
producción, al menos todavía.

Por último, debemos aclarar que todos los conceptos que cubriremos en este capítulo están basados
en la versión 6.7 de vSAN.

#VMwarePorvExperts 304
Capítulo 7 - vSAN Federico Cinalli

2. Conceptos de vSAN

El sistema de almacenamiento definido por software de VMware es extremadamente simple de


implementar y administrar. No obstante, para comprender de forma correcta cómo es la configuración
y administración necesitamos aprender ciertos conceptos y componentes claves en vSAN.

Es posible trabajar con dos tipos de Clusters de vSAN diferentes en cuanto a los tipos de disco y
sus funcionalidades. Por un lado disponemos de vSAN Cluster Híbrido, y por el otro vSAN All-Flash.
Veamos una tabla comparativa.

Característica vSAN Híbrido vSAN All Flash


Discos Capacidad Mecánicos (SAS-SATA) SSD – NVMe
Discos Caché SSD – NVMe SSD – NVMe
70% Lectura
Uso Caché 100% Escritura*
30% Escritura
Deduplicación y Compresión No soportado Soportado (vSAN Enterprise)
Operaciones lectura Primero Caché Principalmente capacidad
Recursos Red vSAN 1Gbps – 10Gbps** 10Gbps o superior
RAID 5/6 No soportado Soportado

*También da servicio de lectura antes que se produzca el movimiento de los datos desde los discos de
caché a los de capacidad, operación conocida como destage.

**Recomendado

Veamos a continuación las diferentes formas de desplegar vSAN en un Cluster.

Cluster de vSAN Clásico


Éste es el vSAN Clásico que requiere un mínimo de 3 Nodos. Si bien técnicamente es posible configurar
un Cluster de vSAN con hasta 30 Nodos (incluso más), no es muy común ver estas cantidades de
Hosts en producción.

Con independencia del tipo de Cluster de vSAN y el número de Nodos, siempre tendremos un único
vSAN Datastore por Cluster y los únicos Hosts que tendrán acceso a ese Datastore serán los miembros
del propio Cluster de vSAN.

Cluster de vSAN de 3 Nodos

#VMwarePorvExperts 305
Capítulo 7 - vSAN Federico Cinalli

Cluster de vSAN de 2 Nodos


También llamado vSAN ROBO para oficinas remotas, es un Cluster de vSAN compuesto por dos Nodos
que replican los componentes entre sí. El Witness Host es normalmente una máquina virtual (también
puede ser un Host físico) que se despliega en otro sitio y almacena únicamente los componentes de
Witness.

Los Clusters de vSAN de 2 Nodos pueden ser configurados en el mismo Site o en diferentes sites y
funcionar de forma similar a los Stretched Clusters.

Cluster de vSAN de 2 Nodos

vSAN Stretched Cluster


El concepto de Sites para vSAN Stretched Cluster es algo especial ya que se trata de dos centros de
datos remotos (o dos edificios) que puedan ser conectados con 10Gbps y una latencia máxima (round
trip) de 5 milisegundos. Merece la pena comenzar aclarando este concepto de Site debido a que estos
requerimientos pueden estar fuera del alcance de múltiples organizaciones con más de un Site.

Es factible describir un Site de Stretched Cluster como un Campus o simplemente dos ubicaciones
físicas diferentes que cumplan con los requerimientos expuestos anteriormente.

El objetivo de un vSAN Stretched Cluster es crear una protección de objetos entre Sites replicando el
método de protección local.

Esquema vSAN Stretched Cluster

#VMwarePorvExperts 306
Capítulo 7 - vSAN Federico Cinalli

Hardware soportado en vSAN


Si hay una parte importante a cumplir en vSAN, ésa es la compatibilidad y el uso del Hardware validado
para vSAN. Además del Host y las interfaces de Red que se validan como siempre en la HCL de
vSphere, las controladoras RAID y los Discos son de obligada verificación en la lista de compatibilidad
de Hardware para vSAN.

Aunque no solamente el Hardware sino que también el Firmware y los drivers deben estar validados
para esos componentes y su correspondiente versión de vSAN.

Existen 3 formas diferentes de seleccionar el Hardware a utilizar según vemos a continuación.

vSAN Hosts compatibles


También conocidos en inglés como Built your own (o móntelo usted mismo) son Hosts de diferentes
marcas que no son vSAN Ready Nodes aunque la totalidad de sus componentes están soportados
para vSAN.

vSAN Ready Nodes


Tal vez la forma más simple de implementar vSAN es utilizando los Ready Nodes para vSAN. Estamos
hablando de un Hardware pre-validado en diferentes modelos, configuraciones variadas según
necesidades y provistos por múltiples fabricantes como Dell, Fujitsu, Lenovo, Intel, etc.

Están disponibles los modelos HY para Clusters Híbridos y los AF para los Clusters All-Flash.

Tanto los discos como las controladoras están pre-validados para vSAN y ofrecen diferentes
combinaciones de CPU, RAM y Capacidad. Algunos fabricantes ofrecen más flexibilidad que otros.

Intel vSAN Ready Node de Adistec

Dell EMC vXRail


Por último tenemos la opción de elegir este sistema listo para usar (pre-instalado) y con un soporte
único tanto para Software como para Hardware aunque también es cierto que es la opción de mayor
costo y tal vez menor flexibilidad en cuanto a modificaciones de la configuración y, especialmente,
escalabilidad de recursos.

Solución HCI de Dell EMC

#VMwarePorvExperts 307
Capítulo 7 - vSAN Federico Cinalli

La Red de vSAN
Evidentemente un elemento crítico es la Red de vSAN a través de la cual no solo se utiliza para servir
los bloques de datos, sino que también es la plataforma sobre la que viajan los componentes en sus
replicaciones, resincronizaciones, balanceos y operaciones internas entre los componentes de vSAN.

Como mencionamos anteriormente, en el caso de un Cluster de vSAN Híbrido es posible utilizar


interfaces de 1GbE, aunque la recomendación es el uso de interfaces de 10GbE. Cuando se trata de
un Cluster All-Flash de vSAN el requerimiento mínimo es una red de 10GbE aunque poco a poco ya
se ven redes de 25Gbps o incluso superiores. Se dice que los interfaces de 25Gbps son los nuevos
10Gbps.

Naturalmente que para evitar un punto único de fallo aprovisionaremos dos interfaces que trabajaran
con el Port Group de VMkernel de vSAN. La configuración es muy simple, como vemos en el siguiente
esquema, un VMKernel con dos Uplinks de los cuales uno estará Activo y el otro en StandBy.

Esquema simple de la Red de vSAN

No sería correcto afirmar que existe una única forma de configurar la red de vSAN aunque el esquema
anterior muestra la opción más común.

Todo siempre depende de la cantidad y calidad de recursos de que dispongamos y de la configuración


de red del resto de los servicios.

Veamos una lista de opciones y sus recomendaciones.

Jumbo Frames: Si es posible, habilitar.

EtherChannel o LACP: Normalmente se habilita cuando el resto de los servicios ya está trabajando el
agrupado de puertos y el área de networking tiene experiencia previa.

Virtual Switch Standard o Distribuido? Distribuido siempre que sea posible. vSAN incluye licencia
de vDS sin importar si nuestro vSphere es Standard.

NIOC (Network IO Control): Habilitarlo y configurarlo. Es la mejor forma establecer la prioridad del
tráfico de vSAN. Esto lo consideraremos “obligatorio” cuando estamos compartiendo interfaces de
10GbE o superiores para múltiples tipos de tráfico.

QoS (Quality of Service): En un mundo perfecto también habilitaríamos QoS salvo que utilicemos
switches físicos exclusivos para el tráfico de vSAN, lo cual no suele ser muy común.

#VMwarePorvExperts 308
Capítulo 7 - vSAN Federico Cinalli

Política de balanceo: Al configurar un Uplink en Activo y otro en StandBy no hace falta definir ninguna
política de balanceo.

Existe un gran documento oficial de VMware que podemos utilizar como guía para la configuración de
los servicios de red en vSAN:

Documento de Diseño de red en vSAN (174 páginas)

Objetos de Máquinas virtuales


Una Máquina Virtual está compuesta por diferentes ficheros de configuración, logs, swap, discos
virtuales y discos delta entre otros.

vSAN gestiona las políticas de capacidad, alta disponibilidad y rendimiento en base a objetos de
máquina virtual. Veamos a continuación cuáles son esos objetos.

VM home namespace: Este objeto es la carpeta de la VM con los ficheros de bios, vmx, nvram, hlog
y vmsd.

Disco Virtual: Por cada disco virtual que tenga la máquina vSAN gestionará un objeto de tipo disco
vmdk.

VM SWAP: El fichero de swap tendrá un tamaño igual a la cantidad de RAM asignada a la VM menos
la reserva.

Disco Delta: Una máquina con Snapshots tiene un disco delta por cada disco virtual y cada Snapshot
disponible.

VM memory: Cada vez que creamos un snapshot y preservamos el estado de la memoria tendremos
almacenado un fichero .vmem que, en vSAN, es otro objeto.

Máquina Virtual y Objetos que la componen

#VMwarePorvExperts 309
Capítulo 7 - vSAN Federico Cinalli

Grupos de Discos
Según explicamos anteriormente cada máquina virtual está compuesta por Objetos. Una vez asignada
la política correspondiente a cada Objeto, vSAN se encarga de crear los Componentes. Si bien los
Componentes se almacenan en el Datastore de vSAN, en realidad ese Datastore está compuesto por
Grupos de Discos o Disk Groups.

Un Host puede tener un Grupo de Discos, hasta un máximo de 5 Grupos de Discos o incluso ninguno.
La buena práctica es aprovisionar cada Host del Cluster de vSAN con 2 Grupos de Disco.

Cluster de vSAN con 2 Disk Groups en cada Host

Los Grupos de Disco deben disponer de un único disco para Caché, el cual será siempre SSD con
independencia del tipo de Cluster de vSAN, y al menos un disco de Capacidad.

El número mínimo de discos de Capacidad por Grupo de Discos es uno, mientras que el número
máximo de discos de Capacidad son 7.

Los discos de Capacidad en un Cluster de vSAN Híbrido son del tipo mecánicos (SAS o SATA) y los
discos de Capacidad en un Cluster de vSAN All-Flash son siempre SSD.

En una infraestructura hiperconvergente (HCI) normalmente cada Host dispone de 6 slots para discos.

A continuación, vemos 3 ejemplos diferentes de cómo se podrían configurar los Disk Groups en un
Host HCI.

3 Ejemplos de configuración de Disk Groups en HCI

#VMwarePorvExperts 310
Capítulo 7 - vSAN Federico Cinalli

Importante: Únicamente los discos de capacidad son los que aportan el Almacenamiento utilizable
(capacidad) en el Datastore de vSAN.

Datastore de vSAN alimentado por los discos de Capacidad

#VMwarePorvExperts 311
Capítulo 7 - vSAN Federico Cinalli

3. Servicios de Arquitectura de vSAN

vSAN es una solución que se configura y trabaja a nivel de Cluster aunque los servicios almacenamiento,
al igual que vSphere HA, puede continuar operativos aún con el servicio de vCenter caído.

La información que vamos a cubrir a continuación no es crítica desde el punto de vista operativa en sí
misma, pero sí muy importante si pretendemos comprender cómo funciona vSAN a nivel de arquitectura
e incluso nos ayudará a interpretar mejor los Logs en un proceso de resolución de problemas al
reconocer los nombres de los servicios de las diferentes capas funcionales de vSAN.

En el momento en que habilitamos vSAN en un Cluster, los Hosts que son miembros del mismo
comienzan a instalar y configurar los servicios de arquitectura. Los servicios son CMMDS, CLOM,
DOM y LSOM.

CMMDS: El servicio de Cluster Monitoring Member and Directory Service es el encargado de almacenar
y gestionar la base de datos de los servicios de Directorio en vSAN. Todos los objetos, componentes y
recursos están indexados en la base de datos que se almacena en memoria en cada uno de los Hosts
que son miembros del Cluster. Cada Host del Cluster tendrá su rol para dar servicio a CMMDS, los
cuales pueden ser Master, Backup o Agent. Existirá un único Master, un único Backup y el resto de los
nodos del Cluster funcionarán como Agent.

CLOM: El acrónimo CLOM proviene de Cluster Level Object Manager y es un servicio clave en vSAN
al definir la viabilidad en la creación de objetos, la mejor ubicación posible siguiendo las políticas
asignadas y la distribución más equitativa posible de los objetos entre Fault Domains, Hosts y Disk
Groups.

CLOM gestiona además la recreación y actualización de objetos luego de un fallo. El servicio CLOM no
utiliza la red y se comunica únicamente con las instancias locales de CMMDS y DOM.

DOM: Distributed Object Manager es el nombre del servicio que funciona como nexo entre CLOM y
LSOM. Cada instancia de CLOM se comunica con su instancia local de DOM para enviar la orden de
creación, actualización y/o modificación de los componentes. Cada instancia de DOM gestionará las
peticiones con su servicio local LSOM a quien le enviará esas peticiones recibidas por CLOM. Para
las tareas a ejecutarse en Hosts diferentes, DOM tendrá que comunicarse con la instancia de DOM de
los otros Hosts del Cluster para hacer llegar esas peticiones, las cuales se reenviarán a sus servicios
LSOM locales.

DOM también gestiona lo que se conoce como DOM Client y DOM Owner. El Client será quien se
encargue del envío de operaciones de entrada/salida en nombre de cada VM. Por cada objeto de
vSAN hay un Owner y es quien gestiona lo más parecido a un bloqueo en los accesos a esos objetos
y entrega las rutas a la ubicación de los componentes.

LSOM: El Log Structured Object Manager es el único servicio que trabaja con los discos de los Hosts.
Gestiona tanto los discos de Caché como también los de capacidad y se hace cargo de las tareas
de Destage para mover los datos desde los discos de Caché hacia los de Capacidad. Cuando están
habilitados los servicios de Deduplicación y Compresión se encarga de deduplicar (al momento del
destage) y de comprimir, siempre y cuando sea posible comprimir un bloque de 4K en 2K o menos.

Si el Cluster de vSAN tiene habilitado el servicio de encriptación entonces será LSOM quien se
encargue de encriptar los datos.

Y como si fuera poco también identificará y reportará cualquier tipo de fallo en los discos físicos de los
Disk Groups así como también monitorizará el espacio consumido en cada uno de los discos.

#VMwarePorvExperts 312
Capítulo 7 - vSAN Federico Cinalli

Servicios de arquitectura de vSAN

#VMwarePorvExperts 313
Capítulo 7 - vSAN Federico Cinalli

4. Configuración de un Cluster de vSAN

La configuración de un Cluster de vSAN es una tarea realmente simple. Una vez validado el Hardware
y definido el Diseño, es solo cosa de unos cuantos clicks.

Ante todo debemos recordar y destacar que vSAN es una solución embebida en el Hypervisor, de ahí
que el título de este apartado comience con Configuración en lugar de Instalación.

Repasemos los requerimientos de vSAN:


• Hardware validado (incluyendo Firmwares y Drivers)

• vCenter Server

• vSphere HA

• Port Group de VMKernel en cada Host

• Un Disk Group por Host (al menos los 3 primeros Hosts)

• Licencia de vSAN

Si bien no es un requerimiento, es altamente recomendable que se considere una consistencia en los


Hosts en cuanto a recursos de cómputo y discos locales.

¿Creamos un Cluster de vSAN? Ahí vamos!!!

Paso 1: Creación del Cluster


Para crear y configurar el Cluster de vSAN los servicios de HA deben estar deshabilitados, aunque una
vez finalizado el asistente inicial debemos habilitarlos ya que es un requerimiento.

Al marcar la opción de vSAN y hacer click en Ok, al cabo de unos pocos segundos tendremos los
servicios básicos de vSAN habilitados en el Cluster.

Creando el Cluster de vSAN

#VMwarePorvExperts 314
Capítulo 7 - vSAN Federico Cinalli

A partir de vSphere 6.7 (vSAN 6.7) disponemos del asistente quickstart. El asistente es opcional y nos
permitirá configurar la totalidad de los servicios de vSAN en el Cluster.

A continuación, veremos una configuración sin utilizar el quickstart.

Cluster quickstart en vSphere Client

Paso 2: Configuración de servicios adicionales y parámetros


Si tenemos pensado habilitar los servicios de Deduplicación y Compresión o bien si nuestro diseño
requiere la encriptación del Datastore de vSAN, se recomienda habilitar todas estas opciones antes de
agregar los Hosts o bien antes de crear o migrar máquinas al Datastore de vSAN.

Esta recomendación es debido a que los Disk Groups requerirán un formato especial para cada caso
y es preferible aplicar ese formato cuando no existen todavía componentes.

En nuestro caso habilitaremos Deduplicación y Compresión. Además, dejaremos habilitada la opción


Thin Swap para ahorrar espacio al aplicar el formato Thin Provisioning a los ficheros de Swap. También
habilitamos el Performance Service que nos proveerá de métricas muy útiles que utilizaremos para
monitorizar nuestro Cluster.

(Hablaremos de la opción Site Read Locality en el apartado de Stretched Cluster)

Opciones generales del Cluster de vSAN

Paso 3: Agregar los Hosts y validar configuración


Al agregar los Hosts al Cluster veremos que se crea el vSAN Datastore aunque, al no haber definido

#VMwarePorvExperts 315
Capítulo 7 - vSAN Federico Cinalli

todavía los Disk Groups, su capacidad será de 0 bytes.

Una vez que los Hosts estén agregados al Cluster sería muy bueno esperar un par de minutos y
consultar por primera vez el vSAN Health con el objetivo de verificar que la conectividad de Red está
funcionando correctamente.

vSAN Health con configuraciones de Red validadas

En el vSAN Health deberíamos verificar también que las controladoras de discos, firmwares y drivers
están validados. Es posible que tengamos que hacer una actualización o incluso un downgrade de
algún driver. Es el momento de dejar todo a punto (pintar todo de verde!) según lo que requiere el
vSAN Health antes de continuar.

Esto es especialmente importante si no queremos tener problemas a la hora de llamar al soporte de


VMware, ya que comenzarán revisando qué tan verde está nuestro vSAN Health.

Una vez que todo está validado es momento de proceder con la creación de los Disk Groups y hacer
que el vSAN Datastore comience a sumar capacidad disponible.

Paso 4: Creando los Disk Groups


Este proceso es muy simple, solo tenemos que ir Host por Host y seleccionar los discos que serán
parte de cada Disk Group según el Diseño.

Si seleccionamos el Cluster, Configuración y en vSAN hacemos click en Disk Management podremos


configurar los Disk Groups de cada Host.

#VMwarePorvExperts 316
Capítulo 7 - vSAN Federico Cinalli

Configuración de Disk Groups en el Cluster

Creando un Disk Group en un Host

Ejecutamos el mismo proceso en cada uno de los Hosts del Cluster. El tiempo que requerirá la creación
de cada Disk Group dependerá de la cantidad de discos y su capacidad, pero hablamos de solo unos
pocos minutos.

Una vez finalizada la creación del último Disk Group ya podemos confirmar que nuestro Datastore de
vSAN dispone de capacidad utilizable.

En este punto ya estamos listos para migrar máquinas o bien crear nuevas sobre nuestro flamante
Datastore de vSAN. ¿Fácil verdad?

#VMwarePorvExperts 317
Capítulo 7 - vSAN Federico Cinalli

5. Políticas de vSAN

Mencionamos varias veces que vSAN se gestiona a través de las Políticas. En realidad, lo que
gestionamos a través de las políticas de vSAN son los objetos de máquina virtual y, una vez asignada
una política, esos objetos están representados en los Disk Groups de los Hosts como Componentes.
A veces son llamados Réplica Components (normalmente en mirroring), otras Data Components (en
Erasure coding) o incluso simplemente Componentes.

Los niveles de tolerancia a fallos en Almacenamiento, consumo de espacio, nivel de RAID y rendimiento
van a depender de la combinación de reglas que definamos en la política asignada al Objeto. O
diciéndolo de otra forma, las reglas de una política van a impactar en el consumo, rendimiento y
tolerancia a fallos.

Por ejemplo, si seleccionamos RAID 1 consumiremos más espacio que con RAID 5, pero a nivel de
rendimiento será mejor RAID 1 debido a que no es necesario el cálculo de paridad.

También existen reglas dentro de las Políticas que permiten crear reserva de espacio en disco, lo cual
supone un mayor consumo de espacio.

Máquinas, Objetos, Políticas y Componentes

vSAN dispone de varias reglas de Políticas en su versión 6.7. Particularmente en la versión 6.7 tenemos
que tener en cuenta que las reglas se verán diferentes (bastante diferentes) al utilizar vSphere Web
Client o vSphere Client.

#VMwarePorvExperts 318
Capítulo 7 - vSAN Federico Cinalli

Política vSAN con RAID 1 en vSphere Web Client

Política vSAN con RAID 1 en vSphere Client

La recomendación es utilizar vSphere Client ya que será el único cliente en las próximas versiones,
por lo cual en este capítulo utilizaremos ese cliente para revisar las reglas. Veamos cómo funciona y
en qué caso aplica cada regla.

Site disaster tolerance: Si configuramos vSAN Stretched Cluster utilizaremos esta regla en la política
de vSAN para asignar a los objetos de las máquinas virtuales que queremos brindar protección entre
sites. La opción es “Dual site mirroring (stretched cluster)”.

Las otras opciones nos permiten definir protección a nivel de Fault Domains y también seleccionar un
Site de preferencia para los componentes de máquinas en caso que no exista una protección entre
sites. A esto se le aplica el “Site Read Locality” y debe estar configurado a nivel de Cluster de vSAN,
en opciones avanzadas.

Configuración de tolerancia a fallos entre Sites

#VMwarePorvExperts 319
Capítulo 7 - vSAN Federico Cinalli

Fallos a Tolerar (antes PFTT): Como su nombre lo indica es el número de fallos que vamos a tolerar.
Cualquier tipo de error que impacte en el acceso al componente contará como un fallo, incluyendo la
puesta en mantenimiento de un Host.

Las opciones disponibles nos permiten configurar la regla para no disponer de redundancia (RAID 0),
protección contra un fallo (RAID 1 y RAID 5), tolerancia de dos fallos (RAID 1 o RAID 6) y soporte para
protección ante tres fallos (RAID 1).

Las opciones de Mirroring con protección contra dos fallos tendrán 3 réplicas y las que toleren hasta
tres fallos contarán con 4 réplicas.

Definiendo la tolerancia a fallos

Número de componentes por disco: opción por defecto 1 y un máximo de 12, aplica únicamente
en vSAN Híbrido con el objetivo de distribuir los componentes entre múltiples discos y de esa forma
obtener un mayor número de IOPS.

Número de discos en los que se distribuirá el componente

Límite de IOPS por objeto: El valor por defecto es 0 (sin límite). Este valor podría aplicar para crear
una especie de “Tiers virtuales” definiendo 2 o más niveles de rendimiento a través de estos límites.

vSAN considera un IOP(s) a una petición de hasta 32K. Si hubiera una petición de 64K entonces sería
considerado como 2 IOPS.

¿Y si hubiese 4 peticiones de 4K? vSAN las gestionará como 4 IOPS diferentes.

#VMwarePorvExperts 320
Capítulo 7 - vSAN Federico Cinalli

Configuración del límite de IOPS

Reserva de espacio por objeto: por defecto se utiliza thin provisioning, lo que supone que no hay
ningún tipo de reserva. Existe la posibilidad de reservar el espacio en el vSAN Datastore para una parte
o incluso la totalidad del componente (25% - 50% - 75% - Thick provisioning). Esta regla cambiará el
formato thin provisioning del objeto a un thick provisioning lazy zeroed (sin inicializar los bloques) lo
cual incrementará el consumo del Datastore de vSAN producto de la capacidad reservada.

Formato y reserva de espacio para objeto

TIP: Evitar a toda costa crear una reserva de espacio en la política de vSAN por defecto. No vamos a
querer ver el resultado, sobre todo si ya estamos en producción ;-)

Reserva de Flash Read Cache: esta reserva aplica únicamente a vSAN Híbrido y se utiliza para
asignar/reservar una determinada capacidad del objeto para ser almacenada en los discos de caché
del Disk Group con el fin de mejorar el ratio de acierto en caché.

Deshabilitar el Object Checksum: por defecto se le aplica el proceso de validación de escritura a


cada dato que se escribe. Existen algunas aplicaciones, normalmente bases de datos, que realizan
su propio checksum. Es en esos casos cuando definimos la política con esta regla para “deshabilitar”
el Object Checksum con el fin de mejorar el rendimiento evitando una doble comprobación, aunque la
diferencia puede llegar a ser apenas perceptible.

Vale aclarar que no se recomienda deshabilitar el Object Checksum.

Reglas avanzadas en política de vSAN

Forzar el aprovisionamiento: cuando creamos una nueva máquina virtual y/o algún objeto en vSAN,
el servicio CLOM validará que ese objeto estará en modo “compliance” según la política asignada.
Si por algún motivo no disponemos de la mínima cantidad de recursos (por ejemplo, un Host en
mantenimiento) el proceso de creación del objeto no continuará debido a la regla por defecto.

Si queremos forzar la creación de esos objetos por más que el estado sea “non compliance” entonces

#VMwarePorvExperts 321
Capítulo 7 - vSAN Federico Cinalli

configuraremos la regla para que la opción Force Provisioning sea “Yes”.

Regla de vSAN para forzar el aprovisionamiento

Comparando métodos de protección


La siguiente tabla es una excelente comparativa de las diferentes opciones a utilizar para tolerar fallos
con sus correspondientes métodos.

Componentes Objetos Erasure Coding Mínimo de


Fallos a tolerar Protección
Replica/Data Witness vs Mirror Hosts
0 RAID 0 1 0 - 3
1 RAID 1 2 1* - 3
1 RAID 5 4 0 33% menos 4
2 RAID 1 3 2* - 5
2 RAID 6 6 0 50% menos 6
3 RAID 1 4 3* - 7
Tabla comparativa de opciones y métodos de protección

*El número de objetos Witness se crea automáticamente dependiendo de varios factores como número
y tamaño de objetos, número de hosts y opciones en las reglas de la política.

Gestión de Políticas de vSAN


Una vez diseñado, implementado y validado el primer Cluster de vSAN pasamos a la configuración de
las políticas. A través de las políticas de vSAN definiremos aspectos tan importantes como la protección
ante fallos, el consumo del espacio en disco, rendimiento y otros aspectos que nos permiten adaptar
los servicios de almacenamiento a las diferentes cargas de trabajo a nivel de objeto de máquina virtual.

Una vez definidas esas políticas, las cuales se crean a nivel de vCenter, es hora de mover máquinas
al Cluster de vSAN. Da igual si vamos a crear máquinas nuevas o si estamos migrando máquinas
existentes al Datastore de vSAN, siempre tendremos que asignar una política.

#VMwarePorvExperts 322
Capítulo 7 - vSAN Federico Cinalli

Asignación de política en nueva máquina virtual

Todo objeto de máquina virtual que esté almacenado en un Datastore de vSAN deberá tener asignada
su política correspondiente. Por cada Cluster de vSAN tendremos una política por defecto.

La recomendación es NO modificar la política de vSAN por defecto.

Siempre podemos crear una nueva política con las reglas que necesitemos.

Ahora la pregunta es, una vez que tenemos máquinas y políticas, ¿cuáles son las opciones de gestión?
La respuesta es bien simple. Las políticas se pueden modificar según necesitemos y también es posible
cambiar (reasignar) una política a alguno o a todos los objetos de una máquina virtual. Veamos los dos
casos.

Cambiando una política a los objetos de una máquina virtual


Por diferentes motivos tal vez necesitemos cambiar una política a uno o todos los objetos de una
máquina virtual. A continuación, veremos una captura de una VM con todos los objetos trabajando con
la política de vSAN por defecto.

Visualizando la política de una VM

#VMwarePorvExperts 323
Capítulo 7 - vSAN Federico Cinalli

Objetos de máquina virtual con la política de vSAN por defecto

Para cambiar la política a los objetos de una VM simplemente tenemos que seleccionar la VM en el
inventario de vCenter con el botón contextual, VM Policies y Edit VM Storage Policies.

Editando las políticas de una VM en vSAN

En la ventana de edición de políticas de almacenamiento tendremos disponible la opción de configurar


una política por disco (Aunque el nombre correcto debería ser objeto. Te perdonamos VMware ;-).

#VMwarePorvExperts 324
Capítulo 7 - vSAN Federico Cinalli

Asignando una política por objeto de máquina

Una vez que asignamos una política diferente veremos el impacto en los cambios. En este caso hemos
cambiado RAID 1 por RAID 5 con su correspondiente ahorro en el consumo de almacenamiento.

Impacto en la reasignación de política

Al cambiar la política debemos tener en cuenta el potencial impacto que generará el cambio. Un
impacto podría ser el mayor consumo de espacio, ya sea temporal o permanente. Y otro impacto serán
las operaciones de I/O al necesitar (no siempre) recrear un componente.

#VMwarePorvExperts 325
Capítulo 7 - vSAN Federico Cinalli

Máquina con nuevos componentes en RAID 5

Cambiando reglas en Política de vSAN


Otra opción de cambios en políticas asignadas a una o varias VMs es la de editar/cambiar una política
de vSAN que ya esté asignada a uno o múltiples objetos de máquinas virtuales.

En este punto tenemos que ser muy conscientes del impacto que podemos generar.

Existen múltiples cambios en políticas que requieren la recreación de componentes.

Cambios en políticas que requieren recreación de componentes:


• Cambio de RAID 1 a RAID 5

• Cambio de RAID 1 a RAID 6

• Cambio de RAID 5 a RAID 6

• Cambio de RAID 5 a RAID 1

• Cambio de RAID 6 a RAID 5

• Cambio de RAID 6 a RAID 1

• Cambio número de objetos por componente (disk stripes per object)

• Reserva de espacio en objeto

• Cambio o asignación de reserva en Flash Read Cache

Como hemos podido observar existe un número importante de cambios que requieren la recreación de
componentes. Esos cambios van a generar operaciones adicionales de I/O, consumo de caché, tráfico
de red y consumo de espacio adicional de disco mientras se ejecutan los cambios.

Por lo tanto, debemos ser conscientes del impacto a generar, sobre todo cuando estamos cambiando
reglas en una política asignada a objetos de múltiples máquinas virtuales.

Para cambiar una regla en una política de vSAN simplemente tenemos que seleccionar la política en
Policies and Profiles/VM Storage Policies y hacer clic en Editar o Edit Settings. Una vez aplicados los
cambios en la política y finalizado el asistente veremos una ventana como la siguiente:

#VMwarePorvExperts 326
Capítulo 7 - vSAN Federico Cinalli

Solicitud de confirmación de aplicación de cambios en política

Como hemos visto disponemos de dos opciones. Una es aplicar los cambios inmediatamente,
generando el impacto que hemos comentado en todos los objetos afectados al mismo tiempo.

La otra opción sería seleccionar que queremos aplicar los cambios de forma manual más adelante.
Esto podemos hacerlo máquina por máquina o, en caso que tengamos un número considerable de
máquinas en el inventario, considerar el uso de PowerCLI para seleccionar las VMs y aplicar los
cambios de forma gradual.

Al seleccionar la opción de aplicar los cambios más adelante, podremos visualizar la lista de VMs con
objetos pendientes de aplicar los cambios. El estado de compliance de la máquina será “Out of Date”.

Política pendiente de asignar en VM

Y en caso de desear aplicar los cambios en la política de forma manual solo tendremos que seleccionar

#VMwarePorvExperts 327
Capítulo 7 - vSAN Federico Cinalli

la máquina, Configure y hacer clic en Reaplicar política (Reapply VM Storage Policy).

Compliance Out of Date

Por último, recordar que las políticas pueden ser cambiadas y editadas por más que las máquinas
estén encendidas. El impacto será mayor o menor dependiendo tanto de los recursos disponibles
como también de la cantidad y tamaño de componentes a recrear.

Se recomienda antes de aplicar un cambio de política verificar si el Cluster está recreando o poniendo
al día componentes. Aprenderemos cómo hacer esto más adelante.

#VMwarePorvExperts 328
Capítulo 7 - vSAN Federico Cinalli

6. Stretched Cluster, 2 Node Cluster y Fault Domains

Con la versión 6.0 de vSAN llegaba All-Flash para entrar de lleno a dar servicios para aplicaciones
críticas con una cantidad industrial de IOPS. La misma versión 6.0 nos traía otra novedad con el
nombre de Fault Domains (o dominios de fallo) en el que podemos crear grupos de Hosts, distribuidos
en diferentes racks, con el objetivo de incrementar la disponibilidad en caso de fallo general a nivel de
rack.

Por otra parte la versión 6.1 presentó vSAN Stretched Cluster para incrementar la disponibilidad entre
dos ubicaciones diferentes en donde estarán grupos de Hosts replicando objetos entre sí.

A partir de la misma versión de vSAN (6.1) nos permite además cubrir las necesidades de otro caso
de uso como lo son oficinas remotas en donde 2 Hosts comparten almacenamiento y ofrecen alta
disponibilidad.

vSAN Fault Domains


El objetivo de Fault Domains es distribuir las réplicas de componentes a través de Disk Groups de
Hosts que estén en diferentes zonas, o dominios de fallo.

Como mencionábamos anteriormente el principal caso de uso es la protección ante fallos generales
a nivel de rack. No obstante también es posible aplicar esta misma protección dentro de un mismo
rack para minimizar el impacto en una situación potencial de más de un Host que compartan el mismo
chasis.

La configuración de Fault Domains es francamente simple. Únicamente necesitamos definir los objetos
lógicos de cada Fault Domain y asociar el o los Hosts a cada FD.

Creación de Fault Domain en Cluster

La cantidad mínima de Fault Domains va a estar asociada al tipo de protección a aplicar en las políticas
del Cluster. Por ejemplo, si aplicaremos una política con una regla que define una protección que utiliza
RAID 5, entonces necesitaremos 4 Fault Domains. Para RAID 6, 6 Dominios de fallo serán necesarios.

Una vez creados los Fault Domains los componentes se distribuirán automáticamente a través de los

#VMwarePorvExperts 329
Capítulo 7 - vSAN Federico Cinalli

Disk Groups de cada Host en cada FD según la política aplicada.

Vista de Cluster con Fault Domain configurado

4 Dominios de fallo con Componentes distribuidos

Por último, debemos comentar que únicamente es posible configurar Fault Domains siempre y cuando
no hayamos habilitado Stretched Cluster o 2 Node Cluster debido a que estas dos soluciones utilizan
ya de por sí el concepto de Fault Domains.

Stretched Clusters
Cuando se trata de incrementar la disponibilidad de las aplicaciones, ya sea a nivel de Computo, Red
o Almacenamiento, los objetivos se alinean con la simplicidad y los requerimientos con la fiabilidad.

vSAN Stretched Cluster aporta simplicidad, fiabilidad y resiliencia.

Un Stretched Cluster de vSAN puede escalar hasta 15 Hosts por sitio y, a través de las políticas de
vSAN, es posible seleccionar las máquinas con sus objetos a los que queremos aportar protección.

Comencemos con la lista de requerimientos.

#VMwarePorvExperts 330
Capítulo 7 - vSAN Federico Cinalli

Requerimientos de vSAN Stretched Cluster:

• Mínimo de 1 Host por Site

• Máximo de 15 Hosts por Site*

• Witness Host en un tercer Site (normalmente es un virtual appliance)

• Conectividad de 10 Gbps entre el Site Primario y el Secundario en capa 2

• Latencia máxima de 5ms Roundtrip entre el Site Primario y el Secundario

• Conectividad de 2 Mbps por cada 1000 objetos entre los Sites de Datos y el Witness Host

• Latencia máxima de 100ms (o superior en algunos casos) entre los Sites de Datos y el Witness
Host

• Licencia vSAN Enterprise

*Es posible trabajar con un número superior de Hosts por Site en VMC on AWS.

En base a los requerimientos podemos ver que el concepto de “Site” puede ser algo relativo. Conectar
2 Sites que estén separados por varios kilómetros y cumplir con el requerimiento de no más de 5
milisegundos de latencia puede ser algo complicado. O al menos la factura de la fibra será cuanto
menos elevada.

Esto hace que tal vez reconsideremos el concepto de Site y lo traslademos a algo como Campus,
Edificio o diferentes ubicaciones físicas que permitan cumplir con los requerimientos.

Respecto a los requerimientos del tercer Site para el Witness, también llamado Witness Site, claramente
son más relajados. Incluso cada día más y más empresas utilizan recursos de Cloud Publica para
hostear sus Witness Hosts.

El Witness Host puede ser un Host físico o bien un virtual Appliance que podemos descargar en
formato OVA.

Veamos todos los pasos para configurar un Cluster de vSAN en Stretched Cluster.

1. Despliegue de Appliance

Una vez descargado el OVA del Witness Appliance procedemos con el despliegue. La versión del OVA
debe ser la misma que la de los Hosts del Cluster.

#VMwarePorvExperts 331
Capítulo 7 - vSAN Federico Cinalli

Desplegando Witness Appliance

Las opciones son las normales de cualquier Appliance.

Desplegando Witness Appliance

Debemos seleccionar el tamaño de la VM del Witness Host. Eso dependerá de la cantidad de máquinas
a proteger como podemos apreciar en la siguiente captura.

#VMwarePorvExperts 332
Capítulo 7 - vSAN Federico Cinalli

Definiendo el tamaño del Witness Host

Y otra parte importante es la asignación de redes. Como podemos ver en la siguiente captura, existen
dos redes. Una es para los servicios de Management, al igual que un ESXi tenemos que conectar a la
misma red de vCenter y Hosts, aunque en este caso podría ser una conexión tanto de capa 2 como
de capa 3, es decir, enrutada.

Asignando redes a los servicios del Appliance

Una vez que finalizamos con el asistente del Appliance tendremos una máquina virtual como cualquier
otra. La diferencia es que esta VM es un ESXi virtualizado o, como suele decirse, en modo nested.

#VMwarePorvExperts 333
Capítulo 7 - vSAN Federico Cinalli

vSAN Witness desplegado

Importante: La máquina virtual del vSAN Appliance deberá operar sobre un Host que no forme parte
de un Cluster de vSAN.

2. Configuración del Appliance

La siguiente tarea será encender el Witness Host y configurar los servicios de red. Al igual que con
cualquier otro ESXi necesitaremos definir un registro DNS de tipo A y otro PTR asociado a la IP que le
asignaremos.

Como hemos mencionado, esa IP será la dirección de Management del Witness Host y el vCenter
tendrá que ser capaz de resolver el hostname como también llegar a la dirección IP asignada.

Witness Host con Management configurado

3. Agregando el Witness Host al inventario

El ESXi virtual que da servicio al Witness Host tiene que estar agregado al inventario del mismo
vCenter que da servicio al Cluster de vSAN.

Podremos ver que el Host virtual se diferencia del resto al utilizar un color azul claro o celeste.

#VMwarePorvExperts 334
Capítulo 7 - vSAN Federico Cinalli

Witness Host en el Inventario de vCenter

4. Configuración del servicio Stretched Cluster

Llegados a este punto ya hemos cumplido con los requerimientos previos a la configuración. Siempre
y cuando no tengamos configurado ningún Fault Domain, podremos hacer click en el botón Configure
para comenzar con el asistente de configuración.

El asistente es muy simple como veremos a continuación.

Cluster de vSAN listo para configurar el servicio Stretched Cluster

Lo primero será definir los Hosts que funcionarán en el Site preferido y los que operarán en el Site
secundario.

Asignando Hosts a cada Site

Lo siguiente es seleccionar el Witness Appliance que tenemos disponible en el inventario de nuestro


vCenter.

#VMwarePorvExperts 335
Capítulo 7 - vSAN Federico Cinalli

Vale aclarar que un Witness Appliance únicamente podrá dar servicio a un Stretched Cluster en
particular.

Asignando el Witness Host al Cluster

Como parte de la configuración del Stretched Cluster es necesario crear un Disk Group en el Witness
Host.

El Witness Host almacenará los componentes Witness de los objetos pertenecientes a las máquinas
protegidas con Stretched Cluster.

Creando el Disk Group en el Witness Host

Y una vez que visualizamos el resumen de la configuración, al hacer click en finalizar comenzará el
proceso de creación o conversión de nuestro vSAN a Stretched Cluster.

Si estamos ejecutando el Quickstart entonces creará el Cluster como Stretched. Y si nuestro Cluster ya
está operando con los servicios de vSAN, se convertirá el servicio para que opere en modo Stretched
Cluster.

#VMwarePorvExperts 336
Capítulo 7 - vSAN Federico Cinalli

Habilitando los servicios de Stretched Cluster

Una vez finalizado el proceso ya podremos ver cómo queda el servicio Stretched Cluster en la consola
de vSphere Client.

Vista de la consola de vSAN Stretched Cluster

A partir de ahora simplemente tendremos que asignar la política correspondiente a los objetos de las
máquinas que queremos proteger a nivel de Site.

Políticas de vSAN para definir protección a nivel de Site

En las políticas podemos ver varias opciones, las cuales explicaremos a continuación.

None – standard cluster: No protegemos los objetos con Stretched Cluster.

None – standard cluster with nested fault domains: Utilizaremos Fault Domain para protección,
aunque tampoco a nivel de Site.

Dual site mirroring (stretched Cluster): Se protegerán los objetos de la máquina a través de Sites

#VMwarePorvExperts 337
Capítulo 7 - vSAN Federico Cinalli

pero no definimos ningún Site en particular. Dependerá de la carga de cada Site o bien de las reglas
de DRS si es que las configuramos.

None – keep data on Preferred (stretched cluster): No se protegen los objetos de la máquina con
Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los Hosts
pertenecientes al Site Preferred.

None – keep data on Non-preferred (stretched cluster): No se protegen los objetos de la máquina
con Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los
Hosts pertenecientes al Site Non-preferred.

None – stretched cluster: No se protegen los objetos de la máquina con Stretched Cluster y el propio
Cluster, en base al espacio disponible, seleccionará el Site con menor consumo para balancear la
carga y que los componentes residan en los Disk Groups del Site seleccionado.

Site Read Locality: esta opción está disponible a partir de vSAN 6.7 y la podemos habilitar o deshabilitar
seleccionando el Cluster, en Configuración, Servicios y Opciones Avanzadas.

El objetivo es consumir un menor ancho de banda entre los Sites al ejecutar las operaciones de lectura
únicamente en los Disk Groups del Site en donde se está ejecutando la VM (recursos de computo).

Reglas DRS afinidad VM-Host: otra configuración muy común es la creación de grupos de Máquina
y Hosts para definir una afinidad. Al aplicar estas reglas de DRS, las máquinas funcionarán,
preferiblemente, los recursos de cómputo del grupo de Hosts del Site preferido o no-preferido, según
hayamos configurado la regla.

Esta es otra forma de acercar las máquinas a consumidores de recursos localizados en un Site concreto
y también en cierta forma a balancear la carga.

Clusters de 2 Nodos
Habiendo cubierto ya los servicios de Stretched Cluster únicamente nos quedaría explicar la diferencia
entre 2 Node Cluster y Stretched Cluster.

Los Clusters de 2 Nodos no tienen por qué operar en Sites diferentes. Está soportado un Stretched
Cluster de 2 Nodos y también un mini-cluster de 2 Nodos de vSAN que funcionen en el mismo Site.

Cluster ROBO de 2 Nodos

La configuración es prácticamente igual debido a que seguimos necesitando un Witness Host y la


configuración es en la misma ubicación del vSphere Client.

En cuanto a reglas, si estamos trabajando con un Cluster de 2 Nodos sin Stretched, la única política
de protección que podemos aplicar es RAID 1 y, al igual que en SC, los Witness components se

#VMwarePorvExperts 338
Capítulo 7 - vSAN Federico Cinalli

almacenarán en el Witness Host.

Cluster de 2 Nodos en modo Stretched

Una opción muy interesante que está únicamente disponible en los Clusters de 2 Nodos que operan en
el mismo sitio es que podemos utilizar un cable cruzado para conectar las vmnics que dan servicio a
los puertos VMKernel de vSAN. Esto nos evita tener que invertir en un Switch de 10Gbps por ejemplo.

Cuántos litros de cerveza podríamos comprar con lo que ahorramos en dos Switches de 10Gbps?

Y la última diferencia considerable es la licencia. Existe un paquete de licencias para Clusters de 2


Nodos que se llama ROBO, aunque no aplica a Stretched Cluster.

No obstante, también es posible licenciar un Cluster de 2 Nodos, con o sin Stretched, utilizando el
licenciamiento normal de vSAN que aplica a nivel de procesador físico o socket.

#VMwarePorvExperts 339
Capítulo 7 - vSAN Federico Cinalli

7. Componentes y fallos en vSAN

En este apartado revisaremos los diferentes tipos de fallos y cómo afectan a los componentes.
Dependiendo el tipo de fallo, los componentes se mostrarán en un estado u otro, así como también las
acciones a ejecutar por parte de vSAN pueden ser variadas.

Comencemos con los diferentes estados en que puede estar un componente:

Active: El componente está funcionando correctamente.

Absent: No hay acceso al componente y vSAN no sabe qué ocurrió. Puede deberse a un fallo de red,
un host caído, fallo de disco o un host en mantenimiento. El sistema esperará 60 minutos hasta que se
recupere el error y una vez pasado ese tiempo, en caso que el componente continúe en modo Absent,
vSAN recreará el componente de forma automática.

Degraded: El estado degradado indica que vSAN confirma un fallo, probablemente en uno de los discos
o incluso en la controladora. De forma inmediata comenzará el proceso de recreación de componente.

Reconfiguring: Ése será el estado del componente mientras se está aplicando una reconfiguración
debido a un cambio en una política que requiere aplicar cambios en los componentes.

A la hora de trabajar con un cluster de vSAN lo primero que debemos comprender es cómo el Cluster
entiende y gestiona los fallos.

Muy probablemente sepamos que si el Host está en modo mantenimiento no será capaz de proveer
servicios de cómputo a máquinas virtuales. De la misma forma, en un Cluster de vSAN, un Host
en modo mantenimiento no proveerá servicios de Almacenamiento. Veremos más adelante cómo
gestionar las operaciones en un Cluster de vSAN pero centremos la atención ahora mismo en ver
cómo impactan en los componentes los diferentes tipos de errores y/o operaciones.

Fallo Estado Componente Alcance fallo Recreación


Todos los componentes
Host en Mantenimiento Absent A partir de los 60 minutos
del Host
Todos los componentes
Host Absent A partir de los 60 minutos
del Host
Todos los componentes
Red (Host aislado) Absent A partir de los 60 minutos
del Host
Controladora Degraded Todos los discos del Host Inmediatamente
Disco Caché Degraded Disk Group Inmediatamente
Disco Capacidad (sin
Degraded Componentes en disco Inmediatamente
deduplicación)
Disco Capacidad (con
Degraded Disk Group Inmediatamente
deduplicación)

Tabla comparativa de fallos y estados

Recreación automática a partir de los 60 minutos

El servicio CLOM gestiona lo que se conoce como CLOM repair delay. Cada vez que un componente
está en modo Absent el servicio CLOM da un margen para que el componente se recupere o vuelva a la

#VMwarePorvExperts 340
Capítulo 7 - vSAN Federico Cinalli

vida sin más. Debemos tener en cuenta que hay veces que existen pequeños fallos de comunicación o
bien un reinicio de un Host (controlado o no) hará que un componente esté en modo Absent. Para evitar
la recreación completa del componente y su correspondiente impacto en consumo de recursos, vSAN
gestiona el CLOM repair delay. El valor de ese parámetro son 60 minutos por defecto y confirmamos
que es posible cambiarlo.

En Opciones avanzadas del Cluster es posible modificar el valor de Object Repair Timer

Si pasados los 60 minutos el componente sigue en modo Absent, CLOM se encargará de recrear
automáticamente todos los componentes que hagan falta para mantener los Objetos en modo compliant.

También puede darse el caso que, pasados unos minutos sin llegar a 60, el recurso con el fallo se
recupera. En ese caso tendremos un componente desactualizado y será CLOM quien se encargue de
comenzar con el proceso de actualización o resincronización, también automáticamente.

Absent o Degraded?

Dependerá del tipo de fallo si el estado de un componente es Absent o Degraded. Existen casos de fallos
de Hardware que dejan el disco en Absent cuando en realidad tiene un fallo total. Por otra parte cuando
el Host tiene la certeza de un fallo en un disco o controladora, normalmente pone los componentes en
modo Degraded y es ahí cuando la recreación de los componentes comienza inmediatamente.

Fallo en discos de Caché

El producirse un fallo en un disco de Caché el impacto inmediato es que perderemos el Disk Group
entero. Esto es así debido a que el disco de caché aporta rendimiento y resiliencia en cuanto a
operaciones de escritura.

Existirán casos en que un disco pueda recuperarse y tal vez el Disk Group vuelva a la vida (con los
componentes desactualizados) pero en la gran mayoría de los casos tendremos que reemplazar el
disco y recrear el Disk Group nuevamente.

Fallo en disco de Capacidad sin deduplicación y compresión habilitada

Otro fallo potencial puede producirse en un disco de capacidad. Si la deduplicación y compresión no


está habilitada en el Cluster de vSAN, entonces el fallo únicamente impactará en los componentes que
estuvieran almacenados en el disco en cuestión.

Una vez más, si el Host tiene la certeza del fallo del disco, los componentes pasarán a un estado

#VMwarePorvExperts 341
Capítulo 7 - vSAN Federico Cinalli

Degraded con su correspondiente recreación de componentes de forma inmediata.

Y si el Host desconoce el estado del disco con fallos o bien alguien decide retirar el disco físico para
pasarle un plumero, los componentes pasarán a un estado Absent y comenzará la cuenta regresiva de
los minutos definidos en el CLOM repair delay.

Fallo en disco de Capacidad con deduplicación y compresión habilitada

Si el Host identifica un fallo en un disco de capacidad y el servicio de deduplicación y compresión está


habilitado en el Cluster de vSAN, todo el Disk Group fallará. Esto es así debido a que tanto el disco de
caché como todos los discos de capacidad del Disk Group comparten el mismo hash para trabajar con
la deduplicación y compresión lo cual genera una dependencia de unos con otros.

En caso de pérdida del Disk Group todos los componentes del mismo se recrearán automáticamente.
Evidentemente la recreación dependerá de la existencia de recursos disponibles.

#VMwarePorvExperts 342
Capítulo 7 - vSAN Federico Cinalli

8. Mantenimiento en Clusters de vSAN

Existen múltiples situaciones en que necesitamos poner un Host en modo mantenimiento, reiniciarlo o
incluso mantenerlo apagado durante un período de tiempo determinado.

A partir de que un Host forma parte de un Cluster de vSAN aportando recursos de almacenamiento las
diferentes operaciones que hemos mencionado deben gestionarse con mucho cuidado, incluso con
criterio.

Cambia el concepto y la forma de gestionar ciertas tareas debido a que un Host en modo mantenimiento,
al igual que ocurre con los recursos de cómputo, no proveerá servicios de almacenamiento.

A continuación, aprenderemos las opciones disponibles cuando ponemos un Host en modo


mantenimiento.

En este punto debemos recordar que, si ponemos un Host en modo mantenimiento y no migramos los
datos, aquellos componentes que permanezcan en el Disk Group pasarán a estar en modo Absent, lo
que supone un fallo, aunque se trate de una operación controlada.

Dependerá de las reglas de tolerancia a fallos que una máquina continúe operativa, aún en modo non-
compliant, luego de poner el Host en modo mantenimiento.

Las tres opciones disponibles son:

• Asegurar accesibilidad (Ensure accesibility) -por defecto-

• Migrar todos los datos (Full data migration)

• No migrar datos (No data migration)

Asegurar accesibilidad

Es la opción por defecto cuando ponemos un Host de vSAN en modo mantenimiento.

El Host identificará todos los componentes que pertenezcan a objetos que no podrían continuar
trabajando en caso de poner el Host en modo mantenimiento.

Esos objetos se recrearán en Disk Groups de Hosts diferentes para mantener la diponibilidad, siempre
y cuando existan recursos disponibles en el Cluster siguiendo las reglas de la política aplicada a los
objetos.

#VMwarePorvExperts 343
Capítulo 7 - vSAN Federico Cinalli

Opción asegurar disponibilidad

Esta opción nos permite agilizar la puesta del Host en mantenimiento a costa de asumir el riesgo de
tener objetos de máquinas en modo non-compliant.

En caso que el Host no esté nuevamente operativo pasados 60 minutos, todos los componentes que
estaban en estado Absent se recrearán automáticamente en otros Disk Groups del Cluster.

Migrar todos los datos

Al seleccionar esta opción la totalidad de los componentes serán recreados en los Disk Groups de
otros Hosts. Evidentemente el impacto que genera esta acción dependerá de la cantidad y tamaño de
los componentes, pero seguramente generaremos un impacto considerable en las operaciones de I/O.

Esta opción es la que tenemos que elegir cuando un Host estará más de una hora en modo mantenimiento
o bien cuando retiraremos el Host del Cluster.

Migración completa en Host en mantenimiento

No migrar los datos

Esta última opción la utilizamos normalmente cuando tenemos la total certeza de que todas las
máquinas y sus objetos tienen una política que, al menos, tolerará un fallo. De esta forma todas las
máquinas con sus objetos continuarán estando operativos. Evidentemente esta opción no consumirá
recursos de red ni de disco al no recrear ningún componente.

Al igual que en la opción Asegurar accesibilidad, si no ponemos en producción el Host en menos de


60 minutos, los componentes en estado Absent se recrearán automáticamente en otros Disk Groups
del Cluster.

#VMwarePorvExperts 344
Capítulo 7 - vSAN Federico Cinalli

No migrar los datos en Host en mantenimiento

Debajo de la opción No data migration podremos ver el número de objetos que no continuarán en
modo compliant.

#VMwarePorvExperts 345
Capítulo 7 - vSAN Federico Cinalli

9. Monitorización de vSAN

La gestión del Cluster de vSAN se caracteriza por la simplicidad de su día a día. La creación, edición
y asignación de Políticas es una parte importante en la vida de un Cluster de vSAN, aunque la verdad
es que los cambios en las Políticas no tendrían por qué ser muy frecuentes.

También las operaciones de mantenimiento de los Hosts requieren su atención, así como también
un posible recambio de componentes de Hardware con fallos como pueden ser un disco de Caché,
Capacidad o incluso una controladora.

La monitorización de un Cluster de vSAN es clave para mantener una infraestructura operativa y


minimizar situaciones desagradables que pueden ser evitadas. Además, tener controlada tanto la
capacidad (consumida y disponible) como también el rendimiento es parte del día a día de un buen
administrador de vSphere.

Existen múltiples herramientas que podremos utilizar para monitorizar nuestros Clusters de vSAN las
cuales analizaremos a continuación.

Herramientas disponibles para monitorizar Clusters de vSAN

• vSphere Client

• Ruby vSphere Console

• ESXCLI

• vRealize Operations Manager (vSAN Management Pack)

• vRealize Log Insight (vSAN Content Pack)

• PowerCLI

vSphere Client

Esta herramienta es, sin lugar a dudas, la más apropiada a la hora de monitorizar un Cluster de vSAN.
Gracias al vSAN Health Check seremos capaces de identificar cualquier tipo de fallo sea en el nivel
que sea. Incluso no importa si disponemos del stack completo de VMware en el cual disponemos de
soluciones como vRealize Operations Manager y Log Insight. vSphere nos proporcionará de forma
simple todo lo que necesitamos en un mismo sitio.

La información provista por vSAN Health Check está organizada por capas como son los Objetos, la
Red, el Hardware, etc,

#VMwarePorvExperts 346
Capítulo 7 - vSAN Federico Cinalli

Vista de vSAN Health Check en vSphere Client

Evidentemente la perfección no existe y debemos identificar los límites de este health check. La versión
gráfica opera sobre vCenter, por lo cual tenemos una dependencia con este servicio. La buena noticia
es que seremos capaces de obtener la misma información por línea de comandos e incluso a través
de un único Host, pero esto lo veremos más adelante en ESXCLI.

Tampoco seremos capaces de organizar vistas personalizadas o crear reportes. Ése trabajo se
lo dejamos al especialista vRealize Operations Manager, al igual que con la gestión de Logs no
encontraremos mejor socio que Log Insight.

Por último, cabe destacar que en cada nueva versión de vSAN vemos más y más novedades y mejoras
en el vSAN Health Check.

Ruby vSphere Console

Para los amantes del command line tenemos todo un Ruby vSphere Console que nos proveerá de
información de todos los Clusters de vSAN que tengamos en la instancia de vCenter en que ejecutamos
la herramienta.

Esta utilidad funciona directamente en vCenter por lo cual, al igual que con vSphere Client, tenemos
la dependencia del servicio de vCenter y el límite de los Clusters administrados por la instancia en
cuestión.

Listado de comandos de Ruby vSphere Console

#VMwarePorvExperts 347
Capítulo 7 - vSAN Federico Cinalli

Podremos movernos entre la estructura del inventario y objetos con los simples comandos ls y cd. Esta
herramienta es ideal cuando queremos obtener información de un objeto en particular, aunque también
es posible hacerlo con ESXCLI. Con el fin de simplificar las largas rutas de los objetos es posible crear
marks que son como accesos directos a objetos en particular.

ESXCLI

Cuando se trata de obtener información del Host y del Cluster por línea de comandos encontraremos
a un gran aliado en la familia de comandos ESXCLI VSAN.

Lo primero que debemos destacar es la gran facilidad de uso. Simplemente debemos comenzar tirando
el comando esxcli vsan y veremos las opciones a continuación.

Lista de opciones del esxcli vsan namespace

Existen comandos que aplican únicamente dentro del ámbito de un Host, y también otros como esxcli
vsan cluster get que devuelve información del Host y del Cluster.

Información de Cluster con esxcli vsan cluster get

Lo más interesante de todo esto es que, a través del comando esxcli vsan health cluster list Obtendremos
la misma información que en vSAN Health, incluso si la instancia de vCenter está caída.

vRealize Operations Manager

¿Seríamos capaces de salir a conducir nuestro coche sin indicadores de los niveles de líquidos, ni el

#VMwarePorvExperts 348
Capítulo 7 - vSAN Federico Cinalli

indicador de velocidad ni tampoco el de temperatura? ¿No verdad? “¿Cómo era capaz de trabajar con
mi entorno de vSphere sin vROps?” es lo que se preguntan los administradores que disponen de la
herramienta y, además, aprendieron a utilizarla.

Vista del Dashboard vSAN Capacity Overview

Los Management Packs de vROps nos permiten extender los sistemas a monitorizar agregando
Dashboards, Views, Reports, etc.

Si bien el vSAN Management Pack (gratuito) es decente y provee buena información, al tratarse de
dos de los productos más populares de VMware se podría haber trabajado con algo más de alegría
aportando más heatmaps y jugando con métricas clave.

vSAN Operations Overview en vROps

Algo a destacar es que utilizando vRealize Operations Manager el alcance de la monitorización no


se limita a un vCenter sino a todas las instancias que tengamos configuradas en los adaptadores.
Por lo tanto, seremos capaces de tener vistas de absolutamente todos los Clusters de vSAN de la
organización. ¿No está mal verdad?

vRealize Log Insight

Cuando se trata de almacenar, indexar y gestionar Logs en un Datacenter no hay dudas que el producto

#VMwarePorvExperts 349
Capítulo 7 - vSAN Federico Cinalli

debe ser de primer nivel. Más que nada debido a que cuando necesitamos trabajar con Logs es que,
generalmente, buscamos resolver un problema y no queremos que la propia herramienta sea otro
problema en sí misma.

Los Content Pack de Log Insight identifican los Logs clave y proveen Dashboards con los indicadores
más importantes y de forma gráfica.

Dashboards de vSAN en Log Insight

Ya sean problemas de hardware, rendimiento o algún objeto lógico de vSAN será tremendamente fácil
trabajar con los Logs de todos los Hosts del Cluster.

Y por último destacar que, al igual que con vROps, Log Insight nos permitirá gestionar los Logs de forma
centralizada de múltiples instancias de Clusters de vSAN ya sea del mismo vCenter o de múltiples
vCenters sin importar la ubicación física de los Datacenters.

PowerCLI

Otra versátil herramienta de línea de comandos que crece de forma exponencial en cada nueva
versión. A la hora de obtener información del estado de configuración u operativo de un Cluster de
vSAN también seremos capaces de utilizar PowerCLI. Especialmente para los administradores con
una buena base de Powershell.

Lista de comandos Get-vSAN en PowerCLI

#VMwarePorvExperts 350
Capítulo 7 - vSAN Federico Cinalli

Si ya de por sí el potencial que ofrece PowerCLI es inmenso, no olvidemos que podemos integrar
vRealize Orchestrator con vCenter, y agregar un Endpoint de PowerCLI en vRO. Esto nos permitiría
utilizar un botón contextual a nivel de Cluster de vSAN con una opción para que nos envíe determinada
información por mail sin movernos del entorno gráfico. ¿Interesante verdad?

#VMwarePorvExperts 351
Capítulo 7 - vSAN Federico Cinalli

10. Top 10 comandos vSAN

En este pequeño apartado destacaremos los 10 comandos más útiles para tener a mano a la hora de
necesitar información y resolver problemas en nuestros Clusters de vSAN.

La gran mayoría de la información que obtendremos con los comandos que veremos a continuación
también la tenemos disponible en el vSAN Health. No obstante, existen muchas situaciones en las
cuales necesitaremos utilizar línea de comandos por lo que mejor estar preparado.

Algunos comandos pertenecen al espacio de nombres ESXCLI VSAN y otros son comandos de Ruby
vSphere Console.

1. esxcli vsan cluster get

Este simple comando nos ayuda a identificar si hay algún host que, debido a un fallo como una partición
de red, no está operativo en el Cluster de vSAN.

Revisando el estado del Host y del Cluster

2. vsan.whatif_host_failures -s ~cluster

A través de la consola de Ruby podemos comprobar con este comando qué ocurriría si el Host con
mayor cantidad de almacenamiento ocupado tuviera una caída.

En el resultado esperamos ver que no tendremos problemas de capacidad, ni que el límite máximo de
objetos esté comprometido y que los objetos continuarán activos a pesar del fallo.

Verificando la disponibilidad de recursos

#VMwarePorvExperts 352
Capítulo 7 - vSAN Federico Cinalli

3. esxcli vsan health cluster list

Mencionamos varias veces que el vSAN Health es el mejor recurso, con diferencia, para obtener
información de qué es lo que está ocurriendo en el Cluster.

La limitación es que dependemos de vCenter, esto es así debido a que visualizamos vSAN Health en
el vSphere Client.

Con este comando podemos ver exactamente lo mismo que en el vSAN Health pero desde la línea de
comandos de un Host. Incluso funcionará con el servicio de vCenter no operativo.

vSAN Health en línea de comandos

4. vsan.vm_object_info ~vm

Este comando de Ruby vSphere Console nos entrega información detallada de un objeto en concreto.
Tendremos acceso a información como el estado de salud, la política que se le aplica, el número de
componentes y sus correspondientes estados.

5. esxcli vsan debug object health summary get

Pocos comandos serán tan útiles como este a la hora de necesitar obtener información del estado de
salud de todos los objetos.

El objetivo es ver la totalidad de objetos en modo healthy y el resto de los estados en 0.

#VMwarePorvExperts 353
Capítulo 7 - vSAN Federico Cinalli

Visualizando el estado de los objetos

6. vsan.cluster_info ~cluster

Este simple comando nos entrega información detallada de cada uno de los Hosts con sus
correspondientes estados y la información de sus recursos de almacenamiento.

Es un gran resumen que en más de una vez nos ayudará a identificar algún problema.

Resumen de Hosts, Cluster y Almacenamiento

7. esxcli vsan debug resync summary get

Una buena práctica antes de poner un Host en modo mantenimiento es verificar si hay operaciones de
recreación o resincronización de componentes.

Este comando será nuestro mejor amigo a la hora de verificar, a través de línea de comandos, si
existen ese tipo de operaciones en el Cluster.

Confirmando operaciones de resincronización

8. esxcli vsan debug vmdk list

Otro de los comandos infaltables para situaciones incómodas. Este comando nos entregará la lista de

#VMwarePorvExperts 354
Capítulo 7 - vSAN Federico Cinalli

los objetos de discos virtuales, incluyendo ficheros swap, que pertenecen a las máquinas virtuales.

Seremos capaces de ver la ruta, la carpeta (para identificar a qué VM pertenece el objeto) y también
el estado de salud.

Verificando el estado de salud de objetos vmdk

9. esxcli vsan debug disk overview

No debe existir una forma más simple de listar todos los discos físicos, de capacidad y caché, de todos
los Hosts del Cluster junto con su estado de salud.

No solamente veremos los discos, sino que también veremos la capacidad total y el espacio utilizado.

Listado de discos físicos del Cluster

10. esxcli vsan debug evacuation precheck -e localhost

Otra forma de verificar qué ocurriría en el hipotético caso de puesta en mantenimiento o fallo de un
Host.

En este caso el comando realiza el análisis del Host local en el que estamos ejecutando el comando y
nos indica el resultado de cada una de las operaciones que podemos seleccionar al poner un Host en
modo mantenimiento.

#VMwarePorvExperts 355
Capítulo 7 - vSAN Federico Cinalli

Analisis precheck antes de poner un Host en mantenimiento

#VMwarePorvExperts 356
Capítulo 7 - vSAN Federico Cinalli

11. Resumen de buenas prácticas en vSAN

¿Qué mejor manera de cerrar el capítulo de vSAN que con un resumen de las mejores prácticas?

Evidentemente se podría escribir mucho más sobre las buenas prácticas y su correspondiente detalle
e incluso de vSAN en general, pero al fin y al cabo éste no es un libro de vSAN, sino tan solo un
capítulo llamado “vSAN” dentro de un libro de SDDC de VMware.

Quién sabe si al final nos animamos y escribimos un libro enterito de vSAN, como corresponde, en
Español… ;-)

Buenas prácticas en vSAN:

• 2 o más Disk Groups por Host

• 2 o más Controladoras de disco por Host

• QoS y Jumbo frames en la red de vSAN

• LACP (si está previamente configurado en la red). Alinear la configuración del switch físico con la
política LACP en el Virtual Switch Distribuido

• 1 Cluster de vSAN, 1 VMKernel, 1 vLan

• Utilizar controladoras de disco en modo Passthrough

• Configurar el Caché de las controladoras de disco en 100% para lectura

• ¿Compartimos vmnics? Utilizar NIOC en vDS. Configurar valores altos de Shares para el tráfico de
vSAN. Considerar definir una reserva para vSAN

• Alinear los discos de Caché, el Endurance y la Capacidad en base a las cargas de trabajo esperadas
(Escritura, Lectura o uso Mixto intensivo)

• Desplegar Hosts con configuración homogénea (CPU, RAM, Red y Discos)

• Setear la BIOS para permitir que la gestión de la alimentación del Host sea controlada por el
sistema operativo (el ESXi)

• Utilizar múltiples Políticas de vSAN según los requerimientos

• Verificar que las controladoras provean un valor alto de queue depth para mejorar el rendimiento

• Considerar el uso de dispositivos NVMe y/o Intel Optane para alto rendimiento

• Considerar la implementación de vmnics de 25Gbps en la red de vSAN

#VMwarePorvExperts 357
Capítulo 7 - vSAN Federico Cinalli

#VMwarePorvExperts 358
ADISTEC VSAN READY NODE

Adistec presenta su solución de


vSAN Ready Node validada por VMware.
Modelos pre-configurados por nuestro equipo de Ingeniería en conjunto con Intel y VMware
utilizando como base la última Arquitectura de procesadores Intel Xeon Scalable (Purley)
y VMware VSAN 6.7.

Buscamos entregar una solución llave en mano que ayudará a sus clientes a modernizar sus
recursos de cómputo y almacenamiento, utilizando tecnología Hiperconvergente con VMware
VSAN. Disponibles en dos modelos: All Flash e Híbrido, lo que le permite cubrir una amplia
gama de necesidades y diferentes
tipos de cargas de trabajo.

Ayude a sus clientes a migrar a un modelo de Software Defined Storage (SDS) usando la última
tecnología de Intel y VMware, sumado a la experiencia de Adistec.

www.adistec.com
Capítulo 8
Alta Disponibilidad

Leandro Ariel Leonhardt

#VMwarePorvExperts 360
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

1. Introducción a vSphere HA

Unas de las funcionalidades “estrella” de VMware es la vSphere HA (alta disponibilidad). La mayoría


de las empresas disponen de servicios críticos, servidores de nóminas, servidores web, servidores de
ficheros/impresión, servidores de bases de datos, etc. cuya parada no programada, ocasiona pérdidas
a la compañía.

VMware vSphere permite reducir tiempos de inactividad, por que proporciona niveles de protección en
todos los niveles, por ejemplo, a nivel de componente (hardware), dotando de alta disponibilidad a la
red con teaming de tarjetas o múltiples rutas de adaptadores de entrada y salida, a nivel de servidor/
sistema con VMware HA, migraciones de máquinas virtuales en caliente con vMotion, Storage vMotion
y Storage DRS (Distributed Resource Scheduler) para el almacenamiento, replicación a nivel de datos
(máquinas virtuales), vSphere Replication o VMware vSphere SRM (Site Recovery Manager) para
recuperación ante un desastre.

vSphere HA utiliza varios hosts ESXi de un clúster vSphere para proteger a las máquinas virtuales,
proporciona una rápida recuperación de las interrupciones, sea por un fallo de hardware o del sistema.

Los niveles de protección de HA se basan en estos cuatro principios:

• Protección cuando falla un hosts ESXi: vSphere HA reinicia automáticamente las máquinas
virtuales en otro host del clúster.

• Protege de fallos de acceso al almacenamiento: permite la recuperación automatizada de


las máquinas virtuales afectadas. Con la protección de componentes de las máquinas virtuales
(VMCP), las máquinas virtuales afectadas se reinician en otros hosts que siguen teniendo acceso
al almacenamiento.

#VMwarePorvExperts 361
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

• Protege de los fallos de en las aplicaciones: supervisa con un software específico, las aplicaciones
que corren en la máquina virtuales, si se detecta un problema o parada de servicio, realiza una
acción (reinicio del servicio, reinicio de la máquina virtual), etc.

• Protección de las máquinas virtuales en caso de aislamiento de red: en caso de aislamiento


de la red de gestión del host o red vSAN, junto a la perdida del almacenamiento, HA reinicia las
máquinas virtuales en otros hosts del Clúster.

#VMwarePorvExperts 362
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

2. Componentes de vSphere HA

Para entender el funcionamiento de vSphere HA, es importante conocer su arquitectura. La arquitectura


de vSphere HA está compuesta por tres componentes fundamentales:

• FDM

• HOSTD

• vCenter

El primero y probablemente el componente más importante es el denominado FDM (Fault Domain


Manager), más comúnmente llamado, “agente HA”.

El agente FDM es encargado de muchas tareas, como la comunicación de los recursos de los hosts,
estado de las máquinas virtuales “protegidas/no protegidas” y la comunicación de los demás agentes
FDM de los hosts que forman el Clúster. Este agente también gestiona el mecanismo de heartbeat,
ubicación de las máquinas virtuales, reinicio de las máquinas virtuales, etc.

vSphere HA está compuesto por un único Log, lo que permite realizar un troubleshooting más simple y
rápido, toda la información respecto a vSphere HA se almacena en un fichero llamando fmd.log (/var/
log/fdm.log)

HOSTD Agent

El agente FDM habla directamente con el agente HOSTD y vCenter. El agente HOSTD es responsable
de otras muchas tareas, como del encendido de las máquinas virtuales (powering on). Si este agente
tiene algún problema, no participará de ningún proceso de HA. El agente FDM se basa de la información
que le brinda el agente HOSTD acerca de las máquinas virtuales registradas en los hosts, y, gestiona
a las máquinas virtuales usando las APIs del agente HOSTD.

En resumidas cuentas, el agente FDM depende del agente HOSTD y si el HOSTD no está operativo,
FDM detiene todas las funciones y se espera a que el HOSTD esté nuevamente operativo.

vCenter

vCenter es el core de un Clúster vSphere, responsable de:

• Desplegar y configurar los agentes de HA

• La comunicación de los cambios del Clúster

#VMwarePorvExperts 363
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

• Protección de las máquinas virtuales

vCenter es responsable de “empujar” el agente FDM hacia el ESXi cuando corresponda. También
es responsable de la comunicación de los cambios de configuración en el Clúster cuando un host es
elegido como “Master”. Trataremos el concepto de “master/slave” más adelante.

El algoritmo de HA de VMware aprovecha de vCenter para recuperar información del Clúster y del
estado de las máquinas virtuales, mostrando un icono “protegido” junto a cada máquina virtual.

Si vCenter Server no está disponible, el Clúster de vSphere HA funcionaría igualmente y ante un


de fallo de hardware, en el host, los agentes FDM reiniciarían las máquinas virtuales en otros hosts
disponibles, en ese caso, vCenter no se daría cuenta de los cambios del Clúster hasta no volver a un
estado normal.

vCenter Server también permite configurar prioridades de reinicios, es preferible que primero se levanten
las máquinas más críticas y seguidamente las menos críticas, esto también va a asegurarnos que en
caso de que no haya recursos suficientes pare encender todas las máquinas virtuales afectadas, que
las más críticas puedan encenderse, esto es una configura-ción manual que realiza el administrador
de la infraestructura.

#VMwarePorvExperts 364
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

3. Conceptos Fundamentales

Para profundizar más el funcionamiento de alta disponibilidad en vSphere, debemos de centrarnos en


los conceptos fundamentales para comprender:

• Master / Slave

• Heartbeating

• Red aislada vs red particionada

• Protección de máquina virtual

• Protección de componentes

Hablemos del Master y Slave

Cuando se habilita HA en un Clúster vSphere, vCenter se encarga de desplegar los agentes FDM en
cada host que forman un Clúster, de todos los hosts, uno es considerado “Master” y los demás son
denominado “Slave”.

Para determinar que host será el Master (principal), el sistema, de manera automática, determina que
host tiene más acceso a los Datastores (LUNs), si uno de los host tiene presentado más Datastores
que los demás, entonces ese host es denominado “Master”.

En la mayoría de los entornos, todos los hosts miembros de un Clúster tienen acceso a la misma
cantidad de Datastores, por lo que es difícil decir quién será denominado Master, en esa situación,
entra un segundo mecanismo basado en objeto que se hace llamar “MOID” (Manage Objet ID), basado
en el ID de un host.

Para que entendáis bien en qué consiste el MOID, pondré un ejemplo:

Imaginad que un host recibe aleatoriamente el ID host-99 y otro recibe el host-100, en ese caso, el
Master será el host-99 por qué el primer número “host-99” es mayor que el “host-100”. Si los primeros
números ID coinciden con el número 9, entonces se procede a comparar con el segundo, el mayor será
elegido como Master, Ej: “host-99” y “host-97”, en este caso, se comparan nos números de la segunda
posición, el “host-99” será el master debido a que 9 es mayor que 7.

Ese proceso de elección de “Master” dura 15 segundos mas o menos, y se inicia cuando se da algunas
de estar circunstancias:

#VMwarePorvExperts 365
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

• Se activa vSphere HA en un Clúster

• El host principal (Master) detecta un fallo del sistema debido a uno de los siguientes factores:

– El host “principal” se pone en modo de mantenimiento.

– vSphere HA se ha reconfigurado.

• Los hosts esclavos no pueden comunicarse con el host principal debido a un problema de red.

La comunicación de los hosts y vCenter se realiza por la red de gestión “Management Net-work” y la
función del host “principal” es informar a vCenter Server del estado del Clúster, de los agentes FDM de
cada host, de la disponibilidad de las máquinas virtuales y del estado / informes del Clúster.

vCenter Server indica al agente de vSphere HA las máquinas virtuales que debe proteger, el agente
conoce los cambios de estado a través del agente HOSTD y vCenter Server se informa de eso a través
del proceso vpxa.

El host principal supervisa el estado de los hosts esclavos y en caso de fallo, en algún host esclavo, el
host principal se hace cargo de “arrancar” las máquinas virtuales en el host principal, es recomendado
activar DRS para un equilibrio de carga en los hosts.

Cuando se activa HA a nivel de Clúster, vCenter empuja los agentes a cada ESXi, pero además,
algunos Datastores compartidos son elegidos como mecanismo de heartbeat, en un datastore VMFS,
se crea una carpeta oculta llamada vSphere-HA, dentro existe un fichero (protectedlist) legible sólo
para el agente FDM con un listado de todas las máquinas protegidas en los host ESXi.

#VMwarePorvExperts 366
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Para un volumen NFS, existe un archivo de bloqueo.

Los hosts esclavos supervisan el estado de las máquinas virtuales que se ejecutan localmente y envían
los cambios de estado al host principal. También supervisan el estado del host principal.

vSphere HA se configura, se gestiona y se supervisa por medio de vCenter Server. El proceso vpxd
que corre dentro de vCenter Server, se encarga de mantener los datos de configuración del clúster, así
como de informar al agente maestro de los cambios en la configuración del clúster.

Cualquier cambio a nivel de Clúster, el maestro informa a los “esclavos” para que se guarden una copia
de la configuración en local.

Las máquinas virtuales de un Clúster con HA quedan automáticamente protegidas cuando encienden.

El Master consulta el estado de los hosts por la red de gestión, el Master es el único que envía
heartbeating (latidos de corazón) por las dos tarjetas de red físicas, los “slaves” solo envían heartbeating
por una de ellas, en el caso de que falle, enviarán por la otra.

Si el host esclavo no responde durante el periodo de tiempo predefinido, el host principal lo declara
como inaccesible, que puede ser parcial (solo si pierde el acceso a la red) o total, si tampoco se llega
al almacenamiento de ese host.

vSphere HA intenta reiniciar las máquinas virtuales solamente en una de las siguientes situaciones:

• Ha fallado un host (no hay heartbeat de red, ni ping, ni heartbeat de datastore).

• Un host ha quedado aislado y la respuesta al aislamiento del host configurado en el clúster es


Power off o Shut down (estas opciones las define el administrador a nivel de Clúster).

3.1 Escenarios de fallos para vSphere High Availability:

• Fallo de un host Master

• Fallo del host Slave

• Fallo de la red (aislamiento de hosts)

• Fallo de acceso al Storage:

#VMwarePorvExperts 367
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

• Protección de componentes de la máquina virtual (VMCP)

- All Paths Down (APD, todos los accesos perdidos al almacenamiento)

- Permanent Device Lost (PDL, Pérdida permanente de dispositivo).

3.2 ¿Qué sucede cuando falla un host Master/principal?

Puede ocurrir que el host tenga un fallo de hardware o que el administrador de la infraestructura ponga
el host en modo mantenimiento, en ese caso, los agentes FDM de los Slaves hablan entre ellos para
elegir un nuevo Master, el proceso dura unos15 segundos aproximadamente y se tienen en cuenta las
dos consideraciones que mencionamos, el host que más datastore vea, ese es el candidato a ser el
nuevo Master, si no, mediante el ID de los hosts (MOID).

El nuevo host principal lee el fichero “protectedlist” de cada datastore heartbeat y determina cuáles de
ellas están protegidas por vSphere HA y deben reiniciarse (power on - si fue por fallo de hardware).

El agente HA activa un proceso antes de declarar que un host está aislado. “s” corresponde a segundos:

T0s - Aislamiento del host (master)

T0s - El master intenta hacer ping a su dirección de aislamiento

T5s - El master se declara el mismo como “aislado”

T25s - El maestro “desencadena” la respuesta de aislamiento (Response for Host Isolation)

Los esclavos declaran un nuevo “Master”

3.3 ¿Qué sucede cuando falla un host Slave/esclavo?

El Master debe averiguar si el fallo del host Slave es parcial o total, recordar que un host está
parcialmente afectado sólo cuando no emite heartbeat por la red de gestión o no llega a sus direcciones
de aislamiento (configuración avanzada en Clúster). En ese caso, se tomará la decisión que establezca
el administrador.

#VMwarePorvExperts 368
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Si el master no llega a hacer ping a la gestión del host, ni tampoco recibe heartbeat de datastore,
entonces el Master lo “declara” como fallo total y se procede al reinicio de todas las máquinas virtuales.

El agente HA activa un proceso antes de declarar que un host está aislado. “s” corresponde a segundos:

T0s - No llega a su dirección de aislamiento: Aislamiento del host (esclavo)

T10s - El esclavo entra en “estado de elección”

T25s - El esclavo se elige el mismo como maestro

T25s - El esclavo hace ping a su gateway “direcciones de aislamiento”

T30s - El esclavo se declara aislado

T60s - El esclavo “desencadena” la respuesta de aislamiento (Response for Host Isolation)

3.4 ¿Qué sucede cuando falla una aplicación?

Para poder “supervisar” aplicaciones, el requisito fundamental es que estén las VMware Tools
ejecutándose en la máquina virtual, de esa manera, cuando una aplicación falla, VMware puede
realizar acciones previamente configuradas por el administrador de la plataforma, por ejemplo, intentar
levantar el servicio equis veces, reiniciar la máquina virtual (en el mismo host), enviar una notificación,
etc.

La supervisión de aplicaciones requiere un agente de supervisión de terceros diseñado especialmente


para esta tarea, entre los mas conocidos/utilizados, el de Symantec.

#VMwarePorvExperts 369
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

4. Protección de una máquina virtual (VMCP)

En vSphere 6.0 se introduce una nueva característica como parte de vSphere HA llamada VM Component
Protection (VMCP). Esta característica protege las máquinas virtuales de los eventos relacionados con
el almacenamiento, específicamente en los incidentes de pérdida de dispositivo permanente (PDL) y
All Paths Down (APD).

Seguramente si has sufrido un problema de almacenamiento (poco frecuentes) antes de vSphere 6,


habrás notado que las máquinas virtuales se quedaban como “inaccesibles”, no respondían, era muy
complicado gestionar esa situación, ni desde las líneas de comandos (esxcli).

Los problemas de conectividad vienen provocados por:

• Fallo de la red o Switch

• Mala configuración del almacenamiento

• Corte eléctrico

Cuando se produce un fallo de accesibilidad al almacenamiento, el host ESXi afectado deja de poder
acceder, vSphere HA responde a un fallo de este tipo, que puede generar una alarma de envero o
hasta el reinicio de la máquina virtual a otro host.

Por defecto, APD se espera 140 segundos cuando se pierden todos los caminos al Datastore, VMCP
esperará un período de tiempo adicional antes de tomar medidas contra las máquinas virtuales
afectadas. El período de espera es de 3 minutos. En otras palabras, VMCP esperará 5m: 20s antes
de actuar contra las máquinas virtuales. La suma del tiempo de espera de APD y el retraso para la
conmutación por error de VM también se conoce como tiempo de espera de VMCP.

Esta característica (VMCP) sólo está disponible para Clústers con vSphere 6.0 o superior.

#VMwarePorvExperts 370
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

5. Opciones de un clúster HA

5.1 Features and Responses

En este apartado tenemos el check de “Enable Host Monitoring”, en el caso de realizar un


mantenimiento sobre los switches de gestión, es posible evitar situaciones de “aislamiento” de host,
deshabilitando esa característica.

¿Qué hace vSphere HA cuando falla un host (Host Failure Response) Restart VMs o Disable?

#VMwarePorvExperts 371
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Si falla un servidor ESXi, lo lógico es que haga una conmutación, para que todas las máquinas virtuales
que corrían en ese host, se reinicien (Restart VMs) en el resto de hosts del clúster. La opción “Disable”
se utiliza para cuando aplicaciones que corren dentro de las máquinas virtuales están licenciadas por
host físico (poco común), por lo tanto, si falla el host, aunque la máquina virtual se reinicie en otro host,
no funcionará por la que licencia es por host físico.

Por defecto, todas máquinas virtuales del clúster HA tienen como prioridad “Medium”, es recomendado
identificar cuáles son los servidores más críticos de nuestra infraestructura, la prioridad que
establezcamos sobre la máquina (High, Medium o Low) decide que máquinas virtuales se encenderán
primero, el “Power on” se hace de manera secuencial y en bloques de máquinas virtuales. Se puede
dar el caso que máquinas virtuales con prioridad baja no se enciendan por qué no hay recursos
suficientes en el clúster.

¿Qué hace vSphere HA cuando se produce aislamiento de host (Response for Host Isolation)
Disable, Power off and restart VMs o Shutdown and restart VMs?

Al existir un segundo mecanismo (heartbeat de datastore), una buena práctica es que vSphere HA no
haga nada, puesto que sólo se ha perdido la red de gestión, las máquinas virtuales tienen acceso al
resto de la red y al almacenamiento.

En un Clúster de vSphere HA con vSAN, se recomienda “Power off and restart VMs”, porque el
heartbeating se ejecuta por la red de vSAN.

¿Qué hace vSphere HA cuando se produce Datastore with PDL o Datastore with APD?

#VMwarePorvExperts 372
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

También conocido como VMCP, VMware recomienda para estos casos, hacer un “Power off and restart
VMs” (con agresividad conservativa o agresiva), puesto que sí perdemos el almacenamiento, las
máquinas virtuales sufren un crash.

¿Qué hace vSphere HA cuando falla una aplicación (VM Monitoring) Disable, VM Monitoring Only, VM
and Application Monitoring?

#VMwarePorvExperts 373
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

He visto muchos clústers con la opción por defecto (Disable), sin embargo, a mí me gusta la opción de
reiniciar, si una máquina virtual se “cuelga”, no estará dando servicio de ninguna manera.

Imaginad que un sistema Windows o Linux se cuelga, VMware HA (agente FDM y HOSTD) no reciben
heartbeat de esa máquina virtual por las VMware Tools (requisito para esta característica), tampoco
observa actividad en disco, en esa situación, considera que esa máquina virtual está colgada y realiza
una acción, no hacer nada (Disable), o reiniciar (VM Monitoring Only).

Es muy importante que sepáis que, antes de reiniciar, VMware saca una captura de pantalla con el
error y lo deja dentro de la carpeta de la máquina virtual con el nombre de la máquina virtual .png, por
esa razón prefiero configurar que la máquina virtual se reinicie.

Para la opción de “VM and Application Monitoring”, sólo funcionará si se integra con una herramienta
adicionar/externa como ya comentamos en otra sección.

5.2 Admission control

El control de admisión es una política utilizada por vSphere HA para garantizar la capacidad de
conmutación por error dentro de un clúster. Cuanto más restrictivos seamos, menos máquinas virtuales
pondrá correr dentro del clúster.

#VMwarePorvExperts 374
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Como consultor, he visto muchos entornos con “Admission Control” deshabitado, para así poder correr
más máquinas de lo que realmente se puede garantizar encender en caso de haber un fallo en el host.

Es decir, cuando Admission Control está deshabitado, el algoritmo de HA no calcula si hay suficientes
recursos para todas las máquinas del clúster, sin embargo, si está habilitado, vSphere HA calcula y te
garantiza que, ante un evento de conmutación, todas las máquinas virtuales harán un Power on.

5.3 Heartbeat datastore

VMware recomienda tener al menos dos Datastore para ello, aunque podemos seleccionar manualmente
los Datastores que nosotros queramos.

Automatically select datastores accessible from the hosts: (Opción por defecto), VMware escoge
aleatoriamente y los “marca” como datastores de heartbeat.

Use datastores only from the specified list: El administrator de la plataforma elige manualmente cuáles

#VMwarePorvExperts 375
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

se usarán.

Use datastores from the specified list and complement automatically if needed: El administrator de la
plataforma elige manualmente cuál se usará como heartbeat, VMware HA podrá marcar otro más en
caso de necesitar.

5.4 Advanced options

Podemos configurar opciones avanzadas que afectan el comportamiento de un clúster de vSphere HA,
como añadir más de una dirección de aislamiento, un máximo de 10, (das.isolationaddress), Ejemplo;
das.isolationaddress1 = xxx.xxx.xxx.xxx das.isolationaddress2 = xxx.xxx.xxx.xxx esta condición va
acompañada de das.usedefaultisolationaddress = false para que no usar una única dirección como
heartbeat.

También, si sólo tenemos un único datastore en el clúster, veremos un Warning que se requiere
al menos dos, se puede “forzar” que solo tengamos uno ignorando esa advertencia con (das.
ignoreInsufficientHbDatastore = True)

Son solo algunos ejemplos, pero existen muchas opciones avanzadas, configurable según la necesidad
y servicios del cliente.

#VMwarePorvExperts 376
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

#VMwarePorvExperts 377
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

6. Monitorización de vSphere HA

La vista “SUMMARY” se encuentra en Clúster / Monitor / vSphere HA, en este apartado tenemos el
Summary, que nos permite conocer el estado general del Clúster, quién es el Master, host conectados
al master, agentes vSphere con problemas, host con fallos, problemas de Network (management),
máquinas virtuales protegidas o no, etc. Esta vista nos aporta una visión global por Clúster y resulta
muy útil para los administradores de la infraestructura.

En Heartbeat podemos observar él o los datastores que están haciendo de Heartbeat, como buena
práctica, VMware recomienda al menos tener dos.

Si existe alguna mala configuración, podemos verlo en “Configuration Issue”, por ejemplo, unos de los
datastores que hacen de Hearbeat no es visible por todos los nodos del Clúster.

Para situación APD o PDL, tenemos un apartado específico para ello, “Datastore under APD or PDL”.

#VMwarePorvExperts 378
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

7. Proactive HA

Con la llega de la versión de vSphere 6.5, VMware introdujo una nueva característica, VMware HA
ahora también detecta condiciones de hardware en los ESXi y permite evacuar las máquinas virtuales
antes de que se produzca un problema de hardware, evitando interrupciones en las máquinas virtuales
gracias a esta funcionalidad. Proactive HA trabaja en conjunto con los proveedores monitorizando el
estado de salud de los componentes de hardware como la memoria, los ventiladores y las fuentes de
alimentación.

Esta función, evita de forma proactiva el tiempo de inactividad de la máquina virtual al detectar posible
fallos en algún componente de hardware y según la configuración que realicemos, el host ESXi se
pondrá en modo cuarentena (equilibra el rendimiento y la disponibilidad, evitando el uso del host
parcialmente degradado siempre que el rendimiento de la máquina virtual no se vea afectado) o, en
modo mantenimiento (asegurándose de la evacuación total de máquinas virtuales en ese host).

DRS debe estar habilitado en el clúster para hacer uso de Proactive HA.

Proactive HA puede responder a diferente tipo de fallos, actualmente hay cinco eventos:

• Memoria

• Storage

• Network

• Ventiladores (Fan)

• Fuente de alimentación

7.1 Configuración de Proactive HA

Nos posicionamos sobre el Clúster / Configure / Services / vSphere HA

En primer lugar, debemos de habilitarlo:

#VMwarePorvExperts 379
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

En este apartado podemos configurar el nivel de automatización y remediación.

En “Automation Level” existen dos modos, el modo manual y el modo automático:

• Manual: vCenter Server sugerirá las recomendaciones de migración para máquinas virtuales en el
host “degradado”, pero la migración de máquinas es realizada por el administrador.

• Automatizado: las máquinas virtuales se migrarán de forma automática a otro host saludable y el
host degradado ingresará según la acción de remediación seleccionada (cuarentena o en modo
mantenimiento).

En el apartado “Remediation” encontramos tres niveles, mixto, modo cuarentena o modo mantenimiento:

La selección del “modo de cuarentena” o de “mantenimiento” aplicará la misma respuesta para fallas
moderadas y graves. La selección del modo “mixto” aplicará el modo de cuarentena para moderados
y el modo de mantenimiento para fallos graves.

#VMwarePorvExperts 380
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Por último, en “Providers” se pueden añadir campos de fallos específicos del proveedor de hardware.

Si queremos que las máquinas virtuales se migren automáticamente (evacuar el host) ante una alerta
de hardware detectado a través de los sensores de hardware, debemos de:

1. Habilitar Proactive HA

2. Establecer “Automated” en el apartado de Automation Level

3. Habilitar vSphere HA y DRS

#VMwarePorvExperts 381
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

8. Buenas prácticas/consideraciones de diseño

Para evitar aislamientos de hosts, es recomendado:

• Implementar redes de heartbeat redundantes (dos tarjetas de red físicas conectado al mismo
vSwitch de gestión (red de management) o Port Group para vSwitch Distribuido.

• Implementar direcciones de aislamiento redundantes (Advanced Options - das.isolationaddress).

En caso de producirse aislamiento de host, un buen diseño (teaming de tarjetas de red de gestión, más
de una dirección de aislamiento, etc) permite a vSphere HA determinar si el host aislado sigue activo
o no.

Un máximo de 64 host por clúster HA y hasta 8000 máquinas virtuales por clúster/máquinas protegidas.

A nivel de almacenamiento, un datastore por FC para que el mecanismo de heartbeating sea


independiente a la red de gestión, para iSCSI, separar físicamente la red de almacenamiento de la red
de gestión (un vSwitch independiente, así como el VMkernel).

Si trabajamos con un clúster vSAN + HA, configurar la acción de “Power off and restart VMs” cuando
se produce un evento de aislamiento de host, porque el heartbeating se ejecuta por la red de vSAN.

#VMwarePorvExperts 382
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

9. DRS - Distributed Resource Scheduler

Distributed Resource Scheduler es una funcionalidad de VMware, controlada y gestionada desde el


vCenter Server, es como el cerebro de una infraestructura virtual, tiene la capacidad de balancear las
cargas de trabajo para evitar que un host se vea saturado ya sea por demanda de CPU, memoria o
red.

DRS se habilita a nivel de clúster, necesita que la red de vMotion esté configurado en todos los hosts
que forman el clúster para poder “migrar” máquinas virtuales y equilibrar las cargas de todos los hosts,
para ello, los hosts deben tener almacenamiento compartido, DRS es compatible con VMFS, NFS,
vSAN y VVOL.

DRS tiene en cuenta la saturación en la red, es decir, antes de migrar una máquina virtual a un host,
también observa el tráfico de red para balancear la carga de CPU y RAM del clúster, si un host está
saturado a nivel de red, las máquinas virtuales se migrarán a otros hosts del clúster.

9.1 Configuración de vSphere DRS: Nivel de automatización

Cómo se puede apreciar en la imagen, tenemos diferentes apartados para configurar: DRS Automation,
Additional Options, Power Management y Advanced Options.

A nivel de automatización, tenemos tres niveles:

• Manual: cuando DRS se encuentra en modo manual, DRS va a recomendar migrar máquinas
virtuales para equilibrar la carga, pero NUNCA migrará de manera automática, ese movimiento
tendrá que hacerlo el administrador. Si encendemos una máquina virtual, DRS muestra una lista
de host del cluster para que elijamos en que servidor encender la VM.

• Partially automated: cuando DRS se encuentra en modo parcialmente automatizado, DRS va a


recomendar migrar máquinas virtuales para equilibrar la carga, pero NUNCA migrará de manera
automática, ese movimiento tendrá que hacerlo el administrador, la diferencia con respecto al
nivel de automatización “Manual” radica en la ubicación de la VM de manera automática cuando
encendemos, reubicándola en el host con menos “carga”.

• Fully automated: cuando un clúster está pasando por mementos de estrés, DRS migrará las
máquinas virtuales de manera automática y sin intervención del administrador para balancear la

#VMwarePorvExperts 383
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

carga del entorno y evitar problemas de rendimiento, a demás, si se encienden máquinas virtuales,
automáticamente los reubicará en los hosts con menos carga.

Estos niveles de automatización tienen diferentes niveles de “agresividad” (Migration Threshold),


siendo el nivel 1 el más “moderado” y el nivel 5 el más “agresivo”:

• Nivel 1: vCenter Server solo aplica las recomendaciones necesarias para satisfacer las limitaciones
del clúster, como las reglas de afinidad y al establecer el host en modo mantenimiento.

• Nivel 2: vCenter Server aplica las recomendaciones que pueden suponer una mejora importante en
el equilibrio de carga del clúster.

• Nivel 3 (predeterminado): vCenter Server aplica las recomendaciones que pueden suponer una
mejora perceptible en el equilibrio de carga del clúster.

• Nivel 4: vCenter Server aplica las recomendaciones que pueden suponer incluso una mejora
moderada en el equilibrio de carga del clúster.

• Nivel 5: aplica todas las recomendaciones. vCenter Server aplica las recomendaciones que pueden
suponer la más ligera mejora en el equilibrio de carga del clúster.

Un nivel muy agresivo podría suponer muchos movimientos de vMotion, algunas aplicaciones son
susceptibles a migrar y muchos movimientos de máquinas virtuales, podrían afectar la red, por defecto,
VMware recomienda el nivel 3, el predeterminado.

VMware incorporó “Predective DRS”, que hace que sea más inteligente, porque se integra con
vRealize Operations Manager (vROPS), vROPS realiza cálculos nocturnos de algoritmos específicos
para balancear la carga de trabajo antes de que el entorno o las máquinas virtuales se vean afectadas.

#VMwarePorvExperts 384
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

9.2 Configuración de clúster DRS: automatización a nivel de VM

La configuración de DRS es a nivel de clúster, pero es posible “sobre-escribir” la configuración a


nivel de máquina virtual, y tiene todo su sentido, por que tal como mencioné un poco más arriba,
hay aplicaciones que son sensibles a migrarse con vMotion o que simplemente, el fabricante de la
aplicación no valide el soporte a vMotion (Oracle Mildelware, F5), etc.

Para sobre-escribir la configuración a nivel de máquina virtual, seleccionamos el clúster —> Configure
—> VM Overrides, en ejemplo de la imagen, el clúster está en modo modo manual (no se aprecia en
esta imagen) pero la máquina virtual está en “Partially Automated”.

9.3 Configuración de clúster DRS: afinidad de la máquina virtual

Esta opción hace referencia a VM/Host Rules, para poder aplicar afinidad o anti afinidad de máquinas
virtuales, por ejemplo, imaginad que tenéis dos servidores DNS corriendo en un clúster, y sin darnos
cuenta, ambos servidores DNS corren en el mismo host, si ese host tiene un problema, perderíamos
servicio de DNS, o tenemos un servidor web, un front-end y back-end, servidores de dominios, etc.

La afinidad puede ser máquinas virtuales corriendo juntas o separadas, máquinas virtuales corriendo
o no en un host o grupo de host (afinidad y anti afinidad).

Las reglas de máquinas las crearemos en VM/Host Rule (“Keep Virtual Machines Together” y “Separate
Virtual Machines”):

#VMwarePorvExperts 385
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Si vamos ha usar las reglas “Virtual Machines to Hosts” o “Virtual Machines to Virtual Machines”,
debemos de definir previamente en el apartado VM/Host Groups creando los grupos (tipos) de “VM
Group” y “Host Group”.

#VMwarePorvExperts 386
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Definido las reglas, éstas pueden ser “preferentes” u “obligatorias”, para las “preferentes” (Should
run on hosts in group), si el host o grupo de host está disponible, las máquinas virtuales correrán en
esos host, si no lo están, podrán correr en otros host, sin embargo, si la regla es “obligatoria” y el host
o grupo de host no está disponible, vCenter Server con HA, no harán “power on” de esas máquinas
virtuales en otros hosts por que la regla ha sido creado como obligatoria (Must run on hosts in group).

Si creamos más de una regla de afinidad de VM-Host, las reglas no se clasifican, sino que se aplican
por igual. Por ejemplo, una máquina virtual que pertenece a dos grupos DRS, cada uno de los cuales
pertenece a una regla requerida diferente, puede ejecutarse solo en los hosts que pertenecen a ambos
grupos DRS del host representados en las reglas.

Cuando dos reglas de afinidad de VM-Host entran en conflicto, la mas antigua tiene prioridad y la
regla más nueva quedará deshabilitada. DRS solo intenta satisfacer las reglas habilitadas y las reglas
deshabilitadas se ignoran.

Por ejemplo, sí creamos una regla de separar máquinas virtuales, por ejemplo: (CiscoISE02 y
CiscoISE03), y otra regla de “mantener máquinas virtuales juntas”, ésta última regla se creará, pero
permanecerá deshabilitada porque se contradicen.

#VMwarePorvExperts 387
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Cuando habilitamos DRS, las funcionalidades de “Pool de recursos” y vAPP estarán disponibles, pero
cuidado, sí en algún momento deshabilitamos DRS y tienes pool de recursos y/o vAPPs, éstas se
borran. Es posible hacer un Snapshot del Pool para “recuperar” en caso de pérdida.

Algo que me gustaría dejar claro es que DRS no es una funcionalidad de vSphere ESXi, forma parte,
pero no lo es, por lo tanto, si el vCenter Server no está operativo, las reglas podrían no respetarse
hasta que el servidor vCenter esté nuevamente operativo, si las reglas se están infringiendo y vCenter
Server vuelve a estar operativo, migrará las máquinas virtuales o grupos de máquinas virtuales para
hacer cumplir las reglas que hayamos definido a nivel de clúster.

Las reglas de DRS se guardan en la base de datos del servidor vCenter Server.

Las reglas DRS no se replican entre vCenter linkados, así que a la hora de hacer un recovery, hay
que tener en cuenta en crear las mismas reglas en el CPD pasivo con las máquinas virtuales de los
“placesholder”.

Tener en cuenta que si usáis TAGS, al hacer un salto de CPD, tampoco se guardan, así que os

#VMwarePorvExperts 388
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

aconsejo tirar de PowerCLI/PowerShell para hacer un export y un import de TAGS ;)

9.4 Visualización del clúster DRS

Al seleccionar el clúster / Monitor / vSphere DRS veremos seis apartados, resulta útil por que podemos
tener una visión global de lo que pasa o ha pasado en el clúster DRS:

En el apartado “Recommendations” encontraremos las recomendaciones del clúster para los niveles
de automatización “manual” o “parcial”, por en esos niveles de automatización, DRS nunca mueve las
máquinas virtuales automáticamente.

En “Faults” encontraremos los fallos del clúster DRS, la razón y el objeto afectado, posibles vMotion
fallidos.

El “History” nos proporciona fecha y hora que se produjo un evento de vMotion, como el detalle de
máquinas virtuales movidas de un host a otro, nos puede resultar útil para troubleshooting e informes.

#VMwarePorvExperts 389
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Las demás visualizaciones como “CPU Utilization”, “Memory Utilization” y “Network Utilization” nos
aportan información sobre la distribución de recursos o mejor dicho, el consumo de los recursos
de cada hosts del clúster, así, si tenemos el clúster en modo manual o parcialmente automatizado,
sabremos si el balanceo que estamos haciendo es equivalente para todos los hosts del clúster.

Al igual que sucede con vSphere HA, un host en modo mantenimiento, no forma parte del clúster de
recursos hasta que salga del modo mantenimiento. Cuando un host está en modo mantenimiento,
ninguna máquina virtual podrá “correr” dentro de él.

9.5 vSphere HA y vSphere DRS

Tal como hemos comentado a lo largo de estos módulos, vSphere HA es un agente (FDM) que corre
dentro de casa servidor ESXi, sin embargo, DRS es una característica de vCenter Server, el servidor
vCenter Server se encarga del cumplimiento de las reglas de afinidad de máquinas virtuales o hosts.

vSphere HA y vSphere DRS pueden y deberían trabajar juntos, son complementarios, aun así, existen
motivos de por qué, vSphere HA no sea capaz de hacer “power on” de máquinas virtuales con DRS:

1. Aunque esto es más de vSphere HA, si el control de admisión no está habilitado, es posible que
ciertas máquinas virtuales no se enciendan en el resto del host del clúster por que no hay recursos
suficientes libres para todas.

2. Existen reglas de afinidad o anti-afinidad que impiden que las máquinas virtuales “corran” en otros
hosts del clúster.

3. A nivel de clúster existen suficientes recursos, pero los recursos están fragmentados entre varios
hosts. En estos casos, vSphere HA utiliza a vSphere DRS para “equilibrar y desfragmentar” él
clúster mediante vMotion e intentar hacer “power on” en el resto de hosts.

#VMwarePorvExperts 390
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

10. Fault Tolerance

Fault Tolerance (FT) posiblemente es unas de las características más asombrosas de VMware, permite
recuperar un servidor virtual ante un fallo de host/datastore, sin pérdida de datos, sin interrupción de
servicio (cero downtime) y sin pérdida de conectividad TCP.

FT siempre ha estado muy limitado, sólo podíamos habilitar esta característica a máquinas virtuales con
1 vCPU (entre otras limitaciones), impedía habilitar esta funcionalidad a la mayoría de los servidores
mas críticos de la empresa.

En vSphere 6.x, VMware dejó de utilizar la tecnología vLockstep que impedía usar más de un vCPU
en FT para poder llegar a más clientes y servicios críticos.

Imagen de www.patriciocerda.com

La máquina virtual protegida recibe el nombre de máquina virtual principal. La máquina virtual duplicada,
es conocida como máquina virtual secundaria, al habilitar FT, se crea la secundaria y se ejecuta en otro
host. La ejecución de la máquina virtual secundaria es idéntica a la de la máquina virtual principal. La
máquina virtual secundaria puede tomar el control en cualquier momento sin interrupción, con lo que
proporciona protección con tolerancia a fallos.

10.1 Características y limitaciones de Fault Tolerance

• Compatible con cualquier aplicación y sistema operativo.

• Admite máquinas virtuales con hasta 4 vCPU y 64 GB de memoria RAM.

• No más de 4 máquinas virtuales con FT por host, pero no más de 8 vCPU asignados para FT por

#VMwarePorvExperts 391
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

host.

• Compatible con vMotion en la máquina principal y en la secundaria.

• FT crea una copia de todos los discos y archivos de la máquina virtual (principal).

• Comprobación mediante puntos de control para sincronizar el vCPU entre la máquina virtual
principal y secundaria.

• Admite diferentes tipos de discos, thin, thick, etc.

• Compatible con DRS.

• Compatible con vSAN.

• HA y vMotion deben de estar configurado en el clúster.

• La máquina virtual principal y secundaria, nunca residen en el mismo host.

• Fault Tolerance ahora es compatible con Site Recovery Manger v8.1.

Os recomiendo validar que el CPU/Servidor está en matriz con VMware para trabajar con FT: https://
www.vmware.com/resources/compatibility/search.php

• Intel Sandy Bridge o posterior.

• AMD Bulldozer o posterior.

10.2 Configuración de la red

Antes de activar Fault Tolerance en una máquina virtual, debemos crear una red de tipo vmkernel, se
recomienda que sea un tráfico específico para ello y que la red sea 10 Gb.

#VMwarePorvExperts 392
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Para trabajar con teaming de tarjetas de red, se recomienda crear dos vmkernel y editar la configuración
para que sea activo/pasivo en un vmkernel y en el otro, lo inverso, la misma configuración que se
realiza para disponer de “vMotion acelerado”.

Ejemplo de teaming (cruzado) en un host:

VMkernel-FT-01

vmnic8 —> Activo

vmnic9 —> Pasivo

VMkernel-FT-02

vmnic9 —> Activo

vmnic8 —> Pasivo

#VMwarePorvExperts 393
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

10.3 Activación de Fault Tolerance en una máquina virtual

Cuando activamos FT en una máquina virtual, VMware FT crea dos máquinas virtuales completa. Cada
máquina virtual tiene su propio archivo de configuración .vmx y sus archivos .vmdk. Estas máquinas
virtuales pueden estar en datastores distintos.

Los archivos de la máquina virtual pueden colocarse en el mismo datastore, sin embargo, VMware
recomienda colocar estos archivos en datastores independientes para una mayor disponibilidad.

Imagen de www.awerty.net

Para activar FT, desde vSphere Web Client, botón derecho sobre la máquina virtual y en opciones de
Fault Tolerance, lo activamos:

#VMwarePorvExperts 394
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

Desde el menú Fault Tolerance también podéis “apagar” Fault Tolerance, suspender, reanudar, migrar
la máquina virtual secundaria a otro host, hacer un Test Failover y test de reinicio de la secundaria.

Si cumplimos los requisitos de compatibilidad de CPU, existe la red de vMotion y la red de Fault
Tolerance, al activarlo, el icono de la máquina virtual se hace azul.

vSphere Fault Tolerance incluye archivos compartidos, estos archivos deben almacenarse en un
datastore compartido por todos los hosts del clúster:

• shared.vmft evita el cambio del UUID.

• .ftgeneration para disociación en casos de desconexión entre los hosts principal y secundario.

Además, vCenter Server aplica una “reserva” del total de la memoria virtual configurada en la máquina
virtual. Mientras FT esté configurado en la máquina virtual, no se puede modificar la reserva de
memoria, el tamaño, el límite, el número de vCPU ni los recursos compartidos. Tampoco se pueden
añadir ni eliminar discos de la máquina virtual.

En caso de querer cambiar estos parámetros, debemos de “apagar” FT en la VM (Turno off Fault
tolerance), aplicar los cambios y volver a habilitar FT en la máquina virtual.

10.4 vSphere Fault Tolerance con vSphere HA y vSphere DRS

Fault tolerance es compatible con vSphere HA y vSphere DRS. Cuando DRS está habilitado, DRS
elege el mejor host con menos carga para la máquina virtual secundaria. Si el host falla o se pierde
el acceso al datastore donde reside la máquina virtual primaria, FT entrará en acción y vSphere HA
arrancará la máquina virtual en otro host y reconocerá que se trata de una máquina con la característica
de FT. Se recomienda activar FT en un entorno que al menos tenga tres hosts, para poder levantar la
máquina virtual secundaria en el tercer host en caso de fallo.

#VMwarePorvExperts 395
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt

#VMwarePorvExperts 396
HERRAMIENTA
GRATUITA

NUEVO Veeam Backup & Replication


Community Edition
La herramienta de backup y recuperación GRATUITA
imprescindible para cualquier carga de trabajo

El NUEVO Veeam Backup & Replication Community Además de proteger 10 VMs, Veeam Backup &
Edition es el software de backup GRATUITO Replication Community Edition proporciona backups
imprescindible para VMware, Hyper-V y Nutanix y migración de VMs GRATUITAS e ILIMITADAS
AHV, además de para servidores físicos Microsoft manuales para más VMs, además de la 10 definidas,
y Linux, estaciones de trabajo e instancias. que también quiera proteger. Sin necesidad
Use el NUEVO Veeam Backup & Replication de desplegar agentes, consigue una solución flexible
Community Edition para proteger hasta 10 VMs, y fiable para hacer backup de VM GRATIS para l
o una combinación de VMs, instancias cloud, a gestión diaria de sus cargas de trabajo.
servidores físicos o estaciones de trabajo. Puede
proteger parte de su entorno, su laboratorio Descargar ahora en http://vee.am/vbr-free
doméstico, o usarlo para llevar a cabo migraciones
sin coste alguno.

La edición Community es:


• Potente: Experimente las funcionalidades de backup
completo, recuperación y replicación ofrecidas por
la edición Standard de Veeam Backup & Replication
• Sencillo: Descargue y empiece a proteger
en cuestión de minutos con cualquier hardware
o almacenamiento que ya posea
• Fiable: Configure y olvídese, con la seguridad
de que sus datos estarán protegidos y disponibles,
cuándo y dónde los necesite — It Just Works.
• GRATIS PARA SIEMPRE

NOTA: Community Edition funciona con más


de 10 instancias, ofreciendo backup manual
para un número ILIMITADO de VMs.
Capítulo 9
Backup y Réplicas

Patricio Cerda

#VMwarePorvExperts 399
Capítulo 9 - Backup y Réplicas Patricio Cerda

1. Introducción

La tecnología evoluciona continuamente, así como evolucionan las necesidades de los clientes.
Pasamos de tener Centros de Datos con múltiples servidores físicos, donde los servicios y aplicaciones
se encontraban amarrados al hardware, a tener una infraestructura virtualizada que nos provee de
abstracción de hardware, elasticidad en el uso de recursos, mayor movilidad y disponibilidad, entre
otras ventajas.

La virtualización de servidores solucionó mucho de los problemas que enfrentábamos en los Centros
de Datos tradicionales, pero también abrió las puertas a una nueva revolución tecnológica: el Cloud
Computing. La famosa “nube” nos permitió proveer de portales de auto-servicio, donde los clientes/
usuarios podían provisionar sus propios servicios, aplicaciones o simplemente máquinas virtuales, de
una manera rápida y sencilla gracias a la automatización provista por las soluciones de Cloud.

La adopción de soluciones de Cloud se vio acelerada además por el cambio de paradigma que significó
el concepto de Centro de Datos Definido por Software (SDDC por sus siglas en ingles), donde la
virtualización ya no estaba limitada simplemente a virtualizar servidores, sino que nos permitía además
virtualizar cada aspecto de los centros de datos, incluyendo el provisionamiento de servicios de red
y de almacenamiento. El SDDC nos permitió contar con un nivel de automatización mucho más
profundo, facilitando la adopción de la Cloud.

Como vemos, la evolución de los Centros de Datos es continua, y seguirá evolucionando sin duda.
Pero a pesar de esta evolución continua, hay algo que ha permanecido constante en el tiempo: La
necesidad de proteger la información almacenada en el Centro de Datos.

En la actualidad, las compañías consideran que casi todos sus servicios/aplicaciones son críticas
para el negocio, por lo que la supervivencia de la compañía yace justamente en poder asegurar
la disponibilidad de dichos servicios/aplicaciones. Es bueno destacar este concepto, donde lo que
necesitamos proteger finalmente no serán meramente datos, sino que lo que realmente necesitamos
proteger son las aplicaciones, los servicios que hacen posible que una compañía siga operando y
creciendo en el tiempo.

IMPORTANTE: El concepto clave que debemos recordar no es el respaldo de datos, sino la


disponibilidad de las aplicaciones/servicios.

Así como la tecnología en los Centros de Datos ha evolucionado, es imperativo que las soluciones
de protección de datos evolucionen también. Las soluciones de respaldo que se utilizaban años
atrás son inútiles en un Centro de Datos moderno, y no son capaces de adaptarse a los continuos
cambios y al continuo crecimiento que se presenta en un entorno de Cloud, el cual por su naturaleza
es altamente dinámico. Las soluciones “Legacy” no son capaces de proveernos de la disponibilidad
continua requerida por las aplicaciones y servicios actuales, con RTOs y RPOs de menos de 15 minutos.

Para proteger nuestros servicios en un ambiente virtualizado o de Cloud, deberemos entonces contar
con una herramienta adecuada. En este aspecto podemos mencionar:

• Veeam Backup and Replication

• Nakivo Backup and Replication

• Vembu VMBackup

• Dell EMC Avamar

• HPE Data Protector.

#VMwarePorvExperts 400
Capítulo 9 - Backup y Réplicas Patricio Cerda

No solo las soluciones de protección de datos han evolucionado, finalmente éstas son solo herramientas.
También han evolucionado las buenas prácticas a la hora de proteger la información contenida en el
Centro de Datos.

En este capítulo hablaremos sobre protección de datos en el Centro de Datos moderno, específicamente
sobre cómo asegurar la continuidad de las aplicaciones y servicios de una compañía. Aquí
incluiremos además algunos Conceptos Claves y Buenas Prácticas recomendadas para las soluciones
de protección de datos previamente mencionadas.

Más adelante además describiremos de manera sencilla todo el proceso de diseño e implementación
de Veeam Backup and Replication, y como usar Veeam ONE y otras herramientas para ayudarnos en
este proceso.

1.1 Conceptos Clave

1.1.1 Recovery Point Objective (RPO): Punto objetivo de recuperación en español


RPO es el punto en el tiempo en el cual los datos deben ser recuperados luego de una falla. En
palabras simples equivale a la cantidad de datos que estoy dispuesto a sacrificar ante una falla.

Por ejemplo: Un RPO de 24 horas significa que protegeremos los datos cada 24 horas, como podría
ser la ejecución de un respaldo cada día a las 10 PM. ¿Qué significa esto? Que si nuestro último
respaldo fue ejecutado ayer a las 10 PM, y hoy se ha producido una falla a las 9:45 PM, deberemos
recuperar los datos desde el ultimo respaldo disponible (ayer a las 10 PM), lo cual implica que todos
los cambios que se han producido desde ese último respaldo, hasta el momento de la falla, están
irremediablemente perdidos.

El RPO no depende directamente de la solución de protección de datos que utilicemos (aunque puede
estar limitado por ésta), sino que depende de las necesidades del negocio. Perfectamente podríamos
tener algunas aplicaciones protegidas con RPOs de 24 horas, mientras que otras aplicaciones más
críticas podrían tener un RPO de solo minutos, o incluso protección continua si así lo permite la solución
de protección de datos utilizada.

IMPORTANTE: El RPO finalmente dependerá del presupuesto del que dispone el cliente, entendiendo
que un RPO más bajo, implica necesariamente invertir más dinero en una solución e infraestructura
adecuados para alcanzar este RPO.

1.1.2 Recovery Time Objective (RTO): Tiempo objetivo de recuperación en español


RTO es básicamente el tiempo máximo dentro del cual un servicio o aplicación debe ser restaurado
luego de una falla.

El RTO podría ser de minutos, horas o incluso de días dependiendo de qué tan crítico es el servicio
que ha fallado. Las soluciones de protección de datos cuentan con distintas técnicas de recuperación
que permiten restaurar los datos requeridos en periodos de tiempo muy breves y con distintos niveles
de granularidad.

Al igual que el RPO, el RTO también dependerá del presupuesto disponible para este proyecto. Un

#VMwarePorvExperts 401
Capítulo 9 - Backup y Réplicas Patricio Cerda

RTO más bajo (minutos) implica una inversión considerablemente más alta que un RTO de varios días.

1.1.3 Business Continuity: Continuidad de Negocios en español


Business Continuity se refiere a la capacidad de una organización o compañía para planificar e
implementar los procesos y medidas necesarias para reanudar las operaciones normales del negocio
después de un desastre o cualquier evento que afecte la continuidad del negocio.

En cualquier plan de continuidad de negocios el foco es el negocio mismo, y debe estar diseñado para
reducir posibles bajadas de servicio al mínimo, e idealmente evitar cualquier interrupción, permitiendo
ofrecer un uptime de 24/7.

1.1.4 Disaster Recovery: Recuperación ante desastres en español


Concepto similar a Business Continuity, pero en este caso, un plan de Disaster Recovery estará centrado
en la tecnología y datos involucrados en la recuperación de los servicios luego de una interrupción de
los mismos. Un plan de Disaster Recovery es básicamente un conjunto de procedimientos donde el
objetivo es recuperar los datos y lograr que la infraestructura TI vuelva a operar con normalidad luego
de un desastre.

Mientras antes una organización recupere sus sistemas de un desastre, más rápido dicha organización
podrá reanudar sus operaciones normales de negocio. Es por esto que usualmente Disaster Recovery
se considera como un componente clave en el diseño del plan de Business Continuity.

NOTA: En algunos casos, el término “Backup/Respaldo” es usado erróneamente como un sustituto al


termino Disaster Recovery. Sin embargo, debemos tener en cuenta que un plan de Disaster Recovery
no está limitado al uso de una solución de Backup, sino que ésta es simplemente un componente
tecnológico en un proceso de recuperación mucho más extenso. Los respaldos son parte integral
de un plan de Disaster Recovery (DRP), pero no puede ser considerado como el único componente
del mismo.

1.1.5 Regla 3-2-1


Muchos expertos aconsejan que, para poder construir una solución de protección de datos sólida, y así
contar con un plan de Disaster Recovery exitoso, se debe seguir la regla 3-2-1.

¿Y que significa esta regla 3-2-1? Pues muy fácil:

• 3: Se debe contar con al menos 3 copias de los datos

• Primera copia serían los datos originales en producción.

• Segunda copia sería un backup primario.

• Tercera copia sería un backup secondario.

• 2: Se debe utilizar al menos dos tipos diferentes de almacenamiento para guardar las copias de los
datos. Podemos utilizar, por ejemplo:

• Discos locales y Cloud

• Almacenamiento vía FC y respaldos en Cintas

#VMwarePorvExperts 402
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Almacenamiento vía NFS y respaldos sobre appliance de Deduplicación.

• 1: Al menos una de las copias debiera permanecer fuera del sitio principal, por ejemplo:

• En la Cloud

• Respaldo secundario en un sitio remoto.

• Respaldo en cintas las cuales luego son transportadas a una ubicación segura o bóveda
externa.

Siguiendo esta regla, si un desastre ocurre afectando los datos de producción y además los respaldos
locales, aun podemos contar con los respaldos que tenemos en una ubicación remota para llevar a
cabo la recuperación.

1.2 Buenas Prácticas para Disaster Recovery

1.2.1 Definir el alcance y dependencias


Actualmente la gran mayoría de aplicaciones y servicios críticos del negocio se ejecutan dentro de una
VM. Aquí podemos encontrar VMs ejecutando diversos servicios como bases de datos, servicios web,
ERPs, CRMs, servicios de correo y mensajería, entre otros.

Claramente no todas las aplicaciones/servicios serán consideradas críticas para el negocio, teniendo
en cuenta además que tendremos un número importante de VMs ejecutando aplicaciones que se
encuentran en etapa de desarrollo, pruebas o QA. En este sentido es importante que se identifiquen
los servicios críticos del negocio, así como la o las VMs utilizadas para soportar dichos servicios. Este
proceso debe incluir además cualquier dependencia requerida para el correcto funcionamiento de los
servicios o aplicaciones que intentamos proteger. Por ejemplo, si deseamos proteger un servicio de
correo provisto por MS Exchange, debemos procurar además proteger el servicio de directorio (Active
Directory) del cual Exchange depende directamente.

#VMwarePorvExperts 403
Capítulo 9 - Backup y Réplicas Patricio Cerda

Al identificar los servicios y aplicaciones que se ejecutan en cada VM, podemos proceder con una
priorización de estas últimas, de manera de proteger con mayor prioridad las VMs que hospeden los
servicios más críticos de la compañía y que requerirán RPOs y RTOs más bajos.

En este mismo proceso podemos excluir VMs que no ofrezcan servicios críticos del negocio, o que
simplemente no ofrezcan ningún servicio que se encuentre actualmente en producción, lo cual nos
permite reducir el uso de recursos en la solución de respaldo.

1.2.2 Definir los requerimientos de conectividad


Un punto crítico para cualquier solución de Respaldo serán los recursos de red disponibles, tanto para
conexión local o remota.

Para realizar respaldos locales, el uso de ancho de banda dependerá de la conexión utilizada
para obtener los datos de las VMs desde el hipervisor, así como de los distintos componentes de
arquitectura de la solución de respaldo. Por ejemplo, si entre el Hipervisor y el Repositorio tendremos
un componente intermedio como un Proxy, debemos considerar también el ancho de banda requerido
para enviar los datos desde el Proxy hasta el repositorio.

1.2.3 Definir los requerimientos de RTO y RPO


Ya previamente definimos ambos conceptos. Ahora lo que necesitamos es poder definir los
requerimientos del cliente respecto a ambos.

El RTO y RPO estará basado finalmente en una decisión de negocio, y estará limitado muchas veces
por las restricciones de presupuesto impuestas por el cliente. Con las soluciones de Backup existentes
actualmente, podemos conseguir RTOs y RPOs por debajo de los 15 minutos, pero para conseguir
dichos tiempos deberemos diseñar una solución que cuente con la performance y capacidad adecuada,
lo cual suele significar una mayor inversión en hardware y licencias.

Debemos considerar además que el RTO y RPO no será necesariamente el mismo para todas las
VMs. Usualmente tendremos RTOs y RPOs más agresivos para las VMs que contengas servicios y
aplicaciones críticos para el negocio, mientras que servicios menos críticos podrían considerar un RTO
y RPO más alto.

1.2.4 Consistencia de los respaldos


Un punto importante al momento de seleccionar y diseñar la solución de Respaldo a utilizar, es la
posibilidad de asegurar la consistencia de los respaldos, específicamente la consistencia a nivel de
aplicaciones y/o a nivel de sistema de archivos.

La mayoría de las soluciones de respaldo para VMware están basadas en Snapshots de las VMs,
no obstante, esto no es suficiente ya que, si bien asegura la consistencia a nivel de disco virtual, no
asegura la consistencia a nivel de aplicaciones y/o de sistema de archivos.

Para lograr dicho nivel de consistencia, se requiere de un nivel de integración mayor con el sistema
operativo y las aplicaciones, lo cual en el caso de sistemas operativos Windows, se traduce en
integración con Microsoft VSS.

Debido a esto, la solución seleccionada debe ser capaz de proveer este nivel de integración con VSS,
así como también de proveer funcionalidades de integración similares para sistemas operativos que

#VMwarePorvExperts 404
Capítulo 9 - Backup y Réplicas Patricio Cerda

no cuenten con VSS (Linux o versiones más antiguas de Windows).

#VMwarePorvExperts 405
Capítulo 9 - Backup y Réplicas Patricio Cerda

2. Diseño y Dimensionamiento de la Infraestructura

Ya que hemos cubierto una serie de conceptos y buenas prácticas asociadas a soluciones de respaldo
y de Disaster Recovery, ahora nos enfocaremos en el diseño y dimensionamiento específico para
Veeam Backup and Replication, incluyendo una serie de buenas prácticas específicas para esta
solución.

Probablemente uno de los puntos más importantes para asegurar el correcto funcionamiento de
cualquier solución, es contar con un buen diseño que permita cumplir con los requerimientos del
cliente, así como también un dimensionamiento apropiado para asegurar que no tendremos problemas
inesperados de capacidad y/o de performance.

A continuación, mencionaremos cada uno de los componentes de la arquitectura de Veeam Backup


and Replication, y sus recomendaciones de diseño y dimensionamiento.

2.1 Veeam Backup Server

El “cerebro” de la solución, el cual provee la interfaz única de configuración y administración de todos


los componentes de la infraestructura de respaldos. Coordina tareas, controla la ejecución de los
Jobs que han sido programados, y controla también la asignación de recursos para cada tarea, entre
otras responsabilidades.

2.1.1 Recomendaciones de diseño


• Veeam Backup Server debe ser instalado sobre un servidor basado en Windows Server. Se
recomienda utilizar la versión más reciente de Windows Server, para evitar problemas de
compatibilidad al realizar restauración de archivos con Instant File Leverl Recovery (IFLR).

• Es posible instalar Veeam Backup Server sobre una máquina virtual o en un servidor físico, siendo
ambas opciones soportadas por Veeam. Yo siempre recomiendo el uso de máquina virtual, ya
que me permite aprovechar las ventajas propias de la virtualización, como la independencia del
hardware, la movilidad con vMotion, portabilidad, alta disponibilidad, etc.

• En caso de tener dos Centros de Datos en modalidad Activo-Standby, se recomienda desplegar


Veeam Backup Server en el sitio Standby. Esto permite que en caso de una falla completa del
Centro de Datos principal (Activo), contemos en todo momento con acceso a la interfaz de Veeam
Backup Server para el proceso de Failover y/o restauración.

• En caso de tener dos o más Centros de Datos, donde todos sean utilizados por servicios/aplicaciones
críticas para el negocio, Veeam Backup Server puede ser deplegado en cualquiera de los Centro
de Datos. En caso de utilizar una máquina virtual para Veeam Backup Server, se recomienda
replicarla…. ¡¡¡Con Veeam Backup and Replication!!!

2.1.2 Guías de dimensionamiento


Muchas veces el dimensionamiento de Veeam Backup Server no se considera como algo critico al ser
un componente de administración, no obstante, es sumamente importante dimensionar adecuadamente
este componente, para asegurar que todos los Jobs puedan ser ejecutados adecuadamente según la

#VMwarePorvExperts 406
Capítulo 9 - Backup y Réplicas Patricio Cerda

configuración presente.

• Se requiere un mínimo de 2 cores de CPU y 8GB de RAM.

• Por cada 10 Jobs concurrentes se requieren 1 core y 4GB de RAM. En este punto se vuelve
importante mantener un número reducido de Jobs, evitando por ejemplo tener 1 máquina virtual
por Job, lo cual obligaría a aumentar enormemente los recursos requerido por Veeam Backup
Server para gestionar todos los Jobs concurrentes que decidamos crear.

• 40 GB en disco

• En caso de habilitar la opción de Indexación de archivos:

• 100MB por cada millón de archivos sobre sistemas operativos Windows.

• 50MB por cada millón de archivos sobre sistemas operativos Linux.

2.2 Veeam Proxy Server

El “Músculo” de la solución. Un Proxy Server es un componente que se ubica entre un origen y un


destino de datos. De esta manera, es el Proxy Server el encargado de obtener los datos que deseamos
proteger, por ejemplo, obteniendo los datos de una VM desde un host ESXi, para luego enviarlos a un
destino, por ejemplo a un Repositorio de respaldos.

Es el Proxy Server el encargado de procesar los Job de Respaldo o Replicación, incluyendo la


aplicación de los algoritmos de Deduplicación y Compresión nativos de Veeam. Del mismo modo, si
hemos habilitado la opción de Encriptación de los respaldos, será el Proxy Server el encargado del
proceso de Encriptación de los datos.

2.2.1 Recomendaciones de diseño


• Un Proxy Server utiliza un servidor con Windows Server (no hay opción de uso de Linux), y debe
ser además un servidor dedicado para esta función.

• Un Proxy Server puede ser un servidor físico o una máquina virtual en caso de que vayamos a
respaldar máquinas virtuales sobre VMware. En caso de utilizar Hyper-V, el Proxy Server debe ser
obligatoriamente un servidor físico.

• Se recomienda desplegar al menos dos Proxy Servers, de manera de tener redundancia para este
rol.

• Se recomienda además desplegar al menos un Proxy Server adicional para tareas de Restauración.

Pónganse en el peor caso, en que todos los Proxy Servers están trabajando en la ejecución de los
respaldos diarios, y en ese momento requieren llevar a cabo una restauración de una máquina virtual.
Si todos los Proxy Servers están ocupados con los respaldos, deberán cancelar uno de estos respaldos,
o esperar a que finalicen para proceder con la restauración.

En cuanto a los Modos de Transporte (VMware), se cuenta con las siguientes recomendaciones:

• Direct Storage Access es la opción más recomendada, siendo la segunda opción el modo Virtual
Appliance (Hot-Add) dejando al modo Network (NBD) como última opción.

#VMwarePorvExperts 407
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Direct SAN Access es el modo recomendado si las máquinas virtuales se encuentran almacenadas
en una cabina de almacenamiento con conexión iSCSI o Fiber Channel. En este caso el Proxy
Server debe ser obligatoriamente un servidor físico, con acceso a la cabina de almacenamiento
productiva, por lo que se debe haber realizado también el proceso de LUN Masking y Zonificación
apropiados.

• Direct NFS Access es el modo recomendado si las máquinas virtuales se encuentran almacenadas
en una NAS, utilizando Datastores NFS. En este caso el Proxy Server puede ser un servidor Físico
o Virtual.

• Virtual Appliance (Hot-Add) es el modo recomendado para ambientes altamente dinámicos, donde
el número de Datastores varía constantemente. Es el segundo modo recomendado en caso que el
modo Direct Storage Access no esté disponible.

• Virtual Appliance (Hot-Add) es el modo recomendado para plataformas que utilicen Virtual SAN
(vSAN), así como también cuando se utilicen Datastores locales.

• Virtual Appliance (Hot-Add) no es recomendado cuando las máquinas virtuales se encuentran


almacenadas en un Datastore NFS. En ese caso se recomienda el uso del modo Direct NFS
Access o el modo Network (NBD)

• Modo Network (NBD) es solo recomendado como última opción, en caso de que los modos
anteriores no estén disponibles o hayan fallado. El modo Network no es recomendado cuando la
conectividad de red es de solo 1Gbps, donde la performance es extremadamente pobre.

Direct Storage
Almacenamiento Virtual Appliance Network Mode
Access
Proxy físico con acceso
SAN Fibre Channel Proxy Virtual en Proxy físico o virtual
directo a la SAN
(FC) ejecución sobre conectado a los
mediante FC.
un host ESXi, con hosts ESXi mediante
Proxy físico o virtual conexión al dispositivo la interface de
SAN iSCSI con acceso directo a la de almacenamiento. Management.
SAN mediante iSCSI.
Proxy físico o virtual
Storage NFS con acceso al Storage No recomendado
via NFS.
Almacenamiento Proxy Virtual en cada
No soportado
Local host ESXi.

2.2.2 Guía de dimensionamiento


El dimensionamiento del Proxy Server es crucial, ya que este componente será el encargado de
ejecutar efectivamente los respaldos, replicaciones y también restauraciones. Un dimensionamiento
inadecuado impactará negativamente la ejecución de los Jobs, y podrían darse el caso de que no
puedan completar la ejecución de todos los Jobs en la ventana de respaldo impuesta por el cliente.

#VMwarePorvExperts 408
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Se requiere un mínimo de 2 GB de RAM + 500MB adicionales por cada tarea concurrente. No


obstante, estos valores son mínimos y solo debieran utilizarse en casos extremos.

• La recomendación es utilizar 1 core de CPU y 2GB de RAM por cada tarea concurrente. Tener
en consideración que una tarea concurrente es el proceso de respaldar, replicar o restaurar un
disco virtual. Por ejemplo, si desean respaldar una máquina virtual con 2 discos virtuales, el Proxy
ejecutará 2 tareas para proceder con el respaldo.

• Por ejemplo, si se desea ejecutar 60 tareas concurrentes, se necesitarán 60 cores de CPU y 120GB
en RAM. Esta capacidad de procesamiento puede ser dividida en múltiples Proxy Server sobre
los cuales Veeam balanceará la carga de manera automática. Esto permitirá además contar con
mayor disponibilidad del servicio, ya que si un Proxy Server falla, aún quedan otros para continuar
con la ejecución de los Job.

• Se recomienda además desplegar al menos 1 Proxy Server adicional para tareas de restauración
(explicado anteriormente). Este proxy podría ser virtual, utilizando el modo de transporte Virtual
Appliance (Hot-Add).

2.3 Veeam Backup Repository

Cuando hablamos de repositorio, hablamos simplemente de una ubicación donde Veeam Backup
and Replication almacenará los archivos de respaldo. Técnicamente hablando, un Repositorio es
simplemente una “carpeta” en un dispositivo de almacenamiento.

En una infraestructura con Veeam Backup and Replication podemos implementar múltiples tipos de
repositorio, considerando que Veeam es totalmente agnóstico con el tipo de almacenamiento utilizado
para almacenar los respaldos, pudiendo por ejemplo utilizar:

• Servidores con discos locales

• Almacenamiento sobre cabina iSCSI o Fiber Channel

• Carpeta compartida vía NFS o CIFS

• Appliance de Deduplicación

Aquí un comparativo de los tipos de almacenamiento que pueden ser utilizados como Repositorio.

Tipo de Repositorio Tipo de Almacenamiento Procesamiento de Datos


Disco local, Almacenamiento El servicio Veeam data mover
conectado directamente, o es desplegado cuando el
Servidor Windows
LUNs conectadas vía iSCSI o servidor es añadido a Veeam
FC. Backup Server.

#VMwarePorvExperts 409
Capítulo 9 - Backup y Réplicas Patricio Cerda

Disco local, Almacenamiento El servicio Veeam data mover


conectado directamente, LUNs service es desplegado cuando
Servidor Linux
conectadas vía iSCSI o FC, o se ejecuta un Job que utilice
shares NFS. dicho Repositorio.
La transferencia de datos es
llevada a cabo mediante el
CIFS (SMB) share Share CIFS (SMB)
servicio Veeam Data Mover en
el Gateway Server (Windows)
La transferencia de datos es
• EMC Data Domain llevada a cabo mediante el
servicio Veeam Data Mover en
Appliance de Deduplicación • ExaGrid
el Gateway Server (Windows),
• HPE StoreOnce o directamente en el caso del
appliance Exagrid.

Un Job de Respaldo puede utilizar un único Repositorio para almacenar los archivos de respaldo, a la
vez que un Repositorio puede ser utilizado por múltiples Jobs. Como alternativa tenemos también el
uso de Scale-Out Backup Repository (SOBR).

SOBR es básicamente una funcionalidad que permite agrupar múltiples Repositorios (pudiendo
ser de distinto tipo) en una única unidad lógica. De esta manera, podemos configurar un Job de
Respaldo para enviar los archivos a esta unidad lógica o Scale-Out Backup Repository, y será Veeam
quien decida en que repositorio especifico serán almacenados los archivos, y también decidirá si todos
los archivos de la cadena de respaldo utilizarán un único repositorio o si los respaldos incrementales
utilizaran un repositorio distinto al respaldo Full.

NOTA: SI quiere saber más de Scale Out Backup Repository puede obtener mayor información en el
siguiente link: https://goo.gl/qGBiUu

2.3.1 Recomendaciones de Diseño


Siendo Veeam totalmente agnóstico respecto al tipo de almacenamiento que pueden utilizarse
para almacenar los archivos de respaldo, existen algunas recomendaciones que debemos tener en
consideración:

• El Repositorio de respaldo contendrá información esencial de la compañía y que será utilizada en


caso de que se produzca alguna emergencia. Debido a esto, el almacenamiento utilizado debe ser
suficientemente robusto, con elementos redundantes que permitan asegurar que los Respaldos
siempre estarán disponibles en caso de ser necesario. Aquí no valen esas NAS tipo IOMEGA o
similar, que son muy buenas para ambientes de laboratorio o para archivos personales, pero que
no proveen la robustez requerida en un entorno corporativo.

• ¡¡¡La capacidad no lo es todo!!! También debemos asegurarnos de que el almacenamiento elegido


nos permita realizar operaciones de lectura y escritura a una velocidad adecuada, que nos permita
cumplir con las ventanas de respaldo impuestas por el cliente, así como también con los tiempos
de recuperación (RTO). No sirve de mucho si compramos una cabina de almacenamiento solo
con discos SATA de 8TB, que nos dará una muy alta capacidad en un espacio físico reducido y a
bajo costo, si luego la ejecución de los respaldos (y más crítico aun, de las restauraciones) será
dolorosamente lento.

• El almacenamiento debiera ser escalable, de manera de poder ir escalando en el tiempo a medida

#VMwarePorvExperts 410
Capítulo 9 - Backup y Réplicas Patricio Cerda

que la compañía va creciendo, y con ésta también va creciendo la información a proteger.

• Podemos utilizar una estrategia de almacenamiento en capas (Tiers), donde por ejemplo los
respaldos más recientes (los últimos 7 días) utilicen una cabina de almacenamiento de alta
performance, pero que no requiere de una gran capacidad.

Al mismo tiempo, podríamos contar con una segunda cabina de almacenamiento de mucho mayor
capacidad, pero con una performance más restringida, lo que nos permitiría almacenar respaldos por
un periodo más extenso, de meses o años (archiving), sin incurrir en altos costos de almacenamiento.

2.3.2 Guía de dimensionamiento


El dimensionamiento de los Repositorios tiene dos partes. En primer lugar, debemos dimensionar
adecuadamente el Veeam Backup Repository Server, lo cual muchas veces no se toma en cuenta ya
que nos enfocamos directamente en la capacidad de almacenamiento.

• Mínimo recomendado 2 cores de CPU para el sistema operativo.

• Se recomienda además 1 core de CPU por cada Job concurrente.

• Finalmente se recomiendan 4GB de ram por cada core de CPU.

NOTA: Estos mismos requerimientos aplican en caso de utilizar un Gateway Server para montar
carpetas compartidas CIFS o Appliances de deduplcación.

Luego viene la parte más crítica, que es el dimensionamiento de la capacidad requerida en los
Repositorios de respaldo. Debemos considerar que existen muchos factores que van a tener un
impacto en este dimensionamiento, y que deben ser considerados a la hora de realizar los cálculos:

• Tamaño total de las VM a ser respaldadas.

• Frecuencia de los respaldos (diario, semanal, mensual, etc.). La frecuencia de los respaldos depende
directamente del RPO que haya solicitado el cliente, y tendrá un impacto en el dimensionamiento,
así como también en los costos asociados al proyecto.

• Periodo de retención de los respaldos (días, meses, años, etc.). Esto también es un requerimiento
del negocio, por lo que debemos tener claro que a más retención, mayor capacidad será requerida,
y mayor será el costo del proyecto.

• Qué tipo de Respaldo se llevará a cabo: Incremental, Reverse Incremental o Forever Forward
Incremental. Esta decisión afectará la capacidad de almacenamiento requerida, y también tendrá
un impacto en la performance de lectura/escritura del Repositorio de Respaldo.

NOTA: Si desean ver una explicación más detallada respecto al impacto en la performance de cada tipo
de respaldo, pueden obtenerla desde el siguiente link: https://goo.gl/5R6DoB. También a continuación
una pequeña tabla con la comparación de cada tipo de respaldo.

Método de Backup Impacto en el Repositorio I/O


Active full 1 write I/O
Forever Forward incremental 3 I/O (1 I/O read + 2 I/O write)
Forward incremental 1 write I/O
Reverse incremental 3 I/O (1 I/O read + 2 I/O write)

#VMwarePorvExperts 411
Capítulo 9 - Backup y Réplicas Patricio Cerda

Synthetic full 2 I/O (1 I/O read + 1 I/O write)


Synthetic full with transform to rollbacks 4 I/O (2 I/O read + 2 I/O write)

Existen otros factores que debemos considerar también a la hora de dimensionar la capacidad
requerida para Repositorio:

• Tasa de Cambio: Básicamente necesitamos saber cuántos datos nuevos son creados, o cuantos
datos son modificados en un periodo de tiempo. Esta información es esencial para poder calcular el
tamaño de los respaldos incrementales. Por ejemplo, si deseamos hacer respaldos incrementales
diarios, con un Full periódico (semanal o mensual), necesitamos saber cuántos datos son creados/
modificados durante esas 24 horas que tenemos de RPO en un respaldo diario.

Pero ¿cómo calculamos esto? Bueno, basado en múltiples implementaciones, en general se


considera apropiado considerar una tasa de cambio diaria de entre 5% y 10%, siendo 10%
considerado generalmente como un valor conservador con el que estaríamos seguros de no
quedarnos cortos en el cálculo de capacidad. Si desean tener un número más preciso, podrían
utilizar Veeam ONE, el cual cuenta con un reporte llamado “VM Change Rate Estimation”, el cual
nos entrega con detalle la tasa de cambio de las VMs.

• Ahorro por Compresión y/o Deduplicación: Veeam cuenta con algoritmos nativos de compresión
y deduplicación que vienen habilitados por defecto. Entre ambos se puede conseguir una reducción
de un 2:1 (50%) en el tamaño de los archivos de respaldo. Esto quiere decir que, si las VM
consumen 10TB de capacidad de almacenamiento, un respaldo Full requeriría aproximadamente
5TB de capacidad.

Este ahorro puede ser incluso mayor, pero depende mucho en el tipo de información a respaldar,
por lo que en general se recomienda utilizar una tasa de ahorro conservadora de 50%.

Este Ahorro también puede variar si utilizamos un Appliance de Dedupliación, los cuales cuentan
con algoritmos de deduplicación mucho más avanzados que proveen una tasa de ahorro mucho
mayor, que puede incluso llegar hasta el 95% (según las especificaciones de ciertos Appliances).

#VMwarePorvExperts 412
Capítulo 9 - Backup y Réplicas Patricio Cerda

IMPORTANTE: Si se decide utilizar Scale-Out Backup Repository (SOBR), esto activará otra
funcionalidad llamada Per-VM Backup File, lo cual reduce enormemente la capacidad de deduplicación
de Veeam, por lo que el ahorro provisto por la Deduplicación nativa provista por Veeam prácticamente
desaparece.

Ahora con toda esta información, debemos realizar el dimensionamiento, para lo cual podemos
proceder de manera manual, usando calculadora o Excel para los cálculos, o podemos apoyarnos en
algunas herramientas ya existentes.

• Aquí les recomiendo utilizar “The Restore Point Simulator” de Timothy Dewin, System Engineer de
Veeam: http://rps.dewin.me

• Otro simulador mucho más completo es el que ha publicado Hannes Kasparick, también empleado
de Veeam, pero éste aún se encuentra en construcción, por lo que podrían presentarse algunos
fallos de momento: http://sizer.kasparick.com

NOTA: Los Partners de Veeam tienen acceso a una herramienta similar en el portal Veeam ProPartner.

EJEMPLO 1

Veamos un ejemplo práctico:

• Deseamos respaldar 50TB de datos.

• Deseamos respaldos diarios, con un Full semanal.

• Deseamos 15 días de retención.

• Utilizaremos una tasa de cambios estándar de 5%.

• Utilizaremos una tasa de reducción conservadora de 50%

• El respaldo Full semanal puede ser Active Full o Synthetic Full

#VMwarePorvExperts 413
Capítulo 9 - Backup y Réplicas Patricio Cerda

Una vez ingresados todos los datos, simplemente le damos click al botón Simulate, y veremos la
capacidad requerida para el Repositorio según los requerimientos antes expuestos.

Como podemos ver, en este caso hemos de requerir aproximadamente 110TB de capacidad de
almacenamiento para poder cumplir con todos los requerimientos solicitados por el cliente.

#VMwarePorvExperts 414
Capítulo 9 - Backup y Réplicas Patricio Cerda

NOTA: Si quieren ver en detalle el funcionamiento de cada método de respaldo con Veeam, pueden ir
al siguiente link: https://goo.gl/cdkimx

EJEMPLO 2

Veamos una pequeña variación del ejemplo anterior. En este caso mantendremos la retención de
15 días, pero eliminaremos el respaldo Full semanal, por lo que utilizaremos el método de respaldo
Forever Forward Incremental. Recuerden que cada método de respaldo tiene sus pros y sus contras,
específicamente en lo que se refiere a capacidad de almacenamiento y a la performance (IOPS).

#VMwarePorvExperts 415
Capítulo 9 - Backup y Réplicas Patricio Cerda

Como podemos ver, la capacidad requerida se ha reducido de 110TB a aproximadamente 56TB. Esto
es simplemente porque ya no se requiere llevar a cabo un respaldo Full Semanal.

A pesar de lo anterior, donde logramos un ahorro importante en la capacidad de almacenamiento, no


debemos olvidar que el método Forever Forward Incremental genera una cantidad de operaciones de
lectura/escritura mucho mayor que el método de respaldo Incremental con Full periódicos, por lo que
deberemos considerar una cabina de almacenamiento con una performance acorde a esta necesidad.

#VMwarePorvExperts 416
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. Instalación de Veeam Backup and Replication

Ya que hemos completado la etapa de diseño y dimensionamiento, llega la hora de implementar


Veeam Backup and Replication. A continuación, iremos detallando los pasos de instalación para los
componentes principales, así como los pre-requisitos para una instalación exitosa.

3.1 Instalar Veeam Backup Server

3.1.1 Requisitos previos


Hardware

• CPU: Procesador x86-64, se recomienda un mínimo de 4 cores. Revisar el apartado de


dimensionamiento en el capítulo anterior.

• Memoria: Mínimo recomendado 8GB de RAM. Revisar el apartado de dimensionamiento en el


capítulo anterior.

• Almacenamiento: 5GB para la instalación del producto, más 4.5GB para la instalación de .NET
Framework 4.6. Revisar el apartado de dimensionamiento en el capítulo anterior.

• Network: Al menos una conexión de 1Gbps o más rápida.

Software

1. Sistemas operativos soportados para la instalación:

• Microsoft Windows Server 2019

• Microsoft Windows Server 2016

• Microsoft Windows Server 2012 R2

• Microsoft Windows Server 2012

• Microsoft Windows Server 2008 R2 SP1

• Microsoft Windows Server 2008 SP2

• Microsoft Windows 10

• Microsoft Windows 8.x

• Microsoft Windows 7 SP1

2. Microsoft .NET Framework 4.6

3. Microsoft Windows Installer 4.5

4. Microsoft SQL Server Management Objects

5. Microsoft SQL Server System CLR Types

#VMwarePorvExperts 417
Capítulo 9 - Backup y Réplicas Patricio Cerda

6. Microsoft Report Viewer Redistributable 2015

7. Microsoft Universal C Runtime

NOTA: Durante la instalación, el asistente verificará si todos los pre-requisitos de software se cumplen
en el servidor donde se está instalando Veeam Backup and Replication. Si parte del software requerido
no se encuentra instalado, el asistente ofrecerá instalar dicho software faltante automáticamente.

Base de Datos

• Microsoft SQL Server 2017

• Microsoft SQL Server 2016 (Microsoft SQL Server 2016 SP1 Express Edition is included in the
setup)*

• Microsoft SQL Server 2014

• Microsoft SQL Server 2012 (Microsoft SQL Server 2012 SP4 Express Edition is included in the
setup)**

• Microsoft SQL Server 2008 R2

• Microsoft SQL Server 2008

NOTA: Se soportan instancias SQL locales o remotas, incluyendo versiones Express y Completas de
SQL Server.

IMPORTANTE: SQL Express está soportado por Veeam Backup and Replication, pero se recomienda
para escenarios con un máximo de 500 máquinas virtuales a proteger.

SQL Express SQL Standard / Enterprise


Unico socket de CPU Yes* Yes
Multiples sockets de CPU No Yes
Numero de VMs. <=500 >500
Tamaño de la Base de Datos < 10 GB =>10 GB
Jobs Concurrentes <=25 Minimo: 2 CPU cores y 4 GB RAM
Jobs Concurrentes <=50 Minimo: 4 CPU cores y 8 GB RAM
Jobs Concurrentes <=100 Minimo: 8 CPU cores y 16 GB RAM

3.1.2 Procedimiento de instalación


La instalación de Veeam Backup Server es un proceso bastante sencillo, el cual revisaremos a
continuación. Debemos destacar además que Veeam Backup Server es el único servidor donde
debemos llevar a cabo la instalación de Veeam Backup and Replication. Los demás roles como Proxy,
Repository Server, Mount Server, WAN Accelerator y otros, solo requieren el despliegue de algunos
componentes de software que son desplegados directamente desde el Veeam Backup Server cuando
le asignamos un rol a uno de los servidores registrados. Revisaremos ese proceso durante esta sección

#VMwarePorvExperts 418
Capítulo 9 - Backup y Réplicas Patricio Cerda

de instalación.

Hay que asegurarse de:

• Cumplir con todos los requerimientos de software y hardware antes mencionados.

• Cuenta de usuario con los privilegios necesarios para llevar a cabo la instalación.

• Conectividad con otros componentes de la infraestructura Veeam.

• Si se va a utilizar una instancia dedicada de SQL Server, esta debe ser instalada previamente antes
de proceder con la instalación.

A continuación, el proceso de instalación:

1. Descargar la última versión de la imagen de instalación de Veeam Backup and Replication desde
el sitio de Veeam.

2. Montar la imagen de instalación en el servidor donde se planea instalar Veeam Backup and
Replication.

3. Despues que se ha montado la imagen, Autorun iniciará el asistente con las opciones de instalación.
Si Autorun no está disponible o se encuentra deshabilitado, ejecutar el archivo “Setup.exe” desde
la imagen.

4. En la sección Veeam Backup and Replication, hacer click en Install

5. Leer y aceptar los acuerdos de licencia.

6. En el paso “Provide License” se debe especificar la licencia de Veeam que se desea instalar. Aquí
existen tres opciones:

a. Utilizar la licencia que haya adquirido el cliente.

b. Utilizar una licencia de evaluación, la cual es enviada al descargar la imagen.

c. No utilizar licencia, en cuyo caso Veeam Backup and Replication se instalará en modo

#VMwarePorvExperts 419
Capítulo 9 - Backup y Réplicas Patricio Cerda

Community Edition.

7. Hacer click en Browse y luego seleccionar el archivo de licencia.

8. En el paso “Program Feature” se deben seleccionar los componentes que el asistente instalará en
el servidor, y seleccionar la carpeta de instalación. El asistente instalará por defecto los siguientes
componentes:

a. Veeam Backup & Replication

b. Veeam Backup Catalog (componente responsible de almacenar los datos de indices de los
archivos de las VM respaldadas)

c. Veeam Backup & Replication Console

9. El asistente también instalará los siguientes componentes en segundo plano. Aquí no tenemos la
opción de NO instalarlos. Estos componentes no requieren licencia adicional.

a. Veeam Explorer for Microsoft Active Directory

b. Veeam Explorer for Microsoft Exchange

c. Veeam Explorer for Oracle

d. Veeam Explorer for Microsoft SQL Server

e. Veeam Explorer for Microsoft SharePoint

10. Debemos seleccionar también la carpeta de instalación. Podemos dejar el directorio por defecto
(C:\Program Files\Veeam\Backup and Replication\), o seleccionar un directorio personalizado.

#VMwarePorvExperts 420
Capítulo 9 - Backup y Réplicas Patricio Cerda

11. En el paso System Configuration Check, el asistente verificará si todos los pre-requisitos de
software se encuentran instalados en la máquina. Si alguno de los componentes de software
requeridos no se encuentra instalado, el asistente ofrecerá instalarlo automáticamente.

12. Se pueden instalar los componentes faltantes de manera automática o manual.

a. Para instalar los componentes faltantes automáticamente, hacer click en Install. El asistente
no interrumpirá el proceso de instalación, e instalará los componentes faltantes durante la
sesión de instalación ya existente.

b. Para instalar los componentes manualmente:

#VMwarePorvExperts 421
Capítulo 9 - Backup y Réplicas Patricio Cerda

i. Hacer click en Cancel y salir del asistente.

ii. Instalar y habilitar los componentes necesarios manualmente.

iii. Iniciar el asistente nuevamente. Y en el paso System Configuration Check hacer click
en Re-run y repetir la verificación.

13. Si todos los componentes requeridos ya se encuentran instalados, el asistente de instalación de


Veeam saltará el paso System Configuration Check.

14. En el paso Default Configuration, se puede elegir instalar Veeam con los parámetros de instalación
por defecto o especificar parámetros personalizados de instalación. Si se elige una instalación
personalizada, se deberán especificar los siguientes parámetros:

a. Cuenta de servicio: Por defecto se utiliza la cuenta LOCAL SYSTEM (recomendado), pero
es posible utilizar una cuenta a elección.

b. Instancia SQL: Es posible instalar SQL Express como parte de la instalación de Veeam
Backup Server, o utilizar una instancia de SQL Server previamente instalada, ya sea local o
remota.

c. Especificar puertos de servicio o utilizar los puertos por defecto.

d. Especificar la ubicación de instalación para vPowerNFS y para el catálogo (en caso de


utilizar indexación de archivos).

15. Ya con todos los parámetros definidos, podemos comenzar con la instalación dando click a la
opción “Install”.

#VMwarePorvExperts 422
Capítulo 9 - Backup y Réplicas Patricio Cerda

3.2 Configuración Inicial de Veeam Backup

Una vez tenemos instalado Veeam Backup Server, podemos proceder con la configuración inicial, la
cual incluye entre otros las siguientes operaciones:

• Integración con uno o más hipervisores

• Registrar servidores para roles adicionales de Veeam Backup.

• Configuración/habilitación de Configuration Backup para proteger la configuración de Veeam


Backup.

• Habilitar las notificaciones por e-mail.

3.2.1 Integración con Hipervisores


Una vez completada la instalación de Veeam Backup Server, podemos proceder con la integración de
Veeam con VMware y/o Hyper-V.

Si planeamos proteger VMs sobre vSphere utilizando Jobs de Respaldo y/o Replicación, además de
llevar a cabo cualquier tarea de restauración y/o failback, es necesario en primer lugar registrar la
plataforma vSphere en la infraestructura de respaldo.

Es posible añadir hosts ESXi individuales, así como también instancias de vCenter Server. La
recomendación siempre es preferir la integración mediante vCenter Server, de esta forma si mueven
VMs de un host a otro con vMotion, no será necesario reconfigurar los Jobs de Backup o Replica, ya

#VMwarePorvExperts 423
Capítulo 9 - Backup y Réplicas Patricio Cerda

que Veeam será capaz de reconocer esta migración, y actualizará los Jobs con dicho cambio, para
luego seguir funcionando de la manera usual.

Para poder registrar una instancia de vCenter Server dentro de Veeam Backup Server debemos seguir
los siguientes pasos:

1. En la vista Backup Infrastructure, hacer click derecho sobre Managed Server y seleccionar “Add
Server”. A continuación, hacer click en VMware vSphere > vSphere.

2. A continuación, debemos ingresar el FQDN o la dirección IP de la instancia vCenter Server. La


recomendación es preferir el uso de FQDN.

#VMwarePorvExperts 424
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. El siguiente paso del asistente nos permite especificar las credenciales requeridas para conectarnos
con vCenter Server así como el puerto requerido para la comunicación entre Veeam y vCenter
Server.

a. Desde la lista de credenciales, seleccionar una cuenta que tenga privilegios de administración
en vCenter Server. Si no han configurado previamente ninguna credencial con dichos privilegios,
pueden configurar una nueva credencial haciendo click en “Manage Accounts” o en “Add”.

b. Por defecto Veeam utiliza el puerto 443 para comunicarse con vCenter Server y con los hosts
ESXi. En caso de que vCenter Server esté utilizando un puerto distinto al puerto por defecto,
debemos ingresar dicho puerto en este paso.

4. En el último paso debemos verificar que estén todos los parámetros en orden y luego dar click en
Finish.

#VMwarePorvExperts 425
Capítulo 9 - Backup y Réplicas Patricio Cerda

Una vez finalizado el registro de vCenter Server, tendremos visibilidad a todas las VMs del inventario
de vCenter Server, las cuales luego serán incluidas en uno o más Jobs de Backup, Backup Copy o
Replicación.

3.2.2 Registrar servidores para Proxy o Repositorio


Para poder habilitar el rol de Proxy, Repository Server, Mount Server, Gateway Server y WAN Accelerator,
etc, es necesario previamente haber registrado uno o más servidores Windows en la consola de Veeam
Backup Server. En el caso de Repository Server, también es posible registrar servidores Linux.

1. En la consola de Veeam Backup Server nos dirigimos a la sección “Backup Infrastructure” en el


menú de navegación izquierdo.

2. En el panel de inventario ir a la sección “Managed Servers” y hacer click en la opción “Add Server”.
Aquí debemos seleccionar la opción “Microsoft Windows”.

#VMwarePorvExperts 426
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. Ingresar el FQDN o dirección IP del servidor que deseamos registrar. La recomendación es utilizar
FQDN. Aquí también podemos proveer una descripción del servidor. Luego hacemos click en Next.

4. El siguiente paso es indicar credenciales con privilegios de administración sobre este servidor.
Podemos utilizar credenciales configuradas previamente (en caso de utilizar la misma credencial
para varios servidores), o podemos añadir nuevas credenciales haciendo click en “Add“ o
en“Manage accounts”.

5. A continuación, en la sección “Review”, revisamos que este todo en orden y hacemos click en
Apply.

6. El asistente procederá a instalar los componentes necesarios sobre el servidor Windows,


específicamente dos servicios:

a. Veeam Installer Service

b. Veeam Data Mover Service.

#VMwarePorvExperts 427
Capítulo 9 - Backup y Réplicas Patricio Cerda

7. Hacemos click en Finish, con lo cual habremos completado el registro.

Ya que tenemos uno o más servidores registrados en Veeam Backup Server, podremos utilizarlos para
diversos roles, como el rol de Proxy Server, Repository Server, entre otros.

3.2.3 Habilitación de Configuration Backup


Toda la configuración de Veeam Backup Server es almacenada en la base de datos SQL Server
utilizada por la instalación de Veeam. Esta configuración incluye:

• Integración con hipervisores

• Registro de servidores Windows y Linux

• Configuración de Backup Proxy

• Configuración de Repositorios

• Configuración de Jobs (Backup, Backup Copy, Replication, SureBackup, etc.)

• Credenciales de usuario.

• Entre otros.

Es esencial proteger esta información en caso de que un desastre provoque la pérdida del Veeam
Backup Server. Si no contamos con un respaldo de esta configuración, nos veremos obligados a
proceder con una instalación nueva de Veeam Backup & Replication, completamente desde cero.
Para proteger la configuración, podríamos simplemente respaldar la base de datos SQL utilizada por
Veeam Backup Server, pero su recuperación sería un poco menos simple en comparación al uso de
Configuration Backup.

Configuration Backup es un Job de respaldo que permite a Veeam recoger todos los datos de
configuración desde la base de datos, y almacenarlos en un conjunto de archivos XML, los cuales
luego serán archivados en un archivo de respaldo con extensión .BCO. Este Job, como cualquier otro
puede ser ejecutado regularmente de manera automática. Es posible seleccionar cuando el Job se
ejecuta y con qué periodicidad, además de elegir el repositorio donde el Configuration Backup será
almacenado, asi como también definir los parámetros de retención.

#VMwarePorvExperts 428
Capítulo 9 - Backup y Réplicas Patricio Cerda

IMPORTANTE: Por defecto, los archivos de respaldo creados por el job de Configuration Backup son
almacenados en el Default Backup Repositorio, el cual se encuentra ubicado en el mismo Veeam Backup
Server. No se recomienda en ningún caso que este respaldo quede almacenado en el mismo Veeam
Backup Server que intentamos proteger, por lo que uno de los primeros cambios en la configuración
que debiéramos llevar a cabo, es seleccionar un Repositorio de respaldo diferente, idealmente que se
encuentre ubicado en una ubicación remota.

Para realizar cambios en el Configuration Backup debemos seguir los siguientes pasos:

1. Desde el menú principal de Veeam Backup Server seleccionar Configuration Backup.

2. Asegurarse que la opción Enable configuration backup to the following repository se encuentre
habilitada.

3. Desde la lista Backup repository, elegir el repositorio donde deseamos almacenar el respaldo.
Asegurarse de utilizar un repositorio que no esté ubicado en el mismo Veeam Backup Server.

4. En el campo Restore points to keep, especificamos los puntos de restauración que queremos
mantener en el repositorio (retención). Valor por defecto: 10.

5. Si hacemos click en Schedule podremos modificar el día, la hora, y la frecuencia en que se llevará
a cabo este respaldo.

6. Se recomienda además activar la opción Encrypt Configuration Backup. Esta opción permite
encriptar el respaldo, lo cual a su vez permite que el respaldo incluya todas las credenciales de
usuario utilizadas en la configuración de Veeam, además de las contraseñas asociadas a cada una
de estas credenciales de usuario.

IMPORTANTE: En caso de olvidar la clave de encriptación, la única manera de desencriptar el respaldo


sería mediante el uso de Veeam Enterprise Manager. En caso de que Veeam Enterprise Manager no
haya sido desplegado ANTES de encriptar los respaldos, entonces no habrá forma de desencriptar

#VMwarePorvExperts 429
Capítulo 9 - Backup y Réplicas Patricio Cerda

dichos respaldos si no se cuenta con la clave de encriptación.

3.2.4 Habilitar Notificaciones por E-mail

1. Desde el menú principal de Veeam Backup Server seleccionar Options. En la siguiente ventana
nos dirigimos al tab “E-Mail Settings”.

2. Aquí podemos habilitar o deshabilitar las notificaciones.

3. En casi de habilitarlas, deberemos especificar:

a. SMTP Server el cual será utilizado para el envío de notificaciones por e-mail. En caso de que el
servidor SMTP requiera autenticación, dichos parámetros los podemos especificar haciendo click en
Advanced.

b. Luego seleccionamos un remitente y un destinatario para las notificaciones.

c. Finalmente definimos un asunto que irá en cada e-mail de notificación enviado por Veeam Backup
and Replication.

4. Luego debemos especificar qué tipo de notificaciones deseamos recibir.

a. En general se recomienda NO habilitar la opción “Notify on success” a menos que sea requerido,
ya que esto generará mucha notifacion por correo, cada vez que un Job finalice exitosamente.

b. La opción “Supress notifications until the last retry” se recomienda dejarla habilitada para reducir
el número de notificaciones recibidas en caso de que un Job falle total o parcialmente, para luego
finalizar exitosamente al segundo o tercer intento (según lo configurado en el Job, respecto a los re-
intentos).

#VMwarePorvExperts 430
Capítulo 9 - Backup y Réplicas Patricio Cerda

3.3 Veeam Proxy Server

Recordemos, como mencionamos previamente, que el rol de Proxy Server es el de ser el “Músculo”
de la solución. Un Proxy Server es un componente que se ubica entre un origen y un destino de datos.
De esta manera, es el Proxy Server el encargado de obtener los datos que deseamos proteger, por
ejemplo, obteniendo los datos de una VM desde un host ESXi, para luego enviarlos a un destino, por
ejemplo a un Repositorio de respaldos.

3.3.1 Requisitos previos


Hardware

• CPU: Procesador x86-64, se recomienda un mínimo de 2 Cores. Revisar el apartado de


dimensionamiento en el capítulo anterior para calcular los recursos requeridos según la cantidad
de tareas concurrentes.

• Memoria: Mínimo recomendado 2GB de RAM. Revisar el apartado de dimensionamiento en el


capítulo anterior para calcular los recursos requeridos según la cantidad de tareas concurrentes.

• Almacenamiento: 300MB.

• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local.

Software

• Sistemas operativos soportados para la instalación:

#VMwarePorvExperts 431
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Microsoft Windows Server 2019

• Microsoft Windows Server 2016 (including versions 1709, 1803)

• Microsoft Windows Server 2012 R2

• Microsoft Windows Server 2012

• Microsoft Windows Server 2008 R2 SP1

• Microsoft Windows Server 2008 SP2

• Microsoft Windows 10

• Microsoft Windows 8.x

• Microsoft Windows 7 SP1

• Microsoft Windows Vista SP2

3.3.2 Añadir un Proxy Server


El proceso de añadir un nuevo Proxy Server es muy sencillo, ya que no es necesario instalar software
alguno sobre este servidor, sino que simplemente habilitaremos una máquina con Windows desde la
consola de administración de Veeam Backup Server con el rol de Veeam Proxy Server.

Asimismo que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le
daremos el rol de Proxy. En caso de no haberlo registrado antes, podremos hacerlo utilizando el
mismo asistente de añadir un nuevo Proxy Server

1. En la barra de menú seleccionamos la opción “Add Proxy”, o hacemos click derecho sobre “Backup
Proxies” y seleccionamos la opción “Add VMware Backup Proxy”.

2. A continuación, deberemos seleccionar el servidor Windows al cual le asignaremos el rol de Proxy


Server. En caso de no haber registrado uno previamente, podemos hacer click en “Add New” para
poder registrar un nuevo servidor Windows.

#VMwarePorvExperts 432
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. En este mismo paso debemos especificar el “Transport Mode”. Por defecto esta en modo
Automático, por lo que será el mismo Proxy quien decida la mejor forma de comunicarse con el
hipervisor para obtener los datos de la VM durante una operación de respaldo o replicación.

Las opciones son Automatic, Direct Storage Access, Appliance Mode y Network Mode.

NOTA: Si desea saber más de los Modos de Transporte puede revisar el siguiente link: https://goo.
gl/gMn9PW

4. Aquí también podemos especificar los Datastores que estarán conectados con este Proxy a través
de una conexión SAN o NFS. Por defecto Veeam detecta automáticamente todos los Datastores
visibles en un Proxy Server.

5. Por último debemos definir la cantidad máxima de tareas concurrentes que podrá ejecutar un
Backup Proxy. Si este valor se excede, el Proxy Server no iniciará nuevas tareas hasta que una de
las actuales finalice.

a. Veeam crea una tarea por cada disco virtual a respaldar/replicar/restaurar. La recomendación
es tener un Core de CPU por cada tarea concurrente.

b. Con eso en mente, si nuestro proxy tiene 4 Cores de CPU, el número de tareas concurrentes
debiera ser también de 4.

6. El siguiente paso es crear las “Traffic Rules” o Reglas de tráfico, las que nos permiten limitar el
tráfico de salida de un Backup Proxy. Utilizando estas reglas podemos gestionar el ancho de banda
máximo que un Proxy puede utilizar en determinados horarios (definidos por el administrador), y
así minimizar el impacto en la performance de la red de producción.

#VMwarePorvExperts 433
Capítulo 9 - Backup y Réplicas Patricio Cerda

7. Finalmente damos click en Finish, con lo cual habremos registrado nuestro Proxy Server.

3.4 Veeam Repository Server / Gateway Server

Cuando hablamos de repositorio, hablamos simplemente de una ubicación donde Veeam Backup
and Replication almacenará los archivos de respaldo. Técnicamente hablando, un Repositorio es
simplemente una “carpeta” en un dispositivo de almacenamiento.

En una infraestructura con Veeam Backup and Replication podemos implementar múltiples tipos de
repositorio, considerando que Veeam es totalmente agnóstico con el tipo de almacenamiento utilizado
para almacenar los respaldos, pudiendo por ejemplo utilizar:

• Servidores con discos locales

• Almacenamiento sobre cabina iSCSI o Fiber Channel

• Carpeta compartida via NFS o CIFS

• Appliance de Deduplicación

Independiente del tipo de almacenamiento a utilizar, es necesario contar con un servidor con el rol de
Repository Server, el cual tendrá dos funciones principales:

• Contar con acceso al dispositivo de almacenamiento que utilizaremos como repositorio, por
ejemplo, una LUN vía iSCSI, o simplemente discos locales.

#VMwarePorvExperts 434
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Proveer el servicio de Data Mover.

NOTA: Con Veeam, toda transferencia de datos requiere del servicio de Data Mover, necesitando un
Data Mover de origen (ej: Proxy Server) y un Data Mover de destino (Ej. Repository Server)

3.4.1 Requisitos previos


Hardware

• CPU: Procesador x86-64, se recomienda un mínimo de 2 Cores. Revisar el apartado de


dimensionamiento en el capítulo anterior para calcular los recursos requeridos según la cantidad
de tareas concurrentes.

• Memoria: Mínimo recomendado 4GB de RAM. Revisar el apartado de dimensionamiento en el


capítulo anterior para calcular los recursos requeridos según la cantidad de tareas concurrentes.

• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local

Software

• Sistemas operativos soportados para la instalación:

• Microsoft Windows Server 2019

• Microsoft Windows Server 2016 (including versions 1709, 1803, 1809)

• Microsoft Windows Server 2012 R2

• Microsoft Windows Server 2012

• Microsoft Windows Server 2008 R2 SP1

• Microsoft Windows Server 2008 SP2

• Microsoft Windows 10

#VMwarePorvExperts 435
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Microsoft Windows 8.x

• Microsoft Windows 7 SP1

• Microsoft Windows Vista SP2

• Linux (Se require bash shell, SSH Perl).

NOTA: Mismos requerimientos aplican para un Gateway Server

3.4.2 Añadir un nuevo Repositorio


El proceso de añadir un nuevo Repositorio es muy sencillo, ya que no es necesario instalar software,
sino que simplemente utilizaremos una máquina con Windows previamente registrada desde la consola
de administración de Veeam Backup Server, y que tenga acceso al dispositivo de almacenamiento que
utilizaremos como repositorio.

Asimismo que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le daremos
el rol de Repository Server. En caso de no haberlo registrado antes, podremos hacerlo utilizando el
mismo asistente de añadir un nuevo Repositorio.

1. Dirigirse a la sección Backup Infrastructure

2. En el panel de inventario hacer click en Backup Repositories y seleccionar “Add Backup Repository”

3. En la ventana que se abre a continuación deberemos seleccionar el tipo de repositorio que


añadiremos.

• Direct Attached Storage: Servidor Windows/Linux con acceso directo al almacenamiento,


pudiendo ser discos locales, almacenamiento iSCSI o FC, entre otros.

• Network Attached Storage: Carpeta compartida mediante NFS o CIFS/SMB. En este caso se
requerirá también un servidor Windows/Linux para operar como Gateway Server, proveyendo
acceso a la carpeta compartida, así como también el servicio de Veeam Data Mover.

• Deduplication Storage Appliance: Dell EMC Data Domain, HPE StoreOnce, Exagrid, Quantum
DXi. Se requiere también de un Gateway Server.

• Object Storage: On-premises o a través de un proveedor de almacenamiento por objetos en


la Cloud. Solo disponible como “Capacity Tier” en una configuración con Scale-Out Backup

#VMwarePorvExperts 436
Capítulo 9 - Backup y Réplicas Patricio Cerda

Repository (disponible a partir de Veeam Backup & Replication 9.5 Update 4).

4. En este ejemplo usamos la opción Direct Attached Storage.

5. Ingresamos un nombre y una descripción para el Repositorio.

6. A continuación, seleccionamos el servidor que utilizaremos como Repository Server / Gateway


Server. En caso de no haberlo registrado previamente, lo podemos registrar en este paso con la
opción “Add New”.

7. Hacer click en “Populate” para mostrar una lista de los discos disponibles en este servidor, y su
capacidad libre.

#VMwarePorvExperts 437
Capítulo 9 - Backup y Réplicas Patricio Cerda

8. En el siguiente paso especificaremos la ruta especifica dentro del disco seleccionado, donde
almacenaremos los respaldos. En este punto también podemos controlar la cantidad de tareas
concurrentes que se pueden ejecutar sobre este repositorio. Si este valor se excede, el Repository
Server no iniciará nuevas tareas hasta que una de las actuales finalice. Revisar el apartado de
diseño para recomendaciones de tareas/Jobs concurrentes.

9. El siguiente paso es especificar el Mount Server. Este componente es requerido para restauraciones
de archivos individuales (Instant file level recovery) y para restauración de ítems de aplicaciones
(Veeam Explorers). Durante dichos proceso de restauración, Veeam montará los discos de la VM
que estamos intentando restaurar desde el archivo de respaldo al Mount Server. Esto reduce la
carga sobre la red y acelera el proceso de restauración.

Usualmente utilizaremos el mismo Repository Server como Mount Server, pero podemos especificar
un servidor alternativo.

10. En este mismo punto podemos habilitar el servicio de vPowerNSF, el cual es esencial para tareas
como Instant VM Recovery, SureBackup y On-Demand Sandbox.

IMPORTANTE: No se recomienda habilitar vPowerNFS en un servidor Windows con servicios


NFS habilitados. Si ambos servicios se encuentras activos, ambos presentarán problemas en su
funcionamiento.

NOTA: Si desea saber más de vPowerNFS y como es utilizado por tarea como Instant VM Recovery,
se recomienda revisar el siguiente link: https://goo.gl/Bpp3Sr

11. Revisamos que este todo en orden y hacemos click en Apply.

12. Una vez que la operación esté finalizada, podemos simplemente hacer click en Finish para cerrar
el asistente.

#VMwarePorvExperts 438
Capítulo 9 - Backup y Réplicas Patricio Cerda

3.5 Veeam Wan Accelerator

A continuación, hablaremos sobre Veeam WAN Acceleration, un componente de la arquitectura de


Veeam Backup and Replication que permite facilitar y hacer más eficiente la transferencia de datos
entre sitios remotos en tareas de Respaldo (aplica solo a jobs de Backup Copy, no a Jobs de Backup
standard) y Replicación.

Esta característica nos permite enfrentar escenarios donde la conexión entre sitios remotos cuenta
con un ancho de banda limitado, y la cantidad de información a transmitir es importante. El objetivo de
WAN Acceleration entonces es optimizar esta transferencia de datos sobre la WAN.

Para el funcionamiento de Veeam WAN Acceleration, se requiere el uso de servidores con el rol de
WAN Accelerator, uno para cada sitio, los cuales serán responsables de gestionar el Cache Global
y la Deduplicación. Los WAN Accelerators se ubicarán entre los Data Movers de origen y destino
(usualmente Repositorios o Proxy Servers) como vemos en la siguiente imagen.

#VMwarePorvExperts 439
Capítulo 9 - Backup y Réplicas Patricio Cerda

Veeam WAN Acceleration es compatible además con Veeam Cloud Connect, lo que permite realizar
operaciones de Backup Copy y de Replica utilizando proveedores de Cloud públicos.

NOTA: Si desea saber más de Veeam WAN Accelerator, se recomienda leer el siguiente link: https://
goo.gl/zL51y7

3.5.1 Requisitos previos


Hardware

• CPU: Procesador x86-64 (depende de su tiene el rol de Source o Target WAN Accelerator. Revisar
el apartado de dimensionamiento en el capítulo anterior para calcular los recursos requeridos
según la cantidad de tareas concurrentes.

• Memoria: Mínimo recomendado 4GB de RAM. Revisar el apartado de dimensionamiento en el


capítulo anterior para calcular los recursos requeridos según la cantidad de tareas concurrentes.

• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local.

Software

• Sistemas operativos soportados para la instalación (64 bits):

• Microsoft Windows Server 2019

• Microsoft Windows Server 2016 (including versions 1709, 1803, 1809)

• Microsoft Windows Server 2012 R2

• Microsoft Windows Server 2012

• Microsoft Windows Server 2008 R2 SP1

• Microsoft Windows Server 2008 SP2

#VMwarePorvExperts 440
Capítulo 9 - Backup y Réplicas Patricio Cerda

• Microsoft Windows 10

• Microsoft Windows 8.x

• Microsoft Windows 7 SP1

• Microsoft Windows Vista SP2

3.5.2 Añadir un WAN Accelerator


El proceso de añadir un nuevo WAN Accelerator es muy sencillo, ya que no es necesario instalar
software alguno sobre éste servidor, sino que simplemente habilitaremos una máquina con Windows
desde la consola de administración de Veeam Backup Server con el rol de WAN Accelerator.

Asumimos que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le
daremos el rol de WAN Accelerator. En caso de no haberlo registrado antes, podremos hacerlo
utilizando el mismo asistente de añadir un nuevo WAN Accelerator.

NOTA: El rol de WAN Accelerator puede ser asignado a servidores que también tengan el rol de
Backup Proxy o de Repository Server. La única recomendación en dicho caso es asegurarse que
el dimensionamiento sea el adecuado, donde se deben sumar los requerimientos de ambos roles
asignados a dicho servidor.

1. Dirigirse a la sección Backup Infrastructure

2. En el panel de inventario hacer click en WAN Accelerators y seleccionar “Add WAN Accelerator”.

3. A continuación, deberemos seleccionar el servidor Windows al cual le asignaremos el rol de WAN


Accelerator. En caso de no haber registrado uno previamente, podemos hacer click en “Add New”
para poder registrar un nuevo servidor Windows.

#VMwarePorvExperts 441
Capítulo 9 - Backup y Réplicas Patricio Cerda

• En este punto podemos personalizar el puerto TCP utilizado por WAN Accelerator. Por defecto
se utiliza el puerto 6165.

• También podemos especificar el número de Streams (conexiones) que WAN Accelerator


utilizará para transmitir los datos de un sitio a otro.

NOTA: Por defecto se utilizan 5 Streams, pero se puede aumentar este parámetro hasta 100 Streams,
lo cual se debe llevar a cabo con precaución, ya que un exceso de Streams (conexiones) podría
saturar en extremo la conexión WAN, y generar latencia en la red. El aumento de Streams también
genera un mayor uso de CPU y Memoria en los WAN Accelerators.

4. A continuación, se debe seleccionar un directorio donde se ubicará el Caché utilizado por WAN
Accelerator para reducir la cantidad de datos transferidos a través de la conexión WAN.

NOTA: El tamaño del Cache es específico para cada WAN Accelerator de origen. Por ejemplo, si
tendrán 4 WAN Accelerators de origen conectados al mismo WAN Accelerator de destino, el tamaño
del Caché deberá ser multiplicado por 4, ya que el Caché no puede ser compartido entre múltiples
WAN Accelerators.

5. La recomendación es que el Global Cache cuente con al menos 10GB por cada Sistema Operativo
que será copiado entre los sitios remotos.

• Cada versión de Windows cuenta como un Sistema Operativo distinto, por lo que cada una
requiere 10GB para el Global Cache.

• Las distintas versiones de Linux cuentan como un único Sistema Operativo, por lo que se
requiere 10GB para contener los bloques de datos de cualquier versión de Linux en el Global
Cache.

• Adicionalmente se requieren al menos 20GB libres para archivos temporales.

#VMwarePorvExperts 442
Capítulo 9 - Backup y Réplicas Patricio Cerda

6. Revisamos que este todo en orden y hacemos click en Apply.

7. Una vez que la operación esté finalizada, podemos simplemente hacer click en Finish para cerrar
el asistente.

#VMwarePorvExperts 443
Capítulo 9 - Backup y Réplicas Patricio Cerda

4. Diseño de Jobs

4.1 Buenas Prácticas

Un punto crucial cuando estamos diseñando e implementando una solución de Backup como Veeam,
es un diseño adecuado de los Jobs de Backup, Backup Copy o Replica. A continuación, mencionaremos
algunas buenas prácticas y recomendaciones a la hora de diseñar y crear estos Jobs.

4.1.1 Máquinas Virtuales por Job


Una duda recurrente de muchos clientes y usuarios es cuantas VMs debieran ser incluidas en un
Job de Backup o Replica. Esto depende un poco del diseño de la solución de Backup, pero algunas
recomendaciones son:

• Incluir no más de 20 o 30 VMs por Job, lo cual permite asegurar que los archivos de respaldo
no sean demasiado grandes, y por lo tanto que sean más fáciles de gestionar por el sistema de
archivos.

• En caso de que decidamos utilizar la opción Per-VM Backup File, podemos aumentar en hasta 10
veces el número de VM por Job, es decir, podemos incluir sin problemas de 200 a 300 VMs por
Job.

NOTA: Veeam ha probado Jobs con hasta 5.000 VMs de manera exitosa, no obstante, la experiencia
de sus ingenieros sugiere que el número adecuado de VMs por Job utilizando Per-VM Backup Files es
de alrededor de 300 VMs.

No son pocos los casos además en que algunos clientes deciden crear Jobs con solo 1 VM, lo cual
tiene varias desventajas que iremos viendo a continuación:

• La administración y operación del día a día se hace más compleja al tener que gestionar un número
mucho más grande de Jobs.

• El número de Jobs tiene un impacto directo en el dimensionamiento de CPU y Memoria para


Veeam Backup Server y para los Repository Server, lo que implica que se requerirán muchos más
recursos de CPU y Memoria para poder ejecutar un mayor número de Jobs de manera concurrente.

• La deduplicación nativa de Veeam es menos efectiva, ya que cada archivo de respaldo contendrá
datos de una única VM, por lo que el número de bloques redundantes será extremadamente
reducido. Esto tiene un impacto directo en el dimensionamiento de los Repositorios.

4.1.2 Cómo agrupar las Máquinas Virtuales en Jobs


No solo es importante el número de VMs que configuremos en cada Job. También es importante definir
como agruparemos estas VMs por Job, es decir, que criterios usaremos para distribuir las VMs en
múltiples Jobs. En general este tipo de decisiones depende de muchos factores, pero aquí tenemos
algunas recomendaciones:

• Agrupar VMs que necesiten las mismas frecuencias de respaldo. Es decir, en primer lugar,

#VMwarePorvExperts 444
Capítulo 9 - Backup y Réplicas Patricio Cerda

debiéramos considerar las VMs con el mismo RPO para que sean configuradas en el mismo Job.

• Agrupar VMs por sistema operativo. Esto permite mejorar la eficiencia de la deduplicación nativa de
Veeam, ya que al tener archivos de respaldo conteniendo VMs con el mismo sistema operativo, el
número de bloques de datos redundantes será mucho mayor, y por lo tanto, el ahorro en capacidad
de almacenamiento en el Repositorio también será mucho mayor.

• Agrupar VMs según su tipo de aplicación. Esto facilitará contar con una configuración común a nivel
de Job, para todas las VM que requieran procesamiento con consistencia a nivel de aplicaciones,
que requieran respaldo de Transaction Logs, que requieran indexación de archivos, entre otros
posibles requerimientos.

4.1.3 Definir el método de Backup


Es importante definir el método de respaldo que utilizaremos, ya que esto tiene un impacto directo en la
capacidad de almacenamiento requerida en el repositorio, pero también un impacto en la performance
del repositorio.

Recordemos que tenemos tres métodos de backup:

• Forward Incremental

• Forever Forward Incremental

• Reverse Incremental

En general el método de respaldo Forward Incremental es el que tiene el menos impacto en la performance
del Repositorio, pero al mismo tiempo requiere de una mayor capacidad de almacenamiento, ya que
requiere de la creación de respaldos Full periódicos.

Por otro lado, Forever Forward Incremental y Reverse Incremental requieren menos capacidad de
almacenamiento, ya que solo se requerirá la creación de un único respaldo Full, sin la necesidad de
crear respaldos Full periódicos.

NOTA: Si desean una explicación más detallada acerca de los métodos de backup, pueden revisar el
siguiente link: https://goo.gl/ZmU2iB. También pueden leer acerca del impacto de cada uno de estos
métodos de respaldo sobre los Repositorios en el siguiente link: https://goo.gl/5R6DoB

4.1.4 Active Full o Synthetic Full


A la hora de configurar respaldos Full periódicos, debemos definir si utilizaremos Active Full o Synthetic
Full.

Lo primero que debemos tener en claro, es que ambos tipos de respaldo Full contienen la misma
información, tienen el mismo tamaño en el Repositorio, e incluso el archivo tiene la misma extensión
(.VBK). La diferencia fundamental entre ambos tipos de respaldo es la forma en que estos son creados:

• Active Full: El 100% de los datos se obtienen desde el Storage en producción donde las VMs se
encuentran hospedadas.

• Synthetic Full: Parte de los datos (incrementos) son obtenidos desde el Storage en producción
donde las VMs se encuentran hospedadas, mientras que la mayor parte de los datos se obtiene
desde los respaldos previos ya existentes en el Repositorio, consolidando los respaldos anteriores

#VMwarePorvExperts 445
Capítulo 9 - Backup y Réplicas Patricio Cerda

con los nuevos datos incrementales obtenidos al momento de ejecutar el respaldo Synthetic Full.

En general utilizaremos Active Full en los siguientes casos:

• Utilizamos Appliance de Deduplicación como repositorio de respaldo. Esto es especialmente


importante si el appliance utilizado no cuenta con integración con Veeam.

• Cuando nos preocupa la performance del almacenamiento utilizado como Repositorio, donde tener
un número muy alto de operaciones de I/O podrían generar una alta latencia, aumentando los
tiempos requeridos para completar el respaldo.

En general utilizaremos Synthetic Full en los siguientes casos:

• Cuando el Repositorio utiliza discos rápidos, incluyendo controladoras RAID por hardware con un
cache suficiente para gestionar un gran número de operaciones de I/O.

• Cuando nos preocupa la performance del almacenamiento en Producción donde las VMs están
hospedadas, y donde la ejecución de un respaldo Active Full podría generar una cantidad excesiva
de operaciones de lectura en el Datastore, provocando potenciales problemas de latencia en el
Datastore productivo donde se encuentran las VMs siendo respaldadas.

• Utilizamos Appliance de Deduplicación con integración con Veeam:

• Dell EMC Data Domain con DD Boost

• HPE StoreOnce con Catalyst

• Exagrid

NOTA: Si desea saber en detalle cómo se diferencian los respaldos Active Full y Synthetic Full, y cómo
funcionan en detalle, pueden revisar el siguiente link: https://goo.gl/zzSSf5

NOTA: Si desea saber más acerca del uso de Appliances de Deduplicación como Repositorios de
respaldo, pueden revisar el siguiente link: https://goo.gl/SFM9Xv

4.1.5 Per-VM Backup File


Si bien la opción Per-VM Backup File es un parámetro configurable a nivel de Repositorio, y no en un
Job, esté parámetro tiene un impacto directo en la forma en que se crean los archivos de Backup, y por lo
tanto tiene que ser considerado a la hora de diseñar los Jobs. A continuación, algunas consideraciones
a la hora de utilizar Per-VM Backup File.

• Per-VM Backup File permite la creación de Jobs con un gran número de VMs (recomendable un
máximo de 300 VMs por Job), lo cual facilita la gestión de la infraestructura, al tener que lidiar con
un menor número de Jobs.

• Per-VM Backup File tiene consideraciones a nivel de performance, ya que genera una gran cantidad
de procesos paralelos de escritura, lo cual podría reducir los tiempos en que un respaldo se
completa. Esto también podría tener un impacto negativo en algunas cabinas de almacenamiento,
las cuales pueden no estar diseñadas para procesar tantas tareas en paralelo. En este punto es
importante definir el número máximo de tareas concurrentes por Respositorio, de manera de evitar
problemas de performance.

• Por la manera en que opera la Deduplicación nativa de Veeam, donde Veeam solo eliminará los
bloques de datos redundantes que se encuentran DENTRO de un mismo archivo de respaldo, sin

#VMwarePorvExperts 446
Capítulo 9 - Backup y Réplicas Patricio Cerda

comparar bloques de datos que se encuentren en distintos archivos de respaldo, el uso de Per-VM
Backup File reducirá al mínimo los ahorros de capacidad provistos por la Deduplicación de Veeam.

Al crear un archivo de respaldo por máquina virtual, Veeam solo podrá eliminar los bloques redundantes
en cada archivo de respaldo individual que, en este caso, contiene datos de una única máquina virtual.
Al no tener múltiples VMs en un mismo archivo de respaldo, el número de bloques redundantes será
inmensamente inferior. Todo esto redunda en una mayor capacidad de almacenamiento requerida en
el repositorio.

4.2 Job de Respaldo (Backup Job)

A continuación, veremos el proceso de creación de un Job de Respaldo o Backup Job, incluyendo


algunas recomendaciones. En primer lugar, nos aseguramos de contar con lo siguiente:

• Integración de Veeam con al menos un hipervisor, VMware o Hyper-V.

• Al menos un Proxy Server

• Al menos un Repositorio con suficiente capacidad de almacenamiento.

• Licencia de Veeam Backup & Replication.

• Si van a configurar el Job con Application-aware processing, se debe contar con credenciales con
privilegios de administración sobre las VMs.

• Si van a respaldar Transaction logs, asegurarse de contar con una cuenta con suficientes privilegios
sobre SQL Server u Oracle.

Los pasos a seguir para crear un Job de Respaldo son los siguientes:

1. Dirigirse al tab Home, hacer click en Backup Job > Virtual machine > VMware vSphere.

2. Ingresar el nombre del Job. Se recomienda diseñar una nomenclatura de nombres que permita
identificar fácilmente el objetivo de este Job y las VM que contiene.

#VMwarePorvExperts 447
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. Seleccionar las VMs que se desean incluir en este Job de respaldo.

a. Hacer click en Add, con lo cual se abrirá otra ventana para seleccionar las VMs a añadir.

b. En la barra de tareas que vemos algunas opciones, que nos permiten visualizar las VMs
utilizando distintas vistas: Hosts and Clusters, VMs and Templates, Datastores and VMs y
VMs and Tags.

c. A continuación, podemos seleccionar VMs individuales, o contenedores con múltiples VMs.


Podemos seleccionar múltiples VMs en este proceso.

d. También en la parte inferior tenemos un cuadro de búsqueda, que nos facilita encontrar VMs
específicas, lo cual puede ser de mucha utilidad en grandes infraestructuras con cientos o
incluso miles de VMs.

#VMwarePorvExperts 448
Capítulo 9 - Backup y Réplicas Patricio Cerda

4. Adicionalmente en este punto podemos excluir objetos en el Job de backup:

a. Podemos excluir discos virtuales específicos de una VM.

b. Podemos excluir VMs desde un contenedor de VMs (ej. Carpetas, Datastores, Resource
Pools, etc.)

c. También podemos excluir templates de VM.

#VMwarePorvExperts 449
Capítulo 9 - Backup y Réplicas Patricio Cerda

5. Finalmente, en este punto también podemos cambiar el orden en que las VMs son procesadas al
momento de ejecutar el Job de Respaldo. Esto podría ser útil si desean respaldar en primer lugar
VMs más críticas.

6. A continuación, podemos especificar el Backup Proxy que deseamos utilizar:

a. El parámetro por defecto es “Automatic Selection”, donde Veeam detectará los Proxies que
tengan acceso al o los Datastores donde se encuentran las VMs, y seleccionara el Proxy más
óptimo para procesar las VMs en el Job.

Veeam asignará Backup Proxies a las VMs incluidas en el Job, una por una. Si hay más de un
Proxy disponible, entonces Veeam analizará el Modo de Transporte disponible en cada Proxy
de manera de seleccionar el Proxy con la conexión más óptima al Datastore. Veeam analizará
además la carga de trabajo en los Proxies, para evitar cuellos de botella al asignar un Proxy
que tenga demasiada carga de trabajo actualmente.

b. Es posible también seleccionar un Backup Proxy manualmente. En este caso se recomienda


que se seleccionen al menos dos Backup Proxies de manera de contar con redundancia. Así,
si uno de los Proxies falla o pierde conexión con el Datastore, el Job de Respaldo puede utilizar
el o los Proxies restantes seleccionados.

#VMwarePorvExperts 450
Capítulo 9 - Backup y Réplicas Patricio Cerda

7. En este punto también debemos especificar el repositorio que utilizaremos para almacenar los
archivos de respaldo.

a. Un Job solo puede tener asignado un único Repositorio.

b. Podemos utilizar Scale-Out Backup Repository para facilitar la gestión de los Jobs y
Repositorios.

8. Finalmente, en este punto debemos especificar la política de retención para este Job. Básicamente
debemos especificar el número de puntos de Restauración que deseamos mantener.

a. Por ejemplo, si realizaremos un respaldo diario, y deseamos una retención de una semana,
debiéramos configurar 7 puntos de restauración.

b. Del mismo modo, si por ejemplo deseamos realizar respaldos cada 1 hora, con una retención
de un día, debiéramos configurar 24 puntos de restauración.

9. A continuación, si hacemos click en Advance, podremos definir los siguientes parámetros:

a. Modo de backup, pudiendo ser Incremental o Reverse Incremental. Si deseamos utilizar


Forever Forward Incremental, debemos seleccionar la opción “Incremental” y remover las
opciones de Full Backup periódicos.

Aquí también podemos configurar respaldos Full periódicos, utilizando Synthetic Full o Active
Full.

#VMwarePorvExperts 451
Capítulo 9 - Backup y Réplicas Patricio Cerda

b. Opciones de mantenimiento, por ejemplo, realizar un Health Check periódico de los archivos
de respaldo, de manera de verificar que no exista corrupción de datos. Del mismo modo
podemos configurar la ejecución periódica de una desfragmentación y compactación del
archivo Full Backup, algo que puede ser especialmente útil cuando utilizamos Forever Forward
Incremental o Reverse Incremental.

#VMwarePorvExperts 452
Capítulo 9 - Backup y Réplicas Patricio Cerda

c. Opciones de almacenamiento:

i. Habilitar o deshabilitar deduplicación nativa de Veeam (por defecto habilitada).

ii. Excluir archivos Swap y/o archivos eliminados.

iii. Configurar el nivel de compresión de los archivos de respaldo.

iv. Habilitar encriptación de los respaldos.

d. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de


correo donde enviar estas notificaciones, así como también que tipo de notificación deseamos
recibir.

#VMwarePorvExperts 453
Capítulo 9 - Backup y Réplicas Patricio Cerda

e. Parámetros de vSphere, como por ejemplo habilitar o deshabilitar Change Block Tracking
(CBT)

f. En la sección “Integration” también podremos habilitar el uso de Backup from Storage


Snapshots, siempre que la cabina de almacenamiento lo soporte y se encuentre integrada con
Veeam Backup Server.

g. Por último podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.

#VMwarePorvExperts 454
Capítulo 9 - Backup y Réplicas Patricio Cerda

10. En el siguiente paso, opcionalmente podemos asociar este Job de Respaldo con un Job de Backup
Copy, de manera de contar con un respaldo secundario para cumplir con la regla 3-2-1. Hablaremos
de Backup Copy en la siguiente sección.

11. A continuación, debemos especificar los parámetros de procesamiento de las máquinas virtuales:

#VMwarePorvExperts 455
Capítulo 9 - Backup y Réplicas Patricio Cerda

a. Podemos habilitar Application-aware processing, lo cual permite realizar respaldos


consistentes a nivel de sistema operativo, y opcionalmente habilitar el respaldo de Transaction
Logs. Esta opción la podemos habilitar o deshabilitar para todas las VMs del Job, o solo para
algunas de ellas, lo cual podemos personalizar haciendo click en Applications.

i. Aquí tendremos una lista de las VMs en el Job, donde podremos deshabilitar el
procesamiento a nivel de aplicaciones.

ii. También podemos configurar el uso de Transaction Logs para SQL, donde podemos
respaldar estos Transaction Logs o solo truncarlos. También podemos configurar la
frecuencia de la ejecución del respaldo de Transaction Logs (por ejemplo, cada 15 minutos),
el cual se ejecuta de manera independiente a la ejecución del Job de Respaldo.

#VMwarePorvExperts 456
Capítulo 9 - Backup y Réplicas Patricio Cerda

iii. Adicionalmente podemos configurar el uso de Transaction Logs para Oracle, donde
podemos respaldar estos Transaction Logs o solo eliminarlos. También podemos configurar
la frecuencia de la ejecución del respaldo de Transaction Logs (por ejemplo, cada 15
minutos), el cual se ejecuta de manera independiente a la ejecución del Job de Respaldo.
Aquí además debemos especificar una cuenta de usuario con privilegios de SYSDBA.

iv. En caso de que la VM a respaldar no sea compatible con Microsoft VSS, podemos
también especificar scripts de pre-freeze y post-thaw para poder llevar a cabo el proceso
de quiescing, y así asegurar la consistencia del respaldo.

#VMwarePorvExperts 457
Capítulo 9 - Backup y Réplicas Patricio Cerda

b. Aquí además podemos habilitar la opción de Indexación del sistema de archivos, lo que
posteriormente facilitará la búsqueda de archivos individuales que necesitemos restaurar con
Instant File Level Recovery. Debemos tener en consideración que la opción de Indexación
podría extender la ejecución del Job de Respaldo, especialmente si la VM contiene una gran
cantidad de archivos, como sería el caso de un File Server.

c. Finalmente, debemos especificar credenciales de usuario con privilegios de administración


sobre las VMs, lo cual es obligatorio en caso de habilitar Application-aware processing o Guest
file system Indexing. Podemos especificar una sola cuenta de usuario para todas las VMs del
Job, o podemos especificar cuentas individuales por cada VM.

12. Finalmente, debemos especificar cuándo se ejecutará este Job en las opciones de Schedule. Un Job
puede ejecutarse diariamente (todos los días o días específicos), mensualmente, periódicamente
(por ejemplo, cada 1 hora), o después de un Job (no se recomienda encadenar Jobs)

a. Aquí también podemos especificar si se re-intentará la ejecución del Job en caso de producirse
una falla. Por defecto el Job reintentará ejecutarse hasta un máximo de 3 veces, con un tiempo
de espera de 10 minutos entre intentos.

b. Por último, podemos especificar una ventana de respaldo, por ejemplo, que los respaldos
se ejecuten entre las 10 PM y las 8 AM. En este caso, si el Job de respaldo no finaliza dentro
de la ventana de respaldo especificada, el Job será cancelado automáticamente, incluyendo el
procesamiento de todas las tareas en ejecución.

#VMwarePorvExperts 458
Capítulo 9 - Backup y Réplicas Patricio Cerda

4.3 Job de Copia de Respaldo (Backup Copy Job)

A continuación, veremos el proceso de creación de un Job Backup Copy, incluyendo algunas


recomendaciones.

Con Backup Copy podemos crear varias copias del mismo respaldo y almacenar estas copias en
Repositorios secundarios para almacenamiento de largo plazo (archiving). Estos repositorios
secundarios son repositorios normales, y pueden estar ubicados en el mismo sitio que el Repositorio
primario, o puede estar en una ubicación remota (recomendado). Debemos considerar además que

#VMwarePorvExperts 459
Capítulo 9 - Backup y Réplicas Patricio Cerda

los archivos de respaldo creados por Backup Copy tienen el mismo formato que los archivos creados
por un Job de Respaldo, por lo que los datos pueden ser restaurados directamente desde un Backup
Copy en caso de ser necesario.

Backup Copy no copia el archivo de respaldo completo (archivo .VBK, VIB o VRB) desde un repositorio
a otro, sino que copia los datos por cada máquina virtual a nivel de bloques. Es decir, cuando el proceso
de Backup Copy comienza, Veeam accederá al archivo de Respaldo en el Repositorio de origen,
obtiene los bloques de datos de la VM especifica que quiere copiar desde el archivo de Respaldo, y los
copia en el Repositorio secundario.

Debido a la forma en que Backup Copy funciona, no se genera ningún impacto sobre la infraestructura
virtual o las máquinas virtuales en sí. Backup Copy simplemente copiará datos de un Repositorio a
otro, sin interactuar con el hipervisor, por lo que no se requiere de Snapshots, ni de la interacción con
VSS, entre otros.

Un Job de Backup Copy puede contener una o multiples VMs, en cuyo caso las VMs serán procesadas
en paralelo al momento de ejecutar el Job. Si una VM tiene múltiples discos virtuales, los discos son
procesados secuencialmente, uno detrás de otro.

Los pasos a seguir para crear un Job de Backup Copy son los siguientes:

1. Dirigirse al tab Home, hacer click en Backup Copy > Virtual machine > VMware vSphere.

#VMwarePorvExperts 460
Capítulo 9 - Backup y Réplicas Patricio Cerda

2. Al iniciar el asistente debemos especificar un nombre y descripción para el Job de Backup Copy.
Se recomienda diseñar una nomenclatura de nombres que permita identificar fácilmente el objetivo
de este Job y las VM que contiene.

Aquí también debemos especificar qué tan seguido se ejecutará el Job de Backup Copy. Un
Job de Backup Copy se ejecuta continuamente, donde el proceso de sincronización se inicia a
intervalos específicos de tiempo, por defecto el intervalo de ejecución de Backup Copy es de 1 día.
Esto significa que el job de Backup Copy creará un nuevo intervalo de Backup Copy una vez al día.

Durante el intervalo de Backup Copy, Veeam verificará si hay nuevos puntos de restauración
disponibles en el Repositorio de origen, y en caso de haberlos, copiara estos nuevos puntos de
restauración disponibles desde el Repositorio de origen hacia el Repositorio de destino.

3. Luego debemos seleccionar las VM que serán parte de este Job de Backup Copy. Debemos
destacar en primer lugar, que las VMs incluidas en un Job de Backup Copy no necesitan coincidir
con las VMs incluidas en un Job de Respaldo. El único requisito en este caso es que la o las VMs
deben estar incluidas en el menos un Job de Respaldo. Podemos seleccionar VMs desde

a. La infraestructura virtual. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en todos los Repositorios disponibles.

b. Desde los respaldos. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en todos los respaldos creados por Veeam.

c. Desde un Job de respaldo. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en los respaldos creados por dicho Job.

#VMwarePorvExperts 461
Capítulo 9 - Backup y Réplicas Patricio Cerda

Adicionalmente en este punto podemos excluir VMs en el Job de Backup Copy.

NOTA: Es posible limitar los Repositorios desde donde el Job de Backup Copy obtendrá los datos de
las VM a ser copiadas al Repositorio Secundario, en caso de que las VMs se hayan añadido al Job
usando las opciones “From Infrastructure” y “From Backups”. De esta forma, Backup Copy buscará
nuevos puntos de restauración solo en los Repositorios seleccionados. Por defecto Veeam buscará
nuevos puntos de restauración en todos los Repositorios disponibles (No aplica para VMs añadidas a
partir de un Job de Respaldo).

#VMwarePorvExperts 462
Capítulo 9 - Backup y Réplicas Patricio Cerda

4. El siguiente paso nos permite definir varios parámetros:

a. En primer lugar, podemos especificar el Repositorio donde serán almacenados los respaldos
creados por el Job de Backup Copy.

b. Luego debemos especificar el número de puntos de restauración que utilizará el Job de


Backup Copy. Por defecto Backup Copy se ejecutará diariamente, por lo que, si especificamos
7 puntos de restauración, significa que tendremos una retención de Días.

NOTA: La cadena de respaldo creada por Backup Copy es equivalente a una cadena de
respaldo utilizando Forever Forward Incremental, por lo cual existirá solo un respaldo Full en
la cadena de respaldo creada por Backup Copy en el repositorio secundario. Esto además
recuerden puede tener un impacto en la performance del Repositorio.

c. En caso de requerir una retención más prolongada, podemos utilizar el esquema GFS
(Grandfather, Father, Son), donde el Job de Backup Copy podrá crear respaldos full periódicos,
que pueden ser semanales, mensuales, trimestrales y/o anuales.

Podemos configurar por ejemplo 4 respaldos semanales, 12 respaldos mensuales, y 3 respaldos


anuales, de manera de tener 3 años de retención de los respaldos.

Los respaldos con GFS pueden ser programados para ser ejecutados en días específicos de la
semana o del mes. Por ejemplo, ejecutar los respaldos mensuales el último domingo de cada
mes.

#VMwarePorvExperts 463
Capítulo 9 - Backup y Réplicas Patricio Cerda

5. A continuación, si hacemos click en Advance, podremos definir los siguientes parámetros:

a. Opciones de mantenimiento, por ejemplo, realizar un Health Check periódico de los


archivos de respaldo, de manera de verificar que no exista corrupción de datos. Del mismo
modo podemos configurar la ejecución periódica de una desfragmentación y compactación del
archivo Full Backup, algo que puede ser especialmente útil cuando utilizamos Forever Forward
Incremental o Reverse Incremental.

b. Opciones de almacenamiento:

i. Habilitar o deshabilitar deduplicación nativa de Veeam (por defecto habilitada).

ii. Configurar el nivel de compresión de los archivos de respaldo.

iii. Habilitar encriptación de los respaldos.

c. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de


correo donde enviar estas notificaciones, así como también que tipo de notificación deseamos
recibir.

d. En la sección “Integration” también podremos habilitar el uso de Backup from Storage


Snapshots, siempre que la cabina de almacenamiento lo soporte y se encuentre integrada con
Veeam Backup Server.

e. Por último, podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.

6. El siguiente punto nos permite especificar si el Job de Backup Copy realizará la copia de los
respaldos de manera directa de un Repositorio a otro, o utilizando WAN Accelerator:

a. La copia Directa permite que los datos de las VMs sean movidos desde un Repositorio a otro
sin interacción de otros componentes. Este método es recomendado para copias de respaldos
dentro del mismo sitio (on-site), o para copias a sitios remotos a través de una conexión de red
de alta velocidad.

b. La copia vía WAN Accelerator permite el uso de un par de WAN Accelerators (uno en cada

#VMwarePorvExperts 464
Capítulo 9 - Backup y Réplicas Patricio Cerda

sitio) para ahorrar ancho de banda y acelerar la ejecución de Backup Copy. Este método es
recomendado cuando no contamos con un suficiente ancho de banda en la conexión entre
ambos sitios.

NOTA: Si desea saber más sobre el funcionamiento de Veeam WAN Acceleration, pueden
revisar el siguiente link: https://goo.gl/zL51y7

7. Finalmente debemos especificar una ventana de respaldo en la cual el Job de Backup Copy podrá
ejecutarse. Recuerden que por defecto el Job de Backup Copy se ejecuta en intervalos de 1 día,
y con esta opción podemos restringir en qué momento del día se procederá con la copia de los
respaldos. No es posible especificar un horario específico para la ejecución de un job de Backup
Copy.

8. Finalmente verificamos que todos los parámetros estén en orden, pudiendo habilitar de inmediato
el Job para que comience a ejecutarse, y hacemos click en Finish para finalizar.

4.4 Job de Réplica

#VMwarePorvExperts 465
Capítulo 9 - Backup y Réplicas Patricio Cerda

Veeam Backup & Replication, como su nombre lo dice, no solo puede ser utilizado para respaldar
máquinas virtuales, sino que también podemos crear Replicas de máquinas virtuales. Al igual que con
los respaldos, las operaciones de réplica se ejecutan sin requerir ningún tipo de agente dentro del
sistema operativo de la VM, apalancando el uso de los Snapshots de VM en VMware.

La replicación con Veeam funciona de manera similar a un respaldo incremental, es decir, durante
la primera replicación de una VM, Veeam copia los datos de la VM ejecutándose en el host ESXi de
origen, y crea una réplica completa en el host ESXi de destino. Luego, las siguientes replicaciones
enviarán solo los cambios que se han producido en la VM desde la anterior replicación, de manera
similar a un respaldo incremental, apalancando también el uso de Change Block Tracking (CBT).

A diferencia de los respaldos, una réplica de una VM es una VM estándar que se mantiene en formato
nativo en el host ESXi de destino, por lo que al ejecutar un Failover, la VM replica puede ser encendida
de inmediato y estar operativa en pocos minutos, permitiendo cumplir RTOs muy exigentes.

Es posible utilizar un job de Replicación para replicar una VM localmente en el mismo Datacenter. Esta
modalidad permite de cierta manera proveer de un mecanismo de alta disponibilidad (HA) a VMs cuyos
sistemas operativos y/o aplicaciones no cuentan con mecanismos nativos de HA o Clustering.

Del mismo modo, podemos utilizar un Job de Replicación para replicar una VM a un sitio remoto, de
manera de proteger la VM en caso de un desastre que provoque la caída del Datacenter completo.

Para crear un Job de Replicación en Veeam deberemos seguir un simple proceso:

1. Dirigirse al tab Home, hacer click en Replication Job > Virtual machine > VMware vSphere.

#VMwarePorvExperts 466
Capítulo 9 - Backup y Réplicas Patricio Cerda

2. Ingresar el nombre del Job. Se recomienda diseñar una nomenclatura de nombres que permita
identificar fácilmente el objetivo de este Job y las VM que contiene. En este punto también existen
algunas opciones adicionales en caso de que planeemos replicar una VM a un sitio remoto:

a. Low Connection Bandwidth: Habilita el uso Replica Seeding, lo cual permite utilizar un
respaldo ya existente en el sitio remoto, de manera de crear la primera replica principalmente a
partir de este respaldo, reduciendo la cantidad de datos que se debe enviar a través de la WAN,
al requerir solo enviar los datos incrementales necesarios, que representan los cambios en los
datos de la VM desde que el respaldo fue creado.

b. Separate Virtual Networks: Si las redes en el sitio remoto no coinciden con las redes en
producción, es posible crear una tabla de Network Mapping para resolver esta inconsistencia.
Básicamente le decimos a Veeam cual PortGroup en el sitio remoto corresponde a determinado
PortGroup en el sitio de Producción.

c. Different IP Addressing Scheme: Permite crear reglas de re-IP para VMs utilizando Sistema
operative Windows. Esto puede ser útil si los segmentos de red utilizados en el sitio local
y el sitio remoto no son los mismos. De esta manera, al realizar un Failover, Veeam podría
reemplazar la IP original de la VM Replica, por una IP valida en el sitio remoto, utilizando las
reglas de re-IP para lograrlo.

3. Seleccionar las VMs que se desean incluir en este Job de Replicación.

a. Hacer click en Add, con lo cual se abrirá otra ventana para seleccionar las VMs a añadir.

b. En la barra de tareas que vemos algunas opciones, que nos permiten visualizar las VMs
utilizando distintas vistas: Hosts and Clusters, VMs and Templates, Datastores and VMs y
VMs and Tags.

c. A continuación, podemos seleccionar VMs individuales, o contenedores con múltiples VMs.


Podemos seleccionar múltiples VMs en este proceso.

d. También en la parte inferior tenemos un cuadro de búsqueda, que nos facilita encontrar VMs
específicas, lo cual puede ser de mucha utilidad en grandes infraestructuras con cientos o
incluso miles de VMs.

#VMwarePorvExperts 467
Capítulo 9 - Backup y Réplicas Patricio Cerda

4. Adicionalmente en este punto podemos excluir objetos en el Job de Replicación:

a. Podemos excluir discos virtuales específicos de una VM.

b. Podemos excluir VMs desde un contenedor de VMs (ej. Carpetas, Datastores, Resource
Pools, etc.)

5. Finalmente, en este punto también podemos especificar desde donde el Job obtendrá los datos
para crear la replica:

a. Desde el almacenamiento en producción (por defecto). En este caso, Veeam leerá los datos
de las VMs desde el almacenamiento en producción, utilizando alguno de los métodos de
transporte soportados.

b. Desde archivo de respaldo (Remote replica from backup). Permite crear replicas (full e
incrementales) a partir de respaldos previamente creados.

#VMwarePorvExperts 468
Capítulo 9 - Backup y Réplicas Patricio Cerda

6. A continuación, deberemos seleccionar el destino donde la réplica será creada:

a. En primer lugar, debemos seleccionar un host ESXi o vSphere Clúster de destino. Este host
ESXi debe haber sido registrado previamente en Veeam Backup Server, ya sea a través del
registro de vCenter Server, o el registro del host ESXi directamente.

b. Luego debemos seleccionar el Resource Pool al cual pertenecerá la réplica. Podemos


especificar un Resource Pool para todas las VMs del Job, o utilizar Resource Pools distintos
para cada máquina virtual.

c. A continuación, debemos seleccionar la carpeta a la cual pertenecerá la réplica. Podemos


especificar una Carpeta para todas las VMs del Job, o utilizar Carpetas distintas para cada
máquina virtual.

d. Por último, debemos seleccionar el Datastore donde la máquina virtual será almacenada.
Podemos especificar un Datastore para todas las VMs del Job, o utilizar Datastores distintos
para cada máquina virtual.

7. El siguiente paso es crear los Network Mappings o asociación de redes. Si las redes en el sitio
remoto no coinciden con las redes en producción, es posible crear una tabla de Network Mapping
para resolver esta inconsistencia. Básicamente le decimos a Veeam cual PortGroup en el sitio
remoto corresponde a determinado PortGroup en el sitio de Producción.

#VMwarePorvExperts 469
Capítulo 9 - Backup y Réplicas Patricio Cerda

8. A continuación, podemos crear también reglas de re-IP para VMs utilizando Sistema operativo
Windows. Esto puede ser útil si los segmentos de red utilizados en el sitio local y el sitio remoto no
son los mismos. De esta manera, al realizar un Failover, Veeam podría reemplazar la IP original
de la VM Replica, por una IP valida en el sitio remoto, utilizando las reglas de re-IP para lograrlo.

9. En este punto también debemos especificar algunos parámetros adicionales requeridos por el Job
de Replicación:

a. Debemos especificar el repositorio que utilizaremos para almacenar la metadata generada


por el Job de Replicación.

i. Un Job solo puede tener asignado un único Repositorio.

ii. No se puede utilizar Scale-Out Backup Repository para la metadata de las réplicas.

b. A continuación, debemos elegir un sufijo a utilizar por las réplicas. Esto permitirá diferenciar
entre la VM original y la VM replica.

c. Finalmente, en este punto debemos especificar la política de retención para este Job.
Básicamente debemos especificar el número de puntos de Restauración que deseamos
mantener en la réplica.

i. Por ejemplo, si realizaremos una réplica diaria, y deseamos una retención de una semana,

#VMwarePorvExperts 470
Capítulo 9 - Backup y Réplicas Patricio Cerda

debiéramos configurar 7 puntos de restauración.

ii. Del mismo modo, si por ejemplo deseamos realizar replicas cada 1 hora, con una retención
de un día, debiéramos configurar 24 puntos de restauración.

10. A continuación, si hacemos click en Advance, podremos definir los siguientes parámetros:

a. Opciones de Trafico:

i. Excluir archivos Swap y/o archivos eliminados.

ii. Configurar el nivel de compresión de los archivos de respaldo.

iii. Optimizaciones de almacenamiento.

#VMwarePorvExperts 471
Capítulo 9 - Backup y Réplicas Patricio Cerda

b. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de


correo donde enviar estas notificaciones, así como también que tipo de notificación deseamos
recibir.

c. Parametros de vSphere, como por ejemplo habilitar o deshabilitar Change Block Tracking
(CBT)

d. En la sección “Integration” también podremos habilitar el uso de Backup from Storage


Snapshots, siempre que la cabina de almacenamiento lo soporte y se encuentre integrada con
Veeam Backup Server.

e. Por último podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.

11. El siguiente punto nos permite especificar si el Job de Replicación realizará la copia de los respaldos
de manera directa de un host ESXi a otro, o utilizando WAN Accelerator:

a. La copia Directa permite que los datos de las VMs sean movidos desde un host ESXi a otro
sin interacción de otros componentes. Este método es recomendado para replicación dentro
del mismo sitio (on-site), o para replicación a sitios remotos a través de una conexión de red
de alta velocidad.

b. La copia vía WAN Accelerator permite el uso de un par de WAN Accelerators (uno en cada
sitio) para ahorrar ancho de banda y acelerar la ejecución de un Job de Replicación. Este
método es recomendado cuando no contamos con un suficiente ancho de banda en la conexión

#VMwarePorvExperts 472
Capítulo 9 - Backup y Réplicas Patricio Cerda

entre ambos sitios.

NOTA: Si desea saber más sobre el funcionamiento de Veeam WAN Acceleration, pueden revisar el
siguiente link: https://goo.gl/zL51y7

12. El siguiente paso es la posibilidad de habilitar Replica seeding o Replica Mapping:

a. Replica Seeding permite utilizar un respaldo ya existente en el sitio remoto como semilla,
de manera de crear la primera replica principalmente a partir de este respaldo, reduciendo la
cantidad de datos que se debe enviar a través de la WAN, al requerir solo enviar los datos
incrementales necesarios, que representan los cambios en los datos de la VM desde que el
respaldo fue creado.

b. Replica Mapping permite utilizar una máquina virtual ya existente en el sitio remoto como
semilla, de manera de crear la primera replica principalmente a partir de esta máquina virtual,
reduciendo la cantidad de datos que se debe enviar a través de la WAN, al requerir solo enviar
los datos incrementales necesarios, que representan las diferencias entre la VM que deseamos
replicar, y la VM que estamos utilizando como semilla.

13. A continuación, debemos especificar los parámetros de procesamiento de las máquinas virtuales:

#VMwarePorvExperts 473
Capítulo 9 - Backup y Réplicas Patricio Cerda

a. Podemos habilitar Application-aware processing, lo cual permite realizar replicas consistentes


a nivel de sistema operativo, y opcionalmente habilitar el procesamiento de Transaction Logs.
Esta opción la podemos habilitar o deshabilitar para todas las VMs del Job, o solo para algunas
de ellas, lo cual podemos personalizar haciendo click en Applications.

i. Aquí tendremos una lista de las VMs en el Job, donde podremos deshabilitar el
procesamiento a nivel de aplicaciones.

ii. También podemos configurar el uso de Transaction Logs para SQL, donde podemos
elegir truncar o no estos Transaction Logs.

#VMwarePorvExperts 474
Capítulo 9 - Backup y Réplicas Patricio Cerda

iii. Adicionalmente podemos configurar el uso de Transaction Logs para Oracle, donde
podemos elegir su eliminar o no estos Transaction Logs. Aquí además debemos especificar
una cuenta de usuario con privilegios de SYSDBA.

iv. Podemos además especificar que ciertas carpetas o archivos sean excluidos del proceso
de réplica, como por ejemplo la carpeta de archivos temporales.

v. En caso de que la VM a replicar no sea compatible con Microsoft VSS, podemos también
especificar scripts de pre-freeze y post-thaw para poder llevar a cabo el proceso de
quiescing, y así asegurar la consistencia de la réplica.

#VMwarePorvExperts 475
Capítulo 9 - Backup y Réplicas Patricio Cerda

b. Finalmente, debemos especificar credenciales de usuario con privilegios de administración


sobre las VMs, lo cual es obligatorio en caso de habilitar Application-aware processing o Guest
file system Indexing. Podemos especificar una sola cuenta de usuario para todas las VMs del
Job, o podemos especificar cuentas individuales por cada VM.

14. Finalmente, debemos especificar cuándo se ejecutará este Job en las opciones de Schedule. Un Job
puede ejecutarse diariamente (todos los días o días específicos), mensualmente, periódicamente
(por ejemplo, cada 1 hora), o después de un Job (no se recomienda encadenar Jobs)

a. Aquí también podemos especificar si se reintentará la ejecución del Job en caso de producirse
una falla. Por defecto el Job reintentará ejecutarse hasta un máximo de 3 veces, con un tiempo
de espera de 10 minutos entre intentos.

b. Por último, podemos especificar una ventana de ejecución para el Job de Replica, por
ejemplo, que los respaldos se ejecuten entre las 10 PM y las 8 AM. En este caso, si el Job
de respaldo no finaliza dentro de la ventana de respaldo especificada, el Job será cancelado
automáticamente, incluyendo el procesamiento de todas las tareas en ejecución.

15. Como último paso hacemos click en Finish, y ya tendremos nuestro Job de Replicación listo para
ser utilizado.

#VMwarePorvExperts 476
Capítulo 9 - Backup y Réplicas Patricio Cerda

5. Opciones de Restauración

En esta sección revisaremos algunas de las opciones de recuperación que tenemos con Veeam
Backup and Replication.

Podemos utilizar Veeam para restaurar una VM completa de dos formas: Restauración full o Instant
VM Recovery.

5.1 Restauración Full de una VM

El tipo de restauración más tradicional y simple. Utilizando este tipo de restauración, todos los datos
que componen la VM serán copiados desde el Repositorio hacia el almacenamiento en producción.

Este tipo de restauración puede tomar mucho tiempo y consumir considerables recursos, ya que
estaremos transfiriendo grandes cantidades de datos dependiendo del tamaño de la máquina virtual.
Del tamaño de la máquina virtual también dependerá el tiempo que tarde el proceso de restauración
para ser completado.

Durante la restauración, el Proxy elegirá automáticamente el método de transporte más adecuado


para proceder con la copia de los datos al almacenamiento en producción, pudiendo utilizar Direct
Storage Access, Virtual Appliance mode, o Network mode.

Una VM puede ser restaurada a su ubicación original, en cuyo caso la VM original será apagada
y removida antes de restaurar la VM desde el respaldo. Una VM también puede ser restaurada a
una ubicación alterna, especificando host ESXi, Datastore y un nombre para la VM, el cual no debe
coincidir con el nombre de otras VMs en el inventario.

NOTA: Al restaurar la VM a la ubicación original, puede también usarse la opción “Quick Rollback”, la
cual básicamente realiza una restauración incremental sobre la VM que ya existe en el inventario de
vCenter Server.

El proceso de restauración requiere de los siguientes pasos:

1. En el tab Home, click Restore > VMware vSphere > Restore from backup > Entire VM restore
> Entire VM restore.

#VMwarePorvExperts 477
Capítulo 9 - Backup y Réplicas Patricio Cerda

2. Seleccionar la o las VMs que deseamos restaurar.

#VMwarePorvExperts 478
Capítulo 9 - Backup y Réplicas Patricio Cerda

3. Seleccione el punto de restauración que desea recuperar, pudiendo ser de un respaldo full o
incremental.

4. Seleccione el modo de restauración, pudiendo restaurar a la ubicación original, o a una ubicación


alterna. También a partir de Veeam Backup & Replication 9.5 Update 4, tenemos una nueva opción
llamada “Staged Restore”. Si quieren saber más acerca de Staged Restore, pueden revisar el
siguiente link: https://goo.gl/Z8Ae5n

5. Si se ha seleccionado la restauración en una ubicación alterna, se deberán especificar los siguientes


parámetros:

a. Host ESXi donde restaurar la VM.

b. Resource Pool donde será ubicada la VM.

c. Datastore donde la VM será almacenada. Se puede elegir un Datastore separado por cada
disco virtual si se requiere, además de poder elegir el formato del disco virtual (Thin o Thick
provisioned).

#VMwarePorvExperts 479
Capítulo 9 - Backup y Réplicas Patricio Cerda

d. Carpeta donde la VM será ubicada.

e. Especificar el PortGroup al cual la VM será conectada.

6. Es posible también activar el uso de Secure Restore, lo cual permite analizar la VM restaurada con
una solución anti-malware antes de realizar la restauración como tal en el ambiente productivo.

#VMwarePorvExperts 480
Capítulo 9 - Backup y Réplicas Patricio Cerda

Más información sobre Secure Restore en el siguiente link: https://goo.gl/ST7hsj

7. Podemos además activar el uso de Staged Restore, el cual permite manipular la VM antes de
realizar la restauración en el ambiente productivo. Esta función apalanca las funciones de Virtual
Lab y vPowerNFS para funcionar. Mayor información sobre Staged Restore en el siguiente link:
https://goo.gl/Z8Ae5n

8. Finalmente ingresamos las razones de ejecución de esta restauración, con lo cual Veeam procederá
con la restauración de la VM completa.

5.2 Restauración con Instant VM Recovery

Restaurar una VM completa, dependiendo de su tamaño, puede tardar horas, tiempo en el que los
usuarios no pueden acceder a los servicios afectados por la falla.

Para poder acelerar este proceso, y poder tener los servicios operativos a la brevedad posible, Veeam
nos ofrece Instant VM Recovery, una funcionalidad que permite tener una VM operativa en cosa
de minutos a partir de un respaldo. Para esto se utilizan tecnologías y técnicas desarrolladas
directamente por Veeam.

Instant VM Recovery nos permite restaurar inmediatamente una VM en un ambiente de producción


ejecutando la máquina virtual directamente desde el archivo de respaldo. La VM en sí misma no es
restaurada directamente al Storage de producción (datastore), sino que Veeam buscará encenderla en
un host ESXi mientras que los archivos que componen la VM se encuentran aún en el Repositorio de
Respaldo en estado deduplicado y comprimido.

Debido a que no se necesita extraer la VM desde el archivo de respaldo y copiarlo en el Storage de


producción, se puede iniciar la VM desde cualquier punto de restauración, ya sea Full o Incremental,
en cosa de minutos, mejorando el RTO y minimizando el downtime de las VMs en producción. De esta
forma, una VM restaurada con Instant VM Recovery permite que los usuarios puedan volver a usar los
servicios en Producción, mientras que resolvemos el problema que provocó la falla en la VM original.

NOTA: Si quiere saber más en detalle el funcionamiento de Instant VM Recovery, pueden ver el
siguiente link: https://goo.gl/Bpp3Sr

La restauración de una VM con Instant VM Recovery es un proceso bastante simple, y lo podemos

#VMwarePorvExperts 481
Capítulo 9 - Backup y Réplicas Patricio Cerda

resumir en los siguientes pasos:

1. Lanzamos el asistente de restauración.

2. Seleccionamos la opción “Instant VM recovery”

3. Seleccionamos la o las VM que queremos recuperar con IVMR

#VMwarePorvExperts 482
Capítulo 9 - Backup y Réplicas Patricio Cerda

4. Seleccionamos el punto de restauración a utilizar

5. Seleccionamos si deseamos restaurar la VM a su ubicación original, lo cual además incluye la


eliminación de la VM original en vSphere, o si vamos a restaurar la VM a una ubicación alterna
donde podemos especificar distintos parámetros, incluyendo el nombre de la VM.

6. Si seleccionamos una ubicación alterna debemos especificar el host ESXi y Datastore a utilizar,
además de especificar el nombre con el que la VM será restaurada.

7. Es posible también, de manera opcional, especificar un datastore para almacenar los bloques que
hayan cambiado durante la ejecución de Instant VM Recovery. Por defecto estos cambios son
almacenados en un cache de vPowerNFS.

#VMwarePorvExperts 483
Capítulo 9 - Backup y Réplicas Patricio Cerda

8. Ingresamos un detalle de las razones para la restauración para efectos de auditoria.

9. Y por último especificamos si la VM deberá ser encendida y conectada a la red una vez que sea
restaurada con IVMR.

Instant VM Recovery es solo una restauración temporal de una VM, ya que no podemos dejarla
corriendo permanentemente desde vPower NFS, por dos razones principales:

• La performance de la VM no será comparable a la de una VM completamente en Producción,


ya que estaremos utilizando un archivo de respaldo que se encuentra en estado comprimido y
deduplicado, y en un Repositorio de Respaldo cuyo diseño no está necesariamente optimizado
para performance, sino para capacidad.

• La VM depende de que el servidor vPower NFS se encuentre operativo para que se mantenga
en funcionamiento. Si el servidor vPower NFS falla o deja de funcionar por cualquier motivo, la VM
recuperada con Instant VM Recovery dejará de funcionar inmediatamente.

Entonces lo importante ahora es definir cómo mover de forma permanente esta VM a producción, sin
perder los cambios realizados durante el tiempo que la VM ha estado funcionando sobre vPower
NFS, finalizando así la sesión de Instant VM Recovery. Esto lo podemos conseguir con una de las
siguientes 3 técnicas:

• Storage vMotion: Se puede usar Storage vMotion para migrar la VM restaurada desde el datastore
vPower NFS al Storage en Producción sin ningún downtime. En este caso, la data de la VM será

#VMwarePorvExperts 484
Capítulo 9 - Backup y Réplicas Patricio Cerda

movida desde el repositorio de respaldo (a través de vPower NFS) a Producción, consolidando


además los cambios realizados mientras la VM se encontraba funcionando con IVMR.

• Replicar o copiar la VM con las funcionalidades nativas de Veeam. En este caso, al finalizar la
copia/replica se debe realizar una operación de Failover, lo cual requiere un periodo de downtime
mientras se copia/replica la VM, se apaga la VM con IVMR, y se enciende la VM copiada/replicada.

• Quick Migration: Veeam restaurará la VM desde el Backup Repository al storage de Producción,


sin el uso de vPower NFS, utilizando una restauración tradicional. El estado de la VM y los cambios
que se han producido mientras la VM se encontraba en ejecución con IVMR serán movidos a la
nueva ubicación donde se está realizando la restauración. Este proceso asegura un downtime
mínimo durante la migración.

NOTA: Si quiere saber más en detalle el funcionamiento de Instant VM Recovery, pueden ver el
siguiente link: https://goo.gl/Bpp3Sr

#VMwarePorvExperts 485
Capítulo 9 - Backup y Réplicas Patricio Cerda

6. Conclusión

Durante este capítulo de respaldos, hemos revisado múltiples conceptos asociados al proceso de
protección de datos en un Datacenter, así como también algunas recomendaciones y buenas prácticas.

Del mismo modo, hemos podido analizar múltiples recomendaciones de diseño y dimensionamiento
específicos para Veeam Backup & Replication. Si bien es imposible cubrir todas las opciones ofrecidas
por Veeam en este capítulo, se ha hecho lo posible por incluir la información que puede ser de mayor
utilidad a la hora de diseñar e implementar Veeam Backup & Replication.

Si desean saber más acerca de Veeam, y de todas las opciones y funcionalidades disponibles, les
recomiendo leer:

1. Documentación oficial de Veeam Backup & Replication para vSphere: https://helpcenter.veeam.


com/docs/backup/vsphere/overview.html?ver=95u4

2. Documento de buenas prácticas de Veeam: https://bp.veeam.expert

#VMwarePorvExperts 486
Capítulo 9 - Backup y Réplicas Patricio Cerda

#VMwarePorvExperts 487
Vembu BDR Suite
No mas complicaciones con el backup
Podría tener actualmente maquinas virtuale o considerar
desplegarlas en un futuro.
Cómo protegería esas maquinas para habilitar la Continuidad
del Negocio?
Está su sistema preparado para fallos inesperados?
Debe tener un plan de acción - BACKUP

Una solución de protección de datos todo incluido para entornos vSphere


“Vembu asegura disponibilidad en nuestros entornos principales de producción que dan soporte a las operaciones de negocio del Grupo
Mackie. Disponibilidad 24x7 en las aplicaciones y sus datos es algo crítico para nosotros, Vembu cumple con nuestros requerimientos.
Vembu se ha convertido en un componente imprescindible en nuestra estrategia de continuidad de negocio de TI.”

- Lee Wong, responsable de Servicios de TI en el grupo Mackie

Backup GRATUITO Ilimitado de Maquinas Virtuales


vembu.com/vembu-bdr-suite-download/

Principales Características
Backup y Replicación sin agentes para Recuperación garantizada con la
proteger todo su entorno vSphere verificación automática del backup

Comience a proteger sus maquinas en menos de 15 Opciones flexibles de backup como app-aware, incremental,
minutos con opciones de recuperación instantánea y políticas de programación y retención y muchas mas…
granular
Capítulo 10
Monitorización de vSphere

Jorge de la Cruz

#VMwarePorvExperts 489
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Monitorización de entornos vSphere

Cuando hablamos de monitorización de vSphere, nos puede venir a la mente diferentes productos,
formas de monitorizar, capas que nos interesa tener controladas, etc.

En este libro vamos a hablar de diferentes maneras de monitorizar nuestro clúster de vSphere, desde
el metal o servidor ESXi que nos otorga la abstracción de recursos de hardware, hasta las aplicaciones
que se ejecutan en las VMs, gracias a las VMware Tools.

Cuando hablamos de monitorización, nos vamos a referir a la habilidad de poder visualizar los eventos
y alarmas de las diferentes capas dentro de nuestro entorno de vSphere, no solamente esto, sino que
además gracias a herramientas como vRealize Operations Manager, vamos a tener una inteligencia
del consumo de recursos durante un periodo de tiempo, y poder crear simulaciones de cargas de
trabajo durante un periodo de tiempo en el futuro.

Si bien este libro no puede abarcar la infinidad de productos comerciales y open source que se
encuentran disponibles a día de hoy para vSphere, vamos a poder analizar en profundidad vRealize
Operations Manager, ESXTOP para monitorización muy a bajo nivel dentro de nuestro hipervisor y
veremos también un ejemplo práctico usando una herramienta de monitorización open source que
hace uso del SDK de VMware.

#VMwarePorvExperts 490
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

1. Monitorizando el rendimiento de vSphere con las


gráficas de vCenter Server

Las alarmas son una gran herramienta para alertar a los administradores de condiciones o eventos
específicos, pero las alarmas no proporcionan la información detallada que los administradores a veces
necesitamos tener. Aquí es donde entran en juego los gráficos de rendimiento de vCenter Server.
vCenter Server tiene muchas funciones nuevas y actualizadas para crear y analizar gráficos. Sin estos
gráficos, el análisis del rendimiento de una máquina virtual sería más complicado y necesitaríamos
siempre herramientas de terceros. La instalación de agentes dentro de una máquina virtual no
proporcionará detalles precisos sobre el comportamiento del servidor ESXi o el consumo de recursos
de un clúster. La razón es obvia: una máquina virtual se configura sólo con dispositivos virtuales y es
una abstracción de Hardware. Sólo el VMkernel de VMware conoce la cantidad exacta de consumo de
recursos para cualquiera de esta abstracción de recursos porque actúa como árbitro entre el hardware
virtual y el hardware físico. En la mayoría de los entornos virtuales, los dispositivos virtuales de las
máquinas virtuales pueden superar en número a los dispositivos de hardware físicos reales, lo que
conocemos como consolidation ratio, lo que requiere las complejas capacidades de compartición y
programación del VMkernel.

Al hacer clic en la pestaña de Performance dentro de nuestro Datacenter en nuestro vSphere Client
HTML5 o dentro de un clúster, host o máquina virtual, podemos obtener una gran cantidad de
información.

Vamos a comenzar con un vistazo al estado de salud de nuestro VCSA, para ello, nos iremos hasta
la vista de Hosts and Clusters, haremos click en nuestro VCSA, nos desplazaremos hasta el menú
llamado Monitor y haremos click en Health.

Esta monitorización nos indica el estado de varios componentes y servicios de nuestro VCSA, por
ejemplo, en la ilustración se aprecia el consumo de cada partición de disco del VCSA, muy importante
cuando estamos realizando upgrades, por ejemplo, o también importante en caso de que estemos
almacenando logs de salud por mucho tiempo, estas particiones pueden llenarse.

Esta monitorización no se queda aquí, también nos ayuda a comprender el estado de vMotion, el
estado del almacenamiento de los logs de los ESXi, y por ejemplo el warning que tengo sobre las
vulnerabilidades en el microprocesador Intel, ya que no he aplicado los parches.

#VMwarePorvExperts 491
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Continuando en la vista de Hosts and Clusters, bajaremos hasta el Datacenter que tenemos creado a
nivel lógico, nos iremos hasta Monitor y luego en Performance – Overview, esta vista nos muestra un
vistazo rápido del estado de nuestros diferentes clústeres:

O el consumo dentro de todos los Datastores por tipo de fichero, muy útil para saber si tenemos
Snapshots, o Swap, o cualquier otro tipo de ficheros llenando nuestro valioso espacio en disco:

También podríamos ver si hacemos click una vez más en View, el espacio usado por los diferentes
Datastores, pero es una vista muy básica y he preferido no añadir captura de pantalla.

Si continuamos en la misma pestaña, pero hacemos click en Advanced, podemos ver en este caso
de Datacenter, el número de operaciones especiales realizados en las máquinas virtuales, tales como
pueden ser vMotions, Storage vMotions, VM Power ON y VM Power Off, interesante gráfica:

#VMwarePorvExperts 492
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Vamos a bajar un nivel ahora hasta uno de nuestros Clúster, en éste mismo nos iremos hasta Monitor,
y allí en el menú de Performance, haremos click Overview, hay varias vistas, en la principal podremos
ver el consumo de CPU, RAM y el número de operaciones realizado en las máquinas virtuales:

Continuando en esta misma pestaña, cambiaremos de vista por la de Resource Pool y Máquinas
Virtuales, que nos mostrará un breve resumen del tiempo que seleccionemos referente a consumo de
CPU y Memoria RAM, en un cómodo TOP 10:

#VMwarePorvExperts 493
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Continuando en esta pestaña, pero cambiando a la vista Avanzada, podremos ver que vienen varias
vistas ya preparadas, pero lo más importante es que podremos editar el Chart Options para crear una
vista más refinada.

Las vistas refinadas en los Chart Options nos permitirán una visualización mucho más detallada, pero
en el caso de Clúster no hay demasiada información relevante, con lo que lo veremos más adelante.

Si bajamos un nivel más, hasta uno de los Hosts, nos vamos hasta Monitor, y luego hasta Performance
– Overview, vamos a poder ver un resumen muy detallado del consumo de CPU, RAM, Disco y
Networking en tiempo real con un máximo de hasta una hora, con lo que es perfecto para hacer
troubleshooting de problemas en tiempo real:

#VMwarePorvExperts 494
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Una de mis vistas favoritas en este simple Overview en los hosts, es la vista llamada Virtual Machines,
que nos mostrará de manera agregada el TOP 10 de VMs que están consumiendo más CPU, RAM,
Disco y Networking, de forma que con un simple click, tengo todo lo que necesito:

Si nos desplazamos hasta la opción de Advanced, podemos crear gráficas mucho más detalladas,
ahora sí, como por ejemplo el consumo de CPU Ready en ms, agrupado por VM, sería algo así:

#VMwarePorvExperts 495
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Y el resultado de esta personalización en la visualización de las gráficas quedaría de la siguiente


manera:

El potencial de las vistas Avanzadas, usando el Chart Options es muy amplio, con lo que os invito a
deteneros en esta sección tanto tiempo como sea necesario para que podáis encontrar las métricas,
con el tiempo y los elementos que realmente son importantes para vosotros.

Si bajamos un nivel más, hasta cualquier VM, y nos vamos hasta Monitor, Performance, Overview,
podremos ver una monitorización más granular para esta VM en concreto, podemos visualizar de un
vistazo el consumo de CPU, RAM, Disco y Networking. Además el resto de vistas en Overview nos
proporcionan una monitorización más que suficiente para comprender si la VM tiene algún tipo de
incidencia:

#VMwarePorvExperts 496
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Para las VMs, tenemos ya lista una vista en el apartado de Advanced que nos hará la vida más sencilla
para comprender si la VM ha sido mal dimensionada a nivel de vCPU, o si el host está tardando mucho
en otorgar recursos de CPU, que suele suceder si hemos dimensionado mal el host:

Si cambiamos de vista y nos vamos hasta Storage, seleccionamos un Datastore y hacemos click en
Monitor, Performance, Overview, tendremos varias vistas muy interesantes para poder consumir, os
dejo un breve ejemplo con el espacio consumido en un Datastore por VM, pero hay otras muchas
vistas muy interesantes para comprobar el rendimiento del Datastore en concreto:

#VMwarePorvExperts 497
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

La parte de Networking está mucho más limitada y más allá de la monitorización de la red dentro de
VMs y Hosts, no encontramos vistas más detalladas dentro de vSphere Client.

Sin embargo podríamos habilitar NetFlow si estamos haciendo uso de Distributed Virtual Switches
(DVS) y poder capturar el tráfico con herramientas de terceros, aquí un link sobre cómo habilitarlo -
https://blog.paessler.com/netflow-configuration-and-monitoring-via-prtg-on-vmware-vsphere y aquí el
resultado de cómo quedaría por ejemplo con una herramienta comercial llamada PRTG:

#VMwarePorvExperts 498
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

2. Monitorizando nuestros ESXi en tiempo real usando


ESXTOP

ESXTOP es una herramienta que viene incluida de serie dentro de ESXi, y que nos proporciona
información en tiempo real del consumo de recursos dentro de un ESXi, como puede ser por ejemplo
CPU, Memoria RAM, Disco, etc. Para todos aquellos que conozcáis un poco de la consola de un
Sistema Operativo normal, ESXTOP es lo que top es para Linux.

ESXTOP incluye nueve diferentes visualizaciones desde la versión de vSphere 6.5, estas visualizaciones
específicas se pueden invocar una vez que estamos en ESXTOP presionando las siguientes teclas:

• c: CPU

• m: Memory

• v: Disk Virtual Machine

• u: Disk Device

• d: Disk Adapter

• n: Network

• i: Interrupt

• p: Power Management

• x: vSAN

Os quiero mostrar con detalle cómo invocar estas diferentes vistas, y todas las opciones que nos
proporciona cada una de ellas, lo primero que haremos será desde un SSH a un Host ESXi, invocar
esxtop, la vista por defecto a la que entramos es la de CPU:

Os dejo una tabla con todos los diferentes parámetros que ESXTOP nos está mostrando respecto al
consumo de CPU:

#VMwarePorvExperts 499
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Métrica Nombre Descripción


ID de una carga de trabajo en ejecución. El ID de la carga
de trabajo suele estar oculto y se muestra el ID del grupo,
ID ID a menos que el grupo se amplíe con el comando “e”. Esto
también se aplica a los grupos con una sola carga de
trabajo. El ID nunca es idéntico al GID.
El ID de grupo de una carga de trabajo en ejecución. Un
grupo a veces también se denomina Resource Pool, que
GID Group ID
no tiene nada en común con los Resource Pools que se
pueden configurar en un Cluster de DRS.
El ID de carga de trabajo líder, también conocido como
ID de cártel VMX para máquinas virtuales. LWID es
LWID Leader Workload ID
típicamente la primera carga de trabajo que se ha iniciado
en un grupo.
Nombre del grupo de una carga de trabajo. El número
que se adjunta al nombre es el LWID. Cuando el grupo se
NAME Name
expande con el comando “e”, se muestra el nombre de la
carga de trabajo.
El número de cargas de trabajo que se ejecutan en un
Number of
NWLD grupo. NWLD es 1 cuando el Grupo es un único proceso,
Workloads
o cuando el grupo ha sido expandido con el comando “e”.
Porcentaje de ciclos de núcleo de la CPU física utilizados
por la carga de trabajo o el grupo. %USED depende
de la frecuencia con la que el núcleo de la CPU está
funcionando y puede ser mayor o menor qué %RUN
cuando la frecuencia nominal (nominal) difiere. Los
%USED Used grupos también pueden ser superiores al 100% cuando
se configuran más vCPUs o cuando hay un alto uso de
%SYS.

UTILIZADO = %RUN + %SYS - %OVRLP

Pulsaremos ‘U’ para clasificar por columna %USED.


Porcentaje del tiempo total programado para que se
ejecute la carga de trabajo. %RUN no tiene en cuenta el
hyperthreading y el tiempo del sistema. En un servidor
%RUN Run habilitado para hyperthreading, %RUN puede ser el doble
de grande que %USED.

La principal diferencia entre %RUN y %RUN es qué


%RUN no tiene en cuenta el tiempo del sistema.
Porcentaje del tiempo que el núcleo VMkernel
ESXi dedica a la carga de trabajo para procesar las
%SYS System
interrupciones y realizar otras actividades del sistema. Un
%SYS alto normalmente significa un IO alto.

#VMwarePorvExperts 500
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Porcentaje de tiempo que una carga de trabajo pasa en el


estado de espera bloqueada u ocupada. Este porcentaje
también incluye %IDLE. El máximo teórico de %WAIT es
%WAIT Wait (NWLD*100). No hay nada malo cuando hay un valor alto
porque el tiempo de inactividad está incluido en %WAIT.

100%= %WAIT + %RDY + %CSTP + %RUN


El porcentaje total de tiempo que una carga de trabajo
pasa en un estado bloqueado a la espera de eventos. La
métrica %VMMWAIT sólo está disponible para vCPUS o
%VMWAIT Virtual Machine Wait combinada en un grupo VM.

Para vCPUS cuando una máquina virtual se expande


con el comando “e”, %WAIT = %VMWAIT + %IDLE +
%SWPWWT
El porcentaje de tiempo que la carga de trabajo estaba
lista para ejecutarse pero esperando en una cola para
ser programada. Esto puede ocurrir incluso cuando hay
muchos ciclos de CPU libres cuando una CPU VM está
limitada administrativamente, lo que se muestra con
%MLMTD.

%RDY Ready Para determinar la contención de CPU de %RDY hay que


tener en cuenta %RDY, %MLMTD y el número de vCPUS.
Si %RDY - %MLMTD es superior al 10% por vCPU, es
muy probable que esté experimentando contención de
CPU. Típicamente usted quiere ver %RDY cerca de 0.

100% = %RUN + %RDY + %CSTP + %WAIT

Presionaremos ‘R’ para ordenar por columna %RDY.


El porcentaje de tiempo que la carga de trabajo de
la vCPU está en un bucle inactivo. %IDLE sólo está
%IDLE Idle disponible para cargas de trabajo de vCPU. Otras cargas
de trabajo no tienen bucles inactivos, por lo que %IDLE
es 0.
Porcentaje de tiempo que los servicios del sistema
dedican a otras cargas de trabajo. Por ejemplo, si VM A
está siendo programado actualmente y el ESXi VMkernel
%OVRLP Overlap
procesa un paquete de red para VM B, el tiempo
empleado aparece como %OVRLP para la máquina
virtual A y %SYS para la máquina virtual B.

#VMwarePorvExperts 501
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

El porcentaje de tiempo que la máquina virtual está lista


para funcionar, pero está esperando la disponibilidad de
otras unidades de procesamiento de vídeo. El estado de
calendario se aplica sólo a las máquinas virtuales SMP. El
programador de la CPU puede poner una vCPU en este
estado, cuando la carga de trabajo de la VM no utiliza
%CSTP CoStop
vCPUs de forma equilibrada. Por ejemplo, si tiene una
VM con 2 vCPUs que ejecutan una aplicación sin SMP,
utilizando 1 vCPU al 100% y 1 vCPU al 0%. En ese caso,
el programador de la CPU penaliza a la VM para reducir
la escasez de recursos para otras VM. Esto se representa
como %CSTP.
El porcentaje de tiempo que una carga de trabajo
estaba lista para ejecutarse, pero deliberadamente no
se programó porque al hacerlo se violaría el límite de la
%MLMTD Max Limited
CPU de la máquina virtual o del conjunto de recursos. El
tiempo %MLMTD está incluido en el tiempo %RDY. Si el
valor no es 0, la VM ha sido limitada administrativamente.
El porcentaje de tiempo que una carga de trabajo
pasa esperando a que el núcleo VM cambie de
memoria. La hora %SWPWT se incluye en la hora
%WAIT. Si %SWPWT es mayor que 0, VMkernel está
%SWPWT Swap Wait intercambiando la memoria de la VM al disco. Esto tendrá
un gran impacto negativo en el desempeño general. El
intercambio puede ser causado por una sobresuscripción
de memoria alta o por límites de memoria configurados
en un pool de recursos o en una máquina virtual.
Número de interruptores de carga de trabajo por segundo.
SWTCH/s Switches/sec Un cambio de contexto ocurre cuando una CPU cambia la
ejecución de una carga de trabajo a otra.
Número de migraciones por segundo. Una carga de
MIG/s Migrates/sec trabajo puede migrarse de un pCPU ocupado a un pCPU
menos cargado para el balanceo de carga.
Número de espiraciones cuánticas por segundo. Esto
ocurre cuando expira un tiempo cuántico dado a una
Quantum Expires/ carga de trabajo que se está ejecutando actualmente. Es
QEXP/s
sec común que una carga de trabajo cambie su estado a EN
ESPERA antes de que expire el tiempo cuántico actual
(50 ms).
Número de despertadores de carga de trabajo por
WAKE/s Wakeups/sec segundo. Una carga de trabajo se despierta cuando su
estado cambia de EN ESPERA a LISTO.
Reserva de recursos, máquinas virtuales o atributos
AMIN Alloc Min de carga de trabajo. Un valor de 0 significa que no hay
reserva.
Límite de atributos de recursos, máquina virtual o carga
AMAX Alloc Max
de trabajo. Un valor de -1 significa ilimitado.

#VMwarePorvExperts 502
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Grupo de recursos, máquina virtual o atributo de carga de


trabajo Compartir. Las cuotas por defecto son -4 (Alta),
ASHRS Alloc Shares
-3 (Normal) y -2 (Baja). Cuando se configura una acción
personalizada, se muestra el valor.
AMLMT Alloc Min Limited Parámetro indocumentado.
AUNITS Allocated unit Unidad de atribución (MHz para máquinas virtuales)
El porcentaje de tiempo que el Pool de recursos/Carga
de trabajo estaba listo para ejecutarse, pero no estaba
%LAT_C Latency CPU
programado para ejecutarse debido a la contención de
recursos de la cpu.
El porcentaje de tiempo que el Pool de recursos/Carga
de trabajo estaba listo para ejecutarse, pero no estaba
%LAT_M Latency Memory
programado para ejecutarse debido a la contención de
recursos de memoria.
La demanda de CPU en porcentaje. Representa el
%DMD Demand
promedio de carga de CPU activa en el último minuto.
Asignación mínima efectiva de cpu en caso de contención
de recursos. Esta es la cantidad de MHz que la carga de
EMIN Effective Min
trabajo recibirá cuando las máquinas virtuales compitan
por los recursos.
TIMER/s Timer/sec Tasa de temporizador para esta carga de trabajo.
AFFINITY_BIT_ Máscara de bits que muestra la afinidad de programación
Affinity Bit Mask
MASK actual para la carga de trabajo.
El procesador físico o lógico en el que se ejecutaba la
CPU CPU carga de trabajo cuando resxtop (o esxtop) obtuvo esta
información.
HTSHARING HT Sharing Configuración actual del hyperthreading.
Indica si la carga de trabajo está actualmente en
HTQ HT Quarantine
cuarentena o no. N significa no y Y significa sí.
Consumo actual de energía de la CPU de una máquina
POWER Power Usage Watts virtual (en vatios). El cálculo del uso se basa en el valor
proporcionado por la fuente de alimentación.

Vamos a presionar ahora (m) para visualizar el consumo de Memoria RAM del Host, por VM, etc:

#VMwarePorvExperts 503
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

De nuevo os dejo una tabla con todos los parámetros que podemos encontrar en esta vista de ESXTOP:

Métrica Nombre Descripción


El ID de la carga de trabajo real se oculta y se visualiza
el ID de grupo. Como no puede expandir el grupo en la
ID ID
pantalla de memoria, no puede ver el ID real de la carga
de trabajo.
El ID de grupo de una carga de trabajo en ejecución. Un
grupo a veces también se denomina Resource Pool, que
GID Group ID no tiene nada en común con los Resource Pools que se
pueden configurar en un Cluster de DRS.

Pulsaremos ‘N’ para ordenar por columna GID.


El ID de carga de trabajo líder, también conocido como
ID de cártel VMX para máquinas virtuales. LWID es
LWID Leader Workload ID
típicamente la primera carga de trabajo que se ha iniciado
en un grupo.
Nombre del grupo de una carga de trabajo. El número que
NAME Name se adjunta al nombre es el LWID. Las máquinas virtuales
no tienen un número añadido.
Number of El número de cargas de trabajo que se ejecutan en el
NWLD
Workloads Grupo. NWLD es 1 cuando el Grupo es un único proceso.
Reserva de recursos, máquinas virtuales o atributos
AMIN Alloc Min de carga de trabajo. Un valor de 0 significa que no hay
reserva.
Límite de atributos de recursos, máquina virtual o carga
AMAX Alloc Max
de trabajo. Un valor de -1 significa ilimitado.
Grupo de recursos, máquina virtual o atributo de carga de
trabajo Compartir. Las cuotas por defecto son -4 (Alta),
ASHRS Alloc Shares
-3 (Normal) y -2 (Baja). Cuando se configura una acción
personalizada, se muestra el valor.
AMLMT Alloc Min Limited Parámetro indocumentado.
AUNITS Allocated unit Unidad de asignación (kilobytes para máquinas virtuales)
Nodo de inicio actual para el pool de recursos o la
máquina virtual. Esta estadística sólo es aplicable a los
sistemas NUMA. Si la máquina virtual no tiene ningún
nodo de inicio, aparecerá un guión (-). Una máquina
virtual se ejecuta sólo en procesadores dentro de su nodo
NHN Numa Home Nodes
de origen, y su memoria recientemente asignada también
proviene del nodo de origen. Una máquina virtual puede
tener varios nodos domésticos cuando el número de
CPUs virtuales excede el número de núcleos por zócalo
físico.
Numa Rebalance
NMIG
Count Delta
Numa Remote Cantidad de memoria remota asignada a la máquina
NRMEM
Memory MBytes virtual.
Numa Local Memory
NLMEM Cantidad de memoria local asignada a la máquina virtual.
MBytes

#VMwarePorvExperts 504
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Porcentaje de memoria local asignada a la máquina


virtual. Este valor debe ser cercano al 100%. Una de las
razones de la mala ubicación de NUMA puede ser que
N%L Numa % Local
una máquina virtual tiene más memoria configurada de la
que está disponible para cada procesador. El acceso a la
memoria remota provoca un aumento de la latencia.
Cantidad de memoria física asignada a una máquina
virtual. Esta es la memoria de la máquina virtual
configurada.
MEMSZ Memory Size MBytes
MEMSZ = SUBVENCIÓN + MCTLSZ + SWCUR + intacto

Presionaremos ‘M’ para ordenar por columna MEMSZ.


Cantidad de memoria física asignada a la máquina virtual.
Memory Granted Si GRANT es menor que MEMSZ, el huésped nunca
GRANT
Size MBytes ha usado toda su memoria configurada o si ha sido
recuperado por el driver de balloon.
Cantidad de memoria consumida por la máquina virtual.
La memoria que consume actualmente la máquina virtual
es igual a la cantidad de memoria que utiliza actualmente
Memory Consumed
CNSM el sistema operativo huésped de la máquina virtual,
Size MBytes
excluyendo la cantidad de memoria guardada por el uso
compartido de páginas transparentes y la compresión de
memoria.
Cantidad específica de memoria física a asignar. Es
SZTGT Target Size MBytes posible que SZTGT sea superior a MEMSZ porque incluye
la memoria superior de la máquina virtual.
La cantidad de memoria física utilizada recientemente
(lectura o escritura) por la máquina virtual. La memoria
tocada es una estimación del conjunto de trabajo, que
TCHD Touched MBytes
indica cuán activamente está utilizando la máquina virtual
su memoria. Este valor es similar a la memoria activa
reportada por el SO huésped.
Touched Write La cantidad de memoria física escrita recientemente por
TCHD_W
MBytes la máquina virtual.
Porcentaje de memoria física activa del huésped, valor
%ACTV Active Estimate
actual.
Porcentaje de memoria física activa del huésped, media
%ACTVS Active Slow Estimate
móvil lento.
Porcentaje de memoria física activa del huésped, media
%ACTVF Active Fast Estimate
móvil rápido.
Porcentaje de memoria física activa del huésped, predecir
%ACTVN Active Next Estimate
qué %ACTVF será en la próxima muestra.
El controlador de memoria de ballon está instalado o no.
MCTL? Memctl? N significa no, Y significa sí. El controlador de ballooning
forma parte de VMware Tools.

#VMwarePorvExperts 505
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Cantidad de memoria física recuperada de la máquina


virtual por medio de un globo. Para disminuir la presión
de la memoria del host, el controlador del globo se infla
dentro de la máquina virtual y hace que la memoria
física esté disponible para otras máquinas virtuales. El
MCTLSZ Memctl MBytes impacto en el rendimiento causado por el balonismo es
pequeño y, por lo tanto, preferible al intercambio. Otra
razón para volar en globo puede ser un límite de memoria
configurado (AMAX).

Pulse ‘B’ para ordenar por columna MCTLSZ.


Memctl Target Cantidad de memoria física que el sistema ESXi intenta
MCTLTGT
MBytes recuperar de la máquina virtual por medio de ballooning.
La cantidad máxima de memoria física que puede ser
MCTLMAX Memctl Max MBytes
recuperada por el driver de ballooning.
SWCUR Swapped MBytes Uso actual de swap por parte de esta máquina virtual.
Destino donde el host ESXi espera que esté el uso de
SWTGT Swap Target MBytes
swap por parte de la máquina virtual.
Swap Read MBytes/ Velocidad a la que el host ESXi intercambia la memoria
SWR/s
sec del disco por la máquina virtual.
Swap Written Velocidad a la que el host ESXi intercambia la memoria
SWW/s
MBytes/sec de la máquina virtual con el disco.
La velocidad a la que se lee la memoria de la caché del
host. Cuando la caché del host está habilitada, el host
Llswap Read
LLSWR/s ESXi puede cambiar a una unidad SSD local, en lugar del
MBytes/sec
almacén de datos de máquinas virtuales, lo que reduce
significativamente el impacto causado por el intercambio.
Velocidad a la que se escribe la memoria en la caché del
host. Cuando la caché del host está habilitada, el host
Llswap Written
LLSWW/s ESXi puede cambiar a una unidad SSD local, en lugar del
MBytes/sec
almacén de datos de máquinas virtuales, lo que reduce
significativamente el impacto causado por el intercambio.
La cantidad de datos leídos del archivo del punto de
Checkpoint Read control. Los datos de un archivo de punto de control se
CPTRD
MBytes leen cuando se reanuda una máquina virtual desde un
estado suspendido.
El tamaño del archivo del punto de control. El archivo
Checkpoint Target
CPTTGT de punto de control se utiliza cuando se suspende una
MBytes
máquina virtual.
El tamaño de las páginas físicas de la máquina virtual que
se ponen a cero. Una página cero es simplemente una
ZERO Zero MBytes
página de memoria que contiene todos los ceros que se
pueden utilizar fácilmente para compartir páginas.
Cantidad de memoria física que se comparte con el
SHRD Shared MBytes
huésped.
Shared Saved Cantidad de memoria física que se guarda debido al uso
SHRDSVD
MBytes compartido de la página.
Copy On Write Hint Cantidad de páginas de sugerencias físicas para el uso
COWH
MBytes compartido de páginas.

#VMwarePorvExperts 506
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Overhead UW Cantidad de memoria de sobrecarga reservada para la


OVHDUW
MBytes carga de trabajo del usuario vmx.
Cantidad de memoria de sobrecarga que consume
OVHD Overhead MBytes
actualmente la máquina virtual.
Overhead Max Cantidad de memoria de recargo reservada para toda la
OVHDMAX
MBytes máquina virtual.
Min Commit Target
MCMTTGT
MBytes
Commit Target
CMTTGT
MBytes
Commit Charged
CMTCHRG
MBytes
Commit Pages Per
CMTPPS
Share
Compressed Tamaño actual de la memoria comprimida por esta
CACHESZ
Memory MBytes máquina virtual.
Used Compressed
CACHEUSD Se utiliza memoria caché de compresión.
Memory MBytes
Compression
ZIP/s Memoria comprimida por segundo.
MBytes/sec
Decompression
UNZIP/s Memoria descomprimida por segundo.
MBytes/sec

Si nos vamos ahora a la vista de Disco por Máquina Virtual (v) podremos ver lo siguiente:

#VMwarePorvExperts 507
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

De nuevo, me gustaría incluir una tabla con todos los parámetros que se pueden observar en esta
vista:

Métrica Nombre Descripción


El ID de disco SCSI virtual. El ID suele estar oculto y se
ID ID muestra el ID de grupo, a menos que el grupo se amplíe
con el comando “e”. Es el mismo ID que utiliza vscsiStats.
GID Group ID El ID de grupo de la máquina virtual.
Virtual Machine El nombre para mostrar de la máquina virtual.
VMNAME
Name Pulsaremos ‘N’ para ordenar por columna VMNAME.
Nombre del dispositivo VSCSI. Sólo se muestra cuando el
VDEVNAME Virtual Device Name
grupo se amplía con el comando “e”.
Number of Virtual
NVDISK Número de dispositivos VSCSI.
Disks
CMDS/s Commands/sec Número de órdenes emitidas por segundo.
Número de comandos de lectura emitidos por segundo.
READS/s Reads/sec
Presionaremos ‘r’ para ordenar por columna READS/s.
Número de comandos de escritura emitidos por segundo.
WRITES/s Writes/sec Presionaremos ‘w’ para ordenar por columna de
ESCRITOS.
Megabytes leídos por segundo.
MBREAD/s MBytes Read/sec
Pulse ‘R’ para ordenar por columna MBREAD/s.
Megabytes escritos por segundo.
MBWRTN/s MBytes Written/sec
Pulse ‘T’ para ordenar por columna MBWRTN/s.
LAT/rd Read Latency Latencia media (en milisegundos) por lectura.
LAT/wr Write Latency Latencia media (en milisegundos) por escritura.

Si queremos monitorizar ahora los dispositivos de Storage físicos presionaremos (u) que nos mostrará:

Si nos vamos de nuevo a ver una tabla detallada de cada parámetro, encontramos lo siguiente para

#VMwarePorvExperts 508
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

ESXTOP y esta vista de los dispositivos físicos de Storage conectados a este Host de ESXi:

Métrica Nombre Descripción


DEVICE Device Nombre del dispositivo de almacenamiento.
Esta columna sólo es visible cuando se amplía con “e”
PATH/WORLD/ Path/World/Partition
para Disk World Statistics, “P” para Disk Path Statistics o
PARTITION Id
“t” para Disk Partition Statistics.
Número de rutas de acceso al dispositivo de
NPH Number of Paths
almacenamiento.
Número de mundos que se ejecutan en el dispositivo de
NWD Number of Worlds almacenamiento. Amplíe el dispositivo con el comando “e”
para mostrar estadísticas de mundos individuales.
Número de particiones en el dispositivo de
NPN Number of Partitions
almacenamiento.
Número de acciones. Sólo se muestra cuando el
SHARES Shares dispositivo se expande con el comando “e” (Disk World
Statistics).
BLKSZ Block Size (Bytes) Tamaño de bloque del dispositivo en bytes.
NUMBLKS Number of Blocks Número de bloques del dispositivo.
Profundidad de la cola de dispositivos actual del
DQLEN Device Q Depth
dispositivo de almacenamiento.
Profundidad de la cola de carga de trabajo. Este es el
número máximo de comandos activos del ESXi VMkernel
WQLEN World Q Depth que el mundo puede tener. Esto es un máximo por
dispositivo para la carga de trabajo. Sólo es válido si el
dispositivo correspondiente se amplía a cargas de trabajo.
Número de comandos en el ESXi VMkernel que están
ACTV Active Commands activos actualmente. Esta estadística se aplica sólo a los
mundos y dispositivos.
Número de comandos en el ESXi VMkernel que están
QUED Queued Commands actualmente en cola. Esta estadística se aplica sólo a las
cargas de trabajo y a los dispositivos.
Porcentaje de la profundidad de la cola utilizada por los
%USD % Used comandos activos del ESXi VMkernel. Esta estadística se
aplica sólo a los mundos y dispositivos.
Relación entre los comandos activos del ESXi VMkernel
más los comandos en cola del ESXi VMkernel y la
LOAD Load
profundidad de la cola. Esta estadística se aplica sólo a
las cargas de trabajo y dispositivos.
CMDS/s Commands/sec Número de órdenes emitidas por segundo.
READS/s Reads/sec Número de comandos de lectura emitidos por segundo.
WRITES/s Writes/sec Número de comandos de escritura emitidos por segundo.
MBREAD/s MBytes Read/sec Megabytes leídos por segundo.
MBWRTN/s MBytes Written/sec Megabytes escritos por segundo.
RESV/s Reserves/sec
CONS/s Conflicts/sec

#VMwarePorvExperts 509
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Este es el tiempo promedio de respuesta en milisegundos


Average Driver
DAVG/cmd por comando que se envía al dispositivo. El valor DAVG
MilliSec/Command
es parte de GAVG.
Average Kernel Esta es la cantidad de tiempo que el comando pasa en el
KAVG/cmd
MilliSec/Command VMkernel. El valor de KAVG es parte de GAVG.
Este es el tiempo de respuesta tal y como lo percibe el
Average Guest
GAVG/cmd sistema operativo huésped. Este número se calcula con
MilliSec/Command
la fórmula: DAVG + KAVG = GAVG
Average Queue
QAVG/cmd Latencia media de la cola por comando en milisegundos.
MilliSec/Command
Average Driver Latencia de lectura media del controlador de dispositivo
DAVG/rd
MilliSec/Read por operación de lectura en milisegundos.
Average Kernel Promedio de latencia de lectura de ESXi VMkernel por
KAVG/rd
MilliSec/Read operación de lectura en milisegundos.
Average Guest Latencia de lectura media del sistema operativo huésped
GAVG/rd
MilliSec/Read por operación de lectura en milisegundos.
Average Queue Latencia media de lectura de la cola por operación de
QAVG/rd
MilliSec/Read lectura en milisegundos.
Average Driver Latencia de escritura media del dispositivo por operación
DAVG/wr
MilliSec/Write de escritura en milisegundos.
Average Kernel Latencia de escritura media de ESXi VMkernel por
KAVG/wr
MilliSec/Write operación de escritura en milisegundos.
Average Guest Latencia de escritura promedio del sistema operativo
GAVG/wr
MilliSec/Write huésped por operación de escritura en milisegundos.
Average Queue Latencia media de escritura en cola por operación de
QAVG/wr
MilliSec/Write escritura en milisegundos.
Failed Commands/
FCMDS/s
sec
FREAD/s Failed Reads/sec
FWRITE/s Failed Writes/sec
Failed Bytes Read/
FMBRD/s
sec
Failed Bytes Written/
FMBWR/s
sec
FRESV/s Failed Reserves/sec
ABRTS/s Aborts/sec Número de comandos abortados por segundo.
RESETS/s Resets/sec Número de comandos reseteados por segundo.
Número de comandos PAE por segundo. Esta estadística
PAECMD/s PAE Commands/sec
se aplica sólo a las rutas.
Número de copias PAE por segundo. Esta estadística se
PAECP/s PAE Copies/sec
aplica sólo a las rutas.
Número de comandos de división por segundo. Esta
SPLTCMD/s Split Commands/sec
estadística se aplica sólo a las rutas.
Número de copias divididas por segundo. Esta estadística
SPLTCP/s Split Copies/sec
se aplica sólo a las rutas.
CLONE_RD VAAI Clone Reads
CLONE_WR VAAI Clone Writes

#VMwarePorvExperts 510
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

CLONE_F VAAI Clone Failed


MBytes Clone
MBC_RD/s
Reads/sec
MBytes Clone
MBC_WR/s
Writes/sec
ATS Atomic Test and Set
Atomic Test and Set
ATSF
Failed
ZERO Zeros
ZERO_F Zeros Failed
MBZERO/s MBytes Zeroed/sec
DELETE Delete
DELETE_F Delete Failed
MBDEL/s Mbytes Delete/sec
Average Success
CAVG/suc
Latency ms/Clone
Average Failure
CAVG/f
Latency ms/Clone
Average Success
AAVG/suc
Latency ms/ATS
Average Failure
AAVG/f
Latency ms/ATS
Average Success
ZAVG/suc
Latency ms/Zero
Average Failure
ZAVG/f
Latency ms/Zero

Para conocer el estado en tiempo real de las controladoras de disco virtuales, usaremos la tecla (d),
no os voy a mostrar una tabla con lo que significa cada parámetro ya que la vista es bastante básica:

Sin embargo, si hablamos de Networking, tecla (n), esta sería la vista con Switches Virtuales Distribuidos:

#VMwarePorvExperts 511
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Vamos a conocer que significa cada parámetro que tenemos en pantalla para esta vista de ESXTOP:

Métrica Nombre Descripción


El ID de puerto utilizado en el conmutador virtual. Este ID
PORT-ID Port ID se utiliza, por ejemplo, para trazas de red con pktcap-uw.

Pulsaremos ‘N’ para ordenar por columna PORT-ID.


Este puerto de switch virtual es un puerto de enlace
UPLINK Uplink?
ascendente físico. N significa no, Y significa sí.
Y significa que el enlace correspondiente está arriba. N
UP Link Up? significa que no lo es. Sólo visible para los puertos de
enlace ascendente.
Velocidad de enlace en Megabits por segundo. Sólo
SPEED Link Speed (Mb/s)
visible para los puertos de enlace ascendente.
Y significa que el enlace correspondiente está operando
FDUPLX Full Duplex? en dúplex completo. N significa que no lo es. Sólo visible
para los puertos de enlace ascendente.
Indica lo que está conectado al puerto de switch virtual.
Los dispositivos conectados pueden ser NICs de
USED-BY Used By máquinas virtuales, puertos VMkernel (vmk#), NICs
físicas (vmnic#) o puertos utilizados para comprobaciones
de estado (Shadow of vmnic#).
El NIC físico que el dispositivo correspondiente está
Team Uplink Physical
TEAM-PNIC utilizando activamente. Esta información es útil para la
NIC Name
resolución de problemas de red.
Nombre del switch virtual. El nombre para mostrar para
DNAME Device Name los switches virtuales o DvsPortset-# para switches
distribuidos.
Packets Transmitted/ Número de paquetes transmitidos por segundo.
PKTTX/s
sec Pulsaremos ‘t’ para ordenar por columna PKTTX/s.
MBits Transmitted/ MegaBits transmitidos por segundo.
MbTX/s
sec Pulsaremos ‘T’ para ordenar por columna MbTX/s.
Average Packet Size
PSZTX Tamaño medio de los paquetes transmitidos en bytes.
Transmitted (Bytes)

#VMwarePorvExperts 512
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Packets Received/ Número de paquetes recibidos por segundo.


PKTRX/s
sec Presionaremos ‘r’ para ordenar por columna PKTRX/s.
MegaBits recibidos por segundo.
MbRX/s MBits Received/sec
Pulsaremos ‘R’ para ordenar por columna MbRX/s.
Average Packet Size
PSZRX Tamaño medio de los paquetes recibidos en bytes.
Received (Bytes)
% Outbound Packets
%DRPTX Porcentaje de paquetes de transmisión perdidos.
Dropped
% Received Packets
%DRPRX Porcentaje de paquetes de recepción eliminados.
Dropped
Número de acciones de Vmkernel publicadas por
ACTN/s Actions Posted/sec segundo. Se trata de un contador interno de VMware sin
más documentación.
Multicast Packets
PKTTXMUL/s Número de paquetes multicast transmitidos por segundo.
Transmitted/sec
Multicast Packets
PKTRXMUL/s Número de paquetes multicast recibidos por segundo.
Received/sec
Broadcast Packets Número de paquetes de difusión transmitidos por
PKTTXBRD/s
Transmitted/sec segundo.
Broadcast Packets
PKTRXBRD/s Número de paquetes de difusión recibidos por segundo.
Received/sec

Si quisiéramos modificar cualquiera de las vistas que hemos analizado, y reducir por ejemplo el número
de campos que queremos mostrar, para facilitarnos el troubleshooting, presionaremos la tecla (f), por
ejemplo, en la vista de CPU he dejado solamente la columna A, D, F, H e I:

Y esto nos muestra la siguiente información, mucho más detallada para lo que yo ando buscando:

#VMwarePorvExperts 513
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Podríamos guardar esta “vista personalizada” con la tecla (W, sí en mayúsculas) y ponerle un nombre
por ejemplo, mivistadecpu:

Para lanzar esta vista en el futuro, tan sencillo como lanzar el comando de ESXTOP de la siguiente
manera:

esxtop –c mivistadecpu

En caso de qué necesitáramos exportar esta información tan valiosa en un fichero .csv para poder ser
analizado en otra herramienta, o en un simple Excel, podríamos conseguirlo de la siguiente manera:

esxtop –b –n 10 > miinformacionimportantedeesxi.csv

Os cuento un poco lo que acabo de hacer, he usado el modo batch de esxtop con el atributo -b.
Además he incluido el atributo -n que lo que hace es tomar la información de 10 tomas en el tiempo,
que por defecto son cada 5 segundos, con lo que he tomado la información de la vista de CPU, la
que viene por defecto, durante 50 segundos de mi ESXi, además como he puesto luego el símbolo de
mayor significa que la información se me guarde en un fichero con el nombre que deseo.

#VMwarePorvExperts 514
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

3. Monitorizando nuestro entorno vSphere usando SNMP

SNMP o Simple Network Management Protocol es un estándar de la Industria para monitorizar y


controlar ciertos aspectos de elementos de nuestro Datacenter.

SNMP se usa ampliamente para la monitorización de redes. SNMP expone los datos de gestión en
forma de variables sobre los sistemas gestionados organizados en una base de información de gestión
(MIB) que describe el estado y la configuración del sistema. Estas variables pueden ser consultadas
remotamente (y, en algunas circunstancias, manipuladas) mediante la gestión de aplicaciones.

Si tuviéramos que dibujar SNMP quedaría de la siguiente manera:

SNMP está muy extendido, pero no por ello es un protocolo sencillo ni mucho menos seguro si lo
desplegamos utilizando SNMPv1 (estandarizado en 1988). Hay algunas buenas prácticas que tenemos
que seguir, por ejemplo y siendo breve:

• Abstenerse de usar Comunidades llamadas public o nombres de empresa

• Utilizar siempre que sea posible una red aislada para el tráfico UDP 161 para SNMP

• Utilizar autenticación gracias a SNMPv3 siempre que sea posible (aumenta el nivel de complejidad
a la hora de configuración)

• Utilizar cifrado en SNMP gracias a SNMPv3

El Departamento de Ciber Seguridad de los Estados Unidos recomienda únicamente el uso de SNMPv3
en su web oficial - https://www.us-cert.gov/ncas/alerts/TA17-156A

#VMwarePorvExperts 515
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

3.1 Monitorizando nuestro vCenter Server usando SNMP

Una vez que hemos dado un vistazo rápido a SNMP, es el momento de habilitar SNMP v3 en nuestro
vCenter, en mi caso estoy usando VCSA, ya que vCenter para Windows va a dejar de tener soporte
muy pronto.

Nos conectaremos a la Shell de VCSA por SSH, tendremos que tener algo similar a lo siguiente:

VMware vCenter Server Appliance 6.7.0.20100

Type: vCenter Server with an embedded Platform Services Controller

Connected to service

* List APIs: “help api list”

* List Plugins: “help pi list”

* Launch BASH: “shell”

Command>

El primero paso es crear un SNMP ID, para ello tendrá que ser una línea de entre 5 y 32 caracteres
hexadecimal, si queréis generar una aleatoria podéis hacerlo en esta web - https://www.browserling.
com/tools/random-hex En caso de que no introduzcamos nada, a la hora de habilitar el servicio se
generará un ID aleatorio, en este caso quiero introducir el mío propio, con lo que:

Command> snmp.set --engineid 5e19bed515e0023931b2528ab614580d

Si quisiera ver el resultado del comando, podría lanzar el siguiente comando que nos mostrará lo que
hemos introducido:

Command> snmp.get
Config:
Syslocation: ‘’
Pid: n/a
Port: 161
Communities: public
Authentication: none
Engineid: 5e19bed515e0023931b2528ab614580d
Remoteusers:
Targets:
Processlist: False
Enable: True
Privacy: none
Syscontact: ‘’
Loglevel: warning
Notraps: ‘’
V3targets:
Users:

#VMwarePorvExperts 516
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Vamos a configurar ahora los protocolos de autenticación y la privacidad, estos dos protocolos harán
que el servicio de SNMP sea más seguro y sigamos las recomendaciones de seguridad Internacionales.

Comenzaremos con la autenticación, podemos configurarla en none, MD5 o SHA1 de la siguiente


manera, donde protocol tendrá que ser reemplazado por vuestra preferencia:

Command> snmp.set --authentication protocol

Posteriormente configuraremos la privacidad, que nos permite seleccionar entre none y AES128, con
lo que el comando quedaría de la siguiente manera, donde protocol es vuestra preferencia:

Command> snmp.set --privacy protocol

Ahora que tenemos ya configurado la privacidad y la autenticación podemos empezar a crear usuarios,
un usuario, para crear un usuario vamos a necesitar el nombre de usuario, no mayor de 32 caracteres,
y un hash de autenticación y otro de privacidad, vamos a generar estos últimos con un comando de
manera muy sencilla, ejecutaremos el siguiente comando, cambiando el VMware2019@ por vuestra
propia palabra secreta:

Command> snmp.hash --auth_hash VMware2019@ --priv_hash VMware2019@ --raw_secret true

Este comando os dará un output similar a este, pero con vuestras claves privadas para auth y privacidad:

Hash:

Priv_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec

Auth_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec

Es ahora cuando podemos crear un usuario, el comando es algo complejo con lo que os dejo una tabla
antes de crearlo:

Parámetro Descripción
userid Reemplazar con vuestro username.
authhash Reemplazar con el valor hash de autenticación.
privhash Reemplazar con el valor hash de privacidad.
Reemplazar con el nivel de seguridad para este usuario, que puede ser auth, para
security autenticarnos únicamente, priv, para autenticación y privacidad, o none, para que
no haya ni autenticación ni privacidad.

Con lo que el comando quedaría de la siguiente manera, tendríais que introducir vuestros propios
hashes y el nivel de seguridad que deseáis:

Command> snmp.set --users userid/authhash/privhash/security

#VMwarePorvExperts 517
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Ya tendríamos casi todo configurado, en el caso de que queramos enviar Traps adicionalmente, el
comando a ejecutar sería el siguiente:

Command> snmp.set --v3targets hostname@port/userid/secLevel/trap

Os dejo una tabla de ayuda para comprender cada parámetro:

Parámetro Descripción
Reemplazar con el hostname o IP del sistema de monitorización que recibe las
hostname
traps.
Reemplazar con el puerto por el que el sistema de monitorización escucha. Si no
port
ponemos ninguno se usará el puerto por defecto, 161.
userid Reemplazar con el nombre de usuario
Reemplazar con none, auth, o priv para indicar el nivel de autenticación y
privacidad que deseamos para el usuario. Usaremos auth si hemos configurado
secLevel
únicamente la autenticación, priv si hemos configurado autenticación y privacidad,
y none si no hemos configurado ninguno.

Por último, arrancaremos el servicio de SNMP lanzando el siguiente comando:

Command> snmp.enable

Y comprobaremos el estado y configuración con un snmp.get:

#VMwarePorvExperts 518
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Command> snmp.get
Config:
Syslocation: ‘’
Pid: 54278
Port: 161
Communities: public
Authentication: SHA1
Engineid: 5e19bed515e0023931b2528ab614580d
Remoteusers:
Targets:
Processlist: False
Enable: True
Privacy: AES128
Syscontact: ‘’
Loglevel: warning
Notraps: ‘’
V3targets:
1:
Ip: 192.168.1.15
Sec_level: priv
User: snmpuser
Type: trap
Port: 161
Users:
1:
Sec_level: priv
Auth_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Priv_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Username: snmpuser

Como buena práctica, tendríamos que irnos ahora al siguiente enlace https://kb.vmware.com/s/
article/1013445 y descargar el fichero llamado 1013445_VMware-mibs-6.7.0-10201460.zip, que
incluye las últimas MIB más actualizadas, en concreto tendremos que importar las siguientes MIB para
que podamos monitorizar VCSA de manera satisfactoria:

a. VMWARE-ROOT-MIB.mib

b. VMWARE-TC-MIB.mib

c. VMWARE-PRODUCTS-MIB.mib

Si queremos lanzar un snmpwalk desde un nodo que tenga el paquete instalado, podríamos hacerlo de
la siguiente manera, de esta manera podremos comprobar que nuestro SNMP está bien configurado:

snmpwalk -v3 -l authPriv -u userid -a SHA -A “PASSWORD1” -x AES -X “PASSWORD1” VCSAHOSTNAME

Si todo está bien configurado podremos ver una respuesta similar a este output:

#VMwarePorvExperts 519
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

SNMPv2-MIB::sysDescr.0 = STRING: VMware-vCenter-Server-Appliance 6.7.0 build-11338799


VMware, Inc x86_64
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.6876.4.7
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (7840447) 21:46:44.47
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: vcsa.zimbra.io
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (1) 0:00:00.01
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.3 = OID: IP-MIB::ip

Ya tendríamos nuestro SNMP listo para ser monitorizado por herramientas de terceros.

Para que os hagáis una idea, así quedaría si usáramos por ejemplo PRTG, una herramienta comercial
con versión gratuita de hasta 100 sensores, así se verían los sensores:

Y así se vería un mapa que podemos crear para ver todo de forma mucho más clara:

#VMwarePorvExperts 520
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

3.2 Monitorizando nuestros Hosts de ESXi usando SNMP

Llega el turno de configurar SNMPv3 en nuestros Hosts de ESXi, recordemos que SNMPv3 es la
opción segura y recomendad de configurar SNMP, y desde aquí os desaconsejo el uso de SNMPv1 o
v2c, vamos con el paso a paso.

El primer paso es configurar ESXi SNMPv3 con el engine id, para ello podemos hacer uso de la
siguiente página para generar uno aleatorio - https://www.browserling.com/tools/random-hex en este
caso:

esxcli system snmp set --engineid 0293a84c7118760f815e9b08fd75fceb

Vamos a continuar con la autenticación y privacidad de SNMPv3, estos dos protocolos harán que el
servicio de SNMP sea más seguro y sigamos las recomendaciones de seguridad Internacionales.

Comenzaremos con la autenticación, podemos configurarla en none, MD5 o SHA1 de la siguiente


manera, donde protocol tendrá que ser reemplazado por vuestra preferencia:

esxcli system snmp set --authentication protocol

Posteriormente configuraremos la privacidad, que nos permite seleccionar entre none y AES128, con
lo que el comando quedaría de la siguiente manera, donde protocol es vuestra preferencia:

esxcli system snmp set --privacy protocol

Ahora que tenemos ya configurado la privacidad y la autenticación podemos empezar a crear usuarios,
un usuario, para crear un usuario vamos a necesitar el nombre de usuario, no mayor de 32 caracteres,
y un hash de autenticación y otro de privacidad, vamos a generar estos últimos con un comando de
manera muy sencilla, ejecutaremos el siguiente comando, cambiando el VMware2019 por vuestra
propia palabra secreta:

esxcli system snmp hash --auth-hash VMware2019 --priv-hash VMware2019 --raw-secret

Este comando os dará un output similar a este, pero con vuestras claves privadas para auth y privacidad:

Authhash: 3516d465f81e5c08421cb50bd5cc8977

Privhash: 3516d465f81e5c08421cb50bd5cc8977

Es ahora cuando podemos crear un usuario, el comando es algo complejo con lo que os dejo una tabla
antes de crearlo:

Parámetro Descripción
userid Reemplazar con vuestro username.

#VMwarePorvExperts 521
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

authhash Reemplazar con el valor hash de autenticación.


privhash Reemplazar con el valor hash de privacidad.
Reemplazar con el nivel de seguridad para este usuario, que puede ser auth,
security para autenticarnos únicamente, priv, para autenticación y privacidad, o none,
para que no haya ni autenticación ni privacidad.

Con lo que el comando quedaría de la siguiente manera, tendríais que introducir vuestros propios
hashes y el nivel de seguridad que deseáis:

esxcli system snmp set --users userid/authhash/privhash/security

Ya tendríamos casi todo configurado, en el caso de que queramos enviar Traps adicionalmente, el
comando a ejecutar sería el siguiente:

esxcli system snmp set --v3targets hostname@port/userid/secLevel/message-type

Os dejo una tabla de ayuda para comprender cada parámetro:

Parámetro Descripción
Reemplazar con el hostname o IP del sistema de
hostname
monitorización que recibe las traps.
Reemplazar con el puerto por el que el sistema
port de monitorización escucha. Si no ponemos
ninguno se usará el puerto por defecto, 161.
userid Reemplazar con el nombre de usuario
Reemplazar con none, auth, o priv para
indicar el nivel de autenticación y privacidad que
deseamos para el usuario. Usaremos auth si
secLevel hemos configurado únicamente la autenticación,
priv si hemos configurado autenticación y
privacidad, y none si no hemos configurado
ninguno.
message-type Reempazar con trap or inform.

Por último, arrancaremos el servicio de SNMP lanzando el siguiente comando:

esxcli system snmp set --enable true

Podríamos comprobar que la configuración de SNMP, por la parte de traps, está bien configurada
lanzando el siguiente comando, que nos devolvería lo siguiente:

esxcli system snmp test

Comments: There is 1 target configured, send warmStart requested, test completed normally.

#VMwarePorvExperts 522
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Y comprobaremos el estado y configuración con un esxcli system snmp get:

esxcli system snmp get


Authentication: MD5
Communities: public
Enable: true
Engineid: 0293a84c7118760f815e9b08fd75fceb
Hwsrc: indications
Largestorage: true
Loglevel: info
Notraps:
Port: 161
Privacy: AES128
Remoteusers:
Syscontact:
Syslocation:
Targets:
Users: snmpuser/3516d465f81e5c08421cb50bd5cc8977/3516d465f81e5c08421cb50bd5cc8977/priv
V3targets: 192.168.1.15@161 snmpuser priv trap

Como buena práctica, tendríamos que irnos ahora al siguiente enlace https://kb.vmware.com/s/
article/1013445 y descargar el fichero llamado 1013445_VMware-mibs-6.7.0-10201460.zip, que
incluye las últimas MIB más actualizadas, en concreto tendremos que importar las siguientes MIB para
que podamos monitorizar VCSA de manera satisfactoria:

a. VMWARE-ROOT-MIB.mib

b. VMWARE-TC-MIB.mib

c. VMWARE-PRODUCTS-MIB.mib

Si queremos lanzar un snmpwalk desde un nodo que tenga el paquete instalado, podríamos hacerlo de
la siguiente manera, de esta manera podremos comprobar que nuestro SNMP está bien configurado:

snmpwalk -v3 -l authPriv -u userid -a SHA -A “PASSWORD1” -x AES -X “PASSWORD1” ESXIHOSTNAME

Si todo está bien configurado podremos ver una respuesta similar a este output:

SNMPv2-MIB::sysDescr.0 = STRING: VMware ESXi 6.7.0 build-10302608 VMware, Inc. x86_64


SNMPv2-MIB::sysObjectID.0 = OID: VMWARE-PRODUCTS-MIB::vmwESX
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (402700) 1:07:07.00
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: esxi-zlon-002

A partir de aquí, ya solamente nos queda usar nuestra aplicación de monitorización de SNMP.

#VMwarePorvExperts 523
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

4. Monitorizando nuestro entorno de vSphere usando


herramientas open source

Una vez que hemos visto en detalle cómo habilitar y testear nuestros diferentes componentes de
VMware, he querido dedicar este último capítulo de la sección sobre monitorización al open source.
Es cierto que hay muchas soluciones open source que monitorizan VMware, tales como el ya longevo
Nagios, o soluciones open con parte comercial como son Centreon por poner un ejemplo rápido, pero
en este libro no voy a extenderme sobre el uso y administración de dichas herramientas.

Podemos encontrar en Internet y en Castellano mucho material al respecto sobre las mencionadas
tecnologías open source y VMware.

En esta sección he querido ir un paso más allá y abstraer la complejidad de entornos de monitorización
al uso, gracias a un simple grupo de aplicaciones y servicios open source que se despliegan en apenas
unos segundos, y que nos ofrecerán una visibilidad de nuestro entorno de VMware mediante elegantes
y personalizables Dashboards.

4.1 InfluxDB, Telegraf y Grafana

En este capítulo vamos a ver cómo podemos crear bellos y funcionales Dashboards para poder colgar
en nuestras pantallas donde los técnicos pueden comprobar de un simple vistazo el estado general de
la Infraestructura vSphere.

Antes de sumergirnos de lleno con el despliegue de estos tres servicios, quiero dejaros un breve
diagrama de los diferentes componentes que vamos a desplegar en una simple VM (estos servicios
pueden escalar para monitorizar varios cientos de miles de VMs, pero para comenzar con una VM todo
en uno es suficiente).

Como podemos ver tenemos diferentes actores principales en cada uno de los rectángulos de colores:

• Telegraf: Se trata del servicio que ejerce de agente recolectando todo tipo de métricas de diferentes

#VMwarePorvExperts 524
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

orígenes, tales como pueden ser: Scripts, Estadísticas de estado, Networking, logs, o en nuestro
caso recolecta información directamente de nuestro vSphere SDK.

• InfluxDB: La Base de datos que almacena los cientos de miles de eventos de cada componente
de vSphere, además de las métricas de vSphere; InfluxDB puede almacenar cualquier otra serie
con datos en específicos rangos de tiempo.

• Grafana: Una solución open source para la creación de Dashboards que soporta múltiples
orígenes de datos, uno de ellos es InfluxDB, con el que tiene una integración muy completa. Con
lo que Grafana mostrará las estadísticas y contadores que seleccionemos en el rango de tiempo
especificado.

Estas tres soluciones pueden expandirse mucho más para cubrir prácticamente cualquier necesidad
dentro de nuestro Datacenter, pero en este libro nos vamos a enfocar en la visualización de entornos
vSphere con ellas.

4.1.1 Instalación y configuración de InfluxDB, Telegraf y Grafana


Para el laboratorio, vamos a usar Ubuntu Server 16.04, pero estos pasos se pueden seguir con
cualquier otra distribución Linux, buscar por los instalables en la web oficial de cada proyecto.

Estos son los recursos Hardware que recomiendo para un entorno de entre 1 a 25 Hosts ESXi,
almacenando métricas de unas 300VMs por un periodo de unos doce meses.

Recursos Cantidad
vCPU 4
RAM 8GB RAM
Disco 150GB (SAS o SSD)
Networking VMXNET3
Controladora PVSCSI

4.1.1.1 Instalación paso a paso de InfluxDB

Vamos a comenzar con la instalación de InfluxDB, la base de datos donde almacenaremos todas las
estadísticas, para ello vamos a comenzar añadiendo el repositorio necesario para los paquetes de
InfluxDB y Telegraf:

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add –

source /etc/lsb-release

echo “deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable” | sudo


tee /etc/apt/sources.list.d/influxdb.list

Una vez que hemos añadido el repositorio, tendremos que actualizar los paquetes de la siguiente
manera:

sudo apt-get update

#VMwarePorvExperts 525
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Con los paquetes ya actualizados, podremos proceder a la instalación de InfluxDB; lanzando el


siguiente comando:

sudo apt-get install influxdb

Procederemos a ejecutar el servicio de la siguiente manera:

sudo systemctl start influxdb

Este comando nos mostrará un mensaje similar a este:

influxdb.service - InfluxDB is an open-source, distributed, time series database

Loaded: loaded (/lib/systemd/system/influxdb.service; enabled; vendor preset: enabled)

Active: active (running) since Tue 2018-12-12 13:10:33 CST; 05s ago

Docs: https://docs.influxdata.com/influxdb/

Main PID: 1718 (influxd)

CGroup: /system.slice/influxdb.service

└─1718 /usr/bin/influxd -config /etc/influxdb/influxdb.conf

Vamos a crear ahora un usuario para administrar InfluxDB, en este caso le he llamado admin, pero
podemos seleccionar el nombre y password que deseemos, entraremos en la aplicación de InfluxDB
lanzando este comando:

influx

Y ejecutaremos este comando cambiando los datos por los vuestros:

CREATE USER “admin” WITH PASSWORD ‘adminvmware2019’ WITH ALL PRIVILEGES

Si lanzamos ahora el siguiente comando podremos ver los usuarios que tenemos:

show users

Output

user admin

---- -----

admin true

#VMwarePorvExperts 526
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Saldremos ahora de la aplicación de InfluxDB con un simple exit:

exit

Y editaremos el fichero de configuración de InfluxDB para habilitar la autenticación HTTP, de la siguiente


manera:

sudo nano /etc/influxdb/influxdb.conf

Haremos scroll hasta que encontremos la sección [http] y donde pone auth-enabled, cambiaremos su
valor por true:

...

[http]

# Determines whether HTTP endpoint is enabled.

# enabled = true

# The bind address used by the HTTP service.

# bind-address = “:8086”

# Determines whether HTTP authentication is enabled.

auth-enabled = true

...

Saldremos y guardaremos los cambios y reiniciaremos el servicio de InfluxDB:

sudo systemctl restart influxdb

4.1.1.2 Instalación paso a paso de Telegraf

Vamos a seguir ahora con la instalación de Telegraf, recordemos el agente que se encarga de recoger
las métricas de diferentes lugares, usando scripts, o en nuestro caso para VMware comunicándose
directamente con el SDK de vSphere, como ya tenemos el repositorio oficial, será tan sencillo como
lanzar la instalación:f

sudo apt-get install telegraf

El servicio se ejecuta de manera automática, con lo que no tenemos que realizar ninguna acción
adicional, ahora tendremos que configurar Telegraf para que pueda mandar la información que recolecta
a nuestra base de datos de InfluxDB, para ello editaremos el fichero de configuración de Telegraf:

sudo nano /etc/telegraf/telegraf.conf

#VMwarePorvExperts 527
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Buscaremos la sección llamada [[outputs.influxdb]] e introduciremos nuestra URL, puede ser localhost
si estamos instalando todo en uno, y muy importante es que seleccionaremos el username y password
que hemos creado anteriormente al instalar InfluxDB:

[[outputs.influxdb]]

## The full HTTP or UDP endpoint URL for your InfluxDB instance.

## Multiple urls can be specified as part of the same cluster,

## this means that only ONE of the urls will be written to each interval.

# urls = [“udp://localhost:8089”] # UDP endpoint example

urls = [“http://localhost:8086”] # required

## The target database for metrics (telegraf will create it if not exists).

database = “telegraf” # required

...

## Write timeout (for the InfluxDB client), formatted as a string.

## If not provided, will default to 5s. 0s means no timeout (not recommended).

timeout = “5s”

username = “admin”

password = “adminvmware2019”

## Set the user agent for HTTP POSTs (can be useful for log differentiation)

# user_agent = “telegraf”

## Set UDP payload size, defaults to InfluxDB UDP Client default (512 bytes)

# udp_payload = 512

Reiniciaremos el servicio de Telegraf con el siguiente comando, para que se incluyan los cambios:

sudo systemctl restart telegraf

Si queremos comprobar el estado del servicio lanzaremos el siguiente comando

systemctl status telegraf

Que nos debería de mostrar un output similar a este:

#VMwarePorvExperts 528
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

telegraf.service - The plugin-driven server agent for reporting metrics into InfluxDB

Loaded: loaded (/lib/systemd/system/telegraf.service; enabled; vendor preset:


enabled)

Active: active (running) since Tue 2017-03-14 15:24:41 CST; 1min 26s ago

Docs: https://github.com/influxdata/telegraf

Main PID: 1752 (telegraf)

CGroup: /system.slice/telegraf.service

└─1752 /usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory


/etc/telegraf/telegraf.d

4.1.1.3 Instalación paso a paso de Grafana

Es el turno de proceder a la instalación de Grafana para comenzar a mostrar información básica,


para ello tendremos que añadir el repositorio de Grafana a nuestro sistema operativo de la siguiente
manera:

curl https://packages.grafana.com/gpg.key | sudo apt-key add -

Actualizaremos nuestros paquetes y lanzaremos la instalación de Grafana con los siguientes comandos:

sudo apt-get update

sudo apt-get install grafana

Para hacer que el servicio de Grafana se ejecute con cada inicio del sistema operativo lanzaremos el
siguiente comando:

sudo update-rc.d grafana-server defaults

Procederemos a arrancar el servicio con el siguiente comando:

systemctl start grafana-server

Para comprobar el estado del servicio lanzaremos el status, como hemos hecho anteriormente para
los otros servicios:

systemctl status grafana-server

Que nos mostrará un output similar a este:

#VMwarePorvExperts 529
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

grafana-server.service - Grafana instance

Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor


preset: enabled)

Active: active (running) since Wed 2018-12-19 00:39:00 GMT; 2 months 5 days ago

Docs: http://docs.grafana.org

Main PID: 9769 (grafana-server)

CGroup: /system.slice/grafana-server.service

9769 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/


run/grafana/grafana-server.pid --packaging=deb cfg:default.paths.logs=/var/log

¡Ya tenemos todo listo! Nos iremos a nuestro navegador favorito e introduciremos la siguiente URL
http://IPDELSERVER:3000 esto nos llevará a la página de login de Grafana, el usuario y password por
defecto es admin/admin:

Nada más hacer login tendremos que añadir un Datasource para que Grafana pueda mostrarnos datos
de una base de datos, en nuestro caso recordemos que usamos InfluxDB:

#VMwarePorvExperts 530
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Aunque seleccionaremos InfluxDB, podemos ver el potencial de la herramienta pudiendo añadir una
infinidad de Datasources a Grafana, como he comentado, seleccionaremos InfluxDB ahora:

La configuración es muy sencilla, tendremos que prestar atención solamente a un par de parámetros
tales como la URL, localhost en mi caso, y por supuesto las credenciales de InfluxDB:

Si todo ha ido bien podremos presionar el botón de Save & Test que nos mostrará algo similar a este
mensaje en caso de que todo funcione como es debido:

#VMwarePorvExperts 531
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Por defecto Telegraf recoge información del servidor donde se ha instalado, esto quiere decir que
tendremos datos del estado y consumo de la CPU, RAM, Disco y Networking de esta VM donde
estamos instalando Telegraf, InfluxDB y Grafana, para tomar contacto con el sistema de Dashboarding,
vamos a crear un nuevo Dashboard, de tipo Graph:

Sobre Panel Title, haremos click y seleccionaremos Edit:

Esto nos mostrará la configuración de esta gráfica que queremos mostrar, os dejo la manera tan
sencilla que tenemos para hacer una selección del consumo de la CPU, por ejemplo:

#VMwarePorvExperts 532
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

En la imagen vemos que he seleccionado la métrica CPU, del host que es la VM donde hemos
instalado todo este stack, he seleccionado el campo usage_system, y le he dado un poco de formato
ordenándolo por vCPU, y cambiando el resultado que se muestra como %. Como esta gráfica podemos
generar RAM, Disco, Networking y demás, hay varios tutoriales en Internet sobre ello, y en este libro
no hablaremos más en detalle sobre Grafana, vamos ahora a ver cómo importar los Dashboards y
monitorizar VMware.

4.2 Configuración de Telegraf para monitorización de vSphere

La monitorización de entornos de vSphere usando el SDK de VMware está disponible de manera


nativa en Telegraf desde su versión 1.8, anunciada en septiembre de 2018. Esto nos abre las puertas
de una monitorización mucho más detallada y de manera nativa para Telegraf, ¡fantástico!

Para configurar Telegraf para que recolecte información de nuestros vSphere, editaremos el fichero de
configuración de Telegraf:

/etc/telegraf/telegraf.conf

Buscaremos la sección llamada [[inputs.vsphere]] y en ella introduciremos el FQDN, usuario y


contraseña con privilegios de nuestro vCenter:

[[inputs.vsphere]]

## List of vCenter URLs to be monitored. These three lines must be uncommented

## and edited for the plugin to work.

vcenters = [ “https://NUESTROVCSAFQDN/sdk” ]

username = “YOURUSER@vsphere.local”

password = “YOURPASS”

Además, vamos a tener que eliminar el estado de comentario al resto de parámetros, por ejemplo, si
queremos monitorizar todos los parámetros os quedaría así:

#VMwarePorvExperts 533
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

## VMs

## Typical VM metrics (if omitted or empty, all metrics are collected)

vm_metric_include = []

# vm_metric_exclude = [] ## Nothing is excluded by default

# vm_instances = true ## true by default

## Hosts

## Typical host metrics (if omitted or empty, all metrics are collected)

host_metric_include = []

# host_metric_exclude = [] ## Nothing excluded by default

# host_instances = true ## true by default

## Clusters

cluster_metric_include = [] ## if omitted or empty, all metrics are collected

# cluster_metric_exclude = [] ## Nothing excluded by default

# cluster_instances = true ## true by default

## Datastores

datastore_metric_include = [] ## if omitted or empty, all metrics are collected

# datastore_metric_exclude = [] ## Nothing excluded by default

# datastore_instances = false ## false by default for Datastores only

## Datacenters

datacenter_metric_include = [] ## if omitted or empty, all metrics are collected

datacenter_metric_exclude = [ “*” ] ## Datacenters are not collected by default.

datacenter_instances = false ## false by default for Datastores only

Además, en caso de que no estemos usando un SSL válido y comercial en nuestro entorno, lo más
sencillo es editar lo siguiente para que acepte certificados SSL auto-firmados y poner true:

insecure_skip_verify = true

Una vez que hemos hecho estos cambios, reiniciaremos nuestro servicio de Telegraf usando:

sudo systemctl restart telegraf

#VMwarePorvExperts 534
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Si quisiéramos ojear de manera rápida si ya estamos recogiendo datos de vSphere, podríamos


directamente realizar estas consultas a la base de datos, donde podremos ver que tenemos ya tablas
llamadas vsphere_*:

influx

> use telegraf

Using database Telegraf

> show measurements

name: measurements

name

----

vsphere_cluster_clusterServices

vsphere_cluster_cpu

vsphere_cluster_mem

vsphere_cluster_vmop

vsphere_datacenter_vmop

vsphere_datastore_datastore

vsphere_datastore_disk

vsphere_host_cpu

vsphere_host_disk

vsphere_host_mem

vsphere_host_net

vsphere_host_power

vsphere_host_storageAdapter

vsphere_host_sys

vsphere_vm_cpu

vsphere_vm_mem

vsphere_vm_net

vsphere_vm_power

vsphere_vm_sys

vsphere_vm_virtualDisk

Esto significa que Telegraf ya está recibiendo correctamente información desde nuestro vSphere hacía
Telegraf y de ahí se está almacenando en nuestra base de datos InfluxDB.

#VMwarePorvExperts 535
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

4.3 Importar Dashboards ya listos en Grafana para monitorización de


vSphere

Ahora que tenemos información en nuestro InfluxDB, llega la hora de visualizarla, hemos realizado un
vistazo rápido a Grafana y sus gráficas en la sección anterior, ahora vamos a importar una serie de
Dashboards que he creado, y que ya traen todo el trabajo complicado de crear las gráficas y dejarlas
bonitas, hecho. He creado cuatro Dashboards y vamos a ver cómo importar todos ellos.

En Grafana, una vez hecho login y todo, nos iremos hasta el menú de la izquierda, pulsaremos el + y
seleccionaremos Import:

Podemos introducir el ID de cada Dashboard o la URL, os dejo aquí los datos:

• VMware vSphere – Overview – 8159 - https://grafana.com/dashboards/8159

• VMware vSphere – Datastore – 8162 - https://grafana.com/dashboards/8162

• VMware vSphere – Hosts – 8165 - https://grafana.com/dashboards/8165

• VMware vSphere – VMs – 8168 - https://grafana.com/dashboards/8168

Una vez introducimos el ID o la URL de ellos, veremos el siguiente menú que nos permitirá cambiar el
nombre, seleccionar una carpeta para guardarlos, y el datasource que queremos usar:

#VMwarePorvExperts 536
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

Os quiero dejar un ejemplo de cómo queda cada Dashboard para que os hagáis una idea sin necesidad
de importarlos:

VMware vSphere – Overview

Este Dashboard nos muestra un breve resumen de todo el entorno en general, desde el Clúster y
Hosts, pasando por Datastores y VMs con el rendimiento en la parte de Networking y Storage:

#VMwarePorvExperts 537
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

VMware vSphere – Datastore

En este Dashboard se muestra el resumen más detallado de cada Datastore, capacidad, espacio
usado y rendimiento:

VMware vSphere – Hosts

En este Dashboard se muestra el resumen más detallado de cada Host, consumo de CPU, RAM y
Networking, así como rendimiento de las HBA y Storage:

VMware vSphere – VMs

Por último, tenemos el Dashboard sobre máquinas virtuales, que nos muestra el resumen más detallado
de cada VM, consumo de CPU, RAM y Networking, así como valores tan importantes como la CPU
Ready:

#VMwarePorvExperts 538
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

#VMwarePorvExperts 539
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

5. Monitorizando nuestro entorno de vSphere usando


Wavefront y Telegraf

Wavefront es el servicio Enterprise que VMware proporciona para ofrecer una monitorización en tiempo
real, con Dashboards que se crean gracias a la información y métricas que se envían a Wavefront
desde vSphere o desde cualquier aplicación, o componente dentro o fuera de nuestro Datacenter.

Desde la versión 1.8 de Telegraf, en la que se monitoriza vSphere usando el SDK, Wavefront soporta
de manera oficial Telegraf con esta integración de manera nativa - https://docs.wavefront.com/vsphere.
html

Pudiéndose crear Dashboards tan útiles y potentes como el siguiente:

#VMwarePorvExperts 540
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

6. Referencias

• https://www.virten.net/vmware/esxtop/

• https://jorgedelacruz.es

• https://wikipedia.com

#VMwarePorvExperts 541
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

#VMwarePorvExperts 542
Patrocinadores

GOLD

SILVER

BRONZE

#VMwarePorvExperts 543
Capítulo 11
Monitorización con Centreon

Héctor Herrero

#VMwarePorvExperts 544
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Monitorizando vSphere con Centreon

En este capítulo vamos a aprender cómo desplegar Centreon y cómo monitorizar con él nuestra
plataforma virtual.

Centreon es una solución para monitorizar aplicaciones, sistemas, redes y nuestro negocio. Basada
en los mismos conceptos que Nagios y siendo un software de código abierto, distribuido bajo Licencia
Pública General de GNU GPLv2.5. Claro que podemos adquirir una versión comercial donde aparte
de soporte nos proveerán de los complementos de pago, con ellos fácilmente podremos monitorizar
toda la infraestructura. Pero la idea del documento será siempre basarnos en la solución abierta y por
tanto gratuita. Centreon inicialmente fue conocida por aportar una interfaz web de gestión sencilla a
Nagios, evitando tocar sus complicados ficheros de configuración, una alternativa a Nagios y NDOUtils
fueron Centreon Engine y Centreon Broker, que tienen fama de ser más eficientes en cuanto al uso
de recursos y con mayor seguridad. Por tanto, trabajaremos con la ISO de la distribución de Centreon.

Al final del capítulo, veremos también cómo visualizar los datos de nuestro entorno virtual ya
monitorizado con NagVis y Grafana.

#VMwarePorvExperts 545
Capítulo 11 - Monitorización con Centreon Héctor Herrero

1. Monitorización con Centreon

La monitorización es un sistema de supervisión de gran alcance que permite a las organizaciones


identificar y resolver problemas de infraestructura TI antes de que afecten los procesos críticos de
negocio. Un sistema de monitorización le da la tranquilidad de saber que los procesos de negocio de
su organización no se verán afectados por interrupciones desconocidas.

Centreon es una potente herramienta que le permite la visión instantánea de aplicaciones críticas en
la infraestructura de su organización. También le permite detectar y reparar los problemas y mitigar
futuros incidentes antes de que afecten a los usuarios finales y clientes.

Centreon se basa en un sistema distribuido donde podemos tener los componentes en un mismo
servidor, o en entornos grandes separarlo en distintas máquinas, tenemos:

• Centreon Central: Es el servidor que corre el motor de monitorización además de ser también un
Poller y encargarse de las notificaciones entre otros.

• Centreon Poller: Son servidores satélites que podremos ir agregando a nuestra infraestructura para
repartir la carga de ejecución de los chequeos. Además, en entornos donde disponemos diferentes
delegaciones nos servirá para centralizar y encapsular toda la información de los chequeos de las
máquinas remotas al Central.

• Base de datos: Servicio de BBDD basado en MariaDB que dispondrá de dos bases de datos:

• centreon: Almacena metadatos y configuraciones del sitio.

• centreon_storage: Almacena la monitorización en tiempo real y almacena históricos.

Mediante un sistema de alertas, podremos recibir un aviso del servicio afectado por el cual el sistema
puede verse comprometido. Este sistema de alertas gestionará los avisos vía mail, Whatsapp, Telegram,
SMS, o incluso pueden ser introducidos en un sistema de gestión de incidencias (helpdesk), siendo
totalmente escalables a los departamentos responsables de dichos servicios.

#VMwarePorvExperts 546
Capítulo 11 - Monitorización con Centreon Héctor Herrero

1.1 Supervisión en tiempo real

Podremos supervisar en tiempo real el estado de los ítems o Servicios monitorizados, así como el
estado de los Hosts (servidores / impresoras / routers / switches / fw…). Nos mostrará cada Servicio
con un indicador OK, WARNING o CRITICAL dependiendo del estado de su salud.

También podremos agrupar los Servicios por Tipo, por si queremos trabajarlos de forma conjunta,
esto es, ver por ejemplo todos los Routers de un vistazo, o todos los servicios de vCenter, Correo,
Infraestructura virtual, Infraestructura física, de comunicaciones…

Podemos filtrar por Host, Servicio, por Grupo… Desde aquí también podremos deshabilitar un Servicio
que no se monitorice temporalmente, o forzar que se checkee de nuevo, o entre otros habilitar el Modo
Mantenimiento y así excluir durante un periodo los checkeos y no ‘manchar’ las gráficas de SLA con
tiempos de caída de servicio, si no de parada de servicio programada.

#VMwarePorvExperts 547
Capítulo 11 - Monitorización con Centreon Héctor Herrero

1.2 Gráficas

Todo Servicio monitorizado generará unas gráficas que podremos utilizar para conocer su estado,
su crecimiento o conocer su historial para poder analizar y buscar problemas. Podremos filtrar por
periodos y realizar comparaciones con otros Servicios monitorizados, permite exportar las imágenes o
los datos que vemos en CSV para luego tratarlos si interesase de una forma muy rápida.

De este modo podremos calcular la capacidad de nuestros sistemas y pronosticar futuras ampliaciones
sobre ellos.

También dispondremos de un Log de Eventos en el que se registrarán todos los sucesos encontrados
en nuestro sistema, pudiendo así analizarlos eficazmente.

Será un histórico de lo que ha sucedido en nuestro entorno, qué servicios o hosts han caído y cuando.
Como siempre, podremos filtrar también por equipo, o periodos de fecha entre otros.

Con esta serie de avisos podremos atacar los problemas de una manera mucho más eficaz ya que
iremos directamente a solucionar el elemento crítico, reduciendo el tiempo de identificación del
problema y el restablecimiento exitoso del servicio.

La monitorización no solo nos ayudará en caso de caída de servicios, sino que también nos facilitará
su identificación mucho antes de que un servicio llegue a comprometerse.

#VMwarePorvExperts 548
Capítulo 11 - Monitorización con Centreon Héctor Herrero

1.3 Medición de SLA

El Dashboard dentro de la monitorización cumple una función muy importante, ya que a través de
él controlaremos el porcentaje de actividad (OK, WARNING. CRITICAL, UNKNOWN, SCHEDULED
DOWNTIME) de nuestros hosts y servicios en un determinado periodo de tiempo.

Con ello será fácil comprobar el cumplimiento de los SLA de disponibilidad (o acuerdo de nivel de
servicio) de los servicios y servidores. Por supuesto tendremos una medición exacta de la Calidad de
servicio que ofrece,

Podremos ver y medir de una forma muy gráfica los tiempos de servicio o SLA que está dando bien
un equipo, un servicio o grupo de equipos o servicios. Analizaremos el % de tiempo que ha estado
cada ítem, el tiempo en OK será que estaba corriendo perfectamente, WARNING indicará que supera
el baremo que indicamos, pero funcional; CRITICAL sí será el tiempo total de parada y también
interesante, conocer el tiempo de parada programada para mantenimiento!

#VMwarePorvExperts 549
Capítulo 11 - Monitorización con Centreon Héctor Herrero

2. NagVis

NagVis es una capa de visualización de dibujos interactivos que se le añade a Centreon para poder
disponer de cualquier tipo de mapa de estado en tiempo real.

¿Qué es un mapa? Un mapa es cualquier dibujo que queramos tener en una pantalla de TV, estos
mapas pueden ser dibujos lógicos o físicos a los que les añadiremos los Servicios que monitorizamos.
Son dibujos totalmente corporativos y personalizados que mostrarán lo que quieras ver en cada uno
de ellos.

Mapas vivos con tráficos de red de las delegaciones al DataCenter, Estado del rack, Plataforma virtual
y sus dependencias…

Son ideales para disponer de una TV en su departamento y tener un Pool que rota distintos mapas,
demostrará lo bien que tiene controlado su departamento a los demás, en caso de que un servicio
se caiga se pondrá el mapa afectado sonando una alerta. Algunos mapas de ejemplo basados en
entornos vSphere:

Mapa de plataforma virtual:

#VMwarePorvExperts 550
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Mapa de Rack:

Mapa de red de almacenamiento o SAN:

#VMwarePorvExperts 551
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Mapa de comunicaciones LAN

Mapa de comunicaciones WAN:

#VMwarePorvExperts 552
Capítulo 11 - Monitorización con Centreon Héctor Herrero

3. Grafana

Grafana no es más que un Panel de explotación y visualización de datos. Es un Dashboard que permite
visualizar cualquier tipo de métrica. Si con las gráficas de Centreon no te bastan, Grafana es la mejor
solución para tratamiento de datos. Podrás personalizar Dashboards a medida y a gusto, añadiendo
las métricas monitorizadas del Centreon directamente. Super sencillo de usar, podrás añadir gráficas
de CPUs, consumos de Memorias, estado de servicios, tanto de MVs como hosts.

Pero ojo, no queda ahí, Grafana se puede usar para explotar datos de tu empresa, visualizar cualquier
dato que se almacene en una base de datos se puede consultar. Ya sean sus bases de datos del ERP
y analizar crecimiento, ventas o compras entre otros, o su sistema de gestión de tiempos o fichajes,
etc, etc… Podrás exportar tus Dashboards a PDF y programar envíos de correos con informes listos
según la demanda requerida.

Por tanto, Grafana se ejecuta de forma individual en otra máquina virtual y se licencia bajo la licencia
Apache License 2.0, libre de costes en cuanto a licenciamiento.

#VMwarePorvExperts 553
Capítulo 11 - Monitorización con Centreon Héctor Herrero

4. Monitorización de Negocio

Una vez dispongamos de la base totalmente monitorizada, siempre se puede escalar dicha monitorización
y pensar un poco en el Negocio. ¿Qué necesita la empresa para que desarrolle su servicio? ¿Qué debe
funcionar? Bien, con la base monitorizada, podremos interrelacionar las dependencias del Negocio en
los Servicios monitorizados. Con ello, podremos saber y medir el SLA que ofrecemos a la empresa, así
como a sus diferentes departamentos organizativos. Se analizarán y sacarán puntos críticos para que
su Negocio no pare su servicio.

¿Sabía acaso que su negocio podría detenerse si un certificado que apenas pasa de los 50€ se
caduca? Es importante conocer qué monitorizar y por qué.

La monitorización de Negocio consiste en la instalación de un componente de análisis de negocio,


pudiendo ser mediante Centreon Monitoring Bussines Intelligence o Nagios Business Process. Más la
compleja definición de cada Servicio Operacional y sus Servicios de Infraestructura.

Se podrán realizar análisis de impacto, para determinar la importancia de un elemento monitorizado.


A la hora de preguntarse por ejemplo ¿Qué pasa si apago este servidor? ¿y si quito este cable?
Conoceremos a qué Servicios de Negocio afectará antes de tocar nada. Por supuesto también para
conocer simulaciones de configuraciones óptimas, etc…

Ejemplo de los principales Servicios de Negocio:

#VMwarePorvExperts 554
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Ejemplo, Servicio Atención al Cliente:

Ejemplo, Servicio Correo Electrónico:

#VMwarePorvExperts 555
Capítulo 11 - Monitorización con Centreon Héctor Herrero

5. Prerrequisitos

A la hora de desplegar Centreon, debemos considerar el tamaño y tipo de monitorización que


necesitaremos. Si únicamente tenemos los ítems a monitorizar en una ubicación o en distintas, para
saber si comenzar con un servidor Central o al menos necesitaremos Pollers, así como el volumen de
los Servicios que monitorizaremos, ya que la ejecución se realiza desde los servidores de Centreon, a
más ítems monitorizados, más recursos necesitará nuestra plataforma; y es posible añadir servidores
Poller para repartir la carga de los chequeos.

La ISO con la distribución de Centreon se basa en un CentOS 7 de x64, para trabajar con ella
necesitaremos un navegador compatible, hoy en día últimas versiones de Firefox, Chrome o Safari
nos valdrán, así como a partir de IE 11. Se recomienda almacenar los datos en una base de datos de
MariaDB en vez de MySQL, y en entornos grandes en, al menos, una máquina dedicada. Un servidor
Poller podría monitorizar unos 7000 servicios de monitorización, con una CPU de al menos 3Ghz, a
más servicios monitorizados, más CPU necesitaremos; dependerá de la complejidad de los chequeos
y su consumo. Como tabla que nos puede servir a modo referencia, usaremos:

Número de Número de Hosts Número de


Central Poller
Servicios (estimados) Servidores
< 500 50 1 Central 1 vCPU + 1 GB RAM
500 - 2000 50 - 200 1 Central 2 vCPU / 2 GB RAM
2000 - 7000 200 - 700 1 Central + 1 Poller 4 vCPU / 4 GB RAM 1 vCPU / 4 GB RAM
7000 - 14000 700 - 1400 1 Central + 1 Poller 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM
14000 - 21000 1400 - 2100 1 Central + 2 Pollers 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM
21000 - 28000 2100 - 2800 1 Central + 3 Pollers 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM

En cuanto al almacenamiento en disco, esto es, en la base de datos y directorio del Engine; pues todo
dependerá del número de los Servicios que se monitoricen y la frecuencia con la que se ejecutan,
además, será importante establecer una retención de los datos. Por poner una tabla de ejemplo, si
nuestros Servicios se chequean cada 5 minutos y tenemos una retención de 6 meses:

Número de Servicios /var/lib/mysql /var/lib/centreon


< 500 10 GB 2.5 GB
500 - 2000 42 GB 10 GB
2000 - 10000 126 GB 30 GB
10000 - 20000 252 GB 60 GB
20000 - 50000 660 GB 150 GB
50000 - 100000 1.4 TB 600 GB

#VMwarePorvExperts 556
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Los servidores de Centreon deben de usar LVM para la gestión de los discos, este será el espacio que
definiremos:

Rol Path Tamaño


Swap De 1 a 1,5 veces el tamaño de la Memoria RAM
/ Al menos 20 GB
Centreon Central o /var/log Al menos 10 GB
Centreon Poller /var/lib/centreon Indicado en la tabla anterior
/var/lib/centreon-broker Al menos 5 GB
/var/cache/centreon/backup Al menos 10 GB
Swap De 1 a 1,5 veces el tamaño de la Memoria RAM
/ Al menos 20 GB
Servidor de BD /var/log Al menos 10 GB
/var/lib/mysql Indicado en la tabla anterior
/var/cache/centreon/backup Al menos 10 GB

#VMwarePorvExperts 557
Capítulo 11 - Monitorización con Centreon Héctor Herrero

6. Instalando Centreon

Lo dicho, gracias al interfaz de Centreon, podremos monitorizar de una manera sencilla, desplegaremos
una máquina virtual, será el que almacene toda la información y además ejecute los chequeos de
salud. Monitorizaremos nuestros servidores Windows, Linux, hosts ESXi, máquinas virtuales, puertos,
certificados, servicios o ejecución de cualquier script que se nos ocurra, sea PowerShell, scripts en
batch, perl, vb… En esta sección veremos puramente la instalación con un sólo servidor.

Nos descargamos la ISO o el appliance virtual de https://download.centreon.com/ y comenzaremos


su despliegue.

Tendremos en cuenta que también nos podremos bajar directamente un appliance virtual en formato
OVA con todo instalado y listo, pero mejor para laboratorios de casa que en producción.

Tras conectar la ISO a la MV comenzamos la instalación de la distribución CES en Centos 7, escogemos


el idioma para la instalación, “Continue”.

#VMwarePorvExperts 558
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Pulsamos primeramente en ‘Installation Type’

Donde debemos seleccionar el tipo de despliegue que haremos, en este caso como indicamos
tendremos este único servidor con todos los roles. “Done”.

#VMwarePorvExperts 559
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Pulsamos en ‘Installaton Destination’,

Y seleccionamos el disco duro y el modo de particionamiento a utilizar. “Done”.

#VMwarePorvExperts 560
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Seleccionamos ‘Network & Hostname’

Habilitamos la interfaz, le indicamos un nombre de máquina con formato FQDN y pulsamos en


“Configure…”,

#VMwarePorvExperts 561
Capítulo 11 - Monitorización con Centreon Héctor Herrero

En ‘IPv4 Settings’ debemos especificar una dirección IP estática, una máscara de red, puerta de enlace,
servidores DNS y dominio de búsqueda local.

No olvidaremos configurar la hora y la zona horaria. Tras ello, comenzamos ya la instalación pulsando
‘Begin Installation’.

#VMwarePorvExperts 562
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Durante la instalación podremos establecer la contraseña al usuario ‘root’, así como crear si necesitamos
usuarios adicionales.

Con establecer el password a root nos será suficiente.

#VMwarePorvExperts 563
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Esperamos, en cuestión de minutos tendremos Centreon desplegado…

Listo, pulsamos en “Reboot” para reiniciar la máquina, recordar desconectar la ISO.

#VMwarePorvExperts 564
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Accedemos mediante un navegador a la dirección IP de Centreon, comenzará un asistente final de


configuración.

Verificamos que disponemos de los módulos correctamente cargados & “Next”,

#VMwarePorvExperts 565
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Estos serían los datos predeterminados del motor de monitorización:

• Directorio de Centreon Engine: /usr/share/centreon-engine


• Binario de las estadísticas de Centreon: /usr/sbin/centenginestats
• Directorio Centreon Engine: /var/lib/centreon-engine
• Directorio del conector de Centreon: /usr/lib64/centreon-connector
• Directorio de librerías de Centreon: /usr/lib64/centreon-engine
• Directorio donde dejaremos los plugins para usar con Centreon: /usr/lib/centreon/plugins

Información sobre la parte del broker:

• Directorio del broker en etc: /etc/centreon-broker


• Módulo del broker: /usr/lib64/nagios/cbmod.so
• Directorio de logs del broker: /var/log/centreon-broker
• Directorio del fichero de retención: /var/lib/centreon-broker
• Directorio de librerías: /usr/share/centreon/lib/centreon-broker

#VMwarePorvExperts 566
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Debemos establecer una contraseña al usuario admin para la gestión de Centreon, así como indicarle
un nombre, apellido y dirección de correo electrónico, “Next”,

Configuraremos la conexión de Centreon con la base de datos, indicaremos que el servidor es ‘localhost’,
puerto 3306, la contraseña del usuario root, indicaremos un nombre a la BD de configuración, y otro
nombre a la BD de datos, crearemos un usuario y le asignaremos una contraseña.

Antes de proceder, debemos añadir permisos desde consola o acceso mediante SSH ejecutando:

mysqladmin -u root password CONTRASEÑA


mysqladmin -u root -h localhost CONTRASEÑA

#VMwarePorvExperts 567
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Continuamos mientras nos crea la estructura de la BD,

Marcamos los módulos Centreon License Manager y Centreon Plugin packs Manager. Nos servirán de
mucha ayuda para desplegarnos plantillas. Pulsamos en “Install”.

#VMwarePorvExperts 568
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Tras su instalación, continuamos con “Next”,

Y ya dispondremos de Centreon instalado y configurado básicamente. Pulsamos en “Finish”.

#VMwarePorvExperts 569
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Ahora ya podremos loguearnos en nuestro panel de Centreon, accedemos como admin y la contraseña
que le hemos establecido durante el asistente de configuración.

Bienvenidos a la interfaz de Centreon, disponemos los siguientes menús:

• Home: Podremos añadir widgets y hacer una vista inicial algo chula con las gráficas más típicas
que solemos consultar. Así como ver las estadísticas del Poller.

• Monitoring: Será la parte desde donde veremos los resultados de la monitorización, los servicios
que analicemos, aquí será donde veremos si el estatus es OK, WARNING o CRITICAL.

• Reporting: Un apartado chulo para medir SLA’s y tiempos de respuesta a nivel individual o a nivel
de grupos de servicios o hosts.

• Configuration: Donde configuraremos los hosts a monitorizar, así como sus servicios o comandos.
Además, en este apartado podremos crear o modificar usuarios, tipos de notificación, Pollers,
Traps SNMP,

• Administration: Para configurar parámetros de Centreon, extensiones sean widgets o módulos,


permisos de ACL, logs, y supervisar el estado del servidor entre otros.

Desde la barra superior: Interesante, de un vistazo podremos supervisar el estado general de nuestra
monitorización, así como el status general de cuántos hosts o servicios hay caídos.

#VMwarePorvExperts 570
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Si vamos a “Configuration” > “Plugin Packs” > “Manager”, llegaremos gestor de plugins que deberemos
instalar. Estos nos crearán las plantillas o templates que necesitaremos para ir creando nuestros hosts
a monitorizar (hosts serán los servidores, impresoras, dispositivos…). Así que será bueno tener la
base de todos estos y así poder monitorizar al menos ya equipos con Linux, Windows, Impresoras,
dispositivos Cisco, SAI, BD de MySQL, así como el propio servidor de Centreon, su base de datos o
el estado del Poller.

#VMwarePorvExperts 571
Capítulo 11 - Monitorización con Centreon Héctor Herrero

7. Monitorizando Hosts ESXi

Bien, tras instalar Centreon, ya podemos directamente monitorizar nuestra plataforma de vSphere,
comenzaremos con los hosts ESXi.

Utilizaremos un magnifico script que conectará mediante API y obtendrá la información que necesitamos.
Pero primeramente debemos instalar los requisitos que requieren que podamos comenzar a usar el
script.

7.1 Instalación requisitos previos

En la máquina de Centreon debemos comenzar con la instalación de requisitos y dependencias:

yum -y install openssl-devel perl-Archive-Zip perl-Class-MethodMaker uuid-perl perl-SOAP-


Lite perl-XML-SAX perl-XML-NamespaceSupport perl-XML-LibXML perl-MIME-Lite perl-MIME-Types
perl-MailTools perl-TimeDate uuid libuuid perl-Data-Dump perl-UUID make gcc perl-devel
libuuid-devel cpan

Debemos descargar el SDK de 64bit para SO Linux de:

https://my.vmware.com/group/vmware/details?downloadGroup=VS-PERL-SDK67&productId=742

#VMwarePorvExperts 572
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Lo copiamos a la máquina de Centreon, con FileZilla o WinSCP podremos realizarlo sencillamente.


Tras copiarlo al CentOS, lo descomprimimos e instalamos el SDK:

tar xvzf VMware-vSphere-Perl-SDK-6.7.0-8156551.x86_64.tar.gz


cd vmware-vsphere-cli-distrib/
./vmware-install.pl

La instalación de SDK nos realizará una serie de cuestiones que podremos continuar con los valores
predeterminados. Seguimos con UUID, lo descargamos, lo compilamos y lo instalamos:

cd /usr/src
wget http://search.cpan.org/CPAN/authors/id/J/JN/JNH/UUID-0.04.tar.gz
tar -xzvf UUID-0.04.tar.gz -C /opt
cd /opt/UUID-0.04
perl Makefile.PL
make
make install

Instalamos también perl-Nagios-Plugin:

yum install nagios-plugins-perl -y

Seguimos con libwww-perl y módulos de Perl que necesitaremos:

cpan GAAS/libwww-perl-5.837.tar.gz
cpan Monitoring::Plugin

Utilizaremos el script ‘check_vmware_api’ de OP5, nos lo descargamos, lo hacemos ejecutable,


probamos a ejecutarlo con el parámetro -h para ver toda su excelente ayuda y lo movemos al directorio
donde guardamos los plugins:

wget https://raw.githubusercontent.com/op5/check_vmware_api/master/check_vmware_api.pl
chmod +x check_vmware_api.pl
./check_vmware_api.pl -h
mv check_vmware_api.pl /usr/lib/centreon/plugins/

#VMwarePorvExperts 573
Capítulo 11 - Monitorización con Centreon Héctor Herrero

7.2 Dando acceso

En cada host que queramos monitorizar, deberemos crear un usuario para permitir acceso al script y
que pueda obtener los valores que nos interesen.

En el Host Client, desde “Administrar” > “Seguridad y usuarios” > “Agregar usuario” podremos dar de
alta nuestro usuario.

Creamos un usuario modelo,

#VMwarePorvExperts 574
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Y recordamos darle permisos de acceso, sobre el Host con botón derecho > “Permisos”.

Pulsamos en “Agregar usuario”,

#VMwarePorvExperts 575
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Y seleccionamos el usuario recién creado y le asociamos al grupo ‘Solo lectura’, con ello será suficiente
para que pueda leer los parámetros requeridos.

Ahora, ya en Centreon debemos crear un fichero de autenticación, donde almacenaremos el usuario


que utilizaremos con el script. Yo le llamo ‘/usr/lib/centreon/plugins/check_vmware_api.auth’ y con el
siguiente formato indicamos los credenciales:

username=monitorizacion
password=contraseña

Podemos validar que todo es correcto haciendo una sencilla prueba desde la Shell del Centreon. Si
ejecutamos:

/usr/lib/centreon/plugins/check_vmware_api.pl -H DIRECCION_IP_HOST -f
/usr/lib/centreon/plugins/check_vmware_api.auth -l cpu -s usage

Veremos el uso de CPU del host. Como vemos el script se alimenta de distintos argumentos, el primero,
con -H le pasamos la dirección IP del host ESXi, con -f le pasamos el fichero de autenticación, con -l
indicamos el Comando y con -s el SubComando. Adicionalmente le podríamos poner -w de Warning y
-c para Critical, si los cumplimentamos con los valores 80 y 90, nos advertirá con un Warning cuando
la CPU use más del 80% y un Critico cuando supere el 90%.

#VMwarePorvExperts 576
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Con este script como comentamos podemos monitorizar muchas cosas más, esta tabla nos valdrá a
modo resumen de lo que obtendremos con dicho script en cuanto monitorizar ESXi’s.

Comando SubComando Descripción


usage Uso de CPU en %
cpu
usagemhz Uso de CPU en Mhz
usage Memoria RAM en %
usagemb Memoria RAM en MB
swap Memoria Swap en MB
mem
overhead Memoria Overhead en MB
overall Memoria total en MB
memctl Memoria Balloning en MB
usage Trafico en KBps
receive Trafico Recibido en KBps
net
send Trafico Enviado en KBps
nic Estado de las NIC
aborted Comandos abortados
resets Resets
read Latencia de lectura en ms
io write Latencia de escritura en ms
kernel Latencia del kernel en ms
device Latencia del dispositivo en ms
queue Latencia de Queue en ms
vmfs NOMBRE_DS Muestra espacio utilizado del datastore VMFS en MB
con Estado de Conexión
health Salud del host
storagehealth Salud del almacenamiento
temperature Temperatura
runtime
sensor Estado de sensores
maintenance Conocer si está en modo mantenimiento
status Estado general del host
issues Estado de la configuración del host
service [nombre] Estado de los servicios del host
adapter Muestra los adaptadores de almacenamiento
storage lun Muestra las unidades lógicas
path Muestra los paths
uptime Uptime
device cd/dvd Lista MVs con dispositivos conectados

#VMwarePorvExperts 577
Capítulo 11 - Monitorización con Centreon Héctor Herrero

7.3 Definiendo el Comando

Para poder monitorizar los Servicios de CPU, Memoria… antes de nada, tenemos que trasladar a
Centreon qué ejecutar cuando queramos saber el resultado de dichos Servicios de monitorización.
Primeramente, definiremos un Comando basado en el script que hemos ejecutado antes, pero
tendremos que sustituir los valores fijos por variables y así podamos usar un solo Comando para
monitorizar todos los Servicios.

Bien, si vamos a “Configuration” > “Commands” > “Add…” crearemos lo siguiente:

$CENTREONPLUGINS$/check_vmware_api.pl -H $HOSTADDRESS$ -f
$CENTREONPLUGINS$/check_vmware_api.auth -l $ARG1$ -s $ARG2$ -w $ARG3$ -c $ARG4$

Cuando Centreon quiera ejecutar algún chequeo de los que queremos, ejecutará lo siguiente, hemos
sustituido con variables y argumentos los valores a rellenar manualmente.

• La variable $CENTREONPLUGINS$ es ‘/usr/lib/centreon/plugins/’


• La variable $HOSTADDRESS$ sería la dirección IP o nombre FQDN del servidor a monitorizar.
• ARG1 sería el primer argumento que le pasaremos, si recordamos es el ‘Comando’ que se indica
tras ‘-l’.
• ARG2 sería el segundo argumento que le pasaremos, si recordamos es el ‘SubComando’ que se
indica tras ‘-s’.
• ARG3 será el valor de Warning.
• ARG4 será el valor de Critical.
Pulsamos en “Describe arguments”,

Así que asociamos de una forma sencilla qué es cada Argumento, que luego cuando creemos los
servicios, lo agradeceremos. “Save”.

#VMwarePorvExperts 578
Capítulo 11 - Monitorización con Centreon Héctor Herrero

7.4 Definiendo los Hosts

Damos de alta en Centreon nuestro primer servidor, un host ESXi.

Desde “Configuration” > “Hosts” > “Add…” añadiremos nuestro primer host ESXi, completaremos al
menos los siguientes campos:

• Name: Nombre del servidor ESXi.

• Alias: Alias del servidor ESXi.

• IP Address / DNS: La dirección IP o nombre DNS del servidor ESXi.

• SNMP Community & Version: En este caso no sería necesario ya que ESXi no soporta SNMP.

• Template: Normalmente seleccionamos ‘generic-active-host-custom’

7.5 Definiendo los Servicios

Aquí ya por fin podremos crear los servicios de lo que queremos monitorizar, sea CPU, RAM, NICs
caídas, estado de los datastores… para ello, nos apoyaremos como hemos dicho en el comando que
acabamos de crear.

#VMwarePorvExperts 579
Capítulo 11 - Monitorización con Centreon Héctor Herrero

En “Configuration” > “Services” > “Add”, crearemos nuestro primer servicio. Rellenaremos al menos
los siguientes datos:

• Description: Nombre del servicio, en mi caso CPU, Memoria RAM, Memoria Swap…

• Linked with Hosts: Aquí añadiremos el host que hemos creado antes, nuestro servidor ESXi.

• Template: Seleccionamos ‘generic-active-service’.

• Check Command: Escogemos el Comando que hemos creado anteriormente.

• Argumentos: Deberemos rellenar todos los argumentos que nos pida el comando.

Tras realizar el primer Servicio, será más cómodo duplicar el recién creado y modificar de nuevo el
Nombre y los Argumentos. Y, claro, hacer tantos servicios como queramos.

#VMwarePorvExperts 580
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Este sería un ejemplo con un resumen de los Servicios más interesantes.

7.6 Grabando la configuración

Bien, una vez hemos creado los Hosts y los Servicios que nos interese, debemos grabar la configuración,
un proceso que generará y exportará los archivos de configuración de Centreon.

Lo haremos desde “Configuration” > “Pollers” > “Export configuration”, indicamos donde hemos realizado
los cambios, en nuestro Poller Central, además indicamos que genere los ficheros de configuración,
arranque en modo debug, exporte los ficheros y reinicie el motor de monitorización. En el método
normalmente con ‘Reload’ nos será más que suficiente, pero si es la primera vez que lo hacemos,
deberemos pulsar ‘Restart’ para que nos reinicie e inicie los servicios.

#VMwarePorvExperts 581
Capítulo 11 - Monitorización con Centreon Héctor Herrero

7.7 Resultado

Desde “Monitoring” > “Services” podremos finalmente supervisar el estado de los Servicios que le
hemos añadido al host ESXi. De una manera rápida tenemos el primer servidor monitorizado.

Si queremos monitorizar servidores ESXi adicionales, ya lo haremos de manera inmediata,


simplemente, desde ‘Configuration’, clonando este host crearemos el resto, generamos tantos hosts
como necesitemos, le indicamos el nombre y dirección IP y listo, recordando crear el usuario local en
cada ESXi.

#VMwarePorvExperts 582
Capítulo 11 - Monitorización con Centreon Héctor Herrero

8. Monitorizando MVs de vSphere

Podemos seguir sacando jugo a este mismo script, con él podremos conocer las métricas que
proporciona vCenter y obtiene de las máquinas virtuales.

8.1 Dando acceso

En esta ocasión el script en vez de hacer las consultas a los hosts, es preferible hacerlas a través de
vCenter Server, ya que las MVs suelen balancearse y moverse entre los hosts ESXi.

Crearemos un usuario en nuestro entorno vCenter, desde vSphere Client > “Administración” > “Single
Sign On” > “Usuarios y grupos” > “Usuarios”, seleccionamos normalmente vsphere.local > “Agregar
Usuario”.

Creamos un usuario genérico y le establecemos una contraseña robusta, pulsamos en “Agregar”.

#VMwarePorvExperts 583
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Vamos a darle permisos al usuario, en la vista de ‘Hosts & Clusters’ seleccionamos el ítem más alto, en
este caso nuestro propio vCenter, y en la pestaña “Permisos” pulsaremos en agregar.

Buscamos al usuario recién creado y le establecemos un rol, normalmente ‘Solo lectura’ será suficiente.
Y marcamos el tick de ‘Propagar a objetos secundarios’.

Una vez creado el usuario, generamos un archivo en Centreon de autenticación, donde almacenamos
los credenciales que usará el script para hacer consultas, en mi caso lo guardo en ‘/usr/lib/centreon/
plugins/check_vmware_api_vc.auth’ con el siguiente contenido:

username=monitorizacion@vsphere.local
password=contraseña

Para probar, tan sencillo como utilizar el mismo script (check_vmware_api.pl), con -D consultamos a
vCenter Server, con -N indicamos el nombre de la MV como se ve en el inventario, con -f le pasamos
el fichero de autenticación; con -l el Comando y con -s el SubComando. Muy similar que a la hora de
monitorizar los hosts ESXi; acordaros que podríamos meter -w para establecer el valor de Warning y
-c el Critical. En este ejemplo vemos el CPU Ready de una máquina virtual.

/usr/lib/centreon/plugins/check_vmware_api.pl -D DIRECCION_IP_VCENTER -N NOMBRE_MV -f


/usr/lib/centreon/plugins/check_vmware_api_vc.auth -l cpu -s ready

#VMwarePorvExperts 584
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Comando SubComando Descripción


usage Uso de CPU en %
usagemhz Uso de CPU en Mhz
cpu
wait CPU Wait en ms
ready CPU Ready en ms
usage Memoria RAM en %
usagemb Memoria RAM en MB
swap Memoria Swap en MB
swapin Memoria Swap In en MB
mem swapout Memoria Swap Out en MB
overhead Memoria Overhead en MB
overall Memoria total en MB
memctl Memoria Balloning en MB
active Memoria Activa
usage Trafico en KBps
net receive Trafico Recibido en KBps
send Trafico Enviado en KBps
usage Uso del disco en MB/s
io read Lectura del disco en MB/s
write Escritura del disco en MB/s
con Estado de Conexión
state Estado de la MV (Encendida/apagada/suspendida)
runtime status Estado general de la MV
guest Estado del SO invitado
tools Estado de las VMware Tools

#VMwarePorvExperts 585
Capítulo 11 - Monitorización con Centreon Héctor Herrero

8.2 Definiendo el Comando

Necesitamos definir un nuevo Comando, ya que el anterior no nos valdrá, nosotros ahora queremos
consultar mediante vCenter y no mediante los hosts.

Vamos a “Configuration” > “Commands” > “Add…” crearemos el Comando con la siguiente línea de
comandos:

$CENTREONPLUGINS$/check_vmware_api.pl -D DIRECCION_IP_SERVIDOR_VCENTER -N $ARG1$ -f


$CENTREONPLUGINS$/check_vmware_api_vc.auth -l $ARG2$ -s $ARG3$ -w $ARG4$ -c $ARG5$

Y pulsamos en “Describe arguments” para identificar cada Argumento:

• ARG1 sería el primer argumento que le pasaremos, tras -N será el Nombre de la MV.

• ARG2 es el segundo argumento, siendo el ‘Comando’ que le pasamos con ‘-l’

• ARG3 será el ‘SubComando’ que se indica tras ‘-s’.

• ARG4 será el valor de Warning.

• ARG5 será el valor de Critical.

#VMwarePorvExperts 586
Capítulo 11 - Monitorización con Centreon Héctor Herrero

8.3 Definiendo los Servicios

Con el Comando ya definido, crearemos tantos Servicios queramos monitorizar de las distintas
máquinas virtuales.

Desde “Configuration” > “Services” > “Add”, crearemos los servicios. O si nos es más cómodos podemos
clonar de alguno ya existente, debemos indicar al menos:

• Description: Nombre del servicio monitorizado. Personalmente, cómo son métricas de virtualización
les suelo llamar ‘MV - …’

• Linked with Hosts: Aquí añadiremos normalmente la máquina monitorizada, para asociarle a ella
las métricas de la capa de virtualización.

• Template: Seleccionamos ‘generic-active-service-custom’.

• Check Command: Elegimos el Comando que acabamos de crear.

• Argumentos: Deberemos rellenar todos los argumentos que nos pida el comando.

#VMwarePorvExperts 587
Capítulo 11 - Monitorización con Centreon Héctor Herrero

8.4 Resultado

Como siempre, tras crear tantos servicios como queramos monitorizar de cada MV y tras grabar y
exportar la configuración en Centreon, ya podremos venir a visualizar los resultados de la monitorización.

Si vamos a “Monitoring” > “Services”, podremos ya buscar los servicios que acabamos de añadir y
visualizaremos su estado actual. Como vemos es una pasada la de métricas que podemos sacar de
cada MV.

#VMwarePorvExperts 588
Capítulo 11 - Monitorización con Centreon Héctor Herrero

9. Monitorizando vCSA

En esta sección del capítulo vamos a monitorizar el appliance virtual de VMware llamado vCenter
Server Appliance o vCSA, que como sabemos es la máquina que proporciona gestión y control de
nuestra plataforma virtual. Y depende del servicio que nos preste puede ser una máquina crítica y
necesaria de monitorizar.

A diferencia de hasta ahora, vCSA lo vamos a monitorizar mediante SNMP, ya que es una MV basada
en Linux. Aún que os recuerdo que el script que hemos visto hasta ahora también tiene una sección
específica para monitorizar DataCenters o incluso a nivel de Clúster, conociendo los recursos de CPU
totales, de Memoria… échale un vistazo a la ayuda:

/usr/lib/centreon/plugins/check_vmware_api.pl -h

Para habilitar SNMP en el vCSA, nos conectamos bien con un Putty por SSH o en consola local,
indicaremos la comunidad SNMP que utilicemos ejecutando:

Command> snmp.set --communities NOMBRE_COMUNIDAD


Command> snmp.enable

#VMwarePorvExperts 589
Capítulo 11 - Monitorización con Centreon Héctor Herrero

9.1 Monitorización base de vCSA

Lo primero de todo, vamos a dar de alta en Centreon la máquina vCSA, para poder enlazarla
posteriormente los Servicios que la van a monitorizar.

Desde “Configuration” > “Hosts” > “Add…” crearemos la máquina, donde:

• Name: Nombre del servidor vCSA.

• Alias: Alias del servidor vCSA.

• IP Address / DNS: La dirección IP o nombre DNS del servidor vCSA.

• SNMP Community & Version: Indicamos la misma comunidad que hemos configurado antes en
el vCSA y establecemos versión ‘2c’.

• Template: Seleccionamos ‘generic-active-host-custom’ y como al inicio instalamos los Plugin Pack


y descargamos las plantillas para SO Linux, añadimos también ‘OS-Linux-SNMP-custom’.

Si grabamos la configuración de Centreon, podremos verificar que al menos algunos de los Servicios
que heredamos de la plantilla Linux nos valdrán para conocer el estado de su CPU, red o Uptime.

#VMwarePorvExperts 590
Capítulo 11 - Monitorización con Centreon Héctor Herrero

9.2 Monitorizando sus discos

Si la plantilla base de Linux que le hemos aplicado al Host de vCSA no nos ha generado los discos,
podremos añadirlos fácilmente.

Desde “Configuration” > “Services” > “Add” añadimos el Servicio que monitorizará el disco ‘/’, lo
enlazamos al Host de vCSA y en ‘Template’ debemos indicar que use ‘OS-Linux-Disk-Generic-Name-
SNMP-custom’. En las macros con indicar el DISKNAME a ‘/’ nos bastará.

Por recordar, una MV vCSA 6.x dispone de los siguientes discos

Punto de montaje Descripción


/boot Boot
/tmp/mount Directorio temporal
SWAP Espacio Swap
/storage/core Core dumps
/storage/log Logs del sistema
/storage/db BD de vPostgres
/storage/dblog Logs de vPostgres
/storage/seat Donde se almacenan las estadísticas, eventos y tareas en vPostgres
/storage/netdump Volcados de red Netdump collector
/storage/autodeploy Repositorio de Auto Deploy
storage/invsvc Servicio de inventario bootstrap y configuración de tomcat
/dev/shm Memoria compartida
/storage/imagebuilder Repositorio de Image Builder
/storage/updatemgr Almacén para Update Manager
/storage/archive Archivado de vPostgres

#VMwarePorvExperts 591
Capítulo 11 - Monitorización con Centreon Héctor Herrero

9.3 Monitorizando Procesos

Si nos interesa conocer si vCSA dispone de los servicios necesarios corriendo, lo más sencillo será
validar que tenemos sus procesos activos, y si los procesos están activos, al menos aseguraremos
que está corriendo.

Podemos utilizar la siguiente tabla para monitorizar los procesos de nuestro vCSA:

Proceso Descripción
vmafdd Servicio VMware Authentication Framework
vmware-cm Servicio VMware Component Manager
vmware-eam Servicio VMware ESX Agent Manager
vmware-sts-idmd Servicio VMware Identity Management Service
vmware-cis-license Servicio VMware License Service
vpostgres Servicio VMware vPostgres
vmware-sca Servicio VMware Service Control Agent
vmware-vpxd Servicio VMware vCenter Server
vmware-vpxd-svcs Servicio VMware vCenter-Services
vmware-vsm Servicio VMware vService Manager
vsphere-ui Servicio VMware vSphere Client
vsphere-client Servicio VMware vSphere Web Client

Para monitorizar cada proceso que nos interese, tendremos que crear un Servicio asociado. Desde
“Configuration” > “Services” > “Add…” y tras rellenar el nombre del Servicio indicaremos que como
Comando de chequeo utilice ‘OS-Linux-SNMP-Process-Generic’, simplemente en las macros que nos
aparecerán cumplimentamos el campo PROCESSNAME con el nombre del proceso asociado.

#VMwarePorvExperts 592
Capítulo 11 - Monitorización con Centreon Héctor Herrero

9.4 Monitorizando caducidad del certificado

Si hemos cambiado los certificados que trae por defecto los servicios de vCSA por unos de confianza,
como buena práctica. Bueno será monitorizarlos para evitar que nos caduquen y tengamos problemas
en el entorno. Este script que utilizaremos también lo podremos utilizar para validar certificados de
otros sitios que dispongamos. Desde Centreon, nos descargamos el script, lo hacemos ejecutable y lo
copiamos al directorio de los plugins:

wget https://raw.githubusercontent.com/matteocorti/check_ssl_cert/master/check_ssl_cert
chmod +x check_ssl_cert
cp check_ssl_cert /usr/lib/centreon/plugins/

Añadimos el Comando que utilizaremos en los Servicios distintos que tengamos para monitorizar
distintos certificados. Indicamos el siguiente ‘Command Line’:

$CENTREONPLUGINS$/check_ssl_cert -H $ARG1$ -A -p $ARG2$ -w $ARG3$ -c $ARG4$

Pulsamos en ‘Describe arguments’ para definir los Argumentos.

Donde el ARG1 será la dirección IP o FQDN contra el que conectaremos. ARG2 es el puerto al que
conectarse. ARG3 son los días de preaviso que queremos para un aviso Warning y ARG4 para cuando
queden menos días y queramos tener un aviso Critical.

#VMwarePorvExperts 593
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Una vez creado el Comando, lo que nos queda como siempre es definir los Servicios que monitorizarán
distintos certificados. En este ejemplo vamos a comprobar la validez del certificado de vSphere Web
Client, por tanto, al crear el Servicio, lo asociamos con el Comando recién creado y cumplimentamos
los argumentos. El primer argumento será la IP o nombre de nuestro vCSA, el segundo argumento
usaremos el puerto 9443 y obtendremos un aviso Warning cuando queden 30 días para que caduque
y si llegados los 15 días ya serán alertas Criticas.

9.5 Monitorizando Puertos

Y por finalizar, si queremos verificar que un puerto tcp está escuchando, lo podremos implementar en
Centreon en cuestión de segundos. Primero instalaremos este plugin de nagios:

yum install nagios-plugins-tcp -y

Tras ello, podremos como ya sabemos, crear el Comando que usaremos para ejecutar el script. Si en
la línea de comandos indicamos:

/usr/lib64/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p $ARG1$

Podremos chequear cualquier puerto (-p) que nos interese.

#VMwarePorvExperts 594
Capítulo 11 - Monitorización con Centreon Héctor Herrero

Y finalmente creamos el Servicio asociado, por ejemplo, para verificar que el puerto de vSphere Web
Client está levantado. A la hora de crear el Servicio seleccionaremos el Comando creado en el paso
anterior y en el argumento simplemente pondremos el número de puerto a monitorizar.

9.6 Resultado

En este pantallazo podemos ver todos los Servicios que hemos ido creando para monitorizar el servidor
vCSA, recordar grabar y exportar la configuración. Con esto aseguraremos conocer en todo momento
qué sucede en nuestro appliance vCSA.

#VMwarePorvExperts 595
Capítulo 11 - Monitorización con Centreon Héctor Herrero

10. Monitorizando Snapshots

En este apartado, veremos cómo Centreon también nos puede ayudar a monitorizar la existencia de
snapshots en nuestra infraestructura virtual, de todos es sabido el peligro que tiene tener snapshots
o dejarlos durante largos periodos… bien generados por backups colgados que dejan snapshots a
medias o nosotros manualmente. ara combatir esto, automatizaremos un checkeo periódico con un
gran script.

Este script necesita que tengamos SSH habilitado en al menos un host ESXi, con ello chequearemos
la existencia de snapshots en sus datastores, no usaremos por tanto SNMP. El script, necesitará
validarse contra el host ESXi a la hora de ejecutarse, por lo que deberemos configurar acceso SSH
con claves públicas. Así el host ESXi confiará en el usuario que ejecuta el script desde la máquina de
Centreon y no preguntará por los credenciales.

Lo primero, será loguearnos en la shell de nuestro Centreon, ahí, nos logueamos con el usuario que
ejecuta los scripts en Centreon, el usuario es ‘centreon-engine’, así que nos logueamos, generamos
las claves para nuestro usuario y copiamos la clave pública al host ESXi; al ser la primera vez que nos
conectemos además confirmaremos con un ‘yes’ que confiamos en su firma.

su - centreon-engine
ssh-keygen -t rsa
scp /var/lib/centreon-engine/.ssh/id_rsa.pub root@DIRECCION_IP_ESXi:/etc/ssh/keys-root/
authorized_keys

Ahora tenemos que descargar el script de esta URL:

https://exchange.nagios.org/directory/Plugins/Operating-Systems/%2A-Virtual-Environments/
VMWare/Check-snapshots-age-and-number/details y lo copiamos con WinSCP o FileZilla a