Uno de los trabajos que hemos realizado esta semana ha sido la puesta en marcha de una replicación nativa activo-pasivo de MySQL de uno de los servidores que contiene las bases de datos de las herramientas que usamos en el día a día. En este caso, nos gustaría compartir uno de los métodos que solemos utilizar para ello teniendo en cuenta que no hay parada de servicio.
La automatización de tareas es una parte esencial de la administración de sistemas y la gestión de infraestructuras, ¿qué duda cabe? Sus ventajas están más que demostradas, tanto para la calidad de vida de las personas como para la optimización de procesos empresariales, sobre todo en empresas que desarrollan la cultura devops en sus equipos.
Pero no siempre es así. Automatizar sistemas tiene un coste en esfuerzo, a veces elevado, que debe ser recompensado en ahorro y optimización del tiempo global empleado en la implantación y mantenimiento de forma recurrente de dichos sistemas. ¿Cuántas veces nos hemos encontrado con automatizaciones anidadas de tareas, que provisionan y configuran sistemas que han ralentizado tanto su ejecución, que se llega a cuestionar su utilidad y la vuelta a la implantación manual por los equipos de sysadmin?
La seguridad informática es un pilar fundamental para los administradores de sistemas y para las empresas que quieren mantener a salvo sus datos. Tener bien securizados nuestros servidores y sistemas es esencial para garantizar esta seguridad ante posibles intrusiones, pero igual de importante es tener controlado qué hacen los usuarios dentro de estos servidores, sin importar que sean usuarios autorizados.
A menudo el performance de PostgreSQL se degrada con el tiempo cuando existe un alto volumen de lectura/escritura, lo que acaba provocando lentitud. Esto en muchas ocasiones es debido a que se produce el efecto conocido como “bloat”. No obstante, una correcta configuración y mantenimiento de PostgreSQL puede evitar estas situaciones y mantener nuestra base de datos con un rendimiento óptimo.
Al igual que muchos otros sistemas de base de datos, PostgreSQL está diseñado para permitir consultas de solo lectura de forma concurrente mientras se realizan actualizaciones de los datos. Esto es posible gracias alMulti-Version Concurrency Control (MVCC), un sistema que permite lecturas continuas generando múltiples snapshots de las transacciones y consolidándose finalmente. De esta manera se produce un mayor uso de disco para almacenar dichos snapshots, conociéndose como bloat.
En nuestro día a día, donde la tecnología y los sistemas informáticos desempeñan un papel fundamental en la operación empresarial, es esencial contar con herramientas de monitorización y observabilidad robustas que nos permitan garantizar la eficiencia y la disponibilidad de nuestros sistemas críticos. En esta ocasión, nos sumergimos en el mundo de la gestión de la monitorización, donde el Percona Monitoring y Management (PMM) ha emergido como una solución valiosa.
Esta semana hemos explorado un problema que ha capturado nuestra atención durante las últimas actualizaciones de PMM, llevándonos a descubrir un obstáculo que merece un análisis. A través de este artículo, os hablamos sobre los desafíos encontrados al realizar actualizaciones de PMM y otros problemas detectados.
Una de las herramientas con las que trabajamos diariamente es Terraform, pero ¿qué es?
Terraform es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp, siendo su objetivo principal permitirnos automatizar y gestionar la infraestructura de nuestros clientes de manera eficiente.
Una de las principales preguntas que hay que plantearse antes de comenzar a trabajar con Terraform es la organización del código, ya que lo normal en las arquitecturas es tener varios entornos: producción, preproducción, desarrollo o los que en cada caso existan.
Pues bien, para tener el código organizadopor cada entorno pueden existir infinitas formas de plantearlo, pero hoy nos centraremos en dos:
El pasado 10 de junio se publicó Debian 12, que viene bajo el nombre de “Bookworm”. Esta versión del popular sistema operativo tendrá soporte hasta 2028, y tras su salida, Debian 11 “Bullseye” ha pasado a ser oldstable aunque su soporte se mantiene hasta 2026. Mientras, Debian 10 “Stretch” pasa a ser oldoldstable y ya no recibe actualizaciones de seguridad, aunque aún tiene soporte LTS hasta el año que viene.
En este artículo vamos a comentar algunos de los cambios que más nos han llamado la atención y que creemos que se deben tener en cuenta para aquellos que vayan a actualizar a esta nueva versión. Os incluimos una guía de cómo realizar dicha actualización
En entornos de Kubernetes, los volúmenes persistentes desempeñan un papel crucial en el almacenamiento de datos de aplicaciones. Tener un entorno dinámico donde los recursos se crean y se destruyen de forma automática, es tan útil como peligroso si nuestros datos persistentes están entre estos recursos del cluster.
Uno de los almacenamientos más utilizados en entornos AWS es Amazon Elastic Block Store (EBS). En entornos de Kubernetes, gracias al controlador de almacenamiento externo EBS-CSI (EBS Container Storage Interface), tenemos la opción de utilizar volúmenes persistentes de EBS de manera eficiente y segura. La base radica en la capacidad de crear snapshots de volúmenes asociados a recursos de Kubernetes para manejarlos con facilidad.
¡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í.