Bij Server Based Computing (SBC) worden werkplekapplicaties

Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen

5.8

Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen

359

ij Server Based Computing (SBC) worden werkplekapplicaties aangeboden vanaf een serverplatform. Bedrijven migreren naar een SBC-omgeving omdat dit onder andere voordelen biedt voor het beheer van werkplekapplicaties. Deze SBComgeving vraagt een andere manier van beheer dan de conventionele client/server (C/S) omgeving. Voor het beheer van de omgeving en de applicatiedistributie kan gebruik worden gemaakt van het Ontwikkel, Test, Acceptatie, Productie (OTAP) proces. De relatie tussen OTAP, ITIL en MOF wordt kort weergegeven. Dit artikel beschrijft of de verwachtingen, die voor de SBC-migratie zijn gewekt, in de praktijk zijn waargemaakt. Het artikel sluit af met een beschrijving van de best practice van het OTAP-proces in een SBC-infrastructuur.

B

Auteur: Jeroen A. Kruithof, BT

DE AANLEIDING VOOR HET ONDERZOEK Het OTAP-proces is een formeel proces, dat bijdraagt aan de beschikbaarheid en beheerbaarheid van applicaties. Het middenen kleinbedrijf heeft een kleine ICT-staf, die is belast met zeer diverse taken. Voor het werken volgens formele procedures is die omgeving te hectisch, een formeel proces staat dan op gespannen voet met de praktijk. Doel van het onderzoek is, om vast te stellen hoe in de praktijk wordt omgegaan met het OTAP-proces, en welke aanbevelingen kunnen worden gedaan om ook bij het middenen kleinbedrijf het OTAP-proces voor een SBC-omgeving te implementeren. Aanpak en indeling In het onderzoek worden bedrijven een jaar nadat de migratie is uitgevoerd benaderd, en wordt de huidige werkwijze geëvalueerd. Een SBC-omgeving vereist een formele manier van werken. Onderzocht is hoe de beheerders zich deze nieuwe manier van werken eigen hebben gemaakt. Tien bedrijven werden benaderd. Er werd ingegaan op de manier waarop het OTAP-concept is geïm-

plementeerd en op de vraag welke elementen hiervan in de praktijk worden gebruikt. Is het überhaupt mogelijk om slechts een deel te doen en hoe wordt bijvoorbeeld een functiescheiding gerealiseerd als er maar één beheerder verantwoordelijk is voor de applicaties? Hoe worden kleine en grote veranderingen op de omgeving doorgevoerd als de druk tot implementeren vanuit de organisatie toeneemt?

5

In dit artikel worden eerst het conventionele C/S en SBC tegenover elkaar gezet en hierna wordt specifiek ingegaan op het OTAPproces. Vervolgens worden de resultaten van het onderzoek gepresenteerd. In het laatste deel worden de gegevens geanalyseerd en voorzien van de best practice voor het toepassen van OTAP in een kleine tot middelgrote SBC-omgeving.

SERVER BASED COMPUTING TEGENOVER CONVENTIONEEL CLIENT/SERVER Na een introductie van het SBC-concept volgt een toelichting op de verschillen in de wijze waarop applicaties op een SBC- en

IT Service Management, best practices Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

C/S-omgeving worden aangeboden. Dit hoofdstuk eindigt met het aanduiden van het belang van het zogenaamde OTAP-proces voor het beheer van applicaties. 360

Introductie van het SBC-concept SBC is een architectuur waarbij een applicatie voor 100% op een applicatieserver draait, en waarbij de user interface van de applicatie wordt weergegeven en bediend met behulp van een werkplek. Tussen de applicatieserver en de werkplek worden alleen de veranderingen van het scherm en de toetsenbord- en muisactiviteiten uitgewisseld. De minimaal vereiste bandbreedte per gebruiker is ongeveer 20 kilobit per seconde, waardoor deze architectuur bijzonder geschikt is in omgevingen met een beperkte bandbreedte tussen de centrale servers en de werkplek.

Figuur 1 SBC-concept

De architectuur wordt gebruikt voor het doorvoeren van servercentralisatie en -standaardisatie en voor het vereenvoudigen van de werkplekken.

Alle backoffice- en applicatieservers worden centraal opgesteld waardoor het beheer wordt vereenvoudigd en de kosten worden gereduceerd. Ook applicaties met een zware netwerkbelasting presteren goed omdat er tussen de applicatieserver en de backofficeserver gebruik wordt gemaakt van snelle netwerkkoppelingen. De architectuur is vrijwel werkplekonafhankelijk waardoor de werkplek kan bestaan uit een grote verscheidenheid aan apparaten, variërend van een standaard-pc of een thin client tot een PDA of een smart phone. In tegenstelling tot de C/S-architectuur worden er bij SBC op de werkplek van de gebruiker geen applicaties geïnstalleerd en bevinden zich geen persoonlijke- of bedrijfsgegevens op de werkplek. Alle bedrijfsgegevens bevinden zich op de centrale serverlocatie en worden niet uitgewisseld met de werkplek. Deze architectuur maakt het mogelijk om gangbare C/S-applicaties zoals DOS, 16 biten 32 bit Windows applicaties, aan te bieden over een beperkte netwerkcapaciteit en kan worden gebruikt als een overgangsfase naar een toekomstige 100% web-enabled omgeving. De applicatieserver is gebaseed op een multi-user Windows operating system, waarop 60 tot 100 werkplekken per applicatieser-

Figuur 2 Voorbeeld van eenvoudige SBC-omgeving

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


ver worden aangesloten. Het aantal systemen waarop de applicaties fysiek worden geïnstalleerd, uitgevoerd en beheerd is hiermee met een factor 60 tot 100 gereduceerd t.o.v. de C/S-architectuur. Omdat de impact van het wegvallen van één applicatieserver gelijk is aan het wegvallen van het aantal aangesloten werkplekken worden er voor de beschikbaarheid van de applicaties meer applicatieservers in productie genomen dan rekenkundig vereist. Verschillen tussen SBC- en C/Somgeving De specifieke verschillen tussen een SBC- en C/S-omgeving komen tot uiting in applicatieperformance en applicatieconflicten. Applicatieperformance Performance van de SBC-omgeving is afhankelijk van de som van het ‘gedrag’ van alle actieve gebruikers en actieve applicaties op één systeem. C/S-applicaties worden in de meeste gevallen voor een pc ontwikkeld en verwachten de volledige systeemresource ter beschikking te hebben. De resources van de applicatieserver worden met de overige gebruikers gedeeld. Moderne applicaties houden hier in veel gevallen rekening mee. Oudere applicaties eisen in een aantal gevallen alle resources van het systeem op, waardoor de applicatieperformance voor andere gebruikers nadelig wordt beïnvloed. Het ‘gedrag’ van de applicaties wordt geanalyseerd door de beheerder en indien nodig worden er instellingen en aanpassingen doorgevoerd of wordt additionele managementsoftware ingezet. Applicatieconflicten Bij de kleine en middelgrote bedrijven zijn tussen de 100 en 200 applicaties in gebruik. In de standaard C/S-omgeving zijn de applicaties verspreid over de werkplekken. Het effect is dat een grote verscheidenheid aan werkplekconfiguraties ontstaat. In de praktijk zijn conflicten lastig te herkennen in een omgeving met zo veel variaties.

Om in de SBC-omgeving de applicatieservers maximaal te kunnen benutten en het beheer te vereenvoudigen worden alle applicatie op alle applicatieservers geïnstalleerd. De applicatieservers zijn en blijven hierdoor identiek. De toegang tot de individuele applicatie wordt per gebruiker centraal beheerd.

361

De kans op versieconflicten en technische conflicten groeit asymptotisch met het aantal geïnstalleerde applicaties. Omdat bij het SBC-concept alle applicaties op alle systemen worden geïnstalleerd bestaat de uitdaging uit het onder controle houden van deze conflicten en afhankelijkheden. Voor het onder controle houden van deze conflicten en afhankelijkheden wordt gebruik gemaakt van het OTAP-concept. Applicatiedistributie in een SBCen C/S-omgeving In een C/S-omgeving is elke werkplek voorzien van een set met basisapplicaties. Per gebruiker wordt een aantal specifieke applicaties geïnstalleerd. Het gevolg is dat er een grote verscheidenheid aan configuraties ontstaat. De kleine en middelgrote bedrijven maken voor het beheer van de applicaties op de werkplekken op beperkte schaal gebruik van geautomatiseerde desktop-managementsystemen (DMS). Met een DMS kunnen voorwaarden worden gesteld aan de werkplek, aan de instellingen of aan de gebruiker van de werkplek, voordat de applicatie wordt geïnstalleerd, aangepast of verwijderd. Bij het doorvoeren van iedere wijziging in de applicatieset moeten alle mogelijke combinaties en afhankelijkheden worden geanalyseerd en getest, voordat de wijziging wordt doorgevoerd. Door de grote verscheidenheid aan hard- en softwareconfiguraties is dit een hele uitdaging en het gevolg is dat een groot aantal individuele en specifieke problemen ontstaan.

5

Voor de bedrijven die geen gebruik maken van een DMS is de kans op verstoring groter en het oplossende vermogen kleiner, doordat het opzetten van een representatieve testomgeving niet mogelijk is. Fouten worden hand-


362

Stappen

Testen

Groep/persoon

Ontwikkel

Technische haalbaarheid

Applicatie packagers

Test

Testen op technische conflicten

Technisch beheerders

Acceptatie

Testen op correcte functionaliteit

Functioneel beheerders

Productie

Pilot

Eindgebruikers

Tabel 1

matig hersteld en uiteindelijk wordt de werkplek voorzien van een nieuw basisinstallatie. In de SBC-omgeving wordt juist gestreefd naar het beperken van het aantal verschillende serverconfiguraties, door alle applicaties op identieke servers aan te bieden. Een aanpassing op één server heeft direct impact op een groep van minimaal 60 gebruikers en de functionaliteit van de applicatie kan per server gaan verschillen. In tegenstelling tot het C/S-model, waarbij applicaties op individuele werkplekken kunnen worden aangepast, worden applicatiewijzigingen in het SBCmodel gelijktijdig op alle applicatieservers doorgevoerd. Deze aanpak vraagt een gedegen voorbereiding en een gestructureerde aanpak. Een gestructureerde aanpak is het toepassen van het OTAP-proces waarbij er een logische en fysieke scheiding wordt aangebracht tussen de productieomgeving en de omgevingen waar de voorbereidingen worden ontwikkeld en getest.

HET OTAP-PROCES Het OTAP-proces is een cyclisch proces dat bestaat uit de stappen: ontwikkelen, testen, accepteren en in-productie-name. Het is van toepassing bij de implementatie van zowel nieuwe applicaties als bij het doorvoeren van aanpassingen op bestaande applicaties. Het doel van het OTAP-proces is het optimaal houden van de kwaliteit van de dienstverlening, door stappen in het wijzigingsproces zo lang mogelijk buiten de productieomgevingen te houden. Pas op het moment dat alle testen succesvol zijn afgerond en iedere vertegenwoordiger akkoord is, wordt overgegaan tot het implementeren van de wijziging in de productieomgeving.

Ter ondersteuning van deze processtappen wordt gebruik gemaakt van vier logisch en fysiek gescheiden omgevingen. Het aantal systemen per omgeving is afhankelijk van de grootte van de organisatie en het aantal applicaties dat wordt geïmplementeerd. Per omgeving is een vaste groep personen verantwoordelijk; deze groep hanteert eigen procedures, methodieken en technieken om de kwaliteit te borgen. Op deze manier wordt een duidelijke functiescheiding aangebracht (tabel 1). Toepassen van OTAP in een SBC-omgeving In de ontwikkelfase wordt alle relevante informatie van de applicatie verzameld. De gegevens worden vastgelegd in een applicatieaanvraagformulier (AAF). Bij wijzigingen wordt het formulier gebruikt om de aanpassingen te administreren. Het AAF-formulier bevat naast de technische gegevens ook informatie over de leverancier, over de functioneel- en technisch beheerder en over de gebruikersgroep. Op basis van dit formulier en de verzamelde media wordt de applicatie geïnstalleerd op een standaard applicatieserver. In deze fase wordt de technische haalbaarheid van de applicatie op het platform geanalyseerd en op basis van een nulmeting wordt het ‘gedrag’ vastgelegd. In de testfase wordt gezocht naar conflicten die kunnen ontstaan bij de installatie van een nieuw pakket in een omgeving met reeds geïnstalleerde applicaties. Dit proces wordt ondersteund met software die een deel van de conflictanalyse kan uitvoeren. De uiteindelijke situatie is een opeenstapeling van applicaties met onderlinge afhankelijkheden. In deze fase wordt getest wat de gevolgen van de mutaties in deze omgeving zijn.



In de acceptatiefase wordt de applicatie aangeboden aan de functioneel beheerder. De inhoudelijke werking wordt getest en er wordt gecontroleerd of alle functionaliteiten beschikbaar zijn. Het aanbieden van een applicatie via het SBC-concept heeft invloed op de prestatie en presentatie van de applicatie. In deze fase worden deze aspecten geanalyseerd en vergeleken en wordt de gebruikershandleiding aangepast.

de facto wereldstandaard voor beheer en levering van IT-diensten. Het OTAP-proces zorgt ervoor dat applicaties geschikt gemaakt worden voor de productieomgeving. Is het nu (volgens ITIL) change management of/en release management?

363

Het doel van change management1 is het planmatig doorvoeren van alle wijzigingen in de ICT-infrastructuur. Daarbij worden de risico’s op verstoring van de diensten en daarmee het verlagen van de kwaliteit van de geleverde diensten zo beperkt mogelijk gehouden. Change management vormt de schakel tussen de operationele productieomgeving en de ondersteunende ontwikkel-, testen acceptatieomgeving. Wijzigingen of nieuw applicaties worden planmatig ingevoerd. Daarbij worden risico’s afgewogen en geminimaliseerd. Op verzoek van change management worden versies (release, upgrade, fix, patch) samengesteld die ook afzonderlijk worden getest. Als deze testen goed zijn verlopen, zal change management de beslissing tot vrijgave nemen. De goedgekeurde en vrijgegeven versie wordt dan gedistribueerd, waarna change management de implementatie op de productieomgeving verzorgt.

De applicatie wordt gefaseerd in productie genomen door deze eerst aan een pilotgroep aan te bieden. Voor het uitvoeren van de pilot wordt één van de productieservers voorzien van de nieuwe applicatie en wordt er tijdens de pilot gebruik gemaakt van productiedata. In de configuratie van de SBC-software wordt aangegeven welke groep gebruikers toegang heeft tot dit pilotsysteem. Bij gebleken geschiktheid wordt de applicatie aan de overige gebruikers aangeboden. Het voordeel van het SBC-concept is dat het distribueren van de applicatie bijzonder snel kan worden gerealiseerd omdat het aantal systemen beperkt is en deze altijd beschikbaar zijn. Door bij de uiteindelijke installatie gebruik te maken van een DMS blijven de productieservers identiek.

OTAP IN RELATIE TOT ITIL EN MOF

Release management beheert alle applicaties binnen de productieomgeving. Er worden uitsluitend gecontroleerde applicaties gedistribueerd, waarbij men ervoor zorgt dat men kan terugvallen op originele versies. De

Hoe past het OTAP-proces nu in het welbekende ITIL-bouwwerk? ITIL (Information Technology Infrastructure Library) is zoals bekend een verzameling best practices, de

5

Applicatie 102

Applicatie 103

Applicatie 101

Applicatie 101

...

Applicatie 100

Applicatie 100

Applicatie 100

...

Applicatie 99

Applicatie 99

Applicatie

2

Applicatie

2

...

...

Applicatie

1

Applicatie

1

Applicatie 1

Applicatie 1

SBC-Software

SBC-Software

SBC-Software

SBC-Software

SBC-Software

Applicatieserver OS

Applicatieserver OS

Applicatieserver OS

Applicatieserver OS

Applicatieserver OS

Hardware

Hardware

Hardware

Hardware

Hardware

Ontwikkelomgeving

Testomgeving

Acceptatieomgeving

Productie-omgeving

Figuur 3 OTAP-omgeving 1

Infravision. www.infravision.xs4all.nl/pages/itil.htm


release manager bewaart en beheert de originele versies van software. Daarnaast bewaakt hij het proces van de beschikbaarstelling van software. 364

De conclusie uit bovenstaande is dat OTAP een combinatie is van release management én change management. De release manager bewaakt het proces van beschikbaarstelling (Ontwikkelen, Testen), de change manager geeft de beslissing tot vrijgave (Accepteren en in Productie nemen). Het Microsoft Operations Framework (MOF)2 is gebaseerd op 3 bouwstenen: • Team model - dat zich richt op alle aspecten van het organiseren van IT-personeel. • Proces model - dat zich richt op IT-processen. • Risicomanagement - dat zich richt op het managen van de risico’s voor IT-diensten. Het procesmodel is gebaseerd op ITIL, zie figuur 4. Veel van de in de figuur vermelde Service Management Functions (SMF’s) komen uit ITIL. Uitzonderingen zijn Workforce Management (in het Optimizing kwadrant) en alle SMF’s in het Operating kwadrant. Op het niveau van het procesmodel is MOF (net als

Het onderzoek is gericht op bedrijven die zijn gemigreerd van het conventionele C/Smodel naar het SBC-model en in deze omgeving applicaties aanbieden aan 300 tot 500 medewerkers. De medewerkers zijn verspreid over gemiddeld vier locaties. Het team van beheerders bestaat uit twee tot tien personen en het takenpakket varieert van breed tot zeer specifiek. Een jaar nadat de migratie is uitgevoerd werden circa tien bedrijven benaderd en hun werkwijze geëvalueerd. Het opzetten en in gebruik nemen van het OTAP-concept is binnen SBC een vereiste, de vorm is een keuze. Onderzocht is hoe de beheerders zich deze nieuwe manier van werken eigen hebben gemaakt.

Change Management Configuration Management Release Management

ing Release Readiness Review

ing

MOF

rt ing

at

Opt im

Ch a

ing z i

ng

po Sup

Service Desk Incident Management Problem Management

SBC IN DE PRAKTIJK

Change Initiation Review

Service Level Management Financial Management Capacity Management Availability Management IT Service Continuity Mgmt. Workforce Management Security Management Infrastructure Engineering

SLA Review

ITIL) platformonafhankelijk. Pas op het niveau waarin de vertaling naar de Microsoftproducten wordt gemaakt wordt de MOFdocumentatie platformafhankelijk. Voor wat betreft de relatie met OTAP verandert er op het niveau van het procesmodel dan ook niets: OTAP is eveneens platformonafhankelijk en MOF kent eveneens change management en release management.

Op

Operations Review

er

System Administration Security Administration Service Monitoring & Control Directory Services Administration Network Administration Storage Management Job Scheduling

Figuur 4 Proces model van MOF 2

Microsoft. www.microsoft.com/technet/itsolutions/cits/mo/mof/mofeo.mspx#EBAA



Verwachtingen Het SBC-concept wordt om verschillende redenen geïmplementeerd. De redenen zijn als volgt te categoriseren: • centralisatie, consolidatie van decentrale systemen; • ontsluiten van functionaliteit voor decentrale locaties, telewerken op een veilige manier; • reductie van beheerkosten, door vereenvoudiging en hergebruik van bestaande apparatuur. De eerste twee punten zijn in alle situaties gerealiseerd. De doelstelling om kostenreductie en vereenvoudiging van de omgeving te realiseren is in vijf van de tien gevallen niet overeenkomstig de verwachting gerealiseerd. Als verklaring wordt gegeven dat het beheer, de complexiteit en de afhankelijk van de werkplekken voor ruim 80% is afgenomen. De centrale omgeving is daarentegen complexer geworden en de afhankelijkheid van een kleiner aantal systemen is toegenomen. Het beheer is kritischer geworden doordat de impact van een verstoring groter is dan bij het werken met individuele werkplekken. Bijzondere aandacht gaat uit naar de applicaties die niet op de SBC-omgeving aangeboden kunnen worden. Van de SBC-architectuur is bekend dat gemiddeld 20% van de applicaties niet geschikt zijn om op de SBComgeving te worden aangeboden. Uit het onderzoek bleek dat gemiddeld 15% van de applicaties om technische of organisatorische redenen niet op de SBC-omgeving aangeboden konden worden. Voor bepaalde oude DOS-applicaties, applicaties met een specifieke hardwareafhankelijkheid of applicaties met onderlinge conflicten valt men terug op de oorspronkelijke werkplekken. Als argument wordt ook gebruikt dat een applicatie slechts door enkele personen wordt gebruikt en de kosten voor het realiseren van een applicatiepackage niet opwegen tegen de voordelen van een beheerbare omgeving.

OTAP-gebruik De implementatie van het OTAP-concept op basis van een gescheiden omgeving is bij 50% van de onderzochte groep gerealiseerd. 30% maakt gebruik van een gecombineerde ontwikkelen testomgeving en 20% implementeert de wijzigingen in de productieomgeving. Voor het implementeren in de productieomgeving wordt één server uit de SBC-omgeving gehaald en worden de aanpassingen op deze server doorgevoerd. Bij slechts 20% van de deelnemers zijn de rollen van ontwikkelaar, tester en functioneel beheerder (acceptant) werkelijk gescheiden. In de meeste gevallen is de technisch beheerder verantwoordelijk voor de implementatie en de uitvoering van de technische testen. Alleen voor specifieke applicaties wordt gebruik gemaakt van een functioneel beheerder met voldoende kennis van de applicatie.

365

Het OTAP-concept heeft tot doel de productie minimaal te verstoren. Het testen van de applicaties door de ontwikkelaar levert in de praktijk niet de gewenste kwaliteit op. Zo blijkt dat 15% van de applicaties die op de productieomgeving zijn geïmplementeerd alsnog aangepast of hersteld moeten worden. Beheer Het gebruik van het OTAP-proces heeft een grote invloed op de beheerbaarheid van de omgeving. Bij de bedrijven waar het OTAPproces zo goed mogelijk wordt gebruikt is de ervaring dat de omgeving steeds beter onder controle komt bij de beheerders. Het systeem maakt het mogelijk om niet alleen maar brandjes te blussen maar ook te investeren in onderzoek en ontwikkeling. De beheerinspanning is in kwantiteit niet afgenomen maar de werkzaamheden zijn verschoven van reactief naar proactief.

5


-- tijd -----> C/S-model

SBCmodel ná 1 jaar

SBC-model

366

OTAP

Geen OTAP C/S Beheer(s)baarheid Figuur 5 Beheerbaarheid in de praktijk

Bij de bedrijven die het OTAP-concept niet of niet volledig praktiseren, bestaat twijfel over het SBC-concept. De combinatie van het beheer van werkplekken naast het beheer van de SBC-omgeving wordt als zeer verstorend aangeduid. De beheerbaarheid van de gehele omgeving is afgenomen. Deze afname wordt geweten aan de toegenomen complexiteit, de kwaliteit van de beheerders en de kwaliteit van de applicaties. 20% van de deelnemers maakt geen gebruik van OTAP en implementeert wijzigingen direct in de SBC-omgeving. Dit zijn de deelnemers die eveneens overwegen het beheer van de omgeving uit te besteden. Applicatiewijzigingen Applicaties hebben onderling bepaalde afhankelijkheden die niet altijd herkenbaar zijn. 80% van de onderzochte bedrijven gebruikt een vaste volgorde waarmee de applicaties worden geïmplementeerd. 60% Overige applicaties

Basis applicaties

Systeem image

van de bedrijven gebruikt voor de installatie de software-distributieonderdelen van de SBC-software. Slechts 20% van de bedrijven gebruikt voor het beheren van de SBC-servers en de resterende werkplekken een desktop management systeem (DMS). De overige 20% voert alle werkzaamheden handmatig uit. Eén van de ongewenste effecten van het handmatig installeren is dat servers niet identiek blijven. De functionaliteit van de gehele omgeving is dan niet consistent en dat kan verwarrend zijn voor de eindgebruikers. Als voordeel is aangegeven dat eventuele aanpassingen snel zijn door te voeren. Kleine aanpassingen worden zonder test op een enkele server doorgevoerd en bij wijzigingen met een grote tijdsdruk wordt er van de gehele applicatieserver een kopie gemaakt en wordt de wijziging geïmplementeerd.

{

Applicatie 200

Applicatie 200

Applicatie 199

Applicatie 199

{ {

...

...

Applicatie 21

Applicatie 21

Applicatie 20 ...

Applicatie 20 Applicatie..

Applicatie 1

Applicatie 1

SBC-Software

SBC-Software

Applicatieserver OS

Applicatieserver OS

Hardware

Hardware

applicatie aanpassing applicatie verwijderen applicatie aanpassing

Figuur 6 Applicatiemutaties



In figuur 6 is de opeenstapeling en onderlinge afhankelijkheid van applicaties aangegeven. Wijzigingen van een enkele applicatie heeft effect op de overige applicaties. 10% van de bedrijven maakt gebruik van een applicatie package omgeving met een ingebouwde conflictanalyse. Gedurende het doorlopen van het OTAP-proces worden de afhankelijkheden en conflicten bekend, en worden ze verholpen of vermeden. In de 130 applicaties die in de productieomgeving zijn geïmplementeerd zijn twee fouten geconstateerd. Het doorlopen van het OTAP-proces kan met de juiste afstemming binnen één dag worden gerealiseerd. Bij een hoge tijdsdruk bestaat de uitdaging uit het vasthouden aan de procedures. 60% van de beheerders geeft aan erg gevoelig te zijn voor deze druk en heeft met overhaaste beslissingen en onzorgvuldigheid het OTAP-proces verstoord.

OTAP EN SBC BEST PRACTICE OTAP leeft wel bij de bedrijven, maar het praktiseren blijft om organisatorische en praktische redenen wat achter. Het aantal beheerders is te klein om de verschillende rollen volledig te kunnen scheiden en op een aantal van 2 tot 12 productieservers is het opzetten van een gescheiden OTAP-straat een grote investering. Aan de verdeling van de beheertaak is in de praktijk weinig te veranderen. Het onderscheid tussen de rollen van de ontwikkelaar en de tester moet wel duidelijk worden aangebracht. In de praktijk worden wijzigingen overhaast in productie genomen en veroorzaken daarmee veel verstoring. Het is voor de kleinere organisatie lastig om voldoende gekwalificeerd personeel aan zich te binden en het uitbesteden van de beheertaak is voor deze groep een reële optie.

Virtualisatie van de OTA-omgeving In de kleine omgeving is het aantal wijzigingen beperkt en wordt de OTAP-omgeving beperkt gebruikt. Het gebruik kan efficiënter door het toepassen van servervirtualisatie. Met servervirtualisatie is het mogelijk om op één fysieke server meerdere logische servers aan te bieden. De logische servers kunnen worden ingezet als volwaardige applicatieservers. Alle gegevens van de logische server worden opgeslagen in enkele bestanden, waardoor het tijdelijk opslaan of terughalen van een specifieke serverconfiguratie zeer eenvoudig en snel is uit te voeren. Deze techniek is ontwikkeld in de mainframeomgeving en wordt al jaren toegepast als systeempartitionering.

367

De drie OTA-functies worden gecombineerd op één fysieke server. Het is bijvoorbeeld mogelijk om parallel meerdere test- of acceptatieservers in te zetten. Tijdens het ontwikkelen en testen van applicaties worden de applicatieservers regelmatig terug gebracht naar een stabiele situatie. In plaats van het gebruik van images of herinstallaties wordt de situatie hersteld door het kopiëren van een aantal bestanden. Op deze manier kan efficiënter en sneller worden gewerkt en drukt het gebruik van servervirtualisatie de operationele kosten. Specifieke applicatieservers Er zijn applicaties (‘bad-apps’) die niet geschikt zijn om op een standaard applicatieserver te worden aangeboden. Als deze ‘bad-apps’ worden gecombineerd met de overige applicaties, ontstaat verstoring van de functionaliteit als gevolg van applicatieconflicten, specifieke afhankelijkheden of systeemeisen.

5

Een specifiek punt dat de kleine organisaties kan helpen is het gebruik van servervirtualisatie en een punt voor de grotere omgevingen is juist het opsplitsen van de productieserver in generieke en specifieke applicatieservers.


368

Applicatie 100

Applicatie 100

Applicatie 99

Applicatie 99 Bad-appl.

3

Bad-appl.

6

Applicatie

2

Applicatie

2

Bad-appl.

2

Bad-appl.

5

Applicatie

1

Applicatie

1

Bad-appl.

1

Bad-appl.

4

...

...

SBC-Software

SBC-Software

SBC-Software

SBC-Software

Applicatieserver OS

Applicatieserver OS

Applicatieserver OS

Applicatieserver OS

Hardware

Hardware

Hardware

Hardware

Productie-omgeving

Productie-omgeving (Bad-Apps)

Figuur 7 Omgeving inclusief ‘bad-apps-servers’

Door de ‘bad-apps’ op specifieke servers te implementeren, zoals in figuur 7 is aangeven, blijft de standaard-productieomgeving stabiel. Op de ‘bad-apps’ server wordt gebruik gemaakt van specifieke management software om het ‘gedrag’ van de applicaties te beteugelen. Het gebruik van applicaties op de ‘bad-apps’-servers is voor de medewerkers vrijwel transparant. Algemene Do’s and Don’ts In het onderstaande overzicht zijn de meest relevante leermomenten opgenomen die van toepassing zijn bij het beheren van een SBComgeving: • OTAP: - Streef naar één omgeving: óf SBC óf C/S, en pas OTAP integraal toe. - Zorg voor een duidelijke scheiding in de functie applicatiepackager/-ontwikkelaar en functioneel tester. - Zorg voor een duidelijke scheiding in de applicatieservers voor Productie en voor OTA. - Herinstalleer de productieapplicatieservers eens per half jaar om de servers identiek te houden en de omgeving op te schonen. • Opleiding: - Zorg voor voldoende kennis door passende opleidingen en certificering vóórdat de omgeving wordt opgeleverd. - Maak gebruik van specialisten bij het opzetten van de applicatie package omgeving.

• Applicaties: - Minimaliseer het aantal applicaties en vervang oude applicaties door webapplicaties. Voorkom het gebruik van niet-32-bit applicaties. - Installeer probleemapplicaties op een specifieke ‘bad-apps’ server. • Installatie: - Handmatige installatie. Zet een generieke softwaredistributietool in. Hanteer een vaste volgorde voor applicatieinstallaties. - Maak gebruik van goede conflictanalyse bij het ontwikkelproces. Jeroen A. Kruithof is senior technisch consultant bij BT, op de afdeling Consulting and Systems Integration. Hij ontwerpt en begeleidt infrastructuurmigraties en is gespecialiseerd in het implementeren van server based computing omgevingen.


Bij Server Based Computing (SBC) worden werkplekapplicaties

Recommend Documents