仮想化データセンター設計

導入

ユーザーの観点から見た情報システムは、GOST RV 51987 で明確に定義されています。「自動化されたシステムであり、その結果、後で使用するための出力情報が表示されます。」 内部構造を考慮すると、本質的に、IS はコードで実装された相互接続されたアルゴリズムのシステムです。 チューリングチャーチの理論の広い意味では、アルゴリズム (または IS) は、入力データのセットを出力データのセットに変換します。
入力データの変換こそが情報システムの存在意義であるとも言えます。 したがって、IS および IS コンプレックス全体の値は、入力データと出力データの値によって決定されます。
これに基づいて、設計を開始してデータ駆動型にし、データの構造と重要性に合わせてアーキテクチャとメソッドを調整する必要があります。

保存データ
設計の準備における重要な段階は、処理と保存が計画されているすべてのデータ セットの特性を取得することです。 これらの特徴には次のようなものがあります。
- データ量;
— データのライフサイクルに関する情報 (新しいデータの増加、寿命、古いデータの処理)。
— 観点からのデータの分類財務指標 (たとえば、過去 XNUMX 時間のデータ損失のコスト) とともに、企業の中核事業 (機密性、完全性、可用性の XNUMX つ) への影響。
— データ処理の地理 (処理システムの物理的な位置)。
— 各データクラスの規制要件 (連邦法-152、PCI DSS など)。

情報システム

データは保存されるだけでなく、情報システムによって処理 (変換) されます。 データ特性を取得した後の次のステップは、情報システムの最も完全なインベントリ、そのアーキテクチャ上の特徴、相互依存性、および XNUMX 種類のリソースの従来のユニットにおけるインフラストラクチャ要件です。
— プロセッサの計算能力。
— RAM の量。
— データストレージシステムのボリュームとパフォーマンスの要件。
— データ伝送ネットワークの要件（外部チャネル、IS コンポーネント間のチャネル）。
この場合、IS の一部として各サービス/マイクロサービスに要件が必要です。
これとは別に、正しい設計のためには、企業の中核事業に対する IS の影響に関するデータを、IS ダウンタイムのコスト (時間あたりルーブル) の形で入手することが必須であることに注意する必要があります。

脅威モデル

データ/サービスを保護するために計画されている脅威の正式なモデルが必要です。 さらに、脅威モデルには機密性の側面だけでなく、完全性と可用性も含まれています。 それらの。 例えば：
— 物理サーバーの障害。
— トップオブラック スイッチの障害。
— データセンター間の光通信チャネルの中断。
— 運用中のストレージ システム全体の障害。
場合によっては、脅威モデルはインフラストラクチャ コンポーネントだけでなく、データ構造の論理的破壊を伴う DBMS 障害など、特定の情報システムまたはそのコンポーネントに対しても作成されます。
説明されていない脅威から保護するためのプロジェクト内のすべての決定は不要です。

規制要件

処理されるデータが規制当局によって定められた特別な規則の対象となる場合、データセットおよび処理/保管規則に関する情報が必要です。

RPO/RTO 目標

あらゆる種類の保護を設計するには、説明されている脅威ごとに目標のデータ損失指標と目標のサービス回復時間を設定する必要があります。
理想的には、RPO と RTO には、単位時間あたりのデータ損失とダウンタイムの関連コストが必要です。

リソースプールへの分割

すべての初期入力情報を収集した後の最初のステップは、脅威モデルと規制要件に基づいてデータ セットと IP をプールにグループ化することです。 さまざまなプールの分割の種類は、システム ソフトウェア レベルでプログラム的に、または物理的に決定されます。
Примеры：
— 個人データを処理する回路は他のシステムから完全に物理的に分離されています。
— バックアップは別のストレージ システムに保存されます。

この場合、プールは不完全に独立している可能性があります。たとえば、コンピューティング リソースの XNUMX つのプール (プロセッサ電力 + RAM) が定義され、単一のデータ ストレージ プールと単一のデータ送信リソース プールが使用されます。

処理能力

要約すると、仮想化データセンターの処理能力要件は、仮想プロセッサ (vCPU) の数と物理プロセッサ (pCPU) 上の統合率の観点から測定されます。 この特定のケースでは、1 pCPU = 1 物理プロセッサ コア (ハイパー スレッディングを除く)。 vCPU の数は、定義されたすべてのリソース プールにわたって合計されます (それぞれに独自の統合係数を持つことができます)。
負荷のかかるシステムの統合係数は、既存のインフラストラクチャに基づいて、またはパイロット設置と負荷テストを通じて経験的に取得されます。 アンロードされたシステムの場合は、「ベスト プラクティス」が使用されます。 具体的には、VMware は平均比率を 8:1 だとしています。

手術記憶

合計 RAM 要件は単純な合計で得られます。 RAM オーバーサブスクリプションの使用は推奨されません。

ストレージリソース

ストレージ要件は、容量とパフォーマンス別にすべてのプールを単純に合計することで得られます。
パフォーマンス要件は、平均読み取り/書き込み比率、および必要に応じて最大応答遅延を組み合わせた IOPS で表されます。
特定のプールまたはシステムのサービス品質 (QoS) 要件は、個別に指定する必要があります。

データネットワークリソース

データ ネットワーク要件は、すべての帯域幅プールを単純に合計することで得られます。
特定のプールまたはシステムのサービス品質 (QoS) および遅延 (RTT) 要件は、個別に指定する必要があります。
データ ネットワーク リソースの要件の一部として、ネットワーク トラフィックの分離および/または暗号化、および優先メカニズム (802.1q、IPSec など) の要件も示されています。

アーキテクチャの選択

このガイドでは、x86 アーキテクチャと 100% サーバー仮想化以外の選択肢については説明しません。 したがって、コンピューティング サブシステム アーキテクチャの選択は、サーバー仮想化プラットフォーム、サーバー フォーム ファクター、および一般的なサーバー構成要件の選択によって決まります。

選択の重要なポイントは、データの処理、保存、送信の機能を分離した古典的なアプローチを使用するか、それとも収束型アプローチを使用するかの確実性です。

古典建築 データの保存と送信にはインテリジェントな外部サブシステムが使用されますが、サーバーは物理リソースの共通プールに処理能力と RAM のみを提供します。 極端な場合には、サーバーは完全に匿名になり、独自のディスクだけでなく、システム識別子さえ持たなくなります。 この場合、OS またはハイパーバイザーは、内蔵フラッシュ メディアまたは外部データ ストレージ システム (SAN からのブート) からロードされます。
古典的なアーキテクチャの枠組み内では、ブレードとラックの選択は主に次の原則に基づいて行われます。
— 費用対効果が高い (平均して、ラックマウント サーバーの方が安価です)。
— 計算密度 (ブレードの方が高い)。
— エネルギー消費と熱放散（ブレードの単位あたりの比単位が高くなります）。
— 拡張性と制御性 (ブレードは通常、大規模な設置ではそれほど労力を必要としません)。
- 拡張カードの使用 (ブレードの選択肢は非常に限られています)。
コンバージェントアーキテクチャ （としても知られている ハイパーコンバージド) には、データ処理とストレージの機能を組み合わせることが含まれます。これにより、ローカル サーバー ディスクが使用され、その結果、従来のブレード フォーム ファクターが放棄されます。 コンバージド システムの場合は、複数のブレード サーバーとローカル ディスクを XNUMX つのケースに組み合わせたラック サーバーまたはクラスター システムが使用されます。

CPU /メモリ

構成を正しく計算するには、環境または各独立したクラスターの負荷のタイプを理解する必要があります。
CPUバウンド – プロセッサーの能力によってパフォーマンスが制限される環境。 RAM を追加しても、パフォーマンス (サーバーあたりの VM の数) は何も変わりません。
メモリバウンド – 環境はRAMによって制限されます。 サーバー上の RAM が増えると、サーバー上でより多くの VM を実行できるようになります。
GB / MHz (GB / pCPU) – この特定の負荷による RAM とプロセッサ電力の消費の平均比率。 特定のパフォーマンスに必要なメモリ量を計算するために使用でき、またその逆も可能です。

サーバー構成の計算

まず、すべての種類の負荷を判断し、異なるコンピューティング プールを異なるクラスターに結合または分割するかを決定する必要があります。
次に、定義されたクラスターごとに、事前にわかっている負荷で GB/MHz 比が決定されます。 負荷が事前にわかっていないが、プロセッサーの電力使用率のレベルが大まかにわかっている場合は、標準の vCPU:pCPU 比率を使用して、プール要件を物理要件に変換できます。

各クラスターについて、vCPU プール要件の合計を係数で割ります。
vCPUsum / vCPU:pCPU = pCPUsum – 必要な物理ユニットの数。 コア
pCPUsum / 1.25 = pCPUht – ハイパースレッディング用に調整されたコアの数
190 コア / 3.5 TB の RAM を備えたクラスターを計算する必要があると仮定します。 同時に、プロセッサー能力の 50% と RAM の 75% のターゲット負荷を受け入れます。

pCPU
190
CPU使用率
視聴者の３８%が

Mem
3500
メモリユーティリティ
視聴者の３８%が

ソケット
基本
サーバー/CPU
サーブメモリ
サーバー/メモリ

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

この場合、常に最も近い整数への切り上げ (=ROUNDUP(A1;0)) を使用します。
表から、いくつかのサーバー構成がターゲット指標に対してバランスが取れていることが明らかです。
— 26 サーバー 2*6c / 192 GB
— 19 サーバー 2*10c / 256 GB
— 10 サーバー 2*18c / 512 GB

これらの構成の選択は、熱パッケージや利用可能な冷却、すでに使用されているサーバー、コストなどの追加の要素に基づいて行う必要があります。

サーバー構成の選択の特徴

ワイド VM。 ワイド VM (1 つの NUMA ノード以上に相当) をホストする必要がある場合は、可能であれば、そのような VM を NUMA ノード内に維持できる構成のサーバーを選択することをお勧めします。 ワイド VM が多数ある場合、クラスター リソースが断片化する危険性があるため、この場合、ワイド VM をできるだけ高密度に配置できるサーバーが選択されます。

単一障害ドメインのサイズ。

サーバー サイズの選択も、単一障害ドメインを最小限に抑えるという原則に基づいています。 たとえば、次のいずれかを選択する場合:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
他のすべての条件が等しい場合、33 番目のオプションを選択する必要があります。これは、17 つのサーバーに障害が発生した場合 (または保守中)、クラスター リソースの XNUMX% ではなく XNUMX% が失われるためです。 同様に、事故の影響を受ける VM と IS の数は半減します。

パフォーマンスに基づいたクラシック ストレージ システムの計算

クラシック ストレージ システムは、運用キャッシュと運用の最適化の影響を除いて、常に最悪のシナリオを使用して計算されます。
基本的なパフォーマンス指標として、ディスク (IOPSdisk) から機械的パフォーマンスを取得します。
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

次に、ディスク プール内のディスクの数が次の式を使用して計算されます。 = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk。 どこ：
- 合計IOPS – ディスク プールからの IOPS で必要な合計パフォーマンス
- RW – 読み取り操作の割合
- RAIDペン – 選択した RAID レベルの RAID ペナルティ

デバイス RAID と RAID ペナルティの詳細については、こちらをご覧ください - ストレージのパフォーマンス。 パート XNUMX。 и ストレージのパフォーマンス。 パートXNUMX。 и ストレージのパフォーマンス。 パート XNUMX

結果として得られるディスクの数に基づいて、マルチレベル ストレージのオプションなど、ストレージ容量の要件を満たす可能なオプションが計算されます。
ストレージ層として SSD を使用するシステムの計算は、別途考慮されます。
フラッシュキャッシュを搭載した計算システムの特長

フラッシュキャッシュ – フラッシュ メモリを XNUMX 次キャッシュとして使用するためのすべての独自テクノロジーの共通名。 フラッシュ キャッシュを使用する場合、ストレージ システムは通常、磁気ディスクからの安定した負荷を提供するように計算され、一方でピークはキャッシュによって処理されます。
この場合、負荷プロファイルとストレージボリュームのブロックへのアクセスの局所化の程度を理解する必要があります。 フラッシュ キャッシュは、高度にローカライズされたクエリを含むワークロード用のテクノロジーであり、均一にロードされたボリューム (分析システムなど) には実際には適用できません。

ローエンド/ミッドレンジハイブリッドシステムの計算

下位クラスと中位クラスのハイブリッド システムは、スケジュールに従ってレベル間をデータが移動するマルチレベル ストレージを使用します。 同時に、最高のモデルのマルチレベル ストレージ ブロックのサイズは 256 MB です。 これらの機能により、多くの人が誤解しているように、階層型ストレージ テクノロジを生産性向上のためのテクノロジとみなすことはできません。 低級および中級クラスのシステムにおけるマルチレベル ストレージは、負荷の不均一性が顕著なシステムのストレージ コストを最適化するためのテクノロジーです。

階層型ストレージの場合、最上位層のパフォーマンスが最初に計算されますが、ストレージの最下位層は不足しているストレージ容量にのみ寄与すると考えられます。 ハイブリッド多層システムの場合、下位レベルからの突然のデータ加熱によるパフォーマンスの低下を補うために、多層プールにフラッシュ キャッシュ テクノロジを使用することが必須です。

階層化ディスクプールでの SSD の使用

マルチレベル ディスク プールでの SSD の使用方法は、特定のメーカーによるフラッシュ キャッシュ アルゴリズムの特定の実装に応じて異なります。
SSD レベルのディスク プールのストレージ ポリシーの一般的な方法は、SSD を優先します。
読み取り専用フラッシュ キャッシュ。 読み取り専用フラッシュ キャッシュの場合、キャッシュに関係なく、SSD 上のストレージ層により書き込みが大幅に局所化されます。
読み取り/書き込みフラッシュ キャッシュ。 フラッシュ キャッシュの場合、書き込みキャッシュ サイズは最初に最大キャッシュ サイズに設定され、キャッシュ サイズがローカライズされたワークロード全体にサービスを提供するには不十分な場合にのみ SSD ストレージ層が表示されます。
SSD とキャッシュのパフォーマンスの計算は、メーカーの推奨に基づいて毎回行われますが、常に最悪のシナリオを考慮して行われます。

出所： habr.com