FreeBSD

いってきた: 第14回FreeBSD勉強会 FreeBSDによるビッグデータ処理プラットフォームの構築

いつもどおり、おやつをたべてから五反田→有楽町→麹町ルートで会場へ。

DSC03519DSC03520DSC03522DSC03585

新年なのでまずは乾杯から始まった。プシュっと。

DSC03524

進行早め(オフレコの内容もあり)だったのであまりメモとれず。資料は公開されないけどFreeBSD Expert Digital Editionに収録されてるそうです。

DSC03527DSC03575

  • USP:
    • 東急ハンズの内部はシェルスクリプト
    • 大学と共同研究してたり、InfiniBandで直結して直列計算させたり
    • よくつかうコマンドは40〜50くらいしかない。
    • 金曜日にコマ研がある。「このコマンドは要る・要らない」を議論。
    • 開発が早い:金曜に打ち合わせして、月曜に動くものをもってくとか。
    • 仕組が簡単なので自社開発できるようになる。
    • オンメモリ+InfiniBand
  • Hadoop:
    • 意外とスケールしなくて手を焼いている案件がけっこうある。現場のエンジニアが設計できなかったり。
  • Bigdata Expo 2012 fall
    • 1億件を数秒で処理が全国レベル→10億件処理を目指す (hadoopだと100台規模)
    • 10億件ソート90秒
    • 100億件サーチ1秒
    • Intel X540-T2: 売ってない。秋葉原をまわって店が別案件に売る予定だったのを買い占める..
  • FreeBSDはn:mスレッドモデルだったが1:1にしたら意外と速かった(しかもすっきりしてる)。
  • でも16コアだと性能が落ちた...
  • いまのエンジニアはNoSQLを使い分けられる人がもとめられている。
  • コアを増やすとメモリバスがきつくなって性能が落ちる方向。コアを増やすことに金をつっこめばいいというわけではない。
  • ハードウェアのちょっとした違いで性能がぜんぜん違うので実機で性能測定してから設計にはいる。
  • I/OがサチっているのかCPUがサチっているのか、見極める必要がある。
  • HWの限界、ファイルシステムの限界、システムコールの限界。
  • 3.2GB/sくらいでるので目安。
  • ULEスケジューラはコアを固定して実行するよりも良い性能が出せる。
  • core i7とxeon: 目的によって使い分ける。
  • tmpfsとmfs:tmpfsの方が早い場合も..
  • powerdを動かすとpowerdが電気を喰ってしまうとか.... ハードウェアにまかせた方がよい場合もある。
  • 10GbE
    • ソースのREDMEに設定がかいてあるので設定はそこをみる。
    • スイッチは高い。
    • メモリをたくさん喰うので4枚も刺すと認識されなくなってしまう。nmbclustersを上げるのが肝。
    • mtu 16114は重要。IBは設定しなくてもいいけど。
    • NICの初期化が間に合わないのでrcスクリプトにsleep 10を入れて逃げた..
    • 再起動しないと設定できないのがきつい。
    • MTUはデバイスごとにちがうので、READMEをみて確認する。
    • FreeBSDのブリッジ機能をつかってスイッチにした。ブリッジのMTUも引き上げておく必要がある。
    • netcatがジャンボフレームに対応してない。nc -jで。新しいncからはコードが消えてるので古いのをとっておく必要ある.. おおもとのコードから消えてたのでマージして消えた.
  • IB
    • WITH_OFED=yesでopensm(マネージャ)がつくられる。

[2013-01-11 20:10]

  • 佐藤先生がリリースノートを書かないとリリースされない...
  • AsiaBSDCon:個人の寄付もうけつけている。

[2013-01-11 20:15]

QA

  • ディスクIOの性能はよくわからない。
  • BOAは結局メモリがボトルネックになった。
  • CPUのパフォーマンスカウンターはみてない。

[2013-01-11 20:20]

DSC03591DSC03588DSC03590

懇親会は21:50くらいに終了。後藤さんは明日も早いらしい...

DSC03583DSC03586

いってきた: 第13回 FreeBSD勉強会 「ZFS の活用とチューニング」

夕方に大きな地震があったが、ちょっとダイヤが乱れたくらいで、勉強会は開催。

DSC02563DSC02564DSC02569DSC02572DSC02571DSC02573

DSC02577

DSC02579DSC02580DSC02581

ZFSの活用とチューニング

使い方(前半)

  • FreeBSD9.0/9.1はチューニングしなくてもそこそこ性能はでる。アプリによっては性能が落ちるポイントがある。
  • ZFSはハードディスクがいっぱいつながっているのが大前提。1台だとうれしいことはなにもない。
  • ZFSは既存のファイルシステムのいいとこどりしている。トレードオフになっているところはCPUなどマシンパワーで解決する。
  • zpool = ストレージプール = ブロックデバイスのあつまりに名前をつけたもの
  • ZFSデータセット = ZPOOL上に構成できる名前空間 = ファイルシステム/ボリューム/スナップショット
  • FreeBSDにはOpenSolarisのコードそのまま取り込まれた。ライセンスはBSDに近いものなので取り込んでも困ることはないもの。
    • StoragePoolAllocator(SPL)のバージョンン: ミラーとか重複排除とかが関係。今は28。
    • ZFS POSIX Layer(ZPL)のバージョン: ユーザからはあまりみえないが、カーネルとのAPI。今は5。
    • この2つのバージョンで使える機能を判断する。
  • OpenSolarisは虫の息...
    • OpenSolarisはだんだんオープンじゃなくなってきている。もう1年半以上あたらしいコードが出てない。
    • Nexenta: illumosをベースにしたストレージを出してた。ソフトだけで商売しようとしてる人たち。
    • いろいろZFSのforkができたが、
    • illumos projectがZFSのコードのとりまとめをしてくれそうな感じ。
  • FreeBSDのZFSは9系か8.3以降を使うべし。それ以前は落とし穴がいっぱいある。
  • マシンはamd64 RAM=4GB以上。1GBでは性能が出ないし止まってしまう可能性もある。
  • ZFSの管理が簡単になるというのは、いままでコマンドラインでUFSをさわってた人にはあまり簡単になったとは思えないかも。
  • FFSのスナップショットはつかいものにならないがZFSのはつかえる。
  • jailの中からでもファイルシステムの安全に操作できるのがメリットの1つ。
  • ZFSはライセンス汚染を避けるためにモジュールになっている。使おうとした瞬間にロードされる。明示的に設定しなくてもよい。
  • zpool create pool da1 da2 でプールをつくったらすぐに/poolがつかえるようになってしまう。
  • ストライピング幅は動的に決まる。
  • zfsがマウントされるのは、プールが認識されたらすぐにマウントされる。/etc/fstabは見ない。
  • zfs_enable=YESが評価されてプールが認識されるのは/etc/fstabを見るよりも前。
  • zpool destroyでデータも全部消える。確認はない。
  • "zfs create プール名/データセット名" でファイルシステムができる。ファイルシステムのサイズは指定されてないことに注意。複数ファイルシステムをつくったらシェアされる。
  • データセットは階層構造をもっているが、マウントポイントの階層構造はそれとは関係なく設定できる。
  • 設定は設定ファイルではなくプロパティにはいっているのでコマンドをバンバンたたいていく。(Solaris流儀)
  • "zfs snapshot プール名/データセット名@スナップショット名" でスナップショットがつくれる。スナップショット名は自由に決められる。
  • スナップショットをつくってもマウントポイント設定されない。ディスクの使用量USEDは0。スナップショットの一覧は "zfs list -t all" でみえる。
  • スナップショットは "zfs set snapdir=visible" にしておくと.zfsの下にみえるようになる。
  • "zfs rollback プール名/データセット名@スナップショット名" でスナップショット時点の内容に戻る。
  • "zfs clone プール名/データセット名@スナップショット名 プール名/新データセット名" でファイルシステムの複製をつくれば容量をつかわずに複製がつくれる。(スナップショットは書き込みできないのでcloneする必要がある)。
    • 微妙に設定がちがうシステムディレクトリをつくるときとか。jailで便利につかえる。
    • クローンというデータセットがあるわけではなく、あくまでもファイルシステムとスナップショットの合わせ技でしかない。
  • バックアップはzfs sendでできる。
    • 従来のファイルシステムではスナップショットやチェックポイントをネイティブでもっているものは少ない。
    • fileコマンドはsendの出力をしっているので、スナップショットの作成日などが表示される。
    • zfs recvでリストアできる。zfs cloneとちがって本当の複製。
    • "zfs send -p" でプロパティもバックアップされるがマウントポイントの設定も保存されてしまうので、
    • "zfs recv -u" で自動マウントされれないようにすべし。(なんで自動マウントがデフォルトなのかは知らん。)
  • zfs destroyはスナップショットがあると消せない。destroy -rでまるごと消せるが注意して。
  • "zfs create -V サイズ プール名/データセット名" でボリュームがつくれる。"/dev/zvol/プール名/データセット名" として見える。
    • ZFSをボリュームマネージャとしてつかうことができる。
    • ボリューム上にファイルシステムをつくっておけばブートシーケンスで、ZFSが読み込まれたあとに/etc/fstabでマウントできる。
    • send/recvもできる。つかってるブロックだけをバックアップできる。
  • ディスクの中にストレージプールの情報が入っているが起動時に全部のディスクを読んでたら時間がかかるので、/boot/zfs/zpool.caccheにも書いてあるが、これが壊れていると起動できなくなる。(つくりなおすことは可能)

[2012-12-07 20:06]

休憩

いつもはぶっ通しでダレてくるので今回は途中で10分休憩を入れることに。

BlogPaint

[2012-12-07 20:15]

使い方(後半)

  • UNIXは設定ファイルの文化だがSolarisはコマンドで設定データベースをいじる文化になっていった。
  • ファイルシステムはかならず2レベルにすること。プール名とおなじデータセットは使わない。スナップショットやバックアップをとるときにめんどくさい。
    • zfs set mountpoint=none poolと設定すればマウントされなくなる。
    • zfs recvのときにsendしたときと同じ場所に戻せないので困る。"zfs send pool@snap | zfs recv pool" はできない。"zfs send pool@snap | zfs recv pool/pool2" はできる。
  • zfs send -Iでスナップショット間の差分バックアップができる。
  • zfs sendでパスワードファイルもそのままはいってしまうので暗号化できる経路をつかうべし。
  • zfs sendが遅い原因の1つはファイルシステムを読みながら出力するので連続的に出てこない。gzipはブロック単位に処理するのでsshにスムーズにデータが流れない原因になる。
    • ddを二段接続してバッファリングしてgzipが暇にならないようにする→gzipの出力に隙間が空かないようにする。10%くらい性能がかわる。
  • zfs diffでファイル単位で差分を抽出できる。スクリプトで処理するときに便利?
  • ストレージプールの種類として「ストライププール」は公式にはそういう名前は書かれてないが便宜上そう呼ぶことに。
  • ミラープールは中身が一致しているわけではない(俺:RAID1のような一致ではないという意味だとおもう)。どちらか1台が故障してもだいじょうぶ。
  • 4台構成でミラーにしないんだったらダブルパリティのRAIDZ2にするのがおすすめ。2台壊れてもだいじょうぶ。
  • とにかくZFSではプールは冗長構成にすべき。コピーをつくることで信頼性を担保しているので。
  • ホットスペアも指定できる。指定しておけば自動的につかってくれる?
  • zpool replaceで動作中にディスク交換できる。
  • zpool addではプールの形式を変えないで追加される、zpool attachではミラーに構成を変えて追加される。
  • zpool scrubはfsckのように一貫性をチェックするものでは「ない」。(やすいディスクなどで)ビットの反転などを検出するためのもの。
    • dailyで動かす必要はない。zfsがアクセスしたときに自動修復してくれるので。アクセスされてないデータを強制的にアクセスするためのもの。
    • scrubの頻度は機器の信頼度による。業務でつかうようなディスクなら1〜2ヶ月でok。エラーが検出されるようならコネクタとかメモリを疑ってみる。
    • scrubは/etc/periodic.confで設定できる。いろいろ議論した結果デフォルト周期は35日。(ただし、デフォルトではscrubしない)
  • zpool export/importは自動で読み込むかどうかの切り替え。
    • 別のマシンに一時的にディスクをもっていってつないだ場合には/boot/zfs/zpool.cacheを書き換えて自動マウントされるようにはなってほしくない。
  • FreeBSD9.1以降ではRootFS on ZFSはつかえるようになるはず。それ以前はいろいろ落とし穴があった。でも手動でやる必要がある。
    • ひみつのgpart add -s 122 -t freebsd-boot..
    • rpoolはroot poolの意味
    • zpool.cacheを自分のファイルシステムの中につくらないといけないのと、CDROMブートだと書ける場所がないのがめんどうなところ。
    • そのうちメニューを選んでできるようになるはずだが..
    • おまじない zpool set cachefile="" rpool
    • zpooltest.shでブートできるかチェックできる。ブートに失敗するとリカバリーがたいへんなので事前にチェック。
    • システム更新したらとにかくzpooltest.shでチェックすべし。zpoolが読めないとヤバい。zpooltest.shが通ったら*たぶん*だいじょうぶ...
    • 起動プールとデータのプールは分けておいた方が、管理が簡単。

[2012-12-07 21:03]

性能とチューニング

  • ZFSはリンクをたくさんたどるがキャッシュ効いているはず、という仮定がおかれている。
  • UFSとちがってZFSは複数のディスクをあつかうのでストライプが効くはず、という仮定もある。
  • 書き込みは、ディスクのwrite backキャッシュが効くのにCoWのせいでランダムアクアセス読み込みが発生して、キャッシュがヒットしないと性能がぜんぜん出なくなる。
    • ベンチマークだとZFSが瞬間的な性能が出ないせいで悪い値がでてしまう。
    • disk 3本でベンチした例: gstripeは性能が出るのにzfsストライプだとディスク単体のIOPSしか出ない。原因は書き込みでも読み込みが入るため。
    • ベンチマークはキャッシュが効かないように工夫されてるのでZFSでは性能評価は低くでる。
  • 空き容量が20%を切ると性能が落ちる。ここをなんとかしようというのはないので、ディスクを追加すべし。
    • 残り0%になると変な動作をする.. ファイルが消せなくなったり...
  • zfs set atime=off: onだとデータ書き込まなくても読んだだけでスナップショットの容量が増えてしまうし、性能がガンガン落ちる。
    • atimeが重要なアプリケーションもあるがzfsでは切った方がよさげ。
  • zfs set compression=: データが主に圧縮される。デキストファイルでは効果があるがCPUをかなり喰うので要調整。圧縮する必要があるかも要検討。lzjbよりも圧縮率がよいlz4というのも検討されている。
  • dedup(デダップ): ぜったいに使うな。メモリをくいまくる(対策なし)。一度onにするとoffにできない(データを書き直さないと元にもどらない)。使えてる人はだれもいない... 小さな規模なら動くけど、小さかったら意味ないし、圧縮の方がよっぽど小さくなる。
    • メモリを喰うのは、おなじ内容のデータがどこにあるのか探すの時間がかかるのと、キャッシュを広くしなければいけないのが問題。メモリがたっぷりあれば別かもしれないが。トラブルがおこったときにも調査がたいへんになる。
  • 小さいファイルのreadが多いワークロード(webサーバ): メタデータのキャッシュが効きているか? vfs.zfs.arc_meta_limitを大きくする。mmap/sendfileをつかうとzfsとbuffer cacheとで二重にキャッシュしてしまうので、アプリをmmap/sendfileを使わない設定にするのがよい。
  • データベースなど固定レコード長もの: recordsize=を合わせておかないと128kBで書き込みされて無駄がでてベンチマーク結果がとんでもないことに。
  • ファイルサーバ: スナップショットの数を減らすことで参照数管理のコストが減ってよい。
  • L2ARCキャッシュでZFSのランダム読み込みを減らす。
  • ZIL: 特に設定しないと各ディスクから少量ずつログ領域をもらってる。分離させて(slog)SSDに置くとよい。
  • zfetch: パラメータが複雑。2プロセスの同時readによるストライド・パターンを検出してread回数を減らす。disableできないが基本設定で問題ないはず。
  • vdev cache: 0にしとけ。シークの時間を減らす効果があるが、いまのデバイスはシーク時間が短かいので効果ない。負荷によらず0でよいが、古いディスクならチューニングする価値があるかもしれない。
  • tgx: COWをまとめてIOを減らすためのしかけ。
    • min_pending,max_pending: 忙しすぎたらwrite止め、暇そうだったら書くスレッショルド。
    • 書き込みをグルーングしてフラグメンテーションを抑えるようになっているのでtxg.timeout=1にするとフラグメントしやすくなる。
    • ベンチマークではなくて自分の負荷に対してトータルの性能がどうなっているか見ること。長いスパンで性能評価するとよい。
    • インパルス的な書き込みとかストリーム的なワークロードに対してはtimeoutを短かくする効果があることも。
  • 統計データをみるには zfs-mon, zfs-stats をつかう。
  • allbsd.orgは細かいファイルアクセスが多いのでメタデータのキャッシュヒット率を上げないといけない。DSC02590
    • L2ARCはSSD 64GBだがあまりヒット率は高くない。でかいファイルが多いためか?
    • wwwなどが入っているcvsrootはgzipの圧縮率はめいいっぱい上げて1/3に圧縮。他はあまり圧縮が効いてない。
    • arc_meta_limitを上げてメタデータをキャッシュする。
    • txg.timeoutを30秒に。
    • NFSクライアントのキャッシュも有効期限を長く。
    • チューニング結果UFSとおなじくらいの性能が出てる。
  • チューニングのまとめ: webをみて試すよりもまず統計をとる。

[2012-12-07 21:56]

「NEC Express5800サーバ FreeBSDへの取り組みについて」DSC02591

  • タワーサーバは店舗とかデジタルサイネージとかにつかわれている(郵便局とか)
  • 空調の電力を抑えるために35度→40度で動作サポート
  • 電力的には外資よりも省電力らしい
  • NECはストレージもスイッチも40度に対応してるよ。背面は50度くらいになって保守員はたいへん!なのでちょっと下げた方が..

冗長電源は分けて温度を下げるようにしてる(特許申請中)

  • IPMIは古い設計なので
  • IPMIはスタンバイ電源で動いているので、IPMIがハングすると電源をひっこぬくしかなかったが、BMCのリセットボタンを用意した!
  • raidカードの情報をよめるようにしたり。

DSC02592DSC02595DSC02596DSC02599DSC02600DSC02601DSC02602DSC02603DSC02604DSC02605DSC02606DSC02607

[2012-12-07 22:12]

[2012-12-07 22:14]

「FreeBSD勉強会」 by BSDコンサルティング(株) 後藤大地DSC02611

  • 講師はつらすぎてやってられないので、
  • 参加費の八掛けを講師の方にお渡ししている。
  • つまり、佐藤先生の睡眠時間を金で買っているということ!
  • InfiniBandのドライバをゴニョゴニョしている。
  • 7系をつかっている客も多いが、サポートしきれないので止めてほしい。9系への移行をサポートします!

DSC02612DSC02613DSC02614BlogPaintDSC02616DSC02617DSC02618DSC02619

[2012-12-07 22:22]

佐藤先生に質問

  • Q: snapshotはunmountされない?
  • A: ZFSとのインタフェイスを決めるときにそうしただけ。気にする必要はない。
  • Q: raidzは2台以上とスライドにあったが2台で構築できる?
  • A: 3台ないと構築はできない。
  • Q: ホットスペアを指定すると、障害があったときに自動でディスクをreplaceしてくれる? (昔みたときはdevdにメッセージがとんでくるだけだったような気が)
  • A: スペアのディスクを選んできて入れ替えるコードが入ったような気がする(うるおぼえ)。

懇親会 〜23:15

DSC02631DSC02632DSC02633DSC02634DSC02635

/usr/ports/editors/emacs23: Warning: no access to tty (Bad file descriptor).

FreeBSD-10 Currentには/dev/ptmxがないので、

M-x shell とか alpaca.elが動かなくなって困っていた。

 ________________________________________________
|Warning: no access to tty (Bad file descriptor).
|Thus no job control in this shell.
|stty: stdin isn't a terminal
|stty: stdin isn't a terminal
|% ■
|----*shell* (Shell:run)-------------------------

openpt()をつかうパッチがeditors/emacs/files/patch-src_s_freebsd.hにあったのでeditores/emacs23に移植した。

なんでemacs23は放置されてるんだろう。セキュリティフィックスしか入らないのかなぁ。

/usr/ports/editors/emacs23/files/patch-src_s_freebsd.h

--- src/s/freebsd.h.orig	2012-01-12 19:27:54.000000000 +0900
+++ src/s/freebsd.h	2012-11-08 14:35:14.318909716 +0900
@@ -169,6 +169,20 @@
 
 #define POSIX_SIGNALS		1
 
+#define PTY_ITERATION	for (i = 0; i < 1; i++)
+#define PTY_NAME_SPRINTF	/* none */
+#define PTY_TTY_NAME_SPRINTF	/* none */
+#define PTY_OPEN						\
+  do								\
+    {								\
+      int slave;						\
+      if (openpty (&fd, &slave, pty_name, NULL, NULL) == -1)	\
+	fd = -1;						\
+      else							\
+	emacs_close (slave);					\
+    }								\
+  while (0)
+
 /* The `combreloc' setting became the default, and it seems to be
    incompatible with unexec.  Symptom is an immediate SEGV in
    XtInitializeWidget when starting Emacs under X11.  */

いってきた: 第12回FreeBSD勉強会 PC以外で動くFreeBSD

PC以外で動くFreeBSD / 佐藤広生 DSC00916

  • コアチームはお金・政治を担当する。コード書きは専門家にまかせる。
  • AsiaBSDCon 3月14〜17日。東京理科大(JR飯田橋)。英語。日本語でも何かやるべきという声もある。 http://www.asiabsdcon.org
  • i386のサポートは切ってしまった。i486以降。pc98(まだ動く),ia64(itanium),sparc64(ultraSPARC以降),powerpc(32bit無印,MacG4,G5,まだツリーにはいっていない.powerPCでしか動かないもの),powerpc64,arm,mips(juniperのコードがちょろちょろでてきてる.動くものをみることはほとんどない).
  • EPSON NP11 (Intel ATOM) ふつうのPCアキテクチャのちっちゃいパソコン.
  • OpenBlockS A6 (ARM9E) Intel,PowerPCをつかっていた
  • DreamPlug (ARM9E) marvellのチップをつかっていてopenblocksとおなじ
  • TL-WR1043ND (MIPS32) 無線LANルータにむりやりつっこんだ。
  • BSD系の源流は4.3BSDでDEC VAX全盛期(?) 1977年
  • VAX以外で動くようになったのは4.4BSDから。
  • FreeSBDはi386 PCでちゃんと動くように、NetBSDはなんでも動くように、というメンタリティーからスタートした。今はちがう。
  • FreeBSDは長いあいだi386でしか動かなかった。
  • 7.xからいろいろツリーがはいってきた。alphaは消された。
  • 組み込みに対応していかないとヤバイぞ、と。
  • マルチコア(32 coreとか)に対応してほしいとの要望がネットワークアプライアンスをつくってるところから。
  • ARMよりMIPSの方がマルチコアのチップがある。
  • FreeBSD/xxxと表記する。
  • 段階: Tier-1(リリースをちゃんとつくる、パッケージも、セキュリティ勧告もする)、 Tier-2(デベロッパがやる気があるときだけリリースされるが、ちゃんとビルドできるようにはなっている)。
  • Tier-1は歴史的にi386,amd64のみ。SPARCはずっとリリースしているけどTier-2。
  • i386,amd64,pc98,ia64,sparc64はちゃんとつかえる。
  • powerpc,powerpc64はパッケージがビルドできなかったりする。
  • arm,mipsはリリースがないので自分でつくらないとだめ。
  • i386,amd64ならIntelやSupermicroなど協力関係にあるベンダのがトラブルすくなし。Dell,HPは動くかどうか気にしてくれてない。
  • pc98のマルチコアマシン(存在するが)は全然入手できないのでたぶん動かない。
  • 机に乗っているのはUltraSPARC2のもの。野心的なメーカーがつくって消えていった。
  • SPARCのはOpenFirmware(IEEE1275)が動いていてUFSのパーティションをそのまま読めるのでローダ。ディスクラベルはVTOC8くらいしか。2TB越えのはたぶんダメ?
  • SPARCマシン24時間コンパイルぶっ通しで動かしているが安定している。
  • itanium:あまりでまわらない。すべてのCPUでチェックしているわけではない。(Marced,Madison,Deerfieldあたり)
    • HP rx2600,zx6000 (PCアキテクチャにIA64をつっこんでるような感じ)
    • SGI Altix 350 一部だけFreeBSDにできるらしい。NUMAになっている。undocumentedなのでサポートしてない。入手はしやすい。
    • EFI shell(OpenFirmwareとコンセプトは同じ)からFATパーティション上のローダを実行。UFSサポートはオプション、FATは必須になっている。PXE(ピクシー)もつかえる。
    • チップセットがぜんぜんちがうので、コードを書かないとDMA周りが動かないが、安定している。
  • powerpc,powerpc64
    • リリースCDをMac G4/G5につっこめば動く。
    • 組み込み向けのは外に出せないコードがあるのでソースツリーにははいっていない。ボードの値段が高いので敷居高い。
    • パッケージで動かないものがある。FreeBSDの責任じゃないけど。
    • OpenFirmwareからAPM(Apple Partition Map)のローダーを読む。MacのOpenFirmwareはかなりてきとう。コマンドをたたくと止まってしまったり... ちょっと操作手順を変えるとおかしくなる。リモートで管理するとかなりストレスがたまる... OSがあがってしまえば関係ないが...
    • SPARC64にくらべると安定度は低い。リブートしてしまったり。
    • Appleはサーバから撤退してしまったとか、ノウハウはたまってない。
    • Firmwareがシリアルにでてこないのでリモートからの管理は大変。
    • デバイスのサポートは全部はいっている。
    • おとしあなたくさん。
  • arm,mips
    • いばらの道
    • 構成を自動検出する仕掛けがない。→ リリースがつくれない → すべての機器用のカーネルをつくって配布?
    • ARMファミリ
      • ARM + 数字 + 機能 (ARM9TDMI,ARM9E,Coretex-A8)
    • ARMアーキテクチャ.
      • ARMv4T,ARMv5TEJ,ARMv6..
    • 規格をコンソーシアムできめてる; ARM9(ファミリ) + ARMv5TEH(アーキテクチャ) = ARM926EJ-S リファレンス実装
    • Marvell 88F6281 = ARM9 + ARMv5TE
    • ARM9 (ARMv5TE):Marvell SoC: Orion,Kirkwood が比較的数が出てて入手しやすい。ちょっと古い2007,2008年ごろ。
    • ARM11(ARMv6): Raspberry Pi 最近のだと。(ARMv6以降のはFreeBSDが動くかどうかあやしいがARM11はやっと動くようになった)
    • Cortex-A9はやっとカーネルのメッセージがでたところくらい。まだ動かない。
  • mips
    • いばらの道
    • アーキテクチャ: MIPS32(24K,1004K..),MIPS64(5K,20K.,,,) (昔はMIPS I,II,III,...とやってたが)
    • NetLogic XLR/XLS: コア32とかのMP。チップがでてこない。
    • OpenWRTプロジェクト: linuxをBSDにおきかえようぜってことで情報が豊富なので参考になる。
    • Atheros AR71xx, Ubiquiti Router Station Pro(1万円くらい,miniPIC *2) FreeBSDがちゃんと動く。
  • 組み込み機器
    • キーボード・スクリーンといった入出力デバイスがないので、そうやって操作するんだ?とか。
    • 記憶デバイスがないのでどうやってつっこむのか?とか。
    • PC以外のデバイスにはプログラムを入れるところがそもそもない。(iPhoneならjailbreakとかして)
    • PCはBIOS,EFIだが、PC以外ではOpenFirmware,U-Boot,Redoot.
    • IPL(initial program loader)はデバッグがたいへん。ここのバグがあるとたいへん。みんな自分がつくるのはイヤ。
    • U-Bootはコードがぜんぶ出ているので、各社改造がしやすい。U-Bootに慣れていれば、けっこうなんとかなる。
    • 汎用のIPLをつかってないデバイスはかなり難易度が高い。
  • まず知らないといけないこと: IPLの種類、入出力デバイス、OSの保存場所
    • FreeBSDが対応してれば試すことはできる。
    • 基本はリバースエンジニアリングする。開発ボードならわかるけど。linuxを参照したり、えらい人にきいたり。
  • buildworldの初期の段階でコンパイラが作られる。
  • OpenBlockS A6 (ARM)
    • U-Boot
    • 0x900000にカーネルをロードすると動く。ELFではなくて生バイナリで。U-Bootが認識するフォーマットにするのが礼儀正しいが、まだコードがない。
    • クロスコンパイル
      • make TARGET_ARCH=arm TARGET=arm make -j4 buildworld
      • make TARGET_ARCH=arm TARGET=arm make -j4 buildkernel KERNCONF=OPENBLOCKS_A6
      • OBJDIRは/usr/obj/arm.arm/usr/src...になる
      • PCにinstallしちゃだめ
      • 複数archでビルドするとぶつかっちゃう。どうするかはこれから...
      • make TARGET_ARCH=arm TARGET=arm make -j4 installworld distriution DESTDIR=/armroot
      • cp OPENBLOCKS_A5/kernel.bin /armroot #ナマバイナリをコピーする
    • パーティションは前半U-Boot用にFAT,後ろをUFSにする。
    • いきなりカーネルをよみこんでいるのでモジュールはstaticにくっつけておく必要がある。
  • DreamPlug A6
    • OpenBlockSとほとんど同じ。クロックはOpenBlockS(600MHz)の2倍の1.2GHzだかかなり熱くなる。
    • SDカードからブートするので簡単。シリアルは変換アダプタが必要。
    • Hit any key が3秒でるのですばやくキーで止める。
    • SDはUSBの下にぶらさがっているのでmass storageとしてみえる。
    • bluetoothとwlanはドライバがない。linuxのドライバはあるが動作があやしい。
  • TP-LInk TL-WR1043ND (MIPS)
    • 海外ではポピュラーだが、日本では認可されてないので使うと電波法的にアウト.. (この会は犯罪を助長する会ではないので、ゼッタイニツカワナイデクダサイ)
    • 中身はLAN *4, WAN *1.
    • シリアルコンソールはないが、基盤上では端子があるので、むりやり外にひっぱってつなぐ。3.3V。
    • U-Bootは "tlp" って打てば止まる!
    • イメージをつくるのはかなりたいへん。
    • 記憶装置がないのでフラッシュメモリにおさまるようにしないといけない。マニュアルなどは削る。viやtopは入ってない。tftpでネットワーク越しに転送する。
    • tftpでRAMに読み込んでから cp.b でフラッシュに書き込む。けっこう時間がかかる。
    • 802.11nのAPとして動作するのは、このチップくらい。
  • まとめ
    • NetBSDなどとくらべるとクロスコンパイルがいけてない。これから拡充予定。
    • 起動がむつかしいが動いてしまえばPCと大差なし。
  • おしらせ
    • フォローアップMLを今朝つくった: http://lists.allbsd.org にアクセスして freebsd-ja に入会申請。

[2012-11-02 20:57]

  • Q: gccからllvmになる?
  • A: 組み込みに関してはgccのままでいく。arm,mipsのサポートがllvmがよわい。binutilsに入ったGPLv3あたらしいarchのコードをどうするか。FreeBSD独自のパッチを入れていく方向でしばらく作業。llvmの品質がつかえるようになったところで切り替えることになるはず。ここ2〜3年は変化ないはず。11/5に切り替える予定。portsはがんばって変える。
  • Q: SPARCとかのマシンは動かしている?
  • A: ずっとbuildをつづけている。パッケージをつくったり。拾ったりヤフオクで戦ったりして入手している。プロジェクトのマシンはデータセンターに入れないといけないが、15〜20Aも喰うのできらわれている。あまってるワークステーションがあったらゆずってほしい。

[2012-11-02 21:03]

...プロジェクタ再起動...

DSC00955

[2012-11-02 21:07]

FreeBSD勉強会 / 後藤大地DSC00957

  • http://atnd.org/events/33453: ZFS活用とチューニング
  • FreeBSD勉強会を相談できる場所にしたい。アンケートに質問を書く。
  • http://www.bsdconsulting.co.jp/ バックエンドはユニゲージ開発手法で。USPの100%子会社なので。
  • @BSDc_tweet
  • BSDcのFreeBSDセミナーは初心者をひきつけたいが、来た人はFreeBSDバリバリだったorz
  • FreeBSD勉強会は、より深く技術を学びたい人向け。
  • おれたち少数派! 協力せざるをえない!
  • http://wiki.freebsd.org/201211VendorSummit
  • FreeBSD Expert Digital Edition 2: 1月出版予定
    • ビッグデータネタ: クラスタを3回もつくりなおした

DSC00958

[2012-11-02 21:17]

デモ〜懇親会

  • UST中継はやってくれる人がいればやってもいい (後藤)

DSC00961DSC00963

[2012-11-02 22:57]

DSC00969

[2012-11-03 00:14]

会社到着。まっくら。めずらしい。

マルエツでカップ麺と温野菜サラダを買って夕食に。

DSC00977DSC00978

いってきた: 第11回 FreeBSD勉強会 FreeBSDハイパーバイザ「BHyVe」の仕組み・使い方紹介

[2012-09-28 18:11]

→橋本→笹塚→市ヶ谷→麹町 で予定どおりに会場着。

人のあつまりが悪いらしく5分遅れで開始。

DSC09047DSC09048DSC09029

[2012-09-28 18:35] DSC09032

概論

  • 完全仮想化: 既存OSを改造してない。VirtualBoxとか ⇔ 準仮想化
    • x86はトラップされない命令がある → 回避方法:
      • バイナリトランスレーション: 実行中にエミュレーションするコードに書き換え。HWの仮想化支援があるまえはこれが主流だった。VMware.
      • IntelVT,AMD-V: Ringとは別にハイパーバイザーモードとゲストモードが追加された。
  • VirtualBox (Oracle)
    • カーネルのなかでドライバとしてハイパーバイザーがうごいている。
    • デスクトップ向け、GPLv2
    • おおくのホストOSで動くのが特徴。
  • Xen(HVM)
    • ハイパーバイザーはHWのすぐ上に載っている。
    • デバイスの初期化はdom0(管理用のOS)がやる。UIもdom0に委託。dom0はlinuxかsolarisでしか動かない。
    • GPLv2
  • 参考: Linux KVM
    • しくみとしてはVirtualBoxに似ている。ハイパーバイザーはホストOSに統合されている。
    • サーバ用途が中心.GPLv2.
  • BHyVe
    • LinuxKVMのFreeBSD版. カーネルに統合されていてふつうのプロセスとして管理される。
    • たぶんサーバ用。Windowsが動かない。
  • 準仮想化 Xen(PVM)
    • ゲストOSを改造するのでWindowsは動かない。
    • 準仮想化の方がバイナリトランスレーションより性能が出た。
  • 準仮想化デバイス
    • 完全仮想化でデバイスをエミュレーションするのはパフォーマンス的に最適ではない。モード切り替えの回数が無駄に多い。
    • ゲスト-ハイパーバイザー間のデータやりとりに最適化されたデバイス。virtioとかはNIC,HDD,consoleをエミュレーション。BHyVeでも使える。
  • コンテナ型仮想化: jail(+VIMAGE)
    • パーティショニングとも。
    • 複数のOSを動かすのではなく、擬似的にOSの環境をつくってリソース管理を別々にやる。
    • 原理的には性能が出やすい。
    • 欠点: OSがパニックするとまきこまれるとか、複数バージョンを同時に使えないとか、

BHyVe詳細 DSC09035

  • KVM似。FreeBSD10へのマージをめざしている。まだカレントにも統合されてない。NetAppの2人くらいがほそぼそと開発している模様。
  • やっと動くようになったところ。Intel VT-x + EPT対応ので動く。
    • FreeBSDのdmesgをみてもEPTに対応してるかはわからない... arch.intel.comでみるとわかる。
  • FreeBSD8版でcontributeされた。いがいとポータブル。
  • まだゲストはFreeBSDしか動かなくて、しかも要改造...
  • NetApp的にはほかのOSが動いているらしいが、外には出してないみたい...
  • amd64でしか動かない。ゲストもホストも。
  • デバイスはまだ最低限のものしかない。準仮想化のdisk,nic,console(テキストのみ、やっつけ仕事のやつ)。それとなぜかPCIパススルーも。

BHyVe実演

  • http://youtu.be/CXoD5NQEKrM
  • VMwareの中で
  • BIOSがないのでホストOS上でローダを実行してカーネルイメージをロードする。レジスタも設定する。(この時点ではまだ実行されてない)。
  • デバイスがほとんどないすかすかなdmesg。(NetAppという文字も...)
  • VMごとにデバイス(/dev/vmm/$VMNAME)ができる。
  • ローダーのコードはもともとのコードをパチってきている。
  • メモリ仮想化
    • 指定した分をどかんと割り付ける。
    • ページ共有(dedup?)はない。
    • ちいさいVMをつくったりけしたりするとフラグメントするかも?
  • PCIパススルー
    • ビデオデバイスはできない。BIOSとか古い仕組とからんでるので難しい。
    • IOAPICエミュレーションはないのでレガシー割り込みは非サポート、MSI割り込みだけ。(MSI-Xは非サポート)。
    • ホストにゲストに割り込みをおくり込むためにstubドライバが必要。
  • make buildworldの結果はちょと遅くなるだけ。
  • ゲストカーネルの変更点:
    • カスタムコンソール、デバッグサポート → シリアルかVGAのサポートが望まれる
    • local APICはMSR経由でアクセス (メモリマップドIO非サポート) → local APIC MMIOサポートが望まれる (いまやってるかできたところぐらい)
    • 2個目以降のCPUはBIOSがないので、初期化コードがクイックハックでつっこまれている → 要BIOSサポート
  • あるといいな
    • libvirt対応: 仮想マシンの設定がGUIでできるようになるとか。 (実はゲストをシャットダウンする方法もない..)
    • ローダー(*BSDとかLinuxとかの)。

[2012-09-28 20:04]

QA:DSC09038

  • Q: FreeBSD10にコミットされる予定だがどのくらいのレベルになるのか?
  • A: わからないが、ゲストに手を入れなくてもFreeBSDが動く程度になるのではないか。
    • baseにぜんぶ入れようとしているので。linuxのローダーを入れることになるとGPL汚染のおそれが。ローダーだけはportsにする?
  • Q: ゲストOSを多重起動するときどうする? 制限はあるか?
  • A: ディスクイメージも分ければできる。制限は特にない。
  • Q: KVMだとホストのユーザ空間で走るプロセスがあるが?
  • A: BHyVeでもある。/usr/sbin/bhyve。ioctl(/dev/vmm/〜, VM_RUN)で vmm.ko で処理できないものをやる。
    • QEMUはつかっていない。BIOSもらくなんだがGPL汚染とか、コードをいじっていると不幸になるとか...

[2012-09-28 20:12]

[2012-09-28 20:13] DSC09040

FreeBSDとCloudCore VPS / KDDI 小原さん

  • 第9回にも参加したひと挙手 → 1/3くらいか?

[2012-09-28 20:17]

FreeBSD勉強会 / ONGS 佐々木さん DSC09041

  • 後藤さんが体調不調のため代理
  • 12回は佐藤先生の組み込みの話 ATNDもすでにある
  • 組み込み屋がいることは把握済!
  • 開発がいそがしくて、FreeBSD daily topicsの更新が遅れぎみ...

[2012-09-28 20:23]

BSDコンサルティング 佐藤さん

[2012-09-28 20:31]

懇親会

  • 自己紹介タイムあり

DSC09043DSC09046

[2012-09-28 22:20]

DSC09049DSC09050

いってきた: 第10回 FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS 基礎 後編

DSC08001DSC08002DSC08005

トラブル

プロジェクターにスライドがでてこない。プロジェクターをリブートしたらうつった。

DSC08006DSC08008DSC08009DSC08010

[2012-08-24 18:47]DSC08013

  • ここ1年半くらのトラブルを経験したマシンがある。
  • 半導体のことを大学で教えている。たいていツールはUNIXでしか動かない。半導体の先生は情報工学を学んでないのでボタンが3つ以上あるとつかえない。学生は自分でUNIXを学ばなければならない。
  • UNIXの伝統:デバイスは特殊ファイルとして見える。
  • GEOMで使いやすくした。

性能

  • 記憶装置の性能: かかる時間=データ待ち時間+データ転送時間
  • USB3対応メモリ8GB(700円くらい)。60MB/sでつかえると書いてある。
  • まずカーネルの性能を知っておかないといけない: dd if=/dev/zero of=/dev/null s=1024x1024 bs=80
  • 1024x1024と書くのがPOSIX的に正しい(ポータビリティが高い)
  • dd if=/dev/da2 of=/dev/da3 bs=1024x1024 count=80 → 8MB/s
  • dd if=/dev/da2 of=/dev/null .. 読むだけなら速いはず → 23.5MB/s
  • dd if=/dev/zero of=/dev/da3 .. → 12.4MB/s ?? 8MB/sじゃない!!
  • read:23.5MB/s + write:12.4MB/s = rw 8MB/s
  • デバイスの待ち時間ができるので遅くなる。
  • ddを2つ3つと並列で動かすと待ち時間が減るので速くなる。
  • データ転送速度とIOPS(処理遅延)に分けて評価すべし。
  • iostat: OSによって微妙にフォーマットが違う。
    • iostat -x da2 -w 1
    • svc_t: サービス待ち時間 (転送サイズが同じならほとんど変わらない:一定)
    • カーネルソースコードが読めないときには統計情報から転送サイズを読み取るしかない。
  • 測定データとIOPSと想定したアクセスパターンをつきあわせてみる。
  • 家庭用一般向けの消費電力の少ないHDDは回転数は落して転送サイズは大きくして転送速度を稼いでいる。
  • アクセス時間 = 固定時間 + データ量依存時間: アプリケーションが最大負荷のときにiostatで統計をとる。
  • IOPS=1000なら1万i-nodeをアクセスするのに10秒かかる。(ls -lとかで差がでる)
    • 1メール1ファイルのようなメールシステムとか。
  • キャッシュが効きやすいようなファイルレイアウトにするとか。
  • UFS_DIRHASH: vfs.ufs.dirhash_maxmemを大きくするとi-nodeキャッシュが改善する。
  • BSD系OSは64KiBが基本転送サイズ。これを大きくしてもそれほど性能がかわらないことが経験的に知られている。
  • dd bs=で1MiBで指定してもカーネルが64KiBに分割してしまう。
  • iostat の %b は利用率。100%になってないと限界までつかってない。
  • GEOM用のstatもある。ミラーしたときの末端のデバイスの性能だけではなくGEOMの性能も知りたい。

gmirrorの設定

  • システムディスクのハンドブックの記述はまちがっている。
  • まず1台(ada1)だけのミラーをつくってada0の内容をコピーする。そのあとリブートしてada0をミラーに組み入れる。これが一番安全。ダウンタイムが短かい。シングルユーザに落ちなくてもリモートからできる(ただし失敗したらアウトだが)。
  • パーティションの末尾に512Bのgmirrorの情報を書くが、空きがないとこまる。ディスクを使い切ることはめったにないが。(近いうちにちゃんとハンドブックに書くよ)
  • ハードディスクをホットスワップできるかはハードウェアの仕様できまる。
  • BIOSはミラーされてるかどうか知らないので、障害時にブートデバイスを変えないといけないかも。ソフトウェアRAIDなのでOSの世界から抜けるとミラーじゃなくなってしまう。
  • ルートパーティションだけにしちゃう一派 → CDROMもUSBメモリも使えないサーバがたまにある。そうなるとディスクをひっこぬくしかなくなる。
  • / と /usr はreadonlyにして運用するというとはよくやる。書き込むのは/varのみに。そうしておくとミスオペ(rm -rf /)に耐えられる。
  • オススメ:
    • / = 3GB
    • swap = メインメモリ以上
    • /var = 30GB
    • /usr = 20GB
    • /tmp = 1GBのメモリディスク
    • 残り = サービスに必要な容量
  • クラッシュダンプはswapに書き出される。パニックしたときにファイルシステムは信用できない。

RAID0,1,3

  • アクセスパターンを再現できるツールをつかう。(最初に乱数でアクセスパターンを生成して、違う構成での性能を比較する。)
  • RAID3はRAID5とちがってパリティディスクが固定されて、ストリーミングのような連続書き込みが速くなる。
  • gmirrorにはreadのストライピングの戦略を選べる。
  • ソフトウェアRAIDは単発でつかったときに性能が上がるのか下がるのか。geomはそんなに悪くない。

HAST

  • GEOMベースでgmirrorの動きをするネットワーク越しに動作する。
  • VRRPやCARPと組み合せると片側だけでも動けるようになる。
  • /etc/hast.confに書く。両方のマシンに同じ設定ファイルを置く。
  • /dev/hast/〜にデバイスができる。
  • UCARP(ユーザランドのCARP実装)をHASTとつかうと便利。
  • 実績はある。暗号化して共有するのもgeomでできる。

ZFS

  • 従来: デバイス→ボリュームマネージャ→ファイルシステム
  • ZFS: ZPOOL→DMU→ZFS
    • たくさんのデバイスがあったときにスケーラビリティを達成する。HDDが2台3台じゃ旨みがない。
    • 堅牢性とかはおまけ。
    • クラスタファイルシステムではない。
    • 既存ファイルシステムの欠点(アカデミックなこととか)はたいていつぶしてある。
  • ZPOOLでできることは既存のボリュームマネージャとできることはかわってないが組み込まれているところがちがう。
  • ZPOOLの上にデータセットをつくれる。データセットとはファイルシステムとか。
  • geomがzpoolにおきかわったと見ればよい。
  • dnode: inodeみたいなもの。ZFSのデータセットを構成する。UFSとはちがって固定的な場所はない。
  • DMU: data management unit. dnodeを操作するカーネル部分。
  • VDEVラベル: L0,L1,L2,L3: スーパーブロック相当。1こ128KiB。前後512KiBをつぶせば認識されなくなる。
  • ラベル=ブートラベル、ZAPオブジェクト、UB0..127。
  • MOS(Meta Object Set): dnodeの配列がふくまれている。
  • リンクをつくるときはかならずコピーがつくられる→堅牢性のキャッチコピーはここから
  • tank : マトリクスから。
  • ファイルシステムもdnodeで管理してファイルとディレクトリもdnodeで管理するという二段になった点だけが違う。
  • コピー3とリンクの途中にログを入れるところが違うくらい。
  • CoW: 書き換えないでコピーする。でも欠点にもなる。
  • ZFSはUFS以上にリンクをたくさん辿るのでdnodeアクセス性能に敏感になる。複数のディスクに分散することで回避することになっている。
  • CoWだと書き込みも読み込みを伴うので書き込みつづけるということができない。
  • 1つのファイルをランダムライトするようなアプリは遅くなる。原理的に回避不可能。書く前に読むアクセスパターンだらけなので性能が100%出ない。トランザクショングループにまとめて書く回数を減らすようにしているが、メモリ上にたくさん覚えておく必要がある。
  • tips
    • amd64: メモリが使えないことのほかに、i386はアクセス効率(MMU)が悪い。
    • vfs.zfs.vdev.cache.size=0: ほとんど効かないのでメモリのムダ。将来的にこの項目はなくなる予定。
    • vfs.zfs.vdev.cache.bshiftは小さいIOをまとめる設定 (default 64Kib(16))。アクセスパターンによって変えるとよい。
    • vfs.zfs.arc_meta_limitを設定してdnodeキャッシュを稼ぐ。 データ量/(8KiB*128B)。 ざっくり1TB=16GBくらい。
      • データアクセスが中心なのかfindするようなメタデータ中心なのかでちがってる。読む方はキャッシュを積めが改善する。

ZFS構築事例

DSC08014DSC08015DSC08016DSC08017DSC08018DSC08019DSC08020DSC08021DSC08022DSC08023DSC08024DSC08025DSC08026DSC08027DSC08028DSC08029DSC08030DSC08031DSC08032DSC08033DSC08034DSC08035

  • allbsd.orgを生贄に。
  • IOPSをみる。
  • writeは5秒に1回になるように設定している。デフォルトは10〜15sだが性能が落ちるので短かくした。アプリによるので測ってみるしかない。IOPSに余裕があれば細かく書くようにすればよい。
  • 120Mbps:内部向けファイルサーバとして
  • 20Mbps:外向のサービス
  • パーソナルで使うくらいならチューニングしなくてもつかえる。
  • FreeBSD9以降は大きなトラブルはないとおもってよい。
  • たくさんのディスクを載せてなければ性能がおちる。

[2012-08-24 21:13]

QA

  • Q: GPTでパーティションをきった理由は
  • A: ブートできるように。p1だけをつかう。gmirrorをつかうときにサイズをあわせるためにそうしてただけ。
  • Q: SSDがつかわれるようになってきたが。
  • A: UFSにはハードディスク前提の最適化としてシリンダーグループがある。でもハードディスクの内部で順番に並んでるとは限らない。UFS2ではシリンダーグループはなくなった。SSD向けにファイルを消したときにTRIMが出るようになっている(UFSのみ)。ZFSもTRIM対応される予定。GEOMレベルで入るらしい。

ZFS: SUNが手を引いてOracleが2年以上ソースを出さなくなった。illumosに開発者が移動している。商用のデバイスをそのコードをつかって商売していて、FreeBSDに入ってきている。FreeBSDのコミュニティーに技術がたまってきているので突然消えたりしないので安心して。

[2012-08-24 21:24]

DSC08036

懇親会。ワイン白+赤+日本酒+つまみ。

DSC08037

[2012-08-25 11:00]

Q: scrubするとパフォーマンスが落ちるんですが。

A: scrubする必要はない。periodicに入ってしまったが必要ない。

いってきた: 第9回FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS

DSC06029DSC06031DSC06032DSC06001DSC06004DSC06009DSC06017

第9回FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS / 佐藤広生

DSC06002DSC06003

DSC06019

GEOM

  • 一次元の配列のように見える。
  • GEOMを回避してストレージにアクセスできない。どうやっても通る。
  • /dev/ada0とか1バイト単位でアクセスできるようになっている。FreeBSDではcdev,bdevの区別をすてた。ブロックデバイスはない。
  • デバイスノード → コンシューマ → プロバイダ → ディスクノード
  • プロバイダとコンシューマはペアになる。
  • ストレージデバイスがつながれたらGEOMの構造が自動でつくられる。伝統的なUNIXと同じように見えるようになっている。
  • BSDラベルのなかにBSDラベルをきっても対応できるらしい。
  • sysctl kern.geom.confdot でgraphviz形式でダンプできる。
  • mirror classは勝手には作られないが、デバイスの最後のブロックにgmirror(8)で書き込むとカーネルがちら見して、設定を読んでミラークラスをつくってくれる。→ tasting と呼ばれている。
  • mirror/mymirrorという名前でもいいけど、UNIX likeなgm0とかにおちついた。
  • ミラーのprimaryの指定は後から変更できるが、基本はlabelの先頭のやつ。
  • ストレージを切り離すにはgmirror forgetという分かりにくい。
  • gmirrorはGENERICに入ってないのでgmirror loadしないといけない。loader.confに入れてブート時に読み込まれるようにしておくこと。
  • 基本的に専用コマンドでGEOMメタデータを書き込む。
  • ZFSを実現するためにGEOMをくみあわせてつかっている(が表にはみえてこない)。

ファイルシステム

  • マウントポイントはディレクトリ基本だが、一部のOSではNFSなどファイル単位でマウントできるものもある。
  • mdconfig -a -t swap -u 0 -s 10m でメモリデバイスをつくる。本当にシステムのメモリが枯渇すると落ちるので注意。
  • UFSはinode領域はディスクの真中あたりに置いてあって先頭に置くよりも平均的にはアクセスが速くなる。
  • inode=2がルートディレクトリ。
  • カーネルをアップデートしても落ちるケースはスーパーブロックやinodeが壊れているかもしれない。
  • ファイルシステムが壊れてたらmountするとパニックしちゃうのでfsckが終わるまでmountできないようになっている。
  • fsckは未使用ブロックの解放をおこなうがメモリがたくさん要る。ディスク1GBに対して0.5MBのメモリが必要。
  • fsckはswaponの前なので注意。
  • inodeを非同期で書き込むと速くなるが信頼性が落ちる。FreeBSDは遅いといわれると悲しい→softupdatesが開発された。
  • softupdatesは削除は参照されないようにしてからブロックを消す。追加はブロックをつくってから参照をいれる。
  • softupdatesを有効にしてても未使用ブロック管理の回収でfsckが必要になる。fsckの時間は短かくならないが損傷の可能性は低くなる。
  • ジャーナリングでメタデータ操作の手順を記録する→復旧時にリプレイすればok。リプレイは何度やっても同じ結果になる。fsckの時間はほぼなくなったが、電源断で戻る幅がおおきくなった。やってないことになる量が増えたということ。10分とか15分とかのオーダで戻る。
  • 現状ジャーナリングを有効にるとdump -Lがつかえなくなる。改修中。
  • Q バグは9.1で直る? A: リリース前にレポートしてほしい、リリース直後は疲弊していてメールをよみとばしてしまう傾向が..
  • Q dragonflyのhammerは移植されるか? A: hammer FSはVFSの改造が入っているのでもってくるのはむつかしい。fuseの形で動かせるが、FreeBSDにもってきてても性能が出ない。技術的に難しい。hammer2でOSもかきかわってきているので。

[2012-07-20 20:37]

FreeBSDとCloudCore VPSと私 / 小原聖健

  • 自宅に置く電気代よりも安いよ。
  • たくさん購入すると安くなるよ。
  • そのうち新しいメニューが出るよ。

[2012-07-20 20:42]

FreeBSD勉強会 / 後藤大地

  • portsはバージョン管理されていないのでどんどん新しくなってしまう、古いバージョンにセキュリティパッチだけあてるサービス。
  • RedHatのような動作検証サポート。検証結果だけでなくてプログラム自体を提供するとか。

懇親会

~22:50

日本酒がいっぱいならんでました。

DSC06034

DSC06038DSC06046

次回以降

ZFS L2ARCをとりはずした

L2ARCとして使っていたSSDを取り外した。

取り外す前にsmartの値をみてみたら、書き込み量が読み込みより数倍多いことがわかる。

L2ARCの挙動としてはオンメモリのARCから押し出されたものをどんどん書き込むので、まさにそのとおりになっている。

L2ARCの書き込み単位は大きく読み出し単位は小さいというのもみえてくる。この特性はNAND Flashの性質にぴったり。

ID# ATTRIBUTE_NAME            RAW_VALUE
  1 Raw_Read_Error_Rate       6
  9 Power_On_Hours            7520
 12 Power_Cycle_Count         52
184 Initial_Bad_Block_Count   123
195 Program_Failure_Blk_Ct    0
196 Erase_Failure_Blk_Ct      0
197 Read_Failure_Blk_Ct       0
198 Read_Sectors_Tot_Ct       3839845191
199 Write_Sectors_Tot_Ct      11750223536
200 Read_Commands_Tot_Ct      148228624
201 Write_Commands_Tot_Ct     41284400
202 Error_Bits_Flash_Tot_Ct   3642321
203 Corr_Read_Errors_Tot_Ct   3504621
204 Bad_Block_Full_Flag       0
205 Max_PE_Count_Spec         10000
206 Min_Erase_Count           824
207 Max_Erase_Count           1803
208 Average_Erase_Count       979
209 Remaining_Lifetime_Perc   91
211 SATA_Error_Ct_CRC         0
212 SATA_Error_Ct_Handshake   0
213 Indilinx_Internal         0

Write_Sectors_Tot_Ct/Read_Sectors_Tot_Ct = 3.06
Write_Commands_Tot_Ct/Read_Commands_Tot_Ct = 0.278
Write_Sectors_Tot_Ct/Write_Commands_Tot_Ct = 284   (142KiB/access)
Read_Sectors_Tot_Ct/Read_Commands_Tot_Ct = 25.9048 (13KiB/access)

手順:

  1. zpool remove tank dev 論理的に取り外し
  2. 電源offしてケーブルの取り外し
  3. ブート

arc_summaryの結果をみてると、L2ARCがなくなるとそのぶんをオンメモリのARCが肥大するようで1〜2GBくらいサイズが大きい。

koie

いってきた: 第8回 FreeBSD勉強会

五反田駅であわてて入場しようとしたら、むこうから来た出場する人と改札ですれ違い。ゲートは閉らなかったけど、ちゃんと入場できたか心配しながら有楽町で出ようとすると「窓口へ」と表示が。残念ながら入場記録がないようだ。

K3410182

麹町駅の3番出口からでてすぐ。となりのビルにmozilla japanの文字が。

DSC04280DSC04281DSC04279

受付でアカウントが見つけられずちょっと手間取ってしまった。

Jail機構と資源制御 / 佐藤広生

(資源制御の話)

  • RACCT/RCTLが新しく導入されたやつ。
  • UNIXでファイルじゃないもの: CPU時間、メモリ、IPCなど。ほんとうは全部ファイルにするつもりだった。
  • 一台の物理マシンを共有できるようにするのがUNIX: ユーザ/グループが管理単位。
  • ユーザ単位で分けられている資源: ユーザランドプロセス空間と使用中のハードウェア(/dev/*)。
  • 限界が許すかぎり早い者勝ち。ただしムダが少なくなるようにがんばる。
  • 「資源使用量を細かく管理しよう」という考えはとぼしい。人間が細かく指定するとムダがでる→ハードウェアのキャパを大きくすればいいよね!
  • Subject--(Action)-->Object
  • ルール:{S,A,O}=許可or拒否 という形で記述する。カーネルががんばって監視する。
  • アクセス制御リストはファイルの許可属性に書いてあるが、ファイル以外はrootかどうかで判断。
  • もっと強力な権限制御はMACをつかう。
  • Disc Quotas (Diskではない!)
    • S=プロセスのUID
    • O=ファイルシステム上の使用量(ブロック・ファイル)
    • A=ファイルへの書き込みアクセス
    • ACL=quotaファイル
    • 資源監視=カーネルがファイルシステムアクセスを監視
    • 4.2BSDで追加。
    • デフォルトは無効。
    • リブートすると使用量を調べなおしという無駄。
  • setrlimit
    • プロセスが使用可能な共有資源の使用制限
    • 4.2BSDで追加。
    • POSIXにも採用されたのでだいたいつかえる。
    • FreeBSDでは/etc/login.confで設定されている。(ログインクラス)
    • ログインクラスはユーザ単位にケーパビリティを定義する仕組。
    • setrlimitはプロセス単位なのでログインプロセスを設定することで子孫プロセス全部に制限がかかる。
    • 欠点: ユーザ単位でしかできない。複数のユーザ/プロセスの集合に対して最大値を決めたいとか複雑なのはできない。

(環境の分割の話)

  • 環境=ユーザプロセスの集合体
  • カーネルは要求に応じて資源を分配するだけ。
  • 分配に必要な情報はカーネルの外(ディスクとか)にあることがほとんど。
  • 複数の環境を1つにまとめてもカーネルはその機能を失わない。
  • chroot: 昔からある方法
    • unixでは資源をファイルで管理しているので見えるファイルを制限すればいいのでは!
    • この種の環境の分割=「名前空間の分離」
    • セキュリティ対策として使われることがしばしばだが、抜け道はいつくか存在する。
    • できないこと: ファイルとして管理されてないもの(プロセスとか)。別ユーザだけどuidが同じとか。ネットワークとか。
  • Jail: もっと分離したい!
    • 分離されたもの: sysctl MIB, proc list, PID空間 (pid+jailIDで管理)
    • uidは分離されていない。
    • rootはファイルシステムは特権ありだが、mountとかファイルシステムの垣根は越えられないように(基本)。
    • jail外部環境に影響をあたえるようなものは拒否。
    • jailもchrootもプロセスに効くので/etc/rc.confに書いて自動的につくる。
    • 作成や環境維持にはsysutils/ezjailが人気。
    • jail(2)とjail_attach(2)をつかう。ABI emulationは親プロセスを継承する。CentOS4もだいたいは動くよ。
    • Linux版のunameはuname -aの出力にはLinuxとFreeBSDがまざって表示される。
    • yumもほぼ動く。
  • VIMAGE (VNET)
    • さらなる拡張。ネットワークを完全独立でネットワークスタックを用意する。ループバックデバイスとか..
    • まだバグがちょっと残っているのでデフォルトではoff。
  • KVMのようなカーネルを複数立ちあげるタイプとはちがう。
  • Jail単位でつかわれている資源量はカーネルはわかってない!
  • setrlimitの欠点
    • ユーザ単位での制限がむつかしい
    • アクションを変えられない
    • 設定後に自由に変更できない。

RACCT

  • RACCT:資源使用量をカーネルが把握するためのフレームワーク
  • RCT: ACL風のルールで指定
  • デフォルトはoffだが特に理由はなくてFreeBSD9.0はゼロだし導入に慎重になっただけ。深刻な不具合報告もない。
  • 書き方: subject:subject-id:resoure:action=amount/per
    • rctl -huで現在の使用値を表示
    • subject=user,process,loginclass,jail がえらべる。
    • action=deny,log,devctl,sig*
    • amount/perはsubject単位でつかえる資源量を指定する。subjectとperは同じでなくてもよい。
    • 1g/userと指定すると1ユーザあたり1Gまで。
  • RACCTでプロセス数を制限すれば学生のフォーク爆弾に有効。
  • なぜかルールの一覧表示はできない。理由不明。技術的にはむつかしくないはず。
  • action=devctlをつかうとdevd経由でいろいろできる。
    • メモリリークするプロセス(e.g. postgresql)があった場合、スワップ使用量が閾値を越えたらdevdから再起動するなど。

QA:

  • ルールの評価順序は上から順番に。

DSC04260

5分でわかる「開発者支援精度」(とCloudCore VPS) / KDDI 斉藤

  • エンジニアがやりたいことをやってみた。
  • さくらとちょっとにてる。
  • 月額1000円で。嫁を説得できる価格。945円で。嫁に怒られないVPSが完成!
  • 申込フォームから申込で3日程度で。
  • FreeBSD9.0も簡単にインストールできるよ。

DSC04288DSC04289

DSC04262DSC04264

Reborn:FreeBSD勉強会 / 後藤

  • KDDIウェブコミュニケーションズ提供
  • 月一でサクサクいくよ。
  • 第9回は 7/20 18:30-20:30
  • 次回テーマは紙にかいて! ハッシュタグをみるのはめんどくさい。

DSC04290

DSC04267DSC04268DSC04269DSC04270DSC04271DSC04272DSC04274DSC04275DSC04276DSC04277DSC04278

そのほか

後藤さんに今回これだけ人が集まったのは何か仕掛があったのかきいてみたところ、ATNDにしたのが効いたのではないかとのこと。技評の告知ページだと1週間くらいしか出せないので人があつまりにくいとか、ユーザー登録するのが面倒だとかあるが、ATNDならtwitterかGoogleのアカウントがれば簡単に申し込める。

DSC04265

DSC-HX200VをFreeBSDにつないでみた

USBケーブルでつなぐ → 電源ボタンがオレンジになる。

ugen0.2: <vendor 0x054c> at usbus0
uhid0: <vendor 0x054c USB Charger, class 0/0, rev 2.00/1.00, addr 2> on usbus0

再生ボタンを押す → 電源ボタンがグリーンになり、「USBモード MassStorage」と表示される。

ugen0.2: <vendor 0x054c> at usbus0 (disconnected)
uhid0: at uhub0, port 5, addr 2 (disconnected)
ugen1.5: <Sony> at usbus1
umass0: <Sony DSC-HX200V, class 0/0, rev 2.00/1.00, addr 5> on usbus1
da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
da0: <Sony DSC 1.00> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 15383MB (31504384 512 byte sectors: 255H 63S/T 1961C)
da1 at umass-sim0 bus 0 scbus9 target 0 lun 1
da1: <Sony DSC 1.00> Removable Direct Access SCSI-0 device
da1: 40.000MB/s transfers
da1: 105MB (216576 512 byte sectors: 64H 32S/T 105C)
da2 at umass-sim0 bus 0 scbus9 target 0 lun 2
da2: <Sony DSC 1.00> Removable Direct Access SCSI-0 device
da2: 40.000MB/s transfers
da2: 21MB (43008 512 byte sectors: 64H 32S/T 21C)

電源ボタンを押す → 電源ボタンが消灯したあとオレンジになる。

ugen1.5: <Sony> at usbus1 (disconnected)
umass0: at uhub1, port 5, addr 5 (disconnected)
(da0:umass-sim0:0:0:0): lost device - 0 outstanding
(da0:umass-sim0:0:0:0): removing device entry
(da1:umass-sim0:0:0:1): lost device - 0 outstanding
(da1:umass-sim0:0:0:1): removing device entry
(da2:umass-sim0:0:0:2): lost device - 0 outstanding
(da2:umass-sim0:0:0:2): removing device entry
ugen0.2: <vendor 0x054c> at usbus0
uhid0: <vendor 0x054c USB Charger, class 0/0, rev 2.00/1.00, addr 2> on usbus0
記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2022-06-26
    • 今日の練習 2022-06-26
    • 今日の練習 2022-06-26
    • 鼻栓: speedo NOSECLIP SD97A07 GY グレイ
    • 鼻栓: speedo NOSECLIP SD97A07 GY グレイ
    • 鼻栓: speedo NOSECLIP SD97A07 GY グレイ
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ