vPC và Jumbo Frame MTU 9000 là hai công nghệ thường được sử dụng trong hệ thống mạng Data Center, đặc biệt với các mô hình Cloud, OpenStack, Ceph, Virtualization và Storage Cluster.

vPC giúp hai switch vật lý hoạt động như một hệ thống logic đối với thiết bị kết nối xuống, cho phép thiết bị sử dụng đồng thời các đường uplink đến hai switch và tăng tính dự phòng.

Trong khi đó, Jumbo Frame cho phép tăng kích thước Ethernet frame vượt mức MTU mặc định 1500 byte. Với các hệ thống cần truyền lượng dữ liệu lớn như Ceph Storage, OpenStack, VMware, Hyper-V hoặc các mạng server nội bộ, MTU 9000 có thể giúp giảm overhead và cải thiện hiệu quả truyền dữ liệu. OpenStack cũng hỗ trợ jumbo frame cho các mạng storage, management, internal API và tenant network; tuy nhiên MTU phải được cấu hình đồng bộ trên toàn bộ đường truyền.

Bài viết dưới đây hướng dẫn cấu hình vPC trên Cisco Nexus kết hợp với Jumbo MTU 9000/9216, đồng thời bổ sung các lưu ý quan trọng khi triển khai trong hệ thống Cloud và Ceph.

Tham khảo dịch vụ VPS giá rẻ tại DataOnline

Mục lục nội dung

1. vPC là gì?

vPC (Virtual Port Channel) là công nghệ của Cisco cho phép hai switch vật lý cùng tham gia một port-channel đối với thiết bị kết nối.

Thay vì:

vPC cho phép thiết bị phía dưới sử dụng hai đường kết nối đồng thời:

                 +-------------+
                 |   Server    |
                 | LACP Bond   |
                 +------+------+
                        |
              +---------+---------+
              |                   |
          Ethernet 1/1        Ethernet 1/1
              |                   |
       +------+-------+     +-----+--------+
       |   Nexus A    |=====|   Nexus B    |
       |   Primary    |     |  Secondary   |
       +--------------+     +--------------+
                 vPC Domain

Đối với server, hai kết nối vật lý có thể được nhìn nhận như một logical port-channel.

Điều này mang lại một số lợi ích:

Tăng redundancy.
Sử dụng đồng thời nhiều đường truyền.
Giảm downtime khi một switch gặp sự cố.
Hỗ trợ LACP.
Giảm nguy cơ một đường uplink trở thành điểm lỗi duy nhất.
Phù hợp với kiến trúc Data Center.

vPC đặc biệt hữu ích khi kết nối:

Server.
Storage.
Hypervisor.
OpenStack Compute.
Ceph Node.
Access Switch.
Distribution/Leaf Switch.

2. Jumbo Frame là gì?

Jumbo Frame là Ethernet frame có kích thước lớn hơn MTU tiêu chuẩn 1500 byte.

Trong mạng Ethernet thông thường:

MTU = 1500

Khi sử dụng Jumbo Frame:

MTU = 9000

hoặc trên một số thiết bị Cisco Nexus có thể cấu hình:

MTU = 9216

MTU lớn hơn cho phép truyền nhiều dữ liệu hơn trong mỗi frame, từ đó giảm số lượng frame cần xử lý và giảm overhead tương đối của header.

Ví dụ:

MTU 1500

Data
↓
[Frame]
[Frame]
[Frame]
[Frame]
[Frame]
...

Trong khi đó:

MTU 9000

Data
↓
[       Large Frame       ]
[       Large Frame       ]
...

Jumbo Frame đặc biệt có giá trị trong các mạng:

Ceph Storage.
OpenStack Storage.
VMware vSphere.
Hyper-V.
Backup.
Replication.
Database Cluster.
High Performance Computing.
Server-to-Server Network.

OpenStack documentation cũng lưu ý rằng MTU lớn có thể giảm overhead và jumbo frame có thể mang lại lợi ích cho Storage, Storage Management, Internal API và Tenant Network.

3. MTU 9000 có thực sự nhanh hơn MTU 1500 không?

Không phải cứ tăng MTU lên 9000 là toàn bộ hệ thống sẽ nhanh hơn.

Hiệu quả phụ thuộc vào:

Bandwidth.
Packet size.
CPU.
NIC.
Switch.
Storage.
Protocol.
Workload.
Network topology.

Ví dụ với Ceph:

VM
 ↓
Compute Node
 ↓
Network
 ↓
Ceph Node
 ↓
NVMe

Nếu sử dụng:

NVMe + 100GbE

thì network có thể truyền lượng dữ liệu rất lớn. Jumbo Frame có thể giúp giảm overhead của packet processing.

Ngược lại, nếu hệ thống chỉ sử dụng:

1GbE + HDD

thì lợi ích từ MTU 9000 có thể không đáng kể.

Quan trọng nhất là MTU phải được hỗ trợ end-to-end.

4. Một lỗi rất thường gặp khi cấu hình Jumbo Frame

Không được chỉ cấu hình MTU 9000 trên server.

Ví dụ:

Server
MTU 9000
   ↓
Switch
MTU 1500
   ↓
Server
MTU 9000

Mô hình này có thể gây:

Packet drop.
Fragmentation.
Connection timeout.
Network chập chờn.
Một số ứng dụng hoạt động nhưng ứng dụng khác bị lỗi.
Ceph performance không ổn định.
VXLAN không hoạt động đúng.

Đối với VLAN, MTU của VLAN cũng không thể lớn hơn MTU của interface vật lý bên dưới. Vì vậy cần cấu hình MTU xuyên suốt từ physical interface, bond, VLAN đến network overlay nếu có.

5. Mô hình vPC đề xuất

Một mô hình Data Center phổ biến:

                         Core / Spine
                         /          \
                        /            \
                       /              \
                +-----+----+    +----+-----+
                | Nexus A  |====| Nexus B  |
                | Primary  |    | Secondary |
                +----+-----+    +-----+-----+
                     |                |
                     |      vPC       |
                     +-------+--------+
                             |
                         Server
                         /    \
                       NIC1   NIC2

Hai Nexus tạo thành:

vPC Domain

Server sử dụng:

LACP / Port-Channel

và kết nối đến cả hai switch.

Trong hệ thống Ceph:

             +----------------+
             |   Ceph Node    |
             +-------+--------+
                     |
               LACP / Bond
                /        \
               /          \
        +-----+----+  +----+-----+
        | Nexus A  |  | Nexus B  |
        +----------+  +----------+

Đây là mô hình phù hợp để giảm single point of failure ở tầng network.

6. Các thành phần cần cấu hình cho vPC

Một vPC domain cơ bản bao gồm:

vPC Peer.
vPC Peer Keepalive.
vPC Peer Link.
vPC Member Port.
LACP.
VLAN/Trunk.
MTU nếu sử dụng Jumbo Frame.

Có thể hình dung:

Nexus A ================= Nexus B
          Peer Link
             +
        Keepalive

       |             |
       |             |
       +---- vPC ----+
             |
          Server

7. Chuẩn bị trước khi cấu hình

Trước khi thực hiện cấu hình, nên xác định:

Switch A

Hostname: NEXUS-A
Role: Primary

Switch B

Hostname: NEXUS-B
Role: Secondary

vPC Domain

Ví dụ:

vPC Domain: 10

Peer Keepalive

Ví dụ:

Nexus A: 192.168.100.1
Nexus B: 192.168.100.2

Peer Link

Ví dụ:

Ethernet1/47
Ethernet1/48

gom vào:

Port-channel 10

Server vPC

Ví dụ:

Nexus A: Ethernet1/1
Nexus B: Ethernet1/1

gom thành:

vPC 20

8. Bước 1: Enable các tính năng vPC và LACP

Trên Nexus A:

configure terminal

feature vpc
feature lacp
feature interface-vlan

Trên Nexus B:

configure terminal

feature vpc
feature lacp
feature interface-vlan

Kiểm tra:

show feature

Đảm bảo các feature cần thiết ở trạng thái:

enabled

9. Bước 2: Tạo vPC Domain

Trên Nexus A:

vpc domain 10

Trên Nexus B:

vpc domain 10

Hai switch phải sử dụng cùng số vPC domain.

Kiểm tra:

show vpc

Ở giai đoạn này vPC chưa hình thành hoàn chỉnh vì Peer Link và Keepalive chưa được cấu hình.

10. Bước 3: Cấu hình vPC Peer Keepalive

Peer Keepalive dùng để hai switch kiểm tra trạng thái của nhau.

Có thể sử dụng:

Layer 3 interface.
Dedicated interface.
SVI.
VRF riêng.

Một mô hình tốt là sử dụng một VRF riêng cho keepalive.

Ví dụ:

vlan 23
  name VPC-KEEPALIVE

Tạo VRF:

vrf context KEEPALIVE

Trên Nexus A:

interface vlan 23
  vrf member KEEPALIVE
  ip address 192.168.100.1/24
  no shutdown

Trên Nexus B:

interface vlan 23
  vrf member KEEPALIVE
  ip address 192.168.100.2/24
  no shutdown

Sau đó cấu hình port kết nối keepalive.

Ví dụ Nexus A:

interface Ethernet1/32
  switchport
  switchport mode access
  switchport access vlan 23

Nexus B cấu hình tương tự.

Kiểm tra:

ping 192.168.100.2 vrf KEEPALIVE

và trên Nexus B:

ping 192.168.100.1 vrf KEEPALIVE

11. Cấu hình Peer Keepalive

Trên Nexus A:

vpc domain 10
  peer-keepalive destination 192.168.100.2 source 192.168.100.1 vrf KEEPALIVE

Trên Nexus B:

vpc domain 10
  peer-keepalive destination 192.168.100.1 source 192.168.100.2 vrf KEEPALIVE

Kiểm tra:

show vpc peer-keepalive

Trạng thái mong muốn:

peer is alive

12. Bước 4: Cấu hình vPC Peer Link

Peer Link là đường kết nối rất quan trọng giữa hai switch vPC.

Nên sử dụng ít nhất hai physical link và gom thành EtherChannel.

Ví dụ:

Nexus A
Eth1/47
Eth1/48
    |
    | LACP
    |
Port-channel 10
    ||
Port-channel 10
    |
    | LACP
    |
Eth1/47
Eth1/48
Nexus B

Trên Nexus A:

interface Ethernet1/47-48
  description VPC-PEER-LINK
  channel-group 10 mode active

Sau đó:

interface port-channel 10
  description VPC-PEER-LINK
  switchport
  switchport mode trunk
  vpc peer-link
  spanning-tree port type network

Trên Nexus B thực hiện tương tự:

interface Ethernet1/47-48
  description VPC-PEER-LINK
  channel-group 10 mode active

và:

interface port-channel 10
  description VPC-PEER-LINK
  switchport
  switchport mode trunk
  vpc peer-link
  spanning-tree port type network

Kiểm tra:

show vpc

Mục tiêu:

Peer status                     : peer adjacency formed ok
vPC peer-link status            : up
Configuration consistency       : success

13. Bước 5: Cấu hình vPC xuống Server

Giả sử server có:

NIC1 → Nexus A Ethernet1/1
NIC2 → Nexus B Ethernet1/1

Trên Nexus A:

interface Ethernet1/1
  description SERVER-01-NIC1
  switchport
  switchport mode trunk
  channel-group 20 mode active

Sau đó:

interface port-channel 20
  description SERVER-01
  switchport
  switchport mode trunk
  vpc 20

Trên Nexus B:

interface Ethernet1/1
  description SERVER-01-NIC2
  switchport
  switchport mode trunk
  channel-group 20 mode active

và:

interface port-channel 20
  description SERVER-01
  switchport
  switchport mode trunk
  vpc 20

Kiểm tra:

show vpc

Kết quả mong muốn:

vPC status
id    Port       Status
20    Po20       up

14. Cấu hình LACP trên Server

Nếu server Linux sử dụng bonding:

NIC1 ───── Nexus A
           |
          vPC
           |
NIC2 ───── Nexus B

Có thể sử dụng:

802.3ad / LACP

Ví dụ Netplan:

network:
  version: 2
  renderer: networkd

  bonds:
    bond0:
      interfaces:
        - eno1
        - eno2

      parameters:
        mode: 802.3ad
        lacp-rate: fast
        transmit-hash-policy: layer3+4

      mtu: 9000

Các NIC thành viên cũng cần đảm bảo MTU phù hợp.

Sau khi cấu hình:

netplan apply

Kiểm tra:

ip link show bond0

và:

cat /proc/net/bonding/bond0

Kiểm tra:

Bonding Mode: IEEE 802.3ad
MII Status: up

15. Cấu hình Jumbo Frame MTU 9000 trên Cisco Nexus

Trên Cisco Nexus, việc hỗ trợ frame lớn không đơn giản chỉ là đặt MTU trên một interface.

Một cách cấu hình phổ biến trên Nexus là sử dụng network-qos.

Ví dụ:

configure terminal

policy-map type network-qos JUMBO
  class type network-qos class-default
    mtu 9216

system qos
  service-policy type network-qos JUMBO

MTU 9216 trên switch tạo ra headroom lớn hơn mức MTU 9000 mà server thường sử dụng.

Cần lưu ý rằng MTU 9216 trên switch không có nghĩa server bắt buộc phải đặt MTU 9216.

Ví dụ hoàn toàn có thể sử dụng:

Switch      9216
Server      9000

Mục tiêu là switch có khả năng chuyển tiếp frame kích thước lớn hơn MTU mà endpoint sử dụng.

16. MTU nên đặt bao nhiêu: 9000 hay 9216?

Đây là câu hỏi thường gặp khi cấu hình Cisco Nexus.

Có thể hiểu:

Server / Linux:
MTU 9000

Cisco Nexus:
MTU capability 9216

Cách này khá phổ biến.

Không nên hiểu rằng tất cả thiết bị trong hệ thống bắt buộc phải có cùng một con số.

Điều quan trọng là:

đường truyền phải hỗ trợ frame cần thiết mà không bị drop hoặc fragment sai cách.

17. Kiểm tra MTU trên Cisco Nexus

Có thể kiểm tra cấu hình:

show running-config | section network-qos

Kiểm tra:

show policy-map system type network-qos

Kiểm tra interface:

show interface Ethernet1/1

Kiểm tra port-channel:

show interface port-channel 20

Kiểm tra vPC:

show vpc

18. Kiểm tra MTU trên Linux

Trên server:

ip link show

Ví dụ:

bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
mtu 9000

Kiểm tra từng NIC:

ip link show eno1
ip link show eno2

Kiểm tra VLAN:

ip link show bond0.100

Nếu sử dụng bridge:

ip link show br0

Cần kiểm tra toàn bộ chain:

NIC
 ↓
Bond
 ↓
VLAN
 ↓
Bridge
 ↓
VM

Không nên chỉ kiểm tra bond0.

19. Kiểm tra Jumbo Frame bằng ping

Đây là bước rất quan trọng.

Giả sử hai server:

Server A: 10.10.10.11
Server B: 10.10.10.12

Thử ping với payload lớn:

ping -M do -s 8972 10.10.10.12

Với IPv4:

8972 payload
+
28 bytes IP/ICMP header
=
9000 bytes

Nếu thành công:

64 bytes from ...

thì có thể xác nhận đường truyền đang hỗ trợ kích thước tương ứng.

Nếu gặp:

Message too long

hoặc:

Frag needed

cần kiểm tra lại MTU.

Có thể giảm dần:

ping -M do -s 8000 10.10.10.12

sau đó:

ping -M do -s 8500 10.10.10.12

và cuối cùng:

ping -M do -s 8972 10.10.10.12

20. Kiểm tra MTU end-to-end

Đây là điểm quan trọng nhất khi triển khai Jumbo Frame.

Không chỉ kiểm tra:

mà cần kiểm tra đúng đường truyền thực tế:

     ↓
vPC
     ↓
Leaf
     ↓
Spine
     ↓
Leaf
     ↓
Ceph Node

Ví dụ với Ceph:

ping -M do -s 8972 <ceph-node-ip>

Nếu sử dụng OpenStack:

 ↓
OVS / OVN
 ↓
VLAN / VXLAN
 ↓
Network
 ↓
Ceph

cần tính cả overhead của overlay.

21. MTU trong OpenStack

Đây là phần rất quan trọng nếu hệ thống sử dụng OpenStack + Ceph.

OpenStack Networking sử dụng MTU của physical network để tính MTU cho virtual network. Với mạng VXLAN, MTU của VM phải nhỏ hơn MTU của physical network để dành chỗ cho encapsulation overhead. Ví dụ tài liệu OpenStack đưa ra trường hợp physical MTU 9000 và VXLAN IPv4 thì MTU của instance có thể là khoảng 8950.

Có thể hình dung:

Physical Network
MTU 9000
     |
     ↓
VXLAN overhead
     |
     ↓
VM Network
MTU khoảng 8950

Do đó không nên đặt MTU 9000 cho VM chỉ vì physical network đang sử dụng MTU 9000 nếu VM traffic đi qua VXLAN.

22. Cấu hình MTU cho OpenStack

Trong mô hình sử dụng underlying physical network MTU 9000, OpenStack có các tham số như:

[DEFAULT]
global_physnet_mtu = 9000

và:

[ml2]
path_mtu = 9000

Các giá trị này phải phù hợp với thiết kế network thực tế.

Không nên thay đổi MTU trên OpenStack một cách độc lập mà không kiểm tra:

Switch
 ↓
NIC
 ↓
Bond
 ↓
Bridge / OVS / OVN
 ↓
VLAN / VXLAN
 ↓
VM

23. Jumbo Frame trong mạng Ceph

Ceph là một trong những workload rất phù hợp để cân nhắc Jumbo Frame.

Ví dụ:

OpenStack Compute
       |
       | RBD I/O
       |
       v
+------------------+
|   Ceph Network   |
|    MTU 9000      |
+------------------+
       |
  +----+----+
  |         |
Ceph01    Ceph02
  |         |
 NVMe      NVMe

Ceph có nhiều loại traffic:

Client I/O.
OSD replication.
Recovery.
Backfill.
Scrubbing.
Heartbeat.
Cluster communication.

Nếu network có bandwidth cao, MTU lớn có thể giúp giảm overhead packet processing.

Tuy nhiên, MTU 9000 không thể bù cho một thiết kế network yếu.

Ví dụ:

NVMe Gen5
+
100GbE

có ý nghĩa hơn nhiều so với:

NVMe Gen5
+
1GbE

24. Có nên tách Ceph Network và Client Network?

Trong hệ thống lớn, có thể cân nhắc tách traffic:

Network 1
Ceph Public / Client

Network 2
Ceph Cluster / Replication

Ví dụ:

          Ceph Node
        /           \
       /             \
Client Network    Cluster Network
   100GbE             100GbE
       |                 |
     Client          OSD Replication

Mục tiêu là tránh recovery hoặc replication chiếm hết bandwidth dành cho client.

Tuy nhiên, việc tách network hay sử dụng chung network cần dựa trên:

Bandwidth.
Number of OSD.
Workload.
Switch capacity.
Traffic pattern.

Không phải mọi cluster đều cần hai physical network độc lập.

25. vPC và Ceph: mô hình tham khảo

Một kiến trúc phù hợp cho Ceph Cluster:

                       Spine
                      /     \
                     /       \
              +-----+---------+-----+
              |                     |
          Nexus A               Nexus B
          Primary               Secondary
              |                     |
              +---------+-----------+
                        |
                       vPC
                        |
          +-------------+-------------+
          |             |             |
        Ceph01        Ceph02        Ceph03
          |             |             |
        NVMe          NVMe          NVMe

Mỗi Ceph Node có:

NIC1 → Nexus A
NIC2 → Nexus B

và sử dụng:

LACP 802.3ad

Nếu sử dụng Jumbo Frame:

Ceph NIC     MTU 9000
Bond         MTU 9000
VLAN         MTU 9000
Switch       ≥ 9000

Tất cả các thiết bị trên đường truyền phải được kiểm tra.

26. Các trường hợp lỗi vPC thường gặp

Trường hợp 1: vPC Peer Link bị lỗi

Khi Peer Link bị mất nhưng Peer Keepalive vẫn hoạt động, hai switch vẫn biết được trạng thái của nhau.

Đây là lý do không nên bỏ qua Peer Keepalive.

Kiểm tra:

show vpc
show vpc peer-keepalive

Trường hợp 2: Peer Keepalive bị lỗi

Nếu chỉ Keepalive bị lỗi nhưng Peer Link vẫn hoạt động, vPC có thể vẫn tiếp tục hoạt động.

Tuy nhiên cần xử lý lỗi vì mất Keepalive làm giảm khả năng phát hiện tình trạng peer.

Trường hợp 3: Một switch vPC bị mất

Nếu Nexus A bị mất:

Nexus A ❌
Nexus B ✓

các kết nối còn hoạt động qua Nexus B sẽ tiếp tục phục vụ traffic nếu thiết kế và thiết bị đầu cuối hỗ trợ redundancy đúng cách.

Đây chính là một trong những mục tiêu chính của vPC.

Trường hợp 4: Peer Link và Keepalive cùng mất

Đây là tình huống đặc biệt nguy hiểm.

Hai switch có thể không còn khả năng xác định chính xác trạng thái của nhau.

Nếu thiết kế không có cơ chế bảo vệ phù hợp, có thể xảy ra:

Split-brain.
Loop.
MAC flapping.
Broadcast storm.
Network instability.

Do đó Peer Link và Peer Keepalive cần được thiết kế với failure scenario rõ ràng.

27. Những lỗi thường gặp khi cấu hình MTU 9000

Chỉ cấu hình MTU trên server

Sai:

Server = 9000
Switch = 1500

Chỉ cấu hình trên switch

Cũng không đủ:

Server = 1500
Switch = 9000

Bond có MTU khác NIC

Ví dụ:

eno1 = 9000
eno2 = 9000
bond0 = 1500

có thể khiến hệ thống không đạt được mục tiêu Jumbo Frame.

VLAN có MTU thấp hơn Bond

Ví dụ:

bond0 = 9000
bond0.100 = 1500

traffic trên VLAN vẫn bị giới hạn bởi VLAN interface.

Bridge có MTU thấp

Nếu sử dụng:

NIC
 ↓
Bond
 ↓
Bridge
 ↓
VM

bridge cũng cần được kiểm tra.

VXLAN không tính overhead

Nếu physical MTU là 9000 thì không có nghĩa VM VXLAN cũng có thể dùng MTU 9000.

OpenStack phải dành không gian cho encapsulation overhead.

28. Không nên bật MTU 9000 cho toàn bộ mạng một cách máy móc

Đây là một lưu ý quan trọng khi thiết kế Data Center.

Không phải network nào cũng cần Jumbo Frame.

Có thể phân chia:

Network	MTU đề xuất
Internet/Public	1500
Management	1500 hoặc 9000
Storage	9000
Ceph	9000
Internal API	9000
Tenant Network	Tùy overlay
VXLAN Underlay	9000
VXLAN VM Network	MTU sau khi trừ overhead
Floating IP	Thường 1500

OpenStack documentation cũng khuyến nghị thận trọng với External/Provisioning/Floating IP interface vì router và các Layer-3 boundary có thể không forward jumbo frame.

29. Checklist triển khai vPC + Jumbo Frame

vPC

Jumbo Frame

OpenStack

Ceph

Ceph public network đúng.
Ceph cluster network đúng nếu sử dụng.
MTU đồng nhất.
Không packet loss.
Network latency thấp.
Recovery không chiếm hết bandwidth.
Kiểm tra throughput.
Kiểm tra IOPS thực tế.

30. Kiểm tra hiệu năng sau khi cấu hình

Không nên chỉ kiểm tra bằng ping.

Có thể sử dụng iperf3.

Trên server:

iperf3 -s

Client:

iperf3 -c 10.10.10.12

Test nhiều stream:

iperf3 -c 10.10.10.12 -P 8

Để đánh giá network thực tế, nên kiểm tra:

Bandwidth
Latency
Packet Loss
Jitter
CPU Usage
NIC Utilization

Nếu là Ceph, tiếp tục kiểm tra:

Ceph IOPS
Ceph Throughput
OSD Latency
Recovery Performance
Network Utilization

31. MTU 9000 có giúp Ceph tăng IOPS không?

Không thể khẳng định trực tiếp.

MTU lớn chủ yếu giúp giảm overhead truyền packet và có thể cải thiện hiệu quả sử dụng network.

IOPS của Ceph còn phụ thuộc rất lớn vào:

NVMe.
CPU.
RAM.
OSD configuration.
Replication.
PG.
Client workload.
Network bandwidth.
Network latency.
Recovery.
RBD.
QEMU/KVM.

Ví dụ một hệ thống:

6 × NVMe
100GbE
Ceph

có thể có IOPS rất cao.

Nhưng nếu:

6 × NVMe
10GbE
Ceph

thì network có thể trở thành bottleneck trước khi NVMe đạt tới giới hạn.

32. vPC + Jumbo Frame có phù hợp cho OpenStack + Ceph không?

Có, đây là một mô hình rất phù hợp cho Data Center Cloud, nếu được thiết kế đúng.

Ví dụ:

                    Spine
                  /       \
                 /         \
          Nexus A           Nexus B
             \               /
              \     vPC     /
               \           /
                +---------+
                     |
             +-------+-------+
             |               |
          Compute          Ceph
             |               |
          OpenStack         RBD
             |               |
             +-------+-------+
                     |
                  NVMe

Mô hình này có thể tận dụng:

vPC để tăng redundancy.
LACP để sử dụng nhiều đường truyền.
Jumbo Frame để giảm network overhead.
Ceph để cung cấp distributed storage.
OpenStack để cung cấp Cloud Infrastructure.

Kết luận

vPC và Jumbo Frame MTU 9000 là hai thành phần quan trọng trong nhiều kiến trúc Data Center hiện đại.

vPC giải quyết bài toán redundancy và sử dụng đồng thời nhiều đường uplink, trong khi Jumbo Frame giúp tối ưu hiệu quả truyền dữ liệu trên những mạng có workload lớn.

Đặc biệt với mô hình:

OpenStack
   +
Ceph
   +
NVMe
   +
25/100GbE

việc thiết kế network đúng có ảnh hưởng rất lớn đến hiệu năng tổng thể.

Tuy nhiên, MTU 9000 không phải là cấu hình chỉ thực hiện trên switch. Cần đảm bảo toàn bộ đường truyền hỗ trợ kích thước frame tương ứng:

NIC
 ↓
Bond
 ↓
VLAN
 ↓
Bridge / OVS / OVN
 ↓
Switch
 ↓
vPC
 ↓
Spine
 ↓
Switch
 ↓
Ceph / Server

Nếu sử dụng OpenStack với VXLAN hoặc các overlay network khác, cần đặc biệt chú ý overhead encapsulation và không nên đặt MTU của VM bằng MTU physical một cách máy móc. OpenStack có cơ chế tính MTU cho virtual network dựa trên underlying network và cần dành không gian cho overlay.

Với hệ thống Cloud/VPS sử dụng OpenStack + Ceph + NVMe, nên kiểm tra cả ba lớp:

Network → Storage → Virtualization

thay vì chỉ benchmark riêng từng thành phần. Khi network được thiết kế đúng, vPC kết hợp Jumbo Frame có thể trở thành nền tảng tốt cho một hạ tầng Cloud có yêu cầu cao về HA, bandwidth, latency và khả năng mở rộng.

Đọc thêm tài liệu tại đây https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/aci-guide-vpc.pdf

1. vPC là gì?

2. Jumbo Frame là gì?

3. MTU 9000 có thực sự nhanh hơn MTU 1500 không?

4. Một lỗi rất thường gặp khi cấu hình Jumbo Frame

5. Mô hình vPC đề xuất

6. Các thành phần cần cấu hình cho vPC

7. Chuẩn bị trước khi cấu hình

Switch A

Switch B

vPC Domain

Peer Keepalive

Peer Link

Server vPC

8. Bước 1: Enable các tính năng vPC và LACP

9. Bước 2: Tạo vPC Domain

10. Bước 3: Cấu hình vPC Peer Keepalive

11. Cấu hình Peer Keepalive

12. Bước 4: Cấu hình vPC Peer Link

13. Bước 5: Cấu hình vPC xuống Server

14. Cấu hình LACP trên Server

15. Cấu hình Jumbo Frame MTU 9000 trên Cisco Nexus

16. MTU nên đặt bao nhiêu: 9000 hay 9216?

17. Kiểm tra MTU trên Cisco Nexus

18. Kiểm tra MTU trên Linux

19. Kiểm tra Jumbo Frame bằng ping

20. Kiểm tra MTU end-to-end

21. MTU trong OpenStack

22. Cấu hình MTU cho OpenStack

23. Jumbo Frame trong mạng Ceph

24. Có nên tách Ceph Network và Client Network?

25. vPC và Ceph: mô hình tham khảo

26. Các trường hợp lỗi vPC thường gặp

Trường hợp 1: vPC Peer Link bị lỗi

Trường hợp 2: Peer Keepalive bị lỗi

Trường hợp 3: Một switch vPC bị mất

Trường hợp 4: Peer Link và Keepalive cùng mất

27. Những lỗi thường gặp khi cấu hình MTU 9000

Chỉ cấu hình MTU trên server

Chỉ cấu hình trên switch

Bond có MTU khác NIC

VLAN có MTU thấp hơn Bond

Bridge có MTU thấp

VXLAN không tính overhead

28. Không nên bật MTU 9000 cho toàn bộ mạng một cách máy móc

29. Checklist triển khai vPC + Jumbo Frame

vPC

Jumbo Frame

OpenStack

Ceph

30. Kiểm tra hiệu năng sau khi cấu hình

31. MTU 9000 có giúp Ceph tăng IOPS không?

32. vPC + Jumbo Frame có phù hợp cho OpenStack + Ceph không?

Kết luận

dataonline