Multi-Site Replication trong Minio

1. Tổng quan

MinIO hỗ trợ cơ chế replication giữa nhiều site nhằm phục vụ các kịch bản Disaster Recovery (DR), High Availability (HA) và Multi-Region Deployment. Tùy nhu cầu, bạn có thể triển khai theo dạng miễn phí (bucket replication một chiều) hoặc bản thương mại (site replication đa chiều, active-active). Nội dung dưới đây phân tích chi tiết các khái niệm, kiến trúc, ví dụ, cùng so sánh sự khác biệt giữa bản miễn phí và bản trả phí.

2. Kiến trúc replication nhiều site

2.1. Distributed MinIO trong một site

Mỗi site triển khai một cluster (pool) riêng biệt.
Ví dụ: tại Site A có 4 node × 3 disk, tại Site B cũng có một cluster tương tự.
Các node trong cùng một cluster yêu cầu kết nối LAN độ trễ thấp.

2.2. Multi-Site Replication

Mỗi site = một cluster độc lập.
Giữa các site bật tính năng replication để đồng bộ dữ liệu.
Có hai mô hình:
- Bucket replication: đồng bộ dữ liệu ở cấp bucket, thường một chiều (A → B).
- Site replication: đồng bộ dữ liệu ở cấp site, nhiều chiều (A ↔ B hoặc A ↔ B ↔ C).

Sơ đồ minh họa:

+-----------+          Replication (async)         +-----------+
|  ClusterA | -----------------------------------> |  ClusterB |
|  (Site A) |                                     |  (Site B) |
+-----------+                                     +-----------+
       |                                               |
       v                                               v
   Người dùng A                                   Người dùng B

3. Miễn phí và trả phí

3.1. Miễn phí (Community / AGPLv3)

Hỗ trợ bucket replication một chiều (async).
Bạn có thể cấu hình để bucket photos ở Site A replicate sang bucket photos ở Site B.
Ứng dụng: DR cơ bản, lưu dữ liệu backup ở site dự phòng.
Giới hạn:
- Chỉ một chiều.
- Không có cơ chế tự động failover.
- Nếu site B bị lỗi, site A vẫn hoạt động nhưng dữ liệu không thể sync sang site B.

Ví dụ:

Site A (cluster 4 node) ----replicate----> Site B (cluster 4 node)

3.2. Trả phí (Enterprise / SUBNET)

Hỗ trợ site replication đa chiều (active-active).
Các site đồng bộ dữ liệu song song và có thể phục vụ đọc/ghi đồng thời.
Có khả năng tự động failover giữa các site.
Dùng cho môi trường yêu cầu HA/DR nghiêm ngặt, multi-region production.

Ví dụ:

Site A <----sync----> Site B <----sync----> Site C
  ^                                               |
  +-----------------------sync--------------------+

4. Build Multi-Site Replication

4.1. Cấu hình bucket replication một chiều (free) giữa hai cluster

Phần này hướng dẫn cấu hình bucket replication một chiều (free) giữa hai cluster MinIO độc lập (multi-site). Bạn sẽ:

Khai báo alias cho hai cluster,
Tạo bucket và bật versioning,
Khai báo remote replication,
Thêm rule replication (chọn phạm vi, xóa đồng bộ, metadata…),
Kiểm thử, theo dõi và xử lý sự cố.

Ghi chú: “Bucket replication” một chiều là tính năng miễn phí. “Site replication” đa chiều, tự động failover là trả phí (Enterprise).

4.2. Điều kiện tiên quyết

Mỗi site là một cluster MinIO độc lập (không kéo giãn 1 cluster qua 2 DC).

Mạng giữa hai site cho phép TCP đến cổng S3 (ví dụ 9000) và bạn có thông tin Access Key/Secret Key của cluster đích.
Đồng bộ giờ (NTP) giữa 2 site để tránh lệch thời gian gây lỗi chữ ký.
Quyền user tại site nguồn đủ để cấu hình replication (thường là admin hoặc user/policy tương đương).

4.3. Cấu hình

Đặt tên alias, tạo bucket

Ví dụ: site nguồn (Site A) tại http://10.237.7.81:9000, site đích (Site B) tại http://10.237.7.76:9000 ACCESS và SECRET cả 2 bên mình lấy là minioadmin

Khai báo alias:

client> mc alias set siteA http://10.237.7.81:9000 minioadmin minioadmin
Added `siteA` successfully.

client> mc alias set siteB http://10.237.7.76:9000 minioadmin minioadmin
Added `siteB` successfully.

Tạo bucket đồng tên (khuyến nghị) ở cả hai site:

client> mc mb siteA/photos
Bucket created successfully `siteA/photos`.

client> mc mb siteB/photos
Bucket created successfully `siteB/photos`.

Bật versioning (bắt buộc cho replication)

client> mc version enable siteA/photos
siteA/photos versioning is enabled

client> mc version enable siteB/photos
siteB/photos versioning is enabled

Versioning cần được bật ở cả nguồn lẫn đích.

Khai báo “remote” (nối bucket nguồn tới bucket đích)

Thêm remote replication service cho bucket nguồn (Site A) tới bucket đích (Site B):

Nếu bạn muốn không kéo object cũ, chỉ replicate các thay đổi mới:

client> mc replicate add siteA/photos \
  --remote-bucket http://minioadmin:minioadmin@10.237.7.76:9000/photos \
  --replicate "delete,delete-marker,metadata-sync"
Replication configuration rule applied to siteA/photos successfully.

Hoặc bao gồm cả các object đã tồn tại từ trước:

mc replicate add siteA/photos \
  --remote-bucket http://minioadmin:minioadmin@10.237.7.76:9000/photos \
  --replicate "delete,delete-marker,metadata-sync,existing-objects"

Nếu endpoint đích dùng HTTPS tự ký, thêm --insecure.
Nếu đích là alias siteB đã khai báo cùng 1 client, bạn cũng có thể viết dạng ngắn:

mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --replicate "delete,delete-marker,metadata-sync"

Tham khảo một số tùy mchọn thường dùng

--replicate "delete": Khi xóa object ở nguồn, hành vi xóa được nhân bản sang đích (yêu cầu versioning).
--replicate "delete-marker": Replicate “delete marker” (xóa có phiên bản).
--replicate "metadata": Đồng bộ cập nhật metadata.
--replicate "tags": Đồng bộ object tags.
--tags "env=prod,team=data": Chỉ replicate object có tag phù hợp.
--prefix "logs/": Chỉ replicate object có key prefix nhất định.
--bandwidth 100MiB: Giới hạn băng thông replicate (tùy phiên bản mc).
--priority 1: Khi có nhiều rule, priority thấp hơn thường có độ ưu tiên cao hơn (tùy phiên bản, hãy thống nhất một convention nội bộ).

5. Verify và kiểm thử.

5.1. Verify

Kết quả dưới đây là quá tuyệt vời — replication đã chạy ngon rồi.

client> mc replicate ls siteA/photos
Rules:
Remote Bucket: 10.237.7.76:9000/photos
  Rule ID: d2u307r6l2pic0s6h81g
  Priority: 0
  ARN: arn:minio:replication::0b316f3b-4ef7-474f-be48-565bf5654c28:photos

Lệnh trả về ARN (định danh remote). Nhớ note lại ARN này (ví dụ arn:minio:replication::0b316f3b-4ef7-474f-be48-565bf5654c28:photos).

5.2. Kiểm thử

Ghi thử file tại nguồn:

client> mc cp /etc/hosts siteA/photos/test.txt
/etc/hosts:      221 B / 221 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 10.15 KiB/s 0s

Kiểm tra ở đích:

client> mc ls siteB/photos
[2025-09-06 13:02:50 UTC]   221B STANDARD test.txt

client> mc cat siteB/photos/test.txt
127.0.0.1 localhost
127.0.1.1 node81

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Kiểm tra xóa (nếu đã bật replicate delete/delete-marker):

client> mc rm siteA/photos/test.txt
Created delete marker `siteA/photos/test.txt` (versionId=d9db30e2-a311-4584-bb8b-8a5a3061766a).

Chờ replica sau đó chạy lệnh mc ls –versions ta có kết quả như dưới. Output này là do bạn đang bật versioning và đã cấu hình replication rồi.

shell> mc ls --versions siteB/photos/test.txt
[2025-09-06 13:19:33 UTC]     0B STANDARD d9db30e2-a311-4584-bb8b-8a5a3061766a v4 DEL test.txt
[2025-09-06 13:18:26 UTC]   221B STANDARD 3ff3f60d-cd9f-4e61-b523-9da07624eb36 v3 PUT test.txt

v3 PUT test.txt
- v3: Version ID thứ 3 của object test.txt.
- PUT: hành động tạo object.
- 221B: dung lượng file (221 byte).
  → Đây chính là bản bạn upload trước đó.
v4 DEL test.txt
- v4: Version ID thứ 4 của object test.txt.
- DEL: delete marker (đánh dấu xóa).
- 0B: kích thước 0 byte (chỉ là marker, không có nội dung).
  → Đây là bản ghi khi bạn xóa test.txt ở siteA và marker được replicate sang siteB.

6. Cơ chế versioning trong MinIO/S3:

Khi bật versioning, xóa object không thật sự xóa data cũ. Thay vào đó, MinIO tạo thêm một delete marker (DEL).
Object cũ (v3 PUT) vẫn còn, chỉ là client mặc định khi ls sẽ coi object đã bị “ẩn” bởi marker (v4 DEL).
Bạn có thể khôi phục bằng cách xóa delete marker, hoặc truy cập trực tiếp version ID của bản cũ.

Nếu bạn muốn replication 2 chiều, lặp lại bước (2) nhưng đảo hướng: tạo rule từ siteB/photos → siteA/photos.

Giả sử muốn khôi phục lại file test.txt ở siteB:

# Xóa delete marker (DEL) → file sẽ hiện lại như trước
mc rm --versions --version-id d9db30e2-a311-4584-bb8b-8a5a3061766a siteB/photos/test.txt

# sau đó list lại:
mc ls siteB/photos

Tuyệt vời — replication đã chạy ngon rồi ✅

mc cp … siteA/photos/test.txt → file xuất hiện ở siteB/photos (221B).
mc rm … tạo delete marker trên siteA → thấy ngay trên siteB (v2 DEL) ⇒ delete-marker replication OK.
mc replicate ls hiển thị Rule ID và Remote Bucket hợp lệ.

7. Dưới đây là vài next steps hữu ích ngắn gọn (tùy chọn không bắt buộc)

Bật 2 chiều (optional)

# Tạo rule chiều ngược lại B -> A
mc version enable siteB/photos
mc replicate add siteB/photos \
  --remote-bucket siteA/photos \
  --replicate "delete,delete-marker,metadata-sync"
mc replicate ls siteB/photos

Replicate cả object cũ (nếu cần “hút” dữ liệu lịch sử)

mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --replicate "delete,delete-marker,metadata-sync,existing-objects"

Giới hạn phạm vi (chỉ 1 prefix)

# Chỉ replicate thư mục temp/
mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --replicate "delete,delete-marker,metadata-sync" \
  --prefix "temp/"

Kiểm tra & giám sát

# Xem rule
mc replicate ls siteA/photos

# Xem version/marker phía đích
mc ls --versions siteB/photos

# Theo dõi tiến độ sao chép đang chạy
mc replicate status siteA/photos

Giới hạn băng thông (tránh saturate link)

# Ví dụ giới hạn upload 20 MiB/s khi thực thi lệnh mc hiện tại
mc --limit-upload 20MiB cp /path/to/big.iso siteA/photos/

Xóa/sửa rule (nếu cần)

# Liệt kê để lấy Rule ID
mc replicate ls siteA/photos

# Xóa 1 rule theo ID
mc replicate rm siteA/photos --id <RULE-ID>

Lưu ý nhanh

Clock sync: luôn giữ NTP đồng bộ trên cả hai site để tránh lỗi chữ ký thời gian.
Versioning: phải bật trên cả nguồn & đích trước khi replicate.
ACL/Policy: nếu dùng user khác minioadmin, nhớ cấp quyền replicate phù hợp.
HTTPS nội bộ: nếu chuyển sang 9443 với cert tự ký, thêm --insecure khi cấu hình/tác nghiệp.

8. Theo dõi và vận hành

Xem rule/remote đang cấu hình: mc admin bucket remote ls siteA/photos mc admin bucket replicate ls siteA/photos
Kiểm tra trạng thái replicate: mc replicate status siteA/photos
Theo dõi sự cố/giao dịch: mc admin trace -v --errors siteA

9. Một vài ví dụ biến thể

Replicate theo prefix: chỉ đồng bộ thư mục images/

mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --prefix "images/" \
  --replicate "delete,delete-marker"

Replicate theo tag: chỉ sync object có tag env=prod

mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --tags "env=prod" \
  --replicate "metadata,tags"

Giới hạn băng thông replicate (nếu cần kiểm soát WAN)

mc replicate add siteA/photos \
  --remote-bucket siteB/photos \
  --bandwidth 100MiB

10. So sánh sự khác nhau giữa bản trả phí và bản mất phí.

Với MinIO bản community (miễn phí) bạn hoàn toàn có thể cấu hình replication 2 chiều bằng cách tự add rule theo cả hai hướng (A→B và B→A). Bạn vừa làm thành công chiều A→B, nếu làm thêm rule B→A thì coi như active-active replication “thủ công”.

Điểm khác nhau so với bản Enterprise Active-Active (trả phí):

Tính năng	Community (miễn phí)	Enterprise Active-Active (trả phí)
Replication 2 chiều	Tự cấu hình 2 rule (A→B, B→A). Hoạt động, nhưng không có cơ chế ngăn xung đột (conflict).	Hỗ trợ chính thức. Có conflict resolution (theo timestamp, version ID, hoặc chính sách tùy chỉnh) để đảm bảo tính nhất quán.
Conflict handling	Không có. Nếu cùng 1 object bị update ở cả A và B gần như đồng thời → có thể gây “ping-pong” replication hoặc mất đồng bộ.	Có built-in conflict resolution, tránh vòng lặp hoặc ghi đè sai.
Quản lý / giám sát	Tự giám sát bằng `mc replicate ls/status`.	Tích hợp MinIO Console Enterprise, alert, metrics chi tiết.
Granularity	Có thể filter theo prefix, nhưng setup thủ công.	Có rule phức tạp, ưu tiên, dễ quản lý ở quy mô nhiều site.
Support & SLA	Tự xử lý sự cố.	Có support thương mại, bảo đảm SLA, tuning performance.

Như vậy khác nhau chính là:
- Bản miễn phí có thể sync 2 chiều, nhưng chỉ phù hợp cho môi trường test, dev, hoặc production nhỏ nơi rủi ro conflict thấp.
- Bản Enterprise Active-Active thì đảm bảo an toàn dữ liệu trong trường hợp conflict, có tính năng quản trị chuyên sâu, hỗ trợ SLA → phù hợp cho hệ thống cần HA, DR chính thức.

11. Troubleshooting

Access Denied / Signature mismatch: kiểm tra Access/Secret, đồng bộ giờ (NTP) và endpoint URL.
Replication không chạy: đảm bảo versioning đã bật cả hai phía; kiểm tra rule có trùng khớp prefix/tags không.
Chậm / backlog lớn: kiểm tra băng thông giữa site, xem --bandwidth có đang giới hạn; theo dõi mc admin trace.
Không thấy xóa được replicate: chắc chắn bạn đã thêm delete và delete-marker vào --replicate.

12. Lời khuyên

Nếu mục tiêu chỉ là backup dữ liệu hoặc DR cơ bản, bản miễn phí với bucket replication một chiều đã đủ.
Nếu cần active-active multi-site với yêu cầu HA/DR cấp doanh nghiệp, bạn nên xem xét bản thương mại.
Tránh triển khai distributed cluster rải rác qua nhiều site (ví dụ 2 node ở Site A + 2 node ở Site B) vì độ trễ mạng sẽ khiến cluster hoạt động không ổn định.
Khi triển khai multi-site, luôn kiểm tra băng thông và độ trễ mạng giữa các datacenter.

13. Kết luận

MinIO replication nhiều site có hai cấp độ: bucket replication miễn phí (một chiều, dùng cho DR cơ bản) và site replication trả phí (đa chiều, active-active, dùng cho HA/DR doanh nghiệp). Tùy yêu cầu thực tế và ngân sách, bạn có thể chọn giải pháp phù hợp. Trong mọi trường hợp, mỗi site nên được triển khai như một cluster độc lập, sau đó bật replication giữa các site thay vì cố gắng kéo dài một cluster qua nhiều datacenter.

Bài viết gần đây

SQL Injection cho người mới

Các vấn đề liên quan đến asymmetric routing

Minio là gì?

So sánh đồng bộ Active-Active giữa Community và Enterprise trong MinIO

Kỹ năng sử dụng FIO

Related Stories

Leave A Reply Cancel reply

Đăng ký nhận thông tin bài viết qua email