Author Archives: Grant Slater

Un año de progreso en infraestructuras: Informe del Ingeniero de Fiabilidad del Sitio 2023/2024

Como Ingeniero Senior de Fiabilidad del Sitio (SRE) de la Fundación OpenStreetMap, el año pasado me centré dentro del Equipo de Operaciones de OpenStreetMap en impulsar la eficiencia, mejorar la resistencia y ampliar nuestra infraestructura para apoyar el crecimiento continuo del proyecto OpenStreetMap. Desde la migración a la nube hasta la actualización de los servidores, hemos realizado varias mejoras desde el año pasado para posicionar mejor la infraestructura de OpenStreetMap y hacer frente a estos retos de resistencia y crecimiento.

Mejorar los servicios de cara al usuario

Servicios de renderizado mejorados

La infraestructura de renderizado de teselas ha experimentado notables mejoras, como optimizaciones de hardware y software, una caducidad más rápida de la caché de teselas para hacer frente al vandalismo, y la automatización para bloquear a los usuarios no atribuidores. Ahora a diario volvemos a renderizar las teselas de zoom bajo, lo que mejora el rendimiento y permite un bucle de retroalimentación al mapeador más rápido. El servicio de teselas se utiliza mucho y mantener la demanda es un reto continuo.

Nuevo servicio de imágenes aéreas

Lanzamos un nuevo servicio de imágenes aéreas compatible con COGs GeoTIFF. El servicio aloja ahora aerial.openstreetmap.org.za, respaldado por 16 TB de imágenes de alta resolución. El nuevo servicio facilita el alojamiento de imágenes adicionales en el futuro.

Transición a la alternativa de Gmail y mitigación del spam

Tras enfrentarme a importantes problemas de spam con el espacio de trabajo de Google de OSMF, migré los servicios de correo electrónico de OSMF a mailbox.org. Esto ha reducido el volumen de spam y ha mejorado la eficiencia administrativa. También estamos en el proceso de transición de los datos históricos de Google Docs de OSMF a un servicio autoalojado.

Hacer frente a los ataques DDoS y al vandalismo

Este año nos hemos enfrentado a varios ataques de denegación de servicio distribuido (DDoS), incluido un importante incidente de DDoS para pedir rescate, del que se informó a las fuerzas de seguridad. Estos ataques pusieron a prueba nuestra infraestructura, pero hemos aplicado medidas para reforzar nuestra resistencia y protegernos mejor contra futuras amenazas.

También hicimos frente al vandalismo a gran escala que afectó a los servicios de OpenStreetMap. Gracias a la rápida respuesta y a los ajustes realizados por el equipo de Operaciones, hemos reforzado nuestra infraestructura para gestionar mejor los abusos y garantizar un servicio continuo.

Alojamiento de Planet Data en AWS S3

Junto con el Equipo de Operaciones de OpenStreetMap, he trasladado nuestro alojamiento de datos de planetas a AWS S3 con réplicas tanto en la UE como en EE.UU., lo que nos ha permitido restablecer por completo el catálogo retrospectivo de datos históricos. A través del patrocinio OpenData de AWS, los diffs de replicación y los datos planetarios son ahora más accesibles.

Facilitar la gestión de los sistemas

Gestión completa de la infraestructura de AWS con OpenTofu

Con el Equipo de Operaciones de OpenStreetMap he migrado con éxito todos los recursos de AWS gestionados manualmente a la Infraestructura como Código (IAC) utilizando OpenTofu (antes Terraform). Esta transición nos ha permitido mejorar la rentabilidad, aumentar la seguridad adoptando un modelo IAM de mínimo privilegio y obtener una mejor visibilidad de los gastos mediante etiquetas de facturación detalladas. Además, hemos integrado S3 Storage Analytics para optimizar aún más nuestros costes, hemos configurado copias de seguridad adicionales y hemos implementado reglas de ciclo de vida mejoradas.

Alerta mejorada de interrupción del servicio

Hemos implementado alertas por SMS para las interrupciones críticas del servicio, junto con una cuenta patrocinada de PagerDuty. Estas mejoras garantizan tiempos de respuesta más rápidos y una mejor coordinación durante las interrupciones, y se está trabajando en la integración completa con Prometheus/Alertmanager y Statuscake.

Reducción de la Deuda Técnica

Este año hemos avanzado en la reducción de la deuda técnica trasladando varios servicios heredados a soluciones más fáciles de mantener. Por ejemplo, hemos puesto en contenedores servicios antiguos, como los sitios web del Estado del Mapa, que antes funcionaban con instalaciones de WordPress mal mantenidas. Esta transición ha mejorado la escalabilidad, la seguridad y el mantenimiento a largo plazo de estos servicios.

Además, sustituimos nuestra instalación de código personalizado de OTRS por una instalación del paquete Znunyde Debian. Este cambio simplifica las actualizaciones y reduce la carga de mantenimiento, garantizando que el sistema permanezca actualizado y seguro sin modificaciones personalizadas.

Garantizar la resistencia de la infraestructura a pesar de los fallos del hardware

El año pasado mantuvimos una infraestructura resistente incluso ante fallos de hardware. Sustituimos numerosos discos y RAM, garantizando una interrupción mínima de los servicios. Nuestro sistema de supervisión a medida nos permite detectar señales tempranas de fallos de hardware, lo que nos permite actuar con rapidez y sustituir los componentes defectuosos antes de que causen problemas importantes. Este enfoque proactivo ha sido clave para mantener el tiempo de actividad y la fiabilidad del sistema.

Mejora de las infraestructuras

Replicación entre sitios de las copias de seguridad

Para garantizar una sólida recuperación de desastres, he establecido una replicación entre cuentas y regiones para las copias de seguridad de AWS S3, lo que permite una recuperación puntual. Esto salvaguarda los datos y servicios críticos, incluso ante fallos graves, proporcionando tranquilidad a largo plazo.

Infraestructura de alta disponibilidad

Las actualizaciones de hardware clave en nuestras sedes de Ámsterdam, Dublín y OSUOSL mejoraron el rendimiento, la capacidad de almacenamiento y la fiabilidad de la red. En 2022 se instalaron nuevos conmutadores, y ahora hemos terminado de establecer una configuración de alta disponibilidad (HA) para garantizar un mejor servicio, que hemos seguido mejorando pasando a enlaces ascendentes diversos duales con nuestro ISP para mejorar la capacidad de recuperación.

Migración a Debian

Estamos migrando de Ubuntu a Debian 12 (Bookworm) como nuestra distribución estándar. Todos los servidores nuevos funcionan ahora con Debian. Nuestra gestión de configuración de chefs se ha actualizado con código de prueba para garantizar la compatibilidad permanente. Esta transición marca un cambio hacia una mayor estabilidad y seguridad a largo plazo. Post de Mastodon celebrando la transición.

De cara al futuro

El año que tenemos por delante nos brinda nuevas y emocionantes oportunidades a medida que avanzamos. Las prioridades clave para 2024 / 2025 incluyen:

Involucramiento

Compromiso con la Comunidad y Comunicación Exterior: Aumentar la colaboración con el Grupo de Trabajo de Comunicación (GTC) y mejorar nuestra comunicación de cara al público sobre el estado del servicio y los cortes.

Mejorar la documentación y la incorporación: Mejoraremos la documentación de incorporación y realizaremos sesiones específicas para ayudar a los nuevos colaboradores a participar en las operaciones más fácilmente. Esto incluye mejorar la fiabilidad y la cobertura de nuestros procesos de prueba, garantizando contribuciones más fluidas y reduciendo la curva de aprendizaje para los nuevos miembros del equipo.

Planificar y optimizar

Planificación de la capacidad para el crecimiento de la infraestructura: A medida que OpenStreetMap y la demanda de nuestros servicios crezcan, nos aseguraremos de que podemos escalar para satisfacer la demanda. Al anticiparnos a las necesidades futuras y equilibrar el rendimiento con un crecimiento rentable, pretendemos mantener la calidad y disponibilidad del servicio que espera nuestra comunidad.

Optimización continua de los costes: Seguiremos buscando formas de reducir costes aprovechando patrocinios como el programa AWS OpenData, garantizando operaciones sostenibles.

Seguir reduciendo la deuda técnica: Seguiremos simplificando nuestra infraestructura reduciendo la carga de mantenimiento de los sistemas heredados, por ejemplo aumentando el uso de contenedores. Esto ayudará a agilizar las tareas de gestión y nos permitirá centrarnos en otras mejoras, haciendo que la infraestructura sea más eficiente y escalable con el tiempo.

Seguir mejorando las infraestructuras

Implantación de equilibradores de carga de alta disponibilidad: Despliegue de la configuración HA (VRRP + LVS + DSR) de los equilibradores de carga para mejorar la fiabilidad del sistema y reducir los posibles tiempos de inactividad.

Finalización de la integración de Prometheus con PagerDuty: Finalización de la integración de Prometheus para la supervisión y PagerDuty para agilizar las alertas y la respuesta a incidentes.

Completar la transición a un entorno Debian completo: Migrar todos los servicios restantes de Ubuntu a Debian para aumentar la estabilidad y la seguridad.

Mejorar las estrategias de recuperación y copia de seguridad en caso de catástrofe: Perfeccionando nuestra documentación de recuperación e introduciendo medidas adicionales de copia de seguridad en todos los servicios críticos están protegidos y son recuperables en caso de fallo.

Impulsando el futuro de OpenStreetMap: Un año de mejoras del ingeniero de fiabilidad del sitio de la Fundación OpenStreetMap

Hace poco más de un año, me uní a la Fundación OpenStreetMap (OSMF) con el objetivo de mejorar la fiabilidad y seguridad de la tecnología y la infraestructura que sustenta OpenStreetMap. A lo largo del año pasado, he trabajado estrechamente con el Grupo de Trabajo de Operaciones, un equipo dedicado de voluntarios. Juntos, hemos logrado un progreso significativo en la mejora de nuestros procesos y documentación, fortaleciendo en última instancia nuestra eficacia colectiva. Estoy inmensamente agradecido por el apoyo y la colaboración dentro de este grupo, y estoy encantado de presenciar los notables avances que hemos dado en la construcción de una base sólida para el futuro de OpenStreetMap.

Entraré en un poco de detalle a continuación sobre lo que se ha hecho. A un alto nivel, facilité la administración de la implementación del software que se ejecuta en nuestros servidores; fortalecí nuestra infraestructura de red a través de una mejor redundancia, monitoreo, acceso y documentación; aumenté nuestro uso de servicios en la nube para la representación de teselas, aprovechando un generoso patrocinio de AWS; mejoré nuestras prácticas de seguridad; actualicé nuestros entornos de desarrolladores; y por último, pero definitivamente no menos importante, finalicé la migración de 16 años de contenido de nuestros antiguos foros a nuestros nuevos foros.

Si quieres saber más de mí en el transcurso del trabajo del año pasado, echa un vistazo a mi charla en State of the Map 2022 y mi entrevista en el podcast GeoMob. Y me encantaría saber de ti, envíame un correo electrónico a osmfuture@firefishy.com.

Detalles de confiabilidad del sitio 2022-2023

Gestión de software en nuestros servidores

Pequeños Componentes de infraestructura en contenedores (GitHub Actions for building)

He puesto en contenedores muchos de nuestros sitios pequeños que se construyeron previamente utilizando métodos a medida en nuestra base de código de chef como parte de la configuración de “Configuración como código”. Se movieron los pasos de compilación a Github Actions. Configuré una base para cualquier proyecto futuro basado en contenedores (“docker”) en el futuro. Estos son nuestros primeros proyectos basados en contenedores / docker alojados en la infraestructura OSMF.

Nuestro código basado en chef ahora es más simple, más seguro y se implementa más rápido.

Pruebas de chef mejoradas (documentación de incorporación de operaciones)

Utilizamos chef.io para la gestión de la infraestructura (configuración) de todos nuestros servidores y el software utilizado en ellos. Durante el último año, las pruebas de cocina del chef test se han extendido y ahora también funcionan en las modernas máquinas Apple Silicon. Las pruebas ahora se ejecutan de manera confiable como parte de nuestros procesos de CI / PR. Las pruebas agregan control de calidad y garantía a los cambios que hacemos. El soporte ARM fue más fácil de agregar porque podíamos usar la cocina de prueba antes de pasar al hardware del servidor ARM.

Tener pruebas confiables debería ayudar a incorporar nuevos colaboradores del chef.

Se reforzó nuestra infraestructura de red

Network Upgrades @ AMS (Nuevos switches, enlaces redundantes duales, Dublín pronto)

Nuestra configuración de red en Ámsterdam no era tan redundante como debería haber sido. El equipo Cisco Small Business que utilizamos se nos había quedado pequeño. Tuvimos cortes de energía inesperados debido a problemas de hardware. El equipo también estaba limitando futuras actualizaciones. El grupo de operaciones decidió reemplazar el hardware con equipos Juniper que habíamos estandarizado en el centro de datos de Dublín. Reemplacé el equipo con un tiempo de inactividad mínimo en un entorno en vivo (<15 minutos).

Los centros de datos de Dublín y Ámsterdam ahora utilizan una configuración estandarizada y más segura. Cada servidor ahora tiene enlaces totalmente vinculados para mejorar la redundancia y el rendimiento. Los switches han mejorado la potencia y la redundancia de la red. Estamos esperando la instalación de los enlaces ascendentes totalmente resistentes (pedido enviado) en el próximo mes.

Acceso fuera de banda a ambos centros de datos (basado en 4G)

Construí e instalé dispositivos de acceso fuera de banda en cada sitio. Los dispositivos están cableados a equipos de red y administración de energía mediante consolas seriales. Los dispositivos fuera de banda tienen un enlace 4G resistente a una red 4G privada (1NCE). Los dispositivos de acceso fuera de banda son Raspberry PI personalizadas con fuentes de alimentación redundantes y 4 conectores seriales.

Documentación de Infraestructura para facilitar el mantenimiento (Racks / Power)

Documenté cada unidad rack, puerto de alimentación (Power Distribution Unit), conexión de red y cable en los centros de datos. Esto facilita la administración de los servidores, reduce los errores y nos permite instruir adecuadamente a las manos remotas (proveedor de soporte externo) para que realicen cualquier cambio en nuestro nombre.

Oxidized (visibilidad de equipos de red)

Nuestra configuración de red y distribución de energía ahora se almacena en git y se informan los cambios. Esto mejora la visibilidad de cualquier cambio, lo que a su vez mejora la seguridad.

La configuración se supervisa continuamente y cualquier desviación de configuración entre nuestros sitios ahora es mucho más fácil de resolver.

Infraestructura Terraform como Código (mejorar la gestión / repetibilidad)

Terraform es una herramienta de infraestructura como código, ahora la usamos para administrar nuestro servicio de monitoreo remoto (statuscake) y estoy en el proceso de implementarlo para administrar nuestra infraestructura de AWS y Fastly.

Anteriormente, todos estos componentes se administraban manualmente utilizando las respectivas interfaces de usuario web. La infraestructura como código permite al equipo de operaciones trabajar colaborativamente en los cambios, mejora la visibilidad y la repetibilidad / reversión de cualquier cambio.

Gestionamos todos los dominios DNS utilizando el código dnscontrol. Se han realizado mejoras incrementales durante el último año, incluida la adición de pruebas de IC para mejorar la colaboración externa.

Aumentó nuestro uso de servicios en la nube

AWS en uso para la infraestructura de representación. Optimización de los costos de AWS. Seguridad mejorada. Copia de seguridad mejorada. Más en trámite

El equipo de operaciones ha ido aumentando lentamente nuestro uso de AWS en los últimos años. He creado varias cuentas de AWS específicas de uso utilizando un modelo de organización de AWS para mejorar la facturación y la seguridad según las directrices de prácticas recomendadas de AWS. Recibimos generosamente el patrocinio de AWS para expandir nuestra infraestructura de renderizado. Creamos la nueva infraestructura de renderizado experimental con la arquitectura ARM con AWS Graviton2 EC2.
No hemos usado anteriormente servidores basados en ARM. Como parte de las mejoras en nuestro chef (configuración como código) habíamos agregado soporte de pruebas locales para Apple Silicon (ARM), solo se requirieron pequeñas adiciones para agregar la compatibilidad requerida para los servidores ARM al chef.

Nos impresionó el rendimiento de las instancias EC2 de AWS Graviton2 para ejecutar la pila de representación de teselas de OSM. También probamos el escalado bajo demanda y la creación de instantáneas de instancias para posibles mejoras adicionales de la pila de render en AWS.
Hemos aumentado nuestro uso de AWS para la copia de seguridad de datos.

Mejoramos nuestra seguridad

Durante el último año se han realizado una serie de mejoras generales de seguridad. Por ejemplo: El acceso al servidor ahora es a través de clave ssh (el acceso con contraseña ahora está deshabilitado). También hemos pasado de un administrador de contraseñas basado en gpg a medida para el equipo de operaciones a usar gopass (versión rica en funciones de https://www.passwordstore.org/), GoPass mejora la administración de claves y el uso compartido del almacén de contraseñas.

Además, también hemos mejorado el bloqueo de nuestras instancias de WordPress al reducir los componentes instalados, deshabilitar las actualizaciones en línea y deshabilitar el acceso XMLRPC. También estamos trabajando para reducir los usuarios con acceso y eliminar los permisos de acceso no utilizados.

Áreas clave documentadas de vulnerabilidad que requieren mejoras (redundancia, seguridad, etc.)

Documentación sobre vulnerabilidad técnica: Estoy elaborando un informe sobre áreas clave de vulnerabilidad que requieren mejoras (Redundancia, Seguridad, etc.). El documento se puede utilizar para enfocar la inversión en el futuro para reducir aún más nuestra exposición a los riesgos.

Hemos renovado nuestros entornos de desarrollo

Nuevo servidor de desarrollo

Hemos migrado todos los usuarios de desarrollo a un nuevo servidor de desarrollo en el último año. El servidor antiguo había terminado su vida útil (~ 10 años) y estaba alcanzando límites de capacidad (CPU y almacenamiento). El nuevo servidor se entregó directamente al centro de datos de Ámsterdam, se instaló físicamente con manos remotas y comuniqué la migración, y luego migré todos los usuarios y proyectos.

Subversion retirada

Retiré nuestro viejo repositorio de código svn.openstreetmap.org el año pasado. El repositorio de código se utilizó desde el inicio del proyecto, y contenía un rico historial de desarrollo de código en el proyecto. Convertí el repositorio de código svn a git usando una configuración de reposurgeon personalizada, se prestó atención a mantener el historial de contribuciones completo y vincular correctamente a los contribuyentes anteriores (350+) a las respectivas cuentas de github y relacionadas. Los antiguos enlaces svn se mantuvieron y ahora enlazan al archivo en github https://github.com/openstreetmap/svn-archive.

Migración del foro

En la migración del antiguo foro migramos 1 millón de publicaciones y 16 años de publicaciones a discourse. Todas las publicaciones se convirtieron de fluxbb markdown a la versión de markdown de discourse. Todas las cuentas se fusionaron y la autenticación se convirtió a OpenStreetMap.org “inicio de sesión único” basado en auth.

Todos los enlaces antiguos del foro redirigen (enlace al importado) para corregir el contenido. Usuarios, categorías (países, etc.), temas de hilo y publicaciones individuales.