Centros de datos primario y secundario

Un exchange de criptomonedas custodia fondos de clientes y funciona de forma continua, por lo que la cuestión de qué ocurre cuando falla un centro de datos no es una nota técnica al pie, sino una decisión de negocio. Un esquema de centros de datos primario y secundario significa que la plataforma funciona en una ubicación y puede continuar, o recuperarse, desde una segunda cuando la primera deja de estar disponible. Es la diferencia entre un negocio que se detiene cuando una sola sede se apaga y uno diseñado para seguir atendiendo a los clientes durante el fallo.

La decisión se lee de forma distinta para cada lector. Para una dirección general atañe a la continuidad de los ingresos, la reputación y la confianza de clientes que esperan acceso a sus fondos en todo momento. Para una dirección técnica trata de topología, comportamiento de conmutación y los objetivos de recuperación a los que la plataforma se compromete. Para una función de cumplimiento u operaciones concierne a la resiliencia operativa, al lugar donde residen los datos y a cómo se evidencia la continuidad ante un regulador. Este artículo explica los centros de datos primario y secundario a un nivel conceptual y arquitectónico. No es una guía de instalación de infraestructura.

Qué son los centros de datos primario y secundario

Un centro de datos primario es el lugar donde un exchange funciona normalmente: la sede que atiende el tráfico de clientes, casa órdenes y registra transacciones en el día a día. Un centro de datos secundario es una sede separada preparada para asumir el relevo cuando el primario no puede atender, ya sea por un fallo de hardware, una caída de red, un incidente en la instalación o una interrupción regional más amplia. El propósito del emparejamiento es claro: no dejar ninguna sede única como punto en el que todo el negocio pueda detenerse.

El rasgo definitorio es la separación deliberada. Dos entornos en el mismo rack, o incluso en el mismo edificio, comparten demasiados riesgos para considerarse redundancia real; un incendio, un incidente eléctrico o una pérdida de conectividad puede alcanzar ambos a la vez. Las sedes primaria y secundaria se sitúan, por tanto, de modo que sea improbable que un único incidente llegue a las dos, y la plataforma se diseña para que la operación pueda pasar de una a otra de forma controlada. Cómo se implementa esa separación queda por debajo de la vista de un decisor, pero el principio es lo que importa: dos sedes que fallan de forma independiente, no dos copias que fallan juntas.

Por qué la redundancia importa para un exchange

Los exchanges están expuestos de forma inusual a las interrupciones. Los mercados se mueven al margen de que una plataforma esté disponible, los clientes esperan alcanzar sus saldos a cualquier hora, y una caída durante la volatilidad puede causar un perjuicio financiero real además del daño reputacional. A diferencia de un servicio que puede encolar el trabajo y ponerse al día después, un exchange que no puede casar órdenes ni procesar retiradas falla en su función esencial justo cuando más se le necesita.

La redundancia entre dos centros de datos responde a esto evitando que la pérdida de una sede se convierta en la pérdida del servicio. También cambia cómo se abordan los trabajos planificados, porque el mantenimiento puede realizarse en una sede mientras la otra atiende, reduciendo la necesidad de ventanas de interrupción disruptivas. El beneficio no es la mera disponibilidad como cifra; es la capacidad de mantener disponibles las funciones de custodia, negociación y liquidación a través de los sucesos que de otro modo las detendrían.

Active-passive y active-active

Hay más de una manera de operar dos sedes, y la elección moldea tanto la resiliencia como el coste. En un esquema active-passive la sede primaria atiende todo el tráfico mientras la secundaria permanece lista, mantenida al día y disponible para asumir el relevo cuando haga falta. Es más sencillo de razonar y por lo general menos costoso de operar, y su resiliencia depende de la rapidez y fiabilidad con que se produzca el cambio a la secundaria. En un esquema active-active ambas sedes atienden tráfico al mismo tiempo, de modo que un fallo retira capacidad en lugar de disponibilidad, al precio de una mayor complejidad arquitectónica y operativa.

Ningún modelo es universalmente correcto. El active-passive conviene a operadores que quieren una recuperación sólida sin la complejidad de operarlo todo en dos lugares a la vez; el active-active conviene a aquellos para quienes incluso una breve interrupción es inaceptable y que tienen la madurez de ingeniería para operarlo. Lo que importa es elegir de forma deliberada, entendiendo el equilibrio entre sencillez y continuidad, en lugar de suponer que una segunda sede ofrece por defecto una conmutación instantánea y sin fricciones.

Objetivos de recuperación: RTO y RPO

Dos cifras convierten una promesa vaga de resiliencia en un compromiso que puede diseñarse y probarse. El recovery time objective, o RTO, es cuánto tiempo el negocio acepta estar indisponible antes de que el servicio se restablezca en la sede secundaria. El recovery point objective, o RPO, es cuántos datos recientes puede aceptar perder el negocio, medido como el intervalo entre la última copia segura y el momento del fallo. Para un exchange que maneja fondos y órdenes, ambos objetivos tienden a ser exigentes, porque clientes y reguladores esperan una recuperación rápida y ninguna transacción perdida.

Estos objetivos son decisiones, no ajustes por defecto. Unas metas más estrictas exigen una sincronización más estrecha entre sedes y pruebas más rigurosas, y conllevan un coste mayor; unas metas más laxas son más baratas pero aceptan más interrupción y posible pérdida de datos. La disciplina importante consiste en fijar el RTO y el RPO de forma deliberada, en línea con lo que el negocio y sus reguladores realmente requieren, y luego demostrarlos mediante pruebas de conmutación periódicas, en vez de suponer que la sede secundaria funcionará cuando por fin se recurra a ella.

Geografía, separación y residencia de datos

Dónde se sitúa la sede secundaria es una decisión con dos dimensiones. La primera es la distancia: las sedes deben estar lo bastante separadas para que un suceso regional, como un fallo de la red eléctrica o de la conectividad, difícilmente afecte a ambas, si bien esa separación interactúa con la estrechez con que pueden mantenerse sincronizadas. La segunda es la jurisdicción, porque un exchange de criptomonedas que rinde cuentas a reguladores y clientes sobre dónde se conserva la información no puede ubicar una sede secundaria donde resulte más cómodo sin considerar la residencia de datos.

Un diseño de dos sedes permite mantener la primaria y la secundaria dentro de una jurisdicción elegida, como una región del Reino Unido o un Estado miembro concreto de la Unión Europea, de modo que la resiliencia no se logre a costa de los compromisos de residencia. Conviene ser preciso aquí: alojar datos en un lugar dado no hace por sí solo conforme a una plataforma, y la redundancia geográfica no satisface por sí sola las obligaciones de protección de datos. Separación y residencia son insumos de una buena gobernanza, y un despliegue dedicado da a un operador el control para tomar ambas decisiones de forma deliberada, en lugar de heredarlas de una plataforma compartida.

Operar un conjunto de dos sedes

Operar dos centros de datos es más que poseer una segunda ubicación; es un compromiso operativo. Mantener la secundaria al día, monitorizar ambas sedes, ensayar la conmutación, verificar las copias de seguridad y mantener los runbooks que rigen un cambio son responsabilidades continuas, asumidas por un equipo interno o mediante un acuerdo gestionado con un proveedor. Una segunda sede aprovisionada y luego descuidada se desalinea de la primaria y ofrece un consuelo falso en vez de una protección real.

Aquí se aplica un principio conocido: no compre solo software. Compre el proceso que lo hace funcionar. Una infraestructura redundante ofrece continuidad solo cuando una operación competente la respalda, ejercitando la vía de conmutación con la frecuencia suficiente para confiar en ella. La ingeniería detallada de esa operación queda fuera de la vista de un decisor, pero el requisito no: un segundo centro de datos y una manera creíble de operarlo y probarlo son dos mitades de la misma decisión, no adquisiciones separables.

Expectativas en el Reino Unido y la UE

El diseño de centros de datos se cruza directamente con las expectativas regulatorias en los mercados centrales de Grumpio. En el Reino Unido, la resiliencia operativa, el safeguarding y el registro exacto son expectativas para las empresas que manejan criptoactivos, y el registro conforme a las Money Laundering Regulations es una puerta de entrada en materia de delito financiero, no una autorización completa. El futuro régimen FSMA para criptoactivos eleva aún más el listón, y un operador capaz de evidenciar una recuperación probada entre sedes primaria y secundaria queda mejor situado ante las expectativas de resiliencia que uno que depende de una única ubicación de la que no puede dar plena cuenta.

En la Unión Europea el marco está asentado. La transición de MiCA ha terminado. Los nuevos proyectos de criptoactivos de la UE deben diseñarse desde el principio para un modelo operativo de CASP autorizado, y DORA fija expectativas de resiliencia operativa digital, incluidas la continuidad de negocio, la recuperación y la gestión del riesgo de TIC y de terceros. No emitimos dictámenes jurídicos ni garantizamos autorizaciones. Implementamos los requisitos regulatorios y de auditoría en la tecnología, la infraestructura y las operaciones. Un diseño primario y secundario puede respaldar las obligaciones de continuidad y resiliencia, pero no las satisface por sí solo; las pruebas, los registros y la gobernanza a su alrededor son lo que convierte la arquitectura en evidencia.

Diseñar la topología adecuada

La topología adecuada se sigue de la tolerancia del operador a la interrupción, de su contexto regulatorio y de su disposición a asumir complejidad operativa. Un operador que busca autorización con necesidades de continuidad exigentes puede justificar un diseño active-active en dos sedes apropiadas a la jurisdicción; un operador más pequeño puede quedar bien servido por un esquema active-passive probado; y un piloto inicial mínimo puede empezar razonablemente con una sede única y un plan claro para añadir redundancia a medida que crece. El error es dejar la pregunta sin plantear hasta que una caída la imponga.

Las preguntas que hacer a cualquier proveedor se siguen de esto. ¿Están las sedes realmente separadas de modo que fallen de forma independiente? ¿Cuáles son el RTO y el RPO, y cómo se prueban y evidencian? ¿Es el esquema active-passive o active-active, y qué implica una conmutación real? ¿Dónde se sitúan las sedes, y respeta eso las obligaciones de residencia? Para una visión más amplia de cómo el despliegue y la resiliencia encajan en la plataforma en su conjunto, los resúmenes de software de exchange de criptomonedas y tecnología aportan el contexto circundante.

Resumen y próximos pasos

Los centros de datos primario y secundario eliminan cualquier sede única como punto en el que un exchange de criptomonedas pueda detenerse, mediante una separación deliberada, un modelo active-passive o active-active elegido y unos objetivos de recuperación fijados y probados en lugar de supuestos. La geografía y la residencia de datos determinan dónde se sitúan las sedes, y el diseño cumple su promesa solo cuando una operación creíble mantiene la secundaria lista y demuestra la vía de conmutación. Elegido de forma deliberada, un conjunto de dos sedes es un cimiento de continuidad y resiliencia más que un coste que minimizar. Las expectativas propias de cada región se exponen en las páginas de preparación para el Reino Unido y la Unión Europea.