Введение в распределенный коммутатор vSphere

Распределенный коммутатор vSphere (VDS) предоставляет вам, клиент, два основных преимущества.
Во-первых, VDS предлагает централизованную плоскость управления для управления вашей виртуальной коммутацией,
взяв на себя большую часть ручной работы из повседневной администрации. Во-вторых, VDS
предлагает расширенные услуги и функции по сравнению со стандартным коммутатором.
VDS находится в середине шкалы функций, предлагая больше возможностей, чем стандартный коммутатор, но оставляя место за столом для сторонних коммутаторов, таких как Cisco
Нексус 1000В. Мы пойдем дальше в сторонние vSwitches в следующей главе. На данный момент мы
сосредоточиться больше на VDS, чем он отличается от стандартного коммутатора, и некоторые аккуратные
кнопки и вещицы, которыми он поставляется загружен.
Плоскость управления
Плоскость управления VDS находится на уровне vCenter стека. То есть vCenter - это
транспортное средство, используемое для создания, изменения и удаления VDS и связанных с ним групп виртуальных портов. Эта
означает, что вы можете создать свой VDS один раз, а затем выбрать, какие хосты будут его использовать. Это
похожая концепция для кластера vSphere. Сам по себе кластер ничего не делает. Вы
можно настроить кластер высокой доступности (HA) и распределенный планировщик ресурсов (DRS)
опций, но пока вы на самом деле не добавите несколько хостов в кластер, он просто выглядит красиво.
VDS бесполезен, пока к нему не добавлены хосты, и только тогда происходит волшебство.
Каждый VDS имеет определенное количество восходящих ссылок. Они называются dvUplinks с номером
после них по умолчанию, но вы можете изменить имя. С точки зрения плоскости управления, присвоение вашим восходящим ссылкам собственного имени помогает определить роль различных восходящих ссылок, которые будет использовать каждый хост.
перемещать трафик в и из VDS. При добавлении хоста в VDS вы отображаете физические порты восходящей линии связи на логические порты dvUplink. На рисунке 9.1 показаны dvUplinks в VDS
используя пользовательское имя «Core 1» и «Core 2» для пары dvUplinks.
ПОДСКАЗКА
Назовите ваши ссылки, чтобы они помогли с устранением неполадок. Мне нравится маркировать мой
в зависимости от назначения VDS, например, «Core - ##» или «Storage - ##». Вы также можете вызвать
инфраструктура физической коммутации, такая как «TOR-A» или «TOR-B», чтобы различать, какой
переключателя стойки (TOR), к которому вы подключаетесь. Избегайте использования определенных имен коммутаторов или IP-адресов, так как
эта информация в любом случае отслеживается CDP или LLDP. Подробнее о LLDP в следующем разделе.
Обработка ошибок vCenter
То, что VDS управляются через vCenter, может вызывать изжогу, так как
кажется, подразумевает зависимость от доступности vCenter. Вам может быть интересно, что произойдет, когда vCenter выйдет из строя - остановится ли виртуальное переключение?
Короткий ответ - нет, переключение будет продолжаться без перерыва. Но у нас есть
осталось пару сотен страниц, так что давайте перейдем к длинному ответу. Хотя это правда, что
мозг VDS лежит на сервере vCenter, на каждом хосте vSphere хранится кэшированная копия конфигурации VDS, которая обновляется каждые пять минут. Если vCenter не работает,
хост продолжает использовать эту кэшированную копию конфигурации VDS. Вы можете войти
ваш хост vSphere через Secure Shell (SSH) и посмотрите файл, если вы перейдете в / etc / vmware / dvsdata.db . Кэшированная база данных показана на рисунке 9.2.
Когда сервер vCenter вернется в рабочее состояние, может появиться несколько ошибок о том, что
что конфигурация VDS не синхронизирована с некоторыми из ваших хостов. Это прояснится
вскоре после того, как конфигурация vCenter VDS будет перенесена на хост vSphere во время
регулярный пятиминутный интервал обновления.
Плоскость данных
Как и в случае стандартного коммутатора, все действия плоскости данных продолжают происходить на
Хост слой. По своей природе данные не передаются через сервер vCenter, поскольку это просто
контрольная точка. Все решения о коммутации продолжают приниматься на самом хосте, следуя
те же правила уровня 2, которые установлены в главе 3 «Сети Ethernet».
Мониторинг
VDS поддерживает оба протокола обнаружения Cisco (CDP) и обнаружение канального уровня
Протокол (LLDP).
Протокол обнаружения Cisco (CDP)
Вы можете вспомнить, что стандартный vSwitch поддерживает CDP, но настраивает и управляет
эта функция требует использования некоторых ESXCLI, PowerCLI или других методов командной строки.
С помощью VDS, помимо включения CDP или LLDP, вы также можете установить режим
либо один из этих протоколов для прослушивания, рекламы или оба, непосредственно из клиента vSphere или
Веб-клиент vSphere. На самом деле это просто выпадающий список в разделе протокола обнаружения.
Аккуратно, а?
Протокол обнаружения канального уровня (LLDP)
Для тех, у кого нет коммутационной среды Cisco, вам повезло. VDS поддерживает
Открытый стандарт, эквивалентный CDP, называется протоколом обнаружения канального уровня (LLDP). Для всех
намерения и цели, LLDP предоставит все, что вы ожидаете от CDP, но работает
через различные платформы поставщиков. Интересно, что все больше и больше коммутаторов Cisco также
поддержка LLDP в наши дни, что помогает в гетерогенной среде коммутации.
Как показано на рисунке 9.3, опция включения LLDP может быть найдена с тем же раскрывающимся списком.
коробка используется для CDP. Вы также можете настроить все три различных режима работы: прослушивание,
Реклама или оба.
ПОДСКАЗКА
Один вопрос, который обычно всплывает, вращается вокруг желания установить LLDP (или даже
CDP в этом отношении) в режим «Реклама» или «Оба» и какой может быть обратная сторона.
Нам еще не приходилось сталкиваться с какой-либо средой, где есть дополнительная информация о
среда - с точки зрения сервера или сети - это плохо. Хотя некоторые
организации будут иметь политику, запрещающую LLDP или CDP включаться определенным образом,
в среде, связанной с соблюдением нормативных требований, большинство из них в порядке. Проверьте с вашей безопасностью
и / или сетевая команда в первую очередь, но велики шансы, что они оценят видимость
в виртуальную сетевую среду.
Поток данных, передающихся по сети
Теперь мы начинаем использовать некоторые дополнительные функции, которые действительно нравятся людям
VDS. Первый - NetFlow, и это расширенная функция, доступная вам в VDS.
NetFlow на самом деле не имеет ничего общего с VMware, но изначально
разработан Cisco и стал достаточно стандартным механизмом для выполнения сети
анализ.
В главе 7 «Чем виртуальная коммутация отличается от физической коммутации», мы упоминали
Идея темного трафика: трафик, который может никогда не покинуть хост. Это потому, что оба
исходная и целевая виртуальные машины расположены на одном хосте. Возможно, две виртуальные машины общаются друг с другом в одной VLAN и оказываются на одном хосте. Черт, это
иногда делается для того, чтобы избежать дополнительной нагрузки на физическую сеть и
потому что темный трафик переключается на гораздо более высокую скорость процессора / оперативной памяти хоста, а
чем на физических сетевых скоростях. NetFlow - это способ мониторинга и выборки IP-трафика, который
происходит в вашем VDS. Конфигурация управляется до уровня группы портов.
Данные трафика отправляются сборщику NetFlow, работающему в другом месте сети. Поток данных, передающихся по сети
обычно используется в физическом мире, чтобы помочь получить представление о трафике и понять, кто и что отправляет и куда.
NetFlow выпускается в различных версиях, от v1 до v10. VMware использует версию IPFIX
NetFlow, версия 10 и расшифровывается как «Информация о потоке интернет-протокола».
ЭКСПОРТ «. IPFIX - это на самом деле слияние версии 9 NetFlow с некоторыми стандартами IETF, и иногда его называют «стандартизированным IETF».
NetFlow 9. ” Если вас смущает то, что версию 10 иногда называют IPFIX 9, вы
не один. Для простоты часто лучше всего назвать это IPFIX, и люди будут знать,
что ты имеешь в виду.
ПОДСКАЗКА
vSphere 5.0 использует NetFlow версии 5, а vSphere 5.1 и выше использует IPFIX (версия 10).
Если вы используете программное обеспечение, которое требует версию 5 или не поддерживает IPFIX, вы можете захотеть
чтобы избежать обновления хостов vSphere, пока вы не сможете найти обходной путь. vSphere 5.1
не поддерживает NetFlow версии 5.
Чтобы воспользоваться NetFlow, вам нужно выполнить два шага. Первый - это настроить параметры NetFlow на самом VDS, о чем мы поговорим подробнее.
Конфигурация VDS NetFlow определяется следующими элементами:
■ IP-адрес: это IP-адрес NetFlow Collector, где информация о трафике
отправлено.
■ Порт: это порт, используемый NetFlow Collector. Обычно это порт UDP 2055
но может варьироваться в зависимости от поставщика, собирающего данные.
■ Переключить IP-адрес: сначала это может сбить с толку. В типичной аппаратной среде каждый коммутатор имеет своего рода IP-идентификатор для управления. Присвоив IP
здесь, NetFlow Collector будет обрабатывать VDS как единый объект. Оно делает
не обязательно должен быть действующим маршрутизируемым IP-адресом, а просто используется в качестве идентификатора. Например,
«1.1.1.1» является действительной записью.
Есть также ряд дополнительных настроек, которые можно настроить при желании:
■ Тайм-аут экспорта активного потока в секундах. Время, которое должно пройти до
переключатель фрагментирует поток и отправляет его в коллектор. Это позволяет избежать отправки
большое количество данных после особенно длинного потока происходит.
■ Тайм-аут экспорта простоя в секундах: аналогичен таймауту активного потока, но для потоков
которые вошли в состояние ожидания. Думайте об этом как о очистке, необходимой для
незадействованный поток своевременно отправляется в коллектор.
■ Частота выборки: это определяет N-й пакет для сбора. По умолчанию значение равно 0,
то есть собирать все пакеты. Если вы установите значение, отличное от 0, оно будет
собрать каждый N-й пакет. Например, 3 будет собирать только каждый третий пакет.
■ Обрабатывать только внутренние потоки: ваш выбор здесь включен или отключен (по умолчанию).
Включение гарантирует, что собраны только те потоки, которые происходят между виртуальными машинами на
тот же хост Это может быть полезно, если вы ищете только темный трафик
потоки, уже настроили NetFlow на вашей физической инфраструктуре, и хотите
избегайте выборки трафика дважды (один раз на виртуальном уровне и снова на физическом уровне).
Второй шаг - включить мониторинг для любых групп портов, которые необходимо отслеживать.
Вы быстро это поймете, когда настроите NetFlow, но не увидите никакого трафика
информация - и мы сделали это не раз.
--------------------------
СЕРВЕР аналог: https://t.co/mFwFiiu368