サーバーがダウンすると、ビジネス目標が中断され、収益が失われる可能性があります。たとえば、インスタンスとデータベースが利用できない場合、航空会社は顧客のフライトを予約できない可能性があります。システムは、火災、人的エラー、コンピューター障害、ディスク障害、プログラミングエラーなど、さまざまな理由で障害が発生する可能性があります。
中断を回避し、ビジネスサービスの継続性を確保するには、高可用性（HA）およびディザスタリカバリ（DR）戦略を実施することが非常に重要です。 HAとDRはしばしば一緒に議論されます。 HAはサーバーのダウンタイムを可能な限り削減することに関心を持っていますが、完璧なシステムはないため、DRは、データベースシステムがダウンした場合に、バックアップメディアを使用して失われたデータを回復するプロセスに重点を置いています。
AlwaysOnは、SQL Server 2012以降、Microsoftの拡張HADR機能を説明するために使用されるブランド/マーケティング用語です。 AlwaysOn以前は、データベースエンジンは、データベースミラーリング、フェールオーバークラスター、ログ配布など、他の組み込みの独自のソリューションをサポートしていました。ただし、これらの手法にはそれぞれ利点と制限があります。多くの場合、組織はその目標に応じて、望ましいHADR戦略を達成するために複数の方法を組み合わせる必要がありました。
AlwaysOn機能が導入されたため、サーバーとデータベースの両方の冗長性を考慮したり、スケーリングの問題が発生したり、スタンバイハードウェアが効率的に使用されていなかったりするために、導入に余分な時間とリソースを費やして導入を複雑にする必要がありません。これらの機能は、古い慣行の多くを便利にブレンドし、不十分な領域を改善します。 AlwaysOn製品の価値を真に理解するには、データベースエンジンが過去にシステムHADRをどのように保証したかについての最初の基本的な概念を再検討することが重要です。
データベースミラーリング
データベースの冗長性は、ミラーリングによって実現できます。たとえば、学生がオンラインで教科書を注文できる、収益を生み出すフロントエンドクライアントアプリを作成できます。顧客が購入を選択すると、バックエンドのPsychologyBooksデータベースに対してリクエストが行われます。 PsychologyBooksデータベースが利用できなくなるような災害が発生した場合、学生は注文を完了することができなくなります。
この中断を回避するために、PsychologyBooksデータベースを含むプリンシパルインスタンスを本番環境にデプロイし、そのPsychologyBooksデータベースの追加コピーをスタンバイ上のミラーサーバーに置くことができます。クライアントアプリは、中断が発生したり、プライマリで回復が完了するのを待つ必要がなく、ミラーリングされたコピーに再接続できます。コピーは、トランザクションログを受信し、記録された変更をやり直すことで、元の変更に対応します。
ミラーリングセッションは、パフォーマンスまたは安全性の高い理由に応じて、さまざまなモードで動作できます。便利なことに、ミラーリングセッションが高安全同期モードで動作し、オプションの監視サーバーの存在によってクォーラムコンセンサスが確立されている場合、自動フェイルオーバーがサポートされます。
ミラーリングの利点にもかかわらず、サーバーの冗長性ではなくデータベースの冗長性のみを提供するため、不十分です。つまり、プライマリサーバーインスタンスがダウンすると、両方のインスタンスがダウンし、データベースレベルでデータのスペアコピーが存在することは問題になりません。スタンバイはユーザー操作をサポートしておらず、ミラーリングされたインスタンス上のデータの読み取り専用コピーを取得するにはスナップショットが必要になります。データベースは保護されていますが、サーバーの役割のメンバーシップ、ログイン情報、エージェントジョブなどのサーバーレベルのオブジェクトは保護されていません。
たとえば、大規模なマーケティングチームがあり、各メンバーが独自のログインを持っている場合、各メンバーのログインを再作成するプロセスをもう一度やり直す必要があります。フェイルオーバーが発生した場合、それはグループとしてではなく、独立したデータベースベースで行われます。
フェイルオーバークラスタリング
フェールオーバークラスタリングは、インスタンスレベルで冗長性を提供し、ハードウェアおよびオペレーティングシステムの障害からの保護を提供します。たとえば、アン女王のノードが発火し、機器の故障が発生したとします。インスタンス全体（特定のタスクを実行するために作成されたログインや特定のジョブなどのインスタンスレベルのオブジェクトを含む）は保護され、クラスターに属する別のノードで自動的に再起動できます。クライアントのアプリとサービスは、引き続きお客様にご利用いただけます。
上記のシナリオは、Windows Serverフェールオーバークラスターグループ（WSFC）内の冗長物理サーバー間でストレージが共有されているために機能します。 OSとSQLServerの両方が連携するため、一度に1つのノードのみがWSFCリソースグループを所有します。
残念ながら、共通のストレージでは、このソリューションは以前のミラーリング戦略が提供していたデータベースの冗長性を提供しません。共有ストレージを使用すると、単一障害点が発生するため、リスクが発生します。たとえば、外部ディスクには重要なPsychologyBooksデータベースの唯一のコピーが含まれている場合があり、インスタンスがBallardノードに正常にフェイルオーバーされたとしても、唯一のストレージコンポーネントが侵害された場合、ビジネス目標が中断されます。フェールオーバークラスタリングは、クラスターよりもさらに拡張する増大する量の作業をクライアントアプリが処理できないため、スケーラビリティの観点からも制約を提案します。
ログ配布
データベースの冗長性を実現するもう1つの方法は、ログ配布を使用することです。トランザクションログはプライマリサーバーにバックアップされ、1つまたは複数のセカンダリサーバーに送信されて復元されます。ミラーリングとは異なり、セカンダリデータベースは読み取り専用アクティビティの対象となる可能性があり、ログ配布頻度はさまざまな間隔で構成できます。セカンダリデータベースが必ずしもプライマリデータベースとリアルタイムで同期している必要がないシナリオでは、パフォーマンス上の利点があります。
たとえば、夜の終わりに統計要約レポートを実行して、1日を通してどの心理学の本が販売されているかを確認するために、コピーデータベースがプライマリデータベースと正確に同期している必要はありません。読み取りを多用するアクティビティは、データベースオブジェクトをロックし、待機時間を長くする可能性があります。したがって、セカンダリサーバーでレポートを実行すると、収益を生み出すプライマリサーバーのワークロード需要が軽減されます。
欠点は、ログ配布が自動フェイルオーバーをサポートしていないことです。したがって、ソースサーバーに障害が発生した場合は、データベースを手動で回復する必要があります。ミラーリングと同様に、ログ配布はサーバーの冗長性を提供せず、データベースレベルのソリューションです。
AlwaysOnについて
古いテクノロジーにはそれぞれ利点とトレードオフがあります。ただし、カスタマイズされたHADRソリューションの実装は、ビジネスニーズを満たすためにこれらのさまざまな戦略を任意に組み合わせて組み合わせるため、すぐに複雑になり、より多くの管理が必要になる可能性があります。そのため、AlwaysOn機能が導入され、以前の戦略の拡張された、すでに組み合わされたバージョンが提供されます。
SQL Serverは、AlwaysOn可用性グループ（AG）とAlwaysOnフェールオーバークラスターインスタンス（FCI）の2つの機能を提供します。どちらも、Windows Serverフェールオーバークラスタリング（WSFC）を実装する必要があります。
AGは、一緒にフェイルオーバーするデータベースのグループです。可用性レプリカをホストするには、各ノードにSQLServerインスタンスがインストールされた複数の冗長物理ノードが必要になります。各レプリカは、同じWSFCの異なるノード上にある必要があります。上記の回路図では、プライマリレプリカはノード01でホストされており、他のすべてのセカンダリレプリカは、WSFCが問題を検出したときにフェールオーバーの対象になります。
セカンダリレプリカがプライマリとの同期を維持する方法は、トランザクションログを送信して変更をやり直すことです。 AGは、非同期コミットモードと同期コミットモードの両方をサポートしています。プライマリレプリカは読み取りと書き込みに適格ですが、セカンダリレプリカは読み取り専用に適格です。バックアップはセカンダリロケーションで実行できます。
すぐに、AlwaysOnAGには利点があります。データベースミラーリングの欠点のいくつかは、データベースを1つのセカンダリサーバーにしかミラーリングできないことと、フェイルオーバーが発生すると、各データベースが個別にミラーリングされることを思い出してください。 AGを使用すると、上記の例のノード02、ノード03、ノード04、ノード05など、多くの場所でデータベースが冗長化されます。データベース可用性サポートでは、最大9つの可用性レプリカを使用できます。
さらに、セカンダリサーバーで読み取り専用データを実現するには、ログ配布が必要になります。しかし、AGでは、読み取り専用データはすでに考慮されています。レポートなどの読み取りを多用するアクティビティは、任意のセカンダリレプリカで実行できます。また、共有ストレージの制約がないことにも注意してください。
ただし、AGをAlwaysOn FCIと組み合わせて、サーバーの冗長性を確保することができます。 FCIインスタンスを使用して可用性レプリカをホストし、ログインやエージェントジョブなどのサーバーレベルのオブジェクトも保護できるようにすることができます。このアプローチでは、共有ストレージが必要になります。ただし、クライアントアプリの再構成を実行する必要があるなどの不便はなくなります。