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

Plugin NFS VAAI de Synology en VMware vSphere 6.0

Como no es la primera vez que me lo preguntan, sí, el plugin de VAAI de vSphere, que según el README de Synology es solo para versión 5.5, funciona correctamente en VMware vSphere 6.0. Lo he instalado en los hosts del laboratorio, con el comando que detalla el README, añadiendo –no-sig-check al final.

Quedaría de la siguiente forma: esxcli software vib install -v /esx-nfsplugin.vib --no-sig-check

Después de reiniciar los hosts, veremos que en la opción de “Hardware Acceleration” aparecerá “Supported”

Reflexiones sobre el Cloud y sus aplicaciones

A raíz de unas jornadas en mi actual empleador, hemos estado hablando sobre el estado del Cloud y sobre el portfolio de una nueva empresa que se ha incorporado al grupo, provocando que por una vez le de al coco. Voy a evitar hablar sobre Devops, Infrastructure as Code, Continuous integration, Continuous development y demás términos que muchos ya estamos acostumbrados, y voy a centrarme en otro aspecto mucho menos tenido en cuenta, pero que marca una diferencia brutal. La arquitectura.

¿Qué se define exactamente como Cloud?

Según el NIST, y cito textualmente:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Con las siguientes características:

On-demand self-service.

Broad network access.

Resource pooling.

Rapid elasticity.

Measured service.

Esto significa que no es posible hablar de Cloud fuera de las grandes casas (Amazon Web Services, Microsoft Azure, Google Cloud Platform)? Para nada, se puede desarrollar un cloud interno, apoyado por tecnologías ahora mismo disponibles para las empresas, como VMware vSphere y OpenStack, pero hay mucho proveedor “cloud” que no lo es, por mucho que se empeñen en decir que lo son.

Pero todos sabemos que queda muy cool decir que tal o cual empresa ya está en la nube, cuando realmente sus aplicaciones ni son cloud-ready ni cloud-native-applications.

Y se llega al quid de la cuestión, ¿todas las empresas pueden tener su infraestructura en la nube? Y aquí llega la respuesta de consultor: “Depende”.

Por poder puedes tener la infraestructura que quieras en la nube, pero puede que no le estés sacando todo el rendimiento que crees ni podrás hacerlo, si tus aplicaciones no están pensadas para funcionar en la nube. Lo primero que acarrea el Cloud, es un cambio en el paradigma de la arquitectura de aplicaciones, más que un cambio en la forma de operar las mismas (el archiconocido devops) donde la aplicación deberá ser capaz de funcionar bajo eliminaciones aleatorias de instancias, problemas de conectividad y mil calamidades más.

Este cambio de paradigma queda reflejado en los Twelve factors, que toda aplicación realmente Cloud-Native debería cumplir, actualmente fijados en lo siguiente:

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes ```

¿Qué significan estos factors? Un cambio en la forma de diseñar las aplicaciones. Un cambio en la mentalidad de la arquitectura. Pasar de pets a cattles. Pasar de monolytic architecture a distributed architecture. Pasar de conexiones directas entre servicios al uso de APIs y mensajería asíncrona.

Si no eres capaz de asumir este cambio, lo siento, tu aplicación no está hecha para funcionar en la nube. Por lo menos no permitiéndote mantener tu salud mental. Ni la de tu equipo de Operaciones.

Modificando umbrales de alerta de los ventiladores en Supermicro

En el post de hoy, voy a cubrir lo que hay que hacer para poder cambiar los umbrales de alerta de los ventiladores en las placa base de Supermicro. Si habeis leído la información sobre mi lab, tengo un par de máquinas Supermicro (un Xeon D-1520 y un D-1540), siendo la 1520 fanless y sinceramente, se calienta mucho. Así que le he puesto un ventilador Noctua como he podido, pero funciona tan bien que bajaba a 300 revoluciones, y hacía que saltara una alarma tanto en la IPMI como en vCenter, saturándome el correo siendo muy molesto.

La solución? Modificar los umbrales de la IPMI, pero esto no puede hacerse desde la interfaz web, pero sí mediante línea de comandos.

Primeros instalaremos la herramienta IPMITOOL, en mi caso usando Brew (estoy en un Mac).

A continuación, ejecutaremos el siguiente comando: ipmitool -U ADMIN -P ADMIN -H IP sensor thresh lower FAN2 150 225 300

Donde el primer valor (150) es el error Lower Non-Recoverable, el segundo (225) es el Lower Critical y 300 es el Lower Non-Critical. Con esto, conseguimos modificar los valores. En mi caso no me hizo falta reiniciar, y ya dejaron de llegarme los avisos.

Desplegando VCSA sobre línea de comandos

Mientras estoy mirando como automatizar la creación de un nested lab (sí, ya sé que existe AutoLab, but just because) os explico como desplegar un VCSA 6.0 desde línea de comandos, usando una fantástica utilidad llamada vcsa-deploy. Mediante un fichero JSON, podemos invocar la utilidad y automáticamente desplegará un VCSA con la configuración que le hagas llegar por el fichero JSON.

El fichero JSON es el siguiente

Desde nuestro equipo, montaremos la ISO y dentro del directorio vcsa-cli-installer encontraremos los directorios para los distintos sistemas operativos soportados. En mi caso usaré el de OS X

./vcsa-deploy ~/repos/homelab/vcsa.json --accept-eula

Ejecutando eso, empezará a desplegar el VCSA. Para que os hagáis una idea de los tiempos, sobre una conexión Wifi con 200Mbps de ancho de banda, tardó 13 minutos en todo el proceso!

Sin lugar a dudas, muy útil.

Configurando iSCSI a golpe de Powercli

Hoy os traigo una breve entrada sobre como configurar iSCSI sobre uno (o varios) hosts vSphere a golpe de teclado. Podríamos usar ansible, pero como estoy repasando para el VCAP-DCA… Lo haremos a base de Powershell!

Conectamos con el vCenter

Connect-VIServer vcenter.vfondevilla.com -User administrator@vsphere.local -Password P@ssw0rd!

Creamos el adaptador iSCSI

Get-VMHostStorage -VMhost vesx01.vfondevilla.com | Set-VMHostStorage -SoftwareIScsiEnabled $True

Creamos el target iSCSI en la HBA que acabamos de crear

get-vmhost vesx01.vfondevilla.com | get-vmhosthba -type "iscsi" |New-IScsiHbaTarget -Address 192.168.30.254

Bindeamos el adaptador a la interfaz VMK

(get-esxcli -VMHost vesx01.vfondevilla.com).iscsi.networkportal.add("vmhba33", $true, "vmk0")

Tras esto, haremos un rescan de las HBA

Get-VMHostStorage vesx03.vfondevilla.com -RescanAllHba

Et voilá, ya tenemos las LUNs disponibles para nuestros hosts!