[Swift] – Phần 1: OpenStack Swift là gì?

1. OpenStack Swift là gì?

Swift còn được gọi là OpenStack Object Storage, là một hệ thống lưu trữ đối tượng (object) mã nguồn mở được thiết kế để lưu trữ hàng petabyte dữ liệu không cấu trúc như hình ảnh, video, bản sao lưu, đầu ra từ các máy chủ và từ bất kỳ ứng dụng nào khác cần lưu trữ hoặc truy xuất dữ liệu.

Swift có khả năng chịu lỗi cao và được thiết kế để chịu được lượng lớn dữ liệu trên nhiều trung tâm dữ liệu. Nó cung cấp khả năng truy cập thông qua API RESTful và được sử dụng trong nhiều dịch vụ lưu trữ cloud.

Swift được xây dựng dựa trên kiến trúc phân tán, nghĩa là dữ liệu được lưu trữ trên nhiều máy chủ khác nhau. Điều này giúp tăng cường khả năng chịu đựng lỗi và đảm bảo rằng dữ liệu luôn sẵn sàng khi cần.

Một số thành phần chính của Swift bao gồm:

• Proxy Server: Proxy Server xử lý và định tuyến yêu cầu từ người dùng tới vị trí lưu trữ phù hợp.
• Storage Server: Là nơi dữ liệu thực sự được lưu trữ. Có ba loại máy chủ lưu trữ: máy chủ object, máy chủ container và máy chủ account.
• Ring: Là cấu trúc dữ liệu mà Swift sử dụng để ánh xạ các object đến các vị trí lưu trữ vật lý.
• Swift Account: Account chứa thông tin về người dùng và quyền truy cập của họ.
• Container: Là đơn vị lưu trữ cơ bản trong Swift, chứa một hoặc nhiều object.

Proxy Server.

Proxy Server trongn các chức năng quan trọng như mã hóa/giải mã dữ liệu, xử lý lỗi và cung cấp các API cho việc tương tác với hệ thống lưu trữ này.

Dưới đây là một số chức năng chính của Proxy Server trong Swift.

• Định tuyến yêu cầu: Proxy Server nhận yêu cầu từ người dùng hoặc ứng dụng, sau đó tra cứu trong ring để xác định vị trí lưu trữ của account, container hoặc object mà yêu cầu đang tìm kiếm.
• Hỗ trợ Erasure Code: Đối với các chính sách lưu trữ sử dụng Erasure Code, Proxy Server cũng chịu trách nhiệm mã hóa dữ liệu object thành các phần (chunks) trước khi lưu trữ và giải mã chúng khi đọc.
• Xử lý lỗi: Nếu một máy chủ lưu trữ không khả dụng, Proxy Server có thể yêu cầu ring cung cấp một máy chủ handoff thay thế. Điều này giúp Swift duy trì khả năng chịu đựng lỗi cao.
• Streaming: Khi dữ liệu object được truyền (streamed) tới hoặc từ máy chủ lưu trữ, dữ liệu này được truyền trực tiếp qua Proxy Server, không được lưu trữ tạm thời (spool) trên Proxy Server. Điều này giúp tối ưu hóa hiệu suất và giảm bộ nhớ cần thiết trên Proxy Server.
• API: Proxy Server cũng cung cấp API công khai cho người dùng và ứng dụng để tương tác với hệ thống Swift. API này cho phép thực hiện các thao tác như tạo, đọc, cập nhật và xóa (CRUD) object, cũng như quản lý account và container.

Khi người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình trên OpenStack Swift, quá trình hoạt động của Proxy Server sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Yêu cầu này đầu tiên sẽ đến Proxy Server. Proxy Server là điểm tiếp xúc đầu tiên trong hệ thống Swift, nó nhận và xử lý tất cả các yêu cầu từ người dùng.
• Proxy Server sẽ sử dụng Ring, một cấu trúc dữ liệu trong Swift, để xác định vị trí lưu trữ thực tế của file windows11.iso trên các máy chủ.
• Proxy Server sau đó sẽ gửi yêu cầu tải lên file windows11.iso đến tất cả các máy chủ được xác định bởi Ring.
• Khi tất cả các máy chủ đều đã lưu trữ thành công file windows11.iso, Proxy Server sẽ gửi phản hồi về cho người dùng hoanghd, xác nhận rằng file đã được tải lên thành công.
• Đồng thời, Proxy Server cũng sẽ cập nhật thông tin về file windows11.iso và container OS_Images trong hệ thống.

Qua quá trình này, Swift đảm bảo rằng file của bạn được lưu trữ một cách an toàn và thông tin về nó luôn được cập nhật và chính xác.

2. Ring.

Ring trong OpenStack Swift là cấu trúc dữ liệu được sử dụng để ánh xạ các object đến các vị trí lưu trữ vật lý. Nó chịu trách nhiệm quyết định object nào được lưu trữ ở đâu trong hệ thống lưu trữ. Ring được thiết kế để cân nhắc đến sự cân đối tải và khả năng chịu đựng lỗi.

Trong Ceph, thành phần tương đương với Ring trong Swift là CRUSH Map. CRUSH (Controlled Replication Under Scalable Hashing) là thuật toán mà Ceph sử dụng để xác định cách phân phối dữ liệu trên các máy chủ lưu trữ. CRUSH Map là cấu trúc dữ liệu mà Ceph sử dụng để biểu diễn hệ thống lưu trữ, bao gồm các máy chủ và ổ đĩa và mối quan hệ giữa chúng.

Cả Ring trong Swift và CRUSH Map trong Ceph đều cho phép hệ thống lưu trữ mở rộng mà không cần phải thay đổi cấu trúc dữ liệu cơ bản. Chúng cũng đều được thiết kế để chịu đựng lỗi và cân nhắc đến sự cân đối tải khi phân phối dữ liệu.

Ví dụ khi người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình, quá trình hoạt động của Ring sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Proxy Server nhận yêu cầu này và sử dụng Ring để xác định vị trí lưu trữ thực tế của file windows11.iso trên các máy chủ.
• Ring sẽ tính toán và trả về một danh sách các máy chủ nơi file windows11.iso sẽ được lưu trữ. Số lượng máy chủ này phụ thuộc vào chính sách lưu trữ mà bạn đã cấu hình (ví dụ: 3 bản sao trong chính sách Replication).
• Proxy Server sau đó sẽ gửi yêu cầu tải lên file windows11.iso đến tất cả các máy chủ này.
• Khi một máy chủ nhận được yêu cầu, nó sẽ lưu trữ file windows11.iso và gửi phản hồi về cho Proxy Server.
• Khi tất cả các máy chủ đều đã lưu trữ thành công file windows11.iso, Proxy Server sẽ gửi phản hồi về cho người dùng hoanghd, xác nhận rằng file đã được tải lên thành công.

Qua quá trình này, Swift đảm bảo rằng file của bạn được lưu trữ một cách an toàn và có thể truy cập từ nhiều vị trí khác nhau, tăng cường độ tin cậy và khả năng chịu lỗi của hệ thống.

3. Storage Policies.

Storage Policies trong OpenStack Swift cho phép bạn xác định cách dữ liệu được lưu trữ và truy cập. Mỗi chính sách lưu trữ (Storage Policy) có thể xác định một số thuộc tính khác nhau, bao gồm:

• Phân phối dữ liệu: Chính sách lưu trữ có thể xác định cách dữ liệu được phân phối trên các máy chủ và trung tâm dữ liệu. Điều này cho phép bạn tối ưu hóa hiệu suất và khả năng chịu đựng lỗi.
• Kiểu lưu trữ: Swift hỗ trợ nhiều kiểu lưu trữ khác nhau, bao gồm lưu trữ object truyền thống và lưu trữ Erasure Code. Chính sách lưu trữ cho phép bạn xác định kiểu lưu trữ nào được sử dụng cho mỗi container hoặc object.
• Độ ưu tiên truy cập: Một số chính sách lưu trữ có thể xác định độ ưu tiên truy cập cho dữ liệu, cho phép bạn tối ưu hóa hiệu suất cho các tác vụ quan trọng.
• Thời gian lưu trữ: Chính sách lưu trữ cũng có thể xác định thời gian mà dữ liệu được giữ lại trước khi bị xóa tự động.

Khi tạo một container mới trong Swift, bạn có thể chỉ định chính sách lưu trữ nào sẽ được sử dụng cho container đó. Sau đó, tất cả các object được thêm vào container sẽ tuân theo chính sách lưu trữ đã chỉ định.

Ví dụ người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình trên OpenStack Swift, quá trình hoạt động của Object Server sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Proxy Server sẽ nhận yêu cầu này và chuyển tiếp nó đến Object Server.
• Object Server sẽ nhận yêu cầu và lưu trữ file windows11.iso vào một vị trí trên đĩa cứng. Đồng thời, nó cũng sẽ lưu trữ các thông tin liên quan như metadata của file, thời gian tải lên, v.v.
• Object Server sau đó sẽ gửi phản hồi về cho Proxy Server, thông báo rằng file windows11.iso đã được lưu trữ thành công.
• Proxy Server sau đó sẽ gửi phản hồi về cho người dùng hoanghd, xác nhận rằng file windows11.iso đã được tải lên thành công.
• Đồng thời, Object Server cũng sẽ tạo ra một yêu cầu cập nhật (update request) và đưa nó vào hàng đợi. Yêu cầu này sẽ được xử lý bởi Object Updater để cập nhật thông tin về file windows11.iso trong hệ thống.

Qua quá trình này, Swift đảm bảo rằng file của bạn được lưu trữ một cách an toàn và thông tin về nó luôn được cập nhật và chính xác.

Object Server.

Trong OpenStack Swift, Object Server là thành phần chịu trách nhiệm lưu trữ và truy xuất dữ liệu thực sự. Nó nhận yêu cầu từ Proxy Server và sau đó truy xuất hoặc lưu trữ dữ liệu trên ổ đĩa. Mỗi Object Server quản lý một tập hợp các ổ đĩa và mỗi ổ đĩa có thể chứa hàng ngàn hoặc hàng triệu object.

Trong Ceph, thành phần tương đương với Object Server là OSD (Object Storage Daemon). Mỗi OSD trong Ceph quản lý một ổ đĩa vật lý và cung cấp khả năng lưu trữ và truy xuất dữ liệu. Ceph cũng sử dụng một lớp trung gian, tương tự như Proxy Server trong Swift, để định tuyến yêu cầu đến OSD thích hợp.

Cả Object Server trong Swift và OSD trong Ceph đều là thành phần cốt lõi của hệ thống lưu trữ, chịu trách nhiệm lưu trữ và truy xuất dữ liệu thực sự.

3. Container Server.

Trong OpenStack Swift, Container Server là thành phần chịu trách nhiệm quản lý các container. Một container là một đơn vị lưu trữ cơ bản trong Swift, chứa một hoặc nhiều object. Container Server lưu trữ thông tin về các object trong mỗi container, bao gồm tên object, kích thước và thời gian.

Trong Ceph, thông tin về việc object nào thuộc về pool nào (tương tự như container trong Swift) được lưu trữ trong metadata của object và được quản lý bởi RADOS, lớp lưu trữ object phân tán của Ceph.

Tuy nhiên, nếu so sánh với cấu trúc tổ chức dữ liệu, pool trong Ceph có thể xem là tương đương với container trong Swift. Cả hai đều là đơn vị lưu trữ cơ bản chứa một hoặc nhiều object.

Trong Swift, mặc định sẽ tồn tại ít nhất một container. Container mặc định thường được sử dụng để lưu trữ các object khi không có container cụ thể được chỉ định hoặc khi không có container nào khác tồn tại trong hệ thống.

Trong một số trường hợp, bạn có thể tạo các container mới để tổ chức và quản lý dữ liệu của mình theo cách tùy chỉnh, tùy thuộc vào yêu cầu cụ thể của ứng dụng hoặc dịch vụ của bạn. Tuy nhiên, không bắt buộc phải tạo các container mới, và bạn vẫn có thể lưu trữ dữ liệu trong container mặc định nếu cần.

Ví dụ khi người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình trên OpenStack Swift, quá trình hoạt động của Container Server sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Khi file windows11.iso được tải lên thành công, Object Server sẽ tạo ra một yêu cầu cập nhật (update request) và đưa nó vào hàng đợi.
• Object Updater sẽ xử lý yêu cầu cập nhật từ hàng đợi. Nó sẽ cập nhật thông tin về file windows11.iso trong hệ thống, bao gồm vị trí lưu trữ, kích thước, và thời gian tải lên.
• Sau đó, Object Updater sẽ tạo ra một yêu cầu cập nhật cho Container Server, thông báo rằng một object mới đã được thêm vào container OS_Images.
• Container Server, thông qua Container Updater, sẽ xử lý yêu cầu cập nhật từ Object Updater. Nó sẽ cập nhật thông tin về container OS_Images, bao gồm số lượng object và tổng kích thước của tất cả các object trong container.

Qua quá trình này, Swift đảm bảo rằng thông tin về tất cả các object và container luôn được cập nhật và chính xác.

5. Account Server.

Trong OpenStack Swift, Account Server là thành phần chịu trách nhiệm quản lý thông tin về các account. Mỗi account trong Swift đại diện cho một người dùng hoặc một nhóm người dùng và chứa một hoặc nhiều container.

Account Server lưu trữ thông tin về các container thuộc về mỗi account, bao gồm tên container, số lượng object trong mỗi container, và tổng kích thước của tất cả các object. Nó cũng lưu trữ thông tin về quyền truy cập của người dùng đối với các container và object.

Khi một yêu cầu được gửi đến Swift, Proxy Server sẽ liên hệ với Account Server để xác minh quyền truy cập của người dùng và lấy thông tin về vị trí của các container và object cần truy cập.

Ví dụ khi người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình trên OpenStack Swift, quá trình hoạt động của Account Server sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Khi file windows11.iso được tải lên thành công, Object Server sẽ tạo ra một yêu cầu cập nhật (update request) và đưa nó vào hàng đợi.
• Object Updater sẽ xử lý yêu cầu cập nhật từ hàng đợi. Nó sẽ cập nhật thông tin về file windows11.iso trong hệ thống, bao gồm vị trí lưu trữ, kích thước, và thời gian tải lên.
• Sau đó, Object Updater sẽ tạo ra một yêu cầu cập nhật cho Container Server, thông báo rằng một object mới đã được thêm vào container OS_Images.
• Container Updater sẽ xử lý yêu cầu cập nhật từ Object Updater. Nó sẽ cập nhật thông tin về container OS_Images, bao gồm số lượng object và tổng kích thước của tất cả các object trong container.
• Cuối cùng, Container Updater sẽ tạo ra một yêu cầu cập nhật cho Account Server, thông báo rằng container OS_Images đã được cập nhật.
• Account Server, thông qua Account Updater, sẽ xử lý yêu cầu cập nhật từ Container Updater. Nó sẽ cập nhật thông tin về account của hoanghd, bao gồm số lượng container và tổng kích thước của tất cả các container trong account.

Qua quá trình này, Swift đảm bảo rằng thông tin về tất cả các object, container, và account luôn được cập nhật và chính xác.

6. Replication.

Replication là quá trình tạo ra một hoặc nhiều bản sao của dữ liệu để tăng cường khả năng chịu đựng lỗi và cải thiện hiệu suất truy cập dữ liệu.

Trong OpenStack Swift, Replication được sử dụng để đảm bảo rằng dữ liệu luôn sẵn sàng ngay cả khi một hoặc nhiều máy chủ lưu trữ gặp sự cố. Swift tự động tạo ra nhiều bản sao của mỗi object và phân phối chúng trên nhiều máy chủ lưu trữ. Nếu một máy chủ lưu trữ gặp sự cố, Swift có thể truy cập vào bản sao của dữ liệu trên một máy chủ khác.

Quá trình Replication trong Swift được quản lý bởi các dịch vụ Replicator riêng biệt cho mỗi loại máy chủ (Object, Container và Account). Các dịch vụ này liên tục kiểm tra và đảm bảo rằng số lượng bản sao của mỗi object đều đạt đến mức mong muốn.

Dưới đây là ví dụ khi bạn sử dụng chính sách lưu trữ Replication, quá trình Replication sẽ hoạt động như sau:

• Người dùng hoanghd tải lên file windows11.iso.
• Swift sẽ lưu trữ file windows11.iso trên một máy chủ lưu trữ.
• Swift sau đó sẽ tạo ra các bản sao của file windows11.iso và phân phối chúng đều trên các máy chủ lưu trữ khác trong hệ thống. Số lượng bản sao tạo ra phụ thuộc vào chính sách lưu trữ Replication mà bạn đã cấu hình.
• Giả sử một máy chủ lưu trữ gặp sự cố và mất file windows11.iso.
• Khi hoanghd yêu cầu truy cập file windows11.iso, Swift sẽ nhận ra rằng file bị mất trên một máy chủ.
• Swift sau đó sẽ chọn một bản sao của file windows11.iso từ một máy chủ khác và trả về cho hoanghd.
• Đồng thời, Swift sẽ sử dụng bản sao này để tái tạo file windows11.iso trên máy chủ gặp sự cố. Điều này được thực hiện bởi dịch vụ Object Replicator.

Quá trình này đảm bảo rằng dữ liệu của bạn luôn an toàn và sẵn sàng truy cập, ngay cả khi một phần của hệ thống lưu trữ gặp sự cố.

7. Reconstruction.

Reconstruction (tái tạo) là quá trình phục hồi dữ liệu từ các bản sao hoặc phần dữ liệu khác nhau khi một phần của dữ liệu gốc bị mất hoặc hỏng.

Trong OpenStack Swift, Reconstruction đặc biệt quan trọng khi sử dụng chính sách lưu trữ Erasure Coding. Erasure Coding là một phương pháp lưu trữ dữ liệu mà dữ liệu gốc được chia thành các phần nhỏ và sau đó được mã hóa thành một tập hợp lớn hơn các phần dữ liệu. Một số phần dữ liệu này có thể bị mất mà dữ liệu gốc vẫn có thể được tái tạo.

Quá trình Reconstruction trong Swift được quản lý bởi Object Reconstructor, một dịch vụ chạy trên mỗi máy chủ lưu trữ object. Khi một phần dữ liệu bị mất, Object Reconstructor sẽ sử dụng các phần dữ liệu còn lại và thông tin mã hóa để tái tạo dữ liệu gốc.

Dưới đây là ví dụ khi bạn sử dụng chính sách lưu trữ Erasure Coding, quá trình Reconstruction sẽ hoạt động như sau:

• Người dùng hoanghd tải lên file windows11.iso.
• Swift chia file windows11.iso thành nhiều phần nhỏ, ví dụ 10 phần.
• Swift sau đó sử dụng thuật toán Erasure Coding để tạo ra thêm 4 phần dữ liệu mã hóa, tạo ra tổng cộng 14 phần dữ liệu.
• Các phần dữ liệu này sau đó được phân phối đều trên các máy chủ lưu trữ trong hệ thống.
• Giả sử một máy chủ lưu trữ gặp sự cố và mất một phần dữ liệu.
• Khi hoanghd yêu cầu truy cập file windows11.iso, Swift sẽ nhận ra rằng một phần dữ liệu bị mất.
• Swift sau đó sẽ sử dụng 10 phần dữ liệu gốc còn lại và 3 phần dữ liệu mã hóa để tái tạo phần dữ liệu bị mất. Điều này được thực hiện bởi dịch vụ Object Reconstructor.
• Khi phần dữ liệu bị mất đã được tái tạo, Swift sẽ trả về file windows11.iso cho hoanghd như thường lệ.

Quá trình này đảm bảo rằng dữ liệu của bạn luôn an toàn và sẵn sàng truy cập, ngay cả khi một phần của hệ thống lưu trữ gặp sự cố.

8. Updaters.

Trong OpenStack Swift, Updaters là các dịch vụ chịu trách nhiệm cập nhật thông tin về các object, container và account trong hệ thống lưu trữ. Có ba loại Updaters trong Swift: Object Updater, Container Updater và Account Updater.

• Object Updater: Khi một object mới được tạo ra hoặc một object hiện có được cập nhật, Object Updater sẽ cập nhật thông tin về object đó trong hệ thống.
• Container Updater: Khi một object mới được thêm vào một container hoặc một object hiện có trong một container được cập nhật, Container Updater sẽ cập nhật thông tin về container đó, bao gồm số lượng object và tổng kích thước của tất cả các object trong container.
• Account Updater: Khi một container mới được tạo ra hoặc một container hiện có được cập nhật, Account Updater sẽ cập nhật thông tin về account chứa container đó, bao gồm số lượng container và tổng kích thước của tất cả các container trong account.

Các Updaters này đảm bảo rằng thông tin về các object, container và account luôn được cập nhật và chính xác.

Ví dụ khi người dùng hoanghd tải lên file windows11.iso vào một container, ví dụ là OS_Images, trong account của mình trên OpenStack Swift, quá trình hoạt động của Updaters sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào container OS_Images.
• Khi file windows11.iso được tải lên thành công, Object Server sẽ tạo ra một yêu cầu cập nhật (update request) và đưa nó vào hàng đợi.
• Object Updater sẽ xử lý yêu cầu cập nhật từ hàng đợi. Nó sẽ cập nhật thông tin về file windows11.iso trong hệ thống, bao gồm vị trí lưu trữ, kích thước, và thời gian tải lên.
• Sau đó, Object Updater sẽ tạo ra một yêu cầu cập nhật cho Container Server, thông báo rằng một object mới đã được thêm vào container OS_Images.
• Container Updater sẽ xử lý yêu cầu cập nhật từ Object Updater. Nó sẽ cập nhật thông tin về container OS_Images, bao gồm số lượng object và tổng kích thước của tất cả các object trong container.
• Cuối cùng, Container Updater sẽ tạo ra một yêu cầu cập nhật cho Account Server, thông báo rằng container OS_Images đã được cập nhật.
• Account Updater sẽ xử lý yêu cầu cập nhật từ Container Updater. Nó sẽ cập nhật thông tin về account của hoanghd, bao gồm số lượng container và tổng kích thước của tất cả các container trong account.

Qua quá trình này, Swift đảm bảo rằng thông tin về tất cả các object, container, và account luôn được cập nhật và chính xác.

9. Auditors.

Trong OpenStack Swift, Auditors là các dịch vụ chịu trách nhiệm kiểm tra tính toàn vẹn của dữ liệu. Có ba loại Auditors trong Swift: Object Auditor, Container Auditor và Account Auditor. Chúng kiểm tra dữ liệu trên các máy chủ object, container và account tương ứng.

Khi người dùng hoanghd tải lên file windows11.iso vào một container trong account của mình trên OpenStack Swift, quá trình hoạt động của Auditors sẽ như sau:

• Người dùng hoanghd tải lên file windows11.iso vào một container.
• Khi file windows11.iso được tải lên thành công, nó sẽ được lưu trữ trên một máy chủ object.
• Object Auditor sẽ kiểm tra tính toàn vẹn của file windows11.iso bằng cách so sánh giá trị hash của nó với giá trị hash được lưu trữ trong hệ thống. Nếu hai giá trị hash không khớp, Object Auditor sẽ đánh dấu file windows11.iso là hỏng và thông báo cho hệ thống để tái tạo file từ các bản sao khác.
• Tương tự, Container Auditor và Account Auditor sẽ kiểm tra tính toàn vẹn của dữ liệu trên máy chủ container và máy chủ account. Nếu phát hiện bất kỳ sự không khớp nào, chúng sẽ đánh dấu dữ liệu là hỏng và thông báo cho hệ thống để khắc phục.

Qua quá trình này, Swift đảm bảo rằng dữ liệu của bạn luôn được bảo vệ và không bị hỏng.

10. Lựa chọn phần cứng.

Proxy node.

• Mỗi một Proxy Node nên phục vụ cho khoảng 5 Storage Nodes
• Nên sử dụng Proxy Node tách biệt với Storage Nodes và có ít nhất từ 2 Proxy Node trở lên cho Loadbalancing

Storage node.

• Nên sử dụng Raid 0 cho các disk SATA để tận dụng cache tăng performance write cho cluster.
• Sử dụng RAID 1 cho HDD chứa OS, việc này đảm bảo độ ổn định cho OS.
• Sử dụng 1GB RAM cho 1TB data + RAM cho các service khác.
• CPU = (total of drives * (core.GHz/per drive)) / GHz of cores.

Replicas và Partition.

•  Xác định số lượng partition trên mỗi ổ đĩa cứng (HDD) trong hệ thống lưu trữ OpenStack Swift:
  • Số HDD ban đầu: Đây là số lượng ổ đĩa cứng mà bạn có khi bắt đầu thiết lập hệ thống.
  • HDD mở rộng sau này: Đây là số lượng ổ đĩa cứng mà bạn dự định thêm vào hệ thống trong tương lai để mở rộng dung lượng lưu trữ.
  • Số partition được lưu trên 1 HDD: Đây là số lượng partition (partition là một đơn vị lưu trữ logic, mỗi partition đại diện cho một phần của không gian lưu trữ trên ổ đĩa và chứa một tập hợp các object lưu trữ) mà mỗi ổ đĩa cứng có thể lưu trữ. Số lượng này phụ thuộc vào dung lượng của ổ đĩa và kích thước mong muốn của mỗi partition.
• Cách xác định số partition như sau:
  • Xác định số lượng partition: Bước đầu tiên là xác định số lượng partition sẽ có trong ring. Ring ở đây là cấu trúc dữ liệu mà OpenStack Swift sử dụng để quản lý và phân phối dữ liệu trên các ổ đĩa.
  • Số lượng partition tối thiểu trên mỗi ổ đĩa: Khuyến nghị có ít nhất 100 partition trên mỗi ổ đĩa để đảm bảo dữ liệu được phân phối đều trên tất cả các ổ đĩa.
  • Xác định số lượng partition tối đa: Một điểm khởi đầu tốt có thể là xác định số lượng ổ đĩa tối đa mà cluster sẽ chứa, sau đó nhân với 100 và làm tròn lên đến số mũ gần nhất của 2. Điều này giúp đảm bảo rằng có đủ partition để phân phối dữ liệu khi thêm ổ đĩa vào cluster.
  • Ví dụ về cách xác định số partition, nếu có 100 HDD và replicas=2 thì số partition được xác định như sau:
    • Tính số lượng partition: Đầu tiên, bạn nhân số lượng partition tối thiểu trên mỗi ổ đĩa (100) với tổng số ổ đĩa (100), sau đó chia cho số lượng replicas (2). Công thức là (100 (partition per HDD) * 100) / 2 = 5000 ~ 8192 (2^13). Tuy nhiên, số lượng partition cần phải là một số mũ của 2, vì vậy bạn làm tròn lên đến số mũ gần nhất của 2, là 8192 (2^13). Vì vậy, số 13 được sử dụng để build ring.
    • Giới hạn kích thước partition: Trong quá trình vận hành, nên giới hạn mỗi partition chứa khoảng từ 10GB – 20GB data. Với ổ đĩa 10TB, dung lượng thực tế có thể sử dụng khoảng 8TB (để dự phòng cho việc mở rộng và quản lý). Nếu tính 20GB cho mỗi partition, thì có khoảng 400 partition trên mỗi ổ đĩa 10TB.
    • Sau khi tính toán chúng ta thay thế giá trị vào swift-ring-builder object.builder create 13 2 1 , ở số 13 đầu tiên (tương ứng với 2^13 = 8192 partition). Trong đó, 2 là số lượng replicas (bản sao của mỗi đối tượng) và 1 là thời gian (tính bằng giờ) giữa các lần rebalance.

Authentication.

• Dùng Keystone + Apache2
• Loadbalancing cho Authentication từ 2 Nodes trở lên.
• Dùng MySQL làm Database Backend cũng từ 2 node trở lên.

Rings.

• Ring Accounts và Ring Containers lưu trữ các thông tin metadata, cần IOPS cao nên sử dụng các disk SSD để lưu trữ, 2 Rings có thể dùng chung các disk SSD.
• Ring Objects bao gồm các disk dùng để lưu trữ các object nên tuỳ theo nhu cầu mà sử dụng các disk có iops và capacity phù hợp.

11. Lựa chọn OS và System.

Khuyến nghị sử dụng hệ điều hành Ubuntu với phiên bản hỗ trợ dài hạn (Long-Term Support – LTS) để triển khai OpenStack Swift. Ubuntu LTS thường được ưa chuộng trong môi trường sản xuất vì nó cung cấp sự ổn định và bảo mật trong một khoảng thời gian dài.

Đồng thời, mình cũng khuyến nghị sử dụng hệ thống file system XFS để lưu trữ các đối tượng trong OpenStack Swift. XFS là một hệ thống file system có hiệu suất cao được thiết kế để xử lý lượng dữ liệu lớn và là lựa chọn phổ biến cho OpenStack Swift vì nó hỗ trợ quản lý dung lượng lớn và có khả năng mở rộng tốt.

Tài liệu tham khảo: https://docs.openstack.org/swift/latest/install/