Не удается выполнить резервное копирование на S3 с помощью OpsCenter 5.2.1

Я обновил OpsCenter с 5.1.3 до 5.2.0 (а затем до 5.2.1). У меня было запланированное резервное копирование на локальный сервер и местоположение S3, настроенное перед обновлением, которое отлично работало с OpsCenter 5.1.3. Я не вносил изменений в запланированное резервное копирование ни во время, ни после обновления.

На следующий день после обновления произошел сбой резервного копирования S3. В opscenterd.log я вижу следующие ошибки:

2015-09-28 17:00:00+0000 [local] INFO: Instructing agents to start backups at Mon, 28 Sep 2015 17:00:00 +0000 2015-09-28 17:00:00+0000 [local] INFO: Scheduled job 458459d6-d038-41b4-9094-7d450e4bac6f finished 2015-09-28 17:00:00+0000 [local] INFO: Snapshots started on all nodes 2015-09-28 17:00:08+0000 [] WARN: Marking request d960ad7b-2ccd-40a4-be7e-8351ac038c53 as failed: {'sstables': {u'solr_admin': {u'solr_resources': {'total_size': 155313, 'total_files': 12, 'done_files': 0, 'errors': [u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', u'{:type :opsagent.backups.destinations/destination-not-found, :message "Destination missing: 62f5a26abce7463bad9deb7380979c4a"}', сокращено для краткости.

Расположение S3 больше не отображается в OpsCenter, когда я редактирую запланированное задание резервного копирования. Когда я пытаюсь повторно добавить местоположение S3, используя ту же корзину и учетные данные, что и раньше, я получаю следующую ошибку:

Location validation error: Call to /local/backups/destination_validate timed out.

Кроме того, я не знаю, связано ли это, но для полноты картины я также вижу некоторые из этих ошибок в opscenterd.log:

WARN: No http agent exists for definition file update. This is likely due to SSL import failure.

Я получаю такое поведение либо с DataStax Enterprise 4.5.1, либо с 4.7.3.


cassandra datastax-enterprise opscenter
person LHWizard    schedule 17.09.2015    source источник

Ответы (3)


arrow_upward
2
arrow_downward

У меня была точно такая же проблема после обновления до OpsCenter 5.2.x, и я просто смог заставить ее работать правильно.

Я удалил все настройки, предложенные в предыдущем ответе, а затем создал новые корзины в us-west-1, us-west-2 и us-standard. После этого я смог успешно добавить все это в качестве пунктов назначения быстро и легко.

Мне кажется, проблема в том, что OpsCenter может пытаться перечислить объекты в корзине, которую вы изначально настроили, в моем случае для двух существующих, которые мы использовали, было 11 ТБ и 19 ГБ данных соответственно.

Это может объяснить, почему увеличение времени ожидания для одних сработало, а для других нет.

Надеюсь это поможет.

person Kaveh Nowroozi    schedule 12.11.2015
comment
Мне удалось решить проблему, удалив папку моментальных снимков в моих корзинах. Затем я смог без проблем повторно использовать те же ведра. - person LHWizard; 20.11.2015

arrow_upward
1
arrow_downward

Попробуйте добавить свойство remote_backup_region в файл конфигурации кластера под заголовком [агенты] в «имя-кластера».conf. Допустимые значения: us-standard, us-west-1, us-west-2, eu-west-1, ap-северо-восток-1, ap-юго-восток-1.

Это помогает?

person Chris Gerlt    schedule 17.09.2015
comment
Я добавил строфу в наш файл opscenter/conf/clusters/local.conf и перезапустил opscenter, но это не помогло, и я получил то же сообщение об ошибке. - person LHWizard; 18.09.2015
comment
Я думаю, что эта информация неверна для 5.2. см. документы. Строфа [агенты] и нас-восток-1 не принимается. это должно быть стандартом США вместо этого Invalid S3 region specified: us-east-1. Valid options are: us-standard, us-west-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, sa-east-1 Это также не решило мою проблему. - person LHWizard; 18.09.2015
comment
Привет, это было что-то вроде выстрела в темноте. Нам-стандарт у вас сработал? - person Chris Gerlt; 18.09.2015
comment
default_api_timeout = 10 Попробуйте увеличить его до 60 (если работает, то уменьшите его, пока не получите стабильную длину соединения). - person Chris Gerlt; 18.09.2015
comment
Нет. Это тоже не сработало. Больше всего расстраивает то, что это работало с OpsCenter 5.1.3, но полностью сломалось при переходе на семейство 5.2.x. - person LHWizard; 18.09.2015
comment
После добавления default_api_timeout обязательно перезапустите процесс opscenterd. - person phact; 08.10.2015

arrow_upward
0
arrow_downward

Проблема решилась комбинацией двух вещей.

  1. Удалите все содержимое существующей корзины S3 (или создайте новую корзину, как ранее предложил @kaveh-nowroozi).
  2. Отредактируйте /etc/datastax-agent/datastax-agent-env.sh и увеличьте размер кучи до 512 МБ, как предложил инженер DataStax. По умолчанию было установлено значение 128 МБ, и я продолжал удваивать его до тех пор, пока резервное копирование не стало успешным.
person LHWizard    schedule 30.11.2015