sebak

@nrm z racji na to, iż nigdy nie stosowałem towerowych rozwiązań nie jest w stanie Ci powiedzieć jak jest w rzeczywistości. Jednak te towery były sprzedawane jako stacje robocze(poza propozycją intela), wiec z natury miały pracować w biurze.

@nrm dla E5 masz dwa rozwiązania, albo poszukać płyt głównych: http://allegro.pl/nowa-plyta-fujitsu-celsius-m720-s2011-d3128-fv-i6948575309.html http://allegro.pl/plyta-glowna-supermicro-mbd-x9sra-i6986489875.html Albo kupić gotową konstrukcję tower, w której kusisz pogodzić się z tym, że nie masz miejsca dla 8 dysków lub przebudujesz ją tak by mieć to miejsce: http://allegro.pl/dell-precision-t3600-xeon-e5-8gb-500gb-nvs300-w7-i6996117463.html http://allegro.pl/hp-z420-xeon-e5-1603-2-8ghz-8gb-320gb-nvs315-pbt-i6865768298.html http://allegro.pl/serwer-intel-2x-xeon-e5v2-16x-ram-raid-8xhdd-4xlan-i6990481481.html @mcbarlo w ocenie opłacalności zazwyczaj chodzi o cenę. Nie dostaniesz DDR3 ECC w dobrej cenie, natomiast DDR3 ECC-R już tak. Przecież @nrm powiedział że nie interesują go rozwiązania rackowe. A przykład przez Ciebie przytoczony dotyczy tylko i wyłącznie rozwiązania rack. Płyty do rozwiązań typu desktop zawsze posiadają większą ilość slotów PCIe. Przy e3 nastąpi degradacja wydajności, jeśli wykorzystasz więcej niż 16 lane pcie, natomiast dla e5 masz dużo większe możliwości.

@mcbarlo Xeony E3 obsługują pamięci ECC, Xeony E5 obsługują pamięci ECC i ECC-R. Pamięci ECC dla DDR3 bardzo ciężko obecnie dostać i mają duże ceny, pamięci ECC-R są bardzo popularne i masowo dostępne, stąd też ich ceny są dużo niższe. 64GB dla DDR3 ECC-R to koszt około 600 zł brutto, koszt 64 GB ramu dla DDR4 to około 2000 zł brutto. Gdzie dla E3 będzie to maks, a dla E5 możesz zawsze w ramach potrzeby ram dołożyć. ZFS lubi dużo ramu ;-). Xeon E5 v2 zapewnia moim zdaniem najlepszy kompromis między wydajnością, a poborem prądu i ceną. Konstrukcje na E3 mają tylko 16 line PCIe, E5 mają 40 line PCIe na procesor. Więc jeśli chodzi o sloty PCIe, zawsze konstrukcja na E3 będzie oferowała gorsze możliwości rozbudowy.

Dla mnie konstrukcja jest tylko jedna sensowna: Płyta główna mATX dla 1 lub 2 Xeon E5 v1/v2. Procesor mimo wszystko poszedłbym w stronę Xeon E5 v2, są równie tanie, a pobór prądu masz zauważalnie niższy(20-30%), plus wyższa wydajność(10-20%). Kontroler dyskowy coś na chipsecie LSI 2308 lub 2008. Obudowa tower, lub jakaś gotowa konstrukcja typu tower. Dlaczego nigdy bym nie poszedł w stronę e3? Ograniczeniem jest ilość ramu i koszty pamięci RAM. W cenie 1 kości 8GB dla e3, dostaniesz 4x8GB dla e5 ;-).

Uważam, że Twoje rozumowanie jest błędne w czasach wielordzeniowych procesorów o dużej ilości rdzeni, ogromnej ilości pamięci RAM i dyskach SSD. Mając do dyspozycji podstawową konfiguracji powiedzmy 2x 8C, 64 GB RAMu i SSD żadnej klient na klasyczny hosting współdzielonym nie powinien nawet zbliżyć się do 20-30% tych zasobów, inaczej nie nadaje się na tego typu usługę i potrzebuję rozwiązania bardziej dedykowanego lub skalowalnego. Usługodawca z kolei powinien niezależnie od stopnia oversellingu, gwarantować zawsze minimum 30% wolnych zasobów na danym nodzie(zalecane 50%) i w razie przekraczania tego parametru dynamicznie przenosić klientów. Nie chodzi mi o gwarantowane zasoby, ale o fakt, że przy taniej mocy obliczeniowej, usługodawcy powinni gwarantować wolne zasoby, na wypadek skoków obciążenia. Tak by z punktu widzenia klienta, nie miało znaczenia czy trafił na serwer zapełniony, czy nowy. Może to jest myślenie życzeniowe, ale ja to tak widzę.

@gb1 moim zdaniem, dobre usługi współdzielone powinny charakteryzować się zawsze odpowiednim zapasem mocy tak, by dla klienta nie było odczuwalne, czy maszyna jest już zapełniona w pełni, czy też nie. Powiedzmy sobie szczerze, obecnie moc obliczeniowa jest tak tania, że nie powinno stanowić to problemów. Wszystko zależy od polityki danej firmy i umiejętnego rozkładania obciążeń. Ale właśnie za to klienci płacą firmą hostingowym, za umiejętne rozkładanie obciążeń.

@gb1 dostawca powinien dbać o równomierne rozmieszczenie użytkowników i wykorzystanych zasobów, tak by wydajność była powtarzalna.

@Borian stary nie uwzględniał MacOS w ankiecie od początku, stąd też tworzył zafałszowany obraz rzeczywistości ;-).

Macbook 12"

@mcbarlo jeśli masz ratio kompresji 1.0x, to wyłącz kompresję, bo widać w Twoim przypadku jest ona zbędna ;-).

Zbyt duży cache, może mieć wpływ na wydajność, ale nie przy rozmiarze na poziomie 1 TB. Im więcej ramu tym lepiej, L2ARC dodatkowo obciąża Ci ram, gdyż trzyma tablicę danych w RAMie. Nie ma prostego przeliczenia RAM <-> pojemność, o ile nie używasz deduplikacji.

Kompresja prawie zawsze daje plus ;-). Zwłaszcza, że jeśli dane mają pomijalny stopień kompresji, nie są kompresowane na dysku. Jeśli odczyt do tych samych danych będzie zanim dane wypadną z kolejki ostatnio używanych, to warto stosować l2arc. Jeśli odczytujesz duży plik losowo, a następnie kolejny i kolejny, a dopiero później wracasz do pierwszego, to jest duża szansa, że cache dużo Ci nie da.

Powiedz mi @mcbarlo jaki to będzie odczyt, liniowy, random? Jaki zapis? Ogólnie cache ZFS'a działa bardzo prostu. Odczyt / Zapis danych trafia do ARC, który podzielony jest na dwa algorytmy: MRU i MFU. Jeden odpowiada za ostatnio używane dane, drugi za najczęściej używane dane. Wszystkie dane trafiają najpierw do cache przewidzianego dla ostatnio dodanych danych. Jeśli brakuje ramu, nowe dane, wypierają najstarsze dane. Jeśli do danych znajdujących w cache ostatnio dodanych odwołasz się chociaż raz, dane te zostaną przeniesione do drugiego algorytmy, z którego wypieranie danych działa analogicznie. Każde dodatkowe odwołanie do danych, przenosi istniejące tam dane na ostatnie miejsce do zwolnienia z cache. Załóżmy że masz 4GB ramu i masz zapis na poziomie 5GB, następnie odwołujesz się do 1 GB zapisanych danych. Nie znajdzie się on w cache. Stąd tak istotne jest dobór rozwiązań w zależności od charakterystyki danych. L2arc to przedłużenie ARC, dane które wypadają z ARC'a trafiają w idealnej sytuacji 1:1 do L2arc.

U mnie na hw, dyski dużo szybciej się zużywały niż w trybie jbod. Jeśli robisz małe obciążenie, to ma małe znaczenie czy stosujesz hw czy jbod, oraz jakich dysków używasz. Zfs on Linux trima nie wspiera, ale posiada różne zmienne konfiguracyjne których nie posiada freebsd. Freebsd z kolei posiada funkcje których nie posiada solaris i tak natywny ZFS posiada ich najmniej.

Wartości o których mówiłem poprzednio wyciągam właśnie z wartości smart, w zależności od dysków parametry 225, 241, 246. Przykład dla jednego z storage, w załączniku, oraz czysty smart dla dyski da0 z tego storage. Obecnie na żadnym serwerze nie posiadam już hw. Nigdy nie analizowałem tego, ze względu na fakt, że ZFS'a używam dla innej wirtualizacji niż ext4. Wszystkie OpenVZ mam na ext4, wszystkie KVM'y na ZFS'ie. KVM'y stoją też częściowo na innych dyskach niż OpenVZ(KVM wszedł do oferty 1,5 roku temu). Wcześniej pisałem, że wiele rzeczy może mieć wpływ na zużycie dysku. EXT4 na ZFS to nadal COW (copy on write), czyli zapis następuje na wolnej przestrzeni. Podczas gdy EXT4 modyfikuje dane na dysku. Pewnie to wpływa na różnice WL. Ewentualnie mam jeszcze jeden trop, ZFS na linuksie nie wspiera TRIM.

@Adam Szendzielorz to były stare czasy, około 3-4 lata temu. Wtedy działało to via hw RAID 10, ext4 (bez trim’a), kernel 2.6.32. Nie twierdze, że była to optymalna konfiguracja dla dysków SSD, ale przy analogicznych warunkach Crucial m550 nie stwarzał takich problemów. Wydajnościowe samsung wygrywał, jeśli chodzi o żywotność, Crucial. Ale jak pisałem wyżej, moje dyski SSD raczej dostają w kość jeśli chodzi o zapis.

Hej, jak podajecie endurance, to podajcie też powierzchnie na jaką się to rozkłada.

@Adam Szendzielorz pełna zgoda, dyski dobiera się pod planowane obciążenie i również uważam, że nie ma nic złego w stosowaniu optymalnego dysku do planowanego obciążenia. Ja niestety często generuje duże obciążenia na poziomie 50-250 TB zapisu na dysk 1 TB rocznie, ale to zasługa głównie charakterystyki usługi jaką jest serwer VPS.

A jakie były pierwsze modele dysków SSD jakie używaliście? Staram się sięgać pamięcią i przypomnieć sobie co to było ;-). Pamiętam, że pierwszym dyskiem SSD jaki użyłem z interfejsem SATA3 był Crucial C300 gdzieś w 2010 roku. To był oszałamiający wzrost wydajności jeśli chodzi o odczyt, dysk rozpędzał się już do 355 MB/s, zapis w zależności od modelu wahał między 55, a 215 MB/s ;-). Miałem kilka legendarnych dysków intela model X25-E, który charakteryzował się niesamowitą jak na tamte czasy wydajnością 250 MB/s odczyt i 170 MB/s zapis. Dysk był cholernie drogi i jako pierwszy miał sensowny endurance, dzięki zastosowaniu kości SLC. A wydajność 35k / 3k iops powalała. Mało kto pamięta, że pierwsze dyski SSD miały konstrukcję dużo bardziej zbliżoną do pendrive niż do współczesnych dysków SSD ;-). A jednak mimo wszystko dawały zauważalny wzrost wydajności, chociaż te konstrukcje były bardzo drogie i szybko padały. Nie pamiętam jakie dokładnie to były modele, ale było to zdecydowanie przed 2008 rokiem. Może Wy macie lepszą pamięć?

Pewnie się da, ale jednak to jest już ekstremalne odzyskiwanie danych. Na codzień preferuję RAID i KOPIE ;-)

Dyski Samsung 850, które mi padły zawsze zachowywały się podobnie. Były zupełnie nie widoczne przez serwer/komputer. Więc wydaje mi się że odzyskanie danych z nich mogły by być problematyczne ;-).

@Tomek test podesłany przez Ciebie jest bezwartościowy i nie ma tego jakkolwiek porównać do zastosowań produkcyjnych. Na żywotność dysku maja wpływ takie czynniki jak: - Obsługa lub nie TRIM - Zajętość dysku % (im dysk bardziej zajęty, tym dysk szybciej się zużywa) - Stopień zastępowania i migracji danych (zapis na SSD jest rozrzucany po najmniej zużytych komórkach. Wiec jeśli 50% danych jest stała i się nie zmienia, komórki w których one są trzymane były zapisywane 1x, natomiast cała reszta zapisu i zmieniajacych się danych nadpisuje cały czas 50% pozostałych komórek) - Typ danych (dyski SSD wewnętrznie kompresują dane) - Rozmiar rekordu - Temperatura pracy - i szereg innych czynników Ja powiem tylko tyle, że mam bardzo negatywne doświadczenie z samsungami 850 PRO. Są to jedyne dyski, które mi fizycznie padły. Co prawda po wyjęciu już z serwerów, ale jednak. Endurace który te dyski wytrzymywały, niewiele przekraczał ten na który była przewidziana gwarancja. Był to jedyny model który miałem i zdecydowałem się na całkowite zastąpienie go innymi rozwiązaniami.

@smarthost model to najważniejsza sprawa ;-). Był to dysk z serii desktop, czy enterprise? Kiedyś HW nie radziły sobie dobrze z obsługą dysków SSD i obsługą TRIM. Więc dyski via HW zużywały się zauważalnie szybciej. Nie wiem jak teraz jest z współczesnymi kontrolerami RAID, ponieważ od 4 lat używam tylko i wyłącznie trybu JBOD.

@nrm jeśli nie generujesz dużego zapisu, to dyski desktopowe bez problemu sobie radzą i ich awaryjność jest bliska zera. Tam gdzie generuje mały zapis stosuję dyski desktop, tam gdzie generuje duży zapis tam stosuje enterprise. Dysków SSD używam produkcyjnie od 6-7 lat i nigdy nie utraciłem ani bajta danych klientów ;-). @smarthost jakie modele?

Mój najbardziej wyeksplatowany dysk ma lekko ponad 36k godzin i cały czas działa bezawaryjnie. Jeśli chodzi zaś o endurance, najwięcej zrobiłem na jedym dysku ~560 TB i był to 1 TB Cruciam M550.