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

はじめに



ユーザーの観点からの情報システムは、GOST RV 51987-「その機能により、その後の使用のために出力情報が表示される自動システム」で明確に定義されています。 内部構造を考慮すると、実際、ISはコードに実装された相互接続されたアルゴリズムのシステムです。 Turing-Church論文の広い意味では、アルゴリズム（およびISの場合）は、入力データのセットを出力データのセットに変換します。

入力データの変換には、情報システムの存在の感覚があるとさえ言えます。 したがって、IPおよびIPコンプレックス全体の値は、入力データと出力データの値によって決定されます。

これに基づいて、設計を開始し、データを基礎として、データの構造と重要性に合わせてアーキテクチャと方法を調整する必要があります。



保存データ

設計の準備における重要なステップは、処理および保管のために計画されたすべてのデータセットの特性を取得することです。 これらの機能は次のとおりです。

-データの量。

-データのライフサイクルに関する情報（新しいデータの成長、寿命、古いデータの処理）;

-t.zによるデータ分類。 企業のコアビジネスへの影響（機密性、整合性、アクセシビリティの3つの要素）と財務指標（たとえば、最後の1時間のデータ損失のコスト）;

-データ処理の地理（処理システムの物理的な場所）;

-各データクラスの規制当局の要件（例：FZ-152、PCI DSS）。







情報システム



データは保存されるだけでなく、情報システムによって処理（変換）されます。 データ特性を取得した後の次のステップは、情報システムの最も完全なインベントリ、それらのアーキテクチャ機能、相互依存性、および4種類のリソースの任意単位のインフラストラクチャ要件です。

-プロセッサの計算能力。

-RAMの量。

-ストレージシステムのボリュームとパフォーマンスの要件。

-データネットワークの要件（外部チャネル、IPのコンポーネント間のチャネル）。

この場合、要件はIS内の各サービス/マイクロサービスに対応する必要があります。

それとは別に、IPダウンタイムのコスト（1時間あたりのルーブル）の形で、正しい設計に必須であるIPが企業のコアビジネスに与える影響に関するデータの可用性に注意する必要があります。



脅威モデル



データ/サービスの保護が計画されている脅威の正式なモデルが必要です。 さらに、脅威モデルには機密性の側面だけでなく、整合性とアクセシビリティも含まれます。 つまり 例えば：

-物理サーバーの障害。

-トップオブザラックスイッチの故障。

-データセンター間の光通信チャネルの破壊。

-運用ストレージシステム全体の障害。

場合によっては、脅威モデルは、インフラストラクチャコンポーネントだけでなく、特定のISまたはそのコンポーネント（データ構造の論理的な破壊を伴うDBMS障害など）についても記述されます。

不特定の脅威から保護するためのプロジェクトのフレームワーク内のすべての決定は冗長です。



規制要件



処理されたデータが規制当局によって確立された特別な規則に従う場合、データセットと処理/保管規則に関する情報は必須です。



RPO / RTOターゲット



あらゆるタイプの保護を設計するには、記載されている各脅威のターゲットデータ損失とターゲットサービス回復時間の指標が必要です。

さらに、理想的には、RPOとRTOに関連するデータ損失と単位時間あたりのダウンタイムのコストが必要です。







リソースプーリング



すべての初期入力情報を収集した後、最初のステップは、脅威モデルと規制要件に基づいて、データセットとIPをプールにグループ化することです。 さまざまなプールの分離のタイプは、システムソフトウェアレベルで物理的に、または物理的に決定されます。

例：

-個人データを処理する回路は、他のシステムから完全に物理的に分離されています。

-バックアップは別のストレージシステムに保存されます。



この場合、プールは完全に独立している場合があります。たとえば、単一のストレージプールと単一のデータ転送リソースプールを使用する2つのコンピューティングリソースプール（プロセッサパワー+ RAM）が決定されます。



プロセッサー能力







仮想化されたデータセンターの抽象的なプロセッサ需要は、仮想プロセッサ（vCPU）の数と物理プロセッサ（pCPU）の統合係数で測定されます。 この特定のケースでは、1 pCPU = 1物理プロセッサコア（ハイパースレッディングを除く）。 vCPUの数は、定義されたすべてのリソースプールで合計されます（各リソースプールには独自の統合率があります）。

負荷システムの統合係数は、既存のインフラストラクチャに基づいて、またはパイロットのインストールと負荷テストを使用して、経験的に取得されます。 アンロードされたシステムの場合、「ベストプラクティス」が使用されます。 特に、VMwareは8の平均比率を呼び出します：1。



RAM



RAMの合計必要量は、単純な合計によって得られます。 RAMへの再サブスクリプションの使用は推奨されません。



ストレージリソース



ストレージリソースの要件は、ボリュームとパフォーマンスの観点からすべてのプールを単純に加算することで取得できます。

パフォーマンス要件は、平均読み取り/書き込み比率、および必要に応じて最大応答遅延と組み合わせて、IOPSで表されます。

個別に、特定のプールまたはシステムに対してQoS要件を指定する必要があります。



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



データネットワーク要件は、すべての帯域幅プールを単純に追加することで取得できます。

特定のプールまたはシステムのサービス品質（QoS）および待ち時間（RTT）を確保するための要件を別途指定する必要があります。

データ伝送ネットワークのリソースの要件のフレームワーク内で、ネットワークトラフィックと優先メカニズム（802.1q、IPSecなど）の分離および/または暗号化の要件も示されています。



アーキテクチャの選択



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



選択のキーポイントは、データまたは収束の処理、保存、および送信の機能を分離した古典的なアプローチを使用する際の確実性です。



古典的なアーキテクチャは、データを保存および送信するためのインテリジェントな外部サブシステムの使用を意味しますが、サーバーは物理リソースの共通プールにプロセッサパワーとRAMのみを提供します。 極端な場合、サーバーは完全に匿名になり、独自のディスクだけでなく、システム識別子も持ちます。 この場合、ビルトインフラッシュメディアまたは外部ストレージシステム（SANからのブート）からOSまたはハイパーバイザーをロードします。

古典的なアーキテクチャのフレームワーク内で、ブレードとラックの選択は、主に次の原則から実行されます。

-経済効率（平均して、ラックサーバーは安価です）。

-計算密度（ブレードが高い場合）;

-消費電力と熱放散（ユニットあたりのブレードの固有性が高い）;

-スケーラビリティと制御性（大規模なインストールでは、ブレード全体の労力が少なくて済みます）。

-拡張カードの使用（ブレードには非常に限られた選択肢）。

コンバージドアーキテクチャ （ ハイパー コンバージドとも呼ばれます ）には、処理機能とストレージ機能の組み合わせが含まれます。これにより、ローカルサーバーディスクが使用され、その結果、クラシックブレードのフォームファクターが拒否されます。 コンバージドシステムの場合、複数のブレードサーバーとローカルディスクを単一のパッケージに組み合わせたラックサーバーまたはクラスターシステムが使用されます。



CPU /メモリ



構成を正しく計算するには、環境または各独立クラスターの負荷の種類を理解する必要があります。

CPUバウンド -プロセッサのパワーによってパフォーマンスが制限される環境。 RAMを追加しても、パフォーマンス（サーバーごとのVMの数）に関しては何も変わりません。

メモリバウンド -RAMによって制限される環境。 サーバーのRAMを増やすと、サーバーでより多くのVMを実行できます。

GB / MHz（GB / pCPU）-特定の負荷のRAMとプロセッサの電力消費の平均比。 特定のパフォーマンスに必要なメモリ量を計算するために使用でき、逆もまた同様です。



サーバー構成の計算







まず、すべての種類の負荷を決定し、異なるクラスター間で異なるコンピューティングプールを結合または分割することを決定する必要があります。

さらに、定義されたクラスターのそれぞれについて、GB / MHz比は事前にわかっている負荷で決定されます。 負荷が事前にわからないが、プロセッサの電力負荷レベルがほぼ理解されている場合は、標準のvCPU係数であるpCPUを使用して、プール要件を物理的なものに変換できます。



各クラスターについて、vCPUプール要件の合計を係数で除算します。

vCPUsum / vCPU：pCPU = pCPUsum-必要な物理数。 コア

pCPUsumm / 1.25 = pCPUht-ハイパースレッディング用に調整されたコアの数

190コア/ 3.5TBのRAMのクラスターを計算するとします。 同時に、ターゲットの50％のCPU負荷と75％のRAMを受け入れます。

pCPU	190	CPU使用率	50％
思い出	3500	Mem util	75％
ソケット	コア	SRV / CPU	Srv mem	Srv / mem
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

他のすべてが等しい場合、2つのオプションを選択する必要があります。1つのサーバーに障害が発生した場合（またはサービスを受けた場合）、クラスターリソースの33％ではなく17％が失われるためです。 同様に、事故の影響を受けるVMとICの数は半分になります。



従来のストレージパフォーマンスの計算







クラシックストレージは常に最悪のシナリオに従って計算され、オンラインキャッシュと操作の最適化の影響を排除します。

基本的なパフォーマンスインジケータとして、ディスク（IOPSdisk）から機械的パフォーマンスを取得します。

-7.2k-75 IOPS

-10k-125 IOPS

-15,000-175 IOPS



次に、ディスクプール内のディスクの数は、次の式を使用して計算されます。 = TotalIOPS *（RW +（1 –RW）* RAIDPen）/ IOPSdisk 。 どこで：

-TotalIOPS-ディスクプールのIOPSで必要な合計パフォーマンス

-RW-読み取り操作の割合

-RAIDpen-選択したRAIDレベルのRAIDペナルティ



RAIDとRAIDペナルティの詳細については、 ストレージパフォーマンスをご覧ください。 パート1 およびストレージパフォーマンス。 パート2 およびストレージパフォーマンス。 パート3



取得したディスクの数に基づいて、階層型ストレージのオプションなど、ストレージ容量の要件を満たす可能なオプションが計算されます。

SSDをストレージ層として使用するシステムの計算は個別に考慮されます。

Flash Cacheを使用したシステムの計算の機能





フラッシュキャッシュは、フラッシュメモリをセカンドレベルキャッシュとして使用するためのすべての独自技術の共通名です。 フラッシュキャッシュを使用する場合、ストレージは通常、磁気ディスクからの安定した負荷を提供するように計算されますが、ピークキャッシュはピーク負荷に対応します。

負荷プロファイルとストレージボリュームブロックへの呼び出しのローカライズの程度を理解する必要があります。 フラッシュキャッシュは、リクエストのローカライズが高いワークロード向けのテクノロジーであり、実際には均等にロードされたボリューム（分析システムなど）には適用できません。



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



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



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



階層化されたディスクプールでSSDを使用する







マルチレベルディスクプールでのSSDの使用は、このメーカーのフラッシュキャッシュアルゴリズムの特定の実装によって異なります。

SSD層ストレージプールのストレージポリシーの一般的なプラクティスは、SSDが最初です。

読み取り専用フラッシュキャッシュ。 読み取り専用フラッシュキャッシュの場合、SSDのストレージレベルは、キャッシュに関係なく、書き込み操作が大幅にローカライズされて表示されます。

フラッシュキャッシュの読み取り/書き込み。 書き込み用のフラッシュキャッシュの場合、最大キャッシュサイズが最初に設定され、SSDのストレージレベルは、キャッシュサイズがローカライズされた負荷全体を提供するには不十分な場合にのみ表示されます。

SSDとキャッシュのパフォーマンス計算は、製造元の推奨に基づいて毎回実行されますが、常に最悪の場合に実行されます。