こんにちは。インサイトテクノロジーの松尾です！
本ブログでは、Dbvisit社のブログ “Five reasons that every SQL Server DBA should evaluate Standby MultiPlatform” を翻訳して紹介いたします！
これまでOracleしか対応できなかったDbvisit社のDbvisit StandbyというDR（災害対策）ツールは、今年SQL Serverへ対応し、Dbvisit Standby MultiPlatform（以下：StandbyMP）として新たにリリースされました。本ブログでは、SQL Serverを利用するにあたって、SQL Serverで備えている他のDR手段に対してStandbyMPがどのような点が優れているかを記載しています。
はじめに
Dbvisit社が提供するStandbyMPは、SQL Serverのディザスタリカバリプロセスを改善し、基本的なAlways On可用性グループとログシッピング以上のものを提供します。
一方、IT管理者と経営者は堅牢なDR計画の重要性を理解していますが、社内のDBAが従来のディザスタリカバリソリューションを設定し維持するために必要となる作業の複雑さと継続的な時間を軽視しがちです。
SQL Server向けのDRソリューションを提案するシーンでは、しばしば現状について2つのシナリオを耳にします。
- DRを無視している企業、もっと親切に言えば、DRプロセスが提供する保護の欠如に気づいていない企業。
- DIYのDRソリューションで十分事足りると考えている企業。
残念ながら、現実にはデータベースの障害が発生した際に、どちらにおいてもうまくいく保証はありません。
Microsoft SQL Serverは、適切に実装され、慎重に維持されれば、基本的な保護を実現できるさまざまな無料の機能を提供しています。しかし、SQL Serverのライセンスの種類や実装方法、および監視・保守・テストにかけられる継続的な工数によって、実現できる保護のレベルが大きく異なってきます。つまり、効果的なDRを少ない工数で設定することは現実的には難しく、人為的なミスが発生しやすく、構築と維持に時間がかかる傾向があるのです。
これらの課題に対処できるように、SQL Server の DBA が StandbyMP を検討すべき5つの理由をご紹介します。
理由その１：ディザスタリカバリのベストプラクティスを促進
データベースに致命的な障害が起こることは、予見できる現実です。専門的なDRソフトウェアがなければ、DRテストを定期的に実行したり、セキュリティパッチを実装したりするような、インシデントへの対応力を確立することは困難で、時間もかかります。
DBAとして、重大なインシデントが発生したときにDR戦略が完璧に機能することに100%の確信を持つ必要があります。これを実現するためにはテストされ、検証された、簡単に実行できるフェイルオーバープロセスを持つことが重要です。
StandbyMPは、一般的なDRプロセスをすばやくワンクリックで実行することで、DRのベストプラクティスを促進します。
・頻繁に行われるDRテストを簡単に実施：ワンクリックのリードオンリーモードと、ワンクリックのグレースフルスイッチオーバー（スタンバイサイトへのデータ損失ゼロの計画的切り替え）によるDRテストが可能です。
・ダウンタイムなしでより頻繁なパッチ適用が可能：保護機能の強化に加え、高度に自動化されたグレースフルスイッチオーバーにより、より迅速かつ頻繁なパッチ適用が可能になり、すべてのプロセスを最新の状態に保つための面倒で複雑な作業が不要になります。
理由その２：データベースフェイルオーバーからの作業ストレスを軽減
DBAにとって、重大なインシデント発生からのプレッシャーは決して歓迎するものではなく、人生の中で最もストレスの多い時間の1つになるでしょう。
前任のDBAのソリューションやスクリプトを解析したり、データベースを手動で再構築したりすることは、最もやりたくないことです。StandbyMPは、セットアップと管理を標準化することで、DRプロセスを簡素化することができます。さらに、自動化されたフェイルオーバーによって、復旧プロセスも大幅に簡素化されます。
スケールアップする場合、フェイルオーバープロセスは、必要な数のデータベースに対して同時に実行することができ、完全なフェイルオーバーをわずか数分で完了させることができます。
理由その３：ワークフローの簡素化とスピードアップ
誰もがより少ないリソースでより多くの作業を行うことを求められておりますが、私たち（DBAを含む）の誰もが、数多くのデータベースとインスタンスにまたがる手動のリカバリ手順とスクリプトを常にテストする時間を持っていないでしょう。多くの異なるデータベースに対して複数の基本可用性グループ（SQL ServerのAlwaysOn Basic Availability Groups）を管理し、ログシッピングを行うスタンバイデータベースを散在させることは、持続可能で拡張可能なやり方ではありません。
それに対して、複数のツールや個別のデータベースで運用するよりも、StandbyMPを使えば、1つの中央コンソールからすべてのDR構成を表示・管理できるのです。
1つのコンソールですべての設定を可視化することはそれだけで強力ですが、さらに、ワンクリックアクションで複雑な手順を簡素化したり、マルチデータベースアクションでタスクを同時に実行したりすることもできます。
理由その４：あらゆる災害に対するレジリエンスを最大化
先に述べたように、DBAとしては、インシデントの種類に関係なく、DR戦略がうまくいくことを100%確信する必要があります。しかし、これをSQL Server Standard Editionで実現するのは困難です。
SQL Serverに対応できるStandbyMPは、低帯域幅のアーキテクチャ、デュアルスタンバイ機能、カスタマイズ可能なログギャップディレイを備えています。このため、あらゆる災害シナリオにおいて、RPOとRTOの要件を満たすことができます。
必要であれば、地理的に異なる場所に2つのスタンバイデータベースを簡単にセットアップし、一方を時間差で稼働させることで、ランサムウェアや内部犯行シナリオに対する保護を強化することも可能なのです。
理由その５：ディザスタリカバリは難しくなく、高価でもありません
DRの導入で多くの組織にとって大きな障壁となるのは、DRのような重大なプロセスの見直しが、複雑でコストがかかるのではないかという懸念です。
しかし、StandbyMPの導入に大規模な構築プロジェクトは必要ありません。StandbyMPは、現在お使いの環境で動作でき、追加の前提条件もなく簡単にインストールできます。つまり、1時間以内にDRを構築することができるのです！ぜひトライアルで試してみてください。驚くほど簡単です。
SQL Serverの基本的なAlwaysOn可用性グループを利用する場合、各ノードでWSFCを設定したり、サーバー間で正しいユーザーと権限を設定したり、各データベースに個別のAGを作成する必要があります。これとStandbyMPをぜひ比較してみてください。
おわりに：DBAだって休暇を取りたい！
DBAだって、休暇を取ったり、誕生日に休んだり、休日に邪魔されたくないのは当然です。複雑なオーダーメイドのプロセスを標準化された直感的なDRに置き換えることで、DBAはデータベースの継続性に関して共同で取り組み、ディザスタリカバリの責任を共有することができるようになります。
StandbyMPが提供する「SQL Serverにおける基本的なAlways On可用性グループとログシッピング以上のもの」とはどんなものでしょうか？まとめると、以下のような特徴となります。
- 導入のしやすさ。優れたDRは、システムを調整したり、再設計したりすることなく実装することができます。
- ワークフローの簡素化とスピードアップ。複数のインスタンスやデータベースプラットフォームにまたがる、マルチデータベースアクションも含めて対応できます。
- 複雑さを解消。ワンクリックアクションとガイド付きワークフローにより、手動スクリプトと手動プロセスをなくします。
- レジリエンスの最大化。ウォームスタンバイデータベースへの自動リカバリにより、あらゆる災害から迅速に回復できます。
- DR計画を改善。すべてのインスタンスとデータベースプラットフォーム（SQL Server、Oracle SE、およびまもなくPostgreSQL）に優れたDRを一貫して実装します。
StandbyMPに興味を持たれた方は、ぜひ以下よりお問い合わせください。
