OSC 2009 Tokyo/Sprint 1st Day
- emobile の設定しわすれてネットつながらない・・・・
仮想化環境の設計手法〜プロのテクニック教えます〜
- 仮想化で問われるのはセンス
- プロのテクニックとは
- 知ってるか知らないか
設計のポイント
- 既存環境の移行が一番多い
- ちゃんと設計をするとコストは下がる
- 押し上げる要因は過大な見積り
- Hardwareの見積りをしっかりすれば,コストは下がる.
- コストの適正化
- 性能が足りなくなったら,スケールアウトする
- コスト削減のメリット・デメリットを「見える化」する
- システム寿命を2年増やす => 仮想化する・しないの場合での見積り
- 押し上げる要因は過大な見積り
設計フェーズ
- 論理的な機能(サーバ)を整理する
- 物理マシンじゃなくて,論理機能として抽象化して整理する
- いま2GHz/8GBだからといって,そのまま落としこまない
- 仮想化の設計をする
- まだ物理マシンは出てこない
- コンピュータリソースは無制限だと考える
- まだ物理マシンは出てこない
- 注意点
- リソースプールは最低3台で構成するのが望ましい
- どのHardwareで動くかは考えない.考えてはいけない.
- 障害発生時はリソースプール内で相互にカバーする
- なのでStand-byサーバはない
設計手順詳細
- サーバのリストアップ
- 重要度と負荷率で,ABCランクをつける
- マシングループ毎に仕分け
- マシン間の関連を書いておく
- グループ毎の要求リソースを算出
- I/O, Network が算出しづらいので,現行サーバのを調べておく
- CPU/メモリは搭載量 x 60% と考える
ハードウェアの選定
- 1台あたり16GB積むのを指標とする
- 場合によっては32GB/64GBもありうる
- 高速なI/Oが必須
- CPU使用率
- CPU使用率30%の物理マシンを仮想マシンに
- CPU60%ルールなら,VM2台 とか
- CPU使用率30%の物理マシンを仮想マシンに
ブレード or ラックマウント?
- 最低3台
- 4台以上なら,ブレード?
- 今後の増強計画を考えると,ラックマウントよりもブレードで用意しておいたほうがいい
- ブレードの弱点も克服されつつある
- HDDがなくなり,SSD/USB/Sun Bootになり,空き容量にメモリを搭載できるようになるようだ
CPUの仮想化
- 1VM CPU を 1物理 CPU に割り付ける
- VM が idle でも Host はそれがわからないので,割り当ててしまう
ネットワーク構成
- 4系統あるほうがいい
- 通常
- 管理用
- ストレージ用
- ライブマイグレーション用
- ブレードのパーツは ebay で買えば安い
- 販売代行しているらしい
ストレージの選定
- OpenSolaris で ZFS が最近のトレンドらしい
- お手軽らしい
- 仮想化はネットワーク前提で考える
- 無停止で容量追加
- Linux ならできるが,何に追加するのか(DBに追加など)を考える
- ストレージ側のスナップショット
- バックアップに有効だが,費用対効果の見極めが肝心
- レプリケーション
- DRBD
- 小さいファイルなら rsync など
Web技術の現状と将来
- SFCの人
W3Cの紹介
- Im Berners-Lee により創設(Web = hypertest + internet を考え出した人)
- W3C が Web の標準仕様を策定している
- 啓蒙活動と将来についての提案もしているようだ
- 3つのホスト組織が運営
- MIT
- ERCIM
- 慶應義塾大学
- 日本の意向の取り入れや、アジア言語の取り扱いなど
- それ以外に W3C オフィスがある
- 主にプロモーション活動
- 標準化のプロセス
- Working Draft -> Last Call -> Candidate -> Proposed -> Recommendation(勧告)
- 「多くの人がどうこう言うより、一人の天才に決めてもらおう」という思想
- Validator を提供
W3Cからのお願い
- 第2の「新しいWeb時代」が来る
W3Cでの最新の活動紹介
HTML5 について
- <canvas> のデモ
- HTML+CSS+JavaScript のみ
- 2D/3D処理が可能
- わりとスムーズに動作する
- 標準機能だけで Video の再生・コントロールなどが可能になる
- native で drag & drop に対応する
- JavaScript との連携が必要になるが,native 対応しているのはいいんじゃないかな
- <input type="date" /> がある
- 日付選択の <input />
- Shibuya.JS++
進化し続けるオープンソースアプリケーションサーバ : GlassFish
GlassFish とは
-
- アプリケーションサーバ
- JavaEE 5 完全準拠
- Web 2.0 対応
- Comet/Web サービス
- 性能が十分であるということらしい
- Comet/Web サービス
有償ユーザの付加価値
GlassFish ESB
JavaEE 6
GlassFish v3
- JRuby などのスクリプト言語のサポート
- GlassFish v3 prelude
- Ruby on Rails のネイティブサポート
- ここが気になるところ
- Ruby on Rails のネイティブサポート
- 計量・高速起動
MySQLをパワーアップ!MySQLサポートツールズを使ってみよう
MySQL を取り巻くツール
- memcached
- キャッシュを全体で共用することができる
- DRBD
- ネットワーク越しのミラーリング
- Heartbeat で Failover 構成がとれる
- MySQL Enterprise Monitor
- 問題のあるクエリの発見,そしてチューニングができる
- 「起こる前に」問題を特定できる
- Gold 以上で Query Analyzer が使える
- クエリチューニングの難しいところ
- ユーザやアプリの動作の把握が難しい
- サーバはパフォーマンスを収集するようにはできていない
- Slow Query Log ではわかりにくい
- 調査しづらい
- SHOW PROCESSLIST/EXPALIN ではどうなっているのか,どうすればいいのかがわかりにくい.
- SHOW PROFILES
- 5.1 からデフォルトで有効になっている
- クエリーの詳細な情報を表示できる
- MySQL クエリアナライザー
- MySQL Proxy 上で動作する
- パフォーマンスの劣化は 15%-20% 程度
- MySQL Workbench
- MySQL Proxy
- 更新・参照のサーバ振り分けとかできる
- 最新版は launchpad で公開中
- Connector/C++
- CMake で
- Windows とソースコードを一本化する都合で導入されたもの
- build するときの Make ファイルを,C コンパイラに応じて作成する
- configure のようなもの?
- Windows なら Visual Studio のプロジェクトファイルを作成できるそうだ
- CMake で
まとめなど
- MySQL Proxy は使いどころありそうなので,検証してみる
- 仮想化を本格的に導入してないといけないな