So Sánh Giải Pháp Giữa Nuage Nokia Và Contrail Juniper

Nghiên cứu, đánh giá ứng dụng giải pháp snd cho hạ tầng mạng truyền tải trong các telco cloud data center - 3

Hình 2.8 - Analytics Node - Configuration node chịu trách nhiệm biên dịch mô hình dữ 1

Hình 2.8 - Analytics Node

- Configuration node chịu trách nhiệm biên dịch mô hình dữ liệu mức cao thành mức thấp hơn phù hợp để tương tác với các phần tử mạng. Configuration node giao tiếp với hệ thống điều phối thông qua giao diện REST. Với các Configuration node khác bằng kỹ thuật đồng bộ phân phối. Và với control node thông qua IF-MAP (Hình 2.9).

Hình 2.9 - Configuration Node Configuration node cung cấp dịch vụ Discovery cho khách hàng 2

Hình 2.9 - Configuration Node

Configuration node cung cấp dịch vụ Discovery cho khách hàng sử dụng có thể định vị các nhà cung cấp dịch vụ. Ví dụ khi vRouter agent trong compute node kết nối với một control node. Nó sử dụng dịch vụ Discovery để khám phá địa chỉ IP của các control node. Máy khách có thể dử dụng để cấu hình cục bộ DHCP hoặc SDN để xác định vị trí của service discovery server.

Configuration node bao gồm các thành phần:

o REST API server.

o Một bus bản tin Redis.

o Cassandra database.

o Schema transformer.

o Server IF-MAP.

o Zookeeper.

- Control node chịu trách nhiệm truyền đạt các dữ liệu trạng thái mức thấp đó tới các phần tử mạng và kết nối với các hệ thống khác một cách nhất quán.

Control node giao tiếp với nhiều node khác nhau (Hình 2.10):

Hình 2.10 – Control Node o Nhận trạng thái cấu hình từ configuration node sử dụng 3

Hình 2.10 – Control Node

o Nhận trạng thái cấu hình từ configuration node sử dụng giao thức if-map

o Trao đổi định tuyến với các control node khác bằng giao thức iBGP

o Trao đổi định tuyến với các vRouter agent trong compute node bằng giao thức XMPP

o Trao đổi định tuyến với gateway node sử dụng BGP và cũng có thể gửi trạng thái cấu hình sử dụng NETCONF

2.1.2.3. Contrail vRouter

Ngoài 3 thành phần chính trình bày ở trên, Contrail SDN controller còn bao gồm 3 phần tử quan trọng khác, đó là: Computer Node, Gateway node và Service node:

- Compute node là các server ảo hóa lưu trữ các VM. Các VM này có thể sử dụng để cho thuê chạy các ứng dụng hoặc có thể là các máy ảo dịch vụ chạy các dịch vụ mạng như Load Balancer, virtual firewall. Mỗi Compute node chứa một Contrail vRouter thực hiện việc chuyển tiếp và phân phối một phần của lớp điều khiển.

Contrail vRouter là các phần tử mạng được triển khai bằng phần mềm. Nó chịu trách nhiệm chuyển tiếp các gói tin từ một VM tới các VM khác thông qua đường kết

nối giữa các server. Bản chất Contrail vRouter là một server x86 chứa các máy ảo. Các VM này được chạy các ứng dụng cá nhân như Web server, database server, các ứng dụng doanh nghiệp hoặc các dịch vụ ảo để tạo chuỗi dịch vụ. Contrail vRouter bao gồm vRouter forwarding plane (mặt phẳng chuyển tiếp) nằm trên Linux kernel, và vRouter agent là Local forwarding plane (mặt phẳng điểu khiển cục bộ). Hai khối

trong Compute node tạo lên Contrail vRouter là vRouter agent và vRouter forwarding plane (Hình 2.11)

Hình 2.11 – Computer Node - vRouter agent thực hiện các chức năng: o Trao đổi trạng 4

Hình 2.11 – Computer Node

- vRouter agent thực hiện các chức năng:

o Trao đổi trạng thái điều khiển như định tuyến với control node sử dụng XMPP.

o Nhận các trạng thái cấu hình cấp thấp như trường hợp định tuyến và nhận chính sách chuyển tiếp từ control node qua giao thức XMPP

o Báo cáo các phân tích trạng thái như logs, statics, các sự kiện tới analytics nodes.

o Thiết lập trạng thái chuyển tiếp vào lớp chuyển tiếp.

o Phát hiện sự tồn tại và thuộc tính của các máy ảo khi kết hợp với Nova agent.

o Mỗi vRouter agent kết nối với ít nhất 2 control node để dự phòng.

- vRouter forwarding plane thực hiện các chức năng:

o Đóng gói mở gói tin được gửi đi hoặc nhận từ overlay network

o Các gói tin nhận được từ overlay network được chỉ định tới 1 trường hợp định tuyến trên cơ sở nhãn MPLS hoặc VNI-virtual network identifier.

o Là giao diện ảo cho các máy ảo nhảy tới các trường hợp định tuyến.

o Nó thực hiện tìm kiếm địa chỉ đích trong cơ sở dữ liệu chuyển tiếp (FIB) tương tự như các bảng chuyển tiếp để chuyển tiếp gói tin đúng tới đích. Việc định tuyến có thể thực hiện ở Layer 3 IP hoặc Layer 2 MAC.

o Các chính sách chuyển tiếp có thể được ứng dụng cho các flow table.

o Match các gói tin với flow table và ứng dụng các flow action.

o Gửi các gói tin không match với flow table tới vRouter agent để cài đặt rule mới vào flow table.

o Gửi các gói tin như DHCP, ARP, MDNS tới vRouter agent để proxying

o Mặt phẳng chuyển tiếp hỗ trợ MPLS dưới GRE/UDP và đóng gói VXLAN ở Overlay. Mặt phẳng chuyển tiếp hỗ trợ cả chuyển tiếp layer 3 và layer 2. Hiện tại mặt phẳng chuyển tiếp vRouter hỗ trợ Ipv4 và có thể hỗ trợ Ipv6 trong tương lai.

- Gateway node là các gateway router hoặc switch vật lý kết nối các máy ảo hoặc mạng ảo tới mạng vật lý như internet, VPN cá nhân, các data center khác hoặc các server không phải ảo hóa.

- Service node là các thành phần mạng vật lý cung cấp các dịch vụ mạng như DPI, IDP, IPS, tối ưu WAN và cân bằng tải. Chuỗi dịch vụ có thể bao gồm nhiều dịch vụ ảo như triển khai VM trong compute node và dịch vụ vật lý như lưu trữ trên các node dịch vụ.

2.1.2.4. Các giao thức quản lý và điều khiển

- Giao thức IF-MAP

- IF-MAP: giao diện truy cập Metadata là một giao thức giữa máy chủ và máy khách tiêu chuẩn mở được phát triển bởi Trusted Computing Group (TCG) là một trong những giao thức cốt lõi của kiến trúc kết nối mạng mở đáng tin cậy.

- IF-MAP cung cấp giao diện giữa Metadata Access Point (MAPs), một database server đóng vai trò trao đổi thông tin về các sự kiện bảo mật, thiết bị bảo mật và các thành phần khác của kiến trúc kết nối mạng đáng tin cậy.

- IF-MAP cung cấp các kỹ thuật mở rộng để định nghĩa mô hình dữ liệu. Định nghĩa giao thức để công bố, mô tả, tìm kiếm trong nơi lưu trữ dữ liệu.

- Contrail sử dụng IF-MAP để phân phối thông tin cấu hình từ Configuration node tới Control node.

- Giao thức XMPP

- Là một giao thức truyền thông cho bản tin định hướng trung gian dựa trên XML. XMPP ban đầu được đặt tên là Jabber được sử dụng để nhắn tin tức thì, hiện diện thông tin, và bảo trì danh sách liên lạc.

- Contrail sử dụng XMPP làm bus thông tin giữa các compute node và control node để trao đổi thông tin bao gồm routes, configuration, operational state, statistics, logs và các sự kiện.

- Giao thức BGP

- Contrail sử dụng BGP (RFC 4271) để trao đổi thông tin định tuyến giữa các control node. BGP cũng có thể được sử dụng để trao đổi thông tin định tuyến giữa control node và gateway node.

- Giao thức Sandesh

- Sandesh là một giao thức dựa trên XML để báo cáo thông tin phân tích. Các thành phần của mọi node đều kết nối với analytics node và trao đổi thông tin thông qua bản tin Sandesh.

2.1.3. So sánh giải pháp giữa Nuage Nokia và Contrail Juniper

Đánh giá kết quả nghiên cứu, thử nghiệm giải pháp SDN cho Telco Cloud Data Center của 2 nhà cung cấp Juniper (Contrail) và Nokia (Nuage) có thể đưa ra một số nhận định và lợi ích nổi bật, cụ thể như sau:

- Với việc sử dụng công nghệ VXLAN giúp số lượng VLAN ID tăng lên 16 triệu, kết quả này giải quyết vấn đề nhu cầu tăng trưởng kết nối giữa các Data center trong tương lai.

- Quá trình quy hoạch, cấp phát, thu hồi tài nguyên IP trong DC được thực hiện tự động, dễ dàng tạo các chuỗi dịch vụ, tự động đấu nối liên kết các tài nguyên hạ tầng mạng (Switch, Router, Firewall, Load Balancer…) giúp giảm đánh kể thời gian triển khai, nhanh chóng đưa dịch vụ đến khách hàng.

- Các tác vụ trong quản lý, vận hành hệ thống thực hiện tập trung và được đơn giản hóa giúp giảm yêu cầu về nhân lực vận hành, cũng như giảm chi phí vận hành mạng lưới.

- Một số thiết bị, chức năng mạng như Switch, Router, Firewall, Load balancer… được ảo hóa để có thể triển khai trên White box hoặc máy ảo giúp giảm chi phí đầu tư hạ tầng mạng.

Để làm rõ ưu/nhược điểm của từng giải pháp, ta đưa ra bảng so sánh chi tiết trong bảng sau:

Giải pháp

Nuage Nokia

Contrail Juniper

Đánh giá

- Triển khai end to end trong DC: tốt

- Khả năng cài đặt: tốt

- Khả năng tùy biến hệ thống: rất tốt

- Tốc độ thực hiện: tốt

- Kết quả test case: tốt

- Triển khai end to end trong DC: tốt

- Khả năng cài đặt: tốt

- Khả năng tùy biến hệ thống: tốt

- Tốc độ thực hiện: tốt

- Kết quả test case: chưa hoàn thiện

Điểm mạnh

- Mở rộng hỗ trợ cả phần cứng và môi trường ảo hóa bao gồm Docker, KVM, Microsoft, Openstack, và Vmware

- Nuage hỗ trợ giao thức VXLAN,

MPLSL3, L2VPNS, GRE, BGP

- Contrail hỗ trợ mạnh mẽ cho Openstack và ảo hóa dựa trên container: Kubernetes và Openshift

- Contrail hỗ trợ giao thức VXLAN,

MPLSL3, L2VPNS, GRE, BGP

Có thể bạn quan tâm!

Xem toàn bộ 48 trang: Nghiên cứu, đánh giá ứng dụng giải pháp snd cho hạ tầng mạng truyền tải trong các telco cloud data center

Giải pháp

Nuage Nokia

Contrail Juniper

- VSC hỗ trợ một số bộ chuyển mạch vật lý từ Arista, DELL, HPE, Nokia và bare metal network (VRS-G)

- Công cụ chính sách mạnh mẽ dựa trên

hệ thống quản lý bảo mật.

- Contrail có thể cấu hình mạng vật lý của Juniper để hỗ trợ kết nối giữa SDN và các mạng ngoài.

Hạn chế

-VSC không kết hợp với NSX của Vmware cho VTEP hoặc các bộ chuyển mạch phân tán của Vmware.

- Cạnh tranh trực tiếp với Cisco và Vmware trong DC SDN

- Hệ sinh thái trung tâm dữ liệu không đa dạng

- Thị trường hạn chế

Bảng 2.1 - So sánh giải pháp giữa Nokia và Juniper

2.2. Nghiên cứu các giải pháp ứng dụng SDN mã nguồn mở

Giải pháp SDN Contrail của Juniper và Nuage của Nokia cho Telco Cloud Data Center có rất nhiều ưu điểm nổi bật, phù hợp với nhu cầu của mạng truyền tải của hầu hết các nhà cung cấp dịch vụ viễn thông và CNTT. Tuy nhiên, việc triển khai SDN hiện đang gặp trở ngại trong vấn đề hiệu quả chi phí đầu tư cũng như định hướng phát triển mở rộng, nâng cao tính năng hệ thống.

Đối với các nhà cung cấp dịch vụ viễn thông & CNTT, vấn đề tối ưu chi phí cũng như hiệu quả đầu tư cực kỳ quan trọng và luôn xem xét hướng đến tìm kiếm một giải pháp không những đáp ứng được hầu hết những lợi ích tương đương từ giải pháp của các hãng mang lại, có khả năng tùy biến linh hoạt phù hợp nhất với hiện trạng hạ tầng mạng lưới của họ, đồng thời cũng phải đảm bảo chi phí đầu tư ban đầu cũng như vận hành hệ thống tối ưu nhất.

Theo quan điểm này, nhóm dự án đã tập trung nghiên cứu, thử nghiệm 2 giải pháp SDN mã nguồn mở Tungsten Fabric và OpenDayLight để so sánh đánh giá tính năng, hiệu năng sử dụng của giải pháp, đánh giá khả năng tương thích hệ thống. Đây cũng là định hướng để xây dựng giải pháp SDN theo nhu cầu của Viettel dựa trên các giải pháp mã nguồn mở trong tương lai.

2.2.1. Giải pháp của Tungsten Fabric (TF)

Tungsten Fabric là một nền tảng mạng ảo hóa mã nguồn mở được phát triển trên nền tảng giải pháp Juniper Contrail, với khả năng mở rộng cao, nó được thiết kế phục vụ cho mạng đa người dùng trong môi trường lớn, sử dụng đồng thời nhiều Orchestrator [9]. Tungsten Fabric triển khai 3 chức năng chính:

- Multi-tenancy

- Gateway function: Kết nối các mạng ảo hóa tới các mạng vật lý, kết nối các dịch vụ mạng ảo và không ảo tới các mạng ảo thông qua một Gateway router.

- Service chaining: Điểu khiển lưu lượng tự động đi qua các chuỗi dịch vụ trong mạng ảo hóa và vật lý như firewall, load balancer.

Ngoài ra Tungsten Fabric cũng cung cấp các chức năng khác như mã hóa bảo mật, theo dõi giám sát hoạt động, topo, hiệu năng hệ thống. Cung cấp các chức năng mạng Routing&Switching, Load balancing. Cung cấp các APIs, Orchestrations, WebUI hỗ trợ việc quản lý vận hành. Tungsten Fabric gồm có thành thành phần chính

Thành phần chính Tungsten Fabric là Controller có chức năng tự động tính toán, cấu hình cho các thiết bị ở lớp chuyển tiếp đáp ứng yêu cầu, chính sách cuả nhà điều phối. Ngoài ra chúng còn tự động thu thập thông tin, trạng thái hoạt động của các phần tử của hệ thống thông qua bản tin Sandesh lưu trữ trong Cassandra database. Nhà vận hành có thể truy cập để lấy các thông tin đã được lưu trong các form thông qua REST API để dễ dàng nhanh chóng xây dựng các ứng dụng giám sát và phân tích hoạt động hệ thống. Controller bao gồm 3 node chính (Hình 2.6):

- Configuration node chịu trách nhiệm biên dịch mô hình dữ liệu mức cao thành mức thấp hơn phù hợp để tương tác với các phần tử mạng.

- Control node chịu trách nhiệm truyền đạt các trạng thái mức thấp đó tới các phần tử mạng và kết nối với các hệ thống khác một cách nhất quán.

- Analytics node chịu trách nhiệm thu thập dữ liệu từ các phần tử mạng và mô tả chúng vào một form thích hợp để lớp ứng dụng có thể sử dụng.

Bên cạnh vRouter đóng vai trò là các thiết bị chuyển mạch mềm được triển khai trên hypervisor của các máy chủ ảo đa chức năng, Tungsten Fabric có các giao diện giao tiếp giữa các lớp bao gồm:

- Northbound interface: REST API

- Southbound interface: XMPP, BGP, NETCONF

- East&West interface: BGP

2.2.2. Giải pháp của OpenDaylight (ODL)

OpenDaylight là một nền tảng SDN đã xuất hiện và khá thành công trong những năm 2010. OpenDayLight (ODL) là một nền tảng mô đun mở hỗ trợ việc cá nhân hóa và tự dộng hóa mạng ở nhiều kích cỡ. ODL tập trung vào khả năng lập trình mạng. ODL đến nay đã có 10 bản phát hành, là Open source SDN controller được sử dụng phổ biến nhất với một cộng đồng rộng khắp trên thế giới [10].

ODL code đã được liên kết và nhúng vào hơn 35 giải pháp và ứng dụng của các hãng như XNC của Cisco, SDN controller của ADVA…

Nền tảng ODL được xây dựng để cho phép người dùng, nhà cung cung cấp giải pháp có thể tự xây dựng Controller một cách linh hoạt nhất phụ thuộc vào nhu cầu của bản thân. ODL là nền tảng hỗ trợ nhiều giao thức nhất trong những nền tảng SDN như Openflow, OVSDB, NETCONF, BGP…

Với khả năng module hóa, ODL cho phép nhà phát triển và người dùng:

- Chỉ cần cài đặt giao thức và dịch vụ mong muốn.

- Có thể kết hợp nhiều giao thức và dịch vụ để có sự linh hoạt nhất.

- Tăng cường sự hợp tác phát triển nền tảng mã nguồn mở

- Nhanh chóng phát triển các tính năng cá nhân, gia tăng giá trị, tận dụng một nền tảng chung được chia sẻ

OpenDayLight hỗ trợ người dùng:

- Phân phối dịch vụ tự động: Cung cấp các dịch vụ on-demand được điều khiển bằng end user và service provider ví dụ như lên lịch băng thông, dịch vụ VPN tự động…

- Cloud và NFV: Phân phối dịch vụ trên hạ tầng Cloud nhanh chóng cho cả enterprise và service provider. Các thiết bị mạng Underlay và dịch vụ mạng có thể được triển khai bằng NFV.

- Tối ưu các nguồn lực mạng: Tự động tối ưu mạng dựa vào tải và các trạng thái cho phép tối ưu gần như thời gian thực cho lưu lượng, topo, thiết bị.

- Khả năng quan sát và điều khiển: Cho phép quản lý mạng tập trung qua giao diện trực quan.

Cộng đồng ODL cung cấp sự nâng cấp liên tục trong các vấn đề liên quan tới bảo mật, khả năng mở rộng, sự hoạt động ổn định và hiệu suất. OpenDayLight tuân theo kiến trúc chung của SDN (Hình 2.12):

Hình 2.12 - Kiến trúc OpenDayLight - Network Apps & Orchestration: Là lớp trên cùng của 5

Hình 2.12 - Kiến trúc OpenDayLight

- Network Apps & Orchestration: Là lớp trên cùng của giải pháp bao gồm các ứng dụng logic mạng và kinh doanh, cho phép việc điều khiển và giám sát hành vi mạng. Ngoài ra các ứng dụng có thể phối hợp với các giải pháp khác nếu cần để quản lý Cloud, các ứng dụng NFV.

- Controller Platform: Lớp thứ hai của giải pháp, nó cung cấp nhiều API phổ biến để giao tiếp với lớp ứng dụng/Orchestrator. Nó cũng có thể triển khai một hoặc nhiều giao thức cho việc điều khiển các thiết bị mạng vật lý. Bên trong Controller cũng chứa các module phục vụ việc quản lý, giám sát, cấu hình các thiết bị mạng.

- Physical & Virtual Network Devices: Là lớp cuối cùng của giải pháp ODL, bao gồm các thiết bị mạng vật lý và ảo hóa, switch, router… Chúng được điều khiển, cấu hình bởi SDN controller.

2.2.3. So sánh giải pháp của Tungsten Fabric (TF) và OpenDaylight (ODL)

Căn cứ vào kết quả nghiên cứu, tìm hiểu cũng như test thử nghiệm tính năng tại Lab (tham chiếu tại Phụ lục 1: Kết quả thử nghiệm tại Lab) có thể đưa ra một số nhận định đánh giá và so sánh ưu điểm/hạn chế của 2 giải pháp cơ bản như sau:

- Đánh giá Tungsten Fabric:

+ Tungsten Fabric hỗ trợ giao diện quản lý. Trên giao diện Web UI của Tungsten Fabric cung cấp đủ các tính năng giúp nhà vận hành giám sát quản lý, cấu hình chính sách, truy xuất thông tin về số lượng, hiệu năng, luồng traffic… của từng phần tử trong hệ thống. Tất cả các công việc vận hành hệ thống SDN đều có thể thực hiện trên giao diện Web UI.

+ Các tính năng Tungsten Fabric cung cấp trong quá trình thử nghiệm vận hành ổn định, không phát sinh lỗi hệ thống, đáp ứng được yêu cầu vận hành khi triển khai thực tế.

+ Trên thực tế, việc thử nghiệm chưa thể đánh giá hoàn chỉnh Testcase “SFC interwork với Firewall và Load balancer” do chưa đảm bảo được thiết bị hỗ trợ và tư vấn từ chuyên gia của hãng.

- Đánh giá OpenDayLight:

+ Về giao diện do trong cộng đồng không còn tổ chức nào đứng ra phát triển phần giao diện cho OpenDayLight (ODL) nên ODL hỗ trợ giao diện rất nghèo nàn và không thân thiện với người vận hành khai thác. Việc thao tác trên giao diện phức tạp và kết quả đem lại không mang nhiều giá trị. Ở các bản Release sau này ODL đã bỏ phần giao diện và sẽ không còn giao diện hỗ trợ việc vận hành nữa.

+ ODL cung cấp rất nhiều tính năng hữu ích, nhưng khi thử nghiệm hệ thống thường xuyên gặp lỗi có thể kể đến như là VM không nhận IP, mất IP, interface kết nối tới Router từ các network bị disable hàng loạt… không đảm bảo dịch vụ khi triển khai thực tế.

Kết luận: Sự lựa chọn giải pháp Tungsten Fabric để triển khai cho hạ tầng Cloud là phù hợp và tối ưu hơn so với giải pháp OpenDayLight, đây là quan điểm đánh giá có tính chất tham khảo quan trọng cho định hướng lựa chọn giải pháp chính thức đưa vào triển khai thực tế trong tương lai. Chi tiết quá trình phát triển và triển khai thí điểm giải pháp mã nguồn mở của Tungsten Fabric trên hạ tầng Cloud hiện có sẽ được trình bày chi tiết tại Chương 3 của luận văn.

CHƯƠNG 3: TRIỂN KHAI GIẢI PHÁP TỰ PHÁT TRIỂN

3.1. Mục tiêu triển khai

Qua 2 giai đoạn nghiên cứu, thử nghiệm SDN cho hạ tầng Cloud Data Center: Giai đoạn 1 nhằm tìm hiểu tính năng vai trò của SDN với sản phẩm SDN của Nokia (hệ thống Nuage) và Juniper (hệ thống Contrail); Giai đoạn 2 nhằm đánh giá tính năng, khả năng đáp ứng nhu cầu cho hệ thống Cloud Data Center của giải pháp SND mã nguồn mở Tungsten Fabric và OpenDaylight, nhóm dự án đã có góc nhìn khá toàn diện về giải pháp đối với mạng truyền tải trong Cloud Data Center và đi đến quyết định lựa chọn giải pháp mã nguồn mở Tungsten Fabric với những ưu điểm nổi trội và được cộng đồng hỗ trợ mạnh làm nền tảng để phát triển và triển khai thí điểm.

Mục tiêu giai đoạn này là đánh giá khả năng tích hợp SDN mã nguồn mở sử dụng nguồn Tungsten Fabric vào hệ thống Cloud Data Center; đánh giá các tính năng, mức độ hoàn thiện trong vận hành khai thác và khả năng hoạt động ổn định của hệ thống. Từ đó hoàn thiện sản phẩm và đưa vào triển khai ở quy mô lớn.

3.2. Phạm vi triển khai

Phạm vi triển khai là cụm Private Cloud cung cấp hạ tầng Cloud cho các đơn vị nội bộ Viettel chạy các ứng dụng ít quan trọng và các ứng dụng thử nghiệm. Cụm Cloud có quy mô: 81 Compute node, tổng số có 2552 CPU, 15 TB Ram, 244TB Storage, cung cấp hạ tầng cho khoảng 400 VM (máy ảo). Việc triển khai thí điểm SDN trên cụm Cloud này đảm bảo yêu cầu test tích hợp và vận hành trên hệ thống Cloud mang tải thật của Viettel đồng thời hạn chế ảnh hưởng trong trường hợp xảy ra sự cố không mong muốn.

3.3. Tổ chức triển khai

Quá trình triển khai được phân thành 4 giai đoạn:

- Khảo sát, quy hoạch đấu nối và lắp đặt bổ sung thiết bị.

- Cài đặt tích hợp SDN Controller.

- Đồng bộ tài nguyên.

- Cắt chuyển VM từ OpenStack sang hạ tầng SDN.

Ứng với mỗi giai đoạn sẽ có các yêu cầu đảm bảo cũng như các bước thực hiện sẽ được tác giả trình bày chi tiết trong từng phần sau:

3.3.1. Quy hoạch đấu nối và triển khai lắp đặt thiết bị

Sơ đồ lắp đặt thực hiện trên cụm Cloud có sẵn có quy mô triển khai như đã nêu tại mục trên (mục 3.2), để cung cấp tính năng VxLAN cho cụm Cloud, nhóm triển khai quay hoạch đấu nối và lắp đặt, tích hợp bổ sung 1 cặp Switch Leaf HP 5940 (Hình 3.1).

Hình 3.1 - Sơ đồ lắp đặt Quy hoạch đấu nối chi tiết: Cụm Cloud, thiết bị 6

Hình 3.1 - Sơ đồ lắp đặt

Quy hoạch đấu nối chi tiết: Cụm Cloud, thiết bị hiện tại và thiết bị lắp đặt bổ sung (1 cặp Switch Leaf HP 5940) được quy hoạch vị trí lắp đặt và đấu nối chi tiết tại Bảng

3.2. Cụ thể như sau:

STT

Switch

Port

Switch

Port

Location

1

HLC9205CLO UD.CR01

XGigabitE thernet1/1/

0/30

HLC9105IT.CLO UD.LEAF.01

Ten 1/0/48

SPHL07_RACK19

2

HLC9205CLO UD.CR02

XGigabitE thernet2/1/

0/30

HLC9105IT.CLO UD.LEAF.01

Ten 2/0/48

SPHL07_RACK19

3

HLC9205CLO UD.CR01

XGigabitE

thernet1/3/ 0/8

HLC9105IT.CLO UD.LEAF.02

Ten 1/0/47

SPHL07_RACK19

4

HLC9205CLO UD.CR02

XGigabitE thernet2/3/

0/8

HLC9105IT.CLO UD.LEAF.02

Ten 2/0/47

SPHL07_RACK19

5

HLC9105IT.CL OUD.LEAF.01

M-

GigabitEth ernet0/0/0

HLC102DCN.N3 K.AC05

Eth1/39

Bảng 3.1 - Quy hoạch đấu nối

3.3.2. Cài đặt, tích hợp SDN controller

3.3.2.1. Cài đặt, tích hợp SDN controller

Đối với các hạ tầng mới, việc cài đặt và tích hợp hệ thống SDN controller diễn ra song song trong quá trình cài đặt NFVI (Openstack, VMware...) Nhưng đối với Viettel, hệ thống Cloud đã tồn tại và đang vận hành. Để tích hợp SDN controller cần phải cắt chuyển các VM từ hạ tầng Cloud đơn thuần sang hạ tầng Cloud có cài đặt SDN controller (Hình 3.1).

Hình 3.2 - Mô hình cắt chuyển

Cụ thể như sau:

- Dồn dịch tài nguyên tạo ra các compute trống.

- Cài đặt SDN controller trên 1 compute trống riêng.

- Các compute trống còn lại cài đặt thành phần vRouter.

- Cắt chuyển VM từ hạ tầng cũ sang hạ tầng được quản lý bởi SDN controller.

3.3.2.2. Công cụ Skydive

Skydive là công cụ giám sát topology mã nguồn mở, công cụ này được nhóm dự án phát triển do nhu cầu giám sát hạ tầng Cloud Underlay và Overlay trên 1 giao diện duy nhất, với các tính năng chính như sau:

- Phát hiện và mô phỏng topo mạng chứa các thiết bị vật lý bao gồm các switch, máy chủ và các cổng mạng vật lý, cũng như các thiết bị ảo như các máy ảo, containers, các cổng mạng ảo và các liên kết vật lý cũng như các liên kết ảo giữa chúng.

- Giám sát trạng thái hoạt động của từng nút mạng, giám sát thông số lưu lượng thời gian thực đi qua từng liên kết mạng.

- Nhanh chóng phát hiện vị trí của các nút mạng dựa trên địa chỉ IP và đường đi (nếu có) giữa hai địa chỉ IP bất kỳ.

Công cụ Skydive được phát triển dựa trên sử dụng các ngôn ngữ Golang (phát triển thành phần Agents và Analyzers), ngôn ngữ TyperScript triển khai dưới dạng NGINX

web server (phát triển giao diện người dùng) và sử dụng cơ sở dữ liệu Elasticsearch (phát triển cơ sở dữ liệu đồ thị). Tất cả các dịch vụ nói trên đều được đóng gói trong các Docker containers và triển khai trên các máy chủ một cách tự động thông qua Ansible.

Skydive được thiết kế bao gồm bốn thành phần chính:

- Agents: Được triển khai trên các máy chủ vật lý, đảm nhiệm vai trò phát hiện và giám sát trạng thái của các thực thể hoạt động trên máy chủ, bao gồm các cổng mạng, các máy ảo và containers.

- Analyzers: Tổng hợp các thông tin phát hiện được bởi agent thành một đồ thị thống nhất thể hiện một cách tổng thể topo mạng. Analyzer còn thực hiện truy vấn thông tin từ những thực thể bên ngoài (các switch vật lý, các API giám sát v.v.) để làm giàu thông tin cho đồ thị.

- Cơ sở dữ liệu: Lưu trữ đồ thị dưới dạng các nút và liên kết cũng như metadata tương ứng cho từng nút và liên kết.

- Giao diện người dùng web: Trực quan hóa topo mạng trên một giao diện người dùng thống nhất.

Việc sử dụng Skydive khá đơn giản, người sử dụng chỉ cần mở giao diện web đăng nhập tài khoản, mật khẩu (truy nhập OpenStack trước đó), sau đó có thể xem các thông số trạng thái hoặc vào các nút mạng để mở rộng để quan sát các thành phần con.

3.3.3. Đồng bộ tài nguyên

Giai đoạn đồng bộ tài nguyên được thực hiện với mục đích đảm bảo các tài nguyên mạng bên OpenStack được đồng bộ sang Tungsten Fabric và thực hiện chạy dữ liệu một lần.

Khi chuyển dịch từ hạ tầng Cloud cũ sang hạ tầng Cloud sử dụng SDN controller, do trong thông tin của SDN controller là Tungsten Fabric chưa có các thông tin về network của hạ tầng Cloud cũ nên những tài nguyên liên quan đến server như network, subnet, port, security group cần được đồng bộ sang SDN controller. Quá trình đồng bộ phải đảm bảo triển khai được cho tất cả các server đang chạy trên cụm hạ tầng cloud thực nghiệm, bao gồm server Ubuntu, CentOS và Windows.

Để đảm bảo cắt chuyển một server thành công, cần đảm bảo những điều kiện các tài nguyên liên quan đến server như network, subnet, port, security group phải được đồng bộ sang Tungsten Fabric SDN controller.

Có 5 bước thực hiện đồng bộ tài nguyên được thực hiện lần lượt như sau:

- Bước 1: Login vào server và vào quyền root.

- Bước 2: Run container convert-script để convert các tài nguyên network.

- Bước 3: Chuyển đến thư mục tf-script và cập nhật code mới nhất

- Bước 4: Chỉnh sửa thông tin authentication

- Bước 5: Thực hiện convert các tài nguyên mạng từ OpenStack sang TF.

3.3.4. Triển khai cắt chuyển VM sang hạ tầng SDN

Quá trình cắt chuyển VM sang hạ tầng SDN được thực hiện qua 5 bước (Hình 3.2). Cụ thể như sau:

- Bước 1: Kiểm tra tình trạng hoạt động của VM, đơn vị quản lý vận hành VM.

- Bước 2: Chạy tool đồng bộ, trích suất thông tin từ OpenStack sang SDN controller.

- Bước 3: Thực hiện cắt chuyển VM sang hạ tầng SDN, sau khi cắt chuyển kiểm tra theo các Checklist.

- Bước 4: Liên hệ đơn vị đang quản lý VM, phối hợp kiểm tra hoạt động của VM sau khi cắt chuyển.

- Bước 5: Nếu các dịch vụ chạy trên VM hoạt động bình thường thì hoàn thành. Trong trường hợp xảy ra bất cứ lỗi hay hiệu năng không đạt sẽ thực hiện Roll Back lại hạ tầng cũ.

Hình 3.3 – Các bước cắt chuyển 3.4. Kết quả triển khai 3.4.1. Triển khai hệ 7

Hình 3.3 – Các bước cắt chuyển

3.4. Kết quả triển khai

3.4.1. Triển khai hệ thống

- Lắp đặt, cấu hình và tích hợp cặp Switch Leaf HP 5940 vào hạ tầng cụm vCloud hiện hữu, hệ thống phần cứng tương thích, hoạt động ổn định.

- Dồn dịch tài nguyên và cài đặt SDN controller trong cụm vCloud thành công, cài đặt Plugin trên OpenStack controller kết nối được 2 hệ thống OpenStack và SDN.

- Nhóm dự án đã phát triển được công cụ Skydive cho phép giám sát hạ tầng Cloud Underlay và Overlay trên 1 giao diện duy nhất.

3.4.2. Kiểm tra tính năng, test dịch vụ và đảm bảo điều kiện đổ tải

- Thực hiện được các testcase đánh giá tính năng của hệ thống SDN.

- Test khả năng Live migrate các máy ảo sang hạ tầng quản lý bởi SDN. Các VM hoạt động bình thường sau khi cắt chuyển.

- Phát triển công cụ Network Resource Synchronization Tool cho phép tự động đồng bộ tài nguyên sang SDN trước khi cắt chuyển máy ảo, công cụ cho phép migrate tài nguyên của 1 Network trong khoảng 5 phút thay vì 1 ngày theo cách làm thủ công.

- Xây dựng kịch bản cắt chuyển và Rollback khi có sự cố.

3.4.3. Tích hợp, đổ tải và đánh giá

- Tích hợp SDN controller vào Cloud của Viettel thành công.

- Cắt chuyển 80/80 máy ảo mang tải thật để đánh giá hoạt động của hệ thống và các máy ảo sau khi cắt chuyển.

- Sau khi triển khai, công cụ Skydive cho phép giám sát các kết nối của thiết bị Switch, Server, máy ảo trong cụm Cloud, giúp việc giám sát trở nên thuận tiện hơn (Hình 3.3).

Hình 3.4 - Giám sát bằng công cụ Skydive Việc triển khai, tích hợp giải pháp SDN 8

Hình 3.4 - Giám sát bằng công cụ Skydive

Việc triển khai, tích hợp giải pháp SDN do đội dự án tự phát triển vào hạ tầng Cloud của Viettel không gây ảnh hưởng đến công tác vận hành và hoạt động của các VM đang chạy.

3.5. Đánh giá hệ thống sau khi tích hợp SDN Controller.

Kết quả đánh giá tính năng hệ thống trước và sau khi tích hợp SDN controller được tóm tắt qua Bảng 3.3, cụ thể như sau:

STT

Tiêu chí

Truyền thống

SDN controller

1

Đáp ứng các tính năng về quản lý, cấp phát tài nguyên trên Cloud

Download pdf, tải về file docx
Ngày đăng: 15/04/2022
Đánh giá:
4.3/5 (1 bình chọn)

Bài viết tương tự

Gửi tin nhắn

Danh mục

Bài viết tương tự

Xem nhiều

Bài viết mới

Home | Contact | About | Terms | Privacy policy
© 2022 Tailieuthamkhao.com | all rights reserved

Trang chủ Tài liệu miễn phí Thư viện số
Top