LoginSignup
2
2

ROSA (Red Hat OpenShift Service on AWS) で仮想マシンを起動してみた

Last updated at Posted at 2024-03-07

はじめに

  • ROSA (Red Hat OpenShift Service on AWS) はAWSとRed Hatが共同提供するフルマネージドなOpenShiftです。
  • OpenShift 4.14からはROSAにおいてもOpenShift Virtualization (OV) の機能がGAとなりました。
    • OVは、UpstreamのKubevirtを取り込んだ、「KVMを応用する事でKubernetesの上で仮想マシンのライフサイクル管理が可能になる機能」です
    • OVを用いてスケジューリングされるVMはBare Metal Nodeの上のみになります
    • よって、ROSAにBare Metal Nodeをアタッチすることで、OVが動きます。
    • 4.14時点では、従来のROSA (Classic) でしかGAとなっておりません。Hosted Control Plane (HCP) でのGAはもう少し待ちましょう。(ただ、私が実機でやってみた感じ、問題なく動くっちゃ動きます)

ROSAにBare Metal Nodeを追加する

本検証環境の仕様は以下の通りです。

  • ROSA 4.14.0
  • Tokyo Region, Multi-AZのCluster

まずはデフォルトで作成されているNode一覧を見てみます。

~ % oc get nodes
NAME                                             STATUS   ROLES                  AGE   VERSION
ip-10-0-0-207.ap-northeast-1.compute.internal    Ready    worker                 10h   v1.27.6+f67aeb3
ip-10-0-13-247.ap-northeast-1.compute.internal   Ready    infra,worker           9h    v1.27.6+f67aeb3
ip-10-0-31-160.ap-northeast-1.compute.internal   Ready    control-plane,master   10h   v1.27.6+f67aeb3
ip-10-0-33-6.ap-northeast-1.compute.internal     Ready    infra,worker           9h    v1.27.6+f67aeb3
ip-10-0-38-109.ap-northeast-1.compute.internal   Ready    worker                 10h   v1.27.6+f67aeb3
ip-10-0-59-203.ap-northeast-1.compute.internal   Ready    control-plane,master   10h   v1.27.6+f67aeb3
ip-10-0-64-220.ap-northeast-1.compute.internal   Ready    control-plane,master   10h   v1.27.6+f67aeb3
ip-10-0-83-142.ap-northeast-1.compute.internal   Ready    infra,worker           9h    v1.27.6+f67aeb3
ip-10-0-91-29.ap-northeast-1.compute.internal    Ready    worker                 10h   v1.27.6+f67aeb3

Control Plane (旧称 Master Node)、Infra Node、Compute Node(旧称 Worker Node)の三種類が作成されています。
※Infra Nodeというのは、Worker Nodeの一種で、OpenShiftを構成する管理コンポーネントを司るPodをスケジューリングするためのNodeです。

OVを利用する為にはBare MetalのWorker Nodeが必要ですので、「Red Hat Hybrid Cloud Console」からNodeを追加します。
image.png
ROSAでは、Worker Nodeたちを種類別にMachine Poolとして作成・管理できます。Add machine poolしていきます。
Bare Metal Nodeを適当に選んでおきます。とりあえずm5.metalを選択しました。AutoScale等はご自由にしてください。
image.png
このまま追加してしまっても良いのですが、Annotation (key:value)にNodeRoleの情報node-role.kubernetes.io/metal: ''付与しておきます。
※あとで見やすいようにするためなので任意。
image.png
追加できました。
image.png
ただしProvisioningされるまで相応の時間がかかりますので、しばし待ちます。
EC2がProvisioningされ、更にOpenShiftのNodeとしてアタッチされるまで30分くらいはかかりました。
image.png
追加されました。NodeのROLE欄にmetalが入っているやつが見えます。

~ % oc get nodes
NAME                                             STATUS   ROLES                  AGE     VERSION
ip-10-0-0-207.ap-northeast-1.compute.internal    Ready    worker                 10h     v1.27.6+f67aeb3
ip-10-0-13-247.ap-northeast-1.compute.internal   Ready    infra,worker           10h     v1.27.6+f67aeb3
ip-10-0-31-160.ap-northeast-1.compute.internal   Ready    control-plane,master   10h     v1.27.6+f67aeb3
ip-10-0-33-6.ap-northeast-1.compute.internal     Ready    infra,worker           10h     v1.27.6+f67aeb3
ip-10-0-38-109.ap-northeast-1.compute.internal   Ready    worker                 10h     v1.27.6+f67aeb3
ip-10-0-50-57.ap-northeast-1.compute.internal    Ready    metal,worker           4m7s    v1.27.6+f67aeb3
ip-10-0-59-203.ap-northeast-1.compute.internal   Ready    control-plane,master   10h     v1.27.6+f67aeb3
ip-10-0-6-250.ap-northeast-1.compute.internal    Ready    metal,worker           4m17s   v1.27.6+f67aeb3
ip-10-0-64-220.ap-northeast-1.compute.internal   Ready    control-plane,master   10h     v1.27.6+f67aeb3
ip-10-0-67-158.ap-northeast-1.compute.internal   Ready    metal,worker           4m27s   v1.27.6+f67aeb3
ip-10-0-83-142.ap-northeast-1.compute.internal   Ready    infra,worker           10h     v1.27.6+f67aeb3
ip-10-0-91-29.ap-northeast-1.compute.internal    Ready    worker                 10h     v1.27.6+f67aeb3

OpenShiftのコンソール画面でも確認してみます。
image.png
m5.metalが3台アタッチされました。

次はOpenShift Virtualization Operatorをインストールしていきます。

OpenShift Virtualization Operatorをインストール

簡単なのでコンソール画面からやっていきます。
管理者向け表示 → Operator → OperatorHub と進み、OpenShift Virtualization Operatorを選択します。
image.png
デフォルト設定のままインストールします。
image.png
インストール完了までしばし待ちます。2,3分お待ち下さい。
image.png
Operatorはインストールできました。続いてKubevirtを含むOVのコンポーネントをDeployしましょう。
「HyperConvergedの作成」をクリックします。
こちらもデフォルト設定で大丈夫です。Project(Namespace)がopenshift-cnvになっていると思います。
そのまま「作成」をクリックしてください。
image.png
コンポーネントが立ち上がるまでしばし待ちます。こちらも2,3分。
※開発者向け表示でトポロジーを確認すると、作成過程を見られます。
image.png
HyperConvergedがDeployされると、画面コンソールの更新を促されますので、更新してください。
管理者向け表示にすると、コンソールの左側にVirtualizationとかいうメニューができます。
image.png
おめでとうございます。ROSAでOpenShift Virtualization機能が使えるようになりました。
では、なんか適当にVMを立ててみましょう。

VMを建てる

Projectを作成しておきます。今回はvirtual-machineという名前にしておきました。
管理者向け表示にて、Virtualization → VirtualMachine と進み、Create VirtualMachineをクリックします。
image.png
From templateを選んでください。
今回はサクッとVMを建てたいので、Fedoraを選びます。
※Fedoraは、RHELの最も上流にいるUpstreamのProjectです。
image.png
今回はそもまま「Quick create VirtualMachine」をクリック。
image.png
直ぐにProvisioningが始まります。しばし待ちます。
image.png
Fedora VMがROSAの上で立ち上がりました。
image.png
「Console」タブからVMのコンソール画面(CLI ot GUI)にアクセスできます。
image.png
開発者向け表示のトポロジー画面からもVMの詳細を見られます。
image.png
本来はPodが浮いているところに「VM」っていうやつがおります。初めて見ると、とても違和感がありますね。

環境観察

さて、Fedora VMの横っちょにNot migratableと青字で表示されています。
image.png
OpenShiftの上で管理するVMは、Bare Metal NodeをまたいでLive Migrationする事ができるのですが、そのためにはVMにアタッチされているVolumeがReadWriteMany (RWX) である必要があります。
なお、VMにアタッチされる論理ディスクの実態はPersistentVolume (PV) です。
※VMもコンテナの中で動いており、コンテナはPodの中で動いています。KubernetesからはVMもPod/Containerとして見ているわけですね。
管理者向け表示にて、ストレージ欄からPersistentVolumeClaim (PVC) を見てみます。
image.png
バインドされているPVを見てみます。
image.png
アクセスモードがReadWriteOnce (RWO) になってます。これではVMのLive Migrationはできません。
実は、AWS EBSの仕様で、EBSをStorageClassとして作成する論理ディスク=PVはRWOしかProvisioningできません。

ほんとか!? ちょっと確認しておきましょう。
image.png
From formを選んでPVCを作成してみます。
image.png
RWO以外が選択できません。

ちなみに、AWS EFSはRWXのPVCを作成可能です。
EFSをStorageClassとして選択できるようにする為には「AWS Elastic File Service CSI Driver Operator」をインストールする必要があります。
image.png
「AWS Elastic File Service CSI Driver Operator」をインストール後、こちらの説明に従ってCRDを編集しますと、StorageClassのプロビジョナーとしてEFSを選択できるようになります。
image.png
EFSをStorageClassに選ぶと、確かにRWO以外の選択肢を選択できます。やった〜!
image.png
ただし、VMのVolumeにはブロックストレージを選択する必要がありますので、RWXであったとしてもEFSからProvisioningされたPV(ファイルシステム)は使えません。残念。

もしVMのLive Migrationを求める場合は、CSI対応の種々のSDSを用いて、RWXでProvisioningできるStorageClassを導入する必要がありますので、そのようにしてください。

なお、ストレージシステムと論理ディスク、あるいはStorageClassとPersistentVolumeなどの関係は、以下のイラストを参考に理解頂けます。
image.png

OpenShift Data Foundationを使ってRWX対応のブロックストレージをProvisioningできるようにする

諦めきれないので、OpenShift Data Foundation (ODF) をROSAにDeployして、cephベースのストレージを使えるにしてみました。

【注意】現時点においては、ROSAにおけるODFの利用はRed Hatの公式サポート対象ではありません。やるにしても自己責任でお願いします。

参考情報:

「OpenShift Data Foundation Operator」をインストールします。OperatorHubからインストールしてください。
image.png
設定はそのままでインストール〜!
image.png
インストールが終わるとStorageSystemの作成と画面コンソールの更新を促されますのでそのようにしてください。
image.png
バッキングストレージはEBSを使います。ので、おそらくデフォルトで選ばれているgp3をそのまま選びます。
image.png
「次へ」をクリックすると、cephクラスタを構成する為のWorker Node選択画面に行きます。
image.png
このNodeの条件が「3 つ以上のノードを (可能であれば) 3 つの異なるゾーンで選択します。ノードごとに最低でも 14 の CPU および 34 GiB のメモリー」ということでして、cephクラスタ用にNodeを更に追加します!

再度「Red Hat Hybrid Cloud Console」からadd machine poolする

条件に適合するMachineを選んでください。とりあえずm5.4xlargeを選んでおきました。
Auto Scallingなどは同じくご自由に!
image.png
これも任意なのですが、あとで見つけやすいように、「Node labels」にnode-role.kubernetes.io/storage: ''を追記しておきました。
image.png
「Add machine pool」を選択し、NodeとしてのProvisioning完了までしばし待ちます。また30分くらい待つ。

~ % oc get nodes
NAME                                             STATUS   ROLES                  AGE    VERSION
ip-10-0-0-207.ap-northeast-1.compute.internal    Ready    worker                 12h    v1.27.6+f67aeb3
ip-10-0-11-81.ap-northeast-1.compute.internal    Ready    storage,worker         30m    v1.27.6+f67aeb3
ip-10-0-13-247.ap-northeast-1.compute.internal   Ready    infra,worker           12h    v1.27.6+f67aeb3
ip-10-0-31-160.ap-northeast-1.compute.internal   Ready    control-plane,master   12h    v1.27.6+f67aeb3
ip-10-0-33-6.ap-northeast-1.compute.internal     Ready    infra,worker           12h    v1.27.6+f67aeb3
ip-10-0-38-109.ap-northeast-1.compute.internal   Ready    worker                 12h    v1.27.6+f67aeb3
ip-10-0-50-57.ap-northeast-1.compute.internal    Ready    metal,worker           104m   v1.27.6+f67aeb3
ip-10-0-56-20.ap-northeast-1.compute.internal    Ready    storage,worker         30m    v1.27.6+f67aeb3
ip-10-0-59-203.ap-northeast-1.compute.internal   Ready    control-plane,master   12h    v1.27.6+f67aeb3
ip-10-0-6-250.ap-northeast-1.compute.internal    Ready    metal,worker           104m   v1.27.6+f67aeb3
ip-10-0-64-220.ap-northeast-1.compute.internal   Ready    control-plane,master   12h    v1.27.6+f67aeb3
ip-10-0-67-158.ap-northeast-1.compute.internal   Ready    metal,worker           105m   v1.27.6+f67aeb3
ip-10-0-83-142.ap-northeast-1.compute.internal   Ready    infra,worker           12h    v1.27.6+f67aeb3
ip-10-0-91-29.ap-northeast-1.compute.internal    Ready    worker                 12h    v1.27.6+f67aeb3
ip-10-0-92-153.ap-northeast-1.compute.internal   Ready    storage,worker         30m    v1.27.6+f67aeb3

Provisioningが完了しました。再びODFの画面に戻ってきて、cephクラスタ用のNode(Storage)を選択します。
当該Node達はストレージクラスタとしてのみ使う予定なので、「テイントノード」にチェックを入れてください。
※テイント(Taint)を付けられたNodeには、明示的にNode指定をしたワークロード以外はスケジューリングされなくなります。
image.png
「次へ」をクリック、その後の設定はデフォルトでOKです。
image.png
ストレージクラスタの作成過程は、ストレージ → Data Foundation → Topologyで見ることができます。
途中、色んなアラートが出てびっくりするのですが、放っておけばストレージクラスタが完成しますので、しばし待ちます。
image.png
ストレージクラスタが完成しました。
image.png
こんな感じです。
image.png
StorageClass一覧を見てみてください。ODFから払い出されたcephベースのリソースが見えますね。
※接頭辞にocsと付いてるやつ。上からファイルストレージ、ブロックストレージ(デバイス)、オブジェクトストレージです。
image.png
さて、VMのVolumeとしてアタッチするべきPVのStorageClassは、ocs-storagecluster-ceph-rbdです。

再度VMを作成する

「Create」をクリックし、「From template」からFedoraを選択します。
image.png
今回は「Customize VirtualMachine」をクリックします。
image.png
ここはそのまま先に進みます。
image.png
「Disk」タブをクリックします。ここでrootdiskをRWXなVolumeにしたいのです。
image.png
rootdisk行の右端の三点リーダみたいなボタンをクリックします。
StorageClassの選択画面に「ocs-storagecluster-ceph-rbd」が見えますね。
また、VM用にディファインされたと思しき「ocs-storagecluster-ceph-rbd-virtualization」も見えております。
ここではとりあえず通常の「ocs-storagecluster-ceph-rbd」を選択しておきます。
image.png

image.png
StorageClassを明示的に設定できました。「Create VirtualMachine」をクリック。
image.png
Provisioning開始されました。しばし待ちます。
image.png
Provisioningが完了しました!しかもNot migratableも消えております!
image.png

Live Migrationをしてみる

前後の変化がシンプルに見やすいので、VM一覧画面から操作してみます。
対象のFedora VMが動いているNodeはip-10-0-50-57.ap-northeast-1.compute.internalということです。
image.png
ip-10-0-50-57.ap-northeast-1.compute.internalをクリックしてみれば、それは当然ながらBare Metal Nodeです。
image.png
三点リーダから「Migrate」をクリックしてみます。
image.png
一瞬だけ「Status」がMigratingとなり、直ぐにRunningになります。
Nodeがip-10-0-67-158.ap-northeast-1.compute.internalに変わりました。
image.png

おわりに

ROSAでGAとなった「OpenShift Virtualization」を使い、Live Migration可能なVMを起動してみました。
「OpenShift Virtualization」によって、ContainerとVMを統一されたプラットフォームの上で取り扱う事ができるようになりました。
これから企業の仮想基盤上のシステム・アプリケーションは、徐々にContainerベースのCloud Nativeなワークロードにモダナイゼーションされていくと思いますが、それでもパッケージソフトの制約等から、VMが完全に無くなることはないでしょう。
そうした場合において、「OpenShift Virtualization」が大いに役立つと思います。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2