Good day! Thanks for your reply.
I agree with you, it is better to separate Hyper-V iSCSI traffic.
I spent several days studying the articles trying to figure out what could be improved.
My initial idea was to install two identical 4-port NICs in the server and configure Teaming with Hyper-V.
node1 node2
NIC1 port1 + NIC1 port1 => Team1
NIC1 port2 + NIC1 port2 => Team2
NIC1 port3 + NIC1 port3 => Team3
NIC1 port4 + NIC1 port4 => Team4
In case of failure not only of a single port, but also of any of the two network cards completely, the system will remain operational. Redundancy will be provided due to the redundancy of the physical ports of the two network cards.
The link
https://www.starwindsoftware.com/best-p ... practices/ in the paragraph "Teaming and Multipathing best practices" says "StarWind Virtual SAN does not support any form of NIC teaming for resiliency or throughput aggregation. "
But following the link
https://www.starwindsoftware.com/blog/w ... tionality/, it became clear to me that teaming using Windows is still supported.
(Q1) Is redundancy (Windows Teaming) of two 4-port 1 / 2.5 / 5 / 10Gbe NICs supported in StarWind?
Why am I considering the 4-port option? Now I work with HP servers, and previously I worked with 1U SuperMicro servers. Usually in 1U SuperMicro there are only 2 network interfaces + 1 PCIe slot, where you can install only one network card (2 or 4 ports). If you install an additional network card, then the SuperMicro server will have 4 (2 + 2) or a maximum of 6 (2 + 4) network ports.
******
I came up with such a scheme with one 4-port card (in the HP 4 * 1Gbe server) + install one 10GB (for example TP-Link TX401). (Why this particular TP-Link model? Firstly - the price, secondly - a good heatsink, thirdly - the official website has drivers for 32 and 64-bit Windows 7, 8, 8.1, 10, Windows Server 2008, 2012, 2016, 2019. And for Linux kernel> 3.10.)
A two-node Hyper-V cluster without external storage.
Node1 and Node2 (physical connection + network traffic distribution)
Node1 Node2
NIC1 port1 (1Gbe) ==== switch ==== NIC1 port1 (1Gbe) - Client access to guest VMs (production network) + Hyper-V management + StarWind management + Hyper-V heartbeat + Hyper-V CSV sync
NIC1 port2 (1Gbe) =============== NIC1 port2 (1Gbe) - Hyper-V heartbeat + Hyper-V CSV sync + Hyper-V live migration (fallback)
NIC1 port3 (1Gbe) =============== NIC1 port3 (1Gbe) - StarWind sync + StarWind heart rate (main)
NIC1 port4 (1Gbe) =============== NIC1 port4 (1Gbe) - StarWind pulse (optional1)
NIC2 port1 (10Gbe) ============== NIC2 port1 (10Gbe) - Hyper-V iSCSI traffic + live migration (main) Hyper-V + Hyper-V heartbeat + CSV synchronization Hyper- V + StarWind sync + StarWind pulse (optional2)
The first NIC1 ports on both nodes are connected to the switch, since needs client access to guest virtual machines. All other ports are connected directly from node to node.
Clarification from me: "Hyper-V Failover Cluster Manager" in the NIC settings can be prioritized for live migration. This is what I mean for "live migration (main + fallback) Hyper-V"
Main - high priority
Fallback - low priority
Typically live migration does not overlap with iSCSI traffic. iSCSI traffic is heavy during initial startup of guest virtual machines. And live migration can be done on weekends (for example, for host maintenance). Therefore, I combined these two traffic in one 10Gbe interface.
(Q2) Is the option (suggested by me above) with two network cards (4 * 1Gbe + 1 * 10Gbe) correct?
I think that you can add another 1 * 10Gbe to the scheme and completely separate the traffic of the live Hyper-V migration, then the scheme would turn out to be quite good.
******
And there were several questions about the StarWind cluster network operation.
When configuring a StarWind cluster at
https://www.starwindsoftware.com/resour ... rver-2016/ in " Heartbeat "in point 5 when configuring the network, the interfaces for" Sync + Heartbeat "and" Heartbeat "are selected
An additional "Heartbeat" is configured so that if the "Sync + Heartbeat" interface is damaged, a split brain does not work, as written at the link
https://www.starwindsoftware.com/blog/w ... and-how-to -avoid-it /
(Q3) How does StarWind choose which interface (if multiple interfaces were selected in the "Specify the interfaces for Synchronization and Heartbeat Channels" setting) will synchronization and heartbeat occur?
(Q4) Do you plan to remove "Heartbeat" in future versions, replacing it with "Sync + Heartbeat"? For example, a Hyper-V cluster does not have a dedicated "Heartbeat".
(Q5) If only "Heartbeat" stops working, will the pulse be transmitted via "Sync + Heartbeat"?
(Q6) Is it possible in StarWind to manually (force) prioritize (if the primary (high priority) interface is damaged, it switches to the backup (low priority) interface) to select the clock and heart rate interfaces?
(Q7) Do you plan to add priorities for choosing interfaces for synchronization and heartbeat in future versions of StarWind?
Now let's imagine the following situation:
Guest virtual machines are evenly distributed across two nodes of the cluster (node1 and node2). "Sync + Heartbeat" between nodes only one without redundancy.
(Q8) How will StarWind prioritize nodes (high-low) if "Sync + Heartbeat" stops working (only "Heartbeat" remains)?
(Q9) What algorithm will StarWind use which of the two nodes will become unsynchronized?
(Q10) What will be the consequences for the guest virtual machines located on node1 and node2, if for example node2 gets low priority and unsynchronized mode?
(Q11) If ALL guest VMs are on node1 only, is node2 guaranteed to get low priority and unsynchronized mode?
(Q12) I know it is possible to configure a witness to avoid this situation, but what if the witness was not configured?
******
I also wanted to suggest you correct something:
1. Correct the instructions (check the "Enable multipath" checkbox for target "Witness") in the instructions at the link starwindsoftware.com/resource-library/starwind-virtual-san-for-hyper-v-2-node-hyperconverged-scenario-with -windows-server-2016 /
2. I think that during configuration, when choosing a cluster size (512 or 4096), it is worth placing a hint (512 for ESXi, 4096 for Hyper-V)
Excuse me for such long messages, I don't want to offend anyone, maybe it's just an out-of-date documentation. Working as a system administrator, I realized that the more accurate and detailed the instructions, the fewer errors and questions users have.
I have numbered all the questions to make it easier to answer.
Добрый день! Спасибо за Ваш ответ.
Я согласен с Вами, Hyper-V iSCSI-трафик лучше отделить.
Я несколько дней изучал статьи пытаясь понять что можно улучшить.
Моя первоначальная идея состояла в том, чтобы установить две одинаковые 4-портовые сетевые карты в сервер и настроить Teaming средствами Hyper-V.
node1 node2
NIC1 порт1 + NIC1 порт1 => Team1
NIC1 порт2 + NIC1 порт2 => Team2
NIC1 порт3 + NIC1 порт3 => Team3
NIC1 порт4 + NIC1 порт4 => Team4
В случае выхода из строя не только одиночного порта, но и любой из двух сетевых карт полностью - система останется работоспособной. Будет обеспечено резервирование за счёт избыточности физических портов двух сетевых карт.
По ссылке
https://www.starwindsoftware.com/best-p ... practices/ в пункте "Teaming and Multipathing best practices" написано "StarWind Virtual SAN does not support any form of NIC teaming for resiliency or throughput aggregation."
Но по ссылке
https://www.starwindsoftware.com/blog/w ... tionality/ мне стало понятно, что teaming средствами Windows всё-таки поддерживается.
(Q1)Поддерживается ли резервирование(Windows Teaming) из двух 4-портовых сетевых карт 1/2,5/5/10Gbe в StarWind?
Почему я рассматриваю вариант именно с 4 портами? Сейчас я работаю с серверами HP, а ранее я работал с 1U серверами SuperMicro. Обычно в 1U SuperMicro всего 2 сетевых интерфейса + 1 слот PCIe, куда можно установить только одну сетевую карту(2 или 4 порта). Если установить дополнительную сетевую карту, то в сервере SuperMicro получится 4(2+2) или максимум 6(2+4) сетевых портов.
******
Придумал вот такую схему с одной 4-портовой картой(в сервере HP 4*1Gbe) + установить одну 10GB(например TP-Link TX401). (Почему именно эта модель TP-Link? Во-первых - цена, во-вторых - хороший радиатор, в-третьих - на официальном сайте есть драйверы для 32 и 64-разрядной Windows 7, 8, 8.1, 10, Windows Server 2008, 2012, 2016, 2019. И для ядра Linux > 3.10.)
Кластер Hyper-V из двух нод без внешнего хранилища.
Node1 and Node2(физическое соединение + распределение сетевого трафика)
Node1 Node2
NIC1 порт1(1Gbe)====switch====NIC1 порт1(1Gbe) - Клиентский доступ к гостевым виртуальным машинам(производственная сеть) + управление Hyper-V + управление StarWind + пульс Hyper-V + синхронизация CSV Hyper-V
NIC1 порт2(1Gbe)==============NIC1 порт2(1Gbe) - пульс Hyper-V + синхронизация CSV Hyper-V + живая миграция(резервная) Hyper-V
NIC1 порт3(1Gbe)==============NIC1 порт3(1Gbe) - синхронизация StarWind + пульс StarWind(основной)
NIC1 порт4(1Gbe)==============NIC1 порт4(1Gbe) - пульс StarWind(дополнительный1)
NIC2 порт1(10Gbe)=============NIC2 порт1(10Gbe) - Hyper-V iSCSI-трафик + живая миграция(основная) Hyper-V + пульс Hyper-V + синхронизация CSV Hyper-V + синхронизация StarWind + пульс StarWind(дополнительный2)
Первые порты NIC1 на обеих нодах подключёны в свитч, т.к. нужен клиентский доступ к гостевым виртуальным машинам. Все остальные порты подключены напрямую из ноды в ноду.
Пояснение от меня: "Диспетчер отказоустойчивости кластера Hyper-V" в настройках сетевых карт можно настроить приоритетность для живой миграции. Именно это я имею ввиду для "живая миграция(основная+резервная) Hyper-V"
Основная - высокий приоритет
Резервная - низкий приоритет
Обычно живая миграция не совпадает по времени с трафиком iSCSI. iSCSI трафик интенсивен при первоначальном запуске гостевых виртуальных машин. А динамическая миграция может быть проведена в выходные(например для технического обслуживания хостов. Поэтому эти два трафика я объединил в одном интерфейсе 10Gbe.
(Q2)Вариант(предложенный мной выше)с двумя сетевыми картами(4*1Gbe + 1*10Gbe) правилен?
Думаю, что в схему можно добавить ещё 1*10Gbe и полностью отделить трафик живой миграции Hyper-V, тогда схема получилась бы совсем хорошей.
******
И появилось несколько вопросов по работе сети кластера StarWind.
При настройке кластера StarWind по ссылке
https://www.starwindsoftware.com/resour ... rver-2016/ в "Heartbeat" в пункте 5 при настройке сети выбираются интерфейсы для "Sync + Heartbeat" и "Heartbeat"
Дополнительный "Heartbeat" настраивается для того, чтобы в случае повреждения интерфейса "Sync + Heartbeat" не получился split brain, как написано по ссылке
https://www.starwindsoftware.com/blog/w ... -avoid-it/
(Q3)Как StarWind выбирает по какому интерфейсу(если при настройке "Specify the interfaces for Synchronization and Heartbeat Channels" было выбрано несколько интерфейсов) будет происходить синхронизация и пульс?
(Q4)Планируете ли Вы в будущих версиях убрать "Heartbeat", заменив его "Sync + Heartbeat"? Например в кластере Hyper-V нет выделенного "Heartbeat".
(Q5)Если перестанет работать только "Heartbeat", по "Sync + Heartbeat" будет передаваться пульс?
(Q6)Можно ли в StarWind вручную(принудительно) назначить приоритеты(в случае повреждения основного(высокий приоритет) происходит переключение на резервный(низкий приоритет) интерфейс)для выбора интерфейсов синхронизации и пульса?
(Q7)Планируете ли Вы в будущих версиях StarWind добавить приоритеты выбора интерфейсов для синхронизации и пульса?
Теперь представим такую ситуацию:
Гостевые виртуальные машины равномерно распределены на двух нодах кластера(node1 и node2). "Sync + Heartbeat" между нодами только один без резервирования.
(Q8)Как StarWind расставит приоритеты для нод(высокий-низкий), если "Sync + Heartbeat" перестанет работать(останется только "Heartbeat")?
(Q9)По какому алгоритму StarWind выберет какая из двух нод станет несинхронизированной?
(Q10)Какие будут последствия для гостевых виртуальных машин находящихся на node1 и node2, если например node2 получит низкий приоритет и несинхронизированный режим?
(Q11)Если ВСЕ гостевые виртуальные машины будут находиться только на node1, то гарантированно ли node2 получит низкий приоритет и несинхронизированный режим?
(Q12)Я знаю, что можно настроить свидетель для исключения такой ситуации, но что делать если свидетель не был настроен?
******
Я также хотел предложить Вам кое-что поправить:
1. Поправить инструкцию(отметить checkbox "Enable multipath" для target "Witness") в инструкции по ссылке starwindsoftware.com/resource-library/starwind-virtual-san-for-hyper-v-2-node-hyperconverged-scenario-with-windows-server-2016/
2. Думаю что во время настройки при выборе размера кластера(512 или 4096) стоит разместить подсказку(512 для ESXi, 4096 для Hyper-V)
Извините меня за столь длинные сообщения, я не хочу никого обидеть, возможно дело просто в неактуализированной документации. Работая системным администратором я понял, что чем точнее и подробнее инструкции, тем меньше ошибок и вопросов у пользователей.
Я пронумеровал все вопросы, чтобы было удобнее отвечать.
. And, those are really good points. Will ask my colleagues to address them.