FCI構成としていたにもかかわらず、SQL Serverが立ち上がらなくなった（フェイルオーバートラブル）：SQL Serverトラブルシューティング（32）（2/2 ページ）

解決方法

　今回のシステムをもう少し細かく見てみます（図25-3）。

図25-3　今回障害が起きたシステムの構成図。構成要素は二重化されているが、ディスクは各ノードで共有している

　FCI構成としている今回のシステムでは、稼働中ノードのネットワークカードが仮に2枚同時に壊れたとしても、システムの完全停止にはなりません。他方のノードにフェイルオーバーすればサービスを継続できるからです。

　しかし、ディスクは各ノードで共有しています。ディスクへの全アクセス経路やディスク装置の物理部品が故障する、さらに、RAIDで冗長化されているディスクが2本同時に壊れるといったような多重障害が発生することも現実にはあり得ます。このように、FCI構成でも防げない障害は幾つか存在します。

　その対策には、以下の方法が推奨されます。

　例えば（2）のログ配布機能は、プライマリーサーバでトランザクションログのバックアップを行い、それをセカンダリーサーバへ転送する仕組みによって、セカンダリーサーバでデータベースの複製を持ちます（図25-4）。

図25-4　SQL Serverの機能であるログ配布の概念図

　基本的には、FCIでも十分可用性を高めることが可能です。しかし、それだけではSLA（Service Level Agreement）が満たされないシステムならば、それに加えてログ配布や可用性グループの構成を考察することも必要となります。

　例えば、重要な全社システムやDR（Disaster Recovery：災害復旧）サイトの運用などが挙げられます。SLAとは、サービス利用者と結ぶ契約において満たすべきサービス水準／サービス品質保証などの基準値のことを指します。参考として、例えば「SLA 99.95％／月間99.95％の可用性を保証する」とする契約ならば、月間停止時間を22分までに抑えなければなりません。

　高い可用性を実現する＝サービスを止めないシステムを構築し、運用することは、技術者として極めて重要な視点です。可用性のレベルを高めた分、コストも相応に掛かってきますが、何よりその対策がこの先のビジネスの発展に正しくつながることを考慮しなければなりません。システムの規模や重要性に応じて、DRソリューションなどを導入した方がよいと判断される場合には、迅速に再設計／構成変更を考察し、実行することが必要です。なお、SLAの現実的な落としどころは、可能な限り設計段階で検討しておくことが望ましいといえます。