私有镜像仓库高可用需分层设计：存储层用minio/s3等对象存储解耦，应用层harbor多实例+patroni/redis cluster，接入层keepalived/vip+健康检查，客户端配置registry-mirrors降级，跨地域通过镜像复制实现地理冗余。
存储层必须与应用层解耦
本地磁盘存储是高可用的最大隐患。Harbor 或 Registry 本身不负责持久化，所有镜像数据应统一写入外部对象存储：
- 推荐 MinIO（自建）或 AWS S3 / 阿里云 OSS（云环境），启用版本控制和跨区域复制
- MinIO 部署建议至少 4 节点+纠删码（如 4+2），可容忍 2 节点同时宕机仍保证数据可读可写
- Harbor 配置中禁用 local filesystem，明确指定 storage_driver.s3 或 storage_driver.minio 参数
- 避免使用 NFS 或 Ceph RBD 等块/文件存储——它们引入额外故障点且难以跨 AZ 扩展
应用层做多实例+状态分离
Harbor 的核心组件（core、jobservice、registry、portal）需拆分部署，数据库与缓存不能共用单点：
- PostgreSQL 建议采用 Patroni + etcd 实现自动主从切换，至少 3 节点集群
- Redis 推荐 Redis Cluster 模式（6 节点以上），避免哨兵模式在脑裂时的写丢失风险
- Harbor 实例本身无状态，可水平扩展；通过负载均衡器（如 Nginx 或 HAProxy）分发请求
- 关闭 Harbor 内置的 Clair 和 Trivy 扫描服务（除非有专用扫描节点），防止资源争抢影响 registry 响应
接入层保障流量连续性
用户访问入口一旦中断，整个仓库就“不可见”。这里的关键是快速感知+无感切换：
- 前端用 Keepalived + VIP 或云厂商 SLB（如阿里云 ALB），健康检查粒度设为 registry API 的 /api/v2.0/health 端点
- DNS 层建议配置 TTL ≤ 60 秒，并配合 Service Mesh（如 Istio）做更细粒度的流量调度
- 客户端 Docker daemon 需预置 fallback 配置：例如在 /etc/docker/daemon.json 中设置 { "registry-mirrors": ["https://mirror.internal"] }，当主仓库不可达时自动降级到只读镜像缓存节点
地理冗余与自动同步
单数据中心再高可用，也扛不住机房级故障。跨可用区或跨地域部署是金融、政企类场景的硬性要求：
- 主中心 Harbor 启用“镜像复制”功能，目标端指向异地 Harbor 实例，策略设为“推送触发+增量同步”
- 复制任务失败时自动告警（集成 Prometheus Alertmanager），并保留最近 3 次失败日志供排查
- 异地节点默认设为只读，仅在主中心完全不可用时，通过 DNS 切换或手动修改 VIP 指向启用写入
- 注意镜像签名（Notary）密钥需统一管理，避免因密钥分散导致异地镜像校验失败
