Strojenie stosu klient / serwer NFS

Mam serwer VMWare CentOS 5 łączący się z maszyną OpenSolaris 2009.06 za pośrednictwem NFS, która przechowuje obrazy dysków. Wydaje mi się, że moje maszyny wirtualne są powolne we / wy, więc chciałbym zrobić wszystko, aby zoptymalizować połączenie.

Nie jestem pewien, jak najlepiej zmierzyć przepustowość w systemie produkcyjnym, ale niektóre nienaukowe testy wykorzystujące dd bs=1024k count=400zapisy lokalne (OpenSolaris) pokazują ~ 1,6 GB / si zdalne (CentOS) zapisują ~ 50 MB / s. Wyobrażam sobie, że są one niższe niż to, co faktycznie otrzymuję, ponieważ 7 maszyn wirtualnych jest obecnie uruchomionych przez połączenie.

Obecnie 2 maszyny są bezpośrednio połączonymi gigE z ramkami jumbo włączonymi na obu kartach sieciowych (MTU = 9000). Poza tym nie dokonano żadnych optymalizacji. Podczas montowania / eksportowania systemu plików NFS używane są ustawienia domyślne.

Gdzie powinienem zacząć obracać pokrętła, aby poprawić wydajność?

Żeby to wyjaśnić, dostajesz 50 MB / s z NFS przez jedno połączenie Ethernet Gb?

A na serwerze hosta działa CentOS z zainstalowanym VMware Server, który z kolei uruchamia 7 maszyn wirtualnych? Czy jest jakiś konkretny powód, dla którego zdecydowałeś się na połączenie CentOS i VMware Server zamiast VMware ESXi, które jest rozwiązaniem o wyższej wydajności?

50 MB / s nie jest świetne, ale nie jest znacznie poniżej tego, czego można oczekiwać po pojedynczym kablu sieciowym Gb - po wprowadzeniu poprawek NFS, o których wspominali ludzie, będziesz patrzeć na może 70- 80 MB / s Opcje wzdłuż linii:

„ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp”

są prawdopodobnie uzasadnione dla Ciebie na obu końcach systemu.

Aby przejść wyżej, musisz spojrzeć na połączenie kart sieciowych w pary, co powinno zwiększyć przepustowość o około 90%. Może być potrzebny przełącznik obsługujący standard 802.3ad, aby uzyskać najlepszą wydajność z agregacją łączy .

Jedną rzeczą, którą zasugerowałem, jest to, że przepustowość we / wy w pudełku OpenSolaris brzmi podejrzanie wysoko, 12 dysków prawdopodobnie nie będzie obsługiwać przepustowości 1,6 GB / s, a może być mocno buforowane przez Solaris + ZFS.

Do naszych maszyn RHEL / CentOS 5 używamy następujących flag montowania

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime

Nowsza wersja jądra Linux obsługuje jeszcze większe parametry rsize / wsize, ale 32k to maksimum dla jądra 2.6.18 w EL5.

Na serwerach NFS przynajmniej dla Linuksa podobno pomaga no_wdelay, jeśli masz kontroler dysku z BBWC. Ponadto, jeśli użyjesz flagi noatime na klientach, prawdopodobnie sensowne jest również zamontowanie systemów plików na serwerach z noatime.

I, jak już wspomniano, nie zawracaj sobie głowy UDP. W sieciach o większej prędkości (1GbE +) istnieje niewielka, ale niezerowa szansa na zawinięcie numeru sekwencji powodujące uszkodzenie danych. Ponadto, jeśli istnieje możliwość utraty pakietów, TCP będzie działał lepiej niż UDP.

Jeśli nie martwisz się tak bardzo o integralność danych, opcja eksportu „asynchronicznie” może znacznie poprawić wydajność (problem z asynchronią polega na tym, że możesz stracić dane w przypadku awarii serwera).

Ponadto, przynajmniej w przypadku serwera Linux, musisz upewnić się, że masz wystarczającą liczbę wątków serwera NFS. Domyślna wartość 8 jest po prostu zbyt niska.

Kiedyś zrobiłem test z Dell R710, 1 procesorem, 4 GB RAM, 6 dyskami SATA z RAID-10. Klientem był Sun x2100, zarówno z CentOS 5.3, jak i parametrami nfs, jak wspomniano powyżej

„ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp”

montowane po obu stronach z noatime.

Zwiększyłem też do nfsds do 256 i użyłem harmonogramu noop dla kontrolera RAID perc6. Inną rzeczą, którą zrobiłem, było wyrównanie partycji do rozmiaru paska 64K kontrolera RAID.

potem zmierzyłem wydajność nfs za pomocą dd - dla odczytów mogłem wypełnić fajkę gigE, ale dla zapisów mogłem uzyskać tylko trochę lepsze wyniki jak ty. Po włączeniu asynchronizacji mogłem uzyskać od 70 do 80 MB / s, ale async nie był dla mnie opcją.

Może nie możesz uzyskać więcej dzięki NFS z linku gigE?

Spróbuj: tymczasowo wyłącz Zent Log (ZIL) na serwerze NFS OpenSolaris, wykonując następujące dwa kroki

1. echo zil_disable/W0t1 | mdb -kw
2. ponownie zainstaluj partycję testową

Następnie przetestuj ponownie. Możesz użyć zilstat, aby upewnić się, że naprawdę nie ma więcej IO w ZIL. Jeśli test działa szybciej, wiesz, że problem z wydajnością ma coś wspólnego z ZIL. Jeśli nadal działa wolno, wiesz, że ZIL nie jest winowajcą i że użycie SSD dla ZIL również nie pomoże. Więcej informacji na temat ZIL można znaleźć w ZFS Evil Tuning Guide .

Inną opcją byłoby przechwytywanie ruchu sieciowego (np. Wireshark) i sprawdzanie, czy występują problemy np. Z ramkami Jumbo. Sprawdź, czy pakiety w sieci wyglądają tak, jak oczekujesz od konfiguracji. Czy dzieje się jakieś złe rozdrobnienie? Czy są retransmisje?

Pomocne może być zwiększenie rozmiarów ładunku do odczytu i zapisu. Zwłaszcza w połączeniu z ramkami typu jumbo.

Uważam, że 32k jest optymalne.

rsize=32768,wsize=32768

Przejście na transport UDP jest oczywiście szybsze niż TCP, ponieważ pozwala zaoszczędzić na sterowaniu transmisją. Ale ma to zastosowanie tylko w niezawodnych sieciach i tam, gdzie NFSv4 nie jest używany.

Wydajność NFS w ZFS jest znacznie poprawiona przez użycie SSD dla dziennika intencji ZFS (ZIL), ponieważ zmniejsza to opóźnienie operacji. Wątek o VMWare NFS o wydajności ZFS na listach mailingowych OpenSolaris NFS i ZFS zawiera dodatkowe informacje, w tym narzędzie do testowania, aby sprawdzić, czy wydajność ZIL jest wąskim gardłem.

Do Twojej wiadomości polecenie dd zapisze w pamięci podręcznej i bez dysku, możesz uzyskać szalone liczby, takie jak 1,6 G / s, ponieważ piszesz do pamięci RAM, a nie dysku w systemie Solaris, możesz użyć opcji „-oflag = sync”, aby wymusić zapis na dysku