Некоторые вопросы коммутации в ЦОД (политики, BPDU, physical vs vswitch)

Когда придумывали виртуализацию серверов, то наверняка задумались над таким вопросом – а как обеспечить взаимодействие между двумя виртуальными машинами в рамках одного физического сервера? Естественным и логичным получился ответ на этот вопрос – нужно организовать каналы связи между виртуальными машинами внутри гипервизора. А так как на данном этапе стандартом де-факто для объединения серверов в сеть является Ethernet, то и способ взаимодействия выбрали вполне предсказуемый – через виртуальный Ethernet коммутатор. Таким образом, для гостевых операционных систем создается полная иллюзия включения в сеть.

Однако такого рода нововведение приводит к размытию границ между сетью и серверами. Как следствие, ряд функций, которые в “довиртуализационной” модели ЦОД однозначно возлагались на сетевое оборудование (коммутаторы) сейчас уже не могут с той же степенью однозначности быть на него возложены. В этой части хотелось бы обсудить следующие вопросы

• где и как корректно обрабатывать ситуацию, когда гостевая операционная система генерирует BPDU сообщение
• где и как должны применяться политики QoS и списки доступа для виртуальных машин
• можно ли отказаться от дополнительного виртуального коммутатора и “вернуть все как было” – чтобы весь сетевой трафик, даже между двумя VM в пределах одного физического сервера, проходил через коммутатор ЦОД

Начнем обсуждение вопросов по порядку – с вопроса о BPDU.
Чтобы понимать суть проблемы, нужно быть знакомым с протоколом Spanning Tree. Этот протокол позволяет построить беспетлевую L2 топологию, основываясь на информационных сообщениях, которыми обмениваются между собой участники процесса STP – эти сообщения и называются BPDU. Причем, под участниками процесса чаще всего понимают именно коммутаторы. Если же в обмен сообщениями попытается вклиниться, скажем, сервер, то, построенная в результате топология может быть неоптимальной — из использования будут исключены высокоскоростные каналы связи.

Конечно же, производители сетевого оборудования придумали способы борьбы с таким поведением. К ним относятся BPDU Filter и BPDU Guard. Задача обоих механизмов – контролировать появление BPDU на тех портах, где они, по мнению сетевого администратора, появляться не должны. Отличаются они лишь способом реагирования на события. Как следует из названия, Filter – просто фильтрует сообщения BPDU, не давая им пройти дальше в сеть и изменить топологию. Guard – более сильный механизм, с его помощью можно заблокировать “вредоносный” порт на коммутаторе и предоставить администраторам сети и серверов разбираться между собой – по какой причине произошел инцидент и как его исправлять.

С моей точки зрения, BPDU Guard является более правильным механизмом для внедрения. Появление BPDU на том порту, где его быть не должно – это необычное событие, и оно может свидетельствовать, к примеру, о заражении сервера и попытке изменить топологию сети с целью направить часть трафика на его интерфейс. Следовательно, в таких случаях правильно будет вначале заблокировать порт, а уже затем разбираться – что послужило причиной. Проводя аналогию, фильтрация BPDU – это лечение симптомов, а BPDU Guard – это лечение, собственно, болезни.

Теперь вернемся в среду виртуализации. Как обсуждалось раньше, есть две точки, где возможно контролировать сообщения BPDU – виртуальный коммутатор или физический коммутатор, в который включен сервер. Рассмотрим эти варианты.

Начнем с физического коммутатора. Представим ситуацию, когда одна из виртуальных машин генерирует BPDU и на порту коммутатора срабатывает BPDU Guard.

Проблема этого сценария в том, что на одном физическом сервере работают несколько виртуальных машин. Причем, как правило, они разделяют между собой общий ресурс – сетевой интерфейс. В случае, если сетевой интерфейс будет заблокирован на коммутаторе, ни одна из виртуальных машин в пределах этого сервера не сможет общаться с внешним миром. Таким образом, могут пострадать невиновные. Хотя, если речь действительно идет о безопасности в ЦОД – то можно сказать, что все средства хороши.

Но, на самом деле, описанный сценарий – еще не самый страшный. Еще интереснее будет когда для “зловредной” виртуальной машины настроен механизм High Availability. Напомню, что этот механизм позволяет перезапустить виртуальную машину на другом сервере в случае отказа на основном сервере. Как правило, в средах виртуализации отказ детектируется с помощью так называемых heartbeat сообщений, которыми члены кластера обмениваются между собой. И, хорошей практикой считается иметь выделенные интерфейсы для этих сообщений. Однако, это не всегда так и вполне распространенным является вариант, когда одни и те же интерфейсы сервера используются для управления, для трафика виртуальных машин, а также для доступа к СХД (в случае использования iSCSI или NFS). Так вот, в самом плохом случае из-за того, что порты сервера будут заблокированы на коммутаторе после срабатывания BPDU Guard также перестанут поступать и heartbeat сообщения от этого сервера. Виртуальная машина “переедет” на другой сервер и … Да, вы правильно догадались, ситуация повторится и на нем.

В итоге, путешествуя по ЦОД, одна виртуальная машина выключит из работы один за другим все физические серверы.

Как видим, применение BPDU Guard на физическом коммутаторе может привести к достаточно неожиданным последствиям, причем, приятными их не назовешь. Можно ли как-то исправить эту ситуацию? Давайте рассмотрим второй вариант точки контроля BPDU — виртуальный коммутатор.

Очевидно, в этом случае BPDU Guard, работающий на виртуальном коммутаторе, исключит из работы не весь физический порт, а только виртуальный порт, через который проходит только трафик “зловредной” виртуальной машины. Таким образом, соседние виртуальные машины не пострадают, а источник проблем будет изолирован. В этом сценарии все хорошо, за исключением того факта, что на сегодняшний день никто из производителей сред виртуализации не включает функцию BPDU Guard в свои виртуальные коммутаторы.

Но ведь должен существовать какой-то выход? Пуcть неидеальный, но он есть. Если мы  хотим защитить свой ЦОД от нежелательных сообщений BPDU, то остается возможность использовать BPDU фильтрацию. Да, в этом случае мы не изолируем “зловредную” виртуальную машину от внешнего мира полностью. И стоит помнить о том, что STP все же придумывался не для того, чтобы просто фильтровать его сообщения. Может наступить ситуация, когда средствами серверов будет создана петля в ЦОД. В этой ситуации STP, конечно же, пригодился бы. Однако, если выбирать из двух зол (фильтровать или не фильтровать STP) меньшее, то, на мой взгляд, стоит все же выбрать BPDU фильтрацию. К тому же, практически все производители сред виртуализации умеют это делать.

Итак, с контролем за BPDU более или менее понятно (хотя, конечно же, любые комментарии и замечания только приветствуются). Перейдем к следующему вопросу, а именно — применение политик QoS и ACL к виртуальным машинам.

Думаю, ни одна сеть не обходится без правил, описывающих кому и к каким ресурсам можно обращаться. В самом простом случае, такие правила могут быть сформулированы и реализованы с помощью Access Control Lists — т.н. списков доступа, в которых фигурируют IP или MAC адреса источников и получателей трафика.

Однако не всегда бывает необходимо жестко запретить обмен трафиком. В случае виртуализации, через один Ethernet интерфейс сервера могут проходить пакеты от нескольких виртуальных машин. Как и с любым разделяемым ресурсом, чтобы “хватило всем”, необходимо регулировать доступ к нему — к примеру, ограничивая скорость обмена трафиком для определенных гостевых систем. Для этого могут применяться, к примеру, средства rate-limiting.

Как и в предыдущем случае, встает вопрос о точке применения такого рода политик, и вариантов опять два — физический или виртуальный коммутатор.

Начнем рассмотрение с физического коммутатора. Предположим, что на одном из портов у него работает политика, обеспечивающая rate-limit и ограничивающая доступ к ресурсам ЦОД для определенной виртуальной машины. Особых проблем с реализацией такого сценария нет — сейчас даже L2 коммутаторы доступа, как правило, умеют проводить анализ заголовков пакетов на L3 и производить rate-limit. Однако с приходом технологий виртуализации ЦОД перестал быть статичным — через некоторое время после настройки такой политики виртуальная машина может переместиться на другой физический сервер, включенный в другой коммутатор. Если ничего не предпринимать, то политика больше не будет актуальной — после перемещения виртуальная машина может использовать сетевой интерфейс без ограничений по скорости, а также иметь доступ к любым ресурсам ЦОД и за его пределами. Следовательно, появляется задача переместить политику вслед за виртуальной машиной. Теоретически, конечно, можно настроить политику на всех портах, где эта виртуальная машина может появиться. Однако на практике такой подход неприменим — слишком сложно поддерживать такую систему и вносить в нее изменения. Поэтому давайте обсудим возможность перемещения политики вслед за VM.

Для того, чтобы политика переместилась вслед за виртуальной машиной, прежде всего, необходимо отследить событие перемещения. К примеру, сигналом о таком событии может служить появление нового MAC адреса на порту коммутатора. После этого коммутатор, используя, к примеру, протокол RADIUS, может запросить у сервера политику, соответствующую этому MAC адресу и применить ее на своем порту. Этот подход вполне жизнеспособен, и даже больше — к его сильным сторонам можно отнести возможность централизованного хранения и редактирования политик. Для полноты картины и для упрощения жизни администраторам сюда можно добавить механизм взаимодействия между сервером RADIUS и управляющим сервером среды виртуализации. С помощью этого механизма можно синхронизировать базу MAC адресов виртуальных машин. В противном случае, администратору придется вручную создавать учетные записи VM на сервере RADIUS и назначать им политики.

Как видим, задача применения политик QoS и ACL имеет решение для случая с физическим коммутатором. Посмотрим, возможно ли ее решить с помощью виртуального коммутатора?

Начнем с описания возможностей. Что касается QoS, то здесь особых проблем нет. Как правило, все виртуальные коммутаторы умеют ограничивать скорость обмена трафиком для виртуальных машин. Со списками доступа — немного сложнее. Не у всех производителей на данном этапе виртуальный коммутатор умеет анализировать содержимое IP заголовков пакетов. Хотя, стоит отметить тот факт, что намечается явная тенденция в сторону использования единого продукта в этой области, причем корни его растут из среды Open Source. Речь идет об Open vSwitch.

А вот с централизованным управлением политиками все как раз немного проще, чем в случае с физическими коммутаторами. Причина этого — производители заранее задумались об этом вопросе и все средства для реализации были у них в руках. Под их контролем находился управляющий центр, под их контролем находился виртуальный коммутатор. Достаточно было наладить между ними взаимодействие. Думаю, вы знакомы (или, по крайней мере слышали) о таких продуктах как Distributed Virtual Switch или Nexus1000v. Они и решают задачу динамического перемещения политик вслед за виртуальной машиной.

Как мне кажется, оба подхода  имеют свое право на существование. В случае контроля за QoS и ACL на физическом коммутаторе мы останемся больше в рамках классических подходов к построению сетей — есть единая точка управления сетью, все политики настраиваются из централизованной системы управления. Минусом такого подхода является требование к наличию сервера RADIUS, а также к коммутационному оборудованию — оно должно поддерживать функционал детектирования событий перемещения VM. В случае же контроля за QoS и ACL на виртуальных коммутаторах никаких дополнительных средств не требуется, однако в сети появляются две точки, из которых происходит управление политиками и, как следствие, усложняется управляемость такой сетью.

Оба обсуждаемых вопроса — о BPDU и о применении политик — возникли по причине того, что в сети образовался дополнительная “прослойка” виртуальных коммутаторов доступа. Следовательно, если из двух образовавшихся уровней сделать один, проблемы исчезли бы сами собой. Давайте попробуем разобраться, возможно ли вернуться к ситуации с одним слоем коммутаторов на уровне агрегации.

В сфере сетевых технологий уже давно вращаются такие термины как VEPA (802.1Qbg) и VN-Tag (802.1Qbh/802.1BR). Эти две технологии как раз и были придуманы для того, чтобы заработать еще больше денег для производителей железа принудительно коммутировать весь трафик через физический коммутатор.

В случае VEPA все Ethernet фреймы, сгенерированные виртуальной машиной, направляются гипервизором на аплинк порт. Задача коммутатора — проверить в своей таблице адрес назначения (destination MAC) и принять решение о том, через какой порт отправить фрейм. Причем, если общение идет между двумя виртуальными серверами в пределах одного физического, то исходящий порт будет тот же, через который фрейм пришел в коммутатор. Правила transparent bridging не позволяют отправлять пакет в тот же порт, откуда он пришел — поэтому со стороны коммутационного оборудования требуется поддержка специального режима — т.н. hairpinning. Кроме этого, и гипервизор также должен поддерживать этот режим функционирования, что пока, к сожалению, наблюдается не у всех производителей. Из известных мне — только Redhat KVM позволяет это делать, вводя специальный тип интерфейса — macvtap (ссылка для тех, кому интересно будет почитать об этом самостоятельно).

Технология VN-tag идет еще дальше в вопросах вмешательства в коммуникации. Каждой виртуальной машине назначается специальный тэг, который добавляется в заголовок фрейма Ethernet. Внимательный читатель уже уловил нюанс, да?  Изменить фрейм Ethernet — означает изменить аппаратную часть, с помощью которой этот фрейм будет обрабатываться и, следовательно, изменить сами коммутаторы и серверные сетевые интерфейсы. Но, нас больше волнуют технические аспекты вопроса, поэтому продолжим обсуждать их. В соответствии с тэгом, на коммутаторе создается свой виртуальный интерфейс, аналогичный физическому. И коммутация уже ведется между этим виртуальным интерфейсом и всеми остальными. Даже если две виртуальные машины обслуживаются одним и тем же аплинком, коммуникации между ними будут проходить между двумя виртуальными интерфейсами внутри коммутатора, по всем канонам transparent bridging.

Итак, возвращаясь к исходному вопросу — можно ли уменьшить количество слоев коммутаторов — выносим вердикт, что технически это возможно. Причем, главным плюсом такого объединения, на мой взгляд, является централизованное управление. Когда есть разграничение ответственности — есть порядок в работе сети, когда же ответственность размывается между сетевыми и серверными администраторами, такого порядка добиться гораздо сложнее. Кроме вопросов централизованного администрирования сторонники внедрения 802.1Qbg/Qbh часто говорят о том, что обработка трафика на физическом коммутаторе разгружает процессор сервера. Но, что интересно, не приводятся цифры — а насколько разгружается процессор?  В то же время, оценка производительности современных vswitch (например, Open vSwitch) показывает, что они в состоянии обработать почти 10Gbps трафика, загрузив всего одно ядро процессора на 80-90% (источник — здесь). Современные же процессоры имеют на борту 4 или 8 ядер, а количество процессоров внутри сервера — два или более.

Каковы же минусы внедрения такого рода технологий? Первый — это отсутствие широкой поддержки. Как я уже упоминал ранее, производители сред виртуализации не торопятся уводить из-под собственного контроля сетевое взаимодействие между виртуальными машинами (что, наверное, логично с их стороны). Похоже, что тенденция в среде виртуализации идет к использованию программных vswitch (и, по моему мнению, новым кандидатом на стандарт де-факто будет именно Open vSwitch. Ведь не зря VMWare озаботилась покупкой Nicira, которая уже имеет собственное решение по построению т.н. Software Defined Network на основе Open vSwitch, не зря Xenserver от Citrix уже работает с этим продуктом, и не зря Redhat KVM готовит поддержку этого продукта в новом релизе).

Второй минус можно обнаружить, если вернуться к теме предыдущего обсуждения, а именно — вопросы генерирования BPDU на виртуальной машине. В случае с VEPA весь трафик принудительно направляется на порт коммутатора и у vswitch нет возможности применить даже BPDU фильтр для контроля. В случае с 802.1BR теоретическая возможность контролировать действия “вредоносной” виртуальной машины на физическом коммутаторе есть (т.к. каждой машине выделен свой виртуальный порт, на котором может быть применен BPDU Guard), однако в документации я не встретил описаний реализации этой возможности.

Таким образом, подводя итог рассуждениям,  нужно сказать, что на сегодня, если задаться целью, можно уменьшить количество слоев коммутаторов в ЦОД, тем самым решив проблему с точкой контроля за сетью. Однако это может сильно привязать вас к производителю оборудования, в силу того, что описанные выше решения еще не являются стандартами.