Luận văn Nghiên cứu triển khai và đánh giá hiệu năng của các giải pháp networking nâng cao cho hệ thống ảo hoá sử dụng openstack

n (Tunneling bridge): Đảm nhận việc dịch lưu lượng truy cập được dán nhãn. Nó diễn giải Vlan ID thành phân đoạn và sử dụng nó sau đó để tạo đường hầm. Ví dụ, để sử dụng các đường hầm GRE, ID phân đoạn được sử dụng để chỉ định ID đường hầm. L2 agent có thể trả lời thêm để áp dụng các quy tắc cụm bảo mật (firewall rule) được thi hành qua Neutron bằng cách sử dụng các bộ IPTABLES và IP. Open vSwitch Agent Như đã đề cập trước đó, Neutron cần các agent bổ trợ (ví dụ: neutron- openvswitch-agent) để cho phép hypervisor và các node mạng cung cấp cấu hình OpenvSwitch cục bộ. OVS agent cung cấp kết nối lớp 2 giữa các máy ảo và do đó cơ sở hạ tầng mạng vật lý sử dụng gắn thẻ VLAN (802.1q). Nó hỗ trợ một mạng không được gắn thẻ (flat) và lên tới 4095 mạng được gắn thẻ (VLAN). Số lượng cụ thể của các mạng VLAN phụ thuộc vào cơ sở hạ tầng mạng vật lý. Sau khi nhận được một yêu cầu từ OVS agent, neutron-server sẽ tìm ra OVS tương ứng. Điều này chủ yếu liên quan đến việc đưa vào Integration bridge (br-int), để tất cả các dịch vụ mạng nội bộ và tenant VM được kết nối. Neutron-openvswitch agent phụ thuộc đáng kể vào API dành riêng cho OVS (ovs lib) để cấu hình OVS và xử lý các mục nhập riêng thông qua 2 tiện ích ovs-vsctl và ovs-ofctl, tương ứng. Mặc dù là switch tương thích OpenFlow, 24 OVS hoạt động bên trong mạng neutron như một switch L2 thông thường với mỗi riêng và truyền thống [16]. Linux operative agent Linux bridge agent chỉ ra các bridge Linux để cho phép sử dụng các mạng L2 cho các tài nguyên OpenStack. Cấu hình cho Linux bridge agent thường được thực hiện trong tệp cấu hình linuxbridge_agent.ini. Đảm bảo rằng khi agent bắt đầu chạy ta cần chuyển tệp cấu hình này làm đối số [14]. SRIOV Nic Switch agent SRIOV nic switch agent cấu hình các chức năng PCI ảo để cho phép OpenStack hiểu được L2 network. Mạng đính kèm cho các tài nguyên khác như bộ định tuyến, DHCP, sau đó sẽ không được hỗ trợ. Cấu hình cho SRIOV nic switch agent thường được xử lý trong file sriov_agent.ini, đảm bảo rằng khi agent bắt đầu chạy. ta cần chuyển tệp cấu hình này làm đối số [14]. MacVTap agent MacVTap agent sử dụng các thiết bị MacVTap kernel để thực hiện các mạng L2 cho các OpenStack instance. Mạng đính kèm cho các tài nguyên thay thế như bộ định tuyến, DHCP, sau đó sẽ không được hỗ trợ. Tệp cấu hình cho MacVTap agent thường được thực hiện trong tệp macvtap_agent.ini. Chắc chắn rằng khi agent trên bắt đầu chạy hay truyền tệp cấu hình này như là một đối số [14]. 2.1.5.2.5 L3 agent Mặc dù L3 agent chia sẻ khá nhiều khía cạnh kiến trúc tương đương như L2 agent, nhưng nó vẫn có một số điểm hoàn toàn khác. Với sự trợ giúp của L2 agent, ta có thể kết nối với các mạng với nhau. Ngược lại, L3 agent có các bộ định tuyến cho phép kết nối với các thành phần khác nhau. Nó chuyển dữ liệu từ một mạng sang một mạng khác và từ mạng của bạn ra mạng ngoài. Hình 2.6 cho phép tóm tắt các dịch vụ L3 cùng với các yếu tố ảo được cấu hình bởi L2 agent. L3 agent tạo các cổng nội bộ hoàn toàn khác nhau với các tiền tố tap cho dịch vụ DNS, qr- cho bộ định tuyến ảo hoặc tiền tố qg- cho một External network (công khai) [17]. Đúng như tên gọi của nó, neutron L3 agent (neutron-l3-agent) cấu hình cho phép một node hoạt động với các dịch vụ mạng lớp 3 hoàn toàn khác nhau như định tuyến, NAT và Floating IP. Theo mạng truyền thống, các dịch vụ L3 như vậy chạy trên node mạng và dựa vào L2 agent để cung cấp kết nối lớp 2 cho các VM instance chạy trên các node điện toán. Các Neutron L3 agent sử dụng ngăn xếp Linux IP và iptables [18] để thực hiện chuyển tiếp 25 L3 và NAT. Để hỗ trợ nhiều bộ định tuyến có địa chỉ IP có thể chồng lấp (overlapping IP address), các neutron-l3-agent mặc định sử dụng các Linux network namespace để cung cấp các trường hợp chuyển tiếp bị cô lập (isolated forwarding). Routing Một network namespace giống như container hoặc VM cho thiết bị mạng, nói cách khác, ảo hóa ngăn xếp mạng (network stack virtualization). Tương tự như kết nối mạng thông thường, việc định tuyến là bắt buộc nếu các gói được gửi từ mạng con này sang mạng con khác, bao gồm lưu lượng giữa các máy ảo thuộc mạng con di động hoặc Hình 2.6: OpenStack Neutron L3 Agents giữa máy ảo và máy chủ có thể truy cập qua External network. L3 phụ thuộc vào L2 agent, theo cách tương tự Nova phụ thuộc vào L2 agent để kết khởi tạo cổng và kết nối. Khi các cổng đó tồn tại, cho dù đó là cổng ovs hay cặp VETH (virtual ethernet), chúng có thể được chuyển vào một namespace, giống như lấy một sợi dây và cắm nó vào thiết bị của bạn. Sau đó, nhiệm vụ của L3 agent là cấu hình địa chỉ IP trên các giao diện. Nó cấu hình định tuyến, cho dù đó là bảng định tuyến cơ bản hay các tuyến bổ sung đã được cấu hình trên bộ định tuyến. Nó sử dụng iptables để thực hiện chức năng Floating IP và cung cấp một Floating IP cho bản máy ảo tương ứng. Neutron phải tìm 26 ra bộ định tuyến chuyên dụng cho mọi phiên bản cụ thể cần phải đi qua để đến mạng bên ngoài và nó sử dụng NAT để thực hiện Floating IP đó. Giả sử rằng có nhiều mạng người dùng và cùng chia sẻ một External network và mỗi mạng trước được kết nối với mạng sau thông qua bộ định tuyến ảo dựa trên Neutron. Một bộ định tuyến như vậy sẽ hoạt động như sau: • Kết nối tới mạng nội bộ (tenant) thông qua giao diện \ qg- \ (gateway) trên br- ex • Kết nối tới External network thông qua cổng giao diện \ pr- \ (router) trên br-int (integration bridge) • Có một namespace (tiền tố \ qrouter- \) liên kết với tên bộ định tuyến để tránh các kết nối IP giữa các mạng. Trên bộ định tuyến, có quyền truy cập siêu dữ liệu, quyền truy cập được chia sẻ cho các instance không có Floating IP và tích hợp một số dịch vụ nâng cao (VPNaas và FWaas). NAT Neutron-l3-agent sẽ thực thi NAT (Network Address Translation) cho bộ định tuyến, chức năng này sử dụng bảng định tuyến iptables của nhân Linux, cho phép các gói từ mạng nội bộ (tenant) được gửi ra External network thành công, trước khi đi ra khỏi web. Giống như định tuyến, các quy tắc NAT của bộ định tuyến phải được thực thi trong một namespace của bộ định tuyến cụ thể để tách chúng ra khỏi mạng máy chủ và mạng của các khách hàng khác sử dụng dịch vụ. Floating IP Theo mặc định, các phiên bản máy chủ có IP mặc định được gán cho chúng. Nhưng nó chỉ hoạt động trong nội bộ. Một floating IP cần được gán cho instance cho để có thể truy cập ra bên ngoài. Compute API sẽ cung cấp một số chức năng để truy cập và sử dụng floating IP. IP được tạo trong mạng nơi khởi chạy máy chủ. API chọn floating IP có sẵn đầu tiên từ nhóm IP và liên kết nó với instance. Nếu một instance bị tắt hoặc xoá bỏ, floating IP của nó sẽ được sử dụng lại. Bộ định tuyến ảo cung cấp floating IP thông qua NAT và iptables. Dịch vụ L3 này phân bổ và liên kết các địa chỉ IP từ một mạng bên ngoài đến các VM thuê bên trong để cho phép chúng có thể truy cập trực tiếp từ một mạng bên ngoài. Như đã giải thích ở trên, neutron-l3-agent thực hiện floating IP cũng bằng cách sử dụng iptables để thực hiện NAT. 2.1.5.2.6 DHCP agent Neutron phụ thuộc vào DHCP agent của nó, neutron-dhcp-agent, nằm trong node mạng để cung cấp dịch vụ Dynamic Host Configuration Protocol (DHCP) cho 27 các mạng được thuê, sau đó phân bổ địa chỉ IP cho VM. đặc biệt, dnsmasq [20] được sử dụng làm dịch vụ back-end cho mục đích này. Đối với mỗi mạng con được tạo, có một trình nền dnsmasq sẽ chạy và được gắn vào int-br qua cổng với tiền tố tap- trong một DHCP namespace. 2.1.5.3 Kiến trúc network Có 4 loại mạng trong một cấu hình OpenStack tiêu chuẩn: Management, Guest, API và External networks [21] Management network Được sử dụng để liên lạc nội bộ giữa các thành phần trong OpenStack. được sử dụng cho quản trị và các hoạt động nội bộ của OpenStack như xác thực, truy cập vào cơ sở dữ liệu nội bộ (trên Controller node), cấu hình, v.v. Khi cụm đang được thiết lập, tất cả các cấu hình yêu cầu kết nối nhiều node đều sử dụng Management network. Các địa chỉ IP trên mạng này chỉ có thể được truy cập trong trung tâm dữ liệu và được đưa vào trong Management Security Domain. Guest network (mạng khách) Được sử dụng để liên lạc dữ liệu giữa các VM bên trong đám mây. Các nhu cầu về địa chỉ IP của mạng này phụ thuộc vào OpenStack Networking plug-in được sử dụng và cả các lựa chọn cấu hình mạng của các mạng ảo được tạo bởi người dùng. Mạng này được đưa vào Guest Security Domain. External network Bất kỳ mạng nào được thiết lập đều có tối thiểu một External network. ngược lại với các mạng khác, External netowork không chỉ đơn giản là một mạng ảo được định nghĩa. Thay vào đó, nó thể hiện một cách nhìn vào một phần của vật lý, External network có thể truy cập từ bên ngoài OpenStack. Địa chỉ IP trên external network có thể được truy cập bởi bất kỳ ai trên mạng bên ngoài. Ngoài ra, bất kỳ external network nào được thiết lập đều có một hoặc vài mạng nội bộ bổ sung. Các mạng định nghĩa bằng phần mềm này kết nối với các VM, chỉ các VM trên bất kỳ mạng nội bộ cụ thể nào hoặc các VM trên mạng con được kết nối qua giao diện với cùng một bộ định tuyến sẽ truy cập trực tiếp vào các máy ảo được kết nối với mạng. Nó thực chất là gateway cho phép lưu lượng truy cập từ các VM instance đến các mạng vật lý hay nói cách khác, nó được sử dụng để cho phép VM có quyền truy cập internet trong một số tình huống triển khai. Các địa chỉ IP trên mạng này cho phép tiếp 28 cận bởi bất kỳ ai trên internet. Như vậy, lưu lượng VM phải đi qua node hoặc các node có khả năng định tuyến. Mạng này được đưa vào trong Public Security Domain. API network Đưa ra toàn bộ OpenStack API, cũng như OpenStack Networking API, tới người dùng. Các địa chỉ IP trên mạng này phải được tiếp cận bởi bất kỳ ai trên internet. Đây có thể là external network vì ta có thể tạo mạng con cho external network với phạm vi phân bổ IP chỉ sử dụng cho API. Mạng này được đưa vào Public Security Domain. 2.1.6 Network và multi-tenancy Ngoài các mạng vật lý kết nối các node khác nhau, trong OpenStack, còn có 2 loại mạng: Mạng người dùng (tenant network) và Mạng nhà cung cấp (provider network) Mạng nhà cung cấp là một mạng nằm ngoài cụm và cho phép kết nối ra bên ngoài, bằng cách đi qua node mạng. Một instance ảo thậm chí có thể phân bổ (và sau đó giải phóng, khi không cần thiết) một floating IP trên mạng này cho phép hiển thị ra bên ngoài. Mạng của nhà cung cấp được tạo bởi người quản trị OpenStack. Thay vào đó, mạng người dùng (còn gọi là mạng tự phục vụ) được hình thành bởi người dùng đám mây để kết nối bên trong các dự án. Tuy nhiên, nó thiếu kết nối với các mạng bên ngoài như internet, trừ khi nó sử dụng bộ định tuyến ảo kết hợp cổng trên mạng của nhà cung cấp. Theo mặc định, các mạng đối tượng thuê hoàn toàn bị cô lập và dường như không được chia sẻ với các dự án khác. Trong giai đoạn tạo ra một instance, một IP cố định được lấy từ mạng này (sẽ không thể sửa đổi được một khi tạo, do kết quả của sự trừu tượng hóa neutron đối với cổng). Hơn nữa, cần lưu ý rằng instance nhận IP từ máy chủ DHCP (thực sự có thể là quá trình dnsmasq [20] được tạo bởi DHCP agent) được cấu hình để cung cấp sao cho IP luôn luôn giống hệt nhau. Neutron OpenStack hỗ trợ các loại dưới đây cho tenant network. • Flat: Tất cả các instances nằm trong cùng một mạng, và có thể chia sẻ với máy chủ. Không hề sử dụng VLAN tagging hay hình thức tách biệt về network khác • VLAN: Cho phép các user tạo nhiều provider hoặc project network sử dụng VLAN IDs (chuẩn 802.1Q tagged) tương ứng với VLANs trong mạng vật lý. Điều này cho phép các instances giao tiếp với nhau trong môi trường đám mây. Chúng có thể giao tiếp với servers, firewalls, load balancers vật lý và các hạ tầng network khác trên cùng một VLAN layer 2 • GRE và VXLAN: VXLAN và GRE là các giao thức đóng gói tạo nên overlay networks để kích hoạt và kiểm soát việc truyền thông giữa các máy ảo 29 (instances). Một router được yêu cầu để cho phép lưu lượng đi ra luồng bên ngoài tenant network GRE hoặc VXLAN. Router cũng có thể yêu cầu để kết nối một tenant network với mạng bên ngoài (ví dụ Internet). Router cung cấp khả năng kết nối tới instances trực tiếp từ mạng bên ngoài sử dụng các địa chỉ floating IP. • Local: trong loại mạng này, các instance nằm trong các máy Compute cục bộ và cách ly với bất kỳ mạng bên ngoài nào. Bên trong một node, các luồng của tenant được phân tách bằng các VLAN ID được gán bên trong. Sau đó, để thực hiện liên lạc giữa các node vật lý, các luồng của tenant được phân tách, ví dụ, bằng VLAN ID, VXLAN ID hoặc GRE ID do người dùng định nghĩa, tùy thuộc vào kỹ thuật cách ly tenant được chọn. Cần lưu ý rằng dù bất cứ cơ chế cách ly tenant nào được sử dụng, bên trong một node OpenStack việc sử dụng các Vlan ID vẫn có thể tạo ra bằng cách gán tự động. Thật vậy, mặc dù một kỹ thuật đường hầm được sử dụng cho các tenant network, các Vlan ID vẫn quen với việc cô lập lưu lượng của tenant trong node. Tuy nhiên, dựa trên ý nghĩa của kỹ thuật này (VLAN, VXLAN, GRE, v.v.), multi-tenant đã đạt được, các cơ chế tiếp theo được yêu cầu để cho những người dùng khác nhau có các mạng chồng chéo. Để làm điều đó, các virtual router cho các tenant network sẽ vẫn được sử dụng vì các quy trình hoạt động như một máy chủ DHCP, được triển khai trong nhiều namespace network. Network namespace là khái niệm cho phép bạn cô lập môi trường mạng network trong một host. Namespace phân chia việc sử dụng các khác niệm liên quan tới network như devices, địa chỉ addresses, ports, định tuyến và các quy tắc tường lửa vào trong một hộp (box) riêng biệt, chủ yếu là ảo hóa mạng trong một máy chạy một kernel duy nhất. Mỗi network namespaces có bản định tuyến riêng, các thiết lập iptables riêng cung cấp cơ chế NAT và lọc đối với các máy ảo thuộc namespace đó. Linux network namespaces cũng cung cấp thêm khả năng để chạy các tiến trình riêng biệt trong nội bộ mỗi namespace. Namespace tên có thể đảm bảo sự cô lập L3, tạo ra khả năng cho nhiều người dùng khác nhau phải chồng chéo địa chỉ IP. Do đó, tính đa dụng đạt được bằng cách sử dụng các kỹ thuật như gắn thẻ Vlan và/hoặc tạo đường hầm (VXLAN, GRE), trong khi cách ly L3 được cấp bằng cách sử dụng nhiều Linux network namespace. Tuy nhiên, cần phải biết rằng Neutron cung cấp nhiều trừu tượng mạng để cho phép người dùng minh bạch với bất kỳ hoặc tất cả các chi tiết cấp thấp này được yêu cầu để cung cấp và tăng cường đa nhiệm trong hệ thống phân tán này. 2.2 OpenvSwitch Có một số công nghệ liên quan đến SDN bao gồm OpenFlow, Open vSwitch và OpenDaylight. Tuy nhiên, phần này chủ yếu tập trung vào Open vSwitch và SDN. 30 Điểm nổi bật giữa các mục quan trọng nhất của phần này là cách thức và nơi Open vSwitch phù hợp với OpenStack. 2.2.1 Motivation cho Open vSwitch Trình ảo hoá muốn linh hoạt kết nối lưu lượng giữa các VM và bên ngoài. Trên các trình ảo hóa dựa trên Linux, điều này có nghĩa là sử dụng bộ chuyển đổi L2 sẵn có (Linux bridge), nhanh và đáng tin cậy. Do đó, cần thiết khi hỏi tại sao Open vSwitch được sử dụng. Câu trả lời là Open vSwitch được nhắm tới mục tiêu triển khai ảo hóa nhiều máy chủ, một cách thức mà các công nghệ trước đó không đáp ứng. Các môi trường này thường được xác định bởi các end-point cực kỳ năng động, việc duy trì logic trừu tượng và tích hợp (đôi khi) với đưa phần cứng chuyển đổi với mục đích đặc biệt. Sau đây là các tính năng của Open vSwitch [39]: • Cho phép giao tiếp giữa các VM thông qua NetFlow, sFlow (R), IP Flow Information Export (IPFIX), Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN) và các cổng ánh xạ tunnel thông qua Generic Routing Encapsulation (GRE). • Link aggregation thông qua Link Aggregation Control Protocol LACP (IEEE 802.1AX-2008) • Mô hình VLAN chuẩn 802.1Q với trunking • Multicast snooping • IETF Tự động đính kèm SPBM và hỗ trợ LLDP cần thiết • BFD and 802.1ag link monitoring • STP (IEEE 802.1D-1998) và RSTP (IEEE 802.1D-2004) • Fine-grained QoS control • Hỗ trợ HFSC qdisc • Kiểm soát lưu lượng trên mỗi VM interface • NIC-bonding với cân bằng tải theo MAC, active-backup và L4 hashing • Hỗ trợ giao thức OpenFlow (bao gồm nhiều phần mở rộng cho ảo hóa) • Hỗ trợ IPv6 • Nhiều giao thức tunneling (GRE, VXLAN, STT và Geneve, với sự hỗ trợ của IPsec) • Giao thức cấu hình từ xa với thông qua C và Python • Tùy chọn công cụ chuyển tiếp kernel và user-space • Multi-table forwarding pipeline with flow-caching engine • Lớp chuyển tiếp trừu tượng để dễ dàng chuyển sang nền tảng phần mềm và phần cứng mới 31 2.2.2 OpenvSwitch Open vSwitch là một dự án nguồn mở của một bộ chuyển mạch phân tán ảo đa lớp, cho phép thực hiện trình ảo hóa các lớp mạng. Điều này phục vụ cho nhiều máy ảo chạy trên một hoặc nhiều node vật lý bổ sung. Với sự trợ giúp của các bridge ảo, các máy ảo có thể giao tiếp với nhau trên cùng một node vật lý, cùng với khả năng kết nối của máy ảo với các cổng của bridge ảo cho phép hoạt động theo cách giống với kết nối của máy chủ vật lý với các cổng vật lý trên một chuyển mạch Lớp 2. Để giao tiếp bên ngoài hypervisor node, các bridge này kết nối các máy ảo với mạng vật lý. Trong OpenStack, mỗi node neutron và cả node Compute (Nova) đều đang chạy Open vSwitch để cung cấp các dịch vụ mạng ảo hóa [23]. OVS phụ thuộc vào 2 yếu tố trong khi chuyển tiếp gói giữa các máy chủ gồm: virtual network bridges và các quy tắc của chúng. OVS có 3 thành phần chính gồm mô-đun máy chủ (ovsdb-server), chương trình deamon (ovs-vswitchd) và một kernel mô-đun. • ovs-vswitchd - Open vSwitch deamon (Slow Path): đây là mô-đun phần mềm thường chạy trong các máy người dùng cho phép giao tiếp với cụm điều khiển (control cluster), nó thường bao gồm các mô-đun quản lý mạng và một SDN controller, cho phép cấu hình mạng và chương trình đưa vào đường dẫn nhanh của kernel. • ovsdb-server - Open vSwitch database server, nơi mà các cấu hình và chính sách chuyển mạch của OVS được lưu trữ. • openvswitch_mod.ko - kernel module (Fast Path): đây thường là gói phần mềm thường chạy trên hệ điều hành hoặc hypervisor kernel để thực sự thực hiện xử lý gói. 32 Hình 2.7: Tổng quan kiến trúc Open vSwitch Open vSwitch là một phần mềm chuyển mạch hỗ trợ OpenFlow. • OpenFlow controller chịu trách nhiệm hướng dẫn cho kernel module (fast- path) biết làm sao xử lý các loại gói khác nhau, hay còn gọi là flows. Một flow mô tả hành động mà kernel module thực hiện để xử lý các gói tin của cùng một loại như thế nào, hay còn được gọi là action. Các kiểu hành động bao gồm chuyển tiếp tới port khác, thay đổi vlan tag... Quá trình tìm kiếm flow khớp với gói tin nhận được gọi là flow matching. • Nhằm mục đích đạt hiệu năng tốt, một phần của flows được cache trong kernel module, và phần còn lại ở vswitchd. • Một gói tin đi vào Open vSwitch kernel module sau khi nó được nhận trên một card mạng. Nếu gói tin khớp với flow nào đó trong kernel module thì kernel module sẽ thực thi các actions tương ứng mô tả trong flow entry. Nếu không (flow missing), kernel module sẽ gửi gói tin lên kernel module và tiến trình flow-matching khác được xử lý tại đây. Sau khi ovs-vswitchd xác định làm sao để xử lý gói tin, nó gửi trả gói tin lại cho kernel module cùng với yêu cầu xử lý. Đồng thời, vswitchd cũng yêu cầu kernel module cache lại flow để xử lý các gói tin tương tự sau đó 33 Hình 2.8: Xử lý gói trong Open vSwitch 2.2.3 Các đặc điểm của OpenvSwitch Open vSwitch là một trong ba thiết bị chuyển mạch ảo phổ biến bên cạnh VMware và Cisco Nexus 1000V. Nicira, sau khi được VMware mua, đã tạo Open vSwitch để giải quyết các vấn đề của cộng đồng mã nguồn mở vì không có phần mềm chuyển mạch ảo đủ đáp ứng nào dành cho một trình ảo hóa dựa trên Linux, ví dụ, KVM và XEN. OVS đã nhanh chóng biến thành chuyển mạch ảo được chấp nhận cho môi trường XEN và hiện tại nó đang có tác động quan trọng đối với dự án OpenStack và cũng là một kiến trúc đáng chú ý trong môi trường SDN. Các đặc điểm sau đã giúp Open vSwitch đảm bảo các yêu cầu thiết yếu. • Tính cơ động của trạng thái: Tất cả các trạng thái mạng liên quan đến một thành phần mạng như máy ảo phải dễ dàng xác định và có thể dịch chuyển trong một môi trường không đồng nhất. Điều này có thể được thể hiện bằng "soft state" thông thường, trạng thái chuyển tiếp L3, ACL, QoS, v.v. Open vSwitch đã kết hợp cả cấu hình và dịch chuyển trạng thái mạng giữa các phiên bản. • Đáp ứng được các thay đổi của mạng: Các môi trường ảo thường được mô tả bằng tỷ lệ đa dạng hóa cao về mặt thêm/xóa VM, thực hiện các thay đổi về cấu hình của mạng, v.v. Open vSwitch đưa ra một nền tảng kiểm soát mạng dựa trên nhận biết và điều chỉnh khi môi trường thay đổi. • Bảo trì các thẻ logic: Các thiết bị chuyển mạch ảo phân tán, ví dụ, VMware vDS và Nexus 1000V của Cisco thường xuyên duy trì sự logic trong mạng thông qua việc gắn thêm hoặc thao tác các thẻ trong các gói mạng. Điều này có 34 thể được sử dụng để nhận ra VM hoặc để giữ một số cài đặt khác chỉ liên quan trong miền logic đó. Một phần quan trọng trong vấn đề xây dựng một chuyển mạch ảo phân tán là để xử lý hiệu quả và chính xác với các thẻ này. Open vSwitch kết hợp nhiều kỹ thuật để xác định và duy trì các quy tắc gắn thẻ, tất cả đều có sẵn cho một quy trình từ xa để phối hợp. • Tích hợp phần cứng: Đường dẫn chuyển tiếp của vSwitch mở có thể quản lý để "giảm tải" xử lý gói cho các thiết bị chipset, bất kể nó nằm trong khung chuyển đổi thiết bị cũ trong một máy chủ lưu trữ cuối. Điều này tính đến đường dẫn điều khiển Open vSwitch để có khả năng điều khiển cả việc thực thi phần mềm khi được cải tiến hoặc chuyển đổi thiết bị. Open vSwitch kiểm soát trìu tượng, cả môi trường lưu trữ ảo và bare-metal đều có thể được quản lý bằng cùng một cơ chế để điều khiển mạng tự động. 2.2.4 Software Defined Network (SDN) Nhiều công ty trực tuyến và đám mây lớn đang chuyển các trung tâm dữ liệu của họ sang ảo hóa để có được lợi ích từ QoS và khả năng dự đoán. Tương tự như vậy, mạng có độ an toàn cao và chi phí thấp là rất quan trọng. Do đó, các nhà cung cấp dịch vụ và các công ty mạng cần một giải pháp thay thế để sử dụng một cách thông minh và hiệu quả. SDN, còn được gọi là Software Defined Network được phát triển, nó là công nghệ mạnh mẽ có khả năng xử lý các ứng dụng thông minh cũng như nên tảng phát triển mạnh mẽ cho các mạng trong tương lai đồng thời giảm chi phí vận hành chỉ bằng cách thay đổi phần cứng và phần mềm, tăng cường và đơn giản hóa việc quản lý mạng bằng phần mềm [36]. Tổng quan về kiến trúc của SDN được hiển thị trong hình 2.9 [40] Thiết lập một mạng bao gồm cài đặt và cấu hình phức tạp của bộ định tuyến, bộ chuyển mạch và các thiết bị mạng khác và đòi hỏi một kỹ sư được đào tạo và có kỹ năng cao để giải quyết thực hiện. Cách tiếp cận này là cách tiếp cận dựa trên hệ thống và dựa trên nhà cung cấp và nó sẽ làm tăng chi phí cung cấp, chi phí nhân lực trong việc quản lý mạng đa cấp và đa nhà cung cấp và giảm doanh thu. Đây là lúc các nhà cung cấp dịch vụ đầu tư mạnh mẽ vào các giải pháp thay thế như SDN giúp tăng khả năng quản lý mạng và giảm chi phí cung cấp [1]. Software Defined Networking (SDN) là thuật ngữ xuất hiện và được đặt ra gần đây nhưng khái niệm về SDN xuất phát từ năm 1996. Nhiều công ty bắt đầu xây dựng và triển khai SDN để biến điều này thành hiện thực và các công ty đứng đằng sau SDN là Ipsilon, Internet Engineering Task Force (IETF), OpenDaylight, Open Networking Foundation (ONF), Ethane và OpenFlow... [36]. Đôi khi mọi người gọi SDN là OpenFlow nhưng thực tế, OpenFlow chỉ là một API cho SDN [36]. 35 Software Defined Networking cho phép quản trị viên mạng thích ứng nhanh theo môi trường kinh doanh năng động và có thể điều khiển mạng từ một vị trí tập trung được gọi là bảng điều khiển mà không cần chạm vào bảng điều khiển riêng cho bộ định tuyến hoặc bộ chuyển mạch hoặc các thiết bị mạng khác, có thể cung cấp dịch vụ nhanh chóng và hỗ trợ xử lý mạng mà không cần biết máy chủ hoặc bộ định tuyến cụ thể được kết nối với các thiết bị khác như thế nào [37-38]. Hình 2.9: Tổng quan kiến trúc SDN 2.2.4.1 Why SDN? Động lực chính đứng sau SDN là nâng cao hiệu năng của mạng, cung cấp và triển khai mạng bằng cách tách control và data plane, cho phép lập trình các thiết bị mạng và cho phép các kỹ sư mạng thực hiện một hoạt động mạng từ một bảng điều khiển mà không cần biết kết nối phức tạp thực tế. Thông thường, việc cấu hình các thiết bị mạng đòi hỏi một kỹ sư mạng được đào tạo chuyên sâu và các thiết bị dựa trên nhà cung cấp yêu cầu đào tạo đặc biệt để thực hiện cùng một nhiệm vụ khác n