オープンソースカンファレンス2008に行ってきました
やっぱり社外イベントに参加するとモチベーションあがりますね。
今日一日参加しただけでも、かなりやる気がおきました!
明日も朝から行く予定ですので、今日のカンファレンス分のメモを残しておきます。特にまとめもしてませんが・・・。
hinemos ver2.4
- アンケート結果
ノード数:50ノード以下の規模を対象としているところが多い
対象OS:36%がlinuxで20%がwindows
半年毎にリリース予定(ver2.4は3月末を予定)
- 追加機能
・サービス・ポート監視
リトライ回数も指定可能
・RHEL5版エージェント対応
・通知メールカスタマイズ機能
テンプレートを自由にカスタマイズ可能だが、定義してある変数のみしか動的な値は指定できない。
・SNMP Trapマスタ編集機能
- nagiosやhinemos以外の運用管理OSS
・OpenNMS
・Zabbix
Xenのクラスタ
P2Vもツールを組み合わせることで実現可能
- HA
・エンタープライズで使用するためにはHAの仕組みも考慮しておく必要がある
⇒dom0に障害が発生したら、domUにも影響があるため
- HeartBeat v2
・アクティブ・アクティブも可能
・これを用いればLiveMigrationにも対応しているため、障害回復後にもともと動作していた物理ノードに移行することが可能となる
・64ビット版だと片方で設定をすればもう一方のノードにも設定を反映してくれるコマンドがある
ha_propagageコマンドかな?
・見える化(GUI)にも対応
・GUIを利用するともっとわかりやすくなる
- HASI
・ストレージに仮想OSのイメージを置いておく
・試してみる場合(LiveMigration)は、Xenサーバの2台は同じCPUであることが望ましい
・SLES10のパッチを適用してからテストしないとパフォーマンスが低下したりErrorが発生する場合がある
・同時書き込みを禁止したりすることでクラスタリングで利用できるようにしたファイルシステム
・NFSのループバックマウントドライバを利用していると時々障害が発生するため、OCFSを用いた方がよい。OCFSだときちんと動作する。
Linux crash dump 読み方
・linuxが管理するデータやプログラムはすべてメモリに存在しているため、ダンプを取得する設定が必要
・フリーズ(ストール、ハングアップ、スローダウン)は解析が難しい
・kernelPanicの原因は、ハードウェア障害、kernel Bug、アプリケーションで利用しているドライバモジュールのバグ
・カーネルのオプションを追加する必要がある
crashkernel=・・・
- ツール
・LKCD
障害が発生したkernelがダンプを出力するため、確実性に問題あり
・diskdump
障害が発生したkernelがダンプを出力する点はLKCDと同じだが、ダンプを取れる確率が上がっている
・netdump
ネットワーク(ssh)経由でnetdumpサーバに出力する
・Kdump
起動時にdump専用のkernel(セカンドカーネル)を準備する
障害が発生したkernelがダンプを出力しない
ネットワーク経由での取得もOK
- oops時の動作設定
※oopsとはkernel内部で何か異常だと判断された状態
・oops派生時にpanicを発生させることも可能
- ストール検知
・利用マシーンが限られる(ゲストOSは無理)
- NMIスイッチ
・ダンプを取得できるスイッチ
・キーボードからはSysRqキー
・Alt-SysRq-s ← 'S'ync
・Alt-SysRq-d ← 'D'ump
・Alt-SysRq-b ← re'B'oot
- lcrash(dump解析ツール)
・LKCDの形式に対応
- crash(dump解析ツール)
・Kdump,diskdump,netdumpに対応
・アーキテクチャが異なると解析できないので要注意
- 以下の知識が必要
・CPU
・C言語
・GCC、プリプロセッサ、マクロ
・アセンブラ
・ニーモニック
・Kernel構造
- コツ
・crashツールを用いて該当関数を特定できたら、gdbを利用して検索するとよい
楽天株式会社におけるOSS活用の現状と今後の展開について
・オープンソース=オレゴン州
・Linuxのリーナスさん、やwikiを考案した人たちがいる
・オレゴン州立大学はOSSに力を入れており、Labもある
・産官学連携も進んでいる
・amazonと楽天の違い
・amazonは本、CD、家電など整備された世界からはじめているが、楽天は地方などを相手にしている。DBはぐちゃぐちゃだったり・・。
・お城を販売したりもしている(ネタでね)
・楽天のビジネス
・根底にあるのは楽天市場
・ECのコンテンツを充実させるためにトラベルや証券が付随する
・楽天技術研究所はデータ分析をすることで、年や商材に依存しないロングテールを目指す
・4月から台湾で楽天市場を展開
・楽天の開発の実態
・共通ライブラリの使用を強制しない
・発注はしないで内製が基本
・DBサーバはsolarisが多い
・WEBサーバなどはLinuxのDebianが多い
・社内勉強会
・OSSはあくまでオプションのひとつ
・楽天が考えているOSSと商用の違い
・サービスをタイムリーに適切に作ることが大切
・技術者のスキル、人材確保が大切
⇒慣れないものを嫌々エンジニアが使うのはNG
・パフォーマンス
・スケーラビリティとライセンス料
・保守
・商用DDMSのベンダーも買収されサポートがなくなる場合はある
・バグはどちらにでもある
・OSS毎にサポート企業と組む
・楽天市場の一部でRuby On Railsを利用している
・生産性は他言語の1.6から3倍
・Railsでもセキュアにつくることは可能
・パフォーマンスもばっちり!
・今後はエンタープライズを考えた大規模分散を考慮する必要がある
・楽天の大規模への2つの取り組み(Ruby)
・処理分散、CPU分散 ⇒ Fairy
・データ分散、メモリ分散 ⇒ ROMA
Ruby会議で報告を予定している