A finales del año pasado tuvo lugar otra transmisión en vivo de la comunidad rusa de PostgreSQL. , durante el cual su cofundador Nikolai Samokhvalov habló con el director técnico de Flant, Dmitry Stolyarov, sobre este DBMS en el contexto de Kubernetes.
Estamos publicando una transcripción de la parte principal de esta discusión, y en Vídeo completo publicado:
Bases de datos y Kubernetes
NA: Hoy no hablaremos de VACÍO ni de PUNTOS DE CONTROL. Queremos hablar de Kubernetes. Sé que tienes muchos años de experiencia. Vi tus videos e incluso volví a ver algunos de ellos... Vayamos directo al punto: ¿por qué Postgres o MySQL en K8?
DS: No hay ni puede haber una respuesta definitiva a esta pregunta. Pero en general, esto es simplicidad y conveniencia... potencial. Todo el mundo quiere servicios gestionados.
NA: ¿Cómo? , ¿solo en casa?
DS: Sí: como RDS, en cualquier lugar.
NA: “En cualquier lugar” es un buen punto. En las grandes empresas todo está ubicado en diferentes lugares. ¿Por qué entonces, si se trata de una gran empresa, no adoptar una solución ya preparada? Por ejemplo, Nutanix tiene sus propios desarrollos, otras empresas (VMware...) tienen el mismo “RDS, solo en casa”.
DS: Pero estamos hablando de una implementación separada que solo funcionará bajo ciertas condiciones. Y si hablamos de Kubernetes, entonces existe una gran variedad de infraestructura (que puede ser en K8). Básicamente, este es un estándar para API para la nube...
NA: ¡También es gratis!
DS: No es tan importante. La libertad es importante para un segmento no muy grande del mercado. Algo más es importante... Probablemente recuerdes el informe “"?
NA: Si
DS: Me di cuenta de que fue recibido de manera muy ambigua. Algunas personas pensaron que estaba diciendo: "¡Chicos, introduzcamos todas las bases de datos en Kubernetes!", mientras que otros decidieron que todas eran bicicletas terribles. Pero quería decir algo completamente diferente: “Mira lo que está pasando, qué problemas hay y cómo se pueden solucionar. ¿Deberíamos utilizar bases de datos de Kubernetes ahora? ¿Producción? Bueno, sólo si te gusta... hacer ciertas cosas. Pero para un desarrollador, puedo decir que lo recomiendo. Para un desarrollador, el dinamismo de crear/eliminar entornos es muy importante”.
NS: Por desarrollador, ¿te refieres a todos los entornos que no son producidos? Puesta en escena, control de calidad…
DS: Si hablamos de soportes de rendimiento, probablemente no, porque los requisitos allí son específicos. Si estamos hablando de casos especiales en los que se necesita una base de datos muy grande para la preparación, entonces probablemente no... Si se trata de un entorno estático y de larga duración, ¿cuál es el beneficio de tener la base de datos ubicada en K8?
NA: Ninguno. Pero ¿dónde vemos entornos estáticos? Un entorno estático quedará obsoleto mañana.
DS: La puesta en escena puede ser estática. Tenemos clientes...
NA: Sí, yo también tengo uno. Es un gran problema si tienes una base de datos de 10 TB y una prueba de 200 GB...
DS: ¡Tengo un caso genial! En la etapa de preparación hay una base de datos de productos en la que se realizan cambios. Y hay un botón: "lanzar a producción". Estos cambios (deltas) se agregan (parece que simplemente se sincronizan a través de la API) en producción. Esta es una opción muy exótica.
NA: He visto startups en el Valle que están en RDS o incluso en Heroku (estas son historias de hace 2 o 3 años) y descargan el volcado a su computadora portátil. Porque la base de datos todavía tiene solo 80 GB y hay espacio en la computadora portátil. Luego compran discos adicionales para todos para que tengan 3 bases de datos para realizar diferentes desarrollos. Así también sucede. También vi que no tienen miedo de copiar el estímulo en la puesta en escena; depende en gran medida de la empresa. Pero también vi que tienen mucho miedo y que muchas veces no tienen suficiente tiempo ni manos. Pero antes de pasar a este tema, quiero oír hablar de Kubernetes. ¿Entiendo correctamente que nadie está bajo demanda todavía?
DS: Disponemos de pequeñas bases de datos en prod. Estamos hablando de volúmenes de decenas de gigabytes y servicios no críticos para los que nos daba pereza hacer réplicas (y no existe tal necesidad). Y siempre que exista almacenamiento normal en Kubernetes. Esta base de datos funcionó en una máquina virtual, condicionalmente en VMware, encima del sistema de almacenamiento. Lo colocamos en y ahora podemos transferirlo de una máquina a otra.
NA: Las bases de datos de este tamaño, hasta 100 GB, se pueden implementar en unos minutos en buenos discos y una buena red, ¿verdad? Una velocidad de 1 GB por segundo ya no es exótica.
DS: Sí, para funcionamiento lineal esto no es un problema.
NA: Está bien, sólo tenemos que pensar en pinchar. Y si estamos considerando Kubernetes para entornos no productivos, ¿qué deberíamos hacer? Eso lo veo en Zalando. , en crujiente , hay algunas otras opciones. Y ahí está - este es nuestro buen amigo Álvaro de España: lo que hacen esencialmente no es solo , y toda la distribución (), en el que, además del propio Postgres, también decidieron meter una copia de seguridad, el proxy Envoy...
DS: ¿Enviado para qué? ¿Equilibrar el tráfico de Postgres específicamente?
NA: Sí. Es decir, lo ven así: si se toma una distribución y un kernel de Linux, entonces PostgreSQL normal es el kernel, y quieren crear una distribución que sea compatible con la nube y se ejecute en Kubernetes. Reúnen componentes (copias de seguridad, etc.) y los depuran para que funcionen bien.
DS: ¡Muy genial! Básicamente, este es un software para crear su propio Postgres administrado.
NA: Las distribuciones de Linux tienen problemas eternos: cómo hacer controladores para que todo el hardware sea compatible. Y tienen la idea de que trabajarán en Kubernetes. Sé que en el operador Zalando vimos hace poco una conexión con AWS y esto ya no es muy bueno. No debería haber ningún vínculo con una infraestructura específica. ¿Cuál es el punto entonces?
DS: No sé exactamente en qué situación se metió Zalando, pero en Kubernetes el almacenamiento ahora está hecho de tal manera que es imposible realizar una copia de seguridad del disco usando un método genérico. Recientemente en estándar - en la última versión — Hicimos posibles las instantáneas, pero ¿dónde se implementa? Honestamente, todo todavía está tan crudo... Estamos probando CSI sobre AWS, GCE, Azure, vSphere, pero tan pronto como comienzas a usarlo, puedes ver que aún no está listo.
NA: Por eso a veces tenemos que depender de la infraestructura. Creo que esto es todavía una etapa temprana: los dolores de crecimiento. Pregunta: ¿Qué consejo le daría a los novatos que quieran probar PgSQL en K8? ¿Qué operador tal vez?
DS: El problema es que Postgres es el 3% para nosotros. También tenemos una lista muy grande de software diferente en Kubernetes, ni siquiera enumeraré todo. Por ejemplo, Elasticsearch. Hay muchos operadores: algunos se están desarrollando activamente, otros no. Nos hemos fijado los requisitos, lo que debería haber en el operador para que nos lo tomemos en serio. En un operador específico para Kubernetes, no en un “operador para hacer algo en las condiciones de Amazon”... De hecho, utilizamos bastante (= casi todos los clientes) un solo operador: (pronto publicaremos un artículo sobre él).
NA: ¿Y tampoco para MySQL? Sé que Percona... como ahora están trabajando en MySQL, MongoDB y Postgres, tendrán que crear algún tipo de solución universal: para todas las bases de datos, para todos los proveedores de nube.
DS: No tuvimos tiempo de mirar los operadores de MySQL. Este no es nuestro enfoque principal en este momento. MySQL funciona bien en modo independiente. ¿Por qué utilizar un operador si simplemente puede iniciar una base de datos? Puede iniciar un contenedor Docker con Postrges, o puede iniciarlo de una manera sencilla.
NA: También hubo una pregunta sobre esto. ¿Ningún operador?
DS: Sí, el 100% de nosotros tenemos PostgreSQL ejecutándose sin operador. Hasta ahora así es. Utilizamos activamente el operador para Prometheus y Redis. Tenemos planes de encontrar un operador para Elasticsearch; es el que está más "en llamas", porque queremos instalarlo en Kubernetes en el 100% de los casos. Del mismo modo que queremos asegurarnos de que MongoDB también esté siempre instalado en Kubernetes. Aquí aparecen ciertos deseos, existe la sensación de que en estos casos se puede hacer algo. Y ni siquiera miramos a Postgres. Por supuesto, sabemos que existen diferentes opciones, pero en realidad tenemos una independiente.
Base de datos para pruebas en Kubernetes
NA: Pasemos al tema de las pruebas. Cómo implementar cambios en la base de datos, desde una perspectiva de DevOps. Hay microservicios, muchas bases de datos, algo cambia en algún lugar todo el tiempo. Cómo garantizar CI/CD normal para que todo esté en orden desde la perspectiva del DBMS. ¿Cuál es tu enfoque?
DS: No puede haber una respuesta. Hay varias opciones. El primero es el tamaño de la base que queremos desplegar. Usted mismo mencionó que las empresas tienen diferentes actitudes hacia tener una copia de la base de datos de producción en el desarrollo y en el escenario.
NA: Y bajo las condiciones del GDPR, creo que cada vez son más cuidadosos... Puedo decir que en Europa ya han comenzado a imponer multas.
DS: Pero a menudo se puede escribir software que tome un volcado de la producción y lo confunda. Se obtienen datos de producción (instantánea, volcado, copia binaria...), pero se anonimizan. En cambio, puede haber scripts de generación: pueden ser dispositivos o simplemente un script que genera una base de datos grande. El problema es: ¿cuánto tiempo lleva crear una imagen base? ¿Y cuánto tiempo lleva implementarlo en el entorno deseado?
Llegamos a un esquema: si el cliente tiene un conjunto de datos fijo (una versión mínima de la base de datos), los usamos de forma predeterminada. Si hablamos de entornos de revisión, cuando creamos una rama, implementamos una instancia de la aplicación; implementamos una pequeña base de datos allí. Pero resultó bien , cuando tomamos un volcado de producción una vez al día (por la noche) y construimos un contenedor Docker con PostgreSQL y MySQL con estos datos cargados en base a él. Si necesita ampliar la base de datos 50 veces a partir de esta imagen, esto se hace de forma bastante sencilla y rápida.
NA: ¿Por simple copia?
DS: Los datos se almacenan directamente en la imagen de Docker. Aquellos. Tenemos una imagen lista para usar, aunque sea de 100 GB. Gracias a las capas en Docker, podemos implementar rápidamente esta imagen tantas veces como necesitemos. El método es estúpido, pero funciona bien.
NA: Luego, cuando realizas la prueba, cambia directamente dentro de Docker, ¿verdad? Copiar en escritura dentro de Docker: deséchelo y vuelva a empezar, todo está bien. ¡Clase! ¿Y tú ya lo estás aprovechando al máximo?
DS: Por mucho tiempo.
NA: Hacemos cosas muy similares. Solo que no utilizamos la copia en escritura de Docker, sino alguna otra.
DS: No es genérico. Y Docker funciona en todas partes.
NA: En teoría, sí. Pero también tenemos módulos allí, puedes crear diferentes módulos y trabajar con diferentes sistemas de archivos. ¡Qué momento aquí! Desde el punto de vista de Postgres, vemos todo esto de manera diferente. Ahora miré desde el lado de Docker y vi que todo funciona para ti. Pero si la base de datos es enorme, por ejemplo 1 TB, entonces todo esto lleva mucho tiempo: operaciones nocturnas y meter todo en Docker... Y si se meten 5 TB en Docker... ¿O está todo bien?
DS: ¿Cuál es la diferencia? Son blobs, solo bits y bytes.
NA: La diferencia es esta: ¿lo haces mediante volcado y restauración?
DS: No es del todo necesario. Los métodos para generar esta imagen pueden ser diferentes.
NA: Para algunos clientes, hemos hecho que, en lugar de generar periódicamente una imagen base, la mantengamos actualizada constantemente. Es esencialmente una réplica, pero recibe datos no directamente del maestro, sino a través de un archivo. Un archivo binario donde se descargan WAL todos los días, donde se realizan copias de seguridad... Estos WAL luego llegan a la imagen base con un ligero retraso (literalmente 1-2 segundos). Lo clonamos de cualquier forma; ahora tenemos ZFS de forma predeterminada.
DS: Pero con ZFS estás limitado a un nodo.
NA: Sí. Pero ZFS también tiene una magia : con él puedes enviar una instantánea e incluso (todavía no lo he probado, pero...) puedes enviar un delta entre dos PGDATA. De hecho, tenemos otra herramienta que realmente no hemos considerado para este tipo de tareas. PostgreSQL tiene , que funciona como un rsync "inteligente", omitiendo mucho de lo que no tienes que ver, porque nada ha cambiado allí. Podemos hacer una sincronización rápida entre los dos servidores y rebobinar de la misma forma.
Entonces, desde este lado, más DBA, estamos tratando de crear una herramienta que nos permita hacer lo mismo que dijiste: tenemos una base de datos, pero queremos probar algo 50 veces, casi simultáneamente.
DS: 50 veces significa que necesita solicitar 50 instancias Spot.
NA: No, hacemos todo en una sola máquina.
DS: Pero, ¿cómo se expandirá 50 veces si esta base de datos es, digamos, de un terabyte? ¿Lo más probable es que necesite 256 GB de RAM condicionales?
NA: Sí, a veces necesitas mucha memoria, eso es normal. Pero este es un ejemplo de la vida. La máquina de producción tiene 96 núcleos y 600 GB. Al mismo tiempo, para la base de datos se utilizan 32 núcleos (a veces incluso 16 núcleos) y 100-120 GB de memoria.
DS: ¿Y ahí caben 50 copias?
NA: Entonces solo hay una copia, entonces la copia en escritura (ZFS) funciona... Te lo contaré con más detalle.
Por ejemplo, tenemos una base de datos de 10 TB. Le hicieron un disco, ZFS también comprimió su tamaño entre un 30 y un 40 por ciento. Como no realizamos pruebas de carga, el tiempo de respuesta exacto no es importante para nosotros: que sea hasta 2 veces más lento, está bien.
Damos la oportunidad a programadores, QA, DBA, etc. realice pruebas en 1-2 subprocesos. Por ejemplo, podrían realizar algún tipo de migración. No requiere 10 núcleos a la vez: necesita 1 backend de Postgres, 1 núcleo. La migración comenzará - tal vez aún se iniciará, entonces se utilizará el segundo núcleo. Tenemos entre 16 y 32 núcleos asignados, por lo que pueden trabajar 10 personas al mismo tiempo, no hay problema.
porque fisicamente PGDATA De todos modos, resulta que en realidad estamos engañando a Postgres. El truco es este: por ejemplo, se lanzan 10 Postgres simultáneamente. ¿Cuál es el problema normalmente? Pusieron , digamos 25%. En consecuencia, esto es 200 GB. No podrás ejecutar más de tres de estos porque se agotará la memoria.
Pero en algún momento nos dimos cuenta de que esto no era necesario: configuramos Shared_buffers en 2 GB. PostgreSQL tiene , y en realidad es el único que influye . Lo configuramos en 0,5 TB. Y ni siquiera importa que en realidad no existan: hace planes como si existieran.
En consecuencia, cuando probemos algún tipo de migración, podremos recopilar todos los planes; veremos cómo sucederá en producción. Los segundos serán diferentes (más lentos), pero los datos que realmente leemos y los planes en sí (qué JOIN hay, etc.) resultan exactamente iguales que en producción. Y puede ejecutar muchas de estas comprobaciones en paralelo en una máquina.
DS: ¿No crees que hay algunos problemas aquí? La primera es una solución que sólo funciona en PostgreSQL. Este enfoque es muy privado, no es genérico. La segunda es que Kubernetes (y todo lo que van a hacer las tecnologías de la nube ahora) involucra muchos nodos, y estos nodos son efímeros. Y en su caso es un nodo persistente y con estado. Estas cosas me ponen en conflicto.
NA: Primero, estoy de acuerdo, esta es una historia puramente de Postgres. Creo que si tenemos algún tipo de E/S directa y un grupo de búfer para casi toda la memoria, este enfoque no funcionará: los planes serán diferentes. Pero por ahora sólo trabajamos con Postgres, no pensamos en otros.
Acerca de Kubernetes. Usted mismo nos dice en todas partes que tenemos una base de datos persistente. Si la instancia falla, lo principal es guardar el disco. Aquí también tenemos toda la plataforma en Kubernetes, y el componente con Postgres está aparte (aunque algún día estará ahí). Por lo tanto, todo es así: la instancia cayó, pero guardamos su PV y simplemente la conectamos a otra (nueva) instancia, como si nada hubiera pasado.
DS: Desde mi punto de vista, creamos pods en Kubernetes. K8 - elástico: los nudos se ordenan según sea necesario. La tarea es simplemente crear un pod y decir que necesita X cantidad de recursos, y luego los K8 lo resolverán por sí solos. Pero el soporte de almacenamiento en Kubernetes sigue siendo inestable: En (este comunicado fue publicado недели hace) estas funciones pasan a ser solo beta.
Pasarán de seis meses a un año y se volverá más o menos estable, o al menos así se declarará. Entonces la posibilidad de tomar instantáneas y cambiar el tamaño resuelve tu problema por completo. Porque tienes una base. Sí, puede que no sea muy rápido, pero la velocidad depende de lo que hay "debajo del capó", porque algunas implementaciones pueden copiar y copiar en escritura a nivel del subsistema de disco.
NA: También es necesario que todos los motores (Amazon, Google...) empiecen a soportar esta versión; esto también lleva algún tiempo.
DS: Aún no los usamos. Usamos el nuestro.
Desarrollo local para Kubernetes
NA: ¿Se ha encontrado con ese deseo cuando necesita instalar todos los pods en una máquina y realizar una prueba tan pequeña? Para obtener rápidamente una prueba de concepto, compruebe que la aplicación se ejecuta en Kubernetes, sin dedicarle muchas máquinas. Está Minikube, ¿verdad?
DS: Me parece que este caso - desplegado en un nodo - trata exclusivamente de desarrollo local. O algunas manifestaciones de tal patrón. Comer Hay , . Estamos avanzando hacia el uso de Kubernetes IN Docker. Ahora comenzamos a trabajar con él para las pruebas.
NA: Solía pensar que se trataba de un intento de envolver todos los pods en una imagen de Docker. Pero resultó que se trata de algo completamente diferente. De todos modos, hay contenedores separados, pods separados, solo en Docker.
DS: Sí. Y se hace una imitación bastante divertida, pero el significado es este... Tenemos una utilidad para implementar: . Queremos convertirlo en un modo condicional. werf up: "Consígueme Kubernetes local". Y luego ejecuta el condicional allí. werf follow. Luego, el desarrollador podrá editar el IDE y se iniciará un proceso en el sistema que ve los cambios y reconstruye las imágenes, redesplegándolas en los K8 locales. Así queremos intentar solucionar el problema del desarrollo local.
Instantáneas y clonación de bases de datos en la realidad de K8
NA: Si volvemos a copiar en escritura. Noté que las nubes también tienen instantáneas. Funcionan de manera diferente. Por ejemplo, en GCP: tienes una instancia de varios terabytes en la costa este de Estados Unidos. Tomas instantáneas periódicamente. Recoge una copia del disco en la costa oeste de una instantánea: en unos minutos todo está listo, funciona muy rápido, solo es necesario llenar el caché en la memoria. Pero estos clones (instantáneas) son para "aprovisionar" un nuevo volumen. Esto es genial cuando necesitas crear muchas instancias.
Pero para las pruebas, me parece que las instantáneas, de las que hablas en Docker o de las que hablo en ZFS, btrfs e incluso LVM... te permiten no crear datos realmente nuevos en una máquina. En la nube, seguirás pagando por ellos cada vez y no esperarás segundos, sino minutos (y en el caso , posiblemente un reloj).
En cambio, puede obtener estos datos en uno o dos segundos, ejecutar la prueba y desecharlos. Estas instantáneas resuelven diferentes problemas. En el primer caso, para ampliar y obtener nuevas réplicas, y en el segundo, para realizar pruebas.
DS: No estoy de acuerdo. Hacer que la clonación de volúmenes funcione correctamente es tarea de la nube. No he visto su implementación, pero sé cómo lo hacemos en hardware. Tenemos Ceph, permite cualquier volumen físico () decir clonar y obtener un segundo volumen con las mismas características en decenas de milisegundos, 'ami, etc. Debe comprender que hay una copia en escritura complicada en su interior. ¿Por qué la nube no debería hacer lo mismo? Estoy seguro de que están intentando hacer esto de una forma u otra.
NA: Pero todavía les llevará segundos, decenas de segundos generar una instancia, llevar Docker allí, etc.
DS: ¿Por qué es necesario generar una instancia completa? Tenemos una instancia con 32 núcleos, 16... y en ella caben, por ejemplo, cuatro. Cuando ordenemos el quinto, la instancia ya estará activada y luego se eliminará.
NA: Sí, interesante, Kubernetes resulta ser una historia diferente. Nuestra base de datos no está en K8 y tenemos una instancia. Pero clonar una base de datos de varios terabytes no lleva más de dos segundos.
DS: Esto es genial. Pero mi observación inicial es que ésta no es una solución genérica. Sí, es genial, pero solo es adecuado para Postgres y solo en un nodo.
NA: Es adecuado no solo para Postgres: estos planes, como lo describí, solo funcionarán en él. Pero si no nos preocupamos por los planes y solo necesitamos todos los datos para las pruebas funcionales, entonces esto es adecuado para cualquier DBMS.
DS: Hace muchos años hicimos algo similar con las instantáneas de LVM. Este es un clásico. Este enfoque se utilizó muy activamente. Los nodos con estado son simplemente una molestia. Porque no debes dejarlos caer, debes recordarlos siempre...
NA: ¿Ves alguna posibilidad de un híbrido aquí? Digamos que stateful es una especie de pod, funciona para varias personas (muchos evaluadores). Tenemos un volumen, pero gracias al sistema de archivos, los clones son locales. Si el pod cae, pero el disco permanece, el pod se elevará, contará la información sobre todos los clones, recogerá todo nuevamente y dirá: "Aquí están sus clones ejecutándose en estos puertos, continúe trabajando con ellos".
DS: Técnicamente, esto significa que dentro de Kubernetes hay un módulo dentro del cual ejecutamos muchos Postgres.
NA: Sí. Tiene un límite: digamos que no trabajan con él más de 10 personas al mismo tiempo. Si necesita 20, lanzaremos un segundo módulo de este tipo. Lo clonaremos por completo, habiendo recibido el segundo volumen completo, tendrá los mismos 10 clones "delgados". ¿No ves esta oportunidad?
DS: Necesitamos agregar problemas de seguridad aquí. Este tipo de organización implica que este pod tiene altos privilegios (capacidades), porque puede realizar operaciones no estándar en el sistema de archivos... Pero repito: creo que a mediano plazo arreglarán el almacenamiento en Kubernetes, y en las nubes arreglarán toda la historia con volúmenes: todo “simplemente funcionará”. Habrá cambio de tamaño, clonación... Hay un volumen; decimos: "Crea uno nuevo basado en eso", y después de un segundo y medio obtenemos lo que necesitamos.
NA: No creo en un segundo y medio por muchos terabytes. En Ceph lo haces tú mismo, pero hablas de las nubes. Vaya a la nube, haga una copia de un volumen EBS de varios terabytes en EC2 y vea cuál será el rendimiento. No tardará unos segundos. Estoy muy interesado en saber cuándo alcanzarán este nivel. Entiendo lo que estás diciendo, pero discrepo.
DS: Bueno, pero dije a mediano plazo, no a corto plazo. Por muchos años.
Acerca del operador para PostgreSQL de Zalando
En medio de esta reunión también se sumó Alexey Klyukin, ex desarrollador de Zalando, que habló sobre la historia del operador PostgreSQL:
Es genial que este tema se aborde en general: tanto Postgres como Kubernetes. Cuando empezamos a hacerlo en Zalando en 2017 era un tema que todo el mundo quería hacer, pero nadie lo hacía. Todo el mundo ya tenía Kubernetes, pero cuando preguntaron qué hacer con las bases de datos, incluso personas como , que predicaba los K8, dijo algo como esto:
“Vaya a los servicios administrados y utilícelos, no ejecute la base de datos en Kubernetes. De lo contrario, sus K8 decidirán, por ejemplo, realizar una actualización, apagar todos los nodos y sus datos volarán muy, muy lejos”.
Decidimos crear un operador que, contrariamente a este consejo, lanzará una base de datos Postgres en Kubernetes. Y teníamos una buena razón. . Esta es una conmutación por error automática para PostgreSQL, realizada correctamente, es decir. utilizando etcd, cónsul o ZooKeeper como almacenamiento de información sobre el clúster. Un repositorio que le dará a todos los que pregunten, por ejemplo, cuál es el líder actual, la misma información, a pesar de que lo tenemos todo distribuido, para que no haya cerebros divididos. Además teníamos para él.
En general, la necesidad de la empresa de realizar una conmutación por error automática apareció después de migrar desde un centro de datos de hardware interno a la nube. La nube se basó en una solución patentada PaaS (Plataforma como servicio). Es de código abierto, pero requirió mucho trabajo ponerlo en funcionamiento. Fue llamado .
Inicialmente, no existía Kubernetes. Más precisamente, cuando se implementó nuestra propia solución, los K8 ya existían, pero estaban tan en bruto que no eran aptos para la producción. Fue, en mi opinión, 2015 o 2016. Para 2017, Kubernetes se había vuelto más o menos maduro: era necesario migrar allí.
Y ya teníamos un contenedor Docker. Había una PaaS que usaba Docker. ¿Por qué no probar los K8? ¿Por qué no escribir su propio operador? Murat Kabilov, que llegó a nosotros desde Avito, comenzó esto como un proyecto por iniciativa propia - "para jugar" - y el proyecto "despegó".
Pero, en general, quería hablar de AWS. ¿Por qué había código histórico relacionado con AWS...
Cuando ejecuta algo en Kubernetes, debe comprender que K8 es un trabajo en progreso. Está en constante desarrollo, mejora e incluso descompone de vez en cuando. Debe estar atento a todos los cambios en Kubernetes, debe estar preparado para sumergirse en él si sucede algo y aprender cómo funciona en detalle, tal vez más de lo que le gustaría. Esto, en principio, se aplica a cualquier plataforma en la que ejecutes tus bases de datos...
Entonces, cuando hicimos la declaración, teníamos Postgres ejecutándose en un volumen externo (EBS en este caso, ya que estábamos trabajando en AWS). La base de datos creció, en algún momento fue necesario cambiar su tamaño: por ejemplo, el tamaño inicial de EBS era de 100 TB, la base de datos creció hasta alcanzarlo, ahora queremos que EBS tenga 200 TB. ¿Cómo? Digamos que puede realizar un volcado/restauración en una nueva instancia, pero esto llevará mucho tiempo e implicará tiempo de inactividad.
Por lo tanto, quería un cambio de tamaño que ampliara la partición de EBS y luego le dijera al sistema de archivos que usara el nuevo espacio. Y lo hicimos, pero en ese momento Kubernetes no tenía ninguna API para la operación de cambio de tamaño. Desde que trabajamos en AWS, escribimos código para su API.
Nadie te impide hacer lo mismo con otras plataformas. No hay ningún indicio en la declaración de que solo se pueda ejecutar en AWS y que no funcionará en todo lo demás. En general, este es un proyecto de Código Abierto: si alguien quiere acelerar el surgimiento del uso de la nueva API, es bienvenido. Comer , solicitudes de extracción: el equipo de Zalando intenta responderlas con bastante rapidez y promocionar al operador. Hasta donde yo sé, el proyecto en Google Summer of Code y algunas otras iniciativas similares. Zalando está trabajando muy activamente en ello.
¡Bono de PD!
Si está interesado en el tema de PostgreSQL y Kubernetes, tenga en cuenta también que la semana pasada tuvo lugar el próximo martes de Postgres, donde hablé con Nikolai. Alejandro Kukushkin de Zalando. El vídeo del mismo está disponible. .
PPS
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com