Hetzner Cloud và hành trình xây dựng ngăn xếp mạng riêng: Từ Linux bridge đến Open vSwitch

Hetzner vừa đăng tải bài viết kỹ thuật đầu tiên trong loạt bài kể về quá trình phát triển ngăn xếp mạng phía sau Hetzner Cloud. Đây không chỉ là câu chuyện về công nghệ, mà còn là minh chứng cho triết lý "tự làm lấy" của nhà cung cấp hạ tầng đến từ Đức — nơi mọi thành phần quan trọng đều được đội ngũ nội bộ tự thiết kế và vận hành.

Triết lý: Mạng thông minh nằm ở host, không nằm ở thiết bị vật lý

Hầu hết các sản phẩm cloud đều cần kết nối linh hoạt và đáng tin cậy, để khách hàng — và cả khách hàng của khách hàng — có thể truy cập dịch vụ chạy trong hạ tầng nhà cung cấp. Cách tiếp cận của Hetzner khá rõ ràng: giữ mạng vật lý đơn giản, đẩy các chức năng mạng phức tạp lên máy chủ (host).

Thay vì xây dựng một hệ thống mạng vật lý "thông minh" và cồng kềnh, Hetzner thiết kế để lớp mạng vật lý chỉ đảm nhiệm việc cung cấp kết nối IP ổn định cho các host. Mọi thứ phức tạp hơn như tường lửa (Firewall), mạng riêng (Private Network) và các dịch vụ hạ tầng phụ trợ đều chạy ngay trên host.

Minh họa hạ tầng mạng Hetzner Cloud

Cách làm này mang lại nhiều lợi ích:

• Tự do thiết kế: không bị giới hạn bởi những gì nhà cung cấp phần cứng cung cấp sẵn
• Phân tách trách nhiệm rõ ràng giữa các nhóm và công nghệ
• Khoanh vùng ảnh hưởng (blast radius): phần lớn lỗi chỉ ảnh hưởng đến một host duy nhất thay vì lan ra toàn hệ thống

Đổi lại, đội ngũ phải tự sở hữu và điều chỉnh toàn bộ giải pháp theo nhu cầu riêng — điều vốn đã nằm trong "DNA" của Hetzner.

Nhìn lại lịch sử: Từ Linux bridge đến Open vSwitch

Ngăn xếp mạng của Hetzner đã trải qua nhiều thế hệ công nghệ khác nhau:

Giai đoạn 2011 — vServer đầu tiên: Sử dụng HDD, Linux bridge gốc và định tuyến tĩnh (static route). Hệ thống hỗ trợ dual-stack với băng thông tối đa 1 Gb/s mỗi host, đạt khoảng 25.000 instance trước khi kết thúc vòng đời.

Tháng 9/2015 — Thế hệ hyper-converged với Ceph: Chuyển sang định tuyến động qua BGP, dùng Linux bridge với NAT 1:1 cho IPv4 và định tuyến hoàn toàn cho IPv6. Điều này cho phép di chuyển địa chỉ IP linh hoạt và bảo trì host mà không ảnh hưởng đến khách hàng. Năm 2016, đường truyền lên host được nâng lên 2x 10 Gb/s. Hệ thống này kéo dài đến 2018 và đạt khoảng 50.000 instance.

Năm 2018 — Hetzner Cloud ra đời: Bỏ NAT, chuyển thẳng sang định tuyến IPv4 trực tiếp.

Tháng 7/2019: Ra mắt data plane dựa trên Open vSwitch, bổ sung hỗ trợ mạng riêng ảo hóa bằng đóng gói VXLAN.

Tháng 3/2021: Ra mắt tường lửa cloud có trạng thái (stateful firewall) dựa trên các flow của Open vSwitch kết hợp netfilter.

Những "viên gạch" cấu thành một VM host

Để một máy chủ cloud hoạt động, mỗi VM host phải đảm nhiệm một loạt chức năng:

• Kết nối Internet: phần lớn máy chủ cần truy cập công khai để hệ thống và dịch vụ có thể được truy cập từ bất kỳ đâu
• Private Network: kết nối các máy chủ, Load Balancer và có thể cả máy chủ chuyên dụng (dedicated server) qua mạng ảo riêng. Traffic được đóng gói bằng VXLAN với VNI (Virtual Network Identifier) riêng cho từng mạng
• Firewall: kiểm soát truy cập theo cổng, giao thức, hoặc giới hạn chiều ra của máy chủ. Việc xử lý phải diễn ra càng gần máy chủ càng tốt, tức là ngay trên host
• DHCP server: cấp phát cấu hình IPv4 động cho các interface công khai và riêng tư
• Metadata server tại địa chỉ 169.254.169.254: phục vụ cloud-init và nhiều công cụ khác như CSI driver, hc-utils, Afterburn/Ignition của Flatcar Linux, hay Talos Linux

Điểm đáng chú ý: cả DHCP server lẫn metadata server đều chạy cục bộ trên từng VM host, nhằm đảm bảo tính sẵn sàng và khả năng phục hồi cao nhất.

Kiến trúc dịch vụ hạ tầng trên VM host

Open vSwitch: Trái tim của ngăn xếp mạng

Phần lớn đường truyền dữ liệu mạng được thực hiện bởi Open vSwitch (OVS) — một virtual switch đa lớp mã nguồn mở. Data path của nó đã nằm trong nhân Linux từ lâu, còn phần user space/control plane có sẵn cho mọi bản phân phối Linux phổ biến.

OVS là ngăn xếp mạng mặc định cho nhiều môi trường ảo hóa như Proxmox VE, OpenStack hay oVirt. Tuy nhiên Hetzner không dùng bất kỳ giải pháp đóng gói nào trong số đó, mà tự quản lý KVM và toàn bộ thành phần xung quanh bằng công cụ tự phát triển.

OVS sử dụng OpenFlow — giao thức mở để cấu hình data plane và quy định cách chuyển tiếp gói tin. Với mỗi hướng giao tiếp, cần có một flow chỉ định cách xử lý và điểm đến của gói. Các flow này có thể khớp chính xác cho những trường hợp như:

• Giao tiếp với gateway qua ARP, NDP, ICMP
• Traffic hướng đến các thành viên khác trong cùng mạng riêng
• Kết nối đến dịch vụ trên Internet

Flusskrebs: "Cua sông" điều phối Open vSwitch

Để cấu hình OVS, lẽ thường sẽ dùng OVN (Open Virtual Network) — control plane chính thức được phát triển song song với OVS. Nhưng vào thời điểm tích hợp OVS, Hetzner đã quyết định đi con đường riêng với một giải pháp tùy chỉnh mang tên Flusskrebs (nghĩa đen là "cua sông" 🦀).

Flusskrebs được viết bằng Python, cung cấp REST API để phần control plane cục bộ trên host gọi tới, và chịu trách nhiệm cấu hình các flow cần thiết cho từng VM hoặc Load Balancer. Nó cũng đảm nhiệm luôn vai trò DHCP server trung tâm cho các interface mạng riêng.

Maximilian Wilhelm, Trưởng nhóm SDN tại Hetzner

Kiến trúc mạng chi tiết trên VM host

Hầu hết các host dùng hai uplink 10 Gb/s gộp thành LAG (Link Aggregation Group) bằng LACP, kết nối đến hai switch vật lý tạo thành virtual chassis. Từ đầu năm nay, Hetzner đã bắt đầu chuyển sang hai uplink định tuyến gốc dùng BGP kết nối đến hai switch độc lập để tăng khả năng chịu lỗi.

Một chi tiết thiết kế quan trọng: các interface uplink không kết nối trực tiếp vào cầu OVS, mà hệ thống Linux định tuyến giữa uplink và OVS. Nhờ vậy, khả năng truy cập host độc lập với OVS, giúp việc cài đặt và bảo trì host dễ dàng hơn.

Mỗi máy chủ cloud có thể có:

• 1 interface mạng công khai
• Tối đa 3 interface mạng riêng

Để xử lý gói tin đi ra (egress), hệ thống dùng các flow mẫu trong OpenFlow, chẳng hạn chỉ chấp nhận gói có đúng địa chỉ MAC nguồn hoặc địa chỉ IP gắn với máy chủ. Với chiều vào (ingress), host tự nhận diện với VM bằng một "virtual gateway MAC" cố định là d2:74:7f:6e:37:e3.

Tường lửa stateful và bài toán giới hạn kết nối

Song song với Open vSwitch, netfilter connection tracking của Linux được dùng để hiện thực tính năng tường lửa cloud có trạng thái. Vì bảng connection tracking được chia sẻ toàn cục, Hetzner phải ngăn nó tràn và đảm bảo công bằng giữa các khách hàng.

Giải pháp là ctcount — một dự án nội bộ theo dõi các entry connection tracking và áp đặt giới hạn 80.000 kết nối đồng thời đang hoạt động cho mỗi máy chủ. Khi chạm ngưỡng này, không kết nối mới nào được mở cho đến khi có kết nối cũ đóng lại.

Hiện trạng và những bước đi tiếp theo

Ngăn xếp dựa trên Open vSwitch đã phục vụ Hetzner rất tốt, ngay cả khi hệ thống vượt mốc hơn một triệu máy chủ cloud. Tuy nhiên, đội ngũ đã nhận thấy những giới hạn nhất định và muốn cải thiện khả năng mở rộng, độ bền bỉ và tính linh hoạt.

Trong nhiều năm qua, nhóm SDN của Hetzner đã xây dựng một ngăn xếp mạng hoàn toàn mới, chuyên biệt hơn, được thiết kế riêng cho nhu cầu của công ty nhưng vẫn dễ vận hành và là nền tảng vững chắc cho các tính năng tương lai — ví dụ như IPv6 cho mạng riêng.

Chi tiết về ngăn xếp mạng mới này sẽ được trình bày trong phần tiếp theo của loạt bài. Hetzner cũng đã có phiên chia sẻ tại Hetzner Summit với tiêu đề "Ngăn xếp mạng Hetzner Cloud mới — Phân tích kỹ thuật chuyên sâu về cách chúng tôi truyền tải gói tin của bạn".

Góc nhìn cho người dùng Việt Nam

Với các doanh nghiệp và lập trình viên Việt Nam đang cân nhắc hạ tầng cloud, câu chuyện của Hetzner mang lại vài gợi ý đáng suy ngẫm. Thứ nhất, việc đặt các chức năng mạng quan trọng ngay trên host thay vì tập trung ở thiết bị vật lý giúp giảm thiểu điểm lỗi đơn (single point of failure) — một yếu tố then chốt với các hệ thống cần độ sẵn sàng cao.

Thứ hai, triết lý "tự sở hữu giải pháp" tuy đòi hỏi đầu tư ban đầu lớn về nhân lực, lại mang lại sự linh hoạt mà các giải pháp đóng gói sẵn khó có thể đáp ứng khi hệ thống mở rộng. Đây là bài học đáng cân nhắc cho các đội hạ tầng tại Việt Nam đang ở giai đoạn tăng trưởng nhanh nhưng ngân sách còn hạn chế.