Linux FailSafeTM Ready for prime-time?!
I
n dit abstract wordt eerst de werking van Linux FailSafeTM toegelicht en daarna volgt een overzicht van de aandachtsgebieden bij een NFS implementatie. Linux FailSafeTM Op CeBIT 2000 in Hannover werd aangekondigd dat SGI, in samenwerking met SuSE Linux AG, de IRIS FailSafe software beschikbaar zal maken onder GPL voor Linux. De bedoeling is om met een stabiele High-Availability cluster omgeving Linux nog beter inzetbaar te maken voor missioncritical toepassingen. Eind vorig jaar is een werkende versie beschikbaar gekomen en deze is o.a. gedemonstreerd in januari jl. op Linux Expo in de RAI in Amsterdam. 1 Linux FailSafe Opstellingen Om een valide beoordeling te kunnen maken over de inzetbaarheid van Linux FailSafe wordt eerst de werking van FailSafe behandeld. Linux FailSafe schaalt momenteel tot 4 nodes in een cluster met de mogelijkheid om opslagcapaciteit te delen (shared storage). Dit biedt de mogelijkheid om meerdere cluster nodes gecontroleerde toegang te geven tot dezelfde data bij een storing. Op deze manier kunnen bij een storing applicaties worden herstart op de overgebleven node(s) en de filesystemen beschikbaar gemaakt voor deze applicaties.
Fig. 1
1.1 Dual-Node Opstelling Figuur 1 geeft een schematisch overzicht van een dual-node opstelling met node-to-node reset mogelijkheid. Beide nodes zijn aangesloten op dezelfde externe storage middels een fibre channel bus. Een private ethernet verbinding is beschikbaar voor het ‘hartbeat’ verkeer. Wat bijzonder is aan deze opstelling is de mogelijkheid dat beide nodes elkaar kunnen resetten. Hiervoor is het nodig dat beide nodes zijn voorzien van een zogeheten EMP (IPMI) poort. Via deze tweede seriële poort kan de ene node de andere – eventueel via een uit-aan cyclus – resetten. Deze functionaliteit is een belangrijke toevoeging omdat het de mogelijkheid biedt om automatisch – eventueel via een power cyclus – een falende node weer op te brengen. In deze opstelling kunnen beide nodes actief zijn, of er kan gekozen worden voor een active-standby opstelling. In het laatste geval kan de standby node eventueel lichter worden uitgevoerd om kosten te besparen. 1.2 Multi-Node Opstelling In omgevingen waar meerdere High-Availability diensten moeten worden gecombineerd kan gekozen worden om meerdere nodes in een Linux FailSafe cluster op te stellen. Zie figuur 2 op de volgende bladzijde. In deze opstelling kunnen meerdere zogeheten ‘resource groups’ (=fail-over
pool. Deze pool wordt opgeslagen in de Linux FailSafe database. Deze database wordt gerepliceerd op iedere node in de pool. Dit houdt overigens niet in dat alle nodes actief participeren in het cluster. Er kunnen dus ook ‘spare’ nodes zijn. 2.3 Cluster Een Linux FailSafe cluster bestaat uit een aantal of alle nodes uit de pool. Er kan maar een cluster worden gedefinieerd in een cluster opstelling. De clusternaam is dus uniek. 2.4 Cluster Membership Het FailSafe cluster membership is de lijst van FailSafe nodes in het cluster die gebruikt kunnen worden om resource groups online te brengen.
Fig. 2
eenheid) worden ondergebracht op de verschillende nodes. Iedere resource group kan beschikbaar worden gemaakt op twee nodes, waartussen deze resource group kan ‘trippen’ tussen deze twee nodes. Iedere node kan ook iedere andere node in deze opstelling resetten. Voor de hartbeat verbindingen wordt gebruik gemaakt van een hub. Dit biedt voldoende bandbreedte. Wat in beide opstellingen naar voren komt is dat onder Linux FailSafe alleen externe Fibre Channel storage wordt ondersteund.
2 Failsafe Onderdelen en Concepten Om wat meer inzicht te verschaffen in Linux FailSafe wordt nu eerst ingegaan op de verschillende onderdelen en concepten. 2.1 Node Zoals fig.1 en fig.2 al aangaven bestaat een Linux FailSafe opstelling, een cluster, uit meerdere nodes. Iedere cluster node draait zelfstandig Linux. 2.2 Pool Al deze cluster nodes zijn opgenomen in de cluster
2.5 Resource Een resource is een enkele eenheid die een dienst levert aan een client of andere resource. Dit kan bijv. een enkele diskdrive zijn, een netwerk adres of een applicatie zoals een webserver. Alle resources hebben een resource naam en een resource type aanduiding . Ook kan een resource afhankelijk zijn van een andere resource. Zo kan bijv. een filesysteem niet geëxporteerd worden als het niet gemount is. 2.6 Resource type Een resource type deelt de resource in een bepaalde groep in. Alle resources van een bepaald resource type kunnen op dezelfde manier behandeld worden bij een zogeheten failover. Net zoals bij de resources kan ook een resource type afhankelijk zijn van andere resource types. Zo is bijv een resource type Netscape_web resource type afhankelijk van een resource type IP_address en resource type volume. Wanneer er bijv. een resource web1 is gedefinieerd met als resource type Netscape_web dan moet de resource group met web1 ook minstens een resource type IP_address en een resource van het type volume hebben.
2.7 Resource Name Een resource name maakt een specifieke resource uniek. Deze naam moet dan ook uniek zijn voor een bepaald resource type. 2.8 Resource group Een resource group is een unieke collectie van elkaar afhankelijke resources. Een resource group wordt aangeduid met een eenvoudige naam en moet uniek zijn in het cluster. Onderstaande tabel geeft een voorbeeld: Resource
Resource Type
10.10.48.22
IP_address
/fs1
Filesystem
vol1
volume
web1
Netscape_web
Wanneer van een resource group een onderdeel wegvalt dan valt de hele group weg en wordt daarmee niet langer beschikbaar. Dit houdt dus in dat een resource group in z’n geheel wordt herstart of overhevelt van de ene node naar de andere. Het is dus ‘the unit of failover.’ Resource groups kunnen elkaar ook niet overlappen; dwz., een resource zit maar in een resource group. 2.9 Resource Dependency List Een resource dependency list is een lijst van onderling afhankelijke resources. Deze afhankelijkheden moeten eerst correct worden aangebracht, alvorens een resource kan worden toegevoegd aan een resource group. Zo moet bijv. eerst een volume worden aangemaakt waarvan een filesysteem afhankelijk wordt gemaakt voordat de combinatie kan worden toegevoegd aan een resource group. 2.10 Failover Een failover is een proces waarbij een resource group van de ene node wordt overgeheveld naar de andere node, afhankelijk van de failover policy. Dit kan worden geïnitieerd door een falende node, een falende resource of ook met de hand door de systeem beheerder.
2.11 Failover Policy De failover policy is de methode van Linux FailSafe om te beslissen hoe een resource group of een applicatie aan een node wordt toegewezen. De failover policy bestaat uit de volgende onderdelen: • Failover domain • Failover attributes • Failover script Linux FailSafe gebruikt de failover domain uitvoer van een failover script, samen met de failover attributes om te bepalen op welke node een resource group thuis behoort te zijn. Iedere resource group moet een failover policy hebben en deze moet uniek zijn binnen een pool. 2.12 Failover Domain Een failover domain is de lijst van nodes waarop een bepaalde resource group actief kan worden gemaakt. Deze nodes moeten binnen hetzelfde cluster zijn, maar het hoeven niet alle nodes van het cluster te zijn. De systeem beheerder definieert het initiële failover domain wanneer de failover policy wordt aangemaakt. Deze lijst wordt getransformeerd naar een run-time failover domain door het failover script. Samen met de failover attributes en het FailSafe cluster membership bepaalt FailSafe op welke node de resource group initieel draait. Bij een volgende failover wordt opnieuw door het failover script de node bepaald waarop de resource group actief wordt. Normaal gesproken wordt een resource group actief op de eerst gedefinieerde node in het runtime failover domain die ook is gedefinieerd in het FailSafe cluster membership. 2.13 Failover Attribute Een failover attribute is een string die van invloed is hoe een resource group in een cluster ‘tripped’. Voorbeelden zijn Auto_Failback en Controlled_Failback. 2.14 Failover Scripts Wanneer een resource group ‘tripped’ dan wordt deze actie uitgevoerd door een failover script. Dit
zijn shell scripts die een run-time failover domain genereren en dit terug melden aan het ha_fsd process. Het ha_fsd process past de failover attributes toe en select de eerste node in het terug gerapporteerde failover domain dat ook onderdeel is van het huidige FailSafe cluster membership. Bij de huidige Linux FailSafe distributie zijn de volgende scripts meegeleverd: • ordered, deze wijzigt het initiële failover domain niet. Hier zijn het initiële en run-time failover domain hetzelfde. • round-robin, deze selecteerd de resource group eigenaar met een round-robin methode. Deze policy kan gebruikt worden voor resource groups die op elke node in het cluster kunnen draaien. Nieuwe scripts kunnen worden bijgemaakt, zie hiervoor het Linux Failsafe Programmer’s Guide. 2.15 Action Scripts De action scripts zijn scripts die bepalen hoe resource groups gestart, gemonitored en gestopt worden. Voor iedere resource type is er een set van deze scripts. Hierna volgt een complete lijst van mogelijke action scripts voor ieder resource type: • exclusive: deze verifieerd dat een resource nog niet draait. • start: deze start een resource • stop: stopt een resource • monitor: monitored een resource • restart: herstart een resource na een monitoring fout. Bij de distributie zit voor elke resource een set scripts. Deze kunnen gebruikt en aangepast worden naar gelieven, ook voor eigen resources.
3 Linux FailSafe Software Overzicht In dit gedeelte wordt de Linux FailSafe software architectuur toegelicht. We maken onderscheid in de volgende layers, zie fig. 3: • Cluster Software Infrastructure • High Availability Infrastructure • Linux Failsafe Base • Linux FailSafe Plugins Hierna volgt een korte beschrijving van de verschillende onderdelen.
Fig. 3
3.1 Cluster Software Infrastructure De cluster software infrastructuur biedt de volgende functionaliteit: • Node logging • Cluster Administratie • Node definitie De cluster software infrastructure omvat de onderdelen cluster_admin en cluster_control. 3.1.1 cluster_admin De cluster_admin bestaat uit de volgende daemon: • cad: Cluster administratie daemon. Deze voorziet in de administratieve services. 3.1.2 cluster_control • crsd: Node control daemon. Deze daemon monitored de seriële verbinding met de andere node. Heeft de mogelijkheid om de andere node te resetten. • cmond: Daemon die alle ander daemons beheert. Dit proces start per node al de andere processen op en herstart ze wanneer een fout optreedt. • cdbd: Beheert de configuratie database and houdt alle kopieën synchroon op alle nodes in de pool. 3.2 High-Availability Infrastructure De high-availability cluster infrastructure (cluster_ha) bestaat uit de volgende software onderdelen: • ha_cmsd: Cluster membership daemon. Deze
•
•
•
higher-level plugins van afhankelijk zijn. filesystem De Filesystem plugin beheert de shared disks/ filesystemen en garandeert dat ze na elkaar worden gemount. file De file resource is een voorbeeld die de aanwezigheid van een file bewaakt. sap de sap plugin beheert de SAP R/3 Central Instance.
Recent zijn de volgende plugins beschikbaar gekomen: •
Apache Apache is de meest gebruikte Web Server op het Internet. Deze plugin biedt de mogelijkheid om meerdere servers op de verschillende nodes in het cluster te draaien.
NFS NFS (Network FileSystem) is de meest gemeenschappelijke methode om files uit te wisselen tussen verschillende Unix en Unix-achtige systemen. Deze plugin ondersteund meerdere onafhankelijk export directories en gerelateerde harde schijven. •
Fig. 4
•
•
voorziet het cluster met de lijst van beschikbare nodes, het zogeheten node membership ha_gcd: Group membership daemon.Voorziet in group membership en betrouwbare communicatie wanneer fouten optreden naar de Linux FailSafe processen toe. ha_srmd: System resource manager daemon. Managed resources, re-source groups, en resource types. Deze daemon voert action scripts voor resources uit.
3.3 Linux Failsafe Base De Linux Failsafe Base software bestaat uit de ha_fsd daemon. Deze daemon is de basis component van de Linux FailSafe software. 3.4 Linux FailSafe plugins De onderstaande plugins zijn of door SGI of door derden beschikbaar gesteld: • template Template is een voorbeeld plugin zonder functie. • IP_address The IP_address plugin managed IP addresses als een aliases op de publieke interface(s) van de nodes. Het wordt normaliter gebruikt als een afhankelijke resource, waar de
•
Samba The Samba software suite is een verzameling van programma’s die het SMB protocol voor Unix implementeren. Het wordt ook wel het CIFS of LanManager protocol genoemd. De plugin ondersteund meerdere SMB servers in een mix in het cluster.
4 Linux FailSafe Communicatie Figuur 4 geeft een overzicht van de communicatie paden van alle daemons via de cluster database daemon met de database. Deze database is niet in een leesbaar ascii formaat en bevat de volgende sleutel componenten van Linux FailSafe: • Resources • Resource types • Resource groups • Failover policies • Nodes • Clusters De cluster configuratie database daemon zorgt
ervoor dat een identieke database automatisch wordt gedistribueerd over de verschillende nodes in het cluster. 4.1 Action Scripts Executie Condities Action scripts worden uitgevoerd onder de volgende omstandigheden: • exclusive: De resource group wordt online gebracht door de gebruiker of er wordt een HA proces gestart. • start: de resource group wordt online gebracht, een HA proces is gestart of er is een resource group probleem opgetreden. • stop: de resource group wordt offline gebracht, het HA proces wordt gestopt, de resource group is in een failover, of de node wordt down gebracht. • monitor: de resource group is actief. • restart: Het monitor script heeft een probleem.
Fig. 5
4.2 Wanneer Action & Failover Scripts worden uitgevoerd Hieronder volgt een overzicht wanneer Linux FailSafe action of failover scripts uitvoert: 1. Bij het booten van de node, wanneer FailSafe wordt gestart, leest FailSafe de database de resource group informatie. 2. FailSafe vraagt de System Resource Manager (SRM) om voor iedere resource group die de Online ready status heeft het exclusive script te draaien. 3. SRM rapporteert van elke resource group de status. Die is: running, partially running of not running. 4. Wanneer een resource group een status heeft van not running op een node waar de HA services zijn gestart, dan gebeurt er het volgende: a. Linux FailSafe draait het failover script voor de desbetreffende resource group.
Het failover policy script neemt de lijst met nodes die de resource group kunnen overnemen als een parameter mee. b. Het failover policy script rapporteert een lijst van nodes in aflopende volgorde van belangrijkheid die de resource group kunnen overnemen. c. FailSafe vraagt aan de SRM om de resource group naar de eerste van deze lijst te verplaatsen. d. SRM voert het start script uit voor alle resources in de betrokken resource group: •
•
Wanneer het start script faalt dan wordt de resource group gemarkeerd als online op die node met een srmd executable error. Wanneer het start script goed wordt uitgevoerd dan start SRM automatisch de monitoring voor deze resources. Na de gespecificeerde start monitoring tijd wordt het monitor script uitgevoerd door SRM voor de resources in de resource group.
5. In het geval dat een resource group de status heeft van running of partially running op maar een node in het cluster, runt FailSafe het failover policy script als volgt: •
•
Wanneer de hoogste prioriteit node dezelfde is als de node waarop de resource group draait met de status running, dan wordt deze online gebracht op dezelfde node. In het geval van de status partially running, vraagt FailSafe de SRM om het start script uit te voeren voor de resources in de resource group die nog niet draaien. Als de hoogste prioriteit node een andere node is dan wordt via SRM het stop script gedraaid voor de resources in de resource group endaarna wordt de resource group online gebracht op de node met de hoogste prioriteit.
6. Wanneer de status van een resource group running of partially running is op meerdere nodes in het cluster, dan wordt de resource group gemarkeerd met een exclusivity error. In dit geval moet een systeembeheerder de resource group in het cluster weer online te brengen. Figuur 5 op de vorige bladzijde geeft een overzicht van de communicatiepaden tussen de verschillende action scripts en de failover policy scripts.
5 Cluster Management en Configuratie Er zijn twee methodes om een Linux FailSafe Cluster te configureren en (online) te beheren: • Cluster Manager Graphical User Interface (GUI). Deze biedt een template gebaseerde interface om FailSafe te configureren, te beheren en te monitoren. Er is een help omgeving aanwezig. •
FailSafe Cluster Manager CLI. Deze biedt een command-line interface voor administratieve taken en kan een complete cluster configuratie aanmaken met behulp van een invoer (command) script file.
Beide omgevingen worden in het kort behandeld.
5.1 Cluster Manager GUI De Cluster Manager GUI is een op java gebaseerde grafische interface voor het beheren van het cluster. Hiervoor is de IBM java runtime environment (IBM JRE 1.1.8) nodig. Fig. 6 geeft een overzicht:
Fig. 6
Middels templates kunnen het cluster, nodes, resources ed. worden gedefinieerd en bestaande aangepast, resource groups online of offline worden gebracht ed. Zie onderstaand voorbeeld in figuur 7.
Fig. 7
5.2 Cluster Manager CLI Naast bovenstaande grafische omgeving heeft Linux FailSafe ook de Cluster Manager CLI. Dit biedt systeembeheerders de mogelijkheid om via bijv. een telnet sessie remote een cluster te beheren. Een belangrijk voordeel van Linux FailSafe is het feit dat resources, resource groups ed. online
kunnen worden gemanipuleerd. Het is zelfs mogelijk om een node in het cluster te resetten. Hieronder wordt een voorbeeld gegeven van een cluster manager (cmgr) scriptfile die gebruikt kan worden om een cluster HA_NFS aan te maken:
add dependency /export of type Filesystem add dependency 144.253.210.100 of type IP_address done define resource /reiserfs of resource_type rsync_NFS set export-info to "rw,sync,no_wdelay" set filesystem to /reiserfs add dependency /reiserfs of type rsync add dependency 144.253.210.100 of type IP_address done done
define node linuxfs-1 set hostname to linuxfs-1 set is_failsafe to true set nodeid to 1 set sysctrl_type to vacm set sysctrl_status to disabled set sysctrl_password to none set sysctrl_owner to linuxfs-2 set sysctrl_device to localhost,blum,frub set sysctrl_owner_type to tty add nic 192.168.0.1 set heartbeat to true set ctrl_msgs to true set priority to 1 done add nic 144.253.210.23 set heartbeat to true set ctrl_msgs to false set priority to 2 done done define node linuxfs-2 set hostname to linuxfs-2 set is_failsafe to true set nodeid to 2 set sysctrl_type to vacm set sysctrl_status to disabled set sysctrl_password to none set sysctrl_owner to linuxfs-1 set sysctrl_device to localhost,blum,frub set sysctrl_owner_type to tty add nic 192.168.0.2 set heartbeat to true set ctrl_msgs to true set priority to 1 done add nic 144.253.210.24 set heartbeat to true set ctrl_msgs to false set priority to 2 done done define cluster HA_NFS set is_failsafe to true set notify_cmd to /usr/bin/Mail set notify_addr to root add node linuxfs-1 add node linuxfs-2 done define failover_policy HA_NFS-failover set attribute to Controlled_Failback set script to ordered set domain to "linuxfs-1 linuxfs-2" done set cluster HA_NFS define resource 144.253.210.100 of resource_type IP_address set NetworkMask to 0xffffff80 set interfaces to eth0 set BroadcastAddress to 144.253.210.128 done define resource /export of resource_type Filesystem set Device to /dev/scsi/host2/bus0/target4/lun0/part1 set FSType to reiserfs set force_umount to yes done define resource /reiserfs of resource_type rsync set Device to /dev/scsi/host0/bus0/target2/lun0/part1 set FSType to reiserfs set force_umount to yes done define resource /export of resource_type NFS set export-info to "rw,sync,no_wdelay" set filesystem to /export
define resource_group HA_NFS-rg cluster HA_NFS set failover_policy to HA_NFS-failover add resource 144.253.210.100 of resource_type IP_address add resource /export of resource_type Filesystem add resource /export of resource_type NFS add resource /reiserfs of resource_type rsync add resource /reiserfs of resource_type rsync_NFS Done
Uiteraard kan cmgr ook interactief gebruikt worden. Bijv. een ‘show node’ commando op node cm1a zal het volgende te zien kunnen geven: cmgr> show node cm1 Logical Node Name: cm1 Hostname: cm1 Nodeid: 1 Reset type: reset System Controller: msc System Controller status: enabled System Controller owner: cm2 System Controller owner device: /dev/ttyd2 System Controller owner type: tty ControlNet Ipaddr: cm1 ControlNet HB: true ControlNet Control: true ControlNet Priority: 0
Het voorgaande voorbeeld maakt gebruik van ReiserFS. Dit is een journalling filesysteem. Een journalling filesysteem is een belangrijke voorwaarde voor een High-Availability opstelling. Een klassiek Berkeley-achtig filesysteem kan een veel te lange filesystem check opleveren wanneer het dirty is en gemount moet worden. Dit brengt ons bij de vraag:
6 Is Linux FailSafe ready for prime-time?! Vergeleken met andere besturingssystemen is Linux stabiel en betrouwbaar gebleken. Is er dan de noodzaak om dit uit te breiden naar een complexere availabilty cluster opstelling? In een aantal gevallen zeker niet. Een belangrijk voordeel van een cluster opstelling is wel dat er ‘back-up’ hardware in de opstelling meegenomen is. Dit biedt de mogelijkheid, om in geval van het echt stuk gaan van een bedrijfskritisch onderdeel, de ingebouwde beschikbaarheid te benutten en bijvoorbeeld de webserver, fileserver of oracle database beschikbaar te houden. Het gaat tenslotte om de beschikbaarheid van de data!
6.1 FailSafe Opstelling Belangrijk voor een High-Availability opstelling zijn vooral de onderdelen die te maken hebben met de (externe, gedeelde) storage zoals de beschikbare volume managers, filesystemen en plugins voor de te gebruiken applicaties zoals fileserving (NFS), webserving (Apache) ed.. De hierna beschreven ervaring is met een Linux FailSafe NFS opstelling opgedaan: 6.2 Externe Storage De standaard Linux drivers voor differential SCSI adapters geven problemen wanneer er meerdere initiators op dezelfde bus actief zijn, zoals bij multi-hosting SCSI het geval is. Dit maakt het noodzakelijk, in een opstelling met externe storage, Fibre Channel SCSI te gebruiken. Hierdoor wordt een Linux FailSafe opstelling met externe storage kostbaarder. 6.3 Volume Manager lvm Hier komt nog bij dat lvm geen mirrorring functie heeft. Bij testen is gebleken dat lvm in combinatie met software mirrorring (raid 0+1) niet goed werkte. Dit maakt dat voor de externe storage alleen hardware Raid 5 (of Raid 0+1) voldoen. 6.4 Journalling Filesysteem Als journalling filesystemen zijn onder andere ReiserFS en XFS (kernel 2.4) beschikbaar. Omdat in de opstelling gekozen was voor de Linux kernel versie 2.2.16, was ReiserFS de enige huidige oplossing. Ook ReiserFS werkt niet in combinatie met software Raid 0+1. Daarnaast moesten ook de tools, zoals mkfs ed. worden gecompileerd. 6.5 Low Cost Mirrorring Om toch een low-cost mirrorring te kunnen bieden met de NFS opstelling is gekozen voor de rsink utility. Hiermee is het mogelijk om bijv. eens per uur een incrementele update van de mirror te doen over het netwerk. Omdat het ging om een NFS server met bijna statische data, vormde dit geen probleem. In deze opstelling verviel dan ook de externe storage. De rsink mirrorring is meegenomen in de failover door er een eigen resource type van te maken. Op deze manier tript de rsink mirrorring functionali-
teit mee tijdens een failover. Het bovenstaande is een belangrijk voordeel van Linux FailSafe: het is uitbreidbaar en men kan er een oplossing op maat mee bouwen. Uiteraard is een opstelling met externe storage, gecombineerd met Raid5, veruit te prefereren, en behoort een standaard onderdeel te zijn in het budget. 6.6 Linux FailSafe NFS Onder Linux zijn zowel NFS v2 als NFS v3 beschikbaar. Voor NFS v3 gelden er echter enkele beperkingen: • NFS v3 werkt alleen over udp • NFS v3 ondersteunt nog geen async Ook is de Linux FailSafe NFS Plugin niet voorzien van locking die gedaan kan worden in een directory op de externe storage. Dit gaf in de praktijk echter weinig problemen tot op heden. Linux FailSafe: Ready for prime-time! Al met al is het een waardige FailSafe opstelling geworden en is Linux FailSafe zeker geschikt gebleken om er een High-Available opstelling mee te bouwen. Referenties: http://www.suse.com/ http://linux-ha.org/ http://www.sistina.com/lvm/ http://www.namesys.com/ http://sourceforge.net/projects/vacm/ http://oss.sgi.com/projects/failsafe/ http://oss.sgi.com/projects/xfs/
