最大128コアのAmpere Altra/Altra Maxプロセッサ(ARMv8.2+ベース)対応のフロントI/O、省スペース(奥行:449mm)2Uラックマウントサーバ。
CPUは Ampere Altra Maxシリーズ も選択できます。
最もグレードが高いCPUモデル M128-30 は、128コア 3.0GHz TDP 250W となります。
メモリは DDR4-3200 RDIMM対応 で最大 4TB まで搭載可能です。
対応OSは現時点では Linux のみとなっています。
以上
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サーバを構築し、障害時の動作確認を行いました。
◎ 環境
ディスク構成
ネットワーク
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 ～ |
簡単に設定した内容をまとめると、
となります。
◎ 動作確認
|
|
アクティブサーバのeth2ポートとeth3ポートからLANケーブルを抜き取っても、STONITH機能によりスタンバイサーバの再起動が確認出来ました。また、HAクラスタ・NFSサービスも継続して動作していることを確認出来ました。
なお、実際に障害が起きた場合、故障箇所の特定には、サーバの動作ログなどの確認が必要となります。
ミニタワー型のシステムPOWER MASTER NAS M8170へは最大2台の2.5インチHDD/SSDの追加搭載が可能で、2.5インチHDD/SSDを追加するとOS用ドライブ、SSDキャッシュ用などに用途に合わせて色々な使い方が出来ます。
 |
 |
POWER MASTER NAS M8170へSSDキャッシュを追加した場合の効果を簡単に調べてみました。
SSDキャッシュには色々な種類があり、ここでいくつかの例を紹介しています。用途や求める性能、予算により選択することが出来ます。
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で構築しました。)
| # 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では指定ファイルサイズまで、指定レコードサイズで繰り返し読み込み/書き込みを行いますので、上記のコマンドでは、
動作が行われます。
◎ 結果
Random Writeでは、”flashcacheあり”の場合/”flashcacheなし”の場合とで顕著な差がみられました。
Random Readでは、ファイルサイズ1024kの場合で”flashcacheあり”の方が速い結果となりましたが、ファイルサイズ16382kの場合では”flashcacheなし”の場合とほぼ同じ結果となりました。
flashcacheを利用していても、16382kファイルサイズ/4kレコードサイズのRandom Readでは、ハードディスクから読み出しがされていたと思われます。
 |
 |
簡単な検証でしたが、flashcacheを利用するとSSDキャッシングの効果により速度アップがみられました。ただ、読み書きするファイルサイズ/レコードサイズによってはSSDキャッシュの効果がみられない場合もありました。利用するアプリケーションでSSDキャッシュの効果がみられるか検証が必要かと思います。
ApcupsdでAPC Smart-UPSの新しいモデル SMTシリーズが動作するか実験してみました。
環境は以下
UPS: APC Smart-UPS SMT1500RMJ2U
通信ケーブル: USB
OS: CentOS 6.4 x86_64
Apcupsd: 3.14.10
SMT1500RMJ2Uに専用のシリアルケーブルは付属されていますが、どうもApcupsdでは動作しないようだ。SMT/SMXシリーズは、新しい通信プロトコル”Microlink”になっていて、Apcupsdは現状ではサポートされていないようです。
ただしUSB接続であれば、基本的な動作（停電時のバッテリモードから復電）は可能みたいです。
Apcupsdはsourceからインストール
configureオプションにUSBを追加してmakeとmake installしました。
設定は以下のみ追加
TIMEOUT 60
デーモンをstartすると、UPSとの通信は成功しているログが出ています。
コンセントを抜いて擬似停電を装い。。。
シャットダウンできました。
UPSがスタンバイ状態でコンセント接続し擬似復電するとサーバが起動しました。
基本的な動作は問題ないようです。
詳細な情報は取得できないようですが。。。
まぁ、良しとしましょう。
FreeNASでZFSレプリケーションについて動作させてみました。
ZFSボリュームやZFSデータセットのZFS スナップショットを定期的/自動的にリモートサーバへ保存出来ます。
FreeNASをインストールしたサーバを2台を準備します。
●環境
MB: Gigabyte GA-E350N-USB3
HDD: 500GB
OS: FreeNAS-8.2.0-RELEASE-p1-x64
それぞれのサーバへZFSボリュームを作成(*1)し、ZFSスナップショット送信元となるサーバのSSH Public Keyを送信先となるサーバへ登録(*2)します。その後、送付先サーバのSSHサービスを実行(*3)します。
*1 メニューのStorage→Volume Managerより作成。
*2 ZFSスナップショット送信元のメニューのStorage → View Replication Tasks → View public keyを選択。
表示されたキーをZFSスナップショットの送信先サーバへコピー＆ペーストします。
(メニューAccount → Users → View Users → rootユーザのModify Userを開き、SSH Public Keyの項目へ、SSH Public keyをペースト。)
*3 メニューServices → SSH → ON。
ZFSスナップショット送信元サーバで 定期的スナップショットのタスクを作成(メニューStorage → Periodic snapshot Tasksより設定)します。
ZFS スナップショットを15分、30分、1時間、2時間、3時間、4時間、6時間、12時間、1日、1週間 間隔で実行出来ます。また、開始時刻と終了時刻、実行する曜日も設定出来ます。ZFSボリュームやZFSデータセットのZFS スナップショットを定期的/自動的にリモートサーバへ保存出来ます。
ZFSスナップショット送信先を登録(メニューStorage → ZFS replicationを選択)します。
登録例では、ZFSスナップショット送信元のボリュームをlocal、送信先のボリュームをremoteとなっています。
(SSH KEY Scanボタンを押すと、自動的に送信先サーバのPublic Keyを取得できます。)
以上の操作により、ZFSスナップショットを定期的/自動的にリモートサーバへ保存出来きました。(下図)
FreeNASは導入しやすく、ZFSレプリケーションを利用するとリモートサーバへ容易にデータのバックアップ出来ます。欲を言えば、フェールオーバーやフェールバックも設定出来るならばもっと良いと思いました。