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