サーバの監視でIPMI2.0準拠のマネージメントコントローラを利用する

当社のサーバ/ワークステーション製品の多くで、IPMI2.0準拠のマネージメントコントローラを利用出来ます。

マネージメントコントローラはOSとは独立に動作し、CPU温度、ファン回転数の監視したり、リモートでサーバの電源制御などができ、専用LANポート（もしくは、共用LANポート）を介して利用します。

専用LANポートには、サーバ背面のI/Oシールドに”監視”と表記されたシールが貼っています。(ただし、シールを貼ることが出来ない製品には貼っておりません。)

マネージメントコントローラを利用するには、動的もしくは静的にIPアドレスを割り当てて利用します。また、各種IPMIソフトウェアに対応していますので、ソフトウェア(※1)をインストールすれば、ターミナルからも利用出来ます。

◎ ターミナルで状態を確認

# ipmitool sdr list

System Temp | 37 degrees C | ok
Peripheral Temp | 45 degrees C | ok
CPU Temp | 0 unspecified | ok
FAN 1 | disabled | ok
FAN 2 | 1050 RPM | ok
FAN 3 | disabled | ok
FAN 4 | disabled | ok
FAN A | 3075 RPM | ok
Vcore | 0.76 Volts | ok
3.3VCC | 3.39 Volts | ok
12V | 11.98 Volts | ok
VDIMM | 1.52 Volts | ok
5VCC | 5.22 Volts | ok
-12V | -11.71 Volts | ok
VBAT | 3.10 Volts | ok
VSB | 3.33 Volts | ok
AVCC | 3.39 Volts | ok
Chassis Intru |0 unspecified | ok

◎ イベントをsyslogへ出力

ipmievdを用いるとipmiのイベント出力をsyslogにも出力することが出来ます。

# service ipmievd start

テストイベントを発生させ、syslogへの出力を確認します。

# ipmitool event 1
Sending SAMPLE event: Temperature – Upper Critical – Going High
0 | Pre-Init Time-stamp | Temperature #0x30 | Upper Criti

# tail /var/log/messages
～
Jul 2 15:45:33 less01 ipmievd: Temperature sensor – Upper Critical going high
Jul 2 15:45:36 less01 ipmievd: Temperature sensor – Upper Critical going high
～

※1 CentOS6.5でのツールのインストールを例として紹介します。

A OpenIPMIとOpenIPMI-toolsをインストールします。

# yum install OpenIPMI OpenIPMI-tools

B ipmiを起動させます。

# service ipmi start
Starting ipmi drivers: [ OK ]

C ipmiの起動を確認します。

# service ipmi status
ipmi_msghandler module in kernel.
ipmi_si module in kernel.
ipmi_devintf module loaded.
/dev/ipmi0 exists.

D ipmievdを起動させます。

# service ipmievd start
Starting ipmievd: [ OK ]

E ipmievdの動作を確認します。

# service ipmievd status
ipmievd (pid 2753) を実行中…

F ipmiとipmievdをOS起動時に開始するように設定します。

# chkconfig | grep ipmi
ipmi 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ipmievd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

# chkconfig ipmi on
# chkconfig ipmievd on

ZFS on Linuxの動作検証

先日、POWER MASTER NAS S9524での、OpenMediaVault動作確認を依頼された時のこと、…..。

OpenMediaVaultは Debian 6.0 (Squeeze)ベースのOSなので、Debian 6.0 (Squeeze)で動作実績のあるPOWER MASTER NAS S9524でも、動作することは予想出来ましたが、念の為に動作確認を行いました。同時にZFS on Linuxも動作検証を行いました。

OpenMediaVaultへのZFS on Linuxのインストールについては、Debian用ZFS on LinuxをOpenmediavaultフォーラムで紹介されていた方法で、インストール可能でした。しかし、ウェブベースの管理システムへの統合がされていないので、まだ、ウェブブラウザからはZFSボリュームを管理出来ない。ZFSは高性能なだけに、残念。

FreeNASでは以前から統合されているので、NAS専用OSですぐにでもZFSを利用したい方は、FreeNASをご検討ください。Openmediavaultには、今後に期待です。

ZFS on Linuxは、Debian 以外のLinuxディストリビューションにも対応していて、CentOSやUbuntuなどでも利用出来ます。現在(2014/07/01)、ZFS on Linuxのバージョンは0.6.3ですが、0.6.1リリース時にはデスクトップからスーパーコンピュータまで展開出来る重要な節目に達したとアナウンスされていました。

管理しやすいデバイス名(※ 1)をつけたり、アドバンスドフォーマットディスクを利用するときにはセクターサイズ指定(※ 2)を気をつければ、使えます！！

※ 1
通常、リムーバブルHDDトレイには番号が表記されているので、/etc/zfs/vdev_id.confを編集してデバイス名とリムーバブルHDDトレイの番号を紐付ければ、HDDの管理をしやすくなる。

# vi /etc/zfs/vdev_id.conf
alias HDD0 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:1:0
alias HDD1 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:2:0
alias HDD2 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:3:0
alias HDD3 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:4:0

※ 2
アドバンスドフォーマットディスクを使う時には、セクターサイズを指定して、zfsボリュームを作成する。

# zpool create -o ashift=12 tank raidz HDD0 HDD1 HDD2 HDD3

(4096セクターを利用したい場合には、 -o ashift=12 (2の12乗)を追加する。)

最後に、POWER MASTER NAS S9524で、Openmediavault 0.5.49の動作を確認出来ました。

HAクラスタ・NFSサーバでSTONITH機能の動作検証 (スプリットブレイン阻止)

POWER MASTER Server S4200には、3.5インチを4台と2.5インチを1台搭載でき、LANポートを4つとIPMI2.0準拠のマネージメントコントローラ用LANポートを1つ備えています。

S008 ラックマウント キットを使うと、1UスペースにPOWER MASTER Server S4200を2台搭載出来るので、HAクラスタ・NFSサーバを構築し、障害時の動作確認を行いました。

◎ 環境

ディスク構成

  • 120GB SSD x1台 (CentOS6.5 x86_64をインストール。)
  • 4TB HDD x4台 (ソフトウェアRAID5を構築。)

ネットワーク

  • bond0 (eth0とeth1でbond0を設定。)
  • eth2,eth3 (死活確認用。eth3はDRBD同期用も兼ねる。)
  • IPMIポート (STONITH機能で利用。)

HAクラスタ用ソフトウェア

ネットワーク構成図

想定した故障は、LANポート故障により2台のサーバ間で死活確認が出来なくなった場合で、その際、STONITH機能により実行されるスタンバイサーバ再起動の確認です。

構築したクラスタは、アクティブ/スタンバイ型のHAクラスタです。各サーバのeth2ポートとeth3ポートを利用して死活確認を行っています。

片方のサーバのeth2ポートとeth3ポート、server1のeth2ポートとserver2のeth3ポートなどいくつか組み合わせパターンが考えられますが、eth2ポートとeth3ポートが同時に正常に動作しなくなると、死活確認が出来なくなります。

死活確認が出来なくなっているだけで、アクティブサーバは停止しておらず、NFSサービスが継続して動作しています。

スタンバイサーバは、アクティブサーバが停止したと判断して、アクティブサーバへの昇格しようとします。もし、昇格するとサービスが二重起動するスプリットブレインが起きてしまいます。

スプリットブレインを防ぐために、STONITH機能によりアクティブサーバがスタンバイサーバを再起動させます。

以下は、pacemakerのCRM設定(一部)です。

～
primitive prmHelper1-1 stonith:external/stonith-helper ¥
params priority=”1″ stonith-timeout=”80s” hostlist=”server1″ dead_check_target=”IP addresses” run_standby_wait=”yes” standby_check_command=”/usr/sbin/crm_resource -r res_IPaddr2_1 -W | grep -q `hostname`” ¥
op start interval=”0s” timeout=”60s” ¥
op monitor interval=”10s” timeout=”60s” ¥
op stop interval=”0s” timeout=”60s” ¥
meta target-role=”started”
primitive prmIpmi1-2 stonith:external/ipmi ¥
params priority=”2″ stonith-timeout=”60s” userid=”ユーザーID” passwd=”パスワード” ipaddr=”IP address” hostname=”server1″ interface=”lanplus” ¥
op start interval=”0s” timeout=”60s” on-fail=”restart” ¥
op monitor interval=”3600s” timeout=”60s” on-fail=”restart” ¥
op stop interval=”0s” timeout=”60s” on-fail=”ignore” ¥
meta target-role=”started”
primitive prmMeatware1-3 stonith:meatware ¥
params priority=”3″ stonith-timeout=”600″ hostlist=”server1″ ¥
op start interval=”0s” timeout=”60s” ¥
op monitor interval=”3600s” timeout=”60s” ¥
op stop interval=”0s” timeout=”60s” ¥
meta target-role=”started”
group grpStonith1 prmHelper1-1 prmIpmi1-2 prmMeatware1-3
location loc-grpStonith1 grpStonith1 ¥
rule $id=”loc-grpStonith1-rule” -inf: #uname eq server1
～

簡単に設定した内容をまとめると、

  1. どちらのサーバがアクティブサーバであるか判定。(stonith:external/stonith-helperを利用。）
  2. アクティブサーバがスタンバイサーバを再起動させる。(stonith:external/ipmiを利用。)
  3. stonith:external/ipmiによりスタンバイサーバが再起動しない場合、サーバ管理者による再起動を求める。(stonith:meatwareを利用。)

となります。

◎ 動作確認

  1. server1側で、eth2ポートとeth3ポートに取り付けられているLANケーブルを抜く。(これにより死活確認が出来なくなります。)
    2.
  2. crm_monコマンドで、server2の再起動を確認。
    3.

アクティブサーバのeth2ポートとeth3ポートからLANケーブルを抜き取っても、STONITH機能によりスタンバイサーバの再起動が確認出来ました。また、HAクラスタ・NFSサービスも継続して動作していることを確認出来ました。

なお、実際に障害が起きた場合、故障箇所の特定には、サーバの動作ログなどの確認が必要となります。

SSDキャッシュ(flashcache)の効果をベンチマークソフトIOzoneで検証してみました

ミニタワー型のシステムPOWER MASTER NAS M8170へは最大2台の2.5インチHDD/SSDの追加搭載が可能で、2.5インチHDD/SSDを追加するとOS用ドライブ、SSDキャッシュ用などに用途に合わせて色々な使い方が出来ます。

POWER MASTER NAS M8170へSSDキャッシュを追加した場合の効果を簡単に調べてみました。

SSDキャッシュには色々な種類があり、ここでいくつかの例を紹介しています。用途や求める性能、予算により選択することが出来ます。

  • RAIDコントローラやS-ATAコントローラへSSDを取り付ける方法(LSI CacheCade、HighPoint Rocket Hybrid)
  • Intel製チップセットの機能を利用する方法(Intel Smart Response Technology)
  • ソフトウェアのみでSSDキャッシュとして利用する方法(flashcache)

POWER MASTER NAS M8170標準構成では、NAS専用OS「FreeNAS」をインストールしており、FreeNASでもSSDキャッシュを利用出来ます。
用途に応じてOSを変更することも出来るので、今回、CentOS6.5へ変更しFlashcacheを利用しました。

Flashcacheのバージョンは、昨年秋に公開されたバージョン3系最新版です。
https://github.com/facebook/flashcache/

◎ 検証で利用した環境

POWER MASTER NAS M8170には3.5インチHDDを4台搭載出来るので、HDD1にはOSをインストールし、HDD2～HDD4でソフトウェアRAID5構築(EXT4でフォーマット、/mntへマウント)しました。
2.5インチHDD/SSDの追加スペースにはSSDを1台取り付け、ソフトウェアRAID5ボリュームのSDDキャッシュとして設定しました。(キャッシュモードはwriteback、キャッシュサイズは40GBで構築しました。)

  • Xeon E3 1230V3
  • メモリ　4G
  • HGST HDS723020BLA642 x1個 (OSインストール)
  • Intel 520 x1個(キャッシュ用SSD)
  • HGST HDS723020BLA642 x3個 (ソフトウェアRAID5)
# mdadm –create /dev/md0 –level=5 –raid-devices=3 /dev/sd[cde]
# mkfs.ext4 /dev/md0
# flashcache_create -p back -s 40g cachedev /dev/sdb /dev/md0
# mount /dev/mapper/cachedev /mnt

falashcache設定後、ベンチマークソフトIOzoneでRandom Read / Random Write を計測してみました。

# iozone -I -i 0 -i 2 -s 1024 -r 4 -f /mnt/test_file1
# iozone -I -i 0 -i 2 -s 16382 -r 4 -f /mnt/test_file2

IOzoneでは指定ファイルサイズまで、指定レコードサイズで繰り返し読み込み/書き込みを行いますので、上記のコマンドでは、

  • 4Kレコードをファイルサイズ1024kになるまで繰り返す、
  • 4Kレコードをファイルサイズ16382kになるまで繰り返す、

動作が行われます。

◎ 結果
Random Writeでは、”flashcacheあり”の場合/”flashcacheなし”の場合とで顕著な差がみられました。
Random Readでは、ファイルサイズ1024kの場合で”flashcacheあり”の方が速い結果となりましたが、ファイルサイズ16382kの場合では”flashcacheなし”の場合とほぼ同じ結果となりました。
flashcacheを利用していても、16382kファイルサイズ/4kレコードサイズのRandom Readでは、ハードディスクから読み出しがされていたと思われます。

簡単な検証でしたが、flashcacheを利用するとSSDキャッシングの効果により速度アップがみられました。ただ、読み書きするファイルサイズ/レコードサイズによってはSSDキャッシュの効果がみられない場合もありました。利用するアプリケーションでSSDキャッシュの効果がみられるか検証が必要かと思います。

IPFire でWi-Fiワイヤレスルータを作成してみました

前回のブログで紹介したファイアーウォールIPFireへUSB無線LANアダプタを取り付けると、ワイヤレスルータとしても動作させることが出来ます。
Power Master Appliance B6301へUSB無線LANアダプタを取り付け、Wi-Fiワイヤレスルータ化させてみました。

◎ 検証で利用した環境

・IPFire 2.13 core update 75
http://www.ipfire.org/
・USB無線LANアダプタ
IO-DATA WN-G300UAと、アキバでなんと300円で売られていたPLANEX GW-USEco300
・Power Master Appliance B6301
http://www.systemworks.co.jp/pma_b630x.php

◎ 手順

  1. USB無線LANアダプタを認識させる
  2. ワイヤレス接続管理ツールhostapdのインストール
  3. 無線LANの設定
  4. クライアントの接続

１　USB無線LANアダプタを認識させる

対応リストに掲載されていなかったので、自動的に認識されるかドキドキしましたが、Power Master Appliance B6301へUSB無線LANアダプタを接続するだけで、認識させることが出来ました。
試される場合には、念のために確認を。
http://wiki.ipfire.org/en/hardware/networking#usb_wlan-adapter

IO-DATA WN-G300UAの場合、

# lsusb
～
Bus 001 Device 002: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
～

PLANEX GW-USEco300の場合、

# lsusb
～
Bus 001 Device 003: ID 2019:ab2b PLANEX GW-USEco300 802.11bgn Wireless Adapter [Realtek RTL8192CU]
～

カーネルモジュールrtl8192cu.koも自動的に読み込まれていました。

# lsmod
～
rtl8192cu 58304 0
rtl8192c_common 32327 1 rtl8192cu
rtlwifi 56726 1 rtl8192cu
mac80211 257216 3 rtl8192cu,rtl8192c_common,rtlwifi
sch_fq_codel 7632 5
cfg80211 163143 2 rtlwifi,mac80211
rfkill 12036 1 cfg80211
compat 11070 5 rtl8192cu,rtlwifi,mac80211,sch_fq_codel,cfg80211
～

両アダプタ共に、 コントローラチップRealtek RTL8192CUを使っている様でしたので、検証は、IO-DATA WN-G300UAで進めました。
USB無線LANアダプタがPower Master Appliance B6301へ認識されたことを確認後、そのアダプタをBLUE0へ割り当てました。（割り当てるには、setupコマンドより行っています。）

2　ワイヤレス接続管理ツールhostapdのインストール

Webブラウザ管理画面中の上部メニュー　IPFire -> pakfireをクリックすると、下の様な画面が表示され、
追加したいアドオンhostapdをポインタで選択し、”＋”ボタンを押してインストールしました。

3　無線LANの設定

アドオンhostapdをインストール後、Webブラウザ管理画面中の上部メニュー　IPFire -> pakfireをクリックすると、sidemenuの中にWLanAPが追加されました。WLanAPをクリックすると、下図の様な画面が表示されます。

WLan settimgs項目を設定し保存すると、Power Master Appliance B6301をワイヤレスルータとして動作させることが出来ました。

4　クライアントの接続

Webブラウザ管理画面中の上部メニュー　network -> DHCP Serverを選択して、BLUE Interface でDHCPサーバを動作させた後、上部メニュー firewall -> BLUE AccessからクライアントのMACアドレスを設定しました。

以上の操作で、クライアントでファイアーウォールの外にアクセス出来ました。