プレゼンテーション

(1)

www.opensolaris.org

Solaris Container

（

_Zone

）を使った

インターネットサーバシステム構築（初級∼中級編）

ジャストプレイヤー株式会社

代表取締役社長瀧康史

(2)

(3)

www.justplayer.co.jp www.justplayer.ne.jp 3

-WEB

システムを作ってみよう（物理）

Storage Array Controller Controller Storage Server HBA Switch Switch SAS接続 SAS接続 Storage Server iSCSI target Storage Server iSCSI target

Server Server Server

Stack L.A. L.A. L.A. HeartBeat L.A. L.A. HBA Storage Server

Switch Stack Switch

L.A. L.A. L.A. Stack Router w FW Router w FW この上は略

物理的な配線

1. Internet

2. Router with FireWall

3. Switch

4. Service Server

5. SAN Switch

6. Storage Server (TARGET)

7. Storage Array

物理図はこんなかんじですが、今回は

L4

より下

の冗長は考えない。

(4)

www.justplayer.co.jp www.justplayer.ne.jp 4 -www.opensolaris.org

WEB

システムを作ってみよう（論理）

WAF WAF DBMS DBMS WEB Server

WEB Server Application Server Application Server DNS / Contents Server MTA

Forward Proxy DNS/Resolver

Load Balancer

w FireWall Load Balancerw FireWall

Internet DNS / Contents Server

下記の役割は別途必要

.

ステージングサーバ

.

監視サーバ

.

バックアップシステム

.

ルータ

他にも色々あるかもしれません。

個別の

IPFW

、ファイルサーバ、

FTP

サーバ等々・

・

(5)

-どのようにして、インターネットサービスのシステムを作るのか？

.

案件の規模

.

サービスの相手、市場の大きさ（想定ユーザ数）

.

かけられるお金

.

予算は？既存リソースの再利用？別途購入？

.

期間

.

今すぐ欲しい？

いつまでに欲しい？

.

このサービスは恒久？それとも期間限定？

.

セキュリティは？

.

理性的に考えれば不思議だが、現実的にはコスト次第。

インフラ系エンジニアは様々な状態にあわせてシステム構築をかえないとなりま

せん。理想と現実をつなぐ役割であるため、色々板挟みです。

そこで・

・

どう作るのか？

(6)

(7)

-サーバ仮想化とは？

「ハードウェア資源と、サーバを分離する」

1 台の物理サーバの上に複数の仮想サーバを動かせるベネフィットより、

複数台の物理サーバの上に、たくさん仮想サーバを動かせる利便性。

仮想化層

(8)

仮想化のファイナンシャル・メリット

.

ハードウェア資源「＝物理サーバ機器群」と、サービスが

密着しない

.

投資サイクルとサービスのライフサイクルを分離できる

.

ほとんどのサービスは、はじめるまでどの規模のハードウェア資源が必要かわからない

.

時期によって繁盛記が異なるサービスがある

具体的には？

.

ハードウェア資源は足りなくなったときに買えばよい

.

リースバック時のサーバリプレースがスムーズである

.

サービスの開始時に、ハードウェアの納期に縛られずにすむ（予算化がいらない

ことも・

・

・）

.

サービスの縮退が、ファイナンシャルのサイクルに縛られずにすむ

(9)

-どんなものがあるのだろう？

.

WEB

サーバ

.

アプリケーション

.

メールサーバ

.

データベースサーバ

.

ファイルサーバ

.

ストレージサーバ

.

ネームサーバ

.

DHCP

サーバ

.

NAT

.

ロードバランサー、ルータ、等々・

・

・もうかけない・

・

サーバとはなにか？≠サーバ機

(10)

サーバを実現する為の技術空間

実現するユニット、セットはなんだろう？

1. プロセスやユーザ単位

2. プロセスのグループ（

Solaris

では

Project

や

Task

）

3. ネットワーク

4. ファイルシステム。

OS

のユーザ・ランド。

5. OS

のカーネルのサービスモジュール。

6. ハードウェアと

OS

のドライバ群

サーバ（サービスのエンジン）とは、

あるサービスを実現するための単位

。

インフラ系のエンジニアは、

これらのサーバ群に最適なリソースを与え、制御し、シ

ステムを正常に稼働・運用させる

のが仕事。

(11)

-各種仮想化の隔離性・仮想化コスト

.

左上のものほど、リソースという側

面からみると、優れている。

.

赤いものは、別

OS

が動く

高低仮想化コスト大小 ● Xen Server （PVM） ● VMware ESX ● Xen Server （HVM） Solaris Container ● User / Process ● 隔離性 ● Linux KVM

● LXC● FreeBSD Jail● chroot

Illumos KVM ●

● Virtuozzo/OpenVZ

(12)

(13)

www.justplayer.co.jp www.justplayer.ne.jp

13

(14)

14

-www.opensolaris.org

(15)

15

(16)

一般的な

_Container

技術と、

(17)

-コンテナ型サーバ仮想化のメリット

ハイパバイザ型に比べて、次のようなメリットがあります。

.

リソースを使わない

.

カーネルは共通。プロセスが本当に利用するメモ

リ、

CPU

だけでよい。

.

パフォーマンスボトルネックがとても少ない

.

グローバルゾーンから見たら１つのプロセスに過

ぎない。

.

ブートが速い

.

カーネルが起動しない分、ブート、リブートがとても速い

資源共有率が高いので、

１つのサーバにたくさん収容できる

(18)

コンテナ型サーバ仮想化のデメリット

ハイパバイザ型に比べて、次のようなデメリットがあります。

.

コンテナごとの隔離性が低い

.

異なる

OS

の動作は不可能

.

比較的、互いの負荷影響を受けやすい

.

一部に動かないアプリケーションがある

.

ライブマイグレーションなどの機能がない

カーネルが共通で資源共有率が高いことによる裏返しです

(19)

-Solaris Containers

の特徴

Solaris Containers

は、次の特徴を持ちます。

.

OS

標準の機能

である

.

パッチなどによる提供ではないため、ノングローバルゾーン（仮想サーバ）とグローバ

ルゾーン（収容機）のアプリケーションレベルの互換性が高い

.

その他の仮想化機能（ネットワーク、ストレージ、パッケージシステム）との親和性

.

Solaris Resource Manager

によるリソース管理

が強い

.

1 つのコンテナの負荷の影響を、他のコンテナに波及させにくい。

.

cpu cap

、

memory cap

等。

.

マイグレーション（別のマシンへの移設）が可能

.

BrandZ

で

Linux

のユーザランドをバイナリ互換で実行可能（

illumos lx-zone

）

.

CentOS 3

、

4 等。

Linux

同様、

yum

でパッケージ管理が可能

(20)

コンテナ型の

OS

は、子の

OS

の

root

ファイルシステムが、ツリーの下に存在する。

/

├──

etc

├──

var

├──

usr

│

……

├──

zones

←

ここは、ものにより異なる。

│

├──

websv1

←

仮想サーバ名

│

└──

root

←

仮想サーバの

root

イメージ

│

├──

etc

│

├──

var

│

├──

usr

│

……

│

├──

websv2

│

└──

root

│

├──

etc

│

├──

var

│

├──

usr

│

……

ファイルの配置

.

仮想サーバ（

n o n g l o b a l

-zone

）のルートファイルシス

テムが、収容サーバ（

global-zone

）から見える。

.

non global zone

のファイル群

は、

global-zone

から自由に触

ることができる。

.

しかし

non global zone

同士で

は、互いに内容を見ることがで

きない。

(21)

21

-プロセスの抜粋。

0 sched

←

global zone 10 /lib/svc/bin/svc.startd 551 /usr/lib/saf/sac -t 300 556 /usr/lib/saf/ttymon

574 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p ope 12 /lib/svc/bin/svc.conﬁ gd

46 /sbin/dlmgmtd

191 /usr/lib/sysevent/syseventd

698 zoneadmd -z work-spec-oi151

←

non global zone 700 zoneadmd -z kikyo1

←

non global zone

900 zsched

←

non global zone

1151 /sbin/init

←

この下にぶら下がってるとわかりやすいが、実は違う。

931 zsched

←

non global zone

1179 /sbin/init

←

この下にぶら下がってるとわかりやすいが、実は違う。

1639 /usr/lib/memcached -u noaccess -u webservd -l 127.0.0.1 -p 11211 -m 128m

←

こ

れは、

non global zone

の中で動いてる。

このように、コンテナの中のプロセスは、親から見えているのが一般。

kill

や

renice

などもすることができる。

(22)

コンテナ内の

1 プロセス＝親

OS

内の

1 プロセス。メモリ空間は、親と共有している。

$ prstat -Z -s size

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 27672 sshd 346M 344M sleep 59 0 4:22:46 0.1% tiarra/1

9522 mysql 178M 164M sleep 59 0 345:51:20 0.3% mysqld/11 860 webservd 87M 45M sleep 59 0 0:00:15 0.0% httpd/1 27659 sshd 79M 68M sleep 59 0 4:10:09 0.2% mono/10 1153 webservd 70M 34M sleep 59 0 0:00:00 0.0% httpd/1 9672 root 63M 18M sleep 59 0 1:36:33 0.1% httpd/1

6116 root 60M 45M sleep 59 0 338:06:56 2.1% pkg.depotd/53 22267 webservd 59M 5528K sleep 59 0 0:00:10 0.0% httpd/1

ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE 52 50 694M 595M 7.3% 268:40:02 4.7% kohju.justplayer.com 62 53 406M 369M 4.5% 374:25:44 2.6% p2vi001.justplayer.ne.jp 61 32 174M 88M 1.1% 44:29:38 1.5% p2vi042.justplayer.ne.jp 0 50 100M 87M 1.1% 880:38:41 2.4% global 11 26 85M 71M 0.9% 48:32:30 0.3% dist.justplayer.com 44 21 130M 108M 1.3% 807:58:20 6.4% ospkg.justplayer.com 9 16 41M 37M 0.5% 329:52:08 2.0% pkg-dev.justplayer.com 33 16 40M 35M 0.4% 362:00:42 1.9% pkg-release.justplayer.com Total: 311 processes, 1401 lwps, load averages: 2.49, 3.02, 2.57

仮想マシンごとに、個別にメモリを確保していないのでメモリの再利用性が高い

(23)

23

-Zone

設置場所を決める。

pfexec zfs create -o mountpoint=/zones rpool/zones

Zone

の作成

pfexec zonecfg -z testzone

プロンプトがでるので、

zone

の作成

set zonepath=/zones/test.justplayer. com set brand=ipkg set autoboot=false set ip-type=shared add net set address=10.100.2.12/29 set physical=bge1 end add rctl set name=zone.cpu-cap

add value (priv=privileged,limit=150,a ction=deny)

end

add rctl

Container

の作り方例

set name=zone.max-swap

add value (priv=privileged,limit=53687 0912,action=deny) end add capped-memory set physical=256M end

このようにすると、

Z F S

のデータセッ

ト、

rpool/zones/test.justplayer.

com

に、

Zone

が作成されます。

(24)

利用に適したもの、適さないもの

適したもの

.

WEB

サーバ

.

アプリケーションサーバ（

PHP

、

Java

Servlet

）

.

メールサーバ

.

DNS

.

DBMS

（

MySQL

、

PostgreSQL

程度

の規模）

.

これらのテスト、本番機、一次サー

バ。等々・

・

アプリケーションによる冗長化が可能

（再起動ができるシステム）

ノンストップで運用する必要があるもの

（

Live Migration

が必要なシステム）

適さないもの

.

別

OS

の収容が必須なもの。

.

Windows

サーバ依存

.

IIS

依存

.

Linux

サーバ依存

(25)

Solaris Container

を

支援する技術

(26)

.

ZFS

による管理

.

ZFS

はツリー構造でデータセット（ファイルシステム）を管理している。

.

仮想サーバ毎に、

ZFS

を委譲して、利用することが可能。

.

仮想サーバ毎の、利用量の

CAP

の制御ができる。

.

スナップショット、ロールバック、クローンな

どの高価なストレージアプライアンスと同等

以上の機能を持つ。

.

スナップショット毎に、バックアップを簡単に

取ることができる。

.

仮想サーバ毎のストレージのアクセス頻度管

理は難しい（わかるけど制御が難しい）

ZFS / Storage

の仮想化と管理

ディスク0 修正後仮想ディスク2 ディスク1 修正後仮想ディスク0 仮想ディスク2 仮想ディスク1 Set1 Set0 OpenSolaris Apache、php5.3 インストール済み OpenSolaris Apache、MySQL インストール済み zfs clone iS CSI target インストール済テンプレートセットインストール後

(27)

27

-.

SAN

を利用した管理

.

COMSTAR

（

iSCSI

などの

TARGET

機能）。

ZFS

と連携して、高価な

DAS

並の機能をが標

準で利用することができる。

.

SAN

を利用し、収容サーバをディスクレスにすることで、さらに仮想化の隔離性が増

す。

.

フェイルセーフのための多重化も簡単にできる

(28)

.

Crossbow

（仮想ネットワークプロジェクト）による管理

.

仮想サーバ毎に、仮想

NIC

を作成して委譲。

.

仮想

NIC

の帯域制御。

.

spoofing

プロテクト。

.

CPU

負荷の制御。

.

IP

の固定制御。

.

仮想

Switch

（

Etherstub

）の作成

.

仮想

Bridge

の作成。

.

VLAN

、フィルタ、ルーティング等

.

仮想サーバへの

MAC

アドレスの貼り付け。

.

帯域の測定、監視など。

Network

の仮想化と管理

(29)

29

-物理

_Network

と論理

_Network

Viriual

Server 6 Server 7Viriual Viriual

Server 0 Server 1Viriual Server 3Viriual

Viriual Server 5 vlan2 vlan1 Viriual Server 4 Viriual Server 2 R Interne t vlan0

物理サーバセット

仮想サーバセット

ControlNetwork・・・・・・マネジメントサーバからの制御に使われるネットワーク

Storage Area Network・・・・・iSCSI用SAN DMZ /Backnet・・・・・・サービス用ネットワーク Host Server 2 Host Server 1 Host Server 0 Management Server R Interne t Storage Server 1 WEB UI CLI等 Storage Server 0

Storage Area Network Backnet (tagVLAN)

DMZ

(30)

(31)

-どの層で隔離・仮想化するのか？

どういう仮想化が必要なのかは、自分が必要な「サーバ」がどういう単位（隔離レベ

ル）のものなのか？を考えることで決まります。

たとえば・

・

1. プロセス、プロセスのグループ

2. OS

のユーザ・ランドから上

3. OS

のカーネルのサービスモジュール

4. ハードウェアと

OS

のドライバ群

■

プラットフォーム依存

■

プロセス・ユーザ・プロジェクト・タスク

■

プロセス・ユーザ・プロジェクト・タスク

■

コンテナ型仮想化

■

ハイパバイザ仮想化

(32)

仮想化を選ぶポイント

.

サーバのポータビリティや、スケーラビリティの考慮したい。

.

仮想化には隔離性が必要。

.

上に行くほど隔離性が少ない代わりに、仮想化コストが下がる。

.

下に行くほど仮想化コストがかかり、リソースの再利用効率が悪くなる。

仮想化を使うには、仮想化層から上のインスタンスの隔離性を担保し、ポータビリ

ティをあげる技術とも言える。

(33)

-.

ホストサーバ上で動作するコンテナ（ノングローバルゾーン）

.

最低

256MB

程度のメモリで動作。

.

AMP

環境を用意する場合は

512MB

以上推奨

.

サービスネットに足をおろし、様々なサービスを動作させる

.

仮想サーバのネットワークは

VLAN

、

VNIC

、

VHUB

（

Crossbow

）機能などで仮想

化されている

.

仮想サーバと物理サーバ群に

IP

的な接点を置かないとよりセキュア

.

仮想サーバのためのネットワーク（サービスネットワーク）とコントロールネットワー

ク、ストレージエリアネットワークは隔離されている

.

Global Zone

側から仮想サーバへのメッセージは

zlogin

経由でしか行われない

.

収容されている物理サーバからの引っ越しも考慮する

.

仮想サーバは、実質メモリが許す限り、作成することが可能

(34)

再びここをみて考察する

WAF WAF DBMS DBMS WEB Server

WEB Server Application Server Application Server DNS / Contents Server MTA

Forward Proxy DNS/Resolver

Load Balancer

w FireWall Load Balancerw FireWall

Internet

(35)

-.

複数構成にしているため、

2 つのマシンがいり

ます。

.

その

2 つをつなぐため、

Private

Net

を、

Network

上に置く必要があります。

これを乗せられる最小環境

Server 1 Server 2 Internet Private Net ControlNet

(36)

メモリキャップのコツ

.

必要のメモリの

2 倍程度を

cap

にし、

90%

ルールなどを敷いて管理した方がい

い。

.

256MB

の契約ですが、

512MB

までは最大利用することが可能・・・など。

.

理由は、ページスキャナーの構造による

lxzone

の互換性

.

所詮、特定のバイナリを動かすためのものと考えた方が良い。

.

LL

ぐらいの動作は概ね可能だが、深いものは動かない。

OS

の壁

.

クラウド化（

XaaS

化）が進むほど、関係なくなってくると考えられるが、現段階で

は、

OS

の壁を越えられない人は、思ってる以上に多い。

コンテナの実運用での

_Tips

(37)

-仮想サーバの移転（マイグレーション）

.

移転元サーバ

.

仮想サーバの停止

(zone halt)

.

仮想サーバの切り離し

_{(zone detach)}

.

ストレージの解放

(zpool export)

.

ストレージの切断

(iscsi detach)

アプリケーション層 OS層ホストサーバ群ハードウェア層 App サーバ WEB サーバサーバWEB O S：CentOS CPU：1.0個分 MEM：256M DISC：5G O S：OpenSolaris CPU：2個分 MEM：1G DISC：60G O S：OpenSolaris CPU：1.5個分 MEM：256M DISC：5G DBMS サーバWEB ミドルウェアサーバ O S：OpenSolaris CPU：1.5個分 MEM：256M DISC：5G O S：OpenSolaris CPU：2個分 MEM：512M DISC：20G O S：CentOS CPU：0.7個分 MEM：512M DISC：20G 仮想サーバの移転が可能

プレゼンテーション

www.opensolaris.org

Solaris Container

（

Zone

）を使った

インターネットサーバシステム構築（初級∼中級編）

ジャストプレイヤー株式会社

代表取締役社長 瀧 康史

-WEB

システムを作ってみよう（物理）

物理的な配線

1.

Internet

2.

Router with FireWall

3.

Switch

4.

Service Server

5.

SAN Switch

6.

Storage Server (TARGET)

7.

Storage Array

物理図はこんなかんじですが、今回は

L4

より下

の冗長は考えない。

WEB

システムを作ってみよう（論理）

下記の役割は別途必要

.

ステージングサーバ

.

監視サーバ

.

バックアップシステム

.

ルータ

他にも色々あるかもしれません。

個別の

IPFW

、ファイルサーバ、

FTP

サーバ等々・

・

・

・

・

・

-どのようにして、インターネットサービスのシステムを作るのか？

.

案件の規模

.

サービスの相手、市場の大きさ（想定ユーザ数）

.

かけられるお金

.

予算は？既存リソースの再利用？別途購入？

.

期間

.

今すぐ欲しい？

いつまでに欲しい？

.

このサービスは恒久？それとも期間限定？

.

セキュリティは？

.

理性的に考えれば不思議だが、現実的にはコスト次第。

インフラ系エンジニアは様々な状態にあわせてシステム構築をかえないとなりま

せん。理想と現実をつなぐ役割であるため、色々板挟みです。

そこで・

・

・

どう作るのか？

-サーバ仮想化とは？

「ハードウェア資源と、サーバを分離する」

_Zone

代表取締役社長瀧康史