日本語フォーラム

 View Only
last person joined: 4 days ago 

HPE Aruba Networking のソリューション、ネットワークマーケットに関する日本語ディスカッションフォーラム
Back to discussions
Expand all | Collapse all

競合のソリューション比較について "無線ネットワークの本当に重要な機能"

This thread has been viewed 19 times

  • 1.  競合のソリューション比較について "無線ネットワークの本当に重要な機能"

    EMPLOYEE
    Posted Nov 21, 2023 07:01 PM

    幸いにもまだまだWi-Fi、ネットワークのニーズは高く、Aruba もその中で評価を頂いています。
    その結果、Juniper Mist 、Cisco Meraki 等との競合比較がいくつかのサイトで行われていますが、残念ながらその中には、7年以上前の古い情報を使っていたり、そもそも間違った情報が伝わってしまっているようです。
    さすがに Aruba の間違った情報が広まってしまうのは見過ごせないので、Aruba Centralに関しての部分は、最新の正しい情報を提供していきたいと思います。

    前回は「無線ネットワークの重要な機能」についてコメントしましたが、今回はその続きで
    Arubaから見た「無線ネットワークの本当に重要な機能」について書いてみようと思います。

    1. ローミングの機能
    ローミング、特に高速ローミング（Fast Roaming）に関しては、既に様々な標準規格が出てきています。まずはAPと端末の双方でそれらの規格に対応しているかが重要です。ローミングは基本的には端末主体で行われる動作なので、端末が規格に対応していないと期待通りのローミングが行われません。
    一般的なローミングに関する規格、機能

    ・802.11r
    ・802.11v
    ・802.11k
    ・OKC (標準規格では無いがWindowsで長く使われている)

    この「端末の対応」が重要なポイントです。Wi-FiはWi-Fi Allianceができて20数年、相互接続問題はほとんどなくなってきました。一方で、ローミングの規格は残念ながら出てきてまだ日が浅いため、端末によっては機能がONになっているせいで逆に問題が発生するケースもあるのが現状です。端末側で機能をON/OFFすることは現実的では無いため、AP側で設定変更をすることで、問題が発生した時にも速やかに対応することができます。

    Arubaはもちろん、上記全ての規格に対応していますし、更に機能のON/OFFを設定することができるようになっています。長年Wi-Fiに取り組んできたからこその機能だと思っています。
    ※AOS10から802.11vだけDefault Enableで無効化出来なくなっています。端末固有の問題が無くなってきたと判断できれば、徐々に全て有効で固定化されるかもしれません。
    2. スティッキー端末（Sticky Client）対策
    Wi-Fiの「遅い」、「接続が切れる」といった問題の多くが、このスティッキー端末問題に起因しています。
    スティッキー端末問題とは、”設計上” APがカバーしている範囲（=安定した接続、期待したスループットが出る範囲）と端末が接続できる範囲のミスマッチによって起こる問題です。
    端末がどのAPに接続するのかは、端末が主体となって決定しています。また、端末は基本的に「APは1台しか存在しない」と思っています。
    その結果、APから遠く離れて通信環境が悪くなっても、APとの接続を切ろうとせず、接続を維持しようとしてしまいます。
    オフィス環境であれば他にもっと接続環境が良いAPが存在しているのにも関わらずそちらに接続しません。
    この問題に対して、他のベンダーでは、端末側のWi-Fiインタフェースドライバーのアップデートなどで対処するように言っている場合もあります。
    もちろん、端末側のドライバーは最新にしておくのがベストですが、それ自体がスティッキー端末問題の解決策になるわけではありません。
    ArubaはClientMatchという機能でスティッキー端末問題に対応することができます。
    このClientMatchは特許技術で、ArubaのAPは、AP自身が接続端末だけでなく、接続可能な範囲にいる端末の情報を収集し、
    それらAPを集中管理しているコントローラ（Instant APの仮想コントローラやクラウドのAruba Centralも含む）が、全ての情報を持っているため、
    「この端末はAP-AよりAP-Bに接続した方が良い」ということが分かります。
    その結果、AP側から強制的に端末との接続を瞬断させて、AP-AからAP-Bへの接続を促すことができるようになります。

    3. 動的なAP間の負荷分散
    よくあるAP間の負荷分散機能は、端末がAPに接続する時だけの負荷を見て分散させています。つまり、端末が一度接続してしまった後に、端末の移動などで負荷が偏ってしまった場合に対処することができず、機能としては十分ではありません。
    ArubaのClientMatchはスティッキー対策で記述した通り、接続後の端末に対しても最適なAPへの接続を促すことができるので、接続後の動的なAP間の負荷分散を行うことが可能です。

    ClientMatchの機能は、リリースされてからもう10年以上経過し、長く利用していただいている機能です。
    リリース当初のレポートですが、こちらに実際の効果についてのレポートがあるのでご参照下さい。
    以下のグラフはレポートからの抜粋で、AP4台に50台の端末を接続した時、ClientMatch無しだと負荷分散ができていないため、一部の端末のパフォーマンス劣化が顕著になっている例です。




    ------------------------------
    Keita Shimono,
    Aruba Japan SE Manager & Airheads Leader
    ------------------------------