Caso de estudio – La caída de Gitlab

Prevenir es mejor que curar

Lo leí por allí

Esta vieja pero confiable frase es muy importante en muchas áreas, si tuvieras un cimiento firme no tendrías que preocuparte por un sismo, si tu instalación eléctrica fuera confiable no necesitarías preocuparte de que un cortocircuito provoque un incendio, existen numerosos estudios que una prevención temprana logra sobrellevar altamente el cáncer y en muchos casos curarlo.

Cada dejadez con nosotros será una deuda que tendremos que pagar tarde o temprano

Juan Retamales & Lo leí por allí

Y no solo aplica a nosotros, también a los sistemas informáticos, y suele llamarse «deuda tecnológica», imaginemos que estamos utilizando una base de datos en producción, y aplicamos el clásico meme de realizar un delete olvidándose del where, para los no tan conocedores, será un camino directo a la quiebra o al despido en especial si no tienen un respaldo, por ello es importante asegurar que realizan respaldos frecuentemente y que desarrollen en un servidor de desarrollo, y dejar el servidor de producción en su lugar, es decir, dejarlo produciendo.

Pero no solo eso, también es importante verificar la integridad de estos respaldos, ya que, si no se verifican, tal vez eso en lo que confías no era nada mas que aire, es decir, nada.

Les invita a leer el caso de estudio con esta música:

Caso de estudio – La caída de gitlab

Primer impacto (incidente)

El 31 de enero de 2017 a las 6 p.m. UTC, se detecto una gran cantidad de peticiones al servidor (posiblemente spammer) golpeando a la base de datos haciéndola inestable, se empezó a estudiar para comprender cual era el problema y desarrollar una estrategia para combatirla.

El 31/01/2017 a las 9 p.m. UTC, esto se intensificó, lo que provocó un bloqueo en las escrituras en la base de datos, lo que provocó un tiempo de inactividad.

Por lo que se tomaron las siguientes acciones:

  • Bloqueo a los spammers basados en su IP
  • Eliminar usuarios por usar un repositorio como forma de CDN
  • Eliminar a los usuarios por enviar spam

Segundo impacto (incidente)

En 2017/01/31 10pm UTC, empezamos a recibir alertas debido a que la DB Replicadora (espejo) se retrasó demasiado, finalmente deteniéndose. Esto sucedió porque hubo un aumento en las transacciones que no fueron procesadas a tiempo por la base de datos secundaria.

Acciones tomadas:

  • Intente solucionar db2, en este punto se está retrasando aproximadamente 4 GB
  • El cluster db2 se niega a replicar, /var/opt/gitlab/postgresql/data se borra para garantizar una replicación limpia
  • El cluster db2 se niega a conectarse db1, quejándose de max_wal_senders ser demasiado bajo. Esta configuración se usa para limitar la cantidad de clientes WAL a replicar.
  • Miembro del equipo 1 ajusta max_wal_senders a 32 encendiiendo db1, reinician PostgreSQL para aplicar cambios
  • PostgreSQL se queja de que hay demasiadas conexiones abiertas y se niega a comenzar
  • Miembro del equipo 1 se ajust max_connections a 2000 partir de 8000, PostgreSQL se inicia de nuevo (a pesar de 8000haber sido usado durante casi un año)
  • El cluster db2 todavía se niega a replicar, aunque ya no se queja de las conexiones; en cambio, simplemente se cuelga sin hacer nada
  • En este punto, la frustración comienza a aparecer. A principios de esta noche , el miembro del equipo 1 mencionó explícitamente que iba a cerrar la sesión porque se estaba haciendo tarde (23:00 más o menos, hora local), pero no lo hizo debido a los problemas de replicación que aparecían. de repente.

Tercer Impacto (incidente)

En 2017/01/31 11 pm Miembro del equipo 1 piensa que tal vez pg_basebackup se niega a trabajar debido a que el directorio de datos de PostgreSQL está presente (a pesar de estar vacío), decide eliminar el directorio. Después de uno o dos segundos, se da cuenta de que lo ejecutó, en db1.cluster.gitlab.com lugar de db2.cluster.gitlab.com.

En 2017/01/31 11:27 pm UTC, Miembro del equipo 1 – cancela la eliminación, pero es demasiado tarde. De alrededor de 300 GB solo quedan unos 4,5 GB.

Tuvimos que bajar GitLab.com y compartir esta información en Twitter:

Problemas encontrados:

  • Las copias de seguridad periódicas también parecen realizarse solo una vez cada 24 horas, aunque el miembro del equipo 1 aún no ha podido averiguar dónde se almacenan. Según Miembro del equipo 2, estos no parecen estar funcionando, produciendo archivos de solo unos pocos bytes de tamaño.
  • Miembro del equipo 3 : Parece que pg_dump puede estar fallando porque se están ejecutando los binarios de PostgreSQL 9.2 en lugar de los binarios de la 9.6. Esto sucede porque omnibus solo usa Pg 9.6 si data / PG_VERSION está configurado en 9.6, pero en los trabajadores este archivo no existe. Como resultado, el valor predeterminado es 9.2, fallando silenciosamente. Como resultado, no se realizaron volcados de SQL. La gema de niebla puede haber limpiado las copias de seguridad más antiguas.
  • Las instantáneas de disco en Azure están habilitadas para el servidor NFS, pero no para los servidores de base de datos.
  • El proceso de sincronización elimina los webhooks una vez que ha sincronizado los datos con la puesta en escena. A menos que podamos extraerlos de una copia de seguridad regular de las últimas 24 horas, se perderán.
  • El procedimiento de replicación es muy frágil, propenso a errores, se basa en un puñado de scripts de shell aleatorios y está mal documentado.
  • Nuestras copias de seguridad de S3 aparentemente tampoco funcionan: el depósito está vacío
  • En otras palabras, de las cinco técnicas de copia de seguridad / replicación implementadas, ninguna funciona de manera confiable o está configurada en primer lugar. Terminamos restaurando una copia de seguridad de seis horas.
  • pg_basebackup esperará silenciosamente a que un maestro inicie el progreso de la replicación, según otro ingeniero de producción, esto puede demorar hasta 10 minutos. Esto puede llevar a uno a pensar que el proceso está atascado de alguna manera. La ejecución del proceso con «strace» no proporcionó información útil sobre lo que podría estar sucediendo.
  • Las instantáneas de LVM se toman de forma predeterminada solo una vez cada 24 horas. Sin embargo, fuera de todo protocolo Miembro del equipo 1 ejecutó uno manualmente unas seis horas antes de la interrupción porque estaba trabajando en el equilibrio de carga para la base de datos.

Enseñanzas

  • Realiza copias y respaldos de la infraestructura critica de tu software
  • Asegurate de revisar que las copias y respaldos se generen correctamente, y por sobretodo, que puedas recuperarte
  • Siempre tener un protocolo de trabajo, por ejemplo yo tengo mucho cuidado al trabajar en la base de datos de producción y solo trabajo en local, y en producción solo tengo permisos de lectura, solo existe un usuario a mi disposición para modificar o escribir pero cuando lo uso tengo un cuidado exhaustivo

Deja un comentario