スライド 1

(1)

1

LXC の本番利用事例

株式会社インターネットレボリューションインフラ課桑澤拓也

(2)

2

自己紹介

株式会社インターネットレボリューション

・成り立ち：コナミデジタルエンタテインメントと

IIJ

の合弁会社・事業内容：デジタルエンタテインメント事業のシステム業務インターネットサービスの開発・運営

発表者

・アミューズメント施設向けサービスのインフラ担当者 (e-AMUSEMENT サービス/システム) ・設計～構築～運用までひと通り

(3)

3

e-AMUSEMENT システム

・クライアントの数 ≒ ゲームきょう体の数

- 家庭用ゲーム機やスマートフォンアプリ等と比べて数が少ない - リクエストが爆発的に増えることは無いので、スケーラビリティはそれほど求められない

・1プレーごとにお金がかかっている

- 可用性は重要

(4)

4

LXCとは？

LXC はよく強力な chroot と本格的な仮想マシンの中間の

ようなものに見なされます。 LXC の目的は、可能な限り

標準的な Linux のインストール環境に近く、しかし別々の

カーネルは必要ないような環境を作ることです。

Linux Containers - LXC - イントロダクション https://linuxcontainers.org/ja/lxc/

・主にシステムコンテナを作るために使用する

アプリコンテナを作ることも可能

・類似のもの

Virtuozzo (OpenVZ) systemd-nspawn

(5)

5

LXC のここが好き

・小さいオーバーヘッド

- VM ほどの隔離性は無いが、VM よりも軽量

・システムコンテナ

- VM に近い感覚で利用できる

・豊富なテンプレートイメージ

- すぐに使い始められる - 検証時のバージョンの CentOS テンプレートは若干問題があったが …

(6)

6

LXC のここが好き

・一斉コマンド実行 / ファイル操作が可能

- ホストOS からコンテナ内でコマンド実行 (lxc-attach) - ホストOS からコンテナ用のファイル操作 (ホストディレクトリの一部を rootfs として利用している場合) # for c in $(lxc-ls --active); do

lxc-attach -n $c -- systemctl reload sshd done

(7)

7

LXC のここが好き

・コンテナフック

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

(8)

8

他の Linux コンテナ実装について

・OpenVZ (Virtuozzo)

- 検証時はまだ RHEL 6 ベース - kernel 自体にかなり手を入れているのが気になった - 現在ではソースコードも公開されている

・systemd-nspawn

検証時 (CentOS 7.0.1406) は … - 特にネットワーク周りの機能が不足していた - 今なら選択できるかもしれない

・Docker

- できなくはないが、システムコンテナ向けではない - stateless, immutable な環境向き

(9)

9

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年程度

(10)

10

システム構成

サービス用インターコネクト 物理ホスト コンテナ (LXC 1.1.2) コンテナ (LXC 1.1.2) 物理ホスト

ホストOS (CentOS 7.1.1503) ホストOS (CentOS 7.1.1503)

各コンテナに PostgreSQL, Pacemaker, Corosync

init (systemd) init (systemd) Corosync Corosync Pacemaker Pacemaker PostgreSQL PostgreSQL x 40 containers 同期レプリケーションクラスタ通信 SSD HDD SSD HDD

(11)

11

コンテナのネットワーク (全体イメージ)

コンテナ 1号機系 (通常時 Master) 2号機系 (通常時 Standby) VIP コンテナコンテナコンテナコンテナ VIP コンテナ VIP VIP VIP VIP サービス用インターコネクト

(12)

12

コンテナのネットワーク (詳細)

em1 (phys) bond0 (bonding) em3

(phys) (phys) em4

em2 (phys) bond0.10 (802.1q tagging) eth0 (macvlan) vmac0 (macvlan) コンテナの Namespace ホストの Namespace p2p1 (phys) p2p2 (phys) bond1 (bonding) eth1 (802.1q) サービス用インターコネクト Master になるコンテナは VIP を作る

(仮想MACアドレスを使うために IPaddr2 を改造した Resource Agent の VIP)

テンプレートは bridge + veth になっているので、そちらが一般的？

IPaddr2 の VIP

VIP

(13)

13

macvlan

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

(14)

14

仮想 MAC アドレス

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

某社 L3 スイッチ某社 L2 スイッチ

VIP VIP VIP

FDB 更新 OK

ARP cache 更新一部 NG ???

ほぼ同時に 大量の GARP

(15)

15

運用の悩み

・コンテナのリソース制御

- CPU cgroup で制御可能だが、適切な設定を定められず野放し - ディスク使用量 XFS project quota で疑似的にコンテナ毎の上限を設定 - ディスク I/O cgroup で制御しきれず野放し

direct I/O は制御可能だが、buffered I/O は (現状) 制御不能 - ネットワーク I/O

(16)

16

運用の悩み

・コンテナのリソース制御

- メモリ使用量 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 の設定なら以下のようにする

(17)

17

運用の悩み

・コンテナのリソース監視

- CPU 使用量 cgroup で CPU 時間を取得できるが、 CPU 時間ベースの見方に慣れていない → 自作ツールで従来通り load average を見られるようにした netlink 経由で cgroup 毎の running, uninterruptible な

プロセス数を知ることができる

(詳細はカーネルソースの Documentation/accounting/ 以下を参照) ので、定期的に調べて calc_load() と同じ方法で計算し結果を

/proc/uptime, /proc/loadavg として見せる

(18)

18

自作ツールの動作イメージ

コンテナの Namespace ホストの Namespace process net process ipc uts pid mnt uts pid mnt net ipc uts pid mnt net ipc /proc/uptime /proc/loadavg /proc/meminfo /proc/diskstats /proc/uptime /proc/loadavg /proc/meminfo /proc/diskstats

(19)

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 で監視可能

(20)

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

(21)

21

トラブル事例

・ある日 systemctl start 実行時にエラーが出るようになる

Too many open files と出るがプロセスが起動する場合もある (active と表示され、プロセスが存在する)

# 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

(22)

22

トラブル事例

・inotify_init1(2)

EMFILE The user limit on the total number of inotify instances has been reached.

fs.inotify.max* の値を増やして解決

systemd が inotify を使うので、systemd を大量に起動する LXC 環境だと発生しやすい

# sysctl -a | grep inotify

fs.inotify.max_queued_events = 16384

fs.inotify.max_user_instances = 128

fs.inotify.max_user_watches = 8192

# 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

(23)

23

LinuxコンテナとLXC入門

- https://speakerdeck.com/tenforward/1st-kistudy