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 システム構成 各コンテナに PostgreSQL, Pacemaker, Corosync コンテナ (LXC 1.1.2) コンテナ (LXC 1.1.2) 同期レプリケーション PostgreSQL PostgreSQL Pacemaker Pacemaker クラスタ通信 Corosync init (systemd) Corosync x 40 containers ホストOS (CentOS 7.1.1503) 物理ホスト SSD init (systemd) ホストOS (CentOS 7.1.1503) インターコネクト HDD 物理ホスト SSD HDD サービス用 10 コンテナのネットワーク (全体イメージ) 1号機系 (通常時 Master) コンテナ 2号機系 (通常時 Standby) VIP コンテナ インターコネクト VIP コンテナ VIP コンテナ VIP コンテナ VIP コンテナ VIP サービス用 11 コンテナのネットワーク (詳細) Master になるコンテナは VIP を作る (仮想MACアドレスを使うために IPaddr2 を改造した Resource Agent の VIP) コンテナの Namespace vmac0 (macvlan) VIP IPaddr2 の VIP VIP eth0 (macvlan) eth1 (802.1q) bond0.10 (802.1q tagging) bond1 (bonding) bond0 (bonding) ホストの Namespace em1 (phys) em2 (phys) em3 (phys) サービス用 em4 (phys) p2p1 p2p2 (phys) (phys) インターコネクト テンプレートは bridge + veth になっているので、そちらが一般的？ 12 macvlan 同じセグメントでも通信不可 (セキュリティ的に望ましい) Container Container Container eth0 (macvlan) eth0 (macvlan) eth0 (macvlan) IP 別セグメントの場合は 外部 のL3 機器経由なら通信可能 IP IP Host IP Router Router bridge mode … 同一ホスト上のコンテナ間の直接通信が可能 private mode … 同一ホスト上のコンテナ間の直接通信は不可能 など複数の動作モード 13 仮想 MAC アドレス VIP VIP VIP ほぼ同時に 大量の GARP 某社 L2 スイッチ FDB 更新 OK 某社 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 net process ipc uts net pid ipc mnt uts pid mnt process /proc/uptime /proc/loadavg /proc/meminfo /proc/diskstats uts net 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
© Copyright 2024 Paperzz
