Cutter 8
- vCPU
- 4 × dedicado
- RAM
- 8 GB
- Almacenamiento
- 160 GB NVMe SSD
- Transferencia
- 10 TB
- IPv4 / IPv6
- 1 / /64 routed
Solución
La disponibilidad real proviene de dominios de fallo independientes, no de un servidor más grande. Tres instancias en tres países con diferentes proveedores de tránsito sobreviven a eventos que ninguna máquina única puede. Presupuesta un balanceador de carga o un punto de entrada anycast, replicación síncrona dentro de la región y asíncrona entre ellas; la latencia hace que las escrituras síncronas entre regiones sean poco prácticas.
| Recurso | Lo que realmente necesita |
|---|---|
| Nodos | Tres mínimo, en tres jurisdicciones |
| Red | Mesh WireGuard; anycast disponible en regiones seleccionadas |
| Base de datos | Síncrona dentro de la región, asíncrona entre regiones |
| DNS | TTL cortos y registros de conmutación por error con comprobación de salud |
La ubicación suele ser la decisión que más importa para esta carga de trabajo, ya sea porque domina la latencia o porque domina la jurisdicción.
Ámsterdam, Ashburn y Singapur es el triángulo clásico.
WireGuard entre todos los nodos, con la aplicación escuchando solo en la malla.
Síncrona dentro de la región, asíncrona entre ellas; conoce tu RPO.
TTL cortos más un registro de conmutación por error con comprobación de salud, o anycast si está disponible.
Mata una región a propósito, un día laborable, mientras estás observando.
Tres es el mínimo práctico: dos te dan un problema de cerebro dividido en lugar de un quórum. Ponlos en tres dominios de fallo separados: diferentes países, idealmente diferentes proveedores de tránsito.
Solo si enrutas a los usuarios a su región más cercana. Multi-región para disponibilidad y multi-región para latencia son diseños diferentes que comparten hardware.
Nuestro SLA es del 99,99 % por instancia, lo que equivale a unos 4,4 minutos de inactividad al mes. Cualquier cosa más allá requiere redundancia que tú mismo construyas.