Unixware Nonstop, meer dan een simpel cluster! Cor Hilbrink, Hilbrink IT Solutions/2Complex
Inleiding Unixware Nonstop Clusters (NSC) staat voor een gedistribueerd Unix systeem opgebouwd uit een aantal onafhankelijke PC systemen welke met elkaar verbonden zijn via een System Area Network (SAN). Ieder systeem (ook wel node genoemd) draait een eigen Unixware kernel, alle systemen tezamen presenteren zich in een Single System Image (SSI) aan de gebruikers. We kunnen ook wel zeggen dat NSC een virtueel Unixware systeem vormt voor de gebruiker en/of applicaties, de fysieke opbouw van het cluster wordt verborgen gehouden zonder concessies te doen aan het standaard Unix model. Bij uitval van een node of ander component kan de virtuele machine tijdelijk een resource verliezen. In geval van een Single Point Of Failure (SPOF) zal de resource via een andere weg zo snel mogelijk weer beschikbaar worden gesteld en is het SSI weer hersteld. Net als in de andere Unix omgevingen zijn er op het SCO platform ook ontwikkelingen geweest. In het algemeen kunnen we zeggen dat alle cluster addons voor zowel OpenServer als Unixware geënt waren op het zg. Failover principe. Het “Single Point Of Failure” wordt in al deze producten opgevangen door minimaal twee of meerdere gelijkwaardige machines op te bouwen en in geval van een calamiteit processen of procesgroepen te laten herstarten op een andere server binnen het cluster. In dit paper wordt het SCO NSC product (NSC) afgezet tegen de reeds bestaande clustering producten. Er zullen aan de hand van enkele praktijksituaties voorbeelden worden gegeven waar NSC een grote stap vooruit kan zijn. Wanneer er ondeskundig met de materie wordt omgesprongen kunnen deze situaties eenvoudig in een negatief scenario worden omgezet.
Historie NSC is beschikbaar op het Unixware 7 platform en is afkomstig uit de keuken van het huidige Compaq. De ontwikkeling van NSC is zo’n 11 jaar terug gestart bij Locus. In 1994 is Tandem deel gaan nemen aan de ontwikkelingen naast Locus. Tandem is verantwoordelijk voor de port naar SVr4. Het product dat door Tandem “NonStop/UX” is gedoopt, is in 1997 geporteerd naar Unixware 2. Deze versie is eigenlijk alleen door Tandem, later Compaq in de telecom markt ingezet. De versie die zowel door SCO als door Compaq op dit moment wordt ondersteund is gebaseerd op Unixware 7.1.1. Aan het huidige product wordt nog steeds gebouwd door de ontwikkelaars van het eerste uur. Ook in de sourcetree zijn nog historische namen terug te vinden die al binnen Tandem werden gehanteerd.
Waarom een cluster ? In de laatste jaren zijn Unix machines steeds zwaarder en kostbaarder geworden. Applicaties eisen meer kracht, hardwareontwikkelingen gaan gestaag door, er wordt meer van de servers gevraagd. De betekenis van een Unix server voor een organisatie wordt pas duidelijk wanneer bijvoorbeeld een disk of een willekeurig andere component uitvalt. Beveiliging tegen spanning uitval is al lang niet meer voldoende en bij uitval van een server dient binnen zeer korte tijd (minuten/seconden) de productie te worden herstart. Andere, in de praktijk genoemde redenen zijn vaak bottlenecks die men wil vermijden, niet in de laatste plaats het opvoeren van performance. De doelstelling achter het inzetten van een cluster is een hogere graad van beschikbaarheid. Extra performance is, indien bereikt met een cluster, een prettige bijkomstigheid maar hoort niet het hoofddoel te zijn.
Uitgangspunten De meeste hoge beschikbaarheids systemen gebruiken het failover principe: faalt een (deel)systeem, dan neemt een ander systeem de taken over. Uitgangspunt van een cluster is dat de eerste calamiteit die met uitval van component(en) gepaard gaat zelfstandig kan worden overleefd. Mocht zich hierna nog een probleem voordoen zonder dat het initiële probleem verholpen is, bestaat er geen garantie dat het cluster deze uitval ook kan opvangen. Dit is afhankelijk in welke subsystemen beide problemen zich voordoen. In het gunstigste geval doet de calamiteit zich voor in een ander subsysteem waardoor het cluster nog steeds “up” is. Het blijft dus noodzaak een cluster te monitoren en in geval van problemen deze zo snel mogelijk weer te repareren. Het bovenstaande betekent dat in een cluster geen Single Point Of Failure (SPOF) mag zitten. Elke functie van elke component moet kunnen worden overgenomen door een andere component. Hoe een dergelijke overname geschiedt is configureerbaar.
Wat is NSC en waar onderscheidt ‘t zich Het NSC cluster concept gaat veel verder dan alleen het failover principe. NSC vormt uit meerdere fysieke servers één virtuele Unix machine met al de daarbij behorende facetten. Deze virtuele machine kan op basis van minimaal 2 tot mogelijk maximaal zo’n 30 fysieke servers worden opgebouwd. Iedere machine binnen het cluster heet een node. Een node kan één of meerdere processoren bevatten, waardoor er met de op dit moment beschikbare servers een veel zwaardere virtuele machine kan worden gebouwd. Iedere node kan additioneel processoren, geheugen, diskruimte en netwerkkaarten aan de virtuele machine toevoegen. Alle nodes worden onderling met elkaar verbonden d.m.v. een zogenaamd “Interconnect” netwerk. De door Tandem ontwikkelde Servernet-I technologie is jarenlang als interconnect gebruikt. De beschikbare bandbreedte is 50 MB/sec. Inmiddels is het ook mogelijk om de interconnect op basis van TCP/IP te bouwen. Dit laatste zou bij voorkeur op basis van Gigabit Ethernet kaarten moeten worden opgezet. Vanaf release 7.1.1b+IP worden enkele van deze type kaarten ondersteund.
Het virtuele Unixware systeem Na installatie en configuratie van SCO NSC ontstaat er een virtueel systeem dat zich naar de gebruiker presenteert als één logische Unix server. Er wordt een “Single System Image” gecreëerd, hetgeen betekent dat er op tal van punten wordt ingegrepen: Single namespace Alle beschikbare storage is op alle nodes beschikbaar op dezelfde plaats. Er is maar één root filesysteem, dus ook maar één /dev directory, één /etc/passwd etc. Virtuele procestabel Alle processen die draaien binnen het cluster worden getoond bij een “ps –ef” commando. Er is maar één init proces, één cron en één lpsched proces clusterwide!!! Processen kunnen een nieuw proces starten op een andere node. Processen kunnen worden gemigreerd naar een andere node zonder opnieuw te worden opgestart. Het Process ID (PID) blijft hetzelfde. Clusterized Inter Proces Communication (IPC)subsystem Op een normal Unixsysteem kunnen processen onderling communiceren d.m.v. IPC’s. Binnen het Unixware NSC cluster is dit ook mogelijk tussen processen die op verschillende nodes draaien. Er dient wel gemeld te worden dat dit bij intensief gebruik de snelheid niet ten goede komt.
Load balancing Op basis van CPU-belasting kan er een dynamische verdeling worden toegepast van processen. Er kunnen nodes worden gegroepeerd en over zo’n groep kan dan de belasting evenredig worden verdeeld. Dit vergt een gedegen kennis van de applicatie(s) die hierin moeten functioneren. Virtuele swapspace en geheugen Alle swap slices zijn clusterwide beschikbaar. Is node1 door z’n swapruimte heen dan kan node1 een beroep doen op de swapspace van node2. Single network stack (TCP/IP) Iedere node kan één of meerdere netwerkinterfaces (NIC) bezitten die ieder op zijn beurt weer deel kunnen uitmaken van een segment in het netwerk. Niet iedere node hoeft een NIC te hebben. Alle netwerkinterfaces zijn clusterwide beschikbaar, ieder node heeft dus een eigen route-tabel. Wel dienen we per segment minimaal twee NIC’s beschikbaar te hebben om het SPOF probleem voor te blijven. Per aangesloten netwerk kan het cluster een additionele interface benoemen tot een maximum van 16 interfaces. Deze additionele NIC wordt als Cluster Virtual IP interface geconfigureerd. Deze interface vertegenwoordigd de virtuele machine op het betreffende segment en wordt bij uitval overgeheveld naar een andere nog wel in dat segment beschikbare node. Een CVIP interface kan als een normale interface worden behandeld en dus ook worden voorzien van aliases e.d. Op netwerkniveau is het mogelijk (geconditioneerd) meerdere processen te draaien die op dezelfde TCP of UDP poort luisteren. Dit is mogelijk doordat er op kernel-level een extra laag is ingebracht (Nerdlayer). Deze Nerd-layer checkt onder andere alle open sockets. Voor uitgaande IP pakketten altijd de kortste weg naar het netwerk gekozen. De inkomende netwerkpakketten kunnen dus via een andere NIC binnenkomen dan dat de uitgaande pakketten worden verstuurd. Normale beheer omgeving In NSC zijn er exact dezelfde beheer tools beschikbaar als op de standaard Unixware omgeving. Enkele tools zijn “clusterised” maar om standaard beheer uit te kunnen voeren is geen additionele scholing noodzakelijk. Voorbeeld: het aanmaken van een gebruiker of printer behoeft maar één maal te gebeuren. In vele andere clustervarianten is dit een aktie die op alle nodes opnieuw uit dient te worden gevoerd. Voorbeeld: Het down brengen van het cluster in z’n geheel kan door exact hetzelfde commando worden uitgevoerd, nl. “shutdown”. Voor additionele beheerzaken zijn er nieuwe tools en menu’s toegevoegd aan de administratie tool “scoadmin”. Geen noodzaak tot Applicatie veranderingen Niet in de laatste plaats is het belangrijk te melden dat er geen wijzigingen in de applicatie behoeven worden doorgevoerd om optimaal gebruik te kunnen maken van het cluster.
Voorbeeld: Een applicatie die luistert op een tcp-socket kan eenvoudig worden overgezet naar een Unixware NSC cluster. Als de Nerd-layer wordt gemeld dat er op een bepaalde TCP/UDP poort meerdere processen kunnen luis teren dan is het mogelijk op iedere node één zo’n proces te starten. De Nerd-layer zal de binnenkomende verbindingen verdelen over de beschikbare listener processen.
Hoe zijn nu de failures afgevangen? Zoals hierboven omschreven heeft NSC behoorlijk veel faciliteiten voor z’n gebruikers. Processen on the fly migreren naar een andere node, IPC’s Clusterwide maar ook loadleveling zijn geavanceerde eigenschappen. Hoe wordt een uitvallende schijf of een node crash op gevangen? Filesystemen Om het uitvallen van een disk op te kunnen vangen dient er dus een exacte kopie van deze disk binnen het cluster beschikbaar te zijn. Binnen NSC zijn een tweetal diskconfiguratie mogelijkheden, nl. “Cross Node Mirror” (CNM) en “Shared Storage”. CNM: NSC maakt gebruik van de Veritas Volume Manager, die tussen twee nodes een mirror van de interne disk(s) tot stand kan brengen. Valt één de twee nodes uit dan wordt dit op Veritas niveau opgemerkt en gaan beide nodes verder met de overgebleven kopie. Bij terugkomst van de uitgevallen disk wordt een complete rebuild van de disk uitgevoerd. Dit is een tijdrovend proces. De interconnect is het kanaal waarover de mirror wordt opgebouwd en in tact wordt gehouden. Algemeen wordt gesproken van een haalbaarheid van CNM bij een maximale mirror van 20 GB. Shared storage: Een sneller en duurder alternatief voor CNM. Basis zijn diskcabinets met daarin een dubbele RAID controller. In de cabinets wordt de data beschermd doordat de disks in RAID-1 of RAID10 zijn geconfigureerd. De diskcabinets zijn vanaf twee machines toegankelijk en dus clusterwide beschikbaar. In een eenvoudige configuratiefile is aan te geven welke nodes de filesystemen kunnen mounten en aan het cluster beschikbaar kunnen stellen. In dezelfde file is aangeven welke node de primaire node en welke node de fallback node betreft. Processen en/of primaire taken Tijdens het starten van het cluster worden de systeemtaken één voor één opgestart. Net als bij een normaal Unixware systeem vindt dit ook plaats vanuit de welbekende /etc/rc2.d en aanverwante directories. Er is een belangrijk verschil: de scripts registreren de op te starten taak bij de “Keepalive” daemon. Keepalive (en niet init) zal het daadwerkelijk te starten proces starten en blijvend monitoren of het proces draaien. Er kan zowel een enkelvoudig proces als wel een groep van processen worden gestart via Keepalive. “Spawndaemon” is het commando waarmee processen kunnen worden geregistreerd, maar ook kunnen worden ontrokken aan de aandacht van Keepalive. Bij het simpelweg afschieten van processen m.b.v. kill zal keepalive anders direct een nieuwe daemon starten! Naast het starten van gebruikersprocessen is er de “CLuster Membership Service” (CLMS). Deze service houdt het al dan niet up zijn van nodes in de gaten. Iedere node moet geregistreerd staan bij de CLMS.
Enkele ervaringen uit de praktijk Inmiddels heb ik zelf zo’n drie jaar ervaring mogen opdoen met NSC. Ik heb met name in voor trajecten: het opbouwen van de testcluster ter acceptatie, maar ook met echte implementaties aktief bij kunnen dragen aan oplossingen. Het is me opgevallen dat klanten vaak een vertekend of zelfs verkeerd beeld hebben van een cluster. Door vooraf duidelijk de uitgangspunten en doelen te definiëren is het bouwen van een cluster beter uitvoerbaar. Hieronder een kleine greep van projecten waar clustering op een niet alledaagse wijze werd ingezet.
Klant heeft populaire netwerkservice, hoe schalen ze op? Een bank had een telebanking applicatie in gebruik genomen op basis van een SCO Unixware7 server. In de eerste maanden na ingebruikname van de applicatie waren er slechts enkele gebruikers actief. Na verloop van tijd begon het usertal exponentieel te groeien. De groei was zelf zodanig dat kon worden uitgerekend wanneer de machine het maximum aantal connecties zou bereiken. Mogelijke oplossing was implementatie van een (identieke) tweede server ernaast. Nadeel: data niet meer in sync, twee adressen voor zelfde dienst. Zonder herschrijven van de applicatie software was dit niet uitvoerbaar. Door een NSC cluster in te zetten en daarop de Nerd-layer juist te configureren (meerdere listeners op een TCP poort) kon de applicatie via het CVIP worden verdeeld. De oplossing bood de gewenste schaalbaarheid voor de klant naast een hogere beschikbaarheid. De mogelijkheid om later meer nodes toe te kunnen voegen bood voor de klant tevens het gewenste groeipad.
Klant heeft database plus gebruikers die op zelfde systeem inloggen Een klant heeft op basis van een Progress database een server draaien met zo’n 30-tal gebruikers. De eerste gebruiker die op het systeem inlogt start ook meteen de database. Klant heeft een draaiend CNM cluster met zo’n 30 GB aan diskruimte. Voor zowel klant als database leverancier waren hier wel eens tekenen van tegenvallende performance maar daar bleef het bij in de testfase. Na enige uitleg over de Nerd-layer bleek een kleine inschattingsfout boven te komen drijven. Een gebruiker die met een telnet een NSC cluster betreedt kan niet zeker weten op welke node hij terecht komt. Telnet wordt via de Nerd-layer gedistribueerd over de beschikbare nodes. Dit geheel kan tot gevolg hebben dat de eerste gebruiker binnenkomt op node2 en dus ook daar de database processen start, terwijl de filesystemen met de databasefiles onder beheer zijn van node1. Daarnaast communiceerden het client deel van de applicatie met de database server via shared memory. Het Cluster is opnieuw opgebouwd in een “External Storage” configuratie. De scripts zijn aangepast en de applicatie geconfigureerd zodat deze communiceert over beter schaalbare TCP/IP connecties. Het Cluster is nu bruikbaar. Klant is op zoek naar (betaalbaar) hoog beschikbaar XDM loginserver Bijna alle clusters zijn storage gericht. De data dient hoog beschikbaar te zijn en meestal draait er een RDBMS. In dit geval betrof het een grote klant waar een vier node cluster moest worden gebouwd zonder relevante storage. Enige gevraagde functie is Xdm loginserver. Dit is nu typisch een omgeving waar niet direct aan een cluster wordt gedacht. Er is hier totaal geen sprake van diskruimte die hoog beschikbaar moet zijn. Een “dikke” SMP machine zou de klus aan moeten kunnen. Toch moest het te bouwen cluster een oud HP cluster vervangen (functioneel was de oplossing dus al eens gebouwd). Een enkelvoudige loginserver zou in geval van storing ongeveer 300 mensen van hun werk
houden. Alle nodes zijn uitgerust met een gemirrorde 9 Gb boot/rootdisk. Alle benodigde dataruimte (home directories) is gelegen op een Netapp740, een snelle NFSserver. Er is dus totaal geen sprake van “protected storage”. De crux van dit cluster ligt puur op processor power en beschikbaarheid. De pre van de NSC oplossing t..o.v het oude HP cluster was het gebruik maken van het Single System Image. Dit leverde voor de systeembeheerders een aanzienlijke tijdwinst en een eenvoudiger cluster op.
Conclusie Unixware NSC verbergt de gedistribueerde eigenschappen van onderliggende hardware door een SSI te implementeren. Applicaties kunnen zonder te worden gemodificeerd (clusterized) worden overgezet naar Unixware NSC. Voor gebruikers doet een cluster zich voor als één grote virtuele machine.
Samenvatting In het bovenstaande is geprobeerd in vogelvlucht de specifieke kenmerken van het NSC cluster te omschrijven. In de praktijk zien we dat clusters failover bieden, NSC gaat echter een ruime stap verder. Het product is, mits deskundig behandeld, breed inzetbaar en betekent daardoor voor mij een spannende stap vooruit. Gelet op het tijdstip van publicatie zal hopelijk het sed 1,$ ‘s/SCO/Caldera/g’ een positieve aanvulling op dit stuk zijn.
Verwijzingen Er zijn over dit onderwerp diverse bronnen aanwezig op het Internet. Compaq:
http://www.compaq.com/solutions/enterprise/highavailability/sco/cpqnsc-pd.html
SCO/Caldera:
http://www.sco.com/partners/nsc
Fujitsu-Siemens: http://www.fujitsu-siemens.de Tevens zijn er vanuit SCO, Compaq en 2Complex workshops en trainingen voorhanden.
