Раздел storage_cassandra файла cluster_name.conf, в частности seed_hosts, local_dc_pref и used_hosts_per_remote_d c, управляет подключением opscenterd к кластеру хранения. Документированное поведение корректно в том, что касается самого процесса opscenterd. Однако поведение агентов отличается.
Opscenterd передает значение storage_cassandra seed_hosts агентам соответствующего кластера, и именно это каждый агент будет использовать для начальных точек контакта, если он не переопределен хостами . установка в локальном адресе агента. Yaml. Настройки local_dc_pref и used_hosts_per_remote_d c не передаются агенту и не влияют на его поведение.
Агент использует defaultLoadBalancingPolicy драйвера Java по умолчанию DCAwareRoundRobinPolicy с поддержкой токенов. Локальный D C явно не передается драйверу, поэтому он будет считать локальный D C D C первого хоста, к которому он успешно подключился. Это означает, что каждый агент будет подключаться к одному D C кластера хранения или другому.
TL; DR: агент подключит только к локальному D C первого действующего узла, с которым агент смог связаться. Невозможно подключить один агент к нескольким DC. К какому узлу агент пытается подключиться, определяется с помощью storage_cassandra seed_hosts, настроенного в cluster_name.conf, или, если он указан, хостов, настроенных в локальном адресе агента. Yaml. Поэтому, если вы хотите, чтобы некоторые агенты подключались к одному D C кластера хранения, а другие агенты подключались к другому D C хранилища, вам потребуется переопределить хосты в address.yaml агента и убедиться, что первые указанные хосты принадлежат D C, к которому вы хотите подключить этот агент.
Обратите внимание, что если используется отдельный кластер хранения , а не , агент подключается только к локальному узлу что это мониторинг.