Giám sát mất gói tin và độ trễ mạng trên Roblox Cloud

Đội ngũ Kỹ thuật Mạng Roblox duy trì một mạng lưới lớn, đang phát triển nhanh chóng với các trung tâm dữ liệu và các điểm hiện diện (POP) phân bố trên toàn cầu. Việc mang lại trải nghiệm người dùng tuyệt vời trên nền tảng Roblox phụ thuộc vào hiệu suất và độ tin cậy của mạng lưới này. Điều quan trọng là các nhà điều hành mạng phải có khả năng khắc phục sự cố và phát hiện các vấn đề trong mạng, đồng thời có cái nhìn tổng quan về hiệu suất mạng. Việc giám sát mạng thường được thực hiện bằng cách thu thập định kỳ các số liệu thiết bị, chỉ số lỗi và nhật ký hệ thống (syslog), sau đó lưu trữ chúng trong cơ sở dữ liệu chuỗi thời gian hoặc cơ sở dữ liệu nhật ký. Dữ liệu được thu thập thông qua mô hình đẩy (push) hoặc kéo (pull) sử dụng các giao thức tiêu chuẩn như SNMP, Netconf, Rest APIs hoặc Streaming Telemetry.

Việc phát hiện sự cố mạng chỉ thông qua dữ liệu telemetry của thiết bị có một số hạn chế, vì đây là kỹ thuật giám sát thụ động. Nó phụ thuộc vào khả năng của các nút mạng trong việc nhận diện và báo cáo các tình huống bất thường ngay khi chúng xảy ra. Thiết bị có thể không luôn gửi lại dữ liệu hoặc, trong một số trường hợp, có thể không hiển thị đầy đủ các chỉ số sức khỏe của mình cho các phương pháp thu thập telemetry thông thường. Ngoài ra, các thiết bị mạng đôi khi có thể cung cấp dữ liệu sai lệch hoặc im lặng chặn lưu lượng truy cập. Một hạn chế lớn của dữ liệu từ xa thiết bị là nó cung cấp rất ít thông tin về khả năng kết nối đầu cuối, số gói tin bị mất và thống kê độ trễ của mạng.

Một cách tuyệt vời để giám sát mạng một cách chủ động là truyền các thăm dò tổng hợp thường xuyên qua mạng lưới như được mô tả trong các hình dưới đây.

Trong quá trình khắc phục sự cố ngừng hoạt động sản xuất, các nhà điều hành mạng thường nhận được những câu hỏi như: “Mạng có đang mất gói tin không?” hoặc “Có sự cố mạng nào đang diễn ra ảnh hưởng đến kết nối dịch vụ không?” Để trả lời những câu hỏi này mà không có dữ liệu lịch sử về mất gói tin và độ trễ, họ sẽ cần phải điều tra một tập hợp lớn các liên kết và nút trong mạng.

Thiết kế hệ thống giám sát mạng lưới đáng tin cậy và có khả năng mở rộng

Để hệ thống giám sát mạng dạng “hộp đen” có thể phát hiện mất gói tin hoặc đỉnh độ trễ một cách hiệu quả, nó cần thực hiện việc kiểm tra liên tục trên các phần khác nhau của mạng. Mạng trung tâm dữ liệu sử dụng tất cả các liên kết giữa các nút để truyền tải lưu lượng người dùng. Các thiết bị mạng sản xuất chạy BGP và cân bằng tải lưu lượng qua nhiều đường dẫn có chi phí bằng nhau. Các thay đổi trong cấu trúc mạng thường được phản ánh trong vòng vài giây thông qua việc cập nhật bảng định tuyến trong điều kiện bình thường. Để có được đo lường chính xác về mất gói tin mạng, các gói kiểm tra nên di chuyển qua càng nhiều đường dẫn càng tốt, bao phủ tất cả các nút và liên kết mạng. Với một mạng lớn như của chúng tôi, trải rộng qua nhiều địa điểm trên toàn cầu, việc kiểm tra giữa mọi cặp nút hoặc rack là không khả thi. Giải pháp bền vững mà chúng tôi đã chọn, không làm giảm mức độ hiển thị, là kiểm tra một mạng lưới N² giữa các rack trong mỗi địa điểm cùng với một mạng lưới N² khác giữa tất cả các địa điểm.

Chúng tôi sử dụng gì để kiểm tra mạng?

Các gói kiểm tra nên mô phỏng lưu lượng thực tế đi qua mạng sản xuất. Hầu hết lưu lượng trên mạng của chúng tôi là TCP, UDP hoặc HTTP, và mỗi giao thức này đều có thể được sử dụng cho các gói kiểm tra. Một trong những vấn đề với việc kiểm tra bằng TCP là nó không đủ nhẹ để mở rộng quy mô cho số lượng kết nối cần thiết để giám sát một mạng lớn. Một vấn đề khác với TCP là cơ chế kiểm soát luồng tích hợp và truyền dữ liệu dựa trên cửa sổ trượt dẫn đến tốc độ truyền của các công cụ kiểm tra thay đổi, điều này không lý tưởng để định lượng hoặc phát hiện các sự cố mất gói tin tạm thời. ICMP, được sử dụng bởi ping và traceroute, thường bị giới hạn tốc độ trên các máy chủ hoặc nút mạng. Điều này giới hạn tốc độ tổng hợp của các công cụ kiểm tra ICMP có thể được sử dụng. Yêu cầu HTTP nằm ở lớp ứng dụng cao hơn và phụ thuộc vào một số yếu tố bên ngoài mạng như hiệu suất máy chủ hoặc ứng dụng. HTTP thêm một yếu tố biến đổi vào kết quả, điều này khó tách biệt. Mục tiêu của hệ thống này là giám sát hiệu suất của hạ tầng mạng cơ sở chủ yếu hoạt động ở các lớp OSI 4 trở xuống. Chúng tôi chọn các gói tin UDP vì những lý do này, ngoài việc nó là giao thức lớp vận chuyển chính trên mạng của chúng tôi.

Chúng tôi thực hiện thăm dò từ đâu?

Một cách để đạt được tốc độ thăm dò tổng hợp cao và bao phủ nhiều đường dẫn mạng là sử dụng càng nhiều nút tính toán càng tốt để truyền các gói thăm dò. Điều này có hai lợi ích: giúp phân tán tải trên các hệ thống tạo ra các gói thăm dò và mở rộng số lượng cổng mạng truyền tải chúng. Tuy nhiên, điều này yêu cầu một trình đại lý (agent) rất ổn định và tiêu tốn ít tài nguyên hệ thống chủ nhất có thể. Đồng thời, tác nhân này phải có khả năng đo lường chính xác tình trạng mất gói tin và độ trễ trên nhiều đường dẫn mà không bị ảnh hưởng bởi sự dao động trong việc sử dụng CPU, bộ nhớ hoặc I/O trên hệ thống máy chủ. Tác nhân này phải liên tục duy trì sự cân bằng tinh tế giữa tính nhẹ nhàng và hiệu suất cao.

Làm thế nào để đo lường mất gói tin và độ trễ mạng?

Điều này có thể trông giống như một phép tính đơn giản trên một luồng probe duy nhất, tuy nhiên, có một số thách thức nảy sinh khi mở rộng quy mô mà không phải lúc nào cũng rõ ràng. Để mở rộng quy mô lên một mạng lưới lớn như vậy, trình đại lý cần tính toán nhanh chóng và chính xác số lượng gói tin truyền (Tx) và nhận (Rx) kèm theo dấu thời gian trên nhiều luồng đồng thời. Điều quan trọng là các chỉ số mất mát mạng không bao gồm các gói tin bị mất tại máy chủ chạy trình đại lý khi CPU của máy chủ bận hoặc bộ đệm mạng của máy chủ bị tràn. Độ trễ mạng cần được tính toán dựa trên tổng thời gian các gói tin thăm dò tồn tại trên đường truyền hoặc các nút mạng trung gian, đồng thời loại trừ thời gian chờ trong bộ đệm I/O và thời gian quá trình trình đại lý đang chờ lịch trình hệ điều hành.

Hệ thống Ping Mesh của Roblox

Nhu cầu giám sát mất mát và độ trễ mạng theo kiểu "hộp đen" đã tồn tại từ khi cơ sở hạ tầng đám mây công cộng và riêng tư phát triển. Việc tìm kiếm một giải pháp sẵn có có thể mở rộng quy mô phù hợp với mạng lưới lớn của chúng tôi đã chứng tỏ là rất khó khăn. Một số nhà cung cấp dịch vụ đám mây lớn và nhà cung cấp công cụ mạng đã thiết kế các giải pháp riêng của họ để giám sát mất mát và độ trễ mạng. Chúng tôi đã thử một số công cụ có sẵn trên thị trường, nhưng gặp phải vấn đề về tính ổn định và khả năng mở rộng, đồng thời chỉ có được cái nhìn hạn chế về hiệu suất mạng. Điều này đã dẫn chúng tôi đến việc xây dựng hệ thống giám sát lưới riêng, giúp phát hiện tốt hơn các lỗi tần suất thấp với chi phí hệ thống thấp. Một số điểm nổi bật của hệ thống chúng tôi là:

• Chúng tôi đã chọn Go để triển khai tất cả các thành phần của hệ thống và điều này đã giúp đạt được hiệu suất cao trong khi sử dụng tối thiểu tài nguyên hệ thống.
• Các agent của chúng tôi rất ổn định và có thể chạy trên nhiều loại máy chủ sản xuất khác nhau, bao gồm cả những máy chủ đang thực hiện các dịch vụ quan trọng trên nền tảng Roblox như máy chủ lưu lượng, máy chủ bộ nhớ đệm và máy chủ ứng dụng.
• Trình đại lý được tối ưu hóa để gộp các thao tác I/O gói tin thông qua các hàm bọc Go trên các hàm hệ thống Linux sendmmsg() và recvmmsg(), cho phép nó truyền tải các gói tin kiểm tra với tần suất cao và chi phí hệ thống thấp. Mỗi trình đại lý trong triển khai của chúng tôi đồng thời truyền các gói tin kiểm tra đến tối đa 100 máy chủ khác, với tốc độ 100 gói tin mỗi giây (PPS). Trình đại lý truyền các đợt gói tin mỗi giây đến từng đích đến.
• Các gói thăm dò mang các giá trị trường Loại Dịch vụ (TOS) khác nhau trong tiêu đề IP đến từng đích và được tính toán riêng biệt về mất gói và độ trễ trên mạng. Mỗi đợt gói bao gồm sự kết hợp của nhiều giá trị TOS khác nhau đến mọi đích khác. Điều này giúp theo dõi hiệu suất mạng cho các lớp Chất lượng Dịch vụ (QoS) khác nhau.
• Trình đại lý có thể phát hiện các sự cố mất gói dữ liệu thấp đến mức 1 trên 6000 gói dữ liệu mỗi phút trên mỗi đường dẫn thăm dò. Mất gói dữ liệu trong lõi hoặc biên của mạng kéo dài dưới 1 giây có thể được phát hiện, chẳng hạn như trong trường hợp BGP flap.
• Biểu đồ mất gói tin của đầu dò giống với biểu đồ tỷ lệ lỗi giao diện thiết bị mạng khi các lỗi này là nguyên nhân gây ra sự mất gói tin. Chúng tôi đã phát hiện ra các lỗi black-holing lưu lượng trong mạng mà rất khó phát hiện.
• Các agent sử dụng dấu thời gian đọc của kernel NIC để đạt độ chính xác cao trong đo lường độ trễ mạng. Độ trễ khứ hồi nội bộ site ổn định trong khoảng 50–100 microgiây có thể được đo lường, loại trừ độ trễ lịch trình hệ điều hành máy chủ và sự chênh lệch đồng hồ mạng.
• Sử dụng CPU và bộ nhớ thấp. Trình đại lý sử dụng ít hơn 25% của một lõi CPU ở tốc độ truyền và nhận đỉnh (5 kpps mỗi chiều). Hầu hết các trình đại lý triển khai chỉ sử dụng khoảng 5% của một lõi. Chỉ cần 10MB bộ nhớ heap để quản lý bộ đệm gói tin và bộ đếm truyền/nhận của trình đại lý. Khi mạng mở rộng, chúng tôi có thể mở rộng theo chiều dọc hoặc ngang bằng cách điều chỉnh giới hạn hoặc thêm các trình đại lý bổ sung.
• Trình đại lý hiếm khi bị ảnh hưởng khi hệ thống máy chủ gặp áp lực. Chúng tôi đã thu được kết quả chính xác ngay cả khi tải CPU của máy chủ đạt gần 99% trong một số trường hợp.
• Dữ liệu telemetry được thu thập từ mỗi agent để theo dõi tình trạng hoạt động của chúng. Các agent có thể phát hiện các tình huống bất thường như khi hệ thống chủ khởi động lại, khi quá trình agent khởi động lại, hoặc khi gói tin bị mất do bộ đệm socket tràn.

Các agent được triển khai bằng Chef trên một tập hợp rộng các cụm máy chủ để duy trì số lượng lớn các nút tham gia vào việc kiểm tra mạng. Tệp nhị phân của agent được chạy và quản lý bằng systemd trên Linux để nó được tự động khởi động lại sau khi hệ thống chủ khởi động lại hoặc nâng cấp agent. Trình điều phối mạng lưới (mesh scheduler) phát hiện và điều chỉnh các luồng dữ liệu một cách động khi cần thiết khi bất kỳ agent nào ngừng hoạt động hoặc có agent mới được triển khai. Ứng dụng trình điều phối của chúng tôi định kỳ kiểm tra danh sách thiết bị và hệ thống phát hiện dịch vụ để phát hiện các đại lý mới và trạng thái sức khỏe của máy chủ trước khi phân bổ mục tiêu cho việc kiểm tra Intra-Pod, Intra-Site và Inter-Site. Một bus tin nhắn được sử dụng để truyền danh sách máy chủ mục tiêu đến từng tác nhân đang truyền các lệnh kiểm tra. Các luồng riêng lẻ bắt nguồn hoặc kết thúc tại một giá đỡ cụ thể được phân phối giữa tất cả các tác nhân có sẵn trong giá đỡ đó. Điều này giúp chúng tôi thực hiện một lượng lớn các đường dẫn có chi phí bằng nhau trong cấu trúc mạng của mình, như được thể hiện trong các hình dưới đây.

Chúng tôi bắt đầu với 150 thiết bị trong lần triển khai đầu tiên và hiện đã mở rộng thành công gấp 10 lần. Mạng lưới này bao phủ hệ thống mạng chính của chúng tôi, kết nối 25 địa điểm trải rộng khắp toàn cầu. Tại một trong những trung tâm dữ liệu chính của chúng tôi, chúng tôi có một mạng lưới nội bộ bao phủ hơn 200 giá đỡ với khoảng 33.000 luồng, tổng hợp thành tốc độ thăm dò 1,65 Mpps. Mỗi giá đỡ nhận được 5–10 kpps thăm dò từ các giá đỡ khác. Ứng dụng lập lịch tính toán và phân phối đồng đều hơn 35.000 mục tiêu trên tất cả các tác nhân của chúng tôi ở các địa điểm khác nhau.

Thu thập và hiển thị dữ liệu

Chúng tôi chạy một ứng dụng thu thập dữ liệu riêng biệt, định kỳ kiểm tra tất cả các agent Ping Mesh để thu thập kết quả mất gói tin và độ trễ. Dữ liệu này được lọc tự động để loại trừ các kết quả không hợp lệ dựa trên trạng thái sức khỏe được lưu trữ cục bộ tại máy thu thập. Ví dụ, chúng tôi loại trừ kết quả từ một agent chạy trên máy chủ không phản hồi kiểm tra sức khỏe hoặc máy chủ vừa khởi động lại. Ứng dụng thu thập dữ liệu của chúng tôi có thể thu thập và lọc kết quả từ hơn 1.500 nút một cách đồng bộ, sau đó nhập dữ liệu vào cơ sở dữ liệu chuỗi thời gian trong vòng 2 giây.

Cả kết quả tổng hợp và theo luồng đều được trực quan hóa thông qua các bảng điều khiển Grafana. Các lưới bản đồ nhiệt (heatmap) có thể khó sử dụng với tập dữ liệu lớn, đặc biệt là tại trung tâm dữ liệu quy mô lớn của chúng tôi. Chúng tôi sử dụng truy vấn Prometheus topk() để hiển thị các đường dẫn có tỷ lệ mất gói tin cao nhất trong số hàng nghìn kết quả, thường chỉ là một vài trường hợp. Các kết quả được kiểm tra kỹ lưỡng so với các số liệu về tình trạng hệ thống của máy chủ và máy khách, được bộ thu thập dữ liệu thăm dò thường xuyên. Điều này mang lại cho chúng tôi mức độ tin cậy cao đối với từng kết quả riêng lẻ, bất kể sự biến động của tỷ lệ mất gói tin lớn đến đâu. Khi xem xét tổng thể các kết quả riêng lẻ, chúng tôi có thể tìm ra manh mối về vị trí xảy ra sự cố mạng. Một số ví dụ về mất gói tin được hệ thống giám sát mạng lưới của chúng tôi phát hiện được hiển thị dưới đây.

Tóm tắt và các bước tiếp theo

Hệ thống Ping Mesh của chúng tôi là một công cụ mạnh mẽ giúp đội ngũ Kỹ thuật Mạng theo dõi tình trạng mất gói tin và độ trễ từ đầu đến cuối. Dữ liệu này có thể được sử dụng để trả lời ngay lập tức câu hỏi: “Mạng có đang làm mất gói tin không?” Dựa trên kinh nghiệm của chúng tôi, các sự cố mạng lớn ảnh hưởng đến khách hàng thường được phát hiện và cảnh báo bởi hệ thống giám sát từ xa của thiết bị. Các vấn đề ít ảnh hưởng nhưng có khả năng gây ra sự cố liên quan đến bộ đệm mạng hoặc lưu lượng truy cập bị cô lập được phát hiện nhờ hệ thống này.

Hệ thống của chúng tôi cũng cung cấp thông tin chi tiết về độ tin cậy tổng thể của Mạng đám mây Roblox. Tại một trong những trung tâm dữ liệu chính của chúng tôi, chúng tôi có hơn 100 triệu lần kiểm tra mỗi phút để theo dõi tình trạng mạng và hiếm khi gặp số lượng gói tin bị mất vượt quá 50 gói mỗi phút. Điều này cho thấy độ tin cậy khoảng 6 chữ số 9 (99,9999%) từ mạng trung tâm dữ liệu của chúng tôi. Rất thường xuyên, không có gói tin nào bị mất trong số 100 triệu gói tin. Khi có một lượng lớn gói tin bị mất, hệ thống này cung cấp thông tin về vị trí và thời gian xảy ra sự cố mất gói tin. Một động cơ tự phục hồi tự động khắc phục sự cố mạng và ngăn chặn lưu lượng người dùng gặp phải các sự cố mất gói tin tiếp theo bằng cách chuyển hướng lưu lượng qua một đường dẫn khác trong mạng. Đội ngũ Mạng tại Roblox đã xây dựng một mạng đám mây cực kỳ đáng tin cậy.

Trong tương lai, chúng tôi dự định sử dụng một công cụ phân tích để liên kết dữ liệu từ telemetry thiết bị, syslogs và các tập dữ liệu khác. Sau đó, chúng tôi dự định so sánh dữ liệu đó với dữ liệu Ping Mesh để giúp xác định chính xác vị trí xảy ra sự cố mạng. Khi mạng đám mây của Roblox tiếp tục mở rộng và phát triển, chúng tôi dự định nâng cấp các cơ chế giám sát để bao gồm IPv6 và khung jumbo, đồng thời thêm nhiều agent hơn để tăng cường phạm vi phủ sóng giữa các site.