Power Systems テクニカル・ワークショップ2017 PowerVM編

Presentation on theme: "Power Systems テクニカル・ワークショップ2017 PowerVM編"— Presentation transcript:

1 Power Systems テクニカル・ワークショップ2017 PowerVM編
日本アイ・ビー・エム株式会社

2 当セッションのアジェンダ １) Powerテクノロジー 復習 ２) PowerVM構成 ベスト・プラクティス
−VIOS、Network、SAN 3) 使える仮想化機能 総復習 LPM（Live Partition Mobility） PEP（Power Enterprise Pools） WPAR（Workload Partitions ） AME（Active Memory Expansion）

3 1) Powerテクノロジー 復習

4 Power Systemsの進化を支えるテクノロジーへの投資
全世界で展開されているPower Linux Centerや、 Open Power Consortiumへの取り組みなど、 Linux on Powerへの1,000億円投資を表明し、 今後より一層オープンなテクノロジーへの 研究開発が行われます。 Power Systems 信頼性 性能 機能

5 Power Systemsの進化を支える3つのキーワード
High Performance　　 １ 進化し続けるパフォーマンス　 Open Technology　　 ２ 既存資産を活用する　 Flexibility ３ 運用管理にかつてない柔軟性を

6 ITインフラを支えるチップ・テクノロジーの進化
2017 2020+〜 POWER10 2014 2010 2007 POWER9 POWER8 22 nm Extreme Analytics Optimization Extreme Big Data Optimization On-chip accelerators 2004 POWER7/7+ 45/32 nm 1チップ12コア SMT 8 FPGA サポート トランザクショナル・メモリー PCIe アクセラレーション 3.0 ～ 4.4 GHz 1チップ8コア eDRAM L3 キャッシュ エネルギー効率の向上 SMT 4 VSM & VSX ストレージ保護キーの拡張 POWER6/6+ 65/65 nm 次世代チップ・ テクノロジーに 3,000億円の投資 3.5 ～ 5.0 GHz デュアル･コア SMT2 十進浮動小数点演算 インストラクション・リトライ ストレージ保護キー 2,400億円 の投資 POWER5/5+ 130/90 nm 1.5 ～ 2.2 GHz デュアル･コア Simultaneous Multi-Threading (SMT) Micro Partitioning

7 ”ムーアの法則”終焉時代に必要なIT業界のイノベーション
System Stack Processors Semiconductor Technology Applications and Services Systems Management& Cloud Development Systems Acceleration & HW/SW Optimization Firmware, Operation System and Hypervisor Processors Semiconductor Technology Moore’s Law Use Cases Price/Performance($/SIR) Workload Acceleration Services Delivery Model Advanced Memory Tech Network & I/O Accel GAP コスト性能比の向上の為には システムスタック全体での技術革新が必須 2004 2006 2008 2010 2012 2014

8 技術革新を進めるOpenPOWER Foundationを設立
Implementation/HPC/Research System/Software/Services I/O/Storage/Acceleration Boards/Systems Chip/SOC Complete member list at

9 開発が進むOpenPOWERコミュニティーの成果物
NVIDIA GPUアクセラレーター -初のJava向け GPUアクセラレーター -Hadoopアナリティクス・パフォーマンスが飛躍的に向上 POWERにおけるRDMAの活用 -スループット10倍 -Key-Value Storeアプリケーションの遅延を改善 CAPI接続FPGAアクセラレーター -消費電力あたりの性能を35倍 -200倍の高速化を実現する金融分野向けモデル

10 Power VMによる仮想化で、システム環境の統合管理が可能に。
仮想環境の運用管理にさらなる柔軟性を PowerVM： リソース管理はポリシーを決めて設定すれば、あとはハードウェア・ファームウェアと連携しPower Hyperviserが仮想環境運用してくれます アプリケーション IBM i 7.1 IBM i 7.2 IBM i 7.3 アプリケーション AIX 5.3 AIX 6.1 AIX 7 アプリケーション RHEL 7 SUSE 11以降 Ubuntu 16.04 区画作成 リソース管理 区画作成 リソース管理 区画作成 リソース管理 HMC PowerVM Hypervisor 　　　　　物理ハードウェア層 プロセッサー メモリー ディスク ネットワークカード Power VMによる仮想化で、システム環境の統合管理が可能に。

11 I/Oの仮想化を実現するPower VM 必要なときに、すぐに、 ほしい環境を 仮想サーバーとして追加可能 I/O 仮想化 (VIOS)
迅速な新サービスの展開を実現： −物理アダプターの追加が不要なため、仮想サーバーを即時に構築可能 −新規に仮想サーバーが欲しい というユーザーの要望に迅速に対応 お客様の統合・基幹基盤に求められる高い可用性と連続稼働を実装： −I/O の仮想化層の冗長化が可能 必要なときに、すぐに、 ほしい環境を 仮想サーバーとして追加可能 物理ネットワーク I/O 仮想化 (VIOS) 仮想サーバー #01 仮想 Fibre 仮想 SCSI 仮想 Ether 仮想サーバー #02 仮想 Fibre 仮想 SCSI 仮想 Ether 仮想サーバー #03 仮想 Fibre 仮想 SCSI 仮想 Ether イーサネット アダプター a5 a4 a3 a2 a1 物理ディスク イーサネット アダプター 仮想 Fibre 仮想 SCSI 仮想 Ether イーサネット アダプター PowerVM Hypervisor 仮想Ether 仮想SCSI 仮想Fibre

12 Power VMの特徴とメリット 特徴 メリット PowerVM Hypervisor Micro-Partitioning
※2 一部の Power Systems で使用可能 ※ 以降のファームウェアを搭載した POWER8 システム上で使用可能 ※ 以降のファームウェアを搭載した POWER8 システム上で使用可能 Power VMの特徴とメリット 特徴 メリット PowerVM Hypervisor 単一システムで複数のオペレーティング環境（IBM i, AIX , RHEL, SUSE）をサポート Micro-Partitioning プロセッサー・コア当たり最大 20 の VM を作成可能※1 Dynamic Logical Partitioning プロセッサー、メモリー、I/O などのシステム・リソースを VM 間で動的に移動可能 Shared Processor Pools ・VM グループのプロセッサー・リソースに上限を設定して、ソフトウェア・ライセンスのコストを削減 ・複数の VM で共用のプロセッサー・リソース (上限あり、または上限なし) を使用可能 ・ワークロード要求に基づいて VM 間で自動的にプロセッサー・リソースを移動可能 Shared Storage Pools Power Systems と VIOS のストレージ・リソースをプールで集中管理して、リソース使用率を最適化 Integrated Virtualization Manager Power Systems のエントリー・モデルにおける VM の作成と管理を簡素化するツール Live Partition Mobility (LPM) ※Enterprise Edition の機能 AIX、IBM i、Linux の VM を稼働したままサーバー間で移動させることで計画停止を回避 Active Memory Sharing (AMS) ※Enterprise Edition の機能 VM 間でのインテリジェントなメモリー・フローを可能にして、メモリーを効率的かつ柔軟に使用 Active Memory Deduplication ※Enterprise Edition の機能 AMS 構成で使用可能。メモリー・ページの重複を検出して削除することで、メモリー消費量を削減 N_Port ID Virtualization (NPIV) ファイバー・チャネル SAN 環境の管理を簡素化して、パフォーマンスを向上 Single Root I/O Virtualization (SR-IOV) ※2 ハードウェア・ベースの I/O の仮想化により、パフォーマンスとサービス制御の品質を強化 System Planning Tool PowerVM を活用する Power Systems の計画と導入を簡素化 VIOS Performance Advisor VIOS のパフォーマンスと状態を確認し、パフォーマンス向上のための推奨値を提供 IBM PowerVP Monitor※1 ※Enterprise Edition の機能 ・仮想ワークロードを物理ハードウェアへマップしている状態で気がかりとなる性能問題へプロアクティブ　　 　に対処できるパフォーマンス・インテリジェンスを提供 ・仮想化サーバーのパフォーマンスをシンプルに色分けしたヘルス表示 リトル・エンディアンの Linux ゲストのサポート※3 システム上で SLES 12、Ubuntu 16.04、RHEL 7 などのリトル・エンディアン Linux ディストリ ビューションを AIX、IBM i、旧バージョンの Linux と同時に実行できる柔軟性を実現 仮想 NIC アダプター SR-IOV アダプターとともに使用することで 、パフォーマンスの向上と LPM のサポートを実現 NovaLink※4 ・PowerVM ホストへの OpenStack の直接接続が可能 ・クラウドのスケーラビリティーを向上させ、管理を簡素化 システムと区画のテンプレート エラーの無い VM の展開・構成を繰り返し実施可能

13 ２) PowerVM構成 ベスト・プラクティス
−VIOS、Network、SAN

14 VIOS

15 VIOSの推奨構成 1/2 … VIOSにはお使いのPowerシステムが保有するCPUの10%を目安としてください。
ご利用の環境によって推奨構成は異なりますが、下記のガイドラインをご参考としていただき、 基本的な運用管理・構成のポイントをご理解いただければと思います。 VIOSにはお使いのPowerシステムが保有するCPUの10%を目安としてください。 　−64個のCPUを保有しているE870モデルは、その10%の6.4CPUをVIOSへ割り当てます。 　−VIOSを冗長化する場合、半分の3.2CPUを割り当ててください（3.2x2=6.4）。 VIOSは冗長化することで、再起動することなくVIOSへのリソースの変更をしたり 、何らかの原因で片方が停止した場合にもDLPARでリソースの変更が可能となり ます。 DLPAR （Dynamic LPAR による手動割当て変更） VIOS01 VIOS02 Client01 Client02 Client03 Client04 … （例） Power870 64CPU VIOSを冗長化する場合 共有プロセッサー・プール それぞれ 5%(3.2CPU) それぞれ 5%(3.2CPU) POWER コア POWER コア POWER コア POWER コア POWER コア POWER コア

16 VIOSの推奨構成 2/2 仮想プロセッサーの設定はdesiredで6CPUに設定した場合は、maximumの場合は 12CPUを割り当てることができます。 共有プロセッサープールを利用する区画はプロセッサー能力の割り当ての上限を 指定する 2つのモードが用意されています。 　−上限あり (capped :  デフォルト値)：指定したプロセッシング・ユニット値を超えられない 　−上限なし (uncapped)：共用プロセッサー・プールに空きがある場合、指定したプロセッシン グ・ユニット値を超えてプロセッサー能力を使用可能 　　　　　　　　　　　　（仮想プロセッサー数 ×1.0 プロセッシング・ユニットまで使用可能） メモリの設定はdesiredであれば最小4GB、最大16GBを目安としてください。 プロセッサー、およびメモリのminimum値は、システム再起動時に必要なリソース です。

17 冗長VIOS構成のお勧め Power Server VIOS Server #01 VIOS Server #02
VIOS冗長化のメリットとして、VIOSのメンテナンスや更新、ソフトウェアのパッチ適用および 単一のVIOSの停止中に、作成したクライアント区画のダウンタイムが発生しない等が挙げられます。 Power Server 仮想サーバー #01 Multi Pathing 仮想SCSI 仮想Ether Interface 仮想SCSI 仮想Ether Port Virtual Switch VIOS Server #01 ent2(SEA) VIOS Server #02 ent2(SEA) (ent1:仮想) eth0 eth0 Network Switch Network Switch 仮想SCSI (ent1:仮想) 仮想SCSI (ent3:仮想) (ent3:仮想) Control Channel 仮想Fibre 仮想Fibre SAN Switch SAN Switch

18 Network

19 Large Send機能 Large Send機能を使用すると、物理ネットワーク上のMTUサイズに関係なく、 クライアントパーティションが仮想イーサネット接続経由で64kBのパケットデー タを送信できるようになります。この場合、大量パケット・ワークロードのCPU 使用率は、MTU 1500に必要なCPUの約半分となります。 VIOS上のSEA entインターフェースで下記のコマンドを実行すると、 クライアントはデフォルトでLarge Send機能がオンとなります。 仮想クライアントは /etc/rc.tcpip configファイルに下記の設定も行って下さい。 $ chdev –dev entX –attr largesend=1 Ifconfig enX largesend up

20 仮想イーサネットでのリンクアグリゲーション機能
リンクアグリゲーションは物理アダプターの取り外しや交換の際、SEAを切断させる ことがないので、柔軟性の提供にもつながります。 VIOSにはホットプラグ対応のネットワークアダプタを使用してください。 全ての物理アダプタはdesiredに設定してください。 （requiredにした場合、起動後の削除や移動ができません。）

21 冗長VIOS構成での仮想イーサネットトランク優先順位
VIOSで共用イーサネットアダプタ（SEA）を使用する場合は、 SEAフェールオーバーでトランク優先 順位を変更する必要があります。 Power Server 仮想サーバー #01 仮想Ether Port （注）トランク優先順位が同じ場合 　　　ブロードキャストストームが発生します。 　　　過去にストームの影響でネットワークが 　　　落ちた事例があるので注意が必要です。 Primary Secondary VIOS Server #01 VIOS Server #02 ent2(SEA) eth0 (ent1:仮想) ent2(SEA) (ent1:仮想) eth0 Enet PCI Enet PCI Enet PCI Enet PCI VLAN 1 VLAN 2 VLAN 1 VLAN 2 VLAN 1 VLAN 2 VLAN 1 VLAN 2

22 Virtual Ethernet – SEA component 優先順位の設定
Primary 1

23 Virtual Ethernet – SEA component 優先順位の設定
Secondary 2

24 10Gbイーサネットアダプターのご使用について
10Gbのアダプターは特別な広帯域アダプタとして考える必要があり、 トップスピードで動かすには高いCPUリソースを必要とします。 パフォーマンス・サイジングのガイドラインでは、このスループットを得るために 各々の10Gbアダプターに1コアのリソースを使用すると考えて下さい。 また、推奨構成ガイドとしては、VIOSで10Gbアダプタを使用する場合は、 専用パーティションに設定することをおすすめしています。 （VIOS用に共有プロセッサープールを使用して、VIOSのCPU使用率を監視し、 10Gbの利用状況によって、CPUリソースの補填を検討するようにしてください）

25 SAN

26 【Redbook:SG247940】PowerVM仮想化導入と構成
26 Very Good books. As usual a perfect book. We periodically make technical corrections to our publications

27 NPIV(N_Port ID Virtualizationとは）
PowerVMでは、vSCSIとNPIVという2つの仮想化ストレージ技術がサポートされ ています。 NPIVは、単一の物理的FCポートを複数のシステム間で共有できる業界標準です。 このテクノロジーを使用すると、物理的なファイバー・チャネル・アダプターの1 つの物理ポートに複数のシステムを接続できます。 各システム（LPAR）には、仮想FCアダプタに関連付けられたワールドワイドポ ート名（WWPN）があります。 つまり、各LPARをネイティブにSAN上の物理ス トレージに接続することができます。

28 VSCSIとNPIVによる仮想化の比較 VSCSI NPIV SAN SAN F C F C F C F C EMC 5000
POWER5 or later POWER6 or later Virtualized Disks VIO Client VIO Client Generic SCSI Disk Generic SCSI Disk Disks EMC 5000 IBM DS8000 Virtual SCSI Virtual FC Virtualized Disks VIO Server Virtualized FC Adapter VIO Server FC Adapters FC Adapters F C F C F C F C SAN SAN EMC 5000 IBM DS8000 EMC 5000 IBM DS8000 SCSI DiskをエミュレーションするVSCSIと異なり、NPIVではデバイスレベルの抽象化や エミュレーションは行いません。 VIOSはパススルーで、クライアントからSANへのFC接続を提供します。

29 NPIVのメリット NPIVにより、ストレージ管理者はストレージ管理に既存のツールと手法を用いる ことができます。
SANマネージャー、コピーサービス、バックアップ/リストアなどの機能は そのまま使用可能です。 VSCSIと比較すると、構築のプロセスが簡易化されています。 ロードバランシング(Active/Active)モードでVIOSを介して複数のPathが 利用可能です。

30 冗長VIOSでのLPM使用時の注意点 冗長VIOS構成を使用する場合、またはLive Partition Mobility（LPM）を 使用できるようにする場合、クライアント用のvSCSIディスクには適切な設定が必 要です。 冗長VIOS環境でSANに接続されたディスクのディスクデバイス予約属性を single_path（VIOSのデフォルト値）からno_reserveに変更します。 $ chdev –dev hdiskX –attr reserve_policy=no_reserve　　　　※全てのhdiskに適用して下さい。 　　　これらの設定は、ほとんどのMPIOソフトウェアが該当します。 　　　その他の個別の設定については提供元ベンダーにご確認下さい。 30

31 3) 使える仮想化機能 総復習 LPM（Live Partition Mobility Overview）

32 LPM（Live Partition Mobility）概要
異なるサーバー間の リソース移動も 稼働中のサービスを 止めることなく実施可能 Virtualized SAN and Network Infrastructure 実行中のワークロードをシステム メンテナンス中に他サーバーに移動 することにより、計画ダウンタイムを削減 必要な時いつでもサーバー間の プロセッサー処理能力を調整可能

33 【事例ご紹介】Power Systemの仮想化を実践されたお客様
主要業務をオンプレのPower Systemsに統合・集約 大手都市銀行 2003年より、IT投資の削減を目的に、 行内に分散するUNIXサーバー群の統合を進める。 2010年、IBM Power Systemsの仮装化機能 （LPM、マイクロパーティショニング、CoD）を 駆使して可用性と柔軟性を兼ね備えたリソース・ プールを実現。数百の区画が稼働する高度な プライベート/クラウド基盤を構築。 2016年、クラウド化の潮流の中、主要業務を オンプレミスのプライベートクラウドに残すことを選択。基盤を最新のPOWER8サーバーへ更改。 今後はPower Systemsクラウドモデルを利用した ハイブリット・クラウド基盤を目指す。 本番リソース・プール 災対/開発リソース・プール Private プライベート・クラウド基盤を残す選択をされた大手金融機関様 Capacity on Demand (CoD) とは　

34 LPMの移行タイプ Active Partition Mobility Inactive Partition Mobility
LPAR内で実行されているOSおよびアプリケーションの稼働を停止することなく、 別筐体の物理マシンに移動することを可能とします。 （適用ケース） ・ワークロードの統合（例　n:1） ・ワークロードバランシング（例　大規模システムへの移行） ・ハードウェアメンテナンスやバージョンアップ作業などの計画的なCEC停止 ・緊急のCEC停止（例　ハードウェアの警告アラート時など） Inactive Partition Mobility 非アクティブLPARを別筐体の物理マシンに移動するもので、この際のLPARはパワーオフ されているものとなります。 このPartition Mobility機能はAIX、IBM iおよびLinuxでサポートされています。 34

35 Live Partition Mobility プロセス
Create virtual SCSI devices System #1 Start migrating memory pages System #2 AIX Client 1 Finish the migration and remove the original LPAR definitions Once enough memory pages have been moved, suspend the source system Create shell partition on target system Validate environment for appropriate resources Suspended Partition Shell Partition AIX Client 1 M M M M M M M M M M M M M M M M A vscsi0 en0 (if) ent1 en0 (if) ent1 A vscsi0 HMC Hypervisor VLAN Hypervisor VLAN VIOS VASI vhost0 ent1 VIOS ent1 vhost0 VASI Mover Service vtscsi0 ent2 SEA en2 (if) en2 (if) ent2 SEA vtscsi0 Mover Service fcs0 ent0 ent0 fcs0 Storage Subsystem A

36 LPM – Managed System Requirements

37 HMC管理画面 – ライセンスの表示 Server Mode

38 HMC管理画面 – AMS・LPMの確認（Server 1）
Server Mode

39 HMC管理画面 – AMS・LPMの確認（Server 2）
Server Mode

40 LPM – Network Requirements

41 LPM – ネットワークの構成要件 LPMの前提として、移動先ホストは 移動元ホストと同じサブネットと VLANである必要があります。
System #01 System #02 仮想Clientサーバー #01 LPMの前提として、移動先ホストは 移動元ホストと同じサブネットと VLANである必要があります。 vlan vlan etn0 etn1 PowerVM Hypervisor PowerVM Hypervisor vlan vlan vlan vlan VIOS Server#01 VIOS Server#02 vlan VIOS Server#01 VIOS Server#02 vlan SEA SEA SEA SEA ネットワークスイッチ

42 HMC管理画面 – SEA VLAN Support （Server 1）
Server Mode

43 HMC管理画面 – SEA VLAN Support （Server 2）
Server Mode

44 LPM - VIOS Requirements

45 Mover Service Partition - MSP
Active Partision Mobility の場合はMSPがEnableになっている必要があります。 移動元サーバーと移動先サーバーの少なくとも1つのVIOSでMSPが有効となって いる必要があります。 HypervisorからVASI(Virtual asynchronous services interface）仮想インター フェイスを通じてパーティションの状況を取得します

46 LPM MSPの確認(1) 移動元・移動先ともにMSPをEnableする必要があります

47 LPM MSPの確認(2)

48 LPM - Source Partition Resources

49 Partition状態の確認

50 Source Partition – 物理I/Oアダプターは不可

51 Source Partition – 仮想ネットワーク

52 LPM, AMS －PowerVM Enterprise Editionが必要

53 4) 使える仮想化機能 総復習 PEP（Power Enterprise Pools）

54 PEPとは

55 PEP (Power Enterprise Pools) 概要
Power Enterprise Pools(PEP)とは ：サーバー・リソースプール内のリソース(CPU & メモリー起動)を共有することにより、複数筐体間でリソースを自由に移動させること。 サーバー1号機 ・CPU起動 ・メモリー起動 ・Power SW サーバー2号機 プール HMC PEPのメリット 何度でも即時にお客様自身でリソースの移動が可能(IBMへの通知不要) 移動用リソースを事前に購入いただけるため、追加の課金や資金調達が不要 HMCのGUIで操作可能のため、固有のコマンド知識が不要 PEPの活用例 プロジェクト・フェーズ（開発初期〜運用）に応じた可動コアの再配置 災対用待機サーバーの平常時稼働コア数の削減 筐体停止を伴う保守作業中でも縮退させることなく、他筐体でのサービス継続

56 【事例ご紹介】Power Systemの仮想化を実践されたお客様
引き継ぎ時も縮退をせずに本番と同等の稼働環境を担保 本番リソース・プール 待機系リソース・プール 大手製造販売会社 各種基盤（AIX / IBM i / Solaris / IA）のサーバー 集約・統合を進める中、クリティカル業務システム (高可用性、高い性能保証、高セキュリティが求めら れるシステム）群を Power Systems 基盤に集約。 Power Systems 基盤の 30% を占める待機系 サーバーのリソースを「Power Enterprise Pool (PEP)」の活用により待機系は最小構成にて配備 することでリソースを抑制。 かつ引き継ぎ時、計画停止時も従来の縮退稼動から 本番と同等環境での稼動を実現。 各業務システムで独立して構築していたサーバー群 を、機能・目的別に集約してサーバー台数を 58% 削減。 区画1 VIO 区画1 VIO 引継や計画停止時に… リソース削減 (平常時) PEP E870C POWER8 32コア 384GBメモリー 区画1 待機系は 縮退稼働 区画1 区画1 区画1 VIO 区画1 VIO 従来 VIO 使用可能なリソース 契約済みリソース 使用可能なリソース (引き継ぎ時) 契約リソース (待機時) 平常時は待機マシンのリソース大幅削減を実現 Power Enterprise Pool (PEP) とは　

57 PEP (Power Enterprise Pools) の種類
(9117-MMD) Power 870 (9119-MME) ミッドレンジ・プール：Power 770(MMD)、Power 870(MME) ミッドレンジ・プールとハイエンド・プールを またがったリソースの移動はできません。 Power 795 (9119-FHB) Power 780 (9179-MHD) Power 880 (9119-MHE) ハイエンド・プール：Power 795(FHB)、Power 780(MHD)、Power 880(MHE)

58 PEPで移動可能なソフトウェアの一覧 OS AIX V6.1, V7.1, V7.2
IBM i V6.1, V7.1, V7.2, V7.3 その他 Power Systems 管轄ソフトウェア PowerHA for AIX V6, V7 PowerHA for i V6.1, V7.1 PowerSC PowerVC PowerVM PowerVP 詳細は「Power Enterprise Pool に関する IBM ライセンス補足契約」(Z )に 記載されている“IBM プログラム番号”にてご確認ください。 Linux OS は移動できません。お客様の責任で移動元および移動先サーバーでのサブスクリプションを得てください。

59 主な注意事項 １プールの最大サーバー数は、ハイエンド32、ミッドレンジ48、合計1,000区画まで
モバイル用起動の初期設定と移動は、1台の HMC で管理（冗長 HMC 可能） 通常の起動機構とモバイル用起動は、同一区画での共存可能 Elastic CoD （On/Off CoD）は必須でありませんが、同一筐体で利用可能 移動できない最小固定起動数 - Power 770/780：4コア、および起動メモリーの 25% - Power 795：24コアまたは搭載コアの25% のいずれか多い方、および起動メモリー の 25% - Power E870/E870C/E880/E880C：8コア、および起動メモリーの 25% プール内のサーバー全てのファームウェアが、eFW 7.8 以降 移動範囲は、同一エンタープライズかつ同一国内に限定 物理搭載数を超えるモバイル用起動の移動は不可 モバイル用起動の移動は、即時かつ動的、回数制限無し - ただし、移動後48時間以内に移動元リソースを非活性の状態に戻すこと

60 PEPとLPMの組み合わせ LPM（Live Partition Mobility）は、論理区画（LPAR）を稼動状態のまま筐体間移動 させる PowerVM Enterprise Edition の機能です PEP と LPM を組み合わせることで、稼動中 LPAR をそのまま別筐体に移動させることが 可能になるので、以下のメリットを享受することが可能です - 筐体停止を伴う保守作業の前に、アプリケーションを稼動させたまま LPAR を別筐体に 　移動させることで、縮退させることなくサービスを継続 - 予め起動しておかなくても、LPAR を移動させる直前に必要なだけのリソースを起動 　させられるので、HW & SW コストを節約できます メリット - LPAR を停止することなく、筐体をまたがった資源の割り振りが可能です - 突発的なリソース変更の要求に迅速に対応できます 注意事項 - Oracle などの場合、LPM を使うことで必要ライセンス数が増加することがあります。

61 PEPとPower HAの組み合わせ フェイルオーバー 稼働中 本番LPAR 待機系LPAR Application Power HA Cluster HMC PowerVM Hypervisor PowerVM Hypervisor Power Enterprise Pool CoD 障害発生時に PowerHA V7.2フェイルオーバー機能により、待機系のサーバー上の コアを自動的に起動させて、LPAR も移動させます PowerHA によるノード引継ぎ時の自動的な DLPAR 機能の拡張 コスト削減メリット - ハードウェア・コスト（CPU コアの起動料金と保守料） - ソフトウェア・コスト（ライセンスと保守料金）

62 アクティベーションコードはPool MasterであるHMCから 他のHMCへ引き継がれます
複数のデータ・センターに別れた複数のシステムを一つの Power Enterprise Poolとすることができます (HMC code) Data Center1 Data Center 2 HMC#01 Pool Master HMC#03 Managing HMC Power7 Power8 Power8 Power7 アクティベーションコードはPool MasterであるHMCから 他のHMCへ引き継がれます HMC#02 HMC#04

63 冗長HMC (HMC 8.850 code) 各データセンター内または各サーバー用に冗長なHMCが可能です。
すべてのHMCは相互にRMC通信を行う必要があります。 Master HMC HMC 1 HMC 2 HMC 3 Power Enterprise Pool Server A Server C Server B Server D HMC 4 HMC 5

64 Power Enterprise Pool 利用例その１
Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 40 mobile 14 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 40 mobile 26 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 20 mobile 60 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 60 mobile 28 “dark”

65 Power Enterprise Pool 利用例その１−①
Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 0 mobile 54 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 40 mobile 26 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 60 mobile 20 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 60 mobile 28 “dark” 40 activation移動

66 Power Enterprise Pool 利用例その１−②
Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 0 mobile 54 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 55 mobile 26 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 45 mobile 20 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 60 mobile 28 “dark” 15 activation移動

67 Power Enterprise Pool 利用例その２
Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 40 mobile 14 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 40 mobile 26 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 20 mobile 60 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 60 mobile 28 “dark”

68 Power Enterprise Pool 利用例その２−①
Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 40 mobile 14 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 32 mobile 34 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 35 mobile 45 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 53 mobile 35 “dark” 8 activation移動 7 activation移動

69 Power Enterprise Pool 利用例 PoolとElastic CoD
更にElastic(On/Off) CoDにより 一時的にdarkコアを活性化し ピーク時をカバーすることができます。 Pool合計 Activations: 96 static 160 mobile 128 “dark” Server A 64 cores 780 4.4GHz Activations: 10 static 40 mobile 14 “dark” Server B 96cores 880 4.4GHz Activations: 30 static 32 mobile 34 “dark” Server C 96 cores 880 4.4GHz Activations: 16 static 35 mobile 45 “dark” Server D 128 cores 780 4.4GHz Activations: 40 static 53 mobile 35 “dark” Not so dark

70 6) 使える仮想化機能 総復習 WPAR（Workload Partitions ）

71 WPARとは

72 WPAR (AIX Workload Partitions )
AIX Workload Partitions(WPAR)とは ： AIXをOSレベルで仮想化し、1つのAIX上で複数のAIX区画を動作させる機能です。 AIX6.1以降でサポート 1つのAIX上で、あたかも複数のAIXが起動しているような環境を提供します LPARに比べて管理が簡単で、メモリやディスクなどの資源を節約できる利点があります 独立したファイルシステムや、IPアドレスを持つこともできます プロセッサー、メモリー、I/Oは、WPAR単位で制限できます  AIX Workload Partition D Workload Partition A Workload Partition B Workload Partition E (注) WPARには、システムWPARとアプリケーションWPARの2種類があります。 　　アプリケ ーションWPARは、システムWPARと異なりAIX全体の 　　仮想環境ではなく、コマンドラインから実行可能な単体アプリケーション 　　を実行するための仮想環境を提供します。 Workload Partition C

73 WPAR と LPAR の違い WPARの構造 LPARの構造 LPAR LPAR LPAR LPAR AIX AIX AIX
B WPAR C AIX AIX AIX AIX（グローバル環境） CPU メモリ I/O CPU メモリ I/O CPU メモリ I/O CPU メモリ I/O WPARとグローバル環境のAIXはカーネルを共有する WPARが使うデータやプロセス、ネットワークなどの 資源は分離され、制限も可能 LPAR間は、CPUやメモリなどの資源が分離されている LPAR間のOSは、完全に独立している

74 WPAR と LPAR の比較 WPAR LPAR ・AIXカーネルはLPAR内で共有
・AIXのOSレベルは同じ（Versioned WPARを除く） ・LPAR毎に独立したAIXカーネル ・AIXのOSレベルはLPAR毎に自由に選択可能 WPAR毎に、細粒度のリソース管理が可能 LPAR毎のリソース管理 最低限必要なメモリーは64MB 最低限必要なメモリーは512MB 少ない管理コスト −単一のオペレーティングシステム −簡単に作成・削除・設定が可能 −統一された管理ツール OSの障害が他のLPARに影響せず、問題の特定が容易 OSで提供されるソフトウェアレベルでのセキュリティ分離機能 ハイパーバイザーによるハードウェアレベルでの セキュリティ分離機能 PowerHAやGPFSクラスタノードとして構成不可 PowerHAやGPFSクラスタノードとして構成可 NFSサーバーとして構成不可 NFSサーバーとして構成可 WPAR個別のカーネルチューニングは利用不可 カーネルチューニング利用可

75 WPAR ユースケース

76 各WPARには独自のソフトウェアを導入可能
開発環境とテスト環境 開発環境では、複数の異なるバージョンのソフトウエアを使う必要に迫られることが あります。 従来は新規にLPARを作成して、各LPAR毎に異なるバージョンのソフトウエアを導入して 開発を行う必要があります。 テスト環境において、OSの設定を変更してテストしたり、不安定なソフトウエアを導入 してテストするなどの一時的に独立した環境が必要となる場合があります。 WPARを使用すれば、グローバル環境と同じOSレベルの環境を素早く簡単に作成できます。 さらに、グローバル環境とデータやプロセスなどが分離されているので、 安心してテストを行うことができます LPAR 各WPARには独自のソフトウェアを導入可能 開発用 WPAR A 開発用 WPAR B テスト用 WPARC WPAR間やグローバル環境との間は、 データやプロセスが分離される。 AIX（グローバル環境） グローバル環境の AIX環境を複製可能

77 開発環境とテスト環境の統合 アプリケーション単位に開発・テスト・本番環境のLPARを作成した場合、LPARの数が 増えてしまい、多くのシステム・リソースを消費し管理の手間も増える場合があります。 WPARによって開発・テスト環境LPARを統合することでLPARを減らすことができ、 またリソースの節約、管理負担の削減が期待できます。 LPARだけの場合 WPAR + LPARの場合 LPAR数を減らすことで 管理の手間を軽減 グローバル環境との リソース共有によって ディスクなどのリソース を節約 LPAR LPAR LPAR LPAR LPAR DB2 本番 DB2 開発 DB2 テスト DB2 本番 DB2 開発 WPAR DB2 テスト WPAR AIX （グローバル環境） AIX AIX AIX AIX

78 VIOSがない環境でNICを共有 通常、VIOSがない環境では、LPAR間でネットワーク・アダプターを共有することはでき ません（IVEを除く）が、WPARを使えばグローバル環境のNICをWPAR間で共有可能です。 VIOSを使わず、限られたネットワーク・アダプターで複数のAIX環境を提供可能 LPARの場合 WPARの場合 グローバル環境のネットワーク・ インターフェースへエイリアスと してWPAR独自のIPアドレスを付与 LPAR LPAR LPAR LPAR VIOS AIX AIX DB2 開発 WPAR DB2 テスト WPAR 物理 ネットワーク 物理 ネットワーク イーサネット アダプター AIX （グローバル環境） eth0 eth0 eth0 イーサネット アダプター 仮想 Ether 仮想 Ether 仮想 Ether Power Hypervisor Power Hypervisor 仮想 SW

79 応用例 Versioned WPAR： − グローバル環境とは異なるバージョンのAIXの実行環境を提供するシステムWPARです。
− AIX5.3のLPARをサポートしないハードウェアであっても、AIX7.1（以降）にAIX5.3のVersioned WPARを 作成し、AIX5.3の実行環境を必要とするアプリケーションを動作させることが可能です。 Versioned WPAR使用環境 前提条件 Versioned WPARはPOWER7以上でサポートされて います。 Versioned WPARはAIX7.1以上の上に作成でき、 AIX5.3の最新レベルを稼働できます。 Versioned WPARはグローバル環境と/usr、/optを 共有することはできません。 Versioned WPARの使用には、別途ライセンス購入 が必要となります。 LPAR LPAR Versioned WPAR （AIX5.3） Versioned WPAR （AIX5.3） Versioned WPAR （AIX5.3） Web Accounting Database Mail AIX7.1（グローバル環境） AIX7.1

80 (関連情報） IBM Power Systems offeringAIX 5.3 のPOWER8 サポート

81 WPAR適用エリアの向き・不向き 1/2 WPARに向いている利用方法
開発用のサンドボックス環境 −WPARを利用すると、現状のAIX環境をもとに新たなAIX環境を簡単に作成できます。 −グローバル環境に影響を与えず、ファイルや設定などを変更することができます。 テスト用の環境 −WPARは早ければ数秒で作成されるため、テスト毎の作成・削除が容易に可能です。 −動作が不安定なアプリケーションを動かしてもグローバル環境に影響を与えないため、 　安心してアプリケーションのテストを実行することができます。 テストや開発環境の統合 −アプリケーション単位に開発・テスト・本番などのLPARを作成すると、LPAR数が増加し、 　多くのシステムリソースを消費し、また運用管理の手間も増えます。 −WPARによってテストや開発用のLPARを統合することで、LPARを減らしリソースの節約、 　運用管理の手間軽減へとつながります。 アプリケーションの分離 −１つのLPARで複数のアプリケーションを動作させるケースでは、各アプリケーション毎に 　アクセス可能なリソースを制限したい場合があります。 −このような場合、各アプリケーション毎にWPARを作成することで、簡単にアクセス可能な 　リソースを制限することができます。 −また、各アプリケーションの管理者が異なる場合、グローバル環境のroot権限を与える必要が 　なくなり、セキュリティ上の問題を軽減することができます。 WPARの適用にあたっては、利用方法の向き不向きをご参考にご検討下さい。

82 WPAR適用エリアの向き・不向き 2/2 WPARが適さない利用方法
グローバル環境と異なるOSレベルを使用したい場合 −WPARは、グローバル環境と同じOSレベルのみサポートします（Versioned WPARを除く） グローバル環境と独立した可用性が必要な場合アプリケーションの分離 −各WPARとグローバル環境はカーネルを共有しているため、グローバル環境でカーネルに起因する問題 　が発生すると、WPARにも波及します。 セキュリティ上の理由によるグローバル環境からの環境の分離 −グローバル環境のrootユーザーは、WPAR環境のファイルへアクセスすることが可能です。 −そのため、グローバル環境のユーザーから隠蔽する理由での分離には適しません。 　ただし、WPAR環境からグローバル環境へは基本的にアクセスできません。 WPARの適用にあたっては、利用方法の向き不向きをご参考にご検討下さい。

83 6) 使える仮想化機能 総復習 AME（Active Memory Expansion）

84 AMEとは

85 AME(Active Memory Expansion)概要
Active Memory Expansion(AME)とは ：メモリー上のデータを圧縮することで利用可能な メモリー・サイズを拡張する機能です。この機能により、OSは割り当てられた物理メモリー・サイズ以上の メモリー空間を利用できるようになります。 LPARで使用可能なメモリー LPARで使用可能なメモリー AME 物理メモリー 物理メモリー 拡張されたメモリー・サイズ

86 AME(Active Memory Expansion)概要
搭載物理メモリー・サイズが同じ筐体で、より多くのLPARを構成可能 各LPARへの物理メモリーの 割り当てを減らすことが可能 搭載物理メモリー 搭載物理メモリー LPAR LPAR LPAR LPAR LPAR LPAR AME LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR

87 AME(Active Memory Expansion)概要
AMEはLPARごとに設定が可能です。 −AMEを使用するLPARと使用しないLPARが同一の筐体内に共存できます。 −LPARでAMEを使用する/しないを切り替えるためにはLPARの再起動が必要です。 −メモリー専有LPAR およびメモリー共有LPAR（Active Memory Sharing）のどちらの環境でも 　AME を使用可能です。 −AME使用設定後の圧縮パラメーター（Memory Expansion Factor）はDLPARで動的に変更可能です。 AMEはOSおよびPOWER Hypervisorで制御します。 −メモリー・アクセスに応じてOS がメモリーを圧縮/展開します。 　・圧縮/展開にはCPUサイクルを使用します。 　・CPU使用率はワークロードにより変わります。 −pinされていないメモリー空間上のデータが圧縮の対象です。 −POWER7プロセッサーup + AIX 環境で使用可能です。 　・AIXはV6 TL04 SP02以降が前提です。

88 Memory Expansion Factor = 1.5 (50% Memory Expansion)
LPARに割り当てる実メモリー・サイズにMemory Expansion Factorを乗じた 値のメモリーがOSから利用可能になります。 （例）20GBの実メモリーを割り当てたAMEを使用可能なLPARでMemory Expansion Factorを 　　　1.5に指定した場合、OSからは20[GB] * 1.5 = 30[GB]のメモリーを使用可能になります。 LPARの割り当てメモリー Memory Expansion Factor = 1.5 (50% Memory Expansion) 非圧縮プール 圧縮プール LPARの実メモリー・サイズ 非圧縮プール 圧縮プール 300GB 200GB 圧縮/解凍

89 当セッションのまとめ 仮想化機能をぜひ、ご活用使ください！ PowerVM構成 ベスト・プラクティス 使える仮想化機能 総復習
LPM（Live Partition Mobility） 　メンテナンスが楽にできます。いつでもサーバー間でプロセッサー能力を調整できます。 PEP（Power Enterprise Pools） リソースを複数筐体間で自由に再配置できリソースを抑制できます。 WPAR（Workload Partitions ） １つのAIX上で複数おAIX区画を動作でき開発・テスト環境など手軽に環境を作れます。 Versioend WPARで古いOSを新しいハードウェア上で稼働させることが可能です。 AME（Active Memory Expansion） メモリーの圧縮拡張でより多くのLPARを構成可能です。 仮想化機能をぜひ、ご活用使ください！