Tài liệu Đồ án sử dụng saltstack triển khai hệ thống private cloud openstack

  • Số trang: 95 |
  • Loại file: PDF |
  • Lượt xem: 4776 |
  • Lượt tải: 84
hoangdieu

Tham gia: 22/06/2014

Mô tả:

Đồ á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 -