オンプレミス環境のハードウェアのサイズ設定要件

オンプレミス環境におけるハードウェアおよびインフラストラチャのサイズ設定のプロセスを開始する前に、クラウド配置のシステム要件 およびセットアップおよび配置の指示 に精通し、基盤となるインフラストラクチャを確実に把握します。

ドキュメントを確認した後、トランザクションと同時実行ユーザー量の見積および平均コア スループットに基づいて、環境のサイズを変更するプロセスを開始できます。

サイズ設定に影響する要因

次の図に示すようにすべての要素は、サイズ設定に寄与します。 より詳細な情報が収集されるほど、より正確にサイジングを決定することができます。 ハードウェアのサイジングは、データをサポートしていないため、不正確になる可能性があります。 必要なデータの絶対最小要件は、1 時間あたりの見積ピーク トランザクション明細行数です。

[]

左から右に見ると、サイジングを正確に推定するために必要な最初の最も重要な要素は、トランザクション プロファイルまたはトランザクション特性です。 1 時間あたりのピーク トランザクション量を常に検索することは重要です。 複数のピーク期間がある場合は、これらの期間を正確に定義する必要があります。

インフラストラクチャに影響を及ぼす負荷を理解するようになると、これらの要因についてさらに詳しく理解する必要があります。

• トランザクション – 種類にもよりますが、通常、取引は 1 日/1 週間を通じて一定のピークがあります。 時間と経費のエントリーでは、通常、1 週間に 1 回ピークを示しますが、販売注文票は、その日の統合またはトリクルによって一括して入荷されることがよくあります

• 同時ユーザー数 – 同時ユーザー数は、サイズを設定する上で 2 番目に重要な要因です。 同時ユーザー数のみに基づいて信頼性の高いサイズの見積を取得することはできません。 この数字しかデータがない場合は、おおよその数字を見積もって、データが増えたときにこれをやり直します。 正確な同時ユーザー定義は次の通りです。

  • 名前付きユーザーは同時ユーザーではありません。
  • 同時ユーザーは、常に名前付きユーザーのサブセットです。
  • ピーク時の負荷は、最大の同時実行のサイズを定義します。

  同時ユーザーのための基準は、ユーザーが次のすべての条件を満たすことです。

  • ログオンしています。
  • 棚卸時の作業トランザクション/照会。
  • アイドル セッションではありません。

• データ構成 - 主に、システムをどのように設定して構成するかということです。 たとえば、法人の数、アイテムの数、BOM レベルの数、セキュリティ設定の複雑さなどです。 これらの要因のそれぞれはパフォーマンスにはほとんど影響しない可能性があるため、これらの要因はインフラストラクチャに関しては賢明な選択肢を使用することで相殺できます。

• 拡張機能 – カスタマイズはシンプルまたは複雑になり得ます。 カスタマイズの数と複雑さと使用の性質は、必要なインフラストラクチャのサイズにさまざまな影響を与えます。 複雑なカスタマイズの場合は、効率性のテストだけでなく、インフラストラクチャのニーズを理解するのに役立つように、パフォーマンス評価を行うことをお勧めします。 拡張機能が、パフォーマンスとスケーラビリティにおけるベストプラクティスに従ってコード化されていない場合、これはさらに重要です。

• レポートと分析 – これらの要因には、通常、システムのさまざまなデータベースに対する大量のクエリの実行が含まれます。 高価なレポートを実行する頻度を理解し、削減することで、レポートの影響を理解するのに役立ちます。

• サード パーティのソリューション1 – これらのソリューションは、ISV のように、拡張と同じ意味合いと推奨事項を持っています。

環境のサイズ変更

サイズの要件を理解するには、処理する必要があるトランザクションの最大使用量を把握する必要があります。 Management Reporter や SSRS などのほとんどの補助システムは、ミッション クリティカルではありません。 その結果、このドキュメントは主に AOS と SQL Server に焦点を当てています。

SQL Server (OLTP)

サイズ変更

• 1 時間あたり DB サーバー上のコアあたり 3K 〜 15K のトランザクション明細行。

• プライマリー SQL Server の一般的な AOS と SQL のコア比率 3:1。 選択された高可用性構成に基づいて、追加のコアが必要です。

  • データベースに重い操作を処理すると、これが 2:1 の比率に回帰する可能性があります。

• 次の要因には、変動が影響します。

  • 使用中のパラメータ設定。
  • 拡張機能のレベル。
  • データベース ログやアラートなどの追加機能の使用。 極端なデータベース ロギングにより、コアあたりのスループットは 1 時間当たり 3K 以下にさらに低下します。
  • データ構成の複雑さ - シンプルな勘定科目表と細かい綿密な勘定科目表は、スループットに影響を与えます。
  • トランザクションの特性。
  • 各コアの 2 GB から 16 BG までのメモリーです。
  • 管理リポーターや SSRS データベースなどの DB サーバー上の補助データベース。
  • Temp DB = 物理プロセッサと同数のファイルを持つ DB サイズの 15 ％。
  • 同時のトランザクション ボリューム/使用量の合計に基づく SAN サイズとスループット。

高可用性

クラスタまたはミラーリングの設定で常に SQL Server を使用することをお勧めします。 2 番目の SQL ノードは、1 次ノードと同じ数のコアを持つ必要があります。

Active Directory フェデレーション サービス (AD FS)

広告のサイズ変更について、広告のサーバーの処理能力ドキュメントを参照してください。

Aサイズ変更スプレッドシートは、展開内のインスタンスの数を計画するために使用できます。

AOS (オンラインおよびバッチ)

サイズ変更

• トランザクションの量と使用法サイズの変更

  • コアあたり 2K から 6K の明細行
  • インスタンスあたり 16 GB
  • 標準ボックス – 4 から 24 コア
  • コアあたり 10 から 15 のエンタープライズ ユーザー
  • コアあたり 15 から 25 のアクティブ ユーザー
  • コアあたり 25 から 50 のチーム メンバー

• バッチ

  • コアあたり 1 から 4 のバッチ スレッド
  • バッチ ウィンドウの特性に基づくサイズ

• AOS、データ管理、およびバッチは、サービス ファブリック内で同じ役割を果たします。 Microsoft Dynamics AX 2012 のように、これらの 3 つのワークロードをまとめてサイズ調整する必要があります。

• ここでは、SQL Server と同じ変動要因が適用されます。

高可用性

• 推測する以上に少なくとも 1 から 2 の AOS があることを確認してください。
• 少なくとも 3 から 4 つの仮想ホストが使用可能であることを確認してください。

Management Reporter

ほとんどの場合、広範囲に使用されない限り、2 つのノードを使用する推奨最小要件が適切に動作します。 頻繁に使用する場合にのみ、2 つ以上のノードが必要になります。 必要に応じて縮尺を調整してください。

SQL Server Reporting Services

一般的な使用可能なリリースは、1 つの SSRS ノードしか展開できません。 テスト中に SSRS ノードを監視し、SSRS で使用可能なコアの数を必要に応じて増やします。 SSRS VM とは異なる仮想ホストで事前構成されたセカンダリ ノードを使用できることを確認してください。 これは、SSRS または仮想ホストをホストする仮想マシンに問題がある場合に重要です。 この場合、交換する必要があります。

バージョン 10.0.17 以降では、高可用性を実現するために追加の SSRS ノードを構成することが可能です。 詳細情報については、SQL Server Reporting Services (SSRS) ノードの高可用性の構成 を参照してください。

環境オーケストレーター

オーケストレータ サービスは、展開および LCS との関連する通信を管理するサービスです。 このサービスはプライマリ Service Fabric サービスとして展開され、最低 3 台の VM が必要です。 このサービスは Service Fabric オーケストレーション サービスと共に位置し、クラスタの最大負荷にサイズを設定する必要があります。 詳細については、 Service Fabric スタンドアロン クラスタの展開計画を参照してください。

仮想化と過剰加入

AOS のようなミッション クリティカルなサービスは、コア、メモリ、ディスクなどの専用リソースを持つ仮想ホストでホストする必要があります。