Zyxel_Tech 27 апр 2021 в 12:00

Облачный интерфейс управления — взгляд под другим углом

9 мин

4.3K

Блог компании ITT SolutionsОблачные сервисы*Сетевое оборудованиеСетевые технологии*Системное администрирование*

Мы много писали про облачное управление: о стратегии применения, построении готовых решений, о нюансах использования, об эксплуатации в реальных условиях. Однако любая технология должна быть не только стратегически правильной, но и продукты, созданные на её основе — удобными для работы.

Инженеры и дизайнеры 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

Разумеется, не все настройки можно вынести в общий раздел. Поэтому в интерфейсе 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.

Вопросы и ответы

Ниже постараемся ответить на некоторые вопросы, которые возникают у людей, недавно столкнувшихся с облачными системами управления.

А что если отключат Интернет? Всё, приплыли?

На самом деле ситуация не так трагична, как кажется. Локальные устройства, управляемые через Nebula: точки доступа, коммутаторы, и даже Интернет-шлюз (его локальные функции, такие как DHCP или RADIUS сервер) — продолжат функционировать. Возникнут трудности с управлением, но локальная сеть не упадёт, и пользователи смогут выполнять ту часть работы, для которой не нужен выход в Интернет, например, работать в 1С на локальном сервере.

При восстановлении канала восстановится и стандартная функция управления.

Проще говоря, тот же принцип, что и при любом централизованном управлении:

Что успели настроить до потери связи с центром, то работает.
Во время отсутствия управляющего центра изменения внести не получится.
Канал подняли — можно продолжить настройки.

Важно. Для устройств, подключённых к Nebula остаётся возможность управления через CLI (или веб-интерфейс, в зависимости от модели).

Разумеется, для безотказной работы необходимо иметь резервный Интернет-канал, для любого сценария управления: с Nebula или локально. Потому что связь с внешним миром — это такой же необходимый ресурс, как и всё остальное, а для бесперебойной работы необходимо резервирование.

А что если данные из облака утекут? Тогда инфраструктурой может управлять кто захочет?

В данном случае стоит рассмотреть сценарий, когда происходит утечка данных, пригодных к использованию посторонними лицами. Данных в таком виде Nebula просто не хранит.

Во-первых, хранятся только данные, которые действительно необходимы для выполнения узкоспециализированных атомарных операций и для построения отчётов, опять же, строго по запросу администратора. Объём СХД, как известно, «не резиновый». Поэтому хранить данные на случай «вдруг понадобится» никто не будет.

Во-вторых, очень важно в каком виде хранятся данные.

Все данные при поступлении анонимизируются. Проще говоря, понять где чья запись от какого клиента — может только сама Nebula.
Все данные хранятся в зашифрованном виде.
Используется такая замечательная вещь, как двухфакторная аутентификация. В случае её использования попытки «порулить чужой системой» останутся безуспешными, если только вы сами не делегируете полномочия.

Примечание. Информацию из первоисточников можно получить по ссылкам в самой Nebula в меню «Помощь — Политика обработки данных».

Дополнительно публикуем две ссылки на документы в открытом доступе:

С другой стороны, при использовании традиционного «необлачного»» управления с прямым подключением — проблем с безопасностью может быть гораздо больше. Например, потерянный служебный ноутбук или принудительное изъятие рабочего ПК сетевого администратора в рамках каких-то там мероприятий — увы, не самый невероятный сценарий. И ситуация при этом может оказаться гораздо более печальна, чем та, когда всё управляется удалённо через «облако».

Регистрация в Nebula — это дорога в один конец? Обратно в автономный режим переключить устройство уже не получится?

Устройства можно перевести в автономный режим работы, просто удалив их из Организации через тот же интерфейс Nebula.

А что если придётся передать устройство в другое подразделение (филиал, дочернюю компанию)?

Если речь идёт о передаче устройств в рамках одной компании — можно просто переместить устройство между площадками. Если же для каждого подразделения существует своя организация в Nebula — тогда их нужно удалить из Организации и зарегистрировать заново.

Подводя итоги

Zyxel Nebula проектировалась как система управления распределённой инфраструктурой. Для неё всё равно, где находится оборудование, важно, чтобы устройства имели выход в Интернет.

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

Полезные ссылки

Теги:

Хабы: