Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

コンテナ基盤であるLXC/LXDを 本番環境で運用する話

1,340 views

Published on

LXC/LXD

Published in: Technology
  • Be the first to comment

コンテナ基盤であるLXC/LXDを 本番環境で運用する話

  1. 1. GMOデジロック株式会社 2017年9月7日 コンテナ基盤であるLXC/LXDを 本番環境で運用する話
  2. 2. 目次 1. 自己紹介 2. LXD 採用まで編 3. LXD 構築から運用まで編 4. LXD 運用編 5. 総括
  3. 3. 自己紹介 名前:藤田伸広 職業:GMOデジロック株式会社 技術部マネージャ (LAN配線から仮想化、お金の話まで担当) 性格:パリピ 特徴:トラブルシューティングは好きだが、 ディープなエンジニアでは無い
  4. 4. ドメインサービス 紹介 低価格、自由度・柔軟性を重視したサービス
  5. 5. ホスティングサービス 紹介 低価格、自由度・柔軟性を重視したサービス ↑コンテナ採用 ↑リニューアル中 続々コンテナ採用予定! ↑私が担当
  6. 6. 弊社は社員11名の会社、 仮想基盤の調査を行ったのは、 社長、私ともう一人の合計3名
  7. 7. 技術的に難しい内容 ⇒ 社長 その他 ⇒私
  8. 8. コンテナ基盤の活用状況 XREA リニューアル完了 好調です! CORESERVER リニューアル中 LXD構成で新規募集開始してます!
  9. 9. ~ LXD 採用まで編~
  10. 10. XREA 仮想化前史~完全仮想化へ 1. その昔、創業当初からのものを含む、古い物理サーバー を使っていた。ハード、ソフトとも老朽化しすぎ。。。 2. 2011年、マイグレーションに際して、KVM 完全仮想化を 採用して刷新。 3. 400 台弱のサーバーが、2ラックに収まった。
  11. 11. 0 150 300 450 物理 KVM LXD サーバー台数推移
  12. 12. 完全仮想化の利点と問題点~運用してみて 1. セキュリティリスクや負荷のコントロールがVM内で完結 1. HDDディスクイメージの容量不足・増設でストレージの無駄が顕在化 2. CPU、メモリ、ディスク等でパフォーマンス不足、無駄の多さが目立つ ……。 3. そして準仮想化へ。 メリット デメリット
  13. 13. よし、時代はコンテナだ! 無駄があるということは、最終的にお客様に 最高のコストパフォーマンスを提供できない!
  14. 14. なぜコンテナか? 1. 年月が経ち、サーバー毎にアクティブ数がまちまちである 2. 最小限のコストで最大限のパフォーマンス 3. 保守・運用が楽、安定している 4. 弊社の規模・要件にマッチしている
  15. 15. なぜLXDか? ・Docker ⇒ 話題のDockerでレンタルサーバーでやってやろう!と試行錯誤するも、 ユーザーの権限独立とネットワーク周りの問題が解決できず、本要件には不 向きと判断 ・KVM ⇒ 前述の通り、オーバーヘッドが多くてリソースが無駄 ・OpenVZ ⇒ コンテナより遅かった ・Vmware ⇒ 考えたこともない、高い ・LXD ⇒コンテナだと、リソースが有効に使えて、ヒャッハー(儲かる)だ!
  16. 16. LXD採用からサービス開始まで① ・コンテナの採用決定から本番まで半年しかなかった ・2016年夏 構築・運営ノウハウ、全てゼロからのスタート!
  17. 17. LXD採用からサービス開始まで② • 2017年2月 運用スタート! • 2017年5月 全台リニューアル完了! • 2017年6月 安定稼働! コンテナの障害なし! まだまだ日々試行錯誤中・・・
  18. 18. XREA、LXDの運用対象 • アカウント数:30万ぐらい • データ量:50TBぐらい • ファイル数:8億ぐらい • 帯域:1Gbpsぐらい
  19. 19. XREA、 LXDの運用環境 • D社サーバー • オールフラッシュ RAID10 • 1ラックに収まるぐらいの台数^^;
  20. 20. XREA、 LXDの運用環境 • ホストOS:Ubuntu 16.04 LTS CentOS7なども検証。やっぱり、 Ubuntu。 • ゲストOS:CentOS7 共有サーバー要件で最適 保守・運用上、実績があり、使い慣れたもの(時間の節約)
  21. 21. なぜZFSか? • 公式がおすすめしているw • ベンチマークが最速(個人的見解) • 成熟しているっぽい
  22. 22. ベンチマーク ホスト Seq-Read: bw=5535.2MB/s, iops=5535 Seq-Write: bw=3002.1MB/s, iops=3002 Rand-Read-512K: bw=5224.6MB/s, iops=10448, Rand-Write-512K: bw=2994.2MB/s, iops=5988 Rand-Read-4K: bw=890889KB/s, iops=222722 Rand-Write-4K: bw=249720KB/s, iops=62430 Rand-Read-4K-QD32: bw=911013KB/s, iops=227753 Rand-Write-4K-QD32: bw=255501KB/s, iops=63875 • fioでの計測 • 5~15%のオーバヘッドは あるものの、概ね良好! コンテナ Seq-Read: bw=4718.1MB/s, iops=4718 Seq-Write: bw=2790.2MB/s, iops=2790 Rand-Read-512K: bw=4376.7MB/s, iops=8752 Rand-Write-512K: bw=2730.7MB/s, iops=5461 Rand-Read-4K: bw=882640KB/s, iops=220659 Rand-Write-4K: bw=229749KB/s, iops=57437 Rand-Read-4K-QD32: bw=874542KB/s, iops=218635 Rand-Write-4K-QD32: bw=248301KB/s, iops=62075
  23. 23. ~ LXD 構築から運用まで編~
  24. 24. ホストシステム構築時のトラブル • オープンファイル数の上限 fs.inotify.max_user_instances • PID、スレッド数の上限 kernel.threads-max kernel.pid_max • 共有メモリー系の上限 vm.max_map_count kernel.msg*
  25. 25. オープンファイル数の上限編 コンテナばんばん作成するぜー! Error: Too many open files Job for network.service canceled. あれ? ⇒コンテナの作成台数が20台を越えた辺りからネットワーク周りが不安定になる ⇒ファイル数、プロセス周りの制限が掛かって上手くいかないのか? こんな事やりました↓
  26. 26. オープンファイル数の上限編 echo 1000000 > /proc/sys/fs/file-max vi /etc/sysctl.conf fs.file-max=1000000 vi /etc/security/limits.conf * soft nofile 1000000 * hard nofile 1000000 ulimit -n 1000000 あれ?直んない ↓ なんで ↓ なんで ↓ なんで ↓ こっちかい ↓
  27. 27. オープンファイル数の上限編 echo "fs.inotify.max_user_instances = 819200" | tee -a /etc/sysctl.conf && sudo sysctl –p そっちかい!
  28. 28. その他上限解除編 fs.aio-max-nr fs.inotify.max_user_instances kernel.msgmax kernel.msgmnb kernel.msgmni kernel.pid_max kernel.sem kernel.shmall kernel.shmmax kernel.shmmni kernel.threads-max net.core.rmem_max net.core.somaxconn net.core.wmem_max net.ipv4.ip_conntrack_max net.ipv4.tcp_fin_timeout net.ipv4.tcp_max_orphans net.ipv4.tcp_rmem net.ipv4.tcp_sack net.ipv4.tcp_syncookies net.ipv4.tcp_timestamps net.ipv4.tcp_window_scaling net.ipv4.tcp_wmem net.nf_conntrack_max vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_ratio vm.dirty_writeback_centisecs vm.max_map_count
  29. 29. ネットワーク編① XREA マイグレも順調、コンテナばんばん作成するぜー! 社長「コンテナのネットワーク繋がらないよ」 藤田「えっ、いや、作成後にネットワークの接続も確認してるし、 正常稼動しているコンテナと同じ構成設定してるのに・・」 全く同じ構成で作成しているのに上手くいかない・・ 技術者として最も嫌なやりがいのあるシチュエーション
  30. 30. ネットワーク編① XREA 藤田「えー慣れない、HSRPなんかやったからかな・・」 まずは自分の設定が正しかったのか自問自答 しかも、予備のNW機器からだと、正常に接続できる。 すでに本番稼働中、サーバーは止めれない。 ○ISCOのサポートと一ヶ月半に及ぶ調査の結果
  31. 31. ネットワーク編② CORE ノウハウもあるし、コンテナばんばん作成するぜー! NW機器を監視して頂いてるGMOインターネットの方から連絡が、 「NW機器がしんどそうなんですけど」 ネットワーク機器、高負荷問題 ⇒仮想化の認識の通りで設定・・・
  32. 32. ネットワーク編② CORE タグVLANで複数のセグメントを受けるNW構成 ⇒NICを複数作成した際に、NICのMACがかぶっていた… KVMであれば、VM毎にユニークなMACアドレス自動を振るが コンテナは、ホスト毎のユニークなMACアドレスで明示的に 割り振る必要があった
  33. 33. ~ LXD 運用編~
  34. 34. 運用時の苦労 マイグレ前半は特にLXDに関連する大きなトラブルは無し!! だが後半、マイグレ作業中に、Apacheのアラートがバンバンなり始める! 「なんだなんだ!?」 容赦なくアラートはバンバン増えていく、薄れゆく意識(夜間作業)、 増大する恐怖・・・ 「ここまで来て、まさかの、切り戻しか・・」 作業時間午前4時… 原因判明 ↓
  35. 35. 運用時の苦労 原因は Apache RLimitNPROC + Potential DoS attacks https://linuxcontainers.org/lxc/security/ ⇒要は、各コンテナでプロセス起動数制限をかける際、制限対象のUIDが共通 であるプロセス数を、全コンテナで見てしまっていた
  36. 36. 運用時の苦労 ホストのロードアベレージが急激に上昇、 ホストからは問題のあるユーザーは特定できない・・ ⇒ZFSがボトルネック チューニングを実施 zfs_arc_meta_adjust_restarts zfs_arc_meta_limit zfs_arc_meta_prune zfs_arc_max 収まったものの、まだまだ未知の問題がでる可能性があり 日々試行錯誤、格闘しています。
  37. 37. 運用時の苦労 コンテナ自体のリソース制御は、この辺をチューニング しています。 (自動化トライ中…) limits.cpu: limits.memory: limits.memory.enforce:
  38. 38. 運用時の苦労 ホスト側からコンテナ自体のリソース制御 + コンテナ内の特定のUIDへの リソース制御 を組み合わせた柔軟な仮想環境に トライ中…
  39. 39. ~ 総括~
  40. 40. LXDはヒャッハーなのか?
  41. 41. LXDに変えてどうだったか ・2ラック(KVM)⇒1ラック(LXD)にできた ・運用でカバーしている部分もあるが、保守・運用負荷は減った ・集約率を上げたにも関わらず、以前よりも快適にご利用頂いている ・CPU/ストレージ/メモリー領域を有効に使える ⇒高速なCPUやSSD、大容量のメモリーを採用でき、安価でご利用頂ける ⇒結果として、競争力のあるサービスになった! ⇒おかげさまで、ユーザー数は増加中!
  42. 42. 結局のところ……
  43. 43. お客様の満足度が上がりました! LXD最高!! OSS/コンテナ開発関係者の 皆様に感謝!
  44. 44. ご清聴ありがとうございました!

×