Переваги централізованих систем керування мережею: порівняння Zyxel Nebula та TP-Link Omada

У великих корпоративних мережах зі складною топологією справжнім пеклом для адміністратора стане послідовне налаштування всіх підключених пристроїв по одному. У таких випадках виявити помилки в мережі або визначити її стан часто практично неможливо. Програмно визначені мережі не мають цієї проблеми: вони автоматично дозволяють вам керувати мережевими функціями через центральний контролер і налаштовувати однорідні пристрої (наприклад, точки доступу або комутатори) у пакетному режимі. Єдиний контролер може допомогти у вирішенні мережевих проблем і автоматично запропонувати рішення, полегшити пошук несправностей і визначити інциденти.

Колись роль контролерів управління відводилася окремим пристроям, що було пов'язано з певними труднощами: по-перше, це ще одна позиція в загальній номенклатурі, яку необхідно встановлювати і обслуговувати, по-друге, будь-який апаратний пристрій більш втратний порівняно з програмним забезпеченням за гнучкістю та можливостями розвитку. По-третє, як тільки у вас з'являється програмний контролер серед декількох апаратних контролерів, відразу ж порушується одноманітність систем управління, і рано чи пізно ви все одно поміняєте апаратне на програмне. І тоді буде вибір: використовувати централізоване локальне рішення чи хмарне?

І давайте порівняємо: в лівому кутку у нас Zyxel з уже немолодою і відточеною системою оркестровки Nebula cloud, а в правому - TP-Link з новою, але дуже перспективною системою Omada SDN. Ми спеціально взяли для порівняння два варіанти - хмарне і локальне управління. При цьому хочемо наголосити, що TP-Link вже має і хмарне рішення Omada. На даний момент Omada SDN Controller має три форми: програмний контролер Omada, апаратний контролер Omada та хмарний контролер Omada, хоч на випуск останнього і пішло значно більше часу. 

5 причин вибрати «хмарний» контролер замість локального

• Клієнту нікуди встановлювати локал: це можуть бути і невеликі готелі, і об'єкти з обмеженим бюджетом, в яких просто немає можливості розмістити машину, по якій би бігав контролер.
• Ваша компанія підтримує кілька об'єктів на аутсорсингу. Причому необов’язково, щоб це були об’єкти одного замовника: у вас як і раніше є єдина точка входу до налаштувань усіх мереж і всіх пристроїв, де б вони не знаходилися, при збереженні всіх вимог конфіденційності.
  
• Ви повинні звільнити постачальника інтернет-послуг від відповідальності за роботу мережевого контролера згідно з умовами контракту.
  
• Вам важливо зменшити площу атаки для зловмисників. Так, тут не варто забувати, що у випадку з Zyxel Nebula ви не витрачаєте час і гроші на адміністрування операційної системи та гіпервізора, на якому встановлений контролер. ОС не буде вимагати оновлення і не буде перезавантажуватися як завгодно, залишаючи вас без доступу до мережі.
  
• Вам потрібна гарантована безпека інтерфейсу керування як готового сервісу, із сертифікатами та публічними тестами.
  

Звичайно, у клієнтів можуть бути й інші причини вибрати готовий сервіс замість того, щоб розгортати власний, але принциповий момент буде незмінним: на відміну від TP-Link Omada, хмара Nebula від Zyxel не прив’язана до «Windows», який завжди оновлюється та перевантажується, і якщо вам потрібна допомога, ви можете звернутися до адміністратора Nebula. У випадку з Omada адміністратором є ви, і звичайнісінькі моделі поведінки можуть призвести до зупинки всієї мережі, про що мова піде далі.

Причини вибрати локальний контролер замість хмарного

• У вас параноїдальні вимоги до безпеки. По суті, ви боїтеся, що обладнання бізнес-класу збере ваші дані і перенесе їх у хмару. У цьому випадку можна закрити локальний контролер і апаратний доступ до мережі, зберігши вхід через домен, а потім оновити прошивку вручну.
• Ви боїтеся, що у вашій країні буде встановлено централізований брандмауер і доступ до серверів буде вимкнено. Тобто в той самий момент, коли все навколо вас рухне, вам важливо зберегти контроль над своєю мережею.
  
• Вам потрібно підключити мережевий контролер до деяких локальних служб моніторингу та аналітики, таких як Elasticsearch або Prometheus, і централізовано отримувати метрику від контролера, а не від кожного пристрою.
  

На практиці, якщо клієнту потрібен контролер локальної мережі, то він або боїться залізної завіси «суверенного інтернету», або не хоче, щоб щось кудись вийшло з його мережі, тому що він не довіряє навіть постачальнику інтернет-послуг.

Апаратна підтримка

За словами Zyxel, підтримка від Nebula вимагає настільки масштабних змін у програмному коді, що мережеве обладнання доводиться розробляти з нуля, тому і вони, і моделі TP-Link з підтримкою програмного контролера винесені в окрему категорію.

У випадку з Zyxel все просто, моделі з пітримкою хмари додатково позначаються NebulaFlex. Що стосується TP-Link, компанія змінила назви товарів, моделі з підтримкою Omada залишились зі звичним старим маркуванням, наприклад TL-SG2008, в той час коли їх аналоги без підтримки Omada SDN отримали нові назви лінійок - це T1500/T1600/T1700/T2500/T2600 і т.д. Відповіно моделі маркуються як T1500G-10PS(TL-SG2210P). По кількості пристроїв з підтримкою централізованого управління важко порівнювати, зараз обидва виробники пропонують безліч моделей і ідуть практично нога в ногу.  

Простота розгортання

І TP-Link, і Zyxel максимально оптимізували процес розгортання масштабних установок. У Zyxel вам достатньо взяти мобільний телефон і в додатку NebulaFlex відсканувати QR-коди на футлярах або навіть на коробках із обладнанням: ви можете додати кілька одиниць обладнання до своєї організації одночасно. Більше того, пряме сканування QR-коду завжди в пріоритеті, а якщо хтось вже додав обладнання у ваш обліковий запис, ви можете додати його на свій мобільний телефон, тому завжди відривайте QR-коди від чохлів після встановлення в людних місцях. Недоліком цього алгоритму є те, що вам потрібен працюючий інтернет у вашій мережі вже на етапі розгортання обладнання.

З TP-Link ви просто підключаєте обладнання мережевими кабелями, а контролер сам знаходить усі пристрої у вашій мережі, після чого можна починати налаштування. Недолік цього алгоритму полягає в тому, що ви можете налаштувати обладнання лише в тій мережі, до якої воно підключено, тобто якщо у вас є два сегменти, наприклад 192.168.1.0 і 10.10.10.0, то спочатку підключіть контролер до першої мережі і налаштуйте там обладнання, а потім повторіть цей крок для іншої мережі або налаштуйте маршрутизацію між ними.

Природно, якась мережа вже повинна працювати, щоб запустити Omada SDN. Складнощі виникають при модернізації декількох підмереж одночасно: якщо у вас загальний контролер, то потрібно налаштувати доступ до всіх мереж, наприклад, прописавши правила маршрутизації або NAT, а це знову ж таки може суперечити політиці безпеки компанії або навіть бути неможливо.

Логування (ведення журналів)

Професійні системні адміністратори вважають за краще зберігати журнали всіх подій на всіх пристроях і назавжди, але програмні мережеві контролери створені з іншою метою - щоб ви могли легко відстежувати стан мережі у веб-інтерфейсі, а також аналізувати та досліджувати інциденти на разом з іншим програмним забезпеченням. Таким чином, і в Nebula, і в Omada SDN ви можете налаштувати експорт журналу на сервер Syslog, а в Zyxel ви можете встановити окремі сервери для точок доступу, комутаторів і шлюзів, а також увімкнути журналювання трафіку гарячих точок. Omada SDN має скромніші налаштування в цьому відношенні: у вас є доступ до однієї адреси сервера Syslog, але ви можете зберігати журнали клієнтського пристрою на ньому.

У базовій версії Nebula може зберігати журнали протягом 24 годин, у версії Plus — 7 днів, а в версії Pro — 1 рік, Omada SDN не має таких обмежень, але перед злісними адміністраторами Zyxel може перевершити підтримку SNMP, яка дозволить контролювати пристрої, підключені до Nebula через Prometheus або Zabbix.

Висновки

За програмними контролерами майбутнє, і якщо ваш проект включає хоча б 2-3 пристрої, вже є сенс вибирати рішення з програмним конфігуратором. Тому що навіть на маленьких проектах заради точки доступу зі світчем систему моніторингу з Zabbix + Grafana + ElasticSearch не побудуєш, а вбудовані інтерфейси мережевих пристроїв застрягли десь в кінці 90-х, мабуть назавжди . І звичайно, з розростанням проекту, появою VPN-тунелів, появою збоїв і спроб злому вам буде тим легше, чим зручнішим і зрозумілішим буде єдиний інтерфейс моніторингу та управління.

Отже, рішення Zyxel є трохи більш зрілим, що цілком зрозуміло, враховуючи, що до Omada вийшов пізніше, а Nebula розробляється з 2017 року. Ми порівняли варіант хмарного і локального встановлення. Проте, TP-Link також розробили хмарний контролер Omada. Omada SDN Cloud Controller пропонує хмарний доступ до своїх локальних платформ централізованого керування (Omada Software Controller і Omada Hardware Controller). Ці платформи дають мережевим адміністраторам контроль над усією мережею, де б вони не були, через програму Omada або веб-інтерфейс користувача без додаткової плати за обслуговування.

І Nebula, і Omada чудово виконують роль централізованого управління з сучасним, зрозумілим і стильним інтерфейсом. Принципових відмінностей між розміщенням контролера в хмарі чи на локальному сервері не так багато, але у всіх випадках, крім Edge, хмарне рішення є більш гнучким і легким.