ACMA 자격증 시험은 AOS 8 운영체제를 기반으로 진행됩니다. 그렇기 때문에 AOS 8 아키텍처에 대해 이해하는 것은 중요합니다. 지난 포스팅에서 Aruba 무선랜 포트폴리오에 대해서 이미 설명을 드렸는데요.
AP(Access Point)를 설명하면서 CAP(Campus AP)와 IAP(Instant AP)에 대한 개념을 말씀드렸습니다.
오늘은 AOS 8 아키텍처는 어떠한 구조를 갖고 있고, 예전 AOS 6와는 어떠한 차이가 있는지 살펴보겠습니다.
AP Terminology (용어 설명)
먼저, AP에 역할별 불리는 이름에 대해서 용어를 정리하고 넘어가보겠습니다.
AP는 WLAN 아키텍처에서 특정한 역할을 부여 받아 구성할 수 있습니다. 그리고 그 역할에 따라 각각 이름이 달리 명명합니다.
먼저, CAP는 Campus AP로 일반적으로 그냥 AP로 불리기도 합니다. 전형적인 AP로 컨트롤러에 연결되어 모든 구성을 컨트롤러부터 명령 받게 됩니다. Mesh AP는 CAP의 일종으로 Uplink가 유선이 아닌 무선 인터페이스를 사용합니다.
AM(Air Monitor)는 지속적으로 무선 환경을 스캔하여 IDS나 RF 정보를 수집합니다.
SA(Spectrum Analyzer)는 분석을 목적으로 일시적 또는 영구적으로 설정하여 주변의 무선 신호를 캡처하는 AP입니다.
RAP(Remote AP)는 CAP랑 유사하게 동작합니다. 하지만, 인터넷을 통해 컨트롤러와 연결합니다. 이를 위해서 컨트롤러와 AP간에 VPN 터널 설정이 필요합니다.
IAP(Instant AP)는 컨트롤러가 필요하지 않습니다. 동일한 서브넷 내의 모든 IAP는 그룹(Swarm)을 구성하고, 그 중에서 VC(Virtual Controller, 가상 컨트롤러) 역할을 수행할 AP를 선택합니다. 이를 통해 IAP는 하드웨어적인 컨트롤러 없이 독립적으로 운영할 수 있습니다.
Controller Mode
Aruba는 세 가지 컨트롤러 모드를 제공합니다.
- Mobility Conductor (Mobility Master)
- Mobility Controller
- Standalone
Mobility Conductor (Mobility Master, MM)
관리 및 제어, 전달 기능을 명확하게 구분하는 새로운 UI에서 중앙 집중형의 멀티 티어 아키텍처를 사용합니다.
중앙 집중되는 지점으로 Mobility Conductor와 관리되는 장치 모두 전체 구성을 설정할 수 있기 때문에 구성 프로세스를 단순화하고 간소화할 수 있습니다.
Mobility Controller (MC)
Mobility Conductor(Mobility Master, MM)는 Mobility Controller를 관리합니다. 그리고 그 컨트롤러는 관리되는 장치(Managed Device, MD)나 관리받는 노드(Managed Node, MN)으로 불리기도 합니다. MD는 AP와 클라이언트 트래픽을 처리하고, 여러 MD는 함께 작동하여 모든 클라이언트 단말에게 고가용성을 제공하고 failover가 발생하더라도 서비스 연속성을 보장합니다.
Standalone
Mobility Conductor는 Standalone 컨트롤러를 관리할 수 없습니다. 컨트롤러를 Standalone 모드로 설치하게 되면, AOS 8.x 일부 기능을 사용할 수 없게 됩니다.
AOS 8 아키텍처
Mobility Conductor (Mobility Master, MM)과 같은 중앙 집중 지점을 통해 Mobility Conductor와 관리되는 장치(MD) 모두 구성할 수 있다고 앞서 설명했습니다.
MM은 기존의 all-master, 단일 master-다중 local, 또는 여러 개의 master-local 배포 방식을 단일 모델로 통합합니다. 공통 구성(기본 구성)을 공유 탬플릿으로 추출해서 장치별 구성을 병합하거나 개별 장치에 대한 구성을 생성할 수 있게 됩니다.
관리 노드(MC/MD)는 AP와 클라이언트 트래픽을 처리합니다. ZTP(Zero Touch Provisioning)을 통해 BOC(Branch Office Controller, 지점 컨트롤러)를 배포할 수도 있습니다.
AOS 6 아키텍처와의 차이
Master Controller vs Mobility Conductor(MM)
예전 AOS 6에서는 MC(Master Controller)를 물리적 어플라이언스에 구축하고, AP까지 보안 터널을 구성할 수 있었습니다. master-local 구조로 구성하여, Master는 일부 구성(AP Group, Local DB, Whitelist DB 등)을 모든 local로 배포(푸시)하고 구성 정보(syntax, parameter 값 범위)를 보내기 전에 검증하지 않습니다.
하지만, AOS 8에서는 물리적 어플라이언스 장치 또는 가상 어플라이언스(VM) 모두에 MM(Mobility Conductor)를 구축할 수 있습니다. 하지만, AP까지 터널링 구성을 하지 않습니다. MM은 관리되는 장치(MD/MC) 모두에게 전체 구성정보를 푸시할 수 있습니다. 그리고 그 구성 정보를 MD로 푸시하기 전에 검증하게 됩니다.
Local Controller vs Managed Node
AOS 6에서는 물리 어플라이언스에만 로컬(Local) 컨트롤러를 구축할 수 있고, Master Controller로부터 일부(Partial) 구성정보를 받아와야만 했습니다. 하지만, VLAN이나 내부 IP주소 등과 같은 L2, L3 구성 정보는 로컬 컨트롤러에서 구성해야 했습니다.
하지만, AOS 8에서는 관리형 노드(Managed Node, MN)을 물리 장치나 가상 머신 모두에 구축 가능합니다. 그리고 MM(Mobility Conductor)는 L2와 L3 구성 정보를 포함한 모든 구성(Config)을 제공합니다.
Partial Config vs Hierarchical Config Model
AOS 6.x의 부분 구성 모드(Partial Configuration mode)에서는 마스터(Master)는 데이터베이스(위 그림의 오렌지색)와 함께 WLAN 구성만 푸시합니다. VLAN이나 인터페이스 정보, IP 라우팅과 같은 L2, L3 구성은 푸시할 수 없습니다. 이러한 정보는 각 로컬 컨트롤러에서 직접 따로따로 구성해야만 합니다.
하지만, 위 그림과 같이 AOS 8.x 모델로 구성한다면, Mobility Master(MM, Mobility Conductor)는 VLAN이나, 인터페이스 정보, IP 라우팅 등 전체 구성 정보를 푸시할 수 있습니다.
이제는 Digital Transformation 이라는 용어와 함께 모빌리티 환경, 모바일 오피스가 필수적이 되고 있습니다. 그러기 위해서는 안정적이고 확장 가능한 무선 네트워크 인프라가 필요합니다.
이러한 요구사항과 트렌드에 맞춰 아루바는 AOS 8이라는 새로운 아키텍처의 운영체제를 출시하게 되었고, 어느새 10번째 업데이트인 8.10.x 버전을 릴리즈 하게 되었습니다.
무선 네트워크에 연결되는 단말의 수가 증가하고, 끊어짐 없이 유지되어야 하고 IoT 연결을 제공할 수 있어야 하는 등 다양한 요구사항에 맞춰서 AOS 8의 기능은 계속 업데이트 되고 있습니다.
다음 포스팅에서는 AOS 8의 특화된 기능을 알아보도록 하겠습니다.
