Bao cao-tot-nghiep-monitoring

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


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


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.


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


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.


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.


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.


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ệ đó.


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


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.


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


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.


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.


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


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)


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ó.


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


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)


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


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


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


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.


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…


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



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


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


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.


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ị:


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.


27

Hình 2.11: Chức năng Modeler Plugin

c. Monitoring Template

Hình 2.12: Chức năng Monitoring Template


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.


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


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.


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


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.


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.


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:


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


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’.


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


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


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.


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ừ


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.


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


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.


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)


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.


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


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.


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.


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 ….


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.


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


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,


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.


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.


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).


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/

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/

Documents

Bao cao-tot-nghiep-monitoring