피드 구독

Squid와 Cisco WCCP(Web Cache Communication protocol)를 기반으로 투명 프록시를 생성하는 프로젝트를 진행하던 2003년에 저는 오버레이 터널을 처음 경험했습니다. 이는 Cisco 라우터와 Squid 프록시 간 구성의 일부는 통신에 GRE(일반 라우팅 캡슐화) 터널을 사용하는 데 필요했습니다. 그 당시에는 터널 프로토콜의 필요성을 완전히 이해하지 못했지만 지금은 대규모 멀티 테넌트 클라우드의 VLAN이 손상되었기 때문에 터널 프로토콜의 중요성을 알게 되었습니다.

VLAN은 네트워크 트래픽을 더 작고 덜 복잡한 네트워크로 세분화하기 위해 개발되었습니다. 단점은 고정된 12비트 필드만 있다는 것입니다. 즉, 네트워크 토폴로지에는 약 4,000개의 VLAN만 있을 수 있습니다. 1990년대 후반과 2000년대 초반에는 네트워킹을 수용하기에 충분한 세그먼트였습니다. 그러나 클라우드 시대와 멀티 테넌트 환경이 도래하면서 더 많은 개별 네트워크 터널이 필요하게 되었습니다.

이 문제를 해결하기 위해 다양한 벤더에서 VXLAN(Virtual Extensible LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation), STT(Stateless Transport Tunneling) 등 다양한 솔루션을 제안했습니다. 세 가지 모두 애플리케이션 데이터를 더 큰 새로운 고정 헤더 필드에 캡슐화합니다. 해당 헤더 크기는 VXLAN 및 NVGRE의 경우 24비트이며, 후자는 주로 Microsoft에서 사용하는 반면 STT의 헤더 크기는 64비트입니다. 이러한 캡슐화 터널링 방법 중 어느 것도 하드웨어 네트워킹 인프라를 변경할 필요가 없지만, 일부 벤더는 솔루션의 효율성을 가속화하는 데 도움이 되는 하드웨어를 제공합니다. 그러나 어떤 솔루션도 서로 호환되지 않습니다.

그러나 현재의 대규모 멀티 테넌트 클라우드에서 모든 것이 손실되는 것은 아닙니다. 새로운 네트워크 가상화 표준이 등장했습니다. GENEVE(Generic Network Virtualization Encapsulation)는 이전 사양의 제한 사항을 해결하고 VXLAN, NVGRE, STT의 모든 기능을 지원합니다. 많은 사람이 GENEVE가 결국 이러한 이전의 형식을 완전히 대체할 수 있다고 믿습니다.

GENEVE의 명시된 목표는 캡슐화 데이터 형식만 정의하는 것입니다. 이전의 형식과 달리 컨트롤 플레인에 대한 정보나 사양이 포함되어 있지 않습니다. 작성자의 말을인용하겠습니다:

"데이터 형식을 정하면 분명한 장점이 있습니다. 대부분의 프로토콜은 표면적으로만 다를 뿐, 중복 작업의 이점이 거의 없습니다. 그러나 컨트롤 플레인은 매우 기본적인 면에서 다양합니다. 요구 사항, 목표, 배포 시나리오가 매우 다양하기 때문에 표준화 사례도 명확하지 않습니다."

이러한 목표를 달성하기 위해 GENEVE의 작성자들은 데이터 형식이 최대한 유연하고 확장 가능해야 한다는 데 동의했습니다. 현재 VXLAN과 NVGRE의 24비트 터널 식별자 필드와 STT의 64비트는 필요한 모든 가상 네트워크를 지정하는 데 충분하지만 향후 개발자는 이 필드를 세분화하여 가상 네트워크 식별자 이외의 정보를 전달하고자 할 것으로 예상됩니다. 이 필드의 잠재적 용도를 가상화된 서버 내에서 또는 섀시 스위치의 라인 카드 간에 현재 교환되는 시스템 상태 정보와 비교합니다. 향후 가능한 모든 용도에 충분한 고정된 필드 크기를 지정할 수 없음을 확인합니다. 또한 GENEVE의 작성자들은 수명이 긴 것으로 입증된 다른 많은 프로토콜에서 힌트를 얻었습니다. BGP(Border Gateway Protocol), LLDP(Link Layer Discovery Protocol), IS-IS(Intermediate System - Intermediate System) 등의 프로토콜은 수십 년 동안 사용되어 왔으며 여전히 그 어느 때보다 인기가 높습니다.

그 이유는 간단합니다. 확장 가능하기 때문입니다. 시간이 지남에 따라 기본 프로토콜을 수정하는 것이 아니라 새로운 선택적 기능을 추가하여 새로운 기능으로 진화합니다.

GENEVE 캡슐화 패킷은 표준 네트워킹 장비를 통해 전송되도록 설계되었습니다. 패킷은 유니캐스트나 멀티캐스트 주소 지정을 사용하여 하나의 터널 엔드포인트에서 하나 이상의 터널 엔드포인트로 전송됩니다. 클라이언트 애플리케이션과 애플리케이션이 실행 중인 호스트는 어떤 식으로든 수정되지 않습니다. 애플리케이션은 하드웨어 스위치와 라우터를 통해 통신하는 것처럼 동일한 IP 패킷을 생성합니다. 패킷에 포함된 대상 IP 주소는 클라우드 테넌트의 가상 네트워크 내에서만 중요합니다. 그런 다음 터널 엔드포인트는 GENEVE 헤더에 최종 사용자 IP 패킷을 캡슐화하여 테넌트의 가상 네트워크를 지정하는 터널 식별자와 옵션을 차례로 추가합니다. 헤더는 GENEVE 패킷임을 지정하는 필드, 옵션이 있는 경우 옵션의 전체 길이, 터널 식별자, 그리고 일련의 옵션으로 구성됩니다. 그런 다음 완료된 패킷은 IPv4와 IPv6을 통해 지원되는 표준 UDP 패킷으로 대상 엔드포인트에 전송됩니다. 수신 터널 엔드포인트는 헤더를 제거하고 포함된 옵션을 해석하며 최종 사용자 패킷을 터널 식별자로 표시된 가상 네트워크 내의 목적지로 보냅니다.

Geneve_VxLAN Headers.jpg

 

GENEVE 사양은 파편화를 방지하고 ECMP(Equal-cost multi-path)와 NIC 하드웨어 오프로드 기능을 활용하여 효율적인 운영을 달성하는 방법에 대한 권장 사항을 제공합니다. 이 사양에서는 차별화된 서비스와 명시적 정체 알림을 지원하는 방법에 대한 옵션도 제공합니다. 작성자는 GENEVE와 하나 이상의 다른 캡슐화 방법이 동일한 시스템에서 사용 중일 때 문제가 발생하지 않을 것으로 예상합니다. GENEVE 터널 엔드포인트는 서로 통신만 하며 패킷은 다른 UDP 패킷과 동일하게 네트워크 인프라에서 처리됩니다. 데이터 형식은 VXLAN, NVGRE, STT의 모든 기능을 지원하므로 결국 이전 세 가지 형식의 사용이 줄어들 수 있습니다. 컨트롤 플레인 프로토콜이 지정되지 않았으므로 작성자는 이 프로토콜이 다른 캡슐화 방법과 함께 사용 중인 모든 프로토콜을 지원할 것으로 예상합니다. 다른 캡슐화 방법에 비해 주요 이점 중 하나는 GENEVE의 유연한 옵션 형식과 옵션 클래스 지정을 위해 IANA(Internet Assigned Numbers Authority)를 사용하는 것입니다. 개발자는 24비트로 제한되거나 해당 크기의 일부만 필요한 경우 64비트 필드의 오버헤드를 발생시키지 않고 동적으로 최대 또는 최소 옵션을 포함할 수 있습니다.

GENEVE로의 전환은 즉시 이루어지지는 않습니다. 다른 캡슐화 방법은 한동안 사용되어 왔으며 동일한 시스템 내에서 여러 가지 방법을 사용할 수 있습니다. 그러나 GENEVE는 향후 OpenStack 릴리스에서 OVS(OpenvSwitch)의 구현으로 승격될 OVN(Open Virtual Network)의 기본 터널링 프로토콜로 채택되고 있습니다.

대규모 멀티 테넌트 클라우드를 통한 경험이 계속 증가하고 있으며 단일 캡슐화 방법이 표준이 될 수는 없습니다. 그러나 유연한 옵션 형식과 다른 방법의 모든 기능을 지원하는 GENEVE는 널리 채택될 수 있는 강력한 후보가 될 것입니다.


Want to learn more about edge computing?

Edge computing is in use today across many industries, including telecommunications, manufacturing, transportation, and utilities. Visit our resources to see how Red Hat's bringing connectivity out to the edge.


Benjamin Schmaus는 NA 중부 지역의 Red Hat 클라우드 TAM입니다. 그는 1998년부터 Linux에 관여해 왔으며 유통, 국방, 소프트웨어, 금융, 고등 교육, 중등 교육 등 다양한 산업 분야의 비즈니스 환경을 지원해 왔습니다. 가장 최근에는 고객이 Red Hat OpenStack Platform과 Red Hat Ceph Storage를 배포, 운영, 지원하도록 하는 데 주력해 왔습니다.

Red Hat 기술 계정 관리자(TAM)는 IT 조직과 협력하여 성공적인 배포를 전략적으로 계획하고 최적의 성능과 성장을 실현하도록 지원하는 전문 제품 전문가입니다. TAM은 세계적 수준의 Red Hat Customer Experience and Engagement 소속으로 문제가 발생하기 전에 식별하고 해결할 수 있도록 사전 예방적 조언과 지침을 제공합니다. 문제가 발생하는 경우, 담당 TAM이 문제를 맡아 고객의 업무 중단을 최소화하면서도 최대한 신속하게 문제를 해결할 수 있도록 최고의 리소스를 활용합니다.


저자 소개

Benjamin Schmaus is a Red Hat Principle Product Manager for Edge Solutions. He has been involved with Linux since 1998 and has supported business environments in a variety of industries: retail, defense, software development, pharmacy, financial, higher education and K-12. His experience in those industries along with various positions within Red Hat have enabled him to have a broad and deep understanding of customer challenges. Most recently, he has been focused on enabling our customers at the edge by driving the Red Hat portfolio to deliver edge solutions that meet their ever diverse needs as they journey through modernization.

Read full bio

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리