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


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