Комментарии 13
По поводу виртуальных машин. Почему вы решили использовать виртуальные машины, а не отдельные инстансы clickhouse (или даже контейнеры) со своим IP-адресом? В общем случае миграция инстанса виртуалки (с данными) и миграция каталога с данными между двумя серверами практически одно и то же, но меньше слоёв операционных систем.
Мы хотели использовать отдельные инстансы ClickHouse, но на тот момент у нас в наличии не было необходимого количества серверов и мы смогли бы реализовать только круговую репликацию, что нас не устраивало. В обозримом будущем мы планируем переехать на отдельные инстансы ClickHouse. Из-за этого ограничения мы как раз и пытались уместить все на существующем железе.
Контейнеры не рассматривали изначально, для подготовки стабильного решения с их использованием, потребовалась бы дополнительное время на аналитику, к сожалению которого у нас не было. Мы уперлись в ограничения прошлой инсталляции кластера и нужно было быстрее переезжать в новый.
Он имел в виду запустить два Кликхауса на одной ОС с разными конфигами, IP и данными в разных директориях. В данном случае не нужно рулить дополнительной ОС и платить цену виртуализации.
Также использование памяти будет более гибким если вдруг один инстанс получит тяжелый запрос. В случае ВМ он будет ограничен только тем что ей выделили...
Да, не так понял вопрос…
Такой вариант не рассматривался. Это связано с нашей организацией работы с конфигурацией виртуалок. Для поддержки такого вида инсталляции нужно было переделать ansible-роль, и поддерживать ее отдельно. Это привело бы к отличиям этой инсталляции от других, а работать с ней может коллега из другой команды.
Виртуализация сейчас не доставляет проблем, это компромиссное и промежуточное решение, в перспективе пары лет, думаю, мы уйдем от нее.
По памяти у нас стоят ограничения в самом ClickHouse, как дополнительный этап отлова не оптимальных запросов на раннем этапе.
в моих тестах с 2tb пожатых данных виртуализация давала +20% скорости итогового просчета, найти секрет такого непонятного тюнинга я не смог в короткое время
Для понимания упираюсь только в процессор, диски m2 в простое
Одним из больших минусов что дефолтной круговой, что вашей, схемы я вижу кросс влияние шардов друг на друга — запись на шард 2 тормозит чтение на шарде 1. А учитывая то, что клик считает (и это в плане дизайна вполне разумно) что он на машине один и все ресурсы его — на hdd я бы такое точно не стал делать, а на ssd не чувствуете эффекта конкуренции между шардами?
1.2 Tб сырых данных, на одну ноду/шард приходится ~4Тб SSD.
Храним по-разному, есть потоки данных которые хранятся постоянно и данные просто дописываются, есть с ограниченным временем жизни от пары недель и больше. Пока соблюдается баланс по тому за какой период могут быть нужны данные, но это тоже все обсуждаемо и изменяемо, появится потребность хранить дольше, начнем хранить дольше. Для каких-то данных используется репликация, есть данные, где она не нужна. В этом кстати есть своя сложность и гибкость одновременно, кластер можно настроить именно так как нам нужно, но для этого нужно потратить какое-то время на изучение документации.
Про размещение на HDD я с Вами полностью согласен. Прошлая инсталляция как раз и жила на HDD с SSD кешем и там были замечены странности и влияние на другие виртуалки. Пришлось добавлять лимиты по IOps, что конечно сыграло не в лучшую сторону для ClickHouse. С SSD были опасения, что можем упереться, но пошли на этот шаг, на данный момент эффекта не заметили. У нас есть понимание как можно расширить кластер, увеличить ему ресурсов и в дальнейшем переехать на отдельные инстансы. Скорее сейчас ловим какие-то другие проблемы из-за увеличения объема данных и количества запросов, но вот в SSD пока не упираемся.
То есть в принципе вы сейчас пришли к тому, что альтинити кликхауз оператор дает из коробки :)
Хотел спросить, зачем сделано по несколько виртуалок, но понял, что @blind_oracleуже указал на альтернативный способ управления, который кажется более приемлимым, когда несколько инстансов CH запущено с разными --config. Так действительно выглядит более гибко, если один из шардов случайно начал перевешивать по нагрузке.
/*offtopic*/ Когда зашёл прокомментировать, а тут уже все знакомые лица...
Хочу поинтересоваться, возможно что-то не допонимаю. А RAID1 на нодах не решал вопрос сохранности и быстрого восстановления в случае выхода ноды из строя?
Репликация ClickHouse без костылей: ожидание и реальность