В 이전 호 나는 네트워크 자동화 프레임워크를 설명했습니다. 일부 사람들에 따르면, 문제에 대한 이러한 첫 번째 접근 방식만으로도 이미 몇 가지 질문이 해결되었다고 합니다. 그리고 이는 나를 매우 기쁘게 합니다. 왜냐하면 이 주기의 우리 목표는 Python 스크립트로 Ansible을 덮는 것이 아니라 시스템을 구축하는 것이기 때문입니다.

동일한 프레임워크가 우리가 질문을 처리할 순서를 설정합니다.
그리고 이번 호에서 다루는 네트워크 가상화는 자동화를 분석하는 ADSM 주제에 특별히 적합하지 않습니다.

하지만 다른 각도에서 살펴보겠습니다.

많은 서비스가 오랫동안 동일한 네트워크를 사용해 왔습니다. 통신 사업자의 경우에는 2G, 3G, LTE, 광대역, B2B 등이 있습니다. DC의 경우: 다양한 클라이언트, 인터넷, 블록 스토리지, 객체 스토리지에 대한 연결.

그리고 모든 서비스는 서로 격리되어야 합니다. 이것이 오버레이 네트워크가 나타난 방식입니다.

그리고 모든 서비스는 사람이 수동으로 구성할 때까지 기다리기를 원하지 않습니다. 이것이 오케스트레이터와 SDN이 등장한 방식입니다.

네트워크 또는 그 일부의 체계적인 자동화에 대한 첫 번째 접근 방식은 VMWare, OpenStack, Google Compute Cloud, AWS, Facebook 등 여러 곳에서 오랫동안 채택되어 구현되었습니다.

이것이 바로 오늘 우리가 다룰 내용입니다.

내용

• 이유
• 전문 용어
• 언더레이 - 물리적 네트워크
• 오버레이 - 가상 네트워크
  • ToR과 오버레이
  • 호스트의 오버레이
  • 텅스텐 원단을 예로 사용
    • 단일 물리적 시스템 내 통신
    • 서로 다른 물리적 시스템에 있는 VM 간의 통신
    • 바깥세계로 나가기

• 자주하는 질문
• 결론
• 유용한 링크

이유

이에 대해 이야기하고 있으므로 네트워크 가상화의 전제 조건을 언급할 가치가 있습니다. 사실 이 과정은 어제 시작된 것이 아닙니다.

네트워크가 항상 모든 시스템에서 가장 활동적이지 않은 부분이었다는 말을 한 번 이상 들어보셨을 것입니다. 그리고 이것은 모든 면에서 사실입니다. 네트워크는 모든 것이 존재하는 기초이며 네트워크를 변경하는 것은 매우 어렵습니다. 네트워크가 다운되면 서비스는 이를 허용하지 않습니다. 단일 노드를 폐기하면 애플리케이션의 상당 부분이 중단되고 많은 고객에게 영향을 미칠 수 있는 경우가 많습니다. 이것이 부분적으로 네트워크 팀이 어떤 변화에도 저항하는 이유 중 하나입니다. 이제 어떻게든 작동하기 때문입니다(우리는 방법조차 모를 수도 있습니다), 그러나 여기서는 새로운 것을 구성해야 하며 이것이 네트워크에 어떤 영향을 미칠지는 알 수 없습니다.

네트워크 담당자가 VLAN을 삽입하고 각 네트워크 노드에 서비스를 등록하지 않을 때까지 기다리지 않기 위해 사람들은 오버레이(오버레이 네트워크)를 사용하는 아이디어를 생각해 냈습니다. 오버레이 네트워크에는 GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE 등

그들의 매력은 두 가지 간단한 점에 있습니다.

• 끝 노드만 구성됩니다. 전송 노드는 건드릴 필요가 없습니다. 이를 통해 프로세스 속도가 크게 향상되고 때로는 새로운 서비스 도입 프로세스에서 네트워크 인프라 부서를 완전히 제외할 수 있습니다.
• 로드는 헤더 내부 깊숙이 숨겨져 있습니다. 전송 노드는 이에 대해, 호스트 주소 지정 또는 오버레이 네트워크의 경로에 대해 아무것도 알 필요가 없습니다. 이는 테이블에 더 적은 정보를 저장해야 함을 의미하며, 이는 더 간단하고 저렴한 장치를 사용한다는 의미입니다.

완전히 본격적인 문제가 아닌 이 문제에서는 가능한 모든 기술을 분석할 계획이 아니라 DC에서 오버레이 네트워크 작동을 위한 프레임워크를 설명할 계획입니다.

전체 시리즈에서는 동일한 서버 장비가 설치된 동일한 랙의 행으로 구성된 데이터 센터를 설명합니다.

이 장비는 서비스를 구현하는 가상 머신/컨테이너/서버리스를 실행합니다.

전문 용어

주기적으로 섬기는 사람 클라이언트-서버 통신의 서버측을 구현하는 프로그램의 이름을 지정하겠습니다.

랙에 있는 물리적 시스템을 서버라고 합니다. 아니 우리는 그럴 것이다.

물리적 기계 — 랙에 설치된 x86 컴퓨터. 가장 자주 사용되는 용어 주인. 그걸 우리는 "라고 부르겠습니다.자동차"또는 주인.

하이퍼바이저 - 가상 머신이 실행되는 물리적 리소스를 에뮬레이션하는 물리적 머신에서 실행되는 애플리케이션입니다. 때로는 문헌과 인터넷에서 "하이퍼바이저"라는 단어가 "호스트"의 동의어로 사용됩니다.

가상 기기 - 하이퍼바이저 상단의 물리적 머신에서 실행되는 운영 체제입니다. 이 주기에서는 실제로 가상 머신인지 아니면 단순한 컨테이너인지는 중요하지 않습니다. "라고 부르자VM«

거주자 이 기사에서 별도의 서비스 또는 별도의 클라이언트로 정의할 광범위한 개념입니다.

다중 테넌시 또는 다중 테넌트 - 서로 다른 클라이언트/서비스에서 동일한 애플리케이션을 사용하는 것입니다. 동시에 별도로 실행되는 인스턴스를 통하지 않고 애플리케이션 아키텍처 덕분에 클라이언트를 서로 격리할 수 있습니다.

ToR - 랙 상단 스위치 - 모든 물리적 기계가 연결된 랙에 설치된 스위치입니다.

ToR 토폴로지 외에도 다양한 공급자가 EoR(End of Row) 또는 Middle of Row를 실행합니다(후자가 매우 드물고 MoR 약어를 본 적이 없지만).

언더레이 네트워크 또는 기본 네트워크 또는 언더레이는 스위치, 라우터, 케이블과 같은 물리적 네트워크 인프라입니다.

오버레이 네트워크 또는 오버레이 네트워크 또는 오버레이 - 물리적 터널 위에서 실행되는 터널의 가상 네트워크입니다.

L3 패브릭 또는 IP 패브릭 - 인터뷰를 위해 STP를 반복하고 TRILL을 배우는 것을 피할 수 있게 해주는 인류의 놀라운 발명품입니다. 액세스 수준까지의 전체 네트워크가 VLAN이 없고 이에 따라 대규모로 확장된 브로드캐스트 도메인이 없는 L3 전용 개념입니다. 다음 부분에서는 “공장”이라는 단어가 어디서 유래했는지 살펴보겠습니다.

SDN - 소프트웨어 정의 네트워크. 소개가 거의 필요하지 않습니다. 사람이 아닌 프로그램을 통해 네트워크를 변경하는 네트워크 관리 접근 방식입니다. 일반적으로 제어 평면을 최종 네트워크 장치를 넘어 컨트롤러로 이동하는 것을 의미합니다.

NFV — 네트워크 기능 가상화 — 네트워크 장치의 가상화. 일부 네트워크 기능을 가상 머신이나 컨테이너 형태로 실행하여 새로운 서비스 구현 속도를 높이고 서비스 체인을 구성하며 수평 확장성을 단순화할 수 있음을 시사합니다.

VNF - 가상 네트워크 기능. 특정 가상 장치: 라우터, 스위치, 방화벽, NAT, IPS/IDS 등

이제 독자가 너무 혼동하지 않도록 의도적으로 특정 구현에 대한 설명을 단순화하고 있습니다. 더 사려 깊은 읽기를 위해 나는 그에게 섹션을 참조하도록 합니다. 참조. 또한, 이 기사가 부정확하다고 비판하는 Roma Gorge는 서버 및 네트워크 가상화 기술에 대해 별도의 호를 더 심층적이고 세부적인 내용에 주의하여 작성할 것을 약속합니다.

오늘날 대부분의 네트워크는 두 부분으로 명확하게 나눌 수 있습니다.

밑받침 — 안정적인 구성을 갖춘 물리적 네트워크.
오버레이 — 테넌트 격리를 위한 Underlay 추상화.

이는 DC(이 기사에서 분석할 것임)와 ISP(이미 분석되었기 때문에 분석하지 않을 것) 모두에 해당됩니다. SDSM). 물론 엔터프라이즈 네트워크에서는 상황이 다소 다릅니다.

네트워크에 초점을 맞춘 그림:

밑받침

언더레이는 물리적 네트워크(하드웨어 스위치 및 케이블)입니다. 지하에 있는 장치는 실제 기계에 접근하는 방법을 알고 있습니다.

이는 표준 프로토콜과 기술에 의존합니다. 특히 오늘날까지의 하드웨어 장치는 칩 프로그래밍이나 자체 프로토콜 구현을 허용하지 않는 독점 소프트웨어에서 작동하기 때문에 다른 공급업체와의 호환성 및 표준화가 필요합니다.

그러나 Google과 같은 회사는 자체 스위치를 개발하고 일반적으로 허용되는 프로토콜을 포기할 여유가 있습니다. 하지만 LAN_DC는 Google이 아닙니다.

언더레이는 물리적 시스템 간의 기본 IP 연결을 담당하기 때문에 상대적으로 거의 변경되지 않습니다. Underlay는 그 위에서 실행되는 서비스, 클라이언트 또는 테넌트에 대해 전혀 알지 못합니다. Underlay는 한 시스템에서 다른 시스템으로 패키지를 전달하기만 하면 됩니다.
언더레이는 다음과 같을 수 있습니다.

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+트릴
• L2+STP

Underlay 네트워크는 CLI/GUI/NETCONF라는 전통적인 방식으로 구성됩니다.

수동으로, 스크립트, 독점 유틸리티.

시리즈의 다음 기사에서는 언더레이에 대해 더 자세히 다루겠습니다.

오버레이

오버레이는 언더레이 위에 확장된 터널의 가상 네트워크로, 이를 통해 한 클라이언트의 VM이 서로 통신하는 동시에 다른 클라이언트와의 격리를 제공할 수 있습니다.

클라이언트 데이터는 공용 네트워크를 통한 전송을 위해 일부 터널링 헤더에 캡슐화됩니다.

따라서 하나의 클라이언트(하나의 서비스)의 VM은 패킷이 실제로 어떤 경로를 사용하는지 알지 못하더라도 오버레이를 통해 서로 통신할 수 있습니다.

예를 들어 오버레이는 위에서 언급한 것과 같을 수 있습니다.

• GRE 터널
• VXLAN
• EVPN
• L3VPN
• 제네바

오버레이 네트워크는 일반적으로 중앙 컨트롤러를 통해 구성 및 유지 관리됩니다. 여기에서 구성, 제어 평면 및 데이터 평면이 클라이언트 트래픽을 라우팅하고 캡슐화하는 장치로 전달됩니다. 조금 이하 예를 들어 살펴보겠습니다.

예, 이것은 가장 순수한 형태의 SDN입니다.

오버레이 네트워크를 구성하는 데는 근본적으로 다른 두 가지 접근 방식이 있습니다.

1. ToR과 오버레이
2. 호스트의 오버레이

ToR과 오버레이

예를 들어 VXLAN 패브릭의 경우처럼 오버레이는 랙에 있는 액세스 스위치(ToR)에서 시작할 수 있습니다.

이는 ISP 네트워크에서 오랜 시간 테스트를 거친 메커니즘이며 모든 네트워크 장비 공급업체에서 이를 지원합니다.

하지만 이 경우 ToR 스위치는 각각 다양한 서비스를 분리할 수 있어야 하며, 네트워크 관리자는 어느 정도 가상 머신 관리자와 협력하여 장치 구성을 (자동이기는 하지만) 변경해야 합니다. .

여기서 나는 독자에게 다음과 같은 기사를 소개하겠습니다. Habré의 VxLAN 우리의 오랜 친구 @bormoglotx.
이 ENOG와 함께한 프레젠테이션 EVPN VXLAN 패브릭을 사용하여 DC 네트워크를 구축하는 접근 방식이 자세히 설명되어 있습니다.

현실에 더욱 완벽하게 몰입하려면 Tsiska의 책을 읽어보세요. 현대적이고 개방적이며 확장 가능한 패브릭: VXLAN EVPN.

VXLAN은 캡슐화 방법일 뿐이며 터널 종료는 ToR이 아닌 호스트에서 발생할 수 있습니다(예: OpenStack의 경우).

그러나 오버레이가 ToR에서 시작되는 VXLAN 패브릭은 확립된 오버레이 네트워크 설계 중 하나입니다.

호스트의 오버레이

또 다른 접근 방식은 최종 호스트에서 터널을 시작하고 종료하는 것입니다.
이 경우 네트워크(언더레이)는 최대한 단순하고 정적으로 유지됩니다.
그리고 호스트 자체는 필요한 모든 캡슐화를 수행합니다.

물론 이를 위해서는 호스트에서 특별한 애플리케이션을 실행해야 하지만 그만한 가치가 있습니다.

첫째, Linux 시스템에서 클라이언트를 실행하는 것이 더 쉽거나 심지어 가능하다고 가정해 봅시다. 스위치에서는 독점 SDN 솔루션으로 전환해야 할 가능성이 높으며 이는 다중 공급업체에 대한 아이디어를 없애줍니다.

둘째, 이 경우 ToR 스위치는 컨트롤 플레인과 데이터 플레인의 관점에서 최대한 단순하게 남겨둘 수 있습니다. 실제로 SDN 컨트롤러와 통신할 필요가 없으며 연결된 모든 클라이언트의 네트워크/ARP를 저장할 필요도 없습니다. 물리적 시스템의 IP 주소를 아는 것만으로도 충분하므로 스위칭/전환이 크게 단순화됩니다. 라우팅 테이블.

ADSM 시리즈에서는 호스트에서 오버레이 접근 방식을 선택합니다. 그런 다음 이에 대해서만 이야기하고 VXLAN 공장으로 돌아가지 않습니다.

예제를 보는 것이 가장 쉽습니다. 그리고 테스트 주제로 현재 알려진 OpenSource SDN 플랫폼인 OpenContrail을 선택하겠습니다. 텅스텐 직물.

기사 마지막 부분에서는 OpenFlow와 OpenvSwitch의 비유에 대해 몇 가지 생각을 해볼 것입니다.

텅스텐 원단을 예로 사용

각 물리적 머신에는 vRouter - 연결된 네트워크와 해당 네트워크가 속한 클라이언트에 대해 알고 있는 가상 라우터 - 본질적으로 PE 라우터입니다. 각 클라이언트에 대해 격리된 라우팅 테이블(VRF 읽기)을 유지합니다. 그리고 vRouter는 실제로 오버레이 터널링을 수행합니다.

vRouter에 대한 자세한 내용은 기사 마지막 부분에 있습니다.

하이퍼바이저에 있는 각 VM은 다음을 통해 이 머신의 vRouter에 연결됩니다. 탭 인터페이스.

가볍게 두드리다 - 터미널 액세스 포인트 - 네트워크 상호 작용을 허용하는 Linux 커널의 가상 인터페이스입니다.

vRouter 뒤에 여러 네트워크가 있는 경우 각 네트워크에 대해 가상 인터페이스가 생성되고 여기에 IP 주소가 할당됩니다. 이는 기본 게이트웨이 주소가 됩니다.
한 클라이언트의 모든 네트워크는 하나의 네트워크에 배치됩니다. VRF (하나의 테이블), 다른 테이블-다른 테이블로.
여기에서 모든 것이 그렇게 단순하지는 않다는 면책 조항을 작성하고 호기심 많은 독자를 기사 끝까지 보내겠습니다..

vRouter는 서로 통신할 수 있고 그에 따라 뒤에 있는 VM도 다음을 통해 라우팅 정보를 교환합니다. SDN 컨트롤러.

외부 세계로 나가기 위해 매트릭스의 출구 지점인 가상 네트워크 게이트웨이가 있습니다. VNGW — 가상 네트워크 GateWay(내 용어).

이제 통신의 예를 살펴보겠습니다. 그러면 명확성이 있을 것입니다.

단일 물리적 시스템 내 통신

VM0은 VM2로 패킷을 보내려고 합니다. 지금은 이것이 단일 클라이언트 VM이라고 가정해 보겠습니다.

데이터 플레인

1. VM-0에는 eth0 인터페이스에 대한 기본 경로가 있습니다. 패키지가 그곳으로 전송됩니다.
   이 인터페이스 eth0은 실제로 TAP 인터페이스 tap0을 통해 가상 라우터 vRouter에 가상으로 연결됩니다.
2. vRouter는 패킷이 어느 인터페이스로 왔는지, 즉 어느 클라이언트(VRF)에 속해 있는지 분석하고, 이 클라이언트의 라우팅 테이블로 수신자의 주소를 확인합니다.
3. 동일한 시스템의 수신자가 다른 포트에 있음을 감지하면 vRouter는 추가 헤더 없이 패킷을 해당 시스템으로 보냅니다. 이 경우 vRouter에는 이미 ARP 레코드가 있습니다.

이 경우 패킷은 물리적 네트워크에 들어 가지 않고 vRouter 내부에서 라우팅됩니다.

컨트롤 플레인

가상 머신이 시작되면 하이퍼바이저는 다음과 같이 알려줍니다.

• 그녀 자신의 IP 주소.
• 기본 경로는 이 네트워크의 vRouter IP 주소를 통하는 것입니다.

하이퍼바이저는 특수 API를 통해 vRouter에 보고합니다.

• 가상 인터페이스를 생성하는 데 필요한 것.
• VM(가상 네트워크)을 생성하려면 어떤 종류의 가상 네트워크가 필요합니까?
• 바인딩할 VRF(VN)입니다.
• 이 VM에 대한 정적 ARP 항목(IP 주소 뒤에 있는 인터페이스 및 연결된 MAC 주소)

이번에도 개념 이해를 위해 실제 상호작용 절차를 단순화했습니다.

따라서 vRouter는 특정 머신에 있는 한 클라이언트의 모든 VM을 직접 연결된 네트워크로 보고 VM 간을 직접 라우팅할 수 있습니다.

그러나 VM0과 VM1은 서로 다른 클라이언트에 속하므로 서로 다른 vRouter 테이블에 있습니다.

서로 직접 통신할 수 있는지 여부는 vRouter 설정 및 네트워크 설계에 따라 다릅니다.
예를 들어 두 클라이언트의 VM이 공용 주소를 사용하거나 vRouter 자체에서 NAT가 발생하는 경우 vRouter로 직접 라우팅이 수행될 수 있습니다.

반대 상황에서는 주소 공간을 교차하는 것이 가능합니다. 공용 주소를 얻으려면 NAT 서버를 거쳐야 합니다. 이는 아래에서 설명하는 외부 네트워크에 액세스하는 것과 유사합니다.

서로 다른 물리적 시스템에 있는 VM 간의 통신

데이터 플레인

1. 시작은 정확히 동일합니다. VM-0은 기본값으로 대상 VM-7(172.17.3.2)을 사용하여 패킷을 보냅니다.
2. vRouter는 이를 수신하고 이번에는 대상이 다른 시스템에 있고 Tunnel0을 통해 액세스할 수 있음을 확인합니다.
3. 먼저 원격 인터페이스를 식별하는 MPLS 레이블을 걸어 놓으면 vRouter가 추가 조회 없이 이 패킷을 배치할 위치를 결정할 수 있습니다.

   

4. Tunnel0에는 소스가 10.0.0.2이고 대상은 10.0.1.2입니다.
   vRouter는 원본 패킷에 GRE(또는 UDP) 헤더와 새 IP를 추가합니다.
5. vRouter 라우팅 테이블에는 ToR1 주소 10.0.0.1을 통한 기본 경로가 있습니다. 그가 그것을 보내는 곳이 바로 그곳이다.

   
   

6. Underlay 네트워크의 구성원인 ToR1은 (예를 들어 OSPF를 통해) 10.0.1.2에 도달하는 방법을 알고 있으며 경로를 따라 패킷을 보냅니다. 여기에서는 ECMP가 활성화되어 있습니다. 그림에는 두 개의 다음 홉이 있으며 서로 다른 스레드가 해시별로 정렬됩니다. 실제 공장의 경우 넥스트홉이 4개일 가능성이 더 높다.

   동시에 그는 외부 IP 헤더 아래에 무엇이 있는지 알 필요가 없습니다. 즉, 실제로 IP에서는 IPv6, MPLS, 이더넷, MPLS, GRE, 그리스어의 샌드위치가 있을 수 있습니다.

7. 따라서 수신 측에서 vRouter는 GRE를 제거하고 MPLS 태그를 사용하여 이 패킷을 어떤 인터페이스로 보내야 하는지 이해하고 이를 제거한 후 원래 형식으로 수신자에게 보냅니다.

컨트롤 플레인

자동차의 시동을 걸면 위에서 설명한 것과 동일한 일이 발생합니다.

그리고 다음 사항도 추가됩니다.

• 각 클라이언트에 대해 vRouter는 MPLS 태그를 할당합니다. 이는 동일한 물리적 시스템 내에서 클라이언트를 분리하는 L3VPN 서비스 레이블입니다.
  

  실제로 MPLS 태그는 항상 vRouter에 의해 무조건 할당됩니다. 결국 머신이 동일한 vRouter 뒤에 있는 다른 머신과만 상호 작용한다는 사실은 미리 알려지지 않았으며 이는 사실이 아닐 가능성이 높습니다.

• vRouter는 BGP 프로토콜(또는 이와 유사 - TF의 경우 XMPP 0_o)을 사용하여 SDN 컨트롤러와의 연결을 설정합니다.
• 이 세션을 통해 vRouter는 연결된 네트워크에 대한 경로를 SDN 컨트롤러에 보고합니다.
  • 네트워크 주소
  • 캡슐화 방법(MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS 클라이언트 태그
  • 귀하의 IP 주소를 다음 홉으로 사용하세요

• SDN 컨트롤러는 연결된 모든 vRouter로부터 이러한 경로를 수신하여 다른 vRouter에 반영합니다. 즉, 경로 리플렉터 역할을 합니다.

반대 방향에서도 같은 일이 일어납니다.

오버레이는 최소한 XNUMX분마다 변경될 수 있습니다. 이는 클라이언트가 정기적으로 가상 머신을 시작하고 종료하는 퍼블릭 클라우드에서 일어나는 일입니다.

중앙 컨트롤러는 구성을 유지하고 vRouter의 스위칭/라우팅 테이블을 모니터링하는 모든 복잡성을 처리합니다.

대략적으로 말하면 컨트롤러는 BGP(또는 유사한 프로토콜)를 통해 모든 vRouter와 통신하고 단순히 라우팅 정보를 전송합니다. 예를 들어 BGP에는 캡슐화 방법을 전달하기 위한 Address-Family가 이미 있습니다. MPLS-in-GRE 또는 MPLS-in-UDP.

동시에 Underlay 네트워크의 구성은 어떤 식으로든 변경되지 않습니다. 그런데 이는 자동화하기가 훨씬 더 어렵고 어색한 움직임으로 인해 중단되기가 더 쉽습니다.

바깥세계로 나가기

어디선가 시뮬레이션이 끝나야 하고, 가상 세계를 벗어나 현실 세계로 들어가야 합니다. 그리고 공중전화 게이트웨이가 필요합니다.

두 가지 접근 방식이 실행됩니다.

1. 하드웨어 라우터가 설치되어 있습니다.
2. 라우터 기능을 구현하는 일부 어플라이언스가 출시되었습니다(예, SDN에 이어 VNF도 만났습니다). 이를 가상 게이트웨이라고 부르겠습니다.

두 번째 접근 방식의 장점은 저렴한 수평 확장성입니다. 전력이 충분하지 않습니다. 게이트웨이가 있는 또 다른 가상 머신을 시작했습니다. 모든 물리적 시스템에서 사용 가능한 랙, 장치, 전원 출력을 찾을 필요 없이 하드웨어 자체를 구입하고, 운반하고, 설치하고, 전환하고, 구성한 다음 결함이 있는 구성 요소를 변경할 수도 있습니다.

가상 게이트웨이의 단점은 물리적 라우터 단위가 여전히 멀티 코어 가상 머신보다 훨씬 더 강력하고 자체 하드웨어 기반에 맞춰진 소프트웨어가 훨씬 더 안정적으로 작동한다는 것입니다(아니). 또한 하드웨어와 소프트웨어 복합체는 구성만 필요하고 간단하게 작동하는 반면, 가상 게이트웨이를 시작하고 유지하는 것은 유능한 엔지니어의 작업이라는 사실도 부정하기 어렵습니다.

한 발로 게이트웨이는 일반 가상 머신처럼 오버레이 가상 네트워크를 살펴보고 다른 모든 VM과 상호 작용할 수 있습니다. 동시에 모든 클라이언트의 네트워크를 종료하고 그에 따라 클라이언트 간의 라우팅을 수행할 수 있습니다.

게이트웨이는 다른 쪽 발로 백본 네트워크를 조사하여 인터넷에 접속하는 방법을 알고 있습니다.

데이터 플레인

즉, 프로세스는 다음과 같습니다.

1. 기본적으로 동일한 vRouter를 사용하는 VM-0은 외부 대상(185.147.83.177)이 있는 패킷을 eth0 인터페이스로 보냅니다.
2. vRouter는 이 패킷을 수신하고 라우팅 테이블에서 대상 주소를 조회합니다. - 터널 1을 통해 VNGW1 게이트웨이를 통해 기본 경로를 찾습니다.
   그는 또한 이것이 SIP 10.0.0.2 및 DIP 10.0.255.2를 사용하는 GRE 터널임을 확인하고 먼저 VNGW1이 예상하는 이 클라이언트의 MPLS 레이블을 연결해야 합니다.
3. vRouter는 초기 패킷을 MPLS, GRE 및 새 IP 헤더로 압축하여 기본적으로 ToR1 주소 10.0.0.1로 보냅니다.
4. 기본 네트워크는 패킷을 게이트웨이 VNGW1로 전달합니다.
5. VNGW1 게이트웨이는 GRE 및 MPLS 터널링 헤더를 제거하고, 대상 주소를 확인하고, 라우팅 테이블을 참조하고, 전체 보기 또는 기본을 통해 인터넷으로 연결된다는 것을 이해합니다. 필요한 경우 NAT 변환을 수행합니다.
6. VNGW에서 국경까지 일반 IP 네트워크가 있을 수 있지만 그럴 가능성은 없습니다.
   전통적인 MPLS 네트워크(IGP+LDP/RSVP TE)가 있을 수 있고, BGP LU가 있는 백 패브릭이나 IP 네트워크를 통해 VNGW에서 경계까지의 GRE 터널이 있을 수 있습니다.
   VNGW1은 필요한 캡슐화를 수행하고 초기 패킷을 경계로 보냅니다.

반대 방향의 트래픽은 반대 순서로 동일한 단계를 거칩니다.

1. 국경은 패킷을 VNGW1로 삭제합니다.
2. 그는 그의 옷을 벗고 수신자의 주소를 확인한 후 Tunnel1 터널(MPLSoGRE 또는 MPLSoUDP)을 통해 접근할 수 있음을 확인합니다.
3. 이에 따라 MPLS 레이블, GRE/UDP 헤더 및 새 IP를 첨부하여 ToR3 10.0.255.1로 보냅니다.
   터널 대상 주소는 대상 VM이 위치한 vRouter의 IP 주소(10.0.0.2)입니다.
4. 기본 네트워크는 패킷을 원하는 vRouter로 전달합니다.
5. 대상 vRouter는 GRE/UDP를 읽고 MPLS 레이블을 사용하여 인터페이스를 식별한 다음 VM의 eth0과 연결된 TAP 인터페이스에 베어 IP 패킷을 보냅니다.

컨트롤 플레인

VNGW1은 SDN 컨트롤러를 사용하여 BGP 환경을 설정합니다. 이로부터 클라이언트에 대한 모든 라우팅 정보(어떤 IP 주소(vRouter)가 어떤 클라이언트 뒤에 있는지, 어떤 MPLS 레이블로 식별되는지)를 수신합니다.

마찬가지로 그 자신도 이 클라이언트의 레이블이 포함된 기본 경로를 SDN 컨트롤러에 알리고 자신을 다음 홉으로 나타냅니다. 그러면 이 기본값이 vRouters에 도착합니다.

VNGW에서는 일반적으로 경로 집계 또는 NAT 변환이 발생합니다.

그리고 다른 방향에서는 정확히 이 집계된 경로를 경계 또는 경로 리플렉터가 있는 세션으로 보냅니다. 그리고 그로부터 기본 경로나 전체 보기 등을 수신합니다.

캡슐화 및 트래픽 교환 측면에서 VNGW는 vRouter와 다르지 않습니다.
범위를 약간 확장하면 방화벽, 트래픽 정리 또는 강화 팜, IPS 등과 같은 다른 네트워크 장치를 VNGW 및 vRouter에 추가할 수 있습니다.

그리고 VRF의 순차적 생성과 올바른 경로 공지를 통해 트래픽이 원하는 방식으로 루프되도록 강제할 수 있습니다. 이를 서비스 체이닝이라고 합니다.

즉, 여기서도 SDN 컨트롤러는 VNGW, vRouter 및 기타 네트워크 장치 간의 경로 반사기 역할을 합니다.

그러나 실제로 컨트롤러는 ACL 및 PBR(정책 기반 라우팅)에 대한 정보도 유출하여 개별 트래픽 흐름이 경로가 지시하는 것과 다르게 진행되도록 합니다.

자주하는 질문

왜 항상 GRE/UDP 발언을 하시나요?

글쎄, 일반적으로 이것은 텅스텐 직물에만 국한된 것이라고 할 수 있습니다. 전혀 고려할 필요가 없습니다.

그러나 우리가 받아들이면 TF 자체는 여전히 OpenContrail이지만 GRE의 MPLS와 UDP의 MPLS라는 두 가지 캡슐화를 모두 지원했습니다.

UDP는 소스 포트에서 원래 IP+프로토+포트의 해시 함수를 헤더에 인코딩하는 것이 매우 쉽기 때문에 좋습니다. 이를 통해 균형을 조정할 수 있습니다.

아쉽게도 GRE의 경우 캡슐화된 모든 트래픽에 대해 동일한 외부 IP 및 GRE 헤더만 있으며 균형 조정에 대한 이야기는 없습니다. 패킷 내부를 그렇게 깊이 볼 수 있는 사람은 거의 없습니다.

얼마 전까지만 해도 라우터는 동적 터널을 사용하는 방법을 MPLSoGRE에서만 사용했으며 아주 최근에야 MPLSoUDP 사용 방법을 배웠습니다. 따라서 우리는 항상 두 가지 다른 캡슐화 가능성에 대해 기록해야 합니다.

공평하게 말하면 TF가 VXLAN을 사용하여 L2 연결을 완벽하게 지원한다는 점은 주목할 가치가 있습니다.

OpenFlow와 유사점을 도출하겠다고 약속하셨습니다.
그들은 정말로 그것을 요구하고 있습니다. 동일한 OpenStack의 vSwitch는 UDP 헤더도 있는 VXLAN을 사용하여 매우 유사한 작업을 수행합니다.

데이터 플레인에서는 거의 동일하게 작동하지만 제어 플레인에서는 상당히 다릅니다. Tungsten Fabric은 XMPP를 사용하여 vRouter에 라우팅 정보를 전달하고 OpenStack은 Openflow를 실행합니다.

vRouter에 대해 좀 더 알려주실 수 있나요?
이는 vRouter Agent와 vRouter Forwarder의 두 부분으로 나뉩니다.

첫 번째는 호스트 OS의 사용자 공간에서 실행되고 SDN 컨트롤러와 통신하여 경로, VRF 및 ACL에 대한 정보를 교환합니다.

두 번째는 데이터 플레인을 구현합니다. 일반적으로 커널 공간에 있지만 SmartNIC에서도 실행할 수 있습니다. CPU와 별도의 프로그래밍 가능 스위칭 칩이 있는 네트워크 카드를 사용하면 호스트 시스템의 CPU에서 로드를 제거하고 네트워크를 더 빠르고 더 빠르게 만들 수 있습니다. 예측 가능.

또 다른 가능한 시나리오는 vRouter가 사용자 공간의 DPDK 애플리케이션이라는 것입니다.

vRouter Agent는 vRouter Forwarder에 설정을 보냅니다.

가상 네트워크란 무엇입니까?
VRF에 대한 기사 시작 부분에서 각 임차인이 자신의 VRF에 연결되어 있다고 언급했습니다. 그리고 이것이 오버레이 네트워크의 작동을 피상적으로 이해하는 데 충분했다면 다음 반복에서는 설명이 필요합니다.

일반적으로 가상화 메커니즘에서 가상 네트워크 엔터티(고유 명사로 간주할 수 있음)는 클라이언트/테넌트/가상 머신과 별도로 도입되며 완전히 독립적입니다. 그리고 이 가상 네트워크는 이미 인터페이스를 통해 하나의 테넌트, 다른 테넌트, 두 개 또는 어느 곳에나 연결될 수 있습니다. 예를 들어 서비스 체이닝은 트래픽이 필요한 순서에 따라 특정 노드를 통과해야 할 때 간단히 가상 네트워크를 올바른 순서로 생성하고 연결함으로써 구현됩니다.

따라서 가상 네트워크와 테넌트 간에는 직접적인 통신이 없습니다.

결론

이는 호스트 및 SDN 컨트롤러의 오버레이를 사용하는 가상 네트워크의 작동에 대한 매우 피상적인 설명입니다. 그러나 현재 어떤 가상화 플랫폼을 선택하든 VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric 또는 Juniper Contrail 등 유사한 방식으로 작동합니다. 캡슐화 및 헤더 유형, 최종 네트워크 장치에 정보를 전달하기 위한 프로토콜은 다르지만 비교적 단순하고 정적인 언더레이 네트워크 위에서 작동하는 소프트웨어 구성 가능 오버레이 네트워크의 원리는 동일하게 유지됩니다.
오늘날 오버레이 네트워크 기반 SDN이 프라이빗 클라우드 구축 분야에서 승리했다고 말할 수 있습니다. 그러나 이것이 현대 세계에서 Openflow가 설 자리가 없다는 것을 의미하지는 않습니다. OpenStacke과 동일한 VMWare NSX에서 사용되며, 제가 아는 한 Google은 이를 사용하여 지하 네트워크를 설정합니다.

문제를 더 깊이 연구하고 싶다면 아래에 더 자세한 자료에 대한 링크를 제공했습니다.

그리고 우리 언더레이는 어떻습니까?

그러나 일반적으로 아무것도 없습니다. 그는 완전히 변하지 않았습니다. 호스트에서 오버레이가 발생하는 경우 그가 해야 할 일은 vRouter/VNGW가 나타나고 사라지며 이들 사이에 패킷을 전달할 때 경로와 ARP를 업데이트하는 것뿐입니다.

Underlay 네트워크에 대한 요구 사항 목록을 작성해 보겠습니다.

1. 우리 상황에서는 일종의 라우팅 프로토콜인 BGP를 사용할 수 있습니다.
2. 과부하로 인해 패킷이 손실되지 않도록 초과 가입 없이 넓은 대역폭을 확보하는 것이 좋습니다.
3. ECMP 지원은 패브릭의 필수적인 부분입니다.
4. ECN과 같은 까다로운 기능을 포함하여 QoS를 제공할 수 있습니다.
5. NETCONF 지원은 미래를 위한 기반입니다.

나는 여기서 Underlay 네트워크 자체의 작업에 거의 시간을 할애하지 않았습니다. 이는 시리즈 후반부에서 이에 초점을 맞추고 오버레이에 대해서만 다룰 것이기 때문입니다.

분명히, 나는 순수 IP 라우팅과 호스트의 오버레이를 사용하여 Cloz 공장에 구축된 DC 네트워크를 예로 사용하여 우리 모두를 심각하게 제한하고 있습니다.

하지만 디자인이 있는 모든 네트워크는 공식적인 용어로 설명되고 자동화될 수 있다고 확신합니다. 여기서 나의 목표는 자동화에 대한 접근 방식을 이해하고 일반적인 형태로 문제를 해결하여 모든 사람을 혼란스럽게 하지 않는 것입니다.

ADSM의 일환으로 Roman Gorge와 저는 컴퓨팅 성능의 가상화와 네트워크 가상화와의 상호 작용에 관한 별도의 호를 발행할 계획입니다. 연락을 유지하다.

유용한 링크

• 텅스텐 직물 건축.
• 정보:클라우드. TF의 가상 네트워크도 다루는 Yandex.Cloud에 대해 6시간 동안 설명합니다.
• 오픈 vSwitch란 무엇입니까?
• VxLAN 소개.
• RFC 7348. VXLAN(Virtual eXtensible Local Area Network): 레이어 2 네트워크에 가상화된 레이어 3 네트워크를 오버레이하기 위한 프레임워크입니다.
  
• VXLAN EVPN 패브릭에 대한 확장형 접근 방식. Underlay, Overlay, 멀티 호밍 및 관리 접근 방식을 포함한 전체 DC 네트워크에 대해 설명합니다.

감사합니다

• 로만 고르가 - 이전 linkmeup 팟캐스트 진행자였으며 현재는 클라우드 플랫폼 분야의 전문가입니다. 의견 및 편집용. 우리는 가까운 시일 내에 가상화에 대한 그의 보다 심층적인 기사를 기다리고 있습니다.
• 알렉산더 샬리모프 - 가상 네트워크 개발 분야의 동료이자 전문가입니다. 의견 및 편집용.
• 발렌틴 시니친 - 텅스텐 직물 분야의 동료이자 전문가입니다. 의견 및 편집용.
• 아르템 체르노바이 — 일러스트레이터 linkmeup. KDPV의 경우.
• 알렉산더 리모노프. "오토마토" 밈의 경우.

출처 : habr.com