モデレーター
モデレーター

ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

VNXのALUAと、次世代VNXのActive/Activeに関するランボー博士とニアライン君の対話です。

ラベル(1)
1 件の受理された解決策

受理された解決策
モデレーター
モデレーター

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

ランボー博士:「今日はActive/ActiveによるLUNアクセスだ」

ニアライン君:「はい」

ランボー博士:「Active/Activeなアクセスとはどういうものか知っているか?」

ニアライン君:「知りません」

ランボー博士:「だろうな」

ニアライン君:「・・・・・」

ランボー博士:「簡単に言えばSP-AとSP-Bから同じLUNに対してアクセスが出来るということだ」

ニアライン君:「え!今までは出来なかったのですか?」

ランボー博士:「そうきたか。。」

ニアライン君:「え?」

ランボー博士:「もう少し気を利かせた質問、「ALUAで以前からSP-AとSP-Bの両方から同じLUNにアクセスが出来たのでは?」あたりが来ると思ったのだが、そこまで期待をした私がバカだったということだな」

ニアライン君:「あるあ?」

ランボー博士:「ALUAとは非対称Active/Activeとも呼ばれるもので、VNX(ストレージ)はSP-AとSP-Bの両方から同じLUNに対するアクセス要求を受けることが出来る」

ニアライン君:「両方のSPからアクセスできるから、非対称ながらもActive/Activeなのですね。とはいってもこの「非対称」っていう言葉は何故ついているのですか?」

ランボー博士:「非対称だからだ」

ニアライン君:「また乱暴な!」

ランボー博士:「乱暴でも何でもない。片方のSPに対するアクセスの方が多いから非対称。それ以上の説明があるか?」

ニアライン君:「いや、例えばどちらか片方のSPに対するパスはPreferred Path、もしくはOptimized Pathと呼ばれ、ホストからLUNへのアクセスは主にそれらのパスを用いて行われるために、アクセスIOの量がPreferred/Optimized Pathが設定されている方に片寄り、アクセスがSP-AとSP-Bで非対称となる。というような意味の非対称かと思っていました」

ランボー博士:「ニアライン、貴様・・・」

ニアライン君:「(にやり)」

ランボー博士:「まぁその説明でもいい。間違えではない」

ニアライン君:「ありがとうございます!」

ランボー博士:「VNXにおけるALUAでは、Preferred/Optimized PathはアクセスしようとしているLUNのデフォルトオーナーであるSPに対するパスが基本的には設定される」

ニアライン君:「何故でしょうか?」

ランボー博士:「それの方がLUNに対するアクセスの経路が短く効率的だからだ」

ニアライン君:「はぁ」

ランボー博士:「VNXの内部処理はまだActive/Passiveだからな」

ニアライン君:「Active/Passive?」

ランボー博士:「そう呼ぶとと恰好は良いが、乱暴に言えば片方のSPからしかバックエンドのLUNにはアクセスが出来ないということだ」

ニアライン君:「じゃあPreferred/Optimalで指定していない方のSPからはアクセスが出来ないってことになってしまうのでは?」

ランボー博士:「ならない」

ニアライン君:「え?何故ですか?」

ランボー博士:「CMIを利用するからだ」

ニアライン君:「なるほど!」

ランボー博士:「もしかして君は今日早く帰りたいと思っていないか?」

ニアライン君:「・・・」

ランボー博士:「CMIとは何か知っているのか?」

ニアライン君:「いえ。知りません」

ランボー博士:「たしか以前はCLARiiON Message Interfaceと呼ばれていたが、最近はある意味当て字でCommunication Manager Interfaceと呼ばれているもので、SP-AとSP-Bをつないで情報のやり取りを行うバスのことだ」

ニアライン君:「はぁ」

ランボー博士:「ちなみに人によって定義は異なるが、ストレージの3大コンポーネントは何か知っているか?」

ニアライン君:「知りません」

ランボー博士:「フロントエンド、キャッシュ、バックエンドだ」

ニアライン君:「フロントとバックでエンドが2つあるのはなんだかおかしくないですか?」

ランボー博士:「名前なのでそのまま憶えろ。何にしてもホストとのIOをやり取りするインタフェースとしてのフロントエンド。ディスクとのIOをやり取りするインタフェースとしてのバックエンド」

ニアライン君:「はぁ」

ランボー博士:「そしてフロントエンドとバックエンドの間に存在するキャッシュという3つのコンポーネントは頭に叩き込んでおけ。VNXではそれらの3大コンポーネントは全てStorage Processor(SP)の中に入っていて、絵にするとこんな感じだ」

storage_components.png

ニアライン君:「一番右にある3つですね」

ランボー博士:「そうだ。そしてVNXはActive/Passiveストレージアレイなので、"バックエンドから"一つのLUNに対しては片方のSPからしかアクセスは出来ない」

ニアライン君:「なんかそうやって強調して言われると"フロントエンドから"だったらアクセスできるみたいに聞こえちゃいますね」

ランボー博士:「そうだ」

ニアライン君:「は?」

ランボー博士:「フロントエンドからだったらアクセス可能だ。一つのLUNに対してどっちのSPからもアクセスできる」

ニアライン君:「え、でも結局はバックエンドからディスクへアクセスするんだから結果的に片方のSPからのみのアクセスになってしまうのではないでしょうか?」

ランボー博士:「そうだ」

ニアライン君:「え?」

ランボー博士:「フロントエンドとバックエンドをきちんと分けて考えろ!」

ニアライン君:「フロントエンドは一つのLUNに対して両SPからのアクセスがOK、ただしバックエンドは片方のSPからしかアクセスはできない。ですよね?」

ランボー博士:「その通り。だからバックエンドでLUNがつながっていない方のSPのフロントエンドからIOリクエストが届いた場合には、CMIを通じてLUNがつながっているSPへとルーティングされ、LUNへとアクセスしていくのだ」

ニアライン君:「でもそれって効率悪いですよね」

ランボー博士:「だからそう言っただろ?」

ニアライン君:「あれ?そうでしたっけ」

ランボー博士:「Preferred/Optimal Pathを利用したアクセスと、もう片方からアクセスがあった場合の処理イメージは以下のようになる」

ALUA-preferred non-preferred.png

ランボー博士:「見ての通りHostからはSP-A、SP-Bの両方にアクセスできるのでフロントエンドではActive/Activeに見えるが、バックエンドは100% Active/Passiveだ」

ニアライン君:「エセActive/Activeですね」

ランボー博士:「そういう大人げないネーミングはやめろ。非対称Active/Activeだ」

ニアライン君:「アンシンメトリック万歳ですね!」

ランボー博士:「しかしながら、次世代VNXでは非対称Active/Activeではなく、完全なActive/Activeがとうとう具備されて以下の図のようなアクセスが可能となったのだ」

active-active.png

ニアライン君:「おぉ」

ランボー博士:「これが次世代VNXにおけるActive/ActiveなLUNアクセスだ!以上!」

ニアライン君:「話はほとんど次世代VNXの話ではなくてVNXの話でしたね!」

ランボー博士:「お前のせいだ」

元の投稿で解決策を見る

0 件の賞賛
6件の返信6
モデレーター
モデレーター

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

ランボー博士:「今日はActive/ActiveによるLUNアクセスだ」

ニアライン君:「はい」

ランボー博士:「Active/Activeなアクセスとはどういうものか知っているか?」

ニアライン君:「知りません」

ランボー博士:「だろうな」

ニアライン君:「・・・・・」

ランボー博士:「簡単に言えばSP-AとSP-Bから同じLUNに対してアクセスが出来るということだ」

ニアライン君:「え!今までは出来なかったのですか?」

ランボー博士:「そうきたか。。」

ニアライン君:「え?」

ランボー博士:「もう少し気を利かせた質問、「ALUAで以前からSP-AとSP-Bの両方から同じLUNにアクセスが出来たのでは?」あたりが来ると思ったのだが、そこまで期待をした私がバカだったということだな」

ニアライン君:「あるあ?」

ランボー博士:「ALUAとは非対称Active/Activeとも呼ばれるもので、VNX(ストレージ)はSP-AとSP-Bの両方から同じLUNに対するアクセス要求を受けることが出来る」

ニアライン君:「両方のSPからアクセスできるから、非対称ながらもActive/Activeなのですね。とはいってもこの「非対称」っていう言葉は何故ついているのですか?」

ランボー博士:「非対称だからだ」

ニアライン君:「また乱暴な!」

ランボー博士:「乱暴でも何でもない。片方のSPに対するアクセスの方が多いから非対称。それ以上の説明があるか?」

ニアライン君:「いや、例えばどちらか片方のSPに対するパスはPreferred Path、もしくはOptimized Pathと呼ばれ、ホストからLUNへのアクセスは主にそれらのパスを用いて行われるために、アクセスIOの量がPreferred/Optimized Pathが設定されている方に片寄り、アクセスがSP-AとSP-Bで非対称となる。というような意味の非対称かと思っていました」

ランボー博士:「ニアライン、貴様・・・」

ニアライン君:「(にやり)」

ランボー博士:「まぁその説明でもいい。間違えではない」

ニアライン君:「ありがとうございます!」

ランボー博士:「VNXにおけるALUAでは、Preferred/Optimized PathはアクセスしようとしているLUNのデフォルトオーナーであるSPに対するパスが基本的には設定される」

ニアライン君:「何故でしょうか?」

ランボー博士:「それの方がLUNに対するアクセスの経路が短く効率的だからだ」

ニアライン君:「はぁ」

ランボー博士:「VNXの内部処理はまだActive/Passiveだからな」

ニアライン君:「Active/Passive?」

ランボー博士:「そう呼ぶとと恰好は良いが、乱暴に言えば片方のSPからしかバックエンドのLUNにはアクセスが出来ないということだ」

ニアライン君:「じゃあPreferred/Optimalで指定していない方のSPからはアクセスが出来ないってことになってしまうのでは?」

ランボー博士:「ならない」

ニアライン君:「え?何故ですか?」

ランボー博士:「CMIを利用するからだ」

ニアライン君:「なるほど!」

ランボー博士:「もしかして君は今日早く帰りたいと思っていないか?」

ニアライン君:「・・・」

ランボー博士:「CMIとは何か知っているのか?」

ニアライン君:「いえ。知りません」

ランボー博士:「たしか以前はCLARiiON Message Interfaceと呼ばれていたが、最近はある意味当て字でCommunication Manager Interfaceと呼ばれているもので、SP-AとSP-Bをつないで情報のやり取りを行うバスのことだ」

ニアライン君:「はぁ」

ランボー博士:「ちなみに人によって定義は異なるが、ストレージの3大コンポーネントは何か知っているか?」

ニアライン君:「知りません」

ランボー博士:「フロントエンド、キャッシュ、バックエンドだ」

ニアライン君:「フロントとバックでエンドが2つあるのはなんだかおかしくないですか?」

ランボー博士:「名前なのでそのまま憶えろ。何にしてもホストとのIOをやり取りするインタフェースとしてのフロントエンド。ディスクとのIOをやり取りするインタフェースとしてのバックエンド」

ニアライン君:「はぁ」

ランボー博士:「そしてフロントエンドとバックエンドの間に存在するキャッシュという3つのコンポーネントは頭に叩き込んでおけ。VNXではそれらの3大コンポーネントは全てStorage Processor(SP)の中に入っていて、絵にするとこんな感じだ」

storage_components.png

ニアライン君:「一番右にある3つですね」

ランボー博士:「そうだ。そしてVNXはActive/Passiveストレージアレイなので、"バックエンドから"一つのLUNに対しては片方のSPからしかアクセスは出来ない」

ニアライン君:「なんかそうやって強調して言われると"フロントエンドから"だったらアクセスできるみたいに聞こえちゃいますね」

ランボー博士:「そうだ」

ニアライン君:「は?」

ランボー博士:「フロントエンドからだったらアクセス可能だ。一つのLUNに対してどっちのSPからもアクセスできる」

ニアライン君:「え、でも結局はバックエンドからディスクへアクセスするんだから結果的に片方のSPからのみのアクセスになってしまうのではないでしょうか?」

ランボー博士:「そうだ」

ニアライン君:「え?」

ランボー博士:「フロントエンドとバックエンドをきちんと分けて考えろ!」

ニアライン君:「フロントエンドは一つのLUNに対して両SPからのアクセスがOK、ただしバックエンドは片方のSPからしかアクセスはできない。ですよね?」

ランボー博士:「その通り。だからバックエンドでLUNがつながっていない方のSPのフロントエンドからIOリクエストが届いた場合には、CMIを通じてLUNがつながっているSPへとルーティングされ、LUNへとアクセスしていくのだ」

ニアライン君:「でもそれって効率悪いですよね」

ランボー博士:「だからそう言っただろ?」

ニアライン君:「あれ?そうでしたっけ」

ランボー博士:「Preferred/Optimal Pathを利用したアクセスと、もう片方からアクセスがあった場合の処理イメージは以下のようになる」

ALUA-preferred non-preferred.png

ランボー博士:「見ての通りHostからはSP-A、SP-Bの両方にアクセスできるのでフロントエンドではActive/Activeに見えるが、バックエンドは100% Active/Passiveだ」

ニアライン君:「エセActive/Activeですね」

ランボー博士:「そういう大人げないネーミングはやめろ。非対称Active/Activeだ」

ニアライン君:「アンシンメトリック万歳ですね!」

ランボー博士:「しかしながら、次世代VNXでは非対称Active/Activeではなく、完全なActive/Activeがとうとう具備されて以下の図のようなアクセスが可能となったのだ」

active-active.png

ニアライン君:「おぉ」

ランボー博士:「これが次世代VNXにおけるActive/ActiveなLUNアクセスだ!以上!」

ニアライン君:「話はほとんど次世代VNXの話ではなくてVNXの話でしたね!」

ランボー博士:「お前のせいだ」

元の投稿で解決策を見る

0 件の賞賛
Goripon
3 Argentium

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

Goriponと申します。

いつも役立つ情報ありがとうございます。

実は私も今VNXにおけるALUAの挙動でわからない点があるので質問させて下さい。

ランボー博士とニアライン君の会話の中でActive/Active StorageとしてHostから認識されるとありますが

Native MPIOから純粋にActive/Activeと認識されるのでしょうか?

環境と懸念といたしましては以下の通りです。

・Win2008 R2 MPIO

Active/Active Storageとして認識された場合、デフォルトでHost側でRound Robinを選択すると思いますが、

その場合のALUAを使用しバックエンドでりダイレクションする事によるパフォーマンス劣化を懸念しております。

・ESXi 5.1 MPIO

こちらも同様にActive/Activeとなった場合はRRが選択されると思います。

RRで本当にActiveなPathだけでバラ巻いてくれるのであれば良いのですが、本来InactiveなPathもActiveと認識

してバラ巻くようであればPolicyを再検討したいと思います。

よろしくお願い致します。

あ、ちなみに次世代VNXではなく。。。VNX5300となります。。。

0 件の賞賛
モデレーター
モデレーター

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

ランボー博士とニアライン君の会話の中でActive/Active StorageとしてHostから認識されるとありますが

Native MPIOから純粋にActive/Activeと認識されるのでしょうか?

Native MPIOから純粋にActive/Activeとは認識されません。

ALUAは(EMC固有の規格ではなく)SCSI SPC-3仕様の規格であるために、「ALUA対応している」Native MPIOからVNX5300はALUA対応のストレージであると認識されます。

Win2008 R2のMPIOはALUAであると認識をすればデフォルトで「Round Robin With Subset」を選択するようです(MSのWebページにはALUAの場合は「フェイルオーバー」がデフォルトと書いてあるものを見つけましたが、とりあえずEMCのHost Connectivity Guideの情報を信じることにします)。

その際には、きちんとLUNのオーナーであるSPへのPath(s)をActive/Optimizedと認識し、オーナーではないSPへのPath(s)をActive/Unoptimizedと認識した上で、Round Robin With Subsetのポリシーに従い、OptimizedのPath(s)を利用したラウンドロビンとして動作してくれるはずです。

一方で、ESXi 5.1以降のMPIOはALUAと認識した場合にはデフォルトでRRを選択します(5.0まではFIXEDでした)。

とはいえ、ESXiのRRではOptimized Path(s)だけを利用してラウンドロビン処理が行われるために、Goriponさんが心配しているようにUnoptimized Path(s)に対してもOptimized Pathと同様のトラフィックが発生→パフォーマンス低下という問題は発生しないはずです。

また、VNX5300でR32以上のBlock OEを利用している場合には、「TrespassしたLUNが自動では元に戻らない」というRRポリシーが持っていた弱点も克服されています!(この問題が克服されたことが、ESXiにおけるALUAのデフォルトポリシーがFIXEDからRRに変更された大きな理由と聞いています)

【参考情報】

VNX and vSphere 5.1 Multipathing Enhancementsを見るとESXiとVNX間のMPIO動作がつかみやすいと思います。

このYoutubeビデオでは、5つのLUNに対してSP-AとSP-Bにそれぞれ2本ずつのPathが設定されている状況、つまり10本のOptimized Pathと10本のUnoptimized Pathがある状況で、MPIOポリシーとしてFixedを選択すると、1つのLUNに対して1つのOptimized Path(合計5パス)のみ利用(<I/O>マークが付与)されるのに対し、RRを選択すると、2本のOptimized Path(合計10パス)がラウンドロビンで利用されるのを見ることが出来ます。

ちなみにこれを見るとわかるのですが、もしもVNX5300の一つのSPに対してPathを1本しか設定していない場合には、RRでもFIXEDでもパフォーマンスに大きな違いは出ないはずです。

0 件の賞賛
Goripon
3 Argentium

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

ご回答ありがとうございます!

ALUAの挙動について大変参考になりました。

ところでWindows2008 MPIOに関してHost Connectivity上、以下の記述を見つけました。

◆ VNX series and CLARiiON devices will report a default Load

Balance Policy as “Round RobinWith Subset”, where all paths to

the SP owning the device as “Active/Optimized”, and all paths to

the SP not owning the LUN as “Active/Unoptimized”.

VNX series and CLARiiON devices attached to the host in ALUA

mode (as is required when using native MPIO) report the path

state which is used directly by the host running native MPIO and

cannot be overridden by changing the Load Balance Policy.

こちらはALUAでもRound RobinWith Subsetで動くと考えてよろしいでしょうか?

お手数ですが、ご確認よろしくお願い致します。

G

0 件の賞賛
モデレーター
モデレーター

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る

Goriponさん

こちらはALUAでもRound RobinWith Subsetで動くと考えてよろしいでしょうか?

はい。該当部分を見るとRound Robin With Subsetで動くと読めますね。

実際に動いているのを見たいと思い、社内ラボでWindows 2008でMPIOを利用してVNXに接続されているものを探してみたのですが、さすがEMC(?)、確認を行った約10台はすべてWindowsのNative MPIOは利用していませんでした(PowerPathを使っているものはあったのですが。。)。

【参考情報】

STORAGE NETWORKS社Webページの「Part IV: Configuring ALUA / Failover in Windows and verifying dual connectivity」セクションにALUAによるWindows 2008のMPIOとCX300(古い。。とはいってもVNXについての言及もあります)の接続に関する記事があり、そこにあるスクリーンショットでもDGC RAID 5デバイスに対してRound Robin With Subsetが設定されているのが読み取れます。Googleで検索すると見つけられると思うので、必要に応じて確認してみてください!

0 件の賞賛
Goripon
3 Argentium

Re: ALUAからActive/Activeへ【Ranbo対話シリーズ】

解決策を見る


Community Mgr様

"Configuring ALUA / Failover in Windows and verifying dual connectivity”も参考にさせて頂きました。

確かに仰るとおりですね。

おかげさまで概ね疑問が解消されました。

(もしかしたら別立てでRR選択時にAuto-Restoreするのか。。を投稿させて頂くかもしれませんがよろしくお願い致します。)

ありがとうございました!

G

0 件の賞賛