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

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

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

* Ring

      Một Ring đại diện cho một ánh xạ giữa tên của các thực thể được lưu trữ trên đĩa và vị trí địa lý của chúng. Có Ring riêng biệt cho các account, container, và các object. Khi các thành phần khác cần phải thực hiện bất kỳ hoạt động trên một container, object, hoặc account, thì cần phải tương tác với Ring thích hợp để xác định vị trí của nó trong cluster.

       Cấu trúc dữ liệu Ring bao gồm ba phần chính: một danh sách các thiết bị trong cluster, một danh sách các danh sách id thiết bị để phân vùng tập thiết bị, và một số nguyên cho biết số bit để tính toán băm để phân vùng.

    Dữ liệu có thể được cô lập với nội dung của zone trong Ring. Mỗi bản sao của một phân vùng được đảm bảo để thường trú trong một zone khác nhau. Một zone có thể đại diện cho một ổ đĩa, một server, cabinet, một switch, hoặc thậm chí một trung tâm dữ liệu.

        Các phân vùng của Ring được chia đều giữa tất cả các thiết bị trong quá trình cài đặt Swift. Khi phân vùng cần phải được di chuyển xung quanh (ví dụ nếu một thiết bị được thêm vào cluster), Ring đảm bảo rằng một số lượng tối thiểu các phân vùng được chuyển tại một thời điểm, và chỉ có một bản sao của một phân vùng được di chuyển tại một thời điểm.

       Trọng lượng có thể được sử dụng để cân bằng sự phân bố của các phân vùng trên ổ đĩa trên cluster. Điều này có thể hữu ích, ví dụ, khi ổ đĩa có kích thước khác nhau được sử dụng trong một cluster.

       Ring được sử dụng bởi các Proxy Server và một số tiến trình nền (như sao chép).

        Bản đồ Ring phân vùng đến các địa điểm vật lý trên đĩa. Ring duy trì lập bản đồ này bằng cách sử dụng các zone, thiết bị, phân vùng, và bản sao. Mỗi phân vùng trong Ring được tái bản, theo mặc định, 3 lần qua cluster, và các địa điểm cho một phân vùng được lưu trữ trong các Map. Ring cũng chịu trách nhiệm xác định những thiết bị được sử dụng cho handoff (bàn giao) khi failure.

Bản đồ Ring  phân vùng đến các địa điểm vật lý trên đĩa.

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

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

* Building Blocks

Các thành phần cho phép Swift để cung cấp tính sẵn sàng cao, độ bền cao và đồng thời cao là:

• Proxy Servers: xử lý tất cả các yêu cầu API.
• Rings: Maps tên logic của dữ liệu đến các địa điểm trên đĩa cụ thể.
• Zones: Mỗi Zone cô lập dữ liệu từ các zone khác. Một thất bại trong một zone không ảnh hưởng đến phần còn lại của cluster vì dữ liệu được nhân rộng trên các zone.
• Accounts & Containers: Mỗi tài khoản và container là cơ sở dữ liệu cá nhân được phân phối trên cluster. Một cơ sở dữ liệu Account có chứa danh sách các Containers trong Account đó. Một cơ sở dữ liệu Container chứa danh sách các đối tượng trong Container đó.
• Objects: Các dữ liệu của chính các đối tượng.
• Partitions: phân vùng lưu trữ các đối tượng, cơ sở dữ liệu Account và cơ sở dữ liệu container. Đây là một trung gian 'vùng chứa' giúp quản lý vị trí, nơi dữ liệu sống trong cluster.

Swift cung cấp các nhóm tên miền không gian trong tài khoản như container.

Swift sử dụng các nhóm server để lưu trữ dữ liệu tĩnh, chẳng hạn như tài liệu, hình ảnh hình ảnh, trên cơ sở lâu dài. Hệ thống hoạt động bằng cách sử dụng một thuật toán băm để cung cấp một định danh duy nhất cho mỗi đối tượng hoặc tập tin, được lưu trữ trên một node / server dữ liệu. Việc bổ sung các node / server mới cho phép các hệ thống mở rộng theo chiều ngang.

Siêu dữ liệu cho từng object thường trú trên tất cả các server trong cluster và phần mềm OpenStack đảm bảo sao chép dữ liệu. File yêu cầu đi tới Swift, Swift ủy quyền server, server dịch các yêu cầu, xác định vị trí các đối tượng theo các thẻ băm và siêu dữ liệu của họ, sau đó lấy các đối tượng và các tập tin.

Administrators chỉ định một hoặc nhiều server tới một zone, và mỗi zone có một bản sao của mọi đối tượng. Hệ thống yêu cầu tối thiểu là ba zone để đảm bảo một sự cân bằng tối ưu giữa hiệu quả chi phí và phòng chống mất dữ liệu (theo Beth Cohen, một kiến trúc sư đám mây cao cấp tại Boston-Cloud Technology Partners Inc (cloudTP))

* Proxy Servers

       Proxy Server là giao diện chung của Swift và xử lý các yêu cầu đến tất cả các API, có trách nhiệm liên kết các phần còn lại của kiến ​​trúc Swift. Với mỗi yêu cầu, nó sẽ tìm kiếm vị trí của account, container, hoặc object trong Ring và định tuyến theo yêu cầu cho phù hợp. Các API công cộng cũng được tiếp xúc thông qua Proxy Server.

       Khi một Proxy Server nhận được yêu cầu, nó sẽ xác định các nút lưu trữ dựa trên URL của đối tượng, ví dụ như:

https://swift.example.com/v1/account/container/object

     Một số lượng lớn những failure cũng được xử lý trong các Proxy Server. Ví dụ, nếu một server là không có sẵn cho một object PUT, nó sẽ yêu cầu Ring cho một handoff server (chuyển giao server khác) và tuyến đường có thay thế.

     Khi đối tượng được trực tiếp đến hoặc từ một object server thì sẽ được truyền trực tiếp thông qua proxy server.

      Proxy Servers sử dụng một kiến ​​trúc được chia sẻ và có thể mở rộng khi cần thiết trên cơ sở khối lượng công việc dự kiến. Có ít nhất hai máy chủ Proxy cần được triển khai để dự phòng. Nếu một máy chủ proxy thất bại, những máy khác sẽ giành quyền điều khiển.

Module Swift (OpenStack Object Storage) - phần 2 - Đặc điểm và lợi ích của Swift

2. Đặc điểm và lợi ích của Swift

* Đặc điểm:

Các đặc tính quan trọng của Swift bao gồm:

• Tất cả các đối tượng được lưu trữ trong Swift có một URL.
• Tất cả các đối tượng được lưu trữ được nhân rộng 3x trong các zone (coi như là duy nhất), có thể được định nghĩa là một nhóm các ổ đĩa, một nút, một rack.
• Tất cả các đối tượng có siêu dữ liệu của riêng mình.
• Các nhà phát triển tương tác với hệ thống lưu trữ đối tượng thông qua một HTTP RESTful API.
• Dữ liệu object có thể được đặt bất cứ nơi nào trong cluster.
• Cluster mở rộng bằng cách thêm các nút bổ sung mà không hy sinh hiệu suất, cho phép nâng cấp hiệu quả chi phí lưu trữ mở rộng tuyến tính.
• Dữ liệu không phải di chuyển đến một hệ thống lưu trữ hoàn toàn mới.
• Các nút mới có thể được thêm vào cluster mà không có thời gian chết.
• Các nút và ổ đĩa bị hỏng có thể được hoán đổi với thời gian nghỉ dưỡng.
• Chạy trên phần cứng tiêu chuẩn công nghiệp, chẳng hạn như Dell, HP, Supermicro…

Để có được một danh sách của tất cả các container trong một account, sử dụng lệnh GET trên tài khoản:

GET http://swift.example.com/v1/account/

Để tạo container mới, sử dụng lệnh PUT với tên của các container mới:

PUT http://swift.example.com/v1/account/new_container

Để liệt kê tất cả các đối tượng trong một container, sử dụng lệnh GET trên container:

GET http://swift.example.com/v1/account/container/

Để tạo các đối tượng mới với một PUT trên đối tượng:

PUT http://swift.example.com/v1/account/container/new_object

Lệnh POST được sử dụng để thay đổi siêu dữ liệu container và objects.

 

* Lợi ích  của Swift:

** Đối với các nhà phát triển ứng dụng:

• Dữ liệu được lưu trữ và phục vụ trực tiếp qua HTTP.
• Truy cập để lưu trữ trong vài phút.
• Một hệ thống lưu trữ multi-tenant (đa người dùng) cho tất cả các ứng dụng.
• Một hệ sinh thái phong phú của các công cụ và thư viện.

** Đối với các nhóm IT:

• Sử dụng chi phí thấp, máy chủ và ổ đĩa tiêu chuẩn công nghiệp.
• Quản lý nhiều dữ liệu hơn và các case sử dụng một cách dễ dàng.
• Kích hoạt các ứng dụng mới một cách nhanh chóng.
• Kiến ​​trúc độ bền cao.
• Không có nhà cung cấp lock-in.

Module Swift (OpenStack Object Storage) - phần 1 - Giới thiệu Swift

1. Giới thiệu Swift

Swift là mã nguồn mở phát hành theo giấy phép Apache 2.0. Swift để sao lưu web, nội dung di động và bất kỳ dữ liệu phi cấu trúc khác, có thể phát triển mà không bị ràng buộc.

Swift: đa người dùng (multi-tenant) có khả năng mở rộng cao, hệ thống lưu trữ dự phòng đối tượng bền vững đã được thiết kế để lưu trữ một lượng lớn dữ liệu phi cấu trúc với chi phí thấp thông qua một http RESTful API. "Khả năng mở rộng cao" có nghĩa là nó có thể mở rộng đến hàng ngàn máy với hàng chục ngàn của ổ đĩa cứng. Swift được thiết kế có khả năng mở rộng theo chiều ngang. Swift là lý tưởng để lưu trữ và phục vụ cho nhiều người, nhiều người sử dụng đồng thời - một đặc điểm phân biệt nó với các hệ thống lưu trữ khác.

"Dự phòng" có nghĩa là swift lưu trữ nhiều bản sao của mỗi thực thể trong hệ thống. Mỗi bản sao được lưu trữ sẵn trong khu vực vật lý riêng biệt, những thất bại phổ biến như các vấn đề về ổ cứng, mạng không gây khó khăn, không gây mất dữ liệu hoặc thời gian chết.

"Lưu trữ dữ liệu phi cấu trúc" có nghĩa là Swift lưu trữ theo các bits. Swift không phải là một cơ sở dữ liệu, không phải là một hệ thống lưu trữ khối cấp, Swift lưu trữ blobs (Binary large Object) của dữ liệu. 

Ngoài ra, vì Swift đảm bảo rằng các object sẽ có sẵn dữ liệu ngay khi chúng được ghi thành công, nên Swift có thể được sử dụng để lưu trữ các nội dung thay đổi thường xuyên. Để thích ứng với những nhu cầu thay đổi, hệ thống lưu trữ phải có khả năng để xử lý khối lượng công việc quy mô web với đồng thời nhiều reader và writer để lưu trữ dữ liệu. Một số dữ liệu thường viết ra và tìm kiếm, chẳng hạn như: các tập tin cơ sở dữ liệu và hình ảnh máy ảo, dữ liệu khác như: văn bản, hình ảnh, tài liệu (và sao lưu thường được ghi một lần và hiếm khi truy cập). Web và các dữ liệu di động cũng cần phải được truy cập qua web thông qua một URL để hỗ trợ web / ứng dụng di động.

Sự khác biệt Swift với nhiều hệ thống lưu trữ khác là nó có nguồn gốc trong một môi trường sản xuất quy mô lớn, có nghĩa là nó được thiết kế để chịu được các lỗi phần cứng mà không cần bất kỳ thời gian chết và cung cấp các nhóm hoạt động các phương tiện để duy trì, nâng cấp và tăng cường một cluster. Swift có quy mô tuyến tính để hoạt động có thể thêm dung lượng lưu trữ khi cần thiết mà không cần lo lắng về chi phí. 

Giới thiệu module Ceilometer

Thời gian gần đây, nhóm thực hiện dự án không thể thường xuyên update bài viết trên blog vì việc học trên trường khá bận (thành viên nhóm đều là sinh viên năm cuối).

Trở lại với blog của nhóm, mình xin gửi một bài viết giới thiệu sơ lược về module Ceilometer.

Module Ceilometer là gì?

Ceilometer là một dự án được phát triển nhằm mục đích cung cấp một điểm liên lạc duy nhất cho hệ thống thanh toán để có được tất cả các phép đo cần thiết để thiết lập việc thanh toán cho khách hàng, module hoạt động trên tất cả các thành phần chính hiện nay của OpenStack và nó có thể hỗ trợ các thành phần mới của OpenStack trong tương lai.

Mục đích của Ceilometer là gì?

* Cung cấp một công cụ hiệu quả để đo dữ liệu, chi phí CPU và mạng.

* Cho phép người phát triển tích hợp hệ thống đo lường một cách trực tiếp hoặc bằng cách thay thế các thành phần.

* Dữ liệu có thể được thu thập bới các thông báo theo dõi (monitoring notifications) được gửi từ các dịch vụ đang hoạt động hoặc bằng cách thăm dò (polling) cơ sở hạ tầng.

* Cho phép người phát triển có thể cấu hình các loại dự liệu thu thập để phục vụ cho mục đích hoạt động của hệ thống một cách phù hợp.

* Một số người dùng có thể thấy các dữ liệu thu thập được từ hệ thống đo lường thông qua một REST API.

* Các thông tin đo được đã được ký (signed) và không thể thoái thác (non-repudiable).

Kiến trúc hệ thống

* Compute Agent chạy trên mỗi node Compute và tiến hành các cuộc khảo sát cho việc thống kê sử dụng tài nguyên.

* Central Agent chạy trên một máy chủ quản lý trung tâm (central management server) để tiến hành thăm dò cho việc thống kê sử dụng nguồn tài nguyên cho những tài nguyên không gắn với instances hoặc node compute.

* Collector chạy trên một hoặc nhiều máy chủ quản lý trung tâm để giám sát các massage queues (để thông báo và để tính toán các dữ liệu đến từ các agent).

* Data Store là một cơ sở dữ liệu có khả năng xử lý đồng thời ghi (từ một hoặc nhiều collector instances) và đọc (từ máy chủ API).

* Máy chủ API - API Server chạy trên một hoặc nhiều máy chủ quản lý trung tâm để cung cấp khả năng truy cập vào dữ liệu từ "data store".