JDM 아키텍처 개요

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

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

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

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

JDM은

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

• 타사 모듈 설치.

• VNF 서비스 체인 형성.

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

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

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

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

참고:

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

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

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

최저 계층은 하드웨어 계층입니다. 메모리(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에 표시하고 있습니다.

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

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

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 에표시된 컨테이너의 전체 아키텍처

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

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

• 구성 파일입니다.

• 표준 운영 세트

• 실행 환경.

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

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

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

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

• Virtio 활용도 이해
• SR-IOV 사용량 이해
• Virtio 및 SR-IOV 비교