vitya
4837fb32c8
git-subtree-dir: .tmp-concepts git-subtree-mainline:98bcc37d32git-subtree-split:c727aaa1b6
112 lines
7.1 KiB
Markdown
112 lines
7.1 KiB
Markdown
---
|
||
title: Future Resilient Architecture — цели на потом
|
||
type: concept
|
||
tags: [planning, architecture, resilience, roadmap, todo]
|
||
sources: [../sources/nas-recovery-session-2026-05-18.md]
|
||
updated: 2026-05-19
|
||
---
|
||
|
||
# Future Resilient Architecture
|
||
|
||
Placeholder для глобальной задачи "выстроить отказоустойчивую архитектуру" — обсуждается **после** того как recovery полностью устаканится.
|
||
|
||
Эта страница — **черновик целей**, не план. По ходу обсуждения распилится на специфичные концепты + ADR (architectural decision records).
|
||
|
||
## Что сейчас не так
|
||
|
||
См. [[recovery-architecture-snapshot]] → раздел "Single Points of Failure". Кратко:
|
||
|
||
- ⚠️ Windows-PC = SPOF
|
||
- ⚠️ Один public IP
|
||
- ⚠️ Один MSSQL primary без replica
|
||
- ⚠️ Один MinIO single-node
|
||
- ⚠️ Backup только Hyper Backup на одну синку (Kreknin), сейчас она cold
|
||
- ⚠️ Backup нового рабочего состояния (CMS data на recovery-host) **отсутствует**
|
||
- ⚠️ Нет off-site backup (cloud)
|
||
|
||
## Цели верхнего уровня
|
||
|
||
1. **RTO** (Recovery Time Objective) — сколько максимум **downtime** клиенты должны видеть при отказе.
|
||
- Текущий по факту: ~15 часов (что и было).
|
||
- Целевой: **< 1 час** для одиночного отказа, **< 4 часов** для каскадного.
|
||
2. **RPO** (Recovery Point Objective) — сколько максимум **данных потерять** при отказе.
|
||
- Текущий: до 24 часов (если успеет бэкап после изменения) — больше если бэкап не успел.
|
||
- Целевой: **< 1 час**, в идеале continuous (replication).
|
||
3. **Стоимость** — bounded by разумным % от выручки клиентов.
|
||
4. **Operational simplicity** — никаких heroic ops по 15 часов в случае проблемы.
|
||
|
||
## Технические направления (наброски)
|
||
|
||
### Backup-стратегия 3-2-1
|
||
|
||
Стандарт: **3** копии данных, **2** разных media, **1** off-site.
|
||
|
||
- **Копия 1:** primary storage (live) на NAS / Windows-PC
|
||
- **Копия 2:** local backup target ([[kreknin-synology]] остаётся, плюс отдельный)
|
||
- **Копия 3:** **cloud off-site** — Backblaze B2 / Yandex Object Storage / AWS S3 Deep Archive / Hetzner Storage Box
|
||
- Все backups encrypted client-side
|
||
- Retention: 7 daily / 4 weekly / 12 monthly
|
||
|
||
### Compute resilience
|
||
|
||
Варианты:
|
||
|
||
A. **Multi-host on-prem:** 2-3 физических машины с виртуализацией (Proxmox VE), HA-кластер, VMотом migration. Дорого, но автономно.
|
||
|
||
B. **Cloud-first:** перенос CMS-стека в managed Kubernetes (Yandex Cloud / VK Cloud / hetzner) — managed MSSQL / managed S3 / managed Postgres. Простота операций, но vendor lock-in.
|
||
|
||
C. **Гибрид:** primary on-prem (Synology с CMR), warm standby в cloud (готовый к failover за 5 мин). Compromise.
|
||
|
||
### Database resilience
|
||
|
||
MSSQL options:
|
||
- **Always On Availability Groups** (требует Enterprise license — недёшево)
|
||
- **Log Shipping** (бесплатно, но manual failover)
|
||
- **MSSQL → PostgreSQL миграция?** (если есть полная свобода — выгоды Open Source + распространённые managed предложения).
|
||
|
||
Для recovery-сценария: **continuous backup** через VDI + native MSSQL TDE backup → S3.
|
||
|
||
### Network resilience
|
||
|
||
- **Multi-WAN на OpenWRT:** primary провайдер + 4G/LTE USB-modem как failover. OpenWRT mwan3 package.
|
||
- **Cloudflare Proxy / Tunnel:** перенаправление публичного трафика через Cloudflare edge. Помогает с DDoS и переключением IP без DNS-changes.
|
||
- **Static IP пересмотр:** разные провайдеры → multi-homed setup.
|
||
|
||
### Monitoring + auto-recovery
|
||
|
||
- **Healthchecks** на каждый layer (TCP, HTTP, deep DB query) — Prometheus + Alertmanager или Uptime Kuma.
|
||
- **Watchdog скрипты** — auto `ipconfig /release/renew` в VM, auto `docker compose restart` контейнера если healthcheck падает > N min.
|
||
- **Telegram-уведомления** на инциденты (для пользователя в реал-тайм когда что-то фейлится).
|
||
|
||
### Документация и runbook
|
||
|
||
- Runbook на каждый процедурный сценарий (failover, restore, network swap).
|
||
- Регулярные **failover drills** раз в квартал — буквально нажать "восстановиться" и засечь время.
|
||
- Wiki эта — стартовая точка.
|
||
|
||
## Что НЕ цели
|
||
|
||
- Перестройка с нуля «потому что сейчас не идеально». Текущая архитектура работает, замена должна быть инкрементальной.
|
||
- 99.99% uptime — нереалистично для one-person infrastructure, и не нужно для CMS-сайтов клиентов.
|
||
|
||
## Следующие шаги (когда дойдут руки)
|
||
|
||
1. Заменить WD40EFAX на CMR-диски, пересобрать пул [[dead-synology-diskstation]].
|
||
2. Включить ежедневный Hyper Backup из нового пула на [[kreknin-synology]].
|
||
3. Добавить cloud-backup target (Yandex Object Storage наиболее очевидный для RU-юрисдикции).
|
||
4. Настроить monitoring/alerts.
|
||
5. Документировать runbooks.
|
||
|
||
Связано со всеми остальными страницами этого wiki.
|
||
|
||
## Прогресс 2026-05-20
|
||
|
||
✅ **Decouple инфра-сервисов от windows-recovery-host SPOF.** Поднят отдельный облачный VDS [[vds-kzntsv]] (Rusonyx 160 NVMe), туда мигрированы gitea / verdaccio / docker-registry + shared DB park (Postgres/MariaDB/Mongo/Redis). [[windows-recovery-host]] теперь хостит **только** production CMS. Это не полный multi-host resilience (VDS сам по себе SPOF), но critical infra decoupling сделан.
|
||
|
||
Запланированы follow-up tasks (см. `.tasks/`):
|
||
- `vds-backup-rsync-kreknin` — ежедневный 05:00 MSK rsync VDS → kreknin с email-нотификацией.
|
||
- `vds-ntfy-push` — self-hosted push на Android для backup status и monitoring.
|
||
- `vds-gc-cron` — cron GC для verdaccio + registry чтобы не повторился incident 99G на registry.
|
||
|
||
Следующая фаза по originally outlined ladder — добавить **cloud off-site backup target** (Backblaze B2 / Yandex Object Storage) поверх kreknin'а, и replicated MSSQL для production CMS.
|