JDM 아키텍처 개요

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

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

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

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

JDM을 통해 다음을 수행할 수 있습니다.

• 수명 주기 동안 게스트 VNF(가상 네트워크 기능) 관리.

• 타사 모듈 설치.

• VNF 서비스 체인 형성

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

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

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

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

메모:

디스어그리게이션된 기본 Junos OS 아키텍처를 다양한 플랫폼에서 구현하는 방법에는 여러 가지가 있습니다. 세부 사항은 크게 다를 수 있습니다. 이 항목에서는 전체 아키텍처에 대해 설명합니다.

고정 하드웨어에서 실행되는 간단한 소프트웨어 프로세스의 가상화는 프로세스 간 통신 영역에서 몇 가지 문제를 제기합니다. 예를 들어, NAT 기능이 있는 VNF는 동일한 디바이스에서 컨테이너로 실행되는 방화벽과 어떻게 연동됩니까? 결국 전체 디바이스에 하나 또는 두 개의 외부 이더넷 포트만 있을 수 있으며 프로세스는 여전히 디바이스 내부에 있습니다. 한 가지 이점은 이러한 가상화된 프로세스 간의 인터페이스가 SXE 포트로 자체적으로 가상화되는 경우가 많다는 사실입니다. 즉, 프로세스 간에 직접 또는 프로세스와 호스트 OS 사이, 그리고 호스트 OS와 다른 프로세스 사이에 일종의 MAC 레이어 브리지를 구성할 수 있습니다. 이는 트래픽이 디바이스에 들어오고 나갈 때 서비스 체인을 지원합니다.

JDM은 사용자에게 친숙한 Junos OS CLI를 제공하고 기본 Linux 커널과의 모든 상호 작용을 처리하여 주니퍼 네트웍스 디바이스의 "모양과 느낌"을 유지합니다.

분할된 Junos OS의 몇 가지 이점은 다음과 같습니다.

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

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

• 이러한 애플리케이션과 도구는 일반적인 Linux 리포지토리를 사용하여 업그레이드할 수 있으며 Junos OS 릴리스와 독립적입니다.

• 모듈화는 결함이 모듈 내에 포함되어 있기 때문에 신뢰성을 높입니다.

• 제어 및 데이터 플레인은 API를 통해 직접 프로그래밍할 수 있습니다.

세분화된 Junos OS 사양에는 아키텍처 모델이 포함됩니다. 집의 건축 모델은 부엌, 지붕 및 식당을 포함하는 방향을 가질 수 있으며 다양한 종류의 주거를 나타낼 수 있습니다. 바닷가 별장에서 궁전 같은 저택까지. 이 집들은 모두 매우 다르게 보이지만 여전히 기본 건축 모델을 따르고 많은 특성을 공유합니다.

마찬가지로, 디스어그리게이션된 Junos OS 아키텍처 모델의 경우, 모델은 단순한 CPE(Customer Premises Equipment)에서 대규모 데이터센터에 설치된 복잡한 스위칭 장비에 이르기까지 매우 다양한 유형의 플랫폼을 다루지만, 플랫폼들이 공유하는 몇 가지 기본 특성을 가지고 있습니다.

이러한 플랫폼들은 어떤 특성을 공유하나요? 디스어그리게이션된 모든 Junos OS 플랫폼은 3개의 레이어에 구축됩니다. 이러한 계층과 가능한 몇 가지 콘텐츠가 그림 3에 나와 있습니다.

가장 낮은 계층은 하드웨어 계층입니다. 메모리(RAM) 및 디스크 공간(SSD) 외에도 플랫폼 하드웨어에는 관리에 사용되는 외부 NIC 포트가 있는 멀티 코어 CPU가 있습니다. 경우에 따라 제어 및 데이터 플레인에 사용되는 단일 NIC 포트가 있지만 해당 포트는 사용자 트래픽 스트림을 위해 패킷 포워딩 엔진과 통신하는 데에도 사용될 수 있습니다.

플랫폼 소프트웨어 계층은 하드웨어 계층 위에 있습니다. 모든 플랫폼 종속 기능이 여기에서 발생합니다. 이러한 기능에는 다양한 가상 구성 요소에 대한 소프트웨어 스위칭 기능이 포함되어 이들 사이의 트래픽을 브리징할 수 있습니다. Linux 또는 KVM(커널 기반 가상 머신)이 플랫폼을 실행하며, 일부 모델에서는 Phone Home 에이전트가 공급업체 또는 서비스 제공업체 디바이스에 연결하여 자동 구성 작업을 수행합니다. Phone Home Agent는 특히 소규모 CPE 플랫폼에 선호됩니다.

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

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

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

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

플랫폼마다 다를 수 있는 이 일반 모델에서 데이터는 물리적 NIC의 포트를 통해 입력되고 대상 MAC 주소에 따라 가상 스위치 기능을 통해 가상 NIC 1을 통해 가상 머신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(Domain Name System)와 같은 간단한 서비스를 제공하는 것임에도 불구하고 게스트 운영 체제의 리소스 집약적 오버헤드에 전체 버전의 운영 체제가 포함되어야 하는 경우가 많다는 것입니다.

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

표준 Linux 컨테이너는 표준 컨테이너라고 하는 소프트웨어 제공 단위를 정의합니다. 전체 게스트 운영 체제를 캡슐화하는 대신 표준 컨테이너는 응용 프로그램 및 응용 프로그램이 수행하도록 프로그래밍된 작업을 수행하는 데 필요한 모든 종속성만 캡슐화합니다. 이 단일 런타임 요소는 수정할 수 있지만 확장 함수에 필요할 수 있는 추가 종속성을 포함하도록 컨테이너를 다시 빌드해야 합니다. 그림 5에 나와 있는 컨테이너의 전체 아키텍처입니다.

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

표준 컨테이너에는 다음이 포함됩니다.

• 구성 파일입니다.

• 표준 작업 집합입니다.

• 실행 환경입니다.

컨테이너 이름은 전 세계 상품을 운송하는 데 사용되는 선적 컨테이너에서 차용한 것입니다. 선적 컨테이너는 컨테이너를 처리하기 위해 특별히 제작된 장비로 적재, 라벨링, 적재, 들어 올리기 및 하역할 수 있는 표준 배송 단위입니다. 내부에 무엇이 있든 컨테이너는 표준 방식으로 처리할 수 있으며 각 컨테이너에는 다른 컨테이너에서 사용할 수 없는 고유한 사용자 공간이 있습니다. Docker는 물리적 서버에서 컨테이너를 실행하는 데 널리 사용되는 컨테이너 관리 시스템이지만 고려해야 할 Drawbridge 또는 Rocket과 같은 대안이 있습니다.

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

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

virtio를 사용하거나 적절한 하드웨어 및 단일 루트 I/O 가상화(SR-IOV)를 사용하여 Linux 기반 가상화 장치와 NFV(Network Functions Virtualization) 모듈 간의 통신을 활성화할 수 있습니다. 각 방법에는 고유한 특성이 있습니다.

• Virtio 사용법 이해
• SR-IOV 사용 이해
• Virtio와 SR-IOV 비교