Cómo instalar un cluster de PostgreSQL en K8s

Instalar PostgreSQL en K8s es sumamente fácil, manejar PostgreSQL, es otra historia. Para instalar y manejar PostgreSQL en K8s se debe utilizar un operador que automatice las operaciones de replicación y administración. Hay varios operadores com Crunchy Data y KubeDB, el que yo utilizo es el operador de Zalando. (https://github.com/zalando/postgres-operator) Debe instalarlo desde su terminal en Linux o “Powershell” en Windows. Debe tener instalado git, helm y Kubernetes para poder seguir el siguiente tutorial de como instalar PostgreSQL. Si tiene instalado Minikube es suficiente. Con los pre-requisitos instalados, utilizar “zalando/postgres-operator” es sencillo con los siguientes pasos:

  1. Descargue el código de GitHub con el siguiente comando: git clone https://github.com/zalando/postgres-operator.git
  2. Posiciónese dentro de la carpeta que descargó: cd postgres-operator
  3. Instale el operador: helm install charts/postgres-operator/
  4. Instale el “cluster”de PostgreSQL: kubectl create -f manifests/minimal-postgres-manifest.yaml
  5. Verifique que todo esté bien: kubectl get pods -l application=spilo -L spilo-role

Así de sencillo, ya tiene un cluster de postgreSQL en K8s.

El nuevo rol del profesional de bases de datos

El siglo 21 es la era de la información. La manera como se maneja los datos ha cambiado dramaticamente. Tecnologías como Kubernetes, y AWS RDS (Amazon Relational Database Services) han cambiado la manera como se manejan las bases de datos. AWS RDS automatiza completamente el proceso de replicación . Cuando la replicación se interrumpe en un “cluster” de AWS RDS, la plataforma se encarga de repararlo automáticamente sin intervención humana. Desplegar y configurar bases de datos se puede hacer en minutos. Recientemente, kubernetes (k8s), permite operadores que manejan bases de datos con sus necesidades particulares con la misma facilidad que se hace en AWS RDS. Instalar, configurar y reparar bases de datos y su solución de alta disponibilidad (por ejemplo, replicación) representa el 90% de las tareas de algunos administradores de bases de datos. ¿Todavía se necesitan administradores de bases de datos? La respuesta es, sí. Déjeme enumerar 3 tareas que todavía se requerirá del administrador de bases de datos:

  1. Administración de la seguridad de las bases de datos. Cada organización tiene diferentes requerimientos en cuanto a la seguridad de sus datos. Esto no se puede automatizar y el administrador de bases de datos es responsable por mantener el estándar de seguridad requerido por la organización.
  2. Estrategia de recuperación de desastres. Se puede automatizar procesos de resguardo, pero esto es solo una pequeña parte de la estrategia de recuperación de desastres. El administrador de bases de datos es responsable de combinar las estrategias y tecnologías necesarias para cumplir con el acuerdo de nivel de servicio establecido por la organización.
  3. Gestión de rendimiento en las bases de datos. Cada base de datos con sus esquemas y el uso que se le da, requieren diferentes estrategias para que el acceso a los datos sea rápido y eficiente. Esto no se puede automatizar.

Estas tareas ya son comunes a los administradores de bases de datos. Ahora enumeraré 5 destrezas que debemos adquirir:

  1. Debemos aprender tecnologías como AWS, Azure y Google Cloud. No vea estos servicios como competencia o el enemigo que quiere quitarle el trabajo. Una vez aprenda y domine estas tecnologías, esas destrezas añadirán valor a usted como profesional.
  2. Aprenda algún lenguaje de programación como Go o Python. Automatizar tareas es un requerimiento hoy para casi todo profesional en la informática. Powershell, Python y Go son destrezas que son requeridas cada vez mas.
  3. Aprenda los fundamentos de manejar Kubernetes y Docker. La popularidad de las tecnologías de contenedores seguirá subiendo. Hoy por hoy, Kubernetes y Docker son los reyes de estas tecnologías. Cierto, no son las únicas en el mercado, pero son las más poulares al momento.
  4. Tecnologías de automatización como Ansible y Chef. Es cierto que hoy se espera que todo se migre a contenedores (Kubernetes o K8s), pero la realidad es que ciertas tecnologías de bases de datos no están listas para K8s. También es cierto que, dependiendo el uso, algunos escenarios harían imposible implementar bases de datos en K8s. Todavía debemos tener la habilidad de automatizar mantenimiento de bases de datos en servidores convencionales.
  5. Deberíamos aprender por lo menos una tecnología NoSQL, aparte de la tecnología de base de datos relacional. NoSQL cubre necesidades de manera más eficiente que RDBMS (Sistema de Manejo de bases de datos relacionales por sus siglas en inglés). MongoDB, y Cassandra son dos sistemas NoSQL muy populares. ScyllaDB si obteniendo popularidad también.

Resistir estos cambios es como tratar de tapar el sol con la mano. Para mantener nuestra profesión, debemos adquirir las destrezas que la industria dicte. Por más que queramos, no podemos dictar a la industria lo que queremos. No resista los cambios, acepte el reto de aprender nuevas destrezas y verá como crece su valor como profesional.

¿Qué es ScyllaDB?, 5 razones por qué debe interesarle

ScyllaDB es un reemplazo de Cassandra. Se diseñó con lenguaje C++ con el propósito de evitar las complejidades de lidiar con Java. La estructura de los “keyspaces” (El término equivalente de bases de datos para Cassandra/ScyllaDB en inglés.) es exactamente igual. Aplicaciones puden utilizar los mismos controladores de Cassandra para conectarse con ScyllaDB. También ScyllaDB cuenta con las herramientas nodetool y cqlsh. ¿Por qué rehacer una de las tecnologías de bases de datos mas populares? La comunidad aspira a mejorar el funcionamiento y rendimiento de Cassandra. La comunidad de ScyllaDB encuentra que utilizar Java en lugar de un lenguaje que hable directamente al procesador limita el rendimiento de Cassandra. De acuerdo con las pruebas realizad, ScyllaDB puede dar 10 veces el rendimiento de Cassandra. Y Cassandra es veloz, muy veloz.

Yo he tenido oportunidad de empezar a probar ScyllaDB y les doy mis 5 razones por las que debería interesarle conocer ScyllaDB:

  1. En mis pruebas, ScyllaDB resultó ser mas rápido. Utilizando una prueba sencilla con la aplicación cassandra-stress, ScyllaDB resultó ser 5 veces más rápido. (Mi servidor de prueba no tiene discos de alto rendimiento.).
  2. ScyllaDB cuenta con la aplicación scylla_setup. Esta aplicación automatiza el proceso de afinación de ScyllaDB. No tiene que afinar JVM para el motor de base de datos ScyllaDB.
  3. Al tener mayor rendimiento, puede procesar la misma cantidad de transacciones con menos recursos. En algunos casos puede economizar 50% de los recursos que necesitaría Cassandra. Imagine, economizar dinero e incrementar el rendimiento de la aplicación. Esta es una oportunidad que no se debe dejar de analizar.
  4. Si ya está utilizando Cassandra, es muy probable que no tenga que cambiar código ya que ScyllaDB utiliza los mismos conectores que Cassandra. A los compañeros administradores de bases de datos les digo, no tengan miedo de probar ScyllaDB. No es muy diferente de manejar Cassandra. Yo encuentro que ScyllaDB es más sencillo de manejar.
  5. La comunidad es muy activa y es muy receptiva a ayudar a los nuevos en el uso de ScyllaDB. Si se une al chat de ScyllaDB en http://slack.scylladb.com/, encontrará que la comunidad está dispuesta a ayudar. De hecho, si hace una pregunta, es muy probable que el que le conteste sea un empleado de ScyllaDB. El que comenzó el proyecto del operador de kubernetes para ScyllaDB es muy activo y me contestado varias preguntas personalmente.

En fin, pienso que si le da la oportunidad, verá que valdrá la pena visitar scylladb.com y experimentar con el software.

5 cosas a considerar antes de implementar bases de datos en Kubernetes

Docker y Kubernetes (abreviado se le dice K8s) están siendo ampliamente adaptadas en la industria tecnológica. En sus comienzos, K8s y Docker no tenían las funcionalidades necesarias para manejar bases de datos. Los contenedores en Docker son efímeros, aunque Kubernetes ofrece excelente manejo de contenedores, no tiene los mecanismos necesarios para manejar por sí solo lo que necesita para automatizar conmutación por error (failover), configurar cambios en la replicación y procesos únicos en bases de datos.

La comunidad está haciendo un excelente trabajo mejorando y añadiendo funcionalidades a K8s. Crearon volúmenes persistentes para montarlos en los “pods” y así contener datos de manera consistente. Esto es que no se borre cuando se elimine y reemplace un “pod”. Para satisfacer las necesidades particulares de cada aplicación, ahora se puede crear CRD (“Custom Resource Definition” o Definición de Recursos Personalizados). Con CRD, y la habilidad de instalar operadores personalizados en K8s, las comunidades “open source” (código abierto”) han creado diferentes operadores que manejan la automatización de tareas pertinentes a las diferentes tecnologías de bases de datos. ¿Es esto suficiente para implementar bases de datos de producción en K8s?

La opinión de este servidor es que sí, pero no en todos los casos. Yo todavía me retraigo de implementar en K8s bases de datos que se utilicen para operaciones intensas de análisis. Un ejemplo sería una base de datos que cada mes recoja 100 GB de datos para procesarlo, analizarlo y al final producir reportes. Esto sin duda requiere un servidor muy poderoso con muchos recursos. Pero hay otras bases de datos que se utilizan para reportes diarios, guardar contraseñas, y recopilar metadata sobre una aplicación. Estas bases de datos, yo me atrevo a decir que se pueden implementar en K8s, aunque tenga miles de usuarios.

Solo porque se puede implementar bases de datos en K8s, no necesariamente signifique que deba hacerlo. Aquí les tengo mi lista de 5 cosas a considerar antes de implementar bases de datos en K8s:

  1. El personal que diseña la arquitectura de la aplicación debe conocer el uso de las bases de datos que se van a administrar. Si se utilizan para cálculos complejos y procesan grandes cantidades de datos, probablemente K8s no es la solución más adecuada para usted. Asegúrese de que los “pods” de K8s tengan los recursos necesarios para operar con alto rendimiento.
  2. El personal que administra las bases de datos en K8s, debe tener entrenamiento en operar K8s. Es cierto que uno no va a ser experto en todo, pero debe conocer lo suficiente como para pedirle a los ingenieros que operan K8s lo que se necesita para operar las bases de datos. K8s es complejo y dentro del nodo de K8s existen redes, “namespaces”, roles, agentes, volúmenes persistentes, etc. Pudieran adjudicar problemas a limitaciones en K8s que en realidad sea configuración incorrecta. Debe tener expertos en K8s para trabajar los problemas que puedan surgir al operar bases de datos.
  3. Sea experto en la tecnología de bases de datos que va a implementar. K8s no es responsable de las configuraciones internas de PostgreSQL, ScyllaDB o cualquier otra base de datos. Eso es responsabilidad del administrador de bases de datos.
  4. Asegúrese de que el hardware de los nodos de K8s sea adecuado. Las bases de datos son aplicaciones robustas que requieren discos, CPUs y memoria de alto rendimiento. Si dispone de discos baratos, la aplicación tendrá problemas con el rendimiento y no será culpa de K8s.
  5. Utilice un buen operador personalizado para manejar bases de datos. K8s no maneja replicación entre “pods”, seleccionar el “pod” que servirá de primario, automatizar conmutación por error (failover) cuando un “pod” falla, etc. Hay varios operadores y no todos funcionan igual. Analice bien las opciones que tenga y elija el que más le convenga. Aquí hay una lista de operadores con buena reputación en la industria:
    1. Stolon (PostgreSQL)
    2. Zalando\postgresq-operator y patroni.
    3. KubeDB
    4. Scylla-operator todavía no está en producción, pero es prometedor.

En resumen, automatizar el manejo de bases de datos no es asunto de lanzarlo en K8s y asumir que todo va a ser automático. Igual que todo en la vida, requiere destreza, planificación y estrategia. Esa inversión vale la pena ya que puede lograr alta disponibilidad y estará más cerca de realizar ese elusivo “cero interrupción de servicio”.