diff --git a/nl_NL.ISO8859-1/books/handbook/vinum/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/vinum/chapter.sgml index 5c6a96e86b..4f3401758b 100644 --- a/nl_NL.ISO8859-1/books/handbook/vinum/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/vinum/chapter.sgml @@ -1,1473 +1,1478 @@ Greg Lehey Geschreven door Erwin Kooi Vertaald door De VINUM volumebeheerder Overzicht Welke harde schijven er ook gebruikt worden, er zijn altijd mogelijke problemen: Ze kunnen te klein zijn. Ze kunnen te traag zijn. Ze kunnen te onbetrouwbaar zijn. Er zijn verschillende oplossingen voor deze problemen voorgesteld en geïmplementeerd. Eén manier waarop gebruikers zich wapenen tegen een aantal van deze problemen is door meerdere en soms ook redundante schijven te gebruiken. Naast ondersteuning voor verschillende kaarten en controllers die hardware-RAID ondersteunen, bevat het &os; basissysteem ook de Vinum Volume Manager, een blokapparaatstuurprogramma waarmee virtuele schijven gemaakt kunnen worden. Vinum is een zogenaamde Volume Manager, een stuurprogramma voor virtuële schijven dat deze drie problemen in beschouwing neemt. Vinum biedt meer flexibiliteit, prestaties en betrouwbaarheid dan traditionele schijfopslag en er kan RAID-0, RAID-1 en RAID-5 mee gemaakt worden of een combinatie van deze RAID-niveaus. In dit hoofdstuk wordt een overzicht gegeven van de mogelijke problemen die traditionele schijfopslag met zich meebrengt en de Vinum Volume Manager wordt geïntroduceerd. Vanaf &os; 5, is Vinum herschreven om in de GEOM-architectuur () te passen, met behoud van de originele ideëen, terminologie, en metagegevens die op de schijf staan. Deze herschrijving wordt gvinum (voor GEOM vinum) genoemd. De volgende tekst refereert aan Vinum als een abstracte naam, onafhankelijk van de implementatievariant. Alle commando-aanroepen dienen nu met het commando gvinum gedaan te worden, en de naam van de kernelmodule is veranderd van vinum.ko naar geom_vinum.ko, en alle apparaatknooppunten bevinden zich in /dev/gvinum in plaats van /dev/vinum. Sinds &os; 6 is de oude implementatie van Vinum niet meer beschikbaar in de broncode. Schijfgrootte Vinum RAID software De capaciteit van schijven wordt groter, maar ook de vraag naar capaciteit neemt toe. Vaak is het gewenste bestandssysteem groter dan de op dat moment beschikbare schijven. Hoewel dit probleem niet meer zo actueel als het tien jaar geleden was, bestaat het nog steeds. In sommige systemen is dit opgelost door een virtuele harde schijf te maken die de gegevens op meerdere fysieke harde schijven kan opslaan. Snelheid van toegang Moderne systemen hebben vaak simultaan toegang tot gegevens nodig. FTP en webservers kunnen bijvoorbeeld duizenden simultane sessies onderhouden en hebben vaak meerdere 100 Mbit/s verbindingen met de rest van de wereld. De benodigde gegevensdoorvoer is dan groter dan de meeste schijven kunnen leveren. Huidige schijven kunnen gegevens sequentieel overdragen met ongeveer 70 MB/s, maar deze snelheid heeft geen waarde in een omgeving waar onafhankelijke processen toegang tot de schijf hebben. In zo'n situatie is het interessanter om vanuit het standpunt van de schijfstuurprogramma te kijken: de belangrijkste parameter is dan de belasting die een bepaalde gegevensoverdracht op het stuurprogramma plaatst. Met andere woorden: wat is het tijdsbeslag van een gegevensoverdracht op te schijf? Bij elke gegevensoverdracht moet de schijf eerst zijn kop positioneren, wachten tot de eerste sector onder de kop doorkomt en vervolgens de overdracht starten. Deze acties duren bijzonder kort. Het heeft geen enkele zin om ze te onderbreken. Neem een overdracht van ongeveer 10 kB: de huidige generatie high-performance schijven kan de kop in 3.5 ms plaatsen. De snelste schijven draaien met 15.000 toeren per minuut, dus de gemiddelde rotatie vertraging (een halve omwenteling) bedraagt 2 ms. Met 70 MB/s de overdracht zelf duurt ongeveer 150 μs, bijna niets vergeleken met de tijd die verloren is gegaan aan het positioneren. In zulke gevallen daalt de gegevensoverdracht naar iets meer dan 1 MB/s en is dus duidelijk afhankelijk van de grootte van de over te dragen gegevens. De traditionele en logische oplossing voor dit probleem is meer schijven: in plaats van één grote schijf, meerdere kleine schijven met een zelfde totale opslagcapaciteit. Iedere schijf is in staat om onafhankelijk de kop te plaatsen en de gegevens over te dragen, dus de effectieve doorvoer neemt toe met een factor bijna gelijk aan het aantal schijven. De exacte verbetering van de doorvoer is natuurlijk kleiner dan het aantal schijven, want hoewel iedere schijf in staat is om parallel de gegevens over te dragen, er is geen garantie dat de gegevens gelijk over de schijven verdeeld is. De belasting op de ene schijf zal dan ook groter zijn dan op de andere schijf. aaneenschakelen schijven aaneenschakelen Vinum aaneenschakelen RAID Een gelijke belasting van de schijven is in grote mate afhankelijk van de manier waarop gegevens over de schijven zijn verdeeld. In het volgende stuk is de opslag van een virtuele schijf voor te stellen als een verzameling sectoren die met een nummer aangesproken kan worden, net als bladzijden in een boek. De meest voor de hand liggende methode om een virtuele schijf te maken is het achter elkaar plakken van de fysieke schijven. Een virtueel boek zou dan opgebouwd zijn uit verschillende achter elkaar zittende fysieke hoofdstukken. Deze methode heet aaneenschakelen (concatenation) en heeft het voordeel dat schijven verschillend van grootte kunnen zijn. Dit werkt prima als toegang tot de gegevens gelijk verdeeld is over de hele gegevensverzameling. Als die toegang beperkt is tot een klein deel van de gegevensverzameling, is de snelheidsverbetering een stuk kleiner. laat de manier zien hoe aaneengeschakelde schijven hun gegevens opslaan.
Aaneengeschakeld georganiseerd
verdelen schijven stripen Vinum verdelen Een andere methode is het verdelen van de totale opslag van de virtuele schijf in kleinere stukjes van gelijke grootte en ze achter elkaar op verschillende fysieke schijven op te slaan. Bijvoorbeeld: de eerste 256 sectoren worden op schijf 1 opgeslagen, de tweede 256 sectoren op schijf 2 enzovoort, tot de laatste schijf is gebuikt, waarna weer bij schijf 1 verder wordt gegaan, net zolang tot de schijven vol zijn. Deze methode heet verdelen (striping) of RAID-0. RAID staat voor Redundant Array of Inexpensive Disks (Redundante Reeks van Goedkope Schijven) en biedt verschillende vormen van fouttolerantie. Hoewel die laatste term wat misleidend is: het biedt namelijk geen redundantie. . Bij RAID-0 kost het iets meer moeite om de gegevens te vinden en het kan extra I/O belasting met zich meebrengen als gegevens zijn verdeeld over verschillende fysieke schijven. Het kan echter ook zorgen voor een constantere belasting van die schijven. geeft weer hoe RAID-0 schijven hun gegevens opslaan.
Verdeeld georganiseerd
Betrouwbaarheid van gegevens Het laatste probleem met de huidige schijven is dat ze onbetrouwbaar zijn. Hoewel de betrouwbaarheid de laatste jaren enorm is toegenomen, blijven schijven het vitale onderdeel van een server dat waarschijnlijk als eerste kapot gaat. Als dat gebeurt kan het catastrofale gevolgen hebben: het vervangen van de schijf en het terugplaatsen van de gegevens kan dagen kosten. spiegelen schijven spiegelen Vinum spiegelen RAID-1 De traditionele manier om dit te voorkomen is spiegelen (mirroring): het hebben van een kopie van de gegevens op een andere fysieke schijf. Sinds de uitvinding van RAID niveaus staat dit bekend als RAID-1. Een schrijfactie naar de virtuele schijf gebeurt op beide fysieke schijven. Een leesactie hoeft slechts vanaf één te gebeuren. Op deze manier kan de virtuele schijf dus blijven werken als één van de twee fysieke schijven kapot is. RAID-1 heeft twee problemen: Prijs. Er is twee keer zoveel schijfruimte nodig als bij een niet-redundante schijf. Prestatie. Een schrijfactie moet op twee schijven gebeuren en kost dus twee keer zoveel bandbreedte. Een leesactie hoeft maar op één schijf te gebeuren en heeft hier dus geen last van. RAID-5 Een andere manier is pariteit, uitgevoerd in RAID niveaus 2, 3, 4 en 5. Van deze vier is RAID-5 het meest interessant. In Vinum is het geïmplementeerd als een variant van een verdeelde organisatie waarbij één blok van elk deel is gereserveerd voor de pariteit van de andere blokken. Voor Vinum is een RAID-5 samenstelling (plex) dan ook gelijk aan een verdeelde samenstelling, met als verschil dat het een pariteitblok bevat in ieder deel. Zoals voorgeschreven door RAID-5 wisselt de locatie van dit pariteitblok van het ene deel naar het andere. De nummers in de gegevensblokken geven de relatieve bloknummers aan.
RAID-5 georganiseerd
Vergeleken met spiegelen heeft RAID-5 het voordeel dat er beduidend minder opslagcapaciteit nodig is. Lezen gebeurt op dezelfde manier als bij een verdeelde organisatie, maar schrijven kost beduidend meer tijd, ongeveer 25% van de leesprestaties meer. Als één schijf uitvalt, kan de reeks doorwerken in een verslechterde staat (degraded mode): gegevens van een functionerende schijf kunnen zonder problemen gelezen worden, maar gegevens van de defecte schijf moeten eerst worden samengesteld uit de pariteit van de overeenkomende blokken van de resterende schijven. Vinum objecten Om deze problemen op te lossen, hanteert vinum een hiërarchie met vier niveaus van objecten: Het meest zichtbare object is de virtuele schijf. Dit object wordt volume genoemd. Op een paar kleine details na, hebben volumes dezelfde eigenschappen als een &unix; schijf. Het belangrijkste verschil is dat er geen beperking aan de grootte van de schijf is. Volumes zijn opgebouwd uit samenstellingen, die elk de totale opslagcapaciteit van het volume hebben. Dit niveau in de hiërarchie biedt daarom redundantie. Een samenstelling is goed voor te stellen als een individuele schijf in een RAID-1 systeem. Iedere schijf bevat dezelfde gegevens. Omdat Vinum bestaat binnen het &unix; opslagsysteem, moet het mogelijk zijn om &unix; partities te gebruiken als bouwstenen voor samenstellingen die uit meerdere schijven bestaan. Maar het blijkt dat dit te inflexibel is: &unix; schijven hebben een beperkt aantal partities. In plaats daarvan verdeelt Vinum een &unix; partitie (de schijf) in aaneengesloten stukken die subschijven worden genoemd. Deze subschijven worden vervolgens als bouwstenen voor de samenstelling gebruikt. Subschijven bestaan op Vinum schijven, op dit moment &unix; partities. Een Vinum schijf kan een oneindig aantal subschijven bevatten. Met uitzondering van een klein stukje aan het begin van de schijf, dat wordt gebruikt om informatie over de instellingen en de toestand op te slaan, is de gehele schijf beschikbaar voor de opslag van gegevens. In de volgende paragrafen wordt beschreven hoe deze objecten de functionaliteit van Vinum leveren. Volumegrootte overwegingen Een samenstelling kan meerdere subschijven bevatten die uitgespreid zijn over alle schijven in de Vinum instelling. Dat houdt in dat de grootte van een individuele schijf geen limiet is voor de samenstelling en dus niet voor het volume. Redundante gegevensopslag Vinum implementeert RAID-0 door meerdere samenstellingen aan een volume te koppelen. Elke samenstelling representeert hierbij de gegevens in het volume. Een volume kan tussen de één en acht samenstellingen bevatten. Hoewel een samenstelling de totale gegevens van een volume voorstelt, is het mogelijk dat delen van deze voorstelling missen, door ontwerp (door geen subschijf voor delen van de samenstelling te definiëren) of per ongeluk (door een defecte schijf). Zo lang tenminste één samenstelling de gegevens voor het gehele volume kan leveren, is het volume volledig bruikbaar. Prestaties Vinum implementeert aaneenschakelen en spiegelen op het niveau van de samenstelling: Een aaneengeschakelde samenstelling gebruikt de adresruimte van elke subschijf achter elkaar. Een verdeelde samenstelling spreiden de gegevens over iedere subschijf. De subschijven moeten daarvoor allemaal dezelfde grootte hebben en er moeten tenminste twee subschijven zijn om onderscheid te kunnen maken met een aaneengeschakelde samenstelling. Welke samenstelling? De versie van Vinum die met &os; &rel.current; wordt meegeleverd, kent twee soorten samenstellingen: Aaneengeschakelde samenstellingen zijn het meest flexibel: ze kunnen een oneindig aantal subschijven bevatten die verschillend van lengte mogen zijn. De samenstelling kan uitgebreid worden door subschijven toe te voegen. Ze kosten minder CPU tijd dan verdeelde samenstellingen, hoewel het verschil van de CPU belasting niet meetbaar is. Aan de andere kant, ze zijn het meest kwetsbaar voor hot-spots, waar één schijf heel intensief gebruikt wordt en anderen ongebruikt blijven. Het grootste voordeel van verdeelde samenstellingen (RAID-0) is dat ze geen hot-spots hebben. Door het kiezen van een optimale deelgrootte (veelal 256 kB) kan de belasting op de fysieke schijven gelijk getrokken worden. De nadelen van deze aanpak zijn (minuscuul) complexere code en beperkingen aan de subschijven: ze moeten allemaal van gelijke grootte zijn en het uitbreiden van een samenstelling met extra subschijven is zo gecompliceerd, dat de huidige versie van Vinum dit niet ondersteunt. Vinum voegt een extra, triviale, beperking toe: een verdeelde samenstelling moet tenminste twee subschijven hebben, omdat die anders niet onderscheiden kan worden van een aaneengeschakelde samenstelling. In worden de voor- en nadelen van elke samenstelling samengevat. Vinum samenstellingen Samenstellingtype Min. aantal subschijven Subschijven toevoegen Gelijke grootte Toepassing aaneengeschakeld 1 ja nee Veel gegevensopslag met maximale flexibiliteit en gemiddelde performance. verdeeld 2 nee ja Hoge prestaties, ook bij veel gelijktijdige toegang.
Voorbeelden Vinum houdt een instellingendatabase bij waarin beschreven staat welke objecten bekend zijn in het systeem. Bij het instellen vult de gebruiker deze database uit één of meer instellingenbestanden met behulp van het hulpprogramma &man.gvinum.8;. Vinum bewaart een kopie van de database op iedere slice (die Vinum apparaat noemt) die door Vinum wordt beheerd. Deze database wordt na iedere statuswijziging bijgewerkt, zodat een na een herstart accuraat de toestand van ieder Vinum object wordt weergegeven. Het instellingenbestand Het instellingenbestand beschrijft de individuele vinum objecten. De definitie van een eenvoudig volume kan er zo uitzien: drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a Dit bestand beschrijft vier Vinum objecten: De drive regel beschrijft een partitie (drive) en de relatieve positie ten opzichte van de onderliggende hardware. Het heeft de symbolische naam a. Deze scheiding van de symbolische naam van de schijf maakt het mogelijk om schijven te verplaatsen van de ene locatie naar de andere, zonder verwarring te veroorzaken. De volume regel beschrijft een volume. Het enige benodigde attribuut is de naam: myvol. De plex regel beschrijft een samenstelling. Het enige benodigde attribuut is de organisatie, in dit geval concat. Er is geen naam nodig: het systeem genereert automatisch een naam door .px aan de volumenaam toe te voegen, waarbij x het nummer van de samenstelling in het volume is. De naam van deze samenstelling wordt dus myvol.p0. De sd regel beschrijft een subschijf. De minimale specificaties zijn de naam van een schijf waar de subschijf kan worden opgeslagen en de lengte van de subschijf. Net als bij een samenstelling is er geen naam nodig: het systeem genereert automatisch een naam door .sx aan de samenstellingnaam toe te voegen, waarbij x het nummer van de subschijf is. De naam van deze subschijf is dus myvol.p0.s0. Na het verwerken van dit bestand ziet de uitvoer van &man.gvinum.8; er als volgt uit: &prompt.root; gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB Deze uitvoer geeft de korte uitvoer van &man.gvinum.8; weer. Het is grafisch weergegeven in .
Een eenvoudig Vinum volume
Deze en de volgende figuren stellen een volume voor dat samenstellingen bevat die weer de subschijven bevatten. In dit triviale voorbeeld bevat het volume een samenstelling en deze samenstelling bevat een subschijf. Dit speciale volume heeft geen voordeel boven een gewone schijf partitie. Het bevat één samenstelling, dus het is niet redundant. De samenstelling bevat één subschijf, dus er is geen verschil in de plaats van de gegevens met een conventionele schijfpartitie. In de volgende paragrafen worden meer interessante instellingen getoond. Verbeterde betrouwbaarheid: spiegelen De betrouwbaarheid van een volume wordt vergroot door spiegelen. Bij het opzetten van een gespiegeld volume is het van belang dat subschijven van iedere samenstelling op een andere schijf staan, zodat een defecte schijf niet beide samenstellingen beïnvloedt. De volgende instelling maakt een gespiegeld volume: drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b In dit voorbeeld was het niet nodig om schijf a opnieuw te definiëren, omdat Vinum alle objecten bijhoudt in de instellingendatabase. Na het verwerken van deze definitie, ziet de instelling er als volgt uit: Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB Het is grafisch weergegeven in .
Een gespiegeld Vinum volume
In dit voorbeeld bevat iedere samenstelling de volledige 512 MB van de opslagcapaciteit. Net als in het vorige voorbeeld bevat iedere samenstelling slechts één subschijf. Verbeterde prestatie Het gespiegelde volume in het vorige voorbeeld is beter bestand tegen hardware fouten dan een niet-gespiegeld volume, maar de prestaties zijn lager: iedere schrijfactie naar het volume moet op beide schijven worden uitgevoerd, waardoor een groter deel van de bandbreedte van de schijf nodig is. Als prestaties een belangrijke rol spelen, moet er een andere benadering gekozen worden: in plaats van spiegelen worden de gegevens verdeeld over zoveel mogelijk schijven. De volgende instelling laat een volume zien waarbij een samenstelling over vier schijven verdeeld is: drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d Zoals eerder al te zien was, is het niet nodig om schijven die al bekend zijn bij Vinum opnieuw te definiëren. Na het verwerken van deze definitie, ziet de instelling er zo uit: Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB
Een verdeeld Vinum volume
Dit volume wordt weergegeven in . De grijstinten geven de positie binnen de samenstelling aan: de lichtste strepen komen het eerst, de donkerste het laatst. Betrouwbaarheid en prestaties Met voldoende hardware is het mogelijk om een volume te bouwen met zowel verbeterde betrouwbaarheid als verbeterde prestaties ten opzichte van een standaard &unix; partitie. De volgende instelling is een voorbeeld van zo'n volume: volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b De subschijven van de tweede samenstelling zijn twee schijven verschoven ten opzichte van die van de eerste samenstelling. Dit zorgt ervoor dat een schrijfactie niet naar dezelfde schijven gaat, zelfs niet als die schrijfactie over twee schijven plaatsvindt. laat deze instelling zien in grafische vorm.
Een gespiegeld en verdeeld Vinum volume
Objectnamen Zoals eerder in dit hoofdstuk beschreven staat, kent Vinum standaardnamen toe aan samenstellingen en subschijven. Er mag echter een andere naam aan gegeven worden. Een andere naamgeving wordt niet aangeraden: ervaring met de VERITAS volumebeheerder, die een willekeurige object benaming toestaat, heeft laten zien dat deze flexibiliteit geen beduidend voordeel heeft, terwijl het de kans op verwarring vergroot. Namen mogen bestaan uit alle karakters, behalve de spatie, maar het wordt aanbevolen om alleen letters, cijfers en het liggende streepje te gebruiken. De namen van de volumes, samenstellingen en subschijven kunnen 64 tekens lang zijn en de namen van schijven kunnen 32 tekens lang zijn. Vinum objecten worden apparaatknooppunten toegekend in de hiërarchie /dev/gvinum. Met de instellingen uit de vorige paragraaf creërt Vinum de volgende apparaatknooppunten: Dit heeft alleen betrekking op de historische Vinum implementatie. De controleapparaten /dev/vinum/control en /dev/vinum/controld, die door respectievelijk &man.gvinum.8; en de Vinum daemon gebruikt worden. Karakterapparaatingangen voor elk volume. Dit zijn de primaire apparaten die door Vinum gebruikt worden. De bovenstaande configuratie zou dus deze apparaten bevatten: /dev/gvinum/myvol, /dev/gvinum/mirror, /dev/gvinum/striped, /dev/gvinum/raid5 en /dev/gvinum/raid10. Dit heeft alleen betrekking op de historische Vinum implementatie. Een map /dev/vinum/drive met ingangen voor elke schijf. Deze ingangen zijn eigenlijk symbolische links naar de bijbehorende schijfknooppunten. Alle volumes krijgen ingangen direct onder /dev/gvinum/. De mappen /dev/gvinum/plex, en /dev/gvinum/sd, welke respectievelijk apparaatknooppunten voor elke plex en voor subschijf bevatten. Dit is een volgend voorbeeld: drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 Na verwerking van dit bestand maakt &man.gvinum.8; de volgende structuur aan in /dev/gvinum: drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 Hoewel het wordt aangeraden om samenstellingen en subschijven geen naam mee te geven, moeten Vinum schijven een naam hebben. Hierdoor kan een schijf naar een andere locatie verplaatst worden terwijl hij nog steeds automatisch herkend wordt. Schijfnamen mogen maximaal 32 tekens lang zijn. Bestandssystemen maken Volumes lijken voor het systeem identiek aan schijven, met één uitzondering: in tegenstelling tot &unix; schijven partitioneert Vinum het volume niet en het bevat dus geen partitietabel. Daarom was het nodig een paar schijfhulpprogramma's te veranderen, met name &man.newfs.8;, dat voorheen probeerde om de laatste letter van een Vinum volumenaam als een partitie te zien. Bijvoorbeeld: een schijf kan een naam hebben als /dev/ad0a of /dev/da2h. Deze namen stellen respectievelijk de eerste partitie (a) op de eerste (0) IDE schijf (ad) en de achtste partitie (h) op de derde (2) SCSI schijf (da) voor. Een Vinum volume kan daarentegen /dev/gvinum/concat heten, een naam die geen enkele relatie met een partitienaam heeft. Normaliter klaagt &man.newfs.8; als het de naam van de schijf niet kan interpreteren. Bijvoorbeeld: &prompt.root; newfs /dev/gvinum/concat newfs: /dev/vinum/gconcat: can't figure out file system partition Gebruik &man.newfs.8; om een bestandssysteem op dit volume aan te maken: &prompt.root; newfs /dev/gvinum/concat Op versies van &os; voor 5.0 heeft &man.newfs.8; een aanvullende vlag -v en het oude apparaatnaamgevingsschema: &prompt.root; newfs -v /dev/vinum/concat Vinum instellen De GENERIC kernel bevat geen Vinum. Het is mogelijk een kernel te bouwen waar Vinum in zit, maar dit wordt niet aangeraden. De standaard manier om Vinum te starten is als kernelmodule (kld). Het is zelfs niet nodig om &man.kldload.8; te gebruiken voor Vinum. Als &man.gvinum.8; wordt gestart en de module is niet geladen, dan gebeurt dit alsnog automatisch. Opstarten Vinum slaat de instellingeninformatie op de schijfslices op in ongeveer dezelfde vorm als de instellingenbestanden. Bij het lezen van de instellingendatabase herkent Vinum een aantal sleutelwoorden die niet zijn toegestaan in instellingenbestanden. Een schijfinstelling kan bijvoorbeeld de volgende tekst bevatten: volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b Duidelijke verschillen zijn de aanwezigheid van expliciete locatie informatie en namen (beide zijn toegestaan, maar worden afgeraden) en informatie over de toestand (die niet beschikbaar is voor de gebruiker). Vinum slaat geen informatie over schijven op in de instellingen: het vindt de schijven door de ingestelde schijven te scannen naar partities met een vinum label. Hierdoor kan Vinum zelfs schijven detecteren als ze aan een andere &unix; schijf worden toegekend. Automatisch opstarten Deze informatie heeft alleen betrekking op de - historische Vinum implementatie. + historische implementatie van Vinum. Gvinum start altijd automatisch op - als de kernelmodule eenmaal is geladen. + wanneer de kernelmodule eenmaal is geladen, via + &man.loader.conf.5;. Voeg + geom_vinum_load="YES" toe aan + /boot/loader.conf om de module + GVinum tijdens het opstarten te + laden. Om Vinum automatisch te laten starten als het systeem opgestart wordt, moet de volgende regel in het /etc/rc.conf bestand staan: start_vinum="YES" # op YES zetten om vinum te starten Als het /etc/rc.conf bestand niet bestaat, moet het gemaakt worden met de bovengenoemde inhoud. Hierdoor laadt het systeem de Vinum kld tijdens het starten en worden de objecten uit de instellingen ook gestart. Dit gebeurt voordat de bestandssystemen aangekoppeld worden. &man.fsck.8; kan dus automatisch draaien en bestandssystemen op Vinum volumes kunnen aangekoppeld worden. Als Vinum met vinum start wordt gestart, leest Vinum de instellingendatabase van één van de Vinum schijven. Normaal gesproken bevat iedere schijf een identieke kopie van de instellingendatabase. Het maakt dus niet uit welke schijf gelezen wordt. Na een crash moet Vinum echter bepalen welke schijf het laatst is bijgewerkt en de instellingen van die schijf gebruiken. Als het nodig is worden de instellingen van de oudere schijven daarna bijgewerkt, in volgorde van leeftijd. Het rootbestandssysteem op Vinum Bij een machine die een volledig gespiegeld bestandssysteem heeft, is het wenselijk ook het rootbestandssysteem te spiegelen. Het bouwen van zo'n instelling is niet zo rechttoe-rechtaan als bij een ander bestandssysteem omdat: Het rootbestandssysteem al heel snel beschikbaar moet zijn tijdens het opstartproces, dus de Vinum infrastructuur moet dan al beschikbaar zijn. Het volume met het rootbestandssysteem bevat ook de bootstrap en de kernel, die gelezen moeten worden door de eigen systeemprogramma's (bijvoorbeeld de BIOS op PC's), die meestal ingesteld kunnen worden om Vinum te gebruiken. In de volgende paragrafen wordt de term rootvolume gebruikt voor het Vinum volume dat het rootbestandssysteem bevat. Het is waarschijnlijk een goed idee om de naam root te gebruiken voor dit volume, maar dit is niet technisch noodzakelijk. Alle commandovoorbeelden in de volgende stukken gaan echter uit van deze naam. Vinum op tijd starten voor het rootbestandssysteem Om dit te bereiken, moeten een aantal stappen worden doorlopen: Vinum moet beschikbaar zijn voor de kernel tijdens het opstarten. De methode zoals beschreven in is dus niet geschikt en de start_vinum parameter mag zelfs niet aanwezig zijn als de volgende opzet wordt gebruikt. De eerste optie is Vinum statisch in de kernel te compileren, zodat het altijd beschikbaar is. Maar die is vaak niet wenselijk. Er is nog een mogelijkheid door /boot/loader () de Vinum kernel module te laten laden, voordat de kernel gestart wordt. Dit wordt gedaan door de volgende regel in /boot/loader.conf op te nemen: gvinum_load="YES" Voor Gvinum wordt alles automatisch opgestart nadat de kernelmodule eenmaal is geladen, dus is alleen de procedure die hierboven is beschreven nodig. De volgende tekst documenteert het gedrag van het historische Vinum systeem, voor oudere installaties. Vinum moet in een vroeg stadium geïnitialiseerd worden om het volume voor het rootbestandssysteem te kunnen leveren. De Vinum kernel module gaat niet uit zichzelf op zoek naar schijven die mogelijk een Vinum volume kunnen bevatten totdat de administrator (of een van de opstartscripts) een vinum start commando geeft. De volgende paragrafen laten de benodigde stappen zien voor &os;. Door de onderstaande regel in /boot/loader.conf te zetten, zoekt Vinum automatisch alle schijven af naar Vinum informatie als onderdeel van het starten van de kernel: vinum.autostart="YES" Het is dus niet nodig om de kernel te vertellen waar het rootbestandssysteem staat. /boot/loader zoekt de naam voor het root apparaat op in /etc/fstab en geeft deze informatie door aan de kernel. Op het moment dat het rootbestandssysteem aangekoppeld moet worden, haalt de kernel uit de apparaatnaam welk stuurprogramma gebruikt moet worden om dit te vertalen naar het interne apparaat-ID (grote/kleine nummer). Een Vinum rootvolume beschikbaar maken voor bootstrap Omdat de huidige &os; bootstrap maar 7,5 KB code bevat en al belast is met het lezen van bestanden (zoals /boot/loader) van het UFS bestandssysteem, is het bijna onmogelijk om het ook te leren hoe Vinum informatie gelezen moet worden en deze dan te gebruiken om de elementen van het bootvolume samen te stellen. Er zijn daarom een paar trucs nodig om de bootstrapcode wijs te maken dat er een standaard "a" partitie aanwezig is met het rootbestandssysteem. Om dit mogelijk te maken, moet het rootvolume aan de volgende eisen voldoen: Het rootvolume mag niet verdeeld of RAID-5 zijn. Het rootvolume mag niet meer dan één aaneengeschakelde subschijf per samenstelling bevatten. Het is mogelijk en wenselijk om meer dan één samenstelling te hebben, ieder met een replica van het rootbestandssysteem. Het bootstrapproces gebruikt wel maar één van deze replica's om de bootstrap en alle andere bestanden te vinden, tot het moment dat de kernel het rootbestandssysteem laadt. Iedere subschijf binnen deze samenstellingen heeft dus zijn eigen "a" partitievoorstelling nodig om dit apparaat opstartbaar te maken. Het is niet verplicht dat iedere voorgestelde "a" partitie op dezelfde offset is geplaatst binnen het apparaat, vergeleken met andere apparaten die samenstellingen van het rootvolume bevatten. Het is wel een goed idee om op die manier Vinum volumes te maken, zodat de resulterende gespiegelde apparaten symmetrisch zijn. Dit om verwarring te voorkomen. Om deze "a" partities voor ieder apparaat dat een deel van het rootvolume bevat te maken, moet het volgende worden gedaan: De locatie (offset vanaf het begin van het apparaat) en de grootte van de subschijf die onderdeel is van het rootvolume moet als volgt bekeken worden: &prompt.root; gvinum l -rv root De Vinum offsets en groottes worden aangegeven in bytes. Ze moeten door 512 worden gedeeld om de bloknummers te krijgen die in bsdlabel moeten worden gebruikt. Voor elk apparaat dat deelneemt aan het rootbestandssysteem moet het onderstaande command uitgevoerd worden: &prompt.root; bsdlabel -e apparaatnaam apparaatnaam moet of de naam van een schijf (zoals da0) voor schijven zonder slice-tabel zijn (ook wel: fdisk), of de naam van de slice zijn (zoals ad0s1). Als er al een "a" partitie op het apparaat aanwezig is (waarschijnlijk met een pre-Vinum rootbestandssysteem), moet die eerst worden hernoemd, zodat het wel toegankelijk blijft (voor de zekerheid), maar niet langer gebruikt wordt om het systeem van op te starten. Actieve partities (zoals een rootbestandssysteem dat op dit moment aangekoppeld is) kan geen andere naam gegeven worden. Dit moet dus gebeuren als het systeem vanaf een Fixit medium opgestart is of in twee stappen, waar (in een gespiegelde situatie) de schijf waar niet van opgestart is als eerste wordt aangepast. Daarna moet de offset van de Vinum partitie op dit apparaat (als het bestaat) opgeteld worden bij de offset van de rootvolume subschijf op dit apparaat. De resulterende waarde wordt de "offset" waarde voor de nieuwe "a" partitie. De "size" waarde voor deze partitie kan worden gehaald uit bovenstaande berekening. De "fstype" wordt 4.2BSD. De "fsize", "bsize" en "cpg" waardes moeten zo goed mogelijk worden gekozen om een daadwerkelijk bestandssysteem na te bootsen, hoewel ze vrij onbelangrijk zijn in deze context. Op deze manier wordt een nieuwe "a" partitie gemaakt dat de Vinum partitie op dit apparaat overlapt. Het bsdlabel staat deze overlap alleen toe als de Vinum partitie gemarkeerd is met het bestandssysteemtype "vinum". Dat is het! Er bestaat nu een nep "a" partitie op ieder apparaat dat een replica van het rootvolume heeft. Het is aan te bevelen om de resultaten nogmaals te verifiëren met iets als: &prompt.root; fsck -n /dev/devnaama Alle bestanden die controle informatie bevatten moeten relatief zijn ten opzichte van het rootbestandssysteem in het Vinum volume dat, bij het creëren van een Vinum volume, niet overeen hoeft te komen met het rootbestandssysteem dat op dit moment in gebruik is. Dit geldt in het bijzonder voor /etc/fstab en /boot/loader.conf. Bij de volgende herstart zou de bootstrap de juiste controle informatie moeten vinden in het nieuwe, op Vinum gebaseerde, rootbestandssysteem en moeten starten. Aan het einde van het kernel initialisatie proces, nadat alle apparaten aangemeld zijn, geeft het volgende bericht aan dat het opzetten gelukt is: Mounting root from ufs:/dev/gvinum/root Een op Vinum gebaseerde rootinstallatie Nadat het Vinum rootvolume is opgezet, geeft gvinum l -rv root een volgend resultaat: ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) De interessante waarden zijn 135680 voor de offset (relatief ten opzichte van de partitie /dev/da0h). Dit vertaalt zich naar 265 512-byte schijfblokken in bsdlabel termen. Zo is de grootte van dit rootvolume 245760 512-byte blokken. /dev/da1h, dat de tweede replica van dit rootvolume bevat, is symmetrische opgezet. Het bsdlabel voor deze apparaten kan er zo uitzien: ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) Hieruit blijkt dat de "size" parameter voor de nep "a" partitie overeenkomt met de waarde als hierboven beschreven en dat de "offset" parameter de som is van de offset binnen de Vinum partitie "h" en de offset van deze partitie binnen het apparaat (of de slice). Dit is een normale opzet om problemen te voorkomen zoals in beschreven is. Verder blijkt dat de hele "a" partitie volledig binnen de "h" partitie valt die alle Vinum gegevens voor dit apparaat bevat. In het bovenstaande voorbeeld is de volledige schijf voor Vinum gereserveerd en er is geen restant van de pre-Vinum rootpartitie, omdat dit een nieuwe schijf is die vanaf het begin af aan bedoeld was als onderdeel van een Vinum instelling. Problemen oplossen Als er iets fout gaat moet er een manier zijn om dat te herstellen. De volgende lijst bevat een paar bekende valkuilen en oplossingen. Systeem bootstrap laadt, maar systeem start niet door Als om wat voor reden dan ook het systeem niet doorgaat met opstarten, kan de bootstrap worden onderbroken door de spatie toets in te drukken tijdens de 10 seconden waarschuwing. Dan kunnen de loader variabelen (zoals vinum.autostart) bekeken worden met behulp van show en aangepast worden met set of unset. Als het enige probleem was dat de Vinum kernelmodule nog niet in de lijst van modules staat die automatisch geladen wordt, dan zal load geom_vinum helpen. Als alles in orde is, kan het opstartproces doorgestart worden met boot -as. De opties geven de kernel aan om het rootbestandssysteem te vragen (), en het opstartproces te stoppen in single-user mode (), waarbij het rootbestandssysteem als alleen-lezen aangekoppeld wordt. Op die manier is er geen risico op gegevensinconsistentie tussen de samenstellingen, zelfs niet als er maar één samenstelling van een multi-samenstellingen volume aangekoppeld is. Op de prompt, waar om het rootbestandssysteem gevraagd wordt, kan ieder apparaat dat een valide rootbestandssysteem bevat worden opgegeven. Als /etc/fstab goed is opgezet, is iets als ufs:/dev/gvinum/root te zien. Een typische andere keuze kan ufs:da0d zijn, dat een hypothetische partitie is die het pre-Vinum rootbestandssysteem bevat. Als één van de alias "a" partities ingevuld wordt die eigenlijk een referentie naar de subschijf van het Vinum rootapparaat zijn, dan wordt in een gespiegelde opzet maar éé kant van het gespiegelde volume aangekoppeld. Als dit bestandssysteem later als lezen/schrijven aangekoppeld wordt, moet(en) de andere samenstelling(en) van het rootvolume verwijderd worden, omdat deze samenstellingen anders inconsistente gegevens bevatten. Alleen primaire bootstrap laadt Als /boot/loader niet start, maar de primaire bootstrap laadt wel (zichtbaar door een enkel minteken in de linker bovenhoek van het scherm, direct na de start van het opstartproces), kan worden geprobeerd het primaire opstartproces te onderbreken door op de spatie toets te drukken. Dit zorgt ervoor dat het opstartproces stopt bij de tweede fase (zie ook ). Hier kan worden geprobeerd vanaf een andere partitie te starten, bijvoorbeeld van de partitie waar het vorige rootbestandssysteem op stond, dat nu van de "a" verplaatst is. Niets start, paniek van bootstrap Dit gebeurt als de bootstrap is vernietigd door de Vinum installatie. Helaas laat Vinum op dit moment slechts 4 KB vrij aan het begin van zijn partitie voordat de Vinum volume identificatie geschreven wordt. De stage 1 en 2 bootstraps en de bsdlabel-informatie hebben ongeveer 8 KB nodig. Dus als de Vinum partitie op offset 0 van de slice van de schijf begint die als opstartbaar was bedoeld, zal deze Vinum informatie de bootstrap vernielen. Als bovenstaande situatie is omzeild, bijvoorbeeld door te starten vanaf een Fixit medium, en de bootstrap opnieuw is aangemaakt met bsdlabel -B zoals beschreven in , overschrijft de nieuwe bootstrap de Vinum identificatie en kan Vinum de Vinum schijven niet langer vinden. Hoewel geen instellingsgegevens van Vinum of gegevens in de Vinum volumes overschreven wordt en alle gegevens hersteld kunnen worden door precies dezelfde instellingsgegevens van Vinum opnieuw in te vullen, is dit een lastige situatie om te herstellen. Het zou nodig zijn om de complete Vinum partitie tenminste 4 KB te verplaatsen, om te voorkomen dat de Vinum identificatie en de bootstrap met elkaar botsen.