Skip to main content
How to enable StorageGRID in your environment
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ローカルトラフィックマネージャロードバランサの詳細

共同作成者
PDF

ローカルトラフィックマネージャロードバランサのガイダンスを確認し、最適な設定を決定します。

以下は、サードパーティ製ロードバランサの設定に関する一般的なガイダンスです。お使いの環境に最適な構成を決定するには、ロードバランサ管理者にお問い合わせください。

ストレージノードのリソースグループを作成

StorageGRIDストレージノードをリソースプールまたはサービスグループにグループ化します（用語は特定のロードバランサによって異なる場合があります）。StorageGRIDストレージノードは次のポートにS3 APIを提供します。

  • S3 HTTPS：18082

  • S3 HTTP：18084

ほとんどのお客様は、標準のHTTPSポートとHTTPポート（443および80）を使用してAPIを仮想サーバに提供することを選択しています。

メモ 各StorageGRIDサイトにはデフォルトで3つのストレージノードが必要で、そのうち2つは正常な状態である必要があります。

健全性チェック

サードパーティのロードバランサには、各ノードの健常性とトラフィックを受信できるかどうかを確認する方法が必要です。NetAppでは、健全性チェックの実行にHTTP方式を使用することを推奨しています OPTIONS 。ロードバランサは個 々 のストレージノードにHTTP要求を発行し OPTIONS 、ステータス応答を期待します。 200

応答を返さないストレージノードがあると 200 、そのノードはストレージ要求を処理できません。アプリケーションとビジネスの要件によって、これらのチェックのタイムアウトと、ロードバランサが実行するアクションを決定する必要があります。

たとえば、データセンター1の4つのストレージノードのうち3つが停止している場合は、すべてのトラフィックをデータセンター2に転送できます。

推奨されるポーリング間隔は1秒に1回で、チェックに3回失敗したあとにノードをオフラインにします。

S3の健全性チェックの例

次の例では、を送信し OPTIONS て確認し 200 OK`ます。Amazon S3が許可されていない要求をサポートしていないため、を使用して `OPTIONS います。

curl -X OPTIONS https://10.63.174.75:18082 --verbose --insecure
* Rebuilt URL to: https://10.63.174.75:18082/
*   Trying 10.63.174.75...
* TCP_NODELAY set
* Connected to 10.63.174.75 (10.63.174.75) port 18082 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: webscale.stl.netapp.com
* Server certificate: NetApp Corp Issuing CA 1
* Server certificate: NetApp Corp Root CA
> OPTIONS / HTTP/1.1
> Host: 10.63.174.75:18082
> User-Agent: curl/7.51.0
> Accept: /
>
< HTTP/1.1 200 OK
< Date: Mon, 22 May 2017 15:17:30 GMT
< Connection: KEEP-ALIVE
< Server: StorageGRID/10.4.0
< x-amz-request-id: 3023514741

ファイルベースまたはコンテンツベースの健全性チェック

一般に、NetAppではファイルベースの健全性チェックは推奨されません。通常、読み取り専用ポリシーが設定されたバケットには、たとえば小さなファイル —`healthcheck.htm`が作成されます。このファイルがフェッチされ、ロードバランサによって評価されます。この方法にはいくつかの欠点があります。

  • * 1つのアカウントに依存します。*ファイルを所有するアカウントが無効になると、健全性チェックは失敗し、ストレージ要求は処理されません。

  • *データ保護ルール。*デフォルトのデータ保護方式は2コピー方式です。このシナリオでは、健全性チェックファイルをホストしている2つのストレージノードを使用できない場合、健全性チェックは失敗し、ストレージ要求が正常なストレージノードに送信されず、グリッドがオフラインになります。

  • *監査ログの肥大化。*ロードバランサは各ストレージノードからファイルをX分ごとにフェッチし、多数の監査ログエントリを作成します。

  • *大量のリソースを必要とします。*健全性チェックファイルをすべてのノードから数秒おきにフェッチすると、グリッドリソースとネットワークリソースが消費されます。

コンテンツベースの健全性チェックが必要な場合は、専用のS3バケットで専用テナントを使用します。

セッションの永続性

セッションの持続性（スティッキ性）とは、特定のHTTPセッションの持続が許可される時間のことです。デフォルトでは、ストレージノードは10分後にセッションを破棄します。持続性が長くなると、すべてのアクションでアプリケーションがセッションを再確立する必要がなくなるため、パフォーマンスが向上しますが、セッションを開いたままにするとリソースが消費されます。ワークロードにメリットがあると判断した場合は、サードパーティのロードバランサでのセッションの永続性を減らすことができます。

仮想ホスト形式のアドレス指定

AWS S3のデフォルトの方法が仮想ホスト形式になりました。StorageGRIDや多くのアプリケーションでは引き続きパス形式がサポートされますが、仮想ホスト形式のサポートを実装することを推奨します。仮想ホスト形式の要求では、ホスト名の一部にバケットが含まれます。

仮想ホスト形式をサポートするには、次の手順を実行します。

  • サポートされるワイルドカードDNSルックアップ：*.s3.company.com

  • ワイルドカードをサポートするには、サブジェクトalt名を含むSSL証明書を使用してください。*.s3.company.com一部のお客様から、ワイルドカード証明書の使用に関するセキュリティ上の懸念が表明されています。StorageGRIDは、FabricPoolなどの主要なアプリケーションと同様に、パス形式のアクセスを引き続きサポートします。とはいえ、仮想ホストがサポートされていないと、一部のS3 API呼び出しが失敗したり、正常に動作しなくなったりします。

SSLターミネーション

サードパーティのロードバランサでのSSLターミネーションには、セキュリティ上の利点があります。ロードバランサが危険にさらされると、グリッドは分離されます。

サポートされる構成は次の3つです。

  • * SSLパススルー*SSL証明書は、カスタムサーバ証明書としてStorageGRIDにインストールされます。

  • * SSLターミネーションと再暗号化（推奨）*これは、SSL証明書をStorageGRIDにインストールするのではなく、ロードバランサでSSL証明書管理をすでに実行している場合に便利です。この構成では、攻撃対象をロードバランサに限定することで、セキュリティ上のメリットが追加されます。

  • * HTTPによるSSL終了*この構成では、SSLはサードパーティのロードバランサで終端され、ロードバランサからStorageGRIDへの通信はSSLオフロードを利用するために非暗号化されます（最新のプロセッサに組み込まれたSSLライブラリを使用すると、メリットは限られています）。

パススルー構成

ロードバランサをパススルー用に設定する場合は、StorageGRIDに証明書をインストールする必要があります。メニューの[Configuration][Server Certificates]>[Object Storage API Service Endpoints Server Certificate]に移動します。

ソースクライアントのIP可視性

StorageGRID 11.4では、信頼できるサードパーティ製ロードバランサの概念が導入されました。クライアントアプリケーションIPをStorageGRIDに転送するには、この機能を設定する必要があります。詳細については、を参照してください。 "サードパーティのレイヤ7ロードバランサと連携するようにStorageGRIDを設定する方法。"

XFFヘッダーを使用してクライアントアプリケーションのIPを表示できるようにするには、次の手順を実行します。

手順

  1. 監査ログにクライアントIPを記録します。

  2. S3バケットまたはグループポリシーを使用する aws:SourceIp 。

ロードバランシング戦略

ほとんどのロードバランシングソリューションには、ロードバランシングに関する複数の戦略が用意されています。一般的な戦略は次のとおりです。

  • *ラウンドロビン*ユニバーサルフィットですが、少数のノードと大規模な転送で単一のノードを詰まらせることに苦しんでいます。

  • *最小接続。*すべてのノードへの接続が均等に分散される、小規模なオブジェクトワークロードや混在オブジェクトワークロードに適しています。

選択するストレージノードの数が増えるにつれて、アルゴリズムの選択はそれほど重要ではありません。

データパス

すべてのデータは、ローカルトラフィックマネージャロードバランサを経由します。StorageGRIDは、Direct Server Routing（DSR；直接サーバールーティング）をサポートしていません。

セツソクノフンサンノカクニン

負荷を複数のストレージノードに均等に分散していることを確認するには、特定のサイトの各ノードで確立されたセッションを確認します。

  • * UIメソッド。*メニューの[Support][Metrics]>[S3][Overview]>[LDR HTTP Sessions]に移動します。

  • *メトリクスAPI。*使用 storagegrid_http_sessions_incoming_currently_established