MSFC

Hyper-Vクラスタ上の高可用性のホストが開始中で1%のままフリーズしてしまいました。数時間放おっておいても状況が変化しません。 200台強あるうちの1台だけの現象です。 Hyper-V: Virtual Machines Freeze at 10% When Starting Up - Premier Field Engineering - Site Home - TechNet Blogs http://blogs.technet.com/b/mspfe/archive/2013/03/18/hyper-v-virtual-machines-freeze-at-10-when-starting-up.aspx なるほど。ネットワークアダプターの構成がおかしいのが原因であるようです。 高可用性の仮想マシンなので、フェールオーバーしようと再起動しようとクラスタが何度でもサーバーをすぐに起動させようとしてしまうので、スタートアップの優先順位を「自動開始しない」に設定したうえでしばらく待っていると「失敗」となり、設定変更～正常起動が行えました。

メンテナンス中にトラブルがあってかなり無駄に時間を使ってしまったので反省も兼ねてメモしておきます。 Hyper-Vクラスタで予備ノードが無いテスト系のノードにhotfixを適用して再起動する作業をしていました。再起動を実行した所…Remote Desktopからはすぐにログオフさせられたもののいつまでたってもシャットダウンしない状況になってしまいました。結局起きていたことは以下の様なことでした。 - Hyper-Vのホストなので、稼働していた仮想マシンの状態を保存 - iSCSI接続に障害を併発しており(そもそもその対応のメンテナンスだったのですが)、ディスクへの書き込みパフォーマンスが出ていなくて時間がかかっていた - さらにディスクが見えなくなりHyper-V Virtual Machine Managementサービスが異常停止 - Hyper-V Virtual Machine Managementサービスはしばらくして自動的に開始 - その間にClusterサービスが停止中のままになる(デッドロック?) 結局Remote PowerShellでは接続できたので、Enter-PSSessionで該当ノードに入り、clusterサービスの実体であるclussvcを殺すことで再起動処理が先に進みました。 get-process clussvc | kill シャットダウンプロセスが進まない場合には、停止処理中で止まってしまっているサービスを見つけてそのプロセスを切るというのはすぐに思いつけないといけないですね。今日はこれに気がつくまでに1時間くらいかかってしまいました。反省です。また、そもそもHyper-Vクラスタでは予備ノードが無いとメンテナンスが非常に厳しいですね。

先日SCVMMで論理ネットワークとVLAN、VMネットワークを改めて勉強し、複数のVLANに対応するように構成を変更しました。あらかたうまく行ったのですが、しばらく時間がたってからなぜか1台の仮想サーバーのみ「サポートされていないクラスター構成」となってしまいました。 実際の影響としては以下の状態でした。 - 対象サーバーにネットワーク経由でアクセス出来ない(pingも通らない) - SCVMM上でも何も操作できない コンソールでの接続もできない - 修復を実行しても直らない - 構成変更をしようとしてもできない PowerShellでRepair-VMを-Forceオプション付きで実行しても修復されず、SCVMMからは手がでない状態になってしまいました。 直接の原因として該当しそうなのは以下のエラーです。 エラー (13921) 高可用性バーチャル マシン (XXXXXXX) は、正しく構成されていないネットワーク アダプターがあるため、 サポートされません。 推奨される操作 すべての仮想ネットワーク アダプターが、高可用性仮想スイッチに接続または切断されていることを確認してください。 そして構成上も特におかしいところも見当たりません。ネットマーク周りの設定変更を行いましたし、ネットワークがおかしいというエラーも出ていますが、他のサーバーは稼働しているので特別このサーバーだけがこのような状態になる理由もよくわかりません。 仕方がないのでネット上を検索して回った所以下に似たような状況の方が。 - [Unsupported cluster configuration SCVMM 2012](http://social.technet.microsoft.com/Forums/en-US/virtualmachinemanager/thread/d9b6961c-a5fb-40c6-9e1d-32a35907af34) フェールオーバークラスタから移動したら直ってしまったということなので、真似をしてみました。 結果、ノードを移動することでエラーは解消されました。 これでとりあえず問題は回避かと思いましたが、この状態でも外部と通信ができませんでした。結局よくNICの状態を見てみたところ、2つある仮想NICの接続先が入れ替わってしまっていることがわかりました。あるいは仮想NICが入れ替わった…のかもしれません。これはipconfig /allで表示されるMACアドレスとSCVMM側で仮想マシンのハードウェア構成から確認できるMACアドレスを突き合わせることで判明しました。 結局、仮想NICのVMネットワークへの接続を切り替える(入れ替える)ことでネットワーク接続も復旧しました。 なぜこの1台だけでこの現象が発生したのかはわかりませんが - フェールオーバークラスタマネージャーから操作して逃げる - MACアドレスで仮想マシン上のNICとハードウェア構成のNICを突き合わせる というノウハウが得られたのでよしとします。同じような現象が発生した際の参考になれば幸いです。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCVMMにて「サポートされていないクラスター構成」となり何もできなくなる | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/05/28/scvmm%E3%81%AB%E3%81%A6%E3%80%8C%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%83%BC%E6%A7%8B%E6%88%90%E3%80%8D/)

ウイルス対策ソフトはどのサーバーにも基本的には導入されると思います。その上で必要な箇所に除外設定を行うことになります。主要なサーバー製品/役割の除外設定を集めてみました。まだ全部は集まっていませんので情報があったら追記していきます。 SCOM 2012 管理サーバー - ~:\Program Files\System Center 2012\Operations Manager\Server\Health Service State\Health Service Store - *.EDB, *.CHK, *.LOG SCOM 2012 エージェント - %ProgramFiles%\System Center Operations Manager\Agent\Health Service State\Health Service Store DPM 2012 ・\XSD フォルダー ・\Temp\MTA フォルダー ・%ProgramFiles%\Microsoft Data Protection Manager\DPM\bin フォルダーの dpmra.exe ・%ProgramFiles%\Microsoft　DPM\DPM\Volumes\Replica フォルダー ・%windir%\Microsoft.net\Framework\v2.0.50727 フォルダーの csc.exe <SQL Server 2012 の場合> ・%ProgramFiles%\Microsoft SQL Server\MSSQL11 < インスタンス名 > \MSSQL\Binn フォルダーの SQLServr.exe ・%ProgramFiles%\Microsoft SQL Server\MSRS11 < インスタンス名 > \Reporting Services\ReportServer\Bin フォルダーの ReportingServicesService.exe ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SystemCenter2012 ウイルス対策ソフトの除外設定 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/25/systemcenter2012-%E3%82%A6%E3%82%A4%E3%83%AB%E3%82%B9%E5%AF%BE%E7%AD%96%E3%82%BD%E3%83%95%E3%83%88%E3%81%AE%E9%99%A4%E5%A4%96%E8%A8%AD%E5%AE%9A/)

今回はWindowsのクラスタ(MSFC(2008以降)、MSCS(2003より前))とMSDTCの関係について調べてみました。 MSDTCとは MSDTCは複数サーバーにまたがった処理を行う際に、不整合が起きないように複数サーバーの調整役を行ってくれるものです。特にデータベースが複数存在するときに全体の処理がきちんと終わったことを確認してから実際にデータ更新を反映させるような際に使われます。以下@ITの記事がイメージがわきやすいと思います。 - [第8回 テーブルアダプタでトランザクション － ＠IT](http://www.atmarkit.co.jp/fdotnet/vblab/vsdbprog_08/vsdbprog_08_03.html) - [第8回 テーブルアダプタでトランザクション － ＠IT](http://www.atmarkit.co.jp/fdotnet/vblab/vsdbprog_08/vsdbprog_08_04.html) サーバー管理屋さん的には動作するアプリケーションでMSDTCを利用するのであればきちんとMSDTCを動作させておいてあげる…という感じになります。特にSQL Serverをクラスタ化するような際にはきちんと考慮が必要ですね。(もちろんMSDTCを使わない処理しか行わないのであれば必要ないです。) Windows Server 2003(MSCS) - [The Microsoft support policy for the Microsoft Distributed Transaction Coordinator on clustered nodes](http://support.microsoft.com/kb/912374/en-us) The MSDTC is a cluster-aware application. You can configure the MSDTC as a clustered resource on clustered nodes. Microsoft only supports running the MSDTC on cluster nodes as a clustered resource. Microsoft does not support the MSDTC in a stand-alone configuration on cluster nodes. 上記では「MSDTCはクラスタ化可能な(cluster-aware)アプリケーションであり、クラスタノード上で構成されたクラスタ化されていないMSDTCはサポートしない」と書かれています。 ...