サポートが終了する AWS の Microsoft 2008 R2 ワークロードを簡単にアップグレードする

多くの IT 企業が 10 年以上にわたって Microsoft Windows Server 2008 R2 オペレーティングシステムと SQL Server 2008 R2 データベースシステムを使ってきました。サポート終了 (EOS) 日 (SQL Server は 2019 年 7 月、Windows Server は 2020 年 1 月) が間近であるため、セキュリティとコンプライアンスのリスクを回避するためにこれらのシステムをサポート対象バージョンにアップグレードすることが重要です。アップグレードをすぐに開始できるように、Windows Server 2008 R2 と SQL Server 2008 R2 (Service Pack 3) の両方のアップグレードを支援するために AWS Systems Manager ドキュメントを組み合わせました。

このブログでは、AWS Systems Manager を使用して、AWS 環境の Windows Server 2008 R2 および SQL Server 2008 R2 サポート終了インスタンスを、低リスクのアプローチを用いてサポートされている新しいバージョンに自動でアップグレードするためのガイダンスを提供します。

Microsoft は、SQL Server 2008 R2 の延長サポート期間中に、セキュリティ更新プログラムを含む技術サポートを提供します。

AWS Systems Manager

AWS Systems Manager は、AWS の強力な統合インターフェースで、AWS リソースを集中管理する機能を提供します。AWS SSM Agent と AWS Systems Manager ドキュメントの使用が、AWS Systems Manager を活用するための核となります。

AWS SSM Agent

AWS Systems Manager Agent (SSM Agent) は、Amazon EC2 インスタンス上で動作する Amazon ソフトウェアです。SSM Agent はクラウドの Systems Manager サービスからのリクエストを処理し、リクエストに指定されているとおりにマシンを構成します。SSM Agent は、EC2 Messaging サービスを使用して、ステータスと実行情報を Systems Manager サービスに送り返します。

AWS SSM ドキュメント

このブログでは、2 つの AWS Systems Manager Automation ドキュメントを活用します。次のリンクから、AWS System Manager ドキュメントに関する詳細を見つけることができます。

ドキュメントには 2 つのアップグレードパスがあります。1 つは Windows Server 2008 R2 から Windows Server 2012 R2 へのアップグレード、もう 1 つは Windows Server 2012 R2 上の SQL Server 2008 R2 から SQL Server 2016 へのアップグレードです。

Windows OS のアップグレード:

Windows Server 2008 R2 から Windows Server 2012 R2 へのアップグレード: AWSEC2-CloneInstanceAndUpgradeWindows

https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html

Windows SQL Server のアップグレード:

Windows Server 2012 R2 上の SQL Server 2008 R2 から SQL Server 2016 へのアップグレード: AWSEC2-CloneInstanceAndUpgradeSQLServer

https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeSQLServer.html

アップグレードオプション

これら 2 つの AWS System Manager Automation ドキュメントを詳しく見てみましょう。

AWSEC2-CloneInstanceAndUpgradeWindows

このスクリプトは、アカウントの Windows Server 2008 R2 インスタンスから Amazon Machine Image (AMI) を作成してから、AMI を Windows Server 2012 R2 にアップグレードします。アップグレード操作は複数ステップのプロセスで、完了までに 2 時間かかる場合もあります。オートメーションはインスタンスから AMI を作成し、次に指定した VPC/Subnet で新しく作成された AMI を起動します。オートメーションワークフローは、Windows Server 2008 R2 から Windows Server 2012 R2 へのインプレースアップグレードを実行します。このワークフローは、アップグレードされたインスタンスに必要な AWS ドライバーも更新またはインストールします。アップグレード後、ワークフローは新しい AMI を作成してから、アップグレードされたインスタンスを終了します。

AWSEC2-CloneInstanceAndUpgradeSQLServer

このスクリプトは、アカウントで実行されている SQL Server 2008 R2 SP3 を実行している Amazon EC2 Windows インスタンスから AMI を作成し、その AMI を SQL Server 2016 SP2 にアップグレードします。アップグレードは多段階プロセスで、完了までに 2 時間かかる場合があります。オートメーションはインスタンスから AMI を作成し、次に指定したサブネットで新しい AMI を起動します。その後、オートメーションは SQL Server 2008 R2 から SQL Server 2016 へのインプレースアップグレードを実行します。アップグレード後、オートメーションはアップグレードされたインスタンスを終了する前に新しい AMI を作成します。

VPC で新しい AMI を起動してアプリケーションの機能をテストできます。テストが終了したら、アップグレードをもう 1 度実行する前に、アップグレードしたインスタンスに完全に切り替える前にアプリケーションのダウンタイムをスケジュールします。

最終結果は 1 つの AMI で、これはアップグレードされたインスタンス AMI です。

最初の AMI

これは現在実行中のインスタンスからの AMI です (アップグレードされていません)。この AMI を使用して別のインスタンスを起動し、インプレースアップグレードプロセスを実行します。最後に、顧客が元のインスタンスをバックアップとして保つことを特にオプトインしない限り、この AMI を顧客アカウントから削除します。これはパラメータ「KeepPreUpgradeImageBackUp」で処理します (デフォルト値は False です。つまり、AMI を削除します)。

2 番目の AMI

これが自動化プロセス全体の最終結果です。2 番目の AMI は自動化プロセスの結果で、元の SQL Server 2008 R2 エンジンの代わりに SQL Server 2016 が含まれています。VPC で新しい AMI を起動してアプリケーションの機能をテストできます。テストが終了したら、アップグレードをもう 1 度実行する前に、アップグレードしたインスタンスに完全に切り替える前にアプリケーションのダウンタイムをスケジュールします。

1.     必要な IAM ロール

自動化プロセスを開始する前に、AWS Systems Manager がアカウントの AWS EC2 および AWS AMI インスタンスに対して自動化を実行できるようにするには、正しい IAM ポリシーを持つ IAM ロールが必要となります。この例の目的と理解を容易にするために、作成ロールは添付の AMI Policy AmazonEC2RoleforSSM と同じ名前も持っています。

次のリンクは、ロールの作成に関するガイダンスを提供しています。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html

2.     前提条件

アップグレードプロセスを開始する前に、次のリンクから AWS Systems Manager の前提条件を満たしていることを確認してください。https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-prereqs.html

3.     AWS SSM Automation の実行オプション

自動化を実行する方法は複数あります。以下にいくつかのオプションを示します。

簡単な実行

各自動化ステップを実行して結果を監査せずに、単一のインスタンスを更新したい場合は、この方法を使用してください。このブログでは、このオプションについて説明しています。詳細については後述します。

レートコントロール:

アップグレードを複数のインスタンスに適用する場合は、このオプションを使用します。これは、次のパラメータを使用して実行できます。

パラメータ (マルチアカウントおよびリージョンでも設定)

これは自動化がどのように分岐するかを定義します。

ターゲット (マルチアカウントおよびリージョンでも設定)

パラメータ値

自動化ドキュメントパラメータに定義されている値を活用します。

リソースグループ

AWS では、リソースは作業できるエンティティです。例としては、Amazon EC2 インスタンス、AWS CloudFormation スタックや Amazon S3 バケットがあります。複数のリソースを扱う場合は、タスクごとに 1 つの AWS のサービスから別の AWS のサービスに移動するのではなく、それらをグループとして管理する方が便利な場合があります。アプリケーション層を構成する EC2 インスタンスなど、多数の関連リソースを管理している場合は、これらのリソースに対して一括処理を一度に実行することが必要になるでしょう。

タグ

AWS では、タグを使用して、目的、所有者、環境など、さまざまな方法で AWS リソースを分類できます。これは、同じ種類のリソースが多数ある場合に便利です。これにより、割り当てたタグに基づいて特定のリソースをすばやく識別できます。たとえば、アカウントの Amazon EC2 インスタンスにタグのセットを定義すると、各インスタンスのコストセンターと環境を追跡するのに役立ちます。

レートコントロール (マルチアカウントおよびリージョンでも設定)

これらのパラメータを設定すると、自動化を適用するフリートの数を、フリートのパーセンテージの目標数で定義できます。

マルチアカウントとリージョン

アカウントと組織単位 (OU)

ここでは、自動化を実行したい複数のアカウントを指定できます。

AWS リージョン

ここで、オートメーションを実行したい複数のリージョンを指定できます。

手動実行

このオプションは単純実行と似ていますが、各自動化ステップを実行して結果を監査したい場合に使用します。

Windows 2008 R2 から 2012 R2 へのアップグレード

このセクションでは、スクリプト AWSEC2-CloneInstanceAndUpgradeWindows の活用に焦点を当てます。

このプロセスが機能するためには、いくつかの前提条件があります。それらの依存関係を確認するには、次のページにアクセスしてください。https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeWindows.html

この例では、AWS アカウントに存在する Window 2008 R2 インスタンスがあります。下の画像は、AdventureWorks のサンプルデータベースとともに、SQL Server 2008 R2 SP3 もインスタンスにインストールされていることを示しています。この自動化が完了すると、AWS Systems Manager は OS を Server 2012 R2 にアップグレードし、SQL Server 2008 R2 はそのまま残ります。

それではアップグレードプロセスを始めましょう！

4.     AWS コンソールで AWS System Manager を開く

このブログでは、専用の AWS Systems Manager インターフェイスを使用しました。

左側のメニューから [自動化] を選択します。

自動化プロセスを開始するには、[自動化の実行] をクリックします。

表示された検索フィルターから自動化ドキュメント AWSEC2-CloneInstanceAndUpgradeWindows をフィルター処理します。

ドキュメントの説明には、自動化ドキュメントの概要が記載されています。

5.     簡単な実行の段階的な実装

InstanceID

これは、自動化を適用したいインスタンス ID です。

InstanceProfile

これは、AWS EC2 および AWS AMI に対して AWS SSM 自動化を実行するために使用する IAM ロールです。https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-configuring-access-role.html を参照してください。

SubnetId

これはアップグレードプロセスおよびソース EC2 が存在する場所のサブネットです。サブネットに AWS のサービス、Amazon S3、および Microsoft へのアウトバウンド接続があることを確認します (パッチをダウンロードするため)。

KeepPreUpgradedBackUp

(オプション) True に設定した場合、オートメーションはインスタンスから作成されたイメージを保持します。デフォルトは False です。

RebootInstanceBeforeTakingImage

(オプション) デフォルトは False (再起動なし) です。True に設定した場合、AWS SSM はアップグレード用の AMI を作成する前にインスタンスを再起動します。

以下のパラメータを入力して自動化を実行します

共有可能実行リンク:

自動化が始まると、その進行状況を監視できます。

オートメーション完了

確認できる出力は AMI ID です (getUpgradeImageDetails.ImageId : ami-01f63*******)。AMI を起動して Window がアップグレードされたことを確認できます。

自動化がすべての手順を実行する必要はありません。手順は自動化とインスタンスの動作に基づいて条件付けられているため、AWS SSM は不要な手順をスキップすることができます。

一部の手順はタイムアウトする可能性があり、AWS SSM はすべての最新パッチをアップグレードおよびインストールしようとしますが、場合によってはその手順の定義可能なタイムアウト設定に基づいてパッチがタイムアウトする場合もあります。その場合、AWS SSM 自動化は次のステップに進み、内部 OS が 2012 R2 にアップグレードされるようにします。

出力

この自動化の場合、新しく作成された AWS AMI の名前と ImageID が提供されます。ここから、以下に示すように AWS EC2 を起動してアップグレードを確認できます。このガイドを使用して、AWS AMI から AWS EC2 を作成する方法を確認してください。

https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/

SQL Server 2008 R2 から SQL Server 2016 へのアップグレード

このセクションでは、スクリプト AWSEC2-CloneInstanceAndUpgradeSQLServer の活用に焦点を当てます。

このプロセスが機能するためには、いくつかの前提条件があります。それらの依存関係を確認するには、次のページにアクセスしてください。https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awsec2-CloneInstanceAndUpgradeSQLServer.html

上記のリンクに記載されている前提条件を構成して満たした後は、次の手順に従って SQL Server 2008 R2 データベースエンジンを SQL Server 2016 にアップグレードできます。この例では、「SQLServer2008r2-Source」という名前の SQL Server 2008 R2 ソースサーバーがあります。データベースエンジンとして SQL Server 2008 R2 を実行しており、OS は Windows 2012r2 です。これは、AWS Systems Manager の Automation ドキュメントを介してデータベースエンジンをアップグレードするサーバーになります。

まだ実行していない場合は、SQL Server 2016 の .iso ファイルをダウンロードしてソースサーバーにマウントします。マウントしたら、すべてのファイルをコピーして、選択した任意のボリュームに配置します。それが完了したら、ボリュームの EBS スナップショットを取り、後で使用するためにスナップショット ID をクリップボードにコピーします。EBS スナップショットの作成方法に関する手順を確認するには、次のリンクに記載されている手順に従ってください。https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-creating-snapshot.html

この特定の例では、SSM-EC2-Profile-Role という名前のロールに、AmazonEc2RoleSSM ポリシーがアタッチされています。そしてそのロールがインスタンスにアタッチされます。これがあれば、SSM サービスは EC2 インスタンスと通信し、AWS SSM サービス内で追加されるとそれに対してコマンドを実行できます。

インスタンスプロファイルが EC2 インスタンスにアタッチされたら、AWS Systems Manager サービスの [Managed Instances] の下にそのインスタンスプロファイルが表示されることを確認します。マネージド型インスタンスが存在しない場合は、数分待つと表示されます。表示されない場合は、以下のように AWS Systems Manager の前提条件が満たされていることを再確認してください。

以下に示すように、インスタンスはマネージド型インスタンスとして表示されます (つまり、インスタンスに対してコマンドを実行可能)。

[Managed Instance] リストを確認したら、AWS Systems Manager 内の [Automation] タブに移動し、[Execute Automation] をクリックします。

AWSEC2-CloneInstanceAndUpgradeSQLServer ドキュメントを検索するには、検索バーに移動し、[Document name prefix] を選択して [Equal] を選択し、ドキュメント名に貼り付けます (AWSEC2-CloneInstanceAndUpgradeSQLServer)。大文字と小文字が区別されるので注意し、大文字と小文字が正しく入力されていることを確認してください。

見つかったら、ドキュメントをクリックし、[次へ] をクリックします。

このアップグレードプロセスを成功させるには、次のパラメータが必要です。

パラメータ:

• InstanceId

Type: String

説明: (必須) Windows Server 2012 R2 (またはそれ以降) または SQL Server 2008 R2 (またはそれ以降) を実行しているインスタンス。

• IamInstanceProfile

Type: String

説明: (必須) IAM インスタンスプロファイル。

• SnapshotId

Type: String

説明: (必須) SQL Server 2016 インストールメディア用のSnapshotId。

• SubnetId

Type: String

説明: (必須) アップグレードプロセス用のサブネットを指定します。サブネットに AWS のサービス、Amazon S3、および Microsoft へのアウトバウンド接続があることを確認します (パッチをダウンロードするため)。

• KeepPreUpgradeImageBackUp

Type: String

説明: (オプション) True に設定した場合、オートメーションはアップグレード前にインスタンスから作成された AMI を削除しません。True に設定した場合は、AMI を削除する必要があります。デフォルトでは、AMI は削除されます。

• RebootInstanceBeforeTakingImage

Type: String

説明: (オプション) True に設定されている場合、オートメーションはアップグレード前の AMI を作成する前にインスタンスを再起動します。デフォルトでは、オートメーションはアップグレード前に再起動しません。

上記のパラメータを設定したら、次に進んでセクションにデータを入力し、[Next] をクリックします。

実行プロセスが開始されたら、スクロールダウンして進捗状況のページを確認することによって、ドキュメントの進捗状況を監視できます。

実行ステータスに「成功」と表示されたら、[出力] ドロップダウンをクリックして AMI 情報を表示できます。ここで AMI ID が表示されます。これを使用して、選択した特定の VPC に対して SQL Server 2016 インスタンスを起動できます。

EC2 コンソールに戻って [AMI] タブをクリックすると、新しい AMI (Amazon Machine Image) が表示されます。これを後で起動して、SQL Server 2016 が正常にインストールされたことを確認できます。

新しい AMI を起動するには、AMI を選択して [起動] をクリックします。

AMI に必要なインスタンスの種類を選択し、マシンを展開する VPC とサブネット、および追加するストレージを選択します。AMI からこの新しい EC2 インスタンスを起動しているので、AMI から存在していたボリュームは、起動した新しい EC2 インスタンスに含めるオプションとして表示されることに注意してください。代わりに、新しいインスタンスからこれらのボリュームを削除するか、追加することもできます。ストレージに希望する処理を選択したら、タグを追加し、インスタンスにセキュリティグループを追加して、最後にインスタンスを起動します。

新しく起動したサーバーのタグ名は SQLServer2016 です。それを選択して接続すると、SQL Server 2016 がインスタンス上の新しいデータベースエンジンになったことを確認できます。

SQL Server Management Studio を起動したら、指定されたサーバーの既定のインスタンス (または名付けたインスタンス) に接続し、クエリウィンドウに次のクエリを実行してエンジンがアップグレードされたことを確認します。

SELECT @@VERSION

確認できる方法は 2 つあります。1 つは Object Explorer 内の特定のビルド番号 (ビルド番号: 13.0.5026) を使う方法、そして 2 つ目は、「Microsoft SQL Server 2016…」という上記クエリからの出力を受信することで確認する方法です。

これで、AWS Systems Manager 内の AWSEC2-CloneInstanceAndUpgradeSQLServer 自動化ドキュメントの処理に成功しました。このプロセスが有用で、アップグレードプロセスで役立つことを願っています。

結論

このブログでは、AWS Systems Manager AWSEC2-CloneInstanceAndUpgradeWindows と AWSEC2 -CloneInstanceAndUpgradeSQLServer の両方の SSM ドキュメントを利用して、AWS 環境に存在する Windows Server 2008 R2 および SQL Server 2008 R2 インスタンスのフリートのアップグレードプロセスを自動化するのに役立つガイダンスを提供しました。自動化手順が完了したら、AWS AMI (Amazon Machine Image) が作成され、アップグレードされたサーバーを使用してどのように進めていくかの点で柔軟性がもたらされるようにすることが重要です。

ご意見やご質問があれば、以下の欄にご記入ください。

著者について

Stefan Minhas はシニアアマゾン ウェブ サービスのコンサルタントです。アメリカ向けのアプリケーションデリバリープラクティスに関するエキスパートで、プロフェッショナルサービスコミュニティ全体で専門技術を開発し成長できるように指導と技術支援を行っています。

Bini Berhe はアマゾン ウェブ サービスのシニアソリューションアーキテクトです。AWS のお客様と協力して、AWS での Microsoft ワークロードの実行に関するガイダンスと技術支援を提供しています。