Mucha gente está familiarizada con el DBMS PostgreSQL y ha demostrado su eficacia en instalaciones pequeñas. Sin embargo, la tendencia hacia el código abierto se ha vuelto cada vez más clara, incluso cuando se trata de grandes empresas y requisitos empresariales. En este artículo le diremos cómo integrar Postgres en un entorno corporativo y compartiremos nuestra experiencia en la creación de un sistema de respaldo (BSS) para esta base de datos usando el sistema de respaldo Commvault como ejemplo.
PostgreSQL ya ha demostrado su valía: el DBMS funciona muy bien, lo utilizan empresas digitales de moda como Alibaba y TripAdvisor, y la falta de tarifas de licencia lo convierte en una alternativa tentadora a monstruos como MS SQL u Oracle DB. Pero tan pronto como empezamos a pensar en PostgreSQL en el panorama empresarial, inmediatamente nos topamos con requisitos estrictos: “¿Qué pasa con la tolerancia a fallas de configuración? ¿Resistencia a desastres? ¿Dónde está el seguimiento integral? ¿Qué pasa con las copias de seguridad automáticas? ¿Qué pasa con el uso de bibliotecas de cintas tanto directamente como en almacenamiento secundario?
Por un lado, PostgreSQL no tiene herramientas de respaldo integradas, como DBMS "para adultos" como RMAN en Oracle DB o SAP Database Backup. Por otro lado, los proveedores de sistemas de respaldo corporativos (Veeam, Veritas, Commvault), aunque admiten PostgreSQL, en realidad solo funcionan con una determinada configuración (generalmente independiente) y con un conjunto de diversas restricciones.
Los sistemas de respaldo especialmente diseñados para PostgreSQL, como Barman, Wal-g, pg_probackup, son extremadamente populares en instalaciones pequeñas de DBMS PostgreSQL o donde no se necesitan respaldos pesados de otros elementos del panorama de TI. Por ejemplo, además de PostgreSQL, la infraestructura puede incluir servidores físicos y virtuales, OpenShift, Oracle, MariaDB, Cassandra, etc. Es recomendable realizar una copia de seguridad de todo esto con una herramienta común. Instalar una solución separada exclusivamente para PostgreSQL es una mala idea: los datos se copiarán en algún lugar del disco y luego será necesario eliminarlos en la cinta. Esta doble copia de seguridad aumenta el tiempo de copia de seguridad y también, lo que es más importante, el tiempo de recuperación.
En una solución empresarial, la copia de seguridad de la instalación se realiza con una determinada cantidad de nodos en un clúster dedicado. Al mismo tiempo, por ejemplo, Commvault solo puede funcionar con un clúster de dos nodos, en el que el primario y el secundario están estrictamente asignados a ciertos nodos. Y sólo tiene sentido hacer una copia de seguridad desde la Primaria, porque la copia de seguridad desde la Secundaria tiene sus limitaciones. Debido a las peculiaridades del DBMS, no se crea un volcado en Secundario y, por lo tanto, solo queda la posibilidad de realizar una copia de seguridad del archivo.
Para reducir el riesgo de tiempo de inactividad, al crear un sistema tolerante a fallas, se crea una configuración de clúster "en vivo" y el primario puede migrar gradualmente entre diferentes servidores. Por ejemplo, el propio software Patroni inicia Primario en un nodo del clúster seleccionado al azar. El IBS no tiene forma de realizar un seguimiento de esto de forma inmediata y, si la configuración cambia, los procesos se interrumpen. Es decir, la introducción de control externo impide que el ISR funcione de manera efectiva, porque el servidor de control simplemente no comprende dónde ni desde qué datos se deben copiar.
Otro problema es la implementación de copias de seguridad en Postgres. Es posible mediante volcado y funciona en bases de datos pequeñas. Pero en bases de datos grandes, el volcado lleva mucho tiempo, requiere muchos recursos y puede provocar el fallo de la instancia de la base de datos.
La copia de seguridad de archivos corrige la situación, pero en bases de datos grandes es lenta porque funciona en modo de subproceso único. Además, los proveedores tienen una serie de restricciones adicionales. O no puede utilizar copias de seguridad de archivos y volcados al mismo tiempo, o no se admite la deduplicación. Hay muchos problemas y, en la mayoría de los casos, es más fácil elegir un DBMS costoso pero probado en lugar de Postgres.
¡No hay ningún lugar al que retirarse! ¡Los desarrolladores de Moscú están detrás!
Sin embargo, recientemente nuestro equipo enfrentó un desafío difícil: en el proyecto para crear AIS OSAGO 2.0, donde creamos la infraestructura de TI, los desarrolladores eligieron PostgreSQL para el nuevo sistema.
Es mucho más fácil para los grandes desarrolladores de software utilizar soluciones de código abierto “de moda”. Facebook cuenta con suficientes especialistas para respaldar el funcionamiento de este DBMS. Y en el caso de RSA, todas las tareas del “segundo día” recayeron sobre nuestros hombros. Se nos pidió garantizar la tolerancia a fallos, montar un clúster y, por supuesto, configurar una copia de seguridad. La lógica de acción fue la siguiente:
- Enseñe al SRK a realizar copias de seguridad desde el nodo principal del clúster. Para hacer esto, SRK debe encontrarlo, lo que significa que es necesaria la integración con una u otra solución de administración de clústeres PostgreSQL. En el caso de RSA se utilizó el software Patroni para ello.
- Decida el tipo de copia de seguridad según el volumen de datos y los requisitos de recuperación. Por ejemplo, cuando necesite restaurar páginas de forma granular, utilice un volcado y, si las bases de datos son grandes y no se requiere una restauración granular, trabaje a nivel de archivo.
- Adjunte la posibilidad de realizar una copia de seguridad en bloque a la solución para crear una copia de seguridad en modo multiproceso.
Al mismo tiempo, inicialmente nos propusimos crear un sistema eficaz y simple sin un monstruoso conjunto de componentes adicionales. Cuantas menos muletas, menor será la carga de trabajo del personal y menor será el riesgo de fallo del SII. Inmediatamente excluimos los enfoques que utilizaban Veeam y RMAN, porque un conjunto de dos soluciones ya insinúa la falta de confiabilidad del sistema.
Un poco de magia para la empresa
Por lo tanto, necesitábamos garantizar un respaldo confiable para 10 clústeres de 3 nodos cada uno, con la misma infraestructura reflejada en el centro de datos de respaldo. Los centros de datos en términos de PostgreSQL funcionan según el principio activo-pasivo. El tamaño total de la base de datos fue de 50 TB. Cualquier sistema de control a nivel corporativo puede hacer frente fácilmente a esto. Pero la advertencia es que inicialmente Postgres no tiene idea de la compatibilidad total y profunda con los sistemas de respaldo. Por lo tanto, tuvimos que buscar una solución que inicialmente tuviera la máxima funcionalidad junto con PostgreSQL y perfeccionar el sistema.
Celebramos 3 "hackathons" internos: analizamos más de cincuenta desarrollos, los probamos, hicimos cambios en relación con nuestras hipótesis y los probamos nuevamente. Después de revisar las opciones disponibles, elegimos Commvault. Desde el primer momento, este producto podía funcionar con la instalación de clúster PostgreSQL más simple, y su arquitectura abierta generó esperanzas (que estaban justificadas) de un desarrollo e integración exitosos. Commvault también puede realizar copias de seguridad de los registros de PostgreSQL. Por ejemplo, Veritas NetBackup en términos de PostgreSQL solo puede realizar copias de seguridad completas.
Más sobre arquitectura. Se instalaron servidores de administración de Commvault en cada uno de los dos centros de datos en una configuración CommServ HA. El sistema está duplicado, administrado a través de una consola y, desde el punto de vista de HA, cumple con todos los requisitos empresariales.
También lanzamos dos servidores de medios físicos en cada centro de datos, a los que conectamos matrices de discos y bibliotecas de cintas dedicadas específicamente para copias de seguridad a través de SAN mediante Fibre Channel. Las bases de datos de deduplicación extendidas garantizaron la tolerancia a fallas de los servidores de medios y la conexión de cada servidor a cada CSV permitió la operación continua si algún componente fallaba. La arquitectura del sistema permite que la copia de seguridad continúe incluso si uno de los centros de datos cae.
Patroni define un nodo primario para cada clúster. Puede ser cualquier nodo libre del centro de datos, pero sólo en su mayor parte. En la copia de seguridad, todos los nodos son secundarios.
Para que Commvault comprenda qué nodo del clúster es el principal, integramos el sistema (gracias a la arquitectura abierta de la solución) con Postgres. Para ello, se creó un script que informa la ubicación actual del nodo primario al servidor de administración de Commvault.
En general, el proceso se ve así:
Patroni selecciona Primario → Keepalived recoge el clúster de IP y ejecuta el script → el agente de Commvault en el nodo del clúster seleccionado recibe una notificación de que este es el primario → Commvault reconfigura automáticamente la copia de seguridad dentro del pseudocliente.
La ventaja de este enfoque es que la solución no afecta la coherencia, la corrección de los registros ni la recuperación de la instancia de Postgres. También es fácilmente escalable, porque ya no es necesario arreglar los nodos primario y secundario de Commvault. Basta con que el sistema comprenda dónde está el primario y que el número de nodos se pueda aumentar a casi cualquier valor.
La solución no pretende ser ideal y tiene sus propios matices. Commvault solo puede realizar copias de seguridad de la instancia completa y no de bases de datos individuales. Por lo tanto, se creó una instancia separada para cada base de datos. Los clientes reales se combinan en pseudoclientes virtuales. Cada pseudocliente de Commvault es un clúster UNIX. Se le agregan aquellos nodos del clúster en los que está instalado el agente Commvault para Postgres. Como resultado, se realiza una copia de seguridad de todos los nodos virtuales del pseudocliente como una sola instancia.
Dentro de cada pseudocliente se indica el nodo activo del cluster. Esto es lo que define nuestra solución de integración para Commvault. El principio de su funcionamiento es bastante simple: si se genera una IP de clúster en un nodo, el script establece el parámetro "nodo activo" en el binario del agente Commvault; de hecho, el script establece "1" en la parte requerida de la memoria. . El agente transmite estos datos a CommServe y Commvault realiza una copia de seguridad desde el nodo deseado. Además, la corrección de la configuración se verifica a nivel de script, lo que ayuda a evitar errores al iniciar una copia de seguridad.
Al mismo tiempo, las bases de datos de gran tamaño se respaldan en bloques a través de múltiples subprocesos, cumpliendo con los requisitos de RPO y ventana de respaldo. La carga en el sistema es insignificante: las copias completas no se producen con tanta frecuencia, otros días solo se recopilan registros y durante los períodos de baja carga.
Por cierto, hemos aplicado políticas separadas para realizar copias de seguridad de los registros de archivo de PostgreSQL: se almacenan de acuerdo con diferentes reglas, se copian de acuerdo con un cronograma diferente y la deduplicación no está habilitada para ellos, ya que estos registros contienen datos únicos.
Para garantizar la coherencia en toda la infraestructura de TI, se instalan clientes de archivos Commvault independientes en cada uno de los nodos del clúster. Excluyen los archivos de Postgres de las copias de seguridad y están destinados únicamente a copias de seguridad del sistema operativo y de las aplicaciones. Esta parte de los datos también tiene su propia política y plazo de conservación.
Actualmente, IBS no afecta los servicios de productividad, pero si la situación cambia, Commvault puede habilitar la limitación de carga.
¿Esta bien? ¡Bien!
Por lo tanto, hemos recibido no solo una copia de seguridad viable, sino también completamente automatizada para una instalación de clúster PostgreSQL, y cumple con todos los requisitos para llamadas empresariales.
Los parámetros RPO y RTO de 1 hora y 2 horas están cubiertos con un margen, lo que significa que el sistema los cumplirá incluso con un aumento significativo en el volumen de datos almacenados. Contrariamente a muchas dudas, PostgreSQL y el entorno empresarial resultaron ser bastante compatibles. Y ahora sabemos por experiencia propia que la copia de seguridad de dichos DBMS es posible en una amplia variedad de configuraciones.
Por supuesto, en este camino tuvimos que desgastar siete pares de botas de hierro, superar numerosas dificultades, pisar varios rastrillos y corregir numerosos errores. Pero ahora el enfoque ya ha sido probado y puede usarse para implementar código abierto en lugar de DBMS propietarios en condiciones empresariales difíciles.
¿Has intentado trabajar con PostgreSQL en un entorno corporativo?
Autores:
Oleg Lavrenov, ingeniero de diseño de sistemas de almacenamiento de datos, Jet Infosystems
Dmitry Erykin, ingeniero de diseño de sistemas informáticos de Jet Infosystems
Fuente: habr.com