Комментарии 24
Отсутствие специалистов на рынке по этому решению делают серьезные опасения по внедрению
документация обширна, но 24*7 уже стремновато…
А так очень красивое решение
Спасибо за комментарий, самое главное — решение рабочее :) и работает 24x7x365
VyOS используются давно, и полностью удовлетворяют всем требованиям, а главное надёжны и предсказуемы.
Что касается специалистов… Поверьте, порог вхождения не очень высок, особенно если человек уже работал с Juniper, или даже Cisco. Единственный недостаток, если с точки зрения не слишком сетевого админа, то это отсутствие GUI, но то в общем такое…
Так-же компания Ubiquiti написала свой веб-интерфейс и назвала это всё EdgeOS для использования в своих маршрутизаторах серии EdgeRouter.
Потом Vyatta Inc. купила компания Brocade и использовала как основу для исключительно коммерческого продукта Brocade Vyatta Network OS.
VyOS является форком с открытыми исходниками последнего издания Vyatta Routing Community Edition…
Таким образом, я-бы не сказал, что на рынке нет специалистов. Juniper и Ubiquiti вполне распространённые решения в определенных кругах…
Совершенно верно, если работал с каким-либо из продуктов, типа Juniper (JunOS), Ubiquitu (EdgeOS ) и Vyatta, то работать с VyOS — это как семечки грызть :)
Ну и если говорить в общем, то принципы работы с VyOS и Cisco ASA примерно похожи: тот же режим конфигурирования устройства (любимый conf t), те же именованные группы правил применяемые к интерфейсу, и т.п. Команды конечно разные, это да :)
Проще, почему vyos а не pfsense?
Как раз выбор стоит для стойки.
в двух словах — это проверенное и надёжное решение
Но pfsense больше графика и понятно интуитивно интерфейс
а vyos это своя коммандная строка
Тут не поспоришь, графическая управлялка конечно же во многих случаях — это аргумент, особенно когда нет под рукой более-менее квалифицированного админа, или просто нет времени разбираться с CLI.
Но с другой стороны, работая с CLI, приходится влезать во внутренности устройства, иначе без знания команд элементарно ничего не настроить, особенно какие-то сложные конфиги.
GUI позволяет это делать в некоторых случаях даже методом тыка или просто запустив мастер настроек — тут да, простота может быть решающим аргументом, но до определённых пределов.
После тех пределов придет понятие:
- выделенное оборудование
- наличие недорогих экспертов уровня ccie
- и нахрен зоопарк и непонятные решения
Вот тут уже получается только cisco juniper…
Кстати цена микротика копейки, между микротиком и vyos и pfsense что выбрать?
Это можно сказать жду статью с аналитикой какойнить адекватной)))
:)))
Ну да, асисяй это конечно нужный товарищ в хозяйстве, но пока рано :))
Чтобы сделать такую статью со сравнительным анализом, надо сесть, и проанализировать эти три решения — как устанавливать, как настраивать, степень сложности, интуитивности использования графической оболочки если есть, и т.п.
И всё равно найдутся или спорщики, или недовольные, так как сравнение как ни крути, будет субъективным в какой-то степени.
Поэтому совет простой — выбирайте то, с чем уже работали,
но исходя из настоящих и будущих требований по проекту и соотвествия им возможностей самого решения, чтобы потом не было мучительно больно и трудно всё или делать по новой, или ставить костыли.
Лично предпочитаю делать всё на Cisco, но даже у них не всегда есть то, что нужно, а уж слово "дешевле" — это явно не про них ;)))
Когда нехватает на cisco берут микротик
Там хватает и экспертов уровня ccnp (выше у микрота хрен найдешь) и главное отдельные железки за копье, да и с графикой все весьма неплохо
Ну так то да, хотя предпочитаю использовать микротики для офисов — тут они наверное вне конкуренции точно, и главное GUI, с которым любой виндовс админ справится.
В своё время в плане простоты работы, ещё нравилось решение от M$ — TMG 2010, очень хорошая вещь была, особенно для публикации сервисов от M$ (правда без CLI), жалко что перестали его поддерживать, да и вообще завалили полностью это направление, всё пытаются запихнуть людей к себе в облака...
… в нашем понимании (согласно трём статьям) у нас сейчас всего-навсего небольшой датацентр с двумя хостами и виртуальными машинами на нём.
Если попытаться "удивить" заказчика, что для всеобщего счастья и чтобы удовлетворить модели трафика типа east-west, ему понадобится вот прямо сейчас потратить ещё много денег на дополнительное оборудование, то он мягко говоря вас не поймёт. И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.
И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.
В самом крайнем абзаце этой статьи, я прямо написал — что у нас ещё есть пара 3850, которые как раз и будут решать проблему роста трафика внутри датацентра, чтобы в итоге получить такую картинку
Но об этом будет в следующей статье :)
И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.
Да, для маленького офиса. Не для ЦОД. И пределы её заканчиваются на LACP серверов или утыкаются в PPS и проц соответственно. Вместо того что бы коммутировать внутрисетевой трафик на wirespeed на железке специально для этого предназначенной.
И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.И будет не прав в корне. Понятие «Пока» очень эфемерное. Пока нет и тут бац и уже есть. Но трогать ничего нельзя ибо продакшен, а масштабировать тоже нельзя ибо изначально не заложено масштабирование. Сразу продумать адресные планы, технологии и унести л3 на железо специально для этого предназначенное, позволит избежать мегатонны головной боли в дальнейшем. Благо, л3 коммутаторы (не обязательно cisco), сейчас не так дороги.
Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хоста.
Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?
Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больно, и тем более не представляет из себя никакой головной боли (даже при необходимости делать это уже в работающем проекте на продакшене), а только сплошное удовольствие для настоящего сетевика (пишу совершенно без сарказма), и это будет показано наглядно, но в следующий раз ;)
Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хостаДа и это мгновенно становится весьма таки накладно при возросшем трафике обрабатываемым процессором.
Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?1. Это не ЦОД. 2. Разница между l2 и l3 управляемым коммумтатором в данном случае окупается необходимостью утилизации ресурсов CPU на свичинг трафика.
Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больнона рабочей инфраструктуре унести л3 на другое железо — ну да, ну да. И это вместо того что бы _Сразу_ сделать все правильно.
на рабочей инфраструктуре унести л3 на другое железо — ну да, ну да. И это вместо того что бы Сразу сделать все правильно.
На рабочей инфраструктуре именно унесём L3 и именно на железо ;)))
Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.
В общем считайте, что следующая статья будет именно про такой случай :))
В котором будет показано не только как надо было строить сеть правильно изначально, но и что делать то, если она была таки построена немного примитивно и без учёта активного роста сетевых абонентов.
Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.Ну ко, тогда статья под дивизом «как нельзя проектировать сеть что бы потом не переделывать».
В некоторых проектах используется бесплатная LTS версия 1.1.8, для некоторых проектов образ билдится самостоятельно.
Для тестового стенда вполне подойдёт rolling release, а если в процессе развёртывания этого стенда удастся протестировать такой образ в работе под нагрузкой, работе с VRRP, BGP, WLB, и т.п — т.е. с тем, с чем придётся работать в дальнейшем, то не вижу особых препятствий использовать его на продакшене.
LTS образы по хорошему тоже надо тестировать, мало ли чего найдётся и у них.
Создание отказоустойчивой ИТ инфраструктуры. Часть 3. Организация маршрутизации на роутерах VyOS