購読中です 読者をやめる 読者になる 読者になる

今更ストレージサーバーをFreeBSDとZFSで組んだ話

家にTimeCapsuleが2台あって、Mac miniも一部ストレージサーバーになっていて、デスクトップマシンにDVDを保存していて、しかも写真はS3にバックアップしてたんだけど、そろそろMac miniが一杯になってきて…という、まあいろいろ限界に近づいていたので我が家のストレージ用に一台新調した。

買ったもの

@Dospara 注文番号:xxxxx
------------------------------------------------------------------------
◎出荷された商品
TOSHIBA DT01ACA200 バルク[2TB]      [ 2個 ]
SanDisk SanDisk Ultra?SDSSDHII-120G-... [ 1個 ]
Intel Core i5 4590S BOX          [ 1個 ]
ASUS H97-PRO               [ 1個 ]
ADATA AX3U1600W4G11-DD (DDR3 PC3-1280... [ 2個 ]

とりあえずこれだけ買って、ふつうに組んだ。ハコは10年近く使っているものがあるので、それを流用。電源だけは先代のものを流用できたけど、Phenom X2とかAGPのグラフィックボードとかいろいろ古かったので、そのあたりはバッサリとさようなら。既存の SATA HDDが 250GB, 500GB, 500GB とあったので、そいつを利用してうまいことZFSなら…ZFSならやってくれるさ…!と思っていた。

SSDは単品でブートパーティションに。SSD内部で冗長化機構をいくつも持っているし、機械部品がないから故障率は少ないはずだ。ハズレを引かなければメモリやマザボと同等の寿命になるはず。仮にSSDが吹っ飛んでもまた買ってきて入れなおせばそれでよいのでOK。ストレージにするといっても常時起動ではなくむしろコールドストレージ(ほとんどオフにしておいて、必要なときだけ火を入れる)として運用するので可用性の要件もそんなに高くない。

memtest86

とりあえずこれ。MacBookUSBメモリに焼いて動かせるのはこれ(公式のやつだとうまく焼けなかった)。

To burn USB stick in Mac: http://www.memtest86.com
Technical instructions: http://www.memtest86.com/technical.htm

まあそんなに頑張っても仕方がないので、2時間ほどまわして納得。

FreeBSD 10.1

いい時代になった。CD-ROMなんか焼かなくても、USBメモリがあればカンタン。16GBとか、そんなにいらねーっていう。ミラーサイトを選択してMacで焼けるように FreeBSD-10.1-RELEASE-amd64-memstick.img.xz をダウンロード。

$ sudo dd if=FreeBSD-10.1-RELEASE-amd64-memstick.img of=/dev/disk3 bs=10m

diskutil list を活用してちゃんとUSBメモリを特定する。これでUSBメモリから起動する。

FreeBSDのインストールは簡単。zrootも簡単だった。rc.confをちょっといじるだけ。IPアドレスも固定。特殊なドライバも入れない。カーネルは一応GENERICでビルドしなおしたけど、これでCPUの最近の命令とか使えてるのかな。まあどちらでもよい。しかしここからが大変だった。

ZFSに慣れる

同僚がものすごいZFS推し(Solaris推しでもある)なので、ZFSを使うことは決めていた。しかし中途半端なHDDが3枚。2TBが2枚。なんとかローコスト運用して、HDDが壊れる度に大きいサイズのもので置き換えて徐々に拡大していきたい…
とりあえず何も考えずにいきなり zpool create しちゃうと、GPTパーティションがないやつもそのまま上書きでグダっとなってしまう。そいで corrupt とかいわれるので、予め

# gpart show
...
# gpart create -s gpt ada4
# gpart add -t freebsd-zfs -a 4k  ada4

としておく。こうすると /dev/ada4p1 ができるので、基本的にはこいつを使う。こんな感じ

# zpool create tank mirror ada1p1 ada2p1 ada3p1 mirror ada4p1 ada5p1
# zpool status tank
 ... tank の構成と状態がきれいに表示される

記憶が定かでないが、たしかこういう構成にしたと思う。ada1 ~ ada3 までが不揃いのHDDたちだ。これだけで自動的に /tank にマウントまでされてしまう。便利。LinuxVFSでウダウダ頑張っていたのがウソのようだ。

ストレージプールをバラしたいときは zpool destroy tank で一発だ。ウッカリやってしまわないように気をつけよう。

障害時の対処はこのあたりを参考にするとよいだろう。

これはメモにあったのだけど…パーティション作成の方法かな。gpartがたまに拗ねるときがある気がするんだ。

障害対応、いきなりの実践

しばらくそれでZFSで作ったり壊したりして遊んでいた。で、そろそろデータを全部移すか…ってなって、ひととおりコピーし終えた頃にやりやがった。 ada2 故障。autodetachされていた。ZFSは優秀である。とりあえず電源落としておいて、もうなんか500GBのやつをもう一度買っても切ないので秋葉原でWDのGreenを2TB 追加購入。ドスパラで買うと3年くらいの保証が無条件でついてくるのでお得だ!これが秋葉原での某DB飲み会の日だったので、4月10日だな。忘れないようにしよ。

いざ土曜日(だったっけ?)、古いHDDを何も考えずに挿して zpool add ada1p1 ada2p1 しちゃうと、セクタサイズが512Bのままになっていて…だかなんだかで zpool status の結果に "block size: 512B configured, 4096B native" と出てくる。どういうことだ。resilver は自動で動作している…が、きになる。ということでいろいろ調べる。

古いHDDはセクタサイズが512Bなのだけど、一方で最近のHDDはセクタサイズが4Kになっている。これをmirrorしちゃうと…セクタサイズが512Bのmirrorになっちゃう!スレの内容をまとめると、まあコイツが出てしまうともう戻らないってこった。新しいプールを作って import/export でやり過ごすくらいしか手はない。zpool 全体でどうなってるかは zdb -C | grep ashift でわかる。 9なら512B, 12なら4096B の模様。

僕はまだ新品のHDDもあるし、データはまあMac miniとかに散らばっているものをまた持ってくればよいので、バッサリと zpool destroy した(その前に一旦一枚ザラの単品パーティションにコピーした*1 )。いい機会なので、2TBのHDDを4本使ってふつうにサイズを揃えて運用することにした。

# zpool create data mirror ada1p1 ada2p1 mirror ada3p1 ada4p1

これだけ。RAIDZにしなかったのは特に理由はないが、仕事でErasure Codingに手を付けられていないので、いくらみんなが安定運用しているといってもちょっと怖かったのだろう。いや理由を思い出した。最初に4本スタートしてしまうと、構成をあとで変えられないからだ。

豆知識: GPT table is corrupt と /var/log/messages で言われたとき

# gpart recover <geom> 

http://yomemacs.hatenablog.jp/entry/2014/02/04/205509

TimeMachineバックアップに使う

netatalk3を入れよう

$ sudo pkg install netatalk3

参考

これでふつうにMacOSからも見れるようになるので、TimeMachine用、DVD鑑賞用、写真バックアップ用のパーティションを afp で見えるようにする。Go To Server...とかで afp://192.168.1.42:5128 とか適当にやっておけばOK

ログの監視

よく考えたらコールドストレージだから死活監視もクソもないのだが、起動時にあえてやるとしたら、いい方法がなかった(NewRelicとかそういうカッコイイのは大げさすぎる)ので、はやりのMQTTというやつを使ってみた。

$ tail -F /var/log/messages | mosquitto_pub -h lite.mqtt.shiguredo.jp -p 1883 -t "<name>/kushana/var/log/messages" -u <name> -P <passwd>  -r -l

としておけば、適当にどこからでも見れる。

$  mosquitto_sub -h lite.mqtt.shiguredo.jp -p 1883 -t <name>/# -u <name> -P <passwd>

まあ必要ないのだけどね。

電源を落とす

$ sudo shutdown -p now

電源管理機構があるとこれで動く。Linuxだと -h で電源落としてくれるのだけど、FreeBSDだと古式ゆかしい halt なので、電源ついたままシステムが止まる(コンソールがないので、停止シーケンスがいつ終わったか分からない…)。

TODO

やりたいこと

  • DVDをストリームするサーバーを立ち上げる
  • pipが動かない
  • Erlang/OTP 17.5 が --disable-hipe でコンパイルできない
  • 妻のTimeMachineをホスト

やらないこと

  • Wake on LAN: 手でボタン押したらええやん
  • TimeCapsuleの廃止: 複製はあればあるほどよいのだよ!

最後にもう一枚。よいショットだったのでどっちを使うか迷った。

*1:このときの cp -r が、ファイル名の辞書順ではない何かよくわからない順番でファイルをコピーしていたのだが、どうしてだろう? /usr/src/bin/cp のコードは3分で飽きてしまった

QConTokyo 2015 で喋ってきました

QCon Tokyo 2015 Conference|QCon 東京 2015 カンファレンス

QConTokyo 2015で、データベースアーキテクチャーの動向と使い分けというお題で発表する機会があった。Bashoは2014年2015年にかけてQConのグローバルなゴールドスポンサーをやらせてもらっていて、ロンドン、サンフランシスコでも社員が喋った。東京は…英語以外の言語での開催はここだけなので、で、日本語でQConぽい話ができる…ということで僕が喋ってきました。

speakerdeck.com

有料イベントで話すのは初めてなので、果たして対価に見合う話を聴衆にできるのか全く自信はなかった。裏番組はGoogleの中の人が話すGolangセッションだから、そもそも人が来ないかもしれない。と思ったら一番広いホールじゃねえか。しかも、いつもはデータベースとかインフラ系の技術に興味持って集まる人が対象だけど、今回は幅広い層の聴衆が来ているはずで、実際スーツの人が多くて…といつもとは違う感じだった。

特に聴衆の関心が読めなかったので、データベースの細かい技術の話やバズワード、マーケティング的ポジショントークなんかをなるべく入れないことを前提に話を練ったのでわりと苦労した。ここまでちゃんと準備してスライドを考えたのは初めてかもしれない。話の筋を考えることに集中したので、結果的にスライドにほとんど絵を入れられなくて文字ばかりになってしまったので、当日はちょっと退屈そうな人もチラホラいた。非常に申し訳なかった。ぼくも文字ばかりのスライド、本当は嫌いだ。

ぼくがあの話をしたその翌日にHacker Newsで Call Me Maybe: MongoDB Stale Reads | Hacker News のスレが盛り上がっていた。このはなしは大分昔にKyle KingsburyがちょっとTwitterで書いていたのでなんとなく知っていたが、果たしてどうなることやら…w 偶然だけど、日本ではLAMPスタックに加えて解析基盤と非同期実行のMQが入り始めたくらいで、システム自体の複雑化や大規模化がそこまで進んでないようにみえる。だからまだ問題になり始めていないのだけど、ネットワークは信頼できると思ったら大間違いなわけで、そういった認識が日本でも広まればいいなと思って書いた。データベースの技術はそのネットワークに依存しているわけで、そこはさすがに同意していただけるかなと思う。でもまあ、当たらぬも八卦、当たらぬも八卦ということで今後の成り行きを見守っていきましょう。

QCon当日はいろんな人と話したり、いろんな話を聴くことができて、世の中にはデータベースだけじゃないんだなあと改めて当たり前のことを確認したのであった。しかしテクノロジーカンファレンスなのだから、会場のWiFiはもうちょっとなんとかできると思うぞ。カンファレンスネットワーク、わりと技術的には難易度高いけどホラ、今は日本にもCONBUとかあるから。

「技術」という言葉について

とくにソフトウェアとかインターネット的な世界のはなし。典型的な用法は「〜〜という新しい技術を仕事で使いたいのだけど、上司が許可してくれない」というものだ。この〜〜には、たとえばちょっと前だとLAMP, Ruby on RailsとかAWSとかHadoopだし、今だとなんだろう、DockerとかC#かな。うーんこの違和感。私の定義では、これはどれも技術ではない。ただのソフトウェアだ。AWSはサービスだ。

TCP/IPSIPは技術だろうか?わたしの感覚ではノーだ。ただの仕様だ。いずれもベースになっている技術はあって、たとえばパケットのルーティングや名前解決、フレーム再送やウィンドウ制御の仕組みや実装は技術といっていいだろう。Hadoopは分散処理の技術を実装したソフトウェアだ。LAMPWebサービスを実装するためのソフトウェアスタックの総称で、そのなかに様々な要素技術はあるだろう。Dockerの中で使われいているAufsや依存性管理の仕組み、名前空間などを使ってインスタンスを分離する仕組み自体は技術だが、「Dockerという技術を習得する」という日本語は間違っている。

もうちょっと展開してみよう。Git引いてはGithubソースコード管理などのツールとして導入したときに、「Githubという技術を導入した」とは言わない。「Gitという技術を導入した」これもおかしい。「レポジトリを分散して管理できる技術を実装したGitというソフトウェアを使って、分散レポジトリを活かした開発フローを導入した」これくらい言わないと技術という言葉は使えない。課題を解決する体系立てられたワザを技術というのであって、ソフトウェアやサービスそのものを技術とはいわない。

わたしの感覚だと、片仮名でテクニックといわれる種類のものの方が技術と呼びやすい。たとえば探索系の問題があったときに単に深さ優先にするのではなくて、DPで実装する。数値計算ならdoubleとfloatで使い分けるコツが違うし、できればSIMD使いたいけどちゃんと実装するのは難しい…(SIMDをちゃんと実装した数値計算のライブラリがあったとして、それは単にライブラリであって技術とは呼ばない)。たとえばMySQLのbinlogレプリケーションはSplit brainが起きるけどSQL ServerならPaxosを使っているのでそれが起きない、とかそういうの。

よく「○○を支える技術」といって、その会社なりサービスを支えるソフトウェアスタックや、その運用を紹介する本が出版されよく買われるようだ。その本は、単に採用されているソフトウェアなりサービスのリストが書かれているわけではない。大抵はそこにある課題と、それを解決する方法が書かれていて、その方法のひとつの実装としてソフトウェアなりサービスの名前が載っているわけである。

もうちょっと違う説明の仕方にしようか。たとえば自分たちのECサイトにリアルタイム推薦を導入したい。そのときにリアルタイムレコメンドができるJubatusを導入するとしよう。Jubatusは新しい技術か?わたしの定義ではそうじゃない。Jubatusはソフトウェアだ。そこに実装されているLSHや、それを複数ノード間で同期する仕組みは技術だ。別にJubatusじゃなくてもSolrでもなんでもよい。Solrそのものはソフトウェアだ。その中で実装されているTokenizerや転置インデックス、インデックス更新の仕組み(詳しく知らない)は技術だ。やりたいことを実現する手段なり工夫なりを技術というのであって、ソフトウェアやプロトコルのことを技術とは呼ばない。

これが私の定義なのだが、Wikipediaなどを見ると「そもそも多様である」的なことが書いてあるの。インターネットでちょっと私の定義の合わない用法があったとしてもまあ言葉狩りだと思われたくもないので、まあ喧しく言わないようにしてここに書いて忘れることにする。

ちなみに、件の上司は、「○○という(仕事の)課題は、△△という技術で解決できるのですが、それを実装したものは〜〜というソフトウェアしかないので、〜〜を使うしかないです」といえば説得できると思う。それであなたが使いたいものは何でも仕事で使えるようになるよ。

キッチンライフを少しだけ楽しくする課金アイテムKitchen Aid

我が家では家事を楽にするための設備投資は推奨されている。最新の課金アイテムはキッチンエイドのスタンドミキサーというやつだ。これの便利さは折り紙つきで、なにせ手を汚さずにいろんなものを混ぜることができる。海外の料理番組では「キッチンエイドの目盛り4で5分間混ぜる」といった風にレシピが記述されているらしい。アタッチメントをいろいろとつけかえることで、様々な混ぜ具合や材料に対応している。テクノロジーは人間を楽にするだけでなく、作業を定量化することにも貢献しているのだ。ハンバーグをこねる、餃子のタネをこねる、クッキーやケーキのもとを作るといった用途で広く知られているこの道具だが、今回はちょっと変わった用途に使ってみた。

今回の材料は納豆である。納豆の既製品を買ってくるまでは異論の余地はないだろうが、その食べ方にはさまざまな議論がある。そこにかけるものの多様さは生卵、刻んだ葱、醤油、等々。中でも混ぜ方は大きな問題で、

すこし検索すればわかるが、いくつか流派があるようである。わたしの理解だと、およそ5〜10分ほど箸で力を入れて混ぜるのが泡立ちと粘りのバランスがとれていて丁度よさそうだ。一方で妻はあの泡が苦手で、ほとんど混ぜないのが好みなのだそうだが…今回問題にしたいのは、ちょうどよい混ぜ具合になるまでのあの手間である。腕が疲れる。指が疲れる。白飯が冷める。飽きる。もうやだ。でも粘りのある納豆を食べたい。ということでキッチンエイドで納豆を混ぜた。その様子を撮影したのでご覧いただきたい。


Mixing Natto with Kitchen Aid - YouTube

これは、KSM5という機種のスタンドミキサーで6〜7分、目盛り2〜3にして混ぜたときのものである。納豆は一般的な3パック組のものを一度に3パック投入した。粒はいささか大きいが、小粒のものにしておけばより潰れにくいだろう。人間が混ぜるよりもはるかに高速で強力な様子がわかるだろうか。

そうして混ぜたものの結果がこれだ*1

今回は実験的な意味もこめて少し長めに混ぜた。おそらく混ぜ時間は4〜5分が最適ではないかと思う。長く混ぜてしまうと、粘りが落ちてきて粒が潰れてしまうためだ。しかし写真の品は泡がよく肥大し、米粒とよく合わさって味は非常によかった。粘りが苦手という人はキッチンエイドを使って長めに混ぜてみると、手で混ぜたのでは得られない食感が得られてよいかもしれない。

*1:カラシが垂れているのは付属品のご愛嬌ということで勘弁

Papers We Love というコミュニティ

第4回 システム系論文輪読会 - connpassが開催されると聞いて、思い出した話。日本だと、○○読み会という形で、特定の国際会議の論文をうわぁーっと集中的に輪読するコミュニティはいくつかあるけど、ある分野なりをまとめて回し読みしようという試みはないように思うので、ここで Papers We Love というコミュニティを紹介しようと思う。


Papers We Love Too - October 2014 - YouTube

予め断っておくが、ぼくはまだ参加したことはないし、同僚がたまたまファウンダーの一人なので知っただけだ。これがなかなか面白い試みだ。

Papers We Love is a repository of academic computer science papers and a community who loves reading them.

ということで、計算機科学のよい論文を集めたリストだ。たまに集まって発表会をやっている。過去の発表の動画がいくつかまとまっているので、様子がわかるかもしれない。発祥はニューヨークだが、トップページにあるように今ではアメリカを始めとして欧米でにわかに盛り上がっている(と思う)。

なんといっても充実しているのは分散システムのディレクトリだ。私が知っている限り重要なものはほとんど入っている。ひとつひとつ読むと時間がかかりそうである、が、読まねば…。積ん読が沢山ある皆様のことだからそんなもの見てるヒマはないというかもしれないが、ひとつ git clone してみてはいかがだろうか。

追記

東京にも有志がいるようなので登録してみた。ぼくが参加できるのはちょっと先になると思うけど…

出張でシアトルに行ってきました

Bashoではリモートワークが基本なのだが(もちろん一部にオフィスもあり通勤している人もいる)、年に何度か社員が集まっていろんなことをする機会がある。詳しくは述べないが、オンラインでできないことをやることが目的だ。

行きの飛行機では映画を2本観た。

  • Big Hero 6 : San Fransokyoという街に住む少年が兄の死の意味を理解する話。戦隊モノ。音楽がかっこいいのでサントラを買おうと思った。
  • LUCY: ロリコンだったはずのリュック・ベッソンスカーレット・ヨハンソンのために作った映画。映画のテーマとは対照的に人がサクサク死んでいく映画。あれ、人間の命ってこんなに軽かったんだっけ…?

機内食は朝のエッグベネディクトがうまかった。やはり全日空しかない。


着いたその日は牡蠣。

次の日はシアトルを散歩。スペースニードル、思ったより低かった。

橦木のない釣鐘。

長い顔

OSS

スタバ一号店。写真ちょっと傾いている

翌日のひるめし。

このビールでかなり酔った。

Pie Bar. このときは通っただけなのだが、後日行って飲んだバーボンとルートビアのカクテルがめちゃくちゃうまかった。

まるまる一尾でてきた鱒。

帰路、Sea-Tac空港でBターミナルの方にあるSUBPOPの店。ウロウロと探索していたら見つけてしまって、思わず衝動買い。

帰りの便では、運良くプレミアムエコノミーにアップグレードしてもらうことができて、快適な旅をした。もうプレミアムエコノミーなしでは無理かも…

Gone Girlという映画を観た。基本的にはサイコパスのお話なんだけども、親子の確執とか継承とか、結婚の難しさとか、メディアのプライバシーとか重い話のなかで兄弟愛だけが救いですな。最初はサイコパスの話だと知らなくてハラハラしながら観てしまったが、あとから思えばなんだか損した気分である。

自分用にGrumpy CatぬいぐるみをSea-Tac空港で買ったのを置いてみた。こいつぅ…

うちにはヘンなぬいぐるみが揃っている。

Netflixのモダンなクラウドベースのプラットフォーム

生活リズムが乱れることがしばしばあって、たとえば遅くまでプログラミングの仕事やネットサーフィンをすると脳が興奮してなかなか寝付けない。もともと寝付きが悪くて、遠足の帰りのバスも一人だけずっと起きてるような子供だったのでまあ仕方がない。さらに歳のせいか、連続して睡眠できる時間が短くなり、パフォーマンスの低下につながることが多くなった。

そこで真人間を目指していくつか施策を打っているのだが、そのひとつが布団のなかでPodcastを聞くというものだ。これは @omo2009 さんがTwitterLeslie Lamportのインタビューの話をしていて、聴いてみたら思っていたより面白かったのがきっかけである。

そういうわけで、ちょっと眠れなそうな夜には、イヤホンを寝室に持ち込んでこのIEEEのPodcastを聴くことにしている。他にもいくつかチャンネル登録しているものがあるのだけど、それはいい話があったら紹介したいと思う。

さて今回聴いたのは、
Episode 216: Adrian Cockcroft on the Modern Cloud-based Platform という話で、元Netflixのおっちゃんがモダンなクラウドベースのプラットフォームはどうあるべきか、どうやったら動くのか、という話をしてくれる。

まあ「ちょっと分散システムの実験したいときに200台のサーバーを10分くらいで立ちあげれるのはすごいアドバンテージだよね」とか「要は普段必要なものよりも大きいコンピューターリソースのプールが常にじゃぶじゃぶあるのが重要(なのであって、プライベートでもパブリックでもどっちでもいい)」というのはクラウド使ってる人だと常識だろう。5000万人にコンテンツを配信して行動をトラッキングして推薦するとか鬼のようなスケールでやっているわけだけども。一部ではまだオンプレ残ってるというのも面白かった。

仕事柄面白かった言葉は "Every Slice of Service" だ。可用性が重要。どんな障害があってもとりあえず顧客がテレビをみるのが止まったり遅れたりしてはいけない。ネットワークが切れたり不調になったりしても、サービスを構成するシステムをどう輪切りにしても、ひとつひとつの輪切りでストリーミングのシステムが上手く動いてないといけない。NetflixではよくChaos Monkeyが話題になるけど、ノードだけじゃなくあらゆる故障パターンをちゃんと想定して運用している(そういう障害を経験したから言ってるのだろう)。一方で全部そういうアーキテクチャにするのは無理なのでバランスとるのも必要なのだけど。

マイクロサービスの話もしてたか。Javaのモジュールのバージョン依存性の管理や、巨大クラスができる話、わずかな変更がサービス全体をぶっ壊してロールバックするリスクとかそういうの。是非とも聴いてみるとよい。よく眠れる。わたしも最後まで聴くのに3晩かかった。

もともとテックなイベントでの発表動画や、最近はやりのなんとか.fm系のやつは人間の喋る速度に律速されるので情報密度が低いから文章読んだほうがマシだろと思っていた。のだけど、情報密度を上げて文章にするとそれはそれで僕のような読書しないもやしっ子にはもともと難しい話だった。脳に筋肉が足りないのである。人間の話す声というのは素晴らしいものである。

ちなみに日本語のPodcastは、元深夜ラジオ勢としては聴きこんでしまって眠気を飛ばす恐れがあるので、購読していない。