Un Nuevo Sol en el Horizonte

Así es como se veía la antigua arquitectura:

Algunos de los aspectos menos destacados de esta arquitectura deberían ser aparentes para cualquiera que haya desplegado esta arquitectura en el pasado:

• Al configurar un nodo de Stellar Core, una configuración segura es esencial y no es fácil de crear. Hay muchos detalles que recordar (como dominios de casa, URIs de base de datos y otros parámetros únicos) incluso si no son tu enfoque principal.
• La reingestión era tediosa: cuando SDF añadía nuevas características a Horizon, a veces las organizaciones necesitaban reingestionar grandes cantidades de historia para poder aprovecharlas. Toma tiempo para que Horizon y Core procesen los ledgers en “metadatos de transacciones” (es decir, datos de series temporales como historial de balances, efectos de cuentas, etc.): una reingestión completa de la historia de pubnet podría tomar semanas, incluso en una máquina potente.
• Debido a este proceso complejo, Stellar Core tenía que retener cientos de gigabytes de datos para que Horizon facilitara la ingestión. A su vez, Horizon almacena varios terabytes de estos metadatos para fines de consulta. Obviamente, perder cualquiera de estos por corrupción u otros contratiempos puede llevar a mucho tiempo de inactividad mientras estas bases de datos se recrean: Stellar Core tardaría un tiempo en ponerse al día con el ledger actual desde cero, y Horizon tardaría aún más tiempo en reingestionar toda la historia de la red de nuevo.
• Escalar era difícil: debido a que Horizon y Stellar Core estaban estrechamente acoplados, si querías más instancias de Horizon, necesitabas más instancias de Core. Esto hacía más difícil construir un clúster de producción serio.
• Naturalmente, los altos requisitos de procesamiento y grandes bases de datos requerían requisitos de sistema más altos para los servidores: más espacio en disco, más potencia de procesamiento, etc.

Todas estas limitaciones se han resuelto con la introducción de Horizon 2.0. Afortunadamente, eso fue entonces, y esto es ahora:

La belleza de la nueva arquitectura modular es que presenta configuraciones más simples que pueden adaptarse a todo tipo de casos de uso:

• Con una versión optimizada de Stellar Core (llamada Captive Core) que puede procesar ledgers enteramente en memoria y comunicarse a través de mecanismos de OS de alto ancho de banda (tubos y sockets), ya no hay una base de datos Core separada que mantener.
• La ingestión es ultrarrápida: lo que solía tomar semanas incluso en hardware de gama alta ahora se puede completar en poco más de un día. Esto es otra mejora sobre anteriores mejoras de rendimiento de ingestión. Eso significa que perder una base de datos de Horizon por corrupción o necesitar reingestionar la historia completa después de una actualización ya no es un gran problema.
• Dado que Horizon sabe exactamente lo que necesita de Core y puede gestionar la vida útil de su instancia por completo, en realidad genera stubs de configuración para la mayoría de los campos necesarios, permitiéndote proporcionar el mínimo indispensable y centrarte en tu caso de uso.
• Escalar un despliegue de producción de Horizon 2.0 es mucho más fácil con Captive Core. Cada pieza se puede escalar de forma independiente: puedes tener cualquier número de instancias orientadas a la ingestión paralela, envío de transacciones o simplemente manejo de solicitudes. Dado que el último punto es una operación de solo lectura, las instancias de servicio de solicitudes están completamente desacopladas de las instancias de base de datos, permitiendo que estas últimas se escalen y repliquen por su cuenta.
• Además, mientras que la presentación de transacciones aún se puede hacer a través de una instancia de Stellar Core independiente, agrupar Captive Core a cada nodo de Horizon en su lugar añade mucha resiliencia; hay un menor riesgo de que fallos de nodos derriben un clúster.

Aunque desplegar un nodo completo de Stellar Core todavía puede ser un proceso involucrado, la introducción de Captive Stellar Core te permite centrarte casi enteramente en desplegar Horizon en sí, permitiéndote participar en la red sin asumir la responsabilidad completa de la gestión del consenso.

Flexibilidad

A diferencia de seleccionar un Pokémon inicial, cambiar de opinión sobre tu arquitectura no es difícil después del hecho. Si de repente te encuentras invertido en la descentralización de la red y quieres ejecutar un validador, la instancia de Stellar Core independiente se puede desplegar de forma independiente mientras tu instancia de Captive Core continúa trabajando con Horizon. Lo inverso también es cierto: si estás ejecutando un validador y decides que ejecutar Horizon es todo lo que te importa, todo lo que se necesita es un poco de reconfiguración para introducir la instancia de Captive Core y disfrutar de los beneficios de rendimiento y arquitectónicos que proporciona.

Requisitos del sistema

Como ya se mencionó, los requisitos del sistema difieren de versiones arquitectónicas anteriores en gran medida debido a los cambios en cómo Stellar Core interactúa con Horizon. Específicamente, la base de datos en memoria requiere alrededor de 3 GiB de RAM, y los requisitos de espacio en disco han disminuido significativamente (de nuevo, por cientos de gigabytes).

Como siempre, una máquina más potente resulta en una ingestión más rápida, pero vale la pena mencionar que después de una ingestión inicial, mantenerse “en línea” es mucho menos intensivo en recursos. Además, es raro que una organización realmente necesite la historia completa del ledger, y por lo tanto puede conformarse con ingerir rangos mucho más pequeños de metadatos de transacciones.

Horizon 2.0 introduce beneficios masivos de rendimiento y arquitectura que hacen que ejecutar la infraestructura de Stellar sea más fácil que nunca:

• El optimizado Captive Stellar Core puede procesar transacciones en memoria, lo que significa…
• ¡Los requisitos de espacio en disco se han reducido enormemente (por 100s de GBs)!
• La ingestión es ahora órdenes de magnitud más rápida (semanas -> un día), lo que significa…
• ¡La base de datos de Horizon ya no es preciosa: se puede reconstruir rápidamente!
• No hay una instancia de Stellar Core separada que gestionar, lo que significa…
• ¡No más requisitos de base de datos para Stellar Core!

¿Emocionado con estos cambios? Consulta la guía de migración para empezar hoy mismo!