LXC/LXD

1. GMOデジロック株式会社
2017年9月7日
コンテナ基盤であるLXC/LXDを
本番環境で運用する話

2. 目次
1. 自己紹介
2. LXD 採用まで編
3. LXD 構築から運用まで編
4. LXD 運用編
5. 総括

3. 自己紹介
名前：藤田伸広
職業：GMOデジロック株式会社
技術部マネージャ
（LAN配線から仮想化、お金の話まで担当）
性格：パリピ
特徴：トラブルシューティングは好きだが、
ディープなエンジニアでは無い

4. ドメインサービス 紹介
低価格、自由度・柔軟性を重視したサービス

5. ホスティングサービス 紹介
低価格、自由度・柔軟性を重視したサービス
↑コンテナ採用 ↑リニューアル中
続々コンテナ採用予定！
↑私が担当

6. 弊社は社員11名の会社、
仮想基盤の調査を行ったのは、
社長、私ともう一人の合計3名

7. 技術的に難しい内容 ⇒
社長
その他
⇒私

10. コンテナ基盤の活用状況
XREA リニューアル完了
好調です！
CORESERVER リニューアル中
LXD構成で新規募集開始してます！

13. ～ LXD 採用まで編～

14. XREA 仮想化前史～完全仮想化へ
1. その昔、創業当初からのものを含む、古い物理サーバー
を使っていた。ハード、ソフトとも老朽化しすぎ。。。
2. 2011年、マイグレーションに際して、KVM 完全仮想化を
採用して刷新。
3. 400 台弱のサーバーが、２ラックに収まった。

15. 0 150 300 450
物理
KVM
LXD
サーバー台数推移

16. 完全仮想化の利点と問題点～運用してみて
1. セキュリティリスクや負荷のコントロールがVM内で完結
1. HDDディスクイメージの容量不足・増設でストレージの無駄が顕在化
2. CPU、メモリ、ディスク等でパフォーマンス不足、無駄の多さが目立つ
……。
3. そして準仮想化へ。
メリット
デメリット

17. よし、時代はコンテナだ！
無駄があるということは、最終的にお客様に
最高のコストパフォーマンスを提供できない！

18. なぜコンテナか？
1. 年月が経ち、サーバー毎にアクティブ数がまちまちである
2. 最小限のコストで最大限のパフォーマンス
3. 保守・運用が楽、安定している
4. 弊社の規模・要件にマッチしている

19. なぜLXDか？
・Docker
⇒ 話題のDockerでレンタルサーバーでやってやろう！と試行錯誤するも、
ユーザーの権限独立とネットワーク周りの問題が解決できず、本要件には不
向きと判断
・KVM ⇒ 前述の通り、オーバーヘッドが多くてリソースが無駄
・OpenVZ ⇒ コンテナより遅かった
・Vmware ⇒ 考えたこともない、高い
・LXD
⇒コンテナだと、リソースが有効に使えて、ヒャッハー（儲かる）だ！

20. LXD採用からサービス開始まで①
・コンテナの採用決定から本番まで半年しかなかった
・2016年夏 構築・運営ノウハウ、全てゼロからのスタート！

21. LXD採用からサービス開始まで②
• 2017年2月 運用スタート！
• 2017年5月 全台リニューアル完了！
• 2017年6月 安定稼働！ コンテナの障害なし！
まだまだ日々試行錯誤中・・・

22. XREA、LXDの運用対象
• アカウント数：30万ぐらい
• データ量：50TBぐらい
• ファイル数：8億ぐらい
• 帯域：1Gbpsぐらい

23. XREA、 LXDの運用環境
• D社サーバー
• オールフラッシュ RAID10
• １ラックに収まるぐらいの台数＾＾；

24. XREA、 LXDの運用環境
• ホストOS:Ubuntu 16.04 LTS
CentOS7なども検証。やっぱり、 Ubuntu。
• ゲストOS:CentOS7
共有サーバー要件で最適
保守・運用上、実績があり、使い慣れたもの（時間の節約）

25. なぜZFSか？
• 公式がおすすめしているｗ
• ベンチマークが最速（個人的見解）
• 成熟しているっぽい

26. ベンチマーク
ホスト
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

27. ～ LXD 構築から運用まで編～

28. ホストシステム構築時のトラブル
• オープンファイル数の上限 fs.inotify.max_user_instances
• PID、スレッド数の上限 kernel.threads-max kernel.pid_max
• 共有メモリー系の上限 vm.max_map_count kernel.msg*

29. オープンファイル数の上限編
コンテナばんばん作成するぜー！
Error: Too many open files
Job for network.service canceled.
あれ？
⇒コンテナの作成台数が20台を越えた辺りからネットワーク周りが不安定になる
⇒ファイル数、プロセス周りの制限が掛かって上手くいかないのか？
こんな事やりました↓

30. オープンファイル数の上限編
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
あれ？直んない
↓
なんで
↓
なんで
↓
なんで
↓
こっちかい
↓

31. オープンファイル数の上限編
echo "fs.inotify.max_user_instances =
819200" | tee -a /etc/sysctl.conf && sudo
sysctl –p
そっちかい！

32. その他上限解除編
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

33. ネットワーク編① XREA
マイグレも順調、コンテナばんばん作成するぜー！
社長「コンテナのネットワーク繋がらないよ」
藤田「えっ、いや、作成後にネットワークの接続も確認してるし、
正常稼動しているコンテナと同じ構成設定してるのに・・」
全く同じ構成で作成しているのに上手くいかない・・
技術者として最も嫌なやりがいのあるシチュエーション

34. ネットワーク編① XREA
藤田「えー慣れない、HSRPなんかやったからかな・・」
まずは自分の設定が正しかったのか自問自答
しかも、予備のNW機器からだと、正常に接続できる。
すでに本番稼働中、サーバーは止めれない。
○ISCOのサポートと一ヶ月半に及ぶ調査の結果

36. ネットワーク編② CORE
ノウハウもあるし、コンテナばんばん作成するぜー！
NW機器を監視して頂いてるGMOインターネットの方から連絡が、
「NW機器がしんどそうなんですけど」
ネットワーク機器、高負荷問題
⇒仮想化の認識の通りで設定・・・

37. ネットワーク編② CORE
タグVLANで複数のセグメントを受けるNW構成
⇒NICを複数作成した際に、NICのMACがかぶっていた…
KVMであれば、VM毎にユニークなMACアドレス自動を振るが
コンテナは、ホスト毎のユニークなMACアドレスで明示的に
割り振る必要があった

38. ～ LXD 運用編～

39. 運用時の苦労
マイグレ前半は特にLXDに関連する大きなトラブルは無し！！
だが後半、マイグレ作業中に、Apacheのアラートがバンバンなり始める！
「なんだなんだ！？」
容赦なくアラートはバンバン増えていく、薄れゆく意識（夜間作業）、
増大する恐怖・・・
「ここまで来て、まさかの、切り戻しか・・」
作業時間午前4時…
原因判明
↓

40. 運用時の苦労
原因は
Apache RLimitNPROC
＋
Potential DoS attacks
https://linuxcontainers.org/lxc/security/
⇒要は、各コンテナでプロセス起動数制限をかける際、制限対象のUIDが共通
であるプロセス数を、全コンテナで見てしまっていた

41. 運用時の苦労
ホストのロードアベレージが急激に上昇、
ホストからは問題のあるユーザーは特定できない・・
⇒ZFSがボトルネック
チューニングを実施
zfs_arc_meta_adjust_restarts zfs_arc_meta_limit
zfs_arc_meta_prune zfs_arc_max
収まったものの、まだまだ未知の問題がでる可能性があり
日々試行錯誤、格闘しています。

42. 運用時の苦労
コンテナ自体のリソース制御は、この辺をチューニング
しています。
（自動化トライ中…）
limits.cpu:
limits.memory:
limits.memory.enforce:

43. 運用時の苦労
ホスト側からコンテナ自体のリソース制御
＋
コンテナ内の特定のUIDへの
リソース制御
を組み合わせた柔軟な仮想環境に
トライ中…

44. ～ 総括～

45. LXDはヒャッハーなのか？

46. LXDに変えてどうだったか
・2ラック（KVM）⇒1ラック（LXD）にできた
・運用でカバーしている部分もあるが、保守・運用負荷は減った
・集約率を上げたにも関わらず、以前よりも快適にご利用頂いている
・CPU/ストレージ/メモリー領域を有効に使える
⇒高速なCPUやSSD、大容量のメモリーを採用でき、安価でご利用頂ける
⇒結果として、競争力のあるサービスになった！
⇒おかげさまで、ユーザー数は増加中！

47. 結局のところ……

48. お客様の満足度が上がりました！
LXD最高！！
OSS/コンテナ開発関係者の
皆様に感謝！

51. ご清聴ありがとうございました！