記憶域スペースダイレクト(S2D)を使用するSQLフェールオーバークラスターインスタンス(FCI)をホストする2016 Windows Serverフェールオーバークラスター(WSFC)で問題が発生しました。各サーバーで、最初の作成が成功した後、S2Dは、未使用のRAIDボリュームをストレージプールに自動的に追加しました(ただし、S2DはRAIDボリューム上に作成できず、レイドされていないディスクを要求します)。今、それは壊れています-私が理解できる限り-それは正確です。その結果、仮想ディスクがオフラインになり、クラスター全体が停止します。クラスターネットワークリソースが不足しているため、オンラインに戻りません。問題のディスクは廃止することはできますが、削除することはできません。仮想ディスクの修復が実行されず、クラスター互換性テストで無効な構成が要求されます。
これは新しいセットアップです。そのため、仮想ディスク、クラスター、またはサーバーを削除して、最初からやり直すことができます。しかし、生産性を高める前に、私は確認する必要があります。これは二度と起こりません。サポートされていないディスクを不必要に誤って追加するだけで、仮想膝でシステム自体をクラッシュして停止させるシステムは、私たちが展開できるプラットフォームではありません。だから私は主に、今それを修復するのではなく、これが起こらないようにする方法が必要です。私の推測では、S2Dセットアップが作成されたディスクよりも多くのディスクを取得しないようにすると、うまくいくと思います。実際のディスク交換中に手動で操作する可能性のあるコストは、クラスターにとっては無視できるほどのものです。しかし、これまでにドキュメントを参照したように、それを制御する方法は見つかりません。何か不足している場合を除き、Set-StoragePool、Set-VirtualDisk、Set-Volumeのいずれも、その拡張にパラメーターを提供していません。
ヘルプやヒントをいただければ幸いです。
上記の詳細は次のとおりです。2台のHPE DL380 Gen9サーバーマシンが、RDMA対応の10GBイーサネットと1GBを介してクライアントネットに二重に接続されています。それぞれにRAIDコントローラーHPが搭載されています???と単純なHBAコントローラーHP ??? (S2Dが絶対に必要であり、直接接続されたレイドされていないディスクでのみ機能するため)。ストレージ構成は、RAIDコントローラーのOS-RAID、RAIDコントローラーのFiles-RAID、およびS2D用のHBAに直接接続されたディスクのセットで構成されます。
OS-RAIDに2つのWindows Servers 2016データセンターエディションをセットアップし、WSFC機能をインストールし、実行してS2Dオプションを含むクラスター互換性テストに合格し、ストレージなしでクラスターを作成し、ファイル共有監視(別のマシン上)を追加し、S2Dを有効にしましたすべてのレイドされていないディスクで自動的に構成されるストレージプール上で、そのプールの上にミラータイプの仮想ディスクを作成し、NTFSをファイルシステムとして使用しました。これは、FS SQL FCIインストールに最適です。
次に、SQL 2016スタンダードエディションをFCIとしてそのクラスターにインストールし、データベースをインポートして、すべてテストしました。すべてが大丈夫でした。データベースはそこにあり、かつてないほど高速でした。自動フェイルオーバーだけでなく強制も簡単でした。すべてが良さそうでした。
翌日、残りのFiles-RAIDを利用しようとしました。事前構成が気に入らなかったため、最初にRAIDレベルを変更しました。事前構成されたRAIDボリュームを削除して新しいボリュームを(各サーバーで)構築した直後に、クラスターがダウンしていることが検出されました。私がこれまでに理解できたことから、その間に事前構成されたFiles-RAIDボリュームが自動的にプールに追加され、削除したばかりなので、プールから失われました。チェックしたところ、新しいFiles-RAIDが見つかりましたが、まだ作成されていて、プールの物理ドライブとしても表示されています。そのため、プールには各サーバーに2つのRAIDボリュームが含まれ、そのうちの1つは存在しませんでした。これらのボリューム(ディスクではない)は、HBA上の実際の物理ディスクと共にGet-PhysicalDiskによって一覧表示されます。これが定期的かどうかはわかりません。プール自体はまだオンラインであり、不満はありません。ただし、仮想ディスクはディスクがないために単に劣化しているのではなく、完全にオフラインです(その結果、クラスター全体も同様です)。
それらの物理ディスク(つまり、実際にはRAIDボリュームであるもの)を廃棄することができましたが、それらには廃棄済みのマークが付けられています。しかし、それらはまだプールにあり、今すぐ削除することはできません。削除しようとすると失敗します。 Repair-VirtualDiskは、残りのディスクだけで仮想ディスクを適切な状態に再構築する必要があります(私はこれを行った: https://social.technet.Microsoft.com/Forums/windows/en-US/dbbf317b- 80d2-4992-b5a9-20b83526a9c2/storage-spaces-remove-physical-disk?forum = winserver8gen )ですが、このジョブはすぐに終了し、「成功」します。もちろん影響はありません。
仮想ディスクをオンラインに切り替えようとしても失敗し、ネットワーク化されたクラスターリソースが利用できないことが示されます。私が理解している限り、不足しているディスクはクラスターリソースではないため、これは(利用可能な)ストレージプールのみを参照できます。プールには修正するエラーは表示されません。クラスター互換性テストを実行すると、クラスターに適していない構成が要求されます。
もう1インチぐらつく可能性のある部分は残っていません。全体が行き詰まっているようです。実行中のWSFCがそのように機能しないようにする方法についてのアイデアはありますか?
特に啓蒙的なエラーメッセージは表示されませんでした。また、すべてのメッセージを投稿してページを爆撃したくありませんでした。誰かが具体的な詳細を知りたければ、私に知らせてください。
皆さん、ありがとうございました!
カルステン
はい、自動プーリング動作を無効にすることができます。エクスペリエンスはすばらしいものではありませんが、確かに実行可能でサポートされています。設定名とコマンドレット構文の例は、この公開ドキュメントの設定セクションにあります。
https://technet.Microsoft.com/en-us/windows-server-docs/failover-clustering/health-service-overview
基本的に、これを管理者として実行します。
Get-StorageSubSystem Cluster * | Set-StorageHealthSetting -Name "System.Storage.PhysicalDisk.AutoPool.Enabled" -Value False
お役に立てれば! -Cosmos(@cosmosdarwin)、Microsoft PM
この問題を見つけた回避策は、RAIDボリュームまたはディスクのバスタイプを、サポートされているタイプからサポートされていないタイプに変更することです。
デバイスマネージャーからコントローラードライバーを識別し、レジストリに移動して、以下の場所でドライバー名を見つける必要があります。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SmartPqi\Parameters
私の場合、SASに対応するレジストリキーをRAIDに変更しました
"BusType"= 0x00000008(RAID)(0x0000000aの代わり)(SAS)
マシンを再起動します
この変更後、クラスター化された記憶域スペースではなく、Windows記憶域サブシステムに記憶域プールを配置できます
このタイプの回避策を適用する場合は、検証済みのソリューションではなく、運用環境を高いリスクにさらす可能性があるため、注意してください。