В своё время и виртуализация считалась чем-то противоестественным (только одна железка на один веб-сервер и никак иначе), да и докер поначалу только разрабами использовался :)
PBR применяется примерно в таком же виде года этак с 2013 (на 3560, 3750...), но видимо из вредности и ненужности работает на них до сих пор (там правда имеется ещё куча всяких политик, но это как раз и есть работа для PBR).
В статье было отдельно отмечено, что ещё имеется вариант с настройкой обычной маршрутизации между 3850 и VyOS — можно, конечно, рассмотреть и такую настройку. Альтернатива (тем более с т.з классической маршрутизации) — это всегда хорошо :)
PBR в данном случае используется в силу своей большей гибкости, по сравнению с традиционным destination routing, так как позволяет настроить практически любые пути прохождения трафика от источника к назначению — по адресу источника или назначения, по сети источника или назначения, по протоколу, по порту и т.п. Также можно включить QoS для такого трафика. Сейчас конечно все эти возможности не используются по полной, но в будущем кто знает.
В плане потребления cpu это теперь не так, практически никакой разницы в утилизации процессора до включения pbr и после не заметно.
Еслии включить ещё acl для трафика, может что и подрастёт, но не проверял.
Хотя в своё время, помню, были проблемы — на cisco 3560 сталкивался с увеличением утилизации cpu
Ну так то да, хотя предпочитаю использовать микротики для офисов — тут они наверное вне конкуренции точно, и главное GUI, с которым любой виндовс админ справится.
В своё время в плане простоты работы, ещё нравилось решение от M$ — TMG 2010, очень хорошая вещь была, особенно для публикации сервисов от M$ (правда без CLI), жалко что перестали его поддерживать, да и вообще завалили полностью это направление, всё пытаются запихнуть людей к себе в облака...
:)))
Ну да, асисяй это конечно нужный товарищ в хозяйстве, но пока рано :))
Чтобы сделать такую статью со сравнительным анализом, надо сесть, и проанализировать эти три решения — как устанавливать, как настраивать, степень сложности, интуитивности использования графической оболочки если есть, и т.п.
И всё равно найдутся или спорщики, или недовольные, так как сравнение как ни крути, будет субъективным в какой-то степени.
Поэтому совет простой — выбирайте то, с чем уже работали,
но исходя из настоящих и будущих требований по проекту и соотвествия им возможностей самого решения, чтобы потом не было мучительно больно и трудно всё или делать по новой, или ставить костыли.
Лично предпочитаю делать всё на Cisco, но даже у них не всегда есть то, что нужно, а уж слово "дешевле" — это явно не про них ;)))
Тут не поспоришь, графическая управлялка конечно же во многих случаях — это аргумент, особенно когда нет под рукой более-менее квалифицированного админа, или просто нет времени разбираться с CLI.
Но с другой стороны, работая с CLI, приходится влезать во внутренности устройства, иначе без знания команд элементарно ничего не настроить, особенно какие-то сложные конфиги.
GUI позволяет это делать в некоторых случаях даже методом тыка или просто запустив мастер настроек — тут да, простота может быть решающим аргументом, но до определённых пределов.
В некоторых проектах используется бесплатная LTS версия 1.1.8, для некоторых проектов образ билдится самостоятельно.
Для тестового стенда вполне подойдёт rolling release, а если в процессе развёртывания этого стенда удастся протестировать такой образ в работе под нагрузкой, работе с VRRP, BGP, WLB, и т.п — т.е. с тем, с чем придётся работать в дальнейшем, то не вижу особых препятствий использовать его на продакшене.
LTS образы по хорошему тоже надо тестировать, мало ли чего найдётся и у них.
Не согласен, статья под девизом " как можно спроектировать сеть "на минималках", и чтобы потом можно было бы её проапгрейдить без простоев" ;)))
Никто полностью переделывать эту сеть в дальнейшем не собирается, это как-то нерационально. Ну подождите пару недель ещё (может и быстрее), и сами увидите
на рабочей инфраструктуре унести л3 на другое железо — ну да, ну да. И это вместо того что бы Сразу сделать все правильно.
На рабочей инфраструктуре именно унесём L3 и именно на железо ;)))
Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.
В общем считайте, что следующая статья будет именно про такой случай :))
В котором будет показано не только как надо было строить сеть правильно изначально, но и что делать то, если она была таки построена немного примитивно и без учёта активного роста сетевых абонентов.
Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хоста.
Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?
Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больно, и тем более не представляет из себя никакой головной боли (даже при необходимости делать это уже в работающем проекте на продакшене), а только сплошное удовольствие для настоящего сетевика (пишу совершенно без сарказма), и это будет показано наглядно, но в следующий раз ;)
Совершенно верно, если работал с каким-либо из продуктов, типа Juniper (JunOS), Ubiquitu (EdgeOS ) и Vyatta, то работать с VyOS — это как семечки грызть :)
Ну и если говорить в общем, то принципы работы с VyOS и Cisco ASA примерно похожи: тот же режим конфигурирования устройства (любимый conf t), те же именованные группы правил применяемые к интерфейсу, и т.п. Команды конечно разные, это да :)
… в нашем понимании (согласно трём статьям) у нас сейчас всего-навсего небольшой датацентр с двумя хостами и виртуальными машинами на нём.
Если попытаться "удивить" заказчика, что для всеобщего счастья и чтобы удовлетворить модели трафика типа east-west, ему понадобится вот прямо сейчас потратить ещё много денег на дополнительное оборудование, то он мягко говоря вас не поймёт. И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.
И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.
В самом крайнем абзаце этой статьи, я прямо написал — что у нас ещё есть пара 3850, которые как раз и будут решать проблему роста трафика внутри датацентра, чтобы в итоге получить такую картинку
Но об этом будет в следующей статье :)
Спасибо за комментарий, самое главное — решение рабочее :) и работает 24x7x365
VyOS используются давно, и полностью удовлетворяют всем требованиям, а главное надёжны и предсказуемы.
Что касается специалистов… Поверьте, порог вхождения не очень высок, особенно если человек уже работал с Juniper, или даже Cisco. Единственный недостаток, если с точки зрения не слишком сетевого админа, то это отсутствие GUI, но то в общем такое…
Когда я писал про кластерный LVM, то не зря отметил, что "oVirt использует что-то наподобие кластерного LVM", т.е. lvmlockd в явном виде не используется, и сам внутренний механизм процесса снятия снэпшотов в документации не описан.
Вывод lvscan
[root@host2 ~]# lvscan | grep bb69829ca80
WARNING: lvmlockd process is not running.
Reading without shared global lock.
ACTIVE '/dev/2639f482-7c6b-48db-bddb-9bae82c7660b/a823137a-6843-4563-b342-bb69829ca807' [1.00 GiB] inherit
Reading VG lvm_storage1_backup1_vg without a lock.
[root@host2 ~]# lvscan | grep a2fce6bb0b84
WARNING: lvmlockd process is not running.
Reading without shared global lock.
ACTIVE '/dev/2639f482-7c6b-48db-bddb-9bae82c7660b/d935fe8f-8dc9-479a-a716-a2fce6bb0b84' [11.00 GiB] inherit
Reading VG lvm_storage1_backup1_vg without a lock.
На нодах овирта примерно тоже самое с дисками для ВМ.
Диски sdb и sdi (не показан в выводе команды) подключены через FC и также объединены через multipath:
И также при отказе одного из узлов, ВМ благополучно перезапускаются на втором хосте, куда через LVM монтируются образы их дисков.
Правда не понял почему снэпшоты делать нельзя в proxmox — в овирте снэпшоты спокойно делаются, неважно какой диск у ВМ, в формате qcow2 или RAW.
Видно сетевика — нет и всё :)
В своё время и виртуализация считалась чем-то противоестественным (только одна железка на один веб-сервер и никак иначе), да и докер поначалу только разрабами использовался :)
В официальной документации никаких противопоказаний к такому использованию PBR нет
PBR применяется примерно в таком же виде года этак с 2013 (на 3560, 3750...), но видимо из вредности и ненужности работает на них до сих пор (там правда имеется ещё куча всяких политик, но это как раз и есть работа для PBR).
В статье было отдельно отмечено, что ещё имеется вариант с настройкой обычной маршрутизации между 3850 и VyOS — можно, конечно, рассмотреть и такую настройку. Альтернатива (тем более с т.з классической маршрутизации) — это всегда хорошо :)
PBR в данном случае используется в силу своей большей гибкости, по сравнению с традиционным destination routing, так как позволяет настроить практически любые пути прохождения трафика от источника к назначению — по адресу источника или назначения, по сети источника или назначения, по протоколу, по порту и т.п. Также можно включить QoS для такого трафика. Сейчас конечно все эти возможности не используются по полной, но в будущем кто знает.
В плане потребления cpu это теперь не так, практически никакой разницы в утилизации процессора до включения pbr и после не заметно.
Еслии включить ещё acl для трафика, может что и подрастёт, но не проверял.
Хотя в своё время, помню, были проблемы — на cisco 3560 сталкивался с увеличением утилизации cpu
Если так интересно в чем отличия, то можете сами почитать
В статье использовалась конкретная модель — Cisco WS-C2960RX-48FPS-L
Умиляет конечно — у завхоза (а особенно у каптёра (кто знает, тот поймёт)) можно ещё и не то найти :))
А в чём проблема с pbr?
Ну так то да, хотя предпочитаю использовать микротики для офисов — тут они наверное вне конкуренции точно, и главное GUI, с которым любой виндовс админ справится.
В своё время в плане простоты работы, ещё нравилось решение от M$ — TMG 2010, очень хорошая вещь была, особенно для публикации сервисов от M$ (правда без CLI), жалко что перестали его поддерживать, да и вообще завалили полностью это направление, всё пытаются запихнуть людей к себе в облака...
:)))
Ну да, асисяй это конечно нужный товарищ в хозяйстве, но пока рано :))
Чтобы сделать такую статью со сравнительным анализом, надо сесть, и проанализировать эти три решения — как устанавливать, как настраивать, степень сложности, интуитивности использования графической оболочки если есть, и т.п.
И всё равно найдутся или спорщики, или недовольные, так как сравнение как ни крути, будет субъективным в какой-то степени.
Поэтому совет простой — выбирайте то, с чем уже работали,
но исходя из настоящих и будущих требований по проекту и соотвествия им возможностей самого решения, чтобы потом не было мучительно больно и трудно всё или делать по новой, или ставить костыли.
Лично предпочитаю делать всё на Cisco, но даже у них не всегда есть то, что нужно, а уж слово "дешевле" — это явно не про них ;)))
Тут не поспоришь, графическая управлялка конечно же во многих случаях — это аргумент, особенно когда нет под рукой более-менее квалифицированного админа, или просто нет времени разбираться с CLI.
Но с другой стороны, работая с CLI, приходится влезать во внутренности устройства, иначе без знания команд элементарно ничего не настроить, особенно какие-то сложные конфиги.
GUI позволяет это делать в некоторых случаях даже методом тыка или просто запустив мастер настроек — тут да, простота может быть решающим аргументом, но до определённых пределов.
в двух словах — это проверенное и надёжное решение
В некоторых проектах используется бесплатная LTS версия 1.1.8, для некоторых проектов образ билдится самостоятельно.
Для тестового стенда вполне подойдёт rolling release, а если в процессе развёртывания этого стенда удастся протестировать такой образ в работе под нагрузкой, работе с VRRP, BGP, WLB, и т.п — т.е. с тем, с чем придётся работать в дальнейшем, то не вижу особых препятствий использовать его на продакшене.
LTS образы по хорошему тоже надо тестировать, мало ли чего найдётся и у них.
Не согласен, статья под девизом " как можно спроектировать сеть "на минималках", и чтобы потом можно было бы её проапгрейдить без простоев" ;)))
Никто полностью переделывать эту сеть в дальнейшем не собирается, это как-то нерационально. Ну подождите пару недель ещё (может и быстрее), и сами увидите
На рабочей инфраструктуре именно унесём L3 и именно на железо ;)))
Ну вот так именно и бывает в жизни — создают изначально одни, потом заказчик говорит что он сам умеет и все свободны, потом оказывается что не очень то и умеет, и приходится браться за дело уже другим и перепроектировать всю сеть без какого-либо перерыва в работе продакшена.
В общем считайте, что следующая статья будет именно про такой случай :))
В котором будет показано не только как надо было строить сеть правильно изначально, но и что делать то, если она была таки построена немного примитивно и без учёта активного роста сетевых абонентов.
Ну почему же сразу кривая то… Эта архитектура вполне рабочая (особенно при ограниченном бюджете, иначе смысл было её рисовать), и если вдруг не хватает производительности при прокачке внутреннего трафика, то так как у нас виртуальные роутеры, можно для них добавить и процессоров и памяти, в конце концов даже прокинуть напрямую физические сетевые карты с хоста.
Эта архитектура актуальна для небольшого ЦОДа, и если не предполагается больших потоков внутреннего трафика, то зачем изначально огород городить, и разводить заказчика на деньги и усложнение инфраструктуры, если например в дальнейшем её будет обслуживать он сам и ему лишние сложности и тем более затраты ни к чему?
Поверьте, внедрение коммутаторов L3 именно в предложенную инфраструктуру -это совсем несложно и не больно, и тем более не представляет из себя никакой головной боли (даже при необходимости делать это уже в работающем проекте на продакшене), а только сплошное удовольствие для настоящего сетевика (пишу совершенно без сарказма), и это будет показано наглядно, но в следующий раз ;)
Совершенно верно, если работал с каким-либо из продуктов, типа Juniper (JunOS), Ubiquitu (EdgeOS ) и Vyatta, то работать с VyOS — это как семечки грызть :)
Ну и если говорить в общем, то принципы работы с VyOS и Cisco ASA примерно похожи: тот же режим конфигурирования устройства (любимый conf t), те же именованные группы правил применяемые к интерфейсу, и т.п. Команды конечно разные, это да :)
… в нашем понимании (согласно трём статьям) у нас сейчас всего-навсего небольшой датацентр с двумя хостами и виртуальными машинами на нём.
Если попытаться "удивить" заказчика, что для всеобщего счастья и чтобы удовлетворить модели трафика типа east-west, ему понадобится вот прямо сейчас потратить ещё много денег на дополнительное оборудование, то он мягко говоря вас не поймёт. И будет в чём-то прав, так как острой необходимости в таком оборудовании на начальном этапе запуска проекта пока нет.
И да, эта архитектура с внутрисетевым трафиком на бордерах — вполне жизеспособна, но конечно же до определённых пределов.
В самом крайнем абзаце этой статьи, я прямо написал — что у нас ещё есть пара 3850, которые как раз и будут решать проблему роста трафика внутри датацентра, чтобы в итоге получить такую картинку
Но об этом будет в следующей статье :)
Спасибо за комментарий, самое главное — решение рабочее :) и работает 24x7x365
VyOS используются давно, и полностью удовлетворяют всем требованиям, а главное надёжны и предсказуемы.
Что касается специалистов… Поверьте, порог вхождения не очень высок, особенно если человек уже работал с Juniper, или даже Cisco. Единственный недостаток, если с точки зрения не слишком сетевого админа, то это отсутствие GUI, но то в общем такое…
Наверное не очень понял вопроса, поэтому немного опишу механику создания снэпшотов в овирте.
Итак, имеется рабочая ВМ с диском размером 11 Гб
Делаем снэпшот для этой ВМ из админпортала.
Когда я писал про кластерный LVM, то не зря отметил, что "oVirt использует что-то наподобие кластерного LVM", т.е. lvmlockd в явном виде не используется, и сам внутренний механизм процесса снятия снэпшотов в документации не описан.
На нодах овирта примерно тоже самое с дисками для ВМ.
Диски sdb и sdi (не показан в выводе команды) подключены через FC и также объединены через multipath:
И также при отказе одного из узлов, ВМ благополучно перезапускаются на втором хосте, куда через LVM монтируются образы их дисков.
Правда не понял почему снэпшоты делать нельзя в proxmox — в овирте снэпшоты спокойно делаются, неважно какой диск у ВМ, в формате qcow2 или RAW.
Овирт делает для любого диска (тонкого, толстого, снэпшота) свой отдельный lvm на хостах кластера.
спасибо :)
думаю недели через 2-3 будет продолжение