スライド 1

Size: px

Start display at page:

Download "スライド 1"

ひろとかみこ
5 years ago
Views:

1 LXC の本番利用事例株式会社インターネットレボリューションインフラ課桑澤拓也 1

2 自己紹介株式会社インターネットレボリューション成り立ち : コナミデジタルエンタテインメントと IIJ の合弁会社事業内容 : デジタルエンタテインメント事業のシステム業務インターネットサービスの開発運営発表者アミューズメント施設向けサービスのインフラ担当者 (e-amusement サービス / システム ) 設計 ~ 構築 ~ 運用までひと通り 2

3 e-amusement システムクライアントの数ゲームきょう体の数 - 家庭用ゲーム機やスマートフォンアプリ等と比べて数が少ない - リクエストが爆発的に増えることは無いのでスケーラビリティはそれほど求められない 1 プレーごとにお金がかかっている - 可用性は重要 3

4 LXC とは? LXC はよく強力な chroot と本格的な仮想マシンの中間のようなものに見なされます LXC の目的は可能な限り標準的な Linux のインストール環境に近くしかし別々のカーネルは必要ないような環境を作ることです Linux Containers - LXC - イントロダクション主にシステムコンテナを作るために使用するアプリコンテナを作ることも可能類似のもの Virtuozzo (OpenVZ) systemd-nspawn 4

5 LXC のここが好き小さいオーバーヘッド - VM ほどの隔離性は無いが VM よりも軽量システムコンテナ - VM に近い感覚で利用できる豊富なテンプレートイメージ - すぐに使い始められる - 検証時のバージョンの CentOS テンプレートは若干問題があったが 5

6 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

7 LXC のここが好きコンテナフック - コンテナを起動停止クローンする際にスクリプトを実行できる - フックタイプによって様々な実行タイミングを選択可能 lxc.hook.pre-start lxc.hook.clone lxc.network.script.up lxc.hook.start 詳細は lxc.container.conf(5) を参照 7

8 他の Linux コンテナ実装について OpenVZ (Virtuozzo) - 検証時はまだ RHEL 6 ベース - kernel 自体にかなり手を入れているのが気になった - 現在ではソースコードも公開されている systemd-nspawn 検証時 (CentOS ) は - 特にネットワーク周りの機能が不足していた - 今なら選択できるかもしれない Docker - できなくはないがシステムコンテナ向けではない - stateless, immutable な環境向き 8

9 LXC 利用システムホスト OS - CentOS , 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

10 システム構成コンテナ (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 ) ホスト OS (CentOS ) 物理ホストインターコネクト物理ホスト SSD HDD SSD HDD サービス用 10

11 コンテナのネットワーク ( 全体イメージ ) 1 号機系 ( 通常時 Master) 2 号機系 ( 通常時 Standby) コンテナ VIP コンテナ VIP インターコネクトコンテナ VIP VIP コンテナコンテナ VIP VIP コンテナサービス用 11

12 コンテナのネットワーク ( 詳細 ) 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

13 macvlan Container Container Container 同じセグメントでも通信不可 ( セキュリティ的に望ましい ) eth0 (macvlan) eth0 (macvlan) eth0 (macvlan) IP IP IP 別セグメントの場合は外部の L3 機器経由なら通信可能 IP Host Router Router bridge mode 同一ホスト上のコンテナ間の直接通信が可能 private mode 同一ホスト上のコンテナ間の直接通信は不可能など複数の動作モード 13

14 仮想 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

15 運用の悩みコンテナのリソース制御 - CPU cgroup で制御可能だが適切な設定を定められず野放し - ディスク使用量 XFS project quota で疑似的にコンテナ毎の上限を設定 - ディスク I/O cgroup で制御しきれず野放し direct I/O は制御可能だが buffered I/O は ( 現状 ) 制御不能 - ネットワーク I/O tc などで制御可能だが野放し 15

16 運用の悩みコンテナのリソース制御 - メモリ使用量 cgroup で物理メモリの上限を設定している swap はホストが持つ領域を共有するので管理が難しい How is SWAP handled by LXC? Proxmox Support Forum memory.swappiness = 0 にしておけば swap 領域が空いている場合でも swap out せずにその cgroup の中で OOM が発生してプロセスが kill される lxc の設定なら以下のようにする lxc.cgroup.memory.swappiness = 0 16

17 運用の悩みコンテナのリソース監視 - CPU 使用量 cgroup で CPU 時間を取得できるが CPU 時間ベースの見方に慣れていない自作ツールで従来通り load average を見られるようにした netlink 経由で cgroup 毎の running, uninterruptible なプロセス数を知ることができる ( 詳細はカーネルソースの Documentation/accounting/ 以下を参照 ) ので定期的に調べて calc_load() と同じ方法で計算し結果を /proc/uptime, /proc/loadavg として見せる netlink で通信するプロセスはホストと同じ netns にいる必要がある 17

18 自作ツールの動作イメージコンテナの 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

19 運用の悩みコンテナのリソース監視 - ディスク使用量従来通り 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

20 運用の悩みコンテナのリソース監視 - メモリ使用量自作ツールで 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 20

21 トラブル事例ある日 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

22 トラブル事例 # 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 = fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.inotify.max* の値を増やして解決 systemd が inotify を使うので systemd を大量に起動する LXC 環境だと発生しやすい 22

23 参考 Linux コンテナと LXC 入門

Evalution of Linux Container(LXC) on Embedded Linux 株式会社富士通コンピュータテクノロジーズ町田裕樹 1201ka01 Copyright 2013 FUJITSU COMPUTER TECHLONOGIES LIMITED

Evalution of Linux Container(LXC) on Embedded Linux 2013.3.8 株式会社富士通コンピュータテクノロジーズ町田裕樹 1201ka01 目次 Linux Container(LXC) の概要 Linux Container(LXC) コンテナ型仮想化ユーザランド LXC を評価評価環境準備アプリケーションコンテナシステムコンテナ 1 Linux