ECS: Okuma/Yazma işlemleri sırasında 400/404 hatalarına neden olan eksik BaseURL

HTTP 400/404 hataları, S3 kullanarak ECS yi okumaya ve yazmaya çalışırken görülür.

Liste işlemleri birden fazla VDC ortamında çalışırken istekler ERROR_KEYPOOL_NOT_FOUND mesajıyla başarısız olabilir.

1. ECS'de kullanıcı kapsamı ayarlarını sorgulayın: 

# 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. Başarısız HTTP istek kimliklerini aramak için svc_request kullanın:

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. dataheadsvc günlüklerinde başarısız olan isteğin ayrıntılarını alın. 

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. Her iki sitede de temel URL için nelerin yapılandırıldığını kontrol edin:

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. Yük dengeleyici, xxxobj7 VDC'ye bu VDC'de yapılandırılmamış olan xxxobj6 temel url adıyla istek gönderiyordu. xxxobj7 VDC grubu bulamadı. Temel URL, VDC'ye özel bir yapılandırmadır. VDC'ler arasında çoğaltılmaz. 

6. Çözüm, her iki temel URL'yi de her iki VDC'ye de eklemektir çünkü bu durumda yük dengeleyici her iki VDC'ye de çapraz trafik göndermektedir. Burada "Ad Alanı ile Kullan" ayarı önemlidir, çünkü bu, ECS'nin ad alanını istemci tarafından sağlanan URL'den ayrıştırmasına izin veren ayardır. Bu ayarlar doğru olduğunda istemci, nesnelere/kovalara her iki VDC'den de erişebilir.