OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。
Red Hat OpenStack Platformのライフサイクルについて何度か取り上げていますが、今回は、OpenStack環境のマイグレーションを取り上げます。「新規にRHOSP環境を構築し、ワークロードをマイグレーションする」という考え方です。既存環境をアップグレードするin-placeアップグレードについては過去の記事とRed Hatのカスタマーポータルサイトに掲載されている公式ドキュメントを参照してください。
OS-Migrate
OS-MigrateはふたつのOpenStackクラウド間でリソースとワークロードをエクスポートおよびインポートするためのフレームワークを提供するオープンソースプロジェクトです。Red Hat OpenStack Platformの一部として提供されている訳ではなく、Red Hatが公式にサポートしている訳でもありません。あくまでオープンソースであり、このような取り組みがされていますというご紹介になります。
OS-Migrateとは
- Ansible Playbookコレクション
- ユースケースにあわせて、用意されているrolesやmodulesを利用してPlaybookをカスタマイズすることが前提です
- インポート・エクスポートにはOpenStack APIを使用します。データベースを直接操作することはありません
マイグレーションのおおまかな流れ
- Destination Cloud（新規環境）作成（これはOS-Migrateの範疇外）
- Pre-workload（"control plane"） Migration
- Source Cloud（既存環境）からリソースをエクスポートしてDestination Cloud（新規環境）にインポート
- Workload Migration
- Source Cloud（既存環境）からVMとアタッチされているボリュームをエクスポートしてDestination Cloud（新規環境）にインポート
これらのエクスポート・インポートの操作はMigratorと呼ぶホストで実施します。OpenStack管理者権限ではなくテナント毎に実施することを前提としています。エクスポート・インポートの情報はyamlファイルに記載されるため、移行に不要な情報を削除したり移行先で名前を変更したい場合など、必要に応じて編集することも可能です。
Pre-workload Migrationの対象となるリソース
VMやボリュームなどのワークロードをマイグレーションする前に、Pre-workloadということでOpenStackリソースをマイグレーションします。マイグレーションできるリソースは以下になります。現在の制限としてFloting ipについては、そのまま（＝同じIPアドレス）移行はできません。Source CloudとDestination CloudでFloting ipレンジが異なっていると考えられるからです。移行先の新規環境において、新しいFloting ipのレンジから自動的に新しくアサインすることは可能です。同様の観点で、プロバイダーネットワークを使用している環境の移行ではSource CloudとDestination CloudでIPアドレスレンジの重複をどうするか考慮する必要がありますが、これはOS-Migrateの範疇外です。
- ユーザー
- プロジェクト
- ネットワーク
- サブネット
- ルーター
- ルーターのインターフェース
- セキュリティグループ
- セキュリティグループのルール
- glanceイメージ
- novaフレーバー
- keyペア
Workload Migration
ワークロード、すなわちVMとアタッチされているボリュームをマイグレーションします。ワークロードを停止して移行するコールドマイグレーションです。移行の際に、boot diskをコピーするかしないかを指定できます。boot diskのコピーを有効にすると、移行先でのインスタンスはboot-from-volumeになります。
Pre-workload Migration
Migrator
- 必要なパッケージ
- Ansible 2.9
- OpenStack Client
- OpenStack SDK
この環境にOS-Migrateをインストールします
- ansible-galaxy collection install os_migrate.os_migrate
インストールで作成されるファイルの一例
├── collections
│ └── ansible_collections
│ ├── community
│ │ ├── crypto
│ │ │ ├── changelogs
│ │ │ ├── meta
│ │ │ ├── plugins
│ │ │ └── tests
│ │ └── general
│ │ ├── changelogs
│ │ ├── meta
│ │ ├── plugins
│ │ ├── scripts
│ │ └── tests
│ ├── openstack
│ │ └── cloud
│ │ ├── docs
│ │ ├── meta
│ │ ├── plugins
│ │ └── scripts
│ └── os_migrate
│ └── os_migrate
│ ├── playbooks
│ ├── plugins
│ ├── roles
│ └── tests
└── tmp
# os_migrate以下
└── os_migrate
├── FILES.json
├── MANIFEST.json
├── README.md
├── localhost_inventory.yml
├── playbooks
│ ├── delete_conversion_hosts.yml
│ ├── deploy_conversion_hosts.yml
│ ├── export_flavors.yml
│ ├── export_images.yml
│ ├── export_keypairs.yml
│ ├── export_networks.yml
│ ├── export_projects.yml
│ ├── export_router_interfaces.yml
│ ├── export_routers.yml
│ ├── export_security_group_rules.yml
│ ├── export_security_groups.yml
│ ├── export_subnets.yml
（略）
MigratorはOpenStack APIを利用するので、認証のための情報をyamlファイルを作成し設定します。リソースが管理者に所属している場合を除いて、プロジェクト／テナント毎にcredentialを利用してOS-migrateを使用することを推奨してます。
- 必要な認証情報
- Source project
- Destination project
- Source admin
- Destination admin
設定例：os-migrate-vars.yml
os_migrate_src_auth: auth_url: http://192.168.0.13.199/v3 password: srcpassword project_domain_name: Default project_name: src user_domain_name: Default username: src os_migrate_src_region_name: regionOne os_migrate_dst_auth: auth_url: http://192.167.0.16:5000/v3 password: dstpassword project_domain_name: Default project_name: dst user_domain_name: Default username: dst os_migrate_dst_region_name: regionOne os_migrate_data_dir: /home/migrator/os-migrate-data
Migratorの準備ができたところで、各種リソースをエクスポート・インポートします。コマンドでよく利用する値は環境変数で設定しておきます。
例として、ネットワークをエクスポートして、それをインポートするためにはMigratorで下記のコマンドを実行します。なお、Migrator はSource CloudとDestination Cloud両方に対してアクセス可能である必要があります。
OSM_COL=/home/migrator/.ansible/collections/ansible_collections/os_migrate/os_migrate ansible-playbook -v \ -i $OSM_COL/localhost_inventory.yml \ -e @os-migrate-vars.yml \ $OSM_COL/playbooks/export_networks.yml ansible-playbook -v \ -i $OSM_COL/localhost_inventory.yml \ -e @os-migrate-vars.yml \ $OSM_COL/playbooks/import_networks.yml
Workload Migration
Conversion Host
ワークロードのマイグレーションではConversion Hostというものを利用します。これは、Source CloudとDestination Cloud両方で稼働する仮想マシンで、バイナリーボリュームデータをSource CloudからDestination Cloudに転送する処理を行います。Conversion Hostはv2v-conversion-host-appliance-devel.qc2というイメージで提供されており、このイメージをSource CloudとDestination Cloudにアップロードしておき、Source CloudとDestination Cloudの移行対象のテナントでインスタンスを起動します。
Source Cloudでの処理
- 移行対象の仮想サーバからボリュームをデタッチします
- Source CloudのConversion Hostにボリュームをアタッチします
- ボリュームをブロックデバイスとしてエクスポートして、Destination CloudのConversion Hostからの接続を待ちます
Destination Cloudでの処理
- Destination CloudのConversion Host上に新しいボリュームを作成します
- Source CloudのConversion Hostによってエクスポートされたブロックに接続し、新しくアタッチされたボリュームにデータをコピーします
- Destination CloudのConversion Hostからボリュームをデタッチします
- 新しいボリュームから新しい仮想サーバを作成します
Workloadについてもエクスポート・インポートのコマンドはPre-workloadと同様にMigratorで実行します。
ansible-playbook -v \ -i $OSM_COL/localhost_inventory.yml \ -e @os-migrate-vars.yml \ $OSM_COL/playbooks/export_workloads.yml ansible-playbook -v \ -i $OSM_COL/localhost_inventory.yml \ -e @os-migrate-vars.yml \ $OSM_COL/playbooks/import_workloads.yml
これらの処理をテナント毎にひたすら実行します。リソースはネットワーク、サブネット、ルーター、ルーターインターフェース等々たくさんありますが、クラウドが稼働中でもエクスポート・インポート処理はできるので問題ないと思います。ワークロードについては停止を伴うため、移行タイミングに考慮が必要です。そのため、実際にマイグレーションするとなると、テナントの数やVMの数、使用しているボリュームのサイズ等考慮すべき点は多数ありますので、このOS-Migrateというツールが即使えるという訳ではありませんが、マイグレーションの方法の一例として紹介させていただきました。
↓OS-Migrateを開発している方々の記事 www.redhat.com
