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
Odpowiedzi:
Nie znam VMWare, ale używam Xenserver i użyłem Hyper-V (R2).
Przy mojej obecnej konfiguracji Xenserver mam:
Skonfigurowałem przełączniki w konfiguracji wielościeżkowej i zoptymalizowałem dla iSCSI poprzez:
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.
źródło
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)
źródło
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.
źródło