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 Mục lục

Lời mở đầu ........................................................................................................................................................ 1 Chương 1. 1.1.

Giới thiệu đề tài ............................................................................................................................ 2

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 i

Đồ án môn học: Giám sát tài nguyên 2.3.3. 2.4.

Libvirt ......................................................................................................................................... 32

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

Hiện thực.................................................................................................................................... 44

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

ii

Đồ án môn học: Giám sát tài nguyên

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.

1


Chương 1. Giới thiệu đề tài 1.1. Bối cảnh 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

1.1.1.

2


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.

3

Đồ án môn học: Giám sát tài nguyên Đố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. 4

Đồ án môn học: Giám sát tài nguyên 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.

5


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

6

Đồ án môn học: Giám sát tài nguyên 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

7

Đồ án môn học: Giám sát tài nguyên 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. 8

Đồ án môn học: Giám sát tài nguyên  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 9

Đồ án môn học: Giám sát tài nguyên 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.

10

Đồ án môn học: Giám sát tài nguyên  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. 11

Đồ án môn học: Giám sát tài nguyên - 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

12

Đồ án môn học: Giám sát tài nguyên 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)

13


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

Đồ án môn học: Giám sát tài nguyên 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

15

Đồ án môn học: Giám sát tài nguyên 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)

16

Đồ án môn học: Giám sát tài nguyên 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 17

Đồ án môn học: Giám sát tài nguyên 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

18

Đồ án môn học: Giám sát tài nguyên 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

19

Đồ án môn học: Giám sát tài nguyên 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.

20

Đồ án môn học: Giám sát tài nguyên  Bảng so sánh tóm tắt giữa các công cụ. Auto Discovery

Agent

SNMP

Syslog

Ganglia

Via gmond check in

Yes

Via plugin

No

Yes

No

Viewing

RRDtool

Via plugin

Yes

Yes

Yes

Flat file, SQL

Yes

Yes

Yes

Full Control

RRDtool, MySQL

Nagios

Via plugin

Supported

Via plugin

Cacti

Via plugin

No

Yes

Plugins Triggers WebApp / Alerts

Data Storage Method

Name

Zabbix

Yes

Supported

Yes

Yes

Yes

Yes

Zenoss

Yes

No

Yes

Yes

Yes

Yes

Full Control Full Control

Oracle, MySQL, PostgreSQL, IBM DB2, SQLite 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… 21

Đồ án môn học: Giám sát tài nguyên 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 22

Đồ án môn học: Giám sát tài nguyên 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 23

Đồ án môn học: Giám sát tài nguyên 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. 24

Đồ án môn học: Giám sát tài nguyên  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ị: 25

Đồ án môn học: Giám sát tài nguyên  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.

26


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

c. Monitoring Template

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

Đồ án môn học: Giám sát tài nguyên Đâ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. 28

Đồ án môn học: Giám sát tài nguyên 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

Kết nối

Máy chủ Zenoss

SMNP Command RRD ZODB MySQL

Trả về dữ liệu

Máy cần giám sát

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

29

Đồ án môn học: Giám sát tài nguyên 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. 30

Đồ án môn học: Giám sát tài nguyên 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 31

Đồ án môn học: Giám sát tài nguyên 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. 32

Đồ án môn học: Giám sát tài nguyên 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.

33


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:

34


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

35

Đồ án môn học: Giám sát tài nguyên  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’.

36

Đồ án môn học: Giám sát tài nguyên 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 37

Đồ án môn học: Giám sát tài nguyên  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 38


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.

39


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ừ 40

Đồ án môn học: Giám sát tài nguyên 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.

41


Get data VM,Host

Resource System

Rest API – RRD values JSON API – ZODB data

My SQL JSON/Rest API Add VM,Host Modify VM - Host

Zenoss

JSON/Rest API

Delete VM,Host

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í

42

Đồ án môn học: Giám sát tài nguyên 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 Free Used Free Rev Trans Home Num Time Stat RAM RAM Disk Disk Bw Bw Dir Login

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.

43


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)

44


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.

45


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

46


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


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.

48


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

49


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.

50


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 51

Đồ án môn học: Giám sát tài nguyên 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, 52

Đồ án môn học: Giám sát tài nguyên 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.

53


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.

54


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

55


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/

56

Bao cao tot nghiep monitoring

Recommend Documents