• Author / Uploaded
• durii

• Categories
• Virtualización
• V Mware
• Violencia contra las mujeres
• Microsoft Exchange Server
• Microsoft Windows

Citation preview

#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: [email protected] 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.

Tipo 1

Tipos de hipervisor

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

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

A partir de la edición Essentials Plus Standard Essentials Plus Enterprise Plus Standard Enterprise Plus 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/vmwareformatos-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 [email protected].. 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 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á.  

Entorno Tiny Entorno Small Entorno Medium Entorno Large Entorno X-Large

No tener más hosts de

No tener más VM de

Número de vCPUs

Memoria

Default Storage Size

Large Storage Size

X-Large Storage Size

10

100

2

10 GB

250 GB

775 GB

1650 GB

100

1.000

3

16 GB

290 GB

820 GB

1700 GB

400

4.000

4

24 GB

425 GB

925 GB

1805 GB

1.000

10.000

16

32 GB

640 GB

990 GB

1870 GB

2.000

35.000

24

49 GB

980 GB

1030 GB

1910 GB

#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 WiFi 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

Protocolo Fibra

FCoE

iSCSI NFS

DAS *

Virtual Volumes vSAN

Compatibilidad con BFS

√ √ √

Compatibilidad con vMotion

√ √ √ √ √ √ √

Compatibilidad con HA

√ √ √ √ √ √

Compatibilidad con DRS

√ √ √ √ √ √

Compatibilidad con disco RAW

√ √ √

√

* 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

Multipath gestionado por ESXi

NFS v4.1

Multipath y trunk nativo

Autenticación AUTH_SYS (raíz)

Autenticación por Kerberos (opcional)

Control de errores en el cliente

Control de errores en el servidor

Bloqueo de archivo por VMware

Bloqueo de archivo integrado

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 HA

Si

Si

vSphere vMotion y vSphere Storage vMotion vSphere Fault Tolerance

vSphere DRS y vSphere DPM Stateless ESXi y Host Profile

vSphere Storage DRS y Storage I/O control Site Recovery Manager

vSphere Virtual Volumes

Si Si Si Si

Si Si Si Si

Si

No

Si

No

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 en su sistema informático, con vCenter y vSphere as a service.

Acceso inmediato a una infraestructura dedicada basada en los últimos procesadores de Intel.

Red mundial de fibra óptica con ancho de banda garantizado, tráfico ilimitado 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

SSD – NVMe

SSD – NVMe

Discos Capacidad

Mecánicos (SAS-SATA)

Uso Caché

70% Lectura 30% Escritura

Discos Caché

Deduplicación y Compresión Operaciones lectura

Recursos Red vSAN RAID 5/6

SSD – NVMe

100% Escritura*

No soportado

Soportado (vSAN Enterprise)

1Gbps – 10Gbps**

10Gbps o superior

Primero Caché No soportado

Principalmente capacidad 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.

Fallos a tolerar

Protección

0

RAID 0

1

RAID 5

1 2 2 3

RAID 1 RAID 1 RAID 6 RAID 1

Componentes Replica/Data

Objetos Witness

Erasure Coding vs Mirror

Mínimo de Hosts

2

1*

-

3

3

2*

4

3*

1 4 6

0

-

0

33% menos

0

50% menos

-

Tabla comparativa de opciones y métodos de protección

3 4 5 6 7

*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

Host en Mantenimiento

Absent

Host

Absent

Red (Host aislado)

Absent

Alcance fallo

Todos los componentes del Host

Todos los componentes del Host

Recreación A partir de los 60 minutos A partir de los 60 minutos

Todos los componentes del Host

A partir de los 60 minutos

Disk Group

Inmediatamente

Controladora

Degraded

Todos los discos del Host

Inmediatamente

Disco Capacidad (sin deduplicación)

Degraded

Componentes en disco

Inmediatamente

Degraded

Disk Group

Inmediatamente

Disco Caché

Disco Capacidad (con deduplicación)

Degraded

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 noncompliant, 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 Edition es el software de backup GRATUITO imprescindible para VMware, Hyper-V y Nutanix AHV, además de para servidores físicos Microsoft y Linux, estaciones de trabajo e instancias. Use el NUEVO Veeam Backup & Replication Community Edition para proteger hasta 10 VMs, o una combinación de VMs, instancias cloud, servidores físicos o estaciones de trabajo. Puede proteger parte de su entorno, su laboratorio 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.

Además de proteger 10 VMs, Veeam Backup & Replication Community Edition proporciona backups y migración de VMs GRATUITAS e ILIMITADAS manuales para más VMs, además de la 10 definidas, que también quiera proteger. Sin necesidad de desplegar agentes, consigue una solución flexible y fiable para hacer backup de VM GRATIS para l a gestión diaria de sus cargas de trabajo. Descargar ahora en http://vee.am/vbr-free

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.

Almacenamiento SAN Fibre Channel (FC) SAN iSCSI Storage NFS



Almacenamiento Local

Direct Storage Access Proxy físico con acceso directo a la SAN mediante FC. Proxy físico o virtual con acceso directo a la SAN mediante iSCSI. Proxy físico o virtual con acceso al Storage via NFS. No soportado

Virtual Appliance Proxy Virtual en ejecución sobre un host ESXi, con conexión al dispositivo de almacenamiento.

Network Mode Proxy físico o virtual conectado a los hosts ESXi mediante la interface de Management.

No recomendado Proxy Virtual en cada 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 Servidor Windows

#VMwarePorvExperts

Tipo de Almacenamiento Disco local, Almacenamiento conectado directamente, o LUNs conectadas vía iSCSI o FC.

Procesamiento de Datos El servicio Veeam data mover es desplegado cuando el servidor es añadido a Veeam Backup Server.

409

Capítulo 9 - Backup y Réplicas Patricio Cerda

Servidor Linux

Disco local, Almacenamiento conectado directamente, LUNs conectadas vía iSCSI o FC, o shares NFS.

CIFS (SMB) share

Share CIFS (SMB)

Appliance de Deduplicación

•

EMC Data Domain

•

ExaGrid

•

HPE StoreOnce

El servicio Veeam data mover service es desplegado cuando se ejecuta un Job que utilice dicho Repositorio. La transferencia de datos es llevada a cabo mediante el servicio Veeam Data Mover en el Gateway Server (Windows) La transferencia de datos es llevada a cabo mediante el servicio Veeam Data Mover en el Gateway Server (Windows), 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 Active full Forever Forward incremental Forward incremental Reverse incremental

#VMwarePorvExperts

Impacto en el Repositorio I/O 1 write I/O 3 I/O (1 I/O read + 2 I/O write) 1 write I/O 3 I/O (1 I/O read + 2 I/O write)

411

Capítulo 9 - Backup y Réplicas Patricio Cerda

Synthetic full Synthetic full with transform to rollbacks

2 I/O (1 I/O read + 1 I/O write) 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. dimensionamiento en el capítulo anterior.

Revisar el apartado de

•

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.

Unico socket de CPU Multiples sockets de CPU Numero de VMs. Tamaño de la Base de Datos Jobs Concurrentes 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 proteger todo su entorno vSphere

Recuperación garantizada con la verificación automática del backup

Comience a proteger sus maquinas en menos de 15 minutos con opciones de recuperación instantánea y granular

Opciones flexibles de backup como app-aware, incremental, políticas de programación y retención y muchas mas…

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

ID

ID

GID

Group ID

LWID

Leader Workload ID

NAME

Name

NWLD

Number of Workloads

%USED

Used

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, 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 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 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 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 grupo. NWLD es 1 cuando el Grupo es un único proceso, 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 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

%RUN

%SYS

#VMwarePorvExperts

Run

System

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 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 interrupciones y realizar otras actividades del sistema. Un %SYS alto normalmente significa un IO alto.

500

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

%WAIT

%VMWAIT

Wait

Virtual Machine Wait

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 (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 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

%IDLE

Idle

%OVRLP

Overlap

#VMwarePorvExperts

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á 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 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.

501

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

%CSTP

CoStop

%MLMTD

Max Limited

%SWPWT

Swap Wait

SWTCH/s

Switches/sec

MIG/s

Migrates/sec

QEXP/s

Quantum Expires/ sec

WAKE/s

Wakeups/sec

AMIN

Alloc Min

AMAX

Alloc Max

#VMwarePorvExperts

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 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 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á 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. 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 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 carga de trabajo que se está ejecutando actualmente. Es 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 segundo. Una carga de trabajo se despierta cuando su estado cambia de EN ESPERA a LISTO. Reserva de recursos, máquinas virtuales o atributos de carga de trabajo. Un valor de 0 significa que no hay reserva. Límite de atributos de recursos, máquina virtual o carga de trabajo. Un valor de -1 significa ilimitado.

502

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

ASHRS

Alloc Shares

AMLMT AUNITS

Alloc Min Limited Allocated unit

%LAT_C

Latency CPU

%LAT_M

Latency Memory

%DMD

Demand

EMIN

Effective Min

TIMER/s AFFINITY_BIT_ MASK

Timer/sec

CPU

CPU

HTSHARING

HT Sharing

HTQ

HT Quarantine

POWER

Power Usage Watts

Affinity Bit Mask

Grupo de recursos, máquina virtual o atributo de carga de trabajo Compartir. Las cuotas por defecto son -4 (Alta), -3 (Normal) y -2 (Baja). Cuando se configura una acción personalizada, se muestra el valor. Parámetro indocumentado. 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 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 programado para ejecutarse debido a la contención de recursos de memoria. La demanda de CPU en porcentaje. Representa el 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 trabajo recibirá cuando las máquinas virtuales compitan por los recursos. Tasa de temporizador para esta carga de trabajo. Máscara de bits que muestra la afinidad de programación actual para la carga de trabajo. El procesador físico o lógico en el que se ejecutaba la carga de trabajo cuando resxtop (o esxtop) obtuvo esta información. Configuración actual del hyperthreading. Indica si la carga de trabajo está actualmente en cuarentena o no. N significa no y Y significa sí. Consumo actual de energía de la CPU de una máquina 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

ID

ID

GID

Group ID

LWID

Leader Workload ID

NAME

Name

NWLD

Number of Workloads

AMIN

Alloc Min

AMAX

Alloc Max

ASHRS

Alloc Shares

AMLMT AUNITS

Alloc Min Limited Allocated unit

NHN

Numa Home Nodes

NMIG NRMEM NLMEM

#VMwarePorvExperts

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 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 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 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. Las máquinas virtuales no tienen un número añadido. El número de cargas de trabajo que se ejecutan en el Grupo. NWLD es 1 cuando el Grupo es un único proceso. Reserva de recursos, máquinas virtuales o atributos de carga de trabajo. Un valor de 0 significa que no hay reserva. Límite de atributos de recursos, máquina virtual o carga 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), -3 (Normal) y -2 (Baja). Cuando se configura una acción personalizada, se muestra el valor. Parámetro indocumentado. 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 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 Count Delta Numa Remote Cantidad de memoria remota asignada a la máquina Memory MBytes virtual. Numa Local Memory Cantidad de memoria local asignada a la máquina virtual. MBytes

504

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

N%L

Numa % Local

MEMSZ

Memory Size MBytes

GRANT

CNSM

SZTGT

TCHD

TCHD_W %ACTV %ACTVS %ACTVF %ACTVN MCTL?

#VMwarePorvExperts

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 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 = 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 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 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 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 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 MBytes la máquina virtual. Porcentaje de memoria física activa del huésped, valor Active Estimate actual. Porcentaje de memoria física activa del huésped, media Active Slow Estimate móvil lento. Porcentaje de memoria física activa del huésped, media Active Fast Estimate móvil rápido. Porcentaje de memoria física activa del huésped, predecir Active Next Estimate qué %ACTVF será en la próxima muestra. El controlador de memoria de ballon está instalado o no. Memctl? N significa no, Y significa sí. El controlador de ballooning forma parte de VMware Tools.

505

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

MCTLSZ

Memctl MBytes

MCTLTGT

Memctl Target MBytes

MCTLMAX

Memctl Max MBytes

SWCUR

Swapped MBytes

SWTGT

Swap Target MBytes

SWR/s SWW/s

Swap Read MBytes/ sec Swap Written MBytes/sec

LLSWR/s

Llswap Read MBytes/sec

LLSWW/s

Llswap Written MBytes/sec

CPTRD

Checkpoint Read MBytes

CPTTGT

Checkpoint Target MBytes

ZERO

Zero MBytes

SHRD

Shared MBytes

SHRDSVD COWH

#VMwarePorvExperts

Shared Saved MBytes Copy On Write Hint MBytes

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 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. Cantidad de memoria física que el sistema ESXi intenta recuperar de la máquina virtual por medio de ballooning. La cantidad máxima de memoria física que puede ser recuperada por el driver de ballooning. Uso actual de swap por parte de esta máquina virtual. Destino donde el host ESXi espera que esté el uso de swap por parte de la máquina virtual. Velocidad a la que el host ESXi intercambia la memoria del disco por la máquina virtual. Velocidad a la que el host ESXi intercambia la memoria 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 ESXi puede cambiar a una unidad SSD local, en lugar del 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 ESXi puede cambiar a una unidad SSD local, en lugar del 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 control. Los datos de un archivo de punto de control se leen cuando se reanuda una máquina virtual desde un estado suspendido. El tamaño del archivo del punto de control. El archivo de punto de control se utiliza cuando se suspende una 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 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 huésped. Cantidad de memoria física que se guarda debido al uso compartido de la página. Cantidad de páginas de sugerencias físicas para el uso compartido de páginas.

506

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

OVHDUW

Overhead UW MBytes

OVHD

Overhead MBytes

OVHDMAX MCMTTGT CMTTGT CMTCHRG CMTPPS CACHESZ CACHEUSD ZIP/s UNZIP/s

Overhead Max MBytes Min Commit Target MBytes Commit Target MBytes Commit Charged MBytes Commit Pages Per Share Compressed Memory MBytes Used Compressed Memory MBytes Compression MBytes/sec Decompression MBytes/sec

Cantidad de memoria de sobrecarga reservada para la carga de trabajo del usuario vmx. Cantidad de memoria de sobrecarga que consume actualmente la máquina virtual. Cantidad de memoria de recargo reservada para toda la máquina virtual.

Tamaño actual de la memoria comprimida por esta máquina virtual. Se utiliza memoria caché de compresión. Memoria comprimida por segundo. Memoria descomprimida por segundo.

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

ID

ID

GID

Group ID

VMNAME

Virtual Machine Name

VDEVNAME

Virtual Device Name

CMDS/s

Number of Virtual Disks Commands/sec

READS/s

Reads/sec

WRITES/s

Writes/sec

MBREAD/s

MBytes Read/sec

MBWRTN/s

MBytes Written/sec

LAT/rd LAT/wr

Read Latency Write Latency

NVDISK

Descripción El ID de disco SCSI virtual. El ID suele estar oculto y se muestra el ID de grupo, a menos que el grupo se amplíe con el comando “e”. Es el mismo ID que utiliza vscsiStats. El ID de grupo de la máquina virtual. El nombre para mostrar de la máquina virtual. Pulsaremos ‘N’ para ordenar por columna VMNAME. Nombre del dispositivo VSCSI. Sólo se muestra cuando el grupo se amplía con el comando “e”. Número de dispositivos VSCSI. Número de órdenes emitidas por segundo. Número de comandos de lectura emitidos por segundo. Presionaremos ‘r’ para ordenar por columna READS/s. Número de comandos de escritura emitidos por segundo. Presionaremos ‘w’ para ordenar por columna de ESCRITOS. Megabytes leídos por segundo. Pulse ‘R’ para ordenar por columna MBREAD/s. Megabytes escritos por segundo. Pulse ‘T’ para ordenar por columna MBWRTN/s. Latencia media (en milisegundos) por lectura. 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 DEVICE

Nombre Device

PATH/WORLD/ PARTITION

Path/World/Partition Id

NPH

Number of Paths

NWD

Number of Worlds

NPN

Number of Partitions

SHARES

Shares

BLKSZ NUMBLKS

Block Size (Bytes) Number of Blocks

DQLEN

Device Q Depth

WQLEN

World Q Depth

ACTV

Active Commands

QUED

Queued Commands

%USD

% Used

LOAD

Load

CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s RESV/s CONS/s

Commands/sec Reads/sec Writes/sec MBytes Read/sec MBytes Written/sec Reserves/sec Conflicts/sec

#VMwarePorvExperts

Descripción Nombre del dispositivo de almacenamiento. Esta columna sólo es visible cuando se amplía con “e” para Disk World Statistics, “P” para Disk Path Statistics o “t” para Disk Partition Statistics. Número de rutas de acceso al dispositivo de almacenamiento. Número de mundos que se ejecutan en el dispositivo de almacenamiento. Amplíe el dispositivo con el comando “e” para mostrar estadísticas de mundos individuales. Número de particiones en el dispositivo de almacenamiento. Número de acciones. Sólo se muestra cuando el dispositivo se expande con el comando “e” (Disk World Statistics). Tamaño de bloque del dispositivo en bytes. Número de bloques del dispositivo. Profundidad de la cola de dispositivos actual del dispositivo de almacenamiento. Profundidad de la cola de carga de trabajo. Este es el número máximo de comandos activos del ESXi VMkernel 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 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 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 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 profundidad de la cola. Esta estadística se aplica sólo a las cargas de trabajo y dispositivos. Número de órdenes emitidas por segundo. Número de comandos de lectura emitidos por segundo. Número de comandos de escritura emitidos por segundo. Megabytes leídos por segundo. Megabytes escritos por segundo.

509

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

DAVG/cmd

Average Driver MilliSec/Command

KAVG/cmd

Average Kernel MilliSec/Command

GAVG/cmd

Average Guest MilliSec/Command

FRESV/s ABRTS/s RESETS/s

Average Queue MilliSec/Command Average Driver MilliSec/Read Average Kernel MilliSec/Read Average Guest MilliSec/Read Average Queue MilliSec/Read Average Driver MilliSec/Write Average Kernel MilliSec/Write Average Guest MilliSec/Write Average Queue MilliSec/Write Failed Commands/ sec Failed Reads/sec Failed Writes/sec Failed Bytes Read/ sec Failed Bytes Written/ sec Failed Reserves/sec Aborts/sec Resets/sec

PAECMD/s

PAE Commands/sec

PAECP/s

PAE Copies/sec

SPLTCMD/s

Split Commands/sec

SPLTCP/s

Split Copies/sec

CLONE_RD CLONE_WR

VAAI Clone Reads VAAI Clone Writes

QAVG/cmd DAVG/rd KAVG/rd GAVG/rd QAVG/rd DAVG/wr KAVG/wr GAVG/wr QAVG/wr FCMDS/s FREAD/s FWRITE/s FMBRD/s FMBWR/s

#VMwarePorvExperts

Este es el tiempo promedio de respuesta en milisegundos por comando que se envía al dispositivo. El valor DAVG es parte de GAVG. Esta es la cantidad de tiempo que el comando pasa en el VMkernel. El valor de KAVG es parte de GAVG. Este es el tiempo de respuesta tal y como lo percibe el sistema operativo huésped. Este número se calcula con la fórmula: DAVG + KAVG = GAVG Latencia media de la cola por comando en milisegundos. Latencia de lectura media del controlador de dispositivo por operación de lectura en milisegundos. Promedio de latencia de lectura de ESXi VMkernel por operación de lectura en milisegundos. Latencia de lectura media del sistema operativo huésped por operación de lectura en milisegundos. Latencia media de lectura de la cola por operación de lectura en milisegundos. Latencia de escritura media del dispositivo por operación de escritura en milisegundos. Latencia de escritura media de ESXi VMkernel por operación de escritura en milisegundos. Latencia de escritura promedio del sistema operativo huésped por operación de escritura en milisegundos. Latencia media de escritura en cola por operación de escritura en milisegundos.

Número de comandos abortados por segundo. Número de comandos reseteados por segundo. Número de comandos PAE por segundo. Esta estadística se aplica sólo a las rutas. Número de copias PAE por segundo. Esta estadística se aplica sólo a las rutas. Número de comandos de división por segundo. Esta estadística se aplica sólo a las rutas. Número de copias divididas por segundo. Esta estadística se aplica sólo a las rutas.

510

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

CLONE_F MBC_RD/s MBC_WR/s ATS ATSF ZERO ZERO_F MBZERO/s DELETE DELETE_F MBDEL/s CAVG/suc CAVG/f AAVG/suc AAVG/f ZAVG/suc ZAVG/f

VAAI Clone Failed MBytes Clone Reads/sec MBytes Clone Writes/sec Atomic Test and Set Atomic Test and Set Failed Zeros Zeros Failed MBytes Zeroed/sec Delete Delete Failed Mbytes Delete/sec Average Success Latency ms/Clone Average Failure Latency ms/Clone Average Success Latency ms/ATS Average Failure Latency ms/ATS Average Success Latency ms/Zero Average Failure 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 PORT-ID UPLINK UP SPEED FDUPLX

USED-BY

TEAM-PNIC DNAME PKTTX/s

Nombre Port ID

Pulsaremos ‘N’ para ordenar por columna PORT-ID. Este puerto de switch virtual es un puerto de enlace Uplink? ascendente físico. N significa no, Y significa sí. Y significa que el enlace correspondiente está arriba. N 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 Link Speed (Mb/s) visible para los puertos de enlace ascendente. Y significa que el enlace correspondiente está operando 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 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 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 Device Name los switches virtuales o DvsPortset-# para switches distribuidos. Packets Transmitted/ Número de paquetes transmitidos por segundo. sec Pulsaremos ‘t’ para ordenar por columna PKTTX/s.

MbTX/s

MBits Transmitted/ sec

PSZTX

Average Packet Size Transmitted (Bytes)

#VMwarePorvExperts

Descripción El ID de puerto utilizado en el conmutador virtual. Este ID se utiliza, por ejemplo, para trazas de red con pktcap-uw.

MegaBits transmitidos por segundo.

Pulsaremos ‘T’ para ordenar por columna MbTX/s. Tamaño medio de los paquetes transmitidos en bytes.

512

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

PKTRX/s

Packets Received/ sec

MbRX/s

MBits Received/sec

PSZRX %DRPTX %DRPRX ACTN/s PKTTXMUL/s PKTRXMUL/s PKTTXBRD/s PKTRXBRD/s

Número de paquetes recibidos por segundo. Presionaremos ‘r’ para ordenar por columna PKTRX/s. MegaBits recibidos por segundo. Pulsaremos ‘R’ para ordenar por columna MbRX/s.

Average Packet Size Tamaño medio de los paquetes recibidos en bytes. Received (Bytes) % Outbound Packets Porcentaje de paquetes de transmisión perdidos. Dropped % Received Packets Porcentaje de paquetes de recepción eliminados. Dropped Número de acciones de Vmkernel publicadas por Actions Posted/sec segundo. Se trata de un contador interno de VMware sin más documentación. Multicast Packets Número de paquetes multicast transmitidos por segundo. Transmitted/sec Multicast Packets Número de paquetes multicast recibidos por segundo. Received/sec Broadcast Packets Número de paquetes de difusión transmitidos por Transmitted/sec segundo. Broadcast Packets 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 userid authhash privhash security

Descripción Reemplazar con vuestro username. Reemplazar con el valor hash de autenticación. Reemplazar con el valor hash de privacidad. Reemplazar con el nivel de seguridad para este usuario, que puede ser auth, 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: 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 hostname port userid secLevel

Descripción Reemplazar con el hostname o IP del sistema de monitorización que recibe las traps. Reemplazar con el puerto por el que el sistema de monitorización escucha. Si no ponemos ninguno se usará el puerto por defecto, 161. 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 ú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 userid

#VMwarePorvExperts

Descripción Reemplazar con vuestro username.

521

Capítulo 10 - Monitorización de vSphere Jorge de la Cruz

authhash privhash security

Reemplazar con el valor hash de autenticación. Reemplazar con el valor hash de privacidad. Reemplazar con el nivel de seguridad para este usuario, que puede ser auth, 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 hostname port userid

secLevel

message-type

Descripción Reemplazar con el hostname o IP del sistema de monitorización que recibe las traps. Reemplazar con el puerto por el que el sistema de monitorización escucha. Si no ponemos ninguno se usará el puerto por defecto, 161. 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 únicamente la autenticación, priv si hemos configurado autenticación y privacidad, y none si no hemos configurado ninguno. 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

vCPU RAM Disco Networking Controladora

Cantidad

4 8GB RAM 150GB (SAS o SSD) VMXNET3 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 = “[email protected]” 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 Servicios

Número de Hosts (estimados)

Número de Servidores

Central

Poller

< 500

50

1 Central

1 vCPU + 1 GB RAM

2000 - 7000

200 - 700

1 Central + 1 Poller

4 vCPU / 4 GB RAM

1 vCPU / 4 GB RAM

1 Central + 2 Pollers 4 vCPU / 8 GB RAM

2 vCPU / 4 GB RAM

500 - 2000

7000 - 14000

14000 - 21000

21000 - 28000

50 - 200

700 - 1400

1400 - 2100

2100 - 2800

1 Central

1 Central + 1 Poller

2 vCPU / 2 GB RAM

4 vCPU / 8 GB RAM

1 Central + 3 Pollers 4 vCPU / 8 GB RAM

2 vCPU / 4 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:

< 500

Número de Servicios

500 - 2000

2000 - 10000

10000 - 20000 20000 - 50000

50000 - 100000

#VMwarePorvExperts

10 GB 42 GB

126 GB 252 GB 660 GB 1.4 TB

/var/lib/mysql

2.5 GB

/var/lib/centreon

10 GB 30 GB 60 GB

150 GB 600 GB

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

Swap

Path

/ Centreon Central o Centreon Poller

/var/log

/var/lib/centreon

/var/lib/centreon-broker

/var/cache/centreon/backup Swap Servidor de BD

 

#VMwarePorvExperts

/

/var/log

/var/lib/mysql

/var/cache/centreon/backup

Tamaño

De 1 a 1,5 veces el tamaño de la Memoria RAM Al menos 20 GB Al menos 10 GB

Indicado en la tabla anterior Al menos 5 GB

Al menos 10 GB

De 1 a 1,5 veces el tamaño de la Memoria RAM Al menos 20 GB Al menos 10 GB

Indicado en la tabla anterior Al menos 10 GB

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-SOAPLite 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 cpu

SubComando usage

Uso de CPU en %

usage

Memoria RAM en %

usagemhz usagemb

mem

swap

overhead overall

memctl usage

net

receive send nic

aborted resets

io

read

write

kernel

device vmfs

queue

NOMBRE_DS con

health

storagehealth runtime

temperature sensor

maintenance status

issues

service

[nombre]

storage

lun

uptime device

#VMwarePorvExperts

adapter path cd/dvd

Descripción

Uso de CPU en Mhz Memoria RAM en MB

Memoria Swap en MB

Memoria Overhead en MB Memoria total en MB

Memoria Balloning en MB Trafico en KBps

Trafico Recibido en KBps Trafico Enviado en KBps Estado de las NIC

Comandos abortados Resets

Latencia de lectura en ms

Latencia de escritura en ms Latencia del kernel en ms

Latencia del dispositivo en ms Latencia de Queue en ms

Muestra espacio utilizado del datastore VMFS en MB Estado de Conexión Salud del host

Salud del almacenamiento Temperatura

Estado de sensores

Conocer si está en modo mantenimiento Estado general del host

Estado de la configuración del host

Estado de los servicios del host

Muestra los adaptadores de almacenamiento Muestra las unidades lógicas Muestra los paths Uptime

Lista MVs con dispositivos conectados

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: [email protected] 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 cpu

SubComando usage

usagemhz wait

ready

Memoria Swap en MB

swapin

swapout

overhead

active

Memoria Swap In en MB

Memoria Swap Out en MB Memoria Overhead en MB Memoria total en MB

Memoria Balloning en MB Memoria Activa

Trafico en KBps

send

Trafico Enviado en KBps

receive usage read

write state

status guest tools

#VMwarePorvExperts

Memoria RAM en MB

usage

con

runtime

CPU Ready en ms

swap

memctl

io

CPU Wait en ms

Memoria RAM en %

overall

net

Uso de CPU en Mhz

usage

usagemb

mem

Uso de CPU en %

Descripción

Trafico Recibido en KBps Uso del disco en MB/s

Lectura del disco en MB/s

Escritura del disco en MB/s Estado de Conexión

Estado de la MV (Encendida/apagada/suspendida) Estado general de la MV Estado del SO invitado

Estado de las VMware Tools

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-NameSNMP-custom’. En las macros con indicar el DISKNAME a ‘/’ nos bastará. Por recordar, una MV vCSA 6.x dispone de los siguientes discos

/boot

Punto de montaje

/tmp/mount SWAP

/storage/core /storage/log /storage/db

/storage/dblog /storage/seat

/storage/netdump

/storage/autodeploy storage/invsvc /dev/shm

/storage/imagebuilder /storage/updatemgr /storage/archive

#VMwarePorvExperts

Boot

Descripción

Directorio temporal Espacio Swap Core dumps

Logs del sistema BD de vPostgres

Logs de vPostgres

Donde se almacenan las estadísticas, eventos y tareas en vPostgres Volcados de red Netdump collector Repositorio de Auto Deploy

Servicio de inventario bootstrap y configuración de tomcat Memoria compartida

Repositorio de Image Builder

Almacén para Update Manager Archivado de vPostgres

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: vmafdd

vmware-cm

vmware-eam

vmware-sts-idmd

vmware-cis-license vpostgres

vmware-sca

vmware-vpxd

vmware-vpxd-svcs vmware-vsm vsphere-ui

vsphere-client

Proceso

Descripción

Servicio VMware Authentication Framework Servicio VMware Component Manager Servicio VMware ESX Agent Manager

Servicio VMware Identity Management Service Servicio VMware License Service Servicio VMware vPostgres

Servicio VMware Service Control Agent Servicio VMware vCenter Server

Servicio VMware vCenter-Services

Servicio VMware vService Manager Servicio VMware 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 authorized_keys

root@DIRECCION_IP_ESXi:/etc/ssh/keys-root/

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 nuestra máquina Centreon, lo hacemos ejecutable y lo movemos al directorio de los plugins de Centreon: chmod +x check_VM_snapshots mv check_VM_snapshots /usr/lib/centreon/plugins

Creamos el Comando en Centreon que vamos a utilizar para llamar a este script, indicamos la siguiente línea de comandos: $CENTREONPLUGINS$/check_VM_snapshots $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$

#VMwarePorvExperts

596

Capítulo 11 - Monitorización con Centreon Héctor Herrero

Pulsamos en “Describe arguments” e indicamos lo que significan; el ARG1 es el valor de Warning, indicando el número de Snapshots que encuentre, el ARG2 para cuando queremos que el número de snapshots encontrados nos alerte como Critical. Y el ARG3 son los días de antigüedad que permitimos que tengan los snapshots.

Y ahora ya podremos crear un Servicio que asociaremos a un host ESXi (al que hayamos configurado el fingerprint), seleccionamos el Comando creado en el paso anterior y acabamos cumplimentando los argumentos. Donde en este ejemplo los snapshots que tengan más de 7 días me alertarán con Warning si hay 1 o con Critical si hay 2 o más snapshots.

Tras grabar y exportar la configuración, si volvemos a la vista de Monitorización y buscamos el Servicio Snapshots creado, podremos verificar qué nos encuentra.

 

#VMwarePorvExperts

597

Capítulo 11 - Monitorización con Centreon Héctor Herrero

11. Visualizando con Grafana Si no nos es suficiente con las gráficas que nos da Centreon, podemos integrar nuestro Centreon con Grafana, podremos exportar los resultados de nuestro Centreon a una máquina con Graphite y visualizarlo con Grafana. Centreon (entre otros) permite exportar los datos que recolecciona a formato Base de Datos de Series Temporales (TSDB), pues gracias a ello, podremos almacenarlos en una Base de Datos de Graphite y con Grafana presentar esos datos en preciosos Dashboards. Grafana es una plataforma Open Source para crear nuestros propios cuadros de mando que permiten monitorizar nuestra infraestructura. Así que, nuestro Centreon monitorizará nuestra plataforma como hasta ahora, pero además, redireccionaremos las métricas que monitoriza a una BD remota, y Grafana podrá leer dicha información y así nosotros crear los Dashboard que nos interese. Os recuerdo que con Grafana no sólo podemos ver este tipo de información, que podemos explotar cualquier tipo de BD, ¿has pensado echarle un vistazo al ERP de tu empresa y hacer Dashboards? Ya habéis visto en el capítulo de ‘Monitorización de entornos vSphere’ de Jorge de la Cruz cómo se instala Grafana, así que esa parte la omitiremos, pero sí indicaremos los pasos necesarios para instalar Graphite, que bien puede ser instalado en la misma máquina de Grafana.

11.1 Instalación de Graphite Para instalar Graphite, utilizaremos el repositorio EPEL, si no lo tienes instalado, deberás hacerlo, e instalamos Graphite, además los paquetes necesarios: yum install -y epel-release yum install -y httpd graphite-web python-carbon perl

Inicializamos el interfaz de graphite y lo iniciamos ejecutando: /usr/bin/graphite-manage syncdb --noinput /usr/bin/graphite-build-index /usr/bin/chown -R apache:apache /var/lib/graphite-web systemctl start carbon-cache

#VMwarePorvExperts

598

Capítulo 11 - Monitorización con Centreon Héctor Herrero

Editamos el fichero de bienvenida ‘/etc/httpd/conf.d/welcome.conf’ y lo comentamos todo con almohadillas (#). También, modificaremos el fichero ‘/etc/httpd/conf.d/graphite-web.conf’ para permitir acceso desde cualquier IP: ##ServerName graphite-web

# Apache 2.4 Require all granted

# Apache 2.2 Order Deny,Allow Allow from all

Tenemos que añadir un par de reglas en el firewall para permitir el acceso externo al puerto de Graphite (2003), así como al acceso web, reiniciamos el firewall para que recargue la configuración: firewall-cmd --zone=public --permanent --add-service=http firewall-cmd --zone=public --permanent --add-port=2003/tcp firewall-cmd --reload

Recordar, para que los servicios arranquen al inicio con la máquina automáticamente, ejecutamos: chkconfig httpd on chkconfig carbon-cache on

Y reiniciamos el servicio httpd para recargar la configuración: systemctl restart httpd

Finalmente, podemos probar a abrir Graphite para ver si tenemos acceso y hemos hecho todo bien, veremos si el agente predeterminado si contiene algo de información, para ello no será más sencillo que abrir un navegador contra la dirección IP de la máquina CentOS, en este caso tan fácil como http:// DIRECCION_IP_MAQUINA_GRAPHITE y ver que estamos obteniendo datos.

#VMwarePorvExperts

599

Capítulo 11 - Monitorización con Centreon Héctor Herrero

11.2 Redireccionar output de Centreon a Graphite Ahora configuraremos que el Broker del Centreon escriba también los datos en Graphite, para ello deberemos seguir los siguientes pasos en la máquina donde tenemos instalado Centreon. Instalamos el plugin que necesitaremos en el Broker con: yum install -y centreon-broker-graphite

Desde la consola de Centreon, vamos a “Configuration” > “Pollers” > “Broker configuration” > “centralbroker-master” > Pestaña “Output” > En el combo del Output escogemos ‘Graphite – Storage – Graphite’ > “Add”, completamos los siguientes campos de la siguiente manera: •

Name: Graphite

•

DB host: DIRECCION_IP_MAQUINA_GRAPHITE

•

DB port: 2003

•

DB user:

•

DB password:

•

Metric naming: centreon.metric.$HOST$.$SERVICE$.$METRIC$

•

Status naming: centreon.status.$HOST$.$SERVICE$

Con esto indicamos a donde exportará la información que recolecta nuestro Centreon y en qué formato lo mandará a nuestro Graphite. Recordaremos que, tras cualquier cambio de configuración en Centreon, debemos grabar, exportar y recargar la configuración, para ello, por repasar, lo hacemos desde: “Configuration” > “Pollers” > “Export configuration” > Marcamos “Generate Configuration files” & “Run monitoring engine debug” &

#VMwarePorvExperts

600

Capítulo 11 - Monitorización con Centreon Héctor Herrero

“Move Export Files” & en Method seleccionamos “Restart” y pulsamos en “Export”. Por verificar y estar seguros, os recomiendo reiniciar estos dos servicios de Centreon desde su shell: service cbd restart service centengine restart

Si accedemos de nuevo a Graphite ya veremos cómo está almacenando las métricas que Centreon le va pasando, según vaya monitorizando nuestro Centreon, esto comenzará a alimentarse.

#VMwarePorvExperts

601

Capítulo 11 - Monitorización con Centreon Héctor Herrero

11.3 Creando el conector de Grafana a Graphite

En Grafana, tendremos que crear un origen de datos, en este caso indicaremos a Grafana que pueda leer los datos de una base de datos de tipo Graphite, desde “Configuration” > “Data Sources” > “Add data source”.

En este conector indicamos un nombre, indicamos en ‘Type’ que sea ‘Graphite’, y en la URL debemos indicar la dirección donde está instalado Graphite, si es la misma máquina que Grafana, con indicar ‘http://localhost’ bastará. Pulsamos sobre “Add”.

#VMwarePorvExperts

602

Capítulo 11 - Monitorización con Centreon Héctor Herrero

11.4 Creando el primer Dashboard

Y por fin podemos comenzar a dibujar y crear nuestros Dashboards con los datos de Centreon y visualizar las métricas y estados de nuestra plataforma virtual. Pulsamos en “New Dashboard” y vamos a añadir un Panel de tipo Graph de ejemplo para mostrar cómo manejarlo, sin código, sólo con el ratón.

Editamos el Panel recién añadido, “Edit”,

En la pestaña “Metrics” añadimos el Data Source que acabamos de crear llamado Centreon, y en las Series bastará con ir añadiendo lo que queremos visualizar. Vamos seleccionando y añadiendo con el ratón lo que nos interese, ‘Centreon’ > ‘Metric’ > ‘Nombre MV’ > ‘Servicio monitorizado’ > ‘métrica obtenida’.

#VMwarePorvExperts

603

Capítulo 11 - Monitorización con Centreon Héctor Herrero

Y bueno, es cuestión de ir añadiendo series de ítems que queramos visualizar y luego en el resto de menús definir el formato de lo que estamos visualizando, cambiar la vista a columnas, puntos o líneas entre otros. A parte de Paneles de tipo Graph, podemos también mostrar únicamente los valores obtenidos, adornarlos con un acelerómetro, utilizar paneles tipo quesito, etc… Verás que es un interfaz super intuitivo y sencillo de usar, podrás en pocos minutos crear los Dashboards que te interesen y visualizar los datos en tiempo real.

¡Verás que Dashboards chulos generas con los datos que monitorizamos desde Cetreon! Podrás crear tantos Dashboards como necesites y posteriormente crear Play Lists para reproducirlos desde una TV y que vaya cambiando de Dashboard cada X tiempo. Recordar, por último, que podremos exportar en PDF los Dashboards y enviarlos programados por correo electrónico de forma totalmente automática.

#VMwarePorvExperts

604

Capítulo 11 - Monitorización con Centreon Héctor Herrero

12. Visualizando con NagVis Vamos a integrar en nuestro Centreon una capa de visualización de mapas o dibujos interactivos, no es más que llevar los ítems monitorizados a dibujos vivos totalmente customizados, sean dibujos de esquemas lógicos, de fotos del CPD, de tráficos SAN, de nuestras máquinas virtuales… de lo que nos dé la imaginación.

12.1 Instalación requisitos previos Bajamos a la shell de nuestro Centreon, debemos actualizar gcc a la versión 4.7 si es que no lo tenemos ya, además de añadir y actualizar variables: sudo wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo -P /etc/yum.repos.d sh -c ‘echo “enabled=1” >> /etc/yum.repos.d/devtools-1.1.repo’ yum install devtoolset-1.1 scl enable devtoolset-1.1 bash gcc --version export CC=/opt/centos/devtoolset-1.1/root/usr/bin/gcc export CPP=/opt/centos/devtoolset-1.1/root/usr/bin/cpp export CXX=/opt/centos/devtoolset-1.1/root/usr/bin/c++

Y añadimos en ‘~/.bash_profile’: export PATH=/opt/centos/devtoolset-1.1/root/usr/bin/:$PATH

Instalaremos MK Livestatus para acceder en tiempo real al estado de los objetos de nuestro Centreon, será un requisito de NagVis para obtener la información y pintarla al momento: yum install gcc-c++ cd /tmp/ wget ‘http://www.mathias-kettner.de/download/mk-livestatus-1.2.8.tar.gz’ tar xzf mk-livestatus-1.2.8.tar.gz cd mk-livestatus-1.2.8 ./configure && make mkdir /usr/lib64/centreon-engine/bin cp /tmp/mk-livestatus-1.2.8/src/livestatus.o /usr/lib64/centreon-engine/bin/

#VMwarePorvExperts

605

Capítulo 11 - Monitorización con Centreon Héctor Herrero

12.2 Configuración en Centreon

Desde de Centreon, vamos a “Configuration” > “Pollers” > “Engine configuration”, pestaña “Data”, agregamos un nuevo módulo pulsando en “+ Add a new entry” y añadimos: /usr/lib64/centreon-engine/bin/livestatus.o /var/lib/centreon-engine/rw/live

Grabamos y exportamos la configuración de Centreon tras modificar esta configuración, reiniciando los servicios y recargando la configuración, como ya sabemos.

12.3 Instalar Backend NagVis Comenzamos por fin con la instalación del backend de NagVis en nuestro appliance de Centreon… comenzamos con los pasos necesarios para descargarlo e instalarlo: cd /tmp/ wget http://www.nagvis.org/share/nagvis-1.9.11.tar.gz tar zxfv nagvis-1.9.11.tar.gz cd nagvis-1.9.11 ./install.sh

Arranca el asistente de instalación de NagVis, deberemos responder correctamente las preguntas que nos haga: Do you ... Please ... Please ... Do you .. Do you ... Do you ... Please ...

want to proceed? [y]: y enter the path to the nagios base directory [/usr/local/nagios]: /usr/lib/centreon enter the path to NagVis base [/usr/local/nagvis]: /usr/lib/nagvis want to use backend mklivestatus? [y]: y want to use backend ndo2db? [n]: n want to use backend ido2db? [n]: n enter your MKLivestatus socket: unix:/var/lib/centreon-engine/rw/live

#VMwarePorvExperts

606

Capítulo 11 - Monitorización con Centreon Héctor Herrero

Please enter the web path to NagVis [/nagvis]:/nagvis ... Please enter the name of the web-server user [apache]: apache ... Please enter the name of the web-server group [apache]: apache ... Create Apache config file [y]: ... +------------------------------ -------------------------+ | Summary | +--------------------------------------------------------+ | NagVis home will be: /usr/lib/nagvis | | Owner of NagVis files will be: apache | | Group of NagVis files will be: apache | | Path to Apache config dir is: /etc/httpd/conf.d | | Apache config will be created: yes | | | | Installation mode: install | | | | Do you really want to continue? [y]: y | ...

Y tras finalizar ya nos indicará que ha finalizado de una manera satisfactoria. Si necesitamos modificar algo, el fichero de configuración será: ‘/usr/lib/nagvis/etc/nagvis.ini.php’. Reiniciamos apache para que recargue la configuración: /etc/init.d/httpd restart

Y ya podremos entrar a NagVis. Probamos a acceder vía web a mediante la URL: http://SERVIDOR_ CENTREON/nagvis. Por defecto tendremos el usuario admin con la contraseña admin.

#VMwarePorvExperts

607

Capítulo 11 - Monitorización con Centreon Héctor Herrero

12.4 Creando un mapa vivo del Entorno Virtual

Tras acceder a NagVis, ya podremos crear nuestro primer mapa, pero, antes de nada, tenemos que dibujar la imagen que queremos animar, usaremos Visio, Photoshop… Por poner esta imagen de ejemplo, donde tenemos nuestras MVs y hosts de una empresa ficticia. Tenemos que subir la imagen de fondo que vamos a usar con el mapa. Desde NagVis, vamos a “Option” > “Manage Backgrounds” y subimos el fichero jpeg.

Para crear un mapa, será tan sencillo como ir a “Options” > “Manage Maps” > “Create Map”, ponerle un nombre y asociarle la imagen de fondo que usará. Creará un mapa totalmente vacío al que le iremos añadiendo iconos, líneas u objetos especiales que leerá de los Servicios monitorizados en Centreon. ¡Comenzamos a animar el mapa! Algo muy sencillo, poner iconos de estados, para ello, desde “Edit Map” > “Add Icon” > “Service” los iremos añadiendo. El cursor del ratón nos cambiará y se nos pondrá una cruz, deberemos pulsar en la zona del dibujo donde queramos añadirlo.

#VMwarePorvExperts

608

Capítulo 11 - Monitorización con Centreon Héctor Herrero

Y nos saltará una ventana emergente de qué queremos añadir, en este ejemplo, estoy añadiendo el Servicio monitorizado llamado CPU del host ESXi, por tanto, lo buscamos en los combos y lo añadimos, grabamos con “Save”. Y ya tendremos nuestro primer objeto añadido. Vemos que el mapa está en Modo Edición, por lo que podremos seguir añadiendo o modificando objetos tranquilamente, lo más rápido para seguir y crear objetos similares, será clonarlos y colocarlos donde los queramos de nuevo, tras ello lo modificaremos e indicaremos a qué otro Servicio corresponde este nuevo objeto.

Tras un rato de trabajo tendremos nuestro primer mapa listo, en este caso vemos que he añadido 2 hosts de ESXi y 4 máquinas virtuales de la monitorización de Centreon, donde veremos de un vistazo su estado, o si el rendimiento se ve afectado, con este tipo de dibujos podemos orientarnos. Al pasar el ratón sobre cada Objeto añadido veremos el estado del resumen de dicho servicio monitorizado. Ya sólo nos queda crear pools de imágenes que cambien cada X segundos y poner una TV en el despacho para demostrar lo bien que tenemos controlado el entorno.

#VMwarePorvExperts

609

Capítulo 11 - Monitorización con Centreon Héctor Herrero

#VMwarePorvExperts

610

Capítulo 12 VDI con Horizon View

Ricard Ibáñez

#VMwarePorvExperts

612

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

1. Introducción Este capítulo, está dedicado a la plataforma de virtualización de escritorios VMware Horizon y no lo plantearemos de una manera tradicional, describiendo cada componente y función. Intentaremos realizar un planteamiento más propio de proyecto de implantación en una empresa, consiguiendo una aproximación a las dudas y procedimientos que seguiríamos en un despliegue de esta tecnología. El tema del capítulo lo estructuraremos en varios apartados según las necesidades más comunes, planteadas en un despliegue de Horizon. Estas decisiones no tienen por qué llevarse al 100% de las empresas donde se plantea una infraestructura de escritorios virtuales, pero intentaremos plantear situaciones para poder ver la gran cantidad de posibilidades que nos ofrece VMware con Horizon.

#VMwarePorvExperts

613

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

2. Descripción del proyecto Como en la mayoría de los proyectos tenemos que realizarnos varias preguntas y resolverlas antes de empezar cualquier fase de la implantación.

2.1 Necesidades Una de las principales necesidades, es mantener un elevado número de equipos disponibles, para los usuarios que trabajan por turnos, es decir, el mismo equipo que por la mañana está usando un usuario, por la tarde deberá usarlo otro. Además, hay que evitar que un equipo esté vinculado a un usuario concreto, para facilitar la movilidad de posición en caso de trabajar por proyectos. Otra necesidad, es que los responsables de departamentos dispongan de un equipo fijo, con el que tengan la garantía de que los datos siempre estará disponibles y solo tendrás acceso ellos. También tendrán aplicaciones distintas a los equipos de usuarios mencionados anteriormente. Algo que se valora es que el equipo de sistemas tenga la capacidad de gestionar sus equipos con total libertad a la hora de instalar o configurar aplicaciones, además de poder ampliar las capacidades del equipo en caso necesario. Toda esta infraestructura deberá tener alta disponibilidad en un solo centro de datos, para garantizar el acceso y los datos de todos los usuarios.

2.2 Propuestas 2.2.1 Infraestructura La principal propuesta es montar una infraestructura redundada a nivel de acceso a los escritorios, lo cual nos llevará a disponer de dos Connection Servers para balancear las conexiones y en caso de caída de uno de los dos, disponer de un servidor activo para que los usuarios sigan trabajando. Un requisito a la hora de montar escritorios Linked Clone es el Composer, el cual, almacenará la base de datos de relaciones de clones de escritorios virtuales y la VM Base. Además, esta base de datos la usaremos también para almacenar los Eventos de la plataforma Horizon.

2.2.2 Escritorios trabajadores Para cumplir con las necesidades se plantea un sistema de escritorios virtuales con Instant Clone, los cuales facilitan un rápido despliegue y un reaprovechamiento de los recursos en el sistema de turnos de los trabajadores.

#VMwarePorvExperts

614

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

2.2.3 Escritorios responsables Los escritorios virtuales de responsables se implementarán con el sistema Linked Clone, el cual permite mantener equipos asignados de manera individual para cada usuario con su espacio de almacenamiento directo en el escritorio virtual, todo esto sin perder la facilidad de despliegue y actualizaciones.

2.2.4 Escritorios IT Los escritorios virtuales que requieren mayor flexibilidad serán los del departamento de sistemas, por lo que crearemos escritorios virtuales clonadas y sin gestión de actualizaciones centralizadas, por lo que cada escritorio será independiente.

2.2.5 Despliegue de aplicaciones Para poder facilitar el despliegue de aplicaciones según las necesidades, tendremos varias opciones. Algunas aplicaciones las instalaremos sobre la plantilla que usaremos para generar escritorios, por lo que cualquier actualización requerirá el despliegue de la plantilla de nuevo. Otras las facilitaremos mediante un servidor RDS para centralizar su aprovisionamiento y actualizaciones. Por último, usaremos el sistema App Volumes para asignar aplicaciones a los escritorios de manera instantánea, consiguiendo una gran flexibilidad a la hora de desplegar aplicaciones.

2.2.6 Gestión de perfiles Para controlar los perfiles de todos los usuarios, usaremos User Environment Manager (UEM), el cual nos permitirá guardar las configuraciones de ciertas aplicaciones para que el usuario las mantenga independientemente del escritorio donde se ejecuta. Además, podremos substituir algunas de las configuraciones típicas de Windows GPO por configuraciones en UEM.

 

#VMwarePorvExperts

615

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3. Infraestructura La infraestructura necesaria para poner en marcha Horizon es muy básica, basta con implementar un solo servidor llamado Connection Server y ya podemos generar escritorios virtuales y conectarnos con el Horizon Client o desde la propia web con HTML5. Si bien, es muy sencillo implementarlo, vamos a complicar un poco el diseño para tener en cuenta factores de redundancia de los Connection Server, así como aprovechar características que nos beneficiaran a la hora de aprovisionar escritorios. Algo muy importante que tenemos que revisar es la matriz de compatibilidad de VMware, la cual nos detallará si nuestra plataforma vSphere es compatible a nivel de versiones con la infraestructura de Horizon que vamos a implementar y sobre todo que versiones de MS SQL Server están soportadas para cada versión. Docu VMware - VMware Product Interoperability Matrices https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&260=

3.1 Diseño Lo primero que veremos es un esquema del diseño de los servidores y servicios para redundar nuestra plataforma. En este diseño veremos servicios que se explicarán con más detalle en las siguientes páginas.

#VMwarePorvExperts

616

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.1.1 Connection Servers Este servicio actuará como bróker de las conexiones entre clientes y escritorios virtuales, controlando la autenticación mediante los usuarios de Active Directory. Como podemos ver en el diseño, este servicio es el centro de la infraestructura, por lo que como mínimo, en una implementación como la que queremos llevar a cabo, instalaremos dos servidores. El proceso de instalación del primer Connection Server y del segundo es distinta, pues el segundo se instalará como réplica del primero. El sistema que utiliza Horizon para replicar configuraciones entre dos o más Connection Server es una base de datos LDAP, similar a la que usamos para Active Directory, por lo que cualquier cambio realizado sobre un Connection Server es inmediatamente enviado a los otros Connection Server. Una vez desplegados los servidores, tendrán el mismo peso a la hora de gestionar conexiones, todo dependerá del balanceo de conexiones. Este balance de conexiones es muy importante para dar siempre acceso a nuestros usuario y un método muy simple es usar el propio balanceador de Windows Server (NLB), que viene incorporado como una característica del SO, el problema es que tendremos poco control sobre el uso y disponibilidad de los Connection Servers en cuanto a monitoreo del tráfico se refiere, por lo que es recomendable usar una balanceador externo con mejores características.

#VMwarePorvExperts

617

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu www.cenabit.com - Balancear las conexiones en Horizon View https://www.cenabit.com/2018/06/balancear-las-conexiones-en-horizon-view/

Instalación del primer Connection Server El proceso de instalación es muy sencillo y tan solo debemos respetar los requisitos mínimos en hardware y versiones. Docu VMware - Requisitos del servidor de conexión de Horizon https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E1B927CD-20A147B5-B613-BB9F1A4B58CB.html

Al ser el primer servidor Connection Server que instalamos, debemos selecciona la opción Servidor estándar de Horizon 7, también marcaremos la opción de HTML Access, de este modo conseguimos que el servidor acepte estas peticiones y luego ya controlaremos el acceso de los clientes mediante la configuración en el Pool.

#VMwarePorvExperts

618

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Introducimos una clave de recuperación para poder restaurar el Connection Server de una copia de seguridad automática.

El Connection Server utiliza unos puertos concretos para comunicarse con los Horizon Client, vCenter y demás elementos de la infraestructura. Es ideal que sea el propio instalador quien se encargue de abrir esos puertos sobre el Firewall de Windows para no tener que realizar configuraciones manuales.

#VMwarePorvExperts

619

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Por último, especificaremos el usuario o grupo Administradores de Horizon. Esta configuración la podremos editar más adelante dentro del portal de administrador de Horizon.

Instalación del segundo Connection Server La instalación del segundo Connection Server difiere muy poco del proceso realizado sobre el primer servidor. La ventana más significativa es en el momento de elegir el tipo de instancia de servidor, que seleccionaremos Horizon 7 Replica Server y también con la opción de HTML Access.

#VMwarePorvExperts

620

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Como es lógico deberemos establecer cuál es el Connection Server del que haremos réplica, por lo que introducimos, preferiblemente, el FQDN de nuestro primer servidor.

3.1.2 Composer Server El servicio de Composer no es un elemento necesario dentro del uso de Horizon, es decir, podemos trabajar con una plataforma de Horizon sin este componente, pero esto impedirá usar la tecnología de Linked Clone. La tecnología que encontramos detrás de Linked Clones, nos permite reducir considerablemente el espacio ocupado por cada escritorio virtual comparado con las clonaciones completas de VMs y reduce mucho el tiempo de aprovisionamiento. Además, nos dará mucha flexibilidad para actualizar todos los escritorios con poco esfuerzo, Windows Update, actualizar aplicaciones o incluso cambiar de SO.

Instalación Composer Server Antes de empezar a instalar el servicio, debemos saber que este servicio requiere de una base de datos SQL y en la versión que está escrita este libro Horizon 7.7, solo tenemos disponibles, Oralce 12C Standard o MS SQL Server en varias de sus versiones. Nota. Debéis comprobar esta matriz de compatibilidad antes de poner en marcha el servicio de Composer, así garantizamos el soporte por parte de VMware. https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db&260=3002

Será necesario tener la consola de SQL Management para acceder a la instancia y crear la base de

#VMwarePorvExperts

621

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

datos para el servicio de Composer. Como podéis observar en la imagen debemos crear una base de datos de Composer y otra, que usaremos más adelante para los eventos de Horizon.

Ahora en el mismo servidor donde instalaremos el servicio Composer, debemos crear un conector ODBC a nivel de Sistema, para usarlo en la instalación del servicio.

#VMwarePorvExperts

622

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Con los pasos previos finalizados, podemos empezar a instalar nuestro servicio de Composer.

Ahora configuraremos el conector que hemos creado anteriormente para que nuestro servicio de Composer pueda conectarse a la base de datos.

#VMwarePorvExperts

623

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Confirmaremos el puerto de comunicación y si no tenemos ningún certificado instalado, se generará un certificado autofirmado para la comunicación entre los Connection Server y el Composer.

#VMwarePorvExperts

624

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.2 Configuración

Docu VMware - Iniciar sesión en Horizon Administrator https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-55BDE139-3E494C8C-B6D6-D9840BF785DA.html

Antes de empezar a pensar en la creación de Pools de escritorios virtuales, debemos configurar nuestra plataforma de Horizon View. Por ello, lo primero que vamos a hacer es acceder al portal de administración y esto lo conseguimos entrando por https a nuestro servidor con /admin. Por ejemplo, https://Viewcon01.librovmware.com/ admin o si accedemos desde el propio servidor https://localhost/admin. Como es de esperar, recibiremos un error de certificado porque todavía estamos operando con certificados autofirmados que no son reconocidos por los equipos como certificados válidos.

3.2.1 Licencia Docu VMware - Instalar la clave de licencia del producto https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-822318BC-132A463C-904C-6E4F8DBF60DB.html

Debemos introducir la licencia adquirida que podemos sacar de nuestra página de https://my.vmware. com. Una vez cargada se habilitarán las opciones vinculadas a nuestra licencia.

#VMwarePorvExperts

625

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.2.2 Grupo administradores de Horizon Docu VMware - Funciones y privilegios predefinidos https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-CA6A24E5B7C6-4E72-96B8-69B70563DDFE.html

En el proceso de instalación hemos definido un usuario como administrador y es el momento que ampliemos el número de usuario administradores de View o añadamos un grupo pensado para tal fin.

Es importante saber que Horizon, permite establecer distintos roles sobre la plataforma en función del acceso necesario para cada tipo de usuario. En organizaciones pequeñas donde existen pocos administradores, es ideal tener acceso total, pero podemos establecer roles de solo lectura o de gestión de Pools.

3.2.3 Permitir Pools de Windows Server Docu VMware - Configuración global de las sesiones cliente https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-897724CACFCD-4030-8597-CC57EAB25D68.html

Veremos más adelante que podemos generar Pools con Windows versión cliente o servidor, pero si nos lanzamos rápidamente a crear un Pool con Windows Server en Horizon View, no conseguiremos encontrar nuestra VM Base para aprovisionar escritorios virtuales. Esto es debido a que por defecto está deshabilitado y podemos activarlo desde la Configuración Global.

#VMwarePorvExperts

626

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.2.4 Base de datos de eventos Docu VMware - Configurar la base de datos de eventos https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E04FDAC2-AD7B4B09-B6E0-4A541646869B.html

Como vimos en el proceso de la configuración de SQL Server, creamos una base de datos llamada VIEW-Event. Este es el momento donde conectaremos nuestro Horizon, con esta base de datos, para poder almacenar los eventos generados y diagnosticar y controlar nuestra infraestructura. Esta configuración es recomendable, pero no imperativa, es decir, si perdemos comunicación con nuestra base de datos, la plataforma seguirá trabajando con normalidad. Una cuestión muy importante es que no podemos usar usuarios con Integración de Autenticación de Windows, sino que debemos usar usuario locale del SQL. También debemos asegurarnos de abrir el puerto 1433, en el servidor SQL, o el que nosotros queramos

#VMwarePorvExperts

627

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

usar para la comunicación de los Connection Server contra esta base de datos.

3.2.5 Conectar con vCenter Docu VMware - Agregar instancias de vCenter Server a Horizon 7 https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-F8210848-BBF94943-BCD8-75E7F5AEFEE8.html

Tenemos la infraestructura de Horizon instalada, pero falta una parte fundamental para poder usarla y es una plataforma vSphere donde poder generar los escritorios virtuales. Antes de añadir un vCenter, debemos preparar nuestro vSphere para poder configurarlo adecuadamente. Lo más habitual es encontrar instalaciones realizadas con el usuario Administrator, tanto de vSphere como de Active Directory, pero no es la mejor solución. Debemos prestar atención a los requerimientos de nuestro entorno para conectar la plataforma Horizon con vCenter. Docu VMware - Privilegios necesarios para el usuario de vCenter Server https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-A878F876-B35942FC-9124-A1E34BFB3319.html

Si no queremos complicar la gestión de los permisos entre las dos plataformas y vamos a usar Control Total de nuestro vCenter, lo que, si debemos hacer, como buena práctica, es crear un usuario dedicado a Horizon. La razón es muy simple, de repente, vemos multitud de migraciones de VMs en nuestro vCenter y si el causante es la infraestructura de Horizon, podremos reconocer esas migraciones por el usuario que las ejecuta.

#VMwarePorvExperts

628

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Para añadir el vCenter a nuestro Horizon usaremos el FQDN, ya que una vez creada la instancia de vCenter en nuestra plataforma no se puede modificar. Si que podremos modificar el usuario de conexión y lo valores máximos de operaciones.

En la misma creación de la instancia de vCenter podremos añadir la configuración de nuestro servidor Composer, si es que nuestra infraestructura lo usa.

Por último, añadiremos el dominio de Active Directory sobre el que operará nuestro Composer, para poder generar y eliminar equipos. Es muy importante que el usuario que conectamos tenga esos permisos sobre nuestro Active Directory.

#VMwarePorvExperts

629

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu VMware - Create a User Account for View Composer AD Operations https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-3446495C-FEC8425C-AFF8-A6CAABA5E973.html

3.2.6 Añadir dominio para Instant Clone Docu VMware - Agregar un administrador de dominio de clones instantáneos https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-5E513495-450B4C2E-A353-A2B45071BDC7.html

Como tenemos previsto usar nuestra infraestructura con tecnología Instant Clone, es el momento de configurar un usuario del dominio para poder operar con nuestro Active Directory, del mismo modo que pasa con el servicio de Composer.

#VMwarePorvExperts

630

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Es importante revisar que permisos requerirá este usuario para operar con nuestro Active Directory. Docu VMware - Crear una cuenta de usuario para operaciones de clones instantáneos https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E91881F4-F8C048A5-A1A4-61577E287E29.html

3.2.7 Instalar certificado Hasta ahora toda la plataforma trabaja con certificados autofirmados por cada uno de los servidores que hemos instalado. Sin tener tan en cuenta los certificados internos de comunicación como vCenter, Composer, etc… Sí que es importante establecer un certificado de acceso para los usuarios. Si estamos pensando en una infraestructura de producción, no deberíamos dejar el acceso a los Connection Server mediante los nombres de las VMs, por lo que deberíamos establecer un nombre para el acceso, por ejemplo, vdi.librovmware.com, sobre este nombre podremos adquirir un certificado de una entidad emisora para validar las conexione SSL sin el molesto error de certificado y garantizando la integridad de la comunicación. También podemos usar una CA propia para poder usar nombres internos, ya que las entidades certificadoras públicas, solo emiten certificados a dominios públicos. Para poder generar una solicitud de certificado y enviarlo a nuestra entidad certificadora favorita, debemos seguir los pasos que nos indica VMware en esta KB. Docu VMware - Using Microsoft Certreq to generate signed SSL certificates in VMware Horizon View https://kb.vmware.com/s/article/2032400

Este proceso, solo se realizará sobre uno de los Connection Server y una vez lo tengamos instalado,

#VMwarePorvExperts

631

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

lo exportaremos con Clave Privada y lo instalaremos en el resto de Connection Servers, renombrando el certificado autofirmado.

Docu www.cenabit.com - Instalación certificado Wildcard en Horizon View https://www.cenabit.com/2016/03/instalacion-certificado-wildcard-en-horizon-view/

3.3 Conexiones

Docu VMware - Network Ports in VMware Horizon 7 https://techzone.vmware.com/resource/network-ports-vmware-horizon-7

En todo el diseño no hemos hablado de las necesidades de redes, como podemos suponer, cuando hablamos de distintos productos conectados entre sí, sobre una misma red para dar lugar a una infraestructura, es muy importante saber que protocolos y puertos necesitan para comunicarse. Para no repasar toda la documentación de red de Horizon, vamos a comentar lo dos aspectos más importantes a nivel de conexión, que son de qué manera daremos acceso a nuestros clientes sobre los escritorios, con conexión a través de túnel o no.

#VMwarePorvExperts

632

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu VMware - Configurar el túnel seguro y la puerta de enlace segura PCoIP https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-7FB5BEBA2C20-47B9-94A9-A19C70D8BB66.html Docu VMware - Configurar la puerta de enlace segura Blast https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-C075A0DB0F59-4CD9-A329-CAF49E93E8DD.html

3.3.1 Conexión tunelizada Cuando hablamos de conexión tunelizada, nos referimos a la centralización del canal de conexión entre nuestros Horizon Client y los escritorios virtuales, pasando en todo momento por los servidores Connection Server. Esta configuración permite evitar la visibilidad de la red de clientes con la red de escritorios virtuales, ya que todo pasa por la red de los Connection Server.

Como podemos observar en el diagrama, al controlar todo el acceso a los escritorios a través de los servidores, cuando uno de esto servidores se apaga, todas las conexiones que gestiona se detienen, teniendo como resultado la desconexión de escritorios virtuales, por lo que los usuarios deberán volver a lanzar la conexión para realizar el túnel por otro Connection Server que esté disponible. Además, para evitar problemas de certificados, deberemos establecer la URL en la configuración de

#VMwarePorvExperts

633

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

cada uno de nuestro Connection Servers para que respondan correctamente a las peticiones de los usuarios.

3.3.2 Conexión no tunelizada A diferencia del anterior método de conexión de nuestro Horizon Clients, cuando consideramos una conexión no tunelizada, lo que debemos hacer es permitir el acceso desde los Clientes, tanto a los servidores, como a los escritorios de manera directa.

#VMwarePorvExperts

634

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Este diseño, requiere de los Connection Server solo en el momento de establecer la conexión entre cliente y escritorio virtual, una vez esta comunicación se ha establecido, el Connection Server ya no realizar ninguna operación más, a nivel de conexión. Por tanto, en el caso de caída de un Connection Server, ningún usuario se verá afectado, si ya está establecida la conexión. Este escenario, como deducimos es mucho más robusto a nivel de fallos, pero más “inseguro” a nivel de conexiones. Para configurar este escenario, lo que debemos hacer es desactivar los túneles de los Connection Servers.

#VMwarePorvExperts

635

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

En el caso del protocolo Blast hay que tener en cuenta que si usamos HTML y no tunelizamos las conexiones, cuando accedamos, nos dará un error de conexión el propio escritorio virtual, ya que estamos accediendo directamente a una VM de manera directa mediante IP, lo cual no tiene un certificado válido. Para evitar este problema, existe la opción de solo tunelizar el protocolo Blast cuando la conexión sea sobre HTML, consiguiendo mayor flexibilidad de acceso (HTML y Horizon Client) sin problemas de certificados y conexiones.

3.4 Consola de administración Todavía no hemos generado escritorios virtuales, ni Pools, ni aplicaciones, pero aprovecharemos el acceso a la consola de administración para dar un repaso a ciertos aspectos que deberemos tener en cuenta.

3.4.1 Dashboard Desde el Panel del portal de administración, podremos ver la salud de nuestra infraestructura, así como el espacio libre y ocupado de los Datastores y el estado de los escritorios o sesiones publicadas.

#VMwarePorvExperts

636

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.4.2 Users and Groups Como es de esperar deberemos poder asignar autorizaciones a los usuario o grupos para acceder a determinado Pool de escritorios o aplicaciones y desde esta consola podremos controlar todas estas asignaciones.

3.4.3 Desktop Pools Esta ventana de administración nos permite crear los Pools de escritorios virtuales, además de ofrecernos todos los datos relacionados con cada uno de los Pools e incluso poder editar las configuraciones del Pool y también las asignaciones.

#VMwarePorvExperts

637

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.4.4 Application Pools Podremos asignar aplicaciones RDS de una de las granjas generadas en otro de los apartados.

3.4.5 Thinapps Esta consola permite aprovisionar las aplicaciones en modo ThinApp que están ubicadas en un repositorio para que aparezcan en los escritorios de los usuarios.

3.4.6 Farms Al igual que la creación de Pools, esta consola nos permitirá generar granjas RDS para luego usar la asignación de aplicaciones o sesiones.

#VMwarePorvExperts

638

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.4.7 Machines Sin duda la consola más visitada en la administración de Horizon View, nos mostrará toda la información relativa a los escritorios virtuales generados. Estado, ubicación, usuario asignado, usuario conectado, etc… Desde esta consola podremos realizar tareas individuales sobre los escritorios virtuales como reiniciarlo, restablecerlo, reconstruirlo o eliminarlo, también poner en modo mantenimiento o cambiar la asignación de un usuario.

3.4.8 Persistent Disks Más adelante veremos lo que son los Persistent Disk usados sobre Pools de Linked Clone, pero podemos avanzar que la gestión y estado de estos discos lo podemos gestionar desde esta consola, por ejemplo, desconectar un disco o conectarlo a otro escritorio.

#VMwarePorvExperts

639

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

3.4.9 Monitoring No cabe duda de que función tiene esta consola dentro de la administración. Nos permite ver todos los eventos generados por la plataforma, así como ver las sesiones en curso y poder interactuar con ellas, como reiniciar la sesión, o enviar un mensaje al usuario.

3.4.10 Global Policies Nos puede interesar por el tipo de escritorios virtuales que aprovisionaremos restringir a nivel de infraestructura el acceso a los USB o la aceleración por Hardware del protocolo PCoIP y la redirección multimedia. Esto lo podremos cambiar desde esta consola.

 

#VMwarePorvExperts

640

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

4. Imagen base con Windows Una de las primeras elecciones, para poder planificar un despliegue de escritorios virtuales es, escoger el SO que vamos a usar. Con VMware Horizon podemos usar varios SO, como por ejemplo Windows Server o Windows Cliente, además de crear escritorios Linux.

4.1 Windows Server o Windows cliente La principal diferencia entre escoger un SO de Cliente o un SO de Servidor es el licenciamiento que usaremos. No solo vale contemplar las licencias de VMware Horizon para nuestro proyecto, también tenemos que contemplar las de los escritorios virtuales que aprovisionaremos, por ello esta es la primera gran elección que deberemos estudiar, probar y confirmar. Las ventajas e inconvenientes residen es la usabilidad del usuario frente a su escritorio virtual y sobre todo al sistema de licenciamiento. En todo este capítulo, trabajaremos con plantillas Windows 10 Enterprise, pero la mayoría de los pasos se pueden aplicar en Windows Server.

4.1.1 Windows Server El licenciamiento, para poder usar Windows Server, es algo sencillo de entender. Podemos escoger entre Windows Server Standard o Windows Server Datacenter, que a grandes rasgos la diferencia reside en el número de VMs que se puede aprovisionar, a nivel de licenciamiento. La Standard permite 2 VMs por licencia y la Datacenter VMs ilimitadas. Nota. Leer con detalle el sistema de licenciamiento de Windows Server para cubrir vuestras necesidades correctamente y tomar la mejor decisión. https://www.microsoft.com/es-es/cloud-platform/windows-server-pricing

Lo recomendable es trabajar con licencias Windows Server Datacenter, que cubren un número ilimitado de VMs creadas en nuestro entorno VMware vSphere. Esto no es todo lo que hay que tener en cuenta a la hora de trabajar con escritorios virtuales de Windows Server, pues el contrato de Microsoft estipula que, si se requiere acceder a un escritorio de manera remota sin ser un acceso de administración del servidor, requiere una licencia de Remote Desktop Services CAL. En definitiva, necesitamos tantas RDS CAL como usuarios vayan a conectarse sobre los escritorios

#VMwarePorvExperts

641

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

virtuales.

4.1.2 Windows cliente El licenciamiento para Windows Cliente es mucho más complejo. Microsoft nos dice que, para acceder a un escritorio virtual, se requiere una licencia de Virtual Desktop Access (VDA). La manera de entender este licenciamiento es que debemos licenciar el cliente que accede a nuestros escritorios virtuales y no los escritorios virtuales en sí mismos. Si disponemos de equipos con Windows 7/8/8.1/10 o Windows Tablet ≤ 10,1 pulgadas, entonces lo más adecuado es coger Software Assurance (SA) en estas licencias para cubrir las necesidades de nuestro entorno VDI. Si disponemos de equipos ThinClient, ZeroClient o cualquier otro tipo de dispositivo que no sea los Windows mencionados anteriormente, entonces debemos adquirir licencias VDA, las cuales nos permitirán conectar a nuestros escritorios virtuales. Nota. Para realizar una buena planificación del licenciamiento, consulta los documentos de Microsoft sobre licencias SA y VDA. Además, contacta con algún Partner de confianza para que te asesore debidamente para evitar conflictos. https://download.microsoft.com/download/2/d/1/2d14fe17-66c2-4d4c-af73-e122930b60f6/ windows-10-volume-licensing-guide.pdf

4.2 Versiones de Windows 10 Desde la salida al mercado de Windows 10, ya se confirmó un rumor y es que Microsoft no quería seguir lanzando nuevos SO cada 2, 3 o 4 años. Este se ha traducido en 1 solo SO, el cual recibe cada 6 meses una gran actualización se todo el sistema. Estas actualizaciones completas incorporan cambio en el funcionamiento del propio sistema operativo por lo que es importante conocer las versiones y las funciones que implementan para decidir cuál es la versión que queremos desplegar en nuestro entorno VDI. Es cierto que cada una de estas actualizaciones dispone de un ciclo de vida limitado, por lo que después de este ciclo de vida ya no dispondremos de parches de seguridad, los cuales se liberan como es tradición una vez al mes. Esto nos lleva a necesitar más que nunca una plataforma donde podamos pasar de versión de Windows 10 de una manera rápida y confiable todos nuestros escritorios, para no encontrarnos con problemas de fragmentación.

4.2.1 Modern Apps y LTSB Windows 10 incorpora, además de grandes cambios en el diseño y funcionalidad, un sistema de

#VMwarePorvExperts

642

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

aplicaciones modernas (ModernApps), las cuales pueden ser instaladas desde la tienda de Microsoft Store. Estas aplicaciones modernas han comenzado a substituir las clásicas aplicaciones de Windows, como la Calculadora, las Sticky Notes, el visor de Fotos o el nuevo navegador Edge, entre otras. En entornos VDI donde los administradores queremos el máximo control de los escritorios, estas aplicaciones suponen un problema de gestión, pues van embebidas en el propio SO y en muchas situaciones no son necesarias para los usuarios. Existe una versión de Windows 10 llamada Long Term Servicing Branch (LTSB). Esta versión, no recibe las actualizaciones de SO cada 6 meses, por lo que tiene una vida de servicio mucho más larga y tampoco recibe tantas actualizaciones mensuales. Windows 10 LTSB, no incorpora las ModernApps, ni el navegador Edge, lo cual en entornos de VDI puede ser una versión a tener en cuenta, pero como contra partida, nuevas funcionalidades que se implementan en las versiones de SO cada 6 meses tampoco estarán disponibles. Docu www.sysadmit.com - Windows: 10 LTSB ¿Qué es? https://www.sysadmit.com/2017/01/windows-10-ltsb-que-es.html

4.3 Preparación imagen base 4.3.1 Hardware virtual Los requisitos necesarios para usar Windows 10 son escasos, apenas 2GB de RAM y 20Gb de disco, pero bien es cierto que con esas características mínimas nuestros usuarios tendrán grandes dificultades para trabajar con fluidez. Vamos a aprovisionar una VM con 2 vCPU, 4GB de RAM y 25GB de disco.

La configuración de la tarjeta de red debemos elegir el tipo de adaptador VMXNET 3, para mejorar la gestión de la red, este tipo de adaptador lo podremos seleccionar en la creación de la VM.

#VMwarePorvExperts

643

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Para la controladora SCSI lo ideal es usar el tipo VMware Paravirtual y mejorar la gestión de los discos virtuales, pero para simplificar la instalación de Windows, lo mejor, es realizar el proceso de configuración del tipo de controladora una vez instalado el SO y tengamos las VMware Tools instaladas, por lo que instalaremos el SO con la configuración que viene por defecto, LSI Logic SAS. Otra parte importante es mantener esta VM con el mínimo de Hardware necesario para funcionar, por ejemplo, quitar el Floppy Disk o el DVD (después de haber instalado el SO) Otra buena práctica, es que nuestra VM no opere en BIOS y lo haga en EFI, por lo que también tendremos que modificarlo antes de nuestra instalación. Cambiar este valor una vez instalado Windows 10, impedirá que arranque el SO.

Por último, realizaremos una configuración sobre las Opciones Avanzadas de la VM para conseguir que los dispositivos de red y disco no aparezcan en el Windows como dispositivos que se puedan extraer, así evitamos problemas con los usuarios que trabajen sobre ellos. En el apartado de Opciones de Máquina Virtual, Avanzado entramos en el menú Editar Configuración… y añadiremos una nueva línea. Name

devices.hotplug

#VMwarePorvExperts

Value false

644

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

4.3.2 Instalación y actualizaciones No vamos a indicar todo el proceso de instalación de Windows 10, pero es un proceso tan sencillo como cargar nuestra ISO en un Volumen VMFS de nuestro vCenter y añadirlo a la VM para que arranque.

El primer paso una vez tenemos instalado Windows 10, será la de ejecutar Windows Update para aplicar todos los parches pendientes y de esta manera asegurar que la plantilla que vamos a desplegar está completamente actualizada.

#VMwarePorvExperts

645

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Ahora daremos paso a todas aquellas aplicaciones que van a formar parte de nuestra plantilla. Estas aplicaciones son aquellas que todos los usuarios de nuestro entorno VDI necesitan usar y no requieren actualizaciones constantes, por ejemplo, 7zip, Java, VLC, Adobe Reader, Chrome, etc… Todas estas aplicaciones deberán estar configurada para evitar actualizaciones automáticas, de esta manera nosotros controlaremos el ciclo de actualizaciones.

4.3.3 Liberar espacio del disco Como es lógico, el espacio en un entorno de VDI es un recurso muy preciado y tenemos que mantener al mínimo la ocupación de nuestros escritorios virtuales, empezando por la plantilla. Lo primero que haremos es una limpieza de todos los archivos descargados de Windows Update y para ello necesitaremos lanzar un comando desde nuestra consola de PowerShell. dism /online /cleanup-image /StartComponentCleanup

4.3.4 Eliminar Modern Apps Ya hemos comentado que existe una versión de Windows 10 que no incorpora las Modern Apps, Windows 10 LTSB, pero también perdemos algunas funcionalidades que se lanzan cada 6 mese, por esto lo más acertado en el caso de usuarios que han de tener ciertas funcionalidades es eliminar todas aquellas Modern Apps que no sean necesarias. Para eliminar las Modern Apps lo podemos hacer mediante PowerShell y tendremos dos apartados que controlar, los AppxPackage y los ProvisionedAppxPackage.

LISTAR APPXPACKAGE Get-AppxPackage | ft

LISTAR APPXPROVISIONEDPACKAGE Get-AppxProvisionedPackage -online | ft

#VMwarePorvExperts

646

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

ELIMINAR APPXPACKAGE Remove-AppxPackage -package “nombre del paquete”

ELIMINAR APPXPROVISIONEDPACKAGE Remove-AppxProvisionedPackage -PackageName “nombre del paquete” -Online

No es buena idea eliminar todas las Modern Apps sin prestar atención a lo que estamos haciendo, porque muchas aplicaciones son ahora parte del uso normal del equipo, por ejemplo, la aplicación Fotos, que es el nuevo visor de imágenes o la Calculadora. Si eliminamos estas dos Modern Apps, y los usuarios necesitas estas funciones deberemos buscar aplicaciones alternativas que cumplan esa función.

4.3.5 VMware OS Optimization Tool Docu Vmware - Vmware OS Optimization Tool https://labs.vmware.com/flings/vmware-os-optimization-tool

Antes de pensar en desplegar una plantilla es necesario e imprescindible aplicar la herramienta VMware OS Optimization Tool (VOOT). Esta herramienta nos permite, ya sea con plantillas creadas o hechas por nosotros, aplicar configuraciones a nuestro Windows 10 para desactivar servicios que no son necesarios en un entorno de VDI. Por ejemplo, desactivar servicios como Windows Update, BranchCache, Hyper-V, VSS, entre otros muchos. También permite la desactivación de efectos visuales o eliminar Tareas Programadas de Windows como el famoso Defrag Schedule. El VOOT es una herramienta muy potente y necesaria, pero que hay que dedicarle tiempo a ver todas las cosas que desactiva o elimina para ver si en nuestro entorno se adapta correctamente. Por supuesto que es posible seleccionar solo aquellos aspectos que queramos desactivar, por ejemplo, Windows Search, es un servicio que aumenta la carga en un VDI, pero muy útil para los usuarios para buscar información en su Windows 10. Existen muchas plantillas preestablecidas para optimizar nuestro Windows 10 o Windows Server, de nosotros depende encontrar la que más se ajusta o crear una propia.

#VMwarePorvExperts

647

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

ANTES DE OPTIMIZAR

DESPUÉS DE OPTIMIZAR

4.3.6 Modificar el perfil de Windows Docu ForensiT https://www.forensit.com/support-downloads.html

Como último paso, me gusta modificar el perfil por defecto que tiene Windows almacenado, el cual

#VMwarePorvExperts

648

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

genera ciertos iconos en el escritorio, barra de tareas, así como establecer un fondo de pantalla y los colores del tema de Windows 10. Para que en la creación de un nuevo perfil en nuestro escritorio virtual sea lo más estándar y no tengamos que retocarlo, lo mejor es modificar el perfil por defecto y que de esta manera todos los usuarios al iniciar por primera vez les aparezca el mismo escritorio. Para conseguir esto de manera sencilla, existe una herramienta llamada Defprof, la cual clona un perfil de usuario que hayamos personalizado sobre el perfil por defecto de Windows. Para poder realizar el proceso debemos arrancar nuestro Windows con un usuario cualquiera y personalizar el escritorio, los iconos, fondo de pantalla y aspecto que consideremos. Una vez terminado, accedemos con un usuario Administrador distinto al que hemos personalizado y lanzamos el programa mediante la Línea de Comandos, indicando el perfil del usuario que hemos personalizado.

El usuario que hemos personalizado, lo podemos eliminar ya que esa configuración se aplicará a todos los nuevos usuarios creados en este Windows.

4.4 Agente de Horizon

Docu VMware - Opciones de configuración personalizadas de Horizon Agent https://docs.vmware.com/es/VMware-Horizon-7/7.6/horizon-virtual-desktops/GUID-61090F90186F-4932-BB0F-06902F0908B5.html

La última parte y más importante para preparar la plantilla que usaremos en el despliegue de escritorios, es la instalación del agente de Horizon. Para que nuestra plataforma interactúe con los escritorios virtuales y nos permita acceder remotamente mediante el Horizon Client o por HTML5, es imprescindible que esta, tenga instalados los componentes del agente de Horizon que vamos a necesitar. El proceso de instalación es muy sencillo, aplicamos el método Next, Next, Netx, pero nos detendremos en la siguiente ventana, que es la que determinará que componentes añadiremos a nuestra plantilla.

#VMwarePorvExperts

649

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Entre los componentes del agente de Horizon, encontramos los protocolos de conexión, como PCoIP o VMware Blast que son de instalación obligatoria, pero también encontramos otros que podemos instalar si realmente los necesitamos. Por ejemplo, la redirección USB, la virtualización de las impresoras, redirección de SmartCard, redirección de webcam y audio, entre otras muchas opciones. En este apartado me gustaría destacar las que tienen un impacto directo en nuestro uso sobre la infraestructura de Horizon, que son: •

VMware Horizon Composer Agent: Este componente, permite usar la plantilla para desplegar escritorios virtuales mediante la tecnología de Linked Clone.

•

VMware Horizon Instant Clone Agent: Este componente permite usar la plantilla para desplegar escritorios virtuales mediante la tecnología de Instant Clone.

•

VMware Horizon 7 Persona Management: Este componente permite sincronizar el perfil del usuario contra una ubicación remota, igual que los perfiles remotos de Windows, pero con mayores ventajas en cuanto a la sincronización. Requiere de las plantillas ADMX para configurarlo mediante GPOs.

Cuando configuramos una plantilla para usarla en Instant Clone, no podemos activar los componentes de Linked Clone y tampoco los de Persona Management, ya que son tecnologías incompatibles. En cambio, si queremos usar la plantilla para Linked Clone, sí que podremos usar Persona Management, pero no podremos activar el agente de Instant clone. Esto es una parte muy importante, pues si disponemos de Pools con distinta tecnología, requeriremos obligatoriamente dos plantillas, una para usar en Linked Clone y otra para usar en Instant Clone.

#VMwarePorvExperts

650

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

4.5 Horizon Client para aplicaciones RDS Docu VMware - Conectarse a aplicaciones publicadas y escritorios remotos https://docs.vmware.com/es/VMware-Horizon-Client-for-Windows/4.10/horizon-client-windowsuser/GUID-45149DE2-75E1-4A7F-9B00-6981F97DF52C.html

La instalación de Horizon Client, no es obligatoria en una plantilla para aprovisionar escritorios virtuales, ya que es el programa que nos permitirá conectar con nuestros escritorios virtuales, por lo que es un sin sentido. Horizon Client, no solo permite conectarnos a escritorios virtuales, sino que también permite conectarse a aplicaciones RDS, previamente aprovisionadas desde el portal de Horizon.

Normalmente, el despliegue de aplicaciones por RDS no se usa para escritorios virtuales, pues existen otros métodos, pero es muy sencillo poder aprovisionar aplicaciones de manera rápida sin complicaciones y eso hacer que en ocasiones queramos mezclar ambos conceptos, escritorios virtuales con aplicaciones por RDS. Como vemos en la imagen del Horizon Client, podemos conectar a un escritorio virtual, pero si queremos acceder a una aplicación RDS, no lo haremos desde dentro del escritorio, deberá ser desde fuera y esto puede ser muy incómodo para los usuarios. El fin de instalar Horizon Client en la plantilla, es poner a disposición de los usuarios las aplicaciones publicadas por RDS con acceso desde su escritorio virtual, consiguiendo una unión de ambos conceptos y facilitando la usabilidad a nuestros usuarios. Para administrar la configuración de todos estos Horizon Client, podremos usar las plantillas administrativas de Active Directory y no configurar las conexiones de manera manual para cada uno de nuestros escritorios virtuales.

#VMwarePorvExperts

651

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

 

#VMwarePorvExperts

652

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

5. Escritorios para IT (Full Clone) En este apartado, veremos cómo aprovisionar los escritorios virtuales al departamento de IT y antes vamos a introducir algunos conceptos. Escritorio Persistente. Estos escritorios almacenan los datos de aplicaciones y usuarios en el mismo disco del sistema operativo. Es lo más parecido a un escritorio físico. Full Clone. Todos aquellos escritorios generados desde un pool Full Clone, son máquinas idénticas entre sí en el instante de ser creadas y todas ocupan un espacio en disco idéntico a la plantilla original. El tiempo de creación de estos escritorios dependerá mucho del tamaño del disco de la VM Base y de la tecnología de disco que se usa, SSD, SCSI, SATA. No requieren conexión con la plantilla original y los datos de usuario, SO y temporales conviven en el mismo disco duro virtual de cada uno de los escritorios.

Recordemos que estos escritorios deben ser escritorios con un alto nivel de flexibilidad, para instalar o desinstalar aplicaciones según convenga. Esto implica que cada escritorio una vez clonado será completamente distinto a otro del mismo Pool.

5.1 Opciones del Pool

Docu VMware - Crear un grupo automatizado que contenga máquinas virtuales completas https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-DB1E305DF9CF-4696-BAB7-7915B0A50DA5.html

#VMwarePorvExperts

653

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu VMware - Configurar grupos de escritorios https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-E298BBACCBBD-4235-A8A7-CFF09E96DF28.html

Gracias a la amplia documentación de VMware respecto a Horizon View, podemos ver la cantidad de parámetros disponibles y sus funciones. A continuación, veremos algunas pantallas en la creación del Pool y sus configuraciones más relevantes.

5.1.1 Aprovisionamiento Si decidimos realizar el aprovisionamiento manual, debemos realizar las operaciones de clonación de la VM Base directamente desde la consola de vSphere, y una vez tengamos las VMs creadas y configuradas ya podremos asignarlas dentro del Pool. Si queremos evitar interactuar en la creación de los escritorios, debemos usar este tipo de aprovisionamiento. Esto, como veremos más adelante, requiere que nuestra VM Base esté en formato plantilla y debemos tener creados los perfiles de configuración de vSphere para seleccionarlo durante la creación del Pool.

5.1.2 Asignación de usuario Podemos escoger asignación Flotante, lo cual cada vez que un usuario cierre la sesión del escritorio virtual, este se liberará para que otro usuario pueda conectarse. Esta opción no es la adecuada en el escenario que planteamos, ya que nos interesa que dará usuario disponga de su equipo de manera dedicada.

#VMwarePorvExperts

654

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

5.1.3 Tipo Tal y como hemos mencionado este será un Pool Full Clone, lo cual debemos indicarlo y además seleccionar la instancia de vCenter que va a usar para generar las VMs. Muchas de las características que nos ofrece Horizon View en los Pools, vienen limitadas por esta elección, al escoger un Pool Full Clone, no podremos realizar Recompose o Push, que son comandos específicos de los tipos de Pool Linked Clone e Instant Clone.

5.1.4 Nombre Es imprescindible que cada Pool tenga un identificador distinto, aunque el Nombre para mostrar puede ser idéntico en todos los casos.

#VMwarePorvExperts

655

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

5.1.5 Configuración Docu VMware - Configuración de grupos de escritorios para todos los tipos de grupos de escritorios https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-0359DB4C4517-4535-8EBC-BD4F27C764F3.html

Dependiendo el tipo de Pool, como ya hemos comentado, tendremos unas opciones u otras y algunas son comunes a todos. Ahora comentaremos las más interesantes: •

Connection Server restrictions: Nos permite restringir el acceso a este Pool por unos determinados Connection Servers. Si lo dejamos por defecto, se puede acceder por cualquier Connection Server.

•

Automatically logoff after disconnect: Permite lanzar un cierre de sesión del usuario una vez desconectado del escritorio virtual y podemos escoger entre Nunca, Inmediatamente y Después de…

•

Default display protocol: Establecerá el protocolo de la sesión por defecto, que en la mayoría de casos usaremos VMware Blast.

•

Allow users to choose protocol: Permite al usuario establecer el protocolo que desea usar, Blast, PCoIP o RDP. Como norma general lo estableceremos en No.

•

HTML Access: Si marcamos esta opción permitimos el uso del Pool mediante acceso HTML, para poder usar esto en la instalación del Connection Server debemos marcar el HTML Access.

#VMwarePorvExperts

656

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

5.1.6 Configuración de aprovisionamiento En este apartado podremos activar o desactivar el aprovisionamiento de los escritorios, es decir podemos crear el Pool pero que no se lance la creación de los escritorios hasta que habilitemos el aprovisionamiento. Aquí definiremos el nombre los escritorios virtuales y para ello tenemos el valor {n} para asignación automática de números. En el caso que queramos usar dos o más dígitos usaremos el valor {n:fixed=2}. También, definiremos el número de escritorios virtuales que vamos a crear en este Pool, el cual podremos modificar más adelante.

#VMwarePorvExperts

657

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Por último, definiremos si queremos aprovisionar todos los escritorios que hemos definido antes de ser usados o si queremos aprovisionarlos durante el primer inicio de sesión del usuario. Recordad que el tiempo de creación de estos escritorios será el de clonar y preparar una VM completa, por lo que se recomiendo aprovisionarlos todos antes del inicio del usuario.

5.1.7 Optimización del almacenamiento Tan solo debemos seleccionar esta opción en el caso de que el clúster donde vayamos a correr los escritorios virtuales sea vSAN.

5.1.8 Configuración vCenter Lo primero que haremos será seleccionar nuestra VM Base, en modo Plantilla de vSphere, luego

#VMwarePorvExperts

658

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

seleccionar la carpeta de nuestro vCenter donde colocaremos los escritorios virtuales generados y por último el Cluster, Resource Pool y Datastore que vamos a usar.

5.1.9 Customización del escritorio Para no tener que realizar ninguna acción sobre los escritorios que generaremos, como, añadirlos al Active Directory o hacer un SysPrep manual, la mejor idea es seleccionar una customización de SO, creada en la consola de vSphere, de esta manera podemos definir cosas como añadir al Active Director, establecer IP en manual o DHCP y otras configuraciones.

5.1.10 Asignar autorización al Pool Docu VMware - Agregar autorizaciones a un grupo de escritorios o aplicaciones https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-A5DFB49A4C0C-4CCB-B481-B22915FFD6D7.html

Ya tenemos nuestro Pool creado y aprovisionado, eso quiere decir que los escritorios virtuales ya están disponibles para ser usados. Lo que necesitamos ahora es asignar un grupo de usuario al Pool para que puedan acceder y empezar

#VMwarePorvExperts

659

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

a usarlos. La mejor manera de controlar el acceso a los Pools es crear grupos en Active Directory que hagan referencia a estos Pools y añadiendo solamente a las personas indicadas. Si intentamos aprovechar grupos existentes de Active Directory no podemos encontrar sorpresas como que un usuario, por error puede acceder a un Pool donde no debería.

5.2 Información y tareas sobre el Pool Desde la consola de Desktop Pools podemos acceder al estado del Pool que acabamos de crear y dividido en varias pestañas encontramos los Eventos generados, las Global Policies que se están aplicando y modificarlas para este Pool en concreto, las asignaciones de autorización al Pool, las Sesiones activas y poder ver el inventario tanto de escritorios virtuales como de discos persistentes, pero sin duda, lo más interesante es la pestaña principal Summary. Desde esta pestaña veremos las opciones de Editar el Pool, Eliminarlo, Asignar usuarios o grupos y modificar el Estado.

 

#VMwarePorvExperts

660

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

6. Escritorios para responsables (Linked Clone) En los escritorios creados para los responsables de los departamentos, vamos a introducir conceptos generales para este tipo de escritorios virtuales.

Linked Clone. La tecnología Linked Clone permite ahorra espacio y tiempo, en la creación de escritorios generados en un Pool. Para poder ahorrar espacio, los discos de cada escritorio virtual no se clonan, se establecer como discos diferenciales del disco original de la plantilla (delta disk). Por ello, es importante mantener la VM Base ya que los escritorios virtuales dependen de ella para generar. El proceso implica primero disponer de una VM Base y realizar un Snapshot como punto de partida, para generar una VM Réplica de la original en ese estado concreto. Por último, genera los escritorios, con los discos diferenciales respecto a la VM Réplica. Los discos de los escritorios virtuales, generados solo almacenarán los cambios diferenciales entre el disco de la VM Réplica y los datos que genera el usuario.

#VMwarePorvExperts

661

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Escritorio no Persistente. Este tipo de escritorios permite mantener un escritorio de tal manera que siempre contiene los mismos datos, por lo que están pensados para sistemas donde los datos y configuraciones no son relevantes. Cada vez que apagamos un equipo, se restablece volviendo a su configuración inicial.

Disco Persistente. Estos discos están disponibles en los Pools Linked Clon y permiten mantener los datos del perfil del usuario (C:\Users), de tal modo que podemos usar un Pool Linked Clon como si fuese Persistente. Este disco redirecciona el perfil a la unidad D: o cualquier otra que configuremos, permitiendo que, si escritorio virtual se recompone o se elimina, se mantiene el disco persistente y el usuario no pierde los datos y las configuraciones del perfil.

Tareas Linked Clone. Existen 3 tareas básicas que debemos entender para saber cómo trabajar con escritorios Linked Clone. Refresh. La tarea de refresco o actualización sirve para restablecer el disco de SO del escritorio virtual (delta disk) al estado en el que se encuentra la VM Réplica, por lo que cualquier cambio realizado sobre ese disco, se perderá. Este refresco, no afectará a los discos persistentes de los escritorios. Recompose. La tarea de recomponer permite cambiar los discos de SO del escritorio virtual con una nueva VM Base o con un nuevo Snapshot. Por ejemplo, si decidimos actualizar los parches de seguridad de todos los escritorios virtuales, tan solo debemos hacerlo en la VM Base, realizar un nuevo Snapshot y recomponer el Pool. Además de poder recomponer todo el Pool, también podemos recomponer solo un escritorio virtual concreto. La tarea de recomponer no afecta a los discos persistentes. Rebalance. La tarea de rebalanceo es muy simple, cuando disponemos de un Pool almacenado en 1 o varios Datastores, nos puede interesar moverlos por tareas de mantenimiento o migración a un nuevo almacenamiento. La operativa de esta tarea es realizar un Refresh hacia un nuevo Datastore, por lo que tenemos que ser consecuentes que se perderán los cambios almacenados en el disco de SO de cada escritorio virtual.

Los escritorios generados en este Pool han de ser homogéneos en cuanto a aplicaciones y además necesitamos que sean actualizables de una manera centralizada, por el departamento de IT, con el objetivo de mantener todos en las mismas versiones tanto de parches como de aplicaciones.

#VMwarePorvExperts

662

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

En este Pool no se permitirá disponer de aplicaciones que no estén aprovisionadas de manera general para todo el Pool ya que se perderán cuando realicemos las acciones de actualización de la plantilla (Recompose).

6.1 Opciones del Pool

Docu VMware - Crear grupos de escritorios de clonación vinculada https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-CE05F77C1121-444A-8C02-40BA874CFCD7.html

6.1.1 Aprovisionamiento Para este Pool parece algo obvio que debemos escoger el aprovisionamiento automático ya que no hay ninguna manera de poder usar la tecnología Linked Clone con un Pool manual.

6.1.2 Asignación del Pool Para la definición de Pool que hemos establecido, vamos a escoger Dedicado, porque nos interesa que cada responsable de departamento mantenga su escritorio de manera indefinida y así podamos tener controlada la asignación. Sería completamente factible usar la opción Flotante, siempre que nos interesase que los usuarios no tuvieran asignada un escritorio de manera indefinida y cada vez que se desconectasen se perdiera la asignación.

#VMwarePorvExperts

663

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

6.1.3 Tipo Como hemos adelantado, usaremos la tecnología Linked Clone para generar este Pool, por lo tanto, seleccionaremos la opción de View Composer linked clones. Esto nos obligará a escoger una instancia vCenter con su correspondiente Composer configurado.

6.1.4 Nombre Como ya hemos comentado le daremos un ID único a este Pool y un nombre descriptivo.

#VMwarePorvExperts

664

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

6.1.5 Configuración Docu VMware - Configuración de grupos de escritorios para todos los tipos de grupos de escritorios https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-0359DB4C4517-4535-8EBC-BD4F27C764F3.html

En la creación del Pool Full Clone, hemos hablado de estas opciones, ahora veremos que opción aparece para el tipo Linked Clone: •

Refresh OS disk after logoff: Esta opción permite que, en cada cierre de sesión del usuario, el disco de SO (disco delta), se refresque de tal manera que cuando vuelva a conectar estará en el mismo estado que la VM Réplica. Disponemos de varias opciones, Nunca, Siempre, Cada x días o Cuando el disco llegue al x% de utilización. Esta opción es muy interesante para evitar el descontrol de configuraciones o instalaciones no centralizadas en la VM Base.

#VMwarePorvExperts

665

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

6.1.6 Configuración del almacenamiento Estas opciones son idénticas al anterior Pool creado, y lo que debemos hacer es darle otro nombre de equipos al nuevo Pool.

6.1.7 Discos View Composer Este apartado es único para los Linked Clone. En este apartado definiremos, si nos interesa, el Disco Persistente, que nos permitirá mantener los datos del perfil sin que se destruyan, reubicando los datos a la unidad que configuramos. También podemos y recomendamos configurar el disco de temporales, este disco almacena todos los archivos temporales que se generan en el escritorio y cuando el usuario cierra la sesión se elimina y

#VMwarePorvExperts

666

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

se crea automáticamente de nuevo al iniciarla. En ambos discos hay que configurar un tamaño especifico máximo, pues estos discos se iniciarán en modo de aprovisionamiento lento y el gran problema es que no pueden ser ampliados una vez generados. Si que podemos modificar el valor del disco en la edición del Pool, pero solo afectará a los nuevos discos. Para poder ampliar un disco persistente existente, debemos hacer como si de una VM se tratase, directamente desde la consola de vSphere y luego desde el Windows, esta tarea se deberá hacer individualmente por cada escritorio virtual. Si decidimos no usar estos discos, todos los datos de perfil y temporales se almacenarán en el delta disk y en las tareas de Refresh, Recompose o Rebalance perderemos todos los datos generados.

6.1.8 Configuración vCenter Este apartado es muy similar al anterior Pool, pero con alguna diferencia, ya que debemos escoger nuestra VM Base sin ser formato Plantilla de vSphere, sino como una VM normal pero deberemos disponer de un Snapshot para generar la VM Réplica y luego los escritorios virtuales.

6.1.9 Configuración avanzada de almacenamiento Este apartado, tenemos opciones para activar la aceleración de almacenamiento, lo cual optimiza #VMwarePorvExperts

667

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

el rendimiento de los discos compartidos para entornos que usan View Composer, también permite reclamar espacio liberado siempre y cuando nuestra plataforma lo soporte.

6.1.10 Customización del escritorio La customización de los escritorios generados con Linked Clone, nos permite usar una funcionalidad muy interesante que se llama QuickPrep. Esta función sustituye al Sysprep de Windows reduciendo las operaciones de restablecimiento siendo mucho más rápido, además podemos pasar Script personalizados. Functions

Elimina cuentas locales

Cambia el identificador de seguridad (SID)

Eliminar el padre del dominio

Cambia el nombre del equipo Genera nuevo SID

Personaliza language, configuración regional, etc. Requiere archivo de configuración

Activación licencias KMS

Scripts post-customización

VMware QuickPrep

Si

No

Si

No

Si

No

Si

Si

Si

Añade al dominio

Reinicios necesarios

Microsoft Sysprep

Si

Si

No

1 (configuración inicial)

0

Si (opcional)

No

Si

No

No

Si

No

Si

https://kb.vmware.com/s/article/2003797

Desde esta configuración estableceremos la Unidad Organizativa de nuestro Active Directory donde se crearán los objetos de Equipo de los escritorios virtuales.

#VMwarePorvExperts

668

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Es una buena práctica marcar la opción que permite reutilizar las cuentas de equipo preexistentes, de esta manera no se crearán multitud de objetos sobre nuestro Active Directory.

6.1.11 Asignar autorización al Pool La asignación de autorización funciona del mismo modo que en el Pool de Full Clones, por lo que crearemos un nuevo grupo de Active Directory para asignar los usuarios que deberán usar este Pool.

6.2 Información y tareas sobre el Pool Como hemos visto en el Pool de Full Clones, podemos ver el estado del Pool desde la consola de Desktop Pools, pero como hemos comentado cada tipo de Pool tienes sus propias opciones sobre la pestaña de Summary. En este caso, además de las opciones vistas anteriormente, podemos encontrar una que es View Composer que nos ofrece tres posibilidades, Refresh, Recompose y Rebalance.

#VMwarePorvExperts

669

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Estas acciones repercutirán sobre todos los escritorios generados, por lo que hay que ser conscientes que un error en alguna acción afectará a todos. La tarea más interesante que vamos a ver es la de Recompose porque es la acción que usaremos cuando quedamos modificar nuestra VM Base, por ejemplo, con nuevas actualizaciones de Windows. Como podemos observar lo primero que nos aparece es cuál será la nueva Parent VM, es decir, si vamos a cambiar la VM sobre la que basamos nuestros escritorios virtuales. La segunda opción que tenemos es la de escoger el Snapshot de la VM Base, para saber en qué estado se van a generar los escritorios virtuales. En el caso de haber actualizado nuestro Windows 10, lo que hubiésemos hecho es un nuevo Snapshot y en esta ventana simplemente lo seleccionamos para que aprovisione a todos los escritorios con ese nuevo Snapshot. Por último, nos da la opción de que la nueva configuración que vamos a desplegar a todos los escritorios pase a ser la nueva configuración del Pool, de este modo si generamos un nuevo escritorio mantendrá la misma VM Base y Snapshot que el resto de los escritorios recompuestos.

#VMwarePorvExperts

670

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Podemos programar la tarea para una hora determinada y además forzar o no, el cierre de sesión de los usuarios.

Una vez lanzado el Recompose nos dirigimos a la pestaña de Tasks para ver el estado de la tarea e incluso si queremos Cancelarla.

#VMwarePorvExperts

671

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

En la pestaña de Inventory, podemos ver en qué estado se encuentra cada uno de los escritorios, si ha empezado la tarea de recomponer o si está todavía el usuario conectado o si está el escritorio disponible para su uso.

Como hemos advertido, esta acción afecta a todos los escritorios virtuales del Pool y debido al gran riesgo que supone un cambio como este es muy recomendable realizarlo primero en un solo escritorio para validar su correcto funcionamiento. Para realizar esto, lo único que debemos hacer, es acceder al escritorio que queramos recomponer y podremos ver que disponemos de las mismas opciones de Refresh, Recompose y Rebalance, además de Cancel Task, que teníamos en el Pool.

#VMwarePorvExperts

672

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7. Escritorios para trabajadores (Instant Clone) En el Pool creado para los trabajadores, vamos a introducir conceptos generales para este tipo de escritorios virtuales. Instant Clone. La tecnología Instant Clone es muy parecida en concepto a Linked Clone, pero con una operativa totalmente distinta. Así como Linked Clone opera a nivel de disco y mantiene un disco en cada escritorio virtual con los datos diferenciales respecto a la VM Réplica, Instant Clone genera en cada escritorio virtual, un disco diferencial y una memoria RAM diferencial respecto a una VM Parent, que se aprovisiona para cada uno de los nodos ESXi y se mantiene encendida.

Esta tecnología no permite mantener ningún dato del escritorio virtual de manera persistente, de este modo, cuando el usuario cierra la sesión o reinicia el escritorio, este, se destruye y se genera de nuevo en el mismo estado que la VM Parent. Instant Clone genera varias VM en el proceso de aprovisionamiento del Pool, por lo que necesitamos una VM Base con un Snapshot del estado que vamos a aprovisionar. Luego se generará una plantilla, para todo el Pool, del estado de nuestra VM Base con el Snapshot y seguidamente una VM Réplica en cada uno de los Datastores asignados al Pool. Estas VM Réplica serán la que generará las VM Parent en cada uno de los nodos ESXi y en cada Datastore asignado al Pool. Las VM Parent están siempre encendidas y son las encargadas de compartir tanto el disco como la memoria para generar los escritorios virtuales y aprovisionarlos en muy pocos minutos.

#VMwarePorvExperts

673

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Push Image. En los Pools de Instant Clone, el concepto para configurar la VM Base es “Published”, esto quiere decir que cuando nosotros queremos cambiar nuestra VM Base o un Snapshot de la VM Base, la tarea que realizamos es un Push Image. Este proceso, no reconfigura ninguno de los escritorios existentes, el proceso realiza las VMs intermedias y las Parents VM en cada host y las deja aprovisionadas, para que, en el próximo cierre de sesión de un escritorio virtual, se genere de la nueva imagen publicada.

Este tipo de Pool se compondrá de escritorios virtuales no persistentes, por lo que, en cada cierre de sesión, reinicio o desconexión, el equipo se eliminará y pasará a entregar un nuevo escritorio virtual al usuario que acceda al sistema. Con estos escritorios virtuales no persistentes, debemos asegurarnos de que los usuarios no almacenan datos sobre sus carpetas de Escritorio, Documentos, Imágenes, etc… ya que, en cada cierre de sesión, los perderían.

#VMwarePorvExperts

674

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Para evitar este inconveniente, lo correcto es usar el sistema de Redirección de Carpetas de Microsoft o el mismo sistema de Redirección de Carpetas mediante VMware UEM, que veremos en el apartado “6 - Perfiles de Usuarios”, así nos aseguramos de que, aun usando escritorios virtuales no persistentes, garantizamos el acceso a los datos guardados durante su uso.

7.1 Opciones del Pool

Docu VMware - Crear grupos de escritorios de clonación instantánea https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-F5C53552F6C8-4BE8-B486-9D172CA1F5CD.html

7.1.1 Aprovisionamiento Instant Clone se basa en el mismo concepto que Linked Clone, escritorios que se aprovisionan de manera automática, por lo que la única opción viable es escoger Pool automático.

7.1.2 Asignación de usuario La razón de implementar este tipo de Pool a los empleados es que no nos interesa que cada empleado tenga un escritorio asignado de manera indefinida, por lo que la opción de la asignación de usuario será Flotante. Con esta opción, conseguiremos que cuando un usuario cierre la sesión, libere el escritorio virtual para que otro usuario pueda acceder.

#VMwarePorvExperts

675

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7.1.3 Tipo Para poder operar tal y como nos interesa, escogeremos el tipo de Pool Instant Clone, y seleccionaremos nuestro vCenter vinculado.

7.1.4 Nombre Como ya hemos comentado le daremos un ID único a este Pool y un nombre descriptivo.

#VMwarePorvExperts

676

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7.1.5 Configuración Docu VMware - Configuración de grupos de escritorios para todos los tipos de grupos de escritorios https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-0359DB4C4517-4535-8EBC-BD4F27C764F3.html

En la creación de los anteriores Pools, hemos hablado de estas opciones, ahora veremos que opción aparece para el tipo Instant Clone: •

Allow user to initiate separate sessions from different client devices: Esta opción permite que un usuario pueda iniciar sesión desde varios dispositivos, teniendo varios escritorios ocupados.

#VMwarePorvExperts

677

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7.1.6 Configuración de aprovisionamiento Estas opciones son idénticas al anterior Pool creado, y lo que debemos hacer es darle otro nombre de equipos al nuevo Pool.

7.1.7 Configuración vCenter Este proceso es idéntico al usado en el Pool Linked Clone, pero hay que ser conscientes que no podemos usar la misma VM Base, pues en la instalación del View Agent no pueden convivir el agente de Linked Clone con el de Instant Clone.

#VMwarePorvExperts

678

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7.1.8 Customización del escritorio Para la customización de los escritorios se usará la tecnología ClonePrep que en funciones es idéntica a QuickPrep.

7.1.9 Asignar autorización al Pool La asignación de autorización funciona del mismo modo que en los anteriores Pools, por lo que crearemos un nuevo grupo de Active Directory para asignar los usuarios que deberán usar este Pool.

#VMwarePorvExperts

679

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

7.2 Información y tareas sobre el Pool Al igual que en los anteriores Pools, ya comentados, disponemos de mucha información sobre Inventario, Sesiones, Eventos, etc…, pero lo diferenciador son las opciones en la pestaña de Summary. Tal y como pasa con el Pool Linked Clone, nos aparece una nueva opción Push Image con tres opciones, Schedule, Reschedule o Cancel.

Del mismo modo que si fuere un Recompose en Linked Clone, nos solicita la VM Base y un Snapshot. Una vez Publicada esta nueva imagen, todos los escritorios se crearán a través de ella.

#VMwarePorvExperts

680

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Si nos dirigimos a la pestaña de Summary y vemos el apartado de vCenter podremos observar que disponemos de dos apartados Current Image, en estado Published y otro apartado Pending Image con el estado Publishing.

Una gran diferencia, con respecto a la gestión de los escritorios virtuales de manera individual, con Linked Clone, es que ahora no disponemos de tareas adicionales sobre los escritorios virtuales de Instant Clone, porque el simple hecho de reiniciar el equipo, este se elimina y se genera de nuevo en el estado idéntico a la imagen Publicada.

#VMwarePorvExperts

681

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

 

#VMwarePorvExperts

682

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

8. Gestión de perfiles Windows Cuando disponemos de un sistema de escritorios virtuales, una de las grandes ventajas es la eliminación y creación de escritorios de manera rápida, podemos aprovisionar 10 ordenadores nuevos o migrar a 10 usuarios de un Windows 7 a un Windows 10 sin mucho esfuerzo. Para poder aprovechar esta ventaja es importante saber dónde y cómo ubicar los datos del perfil de nuestros usuarios, para poder hacer estas migraciones de manera rápida y con el menor impacto posible. Hablamos de la carpeta que habitualmente se encuentra en C:\Users En este apartado vamos a plantear distintas opciones para realizar el tratamiento del perfil para encajar la mejor solución en cada caso.

8.1 Disco local y disco persistente Cuando instalamos un SO de Windows por defecto la carpeta de los perfiles de usuario se ubica en C:\ Users, por lo que cualquier escritorio virtual que aprovisionemos creará las carpetas del perfil en esa ubicación. Esta carpeta, la de los perfiles de Windows, contiene información como Escritorio, Documentos, Imágenes, etc. Además de las carpetas AppData donde se almacenan los datos de configuración de las aplicaciones para ese perfil en concreto. La carpeta del perfil está ubicada directamente en el disco local donde se almacena todo el SO y como ya hemos adelantado, una de las ventajas es poder cambiar nuestro SO sin necesidad de migrar datos. La mejor opción es mover esta carpeta a otra ubicación. Cuando tratamos este tema con un Pool de Linked Clone, ya sabemos que en el momento de Recompose o Refresh, perdemos todos los datos del disco del SO, entonces no es la mejor idea dejar la carpeta del perfil en la ubicación por defecto. Como hemos visto en la creación del Pool Linked Clone, nos permite seleccionar un Disco Persistente para que se añada en cada uno de los escritorios virtuales generados. Este disco garantizará que el perfil del usuario no se ubica en el disco de SO, por lo que no se verá afectado por las tareas habituales de los Pools de Linked Clone.

#VMwarePorvExperts

683

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

8.2 Redirección de carpetas y perfiles móviles 8.2.1 Redirección de carpetas La tecnología que más facilita la gestión de los datos del perfil de un usuario es la redirección de carpetas, que permite acceder a todos los datos desde una unidad de red y donde el administrador, de manera centralizada, controla y gestiona todos estos datos. Esto le permite aplicar políticas de copia de seguridad sin depender de los equipos clientes, además garantiza que, si un usuario accede a otro equipo de la empresa, podrá acceder a sus datos sin problemas y siempre actualizados. Al disponer de los archivos en un servidor, podemos aplicar medidas de control de espacio, bloqueo de extensiones de ficheros e incluso crear informes de estado de los documentos de nuestros usuarios. User Configuration/Windows Settings/Folder Redirection •

Documents y Desktop: Podemos establecer distintas configuraciones sobre las carpetas del perfil, en este caso usaremos la misma. Target •

Settings: Basic – Redirect everyone’s folder to the same location.

•

Target folder location – Create a folder for each user under the root path.

•

Root Path: \\fileserver\folders-redirect

Settings •

Move the contents of Documents to de new location.

•

Leave the folder in the new location when policy is removed.

8.2.2 Perfiles móviles Muy en línea con la redirección de carpetas, encontramos los perfiles móviles que en grandes rasgos permite sincronizar los datos de aplicaciones almacenados en el perfil, pero solo los que se almacenan en AppData\Roaming, es decir aplicaciones preparadas para ser móviles. Los datos almacenados en el perfil móvil se sincronizan con la unidad de red, por lo que en cada inicio o cierre de sesión se debe actualizar los datos y esto puede enlentecer las tareas de inicio y cierre. User Configuration/Windows Settings/Folder Redirection •

AppData (Roaming): Podemos establecer la misma configuración que hemos usado para Documents y Desktop. Target •

Settings: Basic – Redirect everyone’s folder to the same location.

•

Target folder location – Create a folder for each user under the root path.

•

Root Path: \\fileserver\folders-redirect

#VMwarePorvExperts

684

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Settings •

Move the contents of Documents to the new location.

•

Leave the folder in the new location when policy is removed.

Si nos centramos en la redirección de carpetas y perfiles móviles, quizás podemos pensar que no son necesarios los discos persistentes, pues con estas soluciones, ya disponemos de todos los datos en una ubicación compartida. Esto no es así del todo, porque existe una carpeta llamada AppData\Local que no se puede redirigir y en esta carpeta encontramos configuraciones de aplicaciones o cache de aplicaciones que por si estructura no se almacenan en la carpeta AppData\Roaming. Para evitar la pérdida de los datos almacenador en AppData\Roaming en cada Recompose o Refresh, es buena idea mantener tanto la redirección de carpetas, como el perfil móvil, así como el disco persistente, obteniendo un control completo de los datos del perfil del usuario.

8.3 Persona Management VMware en nuestra plataforma de Horizon, nos facilita una tecnología similar a la redirección de carpetas y los perfiles móviles, pero con muchas más opciones de configuración y flexibilidad a la hora con configurarlo. Como vimos en el apartado de Horizon Agent, es un componente que debemos instalar en la plantilla para poder usarlo, pero para configurar y manipular este servicio requeriremos instalar las Plantillas Administrativas en nuestro entorno de Directivas de Grupo (GPO). El concepto de uso es idéntico al mencionado en la redirección de carpetas y perfiles móviles, por lo que, si la idea principal es usar esas tecnologías, es muy muy recomendable usar Persona Management. Podremos encontrar muchas configuraciones referentes a Persona Management y ahora veremos las básicas. Computer Configuration/Administrative Templates/VMware View Agent Configuration/Persona Management/Folder Redirection •

Add the Administrators groups to redirected folders: Permite que los administradores puedan acceder a las carpetas de los perfiles de los usuarios, de lo contrario no podrán acceder.

Computer Configuration/Administrative Templates/VMware View Agent Configuration/Persona Management/Romaing & Syncronization •

Files and folders excuded from roaming: Podemos establecer las carpetas del perfil de usuario que no queremos sincronizar con el servidor. •

Music

•

Pictures

•

Videos

#VMwarePorvExperts

685

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

•

•

•

Download

•

AppData\Local\Temp

•

AppData\Local\Packages

•

$Recycle.Bin

•

*thumb*.db

•

*icon*.db

•

…

Folders to background download: Permite establecer directorios que se sincronicen en segundo plano y no afecten al inicio de sesión. •

AppData\Local

•

AppData\LocalLow

•

…

Manage user persona: Activa la funcionalidad de Persona Management y establece el tiempo de sicronización. •

•

Profile upload Interval: 10 min

Persona repository location: Establece la ubicación de los datos de los perfiles, sin variables. •

Share parth: \\fileserver\profiles-PM

Como se puede observar en su configuración, no hacemos referencia a ninguna parte de la plataforma de Horizon, por lo que esta tecnología la podemos llevar a nuestros escritorios físicos, unificando de este modo a todos los equipos de la empresa. Tan solo requeriremos instalar el Horizon Agent con el servicio de Persona Management.

8.4 VMware User Environment Manager (UEM) Quería empezar con la descripción textual de VMware sobre que es UEM, ya que creo que no hay otra manera de resumirlo para que se entienda. User Environment Manager permite personalizar y configurar políticas dinámicas en cualquier entorno de escritorio de Windows virtual, físico y basado en la cloud

#VMwarePorvExperts

686

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

https://www.vmware.com/es/products/user-environment-manager.html

Para entender la frase de VMware, nos situaremos en la gestión de políticas de grupo, las GPOs y más concretamente en todas aquellas que sirven para desplegar configuraciones denominadas Preferencias a nivel de usuario, por ejemplo, despliegue de unidades de red, impresoras, claves de registro, conectores ODBC, etc. Todas estas configuraciones son muy útiles, el problema es que son complejas de administrar cuando hablamos de muchos usuarios con distintos roles y necesidades. https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user.environment. manager-adminguide/GUID-4DC595C5-E460-4069-825D-405AAE4EF72E.html Este sería uno de los tres puntos fuertes de VMware UEM, pero para no perder detalle vamos a verlos de manera detallada más adelante.

8.4.1 Instalación y configuración Docu VMware - Configuring User Environment Manager https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-install-config/GUID-7D5642ED-736A-48BE-8B80-BACDA81E2929.html

VMware UEM es una herramienta de gestión de perfiles que podemos usar en cualquier entorno, tanto físico como virtual, tanto con VMware Horizon como con Citrix, esto es debido a que trabaja directamente con un agente instalado en el equipo cliente y una configuración basada en ficheros que se configura mediante Directivas de Grupo.

Clientes En el apartado del cliente, la instalación es muy sencilla, tan solo necesitamos ejecutar el instalador del agente correspondiente a la arquitectura de nuestro SO, 64 bits o 32 bits.

Consola UEM En cuanto a la parte administrativa de UEM, tampoco es muy complejo, por un lado, tendremos la consola de gestión que puede estar instalada en el equipo que usaremos para configurar el entorno, no instala ningún servicio, ni requiere estar disponible todo el tiempo, tan solo sirve para configurar los archivos de configuración que se aplicaran a los usuarios.

Configuración UEM Para la configuración de VMware UEM, tenemos los directorios donde almacenaremos las configuraciones generales y los perfiles de configuraciones de aplicaciones individuales para cada usuario.

#VMwarePorvExperts

687

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

La carpeta que almacenará la configuración general deberá estar accesible mediante ruta UNC (\\ serfidordearchivos\UEMCONFIG) y dentro de esta se creará una carpeta con el nombre general. Los permisos sobre esta carpeta serán los siguientes: Cuenta de usuario

Sistema

administradores Usuarios UEM

Control Total

Acceso

Se aplica a …

Esta carpeta, subcarpeta y archivos

Control Total

Esta carpeta, subcarpeta y archivos

Lectura y Ejecución

Esta carpeta, subcarpeta y archivos

Para almacenar los perfiles de las configuraciones de las aplicaciones definiremos otra carpeta, también accesible mediante ruta UNC (\\servidordearchivos\UEMPROFILES). Los permisos sobre esta carpeta serán los siguientes: Cuenta de usuario

Sistema

administradores

Control Total

Acceso

Control Total

Lista de carpetas / leer datos1

Se aplica a …

Esta carpeta, subcarpeta y archivos Esta carpeta, subcarpeta y archivos

Crear careptas / Anexar datos1 Usuarios UEM

Leer los atributos1

Esta carpeta solo

Atributos extendidos de lectura1 Creador o Propietario 1 permisos avanzados

Permisos de lectura1 Control Total

Solo archivos y subcarpetas

Con los directorios creados, solo nos queda añadir las plantillas administrativas de VMware UEM a nuestra plataforma de Active Directory y ya podremos configurar el acceso de los usuarios.

#VMwarePorvExperts

688

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

La configuración está basada en usuario, por lo que deberemos aplicar nuestra directiva de grupo sobre las OUs donde residan nuestros usuarios. Existen muchas configuraciones disponibles en las plantillas de UEM, os mostraremos los mínimos y alguno más, para que la plataforma funcione correctamente. User Configuration/Administrative Templates/VMware UEM/FlexEngine •

Flex config files: Directorio UNC de la carpeta de configuración de UEM. •

Central location of Flex config files: \\servidordearchivos\uemconfig\general

•

Process folder recursively: marcado

•

Run FlexEngine as Group Policy Extension: Ejecuta el servicio de FlexEngine durante el inicio de sesión.

•

Profile archives: Directorio UNC de la carpeta de perfiles de los usuarios. Estableceremos la ruta del perfil UEM del usuario y para ello usaremos variables.

•

•

Location: \\servidordearchivos\UEMPROFILES\%username%\

•

Compress profile archive: marcado

•

Retain file modifications date: marcado

FlexEngine logging: Almacena logs de las acciones de UEM sobre el usuario, nos permitirá saber si hay fallos en la aplicación de las configuraciones. Aprovecharemos el directorio de los perfiles para almacenar los logs. •

Path and name of log file: \\servidordearchivos\UEMPROFILES\%username%\logs.

•

Log level: Warn (para no generar excesivos datos sin necesidad).

•

Maximum log file in kb: 512.

#VMwarePorvExperts

689

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

•

Profile archive backups: Nos permite almacenar un copia de seguridad de las configuraciones de las aplicaciones de cada usuario para recuperarla en caso de error o equivocación en una de ellas. •

Location for storing user profile archive backups: \\servidordearchivos\UEMPROFILES\%username%\backups

•

Number of backups per profile archive: 3

•

Create single backup per day: Marcado

User Configuration/Windows Settings/Scripts (Logon/Logoff) •

Logoff: Definiremos una ejecución del programa FlexEngine con un parámetro para el cierre de sesión del usuario. •

Script Name: c:\Program Files\Immidio\Flex Profiles\FlexEngine.exe

•

Script Parameters: -s

Existe una directiva grupo que es necesaria, pero la deberemos aplicar a los equipos donde se vaya a ejecutar el agente de UEM, ya que es una configuración a nivel de equipo. Computar Configuration/Administrative Templates/System/Logon/ •

Esperar siempre a que se inicialice la red en el inicio del equipo y el inicio de sesión: Como el nombre indica, esta configuración hace que el equipo deba esperar el inicio de sesión hasta que la red esté disponible.

8.4.2 Consola VMware UEM Existen tres grandes conceptos en la consola de gestión de VMware UEM. Estos conceptos están distribuidos en tres pestañas y empezaremos a comentarlas de derecha a izquierda.

#VMwarePorvExperts

690

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Condition Sets De lo primero que hablaremos es de la opción de Conditions Sets, lo cual como el nombre indica nos permite crear condiciones preconfiguradas. Las posibilidades de creación de condiciones son tan variadas como, pertenecer a un grupo o Unidad Organizativa de ActiveDiretory, filtrar por versión o arquitectura de SO, filtrar por fechas o día de la semana, filtrar por IP o rango de red, filtrar por existencia de una clave del registro, fichero o carpeta, incluso filtrar por un valor de una variable del sistema (%temp%, %username%, etc.).

Con estas condiciones definidas, podremos aplicarlas a cualquier configuración que queramos implementar dentro de la consola UEM.

User Environment

#VMwarePorvExperts

691

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu VMware - Configuring User Environment Settings https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-adminguide/GUID-3BEEE7A3-A505-479A-BF22-F1ADE24A5619.html

Este apartado es el substituto natural de la Directivas de Grupo a nivel de usuario, de tal manera que podemos aplicar hasta configuraciones de políticas mediante plantillas administrativas tanto del sistema operativo como de aplicaciones de terceros.

Como podéis observar en la imagen, existen muchas configuraciones y vamos a ver algunas de ellas.

ADMX-BASED SETTINGS Las plantillas administrativas que podemos desplegar desde VMware UEM son solo las basadas en Usuarios y no a nivel de Equipo y lo primero que debemos hacer es cargarlas y para ello tan solo debemos indicar al VMware UEM de donde las tiene que recoger. Como es habitual todas las plantillas administrativas las encontramos en la carpeta de los controladores de dominio C:\Windows\PolicyDefinitions en el caso que uséis el Sistema Centra de GPO, estará en \\ dominio.local\SYSVOL\dominio.local\Policies\PolicyDefinitions. Cuando se añaden todas las plantillas administrativas, debemos ejecutar el proceso de validación, de este modo, nos marcará todas las plantillas que no podemos usar y las eliminaremos para mantener el sistema lo más limpio posible.

#VMwarePorvExperts

692

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Una vez cargadas todas las plantillas administrativas de nuestra ubicación, podemos generar una nueva configuración de ADMX.

APPLICATION BLOCKING El nombre no entraña secreto, se nos permite bloquear todas las aplicaciones que no corran dentro de las carpetas C:\Program Files y C:\Program Files (x86), consiguiendo mediante condiciones poder ejecutar aplicaciones fuera de ese ámbito. Primero debemos activar la configuración a nivel de VMware UEM.

#VMwarePorvExperts

693

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Con la configuración general activada, podemos crear bloqueos de aplicación basadas en el Hash del ejecutable, en la ruta de ejecución o basado en el Publicador de la aplicación.

DRIVE MAPPINGS Mapear unidades nunca fue tan sencillo, tan solo debemos crear una configuración y asignar los valores que queramos. Establecemos un nombre a la configuración, podemos usar Label para dar una descripción breve de la

#VMwarePorvExperts

694

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

configuración y Tag para clasificar todas las configuraciones según nos interese. Decidimos la letra de la unidad sobre la que se cargará la carpeta compartida, establecemos la ruta UNC y le damos un nombre amigable para que los usuarios lo identifiquen con facilidad. Respecto a las opciones de aplicación es aconsejable usar tanto la opción “Undo at logoff and refresh during drive mapping refresh” y “Run asynchronously” para que en cada inicio deba volver a reconectar la unidad y además, se pueda ir aplicando los cambio durante toda la sesión del usuario y no solo aplicarlo en el inicio de sesión.

Si vamos a las Conditions, podremos establecer condiciones únicas para esta configuración o aprovechar para usar las Conditions Sets que hemos establecido al principio, además se puede usar múltiples condiciones usando operadores de OR, AND o NOT.

FILE TYPE ASSOCIATIONS Podemos establecer de una manera gráfica, las aplicaciones que abren cada uno de los tipos de archivos que nos interesa.

#VMwarePorvExperts

695

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Además, podemos establecer la apertura de un archivo realizando una condición de si existe el programa, es decir, si la asociación de un .docx es con la aplicación Word, que lo aplique solo en el caso que exista en la ruta de instalación el programa WINWORD.exe.

FOLDER REDIRECTION Así como hemos visto que podemos redirecciona las carpetas de usuario mediante las GPOs o mediante Persona Management, VMware UEM no es una excepción y permite redirigir las carpetas que nos interesa hacia una ruta UNC compartida para almacenar los datos. La ventaja de aplicar esta configuración mediante UEM es que podemos añadir condiciones para establecer una ruta u otra según la condición que nos interese y no complicarnos la vida con las GPOs.

#VMwarePorvExperts

696

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

PRINTER MAPPINGS Las impresoras son un apartado que lleva de cabeza a los administradores, desde siempre, y bajo mi experiencia, puedo deciros que este apartado es el menos aprovechable, ya que no gestiona drives, colas ni mejora la asignación que podemos hacer con GPOs. Aun así, permite asignar colas de impresión de una manera sencilla mediante las condiciones.

#VMwarePorvExperts

697

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

PRIVILEGE ELEVATION Este apartado compensa el uso de VMware UEM en cualquier escenario, ya que como el nombre nos indica, nos permite establecer aplicaciones para que se ejecuten con permisos elevados sin necesidad de credenciales de administrador. Por ejemplo, todos nos hemos encontrado una aplicación que requiere de permisos de administrador para ejecutarse, porque trabaja sobre directorios del sistema operativo y cuando esto lo trasladamos a un usuario, o le entregamos un usuario con privilegios o debemos hacerlo administrador local del equipo, para que pueda usar la aplicación, lo cual implica muchos riesgos. La idea es que nosotros establezcamos que aplicaciones serán usadas con privilegios elevados, de este modo, el usuario no será administrador local y no deberemos entregar ningún usuario que pueda comprometer la integridad del equipo. También es muy útil para instalación de aplicaciones controladas, que requieren elevación de permisos y por algún motivo lo deben realizar los propios usuarios y no el administrador. Lo primero es activar la característica y en caso de las imágenes hemos añadido un mensaje cuando se ejecuta una aplicación con permisos elevados.

#VMwarePorvExperts

698

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Podemos configurar la elevación de permisos, mediante varios tipos de validación, basado en Ruta, en Hash, en Publicador y en Argumento.

Podemos usar tanto una carpeta como un archivo concreto, siempre que sea un ejecutable .exe. incluso que los procesos derivados del principal también sean ejecutados con privilegios elevados.

REGISTRY SETTINGS El proceso para poder aplicar claves del registro mediante VMware UEM, es muy simple, configuramos las claves en un equipo y las exportamos.

#VMwarePorvExperts

699

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Ahora cuando creamos nuestra configuración lo que haremos es Importar el archivo, con todo su contenido, el cual será volcado en el usuario al que aplique mediante las condiciones.

SHORTCUTS Mucho menos complejo, pero muy útil es aprovisionar accesos directos de lo que nos interese, ya sea en el escritorio o en menú de aplicaciones de los usuarios y como en todos los apartados mediante condiciones que nos aportan una flexibilidad muy completa.

#VMwarePorvExperts

700

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Personalization Este apartado, quizás es el más complejo de entender de la herramienta de VMware UEM, pero a su vez es un concepto muy interesante y potente. Lo que nos permite esta configuración es almacenar las configuraciones de las aplicaciones que queremos para que, sí un usuario inicia sesión en otro equipo que no es el suyo, conserve todas las configuraciones que haya realizado, por ejemplo, accesos directos dentro de Microsoft Office, configurar la calculadora en modo científico, personalizaciones del Chrome o Firefox, etc. Esto no solo aplica a las aplicaciones de terceros, también permite aplicarlo a cosas tan útiles como los certificados instalados, impresoras mapeadas, barra de tareas, contraseñas de Internet Explorer o Microsoft Edge, entre otras. Para facilitar esta adopción VMware UEM ya dispone de plantillas de aplicaciones y configuraciones de Windows almacenadas que podemos usar con muy poco esfuerzo, pero también dispone de una herramienta para capturar una aplicación y poder añadirla al UEM para gestionarla. Además, podrán ser ordenadas mediante carpetas.

AÑADIR CONFIGURACIÓN DE WINDOWS

#VMwarePorvExperts

701

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Docu VMware - Create a Flex Configuration File by Using Windows Common Settings https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-adminguide/GUID-5BA465FD-388B-4FDA-B323-C7117B462AAC.html

Lo primero que veremos es como podemos añadir una configuración de Windows en el UEM para almacenar las configuraciones del usuario, mediante una las plantillas disponibles. Al iniciar Create Config File, podemos escoger entre crearla de cero o usar plantillas y en este caso seleccionamos Use a Windows Common Setting

Seleccionamos Personal Certificates – AppData NOT redirected para que todas las configuraciones de los usuarios hechas en los certificados puedan ser almacenadas por VMware UEM.

Como podemos observar ya tenemos disponible la configuración, pero si miramos la pestaña de Import / Export está vacía, esto es debido a que estamos usando una plantilla de UEM y si queremos ver que importa y exporta esta configuración, nos dirigiremos a Manage y Expand.

#VMwarePorvExperts

702

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Para entender cómo funciona este apartado de Personalization, podemos ver que sobre el archivo de configuración se introducen secciones de [IncludeRegistryTrees], [IncludeFolderTrees], [ExcludeRegistryTrees], entre otro que podemos añadir desde el botón superior Section. En estas secciones definimos que datos ha de exportar e importar el agente de UEM para conservar los datos del usuario, en el caso de esta configuración son unas rutas del registro de Windows, excluyendo una clave en particular y unas rutas de carpetas del perfil del usuario. Este apartado es completamente editable, puesto que nosotros podemos definir las necesidades y configuraciones que queramos para que sean exportadas o no.

AÑADIR APLICACIÓN CON PLANTILLA Docu VMware - Create a Flex Configuration File by Using an Application Template https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-adminguide/GUID-F6129695-3B26-4906-AD28-26AC2F46C640.html

Si repetimos el proceso de crear un archivo de configuración, nos centraremos en usar la opción de Use Application Template y seleccionaremos la Calculadora.

#VMwarePorvExperts

703

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Si expandimos la configuración como hemos realizado en la configuración de Windows, veremos que tan solo exporta una clave de registro para almacenar las configuraciones hechas sobre la aplicación Calculadora.

AÑADIR APLICACIÓN CON PLANTILLA ONLINE Docu VMware - Download Configuration Templates https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-adminguide/GUID-53CB386F-B6F9-408C-B461-051C2E254A11.html

#VMwarePorvExperts

704

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Si os habéis fijado en el anterior proceso, no es que dispongamos de muchas plantillas de aplicaciones, pero como la comunidad VMware es infinita, se ha creado un repositorio donde la gente aporta plantillas ya generadas y podemos descargarlas y añadirlas a nuestra plataforma. https://communities.vmware.com/community/vmtn/user-environment-manager/ content?filterID=contentstatus[published]~objecttype~objecttype[document] VMware, para facilitar la adopción de algunas plantillas de aplicaciones, ha añadido una opción, en la consola de UEM, que nos permite conectarnos con las credenciales de my.vmware.com y añadir las plantillas directamente. Podemos seleccionar una o varias aplicaciones y guardarlas en nuestra plataforma de UEM para poder empezar a usarlas.

AÑADIR APLICACIÓN PROPIA Y ESTABLECER CONFIGURACIÓN Docu VMware - Create a Flex Configuration File by Using Application Profiler https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user. environment.manager-adminguide/GUID-4B10FEF2-25FE-4EE7-9D2A-42E6BDC212BF.html

#VMwarePorvExperts

705

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Aun existiendo infinidad de plantillas ya preparadas dentro de la comunidad de VMware, siempre nos podemos encontrar con alguna que no existe y que debemos usar en nuestro entorno, por ello existe una aplicación, Application Profiler, que instalaremos sobre un equipo, donde no esté el agente de UEM, para poder generar nosotros mismos archivos de configuración de la aplicación que nos interese. Además, podremos definir una configuración predeterminada.

La finalidad de este proceso es capturar una de las aplicaciones instaladas sobre el equipo donde hemos instalado el Application Profiler, de esto modo, podremos saber que rutas del perfil, tanto registro como archivos, modifica la aplicación para poder capturarlo a nuestros usuarios. Además, este proceso nos permite modificar la aplicación capturada, por ejemplo, el aspecto o la configuración de parámetros concretos y almacenar esa información para establecerla como configuración predeterminada a todos los usuarios. Durante el proceso de guardar la configuración deberemos elegir “Save config dile and Predefined Settings”.

Con el archivo almacenado en la carpeta de UEM (\\servidordearchivos\uemconfig\general) podemos acceder a la consola y entrar en la configuración de la aplicación.

#VMwarePorvExperts

706

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

PREDEFINED SETTINGS

En la pestaña Predefines Settings, podemos comprobar que se ha generado una entrada y al editarla, veremos las opciones para aplicar esta configuración. •

Default Settings: Se aplica cuando no existe una configuración definida en la carpeta del perfil de usuario.

•

Partial Enforced Settings: Se aplica siempre, antes de importar el perfil a la sesión del usuario.

•

Default Settings with Partial Enforced Settings: Se combinan ambas configuraciones anteriores, pudiendo ser configuraciones distintas.

•

Full Enforced Setting: Se aplica siempre la configuración definida, aun que el usuario la cambie.

BACKUPS

Otras de las pestañas que podemos comentar en la aplicación son la de Backups, que permite modificar la configuración definida por la Directiva de Grupo para una aplicación concreta.

#VMwarePorvExperts

707

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

DIRECTFLEX

La pestaña de DirectFlex es muy interesante e importante saber cómo se comporta. Para evitar un inicio de sesión del usuario, muy lento, DirectFlex permite realizar la importación de los datos almacenados sobre la aplicación cuando esta se ejecute por primera vez, permitiendo así reducir el tiempo de inicio de sesión. Es probable que en algunas situaciones sea mejor desactivar DirectFlex para evitar que el primer arranque de la aplicación sea demasiado lento y asumir ese tiempo en el inicio de sesión de equipo virtual.

CONDITIONS

En las pestañas, como no puede ser de otra manera podemos encontrar Conditions para aplicarlas directamente sobre una aplicación, para que esta configuración no sea usada para todos los usuarios.

Encontramos una pestaña muy interesante, la de User Enviroment, que como podemos deducir, nos permitirá realizar cualquier configuración que nos interese sobre esta aplicación, unidades de red, impresoras, tareas de pre-importación, post-importación, claves del registro, etc…

#VMwarePorvExperts

708

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

9. Gestión de aplicaciones Qué sentido tendría implantar una infraestructura de virtualización de escritorios, si luego gestionamos las aplicaciones del mismo modo que en un entorno tradicional. Por ello, no vamos a entrar en entornos de despliegue de aplicaciones como las GPO mediante msi o con plataformas como System Center de Microsoft.

9.1 Aplicaciones en plantilla El método más simple para aprovisionar aplicaciones a los escritorios virtuales es desplegar estas, mediante una instalación tradicional sobre la plantilla base que usaremos para generar los escritorios virtuales. Esta opción es la más recomendada para todas aquellas aplicaciones comunes para los usuarios de nuestra empresa como, un visor de PDFs, un programa de compresión de archivos (7zip, WinZip, WinRAR, etc.), un editor de texto avanzado, incluso algún navegador que no sea el propio del sistema Windows 10 como Google Chrome o Firefox. También instalaremos todos los programas básicos de sistemas internos que se requieran, como el antivirus, alguno de acceso remoto como VNC, TeamViewer o AnyDesk, los agentes de Horizon, UEM o AppVolumes. Todas estas aplicaciones tendrán algo en común y es que para poder actualizarlas o instalar nuevas versiones, será imprescindible hacerlo siempre en la plantilla base y luego realizar la tarea de regenerar los escritorios virtuales para que todos dispongan de estos cambios. Es, por tanto, un método muy poco útil para aplicaciones que solo afectan a un grupo de usuarios, por ejemplo, los usuarios de RRHH no tendrán las mismas aplicaciones que los usuarios de Contabilidad y esto implica que no pueden estar en la plantilla base, por lo que buscaremos otro método para desplegar estas aplicaciones.

9.2 Aplicaciones de escritorio remoto (RDS)

Docu www.cenabit.com - Granja RDS en Horizon 7 con Instant clone. Preparar Windows Server 2016 https://www.cenabit.com/2017/07/granja-rds-en-horizon-7-con-instant-clone-preparar-windowsserver-2016/ Docu www.cenabit.com - Granja RDS en Horizon 7 con Instant clone. Crear la Granja RDS http://www.cenabit.com/2017/08/granja-rds-horizon-7-instant-clone-crear-la-granja-rds/

#VMwarePorvExperts

709

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Este tipo de aplicaciones, no nos sorprenderán, pues es básicamente lo que podemos encontrar con Microsoft RemoteApps o Citrix XenApps. Mediante los servicios de Escritorio Remoto de Windows podemos aprovisionar aplicaciones directamente al cliente de Horizon o podemos incluir estas aplicaciones en los escritorios virtuales usando el protocolo de VMware Blast. Lo primero que debemos tener en cuenta es que estos servidores deberán disponer de un servidor de licencias de Remote Desktop Services (RDS) licenciado para tantos usuarios que necesitemos aprovisionar aplicaciones, lo cual implica un coste añadido. Por otro lado, todas las aplicaciones que queramos aprovisionar deberán estar instaladas en uno o varios servidores por lo que hay que tener en consideración licencias, espacio en disco, RAM, etc. En definitiva, un grupo de servidores más que mantener en nuestra infraestructura. Hablamos de un grupo de servidores porque la mayor ventaja de aprovisionar servidores de RDS es usar la tecnología de Instant Clone o Linked Clone para aprovisionar más o menos servidores en función de las necesidades de un momento determinado. Gracias a estas tecnologías podremos pasar de 2 servidores RDSH a 5 sin ningún esfuerzo.

9.3 Aplicaciones Thinapp

Docu VMware - VMware ThinApp User’s Guide https://docs.vmware.com/en/VMware-ThinApp/5.2.4/com.vmware.thinapp.user/GUIDB289AEDC-9080-4373-9C14-16F1D068ED08.html

#VMwarePorvExperts

710

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

El sistema de virtualización de aplicaciones conocido como ThinApp fue el primer método que VMware puso a disposición de los usuarios. ThinApp permite encapsular toda la instalación de una aplicación en un archivo ejecutable .exe que almacenará los archivos de instalación, configuración, claves de registro e incluso accesos directos creados. Una aplicación de ThinApp que requiera dependencias de otra, como podrías ser un Framework específico, deberá ser encapsulada dentro de la misma para evitar problemas de ejecución. Esta aplicación se ejecuta desde una carpeta compartida y de manera aislada al escritorio desde donde la lanzamos, esto permite disponer de una aplicación que solo se ejecuta sobre Windows XP en un entorno de Windows 7, 8 o 10 incluso en Windows Server. Esto permite usar ThinApp tanto en escritorios virtuales como en escritorios físicos. Solo permitirá asignar esta aplicación por usuario, lo cual implica bastante gestión para el administrador, además el aprovisionamiento de la aplicación asignada solo se podrá hacer en el inicio de la sesión, impidiendo realizar un cambio en tiempo real sobre el usuario. La consideración más importante para tener en cuenta para desplegar una aplicación con ThinApp es, realizar una prueba con la aplicación, pues la experiencia de uso, en ocasiones, difiere mucho de lo esperado.

9.4 VMware App Volumes

Docu VMware - VMware App Volumes Documentation https://docs.vmware.com/en/VMware-App-Volumes/index.html

La tecnología AppVolumes es lo más nuevo de VMware en cuanto a virtualización de aplicaciones y en esencia es muy parecida a ThinApp. Se encapsula la instalación de una aplicación, o varias, sobre un .vmdk que se llamará AppStack y podrá ser aprovisionado de distintas maneras, por usuario, grupo de usuarios, equipos o incluso, Unidad Organizativa.

#VMwarePorvExperts

711

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Cuando se asigna un AppStack, podemos aprovisionarlo en tiempo real sobre el escritorio del usuario, consiguiendo un despliegue instantáneo. Incluso podemos retirar un AppStack a los usuarios y en el mismo momento asignar un nuevo, sin necesidad de que cierren la sesión, como pasa en ThinApp. Esto permite ser mucho más flexible con todas las aplicaciones que queremos aprovisionar. También encontraremos un nuevo concepto que son los Writable Volumes, discos que permiten almacenar modificaciones de SO y/o del perfil de usuario de manera que se fusiona con el disco del escritorio virtual al que se conectó. Ejemplo, disponemos de un escritorio virtual sin posibilidad de instalar ninguna aplicación porque en cada cierre de sesión se restablece. Si sobre un usuario cargamos un Writable Volume y realizamos una instalación de una aplicación esta permanecerá sobre el Writable Volume cargándola en cada sesión de este usuario independientemente si el escritorio al que se conecta tiene la aplicación instalada.

#VMwarePorvExperts

712

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

9.4.1 Instalación y configuración Docu VMware - Installing App Volumes https://docs.vmware.com/en/VMware-App-Volumes/2.15/com.vmware.appvolumes.install.doc/ GUID-25B53F4E-C22B-4DBD-A253-D7FA33D965BF.html

Servidor Para poder instalar App Volumes, es necesario disponer de una base de datos de Microsoft SQL Server, podemos usar la versión Express, teniendo en cuenta los límites de tamaño y rendimiento. Lo ideal es si ya disponéis de un MS SQL en la empresa, generar una instancia para almacenar la base de datos.

Cliente Cuando ya disponemos del servidor instalado, podemos instalar el agente. El agente durante la instalación nos requerirá la dirección del servidor de App Volumes, esta configuración podrá ser cambiada más adelante mediante claves del registro de Windows. Además, durante la instalación deberemos especificar si omitimos los errores de certificados entre la conexión del cliente-servidor.

#VMwarePorvExperts

713

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Configuración Docu VMware - Configuring App Volumes Manager https://docs.vmware.com/en/VMware-App-Volumes/2.15/com.vmware.appvolumes.admin.doc/ GUID-3E512951-4045-4C15-A642-69BBCF4C34B6.html

Para la configuración de App Volumes, existe un asistente la primera vez que accedemos al portal web de administración. Este asistente te guiará por las configuraciones necesarias para poner a punto la plataforma.

LICENSE

Cargamos el archivo de licencia descargado de nuestro portal de my.vmware.com.

ADD DOMAINS

Introduciremos los servidores de Active Directory de los cuales leeremos la información para poder asignar AppStacks por grupo, usuario o Unidad Organizativa.

ADMIN ROLES

Seleccionaremos un grupo o usuario para asignarle los roles de administrador de App Volumes, recordad que siempre es mejor trabajar con grupos para agilizar los permisos.

MACHINE MANAGERS

En este apartado, conectaremos con nuestra plataforma de vSphere, conectando directamente con el vCenter.

STORAGE

En este apartado tenemos que indicar sobre que Datastore queremos almacenar los AppStacks y las plantillas de los AppStacks, también definiremos el Datastore donde guardaremos los Writable Volumes y sus plantillas. En este momento también deberemos cargar las plantillas predefinidas de la plataforma para empezar a generar AppStacks.

9.4.2 Consola App Volumes En la consola de App Volumes disponemos de todo lo necesario para crear, adjuntar y controlar los AppStack y Writable Volumes.

#VMwarePorvExperts

714

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Volumes En este apartado encontraremos tres pestañas de control que son:

ATTACHMENTS

Nos permite ver todas AppStacks y los Writable Volumes que están añadidos a los equipos virtuales.

ASSIGNMENTS

Podemos ver un listado de las asignaciones de toda nuestra plataforma, ya sean usuarios, grupos, equipos o Unidades Organizativas.

APLICATIONS

Nos lista todas las aplicaciones que App Volumes ha detectado en los AppStacks que hemos creado y nos indica en cual están instalados. Además de lo comentado, existen dos pestañas que pasaremos a comentar con más detalle.

APPSTACK

Esta ventana será la más usada en la gestión de App Volumes, ya que nos permitirá crear AppStacks, asignarlos y además saber quién tiene conectado el AppStack.

Cuando generamos un nuevo AppStack, debemos especificar a partir de que plantilla se genera. La plantilla que hemos cargado durante la configuración es un disco de 20GB en modo Thin Provisioning

#VMwarePorvExperts

715

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

completamente vacío. Cuando realizamos el proceso de Provisioning, lo que hacemos es cargar este disco vacío en una VM con el agente instalado, para poder instalar las aplicaciones que queramos. Una vez terminado el proceso, ya tenemos disponible este AppStack para asignarlo a los usuarios. Podemos generar nuevas plantillas de AppStack, tan solo copiando, a nivel de vSphere, el archivo .vmdk a la carpeta donde se almacenan las plantillas cloudvolumes\app_template y al generar un nuevo AppStack ya podremos seleccionarlo como plantilla.

Otra de las funciones que encontraremos en la gestión de AppStacks es el Update, el cual genera un nuevo AppStack a partir del que ya existe para realizar algún cambio en él, por ejemplo, actualizaciones de las aplicaciones o añadir aplicaciones nuevas a un AppStack. La asignación de AppStaks se puede hacer por usuario, grupo de usuarios, equipos o unidad organizativa, ya sea de equipos o usuarios.

WRITABLES

Aquí, podremos crear los Writable Volumes y comprobar si están conectados. Además, dispondremos de opciones sobre ellos, como desactivar un Writable Volume, Expandirlo, moverlo de ubicación, realizar una copia de seguridad o restaurar de una ya realizada, incluso eliminarlo. Existen varios tipos de plantillas de Writable Volumes, dependiendo lo que queramos almacenar. •

Template_profile_only_workstation: Almacena solamente en el perfil del usuario.

•

Template_uia_only_workstation: Almacena solamente la parte de SO.

•

Template_uia_plus_profile_workstation: Almacena tanto la parte de SO como el perfil del usuario.

Así como los AppStack se pueden asignar a equipos virtuales, los Writable Volumes solo se pueden asignar a nivel de usuario. Podemos crear los discos de manera individual o especificar un grupo de seguridad y en el momento que el usuario acceda a un escritorio con el agente de App Volumes instalado, se genere el Writable Volume.

#VMwarePorvExperts

716

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

IMPORTANTE. No es posible usar Writable Volume con asignación de AppStack a nivel de equipo, esto es debido a que para añadir los volumenes el orden siempre deber ser, primero Writable Volume y luego los AppStacks, si enlazamos primero lo de máquina, no puede cargar los Writable Volume porque se cargan a nivel de usuario.

Directory En este apartado encontraremos todo lo Reference a los datos de los usuarios, grupos, equipos virtuales y Unidades organizativas que tenemos en uso. Si accedemos a un usuario o equipo, nos dará información tan valiosa como si está Online, que volúmenes tiene conectados en ese momento, que AppStack o Writable Volume tiene asignado, incluso las veces que se ha logeado.

Infraestructure Podemos ver la información de los equipos registrados con el agente sobre nuestra plataforma y su estado, además de ver el almacenamiento y crear grupos de almacenamiento. Estos grupos de almacenamiento nos permitirán replicar o distribuir los AppStacks y Writable Volumes entre varios Datastores.

Activity Veremos todas las tareas pendientes, logs de actividad, mensajes de sistema, log del servidor y tenemos un apartado de Troubleshooting que nos permite crear archivos de log en formato zip para enviar a soporte o analizarlo por nuestra cuenta.

#VMwarePorvExperts

717

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

Configuration Como podemos decidir, este apartado nos permitirá cambiar cualquier configuración de la plataforma, que hemos configurado en el asistente inicial. Conectarnos a un nuevo vCenter, añadir un nuevo dominio de Active Directory, administrar los roles de acceso, cargar una nueva licencia, modificar los datastores y rutas donde se almacenan los AppStacks y Writable Volumes y desde el apartado de settings, podremos establecer una programación para realizará backup en otro Datastore de los Writable Volumes. Una parte que deberemos controlar es que cuando se lanza una actualización de App Volumes, es probable que se mejoren o amplíen las plantillas predeterminadas y si queremos actualizarlas deberemos recargarlas desde la pestaña de Storage.

#VMwarePorvExperts

718

Capítulo 12 - VDI con Horizon View Ricard Ibáñez

#VMwarePorvExperts

719

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

720

Capítulo 13 Citrix en vSphere

Héctor Herrero

#VMwarePorvExperts

721

Capítulo 13 - Citrix en vSphere Héctor Herrero

1. Qué vamos a ver En este capítulo vamos a conocer qué nos pueden ofrecer los productos Citrix, cómo dimensionarlos en un entorno virtual de VMware vSphere, algunas recomendaciones, unas mejores prácticas y una pequeña comparativa de Citrix y VMware. Los puestos de trabajo y la forma de desempeñar nuestro trabajo han cambiado mucho en los últimos 30 años, gracias Internet, a las nuevas tecnologías móviles o tecnologías de virtualización entre otras. Citrix desde entonces viene desarrollando tecnologías que permiten a las empresas que apuestan en innovación IT el poder permitir trabajar a sus profesionales de la manera más óptima.

Una empresa histórica, fundada en 1989, inicialmente se llamaba Citrus; diseñó un protocolo popular llamado ICA (Independent Computing Architecture) para el producto WinFrame en la época de Windows NT; que permitía trabajar a los usuarios de forma remota y segura. Estos productos han ido evolucionando desde entonces y los hemos conocido como Metaframe, Presentation Server, XenApp o XenDesktop. Desde entonces, Citrix es la compañía líder en la entrega de aplicaciones y escritorios virtuales. En este capítulo nos basaremos únicamente en los productos orientados a la entrega de recursos a los usuarios.

 

#VMwarePorvExperts

722

Capítulo 13 - Citrix en vSphere Héctor Herrero

2. Entrega tradicional Cualquier empleado para poder desempeñar su trabajo necesitará acceder a ciertos aplicativos, podemos como tradicionalmente darle un PC con software instalado y configurado. Esta opción menos segura y más costosa nos hará peligrar la credibilidad de nuestro departamento de IT, ya que:

•

Está descentralizado, los datos se almacenan en cada puesto y se pueden perder (fugas de información, roturas del equipo, robos…)

•

Costes de operaciones elevados, cada equipo requiere de su mantenimiento, tanto de software como de hardware. La instalación del software es manual y se hacen infinitas instalaciones. A parte necesitaremos licencias de antivirus, de copias de seguridad…

•

Descontrol, cada empleado tiene diferentes versiones de software o quizá aplicaciones de más. Pueden conectar cualquier dispositivo al equipo y no con buen fin.

•

Largo etcétera…

#VMwarePorvExperts

723

Capítulo 13 - Citrix en vSphere Héctor Herrero

3. Entrega con Virtual Apps and Desktops Virtual Apps and Desktops es la solución que nos proporciona Citrix para la entrega de aplicaciones y escritorios Podremos entregar aplicaciones Windows o Linux, así como sus escritorios a nuestros usuarios. Centralizaremos, securizaremos, y sobre todo tendremos control de nuestro entorno, ya que todos los datos residirán en nuestro centro de datos y nunca más saldrán de él; todo se ejecutará bajo los recursos de equipos del CPD evitaremos las pérdidas o fugas de datos. Los usuarios mediante un cliente ligero o un navegador podrán abrir sus aplicaciones corporativas o trabajar mediante el escritorio que le entreguemos sin mayor diferencia al trabajo tradicional. Y sí cualquier tipo de aplicación, sean las tradicionales de una oficina, así como las que requieran carga multimedia, entornos 3D… en equipos thinclient. Tendremos servidores para alojar múltiples sesiones de usuarios, permitiéndoles a todos ellos trabajar de forma conjunta sobre una sola MV. Podremos entregar las aplicaciones que tengan estos servidores instaladas, asociaremos mediante permisos qué usuarios tienen visibilidad sobre qué apps. O directamente podremos entregarles todo el escritorio del servidor si es que lo preferimos, este debate lo tendremos más adelante. Como podemos imaginar, otro de los grandes beneficios la virtualización de apps y desktops es la unificación de software, ya que todos los usuarios tendrán las mismas versiones de los productos de nuestra empresa; nos simplificará las actualizaciones de software o la implantación de uno nuevo en apenas minutos. Y por supuesto la movilidad, podrán acceder a sus aplicaciones desde la empresa, desde el hotel, casa... de igual manera y con la misma seguridad. Al ejecutarse todo en el centro de datos, podemos ahorrar costes de mantenimiento e incorporar en nuestras empresas equipos thinclient que nunca más requerirán reemplazos o costes de licenciamiento, agentes... Cada usuario, accederá con sus credenciales mediante un portal corporativo totalmente personalizado que les facilitará el acceso a los recursos que necesiten, además con diseños y estilos mobile si es que se accede desde tablets o smartphones.

#VMwarePorvExperts

724

Capítulo 13 - Citrix en vSphere Héctor Herrero

4. Componentes Citrix Virtual Apps and Desktops, anteriormente conocido como XenApp para la entrega de aplicaciones o XenDesktop para la entrega de escritorios, están compuestos de diferentes componentes que realizan distintas funciones, tenemos:

•

Delivery Controller:

Es el componente central de los Sitios de Virtual Apps and Desktops. Se instalará normalmente en una máquina Windows Server dedicada y podremos ir añadiendo tantos Delivery Controller cómo nos interese para repartir la carga y disponer de un entorno tolerante a fallos. Es el Broker de sesiones de nuestro entorno, quien autenticará y administrará los accesos a los recursos de los usuarios. Realiza un seguimiento de los usuarios, conociendo en todo momento donde se han logueado y que recursos disponen, así como les permite reconectarse en caso de necesidad a sus apps o desktops. Podrá conectarse a nuestra plataforma VMware vSphere para aprovisionar máquinas virtuales de manera totalmente integrada. Y Delivery Controller por supuesto podrá administrar el estado de las máquinas, pudiendo iniciarlas o apagarlas en base a la demanda existente.

•

Base de datos

Toda la configuración del sitio Citrix Virtual Apps and Desktops; así como los registros del mismo, sean históricos de conexiones de los usuarios o acciones realizadas por los administradores quedan almacenados en bases de datos. Las bases de datos se almacenarán en un servidor Microsoft SQL Server, en entornos muy pequeños un SQL Express sobre el Delivery Controller sería suficiente. Pero queda clara la importancia de la disponibilidad de las BBDD, por tanto, una solución de alta disponibilidad será importante, algo como SQL Database Mirroring puede ayudarnos y permitir que Delivery Controller siempre tenga conectividad. También es recomendable habilitar y configurar LHC o Local Host Caché en el Broker para seguir dando servicio sin conectividad a BD. De manera predeterminada, estas tres bases de datos se instalan en la misma ubicación que la BD del sitio; aunque esto se podría modificar.

•

Servidor de licencias:

Este servicio administra las licencias del entorno Citrix. Descargaremos desde MyCitrix.com nuestras licencias en archivos con formato .lic y las importaremos; dependerá de ello nos dará uso a diferente edición de producto. Delivery Controller se comunica con él para administrar la licencia de cada usuario o dispositivo que se conecte, mediante un licenciamiento nominal (asociada al usuario) o concurrente (carga simultánea). Si este servicio cae, tendríamos un periodo de gracia de 30 días hasta solventar el problema; por tanto, en este caso no es muy habitual tener entornos de alta disponibilidad. Se puede instalar en una máquina dedicada o en el propio Delivery Controller en entornos pequeños. Se dispone consola de una administración web donde se pueden gestionar directamente con nuestra cuenta de MyCitrix, las licencias se almacenarán en %programfiles(x86)%\Citrix\Licensing\MyFiles

•

VDA o Virtual Delivery Agent

Es un agente que se instala en cada máquina que vamos a entregar a los usuarios, permitirá que los usuarios se conecten a la máquina y utilicen sus recursos para trabajar. Esta máquina podrá compartir

#VMwarePorvExperts

725

Capítulo 13 - Citrix en vSphere Héctor Herrero

sus aplicaciones y su escritorio, podrá ser virtual o física, y correr bajo Windows o Linux. En el caso de usar edición de Server será multiusuario y por tanto múltiples usuarios de forma simultánea podrán trabajar, o si es Desktop, un usuario por máquina. Los VDA se registrarán contra Delivery Controller para comunicar su estado o la información de las sesiones de los usuarios de manera constante, así como su disponibilidad. El usuario al establecer la conexión con el equipo VDA podrá redirigir cualquier dispositivo que tenga en local, para trabajar de igual forma, sean impresoras, lectores de tarjetas, dispositivos USB, cámaras, micrófonos… Gracias a un solo protocolo seguro y optimizado llamado HDX (anteriormente ICA).

•

Citrix StoreFront

Es el frontal, el servicio que autentica a los usuarios y les presenta sus recursos, permite el autoservicio a los escritorios y aplicaciones a las que tienen acceso; podemos pensar en él como en nuestro Store corporativo, nuestra tienda de apps o escritorios. Instalaremos al menos un servidor Storefront en la organización, en entornos muy pequeños podría convivir con Delivery Services. Lo normal será dedicarle una máquina, así como pensar tener alta disponibilidad y balanceo de carga gracias a los Grupos de servidores, donde el servidor principal replicará su configuración al resto de StoreFront miembros. Para facilitar y hacer más familiar el entorno, customizaremos el portal Web con nuestra imagen corporativa.

•

Citrix Workspace App

Es el cliente ligero de Citrix que permitirá conectar al usuario con los recursos de la empresa, anteriormente conocido como Citrix Receiver. Se instala en los dispositivos que usará para conectarse, sea un PC, un ThinClient, una Tablet o un Smartphone con Windows, Linux, Mac, iOs o Android. Ofrece a los usuarios un acceso rápido, seguro y de autoservicio a sus aplicaciones, escritorios o documentos. En dispositivos donde no podamos instalar este cliente, podremos sencillamente acceder a la plataforma Citrix con un navegador compatible con HTML5 directamente, gracias a Citrix Workspace app for HTML5,

•

Citrix Studio

Es la consola de administración, nos permitirá administrar y configurar nuestro Sitio de Citrix Virtual Apps and Desktops. Una única consola para administrar la entrega de las aplicaciones y escritorios a los usuarios; intuitiva y basada en asistentes, nos simplificará los despliegues de recursos y cualquier configuración necesaria en el entorno. Desde la misma podremos agrupar nuestras máquinas en Catálogos, entregar sus recursos mediante Grupos de Entrega, configurar el licenciamiento, conectividad con entornos virtuales o cloud… La mayoría de la configuración la realizaremos mediante las Directivas, tenemos un repositorio con cualquier tipo de configuración que necesitemos, que luego la aplicaremos de la mejor manera que nos interese. La consola Citrix Studio trabaja contra Delivery Controller, tendremos que tenerla instalada en cualquier equipo Windows, una buena práctica es instalarla en los VDA y publicarla.

•

Citrix Director

Con cualquier navegador podremos acceder a esta consola web, que nos permitirá a los técnicos monitorizar y supervisar el entorno de nuestro sitio Citrix en tiempo real. Una consola que nos mostrará

#VMwarePorvExperts

726

Capítulo 13 - Citrix en vSphere Héctor Herrero

las principales alertas de nuestro sitio para que podamos anticiparnos a cualquier eventualidad. Desde aquí también podremos realizar las tareas más comunes sobre los usuarios o grupos, como son: ver información de su sesión, aplicaciones, procesos, conexión, tráfico HDX, datos históricos… y por supuesto la de interactuar con los usuarios, pudiendo controlar remotamente su sesión por si tienen cualquier incidencia. Con una instancia de Citrix Director podemos conectarnos a distintos sitios de Citrix.

Componentes adicionales:

•

NetScaler Gateway

NetScaler es un appliance virtual (o físico) que optimiza, protege y controla la entrega de recursos. En, en el libro nos basaremos únicamente en la parte Gateway, que nos permitirá acceso seguro a nuestros recursos desde el exterior. Los usuarios podrán abrir aplicaciones o escritorios desde el exterior con 1 sólo puerto, HTTPS. Mediante dicho puerto NetScaler Gateway encapsulará todo lo que el usuario necesite para trabajar, visualización, dispositivos, impresión, audio, video…

•

Provisioning Services

Es un servicio que permite aprovisionar imágenes preconfiguradas de Sistemas Operativos por red. Podremos usarlo con Virtual Apps and Desktops para crear tantos servidores o escritorios cómo necesitemos para soportar la carga de nuestros empleados.

 

#VMwarePorvExperts

727

Capítulo 13 - Citrix en vSphere Héctor Herrero

5. Arquitectura

Imagen donde podemos apreciar las distintas capas que componen nuestras infraestructuras y la ubicación de cada componente.

#VMwarePorvExperts

728

Capítulo 13 - Citrix en vSphere Héctor Herrero

6. Mapa de puertos

En la imagen superior podemos apreciar los puertos que utilizan los principales componentes de Citrix para comunicarse entre sí. Si deseas tener más información sobre todos los puertos utilizados en cualquier componente puedes echar un vistazo a: https://support.citrix.com/article/CTX101810

#VMwarePorvExperts

729

Capítulo 13 - Citrix en vSphere Héctor Herrero

7. Citrix vs VMware No es objeto de este capitulo realizar una comparativa que confronte los distintos productos de los fabricantes, si no mostrar que opciones nos ofrecen y poder realizar símiles entre ellos. Cada empresa de virtualización trabaja continuamente por mejorar sus estrategias y sus productos, es en estos últimos años donde más se han recortado las distancias. Tanto Microsoft, como VMware o Citrix, que copan el mercado, disponen productos de lo más interesantes. Microsoft es un actor que lleva unos años mejorando sus soluciones, y gracias a su poder económico, está recortando distancias, gracias a productos como Azure o Hyper-V. Aunque, Citrix, que fue fundada en 1989 y VMware en 1998 llevan especializados en esto mucho tiempo. Veremos cómo son los productos entre las dos empresas más potentes dentro de este sector de la virtualización, como son Citrix y VMware. Cada una, en su día, se especializó en un tipo de virtualización, la primera más orientada a la entrega de recursos a los usuarios y la segunda a la virtualización del datacenter. Así consiguieron copar el mercado, y hoy en día cualquiera de las dos compite, guardando las distancias según las necesidades, entre ellas sin problemas. Así que vamos a explicar un poco por encima, qué características tienen los productos más destacados tanto de VMware y Citrix, que tienen su pareja entre compañías.

7.1 Hypervisor VMware ESXi vs Citrix Hypervisor (XenServer) Los dos hypervisores son gratuitos y están basados en sistemas linux. Ambos, tanto Citrix Hypervisor como VMware ESXi disponen por supuesto de su versión de pago, ya que la versión gratuita tiene muchas limitaciones, lo que hace que no sea adecuada más que para realizar pruebas o entornos de laboratorio. Entre otros sistemas operativos, son capaces de gestionar máquinas virtuales Windows como Linux. Podríamos destacar en Citrix Hypervisor que ha sido el primer hypervisor compatible con los tres fabricantes de GPUs más importantes (ATI, NVIDIA e INTEL). Y, por ejemplo, que la versión de pago de VMware ESXi, unida a la suite vSphere, dispone como sabemos de grandes funcionalidades y sencillez de gestión. También es importante, que VMware ESXi, aunque incluso ya se puede instalar en productos ARM (como en una Raspberry Pi), no es tan compatible con el hardware como lo es Citrix XenServer, ya que ESXi dispone de una lista de compatibilidad bastante limitada (HCL).

7.2 VMware vCenter vs Citrix XenCenter Para la gestión centralizada de los hypervisores, usaremos VMware vCenter o Citrix XenCenter. El primero, se ha convertido en el centro de acción de todos los productos de la suite VMware vSphere, ya que gracias al despliegue de un simple appliance basado en linux Photon, podemos gestionar prácticamente todos los productos de VMware. Actualmente sólo vía web y por fin mediante HTML5.

#VMwarePorvExperts

730

Capítulo 13 - Citrix en vSphere Héctor Herrero

Por su parte, Citrix XenCenter, es un software, una consola que se debe instalar en un equipo Windows mediante la instalación de un cliente que se descarga como un complemento del hypervisor.

7.3 VMware Horizon Apps vs Citrix Virtual Apps Citrix Virtual Apps es la herramienta estrella de Citrix. Lo que permite es publicar en un portal las aplicaciones que el usuario luego ejecuta en un servidor remoto como si fuesen propias (imperceptible para el usuario). Puede trabajar tanto en escritorios/servidores Windows/Linux físicos, como virtualizados. Se gestiona mediante Citrix Studio, y para ello se instala un agente VDA en la máquina destino, y los clientes utilizan otro cliente llamado Citrix Workspace App. Y dispone de su propio protocolo optimizado para la conexión. VMware Horizon Apps es un concepto muy parecido a XenApp, donde a un usuario tiene un portal donde el usuario se loguea y se muestran las Apps, siendo posible su acceso desde cualquier dispositivo (igual que Citrix) sean móvil, tablet, PC, thinclient o fatclient. Normalmente se entregan apps de RDSH. Ambos fabricantes permiten acceso sin cliente, mediante HTML5, quizá Citrix con mayores características. En su defecto se podrá instalar un cliente, tanto VMware Horizon Client como Citrix Workspace App son multiplataforma (Windows, Linux, Android, IOS, MacOS,…)

7.4 VMware Horizon VDI vs Citrix Virtual Desktops Si en vez de aplicaciones individuales queremos servir escritorios, utilizamos la misma plataforma tanto en VMware como en Citrix. Así que en la práctica es el mismo concepto en ambas infraestructuras. Aunque actualmente Citrix es capaz de soportar escritorios cliente Windows y Linux, y Horizon también lo hace, en nuestra opinión la parte de Linux está menos desarrollado en Horizon. Eso es una ventaja, porque al final tenemos que adquirir licencias tanto de Remote Desktop Services (actualmente VDAs) como de Windows, y realmente, si una empresa puede trabajar con escritorios Linux en sus clientes, ahorrará costes. Por su parte, la complejidad de instalación de Horizon y su mantenimiento con respecto a la solución de Citrix, puede ser una gran ventaja para la segunda. Citrix dispone de un sistema de parcheado y versiones LTSP muy interesante. Si quieres ver en 1 minuto una comparativa de lo que necesitas para desplegar un ejemplo de 3 desktops, echa un vistazo a este interesante video: https://www.youtube.com/watch?v=Js8x3ayDbRk

7.5 VMware Workspace One vs Citrix Workspace La tendencia de estas empresas es la de unificar y permitirnos entregar todos los recursos que podamos necesitar en los negocios. En esta unificación, casí lo hacen con los nombres de sus soluciones, siendo VMware Workspace One y Citrix Workspace. La idea es disponer de una solución global donde el espacio de trabajo del usuario esté unificado y #VMwarePorvExperts

731

Capítulo 13 - Citrix en vSphere Héctor Herrero

sobre todo simplificado. De forma que un administrador pueda servir soluciones de todo tipo, siendo transparente al usuario si ese recurso es una APP local o en la nube, por ejemplo. Ya que a parte de entregar apps SaaS podremos gestionar sus dispositivos móviles o proporcionarles acceso a sus ficheros de manera cloud.

7.6 Otros productos VMware vs Citrix En toda la gama de productos de ambas empresas existen otras soluciones que podrían equipararse pero que las empresas implementan de forma ya distinta, como la parte de Networking con Citrix Netscaler o VMware NSX, la parte cloud que podría ser un concepto parecido, la monitorización donde VMware apuesta por parecerse a Grafana, el tema de Containers donde VMware ya está trabajando seriamente y enfoca su futuro, y donde Citrix no ha empezado seriamente…O sí disponen de soluciones serias en cuanto a la gestión del dispositivo móvil o MDM, Citrix dispone de XenMobile y VMware de AirWatch. Por recordar en cuanto al aprovisionamiento de las máquinas virtuales, VMware dispone de Linked Clones y Citrix de Provisioning Services. Por tanto, no creemos que exista una mejor o peor solución para cada empresa o usuario, sino que muchas veces depende del presupuesto, de la oferta comercial, así como de las cualidades del técnico que realice la implantación. Cada fabricante tiene diferentes pros/contras en sus soluciones así como diferentes funcionalidades. Si tienes interés, en 2014 tuve el placer de colaborar en una serie de charlas, una de ellas llamada ‘Despliegue de aplicaciones y escritorios con Citrix y VMware’, donde profundizamos algo más en una comparativa de productos, puedes verla en: https://vimeo.com/108571572

 

#VMwarePorvExperts

732

Capítulo 13 - Citrix en vSphere Héctor Herrero

8. Definición y requisitos de las MVs Lo primero, remarcar que obviamente, el dimensionamiento las máquinas a utilizar dependerán de cada escenario. Tendremos que diferenciar las máquinas que se usarán para la ejecución de los recursos de los usuarios (VDAs) de las máquinas que se tendremos para controlar y disponer del entorno. En entornos LAB o pequeña empresa, podemos en una misma máquina albergar todos los roles de control como son el Delivery Controller, el StoreFront, Servidor de Licencias, BBDD con un SQL Express y Director entre otros. Esta máquina debe tener al menos 12Gb de RAM. Si como es habitual, queremos separar los componentes, por ejemplo, para repartir la carga o configurar sistemas de alta disponibilidad entre ellos, recordaremos que al menos daremos 5Gb de RAM al Delivery Controller, 2Gb de RAM para StoreFront, 2Gb de RAM para Director y 2Gb de RAM al Servidor de Licencias.

Delivery Controller

7 SP1 / 8 10 / 8.1

Studio

Director VDA

StoreFront

2008 R2 SP1

X 7.15

X

Licensing

2012 R2 Std/Ent

2012 R2 Core

2016 Std/Ent

2016 Core

2019 Std/Ent

2019 Core

X

X

X

X

X

X

X 7.15

Windows

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Se necesitan 3 bases de datos: •

Site o Sitio: Donde reside la configuración de nuestro Sitio de Citrix, estado de las sesiones actuales e información de conexión.

•

Configuration Logging o Registros: Se almacenan los cambios de configuración del Sitio y cualquier actividad de los administradores.

•

Monitoring o Supervision: . Monitor Service recopila y almacena los datos históricos que necesita Director, como son las sesiones o información de las conexiones.

Podremos almacenarlas en: •

SQL Server 2008 R2 SP2 o superior. En ediciones Express, Standard, Enterprise y Datacenter.

•

SQL Server 2012 SP1, SP2, SP3 y SP4. En ediciones Express, Standard y Enterprise.

•

SQL Server 2014 SP1, SP2 y SP3. En ediciones Express, Standard y Enterprise.

•

SQL Server 2016 SP1 y SP2. En ediciones Express, Standard y Enterprise.

•

SQL Server 2017. En ediciones Express, Standard y Enterprise.

#VMwarePorvExperts

733

Capítulo 13 - Citrix en vSphere Héctor Herrero

Niveles funcionales del bosque y dominio, soportados: •

Windows Server 2008

•

Windows Server 2008 R2

•

Windows Server 2012

•

Windows Server 2012 R2

•

Windows Server 2016

En cuanto al dimensionamiento de las máquinas VDA que serán las que permitan ejecutar a los usuarios sus aplicaciones, obviamente dependerá del tipo de entrega que hagamos.

Como tabla de soporte de Citrix Virtual Apps and Desktops en infraestructuras vSphere:

VMware

vSphere / Hypervisor

Citrix Virtual Apps and Desktops & Provisioning Services 7.6 LTSR

7.14/7.16/7.17

7.15LTSR

7.18/1811/1808

5.5, 5.5 Up1, Up2, Up3

Soportado CTX140135

Soportado CTX140135

Soportado CTX140135

Soportado CTX140135

6.5, 6.5 Up1, 6.5 Up2

Soportado CTX219808

Soportado CTX219808

Soportado CTX219808

Soportado CTX219808

6.0, 6.0 Up1, 6.0 Up2, 6.0 Up3

6.7, 6.7 Up1

Soportado CTX200969

No Soportado

Soportado CTX200969

No Soportado

Soportado CTX200969

Soportado con el Cumulative Update 3

Soportado CTX200969

Soportado CTX235513

 

#VMwarePorvExperts

734

Capítulo 13 - Citrix en vSphere Héctor Herrero

9. Entregando Apps Normalmente cuando se entregan apps a los usuarios, se entregan desde Windows Server, ya que desde un servidor pueden trabajar múltiples usuarios de manera concurrente. Hoy en día ya la mayoría de las aplicaciones soportan plataformas multiusuario. La entrega de Apps permitirá que el usuario ejecute la aplicación remota en su equipo, de manera totalmente transparente. En entornos de carga media de tipo ofimática, trabajaremos bajo Windows Server con normalmente 4vCPUs y sobre los 24Gb de RAM, podrá soportar unas 40 sesiones de usuarios de manera simultánea; claro está que todo se basa en la carga y uso que hagan de las aplicaciones. Usando una media de 400Mb de RAM por usuario, sería un entorno válido. En cuanto al disco, con apenas 50Gb de disco podría servir, dependerá de las aplicaciones que tenga instaladas y lo que ocupen, ya que los usuarios no almacenan datos en el servidor. Será importante almacenar esta máquina en disco rápido. También podríamos entregar apps a los usuarios desde Windows Desktop, a tener en cuenta que un usuario por equipo de manera simultánea. Quizá más pensado para entornos Workstation, 3D, CAD, apps no compatibles con entornos multiusuario o Windows Server…

#VMwarePorvExperts

735

Capítulo 13 - Citrix en vSphere Héctor Herrero

10. Entregando Desktops Primero, tendríamos que pensar por qué queremos entregar un escritorio completo a un usuario en vez de servirle únicamente aplicaciones. Si todas las razones nos fuerzan a optar por entregar escritorios virtuales tendremos dos posibilidades: Entregarlo mediante Windows Server, será indiferente para el usuario ya que tendrá la experiencia de escritorio tradicional •

Si tiene las aplicaciones instaladas, los usuarios consumirán recursos en dicho servidor. Puede que el usuario tenga visibilidad sobre aplicaciones que no nos interese. Los recursos que debe tener el servidor son algo superiores al escenario de Entregando Apps.

•

Si sólo tiene instalado Citrix Receiver, los usuarios al loguearse pasarán sus credenciales a Citrix Receiver y éste les mostrará aplicaciones que se ejecutarán en otros servidores VDA. Los usuarios apenas consumen recursos de CPU y RAM en estos servidores.

Entrega mediante Windows Desktop •

A diferencia de Windows Server, en los Desktop permitiremos 1 conexión de 1 usuario por equipo.

•

Los Windows Desktop pueden tener las aplicaciones ya instaladas o entregarlas mediante Citrix Receiver. En ambos casos cada MV consumirá 1-2 vCPUs, 2-4Gb de RAM y 40Gb en Disco.

•

Podemos entregar un pool de Desktops a los usuarios y optar por dar un Desktop aleatorio cada vez que se conecten o asignarles manualmente el suyo.

Una buena herramienta para el dimensionamiento puede ser el XenDesktop 7.x Sizing Calculator que tenemos aquí: https://blog.citrix24.com/xendesktop-7-sizing-calculator/

#VMwarePorvExperts

736

Capítulo 13 - Citrix en vSphere Héctor Herrero

11. Aprovisionando máquinas VDA Las máquinas donde los usuarios ejecutarán sus aplicaciones o escritorios pueden ser equipos físicos como máquinas virtuales, tanto con Windows o con Linux. En un entorno virtual, podremos manualmente crear todas las máquinas VDA que necesitemos, como ya sabemos, cada MV consumirá sus recursos de CPU, Memoria RAM y Disco. Si queremos evitar crear las máquinas manualmente, podremos a partir de una imagen maestra desplegar tantas máquinas VDA como nos interese, al igual que cuando tenemos picos de carga, aprovisionar más máquinas para atender la demanda. Normalmente dependerá del tamaño del entorno, en entornos pequeños los VDA suelen ser maquinas creadas manualmente, pero cuando nos enfrentamos a volúmenes altos de usuarios, se gestiona diferente. Tenemos dos opciones diferentes a la hora de aprovisionar máquinas, tenemos la tecnología de Provisioning Services (PVS) o también la de Machine Creation Services (MCS). PVS permite el aprovisionamiento de máquinas, tanto a MVs como Físicas, se integra totalmente con nuestro sitio Citrix. Desde una imagen base crearemos tantas máquinas como necesitemos, sean escritorios como servidores de aplicaciones. Los SO se envían por streaming en red y se ejecutan en RAM y caché, por tanto, no hace falta que tengan discos duros, simplemente se descargan en demanda de lo que van necesitando. Ideal para entornos con cargas inesperadas de usuarios o alta demanda. PVS requiere de al menos un servidor dedicado con este rol de Citrix, y como es recomendable varios para ofrecer alta disponibilidad y balanceo de carga, así como normalmente NIC teaming en las interfaces de red, para acelerar el proceso de entrega del SO o apps que requieran los VDA. Trabaja bajo cualquier almacenamiento sea NAS o SAN, los servidores PVS almacenarán en discos locales o shares los vDisk de las VDA maestras, para luego aprovisionarlos mediante dichas NICs dedicadas. En entornos físicos las máquinas arrancarán por PXE y en entornos virtuales podremos usar un pequeño disco con BDM o Boot Device Manager, ambos indicarán el servidor PVS y la imagen que se deben descargar. En cambio, MCS sólo aprovisiona MVs en nuestra plataforma virtual (no aprovisiona en físico). Al igual, nos basamos en una imagen maestra de una MV y de ella aprovisionaremos tantos servidores y escritorios virtuales cómo necesitemos. Los clones generados tendrán un disco virtual de identidad (16Mb) y un disco diferencial donde se almacenan los datos del usuario, pero se reclama con cada reboot; opcionalmente discos de caché o discos personales (PvD) donde permitiremos que los usuarios almacenen y mantengan sus cambios. Leerán toda la información de un disco creado a partir del snapshot de la imagen maestra, que se almacenará en cada datastore compartido que contenga máquinas MCS. Si disponemos de un entorno nube hibrida, con MCS podremos generar sencillamente e iniciar VDAs en nuestra nube para no afectar a los recursos del datacenter local, esto con PVS no lo podríamos hacer. Es preferible usar almacenamientos tipo NFS ya que al ser tipo NAS tarda menos en aprovisionar las máquinas que usando VMFS en una SAN, ya que trabaja a nivel de bloque y no de fichero. Normalmente MCS se emplea en entornos demo o pilotos al necesitarse menos infraestructura o en entornos puramente VDI ya que su implementación no requiere ninguna complejidad, se intregra con vSphere directamente. Cuando disponemos entornos VDI con escritorios mixed o a gran escala, se suele optar por PVS ya que dispone muchas más posibilidades, entre otros, habilitando el cacheo reducimos IOPS. En entornos donde desplegaremos miles de VDAs, aumentando los puertos de streaming del 6910 a máximo 6968 (por defecto 6910 – 6930) conseguiremos mayor rendimiento, cada puerto soporta un numero de treads, y estos deberían de ser el número de cores que disponga el PVS. Con esto conseguiremos levantar muchas más máquinas por PVS. Si con PVS desplegamos diferentes imágenes de VDA, es recomendable (siempre que se pueda) agruparlas y que cada PVS

#VMwarePorvExperts

737

Capítulo 13 - Citrix en vSphere Héctor Herrero

despliegue diferente colecciones de imágenes, con idea de optimizar el cacheo en RAM del PVS necesitando menos memoria. Tanto MCS con vCenter como los servidores PVS necesitan acceso al Directorio Activo, donde darán de alta las cuentas de los equipos cuando se generen o las borrarán cuando eliminemos los Catálogos de máquinas. Cuando definamos una imagen maestra de MCS o PVS deberemos tener en cuenta realizar una buena optimización de su SO & Apps. Debemos recordar el establecer un procedimiento de actualización e instalación de software en nuestros VDA, tendremos que documentar correctamente los cambios realizados. En cuanto al control de cambios en los VDA y su versionado, esto es, cuando queramos realizar una actualización en la imagen maestra, ambas opciones disponen de su gestión. En ambas opciones el funcionamiento es similar, donde tras actualizar con los cambios requeridos el VDA maestro (updates, nuevas apps…) y apagarla, podremos desplegar este cambio de manera inmediata a todas las VDAs hijas o esperar a que las máquinas se apaguen y tras un simple reinicio cargarían esta nueva versión de VDA. PVS al ser más completo que MCS, dispone de un control de versiones donde tenemos más características, entre ellas, el poder testear la imagen antes de pasarla a producción o hacer roll backs con un click.

En esta imagen podemos ver un resumen de las máquinas que podremos obtener con una u otra tecnología:

Con MCS podremos hacer Pools de máquinas y entregarlas de manera aleatoria o asignarlas estáticamente. Hacer un pool de máquinas con disco personal PvD donde guardarán los cambios. O por último hacer máquinas dedicadas donde los usuarios estarán asignados a máquinas bien manualmente o por primer uso. Con PVS haremos streaming a entornos virtuales o físicos, y si queremos que los usuarios hagan cambios persistentes en las máquinas usaremos PvD, pero sólo en entornos virtuales. Por último, subrayar que cada escenario de cada empresa es distinto, y puede que nos encaje más una solución que otra, o ambas dos de manera simultánea. Si todavía tienes dudas de qué puedes necesitar:

#VMwarePorvExperts

738

Capítulo 13 - Citrix en vSphere Héctor Herrero

Por cierto, si quieres ver un video de PVS en funcionamiento, que mejor que el video clásico de cuándo PVS aún se llamaba Ardence: https://www.youtube.com/watch?v=0v7oJfyn3Hc

A la hora de analizar bien el escenario que más nos interesa, personalmente siempre que se puedo, opto por la virtualización de aplicaciones antes que una virtualización de escritorios, básicamente por los recursos que requiere un escenario frente al otro, además debemos sumar los costes de operación. Pero si forzosamente debemos entregar escritorios, tenemos como hemos visto dos alternativas, en un escenario donde debamos entregar 300 escritorios a 300 usuarios, podremos pensar en entregar 300 Windows Desktops, o 12 Windows Server que hagan la misma función. Podríamos ligeramente apoyarnos en esta comparativa también a la hora de virtualizar apps:

Escritorios de Windows Server

Recursos de cada máquina: • 4 vCPU • 16GB RAM Total recursos consumidos: • 48 vCPU • 192GB RAM

#VMwarePorvExperts

Escritorios de Windows Desktop

Recursos de cada máquina: • 1 vCPU • 1,5GB RAM Total recursos consumidos: • 300vCPU • 450Gb RAM

739

Capítulo 13 - Citrix en vSphere Héctor Herrero

Algo que nos puede ayudar a decidir si podemos optar por una solución de virtualización de aplicaciones o escritorios pueden ser el siguiente diagrama:

#VMwarePorvExperts

740

Capítulo 13 - Citrix en vSphere Héctor Herrero

12. Proceso de logon del Usuario En esta sección veremos el proceso completo de todas las fases que comprenden el inicio de una sesión de un usuario, desde pincha en la primera aplicación o escritorio hasta que se la muestra y pueda trabajar con ella. Será interesante comprenderlo para evitar problemas de logons. Antes de comenzar con más detalle, deberemos tener en cuenta que en un sitio Citrix con múltiples máquinas de tipo VDA, el usuario deberá tener el mismo entorno a la hora de trabajar. Esto es, deberá tener las mismas configuraciones, se consigue mediante el uso normalmente de perfiles móviles, que detallaremos más adelante su optimización. De esta manera se consigue que los usuarios, se conecten a la máquina VDA que se conecten dispondrán de las mismas personalizaciones, firma de correo, historial del navegador… La primera vez que se abre una aplicación o un escritorio comienza el proceso de inicio de sesión, este tiempo es importante minimizarlo para que la sensación del usuario sea buena, una referencia de 30 segundos será válida. Una vez la aplicación o el escritorio haya iniciado, el resto de aplicaciones iniciarán de manera instantánea ya que la sesión está establecida. Pero antes de que el usuario conecte e inicie sesión en una máquina VDA tenemos antes una serie de pasos importantes que debemos conocer:

1. El usuario contacta con el StoreFront y se autentica. El StoreFront lo valida contra el Directorio Activo. 2. StoreFront contacta con Delivery Controller para conocer los recursos a los que el usuario tiene acceso. 3. Delivery Controller le envía una lista con los recursos de apps y escritorios. 4. StoreFront obtiene los recursos. 5. El usuario seleccionará una aplicación o un escritorio al que conectarse. 6. StoreFront contacta con el Delivery Controller para solicitar un VDA disponible que tenga los recursos. 7. Delivery Controller responde a StoreFront con el hostname e IP de la VDA que puede satisfacer la necesidad. Si el VDA está apagado, Delivery Controller podrá dar orden de encenderla.

#VMwarePorvExperts

741

Capítulo 13 - Citrix en vSphere Héctor Herrero

8. StoreFront genera un archivo ICA que contiene la información de la conexión recopilada por Delivery Controller que se envía al usuario final. 9. En el lado del usuario se descarga el archivo de conexión y se abre con Citrix Receiver. 10. Citrix Receiver comprueba e inicia la conexión contra la máquina VDA. 11. VDA comunica con el servicio de licencias Remote Desktop Service para verificar el licenciamiento. 12. Se crea la sesión en el Delivery Controller y comenzaría el Inicio de sesión del usuario en la máquina VDA hasta que finalmente le muestra la aplicación o escritorio que solicitó y con el que podrá trabajar.

Siempre que tengamos bien dimensionado nuestro entorno, los servidores StoreFront y Delivery Controller responderán sin penalizar el proceso de brokering. La parte más delicada viene en el Inicio de sesión de los usuarios, que es donde se va el mayor tiempo del proceso de logon. Estas serían sus 9 fases:

1. HDX Connection: El tiempo dedicado a establecer la conexión HDX del cliente Citrix Receiver a la máquina VDA. Son tareas que realiza el VDA, revisa los requisitos de la aplicación (audio, video, códecs…) y haciendo una compresión de video y gráficos utilizando el códec H.264. Esta fase puede verse afectada a la hora de redirigir dispositivos del usuario al VDA, como son los dispositivos USB, webcam… 2. Session Init: Cuando el usuario inicia sesión en el VDA, se inicia un proceso de subsistema SMSS. exe y arranca un proceso de Winlogon.exe. En Seguridad, del Visor de sucesos: ID 4688 (smss. exe) para el INICIO e ID 4689 (smss.exe) para FIN. 3. Network Providers: En cada inicio de sesión se Winlogon notifica al proveedor de red para que puedan recopilar las credenciales y autenticar al usuario en la red. En nuestros VDA será Citrix PnSson. En Seguridad, del Visor de sucesos: ID 4688 (mpnotify.exe) para el INICIO e ID 4689 (mpnotify.exe) para FIN. 4. Citrix Profile Management: Durante el logon, Citrix UPM copia todas las entradas del registro, ficheros y configuraciones del almacén de perfiles al VDA local. Si existiese un perfil local en el VDA a modo caché, se sincronizaría con los últimos cambios del almacén de perfiles. Normalmente este suele ser el cuello de botella, ya que los usuarios tienen perfiles de gran tamaño si no hemos sido finos a la hora de configurar UPM. En Aplicación, del Visor de sucesos: ID 10 y en User Profile Service: ID 1. 5. User Profile: Durante el inicio de sesión, el sistema carga el perfil del usuario y luego se configura el entorno del usuario de acuerdo con la información del perfil. En User Profile Service, del Visor de sucesos: ID 1 para el INICIO e ID 2 para FIN. 6. Group Policy: Es el momento en el que se cargan las políticas de grupo y directivas del usuario. Es importante verificar que ninguna GPO ralentiza la carga con configuraciones inválidas o el disponer de cientos de GPO. Hasta que no se cargan las GPO no se puede ver la app o escritorio. En GroupPolicy, del Visor de sucesos: ID 4001 para el INICIO e ID 8001 para FIN.

#VMwarePorvExperts

742

Capítulo 13 - Citrix en vSphere Héctor Herrero

7. GP Scripts: Es cuando cargan los scripts de inicio de sesión que tenemos configurados en las GPO. En el caso de los scripts de inicio de sesión síncronos, el Explorador de Windows no se inicia hasta que los scripts de inicio de sesión terminan de ejecutarse. En GroupPolicy, del Visor de sucesos: ID 4018 para el INICIO e ID 5018 para FIN. 8. Pre-Shell: Winlogon ejecuta Userinit.exe, que ejecuta los logon scripts, restablece las conexiones de red y luego inicia Explorer.exe, la interfaz de usuario de Windows. En las sesiones de RDSH, Userinit.exe también ejecuta cmstart.exe, que a su vez llama a wfshell.exe que finalmente abrirá la aplicación publicada y requerida por el usuario. En Security, del Visor de sucesos: ID 4688 (userinit. exe) para el INICIO e ID 4688 (icast.exe) para FIN. 9. Shell: Es el intervalo entre el inicio de la aplicación o escritorio y el tiempo en el que realmente esta disponible para el usuario

Para más información os dejo la completa guía con todo detalle del gran Andrew Morgan: http:// goliathtechnologies.com/wp-content/uploads/2016/05/LOD-Guide.pdf

 

#VMwarePorvExperts

743

Capítulo 13 - Citrix en vSphere Héctor Herrero

13. Perfiles Móviles Queda claro pues, que una buena gestión del perfil del usuario les proveerá de un inicio rápido al entorno. En entornos Citrix usaremos UPM, Citrix User Profile Management, que es un conjunto de directivas que nos van a permitir configurar los perfiles en base a nuestra necesidad de una manera muy sencilla. Habrá que definir primero de todo un almacén, una carpeta compartida que será donde se almacenen los perfiles de los usuarios. Por tanto, al iniciar sesión el usuario se descargará de aquí el perfil a C:\Users del VDA; mientras el usuario trabaja con sus aplicaciones el perfil se sincronizará con el almacén; y finalmente al cerrar la última aplicación se cerrará sesión y el perfil guardará los cambios pendientes al share. El almacén de perfiles lo crearemos en un servidor de ficheros o sistema DFS, una carpeta compartida con los siguientes permisos: Permisos NTFS

Permisos SHARE

Administradores: Control Total

Todos: Cambiar

SYSTEM: Control Total

Administradores: Control Total

Usuarios autenticados: Mostrar contenido de la carpeta, Leer datos & Crear directorios y añadir datos, en este directorio sólo. Creador/Propietario: Control total, subdirectorios y ficheros sólo.

Para gestionar de manera centralizada los perfiles, lo más sencillo puede ser crear y configurar una GPO que aplicaremos a la Unidad Organizativa donde tenemos las máquinas VDA. En dicha directiva deberemos importar la plantilla administrativa de Profile Management que encontraremos en la ISO. Será ahí donde indicaremos todas nuestras necesidades.

#VMwarePorvExperts

744

Capítulo 13 - Citrix en vSphere Héctor Herrero

Deberemos definir las directivas que más nos interesen y se adapten a nuestro entorno, con idea de mantener un perfil ligero. Primero habilitaremos Profile Management y a continuación deberemos establecer la Ruta al almacén de usuarios, con formato UNC y pudiendo usar variables podremos indicar algo como: \\NAS\PerfilesCitrix\%username% A dicha configuración, podrás añadir tantas directivas como te encajen, algunos ejemplos interesantes: Grupos Procesados / Grupos Excluidos: Pondrás indicar a qué Grupos de Usuarios aplicar o excluir de UPM. Reescritura activa: Al habilitarlo permitimos que todos los ficheros del perfil del usuario en el VDA se sincronicen con el almacén para hacer un cierre más rápido. Si queremos sincronizar también los cambios el Registro habilitaremos ‘Registro de reescritura activa’. Gestión de perfiles: Podremos habilitar ‘Eliminar perfiles guardados en caché local al cerrar la sesión’ si queremos que al cerrar la sesión el usuario se elimine el perfil, por higiene. Además podremos establecer una demora para hacerlo, ya que a veces puede que algún proceso quede bloqueado durante X segundos. Así como gestionar si existe un perfil ya en el VDA que hacer, si renombrar el local, eliminarlo o utilizarlo en vez del perfil del almacén. Sistema de archivos: Podremos excluir qué archivos o extensiones de ellos no queremos que viajen y se guarden en el almacén del perfil, o qué directorios… De total obligación su configuración, deberemos aprender y conocer qué excluir en cada organización; ya que cada aplicación genera sus residuos, temporales, cachés… Herramientas tipo WinDirStat nos pueden ayudar a conocer por donde se nos van los perfiles, podremos ver tanto los ficheros grandes como directorios con multitud de ficheros que quizá sobran. Además, en la misma GPO, suele ser recomendable crear redirecciones de carpetas con el fin de evitar que ciertas carpetas que almacenan información no la guarden en el perfil, si no en un share de la red. Mínimamente redireccionaremos carpetas como Descargas o quizás Mis Documentos… Por último, una muy buena idea suele ser minimizar el tamaño del perfil Default que trae nuestro VDA en C:\Users, para que la generación de nuevos perfiles tenga el tamaño menor posible. Directorios que normalmente puedes excluir de UPM: AppData\Local\Packages AppData\Local\TileDataLayer AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache\ ChromeDWriteFontaCache

AppData\Local\Microsoft\Windows\RoamingTiles

AppData\Local\Microsoft\Windows\Temporary Internet Files AppData\Local\Microsoft\Windows\WebCache

AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache

AppData\Local\Microsoft\Windows\WER

AppData\Local\Citrix\DriveMapper3

AppData\Local\Mozilla\Firefox\Profiles\virt4901. default\Cache

AppData\Local\assembly

AppData\Local\Citrix\SelfService\img AppData\Local\Comms AppData\Local\CrashDumps

AppData\Local\Google\Chrome

AppData\Local\Google\Chrome\User Data\Default\ Cache

#VMwarePorvExperts

AppData\Local\Microsoft\Windows\WinX

AppData\Local\Mozilla\Firefox\Profiles\virt4901. default\cache2 AppData\Local\Mozilla\Firefox\Profiles\virt4901. default\safebrowsing-to_delete AppData\Local\SAP\SAP GUI

AppData\Local\SAP\SAP GUI\Cache AppData\Local\SAP\SAP GUI\Traces

745

Capítulo 13 - Citrix en vSphere Héctor Herrero

AppData\Local\Google\Chrome\User Data\Default\Cached Theme Images AppData\Local\Google\Chrome\User Data\Default\JumpListIcons AppData\Local\Google\Chrome\User Data\Default\JumpListIconsOld

AppData\Local\Google\Chrome\User Data\Default\ Media Cache AppData\Local\Google\Chrome\User Data\Default\ Plugin Data

AppData\Local\Sun AppData\Local\Temp AppData\Local\Temporary Internet Files AppData\Local\WebEx\wbxcache AppData\Local\Windows Live

AppData\Local\Google\Chrome\User Data\ PepperFlash

AppData\LocalLow

AppData\Local\Microsoft\AppV

AppData\Roaming\Citrix\PNAgent\AppCache

AppData\Local\Google\Update\download

AppData\Mozilla

AppData\Local\Microsoft\GameDVR

AppData\Roaming\Citrix\PNAgent\Icon Cache

AppData\Local\Microsoft\Group Policy

AppData\Local\Microsoft\Internet Explorer\Recovery

AppData\Local\Microsoft\Internet Explorer\Recovery\ High AppData\Local\Microsoft\Media Player AppData\Local\Microsoft\Messenger AppData\Local\Microsoft\Office\14.0\OfficeFileCache AppData\Local\Microsoft\Office\14.0\OfficeFileCache. old AppData\Local\Microsoft\OneDrive AppData\Local\Microsoft\OneNote AppData\Local\Microsoft\Outlook AppData\Local\Microsoft\PlayReady AppData\Local\Microsoft\Terminal Server Client AppData\Local\Microsoft\WER AppData\Local\Microsoft\Windows Live AppData\Local\Microsoft\Windows Live Contacts AppData\Local\Microsoft\Windows Live Mail AppData\Local\Microsoft\Windows Mail AppData\Local\Microsoft\Windows Store AppData\Local\Microsoft\Windows\1033

#VMwarePorvExperts

AppData\Roaming\Citrix\PNAgent\ResourceCache AppData\Roaming\Citrix\SelfService\Icons AppData\Roaming\ICAClient\Cache AppData\Roaming\Macromedia\Flash Player\#SharedObjects

AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys AppData\Roaming\Microsoft\Document Building Blocks AppData\Roaming\Microsoft\Internet Explorer\ UserData

AppData\Roaming\Microsoft\Templates\LiveContent\ Managed\ AppData\Roaming\Microsoft\Windows\Cookies

AppData\Roaming\Microsoft\Windows\Network Shortcuts AppData\Roaming\Microsoft\Windows\Printer Shortcuts

AppData\Roaming\Mozilla\Firefox\Crash Reports

AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\Crashes AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\healthreport AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\indexedDB AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\minidumps AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\saved-telemetry-pings AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\sessionstore-backups AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\storage

746

Capítulo 13 - Citrix en vSphere Héctor Herrero

AppData\Local\Microsoft\Windows\AppCache AppData\Local\Microsoft\Windows\Application Shortcuts AppData\Local\Microsoft\Windows\Burn

AppData\Local\Microsoft\Windows\Caches

AppData\Local\Microsoft\Windows\Cookies

AppData\Local\Microsoft\Windows\Explorer

AppData\Local\Microsoft\Windows\GameExplorer AppData\Local\Microsoft\Windows\History

AppData\Local\Microsoft\Windows\INetCache AppData\Local\Microsoft\Windows\INetCookies AppData\Local\Microsoft\Windows\Notifications AppData\Local\Microsoft\Windows\Ringtones

AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\weave AppData\Roaming\Mozilla\Firefox\Profiles\virt4901. default\webapps AppData\Roaming\Sun\Java\Deployment\cache AppData\Roaming\Sun\Java\Deployment\log

AppData\Roaming\Sun\Java\Deployment\tmp AppData\Temp Sharefile

Software\Microsoft\Windows NT\CurrentVersion\Fonts Software\Microsoft\Windows NT\CurrentVersion\ FontSubstitutes

Software\Microsoft\Windows\CurrentVersion\UHF\ SHC Videos

AppData\Local\Microsoft\Internet Explorer\DOMStore

La reciente adquisición de Norskale por parte de Citrix, nos trajo Workspace Environment Manager. Si somos Enterprise o Platinum disfrutaremos de la mejor solución para la gestión del espacio de trabajo de los usuarios. Integrándose y mejorando nuestra solución de Perfil de usuario, optimizando el rendimiento para acelerar la entrega de las aplicaciones y tener un mejor tiempo de respuesta.  

#VMwarePorvExperts

747

Capítulo 13 - Citrix en vSphere Héctor Herrero

Finalmente, os quería dejar un diagrama del funcionamiento de Citrix UPM:

#VMwarePorvExperts

748

Capítulo 13 - Citrix en vSphere Héctor Herrero

14. Administrando con Citrix Studio Una vez tenemos claro los requisitos para desplegar un entorno Citrix, y vista parte de la configuración inicial, vamos ahora con las tareas que podremos realizar desde la consola Citrix Studio.

Esta consola será la que utilicemos para administrar el entorno, desde ella daremos de alta las máquinas VDA y entregaremos sus aplicaciones o escritorios a los usuarios. A modo informativo, si te gusta el PowerShell, la consola registra toda la actividad y muestra sus comandos, por si necesitas automatizar tareas. Deberemos añadir las máquinas VDA a Catálogos de máquinas, que no son más que agrupaciones de máquinas físicas o virtuales que se administran como una única entidad. Todas las máquinas de cada Catálogo tienen el mismo S.O., así como normalmente mismas apps instaladas. A la hora de crear el Catálogo deberemos indicar si son S.O. de servidor o escritorio e indicar si las máquinas VDA ya existen o queremos crearlas a partir de una VDA maestra. Como anteriormente indicamos, en entornos virtuales o cloud hibrida podremos apoyarnos de MCS para crear ‘n’ MVs idénticas a un VDA servidor o desktop. En entornos físicos o virtuales podremos montar una infraestructura de Provisioning Services y aprovisionar tantas máquinas VDA necesiten nuestros usuarios en cuestión de segundos. Ambas opciones disponen de una sencilla gestión de versionado, con realizar los cambios en la máquina maestra podremos desplegarlo al resto de VDAs tras un simple reinicio. Tras crear los Catálogos, debemos definir qué recursos de estas máquinas VDA entregaremos a qué usuarios. Crearemos Grupos de Entrega donde indicaremos máquinas de uno o varios Catálogos y especificaremos qué usuarios o grupos de ellos pueden usar las máquinas, indicando si pueden conectarse a su escritorio y/o aplicaciones. En los Grupos de entrega definiremos también la programación horaria, indicando el número de máquinas que queremos dejar iniciadas, dependiendo de si es horario normal u hora punta podremos ya dejar máquinas esperando a conexiones de usuario, para agilizar los inicios; así como apagarlas o suspenderlas tras unos minutos si no se utilizan.

#VMwarePorvExperts

749

Capítulo 13 - Citrix en vSphere Héctor Herrero

Si vamos a publicar aplicaciones a nuestros usuarios, tendremos un menú donde podremos organizar las aplicaciones tanto para nosotros como para los usuarios. Para publicar una app, será tan sencillo cómo indicar de qué Grupo de Entrega y examinar en busca del ejecutable que queramos que se abra (y opcionalmente sus argumentos). Será importante establecerle un nombre a la app, un icono, una Categoría para agrupar las apps, podremos limitar el número de veces que queramos que se abra la app por si es licenciada, o limitar a que sólo la abra una sola vez el usuario… Así como quién puede ver esta aplicación y filtrar por usuario/grupo. Siguiendo con otras secciones que podremos configurar desde Studio, si necesitamos conectarnos a nuestra plataforma virtual o nube para aprovisionar MVs con MCS, deberemos crear una conexión a los recursos. Podremos conectarnos a nuestra plataforma de VMware vSphere a través de nuestro vCenter Server; pero también podremos conectarnos a infraestructuras virtuales de Citrix Hypervisor (anteriormente XenServer), o Hyper-V con System Center Virtual Machine Manager. Podremos conectarnos a los recursos de las nubes: Citrix CloudPlatform, Microsoft Azure o Amazon EC2. En la sección de Licencias deberemos conectar contra un servidor de licencias que hayamos instalado e indicar qué licencias de las que ofrece son para nuestro Sitio, podremos agregar licencias así como indicar en el Sitio la Edición que queremos utilizar. En la sección de Configuración, podremos definir roles de administradores de Citrix, con acceso granular y permisos específicos para nuestros técnicos de IT. También podremos indicar la URL del servidor StoreFront y así en todos los VDA que dispongan de Citrix Receiver instalado se les configure automáticamente, personalmente soy más partidario de hacerlo mediante GPO. Podremos también conectarnos a un entorno de Microsoft Application Virtualization para utilizar App-V y hacer streaming de apps. En caso que dispongamos una implementación de Citrix con servidores remotos en diferentes delegaciones, deberemos configurar las Zonas e indicar qué recursos pertenecen a cada sitio. Ah, y todo lo que hagamos en la consola Citrix Studio quedará registrado, ¡podremos saber quién ha hecho qué, y cuando! Y, por último, no por ello lo menos importante, sino al contrario, son las Directivas. Aquí será donde configuremos la experiencia global del usuario. Mediante pequeñas configuraciones iremos configurando qué opciones pueden realizar los usuarios o qué configuraciones tendrán aplicadas. Podremos crear directivas totalmente personalizadas o apoyarnos en unas plantillas base que nos ofrece Citrix. Estas directivas son casi infinitas, las utilizaremos entre otras cosas, para optimizar conexiones WAN, asignar experiencia de usuario muy alta, para seguridad y control. Podremos impedir acceso a recursos locales para evitar que pueda sacar información de la organización, así como asignarles impresoras específicas… QoS en los canales del protocolo ICA HDX, por ejemplo, limitar que a la hora de imprimir a través de conexiones de baja latencia no supere ciertos Kbps o % de la conexión. Así hasta un largo etcétera, por tanto, digamos es de recomendada lectura todas y cada una de las directivas, vienen correctamente explicadas (y en español). Cualquier directiva se puede aplicar en el ámbito que nos interese, podremos aplicarlas a usuarios/grupos, a VDAs que pertenezcan a un Grupo de Entrega, podremos aplicarlas a rangos de direcciones IP, a OUs, tags… y con esto dejar configurado nuestro entorno en base a nuestra necesidad.

#VMwarePorvExperts

750

Capítulo 13 - Citrix en vSphere Héctor Herrero

15. Impresión Para el variopinto mundo de impresoras que tiene cada organización, Citrix se adapta dando soluciones siempre válidas. Si la organización dispone de impresoras locales en los puestos o impresoras de red, sean del fabricante que sean podremos asignarlas a nuestros usuarios. Lo realizaremos mediante las Directivas. Con las impresoras de red, normalmente dispondremos de un servidor de impresión, este dispone de los drivers necesarios, hará de cola de impresión y compartirá las impresoras. Tendremos dos opciones, o bien instalar estos drivers a las máquinas VDA o utilizar el driver universal de Citrix. Personalmente siempre que se pueda opto por la primera opción, ya que los drivers del fabricante tienen más opciones e información que a veces el usuario necesita. Si utilizamos el driver universal los usuarios podrán imprimir con los ajustes básicos de impresión sin problema alguno en cualquier impresora. Si queremos usa impresoras locales que dispongan los puestos de los usuarios, esta gestión de drivers en los VDA ya suele ser más complicada. Ya que, si el driver no existe en el VDA, podremos decidir si queremos que instalen el driver de la impresora al conectarse (si es compatible), o si utilizar el driver universal de Citrix. Por último, otra opción que os da Citrix, es la posibilidad de montar (al menos) un servidor donde desplegaremos Citrix Universal Print Server, normalmente será el mismo servidor de impresión. Esto nos evitará el tener que instalar drivers de impresoras en las máquinas VDA, ya que al instalar el agente VDA se instala el driver universal de Citrix, y éste se podrá habilitar sencillamente en una Directiva. Donde tan sencillamente habilitaremos Universal Print Server e indicaremos que a la hora de crear la impresora si no existiese el driver nativo, use el universal. Universal Print Server corre en Windows Server 2012 R2 y 2016. Escojamos el escenario que nos interese, configuraremos las Directivas de Impresión en Studio, habilitaremos la creación automática de las impresoras del cliente o asignaremos impresoras de red, decidiremos si permitiremos que instale su driver el usuario, utilice el nativo o el universal. Luego estas directivas, como sabremos las podremos aplicar a usuarios específicos, a grupos de usuarios; o dependiendo de la conexión, si es desde fuera de la organización a través de un NetScaler o por rangos IP a delegaciones… Si necesitamos profundizar, tenemos un documento oficial bastante interesante: https://docs.citrix.com/es-es/citrix-virtual-apps-desktops/printing.html

#VMwarePorvExperts

751

Capítulo 13 - Citrix en vSphere Héctor Herrero

16. Storefront En Storefront crearemos al menos una Tienda o Store que de servicio a nuestra organización, dependiendo de la complejidad de la organización, o si somos un holding de empresas y queremos separar la forma de presentar los recursos de las apps o escritorios a nuestros usuarios.

Deberemos crear una Tienda especificando una URL cómoda para nuestros usuarios, habilitaremos SSL con un certificado válido en IIS y podremos comenzar a definirlo. Para permitir un acceso remoto y seguro a la organización desde Internet, daremos de alta nuestro Citrix NetScaler Gateway y configuraremos las balizas para que StoreFront sepa el usuario si se encuentra dentro o fuera de la organización. Daremos visibilidad a la Tienda sobre nuestras infraestructuras de Citrix, agregaremos los Delivery Controller de nuestros Sitios Citrix sean versión 7.x o anteriores a la 6.5 con XenApp. Si disponemos de Citrix XenMobile también podremos unificarlo y publicar nuestras apps y desktops en él. Podremos habilitar la experiencia de usuario unificada y mostrar un portal más intuitivo para los usuarios, huyendo de diseños anteriores, sobre todo para el uso con dispositivos móviles. Definiremos qué tipo de autenticación ofrecemos con StoreFront, por defecto validarán con su usuario y contraseña del Directorio Activo, pero podremos añadir otros dominios así cómo si les permitimos cambiar las contraseñas, o disponerles de un autoservicio de sus cuentas; donde podrán resetearse la cuenta o contraseña si responden correctamente a unas preguntas. Algo interesante también puede ser habilitar el PassThrough de credenciales, con esto conseguiremos que las credenciales donde se logueó el usuario pasen al Citrix Receiver directamente, o si trabaja con navegador web. O si los #VMwarePorvExperts

752

Capítulo 13 - Citrix en vSphere Héctor Herrero

usuarios disponen de tarjetas inteligentes para loguearse en sus equipos, igualmente pueden ser usadas para validarse en Citrix. Dentro de cada Tienda dispondremos normalmente de un sitio web de StoreFront, en caso de querer personalizar distinto cada sitio web, podremos crear tantos como nos interesen. Ya que intentaremos customizar y hacer corporativo el portal para que el usuario se sienta identificado con el sito, definiremos los colores corporativos y subiremos los logos. Decidiremos aquí si requeriremos que el usuario disponga de Citrix Receiver instalado en local para el acceso a las aplicaciones o escritorios o si le permitiremos acceso también mediante HTML5 y su navegador. Por supuesto podemos poner a disposición del usuario unos enlaces para descargar Receiver si lo necesitase. Definiremos tiempos, entre ellos, cuándo cerrar la sesión del usuario en StoreFront, ya que si pasados X minutos de inactividad por seguridad deberemos cerrar el acceso a la organización. Podemos definir qué pasa cuando se cierra esta sesión, o el usuario la cierra, si desconectar la conexión al VDA para continuar en otro momento, o cerrar la sesión del usuario definitivamente en el VDA. Y finalmente podremos indicar que vista dejar de forma predeterminada, que vean apps primero, o sus escritorios, o que les arranque automáticamente el desktop al loguearse en StoreFront. Si tenemos entornos con clientes antiguos de Citrix, podremos permitir y publicar una URL del servicio para que puedan conectar, basados en PNA. Da un paseo por la consola y descubre más opciones avanzadas. Como inicialmente indicamos, si StoreFront se convierte en un servidor crítico en la infraestructura podemos pensar en desplegar nuevos servidores, tanto para ofrecer esta alta disponibilidad como balancear la carga de los usuarios. Crearemos Grupos de servidores, donde el servidor principal es el que replicará su configuración al resto de servidores miembro, por tanto, en él configuramos StoreFront. El balanceo sobre a qué servidor conectarnos podremos usar algo tan simple como un DNS Round Robin, o configurar un NLB en Windows o mejor solución aún, optar por NetScaler y configurar Load Balancing, que analizará la salud de cada StoreFront.

Un genial recurso a la hora de customizar el portal de StoreFront https://www.citrixguru.com/2016/03/08/ lab-ultimate-storefront-customization-guide/. En ese link podremos aprender a customizar totalmente nuestro portal, sobrepasando las posibilidades que tenemos con Studio.

 

#VMwarePorvExperts

753

Capítulo 13 - Citrix en vSphere Héctor Herrero

17. Optimización del OS VDA La parte más importante sin lugar a dudas será la parte de optimizar los VDA, ya que serán los puestos donde nuestros usuarios trabajarán. Deberán ser equipos prioritarios y con recursos, ayudará el customizar el equipo y aligerar de carga no deseada. Más énfasis aún si serán aprovisionados mediante MCS o Provisioning Services, cuanto más pequeña la imagen mejor, ya que se eleva exponencialmente la necesidad de recursos cuántos más VDA dispongamos y más recursos estamos desaprovechando. Si los VDA son de tipo MV, deberemos tener en cuenta eliminarles el hardware sobrante como es la unidad de CD, la disquetera, puertos serie… En los VDA con Windows, deberemos eliminar los dispositivos ocultos en el administrador de dispositivos para que no se carguen. Siempre recordaremos tener últimas versiones actualizadas para evitar posibles bugs, tanto del agente VDA como las VMware Tools si se tuviesen. Podremos utilizar la magnífica herramienta Citrix Optimizer para optimizar y mejorar el rendimiento del equipo según las recomendaciones de Citrix. Aquí puedes ver cómo se usa: http://www.bujarra.com/ usando-citrix-optimizer Debemos deshabilitar todos los servicios innecesarios, podremos hacerlo en la imagen base directamente o mucho mejor, diseñar una GPO donde vamos a ir aplicando estas mejoras para luego aplicarlas a las OU de VDAs.

Servicios que podemos deshabilitar en Windows 201x: Application Layer Gateway Service

HomeGroup Listener

UPnP Device Host

HomeGroup Provider

Volume Shadow Copy

Microsoft Software Shadow Copy Provider

Windows Backup

Bluetooth Support Service

Optimize Drives

Computer Browser

Secure Socket Tunneling Protocol Service

Windows Connect Now – Config Registrar

Background Intelligent Transfer Service

BitLocker Drive Encryption Service

Block Level Backup Engine Service Offline Files

Device Association Service

Security Center

Device Setup Manager Service

Sensor Monitoring Service

Diagnostic Policy Service

Shell Hardware Detection

Family Safety

SSDP Discovery

Distributed Link Tracking Client Fax

Function Discovery Resource Publication

#VMwarePorvExperts

SNMP Trap Service Superfetch

Windows Color System

Windows Defender Service Windows Error Reporting Service Windows Media Player Network Sharing Service Windows Update

WLAN AutoConfig

WWAN AutoConfig

Telephony

754

Capítulo 13 - Citrix en vSphere Héctor Herrero

Servicios que podemos deshabilitar en Windows 10: Automáticos

Background Intelligent Transfer Service Device Association Service

Diagnostic Policy Services

Manuales AllJoyn Router

Offline Files

Application Layer Gateway Service

Optimize Drives

BitLocker Drive Encryption Service

Retail Demo

Bluetooth Hands free Service

UPnP Device Host Service

Block Level Backup Engine Service

Sensor Monitoring Service

Diagnostics Tracking Service

Bluetooth Support Service

Function Discovery Provider Host

Windows Error Reporting Service

BranchCache Service

Function Discovery Resource Publication

Windows Media Player Network Sharing

Computer Browser Service

Windows Update

Home Group Provider

Encrypting File System Service

WLAN AutoConfig

Security Center

Fax Service

Shell Hardware Detection Service

WWAN AutoConfig

Home Group Listener

Xbox Live Auth Manager

Internet Connection Sharing (ICS)

Xbox Live Game

Diagnostic Service Host Diagnostic System Host

SSDP Discovery SuperFetch Themes

Windows Connect Now – Config Registrar Service Windows Search



#VMwarePorvExperts

755

Capítulo 13 - Citrix en vSphere Héctor Herrero

Tareas programadas a deshabilitar en Windows 201x: AitAgent

GadgetManager

StartupAppTask

AutoWake

KernelCeipTask

UninstallDeviceTask

AnalyzeSystem BfeOnServiceStartTypeChange BthSQM

ConfigNotification Consolidator

DiskDiagnosticDatacollector DiskDiagnosticResolver FamilySafetyMonitor

FamilySafetyRefresh

HotStart

MobilityManager

ProgramDataUpdater Proxy

RacTask

RegIdleBackup ResolutionHost planned

SystemDataProviders UpdateLibrary Upload

UPnPHostConfig UsbCeip

Windows Filtering WinSAT

SessionAgent

Tareas programadas a deshabilitar en Windows 10: Application Experience \ Appraiser

Windows Defender \ Windows Defender CacheMaintenance

Defrag \ ScheduledDefrag

Windows Defender \ Windows Defender Cleanup

FileHistory \ File History

Windows Defender \ Windows DefenderScheduled Scan

Maintenance \ WinSAT

Windows Defender \ Windows DefenderVerification

MemoryDiagnostic \ ProcessMemoryDiagnosticEvents

Windows Filtering Platform \BfeOnServiceStartTypeChange

MemoryDiagnostic \ RunFullMemoryDiagnostic

Application Experience \ StartupAppTask

Power Efficiency Diagnostics \ AnalyzeSystem

Customer Experience Improvement Program \UsbCeip

CHKDSK \ Proactive Scan

RecoveryEnvironment \ VerifyWinRE

Diagnosis \ Scheduled

Shell \ FamilySafetyRefresh

DiskDiagnostic \ MicrosoftWindowsDiskDiagnosticDataCollector

Registry \ RegIdleBackup

Application Experience \ ProgramDataUpdater AutoCHK \ Proxy

Customer Experience Improvement Program \Consolidator Customer Experience Improvement Program \KernelCeipTask Customer Experience Improvement Program \Uploader

Shell \ FamilySafetyMonitor

Windows Defender \ Windows Defender CacheMaintenance

#VMwarePorvExperts

DiskDiagnostic \ MicrosoftWindowsDiskDiagnosticResolver

SystemRestore \ SR WDI \ ResolutionHost

756

Capítulo 13 - Citrix en vSphere Héctor Herrero

Todas estas tareas podemos eliminarlas con el siguiente script de PowerShell donde omitimos por ejemplo el GotoAssist por si queremos que se actualice en background o la tarea que permite que Outlook se minimice en la barra de tareas… ejemplo: $schedule = New-Object -com Schedule.Service $schedule.connect() $tasks = $schedule.getfolder(“\”).gettasks(0) foreach ($task in ($tasks | select Name)) { if ($task -notmatch “G2MUpdateTask”){ $task2 = $task } if ($task2 -notmatch “outlook”){ SchTasks /Delete /TN $($task2.name) /f } }

Limitaremos los visores de sucesos a 1028Kb y en la retención marcaremos que se sobrescriban. Así como es posible que nos interese redireccionarlos a otro disco, lo tenemos en el registro, en: HKLM\ SYSTEM\CurrentControlSet\Services\Eventlog\NombreRegistro\. Deshabilitaremos Windows Update y sus reinicios oportunos, además que Windows Update no busque actualizaciones para los drivers de los dispositivos. En las opciones avanzadas del sistema, en Rendimiento, estableceremos ‘Programas’ para mejorar el rendimiento de la programación del procesador. Además, estableceremos los efectos visuales en la opción para obtener el mejor rendimiento. También recordar que el plan de energía esté en alto rendimiento, tanto en Windows como en las BIOS si trabajamos con equipos físicos. Os dejo una tabla resumen con otras opciones interesantes, aún que Citrix Optimizer ya nos automatizará gran parte de ellas:

Deshabilitar hibernación

Deshabilitar Data Execution Prevention Deshabilitar la recuperación del sistema

Deshabilitar salvapantallas predeterminado Deshabilitar logon de W10 animado

#VMwarePorvExperts

powercfg -h off bcdedit /set nx AlwaysOff bcdedit /set recoveryenabled no HKEY_USERS\.DEFAULT\ControlPanel\Desktop “ScreenSaveActive”=dword: 00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\ System] “EnableFirstLogonAnimation”=dword:00000000

757

Capítulo 13 - Citrix en vSphere Héctor Herrero

Deshabilitar mensajes Hard Error Poner los efectos visuales en personalizado Deshabilitar mostrar el rectángulo de selección translucido

Deshabilitar mostrar sombras bajo las ventanas Deshabilitar animar las ventanas al minimizar y maximizar

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows] “ErrorMode”=dword:00000002 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ VisualEffects] “VisualFXSetting”=dword:00000003 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ Advanced] “ListviewAlphaSelect”=dword:00000000 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ Advanced] “ListviewShadow”=dword:00000000 [HKEY_CURRENT_USER\ControlPanel\Desktop\WindowMetrics] “MinAnimate”=”0”

Deshabilitar las animaciones en la barra de tareas

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ Advanced] “TaskbarAnimations”=dword:00000000

Deshabilitar guardar las vistas previas de miniaturas en la barra de tareas

[HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM] “AlwaysHibernateThumbnails”=dword:00000000

Deshabilitar Peek

[HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM] “EnableAeroPeek”=dword:00000000

Deshabilitar suavizar bordes [HKEY_CURRENT_USER \Control Panel\Desktop] para las fuentes “FontSmoothing”=”0” de pantalla

Deshabilitar el [HKEY_CURRENT_USER \Control Panel\Desktop\] resto de efectos “UserPreferencesMask”=RegBin: “90,12,01,80” visuales Deshabilitar el parpadeo del ratón

Deshabilitar asistente primer uso del IE Reducir el tiempo para mostrar los menús.

Aumentar el tiempo de espera de los servicios

#VMwarePorvExperts

[HKEY_CURRENT_USER \Control Panel\Desktop] “CursorBlinkRate”=”-1″ [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\InternetExplorer\Main] “DisableFirstRunCustomize”=dword:00000001 [HKEY_CURRENT_USER\ControlPanel\Desktop] “MenuShowDelay”, “0” [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control] “ServicesPipeTimeout”=dword:0x001d4c0

758

Capítulo 13 - Citrix en vSphere Héctor Herrero

Deshabilitar Last Access Time Stamp para evitar actualizar la MFT

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\File System] “NtfsDisableLastAccessUpdate”=dword:00000001

Desabilitar la creación de volcados de memoria.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl] “CrashDumpEnabled”=dword:00000000 “LogEvent”=dword:00000000 “SendAlert”=dword:00000000

Disable Large Send Offload

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters] “EnableOffload”=dword:00000000

En entornos PVS además es recomendable generar las imágenes maestras con UEFI reemplazando por la BIOS tradicional, el arranque será más rápido. Así como si optamos por generar los discos en formato VHDX y formatearlos con ReFS v2, obtendremos mucho mayor rendimiento a la hora de aprovisionar y crear las máquinas, así como a la hora de combinar discos desde los snapshots. Si estamos usando Windows 10 como entrega, además, deberíamos eliminar todas las aplicaciones que trae por defecto instaladas. Con ‘Get-ProvisionedAppXPackage -Online|Select DisplayName’ listaremos las aplicaciones instaladas y con ‘Get-AppxPackage -AllUsers | Remove-AppxPackage’ las eliminaremos. Si la máquina necesitase de un software agente Antivirus, especial atención a la manera de desplegarlo, deberemos consultar las guías de cada fabricante para no afectar al rendimiento del entorno. Una idea buena puede ser habilitar el antivirus de hipervisor VMware vShield para evitar repercutir en el entorno con este tipo de soluciones antivirus tradicionales. Deberemos además crear las exclusiones necesarias en cada tipo de máquina: VDA Servidor Archivos

Procesos

%userprofile%\AppData\Local\Temp\Citrix\HDXRTConnector\*\*.txt

%ProgramFiles%\Citrix\User Profile Manager\UserProfileManager.exe %ProgramFiles%\Citrix\Virtual Desktop Agent\BrokerAgent.exe %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con AppDisks) %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con AppDisks) %SystemRoot%\System32\spoolsv.exe %SystemRoot%\System32\winlogon.exe

VDA Desktop Archivos

Procesos

#VMwarePorvExperts

%userprofile%\AppData\Local\Temp\Citrix\HDXRTConnector\*\*.txt

%ProgramFiles%\Citrix\User Profile Manager\UserProfileManager.exe %ProgramFiles%\Citrix\Virtual Desktop Agent\BrokerAgent.exe %ProgramFiles%\Citrix\ICAService\picaSvc2.exe %ProgramFiles%\Citrix\ICAService\CpSvc.exe %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con PvD y AppDisks) %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con PvD y AppDisks) %SystemRoot%\System32\spoolsv.exe %SystemRoot%\System32\winlogon.exe

759

Capítulo 13 - Citrix en vSphere Héctor Herrero

Delivery Controller Archivos Directorios Procesos

%systemroot%\ServiceProfiles\NetworkService\HaDatabaseName.mdf %systemroot%\ServiceProfiles\NetworkService\HaImportDatabaseName.mdf %systemroot%\ServiceProfiles\NetworkService\HaDatabaseName_log.ldf %systemroot%\ServiceProfiles\NetworkService\HaImportDatabaseName_log.ldf %programdata%\Citrix\Broker\Cache

%ProgramFiles%\Citrix\Broker\Service\BrokerService.exe %ProgramFiles%\Citrix\Broker\Service\HighAvailabilityService.exe %ProgramFiles%\Citrix\ConfigSync\ConfigSyncService.exe

StoreFront Archivos Procesos

%SystemRoot%\ServiceProfiles\NetworkService\AppData\Roaming \Citrix\SubscriptionsStore\**\PersistentDictionary.edb

%ProgramFiles%\Citrix\Receiver StoreFront\Services\SubscriptionsStoreService \Citrix.DeliveryServices.SubscriptionsStore.ServiceHost.exe %ProgramFiles%\Citrix\Receiver StoreFront\Services\CredentialWallet \Citrix.DeliveryServices.CredentialWallet.ServiceHost.exe

Servidor PVS

Archivos

Procesos

**\*.vhd **\*.avhd **\*.vhdx **\*.avhdx %SystemRoot%\System32\drivers\CvhdBusP6.sys (Windows Server 2008 R2) %SystemRoot%\System32\drivers\CVhdMp.sys (Windows Server 2012 R2) %SystemRoot%\System32\drivers\CfsDep2.sys %ProgramData%\Citrix\Provisioning Services\Tftpboot\ARDBP32.BIN %ProgramFiles%\Citrix\Provisioning Services\BNTFTP.EXE %ProgramFiles%\Citrix\Provisioning Services\PVSTSB.EXE %ProgramFiles%\Citrix\Provisioning Services\StreamService.exe %ProgramFiles%\Citrix\Provisioning Services\StreamProcess.exe %ProgramFiles%\Citrix\Provisioning Services\soapserver.exe

Agente PVS (o Target Device)

Archivos

**\*.vdiskcache **\vdiskdif.vhdx %SystemRoot%\System32\drivers\bnistack6.sys %SystemRoot%\System32\drivers\CfsDep2.sys %SystemRoot%\System32\drivers\CVhdBusP6.sys %SystemRoot%\System32\drivers\CVhdMp.sys

%ProgramFiles%\Citrix\PvsVm\Service\PvsVmAgent.exe %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con PvD y AppDisks) %ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con PvD y AppDisks)

#VMwarePorvExperts

760

Capítulo 13 - Citrix en vSphere Héctor Herrero

Citrix Receiver Archivos

Procesos

%userprofile%\AppData\Local\Temp\Citrix\RTMediaEngineSRV \MediaEngineSRVDebugLogs\*\*.txt

%programfiles(x86)%\Citrix\ICA Client\MediaEngineService.exe %programfiles(x86)%\Citrix\ICA Client\CDViewer.exe %programfiles(x86)%\Citrix\ICA Client\concentr.exe %programfiles(x86)%\Citrix\ICA Client\wfica32.exe %programfiles(x86)%\Citrix\ICA Client\AuthManager\AuthManSvr.exe %programfiles(x86)%\Citrix\ICA Client\SelfServicePlugin\SelfService.exe %programfiles(x86)%\Citrix\ICA Client\SelfServicePlugin\SelfServicePlugin.exe

Para finalizar, si necesitas la guía oficial de optimización de Windows 10, o para analizar detenidamente con más detalle este tema, puedes echar un vistazo a: https://support.citrix.com/article/CTX216252

 

#VMwarePorvExperts

761

Capítulo 13 - Citrix en vSphere Héctor Herrero

18. Upgrade Una buena práctica para evitar problemas y bugs será siempre utilizar la última versión de Citrix disponible; nos decantaremos opcionalmente por usar una versión LTSR, que es una versión estable y con largo tiempo de soporte, pero quizá menos novedades de funcionalidad. No es arbitraria la manera de actualizar nuestro sitio Citrix, y tras verificar que cumpliremos los requisitos de compatibilidad, seguiremos un orden específico de actualización.

De manera muy resumida, previo a disponer de copias de seguridad de las BBDD de Citrix, las MVs que proporcionan servicios y, como no, un snapshot. Comenzaremos por el primer componente, StoreFront. deberemos actualizar el primer servidor de la granja y posteriormente el resto de servidores del Grupo Storefront y replicar su configuración. Si disponemos Director instalado en una máquina dedicada, será su turno. Realizaremos copia también de las plantillas VDA si no lo hemos hecho ya. Actualizaríamos los servidores de Provisioning Services y a continuación las VDA y su agente de PVS. Será momento ya de actualizar nuestro primer Delivery Controller (o único) y tras ello abrir la consola Citrix Studio, deberemos actualizar el sitio de Citrix, y dependiendo el acceso que dispongamos a las bases de datos, podremos actualizar directamente desde la consola el esquema, o proveer al DBA los scripts para que haga el upgrade de las BBDD. Tras la actualización del sitio verificamos que todo el funcionamiento es correcto. Si tenemos más Delivery Controllers procederemos a actualizarlos para finalizar el proceso de upgrade.  

#VMwarePorvExperts

762

Capítulo 13 - Citrix en vSphere Héctor Herrero

19. Citrix Cloud Como no, Citrix también provee soluciones cloud o hibridas en base a nuestra necesidad. Como hasta ahora podemos disponer de nuestra infraestructura en nuestras instalaciones o externalizar el área que nos interese. Dependerá de nuestro negocio y la manera de trabajo a la hora de diseñar el entorno, así como de su crecimiento y los recursos que dispongamos On Premise. Analizaremos los costes y requisitos que nos suponga cada escenario. Obviamente la parte crítica en estos escenarios es la conectividad al sitio cloud, donde el ancho de banda y la latencia de acceso tiene su importancia, ya que los usuarios, desde los VDA, deben tener acceso inmediato a los recursos con los que trabajen. Podemos utilizar los servicios nube públicos como son Citrix CloudPlatform, Microsoft Azure o Amazon EC2, así como nubes privadas que ofrecen los proveedores de servicios, la idea y resultado final debe ser el mismo, simplificar la entrega unificando recursos. Todo ello, gracias a Citrix Cloud Connector, que será el conector que interconecta nuestros recursos con las distintas nubes. Se despliega en cada sitio que disponga recursos, mediante él dispondremos de una conexión unificada y segura, totalmente transparente para nuestros usuarios que simplemente se limitarán a trabajar de igual manera.

Puede que nos interese externalizar inicialmente la parte de infraestructura, donde albergaremos y ejecutaremos nuestras máquinas VDA en nube, suele ser interesante en entornos donde la carga es indeterminada y variable, donde tengamos que dar recursos a usuarios en base a su demanda, donde hoy tenemos pocos usuarios y mañana miles de ellos. Sería buena idea albergar parte de los VDA y generar tantos como necesitemos arriba, ideal en nubes de pago por uso. También conocido como Cloud Hosted XenDesktop.

#VMwarePorvExperts

763

Capítulo 13 - Citrix en vSphere Héctor Herrero

Citrix Workspace Control plantea otra posibilidad, y no es más que la de subir al cloud la capa de control, que igualmente la gestionaremos de manera centralizada desde la nube. Con idea de mantener los recursos que necesiten los usuarios junto a las máquinas VDA, normalmente en entornos donde la información no puede salir de la organización y además queremos externalizar la infraestructura necesaria para su funcionamiento.

Y obviamente, cómo no, podremos externalizar todo lo necesario en un Citrix Cloud Provider y confiar en él todos nuestros recursos. Se ejecutarán y almacenarán fuera de nuestra organización, donde ya nada dependerá de nuestra infraestructura.  

#VMwarePorvExperts

764

Capítulo 13 - Citrix en vSphere Héctor Herrero

20. Fundamentos sobre vSphere En este capítulo de Citrix hemos visto a modo global ciertas mejoras en configuraciones que podemos aplicar para mejorar tu entorno; ahora, en este apartado, intentaremos agrupar todas las consideraciones que debemos tener en cuenta a la hora de virtualizar nuestra plataforma Citrix bajo VMware vSphere. A lo largo del libro habrás ido conociendo trucos y optimizaciones de la plataforma virtual que podrás aplicar como norma general en tu entorno Citrix. Quizá de toda la infraestructura de Citrix, las máquinas VDA deben ser especialmente las MVs con mayores y mejores recursos. De sobra queda indicar que debemos utilizar procesadores de última generación y evitar siempre que podamos CPU Over-Commitment. Intentando no superar los cores que ofrece un procesador físico por vCPUs en las MVs. Es importante que las máquinas de Citrix se ejecuten desde el mismo nodo NUMA, con objeto de no ralentizar accesos a CPU o RAM, por tanto, definamos las MVs que necesitemos con los cores necesarios, pero sin pasarnos. Sobre todo, en las máquinas VDA y servidores PVS. Valores a revisar serán el CPU Ready y CPU Wait. Para optimizar memoria RAM, una buena idea será ejecutar las MVs con el mismo SO sobre los mismos hosts, la tecnología de VMware, Transparent Memory Page Sharing será más efectiva, ahorrando memoria física en los nodos. Al igual que con la CPU deberemos tener cuidado a la hora de definir la RAM de cada MV evitando siempre que podamos pasarnos de los recursos físicos de cada host. Obviamente, si vemos uso de memoria Swap o Balloning lo corregiremos. Al igual que para el acceso a disco, deberemos proporcionar almacenamiento rápido, siempre que se pueda, los VDA y sus usuarios agradecerán disco sólido. Buenas prácticas será disponer de multipathing configurado en los hosts para su acceso como disponer Storage DRS habilitado en nuestros clústeres de datastores para evitar saturar los datastores con IOs o latencias altas. En entornos grandes, deberemos calcular las IOPS necesarias en base a los recursos que vamos a necesitar. Para discos de datos, como son por ejemplo los almacenes de PVS es buena idea utilizar el adaptador de disco VMware Paravirtual SCSI o PVSCSI. Y como no, en entornos de producción, siempre utilizaremos discos thick. En cuanto a la red, no es necesario hacer hincapié, ya que este recurso es raramente saturado. Una buena práctica será separar los tráficos de red de las MVs de los usuarios y MVs de infraestructura, segmentándolos en diferentes vSwitch o con VLANs. Así como disponer NIC teaming en los host para evitar caídas y balancear tráficos de red. Siempre que podamos, las MVs deberán utilizar el adaptador optimizado de red VMXNET 3. Recordar disponer de las VMware Tools instaladas y actualizadas, a la hora de instalarlas en las máquinas VDA tendremos especial cuidado en no instalar los Shared Folders. Con todo esto, nuestro entorno virtual no debería tener problemas de acceso a los recursos. Las máquinas virtuales deberán estar protegidas por clústers con HA habilitado, así como DRS para balancear la carga de los recursos entre los hosts del clúster. Prestar atención en quizá la necesidad de definición de grupos y reglas de afinidad y anti-afinidad, ya que las MVs que prestan los mismos recursos se deberían ejecutar en distintos nodos para garantizar tolerancia a fallos. Remarcar que las VDA son máquinas que quizá debamos subir sus Shares para un acceso con mayor prioridad que el resto de MVs a los recursos de CPU, RAM o disco. Dependiendo del entorno podamos reservar recursos mínimos a las MVs de Citrix, todo ello como ya sabemos, podremos realizarlo de manera individual por MV o mediante Resource Pools.

#VMwarePorvExperts

765

Capítulo 13 - Citrix en vSphere Héctor Herrero

21. Links interesantes Instalación de los componentes de Citrix Virtual Apps and Desktops: http://www.bujarra.com/instalacion-de-xenapp-7-5/ Configurando alta disponibilidad con Citrix StoreFront: http://www.bujarra.com/grupo-de-servidores-citrix-storefront-para-ha/ Configuración de balanceo de StoreFront con Citrix NetScaler: http://www.bujarra.com/load-balancing-de-storefront-con-citrix-netscaler/ Configuración de alta disponibilidad con Citrix NetScaler: http://www.bujarra.com/alta-disponibilidad-con-citrix-netscaler/ Instalación, configuración y despliegue de imágenes con Citrix Provisioning Services: http://www.bujarra.com/citrix-provisioning-services-7-1-con-citrix-xendesktop-7-1-parte-1/ http://www.bujarra.com/citrix-provisioning-services-7-1-con-citrix-xendesktop-7-1-parte-2/ http://www.bujarra.com/citrix-provisioning-services-7-1-con-citrix-xendesktop-7-1-parte-3/ Configurando alta disponibilidad con Citrix Provisioning Services: http://www.bujarra.com/citrix-provisioning-en-high-availability/ Configuración de balanceo de Citrix Provisioning Services con Citrix NetScaler: http://www.bujarra.com/load-balancing-de-provisioning-con-citrix-netscaler/ Actualizando una imagen VDA maestra con Citrix Provisioning Services: http://www.bujarra.com/actualizando-un-vdisk-en-citrix-provisioning/ Instalar Citrix VDA en Linux: https://www.maquinasvirtuales.eu/instalar-citrix-vda-en-servidor-linux/ Cambiando el idioma del portal StoreFront: http://www.bujarra.com/cambiando-el-idioma-de-citrix-storefront-a-euskera-catalan/ Personalizando mensajes en el portal StoreFront: http://www.bujarra.com/personalizando-mensajes-en-citrix-storefront/ Personalizando los iconos de los desktops: http://www.bujarra.com/personalizando-iconos-escritorios-virtuales-aplicaciones-contenido-citrixxenapp-xendesktop/ Publicando contenidos: http://www.bujarra.com/publicando-contenidos-con-citrix-xenapp/ Instalando y configurando Citrix Universal Print Server: https://www.maquinasvirtuales.eu/instalacion-y-configuracion-citrix-universal-printer-server/ Configurando SQL Mirroring con Witness: http://www.bujarra.com/xendesktop-sql-mirroring-con-witness/

#VMwarePorvExperts

766

Capítulo 13 - Citrix en vSphere Héctor Herrero

Grabación de sesiones de los usuarios: http://www.bujarra.com/session-recording-en-citrix-xenapp-7-6-2/ Auto configuración de Citrix Receiver con el dominio de correo: http://www.bujarra.com/configuracion-de-citrix-receiver-mediante-el-correo-electronico/ Auto configuración de Citrix Receiver en dispositivos móviles: http://www.bujarra.com/citrix-mobile-receiver-setup-url-generator/ Raspberry Pi como thinclient para acceso a Citrix: http://www.bujarra.com/uso-de-raspberry-pi-como-cliente-ligero-soportado-en-citrix/ Hardening en VDAs de Citrix: https://www.maquinasvirtuales.eu/hardening-citrix-xenapp/ Utilizando Citrix AppDisk: http://www.bujarra.com/utilizando-citrix-appdisk/ Configuración de vGPU en VMware para Citrix: https://www.maquinasvirtuales.eu/configuracion-vgpu-en-vmware-6-para-citrix-xenapp/ Auto servicio de cuentas con Citrix Self Service: http://www.bujarra.com/citrix-self-service-password-reset-autoservicio-de-restablecimiento-decontrasenas-y-desbloqueo-de-cuentas/ Personalizar el menú inicio a la hora de entregar desktops: https://www.maquinasvirtuales.eu/personalizar-menu-inicio-en-una-template-desktop/ Integrando y publicando apps en desktops Citrix: http://www.bujarra.com/publicando-aplicaciones-de-citrix-xendesktop-a-citrix-xendesktop/ Uso de PowerShell para administrar entornos Citrix: https://www.maquinasvirtuales.eu/comandos-powershell-administracion-citrix/ Uso de Citrix Health Assistant para chequear la salud del VDA: https://www.maquinasvirtuales.eu/citrix-health-assistant-chequear-vda/ Citrix Virtual Desktop Handbook 7.6 LTSR https://support.citrix.com/article/CTX139331 Citrix Virtual Apps and Desktops Security Guidance https://docs.citrix.com/en-us/xenapp-and-xendesktop/downloads/getting-started-with-citrix-xenappxendesktop-security.pdf System Hardening Guidance for XenApp and XenDesktop https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/system-hardening-forxenapp-and-xendesktop.pdf

#VMwarePorvExperts

767

Capítulo 13 - Citrix en vSphere Héctor Herrero

#VMwarePorvExperts

768

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

769

Capítulo 14 vRealize Orchestrator

Federico Cinalli

#VMwarePorvExperts

770

Capítulo 14 - vRealize Orchestrator Federico Cinalli

1. Introducción vRealize Orchestrator o vRO es el gran desconocido en la numerosa familia de productos de VMware. Se trata de una herramienta de orquestación con interface gráfico, muy simple de utilizar. Lo mejor de todo es que si disponemos de licencia de vCenter entonces también contamos con la licencia de vRealize Orchestrator. ¿Simple verdad? El spin off de vRO era VS-O (Virtual Service Orchestrator) desarrollado por una compañía suiza llamada Dunes. En 2007 VMware compró Dunes y rebautizó VS-O como vCenter Orchestrator o vCO introduciéndolo como parte de la Suite vSphere 4.0. Seguramente muchos se acuerdan de aquel misterioso icono naranja que, en principio, no parecía aportar mucha funcionalidad. vRealize Orchestrator empezó a conocerse un poco más de la mano de vCAC o vCloud Automation Center 5.x/6.x. la cual luego pasaría a llamarse vRealize Automation. vRealize Orchestrator es el compañero perfecto de vRA. vRealize Orchestrator puede trabajar con o sin vRA, pero vRA tiene como requerimiento una instancia de vRealize Orchestrator para poder funcionar. Como se mencionó anteriormente, el Appliance de vRO consume muy pocos recursos y, en entornos de producción, es posible configurarlo en modo Cluster para ofrecer alta disponibilidad. Desde la versión 7.3 de vRO podemos utilizar la base de datos embebida para dar soporte al servicio de Cluster cuando anteriormente esta configuración requería una base de datos SQL Server externa. Existen dos formas diferentes de desplegar vRO. Una es utilizar la instancia embebida que incluye el Appliance de vRA. La segunda, y normalmente la más utilizada, es instalando el propio Appliance de vRealize Orchestrator de forma independiente.

Imagen OVA de la versión 7.5.0

#VMwarePorvExperts

771

Capítulo 14 - vRealize Orchestrator Federico Cinalli

2. Casos de Uso de vRealize Orchestrator Tal como comentamos anteriormente, vRealize Orchestrator es el gran desconocido. Básicamente muchos saben que, en español, vRO es un Orquestador. ¿Pero realmente cuáles son los casos de uso? Se sabe que el potencial es enorme, aunque tal vez nos falten ejemplos un poco mas concretos de para qué normalmente podríamos utilizar vRO. vRealize Orchestrator es un gran pulpo que conecta con prácticamente todos los tipos de recursos y servicios. Hay conexiones nativas a través de los Plugins que utilizan API. Y hay otras que requieren conectarse a través de comodines como puede ser SSH, REST API o incluso Powershell.

Integración de vRO en un entorno con vRA y vCenter

Hoy en día el principal caso de uso de vRO es dar servicio a vRealize Automation tanto para los Blueprints tipo XaaS (lo que sea como servicio), las subscripciones de Event Broker y también lo que se conoce como Resource Actions. Estos tres tipos de servicios de vRA están respaldados por uno o más Workflows de vRO.

#VMwarePorvExperts

772

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Extensibilidad de vRO con otros productos vía Powershell

También es posible utilizar vRealize Orchestrator sin vRealize Automation. En ese caso perderíamos el amistoso interface de usuario, el sistema de autenticación integrado con Identity Manager, control de costos y el sistema de aprobaciones que aporta vRA. Para este último enfoque hablaríamos de procedimientos orquestados gestionados únicamente desde el área de sistemas. Entre las diferentes tareas que se pueden realizar están la configuración en masa de parámetros en recursos de infraestructura como pueden ser Hosts y VMs. Integración con soluciones complementarias como pueden ser Ansible, Puppet y Chef por mencionar algunas. Procedimientos orquestados como el alta de un usuario con su cuenta en Active Directory, su buzón y cuenta en Office 365, su escritorio de XenApp bajo demanda, creación de estructura de carpetas y asignación correspondiente de permisos y envío de mail con PDF adjunto con instrucciones de uso de los sistemas de TI. Automatización de altas de clientes y/o usuarios con sus correspondientes recursos como pueden ser aplicaciones multi maquina, reglas de firewall, balanceadores, clusters, VPNs, etc. En el caso de vRA vamos a poder conectar con infinidad de recursos e interconectar, por ejemplo, servicios de CMDB como Service Now, sistemas de control de costo, soluciones de Backup/DR, IPAMs y demás como parte de una única petición en el catalogo. Como vemos las opciones son infinitas. Bienvenidos al apasionante mundo de vRealize Orchestrator.

 

#VMwarePorvExperts

773

Capítulo 14 - vRealize Orchestrator Federico Cinalli

3. Configuración y Consolas La instalación del Appliance de vRO es simple, siguiente-siguiente. Lamentablemente está fuera del alcance del capítulo pero no es más que configurar parámetros como Contraseña Root, Hostname, IP, DNS, Gateway, Red, Datastore y Cluster.

Opciones de configuración del Appliance de vRO

Una vez que finalizamos el despliegue del Appliance veremos lo siguiente en la consola de la VM:

Vista de consola de vRO

#VMwarePorvExperts

774

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Como podemos observar existen diferentes consolas en vRealize Orchestrator. A la primera que deberíamos acceder sería el Appliance Configuration a través de la IP o el nombre de la VM utilizando https y el puerto 5480. ¿Qué vamos a verificar o configurar en la Consola? Configuraciones como Cluster, cambio de contraseña de root, parámetros de Red, NTP, verificar algún Parche o Actualización disponible, habilitar el acceso SSH o simplemente reiniciar o apagar el Appliance.

Vista de la Consola del Appliance de vRO

Lo siguiente a configurar será el Control Center. Para acceder abriremos una instancia del navegador utilizando https://nombre-o-ip:8283/vco-controlcenter. TIP: Si una vez desplegado vRO no abre la Web del Control Center, entonces ejecutaremos vía SSH el siguiente comando -> service vco-configurator restart

Vista del Control Center

#VMwarePorvExperts

775

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Como parte de la configuración inicial tendremos que definir el proveedor del sistema de autenticación a utilizar. Las dos opciones son: vSphere SSO y vRA Identity Manager.

Configuración del proveedor de autenticación

Aquí no será muy difícil decidirse por una u otra opción. Si estamos desplegando vRO como parte de vRealize Automation, entonces utilizaremos vRA IM (Identity Manager). Y en el caso de una instalación simple para orquestar principalmente soluciones en vSphere, entonces utilizaremos Single Sign On. Otra configuración que utilizaremos frecuentemente en el Control Center será la de gestión de certificados. Existen varios Plugins que requieren la importación previa de certificados digitales antes de poder ejecutar correctamente un Workflow. La buena noticia es que es ridículamente simple importar un certificado como podemos ver en la siguiente imagen. Tan solo debemos introducir la URL del recurso que utiliza el certificado o bien importar el fichero PEM.

Importando Certificados en vRealize Orchestrator

La configuración de Logs también la definiremos a través de la consola del Control Center. Por un lado, el nivel de Logs que deseamos registrar y almacenar, y por el otro el servidor que utilizaremos para almacenar y gestionar los eventos y Logs.

#VMwarePorvExperts

776

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Configuración de Logs en vRO

Consideremos una buena práctica reenviar los Logs a un sistema centralizado de Almacenamiento, Indexación y Gestión de Logs como podría ser vRealize Log Insight.

Configuración de la integración de vRO con un Syslog externo

Los Plugins en vRealize Orchestrator nos ofrecen integración con sistemas externos como Powershell, NSX, AMQP, REST, sistemas que utilizan SSH, Active Directory, vCenter y varios otros. Por defecto con la instalación tenemos instalados varios Plugins como podemos ver en la imagen:

#VMwarePorvExperts

777

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Algunos de los Plugins que están instalados por defecto en vRO

Cada vez son más las empresas que desarrollan sus propios Plugins para ofrecer un valor agregado para diferentes tareas. Podremos encontrar Plugins de vRO en las webs de los fabricantes, pero el sitio por excelencia es VMware Solutions Exchange. Es posible filtrar por Producto (vRealize Orchestrator) y tipo de contenido para encontrar tanto Plugins como incluso también Workflows.

Vista de VMware Solutions Exchange

La pregunta que corresponde ahora es: ¿Cómo podemos instalar nuevos Plugins o actualizar alguno de los existentes? Una vez descargado el Plugin utilizaremos Control Center para instalarlos o actualizarlos.

#VMwarePorvExperts

778

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Opción del Control Center para subir Plugins

Llegados a este punto debemos repasar. Instalamos el Appliance definiendo los parámetros iniciales de Red. Validamos la configuración inicial en la consola del Appliance accediendo a través del puerto 5480. Opciones como NTP y Zona horaria (fundamental en Orchestrator para resolución de problemas) se definen en la consola del Appliance. Utilizando el Control Center definimos el proveedor de autenticación, configuramos los Logs y los integramos con nuestro syslog. También importamos los certificados necesarios (aunque esto puede hacerse en cualquier momento) y pudimos ver cómo instalar un nuevo Plugin. El siguiente Mind Map puede resultar útil para resumir las diferentes consolas y sus principales funcionalidades.

Opciones resumidas de las diferentes Consolas de vRO

#VMwarePorvExperts

779

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Ahora, podemos decir que nuestro vRO está listo para comenzar a trabajar con Workflows. ¡Casi listo! Tenemos que vincular las soluciones con las que queremos trabajar en el inventario de Orchestrator y para eso necesitamos movernos de herramienta, deberíamos pasarnos al Cliente de vRealize Orchestrator, pero antes es necesario comprender conceptos fundamentales en vRealize Orchestrator.

#VMwarePorvExperts

780

Capítulo 14 - vRealize Orchestrator Federico Cinalli

4. Conceptos de vRealize Orchestrator Antes de avanzar con temas mas técnicos veamos primero de forma simple algunos de los nombres y conceptos que vamos a necesitar comprender para utilizar la herramienta. Workflow: El Workflow es la esencia de Orchestrator. Es aquí donde definimos lo que queremos ejecutar, en qué orden, con qué parámetros, basado en qué dependencias o condiciones, hacer llamadas a otros sistemas y un largo etcétera. Endpoint: Los Endpoints nos permiten ejecutar una acción sobre un determinado recurso u objeto. Prácticamente no tiene sentido ejecutar Workflows sin Endpoints. Como ejemplo podemos mencionar un Endpoint de vCenter, host SSH, host API, DC de Directorio Activo, F5, NSX, Puppet o Infoblox entre otros. Acción: Una acción es en vRO lo más parecido a una función ya que se trata de una ejecución simple, de una única tarea que devuelve un valor. El valor del resultado de la Acción puede ser un valor boolean, un número, una tarea o un objeto, por mencionar algunos ejemplos. Recurso: En vRealize Orchestrator es posible crear una lista de Recursos que podemos consultar desde un Workflow. Un ejemplo de Recurso puede ser un fichero de texto, un documento PDF o una configuración almacenada. Configuration Element: Un elemento de configuración o Configuration Element nos permite almacenar Atributos por fuera del ámbito de un Workflow. Aquí podríamos tener predefinidos valores como una instancia en concreta de vCenter, credenciales o bien atributos que utilizaremos como parte de un Workflow. Los valores estarán predefinidos e incluso es posible actualizarlos como parte de la ejecución del Workflow.

Configuration Element sin valores predefinidos

Paquete: Un paquete es un conjunto de objetos de vRealize Orchestrator. En un paquete podremos encontrar Workflows, Actions, Configuration Elements y Recursos. Normalmente utilizamos paquetes de vRO para importar o exportar uno o multiples Workflows y todas sus dependencias, desde una instancia de vRO a otra.

Vista de la opción Importar Paquete en vRO

#VMwarePorvExperts

781

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Elemento: Un Workflow Element o elemento de flujo de trabajo es un componente del propio Workflow que cumplirá una función determinada. Un Workflow Element puede ser un Action, un Scriptable Task, un elemento For Each, una llamada síncrona o asíncrona a otro Workflow o un elemento Log por mencionar algunos.

Ejemplo de un Workflow con 5 Workflow Elements

Parametro: Un Parametro es un valor, una variable, de un determinado tipo como puede ser Texto (String), Numero (Number), una variable verdadero/falso (boolean) o incluso un objeto de un Endpoint como una Unidad Organizativa de una instancia de Directorio Activo. Existen Parametros de entrada (Input Parameters) y Parametros de salida (Output Parameters). Los Input Parameters aparecen ni bien ejecutamos un Workflow para que definamos su valor o variable.

Listado de dos Input Parameters de un Workflow

Vista de los Input Parameters al ejecutar el Workflow

Atributo: Un Attribute es un Parámetro que está predefinido o se define durante la ejecución del Workflow. Si el Atributo está predefinido podríamos considerarlo una constante. Se utiliza también un atributo para pasar variables entre Workflow Elements durante la ejecución del Workflow. No es posible pasar una variable de forma directa entre Workflow Elements. Objeto: Cuando instalamos un Plugin se define una lista de Objetos y las relaciones o dependencias entre sí. También se suelen incluir junto con el Plugin carpetas con Workflows y frecuentemente Actions. Como ejemplo podemos decir que un Objeto del Plugin de Active Directory es un Usuario. Para ejecutar un Workflow o una Acción que trabaja con ese tipo de Objeto deberemos previamente configurar el Endpoint de ese Plugin con al menos una instancia.

#VMwarePorvExperts

782

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Ejemplo de un Objeto Host que corresponde a una instancia de vCenter

#VMwarePorvExperts

783

Capítulo 14 - vRealize Orchestrator Federico Cinalli

5. El Cliente de vRealize Orchestrator El Cliente de vRO está basado en Java. Sí…Java. VMware está trabajando en un nuevo cliente llamado Operations Client (ya disponible en vRO 7.5) basado en HTML v5 pero, al igual que pasó con vSphere Client en 6.5, está muy (pero muy) limitado en cuanto a funcionalidades a la fecha en que se escribió este capítulo del libro. No obstante, sabemos que ése es el camino. Desde la web de vRO http://ip-o-nombreAppliance:8281/vco tenemos acceso al cliente de vRO. También es posible descargarlo directamente.

Cliente de vRealize Orchestrator

Es posible instalar el cliente de vRO o bien simplemente hacer click en el enlace. Recordemos que a este punto de la configuración ya tenemos pre-definido el tipo de autenticación (vSphere SSO o vRA Identity Manager). Ahora es cuando debemos presentar las credenciales correspondientes para acceder al Cliente de vRO. El cliente de vRO tiene tres modos de trabajo que son: •

Administración: El modo Administración permite visualizar los Endpoints y también Importar y Exportar paquetes de vRO.

•

Run: En modo Run o Ejecución seremos capaces de ejecutar Workflows y visualizar objetos del Inventario.

•

Diseño: El modo Diseño es el más interesante con diferencia ya que podremos crear, editar y ejecutar Workflows a la vez que será posible importar y exportar tanto Workflows como también Paquetes.

#VMwarePorvExperts

784

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Selección del modo de ejecución del vRO Client

Una vez que seleccionamos el modo de trabajo, normalmente Design, tenemos delante nuestro un mundo de posibilidades. Lo primero que deberíamos hacer sería agregar las diferentes instancias de componentes a nuestro inventario o, dicho de otra forma, configurar los Endpoints para tener acceso a Objetos. Como ejemplo podemos decir que si pretendemos ejecutar Workflows para cualquier tipo de tarea en vRealize Automation entonces tendremos que agregar nuestro vRA y su correspondiente IaaS como Endpoint del vRealize Orchestrator. Mismo procedimiento para recursos como Active Directory, Powershell, Ansible, NSX, Host API, Puppet, vCenter, etc, etc. Naturalmente que la pregunta es: ¿Cómo puedo agregar un recurso al inventario de mi vRO? La respuesta es muy simple. Ejecutando un Workflow. Por defecto, en la librería de Workflows, disponemos de elementos predefinidos que nos permitirán agregar un recurso a modo de Endpoint en nuestro inventario.

Workflow para agregar una instancia de vCenter al Inventario

¿De qué depende que ese Workflow esté disponible en nuestra biblioteca? Son los Plugins los que agregan carpetas de Workflows en la librería (además de las que creamos nosotros mismos). Esos Workflows normalmente están disponibles en una carpeta llamada Configuration y son lo que permite agregar un recurso a nuestro Inventario.

#VMwarePorvExperts

785

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Workflow que agrega una instancia de vCenter al Inventario de vRO

El ejecutar un Workflow veremos un elemento llamado Token que nos indica si la ejecución del Workflow finalizó correctamente o con un error. Por cada ejecución de Workflow tendremos un Token.

Workflow ejecutado correctamente

Workflow finalizado con un error

Una vez que tengamos un recurso agregado al Inventario ya seremos capaces de ejecutar un Workflow apuntando a uno o varios objetos de una instancia concreta del Inventario.

#VMwarePorvExperts

786

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Instancia de vCenter en el Inventario de vRO

Veamos un ejemplo: Necesitamos automatizar el despliegue de una maquina virtual utilizando Linked Clone en un vCenter en concreto. Como parte del proceso de ejecución del Workflow debemos definir un Input Parameter que, como se aprecia en la siguiente imagen, es un Snapshot de una VM que corresponde a una instancia de vCenter. Al tener nuestro vCenter en el Inventario ya somos capaces de seleccionar el Snapshot y proceder con la ejecución del Workflow.

Seleccionando un objeto de una instancia de vCenter del Inventario

#VMwarePorvExperts

787

Capítulo 14 - vRealize Orchestrator Federico Cinalli

6. Parametros, Atributos y Configuration Elements Si realmente estamos interesados en comprender cómo funciona un Workflow en vRealize Orchestrator, entonces es ahora cuando debemos aplicar todos los sentidos en este apartado. En el supuesto caso que nunca hayamos trabajado con Workflows de vRealize Orchestrator, entonces estamos hablando que este apartado debería ser leído, al menos, un par de veces debido a que contiene conceptos extremadamente importantes. No estamos diciendo que sea complicado, porque no lo es, pero sí que existen una cantidad importante de reglas que requieren ser comprendidas para entender las relaciones y el flujo de variables y constantes en un Workflow. Existen infinidad de Workflows, desde los simples, los medianamente complejos y los extremadamente complejos. La inmensa mayoría de los Workflows, incluyendo los más simples, requieren que aportemos algún tipo de dato o variable, ya sea un objeto, una o varias variables en formato texto, números, etc, etc. A eso le llamamos Input Parameter y durante la ejecución de un Workflow serán tratadas como variables. Con el fin de solicitar la menor cantidad de información posible creando una mejor experiencia hacia el que ejecute el Workflow, solemos predefinir ciertas variables como podría ser el número de virtual cores que tendrá una VM. Otro valor predefinido, o constante, podría ser una instancia concreta de vCenter, una carpeta de maquina virtual, la versión de Hardware virtual o incluso el tipo de direccionamiento a utilizar, como DHCP. La forma de predefinir esas constantes normalmente la gestionamos con lo que llamamos Atributos. Aunque también es posible hacer lo propio en ciertas situaciones recurriendo a los Configuration Elements, pero eso lo veremos mas adelante. Cada parámetro y atributo debe estar asociado a un tipo de dato. Veamos los tipos de datos mas utilizados:

String: Texto Number: Número Boolean: Verdadero o falso Date: Fecha y hora Array: colección de datos (ejemplo: VMs con Snapshots). Puede ser colecciones de texto, números, objetos, etc.

#VMwarePorvExperts

788

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Lista de valores en un Array de texto

Configuration element: Atributos definidos a nivel de vRO que pueden ser consultados desde múltiples Workflows. Objeto: Elementos definidos por un Plugin que comienzan por un identificador del Plugin y dos puntos. Ejemplo: AD:User / VC:VirtualMachineFolder

Lista de tipos de datos de vCenter

Al igual que un cuento, un Workflow debe tener un inicio, un desarrollo y un final (aunque no siempre sea satisfactorio). Al finalizar el Workflow por lo general vamos a entregar una variable a modo de resultado. Esa variable será de tipo número, texto, boolean o el resultado de la ejecución de una tarea. A este resultado le llamaremos Output Parameter. Veamos a continuación un esquema básico de un Workflow con dos Input Parameters, dos Atributos y un Output Parameter trabajando con un par de Workflow Elements.

#VMwarePorvExperts

789

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Ejemplo abstracto del flujo de Parámetros y Atributos en un Workflow

En la imagen anterior el flujo comienza cuando el usuario o administrador que ejecuta el Workflow debe definir tanto el Parametro 1 como el Parametro 2. A continuación se ejecuta el Workflow Element 1 tomando como Parámetros de entrada el Input Parameter 2 y el Attribute 1 cuyo valor o constante fue definido como parte del diseño del Workflow. Como resultado de la ejecución del flujo, el Workflow Element 1 define la variable del Attribute 2. Aclaración: Los Atributos pueden estar definidos como constantes o variables pero nunca serán definidos por el usuario que ejecuta el Workflow. Se definen únicamente a nivel de diseño o bien durante la ejecución del Workflow. La ejecución del Workflow continúa ahora con el Workflow Element 2 entregando como variable de entrada al elemento el Input Parameter 1 y el Attribute 2 (valor previamente definido por el Workflow Element 1). El resultado de la ejecución del flujo del Workflow Element 2 va a establecer el Output Parameter tanto del Workflow Element 2 como del propio Workflow. Más adelante veremos un ejemplo similar sobre un Workflow real pero antes debemos aclarar ciertas reglas de funcionamiento para una mejor comprensión.

Reglas de flujo de Parámetros y Atributos en un Workflow: •

Las variables de Parámetros de entrada (Input Parameters) se definen cada vez que se ejecuta el Workflow

•

Los Atributos pueden estar definidos como constantes o variables pero nunca serán definidos por el usuario que ejecuta el Workflow

•

Los valores de los Atributos únicamente se definen a nivel de diseño o bien durante la ejecución del Workflow

•

No es posible transferir variables entre Workflow Elements, es por eso que utilizamos Atributos como elementos de intercambio

•

Los valores predefinidos de Atributos se mantienen cada vez que se ejecuta un Workflow y pueden modificarse las veces que necesitemos como parte del diseño o actualización del mismo. Esto funciona como una constante.

•

Normalmente el último Workflow Element es el que define el Output Parameter

#VMwarePorvExperts

790

Capítulo 14 - vRealize Orchestrator Federico Cinalli

•

Un Output Parameter puede ser utilizado como Input Parameter en otro Workflow. Eso aplica cuando, desde un Workflow, llamamos a la ejecución de otro Workflow.

•

Es posible proteger el valor de un Atributo ante modificaciones

Vista de Atributos protegidos y sin proteger contra cambios

Diferencia entre Workflow Input Parameter y Workflow Element Input Parameter Si bien los nombres son prácticamente iguales, estamos haciendo referencia a parametros en diferentes ámbitos, aunque deberán estar vinculados entre sí. Como parte del desarrollo del Workflow vamos a vincular el o los Input Parameters del Workflow con el o los Input Parameter del Workflow Element. Partamos de la base que la gran mayoría de Workflows necesitan variables para funcionar, y ya hemos comentado que esas variables las definimos a través de los Input Parameters. Supongamos que nuestro Workflow va a crear un usuario asignándole automáticamente una contraseña.

Los datos que necesitaríamos podrían ser: Input Parameter 1: Nombre del Usuario Input Parameter 2: Complejidad de contraseña? (Si/No) Atributo 1: Contraseña

Nuestro Workflow podría tener un Workflow Element 1 que genere automáticamente la contraseña, basado en el Input Parameter 2 que define si la contraseña deberá tener caracteres especiales o no a través de una variable tipo boolean. El resultado del Workflow Element 1 definirá el valor del Atributo 1 que será la variable de la contraseña generada. El segundo Workflow Element utilizará el Input Parameter 1 (nombre de usuario) para crear el usuario y el valor del Atributo 1 para asignarle la contraseña.

#VMwarePorvExperts

791

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Esquema Parametros y Atributos

Con este ejemplo podemos ver que el Workflow pedirá todos los Input Parameters necesarios para “entregar” o, mejor todavía, “asociar” esos Input Parameters del Workflow a los Input Parameters de cada Workflow Element. A las asociaciones entre un Input Parameter del Workflow y el Input Parameter del Workflow Element, así como también las asociaciones entre un Attribute y un Input Parameter del Workflow Element les llamamos Binding. Como ejemplo podemos decir que cada flecha del esquema es un Binding. De esta forma podemos ver el Binding a un Workflow Element:

Binding de Parametros y Atributos en un Workflow Element

Importante: Aproximadamente el 80% de los errores en un Workflow tienen que ver con los bindings o asociaciones entre Input Parameters y los Atributos. Una vez que comprendamos al 100% las reglas del binding será un antes y un después en nuestra escala de aprendizaje con vRealize Orchestrator. La mejor forma de verificar visualmente los Bindings es utilizando la vista “Visual Binding” como vemos a continuación. Veamos si hay “alguna” similitud entre el último esquema y la siguiente captura:

#VMwarePorvExperts

792

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Visual Binding en el Workflow Element 1

El binding en un Workflow Element se define a nivel de cada Workflow Element de forma independiente, en las propiedades, en las pestañas IN y OUT como puede verse en la siguiente captura.

Binding entre un Input Parameter o Atributo y un Input Parameter de un Workflow Element

También es posible hacer Binding utilizando drag and drop en el Visual Binding. Importante: Recordemos que el usuario que ejecuta el Workflow únicamente definirá la variable de los Input Parameters. Cuando hacemos referencia a un usuario también podemos estar refiriéndonos al sistema que ejecute el Workflow como podría ser una instancia de vRealize Automation o un sistema externo vía REST API. Mencionamos anteriormente que un Workflow Element puede ser un Scriptable Task, un Action, un elemento For Each o incluso una llamada síncrona o asíncrona a otro Workflow. Veamos ahora cómo sería un ejemplo de un Workflow que utiliza un Output Parameter como Input Parameter.

#VMwarePorvExperts

793

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Ejemplo del Workflow Demo 1 interactuando con el Workflow Demo 2

Nota: Los Output Parameters son utilizados por vRealize Automation como respuesta a una subscripción de Event Broker y Workflows de tipo XaaS. En este segundo esquema hemos visto cómo el Workflow Demo 1, a través del Workflow Element 1, llama al Workflow Demo 2 pasándole la variable que necesita para luego recibir el resultado. En este caso el resultado o el Output Parameter del Workflow Demo 2 se utilizará como variable en el Attribute 2 del Workflow Demo1. A su vez, el valor del Attribute 2 servirá como Input Parameter para el Workflow Element 2. La buena noticia es que si somos capaces de comprender este esquema entonces eso significa que entendemos el flujo de Parámetros y Atributos. Si todavía no lo entendemos del todo entonces es un buen momento para comenzar a releer este apartado desde el principio.

Ámbito de variables de Parámetros y Atributos En los dos últimos esquemas hemos visto que, si bien algunos Atributos pueden ser predefinidos, todos los Parámetros e incluso algunos Atributos (los que son definidos durante la ejecución del Workflow) “pierden” su valor, se quedan en blanco en realidad, una vez que se ejecuta nuevamente el Workflow. O dicho en otras palabras, necesitamos introducir nuevamente los valores. Después de todo es justamente esto lo que permite la versatilidad de una orquestación.

Ejemplo de un Atributo predefinido – Complejidad Contraseña

#VMwarePorvExperts

794

Capítulo 14 - vRealize Orchestrator Federico Cinalli

¿Pero qué ocurriría si necesitamos utilizar Atributos en común en dos o más Workflows? ¿Y si necesitamos actualizar esos Atributos “externos” como parte de cada ejecución de un Workflow? Llegados a este punto podríamos tener dos situaciones diferentes. Una en que quisiéramos consultar valores predefinidos que normalmente no cambien. Y otra en que necesitamos que esos valores externos cambien. Veamos un ejemplo de cada caso para ser mas concretos.

Caso 1 – Consulta de atributos externos que no cambian Disponemos de múltiples Workflows para despliegue de VMs. Algunos utilizan Clone y otros Linked Clone. Cada Workflow utiliza una carpeta diferente en vCenter y puede dimensionar los recursos de diferente forma, incluso en diferentes clusters, pero hay ciertos valores que no cambian. Esos valores que no cambian se pueden definir en como un valor externo utilizando Configuration Elements: •

Instancia de vCenter Server

•

Versión de Hardware Virtual

•

Número de Virtual Cores por Socket

•

vSphere Tag para agregar al Backup

Caso 2 – Consulta y actualización de atributo externo que se actualiza Con el objetivo de la definición de la nomenclatura de una maquina, ya sea para el inventario o para el hostname, se utilizará un Configuration Element con un Atributo de tipo Number cuyo valor será el siguiente número disponible. Un Scriptable Task del Workflow se encargará, utilizando JavaScript, de incrementar en uno el valor del atributo una vez definido el hostname de la VM. Éste sería el caso del siguiente esquema en el cual el Atributo 1 obtiene el valor del Configuration Element y el Workflow Element 2 actualiza el valor del Atributo del Configuration Element incrementando el número en uno. De esta forma tanto si este mismo Workflow se ejecuta nuevamente o bien cualquier otro Workflow que consulte ese Atributo externo tendrá entonces el valor actualizado.

Uso de Configuration Elements como valor externo

#VMwarePorvExperts

795

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Ejemplo de Atributos de un Configuration Element

#VMwarePorvExperts

796

Capítulo 14 - vRealize Orchestrator Federico Cinalli

7. Elementos de un Workflow Los elementos de un Workflow o Workflow Elements son lo que le dan vida a nuestro flujo de trabajo. Veamos cuáles son los más utilizados y sus principales características.

Workflow Element

Icono

Descripción

Start

Cada Workflow tiene un único Inicio y se crea automáticamente junto con un elemento End.

End

Cada Workflow debe tener al menos un elemento End. Un nuevo Workflow crea un End automáticamente.

Scriptable Task

Action

Workflow Decision Switch

Log

Foreach Increase counter

Throw

Waiting Event

#VMwarePorvExperts

Es probablemente el elemento más utilizado. Es aquí donde damos funcionalidad al Workflow utilizando código con JavaScript. Las acciones son objetos predefinidos que podemos encontrar en la librería de acciones. Cumplen una única función y normalmente las asociamos a lo que sería una función en desarrollo. Tienen código JavaScript. Desde un Workflow somos capaces de llamar a otro Workflow de la librería. Las llamadas pueden ser Síncronas o Asíncronas. Existen tres tipos de elementos Decisión. Decision, Custom Decision y Decision Activity. Definen la ruta que continuará el flujo en base a ciertas variables. Este elemento continúa con un determinado elemento según una variable existente. Permite considerar múltiples caminos. Los Log elements escriben variables y/o el texto que definamos en el Log o la BBDD de vRO. Existen los Server y System para eventos de Logs, Warning y Critical. Utilizamos frecuentemente estos elementos para gestionar colecciones (arrays) de diferente tipo o para ejecutar acciones repetitivas de forma controlada. Este simple elemento añade 1 a una variable tipo Number. Se utiliza como complemento del elemento Foreach. Una parte esencial de un Workflow es el control de errores. Este tipo de elemento recibe los errores de ejecución y pueden distribuirse en múltiples elementos del flujo de trabajo. Algunos elementos del Workflow requieren esperar un determinado evento para poder continuar con el siguiente elemento.

797

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Waiting Date Sleep User interaction

#VMwarePorvExperts

Otros elementos o flujos deben esperar hasta una fecha y hora determinada para continuar con su ejecución y pasar al siguiente elemento. Utilizamos este elemento para pausar el Workflow por una cantidad determinada de segundos según necesitemos. En ciertos flujos es necesaria la intervención del usuario para continuar de una forma u otra con el siguiente elemento.

798

Capítulo 14 - vRealize Orchestrator Federico Cinalli

8. Trabajando con un Workflow Llegados a este punto vamos a cerrar el capítulo trabajando con un Workflow para poner en práctica todo lo aprendido hasta ahora.

Utilizando Linked Clone sin la suite Horizon Linked Clone es una tecnología que nos permite hacer un clon de una máquina virtual, pero utilizando un Snapshot como disco base. Esto hace que cada VM única comience utilizando un disco Delta de unos 20MB que irá creciendo a medida que sea diferente de la maquina Parent, ya sea por instalación de Software, Documentos, Actualizaciones, etc. Con Linked Clone seremos capaces de crear VMs en cuestión de segundos y utilizando una mínima parte del espacio que normalmente utilizamos. Vale aclarar que este tipo de clonados no es lo mas apto para servidores en Producción que requieran un alto rendimiento. Lo interesante de esto es que Linked Clone está disponible en la Suite Horizon y también como modo de despliegue en vRealize Automation pero, por alguna razón, no está disponible en vSphere Client o Web Client de vSphere. Las tres formas que tenemos de utilizar Linked Clone en vSphere (sin Horizon ni vRA) es utilizando las API de vCenter, PowerCLI y vRealize Orchestrator. En este caso no desarrollaremos ningún Workflow nuevo, sino que modificaremos uno preexistente para simplificar su uso. En la librería de Workflows, vCenter, Virtual Machine management, Clone, Linked Clone disponemos del Workflow “Linked clone, no customization”.

Workflow para despliegues con Linked Clone

No es posible modificar un Workflow que viene por defecto en la librería, pero sí que es posible crear una copia (opción Duplicate) y modificar esa copia a nuestro antojo.

#VMwarePorvExperts

799

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Lo que haremos en este caso es llevar al mínimo los Input Parameters convirtiéndolos en Atributos con valores predefinidos. Una vez duplicado el Workflow original (botón derecho sobre el Workflow y opción Duplicate Workflow) seleccionaremos el Workflow duplicado y lo editaremos presionando Ctrl+E. Mientras estamos editando el Workflow, en la pestaña General, podremos cambiar el nombre del mismo.

Cambiando el nombre a un Workflow

En la vista Inputs veremos todos los Input Parameters según se aprecia en la siguiente captura:

Listado de Input Parameters

Y si ejecutamos el Workflow deberemos completar cada uno de los Input Parameters. Con el fin de simplificar la tarea vamos a convertir (o mover) la mayoría de los Input Parameters en Atributos y, una vez convertidos, les definiremos un valor. ¿Cómo podemos convertir un Input Parameter en un Atributo? En la misma vista de Input Parameters seleccionamos uno o varios Parametros y con botón derecho hacemos click en “Move as attribute”.

#VMwarePorvExperts

800

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Moviendo Parametros a Atributos

Una vez movidos los Parametros ya los veremos como Atributos y podremos proceder a asignar valores predefinidos para llevar al mínimo el número de Input Parameters que debemos definir al ejecutar el Workflow.

Atributos seleccionados que tendremos que predefinir su valor

#VMwarePorvExperts

801

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Atributos con valores predefinidos

¡¡¡Ahora ya estamos listos para probar el Workflow!!! Al ejecutar el Workflow únicamente tendremos que especificar el nombre de la VM.

Definiendo el único Input Parameter

Al cabo de escasos segundos podremos verificar en las tareas de vCenter que una tarea de Clonado ha finalizado. En mi caso demoró 1 segundo.

Tarea de clonado de VM con Linked Clone en 1 segundo

#VMwarePorvExperts

802

Capítulo 14 - vRealize Orchestrator Federico Cinalli

Vista de la nueva VM desplegada con Linked Clone desde vRO

#VMwarePorvExperts

803

Capítulo 14 - vRealize Orchestrator Federico Cinalli

9. Resumen y recomendaciones Este capítulo fue simplemente un resumen del potencial que puede ofrecer vRealize Orchestrator. Naturalmente que el producto da para muchísimo mas que un simple capítulo en un libro, pero al menos disponemos de una buena introducción en nuestro idioma materno. El Workflow de Linked Clone que modificamos fue solo un ejemplo de cómo reutilizar la librería de la que disponemos con más de 300 Workflows listos para utilizar ni bien terminamos de desplegar nuestro vRealize Orchestrator. No olvidemos que existen recursos fantásticos como VMware Code y VMware Solutions Exchange de los que podemos descargar tanto Plugins como Workflows. No obstante, el mejor recurso con diferencia para vRealize Orchestrator son las communities. Es cierto que están disponibles únicamente en ingles pero la cantidad y calidad de recursos que podemos encontrar allí es asombroso. Un gran recurso para aprender simplemente leyendo las diferentes consultas. Tal vez nos estemos preguntando hasta qué punto necesitamos saber de JavaScript para trabajar con vRealize Orchestrator. Todo depende de qué tan complejos serán nuestros Workflows. Muchas veces descubriremos que la tarea que queremos orquestar ya está cubierta por un Workflow de la librería. Habrá otras situaciones en que deberemos invertir nuestro bien mas valioso, que no es ni más ni menos que nuestro tiempo, para aprender cómo resolver algo en particular. Existirán muchas situaciones en que no tendremos mas opción que invitarle un par de cervezas a nuestro amigo desarrollador. Un recurso muy interesante es utilizar Powershell/PowerCLI a través de vRO. Ese recurso se convierte en un comodín muy versátil especialmente cuando JavaScript no es nuestro fuerte. En ese caso no nos podemos perder el proyecto ONYX. Podemos encontrarlo en VMware Flings y nos permite utilizarlo cual grabadora de macros de Excel. Simplemente tenemos que poner ONYX a grabar y ejecutar una o mas acciones en vSphere Web Client. Al detener la grabación nuestro amigo ONYX nos mostrará el código de Powershell en .NET de todas las tareas que ejecutamos durante la grabación. ¿Muy interesante verdad? Y, por último, y no menos importante, necesitamos recordar que todo depende de nosotros. La herramienta está ahí esperándonos para hacer Workflows increíbles.

#VMwarePorvExperts

804

Capítulo 14 - vRealize Orchestrator Federico Cinalli

#VMwarePorvExperts

805

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

806

Capítulo 15 PowerCLI

Miquel Mariano

#VMwarePorvExperts

807

Capítulo 15 - PowerCLI Miquel Mariano

PowerCLI 1. Introducción Como muchos ya sabréis, PowerCLI es otra interfaz de acceso a nuestra plataforma vSphere. Es normal que cualquier administrador de infraestructura virtual esté muy familiarizado con las interfaces GUI como pueden ser el “vSphere Client” o el “ESXi embeded host client” y no es tan habitual el uso de PowerCLI. PowerCLI no es más que un lenguaje de scripting basado en Windows PowerShell que a través de una serie de módulos (cmdlets) proporcionados por VMware nos permite interactuar con nuestra infraestructura vSphere.

Imagen proporcionada por VMware

Para mi PowerCLI es una herramienta tremendamente potente que me sirve para desarrollar múltiples operaciones, desde tareas de administración del propio entorno, tareas de operación con máquinas virtuales o incluso monitorización y reporting del estado de salud de los entornos que administramos. En este capítulo veremos cómo hacer la instalación de la última versión, la 10, y aprenderemos los comandos básicos para poder conectarnos a nuestro entorno y extraer información.

#VMwarePorvExperts

808

Capítulo 15 - PowerCLI Miquel Mariano

2. Instalación PowerCLI La primera tarea será asegurarnos de que tenemos PowerShell instalado en nuestro equipo. En las versiones Windows 7 o superior, el componente viene nativamente instalado pero también os quiero recordar que desde hace poco más de un año, al ser liberada la versión 6.0 de PowerShell, también podremos instalarlo sobre Linux y MacOS. Os dejo el anuncio en el blog oficial Microsoft: https://blogs.msdn.microsoft.com/powershell/2018/01/10/powershell-core-6-0-generally-available-gaand-supported La segunda tarea, será decidir que versión instalar. En fecha de edición de este libro, la última versión estable es la 11.1.0 y tendremos que comprobar en la guía de compatibilidad, la que sea compatible con nuestra versión vSphere.

Imagen proporcionada por VMware

Hasta la versión 6.5 de PowerCLI, la instalación era a través de un instalador que nos podíamos descargar del portal https://my.vmware.com y que tenía un asistente del típico next>next>next>finish pero fue a partir de la versión 6.5.1 y la llegada de PowerShell 6.0 que todo cambió. A partir de aquí la instalación de PowerCLI 6.5.1 y superior se realizará a través de PowerShell y su gestor de módulos. Básicamente son 2 pasos. Nos descargamos los módulos en una ubicación local: Save-Module -Name VMware.PowerCLI -Path

#VMwarePorvExperts

809

Capítulo 15 - PowerCLI Miquel Mariano

Instalamos los módulos con el comando siguiente: Install-Module -Name VMware.PowerCLI

Podréis encontrar una guía paso a paso de cómo instalar la última versión de PowerCLI sobre Windows en el siguiente post: https://miquelmariano.github.io/2019/01/instalar-powerCLI-10-windows

#VMwarePorvExperts

810

Capítulo 15 - PowerCLI Miquel Mariano

3. Cambiar la política de ejecución predeterminada Una vez tengamos instalada la herramienta, podremos utilizar PowerCLI directamente desde una consola de PowerShell 6. La primera vez que utilicemos PowerCLI es posible que recibamos un mensaje de que la política de ejecución de scripts está configurada en modo restringido.

En este punto, es importante tener clara la política de seguridad de nuestra empresa. La política de ejecución que configuremos en PowerShell, no debería estar en conflicto con las directrices propias de seguridad de la empresa.

Para cambiar la política de ejecución de código a un estado que nos permita ejecutar scripts, será necesario ejecutar PowerShell cómo administrador y posteriormente el siguiente comando: PS C:\Users\miquel.mariano> Set-ExecutionPolicy RemoteSigned

Este comando, nos configurará PowerCLI para poder ejecutar scripts locales sin ningún tipo de verificación. Sólo comprobará los scripts descargados de Internet que estén firmados por una entidad de confianza. Los posibles métodos de ejecución los podréis ver a continuación: •

Restricted - La política de ejecución predeterminada. Permite comandos individuales, pero no ejecutar scripts.

•

AllSigned - Requiere que todos los scripts y archivos de configuración estén firmados por un editor de confianza, incluidos los scripts que hemos escrito localmente.

•

RemoteSigned - Requiere una firma digital de un editor de confianza en los scripts y archivos de configuración que se descargan de Internet. Sólo se podrán ejecutar scripts locales.

•

Unrestricted - Se pueden ejecutar scripts sin firmar. Existe el riesgo de ejecutar scripts maliciosos.

•

Bypass – No hay ningún tipo de control ni bloqueo. Tampoco hay advertencias ni avisos.

•

Undefined - No hay una política de ejecución establecida por lo que se aplicará la predeterminada, por lo tanto Restricted.

#VMwarePorvExperts

811

Capítulo 15 - PowerCLI Miquel Mariano

4. Conexión a nuestro entorno vSphere Con PowerCLI, al ser un cliente más del ecosistema vSphere tendremos la posibilidad de conectarnos tanto a un servidor vCenter como directamente a nuestros hosts ESXi. Para establecer una conexión, usaremos el cmdlet connect-viserver: connect-viserver -user -password

A continuación vemos como se ha establecido correctamente una conexión con nuestro vCenter y a la vez con un host ESXi: PS C:\Users\miquel.mariano> connect-viserver vcenter.vmwareporvexperts.org -user miquel. mariano -password Secret123! Name ---vcenter.vmwareporvexperts.org

Port ---443

User ---VMWAREPORVEXPERTS\miquel.mariano

PS C:\Users\miquel.mariano> connect-viserver esxi01.vmwareporvexperts.org -user root -password Secret123! Name ---esxi01.vmwareporvexperts.org

Port ---443

User ---root

Para verificar las conexiones que tenemos activas, nos podremos servir de la variable $global:DefaultVIServers: PS C:\Users\miquel.mariano> $global:DefaultVIServers Name ---esxi01.vmwareporvexperts.org vcenter.vmwareporvexperts.org

Port ---443 443

User ---root VMWAREPORVEXPERTS\miquel.mariano

Ahora que ya tenemos establecidas las conexiones, podremos empezar a ejecutar comandos sobre ellas. Si trabajáis con múltiples conexiones, como es el caso en este ejemplo, utilizaremos el flag -server para referirnos a una conexión u otra:

#VMwarePorvExperts

812

Capítulo 15 - PowerCLI Miquel Mariano

PS C:\Users\miquel.mariano> Get-VMHost -server vcenter.vmwareporvexperts.org Name ConnectionState PowerState MemoryUsageGB MemoryTotalGB Version ------------------ ---------- ------------------------- ------esxi01 Connected PoweredOn 3,116 5,999 6.7.0 esxi02 Connected PoweredOn 3,119 5,999 6.7.0 esxi03 Connected PoweredOn 3,127 5,999 6.7.0 esxi04 Connected PoweredOn 3,122 5,999 6.7.0 esxi05 Connected PoweredOn 3,120 5,999 6.7.0 formacionesxi03.n... Connected PoweredOn 54,352 127,889 6.5.0 formacionesxi04.n... Connected PoweredOn 69,791 127,889 6.5.0 formacionesxi01.n... Connected PoweredOn 2,497 127,889 6.7.0 formacionesxi02.n... Connected PoweredOn 20,548 127,889 6.7.0

NumCpu CpuUsageMhz CpuTotalMhz ----------- -----------

-----

2

228

4198

2

202

4198

2

246

4198

2

243

4198

2

209

4198

16

7649

33584

16

1564

33584

16

35

33584

16

2439

33584

PS C:\Users\miquel.mariano> Get-VMHost -server esxi01.vmwareporvexperts.org Name ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz MemoryUsageGB MemoryTotalGB Version ------------------ ---------- ------ ----------- ---------------------------------- ------esxi01.vmwareporv... Connected PoweredOn 2 207 4198 3,116 5,999 6.7.0

Para realizar la desconexión de nuestros servidores, utilizaremos el comando Disconnect-vIServer: PS C:\Users\miquel.mariano> Disconnect-vIServer -Server * -force Confirm Are you sure you want to perform this action? Performing the operation “Disconnect VIServer” on target “User: VMWAREPORVEXPERTS\ miquel.mariano, Server: vcenter.vmwareporvexperts.org, Port: 443”. [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): A

#VMwarePorvExperts

813

Capítulo 15 - PowerCLI Miquel Mariano

5. Empecemos con lo básico, comando get-help Antes de empezar a trabajar con PowerCLI es interesante entender los comandos disponibles y cómo utilizarlos. Con cada versión, VMware suele publicar un poster con todos los comandos disponibles. A continuación, encontrareis el poster de la versión 10.0 (creo que de la versión 11 todavía no ha salido). https://blogs.vmware.com/PowerCLI/files/2018/04/VMware_PowerCLI_10_FINAL.pdf

El comando get-help nos será de gran ayuda en todo momento. Lo podremos utilizar de la siguiente manera:

•

get-help Nos enseñará una descripción general del comando y su uso. PS C:\Users\miquel.mariano> Get-Help get-vm NAME

Get-VM

SYNOPSIS This cmdlet retrieves the virtual machines on a vCenter Server system. SYNTAX Get-VM [[-Name] ] [-Datastore ] [-Location ] [-NoRecursion] [-Server ] [-Tag ] [] Get-VM -Id [-Server ] [] Get-VM [[-Name] ] [-Server ] [-Tag ] [-VirtualSwitch ] [] Get-VM -RelatedObject [] DESCRIPTION This cmdlet retrieves the virtual machines on a vCenter Server system. Returns a set of virtual machines that correspond to the filter criteria provided by the cmdlet parameters. For virtual machines with multiple NICs and multiple IP addresses, the IPAddress property of the VMGuest object contains all IP addresses of the virtual machine. The IP at position 0 is the primary IP address. RELATED LINKS Online Version: https://code.vmware.com/doc/preview?id=6330#/doc/Get-VM.html Remove-VM New-VM

#VMwarePorvExperts

814

Capítulo 15 - PowerCLI Miquel Mariano

Set-VM Move-VM Start-VM Stop-VM Suspend-VM Restart-VM REMARKS To see the examples, type: “get-help Get-VM -examples”. For more information, type: “get-help Get-VM -detailed”. For technical information, type: “get-help Get-VM -full”. For online help, type: “get-help Get-VM -online”

•

get-help -examples. A veces, la forma más rápida de aprender la sintaxis de un comando es viéndolo en acción.

•

Get-help -detailed. Obtendremos información adicional sobre el comando, incluidas descripciones de parámetros y ejemplos.

•

Get-help -full. Muestra toda la ayuda disponible para un comando, incluida la información técnica sobre sus parámetros. Teniendo esto claro y con un poco de imaginación, podremos hacer casi cualquier cosa con PowerCLI.

#VMwarePorvExperts

815

Capítulo 15 - PowerCLI Miquel Mariano

6. Obtener información de un ESXi El primer comando que os quiero enseñar es el get-vmhost. Nos servirá para echar un vistazo al componente físico de la infraestructura, al propio host ESXi.

TIP: Con el flag -autosize conseguiremos ver toda la columna

Como Podemos ver, aunque hay información muy útil como uso de CPU y Memoria, versión, etc etc… hay muchos otros valores que quedan ocultos. La lista predeterminada que tiene powershell es format-table (ft) Para poder ver toda la información que devuelve el comando, podemos cambiar la salida a format-list (fl)

A continuación vamos a explorar un poco más toda la info que nos da la salida del comando getvmhost. Por ejemplo, la versión de un servidor ESXi

#VMwarePorvExperts

816

Capítulo 15 - PowerCLI Miquel Mariano

Get-VMHost | foreach-object {(Get-View $ _.ID).Config.Product}

Vamos a analizar el comando: •

Get-vmhost: Ya conocemos el propósito de este comando

•

esxi01: Sirve para posicionarnos sobre un servidor en concreto, si no ponemos nada, se recorrerá todos los ESXi de nuestra infraestructura.

•

Pipe (|): Lo utilizamos para decirle a PowerShell que utilice los resultados del comando anterior, en este caso, Get-VMhost,

•

Foreach-object: Sirve para ejecutar el siguiente comando a más de un objeto. Sería como un bucle. Quizás el comando get-vmhost devuelve más de un servidor ESX, pues con el comando foreach-object le decimos que ejecute el comando Get-View (en este ejemplo) para cada objeto devuelto por el comando anterior (get-vmhost).

•

Get-view: Devuelve los objetos que corresponden a los criterios de búsqueda especificados. El cmdlet recupera la vista de objetos especificados por sus ID o por sus objetos de inventario de vSphere.

•

$ _. ID: La parte $ del comando le indica a PowerCLI que trabaje contra el “objeto seleccionado actualmente”. Y la parte .ID corresponde a uno de los valores que si os acordais devolvía el comando get-vmhost

•

.config.product: Son sub-objetos que encontramos dentro de .ID y devuelven información de la versión del ESXi

#VMwarePorvExperts

817

Capítulo 15 - PowerCLI Miquel Mariano

7. Uso de variables en PowerCLI Como sabéis, no solo en PowerShell / PowerCLI, el uso de variables añade mucha flexibilidad a la hora de definir cualquier tarea. En PowerCLI, las variables se definen usando el símbolo dólar $ justo delante. Una variable puede ser una colección a través de $nombre_var [número] o una colección multinivel a través de $nombre_var [número].campo1. Veamos un sencillo ejemplo, dónde creamos una variable y le asignamos un valor: PS C:\> $var=23 PS C:\> PS C:\> $var 23

Otro ejemplo dónde crearemos una variable con múltiples valores: PS PS PS 51 PS

C:\> $var2=23,51,32 C:\> C:\> $var2[1] C:\>

Trabajando con PowerCLI y vSphere, la salida de un comando casi siempre tiene múltiples valores, por ejemplo:

Así que cuando metamos la salida de un comando PowerCLI en una variable, ésta será una colección multinivel.

#VMwarePorvExperts

818

Capítulo 15 - PowerCLI Miquel Mariano

Como comentábamos, para elegir ciertos valores de la colección, lo haremos de la siguiente forma:

Otra opción que tenemos disponible si queremos seleccionar varios de los valores de esta colección es usar los bucles y condicionales: $hosts=get-vmhost foreach($vmhost in $hosts | where name -notlike “form*”){ $vmhost.Name $vmhost.NumCPU $vmhost.MemoryTotalGB }

Hasta aquí parece fácil, no? Pero, qué pasa si queremos saber, por ejemplo, cuantas vCPUs tiene nuestro cluster? Para eso necesitaremos usar operadores matemáticos en nuestras variables. •

= Igual

•

+= Suma el valor y lo asigna a la variable

•

-= Resta el valor y lo asigna a la variable

•

*= Multiplica el valor y lo asigna a la variable

•

/= Divide el valor y lo asigna a la variable $hosts=get-vmhost foreach($vmhost in $hosts | where name -notlike “form*”){ $cputotal+=$vmhost.NumCPU $memoriatotal+=$vmhost.MemoryTotalGB } Write-host “En total el entorno tiene $cputotal CPUs y $memoriatotal GB de RAM”

#VMwarePorvExperts

819

Capítulo 15 - PowerCLI Miquel Mariano

TIP: Para borrar el valor de una variable, utilizaremos el comando Clear-Variable

#VMwarePorvExperts

820

Capítulo 15 - PowerCLI Miquel Mariano

8. Obtener información de VMs Acabamos de ver cómo obtener información de nuestros hosts ESXi, así que es el turno de bajar un nivel e irnos a las VMs. El comando get-vm nos permitirá obtener una lista de todas las VMs de nuestro entorno. Al igual que hemos hecho con el comando get-vmhost, con la opción ft o fl (format-table o format-list) podremos manejar la salida a nuestro antojo

Aquí podemos ver la salida detallada con “fl”

Al igual que en los ejemplos anteriores, combinándolo con get-view podremos obtener muchísima información de cada objeto.

#VMwarePorvExperts

821

Capítulo 15 - PowerCLI Miquel Mariano

#VMwarePorvExperts

822

Capítulo 15 - PowerCLI Miquel Mariano

9. Obtener detalles básicos guest Otro comando interesante a tener en cuenta y que nos da información interesante es get-vmguest. Datos como la IP que tiene esta VM, o el SO instalado o incluso la versión de las VMware Tools se podrán extraer con este comando

#VMwarePorvExperts

823

Capítulo 15 - PowerCLI Miquel Mariano

10. Filtrando con Where-object En PowerShell y por consiguiente en PowerCLI, por norma general, se suelen generar muchísimos objetos cuando realizamos una consulta. Lo hemos visto con el comando get-vmhost o get-vm que nos devuelve la lista de todos los ESXi y VMs respectivamente. En muchas ocasiones no necesitamos toda esa información y es conveniente especificar que objetos concretos queremos que nos muestre. Con el cmdlet Where-Object conseguiremos realizar filtros en nuestras búsquedas para solo mostrar o realizar acciones en los objetos que cumplan ciertos criterios. Con PowerCLI y Where-Object conseguiremos evaluar cada objeto devuelto por un comando y pasarlo a la siguiente canalización sólo si cumple con la condición especificada. Vamos a ver a continuación algunos ejemplos: Lista de VMs cuyo nombre empieza por “miquel” Get-VM | Where-Object {$_.Name -like “miquel*”} | ft -autosize

Lista de VMs que están apagadas Get-VM | Where-Object {$_.powerstate -eq “poweredoff”} | ft -autosize

#VMwarePorvExperts

824

Capítulo 15 - PowerCLI Miquel Mariano

Lista de VMs con más de 10Gb de memoria configurados Get-VM | Where-Object {$_.memorygb -gt 10 } | ft -autosize

Lista de VMs con snapshots de más de 3 dias Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays(-3)} | Select-Object VM, Name, Created

#VMwarePorvExperts

825

Capítulo 15 - PowerCLI Miquel Mariano

Aunque los operadores de comparación son unos cuantos más, a continuación os dejo los que creo que son más importantes y que está bien dominar: •

-eq igual que

•

-ne diferente que

•

-gt mayor que

•

-ge mayor o igual que

•

-lt menor que

•

-le menor o igual que

•

-like que contiene (se utiliza para buscar patrones, usado con *)

•

-notlike que no contiene

•

-match que coincida exactamente

•

-notmatch que no coincida exactamente

El resto, los podéis consultar aquí: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_ comparison_operators?view=powershell-6

#VMwarePorvExperts

826

Capítulo 15 - PowerCLI Miquel Mariano

11. Salida a txt o csv Otra de las bondades que tiene PowerShell y que evidentemente nos podemos beneficiar usando PowerCLI es la salida de los comandos hacia ficheros fuera de PowerCLI, ya sean .txt o .csv Para guardar la salida de un comando en un fichero .txt, utilizaremos la opción Out-File A continuación un ejemplo: Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays(-3)} | Select-Object VM, Name, Created | Out-File snap.txt

En cambio, para generar un fichero .csv, el comando es Export-Csv y se utiliza de la siguiente manera: Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays(-3)} | Select-Object VM, Name, Created | Export-Csv snap.csv

#VMwarePorvExperts

827

Capítulo 15 - PowerCLI Miquel Mariano

#VMwarePorvExperts

828

Capítulo 15 - PowerCLI Miquel Mariano

12. Comandos de una línea En este apartado, me gustaría compartir con vosotros una lista de comandos que podemos ejecutar sin necesidad de crear ningún script y que nos dan información muy valiosa de nuestro entorno: Lista de VMs que contienen snapshots. Filtramos por nombre de snapshot para que no nos muestre los realizados por Veeam Backup. Get-VM | Get-Snapshot | where {$_.Name -notmatch “Restore Point \w”} | Select VM,Name,Description,@{Label=”Size”;Expression={“{0:N2} GB” -f ($_.SizeGB)}},Created | FT -Autosize

Lista de VMs que tienen una ISO presentada. Get-VM | Get-CDDrive | Where-Object {$_.IsoPath -ne $null} | Select Parent,IsoPath

Desmontamos todas las ISOs presentadas a nuestras VMs. Get-VM | Get-CDDrive | where {$_.IsoPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$False

Verificamos el estado del servicio SSH en nuestros hosts ESXi. Get-VMHost | Get-VMHostService | Where { $_.Key -eq “TSM-SSH” } |select VMHost, Label, Running

Arrancar servicio SSH en nuestros hosts ESXi. Get-VMHost | Foreach {Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH”} )}

Detener servicio SSH en nuestros hosts ESXi. Get-VMHost | Foreach {stop-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH”} )}

#VMwarePorvExperts

829

Capítulo 15 - PowerCLI Miquel Mariano

Contar cuantas VMs se están ejecutando en cada host ESXi. Get-VMHost | Sort-Object Name | Select Name,@{N=”VM”;E={ if ($_.ExtensionData.Vm -ne $null) { $_.ExtensionData.Vm.Count } else {0}}}

Contar cuantas VMs se están ejecutando en cada datastore. Get-datastore | Sort-Object Name | Select Name,@{N=”VM”;E={ if ($_.ExtensionData.Vm -ne $null) { $_.ExtensionData.Vm.Count } else {0}}}

Ver estado de las VMware Tools y VirtualHW en todas nuestras VMs. Get-VM | Select @{N=”VMName”; E={$_.Name}}, @{N=”State”; E={$_.PowerState}}, @ {N=”HardwareVersion”; E={$_.Extensiondata.Config.Version}}, @{N=”ToolsVersion”; E={$_. Extensiondata.Config.Tools.ToolsVersion}}, @{N=”ToolsStatus”; E={$_.Extensiondata. Summary.Guest.ToolsStatus}}, @{N=”ToolsVersionStatus”; E={$_.Extensiondata.Summary. Guest.ToolsVersionStatus}}, @{N=”ToolsRunningStatus”; E={$_.Extensiondata.Summary. Guest.ToolsRunningStatus}} | where state -notmatch poweredoff | FT

Ver las VMs que se han creado recientemente Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq VmCreatedEvent} | Select createdTime, UserName, FullFormattedMessage

Ver las VMs que se han eliminado recientemente Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmRemovedEvent”} | Select createdTime, UserName, FullFormattedMessage

Ver los ultimos errores en el visor de eventos de vCenter Get-VIEvent -maxsamples 10000 -Type Error -Start (get-date).AddDays(-7) | Select createdTime, fullFormattedMessage

Ver las VMs que tienen el controlador de red e1000 get-vm | Get-NetworkAdapter parent,networkname,name,type

#VMwarePorvExperts

|

where

{$_.type

-match

“e1000”}

|

select-object

830

Capítulo 15 - PowerCLI Miquel Mariano

13. Script para desplegar VMs Para terminar este capítulo, me gustaría compartir con todos vosotros un script que llevo utilizando bastante tiempo y que me es muy útil a la hora de desplegar VMs, sobre todo si son varias, ya que automáticamente desplegará el nº que le indiquemos. https://github.com/vmwareporvexperts/vmwareporvexperts/tree/master/libro/capitulo-11/PowerCLI

A continuación os dejo el código, en dónde en el apartado de VARIABLES GLOBALES configuraremos todo nuestro despliegue.

#--------------VARIABLES GLOBALES---------------------$Quantity = 1 $BaseVMname = “VM-DEMO-” $PrimerVMxx = 10 #Valor autoincremental del nº de VM. VM-DEMOxx $NameTemplate_or_VM = “miquel-template-W2012R2-Std-ES” #La base para la nueva VM puede ser una plantilla o un clon de otra VM $Is_template = 0 # Valor 1 si se va a desplegar desde una plantilla o 0 si es un clon de otra VM $CustomSpec = “miquel-windows-domain-dhcp” $Cluster = “Cluster-EVC” $Datastore = “G350_FORM_NLSAS_LUN000” $VLAN = “VLAN6-Formacion” $PrimeraIP = 110 #Valor del último octeto de la IP. 10.0.0.xx Se irá autoincrementando en caso que $Quantity sea mayor a 1 $MemGB = 4 $NumCPU = 2

#VMwarePorvExperts

831

Capítulo 15 - PowerCLI Miquel Mariano

#--------------VARIABLES CUSTOM SPECIFICATIONS (los parametros deben ser validos para la VLAN que especifiquemos en la variable $VLAN)--------$net = “10.0.0.” $mask = “255.255.255.0” $gw = “10.0.0.1” $pdns = “8.8.8.8” $sdns = “4.4.4.4”

#----------BUCLE PARA DESPLEGAR N MAQUINAS------------for ($n=1;$n -le $Quantity; $n++) { $vmname = $BaseVMname+$PrimerVMxx write-host Desplegando $vmname de $quantity servers -foregroundcolor yellow $ip = $net+$PrimeraIP #asignamos una ip estatica a la customización Get-OSCustomizationSpec $CustomSpec | Get-OSCustomizationNicMapping | OSCustomizationNicMapping -IpMode UseStaticIp -IpAddress $ip -SubnetMask -DefaultGateway $gw -DNS $pdns,$sdns

Set$mask

if ($Is_template -eq 1){ New-VM -Name $vmname -OSCustomizationSpec $CustomSpec -ResourcePool $Cluster -Template $NameTemplate_or_VM -Datastore $Datastore } if ($Is_template -eq 0){ New-VM -Name $vmname -OSCustomizationSpec $CustomSpec -ResourcePool $Cluster -VM $NameTemplate_or_VM -Datastore $Datastore } Get-VM -Name $vmname | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $VLAN -Confirm:$false Get-VM -Name $vmname | Set-VM -MemoryGB $MemGB -NumCPU $NumCPU -Confirm:$false Start-VM -VM $vmname $PrimeraIP++ $PrimerVMxx++ } #configuramos la customización para que la IP sea asignada mediante asistente Get-OSCustomizationSpec $CustomSpec | Get-OSCustomizationNicMapping | SetOSCustomizationNicMapping -IpMode PromptUser -SubnetMask $mask -DefaultGateway $gw -DNS $pdns,$sdns

Para empezar con el despliegue, simplemente ejecutaremos el script sin especificar ningún parámetro y a disfrutar…

#VMwarePorvExperts

832

Capítulo 15 - PowerCLI Miquel Mariano

#VMwarePorvExperts

833

Capítulo 15 - PowerCLI Miquel Mariano

14. Notificaciones con telegram Hace ya bastante tiempo que utilizo Telegram como sistema de notificaciones. El correo electrónico está bien, pero las notificaciones instantáneas están aún mejor cuando queremos reportar una información concreta de forma rápida. Para poder integrar Telegram con nuestros script de PowerCLI, lo primero que necesitaremos es un “chat bot”. Crear uno de ellos es una tarea realmente sencilla y la red está llena de documentos paso a paso para su creación. Sin ir más lejos, os recomiendo este, que es el mejor que podréis encontrar ;-) https://miquelmariano.github.io/2017/02/notificaciones-automaticas-con-telegram Una vez tengamos el bot creado, tendremos los 2 valores clave necesarios para recibir notificaciones por telegram. El token único del bot y el chatID que identificará a que chat enviaremos notificaciones. El código PowerCLI para enviar notificaciones sólo son 4 lineas: $MyToken = “304017237:AAHpKXZBaw_wOF3H-ryhWl3F3wqIVP_Zqf8” $chatID = 6343788 $Message = “Hola Miquel, este es un mensaje enviado desde PowerCLI” $Go = Invoke-RestMethod -Uri “https://api.telegram.org/bot$($MyToken)/sendMessage?chat_ id=$($chatID)&text=$($Message)”

•

$MyToken: Es el identificador único de nuestro bot

•

$chatID: Es el ID que identifica a que chat enviará las notificaciones

•

$Message: El cuerpo del mensaje que queremos enviar

•

$Go: Lanzamos la URL contra la API de telegram para enviar el mensaje

Tanto el token como el chatID aquí expuestos son reales y totalmente funcionales, pero os recomiendo que experimenteis con vuestro propio bot ya que esta configuración enviará las notificaciones a mi cuenta

#VMwarePorvExperts

834

Capítulo 15 - PowerCLI Miquel Mariano

Ahora que ya sabemos enviar notificaciones con PowerCLI, vamos a intentar exprimir esta funcionalidad y que nos envíe información de nuestro entorno vSphere. Vamos a utilizar algunos de los comandos de una sola línea que comentamos anteriormente: La variable $Message tiene que ser contenido de texto, por lo que la salida de todos nuestros comandos tendrá que ser una cadena de texto. Esto se consige con el flag Out-String. También os recomiendo, utilizar el flag, format-list ya que al convertir el resultado en cadena de texto, las tablas pueden no verse correctamente.

#VMwarePorvExperts

835

Capítulo 15 - PowerCLI Miquel Mariano

Lista de VMs con snapshots: $MyToken = “304017237:AAHpKXZBaw_wOF3H-ryhWl3F3wqIVP_Zqf8” $chatID = 6343788 $Message = Get-VM | Get-Snapshot | where {$_.Name -notmatch “Restore Point \w”} | Select VM,Name,Description,@{Label=”Size”;Expression={“{0:N2} GB” -f ($_.SizeGB)}},Created | FL | Out-String $Go = Invoke-RestMethod -Uri https://api.telegram.org/bot$($MyToken)/sendMessage?chat_ id=$($chatID)&text=$($Message)

#VMwarePorvExperts

836

Capítulo 15 - PowerCLI Miquel Mariano

Lista de VMs que se han eliminado recientemente: $MyToken = “304017237:AAHpKXZBaw_wOF3H-ryhWl3F3wqIVP_Zqf8” $chatID = 6343788 $Message = Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmRemovedEvent”} | Select createdTime, UserName, FullFormattedMessage | FL | Out-String $Go = Invoke-RestMethod -Uri “https://api.telegram.org/bot$($MyToken)/sendMessage?chat_ id=$($chatID)&text=$($Message)”

En algunos casos, se puede dar la circunstancia de que la variable $Message sea demasiado larga para que Telegram la acepte. En este caso en vez de enviar toda la información de golpe, tendremos que hacer un bucle para que vaya enviando los resultados así como se vayan obteniendo.

Lista de VMs el estado de sus VMware Tools y virtual HW:

#VMwarePorvExperts

837

Capítulo 15 - PowerCLI Miquel Mariano

$MyToken = “304017237:AAHpKXZBaw_wOF3H-ryhWl3F3wqIVP_Zqf8” $chatID = 6343788 $Result = Get-VM | Select @{N=”VMName”; E={$_.Name}}, @{N=”State”; E={$_.PowerState}}, @{N=”HardwareVersion”; E={$_.Extensiondata.Config.Version}}, @{N=”ToolsVersion”; E={$_. Extensiondata.Config.Tools.ToolsVersion}}, @{N=”ToolsStatus”; E={$_.Extensiondata. Summary.Guest.ToolsStatus}}, @{N=”ToolsVersionStatus”; E={$_.Extensiondata.Summary. Guest.ToolsVersionStatus}}, @{N=”ToolsRunningStatus”; E={$_.Extensiondata.Summary. Guest.ToolsRunningStatus}} | where state -notmatch poweredoff foreach($output in $Result){ $Message = $output | FL | Out-String $Go = Invoke-RestMethod -Uri “https://api.telegram.org/bot$($MyToken)/sendMessage?chat_ id=$($chatID)&text=$($Message)” }

#VMwarePorvExperts

838

Capítulo 15 - PowerCLI Miquel Mariano

15. VMware hands-on-lab Estoy convencido de que muchos de vosotros ya conoceréis y estaréis familiarizados con la plataforma de laboratorios de VMware: https://labs.hol.vmware.com/HOL/catalogs/ Para todos vosotros, os recomiendo el laboratorio HOL-1911-05-SDC dónde podréis practicar y aprender muchísimas cosas sobre automatización con PowerCLI. El laboratorio está pensado para unos 90 minutos de prácticas y en el aparte de una introducción a PowerCLI se proponen muchas prácticas para automatizar configuraciones tanto de vCenter, como de ESXi así como también de máquinas virtuales.

#VMwarePorvExperts

839

Capítulo 15 - PowerCLI Miquel Mariano

16. govcsim para crear entornos de test No quería despedirme de este capítulo sin hablaros de vCenter Server Simulator (govcsim). Es un proyecto open source que simula la API de un vCenter y ESXi. Está escrito en GO y nos ofrece un entorno completamente funcional donde podremos probar nuestros scripts de PowerCLI, por ejemplo. Este simulador, nos creará un entorno que contendrá los objetos más típicos que nos podremos encontrar en un vCenter: datacenter, cluster, hosts, VMs, resource pools, redes, datastores… De esta manera, como decía, podremos probar nuestros scripts, comandos o simplemente aprender de PowerCLI sin correr el riesgo de romper nada. Aquí encontrareis toda la información relacionada con el proyecto: https://github.com/vmware/govmomi/tree/master/vcsim

En la documentación oficial están las instrucciones para instalar todo el entorno GO y hacer funcionar vcsim, pero existe un contenedor docker que nos facilitará mucho más la instalación. https://hub.docker.com/r/nimmis/vcsim

No corresponde a este capítulo hablar de docker y contenedores, pero una vez tengamos docker instalado en nuestra máquina, arrancar el simulador es tan fácil como ejecutar el siguiente comando: docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

•

docker run: Comando para ejecutar contenedores

•

–rm: Para que se elimine el contenedor una vez parado. Es opcional pero así nos aseguramos que cada vez que lo arranquemos tendremos un entorno “limpio”

•

-d: Para que el contenedor se ejecute en background, “detached”

•

-p 443:443/tcp: Mapeamos el puerto 443TCP del host de docker al contenedor.

•

nimmis/vcsim:latest: Utilizamos la última versión de la imagen nimmis/vcsim.

#VMwarePorvExperts

840

Capítulo 15 - PowerCLI Miquel Mariano

Una vez tengamos nuestro contenedor corriendo, ya podremos coger PowerCLI y lanzar la conexión:

Como veis, el usuario y contraseña por defecto del contenedor es u y p Una cosa a tener en cuenta y si os acordáis de la guía de compatibilidad, es que vcsim simula un vCenter 6.5 y PowerCLI 11 no es compatible. Por eso en la captura anterior estoy utilizando PowerCLI en versión 6.5

A continuación podéis ver los principales objetos que contiene este entorno:

A partir de aquí ya sabéis, con govcsim es posible generar un entorno de laboratorio de forma fácil para poder probar nuestros desarrollos.

#VMwarePorvExperts

841

Capítulo 15 - PowerCLI Miquel Mariano

#VMwarePorvExperts

842

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

843

Capítulo 16 vRealize Automation

Federico Cinalli

#VMwarePorvExperts

844

Capítulo 16 - vRealize Automation Federico Cinalli

vRealize Automation, la Prueba de Concepto 1. Introducción En el VMworld del año 2011 VMware presentó el término SDDC. Desde entonces el concepto de Software Defined Data Center fue globalizándose hasta lo que es hoy en día. La clave está en el Software dicen los que saben… Si comparamos un Datacenter de hoy en día con otro de tan solo 10 o 12 años atrás, aún con virtualización, podemos confirmar que conseguimos principalmente dinamismo y eficiencia. Las cargas de datos siempre van a más, tanto en tamaño como en complejidad. Eso genera la necesidad de, a la par del crecimiento, ser aún más eficientes en nuestro día a día. En cualquier Datacenter existen procesos, procedimientos, tareas y requerimientos. También marcos de Seguridad. La evolución del viaje al Cloud nos sorprendió a muchos estableciendo el entorno Híbrido como algo más que una opción. Incluso la interconexión entre diferentes Cloud Públicas está ganando terreno día a día frente al clásico Datacenter en la Empresa. Esa combinación de Clouds Privadas y Públicas requiere todavía más esfuerzos en la curva de aprendizaje para que seamos capaces de cumplir con los aprovisionamientos, procedimientos y seguridad a la vez que maximizamos las inversiones en recursos. vRealize Automation es una solución Multi-Tenant, Multi-Cloud y Multi-Plataforma que permite no solo el despliegue de cualquier tipo de máquina virtual en diferentes ámbitos, sino que además ofrece la gestión de todo el ciclo de vida de esas máquinas. Como si fuera poco vRA también permite ofrecer lo que conocemos como XaaS, lo que sea como servicio, permitiendo extender de forma exponencial las posibilidades de automatización a través de un único portal de autoservicio, con independencia de las plataformas que estemos gestionando.

¿Qué podemos esperar de este capítulo? vRealize Automation es un producto con un potencial enorme que requiere mucho detalle y desarrollo. La idea de este capítulo del libro es compartir una introducción al producto, con el objetivo que se pueda comprender gran parte del potencial y los principales componentes y dependencias, fundamentalmente orientado a una POC o Prueba de Concepto. Para una mejor comprensión de este capítulo se recomienda tener conocimientos de NSX y vRealize Orchestrator, o bien haber leído previamente los correspondientes capítulos de este mismo libro. Todo el material expuesto está basado en la versión 7.5 de vRA.

#VMwarePorvExperts

845

Capítulo 16 - vRealize Automation Federico Cinalli

2. Casos de Uso Los casos de uso principales están orientados principalmente a organizaciones dinámicas en cuanto a consumo de recursos, pero con múltiples reglas y procedimientos que cumplir ya sea a nivel operativo como también seguridad. Si bien estas organizaciones pueden disponer de múltiples centros de datos, la propia evolución de la tecnología las hace interactuar con mayor frecuencia con soluciones Cloud de proveedores Públicos. La necesidad de un mayor control, una fluida integración de las diferentes áreas de TI sumado a la búsqueda de la simplificación de las operaciones, aunque alineadas con los sistemas de IT Service Management (ITSM) hace que una solución como vRealize Automation sea recibida con los brazos abiertos por la dirección de la organización. Existen infinidad de casos de uso para vRealize Automation. Ante todo, debemos comprender que el alcance de vRA no es solo una plataforma SDDC de VMware. A través del socio de vRA, vRealize Orchestrator, seremos capaces de integrar, complementar, orquestar y automatizar todo tipo de despliegues, configuraciones y servicios en un entorno Multi-Tenant, con soluciones Multi-Cloud y tecnologías Multi-plataforma. Veamos a continuación algunos de los casos de uso más comunes.

Despliegue de Máquinas El primer caso de uso natural de vRealize Automation es la automatización de máquinas virtuales en uno o varios Datacenters con plataforma vSphere. Esos despliegues se personalizarán de tal forma que las maquinas Windows formen parte del dominio de Active Directory, utilizando la correspondiente OU, asociando el segmento de red correspondiente según la petición y agregando la VM tanto al IPAM como al CMDB que estemos utilizando en la organización.

Multiples opciones de personalización

Es posible adaptar los despliegues con pequeñas modificaciones como agregar al usuario que hizo la petición en el catálogo como miembro del grupo administradores local de la VM o aplicar cambios en el sistema operativo según requiera la maquetación.

#VMwarePorvExperts

846

Capítulo 16 - vRealize Automation Federico Cinalli

Gestión de Software vRealize Automation no es una solución de gestión de software. No obstante, sí que es posible preparar la infraestructura necesaria para un cluster de aplicaciones como puede ser la red de heartbeat, servicios de balanceador, almacenamiento y hasta reglas de afinidad y anti-afinidad. De forma complementaria a los Blueprints, seremos capaces de crear nuestra propia librería de Software en la cual, a través de scripts de bash, cmd y/o powershell automatizaremos la instalación, inicio, actualización y desinstalación de componentes de Software en nuestras VMs y contenedores.

Librería de Software en vRA

Si bien esta opción aporta una granularidad y funcionalidad considerable, debemos tener claro que vRA no gestiona un inventario de Software ni mucho menos un sistema de control de versiones o licencias de toda la organización. Esto no quita a que vRA sea la herramienta que canalice los cambios a través de soluciones como Satellite para Linux y System Center para Windows.

Integraciones con Cloud Publica No hay lugar a ninguna duda que éste es el camino y la evolución natural. Hoy en día hablamos de Clouds Híbridas y soluciones de Cloud Públicas complementarias entre sí. vRealize Automation nos aporta la capacidad de interactuar tanto con soluciones de Cloud Privada y Pública de VMware así como también soluciones de Cloud Publica de Azure, Amazon AWS y Google Cloud. Eso sin olvidar el comodín de vRealize Orchestrator para interactuar vía API con cualquier sistema que presente su REST API.

#VMwarePorvExperts

847

Capítulo 16 - vRealize Automation Federico Cinalli

Personalización de EC2 Machine en vRA

Ya sea un nuevo VPC o un repositorio S3 en AWS, o bien una instancia de VM en Azure podrán ser desplegados y gestionados a través de vRealize Automation como un punto único de control y gestión.

Extensibilidad Probablemente sea de lo más interesante que podamos aportar a la organización a través de vRealize Automation. Es aquí donde los proyectos marcan la diferencia entre lo estándar y lo que comúnmente se llama “valor agregado”. La extensibilidad la podemos aportar a la hora de entregar nuevas peticiones como también en lo que llamamos gestión del día 2 a través de Resource Actions o bien como parte de las subscripciones de Event Broker. Ya sea una opción de Backup como servicio en el catálogo, la instalación de un componente de Software o bien la automatización del procedimiento de baja de una VM. Este último ejemplo se identifica claramente con la filosofía de uso de vRealize Automation. Como parte de los procedimientos de la organización, al dar de baja una maquina Windows, debemos ejecutar tareas como remover la VM del Dominio, liberar la IP en el IPAM, cambiar el estado del ítem en la CMDB y hasta posiblemente liberar el costo en vRealize Business.

Sistema de aprobaciones y control de costo Para cada nueva petición en el catálogo de vRA es posible definir unos criterios que exijan la necesidad de aprobación para la petición. Ya sea en base al usuario, a la cantidad de recursos solicitada o directamente al servicio requerido. De forma adicional es posible asignar un coste a cada recurso entregado a través de vRealize Automation con la integración de vRealize Business. Estas dos simples características son puntos fuertes a la hora de negociar con nuestros amigos del departamento financiero.

Seguridad por defecto y como servicio La integración de vRealize Automation con NSX-V y NSX-T es la exquisitez en su máxima expresión. El hecho de definir Blueprints y alinear las configuraciones con la seguridad pre-definida en NSX es un gol desde 45 metros. No solamente la posibilidad de automatizar instancias de NSX EDGE con servicios de Firewall, NAT, VPN y Balanceadores es más que interesante, sino que además vamos a poder hacer uso de la micro segmentación pre-definida por los especialistas de seguridad en NSX. Esa asignación de seguridad la podemos aplicar simplemente asignando una etiqueta en los objetos VM del Blueprint.

#VMwarePorvExperts

848

Capítulo 16 - vRealize Automation Federico Cinalli

Consumo de recursos Y como si todo esto fuera poco debemos también hacer referencia a las formas de consumir estas automatizaciones y recursos. La forma más conocida de uso de vRealize Automation es a través de su entorno gráfico, pero la herramienta aporta opciones muy versátiles como el uso de CMD y API. Tareas como importar o exportar Blueprints, solicitar recursos del catálogo o bien ejecutar acciones en ítems gestionados a través de línea de comandos y/o API nos abren un abanico de posibilidades que cubrirán todas las necesidades de interacción y gestión.

#VMwarePorvExperts

849

Capítulo 16 - vRealize Automation Federico Cinalli

3. Componentes Los componentes en una implementación de vRealize Automation son los mismos tanto para una prueba de concepto como para producción. Evidentemente en entornos en producción cambian los recursos de cómputo asignados, números de instancias y distribución de los diferentes elementos que dan servicio al sistema. Cada implementación de vRealize Automation requiere su diseño y dimensionamiento lo cual va a determinar el número de instancias de Appliances, el número de servidores Windows con diferentes componentes y elementos externos como la base de datos SQL y el Balanceador Web.

Componentes de vRealize Automation vRealize Automation Appliance: Como su nombre lo indica es un Appliance Virtual que descargamos en formato OVA. Funcionalidades incluidas en el Appliance de vRA: •

vRealize Automation (Servicio principal)

•

Identity Manager (LDAP Server)

•

Base de Datos (PostgreSQL)

•

vRealize Orchestrator (Orquestador embebido)

Componentes del Appliance de vRA

Recursos por defecto: 4 vCPU / 18GB de RAM / 140GB de Disco La escalabilidad del Appliance de vRA se consigue ampliando los recursos de cómputo en cada Appliance o bien desplegando instancias adicionales del mismo. No es posible seleccionar los componentes internos a instalar, es decir que en cada despliegue del vRA Appliance tendremos siempre los 4 componentes. Lo que sí es posible es utilizar un Host o Cluster de vRealize Orchestrator como Orquestador externo liberando de esta forma el consumo de recursos de los Workflows de vRO.

#VMwarePorvExperts

850

Capítulo 16 - vRealize Automation Federico Cinalli

Servidor IaaS: Servidor Windows con servicios de Core complementarios al Appliance de vRA. Funcionalidades incluidas en el servidor IaaS**: •

Web site (IIS)

•

Manager

•

DEM Orchestrator*

•

DEM Worker

•

Proxy Agent

Componentes del IaaS Server

Recursos por defecto con todos los componentes: 4 vCPU / 8GB de RAM / 40GB de Disco *El DEM Orchestrator es un elemento totalmente diferente a vRealize Orchestrator. **El servidor IaaS requiere, además, una base de datos SQL Server. Para escalar los servicios de IaaS podemos implementar nuevas instancias de Windows server distribuyendo los diferentes componentes (Web, Manager, Agent y DEMs) con los objetivos de proveer tanto alta disponibilidad como mayor cantidad de recursos. Base de Datos IaaS: Servidor Windows con una base de datos o instancia SQL Server. Recursos por defecto: 2 vCPU / 8 GB de RAM / 40GB de Disco En pruebas de concepto este servicio de Base de Datos puede estar desplegado en el mismo servidor IaaS, aunque en producción se debería utilizar una instancia externa de SQL Server en alta disponibilidad.

Componentes externos o complementarios a vRA El Appliance de vRA, el servidor IaaS y la Base de Datos SQL son los elementos mínimos que necesitamos para poner en marcha vRealize Automation, al menos para una prueba de concepto. Cuando se trata de escalar la solución, proveer resiliencia e incrementar las funcionalidades, vamos a necesitar de determinados elementos externos que describiremos a continuación.

#VMwarePorvExperts

851

Capítulo 16 - vRealize Automation Federico Cinalli

vRealize Orchestrator como elemento externo Como se explicó anteriormente, el Appliance de vRA incluye por defecto una instancia de vRealize Orchestrator. En diseños que requieran atender una demanda considerable de Workflows de vRO así como también en entornos Multi-Site se suele desplegar una o dos instancias externas de vRealize Orchestrator. Esto requerirá la implementación de uno o dos Appliances de vRealize Orchestrator (2 en modo Cluster) reduciendo el consumo de recursos en el Appliance de vRA por parte de los Workflows de vRO.

vRO como elemento externo de vRA

vRealize Orchestrator versión 7.4 introdujo la funcionalidad de Multi-Tenancy que permite definir un aislamiento de instancias basadas en la autenticación de vRA Identity Manager y de esa forma incrementar la seguridad de elementos como Workflows, Acciones, Resource elements y otros.

El Cluster de SQL Server El servidor IaaS necesita una base de datos SQL Server. En entornos de producción se requiere aprovisionar tanto la propia Base de Datos como también la protección de la misma ante fallos para que ésta no se convierta en un punto único de fallo de toda la implementación de vRA. vRA soporta SQL Server 2016 en AlwaysOn y en versiones anteriores de SQL la alta disponibilidad requiere la implementación de un SQL Server en Failover Cluster.

#VMwarePorvExperts

852

Capítulo 16 - vRealize Automation Federico Cinalli

Balanceador Web Como Balanceador podemos utilizar mismamente NSX EDGE (normalmente en HA), F5 o Citrix Netscaler.

Directorio Activo Los servicios de un Active Directory de Microsoft no son obligatorios en una implementación de vRealize Automation. No obstante, en el mundo real siempre integramos AD con Identity Manager de vRA como fuente de autenticación. Eso nos permitirá simplificar el procedimiento de autenticación a los usuarios con la misma cuenta que utilizan en sus equipos a la vez que hacemos nesting con los grupos de IT para la delegación de roles en vRA.

vRealize Business for Cloud vRealize Business o vRB es una solución de control de costos que forma parte de la suite vRealize. Es posible incrementar las funcionalidades de vRealize Automation integrando vRA con vRB o bien desplegar vRealize Business únicamente. Lo curioso del caso es que, si únicamente queremos desplegar vRB, por más que no vayamos a utilizar vRealize Automation, vamos a necesitar instalar una instancia de vRealize Automation como soporte y requerimiento para vRealize Business.

Host de Powershell Una máquina virtual Windows con Powershell integrada con vRO nos permitirá utilizar el “comodín” de Powershell más PowerCLI. El appliance de vRealize Orchestrator no puede ejecutar comandos y/o scripts de Powershell por sí mismo y es por eso que necesitamos integrar vRO con un host de Powershell. Si bien esto no es un requerimiento para la implementación de vRA podemos considerar esta extensión de Powershell como algo prácticamente obligatorio ya que nos dará muchísimo juego en los Blueprint de tipo XaaS así como en las subscripciones de Event Broker.

Prueba de Concepto de vRealize Automation Para un POC de vRA normalmente utilizamos el mínimo de componentes aunque eso no impacta en absoluto en la posibilidad de utilizar el 100% de las funcionalidades del producto con fines de prueba.

#VMwarePorvExperts

853

Capítulo 16 - vRealize Automation Federico Cinalli

Esquema de una instalación mínima de vRA

Un excelente punto de partida para el diseño y dimensionamiento de vRealize Automation en Producción es el documento “VMware vRealize Automation 7x Reference Architecture” en el que podemos ver 3 diseños y dimensionamientos diferentes con bastante detalle.

Documento de Arquitectura de Referencia para vRA 7.5

#VMwarePorvExperts

854

Capítulo 16 - vRealize Automation Federico Cinalli

4 - Implementación de vRealize Automation Introducción Con independencia de si vamos a desplegar una POC o un vRA en Producción, las fases serán las mismas, aunque con mayor o menor número de componentes. Una solución de vRealize Automation en Producción y alta disponibilidad requiere de varios elementos externos lo que supone un mayor tiempo requerido para la puesta en marcha. A continuación, vamos a detallar las diferentes fases y configuraciones requeridas a modo de introducción de los diferentes elementos que componen esta increíble solución que es vRealize Automation. •

Fase 0: El Diseño

•

Fase 1: La Instalación

•

Fase 2: La Configuración

•

Fase 3: El Contenido

•

Fase 4: Las Operaciones del Día 2

La fase de Diseño define los casos de uso y los requerimientos generales del proyecto. La Instalación es cuando instalamos los componentes necesarios como el Appliance, Iaas, balanceadores, registros DNS, etc. En la Configuración integramos todos los elementos como los endpoints, autenticación, orquestador, roles, tenants y varios elementos más. Una vez finalizada la fase de Configuración ya podemos comenzar a crear Contenido en el catálogo de vRealize Automation a través de los blueprints y su posterior gestión a través de las operaciones del día 2.

El Diseño Todo buen diseño debe comenzar con su detalle de Requerimientos, Supuestos, Riesgos y Límites. Veamos una descripción de cada uno y lo que supone una decisión de Diseño. Requerimientos: Probablemente la definición más importante del proyecto. Es aquí en donde se definen los objetivos principales como el alcance, alta disponibilidad, escalabilidad, alineación con casos de uso y su correcta integración con la infraestructura de la organización. Los requerimientos siempre están más enfocados al negocio que a la parte técnica. Supuestos: La lista de supuestos incluye todos los elementos del proyecto que son necesarios para su correcta ejecución como credenciales, servicios, certificados, licencias, recursos y demás. A la hora de comenzar con el proyecto, la lista de supuestos debe estar vacía ya que se tiene que haber confirmado la disponibilidad de la totalidad de las dependencias. Límites: Esta lista muchas veces está compuesta por malas noticias como que no hay presupuesto

#VMwarePorvExperts

855

Capítulo 16 - vRealize Automation Federico Cinalli

disponible para aprovisionar alta disponibilidad, o que la licencia del producto adquirida con antelación no incluye una cierta funcionalidad o simplemente define que debemos cernirnos al software-hardware existente en la organización. El desafío es sortear los Límites cumpliendo los Requerimientos. Riesgos: Por último los riesgos deben estar perfectamente definidos ya que es una forma de poner por escrito al conocimiento previo de cada uno de los riesgos. Entre los riesgos está la no disponibilidad de un centro de datos alternativo (producto de un límite en el presupuesto) o el uso de una base de datos sin redundancia, como simples ejemplos. Aquí deberán estar listados todos los elementos que puedan comprometer la continuidad del servicio de una u otra forma. Los riesgos pueden ser asumidos o bien contar con una salvaguarda correctamente detallada.

TIP: De forma adicional a los elementos definidos anteriormente debe estar muy claro el alcance del

proyecto. Evitar falsas expectativas o bien malos entendidos es el objetivo de este ítem.

Algo tan simple como el número de Datacenters, Endpoints, métodos de autenticación, soporte, número y detalle de los flujos de trabajo (Workflows) es fundamental para el éxito del proyecto por más que se trate de una prueba de concepto o un entorno en producción.

Decisiones de Diseño Una vez definidos los Requerimientos, Supuestos, Límites y Riesgos es hora de comenzar con los diseños de los esquemas Conceptual, Lógico y Físico. El Diseño estará compuesto por múltiples decisiones de diseño con su correspondiente justificación, descripción de impacto y asociación al o los requerimientos relacionados.

Una vez definido el Diseño ya estaremos listos para comenzar con la instalación del producto. Al tratarse de un sistema que requiere innumerables interacciones debemos tener muy en cuenta la existencia de los pre-requisitos como registros DNS’s, licencias de producto, certificados digitales, balanceadores, direcciones IP’s, segmentos de red, claves de producto, recursos de computo, reglas de firewall, sistemas de autenticación y las credenciales necesarias para todas estas interacciones.

Para una correcta implementación y un buen manejo de los tiempos durante el proyecto debemos asegurarnos de disponer del 100% de los pre-requisitos y dependencias antes de comenzar con la implementación. Es necesario además considerar que la mayoría de las compañías que implementan vRA deben requerir información, autenticación y configuraciones a otras áreas. Estas peticiones crean dependencias, las cuales generan retrasos en algunos casos inesperados.

La Instalación de vRealize Automation La instalación de un sistema como vRealize Automation está compuesta por varios componentes y múltiples dependencias o complementos. Este capítulo del libro está enfocado a una POC (Prueba de Concepto) de vRealize Automation por lo que tomaremos como ejemplo una instalación simple de vRA utilizando el mínimo de componentes. A continuación, repasaremos los componentes a utilizar y sus funcionalidades.

#VMwarePorvExperts

856

Capítulo 16 - vRealize Automation Federico Cinalli

Appliance de vRealize Automation: 1 maquina en modalidad virtual appliance con plataforma Linux que descargaremos en formato OVA. Este appliance dará servicio al core de vRA, el sistema de autenticación, el orquestador embebido (vRO) y la base de datos PostgreSQL que utilizarán los tres primeros elementos. La cantidad de recursos que consumirá esta VM será de 4 vCPU, 18GB de RAM y 140GB de Disco como detallamos anteriormente.

Opciones de configuración del Appliance de vRA

Servidor IaaS: 1 máquina virtual con sistema operativo Windows Server. El servidor IaaS dará servicio al Web Server, el Manager, DEM Worker, DEM Orquestrator y el Agente que conectará con vCenter. Al tratarse de una POC es posible instalar en este mismo equipo una instancia de SQL Express. También podría utilizarse como el Host de Powershell/PowerCLI. Los recursos con los que aprovisionaremos esta máquina serán de 4 vCPU, 8GB de RAM y 40GB de Disco. Otros servicios a utilizar: •

Servidor DNS

•

Servidor DHCP (opcional, no requerido)

•

Directorio Activo (opcional, no requerido)

•

vCenter Server (opcional, no requerido)

•

NSX (opcional, no requerido)

Al utilizar el menor número de recursos posible para la POC no necesitaremos ningún balanceador

#VMwarePorvExperts

857

Capítulo 16 - vRealize Automation Federico Cinalli

web, tampoco certificados digitales emitidos por una CA de confianza ni otros elementos como IPAM o vRB. También es posible integrar vRA con vRealize Operations Manager y vRealize Log Insight. Estas integraciones son muy simples de configurar y, por más que se trate de una prueba de concepto, aportan un valor considerable al poder ver el rendimiento de las VMs desplegadas y tener un control de los Logs tanto de vRA como también de los Workflows ejecutados en vRO. Lo que sí vamos a necesitar van a ser los registros DNS tipo A y PTR para el Appliance de vRA y el servidor IaaS. No es necesaria una instancia de Directorio Activo para una POC, aunque sí recomendable para explicar de forma más simple el uso de los Roles de vRA y el nesting en nuestro dominio de Directorio Activo. De cara a darle algo de funcionalidad al POC necesitaríamos una instancia de vCenter con un Cluster simple que incluso puede estar compuesto de un único Host de ESXi si lo quisiéramos. NSX tampoco es un requerimiento para vRealize Automation pero utilizar vRA sin NSX es igual a que el Barcelona deje a Messi en el banco de suplentes. El diseño Lógico de nuestro POC queda entonces de esta forma:

Componentes de un POC de vRA

Esquema de Instalación para una prueba de concepto de vRA El orden de Instalación será muy similar al siguiente: Orden

1

Componente

SQL Server

Tareas

Imagen

Preparar base de datos SQL. En un POC es posible utilizar SQL Express en el mismo equipo IaaS Desplegar maquina Windows

2

IaaS

Aplicar parches y actualizaciones Agregar al Dominio

#VMwarePorvExperts

858

Capítulo 16 - vRealize Automation Federico Cinalli

Creación de registros tipo A y PTR 3

DNS y Usuarios

Alta de cuentas funcionales en Directorio Activo basado en roles de vRA Definir la cuenta administrativa a utilizar en IaaS Desplegar Appliance de vRA

4

Appliance vRA

Definición de contraseña Root Configuración de parámetros de Red Ejecución del asistente desde el equipo IaaS Asociación de instancia de vRA Instalación de Agente vRA en IaaS Validación de requerimientos en IaaS

5

Asistente configuración

Configuración de requerimientos en IaaS Conexión con instancia SQL Definición de contraseña Identity Manager Configuración credenciales DEM’s Configuración credenciales Web y Manager Definición de instancia Agente Creación de certificados digitales Pre-validación de los servicios

6

vRA – IaaS

Instalación de los servicios Validación post-instalación (Web, Servicios, Logs)

Asistente de instalación de vRA finalizado correctamente

#VMwarePorvExperts

859

Capítulo 16 - vRealize Automation Federico Cinalli

5. Conceptos de vRealize Automation Para una correcta comprensión de las siguientes fases debemos comenzar con una breve descripción de los elementos, algunos lógicos y otros externos como vRO, aunque todos necesarios para la puesta en marcha de la maquinaria de vRA. Aclaración: la gran mayoría de la documentación está disponible en idioma inglés. Si bien este libro es en español vamos a utilizar también conceptos en inglés para una mejor asociación entre los conceptos y los nombres que podemos encontrar en la mayoría de documentación en idioma inglés. Tenant: Instancia adicional de vRA que permite segmentar partes de la solución como el Branding, Autenticación, Recursos y administración. Podemos pensar en un Tenant como una delegación, división o cliente de una compañía. Catálogo: El Catálogo de vRA es el elemento que contiene los diferentes tipos de automatizaciones definidos en los Blueprint.

Tenant y Catálogo de vRA

Endpoint: Es el elemento que nos permite conectar con determinados recursos como una instancia de vCenter server, NSX, vRealize Orchestrator, vRealize Operations Manager, etc.

Endpoints y DEM conectando a recursos

#VMwarePorvExperts

860

Capítulo 16 - vRealize Automation Federico Cinalli

Fabric: Una vez que temenos configurado el Endpoint y somos capaces de ver los recursos, a esos recursos los denominamos Fabric. Podemos tener un Fabric de vSphere, AWS, Azure, etc. Fabric Group: El Fabric Groupo representa una cantidad lógica de recursos que provienen del Fabric. Como ejemplo podemos mencionar un Cluster de vSphere.

Cluster 1 de vSphere como Recurso en Fabric Group

Reservas (Reservation): Las reservas en vRA son lo opuesto a las reservas en vSphere. Las reservas de vRA se asignan a Business Groups y establecen un límite de recursos como cantidad máxima de RAM, de GBs o incluso número máximo de VMs que podríamos desplegar en ese BG (Business Group) con los recursos presentados a través de la reserva.

Opciones de Reservas de recursos en vRA

Políticas de Reservas (Policy reservation): Utilizamos las políticas de reservas para pre-definir un tipo de recurso determinado como puede ser un Tier SSD, un Cluster determinado o un Datacenter en

#VMwarePorvExperts

861

Capítulo 16 - vRealize Automation Federico Cinalli

concreto.

Ejemplo de Políticas de Reservas para calidades de Almacenamiento

Business Group: Los BG’s son agrupaciones lógicas que pertenecen a un Tenant determinado. Una simple analogía podría ser una Unidad Organizativa de Directorio Activo. Entre los ejemplos que podemos mencionar podrían estar un departamento de la empresa, un proyecto o una sucursal entre otros.

Asignación de Reservas a log Business Group 1 y 2

Custom groups: En los Custom Groups definimos quién o quienes, normalmente a través de grupos de Directorio Activo, van a poder diseñar los diferentes tipos de Blueprints.

#VMwarePorvExperts

862

Capítulo 16 - vRealize Automation Federico Cinalli

Creación de Custom Group para definir los Blueprint Architects Blueprint: Es lo que le da vida a vRealize Automation. Un Blueprint define las reglas y parámetros de los diferentes tipos de automatizaciones que ofrecemos en el Catálogo de vRA. Podemos tener Blueprints de máquinas virtuales, contenedores o servicios personalizados (XaaS).

Design canvas donde se configuran los Blueprints en vRA

#VMwarePorvExperts

863

Capítulo 16 - vRealize Automation Federico Cinalli

6. Configuración de vRealize Automation Una vez completado y validado el diseño, implementado los componentes y verificada la instalación ya es momento de pasar a la fase de configuración. En la fase de configuración es donde integramos la implementación estándar con los recursos de la organización ya sea en los propios centros de datos y/o con los recursos que disponen en Cloud Publicas. El orden de implementación de una solución de vRealize Automation puede variar ligeramente en algunas fases, aunque el procedimiento bastante concreto. Antes de continuar debemos comprender la diferencia entre los tres sistemas de gestión de identidad que normalmente nos vamos a encontrar. Es muy fácil confundirse y no podemos comenzar la configuración con dudas. Además del Identity Manager, que instala su propio sistema de gestión de identidades, normalmente vamos a integrar vCenter y Directorio Activo.

Usos de cada sistema de gestión de identidades Identity Manager: daremos de alta al menos un usuario para la asignación inicial a los roles de IaaS Admin y Tenant Admin. Single Sign On: el uso del sistema de gestión de identidades y autenticación de vSphere lo utilizaremos para gestionar el acceso a los recursos de vSphere. Directorio Activo: este recurso, integrado en Identity Manager, es lo que normalmente utilizamos en producción para consolidar las cuentas de usuario finales (usuarios de Business Groups) y también las de los administradores de vRealize Automation.

Tres sistemas de gestión de identidades

En la pantalla de login de vRA podremos elegir loguearnos con un usuario local del Identitiy Manager o bien un usuario de Active Directory, siempre y cuando hayamos agregado el dominio de Active Directory a vRA.

#VMwarePorvExperts

864

Capítulo 16 - vRealize Automation Federico Cinalli

Selección de fuente de identidad en pantalla de Login en vRA

Proceso de Configuración de vRealize Automation A continuación, describiremos el proceso de configuración de una instalación simple de vRA, partiendo de la base de un vRA Appliance y un IaaS ya instalados. Expondremos primero una tabla para identificar el orden, el elemento, las tareas y el rol con el que debemos hacer la configuración.

Resumen del proceso de Configuración de vRA

Veamos cada paso de forma general.

Nuevo Tenant Creación del Tenant, definición de la URL y alta de al menos un usuario local que será gestionado por Identity Manager.

#VMwarePorvExperts

865

Capítulo 16 - vRealize Automation Federico Cinalli

Alta de usuarios locales en vRA

Roles en nuevo Tenant Definición del Tenant Admin y el IaaS Admin. El Tenant Admin podrá crear los Business Groups y todo lo relacionado con el Tenant. El IaaS Admin podrá configurar los Endpoints y crear el Fabric Group.

Definición de Roles en nuevo Tenant

Configuración de Endpoints Cualquier usuario con el Rol de IaaS Admin podrá configurar los Endpoints. Dependerá de los recursos de la organización y el proyecto en general pero normalmente configuramos Endpoints para vCenter, NSX, vRealize Orchestrator (por más que utilicemos la instancia embebida) y también vRealize Operations Manager.

Configuración de Endpoints

#VMwarePorvExperts

866

Capítulo 16 - vRealize Automation Federico Cinalli

Integración Active Directory Logueándonos con el Rol del Tenant Admin en el default Tenant podremos configurar la integración de Active Directory con nuestro vRealize Automation. Este paso es de vital importancia para poder utilizar grupos de Active Directory a medida que vamos creando y configurando componentes.

Integración de dominio de Active Directory en vRA Creación de Fabric Group Un usuario con el Rol de IaaS Admin será capaz de crear los Fabric Groups. Como parte del procedimiento de la creación de los Fabric Groups deberemos definir quiénes serán los usuarios y/o grupos del Rol de Fabric Group Admin. Esos usuarios serán los encargados de configurar las reservas de recursos.

Alta de un nuevo Fabric Group

Configuración de Network Profiles Independientemente de si estamos trabajando con NSX o no, deberemos configurar los Network Profiles. Es en estos elementos cuando definiremos la lógica de los servicios de Red con parámetros como segmentos IP, puertas de enlace, servicios DNS y dominios. Los Network Profiles pueden ser External, NAT y/o Routed. Durante la creación de las Reservas se asociará un Network Profile con un Port Group o Virtual Network.

#VMwarePorvExperts

867

Capítulo 16 - vRealize Automation Federico Cinalli

Configuración de un Network Profile de tipo External

Creación de Business Groups Los Recursos de los Fabric Groups y los Blueprints se asignan a los Business Groups. Antes de crear una Reserva para asignar recursos de Computo y Almacenamiento tendremos que disponer de al menos un Business Group. Como parte del procedimiento de creación del BG deberemos definir los roles de BG Manager, Support, Shared y User. Serán estos últimos, los usuarios del Business Groups, los que podrán hacer peticiones de ítems del Catálogo.

Creación de un Business Group

Configuración de Reserva Como hemos visto son múltiples las tareas de configuración que debemos completar antes de poder asignar recursos a un BG a través de una reserva. El concepto de Reserva en vRealize Automation es prácticamente el opuesto que en vSphere. Mientras que en vSphere una Reserva es una promesa de recursos, en vRA hablamos de un ámbito de recursos y un límite estipulado de los mismos. En la Reserva podremos definir el límite de VMs, cantidad máxima de RAM y los Datastores con su correspondiente límite.

#VMwarePorvExperts

868

Capítulo 16 - vRealize Automation Federico Cinalli

Configuración de una Reserva de vSphere

Creación de grupos personalizados Llegados a este punto ya disponemos de recursos en, al menos, un Business Group del Tenant. Eso significa que toca comenzar a diseñar Blueprints, pero antes necesitaremos los privilegios correspondientes. Eso lo hacemos a través de grupos especiales o personalizados que configuraremos en vRealize Automation. Los grupos personalizados o Custom Groups nos permiten crear Roles con diferentes privilegios para trabajar con Blueprints de diferentes tipos.

Creación de Grupos para la definición de Roles de diseño de Blueprints

Listos para diseñar Blueprints Hemos pasado ya por la fase de Diseño, la instalación de los componentes y su validación, la configuración de todos los elementos lógicos de vRA y además disponemos del Rol necesario para, finalmente, poder comenzar con el diseño de los Blueprints. Un usuario con los Roles de Tenant Admin, IaaS Admin y Arquitecto de aplicaciones y Administrador de contenedores podrá ver el siguiente menú en vRA:

Vista de la interface de usuario en vRA con todos los Roles

#VMwarePorvExperts

869

Capítulo 16 - vRealize Automation Federico Cinalli

En este punto estaremos listos para comenzar con el diseño y publicación de Blueprints con sus correspondientes Parámetros, Custom Properties, etc. No obstante, antes de comenzar con la creación de Blueprints, necesitamos comprender la integración entre vRA y NSX. .

#VMwarePorvExperts

870

Capítulo 16 - vRealize Automation Federico Cinalli

7. Integración de NSX y vRealize Automation La combinación de NSX como plataforma de virtualización de Redes y vRealize Automation nos aporta un control total a la hora de trabajar con los Blueprints, siempre alineados con los requerimientos y procedimientos pre-definidos de seguridad. vRealize Automation 7.5 está soportado para trabajar tanto con NSX-V como también con NSX-T. Este capítulo lo basaremos en una integración de vRealize Automation y NSX-V. Comenzaremos bien desde abajo hasta llegar a los Network Profiles y las Reservas de forma que, cuando estemos trabajando con los Blueprints, seamos capaces de comprender correctamente la integración de los servicios de red con vRA. vCenter y NSX •

NSX se registra en vCenter y se comunican vía API

•

Por cada vCenter se podrá registrar un único NSX en relación 1:1

•

NSX necesita trabajar con una base de un virtual distributed switch (vDS1)

•

Por cada Logical Switch de NSX se creará un Port Group de base en vDS1

•

Los Port Groups de un vDS normalmente están aislados entre sí con vLans

•

Los Logical Switches utilizan la encapsulación de VXLAN

•

Los DLR son Distributed Logical Routers y están embebidos en el ESXi

•

Los DLR pueden trabajar con rutas estáticas, OSPF y BGP

•

Los DFW son los Firewall Distribuidos y están embebidos en el ESXi

•

Los DFW aportan la Microsegmentación

•

Los Microsegmentación se gestiona con los Security Groups y Security Tags

Esquema lógico de vCenter y NSX

vRA, vRO, vCenter y NSX

#VMwarePorvExperts

871

Capítulo 16 - vRealize Automation Federico Cinalli

Se va sumando gente al baile decían en mi pueblo. Una vez que tenemos la base mínima del esquema lógico entre vCenter y NSX es tiempo de sumar vRealize Automation y vRealize Orchestrator. Es hora de hacer amigos y registrar las diferentes soluciones entre sí. Independientemente de que utilicemos una instancia embebida de vRO o si utilizamos la instancia interna del Appliance de vRA, debemos registrar el Endpoint de vRO en vRA.

Registro de vRO en vRA

En su momento registramos como Endpoints tanto vCenter como también NSX. Tenemos que asegurarnos de establecer la asociación entre ambos Endpoints en vRA. En el supuesto caso de tener un segundo o tercer vCenter haremos lo propio con cada instancia y su correspondiente instancia de NSX Manager.

Asociación entre un Endpoint de vCenter y un Endpoint de NSX

Además de los Endpoints de vRA, gestionados por el IaaS, con vCenter, NSX y vRO es necesario hacer lo propio en vRealize Orchestrator. Ejecutaremos los Workflows de vRO para registrar tanto la instancia de vCenter como también de NSX.

#VMwarePorvExperts

872

Capítulo 16 - vRealize Automation Federico Cinalli

Workflows en vRO para registros de vCenter y NSX

Una vez configurados los cuatro Endpoints y la correspondiente asociación entre los Endpoints de vCenter y NSX en vRA tendremos algo como lo siguiente:

Esquema Lógico entre vRA, vRO, vCenter y NSX

Network Profiles y Redes en vRealize Automation Una vez definidos los accesos a los recursos de red en vRA, a través de los Endpoints de vRA y vRO, debemos pasar a la parte lógica. Por un lado, vamos a configurar los Network Profiles para pasar luego a la asociación de los recursos lógicos (Network Profiles) con los recursos virtuales (Port Groups o Logical Switches). Lo primero que vamos a definir a la hora de crear un Network Profile es definir el tipo de red. Veamos los tres tipos de redes y sus características.

#VMwarePorvExperts

873

Capítulo 16 - vRealize Automation Federico Cinalli

Creación de Network Profiles en vRealize Automation

Tipos de redes en vRealize Automation External: funciona como un segmento independiente que podría tener acceso a una red superior como Internet. Necesita un Port Group o Logical Switch creado previamente. NAT: es un segmento de red que utilizará una instancia de NSX Edge para separar una red Externa y el segmento interno utilizando reglas NAT. Las VMs se conectarán al segmento interno y es posible definir las reglas NAT como parte del Blueprint. Routed: el tipo de red enrutada utilizará un segmento interno, pero estará conectada a un interface virtual de un Distributed Logical Router que nos permitirá conectarnos a una red superior como puede ser una red External.

Esquema lógico de redes en vRealize Automation

Según podemos apreciar en el esquema anterior, una red External únicamente requiere un Port Group o un Logical Switch además de los parámetros necesarios como DNS, rango de IP y puerta de enlace.

#VMwarePorvExperts

874

Capítulo 16 - vRealize Automation Federico Cinalli

Creación de un External Network Profile

Para crear un Network Profile de tipo NAT vamos a necesitar de los servicios de NSX. Tanto la instancia de NSX Edge, su configuración, como también el Logical Switch se crearán bajo demanda según definición del Blueprint. Se requiere definir el tipo de NAT a configurar (one-to-one o one-to-many) y además es posible definir un ámbito DHCP junto con los parámetros de red.

Creación de un NAT Network Profile

Cuando creamos un Network Profile Routed, además de requerir los servicios de NSX, debemos tener pre-configurado un DLR el cual asociaremos a la hora de crear la Reserva. Como se puede ver en la siguiente imagen, debemos apuntar a una External Network.

#VMwarePorvExperts

875

Capítulo 16 - vRealize Automation Federico Cinalli

Creación de un Routed Network Profile

Configuración de Network Profiles en Reservas Si bien mencionamos anteriormente las Reservas, una parte fundamental es la asociación entre los Network Profiles y los Port Groups (en caso de no utilizar NSX) o los Logical Switches.

Asociación de un Logical Switch y un Network Profile en una Reserva

Como parte de los servicios de red de NSX en vRealize Automation existe una cantidad importante de configuraciones y opciones que están fuera del alcance de este libro, aunque da lugar perfectamente para un libro solo de esa temática. No obstante, merece la pena recomendar el eBook “VMware NSX Automation Fundamentals” de descarga gratuita (en idioma Inglés).

#VMwarePorvExperts

876

Capítulo 16 - vRealize Automation Federico Cinalli

Libro NSX Automation por autores y colaboradores de primer nivel 

#VMwarePorvExperts

877

Capítulo 16 - vRealize Automation Federico Cinalli

8. Conceptos de Blueprints El Catálogo de vRealize Automation está clasificado en tipos de servicios y basado en los diferentes Blueprints. Para ser capaces de ofrecer lo que conocemos como “Ítems del Catalogo” o “Catalog Ítems” debemos, además de crear el Blueprint, definir los permisos y privilegios que permitirán a un usuario de un Business Group hacer un “Request” de un Catalog Item. A este proceso le llamamos “Entitlement”. Existen diversos tipos de Blueprint, algunos simples y otros complejos. Veamos algunos ejemplos. Máquina simple: Despliegue de maquina Windows server con direccionamiento IP estático de un pool predefinido gestionado por el IPAM de vRA. La máquina se agregará automáticamente al dominio y, según el usuario que hace la petición, se creará en la Unidad Organizativa correspondiente. El usuario que solicita la nueva máquina será miembro del grupo de Administradores Local. Cuando la maquina se elimine desde vRealize Automation se eliminará la cuenta de equipo en el dominio y se liberará la IP del Pool seleccionado en el Blueprint. Multi Máquina: Despliegue de dos instancias de Linux Debian. Se establecerá el hostname de forma manual durante la solicitud. Se creará automáticamente la contraseña de ambas cuentas root siguiendo las directrices de seguridad pre-establecidas. Los registros DNS tipo A y PTR se crearán en el la zona DNS como parte del despliegue. Se habilitará el servicio SSH en ambas instancias y en la primera máquina se instalará Apache como parte de la configuración inicial utilizando un script de la librería de Software. En la segunda maquina se instalará, también automáticamente, PostgreSQL. Ambas maquinas estarán conectadas a la misma red y tendrán acceso a Internet a través de una instancia NSX Edge. El usuario que solicitó el Ítem del Catalogo recibirá un mail una notificación confirmando el correcto despliegue de las maquinas. Un documento PDF adjunto en el mail entregará los parámetros como direcciones IP, métodos de acceso y contraseñas de las cuentas root. Aplicaciones con servicios de Red: Cuando el usuario de vRealize Automation hace la petición del Ítem del Catalogo deberá seleccionar el Datacenter en donde se desplegarán las maquinas que darán soporte a las Aplicaciones. Una vez seleccionado el Datacenter se crearán dos instancias de Windows Server y SQL Server con los servicios de AlwaysOn automatizado con Powershell. De forma adicional, otras dos instancias de Windows Server con los servicios de IIS se desplegarán en la misma red. Un NSX Edge se creará bajo demanda y se configurarán los servicios de Balanceador Web para los servicios IIS. Por requerimientos de seguridad se creará una segunda red sin acceso a Internet y conectará un segundo vNic únicamente en las maquinas IIS. Máquinas en Cloud Pública: Se creará una instancia de maquina Linux en la Cloud Publica (Azure, AWS, Etc) y se conectará a un almacenamiento adicional provisto por el mismo proveedor Cloud. Servicio XaaS: El servicio ofrecerá un Túnel VPN bajo demanda. Además del nuevo Peer, que se establecerá como parámetro definido por el usuario, se generará la clave compartida de forma automática definiendo el direccionamiento privado. Se creará una cuenta de usuario en Directorio Activo que servirá como autenticación interna. La nueva cuenta creada se agregará a un grupo de

#VMwarePorvExperts

878

Capítulo 16 - vRealize Automation Federico Cinalli

usuarios y Unidad Organizativa predefinida. Como hemos podido ver las posibilidades son prácticamente infinitas. Es cierto que si bien algunos Blueprints son fáciles de crear y configurar, otros pueden llegar a ser un desafío. ¿Lo mejor de todo? Las posibilidades. En el siguiente esquema vemos un esquema lógico en el que conectamos los recursos de vCenter y NSX con la Reserva y un Blueprint asignado a un catálogo de un Business Group determinado.

Esquema lógico de recursos, reservas, blueprint y catálogo

Objetos gestionados En vRealize Automation tenemos básicamente dos tipos de Blueprints. Por un lado están los Blueprints que crean objetos como puede ser una máquina virtual. A estos objetos les llamamos “gestionables” o “managed ítem” debido a que será posible ejecutar determinados workflows sobre esos objetos o ítems. Los otros tipos de Blueprints ejecutan workflows como por ejemplo el cambio de una contraseña o la ejecución de un backup bajo demanda lo cual no permite ejecutar ningún tipo de workflows sobre el resultado. Una vez que un workflow finaliza el despliegue de un objeto gestionado, en ese preciso momento, comienza lo que llamamos “Día 2”. Las operaciones del día 2, también llamadas Resource Actions, permiten ejecutar workflows para tareas de mantenimiento, parcheado, actualizaciones o cambios en la maquetación. Esos Resource Actions están basados en workflows de vRealize Orchestrator.

Event Broker Otra forma de trabajar con las operaciones del día 2 es a través de las subscripciones de Event Broker. Event Broker nos permite identificar un momento determinado del ciclo de vida de la máquina virtual

#VMwarePorvExperts

879

Capítulo 16 - vRealize Automation Federico Cinalli

como puede ser un reinicio, la ejecución de un snapshot, un redimensionamiento o incluso una aprobación.

Creación de una subscripción de Event Broker

Es posible además considerar múltiples variables como el Tenant, la Reserva, el Usuario o el Datacenter para concretar la subscripción. La subscripción ejecutará un Workflow de vRealize Orchestrator en base al criterio necesario.

Definición de condiciones en una subscripción de Event Broker

Las subscripciones de Event Broker permiten personalizar aún más si cabe no solamente la creación

#VMwarePorvExperts

880

Capítulo 16 - vRealize Automation Federico Cinalli

de recursos, sino que permiten controlar prácticamente la totalidad del ciclo de vida de una máquina virtual. En esta edición del libro las operaciones del día 2 así como también Event Broker está fuera del alcance.

#VMwarePorvExperts

881

Capítulo 16 - vRealize Automation Federico Cinalli

9. Creando un Blueprint básico No podíamos terminar el capítulo de vRA sin ver cómo crear al menos un Blueprint básico. Veremos a continuación una guía paso a paso sobre cómo crear un Blueprint para un despliegue simple de una máquina virtual. 1 – Creamos el Blueprint y definimos el nombre del Blueprint

Opciones de Blueprint para limitar el tiempo que las VMs estarán disponibles

2 – Selección de Transport Zone

El Transport Zone define el ámbito de Virtual Networks entre Clusters

3 – En el Design Canvas seleccionamos Machine Types, vSphere (vCenter) Machine y la arrastramos al centro del canvas.

#VMwarePorvExperts

882

Capítulo 16 - vRealize Automation Federico Cinalli

El Design Canvas en donde agregamos, modificamos y quitamos elementos del Blueprint

4 – Seleccionamos el objeto máquina virtual y veremos las propiedades del objeto. En la pestaña General podremos definir el ID de la VM, seleccionar el número máximo de instancias a solicitar (en este caso solo 1) y seleccionar un Policy Reservation y un Machine prefix para asignar un nombre automático al objeto VM en el inventario de vCenter.

Propiedades de objeto máquina virtual

5 – En Build Information tenemos la opción de seleccionar el modo de despliegue que puede ser Create, Clone o Linked Clone. En este caso la maquina se creará de forma rápida utilizando Linked Clone, para lo cual necesitaremos seleccionar un Snapshot. Podremos además apuntar a un Customizacion spec que no es más que el VM Customization specifications del vCenter. A tener en cuenta que el nombre distingue entre mayúsculas y minúsculas.

#VMwarePorvExperts

883

Capítulo 16 - vRealize Automation Federico Cinalli

Opciones de clonado de la VM

6 – En Machine Resources definiremos la cantidad de recursos mínimos y máximos que un usuario podrá solicitar en este Blueprint. Es muy frecuente que en entornos en producción se definan políticas de aprobación cuando se solicita una cantidad de recursos de CPU, RAM o Disco fuera de lo normal.

Definiendo la cantidad de recursos del Blueprint

7 – En Storage es posible agregar un disco virtual adicional definiendo en número máximo de volúmenes. Algo muy interesante es definir de forma estática la política de almacenamiento o bien ofrecer que el usuario pueda elegir por sí mismo.

Opciones de Almacenamiento de la VM

8 – La configuración de red la definimos en la pestaña Network. Las opciones son agregar una o múltiples vNics a la VM. En la siguiente imagen podemos ver que no hay red disponible. Es normal, lo resolvemos en el siguiente punto.

#VMwarePorvExperts

884

Capítulo 16 - vRealize Automation Federico Cinalli

Configuración de red sin recurso para conectar la vNic

9 – Debemos hacer click en un espacio vacío del Design Canvas y a continuación seleccionar Network & Security en el menú lateral. Seleccionaremos y arrastraremos Existing Network a un espacio vacío del canvas.

Agregando recurso de red al Blueprint

10 – Cuando seleccionamos el objeto Existing Network veremos inmediatamente las propiedades. Debemos hacer click en el botón a la derecha de Network profile y seleccionaremos un Network profile de la lista de las External Networks. Este elemento ya lo vemos familiar verdad? Todavía podemos ver en el Canvas que el objeto VM y el objeto External Network están separados. Solo de momento…

#VMwarePorvExperts

885

Capítulo 16 - vRealize Automation Federico Cinalli

Asignando un Network Profile al External Network

11 – Seleccionamos nuevamente el objeto VM y, en Network, comprobaremos que ahora está disponible para “conectar” nuestro Network Profile. Una vez seleccionado podremos definir el tipo de direccionamiento IP.

Asignando un Network Profile a la VM

12 – Podremos verificar en el canvas que el objeto VM está conectado a la External Network.

Vista de la VM conectada al External Network

13 – Guardaremos el Blueprint y cerraremos el Design Canvas haciendo click en Save y Finish. Esto cerrará el Blueprint y podremos ver que, por defecto, el Status está en modo Draft.

#VMwarePorvExperts

886

Capítulo 16 - vRealize Automation Federico Cinalli

Es muy importante seleccionar (no editar) el Blueprint y hacer click en Publish para que podamos proceder con el procedimiento de Entitlement.

Vista del elemento Blueprint en modo Draft

14 – Es momento de asociar el Blueprint a un servicio y configurar el Entitlement para permitir que usuarios del Business Group puedan ver el Blueprint (luego del Entitlement será Catalog Item) y hacer su correspondiente solicitud.

Creando un servicio en vRA

Los servicios en vRA son útiles para agrupar conjuntos de Blueprints / Catalog Ítems en común. Por ejemplo maquinas Windows, maquinas Linux, servicios AWS, operaciones de Backup, etc.

15 – Una vez creado el servicio agregaremos el Blueprint, también llamado en esta instancia ítem.

Asignando un Blueprint a un Servicio

#VMwarePorvExperts

887

Capítulo 16 - vRealize Automation Federico Cinalli

16 – La asignación de privilegios sobre quién será capaz de realizar una solicitud al Blueprint y qué acciones podrá ejecutar sobre la VM ya desplegada la definimos en el Entitlement.

Entitlements en vRA

Para crear un Entitlement simplemente haremos click en New y seleccionaremos el Servicio, el Blueprint, los usuarios del Business Group y las acciones que permitiremos ejecutar.

Selección de usuarios y definición de estado del Entitlement

Asociando el servicio, el blueprint y las acciones

#VMwarePorvExperts

888

Capítulo 16 - vRealize Automation Federico Cinalli

16 – Finalmente después de 40 páginas leídas podremos ver un objeto en el Catálogo de vRA ;-)

Ítem en el Catálogo de vRA

17 – Ahora es cuando hacemos click en REQUEST para comenzar la solicitud. Podemos completar los datos de Descripción y su justificación y hacer click en SUBMIT.

Ejecutando una solicitud en el Catálogo de vRA

18 – Verificando el despliegue de la solicitud en Deployments. A los pocos segundos de ejecutada la solicitud podremos ver en vCenter el trabajo de clonado de la VM.

#VMwarePorvExperts

889

Capítulo 16 - vRealize Automation Federico Cinalli

Vista de los despliegues en vRealize Automation

19 – Al cabo de unos pocos minutos ya podremos ver la VM tanto en vRealize Automation como también en vCenter.

Ítem disponible en vRA

#VMwarePorvExperts

890

Capítulo 16 - vRealize Automation Federico Cinalli

10. Resumen y recomendaciones Como hemos visto a lo largo de todo el capítulo, tanto la instalación, configuración como también el diseño del Blueprint lleva un trabajo considerable. Son muchos los elementos que deben funcionar de forma coordinada para llevar a cabo una correcta implementación de vRealize Automation. No obstante la recompensa es alta y sobre todo gratificante. Cada Blueprint, Workflow y parámetro puede llegar a ser un verdadero desafío que nos pondrá a prueba. vRealize Automation es el tipo de solución que verdaderamente aporta valor a la organización. Pero no solo a la organización, sino que también a nosotros mismos como profesionales. Evidentemente no es una herramienta para cualquier tipo de empresa como sí puede ser un Host de ESXi, pero también podemos verlo como una oportunidad de marcar la diferencia respecto a nuestro perfil profesional. También es cierto que esta solución es exigente en cuanto a cantidad de recursos y eso incrementa la dificultad a la hora de invertir horas de práctica pero no debemos olvidar los Hands On Labs de vRealize Automation como un recurso muy valioso y que tenemos a nuestra disposición en cuestión de minutos y de forma totalmente gratuita.

Lista de laboratorios de vRealize Automation disponibles en VMware Hands On Labs

#VMwarePorvExperts

891

Capítulo 16 - vRealize Automation Federico Cinalli

#VMwarePorvExperts

892

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

893

Capítulo 17 Automatizando vSphere con Ansible Miquel Mariano

#VMwarePorvExperts

894

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

Ansible

1. Introducción a la automatización de tareas

Igual James Cameron no iba tan desencaminado cuando escribió el guión de Terminator y llegará un día en que Skynet domine el mundo. En un futuro, cada vez menos lejano, las máquinas serán lo suficientemente inteligentes como para averiguar lo que queremos que hagan y hacerlo. Estamos dando pasos agigantados en cuanto a IA y machine learning pero todavía, los humanos, nos pasamos muchísimo tiempo “diciendo” a las máquinas las cosas que queremos que hagan. En el mundo de las TI no es una excepción, y los administradores, dedicamos mucho tiempo a tareas de operación que nos consumen gran parte de nuestra jornada. Crear y configurar un nuevo usuario, desplegar una nueva VM o servicio o simplemente escalar una aplicación que se nos ha quedado corta de recursos son algunos de los ejemplos más clásicos. Seguro que estaréis de acuerdo conmigo en que en vuestro día a día hay decenas de tareas repetitivas y que sería ideal automatizar, pero ¿por qué?

•

Por la disminución y menor posibilidad de errores Siento ser tan directo y deciros esto, pero cometéis errores, cometemos errores. Todos lo hacemos. Continuamente, los humanos, malinterpretamos las cosas, leemos mal, nos olvidamos de algunas tareas, hacemos las tareas en el orden equivocado…Eso es así, y es por eso por lo que la automatización nos permite salirnos de la ecuación y dejar que los sistemas hagan por si solos.

•

Por el ahorro de tiempo Todo lleva tiempo: iniciar sesión en consolas, buscar configuraciones, conectarse a servidores, escribir comandos. Especialmente cuando, según el punto anterior, arruinamos algo y tenemos que arreglarlo. Una vez más, simplemente dejemos que los sistemas lo hagan. Dediquemos nuestro tiempo a innovar, a pensar cómo automatizar más cosas.

•

Por la auto documentación En nuestro día a día, estamos acostumbrados a tratar con infinidad de documentación de instalación y configuración de nuestros sistemas, tareas y operaciones. Esta documentación requiere de un gran esfuerzo para mantenerla actualizada e inevitablemente en muchos casos se descuida y entra en desuso. Infrastructure as Code / Programmable Infrastructure son conceptos que nos permiten a través de código tener una visión clara tanto de la configuración como de la implemen-

#VMwarePorvExperts

895

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

tación de un sistema o tarea con sus pasos a seguir bien definidos. Además, en muchos casos, la configuración inicial y el ciclo de vida de un sistema se automatiza. De esta forma siempre tenemos el código con la configuración actual sin necesidad de mantener documentación paralela.

•

Por la reproducibilidad Reproducibilidad significa que tenemos que ser capaces de reproducir o recrear nuestro sistema de manera fácil y rápida. Se nos puede dar el caso que queramos un entorno paralelo de pruebas para probar nuestros desarrollos o poniéndonos en lo peor, podríamos perder todo nuestro sistema. Tenemos un servicio X que funciona perfectamente, pero el día menos pensado tenemos una contingencia grave y se pierde todo. Tenemos los datos bien salvaguardados en copias de seguridad, pero hay que montar de nuevo toda la infraestructura y la persona que en su día se encargó ya no está en la empresa y sólo dejo un documento básico de instalación. Seguimos ese documento al pie de la letra, pero no hay manera de que eso funcione ☹. Con la automatización y la Infrastructure as Code que comentábamos antes eso es posible, ya que tenemos el código con la última configuración de ese sistema y seriamos capaces de repetir esas configuraciones tantas veces cómo nos sea necesario.

#VMwarePorvExperts

896

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

2. Terminología Antes de nada, me gustaría dejar una pequeña recopilación de conceptos y definiciones que vamos a encontrarnos continuamente al trabajar con Ansible: •

Facts: Información útil de los nodos.

•

Inventario: Incluye información, estática o dinámica, de los nodos administrados y su información.

•

Módulos: Son las librerías que se utilizan para controlar elementos como ficheros, servicios paquetes o comandos. Estos se copian al nodo cliente para que ejecute la tarea indicada.

•

Nodo: Objeto a administrar, ya sea un servidor, un router y otro elementos.

•

Nodo de control: Máquina donde está instalado Ansible engine y que será desde donde administremos el resto de nodos.

•

Play: Lista de tareas a realizar en los clientes especificados en el Playbook.

•

Playbook: Se encarga de definir todas las tareas que debemos realizar sobre un conjunto de hosts clientes.

•

Roles: Es una agrupación de tareas, ficheros y plantillas, que pueden ser reutilizados.

•

Task: Definición de una acción a realizar.

#VMwarePorvExperts

897

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

3. Introducción a Ansible Ansible es una herramienta que nos permite el manejo de configuraciones y despliegue de aplicaciones de manera sencilla. Esta plataforma de código abierto fue creada por Michael DeHaan como startup en 2013 y fue adquirida por RedHat a finales de 2015.

Dentro de la filosofía de Ansible cabe destacar los siguientes puntos: •

No requiere de agentes en los “clientes” Suficiente con una clave SSH y un intérprete de python, disponible nativamente en la mayoría de SO modernos.

•

Utiliza lenguaje YAML, muy intuitivo y de fácil comprensión Eso nos proporciona una suave curva de aprendizaje y en poco tiempo podemos tener implementada la solución.

•

Ahorra tiempo en el despliegue masivo de configuraciones A través de los playbooks y roles, seremos capaces de desplegar nuestras configuraciones masivamente sobre un inventario de servidores.

•

Reduce el % de error humano en la configuración de nuevos servicios. Una vez tengamos nuestros playbooks y roles definidos ya no deberemos preocuparnos por el factor humano. Todas nuestras configuraciones estarán basadas en la definición inicial.

•

Trabaja con la propiedad de idempotencia Una instrucción o comando no se ejecutará más veces una vez alcanzado el estado deseado.

#VMwarePorvExperts

898

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

•

Es OpenSource Tiene una comunidad muy activa con infinidad de módulos específicos.

Por poner alguna desventaja, comentar que: •

Necesita Python tanto en el nodo de control como en las máquinas a configurar.

•

El nodo de control no puede ser un Windows. Es recomendable RedHat, CentOS o Fedora.

Los principales beneficios de Ansible, los hemos comentado anteriormente. Reducir el factor humano frente a errores, ahorro sustancial de tiempo en tareas repetitivas, auto documentación y poder reproducir fácilmente las operaciones o tareas. Ansible, se conecta a los equipos que queremos configurar utilizando una clave SSH i a través de este canal, le envía las instrucciones y configuraciones que queramos aplicar. Hay que tener en cuenta también que todo lo que queramos hacer lo puede procesar en paralelo, así que es lo mismo tener que configurar 1, 5, 10 que 50 servidores a la vez.

#VMwarePorvExperts

899

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

#VMwarePorvExperts

900

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

4. Introducción a YAML y ejemplos YAML es el lenguaje en el que se definen los roles, los playbooks y demás estructuras en Ansible. Su nombre son las siglas de Yet Another Markup Language (Otro lenguaje de marcado más) o recursivamente YAML Ain`t Markup Language (YAML no es un lenguaje de marcado), depende de a quién preguntemos nos encontraremos con una u otra definición. Como comentábamos, es un lenguaje de marca, simple, basado en ficheros de texto plano y pensado para ser legible por humanos. En el mundillo del software y juntamente con XML, este es el formato más extendido para guardar información de configuraciones. Que Ansible utilice YAML para las definiciones de sus roles y/o playbooks, nos proporciona las siguientes ventajas: •

Conveniencia: No es necesario especificar todos los parámetros en el propio fichero YAML, sino que a través de variables podremos añadir estos parámetros a través de la línea de comandos en función de nuestras necesidades.

•

Mantenimiento: Los ficheros YAML, al ser texto plano, puede ser gestionados por un sistema de control de versiones (git o similar), de manera que se pueden registrar los cambios.

•

Flexibilidad: Es posible crear estructuras mucho más complejas usando ficheros YAML ya que podemos hacer que éstos se llamen entre sí. Dada su sencillez basta con conocer un poco sus estructuras básicas para empezar a crear ficheros para Ansible.

4.1 Mapas YAML Clave – Valor Podemos usar relaciones clave-valor en YAML poniendo la clave ‘dos puntos’ valor, en caso de que el valor sea una cadena no es necesario que este entre comillas, aunque por legibilidad es recomendable:

Relación Padre – Hijo La relación padre-hijo en YAML se hace escribiendo la etiqueta padre seguido ‘dos puntos’ y después en la linea siguiente identado** por dos o más espacios los hijos, siempre hacia abajo y conservando

#VMwarePorvExperts

901

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

los mismos espacios para cada hijo del mismo padre:

**https://es.wikipedia.org/wiki/Indentaci%C3%B3n

4.2 Listas en YAML Relación Clave-Lista En caso de la clave contenga una lista de valores podemos poner los valores dentro de corchetes [] separados por comas, p.e : [valor1,valor2,valor3] : La otra forma de hacer una lista es escribiendo los valores como si fueran hijos de la etiqueta valor, pero identificándolos con un guion -, posicionando cada elemento de la lista hacia abajo.

Relación clave-lista-lista Igualmente, los elementos de una lista también puede ser un conjunto de valores, es decir, otra lista. Esto se puede ilustrar de la siguiente manera:

Para finalizar este punto, me gustaría compartir con vosotros algunos consejos generales a la hora de

#VMwarePorvExperts

902

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

crear un fichero YAML: TIP: Usa siempre la codificación UTF-8 para evitar errores. No uses nunca tabulaciones, mejor utilizar espacios. Usa una fuente monoespaciada para visualizar/editar el contenido de los ficheros YAML. (siempre que no trabajes desde la línea de comandos).

#VMwarePorvExperts

903

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

5. Instalación El proceso de instalación de Ansible es bastante sencillo. Hay que tener en cuenta que Ansible no requiere de ninguna BBDD ni de ningún servicio/daemon a ejecutar. Bastará con la instalación de la paquetería necesaria en la máquina que actuará como “nodo de control”. Ansible se puede instalar sobre multitud de plataformas como RHL, Debian, CentOS, OS X…. El único requisito va a ser que el SO del “nodo de control” cuente con el intérprete de Python 2.6 o superior. Actualmente está disponible en la mayoría de SO de forma nativa. A día de hoy, la instalación del “nodo de control” no está soportado sobre plataformas Windows y, al ser propiedad de Red Hat, se recomienda la instalación sobre RHL, CentOS o Fedora. A continuación, veremos los pasos a seguir para la instalación de Ansible en las principales distribuciones:

YUM

APT-Ubuntu

Debian

#VMwarePorvExperts

904

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

TIP: Al ser un producto de Red Hat se recomienda su instalación sobre SO Red Hat, CentOS o Fedora Aquí podéis ver el proceso de instalación sobre un CentOS 7.

#VMwarePorvExperts

905

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

6. Configuración de Ansible Ansible, permite diferentes formas de proporcionar variables de configuración. A través de variables de entorno, directamente en tiempo de ejecución a través de la línea de comando o en un archivo de configuración llamado ansible.cfg. Las opciones que vienen por defecto son bastante correctas y suficientes para empezar, pero hay algunos parámetros que podremos modificar con dicho fichero de configuración. A mí personalmente me gusta modificar la variable donde indicamos donde se guardan los roles, más que nada para seguir una cierta coherencia en el árbol de directorios, que ahora veremos. # additional paths to search for roles in, colon separated roles_path = /etc/ansible/roles

Los cambios que hagamos y usemos en este fichero de configuración se aplicarán en el siguiente orden: •

ANSIBLE_CONFIG (variable de entorno si está configurada)

•

ansible.cfg (en el directorio actual de trabajo)

•

~/.ansible.cfg (en el directorio home del usuario)

•

/etc/ansible/ansible.cfg

De esta manera, por ejemplo, puede ser muy útil para que diferentes usuarios en el mismo “nodo de control” tengan configuraciones diferentes. NOTA: Podréis leer mas sobre el fichero ansible.cfg en la documentación oficial https://docs.ansible.com/ansible/latest/reference_appendices/config.html

Con la instalación inicial de Ansible, se crean una serie de ficheros y directorios en /etc/ansible. En este directorio se encuentra el fichero de configuración que antes comentábamos ansible.cfg, un fichero de inventario llamado hosts y una carpeta para guardar los roles. [root@localhost ansible]# ll /etc/ansible/ total 24 -rw-r--r--. 1 root root 20276 ene 25 16:10 ansible.cfg -rw-r--r--. 1 root root 1015 ene 25 17:01 hosts drwxr-xr-x. 3 root root 27 ene 31 19:09 roles

Cómo buena práctica, yo os recomiendo crearos dos directorios más y llamarlos inventory, para guar#VMwarePorvExperts

906

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

dar ficheros de inventario y playbooks, para guardar playbooks. [root@localhost ansible]# ll /etc/ansible/ total 24 -rw-r--r--. 1 root root 20276 ene 25 16:10 -rw-r--r--. 1 root root 1015 ene 25 17:01 drwxr-xr-x. 2 root root 36 ene 31 19:57 drwxr-xr-x. 2 root root 44 ene 31 19:08 drwxr-xr-x. 3 root root 27 ene 31 19:09

ansible.cfg hosts inventory playbooks roles

Ha llegado el momento de generar nuestra pareja de claves para desde el nodo de control, poder administrar otros servidores. Eso se hará con el comando ssh-keygen de la siguiente forma: [root@localhost ansible]# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/certificado Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/certificado. Your public key has been saved in /root/.ssh/certificado.pub. The key fingerprint is: SHA256:JEvMdbfL4rz5VAlkqdBtnxnw3Ux2+557eu69dVOYe54 [email protected] The key’s randomart image is: +---[RSA 2048]----+ | ....=o +| | o ....++o.=+| | = .. oo..=+| | . + .. o++.| | . S . o = o| | o . . oo| | o . .o=| | + oX| | o.. .EB| +----[SHA256]-----+ [root@localho

Una vez tengamos el par de claves generada, tendremos que copiarla en todos nuestros servidores que queramos controlar con Ansible. Como el libro está enfocado a VMware, vamos a ver como copiar la clave en el mismo servidor de Ansible y luego entramos en detalle con los ESXi.

#VMwarePorvExperts

907

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

[root@localhost ansible]# ssh-copy-id -i /root/.ssh/certificado certificado certificado.pub [root@localhost ansible]# ssh-copy-id -i /root/.ssh/certificado ansible-control-node /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/root/.ssh/certificado. pub” /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Number of key(s) added: 1 Now try logging into the machine, with: “ssh ‘ansible-control-node’” and check to make sure that only the key(s) you wanted were added. [root@localhost ansible]#

Ahora que ya tenemos las claves generadas y copiadas en el servidor que queremos controlar (como demo hemos metido a si mismo) podremos comprobar si realmente funciona. Para ello necesitaremos un inventario. Un inventario, es una lista de nodos accesibles por Ansible, es decir, que tienen ya la clave pública copiada. Este inventario se define en un fichero de configuración en formato INI y su ubicación predeterminada es /etc/ansible/hosts. Se puede utilizar perfectamente este fichero, pero lo recomendado es que nos creemos nuestros propios inventarios y los almacenemos en el directorio que hemos definido previamente para tal labor. Vamos a ser originales y vamos a crear el fichero /etc/ansible/inventory/servidores. [root@localhost ansible]# touch inventory/servidores [root@localhost ansible]# cat inventory/servidores ansible-control-node

He añadido el propio nodo de control que por DNS se resuelve como ansible-control-node. Este fichero de inventario puede tener también grupos de servidores [grupo] o incluso definir rangos esxi[01-10]. En el fichero predeterminado hosts encontraremos diferentes ejemplos. [root@localhost ansible]# vim hosts # This is the default ansible ‘hosts’ file. # # It should live in /etc/ansible/hosts # # - Comments begin with the ‘#’ character # - Blank lines are ignored # - Groups of hosts are delimited by [header] elements # - You can enter hostnames or ip addresses # - A hostname/ip can be a member of multiple groups

#VMwarePorvExperts

908

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

# Ex 1: Ungrouped hosts, specify before any group headers. ## ## ## ##

green.example.com blue.example.com 192.168.100.1 192.168.100.10

# Ex 2: A collection of hosts belonging to the ‘webservers’ group ## ## ## ## ##

[webservers] alpha.example.org beta.example.org 192.168.1.100 192.168.1.110

# If you have multiple hosts following a pattern you can specify # them like this: ## www[001:006].example.com # Ex 3: A collection of database servers in the ‘dbservers’ group ## ## ## ## ## ##

[dbservers] db01.intranet.mydomain.net db02.intranet.mydomain.net 10.25.1.56 10.25.1.57

# Here’s another example of host ranges, this time there are no # leading 0s: ## db-[99:101]-node.example.com

Ahora que ya tenemos las claves debidamente copiadas y un inventario valido, ha llegado el momento de comprobar si realmente ansible funciona y se puede conectar a un servidor remoto. El comando básico para hacer la comprobación ha sido siempre el ping, pero también podremos ejecutar otros comandos, por ejemplo, preguntar por la versión del SO. [root@localhost ansible]# ansible -m ping -i inventory/servidores all ansible-control-node | SUCCESS => { “changed”: false, “ping”: “pong” } [root@localhost ansible]# ansible -m shell -a “cat /etc/*-release” -i inventory/servidores all ansible-control-node | CHANGED | rc=0 >> CentOS Linux release 7.4.1708 (Core) NAME=”CentOS Linux” VERSION=”7 (Core)” ID=”centos” ID_LIKE=”rhel fedora”

#VMwarePorvExperts

909

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

VERSION_ID=”7” PRETTY_NAME=”CentOS Linux 7 (Core)” ANSI_COLOR=”0;31” CPE_NAME=”cpe:/o:centos:centos:7” HOME_URL=”https://www.centos.org/” BUG_REPORT_URL=”https://bugs.centos.org/” CENTOS_MANTISBT_PROJECT=”CentOS-7” CENTOS_MANTISBT_PROJECT_VERSION=”7” REDHAT_SUPPORT_PRODUCT=”centos” REDHAT_SUPPORT_PRODUCT_VERSION=”7” CentOS Linux release 7.4.1708 (Core) CentOS Linux release 7.4.1708 (Core)

#VMwarePorvExperts

910

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

7. Integración con vCenter y ESXi Antes de empezar a ejecutar playbooks de Ansible sobre nuestro vCenter o ESXi, hay algunas cosas que debemos hacer previamente.

Ansible proporciona una gran cantidad de módulos predefinidos para interactuar con vSphere, que se basan en “PyVmomi”, que no es más que la SDK de Python para la API de VMWare vSphere. Para instalar PyVmomi, utlizaremos el gestor pip, que previamente tendremos que instalar desde el repositorio EPEL: [root@localhost ansible]# yum -y install python-pip [root@localhost ansible]# pip install pyvmomi

Con eso hecho, ahora ya podremos usar Ansible para interactuar con vSphere. Para seguir un poco un orden y ya que hablamos del inventario anteriormente, vamos a crear un inventario para nuestros hosts ESXi: [root@localhost ansible]# vim inventory/ESXi [esxi:children] live test [live] esxi01.vmwareporvexperts.org esxi02.vmwareporvexperts.org esxi03.vmwareporvexperts.org

#VMwarePorvExperts

911

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

[test] esxi04.vmwareporvexperts.org esxi05.vmwareporvexperts.org

NOTA: Hemos creado un grupo llamado esxi que contiene 2 subgrupos, live y test. Cada uno de estos grupos contiene varios ESXi.

Si os acordáis, anteriormente generamos un par de claves ssh, pues bien, esa clave deberemos de copiarla en todos los ESXi que queramos manejar con Ansible con el siguiente comando: cat ~/.ssh/id_rsa.pub | ssh root@dbcesx01 ‘cat >> /etc/ssh/keys-root/authorized_keys’

[root@localhost ansible]# cat ~/.ssh/id_rsa.pub ‘cat >> /etc/ssh/keys-root/authorized_keys’ Password: [root@localhost ansible]# cat ~/.ssh/id_rsa.pub ‘cat >> /etc/ssh/keys-root/authorized_keys’ Password: [root@localhost ansible]# cat ~/.ssh/id_rsa.pub ‘cat >> /etc/ssh/keys-root/authorized_keys’ Password: [root@localhost ansible]# cat ~/.ssh/id_rsa.pub ‘cat >> /etc/ssh/keys-root/authorized_keys’ Password: [root@localhost ansible]# cat ~/.ssh/id_rsa.pub ‘cat >> /etc/ssh/keys-root/authorized_keys’ Password: [root@localhost ansible]#

| ssh [email protected] | ssh [email protected] | ssh [email protected] | ssh [email protected] | ssh [email protected]

Para comprobar que las claves están correctas y que nuestro inventario está bien definido, podremos ya ejecutar los primeros comandos contra nuestros ESXi. [root@localhost ansible]# ansible -m ping esxi02.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi04.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi05.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong”

#VMwarePorvExperts

-i inventory/ESXi all {

{

{

912

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

} esxi03.vmwareporvexperts.org | SUCCESS => { “changed”: false, “ping”: “pong” } esxi01.vmwareporvexperts.org | SUCCESS => { “changed”: false, “ping”: “pong” }

[root@localhost ansible]# ansible -m shell -a “vmware -vl” -i inventory/ESXi live esxi02.vmwareporvexperts.org | CHANGED | rc=0 >> VMware ESXi 6.7.0 build-11675023 VMware ESXi 6.7.0 Update 1 esxi03.vmwareporvexperts.org | CHANGED | rc=0 >> VMware ESXi 6.7.0 build-11675023 VMware ESXi 6.7.0 Update 1 esxi01.vmwareporvexperts.org | CHANGED | rc=0 >> VMware ESXi 6.7.0 build-11675023 VMware ESXi 6.7.0 Update 1 [root@localhost ansible]# ansible -m shell -a “vmware -vl” -i inventory/ESXi test esxi05.vmwareporvexperts.org | CHANGED | rc=0 >> VMware ESXi 6.7.0 build-11675023 VMware ESXi 6.7.0 Update 1 esxi04.vmwareporvexperts.org | CHANGED | rc=0 >> VMware ESXi 6.7.0 build-11675023 VMware ESXi 6.7.0 Update 1 Podreis encontrar más información en el portal oficial de Ansible:

#VMwarePorvExperts

913

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

8. Módulos ¿qué son? Los módulos, son considerados la unidad principal de trabajo en Ansible. Es el código que se ejecuta en el servidor administrado. Cada módulo es independiente de los demás y una de las principales características, es la idempotencia, es decir, una acción no se ejecutará más veces una vez alcanzado el estado deseado. Cada uno de estos módulos, devolverá datos en formato JSON, que será interpretado por Ansible y en caso necesario, podremos reutilizar esta información. Un ejemplo, sería el módulo para poner en modo mantenimiento un host ESXi: - name: Enter VSAN-Compliant Maintenance Mode vmware_maintenancemode: hostname: vc_host username: vc_user password: vc_pass esxi_hostname: esxi.host.example vsan: ensureObjectAccessibility evacuate: yes timeout: 3600 state: present

TIP: Encontrareis el directorio completo de módulos para VMWare en la siguiente URL: https://docs.ansible.com/ansible/2.5/modules/list_of_cloud_modules.html?highlight=vmware%20 modules

#VMwarePorvExperts

914

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

9. Tasks Para Ansible, una tarea es una acción que realizar, la ejecución de un módulo. Estas tareas, se pueden ejecutar en modo Ad-Hoc o mediante playbook. El modo ad-hoc nos permite ejecutar directamente comandos en una sola línea sobre nuestros hosts utilizando los módulos que ya tiene Ansible. Este modo se utiliza cuando queremos efectuar una acción simple sobre nuestros hosts, por ejemplo, realizar un ping. [root@localhost ansible]# ansible -m ping esxi02.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi01.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi05.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi04.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” } esxi03.vmwareporvexperts.org | SUCCESS => “changed”: false, “ping”: “pong” }

-i inventory/ESXi all {

{

{

{

{

La ejecución mediante playbook se haría con el comando ansible-playbook de la siguiente manera: [root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores --tags=maintenance PLAY [ansible-control-node] ********************************************************* ************************************************************************************** ************************************ TASK [Gathering Facts] *************************************************************** ************************************************************************************** *********************************** ok: [ansible-control-node] TASK [Enter host maintenance mode] *************************************************** ************************************************************************************** *********************************** changed: [ansible-control-node] PLAY RECAP *************************************************************************** **************************************************************************************

#VMwarePorvExperts

915

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

*********************************** ansible-control-node : ok=2

changed=1

unreachable=0

failed=0

En el siguiente capítulo hablaremos en detalle de los playbooks y cuál es su estructura.

#VMwarePorvExperts

916

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

10. Playbooks Los playbooks quizás son la parte más importante de Ansible, están escritos en YAML y son los ficheros donde describiremos todas las acciones a aplicar sobre nuestras máquinas. Están diseñados para ser fáciles de leer y gracias a la idempotencia, conseguiremos que las acciones descritas no se ejecuten más, una vez se ha llegado al estado deseado. En definitiva, un playbook es: •

Una lista de plays**

•

Cada play, debe contener: •

Hosts

•

Tasks/roles

Y para muestra, un botón…

A continuación, podéis ver la estructura real de un playbook: [root@localhost ansible]# vim playbooks/vmware.yml --- hosts: ansible-control-node connection: local vars: vcenter_hostname: 192.168.6.10 vcenter_username: miquel.mariano vcenter_password: Secret123! datacenter_name: VDC cluster_name: 01-ansible-cluster

#VMwarePorvExperts

917

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

esxi_hostname: esxi00 esxi_username: root esxi_password: Secret123! tasks: - name: Enter host maintenance mode vmware_maintenancemode: hostname: ‘{{ vcenter_hostname }}’ username: ‘{{ vcenter_username }}’ password: ‘{{ vcenter_password }}’ validate_certs: false esxi_hostname: esxi01 state: present tags: maintenance

#VMwarePorvExperts

918

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

11. Roles A medida que vamos añadiendo funcionalidad y complejidad a nuestros playbooks, cada vez se hace más difícil manejarlo con un solo fichero (playbook). Los roles, nos permiten crear estructuras más complejas y dotar de mayor lógica a nuestras operaciones. Según la propia documentación de Ansible: “Roles in Ansible build on the idea of include files and combine them to form clean, reusable abstractions – they allow you to focus more on the big picture and only dive down into the details when needed.” Para la correcta utilización de los roles, es necesario crear toda una estructura de carpetas y subcarpetas donde iremos depositando nuestra configuración. Tenemos dos opciones para crear estas carpetas, de forma manual o utilizando ansible-galaxy. Galaxy, es un repositorio público de roles que utiliza github como almacén de datos. Está pensado para que se pueden crear y compartir fácilmente nuestros roles. https://galaxy.ansible.com/

Para crear un role mediante ansible-galaxy, ejecutamos el siguiente comando dentro de /etc/ansible/ roles: [root@localhost ansible]# ansible-galaxy init roles/deploy_new_VM - roles/deploy_new_VM was created successfully

Y la estructura de carpetas que deberíamos ver seria la siguiente: [root@localhost ansible]# ll total 4 drwxr-xr-x. 2 root root 22 drwxr-xr-x. 2 root root 6 drwxr-xr-x. 2 root root 22 drwxr-xr-x. 2 root root 22 -rw-r--r--. 1 root root 1328 drwxr-xr-x. 2 root root 22 drwxr-xr-x. 2 root root 6 drwxr-xr-x. 2 root root 39 drwxr-xr-x. 2 root root 22

roles/deploy_new_VM/ ene ene ene ene ene ene ene ene ene

31 31 31 31 31 31 31 31 31

19:09 19:09 19:09 19:09 19:09 19:09 19:09 19:09 19:09

defaults files handlers meta README.md tasks templates tests vars

NOTA: Encontrareis una amplia explicación sobre los roles y playbooks en mi blog: https://miquelmariano.github.io/2017/04/roles-y-playbooks-Ansible

#VMwarePorvExperts

919

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

12. Casos de uso Llegados a este punto, estaréis de acuerdo conmigo que el potencial de Ansible para automatizar cualquier tipo de tarea, no solo VMware, es tremendamente alto. Cómo en este libro hemos intentado centrarnos en todo el ecosistema vSphere, vamos a ver algunas ideas para automatizar nuestro entorno vSphere. TIP: Os animo a que os paséis por la lista oficial de módulos para VMware y que vosotros mismos vayáis descubriendo todo lo que podéis hacer con ellos: https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html#vmware-cloud-modules

12.1 Crear un cluster y añadir hosts En este primer ejemplo básico veremos como a través de un playbook podremos crear un clúster y añadir sus correspondientes hosts ESXi. Finalmente, todos estos hosts nos aseguraremos de que están en modo mantenimiento. Ahí va el código: [root@localhost ansible]# vim playbooks/vmware.yml --- hosts: ansible-control-node connection: local vars: vcenter_hostname: 192.168.6.10 vcenter_username: miquel.mariano vcenter_password: Secret123! datacenter_name: VDC cluster_name: 01-ansible-cluster esxi_username: root esxi_password: Secret123! tasks: - name: Create Cluster local_action: module: vmware_cluster hostname: ‘{{ vcenter_hostname }}’ username: ‘{{ vcenter_username }}’ password: ‘{{ vcenter_password }}’ validate_certs: false datacenter_name: ‘{{ datacenter_name }}’ cluster_name: ‘{{ cluster_name }}’ enable_ha: yes enable_drs: yes enable_vsan: yes state: present

#VMwarePorvExperts

920

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

- name: Add ESXi Host to vCenter vmware_host: hostname: ‘{{ vcenter_hostname }}’ username: ‘{{ vcenter_username }}’ password: ‘{{ vcenter_password }}’ datacenter_name: ‘{{ datacenter_name }}’ cluster_name: ‘{{ cluster_name }}’ esxi_hostname: esxi0{{ item }} esxi_username: ‘{{ esxi_username }}’ esxi_password: ‘{{ esxi_password }}’ state: present validate_certs: false with_sequence: start=1 end=5 - name: Enter host maintenance mode vmware_maintenancemode: hostname: ‘{{ vcenter_hostname }}’ username: ‘{{ vcenter_username }}’ password: ‘{{ vcenter_password }}’ validate_certs: false esxi_hostname: esxi0{{ item }} state: present with_sequence: start=1 end=5

Si todo ha ido correcto, el resultado debería ser algo similar a esto: [root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores PLAY [ansible-control-node] ********************************************************* ************************************************************************************** ************************************ TASK [Gathering Facts] *************************************************************** ************************************************************************************** *********************************** ok: [ansible-control-node] TASK [Create Cluster] **************************************************************** ************************************************************************************** *********************************** changed: [ansible-control-node -> localhost] TASK [Add ESXi Host to vCenter] ****************************************************** ************************************************************************************** *********************************** changed: [ansible-control-node] => (item=1) changed: [ansible-control-node] => (item=2) changed: [ansible-control-node] => (item=3) changed: [ansible-control-node] => (item=4) changed: [ansible-control-node] => (item=5) TASK [Enter host maintenance mode] *************************************************** **************************************************************************************

#VMwarePorvExperts

921

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

*********************************** ok: [ansible-control-node] => (item=1) changed: [ansible-control-node] => (item=2) changed: [ansible-control-node] => (item=3) changed: [ansible-control-node] => (item=4) changed: [ansible-control-node] => (item=5) PLAY RECAP *************************************************************************** ************************************************************************************** *********************************** ansible-control-node : ok=4 changed=3 unreachable=0 failed=0 [root@localhost ansible]#

12.2 Configurar NTP y DNS En este caso, veremos cómo cambiar los NTP de nuestros servidores ESXi y a la vez cambiar tanto el hostname y la zona de búsqueda predeterminada, cómo los servidores DNS. Vamos a utilizar el mismo playbook anterior y a continuación le añadiremos el siguiente código: - name: Configure NTP vmware_host_ntp: hostname: ‘{{ vcenter_hostname username: ‘{{ vcenter_username password: ‘{{ vcenter_password validate_certs: false cluster_name: ‘{{ cluster_name state: present ntp_servers: - 0.pool.ntp.org - 1.pool.ntp.org delegate_to: localhost

#VMwarePorvExperts

}}’ }}’ }}’ }}’

922

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

tags: ntp - name: Configure ESXi hostname and DNS servers vmware_dns_config: hostname: esxi0{{ item }}.vmwareporvexperts.org username: ‘{{ esxi_username }}’ password: ‘{{ esxi_password }}’ validate_certs: false change_hostname_to: esxi0{{ item }} domainname: vmwareporvexperts.org dns_servers: - 8.8.8.8 - 8.8.4.4 with_sequence: start=1 end=5 delegate_to: localhost tags: dns

Veréis que en cada task le he añadido unas etiquetas “tag”. De esta manera, aunque sepamos que los módulos trabajan con idem potencia y las tareas anteriores de crear el clúster no se van a ejecutar, con las “tags” podremos centrar directamente la ejecución a lo que nos interese: [root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores --tags ntp,dns PLAY [ansible-control-node] ********************************************************* ************************************************************************************** ************************************ TASK [Gathering Facts] *************************************************************** ************************************************************************************** *********************************** ok: [ansible-control-node] TASK [Configure NTP] ****************************************************************** ************************************************************************************** ********************************** changed: [ansible-control-node -> localhost] TASK [Configure ESXi hostname and DNS servers] **************************************** ************************************************************************************** ********************************** changed: [ansible-control-node -> localhost] => (item=1) changed: [ansible-control-node -> localhost] => (item=2) changed: [ansible-control-node -> localhost] => (item=3) changed: [ansible-control-node -> localhost] => (item=4) changed: [ansible-control-node -> localhost] => (item=5) PLAY RECAP *************************************************************************** ************************************************************************************** *********************************** ansible-control-node : ok=3 changed=2 unreachable=0 failed=0 [root@localhost ansible]#

#VMwarePorvExperts

923

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

12.3 Crear VM Portgroups En esta ocasión, vamos a crear un VM portgroup en todos nuestros ESXi. Para ello, al igual que el ejemplo anterior, añadiremos el siguiente código al playbook y le añadiremos también una etiqueta: - name: Add PRODUCCION Network VM Portgroup vmware_portgroup: hostname: ‘{{ vcenter_hostname }}’ username: ‘{{ vcenter_username }}’ password: ‘{{ vcenter_password }}’ hosts: esxi0{{ item }} validate_certs: false switch_name: vSwitch0 portgroup_name: PRODUCCION vlan_id: 0 state: present with_sequence: start=1 end=5 delegate_to: localhost tags: vm-portgroup

#VMwarePorvExperts

924

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

Se ejecuta de la siguiente forma y el resultado sería: [root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores --tags vm-portgroup PLAY [ansible-control-node] ********************************************************* ************************************************************************************** ************************************ TASK [Gathering Facts] *************************************************************** ************************************************************************************** *********************************** ok: [ansible-control-node] TASK [Add PRODUCCION Network VM Portgroup] ******************************************* ************************************************************************************** *********************************** changed: [ansible-control-node -> localhost] => (item=1) changed: [ansible-control-node -> localhost] => (item=2) changed: [ansible-control-node -> localhost] => (item=3) changed: [ansible-control-node -> localhost] => (item=4) changed: [ansible-control-node -> localhost] => (item=5) PLAY RECAP *************************************************************************** ************************************************************************************** *********************************** ansible-control-node : ok=2 changed=1 unreachable=0 failed=0 [root@localhost ansible]#

#VMwarePorvExperts

925

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

12.4 Crear nueva VM En este último ejemplo, vamos ya a intentar hacer cosas realmente chulas, como por ejemplo, crear una VM en nuestra infraestructura totalmente funcional. Vamos a ello. Para empezar, crearemos un inventario que lo llamaremos vms-to-deploy que contendrá la siguiente información de las máquinas a desplegar: [grupo-test] test1 vm_ip=10.0.0.20 test2 vm_ip=10.0.0.21 [grupo-prueba] prueba1 vm_ip=20.0.0.20 prueba2 vm_ip=20.0.0.21 [grupo-prueba:vars] vc_datacenter=VDC vc_folder=/MIQUEL/VSAN/VMS/PRUEBA vc_cluster=Cluster-EVC vc_note=’Created by Ansible’ vm_datastore=HUS110_LUN0000 vm_networkportgroup=VLAN6_Formacion vm_networkdns1=192.168.6.100 vm_networkdns2=192.168.6.101 vm_networkmask=255.255.255.0 vm_networkgw=10.0.0.1 vm_memory=1024 vm_cpu=1 vm_disksize=20 [grupo-test:vars] vc_datacenter=VDC vc_folder=/MIQUEL/VSAN/VMS/TEST vc_cluster=Cluster-EVC vc_note=’Created by Ansible’ vm_datastore=HUS110_LUN0000 vm_networkportgroup=VLAN6_Formacion vm_networkdns1=192.168.6.100 vm_networkdns2=192.168.6.101 vm_networkmask=255.255.255.0 vm_networkgw=10.0.0.1 vm_memory=1024 vm_cpu=1 vm_disksize=20 [all:vars] vc_hostname=192.168.6.10 [email protected] vc_password=Secret123! vm_template=miquel-template-W2012R2-Std-ES dc_domain=vmwareporvexperts.local localadminpass=Secret123!

#VMwarePorvExperts

926

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

Posteriormente, con el módulo vmware_guest, vamos a crear el playbook deploy-vms.yml el cuan nos permitirá crear y customizar nuestras VMs a nuestro antojo: --- hosts: all gather_facts: false tasks: - name: Deploy VM windows from template and customize vmware_guest: hostname: “{{ vc_hostname }}” username: “{{ vc_username }}” password: “{{ vc_password }}” validate_certs: no datacenter: “{{ vc_datacenter }}” folder: “{{ vc_folder }}” cluster: “{{ vc_cluster }}” name: “{{ inventory_hostname }}” annotation: “{{ vc_note }}” state: poweredon disk: - size_gb: “{{ vm_disksize}}” type: thin datastore: “{{ vm_datastore }}” hardware: memory_mb: “{{ vm_memory }}” num_cpus: “{{ vm_cpu }}” scsi: paravirtual template: “{{ vm_template }}” networks: - name: “{{ vm_networkportgroup }}” ip: “{{ vm_ip }}” netmask: “{{ vm_networkmask }}” gateway: “{{ vm_networkgw }}” customization: hostname: “{{ inventory_hostname }}” autologon: true dns_servers: - “{{ vm_networkdns1 }}” - “{{ vm_networkdns2 }}” dns_suffix: “{{ dc_domain}}” password: “{{ localadminpass }}” delegate_to: localhost

Para finalizar, la ejecución del playbook, seria de la siguiente manera: [root@localhost ansible]# ansible-playbook playbooks/deploy-vms.yml -i inventory/vmsto-deploy PLAY [all] *************************************************************************** ************************************************************************************** ***********************************

#VMwarePorvExperts

927

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

TASK [Deploy VM windows from template and customize] ********************************* ************************************************************************************** *********************************** changed: [prueba1 -> localhost] changed: [prueba2 -> localhost] changed: [test2 -> localhost] changed: [test1 -> localhost] PLAY RECAP *************************************************************************** ************************************************************************************** *********************************** prueba1 : ok=1 changed=1 unreachable=0 failed=0 prueba2 : ok=1 changed=1 unreachable=0 failed=0 test1 : ok=1 changed=1 unreachable=0 failed=0 test2 : ok=1 changed=1 unreachable=0 failed=0

Y aquí veis el resultado:

#VMwarePorvExperts

928

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

13. ¿Por dónde empezar? Antes de terminar con el capítulo, me gustaría hacer una reflexión con todos vosotros. Últimamente, cuando hablo con alguien de automatización, durante la conversación siempre suele salir la misma pregunta. Vale Miquel, esto de automatizar está muy bien, pero ¿por dónde empezamos? Es la pregunta del millón y no tiene una respuesta fácil. Cada empresa tiene un montón de procedimientos y/o procesos y definir por dónde empezar es clave para no morir en el intento. Mi recomendación siempre es la misma. Hay que definir estos 3 grandes grupos:

•

Tareas repetitivas Aquellas tareas que realizamos muchas veces durante nuestra jornada laboral y que al fin y al cabo nos consumen mucho tiempo. Al ser tareas muy repetitivas, tendremos muy claro el proceso y posiblemente será muy fácil automatizarlo (P.E. Crear un usuario).

•

Tareas que nos consumen mucho tiempo No son tareas muy repetitivas, pero sí que al tener que realizarlas nos consumen bastante tiempo. Posiblemente tengamos que invertir tiempo en automatizar estas tareas, pero una vez conseguido, el ahorro de tiempo será muy grande, y podremos dedicarlo a automatizar más ;-) (P.E. Crear una VM).

•

Tareas o procesos críticos para negocio Aquellas actuaciones que tiene un impacto directo a negocio, ya sea porque hay que programar una ventana de parada o porque existe un riesgo de caída del sistema. Posiblemente todas estas tares lleven un gran tiempo de planificación y ejecución con el consiguiente riesgo de error humano. Automatizar todo esto no será tarea fácil, pero una vez conseguido tendremos la tranquilidad que cada vez que nos enfrentemos a esta tarea tendremos mayor probabilidad de éxito.

#VMwarePorvExperts

929

Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano

#VMwarePorvExperts

930

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

931

Capítulo 18 vSphere y Containers

Raúl Unzué

#VMwarePorvExperts

932

Capítulo 18 - vSphere y Containers Raúl Unzué

1. Introducción En la actualidad, las tecnologías de virtualización se han convertido en el paso natural para la evolución de los datacenters en medianas o grandes empresas. A su vez, dichas tecnologías de virtualización han evolucionado estos últimos años de forma exponencial, adaptándose a las nuevas arquitecturas y necesidades que van surgiendo. Una de esas evoluciones ha sido la implementación de virtualización basada en Contenedores. Estos facilitan una arquitectura de ejecución de aplicaciones como microservicios para la que la virtualización tradicional tenía ciertas limitaciones. La ventaja principal de los microservicios es que las empresas pueden desarrollar e implementar aplicaciones de una forma mucho más ágil. El mayor problema de migrar a este tipo de arquitecturas viene derivado de que hay que hacer algunos cambios en las prácticas existentes del personal IT. En este punto, es donde VMware se coloca como uno de los facilitadores del cambio. La tecnología de contenedores no es nueva, ya que, en 1979, el sistema operativo Unix en su versión 7, introdujo el sistema chroot, lo que permitía cambiar el directorio raíz de un proceso y sus hijos a una nueva ubicación.Tras varias evoluciones durante estas décadas, gran parte gracias a la comunidad Linux, ha sido el proyecto open source Docker, cuyo código fue liberado en 2013, el que ha conseguido explotar la popularidad de la que ahora gozan. Docker es un entorno de virtualización ligero que te permite construir y ejecutar aplicaciones dentro de un Contenedor de software aislado. Un Contenedor, es la unidad estándar de software que permite empaquetar el código, las configuraciones y todas sus dependencias en un único objeto, para que la aplicación o aplicaciones se ejecuten sobre un mismo núcleo de sistema operativo de una forma rápida, fiable y consistente.

Ilustración 1 - Arquitectura Containers

Una de las características de los Contenedores, que les han hecho ganar popularidad, es que se pueden implementar fácilmente en todo tipo de entornos, tanto Clouds Híbridas o Públicas como en cualquier instalación local. Es por ello que VMware es una de las empresas que más está apostando en ampliar su oferta en este punto, todo gracias a movimientos estratégicos centrados en mejorar su oferta On-Premise y su oferta Cloud, donde los Containers tienen mucho que decir. Ha constituido a través de su producto estrella, vSphere, un ecosistema vSphere+Contenedores con múltiples actores a su alrededor. Entre esos actores encontramos las tecnologías de orquestación,

#VMwarePorvExperts

933

Capítulo 18 - vSphere y Containers Raúl Unzué

los sistemas operativos dedicados, integradores, entornos Cloud y herramientas de monitorización y gestión. VMware Project Bonneville fue el proyecto que impulsó la integración con vSphere. Se basa en la API de Docker que permite alojar Contenedores como si fuesen máquinas virtuales dentro de vSphere. Para ello utiliza el sistema operativo Photon OS y la clonación instantánea de VMware. Photon OS es una distribución Linux creada por completo por VMware y que está optimizada para trabajar con su infraestructura, aplicaciones Cloud nativas, Contenedores e incluso con Kubernetes, ya que dispone de binarios nativos para su uso en el repositorio Photon. En la actualidad, VMware, está sumergida en soportar Kubernetes como tecnología de orquestación para Contenedores bajo el proyecto VMware Cloud PKS (Pivotal Container Service). Hay que destacar el proyecto de Kubernetes(K8S). Este fue diseñado inicialmente por Google y posteriormente donado a la Cloud Native Computing Foundation (CNCF), para la automatización de despliegues, el escalado y la gestión de aplicaciones contenerizadas.

Ilustración 2 – Logo Kubernetes

Kubernetes es la plataforma de referencia en la automatización de Contenedores, que permite simplificar la gestión de clústeres de grupos de hosts que los ejecutan. Su uso es fundamental para controlar el autoescalado y el despliegue de arquitecturas complejas formadas por varios contenedores.

La evolución, tanto de Kubernetes como de Contenedores, estos últimos años está siendo imparable, como demuestran las periódicas encuestas que realiza la Cloud Native Computing Foundation, de la que VMware es miembro Platinum como otros “grandes actores” (AWS, Cisco, Google Cloud, Microsoft Azure, RedHat, Dell…).

#VMwarePorvExperts

934

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 3 - CNCF Kubernetes

Antes de que empresas como VMware apostaran por los Contenedores y Kubernetes siempre ha existido el estigma de que eran plataformas que servían para Test o Desarrollo y que tenían bastantes limitaciones para gestionar las necesidades de entornos de Producción. Esto está cambiando progresivamente, como ya se está viendo en la evolución de Kubernetes en las empresas, donde ya se ha convertido en apuesta segura para sistemas de alta disponibilidad y computación de alto rendimiento. Hoy en día, gracias al uso de Kubernetes + Contenedores + vSphere, VMware dispone de los argumentos suficientes para que la adopción de las empresas en entornos productivos sea una garantía de éxito.

Ilustración 4 - CNCF Kubernetes Evolución Producción Los Contenedores han supuesto un cambio radical en la forma en la que construimos y desplegamos aplicaciones, en próximos apartados se verá que puede ofrecer VMware desde su perspectiva. Este esquema, que se irá desarrollando con los siguientes apartados, se puede ver las soluciones de las que dispone VMware:

#VMwarePorvExperts

935

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 5 - VMware Containers

 

#VMwarePorvExperts

936

Capítulo 18 - vSphere y Containers Raúl Unzué

2. Arquitectura Contenedores Para explicar la arquitectura de Contenedores en VMware, es necesario compararla con la de máquinas virtuales. La característica clave que distingue un Contenedor de una máquina virtual es la naturaleza efímera de este. En un sistema basado en Contenedores existen múltiples instancias de un contenedor. Estas pueden ser borradas o reemplazadas sin que el servicio se vea impactado. Algo que difícilmente podremos conseguir con máquinas virtuales sin un gasto excesivo de recursos. Incluso se puede dar el caso de tener diferentes versiones de estos coexistiendo. Teniendo en cuenta lo anterior se puede decir que son un sistema escalable, pudiendo variar la cantidad de contenedores en función de, por ejemplo, patrones de tráfico, ya sean autogenerándose o borrándose del sistema. Uno de los puntos que marca la diferencia entre las Máquinas Virtuales y los Contenedores es la forma en la que cada capa de virtualización utiliza los recursos de la máquina. Dicho de otra forma, mientras que el hypervisor abstrae el sistema operativo de la máquina virtual del hardware subyacente, el motor de contenedores abstrae la aplicación del contenedor del sistema operativo subyacente.

Ilustración 2 - Virtual Machine vs Containers

Lo que ha logrado VMware es unir los beneficios de ambas tecnologías a través de vSphere.

 

#VMwarePorvExperts

937

Capítulo 18 - vSphere y Containers Raúl Unzué

3. Beneficios Contenedores en VMware Las características más importantes de implementar los Contenedores sobre una infraestructura VMware son: •

Es el propio vSphere el que ejecuta los Contenedores y no Linux como en otras distribuciones.

•

Los Contenedores no se despliegan dentro de otras máquinas virtuales, si no que dentro de vSphere los Contenedores son propiamente máquinas virtuales.

•

Todos los datos (volúmenes, imágenes y Contenedores) se almacenan directamente, por ejemplo, en los datastores VMFS presentados en los ESXi.

•

Toda la infraestructura hardware y de red es proporcionada por vSphere.

•

Los Contenedores permanecen totalmente aislados tanto del host como de otros Contenedores.

#VMwarePorvExperts

938

Capítulo 18 - vSphere y Containers Raúl Unzué

4. vSphere Integrated Containers VMware vSphere Integrated Containers (VIC) es una plataforma que permite administrar e implementar Contenedores dentro de vSphere compatible desde la versión 6.x y posteriores. La implementación se realiza mediante un appliance basado en la distribución Linux desarrollada por VMware, Photon OS, que se puede encontrar en todos los appliance actuales basados en Linux que distribuye VMware. Se trata de un proyecto de código abierto, con lo que se pone en mano de la comunidad los diferentes componentes de la solución. Al ser una solución open source, no conlleva un sobrecoste su implantación en una infraestructura vSphere.

Aunque su implantación no tiene sobrecoste, si queremos disponer de soporte por parte de VMware, necesitaremos una licencia Enterprise Plus. Adicionalmente, es necesario disponer de switches distribuidos para su implantación, que sólo están disponibles a partir de la licencia Enterprise Plus.

Ilustración 3 - vSphere Integrated Containers

Básicamente dispone de 4 componentes principales: •

vSphere Integrated Containers Management Portal: se trata del dashboard que da acceso a gestionar los diferentes Contenedores, crear los proyectos asociados, configurar el networking, entre otras tareas.

•

vSphere Integrated Containers Registry: nos permite almacenar y distribuir las imágenes de los Contenedores que vamos a utilizar.

•

vSphere Integrated Containers Engine: incluye el componente vic-machine que permite el despliegue de los hosts VCH (Virtual Container Host) y con ello la ejecución de los Contenedores sobre los hosts VMware ESXi.

•

vSphere Integrated Containers Plug-In for vSphere Client: permite la gestión y creación de los hosts VCH desde vSphere. Existen dos versiones del Plug-In tanto para la consola Flash como la HTML5. En las últimas versiones se instala automáticamente en el procedimiento de despliegue de VIC y se actualiza automáticamente al hacer un upgrade la plataforma.

#VMwarePorvExperts

939

Capítulo 18 - vSphere y Containers Raúl Unzué

4.1 Otros Componentes en VIC •

vSphere Integrated Containers Appliance: como ya hemos comentado, es el Appliance que proporciona los servicios de Management Portal (Dashboard) y Registry. A su vez es fundamental para desplegar el resto de los componentes.

•

Virtual Container Host (VCH): es un nuevo concepto que introduce VMware vSphere Integrated Containers, que permite representar los recursos de CPU, RAM y almacenamiento que se van a asignar dentro de la plataforma de vCenter, y a su vez, da acceso a la API de Docker y a las imágenes de Docker Hub para la creación de Containers. Cuando se lanza la creación de un container se ejecuta una máquina virtual liviana que reside dentro del VCH. De tal forma, que los VCH pueden contener múltiples máquinas virtuales livianas y varias instancias de contenedores individuales. A su vez almacenan las imágenes de los Contenedoresdescargadas. Se pueden generar varios VCH dentro del mismo vCenter, y esta tarea se realiza desde un plugin personalizado que en las últimas versiones de VIC se instala automáticamente en vCenter al desplegar VIC.

En la siguiente figura se puede comparar cómo se comporta una infraestructura tradicional de Docker Containers Hosts y como trabaja Virtual Container Hosts, que es capaz de proveer Containers Docker nativos como hemos hablado:

Ilustración 4 – Virtual Container Host

4.2 Networking VIC

#VMwarePorvExperts

940

Capítulo 18 - vSphere y Containers Raúl Unzué

Uno de los puntos más complejos en toda infraestructura basada en Contenedores es el Networking. Por ello vamos a intentar explicar en un alto nivel como es el Networking sobre Docker y posteriormente analizamos como se implementa sobre VIC. Cuando se instala Docker en un host se crean varias interfaces: •

Bridge: Es la red por defecto, esta configuración la tendrán todos los Contenedores salvo que indiquemos lo contrario en su creación. Es un puente al interfaz docker0.

•

Host: Como su propio nombre indica, se refiere a los interfaces del host, y todas las interfaces tendrán acceso.

•

None: Será todo Docker aislado, sin interfaz de red.

Este sería un esquema común en un servidor Docker:

Ilustración 9 – Esquema común Docker

Cuando quieres que el servicio que ejecuta un Container se comparta con otras redes, por ejemplo Internet, se realiza una exposición de puertos a través del host anfitrión. Redirigiendo el puerto expuesto en el host al del Container.

VMware ha intentado simplificar esta configuración de forma que puedes usar switches distribuidos o NSX para poder implementarla y securizarla con toda la infraestructura de vSphere, y a su vez uniendo la red lógica y la red física. Se puede redirigir el tráfico entre Contenedores, el propio VCH, hacia Internet o entre las diferentes redes que existen dentro de vSphere. Los Containers pueden publicar servicios de red mediante NAT (Network Address Translation) de la interfaz Public que se define al generar el VCH.

#VMwarePorvExperts

941

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 10 – Esquema conexión lógico

La siguiente imagen detalla los puertos y protocolos que intervienen en la comunicación en una infraestructura VIC y que habrá que tener en cuenta en cualquier diseño:

Ilustración 11 – Esquema puertos utilizados por componentes

A continuación, detallamos los puertos que intervienen entre los diferentes componentes:

#VMwarePorvExperts

942

Capítulo 18 - vSphere y Containers Raúl Unzué

vSphere Integrated Containers Protocolo

Puerto

HTTPS / TCP

443

HTTPS / TCP

4443

HTTPS / TCP

8282

HTTPS / TCP

8443

HTTPS / TCP

9443

Descripción

Se utiliza para conexiones desde los clientes Docker, vSphere Integrated Containers Management Portal o VCH a vSphere Integrated Containers Registry

Se utiliza para conexiones al servicio Docker Content Trust para vSphere Integrated Containers Registry

Es la conexión por defecto a vSphere Integrated Containers Management Portal UI y API Se utiliza para conexiones al servicio de VIC, que permite crear VCH´s a través del plugin de la consola HTML5 de vSphere Client

Se utiliza para la conexión a la página Getting Started del appliance VIC. Que dispone de un enlace a Management Portal o descargar vSphere Integrated Engine bundle, por ejemplo

Hosts ESXi Protocolo

Puerto

TCP

2377

HTTPS / TCP

443

Descripción

Es necesario para implementar VCH´s en el host ESXi. Se utiliza para conexiones salientes entre la máquina final y el shell del Container Es necesario para implementar VCH´s en el host ESXi. Se utiliza para conexiones entrantes de carga o descarga desde los Datastores

Red Bridge Protocolo TCP

Puerto 53

Descripción

Es necesario para que los VCH´s dispongan de resolución de nombres y conecten con los DNS´s de la infraestructura

Red Clientes Protocolo

Puerto

Descripción

SSH / TCP

22

Conexiones al VCH cuando se usa el modo debug

HTTPS / TCP

2376

Puerto seguro de acceso a la API de Docker

HTTP / TCP

2375

HTTPS / TCP

2378

HTTPS / TCP

6060

Puerto no seguro de acceso a la API de Docker

Conexiones al portal de administración del VCH

Los Contenedores no exponen ningún puerto por defecto, si necesitamos hacer debug sobre ellos, hay que generar el VCH con el comando --debug

Red de Gestión Protocolo

TCP

HTTPS / TCP

#VMwarePorvExperts

Puerto

2377 443

Descripción

Conexiones entrantes de los Contenedores al VCH

Conexiones salientes desde el VCH a los hosts ESXi y al vCenter Server

943

Capítulo 18 - vSphere y Containers Raúl Unzué

Red Containers Protocolo HTTPS / TCP

Puerto 6060

Descripción

Los Contenedores no exponen ningún puerto por defecto, si necesitamos hacer debug sobre ellos, hay que generar el VCH con el comando --debug

4.3 Copia de Seguridad de VIC

LINK REFERENCIA: https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/backup_vic.html

Cuando añades vSphere Integrated Containers a tu infraestructura vSphere, te das cuenta que el resto de componentes como VCH´s, Contenedores,…surgen en una unión entorno al appliance de VIC. Tal y como se ha comentado anteriormente, los Contenedores dentro de vSphere son realmente máquinas virtuales, es importante tener en cuenta ciertos detalles para crear copias de seguridad de todos los componentes sin pérdida de información. Lo primero que tiene que quedar claro, es que la naturaleza, por regla general, de un Contenedor, es efimera, , con lo que no es un elemento adecuado para generar copias de seguridad, simplemente por esa naturaleza. En cambio, dentro de una infraestructura de Contenedores sobre VMware no todos los elementos son efímeros. Si disponéis de datos como bases de datos, la información que contienen, no pueden ser datos efímeros. Para ello se asocian volúmenes a estos de tal forma que los datos persistan en el tiempo. Los principales componentes que deberemos tener en cuenta para hacer copias de seguridad son: •

Los volúmenes enlazados a los Contenedores. Todo dato persistente dentro de un volumen asociado a un Contenedor puede hacerse “copia de seguridad”, tanto en forma de Snapshot** como clonado, sólo si el Contenedor no se está ejecutando. VIC soporta volúmenes en formato tanto NFS como VMFS así que habría que trabajar con herramientas de copias de seguridad que soporten estos formatos, bastante estándares actualmente.

•

vSphere Integrated Containers Management Portal almacena los proyectos y los usuarios. Se pueden hacer “copias de seguridad” mediante clonado de la máquina virtual. Además, se puedem realizar Snapshot** como si fuese un clonado de máquina virtual.

•

vSphere Integrated Containers Registry los datos de imágenes. Y también podemos hacer “copias de seguridad” tanto en forma de Snapshot** como con un clonado de máquina virtual. ** Aunque hablamos de hacer copias de seguridad con Snapshots, no debe tomarse un Snapshot como referencia para realizar copias de seguridad. Ya que un Snapshot es una imagen en el tiempo en un punto concreto del sistema y no una copia de seguridad al uso.**

#VMwarePorvExperts

944

Capítulo 18 - vSphere y Containers Raúl Unzué

Por otra parte, el propio appliance VIC debe tener su copia de seguridad como máquina virtual dentro de la infraestructura. Tal y como está diseñado, nos encontramos con 4 discos por defecto:

Ilustración 11 – Discos vSphere Integrated Containers

VMware lo ha diseñado de esa forma, porque cada disco tiene su funcionalidad específica que ahora detallamos: Disco

Punto de montaje

Disco 1

/

Disco 2

/storage/data

Disco 3

/storage/db

Disco 4

/storage/log

Descripción

En la raíz encontraremos el sistema operative y el estado de la aplicación. Mapeado en SCSI 0:0

Diferentes datos y la instancia VIC Registry. Mapeado en SCSI 0:1

Contiene la base de datos MySQL, Clair y Notary para VIC Registry. Mapeado en SCSI 0:2

Se almacenan los logs de los diferentes componentes. Mapeado en SCSI 0:3

Este diseño nos permite restaurar la máquina virtual VIC desde un Snapshot o simplemente recuperar un VMDK concreto de uno de nuestros discos para poder levantar el sistema ante una incidencia concreta.

4.4 Seguridad en VIC

LINK REFERENCIA: https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/security_reference. html

Una de las ventajas de implementar vSphere Integrated Containers es que a nivel de seguridad vamos

#VMwarePorvExperts

945

Capítulo 18 - vSphere y Containers Raúl Unzué

a encontrarnos un producto integrado en vSphere y que va a aprovechar funciones ya implementadas en otros productos de VMware. Cuando instalamos vSphere Integrated Containers no vamos a generar nuevos usuarios, ni cuentas de servicio o permisos adicionales que otra máquina del sistema. De hecho, se reutilizan las cuentas de usuario ya generadas previamente en vSphere. Teniendo la posibilidad de generar cuentas de usuario para que accedan, dependiendo del perfil que queramos dar, al VIC Management Portal. Por ejemplo, un proyecto en el que hay un desarrollador externo que trabajará temporalmente sobre la plataforma y no necesita permisos adicionales. La implementación es muy sencilla, se pueden usar usuarios locales o utilizar toda la potencia de LDAP o Active Directory:

Ilustración 12 – Agregar usuarios y grupos proyecto

Adicionalmente, vSphere Integrated Containers asegura las conexiones entre sus diferentes componentes, con la infraestructura de vSphere y el entorno Docker, mediante el uso de certificados TLS. Estos certificados pueden ser personalizados por cada administrador, o pueden autogenerarse. A continuación, explicamos el esquema de los certificados usados por los distintos componentes de VIC:

Ilustración 13 – Certificados en VIC

#VMwarePorvExperts

946

Capítulo 18 - vSphere y Containers Raúl Unzué

4.5 Servicios en VIC

LINK REFERENCIA: https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/service_status.html

Existen varios servicios que nos pueden dar alguna pista en nuestro appliance VIC y que podemos comprobar o verificar su estado conectándonos a VIC vía SSH. Estos son los servicios que verificar: •

harbor.service → vSphere Integrated Containers Registry

•

admiral.service → vSphere Integrated Containers Management Portal

•

fileserver.service → Servidor de ficheros integrado en VIC

•

vic-machine-server → Que nos permite crear los VCH´s a través del plugin HTML5 en vCenter

Como hemos dicho los podemos comprobar vía SSH de la siguiente forma: systemctl status harbor.service systemctl status admiral.service systemctl status fileserver.service systemctl status vic-machine-server.service

Y puede haber tres tipos de resultados: Estado active (running) inactive (failed) inactive (dead)

Descripción El servicio se está ejecutando correctamente El servicio no se pudo iniciar. El servicio no está respondiendo.

Una muestra del estado de un servicio:

#VMwarePorvExperts

947

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 14 – Servicios VIC

Para reiniciar cada componente utilizaríamos el parámetro restart en cada comando.

#VMwarePorvExperts

948

Capítulo 18 - vSphere y Containers Raúl Unzué

5. VMware Clouds PKS Presentada en un principio en el VMware World 2017 US, VMware Cloud Pivotal Container Service (PKS) se trata de una solución de contenedores basada en Kubernetes. En un principio fue desarrollada por Pivotal Software y VMware, en colaboración con Google Cloud (Kubernetes). Pivotal Container Service es la solución de VMware para sus servicios de Contenedores en su Infraestructura Cloud. VMware Cloud PKS es un servicio en la nube de VMware que proporciona Kubernetes como servicio.

5.1 ¿Qué es VMware PKS? VMware Pivotal Container Service (PKS) es una solución de contenedores basada en Kubernetes (de ahí la “K”), completamente lista para ser puesta en producción, equipada con una gestión de red avanzada, un registro privado de Contenedores y una gestión completa del ciclo de vida. PKS simplifica radicalmente la implementación y el funcionamiento de los clústeres de Kubernetes para poder ejecutar y gestionar Contenedores a escala en nubes privadas y públicas. A nivel de red, por ejemplo, una sola instancia de VMware NSX-T puede admitir múltiples enrutadores de nivel 0, que se convierten en una pasarela entre las redes lógicas y las físicas. Con esto, cualquier organización puede obtener un mayor aislamiento y control de la red. Por ejemplo, es posible utilizar direcciones IPs superpuestas dentro de la misma infraestructura. PKS es la versión comercial de KUBO, y está estrechamente integrada con otras soluciones como Google Container Service (GKE), vSphere, VMware vCloud o VMware NSX para gestionar la seguridad y la red de los Contenedores. De hecho, PKS es una solución multi-cloud siendo ya en su versión 1.3 compatible las plataformas más importantes como son VMware vSphere, Microsoft Azure, Google Cloud Platform y Amazon EC2. Todo ello desde una interfaz común.

5.2 Componentes VMware PKS •

VMware Harbor: es la solución que ha desarrollado VMware para registrar imágenes de contenedores y que utilizan PKS como VIC. Recientemente el proyecto ha sido entregado a la CNCF, y gracias al impulso de la comunidad open source, se integra con proyectos como CoreOS/RedHat Clair que permite escanear las imágenes en búsqueda de problemas de seguridad o Notary, que permite firmar las imágenes de los Contenedores.

Ilustración 15 – VMware Harbor

#VMwarePorvExperts

949

Capítulo 18 - vSphere y Containers Raúl Unzué

•

Bosh: es un proyecto opensource en el que han contribuido empresas como VMware, Google y Pivotal para implementar Cloud Foundry PaaS, aunque se puede implementar en infraestructuras IaaS para casi cualquier software como VMware vSphere o vCloud, incluso en otras plataformas como Microsoft Azure, AWS EC2, Google Compute Platform u Openstack entre otras. Realiza desde aprovisionamiento, monitoreo, recuperación y actualizaciones de software…ayudando a gestionar el ciclo de vida del software tanto en nubes pequeñas como a gran escala. BOSH en Kubernetes o KUBO es el núcleo o corazón de PKS, siendo la herramienta de implementación de Cloud Foundry. Es el primer componente que se instala en cualquier plataforma Cloud Foundry.

Ilustración 16 – Cloud Foundry Bosh

•

Google Cloud Platform (GCP) Service Broker: proyecto opensource que simplifica la entrega de servicios a aplicaciones que se ejecutan en Kubernetes. Se basa en la implementación de la API Open Service Broker (OSB).

Ilustración 17 – Google Cloud Platform

•

Cloud Foundry: una arquitectura Cloud Foundry está basada en Contenedores que ejecutan aplicaciones independientemente de la programación usada. Para dar soporte a recursos externos también utiliza la API OSB. La premisa es que se puede separar las aplicaciones de la infraestructura utilizada y ser compatible con cualquier tecnología o herramienta que se utilice (Docker, Kubernetes, .NET, Java, …).

Ilustración 18 – Cloud Foundry

En el dibujo podéis ver como interactúa cada componente dentro de la infraestructura PKS.

#VMwarePorvExperts

950

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 19 – Pivotal Container Service  

#VMwarePorvExperts

951

Capítulo 18 - vSphere y Containers Raúl Unzué

6. Casos prácticos En este apartado vamos a mostraros como configurar un entorno de Contenedores en un vCenter OnPremise y un ejemplo Cloud con PKS.

6.1 Requisitos On-Premise Hay que cumplir unos requisitos básicos en los hosts antes de empezar la práctica: LINK REFERENCIA: https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/vi_reqs.html

•

Licencias Enterprise Plus en los hosts

•

Switches distribuidos configurados en host ESXi, con un grupo de puertos para Bridge y otro como Public:

Ilustración 20 – Distributed Switch

•

•

vSphere Integrated Containers Appliance •

vCenter Server 6.0, 6.5, or 6.7

•

ESXi 6.0, 6.5, o 6.7 para todos los hosts

•

Al menos 2 vCPUs

•

Al menos 8GB de RAM

•

Al menos 80GB de disco en Thin Provisioning

Para la gestión se utiliza el vSphere Client en HTML5. La versión Flash tiene limitaciones y tenderá a desaparecer.

 

#VMwarePorvExperts

952

Capítulo 18 - vSphere y Containers Raúl Unzué

6.2 Instalación VIC El primer paso es descargar la OVA desde My Vmware:

Ilustración 21 – My VMware

Cargamos el fichero “Implementar plantilla de OVF”, elegimos red, storage y contraseña para la gestión en los diferentes pasos:

Ilustración 22 – Plantilla OVF

Habilitamos la regla en el firewall de los hosts ESXi desde “Configurar -> Sistema -> Firewall” al puerto TCP 2377:

#VMwarePorvExperts

953

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 23 – Firewall ESXi

Arrancamos la máquina virtual generada, que como se aprecia dispone de un icono diferente:

Ilustración 24 – VIC

Abrimos una consola de la máquina virtual para saber la IP y nos conectamos vía Web. Y realizamos la primera conexión a nuestro vCenter como post-instalación:

#VMwarePorvExperts

954

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 25 – VIC conexión vCenter Server

6.3 Crear VCH Una vez instalado VIC y su plugin en vCenter dispondremos de un nuevo menú, pulsamos sobre “Menú -> vSphere Integrated Containers”

Ilustración 26 – Plugin VIC

#VMwarePorvExperts

955

Capítulo 18 - vSphere y Containers Raúl Unzué

Pulsamos nuevamente sobre vSphere Integrated Containers:

Ilustración 27 – vSphere Integrated Containers

Pulsamos sobre “New Virtual Container Host”:

Ilustración 28 – New Virtual Container Host

Le damos un nombre significativo a nuestro VCH y a los Contenedores que generaremos desde él:

#VMwarePorvExperts

956

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 29 – Create Virtual Container Host

Seleccionamos un recurso de nuestro Datacenter y pulsamos “Next”:

Ilustración 30 – Compute Capacity

Elegimos Datastore, es buena práctica crear una carpeta para VCH y así tener una mejor gestión. Adicionalmente, según nuestra necesidad elegiremos el tamaño en disco de los Contenedores:

#VMwarePorvExperts

957

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 31 – Storage Capacity

Elegimos el grupo de puertos que hemos preparado previamente como Bridge y Public. Podemos modificar el rango de red con que nos queremos mover:

Ilustración 32 – Networks

Podemos definir si los clientes necesitan certificados para conectarse a los Contenedores:

#VMwarePorvExperts

958

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 33 – Certificates

Una buena práctica, es crear una lista blanca o Whitelist de acceso:

Ilustración 33 – Registry Access

Marcaríamos la casilla y añadiríamos los wildcard domain, CIDR o IP/FQDN que queramos considerar en la Whitelist:

#VMwarePorvExperts

959

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 34 – Registry Access

Introducimos los datos para gestionar vSphere:

Ilustración 35 – Operations User

Pulsamos Finish. Si más adelante queréis repetir los pasos, podéis guardar la configuración en un solo comando que podréis encontrar en la parte inferior de la sección Summary:

#VMwarePorvExperts

960

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 36 – Summary

En unos minutos dispondremos de nuestro Virtual Container Host:

Ilustración 37 – Virtual Container Hosts

En pocos minutos dispondremos de la IP para su gestión, escuchando en dos puertos, uno para Docker API Endpoint y otro VCH Admin Portal:

Ilustración 38 – Docker API

Y dispondremos de un nuevo elemento en la vista de hosts. Seremos capaces de gestionar los VCH´s como los Contenedores porque se generan bajo una vApp:

#VMwarePorvExperts

961

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 39 – VCH

Ahora necesitamos agregarlo desde el dashboard de VIC para poder utilizarlo en la creación de Contenedores:

Ilustración 40 – Host de contenedor

Introducimos el puerto y la IP para Docker API Endpoint:

#VMwarePorvExperts

962

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 41 – URL Host de contenedor

Verificamos que la conexión es válida:

Ilustración 42 – Verificar Certificado

Si todo es correcto aparecerá como CONECTADO:

Ilustración 43 – Conectado

#VMwarePorvExperts

963

Capítulo 18 - vSphere y Containers Raúl Unzué

Podemos aprovisionar Contenedores desde el repositorio oficial. Desde Biblioteca -> Todos los repositorios -> Repositorios. Desplegamos el botón Aprovisionar y pulsamos Introducir información adicional.

Ilustración 44 – Introducir información adicional

Rellenamos en el campo Red el puerto que quedará expuesto y también el puerto donde escuchará el Contenedor:

Ilustración 45 – Aprovisionar un contenedor

El tiempo de ejecución del trabajo dependerá de vuestra infraestructura, pero es una cuestión de segundos:

Ilustración 46 – Solicitudes

#VMwarePorvExperts

964

Capítulo 18 - vSphere y Containers Raúl Unzué

Del Container aprovisionado se generará una máquina virtual que veremos en la vista Hosts y clústeres de nuestro vCenter dentro de nuestro VCH:

Ilustración 47 – Containers aprovisionados

Y también en la sección Contenedores de VIC que es donde hay que gestionarlo:

Ilustración 48 – Contenedores

La IP del Contenedor es del rango en modo Bridge definido en el Port Group del VCH.

Ilustración 49 – Modo Bridge

#VMwarePorvExperts

965

Capítulo 18 - vSphere y Containers Raúl Unzué

Siendo la puerta de enlace de dicha red el propio VCH:

Ilustración 50 – Conectado

A través de la puerta de enlace que es el VCH y mediante NAT nuestro Contenedor está dando el servicio por el puerto fijado, en este caso TCP 8080:

Ilustración 51 – Container Nginx

Podréis encontrar más información sobre todos los Contenedores creados desde el “Menú de vuestro vCenter -> vSphere Integrated Containers”. Se puede ver el estado, ubicación o puertos donde trabaja:

Ilustración 52 – Conectado

#VMwarePorvExperts

966

Capítulo 18 - vSphere y Containers Raúl Unzué

Si queremos Clusterizar el Contenedor desde el dashboard de VIC podemos pulsar en la sección “Contenedores -> Seleccionamos Contenedor -> Escala”.

Ilustración 53 – Escala

Esto no funciona cuando has fijado el puerto, si no hay hosts libres:

Ilustración 54 – Failed (ERROR)

En unos segundos se generará un Contenedor en paralelo y en vSphere otra máquina virtual:

#VMwarePorvExperts

967

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 55 – Conectado

Si queremos parar o eliminar un Contenedor lo deberemos hacer desde la consola de VIC seleccionando el Contenedor o los Contenedores sobre los que queremos hacer la acción:

Ilustración 56 – Eliminar o parar Container

Se pueden desplegar varios Contenedores mediante una Plantilla generada vía gráfica o mediante ficheros YML:

Ilustración 57 – Plantillas

Pulsamos “Importar Plantilla” y copiamos el contenido del fichero YML:

#VMwarePorvExperts

968

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 58 – Importar plantilla

6.4 Ejemplo fichero YML En este ejemplo, vamos a generar varios Contenedores anidados para generar un sencillo Wordpress con Mysql: version: ‘2’ services: db: image: mysql:5.7 command: --datadir=/var/lib/mysql/data volumes: - db-data:/var/lib/mysql networks: - db-net environment: MYSQL_ROOT_PASSWORD: librovmwarewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on: - db image: wordpress:latest ports: - “8081:80” volumes:

#VMwarePorvExperts

969

Capítulo 18 - vSphere y Containers Raúl Unzué

- html-data:/var/www/html networks: - web-net - db-net environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress volumes: db-data: driver: “vsphere” driver_opts: Capacity: “4G” VolumeStore: “backed-up-encrypted” html-data: driver: “vsphere” driver_opts: Capacity: “2G” VolumeStore: “default” networks: web-net: db-net: internal: true

6.5 Upgrade VIC A continuación, vamos a detallar el procedimiento para hacer un Upgrade de vuestro vSphere Integrated Containers. Antes de empezar, este procedimiento no debería dejar sin conexión a los VCH y los Contenedores si hemos implementado bien la red. La idea es generar un nuevo VIC en paralelo y migrar los datos, Contenedores y VCH´s al nuevo. Lo primero es bajar el OVA de la nueva versión y cargarla, siguiente el procedimiento de instalación de VIC. Evitaríamos colocar la misma IP que el anterior appliance:

#VMwarePorvExperts

970

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 59 – Cargar OVA VIC

Para actualizar nuestro VMware VIC tendremos que acceder vía SSH al Appliance creado:

Ilustración 60 – IP VIC

Abrimos una consola:

Ilustración 61 – SSH

Utilizamos la contraseña de root:

#VMwarePorvExperts

971

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 62 – SSH

Una vez conectados, nos desplazamos al directorio y lanzamos el comando. Destroy es sólo por eliminar lo antiguo en este paso:

Ilustración 63 – Upgrade.sh

Comienza el proceso de Upgrade, donde podéis ver las respuestas:

#VMwarePorvExperts

972

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 64 – Upgrade.sh

Si no se coloca el parámetro Destroy hay que apagar y eliminar el antiguo a mano:

Ilustración 65 – VIC Destroy

En este momento ya estarán migrados todos los proyectos, VCH´s y Contenedores. Para que los cambios sean efectivos a nivel de vCenter, necesitaremos reiniciar el plugin HTML5 mediante estos comandos vía SSH al vCenter:

#VMwarePorvExperts

973

Capítulo 18 - vSphere y Containers Raúl Unzué

service-control --stop vsphere-ui && service-control --start vsphere-ui service-control --stop vsphere-ui && service-control --start vsphere-ui service-control --stop vsphere-client && service-control --start vsphere-client

Parámetros adicionales que podemos añadir al comando upgrade:

Ilustración 66 – VIC Destroy  

6.6 Desinstalar Plugin VIC En este procedimiento os vamos a explicar cómo desinstalar el plugin vSphere Integrated Containers:

Ilustración 67 – Plugin VIC

Iremos a la siguiente URL, introducís las credenciales de administrador y pulsáis en la parte inferior “void -> UnregisterExtension”: https://vCenter_IP/mob/?moid=ExtensionManager

#VMwarePorvExperts

974

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 68 – Managed Object Type

Introducís el valor com.vmware.vic (también com.vmware.vic.ui) y pulsáis “Invoke Method”. Tenéis que aseguraros que no sale error y sólo muestra void:

Ilustración 69 – Method Invocation Result

6.7 Ejemplo PKS Os vamos a mostrar un ejemplo de laboratorio generado en uno de los Workshop del VMware World 2018 de Barcelona y que os dejo el enlace al código en github: LINK REFERENCIA: https://github.com/Boskey/run_kubernetes_with_vmware/wiki

Es importante que la máquina cliente desde donde os vais a conectar, disponga de VKE CLI y Kubectl, en próximos puntos veremos el enlace de descarga, disponible tanto para MacOS, Windows o Linux. Para poder trabajar con VMware Cloud PKS (Vmware Kubernetes Engine (VKE)), deberemos generar una cuenta desde el siguiente enlace o disponer de una previa en My VMware:

#VMwarePorvExperts

975

Capítulo 18 - vSphere y Containers Raúl Unzué

https://console.cloud.vmware.com/csp/gateway/discovery

Una vez creada nos logueamos con nuestro usuario / contraseña:

Ilustración 70 – VMware Cloud Services

Tendríamos que elegir VMware Cloud PKS:

Ilustración 71 – VMware Cloud PKS

Y pulsar Click to Start:

#VMwarePorvExperts

976

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 72 – Click to Start

Tendremos que generar una nueva organización si es la primera vez, donde se van a generar nuestros proyectos:

Ilustración 73 – VMware Cloud Services

E introducir nuestros datos para el cobro de uso de la infraestructura. Para empezar, dispondremos de 150$ de crédito:

#VMwarePorvExperts

977

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 74 – Payment Information

Dispondremos en la vista My Services el servicio que vamos a manejar:

Ilustración 75 – My Services

Como podéis imaginar, podemos generar proyectos de diferente índole dentro de la nube de VMware:

Ilustración 76 – Servicios VMware Cloud

Pulsaríamos “Developer center”:

#VMwarePorvExperts

978

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 77 – Developer center

Dispondremos del comando de acceso vía consola:

Ilustración 78 – Developer Center

Como hemos comentado, nuestro cliente debe tener instalado el cliente VMware Cloud PKS CLI y kubectl, que podéis descargar desde Downloads:

#VMwarePorvExperts

979

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 79 – Developer Center Downloads

Adicionalmente, desde My Account -> API Tokens, deberemos generar un nuevo Token:

Ilustración 80 – My Account API Tokens

En este ejercicio se dispone de un cluster para cada usuario:

#VMwarePorvExperts

980

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 81 – Cluster

Nos conectaríamos desde nuestro cliente al cloud con el nombre de la organización que hemos creado y nuestro token generado: vke account login -t ‘your-organization-id’ -r ‘your-refresh-token’

Ilustración 82 – Conexión VMware Cloud PKS

Generamos una carpeta y un Proyecto dentro de VKE:

Ilustración 83 – Crear Folder y Project

Conseguimos la autorización kubectl para nuestro clúster:

Ilustración 84 – My Account API Tokens

#VMwarePorvExperts

981

Capítulo 18 - vSphere y Containers Raúl Unzué

Obtenemos nuestros Pods en el clúster:

Ilustracion 84 – Pods

Obtenemos también los servicios:

Ilustración 85 – Servicios

Creamos un namespace. Un namespace está diseñado para usarse en entornos con muchos usuarios distribuidos en varios proyectos, permitiendo distribuir los recursos de un cluster entre varios usuarios:

Ilustración 86 – Create Namespace

Lo usaremos por defecto:

Ilustración 87 – Namespace default

Listamos los namespaces:

Ilustración 88 – Get Namespaces

Creamos un volumen persistente para MySQL:

Ilustración 89 – Create Volumen Persistent

#VMwarePorvExperts

982

Capítulo 18 - vSphere y Containers Raúl Unzué

Verificamos que se ha generado el volumen persistente:

Ilustración 90 – Create Volumen

Desplegamos el pod de MySQL:

Ilustración 91 – Pod MySQL

Implementamos el servidor MySQL que usará el volumen persistente:

Ilustración 92 – MySQL

Ahora desplegamos el Pod del servidor de aplicaciones:

Ilustración 93 – Pod

Desplegamos el Frontend:

Ilustración 94 – Frontend

Desplegamos Redis y ADSB Sync Service:

Ilustración 95 – Redis y ADSB Sync Service

Verificamos que se hayan implementado todos los pods necesarios para los servicios frontend, redis, DBC Sync y el servidor de aplicaciones.

#VMwarePorvExperts

983

Capítulo 18 - vSphere y Containers Raúl Unzué

Ilustración 96 – Verificación Pods

Comprobamos todos los servicios:

Ilustración 97 – Verificación Servicios

Ahora, para poder presentar la aplicación fuera del cluster deberemos crear un servicio que permita el balanceo de carga:

Ilustración 98 – Balanceo de carga

Comprobamos la IP de balanceo:

Ilustración 99 – Comprobar IP

Con esto disponemos de una publicación de una app con varios servicios enlazados en nuestro VMware Cloud PKS.

#VMwarePorvExperts

984

Capítulo 18 - vSphere y Containers Raúl Unzué

#VMwarePorvExperts

985

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

986

Capítulo 19 VMware Code - API

Daniel Romero

#VMwarePorvExperts

987

Capítulo 19 - VMware Code - API Daniel Romero

VMware {Code} VMware ha creado una comunidad dedicada a desarrolladores, devops o administradores de sistemas interesados en la virtualización y su desarrollo, llamada VMware {Code}. A través de un portal de recursos centralizados es posible acceder a documentación, foros, ejemplos o descargas de herramientas. Esta comunidad crece continuamente, no sólo de usuarios, sino de recursos gracias a las nuevas actualizaciones de los productos. Hasta la publicación de vSphere 6.5 únicamente se disponían de APIs SOAP para el intercambio de información. Con la llegada del nuevo cliente HTML5 y las nuevas tendencias de desarrollo de software, VMware ha introducido en sus productos amodelos de API REST que ofrecen a los desarrolladores una experiencia de programación más completa y sencilla. Las SDKs también se han actualizado, además se han introducido nuevas. Están disponible en los lenguajes de programación más populares: .Net, Java, PHP, Python, Javascript, C, Ruby, etc. Esto ayuda a empresas de terceros a desarrollar productos de calidad y totalmente complementarios a vSphere, como por ejemplo: integración con herramientas de copias de seguridad, monitorización, automatización, etc. A lo largo de este capítulo aprenderemos a trabajar con la API REST de VMware sin hacer uso de las SDK.

#VMwarePorvExperts

988

Capítulo 19 - VMware Code - API Daniel Romero

1. ¿Qué es una API REST? Antes de comenzar haremos un repaso al concepto de API. Una API tal y como su acrónimo en inglés indica es una interfaz de programación de aplicaciones que permite el intercambio de mensajes o datos entre dos aplicaciones mediante el uso de operaciones, normalmente basadas en el protocolo HTTP. Ésta permite aislar el cliente del servidor proporcionando fiabilidad y escalabilidad. Además, puede ser desarrollada en cualquier lenguaje de programación. La API REST utiliza un protocolo de cliente/servidor sin estado. Por esto, se requiere enviar toda la información necesaria en la petición HTTP del cliente. ¿Qué quiere decir esto? Supongamos una API que requiera autenticación para acceder a información sensible. Cada vez que se realice una llamada a ésta, hay que enviarle los parámetros correspondientes que permitan el acceso a la información, mediante el uso de credenciales o un token de autorización. Sin entrar en profundidad en el protocolo HTTP, hay que saber que las peticiones enviadas a través de éste se realizan mediante cabeceras, que son las encargadas de transportar la información entre el cliente y el servidor. Las operaciones o métodos más comunes utilizadas en este tipo de APIs son: •

POST (crear)

•

GET (consultar)

•

PUT (editar)

•

DELETE (eliminar)

Se forman mediante URIs con la siguiente estructura: {protocolo}://{host}[:puerto]/{ruta del recurso}?{operación}

Es muy común recibir las respuestas de las llamadas en formato JSON, aunque también es posible obtenerla en XML u otros formatos. Durante este capítulo todas las respuestas de ejemplo serán en formato JSON, que es el utilizado por VMware. Hay que tener en cuenta que las llamadas pueden responder con errores, ya sean porque el recurso no esté disponible, no se disponga de permisos o cualquier otro factor. La definición de estos errores se suele realizar mediante códigos de estado de HTTP. Los más comunes que se pueden encontrar son: Código HTTP 200 400 401 403 503

#VMwarePorvExperts

Razón

Respuesta correcta La solicitud contiene errores Solicitud sin permisos o autenticación Solicitud sin privilegios para acceder al servicio Servicio no disponible

989

Capítulo 19 - VMware Code - API Daniel Romero

1.1 Cómo funciona Para entender correctamente qué es y cómo funciona tenemos que imaginar una API que sea capaz de editar, consultar o borrar un capítulo de este libro y se desea consultar el capítulo 19. Primero se formará la URI en el formato que se mencionó anteriormente: •

Protocolo y host: https://vmwareporvexperts.org

•

Ruta del recurso: /libro/capitulo/19

•

Operación: /consultar

Ahora hay que identificar la operación realizada. Consultar equivale al método GET por lo que utilizando la herramienta CURL a través de una línea de comandos se podría realizar la llamada correspondiente y obtener la información. curl –XGET https://vmwareporvexperts.org/libro/capitulo/19/consultar

Al lanzar el comando se obtendría la respuesta deseada, en este caso la información correspondiente al capítulo 19.

#VMwarePorvExperts

990

Capítulo 19 - VMware Code - API Daniel Romero

2. API REST DE VMware 2.1 Diferentes APIs REST de VMware Ahora que ya se conocemos cómo funciona una API REST, es el momento de ver las APIs que VMware pone a disposición de los usuarios. Éstas han sido clasificadas dependiendo del entorno o plataforma a la que pertenecen: •

•

•

•

•

•

Cloud Management Platform •

vRealize Automation

•

vRealize Log Insight

•

vRealize Operations

•

vRealize Orchestrator

•

vRealize Suite Lifecycle Manager.

Data Center & Cloud Infraestructure •

vCloud Director For Service Providers

•

vCloud Director

•

vSphere

Desktop & Application Virtualization •

Horizon

•

Horizon View

Digital Workspace •

Identity Manager

•

Workspace ONE Notifications Service

Networking & Security •

NSX for vSphere

•

NSX-T

•

vRealize Network Insight

Personal Desktop •

•

Fusion

Storage & Availability •

VSAN

#VMwarePorvExperts

991

Capítulo 19 - VMware Code - API Daniel Romero

•

Other Platform •

Apteligent

•

VMware Cloud on AWS

•

VMware Integrated OpenStack

•

vCloud Availability for Cloud-to-Cloud DR

•

vCloud Usage Meter

No es objetivo de este capítulo aprender cómo funciona cada una de las API mencionadas anteriormente, sino saber cómo usarlas de forma general. Para ello veremos ejemplos de uso de la API de vSphere. Podemos consultar toda la documentación de éstas en la dirección: https://code.vmware.com/apis/

2.2 Cómo acceder al explorador de API de vSphere. Para acceder al catálogo de APIs disponibles basta con abrir en un navegador web la URL de acceso a vCenter añadiendo la ruta apiexplorer: https://vcenter.vmwareporvexperts.org/apiexplorer/

La ventana abierta es el Explorador de APIs. Una vez se accedemos podemos ver a través de un desplegable las diferentes APIs que hay disponible en el entorno vSphere junto con sus recursos. Este explorador es de gran utilidad ya que permite conocer la definición de cada uno de los recursos de la API. En resumidas palabras, se puede decir que es la documentación de uso de las APIs.

#VMwarePorvExperts

992

Capítulo 19 - VMware Code - API Daniel Romero

VMware se ha basado en la interfaz de usuario Swagger UI para la creación del explorador. De esta forma es posible conocer toda la definición de la API e incluso ejecutar operaciones siempre y cuando nos encontremos autenticados con un usuario que disponga de permisos suficientes para operar sobre los componentes de vSphere.

2.3 Recursos de la API de vSphere Para entender cómo se utiliza la API REST de VMware se utilizará de ejemplo la API de vSphere. A través del explorador vamos a ver cómo se accede a algunos de los recursos disponibles, por ejemplo, el de vCenter. Una vez se ha accedido a la URL, en el desplegable Select API hay que seleccionar vcenter. Si se recorre todo el listado de recursos que se han cargado, se observará que hay disponibles diferentes rutas que están clasificadas por cada uno de los componentes de vCenter: •

Cluster

•

Datacenter

•

Datastore

•

Deployment

•

Folder

•

Guest

•

Host

•

Inventory

•

Network

•

OVF

•

Resource pool

•

Services

•

Storage

•

System config

•

VCHA

•

VM

Si pulsamos sobre algún recurso veremos que se despliegan las diferentes operaciones disponibles. Si volvemos a la definición de API REST, podemos identificar claramente las partes que componen la URI. Por ejemplo, veamos el recurso GET vm/power que formaría la siguiente URI. https://venter.vmwareporvexperts.org/rest/vcenter/vm/power

#VMwarePorvExperts

993

Capítulo 19 - VMware Code - API Daniel Romero

Los métodos son fácilmente identificables ya que aparecen agrupados en diferentes colores. Azul para los métodos GET, verde para los POST y rojo para DELETE. En la siguiente imagen se pueden apreciar las operaciones disponibles sobre el encendido/apagado de una máquina virtual.

2.4 Operaciones sobre los recursos de la API Ya conocemos cómo identificar las operaciones disponibles sobre un recurso, veamos la estructura general de una de ellas a nivel de parámetros y respuestas. Tal y como se comentó al comienzo de este capítulo, una respuesta correcta de un método de la API devuelve el código de estado HTTP 200. Además, suele añadir un cuerpo (body) con la información de dicha respuesta, aunque hay operaciones que no lo necesitan. Es la primera información que encontrarás cuando hagas clic sobre una de las operaciones en el explorador de API.

La mayoría de las operaciones sobre una API necesitan parámetros de entrada que permitan identificar sobre qué objeto se va a operar. Algunos pueden ser obligatorios y otros opcionales a modo de filtro. Dependiendo del método utilizado se enviará mediante la URI o bien por POST.

#VMwarePorvExperts

994

Capítulo 19 - VMware Code - API Daniel Romero

En toda definición de la arquitectura de una API se encuentran los mensajes de error. Estos mensajes permiten identificar mediante códigos HTTP el motivo por el que una operación ha respondido de forma incorrecta. A través del explorador podemos conocer la razón por la que una operación puede estar fallando.

El modelo de respuesta de una operación incluye el código de estado de ésta, el cuerpo de la respuesta y otras cabeceras de ayuda. En la siguiente imagen se podemos observar la respuesta del estado de una máquina virtual.

VMware ha creado una API bastante bien documentada. Esto ayuda a la comunidad de desarrolladores enormemente ya que permite interactuar con los componentes del propio software de VMware de manera sencilla.

2.5 Cómo apagar una máquina virtual desde el explorador de APIs Veamos un ejemplo práctico de cómo apagar una máquina virtual utilizando el explorador. Hay que estar autenticado para poder realizar el siguiente ejemplo. En las operaciones sobre la manipulación del estado de una máquina virtual que se vio anteriormente, había una de ellas que permitía el apagado de éstas. POST /vcenter/vm/{vm}/power/stop

#VMwarePorvExperts

995

Capítulo 19 - VMware Code - API Daniel Romero

Al acceder a esta operación podemos comprobar que no va a devolver un cuerpo de respuesta en caso de que sea satisfactoria. Únicamente devolverá el código de estado 200. Además, solicita un parámetro de entrada obligatorio para identificar la máquina virtual que se desea apagar. “Virtual machine identifier. The parameter must be an identifier for the resource type: VirtualMachine”

Este identificador es único y la forma de conocerlo es accediendo al recurso de la API VM.

Una vez localizado el recurso, pulsamos sobre la operación GET /vcenter/vm. Cuando se despliegue toda la estructura de la definición de este método, se podremos comprobar todos los parámetros de entrada solicitados. En este caso, todos son opcionales, por lo que los dejaremos en blanco. nos dirigimos a la parte final y hacemos clic sobre el botón azul TRY IT OUT. Una vez lancemos la petición, se obtendremos una respuesta en el cuerpo en formato JSON que contiene un ARRAY de valores. Cada elemento que lo compone muestra información de las máquinas virtuales disponibles.

Tenemos que identificar la máquina virtual que se quiere apagar. El parámetro name nos ayudará a encontrarla. Una vez se tenga, apuntamos el valor del parámetro vm, que es el parámetro obligatorio que la mayoría de las operaciones requieren para trabajar con una máquina virtual. Es el momento de volver al método POST /vcenter/vm/{vm}/power/stop e introducir el identificador de la máquina virtual que se quiere apagar.

#VMwarePorvExperts

996

Capítulo 19 - VMware Code - API Daniel Romero

Al igual que hicimos anteriormente, hay que desplazarse hasta el final de la definición del método y pulsar en TRY IT OUT. Si la máquina virtual que se ha tratado de apagar existe, se recibiremos la respuesta con el código de estado HTTP 200. Hay que recordar que esta operación no devuelve ningún mensaje en el cuerpo, tal y como se observa en la siguiente imagen:

Este proceso es algo engorroso y no muy práctico para apagar una máquina virtual pero el objetivo de este ejemplo es familiarizarse con la definición de la API y saber utilizar el explorador.

CONSEJO: Entender cómo funciona el explorador de la API de VMware te va a permitir desenvolverte igualmente con otras APIs que utilizan Swagger UI.

#VMwarePorvExperts

997

Capítulo 19 - VMware Code - API Daniel Romero

3. Desarrollo El desarrollo ya no es solo cosa de los programadores. Hasta no hace muchos años, ha sido muy común ver como operadores desplegaban de forma manual el mismo tipo de máquina virtual cada vez que el equipo de desarrollo necesitaba probar una versión de código nueva. Hoy en día todo este proceso se puede automatizar gracias a la disponibilidad de APIs que permiten integrar las herramientas utilizadas con desarrollos propios. Los lenguajes de programación más utilizados en la actualidad para realizar estas operaciones son Python y Javascript (Node.js) ya que son muy versátiles para trabajar con llamadas a APIs. Teniendo en cuenta el ejemplo anterior del apagado de la máquina virtual, en este apartado veremos cómo automatizarlo mediante estos lenguajes de programación. También es posible realizarlo a través de comandos BASH o bien utilizando Powershell, pero no es objetivo de este capítulo. Todos los ejemplos con los que se trabajaremos en este capítulo han sido subidos al repositorio oficial libro VMware por vExperts en GitHub. Puedes acceder a ellos a través de la siguiente URL: https://github.com/vmwareporvexperts/vmwareporvexperts

3.1 Accediendo a la API REST de VMware a través de PYTHON Python puede estar entre los tres lenguajes de programación más utilizado de la actualidad. Es muy sencillo de aprender y versátil. Hoy en día se ha convertido en una herramienta más para cualquier administrador de sistemas. En este apartado se realizaremos el ejemplo anterior utilizando Python 3.x. Es recomendable estar familiarizado con sus sintaxis. Cualquier script en Python comienza importando los módulos o librerías que se van a usar. Request es una de las librerías más utilizadas para realizar llamadas HTTP. Su uso es muy sencillo y permite realizar operaciones GET y POST con pocas líneas de código. Trabajaremos con ella para acceder a los métodos de la API de vSphere apilando diferentes llamadas. Procederemos a instalar la librería en caso de no disponer de ella. pip install request

Un requisito obligatorio para poder trabajar con la de API vSphere es estar autenticado. Ahora ya no vamos a usar el explorador por lo que es necesario obtener autorización de vCenter para poder apagar la máquina virtual. El primer paso consiste en obtener el token, que permitirá que podamos realizar las operaciones necesarias hasta conseguir apagar la máquina virtual. Esto se realiza mediante el método POST /com/vmware/cis/session. Este método utiliza la cabecera vmware-use-header-authn como protección contra CSRF. Además, hay que pasar unas credenciales de acceso a vCenter que dispongan de permisos para listar y apagar máquinas virtuales. Este devuelve un token que será utilizado en el resto de las llamadas a la API.

#VMwarePorvExperts

998

Capítulo 19 - VMware Code - API Daniel Romero

Continuando con el ejemplo de apagado de la máquina virtual, ahora hay que realizar la llamada al método GET /vcenter/vm pasando en la cabecera el token obtenido anteriormente en el parámetro vmware-api-session-id.

Esta petición devuelve una respuesta en el cuerpo en formato JSON con los datos de las máquinas virtuales.

#VMwarePorvExperts

999

Capítulo 19 - VMware Code - API Daniel Romero

Si la máquina que se desea apagar es la llamada “vm01” hay que obtener el valor del campo “vm”. Esto se puede hacer fácilmente recorriendo el array hasta encontrarla.

Una vez encontrada, se guarda el valor en la variable vmid. Este es el parámetro obligatorio que el método POST /vcenter/vm/{vm}/power/stop utiliza para identificar la máquina virtual que se quiere apagar. Por último, sólo queda invocar la llamada que ejecutará la opción de apagado.

Si la máquina virtual estaba encendida, ésta se apagará y se recibirá un código de estado HTTP 200 en caso de que estuviese apagada el código de estado será 400.

#VMwarePorvExperts

1000

Capítulo 19 - VMware Code - API Daniel Romero

CONSEJO: En el código anterior se ha simplificado y no se controlan las llamadas fallidas a la API. Es aconsejable comprobar que en las respuestas de las llamadas se obtiene el código de estado HTTP 200. En caso contrario se debería lanzar una excepción, ya que el resto de las llamadas fallarán.

3.2 Accediendo a la API REST de VMware a través de NODE.JS Node.js es un entorno de ejecución de Javascript que está basado en el motor V8 de Javascript de Google. En la actualidad es muy utilizado en arquitecturas de microservicios ya que necesita muy pocos recursos para su ejecución. En lugar de utilizar la librería Request para las llamadas a la API en Javascript se utilizará Unirest, una librería que es bastante más ligera y fácil de usar. En este momento, en caso de no tener la librería Unirest habría que instalarla. npm install unirest

También hay que tener en cuenta que por naturaleza Javascript realiza peticiones de forma asíncrona y habrá que realizar alguna adaptación para hacerla síncrona. Es recomendable tener experiencia previa en este lenguaje para entender las operaciones que se van a realizar. Continuando con los ejemplos anteriores, ahora toca el turno de encender la máquina virtual. El primer paso consiste, nuevamente, en autenticarnos y conseguir unas credenciales válidas para poder realizar llamadas a la API de vCenter. Se ha creado la función getToken() que realiza la petición POST /com/vmware/cis/session pasándole cómo parámetros los datos de acceso a vCenter. Esta función devuelve una promesa que contiene el cuerpo de la respuesta. Si todo ha ido bien obtendremos el token que se necesitará para el resto de las operaciones.

#VMwarePorvExperts

1001

Capítulo 19 - VMware Code - API Daniel Romero

Lo siguiente es construir la función que se encargará de encender la máquina virtual, la llamaremos startVM(). Esta anidará dos llamadas a la API: la primera para obtendrá el id de la máquina virtual y la segunda que realizará el encendido. Anteriormente se mencionó que Javascript opera de forma asíncrona de manera general. Para trabajar con APIs que necesitan llamadas correlativas hay que realizar una serie de modificaciones para que las peticiones sean síncronas. Esto quiere decir que antes de realizar la siguiente llamada, hay que esperar a que una llamada finalice y devuelva su respuesta. Para conseguirlo hay que inicializar la función startVM() utilizando la expresión async. Esta función debe de parar su hilo de ejecución cuando se invoque la función getToken(). Esto se consigue utilizando la expresión await antes de su llamada. De esta forma hasta que no se obtenga el token la función no continuará con el resto de las llamadas.

#VMwarePorvExperts

1002

Capítulo 19 - VMware Code - API Daniel Romero

Si se observa el código anterior, una vez obtenido el token, se realiza una llamada al método GET / vcenter/vm que devuelve el listado de máquinas virtuales. Busca la máquina llamada vm01 y guarda su identificador para posteriormente hacer la operación POST /vcenter/vm/{vm}/power/start que se encargará de encenderla.

#VMwarePorvExperts

1003

Capítulo 19 - VMware Code - API Daniel Romero

4. Cómo contribuir en VMware {Code} Hemos aprendido a trabajar con la API REST de VMware. Ahora que somos capaces de crear código para operar con los diferentes componentes de vSphere podemos compartirlo con el resto de los usuarios y así enriquecer la comunidad. Es muy importante que todo el código de ejemplo que se vaya a subir no contenga datos sensibles como URLs o credenciales de acceso. A través de la siguiente URL https://code.vmware.com/samples se pueden subir los ejemplos de desarrollos realizados.

Una vez se ha accedido a la URL hay que pulsar en Add New Sample. Dentro, en el primer paso tenemos la posibilidad de: •

Copiar y pegar el código

•

Subir el código de forma comprimida

•

Vincular un repositorio de Github

Dependiendo de la elección seleccionada anteriormente, se habilitará en el paso dos las opciones para añadir el código. Se verá como ejemplo el uso del repositorio de Github creado para este libro.

#VMwarePorvExperts

1004

Capítulo 19 - VMware Code - API Daniel Romero

Al vincular el repositorio se ha seleccionado la ruta en la que se encuentran los ejemplos en Python de este capítulo para no mezclar distintos lenguajes de programación. El siguiente paso es rellenar la información necesaria para identificar el código que queremos compartir: título, descripción, lenguaje, plataforma, etiquetas...

Con todos los datos rellenos ya se puede subir el código pulsando en el botón de Submit. De esta forma se ha contribuido a la comunidad con los ejemplos realizados en este capítulo para que otros usuarios puedan utilizarlos.

#VMwarePorvExperts

1005

Capítulo 19 - VMware Code - API Daniel Romero

GLOSARIO API: Interfaz de programación de aplicaciones. REST: Transferencia de Estado Representacional. SOAP: Protocolo simple de acceso a objetos. HTML5: Quinta revisión del lenguaje básico de la World Wide Web, HTML. SDK: Kit de desarrollo de Software. URI: Identificador de recursos uniforme. NODE.JS: Entorno de ejecución de Javascript basado en el motor V8 de Javascript de Google. PYTHON: Lenguaje de programación interpretado. CSRF: Exploit malicioso que consiste en la falsificación de petición en sitios cruzados.

#VMwarePorvExperts

1006

Capítulo 19 - VMware Code - API Daniel Romero

#VMwarePorvExperts

1007

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

1008

Capítulo 20 VMware Cloud on AWS

Jorge de la Cruz

#VMwarePorvExperts

1009

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

1. Introducción a VMware Cloud en AWS 1.1 ¿Qué es VMware Cloud en AWS?

VMware Cloud en AWS nos ofrece todo el poder que ya conocemos de vSphere, ejecutándose en los Datacenter de Amazon. Consiste en host ESXi baremetal con vCenter, vSAN para el Storage y NSX para el Networking y Seguridad. Ya que es vSphere, todo el conocimiento adquirido durante estos años, los scripts que pudiéramos tener o incluso aplicaciones de gestión e incluso Backups, van a funcionar de la misma manera que lo hacen hoy. VMware Cloud en AWS aporta las amplias, diversas y ricas innovaciones de los servicios de AWS de forma nativa a las aplicaciones empresariales que se ejecutan en las plataformas de virtualización de red, almacenamiento y computación de VMware. Esto nos permite añadir fácil y rápidamente nuevas innovaciones a sus aplicaciones empresariales mediante la integración nativa de las capacidades de infraestructura y plataforma de AWS, como AWS Lambda, Amazon Simple Queue Service (SQS), Amazon S3, Elastic Load Balancing, Amazon RDS, Amazon DynamoDB, Amazon Kinesis y Amazon Redshift, entre muchos otros. Con VMware Cloud en AWS, las organizaciones podemos simplificar sus operaciones de TI híbridas utilizando las mismas tecnologías de VMware Cloud Foundation, incluyendo vSphere, vSAN, NSX y vCenter Server, en sus centros de datos locales y en AWS Cloud sin tener que comprar hardware nuevo o personalizado, reescribir aplicaciones o modificar sus modelos operativos. El servicio aprovisiona automáticamente la infraestructura y proporciona compatibilidad total con la VM y portabilidad de la carga de trabajo entre nuestros entornos locales y la nube AWS Cloud. Con VMware Cloud en AWS, podemos aprovechar la amplia gama de servicios de AWS, incluyendo computación, bases de datos, análisis, Internet of Things (IoT), seguridad, móviles, despliegue, servicios de aplicaciones y mucho más.

#VMwarePorvExperts

1010

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

1.2 ¿Por qué es tan importante VMware Cloud en AWS? Esta solución conjunta nos proporciona lo mejor de VMware, y lo mejor de AWS y hará la vida más sencilla a los clientes que lo utilicen. •

•

VMware •

Liderando la parte de computo, almacenamiento y red

•

Soporte para una cantidad gigante de cargas de trabajo

•

La solución estándar en cualquier Datacenter hoy en día

AWS •

El pago por consumo y flexibilidad

•

Amplia gama de servicios cloud

•

Escalado y posicionamiento Global

1.3 La solución: VMware Cloud en AWS (VMC) •

VMware SSDC stack ejecutándose en AWS •

Computo (vSphere), Almacenamiento (vSAN) y red con seguridad (NSX)

•

Acceso directo a vCenter, incluye además soporte completo para API/CLI

#VMwarePorvExperts

1011

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

• •

•

Entregado como servicio (todo el ciclo de versiones de VMware vSphere completamente gestionado por VMware)

Modo de operación consistente que nos permite beneficiarnos del Cloud Híbrido •

Soporte completo para aplicaciones ya existentes o futuras

•

Herramientas de gestión que se pueden añadir como capas encima de la solución

•

Despliegue en modo Hybrid o Cloud-only está disponible

Beneficio de lo económico de cloud, alineando capacidad y demanda •

Una única factura por parte de VMware, para licencias de VMware y la Infraestructura de AWS

•

Descuentos para clientes grandes por volumen en licencias de VMware

•

Consumir de manera elástica clústers de SDDC

•

On-demand o suscripción

•

Aprovechar todo el recorrido de AWS

El servicio ya está disponible en diferentes ubicaciones del mundo, siguiendo obviamente los Datacenter

#VMwarePorvExperts

1012

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

donde Amazon Web Services ya presta servicio, durante todo 2018 se ha expandido a muchas más regiones, y 2019 se espera que este servicio llegue a muchas otras nuevas localidades.

1.4 Precio y requerimientos mínimos VMware ha habilitado una página web con todos los detalles del producto, muchos vídeos para ayudarnos con esta tecnología, y uno dedicado al precio. A la hora de hardware, VMware no se pilla los dedos y nos ofrece cada server con dos CPU que llegan a los 36 cores, 72 hyper-threads, 512GB de RAM y de almacenamiento flash local (3.6TB caché, 10.7TB capacidad raw en tier). •

La configuración mínima son 3 Hosts de ESXi, y desde ahí podemos crecer sin límite tanto como nuestro negocio necesite.

•

Es posible desplegar un SDDC con un único Host (Single Host SDDC), perfecto para probar la Infraestructura, o para determinadas situaciones de DR. Este Host tiene un ciclo de vida de 30 días máximo, tendrá que convertirse en uno de los SDDC con 3 o 4 hosts o es destruido.

A la hora de consumir la tecnología, y hacer la facturación podemos pagar de tres maneras diferentes: consumo por hora, pago fijo a un año y pago fijo a tres años. Lista de precios: PRECIO PÚBLICO ($ POR HOST)

AHORRO COMPARANDO CON ON-DEMAND

ON-DEMAND (HORA)

1 AÑO RESERVADO

3 AÑOS RESERVADO

$8.3681

$ 51,987

$109,366

30.00%

50.00%

De todas formas, os invito a visitar la siguiente página web donde podemos incluso calcular nuestras cargas de trabajo de manera más personalizada - https://cloud.vmware.com/vmc-aws/pricing

#VMwarePorvExperts

1013

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

2. Cómo crear un SDDC en VMware Cloud on AWS y primer vistazo a la solución Vamos a ver un paso a paso de cómo crear un Software Defined Datacenter en VMware en AWS. Nada más conectarnos a nuestra cuenta de VMware Cloud on AWS veremos un botón grande donde podremos crear un nuevo SDDC:

El siguiente paso será seleccionar la región donde queremos lanzar este SDDC, si queremos que sea Single-Node o Multi-Node y un nombre, tan simple como esto:

En el segundo paso podremos conectar nuestro SDDC a nuestra cuenta de AWS, para poder expandir nuestro entorno vCenter con S3, EC2, y todos los servicios que el cloud de Amazon ofrece, seleccionaremos Skip for now:

#VMwarePorvExperts

1014

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Por último, seleccionaremos el rango de red que queremos usar para nuestros elementos del SDDC internos, en mi caso he seleccionado 10.2.0.0/20:

Y con estos tres simples pasos, nuestro SDDC comenzará a desplegarse de forma automatizada, ESXi, vCenters, VSAN, NSX, todo estará listo en apenas dos horas sin tocar ni una sola tecla más, disfrutar:

#VMwarePorvExperts

1015

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Voilá, pasadas las dos horas ya podremos ver el resumen de nuestro SDDC, con 83GHz, 512GB de memoria RAM y 10TB de Storage VSAN:

Dentro de View details podemos ver el resumen de nuestro entorno, hacerlo crecer, etc.

#VMwarePorvExperts

1016

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

En la parte de Networking, por ejemplo, podremos ver el direccionamiento de nuestro entorno de Management y Compute, y también tenemos dos satélites, uno es Internet y el otro es nuestro Data Center local que tenemos on-prem, por ahora no están conectados entre sí, pero esto lo veremos mas adelante.

#VMwarePorvExperts

1017

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

3. Conectar nuestra cuenta de AWS con nuestra Infraestructura de VMC Vamos a ver cómo conectar nuestro entorno de VMware Cloud on AWS con nuestra cuenta de AWS, para poder usar los servicios de AWS tales como EC2, Balanceadores de Carga, y mucho más, con nuestras aplicaciones que ejecutamos en nuestro VMware Cloud on AWS. La topología que buscamos será algo similar a esto donde nuestro VMware Cloud VPC con todos sus Hosts y VMs internas, tendrán acceso al VPC creado en AWS, donde tendremos dentro las diferentes subnets, EC2, servicios, etc:

El primero paso será irnos hasta nuestro SDDC, y sobre él haremos click en Connect to AWS:

#VMwarePorvExperts

1018

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

El proceso nos conectará de manera inmediata nuestra cuenta de VMC con la de AWS, podemos revisar la cuenta, y el CF-Stack, etc, haremos click en Next:

Seleccionaremos el VPC de AWS al que queremos conectar nuestro entorno de VMware Cloud on AWS, y la subnet que tenemos dentro de ese AWS VPC:

#VMwarePorvExperts

1019

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

El proceso comenzará y veremos la notificación en la barra superior derecha:

Pasados entre 30 segundos a 1 minuto ya veremos que la conexión se ha realizado correctamente:

Finalmente, si nos volvemos a nuestro SDDC, en la parte de Network podremos ver que nuestra red de Compute ya tiene acceso directo a nuestro entorno de Amazon VPC. Nota: Recordar que el Firewall está configurado para denegar todas las conexiones, con lo que

#VMwarePorvExperts

1020

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

tendremos que crear reglas de Firewall para permitir el acceso entre las ubicaciones.

Nota: Como podemos ver hay dos redes, la de Management, que es donde está todo el direccionamiento de gestión de la plataforma, por ejemplo, el vCenter y su puerto 443 tiene que ser abierto aquí. Mientras que en Compute Gateway es la parte de red que las VMs dentro de los Hosts tendrán, es allí donde tendremos que habilitar por ejemplo el SSH hacía un VM que estemos ejecutando dentro de nuestro SDDC.

3.1 Habilitar el tráfico entrante ENI en la red de Compute •

Haremos click en la pestaña de ‘Network’

•

Haremos scroll hasta la sección de ‘Compute Gateway’

•

Expandiremos ‘Firewall Rules’

•

Haremos click en ‘Add Rule’

•

Seleccionaremos ‘ENI – Inbound’ para el campo ‘Rule Name’

•

Haremos cllick en el drop-down donde dice ‘Source’y seleccionaremos ‘All Connected Amazon VPC’

•

En el campo llamado ‘Destination’ , escribiremos nuestro rango del VPC de AWS en este caso ‘192.168.0.0/16’

•

Haremos click en el drop-down donde pone ‘Service’ y seleccionaremos ‘Any (All Traffic)’

•

Finalmente haremos click en ‘SAVE’

#VMwarePorvExperts

1021

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

3.2 Habilitar el tráfico saliente ENI en la red de Compute •

Haremos click en ‘Add Rule’

•

Escribiremos ‘ENI – Outbound’ donde pone ‘Rule Name’

•

Haremos click en el drop-down donde dice ‘Source’ y escribiremos ‘192.168.0.0/16’

•

Donde pone ‘Destination’, haremos click en el drop-down y seleccionaremos ‘All Connected Amazon VPC’

•

Haremos click en el drop-down donde pone ‘Service’ y seleccionaremos ‘Any (All Traffic)’

•

Finalmente haremos click en ‘SAVE’

Ya tendríamos todo configurado y preparado para permitir el tráfico entre nuestro entorno de VMC y de AWS.

#VMwarePorvExperts

1022

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

4. Conectar nuestro Datacenter (pFsense) con nuestra Infraestructura de VMC Es turno en este capítulo de ver cómo podemos interconectar nuestro Datacenter con VMware Cloud on AWS usando VPN IPsec.

4.1 Parámetros básicos que tenemos que tener en cuenta para la VPN Antes de empezar a configurar nada, tenemos que tener planificado cómo queremos configurar la VPN, no solo esto, pero también las IP públicas y los rangos internos que queremos interconectar, preparar una tabla como la siguiente nos ayudará en los pasos posteriores: Parámetro

IP Pública AWS VMC MGM Gateway

Rango de Red AWS VMC MGM

IP Pública de nuestro Datacenter

Rango de Red de nuestro Datacenter

Protocolo

Modo ISAKMP

Algoritmo de Cifrado

Algoritmo de Hashing

Diffie Hellman

Autenticación IKE

Tiempo de vida de ISAKMP/IKE SA

Valor

35.177.252.176

10.2.0.0/20

86.1.207.63

192.168.1.0/24

IKEv1

Main mode

AES-256

SHA1

DH2

Pre-Shared Key

28800 seconds

Editable

No

No

No

No

No

No

Si

No

Si

Si

No

4.2 Configuración de VPN en nuestro pfSense Ahora que conocemos ya los detalles de ambos entornos, vamos a comenzar con la configuración de nuestro lado, nuestro Datacenter. En mi caso estoy usando pfSense, con IP pública dinámica, con lo que es bastante sencillo de configurar, incluso en mi caso.

4.2.1 Configuración de VPN Phase 1 El primero paso será hacer login en nuestro pFsense con un usuario con privilegios para editar la configuración:

#VMwarePorvExperts

1023

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Nos iremos hasta VPN – IPsec para configurar nuestro lado de la VPN:

Añadiremos la primera fase de la intercomunicación entre sitios:

#VMwarePorvExperts

1024

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Hay que recordar que usaremos todos los parámetros que hemos definido anteriormente, he marcado con azul los realmente importantes:

Ahora que tenemos la Phase 1 completada, tendremos que configurar la Phase 2, que es el rango interno al que la VPN tendrá acceso, etc.

4.2.2 Configuración de VPN Phase 2 Al igual que anteriormente, lo primero es tener claro la configuración que queremos para esta fase, por ejemplo: Parámetro

Algoritmo de Cifrado

AES-256

Algoritmo de Hashing

SHA1

Diffie Hellman

Tiempo de vida de SA

Perfect forward secrecy (PFS)

DH2

3600 seconds Enabled

Valor

Si

Editable

Si

No No Si

Desde el menú de VPN – IPsec, veremos nuestro Túnel, haremos click en Show Phase 2 Entries y haremos click en Add P2

#VMwarePorvExperts

1025

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

La configuración tiene que quedar similar a la siguiente, he marcado con azul las partes importantes:

Ahora que tenemos ya todo configurado en nuestro pfSense, es el turno de la configuración final en la parte de VMware Cloud on AWS, vamos a por ello.

4.3 Configuración de VPN en VMware Cloud on AWS Desde nuestro portal de configuración nos iremos hasta Network y en la parte de Management Gateway, haremos click en Add VPN:

#VMwarePorvExperts

1026

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

La configuración de la VPN tiene que contener toda la información que hemos recabado anteriormente, de la siguiente manera:

Una vez que hagamos click en Save, ya podremos ver que pasados unos segundos la VPN se encuentra en estado conectado, en color verde:

#VMwarePorvExperts

1027

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Con esto ya tendríamos interconectado nuesto Datacenter local con nuestro Datacenter en VMware Cloud on AWS. En siguientes entradas veremos más pasos para dejar esta configuración de red perfectamente configurada, como es la configuración de DNS y Firewall, etc.

#VMwarePorvExperts

1028

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

5. Despliegue y Configuración de Cloud Gateway para habilitar Hybrid Cloud Extension en VMC Es turno de ver cómo podemos controlar con una vista única nuestros dos vCenter, el local en nuestro Datacenter y nuestro vCenter en VMware Cloud on AWS usando Hybrid Linked Mode.

5.1 Hybrid Linked Mode

El Hybrid Linked Mode nos permite enlazar nuestra instancia de VMware Cloud en AWS vCenter Server con un dominio vCenter Single Sign-On local. Si vinculamos nuestro servidor de vCenter en la nube a un dominio que contiene varias instancias de vCenter Server enlazadas mediante el modo vinculado mejorado, todas esas instancias se vincularán a nuestro SDDC en la nube.

#VMwarePorvExperts

1029

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Usando el Hybrid Linked Mode, podemos: •

Visualizar y gestionar los inventarios de nuestros centros de datos VMware Cloud y VMware Cloud en AWS desde una única interfaz de vSphere Client, a la que se accede mediante nuestras credenciales locales.

•

Migrar cargas de trabajo entre nuestro centro de datos local y SDDC en nube.

•

Compartir etiquetas y categorías de etiquetas desde la instancia de vCenter Server a nuestro SDDC en la nube.

Existen dos opciones para configurar el Hybrid Linked Mode. Sólo podemos utilizar una de estas opciones a la vez. •

Podemos instalar el dispositivo Cloud Gateway Appliance y utilizarlo para enlazar desde nuestro centro de datos local a su SDDC en nube. En este caso, los grupos de Active Directory se asignan desde el entorno local a la nube. No es necesario que añadamos Active Directory como fuente de identidad en nuestro servidor vCenter en nube.

•

Podemos enlazar desde nuestro SDDC en la nube a nuestro centro de datos local. En este caso, debemos añadir Active Directory como fuente de identidad al servidor vCenter de cloud computing.

El primer paso que haremos será irnos hasta nuestro portal de descargas para descargar VMware vCenter Cloud Gateway:

Una vez hemos descargado y ejecutado el instalador, un asistente nos mostrará el camino para realizar la instalación del appliance:

#VMwarePorvExperts

1030

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Vemos que se compone de dos fases, la primera es desplegar el appliance en nuestro entorno, y la segunda se corresponde a la configuración del mismo, vamos allá:

#VMwarePorvExperts

1031

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Aceptaremos la EULA una vez leída:

#VMwarePorvExperts

1032

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Seleccionaremos nuestro vCenter local donde queremos desplegar este appliance:

#VMwarePorvExperts

1033

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Una carpeta dentro de la Infraestructura donde queramos almacenar este appliance:

#VMwarePorvExperts

1034

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Seleccionaremos ahora el host o cluster donde queremos lanzar el appliance:

#VMwarePorvExperts

1035

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Y le asignaremos un nombre y una contraseña de root:

#VMwarePorvExperts

1036

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Es el turno de seleccionar donde queremos lanzar este appliance, y si lo queremos en modo Thin:

#VMwarePorvExperts

1037

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Y el último paso será configurar la parte de Networking, muy importante es que la entrada de DNS, así como la reverse DNS, estén configuradas para el nombre e IP que seleccionamos:

#VMwarePorvExperts

1038

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Seleccionaremos el SSO que queremos usar, en este caso es el mismo que el propio VCSA ya que tengo mi PSC en el mismo equipo:

#VMwarePorvExperts

1039

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

El proceso comenzará y el appliance comenzará a desplegarse, en mi caso ha tardado unos 10 minutos:

#VMwarePorvExperts

1040

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Ahora es el momento de la segunda fase, haremos click en Start:

#VMwarePorvExperts

1041

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Nos mostrará el asistente un poco de información de lo que significa el Hybrid Linked Mode, etc:

#VMwarePorvExperts

1042

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Seleccionaremos aquí el vCenter Server que tenemos en VMware Cloud on AWS, y las credenciales, todo disponible desde nuestro portal de SDDC, importante que seleccionemos que usuarios de nuestro dominio local pueden acceder a este vCenter en Cloud:

#VMwarePorvExperts

1043

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Y pasados apenas unos minutos tendremos ya todo preparado, podremos hacer click en lanzar el vSphere Client:

#VMwarePorvExperts

1044

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

Y ya podremos ver un vSphere Client HTML5, con los dos vCenter conectados, podemos ver el vCenter de cloud y el nuestro local, no solamente esto, podemos mover VMs entre ellos, templates, etc. Ya tenemos nuestro Hybrid Linked Mode perfectamente configurado y funcionando:

#VMwarePorvExperts

1045

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

A partir de aquí, ya podemos administrar ambos entornos como si fueran uno solo, desplegar VMs, realizar replicas entre Datacenters, mover cargas de trabajo, etc. Nota: Recordar que tenemos dos maneras de administrar nuestro SDDC en VMware Cloud on AWS, una es la consola de gestión del propio SDDC, donde podemos editar configuraciones de Red, autenticación y mucho más, al más alto nivel posible. Y otra es la gestión mediante vCenter, que será donde podremos administrar por supuesto todos los recursos lógicos que tenemos a nuestra disposición, vSAN, VMs, Hosts ESXi, Resource Pools, etc.

#VMwarePorvExperts

1046

Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz

#VMwarePorvExperts

1047

Patrocinadores GOLD

SILVER

BRONZE

#VMwarePorvExperts

1048

Capítulo 21 Consejos para equipos que administran VMware Ariel Sánchez Mora

#VMwarePorvExperts

1049

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

1. Introducción En los siguientes párrafos trato de generalizar mis consejos a casos que aplican a la mayoría de nuestros lectores. Esto es producto únicamente de mi experiencia y discusiones de lo que hemos visto en la comunidad. Se que habrá empresas muy pequeñas donde no habrá suficientes recursos (humanos o económicos) para lograr implementar ciertas recomendaciones, y también habrá empresas mucho más grandes donde los casos se sentirán muy sencillos. Me encantaría que compartan estas ideas y discutan con sus compañeros de trabajo, y me envíen sus comentarios sobre cómo mejorar este contenido. Uso el término Tecnología de Información (TI) como el grupo de personas encargadas de manejar la infraestructura informática de una empresa. No limito los roles dentro de este grupo; conceptualmente incluye a toda persona involucrada con configuración, soporte, gestión, etc.

Ariel Sánchez Mora @arielsanchezmor

#VMwarePorvExperts

1050

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

2. Todo servicio en TI debe ser brindado por un equipo, especialmente VMware Parafraseando al padre de la gerencia moderna Peter Drucker: en el contexto de una empresa, los gerentes son los responsables de manejar recursos con el fin de proveer servicios que la empresa necesita. Si hay algo mal en el servicio, debes hablar con el gerente asignado para saber qué sucede. Los gerentes, por definición, deben estar listos para brindar reportes y ejecutar acciones correctivas con el fin de brindar un buen servicio. Si has oído hablar de VMware antes, sabrás por qué lo traigo a coalición: las soluciones de VMware son “gerentes” en software que administran recursos de TI para lograr efectuar los servicios de infraestructura deseados. Por ejemplo, vSphere administra CPU, memoria, red y almacenamiento. En efecto, VMware permite la gerencia de todo aspecto de la infraestructura: empezaron con virtualización de sistemas operativos y hoy en día abarcan todo tipo de redes, soluciones multi-nube y dispositivos móviles. Las soluciones de VMware fueron pioneras en proveer un “poder gerencial” para toda la infraestructura de TI, y siguen siendo las soluciones más completas., Esto es gracias a su dedicación a proveer aplicaciones de infraestructura programáticas (soluciones de software) - colaborando con la capa física, sin depender de ella para su configuración. Se puede decir que su mayor innovación fue permitir una capa de observabilidad y control total de infraestructura, y gracias a ello ahora tenemos la capacidad de ajustes en software - mucho más ágil y económico q cambiar los componentes de hardware. Debido a que es tan importante, debemos invertir un poco de tiempo en formular una estrategia que nos permita obtener el mayor provecho de las soluciones de VMware. Dichas soluciones constituyen una importante inversión en costo directo y en recursos humanos de la empresa. Es oportuno y recomendado empezar hablando de la estrategia de crear un equipo que estará a cargo de todos los aspectos de esta plataforma. Nota: Existen varias escuelas de pensamiento de cómo se debe manejar TI en general (ITIL, COBIT por ejemplo) pero por el momento voy a simplificar y aplicar directamente a la administración del portafolio de VMware. Empresas más grandes estarán acostumbradas a esto y a tener arquitectos de TI empresariales; lo que quiero recalcar que la falta de estos puestos y procesos a nivel global de la empresa no debe limitarnos, y podemos implementar buenas prácticas para el manejo de las soluciones de VMware sin importar nuestro estado actual. Mi observación personal es que muchas empresas no crean equipos para manejar el ciclo de vida de las soluciones de VMware, simplemente porque no están acostumbradas a crear equipos similares para otras plataformas. El concepto de “manejo de ciclo de vida” en TI, simplificado, es que todo servicio que provee TI debe pasar por las fases de: a. valoración de las necesidades y soluciones disponibles b. diseño de la solución elegida c. planeación del proyecto d. implementación e. validación f. soporte

#VMwarePorvExperts

1051

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

g. retiro de la solución.

Tristemente es muy común que la falta de recursos o de experiencia conlleva a que todos estos procesos son efectuados por una o dos personas, muchas veces sin el tiempo debido y sin ser bien documentados. No debemos aceptar que esta forma de proceder es la correcta, pues sólo creará problemas más grandes y llevará a deuda técnica. Definamos la deuda técnica como “cosas que sabemos que debemos resolver, pero no tenemos tiempo o el conocimiento adecuado, y lo dejaremos así por ahora”. Una función importante de todo encargado de TI debe ser reducir la deuda técnica. Para evitar hundirnos más en el hueco, hay que dejar de cavar. Es común que varios miembros del equipo de servidores sepan qué es vSphere, la plataforma líder en virtualización de sistemas operativos por la cual VMware es famosa, y hasta tengan cierta destreza y familiaridad con la instalación y administración del producto. Elegir a un único encargado de la plataforma VMware es tentador - una persona se haría responsable, con libertad para proceder según mejor le parezca. Debido a que productos como vSphere son sencillos de instalar, conseguirá resultados rápidamente y pensaremos que todo va bien. Pero esta es la estrategia equivocada, porque VMware es mucho más que vSphere. Con el paso del tiempo, las decisiones que generan problemas y deuda técnica se pueden trazar de vuelta a un administrador que no tenía claridad en los conceptos de la plataforma y los efectos a largo plazo. A su defensa, hay que resaltar que rara vez se le otorga tiempo suficiente para estudiar (al menos llevar una clase y certificarse), o no tuvo con quien discutir ideas y dudas, e hizo lo mejor que pudo. En muchísimos casos, este administrador ya no está en la compañía y el siguiente encargado debe hacer doble trabajo: implementar nuevos proyectos evitando y resolviendo problemas de deuda técnica de su antecesor. Es importante dejar de pensar en un solo administrador que sabe todo de VMware, y pensar en un equipo constituido por varias especialidades que estará incluido en todas las etapas del manejo de VMware. Los principales beneficios de contar con un equipo: a. Mejora la calidad durante todas las etapas de ciclo de vida del servicio. b. Soporta la ausencia de miembros para que puedan ir a clases, estudiar y lograr certificaciones, tomen vacaciones y asistan a conferencias. c. Al dividir la carga, permite pensar y discutir estratégicamente desde varios puntos de vista. d. Mejora la comunicación interpersonal y conlleva a más rigor en la documentación de los proyectos. e. Se logra sucesión sin perder información o ímpetu cuando un miembro debe dejar el equipo.

Viendo estas ventajas, es claro que la moral y la satisfacción laboral serán mucho más altas cuando los ingenieros son parte de un equipo, y además lograrán mejor trabajo. Es una situación donde todos ganan. Es importante determinar las personas más indicadas para ser parte de ese equipo. Tradicionalmente se ha visto que VMware cae bajo la responsabilidad del equipo de servidores. Como explique anteriormente, yo considero que esto es problemático: VMware afecta a todas las funciones de TI, incluidos los equipos de redes y los dispositivos de usuario. Si no se trabaja desde el nivel de arquitectura y diseño con el resto de los equipos, habrá trabajo redundante y política interna que

#VMwarePorvExperts

1052

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

retrasará la adopción de la tecnología. Debido a que las soluciones de VMware tocan toda la infraestructura de una empresa, los equipos de VMware deben tener integrantes que abarcan varios equipos de TI. La división más básica de equipos de Tecnología de Información (TI) va algo parecido a esto: a. Un equipo a cargo de redes. b. Un equipo a cargo de servidores. c. Un equipo a cargo de dispositivos de usuario (móviles o estaciones de trabajo).

El primer consejo que le doy a empresas que van a adoptar VMware es que abran sus mentes a lo que viene en el futuro: el Centro de Datos Definido por Software (SDDC, por sus siglas en inglés, Software Defined Data Center). Es mejor empezar el camino de VMware asignando ingenieros de cada uno de los diferentes equipos, escogiendo personas con experiencia interna, que entienden bien el negocio y los procesos de la compañía. Esto inmediatamente permite identificar oportunidades donde las soluciones tendrán mayor impacto y da credibilidad a los proyectos que se van a formar. Además, debido a que en VMware existen varias soluciones y cada solución puede tomar considerable tiempo en dominar, recomiendo identificar también a ingenieros con mucha sed de aprender, dedicados a trabajar bien en equipo y con iniciativa propia. Cuando se combinan experiencia, influencia, conocimiento de la empresa con sed de aprender, mente abierta y buena comunicación, se crean equipos muy efectivos y hay buena química en TI. Hablaré un poco más de actitudes que llevan al éxito en VMware en este capítulo. Quiero aclarar que el “Equipo VMware” es responsable por la plataforma total, pero es claro que cada implementación de servicio será un proyecto. En cada proyecto es donde se pueden asignar líderes a cargo del proyecto, pero aquí me gustaría incluir otro concepto. Es importante que los líderes o pilotos tengan un co-piloto que esté completamente incluido en todas las decisiones y trabajo. El concepto es muy similar a programación en pareja (pair programming). Es aquí donde unir a uno o varios ingenieros experimentados y establecidos con un ingeniero con sed de aprender conlleva a sus máximos beneficios. Mejor aún, combinar personas de diferentes equipos, por ejemplo: a. Proyecto vSphere: ingeniero de sistemas experimentado con ingeniero de dispositivo de usuario con sed de aprender. b. Proyecto NSX: ingenieros de redes y servidores experimentados con ingenieros de redes y servidores con sed de aprender. c. Proyecto Airwatch: ingeniero de dispositivo de usuario experimentado con ingeniero de sistemas con sed de aprender

Hemos hablado de los beneficios de establecer un equipo de VMware, qué tipo de integrantes deben conformarlo, y cómo manejar el liderazgo de los proyectos individuales. Al establecer un equipo empresarial para todas las soluciones VMware se podrán tomar decisiones de arquitectura eficientes, se simplifica el planeamiento futuro y se desarrolla a nuevos miembros. He visto ambos casos en la vida real - cuando hay un equipo multidisciplinario y cuando es solo un encargado - y el modelo multidisciplinario es mucho más eficiente, ágil y trae los mejores resultados. El ambiente laboral se vuelve una de las razones por las cuales los empleados permanecen en la compañía. Crear este modelo completo requiere importante liderazgo en las posiciones gerenciales y ejecutivas

#VMwarePorvExperts

1053

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

de TI y una empresa que tenga el objetivo de liderar en sus soluciones tecnológicas. Pero le quiero decir al lector de este libro que su cargo en la empresa y situación particulares no son una limitación. Para implementar estas estrategias en su ambiente, lidere la iniciativa y explíquela a sus compañeros. No es siempre líder el que tiene el título, sino el que lleva a todos a una mejor situación. Explique a sus jefes, a sus colegas y lleve un cuaderno con ideas de cómo mejorar las cosas. Cuando haya una situación desfavorable, tome la oportunidad de explicar las ventajas de haberlo hecho desde la perspectiva de un equipo global, identificando el problema y trayendo la solución. Por su impacto y beneficios, los proyectos con soluciones de VMware tienden a mostrar valor rápido y crecer vertiginosamente. Por ello es importante haber establecido un equipo que pueda escalar a nuevas demandas y adaptarse rápidamente sin perder calidad. Un equipo interdisciplinario que combina experiencia y sed de aprendizaje es la mejor forma de adoptar VMware. Aún si los equipos no deciden implementar todas las soluciones de VMware en un ciclo de tecnología, entender los conceptos e involucrar a miembros de varias áreas es crucial para llegar a tener agilidad y transformación digital en las empresas a mediano y largo plazo.

#VMwarePorvExperts

1054

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

3. Actitudes y estrategias que llevan al éxito en VMware Ya hablamos de cómo empezar bien en la adopción de las soluciones de VMware, formando un equipo multidisciplinario con integrantes experimentados y sedientos de aprender. Ya que empezamos bien, sigamos bien adoptando buenas costumbres que aplican a casi todo ambiente. Empecemos con el detalle de cómo crear expertos internos en nuestro equipo de VMware. Hablaré en el marco de una empresa que está adoptando soluciones de VMware a pesar de que muchísimas empresas ya tienen vSphere instalado, pues esto aplica cuando uno adopta nuevas soluciones, como NSX. En general, las soluciones de VMware son fáciles de aprender pero difíciles de dominar. Aún los cursos de Instalar Configurar y Administrar (más conocidos por sus siglas en inglés, ICM) no son suficiente para ser un buen ingeniero - cubren el material a nivel teórico pero no entran en diseño, por ejemplo. Personalmente me gustaría que todos los administradores tuvieran el VMware Certified Professional (VCP) de las soluciones que van a implementar, pues es un examen relativamente difícil que obliga al estudiante a leer la documentación del producto. Ya con algo de experiencia, los exámenes de VMware Certified Advanced Professional (VCAP) son buenos desafíos, midiendo conocimiento de vida real y diseño. Quiero recalcar esta preparación porque los ingenieros en la compañía pueden tomar los cursos y exámenes cuando todavía no se ha comprado el producto y empezado el proyecto. Llevar los cursos y exámenes previo a la compra va a ser una mejor estrategia para su empresa. Comúnmente el proceso de compra incluye hablar con representantes de VMware que ayudan a crear la solución y tener esta preparación permite hacer mejores preguntas durante el ciclo de ventas, lo que conlleva a sesiones y compras más satisfactorias para todos. Cuando planeamos con anticipación, siempre vamos a lograr un mejor resultado. Sin embargo, sé que llevar clases y pasar exámenes antes de implementar el producto no es lo común. Las clases y exámenes requieren inversión monetaria y de tiempo, y tiende a ser que los proyectos de VMware requieren empezar inmediatamente, con poca planificación previa de las destrezas de los ingenieros. Entonces recordemos, aunque el producto es fácil de instalar y poner a correr, debemos saldar la deuda de conocimiento en algún momento, para sacar el mayor provecho. Hablando de la situación común - ya implementado, no hubo tiempo para que todos llevaran una clase y menos un examen - mi recomendación es la siguiente. Lee toda la documentación. Si logras realmente absorber la documentación entera, sabrás más que una persona que llevó el ICM y que tiene el VCP. En efecto, aún los exámenes VCAP te refieren a la documentación para el estudio. Me siento cómodo haciendo esta recomendación porque toda la documentación es gratis, disponible al público y se encuentra en https://www.vmware.com/support/pubs/. Puedes hacer una búsqueda de “VMware documentation” en Google y será el primer link. He comprobado que puedes cambiar el idioma y leer la documentación en español, aunque no me extrañaría que primero salga en inglés, y sea más completa en inglés. Hablemos de un tema que tristemente no podemos evitar: no hay mucha información en español. A pesar de que hay traducciones, no son siempre confiables. Debido a esto, una de las mayores inversiones como profesional de TI es tener un conocimiento de inglés avanzado para encontrar y asimilar información cuando no se encuentra en español. Con este libro tratamos de cambiar eso, pero ocuparemos muchos más voluntarios, durante mucho tiempo, para llegar a esa meta donde una persona no ocupa saber inglés. La parte de “realmente absorber” al leer la documentación oficial es lo difícil, porque hay varios

#VMwarePorvExperts

1055

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

conceptos que serán difíciles al principio. No te desanimes, escribe la pregunta en tu cuaderno y sigue. No serás el único que se ha preguntado algo - la mayoría de las preguntas que te harás están explicadas en Internet si las buscas en Google. Si no es a través de una respuesta oficial de VMware, será quizás en un blog o foro. VMware tiene una comunidad grande de usuarios que se dedican a ayudar a otros; hablaremos de la vCommunity en la siguiente sección. Quiero recalcar dos tipos de documentación, adicionales a los documentos oficiales, que son sumamente importantes para todo ingeniero de plataformas VMware. Hablo de leer las notas de lanzamiento (Release Notes) que vienen con cada nueva versión del producto, y las Bases de Conocimiento (Knowledge Base, o KBs). Ambos son críticos para poder efectuar adecuadamente las instalaciones y actualizaciones de producto. En particular, hay dos KBs que referencio con frecuencia. La primera es la lista de versiones de productos, 1014508, debido a que contiene todos los productos de VMware, con numero de build y fecha de publicación. La segunda es el orden de actualización cuando hay varias soluciones de VMware instaladas y dependientes una de la otra. Se usa la versión de vSphere como base, por ejemplo para vSphere 6.7 el número de KB es 53710. Puedes poner en Google “KB 53710” y te lo desplegará como primer resultado. Aparte de la documentación gratuita, hay varios libros que tienen información valiosa y que no es fácil de conseguir de otra forma. En particular, los libros donde Scott Lowe, Duncan Epping y Frank Denneman han sido co-autores o autores principales son buenísimos y a veces hasta se consiguen las versión eBook gratis. En particular, me gustan mucho los de la serie “Deep Dive”. También, si vas a implementar Horizon, recomiendo el libro de Johan Van Amersfoort. Los libros se pueden leer más rápido que la documentación, pero no la sustituyen. Ahora hablaré de dos recursos web que VMware provee y que son importantísimos para los ingenieros: la Lista de Hardware Compatible (más conocido por sus siglas en inglés: HCL, Hardware Compatibility List) y la Matriz de Interoperabilidad de productos VMware (referido como el Interoperability Matrix). Empezando con el HCL: si uno compra servidores modernos típicamente no hay mucho de qué preocuparse, pues todos los vendedores certifican sus plataformas, con sus varias opciones de procesador, tarjetas de red y sistemas de almacenamiento. Pero si por motivos económicos debes usar servidores vas viejos o construir tus propios servidores, debes de estar consciente si lo que quieres combinar está en la lista, pues VMware provee soporte de producción sólo si la versión del software y el hardware están en la lista. VMware provee drivers para muchísimos dispositivos en su imagen base. Estos drivers son soportados por VMware como parte de su validación y se llaman inbox drivers. Sin embargo los partners de VMware pueden añadir más drivers a medida que se descubren bugs y nuevas funcionalidades, muchas veces también requiriendo una actualización de firmware. Cuando un partner hace esto, los drivers se llaman de tipo async. Revisemos un caso de vSphere. Cuando cambian versiones de producto, por ejemplo de 5.5 a 6.0, VMware puede elegir cambiar completamente el driver o versiones soportadas, por lo que es importante revisar las consecuencias de HCL al efectuar actualizaciones de versiones mayores. Asimismo, cada vendedor de servidor debe re-certificar sus plataformas. Muchos fabricantes no certifican hardware que ya tiene 3 generaciones más nuevas; en esos casos, debes permanecer en las versiones soportadas hasta que puedas cambiar el hardware. Esto no es un problema grande pues vCenter permite manejar hasta 3 versiones anteriores de ESXi. Un caso común que veo hoy son servidores HP de generacion 7 o Dell de 11va generación que deben permanecer en vSphere 6.0 y el último vCenter que los podrá soportar es 6.7. La gran mayoría de los casos donde hay una falla en el hipervisor, también conocido como Purple Screen of Death (PSOD) es debido a un driver o firmware que no estaba en el HCL. También puede

#VMwarePorvExperts

1056

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

ser que a una combinación que estaba listada en el HCL se le descubren problemas y se le pide a los clientes que pasen a usar otra versión de driver o firmware. Por ello al instalar soluciones de VMware debemos estar muy conscientes de que lo que hemos instalado esté completamente soportado, y debemos marcarlo así en nuestra documentación. Si se usan Inbox drivers, VMware deberá proveer la solución. Si son drivers async, es el fabricante de hardware quien proveerá la solución. Este tema llega a ser aún más importante cuando hablamos de soluciones de VMware que dependen de vSphere; por ejemplo NSX-V Datacenter depende de las tarjetas de red configuradas a través de ESXi. Mostrar que has adherido a las recomendaciones del HCL es la certificación de que has hecho tu trabajo responsablemente. Recalco que no es sólo cuando construimos el ambiente que tenemos que estar pendientes del HCL. Al efectuar todos los pasos de una actualización se pueden cambiar las versiones de drivers. Es importante mantener actualizada la documentación a medida que cambian los ambientes. El otro recurso en línea que mencioné es la Matriz de Interoperabilidad. Este recurso nos permite determinar qué versiones de software de VMware están certificadas para funcionar entre sí. Cuando hablamos de implementar varias soluciones de VMware, es importante ver que versiones debemos instalar - casi siempre con respecto a vSphere. Lo más común es que se soporten versiones que han salido en periodos de tiempo parecidos. Hablemos un poco más sobre el tema de actualizaciones. Si leemos y seguimos la documentación, revisamos los KBs y notas de lanzamiento y sabemos cuáles versiones de softwares son compatibles, tendremos una alta posibilidad de éxito. Lo que quiero mencionar ahora es terminar todos los pasos de una actualización. Tristemente es común ver ambientes donde los principales componentes fueron actualizados, pero no se completó 100% el trabajo. Por ejemplo, el vCenter y ESXi fueron actualizados, pero las máquinas virtuales siguen con VMware tools o VMware hardware de versiones anteriores. Esto típicamente muestra que los administradores no están haciendo parches en sus sistemas operativos pues nadie quiere apagar las máquinas virtuales para hacer estos mantenimientos. Debemos tratar la administración de infraestructura de TI con respeto y dedicación y asegurarnos de aplicar los parches de seguridad y los mantenimientos necesarios. En el tema de seguridad es mi experiencia que las cosas necesarias para mantener un ambiente funcionando con responsabilidad son en general sencillas, pero requieren ser aplicadas consistentemente. Cuando configuramos un ambiente siempre debemos asegurarnos como mínimo, que: a. el reloj sea correcto en todos los sistemas (configuración del Network Time Protocol, NTP por sus siglas en inglés) b. los logs sean enviados a un servidor de syslog (si la empresa no tiene un servidor central, instalar VMware LogInsight) c. los permisos de administrador sean dados a usuarios individuales, no a cuentas genéricas.

Es cierto que habrá cuentas de servicio para backups y la cuenta default no se puede cambiar o desactivar pero si se puede controlar su acceso. Con respecto a las contraseñas de root y Administrator me gusta ver que los equipos tengan un sistema de manejo de contraseñas. Considero q lo mínimo que toda empresa debe tener es una base de datos de KeePass o Password Safe en un share con los permisos de acceso necesarios para que solo el equipo VMware acceda a la información necesaria, y que se respete una política de expiración de contraseñas. Es aún mejor cuando se cuenta con soluciones empresariales.

#VMwarePorvExperts

1057

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

Si administramos estas tres cosas bien y mantenemos la aplicación de parches de seguridad no queda muchísimo más trabajo para asegurar la plataforma. La documentación explica que la plataforma de infraestructura debe estar en redes internas, protegida por firewalls. Hay documentos que VMware provee explicando todas las configuraciones de seguridad llamados Security Hardening Guides. Con la información de estos documentos se pueden crear políticas de seguridad para la empresa, pero las tres configuraciones que mencioné son condiciones básicas que deben de estar en todos los ambientes. Hablemos por un momento sobre la documentación. Muchas personas están acostumbradas a nada más conectarse a vCenter y piensan que con revisar algunas secciones es suficiente para entender el ambiente. Esto es una ilusión: si repasamos cuáles son todas las opciones configurables de un producto, por ejemplo vSphere ESXi, vemos que hay muchísimas opciones y no todas son visibles desde las interfaces gráficas. Crear documentación manualmente toma mucho tiempo. Hay varias herramientas gratuitas para crear documentación. Yo estoy involucrado con una de ellas junto con mi amigo Edgar Sanchez (@ edmsanchez13). Cuando creamos vDocumentation fue porque vimos la necesidad de tener información del ambiente en excel para un tiempo específico. Otras herramientas que se pueden usar son RVTools, vCheck, el “As Built Report” y vDiagram - simplemente búscalas en Google, sabiendo que no son herramientas oficiales sino de la comunidad. Al usar estas herramientas gratuitas debemos estar conscientes de que estas fueron creadas por personas que pensaban en cierta situación y esta situación puede no ser la misma que la nuestra. Si vemos que falta información que ocupamos, todas estas herramientas son de código abierto y se puede trabajar con los autores para incluir nuevas funcionalidades, e incluso aportar el código que falta para hacer el proceso más rápido. Finalmente, si heredas un ambiente, es importante buscar (o empezar a crear) documentación histórica de los criterios de diseño del ambiente antes de implementarlo. Es más fácil que tratar de descifrar el ambiente después de haber sido implementado, y por ello debe ser parte de cualquier implementación que nosotros efectuemos. Más allá de la documentación quiero hablar un poco sobre cómo se puede manejar el portal de licencias de VMware. Cuando uno compra la solución de VMware se le da acceso a un portal en línea donde están las licencias. Hay que entender que siempre se empieza con dos usuarios importantes en ese portal: el procurement contact y el superuser. Siempre deben haber cuentas con este rol, y no puede haber más de una con ese rol. He visto empresas donde para simplificar el manejo de licencias se usa un solo usuario ligado a un correo que básicamente envía cualquier cambio que se haga a todo el equipo de VMware de la empresa (por ejemplo, [email protected]). Este método ayuda a que todos quienes tienen acceso a la cuenta puedan ver las mismas licencias, todos puedan hacer actualizaciones de las notas en las licencias y permite que los equipos distribuidos puedan trabajar más efectivamente. El principal problema con esta solución es cuando un miembro se va, pues debe cambiarse la contraseña, lo cual no es tan difícil si hay buen manejo del resto de las contraseñas. Si en vez se deciden hacer varios logins al portal de VMware se debe definir con el equipo por qué o cuáles son los permisos que se van a usar. Es importante entender que el procurement contact es crucial para renovar los contratos de mantenimiento y manejar la relación con VMware y por ello debe ser alguien con autoridad en la empresa para tener esas discusiones. El superuser es el usuario con acceso a cambiar los permisos en todas las licencias, que se asignan por folder. Es importante considerar que a pesar de que un usuario no deba tal vez hacer actualización de licencias, puede requerir ver la licencia para poder abrir un ticket de soporte en ese producto. Por ello las personas asignadas al procurement contact y el superuser deben ser conocidos por todos y deben estar familiarizados con el portal para ayudar al resto del equipo según se necesite.

#VMwarePorvExperts

1058

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

Dos cosas que me gusta ver en los portales de VMware son notas en las licencias y orden en las carpetas. Por ejemplo, la mayoría de servidores hoy en día son de 2 o 4 CPU’s. Al dividir las licencias de VMware para que cada servidor tenga una licencia individual, es fácil mantener el control del uso de la licencia y si se debe renovar o no. Es mucho más complicado mostrar orden con una licencia grande que se ha aplicado en varios lugares. Asimismo, crear folders por proyecto, región o estatus de mantenimiento es más sencillo de entender que la práctica de VMware de crear un folder por cada orden de compra. El consejo más importante - adoptar estándares internos y seguirlos consistentemente. Tradicionalmente VMware mantiene tres versiones separadas del software en soporte: a. La versión más reciente es donde se sacan las nuevas funcionalidades primero, así como las actualizaciones de seguridad. b. La versión del medio recibe algunas nuevas funcionalidades y todas las actualizaciones de seguridad, con un ligero retraso. c. La versión más vieja sólo recibe las actualizaciones de seguridad.

Cuando se trata de soluciones nuevas con bastante desarrollo de funcionalidades (un buen ejemplo es NSX o vSAN), es importante estar corriendo la versión más nueva. vSAN, al ser almacenamiento, es de suma importancia pues queremos que cualquier problema sea arreglado lo más pronto posible. En mi experiencia las compañías que están corriendo versiones viejas y fuera de soporte lo hacen simplemente porque no han tenido el tiempo para planificar bien una actualización. Muchas veces no tienen el conocimiento para crear un plan concreto y tienen miedo de causar downtime (tiempo inoperativo, lo que nadie quiere). No debemos dejar que las versiones que corramos sean las que están más lejos de la versión más nueva y correr el riesgo de no estar en una versión soportada. VMware internamente se enfoca en estabilidad - la versión más estable de VMware es la más nueva! En la siguiente sección hablaré de estrategias que permiten hacer cambios sin causar downtime.

#VMwarePorvExperts

1059

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

4. La importancia de ambientes de prueba, homelabs y Hands On Labs Una situación que encuentro comúnmente es que muchos ambientes de producción no tienen a su lado un ambiente de prueba. Cuando hablo de ambiente de prueba me refiero a un ambiente representativo de lo que se está corriendo en producción, cuya función es servir para practicar cambios antes de hacerlos en producción. El esfuerzo para levantar un ambiente de prueba no es particularmente alto pero conlleva importantes beneficios cuando se usa para practicar futuros cambios en producción: a. Familiarizarse con los pasos y poder investigar detalles sin estar causando downtime. b. Tener más tiempo para planificar qué es lo que se ocupa hacer y en qué orden. c. Comprobar que las integraciones entre varias soluciones o con otro software funcionan después de una actualización. d. Entrenar a nuevos miembros y elaborar documentación.

Los ambientes de prueba pueden ser ubicados en servidores más viejos pues el desempeño es de baja prioridad - lo que estamos probando principalmente es el software. Sin embargo, si las condiciones lo permiten, es ideal mantenerlo igual al ambiente de producción para no ser sorprendidos por una dependencia del hardware. Hay otros dos casos que quiero hablar, los homelabs (laboratorios de casa) y los Hands On Labs. Es mi opinión personal que no debemos depender sólo de los ambientes de trabajo para aprender sobre nuevas plataformas sino que también debemos disponer de ambientes que podamos destruir y reconfigurar según nuestras necesidades personales y donde podamos además experimentar con nuevas tecnologías. No es válida la excusa que debido a que la empresa no tiene una plataforma de prueba nosotros no podemos aprender en casa. Una tecnología que será importante para muchos administradores de VMware es aprender sobre Kubernetes. Si no se usa todavía en la empresa es probable que se usará en los próximos cinco años. Un homelab es el lugar ideal para aprender sobre Kubernetes pues no tenemos riesgo alguno de ocasionar problemas en producción y nos permite mucha flexibilidad en el aprendizaje. También en un homelab puede trabajar con equipos mucho más baratos que los equipos que se usan en el trabajo plataformas populares son Intel NUC, servidores construidos con componentes de PC, o los servidores de pequeño formato como Supermicro. Si se puede añadir un dispositivo de almacenamiento de red (NAS) es aún mejor (los Synology son muy populares) y también un switch con ciertas capacidades empresariales. Entiendo también que no es fácil construir por primera vez un homelab - se puede gastar bastante tiempo y dinero en diseñarlo y construirlo. Muchos empezamos con una computadora poderosa principalmente en memoria RAM, a la q le dedicamos un disco duro y hacemos un dual boot a ESXi, usando nested hosts. En internet encontrarás mucha información y guías para hacer esto. Si no quieres gastar dinero y sacrificas un poco de flexibilidad, es más práctico ir a los Hands on Labs que regala VMware en línea y hacer tus pruebas ahí. Si no has efectuado un laboratorio anteriormente, debe saber que los ambientes son reales y puedes elegir no seguir el laboratorio, sino simplemente usar el ambiente para hacer tus pruebas. La única desventaja es que sus ambientes están limitados

#VMwarePorvExperts

1060

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

en tiempo por lo cual cualquier cosa que construyas se perderá después de algunas horas - pero el conocimiento queda. No hay excusa para hacer cambios en producción sin haber ejercido la oportunidad de practicar los cambios antes de hacerlos. El pecado más grande de un administrador de VMware es causar downtime. Piénsalo así: si introducir VMware como la capa que maneja la infraestructura diera peores resultados que manejar los programas directamente sobre el hardware, nadie lo usaría y no estarías leyendo este libro. Como administradores de la plataforma de VMware debemos procurar que si hay downtime no sea por la plataforma de VMware, y no sea causado por nuestras acciones o falta de preparación. Debemos siempre prepararnos para los peores escenarios y tener soluciones a los posibles problemas que puedan surgir.

#VMwarePorvExperts

1061

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

5. Involucrarse en la vCommunity es indispensable Gracias a programas como vExpert, que se dedica a fomentar la discusión y ayuda entre usuarios, y al VMware User Group (VMUG), se ha formado un ambiente muy acogedor a principiantes y nuevos integrantes. Yo le debo muchísimo de mi crecimiento profesional a estos programas y quiero asegurarme que los lectores de este libro sepan que existen y que también le saquen provecho. Existe el concepto de vCommunity: la comunidad mundial de administradores y empleados de VMware que están ahí para ayudarse entre sí. Típicamente lo veras con # porque se usa principalmente en Twitter cuando alguien hace un post donde se pide o se aprecia ayuda. El termino vCommunity sirve para incluir todas las diferentes expresiones de esa ayuda. En mi opinión, las principales vías donde se manifiesta la vCommunity son: a. Los foros de VMware, principalmente VMTN (communities.vmware.com). b. Las reuniones locales y virtuales del VMware User Group. c. Las contribuciones individuales en blogs, podcasts y grabaciones de YouTube. d. Twitter, tal vez la más importante.

Cada uno de los autores de este libro te dio al menos su Twitter handle. Síguelo y a medida que lees el libro, si tienes ideas, mándale un mensaje por ahí a los autores - verás que están muy dispuestos a oír tu opinión y discutir contigo cómo mejorar el contenido. Cuando ayudas al resto a mejorar estarás participando tú también en el vCommunity. Todos tenemos un trabajo que hacer pero cuándo somos parte de una comunidad mundial donde se incentiva ayudar a otros, el trabajo se hace más liviano. Descubrirás que hay muchas más personas que saben de VMware y hablan espanol de lo que pensabas. Además, las relaciones que se hacen en línea, a nivel mundial, se vuelven reales cuando asistes a eventos como VMworld y VMUGs en varias ciudades. Debo también recomendar que te suscribas a ciertos podcasts que son buenos para mantenerse al tanto con VMware y tecnología en general. La mayoría están en inglés y por ello permiten practicar el idioma: a. El VMTN community podcast es la herramienta oficial del grupo de comunidad de VMware. b. Virtually Speaking es creado por empleados de VMware y está enfocado principalmente en storage (vSAN, VVOLs, etc). c. Gigacast es un podcast producido por la comunidad y más relajado, donde se invita a miembros del vCommunity para que den sus opiniones y permite conocernos mejor. d. vBrownBag

En particular (porque soy miembro en dos idiomas y 3 continentes) quiero resaltar a vBrownbag. No lo veo como un podcast tradicional, sino más bien es una herramienta de aprendizaje creada por y para la comunidad. Cada semana se invita a un especialista y se le pide que exponga sobre un tema. Esto se graba en vídeo y se publica tanto en YouTube como en iTunes.

#VMwarePorvExperts

1062

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

Es común encontrar en vBrownBag guías de estudio para certificaciones, exposiciones de nuevas tecnologías y grabaciones en vivo de conferencias de TI. Yo siempre ando buscando personas para exponer en los canales de Europa o Latinoamérica. Si algún día quieres presentar un tema nada más déjame saber. Es mi deseo que todo el que lea este libro se involucre en la #vCommunity. Crea un usuario de Twitter, ponle foto y algunos detalles para conocerte, y síguenos, y mantente en contacto. Este libro se creó gracias a las relaciones que muchos logramos hacer por internet, y queremos que tu escribas el siguiente capítulo.

#VMwarePorvExperts

1063

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

#VMwarePorvExperts

1064