Công cụ triển khai nhanh

CHƢƠNG 3 PHƢƠNG PHÁP TIẾP CẬN VÀ TRIỂN KHAI OPENSTACK

3.1 Công cụ triển khai nhanh

Để triển khai đám mây OpenStack, rất nhiều công cụ đã đƣợc phát triển. Mục tiêu của các công cụ này là tự động hóa việc triển khai OpenStack trong khi giảm bớt một số sự phức tạp cho ngƣời dùng.

Các công cụ hay dùng gồm:

 Devstack: Một mã nguồn mở hƣớng cộng đồng, đƣợc sử dụng trong luận văn này.

 RDO: Phát triển bởi Red Hat.

 PackStack: Một tiện ích sử dụng Puppet để triển khai tự động các phần khác nhau của OpenStack trên nhiều máy chủ đƣợc cài đặt sẵn qua SSH.

 Fule: Một công cụ triển khai nhanh đƣợc phát triển bởi Mirantis. 3.2 Các mô hình triển khai OpenStack

Phần này trình bày cách xây dựng đám mây OpenStack và cách xác nhận tính năng OpenStack bằng cách khởi chạy một instance. Nói chung, việc triển khai OpenStack có thể có 2 loại: môi trường sản xuất hoặc môi trường phát triển.

Môi trường phát triển cực kỳ đơn giản để thiết lập, phù hợp với nhu cầu của ngƣời dùng và nó đƣợc cho là để phân tích nền tảng hoặc để kiểm tra các chức năng. Một số giải pháp đƣợc sử dụng là DevStack và PackStack. Tuy nhiên, việc triển khai

này cực kỳ không ổn định và nó không phù hợp cho việc chạy các kịch bản phức tạp hoặc sử dụng cho khách hàng.

Thay vào đó, môi trường sản xuất rất phức tạp để thiết lập. Quá trình cài đặt nó cần một giai đoạn lập kế hoạch, thƣờng kéo dài ngay cả khi lựa chọn các node mà các thành phần đƣợc triển khai với độ chính xác.

Sau đó, việc triển khai cụ thể có thể xảy ra bằng cách viết tay các cấu hình khi cài đặt các thành phần, nhƣ hƣớng dẫn OpenStack khuyến nghị cho các môi trƣờng tƣơng đối nhỏ hoặc bằng cách sử dụng các công cụ tự động hóa nhƣ Red Hat TripleO, Ansible, Chef, Puppet, Fuel, Autopilot, v.v. Đối với luận văn này, tôi đang sử dụng triển khai bằng DevStack.

3.2.1 Cấu hình cơ sở hạ tầng cài đặt

Cấu hình cơ bản sử dụng để xây dựng OpenStack là một laptop có cấu hình nhƣ sau:

 RAM: 16 BG

 CPU: 16

 Processor: Intel core i7-7600U

Tuy nhiên, OpenStack cần tối thiểu ba node để hoạt động nhƣ mong muốn. Các node này là các máy ảo sẽ chạy trên máy chủ vật lý. Cơ sở hạ tầng ảo cần thiết là nhƣ sau:

 Máy ảo: Mỗi node cần thiết trong quá trình triển khai sẽ là một máy ảo. Trong triển khai này, nó đã đƣợc sử dụng ba máy ảo, một cho mỗi node có tên là controller, network và compute.

 Mạng ảo: Các mạng này sẽ đƣợc sử dụng để kết nối các máy ảo. Hai mạng đã đƣợc xác định trong triển khai này, một cho mục đích quản lý và một cho mục đích trao đổi thông tin nội bộ giữa các nút.

3.2.2 Máy ảo

Để chạy VM, tôi đang sử dụng VMWare Workstation, bên trong tất cả các máy ảo chạy trên bộ ảo hóa KVM và tôi đã cài đặt Ubuntu Server 16.04.3 LTS làm hình ảnh cơ bản. Cấu hình cho từng instance nhƣ sau:

 RAM: 8 GB

 CPU: 4

 Storage: 30GB

3.2.3 Môi trƣờng Single-Node

Trong các phiên bản OpenStack gần đây, các lệnh OpenStack đang sử dụng và cung cấp một giao diện chung cho nhiều dự án, chẳng hạn nhƣ:

 OpenStack network: quản lý networking trong Neutron

 OpenStack identity: quản lý xác thực với Keystone

 OpenStack server: quản lý instances trong Nova

 OpenStack stack: quản lý stacks trong Heat

 OpenStack volume: quản lý volumes trong Cinder, etc.

Tuy nhiên, không phải tất cả các dự án đều sử dụng nó, vì vậy, đôi khi, ngƣời dùng cũng cần sử dụng các công cụ dự án cụ thể. Mặc dù, trong luận án này, chúng tôi đang sử dụng cài đặt máy chủ Single-node, do tài nguyên PC bị hạn chế và không hỗ trợ môi trƣờng multi-node.

OpenStack đƣợc cài đặt trên PC cá nhân chạy hệ điều hành Windows 10 và VMWare Workstation đƣợc sử dụng để tạo máy ảo nhƣ một hệ điều hành khách. Việc cài đặt dựa trên tập lệnh Devstack [30]. Ngoài ra, để hiểu rõ hơn về thử nghiệm ban đầu của OpenStack đƣợc thiết lập dƣới dạng cài đặt single-node, cài đặt single-node mang đến kiến thức thực hành ban đầu với các chức năng OpenStack trong khi đơn giản hóa quy trình cài đặt và phù hợp với PC có tài nguyên phần cứng bị hạn chế.

Trong chế độ all-in-one của Devstack, các mô-đun và dịch vụ OpenStack cơ bản (Identity, Nova, Neutron, Stack, Dashboard) đƣợc cài đặt và chạy trên cùng một máy chủ. Mặc dù Devstack cung cấp một phƣơng pháp nhanh chóng hiệu quả và dễ dàng để trải nghiệm OpenStack, nhƣng nó hoàn toàn không đƣa ra chi tiết phƣơng thức cài đặt và hƣớng dẫn tùy chỉnh cấu hình.

Điều này làm cho hệ thống khó hiểu hơn, đặc biệt là khi gỡ lỗi, các thành phần của nó sẽ có thể xảy ra bất kỳ vấn đề nào trong suốt quá trình cài đặt hoặc vận hành. Mặc dù vậy, DevStack rất thích hợp cho ngƣời mới bắt đầu thay vì phải thực hiện cài đặt đầy đủ cho cụm OpenStack đầy đủ tính năng.

3.3 DevStack

DevStack là một tập hợp các script và tiện ích để nhanh chóng triển khai môi trƣờng đám mây OpenStack và nó có sẵn miễn phí trên GitHub. DevStack cho phép các nhà phát triển và quản trị viên hệ thống tự động hóa quá trình cài đặt OpenStack trên máy chủ, sử dụng một lệnh đơn giản cho mỗi lần cài đặt. Các dịch vụ đƣợc đảm bảo theo mặc định là Identity (Keystone), Object Storage (Swift), Image Storage (Glance), Block Storage (Cinder), Compute (Nova), Network (Neutron), Dashboard

(Hoziron) và Orchestration (Heat). Script chính đƣợc sử dụng là stack.sh, nó thực hiện tất cả các công việc, cài đặt và cấu hình tất cả các dịch vụ ngƣời dùng, tuy nhiên, để sử dụng phiên bản ổn định lệnh git checkout stable/pike đƣợc sử dụng. Tất cả các điều kiện cần thiết, chẳng hạn nhƣ kho Git sẽ sử dụng, các dịch vụ đƣợc kích hoạt hoặc image OS sẽ sử dụng, có thể ghi đè các biến môi trƣờng mặc định (tìm thấy trong stackrc) thông qua tệp local.conf. Phần này đƣợc cấu hình trong phần localrc, nhƣ dƣới đây [30]

====================================== [[local|localrc]]

ADMIN PASSWORD=Password1

DATABASE PASSWORD=$ADMIN PASSWORD RABBIT PASSWORD=$ADMIN PASSWORD SERVICE PASSWORD=$ADMIN PASSWORD HOST IP=192.168.214.128

======================================

Các biến môi trƣờng ENABLE SERVICE đƣợc sử dụng để định nghĩa cho các dịch vụ chạy, ví dụ dịch vụ Nova đƣợc cài đặt, trong máy tính sẽ đƣợc cài đặt gồm

nova-compute, nova-api, nova-network. Bằng cách chạy script

tools/install prereqs.sh, nó có thể thực hiện cài đặt tất cả các phụ thuộc

yêu cầu khi cấu hình dịch vụ. Các script hữu ích khác do DevStack cung cấp là

unstack.sh, cho phép dừng mọi thứ đã đƣợc bắt đầu bởi stack.sh và

clean.sh cố gắng xóa tất cả các dấu vết cài đặt OpenStack để lại do DevStack thực

hiện.

3.3.1 Cấu hình Network

Network node chạy Networking plugin và một số agent khác cung cấp mạng cho ngƣời dùng và cung cấp dịch vụ chuyển mạch, NAT, DHCP và định tuyến. Node này xử lý kết nối bên ngoài cho các máy ảo đƣợc thuê. Trƣớc khi cài đặt các mô-đun, cấu hình mạng cần đƣợc khởi động ở mọi node nhƣ đƣợc hiển thị trong hình 3.1. Phần này rất quan trọng để xác nhận kết nối giữa các node và với internet.

H nh 3.1: Kiến trúc All-in-one Single-node

3.3.2 Network node

Mạng là một chủ đề lớn trong OpenStack. Trong quá khứ, mạng đã đƣợc Nova định nghĩa. Tuy nhiên, khi mạng ngày càng trở nên phức tạp, một dự án riêng biệt đã đƣợc tạo ra để đối phó với vấn đề đó: Neutron. Một số quy trình có thể đƣợc tham gia để làm cho mạng Neutron xuất hiện trong OpenStack. Để thực hiện kết nối mạng thành công trong OpenStack, Neutron cần một vài agent mặc định, cũng nhƣ một số agent bổ sung, có thể đƣợc cài đặt theo yêu cầu [32]: Default Agent

 neutron-openvswitch-agent: Agent này đƣợc cài đặt để tích hợp Open vSwitch với Neutron

 neutron-dhcp-agent: Agent này phân phối địa chỉ IP cho các máy ảo bằng trình điều khiển dnsmasq

nh 3.2: Neutron Default Agents

 neutron-l3-agent: Agent này cho phép tạo ra các thiết bị mạng kết nối tới mạng Layer 2

 neutron-metadate-agent: Cung cấp thông tin cấu hình cũng nhƣ chứng thực cho các instance

Để chạy Neutron thành công ta cũng cần một số các agent/module bổ sung:

 neutron-server

 neutron-ovs-cleanup

 neutron-lbaas-agent

 neutron-plugin-ml2

 python-neutronclient

Các cấu hình của Neutron đƣợc tổ chức trong 5 tệp cấu hình dƣới đây cùng với các dƣờng dẫn lƣu trữ của các tệp:

 neutron.conf tại /etc/neutron/

 ml2 conf.ini tại /etc/neutron/plugins/ml2/

 l3 agent.ini tại /etc/neutron/

 dhcp agent.ini tại /etc/neutron/

 metadata agent.ini tại /etc/neutron/

Nhƣ tất cả các tệp cấu hình OpenStack, chúng cũng đƣợc phân phối trong nhiều mục cấu hình [tên của đề mục].

neutron.conf

Cho phép nhập các tuỳ chọn cấu hình. Tệp neutron.conf chịu trách nhiệm cho việc cấu hình database, cơ chế xác thực, message broker, thông báo sự thay đổi của

Dƣới đây là cấu hình mặc định của OpenStack với cài đặt DevStack, liên quan đến các phần [DEFAULT], [keystone_authtoken] và [nova]. Trong phần DEFAULT, có một vài tùy chọn mặc định đƣợc cấu hình nhƣ

 service_plugins=neutron.services.l3_router_plugin.L3RouterPlugin. Nó thiết

lập bộ định tuyến nhƣ là điểm tiếp nhận các plugin dịch vụ có thể tải từ neutron.service_plugins

 auth_strategy = keystone: Nó sử dụng Keystone làm nhiệm vụ xác thực

 core plugin=ml2: Nó thiết lập ml2 framework là một Neutron core plugin, sẽ đƣợc tải từ neutron.core_plugins namespace.

 notify_nova_on_port_status_changes=True:Nó cho phép gửi thông báo tới

nova khi trạng thái cổng thay đổi.

 notify_nova_on_port_data_changes=True: Nó cho phép gửi thông báo đến

nova khi chuyển dữ liệu, chẳng hạn nhƣ ips cố định hoặc Floating IP, thay đổi để nova có thể cập nhật bộ đệm của nó.

Trong phần keystone_authtoken, có xác định các tùy chọn sau:

 project_name = service: Thiết lập service là tên do ngƣời quản trị đặt.

 user = neutron: Đặt neutron là tên của admin.

 password = NEUTRON_PASS (Password1): Đặt mật khẩu ngƣời dùng Neutron

để xác thực với Keystone.

 auth_url = http://IP_ADDRESS/identity: Đặt đƣờng dẫn API identity

 auth_type = password: Đặt mật khẩu xác thực cho API identity.

 username = nova: Đặt tên ngƣời dùng để kết nối với nova.

 password = NOVA_PASS (Password1): Đặt mật khẩu để kết nối với nova.

 area_name = RegionOne: Đặt tên của vùng nova sẽ sử dụng. Vì cấu hình trong

Keystone chỉ xem xét một region nên cấu hình này không quan trọng.

Cũng cần lƣu ý rằng có một vài lựa chọn không đƣợc sử dụng kể từ khi phát hành phiên bản Queens, đƣợc sử dụng trong luận án này, chẳng hạn nhƣ auth_uri, identity_uri...

ml2 conf.ini

Tệp cấu hình thứ hai là ml2 conf.ini, tệp cấu hình này mô tả cơ chế Open vSwitch (OVS) để xây dựng framework mạng ảo cho các instance. Trong controller node không có các thành phần OVS vì nó không xử lý lƣu lƣợng mạng của instance. Phần ml2 cung cấp các loại network và driver:

 tenant_network_types=vxlan: Một danh sách các network_types để phân bổ cho các mạng tenant. Giá trị mặc định "local", rất có ích cho kiểm tra single- box nhƣng không cung cấp kết nối giữa các máy chủ. Cấu hình loại VXLAN network mà các tenant network sử dụng.

 extension_drivers = port_security: Nó đặt port_security làm extension mở rộng

sẽ đƣợc tải từ neutron.ml2.extension_drivers namespace.

 mechanism_drivers=openvswitch,linuxbridge: Nó đặt openvswitch và

linuxbridge làm trình điều khiển cơ chế mạng đầu vào đƣợc tải từ

neutron.ml2.mechanism_drivers namespace.

Mục securitygroup đƣợc định nghĩa bằng các tuỳ chọn sau:

 firewall_driver=iptables_hybrid: Cấu hình OVS iptable firewall driver

Trong phần ml2_type_* có các tuỳ chọn sau:

 flat_network = public: cấu hình tên công khai cho mạng vật lý mà ở đó các

mạng đƣợc tạo

 network_vlan_range = public:cấu hình mạng vật lý "công khai" mà không có bất kỳ phạm vi VLAN nào cho nhà cung cấp và ngƣời thuê.

 tunnel_id_ranges = 1:1000: Đặt 1 tới 1000 GRE tunnel ID có thể phân bổ cho

tenant network.

 vni_range = 1:1000:Đặt 1 tới 1000 Geneve VNI và VXLAN VNI ID có thể

phân bổ cho tenant network.

l3 agent.ini, dhcp agent.ini, metadata agent.ini

Các tập tin hình tiếp theo là l3_agent.ini, dhcp_agent.ini và metadata_agent.ini. Những tập tin này cung cấp dịch vụ định tuyến cho mạng ảo. Trong phần DEFAULT đã cấu hình các tùy chọn sau:

 interface_driver = openvswitch: Cấu hình openvswitch là driver để duy trì các

interface ảo [34]

 ovs_use_veth = false: Cấu hình false cho phép không sử dụng veth cho OVS interface.

 debug = false: Đặt false cho phép logging level sẽ set thành DEBUG.

 dnsmasq_local_réolv = True: Đặt true cho phép dnsmasq service cũng cấp dịch

vụ phân giải tên cho các instacne thông qua DNS resolvers thông qua máy chủ đang chạy DHCP agent.

 metadata_workers = 2: Số lƣợng worker process riêng cho metadata server sẽ

 nova_metadata_host=IP_ADDRESS: Cấu hình IP của Nova metadata server. 3.4 Cấu hình Neutron

Khi dịch vụ Neutron hoạt động tốt, bây giờ ta có thể có các thay đổi theo yêu cầu, nó có thể đảm bảo cơ sở hạ tầng mạng ảo mà các instance sẽ kết nối và có thể trao đổi dữ liệu giữa chúng. Để làm đƣợc điều này, ta sẽ tạo ra hai loại mạng, mạng bên ngoài và một hoặc nhiều mạng bên trong sẽ là một phần của single tenant.

nh 3.3: Cấu hình Network với CLI

nh 3.4: Network Dashboard

3.4.1 External network

Các external network thƣờng liên lạc qua các mạng vật lý có thể định tuyến công khai trên Internet. Có thể có một hoặc nhiều external network đƣợc tạo với neutron theo yêu cầu [41]:

 Máy ảo có thể định tuyến các gói từ mạng nội bộ đến internet

 Máy ảo có thể sử dụng Floating IP và sử dụng để giao tiếp công khai với internet

External network cung cấp quyền truy cập Internet cho các instance sử dụng NAT (Network Address Translation) theo mặc định, nó cũng đƣợc kết nối riêng với node mạng và có thể đƣợc truy cập bằng cách sử dụng Neutron. External network có phạm vi cho tất cả ngƣời dùng và chỉ có thể đƣợc tạo bởi quản trị viên. Ngƣời dùng kết nối bộ định tuyến của họ để truy cập bên ngoài. Hầu hết hiện nay có 2 loại mạng hay sử dụng là flat (untagged) và VLAN (802.1Q tagged).

Việc tạo mạng có thể đƣợc thực hiện từ ngƣời dùng trong môi trƣờng Dashboard hoặc bằng cách sử dụng OpenStack CLI [42]:

Ở đây Net1 và Net2 đƣợc cấu hình nhƣ một internal/tenant network và external network đƣợc tạo để gửi lƣu lƣợng qua đám mây. Để làm cho internal network giao tiếp với external network, Virtual Router đƣợc sử dụng, trong Project1 VR đƣợc sử dụng để định tuyến lƣu lƣợng và bộ router1 là bộ định tuyến mặc định.

CLI chỉ cung cấp thông tin cụ thể hơn liên quan đến Project.

nh 3.5: Virtual Routers

nh 3.6: Virtual Router cho Project1

nh 3.7: Namespaces

Khi bộ định tuyến đƣợc cấu hình, nhiều namespace qrouter và qdhcp xuất hiện trên node mạng, vì chúng là bản sao logic của ngăn xếp mạng sở hữu bộ định tuyến, quy tắc tƣờng lửa và thiết bị giao diện mạng. Namespace qrouter và qdhcp có các tác vụ độc quyền của chúng, namespace qrouter chịu trách nhiệm đại diện cho bộ định tuyến ảo và định tuyến lƣu lƣợng đến và từ các instance, mặt khác, namespace qdhcp

chịu trách nhiệm cấp DHCP cho mạng [43].

Tuy nhiên, để kết nối các máy ảo trong mạng và qua mạng, OvS đƣợc sử dụng. Bên cạnh kỹ thuật ảo hóa, tất cả các instance đều có TAP interface hoạt động trên lớp 2. Hơn nữa, br-int nhận các gói đƣợc gắn thẻ VLAN và nhận ra mạng mà chúng thuộc về và chuyển gói bằng cách gắn thẻ cho nó thông qua br-ex hoặc không theo đặc tả của đích đến.

stack@openstack: /devstack$ sudo ovs-vsctl show d24c5356-3873- 4a61-b1e4- cc541bedd351 Manager "ptcp:6640:127.0.0.1" is connected: true Bridge br-ex Controller "tcp:127.0.0.1:6633" is connected: true

fail mode: secure Port "ens33" Interface "ens33" Port br-ex Interface br-ex type: internal Port phy-br-ex Interface phy-br-ex type: patch options: peer=int-br-ex Bridge br-int Controller "tcp:127.0.0.1:6633" is connected: true

fail mode: secure Port patch-tun Interface patch-tun type: patch options: peer=patch-int Port "qvof4f07e46-10" tag: 3 Interface "qvof4f07e46-10" Port "qr-9043aecb-62" tag: 3 Interface "qr-9043aecb-62" type: internal