さて、これまでよりも SAN をもう少し活用し、同時に ESXi も活用し始めたいと思います。
現在、私は Dell PowerEdge 1955 ブレードのアレイを、単一エンクロージャの EMC AX4-5 FC ストレージ アレイに接続しています。基本的に、SAN を DAS として使用しています。SAN 上には特定の物理マシンを指す LUN があり、それらのマシンは LUN をさまざまな用途 (ターゲット サーバーに応じて、主にデータベースと Samba/NFS 共有) に利用します。
私は複数の物理ファイル サーバーを所有しており、それぞれに適切な共有を提供するための samba 構成セットアップがあります。RHCS を動作させたことがないので、一度にマウントされる LUN は 1 つのファイル サーバーのみになります。ファイル サーバーがダウンした場合は、手動でフェンスし (ドライブをアンマウントして非公開にするか、Navisphere ユーティリティを使用するか、DRAC 経由で電源を切るかのいずれか)、Navisphere ユーティリティを使用して次の候補で提示された LUN を起動します (その後、Apache とその他のデーモンを起動します)。今のところ、すべて手動で行っています。
まるでクラリネットを演奏するフェリス・ビューラーのような気分です。レッスンを受けたことはありません！
とにかく、改善しようとしています。私がやりたいのは、物理ホストに ESXi をインストールし、2 つのファイル サーバー イメージを保持する LUN を作成することです (1 つが破損したり、故障したりした場合に備えて)。1 つはアクティブで、もう 1 つはスタンバイになります。少なくともこの方法では、自動化は改善されません (ただし、近いうちに「アクティブ」サーバーを切り替えるスクリプトを作成する予定です) が、柔軟性が追加されているように感じます。さらに、ESXi ホストを使用して他の VM を保持できるため、現在のようにハードウェアが無駄になりません。
私の質問は次のとおりです:
1) 私の計画はどれほど愚かなのだろうか?
2) 実際の実装に関しては、LUN 上に通常の vmdk イメージを作成する必要がありますか、それとも「raw」パーティションを指定する必要がありますか (ESXi でそれが可能であれば)?
3) クラスター化されていないファイルサーバーを使用する「良い」方法はありますか?
答え1
あなたの計画は無謀ではありません。いつものように、あなたが何を達成しようとしているのか、どのようにデータを保護するのかに基づいて、これに対処する方法はいくつかあります。
まず、「Raw デバイス マッピング」を使用して、raw LUN を VM に提示できます。これを行うには、次の手順を実行します。
- LUN を ESXi ホスト (またはクラスタリング/HA を使用する場合はホスト グループ) に提示します。
- VMにディスクを追加し、Raw Device Mappingを選択し、LUNを指定します。
- VM内のSCSIバスを再スキャンする
- 通常のディスクと同じように、fdisk でマウントし、fstab に追加します。
利点: セットアップが速く、使用が速く、簡単、将来的に V2P が必要になった場合にディスクを物理ホストに置き換えることができる
欠点: 物理互換モードまたは仮想互換モードのどちらを使用するかによって、VMware ベースのスナップショット/ロールバック オプションの一部が失われる場合があります。
別の方法としては、LUN 上に VMFS を作成してデータストアを作成し、そのデータストア上にある VM に VMDK ディスクを追加する方法があります。
- 利点: 使用ライセンスを購入すれば、Storage vMotion と互換性があります。これにより、LUN 間や SAN 間での VMDK ディスクのホット マイグレーションが可能になります。
どちらの場合も、障害発生時に VMware または VM がファイルシステムを消費すると、同様のリスク状態になります。利用できる回復オプションはまったく異なりますが、どちらかが他方よりも大幅に優れているわけではありません。
私は、必要でない限りRDMを導入しません。VMDKほど柔軟性がないことが分かりました（そして、バグそのため、他のストレージ操作を実行するときに実用的ではありませんでした (修正済み - そのリンクの RDM セクションを参照してください))
VM に関しては、柔軟性を高めるには、ファイルサーバーのブート ディスクを VMDK として SAN に保存し、ホスト障害が発生した場合に他のホストから起動できるようにするのが最善策です。VMware の HA 機能を使用すると、別のホストでの VM の起動は自動的に行われます (VM は、電源が抜かれたかのように 2 番目のホストで起動します。通常のサーバーの場合と同様に、通常の fsck とマジックを実行して起動する必要があります)。HA はライセンス機能であることに注意してください。
VM の障害を軽減するには、起動して SAMBA を構成された状態で起動するために必要な最小限のものを含むファイルサーバーの軽量クローンを作成し、これを各ホストのローカル ディスクに保存して、障害が発生した VM からデータ ドライブを追加して電源を入れるまで待機します。
これにより、SAN 障害が発生した場合に追加のオプションが提供される場合と提供されない場合があります。最良のシナリオでは、データ ストレージに fsck またはその他の修復が必要になりますが、少なくとも VM を修正、再構築、または構成する必要はありません。最悪のシナリオでは、データが失われ、テープに戻る必要があります... ただし、いずれにせよ、すでにその状態になっています。
答え2
将来 vmotion を使用するよう移行する場合に備えて、vmdk イメージを使い続けることをお勧めします。そのための予算が得られるかどうかはわかりません。
マシンがクラスター化されていない場合、私が知る限り、マシンを管理する最善の方法は、負荷をできるだけ均等に分散させることです。私は、最も重要な VM からの負荷がそれぞれに 1/3 ずつかかるようにした、クラスター化されていない 2950 を 3 台持っています。理論的には、一度に 1 台以上のボックスが失われる可能性は低いので、少なくとも 2/3 は影響を受けずに動作を継続できます。
電力の観点から言えば、マシンをできる限り 100% 近くまで負荷をかけ、他のマシンの電源をオフにする方が効率的かもしれませんが、すべての卵を 1 つのバスケットに入れるようなものだと思います。
私は自分自身をこの分野の専門家とは呼びませんが、これは私がやっていることなのです。
答え3
こんにちは、Matt。仮想化ソリューションを使用する場合、ソリューションを分割する方法はたくさんあります。まず、Raw LUN (RDM) と VMDK のパフォーマンスを比較したベンチマークが多数あり、その差は通常無視できるほど小さいことが示されています。RDM に関して注意すべき点がいくつかあります。特定のクラスタリング状況でのみ、RDM (MS クラスタリング) を使用する必要があります。RDM には 2 TB の制限がありますが、LVM を使用してこの制限を回避できます。RDM は、VMFS に使用するために ESXi に LUN を与え、そこに vmdk を配置するよりも、追跡が「困難」です。VMDK (前述のとおり) には、svMotion、スナップショット (pRDM のスナップショットは作成できません) などの優れた利点があります。
無料の ESXi を実行している場合、状況に応じて次の方法があります。まず、すべてのデータは VMFS LUN 上の vmdk ファイルにあります。2 つの VM をセットアップし、IP とサービスのフェイルオーバーに Heartbeat を使用します。Heartbeat はサービス IP を切り替え、必要に応じてデータ LUN をマウント/アンマウントするスクリプトを処理できます。VMware リモート CLI のスクリプトを作成して、フェンシングのために「ダウン」した VM の電源をオフにすることもできます。Heartbeat がシステム間を直接調整するため、データ LUN にアクセスしたり同じサービスを実行したりするリスクは非常に低くなります。ここで重要なのは、データ LUN のマウント/アンマウントとサービスの起動/シャットダウンが通常の init メカニズムではなく Heartbeat によって処理されるようにすることです。
代替のフェイルオーバーは、監視システムを介して実行できます。ダウンしたホストを検出すると、VMware リモート CLI を使用して電源をオフにし (安全のため)、その後バックアップ VM の電源をオンにすることができます。この状況では、フェイルバックは手動で行う必要があります。
私の「小さな」環境では、VMDK が破損したことはありません。また、2 台以上の ESX(i) ホストまたは 12 台以上の VM がある場合は、すべてを追跡するために vCenter を入手する必要があることにも気付きました。Essential/Plus パッケージの一部は、メリットを考慮するとそれほど高価ではありません。
答え4
「物理サーバーに戻るつもりはあるか」と自問してみるといいと思います。
答えが「多分」であれば、RDM に固執すべきでしょう。RDM を備えた ESXi では、ファイバーを動作させるために何かを購入する必要があります (これも esxi では 100% 確実ではありません)。
物理サーバーから ESX (4.0) に RDM を使用して簡単に移行したマシンが数台ありました。Linux マシンと Windows マシンが混在していました (どちらのプラットフォームでも非常に簡単)。物理サーバー上でレガシー FreeBSD (6.0 以前) を実行しているマシンがまだ数台ありますが、古い FBSD カーネルがこれをサポートしていないため、RDM は使用できません。作業は迅速で、LUN を指定して VMWare ツールをインストールする以外に何もする必要はありませんでした。非常に簡単で、コンバーターも手間もかかりません...
自分自身に問いかけるべきもう 1 つのことは、「VMWare のどの機能を使用したいのか?」ということです。
その答えによっては、VMDK 以外の選択肢がない場合があります。たとえば、スナップショットに SAN を使用していて、そのために VMware を使用することを気にしない場合は...
これまでに遭遇した問題について、いくつかメモを共有します。Vmotion は RDM と VMDK で同様にうまく機能しますが、その一方で Storage Vmotion は非 RDM でのみ正しく機能し、Vmotion ストレージを使用して RDM から VMDK に変換しようとすると、コンバータを使用するだけでうまくいきません。ほとんどの Linux ディストリビューションには、ツールのインストールが問題にならないオープン ソースの VMware ツール パッケージがあります。バックアップ アプライアンスは非常に適切に機能し、VMware から無料で提供されますが、私たちが望むほど多くの機能はありません。VMware のクラスを受講することを強くお勧めします。私が受講したクラスは 1 週間でしたが、その価値は十分ありました。VMware のサポートは素晴らしいです。サポート契約を結んで電話しなければならない場合でも、彼らは最高です。助けてくれる人にたどり着くのはイライラしますが (メニューが多すぎて)、いったんたどり着くと、常に迅速で信頼性の高いサポートを提供してくれます。