IP 패브릭 위의 Calico

스케일아웃이나 클라우드 환경에서 Calico가 엔드포인트를 연결하는 엔드투엔드 IP 네트워크를 제공하는 방식을 다뤄요. Calico가 동작하려면 그 밑바탕이 되는 물리 네트워킹 계층, 즉 상호 연결 패브릭(interconnect fabric)이 필요해요. BGP 토폴로지 선택지와 라우트 전파 방식을 중심으로 레퍼런스를 정리했어요.

출처: 문서

본문

Calico는 스케일아웃이나 클라우드 환경에서 엔드포인트(주석 1)를 상호 연결하는 엔드투엔드 IP 네트워크를 제공해요. 그러려면 Calico가 동작할 물리 네트워킹 계층을 제공하는 *상호 연결 패브릭(interconnect fabric)*이 필요해요(주석 2).

Calico는 IP 트래픽을 지원할 수 있는 어떤 상호 연결 패브릭 위에서든 동작하도록 설계됐지만, 구현 시 고려할 점이 가장 적은 패브릭은 이더넷 패브릭 위의 Calico에서 다루는 이더넷 패브릭이에요.

대부분의 경우 이더넷 패브릭이 적절한 선택이지만, L3(IP 패브릭)가 이미 배포되어 있거나 배포될 예정인 인프라도 있고, 그런 환경에서 Calico가 동작하는 게 자연스러울 때도 있어요.

다만 Calico 자체가 라우티드 인프라이기 때문에, IP 라우티드 상호 연결 패브릭과 함께 Calico를 운영할 때는 저울질해야 할 엔지니어링·아키텍처·운영 고려 사항이 더 많아요. 이 글의 나머지 부분에서 그것들을 간략히 정리해요. 그렇다고 해도, Calico는 이더넷 패브릭이든 IP 패브릭이든 똑같이 잘 동작해요.

배경

Calico 기본 아키텍처 개요

Calico 아키텍처에 대한 설명은 아키텍처 개요 문서에서 볼 수 있어요. 다만 이 논의를 위해서는 라우팅과 데이터 경로에 대한 간단한 짚고 넘어가기가 도움이 돼요.

Calico 네트워크에서 각 컴퓨트 서버는 그 서버에 올라간 모든 엔드포인트의 라우터 역할을 해요. 이 기능을 vRouter라고 불러요. 데이터 경로는 Linux 커널이, 컨트롤 플레인은 BGP 프로토콜 서버가, 관리 플레인은 Calico의 서버 에이전트인 Felix가 담당해요.

각 엔드포인트는 자신의 로컬 vRouter를 통해서만 통신할 수 있고, Calico 패킷 흐름의 첫 번째이자 마지막 *홉(hop)*은 항상 vRouter를 거치는 IP 라우터 홉이에요. 각 vRouter는 자신에게 붙어 있는 모든 엔드포인트를, 인프라 패브릭 위의 다른 vRouter들과 라우터들에게 BGP로 광고해요. 보통은 규모를 늘리기 위해 BGP 라우트 리플렉터를 함께 써요. BGP를 쓰는 이유에 대한 논의는 Why BGP?에서 볼 수 있어요.

액세스 컨트롤 리스트(ACL)는 사용 중인 클라우드 오케스트레이터의 지시에 따라 보안(그 외) 정책을 강제해요. Calico 아키텍처에는 다른 컴포넌트들도 있지만, 상호 연결 네트워크 패브릭 논의와는 관련이 없어요.

현재 흔한 IP 스케일아웃 패브릭 아키텍처 개요

스케일아웃 인프라를 위한 IP 패브릭을 만드는 방식은 두 가지예요. 다만 지금까지의 모든 방식은 인프라의 에지 라우터가 랙 상단(TOR, top of rack) 스위치라고 가정해 왔어요. Calico 모델에서는 그 기능을 컴퓨트 서버 자신에게 밀어 넣어요.

두 가지 방식은 다음과 같아요:

라우팅 인프라가 일종의 IGP에 기반하는 방식

IGP 네트워크의 확장 한계 때문에, Calico 팀은 IGP로 엔드포인트 도달 가능성 정보를 배포하는 방식이 Calico 환경에서 충분히 확장되지 않는다고 봐요. 다만 상호 연결 패브릭에서 IGP와 BGP를 조합하는 건 가능해요. IGP가 다음 홉(next-hop) 라우터로의 경로를 전달하고(Calico에서는 흔히 목적지 컴퓨트 서버가 다음 홉이에요), BGP가 특정 엔드포인트의 실제 다음 홉을 배포하는 식이에요. 이는 유효한 모델이고, 실제로 광역으로 분산된 IP 네트워크(예: 통신사 백본 네트워크)에서 가장 흔한 접근이기도 해요. 다만 이런 네트워크의 설계는 다소 복잡해서 이 글에서 더 다루지는 않아요(주석 3).

라우팅 인프라가 전적으로 BGP에 기반하는 방식

이 모델에서는 IP 네트워크가 "충분히 조밀하거나" 지름이 충분히 작아서 BGP로 엔드포인트 라우트를 배포할 수 있고, 그 라우트들의 다음 홉으로 가는 경로를 네트워크의 모든 라우터가 알고 있어요(Calico 네트워크에서는 컴퓨트 서버도 여기에 포함돼요). 이 글이 다루는 네트워크 모델은 이것이에요.

이 글에서는 스케일아웃 세계에서 더 흔한 두 번째 선택지를 다룰 거예요.

BGP 전용 상호 연결 패브릭

BGP 전용 상호 연결 패브릭을 만드는 방법은 여러 가지가 있어요. 여기서는 각각 널리 쓸 만한 변형이 두 개씩 있는 세 가지 모델에 집중해요. 다른 선택지들도 있고, 일부를 왜 포함하지 않았는지는 기타 선택지에서 간단히 짚을 거예요.

두 가지 방식은 다음과 같아요:

• 각 TOR 스위치(와 그 아래 컴퓨트 서버들)가 고유한 자율 시스템(AS, Autonomous System)이고, 리프/스파인 아키텍처에서 스파인 스위치가 제공하는 이더넷 스위칭 플레인을 통해, 혹은 각각이 고유한 AS인 스파인 스위치 집합을 통해 상호 연결되는 BGP 패브릭이에요. 이를 랙별 AS(AS per rack) 모델이라고 부를게요. 이 모델은 IETF RFC 7938에 자세히 나와 있어요.

• 각 컴퓨트 서버가 고유한 AS이고, TOR 스위치들이 하나의 트랜짓 AS를 이루는 BGP 패브릭이에요. 이를 서버별 AS(AS per server) 모델이라고 부를게요.

이 모델들은 모두 이더넷 스파인이나 IP 스파인을 가질 수 있어요. 이더넷 스파인인 경우 각 스파인 스위치는 Calico 이더넷 상호 연결 패브릭 모델처럼 격리된 이더넷 연결 플레인을 제공하고, 각 TOR 스위치는 모든 스파인 스위치에 연결돼요.

또 다른 모델은 각 스파인 스위치가 고유한 AS이고, 각 TOR 스위치가 모든 스파인 스위치와 BGP 피어링하는 방식이에요. 두 경우 모두 TOR 스위치는 ECMP로 이용 가능한 모든 스파인 스위치에 트래픽을 로드 밸런싱해요.

BGP 네트워크 설계 고려 사항

흔한 인식과는 달리 BGP는 사실 꽤 단순한 프로토콜이에요. 예를 들어 Calico 컴퓨트 서버의 BGP 설정은 주석을 제외하면 대략 60줄 정도밖에 안 돼요. 복잡해 보이는 건 BGP로 할 수 있는 것들 때문이에요. BGP 활용 사례 상당수는 복잡한 정책 규칙을 포함하고, 기술적(혹은 비즈니스·재무·정치적 등) 요구를 맞추기 위해 BGP의 동작을 바꿔요. 기본 Calico 네트워크는 그런 영역에 발을 들이지 않기 때문에(주석 4) 비교적 단순 명료해요.

그렇다고 해도, Calico 네트워크의 노드들을 상호 연결할 IP 패브릭을 설계할 때는 BGP 설계 규칙 몇 가지를 기억해야 해요. 이 BGP 설계 요구 사항은 필요하면 우회할 수도 있지만, 그러려면 표준 BGP *범위(envelope)*를 벗어나게 되고, 고급 BGP 설계에 매우 익숙한 구현자만 시도해야 해요.

고려 사항은 다음과 같아요:

• AS 연속성, 혹은 AS 퍼들링(AS puddling)

  어떤 AS 안의 라우터는 다른 AS를 거치지 않고 같은 AS 안의 어떤 라우터와도 통신할 수 있어야 반드시 해요.

• 다음 홉 동작

  기본적으로 BGP 라우터는 같은 AS 안의 라우터와 피어링할 때 라우트의 *다음 홉(next hop)*을 바꾸지 않아요. 반대도 마찬가지예요. 다른 AS의 라우터와 피어링하면 BGP 라우터는 자신을 라우트의 다음 홉으로 설정해요.

• 라우트 리플렉션

  어떤 AS의 모든 BGP 라우터는 그 AS의 다른 모든 라우터와 피어링해야 해요. 이를 *완전 BGP 메시(complete BGP mesh)*라고 불러요. AS의 라우터 수가 늘어나면 이것이 문제가 될 수 있어요. *라우트 리플렉터(route reflector)*를 쓰면 완전 메시의 필요를 줄일 수 있어요. 하지만 라우트 리플렉터에도 확장성 고려 사항이 있어요.

• 엔드포인트

  Calico 네트워크에서 각 엔드포인트는 곧 라우트예요. 하드웨어 네트워킹 플랫폼은 학습할 수 있는 라우트 수의 제약을 받아요. 보통 만 단위에서 십만 단위 수준이에요. 라우트 집계(aggregation)가 도움이 되지만, 보통은 오케스트레이션 소프트웨어(예: OpenStack)가 쓰는 스케줄러의 기능에 좌우돼요.

이 고려 사항들에 대한 더 깊은 논의는 IP 패브릭 설계 고려 사항에서 볼 수 있어요.

아래에서 다룰 설계들이 바로 이 고려 사항들을 다뤄요.

랙별 AS 모델

이 모델은 IETF RFC 7938이 제안한 모델과 가장 가까워요.

앞서 말했듯이 이 모델에는 두 가지 버전이 있어요. 하나는 ToR 스위치들을 상호 연결하는 이더넷 플레인 집합을 두는 버전이고, 다른 하나는 코어 플레인도 라우터인 버전이에요. 다음 다이어그램이 논의에 도움이 될 거예요.

위 다이어그램은 ToR 스위치들이 이더넷 스위칭 플레인 집합으로 물리적으로 메시를 이루는 랙별 AS 모델을 보여 줘요.

위 다이어그램은 ToR 스위치들이 각자 고유한 AS를 가진 개별 BGP 스파인 라우터 집합으로 물리적으로 메시를 이루는 랙별 AS 모델을 보여 줘요.

이 접근에서는 모든 ToR-ToR 또는 ToR-스파인(스파인별 AS인 경우) 링크가 eBGP 피어링이에요. 즉 ToR 스위치 *북쪽(상위)*에서는 (표준 BGP 라우트 리플렉터를 사용한) 라우트 리플렉션이 불가능해요.

L2 스파인 옵션을 쓰면 그 결과 각 ToR은 클러스터의 다른 모든 ToR 스위치와 피어링해야 해요(수백 개의 피어가 될 수 있어요).

스파인별 AS 옵션을 쓰면 각 ToR은 각 스파인과만 피어링하면 돼요(한 파드에 보통 2개에서 16개 사이의 스파인 스위치가 있어요). 다만 스파인 스위치들은 모든 ToR 스위치와 피어링해야 해요(이것 역시 수백 개지만, 대부분의 스파인 스위치는 평균적인 ToR보다 컨트롤 플레인 용량이 크기 때문에 많은 상황에서 이쪽이 더 확장성이 좋을 수 있어요).

랙 안의 구성은 두 변형 모두에서 같고, ToR 북쪽(상위)의 구성과는 다소 달라요.

랙 안의 모든 라우터, 즉 Calico의 경우 모든 컴퓨트 서버는,

자신이 연결된 ToR과 같은 AS를 공유해요.

그 연결은 이더넷 스위칭 계층 형태로 이뤄져요. AS가 연속적으로 유지되려면 랙 안의 각 라우터가 직접 연결되어야 해요. ToR의 라우터 기능 역시 그 이더넷 스위칭 계층에 연결돼요. 실제 구성은 사용하는 ToR에 따라 다르지만, 보통 컴퓨트 서버에 연결된 포트를 서브넷 또는 세그먼트 포트로 취급하고, ToR의 라우터 기능이 그 서브넷으로 단일 인터페이스를 갖는 식이에요.

이 구성 덕분에 랙 안의 각 컴퓨트 서버는 ToR 라우터를 거치지 않고 랙 안의 다른 컴퓨트 서버에 연결할 수 있지만, 물론 ToR 스위칭 기능은 거쳐요. 컴퓨트 서버들과 ToR 라우터를 모두 직접 메시로 연결할 수도 있고, 랙 안에서 라우트 리플렉터를 쓸 수도 있어요. 라우트 리플렉터는 ToR 자체에서 호스팅하거나, 랙 안의 한 개 이상 컴퓨트 서버에서 가상 기능으로 호스팅할 수 있어요.

ToR은 eBGP 라우터로서, 다른 ToR들의 라우트와 데이터 센터 외부의 라우트를 자신의 AS에 속한 컴퓨트 서버들에게 재배포하고, AS(랙) 안에서 온 모든 라우트를 다른 ToR들과 더 넓은 세상에 광고해요. 즉 각 컴퓨트 서버는 모든 외부 라우트의 다음 홉을 ToR로 보고, 랙 내부의 모든 라우트에 대해서는 개별 컴퓨트 서버들이 다음 홉이 돼요.

컴퓨트 서버별 AS 모델

이 모델은 랙별 AS 개념을 논리적 귀결까지 밀어간 거예요. 앞서 언급한 IETF RFC 7938의 전체 모델에서는 ToR이 1차 계층의 집계·라우팅 요소라고 가정해요. Calico에서는 ToR이, L3 라우터라면, 실제로는 2차 계층이에요. 기억하세요. Calico에서 컴퓨트 서버는 항상 엔드포인트의 첫 번째/마지막 라우터이자 첫 번째/마지막 집계 지점이에요.

따라서 이 드래프트의 아키텍처를 따르자면 AS 경계는 ToR이 아니라 컴퓨트 서버가 되어야 해요. 그 차이는 다음 두 다이어그램에서 볼 수 있어요.

위 다이어그램은 ToR 스위치들이 이더넷 스위칭 플레인 집합으로 물리적으로 메시를 이루는 컴퓨트 서버별 AS 모델을 보여 줘요.

위 다이어그램은 ToR 스위치들이 독립적인 라우팅 플레인 집합에 물리적으로 연결되는 컴퓨트 서버별 AS 모델을 보여 줘요.

이 다이어그램들에서 볼 수 있듯이 랙별 AS 모델과 같은 두 변형이 그대로 있어요. 하나는 스파인 스위치들이 ToR 스위치를 상호 연결하는 독립 이더넷 플레인 집합을 제공하는 방식이고, 다른 하나는 그 일을 독립 라우터 집합이 하는 방식이에요.

이 모델의 진짜 차이는 컴퓨트 서버와 ToR 스위치가 모두 독립적인 자율 시스템이라는 점이에요. 이것을 규모 있게 동작하게 하려면 RFC 4893에서 논의된 4바이트 AS 번호를 사용해야 해요. 4바이트 AS 번호를 쓰지 않으면 Calico 패브릭에 들어갈 수 있는 ToR과 컴퓨트 서버의 총수가 약 5천 개의 사설 AS(주석 5) 번호로 제한돼요. 4바이트 AS 번호를 쓰면 약 9,200만 개의 사설 AS 번호를 쓸 수 있으니 어떤 Calico 패브릭에도 충분할 거예요.

이 모델이 랙별 AS 모델과 다른 또 하나는 라우트 리플렉터를 쓰지 않는다는 점이에요. 모든 BGP 피어링이 eBGP거든요. 이 경우 주어진 랙의 각 컴퓨트 서버는 eBGP 라우터 역할도 하는 자신의 ToR 스위치와 피어링해요. 같은 랙의 두 서버가 통신하려면 ToR을 통해 라우팅돼요. 따라서 각 서버는 자신이 연결된 각 ToR마다 하나의 피어링을 갖고, 각 ToR은 자신이 연결된 각 컴퓨트 서버(보통 랙의 모든 컴퓨트 서버)와 피어링을 가져요.

ToR 간 연결에 대한 고려 사항은 규모와 범위 면에서 랙별 AS 모델과 같아요.

다운워드 디폴트 모델

마지막 모델은 조금 달라요. 앞선 모델들에서는 인프라의 모든 라우터가 전체 라우팅 테이블을 갖고 AS 경로를 그대로 유지했지만, 이 모델(주석 6)은 라우팅 경로의 각 단계에서 AS 번호를 제거해요. 이는 로컬 AS에서 온 라우트(출발지와 목적지가 같은 AS를 공유하므로)가 설치되지 못하는 일을 막기 위해서예요.

다음 다이어그램이 이 모델의 AS 관계를 보여 줘요.

위 다이어그램은 모든 Calico 노드가 같은 AS 번호를 공유하고, 모든 ToR 스위치도 같은 AS 번호를 공유함을 보여 줘요. 다만 이 AS들은 서로 달라요(A1은 A2와 같은 네트워크가 아니에요. 둘 다 같은 AS 번호 A를 공유할 뿐이에요).

모든 ToR 스위치에 하나의 AS를, 모든 컴퓨트 서버에 다른 하나의 AS를 쓰면 배포가 단순해져요(구성 표준화). 하지만 진짜 이점은 ToR 스위치의 라우팅 테이블을 덜어 내는 데 있어요.

이 모델에서 각 라우터는 자신의 모든 라우트를 업스트림 피어에게 광고해요(Calico 라우터는 자신의 ToR에게, ToR은 스파인 스위치에게). 대신 업스트림 라우터는 디폴트 라우트만 광고해요. 그러면 주어진 Calico 라우터는 로컬에 호스팅된 엔드포인트의 라우트와 ToR에서 온 디폴트만 갖게 돼요. ToR이 Calico 네트워크에서 나머지 네트워크로 가는 유일한 경로이기 때문에 이것은 실제와 일치해요. ToR 스위치와 스파인 사이에서도 같은 일이 일어나요. 즉 ToR은 자신의 다운스트림 Calico 노드에 호스팅된 엔드포인트의 라우트만 설치하면 돼요. Calico 노드당 200개의 엔드포인트를, 랙마다 80개의 Calico 노드를 넣는다 해도 ToR의 라우팅 테이블은 최대 16,000 엔트리로 제한돼요(가장 소박한 스위치 능력 안에서도 충분히 여유 있는 수준이에요).

디폴트가 원래 스파인에서 시작되기 때문에, 아래로 광고된 라우트가 수신자의 AS에서 시작될 일이 없어요. 그래서 AS 퍼들링 문제를 예방해요.

이 모델에는 (사소한) 단점이 하나 있어요. 유효하지 않은 목적지(존재하지 않는 목적지 IP)로 향하는 모든 트래픽이 폐기되기 전에 스파인 스위치로 포워딩된다는 점이에요.

또한 스파인 스위치는 앞선 예제의 라우티드 스파인에서 그랬던 것처럼 Calico 네트워크의 모든 라우트를 실어야 한다는 점도 유의하세요. 요컨대 이 모델은 스파인에 새로운 부하를 더하지 않고, ToR 스위치가 쓰는 라우팅 테이블 공간을 크게 줄여요. Calico 노드의 라우트 수도 줄어들지만, 앞서 논의했듯 대부분의 배포에서는 그것이 문제 되지 않아요. Calico의 전체 라우팅 테이블이 쓰는 메모리는 최신 컴퓨트 서버의 전체 메모리에서 아주 작은 비율이거든요.

권장 사항

결과로 나오는 라우팅 테이블 크기를 ToR과 스파인 스위치가 감당할 수 있다면(예상 성장까지 고려하는 걸 잊지 마세요), Calico 팀은 랙별 AS 모델을 권장해요.

ToR 스위치의 라우트 테이블 크기가 걱정된다면 Calico는 다운워드 디폴트 모델을 권장해요.

스파인과 ToR 스위치의 라우트 테이블 용량이 모두 걱정되거나, Calico 노드를 연결할 아주 단순한 L2 패브릭을 운영하고 싶다면 이더넷 패브릭 위의 Calico에 자세히 나온 이더넷 패브릭을 고려하세요.

컴퓨트 서버별 AS에 관심이 있다면, Calico 팀도 그 모델의 배포를 논의하는 일에 아주 관심이 많아요.

기타 선택지

이 글과 이더넷 패브릭에서 물리적·논리적 연결성을 배치한 방식에서는, 주어진 라우트의 다음 홉 라우터가 항상 그 라우트를 받는 라우터와 직접 연결돼 있어요. 그래서 다음 홉 라우트를 배포할 다른 프로토콜이 필요 없어요.

하지만 많은(혹은 대부분의) WAN BGP 네트워크에서는 주어진 AS 안의 라우터들이 직접 인접하지 않을 수 있어요. 따라서 라우터가 직접 인접하지 않은 다음 홉 주소를 가진 라우트를 받을 수도 있어요. 그런 경우 주어진 AS 안의 라우터들이 OSPF나 IS-IS 같은 IGP를 사용해 BGP 다음 홉 라우트로의 경로를 결정해요.

주어진 AS 안의 라우터들이 직접 인접하지 않은 비슷한 모델의 Calico 아키텍처가 있을 수도 있어요. 그런 모델에서는 Calico에서 IGP를 사용하는 것이 정당화될 수 있어요. 다만 그 프로토콜들의 구성은 이 기술 노트의 범위 밖이에요.

IP 패브릭 설계 고려 사항

AS 퍼들링

첫 번째 고려 사항은 AS가 연속적(contiguous)으로 유지되어야 한다는 것이에요. 즉 주어진 AS의 어떤 두 노드도 다른 AS를 거치지 않고 통신할 수 있어야 해요. 이 규칙을 지키지 않으면 흔히 *AS 퍼들링(AS puddling)*이라고 부르는 현상이 생기고, 네트워크는 올바르게 동작하지 않아요.

이 규칙의 필연적 귀결 하나는, 같은 AS 번호를 공유하는 두 개의 관리 영역은 설계자가 그러길 원하지 않았더라도 같은 AS에 속한다는 것이에요. BGP는 AS 번호 외에는 어떤 AS가 로컬인지 외부인지 식별할 방법이 없어요. 따라서 직접 연결되지 않고 오직 다른 네트워크나 AS 번호를 통해서만 연결된 두 네트워크에 같은 AS 번호를 재사용하면, BGP 라우터에 대단히 많은 정책 변경을 하지 않는 한 동작하지 않아요.

이 규칙의 또 다른 귀결은, 라우트의 경로에 피어와 같은 AS가 들어 있으면 BGP 라우터가 그 라우트를 피어에게 전파하지 않는다는 것이에요.

이 덕분에 네트워크에서 루프가 생기는 것을 막아 줘요. 그 효과로 같은 AS 안의 두 라우터가 다른 라우터(그 AS에 속했든 아니든)를 경유하지 못하게 해요.

다음 홉 동작

또 하나의 고려 사항은 iBGP와 eBGP의 차이에 근거해요. BGP는 두 가지 모드로 동작해요. 두 라우터가 BGP 피어인데 같은 AS 번호를 공유하면 내부(internal) BGP(iBGP) 피어링 관계에 있다고 봐요. 서로 다른 AS의 멤버라면 외부(external), 즉 eBGP 관계에 있어요.

BGP의 원래 설계 모델은, 주어진 AS 안의 모든 BGP 라우터가 서로에게 어떻게 도달하는지 알고(정적 라우트나 IGP(주석 7) 라우팅 프로토콜 등을 통해), 서로 다른 AS의 라우터는 직접 연결되어 있지 않으면 서로에게 도달하는 방법을 모른다는 것이었어요.

이 설계 관점에 근거해, iBGP 피어링 관계의 라우터들은 주어진 AS 안의 다른 iBGP 라우터를 위해 트래픽을 경유시키지 않는다고 가정해요(즉 A가 C와 통신할 수 있으므로 B를 통해 라우팅할 필요가 없어요). 그래서 BGP의 다음 홉 속성을 바꾸지 않아요(주석 8).

반면 eBGP 피어링을 가진 라우터는 자신의 eBGP 피어가 다음 홉 라우트에 도달하는 방법을 모른다고 가정하고, 다음 홉 필드에 자신의 주소를 대입해요. 이를 흔히 next hop self라고 불러요.

Calico 이더넷 패브릭 모델에서는 모든 컴퓨트 서버(Calico 네트워크의 라우터)가 하나 이상의 이더넷 네트워크로 직접 연결되어 있으므로 직접 도달 가능해요. 이 경우 Calico 네트워크의 라우터는 Calico 패브릭 안에서 next hop self를 설정할 필요가 없어요.

이 글에서 제시한 모델들은 비(非)Calico 라우터를 통과할 수 있는 모든 라우트가 eBGP 라우트가 되도록 보장해요. 따라서 next hop self가 자동으로 올바르게 설정돼요. IP 상호 연결 패브릭에서의 Calico 배포가 그 제약을 만족하지 않는다면 next hop self를 알맞게 구성해야 해요.

라우트 리플렉션

앞서 말했듯이 BGP는 네트워크의 모든 iBGP 라우터가 서로를 직접 보고(말 걸 수 있고) 기대해요. 이를 *BGP 풀 메시(BGP full mesh)*라고 불러요. 작은 네트워크에서는 문제가 없지만 라우터 수가 늘면 흥미로운(?) 상황이 돼요. 예를 들어 어떤 AS에 BGP 라우터가 99개 있고 하나를 더 추가하고 싶다면, 기존 99개 라우터 각각에 그 새 라우터로의 피어링을 구성해야 해요. 구성 시점의 문제일 뿐만 아니라, 각 라우터가 100개의 프로토콜 인접성을 유지해야 한다는 뜻이고, 이는 라우터의 한정된 자원을 갉아 먹기 시작해요. 100개 라우터에서는 그럭저럭 견딜 만해도, 수천~수만 개 라우터(Calico 네트워크의 잠재적 규모)에서는 불가능한 과업이 돼요.

다행히 대규모/인터넷 규모 네트워크는 거의 20년 전에 RFC 1966에 기술된 BGP 라우트 리플렉션을 배포해서 이 문제를 해결했어요. 오늘날 거의 모든 BGP 라우터가 지원하는 기법이에요. 대규모 네트워크에서는 여러 라우트 리플렉터(주석 9)가 고르게 분산되고, 각 iBGP 라우터는 하나 이상(보통 23개)의 라우트 리플렉터와 피어링해요. 각 라우트 리플렉터는 사용 중인 제품에 따라 수십수백 개의 라우트 리플렉터 클라이언트(Calico의 경우 컴퓨트 서버)를 처리할 수 있어요. 그 라우트 리플렉터들은 다시 서로 피어링해요. 즉 완전 메시를 이루어야 하는 라우트 리플렉터 수가 한 자릿수 줄어들고, 각 라우트 리플렉터 클라이언트는 2~3개의 라우트 리플렉터와 피어링하도록만 구성하면 돼요. 훨씬 관리가 쉬워져요.

다른 라우트 리플렉터 아키텍처도 가능하지만, 이 문서의 범위 밖이에요.

엔드포인트

마지막 고려 사항은 Calico 네트워크의 엔드포인트 수예요. 이더넷 패브릭의 경우 상호 연결 패브릭은 실제 엔드포인트를 보지 않고 실제 vRouter, 즉 컴퓨트 서버만 보기 때문에 엔드포인트 수가 패브릭의 제약을 받지 않아요. 하지만 IP 패브릭에서는 사정이 달라요. IP 네트워크는 패킷의 목적지 IP 주소로 포워딩하는데, Calico의 경우 그것이 목적지 엔드포인트예요. 즉 IP 패브릭 노드(예: ToR 스위치와/또는 스파인 스위치)는 네트워크의 각 엔드포인트로의 라우트를 알아야 해요. 이는 Calico vRouter/컴퓨트 서버처럼 BGP 메시에서 라우트 리플렉터 클라이언트로 참여해서 학습해요.

하지만 상대적으로 메모리 제약이 느슨한 컴퓨트 서버와 달리, 물리 스위치는 메모리가 제한적이거나 꽤 비싸요. 즉 물리 스위치는 처리할 수 있는 라우트 수의 한계가 있어요. 현대 컴모디티 스위치의 현재 업계 표준은 128,000 라우트 정도예요. 이는 집계 같은 다른 라우팅 트릭 없이는 IP 패브릭을 쓰는 Calico 설치가 구성 네트워크 하드웨어의 라우팅 테이블 크기로 제한된다는 뜻이고, 오늘날 합리적인 상한은 128,000 엔드포인트예요.

주석

주석 1

Calico 용어에서 엔드포인트는 IP 주소와 인터페이스의 조합이에요. VM, 컨테이너, 혹은 베어 메탈 서버에서 IP 주소에 바인딩되어 실행 중인 프로세스를 가리킬 수도 있어요.

주석 2

이 상호 연결 패브릭은 Calico (v)Router(거의 모든 경우 컴퓨트 서버) 노드들 사이의 연결성과, 패브릭의 다른 요소들(예: 베어 메탈 서버, 보더 라우터, 어플라이언스)의 연결성을 제공해요.

주석 3

이 접근에 대한 논의에 관심이 있다면 알려 주세요. Calico 팀이 논의를 준비하거나, 관심이 충분하다면 후속 기술 노트를 발행할 수도 있어요.

주석 4

다만 특정 Calico 인스턴스가 그런 정책 구조체를 활용할 필요가 생기면 그 도구들을 쓸 수는 있어요.

주석 5

2바이트 AS 공간은 마지막 약 5천 개의 AS 번호를 사설 용도로 예약해요. 다른 AS 번호를 쓸 수 없는 기술적 이유는 없어요. 하지만 사설 인프라 안에서 전역 스코프의 AS 번호를 재사용하는 것은 강하게 권고되지 않아요. 라우팅 시스템 장애나 잘못된 라우팅의 가능성이 상당하고, 그 피해는 재사용을 하는 주체에 국한되지 않아요.

주석 6

이 설계를 처음 본 것은 고객사의 실험실이었고, 공유할 가치가 충분히 혁신적이라고 생각했어요(물론 먼저 허락을 구했고요). 비슷한 AS Path Stripping 접근은 ISP 네트워크에서도 쓰이고 있어요.

주석 7

내부 게이트웨이 프로토콜(IGP)은 AS 경계를 넘지 않는 로컬 라우팅 프로토콜이에요. 오늘날 쓰이는 주요 IGP는 OSPF와 IS-IS예요. 복잡한 iBGP 네트워크는 여전히 IGP 라우팅 프로토콜을 쓰지만, 데이터 센터는 라우터가 많더라도 보통 꽤 단순한 네트워크예요. 따라서 데이터 센터의 경우 IGP 사용을 생략할 수 있는 경우가 잦아요.

주석 8

다음 홉(next hop)은 라우팅 프로토콜이 광고하는 라우트의 속성이에요. 간단히 말해 라우트는 도달하려는 목적지인 *타깃(target)*과, 그 타깃에 도달하기 위한 경로상의 다음 라우터인 *다음 홉(next hop)*으로 정의돼요. 라우트에는 다른 특성들도 많지만, 그것들은 이 글의 범위를 훌쩍 넘어요.

주석 9

라우트 리플렉터는 물리 라우터, 소프트웨어 어플라이언스, 아니면 단순한 BGP 데몬일 수도 있어요. 라우팅 메시지만 처리하고 실제 데이터 플레인 트래픽은 전달하지 않아요. 다만 일부 라우트 리플렉터는 데이터 플레인 트래픽을 전달하는 일반 라우터에 공존하기도 해요. 한 플랫폼에 함께 있더라도 기능은 서로 구별돼요.

더 알아보기 (Learn more)

IP 패브릭에서 Calico를 운영할 때는 AS 퍼들링과 next hop self 두 가지 BGP 성질이 핵심 설계 제약이에요. ToR 라우팅 테이블 크기가 부담되면 다운워드 디폴트 모델을 검토하고, L3 패브릭이 부담스럽다면 이더넷 패브릭 문서로 방향을 바꿔 보세요.