さまざまなストレージパフォーマンスのボトルネックを分析して最適化するにはどうすればよいですか?

[要約]この記事では、ストレージシステムのアーキテクチャと動作原理を分析する実践と、さまざまなストレージパフォーマンスのボトルネックシナリオの詳細な分析を組み合わせて、対応するパフォーマンスの最適化方法を提案し、ピアに特定の基準値を提供することを目指しています。

[著者] Chen Pingchun は現在保険業界で働いており、システム、ストレージ、データバックアップの運用と保守に長年の経験があります。

序文

信頼性、セキュリティ、パフォーマンスは、IT システムの 3 つの最も重要な評価要素です。ITシステムにとって、信頼性とセキュリティは基盤であり、システム障害や情報漏洩による破壊的影響は明らかである一方、ITシステムのサービスレベルを表すコア機能であるパフォーマンスは、企業ビジネスの発展を制限します。 . 開発、ユーザーエクスペリエンスに深刻な影響を及ぼします。

ストレージシステムは企業 IT インフラストラクチャの重要な部分であり、企業内の多数の IT システムにデータストレージサービスを提供します。デジタルトランスフォーメーションの深化に伴い、企業ITシステムの構築がさらに加速し、データ量が急増する一方で、データアクセス頻度も増加しています。ストレージパフォーマンスのボトルネックの影響もさらに増幅されます。この記事では、個人の運用と保守の実践を組み合わせて、ストレージシステムのアーキテクチャと動作原理を分析し、さまざまなストレージパフォーマンスのボトルネックシナリオを詳細に分析し、対応するパフォーマンスの最適化方法を提案します。仲間たちに。

1. ストレージシステムの概要

ストレージシステムのアーキテクチャと動作原理を理解することは、パフォーマンス分析と最適化の入門コースであり、ストレージパフォーマンスの問題をグローバルに分析して解決できるようになります。長年にわたる技術進化とアーキテクチャの変化を経て、ストレージシステムは SAN ストレージ、NAS ストレージ、分散ストレージの 3 つのカテゴリに大別され、それぞれに類似点がありますが、それぞれ独自の特徴もあります。以下では、これら 3 種類のストレージアーキテクチャとその動作原理を詳細に分析します。

1.1 SANストレージ

SAN (ストレージエリアネットワーク) 自体は、データストレージタスクを担当するストレージネットワークであり、ビジネス LAN ネットワークから分離されています。SAN ストレージは、一般に FC、ISCSI、NVMe などの通信プロトコルを使用するストレージブロックベースのストレージシステムです。

アーキテクチャの観点から見ると、SAN ストレージは通常、ストレージコントローラーのバックエンドにディスクアレイをマウントし、データは最終的にディスクアレイに保存され、ディスクアレイには複数の RAID グループが含まれます。N 個のディスクで RAID グループを構成し、共有ストレージプールの論理ディスクである論理ストレージユニット LUN が RAID グループの上位に分割され、SAN ネットワークを介してサーバーの HBA カードに接続されます。サーバーによって使用されます。オペレーティングシステムはディスクをディスクとして認識し、使用するためにパーティション化およびフォーマットされます。そのアーキテクチャを図 1 に示します。

図 1. SAN ストレージのアーキテクチャ図

ストレージデータ IO フローの観点から、一般的に使用されている FC-SAN ストレージを例に挙げると、サーバーオペレーティングシステムは一般にファイルシステムを使用してファイルを管理します。ファイルシステムはストレージ LUN 上に構築されており、ファイルの読み取りと書き込みは行われます。 IO 操作; ファイルは複数のブロックに分割され、ブロックサイズは通常 4KB ～ 16KB に固定されます; データブロックブロックはサーバーの HBA カードに送信され、HBA カードはFC プロトコルのデータフレーム (データフレーム) に変換され、SAN ネットワークを介してストレージシステムのフロントポートに送信され、ストレージのフロントポートは引き続きこれらのデータフレームをデータブロックに再パッケージ化します。通常は 4KB であり、これらのデータブロックをストレージコントローラーに送信します。ストレージコントローラーには、読み取りキャッシュと書き込みキャッシュに分割されるストレージキャッシュ (Cache) があり、キャッシュアルゴリズムの規則に従って、一部の IO データフローが発生します。キャッシュにヒットするとすぐに IO 確認が返され、キャッシュをミスした IO データフローはディスクアレイにアクセスし続ける必要があります。複数のディスクが RAID グループを形成するため、データ IO ストリームは実際には複数のディスクの同時読み取りと書き込みに対応します。。プロセス全体を図 2 に示します。

図 2. FC-SAN ストレージのデータ IO フロー図

1.2 NASストレージ

NAS (Network Attached Storage) ストレージは、一般にネットワークファイルストレージと見なされます。ほとんどのユーザーデータはファイルの形式で存在します。イーサネットアクセスモードを通じて NFS/CIFS プロトコルを採用し、幅広い互換性と使いやすい共有機能を提供します。SAN ストレージと比較すると、NAS ストレージはディスクの形式でストレージサービスを提供せず、パーティショニングやフォーマットを必要とせず、直接マウントできるネットワークファイルシステムを直接提供できます。

アーキテクチャの観点から見ると、NAS ストレージは一般にディスクアレイに基づいて実装されます (クラスタファイルシステムや分散ストレージに基づいた実装もあります)。ディスクアレイ上には、ファイルシステムを作成および管理するための NAS ヘッドがあります。ストレージのコア論理コンポーネントは、典型的な C/S アーキテクチャスタイルであり、ネットワークファイルサービスを外部に提供するサーバー側です。他のクライアントは、認証を取得した後、ファイルシステムをマウントしたり、ネットワークディスクをマップしたり、 HTTP、FTP など、NAS ファイルシステム上のファイルを共有してアクセスできます。そのアーキテクチャを図 3 に示します。

図 3.NAS ストレージアーキテクチャ図

NFS を例としてストレージデータ IO フローの観点から見ると、NAS ストレージには、クライアントキャッシングやサーバーのステートレス性など、SAN ストレージとは明らかに異なる特性があります。まず第一に、クライアントは NAS ファイルシステムに直接アクセスするのではなく、クライアントキャッシュにアクセスします。サーバーのファイルシステムディレクトリツリーはクライアントにマッピングされます。実際、ファイルの読み取りと書き込み時には、固定の読み取りと書き込みが必要です。 -size ページ (ループ内の 64KB など); while サーバークライアントのステートレス性は、クライアントのプロトコルステータス情報を維持する必要がないという事実に反映されており、クライアントは RPC を通じてサーバーのファイルシステムデータを操作します。を呼び出しますが、サーバーのステータスを取得できません。接続が中断された場合でも、接続を継続して再試行できます。図 4 に示すように、TCP アプリケーション層プロトコルに基づく NAS ストレージのデータ IO フローはより柔軟で適応性がありますが、データ IO パスが長くなり、データの一貫性が低くなり、データのセキュリティ上の問題が発生します。データの伝送効率も高くありません。

図 4. nfs プロトコルでの NAS ストレージデータ IO フロー図

1.3 分散ストレージ

分散ストレージシステムは、スケーラブルなクラスタアーキテクチャを採用し、データコピーアルゴリズムを使用してデータを複数の独立したデバイスに分散して保存します。分散クラスタは通常、ユニバーサル TCP/IP ネットワークを通じて接続されます。従来の集中型ストレージアレイと比較して、分散ストレージシステムは複数のストレージサーバーを通じてストレージ負荷を共有できるため、大規模ストレージアプリケーションのニーズを満たすことができます。分散ストレージシステムの一般的な形式には、分散ファイルシステム (HDFS など) やオブジェクトストレージ (Ceph など) があります。

アーキテクチャの観点から見ると、集中型ストレージシステムと比較して、分散ストレージシステムの導入アーキテクチャは一般に一般的なサーバネットワーク相互接続方式を使用するため比較的単純ですが、その論理アーキテクチャはより複雑です。分散ストレージシステムの中心的な設計思想は分散化です. 分散化の難しさは主にメイン制御ノードの分散化にあります. HDFS などのメイン制御ノードを持つアーキテクチャのアーキテクチャ設計思想はマップです-reduce (大規模なものから小規模なものへの縮小)、分割統治、およびマージ処理を行うこのアーキテクチャでは、マスターコントロールノードの調整が必要ですが、マスターコントロールノードの負荷はデータノードに分散され、データのコピーはデータノードに保存されます。図 5 に示すように、各データコピーはデータノード上の 3 つの異なるノードに分散されます。分散化の最大の利点はマスターノード自体のボトルネックを解決することであり、そのアーキテクチャ設計のアイデアはバランスの取れた設計です。アーキテクチャにはデータノードしかありませんが、より多くのロジックを抽象化する必要があります。機能コンポーネントはさまざまなノードに均等に分散されます。Ceph ブロックストレージの使用を例に挙げます。Mon などのクラスター管理および監視コンポーネントに加えて、Ceph の OSD コンポーネントは物理ディスクの管理に使用されます。PG は OSD に基づいて構築されます。データオブジェクトは PG に保存され、データオブジェクトは Ceph ブロックデバイスに対応しており、Ceph ブロックデバイスはアプリケーションで使用できるようにフォーマットおよびパーティション化することができます。アーキテクチャ図を図 6 に示します。

図 5. マスターノードを備えた分散ストレージアーキテクチャ

図 6. マスターノードを使用しない Ceph ストレージアーキテクチャ

ストレージ IO データフローの観点から見ると、データチャネルが少ない集中型ストレージとは異なり、分散ストレージはより多くのより広いデータ入口を持つことができますが、クラスター内にはより多くのデータフローもあります。Cephのブロックストレージを例にとると、クライアントアプリケーションがアクセスするファイルシステムはCephブロックデバイスに相当し、ブロックデータはネットワーク経由でCephクラスタRBDサービスにアクセスし、最終的には3コピーOSDのディスク読み書きに相当します。プロセスを図 7 に示します。3 コピーの分散ストレージシステムの場合、データの強力な一貫性を確保するために、通常、1 つの書き込み IO では、書き込みの完了を最終的に確認する前にマスターコピーと他の 2 つのスレーブコピーが書き込まれる必要があります。

図 7. Ceph ストレージ IO データフロー図

2. ストレージのパフォーマンス分析

ストレージのパフォーマンス分析はパフォーマンス最適化の基礎であり、さまざまな設計ソリューションを備えた多くの種類のストレージシステムが存在しますが、パフォーマンス分析手法には一定の普遍性があります。ストレージの性能分析手法は定性的手法と定量的手法に分けられますが、通常、理解や技術選択の初期段階では定量的分析を行うための条件が整っていない可能性があるため、ストレージシステムの性能評価には主に定性的分析手法が使用されます。 ; そして POC に入ると、テスト、システムの運用、保守などの際には、定量的な分析が主な焦点となり、実際のパフォーマンス指標データを通じてストレージのパフォーマンスのボトルネックを特定する必要があります。

2.1 定性分析

定性分析は、個人の運用および保守の経験に基づいて、ストレージシステムのパフォーマンスがアプリケーションシステムのニーズを満たせるかどうか、およびストレージシステムにパフォーマンスのボトルネックがあるかどうかを分析します。これらはすべて、アプリケーションデータタイプの精通度に依存します。そしてストレージシステム。

2.1.1 アプリケーションデータのIO分析

アプリケーションデータ IO のタイプを理解することは、ストレージパフォーマンス分析の基礎です。表 1 に示すように、さまざまなアプリケーションデータの IO アクセスには違いがあり、主に IO サイズ、シーケンシャルまたはランダムの読み取りと書き込み、読み取りと書き込みの比率などに反映されます。

アプリの種類	IOサイズ	読み書き比率	ランダムまたはシーケンシャルな読み取りと書き込み
一般文書	小さい	読書の割合が多い	主にランダムな読み書き
ログファイル	小さい	かなりの割合で書く	シーケンシャル読み取りおよび書き込み
ビデオストリーミング	大きい	読書の割合が多い	主にシーケンシャルな読み取りと書き込み
オペレーティング·システム	小さい	読書の割合が多い	ほとんどの場合、順次読み取りと書き込みが行われます
データバックアップ	大きい	かなりの割合で書く	シーケンシャル読み取りおよび書き込み
OLTPデータベース	小さい	約 70% 読み取り/30% 書き込み	主にランダムな読み書き
OLAPデータベース	大きい	読書の割合が多い	主にシーケンシャルな読み取りと書き込み

表 1. アプリケーションのデータ IO タイプ

IOサイズ

アプリケーションのデータ型が異なると、データファイルのサイズも異なり、データ IO サイズも異なります。ストレージシステムの IO 処理能力が固定されていると仮定すると、IO が大きい方が単位時間あたりに処理するデータの量が増えるのは明らかなので、小さい IO をマージする方が効率的になります。また、ストレージシステムにはデータサイズの上限があると仮定します。 IO が毎回処理されると、大きな IO が毎回処理される前に分割する必要があり、明らかに IO 処理効率が低下します。たとえば、SAN ストレージは高い IO 処理能力を備えていますが、一度に処理される IO が比較的小さいため、高いパフォーマンスが要求される小規模な IO アプリケーションシステムに適していますが、大規模な IO アプリケーションデータを処理すると効率が低下します。。

読み書き比率

読み取り/書き込み比率はアプリケーションデータの重要な特性の 1 つであり、IO 読み取り操作と書き込み操作の間には大きな違いがあります。一般に、書き込み操作はより多くのストレージパフォーマンスを消費し、書き込み IO 処理能力と遅延が大きく、キャッシュ要件の違いが大きくなります。分散ストレージの場合、マルチコピーメカニズムは読み取り操作を最適化できますが、書き込み操作には役に立ちません。書き込み確認パスが長いため、データ伝送パスを最適化し、より多くの書き込みキャッシュを構成する必要があります。読み取り率の高いアプリケーション向けのシステム。

シーケンシャルまたはランダムな読み取りおよび書き込み

シーケンシャルまたはランダムの読み取りと書き込みの違いは、主にディスクメディアの特性、事前読み取りメカニズム、キャッシュヒット率などに反映されます。機械式ハードディスクの場合、シーケンシャル読み取りおよび書き込み IO はディスクのシーク時間を短縮できますが、ランダム読み取りおよび書き込み IO は応答時間を長くします。キャッシュヒット率を向上させることで、キャッシュ内のデータをシーケンシャル読み取りおよび書き込みに変換できます。 ; SSD ハードドライブには機械的シークがなく、ランダム読み取りおよび書き込み機能は機械的ハードドライブよりもはるかに優れています。

2.1.2 パフォーマンスのボトルネック分析

ストレージパフォーマンス分析の鍵は、パフォーマンスボトルネックを分析することであり、これには 2 つの側面が含まれます: 1 つはパフォーマンスボトルネックを引き起こす要因、もう 1 つはパフォーマンスボトルネックの場所とストレージ IO 輻輳の場所です。

1) パフォーマンスのボトルネックを引き起こす要因

ストレージホットスポット: ストレージホットスポットは、計画と設計における欠陥です。一般的なシナリオには、特定のストレージノード、ポート、ディスクなどに過度に集中しているデータ IO 負荷、ストレージリソースの競合、ロックの競合、ソフトウェアおよびハードウェアのパラメーター制限などが含まれます。

パフォーマンスのスパイク: データ IO の同時実行性が高く、パフォーマンス要件が短期間で解放されるシナリオで一般的です。パフォーマンスのスパイクにより、既存のホットな問題が完全に明らかになり、ストレージパフォーマンスのボトルネックが引き起こされます。典型的なシナリオには、仮想デスクトップの起動嵐、フラッシュセールサービス、等

サービス機能の低下: 障害シナリオでよく見られる、ストレージサービス機能の低下とビジーなデータ IO フェーズの組み合わせは、ストレージパフォーマンスのボトルネックを引き起こします。一般的な障害シナリオには、SAN ストレージの単一ストレージコントローラーの障害、ディスクの再構築などが含まれます。分散ストレージでは、主にノードまたはディスクがオフラインになったり、データコピーの再構築やデータコピーの応答が遅いことが原因で、パフォーマンスのジッターが発生しやすくなります。顧客の CPU とデータコピーの応答が遅いことが原因です。エンドサーバーのメモリリソースが不足しているなど。

2) パフォーマンスのボトルネックの位置付け

ストレージの性能ボトルネック箇所は、ストレージシステムのアーキテクチャと合わせて分析する必要があり、ストレージシステムの構成に応じて、性能ボトルネック箇所を以下のカテゴリに大別できます。

データ伝送ネットワーク：ストレージの外部および内部のデータ伝送ネットワークの帯域幅、ポートレート、伝送プロトコル、伝送路の負荷分散

ストレージコントローラー: コントローラーの CPU 処理能力

キャッシュ: 主にクライアントキャッシュとストレージキャッシュに分けられ、キャッシュサイズ、キャッシュヒット率、読み取りキャッシュと書き込みキャッシュの割り当て率が含まれます。

ディスク: 主に機械式ハードディスク、フラッシュディスク、およびその他のディスクメディアに分かれており、ディスク速度、単一ディスクの読み取りおよび書き込み IOPS、ディスク容量、ディスク数、ディスク冗長性 (RAID、コピーまたは消去コーディング) アルゴリズムが含まれます。

クライアント: クライアントの CPU、メモリ、その他のリソースの使用状況、他のアプリケーションによるストレージリソースの占有、およびその他の外部環境の影響に反映されます。

2.2 定量分析

定量分析は、データ指標の観点から問題を分析および解決するもので、ストレージシステムのサービス能力をストレージ側から測定するだけでなく、ユーザーアプリケーション側からストレージ IO エクスペリエンスを測定することもできます。一般に、ストレージ側の定量分析では、ストレージネットワークやクライアントの影響が除外され、パフォーマンスデータは、ストレージシステム自体にパフォーマンスのボトルネックがあるかどうかを示し、ストレージシステムのパフォーマンス監視に使用できます。ユーザーアプリケーション側は主に一部のパフォーマンスに使用されます。テストシナリオは、ベンチマークツールを通じて、現在のシステム環境のパフォーマンスベースラインを形成できます。

2.2.1 3 つの主要なパフォーマンス指標

ストレージ側の定量分析であっても、ユーザーアプリケーション側の定量分析であっても、IOPS、スループット（Throughput）、レイテンシー（Latency）という3つの主要なストレージパフォーマンスデータ指標と切り離すことはできません。したがって、3つのパフォーマンスデータ指標の意味と相関関係を明確にする必要があります。

IOPS: ストレージによって 1 秒あたりに処理される IO 操作の数を表します。ストレージシステムの場合、パフォーマンス分析を実行するときは、全体的な IOPS に注意を払う必要があるだけでなく、単一のコントローラー、単一の LUN、または単一のディスクの IOPS を分析する必要があることもあります。読み取りまたは書き込み IOPS の間。

スループット: ストレージが 1 秒あたりに処理する IO データの量を表し、ストレージのデータ送信によって占有される帯域幅を表します。IOPS と同様に、読み取りまたは書き込みに分類することもでき、コンポーネントごとに分析できます。

レイテンシ: ストレージシステムが IO 操作を処理するのに必要な時間を表します。通常、これは最も重要なストレージパフォーマンス指標です。IOPS と同様に、読み取りまたは書き込みに分類することもでき、個々のコンポーネントごとに分析できます。

3 つの主要なパフォーマンス指標の分析では、大規模な IO アプリケーションのパフォーマンスを評価するためにスループットを使用するのがより科学的ですが、データベースなどの小規模な IO アプリケーションの場合は、IOPS とレイテンシの指標を通じてパフォーマンスを評価する必要があります。これらの要件が満たされた場合にのみ、高い同時実行性と高速なデータベースアクセスを処理できます。

2.2.2 パフォーマンステストの分析

ストレージパフォーマンステストでは、ストレージのパフォーマンス指標をよりよく理解できます。ストレージパフォーマンステストを例に挙げます。ストレージストレステストツール vdbench (ベアディスクとファイルアクセス方法の両方のストレステストに使用できます)。テストの背景は、ストレージのパフォーマンステストです。ホストに 5 つの LUN が割り当てられます。ホストは、これら 5 つのベアディスクに対してランダムな読み取りおよび書き込みテストを実行します。そのうち 80% が読み取り、20 個が書き込みられます。IO サイズは、テスト用に段階的に調整されます。3 つの主要なパフォーマンスデータ指標以下の通り：

IOサイズ	IOPS	スループット (MB/秒)	遅延 (ミリ秒)
4KB	89288	348.78	0.411
16KB	75209	1175.15	0.488
32KB	59415	1856.72	0.617
64KB	36612	2288.30	1.005
128KB	20686	2585.82	1.833

表 2. ストレージパフォーマンステストデータ

このストレージパフォーマンステストの結論は次のとおりです。

1) ストレージコントローラーの CPU 使用率は 20% ～ 45% でピークに達し、図 8 に示すように、ストレージコントローラーがより高い IO 負荷にも耐えることができることを示しています。

図 8. ストレージコントローラーの CPU 使用率

2) このテストではホストのシステムパフォーマンスのボトルネックには到達せず、CPU 使用率は 20% 未満でした。これはストレージパフォーマンス分析でも重要です。

図 9. ホストシステムの CPU 使用率

3) ストレージパフォーマンスベースライン: 表 2 のテストデータは、さまざまな IO 負荷の下で 5 LUN ストレージを使用する特定のホストのパフォーマンスベースラインデータです。実際の操作中に、他のアプリケーションの IO および読み取りおよび書き込み IO サイズが考慮されます。不均一な要因により、一般的な IOPS のピークはベースライン値の 50% になります。

4) スループットと IOPS: スループット = IOPS*IO サイズ。同じビジネスシナリオでは、一般的な IO サイズは大きく変わりません。その場合、制限テストでのスループットは IOPS に直接比例しますが、スループットは、ネットワーク帯域幅と IOPS は、ストレージ LUN の処理能力によって制限されます。

5) レイテンシと IOPS: テストデータではレイテンシと IOPS の間に反比例の関係があることがわかります。つまり、IOPS が低いほどレイテンシが高くなります。これは、IO が異なるとストレージの負荷圧力が異なるためです。サイズテストシナリオも同様、つまり大規模な IO の場合、ストレージ負荷が大きくなり、IOPS が低下し、遅延が増加します。ストレージシステムの通常の動作条件における IOPS とレイテンシの関係を図 10 に示します。ほとんどの場合、ストレージに対する負荷圧力が大きくなり、IOPS が増加し、レイテンシが増大し始めます。レイテンシが高すぎると、ビジネスシステムのパフォーマンスに影響を与えます。したがって、ほとんどの場合、レイテンシーが最も重要なストレージパフォーマンス指標となり、一般に、より高いパフォーマンス要件が求められるビジネスシステムの場合、ストレージレイテンシーは 5 ミリ秒未満である必要があります。

図 10. 通常の動作条件におけるストレージ IOPS と遅延

3. ストレージパフォーマンスの最適化

ストレージパフォーマンスの分析と最適化は長期にわたる複雑かつ重要なタスクであり、ストレージパフォーマンス最適化作業を継続的に発展させるためには、ストレージパフォーマンス最適化の目標を明確にし、詳細なパフォーマンス分析を実施し、段階的な最適化計画と検証計画を策定する必要があります。。

3.1 最適化戦略

ストレージパフォーマンスの最適化作業には戦略的な性質があり、より合理的なストレージパフォーマンスの最適化計画を策定できるのは、科学的な最適化戦略のみです。

1) 包括的な考慮: ストレージのパフォーマンスは世界的な問題であり、パフォーマンス最適化の決定の正確性を向上させるために、IO パス上のパフォーマンスのボトルネックを包括的に考慮し、パフォーマンス最適化ソリューションで起こり得る連鎖反応を分析する必要があります。

2) 最適化の費用対効果: 合理的なパフォーマンス最適化目標を設定します。複数のパフォーマンス最適化ソリューションを選択する場合は、ソリューションのコスト、実装の複雑さ、利点などを総合的に考慮する必要があります。

3) 計画の方が重要: ストレージパフォーマンスの最適化によって生じる最適化と変換のコストと比較して、事前に合理的な計画を立てることがより重要です。たとえば、ビジネスパフォーマンス要件を考慮したストレージの選択、システムがオンラインになる前のストレージパフォーマンステストのベースラインデータとパフォーマンス容量管理、ストレージの拡張では、パフォーマンス容量の指標 (ストレージ IOPS/ に大きな変化があるかどうかの評価) に注意を払う必要があります。拡張後の GB）、ストレージのパフォーマンス負荷のバランスのとれた分散など。

4) パフォーマンス監視の向上: エンドツーエンドのストレージパフォーマンスも非常に重要であり、データ IO パス全体を監視し、ストレージパフォーマンスのベースラインに基づいて実際の実行パフォーマンスデータを分析し、ストレージパフォーマンスのボトルネックをタイムリーに発見して検証します。ストレージの最適化の結果。

3.2 最適化計画

ストレージパフォーマンス最適化ソリューションは、次のカテゴリに大別できます。

1) ハードウェアのアップグレード

1 台のメカニカルハードディスクの IOPS は約 100、レイテンシは 5 ミリ秒以上ですが、1 台の SSD の IOPS は 10,000 を超え、レイテンシは 1 ミリ秒未満です。フラッシュストレージでは、パフォーマンスを大幅に向上させることができます。NVMe RDMA や RDMA などのテクノロジーを適用すると、基礎となる通信フレームワークが最適化され、データ伝送効率が大幅に向上し、ストレージの遅延が削減されます。ストレージ制御ノードの水平または垂直の拡張により、ストレージ負荷が効果的に増加します。クライアントのハードウェアをアップグレードすると、クライアントの CPU、メモリ、ネットワークなどによって引き起こされるパフォーマンスのボトルネックも解消できます。

ハードウェアのアップグレードはストレージのパフォーマンスを最適化する非常に効果的な手段ですが、多くの場合、比較的高額なハードウェアコストが必要となり、入出力比を慎重に評価する必要があります。

2) 上位層アプリケーションの最適化

上位層アプリケーションの最適化手法も比較的充実しており、主な目標は、データ送信前の重複排除やデータ圧縮の有効化、IO 同時実行性の最適化、多数の小規模なデータの集約など、上位層アプリケーションによってストレージに与えられる IO 負荷を軽減することです。 IO から大規模 IO への変換、データベースのインデックス作成の最適化、SQL ステートメントの最適化。

3) パフォーマンス負荷を調整する

パフォーマンス負荷の調整は、主にホットストレージのパフォーマンスの問題を対象としています。解決策には、ディスク分散の最適化とディスク負荷の調整、ストレージネットワークポートの負荷の調整、ストレージコントローラの負荷の調整、ストレージの追加と新しいストレージへの負荷の一部の調整が含まれます。

4) データキャッシュの最適化

データキャッシュはストレージシステムの非常に重要なパフォーマンスモジュールであり、通常、キャッシュには通常のディスクよりもはるかに高速なメモリやフラッシュメモリなどの高速ストレージメディアが使用されます。ストレージのパフォーマンスの問題の多くはキャッシュに起因しており、キャッシュの最適化によって解決されます。データキャッシュは、クライアントローカルキャッシュとストレージキャッシュに分かれています。たとえば、一部の分散ファイルシステムでは、クライアントのローカルキャッシュが非常に重要です。キャッシュサイズを増やすと、キャッシュヒット率が効果的に向上します。ストレージキャッシュも非常に重要です。マルチレベルデータキャッシュテクノロジにより、ホットデータをより高速なストレージメディアに保存できます。 . 、ストレージの待ち時間を短縮します。