翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# SQL Server の同種データベースの移行
AWS は、クラウド環境で SQL Server データベースを実行する機能を提供します。開発者やデータベース管理者にとって、 AWS クラウドで SQL Server データベースを実行することは、データセンターで SQL Server データベースを実行することと非常によく似ています。このセクションでは、SQL Server データベースをオンプレミス環境またはデータセンターから AWS クラウドに移行するためのオプションについて説明します。
AWS は、次の表に示すように AWS、 で SQL Server を実行するための 3 つのオプションを提供します。
****
| オプション | ハイライト | 詳細情報 |
| --- | --- | --- |
| Amazon RDS 上の Microsoft SQL Server | マネージド型サービス。プロビジョニングとライセンシングが容易で、費用対効果が高く、セットアップ、管理、保守が容易です。 | [Amazon RDS for SQL Server](rds-sql.md) |
| Amazon RDS Custom for SQL Server | マネージドサービスですが、データベースと基盤となるオペレーティングシステムの管理者権限は保持されます。 | [Amazon RDS Custom for SQL Server](rds-custom-sql.md) |
| Amazon EC2 上のサーバー | 自己管理型で、完全な制御と柔軟性を実現します。 | [Amazon EC2 for SQL Server](ec2-sql.md) セクション |
| SQL Server on VMware Cloud on AWS | VMware Cloud on で SQL Server ワークロードをセットアップ、スケーリング、運用 AWS し Directory Service、Active Directory Connector、Amazon S3 と統合します。 | [VMware Cloud on AWS for SQL Server](vmware-sql.md) セクション |
**注意**
2024 年 4 月 30 日現在、VMware Cloud on AWS は AWS またはそのチャネルパートナーによって再販されなくなりました。サービスは Broadcom を通じて引き続き提供されます。詳細については、 AWS 担当者にお問い合わせください。
アプリケーションの要件、データベースの特徴、機能性、成長能力、全体的なアーキテクチャの複雑さによって、どのオプションを選択するかが決まります。複数の SQL Server データベースを に移行する場合 AWS、Amazon RDS に適したものもあれば、Amazon EC2 で直接実行するのに適したものもあります。SQL Server エンタープライズエディションで実行されているが、SQL Server スタンダードエディションには適しているデータベースがあるかもしれません。コストとライセンスを節約するために、Windows 上で稼働している SQL Server データベースを Linux オペレーティングシステムで実行するようにモダナイズしたい場合もあります。多くの AWS お客様は、Amazon RDS、Amazon EC2、VMware Cloud on で複数の SQL Server データベースワークロードを実行します AWS。
**注記**
Migration Hub Orchestrator を使用すると、ネイティブバックアップと復元を使用して、SQL Server データベースを Amazon EC2 または Amazon RDS に移行することを自動化およびオーケストレートできます。詳細については、「 [AWS Migration Hub Orchestrator セクション](mho.md)」を参照してください。
# Amazon RDS for SQL Server
Amazon RDS for SQL Serverは、 AWS上のSQL Serverのプロビジョニングと管理を簡素化するマネージドデータベースサービスです。Amazon RDS を使用すると、クラウドで SQL Server デプロイを簡単に設定、運用、および拡張することができます。Amazon RDS を使用すると、SQL Server の複数のバージョン (2014、2016、2017、2019、2022) とエディション (エクスプレス、ウェブ、スタンダード、エンタープライズを含む) を数分でデプロイでき、費用対効果が高く、サイズ変更も可能なコンピューティング能力を備えています。Amazon RDS for SQL Server DB インスタンスは、汎用 SSD またはプロビジョンド IOPS SSD のストレージを使用してプロビジョニングすることができます。(詳細については、 AWS ドキュメントの[「Amazon RDS ストレージタイプ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage)」を参照してください）。プロビジョンド IOPS SSD は、高速で予測可能で一貫した I/O パフォーマンスを実現するように設計されており、I/O 集約型のトランザクション (OLTP) データベースワークロード向けに最適化されています。
Amazon RDS では、プロビジョニング、バックアップ、ソフトウェアパッチ適用、モニタリング、ハードウェアスケーリングなど、時間のかかるデータベース管理タスクが管理されるため、ユーザーはアプリケーション開発に集中することができます。Amazon RDS for SQL Server では、本番環境のワークロードに高い可用性、パフォーマンス、スケーラビリティ、信頼性を提供するために、マルチ AZ 配置とリードレプリカ (SQL Server Enterprise エディション用) も提供しています。
## Amazon RDS を選ぶタイミング
Amazon RDS for SQL Serverは、次のような場合の移行オプションです：
+ ビジネスとアプリケーションに集中し、データベースのプロビジョニング、バックアップと復旧タスクの管理、セキュリティパッチの管理、SQL Server のマイナーバージョンアップグレード、ストレージ管理など、差別化されていない重労働タスク AWS を処理したいと考えています。
+ 可用性の高いデータベースソリューションが必要であり、データベースミラーリング、フェイルオーバークラスター、またはフェイルオーバー常時オン可用性グループを手動で設定して管理しなくても、Amazon RDS が提供するプッシュボタン式の同期マルチ AZ レプリケーションを活用したいと考えています。
+ 多額の先行投資を行うのではなく、SQL Server ライセンスの料金をインスタンスコストの一部として 1 時間単位で支払う必要があります。
+ データベースのサイズと IOPS のニーズは、Amazon RDS for SQL Server) でサポートされています。現在の最大制限については、 AWS ドキュメントの[「Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。
+ データベースのバックアップやポイントインタイムリカバリを管理する必要はありません。
+ 日常的なデータベース管理ではなく、パフォーマンスチューニングやスキーマの最適化などの高レベルのタスクに集中したい場合。
+ ライセンスの複雑さを気にせずに、ワークロードパターンに基づいてインスタンスタイプをスケールアップまたはスケールダウンしたいと考えている場合。
データベースとプロジェクトの要件を評価した後、Amazon RDS for SQL Server への移行を決定した場合は、以下のセクションに記載されている詳細を確認し、このガイドの後半で説明する[移行のベストプラクティス](best-practices.md)を確認してください。
現在サポートされている SQL Server の機能、バージョン、およびオプションについては、 AWS ウェブサイトの「Amazon [RDS for SQL Server の機能](https://aws.amazon.com/rds/sqlserver/features/)[」、このガイドの後半のAmazon EC2 と Amazon RDS の選択](comparison.md)」、および AWS ドキュメントの[「Amazon RDS 上の Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html)」を参照してください。Amazon RDS Customに移行する場合は、[Amazon RDS Custom for SQL Serverの要件と制限を確認してください](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html)。
## 高可用性
Amazon RDS は、マルチ AZ オプションを使用してデプロイされたデータベースの高可用性とフェイルオーバーサポートを提供します。マルチ AZ オプションでデータベースをプロビジョニングすると、Amazon RDS は自動的に別のアベイラビリティゾーンに同期スタンバイインスタンスをプロビジョニングし、維持します。プライマリ・データベースはデータをスタンバイインスタンスに同期的にレプリケートします。問題が発生した場合、Amazon RDS は異常のあるインスタンスを自動的に修復し、同期を再確立します。インフラストラクチャに障害またはアベイラビリティーゾーンに障害が発生した場合、Amazon RDS ではスタンバイインスタンスへの自動フェイルオーバーが実行されます。フェイルオーバーは、スタンバイとプライマリが完全に同期している場合にのみスタートします。エンドポイントはプライマリインスタンスとスタンバイインスタンスで同じままなので、手動で操作しなくても、フェイルオーバーが完了するとすぐにデータベース運用を再開することができます。フェイルオーバー時間は、復旧プロセスの完了までにかかる時間の影響を受けます。大量のトランザクションがあると、フェイルオーバー時間はより長くなります。
次の図は、Amazon RDS for SQL Server) マルチ AZ 配置オプションを示しています。
![\[Amazon RDS for SQL Server in a Multi-AZ configuration\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-ha.png)
マルチ AZ 設定で SQL Server をセットアップすると、Amazon RDS は、デプロイする SQL Server のバージョンに基づいて、データベースミラーリングまたは Always On 可用性グループを使用してスタンバイデータベースインスタンスを自動的に設定します。特定の SQL Server のバージョンとエディションは、[Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html)に記載されています。
マルチ AZ 配置では、可用性を高めるため、インスタンスのスケーリングやオペレーティングシステム (OS) のパッチ適用などのシステムアップグレードといったオペレーションは、プライマリインスタンスの自動フェイルオーバーの前にスタンバイインスタンスで最初に適用されます。
SQL Server のフェイルオーバー最適化により、特定のワークロードでは、特にデータベースミラーリングデプロイでは、プライマリインスタンスよりもスタンバイインスタンスの I/O 負荷が大きくなることがあります。この機能により、スタンバイインスタンスの IOPS が高くなる可能性があります。Amazon RDS for SQL Server DB インスタンスのストレージタイプと IOPS をプロビジョニングするときは、プライマリインスタンスとスタンバイインスタンスの両方の最大 IOPS ニーズを考慮することをお勧めします。また、クライアントドライバーが`MultiSubnetFailover=True`をサポートしていれば、それを指定してフェイルオーバーの時間を大幅に短縮することもできます。
### 制限事項
+ マルチ AZ オプションは SQL Server Express とウェブエディションでは使用することができません。SQL Server Standard と Enterprise エディションでのみ利用可能です。
+ データベースの読み取りアクティビティを受け入れるように、セカンダリ DB インスタンスを設定することはできません。
+ クロスリージョンマルチ AZ はサポートされていません。
+ Amazon RDS では、スタンドアロン DB インスタンスに停止コマンドを発行し、インスタンスを停止状態に保つことで、コンピューティング料金が発生しないようにすることができます。マルチ AZ 設定の Amazon RDS for SQL Server DB インスタンスは停止できません。代わりに、インスタンスを終了し、終了前に最終スナップショットを作成し、必要なときにそのスナップショットから新しい Amazon RDS インスタンスを再作成することができます。または、マルチ AZ 設定を先に削除してからインスタンスを停止することもできます。7 日後、停止したインスタンスは再起動され、保留中のメンテナンスを適用できるようになります。
その他の制限事項については、Amazon RDS ドキュメントの [Microsoft SQL Server マルチ AZ 配置の注意事項と推奨事項](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Recommendations)を参照してください。
## リードレプリカ
リードレプリカはスケーラビリティとロードバランサーを実現します。SQL Server リードレプリカは、Amazon RDS for SQL Server DB インスタンスの物理コピーであり、読み取り専用に使用されます。Amazon RDS は、読み取り専用のワークロードをリードレプリカ DB インスタンスにオフロードすることで、プライマリ DB インスタンスの負荷を軽減します。プライマリ DB インスタンスに対して行った更新は、リードレプリカに非同期的にコピーされます。
リードレプリカを作成すると、Amazon RDS によりソースインスタンスのスナップショットが作成され、リードレプリカ にスナップショットが転送されます。リードレプリカの作成と削除中に障害が発生することはありません。Amazon RDS for SQL Server では、メンテナンスウィンドウに関係なく、リードレプリカがアップグレードされた後すぐにプライマリデータベースがアップグレードされます。すべてのリードレプリカには、リードレプリカデータベースへの接続に使用する個別のエンドポイントが付属しています。
Amazon RDS for SQL Server では、Always On 可用性グループを設定し、プライマリ DB インスタンスとそのリードレプリカ間の安全なネットワーク接続を維持することで、リードレプリカの作成が簡単にできます。
リードレプリカは、プライマリデータベースと同じ AWS リージョン、または別の リージョンで設定できます。1 つのソース DB インスタンスから最大 5 つのリードレプリカを作成できます。
**注記**
リードレプリカは、次の SQL Server のバージョンとエディションでのみ使用できます。
SQL Server 2017: Enterprise Edition 14.00.3049.1 以降
SQL Server 2016 Enterprise Edition 13.00.5216.0 以降
マルチ AZ 環境のデータベースミラーリングをサポートする SQL Server のバージョンとエディションには、リードレプリカはありません。
次の図は、同じ AWS リージョン内の別のアベイラビリティーゾーンにリードレプリカがあるマルチ AZ 環境の Amazon RDS for SQL Server DB インスタンスを示しています。すべての AWS リージョンが 3 つ以上のアベイラビリティーゾーンを提供しているわけではないため、この戦略を採用する前に、使用する予定の[リージョンを確認](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)する必要があります。
![\[Amazon RDS for SQL Server with a read replica in another Availability Zone in the same Region\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-rr-same-region.png)
SQL Server のリードレプリカでは書き込み操作はできません。リードレプリカを昇格させて書き込み可能にすることができます。いったんプロモートすると、リードレプリカに戻すことはできません。元のプライマリデータベースインスタンスとは関係のない単一のスタンドアロン DB インスタンスになります。昇格したリードレプリカのデータは、昇格をリクエストされた時点までのソース DB インスタンスのデータと一致します。ソース DB インスタンスとそのすべてのリードレプリカの SQL Server DB エンジンバージョンは同じである必要があります。
効率的なレプリケーションを行うには、次の手順をお勧めします。
+ 各リードレプリカに、ソース DB インスタンスと同じコンピューティングリソースとストレージリソースを設定します。
+ 最初に、バックアップ保持期間を 0 以外の値に設定することで、ソース DB インスタンスで自動バックアップを有効にする必要があります。
+ ソース DB インスタンスは、AlwaysOn 可用性グループ (AG) を持つマルチ AZ 配置である必要があります。
SQL Server のバージョンサポート、エディション、制限については、Amazon RDS ドキュメントの 「[SQL Server でのリードレプリカの制限](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html#SQLServer.ReadReplicas.Limitations)」を参照してください。
リードレプリカの使用の詳細については、 AWS ドキュメントの[「リードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)」および[「Amazon RDS の SQL Server リードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html)」を参照してください。データ転送料金の詳細については、「[Amazon RDS の料金](https://aws.amazon.com/rds/pricing/)」を参照してください。
## ディザスタリカバリ
Amazon RDS for SQL Server を使用すると、信頼性の高いクロスリージョンディザスタリカバリ (DR) 戦略を構築することができます。DR ソリューションを作成する主な理由は、事業継続性とコンプライアンスです。
+ 効果的な DR 戦略は、壊滅的な事態が発生してもシステムを最小限に、またはまったく中断せずに稼働させ続けるのに役立ちます。信頼性が高く効果的なクロスリージョン DR 戦略があれば、リージョン全体がオフラインになっても事業を継続することができます。
+ クロスリージョン DR ソリューションは、監査とコンプライアンスの要件を満たすのに役立ちます。
目標復旧時点 (RPO)、目標復旧時間 (RTO) とコストは、DR 戦略を策定する際に考慮すべき 3 つの重要な指標です。クロスリージョンレプリカを提供するその他のオプションについては、[AWS Marketplace](https://aws.amazon.com/marketplace/)を参照してください。これらのアプローチの詳細については、 AWS データベースブログの[「Amazon RDS for SQL Server のクロスリージョンディザスタリカバリ](https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-of-amazon-rds-for-sql-server/)」を参照してください。
# Amazon RDS Custom for SQL Server
サードパーティアプリケーションのカスタマイズ要件のために Amazon RDS などの完全マネージド型サービスへの移行ができない場合は、SQL Server 用 Amazon RDS Custom に移行することができます。依存型アプリケーションを利用するために、データベースと基盤となるオペレーティングシステムの管理者権限を保持することが必要な場合、Amazon RDS Custom が適しています。
## Amazon RDS Custom for SQL Server
Amazon RDS Custom for SQL Server は、次の場合に適した移行オプションです。
+ 基盤となる OS とデータベース環境へのアクセスを必要とするレガシー、カスタム、およびパッケージアプリケーションを有している場合。
+ ベンダーベースのアプリケーションデプロイ要件を満たすには、管理ユーザーアクセスが必要です。
+ このアクセス権により、設定の構成、パッチのインストール、ネイティブ機能の有効化を行って、依存型アプリケーションの要件を満たすために、基盤となる OS にアクセスする必要がある場合。
+ データベースやアプリケーションのニーズに合わせて、データベース環境にアクセスしてカスタマイズしたい場合 (カスタムデータベースパッチを適用したり OS パッケージを変更したりする)。
## 仕組み
Amazon RDS Custom for SQL Server を使用するには、Amazon RDS Custom for SQL Server ドキュメントの[要件](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.reqsMS)を確認してください。[Amazon RDS のドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-setup-sqlserver.html)で説明されているように、Amazon RDS Custom for SQL Server の環境を設定する必要があります。環境を設定したら、以下の図に示す手順に従ってください：
1. Amazon RDS Custom が提供するエンジンバージョンから、RDS Custom for SQL Serverの DB インスタンスを作成します。
Amazon RDS Custom for SQL Server は現在、ドキュメントに記載済みの[サポートされている DB インスタンスクラス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.instancesMS)で SQL Server 2019、SQL Server 2022、Windows 2019 をサポートしています。詳細については、「[RDS Custom for SQL Server DB インスタンスの起動と停止](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.create)」を参照してください。
1. アプリケーションを Amazon RDS Custom DB インスタンスエンドポイントに接続します。
詳細については、 AWS Systems Managerを使用して「[RDS カスタム DB インスタンスに接続する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.ssm)」、および「[RDP を使用して RDS カスタム DB インスタンスに接続する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.rdp)」を参照してください。
1. (オプション) ホストにアクセスしてソフトウェアをカスタマイズします。
1. Amazon RDS Custom オートメーションによって生成された通知とメッセージをモニタリングします。
これらのステップの詳細については、[Amazon RDS Custom ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-sqlserver.workflow.html)を参照してください。
![\[Amazon RDS Custom for SQL Server のワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/custom-rds-sql-server.png)
Amazon RDS Custom はマネージドデータベースサービスであり、クラウドｄえのデータベースのセットアップ、運用、スケーリングを自動化し、基盤となるオペレーティングシステムおよびデータベース環境へのアクセスを許可します。Amazon RDS Custom for SQL Server では、ソフトウェアをインストールして、カスタムアプリケーションとエージェントを実行できます。ホストへの特権アクセス権があるため、レガシーアプリケーションをサポートするためにファイルシステムを変更できます。Amazon RDS Custom DB インスタンスで、カスタムデータベースパッチを適用したり OS パッケージを変更したりできます。
インスタンスをカスタマイズする場合は、Amazon RDS Custom の自動化を最大 24 時間一時停止し、カスタマイズ作業が完了したら再開ができます。自動化を一時停止することで、Amazon RDS の自動化がカスタマイズに直接干渉するのを防ぐことができます。
自動化を再開すると、[サポート範囲](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-troubleshooting.html#custom-troubleshooting.support-perimeter)によって、データベースまたはオペレーティングシステム環境のカスタマイズが Amazon RDS Custom 自動化に干渉するのか、それとも中断するのかが決まります。Amazon RDS Custom は、変更によって DB インスタンスがサポート範囲外にならない限り、ホストとデータベース環境のカスタマイズをサポートします。サポート範囲のチェックはデフォルトで 30 分ごとに実行され、スナップショットの削除や DB インスタンスをモニタリングする Amazon RDS Custom エージェントのアンインストールなどのイベントの後にも行われます。Amazon RDS Custom エージェントは Amazon RDS Custom 機能を確保するための重要なコンポーネントです。エージェントをアンインストールすると、Amazon RDS Custom は 1 分後にサポート境界チェックを実行し、DB インスタンスをサポート境界外に移動します。
Amazon RDS Custom for SQL Server 用の Amazon RDS DB インスタンスを設定すると、ソフトウェアライセンス込みのインスタンスとなります。つまり、SQL Server のライセンスを別途購入する必要はありません。ライセンスの詳細については、[AWS サービス条件](https://aws.amazon.com/service-terms/)のセクション10.5を参照してください。アクティブな AWS プレミアムサポートアカウントをお持ちの場合は、Amazon RDS Custom for SQL Server 固有の問題の AWS プレミアムサポートにお問い合わせください。
Amazon RDS Custom for SQL Server は、限られた DB インスタンスクラスの限られた選択 AWS リージョン と でサポートされています。これらおよびその他の制限事項については、Amazon RDS Custom for SQL Server ドキュメントの[要件と制限事項](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html)のページを参照してください。
オンプレミス SQL Server データベースがある場合は、[Amazon RDS ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-migrating.html)で説明されているプロセスに従って、ネイティブのバックアップまたは復元ユーティリティを使用して Amazon RDS Custom for SQL Server に移行することができます。
詳細については、次のリソースを参照してください。
+ [新規 – Amazon RDS Custom for SQL Server が一般公開](https://aws.amazon.com/blogs/aws/new-amazon-rds-custom-for-sql-server-is-generally-available/) (AWS ニュースブログ)
+ [Amazon RDS Custom for SQL Server と Amazon RDS for SQL Server 間の SQL Server レプリケーションを設定する](https://aws.amazon.com/blogs/database/configure-sql-server-replication-between-amazon-rds-custom-for-sql-server-and-amazon-rds-for-sql-server/) (AWS データベースブログ)
+ [カスタムログ配信を使用してオンプレミスまたは Amazon EC2 SQL Server から Amazon RDS for SQL Server への移行を自動化する](https://aws.amazon.com/blogs/database/automate-on-premises-or-amazon-ec2-sql-server-to-amazon-rds-for-sql-server-migration-using-custom-log-shipping/) (AWS データベースブログ)
+ [Amazon RDS Custom for SQL Server で Always On 可用性グループを使用して高可用性を設定する](https://aws.amazon.com/blogs/database/configure-high-availability-with-always-on-availability-groups-on-amazon-rds-custom-for-sql-server/) (AWS データベースブログ)
+ [CloudFormation テンプレートを使用して Amazon RDS Custom for SQL Server の使用を開始する (ネットワーク設定)](https://aws.amazon.com/blogs/database/get-started-with-amazon-rds-custom-for-sql-server-using-an-aws-cloudformation-template-network-setup/) (AWS データベースブログ)
+ [分散可用性グループを使用してオンプレミスの SQL Server ワークロードを Amazon RDS Custom for SQL Server に移行する](https://aws.amazon.com/blogs/database/migrate-on-premises-sql-server-workloads-to-amazon-rds-custom-for-sql-server-using-distributed-availability-groups/) (AWS データベースブログ)
+ [Amazon RDS Custom for SQL Server で Bring Your Own Media (BYOM) を使用して SQL Server のコストを最適化する](https://aws.amazon.com/blogs/database/optimize-your-sql-server-costs-by-using-bring-your-own-media-byom-on-amazon-rds-custom-for-sql-server/) (AWS データベースブログ)
# Amazon EC2 for SQL Server セクション
Amazon EC2 は、自己管理 SQL Server データベースをサポートしています。つまり、インフラストラクチャとデータベース環境のセットアップを完全に制御することができます。Amazon EC2 でデータベースを実行することは、独自のサーバーでデータベースを実行することとよく似ています。データベースとオペレーティングシステムレベルのアクセスを完全に制御できるため、選択したツールを使用して、オペレーティングシステム、データベースソフトウェア、パッチ、データ複製、バックアップ、および復元を管理することができます。この移行オプションでは、 AWS アーキテクチャのベストプラクティスに基づいて、EC2 インスタンス、ストレージボリューム、スケーラビリティ、ネットワーク、セキュリティなど、すべてのコンポーネントを設定、設定、管理、調整する必要があります。同じリージョンまたは異なる AWS リージョンのインスタンス間でのデータレプリケーションとリカバリは、お客様の責任となります。
## Amazon EC2 を選ぶタイミング
Amazon EC2 は、以下の場合に SQL Server データベースの移行オプションとして適しています。
+ データベースを完全に制御し、基盤となるオペレーティングシステム、データベースのインストール、設定にアクセスする必要があります。
+ バックアップとリカバリ、オペレーティングシステムとデータベースへのパッチ適用、オペレーティングシステムとデータベースパラメータの調整、セキュリティの管理、高可用性またはレプリケーションの設定など、データベースを管理したい場合。
+ Amazon RDS が現在サポートしていない機能やオプションを使いたい場合。詳細については、Amazon RDS ドキュメントの「[サポートされていない機能とサポートが制限されている機能](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport)」を参照してください。
+ Amazon RDS でサポートされていない特定の SQL Server バージョンが必要です。サポートされているバージョンとエディションのリストについては、Amazon RDS ドキュメントの 「[Amazon RDS での SQL Server バージョン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport)」を参照してください。
+ データベースのサイズとパフォーマンス要件は、現在の Amazon RDS for SQL Server サービスを超えています。詳細については、Amazon RDS ドキュメントの「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。
+ アプリケーションに適合しない可能性がある自動ソフトウェアパッチは避けたいです。
+ Amazon RDS for SQL Server のライセンス込みモデルを使用する代わりに、独自のライセンスを持参する必要があります。
+ 現在の制限よりも高い IOPS とストレージ容量を実現したい場合。詳細については、Amazon RDS ドキュメントの「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。
Amazon EC2 で現在サポートされている SQL Server の機能とバージョンのリストについては、このガイドの後半にある「[Amazon EC2 と Amazon RDS から選択する](comparison.md)」を参照してください。
# 高可用性
Amazon EC2 上の SQL Server データベースでは、SQL Server がサポートする任意のレプリケーションテクノロジーを使用して、高可用性、データ保護、およびディザスタリカバリを実現することができます。一般的なソリューションには、ログ配布、データベースミラーリング、Always On 可用性グループ、Always On フェイルオーバークラスターインスタンスなどがあります。
次の図は、1 つの AWS リージョン内の複数のアベイラビリティーゾーンで Amazon EC2 で SQL Server を使用する方法を示しています。プライマリデータベースは読み書き可能なデータベースであり、セカンダリデータベースは高可用性のためにログシッピング、データベースミラーリング、またはAlways On可用性グループによって設定されます。プライマリデータベースからのトランザクションデータはすべて転送され、ログ配布の場合は非同期でセカンダリデータベースに適用でき、Always On 可用性グループとミラーリングの場合は非同期で適用できます。
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# ログ配布
ログ配布では、プライマリデータベースインスタンスから別の DB インスタンスにある 1 つ以上のセカンダリデータベース(*ウォームスタンバイ*とも呼ばれる)にトランザクションログのバックアップを自動的に送信できます。ログ配布では、SQL Server エージェントジョブを使用して、トランザクションログバックアップのバックアップ、コピー、適用を自動化します。ログ配布は一般的にディザスタリカバリ機能と考えられていますが、プライマリ DB インスタンスに障害が発生した場合にセカンダリ DB インスタンスを昇格できるようにすることで、高い可用性を実現することもできます。RTO と RPO に柔軟性がある場合や、データベースがそれほどミッションクリティカルではないと考えられる場合は、ログ配布を使用して SQL Server データベースの可用性を高めることを検討してください。
ログ配布では、必要に応じてプライマリデータベースの読み取り専用コピーとして使用できるセカンダリデータベースにアクセスできるようになるため、データベースの可用性が向上されます。セカンダリ・データベースに変更が反映される前に、プライマリ・データベースで誤って変更されたデー タをリカバリできる遅延時間 (より長い遅延時間) を設定することができます。
プライマリ DB インスタンスとセカンダリ DB インスタンスを別々のアベイラビリティーゾーンで実行し、モニタリングインスタンスをデプロイしてログ配布の詳細をすべて追跡することをお勧めします。ログ配布グループのバックアップ、コピー、復元、または障害イベントは、モニターインスタンスから利用できます。ログ配布設定は、プライマリサーバーからセカンダリサーバーに自動的にフェールオーバーされません。ただし、プライマリーデータベースが利用できなくなった場合、どのセカンダリーデータベースも手動でオンラインにすることができます。
ログ配布はディザスタリカバリソリューションとしてよく使用されますが、アプリケーションの要件によっては高可用性ソリューションとしても使用できます。ログ配布は次の場合に使用します。
+ RTO と RPO の要件は柔軟に設定することができます。ログ配布は RPO を数分、RTO を数分から数時間で提供します。
+ セカンダリデータベースへの自動フェイルオーバーは必要ではありません。
+ セカンダリデータベースからデータを読みたい場合、リストア操作中に読み取り可能である必要はありません。
MARS の詳細については、[ Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server) のドキュメントを参照してください。
# データベースのミラーリング
データベースミラーリングは EC2 インスタンス上にあるデータベースを、完全またはほぼ完全な読み取り専用コピー (ミラー) を別の DB インスタンスに提供します。Amazon RDS はデータベースミラーリングを使用して、Amazon RDS for SQL Server のマルチ AZ サポートを提供しています。この機能により、データベースの可用性と保護が向上し、アップグレード中もデータベースを使用可能な状態に保つメカニズムが提供されます。
**注記**
[Microsoft のドキュメント](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server)によると、データベースミラーリングはSQL Serverの将来のバージョンで削除される予定です。代わりに Always On可用性グループを使用するよう計画してください。
データベースミラーリングでは、SQL サーバーは次の 3 つの役割のいずれかを担うことができます。
+ プライマリ読み取り/書き込みバージョンのデータベースをホストするプリンシパルサーバー。
+ プリンシパルデータベースのコピーをホストするミラーサーバー。
+ オプションの監視サーバー。このサーバーは高安全モードでのみ使用可能です。データベースミラーの状態をモニタリングし、プライマリデータベースからミラーデータベースへのフェイルオーバーを自動化します。
プリンシパルサーバーとミラーサーバーの間でミラーリングセッションが確立されます。ミラーリング中、プリンシパルデータベースで行われたすべてのデータベース変更は、ミラーデータベースでも実行されます。データベースミラーリングは、同期操作でも非同期操作でもかまいません。これは、高安全モードと高性能モードという 2 つのミラーリング動作モードによって決まります。
+ **高安全モード**:このモードは同期操作を使用します。このモードでは、データベースミラーリングセッションは、挿入、更新、削除操作をプリンシパルデータベースからミラーデータベースにできるだけ早く同期します。データベースが同期されるとすぐに、トランザクションはプリンシパルデータベースとミラーデータベースの両方でコミットされます。ミラーデータベースが同じまたは異なるアベイラビリティーゾーンにあるが、同じ AWS リージョン内でホストされている場合は、このオペレーションモードを使用することをお勧めします。
+ **高性能モード:**このモードでは、非同期オペレーションを使用します。このモードでは、データベースミラーリングセッションは挿入、更新、削除操作をプリンシパルデータベースからミラーデータベースに同期しますが、プリンシパルデータベースがトランザクションをコミットしてからミラーデータベースがトランザクションをコミットするまでに時間差が生じることがあります。ミラーデータベースが異なる AWS リージョンにある場合は、このモードを使用することをお勧めします。
データベースミラーリングは次の場合に使用します。
+ RTO と RPO の要件が厳しく、プライマリデータベースとセカンダリデータベース間の遅延があってはなりません。データベースミラーリングでは、RPO は 0 秒 (同期コミットの場合)、数秒から数分の RTO を提供する。
+ セカンダリデータベースから読み取る必要はありません。
+ ミラーリング監視サーバーが同期モードに設定されている場合は、自動フェイルオーバーを実行したい場合。
+ 推奨オプションである Always On 可用性グループは使用できません。
機能制限:
+ 1 対 1 のフェイルオーバーのみがサポートされます。複数のデータベース宛先をプライマリデータベースと同期させることはできません。
MARS の詳細については、[ Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server) のドキュメントを参照してください。
# Always On 可用性グループ
SQL Server Always On 可用性グループは、SQL Server データベースの高可用性とディザスタリカバリソリューションを提供します。可用性グループは、フェイルオーバーされるユーザーデータベースのセットで構成されます。これには、1 セットの読み取り/書き込み可能なプライマリデータベースと、複数セット (1 ～ 8) の関連するセカンダリデータベースが含まれます。セカンダリデータベースをプライマリデータベース (SQL Server Enterprise エディションのみ) の読み取り専用コピーとしてアプリケーション層で利用できるようにして、読み取りワークロードのスケールアウトアーキテクチャを実現することができます。セカンダリデータベースはバックアップ操作に使用することもできます。
SQL Server Always On 可用性グループは、同期コミットモードと非同期コミットモードの両方をサポートしています。同期モードでは、変更がコミットされたり、セカンダリレプリカのログに書き込まれたりした後に、プライマリレプリカがデータベーストランザクションをコミットします。このモードを使用すると、計画的な手動フェイルオーバーと、レプリカが同期している場合の自動フェイルオーバーを実行することができます。同じ環境内の SQL Server インスタンス間で同期コミットモードを使用できます (たとえば、すべてのインスタンスがオンプレミスであるか、すべてのインスタンスが にある場合) AWS。
非同期コミットモードでは、プライマリレプリカはセカンダリレプリカを待たずにデータベーストランザクションをコミットします。異なる環境にある SQL Server インスタンス間で非同期コミットモードを使用できます (たとえば、オンプレミスと にインスタンスがある場合) AWS。
Always On 可用性グループは高可用性またはディザスタリカバリに使用することができます。この方法は次の場合に使用します。
+ RTO と RPO の要件は柔軟に設定することができます。Always On 可用性グループでは、RPO は秒単位、RTO は秒単位から分単位です。
+ データベースグループを管理し、フェイルオーバーしたい場合。Always On 可用性グループは、SQL Server 2019 の同期コミットモードで 0 ～ 4 個のセカンダリレプリカをサポートします。
+ 同期コミットモードでは自動フェイルオーバーを使用したい場合、監視サーバーは必要ではありません。
+ セカンダリデータベースから読みたい場合。
+ 複数のデータベース宛先をプライマリデータベースと同期したい場合。
SQL Server 2016 SP1 以降の SQL Server Standard エディションでは、可用性グループごとに 1 つの読み取り不可能なセカンダリデータベースとリスナーに基本的な高可用性が提供されます。また、可用性グループごとに最大 2 つのノードをサポートします。
# フェイルオーバー常時稼働のフェールオーバークラスターインスタンス
SQL Server Always On フェイルオーバークラスターインスタンス (FCI) は Windows Server フェイルオーバークラスタリング (WSFC) を使用して、サーバーインスタンスレベルで高可用性を提供します。FCI は SQL Server の単一インスタンスで、複数の WSFC ノードにインストールされます。これにより、SQL Server のインストール全体にわたって高可用性が実現されます。基盤となるノードでハードウェア、オペレーティングシステム、アプリケーション、またはサービスの障害が発生した場合、SQL Server インスタンス内のすべてが別の WSFC ノードに移動されます。これには、システムデータベース、SQL Server ログイン、SQL Server エージェントジョブと、証明書が含まれます。
通常、次の場合は Always on 可用性グループよりも FCI の方が適しています。
+ エンタープライズエディションの代わりに SQL Server スタンダードエディションを使用しています。
+ インスタンスごとに多数の小規模データベースがあります。
+ SQL Server エージェントのジョブ、ログインなどのインスタンスレベルのオブジェクトを絶えず変更しています。
に FCIsをデプロイするには、次の 4 つのオプションがあります AWS。
+ 永続予約機能を搭載した Amazon EBS Multi-Attach
+ Amazon FSx for Windows File Server
+ Amazon FSx for NetApp ONTAP
+ AWS パートナーからのソリューション
## 永続予約機能を搭載した Amazon EBS Multi-Attach の使用
[Amazon EBS Multi-Attach と NVMe 予約](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html)は、Windows Server フェイルオーバークラスターの共有ストレージとして Amazon EBS `io2` ボリュームを使用した SQL Server FCI の作成をサポートします。この機能は、Amazon EBS `io2`ボリュームを使用してフェイルオーバークラスターを構築できるようにすることで、フェイルオーバークラスターのセットアッププロセスを簡素化します。これらのボリュームは、インスタンスと同じアベイラビリティーゾーンに限りアタッチできます。Amazon EBS `io2`ボリュームを使用して Windows Server フェイルオーバークラスターをデプロイするには、最新の AWS NVMe ドライバーを使用する必要があります。
Amazon EBS ボリュームおよびインスタンスストアボリュームは、[Nitro ベースのインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)で NVMe ブロックデバイスとして公開されます。Amazon EBS `io2` ボリュームを使用して WSFC および SQL Server FCI を形成する際に設定した [SCSI 永続予約機能](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations)を使用して [AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html)をインストールする必要があります。
この機能の詳細については、 AWS ブログ記事[「How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/)」を参照してください。
## Amazon FSx for Windows File Server の使用
[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) は、フルマネージドの共有ファイルストレージを提供します。ストレージを 2 つのアベイラビリティーゾーンに同期して自動的に複製し、高可用性を実現します。FSx for Windows File Server ストレージを使用すると、Amazon EC2 での SQL Server の高可用性デプロイを簡素化および最適化できます。
Microsoft SQL Server を使用すると、通常、WSFC 内の複数のデータベースノードにデプロイされ、各ノードは共有ファイルストレージにアクセスできます。FSx for Windows File Server は、SQL Server 高可用性デプロイの共有ストレージとして、アクティブデータファイルのストレージとして、および SMB ファイル共有監視として使用できます。
FSx for Windows File Server を使用して SQL Server FCI デプロイの実行の複雑さとコストを削減する方法については、「[Amazon FSx for Windows File Server を使用して Microsoft SQL サーバーの高可用性デプロイを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」を参照してください。このブログ記事では、共有ストレージソリューションとして Amazon FSx Multi-AZ ファイルシステムを使用して SQL Server FCIs をデプロイする手順についてもステップバイステップで説明しています。詳細については、[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) ドキュメントを参照してください。
## Amazon FSx for NetApp ONTAP の使用
Amazon FSx for NetApp ONTAP は、NetApp ONTAP ファイルシステム上に構築された、信頼性が高く、スケーラブルで、パフォーマンスが高く、機能が豊富なファイルストレージを提供するフルマネージドサービスです。FSx for ONTAP は、NetApp ファイルシステムの使い慣れた機能、パフォーマンス、機能、および API オペレーションと、フルマネージド AWS サービスの俊敏性、スケーラビリティ、およびシンプルさを兼ね備えています。
FSx for ONTAP は、Windows および Linux システムの NFS、SMB、iSCSI プロトコルを介してデータへのマルチプロトコルアクセスを提供します。ブログ記事「[Amazon FSx for NetApp ONTAP を使用した SQL Server の高可用性デプロイ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/)」で詳しく説明されているように、可用性が高い SQL Server Always On FCI アーキテクチャを構築できます。FSx for ONTAP は、目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たすために AWS リージョン 、SQL Server 環境を別の環境にフェイルオーバーする簡単な方法も提供します。詳細については、ブログ記事「[FSx for ONTAP を使用した SQL Server Always-On フェイルオーバークラスターインスタンスの HA と DR の実装](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/)」を参照してください。
を使用して SQL Server ソリューションを AWS Launch Wizard にデプロイし AWS、Always On 可用性グループと単一ノードデプロイをサポートすることもできます。Launch Wizard は、FSx for ONTAP を共有ストレージとして Amazon EC2 上の SQL Server Always on FCI のデプロイをサポートします。このサービスは、複雑な手動デプロイプロセスを、共有ストレージに依存するオンプレミス SQL Server ワークロードの移行を加速するガイド付きコンソールベースのウィザードに置き換えることで、時間と労力を節約します。Launch Wizard が数時間で SQL Server FCIs[「Simplify SQL Server Always On deployments with AWS Launch Wizard and Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/)」を参照してください。Launch Wizard は、共有ストレージソリューションとして [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) を使用することで、SQL Server Always On FCI のデプロイもサポートしています。
## AWS パートナーからのソリューションの使用
+ [SIOS DataKeeper](https://us.sios.com/) は、 AWS リージョン および アベイラビリティーゾーン間で高可用性クラスターフェイルオーバーサポートを提供します。SIOS DataKeeper は [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408) で利用できます。
+ DH2i の [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/) により、Kubernetes の SQL Server 可用性グループの完全自動フェイルオーバーと、Windows および Linux の統合インスタンスフェイルオーバーが可能になります。D2HI は [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b) で使用できます。
# FSx for Windows File Server
FSx for Windows File Server は、SMB (Server Message Block) プロトコルを使用してアクセス可能な、フルマネージド、高信頼性、スケーラブルなファイルストレージを提供します。Windows Server 上に構築されており、ユーザークォータ、エンドユーザーファイルの復元、Microsoft Active Directory (AD) 統合など、さまざまな管理機能を備えています。シングル AZ とマルチ AZ 配置オプション、完全マネージド型バックアップ、保管中および転送中のデータの暗号化が可能です。ソリッドステートドライブ (SSD) とハードディスクドライブ (HDD) のストレージオプションを使用すると、ワークロードのコストとパフォーマンスを最適化することができます。また、ストレージをスケールしたり、ファイルシステムのスループットパフォーマンスをいつでも変更したりできます。Amazon FSx ファイルストレージは、Windows、 で実行されている Linux コンピューティングインスタンス AWS、およびオンプレミスからアクセスできます。
Amazon FSx では、継続的可用性 (CA) ファイル共有と小規模なファイルシステムをサポートしているため、高可用性 SQL Server デプロイ用の共有 Windows ストレージを簡単にデプロイできます。このオプションは次のようなユースケースに適しています。
+ WSFC インスタンス内の SQL Server ノードが使用する共有ストレージとして使用することができます。
+ WSFC を使用する任意の SQL Server クラスターで使える SMB ファイル共有ウィットネスとして使用することができます。
Amazon FSx は、ファイルシステムあたり最大 2 GB/秒のベースラインスループット、数十万 IOPS、および安定したサブミリ秒のレイテンシーにより、高速なパフォーマンスを実現します。
SQL インスタンスに適切なパフォーマンスを提供するために、ファイルシステムのサイズに関係なくスループットレベルを選択することができます。スループットキャパシティでは、アクセスする SQL Server インスタンスにファイルサーバーが提供できる IOPS が高くなります。
ストレージ容量によって、保存できるデータ量だけでなく、そのストレージで実行できる IOPS の数も決まります。各ギガバイトのストレージは 3 IOPS です。各ファイルシステムのサイズは最大 64 TB までプロビジョニングすることができます。
SQL Server の高可用性デプロイの複雑さとコストを削減するために Amazon FSx を設定および使用する方法については、 AWS Storage ブログの[「Simplify your Microsoft SQL Server high availability deployments using FSx for Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」を参照してください。新しい CA 共有の作成の詳細については、[FSx for Windows File Server のドキュメント](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share)を参照してください。
# ディザスタリカバリ
多くの組織が SQL Server データベースに高可用性を実装していますが、真の IT レジリエンスを必要とする組織にとっては、それだけでは十分ではありません。ミッションクリティカルなデータベースのデータ損失やダウンタイムを回避するために、ディザスタリカバリソリューションを実装することをお勧めします。SQL Server のデプロイにマルチリージョンのディザスタリカバリアーキテクチャを採用すると、次のことが実現できます。
+ 事業継続性の実現
+ 地理的に分散した顧客ベースのレイテンシーの改善
+ 監査や規制の要件を満たす
ディザスタリカバリのオプションには、[ログ配信](ec2-log-shipping.md)、[Always On 可用性グループ](ec2-always-on.md)、[Amazon S3 に保存され、リージョン間でレプリケートされる Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html)、[Always On 可用性グループと組み合わせた Always On フェイルオーバークラスターインスタンス (FCIs)](ec2-fci.md)、分散可用性グループなどがあります。 Amazon S3 AWS
## 分散可用性グループ
分散可用性グループを使用するアーキテクチャは、複数リージョンの SQL Server のデプロイに最適なアプローチです。分散可用性グループは、2 つの別々の可用性グループにまたがる特殊な種類の可用性グループです。複数の可用性グループのうちの 1 つの可用性グループと考えることができます。基盤となる可用性グループは 2 つの異なる WSFC クラスターで構成されます。
分散可用性グループは疎結合されているため、単一の WSFC クラスターを必要とせず、SQL Server によって管理されます。WSFC クラスターは個別に管理され、送信は主に 2 つの可用性グループ間で非同期で行われるため、別のサイトでのディザスタリカバリ設定が容易です。各可用性グループのプライマリレプリカは、独自のセカンダリレプリカを同期します。
分散可用性グループでは、現時点では手動フェイルオーバーのみがサポートされています。データが失われないようにするには、グローバルプライマリデータベース(つまり、プライマリ可用性グループのデータベース) のすべてのトランザクションを停止します。次に、分散可用性グループを同期コミットに設定します。
# VMware Cloud on AWS for SQL Server
**注意**
2024 年 4 月 30 日現在、VMware Cloud on AWS は AWS またはそのチャネルパートナーによって再販されなくなりました。サービスは Broadcom を通じて引き続き提供されます。詳細については、 AWS 担当者にお問い合わせください。
[VMware Cloud on AWS](https://aws.amazon.com/vmware/) は、 AWS と VMware が共同で開発した統合クラウドサービスです。SQL Server は VMware Cloud on AWSと簡単に統合することができます。この移行オプションにより、仮想化への既存の投資を基盤に構築することができます。
VMware Cloud on には、 AWS 時間単位、オンデマンドベース、またはサブスクリプション形式でアクセスできます。vSphere Hypervisor (ESXi)、仮想 SAN (vSAN)、NSX ネットワーク仮想化プラットフォームなど、データセンターで実行しているのと同じコア VMware テクノロジーが組み込まれており、SQL Server データベースを効率的かつシームレスに管理できるように設計されています。VMware Cloud on AWS では、SQL Server データベースのストレージ、コンピュート、およびメモリを数分でスケールするすることできます。
VMware Cloud on は物理ハードウェア上で直接 AWS 実行されますが、 AWS セキュリティファーストのインフラストラクチャモデルをサポートするように設計されたネットワークとハードウェアの機能を活用します。つまり、VMware 仮想化スタックは、ネストされた仮想化を使用せずに AWS インフラストラクチャ上で実行されます。
VMware Cloud on AWS を使用すると、SQL Server データベースのワークロードを簡単にセットアップ、スケーリング、運用できます AWS。高可用性ソリューションを提供し、オンプレミスの Active Directory と統合して、 AWS Directory Service for Microsoft Active Directory や AD Connector、Amazon Route 53、Amazon CloudWatch、Amazon S3 などの AWS サービスへのアクセスを提供します。バックアップを Amazon S3 に保存し、ディザスタリカバリプロセスをモダナイズおよび簡素化することができます。
## VMware Cloud on を選択するタイミング AWS
VMware Cloud on AWS は、SQL Server データベースのオプションです。
+ SQL Server データベースは、すでに vSphere 仮想化環境のオンプレミスデータセンターで実行されています。
+ 多数のデータベースをお持ちで、以下の理由でクラウドへの迅速な移行が必要な場合 (例えば、わずか数時間) 、移行チームが追加作業を行う必要必要なく移行できます。
+ データセンターの拡張。仮想デスクトップを実行したり、アプリケーションを公開したり、開発/テスト環境を提供したりするには、オンデマンドの容量が必要です。
+ ディザスタリカバリ 新しいディザスタリカバリシステムをセットアップしたい、あるいは既存のシステムを置き換えたい場合。
+ クラウド移行 データセンター全体をクラウドに移行したい、インフラストラクチャを更新したい場合。
SQL Server データベースが 80K を超える IOPS を必要とする場合は、vSAN を使用することができます。
詳細については、 AWS ニュースブログの「In [the Works – VMware Cloud on AWS](https://aws.amazon.com/blogs/aws/in-the-works-vmware-cloud-on-aws/)」および AWS ウェブサイトの[「Deploy Microsoft SQL Server on VMware Cloud on AWS](https://aws.amazon.com/solutionspace/solutions/sql-server-vmware-cloud-on-aws/)」を参照してください。