NovsVMQ

O tym jak Broadcom z Hyper-V serwerem wspólnie o łysinę admina dbali.

Miłe złego początki. Czyli będzie taniej…..

Zachwalając M$ oraz jego rozwiązania wirtualizujące  mocno naciskałem na ich prostotę oraz redukcję kosztów utrzymania maszyn. Dość szybko jednak okazało się, że nie ma róży bez kolców. Zaczęło się bardzo prozaicznie. Jeden z „Advanced users (hehehhe 😉 )” koniecznie zażądał osobnej maszyny dla swoich celów służbowych. Maszyna została utworzona, skonfigurowana. Jako że w zasadzie jest to jakby oddzielny komputer i nie wpływa na działanie innych maszyn to został osadzony na standardowym hoście wirtualizacji. Był to również dom serwera aplikacji co później okaże się zabójcze. Następnie rozpoczęła się faza „do mnie gigabajty” czyli pobieranie niezbędnego softu. Jako, że najlepszym pobieraczem jest torrent to został szybko zainstalowany i rozpoczął zasysanie obrazów ISO. Transfery doszły błyskawicznie do sumy wszystkich łączy. Wtedy zadzwonił telefon:

Panie Pawle mam szary ekran i nie mogę pracować.

Jak to szary ? A co było robione ? – zadałem pytania.

Nic. Po prostu chciałem wystawić fakturę i system nie działa – padła odpowiedź.

Szybki ping do serwera aplikacji i ….. „Upłynął limit czasu żądania”. Ale jak upłynął, przecież to jest postawione na SSD, potężnych procesorach i agregacji portów sieciowych. Taka sytuacja nie powinna mieć miejsca od tego jest failover clustering itp. Szybko doszedłem do tego, że zalanie pakietami hosta wirtualizacji powoduje utratę kontaktu z maszynami wirtualnymi. Nie pomaga agregacja portów. Nie pomaga osobny interfejs dla maszyn wirtualnych. Pomaga jedynie zmniejszenie natłoku pakietów na interfejsie używanym jako interfejs do komunikacji z maszynami wirtualnymi. Jakoś nie mogłem się pogodzić z tym że, nie mogę używać maszyn wirtualnych jak chcę. Rozpoczęły się poszukiwania rozwiązań.

Łączymy fakty

Wszelakie opisy tego typu problemów oscylowały zawsze wokół następujących słów kluczowych: Broadcom, VMQ, TCP Offload, NIC TEAMING. W efekcie skończyło się tym, że zostały zmienione opcje zaznaczone na poniższym zrzucie ekranu.

bcm

 Zrzut zawiera ustawienia aktywne konieczne do wyeliminowania problemu znikających maszyn wirtualnych.

Teraz działa wszystko idealnie pozostaje jednak pytanie jak zachowa się klaster przy „Live migration” bez interface wspierającego VMQ. Pozostaje niedosyt oraz niesmak po całym zajściu. Okazuje się, że teaming kart sieciowych używając oprogramowania oraz sterowników Broadcoma powoduje więcej problemów niż przynosi korzyści.

Grafika wyróżniajaca pobrana ze strony http://www.hypervrockstar.com/tag/dvmq/