sebak

@nrm dobór dysków w moim przypadki zależny jest w dużem mierze od tego jaki zapis przewiduję. Dysk SSD to konstrukcja w miarę prosta i mało awaryjna, jeśli nie zużyjesz komórek pamięci. Z dysków PC, używałem głównie Crucial M550, Samsung 960 PCIe, Intel 750 PCIe. Z dysków Enterprise, używałem Micron M500DC i Samsung SM863. Miałem kilka Samsungów 850 Pro i w moich zastosowaniach te dyski szybciej się zużywały niż Cruciale M550. A podobno to Samsungi były dyskami bardziej PRO ;-). W każdej konfiguracji dyski SSD działają u mnie jako JBOD. Mam złe doświadczenie z kontrolerami SAS i dyskami SSD jako HW. Część dysków działa na macierzach ZFS, część bezpośrednio w serwerach. Na ogól nie zdarzyło mi się, by którykolwiek z tych dysków padł mi na maszynie produkcyjnej. Zawsze monitoruję SMART i jeśli coś mnie nie pokoi, to wymieniam dysk. Zdarzyło mi się 2 razy, że dysk wyjęty po niepokojących parametrach SMART już mi nie wstał, jak próbowałem go za jakiś czas przetestować.

@Adam Szendzielorz moje platformy mają stosunek odczyt/zapis na poziomie 20/80 %.

@Adam Szendzielorz niestety, ten najtańszy dysk może i będzie robił 20k, ale tylko przez chwilkę, po zapełnieniu cache wydajność Ci spadnie zdecydowanie. Na przykład taki Crucial MX300, którego używam do backupu przy długotrwałym obciążeniu jego wydajność spada Ci do około 5k iops: https://www.anandtech.com/show/10274/the-crucial-mx300-750gb-ssd-review-microns-3d-nand-arrives/2 Oczywiście to nadal dużo, ale trzeba mieć na uwadze, że większość dysków SSD przy długotrwałym obciążeniu ma wydajność zdecydowanie mniejszą niż przy krótkich testach na nieobciążonym systemie.

@SiXwishlist ale jednak ten temat dotyczy SSD, a nie innych czynników ;-). Co nie zmienia faktu, że w większości dla klienta usługa ma działać dobrze, a mało kto interesuje na czym ona stoi.

Masz tutaj np. PDF: http://www.samsung.com/semiconductor/global/file/insight/2017/04/best-practices-for-mysql-with-ssds-0.pdf jest o tyle ciekawy, że masz porównanie SAS, SSD AHCI i SSD NVMe. Kilka stron: https://blog.2ndquadrant.com/tables-and-indexes-vs-hdd-and-ssd/ https://blog.serverdensity.com/mongodb-performance-ssds-vs-spindle-sas-drives/ https://itblog.sandisk.com/the-impact-of-ssds-on-business-analytics-apache-hadoop-terasort-benchmark-using-sandisk-ssds/ https://serverfault.com/questions/507521/are-ssd-drives-as-reliable-as-mechanical-drives-2013/507536#507536 https://www.quora.com/Does-using-SSD-improve-the-performance-of-server http://www.profesorweb.es/wp-content/uploads/2012/11/ssd_vs_hdd_price_and_performance_study.pdf

@smarthost poszukaj w necie testów wydajności, jest ich trochę. Jak chcesz, możesz dawać takie przykłady klientom. Z moich obserwacji wynika, że tylko mały odsetek klientów zwraca uwagę na czym stoi usługa. Jednak gdy usługa źle działa, to większość użytkowników to widzi ;-).

Roztargnienie. Poprawiłem już ;-).

@Adam Szendzielorz przedstawił Ci ciekawe wyniki porównania: Strony www, przeważnie w testach i tak w większości lecą z ramu, więc trudno to odnieść jakkolwiek do dysków. Zaufaj doświadczeniu innych, my stosujemy dyski SSD od conajmniej 6 lat i różnice na plus były na tyle istotne, że dzisiaj poza kopiami nie stosujemy nigdzie dysków talerzowych.

Wszystko zależy od tego jaką masz infrastrukturę. W innym temacie pisałem, że tam gdzie się da używam ZFS'a. W przypadku ZFS'a backup jest prosty, mało zajmuje i można praktycznie z maszyny kopii odtworzyć maszyny wirtualne, a kompresja daje zazwyczaj ratio na poziomie 1.3-1,5x. Więc takie kopie, mają dużo mniejsze zapotrzebowanie na dane i wydajność niż inne metody. Serwery kopii zazwyczaj nie wymagają zbyt dużych zasobów. Ja miałem swego czasu kilka serwerków typu HP Microserver Gen 8 i działało to dobrze ;-). Uprzedzę przyszłe wydarzenia. Webh niedługo wycofa się z oferty OpenVZ, zostając tylko przy KVM. Głównym powodem takiej decyzji, były problemy z efektownym backupowaniem dużych ilości danych. Gdzie dla KVM i ZFS'a nie stanowiło to najmniejszego problemu ;-).

@SiXwishlist nie mówiłem o backupie 2TB danych, tylko o koszcie dysku 2TB. Oczywiście backup wszystkich danych na SSD, jest obecnie zbyt drogi i sam go nie stosuję. Jednak jak pisałem wyżej, mam jedną instancję której kopię robię na SSD i jest to celowe, gdyż w tym przypadku czas podniesienia usług z kopii jest dla mnie kluczowy.

@Adam Szendzielorz dlatego też mam tylko jedną taką instancję ;-). Na backup w zupełności starczą dyski SSD pokroju Crucial MX300, które są po około 2k zł za 2 TB. Zwłaszcza jeśli kopia jest kopią przyrostową, generowaną poprzez przesyłanie różnicy między snapshotami. Generuje to minimalne ilości zapisu.

A ja mam jedną instancję na której trzymam backup na SSD. Jest to kopia, z której w razie awarii mogę podnieść usługę. Więc czasem i na backup idą SSD ;-).

@mcbarlo random read, random write czy random read/write? W tym ostatnim dyski talerzowe radzą sobie najgorzej, a niestety ma on najwięcej wspólnego z normalnym ruchem. Nie znam się na Cephie, więc nie wiem na ile on ma wpływ na wydajność.

@mcbarlo jeśli chodzi o transfery, faktycznie dyski talerzowe poszły do przodu. Więc jeśli potrzebujesz przepustowości, to będzie dobry wybór. Niestety gorzej wychodzi jeśli chodzi o iops'y i losowe operacje odczytu / zapisu.

@Sevos tu nie do końca chodzi tylko i wyłącznie o klientów ;-). Powiem Ci jak ja to widzę z punktu widzenia usługodawcy. Wolę wydać więcej funduszy na sprzęt, gdzie jest to wydatek jednorazowy i mieć święty spokój z wydajnością, niż zatrudniać ludzi do reagowania na problemy wynikające z chwilowych problemów z wydajnością. @SiXwishlist dyski talerzowe oczywiście są fajne i znajdziesz dla nich zawsze zastosowanie, jeśli wiesz mniej więcej jaki ruch mają przyjąć. SSD w większości zwalnia Cię z myślenia, co się stanie jeśli ruch okaże się większy niż planowałem ;-).

@mcbarlo nvme jest tak naprawdę protokołem komunikacyjnym, tak jak AHCI. Dyski takie mogą być w formacie PCIe, M.2, U.2(SFF- 8639). O ile PCIe, czy M.2 nie wymienisz w locie, to dyski U.2 są już w pełni do tego przystosowane. PS: Pamiętam jeszcze kilka lat temu, że prawie wszystkie dyski PCIe były w standardzie AHCI. Na Karcie miałeś 4 dyski, połączone RAID 0 ;-). Moim zdaniem, problem z nvme nie jest na poziomie RAID'u, ale ograniczenia obsługiwanych linii PCIe przez platformę. Taka platforma pod Xeon E3 obsługuje tylko PCIe 16x, natomiast każdy dysk PCIe zajmuje 4 linie. Łatwo tutaj policzyć, że przy RAID 10 z 4 dysków wykorzystujemy już pełną przepustowość PCIe. A do tego procesora musi być podłączona jeszcze grafika, sieć, usb itp. Trzeba więc dość dobrze zaplanować dobór odpowiedniej platformy pod wiele dysków PCIe ;-). Dysk SSD PCIe, nie różną się aż tak bardzo jak dyski SATA SSD. Jedne i drugie korzystają z podobnych kości pamięci i posiadają podobne konstrukcje, główną różnicą jest zastosowany kontroler. Wiec jeśli kupisz tani dysk PCIe, to będzie można go łatwo zajechać, podobnie jak w przypadku dysków SATA. Jeśli kupisz dysk PCIe enterprise, to jeśli nie będzie wady fabrycznej to taki dysk jest praktycznie nie do zajechania. Tutaj wszystko tak naprawdę zależy od obciążenia i przeznaczenia. Jeśli robisz 10TB zapisu rocznie, to bez sensu kupować dysk który wytrzyma 10 PB zapisu ;-). Dyski SSD PCIe stosuję od około 2-3 lat, zarówno w RAID jak i bez.

100% pozytywne ;-). Różnica między dyskami SAS, a SSD jest gigantyczna, ale wszystko zależy od obciążenia które generujesz. Przy małym obciążeniu i dyski SATA będą dobrze działać. Dyski SSD z perspektywy usługodawcy dają zdecydowanie mniejszą awaryjność, niż jakiekolwiek dyski talerzowe. Eliminują też problem z nagłym skokiem obciążenia. Z perspektywy klienta, dyski SSD zapewniają dużo lepszą wydajność, w tym tą związaną z czasami dostępu do danych.

@Adam Szendzielorz w tej chwili z tego storage korzysta około 400 serwerów VPS. Jako ciekawostkę dorzucę efektywność pamięci l2arc: Wykorzystujecie w swoich konfiguracjach cache l2arc? Edit: Dodam jeszcze jeden ciekawy wykres pokazujący co się dzieje z pamiecią ARC po jej zwolnieniu: Przed tuningiem l2arc, około 90% pamięci która była zwalniana z ARC, nie trafiała w ogóle do l2arc.

U mnie ten storage, to akurat KVM'y, jak widać ten rodzaj klientów ma trochę większe zapotrzebowanie na przepustowość ;-). Była to moja pierwsza duża macierz ZFS, stąd też wydajność była dla mnie jednym z priorytetów, bo nie wiedziałem wtedy czego mogę się spodziewać. Zarówno po klientach, jak i ZFS'ie, niemniej chciałbym mieć takie obciążenia jak u Ciebie ;-).

@Adam Szendzielorz moje doświadczenie mówi, że RAIDZ jest wydajniejszy niż RAID 10. Tutaj masz stronę z fajnymi testami: https://calomel.org/zfs_raid_speed_capacity.html Moja konfiguracja 5x RAIDZ 5 dysków (25 łącznie), przyjmuje obecnie następujące obciążenie: https://www.dropbox.com/s/x8i44awm950uf4v/Zrzut ekranu 2017-09-15 00.18.22.png?dl=0 Wykres przedstawia sumaryczne operacje na wszystkich dyskach, realne obciążenie(po odrzuceniu dysków z parzystością) to 4/5 tych wartości. A jakie obciążenia średnio generują Wasze macierze?

Tam gdzie muszę Centos, tam gdzie mogę Freebsd ;-).

macOS Sierra i ogólnie OS X od 6-7 lat.

Moje doświadczenie jest głównie z ZFS na Freebsd, na Linux mam tylko 1 maszynę produkcyjną. Robiąc kiedyś porównanie wydajności i zachowania się ZFS'a na obu systemach, doszedłem do wniosku, że ZFS on Linux to zbyt duże ryzyko dla mnie. Testowałem też ZFS'a na Solarisie, jednak tam z kolei system wydawał się zbyt niszowy. Poza backupem, 100% danych trzymam na SSD. Nie wiem jak teraz, ale kiedyś ZFS on Linux nie dorobił się wsparcia dla trim'a, oferował gorszą wydajność na Linux, oraz większe zapotrzebowanie na ram. Dodatkowo nie ZFS na Linux nie wspierał partycji systemowej na ZFS, a to jest bardzo przydatne przy tworzeniu macierzy dyskowej. Moja najwieksza macierz na ZFS składa się z 25 dysków SSD, 2 dysków SSD pod system i 2 dyski PCIe. Jeśli chodzi o deduplikację, wcale nie jest aż tak obciążająca jak mówisz @Adam Szendzielorz. Oczywiście wymaga to odpowiednio dużego recordsize, oraz kilku innych optymalizacji (jak np. dysk pod l2arc dedykowany na metadane). Przy odpowiednio szybkim dysku SSD l2arc nawet nie potrzebujesz dużo ramu do deduplikacji. Oczywiscie l2arc sam w sobie wymaga też tuningu... W Freebsd standardowo l2arc zapis do pamięci ssd jest ograniczony do 5 MB/s, oraz domyślnie dysk może na raz tylko odczytywać lub zapisywać dane. Przy NVMe te limity są śmieszne ;-). Podsumowując, ZFS ma masę zalet, ale trzeba mieć o tym pojęcie. Inaczej dużo łatwiej zrobić sobie krzywdę, niż na innym systemie plików.

df to najmniejszy problem w przypadku zfs'a ;-)

Nie polecam ZFS'a jeśli nie chcesz poświęcić dość dużej ilości czasu na jego poznanie i zrozumienie. Jest to system plików, który niestety ma lekko inną implementacje w zależności od systemu operacyjnego na którym działa(Linux, Unix, Solaris). ZFS ma bardzo wiele opcji konfiguracyjnych, które dają ogromne możliwości doświadczonym użytkownikom. Jednak przy złych ustawieniach, wydajność można zdegradować kilkusetkrotnie, czego nie doświadczymy praktycznie na żadnym innym systemie plików. Natomiast ustawienia nie są uniwersalne, w dużej mierze zależą od tego jakie dane trzymamy i jakimi dyskami dysponujemy. Osobiście uwielbiam ZFS'a, stosuję go już produkcyjnie od kilku lat i odpowiednio skonfigurowany działa perfekcyjnie. Jednak zanim to nastąpiło, było wiele momentów gdy nienawidziłem tego systemu plików ;-).