Мы много писали про облачное управление: о стратегии применения, построении готовых решений, о нюансах использования, об эксплуатации в реальных условиях. Однако любая технология должна быть не только стратегически правильной, но и продукты, созданные на её основе — удобными для работы. Инженеры и дизайнеры Zyxel постарались учесть все вопросы при создании удобного интерфейса для облачной среды Nebula. Но люди индивидуальны и зависимость от привычного окружения у каждого своя. Как быстрее понять основные принципы и адаптироваться к новому стилю работы — об этом и пойдёт речь. В данной статьe мы постарались ответить на следующие вопросы: Также мы подготовили ответы на вопросы, которые встретились в комментариях. Облачная среда управления Nebula — это новое направление по сравнению с традиционным интерфейсом. Любое нововведение требует период адаптации, это старо как мир. И всё равно каждый раз это выглядит как в известной фразе Виктора Степановича Черномырдина: «Никогда такого не было, и вот опять!» Иногда возникают ситуации, когда даже небольшие изменения могут вызвать противоречивое отношение. Например, дежурный администратор, привыкший к одному виду расположения элементов, может чувствовать себя немного не в своей тарелке. Обычно локальный интерфейс для управления чем-либо строится по хорошо знакомой схеме: «Вот конкретное устройство. Слева список разделов, справа — область информации и объектов управления (см. рисунок).  Рисунок 1. Пример локального интерфейса Zyxel (USG FLEX 200). Слева разделы интерфейса, справа — рабочая область. В Nebula всё выглядит примерно также, но… немного по-другому. Почему так происходит, давайте разбираться. https://habrastorage.org/webt/5l/08/jz/5l08jzmrpvallezv7zfgtfv3gn8.png
Рисунок 2. Пример веб-интерфейса Nebula. В отличие от локального интерфейса, где нужно просто хорошо управлять одним-единственным устройством и всё, Zyxel Nebula проектировалась как глобальная система управления распределённой инфраструктурой. Очень часто компания — не монолитная структура, а штаб-квартира с филиалами. Почти всегда присутствует разделение по географическому или какому-либо другому признаку, а то и по всём сразу. Мало того отдельные департаменты внутри организационной единицы могут иметь свою собственную инфраструктуру. Например, отдел разработки может иметь свой production (для внутренних нужд), свою тестовую среду, свои вспомогательные серверы (например, свой DHCP) и всё это отдельно от основных служб и сервисов. Наконец, в компании может быть не один ЦОД, не одна серверная, и тем более не единственная стойка с серверами. Что и накладывает отпечаток на управление всем этим хозяйством.  Рисунок 3. Интерфейс Nebula. Показано «подменю» с выбором раздела» Соответственно, в глобальном интерфейсе управления необходимо создать виртуальную инфраструктуру, адекватную той, что уже существует в реальности. Ещё один интересный нюанс кроется в идеологии подключения. Когда подключаетесь напрямую — нужно учитывать дополнительные условия, например, имеет устройство постоянный адрес, открыты ли порты и так далее. Для работы с Nebula эти вопросы неактуальны, зато могут встретиться другие важные моменты, например, включен ли на самом устройстве параметр Nebula Control Center Discovery, чтобы устройство смогло самостоятельно найти «облако». Начнём с начала и попробуем зарегистрироваться в Nebula c «чистого листа». При регистрации в Zyxel Nebula первое, что предстоит сделать — создать корневую структурную единицу — Предприятие и одну нижестоящую инфраструктурную единицу — Площадку. Таким образом каждое подразделение, ЦОД, серверная, и всё что мы хотим, как-то отделить — можно разместить на отдельных площадках.  Рисунок 4. Создание организации и первой площадки. Какие это даёт преимущества? Во-первых, можно делать общие настройки для всех единиц оборудования на одной Площадке. Не надо дублировать одно и то же для каждого устройства. Во-вторых, можно делегировать управление Площадкой сотрудникам с разными ролями. Например, дежурный администратор может только просматривать информацию, чтобы создать заявку. А сетевой администратор, работающий в филиале — вносить необходимые изменения, но в рамках своей Площадки. Это удобно, и никто не мешает друг другу. Разумеется, не все настройки можно вынести в общий раздел. Поэтому в интерфейсе Nebula сохраняются специализированные подразделы по типу оборудования: Шлюз безопасности, Коммутаторы, Точки доступа. При этом наличие группы общих настроек, размещённой в разделе Площадка вносит некоторое «разнообразие» в привычном алгоритме работы администратора.  Рисунок 5. Настройка портов выбранного коммутатора в разделе «Коммутаторы — Конфигурация» На самом деле вся система Nebula спроектирована так, чтобы не было проблем. Однако существуют ещё внешние факторы, на которые разработчики не могут повлиять при всём желании. Например, если при подключении устройства используется недостаточно быстрое соединение, то и регистрация устройств в сети будет недостаточно быстрой. Ещё одним важным фактором является использование исходящих соединений для связи устройств с облачной средой управления. То есть Nebula не разыскивает устройства, например, по «белым» IP адресам, и не подключается к ним по заранее открытым портам на файерволе, а именно сами устройства связываются с облачной средой управления по протоколу NETCONF. Это и безопасней (никаких «дырок» на файрволе) и проще организовать — не нужно обзаводиться постоянным «белым» IP адресом, или возиться с настройкой DDNS (динамического DNS). Гораздо проще подождать, пока устройство само установит соединение. Выглядит это тривиально: зарегистрировали устройство, допустим, через мобильное приложение, а в интерфейсе Nebula оно появляется само, пусть не сразу, но спустя некоторое время. Давайте опишем, как происходит регистрация и какие этапы она проходит. Зарегистрировать устройство можно двумя способами: послав код устройства через приложение Nebula Mobile (IOS, Android) или указав реквизиты: MAC адрес и серийный номер вручную.  Рисунок 6. Регистрация через мобильное приложение. Рассмотрим мобильную регистрацию. Вначале пользователь выбирает нужную организацию и площадку. Если доступна только одна организация или площадка одна, этот вопрос автоматически снимается. После сканирования QR кода автоматически распознаются тип и модель устройства, а также MAC адрес и серийный номер. Эта информация проходит процедуру анонимизации и шифрования и записывается в базу данных. Обязательно должен быть включён параметр Nebula Control Center Discovery, который запускает процесс поиска и соединения с облачным центром управления. (Как включить — можно посмотреть в документации на конкретную модель). Если устройство онлайн, и у него задействован описанный выше параметр — через некоторое время оно установит связь с облачной средой управления, автоматически подключится к нему, получит идентификатор, и можно будет управлять через «облако».  Рисунок 7. Включение параметра Nebula Control Center Discovery. Схожим образом происходит регистрация вручную с вводом MAC адреса и серийного номера в веб-интерфейсе, но при этом данные сразу вводятся в облако, их не нужно «вытаскивать» из QR кода и передавать по беспроводной связи.  Рисунок 8. Регистрация устройства через веб-интерфейс. По идее, если введённая информация верна, ничего делать не нужно, и устройство через какое-то время окажется в сети Nebula (в обычной ситуации это может занять до 2‑х минут). Но иногда хочется всё получить как можно быстрее. Рассмотрим такой вариант — зарегистрировали устройство в Nebula Mobile, а оно не успело появиться в интерфейсе, и время появления хочется сократить. Можно попробовать перезагрузить устройство — оно сразу после запуска установит соединение. В некоторых случаях это позволит немного ускорить регистрацию (или просто чем-то занять себя во время ожидания). Ещё один способ ускорить процесс — регистрировать устройства вручную через веб-интерфейс. В этом случае не используется этап дешифровки QR кода, и при наличии более скоростного и стабильного проводного соединения данные могут быть переданы быстрее. Ещё один вариант «ошибки» — оборудование зарегистрировано, но в интерфейсе Nebula отображается неактивным. Это говорит о том, что устройство просто не успело соединиться с Nebula для первичного обмена информацией. У пользователя есть выбор: немного подождать или «для ускорения» перезагрузить устройство. Ещё одна помеха на пути к быстрой регистрации — «неторопливый» Интернет-браузер, который показывает старую «картинку». Помогает обнуление кэша или просто завершить работу браузера (все сессии и процессы) и запустить его, снова подключившись к своему аккаунту в Nebula. Ниже постараемся ответить на некоторые вопросы, которые возникают у людей, недавно столкнувшихся с облачными системами управления. На самом деле ситуация не так трагична, как кажется. Локальные устройства, управляемые через Nebula: точки доступа, коммутаторы, и даже Интернет-шлюз (его локальные функции, такие как DHCP или RADIUS сервер) — продолжат функционировать. Возникнут трудности с управлением, но локальная сеть не упадёт, и пользователи смогут выполнять ту часть работы, для которой не нужен выход в Интернет, например, работать в 1С на локальном сервере. При восстановлении канала восстановится и стандартная функция управления. Проще говоря, тот же принцип, что и при любом централизованном управлении: Разумеется, для безотказной работы необходимо иметь резервный Интернет-канал, для любого сценария управления: с Nebula или локально. Потому что связь с внешним миром — это такой же необходимый ресурс, как и всё остальное, а для бесперебойной работы необходимо резервирование. В данном случае стоит рассмотреть сценарий, когда происходит утечка данных, пригодных к использованию посторонними лицами. Данных в таком виде Nebula просто не хранит. Во-первых, хранятся только данные, которые действительно необходимы для выполнения узкоспециализированных атомарных операций и для построения отчётов, опять же, строго по запросу администратора. Объём СХД, как известно, «не резиновый». Поэтому хранить данные на случай «вдруг понадобится» никто не будет. Во-вторых, очень важно в каком виде хранятся данные. Дополнительно публикуем две ссылки на документы в открытом доступе: С другой стороны, при использовании традиционного «необлачного»» управления с прямым подключением — проблем с безопасностью может быть гораздо больше. Например, потерянный служебный ноутбук или принудительное изъятие рабочего ПК сетевого администратора в рамках каких-то там мероприятий — увы, не самый невероятный сценарий. И ситуация при этом может оказаться гораздо более печальна, чем та, когда всё управляется удалённо через «облако». Устройства можно перевести в автономный режим работы, просто удалив их из Организации через тот же интерфейс Nebula. Если речь идёт о передаче устройств в рамках одной компании — можно просто переместить устройство между площадками. Если же для каждого подразделения существует своя организация в Nebula — тогда их нужно удалить из Организации и зарегистрировать заново. Zyxel Nebula проектировалась как система управления распределённой инфраструктурой. Для неё всё равно, где находится оборудование, важно, чтобы устройства имели выход в Интернет. Это накладывает определённый отпечаток на идеологию управления, и, как следствие, на интерфейс пользователя. При работе с любой системой возникают некоторые нюансы, о которых полезно знать перед началом эксплуатации.