Агент DataStax не может подключиться к DSE Opscenter 6

Я пытаюсь запустить однорегиональный кластер с несколькими узлами в DataStax OpsCenter 6.0 на Ec2, но когда я добавляю узел, он не запускается.

В задании установки узла я получаю сообщение об ошибке: не удалось запустить dse

У меня есть 3 узла на Ec2 в одном регионе, и у меня есть центр управления, работающий на 4-м сервере Ec2.

я новичок в cassandra и datastax, и после просмотра документации по datastax кажется, моя проблема связана с тем, что мой endpoint_snitch неверен.

Мой endpoint_snitch фактически установлен на GossipingPropertyFileSnitch, но OpsCenter не позволяет мне выбрать другой вариант, Ec2Snitch недоступен в вариантах endpoint_snitch.

Есть ли у вас какие-либо идеи о правильной конфигурации Datastax Opscenter 6.0 для правильной работы нескольких узлов на Ec2?

Изменить: кажется, что opscenter lcm работает правильно, но когда агент начинает работать на узле, я получаю сообщение об ошибке: /var/log/datastax-agent/agent.log

Невозможно подключиться через JMX, целевая cassandra, вероятно, недоступна или недостижима, проверьте работоспособность cassandra и настройки подключения jmx_host: 127.0.0.1 jmx_port: 7199 учетные данные jmx скрыты от регистрации


person Community    schedule 21.10.2016    source источник
comment
Вам следует избегать Ec2Snitch, он просто вызывает блокировку. Можно делать то же самое с GPFS, это то же самое, но дает вам возможность изменять/контролировать вещи в будущем.   -  person Chris Lohfink    schedule 21.10.2016


Ответы (2)


Похоже, вы используете функцию OpsCenter Lifecycle Manager для развертывания своего кластера. Я разработчик LCM. Трудно точно сказать, что происходит из вашего первоначального отчета... но некоторые общие мысли:

  1. Как сказал Крис Лофинк, не беспокойтесь о снитче. Нет необходимости использовать снитч EC2 в EC2. GPFS может делать все, что может EC2Snitch, и даже больше, поэтому LCM использует его.
  2. В настоящее время LCM не может защитить вас от недопустимых конфигураций DSE. OPSC-7414 — это внутренний номер тикета, который мы используем для отслеживания наших планов по улучшению предварительной проверки конфигураций DSE. Если у вас есть поддержка, свяжитесь с ними, чтобы добавить вашу компанию к этой проблеме, чтобы она быстрее стала приоритетной.
  3. В то же время, если вы используете сломанную конфигурацию DSE... DSE выдаст ошибку при запуске, и вам придется подключиться к узлу DSE по SSH и просмотреть там журналы DSE, чтобы выяснить, что пошло не так, это не всегда просто понять, но это единственный способ решить проблемы с запуском DSE.
  4. Если вы новичок в DSE, самое простое, что можно сделать, это начать с новых целевых блоков и нового профиля конфигурации и оставить конфигурацию по умолчанию для первоначальной установки. После того, как вы запустили свой кластер, вы можете выполнять дополнительные задания по настройке, чтобы изменить одну вещь за раз, а затем, когда вы столкнетесь с проблемой, у вас будет лучшее представление о том, какая настройка ее вызвала.
  5. Также поначалу делайте свою сеть как можно более простой. Это означает, что все ваши цели должны находиться в одной подсети вместе с OpsCenter в одном VPC в одном регионе. Отключите iptables на своих узлах перед запуском LCM. Настройте свою группу безопасности, чтобы разрешить весь трафик от всех членов этой подсети (но, вероятно, не из Интернета, хотя это немного усложняет ситуацию). После того, как у вас будет максимально простая и разрешительная настройка сети, вы можете расшириться до более сложных сетевых сред, будучи уверенными, что любые новые проблемы связаны с вашей сетевой конфигурацией.
  6. Путаница с различными IP-адресами в форме узла также может привести к сбою запуска DSE. Если вы используете очень простую настройку сети «все хосты в одной подсети», описанную ранее, используйте частный IP-адрес цели для адреса ssh-management-address и оставьте все остальные адреса пустыми.
person Mike Lococo    schedule 21.10.2016
comment
спасибо за совет, я попробую настроить сеть все хосты в одной подсети, чтобы проверить, работает ли это - person ; 24.10.2016
comment
поэтому я попробовал это, но dse все равно не запустился. Кажется, эта ошибка возникает при запуске агента dse (я пытаюсь запустить cassandra вручную, он работает, но когда я пытаюсь запустить агент, он останавливается, и я получаю эту ошибку): невозможно подключиться через JMX, целевая cassandra, вероятно, недоступна или недоступен, проверьте работоспособность cassandra и настройки подключения jmx_host: 127.0.0.1 jmx_port: 7199 учетные данные jmx скрыты от регистрации. - person ; 24.10.2016
comment
Я бы задал новый вопрос по этому поводу. Назовите это как DSE не запускается или агент DataStax не может подключиться к билету DSE, в зависимости от поведения, которое вы видите, и упомяните, что вы используете LCM в теле. Название/история этого вопроса заинтересует не тех людей, которые хотят решить ваш текущий вопрос. Включите все соответствующие ошибки/контекст из opscenterd.log на сервере opscenter, а также в целевом объекте DSE /var/log/datastax-agent/startup.log и agent.log и /var/log/cassandra system.log и выходные данные. журнал. - person Mike Lococo; 24.10.2016

Я решил свою проблему, но не нашел, почему не удалось запустить dse при запуске агента.

Я нашел способ запустить OpsCenter LCM и установить мой единственный регион кластера на ec2. После прочтения документации datastax по планированию ec2 я использовал ec2 AMI из доверенных источников вместо базового AMI Ubuntu.

person Community    schedule 25.10.2016
comment
Если вы поделитесь идентификатором AMI, который дал сбой, я мог бы найти проблему и исправить ее или улучшить обмен сообщениями об ошибках, чтобы в следующий раз это было более очевидно. - person Mike Lococo; 07.11.2016
comment
это был идентификатор AMI: ami-0d77397e, но я думаю, что это был тип экземпляра, которому не хватило памяти, он работает на t2small, но не быстро, и у меня несколько сбоев. - person ; 08.11.2016
comment
Я подозреваю, что вы правы насчет ограниченной памяти. Спасибо за продолжение. - person Mike Lococo; 10.11.2016