Comments 8
Коллеги, я очень хочу, чтобы мои опусы становились с каждым разом все лучше и лучше и поэтому был бы очень благодарен, если бы вы аргументировали свои минусы.
Несколько смутил заголовок, с первого захода показалось, что для прочтения этой статьи нужно хорошо понимать и STP и vSwitch. Со второго же захода, статья прочиталась в полне легко, в результате чего некоторые вещи встали на свои места.
А не сильно режут глаз аббревиатуры на английском? может стоит чаще использовать аналог на русском языке? честно говоря, это для меня самая сложная часть написания, потому что на русском я почти не читал техническую литературу, над банальным shared memory я долго ломал голову.
Мне — нет, не режут. Но есть конечно и любители переводить все подряд.
Route based on the originating virtual switch port ID
Правильно делаете, что не переводите всё подряд, например процитированное. Максимум, рядом, в скобках, давать краткие перевод, для понимания с чем имеем дело.
Представляю, сколько бы я искал в своей инфраструктуре эту настройку, упомянутую только на русском :)
vSphere админы выделяют отдельную пару аплинков только для vMotion или FT трафика, что кажется мне пустой тратой интерфейсов
Собственно, а что ещё делать, кроме как закладываться на простаивающий Ethernet-порт для того, чтобы избежать потенциального простоя, когда для банков или телекомов, например, этом может вылиться в значительно большие недополученные прибыли. Есть другие варианты?
PS: допустим, пока не будем учитывать, что в vSphere 5 трафик vMotion научили идти по нескольким аплинкам сразу.
Ну я стараюсь использовать active и standby аплинки.
Например, у меня три port group: первая для management vmknic, вторая для ВМ и траться для vmotion. При этом у меня всего 2 10 Гб интерфейса.
Для первых двух Port group активным является первый аплинк, а второй в режиме standby, и для vmotion у нас второй аплинк активный, а первый в резерве. трафик любого упавшего интерфейса или физического коммутатора прозрачно перекинется на уцелевший аплинк.
Это очень упрощенный пример и в реальной жизни все куда сложней, и уверен, что мой пример не всегда целесообразен, но идею мою он объясняет и экономит как минимум пару аплинков и портов.
Например, у меня три port group: первая для management vmknic, вторая для ВМ и траться для vmotion. При этом у меня всего 2 10 Гб интерфейса.
Для первых двух Port group активным является первый аплинк, а второй в режиме standby, и для vmotion у нас второй аплинк активный, а первый в резерве. трафик любого упавшего интерфейса или физического коммутатора прозрачно перекинется на уцелевший аплинк.
Это очень упрощенный пример и в реальной жизни все куда сложней, и уверен, что мой пример не всегда целесообразен, но идею мою он объясняет и экономит как минимум пару аплинков и портов.
В отличие от физических коммутаторов, vSS не нужно заучивать MAC адреса всех устройств находящихся в том же broadcast домене. Поскольку всем виртуальным машинам MAC адреса назначаются самим ESXi, то vSS уже знает все адреса по умолчанию. Другой отличительной особенностью является то, что vSS совершенно четко делит порты на два типа — внутренние порты и аплинки, и применяет к ним разные правила коммутации.
Наш случай: виртуальный роутер с бриджованым туннелем к другому роутеру. Т.е. L2 сегмент объединённый виртуальной машиной. Или я не правильно понял аргумент?
Sign up to leave a comment.
Почему стандартному vSwitch-у не нужен Spanning Tree протокол