Dostrajanie pamięci iSCSI


29

To jest kanoniczne pytanie dotyczące iSCSI, którego możemy użyć jako odniesienia.

iSCSI to protokół, który umieszcza polecenia SCSI jako ładunek w pakietach sieciowych TCP. Jako taki podlega innym zestawom problemów, powiedzmy, Fibre Channel. Na przykład, jeśli łącze zostanie przepełnione, a bufory przełącznika są zapełnione, Ethernet domyślnie usunie ramki zamiast nakazać hostowi spowolnienie. Prowadzi to do retransmisji, co prowadzi do dużego opóźnienia dla bardzo małej części ruchu pamięci.

Istnieją rozwiązania tego problemu, w zależności od systemu operacyjnego klienta, w tym modyfikowanie ustawień sieciowych. Jak wyglądałaby optymalna konfiguracja klienta iSCSI dla poniższej listy systemów operacyjnych? Czy wymagałoby to zmiany ustawień przełączników? Co z pamięcią?

  • VMWare 4 i 5
  • Windows Hyper-V 2008 i 2008r2
  • Windows 2003 i 2008 na goły metal
  • Linux na goły metal
  • AIX VIO
  • Każdy inny system operacyjny, który uważasz za odpowiedni, byłby odpowiedni

iSCSI jest o wiele bardziej skomplikowane - ale w odniesieniu do stosu IP wszystkie mają zastosowanie do połączeń IP o wysokiej przepustowości i niskim opóźnieniu - nie ma tu nic specjalnego.
Nils

Odpowiedzi:


6

Nie znam VMWare, ale używam Xenserver i użyłem Hyper-V (R2).

Przy mojej obecnej konfiguracji Xenserver mam:

  • 8 serwerów Dell Poweredge 29xx
  • 2 przełączniki Dell Powerconnect 6248
  • 2 Dell MD3000i SAN (iSCSI)

Skonfigurowałem przełączniki w konfiguracji wielościeżkowej i zoptymalizowałem dla iSCSI poprzez:

  • Rozdzielanie moich przełączników na 3 sieci VLANS (2 dla ruchu iSCSI i 1 dla zarządzania)
  • Korzystanie z JumboFrames
  • Stosowanie optymalizacji „iSCSI”, które ma złącze zasilania

Każdy serwer ma wiele kart sieciowych, które zapewniają połączenie z każdym przełącznikiem, zapewniając z kolei redundancję poprzez wielościeżkę między serwerami a siecią SAN iSCSI. Sieci VLAN iSCSI nie zawierają innego ruchu niż iSCSI.

Z przyjemnością informuję, że przy tej konfiguracji „klaster” Xenserver działa doskonale.

Na marginesie mam serwer Windows 2008 podłączony bezpośrednio przez iSCSI do HP SAN (stary serwer plików). Kiedyś działał w systemie Windows 2003 i regularnie przerywał połączenie (nawet po ponownej instalacji 2003); Jednak jak tylko zaktualizowałem system do Windows 2008, pozostaje on podłączony.

Z przyjemnością odpowiem na każde pytanie dotyczące mojej konfiguracji.


1
Czy używasz kabli do układania między dwoma przełącznikami Dell?
SpacemanSpiff

Dlaczego iSCSI? Dlaczego nie DRBD na bezpośrednio podłączonym MD3000?
Nils

@SpacemanSpiff Moje przełączniki nie są ułożone w stos.
Steve

@Nils Nie badałem DRBD, chociaż o tym słyszałem. Co oferuje DRBD przez iSCSI dla mojej bezpośrednio podłączonej pamięci?
Steve

DRBD nie ma narzutu SCSI. Inną rzeczą jest to, że nie można pozbyć się procesu klienta iSCSI, gdy serwer iSCSI umiera lub jest nieosiągalny (ten ostatni nie powinien stanowić problemu w konfiguracji).
Nils

3

To nie jest odpowiedź ... jeszcze. To jest ramy dla ogólnej odpowiedzi. Jeśli masz czas, wypełnij wszystko, o czym wiesz. Jeśli chodzi o konfigurację konkretnego sprzętu, proszę opublikować osobną odpowiedź dla każdego dostawcy, abyśmy mogli utrzymać te informacje uporządkowane i osobne.

Profil QoS dla portów, a także wyłączenie kontroli burzy, ustawienie MTU na 9000, włączenie kontroli przepływu i przełączenie portów w portfast

Przepustowość i opóźnienie

Zaktualizowano oprogramowanie układowe, sterowniki i inne systemy

MPIO

Jumbo Frames / MTU

Wraz ze wzrostem prędkości łączy sieciowych wzrasta także liczba potencjalnie generowanych pakietów. Daje to coraz więcej czasu procesora / przerwania spędzonego na generowaniu pakietów, co skutkuje zarówno nadmiernym obciążeniem systemu przesyłowego, jak i zajęciem nadmiernej przepustowości łącza przy ramkowaniu.

Tak zwane ramki „jumbo” to ramki Ethernet, które przekraczają kanoniczny limit 1518 bajtów. Chociaż liczby mogą się różnić w zależności od dostawców przełączników, systemów operacyjnych i kart sieciowych, najbardziej typowymi dużymi rozmiarami pakietów są 9000 i 9216 bajtów (te ostatnie są najczęściej). Biorąc pod uwagę, że około 6X danych można umieścić w ramce 9K, liczba rzeczywistych pakietów (i przerwań) jest zmniejszona o podobną ilość na hoście. Zyski te są szczególnie wyraźne w przypadku łączy o większej prędkości (tj. 10GE), które wysyłają duże ilości danych (tj. ISCSI).

Włączenie ramek jumbo wymaga skonfigurowania zarówno hosta, jak i przełącznika Ethernet, dlatego przed wdrożeniem należy zachować szczególną ostrożność. Należy przestrzegać kilku wytycznych

1.) W ramach danego segmentu Ethernet (VLAN) wszystkie hosty i routery powinny mieć skonfigurowane takie same MTU. Urządzenie bez odpowiedniej konfiguracji zobaczy większe ramki jako błędy łącza (w szczególności „gigantów”) i upuści je.

2.) W ramach protokołu IP dwa hosty o różnych rozmiarach ramek potrzebują mechanizmu do wynegocjowania odpowiedniego wspólnego rozmiaru ramki. W przypadku protokołu TCP jest to wykrywanie ścieżki MTU (PMTU) i polega na transmisji nieosiągalnych pakietów ICMP. Upewnij się, że PMTU jest włączony we wszystkich systemach i że wszelkie reguły ACL lub zapory zezwalają na te pakiety.

Kontrola przepływu Ethernet (802.3x)

Pomimo tego, że jest zalecany przez niektórych dostawców iSCSI, proste sterowanie przepływem Ethernet 802.3x nie powinno być włączone w większości środowisk, chyba że wszystkie porty przełączników, karty sieciowe i łącza są całkowicie poświęcone ruchowi iSCSI i nic więcej. Jeśli na łączach występuje jakikolwiek inny ruch (taki jak udostępnianie plików SMB lub NFS, bicie serca dla pamięci klastrowej lub VMware, kontrola grupowa / monitorowanie ruchu NIC itp.), Nie należy stosować prostej kontroli przepływu 802.3x, ponieważ blokuje ona całe porty i inny ruch inny niż iSCSI również zostanie zablokowany. Wzrost wydajności Ethernet Flow Control jest często minimalny lub nie ma go wcale, należy przeprowadzić realistyczne testy porównawcze dla całej kombinacji OS / NIC / przełącznika / pamięci w celu ustalenia, czy istnieją jakieś rzeczywiste korzyści.

Rzeczywiste pytanie z perspektywy serwerów brzmi: czy zatrzymam ruch sieciowy, jeśli moja karta sieciowa lub sieć zostaną przepełnione, czy też zacznę upuszczać i retransmitować pakiety? Włączenie kontroli przepływu pozwoli na opróżnienie buforów karty sieciowej po stronie odbiornika, ale spowoduje obciążenie buforów po stronie nadawcy (zwykle urządzenie sieciowe buforuje tutaj).

Kontrola przeciążenia TCP (RFC 5681)

TOE (silniki odciążające TCP / IP)

iSOE (iSCSI Offload Engines)

LSO (segmentacja TCP / duże odciążenie wysyłania)

Izolacja sieci

Powszechną najlepszą praktyką dla iSCSI jest izolowanie zarówno inicjatorów, jak i obiektów docelowych od innego ruchu sieciowego innego niż pamięć masowa. Daje to korzyści pod względem bezpieczeństwa, łatwości zarządzania i, w wielu przypadkach, poświęcenia zasobów na ruch pamięci masowej. Ta izolacja może przybierać różne formy:

1.) Izolacja fizyczna - wszyscy inicjatorzy mają jedną lub więcej kart sieciowych dedykowanych wyłącznie do ruchu iSCSI. Może to oznaczać, ale nie musi, dedykowany sprzęt sieciowy w zależności od możliwości danego sprzętu oraz szczególnych wymagań bezpieczeństwa i operacyjnych w danej organizacji.

2.) Izolacja logiczna - najczęściej inicjowane w szybszych sieciach (tj. 10GE), inicjatorzy mają skonfigurowane tagowanie VLAN (patrz 802.1q), aby oddzielać ruch pamięciowy i nie-pamięciowy.

W wielu organizacjach stosowane są dodatkowe mechanizmy, aby zapewnić, że inicjatorzy iSCSI nie są w stanie dotrzeć do siebie przez te dedykowane sieci, a ponadto, że te dedykowane sieci nie są osiągalne ze standardowych sieci danych. Środki zastosowane w tym celu obejmują standardowe listy kontroli dostępu, prywatne sieci VLAN i zapory ogniowe.

Tutaj również coś o płycie montażowej i przełączaniu tkanin.

QoS (802.1p)

VLAN (802.1q)

STP (RSTP, MSTP itp.)

Tłumienie ruchu (sterowanie burzą, sterowanie wieloma / szerokimi castami)

Bezpieczeństwo

Uwierzytelnianie i bezpieczeństwo

FACET

IPSec

Mapowanie LUN (najlepsze praktyki)


Czy są jakieś tunery dla RFC 5681 na dowolnym urządzeniu? Jeśli nie, powinniśmy usunąć tę sekcję.
Nils

Czy warto dodać, że ramki Jumbo rzadko są obsługiwane dla replikacji iSCSI (ponieważ wszystkie pośrednie urządzenia WAN musiałyby je obsługiwać)?
Jeremy

@Jeremy pewny - napisz to powyżej. Nawet w sieci LAN - jeśli zapomnisz jedno urządzenie po drodze (lub jeśli twój zespół sieci outsourcing coś źle skonfiguruje), MTU ścieżki nie będzie obsługiwał ramek jumbo.
Nils

Zgadzam się z Jeremy. Zero, jeśli dostępny jest protokół TCP-CC, który ma potencjalne korzyści i konsekwencje, należy je przynajmniej przedstawić.
Chris S,

1

Niektóre rozważania i badania należy podjąć subiektywnie w odniesieniu do:

1) Wiele ścieżek - Twoje rozwiązanie SAN i system operacyjny, czy to hypervisor, czy system operacyjny typu „bare metal”, może wymagać specjalnego oprogramowania określonego dostawcy, aby działał poprawnie.

2) Inicjatory - należy sprawdzić, czy inicjator oprogramowania ma wystarczającą wydajność w oparciu o wymagania. Wiele kart sieciowych ma funkcje odciążania iSCSI, które mogą znacznie poprawić przepustowość, ale wiadomo, że niektóre starsze hiperwizory są dość wkurzone, jeśli chodzi o ich obsługę. Bardziej dojrzałe oferty (ESXi 4.1+) wydają się być fajne.

3) Bezpieczeństwo / uprawnienia - pamiętaj, aby w pełni sprawdzić, którzy inicjatorzy wymagają dostępu do których jednostek LUN ... znajdziesz się w złym dniu, jeśli administrator na jednym z komputerów z systemem Windows wykona „inicjalizację dysku” na dysku, który jest naprawdę używany przez inny serwer jako magazyn danych VMware.


W odniesieniu do wielu ścieżek - w rzeczywistości można to również osiągnąć za pośrednictwem różnych sieci - co jest nieco trudniejsze w przypadku IP niż w przypadku FC-SAN (gdzie koncepcja SAN A / B z różnymi strukturami sprzętowymi jest dość powszechna).
Nils

Moje doświadczenie z wieloma ścieżkami było przede wszystkim równe, w którym to przypadku klient zwykle otrzymuje adres IP wykrywania (adres IP grupy), a następnie negocjuje z tym adresem dla rzeczywistych adresów docelowych. Przypuszczam, że można to zrobić w różnych sieciach, a klient albo będzie miał do tego ścieżkę, albo nie, ale wykrycie spadłoby, gdyby ta podsieć, na której znajdowała się IP grupy, była tą, która umarła.
SpacemanSpiff

Próbowałem (natywnej) wielu ścieżek na SLES11 na różnych sieciach VLAN. Trudną częścią była modyfikacja konfiguracji wielościeżkowej, więc cele iSCSI, które trafiły do ​​tej samej pamięci fizycznej, były postrzegane jako to samo urządzenie.
Nils
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.