trợ trong mạng trung tâm dữ liệu
Đảm bảo cung cấp QoS là một nhiệm vụ quan trọng trong các trung tâm dữ liệu đám mây (Cloud data centers), đặc biệt cho các luồng TCP khi TCP mang tới 99,9% lưu lượng trong các trung tâm dữ liệu. Các ứng dụng chạy ở các trung tâm
dữ liệu chỉ có thể đạt hiệu năng mong muốn nếu tài nguyên, băng thông mạng được đảm bảo cùng với các nguồn tài nguyên lưu trữ và tính toán.
SDN và các trung tâm dữ liệu
Các nhà cung cấp dịch vụ điện toán đám mây mong đợi nhiều phiên bản của trung tâm dữ liệu ảo (VDCs- virtual data centers) tới khách hàng. Cùng với đa VDCs trong một trung tâm dữ liệu dẫn tới nhiệm vụ đầy thách thức trong quản lý tự động mạng (như khách hàng vào hay rời khỏi hoặc nhu cầu về thay đổi dung lượng. Hơn nữa, sự di trú của các hệ thống bộ nhớ ảo ở một server đến một server khác, công cụ chung trong các trung tâm dữ liệu, kích hoạt các công cụ như tính toán lại đường dẫn, tái phân bổ băng thông trên các đường bị ảnh hưởng… Đó là nội dung mà SDN dự kiến giúp đỡ trong việc dễ dàng quản lý và điều khiển một trung tâm dữ liệu mạng, ở đó SDN cho phép các chuyển mạch có thể điều khiển bằng một hoặc nhiều bộ điều khiển tự động thích ứng với yêu cầu của mạng trung tâm dữ liệu. Trong khi các giải pháp đảm bảo QoS trong mạng được xem như một đề tài nghiên cứu mạnh mẽ trong thập kỷ vừa qua. Việc nghiên cứu khả năng của kiến trúc SDN giúp đảm bảo cung cấp QoS trong các trung tâm dữ liệu. Đặc biệt việc sử dụng chuẩn hóa OpenFlow cùng các giải pháp tốt nhất để phân tích ưu điểm của các giao diện lập trình ứng dụng (APIs) QoS hỗ trợ trong các phiên bản gần đây (OpenFlow v1.3) nhằm đảm bảo tốc độ TCP trong trung tâm dữ liệu.
Một số thử nghiệm với thuật toán điều khiển tắc nghẽn (như CUBIC hay New Reno), phát hiện ra rằng với các bộ hạn chế tốc độ, các luồng TCP đi qua một chuyển mạch OpenFlow có thể thử nghiệm rớt nhóm các gói tin làm chúng chuyển sang giai đoạn khởi động chậm theo chu kỳ dẫn đến việc không sử dụng hiệu quả băng thông. Hoạt động này có thể ảnh hưởng xấu đến hiệu xuất của các ứng dụng tạo ra các luồng. Do đó chúng ta cần xây dựng cơ chế tốt hơn để hạn chế các tốc độ luồng trong khi cho phép các luồng hoạt động tránh được giai đoạn tắc nghẽn của chúng bằng cách buộc người dùng gửi TCP chậm lại khi ở giai đoạn tắc nghẽn. Điều này có thể làm được bởi việc rớt một gói tin trong một khoảng thời gian
(thường là RTT – Round trip time). Mà việc “rớt” gói có sẵn với các bộ giới hạn tốc độ sử dụng bộ đo trong OpenFlow.
Các giao diện ứng dụng OpenFlow cho việc hỗ trợ QoS
OpenFlow đã xác định và hỗ trợ một khái niệm gọi là “phân chia” (“slicing”), băng thông mạng được phân chia dựa vào các hàng đợi để đảm bảo tốc tối thiểu trên mỗi luồng. Nhưng với sự phân chia này hàng đợi chỉ hỗ trợ một tốc độ tối thiểu, và quan trọng hơn việc giới hạn tốc độ này có thể không đạt được do việc sử dụng “phân chia”. OpenFlow có một hỗ trợ cho QoS tại mức mỗi luồng với việc sử dụng khái niệm “mét”. Một mét được kết hợp với một luồng và xác định một số giới hạn của các “dải mét” (“meter bands”) cùng với tốc độ cụ thể. Sự kết hợp với mỗi dải là hoạt động dựa trên các gói tin phù hợp (của một luồng). “Mét” tương ứng với mỗi luồng đo tốc độ của luồng đến và quyết định “dải mét” dựa trên tốc độ đến. Ví dụ: Một luồng có thể có hai dải 100Mbps và 200Mbps. Nếu một luồng đến với tốc độ 120Mbps, “mét” ứng với dải 100Mbps trên các gói tin của luồng đó, “mét” chọn dải với tốc độ cao nhất thấp hơn thấp độ luồng đo. Một “dải mét” có thể có hoạt động áp dụng tới các gói của luồng có dải băng phù hợp. Do đó, dải băng 100Mbps có thể quyết định để rớt gói của luồng bất cứ khi nào tốc độ luồng đến lớn hơn 100Mbps. Các tùy chọn cho hoạt động trên các gói của mỗi luồng được phù hợp với một “mét” được giới hạn để:
Rớt gói (Drop): khi một kiểu băng của một “mét” được xác định “Rớt gói”, chuyển mạch sẽ rớt các gói tin nếu tốc độ của luồng có “mét” tương ứng vượt xa tốc độ liên quan tới “dải mét” đó.
Đánh dấu DSCP (Differentiated Service Code Point-Điểm mã dịch vụ phân biệt): khi kiểu “băng mét” được xác định như “DSCP remark” hoạt động chuyển mạch giống như một chính sách DiffServ đơn giản để thiêt lập quyền rớt gói của trường DSCP trong mào đầu IP.
Nghiên cứu hiệu năng của các luồng TCP giúp cho việc đảm bảo tốc độ cho các luồng TCP, tránh tắc nghẽn dựa trên khái niệm “phân chia” dựa vào hàng đợi để
đảm bảo tốc độ tối thiểu trên mỗi luồng và khái niệm “mét” kết hợp với mỗi luồng để xác định một số giới hạn “dải mét” tương ứng với tốc độ cụ thể có sẵn trong bộ điều khiển OpenFlow, từ đó đưa ra quyết định làm rớt gói tin buộc người dùng gửi TCP xuống tốc độ chậm trong giai đoạn tắc nghẽn từ đó dẫn đến việc sử dụng hiệu quả băng thông.
2.4 KẾT LUẬN CHƯƠNG
Trong chương 2, ta có thể thấy việc đảm bảo chất lượng lượng dịch vụ ngày càng được không ngừng nâng cao và cải tiến đặc biệt. Từ những giải pháp hạn chế ban đầu như InServ hay DiffServ là động lực thúc đẩy nghiên cứu. Sự ra đời của các giải pháp trên mạng định nghĩa bằng phần mềm (SDN) là điều tất yếu. Nhờ khả năng điều khiển linh hoạt, có giao diện điều khiển đơn giản và lập trình được giúp cho các nhà cung cấp dịch vụ dễ dàng trong quản lý cũng như xây dựng các mô hình dịch vụ tới khách hàng. Chúng ta có thể thấy cả hai giải pháp đưa ra ở trên đều sử dụng phương pháp định tuyến động QoS nhưng đều ảnh hưởng đến các loại lưu lượng khác trên mạng. Một giải pháp mà đảm bảo việc định tuyến các lưu lượng đa phương tiện được tối ưu hóa mà không có tác dụng phụ lên các loại lưu lượng khác, điều mà có thể được tìm hiểu ở chương sau.
CHƯƠNG 3 GIẢI PHÁP OPEN QoS HỖ TRỢ CÁC ỨNG DỤNG ĐA PHƯƠNG TIỆN