Enterate de lo nuevo en Site Recovery Manager


Has visto lo nuevo de Site Recovery Manager

Si utilizas o conociste Site Recovery Manager en sus versiones (5.x o 6.x) pero no has oído lo nuevo que la versión 8.1 trae, aquí te daré algunos datos para que te actualices y conozcas como ha mejorado esta herramienta de recuperación de desastres.

Para comenzar, en su versión 8.1, la interface HTML5 viene estándar, yendo a la par con el resto de los productos de VMware y su interfaz Clarity. En 8.1 encontraras que vSphere Replication y Site Recovery Manager son administrados desde un mismo lugar en vez de páginas separadas como en el pasado. SRM abrira en su propia pestaña del browser, debes hacer click en Open Site Recovery desde la sección de Site Recovery en vCenter.



Se abrira una pestaña para controlar SRM.

Quizás uno de los cambios mas interesantes y bienvenidos por quienes usan el producto – lo sé porque fui usuario de SRM por vario tiempo – es que el requerimiento de que ambos vCenters (centro de datos protegido y centro de datos destino) tengan que estar en la misma versión de vCenter, ya no existe; en cambio hay la magnífica posibilidad de diseñar y proteger, por ejemplo, un vCenter 6.0 en centro de datos origen, y vCenter 6.5 en el destino; asimismo, esto implica que puedes actualizar un solo vCenter Server a la vez; por decir versión 6.0 a 6.5 en uno solo de los centros de datos y no preocuparte por afectar el diseño o que versión este corriendo el nodo SRM. Anteriormente, para actualizar un ambiente de SRM, tenias que considerar actualizaciones de ambos vCenters y ambos nodos SRM, incluso en ciertos casos, las versiones de SRA, si se usa Array Based Replication.  Ahora no, con 8.1 puedes actualizar vCenter un día y SRM después o no hacerlo.

Un dato importante para recordar en esto de las versiones es que tus vCenters si pueden correr diferentes versiones, pero los nodos SRM deben estar en la misma versión.



El desacople mencionado anteriormente en cuanto a las versiones de vCenter, fue un requisito para ofrecer SRM con VMConAWS, ya que mantener las versiones en los centros de datos de clientes a la par con VMConAWS, era algo prácticamente imposible y no viable.
Esto también abrió la posibilidad de expandir las opciones en cuanto a los diseños de SRM y su topología, por ejemplo, ahora puedes proteger tu centro de datos con más facilidad en otro centro de datos privado, en VMConAWS, u otro proveedor de servicio de Cloud.
Si utilizas SRM 6.0, 6.5 o 8.0, puedes actualizar esos nodos directamente a 8.1 en un solo proceso.

Confundido con VMware Encryption?


Si te confunden los términos o métodos usados con relación a vSphere Encryption, no estás solo; basta hablar de los acrónimos y es suficiente para enredarse un poco. Aquí intentare resumir cómo funciona la arquitectura y el proceso de cifrado o encripción en cuanto a VMware, como yo lo entiendo*.


Como en todo lo que publico, debo advertir que nada de lo que lees aquí es oficial ni proviene de mi empleador; yo puedo estar equivocado, aunque no es esa mi intención. Prefiero siempre dejar eso claro.

Para comenzar con el tema de cifrado o encripción, vamos a aclarar algunas de las siglas o acrónimos usados:

·
  KMS: Key Management Service Server. Servidor designado/conectado al vCenter, el cual generara claves de cifrado. KMS será de una compañía terciaria como HyTrust (HyTrust KeyControl), Dell (CloudLink), IBM (IBM Security Key Lifecycle Manager), entre otros. El siguiente link contine un listado:

· KEK: Key Encryption Key. Esta es la clave de cifrado (encryption key) generada por el KMS registrado al vCenter Server. La KEK reside en cada host ESXi – copiada a todos los nodos del clúster.

· DEK: Data Encryption Key. Estas claves de cifrado son generadas por los hosts ESXi y posteriormente encriptadas usando la KEK.



Como funciona el proceso de encriptación en VMware?

vSoccer at VMworld US 2018

Hola,

Many of you landed here because of your interest in joining a bunch of us virtualization and fútbol fanatics play indoor soccer (6 vs. 6) on Tuesday night August 28th while at VMworld. 

I wanted to summarize the idea and details on this post instead of multiple tweets.

To make this a reality we need serious commitment from many of you to rent a field or two (depending how many sign up) at the Longevity Sports Center located 4 miles from MGM Grand. See map here

Update: the #vExpert party is from 7:00 to 10:00 and is only 2 miles away; so things will work out great for those of us that don't want to miss it.

The cost per field per hour is $200 flat rate, so for 12 players will be <$17 per person, per hour.

Here is my thought... if we get 18 players, we'll have 3 teams, can play for 2 hours rotating teams every so many minutes or goals. That will be $400/18 = <$23 per player.
If we get 24 people, we'll decide if we rent 2 fields for one hour, rotate 4 teams for 2 hours, etc. Make your suggestions as this is OUR event.

I already spoke with the manager of the place and the only availability that week is after 10pm; we could rent each field for 1 to 3 hours.

The purpose of this initiative is to create and build vCommunity, to exercise a bit and have fun! There is no need to bring your professional cleats or equipment, any sneakers and shorts will do. This won't be a fierce competition, simply a different and fun way to integrate and meet fellow tech enthusiasts. 

As of today August 7th, we don't have any sponsor(s), some have mention this but I have not reached out to any companies asking for it. If you know how or who/what can provide it, let's try it, even if it's a partial sponsorship, that would be awesome!

As the proponent of this activity, I don't have a problem reserving the place under my name; all I ask for is that if you commit, plan to be there and help cover the costs.

Sign up on this form here; I will keep people updated on count and confirmation once a good enough group have committed to participate.

Thanks.

Conoce sobre VMware Cloud Foundation y vRealize Lifecycle Manager

Creo que a muchos quienes trabajamos en TI, somos entusiastas y nos gusta aprender varios temas nuevos o quizás no tan nuevos, nos pasa lo mismo… no alcanzamos a asimilar tanto producto y solución que existe y sale al mercado constantemente – A mí personalmente me pasa que quisiera aprender muchos temas de los cuales escucho, pero usando la noción de un dicho muy común en inglés - es imposible beber agua de un hidrante - simplemente no hay suficientes horas en el día para aprenderlo todo. 😊

Recientemente quise conocer más acerca de 2 productos ofrecidos por VMware de los cuales no sabia mucho, y aunque no les he dado uso en producción, hasta ahora lo que he visto, me ha parecido realmente valioso y muy útil. Se trata de vRealize Suite Lifecycle Manager y VMware Cloud Foundation, este último incluye SDDC Manager.

Estos dos productos son diferentes e independientes, pero vRealize Suite Lifecycle Manager o vRSLCM como es abreviado, puede ser usado bajo VMware Cloud Foundation/SDDC Manager.

Un resumen corto de lo que cada uno te brinda:


  •    vRealize Suite Lifecycle Manager: Solución que facilita desplegar, mantener y actualizar todos los productos de vRealize Suite, los cuales incluyen vRealize Operations, vRealize Automation, vRealize Log Insight y vRealize Business for Cloud. Lo que obtendrás con esta solución es agilizar y simplificar considerablemente el despliegue y posteriores actualizaciones de todos o cualquiera de los productos de la vRealize Suite que tengas instalados o pienses instalar nuevos. Te ofrece una consola principal para controlarlos desde instalación fresca hasta actualizaciones posteriores.


  •       VMware Cloud Foundation: VCF es similar en el sentido en que ofrece la capacidad para administrar una solución de amplio despliegue, pero esta es enfocada e incluye la infraestructura (servidores, switches, etc.) y el resto del software del pilar de Software-Defined Data Center (SDDC). Todo esto con una herramienta llamada SDDC Manager la cual potencialmente puede también usar Lifecycle Management para controlar también vRealize Suite desde un solo lugar.


Con la intención de compartir con la comunidad entusiasta hispanohablante que se pueda beneficiar de mis notas, al igual que con el interés de educarme más, quiero hacer de este tema un par de publicaciones en las cuales intentare explicar de la mejor manera el uso y los beneficios de estos productos, que facilidades traen, como se usan y lo que tienen en común.

Mantente atento a las futuras publicaciones detallando cada uno de estos productos.




Remediar Spectre y Meltdown en ambientes vSphere - Nueva información

A principio de este año cuando la industria estuvo en llamas de fuego, particularmente Intel, al hacerse público las vulnerabilidades Spectre y Meltdown; todo el mundo pensó que estábamos a punto de pasar por el peor año en la industria y que necesitaríamos remplazar los procesadores físicos de la mayoría de los servidores en nuestros datacenters porque se decía que no había solución sistemática que pudiera corregir los problemas. 

La segunda y tercer semana de Enero fueron de especulaciones. Cuando finalmente Intel lanzo los parches de una manera afanada, muchos corrimos a instalarlos en un afán jamás visto – vi como en 4 días se actualizaban cientos de servidores cuando normalmente se tomaban meses.  Todo esto por la sensación de urgencia que se había generado, quizás sin tanta razón, puesto que no se supo de ataques mayores.

Yo escribí un blog post con los pasos que en aquel momento eran requeridos para actualizar ambientes vSphere; ese resumen era lo recomendado y muchos los sugirieron completar rapido. Días después se supo que el microcódigo  incluido estaba causando problemas y entonces la recomendación siguiente fue: No hacer nada y esperar, o en caso de ya haber aplicado los parches, hacer una modificacion manual en cada host bajo /etc/vmware/config

Cerca de 2 meses después, Intel ha entregado nuevos parches de microcódigo, los cuales hoy han sido lanzados por VMware y cuya informacion completa se encuentra en VMSA-2018-0004.03

Esta es la nueva información a seguir para remediar tu ambiente vSphere, en este orden: 

1. Actualizar tu vCenter Server a las siguientes versiones:

          6.5 U1g
          6.0 U3e
          5.5 U3h


2. Instalar ambos parches en tus hosts ESXi, dependiendo cual versión utilices:

        ESXi 6.5: ESXi650-201803401-BG y ESXi650-201803402-BG
        ESXi 6.5: ESXi600-201803401-BG y ESXi600-201803402-BG
        ESXi 5.5: ESXi550-201803401-BG y ESXi550-201803402-BG


Los bundles ***3402-BG son los que contienen el microcódigo; los ***3401-BG instalan los requisitos para que los Guest VMs puedan usar los nuevos mecanismos de CPU presentados.

3. Si aún no lo has hecho, aplicar los parches de los sistemas operativos en tus maquinas virtuales - bien sean Linux o Windows, el proveedor debe ya haber lanzado estos parches. 


Ciertos detalles a tener en cuenta:

  • Si después de aplicar los parches que salieron mal, tuviste que implementar la solución alternativa de modificar /etc/vmware/config, estos parches harán la ‘limpieza’ de esa modificación, Pero, ten presente que si usas Host Profiles o AutoDeploy, habrá que verificar que no se re-aplique dicho cambio por error.
  • Los parches de sistema operativo en las VMs no son opcionales para protegerse; de no actualizar el OS en tus VMs, no estarás cumpliendo con todos los requisitos y la remediación quedara a medias.
  • La nueva actualización para vCenter es necesaria para EVC, aun si no usas EVA en tus clúster, es recomendable aplicarlo – aunque no requerido para estar protegido.
  • Ambos parches de los hosts pueden ser instalados conjuntamente y solo necesitaras reiniciar una vez.
  • Recuerda que la versión de Virtual Hardware de tus VMs debe ser 9 minimo, pero 11 es recomendable. Si usas Virtual Appliances y no estan en version 9, no la actualices manualmente, debes esperar por la nueva version, completa.
  • La lista de procesadores para los cuales hay microcódigo la puedes ver en la tabla en https://kb.vmware.com/s/article/52085
  • Ten presente que asi apliques los parches, incluyendo el microcódigo, es recomendable instalar el BIOS completo una vez el proveedor de hardware lo haga disponible. 
  • Si actualizas el sistema operativo antes de aplicar los parches de ESXi (Hypervisor-Assisted Guest Mitigation) las VMs requerirán ser apagadas e iniciadas de nuevo.

El mismo KB52085 contiene los pasos para confirmar que tus hosts tienen ambos parches requeridos, pero acá los dejo igual:
           Enciende una VM de versión de hardware 9 o mas alta y examina en su archivo vmware.log para verificar que alguna de las siguientes líneas existe:

            “Capability Found: cpuid.IBRS”
            “Capability Found: cpuid.IBPB”
            “Capabliity Found: cpuid.STIBP”

Con encontrar una sola de las 3 anteriores lineas, indicara que ambos parches han sido instalados.



============


Si tienes preguntas, dudas o deseas agregar/compartir algo, te invito a interactuar conmigo en Twitter o dejar tu mensaje en los comentarios.

Gracias por leer y compartir este post. :-)






Como remediar Spectre y Meltdown en ambientes de vSphere / VMware.


La última semana se ha hablado mucho de Spectre y Meltdown, vulnerabilidades de procesadores modernos que cuando son explotados, permiten que programas puedan obtener información que otros programas han almacenado en memoria como passwords, emails, fotos y otra información personal que normalmente no deberían poder ser accedidos por otros procesos corriendo en el mismo servidor…..hasta ahora.


Puedes leer más acerca de Spectre y Meltdown aquí: https://meltdownattack.com/

Estos bugs están catalogados bajo CVE-2017-5753, CVE-2017-5715 y CVE-2017-5754 (Spectre y Meltdown)

Estas variaciones de bugs han sido categorizadas como unas de las más grandes y masivas para la industria ya que afecta procesadores generados en la última década, es decir, millones de sistemas en todo el mundo, desde computadores personales, celulares y servidores en la nube, estos últimos considerados los más susceptibles ya que en la mayoría de los casos son compartidos por diferentes clientes and ambientes virtualizados. 


A pesar de que ciertas fuentes conocían esta vulnerabilidad hace unos meses, el tema se hizo público el pasado 3 de Enero (Puedes leer mas aqui:  https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html) y como era de esperarse, se convirtió en urgencia para compañías de hardware y software desarrollar parches para remediar en lo posible dichas vulnerabilidades. Aunque inicialmente se escuchó que habría que reemplazar cada uno de los procesadores físicos, lo cual sería algo que tomaría años; rápidamente, la combinación de actualizar todos los componentes en los servidores (BIOS/CPU Microcode, Hypervisor, VM Guest e incluso versión de hardware en el caso de VMware) al parecer serían suficientes para estar protegido. A juzgar por los blogs y documentos oficiales, al menos de VMware, si se actualizan todos los componentes, se estará a salvo - Esperemos que así sea.

Aquí dejo descripción de los diferentes pasos requeridos al día de hoy, si buscas remediar tu ambiente de vSphere:

VMworld 2017 - First day

Although VMworld doesn’t officially start until Sunday or depending how you look at it, Monday; the whole weekend leading to it is an amazing opportunity to get familiar with the huge Mandalay complex, find out where the different places are located and of course one of the best parts of the show… meet fellow technology enthusiasts. This is one of the most valuable things of attending the conference in my opinion.

A day and a half in and I have probably already met 20+ new vFriends from the community and have had excellent conversations about the cloud, infrastructure, automation and even great personal experiences.

One of the anticipated moments for me was to meet Al Rasheed who won the conference pass I was able to donate to the vCommunity last month; Al had never attended VMworld before and just 24 hours in, he is thrilled and having a lot of fun. He has already taken a picture with VMware CEO Pat Gelsinger.




This time around it is also very important to me to be here to meet my new team and continue learning about the TAM role and the organization in general. On Sunday, I attended the TAM Reception, talked and learned a bunch from TAM customers, their feedback about the program and how much they value the relationship.






The first official party of VMworld 2017 was the VMUG Party and as expected, it didn't disappoint; the food was great and the band was simply amazing. They rocked the house and gave us an awesome time to start the week with the right foot.



Getting together with my vBrownBagLATAM friends is always a pleasure and we had a chance to have dinner after the VMUG party. As usual we had a great time.




I am looking forward to the coming days being as amazing as the first one, to the different announcements VMware will have, specially related to the partnership with AWS and to meeting new friends in the community and create lasting relationships.