仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

ストレージ・SANスイッチリプレース時の移行方針について

みなさまお疲れ様です。

今回はストレージとSANスイッチが保守切れになり、リプレースする必要が出てきた場合、どのような移行ステップを考えればいいかを記事にします。

 

本記事では一例として「SANスイッチと一部のストレージが保守切れでリプレースの必要あり」という状況を考えてみましょう。

下記の図で赤点線部分をリプレース対象とします。「OLD Storage」はESXi用にデータストアを提供しているストレージと仮定します。

 

f:id:kenta53682:20170607212435p:plain

 


提案に当たって、下記3ステップを見据えておく必要があります。
①現状調査
②互換性の確認
③移行方針の検討

 


①現状調査
次の「②互換性確認」のために必要となる作業です。
SANスイッチに接続されているサーバー・ストレージの情報を確認します。
下記の情報をまとめておくと②でベンダーへの確認がスムーズになると思います。
・現行サーバー:OSバージョン
・現行サーバー:HBA Firmwareバージョン
・現行サーバー:HBA Driverバージョン
・現行SANスイッチ:FabricOSバージョン
・現行SANスイッチ:空きポートの確認
・現行ストレージ:Controller Firmwareバージョン
・現行ストレージ:SFPモジュール搭載状況、HBA空きポート状況確認


②互換性の確認
SANスイッチをリプレースする場合、新規SANスイッチはFabricOSが最新バージョンになるはずです。

 

この時、サーバー側のOS / HBA Firmware / Driver、ストレージ側のController Firmwareの互換性を確認する必要があります。具体的には下記を確認する必要があると考えられます。

 

互換性確認1 現行サーバー ⇔ 新SANスイッチ ⇔ 新ストレージ の互換性
◆新SANスイッチ、新ストレージが現行サーバーOSと互換性があること
→対応していないとOSバージョンアップが発生する恐れあり

 

◆新SANスイッチ、新ストレージが現行サーバーHBA Firmware / Driverと互換性があること
→対応していないとHBA Firmware / Driver バージョンアップが発生する恐れあり
→また、HBA Firmwareをバージョンアップする場合、現行SANスイッチとの互換性も確認 (移行時に事前作業としてFirmwareを上げるため)

 

※互換性確認1で、現行サーバーをサポートするFabricOSバージョンを確定させる

 

互換性確認2 現行ストレージ ⇔ 新SANスイッチ の互換性
◆現行ストレージコントローラーのFirmwareと1)で確定させたFabricOSバージョンの互換性があること
→対応していないとController Firmwareバージョンアップが発生する恐れあり
→また、Controller Firmwareをバージョンアップする場合、現行SANスイッチとの互換性も確認 (移行時に事前作業としてFirmwareを上げるため)
→下手をすると現行ストレージがサポートされないリスクあり

 

f:id:kenta53682:20170607213435p:plain

 

互換性確認3 現行SANスイッチ ⇔ 新ストレージ の互換性
◆現行SANスイッチのFabricOSと新ストレージの互換性があること

→データ移行の際に、現行SANスイッチに新ストレージを接続するため確認

→対応していないと現行SANスイッチのFabricOSのバージョンアップが発生する恐れあり

 

 

特に互換性の確認が取れないまま提案を進めると(そんなことは100%ないはずですが)
「いざ実作業を始めて問題が起き、サポートされない構成だと判明した」
「OSやHBAバージョンアップなど予想外の作業ボリュームとなり大赤字」
ということになりかねません。

 

 

③移行方針の検討
互換性まで確認ができたら、最後に移行方針を検討します。
規模が大きくないお客様であれば、提案時にある程度移行方針を固めると思います。

下記では移行方針の一例を記載します。

 

移行ステップ1 現行サーバー・ストレージのFirmwareバージョンアップ
まずは事前作業として、現行で稼働しているサーバー・ストレージのFirmwareバージョンアップ作業を行います。
②の確認結果に基づき、必要な機器のみバージョンアップを行います。

 

f:id:kenta53682:20170607213813p:plain

 

 

移行ステップ2 データ移行のため、新ストレージと現行SANスイッチ間のパスを作る
次の手順で行うデータ移行のため、現行ストレージと新ストレージ間のパスを作ります。
新ストレージにHBA空きポートが2つない場合、移行期間中は暫定的に1パスだけで運用を行うようお客様と調整する必要があります。
また、現行SANスイッチ側ににゾーニング設定が必要となります。

f:id:kenta53682:20170607213843p:plain

 


移行ステップ3 仮想マシンデータ移行
現行ストレージから新ストレージに対してvmdkを移行します。
ESXiホストから見ると現行ストレージ・新ストレージ両方が見える状態なので、Storage vMotionが可能です。

 

f:id:kenta53682:20170607213917p:plain

 

移行ステップ4 機器移行
すべての仮想マシンのStorage vMotionが終了したら、いよいよ機器を新SANスイッチに移行します。
一気に機器移行は問題発生時のリスクが大きいので、徐々に移行する方法が無難です。
接続して新ストレージが認識できない等があれば、旧SANスイッチ側に機器を切り戻して調査を行うなどの対応が可能です。

f:id:kenta53682:20170607213942p:plain

 

 

移行ステップ5 現行SANスイッチ・新ストレージ間のパス切断
移行のために準備した現行SANスイッチ ⇔ 新ストレージ間のパスを切断します。
旧SANスイッチと旧ストレージはそのまま撤去する流れとなります。

f:id:kenta53682:20170607214008p:plain

 
以上長文でしたがありがとうございました。SANの記事って意外と少ないですよね。
この記事が同じ悩みを抱えている方の助けになれば幸いです。
但し、移行方法についてはお客様環境毎にBestなものは変わります。本記事をベースにお客様にあった移行方針を考えるようご注意下さい。