Als ik het goed begrijp,
- een SSD * kan worden toegewezen om meerdere backing-HDDs te cachen, en vervolgens kunnen de resulterende cacheapparaten worden RAIDed met mdadm
of - meerdere HDDs kunnen worden RAIDed in een enkel backing-md-apparaat en de SSD toegewezen om dat te cachen
Ik vraag me af wat de verstandigere benadering is. Het komt bij me op dat het kweken van een RAID5 / 6 eenvoudiger kan zijn met een of andere techniek, maar ik ben niet zeker welke!
Zijn er goede redenen (bijv. het vergroten van de back-upopslag of iets anders) om de ene benadering boven de andere te kiezen (voor een groot niet-rootbestandssysteem met VM-back-upbestanden)?
* met “een SSD” bedoel ik een soort redundant SSD-apparaat, bijv. een RAID1 van twee fysieke al SSDs
Reacties
Answer
Ik denk dat het logisch is om het hele md-apparaat in de cache te plaatsen.
Bcache plaatsen om de hele md-apparaat offert het hele idee van een raid op, omdat het nog een single point of failure introduceert.
-
OTH-fouten van SSD-schijven zijn relatief zeldzaam, en bcache kan in de
writethrough/writearoundmodus (in tegenstelling tot dewritebackmodus), waarin er geen gegevens zijn alleen opgeslagen op het cacheapparaat, en het falen van de cache doodt de informatie in de raid niet, waardoor het een relatief veilige optie is. -
Ander feit is dat er aanzienlijke rekenkundige overhead van zachte RAID-5; wanneer elk draaiend raidlid afzonderlijk in de cache wordt opgeslagen, moet de computer dat nog steeds doen Bereken alle pariteiten opnieuw, zelfs bij cache-hits.
-
Het is duidelijk dat je “wat dure SSD-ruimte opoffert als je elke draaiende schijf afzonderlijk in de cache plaatst.– Tenzij u van plan bent om overvallen ssd-cache te gebruiken. -
Beide opties hebben relatief geen invloed op de tijd van het groeiproces – hoewel de optie waarbij draaiende schijven afzonderlijk in de cache worden opgeslagen, mogelijk langzamer kan zijn vanwege meer busverkeer.
Het is een snel en relatief eenvoudig proces om bcache te configureren om de ssd-schijf te verwijderen wanneer u deze moet vervangen. Dankzij de blocks zou het mogelijk moeten zijn om de raid-setup in beide richtingen on-place te migreren.
Je moet ook onthouden dat op dit moment de meeste (alle?) live- CD-distributies ondersteunen bcache niet, dus u kunt “niet eenvoudig toegang krijgen tot uw gegevens met dergelijke tools, ongeacht de bcache – mdraid layout-optie die je hebt gekozen.
Reacties
- I ' heb de vraag bijgewerkt om duidelijk te maken dat ik ' m niet van plan ben om een niet-redundante SSD-cache te hebben. Uw tweede punt punt is een uitstekende poi nt, bedankt daarvoor. Je derde punt over ruimte: bedoel je omdat je ' de pariteit op SSD zou opslaan? re je laatste para, ik ' m gebruik ik F20 maar zal uiteindelijk RHEL / CentOS7 of Debian Jessie gebruiken (als bcache-tools het haalt).
- @JackDouglas Ad 3e opsommingsteken: ja, precies dat. Maar aangezien u van plan bent om raided ssd-schijven te gebruiken, is dat ' niet op u van toepassing.
- Dat doet het nog steeds omdat ze ' ll niet alleen worden gespiegeld, maar zal ook de RAID-pariteit voor de ondersteunende schijven moeten opslaan. Dit is niet ' het geval als de RAID wordt uitgevoerd onder bcache waarvan ik dacht dat het jouw punt was
- Ik denk dat je het tegenovergestelde bedoelt: ssd-matrix doet ' t hoeft de draaiende schijven ' pariteit op te slaan, als het de hele mdraid-schijf wordt gevoed.
- ja, dat ' is precies wat ik bedoel!
Antwoord
I ” Ik denk dat het verstandig is om het resulterende MD-apparaat in de cache te plaatsen.
bcache is ontworpen om sequentiële lees- en schrijfbewerkingen door te geven.
Als je elk apparaat afzonderlijk, logischerwijs, meerdere apparaten bcache striping naar een overvallen of gestripte MD, zal, vanuit het bcache-perspectief, constant willekeurige blokken schrijven.
Terwijl een bcached MD-volume er normaal uitziet, schrijft het bestanden naar het volume in plaats van willekeurige blokken naar verschillende apparaten.
Het hele punt van hard- en software-raid is om de gegevens in de backend te strippen, zodat de resulterende filesys tem ziet eruit als een normaal volume.
Dit is misschien niet correct (aangezien bcache-ontwikkelaars misschien slim zijn en rekening houden met dat soort situaties), maar het logische optimale ding om te doen is om volumes te cachen in plaats van te blokkeren apparaten.
Opmerkingen
- ook een zeer goed punt
- Een grote opeenvolgende schrijfbewerking naar een RAID5 / 6 produceert opeenvolgende schrijfbewerkingen naar alle componenten. Elk componentapparaat krijgt elk N-1-gegevensblok (of pariteit), maar de gegevens die het ontvangt, zijn opeenvolgend. Maar je ' hebt gelijk dat het dingen vervormt. Als er enkele chunks zijn die regelmatig partiële-streep-schrijfbewerkingen zien, resulterend in een lees-wijzig-schrijfbewerking van (een deel van) de pariteitsstreep, kan dat in de cache worden opgeslagen door bcache. Het zou echter nog beter zijn om het hoger in de cache te plaatsen, voordat de gedeeltelijke streep-schrijfbewerking ooit het MD-apparaat raakt.
bcachebacks moeten worden opgemaakt metbcache– dus u ' moet ofwel eenmdarray, formatteer de enkele resulterende schijf volledig als eenbcacheondersteunde partitie, koppel het aan het cachestation en ga van daaruit, of formatteer veel schijven metbcache, koppel ze aan hun cache-station en formatteer de vele schijven als één array. In beide gevallen zijn er meerdere punten van mogelijke mislukking die allemaal afhangen van de interoperabiliteit tussen twee bestandssystemen – om nog maar te zwijgen van de uiteindelijke fs. zie hier : scroll naar beneden .