Niska wydajność zarówno iSCSI, jak i AoE

9

Poszukujemy rezonansowego magazynu prędkości. Ze względu na niski budżet postanowiliśmy wykorzystać oprogramowanie iSCSI lub AoE. Zanim zmienimy naszą infrastrukturę produkcyjną, przeprowadzamy testy, aby wybrać najlepszą technologię.

Do testowania używamy:

  • Fujitsu Siemens RX200 S4 jako cel
  • Fujitsu Siemens RX200 S4 jako inicjator
  • Przełącznik 1Git zarządzany przez NetGear
  • wbudowane karty sieciowe (Broadcom w / TOE), EdiMax NIC, Broadcom NIC w / TOE - wszystkie 1 GB
  • serwer docelowy używa kontrolera QLogic z 6 dyskami WD Blue SATA 2 TB.
  • Zarówno docelowy, jak i inicjujący system operacyjny to Ubuntu 16.04 LTS ze wszystkimi aktualizacjami. Przełącznik jest przeznaczony do przechowywania. Testujemy obligacje i wielościeżkowe.

Naszym problemem jest niska prędkość odczytu. Do testów używamy ddi plik 40-100 GB.

  • lokalny odczyt i zapis na serwerze docelowym wynosi ponad 300 MB / s.
  • pisanie na serwer przez iSCSI lub AoE to ponad 200 MB / s, co nas satysfakcjonuje.
  • odczyt z serwera zawsze wynosi 95-99 MB / s.

Próbowaliśmy ietd, aoetools, LIO. Wykorzystaliśmy obligacje 2 kart sieciowych: balance-rr i LACP, wielościeżkowe z rr. Używane ramki normalne i duże. Wreszcie zrobiliśmy nawet bezpośrednie połączenie Ethernet pomiędzy celem a hostem (bez przełącznika).

Wszystkie testy dają więcej mniej takich samych wyników (oczywiście przy użyciu zwykłych kart sieciowych bez TOE i iSCSI dały wyniki o 20-30% gorsze).

Testowanie sieci za pomocą iperf wykazało transfer około 200 MB / s (2 GBit). Obserwowanie użycia kart sieciowych na celu za pomocą bmon wykazało równe wykorzystanie obu urządzeń (każde około 50 MB / s do odczytu, około 100 MB / s do zapisu).

Ponieważ nie mieliśmy szczęścia, postanowiliśmy użyć trzeciej karty sieciowej (oczywiście po obu stronach). Wyniki były dziwne:

  • 2 karty sieciowe - każda 50 MB / s
  • 3 karty sieciowe - 33 MB / s każda

Czy jest jakieś ograniczenie w oprogramowaniu docelowym, które wyłącza moc wyjściową większą niż 1 GBit / s?

Co robimy źle?

Sebastian Biniecki
źródło
5
10GbE jest obecnie wystarczająco tanie. Jeśli potrzebujesz większej przepustowości (której możesz nie mieć), jest to zalecana ścieżka.
ewwhite
1
10 GbE nie pomoże w ATAoE, jest to bardzo nieskuteczny protokół ramki Ethernet. Specjalnie dla ram Jumbo!
BaronSamedi1958,
1
Miałem na myśli iSCSI. ATAoE jest martwy i nie powinien być do tego wykorzystywany.
ewwhite

Odpowiedzi:

11

Aby wycisnąć maksymalną wydajność z pamięci podłączonej iSCSI, należy użyć ramek Jumbo i MPIO (nie LACP). Zaleca się RDMA / iSER, jeśli możesz to zrobić.

AOE (ATA przez Ethernet) jest stary i gówno. Już dawno pozbyliśmy się Coraida. Używamy StarWind https://www.starwindsoftware.com/ już jako cel iSCSI już od dłuższego czasu, a StarWind poprosił nas o migrację poza Coraid do dowolnego miejsca, które moglibyśmy zrobić.

W tej chwili jesteśmy bardzo dobrzy dzięki iSCSI dostarczanym przez StarWind i używającym Windows, ESX i SCST http://scst.sourceforge.net/ w Linuksie jako inicjatorów. Dzięki RDMA / iSER robi to do 10 Gbit, jak dotąd bardzo szczęśliwy.

Net Runner
źródło
6

Twoje oczekiwania dotyczące działania agregacji łączy Ethernet są nieprawidłowe.

Wszystkie metody agregacji inne niż balance-rr (tj .: wszystkie metody, których tryb> 0) nie zapewniają większej przepustowości pojedynczego połączenia; raczej zwiększają całkowitą dostępną przepustowość, gdy nawiązywanych jest wiele połączeń z / do hostów, których dotyczy problem. Innymi słowy, LAG / LACP nie przyniesie żadnych korzyści w tym scenariuszu jednego połączenia.

Jedyną metodą agregacji, która może zapewnić przepustowość pojedynczej sesji większą niż to, co zwykle można uzyskać na jednym interfejsie, jest balance-rr , który dystrybuuje pakiety w sposób okrągły. Trzeba było ustawić balans-RR na zarówno inicjatora i celu. Jednak dużym problemem jest to, że jest to w dużej mierze zależne od zmiany.

W każdym razie, jeśli ustawisz zarówno target, jak i inicjator na balance-rr, bezpośrednie połączenie dwóch maszyn powinno dać ci większą wydajność. Jeśli nie, czy możesz napisać iperfz balance-rr i obie maszyny bezpośrednio podłączone (bez przełącznika)? Proszę również opublikować dokładne ddpolecenie użyte do przeprowadzenia testu porównawczego.

Shodanshok
źródło
2

Uwaga: mówię tu tylko o iSCSI. Nie mam doświadczenia z AoE poza czytaniem o tym i nie zaimplementowałbym go w żadnej nowej infrastrukturze (jest prawie nieczynny).

Nie używaj balance-rr do niczego innego niż niektóre bardzo szczegółowe protokoły punkt-punkt. Ma okropną wydajność, gdy znajduje się pod praktycznie dowolnym obciążeniem w świecie rzeczywistym, i powoduje masę problemów z siecią (takich jak Jitter). Zdecydowanie nie używaj go z przełącznikiem.

Użyj MPIO bez żadnego wiązania po stronie inicjatora, aby osiągnąć równoważenie obciążenia i tolerancję na uszkodzenia. Aby upewnić się, że Twoje ścieżki nie zostaną „pomieszane”, wysyłając cały ruch w dół po jednej ścieżce, umieść indywidualne ścieżki (w twoim przypadku gigabitowe karty sieciowe między celem a inicjatorem) w osobnych podsieciach.

Nie krępuj się wiązać strony docelowej za pomocą LACP na ścieżkę (jak w przypadku dwóch wiązań dla dwóch ścieżek w sumie czterech kart sieciowych, jako przykładowa konfiguracja portu docelowego). Działa to świetnie i może zrównoważyć wiele połączeń inicjatora korzystających z tych samych ścieżek. Jeśli to możliwe, używaj także ramek jumbo i iSER. Użycie LACP na celu zrównoważy połączenia z każdą ścieżką między kilkoma kartami sieciowymi.

Używanie LACP na inicjatorze będzie skuteczne tylko wtedy, gdy będzie nawiązywało wiele docelowych połączeń z portalem przy jednoczesnym użyciu (nie jest to powszechne przy prawie żadnym obciążeniu). Nawet jeśli efektywnie zaimplementujesz LACP na ścieżkę na inicjatorze, szybko stanie się koszmarem okablowania, w którym można na przykład użyć czterech dodatkowych tkanin do każdego pudełka. Jeśli potrzebujesz więcej niż ~ 2 Gib / s do pojedynczego inicjatora, rozważ Ethernet 10 GiB / s.

Bufor
źródło
1

Większość odpowiedzi na temat obszaru zagrożenia jest całkowicie niepoprawna, alternatywna i pokazuje brak wiedzy na temat obszaru zagrożenia. Po pierwsze, nie jest zepsute. CORAID jest dostawcą AoE, który wznowił działalność jako „SouthSuite”, zachowując znak towarowy CORAID. Są to również ci sami programiści. Tworzą nowe produkty i wspierają większość starych. Pchają również rozwój AoE, jak wyraźnie pokazują ich otwarte techniczne listy mailingowe. Sprawdź stronę internetową, wszystko jest aktualne i opowiada całą historię na ich stronie historii.

Ktoś powiedział, że obszar nie skorzysta z ramek typu jumbo, a także całkowicie się mylił. Był obsługiwany po wydaniu wersji 13 programu „vbladed”. Musisz dostroić MTU, aby obsługiwał nowy rozmiar ramki, ale poza tym działa świetnie.

iSCSI działa w warstwie 5 modelu OSI. Zwykle transportem jest TCP. Daje to pewną korektę błędów (z powodu sum kontrolnych w TCP) i pozwala na kierowanie ruchu przez IP w warstwie 3. Na tym kończą się zalety iSCSI. Jego rzeczywiste wyniki są wręcz okropne, gdy porównuje się je do FCP, AoE lub FCoE. Zapraszam do Google „Porównanie wydajności iscsi” do horroru.

Problem z szybkością odczytu mógł być spowodowany błędną konfiguracją sieci, wyłącz kontrolę przepływu i upewnij się, że używasz wystarczająco dużego bufora gniazda. Nie wspomniałeś również, czy Twój bazowy system plików został dostrojony do pobierania wstępnego do odczytu, czy nie. W zależności od Twojego scenariusza może to ci bardzo pomóc, ale uważaj, aby nie używać go z niektórymi bazami danych, które wymagają buforowania.

Agregacja 802.3ad nie zwiększy znacząco przepustowości pojedynczego strumienia, nawet w scenariuszu round-robin. Skomplikuje to również konfigurację sieci i da ci kilka nowych możliwości zastrzelenia się w stopę poprzez niedopasowanie przedziałów PDU lub błędną konfigurację łącza Cisco VPC w celu obsługi stanu aktywny-aktywny. Nie używaj LACP z AoE, pozwól mu obsługiwać własne wielościeżki i multipleksowanie. Późniejsze wersje AoE radzą sobie z tym pięknie, a w większości przypadków bardziej wdzięcznie niż nawet FCP, ponieważ wszystko jest automatyczne. Dodatkowe porty Ethernet zapewniają większą przepustowość i większą odporność. Rozłożenie portów Ethernet hosta i inicjatora na wiele przełączników może zapewnić jeszcze większą redundancję. Nie ma potrzeby konfigurowania trybu łączenia. Ponadto nie uruchamiaj adresu IP na tych samych interfejsach, z których korzystasz w obszarze AoE.

Krótko mówiąc, nie słuchaj naiwniaków obszarowych, brzmią, że nie mają dużego doświadczenia i po prostu jeżdżą w modnych falach mózgowych. Unikaj stada. Skonfiguruj sklep kopii zapasowych z ręcznie dostosowanym pobieraniem wstępnym, a prawdopodobnie zobaczysz, że przepustowość odczytu rośnie. Porzuć korzystanie z protokołów agregacyjnych i uruchom krzyk z iSCSI. I ostatnia rzecz, przestań używać 'dd', to nie jest świetny test i podlega złym efektom buforowania. Użyj prawdziwego narzędzia porównawczego, takiego jak „fio”, „iozone” lub „dbench”. Dają one znacznie bardziej wiarygodne wyniki.

Swift Griggs
źródło
1

Wiem, że LACP obsługuje wiele połączeń. Testowanie było aktem desperacji :)

Wszystkie testy przeprowadzono przy użyciu balance-rr i dwóch kart sieciowych.

Zapis do celu iSCSI:
dd if = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bajtów (2,1 GB, 2,0 GiB) skopiowane , 10,1093 s, 207 MB / s

Odczyt z celu iSCSI:
dd if = / mnt / zero.bin of = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB , 2,0 GiB) skopiowane, 16,1684 s, 130 MB / s

Prędkość sieci:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Klient łączy się z 172.16.10.80, port
TCP 5001 Rozmiar okna TCP: 325 KB (domyślnie)
--------------------------------------------- ---------------
[3] lokalny port 172.16.10.70 port 37024 połączony z portem 172.16.10.80 port 5001
[ID] Pasmo transferu interwałów
[3] 0,0-10,0 sek 2,30 GBytes 1,98 Gb / s

Testowanie z ramkami iperf i jumbo dało takie same wyniki.

Zyskałem trochę prędkości czytania, uruchamiając na inicjatorze:
hdparm -a 2048 / dev / dm-1
Wcześniej było to 256, a prędkość odczytu wynosiła 96
MB / s. Moim celem jest osiągnięcie prędkości odczytu około 200 MB / s.

EDYCJA:
1. Nie używamy LACP - był to jednorazowy test.
2. Testy z balance-rr i MPIO dają dokładnie takie same wyniki. Testowanie wielu ścieżek za pomocą kart sieciowych w różnych podsieciach.
3. Dodanie większej liczby kart sieciowych nie zwiększa prędkości odczytu, a jedynie zmniejsza wykorzystanie każdej karty sieciowej.
4. Uważamy, że problemem są pewne ograniczenia (sterownik, moduł?), Które nie pozwalają na szybsze czytanie. Ale nie jestem pewien, czy jest to strona docelowa czy inicjacyjna.


EDYCJA 2: Właśnie wykonałem dodatkowy test: skonfigurowałem ten sam host jako cel i inicjator, aby pozbyć się problemów ze sprzętem sieciowym. Byłem w szoku: dokładnie taka sama prędkość czytania! 130 MB / s! Zapisywanie wynosi 227 MB / s.

Sebastian Biniecki
źródło
Aby korzystać z protokołu LACP podczas korzystania z iSCSI, musisz mieć włączonych wiele połączeń na sesję. Brak mc / s = brak wzrostu wydajności. scst.sourceforge.net/mc_s.html i starwindsoftware.com/blog/… mogą pomóc.
BaronSamedi1958,
-2

jak masz skonfigurowane nici, czy wszystkie bufory są poprawnie skonfigurowane, czy masz przydzieloną wystarczającą ilość pamięci RAM do buforów sieciowych. także nie używaj wiązania tutaj możesz użyć 2 kanałów iscsi i multipatować je na inicjatorze, tak samo jak ATAoE multipath na inicjatorze poprzez półkę i identyfikator lun na dowolnej ścieżce.

Damien Dye
źródło
czy są jakieś kontrole i / lub zmiany w konfiguracji, które możesz zasugerować? Nawet jeśli nie masz pełnej odpowiedzi, pomaga ona w udzieleniu odpowiedzi i innym, jeśli możesz dać wskazówki, aby skierować
pytającego