none
Windows Nic Team для Nic в разные фермы core-edge. RRS feed

  • Вопрос

  • Добрый вечер Уважаемые коллеги!

    Столкнулся с некоторой проблемой:

    Что есть со стороны серверов:

    Есть два сервера WS 2012 R2 с ролью Hyper-V.На данных хостах работают гостевые ОС.На каждом сервере по два физических Nic.В свое время тиминг был собран не правильно, поэтому необходимо пересобрать.Позже прибудут еще два двухпортовых  Nic. 

    Что есть со стороны сетевого оборудования:

    SAN на основе Core-Edge. На периферии есть две фермы  FS1 и FS2 Catalyst 6509E, но пока что только в порты одной фермы FS1 входят по два линка с каждого физического Nic сервера.

    Цель:

    Пересобрать Nic Team с учетом еще дополнительного двух портового адаптера таким образом, что бы два Nic смотрели бы в одну ферму FS1, а еще два в другую ферму FS2, и на другом сервере точно так же. Необходимо так же агрегировать каждые два Nic естественно по LACP, что бы получить 2 gbps.Ну и распределить нагрузку по агрегированным Nic  для трафика гостевых ОС.

    Вопрос:

    Как сделать так что бы в одном тиме объединить сразу четыре Nic каждого сервера для развлетвления на разные фермы при резервировании, потому что коллеги сетевики-цискари говорят, что нельзя будет сделать как бы в одном тиминге все четыре Nic и одну группу из двух агрегированных nic отдать на вторую ферму.В свою очередь если делать два тиминга, то такую конфигурацию не поддерживает Microsoft в части виртуализации, потому как должен быть один Nic Team и один виртуальных коммутатор.

    Что можете посоветовать в такой конфигурации ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 24 марта 2014 г. 17:16
    24 марта 2014 г. 17:08

Ответы

  • Если можно, то я своими словами

    1) 2 разные LACP - группы  (разные свитчи) и 1 Nic Team из них на стороне ОС - не вариант. Но стоит заметить, что MC (Multi-Chassis)-LAG + Nic Teaming - рабочий вариант. При MC-LAG все агрегированные порты "определяются" как принадлежащие одному и тому же свитчу. 

    2) 2 LACP-группы, 2 Team адаптера - вариант

    3) Тиминг из 4-х адаптеров + имплементация converged network - вариант. Всё зависит от Вашей реальной загрузки в гостевых средах. 

    4) Тиминг 2-х адаптеров, 1 адаптер под DMZ, 1 адаптер под csv/live migration (TCP) . Приемлимо, но выделять отдельный адаптер под DMZ не стал бы. Тут либо виртуализация через VMM, либо powershell, либо вланы и т.д. Лучше этот адаптер выделить под Management. Но всегда лучше иметь резервные каналы для csv. В данном случае 1 канал - тим, 2 канал - выделенный адаптер. С учетом того, что SAN доставляются другими способами (не Ethernet). 

    Ломайте)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    • Изменено R.LevchenkoMVP 25 марта 2014 г. 16:29 MC_LAG
    • Помечено в качестве ответа rеstless 25 марта 2014 г. 17:00
    25 марта 2014 г. 16:03

Все ответы

  •  Просто на данных коммутаторах уже настроены свои STP и Ether Channel. Может быть в совокупности работы с виндовым Nic Team , что-то необходимо исключить из работы-если одно другому мешает.Допустим STP и виндовый LBFO ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 25 марта 2014 г. 5:49
    25 марта 2014 г. 5:48
  • Добрый день!

    Начнем с того, что Вы можете иметь несколько Team групп, но для поддержки в NIC Team'е, который будет выделен для External Switch, должен быть 1 Team Interface. Это не относится к количеству самих тиминговых групп. Поясните так же какие карточки используются? (проп.способность?)я так понимаю 4 ника по 1 Гб.с? Сделать LACP для 2 членов группы, а для других не делать - так не получится в рамках одного тима


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 6:04
  • Добрый день!

    Начнем с того, что Вы можете иметь несколько Team групп, но для поддержки в NIC Team'е, который будет выделен для External Switch, должен быть 1 Team Interface. Это не относится к количеству самих тиминговых групп. Поясните так же какие карточки используются? (проп.способность?)я так понимаю 4 ника по 1 Гб.с? Сделать LACP для 2 членов группы, а для других не делать - так не получится в рамках одного тима


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    1.Значит если у меня две тиминговые группы, то я имею два мультиплексора (который виден в ОС ) и только один из них я могу привязать к External Switch ? Либо я могу привязать к каждой тиминговой группе (мультиплексору) по одному External Switch- но тогда у меня получается уже два External Switch, но в принципе сохраняется требование один виртуальный коммутатор на одну тиминговую группу ? То есть в итоге получаю куча виртуальных коммутаторов но привязанных каждый к своей и ОДНОЙ группе так ?

    2. Да два встроенный в сервер NIC каждый по 1 Гбит/c и еще будет один NIC двух портовый-каждый порт по 1 Гбит/c.Вот и вопрос: Надо удовлетворить и поддержку Microsoft одна группа на один виртуальный коммутатор, НО если выходит из строя одна из физических ферм CISCO то вторые два физических NIC должны  смотреть в другую ферму CISCO.Отсюда и вопрос как сделать и пропускную способность выше-фичей тима, отказоустойчивость на случай выхода одной из ферм ну и соблюсти поддержку майкрософта ?

    Либо: Все четыре NIC объеденить в тим, агрегировать и раздать по разным фермам. Цискари говорят, что так нельзя.

    Да и еще тут еще моячит одельный NIC на DMZ и он будет особняком стоять, придется тогда один NIC для DMZ выдерать, тогда остается три.И при такой схеме создать в тиме агрегацию двух NIC в 2 Гбит/с и направить в одну ферму и создать вторую группу но в ней один NIC 1 Гбит/c направленный просто на другую ферму на случай отказа ? В общем пока вот и ломаем голову , как поступить, за неимением больше NIC-ов.)) 

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 25 марта 2014 г. 7:26
    25 марта 2014 г. 7:19
  • В общем превратить примерно вот в такое:


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    25 марта 2014 г. 7:40
  • Единственное требование, связанное с Nic Teaming для Ext Switch, которое мне известно , - использовать Nic Team с Default VLAN и 1 team интерфейсом внутри него, т.е. Nic Team ,созданный с настройками по умолчанию (я не беру расчет алгоритмы балансировки и тип тиминга - это всё можно изменять). VLANы желательно определять на уровне ВМ. 

    Как пример, Вы получите 2 тиминга , привязанных к отдельным Ext свитчам. Делать converged networks и т.д. - не вижу смысла ( не те адаптеры у вас). 4 адаптера в тиминге. Если выходят 2 адаптера (ферма FS1), то весь трафик и так будет ретранслирован на оставшиеся 2 адаптера (FS2 ферма) 

    Выше чем позволяет физика Вы не сделаете :). Наилучшая производительность - Switch dependent teaming. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 7:40
  • Единственное требование, связанное с Nic Teaming для Ext Switch, которое мне известно , - использовать Nic Team с Default VLAN и 1 team интерфейсом внутри него, т.е. Nic Team ,созданный с настройками по умолчанию (я не беру расчет алгоритмы балансировки и тип тиминга - это всё можно изменять). VLANы желательно определять на уровне ВМ. 

    Как пример, Вы получите 2 тиминга , привязанных к отдельным Ext свитчам. Делать converged networks и т.д. - не вижу смысла ( не те адаптеры у вас). 4 адаптера в тиминге. Если выходят 2 адаптера (ферма FS1), то весь трафик и так будет ретранслирован на оставшиеся 2 адаптера (FS2 ферма) 

    Выше чем позволяет физика Вы не сделаете :). Наилучшая производительность - Switch dependent teaming. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     То есть еще раз: Две тиминговые группы, в каждой группе 2 NIC Active/Active. Одна группа смотрит в одну ферму, другая в другую. C VLAN и так все ясно, как настраивать. Но есть два вопроса:

     1.У меня некоторое количество ВМ будет привязано к одному External Switch, а другие ВМ получается к другому External Switch. При отказе одной из ферм у меня получается тип группа полностью не рабочая и тогда сеть с ВМ так же пропадает ? Не пойму ...Либо я могу создать две разные тиминговые группы объединив все четыре NIC в LBFO ? 

    2.Агрегация а данном случае так же нужна то есть получить с каждой пары NIC 2 Gbps.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 25 марта 2014 г. 7:54
    25 марта 2014 г. 7:51
  • Сервера в кластер планируете?

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 7:53
  • Сервера в кластер планируете?

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    Да обязательно, как появится третий хост все это счастье будет объединятся в Failover Cluster виртуальных машин + еще гостевые кластера SQL с прокидыванием FC в гостевые ОС.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 25 марта 2014 г. 7:55
    25 марта 2014 г. 7:55
  • Сервера в кластер планируете?


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    Да обязательно, как появится третий хост все это счастье будет объединятся в Failover Cluster виртуальных машин + еще гостевые кластера SQL с прокидыванием FC в гостевые ОС.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    Я Вам просто привел пример того, как можно сделать и не вылезти за рамки "поддержки инфраструктуры". 4 адаптера в тиминге - самый простой вариант. НО: 1 Вы хотите выделить для DMZ (т.е. будет отдельный вирт.свитч DMZ, к примеру). Остаётся 3 адаптера. Делайте тиминг из 2-х адаптеров (FS1 + FS2) и оставляете выделенный для csv/wsfc/live migration (TCP) . Либо 3 адаптера в тиминг, но я бы всё таки вынес отдельный адаптер под cluster и поменял метрики на каждой.

    В случае с converged можно на тиминге из 3-х адаптеров "нарезать" интерфейсы на уровне vSwitch и их уже использовать для кластера,миграции и т.д. Но я бы converged рассматривал при 10 гб.с. Сделайте подсчет нагрузки приложений и +20-30% запас. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 8:13
  • Сервера в кластер планируете?


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    Да обязательно, как появится третий хост все это счастье будет объединятся в Failover Cluster виртуальных машин + еще гостевые кластера SQL с прокидыванием FC в гостевые ОС.

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    Я Вам просто привел пример того, как можно сделать и не вылезти за рамки "поддержки инфраструктуры". 4 адаптера в тиминге - самый простой вариант. НО: 1 Вы хотите выделить для DMZ (т.е. будет отдельный вирт.свитч DMZ, к примеру). Остаётся 3 адаптера. Делайте тиминг из 2-х адаптеров (FS1 + FS2) и оставляете выделенный для csv/wsfc/live migration (TCP) . Либо 3 адаптера в тиминг, но я бы всё таки вынес отдельный адаптер под cluster и поменял метрики на каждой.

    В случае с converged можно на тиминге из 3-х адаптеров "нарезать" интерфейсы на уровне vSwitch и их уже использовать для кластера,миграции и т.д. Но я бы converged рассматривал при 10 гб.с. Сделайте подсчет нагрузки приложений и +20-30% запас. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    То есть в моем случае об агрегации думать не приходится, если я хочу одновременно на две фермы разбрасывать NIC, да и еще кластер строить.Получится в принципе что у меня в одной группе будет два NIC по 1 гбит без агрегации на разные фермы (один NIC в одну ферму , другой NIC  в другую)+ один отдельный NIC на Cluster и Live Migration+ один NIC на DMZ.В принципе и нагрузка не так уж велика на данный момент при входе на NIC хостов.

    И режим работы тиминга тогда получается Switch Independent , то есть к разным свичам придется бросать по одному NIC..

     А вообще я все равно не могу агрегировать несколько NIC в тиме и разнести по разным фермам, все равно придется делать как минимум две тиминговые группы, так ?



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 25 марта 2014 г. 10:07
    25 марта 2014 г. 9:47
  • То есть вопрос остается вопросом именно для поддержки виртуализации, возможно ли распределение агрегированных NIC состоящих в одном тиме на разные коммутаторы для резервирования.Либо если нет, то остается только иметь "толстые" 10 Gbps адаптеры, либо что-то еще ?

    Разве не предусмотрели резервирования относительно физических коммутаторов при агрегации нескольких  NIC в тиминге?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 25 марта 2014 г. 11:38
    25 марта 2014 г. 10:42
  • То есть вопрос остается вопросом именно для поддержки виртуализации, возможно ли распределение агрегированных NIC состоящих в одном тиме на разные коммутаторы для резервирования.Либо если нет, то остается только иметь "толстые" 10 Gbps адаптеры, либо что-то еще ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Сетевики видимо не зря говорят, что не поддерживается (по Cisсo я не подскажу), но с точки зрения Nic Teaming + Вашей схемы я проблем не вижу (LACP-группа из двух адаптеров на каждом свитче). Только зачем так делать то, если можно так же из 4 адаптеров тиминг сделать (мы,конечно, не получим аггрегацию на 100%, но всё таки балансировка и т.д. будет компенсировать) и "разруливать" VLAN'ами Ваши сети. DMZ можно либо в виртуализированную сеть, либо отдельный VLAN. Трафик в DMZ-зоне,как правило, минимальный.

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 11:37
  • То есть вопрос остается вопросом именно для поддержки виртуализации, возможно ли распределение агрегированных NIC состоящих в одном тиме на разные коммутаторы для резервирования.Либо если нет, то остается только иметь "толстые" 10 Gbps адаптеры, либо что-то еще ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Сетевики видимо не зря говорят, что не поддерживается (по Cisсo я не подскажу), но с точки зрения Nic Teaming + Вашей схемы я проблем не вижу (LACP-группа из двух адаптеров на каждом свитче). Только зачем так делать то, если можно так же из 4 адаптеров тиминг сделать (мы,конечно, не получим аггрегацию на 100%, но всё таки балансировка и т.д. будет компенсировать) и "разруливать" VLAN'ами Ваши сети. DMZ можно либо в виртуализированную сеть, либо отдельный VLAN. Трафик в DMZ-зоне,как правило, минимальный.

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     Я все понимаю Роман и вы правы! Так и предполагалось. Четыре физических NIC объединили в тиминг, ну ладно из расчета DMZ пускай даже три NIC. Включили switch dependent+LACP+Hyper-V Port и со стороны одной фермы включили агрегацию.Даже конвергенцию можно сделать и нарезать на виртуальные NIC.Так же отдать транки на все физические NIC которые в тиминге и разруливать VLAN на уровне ВМ!

    НО Сетевики уцепились за схему резервирования, что дескать надо направить половину NIC с каждого сервака на одну циску , а другую половину NIC на другую циску во избежании падения циски и соответственно "отсыхания" доступа к ВМ. На их уровне еще включен Spanning Tree протокол который блокирует порты в зависимости от того дохне ли порт или нет.

    Может быть тут бы и спас бы кластер Failover , если нет heartbeat-ов c переездом на другую ноду, если циска дохнет, но я так понял что у них вторая циска в режиме ожидания что ли, пока не "сдохнет" первая - в общем тут темный лес ((



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!





    • Изменено rеstless 25 марта 2014 г. 11:56
    25 марта 2014 г. 11:46
  • Если так, то резервируйте,конечно, же. Не вижу проблем в тиминге между двумя группами LACP (1 группа=1 свитч=2 адаптера). Возможно коллеги поправят. Практически не сталкивался. В теории - всё гуд должно быть.  

    Уточните у сетевиков всё таки почему они решили что не заработает. Может я что-то недопонимаю. Если LACP группа между разными свитчами - это да..вопрос. А тут стандартная конфигурация по сути. 2 группы на разных свитчах. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 12:04
  • Если так, то резервируйте,конечно, же. Не вижу проблем в тиминге между двумя группами LACP (1 группа=1 свитч=2 адаптера). Возможно коллеги поправят. Практически не сталкивался. В теории - всё гуд должно быть.  

    Уточните у сетевиков всё таки почему они решили что не заработает. Может я что-то недопонимаю. Если LACP группа между разными свитчами - это да..вопрос. А тут стандартная конфигурация по сути. 2 группы на разных свитчах. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     Да и здесь все гуд, НО получится два виртуальных свича, один виртуальный коммутатор на одну группу агрегации.Второй виртуальный коммутатор на другую группу агрегации. Допускаем, что одна циска сдохла и все привязанные к данному виртуальному коммутатору ВМ так же сдыхают, или нет ?

    Другая же часть ВМ присоединенная к другому виртуальному коммутатору и соответственно к группе агрегации продолжает работать-потому как вторая циска работает...

    Вот тут больше всего непоняток ???


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 25 марта 2014 г. 12:14
    25 марта 2014 г. 12:13
  • Стоп стоп. Я речь веду именно об ОДНОМ тиминге, включающий 2 LACP группы, где LACP группа = 2 адаптера, подключенных к соответствующему свитчу. Именно в такой конфигурации я в теории не вижу проблем для работы Nic Teaming.

    Для одного сервера из двух. На втором такой же тиминг.


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 12:17
  • Стоп стоп. Я речь веду именно об ОДНОМ тиминге, включающий 2 LACP группы, где LACP группа = 2 адаптера, подключенных к соответствующему свитчу. Именно в такой конфигурации я в теории не вижу проблем для работы Nic Teaming.

    Для одного сервера из двух. На втором такой же тиминг.


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    О как, А как интересно я могу создать две разные группы LACP на четыре NIC в одном тиминге, то есть для одного мультиплексора привязанного к одному виртуальному коммутатору , разве возможно ?

     Вот только что пробовал, либо я могу в ОДИН тиминг добавить все четыре NIC и сделать LACP только для всего тима, либо сделать второй тим и добавить туда отдельно два NIC и настроить на них LACP-тогда у меня все равно получится два тиvа и в каждом по два NIC c LACP.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!





    • Изменено rеstless 25 марта 2014 г. 12:54
    25 марта 2014 г. 12:25
  • Не так ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 25 марта 2014 г. 12:31
    25 марта 2014 г. 12:31
  • Либо вы имели в виду что бы создать тиминг из четырех NIC с поддержкой LACP на уровне Windows и уже на уровне физических коммутаторов разделить по двум группам LACP ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 25 марта 2014 г. 12:51
    25 марта 2014 г. 12:51
  • Либо вы имели в виду что бы создать тиминг из четырех NIC с поддержкой LACP на уровне Windows и уже на уровне физических коммутаторов разделить по двум группам LACP ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Со стороны ОС тиминг из 4 адаптеров "работать" то будет, но вот со стороны свитчей, скорей всего, проблемы будут (правильно сетевики отмечают) в плане синхронизации каналов LACP.Правило: 1 LACP Team <> 1 Switch  . Это разновидность switch independent всё таки. По сути, Ваша конфигурация (4 адаптера все в одном тиминге) будет аля "тиминг из двух адаптеров, которые разнесены на разные хосты", что,понятное дело, не поддерживается и не решается (ещё пример -"объединение двух транков в третий транк". тоже не получится).  

    Делайте тиминг из 4 адаптеров без LACP и не придумывайте :). 

     

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    25 марта 2014 г. 13:45
  • Либо вы имели в виду что бы создать тиминг из четырех NIC с поддержкой LACP на уровне Windows и уже на уровне физических коммутаторов разделить по двум группам LACP ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Со стороны ОС тиминг из 4 адаптеров "работать" то будет, но вот со стороны свитчей, скорей всего, проблемы будут (правильно сетевики отмечают) в плане синхронизации каналов LACP.Правило: 1 LACP Team <> 1 Switch  . Это разновидность switch independent всё таки. По сути, Ваша конфигурация (4 адаптера все в одном тиминге) будет аля "тиминг из двух адаптеров, которые разнесены на разные хосты", что,понятное дело, не поддерживается и не решается (ещё пример -"объединение двух транков в третий транк". тоже не получится).  

    Делайте тиминг из 4 адаптеров без LACP и не придумывайте :). 

     

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    Хорошо, дабы не засорять мозг не вам Роман не себе, еще раз и по порядку:

    Имеем два сервера виртуализации и на каждом по 4 физических ник NIC.

    Имеем два мощных коммутатора CISCO.

    Задача:

    1.Настроить сетевую конфигурацию обоих серверов для поддержки виртуализации;

    2.Организовать поддержку взаимодействия между VLAN для ВМ.

    3.Создать отдельный порт для ВМ находящихся в DMZ c поддержкой Live Migration.

    4.Создать резервирование на уровне сети с использованием физических коммутаторов.

    Поехали:

    1. два физических NIC мы объединяем в Nic Team и каждый из двух физических NIC (в этом тиминге) будет смотреть в свою ферму-циску. Режим Switch Independent.То есть работает только Failover Active/Active, балансировки нет и LACP нет!

    2.Отдаем транк с обоих ферм на эти два NIC которе в тиминге.Multiplexor Driver Interface который появился в результате создания тиминга делаем External Virtual Switch.На базе этого виртуального коммутатора будут работать vNIC для ВМ.VLAN указывается на уровне ВМ.

    3.Cоздаем обычный External Virtual Switch без тиминга на базе третьего физического NIC.И так же используем для vNIC ВМ с отдачей транка.

    4.Четвертый NIC используем для csv/Lm/Cluster.

    5.Получаем отказоустойчивость на уровне тиминга при сдыхании одного из NIC, а так же отказоуствойчивость на уровне циски-при сдыхании циски трафик польется через второй физический NIC на вторую циску.

    Все так ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!





    • Изменено rеstless 25 марта 2014 г. 15:01
    25 марта 2014 г. 14:23
  • Остался только нерешенным вопрос:

     При таких конфигурация тогда получается либо необходим только один физический свитч,либо два,но как стек -что бы реализовать всю силу LACP ? Немогу только смысл уловить,если

    я хочу балансировку агрегацией реализовать,то я такое решение могу реализовать только либо на одном коммутаторе,либо без поддержки виртуализации несколькими наборами тиминговых групп,где же здесь тогда преимущества то ?

    Либо использовать "взрослые" NIC по 10gbps и тогда уже LACP не потребуется ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 25 марта 2014 г. 15:50
    25 марта 2014 г. 15:04
  • Если можно, то я своими словами

    1) 2 разные LACP - группы  (разные свитчи) и 1 Nic Team из них на стороне ОС - не вариант. Но стоит заметить, что MC (Multi-Chassis)-LAG + Nic Teaming - рабочий вариант. При MC-LAG все агрегированные порты "определяются" как принадлежащие одному и тому же свитчу. 

    2) 2 LACP-группы, 2 Team адаптера - вариант

    3) Тиминг из 4-х адаптеров + имплементация converged network - вариант. Всё зависит от Вашей реальной загрузки в гостевых средах. 

    4) Тиминг 2-х адаптеров, 1 адаптер под DMZ, 1 адаптер под csv/live migration (TCP) . Приемлимо, но выделять отдельный адаптер под DMZ не стал бы. Тут либо виртуализация через VMM, либо powershell, либо вланы и т.д. Лучше этот адаптер выделить под Management. Но всегда лучше иметь резервные каналы для csv. В данном случае 1 канал - тим, 2 канал - выделенный адаптер. С учетом того, что SAN доставляются другими способами (не Ethernet). 

    Ломайте)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    • Изменено R.LevchenkoMVP 25 марта 2014 г. 16:29 MC_LAG
    • Помечено в качестве ответа rеstless 25 марта 2014 г. 17:00
    25 марта 2014 г. 16:03
  • Если можно, то я своими словами

    1) 2 разные LACP - группы  (разные свитчи) и 1 Nic Team из них на стороне ОС - не вариант. Но стоит заметить, что MC (Multi-Chassis)-LAG + Nic Teaming - рабочий вариант. При MC-LAG все агрегированные порты "определяются" как принадлежащие одному и тому же свитчу. 

    2) 2 LACP-группы, 2 Team адаптера - вариант

    3) Тиминг из 4-х адаптеров + имплементация converged network - вариант. Всё зависит от Вашей реальной загрузки в гостевых средах. 

    4) Тиминг 2-х адаптеров, 1 адаптер под DMZ, 1 адаптер под csv/live migration (TCP) . Приемлимо, но выделять отдельный адаптер под DMZ не стал бы. Тут либо виртуализация через VMM, либо powershell, либо вланы и т.д. Лучше этот адаптер выделить под Management. Но всегда лучше иметь резервные каналы для csv. В данном случае 1 канал - тим, 2 канал - выделенный адаптер. С учетом того, что SAN доставляются другими способами (не Ethernet). 

    Ломайте)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


     Ок, спасибо!

    1.Вариант под вопросом.

    2.Вариант, но для поддержки виртуализации сложен.

    3.Этот вариант только с одним физическим свичем, если не надо LACP, тогда и с двумя получится.

    4.Без LACP по одному адаптеру в каждый физический коммутатор, DMZ можно было отдать через VLAN в ту же тимминг из двух адаптеров, но сетивики НАПРОЧЬ сказали, что это должен быть отдельный кабель, какой вариант им еще предложить-уже сложно.До SCVMM еще далеко .А что имеется в виду под PoSh ? И остался один NIC на все остальное связанное с кластером и томами.Не густо конечно но этот как вариант получается. 

    vSAN настроен отдельно для проброса LUN  в гостевые ОС.Ну и LUN  кворума + CSV для кластера виртуальных машин-будет скоро.

    Задача сводилась именно как при всего четырех NIC сделать и агрегацию хотя бы до 2gbps на канале и соответственно разбросать по разным коммутаторам агрегированные каналы. Но видимо более четырех вариантов, которые вы предложили с моей конфигурацией не подойдет,было бы хотя бы 6 NIC, или те же по 10gbps..

    Ну в принципе и на том спасибо, очень помогли,хоть я и на мозг вам накапал конечно, но и почитать наверное еще стоит у айдана фина в его книге про тим много есть..

    Еще раз спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 25 марта 2014 г. 17:04
    25 марта 2014 г. 16:47
  • PoSh имеется ввиду, что через него виртуализацию сети делать,если нет VMM. В VMM весь этот процесс - это next, next, finish

    В вашей ситуации, насколько понимаю, рулят сетевики. Пусть они определяются сначала со своими требованиями+озвучьте свои, а потом уже будем строить на конкретном примере :)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    25 марта 2014 г. 17:39
  • PoSh имеется ввиду, что через него виртуализацию сети делать,если нет VMM. В VMM весь этот процесс - это next, next, finish

    В вашей ситуации, насколько понимаю, рулят сетевики. Пусть они определяются сначала со своими требованиями+озвучьте свои, а потом уже будем строить на конкретном примере :)


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     Да вот с точностью наоборот,я это детище виртуализации пытаюсь протолкнуть, но вот как раз что бы найти общее понимание с сетевиками, я должен сначала разобраться до конца со своей стороны, а сетевики понять как работает Nic Team в WS 2012 R2.

     У сетевеков есть рекомендации, что бы я строил свои интерфейсы с учетом резервирования на обе фермы, хотя они не настаивают.Плюс уперлись рогом в обязательности отдельного NIC для DMZ-это отдельный VLAN 101.Хотя его можно настроить простой раздачей VLAN в том же тиминге на ВМ в своем VLAN.Тогда высвобождается один NIC.

     Мне надо что бы из одного гигабита получилось два, за не имением другого(всего 4 NIC по 1 гбит/c).Но вот что бы удовлетворить и агрегацию и резервирование в "одном флаконе"-голову и ломаю..))


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!







    • Изменено rеstless 26 марта 2014 г. 3:45
    25 марта 2014 г. 20:56
  • В общем как обстоит дело на данный момент:

    Сразу скажу-в части External Virtual Switch "наляпано" не мною, а просто кем то тупо срисовано с WS 2008 R2 - кем то криво настроено (торопились видать с продуктивом), поэтому необходимо пересобирать Nic Team.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 26 марта 2014 г. 3:39
    26 марта 2014 г. 3:34
  • Агрегацию в чистом виде при помощи Nic Teaming не получите, конечно. Но распределение нагрузки по адаптера+резервирование - тоже очень неплохо. Если абстрагироваться чуть. то достигнет ли одна из Ваших ВМ сет. потребности в размере 1 тимингового адаптера на send/receive?

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    26 марта 2014 г. 6:07
  • Агрегацию в чистом виде при помощи Nic Teaming не получите, конечно. Но распределение нагрузки по адаптера+резервирование - тоже очень неплохо. Если абстрагироваться чуть. то достигнет ли одна из Ваших ВМ сет. потребности в размере 1 тимингового адаптера на send/receive?

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     Я это прекрасно понимаю Роман, что LACP без настройки физического коммутатора не настроить, то есть 1gbps+1gbps в Nic Team не 2gbps -это все равно 1gbps пока не настроить LACP со стороны физического свича и в режиме Dependent Switch!

     Можно без агрегации обойтись потому что нагрузка даже не достигает 100 мбит/c. При таком раскладе хватит и одного тиминга из двух NIC и каждый NIC смотрит в свою ферму.Один NIC на csv/cluster/lm и один NIC на DMZ.

     Даже можно попробовать три NIC в тиминг и сделать Converge Fabric и в нем нарезать tNIC для manage/cluster/lm. таким образом два NIC в одну ферму, третий NIC в другую (хотя при сдыхании одной из ферм нагрузка сразу кинется на один NIC).Но всяком случае пока нагрузок страшных я не наблюдал в среднем до 34 мбит/c для обращения пользователей к web сервисам и SQL.

    К стати в 2012 R2 появилась фича выбора режима Dynamic для Independent Switch:

    Although NIC Teaming in Windows Server 2012 provided both distribution of network load across NICs in a team and failover support for teamed NICs, network traffic was not distributed across teamed NICs in a balanced fashion. Beginning with Windows Server 2012 R2, however, a new feature called dynamic load balancing automatically and continuously balances traffic across teamed NICs in an equitable fashion.As you can see from the figure, however, a third load-balancing mode called Dynamic has now been added to NIC Teaming in Windows Server 2012 R2. Not only that, but this new mode is now the default load-balancing mode when you create a new team on the new platform. By using dynamic load balancing, you can now use all members of a NIC team even when the team is in Switch Independent mode.

    Но пока не знаю что это даст, надо тестить.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    26 марта 2014 г. 6:40
  • Про фичу в курсе. Dynamic в большинстве случаев , позиционируется как лучший метод распределения нагрузки. Т.е. для hyper-v - switch independent/dynamic будет наилучшим вариантом ( в вашем случае)

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    26 марта 2014 г. 6:53
  • Ребят, не подскажите , какой более менее "взрослый" инcтрумент есть кроме task manager , что бы можно было помониторить реальную загрузку NIC интерфейсов на входе и выходе с хостов виртуализации ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    27 марта 2014 г. 8:02
  • Ребят, не подскажите , какой более менее "взрослый" инcтрумент есть кроме task manager , что бы можно было помониторить реальную загрузку NIC интерфейсов на входе и выходе с хостов виртуализации ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    1) Для ВМ. Более подробно (тут)

    Enable-VMResourceMetering -VMName VM1 $VMnet=Measure-VM -VMName VM1 $VMnet.NetworkMeteredTrafficReport

    2) Общий инструмент -Perf Mon  (bytes total/sec+bandwith+nic utilization). Больше инфы : тут


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    27 марта 2014 г. 8:11