Некоторые рассуждения по концептуальной сложности импортозамещения виртуализации, в части сети
Столкнулся с проблемой в понимании ряда концепций у вновь приходящих коллег, особенно в части импортозамещения — решил написать статью. Я не уверен, что она нужна на Хабре, но я ее потом переработаю по результатам. Это попытка номер 1 — разобраться в том, что под капотом у сетевой части импортозамещения.
Для лиги лени: ничего сложного в переходе нет, надо всего лишь построить рядом еще одну инфраструктуру. Причем сразу на новых физических принципах. И прочитать несколько книг, все не на русском.
Исторический экскурс и давно забытое.
Совсем недавно — лет так 20 назад — (2004 год) в сегменте x86 не было современной массовой виртуализации. Виртуализация была давно, но рядом с мейнфреймами, выносными терминалами и телетайпами. VMware ESX 2.0 уже вышел, и даже иногда где-то стоял. В сегменте малого и среднего бизнеса было мало денег, мало специалистов, и, ввиду сложностей «в целом» — функции compute \ storage \ switch \ route — выполняли разные устройства, в очень простой — плоской, зачастую без VLAN — сети. И никакой виртуализации.
Технологии росли, плотность (на хост) и проникновение виртуализации росли. В 2008 году вышел Hyper-V, и виртуализация пошла в SMB. В то же время (2006–2008) подтянулись первые домашние \ SMB дешевые массовые роутеры, началась легкая путаница среди начинающих, какое устройство что делает.
Технологии, топологии и скорости росли, появились GENEVE, VXLAN и NVGRE. Стало можно и нужно использовать больше 1023 VLAN. Общие принципы оставались те же — switch отдельно, route отдельно, хотите программный роутер в среде виртуализации — не забывайте оплатить за ASAv или Router 1000V или что сами хотите (ISA 2004–2006 — TMG), но это будет или отдельно оплачиваемая функция, как бы глубоко она не интегрировалась, или отдельный аплайнс \ виртуалка.
Опенсорсные решения в вариациях (Openstack, Keystack, Openvcloud, Cloudstack, OpenNebula, devstack) росли с другой стороны — из запросов уже появившихся облаков, государственных организаций (Openstack == NASA). Заказчики уже знали, что и как они хотели, и получили решение, включающее в себя управление и разделение функционала для масштабов облачной инфраструктуры. Решение масштаба Open* изначально содержит в себе избыточный функционал для SMB, и из-за этого избыточную сложность по сравнению с решениями масштаба Hyper-V Failover Cluster, VMware Robo, VMware vSphere Essential или Huawei FusionCube for ROBO
Пока не было сигнала «все бегом в импортозамещение» ситуация была привычной — на рынке сосуществовали MS Hyper-V, VMware vSphere, и местами Nutanix. Кто-то жил на KVM или даже на Proxmox или VirtualBox. Иногда на такую инфраструктуру были тем или иным способом намазаны контейнеры. Open* жил там, где ему и положено — в инфраструктурах облачных провайдеров, телеком операторов (там, зачастую, был и есть вендорский), или просто больших фирм, имевших свой штат разработки и поддержки. У кого-то одновременно жил и VMware Cloud Director, Azure Stack, и так далее. Это не мешало внутренним обсуждениям, у кого больше денег для заноса в Gartner.
Новые времена.
Два года назад все изменилось, теперь решения на базе Open* и чего-то своего, но с новыми наклейками, зачастую на форках продуктов времен мамонтов, — года из 2014, давно уже не просто засохших, но и окаменевших,- пошли на рынок. Тут даже я и впал в безудержное удивление. Дело не в том, что под капотом того или иного решения. Дело в том, что на 20+ как-бы российских продуктов приходится бросить все и начинать смотреть не готовое изделие в сборке, а на то, из чего же его собирали. И хорошо, если это собрано из чего-то, а не свое целиком.
Проблемы с тем, что собрано из СПО — как-то решаемы, можно полистать старые форумы, поднять машину времени, как-то спросить кто-то помнит или писал. Можно даже поискать код. Есть какие-то шансы разобраться и решить внезапно возникшую проблему (ВВП). Проблемы начинаются там, где написано «самими» или переписано самими ровно настолько, чтобы починить «быстро по рецептам» было уже нельзя. Потому что у переписавших — нет специалистов 2–3 линии, нет комьюнити и нет какого-то живого паблик форума. Нет даже гарантии, что тот разработчик, что писал вот этот модуль, еще работает в той же организации и можно как-то до него достучаться в разумные сроки.
С чем придется столкнуться и что можно начинать читать уже сейчас.
Планирование.
В первую очередь начать планирование сетей — что у вас будет и где, где будут FW и какие. Нужно проследить, чтобы литературу по сетям (ниже) прочитали не только ваши сетевики, но и девопсы. В обязательном порядке перечитать ICND и сети для самых маленьких.
Стенды: PackStack, MicroStac: читать тут
Linux bridge. Это база, вместе с virtio tap drive, switchdev, Netfilter. Статья по теме — An introduction to Linux bridging commands and features
virtio-networking — читать рядом.
IOMMU как проброс сетевых карт. Читать начиная отсюда.
Один из вариантов разделения функций — SR-IOV, читать тут
Следующим шагом будет овес — Open vSwitch: Self-service networks.Читать отсюда и пока не надоест.
После этого придется зажать нос, и нырнуть с головой в развертывание, потому что дальше начинается выбор между теплым и мягким:
vDPA (virtio data path acceleration) kernel framework — это еще одна прокладка между гостевой VM и физикой, но с ней вроде должно что-то быть быстрее. Читать тут.
Она идет как бонус к овсу (Open vSwitch) — OVS-DPDK, где DPDK это Data Plane Development Kit, про который читать надо отдельно
Следующим большим шагом вперед будет Virtualized Network Functions
Сначала придется читать про OpenVIM, потом про OSM Network Service.
Если вы полезете в контейнеры, то начинайте читать про Magnum — is an OpenStack API service developed by the OpenStack Containers Team making container orchestration engines (COE) such as Docker Swarm and Kubernetes available as first class resources in OpenStack.
После этого, если вам недостаточно ML2/OVS — нужно начинать читать про ML2/OVN (Open Virtual Network (OVN)) тут и OVN IC — the Open Virtual Network interconnection controller. Заполировать чтением Tungsten Fabric тут и там.
Можно совсем сломать голову — читая Openstack Ansible OVN Clustering, и OpenFlow — software defined networking (SDN).
На следующем шаге — переходя к запуске пре-пре-стенда — можно ознакомиться с вложенной (Nested) виртуализацией, и заодно с проектом kolla-ansible-aio-configs yoga-centos
Или, можно не глядя махнуть шашкой и раскатать все вконтейнерах — OpenStack-Helm.
Рекомендуемая литература
OpenStack Cloud Computing Cookbook
OpenStack in Action: Bumgardner, Cody
OpenStack for Architects: Solberg, Michael, Silverman, Ben
Back in USSR (послесловие)
Последние лет 10 наблюдаю борьбу двух мнений в интернете. Первое — от нормальных, современных людей, которые читают что сейчас акутально в журнале Птюч — про лучшую в мире советскую сгущенку, лучшее в мире советское мороженое и то, как в СССР пенопласт делали из молочной пены, можно было детей кормить. Второе — от замшелых дедов и иных унылых личностей, которые зачем-то читают мемуары Чертока, Каманина или Карцева. Где пишут, как в СССР за бюджет ожесточенно дрались Челомей (Протон — ОКБ-456) и Глушко (Энергия НИИ-88 — ОКБ-1), как поругались Кузнецов (НИИ-10) и Пилюгин (НИИ-885). Как между собой воевали Харьков (КП ХКБМ), Уралвагонзавод и Кировский завод. И сколько это стоило СССР — иметь на вооружении формально 10+ типов танков и поставлять 10+ разных комплектов запчастей от трех разных заводов.
К чему это?
К тому, что опенстек сам по себе конструктор разных версий, и его компоненты — встроенные и отдельно разворачиваемые — тоже тащат за собой зависимости и версионности. В РФ сейчас около 20 проектов «импортозамещения», и все заявляют о почти достигнутой доступности 99.95% функции Vsphere, не уточняя по какому критерию. В результате специалист, вынужденный нырять в это болото, будет вынужден тратить большую часть времени на попытку разобраться в искусственно суженном наборе компонентов самостоятельно, причем из-за требований ФСТЭК, особенно приказа 17, и требований по КИИ — к устаревшему набору компонентов. Причем, иностранный опыт в виде знакомства с хотя бы Scale Computing — не просто игнорируется, а порицается (минусится) на хабре как избыточно сложный для самостоятельного чтения, а давно висящие в воздухе вопросы про уровень сообщества — убираются в чулан.
