NOPエンジニア blog

統合データ保護基盤 Druva inSync/Phoenixについてご紹介

こんにちは!
Druvaの製品担当、川口です。
今回はクラウド型(SaaS)統合データ保護(バックアップ)基盤であるDurva inSync/Phoenixのご紹介をしたいと思います。

バックアップとは、そして重要性

このブログを読んでいる皆さんにバックアップとは?いう説明は今更かと思いますが、簡単におさらいさせていただきます。
コンピュータ上に保存されているデータは、内蔵された何らかのメディア上に保存されます。現状ではSSDもしくはHDDのどちらかになるかと思います。HDDよりは壊れにくいとはいえ、SSDも最後は必ず壊れますし、これがたとえばクラウド上に保存され、ハードウェア的な保護がクラウド事業者によって担保されていたとしても、人為的もしくは偶発的な事故によってデータが消去される可能性は残ります。データは必ず消失する、という前提に立つ場合、別の場所にコピーを取得しておき、データが失われた際にはそこから戻す(リストアする)必要があります。これがバックアップ(&リストア)です。
以前はコンピュータに直接接続されたテープメディアに取得することが多かったのですが、近年はバックアップ用のソフトウェアがインストールされた統合バックアップサーバに接続されたハードディスク上に取得される場合がほとんどかと思います。

 

エンドポイントバックアップ

サーバのバックアップは慎重に検討され、必要十分なバックアップがとられるものですが(もちろん例外も・・・)、エンドポイント~ここでは従業員に支給された個人用の端末のことを想定しますが~についてはそれぞれの使用者の判断に任されることが多いかと思います。VDIなど情報システム部門ですべて管理している場合は別として、現実的には個々のエンドポイントデバイスについてはバックアップを取得せず、必要なデータはファイルサーバ上に置く運用が主流になっています。
しかし往々にしてそれぞれのエンドポイントにもファイルは置かれ、バックアップされていないエンドポイントの機器が万が一破損し、データが回収不可能となった場合、当然それまで作業していた成果物は永遠に失われます。使ってる当人は普段気にしてないですが、いざ壊れるとかなりショックです・・・。

 

Druvaって何?

USに本社のある会社です。言葉の意味としてはサンスクリット、ヒンドゥー語で北極星ということになります。常にそこにあり、継続的で信頼でき、確固たる地位を持ってお客様のデータを守り続けるという意味が込められています。


Druvaは2008年にヴェリタスソフトウェア(当時はシマンテックでしたが)のエンジニアが中心となってインドで創業されました。
オンプレミスのエンドポイント向けバックアップソリューションから始まり、2010年には追加の出資を受けて本社をシリコンバレーに移し、2012年にはAWSインフラを使ったクラウド型のエンドポイントバックアップソリューションをリリースしました。
2015年に日本法人を設立し、販売を開始しています。

#よく聞かれるのがDruvaってどう読むの?ということなんですが・・・
⇒答え、我々は”ドルーバ”って呼んでますが日本法人の方曰く、好きに読んでください、とのことでした。

 

Druvaを使うと何ができるのか

Druvaを一言で説明した場合、クラウド型、統合型データ保護基盤ということになります。
エンドポイント(デスクトップ・ノートパソコンからスマートフォン、タブレットなど)からクラウドアプリケーション(Office356やBOXなど)、サーバー(物理サーバ、仮想サーバ)までを、inSyncとPhoenixの二つのラインナップで統合的に保護(バックアップ)します。


また保護するだけではなく、発見検知検索といった機能でデータを有効活用することも可能です。
この2種のソフトウェア/サービスについては次回以降詳細に説明させていただきます。

 

Druvaの特徴

ここではDruvaの特徴をお話しいたします。

 


まず一つ目、クラウドネイティブで集中型ということがあります。
Druvaの基盤はクラウド上にありますので、オンプレのバックアップ基盤で必要になる初期のサイジングは不要です。また高い拡張性も同時に兼ね備えています。
さまざまな拠点のデータを保護可能ですが、これは世界中のどこでもというレベルです(当然ネットリーチャブルである必要はあります)。
またバックアップはクラウドで集中管理できますし、これはオンプレで基盤を作ってる場合よくありますが、定期的バージョンアップは不要です。サポートが切れるのでバージョンアップしてくださいと言われて実施するのですが、コンパチ確認やライセンスの移行などがあったりしてそこそこの工数が掛かったりします。

 

次に効率的で高い費用対効果を持つということが挙げられます。
クラウド基盤上のグローバル重複排除を行うことにより、データを圧縮します。そもそもエンドポイント・サーバからの転送データを最小限に抑えることができバックアップ自体も高速に行えます。
(重複排除されたハッシュ値などのデータはAWSのDB上に格納されています)
inSyncはユーザ単位でのライセンスですので(もちろん容量制限はありますが)重複排除が直接コストに跳ね返るわけではないのですが、サーバ向けのPhoenixは重複排除後のデータ量に課金されますので、特に同じデータを複数拠点に持っているといったお客様でしたら有効に活用できるかと思います。

 

さらに各種の規格に準拠し、セキュアであることが挙げられます。
基盤自体はAWSもしくはAzure上に構築されていますのでそもそもその基盤上の各種規格に準拠します。
そして配置されたデータは暗号化されており、バックアップデータは顧客企業にのみアクセス可能です。
(Druvaは使用量しかわかりません)
また管理ユーザはロールベースで管理されます、当然転送されるデータも暗号化されています。

 

最後にバックアップ以外の利活用があります。
これはクラウド上にバックアップしてますので当然なのですが、オンプレでのバックアップと違い、データの遠隔地保管が必要ありません。
(広域災害を想定する場合はリージョンを考慮する必要がありますが)
また強力な検索機能やガバナンス機能も持ちますのでそういった用途に使用することも可能です。

 

今回はDruva製品の概略を説明させていただきましたが、いかがでしたでしょうか?

次回からDruva inSyncとPhoenixの具体的な機能や適用例をご紹介したいと思います。

 

 

【Merakiトラブルシュート】Wireless Health!!!

 

 

Meraki大好きな皆さん、お久しぶりです。

マッチョ近藤です!

4月半ばから食事制限を行い9kgの減量に成功し、肩メロン(※メロンが詰まっているかのような巨大な肩)も好調に構築が進んでいます。まだまだ頑張ります!

同じく売り上げ絶好調のMerakiシリーズですが、いくつか新しい機能が追加されましたのでご紹介します!

■Wireless Health

MRシリーズ(アクセスポイント)に

無線通信のトラブルシューティングツール「Wireless Health」が追加されました。

Wireless HealthはMR24.12以上で追加された新機能です。

 

 

無線通信において通信が確立するまでに様々なプロセスがありますが、Wi-Fiに繋いだ時にどこかで問題が発生した場合、下のようなマークだけが表示されてしまいます。

 

 

 

これだと障害ポイントが解らず、どこに不具合が発生しているのか特定するのに時間が掛かってしまいます。

そこで!Wireless Healthの出番です!!!

このWireless Healthによって無線通信の障害ポイントを明確に確認することができます!

それでは実際の画面を見ていきましょう!

※環境は私の家(近藤ジム)のデータとなります

この「無線状況診断」がWireless healthになります。

※現在ではBETA版となっております。

ここでは過去1週間の「接続失敗割合」と「接続されているワイヤレスクライアントの平均無線遅延」を表示しています。我が家のネットワーク(近藤ジム)は快適な無線LAN環境の様です。

また、AP毎、クライアント毎でも確認が可能です。

・AP別の場合

APマークにマウスを当てると詳細が表示されます。

AP(KondoGYM_MR18)では、接続している2クライアント中1台に不具合があり50%、平均無線遅延が18ms、と表示されています。不具合の割合が50%未満だとAPマークが緑色、50~75%だと黄色、76%~だと赤色で表示されます。

・クライアント別の場合

クライアントデバイスのOS別に不具合割合を確認することも可能です。

Windows 10であったり、Android, iPhone, Mac OS, などデバイスタイプ別で確認することが可能です。

接続クライアント毎にも確認することができます。

 

 

上図をみるとクライアント(DESKTOP-NOSK5TN)では11回無線通信において不具合が起きていることが解ります。

不具合の詳細を見るために”11 connections”をクリックすると……

 

 

クライアント(DESKTOP-NOSK5TN)がどの「AP」の、どの「SSID」における、どの「プロセス」で、不具合の「原因」を確認できます。

上図だとWPA-PSK認証にて失敗があるとわかります!

ただ、ここまでだと文字ばかりでMerakiらしさが無いですよね。。。

安心してください。可視化できますよ!

■不具合発生ステップグラフ

「もっと迅速に原因が知りたい」という方、

この「不具合発生ステップグラフ」で1発です!

 

 

 

 

このグラフは無線通信の各プロセスにおける失敗率を可視化しています。

各ステップの失敗原因は以下になります。

・Association(アソシエート)

1台のAPに接続するクライアント数が多すぎる場合、APとクライアントの機能が一致しない場合、4WAYハンドシェイクでタイムアウトした場合など

・Authentication(認証)

無効なユーザ名/パスワード、不正な事前共有鍵、期限切れのクライアント証明書などの理由で失敗した場合

・DHCP

クライアントがIPアドレスを要求しDHCPサーバから15秒以内に応答がないか、DHCPサーバが応答し使用可能なアドレスが受け取れない場合

・DNS

最初のDNS要求を正常に解決されない場合、DNS応答に15秒以上かかる場合

・Success(トラフィック転送)

アソシエート、認証、DHCP、DNSが完了したクライアントでワイヤレスネットワーク上のトラフィックの転送に失敗した場合

これを見ると私の家では認証で問題が起きているとわかりますね!

(障害数が少ないので、見ても面白くないですね、、)

弊社にて各プロセスで問題を生じさせ、Wireless Healthにて確認しました!

Authenticationにて失敗率が46.2%となり、グラフ内で一番反応があります。

このグラフを見れば、認証部分で何かしら問題があると判断することができます!

DHCPにて失敗率が62.9%で、このグラフを見ると明確にDHCPのプロセスで問題があると一目でわかります。

DNSにて失敗率が58.3%で、こちらも一目でDNSのプロセスで問題があるとわかります!

この不具合発生ステップグラフを見て、一目でこの無線ネットワークで起きている問題の切り分けが可能になります。今回はネットワーク全体で表示していましたが、AP別、SSID別で表示させることも可能です。

■無線遅延状況の可視化

Wireless Health では無線遅延状況を可視化することも可能です。

4つのトラフィックタイプ(音声トラフィック、ビデオトラフィック、ベストエフォートトラフィック、バックグラウンドトラフィック)のカテゴリに自動的に分けられ、円グラフにて遅延状況が表示されます。

DSCPの値を基にトラフィックを分類し、それぞれの遅延状況を分析しています。

我が家の環境が良すぎて緑一色ですが、遅延状況が悪くなると、赤色が増えたりします。

・Wireless Healthを使用した感想は

無線LANで起きている不具合状況の傾向分析を行うことができ、一目で原因がわかりやすい為、トラブルシュートに掛る時間を大幅に短縮できます。

今までですと、事象を再現させてパケットをキャプチャーして、分析しないと原因を追究出来なかったところですが、Wireless Health 機能を使えば、この辺の手間が非常に簡素化されます。

特に追加ライセンスも不要ですので、是非ご活用下さい!

この様なトラブルシューティング機能が新たに追加されたり、精度が向上することで、もうトラブルシュートはめんどくさい作業ではなくなるかもしれませんね!

今後の

Merakiトラブルシュートに期待です!!!

以上、最後まで読んで頂きありがとうございます。

次回、お楽しみに!!

お問い合わせはこちらまで。

Mist APの位置情報精度

Mist APの位置情報精度

こんばんは。わたくし、Mist Systems 社の製品担当をしております長畑と申します。

先般、Mist Systems 社製アクセスポイントを利用した位置情報精度の検証を実施致しましたので、ここにご紹介致します。

 

  • Mist APのBLE

既にご存知の方もいらっしゃるかもしれませんが、Mist System社(以下、Mist)の製品は無線LANコントローラをクラウドの上に配置した『クラウド型無線LAN管理システム』です。

物理的な機器として我々が手に取れるのはアクセスポイント(以下、AP)のみで、設定・運用・管理は全てクラウド上のダシュボードにアクセスして行います。

BLEは殆どのスマートデバイス等(以下、デバイス)で標準搭載となっています(主にiPhone,iPad,Android)。多くのモバイル機器では気軽にBLEの利用が可能ですが、では、モバイル機器からのBLEビーコンを送受信するファシリティ側の準備はどうでしょうか。

BLEを利用するにあたり、大量のBLE物理ビーコンを展開し、管理する必要があります。また、物理ビーコンは電波出力の調整が困難なために、電波環境が変更になると再設置が必要ですし、物理ビーコン内のバッテリーは交換するのに手間と費用がかかります。併せて、ビーコン自体は小さいので紛失、または盗難される可能が危惧されます。

Mist APのBLE を利用すれば電波出力、電源、盗難及び紛失の懸念が払拭されます。更にAPはクラウド上で一元管理出来ますので、運用負荷も軽減されます。

MistのAPにはWi-Fiの機能のみならず、BLE(Bluetooth Low Energy/Bluetooth LE)用として、8本のBLEビーコン送信用と8本のBLEビーコン受信用の計16本のアンテナを搭載していますので、BLEビーコンの送信及び受信することが出来ます。このBLEのビーコンを利用して、位置情報の推測が出来るようになり、高精度の屋内ロケーションサービスとしてサービスを提供することが可能となります。

 

  • 位置の推測

無線送信出力とRSSI(受信強度)が分かると数式から距離を算出することが出来ます(ここでは数式についての説明は省きます)。この算出された距離を半径とし、円を描けば、三つの円の交点の位置に存在することが推測出来ます。これが三点測位になります。

 

Mistの位置情報の推測も三点測位を基本とします。但し、精度向上のために8本のBLE送信用アンテナからのRSSIとAIを利用します。

アプリをインストールされたデバイスは『どのAPの何番のBLEアンテナからRSSIは○○dBm』であるという情報と、APとそのAPの各BLEアンテナからのビーコンのRSSIをMist クラウドに報告します(報告はMist APのWi-Fi経由である必要ありません)。

MistクラウドでこれらのRSSI情報とスマートフォン固有の特性を考慮し、端末の位置を推測し、ダッシュボードのMAP上にX,Y座標として表示します。

併せて、AIを利用しマシンラーニングさせことでより精度の向上を図っています。

マシンラーニングによって精度を向上させるためには、より多くの情報が必要となります。つまり、BLEアンテナからの情報は沢山あるほど、また広範囲であればあるほど、マシンラーニングに有益な情報を取得出来、その結果のRSSI情報をMAPにプロット出来るので正確性が上がり、強いては位置情報の精度向上に繋がります。

 

  • BLEビーコンによる資産管理

APからのBLEビーコンを受信し、Mistクラウドに報告出来るアプリをインストールしたデバイスの事をMistでは、Appクライアント(App Client)と呼びます。

Appクライアントとは逆に、APで受信出来るBLEビーコンを送信しているデバイス(物理ビーコン)をMistではBLEクライアントと呼び、その中で管理用に登録されたデバイスをアセット(若しくはBLE Asset)と呼びます。(記事内ではBLEアセットと記述します。)

位置の推測方法やクラウドのダッシュボード上の表現は同じですが、BLEアセット自体は単なる物理ビーコンなので、Mistクラウドへの報告は出来ません。RSSI情報はビーコンを受信したAPがMistクラウドに報告します。

BLEアセットはその名通り『資産』にあたり、用途は移動出来てしまうホワイトボードや、病院で使用する医療用ワゴン等に取り付けて、位置情報からその『資産』が現在はどこにあるのかを明確することに利用出来ます。

 

  • BLEを利用する為のベストプラクティス

BLEで位置情報を求める場合、通常のWi-Fi APの設置基準では高精度の位置情報が得られません。次にBLEを利用する為のAP設置に関わるベストプラクティス記載します。

・指向性のBLE ビーコンは下方45度の方向に送信しているので、AP は天井から真下向き設置。

・設置高は床面から215㎝~455㎝(7~15フィート)。

・AP間の距離は8m~15m程度。

・廊下、通路の設置に関しては、AP 間の距離を最大17m程度離すことが可能。

・金属物体が多くあるような場所では反射波などの影響で位置精度が下がるため、金属物体からAPを2~3m以上離して設置。

・位置情報の精度を上げるために、APは3台以上が推奨。

・クライアント端末から複数APへの見通しを確保すると精度が向上。

・AP 間の見通しではなく、クライアントからの見通しが重要なので、廊下・通路等ではクライアントからAP2台 以上の見通しが確保できることがベスト。

・フロアマップは必ずスケール(縮尺)を調整する。

・フロアマップは上が真北になるよう設定する。

・フロアマップにAPをプロットする際は、APの 設置高、オリエンテーション(APのLEDの向き)を正確に設定する。

正しく設置した場合の、位置精度は1~3m程度になります。

 

  • 検証方法と結果

検証方法

検証には三角形を構成出来るように執務室内にAPを3台設置。クラウドダッシュボード上ではWi-Fiクライアントも表示されるので、Wi-Fiクライアントの位置情報も確認。

AppクライアントとWi-FiクライアントはiPadを使用し、Appクライアントにする為にMistが提供しているSDKをインストール。BLEアセットは物理ビーコンを使用。

APの三角形内(三点測位内)に7か所の測定ポイントと三角形外に6か所の測定ポイントの計13か所で設定。各ポイントに到着後、2分程停止し、その測定ポイントとダッシュボード上での表示にどれほどの誤差が発生しているかを測定。測定回数は3回実施。

観点

三角形内及び全体で1m内、3m内、5m内にそれぞれ、どの程度の割合で収まっているのかを結果として確認。

 

試験結果

  • 考察

・全体(三角形内+三角形外)と三角形内(三点測位内)では、どのデバイスにおいても三角形内(三点測位内)の方が位置情報精度は高くなっています。

・Appクライアントは、三角形内(三点測位内)において3回の測定結果の平均でも3m以内の確立は95%であり、高精度の位置情報推測が出来ています。

・BLEアセットにおいて、三角形内(三点測位内)で3m以内の結果が然程、良好な結果を得られなかった要因としては、床や天井からの反射・吸収・回折や干渉波の影響を大きく受け易く、その為にゆらぎが発生していることと、ダッシュボードのデータ更新が30秒間隔であり、測定作業におけるポイント確定時のタイミングにより、誤差が発生していると推測されます。

・一般的にWi-Fiクライアントの位置精度は5~10m以内と言われていますが、本検証に於いては三角形内(三点測位内)で5m以内の結果が86%と、比較的良好な結果が出ています。

ただこれは、Wi-Fiクライアント測定時に移動先測定ポイントにて、クライアント側のWi-FiをOff-Onすることで隣接のAPへ接続するようにしていることと、ダッシュボード上では比較的、Wi-Fiクライアン トはAPの近隣に表示される特性の為です。

Mistからも『Wi-Fiの位置情報にはフォーカスしていない』、『現時点ではWi-Fiの位置情報は正確ではない』とコメントがありますので、Wi-Fiクライアントの位置情報は現時点ではあまり期待できない精度となります。

 

  • あとがき

今回はBLEビーコンを利用した位置情報についての記載内容でしたが、先述のとおり、Mist APはWi-Fi機能も実装しています。Mistのみが搭載するWi-Fi機能として『Dynamic Packet Capture(自動パケットキャプチャ)機能』、『Wi-Fi Service level monitoring(Wi-Fiサービスレベルモニタリング』、『Root Cause Analysis(根本原因分析)』があり、ユーザ視点からの新しいWi-Fiの運用、管理、サービスを実現できます。

では、皆様。次回にお会いするまで、ごきげんよう。

新生HyperFlexバージョン3.0の特徴!~もうルーキーとは呼ばせない~

 

 

皆さんこんにちは。

NOP HyperFlex担当SEの深沢です。

 

ついこの間までルーキーと呼ばれていたHyperFlexも早くも3年目。

HCI界ではそろそろ中堅どころになってきたのではないでしょうか。

 

そんなHyperFlexですが、2018年4月に大型アップデートがあり「HyperFlex version 3.0」として大きく生まれ変わりました。

具体的にどのような所が強化されたのでしょうか?

 

そもそもHyperFlexとは何ぞや?と言う方は以下記事を先に見て頂ければと思います。

HCI界の超大型ルーキー”Cisco HyperFlex”

 

新生!HyperFlex 3.0

HyperFlexはversion 3.0へのアップデートにより、以下の部分が強化されました。

 

・ハイパーバイザ―としてMicrosoft Hyper-Vへの対応

・スケーラビリティの拡張

・Logical Availability Zones(LAZ)機能の追加

・ストレッチドクラスタ機能の追加

・LFF(3.5インチディスク)搭載モデルの追加

・Intel Optane(3D XPoint) NVMeキャッシュへの対応

 

なかなか盛り沢山なアップデート内容となっていますが、今回は上記の中から3つをトピックスとして紹介させて頂きたいと思います。

 

スケーラビリティの拡張

今まで、2.6までのハイパーフレックスではAll Flashモデルで32ノード、Hybridモデルでは16ノードまでしか拡張できませんでした。

拡張性が強みのHCIですが、最大16ノードではとても大規模向けの展開には耐えられるものではなかったかと思います。

しかし、今回スケーラビリティの部分が大きく改善されました。

All Flash / Hybrid関わらず、最大64ノードまでの拡張が可能になりました。

圧巻ですね。本気出してます。

 

一つ注意点としては、64ノードの内、32ノードはハイパーコンバージドノード、残りの32ノードがコンピュートノードという所になります。

コンピュートノードというと通常のUCSの事ですね。

つまり、ストレージリソースを含むHCIノード部分が32ノード、UCSが32ノードまで拡張可能で、それらを同一クラスタとして構成した場合に64ノードまで構成できるという事になります。

HCIノードだけで32ノード以上を構成する事は現状不可という所に注意です。

 

現在HX240cというモデルでは、1ノード当たりキャパシティディスクを最大28TB程度積むことができます。

単純計算で32ノードで896TBです。

これだけの容量に加え、勿論SSDを使用した重複排除、圧縮も効いてきます。

あくまで理論値ではありますが、以前と比較すると圧倒的に大規模な環境にも対応できるようになりました。

 

ちなみに実際のサイジングの際にはレプリケーションファクターなどの要素により、実際に使えるディスクの容量は変わってくるので注意が必要です!

 

Logical Availability Zones(LAZ)機能の追加

LAZという機能をご存知でしょうか?

LAZという機能、一言で言うと「今まで以上に可用性が向上する」というものになります。

難しい話はめんどくさい!と言う方は、これだけ理解して頂ければOKです。

 

HyperFlexは常にデータを異なるノードに対して3重書きする事により、データの保全性を保っています。

同一のデータが必ずどこかのノードに存在している為、1台や2台ノードが壊れてもデータの完全性は保たれます。

基本的に最大2ノードまでの同時障害に耐える事ができます。

 

しかし、クラスタを構成できるノード数が増えるにつれて、ノード障害が起きる確率は相対的に上がっていきます。

5ノード中3ノードが同時に壊れる確率と、64ノード中3ノードが同時に壊れる確率は違うわけです。

勿論3ノードが一度に壊れる確率は非常に低いですが、絶対起きないとは言えません。

ここで、LAZを使用する事によって、更に可用性を上げる事が可能です。

LAZ(Logical Availability Zones)では、クラスタの中のノードをグループしてゾーンとし、そのゾーン間でデータの3重書きを行うというものになります。

レプリケーションデータを配置するノードを論理的にグループ化しているという事ですね。

こうする事によって、ゾーン間にまたがった3重同時障害が起きるまでは、データの完全性が保たれます。

同一ゾーンであればたとえ何ノード壊れても問題ありません。

 

上手くゾーンを配置し、物理的にラックを分ければ、特定のラックの電源が落ちてしまった!なんて時も大丈夫です。

まさに大規模な環境にぴったりの機能と言えます。

因みに現段階ではVM版のみの機能となります。

 

ストレッチドクラスタ機能の追加

ストレッチドクラスタとは、「物理的に離れた距離でのクラスタ構成」となります。

つまり、異なるデータセンター間などの環境であっても、その間で同一のHyperFlexクラスタを構成する事が可能になりました。

これにより「HyperFlex間でのレプリケーション」のような動きをさせる事が可能になりました。

HyperFlexでは普段からデータをコピーして別ノードに書きこむという動きをしているので、レプリケーション先を遠隔地にできればそのままDR対策を実現することも可能です。

ある程度の帯域、低遅延環境が必要などの制限もあるので現状では遠いサイト間のレプリケーションはまだ難しそうですが、今後の拡張に期待できる機能の一つです。

現段階ではこちらもVM版(要Enterprise Software License)となります。

 

まとめ

今回の3.0アップデートでは「より大規模に」「より柔軟に」なるような拡張が特徴として挙げられます。

ここまでHyperFlexにしかないコンセプト、特徴、勢いで攻めてきたHyperFlexが段々と手を広げ、多くのニーズに対応してきた印象です。

 

2018年中にはまた新しく「HyperFlex 3.5」がリリースされる予定となっています。

アップデートのペースも早く、次回の拡張にも期待十分ですね。

今後もHCI界を牽引するHyperFlexから目が離せません!

【図解でわかる】MerakiのAuto channel 機能 ★おまけ:【動画でわかる】Meraki+API連携ソリューション

kabu_chart_man_cry

Merakiファンの皆さま、お疲れ様です。

先月、仮想通貨で40万溶かした木村です。(花の12月組です※17年度)
コインチェックでNEMホルダーです。今年は当たり年かも知れません。

そんな仮想通貨とは対照的に売り上げ絶好調のMerakiですが、今回はMRシリーズ(無線アクセスポイント)の自動チャネル動作について調査してみました。

最後にAPI連携ソリューションについても紹介します。

 

自動チャネル変更機能

エンタープライズ向けの無線アクセスポイントについては、ほとんどのケースで自動チャネル変更機能が実装されております。電波干渉が起こりやすい無線LAN環境で、快適なチャネルに自動変更させることで電波干渉を解消してくれる大変有り難い機能です。

もちろんMeraki MRシリーズにも実装されています。

しかしながら、どのタイミングでチャネルが変更されるかの仕様についてはメーカーによってまちまちです。

詳細な動作仕様を公開しているメーカーは少なく、製品によっては最初の起動したタイミングだけしか自動チャネルが動作しないケースもあります。

その辺Merakiはどうなっているのでしょうか。

 

 

Meraki MRシリーズの自動チャネル変更機能

メーカードキュメントを確認してみますと、以下のタイミングで自動チャネルが行われる様です。

自動チャネル変更機能

Auto Channel
https://documentation.meraki.com/MR/Radio_Settings/Auto_Channel

(以前メーカードキュメントに記載されていた内容と変わっています。なので、今後もしれっと変更があるかも知れません。)

なお、Merakiはクラウド管理型のためインターネット断などによってクラウドとの通信が断たれてしまいますと自動チャネルは動作しません。

 

上記 ①(新しいAPが追加されたとき(起動時)) と ③(手動でチャネルを更新したとき) については比較的どのメーカーの無線アクセスポイントにも実装されているかと思います。

④(非802.11のチャネル利用率が65%(分)超過したとき) については、電子レンジなどの非802.11となる無線電波のチャネル利用率が65%以上一分間続いていた場合に、強制的にチャネルを変更します。その時にユーザーが通信を行っていたとしても強制的にチャネルが変更されます。

この実装は3rdラジオが実装されている(有効になっている)タイプのアクセスポイントについてのみ有効で、3rdラジオが実装されていないタイプのアクセスポイントにはこの仕様がありません。

②(定期診断(15分)で、より良いチャネルがあったとき)については15分間隔で無線電波環境を診断し、より良いチャネルがあったと時にチャネルを自動的に変更します。但しその時にユーザーが通信を行っていた場合はチャネル変更は行われません。

このケースについてはどのタイミングでチャネル変更が実行されるのか明記されていません。本当にちゃんと動作するのでしょうか?ということで、検証を行ってみました。

 

 

アクティブユーザーが居ない時の検証環境と結果

以下図の様に同じチャネルを有している他のアクセスポイント上でトラフィックを継続して流しチャネル利用率を上昇させます。チャネル利用率が”High” になるように負荷をかけます。

その間、Meraki MR 側のアクセスポイントはアクティブなトラフィックは流さないようにします。

この状態で15分後にMeraki MR 側のアクセスポイントのチャネルが自動的に変更されていることを確認してみます。

live4

Merakiダッシュボード上からチャネル利用率のライブデータを見てみます。

live1

Meraki MRには1台もつながっていないのにチャネル利用率が62%まで跳ね上がりました!!

 

この状態のまま15分待ちます・・・・・。

 

するとだいたい約10分くらいでチャネルが自動的に変更されました!

live2

イベントログ上では「Channel changed to improve network performance」のログが出力されることを確認しています。

 

 

アクティブユーザーが居る時の検証環境と結果

今度は以下図の様に同じチャネルを有している他のアクセスポイントとの間でトラフィックを継続して流しチャネル利用率を上昇させます。チャネル利用率が”High” になるように負荷をかけます。

この状態で15分後にMeraki MR 側のアクセスポイントのチャネルが自動的に変更されるかどうかを確認してみます。

live3

Merakiダッシュボード上からチャネル利用率のライブデータを見てみます。

live5

イイ感じにチャネル利用率が69%まで跳ね上がりました!!

この状態のまま15分待ちます・・・・・。

huka

こちらは15分以上放置しておいてもチャネルは変わらず。トラフィックの送受信を行っているアクティブユーザーが居る場合は自動チャネル変更が行われませんでした。

 

上記の結果から、クラウド管理型の無線アクセスポイントであっても自動チャネルが正常に動作するということが確認出来ました。

ただしどれくらいの閾値でどれくらいの時間(平均値)を見ているか?というのは不明です。その辺はMerakiのポリシーによって最適な値が設定されているのでしょう。

 

 

 【おまけ】災害用Wi-Fiダッシュボタン! Meraki + API連携

Merakiには「Dashboard API」「Scanning API」「Captive Portal API」といった大きく3つのAPIが提供されています。

api

今回はその中からダッシュボードAPIを使ってWiFiダッシュボタンを作ってみました。大規模災害などの際にボタン1つでWi-Fiを無料開放するというものです。

Youtubeに動画をアップしておりますので是非ご参照下さい。

WiFiダッシュボタン

わざわざパソコンを起動して、ダッシュボードにログインして、SSIDを探して、設定を有効にして~みたいなオペレーション無しで、ボタン1つで簡単に行えます。

他にもいろいろなAPIが提供されていますのでご興味のある方は是非お試しください!