VMware内のSQLServer 2008R2クラスタリング
私は新しいWindows2008 R2/SQL Server R2 HAクラスターに取り組んでおり、これをVMware ESX 5内で実行することを計画しています。ESX内でSQLクラスタリングを使用することについてさまざまな見解を読んだり聞いたりしましたが、他の人は問題ないと言っているようです。しない。専用ホストSANを実行し、コアアプリのSQLが非常に重いため、このためのネットワークを構築します。これが良いアイデアか悪いアイデアかについて、人々の意見を聞いてみたいと思います。
現在、本番環境でこれを行っていますが、問題はほとんどありません。
VMwareには、仮想MSCS構成に関するKB記事があります。
VSphereバージョンの適切なクラスタリングガイドPDFを確認してください。特に、ホスト間でクラスタリングする場合は、サポートマトリックスに注意してください。次の点に注意してください。
- VMwareは、MSCS内での使用についてFC共有ストレージのみをサポートしています（MicrosoftはゲストiSCSIイニシエーターを介して接続した場合にiSCSIをサポートする場合があります。MSサポートの観点からはこれについては肯定的ではありません）
- 物理ホスト間でクラスタリングする場合、共有仮想ディスクはサポートされません。 RDMを使用する必要があります（物理モードをお勧めします）
- MSCSクラスター内のノードをvMotionすることはできません（したがって、クラスター構成でこれらのVMのDRSを無効にします）
ガイド内の他のセットアップ制限にも注意してください。彼らの指示に従えば、設定はかなり簡単です。
このサイトは事実に関するものであり、意見ではありませんが、本番環境ではなく、常にやりたいことを正確に実行します。そのためにスズを使用しますが、テスト/開発環境では非常にうまく機能します。それを行うにはいくつかの異なる方法があります。FCベースのRDMを使用しますが、他の方法もあります。どちらの方法でも、最初のセットアップは難しい場合がありますが、リソースが制限されすぎない限り、機能し続けます。パフォーマンスも良好です。お役に立てれば。
これは、かなり単純なWebサイトをバックアップする使用頻度の低いdbインスタンスに対して行いました。私が抱えていた主な問題は、iSCSI設定をすべて正しく取得することでした。最終的にvSphere iSCSIクライアントを使用し、LUNをVMにマッピングするだけでした。
とは言うものの、新しい年にいくつかの新しいアプリケーションが導入され、データベースのIO要件が大幅に増加します。したがって、クラスターを仮想化から移動します。環境と、HW iSCSIカードまたはFC（まだ決定/コストがかかっていない）のいずれかを備えた専用ハードウェア上。仮想化はいくつかの大きな利点をもたらしますが、特にパフォーマンスに関して、複雑な層全体をもたらす可能性もあります。
キット/予算があり、それが本番インスタンスである場合、非常に負荷の軽いSQLクラスター以外のものをハードウェア上で直接実行します。開発/テスト環境の場合、クラスターの側面をスキップして、単一のSQLインスタンスをVMとして実行する傾向があります。