HI-VPN/hi-server
4
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

chore: snapshot current aws standby and backup tooling work

Browse Source
This commit is contained in:
shanshanzhong
2026-05-13 10:59:03 -07:00
parent c4b2ebf7e1
commit f6911965dc
31 changed files with 1626 additions and 12482 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ops/hifast-aws-standby-architecture-zh.md
+297 -39
View File
@@ -10,6 +10,47 @@
- MySQL / Redis 的同步关系是什么
- 故障时应该如何切换
## 0. 2026-05-13 验收摘要
- 已确认 `104.238.220.230 -> AWS RDS MySQL` 连通，MySQL 外部从库健康：
- 当前复制上游：`hifast-mysql-prod-v2.cd6aey40m6ag.ap-east-1.rds.amazonaws.com`
- `Replica_IO_Running: Yes`
- `Replica_SQL_Running: Yes`
- `Seconds_Behind_Source: 0`
- 已确认 `104.238.220.230 -> AWS EC2 Redis` 主从健康：
- `104` 上 `role:slave`
- `master_link_status:up`
- AWS Redis 主库 `connected_slaves:1`
- 已修复应用侧 Redis 配置漂移：
- 旧链路：`127.0.0.1:6380 -> stunnel4 -> 旧 ElastiCache`
- 新链路：`127.0.0.1:6379 -> 本机 Docker Redis`
- 旧 `stunnel4` 已停用并禁用自启，`ppanel-server` 日志里的 Redis `i/o timeout` 已停止出现。
- 已确认 `ppanel-server` 当前运行方式为 Docker Compose 容器，而不是 systemd 服务：
- Compose 文件：`/opt/ppanel/docker-compose.cloud.yml`
- 配置文件：`/opt/ppanel/configs/ppanel.yaml`
- 容器名：`ppanel-server`
- 健康检查：`curl http://127.0.0.1:8080/v1/common/heartbeat` 返回正常
- 旧自建安全组 `hifast-hk-app-sg`、`hifast-hk-nginx-sg` 已删除；当前 VPC 内仅保留：
- `hifast-hk-app-core-sg`
- `hifast-hk-rds-core-sg`
- `hifast-hk-web-sg`
- `default`
- 目前已经达到“可用且关键链路已恢复”的状态。
- 当前入口层属于已确认的过渡方案：
- 现阶段公网入口仍在 `hifast-hk-app-01`
- 独立 `nginx` 服务器已预留，待 AWS 后续资源到位后再迁移承接
- 当前仍需要继续收敛的核心生产项只剩 1 个：
- RDS 为了让 `104` 走公网白名单复制，当前仍依赖 `hifast-hk-private-1b` 子网临时挂到公网路由表，这不是最终规范形态。
- 已完成的下一步准备：
- 已创建纯公网子网专用的 `DB subnet group`：`hifast-hk-rds-public-only-sgprep`
- 子网包含：
- `subnet-070e3f264a9c79f32` `hifast-hk-public-1a`
- `subnet-00cb5add705c447c8` `hifast-hk-public-1b`
- 已创建专用 S3 备份桶：
- `hifast-prod-backups-200810848252-ap-east-1`
- 当前状态：private
- 当前状态：versioning enabled
## 1. 当前实际环境
### 1.1 AWS 区域
@@ -23,15 +64,37 @@
- 名称：`hifast-hk-app-01`
- Instance ID: `i-079cd9d3ef3748714`
- 角色：应用机 / Nginx / 业务服务 / AWS 侧 Redis 主库宿主机
- 角色：当前实际生产入口 / Nginx / 业务服务 / AWS 侧 Redis 主库宿主机
- 私网 IP: `10.0.1.201`
- 公网 IP: `43.198.248.161`
- 业务服务运行方式：`Docker Compose`
- 业务容器：`ppanel-server`
- 部署目录：`/opt/ppanel`
- 实际配置文件：`/opt/ppanel/configs/ppanel.yaml`
#### 独立 Nginx 服务器
- 名称：`hifast-hk-nginx-01`
- Instance ID: `i-0701d54bf2c6bf594`
- 角色：计划中的独立入口机
- 私网 IP: `10.0.1.175`
- 当前状态：`stopped`
- 当前说明：已经只绑定 `hifast-hk-web-sg`，但目前并未承接正式流量
#### MySQL 主库
- 类型：`AWS RDS MySQL`
- 实例名：`hifast-mysql-prod`
- 实例名：`hifast-mysql-prod-v2`
- Endpoint: `hifast-mysql-prod-v2.cd6aey40m6ag.ap-east-1.rds.amazonaws.com`
- 角色：生产主库
- Engine: `MySQL 8.4.8`
- Publicly accessible: `Yes`
- Multi-AZ: `No`
- Backup retention: `7 days`
- Deletion protection: `On`
- 当前数据库实际体量：约 `187.41 MB`
- 当前表数量：`37`
- 当前 `user` 表记录数：`45076`
#### Redis 主库
@@ -41,6 +104,8 @@
- 版本：`redis:8.2.1`
- 访问端口：`6379`
- 主库出口地址：`43.198.248.161:6379`
- 应用当前实际连接：`127.0.0.1:6379`
- 认证方式：已启用密码认证
#### 外部备用服务器
@@ -48,10 +113,18 @@
- OS: `Ubuntu 24.04 LTS`
- 角色：异地备用节点
- 当前状态：已部署与 AWS 相同的业务服务
- 当前 MySQL 状态：外部只读从库
- 当前 Redis 部署方式：`宿主机原生安装`
- 当前 Redis 版本：`8.6.3`
- 当前 Redis 角色：`AWS Redis 主库的从库`
#### S3 备份桶
- Bucket: `hifast-prod-backups-200810848252-ap-east-1`
- Region: `ap-east-1`
- Public access: blocked
- Versioning: enabled
## 2. 架构总览
```mermaid
@@ -59,7 +132,7 @@ flowchart TB
USER["用户 / 客户端"] --> DNS["域名 / DNS / 入口层"]
DNS --> APP["AWS EC2\nhifast-hk-app-01\n43.198.248.161\n10.0.1.201"]
APP --> RDS["AWS RDS MySQL\nhifast-mysql-prod\n主库"]
APP --> RDS["AWS RDS MySQL\nhifast-mysql-prod-v2\n主库"]
APP --> REDISM["AWS Redis 主库\nDocker redis:8.2.1\n43.198.248.161:6379"]
RDS -. MySQL 备用 / 同步 .-> MYSQLS["104.238.220.230\nMySQL 备用库"]
@@ -87,8 +160,10 @@ flowchart TB
说明：
- 当前主应用入口在 AWS EC2。
- EC2 同时承担业务服务入口。
- 当前主应用入口实际在 `hifast-hk-app-01`。
- `hifast-hk-app-01` 同时承担 Nginx、业务服务、Redis 主库。
- 当前业务服务不是 systemd 单进程部署，而是由 `/opt/ppanel/docker-compose.cloud.yml` 管理的 `ppanel-server` 容器提供 `8080`。
- 独立入口机 `hifast-hk-nginx-01` 已存在，但当前仅作为后续资源开通后的迁移目标。
- MySQL 在 AWS RDS。
- Redis 不在 ElastiCache，而是在 EC2 本机通过 Docker 提供。
@@ -118,43 +193,187 @@ App / Nginx
## 4. 网络与安全边界
### 4.1 EC2 安全组
### 4.1 当前安全组
- 安全组名称：`hifast-hk-app-sg`
- 安全组 ID: `sg-09266fb27bde15714`
截至 `2026-05-13`，VPC `vpc-09fc384522517debc` 内仅保留 4 个安全组：
已确认规则：
- `default`
- `hifast-hk-app-core-sg`
- `hifast-hk-rds-core-sg`
- `hifast-hk-web-sg`
- Redis `6379/tcp`
- 来源：`104.238.220.230/32`
其中绑定关系已经收敛为：
这条规则的作用是：
- `hifast-hk-app-01` -> `hifast-hk-app-core-sg`
- `hifast-hk-nginx-01` -> `hifast-hk-web-sg`
- `hifast-mysql-prod-v2` -> `hifast-hk-rds-core-sg`
- 允许外部备用服务器 `104.238.220.230` 连到 AWS Redis 主库
- 避免 Redis 对全网开放
旧组：
### 4.2 Redis 网络关系
- `hifast-hk-app-sg`
- `hifast-hk-nginx-sg`
已经删除，不再使用。
### 4.2 当前入站规则
#### `hifast-hk-app-core-sg`
- `22/tcp <- 0.0.0.0/0`
- `6379/tcp <- 104.238.220.230/32`
- `8080/tcp <- hifast-hk-web-sg`
#### `hifast-hk-rds-core-sg`
- `3306/tcp <- 104.238.220.230/32`
- `3306/tcp <- hifast-hk-app-core-sg`
#### `hifast-hk-web-sg`
- `22/tcp <- 0.0.0.0/0`
- `80/tcp <- 0.0.0.0/0`
- `443/tcp <- 0.0.0.0/0`
### 4.3 Redis 网络关系
```mermaid
flowchart LR
SG["EC2 Security Group\nsg-09266fb27bde15714"] --> REDIS["AWS Redis 主库\n43.198.248.161:6379"]
SG["hifast-hk-app-core-sg"] --> REDIS["AWS Redis 主库\n43.198.248.161:6379"]
STANDBY["104.238.220.230/32"] --> SG
```
### 4.3 RDS 访问原则
### 4.4 RDS 访问原则
RDS 不应该对公网全开放。
RDS 当前状态已经比之前干净很多：
推荐且已执行过的方向是：
- 只对白名单源 IP 开放 `3306`
- 如果 `104.238.220.230` 需要做外部从库，则只放行这个 IP
- 当前只对白名单和应用安全组开放 `3306`
- 已移除 `3306 <- 0.0.0.0/0`
- 当前 RDS 仅绑定 `hifast-hk-rds-core-sg`
建议原则：
- 不开放 `0.0.0.0/0` 到 MySQL `3306`
- 不开放 `0.0.0.0/0` 到 Redis `6379`
### 4.5 当前仍需继续收敛的网络点
#### 4.5.1 入口层当前属于过渡方案，不作为本阶段阻塞项
当前运行形态是：
- `hifast-hk-app-01` 本机 `nginx` 正在监听 `80/443`
- `hifast-hk-nginx-01` 当前停止
但当前安全组设计是按“独立 nginx 机”拆的：
- `hifast-hk-web-sg` 在 `hifast-hk-nginx-01`
- `hifast-hk-app-core-sg` 在 `hifast-hk-app-01`
这意味着当前真实入口和安全组角色划分还没有完全一致。
但这一点已经被确认为过渡设计，不作为当前阶段必须整改的问题。后续待 AWS 新资源到位后，再把公网入口迁到独立 `nginx` 服务器即可。
#### 4.5.2 RDS 公网复制链路仍是当前唯一核心结构性问题
为了让 `104.238.220.230` 通过公网白名单访问 RDS，当前实际依赖的是：
- RDS `PubliclyAccessible = true`
- RDS ENI 仍在 `subnet-0dcf46db665b6d8a7`
- 该子网名称是 `hifast-hk-private-1b`
- 但这个子网当前被临时关联到了公网路由表
这能用，但不属于最终规范的“纯公网子网组”设计。
本轮已经额外完成的准备动作：
- 已新建纯公网 `DB subnet group`：`hifast-hk-rds-public-only-sgprep`
- 该组状态：`Complete`
- 该组仅包含两条公网子网：
- `hifast-hk-public-1a`
- `hifast-hk-public-1b`
当前结论：
- 不建议继续在现有生产 RDS 上反复试在线切子网组。
- 更稳的收敛方案是：新建一台使用规范公网子网组的生产 RDS，再做一次短切换。
- 由于当前库体量只有约 `187 MB`，这条路线的执行成本并不高，风险也比在现网主库上硬改更可控。
## 4.6 104 如何连接 AWS
这里要特别区分：
- `104` 连接 AWS 数据层
- 本地电脑登录 AWS EC2
这不是同一件事。
### 4.6.1 104 连接 AWS Redis 的方式
`104.238.220.230` 连接 AWS Redis，不是通过 PEM 证书，也不是通过 SSH 登录 AWS 机器，而是直接作为 Redis 从库去访问 AWS Redis 主库：
- 目标地址：`43.198.248.161:6379`
- 连接方式：`TCP`
- 认证方式：`Redis 密码`
- 网络前提：AWS EC2 安全组已放行 `104.238.220.230/32 -> 6379`
也就是说：
```text
104 Redis 从库 -> 直连 AWS Redis 主库公网地址 -> 密码认证 -> 建立复制
```
示意命令：
```bash
redis-cli -h 43.198.248.161 -p 6379 -a '<REDIS_PASSWORD>'
```
### 4.6.2 104 连接 AWS MySQL RDS 的方式
`104.238.220.230` 连接 AWS RDS，也不是通过 PEM 证书，而是通过数据库连接：
- 目标地址：`hifast-mysql-prod-v2.cd6aey40m6ag.ap-east-1.rds.amazonaws.com:3306`
- 连接方式：`MySQL TCP`
- 认证方式：`MySQL 用户名 + 密码`
- 网络前提：RDS 白名单或安全组放行 `104.238.220.230`
也就是说：
```text
104 MySQL 从库 -> 直连 AWS RDS endpoint -> 账号密码认证 -> 建立复制
```
示意命令：
```bash
mysql -h hifast-mysql-prod-v2.cd6aey40m6ag.ap-east-1.rds.amazonaws.com -u admin -p
```
### 4.6.3 本地电脑登录 AWS EC2 的方式
本地电脑这边之前进入 AWS EC2，用的不是 `hifast-hk-app-01-key.pem`，而是：
- `AWS Console`
- `EC2 Instance Connect`
- 浏览器里的 Web SSH 终端
所以当前要理解成 3 条不同链路：
1. 本地电脑 -> AWS 控制台 -> EC2 Instance Connect -> AWS EC2
2. `104` -> AWS Redis 主库公网地址 -> Redis 密码认证
3. `104` -> AWS RDS endpoint -> MySQL 用户密码认证
### 4.6.4 关键结论
当前灾备链路里，`104` 与 AWS 数据同步不依赖 `.pem` 证书文件。
真正依赖的是：
- Redis 安全组放行
- RDS 白名单 / 安全组放行
- 正确的 Redis 密码
- 正确的 MySQL 账号密码
## 5. Redis 实际部署与同步状态
### 5.1 AWS Redis 主库
@@ -186,6 +405,8 @@ RDS 不应该对公网全开放。
- 从 `104` 连接 AWS Redis 主库，认证成功
- AWS 主库写入测试键
- `104` 从库成功读取测试键
- `2026-05-13` 已确认应用机本地 `ppanel-server -> 127.0.0.1:6379` 建立稳定连接
- `2026-05-13` 已确认旧 `stunnel4 -> ElastiCache` 链路下线后，应用日志不再出现 Redis `i/o timeout`
测试键：
@@ -206,7 +427,7 @@ flowchart LR
### 6.1 主库角色
- 主库在 `AWS RDS MySQL`
- 实例：`hifast-mysql-prod`
- 实例：`hifast-mysql-prod-v2`
### 6.2 外部备用角色
@@ -215,26 +436,32 @@ flowchart LR
### 6.3 当前文档说明
Redis 的主从状态已经在本次执行中完成并验证。
MySQL 当前已经完成实际验收，不再只是“待确认”状态。
`2026-05-13` 验收结果：
- `Source_Host = hifast-mysql-prod-v2.cd6aey40m6ag.ap-east-1.rds.amazonaws.com`
- `Replica_IO_Running = Yes`
- `Replica_SQL_Running = Yes`
- `Seconds_Behind_Source = 0`
- `read_only = ON`
- `super_read_only = ON`
这表示 `104` 当前是健康的只读外部备用库。
MySQL 这部分在此前已经有专门 runbook：
- [ops/aws-rds-external-replica-runbook.md](/Users/Apple/code_vpn/vpn/ppanel-server/ops/aws-rds-external-replica-runbook.md)
如果要把 MySQL 也完全纳入同一灾备演练，需要继续确认：
- `104` 当前 MySQL 的同步线程状态
- `SHOW REPLICA STATUS\G` 是否仍然正常
- RDS 到 `104` 的白名单是否仍然保留
## 7. 当前生产方案的真实特点
这套已经落地的架构，不是传统的全 AWS 托管标准形态，而是偏实用的混合方案：
- 应用在 AWS EC2
- 应用和当前实际公网入口在 AWS 同一台 EC2
- MySQL 在 AWS RDS
- Redis 在 AWS EC2 本机
- MySQL / Redis 均向外部服务器 `104` 做灾备
- 旧 ElastiCache / stunnel 链路已经退出当前生产路径
它的优点：
@@ -348,6 +575,9 @@ redis-cli -a '<REDIS_PASSWORD>' REPLICAOF NO ONE
- AWS Redis 主库是否在线
- `104` Redis 从库是否 `master_link_status:up`
- `104` MySQL 复制是否正常
- `ppanel-server` 容器是否 `Up`
- `ppanel-server` 日志中是否再次出现 Redis `i/o timeout`
- `stunnel4` 是否保持 `inactive`
### 9.2 Redis 故障时
@@ -377,7 +607,7 @@ redis-cli -a '<REDIS_PASSWORD>' REPLICAOF NO ONE
### 10.1 当前实际方案
`DNS -> AWS EC2(App + Nginx) -> RDS MySQL + EC2 Redis -> 104 灾备`
`DNS -> hifast-hk-app-01(Nginx + App + Redis) -> RDS MySQL -> 104 灾备`
### 10.2 理想生产方案
@@ -394,11 +624,35 @@ redis-cli -a '<REDIS_PASSWORD>' REPLICAOF NO ONE
建议按优先级补齐：
1. 明确 `104` 应用接管脚本与启动检查项
2. 明确 MySQL 故障切换脚本
3. 明确 Redis 故障切换脚本
4. 明确域名 / DNS 切换方式
5. 做一次完整灾备演练
1. 把 RDS 从“private 子网挂公网路由”的临时方案，收敛成真正的公网 DB subnet group，或改成私网复制方案
2. 明确 `104` 应用接管脚本与启动检查项
3. 明确 MySQL 故障切换脚本
4. 明确 Redis 故障切换脚本
5. 明确域名 / DNS 切换方式
6. 做一次完整灾备演练
7. 待 AWS 新资源到位后，再把公网入口迁到独立 `nginx` 服务器
### 10.4 RDS 推荐收敛路线
当前原先规划的“新建规范 RDS 再切换”路线已经完成，现网主库已经是 `hifast-mysql-prod-v2`。
后续更推荐的正式路线是：
1. 继续以 `hifast-mysql-prod-v2` 作为当前生产主库
2. 确认其持续使用 `hifast-hk-rds-public-only-sgprep`
3. 安全组持续只放：
- `104.238.220.230/32 -> 3306`
- `hifast-hk-app-core-sg -> 3306`
4. 持续确认应用连接目标为 `hifast-mysql-prod-v2`
5. 持续确认 `104` 的外部复制目标为 `hifast-mysql-prod-v2`
6. 验证通过后，再安排旧 RDS 下线
这条路线的优点：
- 最终拓扑规范清晰
- 不需要继续保留“private 子网挂公网路由”的临时设计
- 对当前现网主库的扰动最小
- 当前数据库体量较小，迁移成本可控
## 11. 建议的下一版目标拓扑
@@ -423,16 +677,20 @@ flowchart TB
截至当前，已经可以确认的生产与灾备状态是：
- AWS 是主生产环境
- 应用跑在 `hifast-hk-app-01`
- 应用当前跑在 `hifast-hk-app-01`
- MySQL 主库在 AWS RDS
- Redis 主库在 AWS EC2 Docker
- `104.238.220.230` 是异地备用节点
- `104` 已部署与 AWS 相同的业务服务
- `104` 上 Redis 已切为宿主机原生安装
- `104` Redis 已成功作为 AWS Redis 主库的从库在线同步
- `104` MySQL 已恢复并保持健康复制
- 应用已经切回当前真实可用的本机 Redis 主库
- 旧 `stunnel4 -> ElastiCache` 链路已经退出生产路径
如果后续要继续完善这份方案，优先补充：
- MySQL 最终同步状态复核
- RDS 子网与公网访问模型收敛
- 入口域名 / DNS 切换细则
- 应用层在 `104` 的接管与回切执行清单
- 待资源到位后的独立 `nginx` 迁移清单