Na moim lokalnym serwerze plików mam raid-6 na 7x dyskach HDD.
dd if=/dev/zero of=tempfile bs=1M count=2048 conv=fdatasync
Lokalny test prędkości daje mi prędkość zapisu 349 MB / s.
Zdalne zapisywanie do Samby z SSD (prędkość odczytu> 2 Gb / s) daje mi 259 MB / s zapisów. Ale zdalne zapisywanie na dysk iSCSI (na inicjatorze iSCSI Win10) daje mi tylko 151 Mb / s zapisów.
konfiguracja raid6 - rozmiar porcji 128 KB, rozmiar_paski_paski = 8191. Zapisywanie zamierzonej bitmapy jest na dysku SSD (Samsung 860 PRO, fragment bitmapy 4096K).
Tablica zamontowana z opcjami: rw,noatime,nobarrier,commit=999,stripe=128,data=writeback
konfiguracja open-iscsi: cel oparty jest na pliku 4Tb.
Czy są jakieś wskazówki, dlaczego iSCSI działa wolniej niż Samba podczas pisania? Wszelkie wskazówki, jak poprawić szybkość zapisu w iSCSI?
Zakładam, że ma to coś wspólnego z chęcią, by open-iscsi opróżniało zapisy na dysk po każdej operacji, co zwiększa wzmocnienie zapisu w raid6 z powodu nadmiernego przepisywania parzystości. Ale nie jestem pewien, jak to naprawić. Przyspieszenie jest ważniejsze niż bezpieczeństwo obecnie zapisywanych danych w przypadku awarii zasilania.
Na marginesie, starszy iietsi obiekt docelowy iSCSI miał możliwość włączenia trybu zapisu wstecznego (używania IOMode=wb), a stała prędkość zapisu była znacznie większa. Niestety wydaje się, że jest obecnie nieobsługiwany.
źródło
Odpowiedzi:
Przede wszystkim problem stanowi RAID-6 z powodu obliczenia podwójnej parzystości. Po drugie, możesz dwukrotnie połączyć obiekt docelowy iSCSI w MS iSCSI Initiator, włączyć RR lub Least Queue Depth (niestety Win10 nie obsługuje wielu ścieżek, więc zamiast tego możesz przetestować go z Windows Server).
W rzeczywistości dostęp na poziomie bloków musi być szybszy niż dostęp na poziomie plików. Jakiego narzędzia do testowania wydajności używasz ze strony Windows? Poleciłbym użycie diskspd lub FIO. Dodatkowo możesz użyć czegoś takiego jak Starwind jako znacznie szybszego celu iSCSI.
https://www.starwindsoftware.com/starwind-virtual-san#Hyper-V
źródło
iSCSI powinno być używane na poziomie bloku, opis instalacji brzmi, jakbyś używał systemu plików, umieszczając na nim plik, a następnie uruchamiając ten plik jako warstwę bloku iSCSI.
Jest to dalekie od ideału i zdecydowanie nie jest konfiguracją do porównywania prędkości. Spróbuj użyć lvm na szczycie raid6 do segmentacji przestrzeni i pozostania na warstwie blokowej dla iSCSI lub użyj raid6 bezpośrednio jako urządzenia iSCSI.
W obecnej konfiguracji dane są przesyłane przez sieć, uderzając w plik w systemie plików, który (najprawdopodobniej) nie jest zoptymalizowany pod kątem tego rodzaju obciążenia, a także współużytkowany z innymi procesami. Możliwe jest przeprowadzenie takiej konfiguracji za pomocą iSCSI, ale należy to uznać za niezoptymalizowane rozwiązanie awaryjne.
źródło
Należy pamiętać, że
ddjest to bardzo prosty punkt odniesienia i jest bardzo podatny na zakłócenia. Na przykładddpiszesz zera - jeśli coś ma szczególny przypadek dla danych pełnych zer (np. Ponieważ potrafi kompresować) zobaczysz fantastyczną wydajność, ale przełącz się na pisanie niezerowych „prawdziwych danych” i nagle ta wydajność może zniknąć. ..Aby odpowiedzieć na twoje pytanie (jak we wszystkich testach porównawczych), musisz naprawdę wyodrębnić elementy, aby zidentyfikować bit wprowadzający problem. Na przykład, czy pisanie bezpośrednio do systemu plików Windows (a nie przez iSCSI) jest również wyjątkowo szybkie? Jeśli zastosujesz tę samą konfigurację sprzętową i uruchomisz system Linux zamiast systemu Windows, czy jest on tak samo szybki, czy spowalnia? Co się stanie, jeśli przełączysz się na korzystanie z narzędzia testowego, takiego jak fio ?
Niestety istnieje zbyt wiele możliwości, aby móc odpowiedzieć na takie pytanie dobrze ...
źródło