2015-03-04 6 views
0

Я недавно «унаследовал» установку Carbon/Graphite от коллеги, которую я должен перепроектировать. Текущие настройки:Репликация углеродного реле через датацентры

  • центра обработки данных 1 (DC1): 2 сервера (сервера DC1-1 и сервер-DC1-2) с 1 углерод-реле и 4 углеродных кэшей
  • центра обработки данных 2 (DC2): 2 сервера (сервера DC2-1 и сервер-DC2-2) с 1 углерод-реле и 4 углеродных кэшей

Все 4 углеродных-реле сконфигурированы с REPLICATION_FACTOR 2, последовательного хеширования и все углерода -caches (2 (DC)) * 2 (серверы) * 4 (кеши)). Это привело к тому, что некоторые показатели существуют только на 1 сервере (они, вероятно, были хэшированы в другом кэше на том же сервере). Имея более 1 миллиона показателей, эта проблема затрагивает около 8% всех показателей.

Что я хотел бы сделать, это многоуровневая настройка с резервированием, чтобы отразить все показатели в центрах обработки данных и внутри центра обработки данных. Я использую согласованное хеширование для равномерного распределения показателей на двух серверах.

Для этого мне нужна помощь в конфигурации (главным образом) реле. Вот картина того, что я имею в виду:

http://i.imgur.com/dtjGlhn.png (извините за ссылку, я не позволил вставлять изображения, так как я не хватает репутации)

клиенты будут отправлять свои данные tier1relay s в их соответствующих центрах обработки данных («loadbalancing» будет происходить на стороне клиента, так что, например, все клиенты с четным номером в имени хоста отправили бы tier1relay-DC1-1 и клиенты с нечетным номером отправили бы до tier1relay-DC1-2).

tier2relay s использовать согласованное хеширование для равномерного распределения данных в центре обработки данных через 2 сервера. Например, конфигурация "псевдо" для tier2relay-DC1-1 будет выглядеть следующим образом:

  • RELAY_METHOD = самосогласованного хэширования
  • НАЗНАЧЕНИЯ = сервер-DC1-1: кэш-DC1-1-а, сервер-DC1-1: кэш-DC1-1-б, (...), сервер-DC1-2: кэш-DC1-2-d

То, что я хотел бы знать: как я скажу tier1relay-DC1-1 и tier1relay-DC1-2, что они должны направить все показатели в tier2relay с в DC1 и DC2 (повторить метрики через ГЦ) и сделать своего рода «балансировочных» между tier2relay-DC1-1 и tier2relay-DC1-2.


На другой ноте: Я также хотел бы знать, что происходит внутри углеродного реле, если я использую последовательное хэширование, но один или несколько направлений недостижимы (сервер вниз) - сделать метрики получить хэшируются снова (против достижимых кешей), или они просто будут отброшены на время?(Или задать тот же вопрос под другим углом: когда реле получает метрическое это делает хеширование метрики на основе списка всех настроенных маршрутов или на основе имеющегося в настоящее время направления?)

ответ

0

https://github.com/grobian/carbon-c-relay

Что именно делает то, что вам нужно. Кроме того, это дает вам большое повышение производительности.

+0

Спасибо! Тем временем мы полностью пересмотрели дизайн и немного упростили его. Теперь у нас есть рабочий кластер с ядром tier1-carbon-c-relay, который реплицируется на 2 датацентра, а внутри датацентра использует fnv1a_ch для распределения метрики на tier2-carbon-c-реле. Реле tier2-carbon-c знают только локальные кеши (на сервере) и используют carbon_ch. –

Смежные вопросы