Lessons Learned IBM PureApplication サマー・スクール 第３部 応用実践編：PureApplication Systemにおけるパターン開発と運用･管理 日本アイ・ビー・エム（株）ソフトウェア開発研究所
by user
Comments
Transcript
Lessons Learned IBM PureApplication サマー・スクール 第３部 応用実践編：PureApplication Systemにおけるパターン開発と運用･管理 日本アイ・ビー・エム（株）ソフトウェア開発研究所
IBM PureApplication サマー・スクール 第３部 応用実践編：PureApplication Systemにおけるパターン開発と運用･管理 Lessons Learned 日本アイ・ビー・エム（株）ソフトウェア開発研究所 上野 憲一郎 ([email protected]) © 2013 IBM Corporation Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エム システムズ・エ ンジニアリング株式会社の正式なレビューを受けておりません。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2013年07 月現在の情報であり、製品の新しいリリース、修正などによって動作／仕様が変わる 可能性があるのでご注意下さい。 PureApplication Summer School 2 © 2013 IBM Corporation 2 PureApplication System Lessons Learned 本セッションでは、2012年7月以降、日本において５台以上のIBM PureApplication Systemの導入～運用までを担当してきた経験をお話しいた します。 何が変わるの？ システム構築方法は？ 構成上の前提事項、制約は？ 3 © 2013 IBM Corporation 本セッションでは、2012年７月以降に日本において５台以上のIBM PureApplication Systemの導入から運用までを担当してきた経験をお話しいたし ます。 PureApplication Systemを利用すると、いままでと一体何が変わるの？ システム構築方法の違いはあるの？ PureApplication Systemの導入・システム構築をする上で前提事項や制約はある の？ といった疑問に対する回答を説明していきます。 3 Agenda 4 1. 担当エンジニアのロール 2. 物理的な作業は、コア・ネットワークへの接続のみ 3. ネットワーク技術者との入念な打ち合わせ実施が必須 4. DNSサーバの準備 5. NTPサーバの準備 6. SSHサーバ/SCPサーバ/HTTPサーバの準備 7. ログ保管用サーバの準備 8. MW Hypervisor Editionの設計と通常のMW設計の違い 9. PureApp管理者の責務 10. バックアップ・リストアのアプローチ 11. DNSエントリーの分離について 12. Cloud Group設計に際して 13. MW Hypervisor Edition vs. Core OS with MW まとめ © 2013 IBM Corporation 4 1. 担当エンジニアのロール PureAppの導入・システム設計・システム構築・運用といった各フェーズにお ける担当エンジニアのロールがユニーク 搬入前： 電源投入後： サービス担当エンジニアによるPoC実施 サービス担当エンジニアによる教育実施 プロジェクト開始後： 5 CE（カスタマーエンジニア）による、電源投入後のHW稼動確認 専門エンジニアによる、初期稼動確認・初期設定（ネットワーク設定）実施 初期設定後： プリセールス担当エンジニアによるネットワーク環境確認作業 お客様、サービス担当エンジニアによる設計、構築、運用 © 2013 IBM Corporation 以下の３ページにわたり、IBM PureApplication Systemを利用する場合の担当技 術者のロールについて説明します。 PureApplication Systemを利用する場合、物理的な機器搬入前、電源投入後、初 期設定後 といった順に必要となる技術的な作業および担当者が異なります。 「PureApplication Systemは機器設置から利用可能になるまでの作業時間が非常 に短い」という特性を有効にするため、機器搬入前に実施しておく作業がございま す。通常の機器搬入前の作業に加え、弊社プリセールス担当エンジニアとお客様 ネットワーク担当者の間でネットワーク環境に関して情報共有を行います。お客様 の協力が重要ですので、よろしくお願いいたします。 「機器搬入、設置」 、「開梱・取り付け」、「電源投入」は通常通りです。 「電源投入後」のHW確認（ハードウエアコンポーネントのアテンション・ランプなど の確認）をカスタマー・エンジニアが実施します。 その後、専門のエンジニアによって、初期稼動確認および初期設定（ネットワーク 設定、初期ユーザ登録、ライセンス確認など）を実施します。 ここまでの作業が終了すると、お客様ネットワーク経由でPureApplication System の管理コンソールへのアクセスが可能になります。 その後、PoCや教育といった支援をPureApplication担当エンジニアからお客様に ご提供するケースが多いです。 PoCや教育が完了すると、いよいよ、お客様・PureApplication担当エンジニア・プ ロジェクトメンバーなどによるシステム構築が本格的に開始となります。 5 1. 担当エンジニアのロール: メンテナンス作業につい て PureAppのメンテナンスの主担当は、IBMエンジニアが実施 管理ノードのソフトウェア障害時の修復作業 管理ノードのバックアップからのリストア作業 管理ノードに対するソフトウェア更新作業 ハードウェアに対するファームウエア更新作業 システム・アップサイズ（モデル変更）作業 ハードウェア障害時の修復・交換作業 問題判別に必要な詳細ログ取得作業 電源オフ/オン作業 サービス・ラップトップの利用 6 © 2013 IBM Corporation このスライドでは、PureApplication Systemのメンテナンス作業実施担当者につい て説明します。 PureApplication Systemの専門エンジニア、弊社カスタマー・エンジニアなどが、 以下に挙げるメンテナンス作業を担当します。お客様が担当される作業について は、次ページで説明します。 -PureApplication System 管理ノードのソフトウェア障害時の復旧作業 -PureApplication System 管理ノードの復元作業（バックアップからのリストア作 業） -PureApplication System 管理ノードに対するソフトウェア更新作業 -ハードウェアに対するファームウェア更新作業 -システム・アップサイズ（モデル変更）作業（ノード追加作業） -ハードウェア障害時の復旧・交換作業 -障害時の詳細ログ取得作業 -電源オフ・オン作業 -サービス・ラップトップを利用した各種メンテナンス作業 6 1. 担当エンジニアのロール: メンテナンス作業につい て(続き) お客様、サービス担当エンジニア VMに対するソフトウェア修正適用作業 仮想イメージ、パターン・タイプの更新作業 補足： ソフトウェア・メンテナンス（Fix Pack）は、２つの要素からなる システム・メンテナンス（管理ノードに対するソフトウェア修正）: IBM CEが作業実施 仮想イメージおよびパターン・タイプ: お客様が更新作業実施 7 © 2013 IBM Corporation 当ページでは、お客様（弊社エンジニア、パートナー様が代行する場合も含む）が 実施するメンテナンス作業について説明します。 お客様が担当される作業は以下のとおりです。 -各VMに対するソフトウェア修正の適用作業 -仮想イメージおよびパターン・タイプのカタログへの追加作業 以下に補足情報を説明します。 PureApplication Systemのソフトウェア・メンテナンス（更新）は、２つに大別できま す。 １つめが、管理ノードに対するソフトウェア更新です。こちらは、前スライドでも触れ ましたが、IBMカスタマー・エンジニアが作業を担当します。 ２つめが、「仮想イメージ（たとえば、WebSphere Application Server Hypervisor Editionの導入イメージ）」の更新と「パターン・タイプ」の更新です。これらは、お客 様がPureApplication Systemの管理コンソールあるいはCLIを利用して、 PureApplication Systemのカタログに対して登録・追加を行う作業です。 7 2. 物理的な作業は、コア・ネットワークへの接続のみ ハードウェアに対する物理的な作 業は不要 Top Of Rack スイッチの限定され たポートへの物理結線のみ 8 お客様ネットワークとの物理接続 のため V7000やシャーシ内ネットワーク・ スイッチなどの設定は不要 (事前設定済み) © 2013 IBM Corporation PureApplication Systemは、工場出荷時にハードウェアの各種設定やコンポーネ ント間のケーブルの接続を全て実施しております。したがいまして、お客様データ センターに搬入された後、電源ケーブルの接続を除くと、物理的にお客様が実施 すべき作業は、お客様ネットワークの対向スイッチ（コア・スイッチ）とのネットワーク 結線のみです。 仮想化されたシステム環境構築において、PureApplication Systemラックの上位 に設置されているネットワークスイッチ（Top Of Rackスイッチ）の特定ポートにネット ワークケーブルを接続するという非常に限定された物理的な作業のみが必要とされ ます。 このように、必要な作業は非常に限定されており、それによって、ITシステム構築作 業工数の大幅削減が実現できます。 8 3. ネットワーク技術者との入念な打ち合わせ実施が 必須 Top Of Rack (TOR)スイッチとお客様ネットワークスイッチの設定すり合わせ PureAppシステムコンソールによるTOR設定はシンプル 導入前にプリセールス・エンジニアを含め、ネットワーク専門家による接続性 に関するレビューが必須 TOR コア・ネットワーク Flow Control Mode: “Both receive and transmit flow control” VLAN Mode: “Tagging” Trunk Method: “LACP” Tag Default Port VLAN ID (tag-pvid):”Enabled” Port VLAN ID (PVID): 205 初期設定時に設定 9 © 2013 IBM Corporation 前ページで説明したように、システム構築に際して、お客様が実施する物理的な作 業は、コア・スイッチに対するケーブルの接続のみです。 そのコア・スイッチとの接続のために、PureApplication SystemのTop Of Rack (TOR)スイッチの設定内容について、お客様ネットワーク担当エンジニアと事前に 入念な打ち合わせを実施します。 スライドにTOR側の設定内容例を記しております。TOR側に、このような設定を実 施するのですが、設定を実施する前に、コア・スイッチ側との整合性を確認します。 弊社プリセールス担当エンジニアを含め、接続性の問題が無いように打ち合わせ を重ねてください。 なお、PureApplication System初期設定時の主な作業は、TOR設定です。 9 4. DNSサーバの準備 (必須) PureApp管理ノードからDNSサーバへアクセスができること デプロイされるVMに割り振られるIPアドレスおよび対応するホスト名の登録 PureApp管理ノード DNSサーバ 10.x.x.1 aaa 10.x.x.2 bbb 10.x.x.3 ccc 10.x.x.4 ddd VM 10 初期設定時に設定 © 2013 IBM Corporation PureApplication Systemの導入にあたり、PureApplication Systemラックの外（お 客様ネットワーク上）にDNSサーバを準備してください。このDNSサーバに対して、 PureApplication Systemの管理ノードからネットワーク接続ができるようにネット ワーク設計・設定を実施してください。 また、PureApplication System内にデプロイされたVMもDNSサーバを利用します。 従いまして、各VMからもDNSサーバに接続できるようにネットワーク設計・設定を実 施してください。 ただし、PureApplication System管理ノードが利用するDNSサーバとデプロイした VMが利用するDNSサーバは異なるDNSサーバであっても構いません。 異なる DNSサーバを利用する場合、管理ノードが利用するDNSサーバには、各VMにア サインされるIPアドレスおよびホスト名が登録されている必要がございます。 PureApplication System初期設定時にDNSサーバの登録を行います。 10 5. NTPサーバの準備 (必須) PureApp管理ノードからNTPサーバへアクセスができること デプロイされるVMは、PureApp管理ノード経由でNTPサーバと時刻同期 PureApp管理ノード NTPサーバ VM 初期設定時に設定 11 © 2013 IBM Corporation PureApplication Systemの導入にあたり、PureApplication Systemラックの外（お 客様ネットワーク上）にNTPサーバを準備してください。このNTPサーバに対して、 PureApplication Systemの管理ノードからネットワーク接続ができるようにネット ワーク設計・設定を実施してください。 なお、PureApplication System内にデプロイされたVMは、管理ノード経由でNTP サーバを利用します。 PureApplication System初期設定時にNTPサーバの登録を行います。 11 6. SSHサーバ/SCPサーバ/HTTPサーバの準備 (必須) PureApp管理ノードのバックアップ保存先 FixPack適用時に利用 PureApp管理ノードからのアクセスができること SSHサーバ/SCPサーバ/HTTPサーバ PureApp管理ノード Pure-appsys-x_1.1.0.0.ifp defaultdata • • • • • • • 仮想イメージ パターン・タイプ FixPack iFix eFix Script Package Pattern Back up 12 © 2013 IBM Corporation PureApplication System管理ノードのバックアップ取得時、および、FixPackの適 用作業実施時に、PureApplication Systemラックの外（お客様ネットワーク上）に SSHサーバ/SCPサーバ/HTTPサーバを準備してください。これらのサーバに対し て、PureApplication Systemの管理ノードからネットワーク接続ができるようにネット ワーク設計・設定を実施してください。 以下に上記サーバを必要とする主な作業を列挙します。 -仮想イメージのアップロード作業 -パターン・タイプのアップロード作業 -FixPack適用作業 -iFix適用作業 -eFix（緊急Fix）適用作業 -スクリプト・パッケージのアップロード作業 -パターンのバックアップ取得 -管理ノードのバックアップ取得 12 7. ログ保管用サーバの準備 System Console/Workload Console Log取得・保管に利用 ログのサイズが１回あたり数百MB～数GB PureApp管理ノードへのアクセスができること PureApp管理ノード • System Console Log • Workload Console Log 13 障害発生時に IBMサポートの 指示によりログを ダウンロード CLIを利用して 日次等でダウンロード するしくみを作成 Log保管用サーバ © 2013 IBM Corporation PureApplication System管理ノードから取得（ダウンロード）したSystem Console LogおよびWorkload Console Logを保管するためのサーバを準備してください。 これらのサーバから、PureApplication Systemの管理ノードに対してネットワーク 接続ができるようにネットワーク設計・設定を実施してください。 System Consoleから入手するログは、４GB以上のサイズになる場合がございます。 Workload Consoleから入手するログは、数百MB以上になる場合がございます。 これらのログは、障害発生時に解析部門が必要となります。 障害連絡の際に弊社 サポートに送付していただきますので、ログのダウンロード・保管を行うサーバには 必要十分なディスク容量をあらかじめ確保しておいてください。 13 8. MW Hypervisor Editionの設計と通常のMW設計の 違い Middleware Hypervisor Editionの場合、OS込みで導入（デプロイ） OSの設計を実施する場合は、試しにデプロイを行い、どういう設定で構成される かを確認する 構成内容を変更したい場合、 Script Packageを用意し、デプロイ時に変更 デプロイ終了後にシェルスクリプトなどを用いて変更 MW Hypervisor Edition付属のOS設計・設定変更の実施は、MW担当者の責 務か？ それとも、OS担当者の責務か？ 「ミドルウェア担当」、「OS担当」といった階層によって担当責務を決める？ 「VMデプロイ実施者が管理者」といったVM単位（仮想マシン単位）によって担当 責務を決める？ 14 © 2013 IBM Corporation PureApplication System では、Hypervisor Editionと呼ばれるOSとミドルウェアが一体となったミドルウェアの エディションを使用するケースが一般的です。 例えば、WebSphere Application Server Hypervisor Edition などです。 ここでは、通常のミドルウェアを用いた場合との違いについてお話します。 ミドルウェア環境構築を実施する場合、ミドルウェア導入を担当するエンジニアは、OSの設計を行なわない ケースがございます。その場合、OS設計とミドルウェア設計は個別に実施することになります。 Hypervisor Editionを使用してミドルウェア環境構築を実施する場合を考えてみます。 Hypervisor Editionの 場合、パターンのデプロイ時に指定できるOS関連のオプションは非常に限定されております。 OS設計を行な い、設計に合わせたOS設定を実施したい場合にはどうすればよいのでしょうか。 OS設定内容の変更を行う 方法として以下の2つが代表的です。 1.Script Packageを準備し、パターンのデプロイ時にScript Packageを使って設定変更を実施 2.パターンのデプロイ後、シェルスクリプトやOSコマンドを実行することにより設定変更を行う 上記のような方法で、OS設定変更を実施することが可能です。ただし、Hypervisor Editionによっては、設定変 更に制約がある場合もございますので、使用する Hypervisor Editionごとに確認するようにしてください。 次に、Hypervisor Editionを使用する場合の担当者の責務についてお話します。 我々が参加したプロジェクトでは、Hypervisor Editionに付属するOSについて、「ミドルウェア担当者が責任を 持つべき」か、あるいは、「OS担当者を別途アサインして責任を持ってもらうべき」かを議論しました。つまり、 「パターンを作成する人（VMを作成する人）が、そのVM全体について責任を持つ」というアイデアと、「OS担当 者・ミドルウェア担当者という切り口で責任範囲を分ける」というアイデアのどちらを採用すべきか を議論しまし た。 前者を選択した場合は、「ミドルウェア担当者は、OSの専門知識が不十分である可能性があり、責任が重過ぎ るのでは」という懸念が考えられます。 後者を選択した場合は、「OS担当者自身は、パターン設計・パターン のデプロイを実施していないので、どのような設計・設定かを知らないが、担当を引き受ける」という状況も考え られます。 どちらも、一長一短がありますので、実際には各プロジェクトごとに、参加メンバーのスキルや作業工数などを考 慮した上で決定することになるでしょう。 我々のプロジェクトでは、折衷案を採択しました。 PureApplication System以外にも多くのサーバを導入・構 築していたため、それらサーバのOS担当者に支援を受けながら、各VMの設計・デプロイを担当するミドルウェ ア担当者がOSに対する設定変更を検討しました。 14 9. PureApp管理者の責務 PureApp管理者の責務は？ PureAppラック内の全てに責任を持つ？ PureApp内で稼動するVMは、各VM担当者が責任を持つ？ PureApp管理ノードの責任のみ？ PureAppラック外のサーバを含む、全サーバのOS部分を誰が担当する？ PureAppラック外のサーバを含む、全ミドルウェア部分を誰が担当する？ 私たちのプロジェクトでは、以下のように分担 PureAppラック内にデプロイしたVMは、各VM担当者が責任者 ただし、PureApp管理者・他サーバのOS担当者が適宜、VM担当者を支援 15 © 2013 IBM Corporation PureApplication Systemの管理者 という新しいロールについて考えてみましょう。 一言で、「PureApplication System管理者」といっても、その責務が非常に幅が広 いため、全てに責任を持って担当するべきかどうか、検討が必要です。 以下に、想定されるPureApplication System管理者の責務範囲例を記します。 -ラック内の全てに責任を持つ -管理ノードのみ責任を持つ -VMは各VM担当者が責任を持つ -VMのOS部分はOS担当者が責任を持つ -VMのミドルウェアはミドルウェア担当者が責任を持つ 我々が参加したプロジェクトでは、各VM担当者にVMの責任を持ってもらい(パター ン設計、スクリプト・パッケージ設計・作成、パターンデプロイ、デプロイ後のVMのテ ストを含む)、それ以外のコンポーネントはPureApplication System管理者の責任 範囲としました。 というのも、VM上で稼動するミドルウェアに対する専門性が必要であったため、 PureApplication System管理者のスキルエリア、スキルレベルでは責任範囲に含 めるには十分とは言えなかったからです。 各プロジェクトごとに、メンバーのスキル、作業工数などに応じて、適切な責任範囲 というのを検討する必要がございます。 15 10. バックアップ・リストアのアプローチ 管理ノードのバックアップ・リストア 製品が提供している機能を利用 VMのバックアップ・リストア 要件の確認が必要 リストアの対象は、パターン全体？特定のVMのみ？ バックアップ取得のタイミングは？バックアップ保管は何世代？ スナップショットからのリストアは、仮想システムパターンのみ パターン全体のスナップショット・リストアは最新世代のみ データのバックアップ？システムのバックアップ？ログのバックアップ？ 例： z z 16 データのバックアップ取得は、TSMを利用 システムのバックアップ取得は、スナップショットを利用 © 2013 IBM Corporation PureApplication Systemを使用するにあたり、バックアップおよびリストアに関する検討も 非常に重要な項目です。 我々が参加したプロジェクトにおいて、バックアップ・リストアについて何度と無く議論しまし た。 その際に、特に注意が必要だった点は、バックアップ・リストアの対象は何か です。 議論のたびに、一体どの対象について検討しているのか を再確認しながら検討を進めま した。 具体的には、「管理ノード」についての検討なのか、「VM」についての検討なのか。 VMについての検討の場合、データのバックアップ・リストアについての議論なのか、システ ム全体のバックアップ・リストアについての議論なのか です。 「管理ノード」のバックアップ・リストアの場合は、PureApplication Systemが提供している 機能を利用します。 「VM」のバックアップ・リストアの場合は、パターンの設計も含めて検討が必要です。 以下 に検討項目を記します。 -リストアの方法は、「スナップショットからのリストア」なのか、「パターンの再デプロイによる再 構築」なのか。 スナップショットからリストア可能なパターンは、仮想システムパターンのみ。 -リストアの対象は、「パターン全体」なのか、「特定のVM」なのか。 スナップショットからのリ ストアは、REST APIを利用すればパターン単位でのリストアも可能。GUIによるスナップ ショット・リストアは、パターン全体のリストアのみ。 -バックアップ取得のタイミングはいつなのか。パターンのデプロイ直後なのか。随時なのか。 -バックアップの保管は何世代必要なのか。 パターン単位でのスナップショット・リストは最 新世代のみ可能。 -データのバックアップなのか。システム全体のバックアップなのか。ログのバックアップなの か。 例えば、データのバックアップ取得はTSMを利用し、システムのバックアップ取得はス ナップショットを利用する など。 16 11. DNSエントリーの分離について 各IPグループで異なるDNSを指定する。 その際、各DNSに含まれるエントリーは重複しない。 管理ノードが利用するDNSには、各IPグループが利用するDNSのエントリーをす べて包含している必要がある IP Group: Test_IP_Group DNS: 9.2.1.1 9.2.1.a 9.2.1.b 9.2.1.c aaa.test.ibm.com bbb.test.ibm.com ccc.test.ibm.com IP Group: Service_IP_Group DNS: 9.3.1.1 9.3.1.x xxx.service.ibm.com 9.3.1.y yyy.service.ibm.com 9.3.1.z zzz.service.ibm.com 管理ノード用DNS: 9.1.1.1 9.2.1.a 9.2.1.b 9.2.1.c 9.3.1.x 9.3.1.y 9.3.1.z 17 aaa.test.ibm.com bbb.test.ibm.com ccc.test.ibm.com xxx.service.ibm.com yyy.service.ibm.com zzz.service.ibm.com © 2013 IBM Corporation DNSサーバの準備が必須であることは既にお話したとおりです。 ここでは、DNS サーバに登録するエントリーについての留意点をお話しいたします。 本番環境のVMが利用するDNSとテスト環境のVMが利用するDNSを分離したいと いうお客様要件を考えてみます。 具体的には、「テスト環境のVMが参照するDNS サーバには、セキュリティを考慮して、本番環境のVMに関するエントリは登録しな い」という要件です。 その場合は、同様に、「本番環境のVMが参照するDNSサーバには、テスト環境の VMに関するエントリは登録しない」という要件も想定できます。 上記の要件を満たす場合の設定を具体的に検討します。 1.テスト環境用のVMが属するIPグループ（Test_IP_Group）のDNS設定として、 DNSサーバ 9.2.1.1 を指定。 DNSサーバ（9.2.1.1）には、VMに割りあてる想定の 9.2.1.x のIPアドレスおよびそれに対するホスト名を登録します。 2.本番環境用のVMが属するIPグループ(Service_IP_Group)のDNS設定として、 DNSサーバ 9.3.1.1 を指定。 DNSサーバ(9.3.1.1)には、VMに割りあてる想定の 9.3.1.x のIPアドレスおよびそれに対するホスト名を登録します。 3.管理ノードに設定するDNS設定として、DNSサーバ 9.1.1.1 を指定。 DNSサー バ（9.1.1.1）には、9.2.1.x のIPアドレスおよびそれに対するホスト名を登録し、さら に、9.3.1.x のIPアドレスおよびそれに対するホスト名を登録します。 管理ノードがアクセスするDNSサーバは、各IPグループで使用する想定のVM用IP アドレスおよびそれに対するホスト名を全て包含している必要がございます。 17 12. Cloud Group設計に際して 特に、Smallモデルなどのコンピュートノードが少ないケースにおいて、Cloud Groupを１つにするか、複数にするか、重要な検討ポイント 例： 本番環境専用に１ラックを用意、テスト環境用に１ラックを別途用意 ただし、テスト環境用ラックには、複数のテスト環境を構築予定 テスト環境で想定しているテストシナリオは？ テスト環境と本番環境との設定・構成の違いはどこまで許容されるのか？ 18 性能テスト？障害テスト？ Cloud Groupを複数？１つ？ Cloud Groupの可用性は？ 可用性の設定によりVMの配置可能数が異なる Cloud Group内に登録されているコンピュートノード数 Cloud Groupのタイプは同一にしないと負荷テストの結果に差異が生じる © 2013 IBM Corporation Cloud Groupの設計・設定については、別のセッションで詳しく説明をいたしました。 ここでは、テスト環境と本番環境で、別々のラックを使用するケースでの留意点をお 話します。 本番環境用のラックは1つの本番環境専用という位置づけであるのに対して、テスト 環境用のラックは複数のテスト環境を構築するというケースを考えてみます。 その場合、以下のような項目を確認します。 まず、どのようなテストシナリオをテスト 環境で実施する想定なのでしょうか。 性能テストを実施する予定ですか？ 障害 テストを実施する予定ですか？ また、構成はどうなっているか確認します。 Cloud Groupの設定はどうでしょうか。 可用性のオプションを使用しますか？ Cloud Groupはいくつ構成する予定です か？ 上記のような項目についてどのような想定をしているのでしょうか。 それらの質問・ 確認する意図は、「本番環境の設定・構成とテスト環境の設定・構成に違いがあると すると、どこまで違いを許容できるのでしょうか」という点を確認したいからです。 Cloud Groupに含まれるコンピュートノードの数が異なれば、性能テストの結果が 異なるのは容易に想像がつきます。 Cloud Groupのタイプが本番環境とテスト環境 で異なる場合も（例えば、本番環境は Dedicated タイプだけど、テスト環境は Averageタイプ）、テスト環境で性能テストを行った結果は、本番環境と異なる結果 になります。 障害テストをテスト環境で実施する場合、可用性設定がオフの場合はコンピュート ノード障害テストシナリオ（特定のノードを停止するなど）を実施することができませ ん。つまり、停止するノード上で稼働中のVMを移動する先が無いため、VMを稼動 し続けることができないからです。 仮に本番用ラックと同じモデルのラックをテスト用 に用意した場合でも、上記のような制約が発生しますので留意が必要になります。 18 13. MW Hypervisor Edition vs. Core OS with MW PureAppがサポートする各種ミドルウェア（Hypervisor Edition）は、稼動に必 要なソフトウェアコンポーネントを導入済み Hypervisor Edition以外のミドルウェアをPureApp上で稼動させる場合、Core OSと呼ばれる仮想OSをデプロイ、その後、各種ソフトウェアを導入 Core OS上には限定されたRPMパッケージのみが導入済み 各種ソフトウェアを導入するために前提となるRPMが不足している場合、 19 インターネットに接続できる場合は、Red Hat社からダウンロード インターネットに接続できない場合は、 IBMサポートに提供を依頼 © 2013 IBM Corporation このスライドでは、PureApplication Systemで稼動するミドルウェアについて説明し ます。 WebSphere Application Serverの場合は、WebSphere Application Server Hypervisor Editionと呼ばれるエディションがPureApplication Systemに同梱され ております。 WebSphere Application Server Hypervisor Editionは、 WebSphere Application Serverおよび前提となるソフトウェアコンポーネントを含 んだ仮想OSとして提供されます。 PureApp Intel版の場合は、Redhat Enterprise Linux 上に各種RPMおよびWebSphere Application Serverが導入さ れております。 従いまして、WebSphere Application Server Hypervisor Editionを使ったパター ンをデプロイした場合には、追加ソフトウェアの導入なしで、WebSphere Application Serverを利用できます。 それに対して、Hypervisor Editionが提供されていないミドルウェアをPure App上 で稼動させる場合には、Core OSと呼ばれる仮想OS (PureApp Intel版の場合は、 Redhat Enterprise Linuxのみが含まれます)をデプロイし、その後、必要となる各 種ソフトウェアを導入することで該当のミドルウェアを稼動させることが可能です。 Core OSは、限定されたRPMパッケージが事前に導入されています。 必要に応 じて、弊社サポートに問い合わせを行っていただき、追加のRPMパッケージを弊社 サポート経由で入手可能か相談されるとよいでしょう。 インターネットに接続できる 場合には、Red Hat社からダウンロードすることも可能です。 19 まとめ いくつかのプロジェクトでPureAppを使ってきた感想として、前述のような Lessons Learnedを踏まえ、プロジェクト・ライフサイクル全体を通してPureApp 利用のメリットを享受可能と言える 設計 調達 導入 設計 調達 導入 システムセットアップ … クラウド環境構築、拡張が容易 統合＆構成 テスト 使用開始 アプリケーション稼働環境構築 … 容易なイメージの個別作成、パターン作成 クリックして Deploy 仮想OSの構築 ….アプリケーション稼働環境のデプロイが容易 ファームウエア 更新半自動化 20 システム監視 1-Clickで ノード追加可能 統合＆構成 テスト 使用開始 保守、運用 … 半自動化されたファームウエア更新 、 事前構成済み監視基盤、容易なノード追加 © 2013 IBM Corporation 最後に、我々が複数のお客様および社内システムへの導入・システム設計・パター ン設計・パターンデプロイ・運用設計・運用といった作業に携わってきた感想を述べ させていただきます。 １つのラックに、ネットワーク機器・ストレージ機器・システム管理ノード・アプリケー ション稼動ノードなどの複数ハードウェアコンポーネントが搭載されており、ラックの 搬入後、数時間でシステムが利用可能になるという「システムセットアップ時間の大 幅削減」のメリットは、ハードウェア納入からシステム管理サーバ構築までを実際に 体験しているエンジニアの方々には実感していただけると確信しております。シス テム基盤設計やOS/ミドルウェア設計および導入までの莫大な時間をパターンとい う考え方を用いることにより大幅に削減することが可能となります。また、パターンの 再利用性により、ミドルウェア設計を標準化することができ、品質向上にも貢献でき ます。 システム保守・運用という観点では、ラックに含まれる全てのハードウェアのファーム ウェア更新作業も半自動化されており、非常に少ないステップで実施できるため、 日ごろ、ファームウェア更新作業を手がけているエンジニアの方からは非常に評価 されております。 ノード追加によるシステム増強についても、通常では事前に十分 な時間をかけて作業計画をたて、システム停止時間を最小限にするようにしたり、 物理的な追加作業後の仮想化環境への組み込み作業などが必要になります。 PureApplication Systemでは、システム停止を伴わず、かつ、物理的な追加作業 後は１クリックで仮想化環境に組み込めます。 我々は、導入から保守・運用までの多岐にわたり、PureApplication System利用 によるメリットを体験してきました。 皆様も、ぜひ、PureApplication Systemを活用 し、新しい考え方に基づいたITシステム構築を実践していきましょう。 20 ITを、もっと手早くカンタンに。 21 © 2013 IBM Corporation