WiMAXのモバイルルータを導入した
emobileの2年縛りが終了したため解約してから数ヶ月、外出先でのネットワークが無い不便が辛くなってきたのでWiMAXのモバイルルータを購入した。
忙しい人のために、結論だけ3行で
- 値段安いし、速度速い
- エリアは都市部なら大丈夫そう、でも建物の中や地下はダメ
- 機種固有の問題として、電池の持ちがあまり良くない
WiMAXのモバイルルータも既に数モデル出ているようだったが、ヨドバシ店頭で1円端末として売られていたNECアクセステクニカのAterm WM3300Rを選択。購入前に店員に相談したところ、最低利用期間や契約条件は妥当だと思ったので即断
NEC AtermWM3300R PA-WM3300R(AT)
- 出版社/メーカー: NEC
- メディア: Personal Computers
- 購入: 2人 クリック: 112回
- この商品を含むブログ (23件) を見る
定額のデータプランは月額4480円だが、1年限定で3780円という割引きがされる。また、ヨドバシが提携しているWireless GateのWiFi利用権も付属していた。こちらは利用可能なポイントが微妙なので実用性は低かった。
利用料金や契約期間に関する縛りの緩さなどの点で他のキャリアよりも遥かに上回る利便性がある。
肝心の電波の入りだが、個人的には想像していたものと大差なかった。屋内での入りがあまりよくないというのは事前情報通りだが、通常の個人宅の奥まったところでもそれなりに入る。大きな建物の中心部分はかなり厳しい。大型のビルだと携帯の専用アンテナなりリピータが整備されていることが多いが、これがまだ未整備であるためだろう。また、地下は原則どこも入らないと思ったほうがいい。その地下での弱さを補完するためにWiFiのホットスポットサービスに加入すべきなのだが、付属していたWireless Gateの利用箇所では実用性が低いと感じた。地下鉄の駅をほぼ全てエリアにしたNTT系のサービスかそれと連携するサービスも合わせて加入した方がいい思う。
速度はかなり速い。Android端末やiPad、ノートPCからWiFi経由で使っていたが、対外接続がBフレッツの自宅のWiFi APを使うときと遜色がない。むしろ自宅のAPから離れてWiFi区間が遅い速度でしかリンクしないときより、すぐ近くにモバイルルータがあるときの方が速いこともあったぐらい。
RTTは最初の1hopで90msぐらい。ISPとしてはDIONの中になるようで、ASはAS2516の中のIPアドレスが貰えた。
WiMAXではなくこのモバイルAP固有の問題として、あまり電池の持ちが良くないように感じた。公称でも2.5時間なのでスマートフォンと組み合わせてモリモリ使っていると先にAP側の電池が無くなってしまう。小まめに電源を切ればいいのだけど、起動に1分前後かかりWiFiのネゴシエーションなども考えると起動しっぱなしの運用にしたいところ。後継モデルがCEATECで展示されていたそうで、電池の持ちが2倍ぐらいに改善されているらしい
またモバイルAPでは共通の問題だと思うが、WAN部分の接続とWiFi部分が連動していないので電波の入らないところでもスマートフォンなどからはWiFiの接続は生きているのに、インターネットとの通信ができないという状況になる。WANの接続を即座に反映してWiFiの電波を落とすと、それはそれで不便なので対策は難しいかもしれない
自宅のデスクトップを更新した
ベース Express5800/GT110b
追加したパーツ
あとは前のデスクトップから剥がしてきたRadeon HD 5570。
新しくデスクトップ環境を作るにあたって、Firefoxを止めてGoogle Chromeに切り替えてみたり。
ベースとなるハードウェアが安サーバ機であるため、サスペンドが使えないのは承知の上だったのだけれど普段からハイバネーションを常用する方だったのでこれは特に問題にはならなかった。ただ、ときどき休止状態に入って電源が落ちた直後に再び入ってしまう問題と、復帰後にUSBの再初期化に失敗することがあるのが難点
ディスクが前に使っていた1TBから小さくなったので、いろいろと使い方を変更しなければならない。動画はもちろんだがiTunesの楽曲をどこに置くか悩み中。
Seagateのハイブリッドディスクを使ってみる
動機
搭載されたフラッシュ部分がHDDへのライトバックキャッシュとして動作しているかを確認する。
高速なストレージが求められている場面ではSSDを使うのがもはや定石になりつつあるのだけど、容量やビット単価から導入しにくい場面もある。データベースなどで数百GBの規模になっており、今から分割するのが困難な場合など。通常はその場合、BBU付きのRAIDカードなどで書き込み性能を補うのだが、これもやはり高価だったりする。そこでハイブリッドディスクへの交換のみで同期書き込みの性能向上を図ることができるかを確認する。
RAIDカードのキャッシュは通常512MBのものが多いなか、この製品ではフラッシュ部分に4GBのSLCを使っている。
価格
ドスパラで320GBの物を約13kで購入。これは同じくSeagateの2.5インチSATA 320GBのディスクが5k前後で購入できることを考えると、2倍以上のビット単価である。恐らく競合はSSDであると見込んでいるのであろうSSDとの比較ではIntelのX25-Vが価格的には一番近く、40GBで10k前後。
| 製品名 | サイズ | 価格(ドスパラ調べ) | GB単価(円) |
| Momentus XT | 320G | 12980 | 40.6 |
| Momentus 7200.4 | 320G | 4980 | 15.6 |
| X25-V | 40G | 10470 | 261.8 |
SSDは高価だと感じるけどHDDそのままでは嫌だという層に向けた製品のようなので、値段もまさにそのような位置付け。HDDの約2.5倍、SSDの1/6程度
シーケンシャルリード
Barracuda LP
Timing buffered disk reads: 332 MB in 3.01 seconds = 110.14 MB/sec
Momentus XT
Timing buffered disk reads: 278 MB in 3.01 seconds = 92.33 MB/sec
2.5インチにしては健闘しているか。5400rpmの低消費電力のディスクにすら負けているとも言える。
ランダムI/O
sysbenchのfileioモードを使って測定した。データサイズは256MBと8GB、アクセスパターンはrndrd,rndwr,rndrw、ページキャッシュの影響を排除するためdirect i/oにしてフラッシュ部分にデータが乗るよう初回の実行は捨てて2回目で測定。
| データサイズ | アクセスパターン | I/O発行回数 | アクセス時間の95%tile |
| 256M | rndrd | 217.15 | 45.77ms |
| 256M | rndrw | 178.44 | 78.54ms |
| 256M | rndwr | 252.90 | 24.11ms |
| 8G | rndrd | 149.31 | 64.50ms |
| 8G | rndrw | 172.62 | 77.65ms |
| 8G | rndwr | 197.67 | 28.33ms |
と、まあ全然速くない。かろうじてフラッシュが乗っていることを実感できるのはアクセス時間の最小値が0.15msから0.25msぐらいになるということ。OS側のキャッシュが効かない条件での測定なのでこの数字は純粋にドライブ自体のキャッシュが効いているものと言える。普通の3.5インチのドライブに対しても同様の測定を行なったが、最小値はおおむねドライブのベア性能が見えただけなのでここだけは高速化が顕著に出ている。
総評
このドライブはデータベースなどを置くためのものというより、通常のPCで使ったときにパフォーマンスが伸びることをうたっているので今回の測定はそもそも不適当だったのだがそれを差し引いても若干失望するほどの性能。宣伝では主記憶をキャッシュ容量分(4GB)増やすよりは小さなコストでより近い効果を発揮できるとしている。今回の測定結果を見る限りでは、SLCのセルを使っているというフラッシュ部分もそれほど速くはないか、アルゴリズムが単純ではないため簡単に効果を得るのは難しそうである。宣伝にあるOS起動時のスピードアップなどは、主記憶を増やしても効果を実感し難い場面でありこのドライブの不揮発フラッシュの効果が見えそうな場面ではある。
そもそもの動機であったライトバック動作をしているか否かについては、アクセス時間の最小値からしているように見受けられる。しかし、フラッシュ部分全体を単純にライトバックキャッシュとして使わないためか、あるいはそもそもフラッシュ部分が遅いのかいまひとつ性能の向上への寄与が小さいように思われる。
ただし、今回の測定結果はこの製品の主たるターゲットであるPCでの利用での性能が低いことを示すものではありません。
追記
このディスクはアイドル状態のときに直前にアクセスしたデータをフラッシュ部に移しているのではないかという情報を得たので追試
- データを作成
- ランダムリードでそのファイルへアクセス
- 300秒待つ
- データファイルへランダムアクセス
という順序。
それぞれ毎秒でのI/Oの発行回数
| データサイズ | アクセスパターン | 前回の測定結果 | 今回の結果 |
| 256M | rndrd | 217.15 | 566.83 |
| 256M | rndrw | 178.44 | 223.17 |
| 256M | rndwr | 252.90 | 198.23 |
| 8G | rndrd | 149.31 | 144.08 |
| 8G | rndrw | 172.62 | 135.98 |
| 8G | rndwr | 197.67 | 162.78 |
IIJのコンテナ型データセンターの見学会に行ってきました
大前提
ラック単位でデータセンタを借りているユーザには当面関係のない話です。仮想化されたホスティングサービスのユーザはちょっと関係あるかも。ウェブサービスの完全なユーザにも近い将来は少し関係してくるかもしれない話題。
そもそも何故コンテナデータセンターか
Sunがコンテナ型データセンターを発表してから色々と注目が集まっているコンテナ型だけど、IIJは以下の2点
- 電力効率
- 設備投資の粒度
をメインにコンテナ型のデータセンタを作ることにしたのだそうだ。
電力効率
何故データセンターに空調が必要かと言うと、もちろん設置する機器を冷却しなければならないから。
温度・湿度上限は何となく理解できるが、実は環境条件には下限もある。湿度が低すぎると静電気による事故が増えるし温度が低すぎると可動部分のが潤滑剤が固着してしまうのだそうだ。環境条件には一般的にはASHRAEというアメリカの空調に関する団体が策定した基準を使うので、今回のコンテナ型データセンタでもこれを目標にした。
このデータセンタでは可能な範囲で外気をそのまま利用しつつ、従来型の空調と合わせて効率化を図っている。空調には3つのモードがあり、これらを切り替えながら運用している。
- 外気をそのまま取り込むモード
- 外気と排気を混合するモード
- 排気を再度冷却して循環させるモード
春や秋などの気候の温暖な時期には外気を取り入れるファンが動いているだけと効率よく稼動させることができるし、冬や夜間には低すぎる外気と計算機の排熱を混ぜて適当に温度を上げたうえで冷却に使っている。
実際に1日での温度と湿度の変化をプロットした物を見せてもらったが、早朝で外気がまだ低いときには排気を混合して適当な温度に上げて利用しており、日中になり温度が十分に上がったタイミングで自動的に完全に外気を取り込むモードに切り替わっていた。いずれのモードも電力を大量に消費するコンプレッサーを回さないので、受電部分を除いたPartial PUEで1.04と非常に低い値が出たとのこと。これはもう野晒しでサーバだけ動かしている状態にかなり近い。
その他、空調で冷やすエリアと排熱を集めるエリアを完全に分離したりするなど最初から効率性を重視した設計もあって、日本国内で通年運用で PUE1.2ぐらいになる見通し。これは日本国内の最近建設されている高効率のデータセンタでよくある1.4前後を大きく上回り、Googleなどが自社で使っているデータセンタとほぼ比肩するほど。
測定データでデモで見せてもらったのだけど、国内の温度・湿度環境下で外気冷却を使うというのはノウハウの塊であるようだ。IIJはこの通年での実験で他事業者に比べて1年先に行ったことになる。
今後はASHRAEの基準を一歩進めて、機器が壊れない範囲でより広い環境条件での運用も視野にいれていくとのこと。温度条件が緩和されれば外気のみでの運用可能期間が伸びてより効率を上げることができる。
設備粒度の細分化
従来建屋単位での投資になっていたのが、コンテナ単位で必要に応じて増設出来るようになる。
データセンタを借りた事がある人ならばわかるかもしれないが、新しいデータセンタならばラックがまだ立っておらず広いスペースが余っていることがある。理想的には全ての床が売れている状態が望ましいのだろうが、実際には常時空きを抱えているか逆に供給が足りない状態のいずれかだ。
コンテナ型ならばそもそもの設置スペースという問題はあるが、ラックの需要に応じて順次増やしていけるので投資を小まめに行なえる。設置スペースに関しては十分に土地が安い場所を使うことで解決している。
今回の実験では1コンテナに9ラックが搭載されている。通常のデータセンタではラックにサーバを満載できないが、この実験では冷却能力が非常に高いためにフル搭載状態で運用ができる。とはいえ、ラック数が少なすぎる気がしないでもない。本運用時にはラックの設計変更や寸法を伸ばして搭載ラック数を増やしていくことも考えているらしい。
PUE
PUEとはGreen Gridが発表しているデータセンタの効率性を表す指標。
PUE=データセンタ全体の消費電力 / IT機器の消費電力
という式で計算できる。つまり、データセンタの本分であるIT機器以外にどれぐらい電気を消費するものが稼動しているかということ。理想状態ならば 1で計算機だけしか電力を消費していない状態。もちろんこれは無理なので、国内の普通のデータセンタでは2ぐらい、Googleでは1.13から1.2
上でこのデータセンタのPUEが非常に優秀であると書いたばかりだけど、PUEという指標自体も問題がないわけではない。例えばDC給電などで搭載機器を効率化したとすると、給電設備はデータセンタ側に持つのでPUE自体は悪化したように見えてしまう。
問題もあるけど、実際に使える指標はPUEしか無いよね、というのが現状のようだ。
防災
コンテナの中に入って思ったのだが、改めてやはり閉鎖した空間であるということ。閉所恐怖症の人にはかなり厳しいというか恐らく入れないのではないかというような環境。データセンタは幾つは利用したことがあるが、いずれも通常の建築物だったので、ここほど圧迫感はなかった。
非常口は入口と反対方向に設置されているので、入口付近で火災が発生しても脱出できる構造になっている。多少空間効率を犠牲にしても非常口を付けたくなる理由がわかった。消防法での規制以前に無いと怖い。非常口が無かったら、ちょっとしたボヤでも入口が開かなくなった時点で即座に中の人間が蒸し焼きになってしまいそう。
共同実験には防災機器のメーカも参加しているぐらいで、実験施設とはいえちゃんとその辺も考慮してある。煙探知機は高精度のものを排気口に設置してあった。換気の速度が速すぎて天井に設置しても反応がしないので、ここにしたのだそうだ。
意外な罠
国内だとコンテナほどの大きさの物を移動する事には、道交法的な制約がある。工場から持って行ってポンと設置なのはその通りなのだけど、「持って行って」が意外と面倒という。国際規格の船舶用コンテナならば陸路での移動も考慮しているのかと思ったが、港湾設備付近に高規格道路が整備されているぐらいでどこにでも運搬できるものではないらしい。
コンテナデータセンタと言ったら、あの船舶に搭載するコンテナを流用するものとばかり思っていが実際にはサイズなどの点でそのまま使うよりは搭載機器や移動の都合を考えて違うサイズのものを使っているとのこと。
感想
仮想化技術を使ったCPUのリソース貸しサービスというのがある場面では非常に有用であるという認識はもちろんあって、利用局面によっては使えるだろうとは理解していた。しかし、長期的にリソースを使うときにはアウトソースのオーバーヘッドもあって、結局自社で場所を借りて運用する方が安価なのが現状認識。
Googleが始めた計算機運用環境の高効率化の競争はこうやって国内まで来てしまうと、本当にラックを借り続けるのがランニングコスト上も安価であり続けるかはかなり微妙になってくるのではないか。あるいは、ラックを借りてサービスを運用することが非常に贅沢なものになっていように思った。
さくらは石狩のデータセンタでかなり先端的な取り組みをしているし、IIJのこれも他社に先んじて行なわれた施策である。実際にはいずれのケースも自社で仮想化などでの利用をするそうでユーザにハウジングサービスで場所を貸すわけではないので、本来は物理的にどのように運用されていても関係はない。
- 作者: ルイス・アンドレ・バロッソ、ウルス・ヘルツル,丸山不二夫、首藤一幸、浦本直彦,高嶋優子、徳弘太郎
- 出版社/メーカー: 日経BP社
- 発売日: 2010/08/05
- メディア: 単行本
- 購入: 1人 クリック: 59回
- この商品を含むブログ (19件) を見る
何を極端なことを言っているかと思われそうだが、コンピュータの歴史からすると至極当然の流れと言える。ちょうど先日読んだ「超マシン誕生 新訳・新装版」という本では1970年代後半に新しいミニコンピュータを設計するにあたって、CPUはもちろん命令セットからそのモデル専用のものを作っていた。その後、CPUは既製品を買ってきてアーキテクチャのみを自社設計する時代(PC-9801やFMR、FM TOWNSなど)もあった。今ではCPUもアーキテクチャも規格品でそれらを組み合わせることで新しいコンピュータを作る。それが今後は市販のサーバを組み合わせて計算機ファームを設計する段階に進んだだけなのだ。
Googleは恐らく確信をもって何年も前からやっている。Amazonもかなり早い段階から気付いていたようだ。Microsoftも追従するようにやっている。Appleも始めたようだ。東工大のTUBAMEはまさにこのモデル、神戸のアレは残念ながら古いモデルだと思う。国内の事業者でこの流れに追従できているところはあるだろうか。楽天も数年前からデータセンタを自営に切り替えつつある。ベンチャー系だと自作のサーバをオフィスに置いているところもある。
写真
施設全景
空調ユニットとコンテナ本体の接続部。手前が冷却側で、奥が排熱側。コンテナ側にある扉は非常扉
空調と基礎のと接続は電気と加湿用の細い水道管だけ
ラック側の接続は太い電力ケーブルのみ
中に入るには前室を経由する
ラック全面。機器は熱源として使っているだけ。ここ全体がコールドエリアとなっていて、排気から分離されている。ちなみに"Of course it runs OpenBSD :)"で、ラックの前後に取り付けた温度センサーで集計なんかにも使っています。
温度センサーは多分これ。全部で80ヶ所ほどで計測している。
冷たい空気が背面に抜けてしまわないようにとりあえずの目張り。正式運用時にはラック側で気密性のある構造になるになる予定とのこと
2.6.35に実装されたRPSという機能について
2.6.35が出たので、Linux_2_6_35 - Linux Kernel Newbiesで変更点を眺めていたらRPS/RFSという機能が入ったことに気付く。
RPSとはReceive Packet Steeringの略称で、受信パケットの処理をマルチCPUで分散させることで、スループットの向上を図る機能であるらしい。パッチの提供主はGoogle。
昔kernelの本を読んだときはキャッシュの有効活用の点からあまり分散させると良くないと聞いていたのだけど、8wayぐらいが普通にゴロゴロしている状況ではそうも言っていたれなのかもしれない。8コアの環境でのベンチマークでは2から3倍程度の性能は出たとのこと。
実装を見てみる。Linuxのネットワークスタックの動き自体の概観は送受信 - Linuxカーネルメモ が非常に参考になった。
機能の有効/無効はnet/Kconfigで制御しているのだが…、説明がない。
CONFIG_RPSでifdefされたところを追いかけただけなのだけれど、実装は net/core/dev.c に集中しているようだ。tcpやudpの中にもRPS関連の関数を呼び出す部分が細かく追加されている。
パケットの振り分けのコアとなるはdev.cのget_rps_cpu()。コメントにもある通り、netif_receive_skbから呼ばれて処理をするCPUを返すという処理を行う。netif_receive_skb自体はNAPIの経路で使われる関数で、従来のnetif_rxから来たときにも同様に振り分け処理が実施される。
ハッシュ対象は典型的なIPv4/TCPの場合、srcとdstのIPアドレスとポート番号と対象としている。行きと帰りのパケットで同じCPUが選ばれると嬉しいので、src/dstを正規化した上でハッシュをとっているのが面白いと思った。
実際にハッシュ関数を呼んでいるのは以下の行
skb->rxhash = jhash_3words(addr1, addr2, ports.v32, hashrnd);
呼び出し元のnetif_recieve_skbでは
int netif_receive_skb(struct sk_buff *skb) { if (netdev_tstamp_prequeue) net_timestamp_check(skb); #ifdef CONFIG_RPS { struct rps_dev_flow voidflow, *rflow = &voidflow; int cpu, ret; rcu_read_lock(); cpu = get_rps_cpu(skb->dev, skb, &rflow); if (cpu >= 0) { ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail); rcu_read_unlock(); } else { rcu_read_unlock(); ret = __netif_receive_skb(skb); } return ret; } #else return __netif_receive_skb(skb); #endif }
となっており、受信処理の実体を呼ぶところが、振り分け先のCPUが決定されればCPUごとのキューに追加する処理に置き変っている。
その他udpの中にも、net/ipv4/udp.cで
int udp_disconnect(struct sock *sk, int flags) { struct inet_sock *inet = inet_sk(sk); /* * 1003.1g - break association. */ sk->sk_state = TCP_CLOSE; inet->inet_daddr = 0; inet->inet_dport = 0; sock_rps_save_rxhash(sk, 0);
という処理が入っており、ソケットと処理CPUの対応をクリアする処理が入っていたりする(tcpも同様)。
フローやソケットごとに特定のCPUに処理を割り当ててキャッシュを有効に使いながらパケットをCPU間で上手く分散する処理だなと思った。考えていたより実装分量がずっと小さい、CPU毎に受信キューを持つ機構自体は従前からあったようなのでむしろこの分散処理が無かった方が不思議というか。
HT-03Aをカスタムファームウェアにすると速くなる理由
カスタムファームウェアといっても色々あるので下記のうちどれが使えるかはそのROMに依ります
