聊聊面向全球的鏡像分發網絡
1. 全球的網絡規劃
很多面向全球的多區域基礎設施，在設計之初并沒有在網絡規劃上花費太多心思。當業務復雜到一定程度時，又被逼著進行網絡調整和優化。而任何網絡上的大調整，都將對業務產生巨大影響。最終會陷入進退兩難之地，只能投入更多人力，背上歷史包袱，一次又一次行走于懸崖之顛。
如下圖是我認為比較理想的一種網絡拓撲:
網絡規劃主要有如下幾點:
- 網段劃分
在面向全球的業務形態下，網絡被割裂為兩部分: 海外和中國內地。我更傾向于建立兩個中心，國內的核心節點設置在北京，主要面向國內業務;海外的核心節點設置在新加坡，主要面向海外業務。
因此將 10.128.0.0/16 及以上網段劃分給海外，10.127.0.0/16 及以下劃分給國內。同時，每個區的網段之間相隔 8，預留一定的擴展空間。
- 實現連通
如果是同一個 VPC，那么內網是可達的。但是如果是不同 VPC、不同的廠商、不同的區域之間，我們通常會借助一定的方法實現連通：公網或者專線。
公網是比較普適的一種方法。我們可以基于公網，搭建 VPN 內網，實現網絡連通。但是，公網的連通質量不能得到保障，因此還有一種方式就是專線。
專線能夠實現跨區域的網絡連通，但是云專線通常限于同一家云廠商。也就是說，華為云北京的云專線只能連通華為云新加坡，而不能連通 AWS 新加坡。
- 配置路由
實現連通只是相當于插上了網線，但是轉發數據包時，并不清楚 IP 包的下一跳是哪里，因此還需要配置路由。
由于設置有兩個網絡核心，海外的區域與海外的核心節點需要互通，國內的區域與國內的核心節點需要互通。至于其他各區域是否互通，需要看是否有需求。比如，我們需要在內網進行鏡像數據的 P2P 分發，那么就需要各區域也互通。
2. 建設全球鏡像分發能力
全球的鏡像分發能力是建立在全球 IDC 內網互通的前提下的。我們不能讓基礎設施暴露于公網之上，全部的鏡像數據都是通過內網流量進行傳輸的。
如下圖是一個全球鏡像分發系統:
我們的研發部門在國內，而部署的服務遍布全球。鏡像數據的流轉會經過以下流程:
- 國內構建鏡像并推送到國內的 Habor 中。
- 國內 Habor 同步鏡像到海外的 Habor 中。
- 在某個區域，部署海外的應用，拉取鏡像。
- 由于每個 Docker 中都配置了 Dget 的地址作為 registry-mirrors，應用鏡像被緩存到 Dget 中。
- 在同一個區域，多個副本部署時，都將直接拉取 Dget 中的鏡像。
3. Habor 的部署與高可用
3.1 部署 Habor
Harbor 部署主要有兩種方式 Helm Chart 和 Docker Compose。這里推薦的是 Docker Compose，因為作為一個不會頻繁變更、穩定性要求高的服務，VM 比 Kubernetes 更適合作為 Habor 的基礎設施。
3.2 高可用 Harbor
Harbor 的高可用主要有兩種方式:
- 共享存儲。一致性高，需要部署雙活\主備的存儲后端。
- 多 Harbor 之間同步。一致性不高，鏡像同步需要時間。
我建議采用的方案是共享存儲，不想等待 Harbor 同步完成，推送完的鏡像即可用。如下圖，共享存儲方案下，需要以雙活\主備的形式部署存儲組件:
這里需要共享的組件有:
- 共享 PGSQL
可以直接購買云廠商的服務，然后初始化創建表。
CREATE DATABASE notary_server;
CREATE DATABASE notary_signer;
CREATE DATABASE harbor ENCODING 'UTF8';
CREATE USER harbor;
ALTER USER harbor WITH ENCRYPTED PASSWORD '123456';
GRANT ALL PRIVILEGES ON DATABASE notary_server TO harbor;
GRANT ALL PRIVILEGES ON DATABASE notary_signer TO harbor;
GRANT ALL PRIVILEGES ON DATABASE registry TO harbor;
GRANT ALL PRIVILEGES ON DATABASE harbor TO harbor;
GRANT ALL PRIVILEGES ON DATABASE clair TO harbor;
external_database:
harbor:
host: 1.1.1.1
port: 5432
db_name: harbor
username: harbor
password: 123456
ssl_mode: disable
max_idle_conns: 10
max_open_conns: 100
notary_server:
host: 1.1.1.1
port: 5432
db_name: notary_server
username: harbor
password: 123456
ssl_mode: disable
max_idle_conns: 10
max_open_conns: 30
notary_signer:
host: 1.1.1.1
port: 5432
db_name: notary_signer
username: harbor
password: 123456
ssl_mode: disable
max_idle_conns: 10
max_open_conns: 30
- 共享 Redis
Harbor 的 Redis 主要存儲的是會話 Session 信息，會影響到 Harbor UI 頁面的登錄。如果對可用性要求不太高，可以使用自建的 Redis 實例，因為即使 Redis 的存儲數據丟失，對 Harbor 的數據完整性沒有影響。
- 共享 S3 對象存儲
我使用的是華為 OBS 對象存儲，這里的 AKSK 需要給 full 權限。
storage_service:
s3:
accesskey: xxx
secretkey: xxx
region: ap-southeast-3
regionendpoint: https://obs.ap-southeast-3.myhuaweicloud.com
bucket: xxx
encrypt: false
secure: true
v4auth: true
chunksize: 5242880
multipartcopychunksize: 33554432
multipartcopymaxconcurrency: 100
multipartcopythresholdsize: 33554432
rootdirectory: /registry/
如果擔心 S3 的單點問題，可以購買兩個 Bucket，相互同步鏡像數據。這樣，當其中一個 Bucket 有異常時，可以迅速切換到另外一個 Bucket 恢復服務。
4. 利用 Dragonfly 節省帶寬
為什么需要 Dragonfly 分發鏡像? 其中很大的一個原因在于節省帶寬，還有就是避免 Habor 的負載過大。
如果不使用 Dragonfly 鏡像分發，那么每次拉取鏡像都會向 Habor 請求數據。如下圖:
而采用 Dragonfly 之后，同一個區域只需要請求一次 Harbor，其他請求都可以通過區域內的流量完成。這種方式大大加快了鏡像拉取過程，節省了跨區域的帶寬，減輕了 Habor 的負載壓力。
5. 總結
最近在給業務重新規劃部署一套鏡像管理系統，本篇是相關思考和實踐的一些總結。
本文主要從網絡規劃開始，聊到全球鏡像的分發。網絡規劃主要涉及網段規劃、實現連通、配置路由三個部分。而鏡像分發主要采用的是 Habor + Dragonfly 的方案。同時，推薦的是采用共享存儲的方式部署高可用的 Harbor。
實際上，在部署完 Habor 之后，我還對各區域拉取鏡像的速度進行了測試。另外，還需要將影響 Habor 服務的依賴項配置監控，持續的改進，才能打造好的鏡像倉庫及分發系統。
6. 參考
- https://github.com/dragonflyoss/Dragonfly2
- https://github.com/goharbor/harbor
