サーバーをSANに仮想化するためのベストプラクティスは？
了解しました。SANをこれまでより少し活用し、同時にESXiを活用したいと思います。
現在、単一のエンクロージャーEMC AX4-5FCストレージアレイに接続されたDellPowerEdge1955ブレードのアレイがあります。私は基本的にSANをDASとして使用しています。SANに特定の物理マシンを指しているLUNがあり、それらのマシンはLUNを利用しています。何でも（ターゲットサーバーに応じて、主にデータベースとSamba/NFS共有）。
複数の物理ファイルサーバーがあり、それぞれに適切な共有を提供するためのsamba構成セットアップがあります。 RHCSを機能させることがなかったため、一度にLUNがマウントされるファイルサーバーは1つだけです。ファイルサーバーが停止した場合は、手動でフェンスし（ドライブのマウントを解除して表示しないか、navisphereユーティリティを使用するか、DRACを介して電源を切ることにより）、navisphereユーティリティを使用して次の候補で表示されたLUNを起動します（その後、Apacheおよびその他のデーモンを起動します）。すべて手作業で、今。
フェリス・ビューラーがクラリネットを演奏しているような気分になります。レッスンはありませんでした！
とにかく、私は改善しようとしています。私がやりたいのは、物理ホストにESXiをインストールしてから、2つのファイルサーバーイメージを保持するLUNを作成することです（1つが破損/ fubarになった場合）。1つはアクティブになり、もう1つはスタンバイになります。少なくともこの方法では、自動化を改善しません（ただし、近いうちに「アクティブな」サーバーを切り替えるスクリプトの作成に取り掛かる予定です）が、柔軟性を追加しているように感じます。さらに、使用できます。 ESXiは他のVMを保持するためにホストし、現在のようにハードウェアが無駄になることはありません。
私の質問は次のとおりです。
1）私の計画はどれほど愚かですか？
2）実際の実装に関しては、LUN上に通常のvmdkイメージを作成する必要がありますか、それとも「生の」パーティションを指定する必要があります（ESXiでも可能か？
）クラスター化されていないファイルサーバーを使用する「良い」方法はありますか？
あなたの計画はナッツではありません。いつものように、達成しようとしていることとデータを保護する方法に基づいて、これを攻撃する方法はいくつかあります。
まず、「生のデバイスマッピング」を使用して、生のLUNをVM）に提示できます。これを行うには：
- LUNをESXiホスト（またはクラスタリング/ HAを使用する場合はホストグループ）に提示します
- VMにディスクを追加し、[Rawデバイスマッピング]を選択して、LUNをポイントします
- VM内のSCSIバスを再スキャンします
- 通常のディスクと同じように、fdiskをマウントし、fstabに追加します。
利点：セットアップが速く、使いやすく、簡単で、V2Pを実行する必要がある場合は、ディスクを物理ホストに表すことができます。
欠点：物理互換モードと仮想互換モードのどちらを使用しているかによって、VMwareベースのスナップショット/ロールバックオプションが失われる可能性があります
別のオプションは、LUN上にVMFSを作成してデータストアを作成し、VMDKディスクをそのデータストア上にあるVM）に追加することです。
- 利点：使用するためのライセンスを購入したことがあれば、StoragevMotionに適しています。これにより、LUN間およびSAN間でのVMDKディスクのホットマイグレーションが可能になります。
どちらの場合も、VMwareまたはVMが障害時にファイルシステムを食い尽くす場合、同様のリスクポジションにあります。使用可能なリカバリオプションはありますが、一方が他方よりも大幅に優れているわけではありません。かなり違います。
必要がない限り、RDMを展開しません。私は彼らがVMDKとして私にあまり柔軟性を買わないことを発見しました（そして私は他のストレージ操作を実行するときにそれらを非実用的にした バグ に噛まれました（修正されたので-そのリンクのRDMセクションを参照してください） ））
VMに関しては、柔軟性のための最善の策は、ファイルサーバーのブートディスクをVMDKとしてSANに保存し、ホストに障害が発生した場合に他のホストにブートさせることができるようにすることです。 VMwareのHA機能、別のホストでのVMの起動は自動的に行われます（VMは、電源が入っているかのように2番目のホストで起動します。通常のサーバーの場合のようにそれを起動するための通常のfsckと魔法）。HAはライセンスされた機能であることに注意してください。
VMの失敗を軽減するために、ファイルサーバーのライトクローンを作成します。これには、起動に必要な最小限のクローンが含まれており、SAMBAを構成済みの状態で起動し、これを各ホストのローカルディスクに保存します。失敗したVMからデータドライブを追加し、電源を入れるのを待っています。
これにより、SAN障害が発生した場合に、追加のオプションを購入する場合としない場合があります。最良のシナリオでは、データストレージにfsckまたはその他の修復が必要になりますが、少なくともそうする必要はありません。 VMを上に修正、再構築、または構成します。最悪の場合、データが失われ、テープに戻る必要があります...しかし、とにかくすでにその状態にありました。
ねえマット。仮想化ソリューションを使用する場合、ソリューションをスライスする方法はたくさんあります。まず、Raw LUN（RDM）とVMDKのパフォーマンスを示すベンチマークが多数あり、通常、その差はごくわずかであることが示されています。 RDMで注意すべき点：特定のクラスタリング状況でのみ、RDM（MSクラスタリング）を使用する必要があります。 RDMには2TBの制限がありますが、LVMを使用してこの制限を回避できます。 RDMは、VMFSに使用するためにESXiにLUNを提供し、それにvmdkを配置するよりも、追跡するのが「困難」です。 VMDK（前述のとおり）には、svMotion、Snapshots（pRDMのスナップショットを作成できない）という優れた利点がいくつかあります。
無料のESXiを実行している場合は、次のような状況になります。まず、すべてのデータはVMFSLUNSのvmdkファイルにあります。 2つのVMをセットアップし、IPとサービスのフェイルオーバーにハートビートを使用します。ハートビートはサービスIPをシフトオーバーし、必要に応じてデータLUNをアンマウント/マウントするスクリプトを処理できます。 VMware Remote CLIのスクリプトを作成して、フェンシングのために「ダウン」VMの電源がオフになるようにすることもできます。ハートビートを使用すると、システム間で直接調整することで、データにアクセスする/同じサービスを実行するリスクがあります。ここで重要なのは、データLUNのマウント/アンマウントとサービスの起動/シャットダウンが、通常の初期化メカニズムではなく、ハートビートによって処理されるようにすることです。
代替のフェイルオーバーは、監視システムを介して実行される場合があります。ダウンしたホストを検出すると、VMware Remote CLIを使用して（安全のために）電源をオフにしてから、バックアップVMの電源をオンにすることができます。この状況では、フェイルバックはかなり手動です。
私の「小さな」環境では、VMDKが破損するのを見たことがありません。また、2つ以上のESX（i）ホストまたは12個のVMがある場合は、vCenterを使用してすべてを追跡できるようにする必要があることにも気づきました。 Essential/Plusパッケージの中には、メリットを考慮するとそれほどコストがかからないものもあります。
マット、私はVMwareを使用していませんが、Xenでは常に「RAW」を使用しています。負荷が軽いVMがいくつかあるだけで、パフォーマンスに大きな違いが見られるとは思えません。しかし、すべてのゲストが同じファイルシステム上にある場合、ますます多くのゲストにアクセスし始めると、キューの深さの問題が発生します。これは、NFSでバックアップされたストレージに特に当てはまります。 NFSサーバーに問題があるほどではありませんが、ほとんどのNFSクライアントの実装は問題があります。
冗長性（失敗なし）を探している場合、vmdkを同期する良い方法がわかりません。ただし、ブロックデバイスを使用する場合でも、DRBDを使用して、複製する必要がある/必要なVMのみを複製する可能性があります。
私はvmdkイメージに固執します。将来、vmotionの使用に移行した場合に備えて、予算を確保できるかどうかはわかりません。
マシンがクラスター化されていない場合、私が懸念している限り、それらを管理する最善の方法は、負荷をできるだけ均等に分散することです。私は3つの非クラスター化2950を持っており、最も重要なvmsからの負荷はそれぞれで可能な限り1/3です。理論的には、一度に複数のボックスを失う可能性は低いので、少なくとも2/3は影響を受けずに動作し続けることができます。
パワーの観点からは、マシンをできるだけ100％近くまでロードし、他のマシンの電源をオフにする方がおそらく効率的ですが、私にはすべての卵を1つのバスケットに入れているようです。
私は自分自身をこれの専門家とは呼びません、それは私がしていることです。
「物理サーバーに戻る予定はありますか」と自問する必要があると思います。
答えが多分なら、多分あなたはRDMに固執するべきです。 RDMを備えたESXiでは、ファイバーが機能するために何かを購入する必要があります（esxiでは100％確実ではありません）。
RDMを使用して物理サーバーからESX（4.0）にすばやく移動したマシンがいくつかありました。 LinuxマシンとWindowsマシンが混在していました（両方のプラットフォームで非常に簡単です）。古いFBSDカーネルがこれをサポートしていないため、RDMを使用できない物理サーバー上で実行中のレガシーFreeBSD（6.0以前）がまだいくつかあります。迅速で、LUNをポイントしてVMWareツールをインストールする以外に何もする必要がありませんでした。脳死は簡単です..コンバーターも大騒ぎもありません...
もう1つ自問すべきことは、「VMWareのどの機能を使用したいのか」です。
それに対するあなたの答えによっては、VMDK以外に選択肢がないかもしれません。スナップショットにSANを使用し、たとえばvmwareを使用する必要がない場合。
これまでに遭遇したことについていくつかのメモを共有します。VmotionはRDMとVMDKで同等に機能しますが、一方、ストレージVmotionは非RDMでのみ正しく機能し、Vmotionストレージを使用してRDMからVMDKに移行しようとするとうまくいきません。コンバーターを使用するだけです。ほとんどのLinuxディストリビューションには、ツールのインストールが問題にならないオープンソースのvmwareツールパッケージがあります。バックアップアプリは非常にうまく機能し、vmwareは含まれていませんが、私たちが望むほど多くのことをしていません。 vmwareからクラスを受講することを強くお勧めします。私が取ったのは1週間で、すべてのペニーの価値がありましたVMWareサポートは素晴らしいです..サポート契約を取得し、電話をかけなければならない場合、彼らは最高です..私を助けてくれる人に（多くのメニューに.. ）、しかし、私がそれらを取得すると、それらは常に高速で信頼性の高いサポートを備えています。