스스로 치유하는 네트워크: Flow Label의 마법과 Linux 커널 주변의 탐정. 얀덱스 보고서

최신 데이터 센터에는 다양한 유형의 모니터링이 적용되는 수백 개의 활성 장치가 있습니다. 그러나 완벽한 모니터링을 갖춘 완벽한 엔지니어라도 몇 분 안에 네트워크 장애에 적절하게 대응할 수 있습니다. Next Hop 2020 컨퍼런스 보고서에서 저는 데이터 센터가 밀리초 안에 자체적으로 치유된다는 고유한 기능을 가진 데이터 센터 네트워크 설계 방법론을 제시했습니다. 보다 정확하게는 엔지니어가 문제를 침착하게 해결하는 반면 서비스는 단순히 문제를 인식하지 못합니다.

- 먼저 모던 DC의 구조를 모르시는 분들을 위해 상당히 자세하게 소개하겠습니다.


많은 네트워크 엔지니어에게 데이터 센터 네트워크는 물론 랙의 스위치가 있는 ToR로 시작됩니다. ToR에는 일반적으로 두 가지 유형의 링크가 있습니다. 작은 것들은 서버로 이동하고 다른 것들은 N 배 더 많습니다-첫 번째 수준 스파인, 즉 업링크로 이동합니다. 업링크는 일반적으로 동일한 것으로 간주되며 업링크 간의 트래픽은 proto, src_ip, dst_ip, src_port, dst_port를 포함하는 5튜플 해시를 기반으로 균형을 이룹니다. 여기에는 놀라움이 없습니다.


다음으로 비행기의 구조는 어떻게 생겼습니까? 첫 번째 수준의 척추는 서로 연결되어 있지 않지만 슈퍼 스핀을 통해 연결됩니다. 문자 X는 슈퍼스핀을 담당하며 거의 교차 연결과 같습니다.


그리고 반면에 토리도는 첫 번째 수준의 모든 척추에 연결되어 있음이 분명합니다. 이 그림에서 중요한 것은 무엇입니까? 랙 내부에 상호 작용이 있는 경우 상호 작용은 물론 ToR을 거칩니다. 인터랙션이 모듈 내부로 이동하면 인터랙션은 첫 번째 수준의 스파인을 통과합니다. 상호작용이 상호 모듈식인 경우(여기서 ToR 1 및 ToR 2) 상호작용은 첫 번째 및 두 번째 수준의 스파인을 통과합니다.


이론적으로 이러한 아키텍처는 쉽게 확장할 수 있습니다. 포트 용량, 데이터 센터의 예비 공간 및 사전 배치된 광섬유가 있는 경우 플레인 수를 항상 늘릴 수 있으므로 시스템의 전체 용량이 증가합니다. 종이에 이것은 매우 쉽습니다. 실생활에서도 그렇게 될 것입니다. 그러나 오늘의 이야기는 그것에 관한 것이 아닙니다.


나는 올바른 결론이 도출되기를 원합니다. 데이터 센터 내부에는 많은 경로가 있습니다. 조건부 독립입니다. 데이터 센터 내부의 편도는 ToR 내부에서만 가능합니다. 모듈 내부에는 평면 수와 동일한 수의 경로가 있습니다. 모듈 사이의 경로 수는 평면 수와 각 평면의 슈퍼스핀 수를 곱한 것과 같습니다. 더 명확하게하기 위해 규모를 느끼기 위해 Yandex 데이터 센터 중 하나에 유효한 숫자를 제공하겠습니다.


32개의 평면이 있으며 각 평면에는 256개의 슈퍼스핀이 있습니다. 결과적으로 모듈 내부에 XNUMX개의 경로가 있고 모듈 간 상호 작용을 통해 이미 XNUMX개의 경로가 있음이 밝혀졌습니다.

즉, 우리가 요리책을 개발하고 자가 치료하는 내결함성 데이터 센터를 구축하는 방법을 배우려는 경우 평면 아키텍처가 올바른 선택입니다. 스케일링 문제를 해결할 수 있으며 이론적으로는 쉽습니다. 독립적인 경로가 많이 있습니다. 문제는 다음과 같습니다. 그러한 아키텍처가 장애를 견뎌내는 방법은 무엇입니까? 다양한 충돌이 있습니다. 이제 이에 대해 논의하겠습니다.


슈퍼 스핀 중 하나가 아프게하십시오. 여기서 나는 두 평면의 구조로 돌아갔다. 더 적은 움직이는 부분으로 여기에서 무슨 일이 일어나고 있는지 더 쉽게 볼 수 있기 때문에 우리는 그것들을 예로 들겠습니다. X11이 아프게 놔두세요. 이것이 데이터 센터 내부에 있는 서비스에 어떤 영향을 미칩니까? 실패가 실제로 어떻게 보이는지에 따라 많은 것이 달라집니다.


실패가 양호하면 동일한 BFD의 자동화 수준에서 포착되고 자동화가 기꺼이 문제 관절을 놓고 문제를 격리하면 모든 것이 정상입니다. 우리에게는 많은 경로가 있고 트래픽은 즉시 대체 경로로 다시 라우팅되며 서비스는 아무 것도 알아차리지 못할 것입니다. 이것은 좋은 시나리오입니다.


나쁜 시나리오는 지속적인 손실이 발생하고 자동화가 문제를 인식하지 못하는 경우입니다. 이것이 애플리케이션에 미치는 영향을 이해하려면 TCP 프로토콜이 작동하는 방식에 대해 잠시 논의해야 합니다.


이 정보로 누구에게도 충격을 주지 않기를 바랍니다. TCP는 핸드셰이크 프로토콜입니다. 즉, 가장 간단한 경우 발신자는 두 개의 패킷을 보내고 "두 개의 패킷을 받았습니다."라는 누적 ack를 수신합니다.


그 후 그는 두 개의 패킷을 더 보내며 상황은 반복됩니다. 약간의 단순화에 대해 미리 사과드립니다. 이 시나리오는 윈도우(전송 중인 패킷 수)가 XNUMX인 경우에 맞습니다. 물론 이것은 일반적으로 반드시 그런 것은 아닙니다. 그러나 패킷 전달 컨텍스트는 창 크기의 영향을 받지 않습니다.


패키지 3을 분실하면 어떻게 되나요? 이 경우 수신자는 패킷 1, 2, 4를 받게 됩니다. 그리고 그는 SACK 옵션을 사용하여 발신자에게 명시적으로 알릴 것입니다. 그는 "Ack 2, SACK 4"라고 말합니다.


이때 보낸 사람은 손실된 패킷을 아무 문제 없이 정확하게 반복합니다.


그러나 창의 마지막 패킷이 손실되면 상황이 매우 달라집니다.

수신자는 처음 XNUMX개의 패킷을 수신하고 우선 기다리기 시작합니다. Linux 커널 TCP 스택의 일부 최적화 덕분에 이것이 마지막 패킷이라는 플래그에 명시적인 표시가 없는 한 쌍을 이룬 패킷을 기다립니다. 지연된 ACK 시간 제한이 만료될 때까지 기다린 다음 처음 세 패킷에 대한 승인을 보냅니다. 그러나 이제 보낸 사람이 기다리고 있습니다. 그는 네 번째 패키지가 분실되었는지 또는 곧 도착할지 알 수 없습니다. 그리고 네트워크에 과부하가 걸리지 않도록 하기 위해 패킷이 손실되었다는 명시적 표시 또는 RTO 시간 초과 만료를 기다리려고 합니다.


RTO 시간 제한이란 무엇입니까? 이것은 TCP 스택과 일부 상수에 의해 계산된 RTT의 최대값입니다. 이 상수는 무엇입니까? 이제 논의하겠습니다.


그러나 우리가 다시 운이 좋지 않고 네 번째 패킷이 다시 손실되면 RTO가 두 배가 된다는 것이 중요합니다. 즉, 시도가 실패할 때마다 시간 제한이 두 배가 됩니다.


이제 이 밑이 무엇인지 봅시다. 기본적으로 최소 RTO는 200ms입니다. 이것은 데이터 패킷의 최소 RTO입니다. SYN 패킷의 경우 1초로 다릅니다. 보시다시피 패킷 재전송을 처음 시도하더라도 데이터 센터 내부에서 RTT보다 100배 더 오래 걸립니다.


이제 시나리오로 돌아갑니다. 서비스는 어떻게 되나요? 서비스가 패킷 손실을 시작합니다. 서비스가 처음에는 운이 좋았고 창 중간에서 무언가를 잃어버리면 SACK을 받고 손실된 패킷을 다시 보냅니다.


그러나 불운이 반복되면 RTO가 있습니다. 여기서 중요한 것은 무엇입니까? 예, 네트워크에는 많은 경로가 있습니다. 그러나 하나의 특정 TCP 연결의 TCP 트래픽은 계속해서 동일한 끊어진 스택을 통과합니다. Magic X11이 자체적으로 나가지 않는 한 패킷 손실은 문제가 없는 영역으로 트래픽이 흐르지 않도록 합니다. 동일한 끊어진 스택을 통해 패킷을 전달하려고 합니다. 이로 인해 계단식 오류가 발생합니다. 데이터 센터는 상호 작용하는 응용 프로그램 집합이며 이러한 모든 응용 프로그램의 일부 TCP 연결이 저하되기 시작합니다. 슈퍼 스핀이 DC 내부에 있는 모든 응용 프로그램에 영향을 미치기 때문입니다. 속담에서와 같이 말에 신발을 신지 않으면 말이 절뚝 거립니다. 말 절뚝 거림-보고서가 전달되지 않았습니다. 메시지가 전달되지 않았습니다. 그들은 전쟁에서졌습니다. 여기서만 카운트는 문제가 발생한 순간부터 서비스가 느끼기 시작하는 저하 단계까지 몇 초 동안 갑니다. 이는 사용자가 어딘가에서 무언가를 받지 못할 수도 있음을 의미합니다.


서로를 보완하는 두 가지 고전적인 솔루션이 있습니다. 첫 번째는 빨대를 깔고 다음과 같은 문제를 해결하려는 서비스입니다. “TCP 스택에서 무언가를 조정합시다. 그리고 내부 상태 확인을 통해 애플리케이션 수준 시간 초과 또는 수명이 긴 TCP 세션을 만들어 봅시다. 문제는 그러한 솔루션이 다음과 같다는 것입니다. a) 전혀 확장되지 않습니다. b) 매우 열악한 테스트. 즉, 서비스가 실수로 TCP 스택을 구성하여 더 좋아지더라도 첫째로 이것은 모든 애플리케이션과 모든 데이터 센터에 적용할 가능성이 낮고 둘째로 무엇이 올바르게 수행되었고 무엇을 수행했는지 이해하지 못할 가능성이 큽니다. 아니다. 즉, 작동하지만 제대로 작동하지 않으며 확장되지 않습니다. 네트워크 문제가 발생하면 누구의 책임입니까? 물론 NOC. NOC는 무엇을 하나요?

많은 서비스는 NOC에서 작업이 이와 같이 진행된다고 믿습니다. 하지만 솔직히 말해서 그 뿐만이 아닙니다.


고전적인 계획의 NOC는 많은 모니터링 개발에 참여하고 있습니다. 블랙박스 모니터링과 화이트박스 모니터링이 그것이다. 척추의 블랙박스 모니터링 예시에 대해 말한 지난 넥스트 홉의 알렉산더 클리멘코. 그건 그렇고, 이 모니터링은 작동합니다. 그러나 완벽한 모니터링에도 시간 지연이 있습니다. 일반적으로 몇 분입니다. 작동 후 당직 엔지니어는 작동을 다시 확인하고 문제를 현지화한 다음 문제 영역을 소화할 시간이 필요합니다. 즉, 손실이 발생하는 위치가 즉시 명확하지 않은 경우 최상의 경우 문제 처리에 5분, 최악의 경우 20분이 소요됩니다. 이 모든 시간(5분 또는 20분) 동안 서비스가 계속해서 손상될 것이 분명합니다. 이는 아마도 좋지 않을 것입니다.


무엇을 받고 싶습니까? 우리에게는 길이 너무 많습니다. 그리고 운이 좋지 않은 TCP 흐름이 계속해서 동일한 경로를 사용하기 때문에 문제가 발생합니다. 단일 TCP 연결 내에서 여러 경로를 사용할 수 있는 무언가가 필요합니다. 해결책이 있는 것 같습니다. 소위 다중 경로 TCP, 즉 많은 경로에 대한 TCP라고 하는 TCP가 있습니다. 사실, 여러 네트워크 장치가 있는 스마트폰을 위해 완전히 다른 작업을 위해 개발되었습니다. 전송을 최대화하거나 기본/백업 모드를 만들기 위해 응용 프로그램에 대한 여러 스레드(세션)를 투명하게 생성하고 오류 발생 시 전환할 수 있는 메커니즘이 개발되었습니다. 또는 내가 말했듯이 대역폭을 최대화하십시오.

그러나 여기에는 뉘앙스가 있습니다. 이것이 무엇인지 이해하려면 스트림이 어떻게 설정되는지 살펴봐야 합니다.


스레드는 순차적으로 설정됩니다. 첫 번째 스트림이 먼저 설치됩니다. 후속 흐름은 해당 스레드 내에서 이미 합의된 쿠키를 사용하여 설정됩니다. 그리고 여기에 문제가 있습니다.


문제는 첫 번째 스레드가 설치되지 않으면 두 번째 및 세 번째 스레드가 나타나지 않는다는 것입니다. 즉, 다중 경로 TCP는 첫 번째 스트림에서 SYN 패킷의 손실을 해결하지 않습니다. 그리고 SYN이 손실되면 다중 경로 TCP가 일반 TCP가 됩니다. 따라서 데이터 센터 환경에서는 공장에서의 손실 문제를 해결하고 장애 발생 시 여러 경로를 사용하는 방법을 배우는 데 도움이 되지 않습니다.


무엇이 우리를 도울 수 있습니까? 여러분 중 일부는 이름에서 이미 우리의 추가 이야기에서 중요한 필드가 IPv6 흐름 레이블 헤더 필드가 될 것이라고 추측했습니다. 실제로 이것은 v6에 등장하는 필드이고, v4에는 없는 필드이고, 20비트를 차지하며, 그 사용에 대해 오랫동안 논란이 있었습니다. 이것은 매우 흥미 롭습니다. 분쟁이 있었고 RFC 프레임 워크 내에서 무언가가 수정되었으며 동시에 어디에도 문서화되지 않은 구현이 Linux 커널에 나타났습니다.


저와 함께 약간의 조사를 해보라고 제안합니다. 지난 몇 년 동안 Linux 커널에서 무슨 일이 있었는지 살펴보겠습니다.

2014년. 크고 평판이 좋은 회사의 엔지니어가 소켓 해시에 대한 흐름 레이블 값의 종속성을 Linux 커널의 기능에 추가합니다. 그들은 여기서 무엇을 고치려고 합니까? 이것은 다음 문제를 논의한 RFC 6438과 관련이 있습니다. 데이터 센터 내부에서 IPv4는 IPv6 패킷으로 캡슐화되는 경우가 많습니다. 공장 자체가 IPv6이지만 IPv4는 어떻게든 제공되어야 하기 때문입니다. 오랫동안 TCP 또는 UDP에 도달하여 거기에서 src_ports, dst_ports를 찾기 위해 두 개의 IP 헤더 아래를 볼 수 없는 스위치에 문제가 있었습니다. 처음 두 개의 IP 헤더를 보면 해시가 거의 고정된 것으로 나타났습니다. 이를 방지하기 위해 이 캡슐화된 트래픽의 균형이 올바르게 작동하도록 5튜플 캡슐화된 패킷의 해시를 흐름 레이블 필드의 값에 추가하는 것이 제안되었습니다. 다른 캡슐화 체계, UDP, GRE에 대해서도 거의 동일하게 수행되었으며 후자에서는 GRE 키 필드가 사용되었습니다. 어떤 식으로든 여기서의 목표는 분명합니다. 그리고 적어도 그 시점에서 그들은 유용했습니다.

2015년에는 동일한 존경받는 엔지니어가 새 패치를 제공합니다. 그는 매우 흥미 롭습니다. 다음과 같습니다. 부정적인 라우팅 이벤트의 경우 해시를 무작위로 지정합니다. 부정적인 라우팅 이벤트란 무엇입니까? 이것은 앞에서 논의한 RTO입니다. 즉, 윈도우 테일의 손실은 정말 부정적인 이벤트입니다. 사실, 그것이 무엇인지 추측하는 것은 상대적으로 어렵습니다.

2016년, 또 다른 존경받는 회사도 큰 회사입니다. 그것은 마지막 목발을 파싱하고 우리가 이전에 무작위로 만든 해시가 이제 모든 SYN 재전송과 모든 RTO 시간 초과 후에 변경되도록 만듭니다. 그리고 이 편지에서 처음이자 마지막으로 채널의 손실 또는 과부하가 발생한 경우 트래픽이 여러 경로를 사용하여 소프트 경로 재지정 가능성을 갖도록 하는 궁극적인 목표가 들립니다. 물론 그 이후에 많은 출판물이 있었기 때문에 쉽게 찾을 수 있습니다.

아니요, 할 수 없습니다. 이 주제에 대한 단일 출판물이 없기 때문입니다. 그러나 우리는 알고 있습니다!

무슨 일이 있었는지 완전히 이해하지 못하면 지금 말씀 드리겠습니다.


무엇이 완료되었으며 Linux 커널에 어떤 기능이 추가되었습니까? txhash는 각 RTO 이벤트 후 임의의 값으로 변경됩니다. 이것은 동일한 부정적인 라우팅 결과입니다. 해시는 이 txhash에 따라 달라지고 흐름 레이블은 skb 해시에 따라 달라집니다. 여기에는 함수에 대한 몇 가지 계산이 있으며 모든 세부 정보를 하나의 슬라이드에 배치할 수 없습니다. 궁금한 사람은 커널 코드를 통해 확인할 수 있습니다.

여기서 중요한 것은 무엇입니까? 흐름 레이블 필드의 값은 각 RTO 후에 임의의 숫자로 변경됩니다. 이것이 불행한 TCP 스트림에 어떤 영향을 미칩니 까?


SACK의 경우 알려진 손실 패킷을 다시 보내려고 하기 때문에 아무 것도 변경되지 않았습니다. 여태까지는 그런대로 잘됐다.


그러나 RTO의 경우 ToR의 해시 함수에 흐름 레이블을 추가했다면 트래픽이 다른 경로를 택할 수 있습니다. 그리고 비행기가 많을수록 특정 장치의 충돌에 의해 영향을 받지 않는 경로를 찾을 가능성이 높아집니다.


한 가지 문제가 남아 있습니다 - RTO. 물론 다른 경로가 있지만 많은 시간이 소요됩니다. 200ms는 많습니다. 두 번째는 일반적으로 야생입니다. 앞에서 서비스를 구성하는 시간 제한에 대해 이야기했습니다. 따라서 1초는 일반적으로 애플리케이션 수준에서 서비스를 설정하는 시간 제한이며, 이 경우 서비스가 상대적으로 옳을 것입니다. 또한 현대 데이터 센터 내부의 실제 RTT는 약 XNUMX밀리초입니다.


RTO 시간 초과에 대해 무엇을 할 수 있습니까? 데이터 패킷이 손실된 경우 RTO를 담당하는 시간 초과는 사용자 공간에서 비교적 쉽게 구성할 수 있습니다. IP 유틸리티가 있고 해당 매개변수 중 하나에 동일한 rto_min이 포함되어 있습니다. 물론 RTO를 전역적으로 전환해야 하지만 주어진 접두사에 대해 이러한 메커니즘이 상당히 작동하는 것처럼 보입니다.


사실, SYN_RTO를 사용하면 모든 것이 다소 나빠집니다. 자연스럽게 아래로 고정됩니다. 값은 코어에 고정되어 있습니다(1초). 사용자 공간에서 연결할 수 없습니다. 방법은 하나뿐입니다.


eBPF가 구출됩니다. 간단히 말해서 이들은 작은 C 프로그램이며 커널 스택과 TCP 스택 실행의 다른 위치에 있는 후크에 삽입될 수 있으며 이를 통해 매우 많은 설정을 변경할 수 있습니다. 일반적으로 eBPF는 장기적인 추세입니다. 수십 개의 새로운 sysctl 매개변수를 확인하고 IP 유틸리티를 확장하는 대신 eBPF 방향으로 이동하고 기능을 확장합니다. eBPF를 사용하면 혼잡 제어 및 기타 다양한 TCP 설정을 동적으로 변경할 수 있습니다.


그러나 그것의 도움으로 SYN_RTO의 값을 비틀 수 있다는 것이 중요합니다. 공개적으로 게시된 예가 있습니다. https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. 여기서 무엇을 합니까? 예제는 작동하지만 그 자체로는 매우 거칠다. 여기서는 데이터 센터 내부에서 처음 44비트를 비교하여 일치하는 경우 DC 내부에 있다고 가정합니다. 이 경우 SYN_RTO 시간 제한 값을 4ms로 변경합니다. 동일한 작업을 훨씬 더 우아하게 수행할 수 있습니다. 그러나이 간단한 예는 무엇을 보여줍니다 a) 가능; b) 비교적 쉽다.

우리는 이미 무엇을 알고 있습니까? 평면 아키텍처가 확장을 허용한다는 것은 ToR에서 흐름 레이블을 켜고 문제 영역 주위를 흘릴 기회를 얻을 때 우리에게 매우 유용하다는 것이 밝혀졌습니다. RTO 및 SYN-RTO 값을 낮추는 가장 좋은 방법은 eBPF 프로그램을 사용하는 것입니다. 문제는 남아 있습니다. 밸런싱을 위해 흐름 레이블을 사용하는 것이 안전한가요? 그리고 여기에는 뉘앙스가 있습니다.


네트워크에 anycast에 있는 서비스가 있다고 가정합니다. 아쉽게도 애니캐스트에 대해 자세히 설명할 시간이 없지만 동일한 IP 주소에서 다양한 물리적 서버를 사용할 수 있는 분산 서비스입니다. 그리고 여기에 가능한 문제가 있습니다. RTO 이벤트는 트래픽이 공장을 통과할 때만 발생할 수 있는 것이 아닙니다. ToR 버퍼 수준에서도 발생할 수 있습니다. 인캐스트 이벤트가 발생하면 호스트가 무언가를 유출할 때 호스트에서도 발생할 수 있습니다. RTO 이벤트가 발생하고 흐름 레이블이 변경되는 경우. 이 경우 트래픽은 다른 애니캐스트 인스턴스로 이동할 수 있습니다. 이것이 상태 저장 애니캐스트이고 연결 상태를 포함한다고 가정합니다. L3 Balancer 또는 다른 서비스일 수 있습니다. 그런 다음 RTO 후에 TCP 연결이 이 TCP 연결에 대해 아무것도 모르는 서버에 도착하기 때문에 문제가 발생합니다. 그리고 애니캐스트 서버 간에 상태 공유가 없으면 이러한 트래픽이 삭제되고 TCP 연결이 끊어집니다.


여기서 무엇을 할 수 있습니까? 흐름 레이블 밸런싱을 활성화하는 제어된 환경 내에서 애니캐스트 서버에 액세스할 때 흐름 레이블 값을 수정해야 합니다. 가장 쉬운 방법은 동일한 eBPF 프로그램을 통해 수행하는 것입니다. 그러나 여기에 매우 중요한 점이 있습니다. 데이터 센터 네트워크를 운영하지 않고 통신 사업자라면 어떻게 해야 할까요? 이것은 귀하의 문제이기도 합니다. 특정 버전의 Juniper 및 Arista부터 시작하여 기본적으로 해시 함수에 흐름 레이블을 포함합니다. 솔직히 말해서 이해할 수 없는 이유가 있습니다. 이로 인해 네트워크를 통과하는 사용자의 TCP 연결이 끊어질 수 있습니다. 따라서 이 위치에서 라우터 설정을 확인하는 것이 좋습니다.

어쨌든 실험으로 넘어갈 준비가 된 것 같습니다.


ToR에서 흐름 레이블을 켜고 현재 호스트에 있는 에이전트의 eBPF를 준비했을 때 우리는 다음 큰 실패를 기다리지 않고 통제된 폭발을 수행하기로 결정했습니다. 우리는 75개의 업링크가 있는 ToR을 선택하여 그 중 하나에 드롭했습니다. 그들은 규칙을 세웠다고 그들은 말했습니다. 이제 당신은 모든 패킷을 잃고 있습니다. 왼쪽에서 볼 수 있듯이 패킷당 모니터링이 25%로 떨어졌습니다. 즉, 패킷의 25%가 손실되었습니다. 오른쪽에는 이 ToR 뒤에 있는 서비스 그래프가 있습니다. 사실 이것은 랙 내부의 서버와 조인트의 트래픽 그래프입니다. 보시다시피 그들은 더 낮아졌습니다. 3%가 아니라 어떤 경우에는 4-XNUMX배 더 낮아진 이유는 무엇입니까? TCP 연결이 운이 좋지 않으면 끊어진 인터페이스를 통해 계속 연결을 시도합니다. 이는 DC 내부 서비스의 일반적인 동작으로 인해 악화됩니다. 하나의 사용자 요청에 대해 내부 서비스에 대한 N개의 요청이 생성되고 모든 데이터 소스가 응답하거나 시간 초과가 트리거될 때 응답이 사용자에게 전달됩니다. 여전히 구성해야 하는 애플리케이션 수준. 즉, 모든 것이 매우 나쁘다.


이제 동일한 실험이지만 흐름 레이블이 활성화되었습니다. 왼쪽에서 볼 수 있듯이 일괄 모니터링이 25% 감소했습니다. 이것은 재전송에 대해 아무것도 모르기 때문에 절대적으로 정확합니다. 패킷을 보내고 단순히 전달된 패킷과 손실된 패킷 수의 비율을 계산합니다.

오른쪽에는 서비스 일정이 있습니다. 여기서 문제 관절의 효과를 찾을 수 없습니다. 동일한 밀리초의 트래픽이 문제 영역에서 문제의 영향을 받지 않은 나머지 XNUMX개의 업링크로 이동했습니다. 스스로 치유하는 네트워크가 있습니다.

이것이 내 마지막 슬라이드입니다. 검토할 시간입니다. 이제 자가 치유 데이터 센터 네트워크를 구축하는 방법을 아셨기를 바랍니다. Linux 커널 아카이브를 살펴보고 거기에서 특별한 패치를 찾을 필요가 없습니다. Flow 레이블이 이 경우 문제를 해결한다는 것을 알고 있지만 이 메커니즘에 신중하게 접근해야 합니다. 그리고 통신사라면 플로우 레이블을 해시 함수로 사용해서는 안 된다는 점을 다시 한 번 강조합니다. 그렇지 않으면 사용자 세션이 중단됩니다.

네트워크 엔지니어의 경우 개념적 전환이 필요합니다. 네트워크는 네트워크 장치가 아니라 호스트에서 ToR로 시작하지 않습니다. 꽤 놀라운 예는 eBPF를 사용하여 RTO를 변경하고 흐름 레이블을 애니캐스트 서비스로 수정하는 방법입니다.

흐름 레이블 메커니즘은 제어된 관리 세그먼트 내의 다른 용도에 확실히 적합합니다. 이는 데이터 센터 간의 트래픽일 수도 있고 나가는 트래픽을 제어하기 위해 이러한 메커니즘을 특별한 방식으로 사용할 수 있습니다. 그러나 나는 이것에 대해 다음에 이야기 할 것입니다. 많은 관심 부탁드립니다.

출처 : habr.com