Open VZ
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • FYI 手元の環境で試したところ、問題は routing cache ではなく ARP broadcast への返信の遅延のようでした。
    http://d.hatena.ne.jp/kazuhooku/20091007/1254890935
    Are you sure you want to
    Your message goes here
  • tokuhiromさんの質問の「そもそも素でつかって0.06秒っておそすぎませんか?」を見て、確かに!と思ったので調べてみました。&スライドの内容を訂正させてくださいm(_ _)m

    素の状態でrt_cacheの登録による遅延は0.002~0.003秒でした。
    (一桁間違ってました。。。)

    venetを超えてのホストがrt_cacheにエントリを登録する時間が遅延の対象になっていました。
    (1ホストあたり0.03秒~0.2秒遅延するのを確認しました。)

    キャッシュされている状態では遅延の再現はされませんでした。
    rt_cacheをクリアした所でまた遅延しましたので、

    「venetを超えてrt_cacheにエントリを登録する時に遅延する」

    というのがmemcachedのタイムアウトに引っ掛かっていた原因となります。


    内容に誤りがあり、申し訳有りませんでした。&ご指摘ありがとうございました。
    Are you sure you want to
    Your message goes here
  • すいません、Cache::Memcachedのdefault timeoutが0.25secになってました。。。
    Are you sure you want to
    Your message goes here
  • Cache::Memcachedがそういった設計になっていたかと思います。
    http://search.cpan.org/~bradfitz/Cache-Memcached-1.27/lib/Cache/Memcached.pm


    あと、ネットワーク遅延の件なのですが画像の大きさに限らずrouting chacheのコストで遅延がおきていました。
    一度routing cacheにエントリが登録されると遅延は発生せず、手動でエントリをクリアしたのち遅延が再発していたので、routing cacheのコストが原因だと思っています。

    スライドでは絶対に1登録に0.03秒かかるかの用に書いてありますが、ちょっと違います。
    特にコストがかかるのがvenetを超えてホストがcacheテーブルに登録するときでした。
    Are you sure you want to
    Your message goes here
  • 0.1sec のタイムアウトがサーバ一台のときにはきかないというお話でしたが、そういう設計のモジュールはみたことがないのですが、なんという名前のモジュールでしょうか?
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
10,047
On Slideshare
10,024
From Embeds
23
Number of Embeds
3

Actions

Shares
Downloads
65
Comments
6
Likes
6

Embeds 23

http://www.slideshare.net 20
http://s.deeeki.com 2
http://webcache.googleusercontent.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • OpenVZ とは Linux カーネルをベースに開発された「 OS レベルの仮想化ソフト」 ライセンスは GPL のバージョン2 商用版として Parallels 社の Viruozzo がある
  • 稼働中のコンテナのメモリの設定も可能(512 MB->1GB  など) CPU,IO 周りは Linux のスケジューラに準拠
  • 18 台のコンテナが 4GB メモリのマシン上でネイティブの速度で稼動
  • ハイパーパイザ型の場合はメモリを占有で割り振る メモリの free も占有するので、全体で共有できない
  • OpenVZ ではメモリは占有ではなく、利用する権限を与える メモリの free 部分も共有するので、たくさんのコンテナを稼動させることが可能
  • arp broadcast を venet0 がコンテナに転送する際に遅延が発生していました。 ※   Kazuho さん情報ありがとうございました!! http://d.hatena.ne.jp/kazuhooku/20091007/1254890935
  • P2V による物理サーバをコンテナをイメージ化
  • LVM2 の snapshot の機能を利用してコンテナのスナップショットの作成 ダウンタイム、バックアップタイムが0で可能
  • 物理サーバでイメージの作成
  • OpenVZ サーバでイメージの展開 デバイスファイルなどの作成
  • 起動して完了
  • DRBD で /vz があるデバイスをネットワーク同期 HB で OpenVZ サーバの相互監視 HB でコンテナの起動をコントロール
  • Active サーバがダウンした場合に HB が Standby サーバのコンテナを稼動させる これでほぼダウンタイムが0の冗長構成が可能
  • 移動元サーバでメモリダンプを作成 設定ファイル、ファイルシステム、メモリダンプをすべて転送 (rsync で同期 ) この間コンテナは一時停止状態
  • すべて転送が完了したらメモリダンプを復元し、コンテナの稼動 ネットワーク周りは arpsend とかすると思う

Transcript

  • 1.        ~ High-Performance Virtualization ~ www.shanon.co.jp id: ふじゃ fujya
  • 2. 自己紹介
    • id:fujya (twitter/hatena/mixi/gree で使えます )   [email_address]
    • Shanon という会社で働いてます
    • インフラエンジニア暦3年 linux/centos/monit/syslog-ng/cacti/apache/qmail/postfix/postgres/perl/bash/openvz glusterfs/drbd/heartbeat/samba/nfs/pxe/kick-start/windows(?)/network/server/HW and more…
  • 3. 略歴
    • 1984年:新潟 県新発田市というところで生まれる
    •    幼 / 小 / 中と健やかに成長
    • 2000年:高校入学。コンピュータに興味を持つ
    • 200 3 年:千葉の大学に入学。コンピュータの講義をたくさん受け、この頃からインフラへの興味が高まる
    • 200 7 年:ギリギリ卒業。株式会社シャノン入社後インフラエンジニアとして働き始める
    • 2009年:8月に結婚しました
  • 4. 目次
    • OpenVZ 概要
    • 他仮想化との違い
    • 運用 中に出くわしたトラブル集
    • Twitter で集めてた質疑に応答
    • まとめ
  • 5. OpenVZ とは
    • Linux カーネルをベースに開発された OS レベルの仮想化ソフト
    • GPL v2
    • 商用版として Parallels 社 ( 旧 SWsoft) の「 Virtuozzo 」がある
      • 多くのホスティング業者が VPS サービスを提供している
  • 6. 仮想化の種類
  • 7. OS レベルの仮想化ってなんぞ?
    • カーネルは1つ。その上に複数 OS を稼動させる
    • 他仮想化よりも軽量
    • 仮想レイヤのオーバヘッドが少ない
    • OpenVZ の場合、仮想化できるのは Linux のみ
      • SUSE/CentOS/Fedora/debian etc...
  • 8. 結論から言うと
    • OpenVZ はカーネルは一つ
    • だから
    早い!たくさん立てれる! でも自由度が低い
  • 9. OpenVZ の特徴
    • 稼動中のコンテナに対してのリソース管理が可能
      • CPU
      • メモリ
      • Disk
    • 仮想化による CPU のコストは 1-2% と低い
    • 各コンテナ毎にファイルシステム , プロセス , ネットワークが独立している
    • デバイスファイルへはアクセス制限されている
    • Fair CPU scheduler
    • Fair I/O scheduler
    • live migration 機能
    migration!
  • 10. Fujya が OpenVZ を選んだ理由
    • 抱えていた課題
    • 1:電源容量の削減をしたい
    • 2:今動いてる弱小サーバをパワーアップしたい
    • 3:サーバ単位でバージョン管理したい
    • 4:気軽に開発環境 / 本番環境を増やしたい
  • 11. とある4 GB つんだ OpenVZ サーバのコンテナ数 [root@st-virtual ~]# vzlist CTID NPROC STATUS IP_ADDR HOSTNAME 1212 25 running 192.168.1.10 1212.CT 1214 10 running 192.168.1.41 1214.CT 1220 33 running 192.168.1.3 1220.CT 1231 19 running 192.168.1.4 1231.CT 1232 27 running 192.168.1.9 1232.CT 1233 12 running 192.168.1.20 1233.CT 2001 19 running 192.168.1.25 2001.CT 2020 21 running 192.168.1.51 2020.CT 2021 22 running 192.168.1.52 2021.CT 5050 36 running 192.168.1.200 5050.CT 5051 36 running 192.168.1.197 5051.CT 6001 28 running - 6001.CT 6002 7 running 192.168.1.29 6002.CT 6003 17 running 192.168.1.30 6003.CT 7001 21 running 192.168.1.34 7001.CT 8001 29 running 192.168.1.36 8001.CT 8002 29 running 192.168.1.37 8002.CT 9001 18 running 192.168.1.50 9001.CT [root@st-virtual ~]# vzlist | grep –v VEID | wc -l 18 18台が同時稼動
  • 12. 他仮想化との違い メリット / デメリット
  • 13. OpenVZ とハイパーバイザの違い Dom0 256/512MB 256/512MB 128/512MB 384/512MB 物理メモリ合計2 GB 使用量 残量 DomU 01 DomU 03 DomU 02 仮想マシンでメモリを占有。 ホントは1GBあまってるのに・・・
  • 14. OpenVZ とハイパーバイザの違い ホスト 1024(256+256+128+384)/2048MB 256/2048MB 128/2048MB 384/2048MB 物理メモリ合計2 GB 使用量 残量 CTID 101 CTID103 CTID 102 残り使えるメモリは1GB!
  • 15. クイックインストールガイド
    • Linux インストール
    • OpenVZ リポジトリの設定
    • OpenVZ カーネルのインストール
    • カーネルパラメータを OpenVZ 用に数行修正
    • ユーティリティパッケージのインストール
    • ブートローダーの設定 -> 再起動
    # cd /etc/yum.repos.d # wget http://download.openvz.org/openvz.repo # rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ # cd /etc/yum.repos.d # yum install openvz-kernel
  • 16. コンテナの立ち上げ
    • テンプレートを作成 or Download
    • テンプレートを指定してサーバの立ち上げ
    # vzctl create 1003 –ostemplate centos-4-i386-default –config sample --hostname example.com http:// wiki.openvz.org /Download/template/metadata
  • 17. コンテナの設定
    • vzctl コマンドを用いて各リソースを設定
      • CPU
      • メモリ
      • Disk
      • ネットワーク
      • Hostname
      • Nameserver
      • users password
      • etc…
    # vzctl set 1003 –cpulimit 1000 –privvmpages $((256*128)) –diskspace 1G --hotname hbstudy4.test. –ipadd 192.168.100.100 –nameserver 10.8.15.1 --userpasswd root:hbstudy4 --save
  • 18. コンテナの起動と停止とか
    • vzctl コマンド…起動!
    • 停止
    • 削除
    # vzctl start 1001 # vzctl stop 1001 # vzctl destroy 1001
  • 19. 各種 VZ コマンド
    • vzcalc – コンテナのリソース利用状況を出力
    • vzcfgvalidate – コンテナの設定ファイルのチェック
    • vzcpucheck – マシンの cpu パワーを数値化
    • vzlist – コンテナリストを出力
    • vzmemcheck – コンテナのメモリ設定を一覧で出力
    • vzmigtate – live migration を実行
    • vzpid – 実際の PID をコンテナの PID に変換して出力
    • vzsplit – サンプルコンテナ設定ファイルを作成
    • vzdump – コンテナのバックアップを実施
    • vzyum – ホストサーバからコンテナに yum コマンドを実行
    •                                   他にもたくさん
  • 20. 運用中に出くわしたトラブル集               だワン
  • 21. 第一話   memcahed が使えない!!!?? Cache 死亡フラグ
  • 22. Memcached が使えない!!!??    序章
    • 待望の OpenVZ 本番導入の日
    • 特に問題なくリリース作業は進んでいく
    • 最終確認作業に入り間もなく問題なくリリース完了・・・・
    •              と、誰しも思っていたその時!?
  • 23. Memcached が使えない!!!??  序章
    • 「なんか画像が出たり出なかったりするんすけど?」 ・・・・・「ぇ ? 」
  • 24. Memcached が使えない!!!?? 調査
    • Memcached サーバの立ち上げ忘れかもしれない・・・忘れてない。
    • クライアントとサーバの memcached バージョン変えたから?
    • 旧バージョンに戻しても現象は再発
    • あれ?サーバの設定を1台にしたら動く
    •     とりあえずオープンまで時間が無い。
    •      サーバ1台構成で OPEN
  • 25. Memcached が使えない!!!??  解答編 Memcached- client Memcached-server eth0 eth0 OpenVZ リリース前の構成 物理サーバ A 物理サーバ B 0.006 秒
  • 26. Memcached が使えない!!!??  解答編 eth0 eth0 vent0 vent0 Memcached- client Memcached-server Vent0:0 Vent0:0 OpenVZ リリース後の構成 A  ホスト B  ホスト コンテナ 102 コンテナ 101 0.3 秒
  • 27. Memcached が使えない!!!??  解答編
    • arp broadcast forward 0.3sec
    • Memcached client default timeout 0.25sec
    eth0 eth0 vent0 vent0 Memcached- client Memcached-server Vent0:0 Vent0:0 A  ホスト B  ホスト コンテナ 101 コンテナ 102 arp broadcast forward
  • 28. Memcached が使えない!!!??  解決編
    • 解決方法:
    • venet0 による arp brouadcast forward   ×
    • br0 によるフレーム転送           ○
    eth0 eth0 br0 br0 Memcached- client Memcached-server eth0 eth0 A  ホスト B  ホスト コンテナ 101 コンテナ 102 0.006 秒
  • 29. 第二話                     届かない e-mail
  • 30. 届かない e-mail    はじめ
    • memcached の問題も解決し、OpenVZの運用が順調に進んでいる・・・
    •   が ある日の事
  • 31. 届かない e-mail    苦情編
    • 「メール遅れない時あるんだけど・・・?何これ?」
    • ごめん、知らない。
  • 32. 届かない e-mail    危機編
    • 確認できた現象と再現環境
    [user@CTID1001]$ free -m 合計 使用済 空き領域 共有領域 バッファ キャッシュ Mem: 4047 3530 517 0 0 0 -/+ バッファ : 3530 517 Swap: 0 0 0 privvmpages 1572864(6GB) 物理メモリ :4GB Swap :2GB [user@CTID1001]$ ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1700 524 ? Ss Jul30 0:01 init [3] … .. user 32390 0.0 74.1 3572043 3072000 ? S Sep04 0:00 perl-fcgi
  • 33. 届かない e-mail    危機編
    • 確認できた現象と再現環境
    [user@CTID1001]$ free -m 合計 使用済 空き領域 共有領域 バッファ キャッシュ Mem: 4047 3530 517 0 0 0 -/+ バッファ : 3530 517 Swap: 0 0 0 privvmpages 1572864(6GB) 物理メモリ :4GB Swap :2GB [user@CTID1001]$ ps auxww USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1700 524 ? Ss Jul30 0:01 init [3] … .. user 32390 0.0 74.1 3572043 3072000 ? S Sep04 0:00 perl-fcgi user 32391 0.0 0.1 1203 756 ? S Sep04 0:00 \ _ - qmail-inject cannot allocate memory
  • 34. 届かない e-mail    危機編
    • Linux はプロセスを fork するときは「 Copy on Write 」方式を採用
    • Copy On Warite
    • 1. perl-fcgi が fork
    • 2.仮想アドレス空間を copy ( qmail-inject にはリードオンリーで提供)
    • 3. qmail-inject が MMU に write 要求
    • 4.カーネルは新しい物理メモリを確保し割り当てる
    • Privvmpages は利用メモリ量だけでなく仮想アドレス空間の確保も実施
    2番で仮想アドレス空間が枯渇
  • 35. 届かない e-mail    解決?
    • privvmpages
    • 6GB メモリを割り振っていた
    • 33554432 GB 割り振る
    • 再現しなくなった!問題解決!!
    • (vmguarpages でメモリ確保量を保証することが出来る )
  • 36.
    • 第3話
    • N F S トラブル
  • 37. NFS トラブル      序章
    • 社内のファイルサーバを OpenVZ 化する計画が発足
    • 新ファイルサーバを構築して、最後をして移行 rsync する計画
    • おおむね構築は完了。各種サービスの確認開始
    P2V 現行ファイルサーバ 新ファイルサーバ ( OpenVZ )
  • 38. NFS トラブル      序章
    • NFS サーバスタート
    # /etc/rc.d/init.d/nfs start NFS サービスを起動中  [OK] NFS クォータを起動中   [OK] NFS デーモンを起動中  [NG] NFS mount を起動中  [OK] なんか失敗したんですが
  • 39. NFS トラブル      調査編
    • google 先生教えてください
    カーネルの再構築が必要だよ by
  • 40. NFS トラブル      問合編
    • カーネル再構築なんて面倒
    • 他に良い手が無いの? Google 先生
    NFSD がダメなら UNFS 使えば良いじゃない? by
  • 41. NFS トラブル       what UNFS?
    • UNFS とは
    • ユーザスペースで動く NFS (通常はカーネルサポート)
    • NFSv3 の仕様に沿って実装
    • パフォーマンスは通常よりも少し遅い。でも気にならないほど
    • Linux/Soralis でも動くことが確認されている
    • Connectathon の NFS test suite の基本的で一般的なテストに合格
    http:// www.connectathon.org/nfstests.html
  • 42. NFS トラブル       UNFS で解決
    • 実際にコンテナに UNFS をインストール
    • Read/Write はもちろん問題なく可能
    • Bonnie++ のパフォーマンステストも正常に終了
    • I/O の速度も 100Mbps 環境で 80 ~ 90Mbps は出ることを確認
    • UNFS で問題回避
  • 43. Twitter で集めてた質疑に応答
    • 質疑を見落としてました。。。
  • 44. OpenVZ 応用編
    • No downTime backup
    • P2V(Physical to Virtual)
    • Excellent Redundancy system (DRBD + HeartBeat + OpenVZ)
    • Live migration
  • 45. No downTime backup
    • LVM2 の機能を利用したスナップショットバックアップ
    OpenVZ  サーバ CTID101 (Running) /vz (LVM2) [root@openvz]# vzdump --dumpdir /vz/backup --snapshot 1001 CTID 1001 snapshot backup image
  • 46. P2V(Physical to Virtual) [root@physical]# cat << EOL > /tmp/excludes.excl .bash_history /dev/* /mnt/* /tmp/* /proc/* /sys/* /usr/src/* EOL [root@physical]# tar cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl [root@physical]# scp /tmp/mysystem.tar.bz2 user@openvz:/tmp 1.Physical image の作成
  • 47. P2V(Physical to Virtual) [root@openvz]# mkdir /vz/root/1001 /vz/private/1001 [root@openvz]# cat /etc/vz/conf/ve-vps.basic.conf-sample > /etc/vz/conf/1001.conf [root@openvz]# vzctl set 1001 ipadd x.x.x.x --save [root@openvz]# mv /tmp/mysystem.tar.bz2 /vz/private/1001 [root@openvz]# tar xjpf /vz/private/1001/mysystem.tar.bz2 [root@openvz]# sed -i -e '/getty/d' /vz/private/1001/etc/inittab [root@openvz]# rm -f /vz/private/1001/etc/mtab [root@openvz]# ln -s /proc/mounts /vz/private/1001/etc/mtab [root@openvz]# cp /vz/private/1001/etc/fstab /vz/private/1001/etc/fstab.old [root@openvz]# grep devpts /vz/private/1001/etc/fstab.old > /vz/private/1001/etc/fstab [root@openvz]# mknod --mode 666 /vz/private/1001/dev/ptmx c 5 2 [root@openvz]# mkdir /vz/private/1001/dev/pts [root@openvz]# cp -a /dev/ttyp* /dev/ptyp* /vz/private/1001/dev/ [root@openvz]# /sbin/MAKEDEV -d /vz/private/1001/dev ttyp ptyp [root@openvz]# rm -f /vz/private/1001/dev/null [root@openvz]# mknod --mode 666 /vz/private/1001/dev/null c 1 3 [root@openvz]# mknod --mode 444 /vz/private/1001/dev/urandom c 1 9 [root@openvz]# mkdir /vz/private/1001/proc 2.Openvz server settings
  • 48. P2V(Physical to Virtual) [root@openvz]# vzctl start 1001 3. Container start P2V 完了!!
  • 49. Excellent Redundancy system DRBD で /vz を sync OpenVZ  サーバ( A) OpenVZ  サーバ( B) /vz /vz CTID101 (Running) CTID101 (stopped) HB で相互監視
  • 50. Excellent Redundancy system DRBD で /vz を sync OpenVZ  サーバ( A) OpenVZ  サーバ( B) /vz /vz CTID101 (death) CTID101 (stopped) Down!! HB で相互監視
  • 51. Excellent Redundancy system OpenVZ  サーバ( A) OpenVZ  サーバ( B) /vz /vz CTID101 (death) CTID101 (Running) Down!! HB で相互監視 サーバ( A )の Down を確認後 サーバ( B) の CTID1001 を起動
  • 52.
    • Demo する予定でした。。。
    Live migration
  • 53. Live migration OpenVZ  サーバ( A) OpenVZ  サーバ( B) /vz /vz CTID101 (Running) メモリーダンプ ファイルシステムを移動
  • 54.
    • Demo しますね
    Live migration OpenVZ  サーバ( A) OpenVZ  サーバ( B) /vz /vz CTID101 (Running) メモリーダンプを復元 リソースの配分し稼動
  • 55. まとめ
    • High Performance
    • 同時にたくさんコンテナを稼動させられる
    • 柔軟なリソース管理
    • Checkpointing and live migration support
  • 56.
    • ご清聴ありがとうございました