VMware vSphere to najpopularniejsza i najbardziej rozwinięta platforma wirtualizacji na rynku. Od wielu lat wdrażam tą technologię i niejednokrotnie spotykam się z pytaniami dotyczącymi metod balansowania ruchem sieciowym pomiędzy fizycznymi kartami. W niniejszym artykule przedstawię dostępne mechanizmy oraz postaram się wyjaśnić jak one działają.
Udostępnij!
Dwa podstawowe rodzaje sieci wirtualnych
W środowisku VMware vSphere mamy dwa podstawowe rodzaje sieci wirtualnych – sieci oparte o przełączniki typu „standard” oraz „distributed” (dystrybuowane) Pierwszy wymieniony typ sieci jest dostępny w każdej edycji VMware vSphere (nawet w darmowej) natomiast przełączniki dystrybuowane zawarte są tylko w licencji Enterprise Plus oraz Operations Management Enterprise Plus.
W obu przypadkach mamy możliwość konfiguracji redundancji i balansowania ruchu sieciowego przy wykorzystaniu wielu fizycznych kart sieciowych serwera (hosta):
Każda maszyna wirtualna (VM) by móc komunikować się ze światem zewnętrznym lub innymi maszynami wirtualnymi musi posiadać swoją wirtualną kartę sieciową (network adapter). Taka karta powinna być wpięta do portu (port ID) wirtualnego przełącznika (vSwitch) tak jakby miało to miejsce z fizycznymi serwerami. Oczywiście dla każdego połączenia port ID będzie miał różne wartości.
Przełączniki typu standard
W wirtualnych przełącznikach typu standard mamy dostępne następujące polityki balansowania ruchu :
- Route based on originating virtual port ID
- Route based on source MAC hash
- Route based on IP hash
- Use Explicit failover order
Przełączniki typu distributed
W wersji przełączników dystrybuowanych dodatkowo dostępna jest polityka:
- Route based on physical NIC load.
Każdy z wymienionych mechanizmów ma swoje zalety ale również ograniczenia a wybór właściwego jest uzależniony od naszych potrzeb.
Route based on originating virtual port ID
Route based on originating virtual port ID – jest to domyślna polityka, która nie wymaga dodatkowej konfiguracji warstwy fizycznej. Algorytm wyboru fizycznej karty do komunikacji przypomina trochę round-robin i w naszym przypadku możemy dla uproszczenia założyć, że będzie on wyglądał następująco:
- maszyna VM A będzie używała karty sieciowej vmnic1
- maszyna VM B będzie używała karty sieciowej vmnic2
- maszyna VM C będzie używała karty sieciowej vmnic3
- maszyna VM D będzie używała karty sieciowej vmnic1
Należy zauważyć, że np. wyłączenie maszyn VM B i VM C nie spowoduje równomiernego rozłożenia ruchu – pozostałe uruchomione maszyny będą używały wyłącznie karty vmnic1 i dopiero awaria tego połączenia spowodowałaby zmianę „przypisania” karty fizycznej dla obu maszyn.
Algorytm ten nie wymaga dużego nakładu obliczeniowego ze strony hypervisora gdyż VMkernel w tym wypadku nie musi zaglądać do wnętrza pakietów. Do wyboru którą fizycznej karty użyć posługuje się wartością port ID.
Tą politykę możemy śmiało stosować zwłaszcza jeśli ilość maszyn uruchomionych na hoście będzie większa niż ilość fizycznych kart. Jest to mechanizm „switch independed” czyli możemy np. każdą z fizycznych kart sieciowych podłączyć do innego przełącznika.
Jeśli maszyna wirtualna posiada więcej niż jedną wirtualną kartę sieciową będzie też posiadała więcej niż jeden port ID (dla każdego wirtualne adaptera sieciowego będzie istniał inny port ID) i w efekcie ruch z takich maszyny będzie rozkładany tak jakby to był ruch z innej maszyny.
Poniżej przykład maszyny VM1 (proces o numerze World ID 41268) posiadającej 3 karty sieciowe wpięte do tego samego przełącznika (vSwitch0) i wybrane karty fizyczne do transmisji (Uplink)
Route based on source MAC
Route based on source MAC hash – jest to polityka, w której wybór fizycznej karty sieciowej wyliczany jest na podstawie MAC adresu źródłowego opuszczającego maszynę wirtualną oraz ilości kart fizycznych łącza. VMkernel „zagląda” do środka komunikacji i dokonuje obliczeń dla każdego pakietu stąd większy nakład pracy na hypervisora.
Ponieważ MAC adres karty maszyny wirtualnej raczej jest stały powstaje relacja niemalże identyczna jak w algorytmie „Route based on originating virtual port ID” a zatem po co powstał ten mechanizm i czemu ma służyć skoro zalety takie same ale znacznie większe nakłady ?
Dodatkowo istnieje zagrożenie, że dla dwóch różnych MAC adresów wynik kalkulacji łącza będzie taki sam (tzn. istnieje możliwość, że algorytm dla 3 różnych maszyn wybierze tą samą fizyczną kartę).
Istnieją scenariusze (choć rzadko spotykane), w których ten algorytm mógłby się świetnie sprawdzić.
Może to być wdrożenie wirtualnego appliance, który z punktu widzenia sieci będzie pracował w warstwie drugiej w trybie transparentnym i np. monitorował bądź chronił ruch sieciowy. Przykładem tutaj może być Fortigate Appliance. Takie rozwiązanie może „przepuszczać” ruch sieciowy w obie strony nie zmieniając MAC adresów występujących w komunikacji. Jeśli połączyłoby się tak dwie części tej samej sieci wówczas z pewnością ruch byłby doskonale balansowany.
Route based on IP hash
Route based on IP hash – ten algorytm będzie bardzo dobrze równoważył obciążenie między fizycznymi kartami kalkulacji bowiem dokonuje się na podstawie źródłowego i docelowego adresu IP.
Zatem ruch z jednej maszyny wirtualnej do różnych odbiorców może odbywać się różnymi ścieżkami.
Jednak wymagana tu jest już ingerencja w środowisko gdyż należy po stronie fizycznego przełącznika skonfigurować obsługę protokołu 802.3ad (etherchannel). Jest to również mechanizm najbardziej obciążający VMkernela gdyż wyliczanie interfejsu dokonywane jest dla każdego pakietu.
Do obliczenia wykorzystuje się następującą formułę :
(SourceHEX Xor DestHEX) Mod UplinkCount = InterfaceIndex
gdzie
SourceHEX – źródłowy adres IP przekonwertowany do postaci szesnastkowej
DestHEX – docelowy adres IP przekonwertowany do postaci szesnastkowej
UplinkCount – ilość fizycznych kart sieciowych (z których korzysta nasz vSwitch)
Należy wziąć pod uwagę to, że niekoniecznie wszystko będzie idealnie rozłożone – w zależności od danych wejściowych możemy otrzymać ten sam InterfaceIndex !
Chętnych większego pogłębienia wiedzy w zakresie tej polityki balansowania odsyłam na strony :
https://blogs.vmware.com/kb/2013/03/troubleshooting-network-teaming-problems-with-ip-hash.html
Use Explicit failover order
Use Explicit failover order – przełącznik wirtualny używa zawsze uplinka, który jest pierwszy na liście aktywnych adapterów z sekcji Failover order jeśli spełnia wszystkie wymogi dotyczące poprawności pracy sieci (tzn. nie został wykryty żaden problem). Jeśli wszystkie aktywne uplinki przestaną działać system zacznie używać kart z sekcji Standby.
Route based on physical NIC load
Route based on physical NIC load – polityka ta działa w oparciu o „Route Based on Originating Virtual Port” gdzie dodatkowo wirtualny przełącznik sprawdza aktualne obciążenie fizycznego uplinka i podejmuje działania w celu zredukowania pracy na przeciążonych łączach. Dokładnie co 30 sekund system sprawdza czy obciążenie na danej karcie nie przekroczyło 75% jej wydajności – wówczas port ID o najwyższym stopniu operacji wejścia/wyjścia (I/O) jest przenoszony na inny uplink.
Algorytm ten jest bardzo wydajny. By wyznaczyć adapter obliczenie wykonuje się raz, stąd mały nakład pracy VMkernela (podobnie jak w Originaiting Virtual Port). Testowane są jedynie przeciążenia. Mechanizm Route based on physical NIC load nie wymaga żadnych zmian w sieci fizycznej.
