Спрашивающий
Рекомендации по настойки сети Hyper-V

Общие обсуждения
-
Добрый день, коллеги!
Есть какие-то Best Practices по настройки сети на Hyper-V серверах, сейчас стандартный сервер идет с 4*1Gb интерфейсами.
Давайте рассмотрим 2 ситуации, когда в кластере с общим хранилищем (SAN сеть мы не трогаем) и когда без. Кто как настраивает, объединяете вы в NIC TEAM, а поверх делаете виртуальные интерфейсы по различные виды трафика (управление, резервное копирование, миграции и т.п.) или не используете агрегацию канала оперируете физическими интерфейсами для разделения трафика. За любые статье по этому поводу буду признателен.
- Изменен тип Petko KrushevMicrosoft contingent staff, Moderator 7 декабря 2017 г. 11:02
17 ноября 2017 г. 12:12
Все ответы
-
https://technet.microsoft.com/en-us/library/dn550728(v=ws.11).aspx12 декабря 2017 г. 8:56
-
еще на заре серверов поколения 2012 сами майки где то в дебрях технета писали, что "если вы объединяете сетевые интерфейсы в тим, то обязательно оставьте свободным хотя бы один для возможности управления хостом... а если вы еще и в кластер собираете, то еще один свободный не помешает для внутрикластерной связи..." (как то так в памяти сохранилось). к сожалению за давностью лет ссылку не могу предоставить...
upd: вот нашел ссылку на документ с описанием технологии тиминга, правда на вражеском языке...
- Изменено RAMzez_ 12 декабря 2017 г. 11:50 upd
12 декабря 2017 г. 11:18 -
Если все манипуляции проводить на уровне физ. адаптеров получается не очень рациональное использование сетевых ресурсов. Два линка отдавать под харбит и управление получается 50% пропускной способности.<o:p></o:p>
Как мне кажется целесообразней настругать нужное кол-во виртуальных адаптеров. Да и есть рекомендации относительно LACP, где рекомендуют четное кол-во адаптеров объединять в группу.<o:p></o:p>
12 декабря 2017 г. 11:41 -
~~
Есть какие-то Best Practices по настройки сети на Hyper-V серверах,
сейчас стандартный сервер идет с 4*1Gb интерфейсами.~~
Скорее 2*10Gb
"Последние моды":
Cisco Nexus 3132
Switch Configuration Examples for Microsoft SDNSwitch model: Cisco Nexus 3132
Topology: Two top-of-rack (TOR) switches with a L3 topology connected to a Spine using BGP
+--------+ +--------+ | Spine1 | | Spine2 | BGP ASN: 64807 +--------+ +--------+ | \ / | | \ / | | X | | / \ | .Rack1..| / \ |......................... . +--------+ +--------+ . . | TOR1 |=| TOR2 | BGP ASN: 64651 . ... TORs in additional racks . +--------+ +--------+ . can be added to the . | | . same Spine pair. . | | . . | | . . | | . . | | . . +-------------------+ . . | Hyper-V Hosts |-+ BGP ASNs: . . +-------------------+ |-+ MUX=64652 . . +-------------------+ | GW =64653 . . +-------------------+ . ............................................
- Изменено Victor Miasnikov 13 декабря 2017 г. 9:43
13 декабря 2017 г. 9:40 -
Dell Force10 S4810
Topology: Two aggregate and two top-of-rack (TOR) switches with a L3 topology connected to the border of datacenter core using point-to-point port-channels and BGP
+--------+ +--------+ | Border | | Border | BGP ASN: 4232570300 +--------+ +--------+ | \ / | | \ / | | X | | / \ | | / \ | +--------+ +--------+ | Agg1 | | Agg2 | BGP ASN: 64807 +--------+ +--------+ | \ / | | \ / | | X | | / \ | .Rack1..| / \ |......................... . +--------+ +--------+ . . | TOR1 |=| TOR2 | BGP ASN: 64651 . ... TORs in additional racks . +--------+ +--------+ . can be added to the . | | . same Agg pair. . | | . . | | . . | | . . | | . . +-------------------+ . . | Hyper-V Hosts |-+ BGP ASNs: . . +-------------------+ |-+ MUX=64652 . . +-------------------+ | GW =64653 . . +-------------------+ . ............................................
~
~
~
~
Update the physical intefaces to match the physical links in your environment. These three links are combined into a single port channel:
interface Port-channel 100 description Link to TOR2 no ip address channel-member TenGigabitEthernet 0/45-47 rate-interval 30 no shutdown !
~
~
~
~
Quality of Service for RDMAFor RDMA based storage to function properly, traffic classes must be defined to separate the RDMA based storage traffic from the rest of the host and VM traffic.
dcb enable ! dcb-map RDMA-dcb-map-profile priority-group 0 bandwidth 50 pfc on priority-group 1 bandwidth 50 pfc off priority-pgid 1 1 1 0 1 1 1 1 !
- Изменено Victor Miasnikov 13 декабря 2017 г. 9:46
13 декабря 2017 г. 9:41 -
еще на заре серверов поколения 2012 сами майки где то в дебрях технета писали, что "если вы объединяете сетевые интерфейсы в тим, то обязательно оставьте свободным хотя бы один для возможности управления хостом... а если вы еще и в кластер собираете, то еще один свободный не помешает для внутрикластерной связи..." (как то так в памяти сохранилось). к сожалению за давностью лет ссылку не могу предоставить...
upd: вот нашел ссылку на документ с описанием технологии тиминга, правда на вражеском языке...
Нашел кстати рекомендации MS, где они тонко намекают, что собирайте NIC Teaming, а потом его нарезать (если я их правильно понял:-)):
"NIC Teaming should not be used on iSCSI NIC’s. MPIO is the best method. NIC teaming can be used on the Management, Production (VM traffic), CSV Heartbeat and Live Migration networks" Взято от сюда.
Нашел более свежий документ с описанием технологии тиминга. Прочитав который задумался об использовании тиминга не на уровне хоста, а на уровне VM, тогда можно будет использовать фичи типа VMQ и SR-IOV.
16 марта 2018 г. 11:19 -
Нашел кстати рекомендации MS, где они тонко намекают, что собирайте NIC Teaming, а потом его нарезать (если я их правильно понял:-)):
"NIC Teaming should not be used on iSCSI NIC’s. MPIO is the best method. NIC teaming can be used on the Management, Production (VM traffic), CSV Heartbeat and Live Migration networks" Взято от сюда.
"Объеденение интерфейсов не должно использоваться для iSCSI интерфейсов. MPIO является лучшим методом. Объеденение интерфейсов может быть использовано для сетей управления, производственного трафика (Виртуальных Машин), проверку CSV и Live миграции". Вывод:
Давайте рассмотрим 2 ситуации, когда в кластере с общим хранилищем (SAN сеть мы не трогаем) и когда без.
NIC Teaming не подходит для подключения общего хранилища, но подходит для всего остального.
MPIO подходит для подключения общего хранилища к Hyper-V серверу.
Другими словами:
Если у Вас к серверу виртуализации подключается общее хранилище, то оно должно быть подключено с помощью технологии MPIO (минимум два интерфейса).
Сами виртуальные машины должны использовать технологию NIC Teaming (минимум два интерфейса).
Сам сервер виртуализации желательно управлять через отденьный интерфейс (минимум один интерфейс).
Итого: желательно иметь от 4-5 сетевых интерфейсов при использовании общего хранилища.- Изменено AnahaymModerator 16 марта 2018 г. 11:58
16 марта 2018 г. 11:49Модератор -
NIC Teaming не подходит для подключения общего хранилища, но подходит для всего остального.
MPIO подходит для подключения общего хранилища к Hyper-V серверу.Я согласен для SAN это MPIO и SMB Multichannel (для SMB3), по этому я сразу в посте обозначил, кроме SAN.
А так я нашел очень интересный цикл статей про сетевые архитектуры для Hyper-V 2012 R2 и выше, рекомендую к прочтению, особенно новичкам.
18 марта 2018 г. 21:54 -
Итого: желательно иметь от 4-5 сетевых интерфейсов при использовании общего хранилища.
Ни к чему: с Win 2016 достаточно 2-x
. . .
Physical Network Switch Topology
Each Azure Stack rack can contain one or more Scale Units (hyper-converged clusters) and contains three switches:
- Two DATA Top of Rack (ToR) switches for Windows Server 2016 Converged NIC (SDN + Storage)
- . . .
Each hyper-converged node contains a 2-port 10Gb (or faster) physical NIC. By using the new Switch Embedded Teaming (SET) feature, the DATA network can converge both SDN and Storage traffic, guaranteeing port and link resiliency. Each port is connected to its own ToR switch.
. . .
Azure Stack NIC and Switch
Each Azure Stack hyper-converged host requires a single dual-port 10Gb+ NIC that supports Remote Direct Memory Access (RDMA) for SMB Direct and can either be RoCE v2 or iWARP.
Each DATA ToR switch requires:
- BGP
- Data Center Bridging (DCB)
- Enhanced Transmission Selection (ETS)
- Priority Flow Control (PFC)
- Switch Independent Teaming used by the host
19 марта 2018 г. 11:07 -
Как я понял SET, это альтернатива NIC Teaming (а может даже и замена). Тогда возникает вопрос, в каких сценариях необходимо использовать SET, а в каких по старинке NIC Teaming. А то складывается впечатление, что SET это следующая ступень развития.
19 марта 2018 г. 16:08 -
Ни к чему: с Win 2016 достаточно 2-х
с 10 Gb конечно достаточно.19 марта 2018 г. 16:35Модератор -
Как я понял SET, это альтернатива NIC Teaming (а может даже и замена). Тогда возникает вопрос, в каких сценариях необходимо использовать SET, а в каких по старинке NIC Teaming. А то складывается впечатление, что SET это следующая ступень развития.
Если в кратце, то если у тебя одна двухголовая 10G сетевуха или несколько таких карт с RDMA и ты планируешь их объединять в тиму, то поднимаешь SET. Во всех других случаях, можешь на запариваться.
- Изменено PhilipOzhgikhin 20 марта 2018 г. 6:35
20 марта 2018 г. 6:15 -
У меня есть на одном из Hyper-V серверов двухголовая 10G сетевуха (без RDMA) + FC для сети SAN, как я понимаю в моем сценарии SET особого выигрыша не даст, кроме SR-IOV. А вот если была поддержка RDMA на 10G сетевухе логичней было использовать SET.20 марта 2018 г. 9:11
-
Да, смысл есть только для поддержки RDMA в тиминге.20 марта 2018 г. 11:53