bao cao-tot-nghiep-monitoring
TRANSCRIPT
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH
BÁO CÁO THỰC TẬP TỐT NGHIỆP
Đề tài:
Xây dựng hệ thống giám sát tài nguyên trên nền
tảng điện toán đám mây cho hệ thống Virtual Lab
trong trường đại học
GVHD: PGS.TS. Thoại Nam
TS. Phạm Trần Vũ
Thực hiện: Nguyễn Hữu Nhật Minh (50801265)
Thái Đặng Như Ngọc (50801389)
TP. HỒ CHÍ MINH THÁNG 6/2012
Đồ án môn học: Giám sát tài nguyên
i
Mục lục
Lời mở đầu ........................................................................................................................................................ 1
Chương 1. Giới thiệu đề tài ............................................................................................................................ 2
1.1. Bối cảnh............................................................................................................................................... 2
1.1.1. Tổng quan Virtual Computing Laborator ....................................................................................... 2
1.1.2. Xây dựng hệ thống Virtual Lab trong trường đại học .................................................................... 3
1.1.3. Vấn đề giải quyết .......................................................................................................................... 4
1.2. Mục tiêu .............................................................................................................................................. 4
1.2.1. Đồ án ............................................................................................................................................ 4
1.2.2. Luận văn ....................................................................................................................................... 4
1.3. Triển khai............................................................................................................................................. 5
1.3.1. Giai đoạn nghiên cứu.................................................................................................................... 5
1.3.2. Giai đoạn triển khai ...................................................................................................................... 5
1.3.3. Giai đoạn hoàn thành ................................................................................................................... 5
Chương 2. Công nghệ .................................................................................................................................... 6
2.1. Tổng quan ........................................................................................................................................... 6
2.1.1. Điện toán đám mây ...................................................................................................................... 6
2.1.2. Ảo hóa ........................................................................................................................................ 12
2.1.3. Giám sát ..................................................................................................................................... 18
2.2. Zenoss Core ....................................................................................................................................... 21
2.2.1. Giới thiệu ................................................................................................................................... 21
2.2.2. Kiến trúc ..................................................................................................................................... 22
2.2.3. Chức năng .................................................................................................................................. 25
2.2.4. Các thành phần .......................................................................................................................... 25
2.2.5. Zenpack .................................................................................................................................... 259
2.3. Thư viện hỗ trợ .................................................................................................................................. 30
2.3.1. Zenplugins .................................................................................................................................. 30
2.3.2. NagiosPlugins ............................................................................................................................. 31
Đồ án môn học: Giám sát tài nguyên
ii
2.3.3. Libvirt ......................................................................................................................................... 32
2.4. RRD ................................................................................................................................................... 37
2.4.1. Đặc điểm .................................................................................................................................... 37
2.4.2. RRD trong bộ công cụ RRDtool.................................................................................................... 38
Chương 3. Giải pháp .................................................................................................................................... 39
3.1. Mô hình chung .................................................................................................................................. 39
3.2. Giao tiếp ............................................................................................................................................ 41
3.2.1. Với nhóm quản lý tài nguyên ...................................................................................................... 41
3.2.2. Với nhóm tính phí ....................................................................................................................... 42
3.3. Phương pháp hiện thực ..................................................................................................................... 43
Chương 4. Hiện thực.................................................................................................................................... 44
4.1. Hiện thực Zenpack dùng ssh lấy thông tin thiết bị .............................................................................. 44
4.1.1. Cấu trúc Zenpack hiện thực ........................................................................................................ 44
4.1.2. Deloy và demo............................................................................................................................ 44
4.2. Các plugin sử dụng trong Monitor template ...................................................................................... 51
4.2.1. Plugin mặc định của Zenoss ........................................................................................................ 51
4.2.2. Plugin mở rộng của Zenoss ......................................................................................................... 51
4.2.3. Plugin từ cộng đồng Nagios ........................................................................................................ 52
4.3. Hiện thực module giám sát trong Virtual Lab ..................................................................................... 53
Chương 5. Đánh giá ..................................................................................................................................... 55
Tài liệu tham khảo ........................................................................................................................................... 56
Đồ án môn học: Giám sát tài nguyên
1
Lời mở đầu
Trong khoảng những năm trở lại đây, điện toán đám mây luôn là xu hướng thu
hút các doanh nghiệp và giới nghiên cứu quan tâm bởi những lợi ích mà nó mang lại.
Điện toán điện mây là một mô hình điện toán mới có khả năng co giãn linh động tùy
thuộc vào nhu cầu thực tế, trong đó tất cả các tài nguyên tồn tại dưới dạng dịch vụ
được cung cấp thông qua mạng. Sự ra đời của điện toán đám mây cho phép xây
dựng những hệ thống có khả năng tính toán lớn phục vụ nhu cầu giải quyết những
bài toán có quy mô lớn. Các công ty lớn như Amazon, Google, IBM, Microsoft, Apple
với những kho dữ liệu trung tâm nằm rải rác khắp nơi trên thế giới, thông qua mô
hình điện toán mới này có thể cho phép các doanh nghiệp khác lưu trữ và quản lý dữ
liệu trên những kho dữ liệu này. Sự ra đời điện toán đám mây giúp cho các doanh
nghiệp vừa và nhỏ tiết kiệm chi phí đầu tư và quản lý hạ tầng bằng cách thuê các dịch
vụ này từ các nhà cung cấp. Đồng hành với sự phát triển mạnh mẽ của điện toán
đám mây đã thu hút rất nhiều nhà khoa học, trường đại học và các công ty công nghệ
đầu tư nghiên cứu. Việc ứng dụng điện toán đám mây vẫn còn gây ra những lo ngại
về vấn đề an toàn và bảo mật. Tuy nhiên điện toán đám mây với những lợi ích về mặt
chi phí, tính sẵn sàng và linh động của nó hứa hẹn là một hướng đi đầy tiềm năng.
Đồ án môn học: Giám sát tài nguyên
2
Chương 1. Giới thiệu đề tài
1.1. Bối cảnh
1.1.1. Tổng quan Virtual Computing Laboratory
a. Giới thiệu
Thông thường trong các trường đại học, các sinh viên đều có nhu cầu sử dụng
máy tính không những trong mà còn ngoài các giờ lên lớp để có thể nghiên cứu và
luyện tập các bài học trên lớp. Việc cung cấp các phòng thực hành cho sinh viên
sử dụng ngoài giờ lên lớp có nhiều khó khăn về chi phí mua và quản lý tài nguyên
phần cứng, địa điểm xây dựng, cũng như các chương trình cài đặt trên máy cho
phù hợp với nhu cầu của các môn học… Một giải pháp được sử dụng là các phòng
thực hành ảo (Virtual Computing Laboratory).
Virtual Computing Laboratory (VCL) là sản phẩm của trường đại học Bắc
Carolina được bắt đầu phát triển vào năm 2004. Nó nhằm mục đích làm tăng hiệu
quả trong việc sử dụng phần cứng và cung cấp khả năng truy cập từ xa tới các máy
tính cho các sinh viên, giảng viên hoặc nhà nghiên cứu của trường.
Đặc điểm của VCL:
Cung cấp linh hoạt các tài nguyên theo yêu cầu
Tiết kiệm các chi phí tài nguyên vật lý.
Người dùng có thể sử dụng từ xa bằngmáy tinh cá nhân qua trình duyệt
web. Những máy tính này không cần đòi hỏi cấu hình cao để có thể chạy được
các ứng dụng vì các ứng dụng này được thực hiện trên các server.
Sinh viên có thể tiết kiệm chi phi mua bản quyền các phần mềm ứng dụng
dành cho môn học.
Bất lợi của VCL là thời gian đáp ứng yêu cầu còn lớn. Ngoài ra nó còn yêu
cầu đường truyền mạng ổn định nếu muốn truy cập từ xa.
b. Mô hình hoạt động
Đồ án môn học: Giám sát tài nguyên
3
Hình 1.1: Mô hình tổng quát của VCL
Giao diện web portal dành cho người dùng.
Công cụ quản lý tài nguyên dành bao gồm các hoạt động giám sát, lập lịch, an
ninh, tính toán chi phí…
Các server cơ sở dữ liệu: lưu trữ tất cả dữ liệu về quản l{, điều khiển truy cập,
thông tin lịch sử …
Kho lưu trữ ảnh của các máy ảo.
Hệ thống phần cứng.
1.1.2. Xây dựng hệ thống Virtual Lab trong trường đại học
Việc ứng dụng hệ thống virtual lab trong trường đại học sẽ giúp nâng cao hiệu suất,
giảm chi phí cho nhà trường, cũng như nó sẽ giúp sinh viên, giảng viên có cơ hội tốt
hơn cho việc học tập và giảng dạy. Để có thể xây dựng một hệ thống, và đưa vào vận
dụng đòi hỏi một quá trình nghiên cứu, tìm tòi và áp dụng trong một thời gian dài.
Hệ thống Virtual Lab chúng tôi xây dựng sẽ gồm nhiều thành phần cấu tạo nên như
trang web quản lý, các công cụ quản lý tài nguyên, lập lịch, giám sát tài nguyên, tính
toán chi phí… được thực hiện dựa trên công cụ quản lý hạ tầng Opennebula. Mỗi thành
phần này đảm nhận một nhiệm vụ riêng nhưng có sự giao tiếp giữa chúng giúp hệ
thống có những chức năng hoàn thiện và áp dụng được vào thực tiễn.
Đồ án môn học: Giám sát tài nguyên
4
Đối với nhóm chúng tôi, chúng tôi có nhiệm vụ xây dựng hệ thống giám sát tài
nguyên nhằm giúp hệ thống chính có thể theo dõi, quản lý chặt chẽ các tài nguyên và
đưa ra những quyết định dựa trên những số liệu đó. Đây là một thành phần không thể
thiếu trong mỗi hệ thống mà bất kì hệ thống lớn nào cũng cần phải thực hiện. Việc giám
sát này không những đưa ra những số liệu về hiệu suất hệ thống mà còn có thể đưa ra
những cảnh báo và xử lý khi có lỗi xuất hiện, hoặc hệ thống hoạt động vượt ngưỡng
cho phép.
1.1.3. Vấn đề giải quyết
Với công việc xây dựng hệ thống giám sát tài nguyên Virtual Lab trong trường đại
học thì đòi hỏi nhiều vấn đề cần thực hiện. Người quản lý cần được biết các thông tin
về hệ thống như thông tin CPU, RAM, băng thông, khả năng lưu trữ… để có thể sử dụng
những thông tin này cho các công việc khác. Thêm vào đó những dữ liệu này còn phải
được thể hiện bằng các đồ thị trực quan nhằm giúp việc quan sát, thống kê dễ dàng
hơn. Ngoài ra, việc giám sát phải đưa ra những cảnh báo cho người quản trị để họ đưa
ra những hành động kịp thời phù hợp với hệ thống.
Một vấn đề nữa của giám sát là tính toán được lượng thời gian dùng của một ứng
dụng trên một máy. Một máy khi khởi động sẽ có kèm theo những ứng dụng. Những
ứng dụng có thể là miễn phí hoặc bản quyền, vì thế phải giám sát được thời gian sử
dụng của người dùng đối với những ứng dụng nào yêu cầu bản quyền. Thời gian này sẽ
được dùng cho việc tính toán chi phí của người dùng.
1.2. Mục tiêu
1.2.1. Đồ án
Giám sát các thông tin về CPU, RAM, băng thông, khả năng lưu trữ … cho máy
vật lý và máy ảo.
Vẽ các đồ thị biểu diễn hiệu suất của các máy.
Giám sát các ứng dụng chạy trên máy.
1.2.2. Luận văn
Nghiên cứu chức năng tự động giám sát
Hoàn thiện các chức năng giám sát đã xây dựng
Tích hợp hệ thống giám sát vào hệ thống chung virtual lab.
Đồ án môn học: Giám sát tài nguyên
5
1.3. Triển khai
1.3.1. Giai đoạn nghiên cứu
- Tìm hiểu về mục tiêu của đề tài.
- Mô tả các yêu cầu về chức năng cần có của hệ thống
- Xây dựng sơ đồ giao tiếp giữa các thành phần khác trong hệ thống với hệ thống
giám sát.
- Tìm hiểu về các công cụ giám sát, lựa chọn công cụ phù hợp.
1.3.2. Giai đoạn triển khai
- Hiện thực các chức năng giám sát chính.
- Xây dựng cơ sở dữ liệu lưu trữ.
- Hiện thực các hàm lấy dữ liệu từ hệ thống giám sát
- Hiện thực các hàm tương tác với hệ thống giám sát từ ngoài.
1.3.3. Giai đoạn hoàn thành
- Xây dựng trang web hiển thị thông tin.
- Vận hành hệ thống giám sát.
- Tích hợp các thành phần vào hệ thống chính.
- Kiểm thử, đánh giá hiệu suất, tối ưu hóa.
Đồ án môn học: Giám sát tài nguyên
6
Chương 2. Công nghệ
2.1. Tổng quan
2.1.1. Điện toán đám mây
a. Định nghĩa
Hình 2.1: Mô hình điện toán đám mây
Điện toán đám mây là một thuật ngữ đề cập đến việc phân phối máy tính và khả
năng lưu trữ như là một dịch vụ cho một cộng đồng không đồng nhất của người
dùng cuối. Trong mô hình điện toán này mọi khả năng liên quan đến công nghệ
thông tin đều được cung cấp dưới dạng dịch vụ cho phép người dùng sử dụng các
dịch vụ công nghệ từ các nhà cung cấp mà không cần phải có các kiến thức về nó
cũng như không cần quan tâm đến các cơ sở hạ tầng phục vụ công nghệ đó.
Đồ án môn học: Giám sát tài nguyên
7
b. Các tính chất chính
Linh hoạt: cung cấp dịch vụ đến cho người dùng một cách nhanh chóng
Giao diện lập trình ứng dụng (API): điện toán đám mây thường sử dụng các
API dựa trên REST / RPC để tương tác với nhau trong hệ thống.
Giá cả: được giảm xuống một cách đáng kể, chỉ có chi phí vận hành.
Sự độc lập thiết bị và vị trí: cho phép người dùng có thể sử dụng các trình
duyệt web để truy cập đến hệ thống từ bất cứ nơi nào và bằng bất cứ thiết bị gì
của chính họ.
Ảo hóa: kĩ thuật cho phép servers và thiết bị lưu trữ có thể được chia sẽ với
nhau qua đó làm tăng độ hiệu dụng của hệ thống.
Mô hình multi-tenancy: cho phép một tài nguyên có thể được cấp phát động
cho nhiều người dùng khác nhau, các người dùng này sẽ luân phiên sử dụng tài
nguyên chung này.Như vậy khi một người dùng không có nhu cầu, tài nguyên
rảnh sẽ được hệ thống thu hồi lại và cấp phát cho người dùng khác có nhu cầu
Sự tin cậy: được cải thiện bằng cáchđảm báo hệ thống vận hành liên tục và
khả năng khôi phục sau khi phát sinh lỗi.
Sự mở rộng: có thể được thực hiện thông qua việc phân phát tài nguyên
một cách tự động theo nhu cầu của người sử dụng.
Hiệu suất: được giám sát, các kiến trúc được xây dựng thông qua việc sử
dụng các dịch vụ web để tương tác với hệ thống.
Sự bảo mật: có thể tăng lên do dữ liệu được tập trung hóa và sử dụng các
kênh lưu trữ bảo mật. Tuy nhiên, đứng về phía người dùng, vì họ không tận tay
quản lý dữ liệu, nên có cảm giác khả năng bảo mật thấp hơn, nhất là đối với
những dữ liệu nhạy cảm.
Sự bảo dưỡng: của các ứng dụng điện toán đám mấy có thể thực hiện dễ
dàng bởi vì chúng không cần được cài đặt trên máy của người dùng và có thể
được truy xuất từ nhiều nơi khác nhau
Đồ án môn học: Giám sát tài nguyên
8
c. Mô hình
Phân loại theo phạm vi triển khai:
Hình 2.2: Các mô hình cloud theo phạm vi triển khai
Các đám mây công cộng (Public Cloud): các ứng dụng, không gian lưu
trữ, tài nguyên được xây dựng để cung cấp một cách rộng rãi thông qua
một nha cung cấp dịch vụ. Những ứng dụng này có thể miễn phí hoặc
tính phí theo việc sử dụng.
Các đám mây cộng đồng (Community Cloud): dùng chung hạ tầng giữa
một vài tổ chức từ một cộng đồng xác định mà trong đó việc quản lý hệ
thống sẽ do bên trong hoặc một bên thứ ba hoặc do bên ngoài thực
hiện.
Các đám mây riêng (Private Cloud): là một hệ thống đám mây mà phục
vụ cho một tổ chức. Nó có thể được quản lý bởi các bộ phận bên trong
hoặc bên ngoài hoặc một tổ chức thứ ba.
Đồ án môn học: Giám sát tài nguyên
9
Các đám mây lai (Hybric Cloud): là một hệ thống kết hợp từ hai hoặc
nhiều mô hình trên lại với nhau để tạo ra lợi ích tối đa nhất.
Phân loại theo dịch vụ:
Hình 2.3: Minh họa về các dịch vụ
Các dịch vụ cơ sở hạ tầng (IaaS):
Iaas là tầng đáy của đám mây. Các tài nguyên được cung cấp bao
gồm: servers, mạng, bộ nhớ, CPU, không gian lưu trữ, công cụ quản lý.
Các dịch vụ ở đây hỗ trợ cơ sở hạ tầng ứng dụng bất kể cơ sở hạ tầng đó
đang được cung cấp qua một đám mây hay không. Nó sử dụng ảo hóa để
tạo ra chế độ phân phối các nguồn tài nguyên theo yêu cầu điều này đảm
bảo tiết kiệm được các chi phí cho việc sử dụng tài nguyên và đảm bảo
sự co giãn của hệ thống theo nhu cầu của ứng dụng. Còn đối với người
dùng Iaas thì giá sử dụng sẽ được tính toán trên đơn vị hiệu dụng cơ bản
thông thường là qua tài nguyên họ sử dụng.
Các dịch vụ nền tảng (PaaS):
Trong mô hình này các nhà cung cấp sẽ phân phối các nền tảng kèm
theo các tiện ích thông thường như hệ điều hành, cơ sở dữ liệu, web
server, môi trường lập trình và phát triển phần mềm vào hệ thống. Thông
Đồ án môn học: Giám sát tài nguyên
10
qua những nền tảng này các nhà phát triển ứng dụng có thể phát triển và
chạy các chương trình của họ mà không quan tâm đến chi phí cho việc
mua và quản lý các lớp phần cứng, phần mềm bên dưới.
Mô hình này có các đặc trưng sau:
Phục vụ cho việc phát triển, kiểm tra, triển khai, host, và bảo
dưỡng các ứng dụng trong một môi trường phát triển tích hợp
Cung cấp cho người dùng các công cụ khởi tạo thông qua giao
diện web
Sử dụng kiến trúc multi-tenant cho việc sử dụng tài nguyên
Tích hợp dịch vụ web với cơ sở dữ liệu
Hỗ trợ cho các cộng tác nhóm phát triển
Cung cấp các tiện ích khác như lịch sử, tính phí …
Các dịch vụ phần mềm (SaaS):
Trong mô hình này các nhà cung cấp sẽ cài đặt các phần mềm ứng
dụng trên cloud và người dùng có thể truy cập các phần mềm này từ các
đám mây client. Những người dùng này không được phép quản lý hạ
tầng và nền tảng của những ứng dụng này. Điều này sẽ giúp người dùng
tiết kiệm khoản tiền mua hạ tầng ứng dụng và các chi phí liên quan trên
hạ tầng đó. Còn nhà cung cấp sẽ thu lời từ việc cung cấp các ứng dụng
này cho khách hàng.
Cloud Computing cung cấp các phần mềm hoạt động trên nền web,
được quản lý bởi nhà cung cấp và cho phép người sử dụng truy cập từ xa.
SaaS sẽ cung cấp giấy phép một ứng dụng cho khách hàng để sử dụng
một số dịch vụ theo yêu cầu.
d. Lợi ích
Tiết kiệm: hệ thống cung cấp sẵn các tài nguyên cơ sở hạ tầng công nghệ
một cách nhanh chóng và ít tốn kém. Khách hàng có thể chọn lựa nhà
cung cấp tốt nhất cho nhu cầu về tài nguyên và giá cả của mình.
Tài nguyên được sử dụng hiệu quả theo đúng nhu cầu của khách hàng.
Các dịch vụ điện toán đám mây có thể được truy xuất ở bất kz đâu, bất
kz lúc nào thông qua mạng internet.
Đồ án môn học: Giám sát tài nguyên
11
Nhờ khả năng co giãn mà điện toán đám mấy cung cấp, hệ thống của
khách hàng có khả năng mở rộng hoặc thu nhở một cách linh hoạt tùy
theo nhu cầu cụ thể.
Đáp ứng tốt cho việc lưu trữ dữ liệu.
e. Thách thức
Chi phí bản quyền phần mềm ban đầu có thể khá cao
Tính sẵn sàng vẫn còn chưa được đảm bảo.
An toàn thông tin, một trở ngại của điện toán đám mây. Các thông tin
được lưu trữ tập trung nên dẫn đến sự mất riêng tư của người dùng.
Nguy cơ virus vẫn còn nguyên.
Lừa đảo trực tuyến và các lỗ hỏng Web.
f. Opennebula
OpenNebula ra đời năm 2008, được phát triển mạnh mẽ dựa vào cộng
đồng mã nguồn mở. Các phiên bản và các bản vá của hệ thống này được cập
nhật liên tục thể hiện sự phát triển, khả năng áp dụng và mở rộng của nó.
Những tính năng chính của OpenNebula là: Cung cấp nơi chứa các ảnh máy ảo
(image), nơi chứa các mẫu máy ảo (template), mạng máy tính ảo(virtual
network), cơ chế load ảnh từ kho với các thông số định nghĩa trong các mẫu
máy ảo được định nghĩa trước vào một máy tính vật lý dựa trên bộ phân phối
tài nguyên vào một máy tính vật lý. Những khái niệm cũng như những chuẩn
được tích hợp bên cạnh những tính năng cơ bản như:
- Cụm máy tính ảo (virtual cluster): cho phép tạo cụm các máy tính ảo
nhằm tăng cường khả năng áp dụng điện toán đám mây cho các bài toán
tính toán hiệu năng cao (High Performance Computing).
- Kho chứa dữ liệu (data storage): cho phép quản lý dữ liệu và các ảnh ảo
một cách chuyên biệt trên những nguồn chứa khác nhau như (SAN/NAS,
iSCSI/LVM, VMWare).
- Sử dụng phân phối tài nguyên từ bộ định thời Haiza
- Chuẩn tích hợp OCCI (Open Cloud Computing Integration)
- Tương tác với hệ thống Eucalyptus.
Đồ án môn học: Giám sát tài nguyên
12
- Ozone dùng để tích hợp các front end quản lý OpenNebula với nhau
thành một cụm (zone).
- Tích hợp LDAP vào OpenNebula.
- Công cụ giám sát tài nguyên Ganglia.
Qua khoảng thời gian tìm hiểu và nghiên cứu về hệ thống quản trị hạ tầng
OpenNebula có thể thấy sự phát triển không ngừng của OpenNebula với các
tính năng phù hợp với đề tài phòng thí nghiệm ảo (Virtual Laboratory). Bên
cạnh đó, công cụ này được tích hợp rất nhiều loại driver giao tiếp với các nền
tảng phần cứng sẵn có gồm các loại data storage khác nhau và các cộng cụ ảo
hóa khác nhau như KVM, Xen, VMWare. Trong giai đoạn sắp tới, bộ công cụ
này hứa hẹn sẽ đáp ứng đầy đủ nhu cầu quản lý hạ tầng điện toán đám mây.
2.1.2. Ảo hóa
a. Định nghĩa
Ảo hóa là một công nghệ thiết kế tạo ra một lớp trung gian giữa hệ thống
phần cứng máy tính và phần mềm chạy trên nó. Như vậy từ một máy vật lý
đơn lẻ có thể tạo thành nhiều máy ảo độc lập. Mỗi máy ảo đều có thể có
nguồn hệ thống riêng lẻ, hệ điều hành riêng và ứng dụng riêng.
Mảy ảo là một môi trường hoạt động độc lập tức là trong đó có các phần
mềm hoạt động chung cùng nhau nhưng độc lập với hệ điều hành máy chủ. Ví
dụ một máy ảo Java sẽ chạy các chương trình viết bằng ngôn ngữ Java, nó
không phụ thuộc vào hệ điều hành của máy đó.
Việc áp dụng công nghệ ảo hóa khi áp dụng vào điện toán đám mây sẽ
mang lại nhiều lợi ích cho hệ thống. Trong đó lợi ích lớn nhất mà chúng ta có
thể thấy chính là khả năng hợp nhất hàng loạt các server dịch vụ lại với nhau.
Thông thường thì mỗi server chỉ sử dụng rất ít tài nguyên trên hệ thống, chủ
yếu là CPU và bộ nhớ. Điều đó sẽ gây ra một sự lãng phí về tài nguyên của hệ
thống và cũng sẽ làm tăng chi phí cho những thứ không cần. Vì vậy giải pháp
đưa ra là triển khai hàng loạt máy ảo (mỗi máy ảo tương ứng chạy 1 dịch vụ)
trên một server duy nhất sẽ giúp nâng cao hiệu suất sử dụng hệ thống.
b. Đặc điểm
Tối ưu hóa công suất của phần cứng
Đồ án môn học: Giám sát tài nguyên
13
Việc để các hệ thống dịch vụ chạy trên từng máy riêng lẽ sẽ gây ra một sự
lãng phí về công suất của từng máy. Điều đó sẽ làm tăng thêm chi phí hoạt
động cho toàn hệ thống. Giờ đây với việc các phần cứng được cải tiến và sự ra
đời của công nghệ ảo hóa sẽ giúp cho việc sử dụng tài nguyên phần cứng thêm
hiệu quả. Khi một tài nguyên phần cứng không được dùng trên máy ảo này thì
nó sẽ được cấp phát cho máy ảo khác. Qua đó sẽ giúp nâng cao hiệu suất của
phần cứng.
Giảm số lượng máy vật lý
Nhờ việc tích hợp nhiều hệ thống dịch vụ trên một máy vật lý sẽ làm giảm
đi rất nhiều số lượng máy vật lý cho toàn hệ thống cùng với đó là giảm đi lượng
năng lượng tiêu thụ của toàn hệ thống. Qua đó sẽ cắt giảm được các chi phí cho
việc mua, quản lý, bảo dưỡng phần cứng với các chi phí về năng lượng.
Chí phí quản lý hệ thống lớn
Một hệ thống khi hoạt động sẽ đi kèm theo với nhiều tác vụ phổ biến liên
quan đến nó (giám sát, cài đặt, sửa chữa, bảo trì, sao lưu …). Những công việc
này đòi hỏi rất nhiều nhân lực để thuê những chuyên viên quản trị. Ảo hóa sẽ
mang lại cơ hội để cắt giảm đáng kể chi phí quản lý hệ thống. Có nhiều tác vụ
trong môi trường ảo hóa có thể được cắt giảm( thực hiện ít hơn) như việc thay
thế, giám sát thiết bị phần cứng….
c. Phân loại
Có rất nhiều loại ảo hóa: ảo hóa máy chủ, ảo hóa lưu trữ, ảo hóa phần mềm.
Nhưng trong khuôn khổ đồ án này chúng tôi chỉ xin thảo luận về ảo hóa máy chủ.
Ảo hóa hệ điều hành (OS-level Virtualization)
Đồ án môn học: Giám sát tài nguyên
14
Hình 2.4: Ảo hóa hệ điều hành (OS-level Virtualization)
Ảo hóa hệ điều hành là một phương pháp trong đó nhân một hệ điều hành
cho phép nhiều hệ điều hành khác chạy trên nó. Những hệ điều hành sẽ cung
cấp một tập các thư viện để các ứng dụng tương tác, khiến cho mỗi ứng dụng
được hỗ trợ cảm thấy như đang chạy trên một máy vật lý. Từ góc nhìn của
người dùng, các hệ điều hành này giống như những hệ điều hành thật sự.
Trong mỗi hệ điều hành, các ứng dụng này chỉ tương tác với tài nguyên trên
máy mình chứ không thấy được những tài nguyên của các hệ điều hành ảo
khác. Nó giúp cho việc bảo mật cũng như động bộ hóa.
Một ví dụ cho việc ảo hóa hệ điều hành mà ta có thế thấy đó là từ những
công ty máy chủ Web. Họ sử dụng phương pháp này để khiến một trang chủ
Web chủ tin rằng trang web mình kiểm soát toàn bộ máy chủ hệ thống. Tuy
nhiên trên thực tế mỗi trang web chủ chia sẽ cùng một máy với các trang Web
khác.
Ưu điểm của ảo hóa hệ điều hành là cần rất ít tài nguyên hệ thống. Ngoài ra
nó còn tốn rất ít chi phí bởi vì mỗi chương trình trong hệ điều hành ảo thì sử
dụng các lời gọi hệ thống thông thường và không cần phải chủ thể để mô
phỏng như trong một số phương pháp ảo hóa khác. Nó cũng không cần hỗ trợ
phần cứng đặc biệt để có thể thực hiện nó.
Đồ án môn học: Giám sát tài nguyên
15
Nhưng một nhược điểm lớn của phương pháp này là sự giới hạn trong việc
chọn lựa hệ điều hành, điều này làm giảm đi sự linh động của nó. Nó không
thể cung cấp một hệ điều hành ảo khác với nhân của hệ điều hành chủ vì các
hệ điều hành ảo cùng chạy trên một tài nguyên với hệ điều hành chủ. Vì thế
cần một sự thống nhất trong phiên bản của cá hệ điều hành ảo.
Qua đó ta thấy phương pháp ảo hóa hệ điều hành chỉ thích hợp cho hệ
thống gồm các hệ điều hành với cầu hình thuần nhất.
Ảo hóa hoàn toàn (FullVirtualization)
Hình 2.5: Ảo hóa hoàn toàn (Full Virtulization)
Ảo hóa hoàn toàn là phương pháp dùng phần mềm (hypervisor) để mô
phỏng một môi trường phần cứng để các hệ điều hành chạy trên. Hypervisor là
một lớp phần mềm nằm ngay trên phần cứng hoặc bên dưới hệ điều hành.
Mục đích chính của nó là cung cấp các phân vùng môi trường thực thi tách biệt
trong đó các máy ảo chứa các hệ điều hành khách có thể chạy. Mỗi phân vùng
được cung cấp tập hợp các tài nguyên phần cứng riêng của nó chẳng hạn như
bộ nhớ, CPU và thiết bị. Hypervisor có nhiệm vụ chuyển yêu cầu tài nguyên từ
phần cứng ảo này sang cho phần cứng vật lý. Nó cũng có trách nhiệm phải tạo
Đồ án môn học: Giám sát tài nguyên
16
và duy trì cấu trúc dữ liệu cho các thành phần ảo và cập nhật chúng. Ngoài ra
nó còn điều khiển và phân kênh truy cập đến thành phầnphần cứng.
Phương pháp ảo hóa hoàn toàn này không chỉ hỗ trợ nhiều hệ điều hành
mà còn hỗ trợ nhiều hệ điều hành khác nhau. Những hệ điều hành có thể khác
nhau hoàn toàn như Windows với Linux. Việc chạy đường nhiều hệ điều hành
đồng thời sẽ giúp phát triển song song hoăc thử nghiệm phần mềm ở nhiều
môi trường khác nhau.
Nhược điểm của phương pháp này là nó ảnh hưởng đến khả năng hoạt
động của hệ thống điều khiển khiến các ứng dụng chạy trên đó chậm hơn bình
thường. Vì những tập lệnh trên phần cứng ảo phải được chuyển đổi thành các
tập lệnh trên phần cứng vật l{ (được thực thi bởi hypervisor) sẽ gây nên sự
ảnh hưởng đến tốc độ thực thi của lệnh. Ngoài ra phương pháp ảo hóa này
còn bị giới hạn trong các trình điều khiển thiết bị. Tức là phần mềm ảo hóa chỉ
cung cấp một số trình điều khiển thiết bị cố định và người sử dụng không thể
cài đặt thêm các trình thiết bị mới. Điều nay gây ảnh hưởng tới việc mở rộng
các phần cứng mới.
Ảo hóa lai (ParaVirtualization)
Hình 2.6: Ảo hóa lai (ParaVirtualization)
Đồ án môn học: Giám sát tài nguyên
17
Là phương pháp ảo hóa mà trong đó thay vì mô phỏng môi trường phần
cứng hoàn chỉnh, phần mềm ảo hóa chỉ mô phỏng một phần và cung cấp các
dịch vụ để hệ điều hành khách tương tác với phần cứng. Phương pháp này
đem lại tốc độ, và hiệu quả sử dụng tài nguyên cao hơn so với ảo hóa hoàn
toàn. Nhưng nó lại yêu cầu các hệ điều hành khách chạy trên máy ảo phải
chỉnh sửa. Điều này dẫn tới việc không phải bất cứ hệ điều hành nào cũng có
thể sử dụng phương pháp ảo hóa lai này. Một ví dụ cho phương pháp này là XP
mode của windows 7.
Phương pháp ảo hóa lai này có hai ưu điểm chính. Thứ nhất hiệu suất sử
dụng hệ thống sẽ được nâng cao hơn phương pháp mô phỏng hoàn toàn. Vì
nó chỉ có một lớp mô phỏng mỏng giữa hệ điều hành chủ và phần cứng vật lý.
Lớp này đóng vai trò điều phối quản lý dòng truy cập của các hệ điều hành
khách phía trên để tránh tình trạng cùng sử dụng chung một tài nguyên. Ưu
điểm thứ hai của phương pháp này là nó không bị giới hạn bởi trình điều khiển
thiết bị. Vì nó sử dụng các trình điều khiển thiết bị có trong hệ điều hành chủ
chứ không phải sử dụng những trình điểu khiển có trong phần mềm ảo hóa.
Tuy nhiên phương pháp này cũng có một nhược điểm lớn là hệ điều hành
khách phải được tinh chỉnh để có thể tương tác với các dịch vụ của hệ điều
hành chủ. Do đó hệ điều hành khách chạy ảo hóa không phải là phiên bản gốc
ban đầu. Điều đó cũng có nghĩa là không phải bất cứ hệ điều hành nào cũng có
thể sử dụng phương pháp ảo hóa lại này.
d. KVM
KVM – (Kernel-based Virtual Machine) được biết đến như giải pháp đầu tiên về
công nghệ ảo hóa hoàn toàn (ảo hóa phần cứng) trong giới cộng đồng mã nguồn
mở được đánh dấu bởi việc biên dịch trong nhân Linux 2.6 năm 2007. Sau khoảng
thời gian dài phát triển giải pháp này dần cung cấp khả năng mạnh mẽ trong việc
quản lý và cung cấp môi trường thực thi tương đối ổn định cho nhiều máy ảo.
Máy ảo KVM có thể được giả lập card đồ họa, PCI, thiết bị đầu vào PS/2, card âm
thanh, card mạng Ethernet, Ram (50MB – 32 TB), CPU 1-16 CPUs. Với các phiên
bản hiện thực khác nhau trên nền tảng Linux, OpenSolaris và cho phép chạy các
hệ điều hành khách khác nhau như họ Linux, BSD, Solaris, Windows và MacOS X.
Nhóm chúng tôi chọn KVM làm môi trường ảo hóa thử nghiệm phù hợp cho
các máy ảo trong quá trình triển khai dự án phòng thí nghiệm ảo và chi phí để xây
Đồ án môn học: Giám sát tài nguyên
18
dựng các ảnh ảo là không thật nhiều vì các phiên bản hệ điều hành khách không
phải biên dịch lại như với giải pháp ảo hóa lai trước đây.
2.1.3. Giám sát
a. Định nghĩa
Cùng với sự phát triển mạnh mẽ của hệ thống điện toán đám mây, thì việc
giám sát hệ thống cũng là một phần rất quan trọng đi liền kề. Mục tiêu của việc
giám sát là có thể biết được điều gì xảy ra trong hệ thống tại mỗi thời điểm, từ đó
có thể phát hiện được các vấn đề và đưa ra hướng giải quyết chúng trong thời
gian ngắn nhất.
Giám sát có thể được định nghĩa như là việc theo dõi tài nguyên và thiết bị
trong hệ thống máy tính, cũng như hệ thống mạng để thu thập được các thông tin
về cấu hình, mạng, hiệu suất… từ những ứng dụng tương tác trong hệ thống đó.
Hiện nay có rất nhiều công cụ giám sát được phát triển, điển hình có thể kể ra
một vài công cụ phổ biến sau:
Ganglia
Nagios
Zabbix
Cacti
Zenoss
...
b. Cơ chế giám sát
Poll
Hình 2.7: Cơ chế poll
Đồ án môn học: Giám sát tài nguyên
19
Nguyên tắc hoạt động: Trung tâm giám sát sẽ thường xuyên hỏi thông tin
của thiết bị giám sát để cập nhật thông tin mới nhất về thiết bị. Nếu trung tâm
hỏi thì thiết bị trả lời, không hỏi thì sẽ không trả lời.
Alert
Hình 2.8: Cơ chế Alert
Nguyên tắc hoạt động: mỗi khi trong thiết bị xảy ra sự kiện gì đó thì thiết bị
sẽ tự động gửi thông báo cho trung tâm. Thiết bị chỉ gửi thông tin mang tính
sự kiện chứ không gửi những thông tin thường xuyên thay đổi
Đánh giá
Với mỗi cơ chế đều có ưu nhược điểm của nó.
- Poll: chúng ta có thể chủ động lấy thông tin cần thiết đối tượng xung
quanh. Nhưng nếu có sự thay đổi trong thiết bị thì poll sẽ cập nhật chậm vì
phải chờ đến thời gian định kì để lấy thông tin
- Alert: khi có bất kì sự kiện gì thì trung tâm có thể cập nhật một cách
nhanh nhất. Nhưng nếu trong quá trình có xảy ra sự cố đường truyền gì thì
trung tâm sẽ không thể cập nhật được trạng thái của thiết bị.
Vì vậy trong việc giám sát người ta thường dùng cả hai cơ chế này để có
bổ sung ưu nhược điểm cho nhau.
c. So sánh các công cụ
Các công cụ giám sát thì rất đa dạng và mỗi công cụ đều có ưu khuyết điểm
riêng, nên việc lựa chọn sử dụng công cụ nào cũng là một vấn đề cần phải được
trao đổi kĩ càng. Đối với dự án này chúng tôi chỉ quan tâm đến những công cụ
miễn phí và mã nguồn mỡ vì chi phí và tính linh hoạt của nó. Chúng tôi có đưa ra
các so sánh giữa các công cụ trên về một số mặt quan trọng của việc giám sát.
Về khả năng giám sát
Đồ án môn học: Giám sát tài nguyên
20
Ganglia: là công cụ dành cho hệ thống HPC và có overhead thấp. Nó chủ
yếu là cân nhắc về hiệu suất là chính. Và sử dụng mô hình giám sát theo cụm.
Nagios: là một công cụ giám sát phổ biến nhất trong cộng đồng mã nguồn
mở. Hầu hết mọi chức năng đều phải hỗ trợ thông qua các plugin.
Cacti: là một công cụ giám sát mà có giao diện tương tác đồ họa đẹp dễ cho
người sử dụng.
Zabbix, Zenoss: đều là công cụ mà có khả năng giám sát tốt như Nagios và
đồ họa đẹp như Cacti. Nó có thể trình bày các thông số hiệu suất thông qua
các đồ thị trực quan.
Về mức độ hỗ trợ
Ganglia: nó chủ yếu chỉ thông báo hiệu suất, không có các cảnh báo và các
trigger xử lý khi có thông số nào đó vượt ngưỡng cho phép. Ngoài ra nó cũng
không hỗ trợ syslog ghi lại các công việc báo cáo.
Nagios: Có hệ thống cảnh báo và trigger. Nó cũng đã hỗ trợ syslog thông
qua các plugin
Cacti: khả năng giám sát chưa được tốt lắm so với khả năng giao diện
Zabbix, Zenoss: đều hỗ trợ tốt về cảnh báo và các trigger xử lý. Nó còn có
khả năng auto-discovery tức khả năng tự phát hiện ra các thiết bị mạng mà
được kết nối vào hệ thống.
Về plugins
Ganglia, Cacti: đã có hỗ trợ plugin khá tốt
Nagios: với lượng cộng đồng đông đảo nên số lượng plugin cho Nagios là
rất lớn. Nhưng điều này cũng là trở ngại cho người sử dụng vì khó lựa chọn
plugin cho mình. Ngoài ra vì hầu như mọi thứ trong Nagios đều hỗ trợ qua
plugin nên sẽ khó khăn cho người sử dụng trong việc cài đặt, cấu hình ban đầu
Zabbix: do ra đời sau nên lượng plugin chưa nhiều. Nhưng hiện giờ cộng
đồng sử dụng zabbix cũng đang tăng lên nhiều.
Zenoss: một điểm thuận lợi cho nó là có hỗ trợ định dạng xuất của plugin
Nagios nên từ đó ta có thể tận dụng các plugin này. Điều này cũng sẽ giúp cho
người dùng dễ dàng lựa chọn thêm nhiều plugin.
Đồ án môn học: Giám sát tài nguyên
21
Bảng so sánh tóm tắt giữa các công cụ.
Name Auto Discovery
Agent SNMP Syslog Plugins Triggers / Alerts
WebApp Data Storage
Method
Ganglia Via gmond check in
Yes Via
plugin No Yes No Viewing RRDtool
Nagios Via plugin Supported Via
plugin Via
plugin Yes Yes Yes Flat file, SQL
Cacti Via plugin No Yes Yes Yes Yes Full Control
RRDtool, MySQL
Zabbix
Yes
Supported
Yes
Yes
Yes
Yes
Full Control
Oracle, MySQL, PostgreSQL,
IBM DB2, SQLite Zenoss Yes No Yes Yes Yes Yes Full
Control ZODB, MySQL,
RRDtool
d. Tổng kết
Qua những so sánh trên nhóm chúng tôi quyết định chọn Zenoss làm công cụ
giám sát cho hệ thống hoạt động. Vì Zenoss là một phần mềm mã nguồn mở và có
phiên bản miễn phí (Zenoss Core) cho người sử dụng. Công cụ này cung cấp giao
diện web để hỗ trợ tương tác cho người quản trị. Nó còn có thể đưa ra được các
đồ thị trực quan về các thông số giám sát giúp cho việc quản l{, đánh giá hệ thống
thêm dễ dàng. Ngoài ra nó sử dụng lượng plugin lớn của Zenoss và Nagios về
nhiều chức năng giám sát khác nhau. Đảm bảo những nhu cầu giám sát khác nhau
của hệ thống.
2.2. Zenoss Core
2.2.1. Giới thiệu
Zenoss là một platform mã nguồn mở, được sử dụng để quản lý hệ thống mạng.
Nó cho phép nhà quản trị giám sát hệ thống, quản l{ được trạng thái, cấu hình, hiệu
suất và hoạt động của các thiết bị trong hệ thống thông qua giao diện Web trực
quan. Zenoss có khả năng linh hoạt khá cáo nhờ cơ chế mở rộng thông qua Zenpack
Zenoss cung cấp khả năng giám sát bằng nhiều phương thức: SNMP, SSH, WMI,
Telnet…
Đồ án môn học: Giám sát tài nguyên
22
Lịch sử phát triển:
2002: Zenoss Core được bắt đầu phát triển.
11/2006: Zenoss Core phiên bản 1.0 được phát hành
6/200 7: Zenoss Core phiên bản 2.0 được phát hành
7/2010: Zenoss Core phiên bản 3.0 được phát hành
9/2011: Zenoss Core phiên bản 3.2 được phát hành
2.2.2. Kiến trúc
Zenoss được chia làm 4 lớp chính:
Hình 2.9: Kiến trúc Zenoss
a. User Layer
Được xây dựng xung quanh môi trường ứng dụng web Zope, nó có tác dụng
như là một portal Web. Lớp này sử dụng một vài thư viện của JavaScript, Mochi
Kit, YUI, và extJS.
Bạn có thể truy xuất và quản lý các chức năng thông qua giao diện:
Sử dụng Dashboard để xem trạng thái hiện tại.
Làm việc với các thiết bị, mạng và hệ thống.
Giám sát và đáp ứng các sự kiện
Quản lý user.
Tạo và chạy các báo cáo
Đồ án môn học: Giám sát tài nguyên
23
Lớp user sẽ tương tác với lớp data và lấy thông tin từ đó để trình bày lên giao
diện người dùng.
b. Data Layer
Thông tin cấu hình và thu thập được sẽ được lưu trong lớp data, gồm ba
database phân biệt:
ZenRRD: sử dụng RRDtool, lưu trữ dữ liệu hiệu suất về time-series. Vì mỗi
RRD files được lưu trữ một cách cục bộ cho mỗi collector nên sẽ không có hiện
tượng thắt cổ chai khi một collector mới được thêm vào.
ZenModel: là một mẫu cấu hình. Nó lưu dữ liệu thiết bị trong ZEO database.
ZenEvents: lưu trữ dữ liệu về các sự kiện trong MySQL database
c. Process Layer
Lớp process này quản lý việc giao tiếp giữa lớp collection và lớp data. Nó sẽ
chạy các công việc định kì hoặc các công việc được user khởi tạo (ZenActions và
ZenJobs).Ngoài ra trong lớp này còn có ZenHub để liên kết thông tin giữa lớp dữ
liệu và các daemons
d. Collection Layer
Hình 2.10: Collection Layer
Đồ án môn học: Giám sát tài nguyên
24
Gồm các dịch vụ thu thập dữ liệu cho lớp data. Những dịch vụ này được cung
cấp bởi các deamon mà thực hiện các chức năng mô hình hóa, giám sát và quản lý
sự kiện.
Chức năng mô hình hóa sử dụng SNMP, SSH hoặc WMI để thu thập thông tin
từ các máy con. Thông tin này sẽ được đưa vào modeler plugin và sẽ được chuẩn
hóa theo các định dạng phù hợp với dữ liệu chính.
Còn các daemons giám sát sẽ lấy thông tin về hiệu suất và hiệu dụng của cơ sở
hạ tầng. Thông tin hiệu suất được lưu trong RRD files. Thông tin về trạng thái và
độ hiệu dụng được trả về hệ thống sự kiện thông qua ZenHub. Các daemon này có
thể được chia làm 5 loại:
Automated Modeling Daemons
Zendisc: dùng để khám phá các tài nguyện mang mới
Zenmodeler: dùng để mô hình hóa các thiết bị. Sử dụng các giao thức
SNMP, SSH… để giao tiếp với các thiết bị và lấy ra được các thông tin về hệ
điều hành, hệ thống file, IP…
Availability Modeling Daemons
Zenping: giám sát tình trạng ping của Zenoss.
Zenstatus: kiểm tra hoạt động kết nối của daemons từ xa
Zenprocess: giám sát tài nguyên máy chủ
Event Collection Daemons
Zensyslog: thu thập và phân loại sự kiện hệ thống
Zeneventlog: sử dụng WMI để lấy sự kiện
Zentrap: thu thập các Traps
Performance monitoring Daemons
ZenperfSNMP: thu thập dữ liệu thông qua SNMP.
ZenperfXMLrpc: được dùng cho XML RPC collection.
Zencommand: đăng nhập vào thiết bị (bằng cách sử dụng telnet hay ssh) và
chạy các script để thu thập dữ liệu về hiệu suất.
ZenPacks : thu thập dữ liệu hiệu suất bổ sung. Ví dụ như ZenJMX thu thập
dữ liệu từ các ứng dụng Java, HttpMonitor kiểm tra độ sẵn sàng và đáp ứng
của các trang web.
Đồ án môn học: Giám sát tài nguyên
25
Automated Response Daemons
Zenactions: được sử dụng cho các cảnh báo
2.2.3. Chức năng
a. Discovery
Chức năng để dò tìm và nhận dạng các thiết bị trong hệ thống mạng. Nó sẽ
đưa ra danh sách thiết bị trong hệ thống cũng như cấu hình, định tuyến của
chúng.
Sau khi hoàn tất quá trình, việc còn lại của chúng ta là sắp xếp các thiết bị vào
các device class thích hợp để giám sát chúng.
b. Availibility Monitoring
Hệ thống giám sát tính sẵn sàng dùng để kiểm tra hoạt động của cơ sở hạ tầng.
Zenoss khám phá ra bảng định tuyến của các thiết bị và sẽ xây dựng mô hình
mạng từ đó. Không những vậy Zenoss còn cho phép người dùng có thể xác định
sự hoạt động của các dịch vụ web, mail, transfer file và nhiều dịch vụ khác.
c. Performance Monitoring
Zenoss thu thập và lưu trữ về thông tin hiệu suất các thiết bị thông qua một số
phương thức như SNMP, WMI, câu lệnh hoặc API của ứng dụng. Sau đó nó sẽ
phân tích dữ liệu và đưa ra những bảng báo cáo và đồ thị về những thông tin đó.
d. Event Manager
Zenoss nắm bắt được thông tin hiệu suất và trạng thái thiết bị thông qua các
sự kiện (event). Những sự kiện này sẽ được lưu vào cơ sở dữ liệu của zenoss và sẽ
đước xóa bỏ sau 1 khoảng thời gian tùy vào cấu hình phần mềm. Bạn có thể thêm
vào các sự kiện ngoài các sự kiện của zenoss sinh ra.
e. Modeling
Đây là quá trình giúp zenoss hiểu được môi trường nó đang hoạt động. Nó sẽ
thu thập thông tin cơ bản về hệ điều hành, phần cứng, … của thiết bị. Việc mô
hình hóa này có thể thông qua các phương thức SNMP, SSH.
2.2.4. Các thành phần
a. Device Class
Một phân loại các thiết bị, mỗi lớp này có thể đặc trưng cho một loại thiết bị,
hoặc cho vài lớp thiết bị khác.
Hệ thống đã có sẵn một số lớp thiết bị:
Đồ án môn học: Giám sát tài nguyên
26
Discovered
KVM
Network: Router, Cisco, Firewall, RSM, Terminal Server, Switch)
Ping
Power: UPS, APC
Printer: InkJet, Laser
Server: Cmd, Darwin, Linux, Remote, Scan, Solaris, Windows
Khi bạn có một thiết bị mới bạn sẽ thêm vào lớp thiết bị tương thích với nó để
thực hiện việc giám sát phù hợp.
Ngoài ra bạn có thể tạo riêng lớp mới từ việc kế thừa các lớp trên. Như trong
bài này chúng tôi tạo ra một lớp mới là Server/Virtual Host Machine/KVM cho
những máy KVM được giám sát qua ssh.
b. Modeler Plugin
Có nhiệm vụ truy vấn các thiết bị để lấy lên các thông tin cần thiết và lưu vào
database. Thông thường mỗi modeler plugin sẽ làm một nhiệm vụ riêng là lấy
thông tin cấu hình về OS hoặc file system, routes, process, IP, CPU, memory… Vì
thế thường với một lớp thiết bị thì sẽ có nhiều modeler plugin tương ứng để lấy
dữ liệu thích hợp.
Chúng ta có thể tạo thêm các modeler Plugin cần thiết để lấy thông tin phù
hợp với mục đích.
Như hình dưới ta thấy trong một lớp thiết bị /Server/Cmd thì sẽ có khá nhiều
modeler Plugin. Chúng ta sẽ chọn sử dụng modeler Plugin nào cho phù hợp.
Đồ án môn học: Giám sát tài nguyên
27
Hình 2.11: Chức năng Modeler Plugin
c. Monitoring Template
Hình 2.12: Chức năng Monitoring Template
Đồ án môn học: Giám sát tài nguyên
28
Đây là mẫu định dạng về thông tin thu thập của thiết bị. Mỗi monitoring
template sẽ gồm nhiều data source. Mỗi data source ứng với mỗi câu lệnh được
chạy để thu thập thông tin. Trong data source sẽ có nhiều data point, đó là những
kết quả trả về của câu lệnh trên sau khi đã được dịch qua bởi bộ dịch (parser) của
zenoss. Bộ dịch có 3 loại chính là nagios, cacti, uptime.
Trong monitoring template này chúng ta cũng có thể định nghĩa các cảnh bảo
cũng như các đồ thị. Với cảnh báo chúng ta có thể qui định mức cảnh bảo
(warning) hay báo động (critical). Còn đối với các graph chúng ta sẽ chọn những
datapoint nào sẽ được vẽ. Vì mỗi data point sẽ chứa dữ liệu của trả về sau khi
chạy câu lệnh của data source.
d. Collector
Hình 2.13: Collector
Chứa các thông tin về bộ thu thập dữ liệu của máy chủ. Những thông tin này
gồm những thông tin về thời gian, về thông tin cấu hình Round Robin Database…
Chúng ta có thể chỉnh sửa thông tin chu kì lấy dữ liệu, chu kì ping, cấu hình RRD ..
sao cho thích hợp.
Đồ án môn học: Giám sát tài nguyên
29
2.2.5. Zenpack
a. Giới thiệu
Zenpack là gói phần mềm của zenoss, nó mở rộng và chỉnh sửa hệ thống để có
thể thêm vào các chức năng mới. Ví dụ chúng ta có thể thêm vào lớp thiết bị
(device classs), mẫu giám sát (monitoring templates) hoặc có thể phức tạp hơn là
mở rộng mô hình dữ liệu (data model) và cung cấp collection daemon mới.
Những vấn đề Zenpack có thể thêm vào:
Mẫu giám sát (monitoring templates)
Tài nguyên dữ liệu (data sources)
Đồ thị (graphs)
Lớp sự kiện (event classes)
Sự kiện và lệnh người dùng (event and user commands)
Báo cáo (reports)
Mở rộng mô hình (model extensions)
Định nghĩa sản phẩm (product definitions)
MộtZenpack của hệ thống này có thể được cài đặt cho một hệ thống zenoss
khác. Nó như một plugin cho zenoss.
Để có một zenpack bạn có thể tải từ nhà cung cấp, từ cộng đồng về rồi cài đặt
hoặc tự tay viết mới.
b. Cách thức hoạt động
Hình 2.14: Sơ đồ hoạt động Zenpack
Có hai loại thông tin mà zenpack thu thập đó là thông tin về cầu hình
(configuration data) và thông tin về hiệu suất (performance data).
Máy chủ
Zenoss
Máy cần
giám sát
Kết nối
Trả về dữ liệu
SMNP
Command
RRD
ZODB
MySQL
Đồ án môn học: Giám sát tài nguyên
30
Thông tin cấu hình được thu thập bởi zenmodeler bằng cách sử dụng các
modeler plugin hay collector plugins và mặc định thu thập sau 12 giờ/ 1 lần
(chúng ta có thể chỉnh thời gian này cho thích hợp). Thông tin này sẽ được lưu
trong ZODB
Thông tin về hiệu suất thì được thu thập bởi các monitoring template và cứ
mỗi 5 phút /1 lần. Thông tin sẽ được lưu trong RRD.
Ngoài ra còn có dữ liệu các sự kiện (event data) sẽ được lưu trong MySQL.
c. Tạo một Zenpack
Có nhiều l{ do để bạn tạo mới một zenpack cho riêng mình, như bạn muốn
thực hiện một chức năng giám sát mới mà cộng đồng chưa hỗ trợ, hoặc bạn chỉ
muốn chọn một số thiết lập phù hợp với yêu cầu của bạn. Ngoài ra nếu cài đặt
Zenpack từ cộng động thì khi chỉnh sửa bạn không có quyền đóng gói nó để sử
dụng cho hệ thống khác.
Khi tạo một Zenpack thì đầu tiên ta cần lưu { đến cách đặt tên.Tên một
zenpack sẽ gồm ba phần riêng biệt
Ví dụ: Zenpacks.cloudBK.libvirt, Zenpack.cloudBK.MonitoringHost …
Phần 1: Mặc định là Zenpacks.
Phần 2: Tên hoặc tổ chức của tác giả (community: thường là của Zenoss
phát triển).
Phần 3: Chức năng của Zenpack đó.
Sau khi tạo xong, bạn có thể chỉnh sửa thông tin version, tác giả.Zenpack được
tạo sẽ nằm trong thư mục $ZENHOME/Zenpacks.
2.3. Thư viện hỗ trợ
2.3.1. Zenplugins
a. Định nghĩa
Zenoss Plugins (Zenplugins) bao gồm một bộ sưu tập các thư viện cụ thể viết
bằng ngôn ngữ python mà được sử dụng để thu thập các thông tin hiệu suất trên
một máy tính. Ta có thể sử dụng SSH để thực hiện câu lệnh thu thập tin tức một
cách an toàn mà không cần yêu cầu thiết bị phải cài đặt SNMP.
Việc sử dụng zenplugin sẽ giúp chúng ta dễ dàng thu thập được những thông
tin hiệu suất hơn. Ngoài ra output của các câu lệnh zenplugin được Zenoss hỗ trợ
nên việc phân tích ra dữ liệu sẽ không gặp nhiều khó khăn với người phát triển.
Đồ án môn học: Giám sát tài nguyên
31
b. Sử dụng
Định dạng một câu lệnh:
$zenplugin.py functionName [params]
- zenplugin.py là tiếp đầu ngữ bắt buộc.
- functionName là tên hàm muốn sử dụng (cpu, disk, mem…)
- params : các parameter nếu hàm đó có yêu cầu.
Định dạng output của câu lệnh:
DISK OK;|availBlocks=14251580 usedBlocks=63512052 totalBlocks=78019632
- Dữ liệu xuất đầu tiền là thông báo trạng thái thực hiện của câu lệnh được
ngăn cách với phần sau qua ‘;|’
- Tiếp theo là các dữ liệu xuất của câu lệnh được ngăn cách với nhau bằng
khoảng trắng, mỗi dữ liệu gồm tên của dữ liệu và giá trị của dữ liệu
2.3.2. NagiosPlugins
a. Định nghĩa
Bởi vì cộng đồng sử dụng công cụ Nagios là rất lớn, nên việc có thể thừa kết các
plugins của Nagios thì sẽ giúp cho Zenoss nâng cao được các chức năng của mình.
Nagios plugins là tập hợp thư viện theo chuẩn GNU mà thu thập các thông tin
về cấu hình cũng như hiệu suất của máy tính. Vì phát triển theo chuẩn GNU nên
bất kì hệ điều hành mà được hỗ trợ bởi GNU đều có thể chạy được.
b. Định dạng output của Nagios
$functionName -w value - c value [params]
Các câu lệnh của Nagios hầu như đều yêu cầu chỉ ra mức cảnh bảo(-w) và mức
báo động(-c)cho các kết quả trả về
Output của câu lệnh Nagios sẽ gồm các thành phần: mã trả về, các dữ liệu.
Mã trả về:
Giá trị Trạng thái Mô tả
0 OK Plugin thực hiện thành công và các giá trị trả về không
vượt ngưỡng
1 Warning Plugin thực hiện thành công nhưng giá trị trả về vượt mức
cảnh báo
Đồ án môn học: Giám sát tài nguyên
32
Giá trị Trạng thái Mô tả
2 Critical Plugin phát hiện hoặc các dịch vụ không chạy hoặc có giá
trị vượt mức báo động
3 Unknown Các tham số truyền vào không hợp lệ
Dữ liệu trả về: sẽ được ngăn cách nhau bởi kí hiệu “;” và sẽ gồm
‘Tên’=giátrị;[giátrị_cảnhbáo];[giátrị_báođộng];[giátrị_min];[giátrị_max]
2.3.3. Libvirt
a. Định nghĩa
Hiện nay có rất nhiều phương thức ảo hóa xuất hiện, mỗi phương thức đều có
những điểm mạnh yếu riêng. Vì vậy để dễ dàng cho cách lập trình viên có thể phát
triển các ứng dụng độc lập trên các nền ảo hóa khác nhau, Libvirt là một thư viện
cung cấp khả năng tương tác với các phương thức ảo hóa khác nhau như: Xen,
KVM, VMWare… Libvirt cung cấp các API cho phép truy xuất, tạo, chỉnh sửa, quản
lý, giám sát các thành phần trong môi trường ảo hóa.
Bảng bên dưới là một số khái niệm mà ta sẽ gặp trong quá trình làm việc với
thư viện Libvirt cũng như trong môi trường ảo hóa:
Khái niệm Mô tả
Domain Một thể hiện của hệ điều hành (hoặc một phần) chạy trên máy ảo được
cung cấp bởi hypervisor.
Hypervisor Một lớp phần mềm ảo hóa chạy trên một máy vật lý. cho phép các máy
ảo có kiến trúc khác với node có thể hoạt động trên node được.
Node Máy vật lý
Storage
Pool
Một tập hợp của thành phần lưu trữ được chia thành những phần nhỏ
hơn gọi là volume, sau đó được cấp phát cho các domain.
Volume Một không gian lưu trữ, được cấp phát từ Storage pool, và cấp phát
cho Domain. Có thể coi như một ổ cứng ảo của domain.
Đồ án môn học: Giám sát tài nguyên
33
b. Kiến trúc
Object Model
Libvirt API có thể chia thành các lớp chính sau:
- Hypervisor connections: đây là đối tượng chính trong libvirt API. Tất cả
các chương trình làm việc với libvirt đều phải bắt đầu bằng việc tạo kết nối
tới hypervisor. Một node có thể cung cấp đồng thời nhiều loại hypervisor
khác nhau như KVM và VMWare chẳng hạn. Nhưng tại một thời điểm chỉ có
tối đa một kết nối được tạo ra. Sau khi kết nối được thiết lập, ta có thể dễ
dàng tương tác với các đối tượng khác thông qua các hàm được cung cấp.
- Guest domains: Có hai loại domain chính được định nghĩa trong libvirt là
các máy ảo đang chạy (ở trạng thái là running) và các máy ảo tuy hiện tại
không được chạy nhưng đã được định nghĩa sẵn trong file cấu hình. Mỗi
domain được xác định bằng tên, ID hoặc UUID, trong đó tên và ID của một
máy ảo là duy nhất trên host mà nó đang chạy, còn UUID là một số 16 bytes
xác định một máy ảo trên toàn bộ hệ thống (tất cả các host)
- Virtual networks: virtual network cung cấp các phương thức kết nối các
máy ảo trên cùng một node. Virtual network cũng được xác định bằng tên
và UUID.
- Storage pools và Storage volumes.
- Host device (node): chứa các thông tin vật l{. Libvirt không định nghĩa
một lớp riêng cho host như các thành phần phía trên. Các phương thức
tương tác với host đều được gọi thông qua lớp Connection.
Đồ án môn học: Giám sát tài nguyên
34
Hình 2.15: Các module trong Libvirt
Driver model
Hình bên dưới thể hiện cách thức một ứng dụng tương tác với thư viện
Libvirt. Ban đầu, ứng dụng sẽ yêu cầu tạo một kết nối đến với hypervisor, hay
còn được gọi là driver. Thông qua URI mà ứng dụng yêu cầu, libvirt xác định
được hypervisor đó và tạo ra kết nối. Sau khi tạo kết nối thành công, ứng dụng
sẽ tương tác với hypervisor thông qua các public API mà libvirt hỗ trợ.
Mỗi driver có một định danh riêng, như liệt kê ở bảng bên dưới:
Đồ án môn học: Giám sát tài nguyên
35
Hình 2.16: Các driver trong libvirt
Driver Mô tả
Qemu For managing qemu and KVM guests
Xen For managing old-style (Xen 3.1 and older) Xen guests
Xenapi For managing new-style Xen guests
Uml For for managing UML guests
Vbox For managing VirtualBox guests
openvz For managing OpenVZ containers
Esx For managing VMware ESX guests
Đồ án môn học: Giám sát tài nguyên
36
URI formats
Libvirt sử dụng URIs (Uniform Resource Identifiers) để xác định một kết nối
đến hypervisor. Cả local và remote hypervisors đều được xác định thông qua
URIs. Mỗi connection URI có thể được coi như một địa chỉ URL trên hệ thống
World Wide Web. Mỗi một hypervisor trên một máy có một connection URI để
xác định vị trí node trên mạng và kiểu ảo hóa trên node
- Local URIs: có dạng tổng quát sau
driver:///system
driver:///session
driver+unix:///system
driver+unix:///session
- Remote URIs: có dạng tổng quát
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
Mô tả các thành phần
Thành
phần Mô tả
driver Tên của libvirt hypervisor driver muốn kết nối.
transport Phương thức kết nối đến host. Libvirt cung cấp các giao thức: tls, tcp,
unix, ssh, ext
username Khi sử dụng ssh để kết nối thì cần cung cấp thêm tên user đăng nhập
hostname Địa chỉ host của remote machine
path Hypervisor driver's local URIs. Với Xen, thường là ‘/’, trong khi
QEMU là ‘/system’.
Đồ án môn học: Giám sát tài nguyên
37
2.4. RRD
2.4.1. Đặc điểm
RRD(Round-Robin Database) là loại cơ sở dữ liệu ra đời nhằm mục đích thao tác
trên những dữ liệu biến đổi theo chu kz thời gian như băng thông mạng, nhiệt độ, mức
tải của bộ xử lý, ...
Các dữ liệu sẽ có mức tối đa số lượng giá trị. Khi đạt đến ngưỡng này, các giá trị
mới sẽ thay cho những giá trị cũ nhất theo vòng (circular buffer). Do đó lượng dữ liệu
sau sẽ là một hằng số khi đã đạt đến số dòng dữ liệu cho phép. Các dữ liệu RRD được
đều được xử l{ như những giá trị đo trong những chu kz. Những giá trị trong một
khoảng thời gian dài sẽ được tính toán lại trở thành giá trị duy nhất đại diện. Giá trị đại
diện cho một chu kz được gọi là giá trị đơn (primary data point - PDP). Và nhiều PDP sẽ
được dùng để tính toán cho giá trị hợp nhất (consolidate data point - CDP).
Dữ liệu lưu dữ theo bốn hàm chức năng:
Max: giá trị lớn nhất trong số các PDP được lưu giữ
Min: giá trị nhỏ nhất trong số các PDP được lưu giữ
Average: giá trị trung bình trong số các PDP được lưu giữ
Last: giá trị sau cùng trong số các PDP được lưu giữ
Six short intervals Two large intervals
Minimum (0,3,0,1,2,3)->0 (1,2)->1
Average (0,3,0,1,2,3)->1.5 (1,2)->1.5
Maximum (0,3,0,1,2,3)->3 (1,2)->2
Hình 2.17: Đồ thị có giá trị CDP tạo từ 6 PDP và CDP tạo từ 2 PDP
Có năm loại dữ liệu thường được sử dụng trong RRD:
Gauge: là kiểu dữ liệu rất phổ biến như nhiệt độ, thống kê số lượng
Đồ án môn học: Giám sát tài nguyên
38
Counter: được sử dụng cho những kiểu dữ liệu tăng liên tục và không bao
giờ giảm ngoại trừ lúc bị quá tải như đo tổng lưu lượng băng thông ra vào.
Derive: tương tự như kiểu Gauge
Absolute: bộ đếm sẽ tính từ thời điểm cuối cùng dữ liệu được đọc. Ví dụ:
Đếm số dòng của một thông điệp kể từ lần cập nhật trước đó.
Compute: dữ liệu thu thập được sẽ được tính toán lại theo một công thức.
2.4.2. RRD trong bộ công cụ RRDtool
a. Định nghĩa một nguồn dữ liệu
DS:ds-name:GAUGE | COUNTER | DERIVE | ABSOLUTE:heartbeat:min:max
DS:ds-name:COMPUTE:rpn-expression
Min – Max: khoảng giá trị cho phép của dữ liệu. Ngoài giá trị tối thiểu hoặc
tối đa một dữ liệu sẽ trở thành không xác định ‘Unknown’
Heartbeat : thông số quy định thời gian cho phép để tính toán dữ liệu nếu
quá khoảng thời gian này giá trị sẽ là ‘Unknown’.
Rpn-expression: định nghĩa công thức để tính toán cho loại dữ liệu Compute
b. Định nghĩa các thuộc tính dòng dữ liệu
RRA:AVERAGE | MIN | MAX | LAST:xff:steps:rows
Xff: tỷ số cho phép giữa số lượng Unknown PDP trên tổng số PDP khi tính
toán giá trị CDP.
Steps: Số lượng PDP dùng để tạo nên giá trị CDP
Rows: số lượng dòng dữ liệu tối đa. Khi đạt đến số dòng này dữ liệu mới sẽ
thay thế những dòng dữ liệu cũ nhất.
Ví dụ: Với chu kz 300s (5ph = 1/12h)
RRA:AVERAGE:0.5:1:600:
1 giá trị CDP được tạo từ 1 PDP
Số dòng dữ liệu tối đa là 600 dòng: 600 * 1/12h = 50h
Dữ liệu sẽ lưu trong 50h. Sau đó giá trị mới sẽ thay cho giá trị cũ nhất
RRA:AVERAGE:0.5:6:600:
1 giá trị CDP sẽ được tính trung bình từ 6 PDP
Số dòng dữ liệu tối đa là 600 dòng: 600 * 6 * 1/12h = 300h
Dữ liệu sẽ lưu trong khoảng 300h. Sau đó giá trị mới sẽ thay cho giá trị cũ nhất
Đồ án môn học: Giám sát tài nguyên
39
Chương 3. Giải pháp
3.1. Mô hình chung
Hình 3.1: Mô hình các lớp hệ thống Virtual Lab
Mô hình các lớp hệ thống trên cho ta thấy các thành phần của hệ thống. Việc phân ra
các lớp này giúp người phát triển có thể tách biệt rõ ràng vai trò và chức năng của từng
thành phần.
Đồ án môn học: Giám sát tài nguyên
40
Hình 3.2: Mô hình tương tác tronghệ thống Virtual Lab
Mỗi thành phần đều có những nhiệm vụ riêng nhưng nó cũng cần phải tương tác với
các thành phần khác. Dựa trên sơ đồ chung này ta có thể thấy sự giao tiếp giữa các
thành phần trong trong hệ thống.
Hình 3.3: Mô hình thành phần giám sát
Trên đây là sơ đồ của hệ thống giám sát chúng tôi. Hệ thống giám sát chính sẽ tương
tác với hệ thống Virtual Lab bằng các phương thức gọi hàm từ xa. Bất kì yêu cầu gì từ
Đồ án môn học: Giám sát tài nguyên
41
phía Virtual Lab như yêu cầu giám sát máy vật lý hay máy ảo, lấy thông tin giám sát…
đều được chuyển thành các lời gọi hàm truyền tới hệ thống chính. Ngoài ra hệ thống
giám sát còn phải tương tác với công cụ giám sát Zenoss. Nó sẽ có những yêu cầu như
thêm, xóa thiết bị, lấy dữ liệu từ Zenoss thông qua các Json/Rest API của Zenoss. Những
dữ liệu lấy được này sẽ được lưu trữ xuống các cơ sở dữ liệu của chúng tôi.
Đối với Zenoss thì nhiệm vụ nó sẽ giám sát các thiết bị trong hệ thống. Với mỗi thiết
bị cần phải cài đặt một số plugin lên nó để giúp Zenoss thu thập được các thông tin.
Những plugin này sẽ giúp chúng ta có thể lấy được các thông tin cấu hình thiết bị và
thông tin tài nguyên thiết bị. Nhờ những plugin này mà Zenoss có thể dùng phương
thức SSH/SNMP để có thể giao tiếp và tương tác với các thiết bị.
Nhiêm vụ thực hiện các chức năng chính trong Zenoss sẽ được giao cho ba thành
phần là Device Class, Modeler Plugins, Monitoring Template như đã nói ở phần Zenoss.
Cụ thể Device Class có nhiệm vụ tạo ra thành phần Component mới đối với những thiết
bị nằm trong lớp thiết bị này. Modeler Plugins sẽ lấy các thông tin về cấu hình gồm hệ
điều hành, hệ thống file, các máy ảo trên máy vật l{… Còn Monitoring Template sẽ có
nhiệm vụ lấy thông tin về tài nguyên thiết bị gồm CPU, RAM, băng thông, kích thước
vùng nhớ, số lượng người dùng login, kiểm tra một ứng dụng đang chạy hay không…
3.2. Giao tiếp
Với mô hình được nêu ở trên, thì nhóm chúng tôi sẽ có giao tiếp với hai nhóm chính
là nhóm quản lý tài nguyên (resource management) và nhóm tính phí (pricing)
3.2.1. Với nhóm quản lý tài nguyên
Chúng tôi sẽ cung cấp các thông tin về cấu hình, hiệu suất của máy vật l{ cũng như
máy ảo cho nhóm quản l{ tài nguyên để nhóm này có thể dùng nhưng thông tin này
cho việc lập lịch, cũng như đưa ra nhưng quyết định quản lý. Những thông tin giám sát
được sẽ được trình bày lên cho người dùng nếu họ có yêu cầu. Ngoài ra những thông
tin này còn được lưu trữ lại để có thể sử dụng cho sau này. Một vấn đề trong giao tiếp
giữa hai nhóm là với mỗi thiết bị muốn được giám sát thì phải có yêu cầu thêm nó vào
trong danh sách giám sát của Zenoss. Vì vậy khi có một thiết bị mới nó thì phía quản lý
tài nguyên phải thực hiện hành động thêm thiết bị đó vào Zenoss. Tương tự vậy với xóa
thiết bị đó ra khi không còn dùng nữa.
Đồ án môn học: Giám sát tài nguyên
42
Hình 3.4: Mô hình giao tiếp với chức năng quản lý tài nguyên
3.2.2. Với nhóm tính phí
Chúng tôi sẽ cung cấp thông tin giám sát các phần mềm, các ứng dụng chạy trên
máy ảo để giúp nhóm tính phí có thể tính toàn được chi phí của người dùng. Các thông
tin về thời gian sử dụng của người dùng, của ứng dụng. Những dữ liệu này sẽ được
trích xuất đều đặn từ Zenoss và lưu trữ xuống cơ sở dữ liệu riêng. Nhóm tính phí có thể
tương tác với cơ sở dữ liệu này.
Hình 3.5: Mô hình giao tiếp với chức năng tính phí
JSON/Rest API
Delete
VM,Host
JSON/Rest API
Modify VM
- Host
Add
VM,Host
Resource
System
Get data
VM,Host
Zenoss
Rest API – RRD values
JSON API – ZODB data
My SQL
Đồ án môn học: Giám sát tài nguyên
43
3.3. Phương pháp hiện thực
Dùng Zenoss để có thể lấy các thông tin về cấu hình thiết bị, và về hiệu suất của
thiết bị cần giám sát.
Dùng các API cung cấp bởi Zenoss để lấy thông tin từ các cơ sở dữ liệu của nó và
lưu những thông tin này xuống một cơ sở dữ liệu riêng để tiện cho việc giám sát và
sử dụng.
Các bảng trong cở sở dữ liệu được xây dựng sao cho phù hợp với mục đích giám
sát và các yêu cầu từ các hệ thống xung quanh. Nó gồm ba bảng chính về thông tin
giám sát máy vật lý, máy ảo và ứng dụng chạy trên máy. Ngoài ra còn có một số bảng
phụ trợ khác.
Bảng thông tin cho máy vật lý:
device hostname cores CPU totalRAM freeRAM usedDisk freeDisk revBw transBw Time Stat
Bảng này sẽ chứa các thông tin lấy được từ các máy vật lý gồm thông tin số core,
hiệu suất CPU đang dùng, lượng RAM đang dùng, dung lượng sử dụng, và thông tin
về bằng thông, và trạng thái thiết bị. Tại các thời điểm thích hợp thông tin này sẽ
được lấy và ghi vào bảng dữ liệu.
Bảng thông tin cho máy ảo
Device User Hostname Cores CPU Total RAM
Free RAM
Used Disk
Free Disk
Rev Bw
Trans Bw
Home Dir
Num Login
Time Stat
Tương tự như thông tin máy vật l{ nhưng đối với máy ảo còn có thông tin về dung
lượng home directory và số lượng người dùng đang login vào máy.
Bảng thông tin cho ứng dụng
Device User Hostname Process Time Instances
Thông tin cho ứng dụng bao gồm ứng dụng đó tên gì và đang sử dụng trên thiết bị
nào, người dùng nào, hiện giờ có đang chạy không.
Đồ án môn học: Giám sát tài nguyên
44
Chương 4. Hiện thực
4.1. Hiện thực Zenpack dùng ssh lấy thông tin thiết bị
4.1.1. Cấu trúc Zenpack hiện thực
Như đã đề cập ở trên, một trong những điểm tạo nên sức mạnh của Zenoss đó
chính là khả năng mở rộng. Phần này ta sẽ tiến hành viết 1 Zenpack có chức năng
giám sát các thành phần của 1 hệ thống cloud.
Hệ thống cloud được test ở đây là một hệ thống gồm các máy vật lý kết nối với
nhau. Trong đó có một máy đóng vai trò Front-end, sử dụng OpenNebula để quản lý
cả hệ thống. Máy Front-end cũng đồng thời là Zenoss server. Các máy còn lại đóng
vai trò làm host, cài đặt libvirt. Máy ảo sẽ được tạo và chạy trên các host này.
Có hai loại tài nguyên được giám sát. Các tài nguyên vật lý và các tài nguyên ảo.
Tài nguyên vật lý bao gồm:… của host. Các tài nguyên này sẽ giám sát bằng cách
kế thừa lại template của Zenoss Core. Đây là 1 template hoàn chỉnh để giám sát các
tài nguyên của một máy vật lý thông qua SSH.
Tài nguyên ảo: ta sẽ viết một ZenPack đảm nhiệm vai trò này. Ý tưởng chính của
ZenPack này là sẽ kết nối với máy ảo thông qua 1 SSH. Sau đó sẽ chạy 1 plugin để lấy
các thông tin, đưa cho ZenModeler /ZenCommand.
4.1.2. Deloy và demo
Đầu tiên chúng tôi sẽ cài đặt zenpack đã viết (coi như đang là một hệ thống mới
hoàn toàn chưa có zenpack)
Đồ án môn học: Giám sát tài nguyên
45
Hình 4.1: Cài đặt Zenpack
Bạn sẽ vào tag Zenpacks và chọn Install Zenpack, sau đó chọn đường dẫn tới
file cài đặt Zenpacks.Zenoss.Cloud.KvmMonitoring-py2.6.egg
Sau khi cài đặt thành công, trong device classes sẽ xuất hiện một lớp thiết bị
mới là Server/Virtual Machine Host/KVM.
Đồ án môn học: Giám sát tài nguyên
46
Hình 4.2: Class Virtual Machine Host/KVM được sinh ra
Đây là lớp thiết bị mới do chúng tôi định nghĩa để giám sát các thiết bị ảo hóa
bằng KVM.
Sau đó chúng ta sẽ thêm thiết bị cần giám sát vào lớp tương ứng. Chúng tôi
thêm thiết bị có IP 127.0.0.12 vào lớp Server/Virtual Machine Host/ KVM. Như vậy
có nghĩa là thiết bị này sẽ được thực hiện những tác vụ giám sát tương ứng trong
lớp KVM mà chúng tôi đã định nghĩa.
Tiếp theo cấu hình lại cái thuộc tính cho phù hợp với việc giám sát ( trong tab
Configuration Properties)
Ta cần chú ý sửa những thuộc tính sau:
- zCommandUsername: tên của máy cần giám sát.
- zCommandPassword: mật khẩu máy trên
Đồ án môn học: Giám sát tài nguyên
47
Hình 4.3: Cập nhật thông số cấu hình device
Hai thuộc tính này sẽ giúp zenpack có thể giao tiếp được với thiết bị trên thông
qua giao thức ssh (thuộc tích zCommandProtocol)
Bởi vì chúng tôi sử dụng libvirt nên cũng phải chỉnh sửa những thuộc tính libvirt
phù hợp
Lựa chọn Modeler Plugin: thường thì cứ theo mặc định sẵn có. Nhưng nếu bạn
có hiểu biết thì có thể chọn lựa một cách phù hợp.
Hình 4.4: Các Modeler Plugins trong Zenoss
Sau khi xong phần cấu hình thiết bị, chúng ta sẽ chọn Model Device để zenpack
thực hiện giám sát thiết bị. Còn nếu chỉnh sửa thuộc tính gì đó của thiết bị thì
chúng ta nên thực hiện Push Changes để cập nhật sự thay đổi.
Đồ án môn học: Giám sát tài nguyên
48
Hình 4.5: Model thiết bị
Thông báo về việc giám sát zenpack sẽ được hiện lên. Nếu có lỗi trong quá trình
chạy thì nó sẽ được thông báo tại đây. Chúng ta có thể thấy để chỉnh sửa cho phù
hợp.
Đồ án môn học: Giám sát tài nguyên
49
Hình 4.6: Kết quả model thiết bị
Kết quả giám sát
Hình 4.7: Các component mới sinh ra: IP Services, Virtual Machines ….
Đồ án môn học: Giám sát tài nguyên
50
Hình 4.8: Đồ thị kết quả giám sát trong Zenoss
Chúng tôi có được thông tin về hệ điều hành (linux2.6.32-35), memory/swap
(3.8GB/1.9GM).
Chúng ta có thể xem qua đồ thị về hiệu suất của máy với các đồ thị về
processes, độ hiệu dụng CPU, độ hiệu dụng của memory… Cách lấy điểm những đồ
thị được chúng tôi định nghĩa trong monitoring template.
Ngoài ra phần nhiệm vụ quan trọng của zenpack này là lấy được thông tin của các
máy ảo.
Đồ án môn học: Giám sát tài nguyên
51
Hình 4.9: 2 máy ảo được phát hiện.
Một máy ảo sẽ có được lấy những thông số về tên, RAM, hệ điều hành, và trạng
thái hoạt động. Như kết quả chúng tôi thu được là hiện giờ có hai máy ảo đang
hoạt động tên là one-4 và one-6. Đây chỉ là những thông tin cơ bản chúng tôi lấy.
4.2. Các plugin sử dụng trong Monitor template
4.2.1. Plugin mặc định của Zenoss
Là các plugin được cài đặt kèm theo hệ thống cung cấp khả năng truy xuất thông
tin theo cơ chế SNMP. Những plugin này cung cấp những khả năng cơ bản để xác định
hiệu suất CPU, memory, disk, network service, process.
4.2.2. Plugin mở rộng của Zenoss
Là các plugin được cộng đồng Zenoss bổ sung mở rộng vào các plugin cơ bản để
sử dụng theo cơ chế SSH sử dụng ngôn ngữ Python. Để sử dụng các plugin này, đòi
hỏi các thiết bị được giám sát phải cài đặt bộ plugin này và phải biết được public-key
của máy chứa hệ thống giám sát. Cơ chế này hoạt động dựa trên định dạng dữ liệu
theo chuẩn Nagios có tính linh động khi người dùng có thể tự phát triển các plugin
của riêng mình.
Kiểm tra dung lượng đĩa:
Câu lệnh:/usr/local/bin/zenplugin.py disk /
Kết quả:DISK OK;|totalInodes=2629632 availInodes=2353805
totalBlocks=41902456 availBlocks=9851012
usedInodes=275827 usedBlocks=29951836
Kiểm tra hiệu suất Memory:
Câu lệnh:/usr/local/bin/zenplugin.py mem
Đồ án môn học: Giám sát tài nguyên
52
Kết quả:MEM OK;|hrSwapSize=3087003648 hrMemorySize=6049849344
pageSize=4096 memBuffer=108822528 memAvailReal=3961241600
memAvailSwap=3087003648 memCached=461561856
Kiểm tra hiệu suất CPU:
Câu lệnh:/usr/local/bin/zenplugin.py cpu
Kết quả:CPU OK;|ssCpuRawInterrupt=0 laLoadInt1=1.19 ssRawContexts=705828
laLoadInt5=0.99 ssCpuRawNice=303 ssCpuRawKernel=4195
ssCpuRawSystem=4195 ssCpuRawWait=18757
laLoadInt15=0.73 ssRawInterrupts=479510
ssCpuRawIdle=606324 ssCpuRawUser=13046
4.2.3. Plugin từ cộng đồng Nagios
Là các plugin được phát triển do cộng đồng Nagios cung cấp nhằm bổ sung và mở
rộng các chức năng vốn có của hệ thống. Các plugin được viết trên ngôn ngữ bash –
shell script, Perl, Python, C, C++. Dựa vào cộng đồng mã nguồn mở rất lớn của Nagios
các plugin được đánh giá, xem xét sử dụng và chỉnh sửa đáp ứng các nhu cầu giám sát
nâng cao trên các hệ thống đặc thù khác nhau.
Kiểm tra số người dùng đăng nhập vào máy:
Câu lệnh: /usr/local/nagios/libexec/check_users -w 3 -c 3
Kết quả: USERS OK - 1 users currently logged in |users=1;3;3;0
Kiểm dung lượng một thư mục:
Câu lệnh: /usr/local/nagios/libexec/check_dirsize.sh -d
${here/cDevName} -w 10000000 -c 10000000 –f
Kết quả:3358588 KB - ok|size=3358588KB;10000000;10000000
Kiểm tra băng thông của một interface:
Câu lệnh: /usr/local/nagios/libexec/check_ifutil.pl -i eth0 -w 100M -c 100M
Kết quả: RX Bytes: 0B, TX Bytes: 0B; RX Speed: 0Bps, TX Speed: 0Bps;
OK bandwidth utilization| rx=0;104857600;104857600
tx=0;104857600;104857600 rxs=0;; txs=0;;
• Kiểm tra hiệu suất CPU:
Câu lệnh: /usr/local/nagios/libexec/check_linux_procstat.pl -f
Kết quả: OK - 4 CPU cores - CPU(all) 5.0% used, CPU0 12.0% used,
Đồ án môn học: Giám sát tài nguyên
53
CPU1 3.0% used, CPU2 4.0% used, CPU3 3.0% used
| … CPUs=4;;CPUusage=5.0%;;
• Kiểm tra số tiến trình của một chương trình SSH:
Câu lệnh: /usr/local/nagios/libexec/check_procs -a ssh
Kết quả: PROCS OK: 8 processes with args 'ssh'|procs=8;;
4.3. Hiện thực module giám sát trong Virtual Lab
Module giám sát được xây dựng bằng ngôn ngữ Java nhằm tương tác với Zenoss để
truy xuất dữ liệu và điều khiển các tiến trình giám sát trong hệ thống Zenoss. Module sử
dụng hệ cơ sở dữ liệu Mysql để lưu trữ những thông tin lấy được từ Zenoss nhằm cung
cấp cho các module quản lý tài nguyên và module tính phí.
Hình 4.10: Giao diện trang chủ của website
Trang chủ của website có chức năng ra lệnh deploy một máy ảo từ một mẫu đã được
định nghĩa trước trong hệ thống OpenNebula và chức năng yêu cầu tiến trình truy cập
vào Zenoss lấy dữ liệu giám sát về database MySql. Bên cạnh đó, với việc nhập tên host
hoặc IP sẽ cung cấp 2 chức năng xem các máy ảo đang chạy trên máy vật l{ đó hoặc
thêm máy đó vào hệ thống giám sát Zenoss. Việc thêm một thiết bị vào hệ thống giám
sát Zenoss yêu cầu khoảng 1ph – 2ph để khởi tạo thiết bị trong Zenoss, 1ph để model
thiết bị nhằm kiểm tra trạng thái thiết bị và 1 ph - 2 ph để có dữ liệu giám sát đầu tiên.
Đồ án môn học: Giám sát tài nguyên
54
Hình 4.11: Giao diện của bảng kết quả giám sát các máy vật lý
Giao diện của bảng kết quả nhằm định dạng lại dữ liệu và cung cấp giao diện để theo
dõi dữ liệu hiện có trong cơ sở dữ liệu. Tương tự giao diện trên, còn có các giao diện
thông tin máy ảo và giao diện quản lý tiến trình trong máy ảo.
Đồ án môn học: Giám sát tài nguyên
55
Chương 5. Đánh giá
Qua quá trình hiện thực, các module hiện thực tuy đã đáp ứng được những mục tiêu đề
ra nhưng vẫn còn những chức năng chưa thật sự hoàn chỉnh để tích hợp vào dự án phòng
thí nghiệm ảo. Bên cạnh đó, dữ liệu thu thập được từ các thành phần giám sát vẫn chưa
được kiểm định và so sánh kết quả với những công cụ giám sát chuyên biệt. Mặc dù những
plugin lấy dữ liệu được tổng hợp từ cộng đồng của Nagios - Zenoss được đánh giá cao bởi
người dùng nhưng cần thiết phải qua một thời gian vận hành và kiểm định từ hệ thống thực
tế. Các kết quả giám sát trong phần hiện thực được cập nhật trong khoảng thời gian 1 – 2ph
ngắn hơn mặc định của hệ thống Zenoss là 5ph nhằm đáp ứng tốt nhu cầu cho nhà quản trị.
Tuy nhiên, khoảng thời gian trên cần xem xét và điều chỉnh để phù hợp với nhu cầu giám sát
tài nguyên sử dụng với chức năng định thời. Trong giai đoạn luận văn, đề tài sẽ tiếp tục kiểm
định những dữ liệu giám sát trên hệ thống có quy mô lớn hơn nhằm rút ra những thông số
phù hợp với từng nhu cầu cụ thể.
Trong mô hình hiện thực, chức năng giám sát trực tiếp thu thập dữ liệu và cập nhật vào
cơ sở dữ liệu của hệ thống. Để sử dụng những dữ liệu này, chức năng quản lý tài nguyên và
tính toán chi phí sử dụng được phép truy cập trực tiếp vào cơ sở dữ liệu để sử dụng kết quả
giám sát. Giải pháp hiện thực này dẫn đến sự thiếu trong suốt trong quá trình tích hợp các
chức năng, dẫn đến tính linh hoạt không cao và dễ dẫn đến sự thiếu nhất quán trong dữ
liệu. Nhóm đã thống nhất và đề xuất trong giai đoạn tiếp theo sẽ hiện thực cơ chế trao đổi
thông tin sử dụng gọi hàm từ xa như XML RPC nhằm khắc phục những nhược điểm trên.
Nhìn chung các kết quả thu thập được từ hệ thống giám sát hiện tại là dựa vào từng thiết
bị độc lập trong khi nền tảng điện toán đám mây và đề tài phòng thí nghiệm ảo đòi hỏi
nhiều cấp giám sát khác nhau. Bên cạnh những dữ liệu chi tiết, dựa vào mục tiêu của các hệ
thống khác nhau đòi hỏi cần có những cấp giám sát tổng quát hơn như giám sát theo cụm
máy vật lý (Physical cluster) hay theo cụm máy ảo (Virtual cluster). Việc giám sát theo nhiều
cấp hứa hẹn là bài toán thú vị và đầy thách thức. Bên cạnh đó, đề tài sẽ tiếp tục mở rộng
khả năng tự động hóa nhận dạng sự thay đổi trong các máy giám sát như khi khám phá một
máy mới trong mạng (auto discover devices).
Đồ án môn học: Giám sát tài nguyên
56
Tài liệu tham khảo
[1] Zenoss 3.x Core Network and System Monitoring - Michael Badger
[2] Luận văn tốt nghiệp đại học: nghiên cứu các giải pháp và xây dựng mô hình cho việc
giám sát hệ thông điện toán đám mây – Nguyễn Hữu Lâm, Nguyễn Ngọc Thịnh 6/2011.
[3] Zenoss Administration – Zenoss, Inc
[4] Creating Zenoss ZenPacks for Zenoss 3 – Jane Curry
[5] Báo cáo những nguyên lý sáng tạo ứng dụng trong điện toán đám mây và công nghệ ảo
hóa - Trần Trung
[6] Zenoss Developer Guide – Jane Curry
[7] Zenoss Json API – Zenoss Core API - Zenoss, Inc
[8] OpenNebula Documentation
Website
http://community.zenoss.org
http://zenoss.com
http://en.wikipedia.org/wiki/Cloud_computing
http://nagiosplugins.org/
http://exchange.nagios.org/
http://vcl.ncsu.edu/