Đồ án Sử dụng Saltstack triển khai hệ thống private cloud Openstack của sinh viên Nguyễn Việt Hưng
ĐỒ ÁN TỐT NGHIỆP
Đề tài:
SỬ DỤNG SALTSTACK TRIỂN KHAI HỆ THỐNG
PRIVATE CLOUD OPENSTACK
Giảng viên hướng dẫn: Th.S Nguyễn Tuấn Dũng
Sinh viên:
Nguyễn Việt Hưng
MSSV:
20081297
Lớp:
Toán tin 2 - K53
Ngày 22 tháng 5 năm 2013
Mục lục
Lời nói đầu
1
Lời cảm ơn
5
1 Điện toán đám mây
6
1.1
Khái niệm . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2
Các đặc tính cần có của mô hình cloud . . . . . . . . .
6
1.3
Phân loại . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.3.1
Phân loại theo mô hình dịch vụ cung cấp . . . .
9
1.3.2
Phân loại theo mô hình triển khai . . . . . . . .
15
Openstack . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.4.1
Khái niệm . . . . . . . . . . . . . . . . . . . . .
16
1.4.2
Cấu tạo . . . . . . . . . . . . . . . . . . . . . .
17
1.4.3
OpenStack Compute . . . . . . . . . . . . . . .
20
1.4.4
OpenStack Storage . . . . . . . . . . . . . . . .
20
1.4.5
OpenStack Networking . . . . . . . . . . . . . .
22
1.4.6
OpenStack Dashboard . . . . . . . . . . . . . .
23
1.4
i
1.4.7
Identity Service . . . . . . . . . . . . . . . . . .
23
1.4.8
Image Service . . . . . . . . . . . . . . . . . . .
24
1.4.9
Tính năng . . . . . . . . . . . . . . . . . . . . .
25
1.4.10 Cài đặt và hoạt động . . . . . . . . . . . . . . .
26
2 Quản lý cấu hình
28
2.1
Sơ lược về quản lý cấu hình . . . . . . . . . . . . . . .
28
2.2
Các tiêu chí đánh giá một hệ thống quản lý cấu hình .
29
2.3
Một số chương trình tiêu biểu . . . . . . . . . . . . . .
30
2.3.1
CFEngine . . . . . . . . . . . . . . . . . . . . .
30
2.3.2
Puppet . . . . . . . . . . . . . . . . . . . . . . .
30
2.3.3
Chef . . . . . . . . . . . . . . . . . . . . . . . .
31
2.3.4
Salt . . . . . . . . . . . . . . . . . . . . . . . .
31
2.4
Những khó khăn trong triển khai thủ công hệ thống
cloud OpenStack . . . . . . . . . . . . . . . . . . . . .
2.5
2.6
32
Lợi ích khi sử dụng trình quản lý cấu hình để triển khai
hệ thống cloud OpenStack . . . . . . . . . . . . . . . .
33
Salt
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.6.1
Khái niệm . . . . . . . . . . . . . . . . . . . . .
35
2.6.2
Mô hình và thiết kế . . . . . . . . . . . . . . . .
36
2.6.3
Master và Minion . . . . . . . . . . . . . . . . .
37
2.6.4
State . . . . . . . . . . . . . . . . . . . . . . . .
38
2.6.5
SLS . . . . . . . . . . . . . . . . . . . . . . . .
40
2.6.6
Renderers . . . . . . . . . . . . . . . . . . . . .
44
ii
2.6.7
Pillar . . . . . . . . . . . . . . . . . . . . . . . .
44
2.6.8
Grains . . . . . . . . . . . . . . . . . . . . . . .
45
2.6.9
Quá trình chạy một SLS . . . . . . . . . . . . .
46
2.6.10 Returner . . . . . . . . . . . . . . . . . . . . . .
46
3 Cài đặt hệ thống private cloud OpenStack sử dụng trình
quản lý cấu hình Salt
48
3.1
Các công việc cần thực hiện khi cài đặt OpenStack . .
48
3.2
Trên một node . . . . . . . . . . . . . . . . . . . . . .
51
3.2.1
Thiết kế state cho mysql . . . . . . . . . . . . .
51
3.2.2
Thiết kế state cho rabbitmq . . . . . . . . . . .
55
3.2.3
Thiết kế state cho keystone . . . . . . . . . . .
55
3.2.4
Thiết kế state cho glance . . . . . . . . . . . . .
58
3.2.5
Thiết kế state cho nova . . . . . . . . . . . . . .
62
3.2.6
Thiết kế state cho horizon . . . . . . . . . . . .
63
Trên nhiều node . . . . . . . . . . . . . . . . . . . . . .
64
3.3
4 Kết quả và đánh giá
4.1
4.2
66
Kết quả . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.1.1
Cloud OpenStack . . . . . . . . . . . . . . . . .
66
4.1.2
Salt . . . . . . . . . . . . . . . . . . . . . . . .
74
Đánh giá hiệu quả . . . . . . . . . . . . . . . . . . . .
75
Kết luận
76
iii
Tài liệu tham khảo
79
Danh sách hình vẽ
79
Phụ lục
81
Thiết kế state cho DNSimple
. . . . . . . . . . . . . . . . .
81
Cài đặt và sử dụng DNSimple . . . . . . . . . . . . . . . . .
82
iv
Lời nói đầu
Trong môi trường doanh nghiệp, khi nhu cầu sử dụng máy chủ tăng
lên theo quy mô của doanh nghiệp cũng là lúc nảy sinh nhiều vấn đề.
Trước hết là bài toán tối ưu để sử dụng tối đa công suất của các máy
chủ, tránh tình trạng lãng phí tài nguyên, đồng thời đòi hỏi hệ thống
có khả năng co giãn linh hoạt, chịu lỗi tốt để đảm bảo dịch vụ vẫn vận
hành khi lượng tài nguyên trên một máy tăng cao hay có sự cố xảy
ra. Tiếp đó là bài toán quản lý một lượng lớn máy chủ sao cho nhanh,
hiệu quả, tốn ít nhân lực và thời gian nhất. Giải quyết hai vấn đề trên,
trong đồ án này giới thiệu hai giải pháp cho lần lượt từng vấn đề là
xây dựng đám mây OpenStack và sử dụng công cụ quản lý cấu hình
Salt. Hai công nghệ này đều là các sản phẩm mã nguồn mở, miễn phí,
có lượng người dùng đông đảo và đặc biệt là đã đạt được những thành
công nhất định.
OpenStack là một tập hợp các chương trình mã nguồn mở chạy trên
môi trường Linux, sử dụng các công nghệ hàng đầu để xây dựng nên
một hệ thống cung cấp máy ảo theo nhu cầu của người dùng. Open-
1
Stack cho phép xây dựng hệ thống cloud trên môi trường phần cứng
tiêu chuẩn, không đòi hỏi bất cứ phần cứng hay phần mềm chuyên biệt
nào. Với thiết kế chia thành nhiều module và tuân theo các tiêu chuẩn
có sẵn khiến cho chất lượng của các bộ phận cấu thành OpenStack
nhanh chóng được phát triển và hoàn thiện, thiết kế này còn cho phép
quản trị viên tùy ý lựa chọn chương trình có cùng chức năng để thay
thế các thành phần mà họ không thích. Cũng bởi thiết kế module này
mà việc cài đặt OpenStack đòi hỏi nhà quản trị hệ thống phải có am
hiểu về các công nghệ được sử dụng và bỏ công sức cấu hình các thành
phần để vận hành được một hệ thống cloud.
Mô hình cloud cho phép hệ thống có thể sử dụng sức mạnh của
hàng nghìn máy tính, nhưng khi lượng máy tăng lên, việc quản lý các
máy tính này bắt đầu gặp những khó khăn, đặc biệt là vấn đề quản
lý cấu hình các dịch vụ chạy trên các máy chủ. Các vấn đề có thể gặp
phải:
• Cấu hình các máy chủ không có sự nhất quán: do một người
quản lý nhiều máy chủ hoặc do nhiều người cùng quản lý một
máy chủ.
• Công việc lặp đi lặp lại gây nhàm chán, tốn thời gian, công sức,
dễ nhầm lẫn.
• Các file cấu hình nằm phân tán khiến việc kiểm tra, thay đổi tốn
nhiều thời gian.
2
• Tốn nhiều thời gian và công sức nếu lượng máy tăng lên đến 100
hay thậm chí 1000 máy.
• Khó đảm bảo trạng thái của dịch vụ ở từng máy.
Chương trình quản lý cấu hình đã ra đời để giải quyết các vấn đề
nói trên. Xuất hiện từ lâu (như CFEngine - năm 1993), các chương
trình quản lý cấu hình luôn được phát triển và thay đổi theo sự đổi
mới của hệ thống, có khả năng mở rộng và tự động tốt hóa hơn.
Chef, Puppet, CFEngine là ba chương trình phổ biến nhất trong
lĩnh vực này vào thời điểm hiện tại. Các chương trình đều đã đạt được
những thành công nhất định. Bên cạnh những thành công đó, chúng
vẫn còn nhiều nhược điểm đặc biệt là vấn đề về tính phức tạp của file
cấu hình và khả năng mở rộng.
Salt là một dự án mã nguồn mở mới được bắt đầu từ năm 2011
nhưng có sự phát triển rất nhanh, luôn nhắm tới sự đơn giản, tính
module của các bộ phận cấu thành, khả năng mở rộng của hệ thống
quản lý cấu hình.
Đồ án này thực hiện tìm hiểu các khái niệm về điện toán đám mây,
đi sâu vào tìm hiểu hệ thống OpenStack. Từ đó sử dụng Salt để cài đặt
một hệ thống IaaS cloud sử dụng OpenStack - một hệ thống tương đối
phức tạp để chứng minh sự đơn giản mà linh hoạt của trình quản lý
cấu hình này. Kết quả thu được là một tập hợp các file cấu hình giúp
tiết kiệm về thời gian, công sức trong việc triển khai một hệ thống
cloud, đồng thời giúp nhanh chóng và dễ dàng mang lại trải nghiệm
3
về điện toán đám mây cho người dùng.
4
Lời cảm ơn
Em xin chân thành cảm ơn thầy Th.S Nguyễn Tuấn Dũng đã dành
thời gian để hướng dẫn em hoàn thành đồ án này. Em xin chân thành
cảm ơn các thầy cô đã dạy dỗ, chỉ bảo tận tình cho em suốt 5 năm học,
giúp em có kiến thức thực hiện đồ án này, và sẵn sàng để trở thành
một kỹ sữ, đóng góp cho sự phát triển của đất nước.
5
Chương 1
Điện toán đám mây
1.1
Khái niệm
Điện toán đám mây là mô hình cho phép dùng các tài nguyên của
máy tính một cách tiện lợi, theo nhu cầu. Các tài nguyên này được
nhà cung cấp dịch vụ dự trữ và cung cấp nhanh chóng, ít tốn công sức,
hoặc thậm chí có thể được cấp tự động.
1.2
Các đặc tính cần có của mô hình cloud
Một hệ thống cloud bất kỳ cần có các đặc tính sau:
• Tự phục vụ theo yêu cầu: người dùng có thể đơn phương dự liệu
lượng tài nguyên mình cần sử dụng. Công việc này cần được tự
động hóa, không đòi hỏi người dùng phải thông qua nhà cung
6
cấp dịch vụ.
• Truy cập rộng rãi: luôn sẵn sàng, cho phép truy cập qua mạng,
thông qua các loại client (điện thoại di động, máy tính xách tay,
máy tính để bàn, máy tính bảng...)
• Tập trung tài nguyên: Tài nguyên điện toán được sử dụng để
phục vụ cho nhiều khách hàng. Máy vật lý và máy ảo được cấp
và thu hồi linh hoạt cho các khách hàng theo nhu cầu của họ.
Người dùng không cần biết mọi thông tin địa lý liên quan đến
nơi cung cấp tài nguyên. Các tài nguyên gồm có: khả năng lưu
trữ, xử lý, bộ nhớ, băng thông mạng...
• Co giãn nhanh: có khả năng tăng hoặc giảm lượng tài nguyên khi
cần thiết. Với khách hàng, đặc tính này giúp lượng tài nguyên có
thể trở nên không giới hạn nhưng có lúc lại vừa đủ với nhu cầu
sử dụng, tùy theo yêu cầu của từng thời điểm.
• Các dịch vụ có thể đo được: để cloud có thể thực hiện các tính
năng tự động quản lý, tối ưu tài nguyên, tính toán giá thành.
Ví dụ về mô hình điện toán đám mây của Amazon: Amazon Web
Services (AWS). AWS là tập hợp các web service kết hợp với nhau tạo
thành một nền tảng điện toán đám mây. Hai thành phần nổi bật của
AWS là Amazon EC2 và Amazon S3. Các thành phần chính của AWS:
• Compute
7
Amazon Elastic Compute Cloud (EC2): dịch vụ cung cấp các
máy ảo, có thể mở rộng dễ dàng, sử dụng Xen hypervisor
• Networking
Amazon Elastic Load Balancing (Amazon ELB): phân tán các
yêu cầu truy cập ứng dụng tới nhiều máy ảo Amazon EC2, cung
cấp khả năng chịu lỗi và mở rộng.
• Storage
Amazon Simple Storage Service (S3): cung cấp nền tảng lưu trữ
dựa trên web service
Amazon Elastic Block Store (EBS): cung cấp các volume lưu trữ
mức khối cho EC2
• Database
Amazon RDS: cung cấp các máy chủ cơ sở dữ liệu quan hệ:
MySQL, Oracle, và SQL Server.
Amazon DynamoDB: cung cấp các máy chủ cơ sở dữ liệu hỗ trợ
NoSQL
Amazon ElastiCache: cung cấp dịch vụ caching trong bộ nhớ, hỗ
trợ Memcached
• Ngoài ra AWS còn cung cấp các dịch vụ tầng ứng dụng như: dịch
vụ thông báo, dịch vụ chuyển đổi video, ảnh, dịch vụ truyền tải
8
thông điệp giữa các máy, dịch vụ theo dõi và quản lý máy ảo,
ứng dụng, ...
1.3
1.3.1
Phân loại
Phân loại theo mô hình dịch vụ cung cấp
Infrastructure as a service (IaaS)
IaaS cung cấp các máy tính (máy vật lý hoặc máy ảo) và các tài
nguyên khác. Một hypervisor (bộ phận quản lý máy ảo) đảm nhận
chạy các máy ảo. Một tập hợp các hypervisor trong hệ thống cloud
có thể cung cấp một lượng lớn các máy ảo, có thể mở rộng hoặc thu
hẹp mô hình theo yêu cầu của khác hàng. IaaS thường hỗ trợ các tài
nguyên khác như file ảnh, lưu trữ, tường lửa, cân tải, địa chỉ IP, mạng
nội bộ ảo (VLANs), và các bộ phần mềm. Nguồn tài nguyên phục vụ
cho việc cung cấp theo yêu cầu được lấy kho tài nguyên phần cứng
trong các trung tâm dữ liệu của nhà cung cấp dịch vụ.
Các nhà cung cấp IaaS trên thế giới: Amazon EC2, Windows Azure
Virtual Machines, DynDNS, Google Compute Engine, Rackspace Cloud,
HP Cloud, ...
Ví dụ về IaaS: Windows Azure Virtual Machines cho phép tạo các
máy ảo từ kho các file ảnh sẵn có hoặc sử dụng file ảnh do người dùng
cung cấp. Người sử dụng có toàn quyền điều khiển máy ảo đã tạo. Với
9
dashboard, người dùng có thể theo dõi tình trạng của máy ảo qua biểu
đồ thời gian thực.
Hình 1.1: Dashboard của Windows Azure
Platform as a service (PaaS)
PaaS đưa ra một nền tảng điện toán bao gồm cả hệ điều hành, môi
trường lập trình, cơ sở dữ liệu và máy chủ web. Các nhà phát triển
ứng dụng có thể phát triển, chạy các giải pháp phần mềm của họ trên
một nền tảng cloud mà không cần lo đến chi phí và sự phức tạp của
việc mua và quản lý hạ tầng phần cứng và phần mềm bên dưới. Một
số nhà cung cấp PaaS hỗ trợ tự động cung cấp thêm tài nguyên theo
10
nhu cầu khi cần thiết. Các tổ chức cung cấp PaaS: Heroku, Google
App Engine, Windows Azure, ...
Ví dụ về PaaS: Heroku
Heroku cung cấp nền tảng hỗ trợ môi trường lập trình các ngôn
ngữ Ruby, Java, Node.js Scala, Clojure, Python và PHP cùng với các
cơ sở dữ liệu như PostgreSQL, MongoDB, Redis, ... trên nền tảng hệ
điều hành Debian và Ubuntu. Các nhà phát triển phần mềm đưa mã
nguồn vào hệ thống của Heroku, cấu hình cách chương trình sẽ chạy.
Việc chạy phần mềm do hệ thống của heroku tự động thực hiện. Lượng
tài nguyên ứng dụng sử dụng được đo và ghi lại, nhà phát triển sẽ trả
tiền cho lượng tài nguyên đó.
Hình 1.2: Giao diện dashboard của Heroku
11
Software as a service (SaaS)
SaaS là một mô hình phân phối phần mềm, trong đó các ứng dụng
sẽ được cung cấp, quản lý, vận hành bởi một nhà cung cấp dịch vụ,
người dùng có thể truy cập qua mạng. Toàn bộ ứng dụng và dữ liệu
người dùng đều được lưu trữ bởi nhà cung cấp dịch vụ. Người dùng
thường truy cập SaaS qua trình duyệt Web. Ví dụ: Gmail, Box.net,
Mediafire, ...
Ví dụ về SaaS: Google Drive
Người dùng đăng ký sử dụng dịch vụ. Với tài khoản đã đăng ký,
Google cung cấp cho người dùng một lượng dung lượng lưu trữ và khả
năng truy cập ứng dụng Google Driver trực tuyến. Với ứng dụng web
này, người dùng có thể soạn thảo, lưu trữ, chia sẻ các file văn bản,
bảng tính tương tự như sản phẩm Word, Excel chạy trên các máy tính
của Microsoft Office. Người dùng chỉ cần có một client để truy cập và
sử dụng ứng dụng ở bất cứ nơi đâu.
12
Hình 1.3: Giao diện soạn thảo Spreadsheet của Google Drive
Ba mô hình nói trên thực hiện cung cấp các dịch vụ ở ba tầng khác
nhau. Các dịch vụ tầng trên nên được xây dựng trên các dịch vụ tầng
thấp hơn để nâng cao khả năng mở rộng của toàn bộ hệ thống.
13
Hình 1.4: Phân tầng chức năng của từng mô hình dịch vụ
Hình minh họa 1.4 chỉ rõ chức năng của mỗi mô hình đảm nhận. Ở
mỗi dịch vụ, nhà cung cấp sẽ quản lý các phần có tô màu xám, người
dùng sẽ được quản lý các phần tô màu xanh. Với IaaS, người dùng sẽ
không cần lo lắng về hạ tầng mạng, khả năng lưu trữ, máy vật lý và
công nghệ ảo hóa mà chỉ cần quản lý hệ điều hành và các ứng dụng
chạy trên đó. Với PaaS, phần quản lý của người dùng thu hẹp lại chỉ
còn dữ liệu và ứng dụng của họ, mọi thứ khác đều do nhà cung cấp
dịch vụ quản lý và vận hành. Đến mô hình SaaS thì người dùng không
còn quản lý bất cứ tài nguyên nào, tất cả những gì họ có là quyền truy
cập đến dịch vụ, ngay cả dữ liệu cá nhân của người dùng cũng do nhà
14
cung cấp nắm giữ và quản lý.
Ngoài ba mô hình trên, còn có các mô hình khác như Database as
a service (DBaaS), Network as a service (NaaS)...
1.3.2
Phân loại theo mô hình triển khai
Public cloud
Public cloud là loại cloud cung cấp các tài nguyên (ứng dụng, lưu
trữ, ...v.v) bởi một nhà cung cấp. Các dịch vụ này có thể miễn phí
hoặc trả tiền theo mức sử dụng. Các nhà cung cấp public cloud như
Amazon AWS, Microsoft, Google, Heroku, ...
Private cloud
Private cloud là cloud được vận hành bởi một tổ chức. Tổ chức này
sẽ tự làm nhiệm vụ xây dựng, vận hành và quản lý cloud.
So sánh public cloud và private cloud
Tiểu chuẩn
Public cloud
Private cloud
Chi phí khởi đầu
Không có / thấp
Cao
Chi phí vận hành
Có thể dự trù
Không thể dự trù
Tùy biến
Không thể
Có thể
Sự riêng tư
Không
Có
Đăng nhập một lần
Không thể
Có thể
Mở rộng
Dễ dàng nhưng trong giới hạn
không giới hạn
15
Ngoài ra còn có một số mô hình khác kết hợp bởi hai mô hình trên
như Community cloud, Hybrid cloud.
1.4
Openstack
1.4.1
Khái niệm
Openstack là một bộ công cụ để tạo ra môi trường điện toán đám
mây sử dụng các công nghệ có sẵn trên nền tảng Linux. OpenStack
không đòi hỏi các thiết bị phần cứng, phần mềm chuyên dụng, nó có
khả năng tương thích với các hệ thống đã tồn tại và các công nghệ
từ bên thứ ba. OpenStack được thiết kế để tự động quản lý nguồn tài
nguyên tính toán, nó có thể làm việc với các công nghệ ảo hóa phổ
biến cũng như hệ thống tính toán hiệu năng cao.
OpenStack thường được dùng để cung cấp:
• IaaS hoặc nền tảng để cung cấp các dịch vụ ở lớp cao hơn (PasS,
SaaS, ...)
• phòng IT hoạt động như một nhà cung cấp dịch vụ cloud cho
các đơn vị kinh doanh, các nhóm dự án.
• xử lý dữ liệu lớn (big data) với các công cụ như Hadoop
• thay đổi tài nguyên dựa theo yêu cầu cho các website và ứng
dụng
16
• các môi trường tính toán hiệu năng cao đòi hỏi xử lý các công
việc đa dạng và liên tục, cường độ cao.
1.4.2
Cấu tạo
OpenStack là sự kết hợp của nhiều công nghệ, giải pháp đã tồn tại
với những dự án do chính OpenStack phát triển.
Các dịch vụ của OpenStack được thiết kế với các tiêu chí:
• Có kiến trúc module: giúp nhanh chóng thêm các tính năng mới.
• Tính sẵn sàng cao: đảm nhiệm những công việc quan trọng.
• Có khả năng chịu lỗi: tách rời các tiến trình giúp chống hiện
tượng dịch vụ đổ vỡ hàng loạt.
• Có khả năng khôi phục: dễ dàng phân tích, debug, điều chỉnh.
• Dùng các tiêu chuẩn mở: giúp loại bỏ các nguy cơ tiềm ẩn, tạo cơ
hội để kết hợp với các ngành khác như điện toán di động, phân
tích kinh doanh.
17
Hình 1.5: Sơ đồ tương tác của các dịch vụ trong OpenStack
Sơ đồ trên biểu diễn sự tương tác giữa các dịch vụ thành phần
của OpenStack, các vòng tròn biểu diễn các dịch vụ cung cấp bởi
OpenStack, các hình chữ nhật là các thành phần bên ngoài, không
được bảo trì bởi dự án OpenStack.
Mọi service của OpenStack tương tác với một hàng đợi (RabbitMQ,
Qpid) và một database (MySQL, PostgreSQL). Nova-api, identity ser18
vice, và image service là các service độc lập, không dựa vào các công
nghệ bên ngoài.
Các thành phần của OpenStack có thể được thay thế bởi nhiều giải
pháp tương ứng. Dưới đây là bảng các công nghệ và các giải pháp đã
triển khai để phục vụ công nghệ đó
Công nghệ
Các chương trình đã hỗ trợ
Hàng đợi thông điệp RabbitMQ, Qpid, ZeroMQ
iSCSI back-end
LVM+IET, LVM+tgt,NetApp, Xen Storage
Manager, Ceph SAN , NexentaStor, Sheepdog
Cơ sở dữ liệu
MySQL, PostgreSQL, sqlite
Web server
Apache, Nginx
Session cache
memcache, MySQL, PostgreSQL, sqlite
Openstack bao gồm các dịch vụ chuyên biệt như Compute, Dashboard,
Networking, Storage đảm nhiệm những công việc riêng. Ngoài ra nó có
các dịch vụ được dùng trong cả ba tầng tính toán, lưu trữ và mạng.
Những dịch vụ này giúp việc cài đặt và vận hành cloud dễ dàng hơn,
chúng bao gồm: dịch vụ xác thực, quản lý file ảnh, và một giao diện
19
(API) giúp liên kết các thành phần của OpenStack với nhau cũng như
với các hệ thống bên ngoài để cung cấp một trải nghiệm thống nhất
cho người dùng khi họ sử dụng các tài nguyên cloud khác nhau.
1.4.3
OpenStack Compute
OpenStack compute cung cấp và quản lý các máy ảo. Nó cung cấp
tài nguyên tính toán qua các API cho lập trình viên xây dựng ứng
dụng cloud và qua giao diện web cho người dùng cũng như người quản
lý. Compute sử dụng các công nghệ hypervisor phổ biến như KVM,
XenServer, hay Linux Container (LXC) nếu cần thiết. Bên cạnh hỗ trợ
các hypervisor khác nhau, OpenStack Compute còn hỗ trợ kiến trúc
ARM và các kiến trúc phần cứng khác. Compute dựa vào 1 driver ảo
hóa để quản lý máy ảo, mặc định là libvirt, được dùng để quản lý
KVM. Compute đưa ra khái niệm về khuôn mẫu cho các máy ảo. Mỗi
khuôn mẫu định nghĩa lượng RAM và kích thước ổ cứng. Khi máy ảo
chạy với một khuôn mẫu cụ thể, Openstack Compute điều chỉnh kích
thước đĩa ảnh cho phù hợp với khuôn đưa ra và cấp CPU, RAM theo
yêu cầu.
1.4.4
OpenStack Storage
OpenStack đã hỗ trợ Object Storage và Block Storage, với nhiều
lựa chọn cài đặt tùy theo yêu cầu sử dụng.
20
Object Storage là công nghệ lưu trữ lý tưởng với hiệu quả về giá
thành và khả năng mở rộng không gian lưu trữ. Nó cung cấp nền tảng
lưu trữ phân tán, có thể truy cập qua API giúp dễ dàng cho việc viết
ứng dụng backup, archiving. Công nghệ này còn cho phép các thiết
bị khối (block devices) được kết nối với các máy ảo để mở rộng lưu
trữ, cho hiệu năng cao hơn và có thể tích hợp với các nền tảng lưu trữ
doanh nghiệp như NetApp, Nexenta, SolidFire.
Tính năng của Object Storage
• OpenStack Storage cung cấp giải pháp lưu trữ object sử dụng
các cụm máy chủ đã được chuẩn hóa có khả năng lưu trữ nhiều
petabyte dữ liệu.
• Object Storage không phải là một hệ thống file truyền thống mà
là hệ thống lưu trữ phân tán các dữ liệu tĩnh như file ảnh của
máy ảo, hình ảnh, email, backup.
• Các đối tượng và file được ghi vào nhiều đĩa trải khắp suốt các
máy chủ trong trung tâm dữ liệu, OpenStack chịu trách nhiệm
cho việc đảm bảo sự dư thừa và tính toàn vẹn cho dữ liệu xuyên
suốt các cụm máy.
• Các cụm máy dễ dàng mở rộng bằng việc thêm các máy chủ mới.
Khi một máy chủ hay ổ cứng bị hỏng, dữ liệu được tạo lại từ các
máy trong cụm rồi phân tán đến các vùng khác. Do sử dụng logic
phần mềm để thực hiện đảm bảo dư thừa và phân tán khắp các
21
thiết bị nên các phần cứng thông thường đều có thể được dùng
cho việc lưu trữ, không đòi hỏi phần cứng chuyên dụng.
Tính năng của Block Storage
• Hệ thống lưu trữ khối quản lý việc tạo, gắn và tháo các thiết bị
khối với các máy chủ. Nó được tích hợp hoàn toàn với OpenStack
compute và Dashboard cho phép người dùng cloud tự quản lý nhu
cầu về lưu trữ của họ.
• Bên cạnh việc sử dụng máy chủ Linux để lưu trữ, nó còn hỗ trợ
nhiều nền tảng lưu trữ khác như Ceph, NetApp, Nexenta, và
SolidFire
• Block storage thích hợp cho các trường hợp đòi hỏi hiệu năng
cao (như lưu trữ cơ sở dữ liệu), yêu cầu hệ thống file có thể mở
rộng hoặc cần cung cấp một máy chủ với khả năng truy cập mức
thấp đến thiết bị lưu trữ.
• Khả năng quản lý snapshot cung cấp chức năng mạnh mẽ cho việc
backup dữ liệu chứa trên các thiết bị lưu trữ khối. Các snapshot
có thể dùng để khôi phục hoặc tạo một thiết bị lưu trữ khối mới.
1.4.5
OpenStack Networking
Giải quyết các vấn đề liên quan đến kết nối mạng giữa các máy ảo
với nhau và ra bên ngoài mạng internet. Sử dụng các công nghệ như
22
Open vSwitch, Cisco UCS/Nexus, Linux Bridge, VLAN... giúp dễ mở
rộng hệ thống mạng, việc quản lý IP và điều khiển mạng dựa trên API.
1.4.6
OpenStack Dashboard
Cung cấp giao diện đồ họa cho người quản trị và người dùng giúp
dự liệu và tự động các nguồn tài nguyên trên cloud. Có thiết kế giúp
dễ dàng tích hợp dịch vụ và sản phẩm của bên thứ ba. Hỗ trợ VNC
client dựa trên nền web, cung cấp khả năng truy cập đến máy ảo qua
VNC consoles.
1.4.7
Identity Service
OpenStack Identity có hai tính năng chính:
• Quản lý người dùng: cung cấp một thư mục trung tâm ánh xạ
người dùng đến các dịch vụ OpenStack họ được phép truy cập.
Nó là một hệ thống xác thực chung xuyên suốt cloud và có thể
tích hợp với dịch vụ thư mục đã có như LDAP. Hỗ trợ nhiều hình
thức xác thực bao gồm xác thực bằng tài khoản và mật khẩu,
token...
• Cung cấp danh mục dịch vụ: cung cấp một danh sách các dịch
vụ đã triển khai trong cloud OpenStack. Người dùng và các công
cụ của bên thứ ba có thể xem xét nguồn tài nguyên nào họ được
phép truy cập thông qua lập trình.
23
Với quyền người quản trị, OpenStack Identity cho phép:
• Cấu hình tập trung các chính sách xuyên suốt hệ thống.
• Tạo người dùng và bên thuê, định nghĩa quyền hạn sử dụng các
tài nguyên tính toán, lưu trữ và mạng thông qua tính năng điểu
khiển truy cập dựa trên vai trò (RBAC)
• Tich hợp với một thư mục đã tồn tại như LDAP, tạo nên một cơ
chế xác thực duy nhất cho toàn doanh nghiệp.
Với quyền người dùng, OpenStack cho phép:
• Lấy danh sách các dịch vụ có thể truy cập
• Gửi yêu cầu API hoặc đăng nhập vào web dashboard để tạo các
tài nguyên mà tài khoản đã được cấp.
1.4.8
Image Service
Dịch vụ OpenStack Image cung cấp tính năng khám phá, đăng ký
và truyền tải các dịch vụ liên quan đến đĩa và file ảnh máy chủ. Có
thể sao chép hoặc snapshot một file ảnh máy chủ và lưu trữ nó ngay
lập tức là một tính năng mạnh mẽ của cloud OpenStack. Các ảnh máy
chủ đã được lưu trữ được dùng như một khuôn mẫu để khởi tạo một
máy chủ mới nhanh chóng hơn và thống nhất hơn khi cần dự trù nhiều
máy chủ thay vì việc cài đặt từng hệ điều hành và cấu hình riêng các
24
dịch vụ đi kèm. Nó có thể dùng để lưu trữ và lập danh mục một lượng
backup không giới hạn.
Image Service có thể lưu trữ đĩa và ảnh máy chủ thông qua nhiều
back-end, bao gồm các hệ thống file, OpenStack Object Storage, Ceph....
API cung cấp một giao diện RESTFUL cho việc truy cập thông tin về
đĩa ảnh và cho phép người dùng lấy các đĩa ảnh về máy chủ mới.
Các tính năng của Image Service gồm:
• Quản trị viên có thể tạo các khuôn mẫu để từ đó người dùng có
thể chạy các máy ảo mới
• Người dùng được tùy ý lựa chọn các file ảnh có sẵn, hoặc có thể
tự tạo file ảnh của riêng họ nếu muốn.
• Lưu trữ các snapshot, giúp backup máy ảo nhanh chóng
1.4.9
Tính năng
• Quản lý tập trung tài nguyên máy chủ và CPU, bộ nhớ, đĩa cứng,
card mạng đã ảo hóa. Nâng cao khả năng tận dụng, tự động hóa
các nguồn tài nguyên, nâng cao hiệu quả sử dụng tài nguyên, tiết
kiệm chi phí.
• Quản lý mạng LAN, Flat, Flat DHCP, VLAN DHCP, IPv6. Hỗ
trợ tính năng cấp IPs và VLANs bằng lập trình, linh hoạt trong
25
việc thiết kể mô hình mạng, phù hợp với yêu cầu của ứng dụng
và người dùng.
• Kiến trúc phân tán và không đồng bộ: khả năng mở rộng và nâng
cao tính sẵn sàng của hệ thống
• Quản lý file ảnh máy ảo: dễ dàng lưu trữ, nhập, xuất, chia sẻ file
ảnh.
• Quản lý máy ảo trực tiếp: tăng năng suất với sự quản lý vòng
đời của máy ảo.
• IP động: khả năng gán và gán lại IP cho các máy ảo
• Bảo mật theo nhóm: linh hoạt gán và điều khiển quyền truy cập
máy ảo bằng cách tạo các tổ hợp tài nguyên riêng biệt.
• Điểu khiển truy cập dựa trên vai trò.
• VNC Proxy qua trình duyệt web: dễ dàng, nhanh chóng trong
việc quản trị bằng dòng lệnh
• Lưu trữ và quản lý file bằng lập trình thông qua API: tự động
quản lý và dự phòng tài nguyên
1.4.10
Cài đặt và hoạt động
Việc cài đặt OpenStack có thể thực hiện trên một máy hoặc nhiều
máy. Việc cài đặt trên một máy chỉ mang mục đích thử nghiệm. Trong
26
môi trường sản phẩm, các dịch vụ nên được cài riêng trên các máy chủ
khác nhau. Công việc cài đặt gồm các bước sau:
1. Cài đặt Identity Service (Keystone) và tạo dữ liệu về phân quyền,
phân nhóm ban đầu
2. Cài đặt Image Service (Glance) phục vụ cho việc lưu trữ file ảnh hệ
điều hành
3. Cài đặt Networking (Nova-network/Quantumn), chịu trách nhiệm
cấp IP, NAT cho các máy ảo sẽ được tạo
4. Cài đặt Compute (Nova-compute), thực hiện chạy máy ảo
5. Cài đặt Dashboard(horizon) để quản lý các máy ảo bằng giao diện
web
6. Cài đặt hệ thống lưu trữ (Swift hoặc nova-volume/cinder) phục vụ
mọi hoạt động liên quan đến lưu trữ (không bắt buộc)
27
Chương 2
Quản lý cấu hình
2.1
Sơ lược về quản lý cấu hình
Quản lý cấu hình (Configuration Management) là một quá trình
thiết lập và duy trì tính nhất quán về tốc độ, tính năng của một hệ
thống, một dịch vụ với yêu cầu, thiết kế và các thông tin vận hành
xuyên suốt vòng đời của nó.
Việc quản lý cấu hình thường thực hiện bởi quá trình xây dựng
trước mẫu cho các chương trình cần quản lý và chỉ cần thêm thông
số phù hợp khi sử dụng. Các máy chủ sẽ tải cấu hình dành cho mình
về và thực thi các công việc cài đặt, cấu hình để đạt được một trạng
thái định trước. Quản lý cấu hình thường sử dụng ngôn ngữ của vấn
đề cần giải quyết để che đi sự phức tạp, khác biệt giữa các nền tảng ở
phía dưới. Một số chương trình hỗ trợ chức năng để đảm bảo máy chủ
28
luôn có một cấu hình như đã định trước ngay cả khi cấu hình máy chủ
đó đã bị người dùng thay đổi thủ công.
2.2
Các tiêu chí đánh giá một hệ thống
quản lý cấu hình
• Tính đơn giản: Đối tượng sử dụng các hệ thống quản lý cấu
hình chủ yếu là các nhà quản trị và vận hành hệ thống. Bởi vậy
tính đơn giản là một trong những tiêu chuẩn hàng đầu khi đánh
giá. Những chương trình sử dụng ngôn ngữ phức tạp để viết file
cấu hình có thể gây khó khăn cho việc sử dụng của người dùng.
• Tính linh hoạt: Một mẫu cấu hình cần có khả năng áp dụng
cho nhiều máy khác nhau, với những thay đổi tùy thuộc theo các
thông số của từng máy.
• Khả năng mở rộng tính năng: nhu cầu dễ dàng thêm các
thành phần của bên thứ ba vào một chương trình quản lý cấu
hình là cần thiết. Giúp các nhà phát triển dễ dàng thêm các
thành phần của họ, đồng thời giúp chương trình có thể sử dụng
ở một môi trường chuyên biệt mà không đòi hỏi thay đổi mã
nguồn chương trình.
• Khả năng mở rộng hệ thống (scaling): với những hệ thống
lớn, mô hình của chương trình quản lý cấu hình sử dụng ảnh
29
hưởng lớn tới khả năng mở rộng của nó. Một chương trình sử
dụng mô hình máy chủ - máy khách với một máy chủ duy nhất
sẽ dẫn đến quá tải và không thể mở rộng hệ thống.
2.3
2.3.1
Một số chương trình tiêu biểu
CFEngine
Dự án bắt đầu từ năm 1993, CFEngine ra đời đã trải qua nhiều
phiên bản và thay đổi lớn. Phiên bản mới nhất là CFEngine3. CFEngine
là chương trình đã tồn tại lâu nhất trong lĩnh vực này, với toàn bộ mã
nguồn viết bằng C, không phục thuộc vào chương trình bên ngoài.
CFEngine là chương trình hỗ trợ nhiều nền tảng nhất, và thuộc loại
chạy nhanh nhất và sử dụng ít tài nguyên nhất trong các chương trình
quản lý cấu hình. CFEngine được sử dụng bởi các tổ chức lớn như
AT&T, ADM, LinkedIn, Ebay, Cisco, IBM, NASA,... Điểm yếu lớn
nhất của CFEngine là ngôn ngữ cấu hình phức tạp.
2.3.2
Puppet
Phổ biến thứ hai sau CFEngine, Puppet có cộng đồng người dùng
rộng rãi nhờ ngôn ngữ cấu hình đơn giản hơn nhiều so với CFEngine
hay Chef. Sử dụng ngôn ngữ thủ tục riêng của Puppet để viết cấu hình
hệ thống. Năm 2010, Puppet đã thêm tính năng sử dụng Ruby DSL
30
để nâng cao tính linh động của file cấu hình nhưng đồng thời cũng làm
giảm đi tính đơn giản vốn có của Puppet.
Các khách hàng lớn: Twitter, Nokia, SugarCRM,...
2.3.3
Chef
Chef được xây dựng ngay từ đầu nhắm tới thị trường cloud computing. Chef đứng thứ ba về độ phổ biến trong thị phần các chương
trình quản lý cấu hình. Chef dụng ngôn ngữ Ruby để viết cấu hình hệ
thống, điều này giúp sự linh hoạt trong cấu hình của Chef là không
giới hạn nhưng cũng là rảo cản lớn nhất cho người dùng khi họ phải
học một ngôn ngữ lập trình.
Chef được sử dụng bởi nhiều hãng công nghệ trên thế giới trong
đó có Facebook và DreamHost.
2.3.4
Salt
Salt mới xuất hiện từ năm 2011 và đang trong quá trình phát triển
rất mạnh mẽ. Ngay từ khi ra đời, Salt nhanh chóng thu hút được sự
quan tâm của cộng đồng bởi tính đơn giản trong cấu hình và mô hình
có khả năng mở rộng. Salt sử dụng định dạng YAML để viết file cấu
hình kết hợp với một engine render template. Yếu tố này mang lại sự
đơn giản và linh hoạt cho Salt, việc viết một file cấu hình bằng YAML
đơn giản hơn rất nhiều so với việc học một ngôn ngữ lập trình mới.
31
Các khách hàng nổi bật của Salt có thể kể đến HP cloud, Rackspace,
LinkedIn, Paypal.
Đồ án này sẽ sử dụng Salt để thực hiện quản lý cấu hình, bởi sau
khi thử nghiệm qua cả bốn chương trình này, Salt tỏ ra là chương trình
có ngôn ngữ cấu hình đơn giản hơn cả, kết hợp với tài liệu chính thức
của Salt rất dễ đọc, dễ hiểu, giúp giảm bớt thời gian học dùng Salt.
2.4
Những khó khăn trong triển khai thủ
công hệ thống cloud OpenStack
Việc cài đặt OpenStack thủ công gặp phải những khó khăn:
• Đòi hỏi thực hiện một lượng lớn công việc để cài đặt và cấu hình
nhiều phần mềm. OpenStack là một tập hợp các phần mềm mã
nguồn mở để tạo nên một hệ thống cloud, tính module của mô
hình này là ưu điểm cho phép phát triển độc lập các thành phần
nhưng cũng đồng thời là nhược điểm khiến cho quá trình cài đặt
trở nên phức tạp hơn.
• Việc cài đặt lặp đi lặp lại khi cần cài trên nhiều node. Một hệ
thống cloud trong môi trường chạy thật luôn đòi hỏi được cài
trên tối thiểu 3 máy vật lý có cấu hình mạnh. Khi cần đảm bảo
tính sẵn sàng và khả năng chia tải, hệ thống cần sử dụng thêm
nhiều máy vật lý để đảm bảo các nhu cầu của cloud.
32
• Việc thay đổi cấu hình của một bộ phận trong cloud đòi hỏi phải
thực hiện trên nhiều máy vật lý. Quá trình cấu hình lại bằng tay
luôn tiềm ẩn lỗi do sự bất cẩn của quản trị viên khi phải làm
một lượng công việc lớn.
• Khi cần triển khai một hệ thống cloud mới, phải thực hiện cài
đặt từ đầu. Người vận hành cloud có thể sử dụng các script để
phục vụ việc tự động hóa, nhưng việc này kém linh hoạt, phức
tạp và mang lại năng suất thấp hơn so với việc sử dụng một hệ
thống quản lý cấu hình tập trung.
2.5
Lợi ích khi sử dụng trình quản lý cấu
hình để triển khai hệ thống cloud OpenStack
Sử dụng một chương trình quản lý cấu hình trong quá trình triển
khai hệ thống cloud OpenStack sẽ mang lại những lợi ích sau:
• Tự động hóa công việc cài đặt và cấu hình, dễ dàng mở rộng
hệ thống khi cần triển khai tới hàng trăm, thậm chí hàng nghìn
máy. Giảm sức lực và nhân lực cần thiết để quản lý một hệ thống
lớn.
• Việc cài đặt và cấu hình được thực hiện đồng thời trên nhiều
33
máy cùng lúc, giúp giảm thời gian triển khai hệ thống. So với
thực hiện bằng tay, sử dụng chương trình quản lý cấu hình giúp
tăng tốc độ thực hiện lên gấp N lần khi phải cài đặt trên N máy.
So với thực hiện bằng một script với khả năng chạy song song
thì chương trình quản lý cấu hình đơn giản, nhanh và bảo mật
hơn.
• Khi cần thay đổi, chỉ cần thay đổi một lần tại một máy duy
nhất, các máy cần thay đổi sẽ tự động thay đổi theo. Ưu điểm
này giúp giảm bớt lượng công việc cần làm của nhà quản trị đồng
thời giảm nguy cơ về lỗi trong quá trình thực hiện.
• Nếu quá trình cài đặt xảy ra lỗi, hệ thống sẽ tự thu thập lỗi và
trả về máy quản lý. Nhờ vậy, giảm thiểu được một lượng lớn công
việc, không cần đăng nhập vào từng máy để xem lỗi xảy ra. Các
log về lỗi xảy ra có thể được lưu trữ và phân tích phục vụ quá
trình giải quyết lỗi.
• Dễ dàng kết hợp với các hệ thống logging và monitor để tự động
theo dõi và quản lý cloud nhờ tính phân tán của mô hình quản
lý cấu hình.
• Cấu hình hệ thống cloud có thể sử dụng lại khi cần triển khai
các hệ thống khác. Nếu được thực hiện tốt, cấu hình này thậm
chí có thể sử dụng trên nhiều nền tảng khác nhau, hỗ trợ cho
quá trình nghiên cứu, học tập và thử nghiệm.
34
• Thích hợp cho việc chia nhỏ công việc, phát triển và thử nghiệm
từng nhóm chức năng của cloud cho nhiều nhóm phát triển. Tăng
tính chuyên môn hóa trong công việc và nâng cao chất lượng của
hệ thống.
• Luôn đảm bảo các node trong hệ thống cloud ở một trạng thái
định trước, lập tức thông báo khi có sự cố khiến cho các dịch vụ
hoạt động sai lệch so với dự định. Tính năng này giúp đảm bảo
tính nhất quán của việc quản lý hệ thống, đồng thời giúp phát
hiện và ngăn chặn kịp thời khi cấu hình hệ thống bị thay đổi.
2.6
2.6.1
Salt
Khái niệm
SaltStack hay Salt là chương trình quản lý hệ thống và cấu hình
mã nguồn mở. Hệ thống Salt xây dựng trên một mô hình phân tán
và có khả năng phân tầng (Salt Syndic). Salt được viết bằng ngôn
ngữ Python, các node trong mô hình tương tác với nhau qua hàng đợi
thông tin (Message Queue) sử dụng thư viện ZeroMQ. Salt gồm có hai
chức năng chính:
• Thực thi lệnh từ xa (Remote execution)
• Quản lý cấu hình dựa trên nền tảng thực thi lệnh từ xa
35
2.6.2
Mô hình và thiết kế
• Salt được chia nhỏ thành các module nhỏ, mỗi module đảm nhiệm
một chức năng riêng.
• Việc xây dựng trên thư viện ZeroMQ thay vì một hệ thống
AMQP riêng biệt giúp Salt trở nên nhẹ và nhanh hơn, không
cần tốn tài nguyên duy trì thêm một dịch vụ chạy AMQP. Đồng
thời sử dụng ZeroMQ giúp chuyển file hay data qua nhiều mô
hình mạng phức tạp một cách dễ dàng hơn.
• Tính năng thực thi lệnh từ xa giúp thay thế việc sử dụng SSH.
Sau khi hệ thống Salt được thiết lập, quản trị viên có thể thực
hiện thực thi lệnh trên nhiều máy cùng lúc. Việc chọn nhóm để
thực thi lệnh dễ dàng được quyết định bởi quản trị viên.
• Mô hình phân tầng giúp có thể mở rộng hệ thống lên tới hàng
trăm nghìn máy. Nếu không có mô hình này, khi thực thi triển
khai cấu hình, các máy sẽ cùng lấy thông tin cần thiết từ một
máy tính duy nhất và có thể khiến máy này bị quá tải.
• Tính modular giúp dễ dàng phát triển và mở rộng tính năng cho
Salt. Tạo cơ hội cho bên thứ ba tham gia đóng góp phát triển để
sử dụng Salt quản lý sản phẩm của chính họ.
36
2.6.3
Master và Minion
Một hệ thống quản lý cấu hình dùng Salt bao gồm một hoặc nhiều
máy tính đóng vai trò master. Các máy master chứa các file cấu hình.
Các máy được quản lý cấu hình để chạy các dịch vụ đóng vai trò là
minion và nhận lệnh từ phía master. Các minion khi bắt đầu chạy sẽ
gửi yêu cầu được quản lý tới máy master, các minion được chấp nhận
mới có thể được master quản lý.
Hình 2.1: Mô hình Master - Minion của Salt
37
2.6.4
State
Salt sử dụng hệ thống file cấu hình gọi là SLS (SaLt State file) để
cấu hình các dịch vụ trên máy minion. Mỗi SLS chứa nhiều state, mỗi
state đảm bảo một trạng thái nào đó cho máy mà state đó được thực
thi. Các state cùng liên quan đến một dịch vụ thường được tập trung
vào một SLS hay nhiều SLS trong cùng một thư mục.
Một state mô tả trạng thái mà hệ thống cần có được (phần mềm
được cài, dịch vụ đang chạy, file cấu hình tồn tại, lệnh đã được thực
thi...) Các state của Salt được chứa trong các file có đuôi mở rộng là
"sls". Một state bắt buộc phải chứa các thuộc tính:
• ID: ID của state phải là duy nhất
• loại state: các state có sẵn hoặc do người dùng thêm vào hệ
thống Salt. Ví dụ: pkg để quản lý gói (trạng thái cài đặt...), file
để quản lý file (tồn tại, mode, user, ,..), service để quản lý một
dịch vụ trên Linux (trạng thái của dịch vụ, các file mà dịch vụ
theo dõi...).
• trạng thái: quy định thạng thái của state, phụ thuộc vào loại
state được sử dụng. Ví dụ:
pkg có các trạng thái :
– installed: đảm bảo package đã được cài đặt. Việc thực hiện
cài đặt do các chương trình quản lý gói của từng hệ điều
38
hành đảm nhiệm (apt-get với Ubuntu/Debian, yum với Fedora/Redhat, pacman với ArchLinux, ...)
– purged: đảm bảo package không được cài đặt trên máy.
– latest: đảm bảo package luôn ở phiên bản mới nhất. Khác
với installed, lastest kiểm tra phiên bản của package mỗi
lần chạy, nếu phát hiện có phiên bản mới hơn, state này sẽ
khiến package được update.
service có các trạng thái:
– running: đảm bảo dịch vụ đang chạy, nếu dịch vụ không
chạy thì thực hiện chạy dịch vụ.
– dead: đảm bảo dịch vụ đang không chạy, nếu dịch vụ đang
chạy thì tắt nó đi.
ngoài các thuộc tính bắt buộc trên, mỗi state có thể chứa thêm nhiều
thuộc tính tùy theo mỗi loại state quy định. Ví dụ với service, có thể
khai báo thuộc tính watch và danh sách các file mà dịch vụ này sẽ theo
dõi, nếu nội dung các file đó được thay đổi thông qua Salt, dịch vụ sẽ
được Salt khởi động lại để áp dụng cấu hình mới.
Ví dụ một state:
1
2
/etc/mysql/my.cnf:
file:
3
− managed
4
− source: salt://mariadb/my.cnf.jinja2
39
5
− mode: 644
6
− makedirs: True
Bao gồm:
• ID của state: /etc/mysql/my.cnf
• loại state: file
• trạng thái: managed
• các option của file state: source, mode, makedirs
Khi state này được chạy, máy minion thực hiện tải file my.cnf từ
master và đặt vào thư mục /etc/mysql, đặt mode là 644 và tạo thư
mục /etc/mysql nếu thư mục này không tồn tại. Sau khi thực hiện
xong, minion gửi các thông tin về giá trị thay đổi hoặc lỗi xảy ra về
master.
2.6.5
SLS
SLS (SaLt State file) là file chứa các state sử dụng định dạng
YAML. Định dạng YAML rất đơn giản, có thể mô tả ngắn gọn các
quy tắc biểu diễn YAML như sau:
• dấu hai chấm ":" : biểu diễn kiểu cấu trúc dữ liệu từ điển, bên
trái dấu ":" là key, bên phải là value.
40
• dấu gạch ngang "-" : biểu diễn kiểu cấu trúc dữ liệu danh sách,
theo sau dấu gạch ngang là danh sách các giá trị.
• sau mỗi dấu hai chấm hay gạch ngang cần có một dấu cách nếu
theo ngay sau nó là một giá trị.
• sử dụng hai dấu cách để thụt lề để biểu diễn cấu trúc (không sử
dụng tab).
• dấu thăng "#": dùng để comment. Nếu nội dung có chứa dấu #,
bao quanh nội dung đó bằng dấu ngoặc kép " " để YAML không
xem đó là comment.
Ví dụ SLS cài đặt và chạy dịch vụ keystone (một thành phần của
OpenStack).
1
include:
2
− essex.sqldata
3
− python.mysqldb
4
5
keystone:
6
pkg:
7
− installed
8
− require:
9
10
− pkg: python−mysqldb
service:
11
− running
12
− enable: True
13
− watch:
41
− file: keystone
14
15
− require:
− pkg: keystone
16
17
file:
18
− managed
19
− name: /etc/keystone/keystone.conf
20
− source: salt://essex/keystone.conf.jinja2
21
− template: jinja
22
− mode: 644
23
− user: root
24
− group: root
25
− required_in:
− service: keystone
26
27
cmd:
28
− wait
29
− name: ’keystone−manage db_sync’
30
− watch:
− pkg: keystone
31
32
− require:
33
− mysql_grants: mysql_keystone
34
− service: keystone
35
36
37
/var/lib/keystone/keystone.db:
file:
38
− absent
39
− require:
40
− pkg: keystone
41
42
42
43
/usr/local/src/sample_data.sh:
file:
44
− managed
45
− source: salt://essex/sample_data.sh
46
− template: jinja
47
− mode: 700
48
49
50
./sample_data.sh:
cmd:
51
− wait
52
− cwd: /usr/local/src
53
− watch:
54
55
− cmd: keystone
− require:
56
− file: /usr/local/src/sample_data.sh
57
− mysql_grants: mysql_keystone
Khi SLS được chạy, thứ tự chạy các state luôn thông nhất qua các
lần chạy nhưng không do thứ tự state được viết trong SLS quyết định
mà theo thứ tự từ điển của ID của các state. Thứ tự chạy các state có
thể được chỉ định sử dụng công cụ cung cấp bởi Salt như require hay
order.
Một file SLS có thể nhúng (include) các file SLS khác vào, việc này
giúp các file SLS có thể chia nhỏ, dễ dàng sử dụng lại và mở rộng.
43
2.6.6
Renderers
Do Salt thực hiện thao tác trên các cấu trúc dữ liệu là dict và list,
người dùng có thể sử dụng bất cứ định dạng nào để viết SLS, chỉ cần có
một module thực hiện biến chúng thành các dữ liệu mà Salt sử dụng,
loại module đó gọi là renderer. Các renderer tích hợp sẵn trong Salt
gồm có: jinja, mako, py. Mặc định, Salt sử dụng định dạng YAML để
viết SLS với renderer là jinja.
jinja là tên module Salt dùng để gọi Jinja2. Jinja2 là một templating
engine thực hiện xử lý logic, với khả năng thực hiện các câu lệnh điều
khiển luồng chương trình: if else, for và khả năng sử dụng biến giúp
cho việc cấu hình trở nên linh hoạt.
Py là renderer sử dụng file python để viết SLS.
2.6.7
Pillar
Pillar: dùng để tạo dữ liệu tùy ý cho minion được chỉ định. Các dữ
liệu có thể lưu trữ ở pillar:
• Các dữ liệu nhạy cảm: mật khẩu, khóa bí mật
• Các biến: những giá trị thay đổi. Ví dụ như: ip của 1 máy chủ
• Dữ liệu tùy ý
44
2.6.8
Grains
Grains: grains giúp truy cập thông tin tĩnh của các máy minion.
Các thông tin này được thu thập một lần duy nhất khi minion bắt đầu
chạy và chuyển về cho master. Các thông tin grains của một máy bao
gồm: IP, tên máy, kiến trúc,...
Grains có thể sử dụng trong nhiều mục đích khác nhau:
• điền thông tin của từng máy vào SLS (hostname)
• viết state dùng được cho nhiều nền tảng dựa trên thông tin trong
Grains.
• chọn nhóm máy để áp dụng SLS
Ví dụ:
1
2
3
id:
lappy
ipv4:
4
− 127.0.0.1
5
− 192.168.1.105
6
− 192.168.122.1
7
kernel:
8
Linux
9
kernelrelease:
10
11
12
3.2.0−39−generic
mem_total:
3744
45
13
num_cpus:
4
14
15
16
17
18
os:
Ubuntu
oscodename:
precise
Một số grain trên máy tính có tên lappy chạy Ubuntu 12.04, 4 CPU
2.6.9
Quá trình chạy một SLS
Khi master chỉ định chạy một SLS trên một máy minion nào đó,
renderer bắt đầu thực hiện quá trình xử lý và biến đổi file SLS về dạng
cấu trúc dữ liệu dict và list. Tại đây các biến số, các giá trị grains,
pillar được thay bằng các giá trị thực, các vòng lặp, câu lệnh điều kiện
được thực hiện để tạo ra một SLS chỉ gồm các dữ liệu có thể biến đổi
về cấu trúc dữ liệu dict và list. Sau khi quá trình render SLS thành
công, master chuyển SLS về máy minion cần chạy, minion nhận được
SLS thực hiện chạy các lệnh tương ứng với các state đã khai báo. Sau
khi tất cả các state được thực hiện, minion gửi kết quả về trạng thái
của các state về cho master thông qua kênh truyền zmq.
2.6.10
Returner
Kết quả của một quá trình chạy states không bắt buộc phải trả về
cho master. Khi sử dụng returner, các kết quả này có thể được gửi tới
46
bất cứ hệ thống lưu trữ hoặc quản lý nào. Các returner Salt đang hỗ
trợ có thể kể đến:
• Sentry: Hệ thống lưu trữ log.
• Các database: mysql, mongodb, postgres...
• Cacbon: Hệ thống theo dõi các tiến trình.
• Syslog: Log của hệ thống
47
Chương 3
Cài đặt hệ thống private
cloud OpenStack sử
dụng trình quản lý cấu
hình Salt
3.1
Các công việc cần thực hiện khi cài
đặt OpenStack
• Cài và cấu hình Identity Service (Keystone)
• Cài và cấu hình Image Service (Glance)
48
• Cài Compute (Nova) lên một hoặc nhiều node
• Cấu hình mạng cho hệ thống các máy ảo
• Thêm các file ảnh
• Cài đặt OpenStack Dashboard
49
Hình 3.1: Sơ đồ thứ tự cài đặt các thành phần của OpenStack
Trong sơ đồ trên, các thành phần ngang hàng là các thành phần
có thể cài cùng lúc, thứ tự cài đặt các dịch vụ từ trên xuống dưới, các
dịch vụ phụ thuộc vào dịch vụ mà nó hướng mũi tên tới. Có thể thấy
Nova phụ vào nhiều thành phần khác nên nó được cài sau các dịch vụ
50
nó phụ thuộc. Horizon chỉ cần truy cập được tới keystone để xác thực
quyền truy cập là có thể cho phép người dùng quản lý cả hệ thống
cloud bằng giao diện web.
Dưới đây trình bày việc thực hiện thiết kế state cài đặt openstack
phiên bản Essex trên hệ điều hành Ubuntu 12.04.
3.2
Trên một node
Việc thực hiện cài đặt cloud trên một node giúp mang lại trải
nghiệm về cloud nhanh nhất cho người dùng, tránh khỏi các vấn đề
gặp phải khi chạy nhiều node, mặc dù không mang lại ý nghĩa thực tế
nào trong môi trường sản phẩm.
Hai dịch vụ Database và AMQP cần được cài đặt trước tiên bởi
chúng là kênh lưu trữ và giao tiếp chung cho cả hệ thống cloud. Ở đây
chọn hai chương trình tương ứng là Mariadb và RabbitMQ.
3.2.1
Thiết kế state cho mysql
Mariadb là một phiên bản được tách rời và phát triển từ MySQL từ
sau khi Oracle mua lại Sun. Với khả năng thay thế hoàn toàn MySQl,
Mariadb giữ nguyên toàn bộ tên dịch vụ, các giao diện giao tiếp với các
chương trình, thư viện, và đảm bảo cú pháp tương thích với MySQL.
Các công việc cần thực hiện để cài đặt và cấu hình Mariadb: Thêm địa
chỉ kho phần mềm chứa Mariadb vào danh sách các kho lưu trữ phần
51
mềm của Ubuntu. Thực hiện bởi state sau:
1
2
mariadb_repo:
pkgrepo:
3
− managed
4
− keyid: ’0xcbcb082a1bb943db’
5
− keyserver: keyserver.ubuntu.com
6
− name: deb http://repo.maxindo.net.id/mariadb/repo/5.5/ubuntu precise main
pkgrepo là state thực hiện thêm một kho phần mềm (repository)
vào danh sách các kho phần mềm của ubuntu. Với các tham số là keyid
chứa mã định danh duy nhất của key, keyserver: máy chủ chứa key,
name: tên đầy đủ của kho phần mềm chứa mariadb.
Công việc cài đặt mariadb khi thực hiện bằng Salt có một điểm
cần chú ý: do trình cài đặt mariadb là giao diện tương tác trực tiếp
với người dùng nên trong quá trình chạy tự động Salt sẽ tìm cách để
trả lời các câu hỏi tương tác ấy. Có hai cách để thực hiện việc này:
• Viết trước câu trả lời và đưa vào debconf, thư viện debconf là
nơi mà trình cài đặt sẽ tìm câu trả lời trước khi đưa ra câu hỏi
với người dùng
• Do đặc thù của mysql, trình cài đặt sẽ không hỏi các thông tin
về mật khẩu của root nữa nếu như file debian.cnf đã tồn tại và
chứa mật khẩu ấy. Ở đây sẽ dùng cách này.
State thực hiện cài đặt mariadb và chạy dịch vụ mysql như sau:
52
1
2
mariadb_repo:
pkgrepo:
3
− managed
4
− keyid: ’0xcbcb082a1bb943db’
5
− keyserver: keyserver.ubuntu.com
6
− name: deb http://repo.maxindo.net.id/mariadb/repo/5.5/ubuntu precise main
7
8
9
/etc/mysql/debian.cnf:
file:
10
− managed
11
− source: salt://mariadb/debian.cnf
12
− mode: 600
13
− makedirs: True
14
15
16
/etc/mysql/my.cnf:
file:
17
− managed
18
− source: salt://mariadb/my.cnf.jinja2
19
− mode: 644
20
− makedirs: True
21
22
23
mariadb−server:
pkg:
24
− installed
25
− require:
26
− pkgrepo: mariadb_repo
27
− file: /etc/mysql/debian.cnf
53
28
29
− file: /etc/mysql/my.cnf
service:
30
− name: mysql
31
− running
32
− watch:
33
− file: /etc/mysql/my.cnf
34
− file: /etc/mysql/debian.cnf
35
36
− require:
− pkg: mariadb−server
State /etc/mysql/debian.cnf đảm bảo sự tồn tại của file /etc/
mysql/debian.cnf với mode là 600 đảm bảo chỉ user root mới có thể
xem nội dung của file này. Nội dung file này được viết sẵn trong đường
dẫn salt://mariadb/debian.cnf. Đây là đường dẫn tương đối với
thư mục chứa file top.sls của Salt. Nói cách khác thư mục mariadb
nằm cùng thư mục với file top.sls, còn debian.cnf nằm trong thư mục
mariadb. Thuộc tính makedirs: True đảm bảo thư mục /etc/mysql sẽ
được tạo nếu nó không tồn tại.
Tương tự đối với state /etc/mysql/my.cnf đảm bảo file cấu hình
my.cnf sẽ nằm tại đường dẫn định trước này với mode là 644 - cho
phép tất cả các user trên hệ thống có thể đọc được nhưng chỉ user root
có quyền thay đổi nội dung.
ID mariadb-server chứa hai state con. State pkg thực hiện cài gói
mariadb-server với thuộc tính require yêu cầu state mariadb_repo phải
chạy trước nó đồng thời hai file cấu hình phải tồn tại trước khi gói này
54
được cài (để tránh quá trình tương tác đã nói ở trên). State service
thực hiện chạy dịch vụ có tên là mysql sau khi việc chạy state pkg thực
hiện xong, thuộc tính watch chỉ ra rằng dịch vụ này sẽ khởi động lại
mỗi khi nội dung của một trong hai file cấu hình bị thay đổi bởi Salt.
3.2.2
Thiết kế state cho rabbitmq
Dịch vụ rabbitmq được cài đặt bằng state sau:
1
2
3
4
rabbitmq−server:
pkg:
− installed
service:
5
− running
6
− enable: True
Sau khi gói rabbitmq-server được cài đặt, dịch vụ tương ứng được
Salt khởi động. Không có yêu cầu đặc biệt nào về cấu hình cần được
quản lý với dịch vụ này, nên ta có thể sử dụng file cấu hình đi kèm với
gói đã cài đặt.
3.2.3
Thiết kế state cho keystone
Bước tiếp theo thực hiện cài đặt dịch vụ keystone, keystone cần
được cài đặt trước hết bởi tất cả các dịch vụ đều sẽ sử dụng keystone
để thực hiện xác thực trước khi thực hiện bất cứ hành động nào.
1
include:
55
2
− essex.sqldata
3
− python.mysqldb
4
5
keystone:
6
pkg:
7
− installed
8
− require:
− pkg: python−mysqldb
9
10
service:
11
− running
12
− enable: True
13
− watch:
− file: keystone
14
15
− require:
− pkg: keystone
16
17
file:
18
− managed
19
− name: /etc/keystone/keystone.conf
20
− source: salt://essex/keystone.conf.jinja2
21
− template: jinja
22
− mode: 644
23
− user: root
24
− group: root
25
− required_in:
26
27
− service: keystone
cmd:
28
− wait
29
− name: ’keystone−manage db_sync’
56
30
− watch:
− pkg: keystone
31
32
− require:
33
− mysql_grants: mysql_keystone
34
− service: keystone
35
36
37
/var/lib/keystone/keystone.db:
file:
38
− absent
39
− require:
− pkg: keystone
40
41
42
43
/usr/local/src/sample_data.sh:
file:
44
− managed
45
− source: salt://essex/sample_data.sh
46
− template: jinja
47
− mode: 700
48
49
50
./sample_data.sh:
cmd:
51
− wait
52
− cwd: /usr/local/src
53
− watch:
54
55
− cmd: keystone
− require:
56
− file: /usr/local/src/sample_data.sh
57
− mysql_grants: mysql_keystone
57
Ở đầu SLS, câu lệnh include thực hiện nhúng nội dung hai SLS
essex.sqldata và python.mysqldb vào SLS hiện tại, bởi các state trong
keystone.sls phụ thuộc vào các state trong hai SLS này. Các state pkg,
service và file để cài đặt keystone không có gì đặc biệt so với các state
cùng loại của mariadb. Sau khi dịch vụ keystone đã chạy, cần thực
hiện chạy hai câu lệnh để keystone có thể hoạt động đúng chức năng
của nó. Trước hết, cần chạy câu lệnh "keystone-manage db_sync" để
thực hiện đồng bộ dữ liệu (tạo các bảng cần thiết trong database) và
sau đó chạy script sample_data.sh để nhập vào các dữ liệu về user,
service và role.
3.2.4
Thiết kế state cho glance
Sau khi keystone đã chạy, dịch vụ Image Service cần được cài đặt
để thực hiện cung cấp file ảnh hệ điều hành cho các máy ảo sử dụng.
Việc cài đặt và cấu hình dịch vụ glance thực hiện bởi state sau:
1
include:
2
− essex.sqldata
3
− essex.keystone
4
5
6
7
glance:
pkg:
− installed
8
9
glance−services:
58
10
service:
11
− running
12
− names:
13
− glance−registry
14
− glance−api
15
− watch:
16
− file: /etc/glance/glance−registry.conf
17
− file: /etc/glance/glance−registry−paste.ini
18
− file: /etc/glance/glance−api.conf
19
− file: /etc/glance/glance−api−paste.ini
20
− require:
− pkg: glance
21
22
23
{% for i in (’api.conf’,’api−paste.ini’,’registry.conf’,’registry−paste.ini’)%}
24
/etc/glance/glance−{{ i }}:
25
file:
26
− managed
27
− source: salt://essex/glance−{{ i }}
28
− require:
29
30
31
32
− pkg: glance
− required_in:
− service: glance−services
{% endfor %}
33
34
35
glance_db_sync:
cmd:
36
− wait
37
− name: ’glance−manage version_control 0 && glance−manage db_sync
59
&& service glance−api restart && service glance−registry restart’
38
39
− require:
40
− mysql_grants: mysql_glance
41
− service: glance−services
42
− cmd: ./sample_data.sh
43
44
− watch:
− pkg: glance
Glance bao gồm hai dịch vụ: glance-api và glance-registry. Đi kèm
với mỗi dịch vụ này là hai file cấu hình. SLS trên sử dụng một vòng lặp
for với danh sách các file cấu hình để tránh viết lặp lại các phần giống
nhau của các state. Hai dịch vụ này sẽ theo dõi bốn file cấu hình và sẽ
restart nếu như cấu hình thay đổi. Sau khi các dịch vụ đã chạy, state
glance_db_sync được thực hiện để đồng bộ cơ sở dữ liệu nhằm tạo
các bảng cần thiết. Với thuộc tính wait, câu lệnh này chỉ chạy một lần
duy nhất sau khi pkg: glance được cài đặt và các dịch vụ đã ứng dụng
cấu hình mới. Trong thuộc tính require của state này, mysql_grants là
state thực hiện tạo database, user và gán quyền cho user đã tạo. Nội
dung các state này có trong file essex.sqldata.
Để tự động quá trình tạo file ảnh, SLS images thực hiện tải file ảnh
của một hệ điều hành thu nhỏ với tên cirros và đưa vào hệ thống file
ảnh của glance:
1
2
include:
− essex.glance
3
60
4
5
cirros_image:
file:
6
− managed
7
− name: /usr/local/src/cirros−0.3.0−x86_64−disk.img
8
− source: https://launchpad.net/cirros/trunk/0.3.0/+download/
cirros−0.3.0−x86_64−disk.img
9
10
− source_hash: md5=50bdc35edb03a38d91b1b071afb20a3c
11
12
13
glance_add_cirros:
cmd:
14
− run
15
− name: OS_USERNAME={{ pillar[’openstack’][’OS_USERNAME’] }}
16
OS_PASSWORD={{ pillar[’openstack’][’OS_PASSWORD’] }}
17
SERVICE_TOKEN={{ pillar[’openstack’][’SERVICE_TOKEN’] }}
18
OS_TENANT_NAME={{ pillar[’openstack’][’OS_TENANT_NAME’] }}
19
OS_AUTH_URL={{ pillar[’openstack’][’OS_AUTH_URL’] }}
20
SERVICE_ENDPOINT={{ pillar[’openstack’][’SERVICE_ENDPOINT’] }}
21
OS_REGION_NAME={{ pillar[’openstack’][’OS_REGION_NAME’] }}
22
glance index | grep −o cirros ||
23
OS_USERNAME={{ pillar[’openstack’][’OS_USERNAME’] }}
24
OS_PASSWORD={{ pillar[’openstack’][’OS_PASSWORD’] }}
25
SERVICE_TOKEN={{ pillar[’openstack’][’SERVICE_TOKEN’] }}
26
OS_TENANT_NAME={{ pillar[’openstack’][’OS_TENANT_NAME’] }}
27
OS_AUTH_URL={{ pillar[’openstack’][’OS_AUTH_URL’] }}
28
SERVICE_ENDPOINT={{ pillar[’openstack’][’SERVICE_ENDPOINT’] }}
29
OS_REGION_NAME={{ pillar[’openstack’][’OS_REGION_NAME’] }}
30
glance add name=cirros disk_format=raw container_format=bare < /usr/local
31
/src/cirros−0.3.0−x86_64−disk.img
61
32
− require:
33
− file: cirros_image
34
− cmd: glance_db_sync
State cirros_image thực hiện đảm bảo sự tồn tại của file tại đường
dẫn /usr/local/src/cirros-0.3.0-x86_64-disk.img, với nội dung file này
lấy từ URL https://launchpad.net/cirros/trunk/0.3.0/+download/
cirros-0.3.0-x86\_64-disk.img, giá trị source_hash giúp đảm bảo
file ảnh lấy về được nguyên vẹn, không bị thay đổi hay lỗi trong quá
trình tải. State glance_add_cirros thực hiện câu lệnh "glance add"
để thêm file ảnh cirros vào hệ thống file ảnh của glance, câu lệnh đòi
hỏi sự có mặt của file ảnh cirros và state glance_db_sync đã chạy
trước nó. Do đặc thù của câu lệnh glance đòi hỏi phải xác thực quyền
trước khi thi hành, đoạn lệnh trước glance add thực hiện gán biến môi
trường cần thiết lấy từ pillar rồi dùng biến đó với câu lệnh glance add.
3.2.5
Thiết kế state cho nova
Các dịch vụ compute được cài đặt trong state nova.sls. Quá trình
thực hiện cài đặt không có gì đặc biệt so với dịch vụ glance, ngoài việc
thực hiện một script sau khi dịch vụ đã chạy để tạo network và thêm
các luật bảo mật cho phép truy cập đến máy ảo qua cổng 22 và ping
đến máy đó.
1
2
nova_network_and_inject_key:
cmd:
62
3
− script
4
− source: salt://essex/nova_sec.sh
5
− template: jinja
6
− require:
7
− file: /tmp/id_rsa.pub
8
− pkg: nova
9
− cmd: run_sync_nova
10
− service: nova−services
3.2.6
Thiết kế state cho horizon
Thành phần cuối cùng để chạy một cloud OpenStack là dashboard
với tên horizon, việc cài đặt dashboard thực hiện đơn giản theo SLS
sau:
1
2
3
4
5
memcached:
pkg:
− installed
service:
− running
6
7
8
openstack−dashboard:
pkg:
9
− installed
10
− require:
11
− pkg: memcached
Nội dung file top.sls:
63
1
base:
2
’∗’:
3
− essex.nova
4
− essex.images
5
− essex.keystone
6
− essex.glance
7
− essex.horizon
3.3
Trên nhiều node
Việc cài đặt trên nhiều node đòi hỏi người cài đặt phải thiết kế
trước mô hình, kiến trúc của hệ thống mà họ sẽ cài. Tùy theo nhu cầu
và điều kiện cụ thể của doanh nghiệp mà kiến trúc cloud có thể trở
nên rất khác biệt. Ví dụ với một doanh nghiệp cần lưu trữ nhiều, hệ
thống các node để lưu trữ sẽ tăng lên, các đường mạng cẩn đảm bảo
khả năng truyền dẫn để không gây ra hiện tượng nghẽn cổ chai do lưu
lượng truyển tải cao. Với các doanh nghiệp cần sử dụng nhiều máy ảo
và cần lượng tài nguyên CPU, RAM nhiều, việc cài đặt các compute
node là cần thiết.
Với compute node, chỉ cần cài một dịch vụ duy nhất là ‘novacompute‘, cấu hình các thông số phù hợp là đã có thể sử dụng được.
Các thông số cần thay đổi ở đây là địa chỉ IP của máy host, địa chỉ
này có thể tự động lấy thông qua grains, ngoài ra cần điền thông số
64
về địa chỉ của mysql server, rabbitmq server được cung cấp qua pillar
để dễ dàng thay đổi khi cần thiết.
SLS cài compute node:
1
2
3
4
nova−compute:
pkg:
− installed
service:
5
− running
6
− watch:
7
− file: /etc/nova/nova.conf
8
− file: /etc/nova/api−paste.ini
9
− require:
− pkg: nova−compute
10
11
12
13
/etc/nova/api−paste.ini:
file:
14
− managed
15
− source: salt://essex/api−paste.ini
16
− template: jinja
17
18
19
/etc/nova/nova.conf:
file:
20
− managed
21
− source: salt://essex/nova.conf
22
− template: jinja
65
Chương 4
Kết quả và đánh giá
4.1
4.1.1
Kết quả
Cloud OpenStack
Sau khi chạy xong state để triển khai trên một máy, thu được một
cloud OpenStack với đầy đủ các thành phần thiết yếu, các dịch vụ
chạy ổn định, có thể đăng nhập vào dashboard với tài khoản và mật
khẩu định trước ở pillar và tạo các máy ảo từ file ảnh cirros đã đưa
vào.
• Số máy vật lý: 2
• Hệ điều hành máy vật lý: Ubuntu 12.04 LTS
• Tổng dung lượng RAM có: 4 GB
66
• Số máy ảo cirros dựng lên từ dashboard: 9
• Tất cả các dịch vụ đã được cài đặt hoạt động tốt: mysql, rabbitmq, nova, keystone, glance, horizon
• Có thể quản lý máy ảo (tạo mới, tắt, xóa) bằng dashboard horizon
• Các máy ảo dựng lên hoạt động ổn định, đầy đủ chức năng mà
cirros cung cấp như ping đến đến máy thật và các địa chỉ mạng
internet, dịch vụ ssh trên cirros chạy ổn định, cho phép người
dùng ssh từ ngoài vào
67
Hình 4.1: Giao diện horizon sau khi cài đặt
Hình chụp giao diện của dashboard horizon, với project được chọn là
admin, sau khi cài xong, chưa có máy ảo nào chạy nên thông số phần
overview còn trống.
68
Hình 4.2: Giao diện horizon khi tạo một máy ảo
Hình trên chụp bảng điền thông tin khi tạo một máy ảo với tên cirros2,
sử dụng khuôn mẫu m1.tiny với 1VCPU, 512MB RAM, và không sử
dụng thêm ổ cứng ngoài phần mà cirros yêu cầu. Keypair là ssh key sử
dụng để cloud đưa vào máy ảo khi nó được tạo, giúp cho người dùng
có thể SSH vào sau khi máy ảo đã chạy. Security Groups cho phép lựa
chọn nhóm các quy định bảo mật định trước, ở đây sử dụng nhóm có
tên default.
69
Hình 4.3: Giao diện horizon sau khi tạo một máy ảo
Hình chụp horizon sau khi tạo thành công máy ảo cirros với tên máy
là hvn01.
70
Hình 4.4: Giao diện horizon sau khi tạo hai máy ảo
Hình chụp horizon sau khi tạo 2 máy ảo cirros, phần Overview đã có
các thông số tổng quan về 2 máy này bao gồm tên máy, số VCPU,
lượng ổ cứng được cấp, lượng RAM được cấp, và thời gian mà máy ảo
đã chạy.
71
Hình 4.5: Giao diện horizon khi 10 máy ảo cirros được tạo
Hình trên chụp màn hình phần giao diện của dashboard horizon sau
khi dựng lên 10 máy ảo cirros. Cột Instance name là tên của máy ảo,
cột IP Address hiển thị địa chỉ ip LAN của các máy ảo. Cột Size ghi
thông tin về VCPU, RAM và ổ cứng mà máy ảo được cấp, tất cả 10
máy này đều dùng 1 VCPU, 512 MB RAM, kích thước ổ cứng mặc
định theo đĩa cirros quy định. Cột Status ghi trạng thái của máy ảo,
máy cirros11 có status là error bởi cloud không đủ RAM để cung cấp
cho máy này, vậy nên nó không được tạo và không có địa chỉ IP. Cột
Task ghi lại nhiệm vụ mà cloud đang thực hiện trong quá trình tạo,
xóa, bật, tắt máy ảo. Cột PowerState ghi thông số về tình trạng máy
ảo đang bật, tắt hay lỗi. Cột Actions cho phép người dùng thay đổi
trạng thái máy ảo như bật, tắt, xóa hoặc xem log, kết nối VNC.
72
Hình 4.6: SSH vào máy ảo
Ảnh chụp GNOME terminal khi ssh vào một máy ảo có IP LAN được
cấp là 192.168.122.3, đăng nhập bằng username cirros, sau khi đã truy
cập được vào máy ảo cirros, thực hiện chạy lệnh ip addr để hiển thị
các thông tin về các giao diện mạng của máy ảo này.
Thử nghiệm cài đặt thêm 1 node với vai trò nova-compute, từ node
đầu tiên có thể liệt kê các máy host bằng dòng lệnh và thu được kết
quả như sau khi cài trên 2 node:
Hình 4.7: Liệt kê danh sách máy host (compute-node)
73
4.1.2
Salt
Sau quá trình viết state, thu được 9 file SLS thực hiện cài toàn bộ
các dịch vụ thiết yếu của OpenStack. Các state này có thể được chạy
trên các máy sử dụng hệ điều hành Ubuntu 12.04 để cài đặt một hệ
thống cloud hoàn chỉnh với số compute node tùy ý. Việc sử dụng Salt
giúp việc cài đặt cloud các lần sau trở nên vô cùng đơn giản với công
việc chính là điền các thông số cần thiết (IP máy cài mysql, IP máy
cài rabbitmq, subnet mạng sử dụng, ...) rồi chạy state. Đặc biệt khi
cần thay đổi cấu hình, cụ thể như cần thay đổi địa chỉ của máy chạy
dịnh vụ mysql, chỉ cần thay đổi 1 lần duy nhất ở 1 file duy nhất, Salt
giúp phân tán file này đến tất cả các máy compute node và restart lại
dịch vụ nova-compute để áp dùng cấu hình mới này.
Triển khai trên một node, tổng thời gian cả quá trình cài đặt bằng
tổng thời gian tải và cài đặt các gói cộng với thời gian tải file ảnh cirros,
các phần công việc còn lại chiếm thời gian không đáng kể. Tốc độ của
quá trình chủ yếu phụ thuộc vào tốc độ đường truyền internet. Nếu
thực hiện cache trước các file ảnh và các gói cần cài, quá trình chạy
state sẽ chỉ gồm thời gian cài đặt các gói, trên mô hình thử nghiệm,
khoảng thời gian này dao động từ 7-10 phút, thời gian thực hiện có
thể rất khác tùy theo tốc độ CPU, RAM và đĩa cứng của máy host.
Salt với ngôn ngữ cấu hình đơn giản giúp việc viết state không có
gì khó khăn, với khả năng chỉ định thứ tự chạy các state giúp việc
cài đặt theo thứ tự nhất định được đảm bảo. Các dịch vụ của salt
74
(salt-master, salt-minion) chạy ổn định, sử dụng ít CPU và RAM.
4.2
Đánh giá hiệu quả
• Cần cài đặt thành công một lần trước khi viết các state để có
được các file cấu hình chuẩn
• Trên một node, việc cài đặt nhanh hơn đáng kể so với cài đặt
bằng tay.
• Thời gian viết state phụ thuộc chủ yếu vào sự thành thạo Salt và
hiểu biết về dịch vụ cần cài của người viết. Tổng số dòng của tất
cả các file SLS thực hiện cài đặt: khoảng 265 dòng, với khoảng
6800 ký tự.
• Thời gian cài trên hai node ít hơn thời gian cài đặt trên một
node. Điều này có thể lý giải do Salt thực hiện hai quá trình cài
đặt này cùng lúc trên hai máy khác nhau, nên thời gian cài đặt
của máy nào lâu nhất thì đó cũng là thời gian của cả quá trình
cài đặt. Do quá trình cài đặt có sử dụng cache các gói phần mềm
nên trong khi node 1 đang tải và cài các gói mysql, rabbitmq,
keystone, glance thì node 2 thực hiện tải gói nova-compute. Khi
node 1 cần cài nova-compute nó sẽ không tốn thời gian để tải
gói này nữa (do vừa được cache lại) dẫn đến kết quả như đã thu
được.
75
Kết luận
Đồ án đã thực hiện tìm hiểu và cài đặt OpenStack - một hệ thống
giúp triển khai mô hình IaaS cloud, một giải pháp hiện đại và hiệu quả
cho các doanh nghiệp có nhu cầu sử dụng nhiều máy chủ. Mô hình thử
nghiệm đã dựng lên một hệ thống IaaS cloud chạy trên 2 máy tính,
có khả năng cung cấp các máy ảo một cách nhanh chóng. Các dịch vụ
thành phần của cloud đều chạy ổn định và thực hiện đúng các chức
năng như mong đợi.
Kết hợp với tìm hiểu và ứng dụng công cụ quản lý cấu hình SaltStack, việc cài đặt và quản lý hệ thống cloud trở nên nhanh chóng,
hiệu quả hơn nhiều lần. Kết quả thu được là một tập hợp các file SLS
cho phép cài đặt và quản trị một hệ thống OpenStack cloud nhanh
chóng trên một hoặc nhiều máy tính chạy hệ điều hành Ubuntu 12.04,
chứng minh cho tính khả thi của giải pháp sử dụng OpenStack và Salt
để thực hiện cung cấp và quản lý một lượng lớn máy chủ cho doanh
nghiệp.
Sử dụng hai công nghệ mã nguồn mở chạy trên nền tảng hệ điều
76
hành nhân Linux, đồ án góp phần mang lại những suy nghĩ tích cực về
phần mềm mã nguồn mở, đưa ra giải pháp giúp các doanh nghiệp có
thể tự làm chủ các công nghệ hiện đại hiệu quả mà không tốn nhiều
tiền của. Trong hoàn cảnh các doanh nghiệp công nghệ thông tin trong
nước đang đầu tư với số vốn rất lớn để tìm hiểu và làm chủ công nghệ
điện toán đám may, đồ án giúp mang lại trải nghiệm nhanh chóng cho
người dùng chỉ với lượng công sức và chi phí bỏ ra thấp nhất. Hai công
nghệ được giới thiệu trong đồ án này sẽ rất hữu ích khi môi trường
doanh nghiệp đủ lớn, giúp tiết kiệm nhiều tiền của, công sức, nhưng
với những doanh nghiệp nhỏ, khi lượng máy cần quản lý không nhiều
thì việc sử dụng hai công nghệ này có thể mang lại lợi ích không tương
xứng với công sức bỏ ra.
Do điều kiện về cơ sở vật chất không cho phép nên đồ án mới chỉ
dừng lại ở việc dựng một mô hình cloud trên 2 máy vật lý, chưa thể
giải quyết bài toán thực tế cung cấp lượng lớn server mà mới chỉ có
thể cung cấp được khoảng 10 server nhỏ, chạy ít dịch vụ và các dịch
vụ luôn ở trạng thái rảnh. Đồ án có thể được tiếp tục phát triển theo
hướng giải quyết các bài toán cụ thể, thực hiện cung cấp các server
cho các dự án thật kết hợp với viết các state để tự động quá trình cài
đặt và quản lý cấu hình, đồng thời có thể cài đặt thêm các thành phần
tùy chọn như OpenStack Storage để thực hiện lưu trữ phân tán.
Đồ án thực hiện tìm hiểu hai công nghệ lớn với hai sản phẩm còn
khá mới mẻ nên việc thiếu xót là không thể tránh khỏi, em rất mong
77
nhận được những phản hồi và đóng góp của các thầy cô để có được
một tài liệu tốt hơn cho bản thân em nói riêng và cho ngành công nghệ
thông tin nước nhà nói chung.
78
Tài liệu tham khảo
• http://aws.amazon.com/
• http://blogs.technet.com
• http://docs.openstack.org
• http://en.wikipedia.org/wiki/
• http://www.heroku.com/
• http://www.windowsazure.com/en-us/
• https://drive.google.com/
• http://saltstack.com/
• http://cfengine.com/
• http://www.opscode.com/chef/
• https://puppetlabs.com/
79
Danh sách hình vẽ
1.1
Dashboard của Windows Azure . . . . . . . . . . . . .
10
1.2
Giao diện dashboard của Heroku . . . . . . . . . . . .
11
1.3
Giao diện soạn thảo Spreadsheet của Google Drive . .
13
1.4
Phân tầng chức năng của từng mô hình dịch vụ . . . .
14
1.5
Sơ đồ tương tác của các dịch vụ trong OpenStack . . .
18
2.1
Mô hình Master - Minion của Salt . . . . . . . . . . . .
37
3.1
Sơ đồ thứ tự cài đặt các thành phần của OpenStack . .
50
4.1
Giao diện horizon sau khi cài đặt . . . . . . . . . . . .
68
4.2
Giao diện horizon khi tạo một máy ảo . . . . . . . . .
69
4.3
Giao diện horizon sau khi tạo một máy ảo . . . . . . .
70
4.4
Giao diện horizon sau khi tạo hai máy ảo . . . . . . . .
71
4.5
Giao diện horizon khi 10 máy ảo cirros được tạo . . . .
72
4.6
SSH vào máy ảo . . . . . . . . . . . . . . . . . . . . . .
73
4.7
Liệt kê danh sách máy host (compute-node) . . . . . .
73
80
Phụ lục
Thiết kế state cho DNSimple
DNSimple là một dịch vụ online cho phép quản lý tên miền và các
bản ghi một cách đơn giản và hiệu quả. Dựa trên API của DNSipmle
cung cấp, module dưới đây sẽ thực hiện thiết kế state cho DNSimple
phục vụ công việc sử dụng Salt quản lý tên miền. Module được viết
bằng ngôn ngữ Python 2.7
Một state module cần thực hiện những công việc sau:
• Đọc vào file SLS của người dùng
• Lưu giữ trạng thái trước khi chạy state
• Thực hiện các thay đổi như nội dung SLS yêu cầu
• Trả về những thay đổi và kết quả của quá trình chạy state
dnsimple module thực hiện:
• đọc vào các tên miền cùng trạng thái yêu cầu
81
• đọc vào các record cùng trạng thái yêu cầu
• lấy toàn bộ thông tin hiện tại về tên miền và records
• thực hiện các thay đổi như tạo tên miền, tạo record, thay đổi nội
dung record
• lấy kết quả sau khi thay đổi so sánh với dữ liệu ban đầu
• trả về kết quả của quá trình chạy state
Cài đặt và sử dụng DNSimple
Module viết bằng python :
1
#−∗− encoding: utf−8 −∗−
2
3
’’’
4
DNSimple state
5
requires: requests==1.2.0
6
’’’
7
8
import json
9
import logging
10
try:
11
import requests
12
except ImportError:
13
requests = None
14
82
15
16
log = logging.getLogger(__name__)
17
18
COMMON_HEADER = {’Accept’: ’application/json’,
19
’Content−Type’: ’application/json’,
20
}
21
BASE_URL = ’https://dnsimple.com’
22
23
24
def __virtual__():
25
’’’Verify requests is installed.’’’
26
if requests is None:
27
28
return False
return ’dnsimple’
29
30
31
def auth_session(email, token):
32
ses = requests.Session()
33
ses.auth = (email, token)
34
ses.headers.update(COMMON_HEADER)
35
ses.headers.update({’X−DNSimple−Token’: email + ":" + token})
36
return ses
37
38
39
def created(name, email, token):
40
domain = name
41
ret = {’name’: domain,
42
’changes’: {},
83
43
’result’: False,
44
’comment’: ’’}
45
46
47
if __opts__[’test’]:
return {’name’: name,
48
’changes’: {},
49
’result’: None,
50
’comment’: ’Domain {0} is set to be created’.format(
name)}
51
52
53
path = "/domains"
54
ses = auth_session(email, token)
55
data = {"domain": {"name": domain}}
56
resp = ses.post(BASE_URL + path, json.dumps(data))
57
log.info("{0} {1}".format(resp.status_code, resp.content))
58
if resp.status_code == 201:
59
ret[’result’] = True
60
ret[’changes’][domain] = "Created in your account"
61
elif resp.status_code == 400:
62
comment = "already in your account."
63
if comment in resp.content:
64
ret[’result’] = True
65
ret[’comment’] = comment
66
67
68
69
70
elif resp.status_code == 401:
ret[’result’] = False
else:
raise Exception("{0} {1}".format(resp.status_code, resp.content))
return ret
84
71
72
73
def normalise(records):
74
’’’Return a data with structure same as which returned from API’’’
75
ret = {}
76
for domain in records:
77
li = []
78
for rectype in records[domain]:
79
data = {}
80
data[’record_type’] = rectype
81
recs = records[domain][rectype]
82
for recname in recs:
83
data[’name’] = recname
84
data.update(recs[recname])
li.append(data)
85
ret[domain] = li
86
87
return ret
88
89
90
def records_existed(name, email, token, records):
91
’’’
92
Use returning ASAP when have any error happen. So if nothing change,
93
result is true
94
95
sls example
96
97
98
records_exists:
email:
85
token:
99
records:
100
blahblah.com:
101
A:
102
www:
103
104
content: 123.11.1.11
105
ttl: 123
106
prio: 2
blog:
107
content: 122.2.2.2
108
adomain.org:
109
A:
110
www:
111
112
content: 12.1.1.2
113
...
114
’’’
115
116
ret = {’name’: ’existed’,
117
’changes’: {},
118
’result’: True,
119
’comment’: ’’}
120
121
ses = auth_session(email, token)
122
existing_records = {}
123
for domain in records:
124
path = "/domains/{0}/records".format(domain)
125
data = json.loads(ses.get(BASE_URL + path).content)
126
data = [i[’record’] for i in data]
86
127
existing_records[domain] = data
128
129
to_update = {}
130
to_create = {}
131
new_records = normalise(records)
132
id2erc = {}
133
for domain in records:
134
ex_records = existing_records[domain]
135
new_domain_records = new_records[domain]
136
to_update[domain] = {}
137
for nrc in new_domain_records:
138
need_create = True
139
for erc in ex_records:
140
if nrc[’name’] == erc[’name’]:
141
# some records have same name, check their type for makeing
142
# sure correct update/create
143
# (DNSimple default have 4 NS record with name ’’)
144
if erc[’name’] == ’’:
145
146
if erc[’record_type’] != nrc[’record_type’]:
continue
147
148
id2erc[erc[’id’]] = erc
149
diff = {}
150
for k, v in nrc.items():
151
if erc[k] != v:
152
diff[k] = v
153
154
if diff != {}:
87
to_update[domain][erc[’id’]] = diff
155
156
need_create = False
157
break
158
159
if need_create:
if to_create == {}:
160
to_create[domain] = []
161
to_create[domain].append(nrc)
162
log.info("To create: {0}".format(to_create))
163
log.info("To update: {0}".format(to_update))
164
165
166
if __opts__[’test’]:
return {’name’: name,
167
’changes’: {},
168
’result’: None,
169
’comment’: ’Records {0} is set to be created\nRecords {1} is \
170
set to be updated’.format(to_create, to_update)}
171
172
173
for domain in to_create:
for r in to_create[domain]:
174
path = "/domains/{0}/records".format(domain)
175
data = {"record": r}
176
resp = ses.post(BASE_URL + path, json.dumps(data))
177
log.info("{0} {1}".format(resp.status_code, resp.content))
178
if resp.status_code == 201:
179
180
ret[’changes’]["{0}:{1}".format(domain, r[’name’])] = "created"
elif resp.status_code == 400:
181
ret[’result’] = False
182
ret[’comment’] = resp.content
88
183
184
185
return ret
elif resp.status_code == 404:
if "Couldn\’t find Domain with name" in resp.content:
186
ret[’result’] = False
187
ret[’comment’] = "Couldn’t find domain {0}".format(domain)
188
return ret
189
else:
190
assert resp.status_code != 422
191
ret[’comment’] = "{0} {1} {2}".format(domain, r,
resp.status_code)
192
193
return ret
194
195
196
for dom in to_update:
for rid in to_update[dom]:
197
path = "/domains/{0}/records/{1}".format(dom, rid)
198
record_changes = to_update[dom][rid]
199
resp = ses.put(BASE_URL + path,
200
json.dumps({"record": record_changes}))
201
log.info("{0} {1}".format(resp.status_code, resp.content))
202
if resp.status_code == 200:
203
changes = []
204
for k, v in record_changes.items():
205
changes.append("{0}: {1} => {2}".format(
206
k,
207
id2erc[rid][k],
208
json.loads(resp.content)[’record’][k]))
209
ret[’changes’]["{0} {1}".format(dom,
id2erc[rid][’name’])] = changes
210
89
211
else:
212
ret[’result’] = False
213
ret[’comment’] = "{0} {1}".format(resp.status_code,
resp.content)
214
215
return ret
90
- Xem thêm -