高可用性と災害復旧の概念download.microsoft.com/download/6/b/e/6be0c3f3-2991-4766... ·...

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド

執筆者 LeRoy Tuttle Jr (Microsoft)

寄稿者 Cephas Lin (Microsoft)Justin Erickson (Microsoft)Lindsey Allen (Microsoft)Min He (Microsoft)Sanjay Mishra (Microsoft)

校閲者 Alexei Khalyako (Microsoft)Allan Hirt (SQLHA)Ayad Shammout (Caregroup)Benjamin Wright-Jones (Microsoft)Charles Matthews (Microsoft)David P Smith (ServiceU)Juergen Thomas (Microsoft)Kevin Farlee (Microsoft)Shahryar G Hashemi (Motricity)Wolfgang Kutschera (Bwin Party)

発行日 2012 年 1 月

適用対象 SQL Server 2012

概要このホワイトペーパーではSQL Server 2012 の AlwaysOn による高可用性災害復旧ソリューションを使用して予定されたダウンタイムや予定外のダウンタイムを短縮したりアプリケーションの可用性を最大限に高めたりデータを保護したりする方法について説明します

本書の主な目的はビジネス関係者や技術上の意思決定者システム設計者インフラストラクチャエンジニアデータベース管理者などがこの問題について議論する際の拠りどころとなる一般的なコンテキストを確立することです

主に次の 2 つの内容について取り上げます

高可用性と災害復旧の概念高可用性データベース環境に関するビジネス目標の計画管理測定についてそれぞれの利点や課題を簡単に説明しますその後SQL Server 2012 AlwaysOn および Windows Server のソリューションでサポートされる高可用性と災害復旧の機能について概説します

SQL Server AlwaysOn の保護レイヤーSQL Server AlwaysOn のソリューションで提供される保護レイヤーの主な機能それらを使用する理由および依存関係について詳細に説明します

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド i

インフラストラクチャの可用性SQL Server インスタンスレベルの保護データベースレベルの保護およびデータ層アプリケーションの機能について解説します

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド ii

著作権

このドキュメントは現状有姿で提供されますこのドキュメントに記載されている情報や見解 (URL 等のインターネット Web サイトに関する情報を含む) は将来予告なしに変更されることがありますお客様はその使用に関するリスクを負うものとします

ここで使用される例は架空のものであり説明のためだけに使用されます実在するものとは一切関係ありません

このドキュメントはMicrosoft 製品の無体財産権に関する法的な権利をお客さまに許諾するものではありません内部的な参照目的に限りこのドキュメントを複製して使用することができます

copy 2012 Microsoft All rights reserved

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド iii

目次高可用性と災害復旧の概念1

高可用性について1

予定されたダウンタイムと予定外のダウンタイム2

段階的な可用性2

ダウンタイムの定量化3

復旧目標3

ROI または機会費用の正当化4

可用性の健全度の監視4

災害復旧の計画5

概要 Microsoft SQL Server 2012 での高可用性5

SQL Server AlwaysOn6

計画的なダウンタイムの大幅な削減6

アイドル状態のハードウェアをなくしてコスト効率とパフォーマンスを向上7

簡単な配置と管理7

RPO と RTO の機能比較7

SQL Server AlwaysOn の保護レイヤー8

インフラストラクチャの可用性9

Windows オペレーティングシステム9

Windows Server フェールオーバークラスタリング10

WSFC のクラスター検証ウィザード13

WSFC クォーラムモードと投票の構成14

WSFC の強制クォーラムによる災害復旧17

SQL Server インスタンスレベルでの保護19

可用性の向上 ndash SQL Server インスタンス19

AlwaysOn フェールオーバークラスターインスタンス20

データベースの可用性23

AlwaysOn 可用性グループ23

可用性グループのフェールオーバー25

可用性グループリスナー26

可用性の向上 ndash データベース28

クライアント接続の推奨事項29

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド iv

結論31

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド v

高可用性と災害復旧の概念高可用性と災害復旧のソリューションのために最適なデータベーステクノロジを選択するにはRTO と RPO の計画管理測定に関連するビジネス上の利点課題および目的についてすべての関係者が理解を共有している必要があります

これらの概念を既に理解されている方は「概要 Microsoft SQL Server 2012 での高可用性」のセクションから読み始めてもかまいません

高可用性についてソフトウェアアプリケーションやサービスで高可用性は最終的にはエンドユーザーの体感や期待に基づいて計測されますダウンタイムが生じることでビジネスに与える影響には情報の損失物的損害生産性の低下機会費用契約上の損害信用の損失などさまざまな目に見える影響や目に見えない影響があります

高可用性ソリューションの主な目的はダウンタイムの影響を最小限に抑えるまたは少なくともある程度軽減することですそのための堅実な戦略の 1 つはビジネスプロセスやサービスレベル契約 (SLA) と技術的な機能やインフラストラクチャのコストとの間で最適なバランスを取ることです

プラットフォームの可用性の高さは契約に基づいてさらには顧客や関係者からの期待に応じて判断されますシステムの可用性は次の式で表すことができます

実際のアップタイム予定されたアップタイム

times100

可用性の値は業界ではよく 9 がいくつ並んでいるかによって表現されますそれによって年間の可能なアップタイムの長さ逆に言えばダウンタイムの長さがわかります

9 の個数可用性の割合年間合計ダウンタイム2 99 3 日15 時間3 999 8 時間45 分4 9999 52 分34 秒5 99999 5 分15 秒

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド 1

予定されたダウンタイムと予定外のダウンタイムシステムの停止には予測または計画されたものと予定外の障害によって生じるものとがありますダウンタイムは適切に管理されているのならば否定的に考える必要はありません予測可能なダウンタイムには主に次の 2 種類があります

計画的なメンテナンスあらかじめ時間枠を予告したうえで計画されたメンテナンスタスクが行われますたとえばソフトウェア修正プログラムの適用ハードウェアのアップグレードパスワードの更新オフラインでのインデックス再作成データの読み込み災害復旧手順のリハーサルなどです操作手順を入念に準備することでダウンタイムを最小限に抑えデータ損失を防ぐことができます計画的なメンテナンス作業は予定外の停止によってさらに深刻な事態を招くのを防いだりそのような場合の被害を軽減したりするために必要な投資と考えることができます

予定外の停止システムインフラストラクチャまたはプロセスのレベルで障害が発生した場合ですそれらは予定外で制御できないものであったり予測可能ではあってもまず発生しないだろうと考えられたり影響は許容範囲だろうと考えられたりしたものです堅牢な高可用性ソリューションはそのような障害を検出し停止状態から自動的に復旧してフォールトトレランスを再確立することができます

高可用性に関するサービスレベル契約 (SLA) を規定するときには計画的なメンテナンス作業と予定外のダウンタイムの両方についてそれぞれ個別に主要業績評価指標 (KPI) を計算する必要がありますそうすることで計画的なメンテナンス作業への投資を予定外のダウンタイムを回避できた場合の利益と比較して検討することができます

段階的な可用性高可用性は100 か 0 かの問題として捉えるべきではありませんシステムが完全に停止するのではなく部分的に使用できるのであれば機能が制限されたりパフォーマンスが低下したりしてもエンドユーザーに許容される場合もよくあります可用性には次のようにさまざまな段階があります

読み取りのみ可能および操作の遅延メンテナンス期間中や災害復旧の処理中にデータを取得することはできても新しいワークフローやバックグラウンド処理は一時的に中断されたりキューに入れられたりする場合があります

データ待機時間とアプリケーションの応答時間大量のワークロードバックログの処理プラットフォームの部分的な障害などが原因で限りのあるハードウェアリソースが負荷過剰になったりサイズ不足になったりする場合がありますこれはユーザーエクスペリエンスに影響し生産性は低下しますが作業は続けることができます

部分的一時的または差し迫った障害アプリケーションロジックやハードウェアスタックが堅牢にできていればエラーが発生しても再試行や自己修正が行われますこのような場合エンドユーザーはデータの待ち時間やアプリケーションの応答時間を長く感じることがあります


部分的なエンドツーエンドの障害予定された停止または予定外の停止がソリューションスタックの垂直的なレイヤー (インフラストラクチャプラットフォームおよびアプリケーション) 内でまたは水平的な各種の機能コンポーネント間で整然と行われる場合がありますユーザーは影響を受ける機能またはコンポーネントに応じて部分的に操作が成功したりパフォーマンスの低下を感じたりします

これらの状況はそれぞれ完全な停止に至るまでの可用性の一段階であると同時に災害復旧フェーズの中間段階とも考えることができそれぞれの状況がどの程度許容できるかを判断する必要があります

ダウンタイムの定量化ダウンタイムが発生した場合にはそれが予定されたものであったか予定外のものであったかにかかわらずシステムをオンラインに戻しデータ損失を最小限に抑えることがビジネスとして第一の目標となりますダウンタイムが 1 分経過するごとに直接または間接のコストが刻々と増えていきます予定外のダウンタイムが発生したのであれば時間と労力を適切に配分しながら停止の理由を調査し現在のシステム状態を把握し復旧手順を決定する必要があります

どのような場合でも事前に決めておいた時間になったらビジネス上の意思決定を行う必要があります停止の原因調査やメンテナンス操作を中止してシステムをオンラインに戻すかどうか必要に応じてフォールトトレランスを再構築するかどうかなどを判断します

復旧目標データの冗長性は高可用性データベースソリューションの重要な要素の 1 つですプライマリ SQL Server インスタンスに対するトランザクションの操作は同期または非同期で1 つ以上のセカンダリインスタンスにも適用されます障害が発生すると処理中のトランザクションはロールバックされるかまたはデータ伝達の遅れのためにセカンダリインスタンスでは失われる可能性もあります

影響を見積もりながら機能の復旧にどれくらいの時間がかかるか最後のトランザクションを回復するためにどれくらいの遅延が生じるかという観点で次の復旧目標を設定します

目標復旧時間 (RTO)これはシステムが停止している時間の長さを意味します最初の目標は少なくとも読み取り専用の状態でシステムをオンラインに戻し障害について調査できるようにすることですただし最終的な目的は新しいトランザクションを実行できる状態まで完全にサービスを復元することです

目標復旧時点 (RPO)これは多くの場合どのくらいのデータ損失が許容されるかの基準として考えられます障害発生前に最後にコミットされたデータトランザクションと障害発生後に復元された最新のデータとの時間差や遅延が示されます実際に失われるデータの量は障害発生時のシステムのワークロード障害の種類および使用されている高可用性ソリューションの種類に応じて異なります


RTO と RPO の値はビジネスで許容できるダウンタイムとデータ損失の目安としてまた可用性が健全であるかどうかを監視する際の指標として使用します

ROI または機会費用の正当化ダウンタイムによって生じるビジネス上のコストには金銭的なコストだけでなく顧客からの信用も含まれますこれらのコストには時間の経過と共に発生するものもあれば停止期間中の特定の時点で発生するものもあります復旧時間とデータ復旧ポイントに基づいて停止のコストを見積もる以外にRTO および RPO の達成や停止自体の回避に必要なビジネスプロセスを考えたりインフラストラクチャへの投資を計算したりすることもできますこれらの投資の目的は次のようなものです

ダウンタイムの回避そもそも停止状態にならなければ復旧のコストをまとめて回避できますこの投資にはフォールトトレランスと冗長性のためのハードウェアまたはインフラストラクチャ各障害点を分離した分散ワークロード予防メンテナンスのための計画的なダウンタイムなどのコストが含まれます

復旧の自動化システム障害が発生した場合自動的で透過的な復元が行われればダウンタイムによるカスタマーエクスペリエンスへの影響を大幅に抑えることができます

リソース使用率セカンダリまたはスタンバイインフラストラクチャは障害に備えてアイドル状態にしておくことができますまた読み取り専用ワークロードのために利用したり利用可能なすべてのハードウェアにワークロードを分散してシステム全体のパフォーマンスを向上させたりもできます

RTO と RPO の目標実現に必要な可用性と復旧のための投資は予測されるダウンタイムのコストと組み合わせて時間の関数として表現し正当化することができますこれによって実際の停止中にダウンタイムの経過時間に基づいてコストベースの判断を行うことができます

可用性の健全度の監視運用上の観点からは実際の停止中に関連するすべての変数を考慮しリアルタイムで ROI または機会費用を計算しようとするべきではありません実際にはRPO の期待値に代わるものとしてスタンバイインスタンスのデータ遅延を監視します

停止の際根本的な原因の調査に費やす時間は制限し代わりに復旧環境の正常性の検証に集中する必要がありますその後詳細なシステムログとデータのセカンダリコピーに基づいて原因究明の分析を行います

災害復旧の計画


高可用性のための取り組みでは停止を回避するために何をするかが問題になりますが災害復旧のための取り組みでは停止後に高可用性を再構築するために何をするかが問題になります

できる限り実際に停止状態になる前に災害復旧の手順と役割分担を策定しておくようにします実行中の監視と警告に基づいて自動または手動のフェールオーバーと復旧計画を開始するかどうかは事前に決められた RTO および RPO のしきい値を考慮しつつ判断する必要があります災害復旧計画には次のようなものを含める必要があります

障害と復旧の適用範囲障害の場所や種類に応じてデータセンターレベルインフラストラクチャレベルプラットフォームレベルアプリケーションレベルワークロードレベルなどさまざまなレベルで修正措置が行われます

調査のための資料ベースラインと最新の監視の履歴システム警告イベントログ診断クエリなどを関係者がいつでも利用できるようにしておく必要があります

依存関係の調整アプリケーションスタック内でまたは関係者間でシステムやビジネスの依存関係を把握しておきます

デシジョンツリー繰り返し使用できるデシジョンツリーを事前に定義して検証しておきますこれにはロールの役割障害の優先順位RPO と RTO を実現するためのフェールオーバーの条件所定の復旧手順などを含めます

検証停止状態からの復旧手順を実行した後でシステムが通常の状態に戻ったことを検証するために何をしなければならないかを整理しておきます

文書化新しい担当者でも最低限の補助があれば復旧計画を実行できるように上記のすべての項目を詳細で明確な一連の文書として記録しておきますこのような文書は一般的にランブックまたはクックブックと呼ばれます

復旧のリハーサル定期的に災害復旧計画の演習を行いRTO のベースラインとなる期待値を確立しプライマリサイトと各災害復旧サイトでの本番運用のローテーションを検討します

概要 Microsoft SQL Server 2012 での高可用性要求される RPO と RTO を実現するには主要アプリケーションの継続的なアップタイムを確保することと予定外のダウンタイムや予定されたダウンタイム時に重要なデータを保護することが必要ですSQL Server では低コストで簡単にこれらの目標を実現できる一連の機能が用意されています

新しい AlwaysOn の機能について既によくご存じの方は「SQL Server AlwaysOn の保護レイヤー」のセクションに進んでより詳細な説明をご覧ください


SQL Server AlwaysOnAlwaysOn は高い統合性柔軟性およびコスト効率を特徴とした新しい高可用性災害復旧ソリューションですデータセンター内およびデータセンター間でデータとハードウェアの冗長性を実現しアプリケーションのフェールオーバー時間を短縮することでミッションクリティカルアプリケーションの可用性を高めますAlwaysOn は構成の柔軟性が高く既存のハードウェア投資を再利用できます

AlwaysOn ソリューションではデータベースレベルとインスタンスレベルの両方で可用性を構成するためにSQL Server 2012 の次の 2 つの主要な機能を利用できます

AlwaysOn 可用性グループSQL Server 2012 の新機能の 1 つですデータベースミラーリング機能の大幅な強化によってアプリケーションデータベースの可用性の確保に役立ちますログに基づくデータの移動によってデータ保護を実現し共有ディスクを使用せずにデータ損失をゼロにすることができます

複数のデータベースから成る論理グループの単位で自動および手動のフェールオーバーを実行できますまた最大で 4 つのセカンダリレプリカのサポート高速なアプリケーションフェールオーバー自動ページ修復など多彩なオプションが用意されています

AlwaysOn フェールオーバークラスターインスタンス (FCI)SQL Server フェールオーバークラスタリング機能を拡張し複数のサブネットにわたるマルチサイトクラスタリングをサポートしますこれにより異なるデータセンター間での SQL Server インスタンスのフェールオーバーが可能になりますインスタンスのフェールオーバーがより高速となり予測可能となることでアプリケーションをさらにすばやく復旧させることができます

計画的なダウンタイムの大幅な削減どの組織でもアプリケーションダウンタイムの主な理由はオペレーティングシステムへの修正プログラムの適用ハードウェアメンテナンスなどのための計画的なダウンタイムですこうしたダウンタイムがIT 環境の停止の約 80 を占めています

SQL Server 2012 は修正プログラムの要件を減らしより多くのメンテナンス操作をオンラインで実行できるようにすることで計画的なダウンタイムの大幅な削減に役立ちます

Windows Server CoreSQL Server 2012 ではWindows Server Core への配置がサポートされていますこれはWindows Server 2008 および Windows Server 2008 R2 の最小限の合理化された配置オプションですこれによりオペレーティングシステムの修正プログラムの要件を最小限に抑え約 60 削減することで計画的なダウンタイムを減らすことができます

オンライン操作LOB のインデックスを再作成したり既定値を使用して列を追加したりするオンライン操作のサポート強化によってデータベースメンテナンス時のダウンタイムが削減されます


ローリングアップグレードと修正プログラムAlwaysOn 機能はインスタンスのローリングアップグレードと修正プログラムの適用を容易にしますこれによりアプリケーションのダウンタイムが大幅に削減されます

Hyper-V 上の SQL ServerHyper-V 環境でホストされている SQL Server インスタンスではライブマイグレーションの利点を活用することでホスト間の仮想マシンの移行をダウンタイムなしで実行できます管理者はアプリケーションに影響を与えずにホスト上でメンテナンス操作を実行できます

アイドル状態のハードウェアをなくしてコスト効率とパフォーマンスを向上典型的な高可用性ソリューションでは高コストで冗長なパッシブサーバーが配置されますAlwaysOn 可用性グループを使用するとパッシブまたはアイドルな状態のセカンダリデータベースレプリカを読み取り専用のワークロード (SQL Server Reporting Services のレポートクエリバックアップ操作など) に活用できますプライマリとセカンダリの両方のデータベースレプリカを同時に使用できるためサーバーハードウェア間のリソースのバランスが良くなりすべてのワークロードのパフォーマンスが向上します

簡単な配置と管理構成ウィザードWindows PowerShell コマンドラインインターフェイスのサポートダッシュボード動的管理ビュー (DMV)ポリシーベースの管理System Center 統合などの機能によって可用性グループの配置と管理が簡単になります

RPO と RTO の機能比較目標復旧時点 (RPO) と目標復旧時間 (RTO) のビジネス目標は高可用性災害復旧ソリューションのために使用する SQL Server テクノロジを選択する際に重要な判断材料となります次の表はさまざまなソリューションで実現される結果を大まかに比較したものです


高可用性と災害復旧のSQL Server ソリューション

データ損失の可能性 (RPO)

可能な復旧時間 (RTO)

自動フェールオーバー

読み取り可能な

セカンダリ(1)

AlwaysOn 可用性グループ - 同期コミットゼロ数秒 (4) 0 - 2

AlwaysOn 可用性グループ - 非同期コミット数秒数分 times 0 - 4

AlwaysOn フェールオーバークラスターインスタンス

該当せず(5) 数秒～数分

該当せず

データベースミラーリング(2) - 高い安全性 (同期 + 監視)

ゼロ数秒該当せず

データベースミラーリング(2) - 高パフォーマンス (非同期)

数秒(6) 数分(6) times 該当せず

ログ配布数分(6) 数分～数時間(6)

times 復元中はなし

バックアップコピー復元(3) 数時間(6) 数時間～数日(6)


(1) AlwaysOn 可用性グループで使用できるセカンダリレプリカは種類に関係なく最大 4 つです(2) この機能は将来のバージョンの Microsoft SQL Server では削除される予定です代わりに AlwaysOn 可用性グループを使用

してください(3) バックアップコピー復元は障害復旧には適していますが高可用性には適していません(4) 可用性グループの自動フェールオーバーはフェールオーバークラスターインスタンスとの間ではサポートされていま

せん(5) FCI 自体にはデータ保護機能はありませんデータ損失はストレージシステムの実装に依存します(6) ワークロードデータ量およびフェールオーバーの手順に大きく依存します


SQL Server AlwaysOn の保護レイヤーSQL Server AlwaysOn ソリューションではインフラストラクチャとアプリケーションコンポーネントのいくつかの論理レイヤーおよび物理レイヤーにまたがってフォールトトレランスと災害復旧を実現できます従来はさまざまな関係者と役割ごとに業務と責任を振り分けそれぞれが主に自分のソリューションのレイヤー部分だけに関心を持つことが一般的でした

このセクションではこれらのレイヤーのそれぞれについて詳細に説明しデザインに関する議論や実装についての意思決定に役立つ論点やガイダンスを提示します

SQL Server AlwaysOn ソリューションをうまく利用するには以下のレイヤーについて理解しそれぞれを協調させる必要があります

インフラストラクチャレベルサーバーレベルのフォールトトレランスとノード内のネットワーク通信が含まれますWindows Server フェールオーバークラスタリング (WSFC) 機能を使用して稼働状態の監視とフェールオーバーの調整を行います

SQL Server インスタンスレベルSQL Server AlwaysOn フェールオーバークラスターインスタンス (FCI) はWSFC クラスター内の複数のサーバーノードにまたがってインストールされる SQL Server インスタンスであり各サーバーノードへのフェールオーバーが可能ですFCI をホストするノードは堅牢な対称型共有ストレージ (SAN または SMB) に接続されます

データベースレベル可用性グループは共にフェールオーバーされるユーザーデータベースのセットです可用性グループは1 つのプライマリレプリカと最大 4 つのセカンダリレプリカで構成されます各レプリカはWSFC クラスターの別々のノードにある SQL Server インスタンス (FCI または非 FCI) によってホストされます

クライアント接続データベースクライアントアプリケーションは指定した SQL Server インスタンスネットワーク名に直接接続できますまたは可用性グループリスナーにバインドされている仮想ネットワーク名 (VNN) に接続することもできますVNN はWSFC クラスターおよび可用性グループのトポロジを抽象化するものであり接続要求を適切な SQL Server インスタンスとデータベースレプリカに論理的にリダイレクトします

代表的な AlwaysOn ソリューションの論理トポロジは次の図のようになります


インフラストラクチャの可用性AlwaysOn 可用性グループと AlwaysOn フェールオーバークラスターインスタンスのどちらもWindows Server オペレーティングシステムと WSFC をプラットフォームテクノロジとして利用します今まで以上にMicrosoft SQL Server データベース管理者はこれらのテクノロジについて十分に理解することが必要です

Windows オペレーティングシステムSQL Server は基礎的なインフラストラクチャとネットワークストレージセキュリティ更新プログラムおよび監視のサービスを Windows プラットフォームに依存しています

SQL Server 2012 の各エディションはWindows Server 2008 R2 オペレーティングシステムの対応するエディション (Windows Server 2008 R2 Standard オペレーティングシステムWindows Server 2008 R2 Enterprise オペレーティングシステムWindows Server 2008 R2 Datacenter オペレーティングシステムなど) の機能や能力をさらに進歩させて構築されています

詳細については「SQL Server 2012 のインストールに必要なハードウェアおよびソフトウェア」(httpmsdnmicrosoftcomja-jplibraryms143506(SQL110)aspx) を参照してください

Windows Server Core インストールオプションSQL Server 2012 では高可用性のための主要な機能の 1 つとしてWindows Server 2008 以降で Server Core インストールオプションによる配置をサポートしていますServer Core インストールオプションでは制限された機能と非常に限定的な GUI アプリケーションサポートで特定のサーバーロールを実行するための最低限の環境が提供されます既定では必要なサービスとコマンドプロンプト環境のみが有効です


この操作モードではオペレーティングシステムへの攻撃の危険性とシステムオーバーヘッドが低下し継続的なメンテナンスサービス修正プログラムなどの要件が大幅に削減されます

SQL Server 2012 を Windows Server Core に配置する場合の主な注意点はSQL Server およびオペレーティングシステムのすべての配置構成管理およびメンテナンスをWindows PowerShell などのスクリプト環境やコマンドラインまたはリモートツールを使用して行う必要があることです

プライベートクラウド用の SQL Server の最適化高可用性と災害復旧はプライベートクラウド環境ではさらに重要になってきていますプライベートクラウドに SQL Server を配置すればコンピューターネットワークおよびストレージのリソースが効率的に使用され物理的な場所や資本と運営費用の両方の削減に役立ちます配置の統合リソースの効率的なスケーリングオンデマンドでのリソースの配置が容易になり制御の自由度が失われることもありません

SQL Server ではHyper-V のホストとゲストの両方のシステムに対して Windows Server フェールオーバークラスタリングをサポートするほかライブマイグレーションもサポートしていますこれは意識されるほどのダウンタイムを生じることなくホスト間で仮想マシンを移動できる機能ですライブマイグレーションはゲストクラスタリングとも協調して動作します

詳細については「プライベートクラウドコンピューティング - プライベートクラウド用の SQL Server の最適化」(httpwwwmicrosoftcomSqlServerPrivateCloud) を参照してください

Windows Server フェールオーバークラスタリングWindows Server フェールオーバークラスタリング (WSFC) はMicrosoft SQL Server などのサーバーアプリケーションに対して高可用性と災害復旧をサポートするインフラストラクチャ機能を提供します

WSFC クラスターノードまたはサービスに障害が発生するとそのノードでホストされていたサービスまたはリソースは自動的にまたは手動で他の可用性ノードに転送されますこのプロセスをフェールオーバーと呼びますAlwaysOn ソリューションではこのプロセスが FCI と可用性グループの両方に適用されます

WSFC クラスター内の各ノードは連携して次のような機能を提供します

分散メタデータと通知WSFC サービスとホストされるアプリケーションメタデータはクラスター内の各ノードで維持されますこのメタデータにはホストされるアプリケーションの設定に加えWSFC の構成と状態が含まれます1 つのノードでのメタデータまたは状態の変更はクラスター内の他のノードに自動的に反映されます


リソース管理クラスター内の各ノードは直接アタッチされたストレージ (DAS)ネットワークインターフェイス共有ディスクストレージへのアクセスなど物理的リソースを提供する場合がありますSQL Server などホストされるアプリケーション自体もクラスターリソースとして登録されますまた他のリソースに対するスタートアップと正常性にかかわる依存関係を構成できます

正常性の監視ノード間の正常性およびプライマリノードの正常性はハートビートネットワーク通信とリソースの監視を組み合わせることで検出されますクラスターの全体的な正常性状態はクラスター内のノードのクォーラムの投票によって決定されます

フェールオーバーの調整各リソースはプライマリノードでホストされるように構成されそれぞれ自動的にまたは手動で 1 つ以上のセカンダリノードに転送されます正常性ベースのフェールオーバーポリシーによってノード間でのリソース所有権の自動転送が制御されますフェールオーバーが発生すると適切に対応できるように各ノードおよびホストされているアプリケーションに通知されます

詳細については「Windows Server | フェールオーバークラスタリングとノードバランシング」(httpwwwmicrosoftcomwindowsserver2008enusfailover-clustering-mainaspx) を参照してください

注データベース管理者が WSFC クラスターおよびクォーラム管理の内部動作を理解しておくことが非常に重要になりましたAlwaysOn の正常性の監視管理および障害復旧の手順はすべてが本質的に WSFC 構成と関連しています

WSFC ストレージ構成Windows Server フェールオーバークラスタリングでは接続されているストレージデバイスディスクボリュームおよびファイルシステムの管理をクラスター内の各ノードに依存していますWSFC はストレージサブシステムが非常に堅牢であると想定しているためノードに接続されたストレージデバイスが使用できない場合はクラスターノードが障害状態であると見なします

書き込みベースの操作ではディスクボリュームは SCSI-3 の永続的な予約を使用して一度に 1 つのクラスターノードに論理的に接続されますノードで障害が発生した場合にはストレージサブシステムの機能と構成に応じてディスクボリュームの論理的所有権をクラスター内の別のノードに移すことができます


SQL Server AlwaysOn ソリューションでは次のような WSFC ストレージ構成の組み合わせを利用しその制限も受けます

直接接続とリモートストレージデバイスはサーバーに物理的に直接接続されるかまたはネットワークやホストバスアダプター (HBA) を介してリモートのストレージデバイスを使用しますリモートストレージのテクノロジにはiSCSI やファイバーチャネルなどのストレージエリアネットワーク (SAN) ベースのソリューションとサーバーメッセージブロック (SMB) というファイル共有ベースのソリューションがあります

対称と非対称ストレージデバイスの論理ディスクボリューム構成とファイルパスがクラスターの各ノードでまったく同じである場合それらのストレージデバイスは対称的であると見なされます基になるディスクボリュームの物理的な実装と容量は異なっていてもかまいません


専用と共有専用ストレージは使用するために予約されクラスター内の 1 つのノードに割り当てられます共有ストレージはクラスターの複数のノードからアクセスできます共有ストレージデバイスが SCSI-3 プロトコルに準拠していればそれらの制御と所有権をノード間で移動させることができますWSFC ではファイル共有のためにクラスター共有ボリュームを同時に複数のノードでホスティングできますただしSQL Server は複数のノードからの共有ボリュームへの同時アクセスをサポートしていません

注 SQL Server FCI では対称共有ストレージを使用してインスタンスのすべてのノード所有者 (およびその候補) からアクセスできるようにする必要がありますただしAlwaysOn 可用性グループの導入に伴いそれぞれが独自に専用のローカルまたはリモートストレージを持つ非 FCI の SQL Server インスタンスを WSFC クラスターに配置できるようになりました

WSFC リソースの正常性の検出とフェールオーバーWSFC クラスターノード内の各リソースの状態と正常性は定期的にまたは要求に応じて報告されますクラスターリソースの障害を示す状況としてはたとえば電源障害ディスクまたはメモリのエラーネットワーク通信エラー構成エラー応答しないサービスなどがあります

ネットワークストレージサービスなどの WSFC クラスターリソースは互いに依存するように構成できますあるリソースの累積的な正常性は依存関係を持つリソースの正常性を連続的にたどってゆくことで決定されます

AlwaysOn 可用性グループでは可用性グループと可用性グループリスナーがそれぞれ WSFC クラスターリソースとして登録されますAlwaysOn フェールオーバークラスターインスタンスではSQL Server サービスおよび SQL Server エージェントサービスが WSFC クラスターリソースとして登録されどちらもインスタンスの仮想ネットワーク名リソースに依存します

WSFC クラスターリソースで設定された数のエラーまたは障害が一定期間内に発生した場合構成されたフェールオーバーポリシーによってクラスターサービスは次のいずれかの操作を行います

現在のノードでのリソースの再起動リソースをオフライン化リソースとその依存関係を別のノードへ自動的にフェールオーバー

注 WSFC クラスターリソースの正常性の検出は個々のノードの正常性やクラスターの全体的な正常性には直接影響しません


WSFC のクラスター検証ウィザードクラスター検証ウィザードはWindows Server 2008 および Windows Server 2008 R2 のフェールオーバークラスタリングに統合されている機能ですこれはSQL Server AlwaysOn ソリューションの配置前にクリーンで正常な安定した WSFC 環境が存在していることをデータベース管理者が確認するために使用する主要なツールです

クラスター検証ウィザードではクラスターのノードとして使用するサーバーの集合または既存のクラスターを対象にして一連のテストを実行できますこのプロセスでは基になるハードウェアおよびソフトウェアが個別に直接テストされWSFC クラスターが特定の構成でどの程度良好にサポートされるかについての正確な評価が得られます

この検証プロセスでは各ノードに対して次のようなカテゴリの一連のテストとデータ収集が実施されます

一覧作成BIOS のバージョン環境レベルホストバスアダプターRAMオペレーティングシステムのバージョンデバイスサービスドライバーなどの情報です

ネットワークNIC のバインド順序ネットワーク通信IP 構成ファイアウォール構成などの情報ですすべての NIC でノード間の通信が検証されます

ストレージディスクドライブの容量アクセス待機時間ファイルシステムなどの情報ですSCSI コマンドディスクフェールオーバー機能対称的または非対称的なストレージ構成が検証されます

システム構成Active Directory の構成ドライバーの登録メモリダンプの設定必要なオペレーティングシステムの機能とサービス互換性のあるプロセッサアーキテクチャおよびサービスパックと Windows Software Update のレベルが検証されます

これらの検証テストの結果を利用してクラスターの構成を微調整したり構成を追跡したりダウンタイムを引き起こすかもしれない潜在的なクラスター構成の問題を特定したりできますテスト結果のレポートは後で参照できるようにHTML ドキュメントとして保存できます

これらのテストはWSFC の構成に何か変更を加える前と加えた後に実行するほかSQL Server をインストールする前および災害復旧プロセスの一環として実行する必要がありますマイクロソフトで特定の WSFC クラスター構成がサポートされるためにはマイクロソフトカスタマーサポートサービス (CSS) にクラスター検証レポートを提出する必要があります

詳細については「フェールオーバークラスターステップバイステップガイドフェールオーバークラスター用ハードウェアを検証する」(httptechnetmicrosoftcomja-jplibrarycc732035(WS10)aspx) を参照してください

注ハードウェアベースの地理的クラスタリングストレージソリューションの場合やAlwaysOn 可用性グループの場合のようにクラスター構成に非対称ストレージがあるとクラスター検証ウィザードでストレージの検証手順を成功させるために多数の修正プログラムを適用しなければならないことがあります


詳細については「AlwaysOn 可用性グループの前提条件制限事項および推奨事項」(httpmsdnmicrosoftcomja-jplibraryff878487(SQL110)aspxSystemReqsForAOAG) を参照してください

WSFC クォーラムモードと投票の構成WSFC ではクォーラムベースのアプローチを使用してクラスターの全体的な正常性を監視することでノードレベルのフォールトトレランスを最大限に高めますWSFC のクォーラムモードおよびノード投票構成の基本について理解することはAlwaysOn 高可用性災害復旧ソリューションの設計運用トラブルシューティングのために非常に重要です

クォーラムによるクラスター状態検出WSFC クラスター内の各ノードは定期的なハートビート通信に参加しノードの正常性状態を他のノードと共有します応答しないノードはエラー状態であると見なされます

クォーラムノードセットとはWSFC クラスター内の投票ノードおよび監視サーバーのうち過半数を占めるノードの集合ですWSFC クラスターの全体的な正常性と状態は定期的なクォーラムの投票によって決定されますクォーラムはクラスターが正常でありノードレベルのフォールトトレランスを提供できることを意味します

クォーラムに達していない状態はクラスターが正常でないことを示しますプライマリノードのフェールオーバー先として正常なセカンダリノードを使用できるようにするにはWSFC クラスターの全体的な正常性が維持されている必要があります投票数がクォーラムに達しなかった場合にはWSFC クラスター全体が予防策としてオフラインに設定されますその場合クラスターに登録されている SQL Server インスタンスがすべて停止します

注クォーラム障害のために WSFC クラスターがオフラインに設定されるとオンラインに戻すために手動の操作が必要です詳細については後の「WSFC の強制クォーラムによる災害復旧」のセクションを参照してください

クォーラムモードクォーラムモードはWSFC クラスターレベルで構成されクォーラム投票の方法を指定しますフェールオーバークラスターマネージャーユーティリティではクラスター内のノード数に基づいて推奨するクォーラムモードが提示されます

次のいずれかのクォーラムモードによって投票クォーラムの構成が決定されます

ノードマジョリティクラスターが正常であるためにはクラスター内の半分以上の投票ノードが肯定的に投票する必要があります

ノードおよびファイル共有マジョリティノードマジョリティクォーラムモードに似ていますがリモートファイル共有も投票監視サーバーとして構成され各ノードからそのリモートファイル共有への接続も肯定的な投票としてカウントされますクラスターが正常であるためには投票の過半数が肯定的である必要があります


推奨事項として監視ファイル共有はクラスター内のノードに存在せずクラスター内のすべてのノードから見える必要があります

ノードおよびディスクマジョリティノードマジョリティクォーラムモードに似ていますが共有ディスククラスターリソースも投票監視サーバーとして使用され各ノードからその共有ディスクへの接続も肯定的な投票としてカウントされますクラスターが正常であるためには投票の過半数が肯定的である必要があります

ディスクのみ共有ディスククラスターリソースが監視サーバーとして使用され各ノードからその共有ディスクへの接続が肯定的な投票としてカウントされます

詳細については「フェールオーバークラスターステップバイステップガイドフェールオーバークラスターのクォーラムの構成」(httptechnetmicrosoftcomja-jplibrarycc770620(WS10)aspx) で説明されています

注クラスターの各ノードが同じ共有ストレージクォーラム監視ディスクを使用するように構成されていない限り通常投票ノード数が奇数の場合はノードマジョリティクォーラムモード投票ノード数が偶数の場合はノードおよびファイル共有マジョリティクォーラムモードを使用してください

投票ノードと非投票ノード既定ではWSFC クラスター内の各ノードがクラスタークォーラムのメンバーとなります各ノードファイル共有監視サーバーディスク監視サーバーがクラスターの全体的な正常性の決定においてそれぞれ 1 票ずつの投票権を持ちますクォーラムに関するここまでの説明ではクラスター状態について投票する WSFC クラスターノードのセットを投票ノードとして注意深く限定してきました状況によってはすべてのノードに投票権を与えることが適切でない場合もあります

WSFC クラスターの各ノードはクォーラムを確立しようとし続けますクラスター内の個々のノードはクラスターが全体として正常であるか正常でないかを明確に決定することはできません特定の時点で各ノードからは他のノードの一部がオフラインフェールオーバー中またはネットワーク通信のエラーにより応答不能に見えますクォーラム投票の主な機能はWSFC クラスターの各ノードの見かけの状態が本当にそれらのノードの実際の状態であるかどうかを判断することです

ディスクのみ以外のすべてのクォーラムモデルではクォーラム投票の有効性はクラスター内のすべての投票ノード間に信頼できる通信が確立されていることに依存しますすべてのノードが同じ物理サブネット上にある場合はクォーラムの投票を信頼できます

しかしクォーラム投票で他のサブネット上のノードが応答しないように見えても実際はオンラインで正常である場合はサブネット間のネットワーク通信のエラーが原因であることが考えられますクラスタートポロジクォーラムモードおよびフェールオーバーポリシーの構成によってはネットワーク通信エラーによって投票ノードのセット (またはサブセット) が実質的に複数作成されてしまう可能性があります


投票ノードの複数のサブセットがそれぞれ独自のクォーラムを構築できる状態はスプリットブレインと呼ばれますこの状態では各クォーラム上のノードが別々の動作をし相互に矛盾する可能性があります

注スプリットブレインの状況が発生するのはシステム管理者が強制クォーラム動作を手動で実行するかまたは非常にまれですが強制的な手動フェールオーバーを実行することでクォーラムノードセットが明示的に細分化された場合のみです詳細については後の「WSFC の強制クォーラムによる災害復旧」のセクションを参照してください

クォーラム構成を単純化し稼働時間を長くする目的でノードの投票がクォーラムにカウントされないように各ノードの NodeWeight 設定 (値 0 または 1) を調整することができます

クォーラム投票に推奨される調整以下のガイドラインをこの順番に適用することでクラスターに対して推奨されるクォーラム投票の構成を判断できます

1 既定は投票権なしにします明確な理由がない限り各ノードには投票権を与えないと考えてください

2 すべてのプライマリノードに投票権を与えますAlwaysOn 可用性グループのプライマリレプリカをホストする各ノードおよび AlwaysOn フェールオーバークラスターインスタンスの優先所有者である各ノードは投票権を持つ必要があります

3 可能性のある自動フェールオーバーの所有者を含めます自動フェールオーバーの結果としてプライマリレプリカまたは FCI をホストする可能性がある各ノードは投票を持つ必要があります

4 セカンダリサイトノードを除外します通常はセカンダリ災害復旧サイトに存在するノードには投票を提供しないでくださいプライマリサイトに問題がない場合クラスターをオフラインにする判断にセカンダリサイト内のノードが影響を与えることは避ける必要があります

5 投票数を奇数にします必要に応じて監視ファイル共有監視ノード (SQL Server インスタンスの有無は問いません)または監視ディスクをクラスターに追加してクォーラムモードを調整しクォーラムの投票結果が同数に分かれるのを防ぎます

6 フェールオーバー後の投票割り当てを再評価します正常なクォーラムをサポートしないクラスター構成にフェールオーバーすることは避けます

ノードの投票の調整の詳細については「クラスタークォーラムの NodeWeight の設定の構成」(httpmsdnmicrosoftcomja-jplibraryhh270281(SQL110)aspx) を参照してください

ファイル共有監視サーバーの投票は調整できませんその投票を含めるか除外するかを決めるには別のクォーラムモードを選択する必要があります

注 SQL Server ではWSFC クラスター構成およびノードクォーラム投票に関する設定を管理するためにいくつかのシステム動的管理ビュー (DMV) が公開されています


詳細については「可用性グループの監視」(httpmsdnmicrosoftcomja-jplibraryff878305(SQL110)aspx) を参照してください


WSFC の強制クォーラムによる災害復旧通常クォーラム障害は災害発生時または WSFC クラスター内の複数のノード間で永続的な通信障害が生じた場合に発生しますクォーラム障害が発生するとクラスターがノードレベルのフォールトトレランスを確保できなくなるためその WSFC クラスター内の SQL Server インスタンス可用性グループおよびクラスター化されているサービスがすべてオフラインになりますクォーラム障害はWSFC クラスター内の正常な投票ノード数がクォーラムモデルを満たさなくなったことを意味しますノードによってまったく機能しなくなるものもあればWSFC サービスがシャットダウンしただけでクォーラムと通信できなくなったことを除けば正常なものもあります

WSFC クラスターをオンラインに戻すには既存の構成の少なくとも 1 つのノードでクォーラム障害の根本的な原因を解決する必要があります災害発生時には使用できる代替ハードウェアの再構成や識別が必要となる場合もあります現状のクラスタートポロジを反映するためにWSFC クラスターの残りのノードを再構成する場合もあります

WSFC クラスターノードで強制クォーラムの手順を使用するとクラスターがオフラインになる原因となった安全管理機能を無効にすることができますこれによりクラスターでのクォーラム投票のチェックが実質的に中断されクラスター内の任意のノードで WSFC クラスターリソースと SQL Server をオンラインに戻すことができます

このような災害復旧プロセスの手順を次に示します

1) 障害の範囲を特定します応答しない可用性グループや SQL Server インスタンス災害後に使用できるオンラインのクラスターノードをそれぞれ特定しWindows イベントログと SQL Server システムログを確認します必要に応じて後で分析できるように解析データやシステムログを保存しておきます

2) 1 つのノードで強制クォーラムを使用して WSFC クラスターを起動します他の点では正常なノードで強制クォーラムの手順に従ってクラスターを手動で強制的にオンラインにしますこの場合データ損失の可能性を最小限に抑えるには可用性グループのプライマリレプリカを最後にホストしていたノードを選択します

詳細については「クォーラムを使用せずに WSFC クラスターを強制的に起動する」(httpmsdnmicrosoftcomja-jplibraryhh270275(v=SQL110)aspx) を参照してください

注強制クォーラムの設定を使用するとWSFC クラスターの投票が過半数に達することで通常のクォーラムモードの動作に自動的に切り替わるまでクラスター全体のクォーラムのチェックがブロックされます

3) 他の点では正常な各ノードでWSFC サービスを 1 つずつ通常の方法で起動します他のノードでクラスターサービスを起動するときは強制クォーラムオプションを指定する必要はありません

各ノードの WSFC サービスがオンラインに戻ると他の正常なノードとの間でネゴシエーションが行われ新しいクラスター構成の状態が同期されますクラスターの最新の状態


を判断するときに競合状態の発生を避けるためこの手順は必ず一度に 1 つのノードで行うようにしてください

注起動した各ノードが新たにオンラインにした他のノードと通信できることを確認しますそうしないと複数のクォーラムノードセットが作成されてスプリットブレインの状況に陥るおそれがあります手順 1 の結果に問題がなければこの現象は発生しません

4) 新しいクォーラムモードとノードの投票の構成を適用します強制クォーラムの手順によってクラスターのすべてのノードを正常に再起動させクォーラムのエラーの根本原因を修正した場合クォーラムモードとノードの投票を元の構成から変更する必要はありません

それ以外の場合は新たに復元されたクラスターノードと可用性レプリカのトポロジを評価し必要に応じてクォーラムモードと各ノードの投票割り当てを変更します未復旧のノード上ではWSFC クラスターサービスをオフラインにするかノードの投票をゼロに設定します

注この時点でクラスター内のノードと SQL Server インスタンスが通常の動作に戻っているように見えることがありますがまだ正常なクォーラムには達していない可能性がありますフェールオーバークラスターマネージャーやSQL Server Management Studio の AlwaysOn ダッシュボードまたは適切な DMV を使用して正常なクォーラムが復元されたことを確認してください

5) 必要に応じて可用性グループのデータベースレプリカを復旧します一部のデータベースはSQL Server の通常の起動処理の一環として自動的に復旧されオンラインに戻ることがありますそれ以外のデータベースの復旧には追加で手動の手順を実行する必要があります

可用性グループレプリカのデータ損失の可能性や復旧にかかる時間を最小限に抑えるにはできればプライマリレプリカ同期セカンダリレプリカ非同期セカンダリレプリカの順にオンラインに戻します

6) 障害が発生したコンポーネントを修復するか交換しクラスターを再検証しますこれで最初の災害およびクォーラム障害から復旧できたので障害が発生したノードを修復するか交換しWSFC と AlwaysOn の関連する構成を適切に調整する必要がありますこれには可用性グループレプリカの削除クラスターからのノードの削除ノードへのソフトウェアの再インストールなどが含まれます

注停止したすべての可用性レプリカを修復または削除する必要がありますSQL Server 2012 では最も古い可用性レプリカを最後に認識した時点以降トランザクションログが切り捨てられません停止したレプリカを修復するか可用性グループから削除しないとトランザクションログが大きくなり他のレプリカのトランザクションログの領域が不足する可能性があります


7) 必要に応じて手順 4 を繰り返しますこの目的は正常な動作を行うために適切なレベルのフォールトトレランスと高可用性を再確立することです

8) RPORTO 分析を実行しますSQL Server のシステムログデータベースのタイムスタンプおよび Windows のイベントログを分析して障害の根本的な原因を特定し実際の復旧ポイントと復旧時間を文書に記録します


SQL Server インスタンスレベルでの保護次に説明する AlwaysOn ソリューションの保護レイヤーはデータプラットフォームそれ自体ですMicrosoft SQL Server 2012 とその Windows Server インフラストラクチャコンポーネントとの統合によって次のような機能が提供されます

可用性の向上 ndash SQL Server インスタンスこれは SQL Server 2012 の新しいインスタンスレベルの機能でAlwaysOn フェールオーバークラスターインスタンスとAlwaysOn 可用性グループをホストするスタンドアロンインスタンスの両方の可用性を強化します

以下の強化点によってフェールオーバーの管理およびトラブルシューティングが向上します

柔軟なフェールオーバーポリシー信頼性の高いエラー検出に使用される新しいシステムストアドプロシージャ sp_server_diagnostics の出力でSQL Server インスタンスに影響するエラーの重大度が FailureConditionLevel プロパティによって示されますWSFC のフェールオーバーポリシーによってこの値が SQL Server インスタンスにどのように影響するかを制御できますある程度エラーを許容する設定からSQL Server の内部コンポーネントエラーを重点的に検出する設定までさまざまに構成できます

特定のレベルのエラーによってフェールオーバーを開始するように構成できますエラーのレベルにはサーバーの停止サーバーの応答停止重大なエラー中程度のエラーなんらかの条件付きエラーなどがありますFailureConditionLevel プロパティはFCI または可用性グループのフェールオーバーポリシーのために使用できます

SQL Server 2012 よりも前のバージョンではフェールオーバーを制御できるようなエラー状態の区分がなくすべてのサービスレベルのエラーによってフェールオーバーが発生しました

詳細については「フェールオーバークラスターインスタンスのフェールオーバーポリシー」(httpmsdnmicrosoftcomja-jplibraryff878664(SQL110)aspx) を参照してください

強化されたインストルメンテーションとログAlwaysOn 専用のシステム構成ビューDMVパフォーマンスカウンターに加えて拡張されたイベント正常性セッションによってAlwaysOn 配置のトラブルシューティングチューニングおよび監視に必要な情報を取得して表示できますこれらの多くはSQL Server ポリシー管理の新しいファセットおよびポリシーを通じて公開されます

詳細については「AlwaysOn 可用性グループの動的管理ビューおよび関数」(httpmsdnmicrosoftcomja-jplibraryff877943(SQL110)aspx) と「sysdm_os_cluster_nodes」(httpmsdnmicrosoftcomja-jplibraryms187341(SQL110)aspx) を参照してください


SMB ファイル共有のサポートWindows Server 2008 以降のスタンドアロン用またはフェールオーバークラスターインスタンス用のリモートファイル共有にデータベースファイルを格納することができますこの場合FCI ごとに異なるドライブ文字を使用する必要がありませんこれはストレージを統合する場合やデータベースファイルのストレージを仮想マシンのゲストオペレーティングシステム用物理サーバーでホストする場合などに便利なオプションです適切に構成すれば直接接続されたストレージとほぼ同等の IO パフォーマンスが得られます

詳細については「ファイル共有上の SQL データベース - シナリオを再検討すべきとき」(httpblogsmsdncombsqlserverstorageenginearchive20111018sql-databases-on-file-shares-it-s-time-to-reconsider-the-scenarioaspx) を参照してください

注 WSFC クラスターではSMB ファイル共有リソースの依存関係を SQL Server リソースグループに追加することはできませんファイル共有の可用性を確保するには別の方法を用いる必要がありますファイル共有が使用できなくなった場合SQL Server は IO 例外をスローしオフラインになります

WSFC と DNS の相互運用性FCI または可用性グループリスナーの仮想ネットワーク名 (VNN) はVNN の作成時または構成の変更時にのみDNS に登録されますすべての仮想 IP アドレスはオンライン状態かオフライン状態かに関係なく同じ仮想ネットワーク名で DNS に登録されますDNS の仮想ネットワーク名を解決するためのクライアント呼び出しは各種のラウンドロビンシーケンスによってすべての登録済み IP アドレスを返します

AlwaysOn フェールオーバークラスターインスタンスSQL Server の AlwaysOn フェールオーバークラスターインスタンス (FCI) の主な目的は1 つのデータセンター内のローカルサーバーとストレージハードウェアでホストされている SQL Server インスタンスの可用性を高めることです

FCI はWindows Server フェールオーバークラスタリング (WSFC) のクラスターに含まれる複数のノードにまたがってインストールされる1 つの論理的な SQL Server インスタンスですただし一度に 1 つのノードだけでアクティブになることができますクライアントアプリケーションはアクティブなクラスターノードが所有している仮想ネットワーク名および仮想 IP アドレスに接続します

FCI をインストールした各ノードは同一の構成を持ち同一の SQL Server バイナリを含んでいますWSFC クラスターサービスはアクティブなインスタンス上にある Windows レジストリのエントリからFCI をインストールした各ノードに関連のある変更をレプリケートしますFCI がインストールされている各ノードはインスタンスとそのリソースの所有者の候補として指定されフェールオーバーの優先順位に従って所有者となります

共有対称ストレージボリュームに格納されているデータベースファイルはリソースとして WSFC クラスターに登録され現在 FCI をホストしているノードによって所有されます


詳細については「AlwaysOn フェールオーバークラスターインスタンス」(httpmsdnmicrosoftcomja-jplibraryms189134(SQL110)aspx) を参照してください

FCI のフェールオーバープロセス依存しているクラスターリソースで障害が発生した場合AlwaysOn フェールオーバークラスターインスタンスはWSFC クラスターサービスと連携してフェールオーバーを行いますそのプロセスの概要を以下に示します

1) 再起動が指示されますWSFC の定期的なチェックまたは SQL Server のフェールオーバーポリシー構成によってエラー状態が示されます既定では他のノードへのフェールオーバーを開始する前にサービスの再起動が試みられます再起動の試みがタイムアウトするようであればリソースの障害が発生しています

2) フェールオーバーが指示されますフェールオーバーポリシーチェックによってノードのフェールオーバーが必要であることが示されます

3) SQL Server サービスが停止されますSQL Server サービスが現在実行されている場合はその正常なシャットダウンが試みられます

4) WSFC クラスターリソースが転送されますSQL Server クラスターリソースグループの所有権とそれが依存するネットワークおよび共有ストレージリソースがFCI で次に優先されるノード所有者に転送されます

5) 新しいノードで SQL Server が起動されますSQL Server インスタンスは通常のスタートアッププロシージャで起動されます所定のタイムアウト時間内にオンラインに戻らない場合クラスターサービスはこの新しいノード上のリソースをエラー状態と見なします

6) 新しいノードでユーザーデータベースが復旧されます各ユーザーデータベースは復旧モードに設定されます復旧モードではトランザクションログの再実行操作が適用されコミットされていなかったトランザクションがロールバックされます

FCI の強化以前のバージョンの SQL Server でも FCI のインストールオプションは用意されていましたがSQL Server 2012 では次のような機能強化によって可用性の堅牢性と利便性が向上しました

マルチサブネットクラスタリングSQL Server 2012 では複数のサブネットに存在する WSFC クラスターノードがサポートされていますWSFC クラスターノードに存在する SQL Server インスタンスはいずれかのネットワークインターフェイスが使用可能であれば起動できますこれはクラスターリソースの OR 依存関係と呼ばれます

以前のバージョンの SQL Server の場合SQL Server サービスを起動またはフェールオーバーするにはすべてのネットワークインターフェイスが機能しそれらがすべて同じサブネットまたは VLAN に存在している必要がありました


注マルチサブネットクラスタリングではクラスターノード間のストレージレベルのレプリケーションが自動的には有効になりませんマルチサブネットの FCI ソリューションでクラスターノード間でデータのレプリケーションを行いストレージフェールオーバーを調整するためにはサードパーティから提供される SAN ベースのソリューションを利用する必要があります

詳細については「SQL Server 2012 AlwaysOn マルチサイトフェールオーバークラスターインスタンス」(httpsqlcatcomsqlcatbwhitepapersarchive20111222sql-server-2012-alwayson_3a00_-multisite-failover-cluster-instanceaspx) を参照してください

信頼性の高いエラー検出WSFC クラスターサービスではノードの各 SQL Server 2012 FCI に対してそれぞれ専用の管理者接続が維持されますこの接続では特殊なシステムストアドプロシージャ sp_server_diagnostics を定期的に呼び出すことでシステムの正常性診断に役立つ豊富な情報を含む配列が返されます

SQL Server 2012 よりも前のバージョンではFCI の主な正常性検出メカニズムは単純な一方向のポーリングプロセスとして実装されていましたこのプロセスではWSFC クラスターサービスがインスタンスへの新しい SQL クライアント接続を定期的に作成しサーバー名を照会した後で接続を切断していました何かの理由で接続が失敗するかクエリがタイムアウトした場合フェールオーバーが開始されますが診断情報はほとんど提供されません

詳細については「sql_server_diagnostics」(httpmsdnmicrosoftcomja-jplibraryff878233(SQL110)aspx) を参照してください

現在ではFCI ストレージが次のように幅広い状況でサポートされています

向上したマウントポイントサポートSQL Server のセットアップ時にクラスターディスクのマウントポイント設定が認識されるようになりました指定されたクラスターディスクとそれにマウントされているすべてのディスクがセットアップ時に SQL Server リソースの依存関係に自動的に追加されます

ローカルストレージの tempdbFCI ではローカルの非共有ストレージ (ローカルソリッドステートドライブなど) に tempdb を配置できるようになったため共有 SAN での IO 動作の負荷を大幅に軽減できる可能性があります

SQL Server 2012 よりも前のバージョンの FCI ではtempdb が他のシステムデータベースと共にフェールオーバーされる対称共有ストレージボリュームに配置される必要がありました

注 tempdb の場所はmaster データベースに格納されますこのデータベースはフェールオーバー時にノード間で移動されますtempdb は所有者候補となっているすべてのノード上で有効で対称的なファイルパス (ドライブフォルダーおよび権限) に配置されている必要がありますそうなっていない場合SQL Server サービスが一部のノードでは起動されません



データベースの可用性インフラストラクチャレベルおよび SQL Server インスタンスレベルのコンポーネントで提供されている高可用性機能は互いに連係してホストされているデータベースを暗黙的に保護しますAlwaysOn ソリューションではデータベースのデータおよびデータ層アプリケーションを明示的に保護するために一連のオプションが追加で用意されています

AlwaysOn 可用性グループ可用性グループは1 つの SQL Server インスタンスから同じ WSFC クラスター内の別のインスタンスへと同時にフェールオーバーされるユーザーデータベースのセットですクライアントアプリケーションは可用性グループリスナーと呼ばれる WSFC 仮想ネットワーク名を通じて可用性グループのデータベースに接続できますこうすることで基になる SQL Server インスタンスが抽象化されます

AlwaysOn 可用性グループは正常性監視フェールオーバーの調整およびサーバー接続を Windows Server フェールオーバークラスタリングに依存していますWSFC クラスターノード上の SQL Server インスタンスでAlwaysOn サポートを有効にする必要がありますただしそのインスタンスが FCI である必要はなく対称共有ストレージを使用する必要もありません

詳細については「AlwaysOn 可用性グループの概要」(httpmsdnmicrosoftcomja-jplibraryff877884(SQL110)aspx) を参照してください

可用性レプリカとロール可用性グループの各 SQL Server インスタンスは可用性グループのユーザーデータベースのコピーを保持している可用性レプリカをホストしますSQL Server インスタンスは特定の可用性グループの可用性レプリカを 1 つだけホストすることができますが複数の可用性グループを同じインスタンスに置くことは可能ですSQL Server インスタンスは専用の (非共有) ストレージボリュームを持つ必要があります

可用性レプリカの 1 つがプライマリレプリカの役割を果たしますこれは可用性グループデータベースのマスターコピーとして指定されていて読み取り書き込み操作を行うことができます

可用性グループには読み取り専用の可用性レプリカを最大 4 つまで追加で含めることができますこれらは個別にセカンダリレプリカの役割を果たします

可用性レプリカの同期可用性グループの各データベースの内容はSQL Server によるログベースのデータ移動メカニズムを通じてプライマリレプリカから各セカンダリレプリカに同期されますそのため可用性グループのすべてのデータベースは完全復旧モデルに設定する必要があります

セカンダリレプリカはプライマリレプリカのデータベースとトランザクションログの完全なバックアップと復元によって初期化されますプライマリレプリカで新しいトランザクションがコミットされるとトランザクションログの対応する部分がキャッシュされ


キューに入れられてネットワーク経由でセカンダリレプリカノード上のデータベースミラーリングエンドポイントに送信されます

この方法によりプライマリレプリカのトランザクションログの新しいエントリが各セカンダリレプリカのトランザクションログに追加されます各セカンダリレプリカはログシーケンス番号 (LSN) をプライマリレプリカに定期的に送り返しトランザクションログのどのくらいの量がリモートディスクに書き込まれフラッシュされたかを示します

注各可用性レプリカはそれぞれ独自に独立したトランザクションログ再実行スレッドのセットを保持していますこれは可用性レプリカの同期プロセスには含まれませんセカンダリレプリカ上ではログ再実行プロセスによって遅延時間が生じるためユーザーはそれをデータの待機時間として感じる場合があります

プライマリまたはセカンダリの役割を果たす他に各可用性レプリカには可用性モードもありますこのモードは次のようにCOMMIT TRAN ステートメントの実行時にトランザクションログの書き込みの連係を制御します

同期コミットモードすべての同期コミットセカンダリレプリカからそれぞれ独自のトランザクションログの書き込み完了 (LSN 以降) が通知されるまでプライマリレプリカはそのトランザクションをコミットしません可用性グループでは最大で 2 つの同期コミットセカンダリレプリカを使用できます

同期コミットモードではプライマリレプリカデータベースでトランザクションの遅延が生じますがコミットされたトランザクションに対するセカンダリレプリカでのデータ損失を確実に防ぐことができます

非同期コミットモードプライマリレプリカはローカルトランザクションログの書き込み後にトランザクションをコミットしますが非同期コミットセカンダリレプリカからトランザクションログの書き込み完了通知を待つことはしません可用性グループでは最大で 4 つの非同期コミットセカンダリレプリカを使用できますただし両方の種類を合わせて使用できるセカンダリレプリカの合計は最大 4 つです

非同期コミットモードではプライマリレプリカデータベースで生じるトランザクションの遅延が最小になりますがセカンダリレプリカでのトランザクションログが遅れる場合があるため一部のデータが失われる可能性があります

詳細については「可用性モード」(httpmsdnmicrosoftcomja-jplibraryff877931(SQL110)aspx) を参照してください

可用性レプリカ間のデータフローの全体的な正常性は各レプリカの同期状態によって示されますセカンダリレプリカにフェールオーバーしたときに同期状態が同期済みまたは同期中になっていなければほとんどの場合はデータ損失が発生することになります

各セカンダリレプリカの同期ストリームにはセッションタイムアウトプロパティがあります同期コミットモードに構成されているセカンダリレプリカがセッションタイムアウトでエラーになると内部的には一時的に非同期としてマークされますこれはセカンダ


リレプリカのエラーがプライマリレプリカでのトランザクションログの書き込みに影響しないようにするためですそのセカンダリレプリカが正常に戻ってプライマリレプリカの状態に追いつくと自動的に通常の同期コミットモード動作に戻されます

可用性グループのフェールオーバー可用性グループとそれに対応する仮想ネットワーク名はWSFC クラスターのリソースとして登録されます可用性グループはプライマリレプリカの正常性とフェールオーバーポリシーに基づいて可用性レプリカのレベルでフェールオーバーを行います

可用性グループのフェールオーバーポリシーではsp_server_diagnostics システムストアドプロシージャと FailureConditionLevel プロパティを使用して可用性グループに対して許容されるエラーの重大度のレベルを示しますこの同じメカニズムがFCI のフェールオーバーポリシーにも使用されます

フェールオーバーが発生した場合は共有物理リソースの所有権を他のノードに移す代わりにWSFC を利用して他の SQL Server インスタンス上でセカンダリレプリカを再構成しプライマリレプリカの役割を引き継がせますその後可用性グループの仮想ネットワーク名リソースがそのインスタンスに転送されます関連する可用性レプリカへのすべてのクライアント接続がリセットされます

レプリカの現在の正常性同期状態および可用性モードに基づいて各レプリカには複合的なフェールオーバーの準備状態が定義されますこの状態の値はデータ損失の可能性を示していますレプリカの正常性情報はAlwaysOn ダッシュボードまたは sysdm_hadr_availability_replica_states システムビューで確認できます

各可用性レプリカにはフェールオーバーモードも構成されていますこのモードはフェールオーバーが指示された場合にレプリカの動作を制御します

自動フェールオーバー (データ損失なし)セカンダリレプリカのトランザクションログが既に書き込まれ同期されているのですべての AlwaysOn 構成の中でフェールオーバー時間が最短になりますプライマリレプリカ上の開かれているトランザクションはロールバックされプライマリレプリカの役割はユーザーによる操作なしでセカンダリレプリカに転送されます

この場合プライマリレプリカとセカンダリレプリカの両方を自動フェールオーバーモードに設定し両方の可用性モードを同期コミットに設定する必要がありますレプリカ間の同期状態は同期済みである必要がありますまたWSFC クラスターは正常なクォーラム状態になっている必要があります

自動フェールオーバーはプライマリレプリカまたはセカンダリレプリカが FCI 上にある場合はサポートされませんこれは可用性グループと FCI のフェールオーバー間で競合状態が発生することを防ぐためです


手動フェールオーバーこの場合管理者はプライマリレプリカの状態を評価してセカンダリレプリカにフェールオーバーするかどうかを慎重に判断できます

可用性モードと同期状態に応じて次のような選択が可能です

o 計画的な手動フェールオーバー (データ損失なし)この種類のフェールオーバーを実行できるのはプライマリレプリカとセカンダリレプリカの両方が正常で同期済み状態である場合だけですこれは機能的には自動フェールオーバーと同じです

o 強制手動フェールオーバー (データ損失の可能性を許容)これは対象のセカンダリレプリカの可用性モードが非同期コミットである場合またはプライマリレプリカに同期されない場合に使用できる唯一のフェールオーバー形式です

警告このフェールオーバーオプションは災害復旧の状況に限って使用する必要がありますプライマリレプリカが正常で使用可能である場合は関連する各レプリカの可用性モードを同期コミットに変更し計画的な手動フェールオーバーを実行してください

詳細については「可用性グループの強制手動フェールオーバーの実行」(httpmsdnmicrosoftcomja-jplibraryff877957(SQL110)aspx) を参照してください

フェールオーバー対象のプライマリレプリカまたはセカンダリレプリカが次の条件のいずれかに該当する場合は手動フェールオーバーを実行する必要があります

フェールオーバーモードが手動に設定されている可用性モードが非同期コミットに設定されているレプリカが FCI 上にある

詳細については「フェールオーバーとフェールオーバーモード (AlwaysOn 可用性グループ ) 」(httpmsdnmicrosoftcomja-jplibraryhh213151(SQL110)aspx) を参照してください

注フェールオーバー後新しいプライマリレプリカが同期コミットモードに設定されていない場合セカンダリレプリカの同期状態は中断状態になりますプライマリレプリカが同期コミットモードに設定されるまでデータはセカンダリレプリカに移動されません

可用性グループリスナー可用性グループリスナーはクライアントが可用性グループ内のデータベースにアクセスするために使用できる WSFC 仮想ネットワーク名 (VNN) ですVNN クラスターリソースはプライマリレプリカをホストしている SQL Server インスタンスによって所有されます

仮想ネットワーク名は可用性グループリスナーの作成時または構成の変更時にのみDNS に登録されます可用性グループリスナーで定義されているすべての仮想 IP アドレスは同じ仮想ネットワーク名で DNS に登録されます

可用性グループリスナーを使用する場合クライアント接続要求ではサーバーとして仮想ネットワーク名を指定してから可用性グループ内のデータベース名を指定する必要があり


ます既定ではこれによってプライマリレプリカをホストしている SQL Server インスタンスに接続されます

実行時にはクライアントはローカルの DNS リゾルバーを使用して仮想ネットワーク名にマップされている IP アドレスと TCP ポートの一覧を取得しますクライアントは各 IP アドレスへの接続を成功するか接続タイムアウトに達するまで試し続けますMultiSubnetFailover パラメーターが true に設定されているとクライアントは複数の接続を同時に試行するのでクライアントフェールオーバーが大幅に速くなります

フェールオーバーが行われるとサーバー上でクライアント接続がリセットされ可用性グループリスナーの所有権はプライマリレプリカの役割と共に新しい SQL Server インスタンスに移動しVNN エンドポイントは新しいインスタンスの仮想 IP アドレスと TCP ポートにバインドされます

詳細については「可用性グループリスナークライアント接続およびアプリケーションのフェールオーバー」(httpmsdnmicrosoftcomja-jplibraryhh213417(SQL110)aspx) を参照してください

アプリケーションの目的によるフィルター処理可用性グループリスナーを使用して接続している場合アプリケーションは接続の目的がデータの読み取りと書き込みの両方なのか読み取り専用操作を実行するだけなのかを指定できます指定しない場合クライアントのアプリケーションの目的は既定で読み取りと書き込みになります

各可用性レプリカのプライマリロールとセカンダリロールについてはクライアントのアプリケーションの目的に対する接続レベルのフィルターとして接続アクセスプロパティも指定できます既定ではアプリケーションの目的と接続アクセスとの組み合わせが無効であると接続が拒否されますSQL Server は次のルールを使用してクライアントの接続要求を振り分ける必要があります

可用性レプリカがプライマリロールであり接続アクセスが次のいずれかである場合

すべてのアプリケーションの目的を許可するアプリケーションの目的でクライアント接続をフィルター処理しません

明示的な読み取り書き込みの目的だけを許可するクライアントが読み取り専用を指定している場合接続を拒否します

可用性レプリカがセカンダリロールであり接続アクセスが次のいずれかである場合

接続を許可しないすべての接続を拒否しますレプリカは災害復旧だけに使用されます



読み取り専用の目的を許可するクライアントが読み取り専用を指定していない場合接続を拒否します

詳細については「可用性レプリカでの読み取り専用アクセスの構成」(httpmsdnmicrosoftcomja-jplibraryhh213002(SQL110)aspx) を参照してください

アプリケーションの目的の読み取り専用ルーティングAlwaysOn 可用性グループの特に優れた点はスタンバイハードウェアインフラストラクチャを災害復旧以外の目的に利用できることです1 つ以上のセカンダリレプリカを読み取り専用でアクセスできるように構成するとプライマリレプリカからかなりの量のワークロードを軽減できます

読み取り専用セカンダリレプリカに回すように簡単に調整できるワークロードはレポートデータベースバックアップデータベース整合性チェックインデックスの断片化の分析データパイプライン抽出運用サポート操作サポートアドホッククエリなどです

各可用性レプリカではSQL Server インスタンスのエンドポイントについて順次的な読み取り専用ルーティングリストを構成することもできますこのリストはレプリカがプライマリロールであるときに適用されますこのリストが存在する場合アプリケーションの目的が読み取り専用と指定されているクライアント接続要求はそのリスト内に記載されていて前述のアプリケーションの目的フィルターに適合する最初のセカンダリレプリカにリダイレクトされます

注読み取り専用ルーティングによるリダイレクトはプライマリレプリカにバインドされている可用性グループリスナーによって実行されますプライマリレプリカがオフラインの場合クライアントのリダイレクトは機能しません

詳細については「可用性グループの読み取り専用ルーティングの構成 (SQL Server) 」(httpmsdnmicrosoftcomja-jplibraryhh710054(SQL110)aspx) を参照してください

可用性の向上 ndash データベースSQL Server 2012 ではデータベースの構成と機能に関してさまざまな点が強化されています

以下の機能は復旧時間の短縮に役立ちます

予測可能な復旧時間データベースごとにターゲット復旧時間の長さを設定することでバックグラウンドで実行される CHECKPOINT コマンドのスケジュールを制御できますこのコマンドは間接的なチェックポイントとして再起動時またはフェールオーバー時にトランザクションログの復旧に必要となる時間の推定値に基づいて定期的に実行されますそれによってチェックポイントごとに IO 操作がほぼ均等に配分され復旧時間 (RTO) の予測可能性が高まります

SQL Server 2012 よりも前のバージョンではバックグラウンドの CHECKPOINT コマンドがトランザクションの量や負荷とは無関係に一定間隔で実行されていたので復旧時間を予測することはできませんでした


詳細については「データベースチェックポイント」(httpmsdnmicrosoftcomja-jplibraryms189573(SQL110)aspx) を参照してください

以下の向上点は計画的なダウンタイムが必要になる一般的な状況を減らすのに役立ちます

LOB 列のオンラインインデックス操作varbinary(max)varchar(max)nvarchar(max)または XML データ型の列が含まれているインデックスをオンラインで再構築または再構成できるようになりました

新しい NOT NULL 列のオンラインスキーマ修正既定値を使用して新しい NOT NULL 列を SQL Server 2012 データベーステーブルに追加する場合システムメタデータの更新にはスキーマロックだけが必要ですALTER TABLE ステートメントですべての行にデータを設定する必要はありません

いずれかの行で実際に変更またはインデックスの再作成が行われない限り列の既定値は物理的に格納されませんクエリでは列に実際の値が存在しない場合メタデータから既定値を返します

ストレージのサポート強化の例として次のようなものがあります

ページの自動修復ある種のストレージサブシステムエラーが発生するとデータページが破損し読み取り不可能になる場合がありますAlwaysOn 可用性グループではそのような種類のエラーを検出し自動的に復旧できます復旧のために影響を受けたデータページの最新のコピーが別の可用性レプリカから非同期で取得され適用されます

以前のバージョンでもデータベースミラーリングに同様の機能がありましたが新しい機能では複数のレプリカをサポートできるようになっています

詳細については「ページの自動修復」(httpmsdnmicrosoftcomja-jplibrarybb677167(SQL110)aspx) を参照してください

クライアント接続の推奨事項クライアントアプリケーションが Microsoft SQL Server 2012 AlwaysOn テクノロジの利点を十分に活用できるようにするには次のガイドラインに従います

AlwaysOn 対応のクライアントライブラリ表形式のデータストリーム (TDS) プロトコル Version 74 以降をサポートしているクライアントライブラリを使用しますこれによってAlwaysOn の機能に対応した適切な機能がクライアント側でも提供されますクライアントライブラリの例としてはData Provider for SQL Server in NET Framework 402SQL Native Client 110 などがあります

接続プロバイダープロパティ MultiSubnetFailover = True接続文字列にこのキーワードを使用することでクライアントライブラリでは(複数のサブネットに IP アドレスを持つ) 可用性グループリスナーまたは FCI に登録されているすべての IP アドレスに同時に接


続できるようになります


接続プロバイダープロパティ ApplicationIntent = ReadOnly必要に応じてプライマリレプリカの読み取り専用ワークロードをセカンダリレプリカに移管することができます

レガシクライアントの接続タイムアウトレガシクライアントのデータベースライブラリには並列で接続を試行する機能が実装されていないため複数の IP アドレスがある場合にはTCP タイムアウトに達するか正常に接続できるまで1 つずつ順番に接続を試行します

複数の IP アドレスが存在する場合はタイムアウトと再試行が逐次的に繰り返される可能性に備えてレガシクライアントの接続タイムアウトを調整する必要があります値は少なくとも 15 秒 + 21 秒 times セカンダリレプリカ数にします


結論このホワイトペーパーではSQL Server 2012 の AlwaysOn による高可用性災害復旧ソリューションを使用し予定されたダウンタイムや予定外のダウンタイムを短縮したりアプリケーションの可用性を最大限に高めたりデータを保護したりする方法について基本的なコンテキストを確立しました

高可用性データベース環境の計画管理測定に関連したビジネス上の目的と課題は多くの場合目標復旧時点 (RPO) と目標復旧時間 (RTO) という形で数量化して表すことができます

SQL Server 2012 AlwaysOn は組織が高可用性や災害復旧に関する一般的な状況に対処するための機能をRPO と RTO を適切に達成できることを念頭にインフラストラクチャレベルデータプラットフォームレベルデータベースレベルのそれぞれで提供します

詳細情報

httpwwwmicrosoftcomja-jpsqlserver2012defaultaspx SQL Server Web サイト

httptechnetmicrosoftcomja-jpsqlserver SQL Server TechCenter

httpmsdnmicrosoftcomja-jpsqlserver SQL Server 開発者向け技術情報

このホワイトペーパーはお役に立ちましたかフィードバックをお寄せください1 (役に立たなかった) ～ 5 (非常に役に立った) の 5 段階で評価してくださいまたその評価の理由もお知らせください以下に例を示します

評価が高い例が適切図がわかりやすい説明が明快といったことが理由である評価が低い例が少ない図がわかりにくい説明があいまいといったことが理由で

ある

このようなフィードバックをお寄せいただくと今後のホワイトペーパーの品質向上につながります

フィードバックの送信

loz Version 112012 年 2 月 21 日


高可用性と災害復旧の概念

高可用性について

予定されたダウンタイムと予定外のダウンタイム

段階的な可用性

ダウンタイムの定量化

復旧目標

ROI または機会費用の正当化

可用性の健全度の監視


概要 Microsoft SQL Server 2012 での高可用性

SQL Server AlwaysOn

計画的なダウンタイムの大幅な削減

アイドル状態のハードウェアをなくしてコスト効率とパフォーマンスを向上

簡単な配置と管理

RPO と RTO の機能比較

SQL Server AlwaysOn の保護レイヤー

インフラストラクチャの可用性

Windows オペレーティングシステム

Windows Server Core インストールオプション

プライベートクラウド用の SQL Server の最適化

Windows Server フェールオーバークラスタリング

WSFC ストレージ構成

WSFC リソースの正常性の検出とフェールオーバー

WSFC のクラスター検証ウィザード

WSFC クォーラムモードと投票の構成

クォーラムによるクラスター状態検出

クォーラムモード

投票ノードと非投票ノード

クォーラム投票に推奨される調整

WSFC の強制クォーラムによる災害復旧

SQL Server インスタンスレベルでの保護

可用性の向上 ndash SQL Server インスタンス


FCI のフェールオーバープロセス

FCI の強化

データベースの可用性

AlwaysOn 可用性グループ

可用性レプリカとロール

可用性レプリカの同期

可用性グループのフェールオーバー

可用性グループリスナー

アプリケーションの目的によるフィルター処理

アプリケーションの目的の読み取り専用ルーティング

可用性の向上 ndash データベース

クライアント接続の推奨事項

結論

インフラストラクチャの可用性SQL Server インスタンスレベルの保護データベースレベルの保護およびデータ層アプリケーションの機能について解説します

高可用性と災害復旧のための Microsoft SQL Server AlwaysOn ソリューションガイド ii

著作権











復旧目標3



























結論31








times100

































































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論

著作権











復旧目標3



























結論31








times100

































































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論






復旧目標3



























結論31








times100

































































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論

結論31








times100

































































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論







times100

































































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論






























































セカンダリ(1)





該当せず












































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論
































































































































































































































































詳細情報






ある










復旧目標





SQL Server AlwaysOn
























FCI の強化











結論

高可用性と災害復旧の概念download.microsoft.com/download/6/b/e/6be0c3f3-2991-4766... ·...

Documents