Preparación y ajustes en AWS para adopción de VMware Cloud on AWS


Este es el tercer articulo de una serie que inicie cubriendo detalles de VMware Cloud on AWS; si esta solución es totalmente nueva para ti, asegúrate de también leer Visión General de VMware Cloud on AWS y Capacidad, Diseño y Consideraciones.

Aquí cubriré los requisitos que deben ser completados en tu cuenta de AWS nativa, más específicamente, en tu VPC (Virtual Private Cloud) para de cierto modo, alistarla antes de implementar VMware Cloud on AWS.

Lo primero es acceder a tu cuenta nativa de AWS, navegar a servicios y buscar VPC; si no tienes ninguna VPC que vaya a ser usada para la integración con VMC, debes crear una.

Una VPC en resumen es una porción de Cloud de AWS dedicada para ti, en donde podrás desplegar objectos y servicios de AWS. Esta Virtual Private Cloud, debe tener asociada una dirección IPv4, representada como bloque CIDR con un máximo rango de /16 (ej.: 172.20.0.0/16)



Luego de haber creado la VPC y asignado una IP, lo siguiente es configurar una o más Subnets; subnets en este caso, permiten dar un rango de IPs para uso en la VPC.


Como mínimo una subnet es requerida, pero puedes agregar más de una; comúnmente se crean varias para expandirse a varias zonas (AZs) de una región de AWS. La única o multiples Subnets creadas son derivadas de la IP asignada a tu VPC. Por ejemplo, si mi VPC le asigné IP 172.20.0.0/16, mis subnets pueden ser 172.20.1.0/24, 172.20.2.0/24 y 172.20.3.0/24


Después de crear Subnets, nuestra VPC requiere un Internet Gateway, el Internet Gateway permite la comunicación entre maquinas virtuales dentro de la VPC y el internetCrear el IG es de lo mas sencillo que hay, solo haz clic en crear, dale un nombre y ya.
Después de crear el Internet Gateway, este debe ser explícitamente anexado a la VPC; este paso también es sencillo, solo haz clic en Actions y selecciona “Attach to VPC



El siguiente paso es crear un ENDPOINT, lo que un EndPoint nos permite es poder conectar nuestra VPC y los objetos en ella, a otros servicios de AWS sin tener que hacerlo a través del Internet.

Finalmente es necesario asociar la subnet o subnets creadas en pasos anteriores, con el Route Table de tu VPC. Así se puede determinar la dirección de trafico dentro de tu VPC. 
También, entramos una ruta personalizada de 0.0.0.0/0 para así poder acceder las subnets desde afuera; por ejemplo desde tu vCenter local en tu centro de datos.

Hasta allí, los requisitos de preparación en el lado de AWS para conectar tu VPC con VMC, estarían completos; lo siguiente es entrar a la consola de administración de VMWonAWS y desplegar tu SDDC.



Antes de desplegar tu primer SDDC, o incluso posteriores, ten presente con anterioridad la región que se desea usar, cuantos nodos (recuerda que lo mínimo son 3 y máximo 16 - hoy en día), el nombre que le quieres dar a tu SDDC y que bloque de IP CIDR vas a asignar al SDDC – hay que anotar acá de nuevo que una vez sea desplegada tu SDDC, el CIDR IP no se puede cambiar, la única manera será destruyendo el SDDC y creándolo nuevamente.

AWS tiene un bloque CIDR predeterminado de 10.2.0.0/16 en caso de que no definas otro diferente.



Tan pronto hayas entrado los detalles de que región AWS, el tipo de despliegue (multi-host o Stretched Cluster), nombre de la SDDC y numero de nodos; lo siguiente es conectarte a el VPC que preparamos al inicio; todo esto es automatizado y lo único que debes hacer es permitir que por medio del uso de CLOUDFORMATION, esa conexión sea establecida. Lo que el proceso hace es abrir otra pestaña de tu navegador donde debes entrar las credenciales de tu cuenta AWS, y así dar autorización a completar ese vínculo entre el SDDC de tu VMWonAWS y tu VPC en el AWS nativo. En segundo plano lo que CLOUDFORMATION hace es crear roles que permiten los cambios a algunos recursos de tu cuenta de AWS – básicamente, se está dando autorización propia para lo mínimo necesario.

Ya conectado y con autorización a tu AWS, el proceso muestra la VPC y subnets disponibles que debes escoger 




Por último, entras la IP (CIDR) la cual será principal para administración del SDDC, y aceptas los costos que se incurrirán tan pronto hagas clic prácticamente.


El proceso puede tomar entre 30 minutos a una hora y al final tendrás listo tu SDDC como lo ordenaste y listo para usar.
Aca vemos los detalles de un SDDC de 3 nodes y su capacidad total de recursos.



Ya que tienes tu SDDC dedicado en la nube de AWS, debes agregar una regla de Firewall para permitir acceso al vCenter.

Para agregar dicha regla, haz clic en tu SDDC, luego navega a la pestaña “Networking & Security” y debajo de Security, haces clic en Gateway Firewall; al lado derecho clic a ADD NEW RULE, dale un nombre distintivo, escoge la fuente (Source), normalmente Any y el destino (vCenter) aceptando los 3 servicios requeridos: HTTPS, SSO y ICMP. Para hacer este cambio efectivo, haz clic en el botón PUBLISH



Una vez la regla este en su lugar, puedes hacer clic en el botón  donde podrás ver el URL y copiar la contraseña del usuario cloudadmin@vmc.local


En siguientes posts, escribiré más acerca de configuración de redes, modos de conexión y despliegue de maquinas virtuales en el SDDC de VMWonAWS; mantente al tanto.


-----

Detalles de VMware Cloud on AWS - Capacidad, Diseño y Consideraciones


Este es el segundo de una corta serie de blog posts en español, donde escribo acerca de VMware Cloud on AWS. Te invito a dar un vistazo a los otros posts e interactuar con preguntas o comentarios en Twitter.

En el primer post de la serie, compartí una visión general de lo que es VMware Cloud on AWS y algunos casos de uso. En este post daré mas detalles de la capacidad de cada host y una perspectiva al plano/diseño de la solución.

Capacidad
Recordando lo mencionado anteriormente, VMware Cloud on AWS es desarrollado de una manera muy rápida y los cambios son muy frecuentes; por lo tanto, los detalles acá compartidos pueden cambiar. 
Hoy en día, VMWonAWS se inicia con un mínimo de 3 nodos en un clúster y un máximo de 16; hay una alternativa de prueba con un solo nodo, pero esta solo podrá ser usada por 30 días y en realidad no está lista para producción y más que nada se usa como ensayo y entrenamiento.


El tipo de servidor mas comun y disponible hoy día es el i3, el cual tiene las siguientes características:


Dos procesadores Intel Xeon E5-2686 v4 con 18 cores físicos cada uno, es decir 36 cores en total, estos corren a 2.3GHz clock speed.
512GB de memoria RAM
14.3TB de almacenamiento Flash, modo NVMe – de esta capacidad, 3.6 TB es usada para vSAN cache, mientras 10.7 TB son usadas para capacidad vSAN (almacenamiento).
Una tarjeta de red de 25 Gbps (Elastic Network Adapter)


Un segundo tipo de servidor disponible, son los R5 que permiten integración y uso de EBS (Elastic Block Storage) y tener así más capacidad de almacenamiento por cada nodo; mientras los i3 brindan 10.7TB usable, un nodo R5 puede empezar con 15TB y subir hasta 35TB con EBS; el incremento puede ser de 5TB escalado. 
Hay que destacar que algunos funcionamientos de vSAN como de-duplication, no son respaldados cuando se usa EBS.


Segun lo anterior, si usas servidores i3, en un clúster de 4 nodos, podrás tener una capacidad total de: 


144 cores físicos – 331.2GHz
2TB de memoria RAM
42.8 TB de capacidad de almacenamiento



Diseño
Plano típico común:

Aquí vemos como la solución VMWonAWS esta encima de la infraestructura de AWS, lado derecho y al lado izquierdo sería el vCenter local ya existente; en este caso se pueden usar uno de dos tipos de conexión con VMWonAWS, bien sea AWS Direct Connect o una IPSec VPN, con una de las dos, tendrás ese panel único anhelado donde se pueden acceder y manejar ambos ambientes desde un solo lugar con el cliente vSphere HTML5.



 
Así mismo, varios de los múltiples servicios que AWS ofrece, pueden estar disponibles para integrarse con VMWonAWS; como vemos en esta gráfica, el estar ‘sentados’ en la infraestructura de AWS, permitirá, con ciertos requerimientos, acceder a un numero de servicios y funcionalidades nativas de AWS.


Consideraciones:
Una de las peculiaridades de VMWonAWS es que, al ser un servicio gestionado por VMware, ciertas tareas son restringidas para los usuarios/clientes por medio de roles de seguridad. Recordemos que, para poder garantizar estabilidad, seguridad y proceder con actualizaciones y/o reparaciones de hardware sean lo más ‘invisibles’ posibles para el cliente, hay varias actividades que solo son posibles por empleados de VMware encargados de tu SDDC o por medio de la consola de VMWonAWS, no vCenter directamente.
Al desplegar tu primer SDDC en VMWonAWS, veras restricciones en el área delegada a Management, esta incluye todos los componentes de fundación para el SDDC (vCenter Server, NSX Manager, NSX Controllers, Edges); al desplegar maquinas virtuales, veras como solo es posible usar los Resource Pools marcadas para Compute Workload y no para nada que etiquetado como Management Workload
Este cambio o limitación se puede ver como un sacrificio para no tener que preocuparse por el mantenimiento, actualización y reparación en caso de problemas, de los componentes arriba mencionados.

Solo un ejemplo esta el hecho de no poder acceder por SSH a los servidores ESXi; algo que es muy común en los centros de datos propios.



Otros Datos:
VMware tiene un equipo dedicado para todos los clientes de VMWonAWS llamado Customer Success Team, este equipo ayuda como guía desde el principio en la preparación e implementación de la solución, igualmente pueden ayudar en decisiones de diseño.
El servicio incluye soporte técnico ilimitado por vía de chat o teléfono 24 horas al día, 7 días a la semana.


Portal de VMWonAWS - https://console.cloud.vmware.com

 


En una cuenta de VMWonAWS, categorizada como organización, puedes desplegar hasta 2 SDDCs y cada SDDC puede tener un máximo de 10 clusters. Acá vemos una imagen de una organización con un solo SDDC y un solo clúster de 3 nodos como ejemplo.



Visión General de VMware Cloud on AWS


Este será el primero varios posts relacionados con como iniciar con VMware Cloud on AWS que quiero compartir con la comunidad hispanohablante. Lo que veras en este y otros posts es básico, en modo resumen para cubrir las bases de que es VMWonAWS, sus requisitos y su implementación.

Que es VMware Cloud on AWS? Es el mismo vSphere que ya conoces con vSAN y NSX incluidos por defecto, instalado y corriendo en servidores dedicados en centros de datos de AWS (Amazon Web Services). El servicio es totalmente manejado por VMware, su venta, soporte, actualización de componentes; todo es adquirido y apoyado a través de VMware; pero requieres también tener una cuenta propia con AWS y cierta configuración inicial.

Cuando se adquiere VMWonAWS, se esta pagando por nodos dedicados para tu organización y su unidad mínima de medida es un nodo; es decir que la capacidad predeterminada de un nodo es tanto como podrás incrementar o reducir la capacidad como mínimo en tu clúster.  Cubriré mas acerca de estos servidores y su capacidad, más adelante.

Importante también mencionar, que con la adquisición de VMWonAWS, se esta pagando por todo lo que este contiene, incluyendo licencias de vSphere, NSX y vSAN; teniendo en cuenta que tu equipo de administradores ya no tendrá más que preocuparse por actualizaciones o reparaciones cuando se daña algo en hardware, esta solución puede ser ideal en muchos aspectos. Igualmente, la agilidad y rapidez con se puede escalar es realmente increíble – puedes tener un clúster de 4 servidores en aproximadamente 2 horas. Hablando de ventajas… implementar VMWonAWS permitirá a tu organización migrar servidores a la nube, lo cual en muchas entidades ya es un requisito; y todos esto, sin necesidad para los administradores de aprender algo totalmente nuevo desde cero.

Un dato importante de mencionar acá es que VMWonAWS cambia constantemente, en el sentido de actualizaciones y mejorías; en realidad es donde se aplican lo último en características diseñadas para vSphere, NSX o vSAN; esto ha dado luz a cambios muy benéficos no solo en VMWonAWS, pero también para quienes usan vSphere en sus centros solamente.

Cabe anotar que AWS siendo el líder en prestador de servicios de Cloud, con centros de datos alrededor del mundo, de seguro cubrirá áreas cercanas a donde necesites. Aunque VMWonAWS no esta hoy por hoy disponible en todas las zonas donde AWS esta presente, el plan es expandir a todas y cada una, muy pronto.

Ya que sabes que es VMWonAWS, aquí dejo algunos de los casos de uso mas comunes: 

- Expandir tu centro de datos al Cloud: como mencione antes, algunas entidades ya tienen como requisito tener al menos un pie en la nube y esta es una forma ideal de comenzar o expandir a otras nubes, si la intención es multi-cloud. 

- Consolidar: este uso permite consolidar todo lo que se tiene en el centro de datos propio, sea por costos o espacio físico, y hacer uso de la agilidad y versatilidad en la nube.

- Flexibilidad: la oportunidad de poder la opción de mover tus maquinas virtuales de un lugar a otro sin nada de complejidad y en solo minutos, por ejemplo, para mitigar desastres, es una gran ventaja.

- Adquirir requisitos de conformidad: digamos que tu compañía o cliente necesita implementar una aplicación o servicio que requiere alguna certificación de conformidad, seguridad y es complejo cubrirlo en un centro de datos propio; aquí este caso de uso es perfecto, ya que AWS cumple con los mas altos requisitos y certificaciones.

- Recuperación de desastres: Agregar VMWonAWS en función de sitio secundario en caso de desastre es también muy común, y esto se logra sin la necesidad de comprar y manejar hardware.

En los próximos posts, cubriré detalles de la capacidad de los servidores, la preparación necesaria en tu propia cuenta de AWS para implementar VMWonAWS y algunas cosas más.

vSoccer at VMworld 2019

Hello virtualization and soccer friends,  see updates at the bottom...

It’s time to start planning our second vSoccer event during VMworld and this time I hope to be able to organize and attend both San Francisco and Barcelona – fingers crossed for VMworld Europe.

I’ve been thinking about it for a few days now, debated if it was worth organizing it again, not because it wasn’t good last year, it was amazing… ask anyone from this picture 😊


But because it’s a different city and because during the short week of VMworld, there are SO MANY other events and gatherings, both from the conference itself and parties and other things different vendors organize. However, yesterday I put out this tweet and shared a direct message with some folks who played last year, and the responses were so enthusiastic from people, that the question became… How could we not have vSoccer?  Someone even said that vSoccer was additional motivation to register and attend VMworld – can you believe it?

So, although I could have started planning this whole thing earlier, it’s never too late and I am committing to doing my best to bring our second VMworld #vSoccer event in San Francisco to fruition. The target date will be August 27th which is the Tuesday of that week from 8:00 to 10:00pm. For Barcelona, I will also start researching and reaching out to local people that may be able to help me over there. So, stay tuned, but also please ping me if you have information and can assist in coordinating for Barcelona.

Today, I submitted an application to rent a pitch with the San Francisco Recreation & Parks organization; they have multiple fields around the city – full pitch and half courts. I spoke with a representative from that organization and was told that the applications are evaluated on first come first serve but that I should hear back in a week or two. Their locations vary in size and distance from where the conference will be, so I filtered for what looked like the best fields and closest to Moscone Center, ranging from 2 miles to 7 miles away, no bad.  Cost of rental is cheap, their website list US $96 per hour ($83 for field + $13 for lighting) – this maybe the only thing cheaper in San Francisco than Vegas 😊… we paid $200/hour in Vegas last year.

If you are interested in joining us, please enter your name in the form here;. I promise not to share the information there and will only use it for communication related to this activity.

If you have any ideas, suggestions, can sponsor or know of a vendor that can sponsor us, please let me know via Twitter.

Let's do this and kick some balls... soccer balls that is 😊


June 8th update: I am happy to report that our friends Stephen Foskett Gestal IT Tech Field Day have committed their support for vSoccer at VMworld in San Francisco this year and are covering the costs of the soccer field rental. This is awesome news!! 

Special thanks to Al Rasheed for reaching out to Stephen regarding this event.

If you are not familiar with Tech Field Day, make sure you engage with them and consider becoming a delegate. Follow TechFieldDay and Stephen Foskett on Twitter to thank them and show your appreciation for supporting vSoccer.

We will be playing at an amazing, well regarded Fútbol place in San Francisco called Beach Chalet soccer fields; just take a look at these pictures and tell me who wouldn't like to play here:




Registration form has been updated for tracking, please make sure you get on the list if you are serious about attending.


Update June 27th: We will be using an Eventbrite link for those of you who would like to contribute and reserve a spot on the charter bus that will transport us from Moscone Center to soccer field and back. 
Seats on this bus are limited, so make sure you get on the list before spaces run out. Eventbrite link: https://bit.ly/2Jb4rot


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


Our vCommunity is one of a kind.

Many have written about our unique vCommunity, predominantly with positive comments as they describe their interactions, experiences or opportunities that have been made possible by participating in these groups and engaging with people that share same interests or lines of work.

I want to do my part and share what the greater virtualization community means to me, what it has allowed me to accomplish and why I feel proud to be associated with it. I also will take this opportunity to acknowledge and thank many individuals who have helped me in my path, one way or another.

If you are reading this post and know me from social media, mainly in Twitter, you know what group of people I am referring to; whether you identify it as the vExpert, VMUG, vBrownbag, VTUG or simply the vCommunity, we are one of a kind; you may read/hear this same belief consistently from others and if you are new around or not involved too much, you may think we exaggerate a bit, but the reality is that, that many of us can’t be praising something just for kicks, there is definitely something great about being a member here and you are welcome to join.

My story in the community begun back in 2012 when Randy Castle who led a team I was part of, persuaded me to attend a VMUG meeting in Boston; - Thank you for insisting Randy!  That September of 2012, BostonVMUG held the event in a very unique place, they rented two cruise ships at the Boston harbor, The Boston Spirit and one other I can’t recall the name of; that was a cool and additional incentive to be there and learn what the whole thing was about. That time is one I remember well, not only because the cool location (check out some pictures from 6 years ago here), but also because I met Steve Athanas, Mariano Maluf who at the time was the VMUG President, and Rob Bergin for the first time; by the way, it was Rob who on that day told me that if I wanted to be “in-the-know” in the virtualization world, I needed to open a Twitter account and follow the right people; well, Thanks Rob!; even though I was hesitant about Twitter at first, I learned over the years how useful the platform can be.

After that first VMUG attendance, many consecutive BostonVMUG events had my presence, I wanted to learn and grow my network, everyone made me feel welcomed and the opportunities to meet virtualization and technology experts one-on-one and go back to work with new applicable knowledge was always awesome. There were years when 2 UserCons were arranged in Boston and the place was packed, every time; it quickly became a can’t miss event for me.
One of those UserCon days, the summer of 2014, the organizers had Joshua Andrews bring the mobile TestTrack and Josh had a contest going where the participant would pick a card at random from 10 lab exercises, the person who finished the lab correctly in the shortest amount of time would win the prize at the end of the day, the prize? a VCAP exam voucher – nice!

It was my lucky day as I was able to properly complete the test lab within few minutes. What I must admit here is that the stars had lined up for me as right before the TestTrack challenge, I had participated on a session that covered in detail what the lab asked to do – this was meant to be, that’s what I always say - pure coincidence when I picked that same subject for the lab; things just worked out for me that day.  By virtue of being there, engaged in the event, attending sessions and participating, created a chance of a free VCAP voucher. Although I had a valid VCP at the time, going for the higher-level certification wasn’t in my plans that year, but there I was, with a voucher good for a year and great resources to practice, also provided by Josh. After studying for a couple of months I took and passed the VCAP-DCA. Big thanks to Josh for his TestTrack, the voucher and opportunities to practice on his lab!  Steve Athanas calls my anecdote as “a VMUG success story”, I agree with him and I’m grateful.

Talking about Steve, and it’s time to thank him… he is a person I appreciate and admire very much, having him as a VMUG leader and pioneer at the BostonVMUG for many years has been truly amazing; he is a smart guy, great person, family man, professional and with a great sense of humor. Awesome leader! Thank you, Steve! One day you’ll be the VMUG President, I can smell it ☺

During these and future VMUG and VTUG events, I also met Jonathan Frappier, Luigi Danakos, Mark Gabryjelski, Brian GrafMatt Bradford, James Mueller and many others. Through Jonathan I learned of vBrownbag and their webinars on Wednesday nights, which I attended on occasion – Thank you Jonathan!

It was during one of the vBrownbag sessions when I first heard of an Ariel Sanchez who’s profile picture and Twitter bio referenced his good taste for a football team, I liked the guy from the gecko.☺


Partaking in all these virtual and in-person events, with great deals of knowledge being shared and connections made… what is not to like?

Me, like many in the IT field tend to be introverts or describe as such; but for some good reason, when engaged with the people that make up our community, I feel comfortable and have been able to grow not only with technology but also on social basis, enhancing interpersonal, communication and other soft skills. Thanks to the vCommunity for this! 

When I attended my first VMworld in 2016, I had the chance to meet Ariel Sanchez in person, he was wearing his famous hat and that’s how I was able to spot him in the crowd at the vendor expo. As the world knows, he greets people like we’re his relatives and encourages everyone to be better; Ariel has helped me a lot and was my mentor to become a vExpert, to start this very blog and to take a shot at presenting on the vBrownbagLATAM channel.

After meeting Ariel and many other friends from Latin America at that VMworld, we stayed in touch by way of a group chat, we’ve been very active there since and it was through this ‘staying in touch’ that on July 2017 an open position at VMware was shared with the group by guess who? El Señor Sanchez, who few months earlier had joined the mothership – I became interested in the opportunity, followed up with Ariel, he followed up with his boss who was the hiring manager, and fortunately things worked out and that is the position I now proudly have. So, Ariel Sanchez, my respect and gratitude brother, not just for the referral but for being there and always willing to help me and EVERYONE. Thank you, Ariel!

There is another person I’d like to thank in reference to becoming a VMware employee by way of this community, that is Matt Bradford, he was very supportive during my job application process helping navigate and learn more about the role. Thank you, Matt! You rock!

My narrative here is in no chronological order and I can’t leave out an experience that gave me great joy: having the chance to donate a VMworld pass; and after some time realizing that it could not have been obtained by a more grateful and kind individual, Al Rasheed.

Last year, me and a colleague at my previous employer in Boston registered and planned for VMworld 2017, at the end, there was an additional registration code for the conference that no one was going to use, so I asked my manager at the time, Chris Mitchell, to please allow me to donate it, he kindly accepted. Thank you, Chris! This made a change in someone’s life.
In late July, knowing that I had this code available, I reached out to William Lam and asked him to help me promote my contest, since he could reach a lot of people. Just minutes after I contacted William about the idea, he tweeted this. The whole idea expanded, and it was great to see submissions for it; here, Al describes his entry and thoughts that he would never win. On August 1st, the selected 7 were announced and the next day over a live and very shaky live video, I picked a random winner. Al made it to Las Vegas where we met and hanged out. In there we learned about the circle of karma and this picture is one I tell my family about.

This pictures represent a circle that expands a decade. When you do good, good things will happen.
Al and I never got a chance to take the picture with William at that VMworld, as a matter of fact, I’ve never met William in person, but Al has and that is super cool.


Just last week, I flew to Boston for their 2018 UserCon as I wanted to be there once more, now as a foreigner but always with great love and appreciation for the group that Randy introduced to me 6+ years ago; that assembly of people led by Steve where I gained lots of knowledge, encountered great folks and built awesome relationships, that free resource that permitted so many good things to happen.

That is my story so far in this great vCommunity, or at least the highlights; I learned tons, improved interpersonal skills, accelerated attaining higher level of certification that probably wasn’t going to be on my radar that soon, without a doubt opening new doors for me. I had an amazing opportunity to in part Pay-it-back with the VMworld pass and make a change for someone who is now a friend (Al Rasheed) and he’s been giving back so much to all of us. There is also the new job with relocation included – there is a lot that originated from being there and so many people to acknowledge and express gratitude.

The benefits and opportunities are there and can come to you the way you least expect it; if you are reading this and doubtful of getting involved, don’t think it twice, we’re waiting for you.

Thanks to everyone in this awesome community, I will always feel proud to be a member and look for opportunities to pay-it-back and contribute.

Cheers!


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

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?