ECS:PowerScale:CloudPoolsのパフォーマンスの問題
Summary: 仮想スタイルのアドレス指定を使用し、パフォーマンスを向上させるようにECSとPowerScale(旧Isilon)を構成します。
Symptoms
ECSが仮想IPと仮想スタイルのアドレス指定で構成されていない場合、転送速度が遅くなる可能性がある問題が発生する可能性があります
CloudPoolsは、両方のスタイルのバケット アドレス指定(仮想スタイル アドレス指定、パス スタイル アドレス指定)をサポートしますが、常に仮想スタイルのアドレス指定を最初に試行します。
Cause
PowerScaleとCloudPoolsが保存されたデータを読み取る方法は、1MBのフラグメント単位です
1MBを超えるファイルの読み取りを行うと、これらのフラグメントが順番にフェッチされ、9番目のフラグメントごとに、次のものを含む168バイトのヘッダー ファイルが作成されます
この問題は、これらの要求が数千または数十万の場合に発生します。つまり、S3リクエストを作成する際に固有のオーバーヘッドが積み重なり、ファイルの取得速度と転送速度が低下します
仮想形式のアドレス指定を最初に使用しようとするため、仮想形式のアドレス指定を使用するように構成されていないと、要求間に遅延が発生する可能性があります。
Resolution
プロローグ:
- VIP = "仮想 IP (VIP) は、ワールドがブラウザをサイトに向けるロード バランシング インスタンスです。VIPにはIPアドレスがあり、使用するには公開されている必要があります。通常、TCPまたはUDP ポート番号は、WebトラフィックのTCPポート80など、VIPに関連付けられます。VIP には少なくとも 1 つの実サーバが割り当てられており、そこにトラフィックが分配されます。
- CP = CloudPools
- DNS RR = DNSラウンド ロビン
- CNAME = 正規名レコードは、ドメイン ネーム システムのリソース レコードの一種で、あるドメイン名を別のドメイン名にマップし、正規名と呼びます。これは、1 つの IP アドレスから複数のサービスを実行する場合に便利です。
短いベース URL で仮想形式のアドレス指定を設定する場合は、以下が必要です。
- CPセットアップで使用されるロード バランサーのVIP(またはDNS RRのVIP)
- ロード バランサーVIPのDNSのワイルドカードCNAMEエントリー。これにより、bucket-name.loadbalancer-fqdn.emc.com はPowerScale CPバケット名をロード バランサーのVIP(またはDNS RR)に解決します
- loadbalancer.emc.com のCNAMEエントリー
- ECS UIで構成されたVIPのベースURL
仮想ホスト形式のアドレス指定(CloudPoolsに推奨):
仮想ホストのアドレス指定スキームでは、バケット名がホスト名に表示されます。たとえば、ホスト ecs1.yourco.com の「mybucket」というバケットには、次を使用してアクセスします。
http://mybucket.ecs1.yourco.com
さらに、ECSではアドレスにネームスペースを含めることもできます。例:
<bucketname>.<namespace>.ecs1.yourco.com
このアドレス指定スタイルを使用するには、URLのどの部分がバケット名かを認識できるようにECSを構成する必要があります。これは、ベースURLを構成することによって行われます。さらに、DNSシステムがアドレスを解決できることを確認する必要があります。詳細については、以降のセクションを参照してください。
パス ベースのアドレス指定:
パスベースのアドレス指定スキームでは、パスの末尾にバケット名が追加されます。例:
ecs1.yourco.com/mybucket
名前空間を含める場合は、次の形式を使用します。
ecs1.yourco.com/mynamespace/mybucket
「パート1:DNS設定:
S3サービスを使用してECSストレージにアクセスする場合は、URLによってECSデータ ノードまたはロード バランサーのアドレスが解決されることを確認します。
アプリケーションが仮想ホスト形式のアドレス指定を使用している場合、URL にはバケット名が含まれ、名前空間を含めることができます。このような状況では、仮想ホスト形式のアドレスを解決する DNS エントリを含める必要があります。これを行うには、DNS エントリでワイルドカードを使用します。
たとえば、アプリケーションが bucket.ecs.example.com の形式で要求を発行する場合は、2 つの DNS CNAME エントリが必要です
*.cloudpools_uri.example.com - このワイルドカードCNAMEにより、DNSはURLにバケット名を含むリクエストを解決できます。(CloudPoolsはこれをデフォルトで使用します)
cloudpools_uri.example.com - このCNAMEを使用すると、ECSが要求のどの部分がバケットまたはネームスペースであるかを判断した後にベース名を解決できます
ecs-loadbalancer.example.com - これは、LoadBalancer、GTM、または RoundRobin DNS の FQDN の環境内の既存の A レコードである必要があります。
NAME TYPE VALUE
--------------------------------------------------
*.cloudpools_uri.example.com CNAME ecs-loadbalancer.example.com
cloudpools_uri.example.com CNAME ecs-loadbalancer.example.com
ecs-loadbalancer.example.com A 192.0.2.23
これらのエントリーにより、サービス レベルのコマンド(バケットのリスト)を発行するときにベース名を解決し、仮想ホスト形式のバケット アドレスを解決できます。
「パート2:ECS UIでのベースURLの構成:
仮想ホスト形式のアドレス指定を使用するS3アプリケーションがあり、それを使用してECSに接続する場合は、アドレスのどの部分がバケットを参照し、オプションでネームスペースを参照しているかをECSが認識できるようにベースURLを設定する必要があります。ベースURLは、ECS PortalまたはECS Management REST APIを使用して設定でき、ECSシステム管理者ロールが必要です。
[Base URL Management]ページには、作成されたベースURLと、ECSでのベースURLの使用方法が表示されます
オブジェクト ベースURL > 設定

ECSがバケットの場所のプレフィックスの処理方法を認識できるようにするには、次のいずれかのオプションを選択してベースURLを構成する必要があります。
- ネームスペースでベースURLを使用
- ネームスペースなしでベースURLを使用する
リクエストを処理する際、ECSは次の処理を行います。
- x-emc-namespaceヘッダーからネームスペースを抽出してみます。見つかった場合は、次の手順をスキップしてリクエストを処理します。
- ホスト ヘッダーから URL のホスト名を取得し、アドレスの最後の部分が構成されたベース URL のいずれかと一致するかどうかを確認します。
- ベースURLが一致する場合は、ホスト名のプレフィックス部分(ベースURLが削除されたときに残る部分)を使用して、バケットの場所を取得します。
次の例は、さまざまな構造を持つ受信HTTPリクエストをECSがどのように処理するかを示しています
ネームスペースを使用しないベースURLの例:
Name: Example_BASEURL
BaseURL: cloudpools_uri.example.com
Use with Namespace: No
これにより、要求のどの部分がバケット名であるかを判断できます。次に、要求の例を示します。
d0007430acf369abf0d5681089a1a96abc8fdi16.cloudpools_uri.example.com
ネームスペースを使用して構成すると、もう1つのサブドメインがさかのぼってネームスペースとバケットが決定されます。
ECSでのベースURLの追加:
- この操作には、ECSのシステム管理者ロールが必要です。
- URLを使用してオブジェクトの場所を指定するリクエストで指定されたドメインが、ECSデータ ノードまたはデータ ノードの前にあるロード バランサーの場所を解決することを確認する必要があります。
手順:
- ECS Portalで、Settings>Object Base URLsを選択します。
- [新しいベース URL] を選択します。
[New Base URL] ページが表示されます。

- ベースURLの名前を入力します。これにより、ベース URL テーブルを参照するときに、ベース URL に関する追加情報が提供されます。
- ベースURLを入力します。
オブジェクトの場所の URL が d0007430acf369abf0d5681089a1a96abc8fdi16.cloudpools_uri.example.com という形式の場合、ベース URL は cloudpools_uri.example.com になります。
名前空間セレクターで形式を指定できます。 - オブジェクトアドレスが URL でエンコードされる形式を選択します。ネームスペースあり、またはネームスペースなし
- 「保存」を選択します。
「パート3:CloudPoolsのURIの構成:
最後に、CloudPools構成で適切なURIを設定する必要があります。すでにURIが正しく構成されている可能性がありますが、ここで確認します
URIは、パート1で設定した、ロードバランサー、GTM、またはラウンドロビンを指すCNAMEである必要があります
あなたのURIは次のとおりです。
cloudpools_uri.example.com
オプションで、次のようにポート番号を入力できますが、必須ではありません。
cloudpools_uri.example.com:9020
cloudpools_uri.example.com:443
クラウド アカウントの構成中は、ベースURLにプレフィックス「subdomain」を追加しないでください。
たとえば、URI http://powerscale.cloudpools_uri.example.com:9020を使用してクラウド アカウントを構成しないでください
例外は、PowerScaleがECS上のネームスペースであり、前の手順パート2で[ネームスペースでベースURLを使用する]をオンにした場合です。
「パート4:CloudPoolsが新しい構成を適切に使用しているか確認しています。
これらの手順のいずれかについてサポートが必要な場合は、PowerScaleまたはECSサポート チームでサービス リクエストをオープンしてください。
ロード バランサーのIP = 192.0.2.12
DNSのIP = 192.0.2.53
ECSのIP = 192.168.219.254
PowerScaleのIPアドレス = 192.0.2.70
- DNSがワイルドカードを適切に解決していることを確認してください。VIPまたはLBのIPに解決されるはずです。
admin@:> nslookup TEST.cloudpools-uri.example.com
Server: 192.0.2.53
Address: 192.0.2.53#53
TEST.cloudpools-uri.example.com canonical name = ecs-loadbalancer.example.com
Name: ecs-loadbalancer.example.com
Address: 192.0.2.12
- DNSがベースを適切に解決していることを確認してください。VIPまたはLBのIPに解決されるはずです。
admin@:> nslookup cloudpools-uri.example.com
Server: 192.0.2.53
Address: 192.0.2.53#53
cloudpools-uri.example.com canonical name = ecs-loadbalancer.example.com
Name: ecs-loadbalancer.example.com
Address: 192.0.2.12
- CloudPools URIが正しく設定されていることを確認します。
- ECS UIで構成したベースURLを確認します。
- PowerScaleでCloudPoolsジョブを開始します。
ジョブが作成され、ジョブが完了した時刻をUTCで記録します。 - ECS CLIから、ステップ5で収集した時間を使用して、リクエストが正しく発行されていること、およびエラーがないことを確認します。
svc_requestを使用して、その期間の要求を確認します。
svc_request -start "2018-09-05T18:22:53" -stop "2018-09-05T18:36:05" -t HEAD summary
仮想スタイルのアドレス指定を使用できず、パス スタイルに戻る出力例(これが表示された場合は、サービス リクエストを開き、このKBを参照してください)。
- 仮想形式のアドレス指定を使用して、CloudPoolsジョブからの最初の2つのリクエストがHTTP 403応答を取得していることを確認できます。- パープルハイライト
- 次の2つのリクエストは、パス スタイルのアドレス指定に戻ります( 青色のハイライト)
- リクエストの例 - 緑色のハイライト
admin@> svc_request -start "2025-09-05 T18:22:53" -stop "2025-09-05 18:36:05" -t HEAD summary
svc_request v0.0.10 (svc_tools v1.0.0) Started 2018-09-05 18:54:12
Time range: 2018-09-05 18:22:53 - 2018-09-05 18:36:05
Running against node(s): <All nodes>
Request Type: HEAD
Resp
Node Time Request ID Prot Type MPU Client IP Status (bytes) (ms) URL
169.254.1.2 2025-09-05 18:34:07 0aa18451:1641e1e6334:565b3:3f s3 HEAD - 192.0.2.70 403 0 3 //d0007430acf369abf0d5681089a1a96abd8fdi16.cloudpools-uri.example.com/
169.254.2.3 2025-09-05 18:34:07 0aa1845a:1641e1ded8e:55d9f:77 s3 HEAD - 192.0.2.70 403 0 3 /m0007430acf369abf0d5681089a1a96abd8fdi16.cloudpools-uri.example.com/
169.254.1.1 2025-09-05 18:34:12 0aa18450:1641e1dea6e:56189:5 s3 HEAD - 192.0.2.70 200 0 6 d000e1e56aa209c8e7558b30d6d368c1a7b95i1/
169.254.1.1 2025-09-05 18:34:12 0aa18450:1641e1dea6e:56181:4d s3 HEAD - 192.0.2.70 200 0 3 m000e1e56aa209c8e7558b30d6d368c1a7b95i1/