そろそろGWですね。家のインフラ環境を更新したのでまとめる記事を書こうと思ったのですが、そろそろ10年ちかくOpenStack運用してるなぁと気が付いたので何となくノウハウ記事でも書こうかなと思った次第です。
お家にクラウド環境があったら便利だと思いませんか？例えばAWSのEC2のように手軽に仮想マシンを作ってみたり、仮想マシンを組み合わせてkubernetesのクラスタを構築してみたりしたいと思ったことはあるのではないでしょうか？
それを実現するOSSとしてOpenStackというものがあります。我が家ではOpenStackをかれこれ10年ほど運用しており、自宅でEC2もどきが常にあるような生活を送っています。
今回は、OpenStackの紹介、構築の際の注意点、運用の際の注意点などを紹介しようかと思います。
OpenStackの紹介と我が家のクラスタ構成
大変雑な紹介をするとOpenStackは仮想マシンを管理するOSSです。商用のソフトウェアですとVMWareのvSphereなどをイメージしてもらえると良いです。
VMWareと違って全てOSSで構築されているのが特徴です。色々なコンポーネントの集合体として構成されていて以下のようなコンポーネントで構成されています。
- nova
- 仮想マシン(kvm)の起動を管理
- AWSのEC2のようなものです
- neutron
- 仮想マシンにつなぐ仮想ネットワークを管理
- AWSのVPCのようなものです
- keystone
- 各コンポーネントの認証、認可を管理
- AWSのIAMのようなものです、ただしIAMほど色々できたりしません
- glance
- 仮想マシンのイメージ(ISO的なもの)を管理
- AWSだとAMIが同じようなものです
- cinder
- 仮想マシンの仮想ディスクを管理
- AWSだとEBSが同じようなものです
いきなり沢山サービスが登場してしまって混乱してしまいますよね。
我が家では、このOpenStackを以下のような3台のPCを使ったクラスタ構成で構築しています。
正直なところ3台はやりすぎだと思っており、近年の計算機事情を考えると1台でも十分に実用になるかと思います。
1台目の構成
DeskMini X300を使った小型のPCです。
| コンポーネント | スペック |
| CPU | AMD Ryzen 7 5700G |
| メモリ | 64GB |
| ストレージ | SSD 2TB(NVMe) |
| OS | Ubuntu 22.04 |
2台目の構成
DeskMini A300を使った小型のPCです。
| コンポーネント | スペック |
| CPU | AMD Ryzen 7 2400G |
| メモリ | 32GB |
| ストレージ | SSD 2TB(NVMe) |
| OS | Ubuntu 22.04 |
3台目の構成
Minisforumの桜色のPCです。
https://store.minisforum.jp/products/minisforum-um773-lite
| コンポーネント | スペック |
| CPU | AMD Ryzen 7 7735HS |
| メモリ | 64GB |
| ストレージ | SSD 2TB(NVMe) |
| OS | Ubuntu 22.04 |
OpenStackのインストールの手順
手順としては結構手間がかかります。色々自動化ツールなども存在しているのですが、あまり信用していないので、自分は公式の手順を参考にポチポチやっています。
https://docs.openstack.org/ja/install-guide/index.html
流れとしては
- MySQLのDB向けのユーザの作成
- DBの初期化、スキーマの作成 & マイグレーション
- サービスごとのOpenStack用のユーザの作成
をそれぞれに実施して、その後各種コンポーネント用の設定を追加するようなイメージになります。
大変なのはneutronの設定なので、そこだけ注意深く実施する必要があります。
この辺、どこかでまとめて本とかにしようかなと思っています。
OpenStackインストール時、運用時の注意点
neutronの設定が良く分からないし、NICが1枚しかないPCで構築したい
インストールマニュアルや世間の事例だとNICが2枚以上あるマシンの事例ばかりで参考になりません。
1枚でも問題なく構築できるので安心してください。
例えば、家のクラスタマシンは全て1枚のNICのマシンを採用しています。/etc/network/interfaces に以下のような記述を行ってOpen vSwitchのブリッジが起動時に作られるような設定になっています。
auto lo
iface lo inet loopback
allow-ovs br-ex
auto br-ex
iface br-ex inet static
address 192.168.X.X
netmask 255.255.X.X
gateway 192.168.X.X
dns-nameservers 8.8.8.8 8.8.4.4
ovs_type OVSBridge
ovs_ports enp2s0
allow-br-ex enp2s0
iface enp2s0 inet manual
address 0.0.0.0
ovs_bridge br-ex
ovs_type OVSPortenp2s0 が元々マシンにあったNICです、これにアドレスを付与せずbridgeに直接つなぐような構成にしています。そして、br-ex をneutronで外向きのネットワークデバイスだと設定します。
具体的には、/etc/neutron/plugins/ml2/openvswitch_agent.ini のbridge_mappingsの設定を以下のように設定します。
bridge_mappings = external:br-ex
なお、上記の br-ex という名前のNICの設定と、bridge_mappingsの設定はすべてのホストで設定しなければなりません。controllerのホストだけ設定してOKというものではないので注意が必要です。
そして、external という名前のネットワークをneutron上に構築します。
openstack network create --share --external --provider-physical-network external --provider-network-type flat external
openstack subnet create --network external --allocation-pool start=192.168.5.50,end=192.168.5.200 --dns-nameserver 8.8.8.8 --gateway 192.168.1.1 --subnet-range 192.168.0.0/17 external上記のようにネットワークを構築すると、external というネットワークは br-ex を通じて外向きに通信するネットワークという意味になります。そして、subnetではIPアドレスを指定していますが、これは自宅内部のネットワークアドレス空間(192.168.0.0/17)のものを意味することになります。つまり、自宅のネットワーク(192.168.0.0/17)上の192.168.5.50から192.168.5.200がOpenStack内部の仮想マシン用として確保された事になります。ご自宅の都合に合わせてこれは設定するものになります。
上記のような手順で、NICが1つしかないマシンでも問題なく外部通信が出来るOpenstackが構築できます。
neutronのインストール時の注意点
neutronではバックエンドにつかうテクノロジとしていくつか選択肢がありますが、Open vSwitchを利用するのがおすすめです。
インストールのドキュメントはlinuxbridgeを使う手順が紹介されていますが、linuxbridgeのサポートはしばらくしたら廃止予定なのだそうです。以下のスライドで言及があります。
設定も最新のものではlinuxbridgeはexperimentalになっています。https://docs.openstack.org/neutron/latest/admin/config-experimental-framework.html
最新のneutronのインストール手順はOpen vSwtichを利用する手順が紹介されているのでそちらを参考にしてインストールするのがおススメです。
https://docs.openstack.org/neutron/latest/install/install-ubuntu.html
cinder用のストレージについて
各OSのパーティションとcinderが利用するパーティションは別に構成するのがおすすめです。
ここで問題になるのは、仮想マシンを起動するときにcinderを利用しない場合は、OSの /var/lib/nova の下などに仮想マシンのディスクが作成されて起動することになります。一方でcinderを起動ディスクにする場合はcinder側に作成したLVMのlogical volumeから起動することになります。
つまり、cinderばっかりを利用する想定であればcinder用のパーティションを大きく、OS側のパーティションは小さめに作った方が良いです。逆にOSの方にディスクイメージを作らせる想定であればOS側のパーティションを大きく、cinder側は小さくしてしまえば良いです。
運用の方針次第になりますが、cinder側のパーティションを大きくとってしまうのがおすすめです。いくつか理由があるのですが、
- cinderのvolumeサイズはある程度自由に変更ができるが、仮想マシン起動の際に選べるサイズはflavorによって決められた固定サイズ
- cinderのvolumeはiSCSIを使って接続するのでホストを跨いで利用できる。仮想マシンが稼働しているホストとディスクは別ホストといったことが出来ます、OS側にディスクを作る構成の場合にはこれが出来ません
- 仮想マシンの構成変更がcinderを使っている場合の方が楽。OS側にディスクを作る方針の場合はCPUの数の変更など(t2.smallからt2.largeに変えるようなイメージ)を行う際にディスクのサイズも併せて変更されてしまいます。しかも小さくなる方への変更は許されなかったりします。cinderだとそういった制限もないので取り回しが良いです
上記のような理由で基本的にcinderで仮想マシンを構築するような方針で運用するのがおすすめです。
データ復旧の方法が知りたい
設定ミスや故障などによって仮想マシンが起動しなくなったりすることがあるかもしれません。
マシンの再起動や設定の確認などで復旧すれば良いのですが、上手くいかない場合もあります。そういったときに最悪データの復旧だけは実行したいですよね。
そういった場合は、cinderのvolumeは、/dev/cinder-volumes/ にあると思います。これをkpartx、vgscanなどを使うことでmountすることが出来ます。
Xenのディスクを使った例になりますが以下のような手順で実施できます。
もちろん、こういった事態に備えて別途バックアップを実施しておくのが望ましいです。
仮想マシンのマイグレーションに失敗する
OpenStackのマイグレーションはsshを使ったファイルコピーで実現されています。インストールマニュアルにはこれについて記載されていません。novaのbasic configurationの項目にはsshの設定について記述があります。
https://docs.openstack.org/nova/yoga/admin/ssh-configuration.html
上記を実施したあと
openstack --os-compute-api-version 2.56 server migrate マシンのID --host ホスト名
といったコマンドで仮想マシンのマイグレーションが実施できるようになっているはずです。
ちなみに、live-migrationを実施しようとすると仮想マシンが認識しているCPUまで合わせる必要があります。自分はそれを実施していないので、live-migrationする運用にしていません。
novaのcpu_modelの設定でその辺り設定できるのですが最大公約数的な指定をせざるを得なくなるので古い世代に引っ張られるのは勿体ないし、CPUの世代や種類まで揃ったクラスタになる気がしないので諦めています。
まとまらないまとめ
なんとなく自分のハマった点などをいくつか紹介してみました。
他にもまだまだある気がしますが、思い出したら記事にしていこうかと思います。
また、最近家のサーバーで動いているものは、OpenStackの仮想マシンからkubernetesにお引越しを実施したりしたので、そちらの方もまとめていけたらと思っています。