Module Ceilometer - lựa chọn cơ sở dữ liệu phụ trợ (database backend)

Lựa chọn một cơ sở dữ liệu phụ trợ cho Ceilometer không nên bị xem nhẹ vì một số lý do sau:

1.  Không phải tất cả các trình điều khiển phụ trợ đều được triển khai và thử nghiệm. Để lựa chọn một cách dễ dàng, bảng dưới đây sẽ cung cấp một số điều về tình trạng của từng trình điều khiển có sẵn trong trunk.

2.  Có thể không phải là một ý hay cho việc sử dụng cùng một máy chủ (host) như là một cơ sở dữ liệu khác (database) cho Ceilometer vì Ceilometer có thể thực hiện việc ghi dữ liệu rất nhiều. Lý do này thường được khuyến cáo, nếu việc triển khai Ceilometer nhằm mục đích sản xuất (thương mại) thì nên sử dụng một máy chủ chuyên dụng (dành riêng) cho nó, hoặc ít nhất là sử dụng một máy ảo có khả năng di chuyển sang máy chủ vật lý trong trường hợp cần thiết. Bảng sau đây có thể cung cấp thông tin về volumes mà Ceilometer có thể tạo ra.

Link:

Bảng tính Google

3. Nếu bạn đang định dùng phụ trợ này (backend) để lập hóa đơn cho khách hàng, bạn sẽ thấy rằng khả năng doanh thu mà bạn đạt được liên qua rất nhiều đến độ tin cậy của nó và nó có vẻ như là một yếu tố quan trọng cho các nhà quản lý.

Sau đây là bảng về một số đặc điểm đáng chú ý của từng trình điều khiển cơ sở dữ liệu (database drivers):

Driver                      Toàn bộ               Toàn bộ                 Sử dụng                                         API                    Storage                   sản xuất         ---------------------------------------------------------------------------------------

MongoDB                  Có                       Có                         Nhiềumysql, postgresql        Không                  Có                          /HBASE                      Không                  Có                          /Chú thích: "/" là không rõ thông tin.

Đo lường trong Ceilometer - phần 1

* Đo lường (Measurements)

Có 3 phép đo được định nghĩa trong Ceilometer:

1. Cumulative: tăng theo thời gian ( giờ chạy instance).

2. Gauge: các item riêng biệt (Floating IPs, upload image) và  các giá trị có tính biến động (nhập/xuất đĩa - disk I/O).

3. Delta: thay đổi theo thời gian (băng thông).

* Đơn vị

1. Bất cứ khi nào một volume được đo, SI chấp thuận các đơn vị đo (SI: hệ đo lường quốc tế) và các ký hiệu hoặc chữ viết tắt được sử dụng. Đơn vị thông tin phải được thể hiện trong bit ('b') hoặc byte ('B').

2. Đối với một máy đo (đồng hồ đo - meter) nhất định, các đơn vị đo không bao giờ được thay đổi.

3. Khi một phép đo không đại diện cho một volume (does not represent a volume) thì việc mô tả đơn vị (unit) nên luôn luôn được mô tả đó là phép đo về gì (ví dụ: apples, đĩa (disk), routers, floating IPs, v.v..).

4. Khi tạo một máy đo mới (create a new meter), nếu một máy đo đã tồn tại đang đo một cái gì đó tương tự thì nên sử dụng cùng một kiểu các đơn vị đo (same units) và độ chính xác.

5. Các phép đo và mẫu đo nên được tài liệu hóa lại các đơn vị của nó trong Ceilometer (API và tài liệu  - API and Documentation) và những mẫu mã mới không nên được kết hợp vào (merge) mà không có những tài liệu thích hợp.

* Đây là các kiểu đo cho các thành phần đang được triển khai.

Kiểu (Dimension)          Đơn vị           Ký hiệu          Ghi chú 
---------------------------------------------------------------------------------
None                            N/A                                     Giá trị nhỏ
Volume                         Byte              B
Time (thời gian)             Seconds         s

Thành công nho nhỏ của blog nhóm - chia sẻ vui

Tham gia cuộc thi Mùa hè sáng tạo 2013, nhóm vừa mong muốn thử sức mình với dự án, vừa mong muốn góp một phần nhỏ cho việc phát triển công nghệ tại Việt Nam nói chung và công nghệ OpenStack nói riêng.

Với các bài viết trên blog, đó là những kết quả mà nhóm đạt được (nghiên cứu và tham khảo) trong quá trình tham gia cuộc thi, bên cạnh đó, nhóm mong muốn những bài viết này thực sự hữu ích đối với những người bạn tại Việt Nam có nhu cầu và đam mê tìm hiểu về OpenStack. Nhóm tin rằng những bài viết trên blog sẽ là nguồn tài liệu tham khảo hữu ích cho mọi người.

Tình cờ ngồi search Google.com với dòng tìm kiếm "mùa hè sáng tạo 2013" thì thấy blog cũng như kho nguồn (github) của nhóm hiện ra ở trang đầu. Đối với các thành viên trong nhóm, đó là một niềm vui nhỏ nhỏ, khích lệ cho những nỗ lực của nhóm trong thời gian vừa qua.

Mình có chụp vài hình ảnh để chia sẻ (hoàn toàn không có cache lưu tìm kiếm hay truy cập).

Module Swift (OpenStack Object Storage) - phần 8 - kiến trúc (tt)

3. Swift Architectural Overview (kiến trúc) - part 6

* Replication (tạo bản sao)

       Replication được thiết kế để giữ cho hệ thống trong một trạng thái ổn định khi đối mặt với các điều kiện lỗi tạm thời như mất mạng hoặc ổ đĩa thất bại.

       Các quá trình Replication so sánh local data với mỗi bản sao từ xa để đảm bảo tất cả Replication đều có chứa phiên bản mới nhất. Đối tượng sao chép sử dụng một danh sách băm để nhanh chóng so sánh các phần phụ của mỗi phân vùng.

       Replication cũng đảm bảo việc dữ liệu được xóa khỏi hệ thống, khi một mục (object, container, hoặc account) bị xóa, thì tombstone được thiết lập như là phiên bản mới nhất của item đó. Replication cho thấy những tombstone và đảm bảo rằng mục đó đã được xóa khỏi toàn bộ hệ thống.

Nếu một Zone có dấu hiệu hỏng, một trong các nút có chứa bản sao sẽ thông báo và chủ động sao chép dữ liệu đến một địa điểm bàn giao

* Updaters

       Khi dữ liệu container hoặc account không thể được cập nhật ngay lập tức, điều này thường xảy ra trong các failure hoặc khoảng thời gian load lớn. Nếu bản cập nhật không thành công, cập nhật được xếp hàng đợi tại local trên filesystem, và update sẽ xử lý các bản update không thành công trước đó. Đây là nơi cuối cùng có khả năng đi vào để hoạt động. 

       Ví dụ: giả sử một container server tải và một object mới được đưa vào hệ thống. Các object ngay lập tức có sẵn cho lần đọc ngay sau khi các proxy server đáp ứng cho client. Tuy nhiên, các container server đã không cập nhật danh sách object, do đó, bản cập nhật sẽ được xếp hàng đợi cho một bản cập nhật sau đó. Vì thế danh sách Container có thể tại thời điểm đó không có các object mới được đưa vào hệ thống.

* Auditors (Kiểm toán viên)

       Auditors thu thập dữ liệu local server để kiểm tra tính toàn vẹn của các object, container, và account. Nếu sai xót được tìm thấy (trong trường hợp của bit rot (mục nát, hỏng)), tập tin được cách ly, và replication sẽ thay thế các tập tin lỗi bằng bản sao khác. 

Module Swift (OpenStack Object Storage) - phần 7 - kiến trúc (tt)

3. Swift Architectural Overview (kiến trúc) - part 5

* Object Server 

Server Object là một blob lưu trữ server mà có thể lưu trữ, truy xuất và xóa các đối tượng được lưu trữ trên các thiết bị địa phương. Đối tượng được lưu trữ như các tập tin nhị phân trên filesystem với siêu dữ liệu được lưu trữ trong các thuộc tính mở rộng của tập tin (xattrs). Điều này đòi hỏi: filesystem lựa chọn cho các object servers hỗ trợ xattrs trên các tập tin. Một số filesystem, như ext3, có xattrs tắt theo mặc định.

Mỗi đối tượng được lưu trữ bằng cách sử dụng một đường dẫn có nguồn gốc từ dữ liệu hỏng của tên đối tượng và dấu thời gian của hoạt động. Lần ghi cuối luôn thành công, và đảm bảo rằng đối tượng phiên bản mới nhất sẽ được phục vụ. Xóa là một version (thế hệ) của tập tin. Điều này đảm bảo rằng các tập tin đã xóa được nhân rộng một cách chính xác và các phiên bản cũ hơn không xuất hiện trở lại do các failure.

* Partitions (Phân vùng)

Phân vùng là một tập hợp các dữ liệu được lưu trữ, bao gồm databases account, databases Container, và các object. Phân vùng là cốt lõi để hệ thống sao chép.

Xem một phân vùng như là một thùng di chuyển qua một nhà kho trung tâm. Đơn đặt hàng riêng lẻ được đặt vào thùng. Hệ thống xử lý rằng thùng này như một thực thể gắn kết khi nó di chuyển trên toàn hệ thống. Một thùng đầy sẽ tiết kiệm được các pha hoạt động trên toàn hệ thống.

Replication và update object hoạt động trên phân vùng. Khi hệ thống quy mô hơn, số lượng của phân vùng là một số cố định.

Việc thực hiện các phân vùng là khái niệm rất đơn giản - một phân vùng chỉ là một thư mục trên một đĩa với một bảng băm tương ứng của những gì nó chứa.

Phân vùng Swift có chứa tất cả các dữ liệu trong hệ thống.

Module Swift (OpenStack Object Storage) - phần 6 - kiến trúc (tt)

3. Swift Architectural Overview (kiến trúc) - part 4

* Accounts & Containers

     Mỗi account và container là một cơ sở dữ liệu SQLite riêng lẻ được phân phối trên cluster. Một account database có chứa danh sách các container trong account đó. Một cơ sở dữ liệu container chứa danh sách các đối tượng trong container đó.

Để theo dõi vị trí của dữ liệu object, mỗi account trong hệ thống có một cơ sở dữ liệu, cơ sở dữ liệu đó tham chiếu đến tất cả các container, và mỗi cơ sở dữ liệu container tham chiếu đến mỗi object

** Container Server

     Công việc chính Server container là để xử lý danh sách các đối tượng. Nó không biết về đối tượng, mà chỉ cần biết các đối tượng đang trong một container cụ thể. Danh sách được lưu trữ như là các tập tin cơ sở dữ liệu SQLite, và nhân rộng trên các cluster giống như đối tượng đó như thế nào, luôn theo dõi thống kê tổng số các đối tượng, và tổng dung lượng sử dụng cho container đó.

       SQLite là hệ thống cơ sở dữ liệu quan hệ nhỏ gọn, hoàn chỉnh, có thể cài đặt bên trong các trình ứng dụng khác. SQLite được Richard Hipp viết dưới dạng thư viện bằng ngôn ngữ lập trình C.

** Account Server

       Account Server tương đối giống với Server container, ngoại trừ, nó chịu trách nhiệm về các danh sách các container chứ không phải là các đối tượng.

Module Swift (OpenStack Object Storage) - phần 5 - kiến trúc (tt)

3. Swift Architectural Overview (kiến trúc) - part 3

* Zone: Failure Boundaries (không ranh giới)

      Swift cho phép zone được cấu hình để cô lập các ranh giới thất bại. Mỗi bản sao của dữ liệu nằm trong một zone riêng biệt, nếu có thể. Ở cấp độ nhỏ nhất, một zone có thể là một ổ đĩa đơn hay nhóm của một vài ổ đĩa. Nếu có năm object servers lưu trữ, thì mỗi máy chủ sẽ đại diện cho zone riêng của mình. Phát triển lớn hơn thì sẽ có một rack (hoặc nhiều rack) của object servers, mỗi rack đại diện cho một zone. Mục tiêu của zone là để cho phép các cluster chịu mất các object server quan trọng mà không bị mất tất cả các bản sao của dữ liệu.

      Tất cả mọi thứ trong Swift được lưu giữ, theo mặc định là ba bản sao. Swift sẽ đặt mỗi bản sao "như là duy nhất" để vừa đảm bảo tính sẵn sàng cao và độ bền cao. Điều này có nghĩa là khi lựa chọn một vị trí bản sao, Swift sẽ lựa chọn một máy chủ trong khu vực không sử dụng, và trong khu vực đó đã có một bản sao của dữ liệu.

Khi một ổ đĩa hỏng, bản sao dữ liệu được tự động phân phối cho các zone khác để đảm bảo có ba bản sao của dữ liệu