Automatización

Forzar Dinámicamente la Selección de Red en vRA 7

Diciembre 25, 2016 - - 0 Comentarios

Estoy trabajando en el diseño e implementación de un gran proyecto de Nube Empresarial donde el multi-tenancy es vital para el éxito del proyecto. Cuando se trabaja en un proyecto de nube privada, una infraestructura compartida común es el típico enfoque para hacer viable el caso de negocio. Normalmente, la segregación física se basa principalmente en los requisitos de seguridad y no más en quién compró el hardware. La segregación multi-tenancy se mueve hasta el nivel lógico, convirtiendo la infraestructura en una commodity compartida.

Desde el punto de vista de red, la segregación lógica es soportada por el uso de protocolos como VLAN, PVLAN, GRE, VXLAN y otros. Cada vez que una máquina virtual se aprovisiona a través de vRealize Automation, requiere el acceso a la red para comunicarse con otras cargas de trabajo.

En el caso de user vSphere como plataforma en vRA, las tarjetas de red de la máquina virtual se conectarán a uno de los PortGroups disponibles dentro de la reserva en la que se está aprovisionando. El primer nivel de segregación lógica en vRA es el objeto business group, donde puede tener una o más reservas (el segundo nivel). Si el usuario no es miembro del business group con las reservas enlazadas, no puede aprovisionar ninguna máquina virtual en esta.

Fuente: VMware.com

La reserva incluye qué red o redes el usuario puede conectar tu máquina virtual, pero estas redes no se publican dinámicamente en vRA. El enfoque sencillo es la creación de una custom property denominada “VirtualMachine.NetworkN.Name”, donde N es el índice de la NIC su máquina virtual (comenzando en 0). Durante la creación de esta custom property, tendrás la oportunidad de crear una lista estática o dinámica utilizando cualquier script action que tengas disponible en tu plataforma vRealize Orchestrator que vRA consume.

El reto principal de una lista estática es el mantenimiento de la lista de redes que se muestra al usuario, también esta lista se comparte para todos los usuarios. Desde el punto de vista de seguridad esto no es un problema, ya que la red debe estar habilitada en la reserva del usuario, si no está habilitada, el usuario recibirá un error de que la máquina virtual no se puede aprovisionar porque la reserva no tiene derecho a consumir la red. Si bien esto no implica una riesgo en la seguridad, exponer toda la lista de redes no es el mejor enfoque ya que alguna información confidencial puede estar disponible en el nombre de la red. Por esta razón, crear una lista de redes dinámicas en tiempo real basada en el business group del usuario y la reserva vinculada a esta, parece ser el mejor enfoque que he encontrado hasta ahora. Cuando se trata de un entorno multi-tenancy, los requisitos de seguridad son siempre la pieza más importante del diseño.

Para lograrlo, vamos a aprovechar una script action de vRO disponible desde la versión 7.1 llamada “getApplicableNetworks” (más información). Vamos a ajustar un poco esta script action ya que como viene de forma predeterminada muestra todas las redes permitidas para el usuario independientemente de qué business group está solicitando la máquina virtual. Para filtrar las redes basadas en el business group, crearemos una custom property en el business group con el valor igual al nombre del business group. La razón para crear esta custom property en el business group se debe a que esta no se expone durante el asistente de despliegue de una máquina virtual, por esta razón vRO no puede obtener el valor utilizando las propiedades ASD. Para solucionar este problema, la script action de vRO incluirá una string input que se completa con el valor de la custom property del business group.

Configuración vRO

Comencemos con la configuración de nuestra lista de redes dinámicas forzadas:

  • Copia la script action de vRO incluida en una nueva ubicación. Con este paso nos aseguramos en futuras versiones del plug-in vRA que nada se rompe. Además, la copia será la script action a modificar e incluir el filtro para recuperar solamente las reservas del business group que el solicitante tiene derecho.

Copiar la script action de vRO “getApplicableNetworks”

En vRealize Orchestrator versión 7.2, VMware ha cambiado el código de la script action y la dependencia anterior en 7.1 con la script action llamada “getReservationsForUser”, ha cambiado a “getReservationsForUserAndComponent”. El problema es que la script action “getApplicableNetworks” no funciona en 7.2 ya que VMware se ha olvidado de actualizar el script para incluir como entrada algunos valores que la dependencia “getReservationsForUserAndComponent” requiere.

Si estás utilizando vRO 7.1, puedes omitir este paso.

  • Duplicar la script action actual “getReservationsForUserAndComponent”

Duplicar la script action “getReservationsForUserAndComponent”

  • Degradar a la versión 1.0. El nombre de la script action cambiará a “getReservationsForUser”.

Degradar la script action copiada a version 1.0 (getReservationsForUser)

  • Edita la script action copiada y añade una string input llamada “subtenant”

Añade una string input

  • Ve a la pestaña de script y actualiza la cuarta línea con la carpeta de la script action y el nombre que has duplicado y degradado anteriormente.

var reservations = System.getModule(“com.joseluisgomez.vra.reservations“).getReservationsForUser(user, tenant, host);

  • Entre la 4ª línea (var reservations) y la 5ª línea (var applicableNetworks), agrega la línea siguiente para encontrar el business group con el valor de la custom property de vRA.

var subtenants = vCACCAFEEntitiesFinder.findSubtenants(host, subtenant);

Código actualizado (líneas 4 y 5)

  • El último paso con la script action es agregar un condicional. Se buscará el nombre del business group (subtenant name) que coincida con la string input completada por vRA en todas las reservas recopiladas. Añade la siguiente línea después de “for each“, también puedes agregar una tabulación adicional al código actual para alinearlo correctamente. Además, se requiere una llave de cierre “}” adicional para cerrar el condicional. El código rojo es el nuevo a agregar.

for each(var res in reservations) {
if(res.getSubTenantId() == subtenants[0].id){
var extensionData = res.getExtensionData();
if(extensionData) {
var networks = extensionData.get(“reservationNetworks”);
if(networks) {
for each(var network in networks.getValue()) {
var path = network.getValue().get(“networkPath”);
applicableNetworks.put(path.label, path.label);
}
}
}
}
}
return applicableNetworks;

Condicional a agregar

Hemos terminado con vRO. Ahora es el momento de utilizar esta script action en vRA y nuestro blueprint.

Configuración vRA

  • Crea una custom property para el business group con tu nombre preferido. En mi caso, he utilizado el siguiente:
    • Nombre de la custom property. NGDC.Software.VMware.vRA.Subtenant.Name
    • Valor de la custom property. El nombre del business group (ej .: Tenant_Environment_Service_Index)

Custom property con el nombre del business group como valor

  • Crea una definición de custom property llamada “VirtualMachine.Network0.Name” con la siguiente configuración:
    • Nombre: VirtualMachine.Network0.Name
    • Etiqueta: Select a network
    • Visibilidad: All tenants
    • Orden de muestra: 1
    • Tipo de dato: string
    • Requerido: yes
    • Mostrar como: Dropdown
    • Valores: External values
    • Script action: Haz clic en el botón de cambio y selecciona la script action llamada getApplicableNetworksBySubtenant que hemos creado en los pasos anteriores.
    • Input parameters: Marca la casilla bind y como valor escribe la custom property del business group “NGDC.Software.VMware.vRA.Subtenant.Name“. Nota: La custom property del business group no es descubierta automáticamente si haces clic en la lista desplegable. Debes escribir la custom property.

  • El último paso es agregar en el blueprint la custom property que has creado en el paso anterior. El blueprint no requiere ningún objeto de red, sólo el objeto de máquina virtual de vSphere y agregar a este una NIC virtual. La NIC0 virtual debe tener como custom property lo siguiente:
    • Nombre: VirtualMachine.Network0.Name
    • Valor: Vacío
    • Encriptado: No
    • Sobrescribible: Sí
    • Mostrar en la solicitud: Sí

Blueprint custom property

Resultado

La mejor manera de probar nuestra custom property es crear dos business groups con una reserva cada uno, hacer que el mismo usuario sea el administrador del grupo y crear dos entitlements de catálogo de servicios, uno para cada business group.

La siguiente captura de pantalla muestra el primer business group (Tenant1-Global). Como puedes ver, este business group tiene dos redes. Un dvPortGroup estático (Main) y un NSX VXLAN dvPortGroup (5008-Photon-Hosts)

Lista de red dinámicamente forzada para el business group Tenant1-Global

La siguiente captura de pantalla muestra las redes del segundo business group (CORP_PROD_APP1_01). Como puedes ver, el business group también tiene dos redes, pero diferentes. Dos NSX VXLAN dvPortGroups (5005-NTXCE-Mgmt y 5004-NTXCE-VMs)

Lista de red dinámicamente forzada para el business group CORP_PROD_APP1_01

Conclusión

Espero que lo hayas encontrado útil y pueda ayudarte con implementaciones nuevas y actuales. Este es el mejor enfoque que he encontrado hasta ahora para un diseño multy-tenancy basado en business groups. Este enfoque también funciona si el multi-tenancy se realiza utilizando la funcionalidad de tenants en vRA.

Si te ha gustado, no dudes en compartirlo con tus contactos.

Como operar tu Laboratorio con una Raspberry Pi – Parte 1

Octubre 23, 2016 - - 0 Comentarios

 

Durante mucho tiempo he querido dar algún uso a una vieja Raspberry Pi (Modelo B Revisión 2.0 – 2011.12). Desde que adquirí mi C6100 para el laboratorio casero, era consciente de que no podía mantenerlo encendido 24/7. Desde el punto de vista del ruido y consumo, no es el laboratorio doméstico más idóneo que puedes comprar. En cambio, tienes un montón de recursos para ejecutar cargas de trabajo a un costo reducido.

Con el ruido y el consumo de energía como preocupación, sabía que de alguna manera debería controlar a distancia el laboratorio para poder apagarlo y encenderlo en caso de estar obligado a trabajar con él, o cuando tenga que hacer una demostración a un cliente desde sus instalaciones.

Con los requisitos anteriores, he encontrado a la Raspberry Pi como el dispositivo para soportar los siguientes casos de uso alineados con los requisitos:

  • Servidor VPN
  • Cliente DNS dinámico
  • Estación de control para operar los enchufes con control remoto
  • Estación de control para operar el apagado y encendido del laboratorio

El siguiente diagrama muestra cómo operar tu laboratorio con una Raspberry Pi utilizando diferentes componentes y software.

How to operate your home lab with a raspberry pi

Servidor VPN

Este caso de uso será cubierto en la segunda parte de esta serie de artículos. Pero como breve introducción, el servicio VPN se implementa utilizando un rol de Ansible que he creado, pipoe2h.pivpn (https://galaxy.ansible.com/pipoe2h/pivpn/). Su función será instalar y configurar OpenVPN en tu Raspberry Pi. Tal vez te estés preguntando la razón de no usar pfSense, no tiene soporte para ARM.

Cliente DNS dinámico

Este caso de uso será cubierto en la tercera parte de esta serie de artículos. Pero como adelanto, este caso de uso no abarca sólo la configuración de un cliente de DNS dinámico. La idea es crear tu propio servicio de DNS dinámico si tu alojamiento web ejecuta CPanel. Si eres uno de estos con CPanel, tendrás la oportunidad de crear tu propio servicio de DynDNS y mantener vivo el acceso a tu laboratorio desde donde te encuentres. El servicio DynDNS se puede implementar mediante un rol de Ansible que he creado, pipoe2h.piddns (https://galaxy.ansible.com/pipoe2h/piddns/). Su función será instalar y configurar una página PHP en tu sitio web como punto de entrada para configurar dinámicamente el registro DNS al laboratorio. El cliente DynDNS esta modificado para integrarse con tu propio servicio DynDNS.

Estación de control

La Raspberry Pi te da la oportunidad de que sea la única máquina que esta encendida y reducir así el consumo de energía. Se puede utilizar la Raspi como máquina de salto para operar todo tu laboratorio.

Operar las tomas de control remoto

Este caso de uso será cubierto en la cuarta parte de esta serie de artículos. Como breve introducción, ya que las PDU de gama empresarial con interfaz de gestión para controlar el encendido/apagado de dispositivos son costosas, he encontrado una manera más barata de conseguir al menos el control de encendido/apagado. En una Raspi se puede instalar un placa de control remoto. Usa enchufes con control remoto se puede lograr una experiencia cercana como las PDU empresariales. Yo he comprado el kit de EnerGenie ENER002-2PI por £22.

How to operate your home lab with a raspberry pi

Operar el encendido/apagado del laboratorio

Este caso de uso será cubierto en la quinta parte de esta serie de artículos. Una vez que puedes controlar remotamente tus enchufes, ahora eres capaz de utilizar IPMI o WOL para encender el servidor(es). Compartiré contigo el script PowerCLI que he creado para encender/apagar los hosts ESXi y las máquinas virtuales alojadas.