AOS 10으로 마이그레이션 방법 및 유의사항 - 루바루바의 엣지있는 네트워크 이야기

HPE Aruba Networking의 차세대 무선 네트워크 운영체제로 AOS 10을 소개한지 벌써 5년 가까이 지났습니다.

Aruba 무선랜을 사용하는 상당수의 유저들은 AOS 8 기반의 아키텍처를 사용하고 있습니다. 하지만, 새로운 Wi-Fi 7의 액세스포인트들은 AOS 10 운영체제만 지원하고 있기 때문에 이제는 새로운 운영체제로의 마이그레이션을 검토할 시기입니다.

항상 새로운 운영체제로의 마이그레이션은 운영자 입장에서 고민거리가 많습니다.
어떠한 이슈가 발생할지 알 수 없고 예상치 못한 장애가 발생할 수도 있기 때문에 마이그레이션을 주저하는 것이 현실입니다.

따라서 이번 포스팅에서는 AOS 10으로 마이그레이션에 앞서 고려할 점을 살펴보겠습니다.

마이그레이션 준비 (Planning)

우선 AOS 8 아키텍처에 대한 이해가 먼저 필요합니다.

좌측 그림을 보면 캠퍼스 AP와 모빌리티 컨트롤러 클러스터, 모빌리티 컨덕터, 그리고 AirWave로 구성된 아키텍처가 있습니다.

AOS 8 환경에서 트래픽은 아래와 같이 움직입니다.

CAP¹와 MC²클러스터 사이에 GRE 터널링이 생성됩니다.
와이파이에 연결된 클라이언트 트래픽은 AP가 캡슐화하여 GRE 터널을 통해 클러스터로 전달합니다.
컨트롤러는 트래픽을 디캡슐링하여 트래픽을 검사하고 사용자 역할을 할당하고 태그를 지정한 다음 로컬 인터페이스를 통해 트렁크된 사용자 VLAN으로 전달합니다.
MC 클러스터와 MCR³사이에 IPsec 터널이 구성되어 서로간에 교환되는 모든 컨트롤 플레인 트래픽을 보호합니다.

여기에는 두 가지의 관리 프로토콜이 사용됩니다.

AP, MC, MCR 간의 PAPI⁴
MC에서 MCR 및 AirWave로 전송되는 AMON⁵

AOS 8 vs AOS 10 트래픽 흐름 비교

AOS 10은 구성에 따라 3가지 방식의 아키텍처를 지원합니다.

여기서는 AOS 8 캠퍼스 아키텍처와 유사한 AOS 10 터널모드와 비교해보도록 하겠습니다.
Wi-Fi 클라이언트 트래픽은 AOS 10 터널 모드와 AOS 8 캠퍼스 모드 모두에서 유사하게 처리되지만, 몇 가지 차이점이 있습니다.

GRE 터널은 동일하게 CAP와 MC사이에 구성됩니다.
AOS 10에서는 GRE도 IPSec으로 캡슐화 가능합니다.

AOS 8은 기본적으로 GRE 터널만 사용하지만, AOS 10은 이제 배포 또는 보안 정책에 필요한 경우 제어 및 데이터 트래픽을 종단 간 암호화할 수 있도록 GRE를 통한 IPsec을 제공합니다

기존 MCR과 AirWave는 Central로 대체됩니다.
어플라이언스 간의 IPSec, AMON 및 SNMP 트래픽이 AP 및 게이트웨이에서 Central로 전송되는 TCP 443 트래픽으로 대체됩니다.

AOS 10으로 마이그레이션시 주요 고려사항

AOS 10의 라이선스 및 Central 구독이 적절하게 이뤄졌는지 확인합니다.
HPE GreenLake 계정 생성 여부를 확인하여 없는 경우 계정을 생성합니다.
AP와 컨트롤러 모두 Central과 인터넷을 통해 연결될 수 있는지 방화벽의 정책을 업데이트합니다.
→ Aruba Central 방화벽 포트 및 URL 허용 목록
업그레이드 전에 컨트롤러의 AOS 버전이 8.10.0.12 또는 8.12.0.1 이상인지를 확인합니다.
→ 마이그레이션 및 롤백 기능을 위한 특정 기능과 명령(Command) 때문
AP에서 컨트롤러 검색이 제대로 구성이 되었는지 확인합니다.
→ AP의 시스템 프로필에서 개별 MC의 IP주소가 아닌 VRRP 주소를 가리키고 있는지 확인
캠퍼스 AP의 VLAN(관리용 인터페이스)와 무선 클라이언트 대역이 동일한 VLAN에 배치되지 않도록 확인합니다.
→ 만약 그런 환경인 경우, AOS 10 구성시에 서로 다른 VLAN으로 분리

마이그레이션시 발생할 수 있는 잠재적인 문제점들

브릿지(Bridge) 모드 아키텍처를 사용할 예정이라면..
→ ClearPass(또는 인증 서버)에서 각 AP를 NAD⁶로 추가 필요. 그렇지 않을 경우 인증 요청을 처리 못함
AOS 8에서 IAS⁷를 인증 서버로 활용한다면, AOS 10은 더 이상 지원하지 않으므로 대체 솔루션을 찾아야 합니다.
AOS 8에서 AP들이 고정IP로 구성되어 있다면, DHCP 서비스를 사용할 수 있는지 확인합니다.
→ AOS 10에서 AP는 DHCP 서비스가 필요
업그레이드 예정인 컨트롤러와 AP가 AOS 10을 지원하는지 확인합니다.
→ AOS 10 지원 디바이스 목록 확인
AP와 게이트웨이(컨트롤러)사이 유선 LAN에서 점보프레임이 지원하는지 확인합니다.
→ 완전히 캡슐화된 무선 트래픽의 패킷 조각화(Fragmentation) 때문에 성능 문제가 발생할 수 있음
AOS 8 클러스터가 L2 클러스터에 있는지 확인합니다.
→ L3 모드에 있을 경우, 무중단 장애복구(Hitless Failover)가 작동하지 않습니다.
→ L3 모드에 있을 경우, AP가 기존 MC에서 다른 MC로 이동할 때 클라이언트의 세션을 유지하지 않음

Q. ZTP를 사용하여 AOS 8 컨트롤러를 AOS 10으로 자동으로 업그레이드 할 수 있나요?

A. 이전에 펌웨어 업그레이드를 수행한 적이 있는 모든 컨트롤러는 수동으로 업그레이드 해야 합니다.

그 외에도 기타 문제점과 고려사항은 아래 문서에서 확인해볼 수 있습니다.
→ Planning Aruba AOS 8 to AOS 10 Migration

AOS 8에서 AOS 10으로 마이그레이션 워크플로우 예시

AOS 10으로 업그레이드 하는 방법은 여러 방식이 있을 수 있습니다.
네트워크 아키텍처는 각자 다른 구성을 갖고 있을 수 있기 때문에 하나의 방법이 정답이다 라고는 말하기 어려울 것입니다.

대신 HPE Aruba Networking에서 제시하는 검증된 가이드⁸에서 제시한 한 가지 예시를 갖고 얘기해볼까 합니다.
두 개의 MC가 L2 클러스터 환경으로 연결되어 있는 환경에서의 업그레이드 방법입니다.

1. 컨트롤러 #2 업그레이드

우선 모든 AP를 컨트롤러 #1로 이동시킵니다.

(USWH1MC01) [MDC] #apmove all target-v4 1.1.1.1

모든 AP가 컨트롤러 #1으로 이동했다면, 아무것도 연결되지 않은 컨트롤러 #2를 업그레이드 합니다.

NSP⁹에서 AOS 10 펌웨어 이미지 다운로드
웹브라우저를 통해 컨트롤러 #2 접속 및 로그인
Maintenance > Software Management > Upgrade 탭에서 다운 받은 이미지 업로드

어플라이언스 구성 정보는 백업하여 혹시 모를 상황을 대비합니다.

업로드가 완료되었다는 메시지가 표시되면, 버튼을 클릭하여 재부팅
컨트롤러가 지정된 Aruba Central 그룹에 표시될 때까지 기다리거나 콘솔을 통해 모니터링

AOS 10으로 업그레이드하면, 기존 컨트롤러라는 용어 대신 모빌리티 게이트웨이라는 이름으로 변경됩니다.

업그레이드된 게이트웨이가 네트워크에 연결되고, Central 그룹에 표시되는 것을 확인

2. 테스트 AP 업그레이드

전체 업그레이드하기 전에 AP 한 대를 테스트하여 정상적으로 동작하는지 여부를 확인합니다.

AOS 8 컨트롤러 #1를 SSH를 통해 로그인하여 AP를 AOS 10 AP로 컨버팅합니다.
먼저 리스트에 추가한 후에, Central 연결 등의 확인 절차를 거치게 됩니다.

(USWH1MC01) [MDC] #ap convert add ap-name <ap-name>
(USWH1MC01) [MDC] #ap convert pre-validate specific-aps

검증이 완료되면, IAP AOS 10 이미지 파일을 링크하여 업그레이드 진행합니다.

(USWH1MC01) [MDC] #ap convert active specific-aps server http common.cloud.hpe.com path ccssvc/ccs-system-firmware-registry/IAP <image name>

원격에서 작업 중이라면, AP가 연결된 스위치에서 LLDP의 Neighbour 정보를 통해 업그레이드를 확인할 수 있습니다.

AOS 8 환경을 유지라면, CAP로 표시됩니다.

AOS 10으로 업그레이드가 완료되면, IAP로 표시됩니다.

3. 나머지 AP들 업그레이드

테스트 AP 업그레이드가 성공하고 클라이언트 테스트 절차까지 완료되면,나머지 AP들도 업그레이드를 수행합니다.

테스트 AP는 프로덕션 환경과 동일하게 WLAN 및 SSID를 구성합니다.
그런 다음, SSID 프로필로 이동하여 ESSID를 수정하여 다른 클라이언트에 영향을 미치지 않도록 합니다.

이전의 첫 번째 테스트 AP 업그레이드와 동일하게 AP 컨버팅 명령어를 사용하여 남은 AP들을 업그레이드할 수 있습니다.

AP 그룹별, 층별 또는 캠퍼스 건물별로 업그레이드를 수행하여 영향을 최소화하도록 합니다.
전체 AP를 한 번에 이동할 경우, 네트워크 전체에 문제가 발생할 수 있습니다.

4. 컨트롤러 #1 업그레이드

이제 모든 AP를 게이트웨이 #2로 모두 이동시킨 후에, 컨트롤러 #1에 AP가 없는지 확인합니다.
앞서 1번 섹션에서 컨트롤러 #2를 업그레이드 했던 것과 마찬가지로 컨트롤러 #1을 업그레이드 합니다.

업그레이드가 완료되면, 사이트 유효성 검사를 비롯한 기타 남은 단계를 진행합니다.

AOS 8 vs AOS 10 구성 방식 차이

AOS 8 동작 방식 및 구성

AOS 8의 Mobility Conductor는 아래의 모든 구성요소를 하나의 관리 플랫폼으로 통합하여 전체(글로벌) 또는 그룹별 구성을 훨씬 더 간소화할 수 있는 계층적 구조를 제공합니다.

AP 및 컨트롤러 구성 및 관리를 위한 중앙 집중식 아키텍처의 핵심적 역할
물리 방식 또는 가상머신의 MCR(Mobility Conductor)
다단계 계층 구조 방식: Top-down 방식으로 구성 정보 전달
→ 필요한 경우, 그룹별, 특정 사이트별 정책 설정 가능
서비스 중앙집중화
– RF 관리 (AirMatch)
– 클라이언트 단말 최적화 (ClientMatch)
– 서비스 검색 (AirGroup)

AOS 10(New Central) 동작 방식 및 구성

AOS 10에서는 모든 것은 클라우드 기반의 Aruba Central에서 관리됩니다. 즉, 별도의 MCR이 필요하지 않습니다.

모든 게이트웨이와 AP는 구성과 업데이트, 모니터링을 Central을 통해 이뤄지게 됩니다.
따라서 모든 오케스트레이션이 Aruba Central에서 수행되어지게 됩니다.

전체적인 아키텍처는 AOS 8보다 훨씬 간소화해지고 온 프레미스 서버의 요구사항이 줄어듭니다.
계층적 구조는 여전히 존재하지만, 아래와 같이 Central을 통해 보다 유연한 계층적 구조를 가져갑니다.

이러한 유연성은 아래와 같은 특성과 함께 일관성을 유지하면서 로컬 사이트의 변화를 받아들이기 원활합니다.

유연한 계층적 구성 방식: 글로벌, 사이트, 또는 장치별로 그룹화하여 정책 구성 및 설정할 수 있게 됩니다.
서비스 중앙집중화: AirMatch, ClientMatch, AirGroup 등과 같은 서비스가 모두 클라우드에 통합됩니다.
확장성: 클라우드 환경에서 분석과 모니터링을 하기 때문에 배포 환경을 확장하기 용이합니다.
플랫폼의 진화: AOS 10은 매월 새로운 기능과 개선사항을 업데이트하여 변화하는 요구사항에 쉽게 대응합니다.
다양한 환경 지원: 캠퍼스와 지사(Branch) 환경 모두 사용이 가능하며, 대규모 사이트, 분산환경 모두 대응 가능합니다.

New Central(CNX)에서의 계층 모델

새로운 Central(CNX)에서는 기존 Central과 다른 계층 구조를 가져갑니다.
아래 그림을 보면 좌측에 Central 구성 UI 일부를 확인할 수 있습니다.

Library: 프로필을 저장. 기존 프로필에서 설정 변경 후에 “다른 이름으로 저장”과 유사한 기능
Global: 조직 전체에 일관성을 유지해야 할 필요가 있는 구성을 적용하는 곳.
→ 모든 사이트에서 상속 받는 항목들 – SSID, 역할명, VLAN 이름 등
Site Collection: 오피스, 유통센터, 상점들 사이트들을 그룹화한 것
Site: 뉴욕, 시카고 등 각각의 개별 사이트
→ 특정 사이트에 별도로 지정하고 싶은 설정은 여기에서 정의 가능
Device: 각 사이트에 배포된 게이트웨이, 스위치 AP 등의 장치
Device Group: 유사한 성격을 갖는 장치들을 논리적으로 그룹화

이 계층 구조를 통해 전 세계 여러 지역과 사이트 유형에 걸쳐 수천개의 장치를 관리할 수 있습니다.
필요하다면, 사이트별로 또는 장치별로 조정 가능한 유연성을 확보할 수 있습니다.

이러한 방식은 일상적인 관리를 간소화하고, 전체적으로 네트워크 일관성을 지킬 수 있게 됩니다.

AOS 8 구성 정보 확인

Central에서 새로운 AOS 10 솔루션을 구성하려면 기존 AOS 8 환경에서 필요한 모든 정보를 수집하세요.

필요한 정보 수집

네트워크에서 필요한 정보는 CLI나 Web UI, AirWave 등을 통해서 수집할 수 있습니다.

환경에 따라 Mobility Conductor(MCR), Mobility Controller(MC), AirWave 등에서 다양한 정보를 얻어야 할 수 있습니다.
다음 가이드를 보면, 보다 자세한 정보와 CLI 명령어 등을 확인할 수 있습니다.

→ AOS 10 Migration VSG – AOS 8 Configuration Discovery

Tip! 가장 효과적인 방법으로 MCR 계층 구조 내에서 구성 정보를 수집 및 필터링, 구성하는 방법입니다.
(MobilityConductor) [mynode] #show configuration effective detail
명령어를 통해 출력된 정보를 Excel sheet에 붙여 넣습니다.

위 스크린샷의 순서대로 구성 정보를 “#”를 기준으로 구성값과 소스값을 분리합니다.

채워진 셀(Cell)을 강조 표시(Highlight)합니다.

테이블을 변환(Ctrl + T)합니다.

그럼 아래 그림과 같이 표시됩니다.

특정 노드에서 커밋한 구성을 보려면, 오른쪽 열의 콘텐츠를 기준으로 필터링합니다.

WLAN 구성 레퍼런스: AOS 8 프로필 → AOS 10 프로필

아래 이미지는 AOS 8 구성의 일반적인 개요와 AOS 10 프로필 구성 페이지 내의 해당 설정을 보여줍니다.
이전 검색 단계에서 수집한 정보는 성공적인 업그레이드에 필요한 모든 매개변수를 제공합니다.

AOS 8에서 각각 설정했던 프로필들은 New Central에서 각각의 프로필을 설정할 수 있는 GUI 타일로 보여줍니다.

이렇게 AOS 8에서 AOS 10으로 넘어가기 위해 알아봐야 할 부분들을 살펴보았습니다.

위의 내용은 아주 기본적인 구성에서 업그레이드하기 위한 고려사항들과 함께 방법을 나열한 것입니다.
즉, 실제 환경과 구성에 따라 체크리스트는 더 많아질 수도 있고 고민해야 할 부분도 늘어날 수 있습니다.

대규모 사이트의 업그레이드 및 마이그레이션은 충분한 논의와 검토 후에 시행해야 이슈 없이 안정적으로 넘어갈 수 있습니다.
제조사에서 제공하는 여러 가이드 문서도 차근차근 읽어보면서 계획서를 작성하고 검증한다면 보다 쉽게 검토할 수 있을 것입니다.

Grossary

CAP: Campus AP ↩︎
MC: Mobility Controller ↩︎
MCR: Mobility Conductor (舊 Mobility Master) ↩︎
PAPI: Protocol Application Programming Interface ↩︎
AMON: Advanced Monitoring ↩︎
NAD: Network Access Device ↩︎
IAS: Internal Authentication Server, 컨트롤러의 내부 데이터베이스 ↩︎
VSG: Validated Solution Guide ↩︎
NSP: HPE Networking Support Portal ↩︎