AWS cli: subir archivos a S3

Escrito por Blai el 27.10.21

Cómo subir y sincronizar archivos a un bucket S3 mediante el cli de AWS en Linux.



Veamos cómo subir y sincronizar ficheros a un bucket S3 de AWS.

En este ejemplo, el bucket se llama "blai-1".

Imaginemos que tenemos 3 archivos en local:

[ec2-user@ip-10-5-0-143 ~]$ 2021-10-27 10:56:21 30318 file1.txt 2021-10-27 10:56:22 43784 file2.txt 2021-10-27 10:56:22 96675 file3.txt

Subimos los 3 ficheros al bucket usando "sync files":

[ec2-user@ip-10-5-0-143 ~]$ aws s3 sync files s3://s3-blai-1/files/ upload: files/file1.txt to s3://s3-blai-1/files/file1.txt upload: files/file2.txt to s3://s3-blai-1/files/file2.txt upload: files/file3.txt to s3://s3-blai-1/files/file3.txt

Listamos los ficheros presentes en el bucket:

[ec2-user@ip-10-5-0-143 ~]$ aws s3 ls s3://s3-blai-1/files/ 2021-10-27 10:56:31 30318 file1.txt 2021-10-27 10:56:32 43784 file2.txt 2021-10-27 10:56:32 96675 file3.txt

Borramos file1.txt en local:

[ec2-user@ip-10-5-0-143 ~]$ sudo rm files/file1.txt sudo rm files/file1.txt

Hacemos otro sync de archivos, esta vez con el flag delete.

El flag "delete" indica que se borre del bucket aquello que no exista en local:

[ec2-user@ip-10-5-0-143 ~]$ aws s3 sync files s3://s3-blai-1/files/ --delete delete: s3://s3-blai-1/files/file1.txt

Tras la instrucción anterior, listamos los ficheros presentes en el bucket:

[ec2-user@ip-10-5-0-143 ~]$ aws s3 ls s3://s3-blai-1/files/ 2021-10-27 10:56:32 43784 file2.txt 2021-10-27 10:56:32 96675 file3.txt

Observamos que file1.txt ya no existe.

Leer más »

SAP: disco al 100%, lleno de logs

Escrito por Blai el 20.10.21

Cómo liberar espacio ocupado al 100% por logs en SAP.



Si un sistema SAP tiene el disco al 100% de ocupación es muy posible que este esté lleno de logs.

Se puede comprobar yendo a la carpeta "hdb00004" y observando centenares de ficheros de log.

Para reclamar este espacio, podemos hacer lo siguiente:

1. En global.ini, cambiar el parámetro log_mode a overwrite

2. Reiniciar BBDD y SAP

3. Cambiar log_mode a normal

4. Reiniciar el sistema de nuevo

5. En una ventana de SQL, ejecutar:

ALTER SYSTEM RECLAIM LOG

Tras ejecutar estos pasos, el espacio en disco debería haberse liberado.


Fuentes:

https://answers.sap.com/questions/337800/sap-business-one-hana---delete-log-files-in-mnt000.html

Leer más »

Balancear cache en varios discos usando NGINX

Escrito por Blai el 13.10.21

Cómo distribuir el contenido de la cache almacenada en varios discos distintos.



Hace unos días contaba cómo guardar contenido cacheado en un NGINX que actúa como reverse proxy. Hoy contaré una característica adicional a la configuración presentada anteriormente.

Imaginemos que estamos cacheando contenido en el reverse proxy no tanto para aumentar la velocidad de carga de una web sino para poder presentar ciertas imágenes en caso de que los servidores que las almacenan caigan y dejen de servirlas para asegurar así su disponibilidad.

Si tenemos varios discos duros mapeados a la máquina donde está instalado NGINX, podemos usar NGINX para dividir el caché almacenado entre ellos, añadiendo una capa extra a alta disponibilidad.

A continuación, un ejemplo que muestra como dividir a los clientes de manera uniforme en dos discos duros distintos según el URI de la solicitud enviada por el cliente:

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g inactive=60m use_temp_path=off; proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g inactive=60m use_temp_path=off; split_clients $request_uri $my_cache { 50% “my_cache_hdd1”; 50% “my_cache_hdd2”; } server { # ... location / { proxy_cache $my_cache; proxy_pass http://my_upstream; } }

Las dos directivas proxy_cache_path definen dos cachés (my_cache_hdd1 y my_cache_hdd2) en dos discos duros diferentes (hdd1 y hdd2), para asegurar la alta disponibilidad.

El bloque de configuración split_clients especifica que los resultados de la mitad de las solicitudes (50 %) se almacenan en caché en my_cache_hdd1 y la otra mitad en my_cache_hdd2. El hash basado en la variable $request_uri (el URI de la solicitud) determina qué caché se usa para cada solicitud, lo que da como resultado que las solicitudes de un URI determinado siempre se almacenan en el mismo caché.

Mencionar que este enfoque no reemplaza la configuración de un RAID. Si hay una falla en uno de los discos, podría darse un comportamiento impredecible en el sistema, como mostrarse errores 500 a las solicitudes que se dirigieron al disco duro defectuoso.


Fuentes:

https://www.nginx.com/blog/nginx-caching-guide/

Leer más »

Forzar reboot en Linux

Escrito por Blai el 6.10.21

Cómo ampliar o extender un volumen LVM en Linux.



Queremos reiniciar una máquina Linux, y al ejecutar el comando "reboot" nos encontramos con el siguiente mensaje de error en pantalla:

HOST # reboot Failed to open initctl fifo: No such device or address Failed to talk to init daemon.

Independientemente de cuál sea el problema y del estado en el que se encuentre la máquina, la utilidad systemctl permite forzar el reinicio de un Linux "pase lo que pase" de la siguiente manera:

HOST # systemctl --force --force reboot Rebooting.

Ahora sí, la máquina ya debería estar reiniciándose.

Leer más »