DigiLoog

続きを読む »

HPE製品はサポート契約しないとアップデート用のBIOSを入手出来ない点が問題だが、
中身はDebian/UbuntuのProxmoxならハードウェア問題も発生しにくいと判断して許容した。
むしろ、この問題こそProxmoxを選んだ理由の大部分を占める。

NICは計3ポート搭載されており、2個がデータ送受信用で1個がiLO専用ポートとなる。
ディスプレイはD-Subのみ搭載なのでサーバっぽいと言えばサーバらしいが、
最近のモニタでは搭載していない事もあるので要注意ポイントだった。

中身はギチギチに詰まっておりサーバらしく排気用の4cm角ファンを搭載していた。
拡張カードを搭載するスロットや、
ThinMicroシリーズのディスクエンクロージャーを増設する端子も搭載されている。
ディスクマウンタは3.5インチなので、2.5インチSSDを搭載する為にはマウンタが必要となるが、
今回は端子位置に互換性があるマウンタを2個購入する事でSSDを搭載した。

SATA電源ケーブルと信号ケーブルはコネクタが一体化されている。
信号ケーブルは普通のSATAケーブルなので断線しても入れ替え可能だが、
電源ケーブルはマザーボード側が独自規格となっており入れ替え出来なそうだった。
保守部材に困りそうなので、お金に余裕が出たらコールドスタンバイ用に1台追加しようと思う。

………

自作PCの様にSSD搭載とメモリ増設を済ませたらハードウェアの準備が完了。
早速Proxmoxをインストールしていた所、OS本体からインストールする場合は、
mdadmによるRAID-1構成を標準では組めずZFSミラーにする必要があった。

ZFSはメモリ消費が激しい印象が強く出来る限り利用したく無かったのだが、
経験上ファイルシステムを弄るとパフォーマンスや構成に影響が出やすいのと、
インストールと同時にZFS領域を作れば全てProxmoxから管理出来るメリットがあるので、
メリット・デメリットを比較した上でZFSミラー構成を今回は選択した。

Proxmoxのインストール画面をクリックしていたらディスク構成以外は難なく終了した。
普段からLinuxのインストールをしている人なら30分もあれば終わる内容だと思う。
初めてのLinuxがProxmoxになる人は早々いないと思うが、
そんな人にはハードルの高い箇所があるのでLinuxで慣れてから触った方が良いと思う。

仮想サーバ1台と仮想ルータ3台を稼働させた状態がこちら。
ゲスト環境の負荷を一目で認識できるのは嬉しいポイントだったりする。
今回は利用していないがHCIの様に使う事出来るので、ディスクを管理する画面も備えている。
ZFSを利用する上で危惧していたメモリ使用率も今の所抑えられている。
“dedup=on”になっていない事を真っ先に確認したのも功を奏したと思う。

………

以前利用していたKVM管理ツールのKaresansuiや、今利用しているkimchiとも違う使い勝手だが、
画面構成が洗練されているからかドキュメントが無くてもゲストOSの構築まですんなり出来た。
流石にHAやHCIを組みだすとドキュメントを読まないと厳しいと思うが、
サクッと構築できるのは仮想サーバホスト構築の敷居を下げるメリットがあると感じた。

エンタープライズでオンプレミス仮想サーバホストを構築すると、
殆どのケースでVMware ESXiかOpenStackを使っておりProxmox事例は聞いた事が無いのが現状。
保守出来る所が少ないのも理由の一つだと思うが、
ホビー用途なら十分な利便性と性能を持っているので自宅サーバ勢の選択肢には上がると思う。
開発もまだまだ続く様なので実際に利用しつつ状況をウォッチし続けようと思う。

« 続きを隠す

続きを読む »

アーカイブの展開速度はアルゴリズム・CPU処理速度・ディスクアクセスで大体決まるが、
圧縮速度は上記の3つが複雑に絡まる上、対象ファイルの容量も重要な速度要素となる。
純粋に比較するなら前回と同じ環境がベストだが、6年前と同じ環境を揃えるのは無理なので、
趣向を変えて誰でも同じ条件を再現出来るVPSを使いつつ複数回測定する方針に変更した。

● 実行環境

1. 新規にサーバインスタンスを作成し、CentOS Stream 9をテンプレートインストール
2. インストール直後に”dnf update”を実行して2022年02月05日の最新状態へアップデート
3. OSチューニングは行わず、出来る限り素の状態に近くして計測開始

● コマンドバージョン

● 計測方法

1. バイナリファイルとテキストファイルに対して各圧縮コマンドを実行
2. 各コマンド事に6回の圧縮処理を実行する事で計測ブレを極力無くす
3. 圧縮率指定が出来るコマンドは、速度重視・指定無し・圧縮重視の3種類を測定
   ただし、アーカイブ化(＝無圧縮)オプションは計測を省略する
4. 時間計測にはLinuxのtimeコマンドを使い、real時間をファイル圧縮に要した時間とする
5. 圧縮率は『圧縮後のファイルサイズ ÷ 圧縮前のファイルサイズ』で算出
6. 圧縮対象の元ファイルは下記を利用
   テキストファイルは1度展開した後にtarコマンドで無圧縮アーカイブに固め直して計測

今回は対象コマンドや計測回数が増加したので、次の様なスクリプトを実行して放置した。
コマンドを連発しているので仮想ホスト側で制限がかかる可能性もあるが、
気にしたらベアメタルサーバを持ち出さないとダメになるので諦めた。

#!/bin/sh

date
echo

for LIST in `ls | egrep -iv "(bench|tmp)"`
do
    echo ${LIST}
    time gzip -c ${LIST} > ${LIST}.gz
    echo "---"
done

ls -l
du -l
rm -rf *.gz

………

計測結果の生データとCSVファイルは下記ダウンロードリンクを参照。
そのままのデータなので二次加工もしやすい筈。

今回の計測条件で測定してみたらバイナリとテキストの両方とも7zipが圧倒的に速かった。
前回の時は7zipの処理速度が若干早い中、バランスが取れているのはbzip2の印象だったが、
内部処理が変わったのか躍進していた。
意外なのはxz形式でソースコードの圧縮でも利用される中、圧縮率重視の7zipには負けた。

圧縮率と処理速度の両方とも好成績なのがWindows利用されるrar形式だった。
テキストはそこまで圧縮出来なかったが、
バイナリは96.5%近くまで圧縮しつつ処理速度が2分程度という驚異の結果となった。
xz形式で同じ容量まで圧縮すると10分要する事からも、rarの完成度が出てきた結果となる。

Linuxで良く利用されるgzip・bzip2・xzは前回同様にバランスが取れた結果となった。
デファクトスタンダードとして使われる事が多い三つだが、
不得手なく処理出来るからこそ安定した圧縮率と処理速度を誇っていた。

結果をグラフにしたら、LZMA/LZMA2アルゴリズムを使うxz・7zip形式の速度が顕著になった。
その分、圧縮率が高いので処理速度が遅いのは仕方ない部分もあるが、
同種のアルゴリズムなのにxzと7zipで1.5～2.0倍の速度差が出ているのが気になった。

“ns-lab BB”は現行サーバ基盤へ刷新した時にログの圧縮形式をxzに変更したが、
ここまで顕著に速度差が出るなら7zipを試したい気持ちも若干出てきた。
だがkernelソースでも利用されているxzや、根強く認識のあるgzipはまだ現役な上、
Linuxで7zipは使い勝手が悪いのも事実だったりする。
そんな事もあり、当面はgzip・xzの二強と、間を補完するbzip2を使う事になると思われる。

6年前の計測結果から若干変わった結果となったが、デファクトスタンダードは早々変わらないので、
今後もgzip・bzip2・xzの三つがLinuxで使われる事となりそうだった。
でも、利用シーンによっては違う圧縮形式が選択肢になり得る事を把握した上でベストを選びたい。

« 続きを隠す