Wirtualizacja jako taka to już pojęcie nie najnowsze, a wirtualizacja routerów? Wiele osób jeszcze niechętnie patrzy w stronę zastąpienia "sprawdzonych", sprzętowych routerów "uznanych producentów" czymś innym, czyli zwykle mimo wszystko mniej sprawdzonymi, choć niekoniecznie gorszymi rozwiązaniami programowymi - na przykład wykorzystywaną przez nas linuksową dystrybucją Vyatta. Takie rozwiązania mają właśnie tę niepodważalną zaletę, której sprzęt Cisco, Junipera czy kogokolwiek innego nie posiada - można je przenieść na hypervisor i tam tanim kosztem zapewnić redundancję, migrować "na żywo" pomiędzy serwerami czy skalować wraz ze wzrostem obciążenia. Pytanie tylko - jaki wybrać hypervisor?
Router jest szczególnym elementem każdej infrastruktury - zwykle gdy ten element zawodzi, nie ma sensu funkcjonowanie całej reszty, która za nim stoi. Migrację z Cisco 7140 na linuksową dystrybucję Vyatta przeprowadziliśmy z powodzeniem jeszcze w 2008 roku i byliśmy pod wrażeniem, jak Linux radzi sobie z przerzuceniem wówczas ponad 100 megabitów ruchu na low-endowym serwerze z procesorem Core 2 Duo. Rok później zdecydowaliśmy się na migrację większości infrastruktury do środowiska wirtualnego - w tej większości znalazła się też Vyatta (na marginesie, znalazło się w niej wszystko oprócz serwerów baz danych). Byliśmy ciekawi, czy system równie dobrze będzie funkcjonować jako maszyna wirtualna i czy sprosta surowym wymogom co do transferów i dopuszczalnych opóźnień. Okazuje się, że odpowiedź na to pytanie poznaliśmy dopiero teraz, po wypróbowaniu ostatniego hypervisora, czyli Citrix XenServer. Przysłowie "do trzech razy sztuka" było tu bardzo na miejscu :-)
Zacznijmy od początku i załóżmy, że interesują nas tylko bezpłatne hypervisory. Zanim odpowiem na tytułowe pytanie, zacznę od skreślenia Hyper-V. Nie ma co się oszukiwać - przy całej mojej sympatii i sentymentu do serwerowych rozwiązań Microsoftu niestety ten hypervisor nadal, po ponad dwóch latach od premiery i mimo zabiegów marketingowych producenta, nie nadaje się do wirtualizacji Linuksa. Obecnie nie ma jeszcze oficjalnie wspieranych przez Microsoft i Vyattę komponentów integracyjnych na kształt tych dostępnych u konkurencji, co praktycznie eliminuje Hyper-V z rozgrywki.
ESXi, a raczej VMware vSphere Hypervisor (niedawno przemianowany - żeby nazwa czasem nie była zbyt krótka, niż to dozwolone w korpo-polityce) prezentuje się tu dużo lepiej. Vyatta udostępnia prekonfigurowane obrazy maszyny wirtualnej w formacie OVF. Wszystko byłoby piękne, gdyby nie fakt, że bezpłatna wersja ESXi nie pozwalała na import takiej maszyny - przyznam, że nie wiem jak jest obecnie, bo od jakiegoś czasu ESXi już nie używam. To jednak też nie jest duży problem, bo można sobie pobrać obraz ISO płyty instalacyjnej w wersji dostosowanej do środowisk wirtualnych i po prostu zainstalować na czystej maszynie. To działa i działa nawet całkiem dobrze. Wraz ze wzrostem obciążenia ponad 150-200 Mbit/s pojawił się jednak dziwny problem: jakość komunikacji sieciowej z hostem ESXi, na którym działała Vyatta routująca taki ruch dramatycznie spadała. Przykładowo pobieranie instalatora vSphere Clienta przebiegało z prędkością mierzoną w bajtach na sekundę. Obserwowaliśmy także dużą stratę pakietów. Najgorsze jednak było to, że wszystkie maszyny wirtualne obok Vyatty na tym samym hoście również doświadczały tego problemu! Łączność była upośledzona jedynie "wewnątrz", czyli gdy ruch nie przechodził przez Vyattę. Mimo wszystko był to jednak ogromny problem. Nie rozwiązała go także zmiana typu wirtualnych kart sieciowych na Vyacie z zalecanych VMXNET3 na starsze E1000 - te drugie karty po prostu nie dawały rady i już przy ruchu ok. 100 Mbit/s przez brak offloadingu gotowały się procesory.
Zapoczątkowałem, jak się później okazało, bardzo interesujący wątek na forum Vyatty dotyczący powyższego problemu. Okazało się, że nie jesteśmy sami, choć początkowo Vyatta przerzucała ciężar sprawy na VMware. Na tamtejszym forum jednak nie uzyskałem w ogóle odpowiedzi. Po kilkunastu tygodniach diagnozowania problemu i rozmaitych, nieudanych prób zaczęło nam to doskwierać na tyle, że rozpoczęliśmy przymiarki do testów XenServer. Jak na ironię, gdy kończyliśmy już testy i praktycznie zdecydowaliśmy się na migrację, inżynierom Vyatty udało się ustalić, że problem podobno istotnie leży po stronie ESXi, a jego tymczasowym obejściem jest wyłączenie TCP Segmentation Offloading na kartach sieciowych VMXNET3, ale... nie na Vyacie, a na wszystkich maszynach wirtualnych stojących obok. Na dłuższą metę było to więc rozwiązanie dość karkołomne, a poza tym nie dało się tego zastosować na samym hoście ESXi. Najważniejsze jednak, że w międzyczasie XenServer wypadł w naszych testach bardzo pozytywnie i zdecydowaliśmy się migrować pomimo częściowego rozwiązania problemu z ESXi. Dla przyzwoitości dodam jedynie, że wydana kilka tygodni temu wersja VC6.1 Vyatty zawiera już wbudowaną poprawkę (a może raczej kolejne obejście) i problem nie powinien już być tak uciążliwy. Jeśli ktoś lubi łataninę, to po szczegóły odsyłam do wspomnianego wyżej wątku.
Po przetestowaniu wszystkich liczących się na rynku hypervisorów śmiało stwierdzam - XenServer jest najwygodniejszy jeśli chodzi o Vyattę. Wszystko działa tam jak należy (w tym XenMotion, bo XenServer ma go w wersji bezpłatnej!) i to nawet pod dużym obciążeniem. Nie trzeba też konfigurować niczego nadzwyczaj skomplikowanego. Wystarczy pobrać szablon XVA maszyny wirtualnej ze strony Vyatty, zaimportować go na serwer (co działa bez względu na typ licencji) i po prostu stworzyć na jego podstawie nową maszynę. Do dyspozycji jest tylko jeden typ wirtualnej karty sieciowej, więc nie można się pomylić. Po pierwszym uruchomieniu trzeba jedynie otworzyć w nano plik konfiguracyjny Vyatty znajdujący się w lokalizacji [i]/opt/vyatta/etc/config/config.boot[/i] i dopisać adres MAC do każdego interfejsu sieciowego. Powód? Vyatta osadza MAC w pliku konfiguracyjnym, a przecież budując szablon do pobrania dla wszystkich trudno było go przewidzieć... Aktualnie najnowszy (VC6.1) szablon XVA Vyatty ma wbudowane XenTools w wersji 5.5, więc jeśli mamy wydaną bardzo niedawno wersję 5.6 to trzeba zrobić aktualizację. Nie jest to jednak skomplikowane - montujemy /dev/xvdd czyli napęd CD z narzędziami XenTools i instalujemy pakiet .deb:
sudo mount /dev/xvdd /mnt
sudo dpkg -i /mnt/Linux/xe-guest-utilities_5.6.0-578_i386.deb
Podczas wizyty na tegorocznym Citrix Synergy rozmawiałem z inżynierem Cisco, który notabene znał Vyattę bardzo dobrze. Pytałem go między innymi o to, dlaczego jeszcze nie zauważyli rosnącej popularności wirtualizacji i tego, że wirtualne linuksowe routery mogą w krótkim czasie nieźle namieszać na rynku. Jak można się było spodziewać, otrzymałem wymijającą odpowiedź, ale pewnie byłoby ciekawie, gdyby Cisco zaczęło sprzedawać wirtualne routery - pytanie tylko, jak by je wyceniło? Dopóki to jednak nie nastąpi, polecam zastanowić się nad wirtualizacją Vyatty na jednym z hypervisorów - u nas najlepiej sprawdził się XenServer. Jeśli macie jakieś pytania, chętnie odpowiem w komentarzach :-)