技術的なことをメインにいろいろ書いてくサイトです
ESXi for ARM EditionやUSB Network Native Driver for ESXi といった以前VMware Flings http://flings.vmware.com にあったソフトウェアは、2023年10月に https://developer.vmware.com/samples にリダイレクトされるようになった。
このURLは、 https://developer.broadcom.com/samples にリダイレクトされるのだが、2025年4月2日時点では、errorとなっている。
では、以前VMware Flings にあったものがどこにあるのかというと Broadcom communityの「Welcome to the new home for Flings!」にあった
2024年8月に更新されたvSphere GPU Monitoring を最後に更新はないように見えたけど、
よくみてみたら「Nested ESXi Virtual Appliance」は ESXi 8.0 Update 3c VAが出てた
Oracle Cloud(OCI)のオブジェクトストレージに cyberduck を使って接続する際、なんかうまくいかなかったのでメモ書き
us-phoenix-1にあるので、OCI Object Storage (us-phoenix-1).cyberduckprofile を選択したのだが選択しても表示されるサーバ名は「s3.amazonaws.com」となっている。
cyberduckprofileの内容を確認すると下記なので、本来サーバに表示されるべきなのは「<namespace>.compat.objectstorage.us-phoenix-1.oraclecloud.com」なんじゃないのか？という疑問点が・・・
<key>Protocol</key>
<string>s3</string>
<key>Vendor</key>
<string>oracle-us-phoenix-1</string>
<key>Description</key>
<string>OCI Object Storage (us-phoenix-1)</string>
<key>Hostname Placeholder</key>
<string><namespace>.compat.objectstorage.us-phoenix-1.oraclecloud.com</string>
<key>Hostname Configurable</key>
<true/>
なお、cyberduckのバージョンは 9.1.2 (42722) でした。
じゃあ、OCIにつなぐときはどう接続すればいいのか？
とりあえず、プロファイルはOCI Object Storageを選択する
サーバ名は「<namespace>.compat.objectstorage.us-phoenix-1.oraclecloud.com」
ここでいう<namespace>は、Oracle Cloudコンソールで[ストレージ]-[オブジェクトストレージ]-[バケット(bucket)]で表示される「ネームスペース」のこととなる。
cyberduckに入力すると以下のような感じになる。
続いてAccess KeyとSecret KeyをOracle Cloudコンソールで作成する。
[アイデンティティとセキュリティ]-[ドメイン]でドメイン「Default」を選択
[アイデンティティ・ドメイン]-[ユーザー]にて、API操作用のユーザを作成
作成後、該当ユーザを選択し、[リソース]-[顧客秘密キー]を開く
「秘密キーの生成」をクリック
ここで表示される「生成されたキー」が Secret Keyとなる。
書いてある通りに再表示できないので、間違えずに保存すること。
画面を閉じて一覧に戻ると、Access Keyが確認できる。
これで、Access KeyとSecret Keyが入手できたので、Cyberduck設定画面に入力する
これで接続をすると以下のようにOracle Cloud上のオブジェクトストレージのbucket内容が表示されるのを確認できた。
vSphereがアレなことになってしまってから、いろいろ面倒なことになっています。
そんな中、HPEからHPE VM Essentialsなる仮想基盤を出すという話が・・・
2025/01/14にHPE VM Essentials trial というページが公開されているというのに気がついて、ダウンロードしてみました。
ただ、2025/02/04時点でもドキュメントの理解ができてないので、いまいち設定がよくわかりません・・・
まだ世間に設定してみた情報が少ないので、問題になった点とかのメモもかねて公開していきます。
v8.0.2.1を使用しての感想
・ドキュメントが足らなすぎる
・処理中なのかどうかもう少し表現してほしい
・仮想DVDドライブのメディア入れ替えが動作しないのと初期設定時以外に設定追加できないのなんとかしてほしい
・iSCSIストレージの追加ってどこからやるの？
・ローカルストレージの追加ってどこからやるの？
・ドキュメント上 /var/morpheus ディレクトリで容量使うってどこにも書いてない気がするんですが！！！
・作成した仮想マシンBIOS設定だったんだけど、UEFIへの切り替えはどこでやるの？(作成後に変更不可っぽい)
・Secure Boot / vTPM への対応はするの？(仮想イメージの設定側で変更する?)
HPE VM Essentials trial というページにて公開されています。
登録後は My HPE Software Center から左側の「Software」を開き、Searchキーワードに「HPE VME」と入力して検索すると、Search Resultsにその時点での最新版が表示されます。
2025/03/26注: [My HPE Software Center]からSinginしないで「Browse Free Software」をクリックする、というアクセス方法に代わっていた
2024/01/14時点では、 HPE_VM_Essentials_SW_image_v8.0.1.1_S5Q83-11001.iso の中に、Ubuntu 22.04上へインストールするためのパッケージファイル(hpe-vm_1.0.2-1_amd64.deb)と、HPE Manager用の仮想ディスクイメージファイル(hpe-vme-8.0.1-1.qcow2.gz)が入っていました。
その後、2025/01/29付けで HPE_VM_Essentials_SW_image_8.0.2_1_S5Q83-11003.iso に差し替わり、こちらはパッケージファイルはそのまま(hpe-vm_1.0.2-1_amd64.deb)と、HPE Manager用の仮想ディスクイメージファイルが更新されて hpe-vme-8.0.2-1.qcow2.gz になっていました。
現状ではアップデートされたかどうかのお知らせが出ていないようなので、自分で確認する必要があるようです。(2025/02/26 Release Noteが公開されるようになった)
2025/02/24付けで ver 8.0.3-1がリリースされました。
HPE_VM_Essentials_SW_image_8.0.3_1_S5Q83_11005.iso の中のdebファイルは変わらずhpe-vm_1.0.2-1_amd64.deb のまま。HPE Manager用仮想ディスクイメージが hpe-vme-8.0.3-1.qcow2.gz に更新。
また、追加でHPE Manager仮想マシン内のファイルをアップデートする用に hpe_vm_essentials_8.0.3_1_amd64.deb と hpe_vm_essentials_supplemental_8.0.3_1_all.deb が増えました
変更点ってなんなの？と聞いてみたら、ドキュメントサイト上に v8.0.3 Release Notesが追加されました。
2025/04/03になって ver 8.0.4-1がリリースされました。(ドキュメント上 v8.0.4 March 31, 2025 と書いてあるけど、サイトで公開されたのは4/3)
HPE_VM_Essentials_SW_image_8.0.4_1_S5Q83-11007.iso の中は hpe-vm_1.0.4-1_amd64.deb と hpe-vme-8.0.4-1.qcow2 になりました。
2025/04/04 10時時点では HPE Manager仮想マシンアップデート用のファイルは未公開です。
HPE VM Essentialsのドキュメントページに下記の絵があります。
2025年1月末時点では、Ubuntu 22.04ベースのサーバ上に、HPE VM Consoleパッケージ(hpe-vm_1.0.2-1_amd64.deb)を追加する。
追加したサーバのうち1台の上に、中央管理サーバとなるHPE VME Manager仮想マシンを構築して起動する、というものになる。
Ubuntu 22.04インストール時に最小インストールで実施してみたところ、hpe-vm_1.0.2-1_amd64.deb パッケージインストール時に足らないパッケージを全部持ってきてるようだったので、それで大丈夫だろう、と思って設定していたのですが、HPE VME Manager仮想マシンの構築で失敗するという問題が発生しました。
原因が半月以上わからないままだったのですが、ふと思いついてUbuntuの再インストール時に最小インストール “Ubuntu Server (minimized)” をやめたらすんなりと成功するいう・・・
ドキュメント上、特に記載がないが、動作をみたところ、/var/morpheus/kvm/ 以下にデフォルトのデータストア(仮想マシン格納場所)が作成されていた
このため、 /var/morpheus は別のパーテーションとして容量を確保した方がよいかと思われる。
とりあえず、普通に固定IPアドレスを割り当てたネットワークインタフェースが1つあれば、仮想マシンを動かす設定まで作れる。
ポイント的なものでいうと
・Ubuntu 22.04インストール時に使用するネットワークインタフェースに固定IPを割り当てる
・上記で使ったネットワークインタフェース名(たとえばeno5)は HPE VM Managerインストール時に何回か入力することになる
・Compute VLANを別に用意しなくても問題なく、管理用と同じで動作させることはできる
仮想環境で使用するネットワークについては、open vswitchを利用したものが作成される。
インストール直後は「default」だけだが、HPE VM Managerの初期セットアップとサーバの登録が終わると「Management」と「Compute」という設定ができている。(virsh net-listで確認できる)
Ubuntu 22.04 Serverをインストールした後、ISOイメージの中にある hpe-vmのdebパッケージをインストールすることで、HPE VM Essentailsで使用するhypervisor用サーバとなる。
「sudo apt install -f hpe-vm_1.0.2-1_amd64.deb」というふうに実行すると、必要なUbuntuパッケージとともにインストールされる。
ただ、パッケージインストール後、一度OS再起動した方が良さそうな気がします。
インストール直後の virsh net-list –all実行結果
vmadmin@hpevm:~$ virsh net-list --all
Name State Autostart Persistent
----------------------------------------
vmadmin@hpevm:~$
再起動後の実行結果
vmadmin@hpevm:~$ virsh net-list --all
Name State Autostart Persistent
--------------------------------------------
default active yes yes
vmadmin@hpevm:~$
hpe-vm パッケージをインストールすると、「hpe-vm」コマンドが実行できるようになります。
「sudo hpe-vm」で起動すると以下のような画面となります。
最初は「Keyboard Layout / TimeZone」でキーボードとタイムゾーンを設定します。
コマンドで「sudo timedatectl set-timezone Asia/Tokyo」でもよい。
VC Keymapを「sudo localectl set-keymap jp106」で設定しようかと思ったのですが、そちらはパッケージが足らないらしくエラーになりました（UIから選択すると自動的にインストールされる）
管理はHPE VME Manager仮想マシン経由で行うため、環境内に1台だけインストールを行う。
HPE VME Manager仮想マシンのインストールはhpe-vmの「Install Morpheus」から実施する。
以下のような形でセットアップパラメータを指定する
IP Address: HPE VME Manager仮想マシンのIPアドレス
Netmask, Gateway, DNS Serverは普通に設定
Appliance URLは、セットアップ完了後、HPE VME Manager仮想マシンの管理Webにアクセスする際のURLを指定する。https://ホスト名.ドメイン名 というようなDNSサーバで解決できる名前を指定することを推奨している模様。IPアドレス指定でも大丈夫だった。
Hostname はHPE VME Manager仮想マシンのホスト名
Admin User / Admin Password はHPE VME Manager仮想マシンにsshでログインする場合のユーザ情報
Select VM Sizeは「Small」「Medium」「Large」の3種類から選ぶが、現状のドキュメントでは仮想マシンスペックの違いしかかかれておらず、管理対象台数などがどう変わるかについては不明。
Host Configration Optionsの Management Interface には、ホストサーバで、管理用のIPアドレスがついているインタフェースを選んだ
インストールを開始すると、93%で一度長時間止まる。
これは初回起動にとても時間がかかるためで10分ちょい放置すると、サービスが起動したというウィンドウが表示される。
起動が終わる前に管理URLにアクセスすると以下のような表示が出る。（最初は ポート80しかあいてないが、そのうちポート443もアクセスできるようになる)
完了すると「Morpheus VM Installed」という表示が出る。（下記キャプチャはAppliance URLを IPアドレスで設定した場合のキャプチャ)
サービスの起動が完了したあとにAppliance URLで指定したURLにブラウザからアクセスすると、下記のようなログイン画面が表示される。
ドキュメントで解説している箇所がよくわからないが、以下のツリー構成になっているようだ。
テナント名
└グループ名
└クラウド名
└クラスター名
├ホスト
├VM(仮想マシン)
├ネットワーク
├ストレージ
└仮想イメージ
あと、上記とは直接関係なく「ラベル名」という区別のための識別符をつけることもできる。
テナント名: 初回ログイン時にマスターテナント名として指定
v8.0.2.1時点ではテナントの管理URLっぽいのにアクセスするとエラーになるので、これからなんか実装していくっぽい
グループ名:拠点などでわけることを想定していると思われるもの
クラウド名:「HPE VM Essentials環境」と「vSphere環境」の2種類を登録できる。
クラスター名:vSphereのクラスターとほぼ同じ意味合いでのクラスター。この下に実際の物理Ubuntuサーバ with HPE VMを登録する
初回ログイン時に設定が求められる項目として以下がある
マスターテナント名: 適当になんか名前を設定
マスターユーザーの作成で、主管理ユーザを作成。メールアドレスも必須
初期セットアップは、Install Morpheus で入力したものを指定
最後にライセンス登録。評価版の時はなにも入力しない
以上で初期セットアップ終了
HPE VM Managerセットアップ後のvirsh net-list –allを確認すると、設定が変わっている。
vmadmin@hpevm:~$ virsh net-list --all
Name State Autostart Persistent
-----------------------------------------------
default active yes yes
Management active yes yes
vmadmin@hpevm:~$
初期設定が終わったらサーバ登録を行う。
「インフラストラクチャ」から「グループ」作成→「クラウド作成」
クラウド作成は多少時間がかかるので、ステータスが「INITIALIZING」から「OK」に変わるのを確認すること（自動更新をしないようなので再読み込みで確認）
で、作成されたこのクラウドのリンクをクリックして、「クラスター」を開く
クラスターの追加ウィザードの中で重要なポイントは以下の構成オプションのところ
hpe-vmパッケージをインストールしたUbuntuサーバをSSHホストとして指定
Management Net Interface、Compute Net Interface、Overlay net Interfaceに使用するネットワークインタフェース名を入れる。全部同じインタフェースを使用しても動作した。
（Overlay net Interfaceを空欄で進めたら指定していないはずの eno0デバイスがないというエラーが出たので、指定しないとダメっぽい)
タグVLANを使う場合はCompute Net Interfaceに使うインタフェース名と、COMPUTE VLANSにタグVLANの値を列挙する。
レイアウトは「HPE VM 1.1 Cluster on Existing Ubuntu 22.04」と「HPE VM 1.1 HCI Ceph Cluster on Existing Ubuntu 22.04」の選択肢になっているのだが、HCI構成の場合の要求要件がわからないのでまだ手を付けていない
あと「CPU Model」のところで、そのクラスタで使用する仮想マシンに許可するCPU世代を指定できる。(VMware EVCみたいな感じか)
これで完了をクリックして、少し待つと、クラスターに登録される
登録した後は、情報同期が行われているようなので、10分ぐらい放置する
登録直後は、各サーバの詳細を見ると、下記のようにストレージ情報がありません、と出る。
しばらく待つとそのサーバのローカルディスクが表示される
他のタブでも同様の状態となっているのだが、情報更新中であることを示すアイコンがあるのかどうか現状不明なので、とりあえず再読み込みしてみるしかない模様
ある程度処理が進んでいると「virsh net-list」の実行結果が下記のように「Management」と「Compute」になっていて、最初合ったdefaultが消えている。
vmadmin@hpevm:~$ virsh net-list --all
Name State Autostart Persistent
-----------------------------------------------
Compute active yes yes
Management active yes yes
vmadmin@hpevm:~$
現状、以下の機能は実装されていない模様
・UEFI/BIOSの明示的な切り替え
・UEFI時のSecure Boot 有効/無効 切り替え
・TPMの有効化
このため、標準設定のWindows 11をインストールすることはできない。
とりあえず試験的にインストールしたWindowsとLinuxはBIOS構成となっていた。
Windows Serverなどをインストールするとき、標準的なWindows ISOイメージにはKVM環境向けのvirtioドライバーが含まれていないため、インストーラ上からディスクを認識できない。
Nutanixなどであれば、途中で読み込ませるISOファイルをVirtioドライバISOに換えればよいのだが、HPE VM EssentailsのWeb UIからISOファイルを別のものに変更する操作が動作しない。
正解は仮想マシン新規作成時の「Advanced Options」の中にある「ATTACH VIRTIO DRIVERS」にチェックを入れる、というもの。
これによりOSインストール用のISOイメージの他に、virtioのISOイメージがマウントされた状態で起動するようになる。
なお、v8.0.2.1の状態ではGUI上で作成済みの仮想マシンに対してISOファイルマウントの設定を行うことはできない模様。
RedHat VirtIO SCSI controller :VEN_1AF4&DEV_1001 → viostor
PCIシンプル通信コントローラ :VEN_1AF4&DEV_1003 → vioserial
PCIデバイス :VEN_1AF4&DEV_1002 → balloon
イーサネット コントローラー :VEN_1AF4&DEV_1000 → NetKVM
マルチメディア オーディオ コントローラ :VEN_8086&DEV_2415 → Intel(r) 82801AA AC’97 Audio Controller
マルチメディア オーディオコントローラ(Intel 82801AAエミュレーション)については、適用できるドライバが64bit向けがない？
VEN_1AF4&DEV_1004 → vioscsi
VEN_1AF4&DEV_1005 → viorng
VEN_1AF4&DEV_1041 → NetKVM
VEN_1AF4&DEV_1044 → viorng
VEN_1AF4&DEV_1045 → balloon
VEN_1AF4&DEV_1050 → viogpudo
VEN_1AF4&DEV_1052 → vioinput
VEN_1AF4&DEV_105A → viofs
VEN_8086&DEV_2930 → smbus
VEN_1B36&DEV_0002 ～ DEV_0004 → qemupciserial
VEN_1B36&DEV_0100 → qxl(xp,win7,2008R2),qxldod (win2012～2019)
(VEN_1AF4,VEN_1B36はRedHat Inc、VEN_8086はIntel)
基本的にはWebブラウザから操作することになっている。
が、virtで管理されているので 「virsh dumpxml 仮想マシン名」を実行してみると下記のようなvncに関する設定項目があるのがわかる
<graphics type='vnc' port='41001' autoport='no' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>
上記の場合、サーバローカルに対してのみポート41001でアクセスする場合に使えるので、sshトンネルで127.0.0.1:41001にアクセスする設定をいれてやれば、他のマシンからでも接続できる
この状態で、Windowsにvirt-viewerをインストールして「”C:\Program Files\VirtViewer v11.0-256\bin\remote-viewer.exe” vnc://127.0.0.1:41001」を実行すると接続できる。
パスワードが求められるが、VNCのパスワードはなぜかdumpxmlでは表示されないので「virsh edit 仮想マシン名」を実行して探す必要がある
<graphics type='vnc' port='41001' autoport='no' listen='127.0.0.1' passwd='Mo8lzACR'>
<listen type='address' address='127.0.0.1'/>
</graphics>
上記の場合、「Mo8lzACR」がパスワードとなる
まさかクラスター階層の「ストレージ」にiSCSIのターゲットIPの指定があるなんて・・・
これを指定することで、クラスタに所属するサーバ上でiSCSIストレージが追加されました。
vmadmin@hpevm:~$ sudo iscsiadm -m session
tcp: [1] 172.17.44.9:3260,2460 iqn.2007-11.com.nimblestorage:hpevme-v371c7edc5d1bd1e3.000000d2.6a07af3f (non-flash)
tcp: [2] 192.168.44.9:3260,2460 iqn.2007-11.com.nimblestorage:hpevme-v371c7edc5d1bd1e3.000000d2.6a07af3f (non-flash)
vmadmin@hpevm:~$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 63.9M 1 loop /snap/core20/2318
loop1 7:1 0 87M 1 loop /snap/lxd/29351
loop2 7:2 0 38.8M 1 loop /snap/snapd/21759
loop3 7:3 0 44.4M 1 loop /snap/snapd/23545
loop4 7:4 0 63.7M 1 loop /snap/core20/2434
loop5 7:5 0 89.4M 1 loop /snap/lxd/31333
sda 8:0 0 447.1G 0 disk
tqsda1 8:1 0 1G 0 part /boot/efi
tqsda2 8:2 0 2G 0 part /boot
mqsda3 8:3 0 444.1G 0 part
tqubuntu--vg-ubuntu--lv 253:0 0 100G 0 lvm /
mqubuntu--vg-morpheus 253:1 0 300G 0 lvm /var/morpheus
sdb 8:16 0 447.1G 0 disk
mqsdb1 8:17 0 447.1G 0 part
sdc 8:32 0 447.1G 0 disk
sdd 8:48 0 447.1G 0 disk
sde 8:64 0 447.1G 0 disk
sdf 8:80 0 447.1G 0 disk
sdg 8:96 1 0B 0 disk
sdh 8:112 0 1T 0 disk
mq22674a991c8b22b4c6c9ce9003faf076a 253:2 0 1T 0 mpath
sdi 8:128 0 1T 0 disk
mq22674a991c8b22b4c6c9ce9003faf076a 253:2 0 1T 0 mpath
sr0 11:0 1 1024M 0 rom
vmadmin@hpevm:~$ sudo multipath -ll
22674a991c8b22b4c6c9ce9003faf076a dm-2 Nimble,Server
size=1.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
|- 8:0:0:0 sdh 8:112 active ready running
`- 9:0:0:0 sdi 8:128 active ready running
vmadmin@hpevm:~$
ただ、認識したiSCSIのLUNは、そのままでは利用できず、ファイルシステム作成が必要そうな気配が・・・
仮想環境上にUbuntu をインストールして、hpe-vmパッケージインストールして、Install morpheusを実施してみたところ、なぜか仮想マシンが作られない
確認したらCPUのハードウェア仮想化/IOMMUを有効化してないせいで、KVMが正常に動かないためだった。
それはいいんだけど、問題なのは、/var/log 以下のどこにもそういったログが見当たらない、ということ。
で・・・有効化して再度実施すればいいのかな？と実行してみたところ、open vswitch側の設定が変なことになっていたらしく、Ubuntu=>VM Managerのping疎通が通らない、という状況に
どこを修正すればいいのかわからない状態なので、Ubuntu OSインストールからやり直すことになりました。（それでうまくいった)
VM Manager側の仮想マシンからの疎通確認できるかな？とvirsh edit “VM Managerの名前” でVNCの接続情報を見てvirt-viewerからコンソールを開いてみる
↑はまだセットアップ中だった模様
↓でログインできるようになっていたら初期化が終わってる
Install Morpheusで指定したユーザ名とパスワードでログインできる
HPE VME Managerからサーバを登録すると、 /etc/apt/sources.list.d/morpheus.list に下記にような内容が追加される
$ cat /etc/apt/sources.list.d/morpheus.list
deb [signed-by=/etc/apt/trusted.gpg.d/morpheus.asc] https://172.17.44.169/apt morpheus main
$
Windows 11仮想マシンを作る場合、vTPMを有効にする必要がある。
インスタンス側の設定項目がないなぁ、と思っていたら、ISOイメージファイルを登録する「仮想イメージ」にて設定項目があるとは思わなかった
ISOイメージ登録時に通常は折りたたまれている「高度」オプションの中にある「UEFI」「VTPM ENABLED」「SECURE BOOT」にチェックを入れておくと、このISOイメージを指定してインスタンスを作成した場合に有効になっている、という仕組みである模様
vSphere 7環境サーバ群からvSphere 8環境サーバ群に移管するにあたり、vCenterサーバおよびESXiサーバ側についてはまるっきり新設定にするけど、NFSデータストアストレージについては引き続き利用する、ということになった
新環境に仮想マシンを移動させるのに、Advanced Cross vCenter vMotionを使って仮想マシンを稼働状態のまま移動できないか確認した。
・ESXiのvmkernelで、旧環境と新環境間で通信がネットワークにvMotionを設定
・旧環境と新環境は、同じNFSバージョンでマウントする(データストア名は別でも良い)
・旧環境と新環境で同じホスト名解決が出来ること
vSphere間の仮想マシンデータの移行でもvMotionを使用するため、新旧環境の両方で通信がとれるvmkernelにvMotion設定を行う必要がある
旧環境NFS v3でマウント、新環境NFS v4.1でマウント、とした場合、別のデータストアとして認識されるようで、同じデータストアの実体でありながらコピー処理が発生した。
その際、元の仮想マシン名のディレクトリに「_1」を付与したディレクトリが作成され、そこにコピーが実施されたため、一時的に倍の容量を使用することになることに注意
旧環境と新環境でNFSマウントするときに、データストア名を別の名前でマウントしてみたが、同じデータストアだと認識されるようで、コピー処理は発生しなかった
今回、新環境側で仮想マシンインポートする、という手法でvMotionを実施した。
この場合、新環境側の「最近のタスク」ではキャンセルが実行できない
旧環境側の「最近のタスク」からだとキャンセルが実行できる
仮想マシン停止状態にしてからNFSストレージは移動させない形でのAdvanced Cross vCenter vMotionを実施したところ、一瞬で移行が完了しました。
Proxmox VEのcephストレージ環境の動作を確認するためESXi上に RAM 16GBの仮想マシンを4台作ってテスト中(+1台 corosync qnetdサーバがいてProxmox VEクラスタの維持に使用)
で、あるタイミングから、各ノード上のosdのdownが多発するようになった
root@pve37:~# ceph osd df tree
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME
-1 0.62549 - 480 GiB 210 GiB 204 GiB 178 KiB 5.4 GiB 270 GiB 43.65 1.00 - root default
-3 0.15637 - 160 GiB 59 GiB 58 GiB 47 KiB 1.4 GiB 101 GiB 36.92 0.85 - host pve36
0 hdd 0.03909 1.00000 40 GiB 15 GiB 14 GiB 7 KiB 403 MiB 25 GiB 36.27 0.83 36 up osd.0
1 hdd 0.03909 1.00000 40 GiB 18 GiB 17 GiB 13 KiB 332 MiB 22 GiB 44.03 1.01 52 up osd.1
2 hdd 0.03909 1.00000 40 GiB 11 GiB 10 GiB 18 KiB 337 MiB 29 GiB 26.46 0.61 27 up osd.2
3 hdd 0.03909 1.00000 40 GiB 16 GiB 16 GiB 9 KiB 393 MiB 24 GiB 40.91 0.94 48 up osd.3
-5 0.15637 - 160 GiB 67 GiB 66 GiB 75 KiB 1.6 GiB 93 GiB 41.95 0.96 - host pve37
4 hdd 0.03909 1.00000 40 GiB 19 GiB 18 GiB 24 KiB 443 MiB 21 GiB 46.87 1.07 51 up osd.4
5 hdd 0.03909 1.00000 40 GiB 11 GiB 11 GiB 21 KiB 201 MiB 29 GiB 28.58 0.65 30 up osd.5
6 hdd 0.03909 1.00000 40 GiB 16 GiB 16 GiB 12 KiB 294 MiB 24 GiB 39.51 0.91 40 up osd.6
7 hdd 0.03909 1.00000 40 GiB 21 GiB 20 GiB 18 KiB 693 MiB 19 GiB 52.84 1.21 61 up osd.7
-7 0.15637 - 80 GiB 49 GiB 47 GiB 36 KiB 1.3 GiB 31 GiB 60.91 1.40 - host pve38
8 hdd 0.03909 0 0 B 0 B 0 B 0 B 0 B 0 B 0 0 0 down osd.8
9 hdd 0.03909 0 0 B 0 B 0 B 0 B 0 B 0 B 0 0 0 down osd.9
10 hdd 0.03909 1.00000 40 GiB 20 GiB 20 GiB 17 KiB 415 MiB 20 GiB 51.02 1.17 53 up osd.10
11 hdd 0.03909 1.00000 40 GiB 28 GiB 27 GiB 19 KiB 922 MiB 12 GiB 70.80 1.62 73 up osd.11
-9 0.15637 - 80 GiB 35 GiB 34 GiB 20 KiB 1.1 GiB 45 GiB 43.27 0.99 - host pve39
12 hdd 0.03909 1.00000 40 GiB 20 GiB 20 GiB 7 KiB 824 MiB 20 GiB 50.81 1.16 63 up osd.12
13 hdd 0.03909 0 0 B 0 B 0 B 0 B 0 B 0 B 0 0 0 down osd.13
14 hdd 0.03909 1.00000 40 GiB 14 GiB 14 GiB 13 KiB 303 MiB 26 GiB 35.72 0.82 0 down osd.14
15 hdd 0.03909 0 0 B 0 B 0 B 0 B 0 B 0 B 0 0 0 down osd.15
TOTAL 480 GiB 210 GiB 204 GiB 183 KiB 5.4 GiB 270 GiB 43.65
MIN/MAX VAR: 0.61/1.62 STDDEV: 11.55
root@pve37:~#
pve38のosd.8とosd.9がdownになっているので、pve38にログインしてプロセスを確認すると、–id 8 と –id 9のceph-osdサービスが起動していないので、これらを再起動する
root@pve38:~# ps -ef|grep osd
ceph 1676 1 1 12:14 ? 00:02:01 /usr/bin/ceph-osd -f --cluster ceph --id 10 --setuser ceph --setgroup ceph
ceph 1681 1 2 12:14 ? 00:02:45 /usr/bin/ceph-osd -f --cluster ceph --id 11 --setuser ceph --setgroup ceph
root 30916 30893 0 14:10 pts/0 00:00:00 grep osd
root@pve38:~# systemctl restart ceph-osd@8
root@pve38:~# systemctl restart ceph-osd@9
root@pve38:~#
しばらく待つとupになる
root@pve38:~# ceph osd df tree
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME
-1 0.62549 - 600 GiB 227 GiB 221 GiB 229 KiB 5.6 GiB 373 GiB 37.84 1.00 - root default
-3 0.15637 - 160 GiB 53 GiB 52 GiB 47 KiB 1.4 GiB 107 GiB 33.11 0.88 - host pve36
0 hdd 0.03909 1.00000 40 GiB 13 GiB 12 GiB 7 KiB 403 MiB 27 GiB 31.50 0.83 28 up osd.0
1 hdd 0.03909 1.00000 40 GiB 16 GiB 16 GiB 13 KiB 332 MiB 24 GiB 40.30 1.07 47 up osd.1
2 hdd 0.03909 1.00000 40 GiB 9.7 GiB 9.4 GiB 18 KiB 337 MiB 30 GiB 24.21 0.64 22 up osd.2
3 hdd 0.03909 1.00000 40 GiB 15 GiB 14 GiB 9 KiB 393 MiB 25 GiB 36.41 0.96 41 up osd.3
-5 0.15637 - 160 GiB 61 GiB 59 GiB 75 KiB 1.6 GiB 99 GiB 37.89 1.00 - host pve37
4 hdd 0.03909 1.00000 40 GiB 16 GiB 15 GiB 24 KiB 443 MiB 24 GiB 39.75 1.05 41 up osd.4
5 hdd 0.03909 1.00000 40 GiB 10 GiB 10 GiB 21 KiB 201 MiB 30 GiB 25.52 0.67 26 up osd.5
6 hdd 0.03909 1.00000 40 GiB 14 GiB 13 GiB 12 KiB 278 MiB 26 GiB 34.26 0.91 32 up osd.6
7 hdd 0.03909 1.00000 40 GiB 21 GiB 20 GiB 18 KiB 693 MiB 19 GiB 52.02 1.37 52 up osd.7
-7 0.15637 - 120 GiB 57 GiB 55 GiB 54 KiB 1.5 GiB 63 GiB 47.17 1.25 - host pve38
8 hdd 0.03909 1.00000 40 GiB 14 GiB 14 GiB 18 KiB 132 MiB 26 GiB 35.75 0.94 30 up osd.8
9 hdd 0.03909 1.00000 0 B 0 B 0 B 0 B 0 B 0 B 0 0 22 up osd.9
10 hdd 0.03909 1.00000 40 GiB 18 GiB 18 GiB 17 KiB 419 MiB 22 GiB 45.92 1.21 42 up osd.10
11 hdd 0.03909 1.00000 40 GiB 24 GiB 23 GiB 19 KiB 939 MiB 16 GiB 59.84 1.58 42 up osd.11
-9 0.15637 - 160 GiB 57 GiB 56 GiB 53 KiB 1.2 GiB 103 GiB 35.51 0.94 - host pve39
12 hdd 0.03909 1.00000 40 GiB 15 GiB 14 GiB 7 KiB 841 MiB 25 GiB 37.05 0.98 37 up osd.12
13 hdd 0.03909 1.00000 40 GiB 16 GiB 16 GiB 16 KiB 144 MiB 24 GiB 39.70 1.05 42 up osd.13
14 hdd 0.03909 1.00000 40 GiB 14 GiB 14 GiB 16 KiB 84 MiB 26 GiB 35.82 0.95 39 up osd.14
15 hdd 0.03909 1.00000 40 GiB 12 GiB 12 GiB 14 KiB 127 MiB 28 GiB 29.48 0.78 30 up osd.15
TOTAL 600 GiB 227 GiB 221 GiB 236 KiB 5.6 GiB 373 GiB 37.84
MIN/MAX VAR: 0/1.58 STDDEV: 12.91
root@pve38:~#
が・・・またしばらくすると、他のosdが落ちる、などしていた
RedHat Ceph Storage 7 トラブルシューティングガイドの「第5章 Ceph OSD のトラブルシューティング」5.1.7. OSDS のフラップ を確認すると、osdに指定されているディスクが遅いから、ということになるようだ。
osd_heartbeat_grace_time というパラメータをデフォルトの20秒から変更すると、タイムアウトまでの値を緩和できるのかな、と思ったのだが、どうやって設定するのかが不明…
ceph.orgのOSD Setting を見ると /etc/ceph/ceph.conf (PVEの場合、 /etc/pve/ceph.conf )に追加すればいいのかな？というところなんだけど、OSD Config Reference , Configuring Monitor/OSD Interaction を見ても osd_heartbeat_grace_time というパラメータが無い…(osd_heartbeat_grace ならあった)
RedHatドキュメントの続きに書いてある「この問題を解決するには、以下を行います。」のところを見ると、「ceph osd set noup」「ceph osd set nodown」を設定して、OSDをdownおよびupとしてマークするのを停止する、とある。
試しにnoup,nodownの療法を設定してみたところ、OSDサービスを起動してもceph osd df treeで確認するとdownのままとなっていた。
まあ、upになったとしてもupのマークを付けないのが「noup」だから当然ですね・・・
そんなわけで、「ceph osd unset noup」「ceph osd set nodown」でdownにしない、という設定を入れてみた
設定を入れると「ceph osd stat」での状態確認で「flags nodown」と表示されるようになる。
root@pve38:~# ceph osd stat
16 osds: 16 up (since 62m), 16 in (since 62m); epoch: e4996
flags nodown
root@pve38:~#
とりあえず、これで一時的なごまかしはできた。
ただ、これは、OSDで使用しているディスクが壊れたとしても downにならない、ということでもある。
なので、「nodown」フラグを設定しっぱなしで使う、というのはとても不適切となる。
ちゃんとした対処を行うためには、具体的に何が問題になっているのかを「ceph health detail」を実行して、具体的にSlow OSD heartbeats がどれくらい遅いのかを確認する
root@pve38:~# ceph health detail
HEALTH_WARN nodown flag(s) set; Slow OSD heartbeats on back (longest 5166.450ms); Slow OSD heartbeats on front (longest 5467.151ms)
[WRN] OSDMAP_FLAGS: nodown flag(s) set
[WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 5166.450ms)
Slow OSD heartbeats on back from osd.13 [] to osd.8 [] 5166.450 msec
Slow OSD heartbeats on back from osd.13 [] to osd.0 [] 3898.044 msec
Slow OSD heartbeats on back from osd.12 [] to osd.9 [] 3268.881 msec
Slow OSD heartbeats on back from osd.10 [] to osd.3 [] 2610.064 msec possibly improving
Slow OSD heartbeats on back from osd.12 [] to osd.8 [] 2588.321 msec
Slow OSD heartbeats on back from osd.6 [] to osd.14 [] 2565.141 msec
Slow OSD heartbeats on back from osd.8 [] to osd.7 [] 2385.851 msec possibly improving
Slow OSD heartbeats on back from osd.13 [] to osd.11 [] 2324.505 msec
Slow OSD heartbeats on back from osd.8 [] to osd.12 [] 2305.474 msec possibly improving
Slow OSD heartbeats on back from osd.14 [] to osd.11 [] 2275.033 msec
Truncated long network list. Use ceph daemon mgr.# dump_osd_network for more information
[WRN] OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 5467.151ms)
Slow OSD heartbeats on front from osd.13 [] to osd.8 [] 5467.151 msec
Slow OSD heartbeats on front from osd.13 [] to osd.0 [] 3956.364 msec
Slow OSD heartbeats on front from osd.12 [] to osd.9 [] 3513.493 msec
Slow OSD heartbeats on front from osd.12 [] to osd.8 [] 2657.999 msec
Slow OSD heartbeats on front from osd.6 [] to osd.14 [] 2657.486 msec
Slow OSD heartbeats on front from osd.10 [] to osd.3 [] 2610.558 msec possibly improving
Slow OSD heartbeats on front from osd.8 [] to osd.7 [] 2436.661 msec possibly improving
Slow OSD heartbeats on front from osd.14 [] to osd.11 [] 2351.914 msec
Slow OSD heartbeats on front from osd.14 [] to osd.10 [] 2351.812 msec
Slow OSD heartbeats on front from osd.13 [] to osd.11 [] 2335.698 msec
Truncated long network list. Use ceph daemon mgr.# dump_osd_network for more information
root@pve38:~#
osd.7のログが出てるpve37にログインして /var/log/ceph/ceph-osd.7.log から「no replay from」と「osd.8」でgrep をかけてログを確認
おそらく「Slow OSD heartbeats on front from osd.8 [] to osd.7 [] 2436.661 msec」に相当するあたりがコレなのかな？というところ
2024-11-14T14:46:05.457+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:02.037605+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:06.454+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:02.037605+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:07.467+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:07.338127+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:08.418+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:07.338127+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:09.371+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:09.038264+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:10.416+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:09.038264+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:11.408+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:11.338592+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
oldset deadlineにある時刻と、その前にある時刻の差は20秒なので、 osd_heartbeat_grace もしくは osd_heartbeat_grace_time のデフォルト値 20 が効いてるんだろうなぁ、と推定できる
設定手法について記載を探してみたのだがなかなかない
Ceph Block Device 3rd Party Integration » Ceph iSCSI Gateway » iSCSI Gateway Requirements に下記のような設定例がある
[osd]
osd heartbeat grace = 20
osd heartbeat interval = 5
また、下記のように個別OSDに対して値を設定することも可能であるようだ
ceph tell osd.* config set osd_heartbeat_grace 20
ceph tell osd.* config set osd_heartbeat_interval 5
ceph daemon osd.0 config set osd_heartbeat_grace 20
ceph daemon osd.0 config set osd_heartbeat_interval 5
ceph tellの書式を確認すると「ceph tell osd.* config get osd_heartbeat_grace」で値がとれる模様
root@pve37:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
"osd_heartbeat_grace": "20"
}
osd.1: {
"osd_heartbeat_grace": "20"
}
osd.2: {
"osd_heartbeat_grace": "20"
}
osd.3: {
"osd_heartbeat_grace": "20"
}
osd.4: {
"osd_heartbeat_grace": "20"
}
osd.5: {
"osd_heartbeat_grace": "20"
}
osd.6: {
"osd_heartbeat_grace": "20"
}
osd.7: {
"osd_heartbeat_grace": "20"
}
osd.8: {
"osd_heartbeat_grace": "20"
}
osd.9: {
"osd_heartbeat_grace": "20"
}
osd.10: {
"osd_heartbeat_grace": "20"
}
osd.11: {
"osd_heartbeat_grace": "20"
}
osd.12: {
"osd_heartbeat_grace": "20"
}
osd.13: {
"osd_heartbeat_grace": "20"
}
osd.14: {
"osd_heartbeat_grace": "20"
}
osd.15: {
"osd_heartbeat_grace": "20"
}
root@pve37:~#
とりあえず「ceph tell osd.* config set osd_heartbeat_grace 30」と実行し、30に設定してみる
root@pve37:~# ceph tell osd.* config set osd_heartbeat_grace 30
osd.0: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.1: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.2: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.3: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.4: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.5: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.6: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.7: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.8: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.9: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.10: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.11: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.12: {
"success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.13: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.14: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.15: {
"success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
root@pve37:~#
すべて「”success”」ではあるので設定変更は完了しているのだと思うが、応答が2種類あるのはなんなのだろうか？
設定が変更されたかどうかを確認
root@pve37:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
"osd_heartbeat_grace": "30"
}
osd.1: {
"osd_heartbeat_grace": "30"
}
osd.2: {
"osd_heartbeat_grace": "30"
}
osd.3: {
"osd_heartbeat_grace": "30"
}
osd.4: {
"osd_heartbeat_grace": "30"
}
osd.5: {
"osd_heartbeat_grace": "30"
}
osd.6: {
"osd_heartbeat_grace": "30"
}
osd.7: {
"osd_heartbeat_grace": "30"
}
osd.8: {
"osd_heartbeat_grace": "30"
}
osd.9: {
"osd_heartbeat_grace": "30"
}
osd.10: {
"osd_heartbeat_grace": "30"
}
osd.11: {
"osd_heartbeat_grace": "30"
}
osd.12: {
"osd_heartbeat_grace": "30"
}
osd.13: {
"osd_heartbeat_grace": "30"
}
osd.14: {
"osd_heartbeat_grace": "30"
}
osd.15: {
"osd_heartbeat_grace": "30"
}
root@pve37:~#
とはいえ、set時の出力に「(not observed, change may require restart)」とあるとおり、ceph-osdの再起動が必須であるようだ
/etc/pve/ceph.conf に変更したパラメータは反映されてない模様なので、 osd.4～osd.7があるサーバを再起動してからもう一度値を確認してみたら、20に戻っていた。
root@pve38:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
"osd_heartbeat_grace": "30"
}
osd.1: {
"osd_heartbeat_grace": "30"
}
osd.2: {
"osd_heartbeat_grace": "30"
}
osd.3: {
"osd_heartbeat_grace": "30"
}
osd.4: {
"osd_heartbeat_grace": "20"
}
osd.5: {
"osd_heartbeat_grace": "20"
}
osd.6: {
"osd_heartbeat_grace": "20"
}
osd.7: {
"osd_heartbeat_grace": "20"
}
osd.8: {
"osd_heartbeat_grace": "30"
}
osd.9: {
"osd_heartbeat_grace": "30"
}
osd.10: {
"osd_heartbeat_grace": "30"
}
osd.11: {
"osd_heartbeat_grace": "30"
}
osd.12: {
"osd_heartbeat_grace": "30"
}
osd.13: {
"osd_heartbeat_grace": "30"
}
osd.14: {
"osd_heartbeat_grace": "30"
}
osd.15: {
"osd_heartbeat_grace": "30"
}
root@pve38:~#
/etc/pve/ceph.conf の最後に下記を追加
[osd]
osd heartbeat grace = 30
設定後、再起動してから確認すると、想定通り30になっているのを確認。そもそも、osd_heartbeat_grace についてはceph tellコマンドでの設定変更後、再起動しないでも大丈夫、というやつなんでは？
root@pve38:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
"osd_heartbeat_grace": "30"
}
osd.1: {
"osd_heartbeat_grace": "30"
}
osd.2: {
"osd_heartbeat_grace": "30"
}
osd.3: {
"osd_heartbeat_grace": "30"
}
osd.4: {
"osd_heartbeat_grace": "30"
}
osd.5: {
"osd_heartbeat_grace": "30"
}
osd.6: {
"osd_heartbeat_grace": "30"
}
osd.7: {
"osd_heartbeat_grace": "30"
}
osd.8: {
"osd_heartbeat_grace": "30"
}
osd.9: {
"osd_heartbeat_grace": "30"
}
osd.10: {
"osd_heartbeat_grace": "30"
}
osd.11: {
"osd_heartbeat_grace": "30"
}
osd.12: {
"osd_heartbeat_grace": "30"
}
osd.13: {
"osd_heartbeat_grace": "30"
}
osd.14: {
"osd_heartbeat_grace": "30"
}
osd.15: {
"osd_heartbeat_grace": "30"
}
root@pve38:~#