ECS: BaseURL mancante che causa errori 400/404 durante le operazioni di lettura e scrittura (in inglese)

Gli errori HTTP 400/404 vengono visualizzati quando si tenta di leggere e scrivere su ECS utilizzando S3.

Quando le operazioni di elenco sono in esecuzione in un'ambiente con più VDC, le richieste potrebbero non riuscire con unmessaggio E RROR_KEYPOOL_NOT_FOUND.

1. Eseguire una query sulle impostazioni dell'ambito dell'utente in 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. Utilizzare svc_request per cercare gli ID delle richieste HTTP non riuscite:

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. Ottenere i dettagli della richiesta non riuscita nei log dataheadsvc. 

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. Verificare cosa è configurato per l'URL di base su entrambi i siti:

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. Il load balancer inviava richieste al VDC xxxobj7 con nome baseurl xxxobj6, che non era configurato in tale VDC. Pertanto, xxxobj7 VDC non è riuscito a trovare il bucket. L'URL di base è una configurazione specifica del VDC. Non viene replicata tra VDC. 

6. La soluzione consiste nell'aggiungere entrambi gli URL di base a entrambi i VDC poiché il load balancer in questo caso invia traffico incrociato a entrambi i VDC. L'impostazione "Use with Namespace" è importante in questo caso, perché è l'impostazione che consente a ECS di analizzare il namespace dall'URL fornito dal client. Una volta che queste impostazioni sono corrette, il client può accedere a oggetti/bucket da entrambi i VDC.