📚 课程目录第3章云化部署基础环境准备

3. 云化部署基础环境准备

MongoDB 云化部署的第一步不是安装数据库，而是把承载它的基础环境规划清楚。基础环境决定了后续副本集能否稳定选主、分片集群能否水平扩展、备份恢复能否满足 RPO/RTO。本节围绕云主机、容器、Kubernetes、网络与存储五个层面，说明规划时真正需要确定的参数与配置要点。

一、云主机：从“能跑”到“跑得稳”

MongoDB 对云主机的核心诉求是稳定的计算、充足的内存和可预期的磁盘 IO。规划时先确定三件事：规格、数量、放置策略。

规格上，MongoDB 官方建议生产环境单节点内存不低于 8GB，副本集节点建议 16GB 起步；WiredTiger 默认使用约 50% 可用内存作为缓存，剩余内存留给连接、排序和聚合。CPU 方面，副本集 4～8 vCPU 可满足多数中等负载，分片集群的 mongos 与 config server 可适当降低。磁盘必须使用 SSD 云盘，容量按“数据量 × 1.5～2 倍”预留，因为 WiredTiger 的 journal、oplog 和索引会额外占用空间。

数量与放置上，副本集至少 3 个数据节点，且应分布在不同可用区（AZ），避免单 AZ 故障导致多数派丢失。以三节点副本集为例，可规划为 AZ-A 主节点、AZ-B 从节点、AZ-C 仲裁或从节点。分片集群还需额外规划 config server（3 节点副本集）和 mongos（2 个以上，无状态）。

# 示例：三节点副本集云主机规划（示例参数，非实测）
节点      角色      AZ     规格            系统盘   数据盘
mongo-1   PRIMARY   az-a   8vCPU/32GB      100GB    500GB SSD
mongo-2   SECONDARY az-b   8vCPU/32GB      100GB    500GB SSD
mongo-3   SECONDARY az-c   8vCPU/32GB      100GB    500GB SSD

二、容器：镜像、资源限制与持久化

容器化部署 MongoDB 时，镜像应选择官方 mongo 或 mongodb-enterprise 镜像，并固定版本标签（如 mongo:7.0），避免 latest 带来的不可复现问题。容器内运行 MongoDB 需要关注三点：

资源限制：通过 --memory 和 --cpus 限制容器资源，但要注意 WiredTiger 缓存会按容器可见内存计算，限制过低会导致缓存不足。
持久化：数据目录 /data/db 必须挂载到持久卷，不能使用容器可写层。
启动参数：副本集需传入 --replSet，分片节点需传入 --shardsvr 或 --configsvr。

docker run -d --name mongo-1 \
  --memory 24g --cpus 6 \
  -v /data/mongo/db:/data/db \
  -v /data/mongo/keyfile:/etc/mongo/keyfile:ro \
  mongo:7.0 --replSet rs0 --bind_ip_all \
  --keyFile /etc/mongo/keyfile

这里 --memory 24g 是示例值，实际应结合宿主机内存与同机其他容器综合确定，避免内存超卖引发 OOM。

三、Kubernetes：Operator 与 StatefulSet 的选择

在 Kubernetes 上部署 MongoDB，推荐使用 MongoDB Community Operator 或 Enterprise Operator，而不是手工编写 Deployment。Operator 会自动处理副本集初始化、成员加入、TLS 证书轮换和备份。核心对象是 MongoDBCommunity 自定义资源，其中 members 指定副本集节点数，version 指定镜像版本，security 配置认证与 TLS。

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: mongo-rs
spec:
  members: 3
  version: "7.0.0"
  security:
    authentication:
      modes: ["SCRAM"]
  statefulSet:
    spec:
      volumeClaimTemplates:
      - metadata:
          name: data-volume
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 500Gi

若不用 Operator，则必须使用 StatefulSet 而非 Deployment，因为 MongoDB 节点需要稳定的网络标识（mongo-rs-0.mongo-rs）和独立的持久卷。StatefulSet 的 serviceName 要指向 Headless Service，副本集成员通过 DNS 互相发现。

四、网络：连通性、延迟与安全

网络规划要同时满足“节点互通”和“客户端可达”。副本集内部节点之间需要双向访问 27017 端口，且延迟应控制在 同区域 1ms 以内、跨区域 5ms 以内，否则心跳超时会导致误判主节点下线。跨 AZ 部署时，建议使用云厂商的低延迟内网或对等连接，避免走公网。

客户端访问方面，mongos 或副本集应通过内网负载均衡暴露，公网访问必须叠加 TLS 和 IP 白名单。Kubernetes 内部则通过 ClusterIP Service 暴露，外部通过 LoadBalancer 或 Ingress 接入。安全组规则应遵循最小开放原则：仅允许应用网段访问 27017，管理端口（如 27018、27019）仅允许运维网段。

五、存储：IOPS、容量与备份

存储是 MongoDB 云化中最容易被低估的一环。WiredTiger 的写入路径是“先写 journal，再写数据文件”，因此磁盘的顺序写和随机写 IOPS 直接决定写入吞吐。规划时建议：

IOPS：生产环境 SSD 云盘建议不低于 3000 IOPS，高写入场景（如日志、时序）建议 10000 IOPS 以上。
容量：按“业务数据 × 1.5”估算，再叠加 oplog（建议为数据量的 10%～20%）和索引空间。
备份：使用云盘快照做全量备份，配合 mongodump 或 Ops Manager 做逻辑备份；快照频率建议每日一次，保留 7～30 天。

在 Kubernetes 中，存储通过 StorageClass 和 PersistentVolumeClaim 声明。需要确认 StorageClass 的 reclaimPolicy 为 Retain，避免 PVC 删除时数据卷被一并回收。若使用本地 SSD，则需通过 local 卷和节点亲和性绑定，但会牺牲部分调度灵活性。

规划检查点：副本集节点是否跨 AZ？WiredTiger 缓存是否按容器可见内存计算？StorageClass 的回收策略是否为 Retain？安全组是否只放行了应用网段？这四项确认后，基础环境才算具备承载生产 MongoDB 的条件。

最后，基础环境准备完成后，应通过 rs.status() 确认副本集成员状态为 PRIMARY/SECONDARY，通过 db.serverStatus().wiredTiger.cache 观察缓存命中率，通过 iostat -x 1 观察磁盘 %util 是否长期高于 80%。这些指标是判断环境是否“跑得稳”的直接依据，也是后续云化部署调优的基线。