JDM 아키텍처 개요

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

JDM은 분할된 Junos OS 아키텍처의 유일한 루트 컨테이너입니다(둘 이상의 루트 컨테이너를 허용하는 다른 업계 모델이 있지만 세분화된 Junos OS 아키텍처는 그 중 하나가 아닙니다). 세분화된 Junos OS 단일 루트 모델입니다. JDM의 주요 기능 중 하나는 플랫폼의 수정 및 활동이 기본 호스트 OS(일반적으로 Linux)에 영향을 미치지 않도록 하는 것입니다. 루트 엔티티인 JDM은 이러한 작업에 적합합니다. JDM의 다른 주요 기능은 디바이스의 하드웨어를 가능한 한 전통적인 Junos OS 기반의 물리적 시스템과 비슷하게 보이게 하는 것입니다. 또한 이를 위해서는 일종의 루트 기능이 필요합니다.

그림 1 은 JDM이 전체 아키텍처에서 차지하는 중요한 위치를 보여줍니다.

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

JDM은 다음과 같은 기능을 지원합니다.

• 수명 주기 동안 게스트 VNF(virtualized network functions)를 관리합니다.

• 타사 모듈 설치.

• VNF 서비스 체인 구성.

• guest VNF 이미지 관리(이들의 이진 파일).

• 시스템 인벤토리 및 리소스 사용량을 제어합니다.

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

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

참고:

다양한 플랫폼에서 기본 분할 Junos OS 아키텍처를 구현하는 방법에는 여러 가지가 있습니다. 세부 사항은 크게 다를 수 있습니다. 이 주제에서는 전체 아키텍처에 대해 설명합니다.

고정 하드웨어에서 실행되는 간단한 소프트웨어 프로세스의 가상화는 프로세스 간 통신 영역에서 몇 가지 과제를 안고 있습니다. 예를 들어, NAT 기능이 있는 VNF가 동일한 디바이스에서 컨테이너로 실행되는 방화벽과 어떻게 작동합니까? 결국 전체 디바이스에 하나 또는 두 개의 외부 이더넷 포트만 있을 수 있으며 프로세스는 여전히 디바이스 내부입니다. 한 가지 이점은 이러한 가상화된 프로세스 간의 인터페이스가 주로 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에 표시됩니다.

가장 낮은 레이어는 하드웨어 레이어입니다. 플랫폼 하드웨어에는 메모리(RAM) 및 디스크 공간(SSD) 외에도 관리에 사용되는 외부 NIC 포트가 있는 멀티코어 CPU가 있습니다. 컨트롤 플레인 및 데이터 플레인에 사용되는 단일 NIC 포트가 있지만 해당 포트는 사용자 트래픽 스트림에 대한 패킷 전달 엔진 통신하는 데 사용될 수도 있습니다.

플랫폼 소프트웨어 레이어는 하드웨어 레이어 위에 있습니다. 모든 플랫폼 기반 기능이 여기에서 열립니다. 이러한 기능에는 다양한 가상 구성 요소를 위한 소프트웨어 스위칭 기능이 포함될 수 있습니다. Linux 또는 커널 기반 가상 머신(KVM)이 플랫폼을 실행하고, 일부 모델에서는 전화 홈 에이전트가 벤더 또는 서비스 프로바이더 디바이스에 연락하여 자동 구성 작업을 수행합니다. 전화 홈 에이전트는 소형 CPE 플랫폼에서 특히 선호됩니다.

플랫폼 소프트웨어 레이어 위에는 다양한 플랫폼 독립 기능에 초점을 맞추고 있는 고객 소프트웨어 레이어가 있습니다. 일부 구성 요소는 가상 SRX 디바이스(vSRX 가상 방화벽) 또는 Junos 컨트롤 플레인(JCP)과 같은 가상 머신에 주니퍼 네트웍스 수 있습니다. 이 JCP JDM과 연동되어 디바이스를 전용 주니퍼 네트웍스 플랫폼과 비슷하게 만들지만 더 많은 유연성을 제공합니다. 이러한 유연성의 대부분은 가상화된 네트워크 기능(VNF)을 구현하는 하나 이상의 VNF를 지원하는 능력에서 비롯됩니다. 이러한 VNF는 네트워크 주소 변환(NAT), DNS(Specialized Domain Name System) 서버 조회 등과 같은 여러 유형의 작업으로 구성됩니다.

일반적으로 고정된 수의 CPU 코어와 한정된 양의 디스크 공간이 있습니다. 그러나 가상 환경에서는 리소스 할당 및 사용이 더 복잡합니다. 인터페이스, 디스크 공간, 메모리 또는 코어와 같은 가상 리소스는 VNF 이미지에 의해 결정되는 대로 당시 실행되는 VNF 간에 파지됩니다.

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

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

다른 플랫폼에 변형이 있을 수 있는 이 일반 모델에서는 물리적 NIC의 포트를 통해 데이터가 입력되고 가상 스위치 기능을 통해 목적지 MAC 주소 따라 가상 머신1에서 가상 NIC 1로 브리징됩니다. 트래픽은 물리적 포트로 다시 전달되어 디바이스를 종료할 때까지 구성된 다른 가상 인터페이스를 통해 Virtual Machine2 또는 더 많은 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)의 가상화 뷰를 제공합니다(일반적인 상황). 하이퍼바이저는 물리적 NIC를 관리하고 가상화된 인터페이스만 VNF에 노출합니다.

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

VNF의 가장 큰 장점은 대부분의 애플리케이션을 하이퍼바이저 환경에 쉽게 이식하고 수정 없이 잘 실행할 수 있다는 것입니다.

가장 큰 결단은 대개 게스트 운영 체제의 리소스가 매우 많은 오버헤드가 전체 VNF의 기능이 DNS(도메인 이름 시스템)와 같은 간단한 서비스를 제공하는 경우에도 전체 버전의 운영 체제를 포함해야 한다는 것입니다.

VNF와 달리 컨테이너는 가상 환경에서 독립적인 작업으로 실행하도록 특별히 제작되었습니다. 컨테이너는 VNF처럼 전체 운영 체제를 번들하지 않습니다. 여러 가지 방법으로 컨테이너를 코딩하고 번들화할 수 있지만 유지 관리 및 확장이 용이한 표준 컨테이너를 구축하는 방법도 있습니다. 표준 컨테이너는 우연한 방식으로 생성된 컨테이너보다 훨씬 더 개방적입니다.

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

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

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

• 구성 파일입니다.

• 일련의 표준 운영.

• 실행 환경.

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

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

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

Virtio를 사용하거나 적절한 하드웨어 및 SR-IOV(Single-Root I/O 가상화)를 사용하여 Linux 기반 가상화 디바이스와 NFV(네트워크 기능 가상화) 모듈 간의 통신을 활성화할 수 있습니다. 각 방법은 고유한 특성을 가지고 있습니다.

• Virtio 사용량 이해하기
• SR-IOV 사용량 이해
• Virtio와 SR-IOV 비교