ЕКС: Відсутність BaseURL, що спричиняє помилки 400/404 під час операцій читання запису

Помилки HTTP 400/404 спостерігаються при спробі читання і запису в ECS за допомогою S3.

Коли операції зі списком виконуються в середовищі з кількома VDC, запити можуть завершуватися помилкою зповідомленням E RROR_KEYPOOL_NOT_FOUND.

1. Запитайте налаштування області користувача на 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. Використовуйте svc_request для пошуку ідентифікаторів невдалих HTTP-запитів:

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. 

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. Перевірте, що налаштовано для базової URL-адреси на обох сайтах:

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. Розподілювач навантаження надсилав запити на xxxobj7 VDC з базовим ім'ям xxxobj6, який не був налаштований на цьому VDC. Отже, xxxobj7 VDC не зміг знайти відро. Базова URL-адреса є специфічною для VDC конфігурацією. Він не реплікується між VDC. 

6. Рішення полягає в тому, щоб додати обидві базові URL-адреси до обох VDC, оскільки балансувальник навантаження в цьому випадку надсилає перехресний трафік до обох VDC. Тут важлива настройка "Use with Namespace", тому що саме вона дозволяє ECS аналізувати простір імен з URL, наданого клієнтом. Як тільки ці налаштування будуть правильними, клієнт може отримати доступ до об'єктів/сегментів з обох VDC.