Incrementar la capacidad de un cluster Nutanix NC2

 Modificar la capacidad de un clúster Nutanix en AWS es muy fácil. Simplemente, desde nuestra consola NC2, pulsamos sobre las opciones del clúster que queremos modificar (los 3 puntitos a la derecha) y seleccionamos Settings:

En la ventana de resumen que nos aparece, seleccionamos la pestana de Capacity en la parte superior de la ventana. Aquí podemos ver la opción de revisar cuotas, el tipo y numero de hosts en el clúster, el factor de redundancia, y la opción de elegir el tipo y cantidad de hosts a añadir a nuestro clúster.

Antes de expandir el clúster, necesitamos revisar las cuotas. Si nuestra cuenta no tiene suficientes recursos, no será posible ampliarlo.

Si tenemos recursos para realizar la expansión, el proceso, como se ve en la siguiente captura, es bien fácil. Se selecciona el tipo de host, y el número de nodos a añadir. En la captura de ejemplo se añaden 2 nodos, porque el Redundancy Factor es 2 (RF2):

Si intentásemos reducir el numero de host a 1, no nos lo permitirá. Esto es debido al factor de redundancia. Para RF2, tendrias que agregar 2 nodos para subir a un mínimo de 5 (y mejor serian 6).

Lo mismo pasaría si intentásemos reducir nuestro numero de host de 3 a 2, o 1. El clúster mínimo es de 3 nodos, así que no podríamos reducirlo a 2

Como crear reglas de Firewall distribuidas en VMware on AWS

 Muestro un ejemplo de cómo crear una política de firewall distribuido Tier 3, que controle el trafico entre servidores web, de aplicación y de BBDD. Para ello, haremos una política que permita el trafico http entre el servidor de web y el de aplicación, otra que permita el trafico MySQL entre el servidor de aplicaciones y el de BBDD, y una ultima que elimine todo el trafico de cualquiera de las aplicaciones con esta regla tier 3, a cualquier otra aplicación dentro de esta regla.

Para ello, accedemos a nuestra web de VMware Cloud, entramos en nuestro SDDC, pinchamos en "Networking & Security" y de ahí, click en Distributed Firewall, en el menú de la izquierda, en el apartado de "security", y luego en "Add Policy":

Agregamos un nombre a la nueva política que vamos a crear, vamos a DFW justo a la derecha del nombre de la política, y pinchamos en editar. En la ventana flotante que aparece, pinchamos en Groups, y marcamos el nombre del grupo que nos interesa. Aplicamos,

Y ya podemos empezar con las reglas que aplicará esa política. Primero empezaremos con la regla para permitir trafico web. 

Sobre la política antes creada, pinchamos en los 3 puntitos de la izquierda, y en el menu que aparece, seleccionamos "add rule":

Esto nos genera un nuevo campo dentro de la politica. Lo nombramos de alguna forma identificable, en este caso por ejemplo, "allow web traffic", y editamos la regla:

Ya teníamos un grupo creado llamado Web Servers, conteniendo las maquinas de este servicio. Lo seleccionamos, y aplicamos:

Sobre la regla, editamos el campo "destinations",

En la ventana flotante que aparece, como las anteriores, seleccionamos el grupo correspondiente, en este caso "app servers" (pasa como anteriormente, ya teníamos creado el grupo con las VM que contienen las app, igual que teníamos el grupo web servers):

Ya para terminar, hacemos click en servicios ( 2 imágenes mas arriba, el siguiente campo editable de la regla, a la derecha de "destinations"), y lo mismo, editar. En este caso marcamos el servicio HTTP, y aplicamos:

De nuevo lo mismo que antes...en la ventana donde vemos la regla, esta vez editamos el campo "applied to", seleccionamos "groups", y marcamos el "3 Tier".

Con esto, hemos dejado lista la regla para permitir el trafico web del grupo web servers al grupo app servers, por el puerto http. Vamos a generar ahora una regla para permitir el trafico MySQL. 

Para ello, repetimos el paso de la tercera imagen de este post, ir a los 3 puntitos de la política que creamos, pulsamos, aparecerá un menú desplegable, y pinchamos sobre "add rule". Ponemos nuestro nombre a la regla, en este caso "allow MySQL traffic", y editamos el campo Sources:

En la ventana flotante que aparece, seleccionaremos "app servers" y Apply:

Como veis, es exactamente igual que en la primera regla. En el campo "destinations" lo editamos, para seleccionar el grupo "DB Servers", y aplicamos. 

En el campo Servicios buscamos el servicio MySQL (en vez de haciendo scrolling podemos utilizar el campo filter, para no dejarnos la vista) y aplicamos.

En applied to, seleccionamos grupos, y marcamos el "3 tier" como hicimos en la anterior regla. Quedará algo asi:

Ya solo falta la regla para descartar el resto del trafico. 

Como hemos hecho anteriormente, vamos a los 3 puntitos de la politica, damos a "add Rule" y ponemos un nombre identificable a la regla. Y editamos los 3 campos críticos de las reglas, source, destination, y applied to. En los 3 campos marcamos "3 Tier". La diferencia es que en el campo "allow, pinchamos para expandir menú, y marcamos "drop":

Una vez modificado, pulsamos en "publish" ¡y ya lo tenemos!

Hecha una regla, hechas todas, el procedimiento es el mismo.

Como crear un segmento de red de VMware on AWS

 Vamos a ver un ejemplo rápido de configuración de red en VMware Cloud on AWS. En concreto, la creacion de un segmento de red. Para ello, vamos a nuestra consola de VMware Cloud, https://www.vmware.com/cloud-solutions.html, y accedemos con nuestro login y pass.

Esto nos llevará a nuestra pantalla principal con nuestros SDDCs:

Accedemos al que vamos a configurar, y nos vamos a la pestaña de "networking & security". Desde ahí, en el menú de la izquierda, pulsamos sobre "segments", y "add segment"

Desde aquí podremos configurar los valores del segmento de red. Básicamente es indicar el nombre del segmento, tipo, que suele ser Routed, y el segmento de red CIDR. Pulsamos en SAVE, y nos aparecerá un aviso indicando si queremos configurar el segmento. 

Podemos pulsar en NO. Nos aparecerá el nuevo segmento junto con los que teníamos en pantalla en la captura superior.

Como crear un SDDC de VMware Cloud on AWS

 Cuando hablamos de poner en marcha un entorno SDDC de VMware Cloud en AWS, lo primero que vamos a necesitar es una conexión con nuestra cuenta de AWS. Esto es prácticamente un pre-requisito para poder proporcionar la conexión de interfaz de red elastica (ENI) a los servicios de AWS.

Para el proceso de implementación, podemos elegir una VPC que nos permita enlazar el SDDC a una subred específica de la VPC. Asi que vamos a ver los pasos para crear una VPC en AWS.

Lo primero de todo, hacemos login en AWS con nuestra cuenta:

Continuamos buscando el servicio VPC que queremos configurar. Lo mejor es ir al buscador y poner "VPC"

Hacemos click en VPC, y seguidamente "Create VPC"

Introducimos el nombre que le vamos a dar, y el rango IPv4 CIDR.

Pulsamos sobre "create VPC".

Hasta ahora, es facilito. Ahora crearemos una subred que nos permitirá conectar al SDDC de VMware Cloud en AWS a traves de la conexion ENI.

Dentro del apartado de VPCs, pulsamos en "subnets", y "create subnet". En el VPC ID, seleccionamos la VPC que generamos anteriormente:

En el apartado "subnet settings", escribimos el nombre de la subnet. En Availability zona, la zona de disponibilidad para la subnet. Aquí hay que tener cuidado, porque hay distintas zonas de disponibilidad, y el SDDC debe estar en la AZ de la subnet. Es importante, el apartado de IPv4 CIDR block, indicar el rango de IP para la subnet. Si la VPC tenia un 10.50.0.0/16, que nos da 65.534 IPs, a esta subnet se le da un 10.50.51.0./24, que nos da 254 IPs para este rango:

Finalmente pulsamos sobre "create subnet". En este caso, creamos una sola subnet, pero es una buena idea crear tantas subnets como zonas de disponibilidad haya en la región donde hayas creado tu VPC (y por tanto, en la que está tu SDDC). En este caso, como se ha creado el ejemplo en us-west, con 4 zonas de disponibilidad, podrían generarse, igual que hemos generado la anterior subnet, pero vamos pulsando sobre el botón de "Add new subnet", remarcado en la imagen superior.

Con las 4 subnets, tendrás esta imagen:

 

Ahora estamos en disposición de crear un SDDC de VMware Cloud en AWS.

Para acceder al servicio, en el navegador, vamos a https://www.vmware.com/cloud-solutions.html y en login, seleccionamos "Cloud services console"

Accedemos con nuestra cuenta, y pinchamos en VMware Cloud on AWS:

Pinchamos, en el listado de la izquierda, en SDDCs, y "create SDDC:

Seleccionamos la región de AWS donde crearla,

En el segundo paso, seleccionamos "Connect to AWS Now". Hay que tener en cuenta que, al implementar un SDDC de nodo único, el enlace de la cuenta de AWS puede retrasarse 14 días. Esta opción solo está disponible para una implementación de SDDC de un solo nodo:

Al pulsar sobre Connect to AWS Account, en el menu desplegable que aparece, seleccionamos "connect to an AWS account". Hacemos click en el boton de OPEN AWS CONSOLE WITH CLOUDFORMATION TEMPLATE. CloudFormation el servicio de AWS que permite aprovisionar de forma automática una serie de recursos de AWS.

Veremos una serie de datos como la url del template y el stack name del SDDC, y haciendo un poco de scroll hacia abajo, veremos la casilla de acknowledge que debemos marcar, y seguidamente, "create stack".

Esto nos llevará a una ventana de eventos, que podemos ir refrescando:

Volvemos a la pestaña del navegador de VMware Cloud, y podremos ver que se ha establecido conexión:

Ya podemos seguir con la configuracion del VPC y la subnet. Pulsamos Next para continuar al tercer paso, y en el menu de "choose VPC", seleccionamos, evidentemente, la que generamos anteriormente, igual que su subnet:

Pulsamos Next, y comenzamos con la configuración de la red. En Management Subnet CIDR Block (Bloque CIDR de subred de administración), indicaremos el rango CIDR de todos los componentes de administración del SDDC: hosts ESXi, vCenter, componentes de NSX y cualquier otro componente de administración implementado en el SDDC. Por lo tanto, es importante que sea un rango de direcciones único, que no se superponga con otras direcciones IP de entornos que puedan estar conectados al SDDC. La subred de administración no se puede cambiar después de la creación del SDDC.

Pulsamos next, hacemos click en las dos casillas donde se nos informa que tan pronto continuemos empezará a cobrarse el servicio en facturacion mensual y en coste por uso (tambien nos faiclitan un link sobre precios y promociones) y pulsamos sobre Deploy SDDC:

El despliegue de los elementos lleva entre hora y media a 2 horas. Una vez desplegado, podremos ver nuestro SDDC en la consola:

Podemos pinchar en "details", donde nos indicará el numero de hosts, recursos, y tipo de máquina desplegada en AWS (normalmente i3 para uso común. Para otro tipo de usos, tenemos las i3en, creo recordar...). Podemos ver un aviso indicando un segmento de red creado por defecto para el SDDC. Podemos cerrar el mensaje...

Justo al lado de la pestaña en la que estamos, en summary, tenemos la pestaña Network & Security, que es donde se llevarán a cabo todas las operaciones de redes y seguridad. Desde aquí podemos crear segmentos de red, en los que colocar cargas de trabajo de VM; administrar y configurar reglas de firewall y conectividad externa en general, todas las opciones de red.

En la siguiente pestaña, Add-Ons, complementos disponibles para el servicio VMware Cloud on AWS. Muy importante, el servicio HCX, está disponible para todos los clientes de VMware Cloud on AWS de forma gratuita y permite a los clientes realizar migraciones de VM a gran escala. 

VMware Site Recovery (VSR) es uno de los productos de recuperación ante desastres como servicio de VMware, que permite a los clientes proteger las cargas de trabajo en VMware Cloud on AWS. NSX Advanced Firewall permite implementar políticas de seguridad de red avanzadas. Estos dos servicios, igual que vRealize Automation Cloud (a ver cuando lo renombran a Aria...) son opciones adicionales de pago.

En la pestaña de mantenimiento veremos si hay actualizaciones programadas en el SDDC. Hay que tener en cuenta que VMware Cloud on AWS realiza las actualizaciones en sus sistemas.

En la pestaña de Troubleshooting, podemos realizar pruebas en la infraestructura en ejecución. La prueba actual habilitada es para el modo híbrido vinculado. Con esta función, se podrá confirmar que la red está configurada correctamente para admitir el modo Hybrid Linked.

En la pestaña settings hay info útil del SDDC, como el FQDN, default vCenter user account, dirección de vSphere, dirección del vCenter, etc...

Si nos fijamos en la anterior captura, veremos que sale un mensaje de notificación en la parte de arriba, de "scale up" Si pulsamos sobre él, nos da la opción de escalar nuestro SDDC:

Aquí podemos modificar el numero de hosts, en este caso marcamos añadir 2 mas y pulsando sobre Add hosts, ya los tendríamos:

Tarda pocos minutos en mostrarse el cambio. Y con esto, ya tenemos nuestro SDDC con sus 3 hosts en funcionamiento.

Si te ha gustado el articulo, puedes invitarme a un café ;)

A vueltas con la nube privada: ¿qué es la nube privada?

 Hablando con compañeros sobre el concepto de nube privada observé que ha evolucionado rápidamente, no solo debido a las compañías de virtualización de entornos, sino también debido a los grandes hiperescalares con sus nuevos servicios.

Por poner un ejemplo fácil... antes se podía considerar una nube privada a un Sharepoint: un entorno web, solo accesible desde tu empresa en muchos casos, y que te daba acceso a recursos, archivos, etc...  Este concepto fue evolucionando a todo tipo de recursos informáticos, accesibles desde cualquier parte, pero localizados físicamente en la infraestructura de la empresa, y accesibles a ellos a través de una VPN, habitualmente.

Imagen de kjpargeter en Freepik

Luego llegaron AWS, GCP, Azure, proponiendo a las empresas nuevos conceptos de consumo, como el SaaS, y el IaaS. A partir de ese momento, empresas como VMware o Nutanix, centradas primero en la virtualización, y luego en la hiperconvergencia, empezaron a pivotar hacia la nube. Es lógico, si la gente quiere pagar solo lo que consume, démosles lo que quieren. Empiezan a aparecer los productos clásicos adaptados a la nube, y la nube híbrida (que da para otro post entero). No solo puedes contratar en los grandes hiperescalares servidores dedicados a los que ponerles un ESXi, por ejemplo, es que se llegan a acuerdos que posibilitan servicios como la infraestructura de servicios clásica, pero fácilmente desplegables en la nube, en lo que se define como SDDC (Software Defined Data Center, o centro de datos como servicio).

Llegados a este punto, tenemos claramente definida la nube privada como era en sus orígenes, puramente On-Prem, pero también tenemos esa misma nube privada en la nube. Tanto es asi, que parece que el primer concepto casi desaparezca. Para ello, vamos a ver unas cuantas definiciones, todas coincidentes, sobre qué es nube privada, empezando por VMware:

Una nube privada virtual es una instancia de nube privada que está alojada y ubicada dentro de la infraestructura de un proveedor de nube pública. Se diferencia de los demás tipos de nube privada en que no se encuentra dentro las instalaciones de la propia organización ni en el partner de coubicación.

Una nube privada alojada se ubica en el proveedor de nube y puede residir en las instalaciones o en un centro de datos. Estos recursos no se comparten con otras organizaciones y los gestiona el proveedor de servicios de nube. Todas las actualizaciones y tareas de mantenimiento son responsabilidad del proveedor de nube.

Enlace: https://www.vmware.com/es/topics/glossary/content/private-cloud.html#:~:text=Una%20nube%20privada%20alojada%20se,responsabilidad%20del%20proveedor%20de%20nube

Os facilito también la definición de Nutanix:

Una nube privada es un entorno informático para una organización específica, con ventajas de nube pública pero alojado en el centro de datos de una empresa o mediante un proveedor externo. Las nubes privadas son conocidas por su fiabilidad, escalabilidad y seguridad y, por lo tanto, a menudo son la opción de infraestructura elegida para las cargas de trabajo empresariales.

Enlace: https://www.nutanix.com/es/info/private-cloud

Hasta ahora, las definiciones de dos de los grandes fabricantes de soluciones de virtualización, adaptando su producto al nuevo paradigma. Vamos ahora con las definiciones de los hiperescalares:

Empezamos con la definición de AWS:

Una nube privada es un entorno de computación en la nube dedicado a una única organización. Cualquier infraestructura en la nube consta de recursos de computación subyacentes, como la CPU y el almacenamiento, que se aprovisionan bajo demanda a través de un portal de autoservicio. En una nube privada, todos los recursos se encuentran aislados y bajo el control de una única organización. Por tanto, la nube privada también se conoce como nube interna o corporativa.

Enlace: https://aws.amazon.com/es/what-is/private-cloud/#:~:text=Una%20nube%20privada%20es%20un,de%20un%20portal%20de%20autoservicio

Este texto de AWS está muy bien porque explica el concepto de nube en todas sus formas.

Continúo con Google:

Una nube privada es un modelo de implementación de computación en la nube en el que todos los recursos de la nube están dedicados a un solo cliente o a una organización de usuario. La nube privada, a veces llamada nube privada interna o corporativa, proporciona muchos beneficios de los entornos de computación en la nube, incluidas la escalabilidad, la flexibilidad y la entrega más rápida del servicio.

Enlace: https://cloud.google.com/discover/what-is-a-private-cloud?hl=es-419

Finalizamos con Microsoft:

Una nube privada está compuesta por recursos informáticos en la nube que utiliza exclusivamente una empresa u organización. La nube privada puede ubicarse físicamente en el centro de datos local de tu organización u hospedarse un proveedor de servicios externo. Sin embargo, en una nube privada, los servicios y la infraestructura siempre se mantienen en una red privada, y el hardware y software se dedican únicamente a tu organización.

Enlace: https://azure.microsoft.com/es-es/resources/cloud-computing-dictionary/what-are-private-public-hybrid-clouds/

Esta definición es perfecta.

En resumen: Una nube privada puede alojarse en una nube publica. La diferencia con la nube publica es que los recursos están dedicados íntegramente al cliente. Ademas, según el tipo de nube privada, la gestión de los elementos de software que componen la infraestructura puede estar gestionada por el cliente, o por la empresa facilitadora de los servicios. Lo importante del concepto es que todo se encuentra dentro de una red privada, y el hardware, a diferencia del de los servicios públicos, no es compartido, sino dedicado. El punto clave de la nube privada es que el concepto viene a ser el mismo, pero deslocalizando el hardware: tanto da que la empresa compre "hierro", como que lo "alquile" al hiperescalar de su elección. Esta misma explicación la facilita de manera más resumida el enlace de la definición de Google con las siguientes palabras: 

Antes, las nubes privadas se ejecutaban de forma local, pero ahora es posible ejecutar servicios de nube privada mediante la infraestructura alquilada en los centros de datos de un proveedor de servicios en la nube.

Me quedo con mi explicación, pero esta última condensa la nube privada en apenas 2 lineas.

Si te ha gustado el articulo, puedes invitarme a un café ;)