Libro: VMware por vExperts

Escrito por Blai el 24.4.19

Me entero a través de sysadmit.com, jorgedelacruz.es y pantallazos.es de la salida de un libro gratuito en castellano sobre VMware que lleva por título VMware por vExperts.

Este libro ha sido escrito por nada más y nada menos que 14 autores, los cuales han contribuido explicando diferentes aspectos de VMware: desde qué es la virtualización hasta consejos para equipos que administran entornos VMware, pasando por la realización de backups, réplicas, vMotion...

El índice completo del libro es:

1 – Introducción (Xavi Genestós)
2 – vCenter, ESXi y Maquinas Virtuales (Gorka Izquierdo)
3 – Instalación y Configuración (Xavi Caballé)
4 – Networking (Miguel Angel Alonso)
5 – NSX (Miguel Angel Alonso)
6 – Almacenamiento en vSphere (Leandro Ariel Leonhardt)
7 – vSAN (Federico Cinalli)
8 – Alta Disponibilidad (Leandro Ariel Leonhardt)
9 – Backup y Réplicas (Patricio Cerda)
10 – Monitorización (Jorge de la Cruz)
11 – Monitorizando vSphere con Centreon (Héctor Herrero)
12 – VDI’s con Horizon View (Ricard Ibañez)
13 – Citrix en vSphere (Héctor Herrero)
14 – vRealize Orchestrator (Federico Cinalli)
15 – PowerCLI (Miquel Mariano)
16 – vRealize Automation (Federico Cinalli)
17 – Automatización vSphere con Ansible (Miquel Mariano)
18 – vSphere y Containers (Raúl Unzué)
19 – VMware Code (Daniel Romero)
20 – VMware Cloud en AWS (Jorge de la Cruz)
21 – Consejos para equipos que administran VMware (Ariel Sanchez)

Los autores han juntado a varios sponsors para este proyecto, los cuales han realizado aportaciones económicas directamente a dos obras benéficas:

CEAFA - Confederación Española de Alzheimer

Proyecto Banani

Apenas he tenido tiempo de leer los 3 primeros capítulos, pero debo decir que son muy detallados, al igual que las entradas de los blogs de cada uno de los autores. Estamos ante una obra de calidad de la que se puede aprender mucho, así como ratificar conceptos que ya sabemos.

Podéis descargar el libro gratuitamente desde https://www.vmwareporvexperts.org

Leer más »

Certificados SSL wildcard / comodín

Escrito por Blai el 17.4.19

Qué es un certificado SSL wildcard, cómo generarlo y cómo usarlo en un servidor web.



Un certificado SSL se suele emitir para asegurar un dominio, sea este dominio.com, dominio.net, dominio.org, etc. o un solo subdominio, sea este subdominio.dominio.com, algo.dominio.org, etc.

A parte de certificados SSL emitidos explícitamente para un dominio, existen otro tipo de certificados que permiten asegurar todos los subdominios de un dominio usando un solo certificado SSL. Estos certificados SSL capaces de asegurar múltiples subdominios reciben el nombre de wildcard certificates o "certificados comodín" y se generan como *.dominio.com.

Un certificado comodín puede asegurar al mismo tiempo:

mail.dominio.com
www.dominio.com
contacto.dominio.com
etc.

La principal ventaja de un certificado wildcard es que pagando un solo certificado podemos asegurar todos los subdominios que queramos. Por otro lado, solo podemos asegurar subdominios de primer nivel con un certificado que asegure *.dominio.com.

Si quisieramos asegurar:

es.login.dominio.com
fr.login.dominio.com
it.login.dominio.com
etc.

No podríamos asegurarlos con un certificado wildcard genérico, deberíamos comprar un certificado wildcard de segundo nivel de subdominio, es decir, un certificado que asegurase *.login.dominio.com.

Para generar un certificado wildcard, deberemos seguir los mismos pasos que seguimos para generar un certificado SSL estándar, cambiando el "Common Name" de "dominio.com" a "*.dominio.com" (o a *.sub1.dominio.com para subdominios de segundo nivel) .

El CSR o Certificate Signing Request de un certificado wildcard se generará de la siguiente forma:

C:\temp>openssl req -nodes -keyout clave_privada.key -out pedido_certificado.csr -newkey rsa:2048 Generating a 2048 bit RSA private key ..........................................+++ ..........................................+++ writing new private key to 'clave_privada.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Barcelona Locality Name (eg, city) []:Barcelona Organization Name (eg, company) [Internet Widgits Pty Ltd]:Empresa Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:*.dominio.com Email Address []:hola@email.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

Como comentaba antes, en la línea:

Common Name (e.g. server FQDN or YOUR name) []:*.dominio.com

Se debe introducir *.dominio.com para que el CSR sea válido para generar un certificado wildcard que sea válido para cualquier subdominio de primer nivel de dominio.com.

El siguiente paso es enviar el CSR generado una entidad certificadora para que esta nos devuelva el .crt.

El último paso sería poner ese archivo .crt (parte pública del certificado) y el archivo .key (parte privada del certificado) dentro del servidor web que aloje "algo.dominio.com". A partir de ese momento, cuando alguien acceda a https://algo.dominio.com verá que el subdominio está asegurado con un certificado.

Leer más »

Añadir disco a clúster IBM Spectrum Scale

Escrito por Blai el 10.4.19

Cómo añadir un disco a un clúster de IBM Spectrum Scale en un sistema Linux, paso a paso.



Me encontré recientemente con una base de datos que no arrancaba. Esta base de datos está ubicada en un servidor Linux, así que descartando posibles causas del problema, hice un df -h para ver el procentaje de ocupación de los filesystems del S.O. Fue entonces cuando vi que el filesystem sobre el que reside la base de datos, al que llamaremos "montaje", estaba totalmente lleno (Use%: 100%):

HOST# df -h Filesystem             Size Used Avail Use% Mounted on /dev/sda2               95G  12G   79G  13% / devtmpfs               420G 8.0K  420G   1% /dev tmpfs                  420G  80K  420G   1% /dev/shm tmpfs                  420G  10M  420G   1% /run tmpfs                  420G    0  420G   0% /sys/fs/cgroup /dev/sda1              148M    0  148M   0% /boot/efi /dev/montaje           1.3T 1.3T     0 100% /montaje

Este "montaje" está montado sobre un clúster de IBM Spectrum Scale. Tras ver que no podía liberar espacio en el directorio, decidí añadir un disco al clúster para darle más espacio a /montaje.

Para añadir un disco a un clúster de IBM Spectrum Scale, primero debemos añadir un disco físico o virtual al sistema operativo. Añadí un disco de 1 TB a la máquina virtual y luego miré qué letra se le había asignado al disco a nivel de sistema operativo:

HOST# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0    2:0    1 4K    0 disk sda    8:0    0 128G  0 disk ├─sda1 8:1    0 148M  0 part /boot/efi ├─sda2 8:2    0 95.9G 0 part / └─sda3 8:3    0 32G   0 part [SWAP] sdb    8:16   0 250G  0 disk └─sdb1 8:17   0 250G  0 part sdc    8:32   0 1T    0 disk └─sdc1 8:33   0 1024G 0 part sdd    8:48   0 1T    0 disk sr0    11:0   1 4.1G  0 rom sr1    11:1   1 4.1G  0 rom sr2    11:2   1 8.5M  0 rom

Vi que era el disco "sdd". Me dirigí entonces al directorio /var/mmfs/config y copié el fichero usado en la creación del primer nodo del cluster (NSD server) hacia un nuevo archivo:

HOST# cp disk.list.data.gpfsnode01 disk.list.data.gpfsnode01.new.adddisk

Edité este archivo cambiando los siguientes valores:

device=/dev/sda por device=/dev/sdd
nsd=data01node01 por nsd=data03node01

De modo que el archivo quedó así:

%nsd: device=/dev/sdd nsd=data03node01 servers=gpfsnode01 usage=dataAndMetadata failureGroup=1001 pool=system

Para saber qué nombre usar en el campo "nsd" (para no introducir un nombre que ya estuviese en uso), ejecuté el comando mmlsnsd para listar los Disk Name ya usados en el clúster:

HOST# mmlsnsd File system   Disk name    NSD servers --------------------------------------------------------------------------- montaje       data01node01 gpfsnode01 montaje       data02node01 gpfsnode01

Preparé el disco para ser añadido al clúster con el comando mmcrnsd -F:

HOST# mmcrnsd -F disk.list.data.gpfsnode01.new.adddisk -v yes mmcrnsd: Processing disk sdd

Hecho esto, el disco data03node01 quedó preparado para ser añadido al clúster:

HOST# mmlsnsd File system   Disk name    NSD servers --------------------------------------------------------------------------- montaje       data01node01 gpfsnode01 montaje       data02node01 gpfsnode01 (free disk)   data03node01 gpfsnode01

Por último, añadí el disco al clúster con el comando mmadddisk:

HOST# mmadddisk montaje -F disk.list.data.gpfsnode01.new.adddisk The following disks of montaje will be formatted on node HOST: data03node01: size 1048576 MB Extending Allocation Map Checking Allocation Map for storage pool system Completed adding disks to file system montaje.

Verifiqué que se hubiera añadido el disco al clúster:

HOST# mmlsnsd File system   Disk name    NSD servers --------------------------------------------------------------------------- montaje       data01node01 gpfsnode01 montaje       data02node01 gpfsnode01 montaje       data03node01 gpfsnode01

Con el disco ya añadido al clúster, vi que el espacio total de "montaje" había incrementado en 1 TB. Gracias a esto, el filesystem ya no estaba al 100% de uso:

HOST# df -h Filesystem             Size Used Avail Use% Mounted on /dev/sda2               95G  12G   79G  13% / devtmpfs               420G 8.0K  420G   1% /dev tmpfs                  420G  80K  420G   1% /dev/shm tmpfs                  420G  10M  420G   1% /run tmpfs                  420G    0  420G   0% /sys/fs/cgroup /dev/sda1              148M    0  148M   0% /boot/efi /dev/montaje           2.3T 1.3T     0  50% /montaje

Llegados a este punto, probé a levantar la base de datos y ya arrancó sin problemas.


Fuentes:

https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc
https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.0/com.ibm.spectrum.scale.v4r2.adm.doc

Leer más »

HTTP Load Balancing en nginx

Escrito por Blai el 3.4.19

Cómo configurar load balancing de un servicio HTTP/HTTPS en nginx.



nginx, cuando actúa como reverse proxy, permite hacer balanceo de carga (load balancing) de las peticiones HTTP que le entran a un dominio determinado. Es decir, permite enviar tráfico entrante de un dominio hacia un servidor web u otro dependiendo de ciertas condiciones.

Imaginemos que tenemos un servicio antispam de la marca Barracuda, compuesto por dos aparatos cuyas IPs son 192.168.1.1 y 192.168.1.2. Estos aparatos están conectados en clúster para ofrecer un servicio de alta disponibilidad, de modo que si un aparato cae, el otro recibe todas las conexiones y sigue ofreciendo servicio y viceversa. Además, este clúster permite que los cambios aplicados en un apartado se repliquen al instante al otro aparato, de modo que la administración del servicio antispam puede realizarse desde cualquiera de las dos IPs.

Supongamos también que queremos apuntar la dirección antispam.dominio.com a los dos aparatos, pues apuntar el FQDN a una sola IP nos dejaría sin gestión si uno de los aparatos cayera.

nginx nos ofrece una solución a esta necesidad con su servicio de load balancing de tráfico HTTP. Para hacerlo, apuntamos antispam.dominio.com a la IP del servidor que corre nginx y en la configuración de nginx creamos una política "upstream" que haga balanceo de carga hacia dos o más servidores finales.

El código que nos permite hacer balanceo de carga HTTP es algo parecido a esto:

http {     upstream upstream_antispam {         server 192.168.1.1:8000;         server 192.168.1.2:8000;     }     server {         listen 443 ssl;         server_name antispam.dominio.com;         location / {             proxy_pass http://upstream_antispam;         }     } }

En este código, he creado un bloque "upstream" de nombre "upstream_antispam" que contiene las dos direcciones IP de los aparatos Barracuda, así como el puerto de gestión HTTP que usan (puerto 8000).

Debajo del bloque upstream, he creado un bloque "server" que realiza la función de reverse proxy (proxy_pass) y envía el tráfico al bloque upstream "upstream_antispam" anteriormente declarado.

Con esto, lo que conseguimos es que el tráfico que vaya a https://antispam.dominio.com se vaya repartiendo entre http://192.168.1.1:8000 y http://192.168.1.2:8000, según criterios varios como ¿están las dos IPs activas? ¿hay muchas sesiones activas en una de las IPs? etc.

A partir de este momento, si cae el aparato con IP 192.168.1.1, todo el tráfico que entre a https://antispam.dominio.com pasará a 192.168.1.2. Y si cayera el 192.168.1.2, todo el tráfico pasaría por 192.168.1.1. Si los dos están activos, el tráfico pasará por ambos.

Leer más »