Đánh giá hiệu năng mạng trên điện toán đám mây OpenStack
Tóm tăt
Điện toán đám mây đã bắt đầu pho biến nhờ tính linh hoạt, có khả năng mở rộng, dễ dàng kích hoạt và cung cấp các dịch vụ để xây dựng tài nguyên mà khách hàng có tte truy dip theo yêu cầu của họ. Ngoài ra dịch vụ điện toán đám mây có khả năng chia sẻ tài nguyên hiệu quả giữa các người dùng với nhau. OpenStack, một nền t.ảng điện toán đám mây mã nguồn mở tưorng đối mới, tập trung vào việc cung dip mạng như một dịch vụ (NaaS) sử dụng công nghệ ảo hóa và OpenStack hứa ten là một nền tảng điện toán đám mây sẽ được mở rộng O ạt trong các ứng dụng của doanh nghiệp. Từ đó, mục đích của bài báo là nghiên cứu hiệu năng mạng của OpenStack triển khai trên phiên bản Neutron. Các thông số về hiệu táng như thông lượng, vẩn đề mất gói tin, thời gian trễ gói tin sẽ được đánh giá theo giao thức UDP dựa vào công cụ IPERF.
Tóm tắt nội dung tài liệu: Đánh giá hiệu năng mạng trên điện toán đám mây OpenStack
ĐÁNH GIÁ HIỆU NĂNG MẠNG TRÊN ĐIỆN TOÁN ĐÁM MÂY OPENSTACK Võ Nhân Vâna, Lê Minh Chíb, Nguyễn Quốc Longa, Lê Đắc Nhườngc “Khoa Công nghệ Thông tin, Trường Đại học Duy Tân, Đà Nang, Việt Nam bSỞ thông tin và Truyền thông Đà Nang, Việt Nam cKhoa Công nghệ Thông tin,Tmmg Đại học Hải Phòng, Hải Phòng, Việt Nam Nhận ngày 04 tháng 01 năm 2016 Chỉnh sửa ngày 19 tháng 03 năm 2016 I Chấp nhrn đăng ngày 31 tháng 03 năm 2016 Tóm tăt Điện toán đám mây đã bắt đầu pho biến nhờ tính linh hoạt, có khả năng mở rộng, dễ dàng kích hoạt và cung cấp các dịch vụ để xây dựng tài nguyên mà khách hàng có tte truy dip theo yêu cầu của họ. Ngoài ra dịch vụ điện toán đám mây có khả năng chia sẻ tài nguyên hiệu quả giữa các người dùng với nhau. OpenStack, một nền t.ảng điện toán đám mây mã nguồn mở tưorng đối mới, tập trung vào việc cung dip mạng như một dịch vụ (NaaS) sử dụng công nghệ ảo hóa và OpenStack hứa ten là một nền tảng điện toán đám mây sẽ được mở rộng O ạt trong các ứng dụng của doanh nghiệp. Từ đó, mục đích của bài báo là nghiên cứu hiệu năng mạng của OpenStack triển khai trên phiên bản Neutron. Các thông số về hiệu táng như thông lượng, vẩn đề mất gói tin, thời gian trễ gói tin sẽ được đánh giá theo giao thức UDP dựa vào công cụ IPERF. Từ khóa: Điện toán đám mây; Hiệu năng mạng; OpenStack. GIỚI TIIIỆU CHUNG Điện toán đám mây là một vấn đề nóng hiện nay và các nhà nghiên cứu đã đưa ra nhicu ý tưởng trong lĩnh vực này. Cho đen nay có rất nhiều công nghẹ được sử dụng cho điện toán đám mây, một trong số đó là EC2, OpenStack, OpenNebula, Clouds tack... Điện toán đám mây cung cấp một số dịch vụ như laaS (Infrastructure as a Service), PaaS (Platform as a Service), DaaS (Data as a Service) và SaaS (Software as a Service). Do nhu cầu của điện toán đám mây phát triển rất nhanh chóng, hiệu quả tất, đủ đe đáp ứng nhu cầu cho người sử dụng. Tuy nhiên, một trong những râi quan tâm quan trong nhất của diện toán dám mây là phải đạt một hiệu suất mạng tốt, rn:u không thì Tác giả liên hệ: Email: nhuongld@hus.edu.vn không thể tạo được một hệ thống mạng chất lượng. Do đó, bài báo này tập trung phân tích đánh giá hiệu năng điện toán đám mây dựa trên OpenStack. Điện toán đám mây Điện toán đám mây có thể được định nghĩa [1] là một kiểu máy tính mới trong đó các nguồn lực có thể được mở rông một cách tự động và thông thường được ảo hóa để cung cấp như một dịch vụ trên Internet. Điện toán đám mây đã và đang trở thành một xu hướng công nghệ trong veil và nhiều chuyên gia mong đợi rằng điện toán đám mây thay đổi hình dáng của các quy trình và thị trường của công nghệ thông tin. VỚI công nghệ điện toán đám mây hiện nay, người dùng sử dụng một loạt thiết bị như máy tính, máy tính xách tay, điện thoại PDA để truy cập các chương trình, hệ thống lưu trữ hay các nen tảng phát triển hệ thong thông qua Internet tói các ứng dụng được cung cấp bởi các nhà cung cấp dịch vụ điện toán đám mây. Ưu điểm của công nghẹ này là ti Ct kkm chi phí, tính san sàng cao và khả năng mở rông dễ dàng. Các tính năng chính [2]: Rapid elasticity: nhà cung cấp CC dễ dàng chỉ định cũng như thu hồi tài nguyên người dùng rất nhanh chóng. V phía người dùng được phép yêu cầu mt tài nguyên “không giới hạn” và chỉ việc chi trả theo tron. Broad network access: truy cập vào các tài nguyên máy tính dễ dàng thông qua các cơ chế network tiêu chuẩn. Measured service: provider đảm bảo việc tính toán lượng tiêu dùng của khách hàng. Mô hình hướng đến là “pay as you go”. On-demand self-service: cho phép khách hàng tùy chỉnh tài nguyên sử dụng mà không cần phải thông báo hay qua bít ty sự can throp nào của provider. Resource pooling: các loại tài nguyên vật lý và ảo của cc được chia sẻ với nhau và tự động cấp cho các users. Các mô hình triến khai Có 3 mô hình triển khai diện toán đám mây chính là public (công cộng), private (riêng), và hybrid (“lai” giữa dám mây công cộng và riêng). Đám mây công cộng là mô hình đám mây mà trên đó, các nhà cung cấp đám mây cung cấp các dịch vụ như tài nguyên, platform, hay các ứng dụng lưu trữ trên đám mây và public ra bên ngoài. Các dịch vụ trên public cloud có the miễn phí hoặc có phí [3]. Đám mây riêng thì các dịch vt được cung cấp nội bộ và thường là các dịch vụ kinh doanh, me đích nhắm đen cung cấp dịch vụ cho một nhóm người và đứng đằng sau firewall. Đám mây “lai” là môi trường đám mây mà kết hợp cung cấp các dịch vụ công cộng và riêng [3]. Ngoài ra còn có “community cloud” là đám mây giữa các nhà cung cấp dịch vụ đám mây. Các mô hình dịch w: Ve mô hình cung cấp dịch vụ có 3 loại chính là laaS - cung cấp hạ tầng như một server, PaaS - cung cấp Platform như một service, và SaaS - cung cap software như một service. OpenStack “Sứ mạng của OpenStack: Cung cấp tang điện toán đám mây mã nguồn mở phổ biến để đáp ứng được nhu cầu của bất kể kích cỡ đám mây công cộng hay đám mây riêng, bằng cách đơn giản hóa việc tricn khai và khả năng mở rông cao”. [4] Đúng như sứ mạng trên, OpenStack là một hệ thống quản lý đám mây, điều khiển lượng lớn các tài nguyên tính toán, lưu trữ và mng nằm trong một trung tâm dữ liệu. Tất d. các thao tác quản lý được thực thi thông qua một bảng điều khiển nhằm cung cấp cho quản trị viên khả năng kiểm soát hệ thống và cho phép người dùng tương tác mi tài nguyên mà họ cần thông qua giao diện web. Openstack hoàn toàn là nguồn mở, các thành phần của nó được viết trên Python - ngôn ngĩ đang được đánh giá rất cao những năm gần đây. Sau đây là sơ đồ kiến trúc ở mức logic của Openstack [5] (Hình 1): Dashboard Identity Hình 1. Các thành phần cơ bản trong OpenStack Trong đó: • Dashboard (tên mã Horizon): Cung cấp giao diện điều khiển dưới dạng web, cho phép người dùng tương tác với các dịch vụ của OpenStack để khởi tạo một máy ảo, gán địa chỉ IP, thiết lập kiểm soát truy cập... Compute (tên mã Nova): Cung cấp việc xây dựng và quản lý các máy ảo Networking (tên mã Neutron): Cung cấp kết nối mạng giữa các máy ảo, giữa máy ảo và Internet. Object Storage (tên mã swift): Cung cấp dịch vụ lưu trữ file. Block Storage (tên mã Cinder): Cung cấp thành phần lưu trữ dự phòng cho các máy ảo, tương tự USB, HDD di động,... Identity (tên mã Keystone): Cung cấp dịch vụ chứng thực và ủy quyền cho các dịch vụ khác trong OpenStack. Image (tên mã glance): Cung cấp các file chứa hệ điều hành dành cho các máy ảo. Metering/Monitoring (tên mã Ceilometer): Quản lý và thống kê các thông S) thay đổi trong quá trình hoạt động. Orchestration (tên mã Heat): Cung cấp khả năng xây dựng tự động các dịch vụ như web server, firewall,... cho máy ảo; Điều phối các hoạt động cho đám mây. Database Service (tên mã trove): Cung cấp khả năng mở rông và tin cậy của chức năng Cloud Database as a Service cho ỎL hai công cụ cơ sở dữ lựìu tin tưởng và không tin tưởng. Kết nối mạng trong OpenStack OpenStack Networking cung cấp một lượng API phong phú để quản lý kết nối và xác định kết nối trong tel tang cloud. Nó hỗ trợ nhiều công nghệ mạng khác nhau để kết nối vào tel tầng cloud. Chúng ta sẽ tìm hiểu về mô hình trien khai phần Network, và một số dịch vụ cơ bản của network cung cấp cho tel tầng cloud. Neutron bao gom các tài nguyên t^rn tượng là Network, Subnet, Port. Network: quản lý cô lập mạng ở Layer 2, giong VLAN trong mng vật lý. Subnet: nhóm địa chỉ IP v4/v6 được phân cấp và cấu hình cho thống. Port: một port MĨ được gán với một thiết bị ảo trong tel tầng. Người dùng có thể tạo ra mô hình mạng riêng của mình, bằng cách tạo ra Network và subnet và sau đó hướng dẫn cho các dịch vụ của khác, như Compute để nó có the gán thiết bị ảo đến port trên network đó. Đặc biệt là Neutron cho phép tạo ra mng riêng (Private network) và gán cho các tenant, một tenant có thể có nhiều private network và các private network có thể trùng nhau cho mỗi tenant. Các dịch vụ của Neutron cung cấp bao gồm: Tạo ra một topology riêng cho thống của riêng mình. Ví dụ như tạo ra hệ thống webserver nhiều tầng, để backup hoặc cân bằng tài. Cung cấp sự linh hoạt trong quản tri hạ tang mng, cho phép tùy cMnh hạ tầng cao. Cung cap API mở rông, cho phép phát triển và tích hợp Neutron vào nhiều hệ thống khác nhau. Neutron hỗ trợ nhiều công nghệ mạng khác nhau để tạo ra nhiều chức năng hom, ngoài việc chia VLAN, Subnet, còn có the làm switch ảo qua công nghệ của vSwitch, các chức năng khác như Firewall, DHCP, VPN, Load balancing. MÔ HÌNH TIIỤC NGHIỆM Dịch vụ điện toán đám mây sẽ cung cấp các máy ảo với VCPU, RAM, khả năng lưu trữ khác nhau. Trong OpenStack, các thành phần liên quan đen mng và chuyển mạch cũng được ảo hóa thông qua Neutron. Neutron - phần mềm để định nghĩa các chức năng của một hệ thống mạng, tà lớp 2 cho đến lớp 3, từ switch cho đến router và gán vào hoạt động của các instances. Việc truyền thông của các máy ảo trong OpenStack sẽ không giống nhu việc truyền dẫn trên các hệ thống mạng thông thường vì các thành phần ota mạng được định hướng theo mô hình SDN (Software Define Network). Trong OpenStack, việc triển khai Neutron được hướng đến theo 2 hình thức: sử dụng GRE tunnel hoặc theo mô hình VLAN. GRE tunnel vói ưu thế linh hoạt và dễ cấu hình tuy nhiên hiệu suất thấp, mô hình VLAN có nhiều ưu điểm trong việc triển khai các hệ thống lớn tuy nhiên cần đòi tói số lượng thhbt bị, các thiết kế và cấu hình cao hơn. Đe phục vụ cho mục dích thử nghiệm, mô hình GRE tunnel được sử dụng để hạn chc việc triển khai phức tạp đối với hạ tầng vật lý. Do đó, mô hình thử nghiệm sử dụng GRE tunnel được thực hiện trong 4 kịch bản nhằm mục dích nghiên cứu hiệu suất mạng về thông lượng, thời gian trễ và vấn đe mt gói tin UDP giữa các máy ảo. Trong bài báo này chúng tôi đưa ra 4 kịch bản thử nghiệm như sau: case 1 - Cùng mạng cùng compute node, case 2 - Khác mng cùng compute node, case 3- Cùng rang khác compute node, case 4 - Khác rang khác compute node. Bởi vì Network trong OpenStack được xem như là một tài nguyên và được ảo hóa toàn bộ để hướng đến việc thao tác và quản trị đom giản. Ve lý thuyết, hoạt động của hệ thong network “ảo hóa” này không khác gì so với hệ thong network ^t lý. Trong OpenStack cũng hình thành nên các port ảo tương đương với các kết nối vật lý giữa các thiết bị, các router ảo tương đương với việc phân chia các dải rang với nhau, các khái niệm như VLAN hoặc access control list, ... cũng được thể hiện tương tự. Vì vậy đe đánh giá hoạt động của lớp ảo hóa Network này thì cân đánh giá dựa trên các tiêu chí sau: - Xem xét việc tót nối rang trong hệ thong network ảo tại các máy compute node - Xem xét việc kết nối rang trong hệ thong network ảo giữa các máy compute node với nhau. Từ kết quả đánh giá đó (chính là 4 test cases được thực hiện) mới xem xét đen việc sử dụng OpenStack Network trong thực tề có bảo đảm được như các mô hình network vật lý thông thường. Hình 2. Mô hình triển khai Mô hình triến khai trên hệ thống 3 máy chủ, bao gồm: 01 máy chủ làm Controller và Network, chạy các dịch vụ quản trị Controller của OpenStack như Keystone, MySQL, Neutron, Cinder, và các dịch vụ liên quan khác. 02 máy chủ làm Conpute nodes cài đặt Neutron L2 Agent và rn:n tảng ảo hóa Hypervisor KVM cho việc cung cấp năng lực tính toán dành cho các máy chủ ảo. 153 TẠP CHÍ KHOA Il(.)C ĐẠI HỌC DÀ LẠT [ĐẶC SAN CÔNG NGHỆ THÔNG TIN] Hệ thong mạng của mô hình triển khai bao gồm 4 mạng như sau: Public và Floating IP (trong mô hình là VM Network): 10.196.205.0/24 Management network: 10.196.202.0/24 Storage network: 10.196.203.0/24. Trong mô hình trển khai Storage network nằm chung tót nối vật lý với Management Network. Storage network không nằm trong giới hạn nghiên cứu của bài báo. Internal Network - network dành riêng cho các tenants: 192.168.111.0/24 và 192.168.112.0/24 Ngoài ra còn có 1 mạng PXE phục vụ cho việc quản trị và cài đặt tự động các máy chủ trong hệ thong. Case 1. Mô hình thử nghiệm này thực hiện nhằm nghiên cứu thông lượng, độ trễ, tí lệ mt gói tin UDP giữa hai máy ảo cùng node compute và cùng mạng. Project Host Name Image Name IP Address Size Status Task Power State Time since created Actions ũ admin node-18 IPERF-1b98e6ce-6241- 424c-a874-d672c4a56089 Ubuntu 14 04-64 192 168111 9 10 196 206 133 ml small Active None Running 5 hours. 37 minutes Edit Instance • admin node-18 lPERF-ce99898t>e8l7- 476d-8dbb-db654bf5050t Ubuntu 14 04-64 192 168 111 10 10 196 205 134 ml small Active None Running 5 hours 37 minutes Edit Instance • Osc*-,r>2 2 lem Hình 3. Case 1 được thực hiện vói 2 máy ảo VM1 và VM2 được đặt cùng mạng 192.168.111.0/24 và cùng node 18 Case 2. Mô hình thử nghiệm này thực hiện nhằm nghiên c^ thông lượng, thời gian tre và tí lệ mất gói tin UDP giữa hai máy ảo có cùng node compute nhưng nằm ở hai mng khác nhau. Hai mng khác nhau có thể nằm trên cùng một router hoặc hai router khác nhau. admin node-18 IPERF-3 Ubuntu 14 04-64 192 168112 103 10 196 205 135 m'5ma" Active None Running 6 minutes Edit Instance • admin node-18 lPERF-1b98e6ce-6241- 424c-a874- d672c4a56089 Ubuntu14 04-64 1921681119 10196205133 m1 sma" Active None Running 7 hours 29 minutes Edit Instance • admin node-18 IPERF<e99898b-e817- 476d-8dbb-db654tf505ơ Ubuntu14 04-64 192 168 111 10 10 196 205 134 m,snuil Active None Running 7 hours 29 minutes Edit Instance Hình 4. Case 2 được thực hiện với 2 máy ăo cùng chung 1 node 18 nhưng khác mạng VH nhau (192.168.111.9/24 và 192.168.112.103/24) Case 3. Mô hình thử nghiệm này thực hiện nhằm nghiên cứu thông lượng, thời gian tre và tí lệ mất gói tin UDP giữa hai máy ảo có node compute khác nhau nhưng cùng một mạng với nhau. Project Host Name Image Name IP Address Size . Power Time Status Task r since s"" created Actions Edit Instance * Edit Instance • , IPERF-1b98e6ce-6241- . n. c. 192 168 111 9 ... _ .. Q 5 hours admin node-18 Ubuntu 14 04 64 ___ I mismail Active None Running ■ 424c-a874-d672c4a56089 - 10 196 206 133 51 minutes . IPERF-ce99898b-e8l7- n. CÃ 192 168111 10 . ~ .. D 5 hours adm,n ~*-17 476rM«Z*654M5O5Of Ubun,u14 °4-64 10 196 205 134 sma" A£"ve Rumn9 51minutes Hình 5. Case 3 được thục hiện với 2 máy ảo cùng chung 1 mạng (192.168.111.0/24) nhưng ở 2 node khác nhau (node 17 và node 18) Case 4. Mô hình thử nghiệm này sẽ thực hiện nhằm nghiên cứu thông lượng, thời gian tre, tì lệ mt gói tin UDP giữa hai máy ảo có node compute khác nhau và khác mạng với nhau. Hình 6. Case 4 được thực hiện với 2 máy ảo khác mạng (192.168.112.103 và 192.168.111.10) cũng như khác node nhau (node 17 và node 18) PHÂN TÍCH VÀ ĐÁNH GIÁ Dịch vụ network trong OpenStack chính là Neutron, và Neutron tạo ra các môi trường chuyển mạch (switch), định tuyến (router) thông qua các dịch vụ Neutron L2 Agent, Neutron L3 Agent. Các mô hình thử nghiệm về mạng được mô tà ở trên do module Neutron trong OpenStack tạo ra. Kết quả thử nghiệm tập trung vào việc phân tích các tham số liên quan đến việc truyền nhận gói tin trong thống các máy ảo của OpenStack, các thông S5 được phân tích bao gồm thông lượng, tí lệ mất gói tin trên đường truyền, và thời gian tre của gói tin. 3.1. Thông lưọìig TCP Hình 7a cho thấy giá trị của TCP được thu thập moi 5s một lần trong vòng 5 phút. Từ sơ đồ này cho ta thấy các thông lượng của máy ảo trên cùng một node compute và cùng địa chỉ mạng thì dao động xung quanh giá tri 890Mbps, trong khi các máy ảo trên cùng một node compute nhưng khác địa chỉ mng khoảng 500Mbps. Hình 7a. Thông lưọng TCP trong 4 trường hợp Từ sơ đồ Hình 7b ta có thể thấy thông lượng cho các máy ảo trên cùng mt node compute và cùng địa chỉ mạng là cao hơn nhiều so với các trường hợp còn lại. Điều này lý giải là do khi 1 máy khác địa chỉ mng thì thông lượng cần phải được gii tói Router do OpenStack tạo ra. Hình 7b. truo'ng hợp 3.2. Thông lưọìig và tì lệ mất gói tin UDP Để đo lường thông lượng, thời gian trễ và tì lệ mất gói tm UCP, IPERF được thực thi trong vòng 5 phút và dr liệu sẽ được lay định ty mỗi 5 giây 1 lần. Trong khi dữ liệu được lấy ở một mô hình thì các mô hình thử nghiêm khác sẽ bị dùng lại. Từ những kết quả trong Hình 8 và Hình 9, có thể nhận thấy rằng khi 2 máy ảo được đặt trên cùng node và cùng mạng, chúng thực hiện tốt hơn so với khi chúng ở các node và mạng trong các trường hợp khác. Việc đo lường cho thấy các máy ảo trên cùng node, cùng mạng thì đạt được thông lượng trung bình Xip ả 4.2% so với các trường hợp còn lại. Hình 8. Thông lượng UDP trong 4 case Hình 9. Tỉ lệ mất gói tin UDP trong 4 case Tương tự trong trường liợp đo lường tí lệ mt gói tin thì các máy ảo ở cùng node nhưng khác mạng hoặc khác node và khác mạng thì có thông M cao hơn so với các máy ảo cùng node và cùng mạng. Đặc biệt trong trường top các máy ảo cùng node nhưng khác mạng cho chúng ta thay tí lệ mt gói tin Xip ả 40% so với trường hợp đặt các máy ảo cùng node và cùng mng. Thòi gian trễ Trong trường hợp do lường thời gian tre gói tin, ta nhận thấy giá trị ở case 1 thấp hơn giá trị ở case 2 và giá trị ở case 3 thấp hơn giá trị ở case 4. Điều này cho chúng ta tot luận các máy ảo trên khác địa chỉ mng có giá trị cao hơn so với các máy ảo có cùng địa chỉ mạng. Kết quả này là bình thường vì khi máy ảo khác mng nhau thì lưu lượng đi từ nguồn tới đích phải thông qua nhiều hop hơn khi chúng cùng mạng toi nhau. Mô hình thử nghiệm thường toa trên các con số lý tưởng khi các thiết bị cũng như đường truyền không bị ảnh hưởng toi các tham số tác động bên ngoài. Hệ thống các test cases cũng được xây dựng trên môi trường như vậy. Một đặc điểm quan trọng toa việc kiểm tra thông lượng thường tập trung vào các gói tin UDP để đánh giá. Vì toy nên mô hình thử nghiệm cũng căn cứ trên các cơ sở đó để thực hiện. Trong thực te, các nút mng cũng như máy chủ rè chịu một tải nhất định do ảnh hưởng toa môi trường xung quanh, vì toy nên giá trị thu nhận được trong môi trường LAB to khác biệt so toi thực tế và cần phải được kiểm chtog đối toi từng trường top to thể, ví dụ trong môi trường data center toa FTP, hoặc data center toa VNPT, ... Tuy nhiên bài báo ch giới ton trong toi dung môi trường LAB to chưa đánh giá ảnh hưởng toa môi trường thực te. Vì thực hiện trong môi trường LAB nên số lượng máy chủ như vậy thì có the too đảm cho việc thu thập các thông to kiếm tra và phân tích. Thực tế hệ thong to lớn hơn nhiều, có thể lên đến hàng trăm máy chủ và việc đánh giá phải được thực hiện trên diện rộng hơn, nằm ngoài phạm vi của bài báo. KẾT LUÂN Điện toán đám mây mã nguồn m và đặc biệt là OpenStack hiện nay là một trong những công nghệ được lựa chọn để triển khai cho các công ty trên toàn the giới. Trong bài báo này, chúng tôi phân tích và đánh giá hiệu năng mạng dựa trên các thông số thông lượng UDP, thời gian tre, tỉ lệ mất gói tin trên OpenStack. Từ đó đưa ra kết luận OpcnStack Neutron đảm bảo một hiệu suất cao, băng thông hầu như không bị hiện tượng thắt dỉ chai. Ngoài ra, kết quả cũng cho thấy rang, vị trí da máy ảo cũng như địa chỉ mạng ảnh hưởng đến hiệu suất, cụ thế các máy ảo cùng node và cùng ọng rê cho hiệu năng cao hơn tất cả các trường hợp còn lại tói vì đường truyền da các máy ảo ngắn hơn. Tuy nhiên, chúng tôi chỉ mới nghiên du gói tin UDP trong mô hình nhỏ, can mở rộng để cho kết quả và kết luận tốt hơn. Trong thời gian tói, chúng tôi sẽ đo lường các thông số hiệu năng về nhiều loại gói tin (TCP, UDP) di mô hình lớn và nhiều trường hợp hơn để cho kết quả tin cậy cao. TÀI LIỆU THAM K^O Borko Furht, Armando Escalante, Handbook of Cloud Computing, Springer, (2010). P., M. and T. Grance., The NIST Definition of Cloud Computing, (2011). Sabahi, F. Cloud computing security threats and responses in Communication Software and Networks (ICCSN), 2011 IEEE 3rd International Conference on. (2011). Vo Nhan Van, Le Minh Chi, Nguyen Quoc Long, Nguyen Gia Nhu, and Dac- Nhuong Le, A Performance Analysis of OpenStack Open-source Solution for IaaS Cloud Computing, in proceeding of International Conference on Computer and Communication Technologies (IC3T 2015), Advances in Intelligent Systems and Computing Vol.380,pp.141-150 Springer. (2015) https://wiki.openstack.org/wiki/Main_Page NETWORK VIRTUALIZATION PERFORMANCE ANALYSIS ON OPENSTACK CLOUD COMPUTING INFRASTRUCTURES Vo Nhan Vana, Le Minh Chib, Nguyen Quoc Longa, Le Dac Nhuongc aThe Faculty of Information Technology, Duytan University, Danang, Vietnam bDanang ICT Infrastructure Development Center, Danang, Vietnam cThe Faculty of Information Technology, Haiphong University, Haiphong, Vietnam Corresponding author: nhuongld@hus.edu.vn Article history Received: January 04th, 2016 Received in revised form: March 19th, 2016 Accepted: March 31st, 2016 Abstract Cloud computing has become popular in IT technology because of its advantages that focus on flexible, scaling, resources and services which help customers easy to build their own on-demand IT system easily. Moreover, Cloud computing also can assist users to balance, share, and manage IT resources among customers to get better performance of compute and storage. OpenStack, a new open source cloud computing framework which was a built- in modular architecture and focused on IaaS. OpenStack also focuses on NaaS by using network virtualization technology with native opensource intergrated solution - openvswitch and supports other commercial solutions from vendors. OpenStack nowadays has been popularly in business. This paper does a research on network performance on OpenStack network module code named Neutron. The parameters in virtualization network of OpenStack related to network performance such as throughput, package loss, time and delay of data transmission are estimated through UDP protocol using IPERF benchmarking tool. Our research investigated the possible internal traffic flow patterns and evaluated network performance of each pattern on OpenStack cloud computing environment. Keywords: Cloud computing; Network performance; Openstack.
File đính kèm:
- danh_gia_hieu_nang_mang_tren_dien_toan_dam_may_openstack.doc
- danh_gia_hieu_nang_mang_tren_dien_toan_dam_may_openstack_944_483364.pdf