они не должны упасть, там захардкожен предохранитель, если останется около 500МБ в выделении или на диске - узел уведомит сателлиты, что он полный и будет отклонять попытки загрузить на него что-то.
Однако то, что у вас данные в БД разошлись с данными с диска - не здорово. Видимо used-space-filewalker у вас занимает неприлично долгое время. Я бы рекомендовал отключить lazy mode и ни в коем случае не отключать used-space-filewalker на старте. Если есть возможность - добавьте SSD as a special device, другие пользователи zfs утверждают, что это решает все проблемы.
Вызов
не поможет, нам надо знать сколько осталось в выделении, а не на диске. Хотя последнее тоже проверяется (на старте, чтобы выбрать минимальное из выделения и сколько есть на самом деле; и потом, при каждой загрузке, чтобы понять пора дёргать стоп-кран или ещё нет).
И да, узел использует СИ (десятичные единицы измерения), а вы запрашиваете бинарные.
Запросите так:
Что имеет ввиду @andylevi16, так это то, что мы рекомендуем оставлять 10% свободного места, то есть не выделять всё под крышечку. Если мы вдруг выпустим версию с багом - узел может теоретически скушать всё настолько, что ему в базу запись добавить не удастся (и он её с вероятностью 99% убъёт постоянными попытками), и после этого узел даже запустить не получится.
Но не будем о кошмарах. Желательно иметь свободное место на диске на непредвиденный случай, резко освободить его будет тяжело, даже удаление trash может привести к дисквалификации, если сателлит запросит восстановить оттуда данные и попробует их проверить.
Возможно 10% это много, особенно для больших узлов. Но иметь свободными хотя бы 200ГБ я бы порекомендовал (видел на одном из своих узлов overusage 100GB…).
Не могли бы вы эти факты предоставить? Предохранитель был сделан давно
Пока что это работает для всех тысяч узлов, кроме почему-то вашего. Это нужно исследовать. Если мы допустили баг здесь, его необходимо срочно исправить.
Опишите подробно, как вы добились, чтобы узел использовал диск без остатка?
Оно не задаётся, оно вычисляется: сколько осталось места в выделении (выделенное минус использованное по данным узла).
Мы рекомендуем оставлять 10% от полной вместимости, однако если вы любите риск, вы можете выделить почти всё, но я бы рекомендовал оставлять свободными хотя бы 100ГБ-200ГБ.
Аварийный уровень захардкожен на 500МБ (см. заметки о выпуске выше) и проверяется при каждой попытке загрузить кусочек на ваш узел.
Это может не сработать, если вы растащили папку storage по дискам/папкам симлинками или с помощью mount в docker.
Но для надёжности мы рекомендуем выделять место для узла на 10% меньше полной вместимости диска.
В каком виде предоставить? Смысл в том, что если несколько нод шарят дисковое пространство, то видимо нода не успевает включить этот киллсвитч. Плюс у меня есть тестовая нода, которая на отдельной железке с аппаратным рейдом на ZeusIOPS, так на ней я периодически наблюдаю, что свободное дисковое пространство опускается до 400-450 Мб. Вот кстати ситуация прямо сейчас на 12RYDKnKqrByfHDrx3ACxe3w1THnJ8txN765qTWeYFdFV5YqSBu:
Ну как мы видим по какой-то причине это не срабатывает (мне кажется, из-за того, что одновременно несколько аплоадов работает, например при кейсе 10 клиентов загружают чанки по 64мб, тогда киллсвитч тупо не успеет отработать) + хотелось бы иметь отдельную настройку, вместо хардкода. Это полезно для кейсов, где несколько нод или другого софта шарят одно дисковое пространство (большие ZFS пулы например как у меня, или ваш любимый концепт реюза свободного места с инфраструктуры которую уже использует другой сервис)
Именно это запрещено делать по условиям Node Operator Terms & Conditions
Вы решили нарушить - получайте предсказуемый результат. Правила обычно написаны “кровью”.
Вы не должны запускать более одного узла на диск (пул - это один диск для системы).
Это просто бессмысленно, все узлы в одной подсети /24 получат тот же объём трафика, что и один узел. Запускать несколько имеет смысл в таком случае только чтобы как раз не возиться с RAID. У вас будет один узел на один диск. Умрёт диск, вы потеряете только 1/х общих данных вашей подсети. Это намного лучше, чем потерять всё из-за RAID failure.
Да, zfs RAIDZ убить сложнее, но возможно.
Допустим, но тогда объясните что не так с киллсвитчем на 12RYDKnKqrByfHDrx3ACxe3w1THnJ8txN765qTWeYFdFV5YqSBu =)
Я за вас отвечу, он не успевает отработать. Плюс повторюсь, кейс с использованием диска другим сервисом кроме стораджа, который тоже пишет на диск. Именно для этого нужна крутилка для настройки киллсвитча.
UPD: решение с киллсвитчем на 500мб скорее всего не плохо работало, когда было мало трафика в сети, сейчас вангую к вам прибижит много людей с такой-же проблемой, даже те у кого выделенный диск под сторадж. Т.к. по умолчанию нода принимает 25 коннектов, следовательно киллсвитч даже если не настраивается должен высчитываться динамически на основе данных из конфига по количеству коннектов * на максимальный размер чанка, который может приехать. Но если бы я был менеджером продукта, я бы сделал по умолчанию динамический киллсвитч, который можно перенастроить через конфиг ноды.
UPD2:
Ну это один из кейсов. А если например у меня ZFS + SAN и пачка серверов? В ToS есть где-то требования к организации хранилища, может быть там написано что диск должен быть один физически и обязательно подключен интерфейсом SATA напрямую в ноду?
UPD3: Кстати покажите конкретный пункт ToS запрещающий мне запускать более одного узла на одном диске, я что-то не нашел. Не то, что бы это был мой кейс, просто интересно.
UPD4: Отлично вы захрадкодили минимальное место ноды на стороне спутника
По идее - он должен отрабатывать, актуальное свободное место в выделении/на диске запрашивается каждый раз, когда запрашивается загрузка кусочка (вы это можете видеть в логах).
Вот если ваша дисковая подсистема немного лукавит - тогда такое возможно. Я бы порекомендовал покопать в эту сторону (никто больше не репортил такую проблему). И я даже не очень представляю, как это воспроизвести.
нет конечно. Мы не хотим ограничивать пользователей какой-то технологией. Просто требование, чтобы один узел - как минимум один диск (заметьте - не наоборот).
4.1.4.1. Have a minimum of one (1) hard drive and one (1) processor core dedicated to each Storage Node;
Как обычно - pull requests are welcome!
Особенно если у вас есть вариант, как это сделать правильно, это поможет многим Операторам!
Сейчас изменения в storagenode имеют низкий приоритет, но участие Сообщества это кардинально меняет.
Не надо сваливать на дисковую подсистему повторюсь это RAID5 на ZeusIOPS дисках, однако это вообще никак не влияет, т.к. у вас тут решение дефектив бай дезижн, т.к. при текущей реализации когда оставшееся место форс репорта равно минимальному месту которое определяется на спутнике, у вас всегда будет лаг в несколько чанков с КАЖДОГО спутника. И хорошо, если они маленькие.
Это можно в любую сторону трактовать.
Во первых мне за это не платят, во вторых это нарушает ваш ToS
4.1.3. You will not modify or attempt to modify the Storage Node Software for any purpose including but not limited to attempting to circumvent the audit, bypass security, manipulate the performance of, or otherwise disrupt the Storage Services for any reason, including but not limited to attempting to increase the amount of data stored or bandwidth utilized or the amount of Storage Node Fees, as defined herein, and you will not otherwise interfere with the operation of the Storage Services.
Кстати забавно, с учетом того, что вокруг storagenode построен вообще весь проект.
Да, не платят, это Open source проект. И каким же образом это нарушает ToS?! (Не нарушает, проверено всеми бюрократами, кроме российских).
Вообще-то, вокруг клиентов. Партнёры тоже важны, но они читали ToS и приняли его. Если кто-то не читал, ну, наверное, время пришло, и надо прочитать. Принять или идти искать что-то лучше, если оно существует.
А вы путаете OpenSource и закрытые системы. Этот проект - OpenSource. Практически полностью (кроме имплементаци платежей… но вы тут сами разберётесь, верно?).
Код узла исправить можно, но присоединять его после к публичной Storj - нет. Понимаете разницу?
