Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Phân biệt Switch Vật Lý và Switch Ảo Trên VMware, AWS

    Với dân kỹ thuật chúng ta, khái niệm về Switch vật lý (như Cisco Catalyst hay Nexus) đã quá ăn sâu vào tiềm thức qua các thế hệ.
    Tuy nhiên, khi chuyển dịch sang quản trị hạ tầng ảo hóa như VMware hay môi trường Cloud như AWS, rất nhiều người vẫn mang nguyên tư duy cấu hình mạng vật lý áp đặt lên các Switch ảo (vSwitch), dẫn đến những hiểu lầm tai hại về mặt thiết kế.
    Bài viết hôm nay sẽ đi thẳng vào vấn đề: Phân biệt rõ ràng và chi tiết sự khác nhau giữa Switch vật lý truyền thống và Switch ảo trên môi trường VMware/AWS. 1. Bản chất kiến trúc: ASIC Phần Cứng vs. CPU/RAM Máy Chủ


    Trên môi trường mạng truyền thống, sức mạnh của một Switch vật lý (như Cisco Nexus hay Catalyst) nằm ở bộ vi xử lý chuyên dụng ASIC (Application-Specific Integrated Circuit).
    Gói tin đi vào cổng số 1, ASIC tra bảng phần cứng và đẩy ra cổng số 2 với tốc độ "Wire-speed" (tốc độ dây). Mọi thứ đều được xử lý bằng linh kiện cứng, độc lập hoàn toàn với CPU trung tâm của Switch.
    Ngược lại, Switch ảo (vSwitch) là một thực thể phần mềm 100%. Trên VMware, nó chạy bằng một phần tài nguyên CPU và RAM của chính máy chủ ESXi.
    Gói tin truyền từ Máy ảo A (VM A) sang Máy ảo B (VM B) trên cùng một Host thực chất không đi qua bất kỳ sợi cáp nào. Đó đơn giản là quá trình Hypervisor sao chép dữ liệu từ vùng nhớ RAM này sang vùng nhớ RAM khác (Zero-copy networking). 2. Tư duy học địa chỉ MAC: "Động" thụ động với "Tĩnh" chủ động


    Chúng ta đều thuộc nằm lòng cơ chế Dynamic MAC Learning: Khi Switch thật nhận một Frame, nó nhìn Source MAC để điền vào bảng CAM, và nếu không biết Destination MAC, nó sẽ flood (gửi tràn ngập) Frame đó ra tất cả các cổng (Unknown Unicast Flooding).
    Trên thế giới ảo hóa, tư duy này bị lật đổ:
    • Với VMware: vSwitch không cần "học" thụ động. Bản thân Hypervisor là người sinh ra các vNIC (card mạng ảo) và cấp phát MAC cho chúng. Do đó, vSwitch luôn có sẵn một sơ đồ MAC tĩnh.Nó biết chính xác máy ảo nào đang ở cổng nào. Nếu nó nhận một gói tin có MAC đích không nằm trong danh sách, nó sẽ Drop thẳng tay thay vì Flood.
    • Với AWS VPC: Khái niệm Layer 2 truyền thống thậm chí còn không tồn tại ở lớp mạng vật lý bên dưới. AWS sử dụng mạng Software-Defined Networking (SDN). Mọi địa chỉ IP và MAC đều được quản lý tập trung qua một Mapping Service. Khi một thực thể EC2 gửi dữ liệu, hệ thống thẻ mạng phần cứng chuyên dụng (AWS Nitro) sẽ chặn gói tin lại, tra cứu cơ sở dữ liệu trung tâm, đóng gói (Encapsulate) và định tuyến nó qua mạng lõi Layer 3. Bất kỳ MAC lạ nào cũng bị triệt tiêu ngay tại cửa để đảm bảo an ninh.
    3. Tượng đài Spanning Tree Protocol (STP) sụp đổ


    STP sinh ra để cứu mạng LAN khỏi những vòng lặp (Loop) chết chóc do các đường cáp dự phòng vật lý gây ra. Thế nhưng, trong cấu trúc mạng ảo, giao thức này lại trở nên vô nghĩa.
    Kiến trúc của Switch ảo tuân theo nguyên tắc "Mạng cụt" (Stub Network). Một vSwitch không bao giờ được phép kết nối trực tiếp với một vSwitch khác, và lưu lượng từ một cổng Uplink (nối ra Switch vật lý) đi vào máy chủ sẽ không bao giờ được phép quay đầu đẩy ra một cổng Uplink khác.
    Vì Loop Layer 2 là điều bất khả thi về mặt toán học trong lòng một vSwitch, nó không chạy STP. Khi nhận được các gói tin BPDU từ thiết bị Cisco ở ngoài gửi vào, vSwitch sẽ âm thầm vứt bỏ (Drop) chúng.
    Trên AWS, điều này càng khắt khe hơn khi lưu lượng Broadcast và Multicast gốc bị chặn hoàn toàn để tối ưu băng thông toàn Data Center. 4. Quản lý Vận hành: Từng Cổng (Port) vs. Chính Sách (Policy-based)


    Là dân quản trị mạng, bạn đã quen với việc gõ interface GigabitEthernet 0/1, sau đó cấu hình switchport mode access vlan 10. Quản trị Switch vật lý là quản trị trên từng cổng.
    Bước sang kỷ nguyên ảo hóa, chúng ta quản trị dựa trên nhóm chính sách:
    • Trong VMware, chúng ta tạo ra các Port Group (Nhóm cổng). Bạn gán VLAN ID, thiết lập Security policy cho một Port Group mang tên "Ketoan_VLAN20". Sau đó, bạn chỉ việc gán hàng chục máy ảo vào Port Group này là xong, không quan tâm nó nằm ở cổng ảo số mấy.
    • Trên AWS, tư duy này tiến hóa thành Security GroupsRoute Tables. Bạn không còn chia VLAN hay Trunking nữa. Bạn gán các Security Group (hoạt động như Stateful Firewall) ôm chặt lấy từng card mạng (ENI) của máy chủ ảo, lọc lưu lượng Inbound/Outbound cực kỳ chi tiết.
    5. Cú lừa về Tốc Độ Cổng (Port Speed)


    Ví dụ thực tế: Bạn mở Windows Server trên một máy ảo VMware hoặc AWS EC2, xem Properties của card mạng và thấy báo "Speed: 10 Gbps". Nhiều người sẽ nghĩ mạng của mình đang bị khóa ở tốc độ này.
    Sự thật là, đối với giao tiếp VM-to-VM nội bộ, con số 10 Gbps đó chỉ là một "ảo ảnh" phần mềm đánh lừa hệ điều hành. Tốc độ thực tế hoàn toàn có thể vọt lên 40Gbps hoặc cao hơn, giới hạn duy nhất là băng thông Bus của RAM và tốc độ CPU của máy chủ vật lý.
    Tuy nhiên, "nút thắt cổ chai" thực sự chỉ xuất hiện khi dữ liệu cần đi ra khỏi máy chủ vật lý đó. Lúc này, toàn bộ lưu lượng khổng lồ của các Switch ảo sẽ đổ dồn về các Card mạng vật lý (Uplink/NIC) cắm trên Server.
    Nếu Server của bạn nối với Switch ToR (Top of Rack) bằng 2 sợi cáp quang 10Gbps chạy LACP (EtherChannel), thì tổng băng thông tối đa thoát ra thế giới bên ngoài của toàn bộ hệ thống ảo hóa đó sẽ không thể vượt quá 20Gbps.


    Click image for larger version

Name:	image.png
Views:	0
Size:	26.7 KB
ID:	442460​​
Working...
X