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

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!

vVNX en el homelab

Hoy os traigo este post, en el que os explicaré como he montado la vVNX de EMC, la appliance virtual de storage, en mi homelab.

Empezamos descargandola directamente desde la web de EMC, donde obtendremos el fichero OVA que conformará nuestra cabina de discos virtual.

Desplegamos el “nuevo cacharro que cuesta varios miles de €” en nuestra infraestructura de VMware, pero ojo! Pide 2 vCPU y 12GB de RAM, así que aseguraos que hay suficiente RAM disponible.

Una vez hayamos desplegado la OVA, obtendrá la IP por DHCP y podremos acceder a la interfaz por el puerto https.

Las credenciales por defecto, son Usuario:

admin

Contraseña:

Password123#

Una vez nos loguemos, tendremos que pasar por el Wizard de configuración de la vVNX, con los típicos pasos:

  • EULA
  • Cambio de contraseña de administrador

Y llegaremos a la parte del licenciamiento, donde nos tocará acceder al sitio de soporte de EMC donde introduciremos el System UUID, con esto nos devolverán un fichero LIC, que es la licencia de nuestra appliance.

Seguimos configurando:

  • DNS
  • NTP

Y llegaremos a la parte propiamente dicha de almacenamiento, donde podremos crear los storage pools que queramos.

Aquí hay varias opciones:

  • Usar VMDKs
  • Usar RDMs
  • Passthrough de la controladora RAID o HBA a la VM

En mi caso, ya que no tengo tarjetas RAID ni HBAs ni tengo budget asignado para comprarlas, he usado RDMs, ya trataré en otro post como crear estos RDMs sin tarjetas RAID ni HBA.

En mi caso, he creado dos Storage Pool distintos, cada uno en un SSD distinto, asignando el más pequeño de los dos el rol de “Performance Tier” y al más grande el de “Capacity Tier”, aunque en este caso no tiene ningún tipo de diferencia. Tener dos Tiers distintos nos permite hacer uso del Autotiering de EMC, moviendo los datos calientes al Performance Tier, teniendo la licencia correcta

screen shot 2016-01-05 at 21 23 33

Seleccionaremos los discos que funcionarán con este Storage Pool

screen shot 2016-01-05 at 21 23 59

screen shot 2016-01-05 at 21 24 11

Posteriormente, podremos configurar iSCSI/NFS (según nuestras preferencias), en mi caso he creado dos interfaces iSCSI en dos subnets distintas, con el fin de aplicar Multipathing en el Nested Lab.

screen shot 2016-01-05 at 21 27 40

No configuramos la replicación, aunque podríamos con otro sistema vVNX y montar escenarios que hagan uso de Site Recovery Manager!

Tras haber creado el almacenamiento, pasaremos a configurar los Host ESX en la interfaz de nuestra vVNX. Haremos clic en “Hosts” y posteriormente “VMware Hosts”. En la parte inferior de la página, pulsaremos en “Find ESX Hosts”.

screen shot 2016-01-05 at 21 32 39

Introduciremos el nombre de nuestro vCenter y pulsaremos sobre “Find”, nos pedirá las credenciales de nuestro usuario (de vCenter) y añadiremos los hosts a la vVNX.

screen shot 2016-01-05 at 21 34 00

screen shot 2016-01-05 at 21 34 26

Pasaremos a crear nuestro Datastore, pinchando sobre “Storage” y a su vez en “VMware Datastores”.

Una vez nos pongamos a crear el Datastore, seleccionaremos la tecnología que queramos usar (NFS/VMFS)

screen shot 2016-01-05 at 21 37 25

Introduciremos el nombre y la descripción (esto último es opcional)

screen shot 2016-01-05 at 21 38 12

Seleccionaremos el Storage Pool sobre el que vamos a crear el Datastore

screen shot 2016-01-05 at 21 39 16

Seleccionamos la política de Snapshots automáticos a nivel de VNX (en mi caso lo he deshabilitado)

Configuramos los accesos de los Hosts que añadimos anteriormente, dando acceso a las LUN a los hosts.

Y ya podemos dar por finalizado la configuración!

La propia VNX se encargará de logarse contra el vCenter, y en los hosts que se lo hayamos indicado, crear el Datastore.