이더넷 패브릭 위의 Calico

IP 패킷을 운반할 수 있는 어떤 기술이든 Calico 네트워크의 인터커넥트 패브릭으로 쓸 수 있다는 점을 다룬 레퍼런스예요. L2 이더넷 인터커넥트 패브릭에서 BGP 피어링과 브로드캐스트 도메인을 고려하는 방법을 정리했어요. 대규모 이더넷 네트워크의 알려진 문제점들과 Calico가 그 문제를 어떻게 해소하는지가 핵심이에요.

출처: 문서

본문

IP 패킷을 운반할 수 있는 어떤 기술이든 Calico 네트워크의 인터커넥트 패브릭으로 쓸 수 있어요. 즉, IP를 운반하는 표준 도구인 MPLS와 이더넷도 Calico 네트워크에서 쓸 수 있다는 뜻이에요.

이 글의 초점은 인터커넥트 네트워크로서의 이더넷이에요. 대부분의 대규모 클라우드 운영자는 IP 패브릭으로 전환했고, 그 인프라는 Calico에서도 동작해요. 하지만 그 운영자들이 파드의 인터커넥트 네트워크로 IP를 선택하게 만든 우려 대부분은 Calico가 상당 부분 해소해주기 때문에, 대규모 배포에서조차 이더넷을 Calico 인터커넥트로 진지하게 고려할 수 있어요.

규모가 커질 때 이더넷의 우려 (Concerns over Ethernet at scale)

일정 규모를 넘으면 전통적인 이더넷 네트워크는 프로덕션 배포에 부적합하다는 것은 업계에서 오래전부터 인정받아 온 사실이에요. 이 문제를 해결하려는 여러 시도가 있었음에도, 스케일아웃 네트워킹 커뮤니티는 네트워크 패브릭에서 물리적 포인트 투 포인트 링크를 제공하는 용도를 제외하면 이더넷을 사실상 버렸어요. 대규모에서 이더넷이 실패하는 주요 이유는 다음과 같아요.

• 수많은 엔드포인트 (주석 1)

  이더넷 네트워크의 각 스위치는 이더넷 네트워크에 연결된 모든 이더넷 엔드포인트로 가는 경로를 학습해야 해요. 수십만 개의 엔드포인트를 다룬다면 이 상태 학습은 상당한 작업이 될 수 있어요.

• 네트워크의 높은 변동률(churn) 또는 변화

  엔드포인트가 그만큼 많고 대부분 일시적(가상 머신이나 컨테이너 같은)이라면 네트워크에는 많은 변동이 생겨요. 경로를 다시 학습하는 이 부하는 대부분의 이더넷 스위치 컨트롤 플레인 프로세서에 상당한 짐이 될 수 있어요.

• 대량의 브로드캐스트 트래픽

  이더넷 네트워크의 각 노드가 피어를 찾으려고 브로드캐스트 패킷을 써야 하고, 많은 노드가 다른 목적으로도 브로드캐스트를 쓰기 때문에, 모든 엔드포인트로 복제되는 패킷이 대규모 이더넷 네트워크에서 브로드캐스트 스톰을 일으킬 수 있어요. 그 결과 네트워크와 연결된 엔드포인트의 자원을 대부분, 혹은 전부 소모하게 돼요.

• 스패닝 트리

  스패닝 트리는 이더넷 네트워크가 루프를 형성하지 않도록 유지하는 프로토콜이에요. 더 작고 단순했던 네트워크 시대에 설계된 프로토콜이라 세월을 잘 견디지 못했어요. 이더넷 네트워크의 링크와 인터커넥트 수가 늘어날수록 스패닝 트리 구현 상당수는 더 취약해져요. 안타깝게도 이더넷 네트워크에서 스패닝 트리가 실패하면 그 결과는 치명적인 루프나 네트워크 파티션(또는 둘 다)이고, 대부분의 경우 문제를 추적하거나 해결하기도 어려워요.

이 문제들이 VM 규모(수시간, 수일, 수주 생존하는 수만 개 엔드포인트)에서도 이미 치명적이지만, 컨테이너 규모(수초, 수분, 수일 생존하는 수십만 개 엔드포인트)에서는 절대적으로 치명적이에요.

이전부터 이더넷 데이터센터 네트워크를 끌 생각이 아니었다 해도, 이제는 그럴 마음이 들 거예요. 하지만 그 전에, Calico가 아주 큰 배포에서도 이 문제들을 어떻게 완화하는지 살펴봐요.

Calico는 어떻게 이더넷의 악령을 길들이나? (How does Calico tame the Ethernet daemons?)

먼저 Calico가 이더넷 인터커넥트 패브릭을 어떻게 사용하는지 살펴봐요. 이더넷 네트워크는 연결된 IP 라우터의 반대편에서는 아무것도 보지 못하고 라우터 자체만 본다는 점을 기억하는 게 중요해요. 그래서 인터넷 피어링 지점에서도 이더넷 스위치를 쓸 수 있는 거예요. 스위치는 여러 ISP의 라우터만 보지, 그 ISP 고객들의 노드는 보지 못하거든요. Calico는 같은 효과를 활용해요.

앞서 말한 문제들을 Calico 맥락에서 다시 살펴봐요.

• 수많은 엔드포인트

  Calico 네트워크에서 이더넷 인터커넥트 패브릭은 라우터/컴퓨트 서버만 보지, 엔드포인트는 보지 못해요. 서버당 VM 수십 개(또는 컨테이너 수백 개)인 표준 클라우드 모델에서는, 이더넷이 보고(학습해야 하는) 노드 수가 한두 자릿수나 줄어들어요. 아주 큰 파드(예: 2만 대 서버)라 해도 이더넷 네트워크가 보는 엔드포인트는 여전히 수만 개 정도예요. 어떤 성능 좋은 데이터센터 이더넷 톱오브랙(ToR) 스위치의 처리 범위 안이에요.

• 높은 변동률

  전통적인 이더넷 데이터센터 패브릭에서는 엔드포인트가 생성, 삭제, 이동될 때마다 변동(churn) 이벤트가 발생해요. 엔드포인트가 수십만 개인 대형 데이터센터에서는 이 변동이 하루 종일 초당 수십 건에 이르고, 피크에는 초당 수백, 수천 건에 달할 수 있어요. 하지만 Calico 네트워크에서 변동은 아주 낮아요. (평소 경험하는 것보다 몇 자릿수 큰 변동을 만들 수 있는 유일한 이벤트가 있더라도) 하루 2,000건 정도밖에 없어요. 그 정도의 변화량도 감당하지 못하는 스위치라면 어떤 애플리케이션에도 쓰면 안 되는 스위치예요.

• 대량의 브로드캐스트 트래픽

  Calico 네트워크의 어떤 트래픽이든 첫 홉(그리고 마지막 홉)은 IP 홉이고, IP 홉은 브로드캐스트 트래픽을 종료시키기 때문에, 이더넷 패브릭에는 엔드포인트 브로드캐스트 네트워크가 존재하지 않아요. 실제로 이더넷 패브릭에서 보여야 하는 브로드캐스트 트래픽은 컴퓨트 서버들이 서로를 찾는 ARP뿐이에요. 트래픽 패턴이 어느 정도 일정하다면 정상 상태의 ARP 비율은 거의 0에 가까워요. 병리적인 경우에도 ARP 비율은 통상 허용 범위 안에 머물러요.

• 스패닝 트리

  이더넷 패브릭에 선택한 아키텍처에 따라 스패닝 트리를 아예 끌 수도 있어요. 켜둔 경우에도 노드 수 감소와 변동 감소 덕분에, 역량 있는 대부분의 스패닝 트리 구현은 부하 없이 감당할 수 있어요.

이런 점들을 종합하면, Calico의 이더넷 연결 패브릭이 가능할 뿐 아니라 실용적이고, Calico 네트워크의 인터커넥트 패브릭으로 진지하게 고려할 가치가 있다는 것이 분명해져요.

IP 패브릭 글에서 언급했듯이 Calico에 IP 패브릭도 충분히 가능하지만, 고려해야 할 사항이 더 많아요. 이더넷 패브릭 옵션은 설계에 필요한 아키텍처적 고려가 더 적어요.

이더넷 토폴로지에 대한 간단한 노트

Calico 문서의 다른 부분에서 언급했듯이, Calico는 대부분의 표준 IP 도구를 쓸 수 있기 때문에 패브릭 토폴로지와 관련해 흥미로운 선택지들이 생겨요.

Calico를 위한 이더넷 패브릭은 리프/스파인(leaf/spine) 아키텍처로 구성하는 경우가 가장 많을 거라고 가정해요. 다른 선택지도 가능하지만, 오늘날 스케일아웃 인프라에서 지배적인 아키텍처 모델은 리프/스파인이에요.

Calico는 IP 라우티드 패브릭이기 때문에, MLAG 같은 이더넷 기법 대신 ECMP를 써서 여러 링크에 트래픽을 분산할 수 있어요. Calico 컴퓨트 서버에서 ECMP 로드밸런싱을 활용하면, Calico 노드의 IP 라우팅과 인터커넥트 패브릭의 기본 이더넷 스위칭만으로 여러 독립적인 리프/스파인 플레인으로 패브릭을 구축할 수 있어요. 이 플레인들은 완전히 독립적으로 동작하고, 장애 도메인을 공유하지 않도록 설계할 수도 있어요. 덕분에 이더넷 인터커넥트 패브릭의 한 플레인(또는 그 이상)이 치명적으로 실패해도 파드를 잃지 않아요(장애는 단지 파드의 인터커넥트 대역폭을 줄일 뿐이에요). 오늘날 설계에서 가능한 파드 전역 IP 또는 이더넷 장애보다 훨씬 온건한 장애 모드예요.

이 Facebook 블로그 글에서 다루는 패브릭 방식도 흥미로울 거예요. 개념을 시각화한 그림은 아래에 있어요.

이 다이어그램에는 엔드포인트가 표시되어 있지 않고, 앞서 말했듯 엔드포인트는 패브릭 내부의 어떤 것도 알 수 없어요.

이 다이어그램에서 각 ToR은 네 개의 논리 스위치로 분할되어 있고(예: '포트 VLAN' 활용), (주석 2) 각 컴퓨트 서버는 그 논리 스위치 각각에 연결돼요. 우리는 그 논리 스위치를 색으로 구분할 거예요. 각 ToR에는 파랑, 초록, 주황, 빨강 논리 스위치가 있는 셈이에요. 그 '색'들은 특정 플레인의 구성원이라서, 파랑 플레인, 초록 플레인, 주황 플레인, 빨강 플레인이 생겨요. 각 플레인에는 전용 스파인 스위치가 있고, 주어진 스파인에 속한 각 ToR은 자신의 스파인에만, 그리고 오직 자신의 스파인에만 연결돼요.

각 플레인은 하나의 IP 네트워크를 이루기 때문에, 파랑 플레인은 2001:db8:1000::/36, 초록은 2001:db8:2000::/36, 주황과 빨강은 각각 2001:db8:3000::/36과 2001:db8:4000::/36이에요. (주석 3)

각 IP 네트워크(플레인)는 자체 BGP 라우트 리플렉터가 필요해요. 그 라우트 리플렉터들은 플레인 안에서 서로 피어링하면 되고, 서로 다른 플레인의 라우트 리플렉터끼리는 피어링할 필요가 없어요. 따라서 4플레인 패브릭은 라우트 리플렉터 메시 4개를 갖게 돼요. 각 컴퓨트 서버, 보더 라우터 등은 각 플레인의 라우트 리플렉터 최소 하나(가급적 둘 이상)의 클라이언트가 되어야 해요.

다음 다이어그램은 라우트 리플렉터 환경을 시각화해요.

이 라우트 리플렉터는 스파인 스위치에 연결된 전용 하드웨어(또는 스파인 스위치 그 자체)일 수도 있고, 필요한 논리 리프 스위치(파랑, 초록, 주황, 빨강)에 연결된 물리/가상 라우트 리플렉터일 수도 있어요. 컴퓨트 서버에서 실행되면서 올바른 플레인 링크에 직접 연결되고 vRouter를 거치지 않는 라우트 리플렉터일 수도 있는데, 이는 라우트 리플렉터가 Calico 네트워크 "뒤쪽"에 있을 때 생기는 닭-달걀 문제를 피하려는 거예요.

물론 다른 물리/논리 구성과 수량도 가능하고, 이것은 그저 하나의 예시일 뿐이에요.

논리 구성상 각 컴퓨트 서버는 각 플레인의 서브넷에 주소를 하나씩 갖고, 각 서브넷에 자신의 엔드포인트를 광고해요. ECMP를 켜면 컴퓨트 서버가 모든 플레인에 부하를 분산해요.

한 플레인이 실패하면(예: 스패닝 트리 장애) 그 플레인만 실패해요. 나머지 플레인은 계속 동작해요.

각주

주석 1

이 문서(그리고 모든 Calico 문서)에서는 엔드포인트라는 용어를 가상 머신, 컨테이너, 어플라이언스, 베어메탈 서버, 또는 Calico 네트워크에 연결된 다른 모든 개체를 가리키는 데 쓰는 경향이 있어요. 특정 유형의 엔드포인트를 가리킬 때는 그렇게 따로 말할 거예요(예: 컨테이너와 구별되는 VM의 동작을 말하는 식이에요).

주석 2

이 예제에서는 논리 스위치를 사용해요. 물리 ToR을 쓰거나 둘을 섞을 수도 있어요(예: 각 물리 스위치에 논리 스위치 2개를 올리기).

주석 3

여기서는 IPv6를 순전히 예시로 썼어요. IPv4도 비슷하게 구성할 수 있어요.

더 알아보기 (Learn more)

핵심은 Calico 네트워크에서 이더넷 패브릭이 "보는" 대상이 라우터뿐이라는 점이에요. 이 한 가지가 엔드포인트 학습, 변동률, 브로드캐스트 스톰, 스패닝 트리 문제를 모두 완화해줘요. IP 패브릭 설계도 고민 중이라면 L3 인터커넥트 패브릭 문서를 함께 참고해보세요.