데이터 센터를 확장하는 방법. Yandex 보고서

우리는 초당 100페타바이트가 넘는 최대 이등분 대역폭을 갖춘 XNUMX만 대 이상의 서버를 컴퓨팅 클러스터에 배포할 수 있는 데이터 센터 네트워크 설계를 개발했습니다.

Dmitry Afanasyev의 보고서를 통해 새로운 디자인의 기본 원칙, 토폴로지 확장, 이로 인해 발생하는 문제, 해결 옵션, "밀도 연결"에서 최신 네트워크 장치의 포워딩 플레인 기능 라우팅 및 확장 기능에 대해 알아봅니다. ECMP 경로가 많은 토폴로지. 또한 Dima는 외부 연결 구성, 물리적 계층, 케이블링 시스템 및 용량을 추가로 늘리는 방법에 대해 간략하게 설명했습니다.

- 여러분 좋은 오후입니다! 제 이름은 Dmitry Afanasyev이고 Yandex의 네트워크 설계자이며 주로 데이터 센터 네트워크를 설계합니다.



내 이야기는 Yandex 데이터 센터의 업데이트된 네트워크에 관한 것입니다. 이는 우리가 갖고 있던 디자인이 크게 발전한 것이지만 동시에 몇 가지 새로운 요소도 있습니다. 짧은 시간 안에 많은 정보를 담아야 하기 때문에 개요 프레젠테이션입니다. 논리적 토폴로지를 선택하는 것부터 시작하겠습니다. 그런 다음 컨트롤 플레인에 대한 개요와 데이터 플레인 확장성 문제, 물리적 수준에서 발생하는 일을 선택하고 장치의 일부 기능을 살펴보겠습니다. 얼마 전에 이야기했던 MPLS가 적용된 데이터 센터에서 어떤 일이 일어나고 있는지 잠깐 살펴보겠습니다.

그렇다면 로드 및 서비스 측면에서 Yandex는 무엇입니까? Yandex는 전형적인 하이퍼스케일러입니다. 사용자를 살펴보면 주로 사용자 요청을 처리합니다. 또한 다양한 스트리밍 서비스와 데이터 전송, 스토리지 서비스도 갖추고 있기 때문입니다. 백엔드에 가까울수록 분산 객체 스토리지, 데이터 복제 및 영구 대기열과 같은 인프라 로드 및 서비스가 나타납니다. 워크로드의 주요 유형 중 하나는 MapReduce 및 유사한 시스템, 스트림 처리, 기계 학습 등입니다.

이 모든 일이 일어나는 인프라는 어떻게 되나요? 다시 말하지만, 우리는 아마도 스펙트럼에서 덜 하이퍼스케일러 측면에 조금 더 가깝지만 꽤 전형적인 하이퍼스케일러입니다. 그러나 우리는 모든 속성을 가지고 있습니다. 우리는 가능한 한 상용 하드웨어와 수평적 확장을 사용합니다. 우리는 완전한 리소스 풀링을 제공합니다. 개별 기계, 개별 랙을 사용하여 작업하는 것이 아니라 계획 및 할당을 처리하는 일부 추가 서비스와 함께 이를 상호 교환 가능한 대규모 리소스 풀로 결합하고 이 전체 풀을 사용하여 작업합니다.

따라서 다음 단계는 컴퓨팅 클러스터 수준의 운영 체제입니다. 우리가 사용하는 기술 스택을 완전히 제어하는 ​​것이 매우 중요합니다. 우리는 엔드포인트(호스트), 네트워크 및 소프트웨어 스택을 제어합니다.

우리는 러시아와 해외에 여러 개의 대규모 데이터 센터를 보유하고 있습니다. 이들은 MPLS 기술을 사용하는 백본으로 통합됩니다. 우리의 내부 인프라는 거의 전적으로 IPv6를 기반으로 구축되었지만 여전히 주로 IPv4를 통해 들어오는 외부 트래픽을 처리해야 하기 때문에 어떻게든 IPv4를 통해 들어오는 요청을 프런트엔드 서버로 전달하고 외부 IPv4-인터넷으로 조금 더 전달해야 합니다. 예를 들어 인덱싱의 경우입니다.

데이터 센터 네트워크 설계의 마지막 몇 번의 반복에서는 다중 계층 Clos 토폴로지를 사용했으며 L3 전용이었습니다. 우리는 얼마 전 L2를 떠나 안도의 한숨을 쉬었습니다. 마지막으로 우리 인프라에는 수십만 개의 컴퓨팅(서버) 인스턴스가 포함됩니다. 얼마 전 최대 클러스터 크기는 약 10개의 서버였습니다. 이는 동일한 클러스터 수준의 운영체제, 스케줄러, 리소스 할당 등이 어떻게 작동할 수 있는지에 크게 기인하며, 인프라 소프트웨어 측면에서 진전이 이루어졌기 때문에 목표 규모는 이제 하나의 컴퓨팅 클러스터에 약 100만 대의 서버가 되며, 우리에게는 그러한 클러스터에서 효율적인 리소스 풀링을 허용하는 네트워크 팩토리를 구축할 수 있는 임무가 있습니다.

데이터 센터 네트워크에서 우리는 무엇을 원하는가? 우선, 저렴하고 상당히 균일하게 분포된 대역폭이 많이 있습니다. 네트워크는 리소스를 모을 수 있는 백본이기 때문입니다. 새로운 목표 규모는 클러스터 하나에 약 100만 대의 서버입니다.

물론 우리는 확장 가능하고 안정적인 컨트롤 플레인도 원합니다. 왜냐하면 이러한 대규모 인프라에서는 단순한 무작위 이벤트에서도 많은 골칫거리가 발생하고 컨트롤 플레인이 우리에게 골칫거리를 가져오는 것을 원하지 않기 때문입니다. 동시에 우리는 그 안에 있는 상태를 최소화하고 싶습니다. 조건이 작을수록 모든 것이 더 좋고 안정적으로 작동하며 진단도 더 쉽습니다.

물론 이러한 인프라를 수동으로 관리하는 것은 불가능하고 한동안 불가능했기 때문에 자동화가 필요합니다. 최대한 운영지원이 필요하고, CI/CD 지원도 할 수 있는 정도가 필요합니다.

이러한 규모의 데이터 센터와 클러스터로 인해 서비스 중단 없이 증분 배포 및 확장을 지원하는 작업이 매우 중요해졌습니다. XNUMX개의 머신 크기의 클러스터, 아마도 XNUMX개에 가까운 머신에서 여전히 하나의 작업으로 롤아웃할 수 있습니다. 즉, 인프라 확장을 계획하고 있으며 수천 개의 머신이 하나의 작업으로 추가됩니다. 그러면 십만 대 규모의 클러스터가 이렇게 즉시 발생하는 것이 아니라 일정 기간에 걸쳐 구축됩니다. 그리고 이미 펌핑된 것, 배포된 인프라를 항상 사용할 수 있어야 하는 것이 바람직합니다.

그리고 우리가 갖고 있던 한 가지 요구 사항은 멀티 테넌시 지원, 즉 가상화 또는 네트워크 세분화입니다. 이제 샤딩이 호스트로 이동했고 이로 인해 확장이 매우 쉬워졌기 때문에 네트워크 패브릭 수준에서 이 작업을 수행할 필요가 없습니다. IPv6와 넓은 주소 공간 덕분에 내부 인프라에서 중복된 주소를 사용할 필요가 없었으며 모든 주소 지정이 이미 고유했습니다. 그리고 호스트에 대한 필터링 및 네트워크 분할을 수행했기 때문에 데이터 센터 네트워크에 가상 네트워크 엔터티를 생성할 필요가 없습니다.

매우 중요한 것은 우리에게 필요하지 않은 것입니다. 네트워크에서 일부 기능을 제거할 수 있으면 생활이 훨씬 쉬워지고 일반적으로 사용 가능한 장비 및 소프트웨어의 선택이 확장되어 진단이 매우 간단해집니다.

그렇다면 우리에게 필요하지 않은 것은 무엇이며, 그 일이 일어났을 때 항상 기쁨이 아니라 그 과정이 완료되었을 때 큰 안도감을 가지고 포기할 수 있었던 것은 무엇입니까?

우선 L2를 포기합니다. 실제도 에뮬레이션도 아닌 L2는 필요하지 않습니다. 우리가 애플리케이션 스택을 제어한다는 사실 때문에 주로 사용되지 않습니다. 우리 애플리케이션은 수평으로 확장 가능하고 L3 주소 지정과 함께 작동하며 일부 개별 인스턴스가 종료되는 것을 크게 걱정하지 않고 단순히 새 인스턴스를 롤아웃합니다. 이전 주소에서 롤아웃할 필요가 없습니다. 클러스터에 있는 시스템에 대한 별도의 서비스 검색 및 모니터링 수준입니다. 우리는 이 작업을 네트워크에 위임하지 않습니다. 네트워크의 역할은 A 지점에서 B 지점으로 패킷을 전달하는 것입니다.

또한 네트워크 내에서 주소가 이동하는 상황도 없으므로 이를 모니터링해야 합니다. 많은 설계에서 이는 일반적으로 VM 이동성을 지원하는 데 필요합니다. 우리는 대규모 Yandex의 내부 인프라에서 가상 머신의 이동성을 사용하지 않으며, 이것이 수행되더라도 네트워크 지원에서는 이런 일이 발생해서는 안 된다고 믿습니다. 실제로 수행해야 하는 경우 호스트 수준에서 수행해야 하며, 언더레이 자체(전송 네트워크)의 라우팅 시스템을 건드리거나 너무 많은 동적 변경을 하지 않도록 오버레이로 마이그레이션할 수 있는 주소를 푸시해야 합니다. .

우리가 사용하지 않는 또 다른 기술은 멀티캐스트입니다. 원하시면 그 이유를 자세히 말씀드릴 수 있습니다. 이는 삶을 훨씬 쉽게 만듭니다. 왜냐하면 누군가가 이 문제를 처리하고 가장 단순한 설치를 제외하고 멀티캐스트 제어 평면이 어떻게 생겼는지 정확히 본다면 이것은 큰 골칫거리이기 때문입니다. 게다가 제대로 작동하는 오픈 소스 구현을 찾기도 어렵습니다.

마지막으로 우리는 네트워크가 너무 많이 변하지 않도록 네트워크를 설계합니다. 우리는 라우팅 시스템에서 외부 이벤트의 흐름이 작다는 사실을 믿을 수 있습니다.

데이터 센터 네트워크를 개발할 때 어떤 문제가 발생하고 어떤 제한 사항을 고려해야 합니까? 물론 비용이 듭니다. 확장성, 우리가 성장하고 싶은 수준입니다. 서비스를 중단하지 않고 확장해야 할 필요성. 대역폭, 가용성. 모니터링 시스템, 운영 팀을 위해 네트워크에서 무슨 일이 일어나고 있는지에 대한 가시성. 자동화 지원 - 추가 레이어 도입을 포함하여 다양한 작업을 다양한 수준에서 해결할 수 있으므로 가능한 한 많이 지원합니다. 글쎄요, 공급업체에 의존하지 않을 수도 있습니다. 역사적 시기는 다르지만 어느 부분을 보느냐에 따라 이러한 독립을 달성하는 것이 더 쉽거나 더 어려웠습니다. 네트워크 장치 칩의 단면을 살펴보면 최근까지 처리량이 높은 칩을 원한다면 공급 업체로부터의 독립성에 대해 이야기하는 것이 매우 조건적이었습니다.

네트워크를 구축하기 위해 어떤 논리적 토폴로지를 사용할 것인가? 이것은 다단계 Clos가 될 것입니다. 사실 현재로서는 실질적인 대안이 없습니다. 그리고 Clos 토폴로지는 큰 기수 스위치가 있는 경우 현재 학문적 관심 분야에 더 많은 다양한 고급 토폴로지와 비교해도 상당히 좋습니다.

다단계 Clos 네트워크는 대략 어떻게 구성되어 있으며 그 안에서 호출되는 다양한 요소는 무엇입니까? 먼저 바람이 불어 어디가 북쪽이고 어디가 남쪽이며 어디가 동쪽이고 어디인지 방향을 잡습니다. 이러한 유형의 네트워크는 일반적으로 동서 트래픽이 매우 큰 사람들이 구축합니다. 나머지 요소의 상단에는 더 작은 스위치로 구성된 가상 스위치가 있습니다. 이것이 Clos 네트워크의 재귀적 구축의 주요 아이디어이다. 우리는 어떤 종류의 기수를 가진 요소를 가져와 연결하여 우리가 얻는 것이 더 큰 기수를 가진 스위치로 간주될 수 있도록 합니다. 더 필요한 경우 절차를 반복할 수 있습니다.

예를 들어 1레벨 Clos의 경우 다이어그램에서 수직인 구성 요소를 명확하게 식별할 수 있는 경우 일반적으로 평면이라고 합니다. XNUMX개 레벨의 스파인 스위치(모두 경계 또는 ToR 스위치가 아니며 전송에만 사용됨)로 Clos를 구축한다면 평면은 더 복잡해 보일 것입니다. XNUMX레벨 스위치는 정확히 다음과 같습니다. ToR 또는 리프 스위치 블록과 이와 연결된 첫 번째 레벨 스파인 스위치를 포드라고 부릅니다. 포드 상단에 있는 스파인-XNUMX 수준의 스파인 스위치는 포드의 상단, 즉 포드의 상단입니다. 전체 공장의 최상층에 위치한 스위치는 공장의 최상층인 Top of Fabric입니다.

물론 Clos 네트워크가 구축된 지 꽤 되었는데 아이디어 자체는 일반적으로 고전적인 전화 통신 시대인 TDM 네트워크에서 유래했다는 의문이 듭니다. 어쩌면 더 나은 것이 나타났을 수도 있고, 뭔가 더 잘할 수도 있지 않을까? 예, 아니오. 이론적으로는 그렇습니다. 실제로는 가까운 미래에는 그렇지 않을 것입니다. 흥미로운 토폴로지가 많기 때문에 그 중 일부는 프로덕션에서도 사용됩니다. 예를 들어 Dragonfly는 HPC 애플리케이션에 사용됩니다. Xpander, FatClique, Jellyfish와 같은 흥미로운 토폴로지도 있습니다. 최근 SIGCOMM이나 NSDI와 같은 컨퍼런스의 보고서를 보면 Clos보다 더 나은 속성(하나 또는 다른 것)을 가진 대체 토폴로지에 대한 상당히 많은 수의 작업을 찾을 수 있습니다.

그러나 이러한 모든 토폴로지에는 하나의 흥미로운 속성이 있습니다. 이는 우리가 상용 하드웨어를 기반으로 구축하려고 시도하고 있으며 상당한 비용이 드는 데이터 센터 네트워크에서의 구현을 방해합니다. 이러한 모든 대체 토폴로지에서 대부분의 대역폭은 불행히도 최단 경로를 통해 액세스할 수 없습니다. 따라서 우리는 기존 제어 평면을 사용할 기회를 즉시 잃게 됩니다.

이론적으로 문제에 대한 해결책은 알려져 있습니다. 예를 들어, 이는 k-최단 경로를 사용한 링크 상태 수정이지만, 생산 환경에서 구현되고 장비에서 널리 사용할 수 있는 프로토콜은 없습니다.

더욱이, 대부분의 용량은 최단 경로를 통해 액세스할 수 없기 때문에 모든 경로를 선택하려면 제어 평면보다 더 많은 것을 수정해야 합니다(그런데 이는 제어 평면에서 훨씬 더 많은 상태입니다). 여전히 전달 평면을 수정해야 하며 일반적으로 최소한 두 가지 추가 기능이 필요합니다. 이는 예를 들어 호스트에서 패킷 전달에 대한 모든 결정을 한 번만 내릴 수 있는 기능입니다. 실제로 이것은 소스 라우팅이며 때로는 상호 연결 네트워크에 관한 문헌에서는 이를 일괄 전달 결정이라고 합니다. 그리고 적응형 라우팅은 네트워크 요소에 필요한 기능으로, 예를 들어 대기열의 최소 로드에 대한 정보를 기반으로 다음 홉을 선택한다는 사실로 요약됩니다. 예를 들어, 다른 옵션도 가능합니다.

그래서 그 방향은 흥미롭지만 아쉽게도 지금은 적용할 수 없습니다.

좋아, 우리는 Clos 논리적 토폴로지를 결정했습니다. 어떻게 확장할 것인가? 어떻게 작동하고 무엇을 할 수 있는지 살펴보겠습니다.

Clos 네트워크에는 어떻게든 변경하고 특정 결과를 얻을 수 있는 두 가지 주요 매개변수, 즉 요소의 기수와 네트워크의 레벨 수가 있습니다. 두 가지가 크기에 어떤 영향을 미치는지에 대한 개략도가 있습니다. 이상적으로는 두 가지를 모두 결합합니다.

Clos 네트워크의 최종 너비는 남쪽 기수의 모든 수준의 스파인 스위치, 우리가 가지고 있는 링크 수, 분기 방법의 곱임을 알 수 있습니다. 이것이 네트워크 규모를 확장하는 방법입니다.

용량, 특히 ToR 스위치의 경우 두 가지 확장 옵션이 있습니다. 일반 토폴로지를 유지하면서 더 빠른 링크를 사용하거나 더 많은 평면을 추가할 수 있습니다.

Clos 네트워크의 확장된 버전(오른쪽 하단)을 보고 아래 Clos 네트워크가 있는 이 그림으로 돌아오면...

...이것은 정확히 동일한 토폴로지이지만 이 슬라이드에서는 더 컴팩트하게 축소되었으며 공장 평면이 서로 겹쳐졌습니다. 그것은 동일합니다.

Clos 네트워크 확장은 숫자로 어떻게 보입니까? 여기서는 네트워크에서 얻을 수 있는 최대 너비, 최대 랙 수, ToR 스위치 또는 리프 스위치에 대한 데이터를 제공합니다. 랙에 없는 경우 스파인 레벨에 사용하는 스위치 기수에 따라 얻을 수 있습니다. 우리가 사용하는 레벨 수.

다음은 우리가 보유할 수 있는 랙 수, 서버 수 및 랙당 20kW를 기준으로 이 모든 것이 소비할 수 있는 대략적인 양입니다. 앞서 우리는 약 100만 대 규모의 서버 클러스터 규모를 목표로 하고 있다고 언급한 바 있습니다.

이 전체 설계에서 64개의 옵션이 관심을 끌고 있음을 알 수 있습니다. 128개의 스파인 레이어와 128포트 스위치가 포함된 옵션이 있는데 이는 약간 부족합니다. 그런 다음 32레벨의 150포트(radix XNUMX 포함) 스파인 스위치 또는 XNUMX레벨의 radix XNUMX 스위치에 딱 맞는 옵션이 있습니다. 그리고 더 많은 기수와 더 많은 레이어가 있는 모든 경우에 매우 큰 네트워크를 만들 수 있지만 예상 소비량을 살펴보면 일반적으로 기가와트에 이릅니다. 케이블을 설치하는 것은 가능하지만 한 사이트에서 그렇게 많은 전력을 공급받을 가능성은 없습니다. 데이터센터 통계나 공공데이터를 살펴보면 추정 용량이 XNUMXMW 이상인 데이터센터는 거의 찾아볼 수 없다. 더 큰 규모는 일반적으로 데이터 센터 캠퍼스로, 여러 개의 대규모 데이터 센터가 서로 아주 가까이 위치해 있습니다.

또 다른 중요한 매개 변수가 있습니다. 왼쪽 열을 보면 사용 가능한 대역폭이 나열되어 있습니다. Clos 네트워크에서는 포트의 상당 부분이 스위치를 서로 연결하는 데 사용된다는 것을 쉽게 알 수 있습니다. 유용한 스트립인 사용 가능한 대역폭은 외부, 즉 서버를 향해 제공될 수 있는 것입니다. 당연히 조건부 포트, 특히 밴드에 대해 이야기하고 있습니다. 일반적으로 네트워크 내의 링크는 서버로 향하는 링크보다 빠르지만, 대역폭 단위당 서버 장비로 전송할 수 있는 만큼 네트워크 자체 내에는 여전히 일부 대역폭이 있습니다. 그리고 우리가 더 많은 레벨을 만들수록 이 스트라이프를 외부에 제공하는 데 드는 특정 비용이 더 커집니다.

게다가 이 추가 밴드도 정확히 동일하지는 않습니다. 범위는 짧지만 DAC(직접 연결 구리, 즉 쌍축 케이블) 또는 다중 모드 광학 장치와 같은 것을 사용할 수 있으며 이는 훨씬 더 많거나 적은 비용이 듭니다. 더 긴 범위로 이동하자마자 일반적으로 이는 단일 모드 광학이며 이 추가 대역폭 비용이 눈에 띄게 증가합니다.

그리고 다시 이전 슬라이드로 돌아가서 초과 가입 없이 Clos 네트워크를 생성하면 다이어그램을 쉽게 보고 네트워크가 어떻게 구축되는지 확인할 수 있습니다. 스파인 스위치의 각 레벨을 추가하고 해당 위치에 있던 전체 스트립을 반복합니다. 맨 아래. 플러스 레벨 - 이전 레벨과 동일한 대역, 동일한 수의 스위치 포트 및 동일한 수의 트랜시버를 추가합니다. 따라서 스파인 스위치 수준 수를 최소화하는 것이 매우 바람직합니다.

이 그림을 보면 우리가 기수가 128인 스위치 같은 것을 구축하고 싶다는 것이 분명해졌습니다.

여기에서는 원칙적으로 모든 것이 방금 말한 것과 동일하며 나중에 고려할 슬라이드입니다.

그러한 스위치로 선택할 수 있는 옵션에는 어떤 것이 있습니까? 이제 이러한 네트워크가 마침내 단일 칩 스위치에 구축될 수 있다는 것은 우리에게 매우 기쁜 소식입니다. 그리고 이것은 매우 멋지고, 좋은 기능이 많이 있습니다. 예를 들어 내부 구조가 거의 없습니다. 이는 더 쉽게 부서진다는 것을 의미합니다. 온갖 방법으로 부서지지만 다행히도 완전히 부서집니다. 모듈형 장치에는 이웃과 제어 평면의 관점에서 볼 때 작동하는 것처럼 보이지만 예를 들어 패브릭의 일부가 손실되어 작동하지 않는 경우 결함(매우 불쾌함)이 많이 있습니다. 최대 용량으로. 그리고 이에 대한 트래픽은 완벽하게 작동한다는 사실을 기반으로 균형을 이루므로 과부하가 발생할 수 있습니다.

또는 예를 들어 모듈형 장치 내부에는 고속 SerDes도 있기 때문에 백플레인에 문제가 발생합니다. 내부는 정말 복잡합니다. 전달 요소 간의 표시가 동기화되거나 동기화되지 않습니다. 일반적으로 많은 수의 요소로 구성된 생산적인 모듈형 장치는 일반적으로 내부에 동일한 Clos 네트워크를 포함하지만 진단하기가 매우 어렵습니다. 종종 공급업체 자신도 진단하기가 어렵습니다.

그리고 장치 성능이 저하되지만 토폴로지에서 완전히 벗어나지는 않는 오류 시나리오가 많이 있습니다. 우리의 네트워크는 규모가 크고 동일한 요소 간의 균형이 적극적으로 사용되며 네트워크는 매우 규칙적입니다. 즉 모든 것이 정돈된 한 경로는 다른 경로와 다르지 않습니다. 단순히 일부를 잃는 것이 더 유리합니다. 토폴로지의 장치 중 일부는 작동하는 것처럼 보이지만 일부는 작동하지 않는 상황에 처하게 됩니다.

단일 칩 장치의 다음 장점은 더 좋고 더 빠르게 발전한다는 것입니다. 그들은 또한 더 나은 용량을 갖는 경향이 있습니다. 원형으로 조립된 대규모 구조를 취하면 동일한 속도의 포트에 대한 랙 단위당 용량은 모듈식 장치의 용량보다 거의 두 배 더 좋습니다. 단일 칩을 중심으로 구축된 장치는 모듈형 장치보다 눈에 띄게 저렴하고 에너지 소비도 적습니다.

그러나 물론 이것은 모두 이유가 있으며 단점도 있습니다. 첫째, 기수는 모듈식 장치의 기수보다 거의 항상 작습니다. 128개의 포트가 있는 하나의 칩을 기반으로 구축된 장치를 얻을 수 있다면 이제는 문제 없이 수백 개의 포트가 있는 모듈식 장치를 얻을 수 있습니다.

이는 전달 테이블의 크기가 눈에 띄게 작으며 일반적으로 데이터 평면 확장성과 관련된 모든 것입니다. 얕은 버퍼. 그리고 일반적으로 기능이 다소 제한되어 있습니다. 그러나 이러한 제한 사항을 알고 제 시간에 맞춰 이를 우회하거나 단순히 고려한다면 이는 그렇게 무섭지 않은 것으로 나타났습니다. 기수가 더 작다는 사실은 최근에 마침내 등장한 128 기수를 가진 장치에서는 더 이상 문제가 되지 않습니다. 우리는 두 개의 스파인 레이어로 구축할 수 있습니다. 하지만 우리에게 흥미로운 XNUMX개보다 작은 것을 만드는 것은 여전히 ​​불가능합니다. 한 수준에서는 매우 작은 클러스터가 얻어집니다. 이전 설계와 요구 사항도 여전히 이를 초과했습니다.

실제로 갑자기 솔루션이 벼랑 끝 어딘가에 있는 경우에도 규모를 확장할 수 있는 방법이 있습니다. 서버가 연결되는 마지막(또는 첫 번째) 최하위 레벨은 ToR 스위치 또는 리프 스위치이므로 여기에 하나의 랙을 연결할 필요가 없습니다. 따라서 솔루션이 절반 정도 부족하다면 간단히 낮은 레벨에 큰 기수가 있는 스위치를 사용하고 예를 들어 XNUMX~XNUMX개의 랙을 하나의 스위치에 연결하는 것을 생각해 볼 수 있습니다. 이것도 옵션이고 비용이 들지만 꽤 잘 작동하며 크기를 두 배 정도 늘려야 할 때 좋은 솔루션이 될 수 있습니다.

요약하자면, 우리는 XNUMX개의 팩토리 레이어가 있는 두 수준의 스파인이 있는 토폴로지를 기반으로 구축하고 있습니다.

물리학은 어떻게 될까요? 매우 간단한 계산. 스파인 레벨이 1개인 경우 스위치 레벨은 세 개만 있고 네트워크에는 서버에서 리프 스위치, 스파인 2, 스파인 XNUMX까지 XNUMX개의 케이블 세그먼트가 있을 것으로 예상됩니다. 우리가 할 수 있는 옵션 용도는 Twinax, 다중 모드, 단일 모드입니다. 그리고 여기서 우리는 어떤 스트립을 사용할 수 있는지, 비용은 얼마인지, 물리적 크기는 무엇인지, 커버할 수 있는 범위는 무엇인지, 업그레이드 방법은 무엇인지 고려해야 합니다.

비용면에서는 모든 것이 줄 지어 있습니다. Twinaxes는 능동 광학 장치보다 훨씬 저렴하고 다중 모드 트랜시버보다 저렴합니다. 끝에서 비행 당 가져 가면 100기가비트 스위치 포트보다 다소 저렴합니다. 그리고 단일 모드가 필요한 비행에서는 여러 가지 이유로 데이터 센터에서 CWDM을 사용하는 것이 합리적이지만 PSM(병렬 단일 모드)은 작업하기에 그다지 편리하지 않기 때문에 단일 모드 광학보다 비용이 저렴합니다. 매우 큰 팩의 섬유가 얻어지며 이러한 기술에 초점을 맞추면 대략 다음과 같은 가격 계층 구조를 얻습니다.

한 가지 더 참고할 사항: 불행하게도 분해된 100~4x25 다중 모드 포트를 사용하는 것은 거의 불가능합니다. SFP28 트랜시버의 설계 기능으로 인해 28Gbit QSFP100보다 훨씬 저렴하지 않습니다. 그리고 다중 모드에 대한 이러한 분해는 잘 작동하지 않습니다.

또 다른 한계는 컴퓨팅 클러스터의 크기와 서버 수로 인해 데이터 센터가 물리적으로 크다는 것입니다. 이는 단일 모드로 최소한 한 번의 비행을 수행해야 함을 의미합니다. 다시 말하지만, Pod의 물리적 크기로 인해 두 개의 Twinax(구리 케이블) 스팬을 실행할 수 없습니다.

결과적으로 가격을 최적화하고 이 설계의 기하학적 구조를 고려하면 CWDM을 사용하여 트윈축 스팬, 멀티모드 스팬, 싱글모드 스팬을 얻게 됩니다. 이는 가능한 업그레이드 경로를 고려합니다.

이것이 최근의 모습이며, 우리가 어디로 향하고 있는지, 무엇이 가능한지입니다. 적어도 멀티모드와 싱글모드 모두에서 50기가비트 SerDes로 전환하는 방법은 분명합니다. 더욱이 현재와 미래의 400G용 단일 모드 트랜시버에 무엇이 있는지 살펴보면 종종 50G SerDes가 전기 측면에서 도착하더라도 레인당 100Gbps는 이미 광학 장치로 이동할 수 있습니다. 따라서 50개로 이동하는 대신 레인당 100기가비트 SerDes 및 100Gbps로 전환될 가능성이 높습니다. 왜냐하면 많은 공급업체의 약속에 따라 가용성이 곧 출시될 것으로 예상되기 때문입니다. 50G SerDes가 가장 빨랐던 기간은 그다지 길지 않을 것 같습니다. 100G SerDes의 첫 번째 복사본이 거의 내년에 출시될 예정이기 때문입니다. 그리고 얼마 후에는 아마도 합리적인 돈의 가치가 있을 것입니다.

물리학 선택에 대한 또 하나의 뉘앙스입니다. 원칙적으로 우리는 이미 400G SerDes를 사용하여 200 또는 50기가비트 포트를 사용할 수 있습니다. 그러나 앞서 말했듯이 우리는 당연히 합리적인 범위 내에서 스위치에 상당히 큰 기수를 원하기 때문에 이것이 그다지 의미가 없다는 것이 밝혀졌습니다. 우리는 128을 원합니다. 칩 용량이 제한되어 있고 링크 속도를 높이면 기수가 자연스럽게 감소하므로 기적은 없습니다.

그리고 비행기를 이용해 전체 수용능력을 늘릴 수 있고, 특별한 비용도 없이 비행기 수를 늘릴 수 있습니다. 그리고 기수를 잃으면 추가 레벨을 도입해야 하므로 현재 상황에서는 칩당 사용 가능한 최대 용량을 고려할 때 100기가비트 포트를 사용하는 것이 더 효율적이라는 것이 밝혀졌습니다. 더 큰 기수를 얻으려면.

다음 질문은 물리학이 어떻게 구성되어 있는지, 그러나 케이블 인프라의 관점에서 볼 때입니다. 다소 재미있는 방식으로 구성되어 있음이 밝혀졌습니다. 리프 스위치와 첫 번째 수준 스파인 사이의 케이블 연결 - 링크가 많지 않으며 모든 것이 비교적 간단하게 구성됩니다. 하지만 하나의 평면을 선택하면 내부에서 일어나는 일은 첫 번째 수준의 모든 척추를 두 번째 수준의 모든 척추와 연결해야 한다는 것입니다.

게다가 원칙적으로 데이터 센터 내부가 어떻게 보여야 하는지에 대한 희망 사항도 있습니다. 예를 들어, 우리는 케이블을 묶음으로 결합하고 당겨서 하나의 고밀도 패치 패널이 하나의 패치 패널로 완전히 들어가도록하여 길이 측면에서 동물원이 없도록 만들고 싶었습니다. 우리는 이 문제를 해결했습니다. 처음에 논리적 토폴로지를 살펴보면 평면이 독립적이고 각 평면이 자체적으로 구축될 수 있음을 알 수 있습니다. 그러나 이러한 번들링을 추가하고 전체 패치 패널을 패치 패널로 드래그하려면 하나의 번들 내부에 서로 다른 평면을 혼합하고 광학 교차 연결 형태로 중간 구조를 도입하여 조립된 방식에서 다시 포장해야 합니다. 한 세그먼트에서 다른 세그먼트에서 수집되는 방식입니다. 덕분에 우리는 좋은 기능을 얻었습니다. 모든 복잡한 스위칭이 랙을 벗어나지 않습니다. Clos 네트워크에서 때때로 호출되는 "평면 펼치기"와 같이 무언가를 매우 강력하게 엮어야 할 때 모든 것이 하나의 랙 안에 집중됩니다. 우리는 랙 간을 전환하는 개별 링크까지 고도로 분해되지 않았습니다.

이것이 케이블 인프라의 논리적 구성 관점에서 본 모습입니다. 왼쪽 그림에서 여러 색상의 블록은 첫 번째 레벨 스파인 스위치 블록(각각 2개 조각)과 이 블록에서 나오는 케이블 묶음 XNUMX개를 나타냅니다. 이 블록은 스파인-XNUMX 스위치 블록에서 나오는 묶음과 교차합니다. .

작은 사각형은 교차점을 나타냅니다. 왼쪽 상단에는 이러한 각 교차점에 대한 분석이 있습니다. 이는 실제로 케이블을 다시 포장하여 하나의 스파인-512 평면만 있는 하나의 랙에 완전히 들어가도록 하는 512 x 2 포트 교차 연결 모듈입니다. 오른쪽에 있는 이 사진의 스캔은 척추 1 수준의 여러 포드와 교차 연결로 패키징되는 방식, 척추 2 수준에 도달하는 방식과 관련하여 좀 더 자세히 설명되어 있습니다.

이것이 어떻게 생겼는지입니다. 아직 완전히 조립되지 않은 Spine-2 스탠드(왼쪽)와 교차 연결 스탠드. 불행히도 거기에는 볼거리가 많지 않습니다. 이 전체 구조는 현재 확장 중인 대규모 데이터 센터 중 하나에 배포되고 있습니다. 이것은 진행 중인 작업이므로 더 보기 좋고, 더 잘 채워질 것입니다.

중요한 질문: 우리는 논리적 토폴로지를 선택하고 물리학을 구축했습니다. 컨트롤 플레인은 어떻게 되나요? 운영 경험을 통해 잘 알려져 있으며 링크 상태 프로토콜이 좋다는 보고가 많이 있습니다. 이를 사용하여 작업하는 것이 즐겁지만 안타깝게도 조밀하게 연결된 토폴로지에서는 확장이 잘 되지 않습니다. 그리고 이를 방지하는 한 가지 주요 요소가 있습니다. 이것이 바로 링크 상태 프로토콜에서 플러딩이 작동하는 방식입니다. 플러딩 알고리즘을 사용하여 네트워크가 어떻게 구성되어 있는지 살펴보면 각 단계에서 매우 큰 팬아웃이 발생하고 제어 플레인에 업데이트가 쇄도한다는 것을 알 수 있습니다. 특히 이러한 토폴로지는 링크 상태 프로토콜의 기존 플러딩 알고리즘과 매우 잘 혼합되지 않습니다.

선택은 BGP를 사용하는 것입니다. 이를 올바르게 준비하는 방법은 대규모 데이터 센터에서의 BGP 사용에 대한 RFC 7938에 설명되어 있습니다. 기본 아이디어는 간단합니다. 호스트당 최소 접두사 수와 일반적으로 네트워크의 최소 접두사 수, 가능한 경우 집계를 사용하고 경로 찾기를 억제합니다. 우리는 밸리 프리(Valley Free)라고 불리는 매우 신중하고 통제된 업데이트 배포를 원합니다. 우리는 업데이트가 네트워크를 통과할 때 정확히 한 번 배포되기를 원합니다. 바닥에서 시작되면 위로 올라가서 한 번만 펼쳐집니다. 지그재그가 있어서는 안됩니다. 지그재그는 매우 나쁩니다.

이를 위해 기본 BGP 메커니즘을 사용할 수 있을 만큼 간단한 설계를 사용합니다. 즉, 링크 로컬에서 실행되는 eBGP를 사용하며, 자율 시스템은 ToR의 자율 시스템, 하나의 Pod의 전체 스파인-1 스위치 블록의 자율 시스템, 전체 Top의 일반 자율 시스템으로 할당됩니다. 직물의. BGP의 정상적인 동작조차도 우리가 원하는 업데이트 배포를 제공한다는 것을 확인하는 것은 어렵지 않습니다.

당연히 주소 지정 및 주소 집계는 라우팅이 구축되는 방식과 호환되도록 설계되어야 제어 평면의 안정성이 보장됩니다. 전송 시 L3 주소 지정은 토폴로지에 연결되어 있습니다. 이것이 없으면 집계를 달성할 수 없기 때문입니다. 이것이 없으면 개별 주소가 라우팅 시스템에 들어갑니다. 그리고 한 가지 더, 안타깝게도 집계는 다중 경로와 잘 섞이지 않습니다. 다중 경로가 있고 집계가 있으면 모든 것이 괜찮지만 전체 네트워크가 건강하면 오류가 없기 때문입니다. 불행하게도 네트워크에 장애가 나타나고 토폴로지의 대칭성이 상실되면 장치가 발표된 지점에 도달할 수 있으며 더 이상 가야 할 곳으로 갈 수 없습니다. 따라서 더 이상 다중 경로가 없는 곳(우리의 경우 ToR 스위치)을 집계하는 것이 가장 좋습니다.

실제로 집계는 가능하지만 신중하게 수행됩니다. 네트워크 장애가 발생할 때 제어된 분리를 수행할 수 있는 경우. 그러나 이것은 꽤 어려운 작업입니다. 우리는 이것이 가능한지, 추가 자동화를 추가하는 것이 가능한지, 원하는 동작을 얻기 위해 BGP를 올바르게 실행하는 유한 상태 머신이 가능한지 궁금했습니다. 불행하게도 코너 케이스 처리는 매우 불분명하고 복잡하며, BGP에 외부 첨부 파일을 연결하는 것만으로는 이 작업이 잘 해결되지 않습니다.

이와 관련하여 매우 흥미로운 작업이 RIFT 프로토콜의 프레임워크 내에서 수행되었으며 이에 대해서는 다음 보고서에서 논의됩니다.

또 다른 중요한 점은 대체 경로가 많은 밀집된 토폴로지에서 데이터 플레인이 어떻게 확장되는지입니다. 이 경우 다음 홉 그룹을 설명하는 ECMP 그룹과 같은 몇 가지 추가 데이터 구조가 사용됩니다.

정상적으로 작동하는 네트워크에서는 장애 없이 Clos 토폴로지를 올라갈 때 하나의 그룹만 사용하면 충분합니다. 로컬이 아닌 모든 것이 기본적으로 설명되어 있기 때문에 올라갈 수 있습니다. 위에서 아래로 남쪽으로 이동하면 모든 경로가 ECMP가 아니라 단일 경로 경로입니다. 모든 것이 괜찮습니다. 문제는 고전적인 Clos 토폴로지의 특징은 패브릭의 상단을 보면 어떤 요소에서든 아래 요소에 대한 경로가 하나만 있다는 것입니다. 이 경로를 따라 오류가 발생하면 팩토리 상단에 있는 이 특정 요소는 끊어진 경로 뒤에 있는 접두사에 대해 정확하게 유효하지 않게 됩니다. 그러나 나머지에 대해서는 유효하므로 ECMP 그룹을 구문 분석하고 새로운 상태를 도입해야 합니다.

최신 장치에서 데이터 평면 확장성은 어떤 모습입니까? LPM(최장 접두사 일치)을 수행하면 100개가 넘는 접두사가 있어 모든 것이 꽤 좋습니다. Next Hop 그룹에 대해 이야기하고 있다면 모든 것이 2-4으로 더 나쁩니다. 다음 홉(또는 인접성)에 대한 설명이 포함된 테이블에 대해 이야기하고 있다면 이는 16k에서 64k 사이입니다. 그리고 이것이 문제가 될 수 있습니다. 그리고 여기에서 흥미로운 여담이 나옵니다. 데이터 센터의 MPLS에 무슨 일이 일어났습니까? 원칙적으로 우리는 그것을 하고 싶었습니다.

두 가지 일이 일어났습니다. 호스트에서 마이크로 세분화를 수행했지만 더 이상 네트워크에서 수행할 필요가 없었습니다. 다양한 공급업체의 지원은 그리 좋지 않았으며 MPLS가 포함된 화이트 박스에 대한 개방형 구현의 경우 더욱 그렇습니다. 불행히도 적어도 전통적인 구현인 MPLS는 ECMP와 매우 잘 결합되지 않습니다. 그것이 바로 그 이유입니다.

IP에 대한 ECMP 전달 구조는 다음과 같습니다. 많은 수의 접두사가 동일한 그룹 및 동일한 다음 홉 블록(또는 인접성, 이는 장치마다 다른 문서에서 다르게 호출될 수 있음)을 사용할 수 있습니다. 요점은 이것이 나가는 포트로 설명되고 올바른 다음 홉에 도달하기 위해 MAC 주소를 다시 써야 한다는 것입니다. IP의 경우 모든 것이 단순해 보입니다. 동일한 그룹, 동일한 Next Hops 블록에 매우 많은 수의 접두사를 사용할 수 있습니다.

전통적인 MPLS 아키텍처는 나가는 인터페이스에 따라 레이블을 다른 값으로 다시 쓸 수 있음을 의미합니다. 따라서 각 입력 레이블에 대해 그룹과 다음 홉 블록을 유지해야 합니다. 그리고 아쉽게도 이것은 확장되지 않습니다.

우리 설계에서는 약 4000개의 ToR 스위치가 필요했고 스파인-64에서 스파인-1 방향으로 이동할 경우 최대 너비는 2개의 ECMP 경로라는 것을 쉽게 알 수 있습니다. ToR이 있는 접두사 하나만 사라지면 ECMP 그룹 테이블 하나에 간신히 들어가고 Next Hops 테이블에는 전혀 들어가지 않습니다.

세그먼트 라우팅과 같은 아키텍처에는 전역 레이블이 포함되므로 절망적이지는 않습니다. 공식적으로는 이러한 모든 Next Hop 블록을 다시 축소할 수 있습니다. 이렇게 하려면 와일드카드 유형 작업이 필요합니다. 즉, 레이블을 가져와 특정 값 없이 동일한 레이블에 다시 작성합니다. 그러나 불행히도 이는 사용 가능한 구현에는 거의 존재하지 않습니다.

마지막으로 외부 트래픽을 데이터 센터로 가져와야 합니다. 어떻게 하나요? 이전에는 트래픽이 위에서 Clos 네트워크로 유입되었습니다. 즉, Fabric의 Top에는 모든 Device와 연결되는 Edge Router가 존재합니다. 이 솔루션은 중소 규모에서 매우 잘 작동합니다. 불행하게도 이런 식으로 전체 네트워크에 대칭적으로 트래픽을 전송하려면 Top of fabric의 모든 요소에 동시에 도착해야 하며, 그 수가 XNUMX개 이상이면 대규모도 필요하다는 것이 밝혀졌습니다. 에지 라우터의 기수. 일반적으로 에지 라우터는 기능이 더 뛰어나고 포트가 더 비싸며 디자인이 그다지 아름답지 않기 때문에 비용이 많이 듭니다.

또 다른 옵션은 아래에서 이러한 트래픽을 시작하는 것입니다. Clos 토폴로지는 아래, 즉 ToR 측에서 들어오는 트래픽이 두 번의 반복으로 전체 패브릭 상단의 레벨 간에 균등하게 분산되어 전체 네트워크를 로드하는 방식으로 구축되었음을 쉽게 확인할 수 있습니다. 따라서 외부 연결을 제공하는 특별한 유형의 Pod인 Edge Pod를 소개합니다.

옵션이 하나 더 있습니다. 예를 들어 이것이 Facebook이 하는 일입니다. 그들은 이를 Fabric Aggregator 또는 HGRID라고 부릅니다. 여러 데이터 센터를 연결하기 위해 추가 스파인 레벨이 도입되었습니다. 이 디자인은 인터페이스에 추가 기능이나 캡슐화 변경이 없으면 가능합니다. 추가적인 터치포인트라면 어렵습니다. 일반적으로 데이터 센터의 여러 부분을 분리하는 더 많은 기능과 일종의 막이 있습니다. 이러한 멤브레인을 크게 만드는 것은 의미가 없지만 어떤 이유로 실제로 필요한 경우 제거 가능성을 고려하여 가능한 한 넓게 만들어 호스트에 전달하는 것이 합리적입니다. 예를 들어 이는 많은 클라우드 운영자에 의해 수행됩니다. 오버레이가 있으며 호스트에서 시작됩니다.

우리는 어떤 개발 기회를 보나요? 우선 CI/CD 파이프라인에 대한 지원을 개선합니다. 우리는 우리가 비행하는 방식을 테스트하고 테스트하는 방식으로 비행하기를 원합니다. 인프라가 크고 테스트를 위해 복제하는 것이 불가능하기 때문에 이는 잘 작동하지 않습니다. 테스트 요소를 삭제하지 않고 프로덕션 인프라에 도입하는 방법을 이해해야 합니다.

더 나은 계측과 더 나은 모니터링은 결코 불필요한 일이 아닙니다. 전체적인 질문은 노력과 수익의 균형입니다. 합당한 노력으로 추가할 수 있다면 매우 좋습니다.

네트워크 장치용 개방형 운영 체제. RIFT와 같은 더 나은 프로토콜과 더 나은 라우팅 시스템. 더 나은 혼잡 제어 방식을 사용하고 적어도 일부 지점에서는 클러스터 내에서 RDMA 지원을 도입하는 방법에 대한 연구가 필요합니다.

더 먼 미래를 내다보면 고급 토폴로지와 오버헤드를 덜 사용하는 네트워크가 필요할 수도 있습니다. 새로운 것 중 최근에는 상용 이더넷을 기반으로 하지만 훨씬 더 짧은 헤더를 사용할 수 있는 옵션이 있는 HPC Cray Slingshot용 패브릭 기술에 대한 출판물이 있었습니다. 결과적으로 오버헤드가 감소됩니다.

모든 것은 가능한 한 단순하게 유지되어야 하지만 단순해서는 안 됩니다. 복잡성은 확장성의 적입니다. 단순성과 규칙적인 구조는 우리의 친구입니다. 어딘가에서 규모 확장을 할 수 있다면 그렇게 하세요. 그리고 일반적으로 지금 네트워크 기술에 참여하는 것이 좋습니다. 많은 흥미로운 일들이 일어나고 있습니다. 감사합니다.

출처 : habr.com