こんにちは、キクです。
「物理ポートが所属するブロードキャストドメインを変更したいけど、一度離脱させる作業がめんどくさい」
「異なるブロードキャストドメイン間ではLIFの移動はできないの？」
NetAppを利用していると、こんなシチュエーションに遭遇することもありますよね。
僕もNetAppの初期構築を何度か経験する中で、最初に「Default」というブロードキャストドメインから離脱させてから他のブロードキャストドメインに参加させなければならないのが正直手間だなと思うこともありました。
また、最近ではNetAppを使用したリプレース作業に携わっており、その中でこんな経験をしました。
「新環境NetAppで既に作ってしまったLIFを一度旧環境に退避し、新環境を再構築する」
なんとも二度手間感がありますが、構成変更の関係から致し方なく。。
しかし、そんな中で覚えたのが今回のテーマである『ブロードキャストドメインの結合 / 分割』です。
これまでは手動でブロードキャストドメインから参加ポートへの離脱作業により一度未参加状態にして、そこから新しいブロードキャストドメインに参加させる方法しか知りませんでした。
でも、今回の「結合 / 分割」は簡単に物理ポートの移し替えができたので素直に「便利だな」と感じました。
そんな経験を元に本記事を書いていきたいと思います！
本記事の内容
それでは、よろしくお願いします。
はじめに
今回のテーマである『ブロードキャストドメインの結合 / 分割』の内容に入る前に、作業に関連するいくつかのルールについて見ていきたいと思います。
具体的には「ブロードキャストドメイン」「フェイルオーバーグループ」「LIF」のそれぞれが持つルールになります。
なお、ここで紹介するルールがすべてではなく、本作業に関連するものだけをピックアップしているのであらかじめご了承ください。
ブロードキャストドメインのルール
物理ポートなどが所属する「ブロードキャストドメイン」というものには次のようなルールが存在しています。
これはつまり対象ポートは2つのブロードキャストドメインには所属できないことを意味します。
仮にブロードキャストドメインAに所属しているポートに対してブロードキャストドメインBに所属させるコマンドを実行すれば失敗してしまいます。
本記事冒頭で「最初に「Default」というブロードキャストドメインから外して他のブロードキャストドメインに参加させなければならない」と言っていたのはこのルールがあるからにほかなりません。
フェイルオーバーグループのルール
フェイルオーバーグループのルールの話をする前に、簡単にフェイルオーバーグループそのものについて触れていきます。
フェイルオーバーグループとは、簡単に言えばLIFの移動範囲のことです。
以下の図を見てみてください。
LIFはフェイルオーバーグループAに所属した状態になります。
この場合、LIFは物理ポート2には移動できますがフェイルオーバーグループBに所属している物理ポート3や物理ポート4には移動できません。
というより移動させないためのグループ設定になります。
それでは「フェイルオーバーグループ」のルールを見ていきましょう。
ここでは2つのルールをご紹介します。
ルール1：フェイルオーバグループに追加するすべてのポートが同じブロードキャストドメインに所属している必要がある
このルールから言えることは、別のブロードキャストドメインに参加しているポートは追加することができないということ。
以下の図では、物理ポート5はブロードキャストドメインAに所属するポートです。
ブロードキャストドメインですからネットワークのお話ですよね。
つまり、ブロードキャストドメインAとBは別のネットワークであると考えられます。
この状態でフェイルオーバーグループBに物理ポート5を参加させた場合を考えてみると、障害時には次のような流れになります。
動作②で物理ポート5が選ばれた場合、対象LIFは異なるネットワークであるブロードキャストドメインAに移動することになります。
LIFに設定されたIPアドレス情報はそのままですので、これでは急に通信できない状態になってしまいます。
例えば10.18.10.5/24というIPアドレスを持つLIFが、突然10.18.20.xx/24のネットワークに飛ばされたら通信できなくなってしまいますよね。
ルール1はこのような問題を回避するために設けられているのだと思います。
ルール2：フェイルオーバーグループはシステムによって自動管理され、ブロードキャストドメインのポートが追加/削除されるとフェイルオーバーグループにも同様に自動的に追加/削除される
このルールがあることによりフェイルオーバーグループの管理がとても楽になります。
後ほど登場する「ブロードキャストドメインの結合 / 分割」においてもこの仕組は使用されています。
例えば結合時に対象となったポートはブロードキャストドメインに参加すると同時にフェイルオーバーグループにも自動的に追加されます。
現時点ではイメージしづらいかもしれないので、後ほど詳しく見ていきましょう。
LIFのルール
物理ポート上で稼働する論理インターフェースである「LIF」には以下のようなルールがあります。
このルールがあることによりLIFの移動範囲を定めることができます。
仮にLIFに対してフェイルオーバーグループを設定していない状態だと、障害時にLIFがどこに飛んでいっていしまうか分かりません。
それでは困ってしまうので、事前に設定しておく移動範囲を定めておく必要があるということです。
ブロードキャストドメインの結合
それでは本題に入りましょう。
本節では『ブロードキャストドメインの結合』について解説します。
まず、ここで言う「結合」が何を意味するかについてですが、既存のブロードキャストドメインを2つ選択して一方のブロードキャストドメインに合体させてしまうことを言います。
以下の図を見てみましょう。
結合前はブロードキャストドメインAとブロードキャストドメインBではそれぞれに物理ポートが2つずつ所属している状態です。
これをブロードキャストドメインBに存在するすべてのポートをブロードキャストドメインAに含めてしまうのが「結合」です。
ちなみに上図でも表現していますが、所属ポートをすべて失ったブロードキャストドメインBは不要になるので自動的に削除されます。
実際のコマンドを見てみるとよりイメージが付きやすいと思います。
結合のためのコマンドは以下のようになります。
::> network port broadcast-domain merge -ipspace <IPスペース名> -broadcast-domain <参加対象ブロードキャストドメイン名> -into-broadcast-domain <結合対象ブロードキャストドメイン名>「-broadcast-domain」で選択するのが「ブロードキャストドメインB」
「-into-broadcast-domain」で選択するのが「ブロードキャストドメインA」
つまりはBをAに入れるということになります。
こうすることでブロードキャストドメインAには合計4ポートが所属していることになります。
ここでフェイルオーバーグループのルール2を思い出してください。
このルールによりブロードキャストドメインAに追加された物理ポート3と物理ポート4は、自動的にフェイルオーバーグループAに追加されることになります。
これによりLIFは合計4ポート内で移動できることになりました。
LIFの移動
続いての作業は『LIFの移動』になります。
この作業自体は特に難しいことはなく、LIFを稼働させるポートをフェイルオーバーグループ内で手動で移動させてあげるだけです。
以下の図の場合は物理ポート1から物理ポート3に対してLIFを移動させています。
LIFを移動する移動のためのコマンドは以下のようになります。
::> network interface migrate -vserver <SVM名> -lif <LIF名> -destination-node <移動先ノード名> -destination-port <移動先ポート>「-lif」で選択するのが「移動対象のLIF」
「-destination-node」で選択するのが「移動先ポートを持つノード」
「-destination-port」で選択するのが「移動先ポート」
今回の図ではノードまでは表現していないので分かりづらいかもしれませんが、例えばnode-Aのport-Aからnode-Bのport-BにLIFを移動させたい場合は以下のようになります。
::> network interface migrate -vserver <SVM名> -lif <LIF名> -destination-node node-B -destination-port port-Bノード名の指定が必要なのは、各ノードで保持しているポートの名前は重複しているものがほとんどだからです。
例えば「e0a」という物理ポートが「ノードA」と「ノードB」の両方に存在している場合、ポート名だけではどちらのノードの「e0a」を指しているかが分からなくなってしまいます。
機種や構成によってあるものないものはありますが、基本的には「どのノードのどのポートなのか」を明確にするために明示的にノード名まで指定する必要があります。
LIFのホームノード / ホームポート変更
続いての作業は『ホームノードの変更』『ホームポートの変更』になります。
それぞれの役割や変更方法について、少し詳しく見ていきましょう
ホームノード / ホームポートとは
まず「ホームノード」「ホームポート」とは何かですが、これはLIFに設定された「家」みたいなものです。
家とはすなわち帰るべき場所のこと。
つまり、この2つは「LIFが帰るべき場所」を意味しています。
LIFの移動は手動で行う場合と自動で実行される場合とがあります。
障害発生時にLIFが自動的に移動（フェイルオーバー）したとします。
その後、障害が復旧したら事前に設定されたポートに戻ります。
この「事前に設定されたポート」というのが「ホームポート」になります。
前節でも触れましたが、ポート名だけではどのノードのポートなのかを判別できません。
そのため「ホームノード」の設定も必要になります。
対象のホームポートを持つノードがホームノードです。
この2つの設定によりLIFが帰るべき場所である「家」が明確になります。
変更理由と変更方法
では、なぜ今回の作業でホームノードとホームポートの変更が必要になるのでしょうか。
それは「変更しておかないとせっかく移動したLIFが元のポートに戻ってしまうかもしれないから」です。
LIFを移動していたとしても何か障害があったら元のポート（ホームポート）に戻ってしまいます。
今回の場合は最終的にブロードキャストドメインを分割するのでそれでは困ってしまいます。
そのため、事前にホームノードとホームポートを変更しておく必要があります。
変更のためのコマンドは以下のようになります。
::> network interface modify -vserver <SVM名> -lif <LIF名> -home-node <ホームノード名> -home-port <ホームポート名>ただし、ホームポートの変更は必要ない場合もあります。
というのも、ノードAの「e0a」というポートからノードBの「e0a」というポートに変更したい場合には、「e0a」というポート名は共通ですからホームノードだけ変更してあげれば大丈夫だからです。
逆にホームノードの変更が不要な場合もあります。
理由は似たようなもので、同じノード内でホームポートだけを変更する場合には、ホームノードを変更する必要はないからです。
ブロードキャストドメインの分割
最後の作業は『ブロードキャストドメインの分割』です。
先に実施した「ブロードキャストドメインの結合」の際にブロードキャストドメインBが消えてしまったのを覚えていますでしょうか。
ここでの作業は「ブロードキャストドメインA」を分割して、改めて「ブロードキャストドメインB」を作成することです。
最終的には以下の図のような状態になります。
分割のコマンドは以下のようになります。
::> broadcast-domain split -ipspace <IPスペース名> -broadcast-domain <ブロードキャストドメイン名> -new-broadcast-domain <新ブロードキャストドメイン名> -ports <参加ポート>「-broadcast-domain」で選択するのが「ブロードキャストドメインA」
「-new-broadcast-domain」で選択するのが「ブロードキャストドメインB」
「-ports」で選択するのが「物理ポート3, 物理ポート4」
新しいブロードキャストドメインとしてブロードキャストドメインBを作成します。
そして、ブロードキャストドメインAに所属していた物理ポート3 と物理ポート4をブロードキャストドメインB側に所属させるという動作になります。
元々ある構成を分け合うので「分割」と表現しました。
ちなみにフェイルオーバーグループはブロードキャストドメイン作成時に自動的に同名のものが作成されます。
そのため「フェイルオーバグループB」というのは特に意識する必要がありません。
この作業をもって今回のテーマである『ブロードキャストドメインの結合 / 分割』は完了となります。
最初はブロードキャストドメインAの物理ポート1で稼働していたLIFを、無事にブロードキャストドメインBの物理ポート3に移動することができましたね。
おわりに
いかがだったでしょうか。
今回はブロードキャストドメインの結合と分割によって異なるブロードキャストドメインへのLIFの移動を行いました。
本来異なるブロードキャストドメインに物理ポートを参加させたい場合には、一度参加中のブロードキャストドメインから離脱させる必要があります。
今回のように結合（merge)と分割（split）を利用すれば離脱作業をすることもなく一括で参加できてしまうというのがポイントでした。
ただし、一括で入ってしまうというのは意図していないポートも参加させてしまう恐れがあるので注意も必要です。
とはいえ便利なコマンドだったので、今後は僕も使う機会は多いかなと思っています。
本記事を最後までお読みいただき、ありがとうございました。
ではでは！