Reducción de discos virtuales con LVM con libvirtd y qemu

Antes de nada, este procedimiento es aplicable a servidores virtualizados con libvirt y que utilizan qemu como KVM. Yo lo he ejecutado sobre RHEL6.x, RHEL7.x y Debian8.x. Se trata de un caso concreto, tal y como se hizo.

ANTES DE EMPEZAR, PARA LA MÁQUINA Y HAZ UN BACKUP DE DISCO

Arranca la máquina y para servicios críticos. La información que necesitas tener MUY clara es

• el directorio que voy a reducir y qué volumen lógico es (LV)
• a qué grupo de volúmenes pertenece (VG)
• a qué volumen físico pertenece (PV)

y con toda esta información, puedo ver qué LV/VG/PVs voy a redimensionar. Si no estás familiarizado con el sistema LVM de Linux, por favor, pídele a otra persona que ejecute este proceso.

La estructura del LVM de este servidor es:

[root@server ~]# pvs
     PV VG Fmt Attr PSize PFree
     /dev/vda3 vgsys lvm2 a-- 29,25g 11,50g
     /dev/vda5 vgdata lvm2 a-- 200,00g 12,00g


[root@server ~]# vgs
     VG #PV #LV #SN Attr VSize VFree
     vgdata 1 3 0 wz--n- 200,00g 12,00g
     vgsys 1 3 0 wz--n- 29,25g 11,50g


[root@server ~]# lvs
     LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
     lv_home vgdata -wi-ao-- 4,00g
     lv_ihs vgdata -wi-ao-- 180,00g
     lv_opt vgdata -wi-ao-- 4,00g
     lv_root vgsys -wi-ao-- 11,75g
     lv_tmp vgsys -wi-ao-- 1,00g
     lv_var vgsys -wi-ao-- 5,00g

En este ejemplo, el directorio /ihs se definió muy grande pero ya no se usa tanto espacio, así que tenemos que reducirlo. Los pasos que vamos a dar son los siguientes:

• detectar qué LV hay que reducir → ya lo hemos hecho, el lv_ihs
• detectar en qué VG y PV está alojado → son el vgdata y el /dev/vda5
• hacer un backup de todos los LVs alojados en el VG afectado
• eliminar los LVs, el VG y el PV
• redefinir a nivel de disco las particiones
• recortar el espacio del disco que ya no se va a utilizar y redimensionar el archivo
• montar de nuevo el PV, el VG y los LVs
• volcar el backup

Ahora sí, vamos por partes

Haz una copia del disco. Para la máquina y cópiala con otro nombre

Una vez arranques la máquina de nuevo, para servicios que puedan estar trabajando con los directorios que estén sobre los LVs con los que vamos a trabajar.

Para ver si hay algo en uso (librerías, archivos, lo que sea) yo utilizo el comando lsof de esta manera:

> lsof -l | grep “/ihs”
> lsof -l | grep “/opt”
> lsof -l | grep “/home”

Si alguno de estos comandos te devuelve algo, es porque hay algún archivo en uso y es probable que no hayas parado el servicio.

Lanzo los backups; puedo hacer un tgz o un dd; voy a probar con tgz

> tar -czvf /mnt/server/opt.tgz /opt
> tar -czvf /mnt/server/ihs.tgz /ihs
> tar -czvf /mnt/server/home.tgz /home

Después voy a desmontar los LVs y los elimino; aprovecho y comento las unidades en /etc/fstab para que cuando reinicie no tenga problemas

> umount /opt
> umount /ihs
> umount /home
> lvremove /dev/mapper/vgdata-lv_opt
> lvremove /dev/mapper/vgdata-lv_home
> lvremove /dev/mapper/vgdata-lv_ihs
> vi /etc/fstab → y comento las unidades desmontadas

Voy a desactivar el VG y lo elimino

> vgchange -a n vgdata
> vgremove vgdata

Y ahora elimino el disco vda5 del PV, que es el que contiene el VG que acabo de eliminar

> pvremove /dev/vda5

Antes de parar el servidor, doy de baja la partición desde fdisk

> fdisk /dev/vda

Dentro del fdisk con la p veo todas las particiones cómo están definidas. Las tareas que YO tengo que hacer son (es probable que TÚ tengas otras, dependerá de cómo se particionó el disco en su momento)

• eliminar la partición extendida vda5
• eliminar la partición primaria vda4
• añadir una nueva partición vda4 del tamaño que corresponda (1)
• indicar que el formato de la nueva partición vda4 es LVM

(1) El tamaño va a depender del tamaño que le vaya a dar a los nuevos LV; en mi caso, a /opt le damos 4GB, a /home le damos otros 4GB y a /ihs le damos 20GB, que hacen 28GB. Para no pillarme los dedos, voy a definir una partición de 30GB. El tamaño que le voy a dar a la unidad lo hago cuando la creo, y le asigno el tamaño con un +30G

Una vez he guardado los cambios en del fdisk, paro la máquina y redimensiono los discos. Recuerda que tienes que tener espacio para hacerlo; al menos vas a necesitar el mismo espacio que el que ocupa ahora el archivo del disco, como si lo fueras a duplicar.

> qemu-img convert Server.img -O raw Server.raw

de qcow2 a raw, porque en formato qcow2 no se pueden hacer resizes

> qemu-img resize Server.raw 50G → Cambio el tamaño del disco
> qemu-img convert Server.raw -O qcow2 Server.img → Convierto de raw a qcow2. Cuidado en este paso, si lo ejecutas así borrarás el disco original. Apunta a un fichero con otro nombre o en otro directorio

Arranca la máquina de nuevo (2) y empieza a montar de nuevo la estructura.
Creo el nuevo PV

> pvscan
> pvcreate /dev/vda4

Creo el nuevo VG

> vgcreate vgdata /dev/vda4

Creo los LVs y los formateo (3)

> lvcreate --size 4G -n lv_opt vgdata
> lvcreate --size 4G -n lv_home vgdata
> lvcreate --size 20G -n lv_ihs vgdata
> mkfs.ext4 /dev/vgdata/lv_opt
> mkfs.ext4 /dev/vgdata/lv_home
> mkfs.ext4 /dev/vgdata/lv_ihs

Descomento el /etc/fstab y monto las unidades

> mount -a

Por último restauro el contenido de las carpetas, muevo el contenido de los backups y los vuelco. Después reinicio el servidor y compruebo que los servicios arrancan correctamente

(2) Llegado a este punto, si no has comentado las unidades en el /etc/fstab cuando hemos eliminado los LVs, ahora la máquina no te va a arrancar. No te preocupes, el problema es que no encuentra las unidades para montarlas; podemos solucionarlo, aunque es un poco lento.

Para solucionarlo arranca con un LiveCD (Knoppix, por ejemplo) y vamos a comentar esas unidades en el /etc/fstab. Una vez arranque, hay que activar el soporte de LVM en Knoppix, así que abre una consola y ejecuta:

> sudo su -
> vgscan --mknodes
> vgchange -ay
> lvscan
> mount /dev/vgsys/lv_root /mnt/
> vi /mnt/etc/fstab

y comenta ahora las unidades. Guarda al salir y reinicia, ya deberías poder entrar en el SO.

(3) Si al crear una nueva partición para vgdata no pueda, prueba a arrancar con una distro Gparted y crea la partición sin problemas.

Y vosotros, ¿estáis de acuerdo?

¿Vosotros estáis de acuerdo?

¿Qué distro(s) utilizáis normalmente? ¿Sabíais que existe una distro basada en Hanna Montana? Sí... aquí está el enlace. Ya me contaréis si lo intentáis...

AWS - Actualizar un certificado SSL externo

Hoy os voy a explicar cómo lo hago yo para actualizar un certificado SSL en AWS, un certificado que se ha comprado fuera. Lo vamos a hacer en tres pasos, que son

1. Codificar los certificados (pasar a .pem) 
2. Subirlos a AWS 
3. Cambiar el viejo por el nuevo

1) Para codificar el certificado nuevo vamos a necesitar

domain.crt (el certificado que nos habrá enviado el proveedor)
domain.key
root.crt (es el Certificado Intermedio del tipo de SSL que hemos tramitado, que nos debería dar también el proveedor, sino mejor se lo pedimos). 

Para hacer la conversión y encriptar los archivos lo hacemos así (desde cualquier linux que tenga el paquete openssl instalado)

> rsa -in domain.key -outform PEM -out domain.key.pem
> x509 -inform PEM -in domain.crt -out domain.crt.pem
> x509 -inform PEM -in root.crt -out root.crt.pem

 
Ya los tienes codificados. Vamos a subirlos.

2)    Subirlos no es complicado, sólo necesitas un usuario IAM con permisos para subirlos. Aquí tienes la documentación de todas las políticas en ACM que necesitas para definir los permisos de tu usuario.

La subida la puedes hacer desde la consola de AWS o desde línea de comandos (habiendo instalado las AWS tools previamente). Desde el directorio donde tienes los certificados codificados, el comando sería este

> aws iam upload-server-certificate --server-certificate-name Nombre_del_Certificado --certificate-body file:/domain.crt.pem --private-key file:/domain.key.pem --certificate-chain file:/domain_2016_ca.crt.pem

 
Cuando este paso se hace bien, el sistema devuelve algo así:

{
    "ServerCertificateMetadata": {
        "ServerCertificateId": "ASCAJKNEFTXTK7XXXXXXX",
        "ServerCertificateName": "domain",
        "Expiration": "2019-07-21T23:59:59Z",
        "Path": "/",
        "Arn": "arn:aws:iam::xxxxxxxx:server-certificate/domain",
        "UploadDate": "2018-01-26T11:16:35.819Z"
    }
}

 

Sencillo, ¿no? El problema es cuando el usuario de AWS no tiene permisos, que hay que dárselos. El error es más del tipo:

A client error (AccessDenied) occurred when calling the UploadServerCertificate operation: User: arn:aws:iam::xxxxxxxx:user/USER is not authorized to perform: iam:UploadServerCertificate on resource: arn:aws:iam::xxxxxxxx:server-certificate/domain

 

En este caso, falta algún permisos; prueba a darle a tu usuario permisos IAMFullAccess y a quitárselos después de importar el certificado.

3)    Cambiar el nuevo certificado : Desde el panel de AWS, entra en EC2 y en el panel de la izquierda busca Load Balancing y justo debajo, Load Balancer. Busca el balanceador al que está asociado el certificado que vamos a actualizar, selecciónalo y vete a la pestaña "Listeners". Selecciona el HTTPS y edítalo. En el campo

Default SSL certificate

escoge el certificado que acabas de subir y guarda. Ya lo has cambiado.

Cómo volcar una BD SQL Server desde el RDS de AWS a un entorno on-premise (II)

Hola a todos!
En un primer post os estuve explicando cómo podéis hacer un export de una BD SQL Server en el RDS de AWS.

En este punto tenemos el backup del SQL en S3; para descargarlo necesitamos acceder a S3 y hacer que el archivo esté disponible desde internet. Para hacerlo, accede al panel de AWS y ve a S3; dentro del bucket tenemos el backup, con el mismo nombre que le has dado al hacer el export. Entra en este archivo y en la pestaña Overview hay un botón para hacerlo público:

También tienes el link externo del archivo. Cópialo y vamos al servidor donde vamos a importar esa base de datos

Recuerda borrar lo que vaya quedando en el bucket para que no se generen gastos no necesarios

Ahora tenemos que descargar e importar la base de datos en el entorno de on-premise. Vamos por partes:

1. Conéctate al servidor desde el que vas a lanzar la restauración, para descargar el backup en local.

2. Descarga el .BAK que hemos generado desde S3. Si ves que no te funciona el enlace por algún motivo, piensa que puedes entrar desde el servidor a la consola de AWS y descargarlo directamente. Ten localizada la descarga; yo la suelo mover a la raiz del disco en el que esté para tenerla controlada.

3. Abre el MS SQL y conecta al motor del SQL

4.Vamos a eliminar la BD. Recuerda avisar a quien sea necesario. Para eliminarla, ponla en modo offline primero para confirmar que no hay ninguna conexión abierta y de errores. Si lo haces con una query será algo así

ALTER DATABASE [database_name] SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Los corchetes “[“ y “]” no los quites, son parte de la query. Una vez la BD esté offline, podrás eliminarla sin problema.

5. Ahora ya podemos restaurar la BD. Lo vamos a hacer con esta otra query; modifica los campos que sean necesarios

RESTORE DATABASE [database_name] FROM DISK = 'c:\AAAAMMDD_backup.bak'
WITH MOVE 'database_mdf_name' TO 'C:\Program Files\Microsoft SQL
Server\MSSQL11.DEVW2012\MSSQL\DATA
\database_mdf_name.mdf',
MOVE 'database_log_name' TO 'C:\Program Files\Microsoft SQL
Server\MSSQL11.DEVW2012\MSSQL\DATA
\database_mdf_name.ldf
RECOVERY, REPLACE, STATS = 10;

6. Una vez acabe (puede tardar unos 5 o 10 minutos, dependiendo del tamaño), hay que habilitar el acceso a esta base de datos nueva. En Seguridad → Inicios de Sesion, busca el usuario que se utilizaba antes y vete a propiedades

Cuando se abra la ventana de propiedades, vete a Asignación de usuarios en el menú arriba a la izquierda

y selecciona la nueva base de datos en “Usuarios asignados a este inicio de sesión":

Una vez estén asignados, acepta y el backup estará restaurado del todo.

Cómo volcar una BD SQL Server desde el RDS de AWS a un entorno on-premise (I)

Hola! Hoy os traigo un tutorial algo más elaborado, y el primero (creo) en el que trabajo con AWS. Espero que no sea el único!

Para exportar una BD SQL Server desde AWS a un entorno on-premise, vamos a hacer un export a S3 y desde allí lo descargamos e importamos desde el entorno on premise.

En esta primera parte del tutorial vamos a hacer el export, y en una segunda parte, la importación en destino

Lo que primero vamos a necesitas será un usuario con permisos suficientes para poder exportar el backup y volcarlo en un bucket de S3; después necesitas tener ese bucket. Y por último, tener la opción SQLSERVER_BACKUP_RESTORE añadida a un grupo de opciones en tu instancia RDS.

Si ya tienes un usuario IAM puedes crear y asignarle la política específica para hacer exports/restores RDS o puedes crear un rol y asignarlo. En cualquier caso, la política que tienes que crear debería ser una de las tres definidas aquí.

Para hacer el export del SQLServer nos conectamos a la consola y ejecutamos este comando

exec msdb.dbo.rds_backup_database 
        @source_db_name='database_name',
        @s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name_and_extension',
        @kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id',
        @overwrite_S3_backup_file=1,
        @type='differential/FULL';

donde

• @source_db_name hace referencia a la BD que vas a exportar
• @s3_arn_to_backup_to hace referncia al bucket donde vas a exportar y al nombre del fichero con que se va a guardar
• @kms_master_key_arn hace referencia a la encriptación del fichero, y es OPCIONAL
• @overwrite_S3_backup_file hace referencia a si quieres sobreescribir el fichero en caso de que exista; 1 equivale a Sí y 0 a No. Es OPCIONAL, y por defecto es "1"
• @type hace referencia al tipo de backup, si es diferencial o completo. Esta opción también es OPCIONAL y por defecto equivale a FULL. Para el backup diferencial se toma como punto de referencia el último backup FULL que se ha hecho. Se puede consultar cuándo se ha hecho con esta query:
  

select top 1 
database_name
,  backup_start_date
,  backup_finish_date 
from    msdb.dbo.backupset 
where   database_name='database_name'
and     type = 'D' 
order by backup_start_date desc;

Este export no es instantáneo y va a depender sobre todo del tamaño de la BD; para ver su evolución, lo hacemos con esta query:

exec msdb.dbo.rds_task_status @db_name='database_name';

 
Si quisiéramos restaurar la base de datos, la query sería

exec msdb.dbo.rds_restore_database
@restore_db_name=’database_name';
@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name_and_extension';

Bien, y hasta aquí la parte de AWS; en el siguiente post os explico cómo lo hago yo para importar el export en un SQL Server.



Gracias!

Error común: "Too many open files", en Tomcat o PHP

Si Tomcat os devuelve un error HTTP 500 y en el 'catalina.out' encontráis algo de este tipo

[] org.apache.tomcat.util.net.JIoEndpoint$Acceptor run SEVERE: Socket accept failed
java.net.SocketException: Too many open files

es que tenéis un problema de ficheros abiertos; con

> ulimit -a

puedes ver tu configuración actual; repasa la variable "open files" que te da cuántos ficheros abiertos puede haber por proceso. Puedes modificarla con

> ulimit -n #

donde # es el nuevo valor; prueba con 4096 y reinicia el tomcat para que coja el cambio de esta variable de sistema

Para controlar cuántos ficheros tiene un proceso abierto, lo puedes hacer con  

> lsof -l | grep tomcat

Este tipo de fallo es aplicable a cualquier otra aplicación, no sólo a tomcat; también PHP requiere abrir muchos ficheros y puede  arrojar un error similar. Tenlo en cuenta cuando una aplicación se pare de repente después de rato funcionando bien.

Gracias!

Backup disk

Este es un backup realmente seguro. A prueba de errores