Случайный сбой при создании нового кластера Cassandra с помощью OpsCenter

Версия OpsCenter: 5.1.0 и версия DSE: 4.6.0

Создание нового кластера с использованием OpsCenter напрямую приводит к следующей ошибке. Он случайным образом работает с одними и теми же настройками, но в 95% случаев происходит сбой с той же ошибкой. Opscenter работает на своем собственном компьютере, но использует те же группы безопасности, что и экземпляры кластера. На всякий случай я открыл все TCP-порты для всех IP-адресов. Ниже приведена трассировка стека ошибки из opscenterd.log:

*2015-03-19 10:06:12+0000 [] ИНФОРМАЦИЯ: Начало процесса подготовки 2015-03-19 10:06:12+0000 [] ИНФОРМАЦИЯ: Начало этапа установки подготовки кластера

19.03.2015 10:06:13+0000 [] ПРЕДУПРЕЖДЕНИЕ: HTTP-запрос http://10.xxx:61621/alive? failed: соединение было отклонено другой стороной: 111: соединение отклонено.

2015-03-19 10:06:13+0000 [] ИНФОРМАЦИЯ: Начинается установка агента OpsCenter на 54.x.x.x

19.03.2015 10:06:26+0000 [] ПРЕДУПРЕЖДЕНИЕ: HTTP-запрос http://10.xxx:61621/alive? failed: соединение было отклонено другой стороной: 111: соединение отклонено.

2015-03-19 10:06:31+0000 [] ИНФОРМАЦИЯ: Агент для ip 10.xxx — версия Нет 2015-03-19 10:06:31+0000 [] ИНФОРМАЦИЯ: Агент для ip 10.xxx — версия u '5.1.0' 19-03-2015 10:07:23+0000 [] ИНФОРМАЦИЯ: Агент и dse успешно установлены на узле 10.xxx

2015-03-19 10:07:23+0000 [] ИНФОРМАЦИЯ: Начало фазы «остановки» подготовки кластера

2015-03-19 10:07:25+0000 [] ПРЕДУПРЕЖДЕНИЕ: запрос маркировки «10.xxx: /ops/stop» (f6708fa2-b45f-42b4-b992-90a82b460ac7) как неудавшийся: /usr/sbin/service dse stop не удалось

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

19.03.2015 10:07:25+0000 [] ОШИБКА: не удалось остановить узел 10.x.x.x: ошибка остановки /usr/sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ПРЕДУПРЕЖДЕНИЕ: пометка запроса «остановить этап» (0b6fcb6b-96ba-404e-a484-b4b6b167b309) как сбой: не удалось остановить узел 10.xxx: /usr/sbin/service остановка dse не удалась

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ОШИБКА: Ошибка остановки этапа: не удалось остановить узел 10.x.x.x: ошибка остановки /usr/sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ПРЕДУПРЕЖДЕНИЕ: запрос маркировки «предоставление» (daf1c15d-92e3-40b0-83ca-34d548ea835b) как неудавшийся: этап остановки не выполнен: не удалось остановить узел 10.xxx: /usr/ Ошибка остановки sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ОШИБКА: 2015-03-19 10:07:25+0000 [] ОШИБКА: Ошибка подготовки кластера: Исключение: Ошибка остановки этапа: Не удалось остановить узел 10.xxx: Ошибка остановки /usr/sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ОШИБКА: Не удалось подготовить кластер: Ошибка подготовки кластера: Исключение: Ошибка остановки этапа: Не удалось остановить узел 10.x.x.x: Ошибка остановки /usr/sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

2015-03-19 10:07:25+0000 [] ПРЕДУПРЕЖДЕНИЕ: запрос маркировки 28c021fd-d21a-4fed-bb5c-a4fe17d362e0 как сбой: не удалось выполнить инициализацию кластера: исключение: этап остановки не удалось: не удалось остановить узел 10.xxx: /usr Ошибка остановки /sbin/service dse

    exit status: 1
    stdout:
    log_daemon_msg is a shell function
    Cassandra 2.0 and later require Java 7 or later.

19.03.2015 10:07:41+0000 [] ПРЕДУПРЕЖДЕНИЕ: невозможно найти соответствующий кластер для узла с IP-адресом [u'fe80:0:0:0:2000:aff:feeb:31c7%2', u' 10.xxx', u'0:0:0:0:0:0:0:1%1', u'127.0.0.1']; сообщение было [u'5.1.0', u'/1947480708/conf']. Обычно это указывает на то, что агент OpsCenter все еще работает на старом узле, который был выведен из эксплуатации или является частью кластера, который OpsCenter больше не отслеживает.

Ценим любую помощь! Заранее спасибо Харша


datastax datastax-enterprise opscenter
person Harsha Sharma    schedule 19.03.2015    source источник
comment
Хотел бы добавить, что все это есть на Амазоне. Кроме того, я использую AMI по умолчанию, который предоставляет Opscenter. (ami id - 814ec2e8), поэтому ошибка о Java 7 и т. д. немного увеличивает путаницу, поскольку все это по умолчанию DSE с предустановленным программным обеспечением внутри.   -  person Harsha Sharma    schedule 19.03.2015
comment
Вы уверены, что используете AMI по умолчанию? 814ec2e8 — довольно старый (обновлен в 2013 году), а в OpsCenter 5.1 по умолчанию используется ami-6139e708.   -  person arre    schedule 20.03.2015
comment
ami-814ec2e8 Да, это ID. Я даже обновился до 5.1.1. Я добавляю новый кластер или узел показывает то же самое.   -  person Harsha Sharma    schedule 16.04.2015

Ответы (2)


arrow_upward
6
arrow_downward

Разработчик OpCenter здесь. Я делаю так, чтобы функции обеспечения OpsCenter увеличивались (или время от времени плескались, как вы видели). С грустью и стыдом я должен сказать вам, что вы наткнулись на ошибку.

Datastax AMI версии 2.4, используемый при подготовке OpsCenter (https://github.com/riptano/ComboAMI/tree/2.4) выполняет довольно много работы во время загрузки с помощью сценариев запуска. Одна из этих задач — настроить некоторые ключи репозитория gpg, используемые для проверки пакетов. Время от времени этот процесс может давать сбой, прерывая установку пакетов и приводя к ряду ошибок, которые вы видите. Этот сбой носит периодический характер и в последнее время значительно увеличился по частоте. Если вы проверите /home/ubuntu/datastax-ami/ami.log, вы должны увидеть сбои ключа gpg, которые начинают остальную часть цепочки сбоев.

К сожалению, эта ошибка находится довольно далеко в стеке технологий, и ее трудно обойти вручную. Если вам просто нужно подготовить один кластер, вы можете повторять попытку, пока не получите хороший результат. В противном случае вам лучше всего вручную запустить экземпляры и использовать локальную подготовку для развертывания dse/dsc на их частные IP-адреса:

  • Launch instances using ami-ada2b6c4 (assuming you're in us-east-1)
    • Make sure to add the instances to the OpsCenterSecurity group.
    • Убедитесь, что у вас есть частная половина пары ключей, которую вы используете (она понадобится вам во время локальной подготовки)
    • На странице данных экземпляра нажмите расширенное раскрывающееся меню и добавьте следующие пользовательские данные в виде текста "--raidonly --java7"
  • Выполните локальную подготовку для частного IP-адреса

Не супер-простой обходной путь. Я хочу, чтобы ваш опыт работы с OpsCenter на этот раз был более потрясающим. Хорошей новостью является то, что я нахожусь на этой ошибке, и она будет исправлена ​​в ближайшем релизе.

Изменить: больше нет необходимости вручную удалять файл /etc/security/limits.d/cassandra.conf.

person Mike Lococo    schedule 20.03.2015
comment
Привет Майк. Отличная работа с инструментом Opscenter, и спасибо за ваш ответ. Исправлена ​​ли эта ошибка в Opscenter 5.1.1? Я хотел бы иметь возможность использовать Opscenter для простой подготовки кластеров. Я пробовал пару раз с 5.1.1, и это больше не выдавало мне эту ошибку. Также в качестве запроса функции, пожалуйста, предоставьте opscenter возможность создания узлов и кластеров cassandra в VPC на Amazon. - person Harsha Sharma; 16.04.2015
comment
Исправление не было отправлено, и когда оно выйдет, это будет не релиз, а автоматически загружаемый файл конфигурации. Я свяжусь с вами, когда получу его, у нас есть хороший вклад сообщества в ComboAMI, который я хочу внести, прежде чем мы испечем новый AMI. Что касается VPC, я не могу говорить о возможных будущих функциях, но мы знаем, что люди этого хотят, поэтому следите за журналами изменений. - person Mike Lococo; 27.04.2015
comment
Локальный метод подготовки вызывает те же проблемы. ОШИБКА [Инициализация] Ошибка подключения через JMX: java.io.IOException: не удалось получить заглушку RMIServer javax.naming.ServiceUnavailableException [Корневое исключение — java.rmi.ConnectException: Отказано в подключении к хосту: 127.0.0.1; вложенным исключением является java.net.ConnectException: Отказ в подключении] ИНФОРМАЦИЯ [основной] Создание подключения к 172.31.19.2:61620 ИНФОРМАЦИЯ [приемник StompConnection] Повторное подключение в 0s ИНФОРМАЦИЯ [Инициализация] Запуск сервера Jetty: {:join? ложь, :ssl? false, :host nil, :port 61621} - person Harsha Sharma; 03.09.2015
comment
К сожалению, исправление AMI для OpsCenter 5.x так и не было выпущено. Однако OpsCenter 6.0 уже вышел и включает обновленную функцию подготовки под названием LCM. LCM больше не привязан к конкретному AMI... вы можете установить его в любой поддерживаемой операционной системе (Red Hat, Ubuntu и т. д.), запустив целевые экземпляры с любым общедоступным AMI. - person Mike Lococo; 05.07.2016

arrow_upward
0
arrow_downward

если он просто жалуется на java, тогда установите java 7, желательно, чтобы datastax хотел oracle jdk и jre. возможно, у вас уже есть java 7 и другая версия на ваших узлах, но java 7 не является версией по умолчанию. чтобы изменить это:

sudo update-java-alternatives -s java-7-oracle

это команда, которую вы можете запустить с помощью ssh, поэтому вам не нужно входить в каждый узел

person dtrihinas    schedule 19.03.2015
comment
Спасибо за ваш быстрый ответ. Это странная часть, ami, который я использую для запуска кластера cassandra, по умолчанию предоставляется OpsCenter ... что похоже на своего рода устройство. Подключи и играй. aws.amazon.com/amis/datastax-auto-clustering- ami-2-2 Вся цель будет провалена, если мне придется вручную вмешиваться в запуск узлов с помощью OpsCenter. Но позвольте мне попробовать ваше предложение и вернуться сюда .. Еще раз спасибо. - person Harsha Sharma; 19.03.2015
comment
на самом деле, если это готовый ami, и у вас также возникают проблемы с отказом в подключении, вы можете проверить группу безопасности, которую вы назначаете своим экземплярам, ​​чтобы были доступны правила портов для требуемых портов от cassandra. - person dtrihinas; 19.03.2015
comment
В моей группе безопасности все порты TCP открыты для 0.0.0.0/0. И Opscenter, и узлы cassandra принадлежат к одной и той же группе безопасности, поэтому они должны иметь возможность общаться друг с другом без проблем. Я также могу подключиться по телнету к этому порту 61621 от Opscenter до узла Cassandra, т.е. - person Harsha Sharma; 19.03.2015