SSM を利用して Windows Server 2012 R2 を Windows Server 2019 へ in-place upgrade する

記事タイトルとURLをコピーする

CI部 佐竹です。
本日は Systems Manager (SSM) の Automation を活用して Windows Server 2012 R2 を Windows Server 2019 へアップグレードするという記事です。

はじめに

AWS Systems Manager (AWS SSM) には Automation と言われる自動化ドキュメント(Runbook)があります。

docs.aws.amazon.com

SSM では AWS が予め用意した ドキュメント を単一で実行することで、単一の処理を EC2 上で実行できます。例えば Windows Server のパスワードを失念してしまった場合に、SSM によってパスワードを変更し、その値を書き出すというような処理です。

※補足:ドキュメントはユーザがカスタマイズしたり、オリジナルのドキュメントを用意したりもできます

このように単一のドキュメントで単一の作業を実行することももちろんですが、複数のドキュメントを組み合わせて複雑な処理を行うものもあります。それが今回活用する「Automation」であり、Automation を実行すると SSM によって複数の処理が連続で行われます。

その中でも、今回は Windows Server のインプレースアップグレードに役立つ Automation を詳しくご紹介します。

シナリオ

今回は以下のシナリオにおいて、必要な対応を行うと仮定しご説明します。

  1. m3.medium で動作する Windows_Server-2012-R2_RTM-Japanese-64Bit-Base をインプレースアップグレードし、Windows Server 2019 へとバージョンアップする
  2. バージョンアップの後、合わせて Nitro 世代のインスタンスタイプが利用できるように、ドライバーをアップグレードする

この2つの処理をそれぞれ SSM Automation で実行して行きます。よって、今回実行する Automation は2つです。

対応する Automation Runbook

先のシナリオに対応して実行する SSM Automation Runbook は以下の通りです。

  1. AWSEC2-CloneInstanceAndUpgradeWindows を用いて Windows Server のインプレースアップグレードを行います
  2. AWSSupport-UpgradeWindowsAWSDrivers を用いて Nitro 対応のためドライバーをアップグレードします

AWSEC2-CloneInstanceAndUpgradeWindows

前提条件

まずは AWSEC2-CloneInstanceAndUpgradeWindows を対象の EC2 Instance に実行します。今回、対象のインスタンスでは既に Systems Manager が動作する環境が整っているとして話をすすめますのでご了承ください。

インスタンスに SSM Agent がインストールされていない、IAM Role が付与されていないなど、SSM が動作する前提条件が揃っていない場合は以下を参照ください。

docs.aws.amazon.com

なお、以下に SSM を動かすためのチェックポイントをざっと記載しましたのでご参考ください。

SSM が動作するかのチェックポイント

  1. EC2 Instance に Systems Manager が動作するための IAM Role が付与されている
  2. EC2 Instance が起動しており、正常に動作(2/2)している
  3. EC2 Instance に Systems Manager Agent がインストールされている
  4. EC2 Instance で Systems Manager Agent が実行中であり、正常に動作している
  5. EC2 Instance がネットワーク経路として Systems Manager の Endpoint にアクセス可能となっている(インターネット経由もしくは VPC Endpoint を活用)
  6. SSM Fleet Manager の Managed instances に Online と表示される

f:id:swx-satake:20210414181926p:plain
Online になっているインスタンスには SSM Automation が実行可能です

前準備

以下の2点、Automation の実行前にチェックしてください。

  1. 少なくとも 2 つの vCPU と 4GB の RAM を持つインスタンスでオペレーティングシステムのアップグレードを実行することを推奨されるため、インスタンスタイプは m3.large や m4.large など、large 程度のインスタンスタイプにしておいてください
  2. Cドライブに 20 GB の空き容量が必要です。もし不足している場合は EBS Volume を Modify するなどして対応ください。これが不足している場合は、以下のエラーが発生します。

OSVersion : MICROSOFT WINDOWS SERVER 2012 R2 STANDARD
Not enough space to continue upgrade. Available space 7 GB, minimum required is 20 GB

----------ERROR-------
failed to run commands: exit status 1

Automation で対応できないケース

EBS ボリュームが暗号化されている場合は失敗します。詳しくは以下の公式ドキュメントの記載をご確認ください。

このオートメーションは、暗号化されていない EBS ルートボリュームを持つ EC2 インスタンスでのみ動作します。指定されたインスタンスに暗号化されたルートボリュームがある場合、オートメーションは失敗します。

docs.aws.amazon.com

Automation Runbook の実行

f:id:swx-satake:20210414182433p:plain

SSM Automation は Change Management から実行するようにコンソールが変更されています。Change Management 内のメニュー Automation を押下し、次に画面右上に表示される「Execute automation」を押下します。

f:id:swx-satake:20210414183018p:plain

検索窓が表示されるため AWSEC2-CloneInstanceAndUpgradeWindows を入力して検索します。表示されたドキュメントのうち、必要なものを選択してURLリンクとなっているドキュメント名を押下します。

f:id:swx-satake:20210414183324p:plain

新しいウインドウが開きますので、画面右上の「Execute automation」を押下してドキュメントを実行していきます。

f:id:swx-satake:20210420135221p:plain

デフォルトの「Simple execution」を選択して進めます。

f:id:swx-satake:20210420135315p:plain

ターゲットとするインスタンスの Instance id を指定します。Show interactive instance picker を押下すると、SSM Agent がインストールされているマネージドインスタンスが確認できます。

f:id:swx-satake:20210420135431p:plain

今回のターゲットとするインスタンスをラジオボタンで指定し、次に進みます。

f:id:swx-satake:20210420135504p:plain

必須項目は3つです。

IamInstanceProfile は今回の Automation を実行するために利用される IAM Role を指定します。ARN で指定しませんので注意してください。

TargetWindowVersion は2019を選択します。なお、2016や2012R2も選択可能です。

任意の SubnetId を指定します。これは、一時的に EC2 インスタンスが作成されるサブネットを指定しています。注意ですが Auto-assign public IPv4 addressYes になっているサブネットを選択する必要があります。また、バージョンアップを行いたい EC2 インスタンスが存在する VPC 内にある Subnet を選択してください。

もし No になっている場合は Step 4: assertSubnetHasAutoAssignIPV4 において Failed します。以下がエラーメッセージです。

Failure message
Step fails when it is Execute/Cancelling action. Property value 'False' from the API output is not in the desired values. Desired values: ['True'].. Please refer to Automation Service Troubleshooting Guide for more diagnosis details.

この Automation では、全体的な流れとしてまず「2012R2 のインスタンス」から AMI が取得され、その後バージョンアップ用の「一時インスタンス」が作成されます。また、この「一時インスタンス」は「2012R2 のインスタンス」のインスタンスタイプや Security Groups を引き継ぎます。この「一時インスタンス」にインプレースアップグレードが行われ 2019 になった後「一時インスタンス」の AMI が取得されて終了します。つまり、成果物は AMI となります。元の「2012R2 のインスタンス」は特に影響を受けません。「一時インスタンス」は Automation の最終段階で Terminate されます。

このような処理のため、本 Automation では「EC2 インスタンスの構築権限」「EC2 インスタンスの削除権限」「EC2 インスタンスの読み取り権限」「AMI の作成権限」などが必要になってきます。ただし、 IAM Role に必要な権限は AWS Managed Policy の「AmazonSSMManagedInstanceCore」だけで問題なく動作します。

全て指定が完了した後、右下にある「Execute」を押下します。

f:id:swx-satake:20210420142230p:plain

Automation が実行されたら、後は2時間程度の待ち時間になります。特に処理が重いのは、Step 7の runUpgradeFrom2012R2Or2016 で、これが2時間弱ほどかかります。

f:id:swx-satake:20210420142420p:plain

Executed steps を確認することで進行状況がわかります。

トラブルシューティング

SSM Automation のエラーを追いかける方法をお伝えします。

f:id:swx-satake:20210420144550p:plain

Automation が Failed であることを確認した場合、どの「Step ID」で失敗したのかを確認します。今回は Step 7 で失敗していることがわかります。「Step ID」が URL リンクになっているのでこれを押下してください。

f:id:swx-satake:20210420144754p:plain

「Execution detail - Step X」に進みます。この画面ではエラーを特定するのに役立つ情報がないため、「Outputs」の「ExecutionId」の URL リンクを押下して今一度ジャンプします。

f:id:swx-satake:20210420145104p:plain

「Execution detail」に進みます。

f:id:swx-satake:20210420145231p:plain

この画面でもエラーを特定できませんので、Executed steps から Status = Failed のものを検索します。「Step ID」の URL リンクを押下して進みます。

f:id:swx-satake:20210420145503p:plain

これで「24895178-4772-45e2-ad7d-b19208aeccbd」が表示されました。

Failure message
Automation Step Execution fails when it is launching the instance(s). Get Exception from RunInstances API of ec2 Service. Exception Message from RunInstances API: [Security group sg-b98d60dd and subnet subnet-7f747539 belong to different networks. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameter; Request ID: 6c54891c-8d38-41a2-9f3a-bc202cd3bc3f; Proxy: null)]. Please refer to Automation Service Troubleshooting Guide for more diagnosis details.

今回のエラーですが、指定したサブネットIDが「2012R2 のインスタンス」が存在するのとは別の VPC のサブネットIDであったため、Security Group が使えず EC2 インスタンスの Launch に失敗してしまっています。

AMI ID の確認

全体のステータスが「Success」となっていれば処理は完了しています。「Output」のペインを開くと成果物が確認できます。

f:id:swx-satake:20210420150652p:plain

getUpgradedImageDetails.ImageId ami-0e365e6352892eca9

上記のAMI が Windows Server 2019 にバージョンアップされた後の EC2 インスタンスの AMI です。つまり、これを用いて構築作業までを行わなければなりません。

元の EC2 インスタンスの設定を引き継ぎ、かつ指定した AMI を用いて Launch を行うには「Launch Template」を用いるのが有効です。

ただ、今回本ブログで記載するには記事が長くなりすぎますため、次回のブログでご紹介したいと思います。また AWSSupport-UpgradeWindowsAWSDrivers についても同様となります。

まとめ

本日は Systems Manager (SSM) の Automation を活用して Windows Server 2012 R2 を Windows Server 2019 へアップグレードする方法をご紹介しました。既存の 2012R2 をインプレースアップグレードされたいような場合にご参考ください。

なお最後に注意点を列挙しておきます。

注意点

  1. 実行対象のインスタンスで正常に SSM Agent が動作していること
  2. m4.large など、少なくとも 2 つの vCPU と 4GB の RAM を持つインスタンスタイプに変更しておくこと
  3. Cドライブに 20 GB の空き容量が必要であること
  4. 一時インスタンスのために指定する Subnet ID はターゲットとするインスタンスと同じ VPC 内のものを指定すること
  5. 指定する Subnet ID は Auto-assign public IPv4 address が Yes であること(一時的に Yes に変更する場合は作業後に No へ戻すこと)
  6. 実行対象のインスタンスの EBS ボリュームが暗号化されていないこと
  7. 処理には2時間程度かかるため、長い待ち時間に注意すること
  8. 成果物は AMI であり、元のインスタンスには影響がないこと(SSM が実行されている間に入力されたデータは AMI から Launch されたタイミングで巻き戻ってしまう点に注意)

2021年4月28日 追記

checkAfterWindowsUpgrade2019 において以下のエラーが発生する場合があります。

2021-04-27 00:43:55.795 Error: Upgrade failed with following error
2021-04-27 00:43:55.875 ErrorLevel: 183 

----------ERROR-------
failed to run commands: exit status 1

これは EC2 Instance 起動時に S3 をWindowsにマウントする設定になっている場合に、ドライブのチェック時に失敗してしまうというものです。もし S3 をマウントして利用されている場合は、OS起動時に S3 がマウントされないように設定後、本 Automation を試みてください。

では、また次回のブログでお会いしましょう。

佐竹 陽一 (Yoichi Satake) 記事一覧はコチラ

SRE3課所属。AWS資格12冠。2010年1月からAWSを利用してきました。
AWSのコスト削減、最適化を得意としています。