IBM Cloud Docs
ベストプラクティス File Storage for Classic

ベストプラクティス File Storage for Classic

当社のベストプラクティスに従うことで、ストレージのパフォーマンスを最大限に引き出し、アプリケーションのダウンタイムを回避することができます。

ベスト・プラクティス 1-パスをクリアする

最大 IOPS を実現するには、十分なネットワーク・リソースを用意する必要があります。

  • 専用 VLAN 上でストレージ・トラフィックを実行します。 ソフトウェア・ファイアウォールを介してストレージ・トラフィックを実行すると、待ち時間が増加し、ストレージ・パフォーマンスに悪影響を与えます。 ファイアウォールをバイパスするように VLAN 上でストレージ・トラフィックを実行することをお勧めします。 詳しくは、 独自の VLAN インターフェースへのストレージ・トラフィックのルーティング を参照してください。

  • 可能な限り、 ストレージ・トラフィックをゲートウェイ・デバイスにルーティングしない ようにしてください。 ストレージ・トラフィックがゲートウェイ・デバイスに経路指定されると、ストレージ・トラフィックに待ち時間が追加される可能性があります。また、ゲートウェイ・デバイスのファイアウォールの構成が誤っている場合は、ストレージ・トラフィックの中断が発生する可能性があります。 ストレージの中断は、単一の (クラスター化されていない) ゲートウェイ・デバイスで再始動などの保守が必要な場合に特に当てはまります。 ストレージトラフィックをゲートウェイデバイス経由でルーティングする必要がある場合は、ゲートウェイデバイスに少なくとも10Gbpsのインターフェースがあることを確認してください。そうでないと、ゲートウェイデバイスがネットワークのボトルネックになる可能性があります。

  • NFS トラフィックのファイアウォールでは、個別の IP アドレスの代わりに サブネット・アドレスを使用 します。 NFS ホスト名は 6 つの IP アドレスを処理しますが、これらの 6 つの IP アドレスは変更できます。

  • より高速な NIC を使用してください。 一部の制限は LUN レベルで設定され、インターフェースが高速であってもその制限は増えません。 ただし、イーサネット接続が低速であると、帯域幅が最良のパフォーマンス・レベルを達成するのに支障をきたす可能性があります。

  • より高い帯域幅を選択してください。 イーサネット接続の速度は、ボリュームから予想される最大スループットよりも高速でなければなりません。一般的に、イーサネット接続が、使用可能な帯域幅の 70% を超えることはありません。

    例えば、6,000 IOPS で 16 KB ブロック・サイズを使用している場合、ボリュームは約 94 MB/秒のスループットを処理できます。しかし、LUNへの1 Gbpsイーサネット接続では、サーバーが利用可能な最大スループットを使用しようとすると、ボトルネックとなります。 1Gbpsイーサネット接続の理論上の限界値の70%(毎秒125MB)では、毎秒88MBしか利用できないためです。

ベスト・プラクティス 2-ホストとアプリケーションの最適化

  • ニーズに最も適した入出力スケジューラーを使用してください。 入出力スケジューラーは、ディスク・アクセス要求を最適化するのに役立ちます。 従来は、入出力要求をマージすることによって最適化を実現していました。 ディスクの類似セクションで要求をグループ化することにより、ドライブは頻繁に「シーク」する必要がなくなり、ディスク操作の全体的な応答時間が改善されます。 最新の Linux 実装では、いくつかの I/O スケジューラー・オプションを使用できます。 これらの各オプションには、ディスク・アクセス要求をスケジュールする独自の方法があります。

    • Deadline は、 Red Hat 7.9のデフォルトの入出力スケジューラーであり、通常は別の入出力スケジューラーに変更する必要はありません。 これは待ち時間指向のスケジューラーであり、別個の読み取りキューを作成し、書き込みキューを分離することによって機能します。 各入出力要求には、カーネルが有効期限に使用するタイム・スタンプが関連付けられています。 このスケジューラーは、可能な限り最も効率的な順序付けに基づいてキューにサービスを提供しようとしますが、有効期限は、各入出力要求の「締切」として機能します。 入出力要求が締切期限に達すると、最も高い優先順位にプッシュされます。

    • No Operation (NOOP) は、発生する入出力を受け渡す基本スケジューラーです。 このスケジューラーは、すべての入出力要求を FIFO (先入れ先出し) キューに入れます。 このツールは、他のスケジューラーの複雑な入出力スケジューリングの決定が入出力パフォーマンスの低下の原因となっているかどうかを確認するのに役立ちます。 このスケジューラーは、インテリジェント・ストレージやマルチパス環境など、入出力スケジューリングを行うデバイスを使用するセットアップに推奨されます。 ホスト上でより複雑なスケジューラーを選択すると、ホストのスケジューラーとストレージ・デバイスのスケジューラーが互いに競合し、パフォーマンスが低下する可能性があります。 ストレージ・デバイスは通常、入出力をスケジュールする最良の方法を決定することができます。 I/O スケジューラーを確認して構成する方法について詳しくは、 Red Hatの NOOP または None IO Schedulers の使用方法を参照してください。

    • 完全に公平なキューイング (CFQ) はエレベーターと要求のマージの両方を使用し、NOOP や締切スケジューラーよりも少し複雑です。 これは、多くの Linux ディストリビューションの標準スケジューラーです。 キューごとにディスクを使用するタイム・スライスを割り振る前に、操作によって行われる同時要求を一連のプロセスごとのプールにグループ化します。

    ワークロードが対話式アプリケーションによって支配されている場合、ユーザーは、多数の入出力操作を行うデータベースのパフォーマンスの低下について不満を言う可能性があります。 このような環境では、読み取り操作は書き込み操作よりも著しく頻繁に行われ、アプリケーションはデータの読み取りを待機する可能性が高くなります。 デフォルトのIOスケジューラ設定を確認し、特定のワークロードに合わせて最適化するために、異なるスケジューラを試すことができます。

  • ソースデバイス>スイッチ>ルーター>スイッチ>ターゲットデバイスの ジャンボフレームを有効にする 設定し、ネットワークパス全体で同じになるようにする。 チェーン全体で同じ設定になっていないと、チェーン全体がデフォルトの最小設定に変更されます。 IBM Cloud® のネットワーク・デバイス数は、現在 9,000 に設定されています。 最高のパフォーマンスを得るには、すべてのカスタマー・デバイスを同じ 9,000 の値に設定する必要があります。

    ホスト上で MTU を 9000 に設定すると、以下の利点があります。

    • データは、より少ないフレームで伝送することができます。
    • パケット・ヘッダーに保管されるフォーマット情報のバイト数が少なくなるため、データをより速く送信できます。
    • パケット処理の CPU サイクルと命令の数を減らすことにより、スループットが向上します。
    • ジャンボ・フレームを使用すると、パケットが順不同で到着したり、失われたりする機会が少なくなり、再送信回数が少なくなります。 再送信が少ないほど、TCP リカバリーにかかる時間が短くなります。 その結果、スループットが向上します。
  • 可能な場合は、 NFSv3 プロトコルを使用してください。 ネットワーク・ファイル・システム (NFS) は、分散ファイル共有のためのネットワーク・プロトコルです。 これにより、リモート・ホストはネットワークを介してファイル・システムをマウントし、ローカルにマウントされているかのようにそれらのファイル・システムと対話することができます。 NFSv3 は、安全な非同期書き込みをサポートし、以前の NFSv2よりもエラー処理でより堅固です。 64 ビットのファイル・サイズとオフセットをサポートするため、クライアントは 2 GB を超えるファイル・データにアクセスできます。 NFSv3 no_root_squash をネイティブにサポートしており、ルートクライアントが 共有上でルート権限を保持できるようになります。 NFS NFSv4.1 もサポートされます。 VMware® デプロイメントで File Storage for Classic を使用する場合は、実装に NFSv4.1 を選択することをお勧めします。 各バージョンの異なる機能や、 VMware® vSphere, でサポートされている内容の詳細については 、「 NFS を VMware vSphere で実行する際のベストプラクティス」 をご覧ください。

  • チーミングに関する VMware® 固有のベスト・プラクティスをフォローします。 ストレージ・アレイへのネットワーク・アクセスの可用性を高めるためにチーミングを使用する予定の場合は、仮想 IP アドレスが共有されている 2 つのポートのスイッチでポート・セキュリティーをオフにする必要があります。 このポート・セキュリティー設定の目的は、IP アドレスのスプーフィングを防止することです。 したがって、多くのネットワーク管理者がこの設定を有効にします。 ただし、これを変更しない場合、ポート・セキュリティー設定により、あるスイッチ・ポートから別のスイッチ・ポートへの仮想 IP のフェイルオーバーが防止されます。 これにより、あるパスから別のパスにチーミングをフェイルオーバーすることができなくなります。 ほとんどの LAN スイッチでは、ポート・セキュリティーはポート・レベルで使用可能になっているため、ポートごとにオンまたはオフに設定できます。