Yêu cầu về phần cứng cho Open Stack: phần 2 thiết kế mạng

RESEARCH CREW
10:55 22/06/2018

Trong phần trước của bài viết, chúng ta đã thảo luận một số phương pháp để ước tính số lượng máy chủ và cấu hình (CPU, RAM) cho OpenStack. Trong phần này, sẽ tập trung vào các yêu cầu về kết nối mạng – cách ước tính số lượng NIC (card mạng) cho máy chủ của bạn và throughput(thông lượng) của chúng.
Như chúng ta đã lưu ý, OpenStack có mức tùy biến cao, có nhiều tùy chọn. Điều này cũng giống với cả thiết kế mạng khi triển khai OpenStack. Vì rất khó để bao trùm cho tất cả các kiểu triển khai của OpenStack, nên sẽ tập trung vào việc triển khai networking ở mức phổ biến nhất.

 

1. Logical networks

Một số mạng logic thường được sử dụng trong một cloud OpenStack bao gồm:
– Management network (mạng quản trị): tách biệt băng thông(traffic) quản trị với các băng thông truy cập khác, ví dụ như băng thông được tạo ra bởi các VM và storage.
– Private network(mạng riêng): cung cấp cho dải địa chỉ IP cố định cho VM và cung cấp kết nối giữa các VMs cho một người thuê.
– Public network(mạng dùng chung): cung cấp dải địa chỉ IP tĩnh cho VM và người dùng (công cộng) truy cập tới đám mây trên VM.
– Storage network(mạng lưu trữ): tách băng thông lưu trữ với các băng thông khác.
– Replication network: tách biệt băng thông replication, ví dụ như SWIFT hoặc CEPH với băng thông khác.
– Other network: như mạng tùy chọn riêng cho băng thông của RabbitMQ, hoặc một mạng riêng cho các dịch vụ hỗ trợ HA.
Những mạng logic này nhằm phân chia các loại traffic khác nhau cho khả năng quản lý, hiệu suất và bảo mật.
Điều quan trọng là lập kế hoạch các mạng logic và quá trình triển khai thực hiện, nó sẽ ánh xạ tới các mạng vật lý. Mặc dù có rất nhiều thông số cho quá trình lập kế hoạch mạng, các câu hỏi sau đây là quan trọng nhất:
– Các dịch vụ OpenStack được triển khai trong đám mây của bạn như thế nào?
– Mạng được thực hiện như thế nào trong đám mây OpenStack của bạn?

2. Triển khai mạng cho OpenStack

Có rất nhiều hướng triển khai mạng cho OpenStack nhưng những triển khai phổ biến nhất đều dựa trên Neutron. Neutron là một thành phần mạng lõi của OpenStack. Nó cho phép tạo ra các cấu hình mạng phức tạp và linh hoạt và hỗ trợ cả ảo hóa L2 và L3, cũng như quản lý địa chỉ IP. Ở đây sẽ thảo luận hai hướng triển khai Neutron: Neutron với phân đoạn VLAN (VLAN segmentation) và Neutron với phân đoạn đường hầm thông qua VXLAN hoặc GRE (tuneling segmentation via VXLAN/GRE).

– VLAN segmentation

Với tùy chọn triển khai này, một VLAN được gán cho mỗi người thuê (tenant); ở cách này đám mây OpenStack có thể quản lý đến 4K mạng ảo hoặc 4K tenant, giả sử rằng ứng với một mạng riêng cho mỗi tenant. Hạn chế cách này là phải cấu hình thiết bị mạng hỗ trợ VLAN.

– Tuneling segmentation via VXLAN/GRE

Cả VXLAN segmentation và GRE segmentation được hỗ trợ và băng thông của người thuê được cô lập bằng cách đóng gói(encapsulate) trong đường hầm (tunel). Vì vậy nó có thể xử lý nhiều tenant hơn VLAN segmentation. Ví dụ, VXLAN hỗ trợ lên đến 16M đường hầm. Các mạng con và các mạng con IP khác nhau có thể chồng chéo nhau.
Cấu hình thiết bị mạng đơn giản hơn so với VLAN segmenation. Hạn chế của GRE segmenation là có thêm việc đóng gói GRE nên ảnh hưởng tới cả băng thông và sử dụng CPU, do đó hiệu suất tổng thể của các GRE tunel không tốt bằng VXLAN và VLAN.

3. Triển khai các dịch vụ OpenStack

Để ước lượng số mạng vật lý, số lượng thiết bị chuyển mạch mạng và số NIC cho mỗi máy chủ, sẽ phải xác định mode triển khai OpenStack. Với OpenStack, có nhiều cách để phân phối dịch vụ của mình để đạt được mục tiêu khác nhau. Các mục tiêu này có thể bao gồm các dịch vụ đáp ứng tính sẵn sàng cao và sử dụng tối ưu sử dụng tài nguyên phần cứng.
Nói chung quá trình triển khai được tách biệt giống như một dải phổ, ở một phía hội tụ này là dịch vụ OpenStack có thể chạy trên bất kỳ máy chủ, và mỗi máy chủ phục vụ công việc của người sử dụng và dịch vụ lưu trữ. Với cách tiếp cận như vậy, tất cả các máy chủ cho đám mây OpenStack đều có cùng thiết lập cấu hình (configuration); cụ thể nó cần phải có các NIC cho tất cả các mạng vật lý tồn tại trong đám mây.
Còn phía hội tụ kia, nơi tất cả các dịch vụ OpenStack kiểm soát chạy trên một dedicated node(máy chủ chuyên dụng)còn được gọi là controller node(nút điều khiển). Thông thường, nhiều node điều khiển trong đám mây luôn được thiết lập hướng tới tính sẵn sàng cao. Các loại máy chủ khác như node tính toán (phục vụ công việc của tenant) và các node lưu trữ. Với cách tiếp cận như vậy, các node điều khiển và tính toán phải được kết nối với mạng quản lý và mạng riêng. Các node điều khiển phải được kết nối với mạng công cộng. Các node tính toán và lưu trữ phải được kết nối với mạng lưu trữ.
Giữa hai đầu của dải phổ này, có nhiều sự kết hợp khác của hai phương pháp triển khai người thiết kế phải quyết định nơi đám mây OpenStack ưu tiên mục tiêu nào; cụ thể, làm thế nào phân phối các dịch vụ OpenStack đến các nút phần cứng. Các công cụ triển khai hiện có từ các nhà cung cấp OpenStack khác nhau có thể cung cấp mô hình triển khai tham chiếu đã được chứng minh. Tuy nhiên, ngay cả trong trường hợp này, cũng nên biết lựa chọn hoặc tùy biến, bao gồm:
– Một máy chủ cơ sở dữ liệu OpenStack riêng biệt (hoặc một vài máy chủ cho HA), nếu tổ chức có DBA chuyên nghiệp để chăm sóc nó. Trong trường hợp này, máy chủ cơ sở dữ liệu phải được kết nối với mạng quản lý.
– Nếu có thể muốn phục vụ công việc và dịch vụ lưu trữ của người dùng, ví dụ như Ceph OSD, trên cùng một máy chủ. Điều này sẽ cho phép sử dụng tốt hơn các tài nguyên máy chủ, nhưng đồng thời nó sẽ yêu cầu giới hạn tài nguyên CPU và RAM cho các dịch vụ lưu trữ, vì trong một số trường hợp các dịch vụ như vậy có thể bắt đầu tiêu tốn nhiều tài nguyên hơn mong đợi. Trong cấu hình này, một máy chủ như vậy vẫn nên được kết nối với storage network.
– Bạn có thể xem xét sử dụng một mạng vật lý riêng biệt cho việc theo dõi OpenStack và log. Dịch vụ OpenStack có thể tạo ra log và gửi chúng thông qua management network có thể làm gián đoạn việc quản trị. Ngoài ra, có CPU và RAM, có thể mang lại lợi ích cho điện toán đám mây.
Tùy chọn được đề xuất nhiều nhất cho các nút lưu trữ chuyên dụng (Ceph hoặc Swift) là 2 hoặc 3 NIC trên mỗi máy chủ: NIC đầu tiên dành cho management network, thứ hai là cho storage network. NIC thứ ba là dành cho replication network. Đó là tùy chọn, nhưng được đánh giá cao đối với các đám mây cấp độ cao. Đôi khi, liên kết NIC được sử dụng (xem bên dưới) cho cụm lưu trữ dành riêng để cải thiện thông lượng mạng hoặc tính sẵn sàng.

4. Thiết kế mạng vật lý

Có một số nguyên tắc chung giúp chúng ta hiểu được làm thế nào để lập bản đồ các mạng lưới hợp lý với các mạng vật lý:
Tùy chọn được đề xuất cho mạng quản lý là có một NIC riêng cho từng máy chủ tương ứng và một bộ chuyển mạch mạng riêng biệt. Sự tách biệt như vậy ngăn cản lưu lượng quản trị, chẳng hạn như truy vấn cơ sở dữ liệu, các thông điệp RabbitMQ và các truy vấn quản trị viên đám mây khỏi bị gián đoạn bởi các lưu lượng truy cập khác.
Bởi vì mạng riêng sẽ xử lý tất cả lưu lượng truy cập giữa các máy ảo nên hợp lý khi có một NIC chuyên dụng cho mỗi máy chủ tương ứng và một bộ chuyển mạch mạng chuyên dụng.
Kịch bản sử dụng phổ biến nhất cho mạng công cộng là cung cấp địa chỉ IP công cộng cho một đám mây riêng, nơi có một số địa chỉ IP công cộng có giới hạn. Nếu mạng công cộng cung cấp địa chỉ IP thực, sau đó để bảo mật, mạng công cộng có thể có một NIC riêng cho từng máy chủ tương ứng và một bộ chuyển mạch mạng riêng biệt.
Lưu lượng lưu trữ yêu cầu NIC dành riêng cho nút lưu trữ và tính toán và chuyển đổi mạng riêng biệt.
Một mạng nhân rộng là không bắt buộc và có thể được kết hợp với mạng lưu trữ; tuy nhiên lưu lượng nhân rộng có thể rất rộng vì vậy nên có một NIC riêng cho mỗi nút lưu trữ.
Đối với triển khai nhiều khu vực, bạn có thể cần một mạng lưới quản lý nhiều khu vực riêng biệt ngoài mạng lưới quản lý vùng và một mạng riêng cho sao lưu lưu trữ nhiều khu vực.

5. Bond NIC

Bond NIC là một cách hiệu quả để tăng băng thông có sẵn. Cũng có thể sử dụng phần chuyển đổi dự phòng của NIC bonding để đạt được tính sẵn sàng cao cho mạng đám mây. Nếu bạn quyết định sử dụng bond NIC, sau đó nhân số NIC của 2. Như vậy đối với HA bạn sẽ cần hai lần số lượng các thiết bị chuyển mạch mạng.

6. Tóm lược

Đối với đám mây OpenStack cấp sản xuất, 1-2 NIC trên mỗi máy chủ có thể không đủ, vì bạn sẽ phải sử dụng cùng một mạng vật lý cho một số mạng logic. Quyết định như vậy sẽ có một tác động tiêu cực đến hiệu suất mạng và bảo mật đám mây. Một thỏa hiệp hợp lý là 3 NIC cho mỗi máy chủ cho một số triển khai OpenStack, nhưng nó không đủ linh hoạt về các lựa chọn triển khai có sẵn và khả năng mở rộng. Đối với hầu hết các trường hợp, cấu hình tối ưu là 4 hoặc nhiều hơn NIC trên mỗi máy chủ.
Đối với một số mạng 1Gb là đủ, nhưng 10Gb là tối ưu. 100Gb NIC có thể tốn kém. Fibre Channel cho mạng lưu trữ không nhất thiết là cần thiết nếu bạn sử dụng Ceph như một hệ thống lưu trữ phần mềm phân tán và một mạng 10Gb với liên kết NIC tùy chọn. Đối với kết nối NIC, bạn sẽ cần thêm NIC và thiết bị chuyển mạch mạng. 

TIN LIÊN QUAN
Giới thiệu công nghệ SDN - NFV trong mạng 5G 5G hay Thế hệ thứ 5 là tên gọi cho thế hệ mạng di động mới nhất cùng với các công nghệ cốt lõi đi kèm trong đó bao gồm điện toán đám mây, SDN, NFV. Một yêu cầu quan trọng...
Phần 1: Máy chủ, CPU và RAM Việc xác định yêu cầu phần cứng cho đám mây OpenStack không phải đơn giản; quá trình phức tạp này bởi khối lượng công việc (workload) và yêu cầu về tính sẵn sàng (availability requirements) của đám mây. Cùng thời điểm, nhiều chủng...
LAS VEGAS — As CEO of Hewlett Packard Enterprise (HPE), Antonio Neri is tasked with selling his company’s vision of the future. Neri and the rest of the executive team have said that the future is software-defined — but so have many of HPE’s competitors as they also pivot from...