jp.redhat.com

facebook.com/redhatjapan @redhatjapan

linkedin.com/company/red-hat

IT 最適化は ハイパーコンバージェンスの

実現へ向けた 全体的な過程の最初の一歩で、

COTS フレームワークおよび ソフトウェア中心アーキテクチャ内の

コンピュート、ストレージ、ネットワーク、 仮想化のリソースを統合します。

長年にわたり Red Hat とインテルは、

インテル・アーキテクチャ・ プラットフォーム上で実行される

Red Hat Enterprise Linux の パフォーマンス、信頼性、セキュリティ、

および効果性を最適化するため、 コラボレーションしてきました。

目次IT 最適化のための移行パスの開発 ..................................................................................................2移行のメリット .......................................................................................................................................... 2

移行パス ..................................................................................................................................................... 2

アジャイルな IT を実現する準備 ........................................................................................................... 3

概要：X86 アーキテクチャへの移行 .................................................................................................4新しいインフラストラクチャへの移行対象とするアプリケーションの評価 .................................. 4

現サーバーの負荷の評価 ........................................................................................................................ 4

パイロット導入に適した要素の特定 ..................................................................................................... 5

概念実証 (PoC) アプローチの開発 ....................................................................................................... 5

ソリューション・アーキテクチャの再評価 ............................................................................................ 6

移行のリハーサルの実行 ......................................................................................................................... 6

実稼働環境へのデプロイの開始 ........................................................................................................... 6

次のステップ .............................................................................................................................................. 7

UNIX から LINUX へのアプリケーション移行 ................................................................................7移行の対象範囲 ........................................................................................................................................ 7

移行の検討事項 ........................................................................................................................................ 8

移行する理由 ............................................................................................................................................. 8

一般的な移行シナリオ ............................................................................................................................ 8

移行のデプロイシナリオ ...................................................................................................................11統合 ............................................................................................................................................................. 11

分散 .............................................................................................................................................................12

移行を成功させるためのベストプラクティス .................................................................................13環境移行に関する一般的なガイドライン ............................................................................................13

標準運用環境の構築 ..........................................................................................................................14コンポーネントのプロビジョニング .......................................................................................................15

Red Hat Satellite の概要 ........................................................................................................................16

戦略的プランニングロードマップの作成 ........................................................................................17既存ハードウェアの統合分析 .................................................................................................................17

統合デプロイのシナリオと仮想化分析 .................................................................................................17

高レベルのハードウェア再デプロイの分析 .........................................................................................18

統合リスク分析とリスク緩和計画の更新 .............................................................................................19

トレーニング計画の作成 .........................................................................................................................19

大規模で複雑なアプリケーションの詳細分析 (任意) .......................................................................19

コストの見積もり ......................................................................................................................................19

移行のマスターロードマップの作成 .....................................................................................................20

最適な Intel® Xeon® プロセッサーベース・サーバーの選定 ...........................................................20

RED HAT IT モダナイゼーション・プロセスの継続 ....................................................................... 20

RED HAT の移行サービス .................................................................................................................21

インテルのリソースとサービス .........................................................................................................21

技術詳細

オープン・プラットフォームへの移行ガイド 2018

2jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

IT 最適化のための移行パスの開発テクノロジーのイノベーションは、企業による価値創出と事業成長の原動力として、企業の成功を支えています。高コストで非効率な従来の IT インフラストラクチャはイノベーションを阻害し、継続的な保守上の困難を伴い、ハードウェアとソフトウェア両方のコンポーネントが古くなるにつれて、サポート終了に伴う重大な懸念が生じます。

移行のメリット長期的な移行とモダナイゼーションの計画を策定する間、短期的には従来の IT インフラストラクチャが必要になることもありますが、次のような移行ステップを実行するとメリットを得られます。

• プロプライエタリー・オペレーティングシステム (OS) から Red Hat® Enterprise Linux® に移行する

• Intel® アーキテクチャベースのハードウェアに基づく基盤を採用する

この基本的な移行パスに従うとビジネス価値の目覚ましい強化が迅速に実現し、資本コスト (CAPEX)

と運用コスト (OPEX) の両方が節約されます。高価なプロプライエタリー・ライセンス契約を廃止して、Red Hat が提供する予測可能でコスト効果の高いサブスクリプションモデルに移行すると、OPEX が大幅に削減されます。プロプライエタリー・システムを Intel 搭載の商用 COTS サーバーに置き換えることで、CAPEX も削減されます。スケーラブルで高性能な計算能力と、高い仮想マシン密度を達成する容量を備え、IT リソースを最大限に活用できます。Red Hat® Virtualization を Intel® プロセッサーベースのサーバーと組み合わせると、IT リソースをすばやく柔軟に利用でき、プロプライエタリーなシステムよりもコストは大幅に低下します。

Red Hat とインテルが共同開発した標準ベースのハードウェアおよびソフトウェアのフレームワークにより、リファレンスアーキテクチャ上でテストおよび検証済みの、コミュニティによるソリューションの幅広いエコシステムを利用できます。モダナイゼーション業務の進展を計画している企業は、Red Hat のスケーラブルな管理プラットフォームと相互運用可能なソリューションを活用できます。サーバー数と管理者の人数の比率が改善され、物理、仮想、クラウドのワークロードに対して一元化された管理コンソールにアクセスできるため、スタッフの効率性も飛躍的に向上します。IT 最適化はハイパーコンバージェンスの実現へ向けた全体的な過程の最初の一歩で、COTS フレームワークおよびソフトウェア中心アーキテクチャ内のコンピュート、ストレージ、ネットワーク、仮想化のリソースを統合します。

移行パス本ガイドで取り上げる一般的な移行パスには、次の 4 つの基本ステップがあります。

1. 計画：プロプライエタリー・システムからインテルと Red Hat のオープン・プラットフォームに移行するワークロードを決定します。

2. 変換：移行に備えて必要なコード移植とデータ変換を実施し、その他のサードパーティ・ライブラリやミドルウェアを新しい環境に用意する必要があるかどうか検討します。

3. ハードウェアの構成：予想されるワークロードのサポートに最適な、インテル・アーキテクチャベースのハードウェア構成を決定します。

1 「現在 『インターネットを利用しない』というポリシーの企業が稀なのと同じように、2020 年までには『クラウドを利用しない』というポリシーの企業は稀になると Gartner 社は述べています」Gartner Newsroom、2016 年。 http://www.gartner.com/newsroom/id/3354117

3jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

4. デプロイ：新しいハードウェアへのデプロイを、一連の段階的な手順で完了します。大半のデプロイには、以下の移行段階が必要です。

• 概念検証 (PoC)

• パイロット移行

• リハーサル

• 実稼働開始

実際に必要となるステップはホストされる環境に依存し、個々の状況によって異なります。図 1 に、移行業務に含まれる代表的なアプリケーションに適用される、基本的なステップを示します。

環境1. プロジェクト・プランニング

2. コード変換

3. PoC

4. ソリューション・アーキテクチャ

5. パイロット移行

6. リハーサル移行

7. 実稼働移行

インフラストラクチャ

リモートオフィス/小売コンピューティング

ビジネスクリティカルな COTS アプリケーション

ビジネスクリティカルなカスタム・アプリケーション

図 1. 移行の手法と手順

アジャイルな IT を実現する準備従来のプロプライエタリーな IT 環境から先進的でアジャイルなプラットフォームに移行するには、プロセスの各段階で膨大な量の判断を下すことになります。多くの IT 責任者、CTO、IT 部門のメンバーが、UNIX* から Linux への移行 (U2L) や、縮小命令セットコンピュータ (RISC) アーキテクチャからオープンソース・ソフトウェア・スタックをホストする Intel アーキテクチャベースの標準高ボリュームサーバー

(SHVS) への移行によって達成が見込まれる、ビジネス上のメリットを理解しています。しかし、プロプライエタリー・プラットフォームからオープン・プラットフォームへの移行に関わる個々のステップは、複雑で面倒なものです。入念な計画と専門家による助言があれば、潜在的な失敗を避けられ、このタイプの移行について実績のあるベストプラクティスに合わせられます。

アナリスト会社では IT インフラストラクチャを戦略的にアップグレードするプロセスを、さまざまな用語で表現していますが、その概念は基本的に同一です。IDC Gartner ではバイモーダル1という用語を使用して、2 つの IT デリバリーのモードを表現しています。1 つは安定性、もう 1 つはアジリティを目的としたモードです。IDC はこの段階的アップグレードを、プラットフォームを第 1 段階、第 2 段階、第 3 段階と進化させていくプロセスとして捉えています2。第 3 段階のプラットフォーム は完全なデジタル・トランスフォーメーションとクラウドネイティブ・アプリケーションに基づいたものになります。

1 「Gartner IT Glossary」、Gartner、2017 年。https://www.gartner.com/it-glossary/bimodal/

2 「The Shift to the 3rd Platform」、IDC、2017 年。https://www.redhat.com/cms/managed-files/cl-shift-to-third-platform-idc-analyst-infographic-f9614-201710-en.pdf

4jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

重要な点は、デジタル・トランスフォーメーションを行うからといって、最初からビジネス全体をクラウドに移行する必要はないということです。多数の企業にとって考えられる最初のステップは、ビジネス業務を実行するサーバーを SHVS に、OS 環境を Red Hat Enterprise Linux にオンプレミスでアップグレードすることです。この最適化されたインフラストラクチャを稼働させたときから、ビジネス上のメリットがもたらされます。

RISC から Intel アーキテクチャへの移行と UNIX から Red Hat Enterprise Linux への移行による総所有コスト (TCO) と投資回収率 (ROI) の分析が Alinean によって実施されており、その結果は移行に伴うコスト面のメリットを裏付けています。この分析結果については後述します。

組織のデータセンターの最適化およびモダナイズにおけるインテルと Red Hat の提携の価値について詳細を知るには、ホワイトペーパー「Alleviate technical debt」をダウンロードしてご確認ください。インテルと Red Hat による革新的 IT ソリューション共同開発の取り組みの詳細については、ストラテジックアライアンスに関するこちらの Web ページでご覧いただけます。

概要：X86 アーキテクチャへの移行x86 ベースのインフラストラクチャへの移行を成功させるには、ベストプラクティスに基づいて入念に練られた系統的なアプローチが必要です。状況は事例ごとにすべて異なりますが、IT マネージャーがデプロイを計画する際に、最も重要な検討事項と推奨事項の概要を以下のステップにまとめました。この計画プロセスは本書の後半で詳細に説明します。

新しいインフラストラクチャへの移行対象とするアプリケーションの評価まず現在使用中の UNIX 環境を評価する時間を設け、Red Hat Enterprise Linux エコシステムで利用できる同等の機能を特定します。この際は、サードパーティ製のビジネスアプリケーションも評価の対象として含めたうえで、Red Hat Enterprise Linux エコシステムで利用できる同等機能のほか、移行に伴うリスク要因も特定します。この段階では、Red Hat Enterprise Linux への移行に関して、包括的なロードマップとコスト評価を含む戦略的な移行プランを作成します。

Red Hat では、以下の十分にテストされたプロセスを推奨しています。このプロセスでは、移行によるメリットが期待できる要素を特定し、さまざまな移行シナリオに伴うリスクを確認し、標準的なエンタープライズビルドを作成し、エンタープライズ向けの包括的な戦略的移行プランを作成します。

• 既存の UNIX アーキテクチャを確認し、Red Hat Enterprise Linux エコシステムにおける同等機能を見つける

• サードパーティ製の機能的アプリおよびビジネス・アプリケーションを確認し、Red Hat Enterprise

Linux エコシステムにおける同等機能を特定する

• 組織の準備状況と全体的な移行リスクを評価する

• 詳細なロードマップおよびコスト見積もりを含め、UNIX から Red Hat Enterprise Linux への戦略的な移行プランを策定する

• 戦略的な移行プランを実行に移し、実行をサポートする戦略を実施する

現サーバーの負荷の評価選択したアプリケーション移行の計画が固まったら、サーバーの負荷を入念に評価し、PoC テストに適した構成を決定します。事前にサーバーをサイジングしておくと、処理されるワークロードに適する構成を指定しやすくなります。別のアーキテクチャに移行すると、アプリケーションのパフォーマンスが大きく変わる場合がありますが、類似したプラットフォームでパフォーマンスをテストすることで、パフォーマンスの正確な予想が可能となります。この段階で必要なのは、テスト要件をサポートするための見積もりのみです。実稼働サーバーのサイジングに必要な詳細情報は、実際の PoC から得られます。

「2016 年 8 月に

IDC が実施した 5 年間の

ROI 分析によって、

調査対象の Red Hat

Enterprise Linux と

Red Hat Satellite の

顧客の ROI は 373% に達し、平均して 5 カ月で投資を回収できることが

わかりました」

AL GILLEN、MATTHEW MARDEN 2016 年 9 月3

3 「Red Hat インフラストラクチャソリューションによる標準化がもたらす価値」IDC、2016 年。 https://www.redhat.com/ja/resources/value-of-standardizing-red-hat-infrastructure-solutions

5jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

テストサーバーのメモリーおよびディスク容量はかなり簡単な方法で決定できますが、実装は元のシステムとはまったく異なることが予測されます。これは、元のシステムと比べて優れたコンピュートリソースの可用性や、より幅広い機能が提供されるためです。テストサーバーに最適なプロセッサーを選択することもまた、配慮すべき重要事項です。プラットフォーム移行が完了した後に予期されるワークロードを考慮しながら、適切なコア、スレッド、キャッシュ、およびクロックサイクルあたりの命令の数、その他のプロセッサーの仕様を決定します。この作業には、大半の UNIX オペレーティングシステムに付属しているパフォーマンス監視ツールを使うと便利です。

パイロット導入に適した要素の特定パイロットによって、移行業務を効果的にサポートする運用環境を構築するための基本的なパラメーターが確立されます。現在のビジネス要件に基づき、最初の移行対象として最適で、理想的には迅速な成果へとつながるアプリケーションを特定します。最初の移行対象にはシンプルでわかりやすいアプリケーションを選びがちですが、この方法では継続的な移行業務の重要性を事業部門に納得させるために必要な、戦略的な牽引力を得られません。移行対象としては、これまで積極的に先進的テクノロジーを取り入れ、変化を受け入れてきた事業部門が適しているでしょう。

概念実証 (POC) アプローチの開発移行が複雑な場合やビジネスクリティカルな場合は必ず PoC を実施して、アプリケーションが新しい環境で実行できるか検証し、予測されるワークロードでパフォーマンスがどのようになるか確認します。また、PoC を行うことで、構成の最適化によりパフォーマンスを最大化し、実際の移行の準備プロセスを確立するための最適な方法を特定する助けとなります。

PoC の実施手順は次のとおりです。

• 移行テストのために必要な準備を行ったことを確認する

• 該当する事業部門のメンバーがテストの監督に参加できることを確認する

• テスト移行に使用されるサーバーとデータベースの物理的な位置を確認する

• 移行先のハードウェアにおけるアプリケーションのパフォーマンスをテストするための準備を整える

• 移行中はアプリケーションへの一切の変更を禁止する

この段階では、サーバーのサイジングとアプリケーションのスケーリングを綿密に評価しておくと、PoC

の価値をより高めることができます。サーバー・プラットフォームの選択とサイジングに影響する要因には、以下のものがあります。

• 平均使用率の初期評価値

• 最大使用率の目標

• 需要のピーク

• ワークロード成長率の予測

• 2 ソケットおよび 4 ソケットサーバーの相対容量

• サービスレベル契約 (SLA) 要件を満たすためにどの程度アプリケーションのスケーリングが必要かの検討

• クラスタ、障害復旧、フェイルオーバーなど、高度な考慮事項

PoC の実施方法については、ホワイトペーパー「Migration from UNIX/RISC and Mainframe to

Intel-based Solutions」をご覧ください。

6jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

ソリューション・アーキテクチャの再評価PoC を完了すると、新しい環境への移行対象として選択したアプリケーションをハードウェアで効率的に実行でき、SLA に準拠できるという保証が得られます。この時点で、スケーラビリティや可用性を含む幅広い問題について、ソリューションを再評価することをお勧めします。評価すべき主な問題には、以下のものがあります。

堅牢なハードウェア：大半の移行では、古い機器を新しく堅牢なハードウェアに置き換えるだけで、パフォーマンスとスケーラビリティのほか、信頼性、可用性、サービス可能性 (RAS) が自動的に得られます。電源、ディスクドライブ、ファンなど、冗長コンポーネントを新しいシステムに構成すると、これらに加えてさらにメリットを得られます。ビジネスクリティカル・アプリケーションに高レベルの信頼性と最高のパフォーマンスを求める場合は、Intel® Xeon® プロセッサー・スケーラブル・ファミリーは、高度な RAS 機能と卓越した高可用性を備えています。このファミリーのプロセッサーは、高レベルのコンピュート密度も実現し、大量のワークロードに対応するよう拡張できます。組み込みプロセッサーのアーキテクチャが強化され、ハイパフォーマンス・コンピューティング (HPC) ワークロードの処理が向上します。

クラスタリング：移行された環境内でのエラーの影響を縮小するため、高可用性クラスタリング・ソフトウェアを使用します。このソフトウェアは、Red Hat Enterprise Linux 7 High Availability Add-On から利用できます。このアドオンには、さまざまな構成をサポートするコンポーネントのセットが統合されており、パフォーマンス、高可用性、負荷分散、スケーラビリティ、ファイル共有、コスト効果の計測を支援します。クラスタリングとは、障害が発生した場合にメインサーバーの任務を引き継ぐべき冗長サーバーを指定します。フェイルオーバーは即時ではありませんが、自動的に行われます。クラスタリング・ソフトウェアによって、障害による全体的なシステム可用性への影響が限定的になります。

水平方向のスケーリング：水平方向のスケーリングは、個々のサーバーの大規模化ではなく、サーバーの増設によってワークロードの増加に対処します。プレゼンテーション層のサービスはワークロードの分散を通じて複数のサーバーにスケーリングするため、これらのサービスに対してはこのアプローチが有効です。あるサーバーで障害が発生すると、ワークロードは残りのサーバーに自動的にフェイルオーバーし、高可用性と柔軟なスケーラビリティを提供します。自動プロビジョニングとメンテナンスツールを追加すると、ソリューションを拡張してもオーバーヘッドの管理を抑制できます。

垂直方向のスケーリング：垂直方向にスケーリングされたアーキテクチャ内のアプリケーションは、1 台のサーバー上にあります。ワークロードが増加した場合、パフォーマンスはサーバーへのリソース追加や大規模なシステムへのアップグレードで拡張します。垂直方向のスケーリングで使用するには、高度なスケーラビリティを必要とする、成熟したアプリケーションまたは単機能アプリケーションが適しています。

移行のリハーサルの実行新しいソリューションへの切り替えを確実に成功させるには、入念な準備が必要です。リハーサル移行によって、パイロット移行に使用したプロセスを改善して、効率を最大化するよう最適化できます。プロセスの評価と整理、必要なプロセスを自動化するスクリプトの開発、データ移行手順の綿密な調査により、実稼働環境のスムーズな移行を確実にするための知識と経験を手に入れられます。関連する手順を文書化し、ソリューションの品質保証 (QA) と受け入れテストを実施します。リハーサル移行は、先に進んでも問題ないという確信が得られるまで繰り返すことが重要です。

実稼働環境へのデプロイの開始この時点までで、新しいソリューションと移行プロセスへの全面的な信頼が築けているはずです。

• リハーサルの際に作成した文書を使用し、詳細なプロジェクト計画を作成する

• 最適なメンテナンス期間をスケジュールし、影響を受けるすべての事業部門に通知する

• ターゲットサーバーを再ビルドし、移行前に行うべきすべての手順を完了させる

• リハーサルに従って、実稼働環境の移行を実施する

7jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

• QA および受け入れテストを実行する

• 切り替えるか、承認が得られるまで並行して実行する

• 完了した各ステップを文書化する

次のステップ以降のセクションでは、コアアプリケーションを UNIX 環境から Red Hat Enterprise Linux ベースの環境移行する際のステップについて、さらに詳しく説明します。IT 最適化において最も一般的な移行シナリオと、特定のタイプのアプリケーション移行に関連する難易度を説明します。

UNIX から LINUX へのアプリケーションの移行本セクションおよび以降のセクションで取り上げるシナリオでは、AIX*、Solaris*、HP-UX* 環境などで構成される汎用 UNIX アーキテクチャから Red Hat Enterprise Linux エコシステムへの移行を取り上げます。その他のさまざまな移行シナリオに対応するドキュメントおよびコンサルティングご用意しております。Red Hat にお問い合わせください。

移行の対象範囲移行作業を成功させるには、新しいプラットフォームに移行するアプリケーションのタイプ、コードとデータを変換する相対的な難易度、予定されている Linux 環境のホストに最適なハードウェア・プラットフォームを考慮する必要があります。各種のアプリケーション移行の難易度の比較を図 2 に示します。

インフラストラクチャ・ アプリケーション

リモートオフィス/小売 コンピューティング・ アプリケーション

ビジネスクリティカルな COTS アプリケーション

ビジネスクリティカルな カスタム・アプリケーション

コード/データ変換 コード変換は不要 または少量

複雑性は アプリケーションによって

異なる低い複雑性 中程度の複雑性

ダウンタイム/停止 ほぼ影響なし制御またはスケジュール

可能ダウンタイムの影響を

受ける ダウンタイムの影響を受ける

環境全体に複製 複製が容易 パイロットの後に複製該当するアプリケーションに応じて、容易から中程度

該当するアプリケーションに応じて、中程度から複雑

コストとリスク 低コストと低リスクで 高価値

コストとリスクを負担中程度のリスクとコスト、 再コーディングの複雑性 やアプリケーションの

置換に依存

アプリケーション再作成の 専門知識の有無によって、 コストとリスクが大きくなる

可能性あり

例DNS サーバー、LDAP サーバー、Web サーバー、ファイアウォール、バックアップと復元、ファイルとプリント

リモートオフィス、銀行の 支店、小売店舗などの複数の場所で実行されるビジネスアプリケーション

SAP*、Oracle eBusiness Suite*、関連するデータベースなど、リホスティング・コア・ビジネス・アプリ

ケーション

1 つのビジネスの固有のプロセスをサポートするために作成されたアプリケーション (多くの

場合 C++、C、Java)

図 2. 各種のアプリケーションの移行の難易度

シンプル 複雑移行のしやすさ

8jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

移行対象のアプリケーションによって、ハードウェア・プラットフォームの構成は異なります。たとえば、マルチスレッドを利用しない古いアプリケーションを移行する場合、新しいプラットフォームは必ずしも多数のコアを備えたプロセッサー構成でなくてもかまいません。分析とビッグデータを重視するビジネスの場合、新しいプラットフォームには大量のメモリーと柔軟なソフトウェア・デファインド・ストレージが必要となることがあります。特定のシングルスレッド・ビジネス・アプリケーションのパフォーマンス強化が最優先となる場合は、使用できるコアの総数よりも、プロセッサーのクロック周波数とアクセラレーター・ツールのほうが重要になるでしょう。言い換えると、ハードウェア要件と、選択するコードおよびデータの変換手法は、ビジネスで使用するソフトウェアの性質、機能、要求によって決まります。

移行の検討事項U2L 移行計画を評価するには、IT メンバーと意思決定者は、なぜ移行が必要なのかという、動機の部分をよく検討すべきです。これらの要因は、移行の計画プロセスを支える戦略に影響を与え、移行の可能性、選択肢、および潜在的なトレードオフに影響します。さらに重要なことに、移行を進めるよりも前に、選択可能な移行のタイプと、潜在的なデプロイシナリオを理解しておく必要があります。これらの要素は、移行の計画プロセスのあらゆる側面に影響を及ぼします。

移行する理由UNIX から Red Hat Enterprise Linux に移行する場合、代表的な動機として以下の要因が挙げられます。

• ハードウェア購入、ソフトウェアのライセンスおよび保守コスト、OS サポート、システム管理、消費電力に関わるコストを削減する

• リース期限を迎えたサーバーを置き換える

• 厳格な予算制限に従いながら拡大するビジネス要件に対処する

• サポートが終了したハードウェアとソフトウェアを置き換える

• サーバー、アプリケーション、データセンターの資産を統合する

• 仮想化などの新しいテクノロジーを使用する

• キャパシティ・プランニングとパフォーマンスを改善する • セキュリティと安定性を向上させる

多くの場合、これらの要因が複数組み合わさって OS 移行の最終決定へとつながります。1 つの動機だけではコストに見合わなくても、いくつかのビジネス目的が組み合わされば移行に対する十分な理由となり得ます。一方で、大幅なコスト削減が見込める場合は、その 1 つの要因だけで移行の決め手となることもあるでしょう。しかし組織は将来を見据えて、柔軟な標準ベースの IT インフラストラクチャを確立し、迅速な成長と先進的で高度なテクノロジーをサポートすることの価値を検討すべきです。

一般的な移行シナリオOS を移行する場合は常に、複数の移行シナリオを綿密に検討したうえで計画を練り、移行を成功に導く必要があります。このセクションではこのような主要なシナリオの概要を、最も簡単なものから最も複雑なものへと順に説明していきます。

UNIX インフラストラクチャ・アプリケーションから Red Hat Enterprise Linux インフラストラクチャ・アプリケーションへの移行比較的一般的なシナリオで、最もシンプルな移行パスの 1 つは、UNIX 上の外部インフラストラクチャ・アプリケーションを、Red Hat Enterprise Linux で実行する同等のインフラストラクチャ・アプリケーションに移行するものです (図 3 を参照)。たとえば、Veritas NetBackup* または IBM Spectrum

Protect を UNIX で実行している顧客は、移行後も同じ実行方法を続けたいと考えます。

9jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

組み込み機能から組み込み機能への移行このシナリオでは、UNIX に組み込まれた機能が Red Hat Enterprise Linux に組み込まれた機能と同一または類似しています (図 4 を参照)。機能が両方のオペレーティングシステムの部分で同一の働きをする場合 (Sendmail や NTP など)、移行に対する障壁はあったとしてもごくわずかです。

Red Hat Enterprise Linux インフラストラクチャ・アプリケーション

Red Hat Enterprise Linux

UNIXインフラストラクチャ・アプリケーション

UNIX

図 3. アプリケーション・インフラストラクチャの移行

Red HatEnterprise Linux

組み込み機能 組み込み機能

UNIX

図 4. 組み込み機能がある移行

その他のインフラストラクチャの可能性その他のインフラストラクチャ移行の可能性として、以下のものが考えられます。

• UNIX 機能から Red Hat Enterprise Linux インフラストラクチャ・アプリケーションへの移行：UNIX に存在する組み込み機能が、Red Hat Enterprise Linux には存在しない場合もあります。このシナリオにおいて、Red Hat Enterprise Linux 環境で同じ機能を実現するには、インフラストラクチャ・アプリケーションの追加が必要になることがあります。

• UNIX インフラストラクチャ・アプリケーションから Red Hat Enterprise Linux 組み込み機能への移行：この移行シナリオでは、UNIX 環境内で必要とされていた UNIX インフラストラクチャ・アプリケーションが、同等の組み込み機能を有する Red Hat Enterprise Linux では不要となります。たとえば、Red Hat Enterprise Linux 7 には ID 管理機能が搭載されているため、AIX ではユーザーの一元管理に PowerBroker は不要です。Red Hat Enterprise Linux サブスクリプションには多種多様な機能が初めから含まれているため、多くの場合は大幅なコスト削減につながります。

10jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

オフィスおよびビジネスクリティカル・アプリケーションの移行移行計画の観点から、企業内で使用されているビジネス・アプリケーションは、大きく次の 3 種類のカテゴリに分類できます。

• 独立系ソフトウェアベンダー (ISV) が開発してサポートする、リモートオフィスおよび小売アプリケーション

• 各種のオペレーティングシステムと互換性のあるバージョンがあることが多い、COTS アプリケーション

• 通常はインハウスで開発され、長年にわたって使用されてきたカスタム・アプリケーション

UNIX 上のコア・ビジネス・アプリケーションを Red Hat Enterprise Linux 上の同一または類似のアプリケーションに移行する場合 (図 5 を参照)、難易度は個々の状況に応じて異なります。選択肢としては、以下が挙げられます。

• Red Hat Enterprise Linux で実行される同等のアプリケーションを見つけ、データファイルを新しい環境に移行する

• Red Hat Enterprise Linux で実行するコア・ビジネス・アプリケーションのすべてまたは部分を移植、変換、再コンパイルする

• 必要なプログラミングを実施して、Red Hat Enterprise Linux 上で元のカスタム・アプリケーションの機能を維持する

前述の図 2 のように、移行対象が基本のオフィス・アプリケーションから COTS やビジネスクリティカル・アプリケーションになるにつれ、移行の複雑性は増していきます。

同等または Red Hat Enterprise Linux 向けに移植/コーディング

されたカスタム・アプリケーション

Red Hat Enterprise Linux

UNIXリモートオフィスまたはクリティカルなアプリケーション

(COTS またはカスタム)

UNIX

図 5. オフィスアプリケーションとクリティカルなアプリケーションの移行

カスタム・ビジネスクリティカル・アプリケーションは、開発段階でクロスプラットフォームの互換性に特別な注意を払っていなければ、一般には最も困難な状況を呈します。アプリケーションを Linux 環境に移行する際に従うべきベストプラクティスの詳細は、「移行を成功させるためのベストプラクティス」のセクションをご覧ください。

11jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

移行のデプロイシナリオサーバーワークロードのデプロイで取りうるシナリオを理解し、OS プラットフォーム移行の計画を立てると、新しい環境に最適なエンタープライズ・アーキテクチャを開発でき、移行による設備コストを節約できます。

以降のセクションでは、統合と分散という 2 つのシナリオについて説明します。この他にも集約とクラウド移行という 2つのシナリオがありますが、本書ではこれらは取り上げません。この後者の 2 つのアプローチについては、Red Hat 移行サービスで詳細な情報を提供します。

統合使用率の低い IBM Power* または System p5* システムを少数の x86 ベースシステムに統合すると、データセンターの占有面積を減少させ、ハードウェアの運用コストを低下できます。仮想化を活用すると、Red Hat Enterprise Linux を実行する仮想マシンに個々のワークロードを収容し、コンピュートリソースの使用率と運用管理を改善できます。図 6 に統合デプロイシナリオの例を示します。

Red Hat Enterprise Linux/x86

Red Hat Enterprise Linux/x86

IBM Power 570 IBM Power 570 IBM Power 570

IBM Power 570 IBM Power 570 IBM Power 570

IBM Power 570 IBM Power 570 IBM Power 570

図 6. 統合デプロイのシナリオ

表 1. 統合のメリットとデメリット

メリット デメリット

ハードウェアの運用コストが削減される システム管理タスクが複雑化する

データセンターの占有面積が縮小する プロプライエタリーな仮想化テクノロジーを使用する シナリオで設備コストが増加する

選択した仮想化戦略からの投資収益率が高まる

OS とアプリケーションの間にハイパーバイザーというレイヤーが追加されるので、パフォーマンスにある程度の影響が及ぶ

動的なリソース割り当てと負荷分散をサポートする

12jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

分散このシナリオでは、図 7 に示すように、1 つ以上の Power または System p システムのワークロードを、Red Hat Enterprise Linux を実行する少数の X86 ベースシステムに分散します。これは、IT リソースの多くを Red Hat Enterprise Linux 環境へ移行しようとする企業がよく採用するシナリオでもあります。

ハードウェアリソースを複数のデータセンターの少数のユニットに分散し、スケーリングできます。これまではこのシナリオでは 1U から 4U の独立したラックマウントシステムが一般的でしたが、近年ではブレードの使用が増加しています。ブレードサーバーからは、低い運用コストで同様の利点を得られます。

Red Hat Enterprise Linux

/x86

Red Hat Enterprise Linux

/x86

Red Hat Enterprise Linux

/x86

Red Hat Enterprise Linux

/x86

IBM Power 595

図 7. 分散デプロイのシナリオ

表 2. 分散のメリットとデメリット

メリット デメリット

新しい x86 ハードウェア・テクノロジーでパフォーマンスが向上する

適切に計画しないと運用コストが高まる可能性がある

ハードウェアリソースをスケーリングして設備コストを削減する

資産が適切に最適化されていないと、ワークロードとリソースの使用率が不十分になるリスクが生じる

リソースを再デプロイすると柔軟性が向上する

13jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

移行を成功させるためのベストプラクティス

このセクションでは、前述の図 1 で説明した環境に基づいて、典型的な移行作業で発生する各段階について詳しく説明します。

環境移行に関する一般的なガイドラインプラットフォーム移行を処理するための基本ガイドラインを、最もシンプルな環境から最も複雑な環境の順に並べました。

インフラストラクチャ・アプリケーションこのカテゴリの代表的なアプリケーションの例としては、DNS、LDAP、Web サーバー、ファイアウォール、バックアップと復元ユーティリティ、ファイルおよびプリント・アプリケーションが含まれます。

多くの場合、この環境のアプリケーションは両方のアーキテクチャでネイティブに実行するバージョンがあるので、変換の必要性はあまりありません。また、即座に切り替えられるので、一般に長時間のダウンタイムは発生しません。初期移行に続き、企業全体でプロセスを繰り返すことで、低コストかつ低リスクで優れた価値を実現できます。

リモートオフィスと小売コンピューティング・アプリケーションこのカテゴリの代表的なアプリケーションの例には、リモートオフィス、銀行の支店、小売店舗などの複数の場所で実行されるビジネスアプリケーションが挙げられます。

企業が同じアプリケーションをリモートオフィスや小売店舗などの複数の場所で実行する場合、移行によるコストとリスクはすべてのアプリケーション移行に分散されます。IT チームは 1 回のパイロット移行をうまく完了して実装を最適化して、その後移行プロセスをエンタープライズサーバーに複製できます。

ソリューションスタックの複雑性に応じて、このプロセスのコストとリスクは異なります。ただし、同じソフトウェアスタックがすべての場所で使用されている場合は、後続の移行はシンプルで低リスクになり、移行による総価値は高くなります。

市販の商用アプリケーションこのカテゴリの代表的なアプリケーション例には、SAP*、Oracle eBusiness Suite*、関連するデータベースなど、リホスティング・コア・ビジネス・アプリケーションがあります。

COTS アプリケーションはデータベースレイヤー、アプリケーション・レイヤー、Web サービスレイヤーなどの複数のレイヤーにまたがることが多いので、このタイプの移行の複雑性は高くなります。同じシナリオで、3 つのすべてのレイヤーを大規模な UNIX/RISC サーバーのパーティションでホストすることもできます。その他の場合では、Web またはアプリケーション・レイヤーがインテル・プロセッサーベースのプラットフォームですでにホストされていることがあります。複数レイヤーを移行する場合、移行を段階的に実施することでリスクを低減でき、 移行時に発生する問題の特定と解決が簡単になります。

アプリケーションがインテルアーキテクチャでネイティブに実行されない場合は、コード変換が必要です。ただし、シェルスクリプトとカスタムコードの要素も変換する必要があります。Red Hat では、大規模アプリケーション移行とモダナイゼーションに役立つアプリケーション移行ツールキットを提供しています。

最初に要件の詳細な評価を実施し、その後コード変換を行います。移行の実現可能性を検証するため、ソリューションを構築する前にスケーラビリティと高可用性の PoC を完了します。現実的な実稼働ワークロードに合わせてソリューションをサイジングして、移行のリハーサルを行ってワークフローを最適化します。

この環境には、共通する以下の 3 つのシナリオがあります。

• ソフトウェアを変更せずにアプリケーションスタックをリホストする：この場合、転送が必要になるのはエンタープライズ固有のデータのみで、プロセスが単純化されます。

14jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

• ソフトウェアバージョンを変更してアプリケーションスタックをリホストする：旧バージョンの

Oracle を現在のバージョンに移行する場合などが該当します。このような場合は可変要素がさらに増えるため、複雑性も増加します。新しいバージョンの移行ツールは、古いバージョンでは使用できないことがあります。新しいバージョンで正常に実行させるには、いくらかのコーディングが必要になる場合があります。移行プロセスを円滑に進めるには、必要に応じて経験のある移行コンサルタントに相談してください。

• 大規模なアップグレードを必要とするアプリケーションスタックをリホストする：これには、ソフトウェア・アプリケーションまたは関連したデータベースの変更が伴う場合が該当します。ソフトウェアスタックをアップグレードすると、複数の変更が同時に発生するため、発生した問題の特定が困難になります。この問題を最小限に抑えるには、移行プロセスを独立した手順へと分解します。たとえば、既存のアプリケーション層を移行してから、データベースを移行します。

ビジネスクリティカルなカスタム・アプリケーションこのカテゴリの代表的なアプリケーション例には、1 つのビジネス固有のプロセスをサポートするために作成されたアプリケーションがあり、多くの場合、C++、C、Java* で作成されています。

この移行作業は、大規模なコード変換が必要になるため、複雑なものとなります。評価時に、ソースコード、移植ツール、ライブラリ、ドキュメント、知識のある開発者の有無を検討してください。コード変換にかかる時間と作業量は、コードベースのサイズによって大きく異なります。自動化ツールを使用すると、特に UNIX/RISC 環境からコードを移植するときに、難易度を軽減できます。それでも一般には手動のコーディングが必要で、機能の安定性とパフォーマンスを確認する徹底的なテストも必要になります。コードが先進的で、きちんと作成され、十分に文書化されていると、カスタム・アプリケーションの移行が円滑に進みます。古いカスタム・アプリケーションのほうが、一般には難易度が高くなります。というのも、文書化が不十分でパッチが多く、モノリシックな場合があるためです。

メインフレーム・アプリケーションの移行メインフレーム・アプリケーションの移行は、多くの場合、比較的シンプルです。たとえば、SAP などのベンダーアプリケーションや、Oracle Database* や IBM DB2* などのベンダーデータベースの移行は、かなりシンプルです。その他の状況では、特にメインフレーム上で実行するアプリケーションに相互依存関係がある場合では、複数のアプリケーションとデータセットを同時に移行する必要があり、そのために複雑性が増加します。

何年にもわたって、メインフレームの Intel プロセッサーベースのプラットフォームへの移行が行われてきました。ツール、専門知識、時間をかけてテストしたプロセスを活用すると、このような移行のコスト、作業量、リスクを最小化できます。このタイプの移行の主要組織による成功例については、ホワイトペーパー「ReHosting Mainframe Applications on Intel® Xeon® Processor-Based Servers」をご覧ください。

標準運用環境の構築標準運用環境 (SOE) は、組織でのコア OS の標準実装です。ベース OS、カスタム構成、組織で使用される標準アプリケーション、ソフトウェアアップデート、サービスパックが含まれます。

アプリケーションセットを特定したら、SOE のアプローチに基づいて標準化されたビルドを作成し、一貫性のあるデプロイを迅速に行えるようになります。SOE ビルドは、テスト済みのハードウェア、テスト済みのソフトウェア、Red Hat Enterprise Linux 上にデプロイされた構成のセットで構成されます。SOE

ビルドは関連する技術的およびビジネス上の要件と完全に適合しているので、デプロイ時間が大幅に短縮され、メンテナンスが単純化され、安定性が向上し、サポートおよび管理コストが削減されます。

15jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

コンポーネントのプロビジョニング標準ハードウェアがまだ定義されていない場合、SOE ビルドは現行の企業標準ハードウェア上に構築することができます。ベアメタルから完全に構成された SOE ビルドまで、システムのプロビジョニングは Red Hat Satellite のプロビジョニング機能によって実行されます。

プロビジョニングには表 3 に示すコンポーネントが使用されます。

表 3. コンポーネントのプロビジョニング

構成のプロビジョニング

インストール手法

ソフトウェアパッケージ

セキュリティ、認証、ストレージ、およびその他の要件に従った構成

テストサーバーセットアップのプロビジョニング

デプロイのテスト

ポリシーおよび構成への準拠

デリバリーとトレーニングSOE ビルドのデプロイと修正について顧客の IT スタッフをトレーニングする

その他の顧客ニーズがあれば対処する

その他のトレーニングを推奨する

結果SOE ビルドが顧客の要件を満たす

提供される文書：

実施した作業の詳細リスト

今後の拡張または成長の推奨など、特定の手順

製品固有のマニュアルへのリンク

完全にテストされたプロビジョニングサーバーとプロビジョニング設定ファイル

テスト済みの正確な手法で、リソースが解放される

16jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

RED HAT SATELLITE の概要図 8 に、Red Hat Satellite が SOE ビルドを管理するプロセスを示します。

RED HAT SATELLITE

リージョン 1

カプセル 1

RED HAT ポータル PUPPET DOCKER GIT SCAP カスタムコンテンツ

リージョン 2

カプセル 2

リージョン 3

カプセル 3

リージョン N

カプセル N

Red HatAnalytics

組織 1

組織 2

組織 N

オペレーター

ライフサイクル管理

Red Hat Network Satellite カプセルサービス

管理対象ホストVMwareRed HatVirtualizationOpenStack®

KVMEC2GCERackspaceベアメタルDocker

図 8. Red Hat Satellite による運用環境ビルドの管理

17jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

戦略的プランニングロードマップの作成戦略的移行プランニングプロセスのこの段階で中心となるのは、これまで収集して分析したすべての情報を、包括的な戦略的プランニングロードマップへとまとめる作業です。

戦略的プランニングロードマップを作成するには、以下の手順に従います。

• 資産のインベントリーをコンパイルする

• 既存ハードウェアの詳細な分析を実行する

• デプロイと仮想化の統合プランの分析を完成させる

• 高レベルのハードウェア再デプロイの分析を実行する

• 統合リスク分析とリスク緩和計画を作成する

• トレーニング計画を作成する

• 大規模で複雑なアプリケーションを詳細分析する (任意)

• コストを詳細に見積もる

• 移行のマスターロードマップを作成する

既存ハードウェアの統合分析戦略的移行ロードマップを作成する最初のステップは、新しいプラットフォームに移行するアプリケーションをサポートする、既存ハードウェアの詳細分析を実行することです。まず、機能アプリケーションの分析に基づいてハードウェア環境データを収集します。これには各アプリケーションについて、以下のような開発、テスト、ステージング、デプロイ環境のデータを追跡する作業が含まれます。

• ホストあたりのホスト数とプロセッサーコア数

• メモリー要件

• ストレージおよびファイルシステムの要件

• ネットワーク帯域幅とレイテンシーの要件

ここでの目的は、リホストするアプリケーションセット全体を実行するために必要となる処理能力、メモリー、ストレージ、帯域幅を把握することです。このような統合的な視点からのデータでは一般に、実際にアプリケーションセットを実行するために必要な量よりはるかに多くのリソースがあることが明らかになります。これは、データセンター環境では通常、使用率が低いためです。

統合デプロイのシナリオと仮想化分析移行の対象のアプリケーションに対する集約リソースのニーズを確認した後、同じ統合の視点から、アプリケーションデプロイのシナリオを検討します。この検討で、共通のデプロイシナリオ要件を持つアプリケーショングループを作成するフレームワークが提供され、このグループでの仮想化に基づくコスト節約のチャンスを見極める情報が得られます。

このステップで、移行対象のアプリケーションが新しいサーバー環境にどのように対応するか、統一されたビューが提供されます。

最初に、先に説明した希望するアプリケーションのデプロイシナリオに基づいて、既存のアプリケーションの依存関係を考慮しながら、アプリケーションのデプロイグループを作成します。この結果、統合または分散という、1 つまたは 2 つのグループにアプリケーションが分類されます。

18jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

グループ化のデータが確定したら、各グループについてターゲットとなるハードウェア・プロファイルを指定します。このとき一般には、IBM、Dell、HP、Cisco などの OEM パートナーとの連携が行われます。移行対象のアプリケーションを対応させる、少数の共通システムアーキテクチャを作成するためです。移行の利点とプロセスの例の一覧をご覧ください。

基本的な目標は、標準化によってハードウェアの調達および管理コストを削減するため、作成する共通システム・デプロイ・アーキテクチャの数をできるだけ少なくすることです。通常は、デプロイグループごとに少なくとも 1 つのシステムアーキテクチャがありますが、必須というわけではありません。一部の組織は、デプロイシナリオにかかわらず、すべての移行されたアプリケーションに対して 1 つのデプロイアーキテクチャで標準化しています。

次に、作成したグループ化に基づいておおまかな仮想化分析を実行します。このステップは必須ではありませんが、仮想化に関する組織のポリシーによっては強く推奨されます。仮想化分析で、既存の各アプリケーションデプロイについて、以下のような要因を調べます。

• アプリケーションの SLA

• 平均およびピーク時のハードウェア使用率 (プロセッサーコア、メモリー、ディスク、帯域幅)

• どのアプリケーションがどのデータセンターにあるかを決める、アプリケーションの物理的な位置

• 仮想化の制限 (ISV サポートと法令およびコンプライアンスの問題を考慮する)

• 運用タイプ (開発、テスト、実稼働を含む)

• セキュリティおよびネットワークのセグメント化 (各アプリケーションが存在する物理的なセキュリティゾーンを確立する)

• 高可用性および 障害復旧の要件

• クラスタリングの要件または制限

• 特殊なハードウェア要件 (Storage Area Network (SAN)、InfiniBand*、その他のハードウェアを含む)

• 電力および冷却の要件

これらの要因によって、どのアプリケーションを仮想化でき、どれを仮想化できないかが決まり、仮想化アプリケーション・インスタンスを同じ物理マシンでホストできるかどうかも決まります。この分析の最終結果は、デプロイと仮想化のマップで、特定の仮想化アプリケーション・インスタンスと特定の物理マシン・システム・アーキテクチャとの対応を示します。

高レベルのハードウェア再デプロイの分析移行されたアプリケーションをどのようにデプロイするか、移行チームが確認しだい、アプリケーションが現在実行されているハードウェアのサブセットを再デプロイする機会を検討します。この活動によって、移行コストの一部を打ち消すことができる可能性が生まれます。たとえば、中規模の IBM Power または System p マシンで実行されるデータベース・インスタンスのセットで、Red Hat

Enterprise Linux x86 環境に移行できるものが存在する場合があります。このとき、既存の Power または System p マシンを、この時点で移行されていないより大規模な既存のデータベースクラスタに再デプロイすることができます。Red Hat Enterprise Linux への移行による主なコスト削減は、高額な

Power および System p ボックス数を減らすことで実現できることを考えると、このプロセスは異例に思われます。しかし、経験によって、サーバーの再デプロイによって多額のコストが節約されることがわかっています。特に、再デプロイされたハードウェアがサポート終了などの理由で購入できなくなったが、特定のビジネスクリティカルなアプリケーションを実行するにはそのハードウェアがまだ必要である場合に効果的です。

この再デプロイによって、新しいハードウェアのコストを増やすことなく容量を増加でき、移行の総コストの見積もりがさらに削減されます。

19jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

統合リスク分析とリスク緩和計画の更新このステップでは、移行チームは、移行プランニングプロセスの前段階で特定した、リスク要因の組み合わせを検討します。この段階の最初の 3 つのステップで特定した、新しいリスクに対して、さらに検討します。

この分析で、移行に影響を及ぼす可能性がある、これまで不明だったリスクの組み合わせを洗い出します。たとえば、このプロセスの早期段階で、機能アプリケーション分析フェーズの計画中 (マクロレベルの難易度分析) に特定された大規模で複雑性の高いアプリケーションを移行すると決めたとします。この推奨は、調査したリスクに基づいており、準備およびリスク分析フェーズで、リスクに見合うと判断された移行戦略が作成されます。しかし、統合デプロイシナリオを検討した後、このアプリケーションの仮想化に他のリスクがあると気が付きます。そこで、リスク移行計画を更新して、この新しいリスクに対処します。

また、このような新しいリスク要因と移行戦略に基づいて、移行の対象とするアプリケーションのリストを更新する必要があります。この移行マスターリストをコストの詳細見積もりステップで使用します。

トレーニング計画の作成移行の対象とするアプリケーションを特定し、最適な物理デプロイアーキテクチャを決定し、組織の準備レベルを準備およびリスク分析フェーズで把握したところで、次のステップは、最終的なトレーニング計画をまとめることです。

このステップの目標は、トレーニングを受ける必要があるスタッフと、必要なトレーニング・カリキュラムを特定することです。Red Hat Enterprise Linux トレーニングが追加されることはほぼ確実ですが、他のベンダーからの他の ISV ソフトウェア・トレーニングと OEM ハードウェア・トレーニングも必要となる可能性があります。スタッフは一般に受講できるクラスルームでのトレーニングに参加できますが、固有のニーズに応じてオンサイトで実施することもできます。カスタマイズした一連のワークショップも利用でき、オンサイトで実施して既存のコース内容ではカバーされていないテーマを扱えます。

大規模で複雑なアプリケーションの詳細分析 (任意)この時点で再度、機能アプリケーション分析フェーズのマクロレベルの難易度分析ステップで特定した、大規模で複雑なアプリケーションのリストを見直すことをお勧めします。これらのアプリケーションは、移行の範囲やコストに関して、不確実性が非常に高いレベルになる傾向があります。これらのアプリケーションを詳細に検討し、次のステップであるコストの詳細見積もりに進む前に、移行コストを十分に把握しておくことが、多くの場合に役立ちます。ただし、これは任意のステップであるため、実施するかどうかはケースバイケースでの判断が推奨されます。

コストの見積もり移行全体のコストの詳細見積もりを算定するために必要なすべての情報が揃ったので、このステップでは、以下の直接コストと削減額を合算して、最終的な移行予算の見積もりを算出します。

• 既存の AIX 環境と同等の Red Hat Enterprise Linux 環境を作成するために必要な新しいインフラストラクチャ ISV アプリケーションのコスト

• Red Hat Enterprise Linux にはない既存の AIX アプリケーションの置換に必要な、新しい ISV 機能アプリケーションのコスト

• 各移行のデプロイアーキテクチャの実装に必要な、新しいインテル・アーキテクチャ・ベースのハードウェアのコスト

• アプリケーションの移行コスト

• トレーニングコスト

• プロプライエタリー ISV アプリケーションの排除とオープンソース・アプリケーションとの置換による削減

• 再デプロイされたハードウェアによる削減

20jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

これは見積もりに過ぎないことに注意してください。実際のアプリケーション移行コストとは異なる場合があります。これを ROI または TCO 分析とは捉えないでください。移行しない場合の将来のハードウェア置換コストなどの間接費の削減や運用コストの削減を含んでいないからです。

移行のマスターロードマップの作成最後のステップでは、移行のマスターロードマップ (MMR) を、これまでの 7 つのステップからの結果を使用して作成します。MMR は移行をいつ、どこで、どのように実行するかを示す、プロジェクト計画の働きをします。

まず、特定のシステムとアプリケーション移行を分析して優先順位を付けます。優先順位の関連性の要因には、設備予算の割り当てのタイミング、特定のビジネスの優先度、データセンターの制約があります。これらの要因は通常、特定の組織に依存するので、前もって包括的な要因のリストを作成しておくのは困難です。

移行の優先度が決定すると、実際のプロジェクトのスケジュールが作成され、移行を成功させるために必要な各タスクに固有の日付と所要期間が示されます。このスケジュールは、四半期ごとの IT 予算に対する特定の設備費と運用コストに適合し、移行の支出が常に予算内に収まるようにします。

最終結果は、評価時に収集した情報を利用した移行戦略文書と、タスク、日付、費用を特定したプロジェクト計画です。

最適な INTEL® XEON® プロセッサーベース・サーバーの選定大規模データベース、コア・トランザクション・アプリケーション、ビジネス・インテリジェンス・ソリューションなどの、ビジネスクリティカルなエンタープライズ・ワークロードは、Intel® Xeon® スケーラブル・プロセッサーに基づくサーバーへの移行が可能です。このプロセッサーは、ワークロード最適化機能を搭載し、最新のハイブリッドクラウド・インフラストラクチャと高度な RAS 機能をサポートし、サーバーの稼働時間を 99.999% にまで最大化して、パフォーマンスを平均 1.65 倍にまで向上させます。4このプロセッサー・ファミリーは動的なサービス提供に調整され、分析、人工知能、HPC、ネットワーク変換など、要件の厳しいアプリケーションに最適です。

RED HAT IT モダナイゼーション・プロセスの継続最適化された IT インフラストラクチャを構築すると、組織には次のようなさまざまなメリットが即座にもたらされます。

• 容易にスケーリングしてシステム需要に対応する

• 新しいサービスの提供を迅速化する

• セルフサービス・ポータルを作成してカスタマーエクスペリエンスを改善する

• メンテナンスおよび管理要件を軽減する

• データストレージ費用を削減する

• ハードウェアおよびソフトウェアの費用を削減する

先進的な Intel アーキテクチャベースのハードウェア・プラットフォームで Red Hat Enterprise Linux を実行する環境を確立すると、多様なツール、ソリューション、コンポーネントの導入と統合によって IT モダナイゼーションの推進を継続し、アジリティ、弾力性、自動化、スケーラビリティを向上するための助けとなります。オプションとしては、仮想化ソリューション、ソフトウェア・デファインド・ストレージ、ソフトウェア・デファインド・インフラストラクチャ、管理アプリケーション、生産性向上ツールなどが利用できます。

21jp.redhat.com 技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン

図 9 に示すように、IT モダナイゼーションが進むにつれて仮想化環境から移行し、プライベートクラウドおよびパブリッククラウドのメリットを享受できるようになり、動的なリソース分散、IT 構成の単純化など、多数のメリットが実現します。

物理 仮想 プライベートクラウド パブリッククラウド

図 9. Intel® アーキテクチャ基盤に基づく Red Hat IT モダナイゼーションの過程

さまざまな大企業がデジタル・トランスフォーメーションを推進する流れが、IT インフラの広範なイノベーションへとつながったことで、企業はテクノロジーの進化とオープンスタンダードやオープンソースのメリットを活用できるようになりました。長年にわたり Red Hat とインテルは、インテル・アーキテクチャ・プラットフォーム上で実行される Red Hat Enterprise Linux のパフォーマンス、信頼性、セキュリティ、および効果性を最適化するため、コラボレーションしてきました。両社によって開発されたリファレンスアーキテクチャから、最も需要の高いエンタープライズ・ワークロードも処理できる、確実で安定した IT インフラストラクチャが生まれました。たとえば、Dell、Red Hat、インテルの共同作業により、Intel® Open Network Platform が提供するリファレンスアーキテクチャを使用して、最新のソフトウェア・デファインド・ネットワークとネットワーク機能仮想化 (NFV) コンポーネントのデプロイが簡単になります。フレームワークとしてテストアーキテクチャを利用できることが、ソフトウェア・アプリケーションの開発とデプロイの時間を短縮する主な要因です。

RED HAT の移行サービスRed Hat コンサルティングでは、Red Hat Enterprise Linux への移行の計画と実行を支援するサービスを提供しています。Red Hat® コンサルタントは実地の経験を積んだ Linux 熟練者で、移行のプランニングや Red Hat Enterprise Linux の新しいデプロイを行う貴社のスタッフにアドバイスします。Red Hat には、世界中の金融サービス、医療、通信の大手企業および政府機関との提携業務の経験があります。早い段階でコンサルタントと提携することで、移行のベストプラクティスについて重要な知見を得られ、移行に伴うコスト削減や効率の最大化、実稼働までの期間短縮、ROI の迅速な創出に役立ちます。

詳細については、redhat.com/ja/services/consulting をご覧ください。

インテルのリソースとサービスインテルとそのパートナーは、企業が UNIX/RISC からインテル・アーキテクチャ・インフラストラクチャ上の Linux に移行して、TCO を削減して柔軟性とアジリティを向上し、変化するビジネスニーズに対応できるよう支援します。Red Hat とインテルが共同開発した高度なテクノロジーは、先進的な IT インフラストラクチャの利点を求める企業によるデジタル・トランスフォーメーション業務を成功させます。ソフトウェア・デファインド・インフラストラクチャの革新的な開発により、ビジネスチャンスが新たな領域にまで拡大され、効率的なリソース使用、要求駆動型の動的な再構成、流動的なスケーラビリティを主な目的として、変化するワークロードに対応します。

IT リーダー向けのその他のリソースについては、インテルの New Center of Possibility にアクセスしてください。

jp.redhat.com INC0658210_v1_0218

Copyright © 2019 Red Hat, Inc. Red Hat、Red Hat Enterprise Linux、Shadowman ロゴ、および JBoss は、米国およびその他の国における Red Hat, Inc. またはその子会社の登録商標です。Linux® は、米国およびその他の国における Linus Torvalds 氏の登録商標です。

OpenStack® ワードマークと Square O Design は個別に、または一体として米国とその他の国における OpenStack Foundation の商標または登録商標であり、OpenStack Foundation の許諾の下に使用されています。Red Hat は、OpenStack Foundation と OpenStack コミュニティのいずれにも所属しておらず、公認や出資も受けていません。

2200 MISSION COLLEGE BLVD.

インテルについてインテルが可能にする未来の驚くべき体験

インテルはプロセッサー製品で広く知られる企業ですが、その他にも多くの事業を手がけています。インテルはビジネスと社会、そして地球上のすべての人にすばらしい体験をもたらすため、テクノロジーの最先端でイノベーションを生み出しています。

クラウドの機能性、IoT の遍在性、メモリーとプログラム可能なソリューションの分野における最新の成果、そして次世代を担う常時接続 5G といった最新テクノロジーを通じて、インテルは業界の既成概念を打ち破り、世界的な課題の解決に挑んでいます。インテルはポリシー、多様性、インクルージョン、教育、サステナビリティーの各方面で牽引役を務めながら、株主の皆様、お客様、社会に向けて価値を生み出していきます。

インテル、インテルのロゴ、および Xeon は、Intel Corporation またはその子会社の米国およびその他の国における商標です。 *その他の名称およびブランドは、他社の所有物です。

SANTA CLARA, CA 95054-1549, USA

電話: (408) 765-8080

RED HAT についてオープンソースソリューションのプロバイダーとして世界をリードする Red Hat は、コミュニティとの協業により高い信頼性と性能を備えるクラウド、Linux、ミドルウェア、ストレージおよび仮想化テクノロジーを提供、さらにサポート、トレーニング、コンサルティングサービスも提供しています。Red Hat は、お客様、パートナーおよびオープンソースコミュニティのグローバルネットワークの中核として、成長のためにリソースを解放し、ITの将来に向けた革新的なテクノロジーの創出を支援しています。

facebook.com/redhatjapan @redhatjapan

linkedin.com/company/red-hat

アジア太平洋 +65 6490 4200 オーストラリア 1 800 733 428 ブルネイ /カンボジア 800 862 6691 インド +91 22 3987 8888

インドネシア 001 803 440224 日本 03 5798 8510 韓国 080 708 0880 マレーシア 1 800 812 678

ニュージーランド 0800 450 503 フィリピン 800 1441 0229 シンガポール 800 448 1430 タイ 001 800 441 6039

ベトナム 800 862 6691 中国 800 810 2100 香港 852 3002 1362 台湾 0800 666 052

技術詳細 エンタープライズ IT インフラストラクチャ最適化のベストプラクティスとガイドライン