COLUMN

1．いきなり余談です

先日、私物のパソコンをWindows10からWindows 11へアップグレードしました。このパソコンのハードウェアは10年前に作成したものがベースになっており、これまでもSSDやグラフィックボードの交換などいくつかの変更は行っていました。

しかしWindows 11にするためにはTPM2.0に対応したCPUへの交換が必要となるため、マザーボードとメモリの交換も合わせて必要となる作業となりました。

詳細は省きますが、夕方業務終了後バックアップを取り、電源を落としてからマザーボードを物理的に交換し、CPUと新しいメモリ、各種ケーブル類を配線し直して起動。Windowsのライセンス認証を再度取り、使えるようになるまで数時間は要する作業となりました。

この後Windows 11へのアップグレードが待っており、こちらはパソコン側で対応してくれるので実行だけして就寝しましたが、朝起きて動作確認まで含めると1台のパソコンのアップグレードに一日仕事をしたということになります。

慣れた方ならもっと少ない時間で対応できると思いますが、ハードウェアの物理的な交換が伴うので、どうしても時間がかかってしまう作業となります。

2．WorkSpacesの変更でできること

余談が長くなりましたが、AWS上のお話に戻ります。AWS上では利用者側でハードウェアの交換をすることはありませんが、WorkSpacesにおいては仮想マシンの構築後にこんなことができるようになります。

• コンピューティングタイプの変更
• ボリュームサイズの変更
• プロトコルの変更

プロトコルの変更については、WorkSpacesへの通信プロトコルの変更となるため、今回は省略してコンピューティングタイプの変更とボリュームサイズの変更についてお話ししていきたいと思います。

Amazon WorkSpacesの運用でお困りの方はNTT東日本へお気軽にお問い合わせください。

3．コンピューティングタイプの変更について

コンピューティングタイプの変更は、WorkSpacesのバンドルタイプから選択する形となります。バンドルタイプの中でも、移行元と移行先の組み合わせがあり、組み合わせの異なるコンピューティングタイプの変更は出来ないので注意が必要です。

移行先の組み合わせは、以下の二つとなります。

※グラフィックス及びグラフィックスプロは変更不可（2023/11/30にサポート終了するため、Graphics.g4dnまたはGraphicsPro.g4dnへの移行が必要）

3-1．コンピューティングタイプの変更時における注意点

コンピューティングタイプの変更時における注意点は、以下の通りとなります。

• 新規に作成したWorkSpaceのコンピューティングタイプが変更できるのは、作成してから6時間以降となる
• 大きなコンピューティングタイプへの変更（例：スタンダードからパフォーマンス）は、6時間に1回実行できるが、小さなコンピューティングタイプへの変更（例：パフォーマンスからスタンダード）は30日に1回となるので、慎重な判断を要する
• コンピューティングタイプの変更プロセスには、最大1時間かかる
• コンピューティングタイプの変更中は、切断されるため使用できない
• コンピューティングタイプの変更が終わった後、自動で再起動される（再起動するため、保存していないデータは消える）

3-2．コンピューティングタイプの変更作業のプロセス

上記の注意点を踏まえて、コンピューティングタイプの変更を行うには、次のようなプロセスとなります。

①ユーザー側でファイルやアプリケーションのデータの保存を行って、確実に終了したのち切断する

②WorkSpacesコンソールまたはAWS CLIでコンピューティングタイプの変更を行う

③変更完了後、再接続を行い動作確認する

切断が必要となるため、実際の作業はユーザーが使用していない時間を選択することになることかと思います。

Amazon WorkSpacesの運用でお困りの方はNTT東日本へお気軽にお問い合わせください。

4．ボリュームサイズの変更について

コンピューティングタイプの変更と比べて、ボリュームサイズの変更は制約条件や気を付けることが多くなります。

4-1．ボリュームサイズの変更時における注意点

ボリュームサイズの変更時の注意点は各項目について制約事項が多くなるので、少し分けてご説明したいと思います。

4-1-1．ボリュームタイプおよびボリュームサイズの制限

WorkSpacesで変更可能なボリュームタイプは、SSDタイプのみとなります。

マグネティックタイプのボリュームは変更できません。マグネティックタイプのWorkSpacesは2017年2月以前に構築されたものになりますので、再構築の検討をお勧めします。再構築時にSSDに置換されます。

SSDタイプの変更ですが、以下の組み合わせから選択する形になります。

※Windowsの場合、ルートボリューム=Cドライブ/ユーザボリューム=Dドライブとなります

パーティションについては自動的に拡張されますので、OS側の操作は特に必要ありません。

ここで気を付けるポイントは、一番下のタイプに変更する場合です。

• 一番下のタイプに変更する場合は、まずユーザボリュームを100GBにする必要がある
• ユーザボリュームだけ500GBにしたい、という場合でもルートボリュームを175GB以上にする必要がある

またボリュームの縮小はできないので、コスト効率を考えるとボリュームサイズの選択は慎重に行う必要があります。

ボリュームをむやみに増やすよりはWorkSpaces側はローカルで作業が必要になる最小限のボリュームとしておいて、ファイルサーバーやWorkDocsなどの共有ストレージを利用したほうがおススメです。

また、バンドルタイプがグラフィックス/グラフィックスプロ/Graphics.g4dn/GraphicsPro.g4dnの場合は最小100GBのルートボリューム・ユーザボリュームでも起動できます。

4-1-2．ボリュームサイズ変更時の注意点

ボリュームサイズ変更時の注意点としては、以下の通りとなります。かなり多くなりますので、ご注意が必要です。

• 新規に作成したWorkSpacesのボリュームサイズが変更できるのは、作成してから6時間以降
• 両方のボリュームを同時に変更することは出来ないので、順番に行う必要がある。両方のボリュームを増やす場合はどちらか片方のボリュームを増やしてから、20-30分ほど待機してもう片方のボリュームサイズの変更を行う必要がある
• 同じボリュームを再度拡張する場合は、前回の変更から6時間経過する必要がある
• WorkSpacesが起動中でもボリュームサイズの変更は可能だが、停止中にボリュームサイズの変更を行った場合は起動できない
  （補足：公式ドキュメントの日本語版は「ディスクサイズの拡大中にユーザーが自身の WorkSpaces を使用できるようにするには、WorkSpaces のボリュームのサイズを変更する前に、WorkSpaces のステータスが AVAILABLE ではなく STOPPED であることを確認します。」とあるのですが、英語版を読むと「If you want your users to be able to use their WorkSpaces while the disk size increase is in progress, make sure the WorkSpaces have a status of AVAILABLE instead of STOPPED before you resize the volumes of the WorkSpaces.」とありますので、意味が逆になっています。公式ドキュメントでは英語版と他の言語の記載が矛盾している場合、英語版の表記が優先されるため、上記の解釈が正しくなります）
• ボリュームサイズの変更が完了した後、再起動する必要がある
• ボリューム拡大のプロセスは最大で2時間かかる。同時に対応しているWorkSpacesの数が多い場合は長くなりがちなので、事前にAWS Supportへ連絡する

4-1-3．ボリュームサイズの変更作業のプロセス

上記の注意点を踏まえて、ボリュームサイズの変更を行うには、次のようなプロセスとなります。

(例：ルートボリューム80GB・ユーザボリューム50GBから、ルートボリューム175GB・ユーザボリューム500GBに変更する場合)

①2017年2月以降に構築されたWorkSpacesかどうかを確認する。2017年2月以前の場合は、再構築も検討する

②ユーザボリュームを100GBに増加させる

③ボリューム追加完了後、再起動する

④20-30分程度待機したのち、ルートボリュームを175GBに増加させる

⑤④の完了から6時間以上経過後、ユーザボリュームを500GBに増加させる

⑥ボリューム追加完了後、再起動する

このように、複数に及ぶ作業な上に、6時間以上を必要とします。オンプレミスのパソコンのボリューム拡張の場合、パソコンの電源を落としディスクを物理的に接続し、マウントする作業とするとそれほど大掛かりにはならないことから、パソコンの感覚で簡単に考えると作業時間の見積を誤る例になります。

また、EC2のEBS拡張も16TiBまでユーザボリュームは特段の考慮なく拡張できること、ルートボリュームの変更も2TiBまでは特に問題がないこと、2TiBを超える場合もGPTのパーティション分割が必要ですが、変更は可能ですので、この感覚でとらえると運用時のトラブルのもとになるので、ご注意が必要です。

このことから、ボリュームをむやみに拡張するよりも、可能なものは共有ストレージの利用を検討して、かつどうしても大きなボリュームが必要なWorkSpacesが必要となる場合は再構築するのもひとつの戦略となります。「どうしてもその仮想マシンでないといけないか？」は一度考えることをお勧めします。

言い古された言葉ですが、「クラウドリソースは家畜として扱う」というのは、ここWorkSpacesでも同様となります。

5．まとめ

このように、WorkSpacesの変更については、いくつかの注意事項と作業前の確認事項が必要となります。

VDI構築・運用についても、当社のクラウドVDI設定・運用サービスにてサポートさせていただきますので、お気軽にお問い合わせください。既に構築済みの環境でもご相談可能です。

Amazon WorkSpacesの運用でお困りの方はNTT東日本へお気軽にお問い合わせください。

Amazon Web Services(AWS)および記載するすべてのAmazonのサービス名は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。