NFS czy iSCSI?

iSCSI w praktyce

Załóżmy, że nasze zadanie polega na podłączeniu hosta VMware vSphere z macierzą - przykładowo Dell EqualLogic PS4100.

Macierz ma dwa kontrolery i w każdym z nich po dwa interfejsy GbE. Jej podłączenie sprowadzi się do podłączenia pierwszego interfejsu z pierwszego kontrolera i drugiego interfejsu drugiego kontrolera do pierwszego przełącznika i połączeniu pozostałych dwóch portów z drugim przełącznikiem.

Kontrolery macierzy pracują w trybie active/passive, rozdzielenie interfejsów zabezpieczy nas przed jednoczesnym odłączeniem obu portów aktywnego kontrolera w przypadku awarii przełącznika, co uruchomiłoby dla procedurę failover dla kontrolera.

W macierzy EqualLogic konfigurujemy adres grupy (portalu), prócz tego przypisujemy adres każdemu z (aktywnych) fizycznych interfejsów. Nasza pamięć masowa będzie zatem wykorzystywała trzy adresy - ale do inicjatora iSCSI będzie wpisywany tylko adres grupy.

Po skonfigurowaniu pamięci masowej zajmujemy się hostem vSphere. Na potrzeby ruchu iSCSI potrzebujemy dwóch (co najmniej) dedykowanych interfejsów. Karty sieciowe dodajemy do jednego vSwitcha. Następnie dodajemy do tego vSwitcha trzy interfejsy VMKernel IP - jeden do zadań specjalnych (o tym za chwilę), dwa kolejne do właściwej obsługi ruchu.

NFS czy iSCSI?

Połączenie iSCSI w trybie MPIO (vSphere)

Przed przypisaniem dwóch interfejsów VMKernela do inicjatora iSCSI musimy "popsuć" teaming, tak by każdy z interfejsów wirtualnych był przypisany do dokładnie jednego fizycznego interfejsu. Robimy to dlatego, że nie chcemy by vSphere zajmował się problemami z którymś z tych dwóch interfejsów fizycznych - zostawiamy to iSCSI. Do tego właśnie potrzebujemy tego dodatkowego wirtualnego interfejsu, na którym vSwitch zawsze będzie w stanie pingować (heartbeat VMK) pamięć masową.

Gdy vSwitch i interfejsy sieciowe VMKernela zostaną już skonfigurowane włączamy software'owy inicjator iSCSI, przypinając do niego dwa interfejsy (oczywiście te powiązane z fizycznymi) naszego vSwitcha. Teraz potrzebujemy tylko wpisać do inicjatora adres IP portalu naszej pamięci masowej.

Po zapisaniu przez nas ustawień, inicjator przeskanuje cel iSCSI i - koniec końców - każdy z interfejsów vSphere zestawi połączenie z każdym z interfejsów aktywnego kontrolera (czyli w sumie będziemy mieli cztery ścieżki). Domyślna konfiguracja MPIO na vSphere spowoduje korzystanie tylko z jednego z czterech połączeń do transmisji ruchu do macierzy i - jeśli nastąpi jego zerwanie - przełączenie się na następne. Warto to zmienić wykorzystując redundantne łącze także do rozkładania ruchu. Najprościej to zrobić, konfigurując każdy z celów iSCSI (w naszym przykładzie z Equallogic każdy ze stworzonych woluminów będzie miał własny cel), by ruch rozkładał się zgodnie ze schematem round-robin. W takim schemacie (określanym też mianem karuzeli) porcja danych będzie posyłana cyklicznie i po kolei przez każdą z czterech ścieżek. Nie jest to idealne rozwiązanie, bo może się okazać, że ruch będzie kierowany na ścieżkę, która w danej jest bardziej chwili obciążona niż inne. Producenci pamięci masowych (choć należy zaznaczyć, że nie wszyscy) implementują wydajniejsze rozwiązania (tzw. DSM czyli Device Specific Module). W przypadku omawianej w tym przykładzie macierzy Della jest to programowa wtyczka do vSphere, która pozwala oprogramowaniu lepiej rozkładać ruch niż ślepym round-robin. Rozszerzenie Multipath Extension Module dodaje tryb rozkładający ruch na podstawie długości kolejek dla każdej ze ścieżek, co zapewnia ich równe obłożenie.


TOP 200