Jednym z najczęściej pomijanych tematów przy optymalizacji serwerów jest wydajność transmisji danych TCP/IP. Odpowiednie dobranie i konfiguracja pod konkretne zastosowanie kart sieciowych jest w stanie zniwelować nawet o 20% narzut i obciążenie CPU, zwiększając jednocześnie maksymalną przepustowość.
Systemy ESX serii 3.x już w domyślnej konfiguracji oferują bardzo wydajną obsługę stosu TCP dzięki modułom vmxnet. Dzięki nim jesteśmy w stanie osiągnąć 85-90MB/s pomiędzy VM'ami przy wykorzystaniu tylko jednego linka 1Gb/s. Łatwo jest policzyć, że daje nam to praktycznie 90% wykorzystanie pasma. Aby osiągnąć taki wynik należy zwrócić uwagę na jeden bardzo istotny fakt – przerwania IRQ.
IRQ
Na powyższym zestawieniu bardzo łatwo zauważyć problem, który znacznie ogranicza wydajność modułów lpfc (HBA FC) oraz vmnic0/1 (sieci ethernetowej).
Cała obsługa przerwań wektora 0x79 spoczywa tylko i wyłącznie na CPU0.
Przyczyny należy szukać w konsoli serwisowej (COS), która najwyraźniej jest właścicielem jakiegoś modułu sprzętowego obsługiwanego przez identyczne przerwanie (COS irq 16 (PCI level) i brak nawiasów '<' '>') co interesujące nas karty I/O.
W takiej konfiguracji moduły hipervisora zmuszone są również do pracy tylko na CPU0, powodując w rezultacie znaczne straty wydajnościowe występujące podczas przełączania się procesora pomiędzy dwoma światami (COS i VMK). W takim razie co jeszcze wykorzystuje nam przerwanie 16 ?
USB
Jest nim kontroler USB. Warto zwrócić uwagę na oznaczenia – C opisujące urządzenie wykorzystywane przez konsolę serwisową, V przez hipervisor – co potwierdza współdzielenie przerwania, które wcześniej zauważyliśmy. Aby sprawdzić który moduł jest używany należy użyć poniższego polecenia.
USB
Przerwanie 16 zajmują moduły usb-uhci oraz ehci_hcd, których można się pozbyć w najprostszy sposób poleceniem `modprobe -r ehci-hcd usb-uhci`.
Należy jednak liczyć się z tym, że niemożliwe stanie się administrowanie poprzez podłączenie bezpośrednie konsolą szeregową (tj. RSA, DRAC czy iLO). Dobrym rozwiązaniem jest też zmiana przerwania dla kontrolera USB w BIOS'ie serwera, jednak może przenieść problem na inny komponent serwera (jak kontroler RAID).
Pomyślna zmiana konfiguracji powinna dać nam znaczny wzrost wydajności dzięki równomiernemu rozłożeniu obsługi I/O, widocznemu poniżej :
IRQ
W nowszej wersji ESX 4.0 – vSphere – zmieniona została obsługa sprzętu eliminując jednocześnie problem jednego CPU. Jedynym właścicielem urządzeń jest VMKernel.
Niezależnie od wersji, chcąc uzyskać najlepsze rezultaty należy korzystać z kart sieciowych wspierających sprzętowy offloading sumy kontrolnej, segmentacji TCP oraz większych ramek (Jumbo Frames). Ruch produkcyjny, komunikacyjny pomiędzy VM'ami czy obsługujący transmisję danych do macierzy (Vmotion, NFS, iSCSI) powinien być umieszczany na oddzielnych fizycznych linkach, zapobiegając nadmiernemu wysyceniu. Dlaczego ramki Jumbo są istotne skoro nie powodują polepszenia przepustowości ? Przede wszystkim zmniejszają radykalnie zapotrzebowanie na cykle procesora, który mniej czasu musi poświęcać na obsługę przerwań. Zamiast standardowej wielkości ramki 1500 bajtów, ramka Jumbo może mieć rozmiar do 9000. Dzięki temu o wiele więcej danych może być przesłane w pojedynczej ramce.
Niestety przystosowanie infrastruktury sieciowej pod to rozwiązanie wymaga od nas więcej pracy – należy zmienić rozmiar MTU na każdym urządzeniu biorącym udział w transmisji z serwera A do B. W systemach UNIX/Linux należy skorzystać z polecenia „ifconfig ethX/bgeX/emX mtu 9000”, Windowsy posiadają odpowiednią opcję we właściwościach interfejsu VMWare PCI Ethernet Adapter ->MTU. Następnie dostosować należy switch'e wirtualne serwerów ESX wydając polecenie „esxcfg-vswitch -m 9000 vSwitchX” oraz wszelkie fizyczne urządzenia biorące udział w transmisji pakietów. Odpowiednia wielkość MTU powinna być dobrana biorąc pod uwagę dane, którymi serwery będą się wymieniać. Chcąc zoptymalizować dostęp do storage'u VMFS udostępnionego poprzez iSCSI czy NFS, rozmiar ramki powinien równać się wielkości pojedynczego logicznego bloku dysku – w większości przypadków będzie to 4000 bajtów.