Skip to content
Published on

OpenStack & KVM仮想化完全ガイド2025:プライベートクラウド構築から運用まで

Authors

目次

1. 仮想化の基礎:なぜ仮想化なのか?

1.1 仮想化の定義と歴史

仮想化(Virtualization)とは、物理的なハードウェア上に複数の隔離された仮想環境を作成する技術である。1960年代のIBMメインフレームで始まったこの技術は、2000年代のx86仮想化の普及とともに、現代のクラウドコンピューティングの中核基盤となった。

仮想化が必要な理由:

  • サーバー統合: 物理サーバーの利用率を10-15%から60-80%に向上
  • コスト削減: ハードウェア購入、電力、冷却、スペースコストを大幅に削減
  • 俊敏性: 数分で新しいサーバーをプロビジョニング(物理サーバーは数週間)
  • 隔離: ワークロード間のセキュリティ隔離、障害隔離
  • 災害復旧: スナップショット、ライブマイグレーションで迅速な復旧

1.2 Type-1 vs Type-2 ハイパーバイザー

ハイパーバイザーは、仮想マシンを作成・管理するソフトウェア層である。

Type-1(ベアメタル)ハイパーバイザー:

ハードウェア上に直接インストールされる。ホストOSが不要でオーバーヘッドが少なく、性能が優れている。

  • KVM: Linuxカーネルモジュールとして動作。Linux自体がハイパーバイザーの役割を果たす
  • VMware ESXi: エンタープライズ標準。vSphereエコシステム
  • Xen: AWS EC2の初期基盤。Citrixが管理
  • Microsoft Hyper-V: Windows Serverに内蔵

Type-2(ホスト型)ハイパーバイザー:

既存のOS上にアプリケーションとしてインストールされる。開発・テスト環境に適している。

  • VirtualBox: Oracleのオープンソースソリューション。クロスプラットフォーム
  • VMware Workstation/Fusion: デスクトップ仮想化
  • Parallels Desktop: macOS専用

1.3 仮想化方式の比較

+--------------------------------------------------+
|        仮想化方式の比較                              |
+--------------------------------------------------+
| 完全仮想化 (Full Virtualization)                    |
|   - ゲストOS修正なしで実行                            |
|   - Binary Translationで特権命令を処理                |
|   - 性能オーバーヘッドあり                             |
+--------------------------------------------------+
| 準仮想化 (Para-virtualization)                      |
|   - ゲストOSカーネルの修正が必要 (Hypercall)           |
|   - Xenが代表的                                     |
|   - 性能は優秀だが互換性に制限                          |
+--------------------------------------------------+
| ハードウェア支援仮想化 (HW-assisted)                   |
|   - Intel VT-x / AMD-V                            |
|   - ゲストOS修正不要 + 高性能                          |
|   - KVMがこの方式を活用                               |
+--------------------------------------------------+

1.4 ハイパーバイザー比較表

項目KVMVMware ESXiXenHyper-V
タイプType-1Type-1Type-1Type-1
ライセンスオープンソース (GPL)商用 (無料版あり)オープンソース (GPL)Windows付属
ホストOSLinux独立カーネル独立カーネルWindows Server
性能優秀優秀優秀良好
GPUパススルー対応 (VFIO)対応 (vGPU)限定的対応 (DDA)
ライブマイグレーション対応vMotion対応Live Migration
管理ツールlibvirt, OpenStackvCenterXenCenterSCVMM
エコシステム広大 (Linux)最大のエンタープライズ縮小中Windowsエコシステム

1.5 コンテナ vs 仮想マシン

  仮想マシン (VM)                  コンテナ (Container)
+------------------+           +------------------+
|   App A | App B  |           | App A  |  App B  |
+------------------+           +------------------+
| Guest  | Guest   |           | Bins/  | Bins/   |
|  OS    |  OS     |           | Libs   | Libs    |
+------------------+           +------------------+
|   Hypervisor     |           | Container Engine  |
+------------------+           +------------------+
|   Host OS        |           |   Host OS         |
+------------------+           +------------------+
|   Hardware       |           |   Hardware        |
+------------------+           +------------------+
項目仮想マシンコンテナ
隔離レベル強い(ハードウェアレベル)弱い(カーネル共有)
起動時間数十秒〜数分ミリ秒〜秒
リソースオーバーヘッド高い(各VMにフルOS)低い(カーネル共有)
イメージサイズGB単位MB単位
密度10-50 VM/サーバー100-1000コンテナ/サーバー
セキュリティ強力な隔離gVisor、Kataで強化可能
ユースケース異種OS、レガシーアプリ、高隔離マイクロサービス、CI/CD、スケールアウト

VMを選択すべき場面:

  • 異なるOSの実行が必要な場合(Windows + Linux)
  • 強力なセキュリティ隔離が必須な場合(マルチテナント)
  • レガシーアプリケーションの運用
  • カーネルレベルのカスタマイズが必要な場合

コンテナを選択すべき場面:

  • 同一OS上で多数のインスタンスを実行
  • 高速なスケーリングが必要
  • CI/CDパイプライン
  • マイクロサービスアーキテクチャ

2. KVM/QEMU 詳細分析

2.1 KVMアーキテクチャ

KVM(Kernel-based Virtual Machine)は、Linuxカーネル2.6.20から含まれているハイパーバイザーモジュールである。Linux自体をType-1ハイパーバイザーに変換する。

+--------------------------------------------------+
|          ゲストVM(各VMはLinuxプロセス)               |
|  +-----------+  +-----------+  +-----------+      |
|  | Guest OS  |  | Guest OS  |  | Guest OS  |      |
|  +-----------+  +-----------+  +-----------+      |
|  |   QEMU    |  |   QEMU    |  |   QEMU    |      |
|  | (userspace)|  | (userspace)|  | (userspace)|    |
+--------------------------------------------------+
|              Linux Kernel                         |
|  +------+  +-------+  +--------+  +---------+    |
|  | KVM  |  | sched |  | memory |  | network |    |
|  |module |  |       |  | mgmt   |  | stack   |    |
|  +------+  +-------+  +--------+  +---------+    |
+--------------------------------------------------+
|              Hardware                             |
|  +----------+  +-------+  +--------+             |
|  | CPU      |  | RAM   |  | NIC    |             |
|  | VT-x/SVM |  |       |  |        |             |
|  +----------+  +-------+  +--------+             |
+--------------------------------------------------+

動作原理:

  1. KVMカーネルモジュール(kvm.kokvm-intel.koまたはkvm-amd.ko)がCPUのハードウェア仮想化拡張(VT-x/AMD-V)を活用
  2. 各VMは通常のLinuxプロセスとして実行(QEMUプロセス)
  3. vCPUはLinuxスレッドとしてスケジューリング
  4. QEMUがデバイスエミュレーション(ディスク、ネットワーク、USBなど)を担当
# KVMサポート確認
grep -E '(vmx|svm)' /proc/cpuinfo

# KVMモジュールのロード
sudo modprobe kvm
sudo modprobe kvm_intel  # Intel CPU
# sudo modprobe kvm_amd  # AMD CPU

# KVMデバイス確認
ls -la /dev/kvm

2.2 vCPUピンニングとNUMAトポロジー

NUMA(Non-Uniform Memory Access)アーキテクチャでは、CPUとメモリの物理的な配置が性能に大きく影響する。

# NUMAトポロジー確認
numactl --hardware

# lstopoで可視化
lstopo --of png > topology.png

vCPUピンニング設定(libvirt XML):

<vcpu placement='static'>8</vcpu>
<cputune>
  <vcpupin vcpu='0' cpuset='0'/>
  <vcpupin vcpu='1' cpuset='1'/>
  <vcpupin vcpu='2' cpuset='2'/>
  <vcpupin vcpu='3' cpuset='3'/>
  <vcpupin vcpu='4' cpuset='4'/>
  <vcpupin vcpu='5' cpuset='5'/>
  <vcpupin vcpu='6' cpuset='6'/>
  <vcpupin vcpu='7' cpuset='7'/>
  <emulatorpin cpuset='16-17'/>
</cputune>
<numatune>
  <memory mode='strict' nodeset='0'/>
</numatune>

2.3 virtio:準仮想化I/O

virtioは、ゲストとホスト間の高性能I/Oのための標準インターフェースである。

virtioデバイス用途置き換え対象
virtio-netネットワークe1000, rtl8139
virtio-blkブロックストレージIDE, SATA
virtio-scsiSCSIストレージLSI Logic
virtio-balloonメモリ調整-
virtio-rng乱数生成-
virtio-gpuグラフィックQXL, VGA
virtio-fsホストファイル共有9p
# QEMUでvirtioを使用
qemu-system-x86_64 \
  -drive file=disk.qcow2,if=virtio \
  -netdev tap,id=net0,ifname=tap0,script=no \
  -device virtio-net-pci,netdev=net0 \
  -m 4G \
  -smp 4 \
  -enable-kvm

2.4 メモリ管理

バルーンドライバー:

ゲスト内部でメモリを動的に拡張・縮小し、ホストがメモリを回収できるようにする。

KSM(Kernel Same-page Merging):

同一のメモリページを持つVM間でページを共有し、メモリを節約する。

# KSM有効化
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 20 > /sys/kernel/mm/ksm/sleep_millisecs

Hugepages:

デフォルトの4KBページの代わりに2MBまたは1GBの大きなページを使用し、TLBミスを削減する。

# Hugepages設定
echo 4096 > /proc/sys/vm/nr_hugepages  # 4096 x 2MB = 8GB
<!-- libvirt XMLでHugepages設定 -->
<memoryBacking>
  <hugepages>
    <page size='1' unit='GiB'/>
  </hugepages>
</memoryBacking>

2.5 SR-IOVとGPUパススルー

SR-IOV(Single Root I/O Virtualization):

物理NICを複数の仮想機能(VF)に分割し、VMに直接割り当てる。

# SR-IOV VF作成
echo 4 > /sys/class/net/enp3s0f0/device/sriov_numvfs

# VF一覧確認
lspci | grep "Virtual Function"

GPUパススルー(VFIO):

# IOMMU有効化(GRUB)
# Intel: intel_iommu=on iommu=pt
# AMD: amd_iommu=on iommu=pt

# GPUをvfio-pciにバインド
echo "10de 2204" > /sys/bus/pci/drivers/vfio-pci/new_id

2.6 ライブマイグレーション

実行中のVMをダウンタイムなしで別のホストに移動する。

Pre-copyマイグレーションフロー:
1. メモリ全体を宛先ホストに転送
2. 変更されたダーティページを繰り返し転送
3. ダーティページが十分減少したらVM一時停止
4. 残りのダーティページを転送
5. 宛先ホストでVM再開
# virshライブマイグレーション
virsh migrate --live --persistent --undefinesource \
  myvm qemu+ssh://dest-host/system

# マイグレーション速度制限(MB/s)
virsh migrate-setspeed myvm 100

# マイグレーション状態確認
virsh domjobinfo myvm

3. libvirt管理

3.1 libvirtアーキテクチャ

libvirtは、様々なハイパーバイザーを統合管理するAPI/デーモンである。

+--------------------------------------------------+
|  管理ツール                                         |
|  +--------+ +----------+ +---------+ +--------+  |
|  | virsh  | |virt-      | |OpenStack| |oVirt   |  |
|  |        | |manager   | |Nova     | |        |  |
|  +--------+ +----------+ +---------+ +--------+  |
+--------------------------------------------------+
|  libvirt API (C, Python, Go, Javaバインディング)      |
+--------------------------------------------------+
|  libvirtdデーモン                                    |
+--------------------------------------------------+
|  ドライバー                                          |
|  +-----+ +------+ +------+ +-------+ +--------+  |
|  | KVM | | Xen  | | LXC  | | VBox  | | VMware |  |
|  +-----+ +------+ +------+ +-------+ +--------+  |
+--------------------------------------------------+

3.2 virsh基本コマンド

# VMライフサイクル管理
virsh list --all                    # 全VM一覧
virsh start myvm                    # VM起動
virsh shutdown myvm                 # ゲストOS正常停止
virsh destroy myvm                  # 強制停止(電源断)
virsh reboot myvm                   # 再起動
virsh suspend myvm                  # 一時停止(メモリ状態保持)
virsh resume myvm                   # 再開

# VM作成/削除
virsh define vm.xml                 # XMLでVM定義
virsh undefine myvm                 # VM定義削除
virsh undefine myvm --remove-all-storage  # ストレージも削除

# スナップショット管理
virsh snapshot-create-as myvm snap1 "First snapshot"
virsh snapshot-list myvm
virsh snapshot-revert myvm snap1
virsh snapshot-delete myvm snap1

# リソース調整
virsh setvcpus myvm 4 --live        # vCPUホットアド
virsh setmem myvm 8G --live         # メモリ調整

# コンソール/ディスプレイ接続
virsh console myvm                  # シリアルコンソール
virsh vncdisplay myvm               # VNCポート確認

3.3 XMLドメイン設定

<domain type='kvm'>
  <name>web-server-01</name>
  <memory unit='GiB'>8</memory>
  <currentMemory unit='GiB'>8</currentMemory>
  <vcpu placement='static'>4</vcpu>

  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
    <boot dev='hd'/>
  </os>

  <features>
    <acpi/>
    <apic/>
  </features>

  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='4' threads='1'/>
  </cpu>

  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>

    <!-- virtioディスク -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>
      <source file='/var/lib/libvirt/images/web-server-01.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <!-- virtioネットワーク -->
    <interface type='bridge'>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>

    <!-- VNCディスプレイ -->
    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/>

    <!-- シリアルコンソール -->
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
  </devices>
</domain>

3.4 ストレージプール

# ディレクトリベースのストレージプール
virsh pool-define-as default dir --target /var/lib/libvirt/images
virsh pool-build default
virsh pool-start default
virsh pool-autostart default

# LVMストレージプール
virsh pool-define-as lvm-pool logical \
  --source-name vg_vms --target /dev/vg_vms

# Ceph RBDストレージプール
virsh pool-define-as ceph-pool rbd \
  --source-host mon1.example.com \
  --source-name libvirt-pool \
  --auth-type ceph --auth-username libvirt

# ボリューム管理
virsh vol-create-as default myvm.qcow2 50G --format qcow2
virsh vol-list default
virsh vol-delete myvm.qcow2 default

4. OpenStackアーキテクチャ(全体像)

4.1 OpenStack概要

OpenStackは、データセンターのコンピュート、ストレージ、ネットワークリソースをプールとして管理し、ユーザーにセルフサービスAPIで提供するクラウドOSである。

+------------------------------------------------------------+
|                    Horizon (Dashboard)                       |
+------------------------------------------------------------+
|                    OpenStack API Layer                       |
+------+-------+--------+--------+-------+--------+----------+
| Key- | Nova  |Neutron | Cinder | Glance| Swift  | Heat     |
|stone | Comp- | Net-   | Block  | Image | Object | Orches-  |
| Auth | ute   | work   | Store  |       | Store  | tration  |
+------+-------+--------+--------+-------+--------+----------+
|  RabbitMQ (Message Queue)  |  MariaDB/Galera (Database)    |
+------------------------------------------------------------+
|               Hypervisor (KVM/QEMU)                         |
+------------------------------------------------------------+
|               Physical Infrastructure                       |
+------------------------------------------------------------+

4.2 コアサービス詳細

Keystone(認証/認可):

機能:
- トークンベース認証(Fernet, JWT- RBAC(ロールベースアクセス制御)
- マルチテナンシー(Project/Domain隔離)
- LDAP/AD連携、SAML/OIDCフェデレーション
- サービスカタログ(エンドポイントレジストリ)
# Keystoneトークン発行
openstack token issue

# プロジェクト/ユーザー管理
openstack project create --domain default myproject
openstack user create --domain default --password-prompt myuser
openstack role add --project myproject --user myuser member

Nova(コンピュート):

Nova内部構成:
- nova-api: REST APIエンドポイント
- nova-scheduler: VM配置アルゴリズム(FilterScheduler)
- nova-conductor: DBアクセスプロキシ(セキュリティ)
- nova-compute: ハイパーバイザードライバー(libvirt)
- Placement: リソース追跡サービス
# インスタンス作成
openstack server create \
  --flavor m1.large \
  --image ubuntu-22.04 \
  --network internal-net \
  --security-group default \
  --key-name mykey \
  web-server-01

# フレーバー管理
openstack flavor create --vcpus 4 --ram 8192 --disk 80 m1.large

# インスタンス管理
openstack server list
openstack server show web-server-01
openstack server resize web-server-01 m1.xlarge

Neutron(ネットワーキング):

# ネットワーク作成
openstack network create internal-net
openstack subnet create --network internal-net \
  --subnet-range 10.0.1.0/24 \
  --gateway 10.0.1.1 \
  --dns-nameserver 8.8.8.8 \
  internal-subnet

# ルーター作成
openstack router create main-router
openstack router set --external-gateway external-net main-router
openstack router add subnet main-router internal-subnet

# Floating IP割り当て
openstack floating ip create external-net
openstack server add floating ip web-server-01 203.0.113.10

# セキュリティグループ
openstack security group rule create --protocol tcp \
  --dst-port 80:80 --remote-ip 0.0.0.0/0 default
openstack security group rule create --protocol tcp \
  --dst-port 22:22 --remote-ip 10.0.0.0/8 default

Cinder(ブロックストレージ):

# ボリューム作成と接続
openstack volume create --size 100 data-vol
openstack server add volume web-server-01 data-vol

# スナップショット
openstack volume snapshot create --volume data-vol snap-before-upgrade

# ボリュームタイプ(バックエンド指定)
openstack volume type create --property volume_backend_name=ceph-ssd fast-ssd
openstack volume create --size 50 --type fast-ssd fast-data

4.3 追加サービス

サービスプロジェクト説明AWS対応
コンピュートNovaVM管理EC2
ネットワークNeutronSDNVPC
ブロックストレージCinderディスクEBS
オブジェクトストレージSwift分散ストレージS3
イメージGlanceVMイメージAMI
認証KeystoneIAMIAM
オーケストレーションHeatスタック管理CloudFormation
ダッシュボードHorizonWeb UIConsole
ベアメタルIronic物理サーバー-
DNSDesignateDNS管理Route 53
ロードバランサーOctaviaLBaaSELB
ファイルストレージManila共有ファイルシステムEFS
コンテナMagnumK8sクラスターEKS

5. OpenStackデプロイメント

5.1 デプロイ方式の比較

方式用途複雑度プロダクション
DevStack開発/テスト低い不可
Kolla-Ansibleプロダクション中程度推奨
TripleO大規模プロダクション高い可能
MicroStack (Snap)単一ノードテスト非常に低い不可
OpenStack-Ansibleプロダクション中程度可能

5.2 Kolla-Ansibleデプロイメント

# 1. 準備
pip install kolla-ansible

# 2. インベントリ設定
cp /usr/share/kolla-ansible/ansible/inventory/multinode .
# /etc/kolla/globals.yml
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "2024.2"

kolla_internal_vip_address: "10.0.0.100"
kolla_external_vip_address: "203.0.113.100"

network_interface: "eth0"
neutron_external_interface: "eth1"

enable_cinder: "yes"
enable_cinder_backend_ceph: "yes"
enable_heat: "yes"
enable_horizon: "yes"
# 3. パスワード生成
kolla-genpwd

# 4. ブートストラップ
kolla-ansible -i multinode bootstrap-servers

# 5. 事前検証
kolla-ansible -i multinode prechecks

# 6. デプロイ
kolla-ansible -i multinode deploy

# 7. 後処理
kolla-ansible -i multinode post-deploy

# 8. 確認
source /etc/kolla/admin-openrc.sh
openstack service list

5.3 ネットワークアーキテクチャ

+------------------------------------------------------------+
|  External Network (203.0.113.0/24)                          |
|                        |                                    |
|                  [External Router]                           |
|                        |                                    |
|  Management Network (10.0.0.0/24)                           |
|  +----------+  +----------+  +----------+                   |
|  |Controller|  |Controller|  |Controller|                   |
|  |   Node 1 |  |   Node 2 |  |   Node 3 |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Tunnel Network (10.0.1.0/24) - VXLAN                       |
|        |              |              |                       |
|  +----------+  +----------+  +----------+                   |
|  | Compute  |  | Compute  |  | Compute  |                   |
|  |  Node 1  |  |  Node 2  |  |  Node 3  |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Storage Network (10.0.2.0/24) - Ceph                       |
+------------------------------------------------------------+

6. ネットワーキング詳細分析

6.1 ProviderネットワークとSelf-serviceネットワーク

Providerネットワーク:

  • 管理者が作成、物理ネットワークに直接マッピング
  • VLANベース、外部ルーティング機器を使用
  • シンプルだが柔軟性不足

Self-service(テナント)ネットワーク:

  • テナントが自由に作成
  • VXLAN/GREトンネリングで隔離
  • Neutron L3エージェントがルーティング担当
  • Floating IPで外部アクセス

6.2 OVS vs OVN

Open vSwitch (OVS):
- ソフトウェア仮想スイッチ
- neutron-openvswitch-agentが管理
- 成熟して安定的
- 大規模では性能低下の可能性

OVN (Open Virtual Network):
- OVS上に構築されたSDNソリューション
- 分散型アーキテクチャ(中央エージェント不要)
- ネイティブL3/NAT/DHCP/ACLサポート
- 大規模環境で優れた性能
- OpenStack最新の推奨バックエンド

6.3 VXLANトンネリング

VXLAN (Virtual Extensible LAN):
- UDPポート4789L2フレームをL3ネットワークにカプセル化
- 24ビットVNIで最大約1,600万セグメント(VLAN4,096個)
- マルチテナント環境に最適

パケット構造:
+------+------+------+------+---------+------+------+
|Outer | Outer| Outer| VXLAN| Inner   |Inner |Inner |
|Ether | IP   | UDP  |Header| Ether   |  IP  |Payload|
+------+------+------+------+---------+------+------+

6.4 DVR(Distributed Virtual Router)

DVRはルーティングを各コンピュートノードに分散し、ネットワークノードのボトルネックを解消する。

DVRなし(集中型):
  VM -> Compute Node -> [Network Node: L3 Agent] -> External

DVR適用:
  VM -> Compute Node [Local L3 Agent] -> External
  (East-Westトラフィックもローカルで処理)

7. ストレージアーキテクチャ

7.1 ストレージタイプ

+------------------------------------------------------------+
|  エフェメラルストレージ                                        |
|  - VM削除時に一緒に削除                                       |
|  - ローカルディスク(高速だが非永続)                            |
+------------------------------------------------------------+
|  永続ブロックストレージ (Cinder)                               |
|  - VMと独立したライフサイクル                                   |
|  - 他のVMに再接続可能                                         |
|  - スナップショット、クローン、暗号化対応                         |
+------------------------------------------------------------+
|  オブジェクトストレージ (Swift)                                 |
|  - REST APIでアクセス                                        |
|  - VMイメージ、バックアップデータの保存                          |
+------------------------------------------------------------+
|  共有ファイルシステム (Manila)                                  |
|  - NFS/CIFS共有                                              |
|  - 複数VMが同時アクセス                                        |
+------------------------------------------------------------+

7.2 Ceph統合

CephはOpenStackと最も統合度の高い分散ストレージである。

Ceph + OpenStackマッピング:
- Ceph RBD  -> Cinder(ブロックストレージ)
- Ceph RBD  -> Nova(エフェメラルディスク、ライブマイグレーション)
- Ceph RBD  -> Glance(イメージ保存)
- Ceph RGW  -> Swift API互換(オブジェクトストレージ)
- CephFS    -> Manila(共有ファイルシステム)
# Cephプール作成(OpenStack用)
ceph osd pool create volumes 128
ceph osd pool create images 64
ceph osd pool create vms 128
ceph osd pool create backups 64

# Ceph認証キー作成
ceph auth get-or-create client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images'

7.3 ストレージティアリング

ティアメディア用途レイテンシ
Tier 0NVMe SSDデータベース、高性能VM0.1ms未満
Tier 1SATA SSD一般VM、Webサーバー0.5ms未満
Tier 2HDD (10K RPM)アーカイブ、バックアップ5ms未満
Tier 3Object (S3)コールドデータ数十ms

8. 性能最適化

8.1 CPU最適化

<!-- 高性能VM:CPUピンニング + Hugepages + NUMA -->
<domain type='kvm'>
  <vcpu placement='static'>16</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='5'/>
    <emulatorpin cpuset='0-1'/>
  </cputune>
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>
  <memoryBacking>
    <hugepages>
      <page size='1' unit='GiB'/>
    </hugepages>
  </memoryBacking>
  <cpu mode='host-passthrough'>
    <topology sockets='1' dies='1' cores='16' threads='1'/>
  </cpu>
</domain>

8.2 ネットワーク最適化

性能順(低い -> 高い):
1. virtio-net(ソフトウェア仮想化) - 約10Gbps
2. vhost-net(カーネルモードデータパス) - 約15Gbps
3. DPDK(ユーザースペースパケット処理) - 約40Gbps
4. SR-IOV(ハードウェアパススルー) - ネイティブに近い(約100Gbps)

8.3 ストレージI/O最適化

<!-- I/Oスレッド分離(libvirt) -->
<iothreads>4</iothreads>
<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' cache='none' io='native' iothread='1'/>
  <source file='/var/lib/libvirt/images/vm.qcow2'/>
  <target dev='vda' bus='virtio'/>
</disk>

8.4 オーバーコミット比率

リソースデフォルト推奨値(一般)推奨値(高性能)
CPU16:14:1〜8:11:1(ピンニング)
RAM1.5:11:1〜1.2:11:1(Hugepages)
Disk1.0:12:1(thin)1:1(thick)

9. OpenStack vs VMware vs Proxmox

項目OpenStackVMware vSphereProxmox VE
ライセンスオープンソース (Apache 2.0)商用(高額)オープンソース (AGPL) + 商用
ハイパーバイザーKVM(デフォルト)ESXiKVM + LXC
インストール難易度高い中程度非常に簡単
学習曲線非常に急緩やか
スケーラビリティ数千ノード数百ノード数十ノード
API/自動化強力なREST APIvSphere API, PowerCLIREST API, CLI
マルチテナンシー強力(Project/Domain)限定的(vCenter)基本的(Pool/Permission)
SDNNeutron (OVS/OVN)NSXLinux Bridge/OVS
ストレージCinder + Ceph/NFS/iSCSIvSAN, VMFSZFS, Ceph, LVM
HAPacemaker, HAProxyvSphere HA, FT内蔵HA
コンテナサポートMagnum (K8s)Tanzu内蔵LXC
TCO低い(運用人員必要)非常に高い非常に低い
最適規模大規模クラウドエンタープライズ中小規模

選択ガイド:

  • OpenStack: 大規模プライベート/パブリッククラウド、通信キャリア、研究機関
  • VMware: 既存のエンタープライズ環境、Windows中心、ベンダーサポート必須
  • Proxmox: 中小企業、ホームラボ、シンプルな仮想化、迅速な導入

10. プロダクションベストプラクティス

10.1 高可用性(HA)

コントロールプレーンHA- 最低3台のコントローラーノード
- HAProxy + Keepalived (VIP)
- Pacemaker/Corosync(クラスター管理)
- Galera Cluster(MariaDB同期レプリケーション)
- RabbitMQミラーリングキュー

データプレーンHA- Ceph(三重レプリケーション、ノード障害自動復旧)
- Neutron DVR(ネットワークノードSPOF除去)
- Novaインスタンス HA(Masakari)

10.2 モニタリング

# Prometheus + OpenStack Exporter設定
scrape_configs:
  - job_name: 'openstack'
    static_configs:
      - targets: ['openstack-exporter:9198']
  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph-mgr:9283']
  - job_name: 'libvirt'
    static_configs:
      - targets: ['compute1:9177', 'compute2:9177']

主要モニタリングメトリクス:

カテゴリメトリクス閾値
Novaアクティブインスタンス数容量の80%
Novaスケジューリング失敗率5%以上で警告
NeutronFloating IP使用率90%で警告
Cinderボリューム作成失敗率1%以上で警告
CephOSD状態downのOSD 1台以上で警告
Ceph使用率70%で警告、85%で危険
RabbitMQキュー長1000以上で警告
MariaDBレプリケーション遅延1秒以上で警告

10.3 バックアップ戦略

# OpenStackデータベースバックアップ
mysqldump --all-databases --single-transaction \
  --routines --triggers > openstack-db-backup.sql

# Cinderボリュームバックアップ(Ceph)
rbd snap create volumes/volume-UUID@backup-20260325
rbd export volumes/volume-UUID@backup-20260325 volume-backup.raw

# Glanceイメージバックアップ
openstack image save --file ubuntu-backup.qcow2 ubuntu-22.04

# Novaインスタンススナップショット
openstack server image create --name "web-server-backup" web-server-01

10.4 アップグレード戦略

ローリングアップグレード手順:
1. コントローラーノードを1台ずつアップグレード
   - サービス中断最小化
   - API下位互換性を活用
2. データベースマイグレーション実行
3. コンピュートノードを1台ずつアップグレード
   - VMライブマイグレーションで空ノードをアップグレード
4. Neutronエージェントアップグレード
5. 全サービス検証

11. クイズ

Q1. KVMはどのタイプのハイパーバイザーか?

正解:Type-1(ベアメタル)ハイパーバイザー

KVMはLinuxカーネルモジュールとして動作し、Linuxカーネル自体をハイパーバイザーに変換する。ハードウェア上で直接実行されるホストOS(Linux)に内蔵されているため、Type-1に分類される。Intel VT-x/AMD-Vハードウェア仮想化拡張を活用して高い性能を提供する。

Q2. OpenStackで仮想ネットワーク、サブネット、ルーターを管理するサービスは?

正解:Neutron

NeutronはOpenStackのネットワークサービス(Networking-as-a-Service)である。ML2プラグイン、OVS/OVNエージェント、L3エージェント、DHCPエージェントなどで構成され、仮想ネットワーク、サブネット、ルーター、セキュリティグループ、Floating IPなどを管理する。AWSのVPCに対応するサービスである。

Q3. VXLANトンネリングがVLANに比べて持つ主要な利点は?

正解:セグメント数の拡張(4,096から約1,600万へ)

VLANは12ビットのVLAN IDで最大4,096セグメントしかサポートしない。一方、VXLANは24ビットのVNI(Virtual Network Identifier)を使用して約1,600万のネットワークセグメントをサポートする。大規模マルチテナントクラウド環境で不可欠である。

Q4. KSM(Kernel Same-page Merging)の役割は?

正解:同一のメモリページを持つVM間でメモリを共有し、物理メモリ使用量を削減する

KSMはLinuxカーネル機能で、複数のVMが同一内容のメモリページを持っている場合、1つの物理ページに統合(Copy-on-Write)する。同じOSイメージを使用するVMが多いほど効果が大きい。

Q5. OpenStackプロダクションデプロイメントでKolla-Ansibleが推奨される理由は?

正解:コンテナ化されたサービスデプロイメントで管理の容易さ、再現性、アップグレードの利便性を提供

Kolla-Ansibleは各OpenStackサービスをDockerコンテナとしてパッケージングしてデプロイする。環境隔離(依存関係の競合防止)、迅速なロールバック、再現可能なデプロイメント、サービス別独立アップグレードが可能になる。Ansibleベースのため自動化と反復デプロイメントが容易で、プロダクションHA構成もデフォルトでサポートする。


12. 参考資料

  1. OpenStack公式ドキュメント - docs.openstack.org
  2. KVM公式サイト - linux-kvm.org
  3. libvirt公式ドキュメント - libvirt.org/docs.html
  4. QEMU公式ドキュメント - qemu.org/documentation
  5. Kolla-Ansibleドキュメント - docs.openstack.org/kolla-ansible/latest
  6. Ceph公式ドキュメント - docs.ceph.com
  7. Open vSwitchドキュメント - docs.openvswitch.org
  8. OVNアーキテクチャ - ovn.org
  9. Red Hat OpenStack Platform - access.redhat.com/documentation/en-us/red_hat_openstack_platform
  10. Proxmox VEドキュメント - pve.proxmox.com/wiki/Main_Page
  11. VMware vSphereドキュメント - docs.vmware.com
  12. OpenStack Foundation (OpenInfra) - openinfra.dev
  13. DPDKドキュメント - doc.dpdk.org
  14. SR-IOVガイド - kernel.org/doc/html/latest/PCI/sriov-howto.html