Date: 2010
Author: Matsuo Sawahashi
Type: IBM Professional Paper
Prize: Winner
---------------
---------------
IBM Power Systemsにおけるマルチテナント型仮想化ホスティングサービスの設計技法
山口 星志＊ 青山 真巳＊＊ 沢橋
松王＊＊＊
Design method of multi tenant virtualized hosting
service using IBM Power Systems
Seiji Yamaguchi＊, Manami Aoyama＊＊ and Matsuo Sawahashi＊＊＊
この論文はIBM Power Systemsを使用して複数のお客様に仮想区画を提供するマルチテナント型ホスティングサービスを提供する場合に必要となるシステム設計技法をまとめたものである．シェアードサービスのためのセキュリティ，LPARのサイジング技法などのテクニックだけでなく，安全で安価な保守を意識した構成設計など運用面にも配慮した設計技法を提供する．本設計技法を用いるとクラウド・コンピューティング・サービス事業者はAIXのOSイメージを提供するPaaSもしくはIaaS型のサービスを展開することが可能となる．またアウトソーシング事業者も同様に複数のお客様向けにシェアード型のIT資源提供サービスを展開することが可能となる．
This paper presents IBM
Power Systems design method which will be required for a multi tenant
virtualized hosting service which provides virtual machines to multiple
customers． The design method provides not only security for shared service and
sizing technique but also design technique which cares operational aspect such
as safety configuration to be aware of stable and low cost maintenance． To apply
this design method, the cloud computing service provider can develop PaaS or
IaaS service using AIX OS image．
Out sourcing service provider can also deploy shared IT
resource for multiple customers．
Key Words & Phrases 仮想化，マルチテナント，システム設計，クラウド，サイジング
virtualization,
multi tenant, system design, cloud computing, sizing
１．はじめに
近年，仮想化技術の躍進により，クラウドサービスに対するお客様の興味は年々高まっている．経済産業省が先日発表した報告書では2020年までに累計40兆円超のクラウドサービス市場が世界で創出されるとの予測をしている[1]．国内でも現在300億円の売上があるクラウドサービスは5年後には1,400億円以上の市場規模になると予想される[2]．クラウドサービスの中でも特に，PaaS (Platform as a Service)もしくはIaaS (Infrastructure as a Service)への注目が集まっている[3]．
しかしながら，この領域へのIBM Power systemsを使ったサービスは世界でもあまり事例がない．これに対してIBMはSO向けのIaaSとしてMCCS (Managed Cloud Computing Services) を発表した[4]．本論文ではMCCSでの設計の経験からIBM Power
systems上でマルチテナント型のシェアードサービスを提供する設計手法についてまとめた．同様のサービスを設計，展開する際の参考とされたい．
２．マルチテナント型サービスの課題
共用環境において，個別のお客様向けの設計とは異なり，それぞれのお客様が利用するシステム間(LPAR間)のセキュリティやパフォーマンスの考慮だけなく，多様なお客さまへの要件を満たす柔軟性や可用性を考慮した設計とする必要がある．以下にそれぞれの課題についての詳細を述べる．
2.1共用環境における可用性
共用環境において，サービスを提供している全てのお客さまへ同一の停止時間を調整するということは現実的ではない．特に予防保守などの際にサービス停止が発生することのない可用性が必要である．また筐体障害時の影響を最小化する必要がある．
2.2 LPAR間の分離性
シェアードサービスにおける仮想化設計では，セキュリティ上の観点から，完全にLPAR間の分離性を保つことが必須である．ネットワークとしてはLPAR間での通信を完全に遮断し，ディスクアクセスについても，各お客様環境を分離できる構成とすることが必要である．
2.3 リソース競合の問題
限りあるCPUリソースを有効にかつ他の区画の影響を受けないようにするためには工夫が必要である．キャパシティーを保証するだけではなく，ピークや低稼動率の場合に他の区画とのリソースの融通を図る必要がある．
限られたネットワーク帯域についても最大限のパフォーマンスを出せるだけでなく，他区画への影響が少ない構成を取る必要がある．
2.4 多様なお客様要件を満たす柔軟性
共用インフラサービスとして提供するためには，多様なお客様環境の要件を満たすことが可能なサービスとして提供できる必要がある．
システム設計時に想定したお客様環境だけではなく，様々なピーク特性を持ち，エンドユーザーへのサービス内容もまったく異なるお客様環境に対してもサービス提供ができる必要がある．
以上の考慮点を解決するための設計手法について，次章で詳しく述べる．
３．課題に対する解決策
3.1全体構成
共用環境の障害や保守時の影響を最小化するためにはコンポーネントの徹底した二重化が必要である．MCCSではサーバーやネットワークだけでなく，ストレージ筐体も二重化した．通常はストレージのコントローラーが二重化されているために問題ないとされるが，例えコントローラーが二重化されていていてもストレージ筐体全体の障害は頻繁に発生し，安全のために保守時もサービス停止の上実施することを求められるのが現実である．これを回避するためにSVC（SAN Volume Controller）を使ったストレージ筐体の二重化を推奨する．
3.2ディスク構成
各LPARの分離性を保ちつつ，パフォーマンスを考慮するため以下のようなストレージ設計が必要である．
SVCを利用した仮想ディスク環境によってLPAR間の分離性を保証する方法として，お客様ごとにMdisk groupをアサインする方法と，Vdiskをアサインする方法がある．どちらの方法でもIBMのセキュリティーポリシーであるITCS104の要件を満たしている．
Mdisk groupは個々のディスク筐体ごとのLUN
(Logical Unit Number)の集合体であり，Vdisk はMdisk groupから均一にエクステントを選択した仮想ディスクである[5]．
Mdisk groupを構成する場合，できるだけ大きいサイズで，かつ同じサイズのLUNを組み合わせるとアクセス効率が良く，パフォーマンスが高くなる．
多様なお客さま環境に対応する必要があるため設計時にLUNの数やサイズを見積もることは出来ない．そのため個々のお客様ごとにMdisk groupをアサインし分離する方法は，LUNを効率的に使うことができずパフォーマンスがあまり見込めない構成となる．
Vdiskごとにアクセスを分離する方法をとることにより，パフォーマンスがよく，さらには個々のお客様を受け入れる際の作業も少なくて済むという構成を推奨する
(図1)．
図1 Mdisk groupとVdisk設計の考慮点
また，Mdisk groupの構成は，筐体の能力および回転速度とサイズの同じ物理ディスク上に構成したLUNを組み合わせることでより，パフォーマンスのよい構成をとることが出来る．
シェアード環境では様々な種類のディスクアクセスが混在し事前に想定することはできない．高価で高速なディスクを用意できれば良いが安価なサービスを提供するためには妥協も必要である．そこで推奨するのは高速ディスクと低速ディスクを組み合わせることである．MCCSではDS8100とDS3400を組み合わせ，業務要件に応じて適切なディスクを提供できるようにしている．
3.3サーバー構成
(1)
VIOSのCPU設計
Power systemsの仮想環境を提供する，VIOS (Virtual I/O Server) はネットワークとストレージI/Oを集中管理するため，二重化は必須である．MCCSでは1筐体当り2VIOS構成とした．
VIOSへのCPU割り当ては，EMEAの実績値[6]から2coreとした．シェアードサービスとして提供する場合，様々な負荷ピークを持った複数のお客様が利用する可能性がある．そのため，初期設計での負荷見積りは困難であり，片方のVIOSに負荷が偏る可能性がある．2台のVIOSで利用するSPP(Shared Processor Pool)を構成し，Sharedでアサインすることにより，急なVIOS間での負荷の偏りにも対応できる設計を推奨する．
(2)
VIOCのCPU割り当て
VIOC(Virtual I/O Client)のCPU割り当てについては，文献[7]を参考に，想定されるお客様のCPU使用状況のデータを取得し，VIOC全体のCPU使用量のピークの能力値を確保できるように計算できる．
CPUリソースの競合を起こさないようにするために，VIOC上のSPPは同一プールかつSharedの割り当てとし，重みづけもすべてのLPARで同等とする．またDesiredパラメーターでCPUキャパシティーを保証しながら，Uncapped属性によってコアの上限までバーストを許すことができる．
VIOSで使用するSPPとは分けることにより，VIOSの負荷による影響を各VIOCに与えないようにする．
(3)
LPMによる可用性
共用環境におけるサーバー筐体保守時の可用性を確保するためLPM (Live Partition Mobility)機能[8]が有効である．２筐体以上同時に停止することはない前提とすれば，1筐体分のVIOC資源に相当するリソースを筐体プールの中に確保しておけばよい．1台に寄せておいてもよいし，全台で均等に確保しても良い．
(4)
VLANによるVIOSの振り分け
VIOCのネットワークにおける冗長性を確保する方法として，SEA(Shared Ethernet
Adapter) FailoverとSEA NIB(Network Interface Backup)という方法がある．前者は２つのVIOSで同じVLANに属するVE (Virtual Ethernet)から構成したSEAを構成し，優先度が高い方のVIOSを経由して筐体の外と通信する方法である．後者は２つのVIOSで異なるVLANに属するVEをVIOCに割り振り，NIBを構成するという方法である[9]．
それぞれの構成におけるメリット・デメリットの概要を(表1)にまとめた．
表1 SEA Failover – SEA NIB構成比較
|
|
利点
|
難点
|
|
SEA
Failover構成
|
VIOCで意識しない切り替え・切り戻しが可能
|
確保できるネットワーク帯域が半分となる
|
|
SEA
NIB構成
|
多くの帯域を使うことが可能
|
SEAへの振り分けは各LPARでの設定が必要
|
今回の設計では，冗長性・メンテナンス性を確保するためにVIOS ２台から構成されるSEA Failover構成を採用する．SEA Failover構成はActive-Standbyで冗長性を確保するため各LPARは優先度が高いVIOSを経由してのみ通信することになる．
そのため構成しているVIOS２台の内，優先度が高いVIOSに負荷が偏ってしまう可能性がある．そこでVIOSでの負荷の偏りを軽減するため，VLAN番号の偶数，奇数でそれA系，B系のSEAを構成し，Network I/Oによる負荷の調整・分散が出来る設計を推奨する(図2)．
図2 VIOS-VLAN分散構成
(5)
Etherchannelによる帯域確保
ネットワークのスループットを出すためにMCCSでは各VIOSにアサインしている６つのイーサネットポートの内，A・B系で３つずつのポートからEtherchannelを構成した．バックアップ用チャネルは構成せず，障害時には手動でSEA Failoverを実行することにより，帯域の減少時間を最小限に抑えた運用を可能とした．
(6)
最大VLAN数の事前設定
VIOSの仕様として，付与したVLANの追加・削除の際にはVIOSの再起動を伴うSEAの再構成が必要である．よって，サービス停止を発生することなく柔軟な要件を満たすために設定可能な最大数のVLANを用意した方が良い．MCCSでは最大数である19個のタグ付きVLANを各VEに付与し，16個のVEからSEAを構成した．即ち19×16=304個のVLANを事前に用意する設計とした．
(7)
VIOCにおけるディスクの可用性
ディスクの冗長性設計として， VIOCに仮想Fiberをアサインし直接ディスクを見せるNPIV (N Port ID
Virtualization)とVIOSでVIOCへ提供するディスクへのパスを冗長化する方法 (PV-PV MPIO)がある．前者はVIOC側でDisk I/Oをラウンドロビン設定することによりI/Oのスループットが上がる可能性がある．また，PV-PV MPIOに比べVIOS側の負荷が少ないため限られたリソースを有効に使うことが可能である．しかし，外部ストレージのマイクロコード更新などの際に，VIOCでのドライバの対応が必要になる可能性があり，共用環境としての柔軟性要件を満たしていないため，PV-PV MPIO方式を推奨する．それぞれの構成におけるメリット・デメリットを(表2)にまとめた．
表2 MPIO - NPIV比較
|
|
利点
|
難点
|
|
PV-PV
MPIO
|
サーバーに接続しているStorageの影響をVIOCは受けない
|
Active-standby構成になるためVIOCでは負荷分散しない
|
|
NPIV
|
VIOSへの負荷が低い
VIOCでの負荷分散が可能
|
外部Storageの影響がある
(VIOC-Storageドライバの依存性)
|
VIOCのMPIOではI/Oをラウンドロビンなどの負荷分散をすることは出来ず，active-standbyによる冗長構成となる．そこで，VIOCにおけるMPIOのパス優先度を設定しVIOSの負荷分散設計を行う必要がある．
４．設計検証と結果
各々の設計方法について検証を行い，問題なく設計通りの動きをしていたかを確認する必要がある．ここではMCCSの実際のテストケースに基づいて設計の妥当性を検証する．
4.1 CPU
CPUについて同じ筐体上の区画で負荷を与え，想定された保証レートやバースト属性を発揮できるか検証した．
検証区画のCPUリソースはshared，uncappedで設定し，同じSPPにアサインした．SPPには4コア分のCPUを割り当てた．それぞれのLPARに対して，CPUの重みも同じ値とした．与えるCPUリソースは以下(表3)の通りである．
表3 CPUリソースアサイン
(Desired値)
|
|
PU
|
VP
|
Memory
|
|
VIOC#1
|
0．10
|
1
|
1GB
|
|
VIOC#2
|
0．20
|
1
|
2GB
|
|
VIOC#3
|
0．49
|
1
|
5GB
|
以下(表4)に負荷パターンを記載し，(表5)にその結果のPU値を載せる．(表4)内の数値はPUに対する負荷の割合を示している．
表4 CPU負荷パターン
|
|
Pattern
2
|
Pattern
3
|
Pattern
4
|
|
VIOC#1
|
200%
|
500%
|
1000%
|
|
VIOC#2
|
100%
|
250%
|
500%
|
|
VIOC#3
|
100%
|
140%
|
200%
|
表5 負荷をかけた場合のPU値
|
|
Pattern
2
|
Pattern
3
|
Pattern
4
|
|
VIOC#1
|
0.20
|
0.50
|
1.00
|
|
VIOC#2
|
0.20
|
0.50
|
1.00
|
|
VIOC#3
|
0.49
|
0.69
|
0.98
|
同時に負荷をかけた場合でも，十分なリソースがある場合，それぞれのLPARにおいてCPUは負荷を満たすバースト値を示した．
次に，リソースが逼迫している時の動作を検証するために， 1 coreのSPPを定義し，uncappedで0.2 PUの区画を２つアサインした．初めに一方のLPARに対してのみ負荷をかけ，少し時間が経過した後，別のLPARにも負荷を与えてSPP内でどの様なCPUの取り合いをするかを検証した(図3)．
図3 同一SPP内のCPUリソース配分
(注) 図中の横軸は経過時間(秒)を示し，縦軸はPUを示す．各LPARの重みは同値である．
負荷をかけたLPAR Aは初めSPP内のリソースを全て使っていたが，LPAR Bに負荷がかかりLPAR Bへのリソース要求があると2つのLPARで分け合う動きをしていることが分かる．
つまり，あるLPARが高負荷状態でSPP内のリソースが不足している状況でも，他のLPARが稼働する際にはリソースを分け合う動きをする．また，リソースが使用していない状態では，高負荷なLPARに対してリソースが割り当てられリソースの有効活用がされる．
このようにCPUをアサインすることにより，共用サービスにおいて柔軟性と高パフォーマンス要件を満たすことができる．
4.2 ネットワーク
Etherchannelによるネットワーク帯域の検証とVLAN番号による割り振りの検証を行った．検証環境では，VIOSは2台構成としそれぞれA系，B系のVLANを配置した．
仮想お客さまLPAR，CustA，CustBを作成し，それぞれA系，B系のVLANにアサインした． CustA，CustBそれぞれに対して筐体外の区画からのネットワーク通信 (FTP転送)を実施して，CustA，CustBでのネットワーク流量を計測した．
さらにSEA Failoverを実施しA系，B系のactive-standby構成を入れ替え，障害時にも問題なく帯域を確保できるかを検証・確認した．
以下の(表5)に検証結果を添付する．
表5 ネットワーク検証値結果
|
VLAN
|
状態
|
Gbps
|
|
mkpvio01_A
|
Main
|
2．274972
|
|
mkpvio01_B
|
Sub
|
2．335883
|
上記結果から，VIOSに構成したそれぞれのEtherchannelにおいて2Gbps以上のスループットが出たことが確認できた．MCCSでは1Gbpsの物理ポート3つでEtherchannelを構成した
2Gbps以上の帯域を確保出来ていたことから想定通りの帯域を確保出来ていたことが分かる．
以上の結果から共用環境では複数アダプタによるEtherchannelの構成を推奨する．
4.3 Mdisk Groupによるパフォーマンスの違い
本環境では，要件によりアサインするディスクを変えて運用する設計とした．高速・低速それぞれのMdisk Groupから作成されたVdiskに対してブロックサイズの異なる書き込みアクセスを実施し，どの程度のパフォーマンスの違いが発生するのかを検証した(表6)．
結果から，本環境ではDS3400とDS8100のMdisk groupの違いにより約70%程度のパフォーマンスが異なることが分かった．この結果を参照し，個々の要件と照らし合わせてディスク装置をアサインする設計とした．パフォーマンス値についてはSANを構成する環境によって異なるため，実測して設計を検討いただきたい．
表6 Mdisk groupごとのパフォーマンス
|
Block
Size
|
DS3K
(MB/s)
|
DS8K
(MB/s)
|
DS3K/DS8K
(%)
|
|
4KB
|
239．06
|
341．93
|
69．9
|
|
8KB
|
271．15
|
382．51
|
70．9
|
|
64KB
|
315．22
|
432．04
|
73．0
|
|
1024KB
|
318．44
|
444．95
|
71．6
|
4.4 MPIOの優先度による負荷分散
MPIOによるディスクアクセスについて優先度によるIO割振りが可能であるかを確認した．VIOS２台からのMPIO構成とした仮想ディスクをアサインした検証用LPARを作成した．このLPARからは一つの仮想ディスクに対して２つの仮想SCSIアダプタから接続することになる．
図4 VIOCのディスク Adapter
I/O
この区画に対してアダプタごとにDisk I/Oを計測した．以下検証結果を添付する(図4)．
上記検証結果から，優先度を高く設定したSCSI (vscsi0)からのI/Oのみ計測されていることが分かる．よって，NPIVを利用しない場合にもMPIOによる設計にて，優先度を設定することにより負荷分散することが可能である．共用環境におけるVIOCのディスクアクセス検討の際にはMPIOによる負荷分散法を推奨する．
4.5 LPM (Live Partition Mobility)
LPARを稼働した状態でのLPM時には大量のMemory転送がVIOS間で発生する．そのため，LPM時にLPARのパフォーマンス劣化が発生する可能性がある．実際にどの程度の劣化があるかを検証した．CPUに関してはその仕様上，影響を受けることがない．
LPM検証として，2通りの方法を実施した．1つ目は，通常時とLPM時でそれぞれ負荷をかけてDisk I/O (Write Only)とMemory (ops/s)パフォーマンスにおいてどの程度の差異があったかを確認した(表7)．2つ目は負荷がある場合とない場合でのLPMにかかる時間を計測した(表8)．
表7 LPM時のパフォーマンス比較Ⅰ
|
|
通常
|
LPM時
|
比較(%)
|
|
Disk IO (64KB)
|
562．89
|
364．39
|
64．74
|
|
Memory(ops/s)
|
10358．7
|
6414．73
|
65．85
|
表8 LPM時のパフォーマンス比較Ⅱ
|
|
通常
|
高負荷時
|
比較(%)
|
|
LPM time
|
0 03 32
|
0 04 06
|
109．0
|
上記表から，LPM時にはDisk IO, Memoryのパフォーマンスは通常時に比べて7割弱に減少し，実行時間は10%増加することが分かる．
検証したLPARへは4Gbytesのメモリーをアサインした．つまり，LPM時には平均19.3Mbpsの帯域を使用していたことが分かる．1GbpsのNICをLPMに使用した場合，VIOSの負荷を考慮外とし，GbEの有効使用率を30％とすると15台以上のVIOCを同時にLPMすることが可能である．
LPM時のVIOCのディスクI/Oパフォーマンス劣化の原因は，LPMのためにVIOSに負荷がかかりVIOCのI/Oに割り振るためのメモリーがVIOS上で少なくなった可能性がある．VIOCのメモリパフォーマンス劣化についてはLPM時のメモリーがフリーズしたことが考えられる．
検証結果からLPM自体の時間も増加することが分かった．運用時にはLPM実行時間を検討し，パフォーマンス劣化の影響がないかを考慮して実行計画を検討いただきたい．
５．おわりに
本論文では，IBM Power Systemsを使用して複数のお客様に仮想区画を提供するマルチテナント型仮想化ホスティングサービスにおけるシステム設計技法を様々な観点から設計・考察し，所望の動作をしているかについて検証を実施した．検証結果から，セキュリティ，パフォーマンス，可用性において設計通りの動作を確認することができた．この設計技法を用いてMCCSはサービスを開始しているので信頼性が高いと言える．またIBM BT/ITからIES認定も受けており，LPAR/STORAGE/NETWORKのセキュリティ上の分離についても問題ないことが証明されている為，安心して本設計を利用してほしい．
謝辞
当論文の作成にあたっては，pMCCSの構築・運用メンバー，CPUリソースのサイジングの際Bruno Blanchardさんに助言を頂き，各種検証についてもご協力いただきました．あらためて深謝いたします．
参考文献
[1]
「クラウドコンピュ－ティングと日本の競争力に関する研究会」報告書 http //www．meti．go．jp/press/20100816001/20100816001-3．pdf, p16
[2]
IDC
Japan 国内クラウドサービス市場予測
http //www.idcjapan.co.jp/Press/Current/20100412Apr.html
[3]
丸山不二夫 "クラウド時代への備え", ITアーキテクト, Vol．21, pp24-43 (2009)．
[4]
IBM マネージド・クラウド・コンピューティング・サービス
http //www-935.ibm.com/services/jp/index.wss/offerfamily/so/b1333005
[5]
An IBM
Redbooks publication Implementing the IBM System Storage SAN Volume
Controller V5．1
http //publib-b．boulder．ibm．com/abstracts/sg246423．html
http //publib-b．boulder．ibm．com/abstracts/sg246423．html
[6]
Maurizio
Biffa, Baerbel Altmann Virtualized
Hosting on System p Architecture and Deployment Guide ARC 113 – Operational
Model Final Version 1.3, No. RAGP-TOM-00098, (2009)
[7]
沢橋松王 "サーバー仮想化でITコスト削減と地球温暖化防止を",
2009年IBMプロフェッショナル論文,
No．09PAP5313
[8]
An IBM
Redbooks publication IBM PowerVM Live Partition Mobility
http //www．redbooks．ibm．com/abstracts/sg247460．html
[9]
An IBM
Redbooks publication PowerVM Virtualization on IBM System p Introduction and Configuration Fourth Edition．
http //www．redbooks．ibm．com/abstracts/sg247940．html
