コンピュートインスタンスのシェイプ変更の制約と対応

はじめに

OCIのコンピュートインスタンスは、構築後もベースとなるシェイプ(ハードウェアタイプ)を変更できます。 利用中のシステムを手間なく最新のシェイプにアップデートできるのは魅力的だが、実際に変更を実施してみていくつかの制限があることが判りました。この記事では、発覚した制約をお伝えし、その制約を持つインスタンスのシェイプの変更を実施した際の経験をまとめてお伝えします。

シェイプ変更の制約

1. 構築から時が経過した場合、変更できない場合がある
   筆者の担当した環境では、複数のStandard.E4.Flexが構築されており、全てをStandard.E6.Flexに変更しようとしたところ、プロジェクトの初期に構築したインスタンスは、シェイプの変更画面にStandard.E6.Flexが選択肢として表示されませんでした。 これらの差を確認したところ、OSイメージが違っていました。このイメージの互換性により変更できるシェイプが限定されるようです。
2. ブロックボリュームを複数アタッチしているVMは変更できない
   ブートボリューム+ブロックボリューム2つ(D:とE:に割り当て)のVMのシェイプを変更しようとしたところ、以下のエラーが表示されました。
   
   ブロックボリュームは1つまでしかサポートされないとのことでした。 対応としては、ブロックボリュームを1つに減らすことで、シェイプの変更ができるだろうと思い、実施しました。結論から言うと、成功はできたのですが、作業がシンプルでなく、計画段階で想定していた作業が必須でなかったりしました。

作業対象コンピュートインスタンスの構成

作業前に想定した手順

1. 作業前の状態調査
2. バックアップ取得
3. OS上での取り外し
4. ブロックボリュームのデタッチ
5. シェイプの変更 (通常のシェイプ変更とまったく同じ手順)
6. ブロックボリュームのアタッチ
7. OS上でのドライブ設定
8. 動作確認等の後処理 (2.のバックアップ削除)

構築やバックアップからの戻しの際のブロックボリューム設定が6～8なので、逆の作業として3と4(ブロックボリューム取り外し)を想定しました。
また、今回は確認の意味も含めて、2.バックアップ取得と1.作業前の状態調査を追加しました。
実際に作業してみたところ、心配していたトラブルは発生しませんでした。
用心のために実施した調査や作業は必要でなかったこと、作業時に気が付いたことを踏まえると、想定よりも必須の作業が少なくなりました。

実施作業

省略しても問題なかった各作業項目には「(任意)」と追記します。

1.作業前の状態調査 (任意)

シェイプ変更時に取り外す各環境のブロックボリュームを調査しました。OCIコンソールのインスタンス画面にある「ストレージ」タブから、アタッチされたブロックボリュームの「名前」「ボリュームIQN」および「iSCSIコマンド」を記録しておきます。これらの項目は、「6.1.作業後の状態調査」でも行い、シェイプ変更前後で変わらないことが確認されています。考えてみるとブロックボリューム自体は同一のものなので、前後で変化がないのでしょう。

2.バックアップ取得 (任意)

取り外し対象のドライブ(今回は E: )の内容を、念のためバックアップしておきました。
大事なデータが入ったドライブはバックアップを取得した方が無難ですが、当作業後にドライブの内容はキープできたためこのステップは、任意としました。

3.OS上での取り外し (任意)

このステップは任意とします。実行しなくても対応できることが確認できてますが、参考のため記載しました。
対象サーバーにリモートデスクトップでログインし、iSCSIイニシエータを起動します(iscsicpl.exeを実行)
対象のiSCSIをボリュームIQNを目安に選択し、「切断」します。 利用中のドライブであるため、すぐに切断できず、数回リトライして切断されます。

①該当環境では、初回切断時には確認が出力されました(アクティブセッション数は1)

➁利用中の場合は一度ではログオフできません

➂もう一度「切断」を実施すると、確認メッセージが変わりました (アクティブセッション数は0)

④結果として該当ボリュームは「非アクティブ」となります

⑤E: ドライブも見えなくなりました

4.ブロックボリュームのデタッチ

OCIコンソールからコンピュートインスタンスの「ストレージ」を表示し、 アタッチされたブロックボリュームのうち、取り外し対象のブロックボリュームをデタッチします。

デタッチ選択後、確認が入ります。(この警告を読む限り、やはり 3.の作業は必要そう)

少し待つと、アタッチされたブロックボリュームの一覧から表示されなくなります。

これで、シェイプ変更の前提が整いました。

5.シェイプの変更

通常のシェイプ変更とまったく同じ手順です。

コンピュートインスタンスの詳細画面から、編集に進みます。

インスタンスの編集画面から、変更対象のインスタンスを選択し、「変更の保存」を押して完了します。

インスタンスが起動している状態の場合、「インスタンスの再起動」の確認が入ります。

6.ブロックボリュームのアタッチ

6-1.アタッチ作業

コンピュートインスタンスのストレージ、の「アタッチされたブロックボリューム」にある「ブロックボリュームのアタッチ」を選択します。※
(※注意: VMが停止していると、APIエラーが発生するので、起動していない場合は事前に起動が必要です)

ボリュームの選択からデタッチしたボリュームを選択します アタッチメント・タイプの「カスタム」を選択し、ISCSIの読み込み/書き込みを設定し、「アタッチ」を押します。

しばらくするとアタッチされたブロックボリュームに上記処理のブロックボリュームが追加されます。

6.2.作業後の状態調査

iSCSIコマンドおよび情報を確認します。7で実行する場合に備え、iSCSIコマンドをメモします。 OCIコンソールからのインスタンスの「ストレージ」のアタッチされた「ブロックボリュームの名前」と「ボリュームIQN」および「iSCSIコマンド」記載します。

当作業前と変わっていないことが確認できます。(iSCSIコマンド、ボリュームIQNとも)

7.OS上でのドライブ設定

7-1.OS上でのドライブ確認

該当サーバーにリモートデスクトップ接続し、ドライブとして認識されているかを確認します。

7-2. 外れている場合のリカバリー (必要時のみ実施)

「3.OS上での取り外し」の作業を実施したケース、または、「6.ブロックボリュームのアタッチ」のタイミングによっては外れている場合があります。

(1)iSCSIイニシエータによるリカバリー

iscsicpl を実行し、iSCSIイニシエーターを起動します。

「ターゲット」タブで、該当のiSCSIが「接続完了」になっていない場合、「接続」を試みます。

うまくいかない場合は、いったん「切断」後、「接続」を再実施します。 「接続」ができない場合は、再起動してみてください。

(2) iSCSIコマンドの実行 (任意)

PowerShellを開き、6.1でメモしたiSCSIコマンドを打鍵してみました。コマンドの応答を見る限りでは必要なさそうに見えます。ここまでの作業で成功しなかった場合にのみ試してみてください。

7-3. iSCSIイニシエータとドライブの確認

iscsicpl を実行し、iSCSIイニシエーターを起動します。(7-1.をスキップした場合)

iSCSIイニシエータで、該当のボリュームが接続完了になっていることを確認します。

切断したドライブの復旧を確認します。

8.最終確認

シェイプ変更後、ドライブの状態に問題がないことを確認し、作業を完了しました。

8-1.切断したドライブが作業前と同様に利用できることを確認しました。

・作業前のディレクトリやファイルが残っていること

・ファイルの読み込み/書き込みが正常に行えること

8-2.OSの再起動
OSを再起動して、ドライブが接続されていることも確認できました。

8-3.バックアップの削除
手順2.で取得したバックアップを削除しました。

結論

OCIのコンピュートインスタンスは、シェイプ(構成の違うハードウェア)を簡単に変更できます。 2026年現在のシェイプの変更サービスは、ブロックボリュームが1つまでに制限されています。複数接続されている場合は、取り外して変更処理後、再度接続することで変更可能です。 シェイプ変更の処理は、構築時のOSイメージによってはできない場合があります。

これらを参考にシェイプの変更を活用してください。