Milyen SSD xen dom0 alá?

Merevlemezek, vezérlők

Sziasztok

Eddig 250-320GB-s WD RE2, RE3 diszkeket használtam XenServer rendszer alá RAID1-ben. Kezdenek kiöregedni, szép 50-60 ezer üzemórát megéltek.
Feleslegesnek érzem, hogy 1TB WD RE4-re cseréljem, mivel default install 4GB a root, ezt szoktam 20GB-re felhúzni és bőven elég.
Kinek mi a tapasztalata? SSD-k elmennek már ennyi ideig? Korábban Kingstonnál láttam kis ~30GB-s méretű MLC-s SSD-ket ~10.000 Ft-ért. Ezek kifejezetten ilyen céllal léteznek? Na ezekből már csak mSATA-t látok.
Esetleg más alternatíva?

  • 2285 megtekintés

( _ventura_ v | 2017. 01. 11., sze – 12:34 )

Az új xenserver 7 ben már 64G vagy több a root defaultban :>

Fedora 25, Thinkpad x220

( Sixday v | 2017. 01. 11., sze – 12:45 )

Samsung 850 Pro, jelenleg a legstrapabirobb elerheto aru SSD a piacon szerintem.

-1. Bár papíron 0,3 drive write/day-t tud, valójában ennek a felénél is képes durván lelassulni, még akkor is, ha fenntartasz rajta 7-10%-ot overprovisionnek. Mi annakidején vettünk egy csomót, aztán megváltás volt lecserélni őket Intelre.
(DC S35xx sorozat: 0,3 DWPD, DC S36xx sorozat: 3 DWPD, DC S37xx sorozat: 10 DWPD)

Az SSD csak akkor tudja, hogy mennyi hasznos adat van rajta, ha törléskor trimmeled a felszabaduló területet. A trim nem minden szoftver/hardver környezetben lehetséges. Ekkor az első teleírástól számítva az SSD mindig "tele van", akkor is, ha számodra nincs rajta hasznos adat.

Az SSD firmware próbálja optimalizálni az írást, és a cellák írásciklusát. Ezen segít a trim, az overprovisioning, és persze a firmware "minősége".

Nálunk a fejlesztőknek némi SQL bazgerálással, automatizált build projektekkel nagyjából 2 hét alatt sikerült úgy leültetni a 850 Pro-kat, hogy utána kb. 20 MByte/sec-kel volt hajlandó írni, és egy sima 500 MByte-os fájl átmásolása 20-as loadot okozott az iowait miatt. Ilyenkor, ha teljesen kiürítettük az SSD-t, és Samsung magician-ból toltunk rá egy teljes trim-et, akkor utána ismét ment az eredeti sebességével - kb. újabb két hétig.

Aztán meguntuk, és vettünk Intel DC S3610-eket, és darab-darab kicseréltük őket. Azóta közel két éve mennek, és _semmi_ észrevehető lassulás sincs azóta sem, az írási teljesítmény megegyezik a nullkilométeres korukkal.

A 850 Pro mezei desktop gépbe jó, ahol elenyésző írási mennyiség van.

Mi az 512GB-os 850 Pro-kból készített RAID1-re 480GB-os partíciót hoztunk létre. Lehet, hogy 400GB fölé nem lett volna szabad menni.

Mindegy, nem személyautóval kell aratni, és kombájnnal közértbe menni. A 850 Pro remek desktopba, viszont munkaállomásba és szerverbe pedig meg kell venni legalább az S3510-et. Annyival nem drágább, mint amennyivel többet ad.

+1
Teljesen ismerősek a szimptómák. Mi 840 Pro-val tapasztaltuk ugyanezt, IBM blade-ekben, ahol az LSI SAS controllerre (SATA compatibility módban) voltak rákötve. Az LSI-n valamiért a trim nem ment át, viszonylag sokféle ötletet kipróbáltunk, de nem segített. Jenkins slave-ek voltak rárakva, buildelés nyilván eléggé megtekeri random írással. 25% overprovisioning-et állítottunk be (particionálással, a címtartomány végére így soha nem került egyetlen írásművelet sem).

Eleinte nagyon jó volt a teljesítményük, de idővel vállalhatatlan szintre belassultak és hatalmas load-ot csináltak a szerveren. Ha kivettük a szerverből és desktop gépben megtrimmeltük (hdparm-mal), akkor egy darabig megint jó volt, aztán idővel újra leromlott. Másrészt write amplification is az egekig felment, volt olyan példány, ami 2 hét alatt kb 2000 teljes írási ciklust szedett össze - közel sem volt ennyire meghajtva. Ez a SMART szerint a névleges élettartam kb 40%-a.

Mikor kínunkban visszaraktuk a mechanikus SAS diszkeket, nagyságrendeket gyorsultak a build futások és rögtön eltűntek a nagy load-ok.

Annyi bizonyos, hogy a Samsungok nagyon rosszul viselik a trim hiányát és ezen az overprovisioning sem segít, talán max késlelteti a probléma megjelenését.
---
Régóta vágyok én, az androidok mezonkincsére már!