Если vminsert настроен для записи в два vmstorage. И у

нас две ситуации:
1. vmstorage - не доступен. Рероутинг всё равно произойдет, независимо от настроек disableRerouting, на живой vmstorage и есть шанс его сложить доп дублирующей нагрузкой.
2. vmsorage - очень медленно обрабатывает запросы,
disableRerouting=true -> vminsert будет писать медленно или не сможет по лимитам в оба vmstorage и мы получаем не рабочую всю систему.
disableRerouting=false -> данные полетят с медленного на другой vmsotrage и есть шанс сложить его дублирующей нагрузкой.

Правильно я понимаю?
Если да, то получается есть шанс получить отказоустойчивую систему лишь при схеме что один vminsert пишет лишь в один vmstorage.

Да, все рассуждения верны, кроме последнкго про отказоустойчивую систему. Если каждый vminsert будет писать в собственный vmstorage, то это приведет к следующим проблемам: - кластер будет плохо масштабироваться с добавлением новых vmstorage нод, т.к. на каждую vmstorage ноду будут записываться данные для всех рядов, если перед vminsert-нодами стоит обычный лоад-балансер. Т.е. на каждой vmstorage ноде будет часть данных со всех рядов. Это значит, что при увеличении количества активных рядов нужно будет увеличивать оперативную память в каждой vmstorage ноде, не зависимо от количества vmstorage нод в кластере. Этой проблемы нет, если vminsert пишет во все vmstorage ноды, т.к. при добавлении новых vmstorage нод активные ряды равномерно распределяются по всем vmstorage нодам. - если лоад-балансер отправляет запрос на vminsert, который пишет данные на недоступную vmstorage ноду, то возможны следущие варианты: 1) эти данные не попадут в vmstorage и, соответственно, не будут видны в результатах запросов до тех пор, пока vmstorage не станет доступной. 2) запрос "залипнет" на vminsert'e в ожидании возврата в строй связанного vmstorage; 3) запрос завершится с ошибкой и записываемы даннык могут быть утеряны, если клиент, отправляющий данные в кластер, не попытается переотправить их снова. Правильное решение для отказоустойчивого кластера - увеличить количество vmstorage нод и оставить на них достаточно свободных ресурсов, чтобы они могли справиться с врзросшей нагрузкой, когда заранее оговоренная часть vmstorage нод недоступна (например, одна vmstorage нода при rolling upgrade или пповедении профилактических работ). При этом желательно обеспечить задержку между возвратом в строй одной vmstorage ноды и остановкой следующей vmstorage нодой, чтобы кластер мог прийти в равновесное состояние. Пр этом, чем больше vmstorage нод в кластере, тем выше его отказоустойчивость при недоступности одной vmstorage ноды. Пара десятков vmstorage нод в кластере - самое оно :)

да, забыл момент что удобнее иметь полную копию данных на каждом vmstorage. И тогда получается что каждый vminsert пишет в каждый sotrage весь набор данных.

Такое решение не масштабируется с увеличением объема данных и активных рядов. Если для вас это норм, то, вероятно, лучше использовать несколько копий single-node вм. Это булет более эфыективно по потребляемым ресурсам cpu и ram

Мы же можем управлять это на этапе до vminsert при увеличении нагрузки. При увеличении нагрузки и на каждый shard данных тоже больше нагрузка и при рероутинга она будет примерно также себя вести же.

для таких кейсов, есть ли возможность, что если vminsert не может записать в какой-то storage, не афектить запись в другой?

если делать шардинг данных по рядам до записи их в vminsert, то эта схема может заработать. Но не совсем понятно, как вы решите существующие проблемы в такой схеме, т.к. сейчас шардинг осуществляется на стороне vminsert, а в вашей схеме он переносится на один уровень выше. Т.е. в итоге получается схема, аналогичная текущей, с такими же проблемами

сейчас так и должно работать - если vminsert не может записать данные в какой-то vmstorage, то возможны два варианта: * если этот vmstorage вообще недоступен со стороны vminsert, то запись в остальные vmstorage ноды не прекращается. Просто в них начинает записываться больше данных, которые предназначались для недоступного vmstorage. Это справедливо как для включенного, так и для выключенного рероутинга (-disableRerouting={false|true}) * если vmstorage медленно принимает данные по сравнению с другими vmstorage-нодами, то это может привести к замедлению записи в остальные vmstorage ноды, если реруотинг отключен (-disableRerouting=true), т.к. vminsert будет ждать, пока не получится отправить данные в самую медленную vmstorage ноду, перед отправкой данных в остальные ноды. Если же рероутинг включен (-disableRerouting=false), то vminsert будет перенаправлять данные, которые не успевает принять самый медленный vmstorage, на другие ноды. Таким образом, общая скорость записи в кластер не пострадает

получается что в любом случае недоступный сторадж афектит либо замедлением, либо нагрузкой. Хочется что если не доступен, то дропать данные, а не перенаправлять на другие стораджи.

я не вижу как они решатся и в вашей схеме, конечно если облако и сделать много мелких стораджей то шанс проблемы сильно уменьшится, но сложнее отслеживать что всегда есть точно несколько копий всех данных, либо делать большой оверхед по копиям данных.

интересный режим работы. Думаю, можно добавить опцию для включения его в vminsert, чтобы при недоступности и/или снижении скорости работы одной из vmstorage нод данные, предназначенные для нее, просто дропались вместо рероутинга на другие ноды. Можете создать фичереквест на https://github.com/VictoriaMetrics/VictoriaMetrics/issues , чтобы увеличить шансы на добавление этой фичи? Вроде выглядит несложной в реализации

да, хорошо. утром займусь, спасибо

Вам не нужно вручную отслеживать копии данных - про это заботится vminsert, если указать ему -replicationFactor больше единицы - см. https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#replication-and-data-safety