Продолжаем рассказ о системе построения и управления распределенными сетями Zyxel Nebula. В этот раз поговорим о развитии сетевой инфраструктуры в филиалах.
В предыдущей статье «Сверхновое облако Zyxel Nebula» — экономичный путь к безопасности?" мы рассмотрели вопросы, связанные с организацией сетевой инфраструктуры для небольших предприятий. В этот раз мы поговорим о ситуации, когда компания растёт и развивается.
Как растут организации?
Моноструктура — когда происходит рост внутри некой единой инфраструктуры. Например, краеведческое сообщество жителей города N скорее всего так и останется сообществом города N, даже если все жители войдут в его состав. То же самое можно сказать, например, о небольших финансовых институтах, например, «N-ский Муниципальный Банк» и так далее.
Иногда происходит слияние нескольких организаций в одну или экспансия одной организации за пределы своего региона. В этом случае происходит переход к развитию по филиальной схеме.
Развитие по схеме «центр и филиалы»
Допустим, в одном из небольших городов появляется замечательная компания, продукция которой пользуется хорошим спросом. Например, «N-ские чайники». Эти самые чайники хорошо продаются в других городах, и теперь для увеличения производства и сбыта требуется наличие филиалов.
Вот с открытием первого филиала в другом городе на повестке дня появляются первые вопросы по организации межсетевого взаимодействия.
При этом появляются общие задачи, требуется наладить каналы внутрикорпоративного общения, внедряется общая система бухгалтерского и управленческого учёта. Если это производственная сфера, к этому добавляются вопросы организации общего НИОКР, библиотеки разработок и так далее.
В итоге всё приходит к тому, что требуется некая разветвлённая сеть, которой нужно управлять, реализовать функции мониторинга и в конце концов просто иметь доступ для управления.
Но вне зависимости на каком этапе находится развитие филиальной сети, вопросы кадровой политики будут стоять всегда достаточно остро.
Ранее мы писали о том, что даже один высококвалифицированный сетевой администратор — это слишком много для средней российской компании в 100 с лишним человек. То есть для такого специалиста не будет достаточного количества задач, которые бы оправдывали высокую зарплату и позволяли расти профессионально (вместе с зарплатой, разумеется).
Но что делать если у нас даже не 100 пользователей в одном месте, а 5 локаций по 20 человек, да ещё в разных городах, не говоря о разных странах?
Как подключить филиальную инфраструктуру
Допустим, есть небольшая фирма со своей штаб-квартирой. В ней купили джентльменский набор для организации сети малого офиса в первом филиале: аппаратный шлюз, коммутатор, точку доступа.
При этом новая сетевая мини-структура должна не только обеспечивать внутренние нужды филиала, но также иметь стабильное подключение к центральному офису.
Возникает вопрос: кто и как это будет настраивать на месте?
Как обычно, есть несколько вариантов.
Первым на ум приходит самый дорогой вариант — обратиться к крупной компании — системному интегратору, обладающей хорошим опытом в построении подобных разветвлённых сетей. Однако такая услуга имеет свою немалую цену, которая может оказаться неподъёмной для небольшой компании, только-только начавшей расти.
Еще можно попытаться решить проблему самостоятельно. Для этого есть несколько способов:
Первый — заслать имеющегося сетевого гуру в командировку на место развёртывания филиальной сети. Для этого нужно, во-первых, держать в штате такого специалиста на постоянной основе, во-вторых, чтобы на данный момент в штаб-квартире не было серьёзных задач, требующих решения.
Второй — попытаться сделать в штаб-квартире какие-то начальные настройки, чтобы иметь возможность удалённого подключения, и потом переслать оборудование в филиал. А местная ИТ-служба уже своими силами будет производить установку.
Третий — работа с местным ИТ-специалистом, если таковой имеется, или просто с «продвинутым пользователем» в режиме «зомби», то есть когда сетевой администратор из центрального офиса даёт указания, а сотрудник филиала их напрямую выполняет.
На практике часто встречается сочетание всех трёх способов, то есть сначала отправляется оборудование с «правильной конфигурацией», сотрудник на месте не может разобраться, далее делаются долгие попытки выполнить настройку в режиме «зомби» и в итоге дело оканчивается командировкой сетевого администратора в филиал.
Ещё как вариант — обратиться к аутсорсинговой компании или просто к «приходящему админу», обладающему нужной квалификацией. Этот вариант имеет определённые преимущества и целый набор ограничений.
Во-первых, такую компанию надо найти. Далеко не во всех регионах есть аутсорсинговые компании, имеющие в штате специалиста нужной квалификации. Во-вторых, у такой компании должна быть приемлемая цена за подобные услуги.
Иногда появляются дополнительные вопросы, связанные с квалификацией персонала подрядчика на месте и взаимодействии со специалистом в центральном офисе. Ситуация значительно упрощается, если в штаб-квартире есть свой специалист.
Гораздо хуже если и с той, и с другой стороны работают «приходящие админы» или представители разных аутсорсинговых компаний. Если они по какому-то вопросу не смогли найти общий язык, то общий процесс настройки может затянуться на долгий срок.
Очень сложно заранее предугадать, какой из вариантов окажется менее затратным: интеграционный проект, предварительная настройка оборудования с последующей командировкой специалиста или контракт с аутсорсинговой компанией. При оценке необходимо принимать в расчёт не только выставленный счёт за услуги, но затраченное время, а также такие «тонкие материи» как стоимость простоя, утерянная выгода и так далее.
От лайфхака к облачной технологии
Если всё-таки выбрать вариант самостоятельной настройки силами внутреннего ИТ-подразделения, то можно применить следующий приём.
- Специалист на месте (в филиале) устанавливает компьютер с выходом в Интернет любым доступным способом. Хоть 3G USB модем — в данном случае это неважно. Операционная система в принципе не так важна, но пусть это будет что-то из семейства MS Windows
- На компьютер устанавливается программа удалённого управления, например, TeamViewer или аналогичная. Важно, чтобы клиент-серверная архитектура могла самостоятельное устанавливать связь через облачный сервер. В этом случае не нужно настраивать прямой доступ к компьютеру. Достаточно только знать ID и иметь удалённого клиента.
- Далее этот компьютер подключается к оборудованию, которое подлежит настройке.
- Специалист из филиала сообщает сетевому гуру из центральной штаб-квартиры ID (логин) и пароль для удалённого доступа.
- Получив доступ, сетевой администратор из центрального офиса настраивает оборудование в филиале.
При таком подходе функции местного ИТ-специалиста в филиале ограничиваются физическим сопровождением: монтаж в стойку, подключение кабелей, включение-выключение оборудования по запросу сетевого администратора и так далее.
Примечание. В данной статье названия компаний и имена продуктов используются только в качестве их идентификации. Названия продуктов и компаний (TeamViewer, MS Windows, Zyxel Nebula), упоминаемые в данной публикации, являются торговыми марками, принадлежащими их законным владельцам.
Рисунок 1. Использование стороннего облачного сервиса для создания подключения.
Это замечательный метод изначально содержит в себе несколько ограничений.
- Коммерческое использование TeamViewer или его аналогов не является бесплатным. То есть потребуется покупка лицензии с годовой подпиской, постановка её на учёт в бухгалтерии и так далее.
- Данная схема является не совсем безопасной, так как в случае несанкционированного доступа даёт возможность обращаться ко всем ресурсам филиала, например, к файловому серверу и так далее. То есть если кто-то из персонала попытается подключиться к данному компьютеру из дома, он получит доступ ко всему, что находится в поле зрения.
- Ну и данная схема предназначена скорее для разовой настройки. Такие функции как мониторинг, сбор статистики, оповещение об инцидентах остаются нереализованными.
Поэтому такой обходной вариант больше подходит для выполнения разовых работ по подключению и первоначальной настройки оборудования, но никак не для постоянного использования. При этом всё равно требуется купить лицензию на постоянной основе.
Не стоит забывать, что вопрос мониторинга, сбора статистики, оповещения остаётся открытым.
Примечание. Варианты нелегального использования ПО или граничащие с нелегальным принципиально не рассматриваются. Если организация с самого начала своего существования допускает применения нечестных схем, её будущее весьма незавидно.
И тут, как обычно, перед создателями сетевой инфраструктуры встаёт вопрос: «Зачем изобретать велосипед, не проще ли поискать уже готовое недорогое, а ещё лучше — готовое бесплатное решение?»
Zyxel Nebula — экономичное решение для филиальной инфраструктуры
Оказывается, Zyxel Nebula — это и есть то самое решение, которое не требует присутствия на площадке специалиста по сетевым технологиям.
Zyxel Nebula — это облачный компонент, который позволяет соединяться с удалёнными устройствами, подобно тому, как сервис TeamViewer помогает установить связь с удалённым компьютером.
ЭТО ВАЖНО! Все критические функции для настройки управления в Zyxel Nebula доступны БЕСПЛАТНО. Отличие платной версии заключается в более расширенном числе функций, удобстве использования, более длительном сроке хранения статистики и так далее.
При этом в первый год после начала использования устройства, а это самый важный период тестирования и опытной эксплуатации, в этот период ПОЛНЫЙ НАБОР платных функций уровня Enterprise также доступен БЕСПЛАТНО.
Продолжать использование полного функционала или перейти на бесплатную версию такой выбор потребуется сделать только на второй год.
Отличия между различными вариантами использования можно прочитать здесь.
Все устройства, предназначенные для работы с Nebula, уже содержат программу-клиент для связи с облачным сервисом.
То есть не нужно думать о каком-то компьютере для подключения к сети, дополнительном Интернет-канале, программном обеспечении. Всё уже есть в самой «железке» от Zyxel.
Рисунок 2. Подключение и работа через Zyxel Nebula.
Обратите внимание, что устройства-клиенты Nebula устанавливают исходящее соединение до облака. То есть нет необходимости дополнительно открывать порты, пробрасывать входящее соединение, как это требуется при настройке традиционным способом (локальный доступ).
Из дополнительных возможностей, облегчающих настройку и установку оборудования, стоит отметить простой для освоения web-интерфейс, готовые политики доступа и параметров конфигурации.
Ну и конечно возможности мониторинга и сбора статистики, позволяющие оценить работу и провести адаптацию настроек по итогам наблюдения.
Подключение устройства к Zyxel Nebula
Подключение устройства в облако Nebula — это апофеоз простоты и изящества. Достаточно одного сотрудника, умеющего пользоваться смартфоном, подключённым к Интернет.
Вначале на web-страничке Zyxel создаётся и регистрируется аккаунт предприятия. В каждом предприятии может быть один или несколько сайтов — таким образом можно зарегистрировать штаб-квартиру и все филиалы, при этом выполнив необходимые разграничения прав доступ и так далее.
В web-интерфейсе Nebula заводятся пользователи, которые могут заносить устройства в тот или иной сайт.
Далее всё просто. Сотрудник филиала получает реквизиты для входа, устанавливает на свой смартфон или планшет программу Zyxel Nebula и регистрируется в облаке.
Вызывает через меню функцию добавления устройства.
Рисунок 3. Добавление устройства в облачную среду управления.
Остаётся просканировать через камеру смартфона QR-код с корпуса устройства. И устройство автоматически регистрируется в облаке Zyxel Nebula.
Рисунок 4. Добавление устройства в облачную среду управления.
После этого добавленное устройство появится в списке.
Рисунок 5. Добавленное устройство в списке доступных для управления.
Всё, смартфон можно отключить от Интернет, для Nebula в данном случае он больше не нужен. Устройство теперь доступно через облако и сетевой администратор в штаб-квартире может подключиться к нему для управления.
При этом нет разницы, находится устройство на границе выхода в Сеть, в DMZ или внутри периметра сети. Главное, чтобы оно могло осуществить исходящее соединение по HTTPS протоколу. Всё остальное сделает Zyxel Nebula.
Заключение
Как видим, работать с Zyxel Nebula не просто, а очень просто. Этот сервис призван помочь решить задачу построения и управления сложной многофилиальной сети.
Встроенные функции сбора статистики и мониторинга могут оказать хорошую поддержку при обслуживании сетевой инфраструктуры.
Источники
[1] Первая часть серии статей о Zyxel Nebula «Сверхновое облако Zyxel Nebula — экономичный путь к безопасности?»
[2] Страница Zyxel Nebula на сайте компании Zyxel
[3] Сайт Team Viewer
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
SDN/SDWAN сервисы в вашей сети:
11.11% Интересно, хочу попробовать (оставьте заявку в комментариях)1
0% Уже использую в своей сети (а что используете, если не секрет? — поделитесь в комментариях)0
0% Не планирую, меня и так все устраивает0
88.89% Не доверяю «облакам»8
0% Другой вариант (не сочтите за труд — чиркните в комментах)0
Проголосовали 9 пользователей. Воздержались 6 пользователей.
