Предлагаемая функция — Управляемое завершение работы.

Предлагаемая функция — Управляемое завершение работы., wifiman

bfdulock

Guest

05.03.2025 03:22:00

Поскольку шлюз UniFi может принимать и управлять другими устройствами UniFi, было бы здорово добавить возможность конфигурировать и запускать управляемое выключение указанных устройств UniFi. Кроме того, хотелось бы иметь возможность автоматически запускать управляемое выключение (возможно, через новый PDU UniFi, который может отслеживать уровень заряда одной или нескольких батарей ИБП).

ПОДРОБНОСТИ УПРАВЛЯЕМОГО ВЫКЛЮЧЕНИЯ

Моя идея заключается в том, что шлюз можно было бы настроить с одной или несколькими процедурами выключения. Процедура должна указывать, какие устройства UniFi следует выключить, в каком порядке устройства должны выключиться и какой задержка должна быть между выключением каждого устройства. Процедура может иметь расписание (например, в преддверии запланированного отключения электропитания) для выключения, а также расписание для включения (которое может происходить в обратном порядке выключения). Наконец, процедуру можно было бы запустить вручную из Dashboard или с LCD-дисплея шлюза.

P.S. Какая-то форма управления вне полосы обзора для шлюзов UniFi была бы отличной особенностью.

tgl123

Guest

05.03.2025 03:35:00

Эм, зачем? Какой смысл во всём этом? Я думаю, общий подход UniFi в этом плане таков, что устройства должны выдерживать внезапное отключение питания, и поэтому нет особой необходимости выключать их каким-то более изящным способом. Они, пожалуй, не единственные производители, которые так думают; например, у моих Cisco-коммутаторов пока что я не нашёл команды для корректного выключения.

tgl123

Guest

05.03.2025 07:59:00

Это имеет смысл для них, просто чтобы они могли продавать версии CK+ без HDD. Что касается безопасности при аварийном сбросе, то главное требование — чтобы устройство не вводило вас в заблуждение относительно того, завершена ли запись блока данных в устойчивую память. HDD ничем не лучше и ничем не хуже, чем SSD в этом плане. Реальная проблема в том, что у производителей появляется стимул врать, чтобы их показатели производительности выглядели лучше. Всё сводится к тому, чтобы доверять (... но проверять ...) то, что устройство честно сообщает о завершении записи. Я бы никогда не рискнул хранить критические данные на дешёвых, неизвестных устройствах. Есть ещё один слой доверия и стимулов для обмана на уровне файловой системы ОС. Но когда Ubiquiti создаёт UCK или любое другое устройство контроллера, у них полный контроль над всем стеком хранения, поэтому если они не производят надёжное устройство, это их собственная вина. (Следует отметить, что если вы запускаете UNA на собственном оборудовании, безопасность данных конфигурации — ваша ответственность, а не Ubiquiti.)

tgl123

Guest

05.03.2025 05:08:00

Шлюзы (роутеры) как таковые — это как точки доступа или коммутаторы: вся их конфигурация хранится в сетевом контроллере, так что в худшем случае контроллеру придётся перепрошить их заново после какого-нибудь сбоя. Вот что действительно нужно учитывать: контроллер, который должен сохранять своё состояние при отключении питания. ИМХО, UniFi раньше у них была такая проблема, но пару лет назад они это исправили в своём ПО. Вот почему, например, Cloud Key G2 раньше имели батарейки, а в текущих версиях их уже нет. Батарейки нужны были, чтобы было время для нормального завершения работы после отключения питания, но теперь считают, что это не нужно. (Я как профессиональный разработчик баз данных отлично знаю, что требуется для поддержки требования сохранения данных после отключения питания. Это вполне реализуемо, если в это вкладывать усилия, и Ubiquiti это сделали. Ну, по крайней мере, раз они убрали эти батарейки, то они должны были это сделать правильно.)

bfdulock Guest	#5 05.03.2025 04:38:00 Ты уверен, что они выдержат внезапное отключение – особенно шлюзовые устройства? Мне казалось, я видел посты других, которым после неожиданного отключения приходилось перезагружать устройство.

Читают тему (гостей: 1)