Una de las cosas que realizamos en STR con mucha frecuencia es la migración de sistemas, ya sea entre distintos proveedores o dentro de un mismo proveedor por cambio de versión, servicio o cualquier otra razón.
Recientemente se nos ha presentado un reto con el siguiente contexto:
Comoadministradores de infraestructura cloud, una tarea que muchos de nosotros hemos tenido que realizar (y seguiremos realizando), es adaptarnos a los requisitos de nuestros clientes respecto a las necesidades de almacenamiento que se establecen y que evolucionan/cambian en el tiempo.
A la hora de realizar estas operaciones (añadir nuevos discos o redimensionar discos existentes) en una instancia, la mejor de las situaciones que podemos encontrar es que sin más acciones, la instancia virtualizada detecte dichos cambios de discos, ya sea un nuevo disco o el cambio de tamaño de uno ya existente.
No obstante, en nuestro día a día hemos topado con sistemas de virtualización y/o sistemas operativos que no han detectado automáticamente estos cambios en discos.
Si has llegado aquí es porque te interesan los backups de PostgreSQL ¡Normal!
Se trata de la base de datos que más interés genera a los desarrolladores según la última encuesta anual de StackOverflow. Para tal fin, dentro del conjunto de herramientas existentes, contamos con las herramientas nativas pg_dump y pg_restore.
Éstas facilitan la exportación de datos y su posterior importación, por ello, se utilizan en tareas de copia de seguridad y migraciones.
Es importante tener en mente cuando hablamos de backups que, dando por supuesto la fiabilidad de los mismos, hay dos variables importantes a tener en cuenta siempre.
Un punto importante de los sistemas en producción es el uso de los discos y su ocupación. Como no siempre trabajamos en arquitecturas desplegadas en proveedores que permiten modificar los discos en caliente, nosotros optamos por usar LVM para gestionar los puntos de montaje que requieren estar siempre montados, minimizando así pérdidas de servicio en operaciones sobre los mismos.
La forma más fácil y cómoda en estos casos es asignar un disco extra sobre la máquina y añadirlo al LVM para ampliar su capacidad. Pero esto, con el paso del tiempo ocasiona tener una gran cantidad de discos de diferentes tamaños e incluso de diferente rendimientos que puede afectar al performance de nuestro servicio o trabajos que requieran el uso de estos dispositivos de almacenamiento.
Ahora mismo estamos en medio del proceso de búsqueda de un/a nuevo/a sysadmin para el equipo técnico y como estos procesos son bidireccionales, recibimos bastantes preguntas por parte de algunas de las personas que aplican al puesto.
Esta semana nos han preguntado nuevamente sobre cómo organizamos el trabajo del equipo técnico en STR Sistemas y me ha parecido interesante compartirlo de manera pública, tal y como haríamos en las conversaciones de pasillo de algún evento, o en una sesión del SOSZ, mi evento favorito.
Compartimos en nuestro blog la charla "Un caso real de Disaster Recovery" que nuestro compañero @txetxuvel preparó para Commit Conf 2018.
En esta charla compartimos el proceso de diseño e implantación que llevamos a cabo en STR Sistemas para el plan de Disaster Recovey de la empresa de giros Monty Global Payments, en adelante Mionty, presente por ejemplo en locutorios, y casas de cambio de moneda de diferentes países europeos así como a través de su marca online Clicktransfer que está en proceso de lanzamiento.
¡Usamos cookies propias y de terceros para mejorar tu experiencia en esta web! Si sigues navegando, consientes y aceptas estas cookies en tu ordenador, móvil o tablet.
Más información sobre las cookies y cómo cambiar su configuración en tu navegador aquí.