Onderschat uw bestaande activa niet, herwaardeer ze!

“Door de technologie te herzien, kan je andere kostenmodellen overwegen en dus meer doen met minder middelen!”

Olivier Lambert, Technical Director, All4It

De prijsstijging van opslag- en rekenbronnen is onmiskenbaar. Voor zijn klanten, waaronder talrijke grote distributiebedrijven, schat All4It de inflatie op 15 à 30% per jaar. Als de infrastructuur omwille van de hoge beschikbaarheid wordt ontdubbeld, valt dat duur uit. Vooral wanneer de back-upinfrastructuur “latent” is. Er kan natuurlijk nog in fail-softmodus worden gewerkt. Lange tijd stelden de constructeurs die oplossing voor om de kosten te beperken. Maar door het toenemende aantal kritieke toepassingen blijkt ze steeds delicater te zijn.

“Hoed u voor die al te theoretische benaderingen, waarschuwt Olivier Lambert. Als u onderhevig bent aan criteria zoals seizoensgebonden factoren, wat meestal het geval is in de distributiesector, of aan het weer, ervaart u voortdurend activiteitspieken die zo precies mogelijk moeten worden beheerd. In die omstandigheden kan de beschikbaarheid van een tweede infrastructuur moeilijk verzekerd worden …”

Al is “cluster failover” ongetwijfeld de verst gevorderde oplossing om een service over te nemen, toch bieden de moderne software-infrastructuren voortaan ingebouwde functionaliteiten die instaan voor fouttolerantie. In die context is het DBMS zonder twijfel een van de laatste “singleton”-diensten -de SPOF (Single Point of Failure) draait immers vaak slechts op één machine tegelijk. Bovendien is deze dienst het moeilijkst te beveiligen met een “cluster failover” doordat zijn onderliggende systemen afhankelijk zijn van het netwerk, de systemen en de bestanden. Om een DBMS te switchen -als gevolg van het stilleggen en volledig herstarten van de systemen nadat de bronnen opnieuw zijn toegewezen, wat tijd kan vergen-, moet men zich er zeker van zijn dat de schijven overgezet worden naar de machine waarop de service wordt voortgezet.

“Op dit punt zorgt een systeem als RAC voor het hele verschil. Het is het DBMS dat geclusterd is; er is geen externe software nodig om toe te zien op de database. En doordat deze laatste gelijktijdig door meerdere machines wordt beheerd, is er geen failover. Als één machine uitvalt, blijft de andere de dienst verzekeren. Dat is een groot voordeel! Vermits er geen failover is, bestaat de mogelijkheid om het systeem te laten evolueren zonder het periodiek te testen, dus zonder de werking van het systeem te beïnvloeden. Bovendien gebeurt de bediening door de beheerder van het DBMS. Doordat de omgeving vereenvoudigd is, bespaart u op de bronnen om het te managen.”

Dit alles levert besparingen op die in de huidige context welkom zijn. Bij All4It kadert dit aanbod rond RAC, dat meer bepaald beschikbaar is in SAP- en Linux-omgevingen, in de ROPI (Return On Past Investment) formule. Concreet gezien gaat het om de optimalisatie van wat reeds operationeel is. “Wat de oorzaken van de huidige crisis ook zijn, de effecten ervan zijn onafwendbaar, zegt stichter en CEO Xavier Ghyssens van All4It. Wat echter moet worden vermeden, is een afwachtende houding. Om die reden streven we in ons partnerschap met Oracle twee welbepaalde doelstellingen na: de bestaande investeringen beter benutten en ons op een dynamische manier focussen op de strategische oplossingen voor de kernactiviteit van onze klanten.”

De ene infrastructuur is natuurlijk de andere niet. Men begint bij het kwalificeren en kwantificeren van wat bestaat, het meten van de gevolgen van een onderbreking, het evalueren van de beveiligingen die bestaan en degene die nodig zouden zijn. Het kostenaspect is uiteraard belangrijk, net als een duidelijke afbakening, in samenspraak met de betrokken bedrijfstakken, van de verwachte serviceniveaus. Daaruit zullen prioriteiten voortvloeien. In elk geval is het absoluut noodzakelijk om te zorgen voor indicatoren waarmee men de vorderingen kan meten, de return on investment kan vaststellen om te kiezen voor een terugkerende aanpak waardoor het vertrouwen in de systemen toelaat om de mogelijkheid van nieuwe diensten te onderzoeken en dus op zoek te gaan naar nieuwe stabiele situaties.

All4It, dat voortbouwt op zijn Oracle RAC-ervaring, steunt zijn strategie op het uitbouwen van een “actief/actief”-cluster (zie kaderstuk). Dat betekent dat het herstel bij het uitvallen van een clusterknooppunt gebeurt door de automatische overheveling van de sessie naar een ander knooppunt in het netwerk en een snellere hersteltijd oplevert. Op het eerste gezicht lijkt het verstandiger om de beschikbare servers in “actief/actief”-modus te gebruiken dan zich te beperken tot een deel van de beschikbare bronnen.

Echt nieuw is dat niet. Reeds jarenlang biedt de Oracle RAC-technologie talrijke systemen, waaronder ook SAP, hoge beschikbaarheid, het vermogen om de capaciteit van meerdere machines te verhogen en de beschikbare middelen beter te benutten. Meer specifiek vergemakkelijkt RAC het beheer van de systemen: het is niet langer nodig om failovers van de vergrendeling van bays, bestandssystemen, databases enz. te beheren. Olivier Lambert: “We herzien ons aanbod om het maximaal te benutten. Dankzij de technologie kunnen andere kostenmodellen worden overwogen: u kunt een systeem uitbouwen op basis van standaard hardwarecomponenten; u kunt het aantal softwareprogramma’s in het ecosysteem beperken -met de Oracle-clusterware kunnen bijvoorbeeld externe toepassingen worden beveiligd. De Oracle-beheerder kan alleen instaan voor de ondersteuning en productie van een complete set functies waar doorgaans diverse specialisten aan te pas komen. Door het aantal betrokkenen en dus interacties en beperkingen te verminderen, verbetert u bovendien de servicekwaliteit.”

Om de ROI op de doorgevoerde investeringen te verhogen en te versnellen, stellen All4It en Oracle het volgende voor:

- een globale aanpak die nauw aansluit bij de kernactiviteiten, van structuurschema tot integrale exploitatie;
- een grondige analyse van de levenscyclus van de bestaande beheeroplossingen;
- de migratie van de bestaande systemen (met name ERP) naar omgevingen voor hoge beschikbaarheid onder Oracle RAC om beter aan de strategische eisen te voldoen;
- het doorvoeren van nieuwigheden die een meerwaarde bieden ten aanzien van de strategische evoluties van de klanten (virtualisatie, hoge beschikbaarheid, veiligheid, enz.)

Met Oracle RAC kunnen meerdere servers van één cluster op volledig transparante wijze worden gebruikt. Een RAC-base is een uniek beeld (single image). Door de mogelijkheid te bieden om extra knooppunten in een cluster te voorzien, maakt Oracle RAC het mogelijk om de capaciteit horizontaal uit te breiden, zonder de dienst te onderbreken. Daardoor hoeft men zich niet te beperken tot één enkele server waarbij de capaciteitsverhoging vaak begrensd wordt door het aantal CPU’s, de capaciteit van het OS en de kostprijs van de server.

Dankzij Oracle RAC kan dus de capaciteit van een high-end server worden geboden door gebruik te maken van instapservers! Bovendien biedt dit systeem een grotere beschikbaarheid dan één enkele server. Zo kan een organisatie ervoor opteren om een uitgebreid gegevensbestand met 4 servers van elk 8 CPU’s te beheren in plaats van een server van 32 CPU’s aan te kopen. In feite zullen de 4 “commodity”-servers goedkoper zijn dan één enkele server van 32 CPU’s. Verder heeft de cluster van 4 servers geen SPOF en is hij daardoor veel meer beschikbaar dan één enkele server van 32 CPU’s. Een andere troef van de RAC is de mogelijkheid om te beginnen met een cluster van 2 knooppunten en daarna extra knooppunten toe te voegen in functie van de toekomstige behoefte aan capaciteitsverhoging.

Bij een RAC wordt het gegevensbestand en de bijhorende toepassingen niet onderbroken bij een storing. De capaciteitsverhoging van een RAC-base is lineair. Het toevoegen van een nieuw knooppunt in een RAC-cluster onderbreekt de activiteit van de database niet. De servicekwaliteit blijft dus constant door de tijd heen.

Het principe van de clusters is een oplossing die perfect is aangepast aan een omgeving voor hoge beschikbaarheid door een uniek storingsrisicopunt te voorkomen. In een hoge beschikbaarheidscluster stelt een server, die “actief” wordt genoemd, de “beschermde” dienst ter beschikking. Wanneer die server om een of andere reden onbeschikbaar wordt, neemt een andere server, die “passief” wordt genoemd, de activiteit over. Hij heeft toegang tot dezelfde gegevens als de “master” server, hetzij door datareplicatie, hetzij via een gedeelde SAN-bay, waardoor hij dezelfde dienst als de vorige server kan waarborgen. Deze configuratie noemt men “actief/passief”.

Deze logica kan worden toegepast in een “actief/actief”-omgeving: standaard deelt elke server de “database”-resource. De load balancing kan automatisch en dynamisch worden beheerd. Meer geavanceerde configuraties zijn mogelijk: de ene server kan master zijn voor één bron, terwijl de andere dat voor een andere bron is. Mocht een van beide uitvallen, dan neemt de tweede server beide activiteiten voor zijn rekening.