Tales from a Solution Architect vMotioning from Solution Engineering to Solution Architects

Como calcular vCPUs y vRAM provisionadas en un cluster de VMware

Muchas veces nos preguntamos cuantas vCPUs tenemos provisionadas para mantener la contención controlada, al igual que la RAM que tenemos provisional (que no activa) en las VMs. Desde la PowerCLI de VMware podemos ejecutar lo siguiente:

Memoria RAM provisionada

(get-datacenter virtualdatacenterName | get-cluster | get-vm | measure-object 'memoryGB' -sum).sum

vCPUs provisionadas

(get-datacenter virtualdatacenterName | get-cluster | get-vm | measure-object 'numcpu' -sum).sum

Con esto, obtentendreis los valores :)

vRealize Automation - Desplegando vRealize Appliance

En este post, procederemos a desplegar la appliance vRealize, tal y como hicimos con la Identity Appliance. Los datos de esta appliance en mi caso son los siguientes:

  • Dirección IP: 192.168.1.246/24
  • Gateway: 192.168.1.2
  • Hostname: vcac.vfondevilla.local

Tras haber desplegado la appliance, nos conectaremos a la VAMI de la misma (https://vcac.vfondevilla.local:5480) y pincharemos sobre vRA Settings En Host Settings marcaremos la opción de Resolve Automatically para que nos rellene el campo con el hostname y Generate Certificate que rellenaremos con los campos que creamos convenientes vRA setup

Aplicaremos los cambios y procederemos a configurar la parte de SSO con el hostname vcac-identity.vfondevilla.local vRA setup

Aceptamos el certificado de la vcac-identity y debería salirnos en verde con el estado Connected. En este paso pueden pasar varios minutos, paciencia vRA setup vRA setup

Metemos la licencia de la aplicación (obviamente aquí no pongo captura de pantalla :)) y esperamos unos minutos mientras aplica los cambios en el sistema.

Tras estos pasos, mirar que en la pestaña Services aparecen registered por lo menos los siguientes:

  • authorization
  • authentication
  • eventlog-service
  • shell-ui-app
  • branding-service
  • plugin-service

Tras esto solo queda acceder a https://vcac.vfondevilla.local/vcac y loguearse con los datos del SSO que se configuraron en el despliegue de la Identity Appliance, para comprobar que la parte de la gestión de vRA está operativa, solo nos quedaría la parte del IaaS, que trataremos en la siguiente parte.

Primeros pensamientos sobre VMware Integrated OpenStack

He desplegado (parcialmente) VMware Integrated OpenStack en mi homelab, y he de decir que ha sido un poco dulce-amargo, dulce por la posibilidad de poder usar un nuevo estándar de facto como OpenStack encima del hypervisor que probablemente ya esté en producción, y amargo porque los requerimientos por defecto de VMware son totalmente abrumadores, y para muestra os pego los requisitos de la suite.

OpenStack Requirements

192 GB de RAM, 56 vCPUs y 605 GB de Storage. Tendré que mirar cuanto puedo reducirlo y si entrará en 40GB de RAM siendo minimamente usable, porque si no veo pidiéndole a la empresa que me monte un laboratorio enterprise-grade para poder jugar con ello.

Como ventajas que le veo:

  • Soportado por VMware, siendo el soporte opcional. Mientras no lo tengas en producción, el coste que te ahorras.
  • Upgrades probados por VMware, siendo completamente drop-in
  • Abstracción de la capa de hypervisor, facilitando una posible integración de nuevos hypervisores.

Como desventajas principales:

  • Los requisitos mínimos marcados por VMware, 15 VMs, 56 vCPU y 192 GB de RAM, prácticamente te comes un servidor en la infraestructura OpenStack
  • Para sacarle el máximo jugo posible necesitas tener NSX instalado en el entorno, si no pierdes parte de las funcionalidades de red como segmentación de capa 2 y parte de los servicios de capa 3 como routers virtuales e IPs flotantes.

Solo me queda decir que estoy emocionado con esta nueva suite y espero poder probarla a fondo estos días. ¡Gracias VMware!

vRealize Automation - Pre-requisitos y desplegando SSO

Empiezo esta serie de posts respecto al despliegue de la suite vRealize Automation, anteriormente conocida como vCloud Automation Center o vCAC. Para los que no conozcan esta suite de VMware, es la evolución de vCloud Director, añadiendo la posibilidad de desplegar workloads en cloud público (Amazon, vCloud Air...)

En este caso, vamos a desplegar 3 VMs para dar el servicio, que son la Identity Appliance (o SSO), el componente IaaS y la appliance vRealize Automation y aprovecharé un servidor con SQL Server 2014 que ya tengo desplegado en el homelab para alojar la BBDD de vRA.

Como pre-requisitos, debemos tener un Active Directory presente, con sus funciones de DNS ya que el software requiere de trabajar con FQDNs. En este caso vamos a trabajar con el dominio vfondevilla.local que es el dominio de mi homelab

Para la parte de SQL Server del componente IaaS, necesitaremos:

  • Que el protocolo TCP/IP esté habilitado en MS SQL Server
  • Microsoft Distributed Transaction Coordinator Service (MS DTC) en todos los nodos de SQL
  • Puertos entre las distintas máquinas abiertos, si tienes dudas de cuales son, revisa la documentación de vRealize Automation

Procedemos a desplegar la Identity Appliance, rellenando los menús del OVF correspondientes, en este caso los datos de mi laboratorio son los siguientes:

  • Dirección IP: 192.168.1.247/24
  • Gateway: 192.168.1.2
  • Hostname: vcac-identity.vfondevilla.local

Tras haber desplegado la appliance, procederemos a conectarnos a https://vcac-identity.vfondevilla.local:5480, donde nos aparecerá la VAMI de la appliance y nos logaremos con las credenciales introducidas en el momento de desplegar la appliance.

Configuraremos la zona horaria, en mi caso Europe/Madrid, y en la pestaña Admin/Time Settings, lo configuraremos en modo "Use Time Server" e introduciremos la IP del controlador de dominio. vRA setup

Como curiosidad, la contraseña de administrador de la appliance caduca en un año, y por lo que he visto no se puede deshabilitar que caduque, así que ojito con la bomba de tiempo que nos deja VMware!

La siguiente parte será la configuración del SSO, donde introduciremos la contraseña del usuario administrator del dominio vsphere.local que es el de por defecto. vRA setup

Tras haber cambiado la contraseña (puede tardar un par de minutos), pasaremos a la sección Host settings donde verificaremos que el nombre es correcto. En otras versiones de vRealize Automation o vCAC en esta parte había que añadir :7444 en el hostname de la appliance, pero en la versión 6.2 ya no nos hará falta hacerlo.

A continuación generaremos un certificado autofirmado (o si teneis un SSL, lo procederemos a importar) vRA setup

Por último, uniremos nuestro appliance al Active Directory para el control del login, en la pestaña Active Directory, introduciremos los datos del Active Directory y presionaremos en apply. En mi caso en un primer momento me dió error: Warning: Cannot resolve domain controller IP address 192.168.1.252. There is a network misconfiguration. Check the host name, DNS Servers, and DHCP settings on the Network tab. You may need to restart the appliance after changing the network configuration.

Esto es debido a que no podía resolver la ip del DNS, en la pestaña Network, Address vi que falta el Domain Name, lo añadí y ya se unió correctamente al dominio.

Tras esto, hemos completado de desplegar la Identity Appliance del vRA en nuestro laboratorio.

Autoscaling en VMware - Despliegue del servidor DSC

Como siguiente paso, vamos a proceder a desplegar una VM que alojará nuestro servidor DSC en modo pull, donde iremos alojando los ficheros de configuración (mof) de las máquinas de nuestro dominio. La desplegaremos en el direccionamiento asignado al cliente Cestas Asociadas (192.168.30.0/24), conjuntamente con el Domain Controller.

Tras haberla desplegado, procederemos a instalar la característica (feature) de Windows PowerShell Desired State Configuration, tanto por la GUI como por Powershell. Si lo hacemos por powershell hay que añadir la consola de IIS a la instalación

Add-WindowsFeature Dsc-Service, Web-Mgmt-Console

Tras esto procedemos a instalar el módulo de Powershell xPSDesiredStateConfiguration descargándolo de https://gallery.technet.microsoft.com/xPSDesiredStateConfiguratio-417dc71d y descomprimiéndolo en %programfiles%\WindowsPowerShell\modules

Habilitamos el listener de WinRM (Windows Remote Management)

winrm quickconfig

Para darle más seguridad al sistema, vamos a proceder a configurar el servidor DSC en modo HTTPS. (Paranoia mode on)

Instalaremos un certificado emitido para el servidor dsc-server.test.local, que previamente habremos solicitado a la CA del dominio, con el friendly name de dsc webserver

Nos apuntaremos el Thumbprint del certificado, que conseguiremos de la siguiente forma:

Get-ChildItem -Path cert: -Recurse | Where { $_.FriendlyName contains dsc* } | select Subject, FriendlyName, Thumbprint | Format-List

Tras esto crearemos una configuración DSC para el propio servidor DSC, que nos configurará todo lo necesario.

configuration NewPullServer
{
    param
    (
        [string[]]$ComputerName = 'localhost'
    )
    Import-DSCResource -ModuleName xPSDesiredStateConfiguration
    Node $ComputerName
    {
        WindowsFeature DSCServiceFeature
        {
            Ensure = "Present"
            Name   = "DSC-Service"
        }
        xDscWebService PSDSCPullServer
        {
            Ensure                  = "Present"
            EndpointName            = "PSDSCPullServer"
            Port                    = 8080
            PhysicalPath            = "$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer"
            CertificateThumbPrint   = "E493BC34B3E0AA33A482FCB3E159670AE585A984"
            ModulePath              = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
            ConfigurationPath       = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
            State                   = "Started"
            DependsOn               = "[WindowsFeature]DSCServiceFeature"
        }
        xDscWebService PSDSCComplianceServer
        {
            Ensure                  = "Present"
            EndpointName            = "PSDSCComplianceServer"
            Port                    = 9080
            PhysicalPath            = "$env:SystemDrive\inetpub\wwwroot\PSDSCComplianceServer"
            CertificateThumbPrint   = "E493BC34B3E0AA33A482FCB3E159670AE585A984"
            State                   = "Started"
            IsComplianceServer      = $true
            DependsOn               = ("[WindowsFeature]DSCServiceFeature","[xDSCWebService]PSDSCPullServer")
        }
    }
}

NewPullServer ComputerName dsc.test.local

Esto nos generará una nueva carpeta, llamada NewPullServer donde contendrá el .mof del servidor dsc.test.local Tras intentar ejecutarlo, con Start-DscConfiguration .\NewPullServer -Wait os dará un fallo, de este estilo: ``` PowerShell provider MSFT_xDSCWebService failed to execute Set-TargetResource functionality with error message: ERROR: C:\Windows\System32\WindowsPowerShell\v1.0\modules\PSDesiredStateConfiguration\PullServer\es\Microsoft.Powershell.Desir edStateConfiguration.Service.Resources.dll does not exist + CategoryInfo : InvalidOperation: (:) [], CimException + FullyQualifiedErrorId : ProviderOperationExecutionFailure + PSComputerName : dsc.test.local

The SendConfigurationApply function did not succeed. + CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException + FullyQualifiedErrorId : MI RESULT 1 + PSComputerName : dsc.test.local ``` Se soluciona copiando y renombrando C:\Windows\System32\WindowsPowerShell\v1.0\modules\PSDesiredStateConfiguration\PullServer\en\ a C:\Windows\System32\WindowsPowerShell\v1.0\modules\PSDesiredStateConfiguration\PullServer\es\

Tras esto la ejecución de la configuración se completará correctamente. Desde el IIS Manager podremos confirmar que los bindings del servidor DSC se han creado en el protocolo HTTPS.