みなさん、こんにちは。

本ブログではarubaの無線LANコントローラの冗長化方式をご紹介します。

arubaではAOSのバージョンを6から8にあげると、アーキテクチャが大きく変更されます。

最近のリリース機器ではAOS6をサポートしなくなっており、今後AOS8への移行はますます加速されると思います。
今回はAOS8編としていますが、AOS6編は現状予定しておりません。

AOS6編はご要望があれば記載したいと思います。

　目次　

はじめに.
1. MM-MD/MCM-MD
　1.1 MM/MCMの冗長化
　　1.1.1 L2 Redundancy
　　1.1.2 L3 Redundancy
　　1.1.3 L2&L3 Redundancy
　1.2 MDの冗長
　　1.2.1 Cluster
　　1.2.2 VRRP
　　1.2.3 HA
　　1.2.4 Backup LMS
2.Stabdalone
　2.1 Standaloneコントローラの冗長化
　　2.1.1 Master Redundancy
　　2.1.2 VRRP
　　2.1.3 HA
　　2.1.4 Backup LMS
まとめ.

はじめに.

複数台のコントローラ導入時の考慮点の一つに各コントローラの管理方法があります。

2-3台のコントローラであれば個別に設定を管理することはまだ現実的かと思いますが、台数が増えるにつれて個別の管理は難しくなってきます。

arubaではコントローラを管理するMasterコントローラを導入することで一元的に管理可能とし、設定/管理の負担を軽減することが可能です。

AOS8ではコントローラを一元管理する構成としてMM-MDとMCM-MDの2つ、各コントローラを個別に管理する構成としてStandaloneが存在します。

ここからはコントローラの管理方法にあわせて、各構成での冗長化方式をご紹介させていただきます。

1. MM-MD/MCM-MD

AOS8のMM-MD/MCM-MD構成では、Mobility Master(MM)、もしくはMobility Controller Master(MCM)が各コントローラの管理を行い、管理されるコントローラはManaged Device(MD)と呼ばれます。

※今後出てくる図ではコントローラ、APが直接接続されているように記載していますが、あくまで概要図となり実際はスイッチ等を介した接続となるケースが多いです。

図1. MM-MD/MCM-MD

簡単に各機器の役割をご紹介します。

・Mobility Master(MM)

MMは無線LANコントローラーのコントロールプレーンを担います。
設定/管理だけではなく、APのチャネルの調整や電波出力調整などすべてMMで処理します。

AOS6とは異なりMMではAPを収容することができません。

AOS8の全ての機能を利用するにはMMが必須となり、その中でもAirMatchの機能が重要となっています。

従来はARM(Adaptive Radio Management)で電波環境の調整を行っていましたが、ARMは各APが個別で計算しているため、周辺の電波状況の変化により各APの変化が発生しやすいというデメリットもありました。

AirMatchではMMが各APの状況を収集しすべてを一元管理しますので、安定した電波環境が提供しやすくなっています。

・Mobility Controller Master(MCM)

MCMはMMから設定管理機能を切り出したイメージで、AirMatchをはじめとするAOS8の特徴的な機能が利用できません。

MCMは7030と7200シリーズのコントローラのみがサポートされており、MM同様にAPの収容はできず、仮想環境上で動作するVMCも管理できません。

このように制限事項も多いため、MCM-MD構成を利用される場合は注意が必要です。

それではMM-MD/MCM-MD構成における冗長化方式についてご説明します。

1.1 MM/MCMの冗長化

ここではMasterコントローラとなる、MM/MCMの冗長化方式についてご説明します。

MM/MCMの冗長化方式にはL2 Redundancyがあります。
またMMのみの冗長化方式としてL3 Redundancyもあり、双方を組み合わせたL2&L3 Redundancyでの冗長も可能です。

MM/MCMの冗長は全てActive-Stanby構成での冗長となります。

1.1.1 L2 Redundancy

L2 RedundancyではVRRPによる冗長となり、Active/StandbyとなるMM/MCMの管理IPアドレスは同一セグメントの必要があります。

MDはMM/MCMのIPとしてVRRPのVIPを指定します。

ActiveのMM障害時でStandbyに切り替わった際にはStandby側での設定変更が可能となり、VRRPの設定次第で切り戻り(preempt)も可能です。

図1.1.1 L2 Redundancy

1.1.2 L3 Redundancy

L3 Redundancyでは2台のMMの管理IPアドレスが同一セグメントである必要がないため、サイト間での冗長が可能となります。

MDはMMのIPをPrimary/Secondaryでそれぞれ指定します。

MD側でPrimaryのMM障害を検知してから15分後にSecondaryへと切り替わり、Primaryが復旧した場合には必ずPrimaryへの切り戻りが発生します。

またSecondaryへ切り替わっている際は、Secondary側での設定変更は行うことができず、変更する場合は手動でPrimaryへと役割変更をする必要があります。

L3 Redundancyではモニタリングなど一部のデータは同期されません。

前述の通りL3 RedundancyはMMのみで構成可能となり、MCMでは構成できません。

図1.1.2 L3 Redundancy

1.1.3 L2&L3 Redundancy

L2/L3 Redundancyの組み合わせで最大4台のMMの冗長化が可能となります。

MDはMMのPrimary/SecondaryとしてそれぞれのVRRPのVIPを指定します。

この冗長を取ることでMM1台の単一障害ではL2 RedundancyのVRRPにより切り替わり、サイト障害の際にはL3 RedundancyでSecondaryのMMに切り替えることが可能となります。

図1.1.3 L2&L3 Redundancy

1.2 MDの冗長

次にMDの冗長化方式をご紹介します。
MDの冗長化方式としては大きく4つあります。

1.2.1 Cluster

Clusterはその名の通りMDをクラスタリングすることで冗長化を図ります。

Clusterによる冗長化はMMが必須となり、MCMによる構成ではサポートされません。

MD間でメッシュ状にIPsecトンネルを構築し、情報を同期することでクラスタリングを構成します。

Cluster内のMDはAPを終端するコントローラ(AAC:AP Anchor Controller)、クライアント(のトラフィック)を終端するコントローラ(UAC:User Anchor Controller)の役割を持ち、それぞれにActive/Standbyが存在します。

ClusterではMDの型番により冗長可能な台数に上限があります。
7200シリーズが最大で12台でのClusterが構成可能です。

APはCAP、CPsec APをサポートし、RAPはCert-based RAPのみサポートとなります。(PSK RAPは未サポート)
またMesh APもサポートします。

APの動作モード

arubaではコントローラとAP間で2つのトンネルを構築します。

GREトンネル：データ(実際のトラフィック)送受信用
PAPI：コントロール(制御情報)送受信用、PAPIはaruba独自の技術

動作モードによって上記のトンネルの暗号化有無が異なります。

・CAP
双方のトンネルは暗号化されないため、インターネットを介さない企業内のAPで使用します。

・CPsec AP
CAPのControle Plane(PAPI)のみIPsecで暗号化します。
CPsecを有効にするとコントローラに登録されたAPのみが接続可能となり、コントローラへの不正なAPの接続を防ぐこともできます。

・RAP
GRE/PAPIの双方をIPsecで暗号化します。インターネットを介したコントローラとAP間がセキュアではない環境下等で使用します。
コントローラへの登録時の認証に証明書を利用するCert-based RAPと、PSKを利用するPSK RAPがあります。

・Mesh AP
AP間をWiFiにてメッシュ接続したAPを指します。

Clusterの構成は以下の2つに分類されます。

・L2-Connected

Cluster内のMDが同一のクライアントVLANを保持しています。
また異なるVLANを設定しているMDがいる場合は、そのVLANを除外することでL2-Connectedにすることが可能です。

L2-Connected構成ではClient State Synchronizationを有効化することで、MDの障害時にクライアントがActive-UACからStandby-UACへの断時間なしでの迂回(Hitless Failover)が可能となります。

Cluster構成でのClient State Synchronizationでは、Active-UACとStandby-UACでユーザの状態、キーキャッシュ、PMKキャッシュ等を共有し、重要と判断されたユーザーセッションも同期します。

L2-Connected構成であればde-authを発生させず、Hitless Failoverが可能となっています。

・L3-Connected

Cluster内のMDが異なるクライアントVLANを保持しています。

Client State Synchronizationが機能せず、Failover時にクライアントはde-authを受け取るためHitless Failoverとなりません。

Clusterの機能を最大限に生かすにはL2-Connectedである必要があります。

図1.2.1 Cluster

1.2.2 VRRP

VRRPを利用した冗長化の場合、冗長するMDはL2接続されている必要があります。

VRRPではActive-StandbyとActive-Active、N:1の3つの構成が可能となり、N:1構成で3台以上の冗長をとることが可能です。

Active-Active、N:1の構成では複数のVRRPグループを設定することで、AP毎にActiveのMDを指定することが可能となります。

VRRPではCAP、CPsec AP、RAP、Mesh APの全てサポートとなります。

図1.2.2 VRRP

1.2.3 HA

HAではAPはActive/Standby両方のMDに対してGREトンネルをセットアップし、MDとAP間でGREのハートビートを行います。
またオプションでMD間でのハートビートを行うことが可能で、有効にすることでAPのFailoverは1秒未満に短縮できます。(無効の場合は約8秒)

クライアントのFailoverにはClusterの際にご説明したClient State Synchronizationが利用可能となります。

HAのClient State Synchronizationは802.1Xユーザのみが対象となり、キーキャッシュ、PMKキャッシュをActive/StandbyのMD間で同期します。
Cluster構成とは異なりユーザセッションは同期されず、Failover時にはde-authが発生するためHitless Failoverとはなりません。

HAではMDの管理IPは同一セグメントである必要が無いためサイト間での冗長も可能となります。

サイト間冗長の場合は障害時の切り替わりでクライアントIPが変更となる可能性があるため、Client State Synchronizationを利用する場合にはMD間の接続はL2が推奨となります。

AP毎にActive/StandbyとなるMDの指定が可能となるため、MDを3台以上冗長可能で、Active-Active/Active-Standby/N:1の冗長構成が可能です。
N:1構成ではオーバーサブスクリプション機能を利用することでStandbyのMDはハードウェアの制限を超えたStandby GREトンネルを終端することが可能となりますが、Client State Synchronizationが未サポートとなります。

HAはCAP/CPsec APをサポートしますが、RAP、Mesh APは非サポートとなります。

またCPsec APかつトラフィックがコントローラを経由しないBridgeモードを利用する場合には、HAをサポートするMDの機種は7200シリーズのみとなります。

図1.2.3 HA

1.2.4 Backup LMS

APはPrimaryとなるMD(LMS：Local Mobility Switch)を指定し、SecondaryのMDをBackup LMSとして指定することでPrimaryの障害時にSecondaryにFailoverします。

APはLMSで指定したMDとGREトンネルをセットアップし、MD-AP間でハートビートを行います。

APがPrimaryのMDの障害を検知すると、Backup LMSで指定したSecondaryのMDから無線設定をダウンロードし、その後GREトンネルをセットアップします。

そのためAPのFailoverの時間はHAと比べて長くなります。

またクライアントはde-authを受け取ります。

HA同様にActive-Active/Active-Standby/N:1の冗長構成が可能で、MDが同一セグメントである必要が無いためサイト間冗長が可能です。

Backup LMSではCAP、CPsec AP、RAP、Mesh APの全てサポートとなります。

図1.2.4 Backup LMS

2.Stabdalone

Standaloneの構成では各コントローラが独立して動作するため、個別に設定/管理を行う必要があります。

AOS6のAll Masterと同等の構成となります。

2.1 Standaloneコントローラの冗長化

Standaloneコントローラの冗長化に関しては「1.2 MDの冗長」とほぼ同じ冗長構成となります。

Cluster構成に関してはMM-MD構成でのみ動作可能なため、それ以外のVRRP、HA、Backup LMSの3つの方式で冗長が可能です。
またAOS6のMaster Redundancyと同等機能の利用も可能となります。

2.1.1 Master Redundancy

Active-Standby Standaloneと呼ばれることもあります。

Standalone構成の場合、各コントローラは個別に設定/管理を行う必要があると記載しましたが、Master Redundancyの機能を利用することで2台のStandaloneコントローラをActive-Standby構成で一元管理することが可能です。

Master RedundancyではVRRPが必須となり、Standby側のStandaloneコントローラにはAPは接続できません。

Master Redundancyでは後述のBackup LMSとの併用が可能となりますが、HAとの併用はサポートされません。

図2.1.1 Master Redundancy

2.1.2 VRRP

詳細については「1.2.2 VRRP」を参照してください。

Active-Active/Active-Standby/N:1で冗長可能となりますが、Active-Standby構成の場合は前述のMaster Redundancyを利用することが一般的となります。

2.1.3 HA

詳細については「1.2.3 HA」を参照ください。

2.1.4 Backup LMS

詳細については「1.2.4 Backup LMS」を参照ください。

まとめ.

大分長くなってしまいましたが各構成と冗長化方式を一覧で表にまとめます。

図3. まとめ

最後に冗長化方式毎の利用シチュエーションをご紹介します。

・Cluster

MM-MD構成の場合はHitless Failoverが可能なClusterによる冗長が推奨です。

・HA

MCM-MD構成、Master Redundancyを利用しないStandalone構成でAPがCAPの場合はHAが推奨です。

・VRRP

Master Redundancyを利用したStandalone構成でAPがCAPの場合、またコントローラ間がL2接続でAPがRAPの場合はVRRPが推奨です。

・Backup LMS

上記以外でコントローラ間をL3で接続する場合はBackup LMSが推奨です。

今回は以上で終了となります。
最後までお読みいただきありがとうございます。