Các trung tâm dữ liệu hiện đại được cài đặt hàng trăm thiết bị đang hoạt động, được bao phủ bởi các loại giám sát khác nhau. Nhưng ngay cả một kỹ sư lý tưởng với khả năng giám sát hoàn hảo trong tay cũng có thể phản hồi chính xác khi mạng bị lỗi chỉ trong vài phút. Trong một báo cáo tại hội nghị Next Hop 2020, tôi đã trình bày một phương pháp thiết kế mạng trung tâm dữ liệu, có một tính năng độc đáo - trung tâm dữ liệu tự phục hồi trong một phần nghìn giây. Chính xác hơn, kỹ sư bình tĩnh khắc phục sự cố, trong khi các dịch vụ không nhận thấy điều đó.
Đối với nhiều kỹ sư mạng, tất nhiên, mạng trung tâm dữ liệu bắt đầu bằng ToR, bằng một công tắc trên giá đỡ. ToR thường có hai loại liên kết. Những cái nhỏ đi đến máy chủ, những cái khác - có số lượng gấp N lần - đi về phía các gai của cấp độ đầu tiên, tức là tới các liên kết lên của nó. Các liên kết lên thường được coi là bằng nhau và lưu lượng giữa các liên kết lên được cân bằng dựa trên hàm băm từ 5 bộ, bao gồm proto, src_ip, dst_ip, src_port, dst_port. Không có gì ngạc nhiên ở đây.
Tiếp theo, kiến trúc quy hoạch trông như thế nào? Các gai ở cấp độ đầu tiên không được kết nối với nhau mà được kết nối thông qua các siêu gai. Chữ X sẽ chịu trách nhiệm cho các siêu gai, nó gần giống như một kết nối chéo.
Và mặt khác, rõ ràng là tori được kết nối với tất cả các gai ở cấp độ đầu tiên. Điều gì quan trọng trong bức tranh này? Nếu chúng ta có sự tương tác bên trong giá đỡ, thì sự tương tác đó tất nhiên sẽ thông qua ToR. Nếu tương tác xảy ra bên trong mô-đun thì tương tác sẽ xảy ra thông qua các gai cấp độ đầu tiên. Nếu tương tác là đa môđun - như ở đây, ToR 1 và ToR 2 - thì tương tác sẽ đi qua các gai của cả cấp độ thứ nhất và thứ hai.
Về lý thuyết, kiến trúc như vậy có thể dễ dàng mở rộng. Nếu chúng ta có công suất cổng, không gian trống trong trung tâm dữ liệu và cáp quang được bố trí sẵn thì số làn đường luôn có thể tăng lên, từ đó tăng công suất chung của hệ thống. Điều này rất dễ thực hiện trên giấy. Trong cuộc sống nó sẽ như thế này. Nhưng câu chuyện hôm nay không phải về điều đó.
Tôi muốn những kết luận đúng đắn được rút ra. Chúng tôi có nhiều đường dẫn bên trong trung tâm dữ liệu. Họ độc lập có điều kiện. Một đường dẫn bên trong trung tâm dữ liệu chỉ có thể có bên trong ToR. Bên trong mô-đun, chúng ta có số lượng đường đi bằng số làn đường. Số lượng đường đi giữa các mô-đun bằng tích của số mặt phẳng và số lượng siêu trục trong mỗi mặt phẳng. Để rõ ràng hơn, để hiểu được quy mô, tôi sẽ đưa ra những con số hợp lệ cho một trong các trung tâm dữ liệu Yandex.
Có tám mặt phẳng, mỗi mặt phẳng có 32 siêu gai. Kết quả là, hóa ra có tám đường dẫn bên trong mô-đun và với sự tương tác giữa các mô-đun thì đã có 256 đường dẫn trong số đó.
Nghĩa là, nếu chúng ta đang phát triển Cookbook, cố gắng học cách xây dựng các trung tâm dữ liệu có khả năng chịu lỗi và tự phục hồi, thì kiến trúc phẳng là lựa chọn đúng đắn. Nó giải quyết vấn đề mở rộng quy mô và về mặt lý thuyết thì rất dễ dàng. Có nhiều con đường độc lập. Câu hỏi vẫn là: làm thế nào một kiến trúc như vậy tồn tại được sau những thất bại? Có nhiều thất bại khác nhau. Và chúng ta sẽ thảo luận về điều này ngay bây giờ.
Hãy để một trong những siêu gai của chúng ta “bị bệnh”. Ở đây tôi quay trở lại kiến trúc hai mặt phẳng. Chúng tôi sẽ lấy những điều này làm ví dụ vì đơn giản là sẽ dễ dàng hơn để xem điều gì đang xảy ra với ít bộ phận chuyển động hơn. Hãy để X11 bị bệnh. Điều này sẽ ảnh hưởng như thế nào đến các dịch vụ bên trong trung tâm dữ liệu? Rất nhiều điều phụ thuộc vào việc thất bại thực sự trông như thế nào.
Nếu lỗi tốt, nó được phát hiện ở mức độ tự động hóa của cùng một BFD, việc tự động hóa vui vẻ đặt các khớp có vấn đề và cô lập vấn đề, thì mọi thứ đều ổn. Chúng tôi có nhiều đường dẫn, giao thông ngay lập tức được định tuyến lại sang các tuyến đường thay thế và các dịch vụ sẽ không nhận thấy bất kỳ điều gì. Đây là một kịch bản hay.
Một kịch bản xấu là nếu chúng ta liên tục thua lỗ và quá trình tự động hóa không nhận thấy vấn đề. Để hiểu điều này ảnh hưởng như thế nào đến một ứng dụng, chúng ta sẽ phải dành một chút thời gian để thảo luận về cách thức hoạt động của TCP.
Tôi hy vọng tôi không gây sốc cho bất kỳ ai với thông tin này: TCP là một giao thức xác nhận việc truyền tải. Nghĩa là, trong trường hợp đơn giản nhất, người gửi gửi hai gói và nhận được một xác nhận tích lũy trên chúng: “Tôi đã nhận được hai gói”.
Sau đó, anh ta sẽ gửi thêm hai gói tin nữa và tình trạng này sẽ lặp lại. Tôi xin lỗi trước vì một số đơn giản hóa. Kịch bản này đúng nếu cửa sổ (số gói trong chuyến bay) là hai. Tất nhiên, trong trường hợp tổng quát điều này không nhất thiết phải như vậy. Nhưng kích thước cửa sổ không ảnh hưởng đến bối cảnh chuyển tiếp gói.
Điều gì xảy ra nếu chúng ta mất gói 3? Trong trường hợp này, người nhận sẽ nhận được gói 1, 2 và 4. Và anh ta sẽ thông báo rõ ràng cho người gửi bằng tùy chọn SACK: “Bạn biết đấy, ba gói đã đến, nhưng gói giữa đã bị mất”. Anh ấy nói, "Ack 2, SACK 4."
Tại thời điểm này, người gửi sẽ lặp lại chính xác gói bị mất mà không gặp bất kỳ sự cố nào.
Nhưng nếu gói cuối cùng trong cửa sổ bị mất, tình hình sẽ hoàn toàn khác.
Người nhận nhận được ba gói đầu tiên và trước hết bắt đầu chờ đợi. Nhờ một số tối ưu hóa trong ngăn xếp TCP của nhân Linux, nó sẽ đợi một gói được ghép nối trừ khi các cờ chỉ rõ rằng đó là gói cuối cùng hoặc thứ gì đó tương tự. Nó sẽ đợi cho đến khi hết thời gian chờ ACK bị trì hoãn và sau đó gửi xác nhận cho ba gói đầu tiên. Nhưng bây giờ người gửi sẽ đợi. Anh ta không biết gói thứ tư đã bị thất lạc hay sắp đến. Và để không làm mạng bị quá tải, nó sẽ cố gắng đợi một dấu hiệu rõ ràng rằng gói bị mất hoặc khi hết thời gian chờ RTO.
Thời gian chờ RTO là gì? Đây là mức RTT tối đa được tính toán bởi ngăn xếp TCP và một số hằng số. Đây là loại hằng số gì, bây giờ chúng ta sẽ thảo luận.
Nhưng điều quan trọng là nếu chúng ta lại không may mắn và gói thứ tư lại bị mất thì RTO sẽ tăng gấp đôi. Nghĩa là, mỗi lần thử không thành công đồng nghĩa với việc tăng gấp đôi thời gian chờ.
Bây giờ chúng ta hãy xem cơ sở này bằng bao nhiêu. Theo mặc định, RTO tối thiểu là 200 ms. Đây là RTO tối thiểu cho các gói dữ liệu. Đối với gói SYN thì khác, 1 giây. Như bạn có thể thấy, ngay cả lần thử gửi lại gói đầu tiên cũng sẽ mất nhiều thời gian hơn 100 lần so với RTT bên trong trung tâm dữ liệu.
Bây giờ hãy quay lại kịch bản của chúng tôi. Chuyện gì đang xảy ra với dịch vụ vậy? Dịch vụ bắt đầu mất gói. Hãy để dịch vụ may mắn có điều kiện lúc đầu và mất thứ gì đó ở giữa cửa sổ, sau đó nó nhận được SACK và gửi lại các gói bị mất.
Nhưng nếu vận rủi lặp lại thì chúng ta có RTO. Điều gì quan trọng ở đây? Có, chúng tôi có rất nhiều đường dẫn trong mạng lưới của mình. Nhưng lưu lượng TCP của một kết nối TCP cụ thể sẽ tiếp tục đi qua cùng một ngăn xếp bị hỏng. Mất gói, với điều kiện chiếc X11 kỳ diệu này của chúng tôi không tự tắt, không dẫn đến lưu lượng truy cập chảy vào các khu vực không có vấn đề gì. Chúng tôi đang cố gắng phân phối gói tin qua cùng một ngăn xếp bị hỏng. Điều này dẫn đến lỗi xếp tầng: trung tâm dữ liệu là một tập hợp các ứng dụng tương tác và một số kết nối TCP của tất cả các ứng dụng này bắt đầu xuống cấp - vì superspine thường ảnh hưởng đến tất cả các ứng dụng bên trong trung tâm dữ liệu. Tục ngữ có câu: không đánh móng ngựa thì ngựa bị què; con ngựa bị què - báo cáo không được gửi; báo cáo không được gửi - chúng tôi đã thua trong cuộc chiến. Ở đây chỉ tính bằng giây kể từ thời điểm sự cố phát sinh cho đến giai đoạn xuống cấp mà dịch vụ bắt đầu cảm nhận được. Điều này có nghĩa là người dùng có thể đang bỏ lỡ điều gì đó ở đâu đó.
Có hai giải pháp cổ điển bổ sung cho nhau. Đầu tiên là các dịch vụ đang cố gắng đưa ống hút vào và giải quyết vấn đề như thế này: “Hãy điều chỉnh thứ gì đó trong ngăn xếp TCP. Hãy đặt thời gian chờ ở cấp ứng dụng hoặc các phiên TCP tồn tại lâu dài bằng kiểm tra tình trạng nội bộ.” Vấn đề là các giải pháp như vậy: a) hoàn toàn không mở rộng quy mô; b) được kiểm tra rất kém. Nghĩa là, ngay cả khi dịch vụ vô tình định cấu hình ngăn xếp TCP theo cách làm cho nó tốt hơn, thứ nhất, nó khó có thể áp dụng được cho tất cả các ứng dụng và tất cả các trung tâm dữ liệu, và thứ hai, rất có thể, nó sẽ không hiểu rằng nó đã được thực hiện. đúng và cái gì không. Tức là nó hoạt động nhưng hoạt động kém và không mở rộng quy mô. Và nếu mạng có vấn đề thì ai là người chịu trách nhiệm? Tất nhiên là NOC. NOC làm gì?
Nhiều dịch vụ tin rằng công việc của NOC sẽ xảy ra như thế này. Nhưng thành thật mà nói, không chỉ có vậy.
NOC trong sơ đồ cổ điển tham gia vào việc phát triển nhiều hệ thống giám sát. Đây là cả giám sát hộp đen và hộp trắng. Về một ví dụ về giám sát cột sống hộp đen Alexander Klimenko tại Next Hop cuối cùng. Nhân tiện, việc giám sát này có tác dụng. Nhưng ngay cả việc giám sát lý tưởng cũng sẽ có độ trễ về thời gian. Thông thường đây là một vài phút. Sau khi nó tắt, các kỹ sư đang làm nhiệm vụ cần thời gian để kiểm tra lại hoạt động của nó, khoanh vùng sự cố và sau đó dập tắt khu vực có sự cố. Nghĩa là, trong trường hợp tốt nhất, việc xử lý sự cố mất 5 phút, trong trường hợp xấu nhất là 20 phút, nếu không xác định được ngay vị trí xảy ra tổn thất. Rõ ràng là trong suốt thời gian này - 5 hoặc 20 phút - các dịch vụ của chúng tôi sẽ tiếp tục gặp khó khăn, điều này có thể là không tốt.
Bạn thực sự muốn nhận được điều gì? Chúng ta có rất nhiều cách. Và vấn đề phát sinh chính xác là do các luồng TCP không may mắn vẫn tiếp tục sử dụng cùng một tuyến đường. Chúng tôi cần thứ gì đó cho phép chúng tôi sử dụng nhiều tuyến trong một kết nối TCP. Có vẻ như chúng ta có một giải pháp. Có TCP, được gọi là TCP đa đường, nghĩa là TCP cho nhiều đường dẫn. Đúng vậy, nó được phát triển cho một nhiệm vụ hoàn toàn khác - dành cho điện thoại thông minh có nhiều thiết bị mạng. Để tối đa hóa quá trình truyền hoặc tạo chế độ chính/sao lưu, một cơ chế đã được phát triển nhằm tạo ra nhiều luồng (phiên) một cách minh bạch cho ứng dụng và cho phép bạn chuyển đổi giữa chúng trong trường hợp xảy ra lỗi. Hoặc, như tôi đã nói, hãy tối đa hóa chuỗi trận.
Nhưng có một sắc thái ở đây. Để hiểu nó là gì, chúng ta sẽ phải xem các luồng được thiết lập như thế nào.
Chủ đề được cài đặt tuần tự. Chủ đề đầu tiên được cài đặt đầu tiên. Sau đó, các luồng tiếp theo sẽ được đặt bằng cách sử dụng cookie đã được thống nhất trong luồng đó. Và đây là vấn đề.
Vấn đề là nếu luồng đầu tiên không tự thiết lập thì luồng thứ hai và thứ ba sẽ không bao giờ phát sinh. Nghĩa là, TCP đa đường không giải quyết được việc mất gói SYN trong luồng đầu tiên. Và nếu SYN bị mất, TCP đa đường sẽ chuyển thành TCP thông thường. Điều này có nghĩa là trong môi trường trung tâm dữ liệu, nó sẽ không giúp chúng ta giải quyết vấn đề thất thoát trong nhà máy và học cách sử dụng nhiều đường dẫn trong trường hợp xảy ra lỗi.
Điều gì có thể giúp chúng tôi? Một số bạn đã đoán được từ tiêu đề rằng một trường quan trọng trong câu chuyện tiếp theo của chúng ta sẽ là trường tiêu đề nhãn luồng IPv6. Quả thực đây là trường xuất hiện ở v6 chứ không phải ở v4, nó chiếm 20 bit và đã có nhiều tranh cãi về việc sử dụng nó từ lâu. Điều này rất thú vị - đã có những tranh chấp, một cái gì đó đã được sửa trong RFC, đồng thời một triển khai xuất hiện trong nhân Linux, không được ghi lại ở bất kỳ đâu.
Tôi mời bạn cùng tôi đi điều tra một chút. Chúng ta hãy xem những gì đã xảy ra trong nhân Linux trong vài năm qua.
năm 2014. Một kỹ sư từ một công ty lớn và có uy tín bổ sung thêm chức năng của nhân Linux vào sự phụ thuộc của giá trị nhãn luồng vào hàm băm ổ cắm. Họ đang cố gắng khắc phục điều gì ở đây? Điều này liên quan đến RFC 6438, thảo luận về vấn đề sau. Bên trong trung tâm dữ liệu, IPv4 thường được gói gọn trong các gói IPv6, vì bản thân nhà máy là IPv6 nhưng IPv4 bằng cách nào đó phải được đưa ra bên ngoài. Trong một thời gian dài, có vấn đề với các switch không thể nhìn dưới hai tiêu đề IP để truy cập TCP hoặc UDP và tìm src_ports, dst_ports ở đó. Hóa ra hàm băm, nếu bạn nhìn vào hai tiêu đề IP đầu tiên, hóa ra gần như đã được sửa. Để tránh điều này, để việc cân bằng lưu lượng được đóng gói này hoạt động chính xác, người ta đã đề xuất thêm hàm băm của gói được đóng gói 5 bộ vào giá trị của trường nhãn luồng. Điều tương tự cũng được thực hiện đối với các sơ đồ đóng gói khác, đối với UDP, đối với GRE, GRE sử dụng trường Khóa GRE. Bằng cách này hay cách khác, các mục tiêu ở đây đều rõ ràng. Và ít nhất tại thời điểm đó chúng rất hữu ích.
Vào năm 2015, một bản vá mới đến từ cùng một kỹ sư đáng kính. Anh ấy rất thú vị. Nó nói như sau - chúng tôi sẽ chọn ngẫu nhiên hàm băm trong trường hợp có sự kiện định tuyến tiêu cực. Sự kiện định tuyến tiêu cực là gì? Đây là RTO mà chúng ta đã thảo luận trước đó, tức là việc mất phần đuôi cửa sổ là một sự kiện thực sự tiêu cực. Đúng, tương đối khó để đoán rằng đây là nó.
2016, một công ty uy tín khác, cũng lớn. Nó tháo rời những chiếc nạng cuối cùng và làm cho hàm băm mà trước đây chúng tôi đã tạo ngẫu nhiên giờ thay đổi cho mỗi lần truyền lại SYN và sau mỗi lần hết thời gian chờ RTO. Và trong bức thư này, lần đầu tiên và cũng là lần cuối cùng, mục tiêu cuối cùng được nêu rõ - để đảm bảo rằng lưu lượng truy cập trong trường hợp bị mất hoặc tắc nghẽn kênh có khả năng được định tuyến lại một cách nhẹ nhàng và sử dụng nhiều đường dẫn. Tất nhiên, sau này đã có rất nhiều ấn phẩm, bạn có thể dễ dàng tìm thấy chúng.
Mặc dù không, nhưng bạn không thể, vì chưa có một ấn phẩm nào về chủ đề này. Nhưng chúng tôi biết!
Và nếu bạn chưa hiểu hết những gì đã được thực hiện, tôi sẽ nói cho bạn biết ngay bây giờ.
Điều gì đã được thực hiện, chức năng nào đã được thêm vào nhân Linux? txhash thay đổi thành giá trị ngẫu nhiên sau mỗi sự kiện RTO. Đây là kết quả rất tiêu cực của việc định tuyến. Hàm băm phụ thuộc vào txhash này và nhãn luồng phụ thuộc vào hàm băm skb. Có một số tính toán về chức năng ở đây, tất cả các chi tiết không thể được đặt trên một slide. Nếu ai tò mò, bạn có thể xem qua mã kernel và kiểm tra.
Điều gì quan trọng ở đây? Giá trị của trường nhãn luồng thay đổi thành một số ngẫu nhiên sau mỗi RTO. Điều này ảnh hưởng đến luồng TCP không may của chúng tôi như thế nào?
Nếu xảy ra SACK, không có gì thay đổi vì chúng tôi đang cố gắng gửi lại gói đã biết bị mất. Càng xa càng tốt.
Nhưng trong trường hợp RTO, với điều kiện là chúng ta đã thêm nhãn luồng vào hàm băm trên ToR, lưu lượng có thể đi theo một tuyến khác. Và càng có nhiều làn đường thì khả năng tìm được đường đi không bị ảnh hưởng do lỗi trên một thiết bị cụ thể càng lớn.
Một vấn đề vẫn còn - RTO. Tất nhiên, có một con đường khác, nhưng sẽ lãng phí rất nhiều thời gian cho việc này. 200 ms là rất nhiều. Một giây là hoàn toàn hoang dã. Trước đây, tôi đã nói về thời gian chờ mà dịch vụ được định cấu hình. Vì vậy, giây là thời gian chờ, thường được dịch vụ định cấu hình ở cấp ứng dụng và trong trường hợp này, dịch vụ thậm chí sẽ tương đối đúng. Hơn nữa, tôi nhắc lại, RTT thực sự bên trong một trung tâm dữ liệu hiện đại là khoảng 1 mili giây.
Bạn có thể làm gì với thời gian chờ RTO? Thời gian chờ, chịu trách nhiệm cho RTO trong trường hợp mất gói dữ liệu, có thể được cấu hình tương đối dễ dàng từ không gian người dùng: có một tiện ích IP và một trong các tham số của nó chứa cùng rto_min. Tất nhiên, xét rằng RTO cần phải được điều chỉnh không phải trên toàn cầu, nhưng đối với các tiền tố nhất định, cơ chế như vậy có vẻ khá khả thi.
Đúng, với SYN_RTO mọi thứ có phần tệ hơn. Nó được đóng đinh một cách tự nhiên. Kernel có giá trị cố định là 1 giây, thế là xong. Bạn không thể đến đó từ không gian người dùng. Chỉ co một cach duy nhât.
eBPF đến giải cứu. Nói một cách đơn giản, đây là những chương trình C. Chúng có thể được chèn vào các hook ở những vị trí khác nhau khi thực thi ngăn xếp kernel và ngăn xếp TCP, nhờ đó bạn có thể thay đổi một số lượng rất lớn cài đặt. Nhìn chung, eBPF là một xu hướng dài hạn. Thay vì cắt giảm hàng tá tham số sysctl mới và mở rộng tiện ích IP, phong trào đang hướng tới eBPF và mở rộng chức năng của nó. Sử dụng eBPF, bạn có thể tự động thay đổi các biện pháp kiểm soát tắc nghẽn và nhiều cài đặt TCP khác.
Nhưng điều quan trọng đối với chúng tôi là nó có thể được sử dụng để thay đổi các giá trị SYN_RTO. Hơn nữa, có một ví dụ được đăng công khai: . Những gì đã được thực hiện ở đây? Ví dụ này đang hoạt động nhưng bản thân nó rất thô. Ở đây giả định rằng bên trong trung tâm dữ liệu, chúng ta so sánh 44 bit đầu tiên, nếu chúng khớp nhau thì chúng ta đang ở bên trong trung tâm dữ liệu. Và trong trường hợp này, chúng tôi thay đổi giá trị thời gian chờ SYN_RTO thành 4ms. Nhiệm vụ tương tự có thể được thực hiện một cách thanh lịch hơn nhiều. Nhưng ví dụ đơn giản này cho thấy điều này a) có thể xảy ra; b) tương đối đơn giản.
Chúng ta đã biết gì rồi? Thực tế là kiến trúc mặt phẳng cho phép mở rộng quy mô, hóa ra nó cực kỳ hữu ích cho chúng tôi khi chúng tôi kích hoạt nhãn luồng trên ToR và có khả năng di chuyển xung quanh các khu vực có vấn đề. Cách tốt nhất để giảm giá trị RTO và SYN-RTO là sử dụng các chương trình eBPF. Câu hỏi vẫn là: sử dụng nhãn luồng để cân bằng có an toàn không? Và có một sắc thái ở đây.
Giả sử bạn có một dịch vụ trên mạng hoạt động ở chế độ Anycast. Thật không may, tôi không có thời gian để đi sâu vào chi tiết về Anycast là gì, nhưng nó là một dịch vụ phân tán với các máy chủ vật lý khác nhau có thể truy cập qua cùng một địa chỉ IP. Và đây là một vấn đề có thể xảy ra: sự kiện RTO có thể xảy ra không chỉ khi lưu lượng truy cập đi qua kết cấu. Nó cũng có thể xảy ra ở cấp độ bộ đệm ToR: khi một sự kiện incast xảy ra, nó thậm chí có thể xảy ra trên máy chủ khi máy chủ làm đổ thứ gì đó. Khi một sự kiện RTO xảy ra và nó thay đổi nhãn luồng. Trong trường hợp này, lưu lượng truy cập có thể đi đến một phiên bản Anycast khác. Giả sử đây là một Anycast có trạng thái, nó chứa trạng thái kết nối - nó có thể là Bộ cân bằng L3 hoặc một số dịch vụ khác. Sau đó, một vấn đề phát sinh, vì sau RTO, kết nối TCP đến máy chủ, máy chủ không biết gì về kết nối TCP này. Và nếu chúng tôi không chia sẻ trạng thái giữa các máy chủ Anycast thì lưu lượng truy cập đó sẽ bị giảm và kết nối TCP sẽ bị hỏng.
Bạn có thể làm gì ở đây? Trong môi trường được kiểm soát của bạn, nơi bạn kích hoạt cân bằng nhãn luồng, bạn cần ghi lại giá trị của nhãn luồng khi truy cập máy chủ Anycast. Cách dễ nhất là thực hiện việc này thông qua cùng một chương trình eBPF. Nhưng đây là một điểm rất quan trọng - phải làm gì nếu bạn không vận hành mạng trung tâm dữ liệu mà là nhà khai thác viễn thông? Đây cũng là vấn đề của bạn: bắt đầu với một số phiên bản nhất định của Juniper và Arista, chúng bao gồm nhãn luồng trong hàm băm theo mặc định - thành thật mà nói, vì một lý do mà tôi không rõ ràng. Điều này có thể khiến bạn mất kết nối TCP từ những người dùng đi qua mạng của bạn. Vì vậy, tôi thực sự khuyên bạn nên kiểm tra cài đặt bộ định tuyến của mình tại đây.
Bằng cách này hay cách khác, đối với tôi, có vẻ như chúng ta đã sẵn sàng chuyển sang thử nghiệm.
Khi chúng tôi kích hoạt nhãn luồng trên ToR, chuẩn bị tác nhân eBPF, hiện đang tồn tại trên máy chủ, chúng tôi quyết định không chờ đợi sự cố lớn tiếp theo mà tiến hành các vụ nổ có kiểm soát. Chúng tôi đã sử dụng ToR, có bốn liên kết lên và thiết lập các phần thả xuống trên một trong số chúng. Họ đưa ra một quy tắc và nói - bây giờ bạn đang mất tất cả các gói. Như bạn có thể thấy ở bên trái, chúng tôi có tính năng giám sát từng gói, tỷ lệ này đã giảm xuống còn 75%, tức là 25% gói bị mất. Bên phải là biểu đồ các dịch vụ đằng sau Điều khoản này. Về cơ bản, đây là biểu đồ lưu lượng truy cập của các giao diện với máy chủ bên trong giá đỡ. Như bạn có thể thấy, chúng thậm chí còn chìm xuống thấp hơn. Tại sao họ giảm thấp hơn - không phải 25%, mà trong một số trường hợp là 3-4 lần? Nếu kết nối TCP không may mắn, nó sẽ tiếp tục cố gắng đi qua điểm nối bị hỏng. Điều này càng trở nên trầm trọng hơn do hành vi điển hình của dịch vụ bên trong DC - đối với một yêu cầu của người dùng, N yêu cầu đối với các dịch vụ nội bộ được tạo ra và phản hồi sẽ đến tay người dùng khi tất cả các nguồn dữ liệu phản hồi hoặc khi hết thời gian chờ ở ứng dụng cấp độ vẫn cần được cấu hình. Tức là mọi thứ đều rất, rất tệ.
Bây giờ, cùng một thử nghiệm nhưng đã bật giá trị nhãn quy trình. Như bạn có thể thấy, ở bên trái, khả năng giám sát lô của chúng tôi cũng giảm 25%. Điều này hoàn toàn chính xác, vì nó không biết gì về việc truyền lại, nó gửi các gói và chỉ đơn giản là đếm tỷ lệ giữa số gói được gửi và gói bị mất.
Và bên phải là lịch trình dịch vụ. Bạn sẽ không tìm thấy tác dụng của một khớp có vấn đề ở đây. Trong cùng một phần nghìn giây đó, lưu lượng truy cập từ khu vực có sự cố đến ba đường lên còn lại không bị ảnh hưởng bởi sự cố. Chúng tôi có một mạng lưới có thể tự chữa lành.
Đây là slide cuối cùng của tôi, đã đến lúc tóm tắt. Bây giờ, tôi hy vọng bạn biết cách xây dựng mạng trung tâm dữ liệu có khả năng tự phục hồi. Bạn sẽ không cần phải đi qua kho lưu trữ nhân Linux và tìm kiếm các bản vá đặc biệt ở đó; bạn biết rằng nhãn Flow trong trường hợp này sẽ giải quyết được vấn đề, nhưng bạn cần tiếp cận cơ chế này một cách cẩn thận. Và tôi nhấn mạnh một lần nữa rằng nếu bạn là nhà khai thác viễn thông, bạn không nên sử dụng nhãn luồng làm hàm băm, nếu không bạn sẽ làm gián đoạn phiên của người dùng.
Các kỹ sư mạng phải trải qua quá trình thay đổi khái niệm: mạng bắt đầu không phải bằng ToR, không phải với thiết bị mạng mà với máy chủ. Một ví dụ khá nổi bật là cách chúng tôi sử dụng eBPF để thay đổi RTO và sửa nhãn luồng đối với các dịch vụ Anycast.
Cơ chế nhãn luồng chắc chắn phù hợp với các ứng dụng khác trong phân đoạn hành chính được kiểm soát. Đây có thể là lưu lượng truy cập giữa các trung tâm dữ liệu hoặc bạn có thể sử dụng các cơ chế đó theo cách đặc biệt để quản lý lưu lượng đi. Nhưng tôi hy vọng lần sau tôi sẽ kể cho bạn nghe về điều này. Cảm ơn bạn rất nhiều sự chú ý của bạn.
Nguồn: www.habr.com