IT or War

File Base Backup とは？ 仮想マシンのバックアップといえば、 VADP を利用したイメージベースのバックアップが一般的ですが、 vCenter Server や NSX Manager といった仮想アプライアンスにおいてはファイルベースのバックアップというものが存在します。 ファイルベースバックアップとは、仮想アプライアンスのイメージそのものではなく、仮想アプラインスとしての設定値やログファイルや DB ダンプといった情報のみのバックアップであり、 OS イメージ自体は含まれません。そのため、イメージベースのバックアップよりはサイズが小さくなります。 一方で、リストアの際には仮想アプライアンスの OVA ファイルが必要となります。 OVA ファイルから仮想アプライアンスを展開したのちに、仮想アプライアンスの機能でバックアップファイルから設定等を復旧する流れになります。     既存のバックアップ手法があればファイルベースバックアップは不要？   vCenter サーバで File Base Backup がサポートされたのは vCenter 6.5 からです。 それ以前は VADP を利用したイメージベースバックアップが主流だった認識です。 File Base Backup/Restore の登場によって、 vCenter サーバのイメージベースバックアップが非サポートになるという噂も一時期耳にしましたが、 少なくとも本記事投稿時点ではイメージベースバックアップは引き続きサポートされています。 Image-Based Backup and Restore of a vCenter Server Environment (vmware.com)   ここで一つの疑問が生まれます。 「従来のイメージベースバックアップを利用している環境であればファイルベースバックアップは不要なのか？」   厳密にいえばイメージベースバックアップとファイルベースバックアップのそれぞれからリストアした場合で、 １００％同じ状態にリストアされるわけではないのですが、特定の正常動作ポイントにリストアが可能であるという意味において、 どちらか一方の手法...

  ※本ナレッジは学術的な根拠に基づくものではなく私個人が利用している評価方法です。結果についての責任は負いかねますので、ご利用の際は自己責任でお願いします。     背景 ストレージの性能指標として IOPS やレイテンシやスループットを参照する場合がある。 多くの場合、ランダム Read/Write （ RR/RW ）とシーケンシャル Read/Write （ SR/SW ）における限界性能値であったり、 サンプルワークロードとして、 OLTP 32KB Read 70% や、 RDMS Read 40% などの負荷に対する性能値として提示されている場合がある。 とはいえ、実際の環境ではそれらの IO パターンと一致していないことも、当然ながら多い。 そのようなときに、 RW 比が 7:3 ではなく、 6:4 のときの IOPS 性能値が知りたいケースもある。 本記事ではそのようなときに既存の性能情報からざっくりと必要な RW 比での情報を見積もる方法を紹介する。     必要な情報 そもそもの話として、実環境の RW 比と必要となる IOPS 性能値がわかっていなければ評価のしようがない。 また、平均的な IO サイズについても知っておく必要がある。 そして、評価対象であるストレージの性能情報についてもなるべく多くのパターンを入手する必要がある。 実環境の RW 比、 IOPS 、 IO サイズについては把握できていない環境も多いが、 LiveOptics （無償）などのアセスメントツールを使うことで簡単に確認できる。 ストレージの性能情報についてはベンダーに確認する、もしくは Sizing Tool などから入手できる場合もある。 このとき、 IO サイズのパターンが多ければ多いほど良い。 IO サイズによって IOPS は大きく変わるが、 RW 比と異なり異なる IO サイズでの性能情報を見積もることは困難であるため、実環境に近い IO サイズで検証している性能情報を入手することが重要である。     100 ％ Read / 100 ％ Write の限界性能値のみがわかる場合。   実環境の平均 IO サ...

ちょっとしたメモとして投稿。     事象 vSAN iSCSI Target を作成したのにESXiホストで iSCSI サービスが LISTEN されない   原因 vSAN iSCSI ターゲットの設定画面にて、「デフォルトの iSCSI ネットワーク」で指定したvmkernel portが IPv4 無効な場合に 発生する   説明 vSAN iSCSI Target を有効化する際に、デフォルトの iSCIS ネットワークとして既存の vmkernel port を選択する項目がある。   この項目は、その後のステップで iSCSI ターゲットを作成する際に任意の vmkernel port で上書きできるため、この時点で実際に利用する vmkernel port を指定する必要はない。 しかしながら、実際に iSCSI ターゲットのインターフェースとして利用可能な vmkernel port を利用する必要がある。 たとえば、 VxRail などのアプライアンス製品では vmk0 は自動検知用（IPv6利用）として ipv4 が無効化されているケースがある。 このようなケースにおいて、ipv4が無効化されているvmkernel port を「デフォルトの iSCSI ネットワーク」として指定した場合、vSAN iSCSIターゲットサービスの起動時に該当のポートを iSCSI ターゲットとしてバインドすることができず、正常に起動できなくなる。結果として、 iSCSI ターゲット作成時に上書きした他の vmkernel port も含めて iSCSI 接続ができなくなる。   仮に以下の設定をしたとする。 ・デフォルトの iSCSI ネットワークとして vmk0 （ IPv4 が無効）を指定 ・作成した iSCSI ターゲットで vmk5 を指定   この状況で iSCSI Target (vmk5 利用 ) に対して iSCSI 接続を試みても接続ができない。 vitd.log を確認すると以下の実際には使われない vmk0 に対して iSCSI サービスのバインドができないため、 vmk5 へのバインドも...

目的 vSAN のノード & ディスク障害を発生させて IO の停滞がどれくらい発生するのかを確認することを目的とします。     手順概要 vSAN 上で Windows/Linux OS を稼働させ、ベンチマークツールで IO 負荷をかけながら、パフォーマンスツールで IO をモニターします。 途中で意図的に障害を発生させて IO への影響（停滞～復旧までの時間）を確認します。   vSAN クラスタの準備 通常通りに vSAN クラスタを準備します。 本検証では、 vSAN 8.0U1 の OSA Hybrid の 4 ノードクラスタを準備しました。     疑似障害の準備 vSAN PG の Teaming ポリシー設定で、 Active の vmnic を一つだけにしておきます。それ以外は Unused に設定し、 Standby にはしません。 esxcli vsan network list で vSAN 用の vmk を特定します。 esxtop の n オプションで vsan vmk が利用する vmnic も特定しておきます。   Windows VM の準備   OS のインストール まずは検証用の Windows OS を vSAN クラスタ上に準備します。（検証用 Windows VM ） IO 計測をする VMDK は別で作成するため、 Windows OS をインストールする VMDK は vSAN でなくてもよいですが、 仮想マシンの構成ファイルを vSAN 上に配置しておかないと後述の物理配置確認ができなくなります。（ GUI に表示されない） そのため、仮想マシンの構成ファイル（ vmx ファイルとか）は vSAN データストア上に配置しましょう。（ Storage vMotion でディスク個別の配置が可能です）   検証用の VMDK を作成する 障害検証用の VMDK （ vSAN DataStore ）を作成し、 Windows OS に新規ドライブとして認識させます。（本検証では E ドライブ）   ...