Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

JDM 아키텍처 개요

해체된 Junos OS

많은 네트워크 장비 벤더들은 전통적으로 소프트웨어를 목적에 따라 하드웨어에 바운드해 고객들에게 번들 및 패키지 소프트웨어와 하드웨어 조합을 판매했습니다. 그러나 해체된 Junos OS 통해 Juniper 네트워크 디바이스는 클라우드 지향, 개방형, 보다 유연한 구현 시나리오에 따라 조정됩니다.

해체된 Junos OS 아키텍처의 기본 원칙은 Junos OS 소프트웨어 및 전용하드웨어를 가상화된 구성 요소로 분해(디스어그리게이엄)합니다. 이 구성 요소는 주니퍼 네트웍스 하드웨어뿐만 아니라 화이트 박스 또는 베어메탈 서버에서도 실행할 수 있습니다. 이 새로운 아키텍처에서 JDM(Juniper Device Manager)은 소프트웨어 구성 요소를 관리하는 가상화된 루트 컨테이너입니다.

JDM은 세분화 Junos OS 아키텍처에서 유일한 루트 컨테이너입니다(두 개 이상의 루트 컨테이너를 허용하는 다른 업계 모델이 있지만 세분화된 Junos OS 아키텍처는 해당되지 않습니다). 세분화 Junos OS 모델은 단일 루트 모델입니다. JDM의 주요 기능 중 하나는 플랫폼의 수정 및 활동이 기반 호스트 OS(일반적으로 Linux)에 영향을 미치는 것을 방지하는 것입니다. 루트 엔티티인 JDM은 이 작업에 매우 적합하다. JDM의 또 다른 주요 기능은 장비 하드웨어가 가능한 기존 Junos OS 물리적 시스템과 마찬가지로 보이게 하는 것입니다. 이를 위해서는 일원적인 루트 기능도 필요합니다.

그림 1은 JDM이 전체 아키텍처에서 차지하는 중요한 위치를 설명하고 있습니다.

그림 1: Juniper 장비 관리자의 위치 Position of the Juniper Device Manager

VNF는 완전히 가상화된 네트워킹 환경을 지원하는 데 필요한 모든 구성 요소를 포함하는 통합 오퍼링입니다. VNF는 네트워크 최적화를 중점적으로 다고 있습니다.

JDM은

  • 수명 주기 동안 게스트 VNF(Virtualized Network Function)의 관리

  • 타사 모듈 설치.

  • VNF 서비스 체인 형성.

  • 게스트 VNF 이미지 관리(바이너리 파일).

  • 시스템 인벤토리 및 리소스 사용량 제어

기본 아키텍처의 일부 구현에는 기본 패킷 전달 엔진 Linux 플랫폼 하드웨어 포트가 포함되어 있습니다. 이를 통해 일반 플랫폼의 베어메탈 하드웨어와 주니퍼 네트웍스 데이터 플레인을 보다 잘 통합할 수 있습니다.

해체된 Junos OS 아키텍처를 통해 JDM은 방화벽 또는 네트워크 주소 변환(네트워크 주소 변환(NAT)) 기능을 처리할 수 있습니다. JDM과 통합된 다른 VNF 및 컨테이너는 타사 주니퍼 네트웍스 네이티브 Linux 애플리케이션으로 타사 제품을 사용할 수 있습니다. 세분화되어 있는 Junos OS 아키텍처는 그림 2에서구조적으로 표시됩니다.

그림 2: 기본 세분화 Junos OS 아키텍처 Basic Disaggregated Junos OS Architecture
참고:

다양한 플랫폼에서 기본 세분화 Junos OS 아키텍처를 구현하는 여러 가지 방법이 있습니다. 세부 정보는 크게 다를 수 있습니다. 이 주제는 전반적인 아키텍처에 대해 설명하고 있습니다.

고정 하드웨어에서 실행되는 단순한 소프트웨어 프로세스의 가상화는 프로세스 간 통신 영역에 몇 가지 과제를 안고 있습니다. 예를 들어, vNF가 동일한 디바이스에서 컨테이너로 네트워크 주소 변환(NAT) 방화벽과 어떻게 연동되는가? 결국 전체 디바이스에 1개 또는 2개의 외부 Ethernet 포트가 있을 수 있으며 프로세스는 여전히 장치 내부에 있습니다. 한 가지 이점은 이러한 가상화된 프로세스 간의 인터페이스가 SXE포트로 가상화되는 경우가 많다는 것입니다. 즉, 프로세스 간에 직접 또는 프로세스와 호스트 OS 간 그리고 호스트 OS와 다른 프로세스 간에 MAC 레이어 브리지의 유형을 구성할 수 있습니다. 그러면 트래픽이 디바이스로 들어오고 나가는 서비스의 체인이 지원됩니다.

JDM은 사용자에게 친숙한 서비스를 Junos OS CLI 기반 Linux 커널과의 모든 상호 작용을 처리하여 사용자 장치의 "보기와 느낌"을 주니퍼 네트웍스 있습니다.

이 세분화의 이점은 Junos OS 있습니다.

  • 전체 시스템을 서버 플랫폼 관리와 같이 관리할 수 있습니다.

  • 고객은 Chef, Wiireshark 또는 Quagga와 같은 타사 애플리케이션, 도구 및 서비스를 VM(가상 머신) 또는 컨테이너에 설치할 수 있습니다.

  • 이러한 애플리케이션 및 툴은 일반적인 Linux 리포지토리를 사용하여 업그레이드될 수 있으며 릴리스와 Junos OS 있습니다.

  • 모듈 내 장애가 포함되어 안정성이 향상됩니다.

  • 컨트롤 플레인과 데이터 플레인은 API를 통해 직접 프로그래밍할 수 있습니다.

물리적 구성 요소 및 가상 구성 요소 이해

해체된 Junos OS NFV(네트워크 기능 가상화) 환경에서 디바이스 구성 요소는 물리적 또는 가상 환경일 수 있습니다. 인터페이스(포트), 패킷 또는 프레임이 디바이스를 통과하는 경로, CPU 코어 또는 디스크 공간과 같은 기타 측면에 동일한 물리적/가상 구분을 적용할 수 있습니다.

세분화 Junos OS 사양에는 아키텍처 모델이 포함되어 있습니다. 집의 아키텍처 모델은 부가가치, 루프, 식사 공간을 포함해 방향을 제시할 수 있으며 다양한 유형의 주민을 대표할 수 있습니다. 해변가의 코티지에서부터 구식 맨션까지. 이 모든 주택은 매우 서로 다른 모양을 보이지만 여전히 기본 아키텍처 모델을 따르며 여러 특성을 공유합니다.

마찬가지로 해체된 Junos OS 아키텍처 모델의 경우, 이 모델은 단순한 CPE(고객 사내 장비)부터 대규모 데이터센터에 설치된 복잡한 스위칭 장비까지 매우 다양한 유형의 플랫폼을 지원하지만, 플랫폼이 공유하는 몇 가지 기본 특성을 가지고 있습니다.

이들 플랫폼이 어떤 특성을 공유할까요? 모든 세분화 Junos OS 플랫폼은 3개 레이어로 구축됩니다. 이러한 레이어와 가능한 몇 가지 콘텐츠는 그림 3에 표시하고 있습니다.

그림 3: 디스어그리게이션된 네트워크의 물리 및 가상 Junos OS Physical and Virtual Layers in the Disaggregated Junos OS

최저 계층은 하드웨어 계층입니다. 메모리(RAM) 및 디스크 공간(SSD) 외에도 플랫폼 하드웨어에는 관리에 사용되는 외부 네트워크 정보 센터(NIC) 코어 CPU가 있습니다. 경우에 따라 컨트롤 및 데이터 플레인에 사용되는 단일 네트워크 정보 센터(NIC) 포트가 있을 수 있지만, 해당 포트는 사용자 트래픽 스트림에 대한 단일 트래픽 패킷 전달 엔진 사용할 수도 있습니다.

플랫폼 소프트웨어 레이어는 하드웨어 레이어 위에 있습니다. 모든 플랫폼 종속 기능은 여기에서 수행됩니다. 이들 기능에는 트래픽을 연결하는 다양한 가상 구성 요소를 위한 소프트웨어 스위칭 기능이 포함되어 있습니다. Linux 또는 커널 기반 가상 머신(KVM)은 플랫폼을 실행하며, 일부 모델에서는 전화 홈 에이전트가 벤더 또는 서비스 제공업체 디바이스에 연락하여 자동 구성 작업을 수행합니다. 전화 홈 에이전트는 특히 소규모 CPE 플랫폼에 선호됩니다.

플랫폼 소프트웨어 레이어 위에는 다양한 플랫폼 독립적인 기능을 아우를 수 있는 고객 소프트웨어 레이어가 있습니다. 일부 구성 요소는 가상 SR vSRX X 디바이스(주니퍼 네트웍스) 또는 Junos 컨트롤 플레인(JCP)과 같은 가상 머신일 JCP. 이 JCP JDM과 연동하여 이 장비는 전용 주니퍼 네트웍스 플랫폼과 되지만, 더 많은 유연성을 제공합니다. 이러한 유연성의 상당수는 가상화된 네트워크 기능(VNF)을 구현하는 하나 이상의 VNF를 지원할 수 있는 능력에서 비추어 볼 수 있습니다. 이러한 VNF는 네트워크 주소 변환(네트워크 주소 변환(NAT)), DNS(Domain Name System) 서버 룩업과 같은 많은 유형의 작업으로 구성됩니다.

일반적으로, 고정된 수의 CPU 코어와 정해진 양의 디스크 공간이 있습니다. 하지만 가상 환경에서는 리소스 할당 및 사용이 더욱 복잡해집니다. 인터페이스, 디스크 공간, 메모리 또는 코어와 같은 가상 리소스는 VNF 이미지에 따라 당시 실행되는 VNF 사이에서 구문을 구비합니다.

VNF는 물리적 디바이스를 공유하는 VM(가상 머신) 또는 컨테이너 여부에 따라 종종 서로 통신해야 합니다. 패킷 또는 프레임은 물리적 인터페이스(포트)를 통해 디바이스로 들어오고 일부 초기 VNF로 배포됩니다. 트래픽 흐름을 일부 처리한 후 VNF는 구성할 경우 트래픽을 다른 VNF로 전달한 다음, 트래픽이 물리적 디바이스에서 나가기 전에 다른 VNF로 전달합니다. 이러한 VNF는 디바이스 내부에 전송되는 데이터 플레인 서비스 체인을 구성합니다.

어떻게 분리된 VM 또는 컨테이너인 VNF가 트래픽을 다른 VM으로 전달하는가? 서비스 체인은 물리적 인터페이스에서 하나 이상의 내부 가상 인터페이스로 트래픽을 전달하도록 구성됩니다. 따라서 각 VM 또는 컨테이너와 연관된 가상 NIC가 있습니다. 모든 는 디바이스 내부의 가상 스위치 또는 브리지 기능에 의해 연결되어 있습니다. 물리적 인터페이스와 가상 인터페이스 간의 통신을 가능하게 하는 이 일반적인 관계는 그림 4에 표시하고 있습니다.

그림 4: 물리적 구성 요소 및 가상 구성 요소 통신 Physical and Virtual Component Communication

서로 다른 플랫폼에서 변형이 있을 수 있는 이 일반 모델에서는 데이터가 물리적 네트워크 정보 센터(NIC)의 포트를 통해 입력되어 대상 MAC 주소에 따라 Virtual 네트워크 정보 센터(NIC) 1을 통해 Virtual Machine1로 연결됩니다. 트래픽은 물리적 포트로 돌아와 디바이스가 나설 때까지 트래픽을 다른 구성된 가상 인터페이스를 통해 가상 머신2 이상의 VNF로 브리지될 수도 있습니다.

구성을 위해 이러한 인터페이스는 ge-0/0/0 또는 fxp0과 같은 익숙한 지정이나 sxe0 또는 hsxe0과 같은 새로운 지정을 사용할 수 있습니다. 일부는 실제일 수 있지만 내부 포트(예: sxe0)를 통해 디바이스를 운영하는 데 필요한 완전 가상 구조(예: hsxe0)가 될 수 있습니다.

VM Junos OS 세분화

클라우드 컴퓨팅은 최종 사용자 서버 기능 및 대규모 데이터센터 또는 여러 데이터센터 간 분산된 엔드포인트를 연결하는 데 필요한 네트워크 기능 모두를 위해 가상화된 환경에서 애플리케이션을 실행할 수 있도록 지원합니다. 애플리케이션 및 네트워크 기능은 VNF(가상화된 네트워크 기능)에 의해 구현될 수 있습니다. 이들 두 가지 패키지 유형 간의 차이점은 무엇일까요? 누군가 다른 패키지를 사용하는 이유는 무엇인가?

VNF와 컨테이너 모두 하나의 물리적 서버를 공유하는 수만 대 또는 수백 개의 VNF로 하드웨어의 멀티플렉스를 허용합니다. 이를 통해 새로운 서비스를 빠르게 구축하는 것은 물론, 과중한 사용 시 워크로드 확장 및 마이그레이션 또는 물리적 유지 보수(마이그레이션 사용 시)도 지원할 수 있습니다.

클라우드 컴퓨팅 환경에서는 일반적으로 VNF를 사용하여 현대 네트워크의 빅 데이터를 특징으로 하는 대규모 서버 팜에서 막대한 작업을 처리해야 합니다. 서버 가상화는 다양한 개발 환경, 하드웨어 플랫폼 또는 운영 체제를 위해 작성된 애플리케이션이 적합한 소프트웨어 스위트를 실행되는 일반 하드웨어에서 실행할 수 있도록 지원합니다.

VNF는 하이퍼바이즈를 사용하여 물리적 환경을 관리하고 특정 시간 동안 실행되는 VNF 사이에 리소스를 할당합니다. 인기 하이퍼바이즈로는 Xen, KVM, VMWare ESXi를 포함하지만, 그 외에는 여러 가지가 있습니다. VNF는 하이퍼바이저의 사용자 공간에서 실행하며 VM 애플리케이션의 운영 체제를 완전하게 구현합니다. 예를 들어, C++ 언어로 작성 및 Microsoft Windows 운영 체제에서 컴피리즈 및 실행된 애플리케이션은 하이퍼바이즈를 사용하여 Linux 운영 체제에서 실행할 수 있습니다. 이 경우 Windows는 게스트 운영 체제입니다.

하이퍼바이즈는 VNF 하드웨어에 대한 에뮬레이터 뷰를 게스트 운영 체제에 제공합니다. 메모리 디스크 공간과 같은 다른 리소스 중에서도 하이퍼바이즈는 서로 다른 VM의 엔드포인트가 서로 다른 서버 또는 호스트에 상주할 때(네트워크 정보 센터(NIC)) 네트워크 인터페이스 카드에 대한 가상화된 뷰를 제공합니다. 하이퍼바이저는 물리적 NI를 관리하고 VNF에 가상화된 인터페이스만 노출합니다.

하이퍼바이더는 또한 VLAN 프레임 레이어의 VNF가 동일한 박스 내부 또는(가상) 네트워크 상에서 패킷을 교환할 수 있는 가상 스위치 환경을 실행합니다.

VNF의 가장 큰 장점은 대부분의 애플리케이션을 하이퍼바이즈 환경에 쉽게 이식할 수 있으며 수정 없이도 잘 실행될 수 있습니다.

가장 큰 단점은 종종 게스트 운영 체제의 리소스가 높은 오버헤드가 전체 VNF의 기능이 DNS(Domain Name System)과 같은 단순한 서비스를 제공하는 경우에도 전체 운영 체제 버전을 포함해야 하다는 것입니다.

VNF와 달리 컨테이너는 가상 환경에서 독립 작업으로 실행될 수 있는 용도로 제작되었습니다. 컨테이너는 VNF와 같은 내부에서 전체 운영 체제를 번들화하지 않습니다. 컨테이너는 다양한 방식으로 코드화하고 번들할 수 있지만 유지 관리 및 확장이 쉬운 표준 컨테이너를 구축하는 방법도 있습니다. 표준 컨테이너는 매우 개방적인(haphazard) 스타일로 생성된 컨테이너보다 훨씬 더 개방적입니다.

표준 Linux 컨테이너는 표준 컨테이너라고 하는 소프트웨어 제공을 정의합니다. 표준 컨테이너는 전체 게스트 운영 체제를 캡슐화하는 대신 애플리케이션이 프로그래밍된 작업을 수행하는 데 필요한 종속성과 애플리케이션만 캡슐화합니다. 이 단일 런타임 요소는 수정할 수 있지만, 확장 기능이 필요할 수 있는 추가 종속성 을 포함하려면 컨테이너를 재구성해야 합니다. 그림 5 에표시된 컨테이너의 전체 아키텍처

그림 5: 컨테이너–전체 아키텍처 Containers–Overall Architecture

컨테이너는 하이퍼바이즈가 아닌 호스트 OS 커널에서 실행됩니다. 컨테이너 아키텍처는 컨테이너 엔진을 사용하여 기반 플랫폼을 관리합니다. VNF를 실행하려는 경우 컨테이너는 완전한 하이퍼바이즈 및 게스트 OS 환경도 패키지로 구성할 수 있습니다.

표준 컨테이너는 다음과 같습니다.

  • 구성 파일입니다.

  • 표준 운영 세트

  • 실행 환경.

컨테이너는 전 세계 상품을 운송하는 데 사용되는 선적 컨테이너에서 빌려 왔다. 운송 컨테이너는 컨테이너를 처리하기 위해 특별히 제작된 장비에 의해 로딩, 라벨링, 스택 설치, 리프트 및 언로드할 수 있는 표준 배송 장치입니다. 내부에 상관없이 컨테이너를 표준으로 처리할 수 있으며 각 컨테이너는 다른 컨테이너에서 사용할 수 없는 자체 사용자 공간을 가지고 있습니다. Docker는 물리적 서버에서 컨테이너를 실행할 수 있는 인기 있는 컨테이너 관리 시스템으로, Drawbridge 또는 Rocket과 같은 대안을 고려해야 합니다.

각 컨테이너에는 가상 인터페이스가 할당됩니다. Docker와 같은 컨테이너 관리 시스템에는 여러 가상 인터페이스와 물리적 인터페이스를 연결하는 가상 네트워크 정보 센터(NIC). 컨테이너의 구성 및 환경 변수는 어떤 컨테이너가 서로 통신할 수 있는지, 외부 네트워크를 사용할 수 있는지를 확인합니다. 컨테이너는 종종 동일한 네트워크 주소 공간을 네트워크 주소 변환(NAT) 다른 방법이 있기 때문에 외부 네트워킹은 일반적으로 네트워크 주소 변환(NAT) 수행됩니다.

컨테이너의 가장 큰 이점은 디바이스에서 로딩하고 VNF보다 더 빠르게 실행할 수다는 것입니다. 컨테이너는 또한 리소스를 더 많이 사용할 수도 있습니다. 또한 동일한 하드웨어에서 VNF보다 더 많은 컨테이너를 실행할 수 있습니다. 컨테이너가 전체 게스트 운영 체제나 부팅 시간을 요구하지 않는 것이기 때문이다. 컨테이너는 수십초가 아닌 밀리초 만에 로드 및 실행할 수 있습니다. 그러나 컨테이너의 가장 큰 단점은 VNF를 기본 상태로 실행할 수 있는 반면, 일부 표준 또는 공통 구현을 준수하기 위해 특별히 작성해야 하는 것입니다.

Virtio 및 SR-IOV 사용

Virtio를 사용하거나 적절한 하드웨어 및 단일 루트 I/O 가상화(SR-IOV)를 사용하여 Linux 기반 가상화 디바이스와 NFV(Network Functions Virtualization) 모듈 간의 통신을 지원할 수 있습니다. 각 메소드마다 고유한 특성이 있습니다.

Virtio 활용도 이해

물리적 디바이스가 가상화되는 경우 물리적 네트워크 정보 센터(NIC) 물리적 스위치와 외부 물리적 스위치는 물론 가상 네트워크 정보 센터(NIC) 내부 가상 스위치가 공존하게 됩니다. 따라서 디바이스의 분리된 VNF는 각각 자체 메모리와 디스크 공간 및 CPU 주기를 가지고 서로 통신을 시도할 때 사용 중 여러 포트, MAC 주소 및 IP 주소를 사용하는 데 어려움이 있습니다. Virtio 라이브러리를 통해 격리된 가상 기능 간의 트래픽 흐름이 보다 간편하고 쉬워집니다.

Virtio는 유용한 가상화 기능에 대한 표준 Linux libvirt 라이브러리의 일부로 일반적으로 대부분의 Linux 버전에 포함되어 있습니다. Virtio는 VNF 간 통신에 대한 소프트웨어 전용 접근 방식입니다. Virtio는 개별 가상 프로세스를 연결하는 방법을 제공합니다. Virtio의 번들 특성 덕분에 모든 Linux 실행 디바이스에서 Virtio를 사용할 수 있습니다.

Virtio는 VNF와 컨테이너가 단순한 내부 브리지를 사용하여 트래픽을 송수신할 수 있습니다. 트래픽은 여전히 도착하여 외부 브리지를 통과할 수 있습니다. 외장 브리지는 브리지 한 단말의 가상화된 네트워크 정보 센터(NIC) 인터페이스와 브리지의 다른 엔드에 있는 물리적 외부 네트워크 정보 센터(NIC) 인터페이스를 사용하여 패킷과 프레임을 송수신합니다. 여러 유형의 내부 브리지가 호스트 OS의 가상화된 내부 스위치 기능을 통해 네트워크 정보 센터(NIC) 2개의 가상화된 내부 네트워크 정보 센터(NIC) 연결합니다. Virtio의 전반적인 아키텍처는 그림 6에 표시하고 있습니다.

그림 6: Virtio를 함께하는 VNF 브리지어링 VNF Bridging with Virtio

그림 6은 호스트 OS를 실행하는 단일 물리적 네트워크 정보 센터(NIC) 카드가 있는 서버 장치의 내부 구조를 보여줍니다(장비의 외부 커버는 표시되어 있지 않습니다). 호스트 OS에는 virtio로 구현된 가상 스위치 또는 브리지가 포함되어 있습니다. OS 위에서 일부 가상 머신은 Virtio를 통해 통신하는 가상 NI를 채용하고 있습니다. 그림에는 여러 개의 버추얼 머신이 실행되고 번호가 1에서 N로 나타났습니다. 표준 "dot dot dot" 표시는 그림에 나와 있지 않은 가능한 가상 머신 및 NI를 나타냅니다. 점선은 virtio를 사용하여 가능한 데이터 경로를 나타냅니다. 장비로 들어오고 나가는 트래픽은 물리적 트래픽과 포트를 통해 네트워크 정보 센터(NIC) 있습니다.

그림 6은 또한 디바이스가 내부 브리지를 통과하는 트래픽을 보여줍니다. 가상 머신 1은 가상화된 내부 네트워크 정보 센터(NIC) 물리적 외부 인터페이스와 네트워크 정보 센터(NIC) 연결합니다. 버추얼 머신 2 및 버추얼 머신 N은 호스트 OS의 내부 브리지를 통해 내부 가상 NI를 연결합니다. 이러한 인터페이스에는 관련 VLAN 레이블 또는 내부 인터페이스 이름이 있을 수 있습니다. VNF 간에 이 내부 브리지를 통해 전송되는 프레임은 결코 디바이스를 남겨 두지 않습니다. 호스트 OS에서 브리지(및 가상화된 스위치 기능)의 위치를 참고하십시오. 디바이스에서 간단한 브리지를 사용하는지 유의하십시오. 이러한 브리지는 일반 Linux 명령어로 구성하거나 구성 명령문을 사용하여 CLI 수 있습니다. 스크립트를 사용하여 프로세스를 자동화할 수 있습니다.

Virtio는 디스크 및 네트워크 디바이스 드라이버를 위한 가상화 표준입니다. 오직 게스트 디바이스 드라이버(가상화된 기능을 위한 디바이스 드라이버)만이 가상 환경에서 실행 중인지 알아야 합니다. 이러한 동인은 하이퍼바이저와 연동되어 가상 기능으로 성능 이점을 얻게 됩니다. Virtio는 아키텍처적으로 유사하지만 동일하지는 않습니다. Xen 패러다임화된 디바이스 드라이버(Xen에서 실행될 때 더 빠르게 만들기 위해 게스트에 추가된 드라이버). VMWare의 게스트 툴 역시 Virtio와 유사합니다.

트래픽의 상당수는 호스트 OS CPU에 집중됩니다. 즉, 보다 명시적으로 가상화된 내부 브리지에 있습니다. 따라서 호스트 CPU는 디바이스 확장에 따라 적절히 수행할 수 있어야 합니다.

SR-IOV 사용량 이해

물리적 디바이스가 가상화될 때 물리적 네트워크 인터페이스 카드(네트워크 정보 센터(NIC)) 인터페이스와 외부 물리적 스위치는 물론 가상 네트워크 정보 센터(NIC) 내부 가상 스위치가 공존하게 됩니다. 따라서 디바이스의 격리된 가상 머신(VM) 또는 컨테이너는 각각 자체 메모리와 디스크 공간 및 CPU 주기를 가지고 서로 통신을 시도할 때 사용 시 여러 포트, MAC 주소 및 IP 주소를 사용하는 데 어려움을 갖습니다.

SR-IOV는 가상화 기능의 개념을 물리적 네트워크와 네트워크 정보 센터(NIC). 단일 물리적 카드는 상위 레이어에서 실행되는 가상 기능과 네트워크 정보 센터(NIC) 포트당 최대 16개의 파티션으로 분할됩니다. 이러한 가상 기능 간의 통신은 일반적으로 브리지를 통해 개별 디바이스와 네트워크 정보 센터(NIC) 처리되는 방식으로 처리됩니다. SR-IOV는 SR-IOV 네트워크 정보 센터(NIC) 스위치의 생성, 삭제, 열기 및 쿼리를 위한 표준 메소드 세트는 물론, 설정할 수 없는 표준 매개 변수도 포함합니다.

SR-IOV의 단일 루트 부분은 모든 운영을 제어하는 기본 네트워크 정보 센터(NIC) 있는 것입니다. SR-IOV 지원 네트워크 정보 센터(NIC) 모든 네트워크 카드와 동일한 물리적 비트별 기능을 제공하는 표준 Ethernet 포트입니다.

그러나 SR-IOV는 또한 여러 가상 기능을 제공합니다. 이는 입력 및 출력 작업을 처리하는 단순한 큐를 통해 수행됩니다. 디바이스에서 실행되는 각 VNF는 이러한 네트워크 정보 센터(NIC) 파티션 중 하나에 매핑되어 VNF 자체가 모든 하드웨어 리소스에 네트워크 정보 센터(NIC) 있습니다. 또한 네트워크 정보 센터(NIC) 트래픽 큐로 프레임을 분류하는 단순한 Layer 2 정렬 기능도 제공합니다. 패킷은 직접 네트워크 가상 기능에서 DMA(Direct Memory Access)를 사용하여 VM의 메모리로 직접 이동되어 하이퍼바이즈를 완벽하게 우회합니다. SR-IOV 작업에서 네트워크 정보 센터(NIC) 역할은 그림 7에 표시되어 있습니다.

그림 7: SR-IOV를 사용한 VNF 통신 VNF Communication Using SR-IOV

하이퍼바이즈는 여전히 VNF를 가상 네트워크 기능에 할당하고, 패킷 내부의 데이터를 전송하지 않는 물리적 카드 관리에 관여하고 있습니다. VNF-VNF 통신은 Virtual 네트워크 정보 센터(NIC) 1, Virtual 네트워크 정보 센터(NIC) 2, Virtual 네트워크 정보 센터(NIC) N에 의해 수행됩니다. 또한 VNF와 외부 장치 포트 간 트래픽을 셔틀 네트워크 정보 센터(NIC) 정렬기에서 모든 가상 기능과 정렬을 추적하는 일부 가상 기능도 있습니다(표시하지 않습니다).

SR-IOV의 지원 능력은 플랫폼 하드웨어, 특히 데이터 전송을 위해 DMA를 네트워크 정보 센터(NIC) VNF 또는 컨테이너의 소프트웨어에 따라 달라집니다. 분할 가능한 NIC와 내부 브리게이션이 필요한 경우, 비용이 더 많이 들기 때문에 사용이 가능해 소형 장비의 비용을 크게 증가할 수 있습니다. VNF와 컨테이너를 재구성하는 작업은 사소한 작업이 아닙니다.

Virtio 및 SR-IOV 비교

Virtio는 유용한 가상화 기능의 표준 libvirt 라이브러리의 일부로 일반적으로 대부분의 Linux 버전에 포함되어 있습니다. Virtio는 소프트웨어 전용 접근 방식을 채택합니다. SR-IOV는 특정 방식으로 작성된 소프트웨어와 전문 하드웨어를 필요로 하기 때문에 간단한 디바이스에서도 비용이 증가합니다.

일반적으로 Virtio를 빠르고 쉽게 사용할 수 있습니다. Libvirt는 모든 Linux 배포의 일부로 브리지를 설정하기 위한 명령어가 잘 이해됩니다. 그러나 virtio는 일반적으로 VNF 간에 디바이스 안과 밖으로 연결되는 모든 트래픽을 연결하는 호스트 OS에서 성능의 모든 부담을 안고 있습니다.

일반적으로 SR-IOV는 짧은 시간, 즉 비가상 장치 성능으로 짧은 지연 시간을 제공하고 CPU 활용률을 낮출 수 있습니다. 하지만 VNF는 한 장비에서 다른 장치로의 VNF 마이그레이션은 복잡한 네트워크 정보 센터(NIC) 리소스에 의존하기 때문에 복잡합니다. 또한 VNF의 포우링 상태는 SR-IOV 스위치에 구축된 Layer 2 스위치에 네트워크 정보 센터(NIC). 이 때문에 포스터에 대한 규칙이 하드웨어에 코드화될 수 있으며 종종 변경할 수 있기 때문에 포링이 더 이상 유연하지 않습니다.

Virtio에 대한 지원은 거의 보편적이기 때문에 SR-IOV에 대한 지원은 하드웨어 및 플랫폼에 네트워크 정보 센터(NIC) 다릅니다. SR-주니퍼 네트웍스 NFX250 네트워크 서비스 플랫폼 지원하며 각 물리적 포트에서 16개 파티션을 네트워크 정보 센터(NIC) 있습니다.

주어진 VNF는 Virtio 또는 SR-IOV를 사용할 수 있습니다. 또는 지원되는 경우 두 가지 방법 모두를 동시에 사용할 수 있습니다.

참고:

Virtio는 가상화된 디바이스와 NFV 모듈을 연결하기 위한 권장 방법입니다.