サーバーをSANに仮想化するためのベストプラクティスですか？

申し分なく、私は今までより少しだけSANを活用し始め、同時にESXiを活用したいと思います。

現在、単一エンクロージャEMC AX4-5 FCストレージアレイに接続されたDell PowerEdge 1955ブレードのアレイを持っています。私は本質的にDASとしてSANを使用しています。SANには特定の物理マシンを指すLUNがあり、それらのマシンは何に対してもLUNを利用します（ほとんどの場合、ターゲットサーバーに応じてデータベースとSamba / NFS共有）。

複数の物理ファイルサーバーがあり、それぞれに適切な共有を提供するためのsamba構成セットアップがあります。RHCSが機能しないので、一度に1つのファイルサーバーのみがLUNをマウントします。ファイルサーバーが停止した場合、手動でフェンスし（navisphereユーティリティを使用してドライブをアンマウントおよび表示解除するか、DRACを使用して電源を切断します）、navisphereユーティリティを使用して、提示されたLUNを次の候補（その後、Apacheと他のデーモンを起動します）。すべて手作業で、今すぐ。

Ferris Buellerがクラリネットを演奏しているように感じます。レッスンはありませんでした！

とにかく、私は改善しようとしています。私がしたいのは、物理ホストにESXiをインストールし、2つのファイルサーバーイメージを保持するLUNを作成することです（一方が破損/フバーになった場合）、一方はアクティブになり、他方はスタンバイになります。少なくともこの方法では、自動化を改善しません（すぐに「アクティブな」サーバーを切り替えるスクリプトを作成することになります）が、柔軟性を追加しているように感じます。 ESXiホストが他のVMを保持するため、現在のようにハードウェアが無駄になりません。

私の質問は：

1）私の計画はどれほど愚かですか？

2）実際の実装に関しては、LUNに通常のvmdkイメージを作成する必要がありますか、それとも「raw」パーティションを提供する必要があります（ESXiで可能であれば）。

3）非クラスター化ファイルサーバーを使用する「良い」方法はありますか？

あなたの計画は簡単ではありません。いつものように、達成しようとしていることとデータの保護方法に基づいて、これを攻撃する方法はいくつかあります。

最初に、「未加工デバイスマッピング」を使用してVMに未加工LUNを提示できます。これをする：

• ESXiホスト（または、クラスタリング/ HAを使用する場合はホストグループ）にLUNを提示します
• ディスクをVMに追加し、Rawデバイスマッピングを選択して、LUNをポイントします
• VM内のSCSIバスを再スキャンします
• fdisk、通常のディスクのように、マウントしてfstabに追加します。

利点：設定が速く、使いやすく、簡単で、V2Pを必要とする場合にディスクを物理ホストに表すことができます

欠点：物理互換モードと仮想互換モードのどちらを使用するかによって、VMwareベースのスナップショット/ロールバックオプションが失われる場合があります

別のオプションは、LUNにVMFSを作成してデータストアを作成し、そのデータストアにあるVMにVMDKディスクを追加することです。

• 利点：使用するライセンスを購入した場合、Storage vMotionに対応しています。これにより、LUNとSANの間でのVMDKディスクのホットマイグレーションが可能になります。

どちらの場合も、VMwareやVMが障害時にファイルシステムを食い尽くした場合、同様のリスク状態にあります。1つは他のものより大幅に優れているわけではありませんが、使用できる回復オプションはまったく異なります。

必要がない限り、RDMを展開しません。VMDKとしての柔軟性をあまり買わないことに気付きました（そして、他のストレージ操作を実行するときにそれらを非実用的にするバグに噛まれました（修正されているため、そのリンクのRDMセクションを参照してください））

VMの場合、柔軟性を確保するには、ファイルサーバーのブートディスクをVMDKとしてSANに保存して、ホストに障害が発生した場合に他のホストでブートできるようにすることをお勧めします。VMwareのHA機能を使用すると、別のホストでのVMの起動は自動的に行われます（VMは電源が切断されたかのように2番目のホストで起動します。通常のサーバーの場合と同様に、通常のfsckと魔法を実行して）。HAはライセンスが必要な機能です。

VMの障害を緩和するために、ブートに必要な最低限の構成を含むファイルサーバーのライトクローンを構築し、SAMBAを構成済みの状態で起動して各ホストのローカルディスクに保存し、データドライブの追加を待機できますVMに障害が発生し、電源を入れます。

これにより、SANに障害が発生した場合に追加のオプションが購入される場合とされない場合があります。ベストケースのシナリオでは、データストレージにfsckまたはその他の修復が必要になりますが、少なくともVMを修正、再構築、または構成する必要はありません。最悪の場合、データを失い、テープに戻る必要がありますが、とにかくすでにその状態にありました。

vmdkのイメージに固執します。将来vMotionを使用する場合に備えて、予算を確保できるかどうかはわかりません。

マシンがクラスタ化されていない場合、私が懸念している限り、それらを管理する最良の方法は、可能な限り均等に負荷を分散させることです。3つの非クラスター化2950があり、最も重要なVMからの負荷が可能な限りそれぞれ1/3になります。理論的には、一度に複数のボックスを失う可能性は低いため、少なくとも2/3は影響を受けずに動作を継続できます。

電力の観点からは、できる限り100％近くまでマシンをロードし、他のマシンの電源をオフにする方が効率的かもしれませんが、すべての卵を1つのバスケットに入れているように思えます。

私はこれを自分の専門家とは呼ばないでしょう。

ちょっとマット。仮想化ソリューションを使用する場合、ソリューションをスライスする方法はたくさんあります。まず、Raw LUN（RDM）とVMDKのパフォーマンスを示す多くのベンチマークがありましたが、その差は通常、ごくわずかであることが示されています。RDMで注意すべきいくつかの事項：特定のクラスタリングの状況でのみRDM（MSクラスタリング）を使用する必要があります。RDMには2TBの制限がありますが、LVMを使用してこの制限を回避できます。RDMは、VMFSで使用するためにLUNをESXiに提供し、vmdkを配置するよりも、追跡するのが「困難」です。VMDK（前述のとおり）には、svMotion、スナップショット（pRDMのスナップショットはできません）など、いくつかの素晴らしい利点があります。

無料のESXiを実行している場合、次の方法で状況を解決できます。まず、すべてのデータはVMFS LUNSのvmdkファイルにあります。2つのVMをセットアップし、Heartbeatを使用してIPとサービスのフェールオーバーを行います。ハートビートはサービスIPを移行し、必要に応じてデータLUNをアンマウント/マウントするスクリプトを処理できます。いくつかのVMwareリモートCLIのスクリプトを作成して、「ダウン」したVMのフェンシングを確実にオフにすることもできます。システム間で直接調整するハートビートにより、データへのアクセスと同じサービスの実行の両方のリスクは非常に低くなります。ここで重要なのは、データLUNのマウント/アンマウントとサービスの起動/シャットダウンが、通常のinitメカニズムではなく、Heartbeatによって処理されることを確認することです。

別のフェールオーバーは、監視システムを介して実現できます。ダウンしたホストを検出すると、VMware Remote CLIを使用して電源をオフにし（安全のため）、バックアップvmの電源をオンにします。この状況では、フェールバックはかなり手作業です。

「小さな」環境では、VMDKが破損することはありません。また、2つ以上のESX（i）ホストまたは1ダース以上のVMがある場合は、vCenterを使用してすべてを追跡できるようにしたいということにも気付きました。Essential / Plusパッケージの一部は、利点を考慮してもそれほど高価ではありません。

マット、私はVMwareを使用していないことを知っていますが、Xenでは常に「RAW」を使用しています。わずかにロードされたVMがわずかしかないので、パフォーマンスの違いの多くがわかるとは思いません。しかし、すべてのゲストが同じファイルシステム上にある場合、ますます多くのゲストにアクセスし始めると、キューの深さの問題が発生します。これは、NFSでバックアップされたストレージに特に当てはまります。NFSサーバーに問題があるほどではありませんが、ほとんどのNFSクライアントの実装には問題があります。

冗長性（障害）を探している場合、vmdksを同期する良い方法がわかりません。ただし、ブロックデバイスを使用する場合、DRBDを使用して、必要なVMのみを複製するか、複製する必要があります。

「物理サーバーに戻る予定はありますか」と自問するべきだと思います

もし答えが多分なら、おそらく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で同じように機能しますが、Storage Vmotionは非RDMでのみ正しく動作し、Vmotionストレージを使用してRDMからVMDKに移行しようとすると、コンバータを使用するだけです。ほとんどのLinuxディストリビューションには、ツールのインストールを問題にしないオープンソースのvmwareツールパッケージがあります。バックアップアプリケーションは非常に良好に機能し、vmwareを使用しませんが、必要な処理は行いません。vmwareからクラスを取得することを強くお勧めします。私が取ったのは1週間で、すべてのペニーVMWareサポートに値するものでした。サポート契約を取得し、電話をかけなければならない場合は、最高です。 ）、しかし、私はそれらを手に入れたら、常に高速で信頼性の高いサポートが提供されます。