Cisco CSR 1000v: Обзор возможностей. Часть 1
Сегодня мы хотим немного коснуться темы маршрутизации в сетях провайдеров облачных услуг и заодно рассказать вам почему для нас оказался очень интересным относительно новый продукт хорошо известной компании Cisco Systems, а именно — Cloud Services Router 1000v (CSR 1000v).
Перед самым стартом проекта определили для себя оптимальный набор инструментов и технических решений на основе множественных тестов по программе и методики испытаний (ПиМИ) для сетевого оборудования (внутренний документ для тестирования на базе центра компетенций), которые позволили бы нам предоставлять качественный сервис для своих клиентов.
Важными факторами при выборе того или иного решения, помимо цены, также, значилось качество, то есть предсказуемость работы программных и аппаратных компонентов решения и, при необходимости, доступность технической поддержки производителя, на ряду с высоким уровнем надёжности и масштабируемости. Совокупность этих критериев могут удовлетворить немногие решения, имеющие отказоустойчивую архитектуру, дублированные аппаратные компоненты и богатый набор возможностей. Однако, все эти решения объединяет немалая стоимость, что на начальном этапе развития нашего проекта было серьёзным минусом. В свою очередь, специфика проекта заставила нас задуматься о возможности использования под задачи маршрутизации уже имеющихся вычислительных ресурсов.
Не использовать ли нам имеющиеся у нас серверные мощности для размещения маршрутизатора в виртуальной среде? Тем более, облачная среда на базе продуктов от VMware обладает необходимым уровнем отказоустойчивости, надёжности и масштабируемости. В итоге, получилось бы немного сэкономить на аппаратном обеспечении, заплатив только за необходимое ПО.
Cisco Premier Partner
Являясь партнёром компании Cisco уровня Premier, нам требовалось обязательно протестировать функционал Cisco CSR 1000v, который занимает своё законное место в портфолио решений для Enterprise сегмента.
Наше знакомство с ним началось с подробного изучения функциональности, политики лицензирования и 60-дневного пробного периода. Стоит отметить очень сильное сходство CSR 1000v с линейкой маршрутизаторов ISR в плане интерфейса программного обеспечения IOS и модели предоставления технологических вариантов исполнения.
Лицензирование.
CSR 1000v доступен в 4-х «редакциях»: IP Base, Security, AppX, AX.
Таблица с описанием различий между редакциями
Как можно заметить, распределение программных возможностей по технологическим «пакетам» схоже с аналогичным в продуктовой линейке маршрутизаторов ISR (Integrated Services Routers). Так что, для тех, кто сталкивался с маршрутизаторами ISR второго поколения (G2), данная схема лицензирования не будет в новинку.
Также, стоит отметить, что так как это маршрутизатор для cloud infrastructure, где производительность каналов связи и специфика применения может быть разной, схема лицензирования дополнилась максимальной пропускной способностью. Для каждого технологического пакета доступен выбор пропускной способности в 10, 50, 100, 250, 500 Мбит/с, а также 1, 2.5, 5 и 10 Гбит/с. Обратите внимание, что данные числа обозначают суммарную пропускную способность маршрутизатора, где учитывается трафик на всех интерфейсах маршрутизатора и для каждого интерфейса учитывается отдельно входящий и исходящий трафик.
Другими словами, лицензировав 1 Гбит/с пропускной способности вы сможете обеспечить либо 500 Мбит/с дуплекса на одном интерфейсе, либо, например, обеспечить одновременно 900 Мбит/с исходящего трафика на интерфейсе при 100 Мбит/с входящего. Либо будет любая другая комбинация, но в сумме за лицензированную пропускную способность выйти не получится.
Системные требования
Очень важным аспектом при выборе виртуального маршрутизатора была корректное функционирование в среде VMware. К счастью, Cisco и VMware являются давними друзьями и в списке совместимости удалось найти не только гипервизор vSphere, но и Microsoft Hyper-V, Citrix XenServer и KVM на базе Red Hat или Ubuntu. Отдельно стоит отметить тот факт, что также официально поддерживается работа CSR в публичных облачных сервисах Amazon Web Services и Microsoft Azure. В нашем случае, запускать его планировалось на гипервизоре vSphere 6.
Отказоустойчивость при таком сценарии можно обеспечить несколькими вариантами: High Availability (HA) или Fault Tolerance (FT). На всякий случай напомню, что отличаются эти варианты временем простоя при возникновении неисправности хоста виртуализации: HA — машина перезапустится на исправном хосте (при этом есть риски потерять изменения в конфигурации маршрутизатора, если она не была вовремя сохранена, и достаточно продолжительное время восстановления сервиса, т.к. все мы знаем сколько может загружаться IOS), FT — переходит в активное состояние теневая копия ВМ, запущенная на другом хосте (при этом варианте сбоев в работе сервиса не возникает). Протестировав оба варианта, пришли к выводу, что решение CSR 1000v в полной мере удовлетворяет требованиям и отказоустойчивости.
Что касается требований к вычислительным ресурсам, здесь всё зависит от выбранного технологического пакета и лицензированной пропускной способности. Минимальным рекомендуемым порогом является 1 vCPU / 4 ГБ оперативной памяти, места на диске требуется не более 8 ГБ. Такие характеристики виртуальной машины для CSR позволят ему работать на скоростях до 1 Гбит/с включительно (правда, с небольшой оговоркой касательно редакции AX, где уже потребуется больше ресурсов). Далее увеличиваем ресурсы согласно рекомендациям из документации.
Таким образом, ресурсов для него у нас тоже было достаточно. Тем более пропускная способность в 1 Гбит/с, что равняется по сути 500 Мбит/с дуплекса на начальном этапе могла удовлетворить все наши потребности.
Нюансы работы
При использовании CSR 1000v обязательно нужно учитывать тот факт, что это не отдельное устройство со своей оптимизированной аппаратной базой, независимое от среды виртуализации, используемой в облаке и особенностей реализации того или иного функционала, а это по сути такая же виртуальная машина, как и все остальные, работающие на сервере, у которой есть свои требования к вычислительным ресурсам, к настройкам сети, физическому подключению к сети передачи данных и прочему. В процессе опытной эксплуатации маршрутизатора CSR 1000v нами были выделены следующие моменты:
1. Рекомендуется выделять отдельные физические порты на сервере под виртуальные коммутаторы для CSR, чтобы избежать возможные проблемы с пропускной способностью, особенно, в случае использования SDS (Software-defined storage), когда между серверными узлами наблюдается немалое количество трафика при создании новой ВМ в момент заказа новой услуги. Также, проблемы могут наблюдаться в момент создания резервных копий при использовании сетевых адаптеров в режиме «общего доступа».
2. Необходимо резервировать вычислительные ресурсы (процессор и оперативную память) в необходимом количестве средствами гипервизора под нужны CSR для его корректной и эффективной работы, чтобы исключить проблемы с производительностью сети, вызванные нехваткой ресурсов.
3. Следует очень внимательно относиться к настройкам параметров безопасности для групп портов (Port Group) и виртуальных коммутаторов (в терминологии VMware). Речь идёт о параметрах «MAC address changes», «Forged transmissions» и «Promiscuous mode». Для работы, например, такого функционала как HSRP / VRRP и MPLS приходилось «включать» (переводить в значение «Accept») Promiscuous Mode для портовой группы, в которой находился соответствующий интерфейс CSR.
P.S. Как соберём хотя бы 20 000 просмотров, напишем вторую часть с практикой использования :-)
Комментарии (1)
10 апреля 2017 в 15:27 (комментарий был изменён)
+4↑
↓
обязательно напишите вторую часть, без всякого шантажа про 20к просмотров — это детство какое-то. и отразите следующие моменты:
— как победить hsrp/vrrp в esxi и в kvm (просто открутить безопасность — не помогает);
— как победить interchassis high availability;
— про то как csr начинает терять пакеты и вносить delay в трафик при перемещении виртуальной машины между хостами;
— ограничения при использовании в IWAN;
