ESXiで幾つかのサーバーを動かしているが、家庭内でメインで働いているサーバーOSが古くなったので置き換えようと思った。
ところが…サーバーのハードディスクを1TBに設定していて、ローカルPCの空き容量が足らなくてイメージを落としてくることさえできない。
★注意★
今回の操作はディスクのパーティションを操作したり、ディスクイメージそのものを操作したりする。失敗に備えて大事なファイルはバックアップしておいた方がいい。
やること。
仮想ディスクの種類
実際に利用しているのは120GBくらい？だったか。写真とか動画とかは別のところに保管しているから、たいした使用量じゃなかった。でも、仮想ディスクのファイルサイズが1TBになっており、とても扱いづらい状態になっている。でも、なんで1TBになっているんだろう？
VMware Docs / 仮想ディスクのプロビジョニング ポリシーについて
プロビジョニングというのは資源を割り当てて運用可能にすること、のようだ。
シックプロビジョニング(Thick Provisioning)
Thick…厚いとか太いとか、そんな意味か。
仮想ディスクを作成したときに、必要な容量が割り当てられるやり方。
さらに…
- 作成したときに全てを0で埋めるEager Zeroed
- 初めて必要になったときに0で埋めるLazy Zeroed
の2タイプがある。
シンプロビジョニング(Thin Provisioning)
Thin…薄い、ってところか。
仮想ディスクを作成したときには初期処理に必要な分だけを確保し、多くの容量が必要になったらその都度割り当てられるやり方。
今回選択していたのは…
ディスクイメージのファイルサイズが1TBになっていたのは、シックプロビジョニングでディスクを割り当てたからに違いない。確かにシステム構築時にどうするか迷った項目だったし、それでいて安易に「いくらかでも速いほうがいいや」とか思った気がしてきた…結果、ちょっと大変なことになった。
仮想ディスクのサイズ縮小
コマンドの挙動を見る限り、縮小というよりは、同じサイズの複製を作ってからプロビジョニングしていない領域を明確にしているだけに思われる。つまり、ESXiが動作しているマシンに最低でも「仮想ディスクの複製を作れるだけのデータストア容量」が必要になる。そして、実際に仮想ディスクにサイズが減るわけじゃない。
ただし、vCenter Converterで取り出すディスクのサイズが小さくなる。
これを実現するために、
- パーティションの使用領域を前方に詰める
- 未使用領域を大きなパーティションとして確保して0を埋める
- シックプロビジョニング→シンプロビジョニングに変換
を行う。安易にディスクを大きく取ったばっかりに大変な…
パーティションの縮小
GPartedを利用してパーティションを縮小する。
実際にはUbuntu 18.04のインストーラーを使って Try Ubuntu からデスクトップに行って、GPartedを起動している。
まずは、システムがインストールされていた /dev/sda1 を縮小。よく見れば使用量が100GBを切っているなぁ…ということで130GB程に。
swap領域は拡張パーティションに作成されていた。拡張パーティションを/dev/sda1の直後まで広げ、swapをoff→swapパーティションを先頭に移動、その後に拡張パーティションを縮めた。
最後に0埋めするために基本パーティションで/dev/sda3を作成。
当然だけど、この操作にはそれなりの時間がかかる。
空き領域を0埋め
ddコマンドで0埋め
今回の例では、0埋めしたいのは /dev/sda3。参照元では0で埋まったファイルを作成しているが、今回作ったパーティションそのものを消してしまう予定なので、パーティションそのものに0を書き込んだ。
りんか IT備忘禄 / 【実践】VMwareの仮想ディスクを縮小する
$ sudo su -
# dd if=/dev/zero of=/dev/sda3 bs=1M
※パーティションが本来持っているべき情報とかも消えちゃうと厄介だけど…
ddコマンドの進捗確認
ddコマンドはどこまで進んでいるのかを教えてくれない。別のターミナルを開いてシグナルを送ると進捗を教えてくれるようになる。
Qiita / ddの進捗を確認
$ sudo su -
# watch -n 60 pkill -USR1 dd
※これで1分ごとの進捗が出るようになる。
うちの環境では、1分間に概ね3GBの書き出しをしていた。
0埋め速度の調整
0埋め速度が速いのはいいけれど、2020/01/03 16:00～18:00くらい？の間、ふと見ると5～6アクセスをいただいており、この方達へのレスポンスが甚だしく悪くなっているはずだ…トラブルで捜し物をしているのに、見つけた先が開けないとかいうんじゃ申し訳なさ過ぎる…
ESXiのディスクの設定を色々とみていたときに「制限なし」という言葉を見かけていたので、その設定項目IOPsで検索してみたところアクセス速度に制限が掛けられそうだと分かった。
仮想マシンの設定を編集、ハードディスクの項目を開いて「制限 - IOPs」の値を変更する。うちの環境の場合で、この値を800にしたところddは1分で2GBを書き込み、500で1GB、200だとあまり先に進まなくなった。
この項目は起動中も変更することができるので、動かしながらいい感じに調整すればいいと思う。
0埋めしたパーティションを削除
GPartedを使って0埋めしたパーティション/dev/sda3を削除する。
これで、ディスクが小さくなっても問題ない状態ができた。
シンプロビジョニングに変換
ESXiにsshで接続し、ディスクを変換する。
$ vmkfstools -i hogeserver.vmdk -d thin hogeserver-thin.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk 'hogeserver.vmdk'...
Clone: 10% done.
10%から先が長い。長いけれどもきちんと進捗しているし、終わる。
うちの環境で3時間30分程度かかった。
この間、ディスクアクセスがほとんどこの処理に取られてしまい、ブログはまともにアクセスできなかった。実行するタイミングには注意が必要かも。
途中で別のssh接続をして確認すると、全く同じサイズのファイルができている！ファイルの更新日時は変わらないままだったが、とにかく処理は先に進んで完了した。
ls -la
total 1075567808
drwxr-xr-x 1 root root 77824 Jan 3 19:48 .
drwxr-xr-t 1 root root 77824 Jan 3 07:16 ..
-rw------- 1 root root 1099511627776 Jan 3 19:41 hogeserver-flat.vmdk
-rw------- 1 root root 1099511627776 Jan 3 19:48 hogeserver-thin-flat.vmdk
-rw------- 1 root root 501 Jan 3 19:48 hogeserver-thin.vmdk
-rw------- 1 root root 695 Jan 3 19:40 hogeserver.vmdk
…
完了したディスクに差し替えて、問題なく起動することを確認してみる。
→ 問題なく起動して動作したので、シャットダウンする。
vCenterConverterでバックアップを取る
vCenterConverterでバックアップを取ったところ、135GB程のディスクイメージとなった。大体狙い通り。
バックアップのジョブを投入する際、容量が足りないと言われた。
一応、1TBの容量があることを確認しているようだ。
また、ジョブの終了予定は1日と6時間程度となっていたが、実際には3時間程度で処理が終了した。シンプロビジョニングで不要な部分をカットしておいたのが功を奏した感じ。
さいごに
容量は必要になったときに広げるのがいいんだなってよく分かる出来事だった。広げればいい場所も今なら分かるし。
ホントに大変だったなぁ。
コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他