第3章 仮想マシンのインスタンス

以下の各項の手順に従って、ネットワーク、キーペアを作成し、イメージまたはボリュームソースをアップロードします。これらのコンポーネントは、インスタンスの作成に使用され、デフォルトでは提供されません。また、新規セキュリティーグループ作成して、ユーザーが SSH アクセスできるようにする必要があります。

インスタンスを更新するには、プロジェクト > コンピュート > インスタンス を選択してから、そのインスタンスに対して実行するアクションを アクション コラムで選択します。これらのアクションにより、数多くの方法でインスタンスを操作することができます。

外部の IP アドレスを作成して確保することができます。「Floating IP アドレスの作成、割り当て、解放」を参照してください。

インスタンスのリサイズ (メモリーまたは CPU 数) を行うには、適切な容量のあるインスタンスで新規フレーバーを選択する必要があります。サイズを大きくする場合には、ホストに十分な容量があることをあらかじめ確認することを忘れないようにしてください。

本項では、Dashboard またはコマンドラインインターフェースを使用して、インスタンスのコンソールにアクセスする複数の方法について説明します。また、インスタンスのシリアルポートに直接接続して、ネットワーク接続が失敗しても、デバッグすることが可能です。

# git clone https://github.com/cloudbuilders/nova-xvpvncviewer
# cd nova-xvpvncviewer/viewer
# make

# java -jar VncViewer.jar _URL_

$ nova get-serial-console INSTANCE_ID

# git clone https://github.com/larsks/novaconsole/
# cd novaconsole

# python console-client-poll.py

以下のような使用状況統計が提供されます。

同時に複数のインスタンスを起動する必要がある場合には (例: コンピュートまたはコントローラーのメンテナンスでダウンしている場合など)、プロジェクト > コンピュート > インスタンス から簡単に起動できます。

同様に、適切なアクションを選択して、複数のインスタンスを終了またはソフトリブートすることができます。

キーペアにより、インスタンスへ SSH でアクセスすることができます。キーペアの生成時には毎回、証明書がローカルマシンにダウンロードされ、ユーザーに配布できます。通常は、プロジェクトごとにキーペアが 1 つ作成されます (そのキーペアは、複数のインスタンスに使用されます)。

既存のキーペアを OpenStack にインポートすることも可能です。

# ssh-add ~/.ssh/os-key.pem

セキュリティーグループとは、プロジェクトのインスタンスに割り当て可能な IP フィルターのルールセットで、インスタンスへのネットワークのアクセス権限を定義します。セキュリティーグループはプロジェクト別になっており、プロジェクトメンバーは自分のセキュリティーグループのデフォルトルールを編集して新規ルールセットを追加することができます。

プロジェクトのセキュリティー管理に関する詳しい情報は、Red Hat OpenStack Platform で『ユーザーおよびアイデンティティー管理ガイド』の「プロジェクトのセキュリティー管理」の項を参照してください。

デフォルトでは、インスタンスを最初に作成する際に、そのインスタンスに内部 IP アドレスが割り当てられますが、Floating IP アドレス (外部アドレス) を作成して割り当てることによりパブリックネットワークを介したアクセスを有効にすることができます。インスタンスに割り当てられている IP アドレスは、インスタンスの状態に関わらず変更することができます。

プロジェクトには、使用できる Floating IP アドレスの範囲が限定されているので (デフォルトの上限は 50)、必要がなくなったアドレスは、再利用できるように解放することを推奨します。Floating IP アドレスは、既存の Floating IP プールからのみ確保することができます。Red Hat OpenStack Platform で『ネットワークガイド』の「Floating IP プールの作成」の項を参照してください。

前提条件

最初に、キーペアのファイルを SSH に読み込み、次に名前を指定せずに ssh を使用します。

以下のコマンドの例は、Red Hat Enterprise Linux のゲストイメージに cloud-user として SSH アクセスする方法を示しています。

$ ssh cloud-user@192.0.2.24

$ ssh -i /myDir/os-key.pem cloud-user@192.0.2.24

以下の手順に従って、admin (root) パスワードを挿入することができます。

nova boot コマンドを使用して、新規インスタンスを起動する際には、コマンドの出力に adminPass パラメーターが表示されます。このパスワードを使用して、インスタンスに root ユーザーとしてログインすることができます。

Compute サービスは、/etc/shadow ファイル内のパスワード値を root ユーザー用に上書きします。以下の手順は、KVM ゲストイメージの root アカウントをアクティブ化するのにも使用することが可能です。KVM ゲストイメージの使用方法についての詳しい情報は、「Red Hat OpenStack Platform における KVM ゲストイメージの使用」を参照してください。

Dashboard からカスタムパスワードを設定することも可能です。これを有効にするには、can_set_password パラメーターを true に設定した後に、以下のコマンドを実行します。

# systemctl restart httpd.service

新規追加された admin パスワードフィールドは以下のように表示されます。

上記のフィールドは、インスタンスの起動/再ビルド時に使用することができます。

デフォルトでは、フレーバーの作成およびフレーバーの完全リストの表示ができるのは管理者のみです (「管理 > システム > フレーバー」を選択)。全ユーザーがフレーバーを設定できるようにするには、/etc/nova/policy.json ファイル (nova-api サーバー) で以下の値を指定します。

"compute_extension:flavormanage": "",

一般属性の編集に加えて、フレーバーにメタデータ (extra_specs) を追加することが可能です。メタデータは、インスタンスの使用方法を微調整するのに役立ちます。たとえば、最大許容帯域幅やディスクの書き込みを設定する場合などです。

デフォルトでは、ホストアグリゲートのメタデータは、インスタンスの使用先のフィルタリングには使用されません。メタデータの使用を有効にするには、Compute のスケジューラーの設定を更新する必要があります。

Dashboard に管理ユーザーとしてログインして 管理 > システム > ホストアグリゲート を選択します。ホストアグリゲート のセクションに現在定義済みのアグリゲートがすべてリストされます。アベイラビリティーゾーン のセクションには全ゾーンがリストされます。

scheduler_default_filters オプションでスケジューラーが使用するフィルターを定義します (/etc/nova/nova.conf ファイル。root または nova ユーザーのパーミッションが必要)。

デフォルトでは、以下のフィルターがスケジューラーで実行されるように設定されています。

scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

一部のフィルターは、以下の方法でインスタンスに渡されるパラメーターの情報を使用します。

以下の表には、利用可能な全フィルターをまとめています。

セルとホストはいずれも、スケジューリング用に重み付けすることができます。(フィルタリング後に) 重みが最大のホストまたはセルが選択されます。重み付け関数にはすべて、ノードの重みを正規化した後に適用される乗数が指定されます。ノードの重みは以下のように計算されます。

w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...

重みのオプションは、ホストの /etc/nova/nova.conf ファイルで設定することができます (root または nova ユーザーのパーミッションが必要です)。

共有ストレージを使用する場合には、以下の手順に従って Compute サービスのインスタンスディレクトリーを 2 つのノードにエクスポートし、ノードがアクセスできることを確認します。ディレクトリーのパスは /etc/nova/nova.conf ファイルの state_path および instances_path のパラメーターで設定されます。この手順では、デフォルト値の /var/lib/nova/instances を使用しています。共有ストレージを設定することができるのは、root アクセスのあるユーザーのみです。

# df -k

$ glance image-update IMAGE_ID --property os_require_quiesce=yes

$ glance image-create --name NAME \
--disk-format raw \
--container-format bare \
--file FILE_NAME \
--is-public True \
--property hw_qemu_guest_agent=yes \
--progress

スナップショットからインスタンスを起動するには、スナップショットを選択して 起動 をクリックします。

スナップショットがベースとなっているインスタンスを削除する場合には、スナップショットにはインスタンス ID が保存されます。nova image-list コマンドを使用してこの情報を確認して、スナップショットでインスタンスを復元します。

インスタンスの起動に関する詳しい情報は 「インスタンスの作成」を参照してください。

以前のリリースでは、バックアップの一貫性を確保するには、アクティブなインスタンスのスナップショットを作成する前にファイルシステムを手動で停止 (fsfreeze) する必要がありました。

Red Hat OpenStack Platform 7 リリース以降のバージョンでは、Compute の libvirt ドライバーは、QEMU ゲストーエージェント にファイルシステムを (fsfreeze-hook がインストールされている場合には、アプリケーションも対象) フリーズするように自動的に要求します。ファイルシステムの停止に対するサポートにより、スケジュールされた自動スナップショット作成をブロックデバイスレベルで実行できるようになりました。

この機能は、QEMU ゲストエージェント (qemu-ga) がインストール済みで、かつイメージのメタデータで有効化されている (hw_qemu_guest_agent=yes) 場合にのみ有効です。

ブートディスクとレスキューモード用のディスクには同じ UUID が使用されているため、仮想マシンがレスキューモード用のディスクの代わりにブートディスクから起動されてしまう可能性があります。

この問題を回避するには、レスキュー用のイメージを nova から取得する前に、初期イメージで以下の手順を実行する必要があります。

対象のイメージの UUID を変更したら、以下のコマンドを実行して、生成されたレスキューイメージを OpenStack Image サービスに追加します。

OpenStack Dashboard を使用してイメージをアップロードすることも可能です。「イメージのアップロード」の項を参照してください。

これで、インスタンスに必要な変更を加えて、問題を修正できる状態となりました。

修正したインスタンスは unrescue して、ブートディスクから再起動することができます。

アンレスキューの操作が正常に完了すると、インスタンスのステータスは ACTIVE に戻ります。