- 1. はじめに
- 2. OpenNebulaの特徴と位置づけ
- 3. 検証環境の構築
- 4. 検証
- 5. まとめ
- 6. 参考資料
- 7. 商標について
- 8. 免責事項
1. はじめに
1.1. 検証の背景と目的
NTT西日本の平岡です。
本記事では、オープンソースのクラウド管理プラットフォームであるOpenNebula 7.0を実際に構築し、その特徴的な機能を検証した結果をご報告いたします。
近年、オンプレミス環境でのプライベートクラウド基盤構築において、オープンソースソリューションの重要性が高まっています。OpenNebulaは、VMware vSphereやProxmox VEと同様に、複数の物理ホスト上で仮想マシン(VM)を統合管理できる仮想化基盤です。
本検証では、特に以下の点に焦点を当てました。
- OpenNebula独自のストレージ管理アーキテクチャ(IMAGE/SYSTEM Datastore)
- 共有ストレージ環境でのスナップショット機能
- Live Migration(ライブマイグレーション)の実現
- Persistent ImageとSymbolic Linkによるディスク容量の最適化
1.2. 対象読者
本記事は、以下のような方々を想定しています。
- 仮想化基盤の導入を検討されている方: OpenNebulaの特徴や導入方法を知りたい方
- 既存の仮想化基盤からの移行を検討されている方: Proxmox VE等の他の仮想化基盤との違いを理解したい方
- OpenNebulaの基本的な知識をお持ちの方: より実践的な構築手順や運用上の知見を求めている方
OpenNebulaの基本的な概念については公式ドキュメントをご参照いただくことを前提としていますが、本記事内でも簡潔に概要を説明いたします。
1.3. 検証条件
本記事は、2025年12月時点の情報に基づいています。
- OpenNebula: バージョン 7.0
- Ubuntu Server: 24.04 LTS
- Proxmox VE: 8.3(ホスト環境)
本記事が、OpenNebulaの導入を検討されている方々の参考になれば幸いです。
2. OpenNebulaの特徴と位置づけ
2.1. OpenNebulaとは
OpenNebulaは、オープンソースのクラウド管理プラットフォームであり、複数の物理ホスト上で仮想マシン(VM)を統合管理するためのソリューションです。2008年に開発が開始され、Apache License 2.0の下で公開されています。
OpenNebulaの主な特徴は以下の通りです。
- 軽量性: VMware vSphere※と比較して、システム要件が低く、小規模環境でも導入しやすい
- ハイパーバイザー: KVM、LXC、Firecracker(microVM)等に対応
- API: REST APIによる自動化が容易
- マルチテナント対応: ユーザー/グループ単位でのリソース分離が可能
- ハイブリッドクラウド対応: AWS EC2、Microsoft Azureとの統合によりハイブリッドクラウド構成が可能
2.2. 他の仮想化基盤との比較
OpenNebulaは、以下のような特徴を持つオープンソースのクラウド管理プラットフォームです。
| 項目 | OpenNebula | Proxmox VE | VMware vSphere |
|---|---|---|---|
| ライセンス | Apache 2.0(OSS) | AGPL v3(OSS) | 商用 |
| システム要件 | 低 | 低 | 高 |
| ハイパーバイザー | KVM, LXC, Firecracker等 | KVM, LXC | ESXi専用 |
| ストレージ構造 | 2階層(IMAGE/SYSTEM) | 1階層(統合管理) | 1階層(統合管理) |
| API | REST API | REST API | vSphere API |
| コスト | 無料/有料 | 無料/有料 | 無料/有料 |
2.3. 最重要ポイント:ディスクイメージの扱い方の違い
OpenNebulaの最も特徴的な点は、2階層のデータストア構造です。
Proxmox VEとの比較:
| 項目 | Proxmox VE | OpenNebula |
|---|---|---|
| デフォルトクローン | Full Clone(完全複製) | Non-Persistent Image(バッキングファイル) |
| ストレージ構造 | 1階層(統合管理) | 2階層(IMAGE/SYSTEM Datastore) |
| テンプレート保存 | ストレージ上 | IMAGE Datastore(専用) |
| VM稼働ディスク | 同一ストレージ | SYSTEM Datastore(専用、別の場所も可) |
OpenNebulaの2階層構造の利点:
- IMAGE Datastore: VMテンプレート(イメージ)を保存する専用領域
- SYSTEM Datastore: 実際にVMが稼働する際のディスクが配置される領域
この分離により、例えば「高速なSANにテンプレートを保存し、ローカルSSDでVMを実行」といった柔軟な構成が可能になります。
3. 検証環境の構築
3.1. 環境概要
本検証では、入れ子仮想化(Nested Virtualization)環境を使用しました。
ホスト環境:
- 物理ホスト: Proxmox VE 8.3
- ゲストOS: Ubuntu Server 24.04 LTS
- OpenNebula: バージョン 7.0
ストレージ:
- TrueNAS Scale:
192.168.11.4 - iSCSI Target:
iqn.2005-10.org.freenas.ctl:block - iSCSI LUN: 750GB(Zvol)
3.1.1. 最終構成
本検証では、最終的に以下の構成を構築します。
最終構成(3台のCompute Node構成):
- Frontend + Compute Node: 1台
- ホスト名:
nebula-f1 - IPアドレス:
192.168.11.110 - 役割: Frontend機能 + VM実行
- ホスト名:
- Compute Node: 2台
- ホスト名:
nebula-n1,nebula-n2 - IPアドレス:
192.168.11.111,192.168.11.112 - 役割: VM実行
- ホスト名:
3.1.2. 初期構成(構築開始時)
ただし、構築は以下の初期構成から開始します:
- Frontend(フロントエンド): 1台
- ホスト名:
nebula-f1 - IPアドレス:
192.168.11.110 - 役割: OpenNebulaの管理機能のみ
- ホスト名:
- Compute Node(計算ノード): 2台
- ホスト名:
nebula-n1,nebula-n2 - IPアドレス:
192.168.11.111,192.168.11.112 - 役割: VM実行
- ホスト名:
この初期構成で基本環境を構築した後、4.3章「FrontendへのCompute Node機能の追加」にて、nebula-f1にもCompute Node機能を追加し、最終構成へと移行します。
3.1.3. 前提条件
本手順を実施する前に、以下が必要です。
- Proxmox VE 8.3環境: 入れ子仮想化が有効化されていること
- ネットワーク環境: 各ノードが相互に通信可能なネットワーク(本検証では
192.168.11.0/24) - TrueNAS Scale環境(共有ストレージ構築用): iSCSI Target機能が利用可能であること
以下は、本記事では構築手順を省略し、構築済みの前提とします。
- Proxmox VEホスト環境: 物理ホストまたはProxmox VE環境
- 各ノード(Frontend/Compute Node)のVM: Ubuntu Server 24.04 LTSがインストール済み
- TrueNAS Scale環境: iSCSI LUN提供用(共有ストレージ構築用)
3.2. FrontendとCompute Nodeの準備
本セクションでは、全ノード(Frontend 1台 + Compute Node 2台)に対して、OpenNebulaインストール前の準備作業を実施します。
3.2.1. 重要な前提条件
各VMは個別にインストールする必要があります。クローン機能を使用すると、以下の問題が発生します。
machine-idの重複- SSH host keyの重複
- DHCP識別子の重複
- iSCSI IQNの重複
これらは、OpenNebulaのクラスタ構成や共有ストレージの構築において深刻な問題を引き起こす可能性があります。
本セクションの対象ノード:
nebula-f1(192.168.11.110): Frontendnebula-n1(192.168.11.111): Compute Nodenebula-n2(192.168.11.112): Compute Node
以下の手順は、上記3台全てのノードで実施してください。
3.2.2. ホスト設定手順
1. ユーザー作成(全ノードで実行)
各ホストでflathillユーザーを作成し、sudo権限を付与します。
sudo adduser flathill sudo usermod -aG sudo flathill
2. 静的IPアドレスの設定(全ノードで実行)
Netplanを使用して静的IPアドレスを設定します(/etc/netplan/50-cloud-init.yamlを編集)。
network: version: 2 ethernets: enp6s18: addresses: - 192.168.11.110/24 # 各ホストで異なるIP(110, 111, 112) routes: - to: default via: 192.168.11.1 nameservers: addresses: - 1.1.1.1 - 8.8.8.8
設定を適用します。
sudo netplan apply
3. ホスト名と名前解決の設定(全ノードで実行)
各ホストで/etc/hostsを編集します。
192.168.11.110 nebula-f1 192.168.11.111 nebula-n1 192.168.11.112 nebula-n2
3.3. OpenNebulaのインストール
3.3.1. OneDeploy(Ansible)について
OpenNebula 7.0では、AnsibleベースのOneDeployを使用した自動インストールが推奨されています。
OneDeployの特徴:
- 自動化: Ansibleによるプロビジョニングで、手動設定を最小化
- 一貫性: 全ノードに対して統一された設定を適用
- 柔軟性: インベントリファイルで構成をカスタマイズ可能
- 公式サポート: OpenNebula公式が提供するデプロイ方法
詳細は、OpenNebula公式ドキュメントをご参照ください。
3.3.2. インストール全体の流れ
本セクションでは、以下の流れでOpenNebulaをインストールします。
- Frontend(
nebula-f1)での準備: OneDeploy環境の構築 - インベントリファイルの作成: 構成情報の定義
- SSH鍵認証の設定: Ansible実行用の認証設定
- OpenNebulaのデプロイ: Playbook実行による自動インストール
- ネットワークブリッジの手動調整: Ubuntu 24.04特有の調整
実行ノード:
- 準備〜デプロイ:
nebula-f1(Frontend)で実行 - ネットワーク調整: 全ノード(
nebula-f1,nebula-n1,nebula-n2)で実行
3.3.3. Frontend(nebula-f1)での準備
実行ノード: nebula-f1
1. 必要なパッケージのインストール
sudo apt update sudo apt install -y python3-pip pipx git
2. one-deployリポジトリのクローン
git clone https://github.com/OpenNebula/one-deploy.git cd one-deploy
3. Python仮想環境の構築
pipx install hatch hatch shell make requirements
3.3.4. インベントリファイルの作成
実行ノード: nebula-f1
example.ymlファイルを作成し、以下のように設定します。
all: vars: ansible_user: flathill ansible_become: true one_version: '7.0' one_pass: ******** ds: mode: ssh vn: admin_net: managed: true template: VN_MAD: bridge PHYDEV: enp6s18 BRIDGE: br0 AR: TYPE: IP4 IP: 192.168.11.128 SIZE: 48 NETWORK_ADDRESS: 192.168.11.0 NETWORK_MASK: 255.255.255.0 GATEWAY: 192.168.11.1 DNS: 1.1.1.1 children: frontend: hosts: nebula-f1: ansible_host: 192.168.11.110 node: hosts: nebula-n1: ansible_host: 192.168.11.111 nebula-n2: ansible_host: 192.168.11.112
注意: one_passには、oneadminユーザーのパスワードを設定してください。
3.3.5. SSH鍵認証の設定
実行ノード: nebula-f1
1. SSH鍵ペアの生成
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
2. 公開鍵の配布
ssh-copy-id flathill@192.168.11.110 ssh-copy-id flathill@192.168.11.111 ssh-copy-id flathill@192.168.11.112
3.3.6. OpenNebulaのデプロイ
実行ノード: nebula-f1
1. 接続テスト
ansible -i example.yml all -m ping
2. デプロイの実行
ansible-playbook -i example.yml opennebula.deploy.main
デプロイには約10〜15分程度かかります。
3.3.7. ネットワークブリッジの手動調整
実行ノード: 全ノード(nebula-f1, nebula-n1, nebula-n2)
Ubuntu 24.04では、OneDeploy後にbr0ブリッジの手動調整が必要な場合があります。
手動調整が必要な条件:
- OneDeploy実行後、ネットワーク接続が不安定になる場合
br0ブリッジが正常に動作していない場合(例: VMが外部ネットワークに接続できない)/etc/netplan/配下の自動生成されたファイルが正しくない場合
調整手順:
各ノードで/etc/netplan/配下の設定ファイル(例: 01-netcfg.yaml)を確認し、必要に応じて以下のように調整します。
network: version: 2 ethernets: enp6s18: dhcp4: false bridges: br0: interfaces: [enp6s18] addresses: - 192.168.11.110/24 # 各ホストで異なるIP(110, 111, 112) routes: - to: default via: 192.168.11.1 nameservers: addresses: - 1.1.1.1 - 8.8.8.8 dhcp4: false
設定を適用します。
sudo netplan apply
3.4. Sunstone WebUIへのアクセス
ブラウザで以下のURLにアクセスします。
http://192.168.11.110:2616
ログイン情報:
- ユーザー名:
oneadmin - パスワード: インベントリファイルで設定した値
4. 検証
4.0. 検証結果サマリ
本章では、OpenNebulaの主要機能について8つの項目を検証しました。以下、各検証項目の概要と結果をまとめます。
4.0.1. 検証項目一覧
| 項目 | 目的 | 主要技術 | 結果 |
|---|---|---|---|
| 4.1 VM作成の基礎 | ISOイメージからの任意OS(Ubuntu 24.04)インストール検証 | ISO Upload, Disk Image作成, VNC Console | ✅ 成功 - MarketplaceなしでVM作成可能 |
| 4.2 共有ストレージの構築 | iSCSI + OCFS2によるクラスタファイルシステム構築 | iSCSI Initiator, Multipath(WWID), OCFS2, Datastore登録 | ✅ 成功 - 3ノードで共有ストレージ利用可能 |
| 4.3 Compute Node追加 | FrontendへのCompute Node機能追加(--limitによる段階的追加) |
OneDeploy, Ansible --limitオプション |
✅ 成功 - Frontend/Node共存動作確認 |
| 4.4 ストレージ管理 | IMAGE/SYSTEM Datastoreの2階層構造とTM_MADの理解 | TM_MAD(shared/qcow2/ssh), Persistent/Non-Persistent Image | ✅ 成功 - 2階層構造の動作確認 |
| 4.5 スナップショット | QCOW2による内部/外部スナップショット機能検証 | TM_MAD=qcow2, VMスナップショット, ディスクスナップショット | ✅ 成功 - スナップショット作成/復元動作確認 |
| 4.6 Live Migration | VM移行検証 | 共有ストレージ, dynamic_ownership, パケットロス測定 |
✅ 成功 - パケットロスなしで移行完了 |
| 4.7 ストレージ追加 | 2つ目のiSCSI LUN追加と複数ストレージ同時運用 | iSCSI Target(block2), /dev/mapper/mpathc, OCFS2(ocfs2-shared2) | ✅ 成功 - 複数共有ストレージ同時運用可能 |
| 4.8 Persistent Image検証 | Persistent Image + Symbolic Linkによるディスク容量最適化 | Symbolic Link, Persistent Image, ローカルディスク節約 | ✅ 成功 - Symbolic Linkでローカルディスク不使用を実現 |
本章の構成: 各セクションでは、目的・前提条件・手順・結果/考察を詳しく記載しています。
4.0.2. 主要な検証成果
本検証を通じて、以下の重要な成果を得ることができました。
✅ Live Migration の検証成功
- パケットロス: なし
- マイグレーション完了時間: 約2〜3秒
- VMスナップショット保持状態でも移行成功
- TM_MAD=qcow2/shared 両方で動作確認
✅ スナップショット機能の動作確認
- 内部スナップショット(VM全体): 作成/復元成功
- 外部スナップショット(ディスク個別): 作成/復元成功
- Persistent Imageでもスナップショット利用可能(
PERSISTENT_SNAPSHOTS="YES"設定)
✅ 共有ストレージの運用
- iSCSI + OCFS2による3ノードクラスタファイルシステム構築
- 2つの共有ストレージ(750GB×2)の同時運用成功
✅ ディスク容量の最適化
- Persistent Image + Symbolic Link方式によるディスク容量節約
- IMAGE Datastoreの容量を節約しつつPersistent Image運用可能
✅ 段階的なノード追加の実現
--limitオプションによる安全なノード追加- Frontend/Compute Node共存の動作確認
- 既存環境への影響なし
注意: 本検証結果は特定の検証環境における結果であり、すべての環境での動作を保証するものではありません。本番環境への適用前に、必ず各環境での十分な検証を実施してください。
4.1. VM作成の基礎
4.1.1. 目的
OpenNebula MarketplaceにないOSや、特定バージョンのOSをインストールする方法を検証します。具体的には、ISOイメージから直接OSをインストールし、カスタムVMを作成する手順を確認します。
この検証により、Marketplaceに依存せず、任意のOSをOpenNebula環境で利用できることを実証します。
4.1.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- Sunstone WebUIにアクセス可能であること
- デフォルトのDatastoreが利用可能であること
4.1.3. 手順
ここでは、Ubuntu 24.04 LTS Serverを例に手順をご説明します。
4.1.3.1. ISOイメージのアップロード
1. ISOファイルのダウンロード
Ubuntu公式サイトからubuntu-24.04.3-live-server-amd64.iso(約3GB)をダウンロードします。
2. Sunstone WebUIでのアップロード
Storage → Images → +Create → Uploadを選択します。
以下の項目を設定します。
- Name:
Ubuntu 24.04 LTS Server ISO - Type:
Readonly CD-ROM - Datastore:
default - File: ダウンロードしたISOファイルを選択
Createをクリックしてアップロードを開始します。
4.1.3.2. 空のディスクイメージの作成
OSをインストールするための空のディスクイメージを作成します。
Storage → Images → +Create → Createを選択します。
以下の項目を設定します。
- Name:
Ubuntu 24.04 Install Disk - Type:
Operating system image - Make Persistent: ✅ 必要に応じて
- Size:
30720 MB(30GB) - Datastore:
default
Createをクリックします。
4.1.3.3. VMテンプレートの作成
1. 基本設定
Templates → VMs → +Createを選択します。
以下の項目を設定します。
- Hypervisor:
KVM - Name:
Ubuntu 24.04 Install Template - Memory:
4 GB - Physical CPU:
2 - Virtual CPU:
2
2. ディスクの設定
Storageタブで、以下の順序でディスクを追加します。
- 先に:
Ubuntu 24.04 Install Disk - 後に:
Ubuntu 24.04 LTS Server ISO(Read-only: Yesとして追加)
3. ネットワークの設定
Networkタブで、Automatic Select Virtual Networkを選択し、SSHを有効化します。
4. ブート順序の設定
OS & CPUタブで、以下のブート順序を設定します。
- First boot device:
CD-ROM - Second boot device:
Hard Disk
この設定により、初回起動時にISOから起動し、OSインストール後はハードディスクから起動します。
Createをクリックしてテンプレートを作成します。
4.1.3.4. VMのインスタンス化とインストール
作成したテンプレートから、VMをインスタンス化し、通常のOSインストール手順でUbuntu 24.04 LTSをインストールします。
インストール完了後、VMを再起動すると、ハードディスクから正常に起動します。
4.1.4. 結果/考察
検証結果:
- ISOイメージから任意のOSをインストールできることを確認
- ブート順序の設定により、初回はCD-ROM、インストール後はHard Diskから起動することを確認
- OpenNebula Marketplaceに依存せず、カスタムOSを利用可能
考察:
- OpenNebulaは、Marketplace以外にも柔軟にOSを導入できる
- ブート順序の設定が正しくないと、インストール後もISOから起動し続けるため注意が必要
- 空のディスクイメージのサイズは、用途に応じて適切に設定する必要がある
4.2. 共有ストレージの構築
4.2.1. 目的
OpenNebulaのLive Migrationや高度な機能を活用するために、共有ストレージを構築します。本検証では、TrueNAS Scaleを使用してiSCSI LUNを提供し、各ノードでOCFS2クラスタファイルシステムを構築することで、全ノードからアクセス可能な共有ストレージを実現します。
この検証により、以下を確認します。
- iSCSI + OCFS2による共有ストレージの構築方法
- 全ノードからの同時アクセスが可能であること
- OpenNebulaのDatastoreとして利用可能であること
4.2.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- TrueNAS Scale環境が構築済みで、iSCSI Target機能が利用可能であること
- 全ノード(
nebula-f1,nebula-n1,nebula-n2)が相互に通信可能であること
4.2.3. 手順
4.2.3.1. iSCSI Initiatorの設定
全てのノード(nebula-f1, nebula-n1, nebula-n2)で以下の手順を実施します。
1. パッケージのインストール
sudo apt update sudo apt install -y open-iscsi multipath-tools
2. Initiator IQNの確認と再生成
重要: VMをクローンして作成した場合、Initiator IQNが重複している可能性があります。
現在のIQNを確認:
sudo cat /etc/iscsi/initiatorname.iscsi
全ノードで異なる値になっているか確認します。
重複している場合は再生成:
sudo rm /etc/iscsi/initiatorname.iscsi sudo systemctl restart iscsid sudo cat /etc/iscsi/initiatorname.iscsi
各ノードで一意のIQNが生成されていることを確認します。
3. iSCSI Targetの検出とログイン
# Targetの検出 sudo iscsiadm -m discovery -t st -p 192.168.11.4:3260 # ログイン sudo iscsiadm -m node --targetname iqn.2005-10.org.freenas.ctl:block --portal 192.168.11.4:3260 --login # 自動ログインの有効化 sudo iscsiadm -m node --targetname iqn.2005-10.org.freenas.ctl:block --portal 192.168.11.4:3260 --op update -n node.startup -v automatic
4. デバイスの確認
lsblk
750GBのディスク(例: /dev/sdb)が認識されていることを確認します。
5. Multipathの設定
/etc/multipath.confを作成または編集します。
sudo nano /etc/multipath.conf
以下の内容を追加します。
defaults {
user_friendly_names yes
find_multipaths yes
}
multipaths {
multipath {
wwid 33191e2b04c21abe0000000000000000
alias mpathb
}
}
wwidの値は、以下のコマンドで確認できます。
sudo /lib/udev/scsi_id -g -u -d /dev/sdb
Multipathサービスを再起動します。
sudo systemctl restart multipathd
注記: 検証環境では単一のパスしか存在しないため、wwidも1つとしています。
6. 設定の確認
sudo multipath -ll
/dev/mapper/mpathbが作成されていることを確認します。
全ノードでの確認
各ノードで同じLUNが認識され、同じ/dev/mapper/mpathbデバイスが存在することを確認します。
4.2.3.2. OCFS2クラスタファイルシステムの構築
1. OCFS2のインストール(全ノードで実行)
sudo apt update sudo apt install -y ocfs2-tools
2. O2CBの設定(全ノードで実行)
sudo dpkg-reconfigure ocfs2-tools
以下のように回答します。
- Would you like to start O2CB at boot time?:
Yes - Name of the cluster:
ocfs2 - Heartbeat threshold: デフォルト(Enter)
- Network idle timeout: デフォルト(Enter)
3. クラスタ設定ファイルの作成
nebula-f1で実行:
/etc/ocfs2/cluster.confを作成します。
sudo nano /etc/ocfs2/cluster.conf
以下の内容を記述します。
cluster:
node_count = 3
name = opennebula
node:
ip_port = 7777
ip_address = 192.168.11.110
number = 0
name = nebula-f1
cluster = opennebula
node:
ip_port = 7777
ip_address = 192.168.11.111
number = 1
name = nebula-n1
cluster = opennebula
node:
ip_port = 7777
ip_address = 192.168.11.112
number = 2
name = nebula-n2
cluster = opennebula
他のノードへ配布:
sudo scp /etc/ocfs2/cluster.conf nebula-n1:/tmp/ sudo scp /etc/ocfs2/cluster.conf nebula-n2:/tmp/
各ノードで以下を実行します。
sudo mv /tmp/cluster.conf /etc/ocfs2/cluster.conf sudo chown root:root /etc/ocfs2/cluster.conf sudo chmod 644 /etc/ocfs2/cluster.conf
4. サービスの起動(全ノードで実行)
sudo systemctl enable o2cb sudo systemctl start o2cb sudo systemctl enable ocfs2 sudo systemctl start ocfs2
5. ファイルシステムの作成
nebula-f1で実行:
sudo mkfs.ocfs2 -L "shared-iscsi1" -N 3 /dev/mapper/mpathb
-L: ファイルシステムのラベル-N: クラスタのノード数(3)
6. マウントポイントの作成(全ノードで実行)
sudo mkdir -p /mnt/shared-iscsi1
7. ファイルシステムのマウント(全ノードで実行)
sudo mount -t ocfs2 /dev/mapper/mpathb /mnt/shared-iscsi1
容量を確認します。
df -h /mnt/shared-iscsi1
750GB程度の容量が表示されることを確認します。
8. 所有者とパーミッションの設定(全ノードで実行)
sudo chown oneadmin:oneadmin /mnt/shared-iscsi1 sudo chmod 755 /mnt/shared-iscsi1
9. クラスタ機能の確認
nebula-f1で実行:
sudo touch /mnt/shared-iscsi1/test-from-f1.txt
nebula-n1とnebula-n2で確認:
ls -l /mnt/shared-iscsi1/
test-from-f1.txtが確認できれば、OCFS2クラスタが正常に機能しています。
10. 自動マウントの設定(全ノードで実行)
/etc/fstabに以下を追加します。
sudo nano /etc/fstab
/dev/mapper/mpathb /mnt/shared-iscsi1 ocfs2 _netdev,defaults 0 0
_netdevオプションは、ネットワークが利用可能になった後にマウントを試みることを示します。
4.2.4. 結果/考察
検証結果:
- iSCSI + OCFS2による共有ストレージを正常に構築できることを確認
- 全ノード(
nebula-f1,nebula-n1,nebula-n2)から同時にアクセス可能であることを確認 - あるノードで作成したファイルが、他のノードから即座に確認できることを確認
考察:
- OCFS2は、複数ノードからの同時書き込みに対応したクラスタファイルシステムであり、OpenNebulaの共有ストレージとして適している
- Multipathの設定により、iSCSI接続の冗長性を確保できる
- 自動マウント設定により、ノード再起動後も自動的に共有ストレージがマウントされる
4.3. FrontendへのCompute Node機能の追加
4.3.1. 目的
既存のFrontend専用ノード(nebula-f1)に対してCompute Node機能を追加します。これにより、Frontendの余剰リソースをVM実行にも活用できることを実証します。
この検証により、以下を確認します。
- 既存環境を停止せずに、ノードを追加できること
--limitオプションによる影響範囲の限定- 追加したノードが正常にCompute Nodeとして機能すること
4.3.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- 共有ストレージ(
/mnt/shared-iscsi1)が全ノードでマウント済みであること(4.2章) - 各ホストで
/etc/hostsに全ノードの名前解決が設定済みであること
4.3.3. 手順
4.3.3.1. インベントリファイルの更新
nebula-f1で実行:
まず、現在のインベントリファイルをバックアップします。
cd ~/one-deploy cp example.yml example.yml.backup
example.ymlを編集し、nodeセクションにnebula-f1を追加します。
nano example.yml
変更前:
children: frontend: hosts: nebula-f1: ansible_host: 192.168.11.110 node: hosts: nebula-n1: ansible_host: 192.168.11.111 nebula-n2: ansible_host: 192.168.11.112
変更後:
children: frontend: hosts: nebula-f1: ansible_host: 192.168.11.110 node: hosts: nebula-f1: # ← 追加 ansible_host: 192.168.11.110 # ← 追加 nebula-n1: ansible_host: 192.168.11.111 nebula-n2: ansible_host: 192.168.11.112
変更内容の確認:
diff example.yml.backup example.yml
以下のような差分が表示されることを確認します。
node:
hosts:
+ nebula-f1:
+ ansible_host: 192.168.11.110
nebula-n1:
ansible_host: 192.168.11.111
4.3.3.2. OneDeploy Playbookの再実行
重要: ここでは--limitオプションを使用して、nebula-f1のみに対してPlaybookを実行します。
hatch shell # Python仮想環境に入る(既に入っている場合は不要) ansible-playbook -i example.yml opennebula.deploy.main --limit nebula-f1
実行結果の例:
Playbookが正常に実行されると、以下のようなタスクが実行されます。
TASK [opennebula.deploy.opennebula/node : Install OpenNebula KVM packages] **** changed: [nebula-f1] TASK [opennebula.deploy.opennebula/node : Ensure unique Libvirt UUID] **** changed: [nebula-f1] TASK [opennebula.deploy.opennebula/node : Restart Libvirtd] **** changed: [nebula-f1] TASK [opennebula.deploy.opennebula/node : Update AppArmor permissions] **** changed: [nebula-f1] PLAY RECAP ********************************************************************* nebula-f1 : ok=25 changed=8 unreachable=0 failed=0
4.3.3.3. 追加したノードの確認
Sunstone WebUIでの確認:
Infrastructure→Hostsを選択nebula-f1がCompute Nodeとして追加されていることを確認
CLIでの確認:
onehost list
以下のような出力が得られます。
ID NAME CLUSTER RVM ALLOCATED_CPU ALLOCATED_MEM STAT 0 nebula-f1 default 0 0 / 200 (0%) 0K / 3.8G (0%) on 1 nebula-n1 default 0 0 / 200 (0%) 0K / 3.8G (0%) on 2 nebula-n2 default 0 0 / 200 (0%) 0K / 3.8G (0%) on
3台全てのホストがonステータスで表示されていることを確認します。
4.3.4. 結果/考察
検証結果:
--limitオプションにより、既存のノード(nebula-n1,nebula-n2)に影響を与えずに、nebula-f1のみにCompute Node機能を追加できることを確認- 追加した
nebula-f1が正常にCompute Nodeとして認識されることを確認 - 3台全てのノードが
onステータスで動作することを確認
考察:
- OpenNebulaは、既存環境を停止せずに柔軟にノードを追加できる
--limitオプションは、影響範囲を限定し、リスクを軽減する有効な手段- この手法は、段階的な環境拡張や、リソースの有効活用に非常に有用
OneDeploy --limitオプションの利点:
- 影響範囲の限定: 既存のノードに影響を与えない
- 実行時間の短縮: 1台のみに対して処理を行うため、高速に完了
- リスクの軽減: 既存環境を維持しながら、安全に変更を適用
最終構成の確認:
この時点で、OpenNebula環境は以下の構成になります。
- nebula-f1(192.168.11.110): Frontend + Compute Node
- nebula-n1(192.168.11.111): Compute Node
- nebula-n2(192.168.11.112): Compute Node
計3台のCompute Nodeが利用可能となり、Live Migrationの検証など、より実践的な環境が整いました。
4.4. OpenNebulaのストレージ管理
4.4.1. 目的
OpenNebula独自の2階層ストレージ構造(IMAGE Datastore / SYSTEM Datastore)と、TM_MAD(Transfer Manager Driver)の動作を理解します。
この検証により、以下を確認します。
- IMAGE DatastoreとSYSTEM Datastoreの役割と違い
- TM_MADによるディスク転送方法の違い
- 共有ストレージDatastoreの追加方法
4.4.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章完了)
- 共有ストレージ(
/mnt/shared-iscsi1)が全ノードでマウント済みであること(4.2章完了)
4.4.3. 手順
4.4.3.1. IMAGE DatastoreとSYSTEM Datastoreの理解
OpenNebulaのストレージ管理は、2階層構造になっています。
IMAGE Datastore:
- VMのテンプレートイメージ(ディスクイメージ)を保存する場所
- Marketplaceからダウンロードしたイメージもここに保存
- VMインスタンス化時の「元ネタ」として機能
SYSTEM Datastore:
- 実際にVMが稼働する際のディスクが配置される場所
- VMインスタンス化時に、IMAGE DatastoreからSYSTEM Datastoreへディスクがコピー/リンクされる
- VMの実行中のディスクI/Oは、SYSTEM Datastoreに対して行われる
4.4.3.2. TM_MAD(Transfer Manager Driver)の理解
TM_MADは、IMAGE DatastoreからSYSTEM Datastoreへのディスク転送方法を制御します。
主な種類:
| TM_MAD | 説明 | 共有ストレージ | Non-Persistent動作 | Persistent動作 |
|---|---|---|---|---|
| qcow2 | QCOW2形式のバッキングファイルを使用 | 必須 | バッキングファイル作成 | シンボリックリンク |
| shared | Rawイメージのコピー/リンク | 必須 | 完全コピー | シンボリックリンク |
| ssh | SSH経由でローカルディスクにコピー | 不要 | 完全コピー | 完全コピー |
4.4.3.3. Non-Persistent ImageとPersistent Imageの理解
Non-Persistent Image(デフォルト):
- VMインスタンス化時に、元のイメージは変更されない
- VM削除時に、SYSTEM Datastore上のディスクも削除される
- Proxmox VEの「Linked Clone」に相当
Persistent Image:
- VMインスタンス化時に、イメージ自体が使用される
- VM削除後も、イメージの変更は保持される
- Proxmox VEの「Full Clone」に相当
4.4.3.4. 共有ストレージDatastoreの追加
OCFS2で構築した共有ストレージを、OpenNebulaのDatastoreとして登録します。
1. Datastoreテンプレートの作成
nebula-f1で実行:
shared-iscsi1-ds.tplファイルを作成します。
cat > shared-iscsi1-ds.tpl << 'EOF' NAME = "shared-iscsi1" TYPE = IMAGE_DS DS_MAD = fs TM_MAD = shared SHARED = YES EOF
Datastoreを作成します。
onedatastore create shared-iscsi1-ds.tpl
作成されたDatastore IDを確認します。
onedatastore list
例えば、ID 104が作成された場合、後述のシンボリックリンクのパス(/var/lib/one/datastores/104)と一致させます。
2.シンボリックリンクの作成(全ノードで実行)
まず、OpenNebulaサービスを停止します。
sudo systemctl stop opennebula opennebula-sunstone
共有ストレージへのシンボリックリンクを作成します。
sudo ln -s /mnt/shared-iscsi1 /var/lib/one/datastores/104
ここで、104は前述のDatastore IDです。
OpenNebulaサービスを起動します。
sudo systemctl start opennebula opennebula-sunstone
3. WebUIでの確認
Sunstone WebUIで、Infrastructure → Datastoresを確認します。
shared-iscsi1が750GB程度の容量で表示されていることを確認します。
4.4.4. 結果/考察
検証結果:
- OpenNebulaの2階層ストレージ構造(IMAGE/SYSTEM Datastore)を理解
- TM_MADによるディスク転送方法の違いを理解
- 共有ストレージDatastoreを正常に追加できることを確認
考察:
- OpenNebulaの2階層構造は、Proxmox VE等の1階層構造と比較して、柔軟なストレージ配置が可能
- TM_MADの選択により、パフォーマンスと機能(スナップショット対応等)のトレードオフを調整できる
- 共有ストレージDatastoreの追加により、Live Migrationやスナップショット機能の基盤が整う
4.5. スナップショット機能の検証
4.5.1. 目的
OpenNebulaのスナップショット機能(VMスナップショット/Diskスナップショット)の動作を検証します。特に、QCOW2形式の内部スナップショットと外部スナップショット(バッキングファイルチェーン)の違いを理解します。
この検証により、以下を確認します。
- TM_MADによるスナップショット対応状況の違い
- QCOW2 Datastoreの構築方法
- VMスナップショットとDiskスナップショットの違いと共存
- スナップショットの作成・復元・削除の動作
4.5.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- 共有ストレージ(
/mnt/shared-iscsi1)が全ノードでマウント済みであること(4.2章) - IMAGE/SYSTEM Datastoreの概念を理解していること(4.4章)
4.5.3. 手順
注記: 本節のすべての手順は、特に記載がない限り Frontend(nebula-f1) で実行します。
4.5.3.1. TM_MADとスナップショット対応状況
OpenNebulaのスナップショット機能は、使用するTM_MADによって対応状況が異なります。
| TM_MAD | VM Snapshot | Disk Snapshot |
|---|---|---|
| qcow2 | ✅ 対応 | ✅ 対応 |
| shared | ❌ 非対応 | ❌ 非対応 |
| ssh | ❌ 非対応 | ❌ 非対応 |
スナップショット機能を使用するには、TM_MAD=qcow2が必須です。
4.5.3.2. QCOW2 Datastoreの構築
1. IMAGE Datastoreの作成
Datastoreテンプレート(image-qcow2-ds.tpl)の作成:
cat > image-qcow2-ds.tpl << 'EOF' NAME = "image-qcow2" TYPE = IMAGE_DS DS_MAD = fs TM_MAD = qcow2 SHARED = YES EOF
Datastoreの作成:
onedatastore create image-qcow2-ds.tpl
作成されたDatastore ID(例: 108)を確認します。
onedatastore list
2. SYSTEM Datastoreの作成
Datastoreテンプレート(system-qcow2-ds.tpl)の作成:
cat > system-qcow2-ds.tpl << 'EOF' NAME = "system-qcow2" TYPE = SYSTEM_DS DS_MAD = - TM_MAD = qcow2 SHARED = YES EOF
Datastoreの作成:
onedatastore create system-qcow2-ds.tpl
作成されたDatastore ID(例: 109)を確認します。
3. 全ノードでシンボリックリンクを作成
sudo systemctl stop opennebula opennebula-sunstone sudo ln -s /mnt/shared-iscsi1 /var/lib/one/datastores/108 sudo ln -s /mnt/shared-iscsi1 /var/lib/one/datastores/109 sudo systemctl start opennebula opennebula-sunstone
4.5.3.3. イメージのクローンとVM作成
1. イメージのクローン
既存のイメージ(例: alpine)を、新しいimage-qcow2 Datastoreにクローンします。
Sunstone WebUIで、Storage → Imagesから対象イメージを選択し、Cloneを実行します。
- Target datastore:
image-qcow2
2. VMテンプレートの作成
クローンしたqcow2イメージを使用するVMテンプレートを作成します。
- Disk: クローンしたqcow2イメージを選択
- Network: 適切なネットワークを選択
3. VMのインスタンス化
作成したテンプレートからVMをインスタンス化します(例: VM ID 17)。
4. QCOW2フォーマットの確認
onevm show 17 | grep TM_MAD
TM_MAD_SYSTEM="qcow2"と表示されることを確認します。
VMのディスクファイルを確認します。
sudo qemu-img info /mnt/shared-iscsi1/17/disk.0
以下のような出力が得られます。
image: /mnt/shared-iscsi1/17/disk.0 file format: qcow2 virtual size: 256 MiB (268435456 bytes) disk size: 116 MiB backing file: /mnt/shared-iscsi1/a53aa337665a2f044a2bf7492401aa02
backing fileが存在することで、Copy-on-Write(差分管理)が機能しています。
4.5.3.4. VMスナップショットの作成
VMが実行中の状態で、スナップショットを作成します。
onevm snapshot-create 17 "first-snapshot"
スナップショットが作成されたことを確認します。
onevm show 17
SNAPSHOTセクションにスナップショット情報が表示されます。
SNAPSHOT ID : 0 NAME : first-snapshot TIME : 2025-01-15 10:30:00 SIZE : 115 MiB
VMスナップショットには、ディスク状態に加えて、メモリ状態(約115 MiB)も含まれます。
4.5.3.5. VMスナップショットの動作確認
1. ファイル構造の確認
ls -lh /mnt/shared-iscsi1/17/disk.0.snap/
スナップショットは、QCOW2ファイルの内部スナップショットとして保存されます。
sudo qemu-img info /mnt/shared-iscsi1/17/disk.0.snap/0
2. 複数のVMスナップショット作成
onevm snapshot-create 17 "second-snapshot" onevm snapshot-create 17 "third-snapshot"
スナップショットリストを確認します。
onevm show 17
全てのVMスナップショットが、単一のQCOW2ファイル内に保存されていることを確認できます。
3. VMスナップショットからの復元
VMが実行中でも復元可能です。
onevm snapshot-revert 17 0
これにより、VM内のファイルがfirst-snapshot作成時点の状態に戻ります。
4. VMスナップショットの削除
中間のスナップショット(例: ID 1)を削除します。
onevm snapshot-delete 17 1
削除後、QCOW2ファイルのサイズが減少します。
ls -lh /mnt/shared-iscsi1/17/disk.0.snap/0
スナップショット削除時には、QCOW2内部でスナップショットの統合(マージ)が行われます。
4.5.3.6. Diskスナップショットの作成
VMスナップショット(メモリ状態を含む)とは異なり、Diskスナップショットはディスク状態のみを保存します。
onevm disk-snapshot-create 17 0 "disk-snapshot-1"
Diskスナップショットの仕組み:
Diskスナップショットは、QCOW2の外部スナップショット(バッキングファイルチェーン)を使用します。
ファイル構造の確認:
ls -lh /mnt/shared-iscsi1/17/disk.0.snap/
新しい差分ファイル(例: 1)が作成されます。
sudo qemu-img info /mnt/shared-iscsi1/17/disk.0.snap/1
出力例:
image: /mnt/shared-iscsi1/17/disk.0.snap/1 file format: qcow2 virtual size: 256 MiB (268435456 bytes) disk size: 704 KiB backing file: /mnt/shared-iscsi1/17/disk.0.snap/0
新しい差分ファイルが作成され、元のファイルがbacking fileとなります。
disk.0シンボリックリンクは、最新の差分ファイルを指すように更新されます。
ls -l /mnt/shared-iscsi1/17/disk.0
lrwxrwxrwx 1 oneadmin oneadmin 45 Jan 15 11:00 /mnt/shared-iscsi1/17/disk.0 -> /mnt/shared-iscsi1/17/disk.0.snap/1
4.5.3.7. VMスナップショットとDiskスナップショットの共存
元のファイル(disk.0.snap/0)には、VMスナップショット(内部スナップショット)が保持されたままです。
sudo qemu-img info /mnt/shared-iscsi1/17/disk.0.snap/0
Snapshot list: ID TAG VM SIZE DATE VM CLOCK 0 first-snapshot 115 MiB 2025-01-15 10:30:00 00:00:05.123 2 second-snapshot 115 MiB 2025-01-15 10:35:00 00:00:10.456 3 third-snapshot 115 MiB 2025-01-15 10:40:00 00:00:15.789
外部スナップショット(Disk snapshot)と内部スナップショット(VM snapshot)は独立して共存できます。
4.5.4. 結果/考察
検証結果:
TM_MAD=qcow2でのみスナップショット機能が利用可能であることを確認- QCOW2 Datastoreを正常に構築できることを確認
- VMスナップショット(内部スナップショット)とDiskスナップショット(外部スナップショット)の違いを理解
- VMスナップショットとDiskスナップショットが独立して共存できることを確認
- スナップショットの作成・復元・削除が正常に動作することを確認
考察:
- VMスナップショット(メモリ状態含む)は、VM実行中でも復元可能であり、迅速なロールバックに有用
- Diskスナップショット(ディスク状態のみ)は、バッキングファイルチェーンを形成し、長期的なバックアップに適している
- 2種類のスナップショットは独立して管理され、用途に応じて使い分けることが可能
- スナップショット削除時のマージ処理により、ディスク容量を効率的に管理できる
4.6. Live Migrationの実現
4.6.1. 目的
OpenNebulaのLive Migration(ライブマイグレーション)機能を検証し、VMを停止せずに別のホストへ移動できることを確認します。特に、スナップショットが存在する状態でのLive Migrationの動作を検証します。
この検証により、以下を確認します。
- Live Migrationの前提条件と設定方法
dynamic_ownership設定の重要性- スナップショットありVMのLive Migration動作
- パケットロスの計測
4.6.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- 共有ストレージ(
/mnt/shared-iscsi1)が全ノードでマウント済みであること(4.2章) - 3台のCompute Node(
nebula-f1,nebula-n1,nebula-n2)が利用可能であること(4.3章) - QCOW2 Datastoreが構築済みであること(4.5章)
データストア構成:
本検証は、以下のデータストアを利用します。
- IMAGE Datastore:
image-qcow2(TM_MAD: qcow2、共有ストレージ) - SYSTEM Datastore:
system-qcow2(TM_MAD: qcow2、共有ストレージ)
4.6.3. 手順
4.6.3.1. Live Migrationの前提条件
- 共有ストレージ: 全ノードから同じストレージにアクセスできること
- ネットワーク接続: 各ノード間で十分な帯域幅があること
- 同一のハイパーバイザー: 全ノードで同じKVMバージョンが動作していること
- Libvirtの設定:
dynamic_ownershipの設定(後述)
4.6.3.2. dynamic_ownershipの問題と対処法
これは非常に重要な設定です。
OpenNebulaのLive Migrationを成功させるには、/etc/libvirt/qemu.confのdynamic_ownership設定を確認する必要があります。
1. 問題の確認(全ノードで実行)
sudo grep dynamic_ownership /etc/libvirt/qemu.conf
もしdynamic_ownership = 0となっている場合、Live Migration時にパーミッションエラーが発生します。
2. 対処方法(全ノードで実行)
/etc/libvirt/qemu.confを編集します。
sudo nano /etc/libvirt/qemu.conf
以下のように変更します。
# dynamic_ownership = 0 # コメントアウト dynamic_ownership = 1 # 1に設定(または行ごとコメントアウト)
Libvirtを再起動します。
sudo systemctl restart libvirtd
4.6.3.3. Live Migrationの検証
検証パターン1: QCOW2(スナップショットなし)
VMの作成とLive Migration:
# VMのインスタンス化 onevm create alpine-template --name "alpine-migrate-test" # VM IDの確認(例: 20) onevm list # 実行中のホストを確認 onevm show 20 | grep HOST
Live Migrationの実行:
onevm migrate --live 20 nebula-n1
パケットロスの確認:
VM内でpingを実行しながらLive Migrationを行います。
結果:
- パケットロス なし
検証パターン2: QCOW2(VMスナップショットあり)
VMスナップショットを作成:
onevm snapshot-create 20 "test-snapshot"
スナップショットにメモリ状態(約113 MiB)が含まれることを確認します。
onevm show 20
Live Migrationの実行:
onevm migrate --live 20 nebula-n2
結果:
- パケットロス なし
- VMスナップショットは完全に保持
- VM内の全てのデータも保持
検証パターン3: QCOW2(Diskスナップショットあり)
Diskスナップショットを作成:
onevm disk-snapshot-create 20 0 "disk-test-snapshot"
バッキングファイルチェーンが形成されたことを確認します。
sudo qemu-img info /mnt/shared-iscsi1/20/disk.0.snap/1
Live Migrationの実行:
onevm migrate --live 20 nebula-f1
結果:
- パケットロス なし
- バッキングファイルチェーンは全ノードで正常に機能
- スナップショット情報も完全に保持
検証パターン4: Shared TM_MAD
TM_MAD=sharedを使用したVMでも、Live Migrationの動作を確認しました。
結果:
- Live Migration成功
- ただし、スナップショット機能は使用不可
4.6.4. 結果/考察
検証結果:
| 構成 | Live Migration | VMスナップショット | Diskスナップショット |
|---|---|---|---|
| qcow2(スナップショットなし) | ✅ 成功 | - | - |
| qcow2(VMスナップショットあり) | ✅ 成功、データ保持 | ✅ 保持 | - |
| qcow2(Diskスナップショットあり) | ✅ 成功、チェーン保持 | - | ✅ 保持 |
| shared(スナップショットなし) | ✅ 成功 | ❌ 非対応 | ❌ 非対応 |
考察:
- 共有ストレージ +
dynamic_ownership = 1の設定により、OpenNebulaの全ての高度な機能が利用可能 - Live Migration中のパケットロスが発生せず、本検証環境においてVMを移動できることを確認
- スナップショット(内部/外部)が存在する状態でも、Live Migrationは正常に動作し、スナップショット情報も完全に保持される
dynamic_ownership設定は、Live Migration成功の鍵であり、必ず確認が必要
4.7. 追加ストレージの構築
4.7.1. 目的
ストレージの追加を措定し、2つ目のiSCSI LUNを追加し、新しいデータストアを構築します。複数の共有ストレージを構築することで、用途やパフォーマンス要件に応じてストレージを使い分けられることを確認します。
この検証により、以下を確認します。
- 2つ目のiSCSI LUNの追加方法
- 複数の共有ストレージの同時運用
- 新しいDatastoreの追加方法
4.7.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- 1つ目の共有ストレージ(
/mnt/shared-iscsi1)が全ノードでマウント済みであること(4.2章) - TrueNAS Scale環境で、2つ目のiSCSI LUNが作成済みであること
4.7.3. 手順
4.7.3.1. 2つ目のiSCSI LUNの追加
TrueNAS側の設定:
- iSCSI Target:
iqn.2005-10.org.freenas.ctl:block2 - iSCSI LUN: 750GB(Zvol)
全ノードでのiSCSI設定:
# Targetの検出 sudo iscsiadm -m discovery -t st -p 192.168.11.4:3260 # ログイン sudo iscsiadm -m node --targetname iqn.2005-10.org.freenas.ctl:block2 --portal 192.168.11.4:3260 --login # 自動ログインの有効化 sudo iscsiadm -m node --targetname iqn.2005-10.org.freenas.ctl:block2 --portal 192.168.11.4:3260 --op update -n node.startup -v automatic
デバイスの確認:
lsblk
新しいディスク(例: /dev/sdc)が認識されていることを確認します。
Multipathの設定:
/etc/multipath.confに以下を追加します。
multipaths {
multipath {
wwid 33191e2b04c21abe0000000000000001
alias mpathc
}
}
Multipathサービスを再起動します。
sudo systemctl restart multipathd sudo multipath -ll
/dev/mapper/mpathcが作成されていることを確認します。
4.7.3.2. OCFS2ファイルシステムの作成
nebula-f1で実行:
sudo mkfs.ocfs2 -L "ocfs2-shared2" -N 3 /dev/mapper/mpathc
4.7.3.3. マウント設定
全ノードで実行:
sudo mkdir -p /mnt/shared-iscsi2 sudo mount -t ocfs2 /dev/mapper/mpathc /mnt/shared-iscsi2 sudo chown oneadmin:oneadmin /mnt/shared-iscsi2 sudo chmod 755 /mnt/shared-iscsi2
自動マウントの設定:
/etc/fstabに以下を追加します。
/dev/mapper/mpathc /mnt/shared-iscsi2 ocfs2 _netdev,defaults 0 0
4.7.3.4. OpenNebula Datastoreの追加
SYSTEM Datastoreの作成:
cat > system-qcow2-iscsi2-ds.tpl << 'EOF' NAME = "system-qcow2-iscsi2" TYPE = SYSTEM_DS DS_MAD = - TM_MAD = qcow2 SHARED = YES PERSISTENT_SNAPSHOTS = "YES" EOF onedatastore create system-qcow2-iscsi2-ds.tpl
作成されたDatastore ID(例: 111)を確認します。
IMAGE Datastoreの作成:
cat > image-qcow2-iscsi2-ds.tpl << 'EOF' NAME = "image-qcow2-iscsi2" TYPE = IMAGE_DS DS_MAD = fs TM_MAD = qcow2 SHARED = YES EOF onedatastore create image-qcow2-iscsi2-ds.tpl
作成されたDatastore ID(例: 112)を確認します。
全ノードでシンボリックリンクを作成:
sudo systemctl stop opennebula opennebula-sunstone sudo ln -s /mnt/shared-iscsi2 /var/lib/one/datastores/111 sudo ln -s /mnt/shared-iscsi2 /var/lib/one/datastores/112 sudo systemctl start opennebula opennebula-sunstone
4.7.4. 結果/考察
検証結果:
- 2つ目のiSCSI LUNを正常に追加できることを確認
- 複数の共有ストレージ(
/mnt/shared-iscsi1,/mnt/shared-iscsi2)を同時に運用できることを確認 - 新しいDatastore(IMAGE/SYSTEM)を正常に追加できることを確認
考察:
- OpenNebulaは、複数の共有ストレージを同時に利用可能
- 用途やパフォーマンス要件に応じて、異なるストレージを使い分けることが可能
4.8. Persistent Image検証
4.8.1. 目的
OpenNebulaのストレージ管理(2階層構造、TM_MAD、Persistent Image等)を、Proxmox VEと比較しながら理解します。特に、Persistent ImageとSymbolic Linkを活用したディスク容量最適化の仕組みを検証します。
この検証により、以下を確認します。
- OpenNebulaとProxmox VEのストレージ概念の違い
- TM_MADによるクローン処理の違い
- CLONE_TARGETとLN_TARGETパラメータの動作
- Persistent ImageとSymbolic Linkによるディスク容量最適化
- Persistent Imageのスナップショット機能
4.8.2. 前提条件
- OpenNebulaが正常にインストールされていること(3章)
- 共有ストレージ(
/mnt/shared-iscsi1,/mnt/shared-iscsi2)が全ノードでマウント済みであること(4.2章、4.7章) - QCOW2 Datastoreが構築済みであること(4.5章)
- IMAGE/SYSTEM Datastoreの概念を理解していること(4.4章)
データストア構成:
本検証は、以下のデータストアを利用します。
- IMAGE Datastore:
image-qcow2(TM_MAD: qcow2、共有ストレージ) - SYSTEM Datastore:
system(TM_MAD: ssh、ローカルディスク)
4.8.3. 手順
注記: 本節のすべての手順は、特に記載がない限り Frontend(nebula-f1) で実行します。
4.8.3.1. デフォルトのクローン動作の違い
| 仮想化基盤 | デフォルト動作 | 特徴 |
|---|---|---|
| Proxmox VE | Full Clone(完全複製) | ディスク使用量は増加するが、独立性が高い |
| OpenNebula | Non-Persistent Image(バッキングファイル) | ディスク使用量は最小限、効率的 |
4.8.3.2. OpenNebulaの2階層ストレージ構造
OpenNebulaは、IMAGE DatastoreとSYSTEM Datastoreを分離することで、柔軟なストレージ構成を実現します。
例: 高速SAN + ローカルSSD構成
- IMAGE Datastore: 高速SAN(共有ストレージ)にVMテンプレートを保存
- SYSTEM Datastore: ローカルSSD(各ノード)でVMを実行
この構成により、テンプレートは全ノードで共有しつつ、VM実行時のI/Oパフォーマンスを最大化できます。
4.8.3.3. TM_MADとクローン処理
| TM_MAD | Non-Persistent Image | Persistent Image |
|---|---|---|
| qcow2 | バッキングファイル参照 (差分のみ記録) | シンボリックリンク |
| shared | 完全コピー (Rawフォーマット) | シンボリックリンク |
| ssh | ローカルディスクに完全コピー | ローカルディスクに完全コピー |
4.8.3.4. CLONE_TARGETとLN_TARGETパラメータ
CLONE_TARGET:
Non-Persistent Imageのクローン方法を制御します。
onedatastore show 108 | grep CLONE_TARGET
CLONE_TARGET="SYSTEM"
CLONE_TARGET="SYSTEM"の場合、SYSTEM DatastoreのTM_MADに従ってクローン処理が決定されます。
LN_TARGET:
Persistent Imageのリンク方法を制御します。
onedatastore show 0 | grep LN_TARGET
LN_TARGET="NONE"
LN_TARGET="NONE": シンボリックリンクを使用LN_TARGET="SELF": 完全コピー
4.8.3.5. Persistent ImageとSymbolic Linkによるディスク容量最適化
LN_TARGET設定の変更:
/etc/one/oned.confを編集します。
sudo nano /etc/one/oned.conf
ssh TM_MADセクションのLN_TARGETを"SYSTEM" から "NONE"に変更します。
TM_MAD_CONF = [
NAME = "ssh",
LN_TARGET = "NONE",
...
]
OpenNebulaを再起動します。
sudo systemctl restart opennebula
Persistent Imageの作成:
oneimage clone alpine-base alpine-persistent-test --persistent
作成されたイメージID(例: 12)を確認します。
oneimage list
VMのインスタンス化:
Persistent Imageを使用するVMテンプレートを作成し、VMをインスタンス化します(例: VM ID 33)。
ローカルディスク容量の確認:
du -sh /var/lib/one/datastores/0/
8.0K /var/lib/one/datastores/0/
VM専用ディレクトリが存在しないことを確認:
ls /var/lib/one/datastores/0/
ローカルディスクにVMディスクがコピーされていないことが確認できます。
Symbolic Linkの確認:
共有ストレージ上のVM作業ディレクトリ:
ls -lh /mnt/shared-iscsi1/33/
lrwxrwxrwx 1 oneadmin oneadmin 53 Jan 16 10:00 disk.0 -> /mnt/shared-iscsi1/a53aa337665a2f044a2bf7492401aa02
disk.0は、IMAGE Datastore上の実際のPersistent Imageファイルへのシンボリックリンクです。
VM内でのディスクI/O動作確認:
VMにログインし、ファイルの書き込み・読み込みを実行します。正常に動作することを確認できます。
Live Migration時の動作確認:
onevm migrate --live 33 nebula-n1
Live Migration後も、各ノードで以下を確認できます。
- ローカルディスク(
/var/lib/one/datastores/0/)は依然として未使用 - シンボリックリンク構造は維持
- VM動作は正常
この構成により、ローカルディスクを節約しつつ、Live Migrationも正常に機能します。
4.8.3.6. Persistent Imageのスナップショット機能
前提条件:
Persistent Imageでスナップショット機能を使用するには、以下の構成が必要です。
- IMAGE Datastore:
TM_MAD=qcow2、共有ストレージ - SYSTEM Datastore:
TM_MAD=qcow2、SHARED=YES、PERSISTENT_SNAPSHOTS="YES"
スナップショットの作成:
onevm disk-snapshot-create 33 0 "test-snapshot"
ファイル構造の確認:
ls -lh /mnt/shared-iscsi1/33/disk.0.snap/
-rw-r--r-- 1 oneadmin oneadmin 896K Jan 16 11:00 1
新しいqcow2差分ファイル(例: 1)が作成されます。
disk.0シンボリックリンクの確認:
ls -l /mnt/shared-iscsi1/33/disk.0
lrwxrwxrwx 1 oneadmin oneadmin 45 Jan 16 11:00 /mnt/shared-iscsi1/33/disk.0 -> /mnt/shared-iscsi1/33/disk.0.snap/1
disk.0は、最新の差分ファイルを参照するようになります。
バッキングファイルチェーンの確認:
sudo qemu-img info /mnt/shared-iscsi1/33/disk.0.snap/1
backing file: /mnt/shared-iscsi1/a53aa337665a2f044a2bf7492401aa02
元のPersistent Imageファイルがbacking fileとして参照されます。
SYSTEM Datastoreの役割:
SYSTEM Datastore(ID 109)は、TM_MAD=qcow2、PERSISTENT_SNAPSHOTS="YES"の設定により、Persistent Imageのスナップショット用差分ファイルを管理します。
onedatastore show 109
DATASTORE 109 INFORMATION ID : 109 NAME : system-qcow2 ... TYPE : SYSTEM_DS TM_MAD : qcow2 SHARED : YES PERSISTENT_SNAPSHOTS : YES
この設定により、Persistent Imageに対してもスナップショット機能が利用可能になります。
複数スナップショットとツリー構造:
onevm disk-snapshot-create 33 0 "test-snapshot-2" onevm disk-snapshot-create 33 0 "test-snapshot-3"
スナップショット一覧を確認します。
onevm show 33
DISK SNAPSHOT ID PARENT DATE SIZE NAME 0 -1 01/16 10:00 116M - 1 0 01/16 11:00 1.4M test-snapshot 2 1 01/16 11:05 640K test-snapshot-2 =>3 2 01/16 11:10 768K test-snapshot-3
=>マークは、現在アクティブなスナップショット(VM実行中のディスク)を示します。
Live Migration時の動作:
onevm migrate --live 33 nebula-n2
Live Migration後も、スナップショット情報とバッキングファイルチェーンは完全に保持されます。
差分ファイルのサイズは、VM実行中に増加します。
ls -lh /mnt/shared-iscsi1/33/disk.0.snap/
-rw-r--r-- 1 oneadmin oneadmin 896K Jan 16 11:00 1 -rw-r--r-- 1 oneadmin oneadmin 640K Jan 16 11:05 2 -rw-r--r-- 1 oneadmin oneadmin 768K Jan 16 11:10 3
スナップショット削除時の動作:
アクティブなスナップショット(例: ID 3)を削除します。
onevm disk-snapshot-delete 33 0 3
削除後、その親スナップショット(ID 2)が自動的にアクティブになります。
onevm show 33
DISK SNAPSHOT ID PARENT DATE SIZE NAME 0 -1 01/16 10:00 116M - 1 0 01/16 11:00 1.4M test-snapshot =>2 1 01/16 11:05 640K test-snapshot-2
ルートスナップショット(ID 0)の削除保護:
ルートスナップショットを削除しようとすると、以下のエラーが表示されます。
onevm disk-snapshot-delete 33 0 0
[one.vm.disk_snapshot_delete] Error: Cannot delete snapshot 0 for persistent disk images
この保護機構により、Persistent Imageの元データが誤って削除されることを防ぎます。
4.8.4. 結果/考察
検証結果:
- OpenNebulaの2階層ストレージ構造は、Proxmox VEの1階層構造と比較して、柔軟なストレージ配置が可能
- TM_MADの選択により、クローン処理の動作が大きく異なる
- TM_MADがsshの場合、
LN_TARGET="NONE"設定により、Persistent Imageの場合Symbolic Linkを使用し、ローカルディスク容量を節約可能 PERSISTENT_SNAPSHOTS="YES"設定により、Persistent Imageに対してもスナップショット機能が利用可能- スナップショットツリー構造により、複数世代のスナップショットを管理可能
- ルートスナップショットの削除保護により、データ損失リスクを軽減
考察:
- OpenNebulaのストレージ管理は、Proxmox VEと比較して複雑だが、その分柔軟性が高い
- Persistent ImageとSymbolic Linkの組み合わせにより、ディスク容量を効率的に管理しつつ、Live Migrationも実現可能
PERSISTENT_SNAPSHOTS設定は、Persistent Imageのスナップショット機能を実現する鍵- スナップショットの削除保護機構により、運用時の誤操作リスクを軽減できる
5. まとめ
本記事では、OpenNebula 7.0を実際に構築し、以下の項目を検証いたしました。
5.1. 検証した主要項目
- 基本環境の構築: OneDeploy(Ansible)による自動インストール
- VM作成の基礎: ISOイメージからの任意OSインストール
- 共有ストレージの構築: iSCSI + OCFS2によるクラスタファイルシステム
- FrontendへのCompute Node機能の追加:
--limitオプションによる柔軟なノード追加 - ストレージ管理: IMAGE/SYSTEM Datastoreの2階層構造とTM_MAD
- スナップショット機能: QCOW2による内部/外部スナップショット
- Live Migration: 共有ストレージ環境でのシームレスな移行
- 追加ストレージの構築: 複数の共有ストレージの同時運用
- ディスク容量最適化: Persistent ImageとSymbolic Linkの活用
5.2. 今後の展開
OpenNebulaは、以下のような用途で有効活用できると考えられます。
- プライベートクラウド基盤:VM統合管理
- 開発/テスト環境: 効率的なリソース共有とスナップショット活用
- マルチテナント環境: ユーザー/グループ単位でのリソース分離
- ハイブリッドクラウド: パブリッククラウドとの統合管理
本記事が、OpenNebulaの導入および運用の参考になれば幸いです。
6. 参考資料
- OpenNebula Documentation
- OneDeploy Tutorial: Local Datastore
- Storage System Overview
- Ubuntu Server 24.04 LTS
- TrueNAS Scale Documentation
7. 商標について
本記事で使用している以下の名称は、各社の商標または登録商標です。
- VMware、VMware vSphere、ESXiは、VMware, Inc.の米国およびその他の地域における登録商標または商標です。
- Proxmox VEは、Proxmox Server Solutions GmbHの商標です。
- Ubuntu、Ubuntu Serverは、Canonical Ltd.の商標です。
- TrueNAS、TrueNAS Scaleは、iXsystems, Inc.の商標です。
- その他、本記事中に記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。
8. 免責事項
8.1. セキュリティに関する注意事項
本記事で紹介している構成は、検証環境を想定しています。本番環境で使用する場合は、以下の点にご注意ください。
- ファイアウォール設定: 適切なファイアウォールルールを設定し、不要なポートを閉じてください
- 認証情報の管理:
oneadminパスワード、データベースパスワード等は、強固なパスワードに変更してください - SSH鍵認証: パスフレーズ付きのSSH鍵を使用することを推奨します
- ネットワーク分離: 管理ネットワークとVMネットワークを分離することを推奨します
- 定期的なアップデート: OpenNebula、OS、ハイパーバイザーのセキュリティアップデートを定期的に適用してください
- その他: 要件により適切なセキュリティ対策を講じてください
8.2. データ損失に関する注意事項
- バックアップの実施: 重要なVMやデータは、定期的にバックアップを取得してください
- スナップショット削除: スナップショットの削除は、データ損失リスクを伴うため、慎重に実施してください
- ストレージ障害: 共有ストレージの障害は、全VMに影響を与える可能性があるため、冗長化を検討してください
- 検証環境での事前テスト: 本番環境での作業前に、必ず検証環境でテストを実施してください
8.3. 一般的な免責事項
本記事の内容は、2025年12月時点の情報に基づいており、将来的に変更される可能性があります。本記事の内容を実施したことにより発生したいかなる損害についても、筆者および所属組織は一切の責任を負いかねます。ご了承ください。
8.4. 執筆者
平岡 征一朗（NTT西日本 エンタープライズビジネス営業部 社会基盤営業部門 文教営業担当（福岡））
文教（大学）担当のシステムエンジニアです。インフラからアプリまでトラブルシュートが大好きです。
