物性物理学 - 東京大学 · 2017. 6. 23. · 物性物理学がターゲットとするスケール 世界の階層構造：長さスケール 10-15 m 1 1021 1Å 10-6 1μm 10-10
使用する SAP® HANA® の スケール アップ環境に …...VMware vSphere...
38
VMware vSphere® 上で 使用する SAP® HANA® の スケール アップ環境に関する ベスト プラクティスと推奨事項 導入と技術的な検討事項のガイド
Transcript of 使用する SAP® HANA® の スケール アップ環境に …...VMware vSphere...
VMware vSphere® 上で 使用する SAP® HANA® の スケール アップ環境に関する ベスト プラクティスと推奨事項導入と技術的な検討事項のガイド
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2
目次はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
本番環境のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
使用する製品とテクノロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
SAP HANA Tailored Data Center Integration （TDI） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
SAP HANA アプライアンス モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
vSphere vMotion （ライブ マイグレーション） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
vSphere vMotion による SAP HANA データベースの移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
vSphere Distributed Resource Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
vSphere DRS による SAP HANA 環境の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SAP HANA と vSphere HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SAP HANA のクローンとテンプレート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
vSphere ホスト プロファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
SAP HANA データベースの統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
導入のベスト プラクティス. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
コンピューティング環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ストレージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
vSphere 上で使用する SAP HANA の最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ワークロードの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
NIC の最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
仮想 SCSI アダプタの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
導入に関するヒントとガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
仮想化した SAP HANA のサイジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SAP HANA のサイジング方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
SAPS ベースの SAP HANA のサイジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
SAP HANA の T シャツ サイジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
複数の SAP HANA 仮想マシンを 1 台の ESXi ホストに展開する場合のサイジングの例 . . . . 32
SAP HANA 仮想システムのストレージのサイジング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
付録 A： vSphere 関連の問題のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . 35
サポート リクエストの発行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
vCenter Server と esxtop を使用して vSphere のトラブルシューティングを行う方法 . . . . 35
参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3
はじめにSAP® HANA™ は業界をリードするインメモリ データ プラットフォームです。SAP HANA を使用する SAP® 社製およびパートナー社製ソリューションを導入すると、リアル タイムのビジネス運営が可能になります。トランザク
ション処理と分析処理の両面に対して最適化された SAP HANA ソリューションでは、分析、ビジネス プロセス、センチメント データ処理、および予測機能のスピードが大幅に向上します。また、SAP HANA ソリューションを使用すると、ビッグ データを迅速に分析して、革新を進めることができます。
SAP HANA データベースは、マルチ コア アーキテクチャを使用してデータを管理し、すべてのコアにデータを分散させます。スケール アウト機能 （水平方向の拡張） とスケール アップ機能 （垂直方向の拡張） を使用して、RAM の局所性を最大化します。スケール アップ システムによって、スケーラビリティと柔軟性がもたらされ、CPU、メモリ、およびストレージを必要に応じてそれぞれ拡張できます。
VMware® vSphere™ 仮想化およびクラウド コンピューティング プラットフォームを基盤として SAP HANA
プラットフォームを使用することで、SAP HANA をご利用のお客様に新しい展開アーキテクチャが提供されます。SAP HANA と VMware ソリューションを組み合わせると、俊敏性、優れた可用性、コストの削減、および容易なプロビジョニングを実現するデータセンター プラットフォームが構築されます。このソリューションによって、SAP
HANA のインスタンスを仮想マシンに迅速にプロビジョニングすることが可能になります。
SAP HANA プラットフォームと VMware vSphere 仮想化インフラストラクチャを組み合わせて使用すると、費用対効果に優れた独自のソリューションを構築するための最適な環境が生まれます。SAP HANA と VMware ソリューションの組み合わせには、VMware vSphere® vMotion®、VMware vSphere® Distributed Resource Scheduler™
（DRS）、および VMware vSphere® High Availability （HA） が使用されます。それによって、運用のパフォーマンスと可用性を最高レベルに引き上げることができます。
このドキュメントでは、VMware 仮想化インフラストラクチャ上で実行される SAP HANA のスケール アップ環境の構成、展開、および最適化に関するベスト プラクティスの手法と推奨事項について説明します。このドキュメントで示される調査結果の多くは、VMware® と SAP® 社が協力して実施したテストによるものです。このテストは、VMware vSphere 5.5 を基盤とする SAP HANA のスケール アップ環境について、パフォーマンスの特徴を調べるために実施しました。
このドキュメントは、VMware 仮想化環境内での SAP HANA プラットフォームの構成および導入を担当するアーキテクト、エンジニア、および管理者を対象としています。vSphere の概念と機能、SAP HANA、SAP 社の関連する製品およびテクノロジーについて、読者が基本的な知識を持っていることを想定しています。
本番環境のサポート
2012 年 11 月に、SAP 社は、本番環境以外の環境について、vSphere 5.1 上での SAP HANA の使用をサポートすると発表しました。さらに、2014 年 4 月、SAP HANA Tailored Data Center Integration （TDI） 環境を含む SAP
HANA のスケール アップ本番環境をサポート対象として追加しました。
VMware は、最大で合計 1 TB の RAM を搭載する SAP HANA スケールアップ データベースをサポートします。 1 TB の SAP HANA データベースは、約 512 GB の圧縮されたデータで構成されます。RAM の残りは一時テーブル、中間計算、および SAP HANA データベースのほかの構造のために使用されます。vSphere 上で SAP HANA を
サイジングする場合、物理的な要件と同様の条件があります。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 4
使用する製品とテクノロジーSAP HANA と VMware ソリューションを組み合わせて使用する場合の主な製品とテクノロジーには、SAP®
HANA™ SP07 プラットフォームや VMware® vSphere™ 5.5 プラットフォームなどがあります。特に、このソリューションでは、vSphere vMotion、vSphere DRS、vSphere HA など、vSphere の高度な機能を使用します。以降のセクションでは、これらの製品とテクノロジーのそれぞれについて説明します。
SAP HANA
SAP HANA は業界をリードするインメモリ データ プラットフォームです。SAP HANA を使用する SAP 社製およびパートナー社製ソリューションを導入すると、リアル タイムのビジネス運営が可能になります。SAP HANA は、オンプレミス アプライアンスとして展開するか、クラウド上に展開できる、インメモリ データ プラットフォームです。この革新的なプラットフォームは、リアル タイム分析の実行と、リアル タイム アプリケーションの開発および展開に最適です。
SAP HANA プラットフォームは、データベース機能とアプリケーション プラットフォーム機能をインメモリで統合して、トランザクション、分析、テキスト分析、予測、および地理情報処理を変革し、リアル タイムのビジネス運用を実現します。このリアル タイム データ プラットフォームの中心になるのが、SAP HANA データベースです。SAP HANA データベースは、次に説明するように、現在市場にあるほかのどのデータベース エンジンとも根本的に異なります。
図 1： 新しい種類のリアル タイム分析とリアル タイム アプリケーションを実現する SAP HANA プラットフォーム
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 5
SAP HANA プラットフォームは、次世代のリアル タイム アプリケーションの構築および展開や、リアル タイム分析の実行に最適です。SAP HANA のアーキテクチャでは、オンライン トランザクション処理 （OLTP） とオンライン分析処理 （OLAP） を統合して、単一のインメモリ データストアで実行できます。このカラム型のインメモリ データストアは、ACID （原子性、一貫性、独立性、永続性） コンプライアンス モデルに対応しています。データに冗長性はなく、遅延も発生しません。
SAP HANA が提供する高度な機能を使用すると、予測分析、テキスト分析、地理情報処理、ビジネス分析、および
データ仮想化について、すべて単一のアーキテクチャ上で、大幅に迅速化できます。また、アプリケーションの開発が簡素化し、ビッグ データの複数のソースや構造にまたがる処理が迅速化されるため、革新を推進できます。
SAP HANA は、次のようなシナリオに適しています。
• データ セットについて詳細な分析を行い、複雑な対話形式の質問に対応する必要がある
• 幅広い （さまざまなソースからなるさまざまな種類のデータ セットで構成される、膨大なデータ セットを使用する） 分析を同時に行う必要がある
このような場合に、最新のデータ、可能であればリアル タイムのデータを使用したいというニーズが増加しています。
さらに企業は、データの準備、事前の集計、調整など、事前に処理を行うことなく、分析を迅速に実行する （応答時間を非常に短くして、真の双方向性を実現する） 必要があります。
このようなシナリオで、独自の一連の要件に効果的に対応できるのは、SAP HANA のみです。実際、SAP HANA が真価を発揮するのは、これらの要件、またはその一部の組み合わせに対応する場合です。
リアル タイムの分析SAP HANA が実行できるリアル タイムの分析の例を次に示します。
• 運用レポート： カスタムのシステムや SAP ERP などのトランザクション システムから、リアル タイムの情報を提供します。
• データ ウェアハウス （SAP HANA 上での SAP NetWeaver BW の使用）： SAP NetWeaver Business Warehouse
（BW） をご利用のお客様は、BW アプリケーション全体を SAP HANA プラットフォーム上で実行することで、これまでにないパフォーマンスを実現できます。たとえば、クエリの実行は 10 倍から 100 倍、データの読み込みは
5 倍から 10 倍、計算は 5 倍から 10 倍速くなります。
• ビッグ データの予測分析およびテキスト分析： SAP HANA では、イン データベース予測アルゴリズムと、R との連携機能を使用して、大量のデータに対してリアル タイムで予測分析およびテキスト分析を実行できます。SAP
HANA のテキスト検索 / 分析機能は、非構造化データを活用するための堅牢な手段の 1 つです。
リアルタイム アプリケーションSAP HANA が実行できるリアルタイム アプリケーションの例を次に示します。
• コア プロセス アクセラレータ： ERP アクセラレータを使用して、経営に関するレポート作成を迅速化します。環境に影響を与えることなくインメモリ テクノロジーを活用することができます。
• 計画と最適化を行うアプリケーション： SAP HANA は、複雑なスケジューリングが必要で、迅速に結果を提供する必要があるアプリケーションに適しています。SAP 社は、ほかのベンダーには実現できないソリューションを提供しています。
• 感知即応型 （Sense & Response） アプリケーション： これらのアプリケーションは、スマート メーターのデータ、POS のデータ、ソーシャル メディアのデータなどのビッグ データから、リアル タイムの情報を提供します。パーソナライズされた情報や推奨事項、テキストの検索とマイニング、予測分析など、複雑さに対処できる必要があります。通常、これらのプロセスは大量のデータを使用します。このようなプロセスの多くは、コストとパフォーマンスの制約から、以前は導入できませんでした。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 6
OLTP ワークロードリアルタイム分析 （OLAP） ワークロードに加え、HANA は従来のオンライン トランザクション処理 （OLTP） ワークロードの実行にも適しています。SAP 社は、SAP Business Suite on HANA （SoH） によって、組み込みのシナリオでの通常のデータベースの実行だけでなく、SAP HANA による SoH ワークロードの実行もサポートしています。SoH では、従来リレーショナル データベース上で実行されていたシナリオが、すべて SAP HANA データベース上で実行されます。そのため、オンライン処理と分析を別々に処理する代わりに、SAP HANA データベースで最適化された既存の機能を使用することができます。
SAP HANA の詳細情報については、SAP HANA プラットフォームのサポート ページ （英語）
（https://help.sap.com/hana_platform） を参照してください。
SAP HANA Tailored Data Center Integration （TDI）
SAP HANA Tailored Data Center Integration （TDI） を使用すると、既存のハードウェア コンポーネントおよびインフラストラクチャ コンポーネントの特定の部分を SAP HANA 環境に使用できます。通常は、必要なコンポーネントは SAP HANA アプライアンスにすべて搭載されており、事前構成された状態で、認定を受けた SAP HANA
ハードウェア パートナーから提供されます。SAP HANA アプライアンスに搭載されているコンポーネントを使用する代わりに、お客様の環境にある既存のハードウェア コンポーネントやインフラストラクチャ コンポーネントの一部を使用することが TDI の目的です。
既存のデータセンターのレイアウトに応じて、SAP HANA TDI では次のことが可能になります。
• 既存のハードウェア コンポーネントと運用プロセスを再利用して、ハードウェア コストと運用コストを削減できます。
• 既存の IT 管理プロセスを SAP HANA 実装環境で使用することで、リスクを低減し、短時間で成果を得ることができます。
• 既存のエコシステムを最大限に活用することによって、ハードウェア ベンダーをより柔軟に選択できるようになります。
SAP HANA TDI フレームワークの利用について、次に説明します。
• TDI の導入が最初に可能になったレイヤーはストレージで、2013 年の 11 月から一般公開されています。ネットワーク
レイヤーのパイロット プログラムは、2013 年の第 4 四半期に開始されました。
• VMware の機能の多くは共有ストレージ TDI を必要とするので、VMware プラットフォームは推奨運用モデルに従います。
詳細については、このドキュメントの末尾近くにある 「参考資料」 のセクション （SAP HANA に関する参考資料） を参照してください。
図 2： SAP HANA Tailored Data Center Integration （TDI）
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 7
SAP HANA アプライアンス モデル
SAP HANA アプライアンスは、柔軟性に優れた、多目的の、データソースに依存しないインメモリ アプライアンスです。Dell 社、Cisco 社、IBM 社、HP 社、Fujitsu 社など、SAP 社の主要なパートナーが提供する Intel ベースのハードウェア上での実行に最適化された、SAP ソフトウェア コンポーネントで構成されています。SAP HANA データベース、リアル タイム アプリケーション サービス、データ サービス、データ管理、データおよびライフサイクルの管理、業界標準に準拠した複数のインターフェイスのサポート、使いやすいデータ モデリング ツールである SAP
HANA Studio など、多数の SAP ソフトウェア コンポーネントが組み込まれています。
SAP HANA アプライアンスは、次の機能を提供します。
• ロー型とカラム型のデータストアをネイティブにサポートし、完全な ACID トランザクション機能を提供する、 単一の SAP HANA データベース
• 強力で柔軟なデータ計算エンジン
• SQL インターフェイスと MDX インターフェイス
• 情報統合モデリング設計環境
• 業務データのビューを保存および維持するためのデータ リポジトリ （パワーオフしてもデータは維持される）
• SAP 社の製品 （SAP NetWeaver BW、ERP など） のデータソースおよび SAP 製品以外のデータソースにアクセスするためのデータ統合機能
• 統合ライフサイクル管理機能
• さまざまなパートナーが提供する一般的なハードウェア向けに最適化されていることで、低い TCO を実現
これらの機能を組み合わせることで、SAP HANA は企業全体からの大量のデータを処理し、複雑な計算を適用できます。その結果、IT 部門が関与することなく、意思決定者が大量の情報について極めて迅速かつ柔軟に調査と分析を行うことができます。
VMware vSphere
VMware vSphere は最高の仮想化ソリューションであり、クラウド コンピューティング アーキテクチャの基盤となるテクノロジーです。vSphere を使用すると、IT 部門は、最も要求の厳しいビジネス クリティカルなアプリケーションのサービス レベル アグリーメント （SLA） を、最小限の総所有コスト （TCO） で満たすことができます。vSphere では、業界最高クラスの効率性と豊富な選択肢を活用して、すべての IT リソースを管理できます。
vSphere 仮想化ソリューションは、次のことを実現します。
• 統合： VMware の仮想化ソリューションによって、複数のアプリケーション サーバを 1 台の物理サーバに統合できます。全体的にパフォーマンスの低下はほとんどありません。使用率の低いサーバ ハードウェア、ソフトウェア、およびインフラストラクチャを減らす （あるいはなくす） ことができます。
• 管理性： ハードウェアのメンテナンスなどの定常作業を簡素化する VMware vSphere® vMotion® や VMware
vSphere® Storage vMotion® を使用して、サーバ間および関連するストレージ間で仮想マシンをライブ マイグレーションできます。ダウンタイムは発生しません。
• 可用性： 高可用性を実現することによって、計画外のダウンタイムを削減し、アプリケーションのサービス レベルを向上できます。VMware vSphere® High Availability （HA） を使用すると、計画外のハードウェアの障害が発生した場合、影響を受ける仮想マシンが VMware クラスタ内の別のホスト上で自動的に再起動されます。
• 自動化： VMware ソリューションではロード バランシングを自動的に行い、vSphere vMotion と vSphere
Storage vMotion を活用して、一連の VMware® ESXi® ホスト間で仮想マシンを移行します。VMware vSphere®
Distributed Resource Scheduler™ （DRS） と VMware vSphere® Storage DRS™ を使用することで、仮想
マシンとストレージについて、リソースの再配置と最適化に関する決定を自動的に行うことができます。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 8
• プロビジョニング： VMware の仮想化ソリューションは、アプリケーションをイメージにカプセル化して、複製
または移動できます。そのため、アプリケーションのプロビジョニングと展開のコストを大幅に削減できます。
vSphere は、アプリケーションが要求するリソース、オペレーティング システム、リソースを提供する基盤となるハードウェアの間に抽象化レイヤーを作成します。vSphere を使用すると、複数の分離された実行環境が単一のハードウェア プラットフォームを共有できます。vSphere は、各環境にハードウェア リソースの独自のセットを実装します。
vSphere の詳細については、このドキュメントの末尾近くにある 「参考資料」 のセクションを参照してください。
vSphere vMotion （ライブ マイグレーション）
vSphere vMotion を使用すると、実行中の仮想マシンを別の物理サーバへダウンタイムなしで移行できます。また、サービスの可用性が継続され、トランザクションの整合性が完全に維持されます。vSphere vMotion は、自己最適化が可能で、自動化された動的なデータセンターを構築するための主要テクノロジーです。vSphere vMotion によって、ハードウェアのメンテナンスをいつでも実行できるようになります。また、次に説明するように、vSphere vMotion
はサーバのクラスタリングや冗長化を必要としません。
図 3： vSphere の仮想インフラストラクチャ
図 4： vSphere vMotion
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 9
vSphere vMotion の特徴は、次のとおりです。
• 実行中の仮想マシン全体を瞬時に移行します。ユーザーに影響を与えることなく、ダウンタイムなしでライブ マイグレーションを実行します。
• ライブ マイグレーションを管理し、事前に設定した時刻に実行されるように容易にスケジューリングできます。 管理者が操作する必要はありません。本番環境での実績のある製品で、信頼性と管理性をもたらします。
• vSphere がサポートするあらゆるタイプのハードウェアおよびストレージ間で、任意のオペレーティング システムを実行している複数の仮想マシンを監査証跡付きで同時に移行できます。
• サービス レベルを維持し、パフォーマンスに関する目標を達成するために、ESXi® サーバ ホスト マシン間でオンライン ワークロードを移動できます。
• リソース プール内で、仮想マシンの配置を継続的および自動的に最適化します。障害が発生したサーバやパフォーマンスが低下しているサーバから、仮想マシンをプロアクティブに移行します。
• ダウンタイムを計画したり、ビジネス業務を中断したりすることなく、ハードウェアのメンテナンスを実行できます。
ファイバ チャネル、iSCSI のストレージ エリア ネットワーク （SAN）、ネットワーク接続ストレージ （NAS） などの共有ストレージに保存されるファイル セットとして、仮想マシン全体の状態がカプセル化されます。VMware
vSphere Virtual Machine File System （VMFS） を使用すると、複数の ESXi が同じ仮想マシン ファイルに同時にアクセスすることが可能になります。
アクティブなメモリおよび仮想マシンの正確な稼動状態が、高速ネットワークを介して迅速に伝達されます。これにより、移行元の ESXi ホストで実行中の仮想マシンを移行先の ESXi ホスト上で即座に実行できます。vSphere
vMotion は、実行中のメモリ トランザクションをビットマップに記録することで、ユーザーに転送時間を意識させません。
vSphere vMotion は、メモリおよびシステムの状態すべてを移行先の ESXi ホストにコピーした後、移行元の仮想マシンをサスペンドし、ビットマップを移行先の ESXi ホストにコピーして、移行先の ESXi ホスト上の仮想マシンをレジュームします。仮想マシンで使用されるネットワークは、基盤となる ESXi ホストで仮想化されます。これにより、移行後も仮想マシンのネットワーク ID とネットワーク接続が維持されます。
vSphere vMotion は、プロセスの一環として仮想 MAC アドレスを管理します。移行先マシンがアクティブになると、vSphere vMotion からネットワーク ルータに対して ping が送信され、仮想 MAC アドレスに対応する新しい物理アドレスがネットワーク ルータで認識されているかどうかを確認します。vSphere vMotion を使用した仮想マシンの移行では、正確な稼動状態、ネットワーク ID、およびアクティブなネットワーク接続が維持されるため、ダウンタイムの発生やユーザーへの影響はありません。
vSphere vMotion による SAP HANA データベースの移行
vSphere vMotion を使用することで、稼動中の SAP HANA データベースをホスト間でダウンタイムを発生させることなく移行できます。SAP HANA ホストでハードウェアに関するアラートが増加した場合は、基本的な知識を持つ管理者、データベース管理者、または仮想インフラストラクチャ管理者が、ダウンタイムやコストが発生しないように、そのホストにある SAP HANA データベースを別の vSphere ホストにプロアクティブに移行できます。
SAP HANA はインメモリで実行されるので、大量のメモリを使用します。ライブ マイグレーションを実行する際、vSphere vMotion は SAP HANA のメモリのすべての状態を維持します。同時に、移行が完了するまでクエリまたはトランザクションの処理は継続し、パフォーマンスに与える影響はごくわずかです。
対照的に、SAP HANA を再起動すると、次のようになります。
• クエリまたはトランザクションの処理は中断されます。
• 一時テーブルと一時的な計算値は失われます。
• SAP HANA はシステム テーブルを読み込み、リスタートを実行します。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 0
• その後、ディスクからメモリにカラムを事前ロードしたり、クエリを実行して読み込んだりすることができます。
注： タイム スタンプ カウンタ （TSC） の問題を避けるために、仮想マシンを移行する場合は、移行元と移行先の
ESXi ホスト サーバで、同じタイプかつ同じ周波数の CPU を使用する必要があります。
オプション 説明
高優先順位 VMware vCenter Server は移行元と移行先の両方のホストでリソースを確保し、移行中の仮想マシンの可用性を保証します。リソースを確保できない場合、高優先順位での移行は続行されません。
低優先順位 vCenter Server は、移行中の可用性を維持するために移行元ホストおよび移行先ホストでのリソース予約は行いません。低優先順位の移行は、常に実行されます。ただし、移行中にホストのリソースを確保できない場合、仮想マシンの一部の機能が利用できなくなります。
表 1： vSphere vMotion による移行のポリシー
本番環境の SAP HANA 仮想マシンには、メモリと CPU の予約が構成されています。移行先のホストで十分なリソースを使用できない場合、vSphere vMotion は失敗します。vSphere 上の SAP HANA のパフォーマンスレベルを維持するために、このような動作となります。
vSphere Distributed Resource Scheduler
vSphere Distributed Resource Scheduler （DRS） は、ロード バランシングを自動的に実行するテクノロジーであり、ビジネスの優先順位に基づいたリソースの使用を可能にします。次に説明するように、vSphere DRS は、 ビジネスの優先順位に合わせてリソースを動的に割り当て、コンピューティングのキャパシティを調整して、データセンターの消費電力を削減します。
ESXi ホスト間で仮想マシンを移行する場合には vSphere vMotion を活用します。vSphere DRS は、vSphere サーバ全体の使用率を継続的に監視し、ビジネス ニーズに合わせて使用可能なリソースを仮想マシン間にインテリジェントに割り当てます。
vSphere DRS を使用すると、クラスタ内の任意のホストに仮想マシンを自動的に初期配置できます。ホストや仮想マシンをクラスタに追加したりクラスタから削除したりする場合には、リソースの再配置と最適化に関する決定を
自動的に行うことができます。vSphere DRS を手動モードに構成すると、後で確認して実行できるように、推奨
される設定が作成されます。自動的なアクティビティは発生しません。
図 5： vSphere Distributed Resource Scheduler
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 1
vSphere DRS による SAP HANA 環境の管理
SAP HANA 環境は、vSphere DRS を使用して管理できます。次に説明する vSphere DRS の自動化モードと自動化ルールを使用すると、ハードウェアへの投資とホストのリソースを最大限に活用しつつ、SAP HANA 環境で企業の
SLA を維持することができます。
vSphere DRS で設定できる自動化モードは、次のとおりです。
• 手動： このモードでは、vSphere DRS がクラスタ内でのパワーオン時の仮想マシンの配置について推奨される設定を表示し、また、移行についても推奨される設定を表示します。
• 一部自動化： このモードでは、vSphere DRS がパワーオン時に仮想マシンを自動的に配置し、仮想マシンの移行については推奨される設定を表示します。
• 完全自動化： このモードでは、vSphere DRS が配置と移行を自動的に行います。
SAP HANA データベースを展開する場合、不要な移行が行われないように DRS ルールを設定する必要があります。
• たとえば、1 個のクラスタには最大で 32 台のホストが含まれます。SAP HANA の認定を受けたサーバであるホストがクラスタに 3 台しかない場合、vSphere DRS が SAP HANA を認定されていないホストに移動してしまう可能性があります。この場合、vSphere DRS にアフィニティ ルールを設定して、SAP HANA の移行先には SAP
HANA の認定を受けたホスト サーバのみを使用するようにします。
• vSphere DRS には非アフィニティ ルールを設定することもできます。たとえば、月末に特定の vSphere ホストで
SAP HANA 仮想マシンのみを実行するように設定できます。このルールには、1 台のホストで SAP HANA の
インスタンスを 1 個しか実行しないという条件を設定することもできます。
データ管理システムの運用を開始する時点で DRS ルールが設定されていない場合は、vSphere DRS を手動モードに設定します。それによって、vSphere vMotion の処理が自動的に行われて SAP HANA がサポート対象外の認定
されていないサーバに配置されることを回避できます。
vSphere High AvailabilityvSphere High Availability （HA） は、仮想マシンで実行するアプリケーションに対し、費用対効果に優れた高可用性を提供します。物理サーバに障害が発生した場合、影響を受けた仮想マシンは、キャパシティに余裕のある本番環境の別のサーバ上で自動的に再起動されます。オペレーティング システムに障害が発生した場合、vSphere HA は、影響を受けた仮想マシンを同じ物理サーバ上で再起動します。vSphere HA と vSphere プラットフォームのほかの可用性機能とを組み合わせることで、IT 部門はすべての重要なアプリケーションに必要な可用性レベルを選択し、簡単に提供できます。
vSphere HA を使用すると、IT 部門は次のことが可能になります。
• 専用のスタンバイ ハードウェアや追加ソフトウェアを導入することなく、計画外のダウンタイムおよび IT サービスの中断を最小限に抑えることができます。
• オペレーティング システムまたは特定のアプリケーションに関連する、フェイルオーバー ソリューションの複雑さおよびコストを削減しながら、仮想 IT 環境全体に低コストかつ統一的に高可用性を提供します。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 2
SAP HANA と vSphere HA
このセクションでは、SAP HANA の高可用性機能と vSphere HA の機能の使用例と制限について説明します。また、SAP HANA の高可用性機能と vSphere HA の機能のうち、使用できる組み合わせについても説明します。
バックアップとリストアの機能に加え、SAP HANA には組み込みの高可用性機能が搭載されています。
SAP HANA の高可用性の詳細については、「Introduction to High Availability for SAP HANA」
（http://www.saphana.com/docs/DOC-2775） を参照してください。
vSphere HA は、使いやすく、多くの IT 部門と SAP HANA 環境にとって十分な高可用性を提供します。vSphere
HA は、通常 SAP HANA インスタンスで 99.9 % の可用性を実現します 1。
フェイルオーバーの間、vSphere 仮想マシンで実行される SAP HANA データベースは、クラスタ内の指定されたホストで優先的に再起動できます。専用のスタンバイ サーバは不要です。ただし、SAP HANA データベースは、SAP HANA の認定を受けたサーバでしか実行できません。また、vSphere HA を使用する場合、DRS ルールを設定する必要があります。詳細については、前述の 「vSphere DRS による SAP HANA 環境の管理」 のセクションを参照してください。vSphere 5.5 では、vSphere HA イベントが発生した際に、DRS ルールが維持されます。
vSphere HA が検出および応答できるのは、仮想マシンのオペレーティング システムまたは vSphere ホストのハードウェアに障害が発生し、その障害が vSphere HA で保護されている仮想マシンに悪影響を与える場合のみです。
これに対して、SAP HANA は専用の高可用性ソリューションを備えています。これを vSphere HA と組み合わせて使用することで、SAP HANA インスタンスをすべてのレベルで保護できます。
SAP HANA System Replication2 は、SAP HANA 用の別の HA ソリューションです。このソリューションによって、目標復旧時間 （RTO） を大幅に短縮できます。SAP HANA System Replication では、構成時にデータの事前ロードの有無を指定できます。現時点では、スケール アップ型の単一の SAP HANA インスタンス仮想マシンのみをサポートします。
次の表は、vSphere 上で仮想化された SAP HANA システムで使用できる、さまざまな高可用性ソリューションについてまとめたものです。
図 6： vSphere High Availability
1 http://itblog.emc.com/2014/01/30/why-emc-it-virtualized-sap-hana-with-vmware/ （英語）
2 http://www.saphana.com/servlet/JiveServlet/downloadBody/2775-102-4-9467/HANA_HA_2.1.pdf （英語）
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 3
高可用性 ソリューション
VMware vSphere High Availability*
VMware vCenter Site Recovery Manager
SAP HANA System Replication
SAP HANA Host Auto-Failover
オペレーティング システム障害
○ – ○ ○
ハードウェア障害 ○ – ○ ○
アプリケーション障害 × – ○ ○
IP のリダイレクト / DNS のアップデート
不要 – × クラスタ ソフトウェアなどのサードパーティ製ソフト ウェアを使用、vCenter Site Recovery Manager が必要
-
サイトの フェイルオーバー
× ○ サードパーティ製ストレージ レプリケーションを使用すれば可能
○ ×
目標復旧時間 （RTO） 短い 中程度 最短 ～ 中程度。IP のリダイレクトの ソリューションによる
短い
合わせて使用可能 vCenter Site Recovery Manager、SAP HANA System Replication、サードパーティ製クラスタ ソリューション **
vSphere High Availability、サードパーティ製ストレージ レプリケーション
vSphere High Availability
SAP HANA System Replication
* 詳細については、『VMware vSphere High Availability 5.0 Deployment Best Practices』 を参照してください。 http://www.vmware.com/files/pdf/techpaper/vmw-vsphere-high-availability.pdf
** 詳細については、「High Availability Solutions for SAP on VMware」 のページで、VMware のゲスト内のクラスタ ソリューションに関する制限を参照してください。 http://scn.sap.com/docs/DOC-32023
表 2： VMware vSphere 上で使用できる SAP HANA 用の高可用性ソリューション
SAP HANA の組み込みの高可用性機能は、vSphere HA と組み合わせることができます。したがって、SAP
HANA はあらゆるレベルで保護できます。VMware の HA ソリューションと SAP HANA の HA ソリューションを組み合わせて使用する場合、保護対象の機能ごとにどちらか 1 つのソリューションのみが使用されるようにする
必要があります。障害の発生時に両方のソリューションが使用されると、HA プロセスが妨げられる可能性があり
ます。vSphere DRS など、運用管理に関わる機能は、高可用性の概念が損なわれないように構成する必要があります。たとえば、SAP HANA System Replication 仮想マシンをすでに実行している ESXi ホストがあったとします。 実行中の SAP HANA 仮想マシンが DRS によってその ESXi ホストに自動的に移動させられないようにします。HA イベントや再起動の後に SAP HANA を自動的に起動するには、SAP HANA を自動的に起動するパラメータを
SAP HANA の構成ファイルに追加する必要があります。詳細については、『SAP HANA Master Guide』 （http://www.saphana.com/docs/DOC-3817） を参照してください。
vSphere HA と SAP HANA System Replication を組み合わせた HANA の高可用性の概念を以下の図に示します。このソリューションでは、vSphere ホストまたは仮想マシンのオペレーティング システムに関連する問題はローカルで解決されます。データセンター全体が障害の影響を受けるというまれな場合には、リモートのデータセンターに配置された vSphere ホスト上で実行される別の仮想マシン上で、SAP HANA インスタンスを再起動できます。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 4
HANA と書かれた仮想マシンは、ホスト A で実行されていた SAP HANA 仮想マシンが再起動されたものです。vSphere HA が障害を検出して、SAP HANA 仮想マシンをホスト A で再起動できない場合、自動的にホスト B で再起動します。SAP HANA インスタンスは実行され続けながら、ホスト C で実行される HANA レプリカ仮想マシンに HANA データベースのログをレプリケーションします。データセンター A 全体が障害の影響を受ける事態が発生した場合、SAP HANA インスタンスをこのレプリカから再起動できます。SAP HANA データベースをリモートのデータセンター C で再起動する場合、リモートでの再起動プロセスを完全に制御して、vSphere HA による自動的な再起動プロセスとの間で競合が発生しないようにするために、再起動を手動で開始する必要があります。
SAP HANA のクローンとテンプレート
仮想化した SAP HANA データベースをインストールした後、構成および調整済みの SUSE Linux オペレーティング
システムを使用して、VMware のテンプレートまたはクローンを作成できます。この SUSE Linux オペレーティング
システムには、必要なドライバがすべて事前ロードされ、vSphere 上で実行するために最適化した任意のソフトウェアが追加されている必要があります。
vSphere は、VMware のクローンまたはテンプレートを使用して、SAP HANA 仮想マシンのコピーを作成できます。VMware のクローンは、SAP HANA 仮想マシンの正確なコピーです。仮想マシンのクローンを作成すると、設定、構成された仮想デバイス、インストールされたソフトウェア、および仮想マシン ディスクのその他の内容を含め、仮想マシン全体のコピーが作成されます。必要に応じて、ゲスト OS をカスタマイズして、vSphere ホストの名前やネットワーク設定など、クローンのプロパティの一部を変更できます。
仮想マシンの正確なコピーであるクローンに対して、VMware のスナップショットは、スナップショット作成時点での仮想マシンの状態を表すもので、仮想マシンのパフォーマンスに悪影響を与える可能性があります。仮想マシンのパフォーマンスへの影響は、スナップショットの保存期間と、スナップショットの作成後に仮想マシンとそのゲスト
OS がどの程度変更されたかに基づいて決まります。スナップショットは、本番環境で SAP HANA を使用する場合はサポートされません。
SAP HANA データベースの構成が完了し、vSphere 用に最適化したら、VMware のテンプレートを使うことを推奨します。VMware のテンプレートは、多数の SAP HANA クローンを作成するために使用する、SAP HANA 仮想マシンのマスター コピーです。テンプレートを使用して、複数の SAP HANA 仮想マシンを作成およびプロビジョニングできます。テンプレートは、パワーオンしたり編集したりすることはできません。テンプレートは、繰り返し使用できる SAP HANA 仮想マシンの構成を保存して展開するための安全な方法です。
図 7： vSphere HA と SAP HANA に組み込まれた HA 機能を組み合わせた、SAP HANA の HA / DT ソリューション
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 5
vSphere ホスト プロファイル
vSphere ホスト プロファイルは、参照ホストの構成をカプセル化して、プロファイルまたはテンプレートにする機能です。作成したプロファイルまたはテンプレートは、新規あるいは既存の vSphere ホストに適用できます。ホスト
プロファイルを使用することで、すべての vSphere ホストの構成について一貫性が確保されます。また、コンプライアンスの自動チェックにより、構成エラーを容易に防ぐことができます。
コンプライアンスを定期的にチェックして、ホストまたはクラスタの構成が適切であることを確認します。ホスト
またはクラスタにプロファイルを関連付けたら、vSphere Client 内のさまざまな場所から、プロファイルを使用してコンプライアンスの状態を確認できます。
また、ファームウェアのアップグレードなどで、クラスタ内の複数のホストのストレージ、ネットワーク、またはセキュリティ構成を変更する必要が生じた場合は、ホスト プロファイルを編集し、クラスタ全体に適用することで、整合性を維持しながら構成を更新できます。
SAP HANA 環境を構築する際、すべての SAP HANA 仮想マシンを最適化して、一貫した構成を行うことが重要
です。ホストも最適化して一貫した構成を行う必要があります。VMware のクローンとテンプレートを使用して SAP
HANA 環境を構築すると、整合性を維持した迅速な導入を行い、一貫したパフォーマンス レベルを実現できます。
SAP HANA データベースの統合
vSphere 5.5 を使用すると、最大 1 TB の SAP HANA データベースの仮想マシンを作成できます。vSphere 5.5 は、ホストごとに最大 4 TB の RAM に対応するので、さまざまなサイズの複数の SAP HANA データベースを 1 台のサーバに統合できます。本番環境において SAP HANA を VMware vSphere® 5.5 上で使用する場合、SAP HANA
の認定を受けた 1 台の専用のサーバ上で 1 台の仮想マシンを利用できます。
SAP 社はまた、限定的に、本番環境と本番環境以外のいずれの使用でも、SAP HANA の認定を受けた複数のサーバ上で複数の仮想マシンを実行することをサポートしています。
完全に分離された安全な SAP HANA 仮想マシンの展開は、SAP の複数の SID 環境とは大きく異なります。
RAM や CPU と同様に、ストレージ リソースのオーバーコミットメントは、アプライアンスと TDI のどちらのデリバリ モデルでもサポートされません。アプライアンス デリバリ モデルを使用して仮想マシンを統合する場合、1 台の VMware ホスト上で実行できるライセンスを付与された SAP HANA 仮想マシンの最大数は、認定を受けたハードウェア アプライアンス ベンダーによって定義されます。TDI デリバリ モデルでは、認定を受けたストレージのみを使用できます。ストレージ ベンダーと協力して、ストレージ インフラストラクチャに展開できる SAP HANA 仮想マシンの最大数を判断してください。
図 8： SAP HANA の統合と柔軟な展開
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 6
導入のベスト プラクティスここからは、vSphere 上で SAP HANA を使用する場合の、コンピューティング環境、ネットワーク、およびスト
レージの各分野のベスト プラクティスについて説明します。
コンピューティング環境
vSphere プラットフォームに SAP HANA を展開すると、最適化された専用の仮想マシンおよびコンピューティング環境を実現できます。このような環境を構築する場合は、まず BIOS の設定を慎重に確認し、コンピューティング
リソース （CPU、メモリ、ネットワーク、I/O） を SAP HANA に割り当てるために、不要なプロセスや周辺機器を無効にします。
ここで、コンピューティング環境の機能について説明します。
• vSphere ホスト サーバの BIOS 設定
• 仮想マシンのゲスト OS
• ハードウェア アシストによるメモリの仮想化
• ラージ （ヒュージ） メモリ ページ
• Non-Uniform Memory Access （NUMA）
• 巨大仮想マシン
• 仮想 CPU
• ハイパースレッド
• メモリに関する検討事項
vSphere ホスト サーバの BIOS 設定Intel® Xeon® 5500 シリーズやその後継 CPU など、Nehalem クラスの Intel® 社のマイクロ アーキテクチャを搭載したサーバには、C ステートとインテル ターボ ブーストの 2 つの電力管理オプションがあります。C ステートが
有効になっていると、メモリの遅延が増加します。そのため、遅延の影響を受けやすいワークロードについては、 C ステートの使用はお勧めしません。
有効にする設定 無効にする設定
• Virtualization Technology （VT）
• ターボ モード
• ハードウェア ベースの仮想化の サポート
• ハイパースレッド
• XD ビット （vSphere vMotion と vSphere DRS のために必要）
• ノードのインターリーブ
• C1E Halt ステート
• 電力管理機能： [High Performance] に設定
• 使用しない機能： [Video BIOS Shadowable]、[Video RAM Cacheable]、 オン ボードのオーディオ、オン ボードのモデム、オン ボードのシリアル ポート、オン ボードのパラレル ポート、オン ボードのゲーム ポート、フロッピー ドライブ、CD-ROM、USB
表 3： vSphere ホスト サーバの BIOS 設定
仮想マシンのゲスト OSSAP HANA は、SUSE® Linux Enterprise Server （SLES） 11 Service Pack 2 以降でサポートされます。VMware
の仮想化ソリューションを活用し、最適化されたコンピューティング環境を作成できるようにオペレーティング システムをインストールしてください。
オペレーティング システムのインストール中に周辺コンポーネントが再度有効化されないようにすることが重要です。BIOS で周辺コンポーネントを無効にしても、これらのコンポーネントが完全に無効になっているとは限りません。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 7
インストールした後に、フォアグラウンドおよびバックグラウンドの不要なプロセスを無効にします。たとえば、SUSE Linux の次のプロセスなどです。
• anacron、apmd、atd、autofs、cups、cupsconfig、gpm、isdn、iptables、kudzu、netfs、portmap
そして、次の表で説明するとおり、SUSE Linux の追加コンポーネントを SAP HANA にインストールします。
SUSE Linux のコンポーネント SAP HANA にインストールする際の注意事項
gtk2 オペレーティング システムのディストリビューションで提供されるバージョンを使用します。
java-1_6_0-ibm オペレーティング システムのディストリビューションで提供されるバージョンを使用します。このコンポーネントは SAP HANA システムの SAP HANA Studio に必須です。
libicu オペレーティング システムのディストリビューションで提供されるバージョンを使用します。
mozilla-xulrunner192-1.9.2.xx-x.x.x オペレーティング システムで提供されるバージョンを使用します。 ただし、所定のバージョン以降のものを使用してください。
ntp、sudo
syslog-ng オペレーティング システムのディストリビューションで提供されるバージョンを使用します。
tcsh、libssh2-1、expect、 autoyast2-installation、yast2-ncurses、libgcc、libstdc++
表 4： SAP HANA で使用する SUSE Linux のコンポーネント
次の要件について確認してください。
• 根本原因分析など、特定の理由があって必要でないかぎり、SLES のカーネル ダンプ機能 （kdump） を無効にします。
SLES のカーネルのパラメータを次のように構成します。
• net.ipv4.tcp_slow_start_after_idle=0
共有メモリの設定をインストール中に指定しなかった場合、次の表で示すとおりに設定してください。
サイズ shmmni の値 物理メモリ
小 4096 24 GB 以上、64 GB 未満
中 65536 64 GB 以上、256 GB 未満
大 53488 256 GB 以上
表 5： ゲスト OS の共有メモリ設定
インストールの完了後、整合性を維持するために SAP HANA の 「ゴールド」 テンプレートまたはクローンを作成します。詳細については、前述の 「SAP HANA のクローンとテンプレート」 のセクションを参照してください。
インストールに関する包括的かつ最新の手順を確認するには、『SAP HANA Server Installation Guide』 を参照してください。vSphere 上での SAP HANA のゴールド コピーの構成にかかわる、前述の設定項目について詳しく掲載されています。
詳細については、『SAP HANA Server Installation Guide』 を参照してください。
https://help.sap.com/hana/SAP_HANA_Installation_Guide_en.pdf
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 8
ハードウェア アシストによるメモリの仮想化最近のプロセッサの一部には、メモリ管理ユニット （MMU） の仮想化をハードウェアでサポートすることで、MMU
の仮想化によって生じるオーバーヘッドに対応するものがあります。ハードウェア アシストによる MMU 仮想化を使用できない場合、VMware ESXi はシャドウ ページ テーブルを維持します。シャドウ ページ テーブルは、ゲストの仮想メモリのアドレスをホストの物理メモリのアドレスに直接マッピングします。
シャドウ ページ テーブルはプロセッサが使用するために維持され、また、ゲスト ページ テーブルとの整合性が保持されます。ハードウェアの変換索引バッファ （TLB） が、ゲストの仮想メモリ アドレスからホストの物理メモリ アドレスへの直接の変換をシャドウ ページ テーブルから読み込んでキャッシュするため、通常のメモリ参照では追加のオーバーヘッドが発生しなくなります。ただし、シャドウ ページ テーブルを維持するために追加の作業が必要です。
ハードウェア アシストを使用すると、ソフトウェアによるメモリ仮想化のオーバーヘッドをなくすことができます。特に、シャドウ ページ テーブルとゲスト ページ テーブルを同期するために必要なオーバーヘッドを排除できますが、TLB ミスによる遅延は非常に大きくなります。つまり、ハードウェア アシストがワークロードにもたらすメリットの大きさを決める主な要因は、ソフトウェアによるメモリ仮想化を使用する際に発生するメモリ仮想化のオーバーヘッドです。
プロセスの作成、メモリのマッピング、コンテキストの切り替えなど、ページ テーブルのアクティビティがワーク
ロードであまり発生しない場合、ソフトウェアによる仮想化から発生するオーバーヘッドは大きくありません。しかし、データベースに関するワークロードなど、ページ テーブルのアクティビティが大量に発生するワークロードでは、 ハードウェア アシストによるメリットを得られる可能性が高くなります。
こうした理由から、CPU とゲスト OS の組み合わせに基づいて最適な仮想マシン モニタを vSphere が選択できるようにすることをお勧めします。
ラージ （ヒュージ） メモリ ページSAP HANA は、標準の SLES 11 または SLES 11 for SAP applications ゲスト OS のみでサポートされています。SAP HANA 仮想マシンについても、SAP HANA ハードウェア アプライアンスと同じオペレーティング システム要件が適用されます。SLES 11 SP2 以降では、Linux で透過的なヒュージ ページを使用して、SAP HANA でラージ
ページを使用できるようにすることが可能です。
ラージ （ヒュージ） ページを使用すると、TLB へのアクセスの効率性が向上し、データベースのパフォーマンスが向上する可能性があります。ラージ ページを使用した場合、スモール ページを使用してワークロードを実行する場合に比べ、vSphere 上での SAP HANA データベースのパフォーマンスが大幅に向上します。
オペレーティング システム レベルで有効化した透過的なヒュージ ページを使用すると、パフォーマンスは通常 10 %
ほど向上します。SLES 11 SP2 以降では、ヒュージ ページはデフォルトで有効になっています。
Non-Uniform Memory Access （NUMA）Non-Uniform Memory Access （NUMA） アーキテクチャは、複数のプロセッサ ソケットを搭載するサーバでよく使用されます。メモリの制約を受けていて、遅延の影響を受けやすいシステムのサイジングを行う場合、このメモリ
アクセス アーキテクチャについて理解することが重要です。
1 個の NUMA ノードは、1 個の CPU ソケットに相当します。2 個のソケットがあるサーバには、2 個の NUMA ノードがあります。そのため、利用できる物理 CPU コア数と RAM は、NUMA ノード間で均等に分割できます。1 個の
NUMA ノードに収まるように仮想マシンをサイジングする場合、この点が重要です。たとえば、4 ソケット、40 コア
（ソケットあたり 10 コア）、512 GB の RAM を搭載したサーバの場合、NUMA ノードは 4 個あり、各ノードの物理コア （CPU） は 10 個、RAM は 128 GB （512 ÷ 4） となります。
仮想マシンのサイジングを行う場合、NUMA ノードの境界について慎重に考慮することが重要です。この例では、仮想 CPU 10 個、RAM 128 GB が境界にあたります。1 個の NUMA ノードの CPU と RAM のサイズ境界を上回ると、仮想マシンは離れた場所からメモリを取得するため、パフォーマンスが低下する可能性があります。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 1 9
巨大仮想マシンあるワークロードに対して、単一の NUMA ノードの CPU または RAM が十分なリソースを提供できない場合、 1 個の NUMA ノードよりも規模の大きい仮想マシンを使用することをお勧めします。そのような仮想マシンでは、リモート メモリへのアクセスが発生するものの、追加の CPU または RAM が必要になる場合に比べるとパフォー
マンスに与える影響は少ないため、パフォーマンスは向上します。
一般的に、できるだけ少ない数の NUMA ノードに収まるように仮想マシンをサイジングしてください。また、仮想マシンをオーバーサイジングしないでください。仮想マシンをオーバーサイジングすると、リモート メモリへの不要なアクセスが発生します。ESXi の CPU スケジューラは NUMA に対応しており、可能なかぎりリモート メモリにアクセスしないように設計されています。
仮想マシンの NUMA の局所性が低い場合、esxtop で N%L カウンタを確認します。NUMA の局所性に問題がない場合、N%L カウンタは 100 % です。詳細については、このドキュメントの後半にある 「付録 A： vSphere 関連の問題のトラブルシューティング」 を参照してください。
仮想 CPUSAP HANA 仮想マシンを本番環境用に構成する場合、システム上で実行する複数の仮想マシンの仮想 CPU リソースの合計が、ホストの CPU キャパシティを超えないようにします。ホストで CPU をオーバーコミットメントしないようにしてください。ホストの CPU キャパシティに過剰な負荷がかかると、仮想データベースのパフォーマンスが低下する可能性があります。
仮想化した SAP HANA に仮想 CPU を過剰に構成すると、vSphere が必要とするリソースがわずかに増加します。これは、未使用の仮想 CPU もタイマー割り込みを使用するためです。vSphere は、仮想マシンの仮想 CPU を同時にスケジューリングして、可能なかぎり仮想 CPU を並行して実行しようとします。未使用の仮想 CPU によって、使用されている仮想 CPU でのスケジューリングに制約が生じ、全体のパフォーマンスが低下する可能性があります。
図 9： 1 個の NUMA ノードにちょうど収まる非常に小規模な SAP HANA 仮想マシン
図 10： 2 個の NUMA ノードにちょうど収まる小規模な SAP HANA 仮想マシン
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 0
ハイパースレッド プロセッサでハイパースレッドを使用すると、単一の物理コア上で複数の命令スレッドを実行できます。コアのリソースの多くは、実際はコア間で共有されていますが、論理スレッドを追加することで、パフォーマンスを通常 10 ～ 20 %
の範囲で向上させることができます。vSphere と SAP HANA を実行するシステムでは、ハイパースレッドを有効にすることをお勧めします。
vSphere 仮想マシンに割り当てられている仮想 CPU は、仮想 CPU を実行している物理サーバ上の論理スレッドにマッピングされます。ハイパースレッドが有効である場合、各物理コアの論理スレッドは 2 個になります。CPU
リソースのすべてを仮想マシンに割り当てるには、割り当てられる仮想 CPU の数とサーバ上の論理スレッドの数が同じである必要があります。たとえば、Intel® Xeon® プロセッサの E7 シリーズ （Westmere-EX） ベースのサーバで、ソケットが 4 個あり、ソケットごとに 10 個のコアがある場合、物理コアは 40 個、論理スレッドは 80 個となります。
HANA ベースの仮想マシンの仮想 CPU、物理コア、ハイパースレッドに関するサイジングと構成の詳細については、このドキュメントの後半にある 「仮想化した SAP HANA のサイジング」 のセクションを参照してください。
メモリに関する検討事項メモリについてのベスト プラクティスは、SAP HANA に構成済みの RAM と同じ容量のメモリ予約を構成することです。メモリをオーバーコミットメントしないでください。本番環境以外の複数の SAP HANA インスタンスを同じホストに統合する場合、vSphere は同じオペレーティング システムを実行するすべての仮想マシン間でメモリを
共有できます。この場合、vSphere は独自の透過的なページ共有の技術を使用してメモリを再利用するため、物理
RAM を使用する場合に比べて少ないメモリでデータベースを実行できます。
このとき、ESXi のカーネルと仮想マシンのオーバーヘッドのためにメモリを残すようにしてください。控えめな
見積もりとして、システムのメモリの最大 5 % をこのオーバーヘッドのために使用して問題ありません。メモリ オーバーヘッドを仮想マシンに割り当てないでください。
メモリ オーバーヘッドの詳細については、バージョン 5.5 用の 『vSphere リソース管理』
（http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-
resource-management-guide.pdf） の 「メモリ リソースの管理」 のセクションを参照してください。
ネットワーク
SAP HANA 用のネットワーク構成には、分散仮想スイッチと VMXNET 3 の最適化が含まれます。ここで、それぞれについて説明します。
分散仮想スイッチSAP HANA は分散仮想スイッチを使用します。vSphere 4.0 より前のバージョンでは、仮想インフラストラクチャ管理者が各ホスト上で標準スイッチを構成しました。分散仮想スイッチを使用すると、複数の vSphere ホストに
わたる仮想マシンのネットワークを、1 台の仮想スイッチとして、vCenter Server から vSphere Client によって一元管理できます。
vSphere ホストを追加するときに、そのホストのネットワークを構成する必要はありません。ホストは定義されたポート グループ （SAP HANA トラフィック専用か、あるいはその他のアプリケーション固有のトラフィック専用） に追加されます。
プライベート VLAN （PVLAN） のサポートに加え、分散仮想スイッチは受信および送信ネットワーク トラフィックのシェーピングにも対応します。VMware の標準スイッチは、vCenter Server の管理ユーザー インターフェイスを使用して、ダウンタイムなしで分散仮想スイッチに容易に移行できます。
VMXNET 3ベスト プラクティスは、SAP HANA 仮想マシン用に VMXNET 3 仮想 NIC を使用することです。VMXNET 3 は、パフォーマンスを向上して遅延の影響を受けやすいワークロードに対応するために設計された、最新世代の準仮想化
NIC です。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 1
VMXNET 3 は、マルチ キューのサポート、受信側のスケーリング、IPv4/IPv6 オフロード、MSI/MSI-X 割り込み配信などの高度な機能を提供します。
物理 NIC が Interrupt Coalescing を実装するのと同じ理由で、VMXNET 3 は、同機能をデフォルトでサポートします。Interrupt Coalescing によって、複数の仮想 CPU が搭載された、ワークロードを並列処理する仮想マシンへのスループットを向上できます。
Red Hat Enterprise Linux 6 と SUSE Linux Enterprise Server 11 SP1 には、VMXNET 3 NIC のサポートが組み込まれています。これらのゲスト OS では、VMware Tools を使用しなくても、VMXNET 3 ドライバ構成を有効にできます。
ストレージ
SAP HANA 環境で一般的なストレージ構成は、Virtual Machine File System （VMFS）、データストア、準仮想化
SCSI アダプタなどです。
ここで、ストレージ機能について説明します。
• Virtual Machine File System （VMFS）
• データストア
• 準仮想化 SCSI アダプタ
• 複数の仮想 SCSI コントローラ
• ファイル システムに関する検討事項と調整
• SUSE Linux の I/O スケジューラ
Virtual Machine File SystemVMware vSphere Virtual Machine File System （VMFS） は、仮想マシン用に最適化されており、パフォーマンスに優れた、クラスタ化されたストレージの仮想化を実現します。VMFS を使用すると、各仮想マシンが小さいファイル
セットにカプセル化されます。VMFS は、物理 SCSI ディスクやパーティション上にあるファイルにアクセスするために使用される、デフォルトのストレージ管理インターフェイスです。VMFS では、複数の ESXi インスタンスが、仮想マシンの共有ストレージに同時にアクセスできます。また、vSphere vMotion、vSphere DRS、vSphere HA
などの仮想化分散インフラストラクチャ サービスを、ESXi ホストのクラスタ内で実行できます。
仮想環境のパフォーマンスと管理性を調整するためには、VMFS を使用してデータベースを展開することが一般的なベスト プラクティスです。パフォーマンスを向上する目的で、Raw Device Mapping （RDM） が誤って選択される場合がありますが、データベースに関連する 2 つの主要なワークロードは、ランダム読み取り / 書き込みと順次書き込みであり、この 2 つは、VMFS に展開しても RDM を使用しても、スループットのパフォーマンス特性はほぼ同じです。
SAP HANA TDI と IBM General Parallel File System IBM General Parallel File System （GPFS） は、パフォーマンスが高い、優れた共有ディスク管理ソリューションです。IBM 社の SAP HANA フレームワークの主要なコンポーネントの 1 つで、ローカルのディスク リソースを共有できるようにします。
TDI を使用すると、既存の共有エンタープライズ ストレージ環境を使用できるようになるため、vSphere を使用して
SAP 環境を仮想化する場合、GPFS は推奨されません。GPFS では、次の機能がサポートされません。
• vSphere vMotion、vSphere DRS、vSphere Fault Tolerance （FT）、クローン作成
• N-Port ID Virtualization （NPIV）
• 複数のバージョンの vSphere ESXi における IBM GPFS の使用
• パーシステント リザベーション （VMware ソリューションに対しては使用できない）
また、GPFS では、物理互換モードの Raw Device Mapping （RDM） のみがサポートされます。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 2
データストアvSphere は、仮想ディスクを格納するためにデータストアを使用します。データストアは、ストレージ レイヤーを抽象化して、ストレージ デバイスの物理属性を仮想マシンに認識させないようにします。VMware 管理者は、複数のデータストアを作成して、これを単一の統合ストレージ プールとして使用するか、またはさまざまなアプリケーション
ワークロードを分離するための複数のデータストアとして使用できます。
従来のストレージ エリア ネットワーク （SAN） 環境では、要求の厳しい I/O プロファイルをアプリケーションが持っている場合、専用データストアを作成することが一般的なベスト プラクティスです。データベースはこのカテゴリに該当します。vSphere で専用データストアを作成すると、データベース管理者は、さまざまなアプリケーションに対して個別の SLA を定義できます。これは、物理環境で専用の論理ユニット （LUN） をプロビジョニングすることに似ています。
これまでの説明をまとめると、vSphere 上で SAP HANA を使用する場合、データストアを次のように使用できます。
• SAP HANA のデータとログのために個別の分離されたデータストアを作成する。
• 複数の SAP HANA 仮想マシンのデータ用仮想マシン ディスク ファイルとログ用仮想マシン ディスク ファイルを、同じクラスのストレージ上にプロビジョニングできる。
• 仮想マシン ディスク ファイルをゼロ初期化される形式でプロビジョニング （eager zeroed thick） して、後で必要に応じてゼロ初期化されること （lazy zeroed） を回避する。
準仮想化 SCSI アダプタ ベスト プラクティスとしては、システム ソフトウェアと SAP HANA のバイナリをホストするディスクで使用するためにプライマリ アダプタを作成し、SAP HANA のデータとログをホストするデバイス用に準仮想化 SCSI
（PVSCSI） アダプタを別途作成します。PVSCSI アダプタは高性能のストレージ アダプタです。これを使用すると、スループットが向上し、CPU 使用率が低下する可能性があります。
SAP HANA 用に PVSCSI アダプタを構成するには、VMware ナレッジベースの記事 「ディスクを構成して
VMware 準仮想化 SCSI （PVSCSI） アダプタを使う （2053209）」
（http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externa
lId=2053209） を参照してください。
複数の仮想 SCSI コントローラ複数の仮想 SCSI コントローラを作成して、データベースのワークロードに関連する I/O を分散させることをお勧めします。複数の SCSI コントローラを作成する場合、それらのコントローラをデータベースまたはオペレーティング
システムのワークロードのプロファイルにマッピングします。オペレーティング システムと SAP HANA のバイナリを 1 個の SCSI コントローラ上に配置し、SAP HANA のデータ ファイルとログ ファイルを別の SCSI コントローラ上に配置します。
複数の仮想 SCSI コントローラを使用する主な目的は、データベースの 1 件のトランザクションまたは 1 件のクエリ内の作業単位を並列処理することです。この場合、複数の SCSI コントローラを使用して 1 件のトランザクション内の 1 個の作業単位を並列処理することの影響について、慎重に考慮します。たとえば、データ ファイル用に複数の
SCSI コントローラを作成すると、スループットが向上しますが、遅延も増加する可能性があります。
仮想 SCSI ドライバ 仮想デバイス 説明 推奨サイズ 仮想プール
LSI Logic 0:0 /usr/sap 50 GB RAID 5
準仮想化 1:0 /hana/data/<SID> メモリの 3 倍 RAID 5
準仮想化 2:0 /hana/log/<SID> メモリと同じ RAID 1
準仮想化 3:0 /hana/shared/<SID> N/A RAID 5
表 6： 仮想 SCSI コントローラ用の SAP HANA のレイアウト
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 3
ファイル システムに関する検討事項と調整 物理環境と同様に、ファイル システムが調整されていないと、パフォーマンスに大きな影響が生じます。ファイル
システムの調整に関する問題は、データベースにかぎらず、I/O 負荷の高いあらゆるワークロードで発生します。vSphere VMFS のパーティションに関する推奨事項を次に示します。
• ほかのディスク ベースのファイル システムと同様に、パーティションが調整されていない場合は VMFS に問題が発生します。64 KB の境界に従って自動的に調整されるように、vSphere Client または vSphere Web Client
を使用して VMFS パーティションを作成します。
• 手動で VMFS パーティションを調整するには、パーティション開始ブロックに関するストレージ ベンダーの推奨事項を確認してください （たとえば、EMC VNX は 128 K のオフセットを使用）。
SUSE Linux の I/O スケジューラLinux 2.6 カーネルの時点で、デフォルトの I/O スケジューラは Completely Fair Queuing （CFQ） です。この
スケジューラは、ほぼすべてのワークロードに対して効果的なソリューションです。デフォルトのスケジューラは、VMDK ベースおよび RDM ベースの仮想ストレージ ソリューションで、すべてのディスク I/O に影響します。仮想環境では、多くの場合、ホストとゲストの両方のレイヤーで I/O をスケジューリングすることにはメリットがありません。
ホスト OS が管理する 1 個のファイル システムまたは 1 個のブロック デバイス上のストレージを複数のゲストが使用する場合、ホストはすべてのゲストからの要求とストレージの物理レイアウトを認識するため、ホストのほうが効率的に I/O をスケジューリングできる可能性があります。ストレージの物理レイアウトは、ゲストの仮想ストレージとは直線的には対応しない場合があります。
テストの結果によると、仮想化した Linux ゲストでは、Noop I/O スケジューラが優れたパフォーマンスを示します。ESXi は非同期的でインテリジェントな I/O スケジューラを使用します。そのため、I/O スケジューリングを ESXi
に処理させることで、仮想ゲストのパフォーマンスが向上します。
詳細については、「Linux 2.6 kernel-based virtual machines experience slow disk I/O performance (2011861)」 （http://kb.vmware.com/kb/2011861） を参照してください。
vSphere 上で使用する SAP HANA の最適化一般的に、VMware の仮想化ソリューション上で使用する SAP HANA のテストと特性調査を行う場合、次に示す
ESXi のパフォーマンスの調整を適用しています。このセクションでは、VMware の仮想化環境で SAP HANA を実行する場合に合わせてカスタマイズされた、さらなる最適化の方法について説明します。
vSphere は異種混在のクラスタ環境で複数の仮想マシンを実行できます。SAP 環境を作成する場合、アプリケーションの所有者と仮想インフラストラクチャの管理者は、パフォーマンスの絶対値と多様性について、それぞれのメリットを比較して評価する必要があります。
ここで、さらなる最適化について説明します。
• ワークロードの最適化
• 仮想 NUMA を物理 NUMA に固定
• NIC の最適化
• 仮想 SCSI アダプタの最適化
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 4
ワークロードの最適化
本番環境の SAP HANA 仮想マシンのパフォーマンスを最適化するには、ここで説明する設定を使用してください。CPU のスケジューリングと優先度については、これらの設定によって仮想 CPU の量と仮想 NUMA の移行を削減することで、パフォーマンスの向上を実現できます。また同時に、本番環境の SAP HANA 仮想マシンの優先度も向上させることができます。
仮想 NUMA を物理 NUMA に固定仮想 CPU を固定して、仮想 NUMA ノードが別の物理 NUMA ノードに移行しないようにすることができます。仮想マシンの .vmx ファイルの構成設定でパターンを指定するか、vSphere Client の詳細設定パラメータ セクションを使用して、各仮想 CPU を物理 NUMA ノードに固定します。
次に例を示します。
sched.vcpu0.affinity = "0-19"
….
sched.vcpu9.affinity = "0-19"
sched.vcpu10.affinity = "20-39"
…..
sched.vcpu19.affinity = "20-39"
sched.vcpu20.affinity = "40-59"
…..
sched.vcpu29.affinity = "40-59"
sched.vcpu30.affinity = "60-79"
……
sched.vcpu39.affinity = "60-79"
遅延を小さくする設定 SAP HANA の遅延を最小限に抑えるために、[待ち時間感度 ] を [高 ] に設定することをお勧めします。手順を次に示します。
SAP HANA 仮想マシンの設定画面に移動します。[仮想マシンオプション ] タブをクリックし、[設定 ] を選択して、[待ち時間感度 ] を [高 ] に設定します。
パフォーマンスをさらに向上し、遅延をさらに軽減するには、仮想マシンのメモリを事前に割り当てるように設定します。
SAP HANA 仮想マシンの [設定の編集 ] に移動して、[オプション ] タブをクリックし、[詳細 ] - [設定パラメータ ]
の順に選択します。次の 2 行を追加します。
sched.mem.prealloc = "TRUE"
sched.swap.vmxSwapEnabled = "FALSE"
NIC の最適化
ほとんどの NIC には Interrupt Coalescing を無効にするメカニズムがあり、通常は、ethtool コマンドを使用するかモジュール パラメータを設定して、このメカニズムを使用します。
ESXi ホストで物理 NIC の Interrupt Coalescing を無効にする必要があるかどうかを判断するために、次のコマンドを入力します。
• # esxcli system module parameters set -m ixgbe -p "InterruptThrottleRate=0"
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 5
この例は、ixgbe と呼ばれる Intel® 社の 10 GbE ドライバに対するものです。NIC に対する適切なモジュール パラメータを確認するために、まず、次の ESXi コマンドを使用して、ドライバを確認します。
• # esxcli network nic list
次に、使用されているドライバのモジュール パラメータの一覧を確認します。
• # esxcli system module parameters list -m <ドライバ名 >
Large Receive Offload （LRO） は、スループットの向上と CPU 使用率の低減に役立つ VMXNET 3 の機能です。LRO は、受信した複数の TCP セグメントを単一の大きな TCP セグメントに統合してから、ゲストの TCP スタックに送信します。
ただし、遅延の影響を受けやすく、TCP に依存するアプリケーションでは、小さな TCP セグメントを大きな TCP
セグメントに統合するためにかかる時間によって、遅延が増加します。LRO は、TCP 遅延 ACK （大きな TCP セグメントを 2 個受信してから ACK （確認応答） を送信する技術） などの TCP アルゴリズムに影響を与える可能性が
あります。また、アプリケーションの End-to-End の遅延を増加させます。
LRO を無効化することがアプリケーション スタックの要件にとってメリットがあるかどうかを確認するには、Linux ゲスト OS で VMXNET 3 ドライバを再読み込みします。
• # modprobe -r vmxnet3
/etc/modprobe.conf （Linux のバージョンによって異なる） に次の行を追加します。
• options vmxnet3 disable_lro=1
次に、ドライバを再読み込みします。
• # modprobe vmxnet3
仮想 SCSI アダプタの最適化
SAP HANA を実行する Linux ベースのゲスト内で PVSCSI ドライバのキューの深度を増加させるには、Linux
カーネルの起動オプションを追加します。
vmw_pvscsi.cmd_per_lun=1024
vmw_pvscsi.ring_pages=32
導入に関するヒントとガイドラインSAP HANA を vSphere 上で使用するためのヒントとガイドラインについて、次の表で説明します。
コンポーネント 設定
SUSE オペレーティング システム
• XFS ファイル システム
• Noop I/O スケジューラ
• ハイパースレッドを有効にする
• PVSCSI に関するカーネル パラメータを追加する
– vmw_pvscsi.cmd_per_lun=1024
– vmw_pvscsi.ring_pages=32
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 6
コンポーネント 設定
仮想マシンの BIOS
• 有効にする機能
– Virtualization Technology （VT）
– ターボ モード
– ハードウェア ベースの仮想化のサポート
– ハイパースレッド
– XD ビット （vSphere vMotion と vSphere DRS のために必要）
• 無効にする機能
– ノードのインターリーブ
– C1E Halt ステート
– 電力管理： [High Performance] に設定
• 使用しない機能： [Video BIOS Shadowable]、[Video RAM Cacheable]、オン ボードのオーディオ、オン ボードのモデム、オン ボードのシリアル ポート、オン ボードのパラレル ポート、オン ボードのゲーム ポート、フロッピー ドライブ、CD-ROM、USB
SAP HANA 仮想マシン
• 仮想ハードウェア バージョン 10 以降を使用する
• ラージ （ヒュージ） ページを使用する
• CPU またはメモリ リソースをオーバーコミットメントしない
• 必要最小限の NUMA ノードを使用する
• 仮想マシンをオーバーサイジングしない
• VMXNET 3 仮想 NIC を使用する
• I/O デバイス用に準仮想化 SCSI ドライバを使用する
• 仮想マシンの [待ち時間感度 ] を [高 ] に設定する
• SAP HANA のバイナリを実行するオペレーティング システムで LSI Logic SCSI ドライバを使用する
• ファイル システムのオフセットを調整する （例： VNX では 128 K のオフセットを使用する）
• 仮想マシン ディスク （VMDK） ファイル システムを使用する
• SAP HANA のデータとログ ファイルのために専用の分離されたデータストアを作成する
• 仮想マシン ディスク ファイルをゼロ初期化される形式でプロビジョニング （eagerzeroed thick） して、後で必要に応じてゼロ初期化されること （lazy zeroed） を回避する
• 複数の仮想 SCSI コントローラを使用する
• インストール後に SAP HANA の 「ゴールド」 クローンまたはテンプレートを作成する
• 仮想マシンのメモリを事前に割り当てるように設定する
vSphere 5.5 ホスト
• CPU とゲスト OS の組み合わせに基づいて最適な仮想マシン モニタを vSphere が選択できるようにする
• ハードウェア アシストによるメモリ仮想化： CPU/MMU 仮想化オプションを自動に設定
• 分散仮想スイッチを使用して、管理を容易にするとともに、データベース、アプリケーション、および vSphere vMotion のトラフィックをそれぞれ別の VLAN に分離する
表 7： SAP HANA を vSphere 上で使用するためのヒントとガイドライン
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 7
仮想化した SAP HANA のサイジング
仮想環境向けに SAP HANA をサイジングする場合、物理環境向けに SAP HANA をサイジングするのとはいくつか違いがあります。それらの違いの原因は、仮想マシンのサイズ制限、仮想 CPU から物理 CPU へのマッピング、仮想化によって生じるわずかなオーバーヘッドのコストです。基本的なプロセスとしては、SAP HANA データベースを通常のとおりに （物理環境と同じように） サイジングしてから、仮想化のために必要な調整を行います。
ここでは、仮想化した SAP HANA を適切にサイジングするために使用される要素のそれぞれについて、例を挙げながら説明します。次の要素について説明します。
• 仮想マシンの最大サイズ
• 仮想 CPU から物理 CPU へのマッピング
• メモリ オーバーヘッド
• SAP HANA のサイジング方法
• SAPS ベースの SAP HANA のサイジング
• SAP HANA の T シャツ サイジング
• 仮想マシンのパフォーマンスを最大化するためのサイジング
• システム全体のパフォーマンスを最大化するためのサイジング
• 複数の SAP HANA 仮想マシンを 1 台の ESXi ホストに展開する場合のサイジングの例
以降のセクションで、それぞれの要素について説明します。
仮想マシンの最大サイズvSphere 5.5 での仮想マシンの最大サイズは、仮想 CPU 64 個、RAM 1 TB です。これは、SAP HANA ハードウェア
アプライアンスとして使用される 4 ソケットや 8 ソケットのサーバよりも小規模です。これらの大規模な SAP
HANA ハードウェア アプライアンスを 1 台の仮想マシンに直接マッピングすることはできません。
仮想 CPU から物理 CPU へのマッピングSAP HANA に使用される Intel 社の最新世代のプロセッサには、ハイパースレッドという機能があります。ハイパースレッドを使用すると、各物理コアが 2 個の実行スレッドを持つことができます。2 個のスレッドは、同じ物理コアのリソースを共有します。パフォーマンスが 2 倍になるわけではありませんが、ほとんどの場合でパフォーマンスを
10 ～ 20 % 向上できます。
仮想マシン用に作成された仮想 CPU は、論理スレッド上で実行されるようにスケジューリングされます。仮想 CPU は、物理コアの論理スレッドに直接マッピングされます。
vSphere のデフォルトの動作では、仮想 CPU を別々の物理 CPU にスケジューリングします。まず、各物理コアの
1 個の実行スレッドを使用します。すべての物理コアで 1 個の仮想 CPU がスケジューリングされて実行されると、次に vSphere は各物理コアの 2 番目の論理実行スレッドを使用するように仮想 CPU をスケジューリングします。
サイジングの観点から見た場合、仮想 CPU は、パフォーマンスに関してはハイパースレッドが有効でない物理コアと同等です。ハイパースレッドを有効にしてパフォーマンスを 10 ～ 20 % 向上させるためには、仮想 CPU の数を
2 倍にする必要があります。たとえば、物理コアが 64 個あり、ハイパースレッドが有効である SAP HANA の物理サーバ システムは、仮想 CPU が 64 個、実行スレッドが 64 個あり、すべてを前述のサーバの物理コアにマッピングしている SAP HANA の仮想サーバ システム （仮想マシン） に比べて、パフォーマンスが 10 ～ 20 % 高くなります。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 8
メモリ オーバーヘッド仮想マシンは、作成時に割り当てられた RAM のすべてにアクセスして使用することができます。ただし、ESXi ハイパーバイザーを実行し、仮想マシンに割り当てられた仮想メモリを管理するために、メモリの一部が必要です。メモリの最適化技術が多数導入されているため、vSphere のお客様の多くは、このメモリ オーバーヘッドには気付きません。
本番環境の SAP HANA 仮想マシンは、すべてのメモリを予約するため、メモリ最適化技術を有効にできません。このことから、少量の RAM を割り当てずにホストに残しておき、ハイパーバイザーと仮想マシンのメモリ オーバーヘッドが必要とするメモリとして使用する必要があります。
非常に控えめな見積もりでは、オーバーヘッドのために SAP HANA 仮想マシンに割り当てずに残しておく必要がある
RAM の割合は、3 ～ 4 % です。たとえば、1 TB の RAM を搭載するシステムでは、約 30 ～ 40 GB を仮想マシンに割り当てずに残しておく必要があります。大規模な仮想マシンを 1 台作成して 980 GB を割り当てるか、仮想
マシンを 2 台作成してそれぞれに 490 GB を割り当てると、ハイパーバイザーと仮想マシンのメモリ オーバーヘッドのために十分なメモリを残すことができます。
SAP HANA 仮想マシン用に構成されるメモリの予約に、このメモリ オーバーヘッドが認識される点に注意してください。リソースのオーバーコミットメントが許可されている環境では、このメモリ オーバーヘッドについて計算したり構成したりする必要はありません。
SAP HANA のサイジング方法仮想化した SAP HANA システムのサイジングには、物理環境の SAP HANA システムのサイジングと同じ方法を使用します。システムを最初にサイジングする場合、SAP QuickSizer を使用するか、既存のシステムに基づいて
サイジングします。その結果、サイジングされたアプリケーションを実行するシステムに必要なパフォーマンスを表す数字が得られます。この数字は SAPS と呼ばれ、パフォーマンスの単位を表します。
SAP 社のパートナーは、提供されたベンチマークを使用してシステムのテストを行い、機能を SAPS に換算して評価します。SAPS のサイジングと合わせて、メモリのサイジングも実行する必要があります。圧縮されたメモリの必要サイズを決定したら、SAP HANA 仮想マシンのメモリを定義できます。
また、SAP アプリケーションのサイジングは、SAPS を単位として行われます。SAP HANA ハードウェア アプライアンスは、お客様が容易に構成および選択できるように、T シャツ サイジング （S、M、L） でサイジングされています。このサイジングは、ハードウェア ベンダーが提供します。SAP HANA では、これら 2 つの手法を組み合わせて使用します。次に、それぞれの手法について説明します。
SAPS ベースの SAP HANA のサイジング
SAP Application Performance Standard （SAPS） は、SAP 環境内のシステム構成のパフォーマンスを示す、ハードウェアに依存しない値です。SAPS は、Sales and Distribution （SD） ベンチマークから計算されます。100 SAPS は、1 時間に 2,000 件の受注項目を完全に処理する能力として定義されます。
SAPS を使用して、SAP HANA システムの CPU リソース要件を計算できます。SAP HANA はインメモリ プラットフォームなので、SAP HANA システムのメモリのニーズは、キャパシティのサイジングに基づいて計算されます。通常、このサイジングはお客様が SAP 社またはパートナーと連携して実施します。この作業で使用するツールや
リソースは、仮想環境でも物理環境でも同じです。最初のサイジングに関するこれらの値が決定したら、その値を
使用して、SAP HANA 仮想マシンと vSphere ホストのサイズを定義できます。
サイジングの詳細については、「SAP Service Marketplace」 （https://service.sap.com/sizing） を参照してください
（この Web サイトにアクセスするには、標準の SAP サポート ポータル認証情報が必要です）。
CPU のパフォーマンスは、新しいリリースごとに向上しています。仮想マシンの SAPS の評価は、その仮想マシンを実行している物理コアのパフォーマンスに依存します。SAP HANA については、現在、Intel® Xeon® プロセッサ
E7 シリーズ （Westmere-EX） と Intel® Xeon® プロセッサ E7 v2 シリーズ （Ivy Bridge-EX） がサポートされています。つまり、特定の仮想マシンの SAPS 評価は、その仮想マシンを実行しているプロセッサによって異なる可能性があります。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 2 9
Intel E7 CPU について、vSphere 上で実行される SAP アプリケーションの、公式に発表されたベンチマーク結果は存在しません。そのため、SAP が認定した Westmere-EX と Ivy Bridge-EX CPU に関する、公式に発表されたコア単位の SAPS の値の平均を使用します。値を次の表にまとめました。
表では、Intel Xeon プロセッサ E7 コアのそれぞれについて、仮想環境での SAPS の値の平均も示します。この場合、仮想化のオーバーヘッドによって、値は 10 % 低下します。また、1 台のサーバで利用可能なすべての実行スレッドを 1 個のアプリケーションまたはデータベースのために使用すれば、ハイパースレッドによってパフォーマンスが
20 % 向上する可能性があります。
この 2 つの仮定に基づいて、仮想環境でハイパースレッドを使用しない場合のコアあたりの SAPS の平均は、次の公式を使用して計算できます。
仮想環境の SAPS = 物理環境の SAPS / 1.1 （オーバーヘッド） / 1.2 （ハイパースレッド）
注： 次の表では平均値を示しています。特定のハードウェア ベンダーが、自社の特定の SAP HANA システムについて述べる場合、より高い値、またはより低い値を使用する可能性があります。
表 8 は、Westmere-EX CPU の CPU コアあたりの利用可能な平均 SAPS サイジング値です。
CPU 物理環境でハイパースレッドを使用する場合のコアあたり SAPS の平均
仮想環境でハイパースレッドを使用しない場合のコアあたり SAPS の平均
Intel Xeon プロセッサ E7 2870 1745 1320
Intel Xeon プロセッサ E7 4870 1730 1310
Intel Xeon プロセッサ E7 8870 1670 1260
表 8： Intel Westmere-EX CPU コアの SAPS の値
表 9 は、Ivy Bridge-EX CPU の CPU コアあたりの利用可能な平均 SAPS サイジング値です。
CPU 物理環境でハイパースレッドを使用する場合のコアあたり SAPS の平均
仮想環境でハイパースレッドを使用しない場合のコアあたり SAPS の平均
Intel Xeon プロセッサ E7 v2 4890 2230 1680
表 9： Intel Ivy Bridge-EX CPU コアの SAPS の値
SAP Standard Application Benchmark の公開されている結果の詳細については、
http://www.sap.com/benchmark （英語） を参照してください。
SAP HANA システムは、メモリのサイジングも行う必要があります。詳細については、SAP BW on HANA と
SAP Business Suite on HANA の、公開されているサイジングのガイドラインを参照してください。
• 「SAP Business Suite powered by SAP HANA」 の 「Sizing for SAP Business Suite powered by SAP HANA」 （http://www.saphana.com/docs/DOC-2933）
• 「How NOT to size a SAP NetWeaver BW system for SAP HANA」
（http://scn.sap.com/community/netweaver-bw-hana/blog/2013/08/28/how-not-to-size-a-sap-
netweaver-bw-system-for-sap-hana）
注： SAP HANA 仮想マシンの仮想メモリの適切なサイズを定義するには、メモリのサイジングを行う必要があります。
前述のとおり、1 個の仮想 CPU は 1 個の論理実行スレッドにマッピングされるので、仮想 CPU は完全な物理コアと厳密に等しいわけではありません。ハイパースレッドが有効である場合、各物理コアの実行スレッドは 2 個になり
ます。つまり、両方の実行スレッドを使用するには、2 個の仮想 CPU が必要です。ただし、ハイパースレッドを
有効にして追加のスレッドを作成しても、コアのパフォーマンスは 2 倍にはなりません。ハイパースレッドを有効にすると、システム全体のパフォーマンスが通常約 10 % ～ 20 % 向上します。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 0
vSphere のデフォルトの動作では、仮想 CPU を別々の物理コアにスケジューリングし、基本的に、各仮想 CPU に独自のコアを提供します。すべての物理コアが使用されると、次に仮想 CPU を物理コアの 2 番目の論理スレッドにスケジューリングします。
ハードウェア ベンダーは、カスタムの SAPS サイジングのほかに、事前構成済みの SAP HANA アプライアンス
システムも提供しています。
SAP HANA の T シャツ サイジング
SAP HANA のハードウェア ベースのアプライアンスは、事前構成済みのさまざまなサイズで提供されます。これを
SAP HANA の T シャツ サイズと呼びます。vSphere 5.5 は、仮想マシン 1 台ごとに最大で仮想 CPU 64 個、RAM 1 TB をサポートします。SAP HANA ハードウェア アプライアンスのサイズは、Westmere-EX または Ivy
Bridge-EX CPU に基づいています。これらの CPU は、プロセッサあたり最大で 10 個または 15 個のコアがあります。
利用可能な SAP HANA の T シャツ構成は、CPU とメモリの一定の比率に従います。その比率は、SAP BW on
HANA （BWoH） を使用するか、SAP Business Suite on HANA （SoH） を使用するかによって異なります。また、CPU のタイプによっても異なります。
次の表は、仮想化した SAP HANA の T シャツ サイズの例を示しています。ハードウェア アプライアンスと同じ
CPU とメモリの比率を維持しています。前のセクション 「SAPS ベースの SAP HANA のサイジング」 の延長として、次の表でも各構成について計算された SAPS の値を表示しています。
前述のとおり、仮想化のために少量のメモリが必要となるので、サーバに残しておく必要があります。搭載している物理メモリをすべて SAP HANA 仮想マシンに割り当てる予定の場合、SAP HANA 仮想マシンに割り当てるメモリを 3 ～ 4 % 削減する必要があります。たとえば、1 TB （1024 GB） の RAM があるシステムで、2 台の SAP HANA
仮想マシンをホストする予定であれば、ハイパーバイザーを実行するためのメモリを見越して、各仮想マシンを 512 GB
ではなく 490 GB にサイジングする必要があります。
注： T シャツ サイズの SAP HANA 仮想マシンを使用する前に、SAPS と RAM のカスタムのサイジングをお勧めします。カスタムのサイジングは、SAP アプリケーションと SAP HANA の実際のリソース要件に対応するように実行する必要があります。SAP HANA 上のカスタム SAP アプリケーションの SAPS と RAM の要件を定義したときに、コアとメモリの比率が T シャツ サイズの SAP HANA 仮想マシンと異なる場合があります。SAP HANA のサイジングに関する文書に準拠している構成は、完全にサポートされます。
次の表は、SAP BW powered by SAP HANA （BWoH） 用の Westmere-EX ベースのハードウェア プラットフォームにおける、仮想化した SAP HANA の T シャツ サイジングです。ハードウェアと同じ T シャツ サイジングを使用して、メモリと CPU の同じ比率を維持しています。表の例では、NUMA ノードのメモリの局所性を確保して、メモリが最大のパフォーマンスを発揮できる RAM の量を示しています。RAM の値は、サーバに搭載されている
実際に利用可能な RAM の量に適合させる必要があります。
ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
1 5 5 64 6560
1 10 10 128 13120
2 10 20 256 26240
4 10 40 512 52480
表 10： 仮想化した BWoH のサイジングの例： Westmere-EX （2.4 GHz）
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 1
次の表は、SAP BW powered by SAP HANA （BWoH） 用の Ivy Bridge-EX ベースのハードウェア プラットフォームにおける、仮想化した SAP HANA の T シャツ サイジングです。ハードウェアと同じ T シャツ サイジングを使用して、メモリと CPU の同じ比率を維持しています。
ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
1 5 5 64 8440
1 10 10 128 16890
1 15 15 128 25340
2 15 30 256 50680
3 15 45 768 76020
4 15 60 1024 101360
表 11： 仮想化した BWoH のサイジングの例： Ivy-Bridge （2.8 GHz）
次の表は、SAP Business Suite powered by SAP HANA （SoH） 用の Westmere-EX ベースのハードウェア
プラットフォームにおける、仮想化した SAP HANA の T シャツ サイジングです。ハードウェアと同じ T シャツ
サイジングを使用して、メモリと CPU の同じ比率を維持しています。表の例では、NUMA ノードのメモリの局所性を確保して、メモリが最大のパフォーマンスを発揮できる RAM の量を示しています。RAM の値は、サーバに搭載されている実際に利用可能な RAM の量に適合させる必要があります。
ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
1 5 5 64 6560
1 5 5 128 6560
1 10 10 256 13120
2 10 20 512 26240
3 10 30 768 39360
4 10 40 1024 52480
表 12： 仮想化した SoH のサイジングの例： Westmere-EX （2.4 GHz）
次の表は、SAP Business Suite powered by SAP HANA （SoH） 用の Ivy Bridge-EX ベースのハードウェア
プラットフォームにおける、仮想化した SAP HANA の T シャツ サイジングです。ハードウェアと同じ T シャツ
サイジングを使用して、メモリと CPU の同じ比率を維持しています。
ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
1 5 5 64 8440
1 15 15 192 25340
1 15 15 256 25340
2 15 30 512 50680
3 15 45 768 76020
4 15 60 1024 101360
表 13： 仮想化した SoH のサイジングの例： Ivy-Bridge （2.8 GHz）
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 2
注： SAP HANA は、ここに挙げた特定の構成でなくても仮想マシンとしてプロビジョニングできます。ただし、SAP が発行する SAP HANA のサイジングのガイドラインに従う必要があります。
SAP HANA 仮想マシンは、最低でも 5 コア、RAM 64 GB に構成して、仮想 CPU 64 個、RAM 1 TB に拡張することをお勧めします。このように柔軟な構成にすることで、事前構成済みの SAP HANA アプライアンス システムの指示に従ってサイジングするのではなく、実際のニーズに基づいて SAP HANA の各インスタンスをサイジングできます。
前述の T シャツ サイジングの例では、サーバでハイパースレッドが有効になっていて、仮想マシンは仮想 CPU ごとに最高のパフォーマンスを実現するように構成されていると想定しています。各仮想 CPU には、実行場所である物理コアがあります。つまり、仮想 CPU と物理コアは 1 対 1 でマッピングされており、さらに、可能な場合は物理 CPU
ソケットと仮想 CPU ソケットが 1 対 1 でマッピングされています。
システム全体のパフォーマンスを最大化して、仮想 CPU のためにハイパースレッドを使用するには、メモリの量はそのままで、仮想 CPU の数を 2 倍にする必要があります。
仮想マシンのパフォーマンスを最大化するためのサイジングある仮想マシンにおいて最高のパフォーマンスを実現するためには、各仮想 CPU に独自の物理コアが必要です。 つまり、仮想 CPU と物理 CPU が 1 対 1 で対応する必要があります。たとえば、64 個の仮想 CPU を搭載する大規模な仮想マシンがあり、各仮想 CPU が独自の物理コアで実行されているとします。この場合、64 個の仮想 CPU が
64 個の物理 CPU に相当し、ハイパースレッドは使用されていません。
システム全体のパフォーマンスを最大化するためのサイジング比較的新しい物理サーバには、仮想 CPU の構成の上限を上回る CPU コア / スレッドがあります。そのため、1 台の
サーバのすべてのスレッドを 1 台の仮想マシンに割り当てることはできません。SAP HANA 仮想マシンですべての論理スレッドを使用するには、複数の仮想マシンを作成する必要があります。ソケットが 4 個あり、ソケットごとに
10 個のコアがある Intel Westmere-EX CPU の場合、システムには合計で 80 個の論理スレッドがあります。たとえば、すべてのスレッドを使用するように仮想マシンを構成するには、4 台の仮想マシンを作成します。各仮想マシンが 20 個の論理スレッドを使用し、それぞれに割り当てられた 10 個の物理コアのみを使用するようにします。
複数の SAP HANA 仮想マシンを 1 台の ESXi ホストに展開する場合のサイジングの例
仮想化の使用例の 1 つに、SAP HANA の統合があります。複数の SAP HANA 仮想マシンを 1 台のサーバに統合するとき、SAPS のキャパシティと使用可能なメモリを超えないようにする必要があります。繰り返しますが、SAP 社は、限定的に、本番環境と本番環境以外のいずれの使用でも、SAP HANA の認定を受けた複数のサーバ上で複数の仮想マシンを実行することをサポートしています。
次の例は、仮想化された SAP HANA インスタンスを、1 台の 4 ソケットの vSphere ホスト上で統合するシナリオを示しています。表 14 は本番環境、表 15 は本番環境以外で使用する場合です。ESXi カーネルを運用するために
十分なリソースを残してあり、構成されたリソースがホストで利用可能なリソースを超えてないことが、表からわかります。
これらのサイジングの例からわかるように、サーバのコアとメモリの比率と SAPS キャパシティを維持することで、T シャツ サイジングの SAP HANA 構成を容易に調整できます。
注： 次の例では、SAP HANA 仮想マシンにより多くの RAM を割り当てることもできます。ESXi カーネルを運用するために必要なメモリの最大量は、実行中のすべての SAP HANA 仮想マシン インスタンスの RAM の合計の
3 ～ 4 % です。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 3
物理サーバ CPU 物理コア 物理コアの合計 RAM （GB 単位） SAPS
4 ソケット サーバ 4 10 40 1024 69280
SAP HANA 仮想マシン ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
SoH VM 1 2 10 20 512 26240
BWoH VM 2 2 10 20 256 26240
合計 40 768 52480
vSphere ESXi 用の残りリソース
CPU ハイパースレッド ハイパースレッドの合計 RAM （GB 単位） SAPS*
ESXi カーネル 4 10 40 256 16800
* この値は、ESXi カーネルを運用するために残された CPU リソースを示します。
表 14： サイジングの例： 4 ソケットの Westmere-EX （2.4 GHz）、RAM 1 TB、SAP HANA の認定を受けたサーバ
表 15 は、本番環境以外の例です。この例では、1 個の CPU ソケットが、並行して実行される 2 台の SAP HANA
仮想マシンによって使用されます。
物理サーバ CPU 物理コア 物理コアの合計 RAM （GB 単位） SAPS
4 ソケット サーバ 4 15 60 2048 133800
SAP HANA 仮想マシン ソケット （CPU） 仮想 CPU （コア） 仮想 CPU の合計 RAM （GB 単位） SAPS
SoH VM 1 2 10 20 1024 33790
BWoH VM 2 2 15 30 512 50680
BWoH VM 3 1 5 5 128 8440
SoH VM 4 1 5 5 256 8440
合計 60 1920 101350
vSphere ESXi 用の残りリソース
CPU ハイパースレッド ハイパースレッドの合計 RAM （GB 単位） SAPS*
ESXi カーネル 4 10 60 128 32450
* この値は、ESXi カーネルを運用するために残された CPU リソースを示します。
表 15： 本番環境以外でのサイジングの例： 4 ソケットの Ivy Bridge-EX （2.8 GHz）、RAM 2 TB、SAP HANA の認定を受けたサーバ
SAP HANA 仮想システムのストレージのサイジング
1 台の vSphere ホスト上で並行して実行される SAP HANA 仮想マシンについて、サポートできる台数は、使用するストレージの I/O キャパシティによって制限されます。RAM と CPU リソースの場合と同様に、I/O のオーバー
コミットメントもサポートされません。
SAP 社は、本番環境の SAP HANA システムについて、データのスループットと遅延の KPI を定義しました。これらの KPI は、本番環境での SAP HANA システムの使用を保証する最小要件の値です。
事前構成済みの SAP HANA アプライアンス サーバは、1 個の SAP HANA インスタンスについて、これらの KPI
要件を満たします。事前構成済みの HANA アプライアンスで 2 台以上の SAP HANA 本番仮想マシンを実行する
必要がある場合、I/O キャパシティを増加させる必要があります。
開発およびテスト用の SAP HANA インスタンスでは、SAP 社はこれらのストレージ要件を満たすことを必須としていませんが、推奨しています。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 4
1 台のサーバ上で実行する必要がある SAP HANA インスタンスまたは仮想マシンの数に応じて、SAP HANA 本番仮想マシンの台数を乗算して、KPI の値を増やす必要があります。
使用されるストレージが、本番環境の SAP HANA システムに求められるデータのスループットと遅延の KPI 要件を満たせるかどうかを測定するために、SAP 社は、専用のツールである SAP HANA Hardware Configuration
Check Tool3 をリリースしました。選択した SAP HANA アプライアンス サーバのストレージで利用できる I/O
キャパシティが十分でない場合、アプライアンス ベンダーのガイドラインにしたがって、ローカル ストレージの
キャパシティをアップグレードする必要があります。
このドキュメントの前のセクションで説明したとおり、SAP HANA の別の展開方法には、SAP HANA Tailored
Data Center Integration （TDI） があります。
TDI では外部ストレージを使用できます。vMotion や vSphere HA のような、VMware の最も高度な機能には、外部ストレージが必要です。また、外部ストレージを使用すると、SAP HANA の要件であるデータのスループットと遅延の KPI を満たす構成にしやすくなるため、SAP HANA を仮想化する多くのお客様が、事前構成済みの SAP
HANA アプライアンスの代わりに TDI 構成を選択する可能性があります。
SAP HANA HW Configuration Check Tool と本番環境の SAP HANA インスタンスのストレージの KPI に関する詳細については、SAP ノート 1943937 を参照してください。
3 SAP_HANA_Hardware_Configuration_Check_Tool_1.4.pdf
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 5
付録 A： vSphere 関連の問題のトラブルシューティング
サポート リクエストの発行
VMware vSphere が適切に構成されておらず、ボトルネックの原因になっていると考えられる場合、My VMware
（http://www.vmware.com/support/contacts/file-sr.html） でサポート リクエストを発行してください。
また、次の点を確認してください。
• 「ESXi / ESX 環境での仮想マシンのパフォーマンス トラブルシューティング (2019905)」
（http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externa
lId=2019905） で説明されているトラブルシューティングの手順に従ってください。
• すべてのベスト プラクティスを適用していることを確認してください。『Performance Best Practices for
VMware vSphere 5.5』 （http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf） を参照してください。
• vm-support ユーティリティを実行して、サービス コンソールでコマンド 「vm support s」 を実行してください。このコマンドは、VMware が問題について診断するために必要な情報を収集します。問題が発生したときにはこのコマンドを実行することを推奨します。
• 詳細については、このドキュメントの末尾近くにある 「参考資料」 のセクションを参照してください。
vCenter Server と esxtop を使用して vSphere のトラブルシューティングを行う方法
ここでは、vCenter Server と esxtop を使用して vSphere のトラブルシューティングを行う方法について説明します。
vCenter Server のチャートの使用と vSphere の監視vCenter Server のパフォーマンス チャートによってパフォーマンスを監視する方法を理解するには、『vSphere の監視およびパフォーマンス』
（http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-
monitoring-performance-guide.pdf） を参照してください。
esxtop の基礎esxtop のメトリックの詳細については、「Interpreting esxtop Statistics」
（https://communities.vmware.com/docs/DOC-9279） を参照してください。
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 6
次の表は、トラブルシューティングのために使用できるメトリックについてまとめたものです。
画面 メトリック しきい値 説明
CPU %RDY 10 仮想 CPU の過剰なプロビジョニング、vSMP の過度な使用、または制限 （%MLMTD を確認） が設定されている。この %RDY 値は仮想マシンのすべての仮想 CPU の %RDY の合計。たとえば、1 個の仮想 CPU の %RDY の最大値が 100 % の場合、4 個の仮想 CPU の %RDY の最大値は 400 % になる。1 個の 仮想 CPU の %RDY が 20 の場合は、仮想 CPU が、VMkernel によるスケジューリングを待機するために時間の 20 % を費やしている状態であるため、問題があることを示す。
CPU %CSTP 3 vSMP の過度な使用。対象となる特定の仮想マシンの仮想 CPU の容量を減らす必要がある。
CPU %MLMTD 0 0 より大きい場合は、ワールドの実行が抑止される。考えられる原因は CPU の制限。
CPU %SWPWT 5 スワップされたページがディスクから読み取られるのを仮想マシンが待機している。メモリがオーバーコミットメントされている可能性がある。
MEM MCTLSZ 1 0 より大きい場合、ホストがオーバーコミットメント状態であるため、メモリを再利用するために、ホストが仮想マシンにバルーン ドライバの拡張を強制する。
MEM SWCUR 1 0 より大きい場合、ホストが過去にメモリ ページをスワップ済みである。 ホストがオーバーコミットメントされている可能性がある。
MEM SWR/s 1 0 より大きい場合、ホストはスワップから読み取りを行っている。原因は 過度なメモリのオーバーコミットメント。
MEM SWW/s 1 0 より大きい場合、ホストはスワップへの書き込みを行っている。原因は 過度なメモリのオーバーコミットメント。
MEM N%L 80 80 より小さい場合、仮想マシンの NUMA の局所性が乏しくなっている。仮想マシンのメモリ サイズが各プロセッサに対してローカルなメモリの容量より大きい場合、ESXi スケジューラはその仮想マシンで NUMA の最適化を使用しない。
NETWORK %DRPTX 1 ネットワーク使用率が高いため、送信パッケージがドロップされ、ハードウェアの負荷が増大している。
NETWORK %DRPRX 1 ネットワーク使用率が高いため、受信パッケージがドロップされ、ハードウェアの負荷が増大している。
DISK GAVG 25 DAVG と KAVG を参照。GAVG = DAVG + KAVG で表される。
DISK DAVG 25 このレベルでは、ディスクの遅延が発生していて、原因がストレージ アレイである可能性がある。
DISK KAVG 2 VMkernel が原因でディスクの遅延が発生している。通常、KAVG が高い場合はキューイングを示す。QUED を確認。
DISK QUED 1 キューが限界に達している。キューの深度の設定が浅すぎる可能性がある。最適なキューの値について、アレイ ベンダーに問い合わせる。
DISK ABRTS/s 1 ストレージからの応答がないため、仮想マシンによって中止が実行されたことを示す。Windows 仮想マシンの場合は、デフォルトで 60 秒後に発生する。原因はパスの障害、またはストレージ アレイが I/O を受け入れないため。
DISK RESET/s 1 1 秒あたりのリセットされたコマンド数。
表 16： esxtop の基礎： トラブルシューティングに使用するメトリック
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
テクニカル ホワイト ペーパー / 3 7
参考資料SAP HANA や、このドキュメント内で説明した VMware の製品および技術の詳細については、次のリンクと参考資料を確認してください。
VMware に関する参考資料
VMware vSphere
• VMware vSphere のドキュメント：
http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html
• VMware vSphere： http://www.vmware.com/jp/products/vsphere
• VMware vSphere のサポート センターの Web サイト：
http://www.vmware.com/jp/support/product-support/vsphere/index.html
• 『What's New in VMware vSphere 5.1 – Performance』：
http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Performance-
Technical-Whitepaper.pdf
• 『Performance Best Practices for VMware vSphere 5.1』：
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.1.pdf
• 『Performance Best Practices for VMware vSphere 5.5』：
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf
• 『VMware vSphere Distributed Switch Best Practices』：
http://www.vmware.com/files/pdf/techpaper/vsphere-distributed-switch-best-practices.pdf
• 互換性ガイドのページ内の VMware ハードウェア互換性ガイド （英語）：
http://www.vmware.com/resources/guides.html?src=WWW_BestMatch_US#utm_source=WWW_
BestMatch_US&utm_medium=src&utm_campaign=src-tagged-url
• VMware 互換性ガイド （互換性のあるストレージ デバイスおよびネットワーク デバイス）（英語）：
http://www.vmware.com/resources/compatibility/search.php
• 『Performance Characterization of VMFS and RDM Using a SAN』：
http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf
• 「ディスクを構成して VMware 準仮想化 SCSI （PVSCSI） アダプタを使う (2053209)」：
http://kb.vmware.com/kb/2053209
• サーバおよびデータセンター仮想化製品： http://www.vmware.com/jp/products/datacenter-virtualization.html
• VMware の主なドキュメント セット： http://www.vmware.com/jp/support/pubs
全般的な情報
• VMware Web サイト： http://www.vmware.com/
• 「VMware Licensing Help Center」： http://www.vmware.com/support/licensing/
• VMware コミュニティ、VMware Technology Network （VMTN）（英語）：
https://communities.vmware.com/community/vmtn
• VMware コミュニティ、VMware ナレッジベース （英語）：
http://communities.vmware.com/community/vmtn/resources/knowledgebase
• VMware のベスト プラクティスの Web サイト （英語）：
https://communities.vmware.com/community/vmtn/bestpractices
• Support Insider ブログ （英語）： http://blogs.vmware.com/kbtv/
ヴイエムウェア株式会社 〒 105-0013 東京都港区浜松町 1-30-5 浜松町スクエア 13F www.vmware.com/jpCopyright © 2014 VMware, Inc. All rights reserved. 本製品は、米国および国際的著作権法および知的財産法によって保護されています。VMware 製品は、http://www.vmware.com/go/patents のリストに表示されている 1 件または複数の特許対象です。VMware は、米国およびその他の地域における VMware, Inc. の登録商標または商標です。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。アイテム No.： VMW-TWP-BEST-PRACTICES-SAP-HANA-vSPHERE-A4-106 07/14
• VMware TV （英語）： http://www.youtube.com/user/vmwaretv
• VMworld TV （英語）： http://www.youtube.com/user/VMworldTV
• VMware KBTV （外部）（英語）： http://www.youtube.com/user/VMwareKB
SAP HANA に関する参考資料
• SAP Community Network の Web サイト SAP on VMware （英語）：
http://scn.sap.com/docs/DOC-27384
• SAP 社の Web サイト： http://www.sap.com/japan
• 「SAP Expands Preferred Strategic Collaboration With VMware, Unveils New Deployment Architecture
for SAP HANA」：
http://www.saphana.com/community/learn/news/blog/2012/11/27/sap-expands-preferred-strategic-
collaboration-with-vmware-unveils-new-deployment-architecture-for-sap-hana
• 『SAP HANA running on VMware vSphere VMs』：
（このドキュメントにアクセスするには、標準の SAP サポート ポータル認証情報が必要です）
https://websmp130.sap-ag.de/sap/support/notes/1788665
• SAP HANA の Web サイト （英語）： http://www.saphana.com/welcome
• SAP HANA の製品ページ： http://www.sap.com/japan/pc/tech/in-memory-computing-hana.html
• 「What is SAP HANA?」： http://www.saphana.com/docs/DOC-2272
• 「Overview - SAP HANA tailored data center integration」： http://www.saphana.com/docs/DOC-3633
• 「SAP HANA Master Guide」： http://www.saphana.com/docs/DOC-3817
謝辞このドキュメントの執筆にあたり、次の方々にご協力いただきました。
• Todd Muirhead、VMware、パフォーマンス チーム、スタッフ エンジニア
• Yury Baskakov、VMware、仮想マシン モニタ チーム、スタッフ エンジニア
• Michael Ho、VMware、仮想マシン モニタ チーム、スタッフ エンジニア
• Erik Rieger, Sr.、VMware、SAP グローバル アライアンス、システム エンジニア
• Vas Mitra、VMware、シニア システム エンジニア
• Bob Goldsand、VMware、グローバル アライアンス、スタッフ パートナー アーキテクト
• Jon Catanzano 氏、テクニカル ライター、コンサルタント
VMware vSphere 上で使用する SAP HANA の スケール アップ環境に関するベスト プラクティスと推奨事項
本資料は原題「Best Practices and Recommendations for Scale-up Deployments of SAP® HANA® on VMware vSphere®」の翻訳版です。
