お家で始める仮想化環境 Proxmox VE クラスタ構築・マイグレーション編

目次

環境

前提として、Proxmoxの基本的な構築が完了している必要があります。
Proxmox環境の構築方法はこちらをご覧ください。

また、今回は2台のノードでクラスタの構成を行います。

クラスタ構成時の注意点

Proxmoxのクラスタは、2台のノードから構成することが出来ます。
しかしながら、HA構成にしたい場合は3台以上のノードが必要になります。

また、一度クラスタに追加したノードの削除について、一度削除したノードを再登録することが出来ません。
Proxmoxを再インストールする必要があります。
(CLIにてProxmoxを再インストールせずに再登録する方法もあるようです)

試しにクラスタを構成する場合は、これらに対して注意が必要です。

クラスタ構成の利点

クラスタを構成すると、各ノードのWebGUIにアクセスする必要が無くなり、単一のWebGUIからクラスタ内のすべてのノードの操作が出来るようになります。
また、マイグレーションが可能になり、NFSなどの共有ストレージ上に配置されたVMであれば、ライブマイグレーションも利用可能になります。

(Proxmoxではこれらの機能はすべて無償で利用できます)

準備

管理用のネットワークとは別に、クラスタ構成に使用するネットワークを設定することが出来ますので、必要に応じてクラスタに使用するNICの設定をしておきます。

クラスタの作成

まず、元となるクラスタの作成を行います。
どのノードで作業してもよいはずですが、今回は「node1」と名のつけたノードで作業します。
この作業は、どれか1つのノードのみの作業でかまいません。

左側のメニューで「Datacenter」を選択し、「Cluster」を選び、クラスタ情報を表示します。

「Create Cluster」ボタンを押します。

クラスタ名を決め、「Cluster Name」に入力します。
この名前は後から変更することが出来ませんので、慎重に決めてください。
また、「Cluster Network」に、クラスタで使用するネットワークを設定します。
複数のリンクを使用することで、Failoverなどが可能になるようです。

入力が完了したら、「Create」を押して、操作が完了するのを待ちます。
「TASK OK」と表示されれば、閉じて問題ありません。

これで、先ほどの画面に作成したクラスタの情報が表示されているはずです。

クラスタへの参加

先ほど「Node1」で作成したクラスタに対して、別のノードを参加させる操作を行います。
今回は「Node2」を参加させます。
複数のノードを参加させる場合は、残りのすべてのノードで同様の操作を行ってください。

まずは、先ほどクラスタを作成した「Node1」上で、クラスタへの参加に必要な情報を取得します。
「Cluster Information」より「Join Information」を押すことで、必要な情報が表示されます。

以下のようなダイアログが表示されますので「Join Information」の中身をコピーします。
左下の「Copy Information」ボタンを利用してコピーが出来るようですが、うまくできない場合は手動でコピーしてみてください。

続いて、「Node2」で作業を行います。
「Datacenter」から「Cluster」より、「Join Cluster」を押します。

以下のようなダイアログが表示されますので、「Information」のところに先ほどコピーした文字列をそのまま貼り付けます。

貼り付けると、「Peer Address」や「Passowrd」などが表示されますので、「Password」にクラスタを作成したノード(今回は「Node1」)のパスワードを入力します。
また、「Cluter Network」の項目で、「Link 0」にて、クラスタに使用するネットワークを選択します。

入力が完了したら、「Join」を押します。

すると、以下のようなダイアログが出て止まってしまいますが、「Node1」の方へ戻り、「Cluster Nodes」に登録したノードが表示されているか確認します。

表示されていれば、このダイアログは閉じてかまいません。

以上で、クラスタへの参加が完了します。
複数のノードを参加させたい場合は、ノード数に応じてこの操作を繰り返してください。

マイグレーション

試しに、クラスタ内でVMのマイグレーションを行ってみます。
今回は「Node1」に存在するVM「TestVM」を「Node2」へマイグレーションしてみます。

移動させたいVMを選択肢、右上の「Migrate」ボタンを押します。

以下のように、移動先のノードを選択するダイアログが表示されますので、「Target Node」の項目で移動先のノードを選択します。

選択したら、「Migrate」ボタンを押します。
すると、マイグレーション処理が開始され、しばらく待つと「TASK OK」と表示されますので、ダイアログを閉じます。

「TestVM」が「Node2」に移動していることが確認できます。

このように、停止中のVMを移動させるマイグレーションは、非常に簡単に行うことが出来ます。

100GbEをテストする 計測編 Mellanox ConnectX-5

Mellanox ConnectX-5 (MCX555A-ECAT)

今回、検証に当たって以下のマシンを2台お借りしたので、100GbEにおいて性能測定ツールが帯域を使用しきれるのか、調べてみました。

詳細
CPU AMD EPYC 7232P 8-Core Processor
Memory DDR4 ECC RDIMM 64GB
NIC Mellanox ConnectX-5 100Gb(InfiniBand/Ethernet) MCX555A-ECAT

目次

準備

今回は、Ubuntu 20.04.1 を使用しました。
Ubuntuに最初から入っているドライバは使用せず、Mellanox公式から取得したドライバを使用することにします。
今回は、MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgzを使用しました。

取得したファイルを解凍します。

$ tar zxvf MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgz
$ cd MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64/

解凍されたディレクトリの中にある、mlnxofedinstallを実行します。

$ ls
common_installers.pl            DEBS    LICENSE                     RPM-GPG-KEY-Mellanox
common.pl                       distro  mlnx_add_kernel_support.sh  src
create_mlnx_ofed_installers.pl  docs    mlnxofedinstall             uninstall.sh
$ ./mlnxofedinstall

実行後、新しいドライバを使用するにはopenibdの再起動が必要な旨のメッセージが表示されますので、指示に従います。

Installation passed successfully
To load the new driver, run:
/etc/init.d/openibd restart
$ sudo /etc/init.d/openibd restart

IPアドレスについて、今回は10.0.0.1/2410.0.0.2/24を使用し、以下のように直結することにします。

10.0.0.1/24 ---------- 10.0.0.2/24

OSインストール時にIPアドレスの設定はしていませんので、 Interface は Down な状態になっています。
そこで Interface を Up にしますが、設定を保存しておく必要はないので今回はipコマンドを使用しました。

$ sudo ip link set enp65s0 up

Inteface にIPアドレスの割り当てを行います。(この場合、該当のインタフェースはenp65s0です)

$ sudo ip addr add <ip> dev enp65s0

DACを接続し100Gbpsでリンクしているか確認します。

$ ethtool enp65s0
Settings for enp65s0:
        Supported ports: [ Backplane ]
        Supported link modes:   1000baseKX/Full
                                10000baseKR/Full
                                40000baseKR4/Full
                                40000baseCR4/Full
                                40000baseSR4/Full
                                40000baseLR4/Full
                                25000baseCR/Full
                                25000baseKR/Full
                                25000baseSR/Full
                                50000baseCR2/Full
                                50000baseKR2/Full
                                100000baseKR4/Full
                                100000baseSR4/Full
                                100000baseCR4/Full
                                100000baseLR4_ER4/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: None BaseR RS
        Advertised link modes:  1000baseKX/Full
                                10000baseKR/Full
                                40000baseKR4/Full
                                40000baseCR4/Full
                                40000baseSR4/Full
                                40000baseLR4/Full
                                25000baseCR/Full
                                25000baseKR/Full
                                25000baseSR/Full
                                50000baseCR2/Full
                                50000baseKR2/Full
                                100000baseKR4/Full
                                100000baseSR4/Full
                                100000baseCR4/Full
                                100000baseLR4_ER4/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: RS
        Link partner advertised link modes:  Not reported
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100000Mb/s
        Duplex: Full
        Port: Direct Attach Copper
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
        Current message level: 0x00000004 (4)
                               link
        Link detected: yes

Speed: 100000Mb/sとなっているので、100Gbpsで正しくリンクアップしていることが確認できました。

計測(MTU1500)

まずは、MTU1500で計測してみます。

iperf3 Single Thread

$ iperf3 -c 10.0.0.1
Connecting to host 10.0.0.1, port 5201
[  5] local 10.0.0.2 port 41020 connected to 10.0.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.24 GBytes  19.2 Gbits/sec    0   1.05 MBytes
[  5]   1.00-2.00   sec  2.25 GBytes  19.3 Gbits/sec    0   1.05 MBytes
[  5]   2.00-3.00   sec  3.47 GBytes  29.8 Gbits/sec  371   1.01 MBytes
[  5]   3.00-4.00   sec  3.44 GBytes  29.5 Gbits/sec    1   1.01 MBytes
[  5]   4.00-5.00   sec  2.82 GBytes  24.3 Gbits/sec    3   1.01 MBytes
[  5]   5.00-6.00   sec  2.68 GBytes  23.0 Gbits/sec    2   1.01 MBytes
[  5]   6.00-7.00   sec  2.65 GBytes  22.8 Gbits/sec    1   1.01 MBytes
[  5]   7.00-8.00   sec  2.65 GBytes  22.8 Gbits/sec    0   1.01 MBytes
[  5]   8.00-9.00   sec  2.65 GBytes  22.8 Gbits/sec    0   1.01 MBytes
[  5]   9.00-10.00  sec  2.65 GBytes  22.8 Gbits/sec    0   1.23 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  27.5 GBytes  23.6 Gbits/sec  378             sender
[  5]   0.00-10.00  sec  27.5 GBytes  23.6 Gbits/sec                  receiver

iperf Done.

23.6 Gbits/sec

iperf3 10 Threads.

$ iperf3 -P 10 -c 10.0.0.1
--<中略>--
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec  181             sender
[  5]   0.00-10.00  sec  3.10 GBytes  2.67 Gbits/sec                  receiver
[  7]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec   17             sender
[  7]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[  9]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec   36             sender
[  9]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 11]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec  185             sender
[ 11]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 13]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec    0             sender
[ 13]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 15]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec   13             sender
[ 15]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 17]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec    0             sender
[ 17]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 19]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec   24             sender
[ 19]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 21]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec   45             sender
[ 21]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[ 23]   0.00-10.00  sec  3.11 GBytes  2.67 Gbits/sec    4             sender
[ 23]   0.00-10.00  sec  3.10 GBytes  2.66 Gbits/sec                  receiver
[SUM]   0.00-10.00  sec  31.1 GBytes  26.7 Gbits/sec  505             sender
[SUM]   0.00-10.00  sec  31.0 GBytes  26.6 Gbits/sec                  receiver

iperf Done.

26.6 Gbits/sec

iperf2 Single Thread.

$ iperf -c 10.0.0.1
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[  3] local 10.0.0.2 port 46778 connected with 10.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  26.5 GBytes  22.8 Gbits/sec

22.8 Gbits/sec

iperf2 10 Threads.

$ iperf -c 10.0.0.1 -P 10
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 1.80 MByte (default)
------------------------------------------------------------
[ 12] local 10.0.0.2 port 46800 connected with 10.0.0.1 port 5001
[  7] local 10.0.0.2 port 46794 connected with 10.0.0.1 port 5001
[  9] local 10.0.0.2 port 46792 connected with 10.0.0.1 port 5001
[ 10] local 10.0.0.2 port 46796 connected with 10.0.0.1 port 5001
[  4] local 10.0.0.2 port 46784 connected with 10.0.0.1 port 5001
[  6] local 10.0.0.2 port 46786 connected with 10.0.0.1 port 5001
[  3] local 10.0.0.2 port 46782 connected with 10.0.0.1 port 5001
[  8] local 10.0.0.2 port 46790 connected with 10.0.0.1 port 5001
[  5] local 10.0.0.2 port 46788 connected with 10.0.0.1 port 5001
[ 11] local 10.0.0.2 port 46798 connected with 10.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[ 12]  0.0-10.0 sec  11.6 GBytes  9.92 Gbits/sec
[  7]  0.0-10.0 sec  7.99 GBytes  6.86 Gbits/sec
[  9]  0.0-10.0 sec  7.15 GBytes  6.14 Gbits/sec
[ 10]  0.0-10.0 sec  11.1 GBytes  9.53 Gbits/sec
[  4]  0.0-10.0 sec  10.8 GBytes  9.26 Gbits/sec
[  6]  0.0-10.0 sec  13.5 GBytes  11.6 Gbits/sec
[  3]  0.0-10.0 sec  7.58 GBytes  6.51 Gbits/sec
[  8]  0.0-10.0 sec  10.1 GBytes  8.63 Gbits/sec
[  5]  0.0-10.0 sec  13.4 GBytes  11.5 Gbits/sec
[ 11]  0.0-10.0 sec  6.85 GBytes  5.88 Gbits/sec
[SUM]  0.0-10.0 sec  99.9 GBytes  85.8 Gbits/sec

85.8 Gbits/sec

表にしてみると以下のようになりました。

計測方法 実測値
iperf3 Single Thread 23.6 Gbits/sec
iperf3 10 Threads 26.6 Gbits/sec
iperf2 Single Thread 22.8 Gbits/sec
iperf2 10 Threads 85.8 Gbits/sec

iperf3よりもiperf2の方が計測時に速度が出ていることが分かります。
この結果は、CRS326-24S+2Q+RMでの40GbEのスループットをテストしてみた!でも同様の傾向がみられました。

計測(MTU9000)

続いて、MTUを9000にして再度計測を行ってみます。

$ sudo ip link set dev enp65s0 mtu 9000

iperf3 Single Thread

$ iperf3 -c 10.0.0.1
Connecting to host 10.0.0.1, port 5201
[  5] local 10.0.0.2 port 41070 connected to 10.0.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  4.29 GBytes  36.8 Gbits/sec   42   1.71 MBytes
[  5]   1.00-2.00   sec  3.49 GBytes  30.0 Gbits/sec    4   1.71 MBytes
[  5]   2.00-3.00   sec  3.56 GBytes  30.6 Gbits/sec    3   1.71 MBytes
[  5]   3.00-4.00   sec  3.57 GBytes  30.7 Gbits/sec    1   1.71 MBytes
[  5]   4.00-5.00   sec  3.57 GBytes  30.7 Gbits/sec    1   1.72 MBytes
[  5]   5.00-6.00   sec  3.29 GBytes  28.3 Gbits/sec    6   1.72 MBytes
[  5]   6.00-7.00   sec  3.39 GBytes  29.1 Gbits/sec    3   1.72 MBytes
[  5]   7.00-8.00   sec  3.39 GBytes  29.1 Gbits/sec   18   1.08 MBytes
[  5]   8.00-9.00   sec  3.33 GBytes  28.6 Gbits/sec    0   1.08 MBytes
[  5]   9.00-10.00  sec  3.37 GBytes  28.9 Gbits/sec    2   1.08 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  35.2 GBytes  30.3 Gbits/sec   80             sender
[  5]   0.00-10.00  sec  35.2 GBytes  30.3 Gbits/sec                  receiver

iperf Done.

30.3 Gbits/sec

iperf3 10 Threads.

$ iperf3 -P 10 -c 10.0.0.1
--<中略>--
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   41             sender
[  5]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[  7]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   24             sender
[  7]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[  9]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   70             sender
[  9]   0.00-10.00  sec  4.24 GBytes  3.64 Gbits/sec                  receiver
[ 11]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   30             sender
[ 11]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[ 13]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   65             sender
[ 13]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[ 15]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   44             sender
[ 15]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[ 17]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   34             sender
[ 17]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[ 19]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   75             sender
[ 19]   0.00-10.00  sec  4.24 GBytes  3.65 Gbits/sec                  receiver
[ 21]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   72             sender
[ 21]   0.00-10.00  sec  4.24 GBytes  3.64 Gbits/sec                  receiver
[ 23]   0.00-10.00  sec  4.25 GBytes  3.65 Gbits/sec   45             sender
[ 23]   0.00-10.00  sec  4.24 GBytes  3.64 Gbits/sec                  receiver
[SUM]   0.00-10.00  sec  42.5 GBytes  36.5 Gbits/sec  500             sender
[SUM]   0.00-10.00  sec  42.4 GBytes  36.4 Gbits/sec                  receiver

iperf Done.

36.4 Gbits/sec

iperf2 Single Thread.

$ iperf -c 10.0.0.1
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 2.13 MByte (default)
------------------------------------------------------------
[  3] local 10.0.0.2 port 46828 connected with 10.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  40.0 GBytes  34.4 Gbits/sec

34.4 Gbits/sec

iperf2 10 Threads.

$ iperf -c 10.0.0.1 -P 10
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 1.90 MByte (default)
------------------------------------------------------------
[ 12] local 10.0.0.2 port 46848 connected with 10.0.0.1 port 5001
[  8] local 10.0.0.2 port 46838 connected with 10.0.0.1 port 5001
[  7] local 10.0.0.2 port 46840 connected with 10.0.0.1 port 5001
[ 11] local 10.0.0.2 port 46846 connected with 10.0.0.1 port 5001
[  5] local 10.0.0.2 port 46834 connected with 10.0.0.1 port 5001
[  6] local 10.0.0.2 port 46836 connected with 10.0.0.1 port 5001
[ 10] local 10.0.0.2 port 46842 connected with 10.0.0.1 port 5001
[  4] local 10.0.0.2 port 46832 connected with 10.0.0.1 port 5001
[  9] local 10.0.0.2 port 46844 connected with 10.0.0.1 port 5001
[  3] local 10.0.0.2 port 46830 connected with 10.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[ 12]  0.0-10.0 sec  8.39 GBytes  7.21 Gbits/sec
[  8]  0.0-10.0 sec  8.72 GBytes  7.49 Gbits/sec
[  7]  0.0-10.0 sec  22.3 GBytes  19.1 Gbits/sec
[ 11]  0.0-10.0 sec  8.59 GBytes  7.38 Gbits/sec
[  5]  0.0-10.0 sec  9.57 GBytes  8.22 Gbits/sec
[  6]  0.0-10.0 sec  21.7 GBytes  18.6 Gbits/sec
[ 10]  0.0-10.0 sec  8.56 GBytes  7.35 Gbits/sec
[  4]  0.0-10.0 sec  9.24 GBytes  7.93 Gbits/sec
[  9]  0.0-10.0 sec  8.87 GBytes  7.62 Gbits/sec
[  3]  0.0-10.0 sec  9.19 GBytes  7.90 Gbits/sec
[SUM]  0.0-10.0 sec   115 GBytes  98.8 Gbits/sec

98.8 Gbits/sec

表にしてみると以下のようになりました。

計測方法 実測値
iperf3 Single Thread 30.3 Gbits/sec
iperf3 10 Threads 36.4 Gbits/sec
iperf2 Single Thread 34.4 Gbits/sec
iperf2 10 Threads 98.8 Gbits/sec

先ほどと同様に、こちらもiperf3よりiperf2の方が計測時に速度が出ていることが分かります。

まとめ

先ほどの結果をまとめて表にしてみると以下のようになりました。

計測方法 MTU 1500 MTU 9000
iperf3 Single Thread 23.6 Gbits/sec 30.3 Gbits/sec
iperf3 10 Threads 26.6 Gbits/sec 36.4 Gbits/sec
iperf2 Single Thread 22.8 Gbits/sec 34.4 Gbits/sec
iperf2 10 Threads 85.8 Gbits/sec 98.8 Gbits/sec

これらの結果を踏まえると、それぞれの計測方法においてMTU9000の方が計測値が速いことから、ジャンボフレームはある程度の効果があると考えられます。
また、iperf2において-Pオプションを使用して並列実行することで、98.8 Gbits/secと100Gbps近い数値が出ています。

iperf2-Pオプションを使用して計測することでソフトウェア側のボトルネックをある程度解消できることは、以前計測を行った際の結果から予想していましたが、せいぜい40Gbps程度が限界だろうと思っていたので、100Gbpsという理論値に近い数値が出たことは予想外でした。

テスト結果が信頼できるかどうかという点については不明ですが、正しい結果であるとすれば、100GbEにおいてもiperf2-Pオプションと併用することで帯域テストを行うことは十分可能なのではないでしょうか。

今回は 100GbE 環境をマシンごと利用できる機会があったので、検証を行ってみました。
本環境で100Gbps出せるという事が確認できました。

40GbE環境や100GbE環境でiperf2iperf3を使用して帯域テストを行う際には、ソフトウェア側がボトルネックになる可能性を考慮する必要があります。

参考になれば幸いです。

オンプレKubernetes(Rancher)環境でCD環境を組んでみた

CD環境を構成したい!

と、突然書いてみたわけですが、経緯を少し振り返ってみます。
経緯なんてどうでもいいという場合は読み飛ばしてください。

こちらで紹介したように、弊宅のオンプレ環境ではKubernetesのクラスタが動いています。
こちらのブログやポートフォリオが乗っている本番環境には、Rancherを使用していますが、更新のたびにデプロイ処理を行っていました。
また、コードはGithubで管理していますので、GithubへPush後、コンテナイメージを作成しローカルのコンテナレジストリにPushしたのち、Rancher側でのPodの更新が必要な状態でした。

そこで、今回は、GithubへPushした後の、コンテナイメージの作成・レジストリへのPush・デプロイまでを自動化してみます。

構成

ざっくり図にしてみると、こんな感じになりました。

Github上のmasterブランチへの変更の検知には、Webhookを使用しています。
当然、Webhookを使用していますので、Rancher自体にグローバルから到達可能である必要があります。
(Githubとの連携作業は、ローカルIPアドレスのみでも行うことが出来ますが、Webhookが機能しなくなります。その場合、Githubのリポジトリ設定からWebhookの宛先を修正してください。)
筆者は、少し変なことをしてWebhookのみグローバルからRancherに到達可能にしています。

コンテナイメージのビルドなどのフローは、Rancher自体が持つPipelineと呼ばれる仕組みを利用し、設定を行っています。
この設定は、RancherのWebGUI上から行うことが出来ます。
作成された設定ファイルは、(今回の場合はGithubに)pushされます。
なお、Pipelineの仕組み自体に、DockerRegistryをホストする機能がありますが、今回はすでにオンプレ環境でレジストリが存在するため、そちらを使用するようにしました。
もちろん、DockerHubなどのレジストリも設定可能です。
このPipelineとしての設定を記したファイルは、.rancher-pipeline.ymlとして保存されます。

デプロイでは、ワークロードの設定を記述したYAMLファイルを用意しておく必要があります。
すでにワークロードがデプロイされている場合には、Rancher上からこのYAMLファイルを取得する事が可能です。
しかし、デプロイ自体には不必要な情報が多く含まれているため、編集を行う必要があります。
内容自体は、当たり前ですが通常デプロイする際に記述するYAMLファイルと同様です。

なお、Kubernetesでは、コンテナイメージのタグが同一のまま(latestなど)configを更新しても、Podは更新されません。
そのため、 ${CICD_EXECUTION_SEQUENCE} などの変数を使用してコンテナイメージのタグを変化させる必要がある点、注意が必要です。
このタグは、クラスタにapplyされる前に置換が行われるため、クラスタにデプロイする際に使用するYAMLファイルにも記述することが出来ます。
つまり、コンテナイメージをビルドする際のタグと、クラスタへのデプロイに使用するYAMLファイル上のイメージタグに変数を使用することで、Podの更新を行うことが出来ます。

Rancher公式のサンプルをいくつか列挙しておきます。
pipeline-example-php
pipeline-example-maven
pipeline-example-go

例えば、ポートフォリオ.rancher-pipeline.ymlはこのような形になっています。
(レジストリのURLが混ざっているため、一部伏せています。)

stages:
- name: DockerBuild
  steps:
  - publishImageConfig:
      dockerfilePath: ./Dockerfile
      buildContext: .
      tag: <レジストリのアドレスやパス>/production/portfolio:${CICD_EXECUTION_SEQUENCE}
      pushRemote: true
      registry: <Rancher上で登録したRegistryの名称>
  when:
    event: {}
- name: Deploy
  steps:
  - applyYamlConfig:
      path: ./deployment.yaml
timeout: 60
notification: {}

.rancher-pipeline.ymlにあるように、フローに失敗した場合や成功した場合に通知を行うこともできるようです。
これにより、デプロイまでのフローを自動化することが出来ました。

余談

そもそも自動化しようとしたきっかけは、業務でGithub Actionsを使用した自動化作業を行ったことでした。
そこで、手元でも本題にあるフローを自動化しようと思い立ったわけです。。
(結局Github Actionsを使用することなく構築しましたが…)

CI/CDについては今後、勉強して行きたいと思います。

リソースモニター bashtop を使ってみる

bashtop

bashtop は、CPUやメモリ・ディスク・ネットワークといったリソースの使用状況や、プロセス一覧などを確認できるCLIツールです。

同種のツールとして、 htop などが挙げられますが、 bashtop の特徴はより多くの情報を表示できる点です。

インストール方法などは、 bashtop のリポジトリをご確認ください。

実行してみる

シェルからコマンドを叩くだけです。

$ bashtop

調子に乗って32C64T環境で実行したからか、表示がずれていますね。

このような形で、CPU・メモリ・ディスクに加えて、プロセス一覧を見ることが出来、さらには、ネットワークの通信量も確認することが可能です。

htop の場合、CPUやメモリの使用状況を確認することは出来ますが、ネットワークの通信量を確認することが出来ませんでしたが、bashtop では、これらの情報を一括で表示できています。

以上、簡単にではありますが、 bashtop の紹介でした。

お家で始める仮想化環境 Proxmox VE 環境構築編

目次

2023/02/12 最新のProxmoxでの変更箇所について解説記事を挟みました。

Proxmox VE とは

Proxmox VE とは、仮想化環境を提供するプラットフォームの1つです。
VM(Virtual Machine)などのホストとして使用できます。
似た目的の製品として、VMWare ESXiなどがあります。
こちらを利用されている方も多いのではないでしょうか。

Proxmox - powerful open-source server solutions
https://proxmox.com/

ちなみに、Proxmox VE は Proxmox Virtual Environment の略です。

筆者は1年以上 Proxmox VE を使用していますが、いずれも安定して動作しています。

Proxmox VE の特徴

大きな特徴として、VMWare ESXiと比較し、ライセンスフリーでほぼすべての機能を利用できる点が挙げられます。
無償版でも、VMWare ESXiのようにVMあたりのコア数の制限はありません。
また、複数のホストをクラスタリングしたり、HA環境、ライブマイグレーションといった機能も無償で利用することができます。
さらに、VMWare ESXiと同様にWebインタフェースを持っていますので、Webブラウザ経由で簡単に管理することができます。
Debianベースで開発されていますので、ホストOS上にRAIDコントローラのドライバなども簡単に導入することができるのも、利点といえるでしょう。
さらに、VMWare ESXiでは早期にCPUサポートが打ち切られるケースがありますが、Proxmox VEでは基本的にLinux Kernelが動作可能なモノであれば動かすことができます。
自宅などで古いハードウェアを利用する際には、有力な選択肢となるでしょう。

VM(Virtual Machine)やLXC(Linux Container)に対応します。

インストール準備

公式サイトより、Proxmox VE のISOイメージをダウンロードしてください。
2020年8月12日時点では、Proxmox VE 6.2 が最新でした。

容量は863MBとなっています。丁度Debianのイメージと同じぐらいですね。

イメージのダウンロードが完了したら、balenaEtcherやddコマンドを利用して、適当なUSBメモリにダウンロードしたイメージを書き込んでください。
ここでは、書き込み手順については省略します。

イメージの書き込みが完了したら、準備は完了です。

インストール

仮想化環境の役割を与えるマシンを用意します。
今回は、以下のマシンを使用しています。
(AMD CPUを使用していますが、既存環境はIntel CPU上でProxmox VEを運用しており、手順に差が無いことを確認しています。)

パーツ 詳細
CPU AMD EPYC 7452 32Core Processor
M/B Supermicro H11SSL-i (Rev2.0)
Memory DDR4 ECC Registered 128GB

なお、利用するマシンのBIOSにて、CPU Virtualizationサポートを有効化しておきます。
Intel CPUの場合はVT-dなど、AMD CPUの場合はSVM Modeなどです。

これらの準備が完了すれば、先ほど作成したUSBメモリをマシンへ接続し、USBからブートします。
以下のような Welcome to Proxmox Virtual Environment と書かれた画面が表示されます

今回は普通にインストールしますので、「Install Proxmox VE」を選択します。
ブートログが流れたのち、以下のようなライセンス同意画面が表示されますので、ライセンスを読み問題が無ければ右下の「I agree」を押します。
なお、これらの操作はキーボードでもマウスでも操作可能です。

同意すると、インストールするターゲットディスクの選択画面が現れます。

今回は /dev/sda にデフォルトの ext4 でインストールします。
ソフトウェアRAIDを構成することも可能ですので、必要に応じてオプションを変更します。

続いて、国やタイムゾーン、キーボードレイアウトなどの設定です。
ここも各自必要に応じて設定します。

続いて、パスワードとE-Mailの設定です。
パスワードは、rootユーザーのパスワードになります。E-Mailも合わせて適時設定します。

続いて、ネットワーク周りの設定です。
ここでは、管理用ネットワークについて設定を行います。
管理用ネットワークとして利用するインタフェースとHostname・IPアドレス等を適切に設定します。

最後に、確認画面が表示されますので、設定に問題が無ければ「Install」を選択し、インストールを開始します。

インストール処理が行われますので、終了するまで待ちます。

インストールが完了すると、右下に「Reboot」と表示されますので、指示に従って再起動します。
なお、再起動中に、インストールに使用したUSBメモリは外しておきます。

再起動が完了すると、Proxmoxの起動メニューが表示されますが、選択しなければ通常起動されます。

起動が完了すると、Webインターフェースへアクセスするための情報(URL)が表示されますので、指示に従ってブラウザからアクセスします。
なお、今回は https://192.168.2.133:8006/ となっています。
(インストール時に設定した管理ネットワークのIPアドレスが使用されます)

ブラウザからWebインタフェースへアクセスすると、SSLエラーが出ますが、自己証明書を使用している為に表示されているだけですので、そのままアクセスを続行します。
ログインを求められますので、インストール時に設定したパスワードなどを使用してログインします。
(ユーザー名のデフォルトは root です。)
言語なども必要に応じて変更します。

ログインすると、「No valid subscription」といったダイアログが表示されますが、そのまま「OK」を押して続行します。
無償版を使用していると表示されますが、無償版のデメリットはこのダイアログが表示されるぐらいなので、我慢しましょう。

以上で基本的な手順でのインストールは完了です。

無償版リポジトリを設定する

インストール直後の初期状態では、有償版のリポジトリが設定されているため、アップデートなどを行うことができません。
そこで、無償版のリポジトリを設定する必要があります。

なお、最新の Proxmox VE ではWebUIから設定可能になりました。
詳細はこちらで解説しています。

Webインターフェースから Proxmox 自体のシェルへアクセス可能なので、そちらから設定を行います。
(もちろん、SSHでのアクセスも可能ですので、お好みの方法で設定を行ってください。)
左側のサイドバーからホストを選択します。今回は「test」となっています。
その後、右上のShellからお好きな方法で接続してください。
今回はコピー&ペーストが使用可能な「xterm.js」を使用します。

起動が完了したら、こちらを参考にリポジトリの設定を変更します。
2020/12/29 情報を上記Wikiの最新情報に更新しました。

/etc/apt/sources.list に無償版のリポジトリを追加

# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription

/etc/apt/sources.list.d/pve-enterprise.list から有償版リポジトリを無効化
(ここではコメントアウトしています)

# deb https://enterprise.proxmox.com/debian stretch pve-enterprise

以上の変更操作が完了したら、アップデートを行います。
アップデートを行うには、2つの方法があります
1、このままシェルからアップデートを行う。
2、Webインタフェースから行う。

1、このままシェルからアップデートを行う。
Proxmox VE はDebianをベースにしていますので、パッケージマネージャとして apt が使用されています。

apt update && apt upgrade -y && apt dist-upgrade -y

2、Webインタフェースから行う。
Webインタフェースで、ホストを選択して「Updates」を開きます。
(画像の赤線部)

更新があるか確認する必要があるので、左上の「Refresh」を押し、パッケージの更新有無を確認します。
「No valid ・・・」ダイアログが出たのち、ログが出ますので、「Task OK」と表示されたら閉じます。
先ほどの画面に、更新のあるパッケージリストが表示されているはずです。

続いて、先ほどのボタンの右側「Upgrade」を押します。
シェルが開いて、Do you want to continue? [Y/n] と聞いてきますので、問題がなければyを入力して続行します。
こちらも、処理が完了したら閉じてOKです。

以上で、パッケージのアップデートが出来るようになりました。

Summary

ネットワークの設定は、ホストを選択した状態で、「Network」から行うことができます。
ストレージの設定は左側のツリートップの「Datacenter」を選択した状態で「Storage」から行うことができます。
ホストごとに設定すると思ってホストを選択した状態でストレージ設定を探してしまうので、注意が必要です。

ISOイメージをアップロードする

VMの作成などに使用するISOイメージのアップロードを行います。
Webインタフェース左側のツリーから「local」を選択します。(対象のストレージを選択しています。)
「Content」から「Upload」を押し、アップロードしたいイメージを選択して「Upload」を押します。

簡単にISOイメージなどをアップロードすることができます。

VMを作成してみる

試してにVM(Virtual Machine)を作成してみます。
Webインタフェース右上から「Create VM」を選択します。

VMを作成するホスト(Node)やID、名前を設定します。

続いて、インストールに使用するISOイメージや、GuestOSの選択を行います。
今回はUbuntu20.04.1を使用するので、以下のように設定しています。

「System」タブは、VMを作成してみるだけなら特に設定する必要はありません。

「Hard Disk」タブでは、ゲストOSが使用するストレージの設定を行います。
保存先やサイズなどを設定します。

「CPU」「Memory」では、ゲストOSに割くリソース量を設定することができます。
ホストOSの持つリソース量を超えないように設定します。

「Network」では、VMに割り当てるbridgeインタフェースの設定をします。初期設定のままだと「vmbr0」しか存在しないので、今回はそれを選択しておきます。
必要に応じて変更してください。

「Confirm」では確認画面が表示されますので、問題が無ければダイアログ右下の「Finish」を押します。

VMの作成が完了すると、Webインタフェース左側のツリーに作成したVMが表示されます。

作成したVMを選択し、右上の「Start」を押すとVMが立ち上がります。
「Console」を押すことでコンソールにアクセス可能です。

コンソールにアクセスすると、VMが立ち上がっているはずです。
(今回はVM上でのOSインストールは行いません)

まとめ

今回は、Proxmox VEの初期セットアップ方法について書いて見ました。
多くの人がVMWare ESXiを使用する中で、Proxmox VEは無償版での機能制限がほぼないのが魅力です。
さらに、VMWare ESXiは早期にCPUサポートをやめますが、Proxmox VEでは基本的にLinux Kernelが動作するCPUであれば利用できます。
自宅などで古いハードウェア上で利用したい場合には大きなメリットとなるでしょう。

今回は初期セットアップ方法のみの解説でした。
ストレージやネットワーク周りの設定、クラスタリングなどについても、需要がありそうであれば書いてみたいと思います。

自宅インフラ紹介2020年6月 論理構成編

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。
(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)

1年ほど前の構成はこちら
最近書いた物理構成はこちら

指針

これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。
しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。
そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。
また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。
(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)

Server Hardware

本構成では、物理サーバを3台使用しています。
うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。

Hypervisor for Virtualization

Hypervisor には引き続き proxmox を利用します。
VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。

Infrastructure with kubernetes

物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。
また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。
これらの物理サーバは 10GbE 2本で接続されています。
さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。
HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。

Registry for Container

Docker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。
また、これらのレジストリは kubernetes が動くマシンとは独立し、ストレージサーバ上の仮想マシンで動作させています。
kubernetes クラスタ内に配置しなかったのはストレージサーバ上で動作させるほうがストレージ的に都合が良かったためです。
適当なマシンが手に入れば引っ越し予定ですので、それと同時に kubernetes クラスタ内に配置するかもしれません。
このあたりはまだ詰めきれていない状態です。

HTTP and HTTPS Traffic

外部からのHTTP(HTTPS)トラフィックは、Nginx Reverse Proxy を使用して Ingress Load Balancer へ流しています。
ルータからのフォワーディングは 1IP に向けることしか出来なかったので、間に Nginx を挟み Ingress が動く複数のワーカーへ通信を分散しています。
手元の機材では、これ以外の方法が思いつきませんでした

Redundancy and Scalability

構成上、 Nginx や Registry が単一障害点となっていますが、 kubernetes クラスタについては物理・論理の両方での冗長性を確保しています。
例えば、物理的にサーバをメンテナンスする際にも、もう一方のサーバでサービスは動き続けます。
また、ワーカーの動く仮想マシンの1つをシャットダウンしたとしても、サービスは動き続けることが出来ます。
さらに、水平方向へのスケーリングも容易に行うことができ、これらは Horizontal Pod Autoscaler によってオートスケーリングされます。
個人レベルでは全く意味がないですが、ある程度の冗長性とスケーラビリティを実現しました。
これで気軽にサーバの電源を落とせます

まとめ

今回、自宅ラックで構成した環境は、kubernetes をメインとしました。
それに付随して、スケーラビリティを確保することができ、ラックのメンテナンスが容易になりました。
kubernetes の検証も兼ねて構成したものですので、構成した本番環境以外で別途クラスタを構築し、今後の学習に利用する予定です。
眠くなってきたので、今回はこのあたりで終わっておきます。

Docker Private Registryを構築しDashboardを利用する

Docker Registryをプライベートで利用したい

Docker Hub には、Docker イメージをアップロード出来る機能がありますが、アップロードしたイメージは有料会員で無い限りすべてパブリックに公開されます。
つまり、Docker Hub 上においてプライベートなレジストリを利用するには、有料会員となる必要があるわけです。
しかしながら、個人利用においては自身で作成したイメージをパブリックに公開したくないことも多々あります。
そこで、レジストリを自身でホスティングする方法で、自分だけの Docker Registry を構築してみます。

本記事は、自宅オンプレ環境にイメージを展開するためのレジストリを構築するという目的で、TLS等での通信に必要な証明書については触れません。

Docker Private Registry をDocker上で実行する

Docker Private Registry 自体のイメージは、Docker Hub 上で発見することができます。
また、以下のようにコマンドを利用しても検索を行うことができます。

$ docker search registry
NAME             DESCRIPTION                                     STARS       OFFICIAL       AUTOMATED
registry         The Docker Registry 2.0 implementation for s…   2984        [OK]     

事前にイメージを手元にダウンロードしておきたい場合は、pull オプションを利用してください。

$ docker pull registry

また、これらの手順を行わなくとも以下のコマンドを実行することで、手元にイメージがない場合は自動的にダウンロードされます。
なお、本記事では、registry:latest を使用し、レジストリ用のポートとしてホストのポート5000番をbindしています。

$ docker run -d -p 5000:5000 --restart always --name registry -v /mnt/docker/registry:/var/lib/registry registry

ここでは、Dockerを実行しているホストOS上の /mnt/docker/registry ディレクトリを、コンテナ上の /var/lib/registry にマウントしています。
これは、コンテナを再起動したりした場合でも レジストリにアップロードしたイメージを保持するために必要です。
必要に応じてホストOS側のディレクトリの作成を行ってください。
docker psコマンドを用いて実行状態を確認することができます。

$ docker ps
CONTAINER ID    IMAGE       COMMAND                  CREATED             STATUS              PORTS                    NAMES
26d11328cef9    registry    "/entrypoint.sh /etc…"   16 seconds ago      Up 14 seconds       0.0.0.0:5000->5000/tcp   registry

なお、必要に応じてDockerを実行しているホストOS側のFirewallを適切に設定してください。
本記事ではufw等の設定は省略します。

Docker Image を利用する側の設定

Docker Image をアップロードする際、デフォルトではTLS等の暗号化通信において、適切に暗号化されたホストとのみ通信を行うような設定になっています。
しかしながら、今回はTLS等の暗号化通信を使用しませんので、レジストリのホストが信頼できるホストであるとして、設定を行う必要があります。

Docker Image をアップロードするマシンにおいて、以下のファイルを編集します。
(必要に応じて管理者権限で実行してください)

$ nano /etc/docker/daemon.json

このファイルに、以下の記述を追加します。
この例では、レジストリを構築したホストのIPアドレスを 192.168.1.10 と仮定しています。

{
  "insecure-registries" : ["192.168.1.10:5000"]
}

Docker Image をアップロードしてみる

ここでは、Docker Hub 上の例を引用し、Ubuntuのイメージを構築したレジストリにアップロードしてみます。
(適時、IPアドレス・ポート番号は変更してください)

$ docker pull ubuntu
$ docker tag ubuntu 192.168.1.10:5000/ubuntu
$ docker push 192.168.1.10:5000/ubuntu

簡易的なWeb Dashboard

docker-registry-frontendは、どのようなイメージがレジストリ上に存在するか確認することが出来るWebインタフェースです。

利用するには、以下のようにコマンドを実行します。
(適時、IPアドレス・ポート番号は読み替えてください)

$ docker run -d -e ENV_DOCKER_REGISTRY_HOST=192.168.1.10 -e ENV_DOCKER_REGISTRY_PORT=5000 -p 8080:80 konradkleine/docker-registry-frontend:v2

なお、レジストリのホストIPアドレスとして、localhost を用いることはできませんのでご注意ください。

docker ps コマンドを利用して、コンテナが実行されているか確認することができます。
(ここでは、レジストリとWebインタフェースを同じホストで実行しています)

$ docker ps
CONTAINER ID    IMAGE                                      COMMAND                  CREATED           STATUS          PORTS                           NAMES
313bf15a690e    konradkleine/docker-registry-frontend:v2   "/bin/sh -c $START_S…"   5 seconds ago     Up 2 seconds    443/tcp, 0.0.0.0:8080->80/tcp   wonderful_williams
26d11328cef9    registry                                   "/entrypoint.sh /etc…"   21 minutes ago    Up 21 minutes   0.0.0.0:5000->5000/tcp          registry

コンテナが実行されていれば、ブラウザ上から http://192.168.1.10:8080/ とすることでWebインタフェースにアクセスできるはずです。

今回は、プライベートな Docker Registry を構築し、簡易的なWebインタフェースを試しました。

本記事を執筆中に、別途レジストリに使えそうなものを発見したので、余裕があればそちらも試してみようと思います。

Western Digital Ultrastar DC SS200 SAS SSD(12Gbps)を手に入れたのでベンチマークなど

Westarn Digital Ultrastar DC SS200 SAS SSD

名前長いですね

こちらの800GBモデルをBrand Newで手に入れたので、軽くベンチしてみました。

SAS接続モデルですので、通常のPC等のマザーボードに搭載されているSATAポートでの利用はできません。
基本的なスペックは以下のとおりです。

  • SAS 12Gb/s
  • 15nm MLC NAND
  • MTBF 2.5M Hours

(メーカーのSpecificationより)
3年ほど前の製品ですので、今時のSSDと比べると見劣りする部分はありますが、安かったので手に入れてみました。

ベンチマーク

SAS接続モデルですので、対応したデバイスを用いました。
今回はHPEのDL380 Gen10サーバを使用し、RAIDコントローラはHBAモードとしました。

SAS 12Gb/sでの接続ですので、シーケンシャルについてはバス幅の理論値近くまで出ている事が読み取れます。
ランダム4KなどはNVMe SSDには叶いませんが、SAS12Gbpsに対応したホットスワップベイを持つサーバにて使用する予定ですので、NVMeベイやSecondary CPUを手に入れるコストを考えると、SATAと比較してもバランスが良いと言えると思います。

時間がなく簡単なベンチしかできていませんが、12Gb/s接続のSAS SSDに興味のある方の参考になれば幸いです。

自宅環境紹介 2020 5月編

色々と機材更新やらがありましたが、1年ほど書いていないなと思ったので、書いてみることにしました。
前半は機器類の紹介、後半は構成についてです。

自宅36Uラック

私は一人暮らしをしている学生ですが、自宅に36Uラックを設置しています。
その様子を先に。

サーバ

サーバ機器はラック下部にマウントしています。
重量のある機器はできるだけラック下部へ設置し、ラック自体の重心を下げるように努めています。
自宅のワンルームに設置していますから、地震等でラックが倒壊する可能性をできるだけ抑えるのが目的です。

現在、以下のようなサーバがあります。

名称 CPU RAM
HP DL380e Gen8 Intel Xeon E5-2420v2 64GB
HP DL380p Gen8 Intel Xeon E5-2640v2 x2 128GB
HPE DL380 Gen10 Intel Xeon Silver 4208 128GB
HPE DL380 Gen10 Intel Xeon Bronze 3104 16GB
自作 AMD EPYC 7452 32-Core Processor 128GB

ネットワーク

ネットワーク機器は主にラック上部にマウントしています。
機器類の管理ネットワークは1GbEで構成し、ストレージ周りは10GbEとしています。
使用しているスイッチには40GbEポートがありますから、将来的に40GbEを利用する予定です。
(スイッチの紹介、検証等は別途記事にしていますので、アーカイブから御覧ください。)

さらに、光ファイバーを2回線引き込んでいます。

また、OpenVPNを用いたSite-to-Site VPNによって、VPS及び別のリージョンに設置した機器類について、接続を行っています。
各リージョン間の経路情報の交換は、BGPを用いて行っております。

電源

夏場のゲリラ豪雨等の一時的な停電・電圧降下に対応するため、1200VAのUPSを1台設置しています。
昨年夏の稼働回数は、瞬間的な電圧降下によって15回ほど作動しましたので、重要な役割を担っています。

また、15Aのブレーカを搭載したサーバラック用にコンセントバーを背面に設置しております。

構成とか

現在は、TrueNAS(FreeNAS)を用いたネットワークストレージのみが稼働している状況です。

今まではProxmoxを用いた仮想化環境をメインにしておりましたが、先日まで検証を実施していたKubernetesを用いたコンテナ環境を用いて、再構築する予定です。
必要なパーツが揃い次第、取り掛かる予定です。

また、これらの環境構築が完了すれば、再度このブログや、ホームページ等を自宅でのホスティングに戻す予定です。

ZabbixやGrafanaを用いた監視環境も確立する予定ですので、現在予定している環境の構築が完了すれば、ネットワーク面も含めた構成などを書き起こしたいと思います。

AMD EPYC + 2U + 本格水冷での稼働状況

性能及び冷却性能テスト編

前回、AMD EPYC Processor で2U本格水冷サーバを組んでみた。という記事を書きました。
今回はその性能テスト編になります。

およそ1か月近くたち、その間 Rosetta@Home 稼働のために、フル負荷で連続1か月ほど稼働させておりましたので、その評価と合わせてお届けします。
(Linux環境で運用したので、Windows系のベンチマークを取るのがめんどくさくて、本記事の投稿が遅れました。)

その前にタスクマネージャーの図でも。

どうやら、Windows10のタスクマネージャーはそうスレッド数が64以上になると、いくらウインドウを大きくしたところでチャートは表示されないようですね。
48スレッド環境では全スレッドチャートが表示されていたので。

Cinebench R20

CPUベンチの定番といえばこれではないでしょうか。

Temperature

ベンチ中の温度は40度以下でした。

EPYCにはプロセッサダイが4つありますので、4ノードの温度が表示されています。
なお、温度取得にはHWMonitorを利用しております。

Rosetta@Home

こちらは明確なスコア等は無いので、評価のしようがないところですが、安定して1か月ほど動作しておりました。

評価

水冷での冷却性能や、静音性について。

本サーバ機を2Uサイズながら水冷としたのには、主に2つの目的がありました。
1つは、静音化です。
通常、2Uサイズのサーバ機では、CPUやその他コンポーネントを十分に冷却する必要があるためにファンが高速回転し、かなりの騒音となります。
しかしながら、寝室にサーバラックがありますので、出来る限り静音化しなければ安眠の妨げとなります。
もう1つは、冷却性能の向上です。
2Uサイズという非常に薄い空間において冷却性能を担保するには、クーラントによって熱源を移動させ、より大きなヒートシンク(今回はラジエータ)で冷却することです。

まず、静音化について。
本サーバ機においては、性能や発熱量に対して非常に騒音を小さくすることに成功しています。
それなりに音はしますが、扇風機の強運転よりは少し静かなぐらいです。

もう1つ、冷却性能について、先ほど示したように最大負荷時でもCPU温度は40度程度でした。
室温は25度程度、アイドル時26度ですので、冷却性能は非常に高いといえるでしょう。
なにせCPUはTDP155Wですから。

省電力性

Zen2アーキテクチャを採用したEPYCという事で、電力性能の方も気になっておりました。
結論から言いますと、性能に対する消費電力はとても優れたものです。
これだけの性能がありながら、フル負荷状態でシステム全体の使用電力(PDU読みです)は200W以下と、中古サーバばかりを扱ってきた自分としては考えられないような性能です。
例えば、Xeon E5 v3世代のCPUを2基搭載したサーバでは、フル負荷時にはシステム全体で400W近い消費電力でした。

総評?

今回のマシンのパーツ台等はおよそ25万円ほどとなりました。
金額に対してはかなり性能の良い、安定したマシンを組めたと思います。
唯一問題となるのが、水冷化したことで、空冷と比べてより頻度の高い定期的なメンテナンスが必要となることです。
放置しているとクーラントの漏れなどの問題が起きやすくなりますから。

手に入りやすい安価なプロセッサではありませんが、Zen2アーキテクチャのEPYCプロセッサはかなりお勧めできるものだと思います。
(おそらくThreadripper 3970Xあたりの方が手に入りやすいと思いますが。)

もうちょっと真面目に書こうと当初は思っていたのですが、かなり雑になってしまいました。

About

インフラエンジニア
インフラ系の技術を中心に紹介・解説しています。

お問い合わせはTwitter DMまで

Privacy Policy

About Me

Recommends

Archives