Блог

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

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

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

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

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

Есть ли у вас какие-либо идеи о правильной конфигурации 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, удерживаемые при регистрации.

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

1. Как сказал Крис Лофинк, не беспокойтесь о стукаче. Нет необходимости использовать EC2 snitch в EC2. GPFS может делать все, что может Ec2Snitch, и даже больше, поэтому LCM использует его.
2. В настоящее время LCM не может защитить вас от недопустимых конфигураций DSE. OPSC-7414 — это внутренний номер заявки, который мы используем для отслеживания наших планов по улучшению предварительной проверки конфигураций DSE. Если у вас есть служба поддержки, свяжитесь с ними, чтобы ваша компания была добавлена к этой проблеме, чтобы она быстрее получила приоритет.
3. В то же время, если вы используете неработающую конфигурацию DSE… DSE выдает ошибку при запуске, и вам придется подключиться по SSH к узлу DSE и просмотреть там журналы DSE, чтобы выяснить, что пошло не так, это не всегда просто понять, но это единственный способ устранить проблемы при запуске DSE.
4. Если вы новичок в DSE, самое простое, что можно сделать, это начать с новых целевых полей и нового профиля конфигурации и оставить конфигурацию по умолчанию, насколько это возможно, для первоначальной установки. Запустив свой кластер, вы можете выполнить дополнительные задания настройки, чтобы изменять что-то одно за раз, а затем, когда вы столкнетесь с проблемой, у вас будет лучшее представление о том, какие настройки ее вызвали.
5. Кроме того, вначале ваша сеть должна быть как можно более простой. Это означает, что все ваши цели находятся в одной подсети вместе с OpsCenter на одном VPC в одном регионе. Отключите iptables на своих узлах перед запуском LCM. Настройте свою группу безопасности так, чтобы разрешать весь трафик от всех членов этой подсети (но, вероятно, не из Интернета, хотя это немного усложняет ситуацию). Как только у вас заработает максимально простая и разрешительная настройка сети, вы сможете перейти к более сложным сетевым средам, будучи уверенным, что любые новые проблемы связаны с вашей конфигурацией сети.
6. Перепутывание различных IP-адресов в форме узла также может привести к сбою запуска DSE. Если вы используете очень простую настройку сети «все хосты в одной подсети», которую я описал ранее, используйте частный IP-адрес цели в качестве адреса ssh-management-address и оставьте все остальные адреса пустыми.

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

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