[出典] SQL Serverの高可用性(1)----高可用性の概要

SQL Server 2005以降、Microsoftはダウンタイムの削減とビジネスデータの保護強化のために多様な高可用性技術を提供してきました。また、SQL Server 2008、SQL Server 2008 R2、SQL Server 2012の継続的なリリースにより、さまざまなシナリオに対応する多くの高可用性技術がSQL Serverに搭載されています。

    この記事を始める前に、どの高可用性技術を使うかを決定する要因について簡単に説明します。

    多くの企業は、オンラインショッピングサイトのように、データの一部または一部を高度に利用可能にする必要があります。オンライン商品データベースは24時間365日オンラインでなければなりません。そうでなければ、競争の激しい市場環境ではダウンタイムは顧客や収益の喪失を意味します。 例えば、SQL Serverに依存するコールセンターでは、データベースがダウンすると、すべての発信者はそこに座って「すみません、システム障害です」と返信するしかなく、これも受け入れられません。

    もちろん、理想的な世界ではすべての重要なデータが常にオンラインであるべきですが、現実世界ではデータベースが利用できない理由がさまざまです。災害の時間や形態を予測することは不可能であり、さまざまな緊急事態を防ぐために事前に対策を講じる必要があります。そのため、SQL Serverは主にクラスタリング、レプリケーション、ミラーリング、ログ配信、AlwaysOn可用性グループ、ファイルグループのバックアップや復元など、さまざまな高可用性技術を提供します。 オンライン再構築インデックスのような単一インスタンスの高可用性技術。 高可用性技術の利用は、馴染みのある技術を直接選択することではなく、ビジネスと技術を包括的に考慮することです。 すべての機能を実現できる単一の技術は存在しないからです。 これらの技術を、あなたの特定のビジネスや予算に基づいてどのように採用するかは、いわゆる高可用性戦略として知られています。

高可用性戦略を設計する際には、まず以下の要素を考慮する必要があります。

• RTO(回復時間目標)—すなわち回復時間目標は、許容されるダウンタイムの量を意味し、通常は数個の9で表されます。例えば、99.999%の可用性は年間5分以内のダウンタイム、99.99%の可用性は年間52.5分以内のダウンタイム、99.9%の稼働可能性は年間最大8.75時間のダウンタイムを意味します。 RTOの計算方法は、システムが24時間365日稼働しているのか、それとも午前6時から午後9時までのみなのかなどを考慮していることに注目に値します。 メンテナンスウィンドウがダウンタイムにカウントされるかどうかにも注意が必要で、メンテナンス期間中にデータベースのメンテナンスやパッチ適用が許可されていることで、より高い可用性を実現しやすくなります。
• RPO(リカバリーポイント目標)– リカバリーポイント目標とも呼ばれ、許容されるデータ損失の量を意味します。 通常、しっかりバックアップを取れば、データ損失ゼロを簡単に達成できます。 しかし、災害が発生した場合、データベースの破損の程度によっては、バックアップからデータを復元するのにかかる時間がデータベースを利用不能にし、RTOの実装に影響を及ぼします。 初期で有名な例としては、ヨーロッパやアメリカの銀行システムがあります。RPOのみを考慮し、システムには完全なバックアップとログバックアップのみがあり、3か月ごとの完全なバックアップ、15分ごとのログバックアップのみが存在します。災害発生時には完全なバックアップとログバックアップのみがデータを復元できます。つまり、データ損失はなく、データの復元に丸2日かかったため、銀行システムは2日間利用できず、多くの顧客が失われました。 もう一つの反対の例は、国内のオンライン動画ウェブサイトで、SQL Serverをバックエンドのリレーショナルデータベースとして使い、フロントエンドはNo-SQLを使用し、バックアップとして定期的にNo-SQLデータをリレーショナルデータベースにインポートしています。
  

    予算 – RTOとRPOは総称してSLA(サービスレベル契約)と呼ばれ、高可用性戦略を設計する際には、ビジネスの予算や失敗時の異なるSLAのコストを測定することが重要です。 一般的に、限られた予算で高いSLAを達成するのは難しく、たとえ複雑なアーキテクチャで高いSLAが達成されても、複雑なアーキテクチャは運用および保守コストも高くつつもるため、SLAを満たすために予算内で適切な技術を選択する必要があります。

したがって、一般的に高可用性の大きな枠組みは、いくつかの注文受付に関する質問によって決定できます。

• 株主が受け入れるダウンタイムはどれくらいですか?
• マネージャーにとって許容される休憩時間はどのくらいでしょうか?
• 高可用性シナリオで提供される予算はどのくらいですか?
• ダウンタイムによる1時間あたりの損失はどれくらいですか?
  

• コールドバックアップ:スタンバイサーバーはプライマリサーバーのデータを受け付けるよう設定され、失敗した場合は手動でデータをプライマリデータベースに復元するか、接続文字列やプログラムの権限を再設定してバックアップデータベースをオンラインにします。
• ウォームバックアップ:プライマリサーバーデータはバックアップサーバーに継続的にログを送信します(不規則な間隔で、15分、30分、1分など)。このため、プライマリサーバーからバックアップサーバーへのデータは非同期的に更新されるため、プライマリサーバーとバックアップサーバーのデータが保証されることはありません。 さらに、この方式は通常、自動故障監視やフェイルオーバーを実装していません。
• ホットバックアップ:プライマリサーバーのデータは自動的にバックアップサーバー上で同期され、多くの場合、自動故障監視やフェイルオーバー機能が搭載されており、プライマリサーバーとバックアップサーバーのデータ一貫性が保証されます。
  

    寒い時から暖かい時、熱いバックアップまで、コストが急上昇します。

    SQL Serverでサポートされている高可用性機能はバージョンに密接に関連しており、エンタープライズ版は以下を含むすべての高可用性機能をサポートしています:

• フェイルオーバークラスター
• l データベース画像
• l トランザクションログ送信
• l データベーススナップショット
• l 高可用性アップグレード
• l ホットロードメモリ
• l オンラインインデックス操作
• l データベース部分オンライン(マスターファイルグループまたはマスターファイルグループおよび追加のNDFファイルのみが復元されます)
  

    高可用性機能の具体的なバージョンについては、以下をご覧ください:http://msdn.microsoft.com/zh-cn/library/cc645993.aspx無料のExpress版はデータベースミラーリングのウィットネスサーバーとして機能するため、コスト削減につながります。

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

    フェイルオーバークラスターはSQL Serverインスタンス全体に対して高可用性サポートを提供しており、つまりクラスタ内のノード上のSQL ServerインスタンスがハードウェアエラーやOSエラーなどにより他のノードにフェイルオーバーされることを意味します。 高可用性は、複数のサーバー(ノード)が1台以上のディスクを共有することで達成され、フェイルオーバークラスターは単一のコンピュータと同様にネットワーク上に現れますが、高可用性特性を持っています。 フェイルオーバークラスターは共有ディスクに基づいているため、ディスク障害は単一のポイントであるため、SANレプリケーションなどの追加保護をディスクレベルで展開する必要があることに注意が必要です。 最も一般的なフェイルオーバークラスターは、マスターとスレーブを含む2ノードのフェイルオーバークラスターです。

トランザクションログの伝送

    トランザクションログの出荷は、データベースレベルの高可用性保護を提供します。 ログは対応する本番データベース(「プライマリデータベース」と呼ばれる)の1つ以上のスタンバイデータベース(「セカンダリデータベース」と呼ばれる)を維持するために使用されます。 フェイルオーバーが発生する前に、すべての未復元ログバックアップを手動で適用してセカンダリデータベースを完全に更新しなければなりません。 ログ配信は複数のスタンバイデータベースをサポートする柔軟性があります。 複数の代替データベースが必要な場合は、ログ配信を別々に、またはデータベースミラーリングの補完として利用できます。 これらのソリューションを組み合わせて使用すると、現在のデータベースミラーリング構成の主データベースは、同時にログ出荷構成の主データベースでもあります。

    トランザクションログの配信はコールドバックアップやウォームバックアップに利用できます。

データベースミラーリング

    データベースミラーリングは実際にはソフトウェアソリューションであり、データベースレベルの保護も提供し、ほぼ瞬時のフェイルオーバーを可能にしてデータベースの可用性を向上させます。 データベースミラーは、対応する本番データベース(「プリンシパルデータベース」と呼ばれる)のための単一のスタンバイデータベース(または「ミラーデータベース」)を維持するために使用できます。
ミラーデータベースは常に復元状態にありますが、データベース自体は復元されていないため、ミラーデータベースに直接アクセスすることはできません。 しかし、レポートのような読み取り専用ロードの場合は、ミラーされたデータベースのスナップショットを作成することで間接的にミラードデータベースを利用することができます。 データベーススナップショットは、スナップショットが作成される際にクライアントにデータベース内のデータへの読み取り専用アクセスを提供します。 各データベースミラーリング構成には、主データベースを含む「プリンシパルサーバー」と、ミラーされたデータベースを含むミラーサーバーが関与します。 ミラーサーバーはミラーデータベースと主データベースを継続的に更新します。
    データベースミラーリングは、高セキュリティモードで同期動作、または高性能モードで非同期動作で動作します。 高性能モードでは、トランザクションはミラーサーバーがログをディスクに書き込むのを待つ必要がなく、パフォーマンスを最大化します。 高セキュリティモードでは、コミットされたトランザクションは両パートナーによってコミットされますが、トランザクション遅延時間は延長されます。 データベースミラーリングの最も単純な構成は、主サーバーとミラーサーバーのみを含みます。 この構成では、主サーバーが失われた場合、ミラーサーバーをスタンバイサーバーとして使用できますが、データ損失を引き起こす可能性があります。 高セキュリティモードはスタンバイ設定の高セキュリティモードをサポートし、自動フェイルオーバー機能を備えています。 この構成には「ウィットネスサーバー」と呼ばれるサードパーティのサーバーインスタンスが関与し、ミラーサーバーをホットバックアップサーバーとして使用できるようにします。 プライマリデータベースからミラーデータベースへのフェイルオーバーは通常数秒かかります。

    データベースミラーリングはウォームバックアップとホットバックアップの両方に使用できます。

写し

    レプリケーションは厳密には高可用性を目的とした機能ではありませんが、高可用性に適用可能です。 レプリケーションはデータベースのオブジェクトレベルの保護を提供します。 レプリケーションはパブリッシュ・サブスクライブモデルを用い、データがパブリッシャーと呼ばれるプライマリサーバーから1つ以上のセカンダリーまたはサブスクライバーに公開されます。 レプリケーションはこれらのサーバー間でリアルタイムの可用性とスケーラビリティを提供します。 フィルタリングをサポートし、サブセットのデータを提供するとともに、パーティションの更新もサポートしています。 加入者はオンラインで、クエリ復旧なしで報告やその他の機能に利用できます。 SQL Serverは4種類のレプリケーションタイプを提供します:スナップショットレプリケーション、トランザクションレプリケーション、ピアツーピアレプリケーション、マージレプリケーションです。

オールズオンユーザビリティグループ

    AlwaysOn可用性グループはSQL Server 2012で導入された新機能です。 データベースレベルの保護も提供されています。 また、データベースミラーリングが1:1でしか対応できない制限を拡大し、1つのプライマリレプリカが最大4つのセカンダリレプリカに対応しられるようになり(SQL Server 2014ではこの制限が8つに拡大)、そのうち2つのセカンダリレプリカをリアルタイムでホットバックアップおよびプライマリレプリカとして同期でき、残りの2つの非同期セカンダリレプリカはウォームバックアップとして使用可能です。 さらに、セカンダリプレカは読み取り専用に設定でき、バックアップの負荷を担うために使用できます。

    このため、SQL Server 2012ではデータベースミラーリングが「時代遅れ」とマークされています。

    高可用性の基本概念とSQL Serverで提供される高可用性技術を理解した後、高可用性戦略の設計を見てみましょう。 高可用性戦略の計画は、4つのフェーズに分けられます。

要件を集める

    高可用性戦略を決定する最初のステップは、間違いなくSLAを確立するためのビジネス要件を集めることです。 RTOとRPOは最も重要な部分であり、これを踏まえて可用性要件の現実的な期待を設定し、それに基づく現実的な高可用性戦略を策定します。

評価限度額

    評価の制限は、SQL Serverのさまざまな高可用性技術の制限だけでなく、非技術的技術にも限られます。 予算が数万元しかなく、オフサイトデータセンターとSANレプリケーションに基づく高可用性ソリューションを望むなら、それは間違いなく愚かな夢です。 もう一つの非技術的な制約は運用担当者のレベルであり、複雑なアーキテクチャはより熟練した運用担当者を必要とすることが多いです。 その他の非技術的な制約には、データセンター内のディスク容量の可用性、電源や空調がニーズを満たせるかどうか、可用性戦略の実施にかかる時間などがあります。

    技術的な制限には、異なる高可用性機能や制限、異なるSQL Serverバージョンでサポートされる機能、CPU数、メモリサイズなどがあります。 高可用性ポリシーを実装する前に、まずMicrosoft MSDNウェブサイト上の異なるSQL Serverバージョンや機能の制限を確認することを強くお勧めします。

選択技術

    要件を集め、制約を評価した後、次のステップは、本記事で先に述べた技術または技術の組み合わせをSLA要件を満たすために選択することです。 選択した技術がSLAを満たさない場合、SLAを満たしていない制限を簡単に報告でき、リソースの補填やSLAの妥協を要求できます。

テスト、検証、文書化

    高可用性ポリシーは、現行の可用性ポリシーがSLAを満たしていることを保証するために、最初から厳密にテスト・検証される必要があります。 しかし、高可用性戦略を導入する際には、データの増加やビジネス、要件の変化に伴い、現在のポリシーがSLAを守れるかどうかを定期的にテスト・検証する必要があります。 同時に、可用性ソリューションの設定、フェイルオーバー方法、災害復旧計画を同時に文書化し、故障や高可用性戦略の将来調整時に追跡できるようにすべきです。

この記事では、高可用性の基本概念、SLAの概念、SQL Serverでサポートされているさまざまな高可用性機能、そして高可用性戦略を設計するために必要なステップについて説明します。 この記事はデータベースレベルの高可用性のみについて論じていますが、高可用性はDBAだけの問題ではなく、システム運用・保守担当者、ネットワーク管理者、開発者、マネージャーなど異なる役割がSLAをよりよく満たすための協力も含まれます。