В эти выходные я выяснил, что мой NAS (Synology DS 411+II) поддерживает Docker, с помощью которого можно запустить Unifi Controller в контейнере. Так что, думаю, буду использовать это решение

@smawuascht

- Случайная потеря питания на CK – это то, чего я, к счастью, избегал, но из прочитанных тем я понял, что потеря питания приводит к повреждению CK, а не к его "закирпичиванию". В худшем случае, можно сбросить CK к заводским настройкам и восстановить из файла резервной копии, если у тебя он есть. С помощью UniFi контроллера можно вручную создавать резервную копию в любое время и скачивать ее куда угодно. Я делаю это каждый раз, когда вношу изменения в конфигурацию, что случается не очень часто. Я веду журнал того, когда что-то ковыряю в сети, и это дает мне резервную копию, на которую можно ссылаться в этом журнале, если потребуется восстановить ее. Контроллер также можно настроить для автоматического создания файла резервной копии, который сохраняется определенным образом. У меня настроено создание резервной копии каждую неделю и сохранение семи файлов резервных копий. Если планируешь полагаться на эти авторезервные файлы, важно убедиться, что авторезервное копирование работает. Некоторые обнаружили, что оно не работает на их CK из-за неисправной SD-карты или по другой причине. В любом случае, поддерживать актуальный файл резервной копии вне CK (или любого другого оборудования, на котором работает контроллер) было бы хорошей практикой.

Я использую CK и готов переходить на UAS.

В нашей церкви (около 4000 постоянных посетителей, около 50 сотрудников), в старых зданиях (в новом здании используется Ruckus) установлено около 20 UAP разных поколений и типов. Контроллер работает как контейнер на Linux VM вместе с UNMS и LibreNMS с Oxidized для архивирования конфигураций устройств AirMax и Juniper в университетской сети. Запускать контроллер напрямую на Linux OS (Debian или Ubuntu) со временем оказалось довольно мучительно. Обновления Java часто не очень хорошо совместимы, особенно при переходе между поколениями (например, jre6 -> jre7 -> jre8 и так далее). Запуск в контейнере избавил нас от всей той ерунды, с которой мы сталкивались при использовании UniFi контроллера. Мы используем релиз jacobalberty/unifi:stable и запускаем развертывание без UID0 (ура, за лучшую безопасность!). В целом, это гораздо стабильнее, обновления стали намного проще, и головной боли стало меньше как минимум на 95%. Не понимаю, зачем кому-то вообще хочется запускать что-то другое, кроме контейнерного UniFi контроллера (кроме, разве что, очень маленьких сайтов, которым нужно что-то вроде CloudKey).

У нас один контроллер на ВМ в основном офисе. Все сайты наших клиентов используют наш внутренний контроллер. Настраивать отдельный контроллер для каждой клиентской развертки на месте у них - нецелесообразно и превратится в кошмар с управлением. Просто сделайте один контроллер и пусть все ваши клиенты его используют.

Работает идеально, одна инстанция в виртуальной машине обслуживает десятки клиентских сайтов. Я никогда не был поклонником cloud key. Если бы мне нужна была какая-то штука на месте, я бы взял NUC [или что-то подобное]; гораздо мощнее, чем cloud key.

Хм, это не звучит хорошо, честно говоря. И даже если Controller работает на другой системе, это не особенно защищает от проблем, которые вы подняли. Странно, что в 2018 году нет ничего, что могло бы этого предотвратить. Если CloudKey или любая другая инстанция Uniify Controller теряет питание, как решать возникшие проблемы? Можно просто сделать бэкап CloudKey и загрузить его, и все будет хорошо, или потеря питания "бруит" устройство? Получается, что покупать источник бесперебойного питания для моей системы – это, как мне кажется, слишком много, если честно

@smawuascht

- Одно "ограничение" Cloud Key в том, что он (пока) не очень терпим к отключению питания без корректной команды на выключение. Подключение Cloud Key к источнику питания от ИБП помогает уменьшить эту проблему, но не решает её полностью, так как батарея не вечна, и (пока) нет способа для ИБП сообщить Cloud Key о предстоящем отключении.

Редактирую: Моя мысль в том, что с другим аппаратным решением, возможно, у вас появится шанс подключить его к ИБП, чтобы ИБП мог работать с ОС для корректного выключения. Шансов на это с Cloud Key нет.

Для справки, список тем, которые я собрал, касающихся проблемы повреждения Cloud Key при отключении питания, доступен здесь. Скорее всего, многие участники этих тем скажут, что Cloud Key по-прежнему очень хрупок.

Тем не менее, я использую Cloud Key в своей домашней сети.

Это 32b, и у него довольно ограниченный CPU и хранилище. К тому же, первые версии были известны тем, что "падали замертво". А апгрейд — это всегда целое приключение. Для дома я бы посмотрел в сторону Amazon EWS Free Tier, бесплатной VM от Google или Digital Ocean за 5 баксов в месяц. Бонус от хостинга в облаке в том, что его легко поделиться с семьей и друзьями, и они будут в восторге, если ты поможешь им настроить стабильное и отслеживаемое решение для Wi-Fi 😉