ECS: Ontbrekende BaseURL veroorzaakt 400/404-fouten tijdens lees-schrijfbewerkingen

HTTP 400/404-fouten worden weergegeven bij het lezen en schrijven naar ECS met behulp van S3.

Wanneer lijstbewerkingen worden uitgevoerd in een omgeving met meerdere VDC's, kunnen aanvragen mislukken metbericht E RROR_KEYPOOL_NOT_FOUND.

1. Voer query's uit op de instellingen voor het gebruikersbereik op het ECS: 

# svc_rest_cmd config/object/properties.json
  

Example:

admin@g1-ecs3:~> svc_rest_cmd config/object/properties.json
svc_rest_cmd 1.0.10

{
  "properties": {
    "user_scope": "GLOBAL"
  },
  "empty": false,
  "allProperties": {
    "user_scope": "GLOBAL"
  }
}

2. Gebruik svc_request om te zoeken naar de mislukte HTTP-aanvraag-ID's:

Example:
admin@g1-ecs3:~> svc_request errorsummary
svc_request v1.0.11 (svc_tools v1.5.4)                 Started 2019-07-02 16:26:14


Time range:  2019-07-02 14:26:14 - 2019-07-02 16:26:14
Running against node(s): <All nodes>
                                                                                     Resp                         
                                                                                     Time     Retry               
Node             Time                Request ID                         Type  Status (ms)     #       Exception                      URL
169.254.1.2      19-07-02 14:38:41   0a51548d:16b6bc5bf6e:9b15:1       GET   404    17       0       ObjectControllerException      https://testjkns3.xxxobj6.ms.com/bkt1/object1
 

3. Meer informatie over de mislukte aanvraag in de dataheadsvc-logboeken. 

admin@ecs:/opt/emc/caspian/fabric/agent/services/fabric/data> svc_request -r 0a51548d:16b6bc5bf6e:9b15:1 -start 14:00 showlogs
svc_request v1.0.10 (svc_tools v1.5.3)                 Started 2019-07-01 19:55:02

Time range:  2019-07-01 14:00:00 - 2019-07-01 19:55:01
Running against node(s): <All nodes>
Request ID: 0a51548d:16b6bc5bf6e:9b15:1
##################################################
Reqid:                    0a51548d:16b6bc5bf6e:9b15:1

Reply timestamp:          2019-07-01T14:56:41,806
Protocol:                 s3
Request Type:             GET
Size:                     177 Bytes (0.000 MB)
Response Time:            17 ms
URL:                      https://testjkns3.xxxobj6.ms.com/bkt1/object1
ShortURL:                 https://testjkns3.xxxobj6.ms.com/bkt1/object1
Bucket:
Object:                   /testjkns3.xxxobj6.ms.com/bkt1/object1
Options:
Status:                   404
Client IP:                10.xxx.xx.17
Thread ID:                qtp1776502451-104390

Request (or retry)
  completed:              No
Exception:                ObjectAccessException
Retry #:                  0 (of 0 total)

Multi-part upload:        -

log messages:
169.254.1.7  [qtp1776502451-104390-0a51548d:16b6bc5bf6e:9b15:1-s3-10.196.105.17] ERROR ResourceClient.java (line 331) 
request id 0a51548d:16b6bc5bf6e:9b15:2, 
command type REQUEST_BUCKET_GET failed with error code ERROR_KEYPOOL_NOT_FOUND and message 'bucket xxx1.bkt1 not found'
169.254.1.7 2019-07-01T14:56:41,801  INFO KeyPoolInfoAccess.java (line 283) 
Cannot get keypool info from DT server since kpId xxx1.bkt1 is not found there
169.254.1.7 2019-07-01T14:56:41,801  ERROR S3Exception.java (line 942) got object access exception. RequestId 0a51548d:16b6bc5bf6e:9b15:1
com.emc.storageos.objcontrol.object.exception.ObjectAccessException: NoSuchBucket
169.254.1.7  [qtp1776502451-104390] INFO RequestLog.java (line 83) 10.196.105.17 GET https://testjkns3.xxxobj6.ms.com/bkt1/object1 HTTP/1.1 404 17 - 177

 

4. Controleer wat er is geconfigureerd voor de basis-URL op beide sites:

Example:

Output from xxxobj7 VDC, we see only a default base url

svc_rest_cmd 1.0.10

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<base_urls>
  <base_url>
    <id>urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</id>
    <link rel="self" href="/object/baseurl/urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"/>
    <name>DefaultBaseUrl</name>
  </base_url>
</base_urls>

VDC xxxobj6 has customer  baseurl configured which is not configured on xxxobj7
svc_rest_cmd 1.0.10

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<base_urls>
  <base_url>
    <id>urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</id>
    <link rel="self" href="/object/baseurl/urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"/>
    <name>DefaultBaseUrl</name>
  </base_url>
  <base_url>
    <id>urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</id>
    <link rel="self" href="/object/baseurl/urn:ObjectBaseUrl:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"/>
    <name>xxxobj6</name>
  </base_url>
</base_urls>
 

5. De load balancer stuurde aanvragen naar de xxxobj7 VDC met de baseurl-naam xxxobj6, die niet was geconfigureerd op die VDC. Dus xxxobj7 VDC kon de emmer niet vinden. De basis-URL is een VDC-specifieke configuratie. Het wordt niet gerepliceerd tussen VDC's. 

6. De oplossing is om beide basis-URL's aan beide VDC's toe te voegen, aangezien de load balancer in dit geval cross-verkeer naar beide VDC's stuurt. De instelling "Use with Namespace" is hier belangrijk, omdat dit de instelling is waarmee ECS de namespace kan parseren op basis van de URL die door de client is verstrekt. Zodra deze instellingen correct zijn, heeft de client toegang tot objecten/buckets van beide VDC's.