Это действительно только проблема с Cloud Key? У меня сложилось впечатление, что если система, на которой работает контроллер, выходит из строя, MongoDB вполне может зависнуть. Такое может случиться на debian, windows, cloud key и так далее. Это не так?

Привет, @Rockelstad, добро пожаловать в сообщество! Загляни на UCK G2 😉 С уважением, Гленн Р.

@dmveoci

Если включить журналирование MongoDB, то SD-карта на Raspberry быстро выйдет из строя. Конечно, можно подключить внешний USB-диск. Если поискать на форумах, там полно тем на эту тему. Как насчёт запустить контроллер в облачном сервисе? Я не рекламирую Google, но у них есть бесплатный микро-инстанс, и на нём можно запустить UniFi-контроллер. Я написал готовый скрипт для установки со всеми нужными штуками, которые знаю. Если есть десять минут, посмотрите видео в моей статье: https://metis.fi/en/2018/02/unifi-on-gcp/ Конечно, всегда можно вернуться к Cloud Key или Raspberry, если захотите.

Я значительно сузил круг проблемы. У меня есть 5 cloud key, которые я настроил и протестировал, используя актуальную на 02.02.18 прошивку.

Я настроил все 5 cloud key и не выключал их через портал, а просто отключал питание. При этом 2 из 5 не запускались снова. Если я сканировал сеть, то мог найти все устройства, кроме тех двух, которые не отображались в портале и мигали белым светодиодом. Я попытался зайти на них по IP-адресу, чтобы открыть GUI. В интерфейсе увидел, что Unifi-сервер не запущен, но нажатие кнопки «Start Unifi» не дало результата.

Если же перейти на вкладку REBOOT в разделе обслуживания, можно было успешно перезагрузить cloud key, и после этого не требовалось никаких дополнительных действий. Мне не пришлось делать сброс к заводским настройкам или восстанавливать из резервной копии, как вежливый человек в чате советовал сделать дважды на другом объекте (тогда был плохой день).

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

Похоже, что проблема в том, что cloud key некорректно выключается, то есть не происходит полноценное выключение, управляемое пользователем. Для меня это ОГРОМНАЯ проблема, так как я никак не могу контролировать питание на объектах клиентов, и если я теряю связь с ключом, мне приходится ехать туда… что занимает до 3 часов в одну сторону.

Ubiquiti… пожалуйста, разберитесь и исправьте это, так как я уверен, что проблема именно в cloud key в целом. Весь смысл cloud key ставится под вопрос, если он не выдерживает простое отключение питания.

Есть ли реальные причины не включать журналирование на Cloud Key? Ubiquiti по умолчанию отключает журналирование, и я понимаю, что это связано с дополнительным износом SD-карты, но насколько сильным? Есть ли ещё какие-то причины, по которым журналирование отключено? С уважением, Anthony

@gonesilent

Это просто ещё один вариант, из которых тебе придётся выбирать. Советую снять шапочку из фольги и вместо этого подтолкнуть команду UBNT поучаствовать в этом разговоре. Боюсь, что эта ветка никуда не приведёт, прощай.

@StrangerDanger  
Мы с этим не согласимся.

@matuscak  
Действительно, проблемы, вызванные перебоями с питанием, характерны не только для CK. Плохие Micro-SD карты тоже могут создавать проблемы, но это уже не ответственность UBNT. Однако если кто-то управляет корпоративной сетью, я бы ожидал, что он обеспечит какую-то (электропитательную) устойчивость для всех критически важных компонентов. И я бы не советовал использовать для управления сервер на PoE или USB питании. Мне CK нравится, но он не подходит для всех случаев. Я решил доверить это своему облачному провайдеру, используя его снимки и прочее. Кроме того, я сам регулярно делаю резервные копии контроллера и храню их "вне офиса". Всё это можно организовать довольно бюджетно по сравнению с решениями других производителей.

@StrangerDanger

Хотя я и согласен с тем, что CK должен быть более устойчивым, нигде конкретно не говорится, что Cloud Key предназначен для сетей корпоративного уровня. Конечно, можно долго спорить, что именно считать корпоративным уровнем... Вариантов полно, но среди них Cloud Key не рассчитан на крупные сети (сотрудники UBNT часто рекомендуют использовать его для менее чем 20 устройств) или там, где важна высокая доступность. Если вы управляете корпоративными сетями (по моей личной дефиниции), крайне важно иметь платформу управления с высокой доступностью, и задача тех, кто управляет сетью, — настроить это должным образом. Раньше, когда я продавал решения по управлению сетями корпоративным и провайдерским клиентам, такие системы часто разворачивались на кластерах с высокой отказоустойчивостью. Это, конечно, не тот же уровень, что UniFi-контроллер, по крайней мере в плане стоимости, но вы поняли, о чём я.

Запись лога не должна приводить к тому, что устройство перестаёт загружаться, независимо от того, насколько оно загружено. Если это известная проблема, то при загрузке должен запускаться скрипт очистки базы данных, чтобы избежать таких ситуаций. Мы же говорим о маленьком IoT-устройстве, а не о какой-то навороченной SQL-базе, обслуживающей сотни клиентов (кстати, она прекрасно восстанавливается после отключения электроэнергии). Надеюсь, по мере развития устройства надёжность будет только расти. С уважением, Plasma