LXC の本番利用事例 株式会社インターネットレボリューション インフラ課桑澤拓也 1
自己紹介 株式会社インターネットレボリューション 成り立ち : コナミデジタルエンタテインメントと IIJ の合弁会社 事業内容 : デジタルエンタテインメント事業のシステム業務インターネットサービスの開発 運営 発表者 アミューズメント施設向けサービスのインフラ担当者 (e-amusement サービス / システム ) 設計 ~ 構築 ~ 運用までひと通り 2
e-amusement システム クライアントの数 ゲームきょう体の数 - 家庭用ゲーム機やスマートフォンアプリ等と比べて数が少ない - リクエストが爆発的に増えることは無いので スケーラビリティはそれほど求められない 1 プレーごとにお金がかかっている - 可用性は重要 3
LXC とは? LXC はよく強力な chroot と本格的な仮想マシンの中間のようなものに見なされます LXC の目的は 可能な限り標準的な Linux のインストール環境に近く しかし別々のカーネルは必要ないような環境を作ることです Linux Containers - LXC - イントロダクション https://linuxcontainers.org/ja/lxc/ 主にシステムコンテナを作るために使用するアプリコンテナを作ることも可能 類似のもの Virtuozzo (OpenVZ) systemd-nspawn 4
LXC のここが好き 小さいオーバーヘッド - VM ほどの隔離性は無いが VM よりも軽量 システムコンテナ - VM に近い感覚で利用できる 豊富なテンプレートイメージ - すぐに使い始められる - 検証時のバージョンの CentOS テンプレートは若干問題があったが 5
LXC のここが好き 一斉コマンド実行 / ファイル操作が可能 - ホスト OS からコンテナ内でコマンド実行 (lxc-attach) # for c in $(lxc-ls --active); do lxc-attach -n $c -- systemctl reload sshd done - ホスト OS からコンテナ用のファイル操作 ( ホストディレクトリの一部を rootfs として利用している場合 ) # md5sum /var/lib/lxc/*/rootfs/etc/hogehoge 6
LXC のここが好き コンテナフック - コンテナを起動 停止 クローンする際にスクリプトを実行できる - フックタイプによって様々な実行タイミングを選択可能 lxc.hook.pre-start lxc.hook.clone lxc.network.script.up lxc.hook.start 詳細は lxc.container.conf(5) を参照 7
他の Linux コンテナ実装について OpenVZ (Virtuozzo) - 検証時はまだ RHEL 6 ベース - kernel 自体にかなり手を入れているのが気になった - 現在ではソースコードも公開されている systemd-nspawn 検証時 (CentOS 7.0.1406) は - 特にネットワーク周りの機能が不足していた - 今なら選択できるかもしれない Docker - できなくはないが システムコンテナ向けではない - stateless, immutable な環境向き 8
LXC 利用システム ホスト OS - CentOS 7.1.1511, LXC 1.1.2, Python3 - Libvirt や LXD は使わず lxc-* コマンドを利用 - LXCFS を真似たリソース監視用の自作ツール 2 台の物理サーバ - ゲームタイトルやシステムの用途毎にコンテナを作成 - 現在 1 物理サーバあたり 40 以上のコンテナが稼働 DB サーバコンテナ - Corosync, Pacemaker による HA (2 コンテナで 1 セット ) - Stonith なし 2 ノードクラスタ, VIPcheck によるマルチマスター防止 - PostgreSQL 9.4, 同期レプリケーション, 共有ディスクなし 本番環境での運用実績は 1 年程度 9
システム構成 コンテナ (LXC 1.1.2) コンテナ (LXC 1.1.2) 同期レプリケーション PostgreSQL 各コンテナに PostgreSQL, Pacemaker, Corosync PostgreSQL Pacemaker Corosync クラスタ通信 Pacemaker Corosync init (systemd) x 40 containers init (systemd) ホスト OS (CentOS 7.1.1503) ホスト OS (CentOS 7.1.1503) 物理ホスト インターコネクト 物理ホスト SSD HDD SSD HDD サービス用 10
コンテナのネットワーク ( 全体イメージ ) 1 号機系 ( 通常時 Master) 2 号機系 ( 通常時 Standby) コンテナ VIP コンテナ VIP インターコネクト コンテナ VIP VIP コンテナ コンテナ VIP VIP コンテナ サービス用 11
コンテナのネットワーク ( 詳細 ) Master になるコンテナは VIP を作る ( 仮想 MAC アドレスを使うために IPaddr2 を改造した Resource Agent の VIP) コンテナの Namespace ホストの Namespace vmac0 (macvlan) eth0 (macvlan) VIP bond0.10 (802.1q tagging) bond0 (bonding) IPaddr2 の VIP eth1 (802.1q) VIP bond1 (bonding) em1 (phys) em2 (phys) em3 (phys) em4 (phys) p2p1 (phys) p2p2 (phys) サービス用 インターコネクト テンプレートは bridge + veth になっているので そちらが一般的? 12
macvlan Container Container Container 同じセグメントでも通信不可 ( セキュリティ的に望ましい ) eth0 (macvlan) eth0 (macvlan) eth0 (macvlan) IP IP IP 別セグメントの場合は外部の L3 機器経由なら通信可能 IP Host Router Router bridge mode 同一ホスト上のコンテナ間の直接通信が可能 private mode 同一ホスト上のコンテナ間の直接通信は不可能など複数の動作モード 13
仮想 MAC アドレス VIP VIP VIP ほぼ同時に大量の GARP FDB 更新 OK 某社 L2 スイッチ 某社 L3 スイッチ ARP cache 更新一部 NG??? macvlan インタフェースに HA クラスタ毎に共通の MAC アドレスを設定 ARP cache の更新を不要にする 正しい MAC アドレスで ARP 応答させるため 以下の kernel paramter に注意 arp_filter, arp_ignore, arp_announce, rp_filter https://github.com/acassen/keepalived/blob/master/doc/note_vrrp_vmac.txt http://qiita.com/albatross/items/8c32615b5154acf712f2 14
運用の悩み コンテナのリソース制御 - CPU cgroup で制御可能だが 適切な設定を定められず野放し - ディスク使用量 XFS project quota で疑似的にコンテナ毎の上限を設定 - ディスク I/O cgroup で制御しきれず野放し direct I/O は制御可能だが buffered I/O は ( 現状 ) 制御不能 - ネットワーク I/O tc などで制御可能だが 野放し 15
運用の悩み コンテナのリソース制御 - メモリ使用量 cgroup で物理メモリの上限を設定している swap はホストが持つ領域を共有するので管理が難しい How is SWAP handled by LXC? Proxmox Support Forum https://forum.proxmox.com/threads/how-is-swap-handled-by-lxc.26756/ memory.swappiness = 0 にしておけば swap 領域が空いている場合でも swap out せずにその cgroup の中で OOM が発生してプロセスが kill される lxc の設定なら以下のようにする lxc.cgroup.memory.swappiness = 0 16
運用の悩み コンテナのリソース監視 - CPU 使用量 cgroup で CPU 時間を取得できるが CPU 時間ベースの見方に慣れていない 自作ツールで従来通り load average を見られるようにした netlink 経由で cgroup 毎の running, uninterruptible なプロセス数を知ることができる ( 詳細はカーネルソースの Documentation/accounting/ 以下を参照 ) ので 定期的に調べて calc_load() と同じ方法で計算し結果を /proc/uptime, /proc/loadavg として見せる netlink で通信するプロセスはホストと同じ netns にいる必要がある 17
自作ツールの動作イメージ コンテナの Namespace ホストの Namespace uts net net process pid ipc ipc uts mnt /proc/uptime /proc/loadavg /proc/meminfo /proc/diskstats pid uts net mnt process pid ipc mnt /proc/uptime /proc/loadavg /proc/meminfo /proc/diskstats 18
運用の悩み コンテナのリソース監視 - ディスク使用量 従来通り df コマンドや snmp で監視可能 (XFS project quota の機能によるもの ) - ディスク I/O 自作ツールで LXCFS と同じように cgroup の情報 blkio.throttle.io_serviced blkio.throttle.io_service_bytes を /proc/diskstats として見せて従来のツールに対応 正常に測定されないケースもあるようですコンテナに LVM を使わせていれば普通に正しい値が取得できそう - ネットワーク I/O 従来通り ip コマンドや snmp で監視可能 19
運用の悩み コンテナのリソース監視 - メモリ使用量 自作ツールで LXCFS と同じように cgroup の情報 memory.usage_in_bytes memory.limit_in_bytes memory.memsw.usage_in_bytes memory.memsw.limit_in_bytes memory.stat を /proc/meminfo として見せて従来のツールに対応 とは言え sysinfo(2) を使うようなツールには未対応 Memory inside Linux containers Fabio Kung https://fabiokung.com/2014/03/13/memory-inside-linux-containers/ 20
トラブル事例 ある日 systemctl start 実行時にエラーが出るようになる # systemctl start nslcd Error: Too many open files Job for nslcd.service failed because a configured resource limit was exceeded. See "systemctl status nslcd.service" and "journalctl -xe" for details. # systemctl is-failed nslcd failed Too many open files と出るがプロセスが起動する場合もある (active と表示され プロセスが存在する ) 21
トラブル事例 # strace -fy systemctl start nslcd 2>&1 grep EMFILE [pid 672] inotify_init1(in_cloexec) = -1 EMFILE (Too many open files) Error: Too many open files inotify_init1(2) EMFILE The user limit on the total number of inotify instances has been reached. # sysctl -a grep inotify fs.inotify.max_queued_events = 16384 fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.inotify.max* の値を増やして解決 systemd が inotify を使うので systemd を大量に起動する LXC 環境だと発生しやすい 22
参考 Linux コンテナと LXC 入門 - https://speakerdeck.com/tenforward/1st-kistudy 23