LXD 採用から運用までの顛末記

LXD 採用から運用までの顛末記

1. 1. GMOデジロック株式会社 2017年6月17日 ＠大阪 左川善章 LXD 採用から運用までの 顛末記
2. 2. 目次 1. 自己紹介 2. LXD 採用まで編 3. LXD 構築から運用まで編 4. LXD 運用編 5. 総括
3. 3. 自己紹介 名前：左川善章 職業：GMOデジロック株式会社 技術部（サーバー保守・運用担当） 性格：真面目、誠実（笑） 特徴：ボケもツッコミも下手な関西人
4. 4. ドメインサービス 紹介 低価格、自由度・柔軟性を重視したサービス 契約数 140万件以上 ユーザー数21万人
5. 5. ホスティングサービス 紹介 低価格、自由度・柔軟性を重視したサービス ↑コンテナ採用 ↑リニューアル予定 続々コンテナ採用予定！
6. 6. ～ LXD 採用まで編～
7. 7. 色々お話させて頂きますが、 LXD採用で、 XREA、 ハイパフォーマンスで 安定稼動しております！！ コンテナ関係者の皆様に感謝！
8. 8. XREA 仮想化前史～完全仮想化へ 1. その昔、創業当初からのものを含む、古い物理サーバー を使っていた。ハード、ソフトとも老朽化しすぎ。。。 2. 2011年、マイグレーションに際して、KVM 完全仮想化を 採用して刷新。 3. 400 台弱のサーバーが、２ラックに収まった。
9. 9. 完全仮想化の利点と問題点～運用してみて 1. セキュリティリスクや負荷のコントロールがVM内で完結 1. HDDディスクイメージの容量不足・増設でストレージの無駄が顕在化 2. CPU、メモリ、ディスク等でパフォーマンス不足、無駄の多さが目立つ……。 3. そして準仮想化へ。 メリット デメリット
10. 10. よし、時代はコンテナだ！ このままでは、お客様の満足度が下がる！
11. 11. なぜコンテナか？ 1. 年月が経ち、サーバー毎にアクティブ数がまちまちである 2. 最小限のコストで最大限のパフォーマンス 3. 保守・運用が楽、安定している 4. 弊社の規模・要件にマッチしている
12. 12. なぜLXDか？ ・Docker ⇒ Dockerでレンタルサーバーでやってやろう！と試行錯誤するも、ユーザーの権限独立 とネットワーク周りの問題が解決できず、本要件には不向きと判断 ・KVM ⇒ 前述の通り、オーバーヘッドが多くてリソースが無駄 ・OpenVZ ⇒ コンテナより遅かった ・Vmware ⇒ 考えたこともない ・LXD ⇒コンテナだし、リソースが有効に使えて、ヒャッハーだ！ （開発・構築担当者 原文ママ）
13. 13. LXD採用からサービス開始まで① • コンテナの採用決定から本番まで半年しかなかった • 2016年夏 構築・運営ノウハウ、全てゼロからのスタート！
14. 14. LXD採用からサービス開始まで② • 2017年2月 運用スタート！ • 2017年5月 全台リニューアル完了！ • 2017年6月 安定稼働！ コンテナの障害なし！ まだまだ日々試行錯誤中・・・
15. 15. LXDの運用対象 • アカウント数：30万ぐらい • データ量：50TBぐらい • ファイル数：8億ぐらい • 帯域：1Gbpsぐらい
16. 16. LXDの運用環境 • D社サーバー • オールフラッシュ RAID10 • １ラックに収まるぐらいの台数＾＾；
17. 17. LXDの運用環境 • ホストOS:Ubuntu 16.04 LTS CentOS7なども検証。やっぱり、 Ubuntu。 • ゲストOS:CentOS7 共有サーバー要件で最適 保守・運用上、実績があり、使い慣れたもの（時間の節約）
18. 18. LXDの運用環境 • 最新版LXD 2.0.9 • ZFS + ブロックデバイス • ホスト、ゲストのファイルシステム：ext4
19. 19. なぜZFSか？ • 公式がおすすめしているｗ • ベンチマークが最速（個人的見解） • 成熟している（運用実績はないが…）
20. 20. ベンチマーク ホスト 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
21. 21. ～ LXD 構築から運用まで編～
22. 22. ホストシステム構築時のトラブル • オープンファイル数の上限 fs.inotify.max_user_instances • PID、スレッド数の上限 kernel.threads-max kernel.pid_max • 共有メモリー系の上限 vm.max_map_count kernel.msg*
23. 23. オープンファイル数の上限編 コンテナばんばん作成するぜー！（開発・構築担当者談） Error: Too many open files Job for network.service canceled. あれ？ ⇒コンテナの作成台数が20台を越えた辺りからネットワーク周りが不安定になる ⇒ファイル数、プロセス周りの制限が掛かって上手くいかないのか？ こんな事やりました↓
24. 24. オープンファイル数の上限編 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 あれ？直んない ↓ なんで ↓ なんで ↓ なんで ↓ こっちかい ↓
25. 25. オープンファイル数の上限編 echo "fs.inotify.max_user_instances = 819200" | tee -a /etc/sysctl.conf && sudo sysctl –p そっちかい！
26. 26. その他上限解除編 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
27. 27. ～ LXD 運用編～
28. 28. 運用時の苦労① ゲゲッ ユーザークォータできないん ですけど… ⇒色々調査したものの解決策が見つからず ⇒運用でカバー！
29. 29. 運用時の苦労② マイグレ前半は特にLXDに関連する大きなトラブルは無し！！ だが後半、マイグレ作業中に、Apacheのアラートがバンバンなり始める！ 「なんだなんだ！？」 容赦なくアラートはバンバン増えていく、薄れゆく意識（夜間作業）、 増大する恐怖・・・ 「ここまで来て、まさかの、切り戻しか・・」 作業時間午前4時… 原因判明 ↓
30. 30. 運用時の苦労② 原因は Apache RLimitNPROC ＋ Potential DoS attacks https://linuxcontainers.org/lxc/security/ ⇒要は、各コンテナでプロセス起動数制限をかける際、制限対象のUIDが共通 であるプロセス数を、全コンテナで見てしまっていた
31. 31. 運用時の苦労③ ホストのロードアベレージが急激に上昇、 ホストからは問題のあるユーザーは特定できない・・ ⇒ZFSがボトルネック チューニングを実施 zfs_arc_meta_adjust_restarts zfs_arc_meta_prune 収まったものの、まだまだ未知の問題がでる可能性があり 日々試行錯誤、格闘しています。
32. 32. 運用時の苦労④ コンテナ自体のリソース制御は、この辺をチュー ニングしています。 （自動化テスト中…） limits.cpu: limits.memory: limits.memory.enforce:
33. 33. 運用時の苦労⑤ ホスト側からコンテナ内のユーザーを制御するた め、コンテナ内のUIDを取得し、制御する仕組み をテスト中…
34. 34. ～ 総括～
35. 35. LXDはヒャッハーなのか？
36. 36. LXDに変えてどうだったか ・2ラック⇒1ラックにできた ・運用でカバーしている部分もあるが、保守・運用負荷は減った ・集約率を上げたにも関わらず、以前よりも快適にご利用頂いている ・CPU/ストレージ/メモリー領域を有効に使える ⇒高速なCPUやSSD、大容量のメモリーを採用でき、安価でご利用頂ける ⇒結果として、競争力のあるサービスになった！ ⇒おかげさまで、ユーザー数は増加中！
37. 37. 結局のところ……
38. 38. ヒャッハーだ！
39. 39. お客様の満足度が上がりました！ LXD最高！！ OSS/コンテナ開発関係者の 皆様に感謝！ ご清聴ありがとうございました。