DELL PowerConnect 5324を7, 8年ほど前から使っている。
なぜか、当時から64bit counterでちゃんとデータがとれずに困っていたが、アクセス回線が100Mbpsでありかつ、あまり負荷が無かったため、データのとれる32bit counter で値をとっていた。
今回、Bフレッツファミリー100が終了に伴いフレッツネクストファミリー隼へ移行することになり、現在2回線。
負荷試験でいじめるにしても、ifstatなどでリアルタイムモニタをするしかなく、グラフで値が取得出来なかったので、まじめに原因を調べた。最初疑ったのは、Cactiの環境の問題かと思いきや、どうやら違う。
tcpdumpをしながら、64bit counterでどのMIBを叩くかなど確認しながら行き着いた結果は、スイッチが原因。
32bit counter時
.1.3.6.1.2.1.2.2.1.16 IF-MIB::ifInOctets
64bit counter時
1.3.6.1.2.1.31.1.1.1.6 IF-MIB::ifHCInOctets
試しにAlaxalAのスイッチで実験。これが正常。
$ snmpwalk -v2c -c xxx 192.168.80.xx .1.3.6.1.2.1.2.2.1.16
IF-MIB::ifOutOctets.1 = Counter32: 1516
IF-MIB::ifOutOctets.3 = Counter32: 0
IF-MIB::ifOutOctets.10 = Counter32: 1487112571
IF-MIB::ifOutOctets.11 = Counter32: 2456434929
IF-MIB::ifOutOctets.12 = Counter32: 3346849069
IF-MIB::ifOutOctets.13 = Counter32: 4132961252
IF-MIB::ifOutOctets.14 = Counter32: 4194669011
IF-MIB::ifOutOctets.15 = Counter32: 3774590644
IF-MIB::ifOutOctets.16 = Counter32: 3056671465
IF-MIB::ifOutOctets.17 = Counter32: 3530654755
IF-MIB::ifOutOctets.18 = Counter32: 3422319366
IF-MIB::ifOutOctets.19 = Counter32: 3198503144
IF-MIB::ifOutOctets.20 = Counter32: 2603936208
IF-MIB::ifOutOctets.21 = Counter32: 2188571600
IF-MIB::ifOutOctets.22 = Counter32: 1012100246
IF-MIB::ifOutOctets.23 = Counter32: 4262057869
IF-MIB::ifOutOctets.24 = Counter32: 306827950
$ snmpwalk -v2c -c xxx 192.168.80.xx 1.3.6.1.2.1.31.1.1.1.6
IF-MIB::ifHCInOctets.3 = Counter64: 0
IF-MIB::ifHCInOctets.10 = Counter64: 25569802183641
IF-MIB::ifHCInOctets.11 = Counter64: 254264225399
IF-MIB::ifHCInOctets.12 = Counter64: 1731910044921
IF-MIB::ifHCInOctets.13 = Counter64: 102135098057
IF-MIB::ifHCInOctets.14 = Counter64: 29005642362472
IF-MIB::ifHCInOctets.15 = Counter64: 7648801206204
IF-MIB::ifHCInOctets.16 = Counter64: 6830172184232
IF-MIB::ifHCInOctets.17 = Counter64: 15829343
IF-MIB::ifHCInOctets.18 = Counter64: 210465854534
IF-MIB::ifHCInOctets.19 = Counter64: 1865576387531
IF-MIB::ifHCInOctets.20 = Counter64: 2153968856761
IF-MIB::ifHCInOctets.21 = Counter64: 1120854776316
IF-MIB::ifHCInOctets.22 = Counter64: 1900766547462
IF-MIB::ifHCInOctets.23 = Counter64: 154432887612
IF-MIB::ifHCInOctets.24 = Counter64: 252176593
問題のあったDELLのスイッチではどうだろうか。
$ snmpwalk -v2c -c xxx 192.168.0.xx .1.3.6.1.2.1.2.2.1.16
IF-MIB::ifOutOctets.1 = Counter32: 1499571481
IF-MIB::ifOutOctets.2 = Counter32: 321711521
IF-MIB::ifOutOctets.3 = Counter32: 0
IF-MIB::ifOutOctets.4 = Counter32: 1875939512
IF-MIB::ifOutOctets.5 = Counter32: 4191135883
IF-MIB::ifOutOctets.6 = Counter32: 0
IF-MIB::ifOutOctets.7 = Counter32: 128224061
IF-MIB::ifOutOctets.8 = Counter32: 119541184
IF-MIB::ifOutOctets.9 = Counter32: 127963818
IF-MIB::ifOutOctets.10 = Counter32: 0
IF-MIB::ifOutOctets.11 = Counter32: 169218862
IF-MIB::ifOutOctets.12 = Counter32: 3506523126
$ snmpwalk -v2c -c xxx 192.168.0.xx 1.3.6.1.2.1.31.1.1.1.6
IF-MIB::ifHCInOctets = No Such Instance currently exists at this OID
全ポートGigabit対応スイッチで、64bitカウンタに対応していないとはさすがに思わなかった。
さすがに、ネットワークメインじゃ無いメーカーが手を出すとこういう問題が発生すると言うことだろうか。困った困った。
ちなみに同一の問題が、Panasonicのスイッチでも発生している。
$ snmpwalk -v2c -c xxx 192.168.80.xxx system
SNMPv2-MIB::sysDescr.0 = STRING: <M16eG-Version1> System Software Release: 1.0.0.148
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.396.5.4.2.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3885301964) 449 days, 16:30:19.64
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: sw2.tokyo
$ snmpwalk -v2c -c xxx 192.168.80.xx 1.3.6.1.2.1.31.1.1.1.6
IF-MIB::ifHCInOctets = No more variables left in this MIB View (It is past the end of the MIB tree)
$
この問題に気づき、ぐぐったら、フォーラムに同様の書き込みがあった。これは、原因が明確にわかっていないと検索出来ないたぐい。Broadcomのチップが対応していないと言いたいのかな?
PCT5324 64bit SNMP
There are no plans to add support for the 64-bit HC counters. I believe this is a limitation of the ASIC, so a firmware update would not be able to add this support.
さらに見つけたのが、導入した後の話。。
I believe 5324 2.x.x.x firmware has 64 bit counters. It's on their website.
I've just installed the 2.x firmware and I can confirm the 64 bits counters!
Confirmed here as well. Yipee
動くのか動かないのか。ここからはわからず。
ちなみに、ファームウェアは次のバージョン。
NARA-PC5324# show ver
SW version 1.0.0.45 ( date 07-Jun-2004 time 14:34:51 )
Boot version 1.0.0.21 ( date 10-Aug-2004 time 13:33:06 )
HW version 00.00.02
Dell PowerConnect 5324, v.boot1.0.2.02/fw2.0.1.4, A06を見る限り、Last Updated 03 Nov 2011 らしいので、実はいけたりするのかな。
いしても、ネットワーク専門じゃないメーカーを買うとはまるという罠はここに。
ニュースには、
デル、大規模ネットワーク向けスイッチPowerConnect 5324を発売とあるんだけどなー。でも、所詮この程度。
ちなみに、この機器は、2013年6月27日にuptimeを見たとき次の値。そして、今年の8月7日にVLAN設定を変更していたら、応答が無くなりリブートした。
PC5324# show system
System Description: Ethernet Switch
System Up Time (days,hour:min:sec): 696,23:54:15
計算すると、約2200日連続稼働。記憶によると導入したのが、2007年頃。約10年ぐらい連続稼働しているので、そろそろお役御免なのかもしれません。
ということで、ファームウェアを更新してみました。
更新前:
NARA-PC5324# show version
SW version 1.0.0.45 ( date 07-Jun-2004 time 14:34:51 )
Boot version 1.0.0.21 ( date 10-Aug-2004 time 13:33:06 )
HW version 00.00.02
NARA-PC5324#
更新後:
NARA-PC5324# show ver
SW version 2.0.1.4 ( date 01-Aug-2010 time 17:00:12 )
Boot version 1.0.2.02 ( date 23-Jul-2006 time 16:45:47 )
HW version 00.00.02
NARA-PC5324#
更新が完了したので、試してみましょうか。
$ snmpwalk -v2c -c xxx 192.168.0.xxx 1.3.6.1.2.1.31.1.1.1.6
IF-MIB::ifHCInOctets.1 = Counter64: 8278680
IF-MIB::ifHCInOctets.2 = Counter64: 0
IF-MIB::ifHCInOctets.3 = Counter64: 0
IF-MIB::ifHCInOctets.4 = Counter64: 847869
IF-MIB::ifHCInOctets.5 = Counter64: 6184210
IF-MIB::ifHCInOctets.6 = Counter64: 0
IF-MIB::ifHCInOctets.7 = Counter64: 0
IF-MIB::ifHCInOctets.8 = Counter64: 0
IF-MIB::ifHCInOctets.9 = Counter64: 0
とれるようになりました.... ふむ。。。
ちなみに、リリースノートには本件に関する内容の記載はありませんでした。。。しょんぼり。
今年の5月末、支払期限間近のタイミングの出来事。
とあるイベントでJPNICに訪問する機会(JPNICが会場を提供している)があり、訪問。
近くにJPNICの中の知り合いの方が通りかかったので、
「ちょっとお願いがあるんだけど、維持費を現金でもってきたので、支払いたいんだけど!」
と引き留めたところ、ちょっとまってね〜。とニコニコ。
そうしたら、いつもおなじみのIP事業部のお兄さん(JANOGとかよくいらっしゃる方)と経理の方を連れてきました。
多少時間はかかったモノの、領収書を発行し、現金ニコニコ払い、手渡しが出来ましたw
もちろん、こういう突撃なので、おつりが一切でないようにきっちり金額を持参。
事前にアポをとっておくと、ダメですといわれそうなので、突撃です。これで、振込手数料432円が浮きました。
請求書
請求書もフォーマットがおかしいですね、個人なのに、会社名のところに名前をいれているのか、敬称が無い。
その上で、担当者様。ちょっと、個人宅には、経理担当などはいません。あ、既婚なら、お金を管理する奥様はいるかも、、、、だが、私は独身だ!(笑)
そして、その後、名前。。よくわからず。という突っ込みをいれたら、「個人はあなただけだから勘弁してよ〜」と言われてしまいました。
無事、領収書発行。
領収書はテンプレをベースに個別に作成するので、宛名などちゃんとつくられていますね。
やはり、システム的なモノは個人を対象にしていなさそうでした。
ということで、仕事は増えるかもしれないけど、元々発生していなかった維持費。仕事を作って請求しているようなものだし、別にいいよね。てことで、現金払いが無事出来ました。
現金もって、突撃したのはあなただけですよといわれました。うん、いいの。実績出来ました。現金ニコニコ払いはOKですよ!
2000年過ぎから、我が家はIPv6 Onlyでも動くようにサイトを構築している。
そんななか、IPv6が当たり前の環境にいたが、いま、現状でどういう感じかと探ってみた。
昨今、IPoE(VNE)や、IPv6を標準に提供する元電力系ISP(auひかりone)、そして、Softbank光やnuro光など増えてきていること、
モバイル3社は2017年度中にIPv6導入することを発表している。
また、Appleは2015年6月より、アプリが
IPv6 Only Networkに対応していることを
必須としているので、そのあたりも確認していきたい。
環境は、Windows 7 + Chrome 、IPv6 Onlyでアクセスする。
尚、GoogleやFacebookは、IPv4が無くとも全く困らないことをお伝えしておく。
ターゲットにしたWebサイトは、下記の通り。主要OSについては、OS Updateができるかも確認している。
DNS Cache ServerはGoogle Public DNSを使用している。Cache ServerがDualStackに対応していることがおそらく世の常なので、権威サーバーがIPv6トランスポートをもっているかどうかは対象としていない。
- 主要OSを提供しているベンダー(Microsoft, Apple)
- モバイル3キャリア(NTTdocomo, AU/KDDI, Softbank)
- VNE事業を行っている/行おうとしているxSP
- 主要ISP
長いので、最初に結果を書いておく。
主要OS
Microsoft
Topページすらまともに表示できない。
画像やCSSなど外部サーバーでIPv4のみ。
supportやtechnetも繋がらない。
Windows UpdateはIPv6 Onlyでも動作した。
Apple
Apple Store(オンライン販売のページ)はまともに表示できない。
itunesはだめ。もちろん、AppStore(App側)もダメ。
アプリには対応を要求する割には....情けない。
apple.co.jp は www.apple.comにリダイレクトするだけの簡単な仕事なのにIPv6未対応。
なんで、これぐらい出来ないのかな?
日本国内携帯3社
NTTdocomo
www.nttdocomo.co.jp にほぼ集約されているのでコンテンツは閲覧可能。
だが、dpointや、mydocomoなど、IPv6非対応のため、使えない。
サービス紹介、エリア検索等については、サイトそのものは、同一FQDN内におさまっているのでおおよそOK
エリア地図もGoogleサービスを使用しているため、表示可能。
Softbank
mysoftbankは非対応、ybbのリンクまでは行けるが、契約がらみでは非対応。
サービス紹介については、サイトそのものは、同一FQDN内におさまっているのでおおよそOK
対応エリア検索の地図はYahooJapanの外部を利用しており、こちらが非対応。
KDDI
Topページは見れるが正しく表示できない。
外部ドメインにCSS/画像などをとりに行くものの、サーバーがIPv6に非対応。
でも、そのほかダメ。AUのサイトに関してはそもそも非対応。
以前はau(www.au.kddi.com)も対応していたが、ドメイン変更に伴いアクセス不可。
IPv6でアクセスしていますといいながら、バナーが見えるだけでサイトとして機能していない。
IPoE VNE/主要ISP
※ IPoEに関しては、NTT東西より
申し込み受領された事業者を対象としており、サービス開始の有無については考慮していない。
NTT東西
フレッツサイトはIPv6に非対応
コーポーレートサイトはNTT東はAAAAが付与されているが、正しく応答しない、壊れた環境。
BBIX
何ら問題無いが検索窓がYahooに依存しておりNG
JPNE
何ら問題無い
Transix
何ら問題無い
FreeBIT
何ら問題無いが、DTIは非対応
Biglobe
サイトは見れる。
ただし、入会サイトやアイドル、グラビアなどダメ。
メールのリンクなど表示されない。
そもそも認証系サイトがIPv4にしか対応していない。
AsahiNet
論外。AAAAすらついてない。
v6確認サイトのみ外部ドメインのサーバーで確認可能
OCN
完全アウト、まともに閲覧出来ない。KDDIと同レベルかそれ以上に論外。
その他メールなどもダメ。
OCN(Global IP Network)
さすがにこちらは大丈夫。
検索窓はNG
IIJ/IIJMIO
問題無し
Plala
全部対応、マイページ、WebメールなどもOK
Nifty
非対応。AAAAすら無い
So-net
www.so-net.ne.jpは対応しているが、
nuro.jpは非対応。www.so-net.ne.jp のSSLページは挙動が変でIPv6環境では正しく表示出来ない。
★ 主要OS:
★ モバイル事業者 3社の対応状況:
- NTTdocomo
www.nttdocomo.co.jpにほぼ集約されているのでコンテンツは閲覧可能。
サービス紹介、エリア検索、エリア地図表示等については、サイトそのものは、同一FQDN内におさまっているのでおおよそ問題無く利用可能だった。地図に関しては、Googleを使用しているため、問題無く表示される。~
だが、dpointや、mydocomoなど、IPv6非対応のため、使えない。
というか、ページ表示に応答が無くエラーとなる。
- SoftBank
softbank.jpにほぼ集約されているので、サービス紹介などコンテンツは閲覧可能。
エリア検索等については、サイトそのものは、同一FQDN内におさまっているのでおおよそ問題無く利用可能だったが、地図に関しては、YahooJapanのモノを使用しており、こちらは表示不可。
service.areamap.mb.softbank.jp
mysoftbankは非対応、ybbのリンクまでは行けるが、契約がらみでは非対応。
- KDDI/AU
Topページは見れるが非常に残念な状況。論外。
auに関しては、以前、
www.au.kddi.comのFQDNで、IPv6対応、普通に表示できていたのに、今はリニューアルと同時に、劣化というか、デグレしている。
てか、劣化するって、会社的に大丈夫なんか?今時あり得ない。論外。
今は、
www.au.comとなっており、AAAAすら存在しない、世の中見直した方がいいよ?
こういうサイトはクラウドに行くときもちゃんと対応しているか必要条件。
ベースのインフラはAWS EC2ってところか。今は対応してるはずだしね。
対応させないと決断したひと出てこいといわれても仕方が無いレベル。
$ host www.au.kddi.com
www.au.kddi.com has address 106.162.242.188
$ host www.au.com
www.au.com is an alias for cdn-kddi-prod.adobecqms.net.
cdn-kddi-prod.adobecqms.net has address 54.192.110.232
$ host 54.192.110.232
232.110.192.54.in-addr.arpa domain name pointer server-54-192-110-232.nrt53.r.cloudfront.net.
何が一番最悪かというと、IPv6でアクセスしていますというバナー表示する割には、サイトがまともに表示できない。
★ IPoE VNE/主要ISP:
もう、こちらは、ざくっと。結論から言うと、初期VNE3社および、IIJ/Plalaぐらいしかまともなサイトは無かった。
初期VNE事業者 3社は個人の手続きを対象としておらず、ローミングなど、ISP事業者にサービス紹介にとどまり、普通にDualStack化されている。しかし、ISPでいうと、IIJ/Plalaぐらいしかまともに動作していなかった。
- BBIX
こちらは検索窓がYahooのサイトに依存しており、IPv4のみで動作しなかったが、それ以外すべてIPv6に対応していた。
また、ご丁寧に、IPv6でアクセスしているとアイコンまで表示してくれた。
- JPNE
こちらは、問題を見つけることが出来なかった。
また、ご丁寧に、IPv6でアクセスした場合、IPv6アドレスまで表示してくれた。
- Transix/InternetMultifeed
こちらは、問題を見つけることが出来なかった。
また、ご丁寧に、IPv6でアクセスしているとアイコンまで表示してくれた。
- FreeBIT(コーポレートサイト)
旧DTIに関してはAAAAすら付与されておらず、非対応だったが、FreeBITに関してはコーポレートサイトのみしかなかった(?)為、こちらの調査。こちらは、検索窓を含めて、IPv6に対応している。特に検索窓を含めて問題を見つけることができなかった。
- BIGLOBE
コーポレートサイトは特に問題無く表示された。検索も正常。ISPポータルは、いろいろと問題が発生。ここの会社はずいぶん長い間IPv6サービスをやっていたおおもうんだがな。。。
特に、入会ページや、法人向けサイト、サポートサイト、その他、アイドルグラビア、写真集など、AAAAがなく、アクセス不可。
メールというか、SSOがらみの認証が非対応のため、まったく会員および会員になろうとしているユーザーは、必要な情報にアクセス出来ない。また、アプレットなどを使っているのか、異なるFQDNのものは、リンクすら表示されないことがあった。
ただ、ポータルからアクセス出来る天気など一部のコンテンツは問題無く閲覧出来た。でも、本来必要な情報にアクセスできないのは問題。
そして、サポートサイトで、
IPv6接続のご案内がIPv6でアクセス出来ないのはいろいろと論外だった。
- AsahiNet
AAAAすらついていなくて、論外。
ただし、
IPv6接続確認ページのみ対応。サーバーは外部のさくらインターネットだった。
- OCN
サイトの作り方が一番ひどかった。
www.ocn.ne.jp には、IPv6対応のため、AAAAが付いているのに、後付けでRedirectし、service.ocn.ne.jp などIPv6非対応のサーバーのコンテンツにアクセスさせる仕様。これは頭が悪い。
下記のJavaScriptなどは、v4/v6/dualstackのサーバーと用意しているのに、そのほかはめちゃくちゃ。
<script type="text/javascript">
var getIPv4 = '';
var getIPv6 = '';
</script>
<script type="text/javascript" src="http://v4.ocn.ne.jp/cgi-bin/v4/checkip/checkip.cgi"></script>
<script type="text/javascript" src="http://v6.ocn.ne.jp/cgi-bin/v6/checkip/checkip.cgi"></script>
<script type="text/javascript" src="http://c011.ocn.ne.jp/_top/js/ipv4v6_check.js"></script>
<script type="text/javascript">
if(nIpVer == 6){
document.write('');
document.write('<link rel="stylesheet" href="http://v4.ocn.ne.jp/_top/css/base.css" media="all">');
document.write('');
}else{
document.write('');
document.write('<link rel="stylesheet" href="http://c011.ocn.ne.jp/_top/css/base.css?6823" media="all">');
document.write('');
}
</script>
最初はきちんと対応した環境になっていたんだとおもうが、後で触った人が壊したんだろう。こんなことをする暇あるんだったら、ちゃんと対応させろってな。サイトを管理するひとは、IPv6のことを全く意識していなさそうだ。もちろん、検索窓なんかは動かない(外部サービス/Gooが非対応))。尚、c011.ocn.ne.jp は Akamaiを使用しており、こちらは、DualStackに対応している。が頭の悪い作り方をしているので、まともに活用されていない。
一応余談だが、
Global IP Networkの方は、問題を見つけれない程度には対応されていた。といいたいところだが、検索窓は、こちらもIPv6非対応のGooを使っているため動かない。
- NTTぷらら
個人的には、一番ありえないとおもったサイト。
この中ではIIJに並ぶまともなサイトだった。
- IIJ
昔からまじめにIPv6に取り組んでいる唯一の組織と言ってもよいかもしれない。
残念なのは、biz.iij.jp が非対応。その他では、技術ブログ(
てくろぐ、
GIOろぐ(なぜにこれだけSSL対応?)、
スマートメーターBルートブログ)
などが対応していたことも評価しておく。 IPv6対応クラウドサービスワークショップで堂前さんが、IIJGIOもIPv4が亡くてもコンパネなどアクセスしてほぼすべての操作ができますからね!と楽しそうにデモをしていたぐらい、自信があるようだ。
★ クラウド事業者/ホスティング事業者:
AWSについては、サービスとしてはIPv6に積極的に対応していると、
IPv6対応クラウドサービスワークショップで
公言している。が、自Webサイトには未対応。
さくらインターネットは、IPv6推進していますとかいいながら、サイトはIPv6に非対応。
以前は対応していたのに、ころころとDC内ごろつきをしはじめてから、非対応になった。
今や、腐ったSaaSesで使われていた日本ラッドの
IPアドレスまでのっとって、コーポレートサイトにつかっていてちょっとワロタ。元ライバルだったよね。
意味ありなかんじでIPアドレスを使っている。だが、IPv6には非対応。ウケる。
ちなみに、ここも
主要サービスすべてにIPv6対応していると、公言している。
$ host www.sakura.ad.jp
www.sakura.ad.jp is an alias for site-112800350116.gslb3.sakura.ne.jp.
site-112800350116.gslb3.sakura.ne.jp has address 163.43.24.70
★ まとめ:
IPv6事業を積極的にやりますと宣言している事業者の多くは、WebサイトをIPv6対応にしているが、Topページがちゃんと閲覧出来ないところ、検索窓が動かないところが多く見受けられた。
また、最悪な例としては、直接サイトから絶対パスで呼び出す外部リンクの一部(主にCSSや画像、JavaScript等)の参照先サーバーが、IPv6にそもそも対応していないという悲しいことが発生。
中途半端なことをするぐらいなら、Reverse Proxyなどしかけて工夫すればよいのだが、一切ケアできていない。
ログインをしなければいけないなど、作り込んだサイトは仕方ないとしても、見せ方には工夫の余地がある。
少なくとも、サイトのコンテンツの一部(除外部サイトへのリンクや、別サービスのリンク)以外は、全部IPv6に対応させる必要がある。非常に優秀だと感じたのは、NTT東西フレッツネクストのIPoEサービスを始めるに当たって、名乗り出たVNE 3社の対応は素晴らしいとおもう。
また、IPv6アクセス時には、IPv6でアクセスしているとわかるようなロゴを掲載しているサイトは比較的まともな運用をされているように感じる。
本当はDL380 G8で2.5インチ 2TBのディスクを16本とかやりたかったのだけど、コストの問題で、DL180 G6で妥協。
ちょうどよいモノが出回っていたので、3台調達して、ディスクだけ入れ替え。
もちろん、冗長化電源、DualCPUなのでちょうどよさそう。
3台あるのは、1台部品取り用(どうやら故障品を引いてしまった様子)、2台の内1台はコールドスタンバイ機、すなわち予備ですね。
中古品なので、部品取りをした上、最終的に抜け殻になったので、ハードオフに処分をしにもっていきました。
奴らはバカなので、本体のホットスワップ電源ユニットを抜いて、ドライブベイを外してもっていくと、1台のなのに、分割して計算し始めました。
値段が全く付かなかったので、電源ユニットだけ持ち帰り冗長化電源の予備として確保しておくことに。
現行販売品であっても、古いですねー、の一言、動作確認もしません。
まともに動作確認や調べようともしないので、動くモノなどまともなモノを持ち込むのが間違いです。ゴミ捨て場です。
ちゃんと査定+評価するのであれば、こちらもそれなりの対応をします。
脱線からもどして、当初、調達した構成は、1TB x 8 が2セット、残り1セットは300G SAS x 6 の構成。
大量にSATA 1TBのHDDとSAS 300GBのディスクがあまりましたが、1TBのディスクは、カセットの要領で、テンポラリディスクとして転用します。
いわゆるアーカイブ保存用ですね。
DL180G6には、不具合が有り、PCIeにSmartArrayオプションをつけると、温度管理に不具合が生じて、FAN全開で回るというバグ。
これは、ファームウェアでも改善されないようで、困りました。
同じ問題を、
serverfult HP ProLiant DL180 G6 Fan Noise?というところに投稿が。組み合わせで発生する様子。また、PCIeに他のSASカードをつけて、miniSASで接続した場合も同様にこの問題が発生するので、ドライブベイのFANユニットの温度状態が正しくとれないのが原因では無いかと推測しています。
また、PCIeにカード類をさす場合とささない場合では、PCIe周りのBIOSが異なるようで、起動中になにかしら、ファームウェアの入れ替え作業を実施してるえるようなメッセージが表示されおり、このタイミングでうっかり電源が落ちると、BIOSが飛んだりして大変なことになりそうです。ってかマニュアルにも記載が見つけれなかったがいろいろと癖がありそう。
原因がわかったので、3台ある内のDL180から内蔵用のP410/512 FBWC コントローラー(内部接続専用)用を移植したら、FAN全開問題が解消さました。そして、RAID6ボリュームを作成。~これだけあると、構成がばらばらなので、PCIe接続用SmartArray、FBWC、メモリなどあるので、調整ができてちょうどよいですね。
構成は、Xeon 5640 + MEM 24GB + P410 +
WD RED 4TB x 8(RAID6)で24TBストレージになりました。
ディスクは購入時は、1.5万円ほどでしたけが、その後値段が上がったのでよいタイミングで調達したと思います。6TB,8TBはGiga単価が高いこと、故障率が高いで、みんな4TBにいったんだとおもいます。
ある程度動いたので、Twitterに、
投稿。
リツイート件数が892件いただきました。女子のお家のNASですよ。
892というと、Cisco 892FJがほしい(w
OS はFreeBSDでzfs+dedup採用です。dedupを使う場合、CPUにDiskIOをかなり消費します。
元々、このストレージはデータバックアップなので、snapshotを走らせ、一日一回データバックアップが裏で動くのですが、この際、dedupがあると、7〜8倍ぐらい入ります。その上で、圧縮ボリュームにしてます(以前の実績値)。圧縮を有効にすると、実際の容量とはかけ離れてきてしまうので、実際使っている容量がわかりづらくなります。さて、既存のDL120からデータをお引っ越ししようと、zfs sendを行おうとすると、40TBを超え、1Gbpsでは1週間ほどかかる見込み。実際に見えていない容量もあるので、計算上はもっとかかる可能性があります。
実際に転送をしてみると、転送先ではあまり、dedupが効かない感じ。。。まだ、最初の方だし仕方ないですかね。
また、今までの経験から、1Gbpsでは帯域が厳しく、10Gbpsに行くにもちょっと...と悩んでいたので、Link Aggregation(LACP/802.3ad)を採用しました。その上で、データ転送をしたら、ちゃんと2Gbps近く出ることもわかりました。
AxalaxAのスイッチとFreeBSDと組み合わせると、AlaxalAから来るトラフィックは、同一mac/ip/port であっても、リンクが分散してくれるようなので、よい実装です。帯域を使い切れますね。
転送元はほぼ、1Gbpsきっちり出てくれています。
が、なかなか終わりませんので、放置しましょう。
結局終わりそうにも無いので、古い不要になったsnapshotを消して少し軽くしてから、再度転送しようかとおもいます。
ちなみに、FANが全開で回ると、40Wぐらい消費電力が増えますが、負荷がさほど高くないときは、100〜120W前後程度で落ち着いています。
HBAの問題が解消されないと、ものすごいFANの音と、1kwhあたり、30円で計算すると、28.8Kwh、すなわち、864円程度電気代が値上がりすることになりますので、非常にシビアな問題です。