Несколько вещей, которые я бы попробовал в этой ситуации: 1) Проверить сетевые порты на хосте.
# netstat -nap | grep 7199 | grep LISTEN
Вы либо захотите выполнить указанную выше команду в качестве владельца кассандры (при условии, что кассандра запустила процесс прослушивания на 7199), или как root (чтобы вы могли видеть все, что прослушивает порт 7199). Если вы вернете линии назад, вы сможете получить идентификатор процесса unix, который прослушивает порт 7199 (порт, который Cassandra использует для JMX по умолчанию). Проверьте, что cassandra - это процесс, прослушивающий этот порт с помощью:
# ps -ef | grep <pidFoundFromAboveCommand>
Если это cassandra (или dse, если используется datastax), то вы добились прогресса. Если нет, то Cassandra не работает или использует другой порт, который вам нужно будет указать при подключении.
Если Cassandra работает и прослушивает порт 7199, то это зависит от конфигурации вашего cassandra.yaml , в частности, ваш адрес_для прослушивания, native_transport_broadcast_address и native_transport_address, вам может потребоваться указать имя хоста. Как вы можете сказать, он пытается подключиться к 127.0.0.1. Возможно, вам придется указать хост в вашей команде nodetool (и, возможно, порт, если JMX_PORT отличается от 7199), чтобы заставить его работать.
Я не могу вспомнить комбинацию, но наша конфигурация имеет native_transport_address = 0.0.0.0, native_transport_broadcast_address = "hostIP" и listen_address = "hostIP". Эта комбинация позволит вам не указывать имя хоста из команды nodetool.
Последнее, что вы можете проверить, это то, не мешают ли брандмауэры подключиться к порту 7199. Как вы пытаетесь используйте 127.0.0.1, возможно, iptables (firewalld) блокирует этот порт, но в большинстве случаев это маловероятно.