none
Рекомендации по настойки сети Hyper-V RRS feed

 > 

  • Общие обсуждения

  • Discussion
    Нужно войти
    0
    Нужно войти

    Добрый день, коллеги!

    Есть какие-то Best Practices по настройки сети на Hyper-V серверах, сейчас стандартный сервер идет с 4*1Gb интерфейсами.

    Давайте рассмотрим 2 ситуации, когда в кластере с общим хранилищем (SAN сеть мы не трогаем) и когда без. Кто как настраивает, объединяете вы в NIC TEAM, а поверх делаете виртуальные интерфейсы по различные виды трафика (управление, резервное копирование, миграции и т.п.) или не используете агрегацию канала  оперируете физическими интерфейсами для разделения трафика. За любые статье по этому поводу буду признателен.


    17 ноября 2017 г. 12:12
    |

Все ответы

  • Discussion
    Нужно войти
    0
    Нужно войти
    https://technet.microsoft.com/en-us/library/dn550728(v=ws.11).aspx 
    12 декабря 2017 г. 8:56
    |
  • Discussion
    Нужно войти
    1
    Нужно войти

    еще на заре серверов поколения 2012 сами майки где то в дебрях технета писали, что "если вы объединяете сетевые интерфейсы в тим, то обязательно оставьте свободным хотя бы один для возможности управления хостом... а если вы еще и в кластер собираете, то еще один свободный не помешает для внутрикластерной связи..." (как то так в памяти сохранилось). к сожалению за давностью лет ссылку не могу предоставить...

    upd: вот нашел ссылку на документ с описанием технологии тиминга, правда на вражеском языке...

    • Изменено RAMzez_ 12 декабря 2017 г. 11:50 upd
    12 декабря 2017 г. 11:18
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    Если все манипуляции проводить на уровне физ. адаптеров получается не очень рациональное использование сетевых ресурсов. Два линка отдавать под харбит и управление получается 50% пропускной способности.<o:p></o:p>

    Как мне кажется целесообразней настругать нужное кол-во виртуальных адаптеров. Да и есть рекомендации относительно LACP, где рекомендуют четное кол-во адаптеров объединять в группу.<o:p></o:p>

    12 декабря 2017 г. 11:41
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    ~~

    Есть какие-то Best Practices по настройки сети на Hyper-V серверах,
    сейчас стандартный сервер идет с 4*1Gb интерфейсами.

    ~~

     Скорее 2*10Gb

    "Последние моды":

    Cisco Nexus 3132

    https://github.com/Microsoft/SDN/tree/master/SwitchConfigExamples/Cisco%20Nexus%203132%20-%20Redundant%20TOR

    Switch Configuration Examples for Microsoft SDN

    Switch 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   .
.      +-------------------+               .
............................................


    13 декабря 2017 г. 9:40
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    Dell Force10 S4810

    https://github.com/Microsoft/SDN/tree/master/SwitchConfigExamples/Dell%20Force10%20S4810%20-%20Redundant%20TOR%20with%20Aggregate

    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 RDMA

    For 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
!

    13 декабря 2017 г. 9:41
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    еще на заре серверов поколения 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
    |
  • Discussion
    Нужно войти
    1
    Нужно войти
    Нашел кстати рекомендации 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 сетевых интерфейсов при использовании общего хранилища.

    16 марта 2018 г. 11:49
    |
    Модератор
  • Discussion
    Нужно войти
    0
    Нужно войти

    NIC Teaming не подходит для подключения общего хранилища, но подходит для всего остального.
    MPIO подходит для подключения общего хранилища к Hyper-V серверу.

     Я согласен для SAN это MPIO и SMB Multichannel  (для SMB3), по этому я сразу в посте обозначил, кроме SAN.

    А так я нашел очень интересный цикл статей про сетевые архитектуры для Hyper-V 2012 R2  и выше, рекомендую к прочтению, особенно новичкам.


    18 марта 2018 г. 21:54
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    Итого: желательно иметь от 4-5 сетевых интерфейсов при использовании общего хранилища.

    Ни к чему: с Win 2016 достаточно 2-x

    http://hyper-v.nu/archives/hvredevoort/2016/09/microsoft-ignite-2016-day-3-dive-into-microsoft-azure-stack-architecture-part-2/

     . . .

    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
    |
  • Discussion
    Нужно войти
    0
    Нужно войти

    Как я понял SET, это альтернатива NIC Teaming (а может даже и замена). Тогда возникает вопрос, в каких сценариях необходимо использовать SET, а в каких по старинке NIC Teaming. А то складывается впечатление, что SET это следующая ступень развития.


    19 марта 2018 г. 16:08
    |
  • Discussion
    Нужно войти
    0
    Нужно войти
    Ни к чему: с Win 2016 достаточно 2-х

    с 10 Gb конечно достаточно.
    19 марта 2018 г. 16:35
    |
    Модератор
  • Discussion
    Нужно войти
    0
    Нужно войти

    Как я понял SET, это альтернатива NIC Teaming (а может даже и замена). Тогда возникает вопрос, в каких сценариях необходимо использовать SET, а в каких по старинке NIC Teaming. А то складывается впечатление, что SET это следующая ступень развития.

    Если в кратце, то если у тебя одна двухголовая 10G сетевуха или несколько таких карт с RDMA и ты планируешь их объединять в тиму, то поднимаешь SET. Во всех других случаях, можешь на запариваться.


    20 марта 2018 г. 6:15
    |
  • Discussion
    Нужно войти
    0
    Нужно войти
    У меня есть на одном из Hyper-V серверов двухголовая 10G сетевуха (без RDMA) + FC для сети SAN, как я понимаю в моем сценарии SET особого выигрыша не даст, кроме SR-IOV.  А вот если была поддержка RDMA на 10G сетевухе логичней было  использовать SET.
    20 марта 2018 г. 9:11
    |
  • Discussion
    Нужно войти
    0
    Нужно войти
    Да, смысл есть только для поддержки RDMA в тиминге.
    20 марта 2018 г. 11:53
    |