今回のシステムをもう少し細かく見てみます(図25-3)。
FCI構成としている今回のシステムでは、稼働中ノードのネットワークカードが仮に2枚同時に壊れたとしても、システムの完全停止にはなりません。他方のノードにフェイルオーバーすればサービスを継続できるからです。
しかし、ディスクは各ノードで共有しています。ディスクへの全アクセス経路やディスク装置の物理部品が故障する、さらに、RAIDで冗長化されているディスクが2本同時に壊れるといったような多重障害が発生することも現実にはあり得ます。このように、FCI構成でも防げない障害は幾つか存在します。
その対策には、以下の方法が推奨されます。
対応策 | 特徴 | 実装/運用の難易度 | 復旧時間 |
---|---|---|---|
(1)バックアップのリストアを行う | 共有ディスクの破損に向けた対策として最もシンプルな方法 採取したバックアップを共有ディスク外に持つことで、障害発生後にディスクを修理した後にリストアすることで復旧が可能。ただし、ディスク復旧とリストアには一定の時間を要するので、場合によっては数日の復旧期間を見込む必要がある |
低 | 長 |
(2)ログ配布機能を利用する | トランザクションログを他のサーバに転送することで、データの複製を別サーバに持っておける機能であるログ配布を利用する方法 課題は、ログ配布のために別サーバを用意する必要があり、ログ配布用のジョブが動作するので、設計や運用にやや手間が掛かること。業務停止期間は運用次第だが、1日以内から1日程度 |
中 | 中 |
(3)可用性グループを利用する | Always Onのもう1つの機能である「可用性グループ(AG)」を利用することで、遠隔地にデータベースのレプリカを持つ方法 FCIと併用可能だが、その場合はAGの自動フェイルオーバーが動作しない仕様であるため、FCIとAGでどんな障害に対応するかをあらかじめ認識しておく必要がある。ただ、業務停止期間は数分〜数時間程度まで短縮できる |
高 | 短 |
例えば(2)のログ配布機能は、プライマリーサーバでトランザクションログのバックアップを行い、それをセカンダリーサーバへ転送する仕組みによって、セカンダリーサーバでデータベースの複製を持ちます(図25-4)。
基本的には、FCIでも十分可用性を高めることが可能です。しかし、それだけではSLA(Service Level Agreement)が満たされないシステムならば、それに加えてログ配布や可用性グループの構成を考察することも必要となります。
例えば、重要な全社システムやDR(Disaster Recovery:災害復旧)サイトの運用などが挙げられます。SLAとは、サービス利用者と結ぶ契約において満たすべきサービス水準/サービス品質保証などの基準値のことを指します。参考として、例えば「SLA 99.95%/月間99.95%の可用性を保証する」とする契約ならば、月間停止時間を22分までに抑えなければなりません。
高い可用性を実現する=サービスを止めないシステムを構築し、運用することは、技術者として極めて重要な視点です。可用性のレベルを高めた分、コストも相応に掛かってきますが、何よりその対策がこの先のビジネスの発展に正しくつながることを考慮しなければなりません。システムの規模や重要性に応じて、DRソリューションなどを導入した方がよいと判断される場合には、迅速に再設計/構成変更を考察し、実行することが必要です。なお、SLAの現実的な落としどころは、可能な限り設計段階で検討しておくことが望ましいといえます。
ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP Data Platform(2011〜)。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、2016年現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。
ユニアデックス株式会社所属。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
Copyright © ITmedia, Inc. All Rights Reserved.