インストールの準備

SAP HANA サイジングの実行

Objective

After completing this lesson, you will be able to SAP HANA サイジングを実行します。

SAP HANA のサイジングの一般的なコンセプト

ビジネスシナリオ

会社は、すべての SAP Business Suite および SAP BW システムを SAP HANA データベースに移行することを決定しました。SAP HANA データベースシステムをデプロイする (つまり、SAP HANA アプライアンスとしてデプロイする、または SAP HANA 調整済データセンタ統合 (TDI) アプローチに従ってデプロイする) のに最適な方法を調査する必要があります。

SAP HANA データベースのサイジングは、主にメインメモリサイズを中心に展開されます。データセットベースをメモリに保持するために必要なメモリは、ソースデータベースのサイズから決定されます。

SAP HANA では、メモリに格納されたデータが圧縮されます。圧縮率は使用されるシナリオによって異なるため、必要なメモリ量を見積もることはできません。メモリサイジングは、常に Quick Sizer for SAP HANA、または SAP HANA サイジングレポートおよび SAP ノートを使用して実行する必要があります。

ヒント

SAP HANA 圧縮の動作については、SAP ノート 2112604: FAQ - SAP HANA 圧縮 (FAQ - SAP HANA Compression) を参照してください。

この図は、データフローおよび処理コンポーネントを含む SAP HANA のインメモリデータベースシステムのアーキテクチャを示しています。

このメモリ値に基づいて、ハードウェア設定を選択することができます。SAP HANA データベースシステムは、SAP HANA 調整済データセンタ統合 (TDI) または SAP HANA アプライアンス設定としてデプロイできます。どちらの場合も、認定ハードウェアのカタログから適切なハードウェアを選択することができます。

注記

以下の情報は、SAP HANA データベースサーバのサイジングにのみ関連します。シナリオに応じて、SAP ABAP アプリケーションサーバなどの他のコンポーネントのサイジングを個別に考慮する必要があります。

この図は、さまざまなシナリオにおける SAP Business Suite (OLTP)、SAP BW/4HANA (OLAP)、および非 SAP ソースを比較したものです。

SAP HANA データベースのサイジングを行う場合のサイジングアプローチは、カスタマが使用する導入シナリオに依存します。可能なサイジングアプローチは以下のとおりです。

  • SAP アプリケーションおよび SAP HANA を初めて使用するカスタマは、Quick Sizer を使用して SAP HANA システムに必要なメモリのサイズを決定することができます。この方法は、グリーンフィールド導入を実行する既存の SAP カスタマも使用できます。
  • SAP HANA 上で実行するために既存の SAP NetWeaver ベースシステムの移行を望まれるカスタマは、必要なメモリを計算するサイジングレポートを実行できます。非 SAP NetWeaver ベースシステムの場合は、SAP ノート 1514966 に記載されているサイジング方法を使用します。
  • 大規模または複雑なシステムでは、SAP サイジングエキスパートによるサイジングが必要です。

以下のシナリオでは、SAP エキスパートのサイジングが必要です。

  • 複数の ERP ソースシステムを SAP HANA 上の 1 つの ERP システムに統合する。
  • ERP 機能をソースシステムから分離して SAP HANA システム上の ERP に移行する。
  • 大容量のレガシーシステムを SAP HANA に移行する。

SAP HANA 調整済データセンタ統合 (TDI) の概要

アプライアンスと TDI

SAP HANA オンプレミスデプロイメントでは、SAP HANA は専用のハードウェア上で実行されます。オンプレミス SAP HANA は、以下の機能を通じてデプロイされます。

  • SAP HANA アプライアンスでは、ハードウェアパートナが提供する実証済ハードウェア上で SAP HANA ソフトウェアコンポーネントが組み合わせられます。このアプローチは、Intel ベースのハードウェアプラットフォームでのみ有効です。このアプローチはシンプルですが、ハードウェアの柔軟性と既存の IT 運用プロセスへの準拠には制限があります。そのため、SAP HANA 調整済データセンタ統合は、カスタマに高い柔軟性を提供する新しいオプションとして提供されます。

  • SAP HANA 調整済データセンタ統合 (TDI) では、データセンタで SAP HANA を実行するために必要とされるハードウェアコンポーネントをより柔軟に選択できます。このアプローチを活用することによるメリットは以下のとおりです。

    • 既存のハードウェアコンポーネントと運用プロセスを再利用することによるハードウェアコストと運用コストの削減
    • SAP HANA 導入に対して既存の IT 管理プロセスを有効化することによるリスク軽減と価値実現までの時間の最適化
    • 既存のエコシステムを活用することによるハードウェアベンダ選定における柔軟性の向上

つまり、SAP HANA 調整済データセンタ統合は、IT 予算内に収め、導入サイクルを短縮するのに役立ち、ハードウェアイノベーションをより有効に活用して SAP HANA の導入を促進します。

SAP は、特定の SAP HANA 調整済データセンタ統合インフラストラクチャを正式に認定していません。代わりに、SAP はハードウェアコンポーネントをその SAP HANA ハードウェアパートナとともに認定しており、SAP HANA 調整済データセンタ統合にこれらの認定済設定のみを使用することを要件としています。

公式の SAP HANA Hardware Directory を使用し、認定済 SAP HANA アプライアンスのコンピューティングサーバと部品表がまったく同じもの (ストレージは含まない) として、ご使用のコンピューティングノードおよびストレージシステムが示されていることを確認してください。

SAP HANA のインストールは、有効な SAP Certified Associate - Database Administrator - SAP HANA (C_DBADM_2404) 以降を所有しているユーザが実行する必要があります。

SAP HANA ハードウェアパートナとその従業員には、この認定を受けている必要はありません。 ただし、SAP HANA ハードウェアパートナの外注先である会社またはその従業員は、HANA ソフトウェアインストールの実行を認定される必要があります。

注記

IBM では、カスタマのサイジングニーズを満たすハードウェアまたはパーティション設定への SAP サイジングのマッピングをサポートするプロセスを提供しています。詳細については、SAP ノート 2055470: SAP HANA on POWER 計画およびインストールの詳細 - 総括ノート (SAP HANA on POWER Planning and Installation Specifics - Central Note) を参照してください。

調整済データセンタ統合により既存のハードウェアコンポーネントとプロセスを再利用することで、ハードウェアコストおよび運用コストを削減できます。

注記

調整済データセンタ統合は自由性と柔軟性をもたらしますが、同時にインストールからランドスケープの稼働にわたって、システムに対するユーザの責任が増えることにもつながります。

SAP HANA 調整済データセンタ統合の一般要件

SAP および SAP HANA ハードウェアおよびソフトウェアパートナは、以下のガイドラインを使用する場合、SAP HANA 調整済データセンタ統合システム設定をサポートします。

  • 認定ハードウェアの使用: Certified and Supported SAP HANA Hardware directory に記載されているサーバのみがサポートされます。これらは、SAP HANA アプライアンスと同じサーバです。
  • 認定ストレージの使用: 認定およびサポート対象の SAP HANA ハードウェアディレクトリのエンタープライズストレージタブに一覧表示されているストレージのみが、データスループットおよび遅延の要件を満たしており、SAP によってサポートされています。
  • SAP HANA 認定者によって実行されるインストール: SAP HANA をインストールするユーザは、有効な証明書を持っている必要があります。現在有効な C_DBADM_xxxx 認定は、SAP Learning Web サイトにあります。

調整済データセンタ統合のストレージ要件

認定を受けるには、各ストレージベンダはベンダ固有の設定ガイドを提出する必要があります。このガイドでは、SAP HANA との最適なコラボレーションのためにストレージを設定する方法について説明されます。ストレージベンダは、カスタマにガイドを提供します。

SAP ノート 1900823 - SAP HANA ストレージコネクタ API (SAP HANA Storage Connector API) に添付されているストレージホワイトペーパーを入念に確認してください。

調整済データセンタ統合の SAP HANA ハードウェアおよびクラウド計測ツールを使用して、ストレージ KPI をチェックします。これは、ストレージ設定を変更するたびに実行できます。

注記

カスタマは、SAP Digital Business Services と連携して、本稼働前に SAP HANA ゴーライブチェックを実行することを検討する必要があります。

SAP HANA 調整済データセンタ統合の企業ネットワーク要件

企業ネットワークとの調整済データセンタ統合を導入すると、以下の前提条件を満たすハードウェア設定が SAP でサポートされます。

ネットワークセグメンテーション - すべてのネットワークを適切にセグメント化する必要があります。また、すべてのネットワークが同じコア/バックボーンスイッチに接続できる状態にある必要があります。以下のゾーン設定を使用することをお奨めします。

  • クライアントゾーン - アプリケーションサーバ、データソース、BI クライアントなどの SAP HANA クライアントによって使用されます。
  • 内部ゾーン - SAP HANA ワーカーノード間の通信 (ノード間通信) に使用されます。
  • ストレージゾーン - エンタープライズストレージへの読込と書込、およびバックアップインフラストラクチャへのバックアップの書込に使用されます。

内部ゾーンおよびストレージゾーンの場合、イーサネットの最小帯域幅要件は 10 GbE 以上です。

エンタープライズストレージにファイバーチャネルを使用する場合の最小帯域幅要件は、8 GbF 以上です。

注記

ネットワークセキュリティおよびセグメンテーションは、ネットワークスイッチベンダの機能であり、スイッチベンダの仕様に従って設定する必要があります。 

それ以外に、SAP による追加の承認は必要ありません。SAP では、データセンタ統合の設定を調整するためのネットワークコンポーネントの認証は導入していません。本稼動前に SAP HANA ゴーライブチェックを実行するには、SAP Active Global Support の関与を検討する必要があります。

重要な文書およびツール

SAP HANA 調整済データセンタ統合のサイジング方法

SAP HANA 調整済データセンタ統合設定のサイジング

SAP HANA 調整済データセンタ統合設定のサイジングは、以下の 3 つの主要ステップで構成されます。

  • 静的データと動的データの RAM サイジング

  • パーシスタンスストレージのディスクサイジング

  • クエリおよび計算の CPU サイジング

3 つのサイジングステップについては、以下のセクションで説明します。

静的および動的データの DRAM サイジング

SAP HANA 調整済データセンタ統合システムをサイジングするための最初のステップは、メモリサイジングの実行です。ユースケースに応じて、以下のリソースを使用します。

最初の SAP HANA メモリ初期サイジングを実行する場合は、両方の方法を使用することをお奨めします。Quick Sizer と SAP ノートによって、必要な SAP HANA メモリサイズが 2 つの異なる方法で決定されます。両方の値が類似している場合は、間違いがないことがわかります。

Suite on SAP HANA のサイジング

レポート /SDF/HDB_SIZING は定期的に更新および改良されるため、常に SAP ノートをチェックして、レポートの新しいバージョンを確認してください。レポート /SDF/HDB_SIZING は継続的に更新されるため、このセクションに示されているスクリーンショットは古い可能性があります。

最新バージョンのレポート /SDF/HDB_SIZING については、SAP ノート 1872170 "ABAP on HANA サイジングレポート (S/4HANA、Suite on HANA...)" を必ず確認してください。

この図は、HANA データベース設定の SAP メモリサイジング、RAM、ディスク、キャッシュ、およびその他のパラメータを示しています。

SAP BW/4HANA のサイジング

この図は、SAP ノードのメモリ要件、ディスク領域、および 2048 GB ノードのサイジングガイドラインの詳細を示しています。

サイジングノートには、メモリサイジング (カラム、ローストア、および追加コンポーネント)、データおよびログファイルのディスクサイジング、および CPU サイジングが記載されています。これらの SAP ノートの一部には、いくつかの追加情報が添付されています。

注記

レポート ZNEWHDB_SIZE は、システム負荷が低い状態で実行されます。Suite on SAP HANA システムのサイズに応じて、最大で 8 ~ 12 時間以上かかります。そのため、ロード前に連結システムでレポートをテストすることをお奨めします。

静的メモリ所要量と動的メモリ所要量

静的 RAM 要件と動的 RAM 要件は、以下のように区別されます。

  • 静的データメモリ要件

    静的 RAM 要件は、テーブルデータの保持に使用されるメインメモリの量を参照します。SAP HANA の静的メモリサイジングは、メモリに格納されるデータ量によって決定されます。特に、この数値は、対応するデータベーステーブルによってカバーされるディスク領域の量 (関連する索引を除く) に関連しています。

    データベースで圧縮がサポートされている場合は、非圧縮データの領域が必要であることに注意してください。この量のデータに基づいて、圧縮係数が適用され、SAP HANA に必要な RAM のサイズが決定されます。

  • 動的データメモリ要件

    新規データのロード時またはクエリの実行時に動的に登録されるオブジェクトには、追加のメモリが必要です。静的オブジェクトと同じ量のメモリを動的オブジェクト用に予約することをお奨めします。そのため、静的 RAM に 2 を乗じて合計 RAM を計算します。

SAP HANA 仮想化環境では、以下の SAP ノートも考慮する必要があります。

  • SAP ノート 2779240 - 仮想化環境のワークロードベースのサイジング (Workload-based sizing for virtualized environments)
  • SAP ノート 2652670 - VMware vSphere 上の SAP HANA VM (SAP HANA VM on VMware vSphere)
  • SAP ノート 1788665 - 仮想化された/パーティション化された (マルチテナント) 環境向けの SAP HANA サポート (SAP HANA Support for virtualized/partitioned (multi-tenant) environments)
  • SAP ノート 2315348 - 本稼働での VMware vSphere 6 上の SAP HANA (SAP HANA on VMware vSphere 6 in production)
  • SAP ノート 2393917 - 本稼働での VMware vSphere 6.5 および 6.7 上の SAP HANA (SAP HANA on VMware vSphere 6.5 and 6.7 in production)
  • SAP ノート 2284516 - SUSE Linux Enterprise ハイパーバイザ上で仮想化された SAP HANA (SAP HANA virtualized on SUSE Linux Enterprise hypervisors)
  • SAP ノート 2599726 - 本稼働での Red Hat Virtualization 上の SAP HANA (SAP HANA on Red Hat Virtualization in production)
  • SAP ノート 2659955 - Fusionsphere KVM 上の SAP HANA (SAP HANA on Fusionsphere KVM)
  • SAP ノート 2686722 - Nutanix Acropolis ハイパーバイザ上で仮想化された SAP HANA (SAP HANA virtualized on Nutanix Acropolis Hypervisor)

スケールアウト環境では、以下の SAP ノートも考慮する必要があります。

  • SAP ノート 2680623 - 同一の基礎となるサーバ上の複数の SAP HANA スケールアウトシステム (SID) (Multiple SAP HANA Scale-out Systems (SIDs) on the Same Underlying Servers)
  • SAP ノート 1886462 - HANA スケールアウト - /etc/hosts ファイルの設定
  • SAP ノート 1781986 - Business Suite on SAP HANA スケールアウト (Business Suite on SAP HANA Scale-out)
  • SAP ノート 1825774 - SAP Business Suite Powered by SAP HANA - 複数ノードサポート (SAP Business Suite Powered by SAP HANA - Multi-Node Support)
  • SAP ノート 1950470 - Business Suite on SAP HANA スケールアウトのハードウェアの前提条件 (Hardware Prerequisites for Business Suite on SAP HANA Scale-out)
  • SAP ノート 1702409 - HANA DB: BW on HANA の最適なスケールアウトノード数 (HANA DB: Optimal number of Scale-out nodes for BW on HANA)

SAP HANA ストレージ要件のサイジング

SAP HANA は、データの大部分をインメモリで保存および処理する、インメモリデータベースです。また、永続保管場所にデータを保存することで、データ損失を防ぐことができます。

追加のストレージサイジングの推奨事項については、SAP Note 1900823 - SAP HANA Storage Connector API に添付されている SAP HANA Storage Requirements ホワイトペーパーに記載されているガイドラインに従ってください。

永続ストレージでは、データボリュームとログボリュームが区別されます。SAP HANA のデータボリュームでは、変更されたデータをデータボリュームに書き込むことで、インメモリデータのコピーが保持されます。ログボリュームは、障害発生時にデータ損失ゼロでデータベースのリカバリを保証します。SAP HANA では、各トランザクションが REDO ログエントリの形式で記録されます。

データボリュームに必要なディスク領域

この図は、SAP HANA のサイジング結果と、ディスク上の必要なデータボリュームを見積もるための式を示しています。

セーブポイントまたはスナップショットが登録されるか、デルタマージ操作が実行されるたびに、メモリからマウントポイント/hana/data/<sid>にあるデータボリュームにデータが書き込まれます。

特定の SAP HANA システムのデータボリュームの推奨サイズは、サイジングレポートの計算結果と同じです。ディスク上の正味データサイズと 20% の追加空き領域を使用します。

図 "データボリュームサイズの決定" は、Suite on HANA のサイジングレポート結果の例を示しています。サイジングレポートには、ディスク上の正味データサイズが表示されます。必要な SAP HANA データボリュームサイズを決定するには、20% を加算します。この 20% の追加領域は、デルタマージ操作時に必要です。これは、該当するテーブルが一時的にディスクに短時間複製されるためです。

予想される前年比成長も含めます。たとえば、今後 3 年間では年間 15% です。これにより、サイズデータ式に加算する必要がある係数は 1,52 (= 1,153) になります。

非 SAP HANA データベースを SAP HANA に移行する際に、サイジングフェーズで計算されたディスク領域より多くのディスク領域が一時的に必要になる場合があります。Enterprise Storage では、これはストレージ全体のサイジングには関連しません。ストレージシステムでは、必要に応じて追加領域を提供できるためです。

ログボリュームに必要なディスク領域

ログボリュームの最小サイズは、2 つの SAP HANA セーブポイント間で発生するデータ変更の数によって異なります。このセーブポイントは、デフォルトでは 5 分ごとに登録されます。その期間にトランザクションを書き込むことによって実行されるデータ変更が多いほど、のログ/hana/log/<SID>ボリュームに書き込まれる REDO ログセグメントも多くなります。ログボリュームのサイジング時には、以下の点を考慮してください。

  • REDO ログは、データボリュームでセーブポイントエントリが使用可能になる前に上書きしないでください。上書きすると、SAP HANA データベースを再起動できなくなる可能性があります。

    セーブポイントの書込が遅延する状況が発生する可能性があります。たとえば、ソースデータベースとターゲット (SAP HANA) データベース間の入出力が遅い環境で、データベース移行プロセス中に高ワークロードを処理する必要がある場合に遅延が発生します。このような場合は、セーブポイントがデータボリュームに書き込まれていない限り、ログボリューム内の REDO ログの量は、すべてのログセグメントが満杯になるまで増え続けます。

  • このパラメータLOG_MODE = NORMALが設定されている場合、バックアップの実行前に REDO ログを上書きしないでください。そのため、インシデントや障害によってバックアッププロセスが中断される可能性がある状況に備えて、追加の領域を確保してください。この余分な領域によって、システム管理者は、ログボリュームが満杯になる前に、バックアッププロセスを修正して終了することができます。

ログボリュームサイズの決定

この図は、RAM が 512GB 以下であるシステムに対して想定される HANA システムメモリ所要量を示しています。

SAP HANA データベースのサイズと必要なログボリュームサイズの間には、直接的な相関関係はありません。ただし、図 "ログボリュームサイズの決定" の計算式は、本稼働の SAP HANA インストールのベストプラクティスおよび経験に基づいているため、使用することをお奨めします。データボリュームの計算式とは異なり、合計メモリ所要量 (RAM) に応じて計算されます。

ログボリュームサイズの例を以下に示します。

  • 128 GB システム ≥ サイズログボリューム = 64 GB

  • 256 GB システム ≥ サイズログボリューム = 128 GB

  • 512 GB システム ≥ サイズログボリューム = 256 GB

  • 1 TB システム ≥ サイズログボリュームミン = 512 GB

  • 2 TB システム ≥ サイズログボリュームミン = 512 GB

  • 4 TB システム ≥ サイズログボリュームミン = 512 GB

注記

インメモリデータベースサイズが 512 GB を超えるシステムの場合、前の式は最小値を表します。現時点では、本稼働の SAP 内部 SAP HANA インストールでの経験に基づいて、この値は SAP HANA のユースケースごとに十分であるとみなされます。ただし、前述のように、ログボリュームに格納されるデータ量は処理されるワークロードに依存するため、この値がログボリュームのサイジングには不十分である場合があります。

SAP HANA のインストールに必要なディスク領域

この図は、RAM およびストレージ容量に基づく単一ノードインストールの最小サイズと最大サイズを示しています。

単一ホスト設定の場合、すべてのバイナリ、トレース、および設定ファイルはに保存されます/hana/shared/<SID>。

注記

マニュアルファイルおよび設定パラメータファイルは、/hana/shared/<SID>ファイルシステムをまたはinstallation pathマウントポイントsapmntとして参照します。

ファイルシステムは/hana/shared/<SID>、共有ファイルシステムまたはローカルファイルシステムとして設定することができます。共有ファイルシステムとして設定/hana/shared/<SID>する利点は、単一ホストシステムからマルチホストシステムへの変換が容易になることです。

単一ノード SAP HANA システムについては、/hana/shared/<SID> の最小推奨ディスク領域が図 "共有単一ホストサイズの決定" に示されています (最大は 1 TB)。

以下は、単一ノードの SAP HANA インストールサイズの例です。

  • 単一ノード 128 GB 以上のサイズインストール = 128 GB

  • 単一ノード 256 GB 以上のサイズインストール = 256 GB

  • 単一ノード 512 GB 以上のサイズインストール = 512 GB

  • 単一ノード 1 TB 以上のサイズインストール = 1 TB

  • 単一ノード 2 TB 以上のサイズインストール = 1 TB

  • 単一ノード 4 TB 以上のサイズインストール = 1 TB

共有スケールアウトサイズの決定

この図は、ワーカーノードおよびスケールアウト係数に基づいて RAM インストールサイズを計算するための式を示しています。

複数ホスト (スケールアウト) システムの場合、すべてのバイナリ、トレース、および設定ファイルは、ファイルシステム /hana/shared/<SID> の、SAP HANA システムのすべてのワーカーノードに公開される共有ファイルシステムに保存されます。installation path (sapmnt) では、スケールアウト SAP HANA データベースシステムのトレースファイルを書き込むために、ワーカーノードごとに追加の領域が必要です。

本稼働の SAP HANA インストールの経験から、SAP HANA データベースのサイズが大きくなるほど、書き込まれるトレースが多いことがわかります。したがって、計算は合計メモリ所要量 (RAM) に基づきます。

スケールアウト SAP HANA システムの場合、/hana/shared/<SID> の推奨ディスク領域は、ワーカーノードの数によって異なります。特定のスケールアウトシステムの 4 つのワーカーノードごとに、1x ワーカーノード RAM のディスク領域が推奨されます。

以下は、スケールアウト SAP HANA インストールサイズの例です。

  • 3 システム、ノードあたり 512 GB サイズインストール = 1x 512 GB = 512 GB

  • 4 システム、ノードあたり 512 GB サイズインストール = 1x 512 GB = 512 GB

  • 5 システム、ノードあたり 512 GB サイズインストール = 2x 512 GB = 1 TB

  • ...

  • 9 システム、ノードあたり 512 GB サイズインストール = 3x 512 GB = 1.5 TB

  • ...

  • 3 システム、ノードごとに 1 TB サイズインストール = 1x 1 TB = 1 TB

  • 4 システム、ノードごとに 1 TB サイズインストール = 1x 1 TB = 1 TB

  • 5 システム、ノードごとに 1 TB サイズインストール = 2x 1 TB = 2 TB

  • 9 システム、ノードごとに 1 TB サイズインストール = 3x 1 TB = 3 TB

注記

スケールアウトシステムでは、ノードにロール Standby を設定することもできます。Standby ロールが設定されたノードは、障害が発生したノードのデータボリュームとログボリュームを引き継ぐため、追加のディスク領域を必要としません。

バックアップに必要なディスク領域

この図は、循環タイムラインを使用したフル、デルタ、および自動ログバックアップを含む 28 日間のバックアップサイクルを示しています。

完全データバックアップには、すべてのデータボリュームのペイロード全体が含まれます。バックアップディレクトリに必要なサイズは、データボリュームの合計サイズだけでなく、ディスクに保持されているバックアップ世代の数、および SAP HANA データベースでデータが変更される頻度によっても異なります。たとえば、バックアップポリシーで完全データバックアップを毎日実行し、それらのバックアップを 1 週間保持する必要がある場合は、バックアップストレージのサイズをデータ領域のサイズの 7 倍にする必要があります。

データバックアップに加えて、ポイントインタイムデータベースリカバリを可能にするために、ログバックアップのバックアップストレージを予約する必要があります。書き込まれるログバックアップの数とサイズは、SAP HANA データベースの変更操作の数によって異なります。

技術的には、複数の SAP HANA データベースのバックアップを集中共有バックアップストレージに保存することができます。ただし、複数のバックアッププロセスまたはリカバリプロセスが並列で実行される場合、これは特定のバックアップストレージの全体的なデータスループットに影響します。つまり、並列プロセス数が一定の数を超えた場合に、バックアップストレージが一定レベルのデータスループットを保証できない場合、バックアップおよびリカバリプロセスの速度が大幅に低下する可能性があります。

バックアップ方針: 全フルバックアップ

Code Snippet
1234
28x 2.50TB = 70TB 28x 0.25TB = 7TB + --------------------------------- Backup size = 77TB

バックアップ方針: 週末フルバックアップ、稼働日増分バックアップ

Code Snippet
12345
4x 2.50TB = 10.0TB 24x 0.05TB = 1.2TB 28x 0.25TB = 7.0TB + --------------------------------- Backup size = 18.2TB

エクスポートに必要なディスク領域

問題の根本的原因分析にデータベースコンテンツが必要な場合があります。このためには、バイナリエクスポートを保持するために十分なディスク領域を提供する必要があります。ほとんどの場合、根本的原因分析のためにデータベースコンテンツ全体をエクスポートする必要はありません。したがって、最大のデータベーステーブルのサイズの約 2 倍の記憶域を確保するだけで十分です。

ネットワーク要件

通常、ネットワークサイジングは帯域幅に焦点を当てており、一般にギガビット/秒 (Gbit/s) で表されます。

また、仮想デバイス (ハイパーバイザフェイルオーバーなど)、管理ホスト (SAP HANA データベースコックピットなど)、およびブートサーバ間の通信を処理するために、管理ゾーンを作成することもよくあります。

アプライアンスとして SAP HANA をデプロイすると、内部ゾーンおよびストレージゾーンに対して "ネットワーク接続" が提供されます。クライアントゾーンと管理ゾーンは、お客様の責任です。

調整済データセンタ統合アプローチを使用して SAP HANA をデプロイする場合、内部ゾーンおよびストレージゾーンの推奨処理速度は最小 10 Gbit/s です。

サイジングの推奨事項など、SAP HANA のネットワーク設定の詳細については、SAP HANA ネットワーク要件 (SAP HANA Network Requirement) を参照してください。

データベース CPU サイジング

この図は、マルチユーザデータベースシナリオにおける CPU 負荷調整のクエリのサイジングに関する前提と重要性を示しています。

SAP HANA スタンドアロンに移行するための CPU 要件は、比較対象の実際の参照がないため、予測が困難です。したがって、前に参照されたサイジングには、有効ユーザあたり 300 SAPS、CPU 使用率バッファに対する 0.65 という計算式があります。有効ユーザとは、特定の時点で CPU 電力を消費するユーザのことです。サイジングでは、多くの場合、顧客はエンドユーザの (重複する) アクティビティパターンを過大評価します。エンドユーザによっては、データベースレベルで複雑な、または負荷の低い計算を実行することもできます。

この推奨事項は、検証が必要な初期見積と考えてください。システム上にユーザが多いほど、この式が正確である可能性が低くなります。追加の CPU 分析に時間を投資するかどうかの決定は、CPU 制限に達するリスクに依存します。たとえば、2 つのソケットを持つ SAP HANA サーバでは、約 60,000 の SAPS が提供されます。

CPU 要件を検証する場合は、単一ユーザテストまたはロードテストで、上位 5 から 10 の SAP HANA トランザクションを使用したテストが役立ちます。

サイジング方法 Quick Sizer for SAP HANA

この図は、Quick Sizer ツールおよび財務パフォーマンステーブルを使用した初期ハードウェアサイジングの段階的なプロセスを示しています。

SAP HANA データベースは、Quick Sizer を使用してサイジングすることもできます。詳細については、Quick Sizer を参照してください。

Quick Sizer では、以下が計算されます。

  • CPU

  • ディスク

  • メモリ

  • 入力/出力リソースカテゴリ

スループット数およびさまざまな SAP ソリューションを使用するユーザの数に基づいて、ハードウェアおよびデータベース非依存の形式で計算されます。サイジングは、カスタマ、ハードウェアベンダ、および SAP を継続的にまとめる反復プロセスです。たとえば、SAP ハードウェアベンダへの直接リンクによって入札手順が促進されます。

Quick Sizer を使用した初期サイジングの推奨事項については、図 "クイックサイザーツール" に示すステップに従ってください。設定例については、SAP 標準アプリケーションベンチマーク (SAP Standard Application Benchmarks) を参照してください。

Quick Sizer では、複数の事前定義済シナリオを選択できます。たとえば、以下のシナリオを選択することができます。

  • SAP Business Suite powered by SAP HANA
  • SAP S/4HANA
  • SAP BW/4HANA
  • スタンドアロン SAP HANA
  • SAP S/4HANA Cloud

各シナリオでは、予想されるデータ圧縮が異なります。

SAP HANA アプライアンスのサイジング方法

メモリサイジングの結果は、SAP HANA システムのハードウェア推奨事項の基礎となります。SAP HANA アプライアンスの購入を決定した場合は、SAP HANA Hardware Directory 一覧を確認します。この一覧には、認定されているか、またはサポートされているハードウェアがすべて表示されます。SAP HANA アプライアンスのストレージおよび CPU サイジングは、認定アプライアンス製品に含まれているため、考慮する必要はありません。

注意

SAP HANA データベースソフトウェア以外のアプリケーションは、SAP によって明示的にサポートされているシナリオを除き、データベースサーバにインストールしてはなりません。これについては、デプロイメントオプションについてのレッスンで説明します。

メモリ所要量を計算するには、以下の SAP ノートを使用してください。

SAP HANA アプライアンス

利用可能な SAP HANA アプライアンスと認定 SAP HANA アプライアンスの概要は、SAP HANA ハードウェアディレクトリにあります。

注意

少なくとも Intel Haswell CPU 以降の SAP HANA 2.0 コンピューティングノードで開始する必要があります。SAP ノート 2399995 - SAP HANA 2.0 のハードウェア要件 (Hardware requirement for SAP HANA 2.0) を参照してください。

サイジングの推奨事項は認定済ハードウェアのみに適用されます。適切なハードウェア設定については、ハードウェアベンダにお問い合わせください。SAP HANA 開発チームは、SAP HANA データベースを常に最適化しています。SAP HANA メモリサイジングを実行する場合は、常に最新の文書および SAP ノートを確認することをお奨めします。

SAP HANA 非 NetWeaver のサイジング方法

非 NetWeaver のサイジング方法

SAP ノート 1514966 - SAP HANA 1.0: SAP In-Memory Database のサイジング (SAP HANA 1.0: Sizing SAP In-Memory Database) には、非 NetWeaver シナリオ (データが外部データソースから取得され、そのデータのモデリングと分析に SAP HANA が使用される場合など) における SAP HANA のサイジングについて記載されています。これらのサイジングルールは、SAP BW/4HANA、Business Suite on SAP HANA システム、または SAP S/4HANA のサイジングには使用しないでください。不適切な値が生成されるためです。

その他の注意事項

さまざまな SAP HANA シナリオでは、ネイティブおよびサードパーティテクノロジーによって、頻繁に使用されないデータを SAP HANA パーシスタンスまたは他のデータベース管理システムに置き換える機能が提供されます。このようなテクノロジーが使用される場合、これはメインメモリサイジングで考慮されます。以下に例を示します。

  • SAP HANA ネイティブストレージ拡張 (SAP ノート 2775588) および SAP HANA のデータエージング (SAP ノート 2816823)

    SAP HANA ネイティブストレージ拡張は、SAP HANA の汎用的な組込ウォームデータストアです。これにより、あまり頻繁にアクセスされないデータをメモリに完全にロードすることなく管理することができます。SAP HANA ネイティブストレージ拡張により、SAP HANA データベースにネイティブウォームデータ階層が追加されます。ディスク容量が拡張されることにより、SAP HANA データベースのページロード可能なウォームデータが管理され、インテリジェントなバッファキャッシュによってメモリとディスク間でデータの各ページが転送されます。

    ディスクベースのデータベーステクノロジーと SAP HANA インメモリデータベースを統合することで費用対性能比を向上させながら、SAP HANA 拡張ノードや SAP HANA 動的階層化などの他のウォームデータ階層化ソリューションを補完します。

    ただし、SAP HANA ネイティブストレージ拡張は、SAP HANA の既存のデータエージング機能に干渉するものではないことに注意してください。これにより、SAP S/4HANA のデータエージング機能が置き換えられることも、エージングプロセスやアクセスが変更されることもありません。SAP S/4HANA データエージングテーブルは、引き続き SAP S/4HANA に完全に制御され、変更すべきではありません。SAP S/4HANA 以外でデータベーステーブルを変更すると、SAP S/4HANA でエラーが発生する可能性があるためです。

  • SAP BW/4HANA の非アクティブデータの概念およびニアラインストレージソリューション (SAP ノート 1767880 および SAP ノート 2165650)

    大規模な SAP BW システムには、使用されなくなった、またはほとんど使用されない大量のデータが含まれています。ただし、履歴データ、法的な理由によるデータの保持など、システムに残ります。このデータは非有効データと呼ばれます。SAP BW/4HANA の実装では、メインメモリボトルネックで LRU (last-recently-used: 最近の使用) 概念が使用される場合に、非アクティブデータを移動できます。このコンセプトにより、メインメモリリソース管理が改善され、大量の非有効データのハードウェアサイジングに好影響を与えます。詳細については、SAP ノート 1736976 を参照してください。さらに、ニアラインストレージソリューションを使用してコールドデータを保存することもでき、メモリ量の削減にも役立ちます。

  • SAP HANA スマートデータアクセス 2.0 (SAP ノート 2352696):

    SAP HANA スマートデータアクセスでは、SQL クエリを介して、リモートデータが SAP HANA のローカルテーブルであるかのようにリモートデータにアクセスすることができます。最初に SAP HANA にデータをコピーする必要はありません。この機能は、運用上のメリットとコスト面でのメリットをもたらし、次世代の分析アプリケーションの開発とデプロイメントをサポートします。これには、データの格納場所や生成しているシステムに関係なく、複数のシステムからのデータにリアルタイムでアクセス、統合、および統合する機能が必要です。

  • 非推奨: SAP HANA 2.0 動的階層化 (SAP ノート 3414255)

    SAP HANA 動的階層化は、履歴データを管理するための SAP HANA データベースへのオプションのアドオンです。その目的は、アクセス頻度の低いウォームデータを管理するために(SAP HANA のインメモリストアではなく)、ディスクセントリックカラムストアで SAP HANA メモリを拡張することです。ウォームデータでは、非常にアクティブな "ホット" データと比較して、パフォーマンスの要件が緩和されます。拡張ストア内のデータはオンラインであり、クエリと更新の両方で使用できます。小規模な SAP HANA データベースに動的階層化を追加することはできますが、動的階層化の対象となるのは、大規模なデータボリュームにデータライフサイクル管理ソリューションが必要になり始める、サイズが 512 GB 以上の SAP HANA データベースです。