Diplomarbeit Optimierung der Dienstauswahl in einem CORBA ... · Rheinisch-Westfalische Technische...

Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IVProf. Dr. rer. nat. O. Spaniol

Diplomarbeit

Optimierung der Dienstauswahl in einemCORBA-Trader unter dem Aspekt dynamischer

Lastverteilung

(Optimizing the Set of Selected Services in aCORBA Trader by Integrating Dynamic Load

Balancing)

vorgelegt von:Cand. Inf. Helmut Neukirchen

Matr.-Nr. XXXXXX

Marz 1999

Betreuer:Prof. Dr. rer. nat. O. Spaniol

Dipl. Inf. D. Thißen

Zweitgutachter:Prof. Dr. Ing. M. Nagl

Hiermit versichereich, daßich die vorliegendeDiplomarbeitselbstandigundnur un-terBenutzungderangegebenenHilfsmittel angefertigthabe.Alle Stellen,diewortlichodersinngemaßausveroffentlichtenSchriftenentnommensind,sindalssolchekennt-lich gemacht.

Aachen,den9.3.1999

HelmutNeukirchen

Inhaltsverzeichnis

1 Einleitung 1

2 Dienstvermittlung und Lastbalancierungin Verteilten Systemen 32.1 VerteilteSysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 DasobjektorientierteVerteilungsmodell. . . . . . . . . . . . 52.1.2 Kommunikationin VerteiltenSystemen. . . . . . . . . . . . 72.1.3 ManagementvonVerteiltenSystemen. . . . . . . . . . . . . 112.1.4 MonitoringvonVerteiltenSystemen. . . . . . . . . . . . . . 132.1.5 Verteilungsplattformen. . . . . . . . . . . . . . . . . . . . . 15

2.2 Dienstvermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Dienstein VerteiltenSystemen. . . . . . . . . . . . . . . . . 182.2.2 Namensdienst. . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3 Trading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Lastverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1 Lastin VerteiltenSystemen . . . . . . . . . . . . . . . . . . 212.3.2 StatischeLastverteilung . . . . . . . . . . . . . . . . . . . . 242.3.3 DynamischeLastverteilung . . . . . . . . . . . . . . . . . . 24

3 Optimierung der Dienstauswahldurch Lastbalancierung 273.1 Arbeitenim UmfeldTrading . . . . . . . . . . . . . . . . . . . . . . 273.2 Arbeitenim UmfeldLastbalancierung. . . . . . . . . . . . . . . . . 293.3 BestehendeAnsatzederDienstvermittlungunterdemAspektderLast 30

3.3.1 MELODY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.2 LYDIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Verbesserungsmoglichkeiten . . . . . . . . . . . . . . . . . . . . . . 343.4.1 AnforderungenaneinenverbessertenEntwurf . . . . . . . . . 373.4.2 Entwurfsentscheidungen. . . . . . . . . . . . . . . . . . . . 383.4.3 EinordnungdervorgestelltenAnsatze . . . . . . . . . . . . . 42

4 RealisierungeinesTradingsystemszur Lastbalancierung 454.1 ModellierungdesTradingsundderLastbalancierung. . . . . . . . . 45

4.1.1 Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . . . . 464.1.2 ArchitekturundVerhaltendesModells . . . . . . . . . . . . 51

ii INHALTSVERZEICHNIS

4.2 ImplementierungdesModells . . . . . . . . . . . . . . . . . . . . . 594.2.1 Sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.3 Trader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.4 LoadBalancer . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 BewertungdesAnsatzes 775.1 Meßgroßen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.1.1 Lastverteilungsgute . . . . . . . . . . . . . . . . . . . . . . . 785.1.2 Lastverteilungsaufwand . . . . . . . . . . . . . . . . . . . . 785.1.3 FehlerderMeßgroßen . . . . . . . . . . . . . . . . . . . . . 78

5.2 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2.1 Lasterzeugung. . . . . . . . . . . . . . . . . . . . . . . . . 795.2.2 Meßwertaufnahme. . . . . . . . . . . . . . . . . . . . . . . 81

5.3 Meßergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.3.1 Lastverteilungsgute . . . . . . . . . . . . . . . . . . . . . . . 825.3.2 EinflußdesRegelwerksaufdieLastbalancierung. . . . . . . 965.3.3 Lastverteilungsaufwand . . . . . . . . . . . . . . . . . . . . 101

5.4 ZusammenfassungderMeßergebnisse. . . . . . . . . . . . . . . . . 104

6 Schlußbemerkungen 107

Literatur verzeichnis 111

Kapitel 1

Einleitung

DerWunschnachimmerleistungsfahigerenComputeranwendungenunddieMoglich-keit, uberdasInternetweltweitangeboteneDienstezunutzen,habenzueinembeacht-lichenWandelderSoftwaresystemegefuhrt. Die vorherrschendenEinzelplatzanwen-dungenwerdenin diesemZugevonverteiltenAnwendungenabgelost.SieversprecheneineeffizienteNutzungdervorhandenenRessourcenundunterstutzendenTrendderArbeitswelthin zurflexiblen,computergestutztenGruppenarbeit.Im Gegensatzzu einemmonolitischen,zentralenSystemsind Verteilte SystemeinderLage,die angesprochenenAnforderungenzu erfullen, dasie Aufgabenauf meh-rereRechnerknotenverteilenkonnenund so eineSteigerungder LeistungsfahigkeitgegenubereinemeinzelnenSystemermoglichen.Gleichzeitigmit demAufkommenverteilterTechnologienwurdejedochdeutlich,daßsichdie Softwareentwicklungbei verteiltenAnwendungenweitauskomplexer alsbeiherkommlichenSystemengestaltet.Zur LosungdiesesProblemswerdenstandardi-sierteVerteilungsplattformenbenotigt, die in derLagesind,dieVerteilungtransparenterscheinenzu lassen.OffeneStandardshelfendabei,HeterogenitatenzwischendeneinzelnenKomponenteneinesSystemszu uberbrucken.Ein solcherStandard,derzu-nehmendanBedeutunggewinnt, liegt seiteinigerZeit mit CORBA vor.EinenzentralenBestandteildesCORBA-Standardsbildet die einheitlicheSchnittstel-lenbeschreibung,durchdieesmoglich ist, DienstenachdemBaukastenprinzipzunut-zen.DurchIntranetzeunddasInternetkannsoaufeinfirmenweitesodergarweltwei-tesAngebotvonDienstenzugegriffenwerden.EsentstehteinoffenerDienstmarkt,zudessenNutzungeinegeeigneteVermittlungbenotigt wird. DasTrading-Konzeptbie-teneinederartigeUnterstutzung,indemDiensteanhandihrer DienstleistungtypisiertunddurchihreDiensteigenschaftennahercharakterisiertwerden.Als weitererwichtiger Aspektvon VerteiltenSystemenist die moglicheRedundanzvonKomponentenanzusehen.HierdurchkannzumeinendieAusfallsicherheitgestei-gertwerden.Zum anderenwird dasSystembezuglich seinerLeistungsfahigkeit ska-lierbar. Dennochkannesauchin einemausreichenddimensioniertenVerteiltenSy-stemzu temporarenLeistungsengpassenkommen,wenneineRessourceintensiv vonmehrerenDienstnutzerngleichzeitiggenutztwird. DieseEngpassekonnenvermindert

2 1. Einleitung

werden,indemDienstnutzungenaufmehrereahnlicheDienstanbieterverteiltwerden.In dieserArbeit wird einKonzeptvorgestellt,daseineLastverteilungin einemDienst-markt ermoglicht. Hierbei kommt ein Traderzum Einsatz,dessenZiel es ist, einenoptimalenDienstauszuwahlen.DieseOptimalitatbeziehtsichaufzweiAspekte,zwi-schendenenein Kompromißzu schließenist. Einerseitsist dies die Dienstbearbei-tungsdauer, die nebenderLeistungsfahigkeit einesRechnerknotensauchvon derak-tuellenLastabhangigist. Andererseitssoll weiterhindieGutederEigenschafteneinesDienstangebotsberucksichtigtwerden,um dasPotential,dassichdurchdasTrading-konzeptergibt, nutzenzu konnen.Von einer transparentenIntegrationeinerderarti-genLastverteilungin die Dienstvermittlungkonnenalle Dienstnutzerprofitieren.ImRahmendieserArbeit wurdeeinentsprechendesKonzeptunterderCORBA-PlattformOrbix implementiertundgetestet.Die vorliegendeArbeit gliedertsichin sechsKapitel.Zunachstwird aufdiezumweite-renVerstandnisvonDienstvermittlungundLastverteilungbenotigtenGrundlagenvonVerteiltenSystemeneingegangen.NebenDienstvermittlungskonzeptenund Lastver-teilungsstrategienkommendabeiauchdasManagementvonVerteiltenSystem,Kom-munikationsprinzipiensowie derCORBA-StandardzurSprache.Im dritten Kapitel werdenexistierendeArbeiten im Umfeld von DienstvermittlungundLastverteilungvorgestellt.Ein Schwerpunktwird dabeiauf die IntegrationdieserbeidenAspektegelegt. Aus denSchwachender betrachtetenArbeitenergebensichAnforderungenaneinenverbessertenEntwurf.DieseVerbesserungsvorschlagebildenzusammenmit weiterenEntwurfsentscheidungendenSchlußdiesesKapitels.Siege-benzusammenmit einerEinordnungdeseigenenAnsatzesbezuglichderbestehendenSystemeeinenAusblickaufdaszuentwickelndeKonzeptzurOptimierungderDienst-auswahlunterdemAspektdynamischerLastverteilung.DasausderAnforderungsspezifikationentwickelteObjekt-Modellwird in dererstenHalftevonKapitel4 beschrieben.Die zweiteHalfteenthalt einigeausgewahlteAspek-te der Implementierungder realisiertenTrader/LoadBalancer-Kombination.Nebenden strukturellenEigenschaftenwird in diesemKapitel auchauf dasVerhaltenderentstandenenKomponenteneingegangen.Eine Bewertungder vorgenommenenImplementierungund der verwendetenAlgo-rithmenwird im funftenKapitelvorgenommen.DiesgeschiehtanhandvonLeistungs-messungenin kunstlich generiertenTestszenarien.Es erfolgt ein Vergleich der un-terschiedlichenimplementiertenStrategien sowohl untereinanderals auchbezuglicheinesherkommlichenTraders.Kapitel 6 bildet denAbschlußund faßtdie in dieserArbeit gewonnenResultatezu-sammen.AnhandderoffengebliebenenFragenwird einAusblickaufweitere,verfol-genswerterscheinendeAnsatzegegeben.

Kapitel 2

Dienstvermittlung undLastbalancierunginVerteilten Systemen

Im folgendensoll ein Uberblick uber Verteilte Systemeund die dort eingesetz-ten Konzeptegegebenwerden.Neben den Grundlagen,die im wesentlichenauf[Tan95, Pop96]basieren,wird dabeidetaillierterauf die im weiterenVerlauf dieserArbeit behandeltenSchwerpunkteDienstvermittlungundLastverteilungeingegangen.

2.1 Verteilte Systeme

Laut [SPM94] handeltessichbei einemVerteiltenSystemum ein”Systemmit raum-

lich verteiltenKomponenten,diekeinengemeinsamenSpeicherbenutzenundeinerde-zentralenAdministration unterstellt sind.Zur AusfuhrunggemeinsamerZiele ist eineKooperationder Komponentenmoglich. WerdenvondenKomponentenDiensteange-botenoder genutzt,so entstehtein Client/Server-System,im Falle einer zusatzlichenzentralenDienstvermittlungeinTradingsystem.“ 1

Ein VerteiltesSystembestehtdemnach– wie in Abbildung2.1dargestellt– ausmeh-rerenComputern(Rechnerknoten),dieuntereinandervernetztsind.Die Softwarekom-ponentenauf deneinzelnenRechnerknotenwerdengleichzeitigausgefuhrt undkom-munizierenuberdasNetzwerkuntereinander, umDatenauszutauschen.Gegenuberherkommlichen,zentralenSystemenbietetderverteilteAnsatzeinigeVor-teile, die – nicht zuletzt wegen der dadurchmoglichen Kosteneinsparung– dazugefuhrt haben,daßsich verteilteAnwendungenimmer starker durchsetzen.Im glei-chenMaßeverlierendabeiGroßrechneranBedeutung,dasiebei Aufgaben,die sichgenausogutauf mehrerekleinereRechnerverteilenlassen,ungleichteurerin derAn-schaffungsind.

1Laut [Tan95] definiertLeslieLamportein VerteiltesSystemwie folgt:”Ein System,mit demman

nicht arbeitenkann,weil einRechnerausgefallenist, vondemmannoch nieetwasgehort hat.“

4 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen

Netzwerk

Computer 1 Computer 2 Computer 3

CPU CPU

Speicher Speicher

CPU

Speicher

Abbildung2.1:Ein einfachesVerteiltesSystem

Zu denVorteilenvonVerteiltenSystemenzahlenu.a.[ZFD93]:� Wirtschaftlichkeit: Ein Verteiltes Systemist bei gleicher LeistungsfahigkeitpreiswerteralseinentsprechenderGroßrechner.� Geschwindigkeit: Durch Parallelisierung von Arbeitsschrittenkonnen Ge-schwindigkeitenerreichtwerden,dieeineinzelnerRechnernieerreichenkann.� GemeinsameNutzungvonBetriebsmitteln:GemeinsambenotigteDatenkonnenvon allengenutztwerden;teureGeratekonnenvon allenKomponentendesSy-stemsbenutztwerden.� Verteiltheit: Die z.B. aufgrund von kooperativer GruppenarbeitnotwendigeraumlicheVerteilungvon Rechnersystemen,die miteinanderkommunizieren,wird durchVerteilteSystemeerstmoglich.� Fehlertoleranz:Bei Ausfall einesRechnerknotenskann dasRestsystemnochweiterarbeitenunddieFunktionalitatdesausgefallenRechnersubernehmen.� Skalierbarkeit: Die Rechenleistungkann in beliebigenSchrittendurch Hin-zufugenvonneuenRechnerknotenandiebenotigteLeistungangepaßtwerden.� Flexibilit at: Eine Anderungin derStrukturdesSystemsist leicht moglich, umsichsogeandertenGegebenheitenanzupassen.

Damit ein VerteiltesSystemdie genanntenVorteile ausspielenkann,mussenjedocheinigeSchwierigkeiten,diesichaufgrundderVerteiltheitergeben,gelostwerden.Alsproblembehaftetsinddie folgendenPunkteanzusehen:� Softwareentwicklung:Durch die Verteilungvon Datenund Algorithmenerge-

ben sich neuartigesoftwaretechnischeProbleme.Damit die Erstellungskosten

2.1.VerteilteSysteme 5

verteilterAnwendungenim Bereichvon zentralenAnwendungenliegen,wer-denKonzeptezur nahtlosenIntegrationderVerteilungbenotigt.� Heterogenitat: Ein SystemkannausKomponentenverschiedenerHerstellerbe-stehen.Zur UberbruckungderherstellerspezifischenUnterschiedewerdenoffe-neStandardsbenotigt.� Datenschutzund Datensicherheit:Durch die Verteilungkonnenschutzenswer-te Datennicht mehrso leicht gegenunerlaubteZugriffe abgeschottetwerden.Hierfur mussenAuthentifizierungs-und sonstigeSicherheitsmechanismenaufdieKonzeptederVerteiltenSystemeubertragenwerden.� Fehleranfalligkeit: Jegroßerein Systemwird, destowahrscheinlicherwird es,daß eine Komponenteausfallt. Um die Auswirkung zu begrenzen,muß esmoglichsein,daßandereKomponentendieAufgabenderausgefallenenKompo-nenteubernehmen.Zusatzlichkommtin VerteiltenSystemendurchdieKommu-nikationubereinNetzwerkeinezusatzliche,durchentsprechendeUbertragungs-protokolle zuberucksichtigendeFehlerquelleim Programmdatenflußhinzu.� Synchronisation:Die Synchronisationvon Uhrenund Ablaufengestaltetsichschwierigerals in zentralenSystemenund erfordertneuartige,verteilteAlgo-rithmen.� Lokalisierungvon Komponenten:Im Gegensatzzu Einzelplatzanwendungen,beidenensichallebenotigtenProgrammkomponentenaufdemlokalenRechnerbefinden,benotigenverteilteAnwendungeneineentsprechendeUnterstutzung,da durchdenEinsatzin einemoffenenDienstmarktund aufgrundvon Objekt-migrationerstzur Laufzeitermitteltwerdenkann,auf welchemRechnerknotensichein jeweilsgesuchtesObjektbefindet.� Uberlast:Der Vorteil der Skalierbarkeit gehtschnellverloren,wennaufgrundvon lokalenEngpassendie gesamteSystemleistungherabgesetztwird. HierbeimußzwischeneinerUberlastdesNetzesaufgrundubermaßigerKommunikati-onsvorgangeund uberlastetenRechnerknotendurcherhohtesBerechnungsauf-kommenunterschiedenwerden.Zur VermeidungsolcherUberlastsituationenistnebender Reduzierungvon Flaschenhalsenauf eine gleichmaßigeVerteilungderLastaufmehrereKomponentenzuachten.

2.1.1 Dasobjektorientierte Verteilungsmodell

Die im vorhergehendenAbschnittaufgefuhrtenProblemekonnenzumTeil vermiedenwerden,wenn eine Kontextunabhangigkeit [ZFD93] der Komponentengegebenist,d.h.einzelneKomponentenohneAnderungin unterschiedlichenUmgebungeneinge-setztwerdenkonnen.Als wichtige Grundanforderungenan ein Paradigma,dasdie


EntwicklungeinesVerteiltenSystemsunterstutzt,ergebensichdementsprechendu.a.[Red96,Kov94]:� Verteilungstransparenz:Die AspektederVerteilung(Auf welchemRechnerbe-

findensichdie Daten?Wie ist dasSystemstrukturiert?)sollenderAnwendung– undsomitdemEntwickler– verborgenbleiben,damitwie gewohntauf DatenundProgrammteilezugegriffenwerdenkann.� InteroperabilitatundOffenheit:Um eineZusammenarbeitderunterschiedlichenRechnerundBetriebssystemesowieNetze,ausdenendasSystembestehenkann,zu ermoglichen,mussenderenHeterogenitatendurch herstellerubergreifende,offeneStandardsuberbrucktwerden.� Flexibilit at und Modularitat: Eine modulareSoftwareentwicklungermoglichtdie effizienteWiederverwendungvon existierendenKomponenten.Die Modu-le bilden dabeidie Einheiten,in die dasGesamtsystemzerlegt und auf einzel-neRechnerknotenverteilt werdenkann.DurchAnderunganwenigenModulenkanndasSystemeffizientundflexibel neuenGegebenheitenangepaßtwerden.

Eshatsichgezeigt,daßeinobjektorientierterAnsatz[RBP+93, Mey90] bisherambe-stengeeignetist, dieseAnforderungenzu erfullen [Sch91]:Die objektbasierteSicht-weisesorgt durchAbstraktiondafur, daßDetailsverborgenwerden[Nag90],wodurchdie ForderungennachVerteilungstransparenzundInteroperabilitat erfullt werden.Dabei der objektorientiertenHerangehensweiseein GesamtsystemauseinerAnsamm-lung von einzelnenObjektengebildetwird, ergibt sich automatischein modularerAufbau,derdaruberhinausdurchdieubrigenAspektedesobjektorientiertenAnsatzesnochanweitererFlexibilit atgewinnt.Beim objektorientiertenParadigmawird alsgrundlegendesKonstruktdasObjektver-wendet;esenthalt DatenstrukturenundAlgorithmenzugleichund ist somit ideal furdie Verteilungsowohl von Datenals auchAblaufengeeignet.Die in der realenWeltanzutreffendenObjekteeinerAnwendungspiegeln sich bei der ModellierungdieserAnwendungim Computerin FormvonsolchenSoftwareobjektenwieder. DaderAuf-ruf dereinzelnenOperationeneinesObjektskonzeptionellbereitseinegewisseKom-munikationerfordert,um daspassendeObjektodereineOperation(sog.Methode)zufinden(dynamischesBinden),gestaltetsichderUbergangzueinemVerteiltenSystemrelativ einfach.EinzelneObjektelassensichauf verschiedenenRechnerknoteninstantiierenundstel-len ihreDiensteuberSchnittstellennachaußenanderenObjektenzurVerfugung.EineverteilteAnwendungsetztsichdannausdenInstanzensolcherObjektezusammen,diegegenseitigOperationenaufrufen.Die Kommunikationerfolgtdabeiwie in Abbildung2.2uberihreSchnittstellen.Zum Aufruf solcherOperationenwird ein entfernterMethodenaufrufverwendet,derdasKonzeptdesentferntenUnterprogrammaufrufs(remoteprocedurecall, RPC) indieobjektorientierteWelt ubertragt[Sch91].


Operationsaufrufe

Schnittstelle

Daten

Methoden

Abbildung2.2:AufbaueinesObjekts

Fruhe Verteilte Systemebasiertenauf dem Client-Server-Modell, bei dem uberEin-/Ausgabeprimitive(

”send“ und

”receive“ ) DatenvonBenutzerprozessen(Clients)

an Dienstprozesse(Server) geschickt,dort verarbeitetund zur Ergebnisubermittlungwiederzuruckgesendetwurden.DasdarauffolgendeParadigmagreift denherkommli-chenUnterprogrammaufrufauf underreichtdadurchdie geforderteVerteilungstrans-parenz.Die Idee des entferntenUnterprogrammaufrufssieht vor, den Aufruf vonDiensten,die sich auf einemanderenRechnerbefinden,wie einenherkommlichenUnterprogrammaufruferscheinenzu lassen.Der Aufruf von entferntenDienstenun-terscheidetsichfur denProgrammierernicht von demAufruf einesUnterprogramms,dasdenselbenDienstlokal erbringt.Fur dasobjektorientierteVerteilungsmodellmußdiesesKonzeptnocherweitertwer-den.NebendernunmoglichenObjektvererbungundOperationspolymorphie[Mey90,RBP+93], die einerzusatzlichenBeachtungbedurfen,konnendurchdie VerwendungeinesobjektorientiertenAnsatzesnunnichtnurUnterprogramme,sondernauchDatentransparentverteilt werden.Dadurchwird esu.a.moglich, Referenzenauf entfernteDatenbzw. Objektezu verwenden,weshalbdie Behandlungvon Zeigernebenfalls andieverteilteWelt angepaßtwerdenmuß[Sch91].Die beschriebenenVorteileunddiedafur zu losendenProblememachendeutlich,daßVerteilteSystemeunterdemAspektder Softwareentwicklungzugleichein ProblemundeineChancedarstellen:Zum einenwerdendurchdie Verteilungvollig neuartigeProblemeaufgeworfen,zumanderenruckt die Vision derWiederverwendbarkeit vonSoftware nachdem Baukastenprinzip[Nag90] einenSchritt naher, da in VerteiltenSystemeneineKontextunabhangigkeit gegebenist [Sta95, APRA98, Sch91].

2.1.2 Kommunikation in Verteilten Systemen

EineelementareGrundlagefur jedesVerteilteSystemist einefunktionierendeKom-munikationsinfrastruktur. Um die in den vorhergehendenenAbschnittengeforderte


Offenheit des Systemszu erreichen,werdenoffene Kommunikationsarchitekturenbenotigt. Als Modell, daseinen Rahmendafur bietet, hat sich das OpenSystemsInterconnection-Referenzmodell(OSI-RM) [ISO84] derinternationalenStandardisie-rungsbehordeISObewahrt.Um eineoffeneKommunikationzu gewahrleisten,siehtdasOSI-Modell vor, die je-weils spezifischenAspekteder Kommunikationin insgesamtsiebenaufeinanderauf-setzendeSchichtenmit definiertenSchnittstellenzu kapseln.Die in den einzelnenEbenenbehandeltenAspektereichenvon derUbertragungshardwareuberdie Sicher-stellungeinesfehlerfreienTransportsbis zur eigentlichenAnwendung.Die genaueSchichtungist in Abbildung2.3(a)dargestellt.

7

6

5

4

3

2

1

OSI-Referenzmodell

Anwendungungsschicht

Präsentationsschicht

Sitzungsschicht

Transportschicht

Netzwerkschicht

Verbindungsschicht

Physikalische SchichtEthernet, FDDI, ...

Client-Server-Modell

HTTP, FTP, RPC, ...

TCP/IP

TCP, UDP

IP

Ethernet, FDDI, ...

Anfrage-/Antwortprotokoll

(a) (b) (c)

--

--

--

--

--

--

Abbildung 2.3: Die OSI-Schichten,die TCP/IP-Protokollfamilie und das Client-Server-Modell

Von der ISO werdenauchkonkreteProtokolle zur Implementierungdervon denein-zelnenOSI-SchichtenbereitzustellendenDienstevorgeschlagen,dennochhatsichdieunabhangigdavonentwickelteInternetprotokollfamilieweltweitdurchgesetzt[Tan96].Die Internetprotokollfamilie besitztzwar kein so sauberesModell wie OSI, ist aberaufgrunddesebenfallsvorhandenenSchichtenkonzeptsundseinerweitenVerbreitunggleichermaßenzur Kommunikationin heterogenenSystemengeeignet.EineEinord-nung der einzelnenInternetprotokolle in dasOSI-Referenzmodellist in Abbildung2.3(b) gegeben.Es lassensich grundsatzlich verbindungsorientierteund verbindungsloseUbertra-gungsprotokolle unterscheiden.Wahrenddas verbindungsorientierteTransmissionControl Protocol (TCP) eine VerbindungzwischenSenderund EmpfangeraufbautundeineverlustfreieInformationsubertragunggarantiert,fehlt demverbindungslosen


User DatagramProtocol(UDP) eine derartigeSicherung.Da UDP unmittelbaraufdemrechteinfachenInternetprotokoll (IP) derdarunterliegendenSchichtaufbaut,istdie Ubertragungmittels UDP schneller, aberauchfehlerbehafteterals die per TCP.Die Pakete,die dasInternetprotokoll zur Ubertragungverwendet,konnenverloren-gehenoderin unterschiedlicherReihenfolgeeintreffen, weshalbTCPzusatzlicheineaufwendigeSicherungundSortierungderIP-Paketevornehmenmuß[Tan96].Ein Grund, der – nebender fruherenVerfugbarkeit – zur Dominanzder Internet-protokolle beigetragenhat, ist deren– gegenuberOSI-Protokollimplementierungen–i.d.R. hohereGeschwindigkeit. Hierfur ist die effizientereImplementierbarkeit bzw.diegeringereAnzahlvonSchichtenverantwortlich,dajededurchlaufeneSchichteinenzusatzlichenProtokolloverheadzur Folge hat. Im Vergleich dazu ist in Abbildung2.3(c) dasClient-Server-Modell zur Prozeßkommunikationzu sehen,dasmit seinemeinfachenAnfrage-/Antwortprotokoll direkt auf der Netzwerkhardwareaufsetztundentsprechendschnellarbeitenkann[Tan96].Die beidenbeschriebenenKommunikationsarchitekturenerlaubeneineKommunikati-on zwischeneinzelnenRechnerknoten;siebeinhaltenaberkeineKonzeptezur Kom-munikationzwischeneinzelnenentferntenProzessen.Dies wird nebemdemClient-Server-Modell, dassich wegen mangelnderTransparenznicht durchsetzenkonnte,vom bereitsim vorherigenKapitel angesprochenenentferntenMethoden-bzw. Pro-zeduraufrufgeleistet.DiesesKonzeptist in den oberstendrei Schichtendes OSI-Referenzmodellsangesiedeltund setztauf den ubrigenunterenvier Schichtenauf.VomAspektderDatenkommunikationherist esdabeiunerheblich,obeinprozeduralesodereinobjektorientesVerteilungsmodellzumEinsatzkommt,weshalbim folgendenvereinheitlichendderBegriff RPCverwendetwird.Da herkommliche ProgrammiersprachenUnterprogrammelediglich lokal aufrufenkonnen,wird eineErweiterungbenotigt, die esdemBenutzerprozeßermoglicht, denUnterprogrammaufrufuber dasNetzwerkan den gewunschtenServer-Prozeßwei-terzuleiten.Dies wird vom sogenanntenClient-Stubgeleistet.Dieser verpacktdieUbergabeparameterdesUnterprogrammaufrufsin einNachrichtenpacket,dasvonderKommunikationsinfrastrukturandenZielrechnerweitergeleitetwird. Dort nimmt derServer-StubdiesesPaket entgegen,packtdie ubergebenenParameterausundruft da-mit dasgewunschteUnterprogrammauf, um im Anschlußdie Ruckgabeparameterzuruckzusenden.DieserAblaufwird in Abbildung2.4dargestellt.Nebendenbeschrie-benenAufgabenmußsichderStubauchdarumkummern,daßdie verwendetenDa-tenformatederjeweiligenRechnerknotenkompatibelsind,indemdiezuubertragendenWertein einerechnerunabhangigeDarstellungumgewandeltwerden(Marshalling).AnalogzurSemantikdesherkommlichenUnterprogrammaufrufswird deraufrufendeProzeßblockiert,bis die Ruckgabeparametereingetroffen sind.Da ausGeschwindig-keitsgrundenfur den RPC oft ein verbindungslosesUbertragungsprotokoll verwen-detwird, kannesjedochvorkommen,daßRPC-Nachrichtenverlorengehen.Der Stubmußsich deshalbnacheinemTimeoutdarumkummern,die Nachrichtein weiteresMal zu sendenodereinenFehlerzu melden.Hierin unterscheidetsich die Semantikdesentferntenvom lokalenUnterprogrammauf,bei demkein Fehlerauftretenkann.


a:=sum(4,5)

Prozeß

a:=9

blockiert

(sum,4,5)

Zeit

(9)

sum(x,y){

}return(x+y)

Client-Prozeß Server-Prozeß

Server

Client-Rechner Server-Rechner

Client

Client-Stub

Betriebssystem

Server-Stub

Aufrufparameter

parameterRückgabe-

Betriebssystem

Abbildung2.4:SchemaeinesentferntenProzeduraufrufs

In objektorientiertenSprachensindublicherweiseprogrammeigeneRoutinenzurAus-nahmebehandlungvorgesehen,uberdiederAufrufer geeignetaufstub-generierteFeh-ler reagierenkann.Die vom Client-StubgenerierteRPC-Nachrichtist an ein konkretesaufzurufendesUnterprogrammgerichtet.DasVerteilteSystemstehtdabeivor demProblem,dieseNachrichteinembestimmtenProzeßauf einembestimmtenRechnerknotenzuordnenzu mussen.Hierfur wird ein dynamischerBinderbenotigt, derausdenAngaben,mitdenensich ein Serverprozeßbeim Binder registrierenmuß,die passendeZuordnungtreffenkann.Abschnitt2.2beschaftigt sicheingehendmit denverschiedenenKonzep-ten,diedazuverwendetwerdenkonnen.Der entfernteUnterprogrammaufrufgliedertsich zwar hervorragendin die Welt derbekanntenProgrammierparadigmenein, fur mancheAnwendungsgebiete,die in Ver-teiltenSystemenauftreten,ist diesesKonzeptdennochungeeignet.Fur eineasynchro-ne Kommunikation,die es den beteiligtenProzessenermoglicht, weiterzuarbeiten,ohneauf die Antwort desanderenProzesseswartenzu mussen,sind beispielswei-senicht-blockierendeKommunikationsmethodennotig. Auch Meldungen,die analleodermehrereProzessegehensollen(Broad-bzw. Multicasting),lassensichnichteffi-zientmit derZwei-Parteien-KommunikationdesRPCrealisieren.Hierfur sindin denmeistenVerteiltenSystemengesonderteKonzeptevorgesehen,aufdieandieserStelleallerdingsnichtnahereingegangenwerdensoll.


2.1.3 Managementvon Verteilten Systemen

Um die vielfaltigen Ressourceneines Verteilten Systemszu verwalten, zu uber-wachenund zu koordinieren,wird ein speziellesManagementbenotigt. Ziel einesderartigenManagementsvon VerteiltenSystemenist ein moglichst effektiver Ein-satz des Gesamtsystems.Eine ausfuhrliche Beschreibung diesesGebietswird in[HA93, Slo94,Sei94,LR96,Kau92]gegeben.Die hierbetrachtetenManagementaufgabenlassensichdurchEbenenundfunktionaleBereichestrukturieren.ZunachstlassensichdieeinzelnenRessourceneinesVerteiltenSystemder Netzwerkebene,der (Betriebs-)Systemebeneund der Anwendungsebenezuordnen.Fur dasin dieserArbeit behandelteGebietdesAnwendungsmanagementbestehendie verwaltetenRessourcenbeispielsweiseausdenstatischenSoftwaremo-dulenunddenlaufendenProzessen,sowie denvondiesenverarbeitetenDaten.Als weitereStrukturierungsdimensiondient die Aufteilung in unterschiedlichefunk-tionaleManagementbereiche.Dieseergebensichausdenfur ein umfassendesMana-gementbenotigtengrundsatzlichenAufgaben.Im einzelnenergebensichfunf Aufga-benbereiche[ISO89]:� Fehlermanagement:Es ist fur die ordnungsgemaßeFunktion einesSystems

außerstwichtig, Fehlerim Systemzu erkennenund zu beheben.Das Fehler-managementmußentsprechendeFunktionenzurVerfugungstellen.� Konfigurationsmanagement:DieserBereichbefaßtsichmit derStrukturdesSy-stemsundderKonfigurationdereinzelnenKomponenten.NebendemstatischenSystemzustand,der vor Inbetriebnahmeeingestelltwird, sollte sich dieserZu-standauchdynamischandernlassen.� Abbrechnungsmanagement:Vor allemim kommerziellenBereichspieltdie Er-fassungderdurchdie NutzungderverwaltetenRessourcenbzw. Dienstleistun-genaufgetretenenKosteneinewichtigeRolle.� Leistungsmanagement:Uberlastsituationensollen erkanntund durch Lastaus-gleichabgefangenwerden.Hierzu ist esnotig, Statistiken uberdie Auslastungzu fuhren,um geeigneteGegenmaßnahmenplanenzukonnen.� Sicherheitsmanagement:Um Datensicherheitund Datenschutzzu gewahrlei-sten,mussenZugriffsrechteverwaltet und geregelt werden,anhanddererAu-thentifizierungsmechanismendenZugriff auf die jeweiligenRessourcenzulas-senoderauchAlarm auslosen.

DurchKombinationdieserBereichelassensichweitereAufgabengebietebehandeln.Hierunterfallt z.B. dasDienstmanagement,bei demdie moglichenDienste,die voneinerAnwendungin Anspruchgenommenwerdenkonnen,verwaltetwerden.NebenderkorrektenZuteilungderunterschiedlichenDienstleistungenandieDienstnutzeristdabeidie BerucksichtungunterschiedlicherDienstgute(Quality of Service,QoS)von


Bedeutung.In Echtzeitsystemenundim Multimediabereichist die Qualitat derUber-tragungaußerstwichtig.VonverschiedenenSeitenwurdenStandardsentwickelt,welchedieVereinheitlichung,die bei denKommmunikationsnetzenstattgefundenhat,auchauf derenManagementubertragensollen.VonderNetzwerkebenekommendgibt esdementsprechendwiedereinenISO OSI-Standard(CommonManagementInformationServicebzw. Protocol,CMIS/CMIP) [ISO89] sowie einenInternetstandard(Simple Network ManagementProtocol,SNMP)[CFSD90], diesichdurchgesetzthaben.Danebenexistierenim BereichdesManagementsfur verteilteAnwendungenzur Zeitnochviele unterschiedlicheSysteme,dadie StandardsderNetzwerkebenesichnichtumfassendhierauf ubertragenlassen.SNMP bietet kein objektorientiertesKonzeptund aufgrundder angestrebtenEinfachheitauch nur eine eingeschrankte Funktio-nalitat; CMIP hingegen erfullt zwar dieseAnforderungen,ist jedochviel zu kom-plex und entsprechendaufwendigzu implementieren.Zur Zeit dominierendahernochproprietareLosungen,die sich am OSI-Standardorientieren.NebendemOSI-ManagementFramework hat die ISO spaterspeziellfur VerteilteSystemedasOpenDistributed Processing-Referenzmodell(ODP-RM) [Ray94, ISO95a]standardisiert,dasseitneuererZeit auchim ManagementbereichanEinflußgewinnt [KN97].DasODP-Referenzmodellist in Schicht7 desOSI-Referenzmodellsanzusiedelnundstellt ein Rahmenwerkfur VerteilteSystemedar. Die darinvorgesehenenSichtenundModellierungenbieteneineBasis,um offenVerteilteSystemezuentwickeln.AnhandderzugehorigenFunktionen[ISO95b]konnendementsprechendoffeneManagement-architekturenerstelltwerden[KN97].Ahnlich wie bei denVerteilungsparadigmenhatsich im Managementbereich– abge-sehenvon SNMP – ein objektorientiertesParadigmadurchgesetzt.ZentralerBegriffist hierbeidasManagedObject(MO), daseineManagementsichtauf die zu verwal-tendenRessourcenmodelliert. Im Gegensatzzur softwaretechnischenSicht werdendurchManagedObjectsnicht die datenverarbeitendenBausteine,sonderndie fur dasManagementidentifiziertenRessourcenabstrahiert.DerenStatuskannubereineei-geneManagementschnittstelle,die vonderreinenDatenverarbeitungsschnittstelledesentsprechendenSoftwareobjektsunabhangigist, von außendurcheinenManagerab-gefragtundverandertwerden[Kov94, BU96, ISO89].Die softwaretechnischenObjekte, die die jeweils lokalen ManagedObjectseinesRechnerknotensverwalten,werdeni.d.R.als(Management-)Agentenbezeichnet.AufVeranlassungeinesexternenManagersnehmendie Agentendie eigentlichenAnde-rungenan denverwaltetenRessourcenvor bzw. leiten Nachrichten(Notifikationen),die ein ManagedObjectaufgrundeinesEreignisseserzeugt,an einenManagerwei-ter. GegenubereinemManagertritt ein Agentdabeiin die Rolle einesManagedOb-jects,gegenubereinemManagedObject in die Rolle einesManagers.Das Zusam-menspielin einerderartigenManagementarchitekturist in Abbildung2.5 dargestellt[Kov94, CPRV96, IDSM93].Die in einemSystemverfugbarenManagementinformationen,diesichausderMengederverwaltetenManagedObjectsergeben,werdenalsManagementInformationBase


MOAgent in

Manager-Rolle

MO-RolleAgent in

Verwaltender Rechner Verwalteter Rechner

MO

Managementvorgaben

AgentManager

Managementoperation

Managementnachricht

Abbildung2.5:PrinzipiellerAufbaueinerverteiltenManagementarchitektur

(MIB) bezeichnet.DasOSI-Modelllaßtoffen, in welcherFormsichdie MIB in einerImplementierungwiederfindet[CPRV96, ISO89].

2.1.4 Monitoring von Verteilten Systemen

Da die ManagementInformationBaseauchveranderlicheInformationenbeinhaltenkann,wird fur dieErfassungsolcherDateneinespezielleUnterstutzungbenotigt.Dieswird vomMonitoringgeleistet.Monitoring umfaßt alle Vorgange,die notig sind, um dynamischeInformationenineinemVerteiltenSystemzu sammeln[MS93]. Weil sichManagemententscheidungennachderartigenInformationenrichten,bildetdieErfassungundAufbereitungvonSy-steminformationeneinebedeutendeGrundlagefur dasManagement[IDSM93]. DieRolle, die dasMonitoring im Managementvorgangeinnimmt,wird in Abbildung2.6deutlich.Ein guter Uberblick uberdasMonitoring von VerteiltenSystemenwird in[MS93, JLS+87]gegeben.

Datenerfassung

Monitoring

System

Management-

Änderungs-operationen

Entscheidungen

Beeinflussung

Abbildung2.6:Monitoring im Kontext desManagements


NebenAnwendungen,diedie gesammeltenInformationenaufbereitenunddarstellen,werdenMechanismenbenotigt, um die gewunschtenInformationenamOrt desAuf-tretenszuerfassenundanschließendweiterzuverbreitenbzw. fur einenspaterenAbrufzuspeichern.Dieswird vonMonitorobjektengeleistet,die– ahnlicheinemAgenten–von denzu uberwachendenRessourcenDatenuberderenZustandermittelnundwei-terverarbeiten.NebeneinerzeitbasiertenMeßwertaufnahmein regelmaßigenAbstandenist aucheinereignisbasiertesMonitoringmoglich,beidemEreignisse,dieeineZustandsanderungderuberwachtenRessourcesignalisieren,erkanntundweitergemeldetwerdenmussen.In diesemZusammenhangtritt dasProblemderzeitlichenkorrektenEinsortierungderDatenauf,dain einemVerteiltenSystemdieReihenfolgedesEintreffensvonInforma-tionennicht unbedingtmit derReihenfolgederEntstehungubereinstimmenmußundZeitmarken aufgrundunsynchronisierterUhrennicht eindeutigsind. Damit die vonverschiedenenMonitorenerfaßtenDatengemeinsamgenutztwerdenkonnen,mußderMonitor daruberhinausdie WerteuberMetriken in vergleichbareWerteumrechnenundin einemeinheitlichenDatenformatzurVerfugungstellen.Bei weiterAuslegungdesManagementbegriffs fallenalle perMonitoring gesammel-ten Daten in den Managementbereich.Dementsprechendlassensich auchdie dortidentifiziertenfunf Bereichewie beispielsweisedie Fehlerbehebungbzw. -sucheoderetwa die LeistungdesSystemsauchzur KlassifikationderEinsatzgebietedesMoni-toring benutzen.DieseBereichekonnenwiederumdemUrsprungderDatenentspre-chendin Netzwerk-,System-undAnwendungsebeneunterteiltwerden.Der BereichdesLeistungsmonitoringsoll im folgendenbeispielhaftvorgestelltwer-den,da er im weiterenVerlauf der vorliegendenArbeit eine wichtige Rolle spielt.Um die Last innerhalbeinerverteiltenAnwendungzu bestimmen,wird ein Monitorbenotigt,derdielastspezifischenMerkmaledeszuuberwachendenObjektsmißt.Dazubietetessichbeispielsweisean,dievomObjekterzeugteCPU-LastoderdieAntwort-zeitenauf die Anfragender Clients zu messen.Wahrendfur die ersteVarianteeinBetriebssystemaufrufauf dembetreffendenRechnerknotenreicht,mußfur die zweiteeinsogenannterSensorin daszuuberwachendeSoftwareobjekteingebautwerden,umdort die entsprechendenZeitenzu messenund ubereineMonitoring-SchnittstelleandenMonitor zu ubertragen.Bei derVerwendungvon Sensorenmußdasobjektbasier-te KonzeptdesVersteckensvon internenInformationendurchbrochenwerden,da jageradedieseinternenDateneinesObjektserfaßtundnachaußenubermitteltwerdensollen[CPRV96].Als zusatzlichesProblemistbesondersbeimLeistungsmonitoringzubeachten,daßdasMonitoringselberwiederumEinflußaufdasSystemhat,dadieUbertragungderMeß-datenNetzwerklasterzeugtundderMonitor selberRechenzeitundSpeicherbenotigt,daessichbeimMonitor um ein herkommlichesSoftwareobjekthandelt.Daherist esnotwendig,einenKompromißzwischendengegensatzlichenZielen einermoglichsthohenGenauigkeit bzw. AktualitatderMeßdatenundeinermoglichstgeringenzusatz-lich erzeugtenLastzufinden.Hardware-MonitorewurdendiesenEffekt reduzieren,siesindallerdingsauchteurerundunflexibler, weshalbsieselteneingesetztwerden.


2.1.5 Verteilungsplattformen

Die in den vorhergehendenAbschnittenvorgestelltenKonzeptesollendazudienen,derAnwendungbzw. demAnwendungsprogrammiererdie AspektederVerteilungzuverbergenbzw. denUmgangmit demSystemzuvereinfachen.Daz.Z.keinesderver-breitetenBetriebssystemedie dafur notwendigenEigenschaftenzur Verfugungstellt,wird hierfur zusatzlicheSoftware benotigt. DieseLucke zwischenAnwendungundBetriebssystemwird vondenVerteilungsplattformengeschlossen.Hierfur ist – ihrerinAbbildung2.7gezeigtenLageentsprechend– derBegriff Middlewareublich[Pop96].

(Middleware)Verteilungsplattform

Anwendung

Betriebssystem

Hardware

Abbildung2.7:EinordnungderMiddelwarein einegrobeSystemarchitektur

VerteilungsplattformenstellendiebenotigteLaufzeitumgebung(u.a.dendynamischenBinder)unddie Programmiersprachenerweiterung(Client-undServerstub)bereit.ZudiesemZweck wird eine InterfaceDefinition Language(IDL) benutzt,mit der dieSchnittstellender verteiltenKomponentendefiniert werden.Damit die derartdefi-niertenOperationenin denherkommlichenProgrammiersprachenaufgerufenwerdenkonnen,erzeugtein IDL-Compiler ausdiesenDefinitionenInclude-DateienundPro-grammcode,die in dasherkommlicheAnwendungsprogrammeingebundenwerdenunddenjeweiligenStubenthalten.DerdabeiublichegrundsatzlicheAblauf zurErzeu-gungeinerausfuhrbarenDateiist derAbbildung2.8zuentnehmen[Pop96,Red96].

IDL-Schnittstellendefinition

Client-QuelltextIDL-Compiler

Server-Quelltext

Compiler & Linker

Server-Stub

Laufzeitbibliothek

Server-ProgrammClient-Programm

Compiler & Linker

Client-Stub

Abbildung2.8:Programmerzeugungmit einerVerteilungsplattform


Der bereitsin Abschnitt2.1.3angesprocheneODP-Standardstellt lediglich ein Refe-renzmodellfur Verteilungsplattformendar, indemeralsRahmenwerkbeschreibt,wel-cheVoraussetzungengegebenseinmussenbzw. welcheHerangehensweiseneingesetztwerdensollen,um ein offenesVerteiltesSystemzu konstruieren.Eine konkreteIm-plementierungist durchODPallerdingsnicht vorgegeben[Ray94, ISO95a].Dement-sprechendexistierenverschiedeneAnsatzefur Verteilungsplattformen,die mehroderwenigerkonform zum ODP-Referenzmodellsind. Zu den wichtigstenzahlenDis-tributed ComputingEnvironment (DCE) [OSF94] der Open Software Foundation(OSF),ActiveX/DistributedComponentObjectModel (DCOM) [BK96] von Micro-softunddiverseImplementierungenderCommonObjectRequestBrokerArchitecture(CORBA) [OMG98] derObjectManagementGroup(OMG).WahrendDCE an Bedeutungverliert, weil esdasobjektorientierteParadigmanichtunterstutzt [YD96], hat Microsoft mit DCOM den DCE RPCum eine objektorien-tierte Ebeneerweitertund versuchtso, einenStandardfur die PersonalComputer-Welt zu setzen,der allerdingsnicht sehroffen ist und aufgrundseinerhistorischenEntwicklung keine saubereArchitektur besitzt [CHY+97]. Außerhalbder Micro-soft Windows-Systemesetztsich seit einigerZeit der CORBA-Standarddurch,derals offener Standardvon vielen Herstellernunterstutzt wird. Da keine Referenz-implementierungenvorgesehenist, liegen diversefreie und kommerzielleCORBA-Implementierungenfur viele verschiedeneHardwareplattformenvor. Hierdurchist esu.a.moglich, die Heterogenitatenzwischender UNIX und PC-Welt zu uberbrucken[CHY+97, YD96, Sta95,APRA98].BeispielhaftseinebendemfreienMICO [PR98]unddemweit verbreitetenVisiBroker von Inprise[Inp98] als ebenfalls weit verbrei-teteCORBA-ImplementierungOrbix [Ion97a,Ion97b] von Ionagenannt,auf derdievorliegendeArbeit basiert.Ein rechtguterUberblickzumCORBA-StandardderObjectManagementGroupwirdin [YD96] gegeben.Die 1989gegrundeteOMG ist ein Konsortiumvon mittlerwei-le fast tausendFirmen,daszum Ziel hat, verteilteobjektorientierteTechnologienzufordern,indemeinoffenerStandarddafur geschaffenwird [Sta95,APRA98,Pop96].DenelementarstenTeil derin Abbildung2.9dargestelltenObjectManagementArchi-tecture(OMA) [OMG95a], diedenOMG-Standardfur offeneobjektorientierteVertei-lungsplattformenbeschreibt,bildet die CommonObjectRequestBroker Architecture[OMG98]. WichtigsteBestandteilevonCORBA sinddieSpezifikationdesObjectRe-questBrokers(ORB),derdendynamischenBinderunddenentferntenMethodenauf-ruf realisiert,unddie Abbildungder IDL-Schnittstellenbeschreibungin verschiedenegebrauchlicheProgrammiersprachen(Language-Mappings)[Sta95,Red96].Daruber hinaussind in der OMA Object Servicesstandardisiert(CORBAservices[OMG97]). Sie bietendie Grundfunktionen,die fur die Arbeit mit verteiltenObjek-ten benotigt werden,an. So stehtfur ein kontextunabhangigesdynamischesBindender ObjectNamingServicezur Verfugung,der esermoglicht, ObjekteanhandeinessymbolischenNamensstattuberObjektreferenzenzuadressieren.WeitereFunktionenermoglichenz.B. die Migration von Objektenoder ihre persistenteSpeicherungaufDatentragern.


Die CommonFacilities,die haufig gebrauchteAnwendungsfunktionen,wie sie etwafur grafischeBenutzeroberflachenoderzur Dokumentenverwaltungbenotigt werden,bereitstellen,sindzwar standardisiert(CORBAfacilities [OMG95b]), aberbishernuroptionalin einigenOMA/CORBA2-Implementierungenvorhanden.Als weiterenBereichidentifiziertdie OMA die anwendungsspezifischenDomainIn-terfaces,dieDienstefur unterschiedlicheAnwendungsbereichewie CAD, denFinanz-sektoroderetwadenderTelekommunikationsindustriezusammenfassen.

Anwendungsobjekte

Object Request Broker (ORB)

Object Services/CORBAservices

DomainInterfaces Facilities

Common

Abbildung2.9:Die BestandteilederObjectManagementArchitecture(OMA)

Der ORB bildet die Kommunikationszentraleder OMA. Der von ihm bereitgestellteentfernteMethodenaufrufrealisiertallerdingsnichtalleKonzeptedesobjektorientier-tenParadigmas[RBP+93]. So ist esnicht erlaubt,per IDL definierteOperatorenpo-lymorphzu gestaltenbzw. zu uberladen.Die Objektubergabein AufrufparameternistnureingeschranktmoglichunddasKonzeptderObjektidentitatwurdeerstin derVer-sion2.0 desCORBA-Standardseingefuhrt. Zwar benutztderdynamischeBinderdesORB zur Objektidentifikationschonimmer eindeutigeObjektreferenzen,diesesindallerdingsnichtweltweit,sondernnur innerhalbdesORBeindeutig.Die entferntenOperationsaufrufedesORBswerdensynchronabgewickelt,wobeieineasynchroneKommunikationebenfalls uber Oneway-Operationsaufrufeper IDL de-finierbar ist. Fur eine ereignisbasierteGruppenkommunikationenreicht dies jedochnicht aus,hierfur kannder in denCORBAservicesspezifizierteEventServiceeinge-setztwerden[OMG97].Die Offenheit von CORBA wurde in der Version2.0 durchein standardisiertesIn-ternetInter-ORB-Protokoll (IIOP) hergestellt.Dadurchist esmoglich, auchmit denORBsandererAnbieterzu kommunizieren.Fur die Kommunikationmit nicht OMA-konformenSystemenstehenEnvironment-SpecificInter-ORB Protocols(ESIOPs)zu

2Da CORBA anfangsdereinzigestandardisierteBestandteilderOMA war, hatsichCORBA mitt-lerweileauchalsOberbegriff hierfur eingeburgert.


denRPCsvonDCEundDCOM zurVerfugung[Red96,Sta95,APRA98].Managementfunktionalitatensind nur in den optionalenCORBAfacilities mit einerproprietarenArchitekturvorgesehen[OMG95b, KN97]. Mittlerweile arbeitenaberdieOMG und ISO zusammen,undCORBA undODPnahernsich langsameinanderan,sodaßCORBA in einigenBereichenzudenODP-Referenzplattformenzahlt.

2.2 Dienstvermittlung

FruheVerteilteSystemesahendieAdressierungeinesProzessesdirekt uberdenRech-nernamen,auf demsich dannderentsprechendeProzeßbefindenmußte,vor. DieserAnsatzist jedochsehrunflexibel, da bereitsein RechnerwechseleineAnderungderverteiltenAnwendungnotwendigmacht[Pop96,Tan95].DementsprechendwurdenweitergehendeKonzepteentwickelt, die – aufbauendaufdemBegriff desDienstes– flexiblere Adressierungskonzeptevorsehen,uberdie esmoglichwird, Softwarekomponenten,dieunabhangigvoneinanderentwickelt wurden,zusammenarbeitenzu lassen.[Pop96,SPM94,Kel93] beschaftigensich ausfuhrlichmit demAspektderDienstvermittlungin VerteiltenSystemen.

2.2.1 Dienstein Verteilten Systemen

In [SPM94] ist ein Dienst definiert als”Funktion, die von einemObjekt an einer

Schnittstelleangebotenwird“ . Zunachsthandeltessich alsonur um einenabstrak-tenBegriff, der die von einemObjektbereitgestellteDatenverarbeitungsfunktionbe-zeichnet.Im Abschnitt2.2.3wird dasKonzeptdesDienstesallerdingsnochumeinigeBestandteileerweitert.Der UnterscheidungzwischenClient und Server entsprechendlaßt sich zwischenDienstnutzerund Diensterbringerunterscheiden.Ziel einerDienstvermittlung ist esdemnach,dasdynamischeBindenzu unterstutzen,indemfur einenDienstnutzerdergewunschteDiensterbringergefundenwird [Kov94].

2.2.2 Namensdienst

Die ersteVerbesserunggegenuber einer statischenProzeßadressierungstellen Na-mensdienstedar. Die ServerwerdenhierbeistattuberihrephysikalischeAdresseubereinenlogischenbzw. symbolischenNamenangesprochen.Unter der Voraussetzung,daßdemDienstnutzerder NamedesgewunschtenDienstesbekanntist, benotigt derClient keineweiterenInformationenuberdenServer: Ein Diensterbringerregistriertsich bei einemsystemweitverfugbarenName-Server unterAngabeseineslogischenNamensund seinerphysikalischenAdresse.Ein Client kann nun mit Hilfe deslo-gischenNamensdie physikalischeAdressedesServerprozesseserfragenundmittelsdieserAdresseuberdendynamischenBinderdengewunschtenDienstnutzen.

2.2.Dienstvermittlung 19

2.2.3 Trading

Der Ubergangvom NamensdienstzumTraderwird haufigmit demUbergangvon ei-nemTelefonbuch zu den

”GelbenSeiten“ verglichen.Wahrendbeim Namensdienst

jederDiensteineneindeutigenNamenbesitzenmuß,siehtdasKonzeptdesTradingsvor, dengewunschtenDienstuberseinenTyp undseineEigenschaftenzubeschreiben.Der Tradersuchtdannauf AnfrageeinesDienstnutzers(Importer)ausseinerDaten-bankdenDienstanbieter(Exporter)heraus,derdiegewunschtenEigenschaftenbesitztbzw. – falls mehrerepassendeDienstangeboteexistieren– denjenigen,derzusatzlichangegebeneOptimalitatskriterienambestenerfullt. Die eigentlicheDienstnutzunger-folgt im AnschlußdaranohnedenTrader, indemeineBindungzwischenDienstnutzerunddemsoebenermitteltenDienstanbieterhergestelltwird. DergenerelleAblaufeinerDienstvermittlungubereinenTraderist in Abbildung2.10dargestellt[Kov94].

Dienstanbieter Dienstnutzer

1. Export

3. Importangebot

2. Importanfrage

4. Dienstnutzung

Trader

Abbildung2.10:Ablauf derDienstvermittlungmittelseinesTraders

WahrendbeimNamensdienstNamenfur diekonkretenDienstinstanzenvergebenwer-den, sieht das Trading eindeutigeNamenfur die jeweiligen Diensttypenvor. DerDiensttyperweitertdasKonzeptdesDienstesum die Angabe,welcheFunktionalitatein Diensterbringt.Aus derAngabedesDiensttyps(z.B.

”Drucker“ ,

”Compiler“ ) er-

gibt sich auchautomatischdie Signaturbzw. SchnittstellendefinitioneinesDienstes,dafur jedenDiensttypdiezur VerfugunggestelltenOperationeneinheitlichfestgelegtsind.Nur soist einoffenerDienstmarktmoglich.UnterschiedlicheDienste des gleichen Diensttypskonnen uber Diensteigenschaf-ten (z.B.

”Papierformat“ beim

”Drucker“ -Dienst,

”Zielplattform“ beim

”Compiler“ -

Dienst) genauercharakterisiertwerden,da die alleinige AngabedesDiensttypsofteinezu grobeGranularitat aufweist.Jenachdem,ob die Diensteigenschaftverander-lich (z.B.

”Druckerwarteschlangenlange“ ) oderunveranderlich(z.B.

”Papierformat“ )

ist, wird zwischendynamischenundstatischenAttributenunterschieden.Die ErmittlungdynamischerDienstattributeerfordertspezielleKonzepte,um siemitmoglichstgeringemKommunikationsaufwandim Traderaktuellzuhalten.Grundsatz-lich kannhierbeizwischenPolling,beidemderTraderdiedynamischenAttributederin FragekommendenDienstebei jederImportanfrageermittelt,undCaching,beidemdieexportierendenDienstejedeAttributanderungdemTradermitteilen,unterschieden


werden.Der Ablauf beiderVerfahrenist Abbildung 2.11 zu sehen.Je nachSzena-rio (haufigeImportanfragenbeiseltenenAttributanderungenim GegensatzzuseltenenImportanfragenbeihaufigenAttributanderungen)sinddieseVerfahrenunterschiedlichgutgeeignet,wobeiauchhybrideVerfahrenmoglichsind[Kov94, Kup95].

Trader1.

2.

Trader

2.3.

4.

1.

Dienstnutzer

Dienstanbieter

Dienstanbieter

Dienstanbieter

Dienstanbieter

Dienstanbieter

Dienstanbieter

Dienstnutzer

Polling

Caching

Abbildung2.11:AnfragereihenfolgebeiderAktualisierungdynamischerAttribute

Zur weiterenStrukturierungder in der TraderdatenbankregistriertenDienstangebo-te sind in vielen TradernTradingkontexte (Dienst-Directories)vorgesehen.AhnlicheinemVerzeichnisbaumin einemDateisystemkonnenhierin Diensteunter admini-strativenGesichtspunkteneingetragenwerden.Haufigist auchdie Zusammenarbeitvon mehrerenTradern,die jeweils fur einenBe-reich (Domane)zustandig sind, moglich. Das Konzeptder Trader-Foderationsiehtvor, daßein TraderImport-Anfragenan andereTraderweiterreicht.Hierdurchwirddie Mengeder Dienste,die ein einzelnerTradervermittelnkann,vergoßert,da nunzusatzlichdasAngebotderanderenTraderebenfallszurVerfugungsteht.Die genaue-ren Umstandeder ZusammenarbeitzwischendenTradernwerdenuberFoderations-vertragegeregelt. Auf den Aspekt der Zusammenarbeitvon Tradernwird in dieserArbeit jedochnichtweitereingegangen.Im BereichdesTradinghatderODP-Trading-Standard[ISO96] einegroßeBedeutung.Er umfaßtalle obenbeschriebenenTrading-Konzepteunddefiniertu.a.eineTrading-Schnittstellemit FunktionenzumIm- undExportvon Diensten.Die OMG hateben-fallseinenTradingdiensteingefuhrt.DieserwurdeinnerhalbderCORBAservicesstan-dardisiert[OMG97] undbeinhaltetetdiewichtigstenPunktedesODP-Tradings.

2.3.Lastverteilung 21

2.3 Lastverteilung

Ein schonrechtfruh eingesetztesKonzeptzur schnellerenBearbeitungvonAufgabenin VerteiltenSystemenstellt die Lastverteilungdar. Wahrenddie Anfangein derVer-teilung (Scheduling)von Batch-Auftragenin Time-Sharing-Systemen[SG94] liegenundsichuberdieAnwendungbeiParallelrechnernweiterentwickelt haben,ist derEin-satzin heterogenenVerteiltenSystemeneineaktuelleThematik.SobeschaftigensichzahlreicheneuereArbeiten[Sch97a,SB97, Sch96a,Sch96b,Kov94, KRK94, Die97]mit diesemGebiet,dennochsinddie alterenArtikel [WM85, ELZ86, MTS89] immernochvongrundlegenderBedeutung.Prinzipiell hat die Lastverteilungzum Ziel, alle zur VerfugungstehendenRessour-cengleichmaßigzunutzen,indemzubearbeitendeAufgabenauf ungenutztebzw. nurschwachbelasteteRessourcenverteilt und dort parallelabgearbeitetwerden.Hierfurwird eine Instanz,der Lastverteiler (Load Balancer),benotigt, der dieseVerteilunganhandeinerLastverteilungsstrategiekoordiniert.EineoptimaleLosungdesLastverteilungsproblemsminimiertdiemittlereAntwortzeitfur diezubearbeitendenAuftrage.SolcheineLosungist allerdingsnurdannmoglich,wennsowohl die Laufzeitder einzelnenAnfragenals auchdie MengederAnfragenvorherbekanntsind, was in der Praxisseltender Fall ist. Daruberhinausist diesesProblemNP-vollstandig.In realenSystemenkonnenVerteilungsstrategiendeshalbnureineNaherungderoptimalenLosungbieten.Untersuchungenhabenaberergeben,daßbereitseinfacheVerfahreneineguteNaherungerreichenkonnen[ELZ86].Bei eineminhomogenenSystem,dasausunterschiedlichleistungsstarken Rechner-knotenbesteht,kannsich dasZiel, einemoglichstgleichmaßigeVerteilungder Ge-samtlastzu erreichenundeinemoglichstkurzeAntwortzeit fur jedeneinzelnenAuf-tragzugarantieren,durchausunterscheiden.Sosorgt dieZuweisungeinerAufgabeaneinenleistungsschwachenRechnerknotenzwar fur einebessereNutzungdesGesamt-systems,dieBearbeitungszeitfur dieseneinzelnenAuftragliegt dafur allerdingshoherundtreibtsomitim Extremfall auchdieuberalleAuftragegemitteltedurchschnittlicheAntwortzeitin dieHohe.Damit in einemVerteiltenSystemuberhaupteineLastverteilungmoglich ist, mußeinDienst von mehrerenServern gleichzeitigangebotenwerden.Falls hierfur mehrereInstanzendesselbenServersbenutztwerden,wird vonServer-Replikationgesprochen.

2.3.1 Last in Verteilten Systemen

In einemVerteiltenSystemumfaßtderBegriff Lasthauptsachlichzwei Aspekte:Ne-bender reinenCPU-Lastist auchdie Netzlast,die beispielsweisedurchdie Prozeß-kommunikationverursachtwird, von großerBedeutung.Falls esum die NutzungvonPeripheriegeratengeht,kannaberdaruberhinausauchdie Betrachungihrer Belastungvon Interessesein.Fur die Beurteilungvon Last wird eine Metrik benotigt, die geeignetist, die Bela-stungeinesSystemszu beschreiben.Ein objektiver Lastbegriff kannbei der Model-


lierung von Rechensystemendurch Warteschlangenmodellegewonnenwerden.DiewichtigstendabeibenotigtenBegriffe sollenim folgendenkurzvorgestelltwerden.Ei-neausfuhrlichereEinfuhrungin die modellbasierteLeistungsbewertungvon Rechen-systemenfindetsichin [Hav98,Bol89, SF94].Die Bearbeitungvon AuftragendurcheinenRechnerknotenlaßtsich – entsprechendAbbildung2.12– uberein Warteschlangenmodellanalysieren.Die BearbeitungeinesAuftragserfolgt durcheinenServer, der dafur die Bedienzeit

��benotigt. Alle wei-

terenAuftrage,die in dieserZeit eintreffen, reihensich in die Warteschlangeein undverbringendorteineentsprechendeWartezeit.AusderSummedieserbeidenZeitener-gibt sichdieAntwortzeiteinesAuftrags.Die Zeit, diezwischendemEintreffenzweierAuftragevergeht,wird alsZwischenankunftszeit

��bezeichnet.

ServerWarteschlange

Antwortzeit

Auftrag

WartezeitBedienzeit

Zwischenankunftszeit

Abbildung2.12:Ein einfachesWarteschlangenmodell

Die Last � ist uberVerhaltnis zwischender Zeit, die der Server beschaftigt ist, undderGesamtzeitdefiniert.Fur dasobenebeschriebeneWarteschlangensystemberechnetsichdie Auslastungausder uberalle AuftragegemitteltenBedien-undZwischenan-kunftszeit:

�� Soll nicht die Last eineseinzelnenServers,sonderneinesGesamtsystemsbetrachtetwerden,bietetessichan,stattmit mittlererBedien-undZwischenankunftszeit

��bzw.��

mit denjeweils reziproken Bedienraten� �� und der Ankunftsrate�� zurechnen:

�� Fur ein stabilesSystemliegt � zwischen0 und 1. Bei �� ist ein Systemuberla-stet.EinesolcheUberlastkannnur durchzusatzlichebzw. schnellereServer behobenwerden.Dochauchbei � !� konnenin einemzeitlichbegrenztenFenstertemporareUberlast-situationenauftreten.Dies ist dannderFall, wennsichAuftragein derWarteschlan-gestauenunddieserStauerstin einerUnterlastsituationabgebautwerdenkann.Die


Wahrscheinlichkeit fur solcheStauswachstmit steigenderLast,sodaßdanndie mitt-lereAntwortzeitentsprechendansteigt.Abbildung2.13stellt die theoretischenWertefur eineneinzelnenServer sowie ein Systemmit 4 Servern dar. Die beidenSyste-mewurdendazudurcheineM/M/1 undeineM/M/4-Warteschlangemodelliert.DiesebeidenWarteschlangenmodellecharakterisierenein Systemmit 1 bzw. 4 Servern,dieexponentiellverteilteBedienzeitenhaben,wobei die Zwischenankunftszeitebenfallsexponentiellverteilt ist. Die ExponentialverteilungbeschreibteinenAnkunfts- bzw.Bedienprozeß,bei demkurzeZwischenankunfts-undBedienzeitenwahrscheinlichersindalslangeZwischenankunfts-undBedienzeiten.DadieExponentialverteilungdieEigenschaftder Gedachtnislosigkeit besitzt, ist dafur gesorgt, daßein Ereignisun-abhangigvonallenvorherigenEreignisseneintrifft. Fur dieBetrachtungeinesServersbedeutetdies,daßausderBeobachtungderzuruckliegendenZwischenankunftszeitenkeineAussageuberzukunftigeAuftragseingangegetroffenwerdenkann.

0

1

2

3

4

5

6

7

8

9

10

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

"

Last

M/M/1 bei Bedienzeit 1sM/M/4 bei Bedienzeit 1s

Abbildung2.13:Mittlere Antwortzeitenin Abhangigkeit von derLastbei einemein-zelnemServer undbei4 Servern(Bedienzeitjeweils1s)

Die abgebildetenWertestellendie theoretischenSchranken fur Lastverteilungsstra-tegien dar. Eine optimaleStrategie kannbei # Servern nicht bessersein,als daszu-gehorigeM/M/ # -System,dasbereitseineoptimaleVerteilungsstrategiebeinhaltet.EinM/M/1-System,bei dem lediglich ein Server genutztwird, stellt entsprechenddieWorst-Case-Schranke dar.


2.3.2 StatischeLastverteilung

Die einfachsteFormderLastverteilungstellenstatischeVerteilungsverfahrendar. Ein-gehendeAuftragewerdenhierbeinacheinemfestenSchemaaufdie jeweiligenSerververteilt.In derenglischenLiteraturwird hierfur i.d.R.derBegriff

”LoadSharing“ ver-

wendet.NebendeterministischenVerfahren,wie z.B.zyklischeZuweisung,beiderdieLastderReihenachauf alle Server verteilt wird, gehort aucheinezufallige (probabilistische)VerteilungaufdieeinzelnenServerzudenstatischenLastbalancierungsverfahren.StatischeVerfahrenhabengemein,daßsiezwar einfachundeffizientzu implementie-rensind,sichabernicht auf die jeweils vorliegendeSituationeinstellenkonnen.DieresultierendeLastverteilungist daherspeziellin VerteiltenSystemenmit inhomogenerRechenleistungungenugend.

2.3.3 DynamischeLastverteilung

DynamischeLastverteilungsstrategienliefernbessereErgebnissealsstatischeVerfah-ren,dasiesichauf die jeweiligenSituationeneinstellenkonnen.Im Englischenwirdfur solcheadaptivenVerfahrenmeistderBegriff

”LoadBalancing“ verwendet.

Zur AnpassungandenjeweiligenSystemzustandbenotigendynamischeVerfahrenIn-formationen,die Ruckschlusseuberdie LastandenverschiedenenKomponentendesSystemszulassen.Auf der Grenzezwischenstatischenund dynamischenVerfahrenliegendiegedachtnisbehaftetenStrategien,diezwardieZahlderzuruckliegendenSer-vernutzungenberucksichtigen,aberansonstenuberkeinerleiRuckmeldungvon denServernverfugen.Die weitergehendendynamischenStrategien messenperMonitoring die Last an denjeweiligenServernundbeziehendiesein dieweiterenVerteilungsentscheidungenein.Bei denQuell-initiiertenVerfahrenkommt ein zentraleroder– um Engpassezu ver-meiden– ein auf jedemClient-KnotenreplizierterLoad Balancerzum Einsatz,deranhandder gesammeltenLastinformationendie eintreffendenAnfragendesClientsaufdie in FragekommendenSerververteilt.Bei Server-initiierten Verfahrenmeldetsichein Server beimLoadBalancer, wennerseineLast als niedrig einstuft,und holt von der beim Load BalancerentstehendenWarteschlangediezubearbeitendenAnfragenab.Beim Entwurf einerLastverteilungsstrategie mußberucksichtigtwerden,daßdie imLoad BalancergespeichertenMeßwerte,auf denendynamischeStrategien beruhen,nurdie Vergangenheitwiederspiegelnkonnenunddemnachveraltetsind.Als Abhilfewareesdenkbar, dieseDatensehrhaufig an denLoad Balancerzu ubermitteln,umsiedort wenigstensmoglichstaktuellzu halten.Dies fuhrt jedochzu einemerhohtenKommunikationsaufkommen,wodurchder Load BalancerEinfluß auf die Netzlastnimmt. Der notige KompromißzwischenAktualitat und KommunikationsoverheadkanndurchdieVerwendungeinergeeignetenLastmetrikentscharft werden.Nebenderin Abschnitt2.3.1vorgestelltenabsolutenMetrik derLast,sindin derPraxis


weitere,relative Metrikenublich [WM85, Sch96a,Sch96b].GebrauchlicheMetrikensindhierbeivor allemdie Warteschlangenlange,die Antwortzeitoderdie BedienrateeinesServers.Metriken,dieauf derWarteschlangenlangeberuhen,habendenVorteil,daßsienichtnurdieVergangenheitbeschreiben.DasiedieerstnochzubearbeitendenAuftrageder Warteschlangeberucksichtigen,konnensie ein wenig

”in die Zukunft“

blicken.Die absoluteMetrik derLasthingegenbasiertdefinitionsgemaßaufMeßwer-ten,die ubereinzuruckliegendesZeitintervall gemitteltwerden.Fur die Optimierungbezuglich derNetzlastkommtnebender reinenNetzwerkausla-stungbeispielsweisenochdie UbertragungsratedesNetzwerksegmentszwischenCli-entundServer– beiWeitverkehrsnetzenauchnochderenDistanz– in Betracht.FastalleLastverteilungsstrategienapproximierendieLosungdesVerteilungsproblemsanhandeinerGreedy-Heuristik,dieankommendeAuftrageandenServer mit dermo-mentankleinstenLastweiterleitet.Soverwendetdie haufigeingesetzteJoin-Shortest-Queue-StrategiedieWarteschlangenlangealsMetrik undwahltentsprechenddenSer-ver mit derkurzestenWarteschlangenlangeaus.EineVariantedavon betrachtetdabeinichtalle Server, sondernnur einigezufallig ausgewahlteServer, sodaßnicht fur alleServerdieenstprechendeLastinformationeingeholtwerdenmuß.Falls die Bediendauerder einzelnenAuftrage von vornehereinbekanntist, kannbei Server-initiierten Strategien daruberhinausvon der ublichen First-Come-First-Served-Abarbeitungder Warteschlangeabgewichen werden.Stattdessenbietet sicheineShortest-Job-First-Abarbeitungsstrategie an,durchdie – unabhangigvon derei-gentlichenLastverteilung– die mittlereAntwortzeitder in derWarteschlangebefind-lichenAnfragenverringertwird.

Kapitel 3

Optimierung der Dienstauswahldurch Lastbalancierung

In diesemKapitelerfolgteineVorstellungvonKonzeptenfur eineverbesserteDienst-auswahl durchBerucksichtigungderbei denjeweiligenDienstanbieternvorliegendenLast. EntsprechenddenZielen der LastverteilungsollendadurchLeistungsengpassebei der Dienstausfuhrungvermiedenwerden,indembeim TradingnachMoglichkeitnursolcheDienstangebotevermitteltwerden,diezudiesemZeitpunktwenigausgela-stetsind.NachdereinfuhrendenBehandlungexistierenderArbeitenzu dieserThematiksowiedenzugrundeliegendenGebietendesTradingsundderLastverteilungwerdenweiter-gehendeVerbesserungsmoglichkeitenfur einenTrader, derbei derDienstvermittlungdie Serverlastberucksichtigt,aufgezeigt.HierausergebensicheinigeAnforderungenaneinenverbessertenEntwurf,dieim Anschlußdaranvorgestelltwerden.BevordieimnachstenKapitelbeschriebeneRealisierungeinesverbessertenTradingsystemsvorge-nommenwerdenkann,sindnocheineReihevon Entwurfsentscheidungenzu treffen.DieseEntscheidungenunddasdurchsie festgelegteSzenarioerganzendie Anforde-rungsbeschreibung.ZumSchlußwird einkurzerUberblickuberdie in diesemKapitelvorgestelltenAnsatzegegeben.

3.1 Arbeiten im Umfeld Trading

ZunachstsolleneinigeTrader-Projektevorgestelltwerden.DieseArbeitenberucksich-tigenzwarbeiderDienstvermittlungnichtexplizit dieLastdereinzelnenDienstanbie-ter, sie bilden jedochmit ihren Konzeptenzur Dienstvermittlungdie Grundlagefurdie vorliegendeArbeit, weshalbim folgendenauf sie eingangenwird. Ein besonde-resAugenmerkwird dabeiauf die dynamischenDienstattributegerichtet,dasieeinewichtigeGrundlagezur Einbeziehungder sich standiganderndenLastaspektein dieDienstvermittlungdarstellen.Es existieren zahlreicheKonzeptebzw. Implementierungenzur Dienstvermittlung

28 3. OptimierungderDienstauswahldurchLastbalancierung

mittels einesTraders[Kel93]. Als bedeutendsterStandardist hierbei der im ODP-ReferenzmodelldefinierteODP-Trader[ISO96] zu nennen.Die wichtigstendortdefi-niertenFunktionalitatenwurdenbereitsin Abschnitt2.2.3beschrieben.HierzugehortinsbesonderedieUnterstutzungvonstatischenunddynamischenDienstattributen.Der in den CORBAservices [OMG97] vorgeseheneTrader wurde weitestge-hend in Einklang mit dem ODP Trading-Modell spezifiziert. Dementsprechendsind auch hier feste und veranderlicheDiensteigenschaftenvorgesehen.Die Un-terstutzungvon dynamischenDienstattributenist allerdingsdenjeweiligenCORBA-Traderimplementierungenfreigestellt,sodaßerstzur LaufzeitdurchNachfragebeimjeweiligenTraderermitteltwerdenkann,obdieseFunktionalitatangebotenwird.Die Aktualisierungvon veranderlichenDiensteigenschaftenkannsowohl perPollingals auchuberCachingdurchgefuhrt werden.Die Festlegungauf einedieserbeidenAktualisierungsstrategien obliegt den Dienstexportern,wobei auchhier dem Traderfreigestelltist, nureinedieserStrategienzuunterstutzen.Fur Attribute, die per Pollingstrategie aktualisiertwerden,verwendetdie OMG denBegriff

”Dynamic Properties“ . Zur Realisierungder Pollingfunktionalitat muß ein

Dienstanbieterbeim Dienstexport eineSchnittstellebekanntgeben,uberdie der Tra-der spater den Wert der jeweiligen Diensteigenschaftabfragenkann.

”Modifiable

Properties“ bezeichnendynamischeAttribute, die per Cachingaktualisiertwerden.Diesgeschieht,indemein DienstanbieterbeimTradereineentsprechende

”Modify“ -

Operationaufruft.Mittlerweile liegenfur einigekommerzielleundfreie CORBA-SystemeTraderimple-mentierungenvor [APRA98]. Beispielhaftseihier derOrbixTradervon Iona[Ion98]genannt.Dieserwurdeam australischenCentrefor DistributedSystemsTechnology(DSTC)entwickelt. Er unterstutztstatischeunddynamischeDiensteigenschaften,wo-beibeimPollingzurGeschwindigkeitsteigerungparalleleAnfragenbeideneinzelnenDienstanbieterneingesetztwerdenkonnen.Im folgendenwird aufdenTrader, deramLehrstuhlfur InformatikIV entwickelt wur-de,eingegangen.Da fur diesenderQuellcodekomplettvorliegt, bieteter sichfur diein dieserArbeit vorgeseheneTrader-Erweiterungan.Dieser Trader basiert auf einem fruhen Entwurf der ODP-Trader-Spezifikation[ISO94]. Er wurdein einerReihevon Diplomarbeitenerstelltbzw. weiterentwickeltundsetztauf Orbix 2.x unddemBetriebssystemSolaris[GGM93] von SUN auf.DieersteImplementierung[Zla96] bot zunachstnur die Grundfunktionenzum Im- undExport von Diensten.Zur StrukturierungdesDienstangebotskonnenentsprechendder fruherenODP-SpezifikationTradingkontexte benutztwerden.Mit [Sch97b]wur-dedie Implementierungum die UnterstutzungvonTrader-Foderationenerweitertundbezuglich der dabeierzielbarenLeistungssteigerungdurch Cachinguntersucht.Ei-neintensivereBeschaftigungmit dynamischenDiensteigenschaftenfindetin [Kup95]statt.Dort wird beispielhafteinesehreinfacheLastbalancierunganhandvon dynami-schenAttributenrealisiert.[Thi96] behandeltdie OptimierungderDienstauswahl beimehreren,dieDienstgutebeschreibendenAttributen.EineeingehendeAnalysederbeiderDienstvermittlungauftretendenKommunikationslastwird in [Hei95] gegeben.

3.2.Arbeitenim UmfeldLastbalancierung 29

3.2 Arbeiten im Umfeld Lastbalancierung

Bevor im nachstenAbschnittauf die Kombinationvon TradingundLastbalancierungeingegangenwird, werdenhiervon losgelostzunachsteinigegrundsatzlicheAbhand-lungendesThemasLastbalancierungbetrachtet.Zu den grundlegendenArbeiten sind [WM85, ELZ86, MTS89] zu zahlen,sie be-schaftigensich jedochnur mit homogenenVerteiltenSystemen.[WM85] vergleichtanhandvonmathematischenUberlegungenundSimulationenverschiedeneStrategienbzw. Scheduling-Algorithmenzur Lastverteilungundgibt dabeidenServer-initiiertenVerfahrendenVorzug.[ELZ86] kommt mit ahnlichenBetrachtungenzu der Aussa-ge,daßeinfacheStrategien,diewenigKommunikationsaufwanderfordern,ambestengeeignetsind.Hierbeiwird Schwellwert-basiertenVerfahren,bei denenzufallig aus-gewahltenServern solangeAuftragezugeteiltwerden,bis ihre Last einenbestimm-tenSchwellwert uberschreitet,derVorzuggegeben.EineZusammenfassungdieserEr-gebnissefuhrt zu der Gating-Technik,bei der durchzwei Schwellwerteein Korridordefiniertwird, innerhalbdessendie Last einerRessourceoptimal genutztwird. BeiUnterschreitungdesunterenSchwellwertsmeldetsich der Server bei der Lastvertei-lungskomponente,bei UberschreitungdesoberenSchwellwertswerdenvom ServerselberkeineweiterenAuftragemehrangenommen.[MTS89] weist allerdingsnach,daßdiesbeiLastinformationen,derenAlter uberderAusfuhrungszeitderbearbeitetenAuftrageliegt, nichtmehreffektiv ist.KomplexereStrategien wurdenin jungererZeit ebenfalls erortert.So sieht[KRK94]einNeuronalesNetzfur einen

”lernenden“ LoadBalancervor, um Ausfuhrungszeiten

anhandvon vergangenenBediendauernim vorauszu schatzen.In [Die97] wird einauf der Fuzzy-EntscheidungstheoriebasierenderLoad Balancervorgestellt,der an-handvon Fuzzy-Regeln diejenigeLastverteilungsstragieauswahlt, die am bestenfurdie jeweiligeSituationgeeignetzuseinscheint.DiesekomplexenAlgorithmenwider-sprechenjedochder in denalterenArbeitenaufgestelltenThesevon der Einfachheitder Strategien, was in der neuerenArbeit [GLL96] nochmalsbekraftigt wird. Auch[Del97] kommt durch Simulationenzu dem Schluß,daßWissenuber die Ausfuh-rungszeitender Auftragekeinebzw. nur eineminimaleVerbesserunggegenuberdereinfachenEntscheidunganhandder aktuell an deneinzelnenRechnerknotenvorlie-gendenLastbringt.UberKonzeptezur Ermittlungder Last machendie zitiertenArtikel keineAngaben.Hierfur sindArbeiten,die sichmit Leistungsmonitoringbeschaftigen,heranzuziehen.So beschaftigt sich [CPRV96] beispielsweisemit der Implementierungeiner Platt-form fur LeistungsmanagementunddemzugrundeliegendenMonitoringsystem.DiesePlattformbasiertauf auf demOSI-Managementmodellundbeziehtsichdementspre-chendhauptsachlichauf die Netzwerkebene.[BU96] stellt ein Konzeptfur dasMoni-toringvonCORBA-Systemenim RahmendesMAScOTTE-Projektsvor. Die Autorengebendabeiu.a.Vorschlagefur Managementinformationen,die fur ein Leistungsmo-nitoring von CORBA-Anwendungennutzlich sind. In diesenbeidenArbeiten wirdjedochnichtaufdenAspektderLastverteilungeingegangen.


Die Diplomarbeit[Sem97]realisierteinedynamischeLastverteilungfur einCORBA-System.Hierzu wird zu den vorhandenServern und Clients eine zentraleMana-gementkomponente,sowie pro Server-Rechnerknotenein Monitor und pro Client-RechnerknoteneineLastverteilungskomponentehinzugefugt. In Abbildung3.1ist diegrobeArchitektur sowie der Kommunikationsflußzwischenden Komponentendesdort realisiertenAnsatzesdargestellt.3

Monitoring-

Load Balancer

ClientClient

Monitor

Server

Manager

* *Client-Knoten

Monitoring

InitialisierungInitialisierungMonitoring-Daten

ServerauswahlDaten

Server-Knoten

Servernutzung

Manager-Knoten

Registrierung

Abbildung3.1:Verteilungsdiagrammdesin [Sem97] realisiertenAnsatzes

Die Ermittlung der Last erfolgt durchMeßanfragen,die ein Monitor an denlokalenServer schickt.Aus derZeitspanne,die der Server zur BeantwortungdieserAnfragebenotigt, wird aufdessenBelastunggeschlossen.Bei dieserArbeit werdenAspektederDienstauswahlnichtberucksichtigt,dadieLastvon lediglich einemeinzelnenDienstdurchReplikationauf mehreregleicheServer-objekteverteilt wird. Da aberauchhierzuderQuellcodeamLehrstuhlvorliegt, wareesdenkbar, Konzeptehierausin denbereitserwahntenAachenerTradereinfließenzulassen.

3.3 BestehendeAnsatzeder Dienstvermittlungunter demAspekt der Lastbalancierung

Obwohl sowohl Trading als auchLastbalancierungimmer noch ein aktuellesFor-schungsthemaim Bereichder VerteiltenSystemedarstellen,gibt esnur wenigeAr-beiten,diesichmit einerZusammenfuhrungdieserbeidenBereichebeschaftigen.DieOptimierungder DienstvermittlungdurchAuswahl von moglichst wenig belastetenDienstangebotenversprichteineSenkungderdurchschnittlichenDienstbearbeitungs-zeitundist somitgeeignet,dieAuswirkungtemporarerLeistungsengpassezumildern.

3Hierfur undfur diefolgendenVerteilungsdiagrammewird dieNotationderUnifiedModellingLan-guage(UML)verwendet.PotentiellmehrfachvorhandeneBestandteilewerdendabeimit einem

”*“ ge-

kennzeichnet.

3.3.BestehendeAnsatzederDienstvermittlungunterdemAspektderLast 31

EineLiteraturstudielieferteim wesentlichendie im folgendenvorgestelltenProjekte,diesichmit diesemGebietbeschaftigen.Als einetheoretischeGrundlagekonnendie Untersuchungenin [MP93, WT93] die-nen.Die dortdurchgefuhrtenSimulationenbestatigenim wesentlichendieErgebnissederfruhenArbeitenzumThemaLastverteilung.In beidenArbeitenwird mit demKon-zepteiner

”sozialen“ Dienstauswahlstrategie gearbeitet,bei der wahrendder Dienst-

auswahl globaleAspekteberucksichtigtwerden.Eine”soziale“ Dienstauswahlstrate-

gie garantiertnicht jedemeinzelnenDienstnutzereine optimaleAuswahl, vielmehrwird versucht,die Optimalitatsbedingungbezuglich desGesamtsystemseinzuhalten.Fur die Lastverteilungwurdediesbedeuten,daßeinemClient ein langsamerServerzugewiesenwird, wenndadurchdie durchschnittlicheAntwortzeit insgesamtgesenktwerdenkann.[WT93] weistauchauf die GefahreinerzwischendenServernoszillierendenUberla-stunghin, diedadurchzustandekommenkann,daßeinbesonderswenigausgelasteterServervoneinemzentralenTraderalleAuftragezugewiesenbekommt,wasbeidiesemServer wiederumzu einerbesondershohenLastfuhrt.Die dadurchentlastetenServerwerdendaraufhinim nachstenSchritt wiederbesondersstarkbelastet.DieseGefahrsteigtmit demAlter der verwendetenLastinformationen.Zur Losungwerdendyna-mischeVerteilungstrategien,die zusatzlich um eineZufallskomponenteangereichertsind,vorgeschlagen.Ein besondererSchwerpunktwird in [WT93] auf die VerwendungvonWissengelegt,daseinTraderaufgrundfruhererVermittlungenuberdieAuslastungeinesServersbe-sitzt.Fur diesenFall wird nachgewiesen,daßsicheinelediglichdiesberucksichtigen-dezyklischeZuweisunginnerhalbderin FragekommendenDienstangeboteundeineLastbalancierung,die auf Leistungsmonitoringbasiert,in ihrer Qualitat nicht wesent-lich unterscheiden.DieseSimulationberuhtjedochaufderAnnahme,daßdieBearbei-tungszeitderjeweilsvermitteltenDiensteim vorhineinbekanntbzw. immergleichist,sodaßzu jedemZeitpunktbestimmtwerdenkann,welcherServeralsnachsteswiederfrei wird. Ein Ausblick,wie dieseZeitenin derPraxisermitteltwerdenkonnten,wirdallerdingsnichtgegeben.DiegleicheArbeitbetrachtetauchdasSzenariokonkurrierenderTrader, wie esz.B.beiTrader-Foderationenvorliegt. EswurdederFall untersucht,daßjedereinzelneTradernurdasWissenuberdievonihm vermitteltenDienstebesitzt,wodurchsichdieglobaleLeistungderVerteilungsstrategienentsprechendverschlechtert.NebendiesentheoretischenArbeiten,derenErgebnisseaufSimulationenberuhen,gibtes einige konkreteImplementierungenvon speziellenDienstvermittlungsarchitektu-ren, die Lastaspektemit einbeziehen.Im wesentlichensind dasdie beidenProjekteMELODY undLYDIA, die in denfolgendenAbschnitten3.3.1und3.3.2vorgestelltwerden.Außer derart spezialisiertenAnsatzenkonnenaber auch herkommliche Dienstver-mittlungssrchitekturenansatzweisezur Lastverteilungverwendetwerden.Falls einDienstanbieterLastinformationenalsdynamischesAttribut zur Verfugungstellt,kannein TraderanhanddesseneineLastverteilungvornehmen.Iona schlagt dies fur sei-


nenOrbixTradervor, indembei der Dienstauswahl bezuglich desLastattributs opti-miert wird [Ion98]. Fur die neuesteOrbix-Version3.0 wird außerdemeineauf demNamensdienstOrbixNamesbasierendeLastbalancierungin Aussichtgestellt.Hierzusoll es moglich sein,zu balancierendeServer durch Klassenbildungzu gruppieren.Daruber, obeinestatischeoderdynamischeLastverteilungvorgenommenwird, liegenkeineInformationenvor.

3.3.1 MELOD Y

Dasan der Universitat StuttgartbeheimateteProjektMELODY (ManagementEnvi-ronmentfor LargeOpenDistributedSystems)beschaftigt sichschwerpunktmaßigmitderDienstvermittlungunddemManagementVerteilterSystemesowie derenZusam-menarbeit,da sich wesentlicheTeile ihrer Funktionalitatenerganzen.Eine ausfuhr-liche Beschreibung desProjektsfindet sich in [KB95]. SpeziellereAspektewerdenbeispielsweisein [Kel93,Kov94, Kov96] behandelt.Die ArchitektursiehteineHierarchievonTraderundManagementsystemvor, beidemder Traderauf einemManagementsystemaufsetztund dessenFunktionennutzt,umz.B. dynamischeAttributeoderdie LasteinesDienstanbieterszu ermitteln.Die Ver-knupfung zwischenTrading und Managementerfolgt im MELODY-System,indemdynamischeDienstattributeaufManagementattributeabgebildetwerden.DasManagenementsystembestehtauseinemManagement-Agenten(MMA) proKno-ten,beidemsichdielokalenKomponentenanmeldenkonnen.DasMonitoringerfolgt,indemdie lokalenKomponentenihre ManagementinformationendemManagement-Agentenzur Verfugungstellen.Von diesemkonnensieauchglobaleManagementin-formationenabrufen.Zu diesemZweck kommunizierendie einzelnenManagement-Agentenuntereinander. Zur ErmittlungdynamischerAttributearbeitetderTradermitdenManagement-Agentenzusammen,indemer anhandderAbbildungvon Dienstat-tributenauf Managementattribute,die ein DienstanbieterbeimExportangebenmuß,dieaktuellenAttributwerteerfragt.Die VerteilungundZusammenarbeitdereinzelnenMELODY-Komponentenist in Abbildung3.2zusehen.

Client

MMA

Trader-Knoten*Trader

*Server-Knoten

übermitteln

MMA

ServerDienstexport

import

Servernutzung

Austausch vonManagementinformationen

Dienst-

Client-Knoten

Managementinfor-mationen erfragen

Monitordaten

MMA=Management-Agent

Abbildung3.2:VerteilungsdiagrammdesMELODY-Systems

3.3.BestehendeAnsatzederDienstvermittlungunterdemAspektderLast 33

DasSystemstehtzur Zeit unterdemBetriebssystemUnix fur die Verteilungsplattfor-menDCEundCORBA zur Verfugung.Zur ErmittlungdynamischerAttributekonnenverschiedeneStrategien zum Einsatzkommen:Nebensynchronenund asynchronenZugriffen kann der Trader zur weiterenGeschwindigkeitssteigerungdie einzelnenZugriffe auf mehrereparallel laufendeThreadsverteilen.Daruberhinaussieht dasManagementsystemeine dynamischeUmschaltungzwischenCachingund Polling-Strategien vor. Die Umschaltentscheidungerfolgt aufgrundder Abfrage-und Ande-rungshaufigkeitenderdynamischenAttribute(vgl. Abschnitt2.2.3).Anhandvon komplexenAuswahl- und Optimierungskriterienbei der Dienstauswahlist esmoglich,eineLastverteilungvorzunehmen.Die hierfur notigeAngabevon Ge-wichtungsfaktorenist allerdingsnichtstandardkonform.Zur LastbalancierungkonnendynamischeAttribute,welchedie Serverauslastungcharakterisieren,verwendetwer-den. Diesewerdenvom Managementsystementwederimplizit, z.B. ausder CPU-AuslastungeinesRechnerknotens,oderexplizit, z.B. uberein Warteschlangenlangen-Attribut desServers,ermittelt.Ein speziellesKonzeptder Ressourcenreservierungerlaubtdem Trader, mit einemDienstanbieterin Verhandlungzu treten,um dessenRessourcenfur einengewissenZeitraumzu reservieren,so daß einem DienstnutzerwahrenddieserZeit eine be-stimmteDienstqualitat garantiertwerdenkann.Auch diesesKonzeptgeht uberdenODP-Tradingstandardhinaus.

3.3.2 LYDIA

DasESPRIT-ProjektLYDIA befaßtsichmit Lastverteilungin ParallelenundVerteil-ten Systemen.Die wesentlichenArbeiten,die sich dabeimit der LastverteilungvonDienstenin heterogenenVerteiltenSystemenbefassen,stammenvonBjornSchiemannausderForschungs-undEntwicklungsabteilungderSiemensAG. Als Beispielanwen-dungdienenTransaktionssystemefur Datenbanken.In [Sch96b]wird einedetaillierteBeschreibung diesesKonzeptsgegeben,[Sch96a]stellt eineKurzfassungdieserBe-schreibungdar. NeuereErgebnissesindin [Sch97a, SB97]zufinden.SchiemannsiehteinenahtloseIntegrationder Lastverteilungfur Verteilungsplattfor-men,die eineInterfaceDefinition Languagezur Beschreibungvon Schnittstellenver-wenden,vor. Dazuwird derStub,derautomatischausderIDL-Beschreibungerzeugtwird, umeineMonitor- bzw. Sensorkomponenteerweitert.Die dorterfaßtenLastinfor-mationenwerdenaneinenLoadBalancerweitergeleitet,dervoneinemNamensdienstbei der Dienstvermittlungbefragtwird, um einenoptimalenDienstanbieterheraus-zusuchen.Hierin liegt eineSchwachediesesKonzepts,dadie Lastverteilungnur furein Namensdienst-basiertesSystemkonzipiertist. Die zusatzlichenAspekte,die sichdurchdenEinsatzeinesTradersergeben,wennbeispielsweisedie Dienstauswahl desTradersund desLoad Balancerszusammengefuhrt werdenmussen,bleibendeshalbunberucksichtigt.In Abbildung3.3ist diegrobeArchitekturdiesesSystemsdargestellt.Die vomjeweili-genStubgemessenenMonitoringdatenwerdenaneinenjeweilslokalenLoadBalancer


DataServer geschicktunddort in einerMIB verwaltet.DieserDataServer verbreitetdie neueingetroffenenDatenanalle anderenLoadBalancerDataServer, damit jederlokaleLoadBalancerZugriff aufdieglobalenLastinformationenhat.Um einenDienstzufinden,fragteinClientbeimNamensdienstan,derdannin Absprachemit demLoadBalancerdenoptimalenServerzuruckliefert.

Client Stub

LB

LB Data Server

ServerStub

LB Data Server

* *

Namensdienst

Client-Knoten Server-KnotenServernutzung

LB=Load Balancer

Monitordatenübermitteln

Monitordatenübermitteln

MonitordatenZugriff auf

Austausch von Monitoring-Daten

Migration ve

ranlassen

importDienst-

Server erfragen

Optimalen

Abbildung3.3:VerteilungsdiagrammdesSystemsvonSchiemann

Zusatzlich unterstutzt dasKonzeptServermigration.Ein Load Balancerkann einenServeranweisen,dieaktuelleBindungzuunterbrechen.Dadurchwird derbetreffendeClient bei der nachstenDienstnutzunggezwungen,sich direkt beim Load BalancernachderneuenServeradressezuerkundigen.DiesesKonzeptist prinzipiell auf jederIDL-basiertenVerteilungsplattformzurealisie-ren.Die Implementierung,die prototypischauf einemCORBA-Systemerfolgte,mußjedochbestimmteInformationenuberdiezugrundeliegendePlattformbesitzen,dafurdasMonitoring der automatischgenerierteStub-Quellcodemodifiziert werdenmuß.Dies ist alsweitereSchwacheanzusehen,dadiesedirekteManipulationrechtunsau-ber ist. Somußinsbesonderegenaubekanntsein,wie der IDL-Compiler die Umset-zungderSchnittstellenbeschreibungauf die jeweils verwendeteProgrammiersprachevornimmt.

3.4 Verbesserungsmoglichkeiten

Alle vorgestelltenAnsatzelosendie Problemstellung,die in dieserArbeit behandeltwerdensoll, nicht vollstandig. Fur eine Optimierungder Dienstauswahl in einemCORBA-TraderunterdemAspektdynamischerLastverteilungfehlendort jeweilses-sentielleAspekte.Die bei deneinzelnenAnsatzenzu kritisierendenPunktesind imfolgendenaufgefuhrt.ReineTrader-Implementierungenbeschrankensichauf die Dienstvermittlung– Kon-zeptezur Lastverteilungsind dort nicht vorgesehen.Zwar ist esprinzipiell denkbar,

3.4.Verbesserungsmoglichkeiten 35

uberdynamischeLast-Attributein Verbindungmit AuswahlbedingungenundOptimie-rungsfunktionenmoglichst gering ausgelasteteDienstangeboteauszuwahlen; in derPraxisscheitertdiesjedochgroßtenteils.Soist esfur einenDienstanbieteroft proble-matisch,ohneeinenseperatenMonitor Lastinformationenzur Verfugungzu stellen.Weit schwierigergestaltetsich jedochder eigentlicheAuswahlprozeßinnerhalbdesTraders.KomplexeLastbewertungen,dieauf vielenverschiedenenLastinformationenberuhen,sinddortnichtmoglich.Dies gilt auchfur denAachenerTrader. So stellt die in [Kup95] beispielhaftvorge-nommeneLastverteilunguber dynamischeAttribute nur eine Vorstufezur dynami-schenLastverteilungin einemTrading-Systemdar. Statt kontinuierlicherLastkenn-zahlenwerdenlediglich diskrete

”Busy“ und

”Idle“ -Zustande,die die Servernutzung

charakterisieren,verwendet.EineeigeneLastverteilungskomponente,dieeineBewer-tungderunterschiedlichenLastinformationenvornimmtundihre Ergebnissemit demTraderabgleicht,ist nichtvorgesehen.DaruberhinausweistdievorliegendeTrader-ImplementierungkleinereFehlerauf,diesich u.a.bei der Benutzungvon Kontexten und Diensttyp-Hierarchienzeigen.Auchdie Verwendungvon konkretenObjektreferenzenin DienstangebotenmußerstnochdenEigenheitenderCORBA-ImplementierungvonIonaangepaßtwerden.Als großtesHindernisfur einerein auf diesemTraderbasierendeLastbalancierungist jedochdieaußerstunvollstandigeUnterstutzungvon dynamischenDiensteigenschaftenanzuse-hen.Die ebenfalls am Lehrstuhlfur Informatik IV erstellteDiplomarbeit[Sem97]bietetzwarwiederumeinedynamischeLastverteilungubereineLastverteilungskomponente,dievoneinenManagementobjektmit denMeßdatenderServermonitoreversorgt wird,eineDienstvermittlungist dortallerdingsnichtvorhanden.EsfindetsichzwarderHin-weisaufeineeinfacheIntegrierbarkeit in einenTrader– wie diesgenauerfolgenkann,bleibt allerdingsoffen.An andererStellewird alsMotivationfur dendort realisiertenLastverteilungsansatzdie Replikationvon Traderobjektengegeben,wobei ebenfallsoffen bleibt, wie die Zusammenarbeitder repliziertenTraderobjekteaussehenkann.DaruberhinausstelltdieErmittlungderLastinformationeineSchwachstelledieserAr-beit dar. Sie erfolgt durchMeßanfragenan denServer, die sich zusammenmit denregularenAuftragenin dieServer-Warteschlangeeinreihen.Aus derZeit, dievergeht,bis eineabgeschickteMeßanfragebeantwortetwird, ziehtderMonitor RuckschlusseuberdieWarteschlangenlange.DerdabeigewonneneWertbeschreibtjedochnichtdieaktuelleWarteschlange,sondernnur die SituationzumZeitpunktalsdie Meßanfrageabgeschicktwurde.Die Lastverteilungerfolgt demnachanhandvon veraltetenInfor-mationen,die sich in derZwischenzeitentscheidendgeanderthabenkonnen.Bemer-kenswertist jedochdasErgebnis,daßsichServer-initiierte Lastverteilungsstrategien,wie sie in [WM85] vorgeschlagenwerden,in derPraxisnicht bewahren.UnabhangigdavonsindderartigeStrategienin einemweltweitenDienstmarktnur schwerzu reali-sieren,dahierbeianmehrerenTraderneinerFoderationWarteschlangenmit Auftragenentstehen,dieallevomServer berucksichtigtwerdenmußten.TheoretischeArbeitenwie [WT93] bietenzwareingutesRustzeugfur dieBetrachtung


desProblembereichsderLastverteilungin Trading-Systemen,konkreteHilfestellungfur die Implementierungder dort simuliertenStrategien wird aberdadurchnicht ge-geben.So ist die Verwendungvon Wissen,dasein Traderuberdie VermittlungvonDienstenbesitzt,sehrvielversprechend;diein [WT93] benotigteAussageuberdieBe-arbeitungszeitenvonzuvermittelndenDienstenist in derPraxisjedochnurschwerzurealisieren.Die dort getroffeneAnnahmevon jeweils gleicherServergeschwindigkeitzur Schatzungvon Dienstbearbeitungszeitenerscheintspeziellfur heterogeneSyste-menicht plausibel.Dennin einemoffenenDienstmarktsindAussagenuberdie Lei-stungsfahigkeit der einzelnenDienstanbietersowie uberdie Komplexitat einesAuf-trags,beidemderEinflußderEingabedatenunbekanntist, kaummoglich.

VielversprechendererscheinendasMELODY- unddasLYDIA-Projekt.Aberauchdie-selosendieProblemstellungnicht vollstandig.

DasMELODY-ProjektbietetguteAnsatzeaufgrundderVerknupfungvonTradingundManagementsamtMonitoring. In Kombinationmit denangebotenenkomplexenTra-deranfragenund Optimierungsstrategien,die beispielsweiseeinegezielteAbwagungzwischender Qualitat von Diensteigenschaftenund Serverlastermoglichen,durftenwesentlicheAnforderungendervorliegendenProblemstellungzu losensein.Dennochist das Fehleneiner speziellenLastverteilungskomponenteals Mangel anzusehen,da komplexe Lastverteilungsstrategienallein uberdenTradernicht realisiertwerdenkonnen.Weiterhinist zukritisieren,daßeinederartigeLastbalancierungnicht transpa-rentfur denDienst-Importererfolgt,sondernvielmehrvondiesemdurchVerwendungvonnichtstandardisiertenDienstauswahlkriterienerzwungenwerdenmuß.

SchiemannsArbeitenim LYDIA-Projekt bietenein gutesKonzeptzur dynamischenLastverteilungin einemCORBA-System.AufgrundderbereitserwahntenSchwachengenugt dieser Ansatz jedoch nicht den gestelltenAnforderungen.Die Dienstver-mittlung uber einen Namensdienststellt einen konzeptionellenMangel dar. DerwunschenswerteUbergangzu einemTradererfordertumfangreichereAnderungen,wenn daszusatzlichePotential,dassich dadurchergibt, ausgeschopft werdensoll.Fur die konkreteRealisierungist anzumerken,daßdie direkteManipulationim Stubzwar fur dasubrigeSystemextrem transparent,aberinsgesamtnicht zukunftssicherist, dazuviel Kenntnisuberdie zugrundeliegendeCORBA-Implementierungbenotigtwird. Sowurdein SchiemannsPrototypdie Stub-Modifikationvon Handvorgenom-menund daraufverwiesen,daßauf InternaausdemQuelltext der Siemens-eigenenCORBA-ImplementierungSORBETzuruckgegriffen wird. Als sauberereAlternativefuhrt Schiemanndeshalbselberdie im Orbix-SystembereitgestelltenFilterpunktean,mit denenmansichubergenaudefinierteZugangspunktein denStubeinklinkenkann,um soein transparentesMonitoring der uberdenStubbequemzu ermittelndenLast-informationenzu realisieren.Auch die Servermigrationist alskritisch anzusehen,dasie aufgrundder dabeizusatzlich entstehendenLast nur bei sehrlang andauerndenAuftragenvon Nutzenist, wie die Simulationender theoretischenArbeitenergebenhaben.Ebensostellt sichdieFrage,ob in einemoffenenundheterogenenDienstmarktuberhaupteineServermigrationmoglich ist.


3.4.1 Anforderungenan einenverbessertenEntwurf

An einengutenAnsatzzur lastabhangigenOptimierungder Dienstauswahl musseneinigekonzeptionelleAnforderungengestelltwerden.AusdervorangegangenenAna-lysederSchwachstellenderexistierendenArbeitenergebensichdie folgendePunkte,die fur einenverbessertenEntwurf zubeachtensind.� Um die Vorteile, die sich durcheinenoffenenDienstmarktergeben,voll aus-

nutzenzu konnen,ist ein Traderzur qualifiziertenDienstvermittlungerforder-lich. UnabhangigvonderOptimierungdurchLastbalancierungmußesweiterhinmoglich sein,die DiensteigenschaftendurchSelektions-und zugehorigeOpti-mierungskriterienbestimmenzukonnen.� Zur einfachenVerwendbarkeit in bestehendenAnwendungenist einetransparen-te Lastverteilungerforderlich.Der Dienstnutzersolltesichnicht um dieseneueFunktionalitatkummernmussen,sonderndiegewohntenAufrufe weiterhinver-wendenkonnen.Hierzu ist eine Lastverteilungskomponentein den Traderzuintegrieren.� Fur den Einsatz in heterogenenSystemenist die Konformitat zu Standardsbedeutsam.Dies beziehtsich vor allem auf die Verteilungsplattformund dieSchnittstellezumTrader.� NebendiesenaußerenBedingungenist fur die InternaeinesverbessertenEnt-wurfs zu beachten,daßdie Verzahnungvon Traderund Load BalancerSyner-gieeffekteerwartenlaßt.Diesist dadurchzu begrunden,daßderLoadBalancerdasWissendesTradersuberzuruckliegendeVermittlungenbenutzenkannunddergegenseitigenZugriff auf interneDatenstruktureneinebessereEinschatzungderDienstehinsichtlichverschiedensterKriterienermoglicht.� Im Anschlußan die Ermittlung der in FragekommendenDienstanbieteristes notig, die Ergebnissevon Traderund Load Balancergeeignetzusammen-zufuhren.Hierzumußein Regelwerk eingesetztwerden,anhanddessenbei derZusammenfuhrungderbeidenErgebnismengenein Kompromißzwischenopti-malenDiensteigenschaftenundgeringerLastgefundenwerdenkann.Nebenei-nersinnvollen Default-CharakteristikmußesdenImporternmoglich sein,uberdie Standard-konformeTrader-SchnittstelleEinfluß auf die ParameterdesRe-gelwerksauszuuben.� Die Festlegungauf einefesteLastverteilungsstrategie ist zu vermeiden,da dieErfahrungausdenvorgestelltenArbeitenlehrt, daßessich oft erst in der Pra-xis herausstellt,welcheStrategie fur eine bestimmteKonstellationam bestengeeignetist. Esmußdaherleichtmoglichsein,dieverwendeteStrategieauszut-auschen.


� Fur eine effektive LastbalancierungmussendynamischeStrategien eingesetztwerden,was die Ermittlung der Last bei den in FragekommendenDienstan-bieternnotig macht.Hierzu ist ein entsprechendesManagement-bzw. Monito-ringkonzepterforderlich,dasaußerdemflexibel genugseinmuß,denWechselvon LastverteilungsstragienundderenunterschiedlichenInformationsbedarfzuunterstutzen.

3.4.2 Entwurfsentscheidungen

Bei der Konzeptioneiner Realisierung,die den zuvor aufgefuhrtenAnforderungenentspricht,sindverschiedeneUmfelder, in denendasSystemeingesetztwerdensoll,denkbar. Einerseitssoll der Entwurf flexibel genugsein,um sich diesenSzenarienanpassenzu konnen,andererseitsmusseneinigeFestlegungengetroffen werden,umeineeffizienteundim RahmendieserDiplomarbeitrealisierbareImplementierungzuermoglichen.Zur EinschrankungdesProblembereichswurdendahereinigeEntscheidungengetrof-fen,die fur denweiterenEntwurfdasnunbeschriebeneSzenarioergeben.

Verteilungsplattform: Als Verteilungsplattformwird die am Lehrstuhl installierteCORBA-ImplementierungOrbix von Iona in der Version2.3 unter dem Be-triebssystemSolaris2.6vonSUNverwendet.

Trader: Fur die RealisierungderTraderfunktionalitat wird deramLehrstuhlfur In-formatik IV entwickelteTradereingesetzt.Eswerdendie dort implementiertenTrader-Schnittstellenbeibehalten.

Integration desLoad Balancers: Zur besserenVerzahnungdes Trading- und desLastbalancierungsprozesseswird der vorhandeneTraderim Quelltext modifi-ziert undum denLoadBalancerangereichert,sodaßauf Trader-interneDatenzugegriffen werdenkann.Fur lediglich als ausfuhrbareDatei vorliegendeTra-der, wie z.B. denOrbixTrader, wareaberauchein

”Wrapper“ -Objektdenkbar,

dasdenTraderunddenLoadBalancergetrenntausfuhrt undanschließendde-renErgebnissezusammenfuhrt.EineNutzungvonTrader-internemWissenwarehierbeiallerdingsnichtmehrmoglich.

Dauer der Bindung: Es wird einepermanenteNeuwahl der Dienstanbieterjeweilsvor derNutzungeinesDienstesdurchdie Dienstnutzervorausgesetzt.Der um-gekehrteFall, beidemeineeinmalvomTraderaneinenClientgelieferteDienst-mengevoneinemLoadBalancerverwaltetwird, versprichtzwareineschnellereDienstauswahl, diesewareabernicht unbedingtoptimal, falls sich in derZwi-schenzeitdie DiensteigenschaftenderDienstanbietergeanderthabenoderneueDienstanbieterhinzukommen.In diesemFall wareeineServermigrationnotig –dieserAspektsoll in dieserArbeit jedochnichtbetrachtetwerden.


Transparenz: Die Integrationder Lastbalancierungin den Tradersoll fur den Be-nutzertransparenterfolgen.Um dennocheinenEinfluß auf die Lastverteilungnehmenzu konnen,konnenCharakteristikader Lastverteilunguber spezielleDienstattributeangegebenwerden.NebenderFestlegung,obdieDienstauswahlmit oderohneLastberucksichtigungerfolgensoll, sindweitereAttributezurBe-schreibungderPrioritatenbezuglichderZusammenfuhrungdervonTrader- undLoadBalancer-Ergebnissenvorgesehen.

FoderativesTrading: Die zugrundeliegende Traderimplementierungunterstutztzwar die Trader-Foderation,die EinbeziehungdiesesAspektssprengtjedochdenRahmendieserDiplomarbeit.SomußtengeeigneteKonzeptezurErmittlungderLastbei Dienstanbieternin fremdenDomanenentwickelt werden.Auch dieNutzungvonTrader-WissendurchdenLoadBalancerist nichtmehrvollstandigmoglich,dader jeweils lokaleTradernur eineeingeschrankteSichtauf die ge-samteFoderationbesitzt.Durchdie VerwendungeineseinzigenzentralenTra-dersbestehtallerdingsdie Gefahr, daßdieserzum Flaschenhalswird und sodenGesamtdurchsatzdesSystemsherabsetzt.Dochauchdie VerwendungvonmehrerenrepliziertenTraderninnerhalbeinerDomanewurdesich als ahnlichkomplex erweisen,wobeidanndie Frageaufkommt,werdenTradersamtLast-balanciererbalanciert.Hierfur wareeinseperatesLastverteilungskonzeptnotig.

Management: In derSpezifikationderCORBAfacilitieswird zwar auchaufdenBe-reichdesSystemmanagementseingegangen,allerdingsliegenhierfur nochkei-ne Standardsvor, weshalbaußerwenigenherstellerspezifischenAnsatzenzurZeit nochkein Managementsystemfur die CORBA-Plattform vorliegt. Daherwird fur dieseDiplomarbeitein eigenesManagementkonzeptverwendet,dassich allerdingsauf dasMonitoring der fur die LastverteilungbenotigtenDatenbeschrankt.

Anzahl Server pro Rechnerknoten: Entscheidendfur dasMonitoring,dabeinurei-nemDienstanbieterpro RechnerknotenjederMonitor eindeutigmit einemSer-ver identifiziertwerdenkann.Bei mehrereServernproKnotenmußderMonitormehrereServer verwaltenund unterscheiden,was dannauchim Load Balan-cer berucksichtigtwerdenmuß.Um dasKonzeptflexibel zu gestalten,werdenmehrereServerproMonitor unterstutzt.

NebendiesemgrobenRahmen,derdenzubehandelndenProblembereicheinschrankt,tretennocheineReiheweitererEntscheidungenauf, die abereherDetailsdesEnt-wurfs betrefffen. Hierbei handeltessich zum Teil aberum Parameter, durchdie dieQualitatderangestrebtenOptimierungentscheidendbeeinflußtwerdenkann,weshalbeinigevon ihnenbewußtoffen gelassenwurden,um mehrereAlternativentestenundbewertenzukonnen.Hierzuzahlen:

Lastbegriff: Die betrachteteLastkannvielfaltigt sein,z.B. die CPU-Last,die Netz-last, die Last, die sich durch Input-/Output-Operationenergibt, oderauchdie


Last,die bei einemzu nutzendenPeripheriegerat vorliegt. In dieserArbeit er-folgt eineBeschrankungaufdieCPU-Last.

Lastmetrik: Zur Vergleichbarkeit dervon deneinzelnenMonitorengeliefertenLast-datenwird eine jeweils einheitlicheMetrik benotigt. Als vergleichbareMaßebietensich die aktuelleWarteschlangenlange,die durchschnittlicheDienstbe-arbeitungszeitoder Rateder Dienstnutzungswunschepro Zeiteinheitan. DieVerwendungvon absolutenZeitpunktensollte vermiedenwerden,da sonstei-nekomplexe UhrensynchronisationzwischendeneinzelnenRechnerknotener-forderlich ist. Da unklar ist, welcheder vorgeschlagenenMetriken am Bestengeeignetist, ist derenBewertungGegenstanddieserDiplomarbeit.

Lastverteilungsstrategien: Da ebenfalls unklar ist, welcheLastverteilungsstrategieeinzusetzenist, mußein flexibler Austauschvon Strategien moglich sein.Hierliegt ein engerZusammenhangmit denLastmetriken vor, da unterschiedlicheStrategienauchunterschiedlicheInformationenbenotigen.NebenverschiedenendynamischenStrategien,die auf denobenerwahntenMetrikenbasieren,sollenaußerdemstatischeVerfahren,sowie VerfahrenausdemGrenzbereichvon sta-tischerund dynamischerLastverteilungeingesetztwerden.Hierzu zahlenreinprobabilistischeVerfahren,sowie solche,die einezyklischeZuweisunganhandderAnzahlderzuruckliegendenVermittlungenvornehmen.DieseStrategiensol-lenebenfalls getestundbewertetwerden.

Ermittlung der Last: Die Last der einzelnenDienstanbietersoll uber SensorenindenFilterpunkten,uberdiemansichin denStubderDienstschnittstelleneinklin-ken kann,erfolgen.So ist eine transparenteMeßwertaufnahmemoglich, uberdie die wichtigstenLastinformationenermittelt werdenkonnen.DieseFilter-punktewerdenzwar zur Zeit nur von Orbix angeboten,dasieaberin die Versi-on2.2derCORBA-Spezifikationaufgenommenwurden,ist dieNicht-CORBA-KonformitatdiesesEntwurfsnurvonkurzerDauer.

Plazierungder Monitor e: Nebender Frage,wie die Sensorenrealisiertwerden,istweiterhinzu klaren,wie die Monitorobjekte,die mit demLoadBalancerkom-munzieren,in dasSystemintegriertwerden.SolangeeineCaching-StrategiezurUbermittlungderLastinformationenandenLoadBalancereingesetztwird, ist esausreichend,denMonitor zusammenmit demSensorin denServerprozeßzuin-tegrieren.DieseLosunghatdenVorteil,daßsiefur dasGesamtsystemsehrtrans-parentist. Falls die Lastinformationenvom Load Balancerper Polling erfragtwerdensollen,ist diesePlazierungjedochproblembehaftet,daeineAntwort nurdannmoglich ist, wennder Serverprozeßnicht beschaftigt ist und auf Anfra-genwartet.Deshalbbietetessich fur einePollingstrategie an,denMonitor alsseperatenProzeßoderzumindestals eigenenThreadzu realisieren.AlternativhierzukonntederLoadBalancerdazuubergehen,einenServerprozeß,dernichtschnellgenugauf einePollinganfrageantwortenkann,alsuberlastetanzusehen


undausderaktuellenBewertungherauszu lassen.Bei einerhohenLastkonntediesaberim Extremfall dazufuhren,daßgar keineServer vermittelt werden.Daherwird ein seperaterMonitorprozeßverwendet.DieshatzudemgegenubereinemThreaddenVorteil, daßein Monitor auchbei Ausfall desServersnochInformationen,z.B. uberdenServerausfall, andasManagementsystemweiter-leitenkann.

Ubermittlung der Monitormeßdaten an denLoad Balancer: Wahrend die Kom-munikationzwischenSensorund Monitor lokal auf dem jeweiligen Rechner-knotenerfolgt, verursachtdie Ubertragungder Monitordatenan denLoad Ba-lancereineerhohteNetzlast.Als KommunikationsmethodebietensichOneway-Operationsaufrufeoderder EventServicean. Da der zu realisierendeEntwurflediglich einenzentralenLoad Balancervorsieht,wird keineGruppenkommu-nikationbenotigt, sodaßeinfacheOneway-Operationsaufrufeausreichendsind.DieseasynchronenAufrufe sind im Gegensatzzu herkommlichen,synchronenOperationsaufrufenschnellerunderzeugenwenigerNetzlast,dakein Fehlersi-cherungsprotokoll mit zusatzlichenQuittungeneingesetztwird. Im Gegenzugsteigtjedochdie Fehleranfalligkeit an.Da in Orbix beimOneway-Protokoll zu-mindestgarantiertwird, dasdie Nachrichtfehlerfreiauf dasNetzwerkgegebenwurde,ist beimEinsatzin einemrein lokalenNetzderVerlustvon Nachrichteneherzuvernachlassigen.

Caching/Polling-Strategie: Da sich diesebeidenAttributierungsstrategien zur Er-mittlung der Lastinformationenje nachdem,wie oft die Lastinformationenbenotigt werden,unterschiedlichgut eignen,mussensowohl Cachingals auchPolling implementiert werden, um deren praktischeEignung bewerten zukonnen.Eine Optimierungder durchdasMonitoring erzeugtenNetzlastkanndanndurchdynamischeUmschaltungzwischenbeidenStrategienerfolgen.

Verwendungvon Wissenuber vergangeneVermittlungen: Der LoadBalancerbe-findetsichin derLage,dasWissendesTradersubererfolgteVermittlungenzurSchatzungderbeideneinzelnenDienstanbieternvorliegendenLastbenutzenzukonnen.Da dasTrading-Prinzipnur denBeginn einerDienstnutzungbeinhal-tet, konnendadurchallerdingskeineInformationengewonnenwerden,die vonderBearbeitungsgeschwindigkeit desDienstanbietersabhangen.Von denzuvorvorgeschlagenMetrikenbleibtdahernurdieAnzahldergewunschtenDienstnut-zungen,die im TradereineSchatzungderLastzulaßt,ubrig.Alle weiterenLast-informationenkonnennur durchKombinationmit denMonitordatengewonnenwerden.

BeschleunigungdesLastbalancierungsablaufs: DurchParallelisierungderDienst-auswahl im Traderund im LoadBalancerkanneineunnotigeVerzogerungdesDienstauswahlprozessesverhindertwerden.Hierzu werdenmehrereThreads


benotigt, die die ErmittlungderLastinformationenunabhangigvon derDienst-auswahl desTradersermoglichen.Dafur benotigt der Load BalancerEinblickin denlaufendenDienstauswahlprozeß,um bereitsvor Ablauf diesesProzessesentscheidenzu konnen,welcheDienstanbieterfur die Lastverteilungin Fragekommen.

Regelwerkzur Zusammenfuhrung der Ergebnisse:Die Ranglistender Dienstan-bieter, die vom Traderund vom Load BalancerunterverschiedenenGesichts-punktenerstelltwurden,mussenamEndederImportanfragezusammengefuhrtwerden.Hierzu ist ein Regelwerk notig, daßaufgrundunterschiedlicherKri-terieneineAbwagungzwischenDiensteigenschaftenund Lastvornimmt.EinetransparenteRealisierungist im Tradermoglich,wobeieinDienstnutzerzusatz-lich PraferenzenuberAttributvorgabenangebenkann.So ist die OptimierunganhandeinerNorm,diedenAbstandderDiensteigenschaftenundderDienstlastberechnet,denkbar. Eine flexiblere Zusammenfuhrungware durch Aufruf ei-nerCallbackfunktionmoglich, die derDienstnutzerdemTraderzur Verfugungstellt,umdiebeidenRanglistenzuvereinen.Fur derartigeCallback-FunktionenexistierenjedochkeineStandards,sodaßhierdurchbeimDienstimportderTra-derstandardverletztwurde.

3.4.3 Einordnung der vorgestelltenAnsatze

Abschließendlaßtsich ein kurzerUberblick uberdie in diesemKapitel behandeltenImplementierungengeben.Tabelle3.1 faßthierzuim wesentlichendie KritikpunkteausAbschnitt3.4 zusammenundordnetdeneigenenEntwurf bezuglich deranderenvorgestellten,relevantenAnsatzeein. Diesgeschiehtanhandvon vier – fur eineOp-timierungderDienstauswahl unterdemAspektderLastbalancierungwesentlichen–Punkten.Die in einen Dienstmarkt benotigte Tradingfunktionalitat wird von dem reinenLoadbalancing-Ansatzin [Sem97]nicht geboten.Auch der im LYDIA-Projekt vonSchiemannverfolgteAnsatz[Sch96a,Sch96b,Sch97a, SB97] basiertlediglichaufei-nemNamensdienstzurDienstvermittlung.Die ubrigenAnsatzeweisendiesenschwer-wiegendenMangelnichtauf.SpezielleLastverteilungskomponenten,die komplexe Lastbewertungenvornehmenkonnen,sind nur in [Sem97],demLYDIA-Projekt, sowie demin dieserArbeit ver-folgtenAnsatzenthalten.DasMELODY-System[Kel93, Kov94, KB95,Kov96] bietetuberseinManagementsystemzumindestLastinformationenan.Diesekonnenuberdiein diesemTradermoglichenkomplexenAuswahlregeln fur eineeinfacheLastbalan-cierungverwendetwerden.Ein Regelwerk, dasdie unter verschiedenenAspektenenstandenenErgebnissevonTrader und Load Balancerzu einem Kompromiß aus niedriger Last und hoherDienstgute zusammenfuhrt, bietet nur der eigeneAnsatz.Da der MELODY-TradereineOptimierunguberGewichtungsfunktionenzulaßt,warehiermit ansatzweiseeine


enthalteneKomponenten Ans

atz

Aac

hene

rTra

der

Load

Bal

ance

rnac

h[S

em97

]

ME

LOD

Y

LYD

IA

Eig

ener

Ans

atz

Trader + - + - +LoadBalancer - + $ 4 + +

RegelwerkzurErgebniszusammenfuhrung - - $ 5 - +allgemeinesManagement - - + - -

Tabelle3.1:Vor- undNachteiledereinzelnenKonzepte

derartigeFunktionalitatzurealisieren.Die angebotenenAuswahlregelnsindallerdingsnichtkonformzudengangigenTraderstandards.Fur die Lastermittlungwird ein Monitorsystembenotigt. Dieseswurdesichhervorra-gendin ein allgemeinesManagementvon VerteiltenSystemeneingliedern.Ein um-fassenderManagementansatzist allerdingsnur im MELODY-Systementhalten.DieanderenvorgestelltenArbeitenundauchdie eigeneArbeit, beschrankensich– sofernsiesich uberhauptmit Lastverteilungbeschaftigen– auf ein reinesLeistungsmonito-ring.

4AnsatzweiseuberTraderauswahlregelnundLastinformationen,dievonMonitorenalsdynamischeAttributeangebotenwerden.

5AnsatzweiseuberkomplexeAuswahlregelnim Trader.

Kapitel 4

RealisierungeinesTradingsystemszurLastbalancierung

DiesesKapitel beschreibtdie RealisierungeinesTraders,der eine OptimierungderDienstauswahlaufgrundderbeideneinzelnenDienstanbieternvorliegendenLastvor-nimmt.Fur dieRealisierungwurdezunachstderdurchdie im vorhergehendenKapitelgestell-tenAnforderungeneingegrenzteProblembereichobjektorientiertmodelliert.DerdabeientstandeneEntwurf ist in Abschnitt4.1wiedergegeben.Daranschloßsichdie ImplementierungdesEntwurfsin derProgrammierspracheC++unter Verwendungder CORBA-Plattform Orbix an. Einzelheitendazusind im Ab-schnitt4.2aufgefuhrt.Zur ValidierungfandenTestlaufestatt,anhanddererdieFunktionsfahigkeit derimple-mentiertenKlassenuberpruft wurde.Die abschließendeLeistungsbewertungdesrea-lisiertenSystems,die zur BewertungdesentwickeltenGesamtkonzeptsdient, findetsichim nachstenKapitel.Die beschriebeneVorgehensweisestelltallerdingsnurdieEndsichtdesEntwicklungs-prozessesdar. Die einzelnenStufenderSoftwareentwicklungwurdenvielmehrmehr-malsdurchlaufen,sodaßsichdasendgultigeSystemdurcheinenwiederholtenProzeßvon iterativenVerfeinerungenherauskristallisierte.

4.1 Modellierung desTradings und der Lastbalancie-rung

Durch die objektorientierteModellierungsollenAblaufeund GegenstandedesPro-blembereichsidentifiziertundaufKlassenbzw. ObjekteundderenBeziehungenunter-einanderabgebildetwerden.Im LaufedesiterativenEntwicklungsprozessesentstehtdabeidieArchitekturdesSoftwaresystems.Zur DarstellungdesentwickeltenModellswird dievonderOMG standardisierteUni-fied Modeling Language(UML) [FS98, Bur97] in der Version1.3 verwendet.UML

46 4. RealisierungeinesTradingsystemszurLastbalancierung

bietetverschiedeneNotationenfur die wichtigstenAspekte,die ein objektorientiertesModell beinhaltet.Die Verteilungsdiagrammezur Notationder Komponentenverteilungwurdenbereitsim vorhergehendenKapitelverwendet.In diesemKapitelwerdenzusatzlichnochUse-Case-Diagramme,SequenzdiagrammeundKlassenstrukturdiagrammeeingesetzt.Ab-gesehenvonDetailssinddieseDiagrammeintuitiv verstandlich,weshalbim folgendennurkurz ihr Verwendungszweckerlautertwird.Bei Use-Caseshandeltessich um Anwendungsfalle, die in demzu modellierendenSystemauftreten.DasIdentifizierenvonAblaufenstelltnebenderIdentifizierungvonKlasseneinendererstenSchrittebei derModellerstellungdar. Die zugehorigenDia-grammebeschreibeneinzelneVorgangesowie die daranbeteiligtenAkteure.Zusatz-lich konnenBeziehungen(

”Benutzt“ ,

”Erweitert“ ) zwischendeneinzelnenVorgangen

angebenwerden.KlassenstrukturdiagrammestelleneinezentraleNotationzur Beschreibungvon stati-schenBeziehungenzwischendenidentifiziertenKlasseneinesModellsdar. Mit die-senDiagrammtypkonnenBeziehungenzwischenKlassendargestelltwerden.HierzuzahlenAssoziationen(

”Benutzt“ ) zwischenKlassen,Generalisierungen(

”Erbt von“ )

sowie Klassen-Aggregationen(”Enthalt“ ).

DurchSequenzdiagrammekanndieInteraktionzwischenObjektenerfaßtwerden.Da-zu wird entlangeinerZeitachsederAblauf desNachrichtenaustauschszwischenOb-jektendargestellt.In diesemZusammenhangist esauchmoglich, nebenlaufigePro-zesse(Threads)darzustellen.UnterBerucksichtigungderAnforderungenausKapitel 3 ergibt sichfur daszu reali-sierendeTradingsystemdasim weiterenbeschriebeneModell. Weil dasgesamteAn-wendungsgebietansichbereitseinerModellbildungentsprungenist, gestaltetsichdieModellierungrelativ einfach.

4.1.1 Anwendungsfalle

ZunachstlassensichalsAkteurederTraderundderLoadBalancer, dieMonitoresowiedie Dienstanbieterbzw. Server-MOs unddie Dienstnutzeridentifizieren.Ihre Aufga-benwurdenbereitsin denbeidenvorangehendenKapiteln beschrieben.Von diesenAkteurengehenim wesentlichensiebenverschiedeneAnwendungsfalle aus.Die ein-zelnenVorgangewerdennachfolgendbeschrieben.Obwohl dieDienstanbieter-RolleunddieManagedObject-RollevomgleichenServer-objekteingenommenwerden,wird einServer– wie beiderManagementsichtublich–durch ein Datenverarbeitungsobjektund ein Management-Objektmodelliert. DieseUnterscheidungist sinnvoll, dasichdiesebeidenAkteurespaterin unterschiedlichenRollen wiederfinden.Die InformationendesServer-MO werdenin die ManagementInformationBaseeingetragen,einDienstanbieterfindetsichhingegenalsDienstange-bot in denTabellendesTraderswieder.Dementsprechendwerdendie Falle Dienstexport und Registrierungvon ServernimManagementsystem(bzw. Dienstabmeldung(Withdraw)undDeregistrierungvonSer-

4.1.ModellierungdesTradingsundderLastbalancierung 47

vern) als unterschiedlicheAnwendungsfalle angesehen.Da laut Anforderungsspezi-fikation die Lastverteilungtransparenterfolgensoll, darf ein Dienstanbieternichtsvom ManagementsystemunddessenMonitorenwissen,sodaßdiesebeidenAnwen-dungsfallevoneinanderzu trennensind.

4.1.1.1 Registrierung von Servern im Managementsystem

Abbildung4.1stellt denAnwendungsfall derRegistrierungeinesServersbzw. dessenMO beimManagementsystemdar. Dazuwird dasServer-MO nachdemServerstartbeiseinemlokalenMonitor registriert.Dieserubernimmtdannfur alleMOsseinesRech-nerknotenseineAgentenrollebezuglich desubrigenSystems.Dazulegt ein MonitoreinenEintragfur jedesServer-MO in seinerlokalenManagementInformationenBasean.

Da ein Load Balancerdie Managementinformationenaller Serverobjektebenotigt,meldetein Monitor die von ihm uberwachtenServer-MOs demLoad Balancer. Da-durcherfahrt letzterer, welcherMonitor fur welcheServer-MOs als Agentzustandigist. Der Load Balancermerkt sich bei der RegistrierungdieseZuordnung,indemereinenentsprechendenServer-Monitor-Eintraganlegt. Die RegistrierungeinesServer-MOs beim Load Balancerwird durch die AnmeldungdesServer-MOs bei seinemMonitor ausgelost.

Registrierungbeim Monitor

Server-Eintragin der MIB anlegen

Monitor

Load Balancer

Registrierungbeim Loadbalancer

Server-Monitor-Eintrag anlegen

Server-MO

"Benutzt"

"Benutzt"

"Benutzt"

Abbildung 4.1: Use-Case-Diagrammfur die Registrierungvon Servern im Manage-mentsystem


4.1.1.2 Dienstexport

Der Anwendungsfall Dienstexport umfaßt dasAnmeldeneinesDienstesbei einemTrader. Dazuwird auf denAnwendungsfall Dienstangeboteintragenzuruckgegriffen,der dasexportierteDienstangebotin die DiensttabelledesTraderseintragt. Daszu-gehorigeUse-Case-Diagrammfindetsichin Abbildung4.2.

Dienstanbieter Trader

Dienstangeboteintragen

Dienstexport

"Benutzt"

Abbildung4.2:Use-Case-Diagrammfur demDienstexport

4.1.1.3 Dienstimport/Lastbalancierung

In Abbildung 4.3 ist der Anwendungsfall desImportsvon Dienstenmit gleichzeiti-ger Lastbalancierungwiedergegeben.Beim Dienstimportwird zunachstein Anwen-dungsfall durchlaufen,der die passendenDienstangeboteausder DiensttabelledesTradersheraussucht.DieserAnwendungsfall greift auf einenTypmanagerzuruck,umdie moglichenUntertypendesgewunschtenDiensteszu ermitteln.In einemweiterenAnwendungsfall mußderLoadBalancerdie Lastfur die in FragekommendenServerbestimmen.WenndiesebeideAnwendungsfalle durchlaufensind,mussendie beidenErgebnisse,diedabeientstandensind,zusammengefuhrtwerden.

passende Dienst-angebote suchen Last bestimmen

Ergebnissezusammenführen

TraderDienstimport/

Lastbalancierung

Dienstnutzer

Load Balancer

Typmanager erfragenUntertypen vom

"Benutzt" "Benutzt""Benutzt""Benutzt"

Abbildung4.3:Use-Case-Diagrammfur demDienstimportmit Lastbalancierung

Der Anwendungsfall Last bestimmen, der intern verwendetwird, greift bei Verwen-dung einer dynamischenLastverteilungsstrategie auf Lastinformationenzuruck, die


entwederper CachingoderPolling von denMonitorenzum Load Balancerubertra-gen wurden.DieserAnwendungsfall baut daherauf dem nachstenAnwendungsfallLastubermittlungauf.

4.1.1.4 Lastubermittlung

Die angesprocheneLastubermittlungist im Anwendungsfall ausAbbildung 4.4 dar-gestellt.Sie verlauft in zwei Stufen.Der Ubertragungder Datenvon denMonitorenan denLoad BalancergehteineNotifikation, die vom Server-MO abgeschicktwird,voraus.Dabei werdendie in den SensorendesServers angefallenenDatenan denzustandigenMonitor ubertragen.DieserberechnetausdeneingetroffenenInformatio-nendiebenotigtenLastmetrikenundtragtdiesein seinelokaleMIB ein.Die Lastinformationenwerdenin Abhangigkeit vondereingesetztenAktualisierungs-trategie andenLoadBalancerubermittelt.Bei einerCaching-Strategie wird der An-wendungsfall Last schicken (Caching) durchlaufen,bei einer Pollingstrategie wirdvom Load Balancerder analogeFall Last erfragen (Polling) angewendet.In beidenFallen wird die ubermittelteLast bis zur nachstenAktualisierungim Load Balancergespeichert.

Last im LoadBalancer merken

Last schicken(Caching)

Last erfragen(Polling)

eintragenLast in MIB

Monitor

Load Balancer

Server-MOübertragen

Notifikation "Benutzt"

"Benutzt"

"Benutzt"

Abbildung4.4:Use-Case-Diagrammfur dieUbermittlungderLastvondenMonitorenzumLoadBalancer

4.1.1.5 Dienstnutzung

Bei der Dienstnutzungruft ein Dienstanbieteranhanddeszuvor im AnwendungsfallDienstimport/LastbalancierungimportiertenDienstangebotsdie gewunschteOperati-oneinesDienstanbietersauf.


Dienstnutzer Dienstanbieter

Sensordurchlaufen

Dienstnutzung

"Benutzt"

Abbildung4.5:Use-Case-Diagrammfur dieDienstnutzung

Wie derAbbildung4.5 zu entnehmenist, mußauf derDienstanbieterseitenebendereigentlichenDienstbearbeitungnoch der Anwendungsfall Sensordurchlaufen aus-gefuhrt werden,da sich durchdie Dienstbearbeitungdie LastparameterandernunddementsprechendneuerfaßtundalsNotifikationverschicktwerdenmussen.

4.1.1.6 Dienstabmeldung(Withdraw)

Dasin Abbildung4.6gezeigteZuruckziehen(Withdraw) einesDienstangebotserfolgtvollkommenanalogzumDienstexport. Zur AbmeldungmußderbeimExportvorge-nommeneEintragwiederausderDiensttabelledesTradersentferntwerden.

Dienstanbieter Trader

Dienstangebotlöschen

(Withdraw)Dienstabmeldung

"Benutzt"

Abbildung4.6:Use-Case-Diagrammfur dieDienstabmeldung

Ein eventuellesAbmeldenausdemManagementsystemerfolgt unabhangigdavon imAnwendungsfall DeregistrierungvonServern.

4.1.1.7 Deregistrierung von Servern

Auch die Deregistrierungvon Servern lauft – wie in Abbildung 4.7 zu sehenist –analogzurRegistrierungvonServernbeimManagementsystem.DieBeendigungeinesServersfuhrtzurDeregistrierungdeszugehorigenMOs.DerentsprechendeEintraginderMIB desMonitorswird dabeigeloscht.Im AnschlußnimmtderMonitor seineAgentenrollegegenuberdemrestlichenSystemwarundsorgt beimLoadBalancerfur dieDeregistrierungdesabzumeldendenServer-


MO. Dies geschieht,indemder zu diesemMO gehorige Server-Monitor-EintragimLoadBalancergeloschtwird.

Server-Eintragin der MIB löschen

Monitor

Load Balancer

Deregistrierungbeim Loadbalancer

Server-Monitor-Eintrag löschen

Server-MObeim Monitor

Deregistrierung

"Benutzt"

"Benutzt"

"Benutzt"

Abbildung4.7:Use-Case-Diagrammfur dieDeregistrierungvonServern

4.1.2 Ar chitektur und Verhalten desModells

Ein Softwaremodellbeinhaltetim wesentlichenzwei Aspekte:die statischeArchitek-tur und dasVerhaltendesSystems.Die Architektur ergibt sich ausden identifizier-ten Komponentenund den darin enthaltenenKlassen.Das Verhaltensetztsich ausderFunktionalitat einerKlasse,sowie demZusammenspielzwischendenjeweiligenKlasseninstanzenzusammen.Diesestatischenund dynamischenAspektewerdenindenfolgendenAbschnittenbeschrieben.Die in denAnwendungsfallenauftretendenAkteurebilden– dasieTeil desSystemssind – unmittelbardie KomponentendesSystems.Der DienstanbieteraspektsowiederMO-AspektdesServerswerdenallerdingszu einereinzigenServer-Komponentezusammengefaßt.AusihrerRolleinnerhalbdesVerteiltenSystemsherausist dieVerteilungderKompon-tenaufdieeinzelnenRechnerknotenvorgegeben.LediglichbezuglichzweierBestand-teiledesSystemexistierteinEntscheidungsspielraum.Die Entscheidung,dieMonitorenichtalsBestandteildesServers,sondernalsseperatenProzeßzu modellieren,wurdebereitsin der AnforderungsspezifikationausKapitel 3 getroffen. Fur denLoad Ba-lancerbietet es sich an, eine zentraleKomponentezu verwenden,da diesemit derebenfallszentralenTraderkomponenteengzusammenarbeitensoll.Die konkreteVerteilungdereinzelnenKomponentenist in Abbildung4.8dargestellt.Siegibt einenerstenUberblickuberdaserstellteModell.


Client

Trader-Knoten*Trader

*Server-Knoten

übermitteln

ServerDienstexport

import

Servernutzung

Austausch vonManagementinformationen

Dienst-

Client-Knoten

Lastbalancierungvornehmen

Sensordaten

MonitorLoad Balancer

Abbildung4.8:Verteilungsdiagrammfur dasGesamtmodell

DasModell siehtdemnachfur jedenRechnerknoten,aufdemeinServer arbeitet,einedavonunabhangigeMonitorkomponentezudessenUberwachungvor. DieseMonitor-komponentestehtaußerdemmit der Load Balancer-Komponente,die sich auf demgleichenRechnerknotenwie dieTraderkomponentebefindet,in Verbindung.Die Tra-derkomponentearbeitetmit der Load Balancer-Komponentezusammen,um bei Im-portanfragendieLastbalancierungvornehmenzu lassen.

importOffer

register_server

exportOffer

getSubtypesbalanceOffer

poll_load

Dienstnutzung

sensordata

withdrawOffer

deregister_server

push_load

register_sensor

deregister_sensor

Client

ServerMonitorTraderTypmanager LoadBalancer

Abbildung4.9:Sequenzdiagrammfur dasGesamtsystem

Bevor die einzelnenKomponentennahervorgestelltwerden,wird derenZusammen-spiel durchdasSequenzdiagrammin Abbildung 4.9 beschrieben.DiesesDiagramm


ergibt sichunmittelbarausdenAnwendungsfallen.Ein neugestarteterServer meldetsichzunachstinnerhalbdesManagementsystemsan.SeinzugehorigerMonitor reichtdazudessenRegistrierungandenLoadBalancerweiter. Im AnschlußdaranexportiertderServer seinDienstangebotandenTrader. Ein Client, dereineImport-AnfrageandenTraderstellt, lost dadurcheineKommunikationdesTradersmit demTypmana-geraus,dadie UntertypendesgewunschtenDienstesbestimmtwerdenmussen.DerTraderinformiert denLoadBalanceruberdie gefundenenDienstangebote.Dieserer-mittelt danndie Lastder jeweiligenDienstanbieterundliefert die unterLastaspektenoptimierteDienstangebotsmengezuruck.Bei deranschließendenDienstnutzungdurchdenClient falleninnerhalbdesServersensorsDatenan,diezumMonitor undggf. perCachingauchan denLoad Balancerubertragenwerden.Vor der TerminierungziehteinServerseinDienstangebotbeimTraderzuruckundderegistriertsichinnerhalbdesManagementsystems.

4.1.2.1 Server

Die Serverkomponentesetztsich, wie in Abbildung 4.10 zu sehenist, nebendemHauptprogrammmain, das den Server in das CORBA-Systemeinklinkt, aus zweigrundlegendenKlassenzusammen.

mainServer_i

Server"Interface"

Sensor

Monitor

monitor

Abbildung4.10:KlassenstrukturdiagrammderServerkomponente

Die KlasseServeri beinhaltetdie eigentlicheFunktionalitat, die von einemServerangebotenwird. DieseFunktionalitat verursachtdie Last, die in dem Systemver-teilt werdensoll. Die angebotenenOperationenwerdennachaußenhin uberdie IDL-SchnittstelleServerangeboten.Serveri stellt eineImplementierungderSchnittstelleServerdar.Die zweitenKlasserealisiertdenSensor, derdieLastdaten,die in diesemServeranfal-len,erfaßtunduberdie IDL-SchnittstellemonitorandenlokalenMonitor weiterleitet.NebendemVerschicken von solchenLast-Notifikationensetztein SensorobjektdieMonitorkomponenteauchuberdenStartunddie BeendigungseinesServerobjektsinKenntnis.Die konkreteImplementierungderSensor-Klasseist in Abschnitt4.2.1be-schrieben.Die im SensorermitteltenLastdatenwerdenuberdie in Abbildung 4.11dargestellteIDL-StrukturdefinitionLoadTypereprasentiert.DiesesFormatist flexibel genug,um


im ganzenSystemzur UbertragungderLasteingesetztzu werden,daesunterschied-licheMetrikenvorsieht.

interface loadbalancing_t ypes{

enum LoadmetricType {SERVICETIME_REALTIME,SERVICETIME_PROCESSTI ME, PROCESSTIME_REALTI ME_RATI O,QUEUELENGTH,ESTIMATED_TIME_TO_WORK, ON_IDLE, REQUEST_RATE,USAGE_COUNT,HOST_LOAD, UNVALID};

struct LoadType {LoadmetricType loadmetric;float loadvalue;};

};

Abbildung4.11:IDL-Spezifikationfur die Lastinformationen,die im Systemubertra-genwerden

4.1.2.2 Monitor

Die Monitorkomponentemußim wesentlichendieManagementInformationBasefurdie lokalenManagedObjectsverwaltenund demLoad BalancerdenZugriff daraufermoglichen.Der Anforderungsspezifikationentsprechendwird ein proprietaresMa-nagementeingesetzt,daslediglich die zu balancierendenServer und derenLast um-faßt.DasKlassenstrukturdiagrammdesMonitorsist in Abbildung4.12zusehen.Die MIB,in der die Lastinformationender lokalenServer gespeichertsind,wird uberdie bei-denKlassenServerEntryListundServerEntrymodelliert.Fur jedenregistriertenSer-ver wird eine Instanzder KlasseServerEntryangelegt und durchdie Listen-Klasseverwaltet.In deneinzelnenServerEntry-Objektenwird dievondenSensorenubermit-telteLastgespeichert.Da dasManagementsystemunterschiedlicheLastmetrikenun-terstutzensoll, werdendortalleLastinformation,dievomSensorin unterschiedlichenMetrikenubermitteltwerden,gespeichert.AußerdenKlassen,die fur die RealisierungderMIB benotigt werden,wird nochdieKlasseMonitor i benotigt, diedieMonitor-Schnittstelleimplementiert.Die Operatio-nen,die von denSensorenaufgerufenwerden,sinddort als

”oneway“ deklariert.Da

dieseasynchroneKommunikationlokal stattfindet,kannderenGeschwindigkeitsvor-teil genutztwerden,ohnebefurchtenzu mussen,daßdieNachrichtenbei derUbertra-gungdurchNetzwerkfehlerverlorengehen.Die ubrigenOperationender Schnittstellewerdenvom Load Balanceraufgerufen.poll load wird verwendet,um durchPolling LastinformationenausderMIB desMo-nitorszuerfragen.Die zweiteOperationschaltetvonPollingaufCachingum.Fur die Kommunikationin der umgekehrtenRichtunggreift der Monitor wiederumauf die SchnittstelledesLoadBalancerszu. Im wesentlichenhandeltessich um dieOperationenzur RegistrierungundDeregistrierungvon Servernundzur UbertragungvonLastdatenim Caching-Betrieb.


main

ServerEntryListMonitor_i

load_balancer

ServerEntry

ServerLoad

*

insert_server(Server)delete_server(Server)insert_load(Server,Load)

set_server(Server)get_server():Serverinsert_load(Load)get_load(Metrik):Load

get_load(Server,Metrik):Load

monitor"Interface"

register_sensor(Server)deregister_sensor(Server)sensordata(Server, Load)poll_load(Server,

switch_polling_caching(...)Metrik):Load

LoadBalancer

Abbildung4.12:KlassenstrukturdiagrammderMonitorkomponente

4.1.2.3 Trader

Die Struktur der Traderkomponente konnte von der existierenden Trader-Implementierungubernommenwerden.Die dortverwendeteKlassenstrukturist in Ab-bildung4.13wiedergegeben.ZusatzlichhatdieKlasseTrader i Zugriff aufdieKlasseLoadbalanceri, um dessenLastbalancierungsoperationenaufrufenzu konnen,wennpassendeDienstangebotegefundenwurden.

Loadbalancer_i"friend"

*

ContextTableItem

ContextName

addService(...)searchTable(...)withdraw(...)

ContextTable

addContextAndService(...)searchContext(...)withdraw(...)

ServiceTable

addService(...)searchTable(...)withdraw(...)

*matchAgainstAll(...)

servicePropertyValuesserviceInterfaceIdserviceTypeDescription

ServiceTableItem

Nametypemanagernametypemanager

trader"Interface"

exportOffer(...)importOffer(...)withdrawOffer(...)

Trader_i

Abbildung4.13:KlassenstrukturdiagrammderTraderkomponente


Die KlasseTrader i realisiertdieIDL-SchnittstellederTradingoperationen.Dieseent-sprechenderalterenODP-Traderspezifikation[ISO94]. AusdieserSpezifikationergibtsichauchdie StrukturderDiensttabelle,die sichausdenKlassenContextTable, Con-textTableItem, ServiceTableundServiceTableItemzusammensetzt.Die eigentlichenDienstangebotesind in Instanzenvon ServiceTableItemgespeichert.Laut der verwendetenODP-Spezifikationwerdendie DienstangebotedurchKontex-te strukturiert.JederKontext wird durchein ContextTableItem-Objekt reprasentiert.Die in einemKontext enthaltenenDienstangebotesind in einemServiceTable-Objektzusammengefaßt.Bei derSuchenacheinempassendenDienstangebot(importOffer2)wird in der KlasseContextTable die Nametypemanagerkomponenteaufgerufen,umdie passendenDienstuntertypenzu bestimmen.Von den in FragekommendenCon-textTableItem-Objektenausgehendwird dannnachpassendenDienstangebotenin de-renDiensttabellegesucht.FallseinpassenderEintraggefundenwurde,tragtsichdieserin dieErgebnislisteein.An dieserStelle nimmt der Trader ublicherweisedie Optimierungbezuglich derDienstattributevor. HierzukannuberdenParametermatchingConstraintseinDienstat-tribut angegebenwerden,dasminimiertodermaximiertwerdensoll. DieseStellebie-tet sich auchan, um uberdie Friend-Klasseloadbalanceri mit der Load Balancer-Komponentezusammenzuarbeiten,dain diesemMomenteinneuesDienstangebotge-fundenwurde,dasfur dieLastbalancierungin Fragekommt.DerLoadBalancerkanndannbeginnen,fur diesesDienstangebotdie Lastzu ermitteln.Da die Dienstvermitt-lungunterBerucksichtigungderLasterfolgensoll, darfderTraderseineOptimierungnun nicht mehr lediglich bezuglich desDienstattributs vornehmen,vielmehrmußernun alle in FragekommendenDienstangebotezuruckliefern,damit im AnschlußeinKompromißzwischenLastundDienstattributierunggefundenwerdenkann.DieserKompromißwird uberein Regelwerk getroffen,dessenModell in dernunfol-gendenBeschreibungdesLoadBalancersvorgestelltwird. Die genaueImplementie-rungwird in Abschnitt4.2.4.4erlautert.

4.1.2.4 Load Balancer

Die Load Balancer-Komponentebenotigt fur ihre Arbeit eine Tabelle, in der diefur jedenServerbenotigtenManagementinformationenabgelegt werden.DesweiterenkommteineTabellezumEinsatz,in diefur jedesvomTradergefundeneDienstangebotein Elementhinzugefugt wird. In jedemElementist die LastdeszugehorigenServersund derWert deszu optimierendenDienstattributsgespeichert.Nachdemder TraderseineDiensttabellendurchlaufenhat,wird fur jedenEintragin dieserTabelledesLoadBalancersdurchein Regelwerk einePunktzahlberechnet,die sich ausder Last unddemAttributwertergibt. AufgrunddieserPunktzahlkanndanndasDienstangeboter-mittelt werden,dasdenbestenKompromißdieserbeidenWertedarstellt.Die genaueKlassenstrukturderLoadBalancer-Komponenteist in Abbildung4.14zusehen.Die HauptklasseLoad balanceri realisiertdie load balancer-Schnittstelle.Ne-benderRegistrierungundDeregistrierungvon Servernnimmt siepushload-Aufrufe


insert_load(...)

ServerMonitor-Table

IORHash

hash(Server) registerServerMonitor(...)

lookup_load(...)

*

HashTableItem

store_pointer(...)is_empty()

Monitormonitor

ServerMonitor-TableItem

PointerToHashedItem

get_pointer()

Load_balancer_i

initScoretable()

getBestscoredItem(...)insertScoretable(Service)

ServerMonitor

registerServerMonitor(...)

getServer()getMonitor()getLoadStoreItem()

ScoreTable

minPropertymaxPropertyminLoadmaxLoad

insertNewService(

updateTableloads()Service, Property)

AndReturnMinimal()calcTablescores-

*

ScoreTableItem

ServicePropertyLoadScore

deregisterServerMonitor(...)

deregisterServerMonitor(...)

LoadStoreItem{abstract}

CachingPollingHistory

getMetricNeeded()setLoad(...)getLoad()

LoadStoreItem-ImplementationImplementedLoadmetric

load_balancer"Interface"

registerServer(...)deregisterServer(...)push_load(...)switch_polling_caching(...)

Abbildung4.14:KlassenstrukturdiagrammderLoadBalancer-Komponente

entgegen,die im Caching-BetriebvondenMonitorenandenLoadBalancergeschicktwerden.DaruberhinausbietetdieseKlasseOperationenan,die vonderFriend-KlasseTrader i aufgerufenwerden,um eineDienstangebotsmengebezuglich der Serverlastzubalancieren.Zur Verwaltungder Managementinformationenwird die KlasseServerMonitorTablemit ihren Hilfsklasseneingesetzt.Da dieseglobaleMIB sehrviele Eintrageenthal-tenkann,wird derZugriff, deranhandderServerschnittstellen-Identifikationerfolgt,ubereineHashtabellebeschleunigt[CLR94]. Die benotigteHashfunktionwird vonderKlasseIORHashbereitgestellt.Die in den HasheintragengespeichertenObjektevom Typ ServerMonitorTableItementhaltenzujedemServerdenMonitor, derz.B.beiPolling-Anfragenfur siezustandigist.Die vondemjeweiligenMonitor ubermitteltenLastinformationenwerdenin einemObjekt,daseineImplementierungderabstraktenKlasseLoadStoreItembereitstellt,ge-speichert.Dazuenthalt ein ServerMonitorTableItem-ObjekteinenZeigerauf ein der-


artigesLastspeicherungsobjekt.Fur dieLastreprasentationwurdeeineabstrakteBasis-klassegewahlt, um denEntwurf flexibel zu halten.Von dieserabstraktenBasisklassesinddie jeweiligenKlassen,dieunterschiedlicheLastverteilungsstrategienimplemen-tieren,abgeleitet.In diesenKlassenkonnenverschiedenenLastmetrikenzumEinsatzkommen.DasobenangesprocheneRegelwerk unddie abstrakteLastklassesetzenle-diglich voraus,daßdasErgebnisder jeweiligen Lastverteilungsstrategie uber eineneinzelnenZahlenwertausgedrucktwerdenkann.DasRegelwerk, daseinenKompromißzwischenLast und Dienstattributgute findensoll, ist in der KlasseScoreTable angesiedelt.DieseKlassewird bei jeder Import-AnfrageandenTraderneuinstantiiert.Die in einersolchenInstanzenthalteneTabellevon ScoreTableItem-Objektenwird wahrendderAbarbeitungder Importanfrageauf-gebaut.Bei jedempassendemDienstangebotruft derTrader, derdurchdieDeklarationals

”friend“ Zugriff auf denLoadBalancerhat,die MethodeLoad balanceri::insert-

Scoretableauf. Dieselegt uberdie MethodeScoreTable::insertNewServiceein neuesScoreTableIteman.Dort wird zunachstder jeweilige DienstanbieterunddessenWertdeszuoptimierendenAttributsvermerkt.Nachdemder Traderalle passendenDienstanbietergefundenhat,wird die MethodeScoreTable::updateTableloadsaufgerufen.Diesebefragtdie LastverteilungsstrategiedeszudemDienstanbietergehorendemLoadStoreItemnacheinemZahlenwert,derdieLastdesentsprechendenServersbeschreibt,und tragt ihn in dasScoreTableItemein.DiesesAktualisierungfindeterststatt,nachdemdie kompletteDienstangebotsmengefeststeht,sodaßalleLastinformationenin etwagleichalt sind.DadurchkonnenAnde-rungender Last,die sich seit der AufnahmeeinesDienstangebotsin die ScoreTableergebenhaben,nochberucksichtigtwerden.Dies ist besondersdannvon Bedeutung,wenndieDauereinerImportanfragesehrgroßist.Da nundie beidenInformationen,auf denenderzu findendeKompromißberuht,vor-liegen,kannnundurchdieMethodeLoad balanceri::getBestScoredItembzw. Score-Table::calcTablescoresAndReturnMinimaldasRegelwerkaufgerufenwerden.Als Er-gebniswird derDienstzuruckgegeben,derunterVerwendungder jeweils implemen-tiertenKompromiß-Strategie die bestePunktebewertungerhaltenhat.EineBeschrei-bungderimplementiertenStrategiewird in Abschnitt4.2.4.4gegeben.

4.1.2.5 Client

Die Modellierungvon Clientsliegt außerhalbderAufgabenstellungdieserArbeit. AndieserStellesoll deshalbnur kurz daraufeingegangenwerden,daßeseinemClientslaut Anforderungsspezifikationmoglichseinsoll, Einflußauf die ParameterdesLoadBalancerszunehmen.Da derEinsatzdesLoadBalancerstransparentinnerhalbdesImport-Vorgangserfol-gensoll, mussendie gewunschtenParameteruberdie Import-Operationder Trader-Schnittstelleangegebenwerden.Der neuesteODP-Standard[ISO96] sieht fur die Import-Operationu.a.die AngabevonscopingCriteriavor, anhanddererBedingungenandie Import-OperationdesTra-

4.2.ImplementierungdesModells 59

dersgestelltwerdenkonnen.DieswareauchdergeeigneteOrt, um Vorgabenfur denLoadBalancerunddessenRegelwerkzumachen.In der Import-OperationdeszugrundeliegendenenTradersist ein solcherParameternochnichtvorgesehen,weshalbauf andereParameterausgewichenwerdenmuß.Es bietetsich der ParameterserviceOfferPropOfInterestan, uberdenmitgeteiltwer-denkann,welcheDienstangebotseigenschaftenermittelt werdensollen.Die Seman-tik diesesParameterswurdedahingehenderganzt,daßdurchdie AngabebestimmterSchlusselworterdie VerwendungdesLoadBalancersein- oderausgeschaltetwerdenkannbzw. von denDefaultparameterndesRegelwerksabweichendeParameterange-gebenwerdenkonnen.Nahereshierzufindetsich in dernun folgendendenBeschrei-bungderImplementierungdesvorgestelltenModells.

4.2 Implementierung desModells

Die KlassendesbeschriebenenModellslassensichunmittelbarin entsprechendeC++-Klassendefinitionenubertragen.DasModell laßtjedochaucheinigeAspekteder Im-plementierungoffen. Insbesonderedie verwendetenLastmetrikenunddasRegelwerkbzw. dessenKompromiß-Strategiewurdenbewußtflexibel modelliert,sodaßverschie-densteImplementierungenmoglichsind.Im folgendenwird daherein besondererSchwerpunktauf die hierfur tatsachlichver-wendeteImplementierungbzw. die zugrundeliegendenAlgorithmengelegt. Daruber-hinauswird aberauchauf einigeweitereImplementierungsdetailseingegangen,diefur dasAnwendungsfeldderLastbalancierungbesondersinteressantsind.

4.2.1 Sensor

4.2.1.1 Erfassungder Meßdaten

Die in denServernbefindlichenSensorenmussenverschiedeneInformationenerfas-sen,anhanddererAussagenuberdieAuslastungdesServersgetroffenwerdenkonnen.Zur Ermittlung dieserDaten werdenFilter verwendet,die das Orbix-SystemzurVerfugungstellt. Zu Beginn undEndeeinesentferntenMethodenaufrufswird anins-gesamtachtStellenein derartigerFilter aufgerufen.Abbildung4.15zeigteinenent-ferntenMethodenaufrufund die Filterpunkte,die dabeidurchlaufenwerden.BevoreinMethodenaufrufeinenRechnerknotenverlaßt,werdendiezu ubertragendenDatenin ein einheitlichesFormat ubertragen.Wenn ein entfernterMethodenaufrufan ei-nemRechnerknoteneintrifft, wird die einheitlichenDarstellungwiederin die interneReprasentationumgewandelt.DieserMechanismuswird als Marshallingbezeichnet.Orbix bietetvor undnachjedemMarshallingvorgangeinenFilterpunktan,in denbe-nutzereigeneObjekteeingeklinktwerdenkonnen.Hierzumussendiesevondervorde-finiertenKlasseCORBA::filter abgeleitetwerdenunddie MethodenderbetreffendenFilterpunkteneudefinieren.


PostMarshaloutReply outReply

PreMarshalPostMarshalinReply

PreMarshalinReply

Marshalling Marshalling

inRequestPreMarshal

inRequestPostMarshal

outRequestPreMarshal

outRequestPostMarshal

Marshalling Marshalling

Client Server

Abbildung4.15:Die Orbix-Filterpunkte

Weil die Sensorenlediglich DatendesServerserfassensollen,wurdennur die Filter-punkteinnerhalbdesServersverwendet.DabereitsdasMarshallingeinegewisseLastverursacht,wurdendie FilterpunkteinRequestPreMarshal und outReplyPostMarshalinstrumentiert,umdierelavantenMeßdatenzuerfassen.Tabelle4.1fuhrtdie Informa-tionen,dieaufdieseWeiseerfaßtwerden,auf.

Information Berechnung

Bedienzeitin Echtzeit Endzeitin Echtzeit % Startzeitin EchtzeitBedienzeitin Prozeßzeit Endzeitin Prozeßzeit% Startzeitin Prozeßzeit

NutzbareCPU-Leistung Bedienzeitin ProzeßzeitBedienzeitin Echtzeit

Tabelle4.1:Meßdaten,die uberdieFilterpunkteerfaßtwerden

Zur ZeitmessungwurdenzweiverschiedeneFunktionen,dieSolaris2.xzurVerfugungstellt, verwendet.Fur die Messungder Echtzeitwurde gettimeofdaybenutzt.DieseFunktion liefert die aktuelleUhrzeit in Mikrosekundenauflosung.Zur MessungderProzeßzeitstehtdieFunktiontimeszurVerfugung,dieeineAuflosungvon10Millise-kundenbesitzt[SL94].In Tabelle4.1 ist die Warteschlangenlangenicht aufgefuhrt, da die herkommlichenFilterpunktenichtgeeignetsind,diesezuermitteln.Die achtvorgestelltenFilterpunktewerdennur zumZeitpunktderAufrufbearbeitungdurchlaufen.Auftrage,die eintref-fen, wahrendein Server beschaftigt ist, werdenin eineOrbix-eigeneWarteschlangeeingefugt unddurchlaufendenServer-Filter erst,wennsiederWarteschlangezur Be-arbeitungentnommenwerden.Zur LosungdiesesProblemswurdenThreadseingesetzt.EswerdenmindestenszweiThreadsbenotigt. Einer derThreadsbearbeitetdie eigentlichenAuftrage,der zweitenimmt neuankommendeAnfragenentgegen.Fur die Entgegennahmeder AnfragendurcheinenThreadbietetOrbix einenweiterenFilter an, der von der KlasseCOR-BA::ThreadFilter abzuleitenist. In diesemFall kannjedochnichtmehraufdieOrbix-eigeneWarteschlangenverwaltungzuruckgegriffen werden.Stattdessenmußeineei-geneWarteschlangenverwaltungimplementiertwerden.HierbeikanndannauchleichtdieWarteschlangenlangeermitteltwerden.


Da nebenlaufigeProzessezumEinsatzkommen,werdenfur denZugriff auf gemein-sameDatenstrukturenMechanismenzur Prozeßsynchronisationbenotigt [SG94].So-laris bietethierfur in der Thread-BibliothekSemaphorenund Mutexe, die einenge-genseitigenAusschlußgarantieren,an[GGM93]. Mit diesenMethodenkanndasvor-liegendeErzeuger-Verbraucher-Problembequemgelostwerden.Als Erzeugertritt derThread,der den ThreadFilter ausfuhrt und neu eintreffendeAnfragenin die Wart-schlangeeinfugt,auf.DerzweiteThreadentnimmtalsVerbraucherderWarteschlangeAnfragen,solangediesegefullt ist.

4.2.1.2 Kommunikation mit demMonitor

Die in denFilterpunktenermitteltenMeßdatenwerdendirekt nachihrer ErfassungandenlokalenMonitor ubertragen;hierfur werdenOneway-Aufrufeverwendet.Da sicheinServermit seinenFilterpunktennichtim selbenBetriebssystemprozeßwie derMo-nitor befindet,wird dieserAufruf uberdenORB abgewickelt. EineschnellereImple-mentierungzur KommunikationzwischenSensorundMonitor wareuberSharedMe-morymoglich[SG94].AufgrunddeswesentlichhoherenImplementierungsaufwandeswurdedieseVariantejedochnicht verwendet.Stattdessenwurdewie – im restlichenSystemauch– zurProzeßkommunikationaufCORBA zuruckgegriffen.

4.2.2 Monitor

4.2.2.1 Lastmetriken in der ManagementInformation Base

Der Monitor verwaltet in seiner MIB die von den Sensoren eingehendenLastinformationen. Diese Informationen treffen in vier verschiedenenMetri-kenein:SERVICETIME REALTIME, SERVICETIME PROCESSTIME,PROCESSTI-ME REALTIME RATIO, QUEUELENGTH(vgl. Abschnitt4.2.1.1).Aus diesenLast-metrikenkonnenweitereberechnetwerden.Die Monitorimplementierungverwendetfur ihre proprietare MIB nebeneinfachenEintragen,in denendie von denSensorengeliefertenMetriken gespeichertwerden,auch

”intelligente“ Eintrage,die ihrenWert selbstbzw. ausdenubrigenEintragenbe-

rechnenkonnen.Außereinergleitendenbzw. exponentiellenDurchschnittsbildungfurbestimmteMetrikenwurdebeispielhaftdieim folgendenvorgestellteMetrik ESTIMA-TED TIME TO WORKzurSchatzungderverbleibendenAntwortzeitimplementiert.Die exakteverbleibendeAntwortzeit & ')(+*-, einesServerszumZeitpunkt * ergibt sichausdenverbleibendenBedienzeiten&�.0/ der einzelnenim SystembefindlichenAuf-trage 132 :

& ')(�*-,)4!5 2 &�.0/76DadieBedienzeiten&�.0/ in derPraxisallerdingsnicht im vorausbekanntsind,mussengeschatzteBedienzeiten&98.:/ verwendetwerden.Die SchatzungderverbleibendenAnt-wortzeitlautetdementsprechend:


& 8' (�*-,)4!5 2 & 8.0/ 6In dervorliegendenImplementierungwird alsgeschatzteBedienzeit&;8.:/ fur jedenAuf-trag 1<2 dergleitendeDurchschnitt& . (+*-, verwendet,dersichausdenBedienzeitenderzuruckliegendenAuftrageergibt. Fur denFall, daßzumZeitpunkt *�= geradeein Auf-trag denServer verlaßtund dabeinoch >?(�*�=@, Auftragein der Warteschlangestehen,kanndieverbleibendeAntwortzeitdurch

& 8' (�*�=A,)4B>?(�*�=@,DC@& . (+*�=E,geschatztwerden.Fur beliebigeZeitpunkte* mußberucksichtigtwerden,daßsichdiegesamteverbleibendeAntwortzeit jeweils durchdie BearbeitungdesaktuellenAuf-tragsverringert.Der Zeitpunkt,zu demdermomentanim Server bearbeiteteAuftragder Warteschlangeentnommenwurde,sei *�= . Solangekeine neuenAuftragehinzu-kommen,ergibt sichalsSchatzungzumZeitpunkt * :

& 8' (�*-,)4 F�Gfalls &98' (+*�=E,D%H(+*I%J*�=A,LK G& 8' (�*�=@,D%M(�*I%N*�=@, sonst

fur *PO�*�=Q6Falls wahrendder Bearbeitungein neuerAuftrag hinzukommt, erhoht sich dieseSchatzungentsprechendumdenWert & . (+*-, :& 8' (+*-,LRS4M& 8' (�*-,�TU& . (�*-,)6DasPrinzip der vorgestelltenSchatzungist in Abbildung 4.16 illustriert. Zum Zeit-punkt *�= befindensich dort genau >?(�*�=A, Auftrage im System,so daß sich fur diegeschatzteverbleibendeAntwortzeitderWert & 8' (�*�=A,V4W>?(�*�=A,ICE& . (�*�=@, ergibt. Im Lau-fe der Zeit verringertsich dieserWert kontinuierlichbis zum Zeitpunkt *�X , an demein neuerAuftrag die Warteschlangebetritt. WahrenddiesesZeitraumshat sich dieSchatzungumdenBetrag (+*�X0%*�=E, verringert.DurchdenneuenAuftragerhohtsichdieSchatzungumdiegeschatzteBedienzeit& . (�*�XY, .

T (

t )

jq(

t )ST (

t )_

j

RT (

t)*

S_j+

20

. T (

t )

tjt t’

S_

t j+1

_ Sq(

t )

j+1

+T

(t’)

t’’

S_+

T (

t’’)j+

1

t j+2

j-(

t’-t )

Abbildung4.16:SchatzungderverbleibendenAntwortzeit


ZumZeitpunkt *�=[Z]\ verlaßteinAuftragdenServer, sodaßdiegeschatzteverbleibendeAntwortzeitneuberechnetwird. DadieBearbeitungdesgeradeabgefertigtenAuftragslangeralsdiezuvor verwendetedurchschnittlicheBedienzeitgedauerthat,erhohtsichdieserDurchschnitt.Die aus& . (�*�=[Z]\^, neuberechneteSchatzungfallt daherhoherausalsursprunglichangenommen.

Im weiterenVerlaufverringertsichderSchatzwert & 8' (�*-, mit derZeit bis zur unterenGrenze0s. Zur Zeit *�X X betritt nochmalsein Auftrag dasSystem.SeineBearbeitungwird zumZeitpunkt *�=_Za` abgeschlossen.Da sichnunkeineAuftragemehrim Systembefinden,berechnetsichdiegeschatzteverbleibendeAntwortzeitzu0s.Dergeradebe-arbeiteteAuftragwurdeschnelleralserwartetbedient,sodaßsichbei *�=[Za` einSprungergibt.

Die zugehorigeImplementierungist in denAbbildungen4.17und4.18zusehen.

...delta=newqueuelength-queuelength. oldval ue;if (delta<=0)

// Warteschlange wurde kuerzer, d.h. Request beendet// Absolute Berechnung, um Fortpflanzungsfehler klein zu halten// und geaenderten Mittelwert der Bedienzeit ueberall einzubeziehen.insert_estimated_time_to_work(

newqueuelength*get_avg_servicetim e_rea ltime ());else

// Warteschlange wurde laenger, d.h. Request dazugekommen// Relativer Zuwachsinsert_estimated_time_to_work(get_est imate d_tim e_to_w ork()

+delta*get_avg_servicetime_realtime() );...

Abbildung4.17:EintragenderSchatzungderverbleibendenAntwortzeitin dieMIB

float ServerEntry::get_estimated_time_to_wor k(){

float value=estimated_time_to_work.value;long end_sec_real, end_usec_real;myClock.get_realtime(end_sec_real, end_usec_real);value-=(end_sec_real-estimated_time_t o_wor k.tim estamp _sec)

+(end_usec_real-estimated_time_to_w ork.t imest amp_usec)/1 00000 0.0;if (value<0)

value=0;return value;

};

Abbildung4.18:AuslesenderSchatzungderverbleibendenAntwortzeitausderMIB


4.2.2.2 Kommunikation mit demLoad Balancer

Wahrenddie in Abschnitt4.2.1.2beschriebeneKommunikationzwischenSensorundMonitor vonlokalerNaturist, erfolgtdieUbertragungvonDatenausMonitor-MIB andenLoadBalanceruberdasNetzwerk.Die verschicktenNachrichtenpaketesindrelativ klein,weil sievergleichsweisewenigeDatenenthalten.DadieseLastdatenabersehrhaufigubertragenwerden,lohntessich,ihr Aufkommennaherzubetrachten.Die Informationen,auf denendie Lastbalancierungberuht,solltenmoglichstaktuellsein.[MTS89,WT93] empfehlen– wie in Kapitel3 erwahnt–, keineLastinformatio-nenzuverwenden,derenAlter oberhalbderGroßenordnungderBedienzeitliegt,daessonstzueinersichzyklischaufschaukelndenUberlastungvoneinzelnenServernkom-menkann.Um dieszuverhindern,verschickendieMonitoreim Caching-BetriebzumEndejederDienstnutzungdie vom LoadBalancergewunschtenLastmetriken.EinigeMetriken,wiez.B.dieWarteschlangenlangeoderdiezuvor vorgestellteESTIMATED -TIME TO WORK-Metrik, werdenaußerdemauchzu Beginn einerDienstbearbeitungaktualisiert.Im Caching-Betriebfallendaherbei jederDienstnutzung– je nacheingesetzterMetrik– ein oderzwei Nachrichtenan,die andenLoadBalancerubertragenwerden.BeimPolling-Moduswerdenfur jedeDienstvermittlungdie benotigtenLastinformationenderin FragekommendenServer vondenjeweiligenMonitorenerfragt.In einergeschlossenenTrading-Domane,in derein Server genaudanngenutztwird,wenn er vom Tradervermittelt wurde, konneneinige Uberlegungenbezuglich desNachrichtenaufkommens,dasdurcheinePolling- bzw. Caching-Strategie verursachtwird, angestelltwerden.In diesemFall ruft jedeDienstvermittlung,dersichentspre-chendeineDienstnutzunganschließt,selbereineAnderungderLast– unddamiteinenAktualisierungsbedarf– hervor.Fur einederartgeschlosseneTrading-Domaneergibt sich bezuglich der hervorgeru-fenenNetzlastein Vorteil fur die Caching-Strategie. In einerDomanemit b in FragekommendenDienstanbietern,verursachteineImportanfrageandenTraderb Polling-Anfragen.Bei einer Caching-Strategie wurde eine Importanfragemit anschließen-der Dienstnutzung– in Abhangigkeit von der verwendetenLastmetrik – ein oderzwei Caching-Updatesnach sich ziehen.Spatestensbei mehr als zwei Dienstan-bietern,die dasgewunschteDienstangebotexportieren,ist demnacheine Caching-Aktualisierungsstrategiefur dieLastubermittlungzubevorzugen.Fur denFall, daßeinServerauchunabhangigvoneinerTradervermittlunggenutztwirdodersichunabhangigvon derServernutzunganderndeLastmetriken(z.B. die Hinter-grundlasteinesRechnernknotens)verwendetwerden,verlierendieseUberlegungenallerdingsihre Gultigkeit. AllgemeineAussagenkonnenhierfur nicht mehrgetroffenwerden.Um dennochselbstin diesemFall eineoptimaleAktualisierungsstrategie,die amwe-nigstenNachrichtenaufkommenzur Folgehat,zuverwenden,wurdeeinedynamischeUmschaltungzwischenCaching-undPollingbetriebimplementiert.In [Kup95] ist ein


Automatismusbeschrieben,der dies leistet.Ein derartigerAutomatismusvergleichtdie Zugriffsrateund die AnderungsrateeinesAttributs. Falls sich der Wert desAt-tributs ofter andertals er abgefragtwird, empfiehltsich zur Minimierung der Nach-richtenanzahlderEinsatzeinerPollingstrategie.Der umgekehrteFall liegt vor, wennein Attributwert ofter abgefragtalsgeandertwird. In dieserSituationist eineAktua-lisierungmittelsCachingoptimal.Der Automatismusist in Abbildung4.19durcheinSequenzdiagrammdargestellt.

sensordata

sensordata

poll_load

Caching)switch_polling_caching(

push_load

switch_polling_caching(Polling)

das LastattributZugriff auf

das LastattributZugriff auf

Lastattributwerts

LoadBalancer Monitor

Pollingstrategieaktiviert

Zugriffsrate > Änderungsrate?Ja: Umschalten!

aktiviertCachingstrategie

Änderung desLastattributwerts

Sensor

Änderung des

Änderungsrate > Zugriffsrate?Ja: Umschalten!

Pollingstrategieaktiviert

Abbildung4.19:DynamischeUmschaltungderAktualisierungsstrategie

Im Polling-BetriebkannderAttributanbieter– in dieserArbeit derMonitor – dieEnt-scheidung,auf Cachingumzuschalten,treffen.DemMonitor liegenin diesemFall diebeidenbenotigtenInformationenvor. Die Anderungsrateergibt sichausdemzeitlichenAbstand,in demderSensorseineDatenandemMonitor verschickt.Die Zugriffsra-te kannausdemzeitlichenAbstand,in demdie Polling-AnfragendesLoad Balan-cerseingehen,bestimmtwerden.Falls die Zugriffsrategroßerals die Anderungsrateist, informiert der Monitor den Load Balancerdaruber. Dieserschaltetdannin denCaching-Betriebum,derin dieserSituationoptimalist.Im Caching-BetriebkannderMonitor nichtmehrdieZugriffsrateermitteln.DerLoadBalancerkannjetztaberausdeneintreffendenCache-UpdatesInformationenuberdieAnderungsrategewinnen.FallsdieAnderungsrategroßeralsdieZugriffsratedesLoad


Balancersist, schaltetdieseraufdenPolling-Betriebumundteilt diesdemzustandigenMonitor mit.NebendemAspektderNetzlastkannbeidenunterschiedlichenAktualisierungsstrate-gienauchnochderEinflußdieDienstvermittlungsdauerbetrachtetwerden.GegenuberderPolling-Strategie,dieerstbei dereigentlichenDienstvermittlungaufgerufenwird,hat die Caching-Strategie den Vorteil, daßdie benotigtenLastinformationenbereitsbei derderDienstvermittlungvorliegen.EineCaching-Strategie versprichtdahereinekurzereDienstvermittlungszeit.Da die Abwagungzwischeneinerevtl. die NetzlastreduzierendenPolling-Strategieund einer die DienstvermittlungszeitverringerndenCaching-Stratgeiesubjektiv ist,konnenhierfur keineAutomatismenangegebenwerden.In der vorliegendenImple-mentierungkann kann daherbeim Vergleich der Anderungs-und Zugriffsrate ei-ne Gewichtung angegebenwerden.Nebender angesprochenensubjektiven Prafe-renzkann dadurchauchberucksichtigtwerden,daßdie beim CachingeingesetztenOneway-OperationsaufrufewegenderfehlendenRuckantwortgegenuberdensynchro-nenPolling-AnfragenwenigerNetzlastverursachen.

4.2.3 Trader

4.2.3.1 Verwaltung der Diensttabellen

Die VerwaltungderDiensttabellenkonntevon derbereitsvorliegendenTraderimple-mentierungubernommenwerden.Die strukturelleAssoziationder Kontext- und derDiensttabellenwurdebereitsim Klassenstrukturdiagrammin Abbildung4.13erlautert.Die ursprunglicheImplementierungderAbbildungderBaumstrukturauf die verwen-deteinterneDatenstrukturwar jedochfehlerhaftund mußtekorrigiert werden.DieBaumstrukturwurdedurcheineLISP-ahnlicheTochter-Schwester-Strukturreprasen-tiert. Zur TraversierungeinesTeilbaumswurdeeineRekursioneingesetzt,die verse-hentlichauchdieSchwesterndesStartknotensdurchlief.6

Die Reihenfolge,in der die Einschrankungder Dienstangebotsmengeerfolgt, ist inAbbildung4.20zu sehen.Anhanddesbei der Import-AnfrageangebenenKontextes,durchdendieDienstangebotsmengeunterorganisatorischenGesichtspunktenstruktu-riert wird, wird im erstenSchrittderStartknotendesabzusuchendenKontextteilbaumsbestimmt.JederdurchlaufeneKnotendesTeilbaumsenthalt eineDiensttabelle,in deralleDienstangebotedesjeweiligenKontexteseingetragensind.In nachstenSchrittwerdenfur jededieserDiensttabellendieDienstangeboteherausge-sucht,diedenmatchingConstraintsderImport-Anfrageentsprechen.Anhanddermat-chingConstraintskannein logischerAusdruckangegebenwerden,dendieDienstattri-bute einesDienstangebotserfullen mussen,um in die Ergebnismengeaufgenommenzuwerden.

6Der gleicheFehlermußteauchin der ImplementierungdesTypmanagers,der die selbeinterneReprasentationderBaumstrukturverwendet,behobenwerden.


costs=200 3

costs=170 2costs=80 5

costs=210 2costs=50 2

costs=160 4

costs=120 1costs=130 2costs=240 7

rwth1. Einschränkung

contextName="/rwth/info"

2. Einschränkung matchingConstraints.rule="costs<150"

3. EinschränkungserviceTypeDescription=2

costs=80costs=170

costs=200

costs=50costs=190

costs=130costs=240

costs=160

costs=120

Gesamter Datenbestand

Ergebnis

4. Einschränkungdurch Optimierung

Constraints.minMaxRule=matching-

"MINIMUM costs"

costs=50 2

durch Kontext

durch Bedingungen

durch Diensttyp

i5i4

info

i5

rwth

i4

info

Abbildung4.20:DienstauswahldesTraders

Die Uberprufung,obein DienstangebotuberhauptdengewunschtenDiensttypbereit-stellt, erfolgt erst in Schritt 3. Die hierbeiverwendetennumerischenDiensttypanga-ben stellenIndizesinnerhalbdesTypmanagersdar. Uber diesenTypmanagerist esaußerdemmoglich,Untertyp-BeziehungenzwischenverschiedenenDiensttypenfest-zulegen.In Schritt4 kanneineOptimierungdesbisherigenErgebnissesdurchgefuhrt werden.Hierzu kanndie ausgewahlteDienstangebotsmengebezuglich einesAttributs maxi-miert oderminimiert werden.Die Angabeder gewunschtenOptimierungerfolgt imImport-Aufruf uberdasStrukturelementmatchingConstraints.minMaxRule.Zusatzlich zu der bereitsvorhandenenMinimum- und Maximum-Optimierungsregelwurde eine Random-Auswahlwahlregel implementiert, die unabhangig von denDienstattributwertenzufallig einElementderErgebnismengeausSchritt3 alsDienst-angebotzuruckliefert.DurchVerwendungderRandom-Regel kannbereitseineeinfa-che,statischeLastverteilungrealisiertwerden.

4.2.3.2 Zusammenarbeitmit demLoad Balancer

Die Zusammenarbeitder Traderkomponentemit der Load Balancer-Komponenteer-folgt im wesentlicheninnerhalbvon Schritt 4. Im Anschlußan den dritten Schrittliegendie Kandidatenfur die Lastbalancierungendgultig fest, so daßsie demLoad


Balancermitgeteilt werdenkonnen.Da das weiter unten beschriebeneRegelwerkeinen KompromißzwischenDienstattributoptimierungund Lastoptimierungfindensoll, darf in Schritt 4 keine Optimierungbezuglich einer Diensteigenschaftdurch-gefuhrt werden.Stattdessenwird die MethodeLoadbalanceri::insert scoretable(...)aufgerufen,um die Dienstangebotein die Liste der durch das Regelwerk zu be-wertendenServer aufzunehmen.Der Quelltext der MethodeBalancedServiceTable-Item::matchAgainstAll(...), in derdie Schritte2 bis 4 implementiertsind,ist in Abbil-dung4.21auszugsweiseaufgefuhrt.

void BalancedServiceTableItem::matchAga instA ll(.. .){...if (matchAgainstMatchingConstraint(ma tchin gConstraint .rule )==tr ue){

if (matchAgainstType(servTypeDesc,idSeq) ==tru e){if (use_loadbalancer_flag){

// jedes gefundene Dienstangebot eintragen// 1. in die DienstangebotslisteserviceOfferDetailList_var[++index]= ...// 2. In die Scoretableprop_name=

matchingConstraint.minMaxRule.maxP roper tyName ();checkServicePropertyValues(servicePr opert yValue s,

prop_name, prop_val);property_value=atoi(prop_val.value);Loadbalancer_Ptr->insert_scoretable( score table_ Ptr,

serviceOfferDetailList_var, index, property_value);}else // kein Loadbalancer benutzen: alte Semantik:{

IndicatorType indicator=checkPropsAgainstMinMax(matchingCon strai nt.min MaxRule,

actualMinMax);switch(indicator){

case improves:serviceOfferDetailList_var->length(1) ;serviceOfferDetailList_var[index=0]= ...

break;case emptyOrEquals:

serviceOfferDetailList_var[++index]= ...break;

};};

};};

};

Abbildung4.21:EinfugeneinespassendenDienstangebotsin die TabelledesRegel-werks

NachdemderTraderseineDiensttabellendurchlaufenhat,stehtdasDienstangebotfestund dasRegelwerk desLoadBalancerkannaufgerufenwerden.Dies geschieht,wie


in Abbildung4.22,die denQuelltext derMethodeTrader i::importOffer2 enthalt, zusehenist, durchdenAufruf vonLoadbalanceri::get bestscoreditem.

void Trader_i::importOffer2(...){...if (use_loadbalancer)

my_scoretable=my_Loadbalancer->init _scor etabl e();// Eigentliche TradingfunktioncontextTable->searchContext( ... );// Angebot balancierenif (use_loadbalancer){

// Aus der Scoretable, in die der Trader parallel sein Angebot// eingetragen hat, den besten Eintrag suchenserviceofferindex=my_Loadbalancer-> get_b est_s coredi tem(

my_scoretable, minmax_flag, load_weight, property_weight, norm);};...

};

Abbildung4.22:Aufruf desRegelwerksdurchdenTrader

4.2.4 Load Balancer

4.2.4.1 Die globaleManagementInformation Base

Neben der eigentlichenLastverteilungsstrategie und dem Regelwerk zur Zusam-menfuhrungderErgebnissevonLoadBalancerundTraderwird eineglobaleManage-mentInformationBasebenotigt, in derdieubermitteltenLastinformationenderServergespeichertwerden.Die hierfur verwendeteKlassenstrukturwurdebereitsim Klas-senstrukturdiagrammausAbbildung4.14vorgestellt.NebenderSpeicherungmußsichdieKlasseServerMonitorTable, diedieMIB verwal-tet,auchumdieAktualisierungderDatenmittelsPolling-Anfragenbzw. nachCache-Updateskummern.Dabei– aberauchwahrenddesLastbalancierungsvorgangs– wirdsehroft auf dieseTabellezugegriffen. Der Zugriff erfolgt uber die Angabedesje-weilsrelevantenServers.Die IdentifikationvonverteiltenObjektenerfolgt in CORBAubereineinteroperableObjekt-Referenz(IOR). Hierbeihandeltessichum einecirca0,5 Kilobyte großeZeichenkette,die – uberASCII-Ziffern kodiert– denNamenderServerimplementierung,dessenSchnittstellentypunddenzugehorigenRechnernamenenthalt. Da einelineareSuchein derMIB-Tabellesehrviele langwierigeZeichenket-tenvergleichebenotigenwurde,wurdederZugriff auf die MIB ubereineHashtabellebeschleunigt.Der CORBA-StandardsiehteinederartigeHashfunktionvor, allerdingskanndie be-treffendeMethodenicht auf eine IOR, sondernnur auf ein instantiiertesCORBA-Objekt angewendetwerden.Da fur die in der MIB verwaltetenObjektejedochnur


derenIOR vorliegt, mußteeineentsprechendeHashfunktionzusatzlichimplementiertwerden.Dieseist in Abbildung4.23dargestellt.Zur Generierungvon moglichstein-deutigenHashwertenwird ausgenutzt,daßeineIOR uberwiegendausASCII-Ziffernbesteht.Dieseunterschiedensichlediglich in 4 Bits voneinander, weshalbdie einzel-nenZeichenjeweilsum4 Bits versetztzyklischzueinemlongaufaddiertwerden.

unsigned long IORHash::hash(const char* ior, unsigned long max){unsigned int ior_length=strlen(ior);unsigned long carry,value=0;for (unsigned int i=0;i<ior_length;i++){

value=(value<<4)+ior[i]; // 4 Bit-Shift und Zeichen dazuaddierenif((carry=value&0xf0000000)) // Wraparound notwendig?{ // Ja: Wraparound simulieren

value=valueˆ(carry>>24); value=valueˆcarry;}

}return value%max;

};

Abbildung4.23:Die verwendeteHashfunktionfur CORBA-Objektreferenzen

4.2.4.2 Kommunikation mit denMonitor en

Bevor die Lastdatenin die MIB des Load Balancerseingetragenwerdenkonnen,mussensie von denMonitorenzum Load Balancerubertragenwordensein. In Ab-schnitt4.2.2.2wurdenbereitsdie Caching-Strategie undein Automatismuszur dyna-mischenUmschaltungzwischenCachingundPollingvorgestellt.Die Polling-Strategiewurdeim LoadBalancerin einernebenlaufigenundeinernicht-nebenlaufigenVarianteimplementiert.Die Ermittlung der LastinformationeneinesServers durcheinenPolling-Aufruf er-folgt im Anschlußan den Eintrag deszugehorigen Dienstangebotsin die ScoreTa-ble. In dernicht-nebenlaufigenVarianteblockiertderentfernteOperationsaufrufmo-nitor::poll load(...)daherdie DienstvermittlungdesTradersbis die Antwort desMo-nitorsvorliegt. Um bei einemAusfall desMonitorsodereinerlangsamenNetzwerk-verbindungdennocheinenzugigenAblauf derDienstvermittlungzugarantieren,wur-de fur die Polling-Anfragenein gesondertesTimeout implementiert.Dazuwird dieZeit gemessen,die einePolling-Anfrageim Durchschnittbenotigt. DasTimeoutfureinenPoll-Aufruf ergibt sich auseinemVielfachendiesesDurchschnitts.Abbildung4.24zeigteinenAusschnittausdiesemCode,derdieCORBA-Environmentsnutzt,umdort eine– von derDefaulteinstellungabweichendes– Timeoutangebenzu konnen.Wird dieseZeit uberschritten,so wird vom CORBA-LaufzeitsystemeineExceptionerzeugt,in dereineAusnahmebehandlungfur denjeweiligenAufruf durchgefuhrtwer-denkann.Eshatsichgezeigt,daßdie vorliegendeOrbix-Implementierungbei kurzenTimeout-Vorgaben (im Bereich von wenigen Millisekunden) sporadischeine Timeout-


void ServerMonitorTable::poll_load(cons t char* server){

...mytimeout=servermonitortableitem->get _poll ing_d elay() ;CORBA::Environment env;env.timeout(2*mytimeout); // Timeout

// Startzeit messenmyClock.get_realtime(start_sec, start_usec);try{

current_monitor_ptr->poll_load(serv er,item->loadItem->get_metric_needed(),lo ad, env);

}catch (CORBA::COMM_FAILURE &sysEx) {

// Timeoutenv.clear(); // Exception entfernen

}// Endzeit messenmyClock.get_realtime(end_sec, end_usec);mytimeout=int((end_sec-start_sec)*100 0+(en d_use c-star t_use c)/10 00.0);// Antwortdauer merkenservermonitortableitem->insert_pollin g_del ay(my timeou t);...

}

Abbildung4.24:Timeoutbehandlungfur diePolling-Anfrage

Exceptionerzeugt,obwohl die angegebeneZeitspannenochgarnicht abgelaufenist.Um diesenFehlerin Orbix zuumgehen,empfiehltessichdaher, eineuntereSchrankevonca.1 Sekundefur dieTimeout-Vorgabeeinzusetzen.WahrenddesWartensauf die Poll-Antwort konntederTraderbereitsmit derDienst-vermittlungfortfahren,dadiebeimPollingerfragtenLastinformationenerstzumEndederDienstvermittlungbenotigt werden.Dies versuchtsich die nebenlaufigeVariantederPolling-Strategiezunutzezu machen.Die benotigteNebenlaufigkeit wurdedurchThreadsrealisiert.EinThreadstellteinen

”Prozeßim Prozeß“ dar, derunabhangigvomumfassendenPro-

zeßausgefuhrt werdenkann.Im zugrundeliegendenBetriebssystemSolaris2 ist einzweischichtigesNebenlaufigkeitsmodellimplementiert[SG94,GGM93]. Abbildung4.25zeigtdie dabeivorgenommeneUnterscheidungzwischenThreadsund leichtge-wichtigenProzessen.Die Threadsstellendie Einheitendar, mit denender Program-miererumgeht,die leichtgewichtigenProzessewerdenvom Betriebssystemverwen-det,um darin die Threadsauszufuhren.Nur die leichtgewichtigenProzessenehmenamCPU-Schedulingteil, wahrenddie Threadsauf einekooperative Zusammenarbeitangewiesensind,in dersiesicheinenleichtgewichtigenProzeßteilen.Ein Threadgibt

”seinen“ leichtgewichtigenProzeßab,wennerz.B.aufeineSemapho-

rewartetoderexplizit dieFunktionthr yield()aufruft.Solaris2 bemuhtsichzwar, je-demProzeßausreichendvieleleichtgewichtigeProzessezurVerfugungzustellen,den-


LeichgewichtigteProzesse

Threads

Prozeß 1 Prozeß 2 Prozeß 2

CPU

Betriebssystem

Abbildung4.25:DasThread-Modellin Solaris2

nochzeigtdie Praxis,daßdiesesBemuhennicht ausreichendist. Daherist eszusatz-lich moglich, gebundeneThreadszu erzeugen,die ihren

”eigenen“ leichtgewichtigen

Prozeßbesitzen.Der Quelltext in Abbildung 4.26 zeigt die Thread-Funktionen,die benotigt werden,umeinenOrbix-Operationsaufrufnebenlaufigabzusetzen.

...thread_t my_pollthread; // Zeiger auf Pollthread...// Gebundenen Thread erzeugenthr_create(NULL, 0, ServerMonitorTable::poll_load,

(void*)threadstuff, THR_BOUND,my_pollthread)// Dem neuen Thread die Chance geben, zu arbeitenthr_yield();...

Abbildung4.26:ErzeugungeinesgebundenenThreads

4.2.4.3 Lastverteilungsstrategien

Das dieserImplementierungzugrundeliegendeObjektmodellsieht fur die Speiche-rungundBewertungvon LastinformationeneineabstrakteBasisklasseloadstoreitemvor, vonderkonkreteImplementierungenabgeleitetwerden.Die entsprechendeKlas-senstrukturwurdebereitsin Abschnitt4.1.2.4beschrieben.Die in diesemModell vorgeseheneLastbalancierungerfolgt zweistufig,da nachderBewertungder Last auchnoch der besteKompromißzwischenTrader- und LoadBalancer-Ergebnisgefundenwerdenmuß.Die eigentlicheAuswahl einesServer ge-schiehterstim Regelwerk,dasim nachstenAbschnittbeschriebenist.Die eingesetztenLastverteilungsstrategienhabendahernur die Aufgabe,fur dasRe-gelwerk einenBewertungder Last vorzunehmen.Fur dieseArbeit wurden– nebender Traderauswahlstrategie RANDOM– drei verschiedeneLastverteilungsstrategienimplementiert.


Diesebasierenauf unterschiedlichenLastmetriken. In Abschnitt2.3.3wurdebereitsdaraufhingewiesen,daßdieLast,wie siedortdefiniertist, eineungeeigneteBasiszurLastverteilungist. Sieist in zweierleiHinsichtproblematisch.Zum einenberucksichtigtsie nur zuruckliegendeVermittlungen.Auftrage,die zwarbereitsan einenServer vermittelt,dort abererst in Zukunft ausgefuhrt werden,weilsienochin derWarteschlangestehenbzw. erstnochverschicktwerden,habenkeinenEinflußaufdieaktuelleLast.EineaufderLastbasierendeStrategiewurdein derZwi-schenzeitbeliebigviele weitereAuftragean einenServer mit niedrigerLast vermit-teln, daesaufgrundderMittelwertbildungeineWeile dauert,bis die neuenAuftragedie Durchschnittsbildungsignifikantbeeinflussen.Dies widersprichtder Forderung,moglichstaktuelleLastinformationenzuverwenden.Zum anderengibt die Last einesRechnerknotenskeine Auskunft uber dessenLei-stungsfahigkeit. So ist in einemSystemmit inhomogenerLeistungsfahigkeit ein aus-gelasteter, aberschnellerRechnerunterUmstandeneinemschwachausgelasteten,aberlangsamenRechnervorzuziehen.Unter diesenGesichtspunken wurde darauf verzichtet,Strategien zu implementie-ren, die auf der Metrik der Last basieren.StattdessenwurdenLastverteilungsstrate-gienimplementiert,die ihre EntscheidunganhandderAnzahlderbisherigenVermitt-lungen(Klasseloadstoreitemusage count), anhandderWarteschlangenlange(Klasseloadstoreitemqueuelength), sowie anhanddergeschatztenverbleibendenAntwortzeit(Klasseloadstoreitemestimatedtime to work) treffen.Die beidenletzterenMetrikenwerdenuberdie Monitorezur Verfugunggestellt.DieAnzahlderVermittlungenkanninnerhalbdesTradersohneVerwendungderMonito-re ermitteltwerden.Fur die Messungen,die im nachstenKapitel vorgestelltwerden,wurdedieAnzahlderVermittlungenjeweilsseitBeginneinerMessreihebetrachtet.Inder Praxisbietetessich an,hierfur ein Ruckwartsfensterzu verwenden,daßnur dieVermittlungeninnerhalbeinesbestimmtenZeitraumszahlt.Das im nachstenAbschnitt beschriebeneRegelwerk zur Zusammenfuhrung desTrader- undLoadBalancer-Ergebnissessiehtvor, daßdieLastjedesServersubereinePunktzahlbewertetwird. Die implementiertenLastverteilungsstrategienverwendenei-neGreedy-Heuristik[CLR94], die ihreBewertungsentscheidunglediglichanhanddermomentanenServerlasttrif ft. Diesewird durchdie jeweilsverwendetenMetrikencha-rakterisiert.Bei VerwendungderMetrik ESTIMATED TIME TO WORK ist zusatzlichzuberucksichtigen,daßdiesealtertunddementsprechendvon ihremWertdasjeweili-geAlter abgezogenwerdenmuß.Die in dendrei KlassenimplementierteGreedy-Strategie vergibt die bestePunktzahlandenServer mit demgeringstenLastwert.In allendreiKlassenergibt sichdaherdiePunktzahlunmittelbarausdemgespeichertenLastwert.

4.2.4.4 Regelwerkzur Ergebniszusammenfuhrung

Zum Endeder Dienstvermittlung muß dasErgebnisdesTraders,der sich nur mitdenDiensteigenschaftenbefaßt,und dasdesLoad Balancers,der nur die Last eines


Serversbetrachtet,zusammengefuhrt werden.Hierfur wird ein Regelwerk eingesetzt,dasabschließendaufgerufenwird, um einenKompromißzwischenmoglichstgutenDiensteigenschaftenundeinermoglichstniedrigenLastzu finden.Um einederartigeAbwagungvornehmenzu konnen,mußeineBewertungdieserbeidenunterschiedli-chenAspektevorliegen.DieserVorgangist in Abbildung4.27dargestellt.

Kompromiß

RegelwerkServer

BewerteteBewertete

angeboteDienst-

Trader Load Balancer

endgültigesDienstangebot

Abbildung4.27:Die ZusammenfuhrungderErgebnissevonTraderundLoadBalancer

Wahrendder Load BalancerdurchseineLastverteilungsstrategie einePunktzahlfurdie AuslastungdesDienstanbietersvergebenhat,ist fur denTraderunklar, wie er dieDiensteigenschafteneinesDienstangebotsbewertensoll. Da die IntegrationderLast-verteilungtransparenterfolgensoll, scheideteineErweiterungderTraderschnittstelleaus.Als Hinweisdarauf,auf welcherBasisdie Bewertungerfolgensoll, wird deshalbdasStrukturelementmatchingConstraints.minMaxRulederTrader-Importanfragever-wendet.Uberdiesesgibt ein Importeran,welchesDienstattribut minimiert oderma-ximiert werdensoll. Es bietetsich daheran,denabsolutennumerischenWert diesesDienstattributs als Bewertunganzusehen.Sollte ein Importer keinenOptimierungs-wunschbezuglich einesDienstattributs angegebenhaben,so kann dies zum Anlaßgenommenwerden,einereineLastverteilungdurchzufuhren.Zur ZusammenfuhrungdieserbeidenBewertungenwird eineAbbildung c benotigt,welche die vorliegendenBewertungender Last d Last und der Diensteigenschaftd Diensteigenschaft aufeineeinzelneBewertungderKompromißgute d Kompromiß abbildet:ceRfd Last g d Diensteigenschaft hi d Kompromiß 6Prinzipiell kommenhierfur beliebigeFunktion j k g j k i j k in Frage.Da die bei-denWerte d Last und d Diensteigenschaft alsvoneinanderlinearunabhangiganzusehensind,bietetessichan,siealsKomponenteneineszweidimensionalenVektorsaufzufassen.Unterder Voraussetzung,daßbei beidenBewertungenPunktzahlenin derNahevon


0 alseineguteBewertunganzusehensind,stellt derNullvektordasbestmoglicheEr-

gebnisdar. Die LangedesVektors l d Lastd Diensteigenschaft m gibt unterdiesenUmstandenden

AbstandzumOptimuman.Bei derBestimmungderLangeeinesVektorskonnenverschiedeneNormenverwendetwerden[EJ91]. Die n -NormeinesVektorso ist allgemeindefiniertalsp o p�q 4sr 5 2et q 2^uwvx 6Am gebrauchlichstensinddie Normenfur ny4{z (Manhattandistanz)und ny4}| (eu-klidischeDistanz),sowie fur ~Y�Y��n i � (Maximumsnorm).In Abbildung4.28sinddieVektoren� , d und � eingezeichnet.An ihnenlaßtsichdieunterschiedlicheCharakteristikderNormendarstellen.Die euklidischeNormundallegroßerenNormenreagierenviel starker auf einzelneAusreißerin denKomponenteneinesVektorsals die Manhattan-Norm.� hat deswegenbei Verwendungder eukli-dischenDistanzeinengroßerenAbstandvom Ursprungals � . Die ManhattandistanzberucksichtigtAusreißerin denKomponentennichtsostark,sodaßhierfur diePunkte� und � dengleichenAbstandhaben.Punkt � ist fur beideNormengleichweit vomUrsprungentfernt.Die euklidischeNorm enstprichtdem

”intuitivem“ Langenbegriff.

Bei VerwendungdieserNormhabendieVektoren� und d diegleicheLange.

Optimum Dienstgüte

Last

gleiche euklidische Distanz

gleiche Manhattandistanz

B A

C

Abbildung4.28:EuklidischeNormundManhattannorm

Normeneignensichdemnach,um im Regelwerk einenKompromißzu bewerten,in-demdessenNahezum Optimumbetrachtetwird. Falls bei derBewertungzusatzlicheinePraferenzbezuglich derLastoderdesDienstattributsberucksichtigtwerdensoll,konnendieeinzelnenKomponentenmit einerGewichtung� versehenwerden.Im Fal-le dereuklidischenNormergibt diesbeispielsweise:d Kompromiß 4W� (�� Diensteigenschaft C�d Diensteigenschaft , ` T�(�� Last C�d Last, ` 6


DieseNormenzur Abstandsbewertunglassensich sehreinfachimplementieren.Ab-weichendvon denDefaulteinstellungfur die zu verwendendeNorm unddie Gewich-tungenkonnenaußerdemeigeneParameterhierfur beimImport uberdiegewunschtenDienstangebotseigenschaften(vgl. Abschnitt4.1.2.5)angebenwerden.Um die Bewertungvon Last und Dienstattribut vergleichenzu konnen,mußvorhereineSkalierungihresWertebereichsvorgenommenwerden:�d Last� 4 d Last� %��?2�d Last/��f2�d Last/�%��?2�d Last/E� ��2 d Last/V�4��Y�2 d Last/D6DieseSkalierungbildet denursprunglichenWertebereichder Lastbewertungauf dasIntervall � G 6�6�zA� ab. Die SkalierungderDienstattributeerfolgtanalog,wobeizuberuck-sichtigenist, obderAttributwertminimiertodermaximiertwerdensoll.

ScoreTableItem* ScoreTable::calc_tablescores_and_return_minimal(int maximize_property_flag,float load_weight, float property_weight, float norm)

{...for(p=head; p!=NULL; p=p->get_next()){

my_load=p->get_load();my_property=p->get_property();// Skalieren der Werte bzgl. ihres Wertebereichs...my_load=(my_load-min_load)/(max_loa d-min _load );my_property=(my_property-min_proper ty)/( max_propert y-min _prop erty);// Eigentliche Berechnung der Score// Hierzu wird eine n-Norm mit Gewichten verwendetp->set_score(pow(pow((load_weight)* (my_l oad), norm)

+pow((property_weight)*(my_proper ty), norm),1/norm));

// Neue Score besser als bisher?if ((p->get_score()<minimal_score)){

minimal_score=p->get_score();minimal_item=p;

};};return minimal_item;

};

Abbildung4.29:Quelltext desRegelwerks

Der Quelltext des implementiertenRegelwerks, das die beschriebenenSchrittedurchfuhrt, ist in Abbildung 4.29 zu sehen.Als Ergebniswird dabeidasDienstan-gebotzuruckgeliefert,dessenBewertungsvektordenkleinstenAbstandvomOptimumbesitzt.In Abhangigkeit von dengewahltenGewichtungsfaktorenfuhrt diesdannzueinermehroderwenigerstarkausgepragtenLastbalancierung.

Kapitel 5

BewertungdesAnsatzes

In diesemKapitelerfolgteineBewertungdesimplementiertenAnsatzeszurDienstver-mittlung unterBerucksichtigungder Last von Dienstanbietern.Zunachstwerdendiefur die BewertungherangezogenenMeßgroßenundGrundlagenausderempirischenStatistikvorgestellt.DaranschließtsichdieBeschreibungderverwendetenTestumge-bungan.Die eigentlichenMeßergebnisseundderenInterpretationbildendenHaupt-teil diesesKapitels.Die dabeivorgenommeBewertungbetrachtetaußerder QualitatdervorgenommenenLastverteilungauchdenAufwand,derbeiderDienstvermittlungdurch die Lastverteilungskomponentezusatzlich entsteht.AbschließendwerdendieSchlusse,die bei der InterpretationderMeßergebnissegezogenwerdenkonnten,zu-sammengefaßt.

5.1 Meßgroßen

Zur LeistungsbewertungeinesSystemwerdenKriterien benotigt, anhandderereineBeurteilungvorgenommenwerdenkann.Hierbeimußzwischensubjektivenund ob-jektivenKriterienunterschiedenwerden.Aspekte,diedieDienstgutebetreffen,sindhaufigsubjektiv. EslassensichzwarMetri-kenverwenden,um die Dienstgutezu bewerten.Diesewerdenjedochin dergleichenFormbereitsim zubewertendenSystemeingesetzt,sodaßdiejeweiligenMetrikenaufsich selbstangewandtwurden.Es ist deshalbnicht moglich, eineobjektive Empfeh-lungauszusprechen,welcheMetrik im Regelwerkambesteneingesetztwerdensollte,umdortdieBewertungderDienstgutevorzunehmen.Ebensoist dieWahlderGewich-tungsfaktorenfur die Lastbzw. die DienstguteletztendlichGeschmackssache,sodaßdiesbezuglichebenfalls keineoptimaleGewichtungbestimmtwerdenkann.Zur BeurteilungdermoglichenLastmetrikenundLastverteilungsstrategienlassensichjedochvielfaltige objektive Kriterien verwenden.Ebensoist es moglich, den Over-head,derdurchdie Lastverteilungim Trading-Prozeßentsteht,zu messen.Als wich-tigsteMeßgroßekommthierbeijeweils die mittlereAntwortzeitzumEinsatz.Die imeinzelnenverwendetenMeßgroßenwerdenim folgendenvorgestellt.

78 5. BewertungdesAnsatzes

5.1.1 Lastverteilungsgute

DasZiel derLastverteilungbestehtdarin,systemweitdie Antwortzeitzu minimieren.Als Kriterium zurBeurteilungderQualitateinerLastverteilungsstrategiebietetessichdaheran,die uberalle DienstanbietergemittelteAntwortzeitzu messen.JenaherdiedurcheineLastverteilungsstrategie erzieltemittlere Antwortzeit an dastheoretischeMinimum ruckt,destobesserist dieseStrategie.Als theoretischesMinimum kanndiemittlereWartezeiteinesM/M/ � -Warteschlangensystemsangesehenwerden,dain die-semWarteschlangenmodellvoneineroptimalenLastverteilungausgegangenwird. FurkonstanteBedienzeitenbeschreibteinM/D/ � -Modell mit seinerdeterministischenBe-dienratedasSystemnochexakter. Da dasM/M/ � -Modell denallgemeinerenFall be-schreibt,wird im weiterenauf dieseModellierungzuruckgegriffen.Als weiteresKriterium zurBewertungeinerLastverteilungsstrategiewird dieLast,diebei jedemeinzelnenDienstanbieterentsteht,betrachtet.Eine guteLastbalancierungsorgt dafur, daßdie Last bei allen Anbieterngleich groß ist. Fur ein inhomogenesSystemmit unterschiedlichleistungsfahigenRechnernkannesbeieinersehrniedrigenSystemauslastungallerdingsauchsinnvoll sein,schnelleRechnerstarkerzubelasten.Die durchschnittlicheAnzahlderAuftrageim System,d.h.in derWartschlangeundimServer, bietetein Bewertungskriterium,dasahnlichwie die Last interpretiertwerdenkann.GegenuberderLastfließthierzusatzlichnochdieWarteschlangenlangeein.Als letzte Meßgroßezur Bewertungeiner Lastverteilungsstrategie wird die AnzahlderDienstnutzungenverwendet.Bei homogenenSystemsolltenalle Server gleichoftaufgerufenwordensein,im inhomogenenFall solltesichhier dasVerhaltnisderLei-stungsfahigkeit dereinzelnenRechnerknotenwiderspiegeln.

5.1.2 Lastverteilungsaufwand

NebenderGutederLastverteilungsstrategiensoll auchderEinflußderLastverteilungauf die Dienstvermittlunguntersuchtwerden.Hierbei interessiertbesonders,um wie-viel dieDienstvermittlungszeitdurchdieBetrachtungderLaststeigt.Als Bewertungs-kriteriumwird hierfur diemittlereAntwortzeitdesTradersverwendet.Da die Lastverteilungskomponentenicht nur Einflußauf die Dienstvermittlungsdauerhat,wird außerdemnochdieNetzlastbetrachtet,diedurchdie UbermittlungderLast-informationenvondenMonitorenzumLoadBalancerentsteht.Diesgeschieht,indemdieAnzahlderhierdurchentstehendenKommunikationsvorgangegezahltwird.

5.1.3 Fehler der Meßgroßen

Die gemessenenWertestellennur Stichprobendar. Aus diesemGrundekonnenle-diglich Schatzungenfur die wahrenWerteder jeweiligenMeßgroßenvorgenommenwerden.Die empirischeStatistikbietetMethoden,um SchatzwerteundderenFehlerzu bestimmen[Sto93]. Die fur die nachfolgendenBewertungeneingesetztenMetho-densollenandieserStellekurzvorgestelltwerden.

5.2.Testumgebung 79

Aus b gemessenenWerten t 2 kannuberdasarithmetischeMittel eineSchatzung�e�fur denwahrenWert � vorgenommenwerden:

��4 t 4 zb �52��]\�t 2�6Ein solcherSchatzwertenthalt keineAussagedaruber, wie gutdieseSchatzungist. EsmußzusatzlichdieStreuungderMeßwertet 2 betrachtetwerden,umdieQualitateinesSchatzwertesbeurteilenzukonnen.Ein einfachesMaßfur dieStreuungderMeßwerteist die empirischeVarianz `� , die sichausderquadratischenAbweichungdereinzel-nenMeßwertevomSchatzwertberechnet:

`� 4 zb¡%Mz �52��]\ ( t 2 % t , ` 6Als weiteresMaß fur die Gute einerSchatzungkonnenKonfidenzintervalle verwen-detwerden.Der wahreWert � befindetsichmit Wahrscheinlichkeit ¢ außerhalbdeszugehorigen(1 %9¢ )-Konfidenzintervalls, dasdenSchatzwertumschließt.Das(1 %;¢ )-Konfidenzintervall ist wie folgt definiert:

��£% a�¤ b C@*¦¥]§ \©¨7ª «¬§ �¬¨�\P�� B�e��T a�¤ b CA*¦¥]§ \©¨7ª «¬§ �¬¨�\L6Bei *¦¥�§ ®<§ � handeltessichumdasPerzentilder * - bzw. Student-Verteilung.EinPerzentilgibt denWertan,deneinAnteil ¢ allerWerteunterschreitetbzw. einAnteil von(1 %9¢ )uberschreitet.Fur ¢¯4 G 6±° ergibt sichbeispielsweisederMedian.Bei dennachfolgendenDiagrammendiesesKapitelsist zur BeurteilungderGutederMessungenjeweilsdas90%-Konfidenzintervall in FormvonFehlerbalkenangegeben.

5.2 Testumgebung

Im folgendenwird eineBeschreibungderTestumgebung,in derdie Messungenstatt-fanden,gegeben.

5.2.1 Lasterzeugung

Die Umgebung,in derdieMessungendurchgefuhrtwerden,soll einerseitsdenEinsatzdeszu bewertendenSystemsin derPraxiswiderspiegeln,andererseitssoll die Umge-bungeingenaudefiniertesUmfelddarstellen,umdieMessungennachvollziehbarundwiederholbarzugestalten.Eswurdedaherversucht,ein Szenariozu schaffen,daßdeterministischeAnfragenandenTraderenthalt undvonderresultierendenServernutzunghereinemrealenEinsatzmoglichstnahekommt.Da keinekonkretenUntersuchungenausder Praxisbekanntsind,diedieAnfragecharakteristikin einemClient-Server-Systembeschreiben,wurde


einesynthetischeAnfragesequenzerstellt,die geeigneterscheint,ein realesAnfrage-verhaltenzusimulieren.Bei derErzeugungeinersolchenAnfragesequenzmussenverschiedeneDingebeach-tet werden.Zunachsteinmalsoll jedeSequenzeinebestimmteLasterzeugen,sodaßMessungenfur verschiedeneLastendurchgefuhrt werdenkonnen.Insbesonderemußdaraufgeachtetwerden,daßdasGesamtsystemnicht uberlastetwird. HierzumußeinstabilerZustandvorliegen,d.h.esdurfennichtmehrAnfragengestelltwerden,alsdasSystemuberhauptin dergegebenenZeitbearbeitenkann[Bol89]. Dennochsollenzeit-lich beschrankteUberlastsituationenauftreten,um dasVerhaltenderLastverteilungs-strategienin temporarenUberlastsituationenbeurteilenzu konnen.Dieskannerreichtwerden,indemnebenkurzzeitigenAnfrage-BurstsauchentsprechendeRuhephaseninderAnfragesequenzenthaltensind.Zur GenerierungeinerAnfragesequenzmit einerderartigenCharakteristikwurdeeinPseudozufallszahlengeneratorverwendet,der in einembestimmtenZeitraumeinebe-stimmteAnzahl von Anfragenplaziert.Bei b Servern laßtsich fur � AnfragendieGesamtdauer& einerSequenz,diedieLast ² erzeugt,ausdeneinzelnenBedienzeiten*�³´/ berechnen:

&B4 � ² zµ �2��]\ \¶¸· / 6Falls verschiedeneKlassenvon Anfragenmit jeweils unterschiedlicherBediendauerzumEinsatzkommen,ergibt sichdie Gesamtdauer&�¹ ausderSummederSequenz-dauernfur dieeinzelnenAnfrageklassen:

&�¹�4 5ºKlassen»E� &�=�6

Fur die nachfolgendenMessungenwurdeeineSequenzmit 100Anfragenverwendet.Die generierteSequenz,die bei allenMessungenzumEinsatzkam,ist in Abbildung5.1 dargestellt.Fur die unterschiedlichenzu generierendenLastenundunterschiedli-chenLeistungsstarken der eingesetztenRechnerwurdedieseSequenzentsprechendskaliert.Bei denMessungenkamenSequenzdauernzwischen32 und1046SekundenzumEinsatz.Die Bedienzeitenlagenzwischen1.1und16.0Sekunden.Die eigentlicheLast wird von Servern erzeugt,die auf AnfrageRechenzeitverbrau-chenundsomitCPU-Lastverursachen.

Abbildung5.1:Die fur dieMessungenverwendeteAnfragesequenz

5.2.Testumgebung 81

5.2.2 Meßwertaufnahme

Zur AufnahmederMeßwertewurdeein zentralerClient verwendet,derentsprechendder generiertenAnfragesequenzImport-Anfragenan denTraderstellt und direkt imAnschlußden vom Trader vermitteltenServer nutzt. Da wahrendder temporarenUberlastsituationender Client auf mehrereausstehendeAnfragenwartenmuß,wer-denThreadsverwendet,um wahrenddessenweiterhinneueAnfragenabschicken zukonnen.Die zu bewertendenMeßgroßenfallenanverschiedenenStellendesSystemsan.DiemittlereAntwortzeitallerServerkannim Clientgemessenwerden.Dort wird ebenfallsdieDienstvermittlungsdauer, d.h.dieAntwortzeitdesTradersgemessen.Derzusatzli-cheKommunikationsaufwandderLastverteilungwird im Tradererfaßt,dabeidiesemalle relevantenLastnachrichteneintreffen. ServerspezifischeDaten,wie dessenLast,dessenmittlereWarteschlangenlangesowie dessenAnzahlderNutzungenwerdenvondenjeweiligen Monitorengemessen.Hierfur konnenzum Teil die bereitsgenutztenFilterpunkteverwendetwerden,zum Teil mussenaberauchseparateMeßpunktein-stalliertwerden.Zur Zeitmessungwird, wie bereitsin Kapitel4 beschrieben,dieUnix-Betriebssystemfunktiongettimeofdayverwendet.Die Messungenwurdenin einemlokalen Netzwerk(10/100Mb/s-Ethernet)durch-gefuhrt. Die verwendeteRechnerhardware ist in Tabelle 5.1 aufgefuhrt. Die Mes-sungenfandenjeweils mit vier Servern, die den gleichenDienstexportierten,statt.Fur die MessungeneinesSystemsmit homogenerRechenleistungwurdendie Serverauf denRechnernAoxomoxoa,Hauptquartier, Intensivstationund Voltaire gestartet.DasinhomogeneSystemwurdedurchdie RechnerOstgote, Titanic, Voltaire unddendurcheinenHintergrundprozeßauf 50%-RechenleistunggedrosseltenRechnerAoxo-moxoarealisiert.Die einzelnenRechnerwarenansonstenwahrendder Messungenweitgehendungenutzt.Der Traderlief auf demRechnerStarfighter. Bei der Bewer-tungderDienstvermittlungsdauerwurdezurAktualisierungderLastinformationenei-neCaching-Strategieverwendet.

Rechnername Aoxomoxoa,Haupt-quartier, Intensivsta-tion, Voltaire

Starfighter,Titanic Ostgote

Hersteller Sun Sun SunModell Ultra 1 Creator(3D) Ultra 1 140 SPARCStation5

AnzahlCPUs 1 1 1Taktrate 167Mhz 143Mhz 110Mhz

Hauptspeicher 128MB 64MB 32MBVirtuellerSpeicher 450MB 176MB 101MB

Tabelle5.1:KenndatenderverwendetenRechnerknoten


5.3 Meßergebnisse

5.3.1 Lastverteilungsgute

In diesemAbschnittwird allein die Gute der verwendetenLastverteilungsstrategienbetrachtet.Die Import-Anfragebeschrankte sich auf die AngabedesgewunschtenDiensttyps.EineEinschrankungbezuglichderDienstattributefandnichtstatt.DerEin-flußvonAttributenbzw. dieLeistungsfahigkeitdesRegelwerks,daseinenKompromißzwischenDienstguteundLasttrif ft, wird in Abschnitt5.3.2untersucht.

5.3.1.1 ReineLastbalancierungbei homogenerServerleistung

DieverschiedenenLastverteilungsstrategiensindfur unterschiedlichenSituationenun-terschiedlichgutgeeignet.Zunachstwird aufdenhomogenenFall eingangen,beidemallevier verwendetenRechnerdiegleicheRechenleistungbesitzen.Die Anfragenha-benallediegleicheBedienzeit*�³ =1.1s.Abbildung5.2stellt fur diesenFall diemittlereAntwortzeitdar. Nebendenimplemen-tiertenStrategienRandom,Usage Count,QueuelengthundEstimatedTime To Work,dieaufdenim vorhergehendenKapitelbeschriebenenMetrikenberuhen,sindalstheo-retischeGrenzendie Antwortzeitender M/M/1 und M/M/4-Warteschlangenmodelleeingezeichnet.

0

1

2

3

4

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

¼

Last

RandomUsage_CountQueuelength

Estimated_Time_To_WorkM/M/1M/M/4

Abbildung5.2:Antwortzeitenfur reineLastbalancierung(homogenesSystem)

5.3.Meßergebnisse 83

Die Antwortzeiten der drei Strategien Usage Count, Queuelengthund Estima-ted Time To Work liegen relativ dicht beieinanderund kommendem theoretischenOptimumnochnahe.Die zufallige VerteilungderAnfragenauf die Server schneidethingegenschlechtab. Dies ist daraufzuruckzufuhren,daßderverwendetePseudozu-fallsgeneratorkeinesehrguteGleichverteilungbesitzt.Fur einenZahlengenerator, derauchubereinenkurzenZeitraumeineGleichverteilungrealisert,wareein ahnlichgu-tesVerhaltenwie bei Usage Countzu erwarten.Die CharakteristikeinesderartigenZahlengeneratorswaredannallerdingsauchnichtmehralszufallig zubezeichnen.Als besteStrategie stellt sich Usage Countheraus,bei der der bisheram wenigstengenutzteServervermitteltwird. Dajeweilsdiegleichenvier Serververmitteltwerden,entsprichtdiesdervon einigenTradernangebotenenStrategie Cyclic Choice, bei dermehrerein FragekommendeDienstanbieterreihumvermitteltwerden.Fur den Fall, daßdie Rechenleistunghomogenist, reicht daherdasalleinige Wis-sendesTradersaus,um eineguteLastverteilungzu realieren.Diesgilt allerdingsnurfur denFall, daßdie Server nicht ohnedie VermittlungdesTradersgenutztwerdenundkeineHintergrundlastdurchweitereServer verursachtwird. Derweiteruntenbe-schriebeneninhomogeneFall legt denSchlußnahe,daßdieseStrategieversagt,sobaldServerohnedasWissendesTradersgenutztwerden.In diesemFall bietetessichan,aufQueuelengthoderEstimatedTime To Work auszu-weichen.Bei Lastenoberhalbvon ½ =0.4schneidetdieVerteilunganhanddergeschatz-tenverbleibendenBearbeitungszeitetwasbesserabalsdie alleinigeBetrachtungderWarteschlangenlange.Die Gute der Messungenist recht hoch, so daß die Fehlerbalken der 90%-Konfidenzintervalle großtenteilsin denMarkierungenderMeßwerteuntergehen.Le-diglich in denFallen, in denenandenverwendetenRechnerngleichzeitiggearbeitetunddadurchunregelmaßigeHintergrundlasterzeugtwurde,fallt dieQualitatderMes-sungenetwasschlechteraus.Bei Betrachtungder einzelnenServer laßtsich die Charaktistikder einzelnenLast-verteilungsstrategienbeurteilen.Abbildung5.3gibt dieLastandeneinzelnenServernAoxomoxoa,Hauptquartier, IntensivstationundVoltairewieder. Eswurdenhierfur ex-emplarischdieGesamtsystemlasten½ =0.3,0.5,0.7,0.9herausgegriffen.Esist zusehen,daßdieVerteilung,diedurchdiedynamischenStrategienQueuelengthund EstimatedTime To Work erzielt wird, mit steigenderLast gleichmaßigerwird.Bei kleiner Systemauslastungergibt sich eine Rangfolgebezuglich der AuslastungderServer. Dies ist dadurchzu erklaren,daßbei kleinenLastennur wenigeAuftragegleichzeitigzubearbeitensind.Fallssichz.B.alleServerim Leerlaufbefinden,weisendie beidendynamischenStrategien einenneuenAuftrag immer demjenigenServerzu, der als erstervom Tradergefundenwurde.Die statischeRandom-Strategie bzw.die Usage Count-Strategie ausdemGrenzfeldzwischenstatischenunddynamischenStrategienbesitzenhingegenkeinePraferenzen.Bei dendynamischenStrategienlaßtsich bei niedrigenLastenausder Anzahl der Anfragenpro Server die Reihenfolgeablesen,in derdieServer im Tradergespeichertsind.Abbildung5.4verdeutlichtdies.Obwohl bei denStrategien Queuelengthund EstimatedTime To Work bei niedriger


0

0.5

1

A H I V A H I V A H I V A H I V

Last

der

ein

zeln

en S

erve

r¾

Gesamtlast 0.3

A=AoxomoxoaH=HauptquartierI=IntensivstationV=Voltaire


Estimated_Time_To_Work

0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.5



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.7



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.9



Abbildung5.3:LastandeneinzelnenServern(homogenesSystem)

0

10

20

30

40


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.3



0

10

20

30

40


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.5



0

10

20

30

40


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.7



0

10

20

30

40


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.9



Abbildung5.4:AnfragenproServer (homogenesSystem)

Last die Verteilungder Anfragenungleichmaßigist, bedeutetdies jedochnicht, daßdies auchzu schlechtenAntwortzeitenfuhrt. Die Ungleichverteilungtritt nur dann


auf, wenndie Server ungenutztsind.Bei steigenderLast steigtauchdie Anzahl dergenutztenServer, sodaßsichbeihohenLastendementsprechendeineGleichverteilungergibt. Falls auchbei niedrigenLasteneinegleichmaßigeLastverteilunggewunschtist, bietet es sich an, die beidendynamischenStrategien mit den beidenstatischenStrategienzukoppeln.

00.5

11.5

22.5

33.5

44.5

5


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.3



00.5

11.5

22.5

33.5

44.5

5


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.5



00.5

11.5

22.5

33.5

44.5

5


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.7



00.5

11.5

22.5

33.5

44.5

5


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.9



Abbildung5.5:Auftrageim SystemproServer (homogenesSystem)

In Abbildung5.5 ist abschließenddie AnzahldergleichzeitigenAuftragepro Server-systemdargestellt.Bei kleinenLastenwartetselteneinAuftrag in derWarteschlange.Hierfur ergibt sich daherungefahr die Last der einzelnenServer, wie sie bereitsinAbbildung 5.3 zu sehenwar. Bei großenLastenmachensich hingegendie warten-denAuftragebemerkbar. Dementsprechendsteigtdort die Anzahl der gleichzeitigenAuftragein denjeweiligenServersystemen.Bemerkenswertist, daßdieStrategieEsti-matedTime To Work bei hohenLasteneinegleichmaßigereVerteilungder Auftrageim Serversystemsowohl bezuglichdesinsgesamtbesserabschneidendeUsage Count-Verfahrenalsauchdes– genaudieseAnzahlbetrachtenden– Queuelength-Verfahrenerzielt.

5.3.1.2 ReineLastbalancierungbei inhomogenerServerleistung

Im inhomogenenFall zeigendie betrachtetenLastverteilungsstrategien ein anderesVerhalten.Die BedienzeitderverwendetenAnfragebetragt fur dasim folgendenun-tersuchteSzenarioje nachRechner1.1s(Voltaire), 1.3s(Titanic), 1.7s(Ostgote) bzw.2.2s(Aoxomoxoagedrosselt).


DiehierausresultierendenmittlerenAntwortzeitensindin Abbildung5.6in Abhangig-keit vonderLastaufgetragen.Als theoretischeObergrenzeist diemittlereAntwortzeitfur eineM/M/1-Warteschlangemit der BedienzeitdeslangsamstenRechnerseinge-zeichnet.Dies entsprichteinerLastverteilungsstrategie, die immer den langsamstenRechnerauswahlt.Als UntergrenzewurdeeineM/M/4-Warteschlangeverwendet,diesich fur denFall ergibt, daßviermalder schnellsteRechnerzur Verfugungsteht.DatatsachlichauchlangsamereRechnergenutztwerden,entsprichtdiesnicht der wirk-lichen theoretischenUntergrenze,die speziellbei hohenLastenetwas hoher liegendurfte. Da eineexakteanalytischeBetrachtungaberan dieserStellezu komplex ist,wurdedieseVereinfachunggetroffen.

0

1

2

3

4

5

6

7

8

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last


Estimated_Time_To_WorkM/M/1 kleinste Bedienrate

M/M/4 größte Bedienrate

Abbildung5.6:Antwortzeitenfur reineLastbalancierung(inhomogenesSystem)

Auch im inhomogenenFall erweistsichdiezufalligeVerteilungalsschlechtesteStra-tegie. Im Gegensatzzum homogenenFall schneidetdie Verteilungnachder AnzahlderDienstnutzungen(Usage Count) nunebenfallsdeutlichschlechterabalsdiebeidendynamischenStrategien.DiesesVerhaltenentsprichtauchderErwartung,daleistungs-schwacheRechnerweiterhingenausoviele Anfragenzugewiesenbekommenwie lei-stungsstarkere.Die beidendynamischenLastverteilungsstrategienkonnensehrviel besserauf die in-homogeneServerleistungeingehen.Die durchsie resultierendemittlere Antwortzeitverlauft immernochvergleichsweisenaheandereingezeichneten,vereinfachtenUn-tergrenze.Obwohl die Strategie, die auf derMetrik EstimatedTime To Work beruht,die unterschiedlichenBediendauernder einzelnenServer erfaßt, erweistsich dieseStrategienurminimaldereinfacherenQueuelength-Strategie uberlegen.


Zur VisualisierungderCharakteristikdereinzelnenStrategiensind in denAbbildun-gen5.7 bis 5.9 die MeßgroßennachServern (Aoxomoxoa,Ostgote, Titanic, Voltaire)aufgeschlusselt.Als Lastwertewurdediesmalexemplarisch½ =0.3, 0.7, 0.8 und 0.9herausgegriffen.Im GegensatzzumhomogenenFall fallt beidenMessungenmit inho-mogenenRechnerndieQualitatdieserMeßwerteschlechteraus.DadieKonfidenzal-lerdingsnurbeidendynamischenVerfahrenschlechterwurde,kannvermutetwerden,daßessichdabeinicht um Fehlerin derMessunghandelt.Vielmehrdurfte derLoadBalancerselberjeweils bei Entscheidungen,die

”auf derKippe“ standen,in verschie-

denenMeßdurchlaufenjeweilszuunterschiedlichenErgebnissengekommensein,weildie entsprechendenMonitordatenminimal andersausgefallensind.DiesesPhanomenzeigtsichauchbeidenSzenariendernochfolgendenAbschnitte.

0

0.5

1

A O T V A O T V A O T V A O T V

Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.3

A=AoxomoxoaO=OstgoteT=TitanicV=Voltaire



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.7



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.8



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.9



Abbildung5.7:LastandeneinzelnenServern(inhomogenesSystem)

Die Betrachtungder Last an deneinzelnenServern bestatigt, wie schlechtstatischeVerfahrenim inhomogenenFall die Last verteilen.Die Usage Count-Strategie ver-gibt gleichmaßigAuftrageandieunterschiedlichleistungsfahigenServer. DieshatzurFolge,daßbei schwachenRechnernschnelleinehoheLast erreichtist, wahrenddieschnellerenRechnernochfreieKapazitatenbesitzen.Die dynamischenVerfahrenhingegenbevorzugenschnellereServer(Voltaire, Titanic),sodaßdiesenmehrAuftragezugewiesenwerdenundderenAuslastunghoheralsdieder langsamerenRechnerist. Generellist festzustellen,daßeinederartigeBevorzu-gungnurbeiniedrigenLastenmoglichist,dabeihoherLastdiegesamtezurVerfugungstehendeRechenleistungbenotigt wird, sodaßauchanschwachereRechnerAuftrageverteiltwerden.


0

10

20

30

40

50


Anf

rage

n pr

o S

erve

r¿

Gesamtlast 0.3



0

10

20

30

40

50


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.8



0

10

20

30

40

50


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.8



0

10

20

30

40

50


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.9



Abbildung5.8:AnfragenproServer (inhomogenesSystem)

0

1

2

3

4

5

6

7

8


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.3



0

1

2

3

4

5

6

7

8


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.7



0

1

2

3

4

5

6

7

8


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.8



0

1

2

3

4

5

6

7

8


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.9



Abbildung5.9:Auftrageim SystemproServer (inhomogenesSystem)

Bezuglich derAuftrage,die sichgleichzeitigim Server-Warteschlangensystembefin-den,spiegelt sich bei niedrigerAuslastung– wie zu erwarten– die Last wieder. Bei


steigenderLastergibt sichbei denstatischenVerfahreneineextremeUngleichvertei-lung,dasichandenlangsamenServernAuftragestauen.Die dynamischenVerfahrensorgenhingegenfur eineannaherndeGleichverteilung,dadenServern,die ihre War-teschlangeschnellerleeren,immerentsprechendneueAuftragezugeteiltwerden.Abschließendlaßtsich feststellen,daßdynamischeLastverteilungsstrategien bei in-homogenenSystemenden statischenStrategien uberlegen sind. Wissen uber dieAusfuhrungszeitender einzelnenAuftragebringt gegenubereiner rein auf der War-teschlangenlangebasierendendynamischenStrategie keineherausragendenVorteile.Um dieQualitatderstatischenVerfahrenzuerhohen,wareesdenkbar, derenZuteilungentsprechendder Leistungder einzelnenServer zu gewichten.Damit dies moglichist, muß allerdingsdie Leistungsfahigkeit aller Server bekanntsein.DieseVoraus-setzungist in einemoffenenDienstmarktnicht gegeben.Durch die dort moglichetransparenteServermigrationkannsichdie LeistungeinesDienstanbietersunbemerktverandern.Daruberhinauskannein statischesVerfahrenprinzipiell keinewechselndeHintergrundlasterfassen.

5.3.1.3 Reine Lastbalancierung bei homogenerServerleistung mit verschiede-nenAnfrageklassen

Wahrendbei den vorhergehendenSzenarienimmer die gleiche Anfrage an dieDienstanbietergestelltwurde,werdennun vier verschiedeneKlassenvon Anfrageneingesetzt.DiesebesitzenunterschiedlicheBedienzeiten.DiesesSzenariokannso interpretiertwerden,daßauf denServerrechnerknoteneinewechselndeHintergrundlastfur eineunregelmaßigeVerlangerungderDienstbearbei-tungszeitsorgt.Zunachstsoll der Fall mit homogenerRechnerleistunguntersuchtwerden.Die Be-diendauerder einzelnenAnfrageklassenlag hiefur bei 8.0s,3.0s,1.1sund 0.4s.DieverschicktenAnfragenwurdenzufallig ausdenvier Klassengewahlt,wobeiausjederKlassediegleicheAnzahlvonAnfragengezogenwurde.Die uberalleAnfrageklassengemittelteAntwortzeitist in Abbildung5.10dargestellt.Der Versuch,diesesSzenarioanalytischuber Warteschlangenmodellezu erfassen,wurdehiernichtunternommen.Bei derBerechnungdermittlerenAntwortzeitenwur-deuberdieAntwortzeitenallerAnfragenklassengemittelt.Weil diezuuntersuchendenStrategiennichtdasZiel haben,eineShortest-Job-Firsto.a.Strategiezu implementie-ren,wurdedasBedienverhaltenfur einzelneKlassennichtuntersucht.Trotz der unterschiedlichenBedienzeitender Klassenreicht es,die gemittelteAnt-wortzeit zu betrachten.Zwar ergibt sich die Antwortzeit ausder Wartezeitund derBedienzeit,die von Klassezu Klassevariiert, dennochmußdiesnicht berucksichtigtwerden.Die AnzahlderAnfragenproKlasseist fur jedeMeßreihegleich,sodaßin diegemittelteAntwortzeitaufgrundderLinearitatdesarithmetischenMittelwertoperatorslediglicheinekonstanteSumme,diesichausdermittlerenBedienzeitergibt, eingeht.Im Vergleich mit dem entsprechendenklassenlosenhomogenenFall fallt zunachstauf, daß der Abstandder drei Strategien Usage Count, Queuelengthund Estima-


0123456789

1011121314

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last



Abbildung 5.10: Antwortzeitenfur reine Lastbalancierung(homogenesSystemmitAnfrageklassen)

ted Time To Work voneinandergroßergewordenist. Bei nahererBetrachtungzeigtsichsogar, daßsichderenVerhaltenumgekehrthat.Abgesehenvon der Random-Strategie, die erneutam schlechtestenabschneidet,istin diesemFall die gleichmaßigeVerteilungper Usage Count bei hohenLastendieschlechtesteLastverteilungsstrategie.Dies ist dadurchzu erklaren,daßdie eingehen-denAnfragenzwar gleichmaßigauf die einzelnenServer verteilt werden,die Klasse– und damitdie Große– dereingehendenAnfrageist jedochzufallig. Die einzelnenServersinddahermit unterschiedlichlangenAnfragenbeschaftigt.Bei einerSystemlast,die kleiner als ½ =0.6 ist, erweistsich allerdingsdie StrategieEstimatedTime To Work als schlechter. Dies ist dadurchzu erklaren, daß sie zurSchatzungder verbleibendenBearbeitungszeiteinengleitendenMittelwert ausdenvergangenenAnfragebediendauernbildet. Da die Bediendauernaufgrundder unter-schiedlichenKlassenvariieren,wird einefalscheSchatzungvorgenommen.Bei stei-genderLast wird der Schatzfehlervon der Tatsache,daßdieseStrategie gegenuberUsage Countdynamischist, aufgewogen.Als besteStrategie stellt sich Queuelengthheraus.Bei ihrer Betrachtungder Warte-schlangenlangebesitztdieseStrategie kein Wissenuberdie Großederdarinenthalte-nenAuftrage,stattdessenwerdenalle Auftrageals gleichwertigangesehen.Die Ver-wendungvon keinemWissenbezuglich derAuftragsgroßeerweistsichalsbesseralsdie Verwendungvon falschemWissen,wie esbei EstimatedTime To Work der Fallist.


0

0.5

1


Last

der

ein

zeln

en S

erve

r¾

Gesamtlast 0.3

A=AoxomoxoaO=OstgoteT=TitanicV=Voltaire



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.5



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.7



0

0.5

1

A H I V A H I V A H I V A H I VLa

st d

er e

inze

lnen

Ser

ver

¾Gesamtlast 0.9



Abbildung5.11:LastandeneinzelnenServern(homogenesSystemmit Anfrageklas-sen)

Die Meßwertefur die einzelnenServer sindin denAbbildungen5.11bis 5.13darge-stellt. Bezuglich der dynamischenStrategien ist – wie schonbeim klassenlosenho-mogenenFall – festzustellen,daßbei kleinenLastendie Server ihrer ReihenfolgeinderTraderdiensttabelleentsprechendgenutztwerden.Mit steigenderGesamtlastver-schwindetauchin diesemFall diesePraferenzzugunsteneinergleichmaßigenVertei-lung.Bei hohenLastenerzieltdie Strategie Queuelengthdie gleichmaßigsteVerteilungderLastauf alle Server. DiesesErgebnisbestatigt dasguteAbschneiden,dasdieseStra-tegie bezuglich dermittlerenAntwortzeitaufweist.Alle anderenVerfahrenscheiternbeimVersuch,im HochlastbereicheineGleichverteilungderLastzuerreichen.Die BewertungderStrategienanhandderUberprufung,ob die Anfragengleichmaßiguberdie Server verteilt wurden,ist im vorliegendenSzenarionicht zulassig.WegenderunterschiedlichenAnfrageklassenkanndiegleicheAnzahlvonAuftragenzueinerunterschiedlichenLastfuhren.Dieszeigtdie BetrachtungderStrategie Usage Count.Obwohl dieAnzahlderAnfragenfur jedenServer gleichist, ergibt sichbezuglichderauftretendenWarteschlangenlangeneinesehrungleichmaßigeVerteilung.Fur die Last ½ =0.9 fallt in Abbildung 5.13 auf, daß die Strategie Estima-ted Time To Work scheinbareinesehrguteVerteilungder Auftrageuberdie Serverbzw. derenWarteschlangenrealisiert.Gleichzeitigfallt aberauchauf, daßdort dieKonfidenzintervalle sehrgroß sind, weshalbeine derartigeAussagenicht getroffenwerdenkann.Ein Vergleich mit Abbildung 5.10 weist auf ein eherschlechtesVer-


0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r¿

Gesamtlast 0.3Random

Usage_CountQueuelength


0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.5



0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.7



0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.9



Abbildung5.12:AnfragenproServer (homogenesSystemmit Anfrageklassen)

0

1

2

3

4

5

6


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.3



0

1

2

3

4

5

6


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.5



0

1

2

3

4

5

6


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.7



0

1

2

3

4

5

6


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.9



Abbildung5.13:Auftrageim SystemproServer(homogenesSystemmit Anfrageklas-sen)


haltenhin und legt nahe,daßdie Schatzungder verbleibendenAntwortzeit wegenderunterschiedlichenBedienzeiteninstabilist undfur eineentsprechendeVarianzderMeßwertesorgt.Eslaßtsichfesthalten,daßdie Strategie Queuelengthambestenmit denunterschied-lich großenAnfragendiesesSzenariosumgehenkann.Die Strategie Usage Countistfur hoheLastenschlechtgeeignet.EstimatedTime To Work schneidetzwar bei nied-rigen Lastenschlechterab, dafur verhalt sie sich bei hohenLastenbesser. Ihre Lei-stungsfahigkeit ist dortaberdeutlichschlechteralsdiederQueuelength-Strategie.DieprobabilistischeVerteilungstellt sichwie bei allenanderenSzenarienalsungeeignetheraus.

5.3.1.4 ReineLastbalancierungbei inhomogenerServerleistungmit verschiede-nenAnfrageklassen

Als letztesSzenariosoll eineKombinationderbeidenvorhergehendenSzenarienun-tersuchtwerden.NebenmehrerenKlassenmit unterschiedlichenBedienzeitenwurdedasinhomogeneSystem,dasbereitsim vorletztenAbschnittbeschriebenwurde,einge-setzt.EswurdendieselbenAnfrageklassenwie in Abschnitt5.3.1.3verwendet.DurchdieinhomogeneRechenleistungvariierendieresultierendenBedienzeiteneinerKlassevonDienstanbieterzuDienstanbieter.Die fur diesenFall gemessenenAntwortzeitensindin Abbildung5.14zusehen.

0

2

4

6

8

10

12

14

16

18

20

22

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last



Abbildung5.14:Antwortzeitenfur reineLastbalancierung(inhomogenesSystemmitAnfrageklassen)


DiesesdoppeltinhomogeneSzenarioscheidetendgultig diedynamischenvondensta-tischenLastverteilungsverfahren.Die in denvorhergehendenFallenimmernochganzgutabschneidendeUsage Count-StrategiedegeneriertnunvonderLeistungsfahigkeitherannaherndzurRandom-Strategie.Die beidendynamischenStrategiensindauchindiesemFall in derLage,sichderinhomogenenUmgebunganzupassen.Bezuglich der VerfahrenQueuelengthund EstimatedTime To Work ergibt sich imwesentlichendasgleicheBild wie bereitsbeim homogenenFall mit verschiedenenAnfrageklassen.Die rein auf der WarteschlangenlangebasierendeStrategie laßtsichnicht von denunterschiedlichenBediendauernder verschiedenenKlassenbeeinflus-sen.QueuelengtherreichtdahergeringereAntwortzeitenalsEstimatedTime To Work.

0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.3

A=AoxomoxoaH=HauptquartierI=IntensivstationV=Voltaire



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.7



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.8



0

0.5

1


Last

der

ein

zeln

en S

erve

r

¾Gesamtlast 0.9



Abbildung 5.15:Last an deneinzelnenServern (inhomogenesSystemmit Anfrage-klassen)

Die Last ist in Abbildung5.15nachdeneinzelnenServernaufgeschlusselt.Bei nied-rigen Lastenzeigt sich wiederdasvon denimplementiertendynamischenVerfahrengewohnteVerhalten,Server entsprechendder ReihenfolgedesAuffindensbevorzugtzu vermitteln.Die UberlegenheitderdynamischenStrategienbestatigt sichbei hohenLasten,dahiereineausgeglichenereLastverteilungerreichtwird alsbeidenstatischenVerfahren.Esfallt jedochauf,daßselbstfur ½ =0.9sowohl von Queuelength, alsauchvon EstimatedTime To Work derRechnerVoltaire starker belastetwurde.Zumindestfur die Strategie Queuelengthlaßtsichdasnicht dadurcherklaren,daßVoltaire auchfur derarthoheLastennochuberLeistungsreservenverfugt oderdurchdie Praferenzder Strategien fur denzuerstgefundenServer ofter vermitteltwird. Die Betrachtung


der Abbildung 5.16zeigt vielmehr, daßdie beidenRechnerTitanic und Voltaire beiQueuelengthin etwagleichoft genutztwurden.

0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.3



0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.7



0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.8



0

10

20

30

40

50

60


Anf

rage

n pr

o S

erve

r

¿Gesamtlast 0.9



Abbildung5.16:AnfragenproServer (inhomogenesSystemmit Anfrageklassen)

Wie schonbeimhomogenenFall mit verschiedenenAnfrageklassenist festzustellen,daßdie Varianzder dynamischenVerfahrenbezuglich der Anfragehaufigkeit relativhochist. Hier liegt ebenfalls dieVermutungnahe,daßdiesauf jeweilsunterschiedlichausfallende,knappeEntscheidungeninnerhalbdesLoad Balancerszuruckzufuhrenist. Spezielldie Schatzungder verbleibendenAntwortzeit, die die Strategie Estima-ted Time To Work anhanddermittlerenBedienratevorzunehmenversucht,wird durchdiedoppelteInhomogenitatdiesesSzenariosnochstarkerdurcheinandergebracht.Dieszeigtsichauchin Abbildung5.17,wo fur hoheLastendieKonfidenzintervallederEstimatedTime To Work-Strategie großausfallen.DasgleichermaßenschlechteAb-schneidenderstatischenStrategien laßtauchsichanderAnzahlderAuftragein denjeweiligenServersystemenfestmachen.An denlangsamenRechnernentstehengroßeStaus,die bei der Usage Count-Strategie aufgrundder dort verwendetenGleichver-teilungderAuftrage,die InhomogenitatdesSzenarioswiedergeben.Die dynamischenVerfahrenerreichenhingegen eine vergleichsweisegute GleichverteilungbezuglichdereinzelnenWarteschlangen.Auch in diesemUmfeld bestatigt sichdie Erkenntnis,daßbei inhomogenerRechner-leistunglediglich dynamischeStrategienzur Lastverteilunggeeignetsind.DurchdiezusatzlicheInhomogenitat, die sich durchdie verschiedenenAnfrageklassenergibt,sinkt die Leistungder Usage Count-Strategie, die beim homogenenFall mit Klas-sennochrelativ gutabschnitt,rapide.Als bestesLastverteilungsverfahrenerweistsich


0

1

2

3

4

5

6

7


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

rÀ

Gesamtlast 0.3



0

1

2

3

4

5

6

7


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.7



0

1

2

3

4

5

6

7


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.8



0

1

2

3

4

5

6

7


#Gle

ichz

eitig

e A

uftr

aege

im S

erve

r

ÀGesamtlast 0.9



Abbildung5.17:Auftrageim Systempro Server (inhomogenesSystemmit Anfrage-klassen)

Queuelength, die auchin diesemSzenariobei hoherAuslastungeine gleichmaßigeVerteilungderentstehendenLastvornehmenkann.

5.3.2 Einfluß desRegelwerksauf die Lastbalancierung

Nachdemin denvorhergehendenSzenariendieOptimierungderDienstauswahl ledig-lich bezuglichderLaststattfand,wird nundieLeistungsfahigkeit desrealisiertenTra-der/LoadBalancer-Systemfur denFall untersucht,daßzusatzlichbeiderOptimierungdieDienstattributierungzuberucksichtigenist. Im wesentlichenist hierbeiderEinflußderGewichtungsparameterundderverwendetenNormim Regelwerkvon Interesse.Die Entscheidung,wie LastundDienstgutezu gewichtensind, ist subjektiv. Die fol-gendenMeßergebnissekonnendahernuralsHilfe dienen,umzu entscheiden,welcheGewichtunggewahltwerdensoll, umbeidenzuerwartendenLastennocheineakzep-tableAntwortzeitzuerreichen.Als Beispielszenariowurde der klassenloseFall mit homogenerRechnerleistunggewahlt.Die vier DienstanbieterbotendengleichenDienstanundwurdenmit einemDienstattribut, dessenWert je nachDienstanbierterunterschiedlichausfiel,versehen.Dienstanbieter1 bekamdenWert 25, Dienstanbieter2 denWert 50, Dienstanbieter3denWert75undDienstanbieter4 denWert100.Durch die Import-Anfragewurdeder von diesenDienstanbieternangeboteneDienstgesucht,wobei dasverwendeteDienstattribut zu minimierenwar. Dem Regelwerk


wurdenverschiedeneParameterfur die Gewichtungvon Last und Dienstattributgutesowie fur diezuverwendendeNormvorgegeben.DadasRegelwerknebeneinerBewertungderDienstattributguteaucheineBewertungderLastbenotigt, konnennur Lastverteilungsstrategienverwendetwerden,dieauf ei-ner Lastmetrikbasieren.Die Strategie Randomscheidetdaheraus.Da die StrategieUsage Count die Anzahl der Dienstvermittlungenals Lastmetrikverwendet,wurdediesemit in dieBetrachtungeinbezogen.Die Abbildungen5.18bis5.20und5.22zeigendieAntwortzeiten,diesichfur diever-schiedenenLastverteilungsstrategien bei verschiedenenGewichtungenund Normenergeben.Nebendendrei hierbeieingesetztenStrategien ist zusatzlichnochzumVer-gleichdasbesteErgebnisdeshomogenenSzenariosausAbschnitt5.3.1.1eingezeich-net.Dort wurdedasgleicheUmfeldverwendet,allerdingsbeireinerLastbalancierung.Die Strategie Usage Counthat dort dasbesteErgebniserzielt.Es stellt fur die Pra-xis einerealistischereUntergrenzealsdiedesM/M/4-Warteschlangenmodellsdar. AndiesermußsichdasRegelwerkmessenlassen.

0

1

2

3

4

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last

Gewichtung: 75% Last, 25% Dienstattribut (Euklidische Norm)


Estimated_Time_To_WorkReine Lastbalancierung (Usage_Count)

Abbildung 5.18: Antwortzeiten bei Gewichtung von 75%:25% furLast/Dienstattributgutemit euklidischerNorm(homogenesSystem)

Die in Abbildung5.18dargestelltenAntwortzeitenbeieinerGewichtungvon75%furdenLastaspektund 25% fur die Dienstattributgute unterscheidensich fastnicht vondenWerten,die sieim Fall derreinenLastbalancierungangenommenhaben.Dort er-gabsich auchschondie leicht unterschiedlicheQualitat der StragienUsage Count,QueuelengthundEstimatedTime To Work, diesichhierebenfallswiederfindet.DieseGewichtungerweistsichdemzufolgealsunproblematisch,wenneineGewichtungge-


suchtwird, beiderdieDienstguteeinfließtundweiterhineinesehrguteLastverteilungstattfindet.Die abgebildetenAntwortzeitenwurdenunterVerwendungdereuklidischenNormge-messen.Die Werte,die sichbei EinsatzderManhattan-Distanzergeben,wurdenhiernicht aufgefuhrt, dasie sichbei dernochrechtstarkenGewichtungderLast nur mi-nimal von denendereuklidischenDistanzunterscheiden.Ebensowenigwurdedie Er-gebnissefur eine90% Gewichtungder Last vorgestellt,da sich dasErgebnissederGewichtungvon75%Lastbzw. 25%Dienstgutedemgegenubernichtveranderthat.Bei einer50%/50%GewichtungzeigtsichhingegeneinanderesBild. Sowohl die jetztnocherzielbareLastbalancierung,alsauchdie unterschiedlichenNormenbetreffend,ergebensichsichtbareUnterschiede.

0

1

2

3

4

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last





Abbildung5.19zeigtdie Antwortzeitenbei VerwendungdereuklidischenNorm.DerAnstieg derAntwortzeiterfolgt schnellerals in denvorherigenFallen. In deroberenHalftedesLaststpektrumsergibt sicheinerheblicherAbstandvonderLastverteilungs-qualitat,diesichergibt,wennlediglichdieLastberucksichtigtwird. Alle dreiStrategi-enverhaltensichhierbeiim wesentlichengleich.Bei kleinenLastenergibt sichledig-lich einminimalerVorteil fur dieStrategieUsage Count, beihohenfur Queuelength.In Abbildung 5.20 ist die analogeSituationbei Einsatzder Manhattan-Distanzauf-gefuhrt. Die Lastverteilungerfolgt auchbei hoherLast nochgut. Dies heißt im Ge-genzugaberauch,daßdie Dienstattributgute der zuruckgeliefertenDienstangebote


0

1

2

3

4

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last

Gewichtung: 50% Last, 50% Dienstattribut (Manhattan-Norm)



Abbildung 5.20: Antwortzeiten bei Gewichtung von 50%:50% furLast/Dienstattributgutemit Manhattan-Norm(homogenesSystem)

LastLast

1

2

3

4 Dienstanbieter

DienstgüteDienstgüte

12

3

4 Dienstanbieter

Euklidische Norm Manhattan-Norm

Abbildung5.21:AnzahlderDienstanbieterin Abhangigkeit von LastmetrikwertundDienstgute

schlechterausgefallen ist, da dasRegelwerk die gegebeneneSituationbzw. die At-tributwertenicht andernkann.

Um dasunterschiedlicheVerhaltender beidenNormenzu verstehen,bietet es sichan,die Ubergangezubetrachten,andenendie Normenjeweilsdazuubergehen,einenweiterenDienstanbieterzunutzen.In Abbildung5.21sindisometrischeLinien einge-zeichnet,andenendie jeweiligeNorm einenweiterenDienstanbietermit in die Kom-promißmengeaufnimmt.


Bei der euklidischenNorm ist die Flache,innerhalbder sich ein Kompromißzwi-schenDienstgute und Last nochauf einenDienstanbieterbeschrankt,großerals beiderManhattan-Norm.Daherfallt bei dereuklidischenNorm die Antwortzeitentspre-chendhoheraus.Die Manhattan-Normgehtfruherdazuuber, einenweiteren– vonderDienstguteschlechteren,aberunbelasteten– Dienstanbietervorzuschlagen.AufgrundihrerCharakteristikbemuhtsichdieManhattan-Metriknicht,einenKompromißin derMitte zwischenDienstguteundLastzu finden,sondernnimmt schnelleineschlechteDiensteigenschaftin Kauf, umdieLastzusenken.Bei einer zu starken Gewichtung der Dienstattributgute nutzt dies allerdingsauchnichtsmehr. Abbildung 5.22zeigt diesdeutlichfur denFall, daßder Lastaspektle-diglich mit 25% gewichtet wird, die Attributgute hingegenmit 75%. Hierbei haltenbeideNormensostarkandemDienstanbietermit derbestenDienstattributsgutefest,daßdasGesamtsystemzu einemSystemmit nur 1 Dienstanbieterdegeneriert.EineAnkunftsrate,die fur ein 4-Server-SystemeineLastvon ½ =0.3darstellt,laßtdie Ant-wortzeitdesderartdegeneriertenSystemsin dieHoheschnellen.Diesist examplarischfur dieeuklidischeNormdargestellt.

0

5

10

15

20

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

mitt

lere

Ant

wor

tzei

t [s]

Á

Last





Abschließendmuß darauf hingewiesen werden, daß das untersuchteSzenariowillk urlich gewahlt wurde. In Abhangigkeit von den Attributwertenund der Lei-stungsfahigkeit der Server kannsich bezuglich der Gewichtung,die nochzu akzep-tablenAntwortzeitenfuhrt,einanderesBild ergeben.


5.3.3 Lastverteilungsaufwand

Nebender Qualitat der erzieltenLastverteilungmußzur BewertungdesrealisiertenAnsatzesder zusatzlicheAufwand,der sich bei der DienstvermittlungaufgrunddesLoadBalancersergibt, untersuchtwerden.Im folgendenwerdenhierzudieDienstver-mittlungszeitunddiezusatzlichenKommunikationsaufrufe,die fur dieAktualisierungderLastinformationenbenotigt werden,betrachtet.

5.3.3.1 Dienstvermittlungszeit

Die Dienstvermittlungszeitsetztsich auseinemAnteil, dender Traderbenotigt, umDienstangeboteausseinenTabellenzusuchen,undeinemAnteil, denderLoadBalan-cerbenotigt, um die dabeientstehendeDienstauswahl unterdemLastaspektzu opti-mieren,zusammen.

0.07

0.08

0.09

0.1

0.11

0.12

0.13

0.14

0.15

0.16

0.17

0.18

0.19

0.2

1 2 3 4 5 6

mitt

lere

Ant

wor

tzei

t [s]

Â

Anzahl vermittelter Dienstangebote

Queuelength (Threaded Polling)Estimated_time_to_work (Polling)

Queuelength (Polling)Estimated_time_to_work (Caching)

Queuelength (Caching)Usage_count

Random

Abbildung 5.23: Mittlere Antwortzeitender verschiedenenTrader-/Load Balancer-Variantenin Abhangigkeit vonderAnzahlderzuruckgeliefertenDienste

In Abbildung5.23ist diemittlereAntwortzeitfur dieDienstvermittlungmit verschie-denenLastverteilungsstrategienzusehen.In derDiensttabelledesTraderswarensechsDienstangeboteeingetragen.Wie im vorhergehendenAbschnittwurdensieubergenaueineDiensteigenschaftattributiert.JedemDienstanbieterwurdeein eigenerDiensttypzugewiesen.Durch eine entsprechendeObertyp-/Untertyp-Relationim Typmanagerwar dafur gesorgt, daßbei denImport-Anfragen– je nachangegebenemDienstober-typ – ein bis sechsDienstangebotezuruckgeliefertwurden.Sofernesvon derjeweili-


genLastverteilungsstrategie unterstutzt wurde,sollte ubereineeuklidischeNorm einKompromißzwischenLastundDienstgutegetroffenwerden.DadieRandom-StrategiedieDienstauswahlohnedenLoadBalancervornimmt,kanndieserFall alsReferenzfurdieDienstvermittlungszeiteinerreinenTraderimplementie-rungangesehenwerden.Die Dienstvermittlungsdauersteigtin allenVariantenstarkerals linear mit der Anzahl der vermitteltenDienstangebotean. Als Erklarungkommthierfur in Frage,daßdiverseTrader-interneListenmehrfachdurchlaufenwerden,sodaßsichinsgesamteinAufwand ÃÅÄ�Æ�Ç@È ergibt.DerEinsatzdesLoadBalancersunddesRegelwerksfuhrtgegenuberdemreinenTra-dingzueinerhoherenDienstvermittlungsdauer.FallsdiebenotigtenLastinformationenperCachingaktualisiertwerden,fallt dieseErhohungallerdingssehrgeringaus.DieUsage CountunddieQueuelength-Strategienschneidenhierbeiambestenab. Diesistdadurchzu erklaren,daßdie hierbeizugrundeliegendenMetriken sehreinfachsind.Die Strategie EstimatedTime To Work setzteinekomplexereLastmetrikein. Bei je-demAuslesendieserMetrik mußeineBetriebssystemfunktionaufgerufenwerden,umdasAltern dieserMetrik zu berucksichtigen.Demenstprechendfallt hierdieAntwort-zeitetwashoheraus.Fur den Fall, daß die benotigten Lastinformationenper Polling jeweils wahrendder Dienstvermittlung erfragt werdenmussen,fallt die Erhohung der Antwortzeitstarker aus. Zur Ermittlung der dynamischenLastinformationenmuß ein entfern-ter Operationsaufrufan den Monitor abgeschicktwerden; dieser muß in seinerMIB die gewunschteMetrik nachschauenund zuruckschicken. Die Load Balancer-Komponentemußnun ihrerseitsdie empfangeneLast in die globaleMIB eintragen.Erstdannwerdendie gleichenSchrittewie beimCaching-Fall durchlaufen.Die Esti-matedTime To Work-Strategie nimmt nochmehrZeit in Anspruch,da der MonitorebenfallsdasAltern dieserMetrik berucksichtigenmuß.EinePolling-Variante,dieproPolling-Aufruf eineneigenenThreadbenutzt,solltediefur dasPolling benotigtenSchritteparallelabarbeitenund die Pausen,die sich beimWartenauf die Antwort einesentferntenMethodenaufrufsergeben,besserausnutzen.Die Messunghat jedochergeben,daßdiesnicht gelungenist. VielmehrscheintdieErzeugungvon neuenThreadsunddie notigeThread-Synchronisationsoviel Zeit inAnspruchzu nehmen,daßdieseVariantezu einer Verlangerungder Dienstvermitt-lungszeitfuhrt. Da in einemlokalenNetzPolling-Anfragensehrschnellbeantwortetwerden,ist dort eineeinfachePolling-Strategie vollig ausreichend.Beim EinsatzdesLoadBalancersin WeitverkehrsnetzenkonntesichderEinsatzeinerPolling-Strategiemit Threadshingegenlohnen,dadort die Polling-Anfragennicht mehrsoschnellbe-antwortetwerden.Um denOverhead,derdurchdie Erzeugungvon Threadsentsteht,zu verringern,wareesaußerdemmoglich, immer einenPool von Threadsbereitzuhalten,aufdendanndiePolling-Anfragenverteiltwerdenkonnen.Bei genauerBetrachtungderMeßergebnissezeigtsich,daßdieDienstvermittlungszeitbeiEinsatzdesLoadBalancersnichtumeinenkonstantenBetraguberderZeit desrei-nenTradersmit Random-Strategie liegt, sondernmit steigenderAnzahldervomLoadBalancerzu berucksichtigendenDienstangebotewachst.Der Load Balancermußje-


desvom TradergelieferteDienstangebotverwaltenund bewerten,so daßhierfur derAufwand ÃÅÄ�Æ7È anzusetzenist.DabeiderImplementierungaufEffizienzgeachtetwur-de,gehtderLoadBalancervermutlichmit ÉÄ�ÆDÈ in die Dienstvermittlungsdauerein.Durchdie Hashfunktionwird daswiederholteDurchlaufenvon Listenvermieden.DadasRegelwerk die vom TradergelieferteDienstangebotsmengenicht sortierenmuß,sondernlediglich den bestenKompromißheraussucht,geht dasRegelwerk nur mitdemAufwand É�Ä�ÆDÈ ein.Eslaßtsichfesthalten,daßdiezusatzlicheLastbalancierungzueinerVerlangerungderDienstvermittlungsdauerfuhrt. Bei Einsatzvon Caching-Verfahrenzur Lastubermitt-lung fallt dieseVerlangerungabersehrgeringaus.Polling-StrategienzurderUbertra-gungderLastinformationensolltenhingegenvermiedenwerden.

5.3.3.2 Kommunikationsaufwand

Als letztessoll diezusatzlicheKommunikation,die fur diedynamischeLastverteilungbenotigt wird, betrachtetwerden.HierzuwurdendieentferntenOperationsaufrufe,diezurUbermittlungderLastinformationenverschicktwerdenmußten,gezahlt.BeimPol-ling werdendiesevomLoadBalancerandieMonitoregesendet,beimCachingvondenMonitorenandenLoadBalancer.Wie im vorherigenAbschnitt wurdensechsDienstangebote,die in einer Untertyp-Beziehungzueinanderstanden,andenTraderexportiert.DurchentsprechendeImport-Anfragen wurden dem Load Balancerdurch den Trader – in Abhangigkeit vomgewunschtenDienstobertyp– ein bis sechsDienstangebotevorgelegt. Zur Lastver-teilung kam die EstimatedTime To Work-Strategie zum Einsatz.Diese sendetimCaching-BetriebproDienstnutzungzweiCache-AktualisierungenandenLoadBalan-cer. InsgesamterfolgteneinhundertImport-Anfragenmit anschließenderNutzungdesvermitteltenDienstes.EineparalleleNutzungderDiensteohnevorherigeVermittlungdurchdenTraderfandnichtstatt.

0

100

200

300

400

500

600

1 2 3 4 5 6Anz

ahl e

ntfe

rnte

r O

pera

tions

aufr

ufe


Polling

0

100

200

300

400

500

600

1 2 3 4 5 6Anz

ahl e

ntfe

rnte

r O

pera

tions

aufr

ufe


Caching

Abbildung5.24:AnzahlderentferntenOperationsaufrufebeiderLastubermittlungperCachingundPolling (100Import-Anfragenund100Dienstnutzungen)

Die ausdiesemSzenarioresultierendenErgebnissesindin Abbildung5.24aufgefuhrt.Es zeigt sich,daßmit steigenderAnzahlder Dienstanbieter, die vom Load Balancer


betrachtetwerden,auchdie AnzahlderPolling-Anfragenandie Monitoresteigt.Beijedemder einhundertImport-Aufrufe muß fur alle in FragekommendenDienstan-bieterdie Last ermittelt werden.Die Anzahl der Caching-Nachrichtenist hingegenkonstant.Ihr Wertergibt sichausderAnzahlderDienstnutzungenundderAnzahlderCache-Aktualisierungen,die proDienstnutzungdurchgefuhrtwerden.Die ErgebnisseentsprechendenUberlegungen,diebereitsin Abschnitt4.2.2.2gefuhrtwurden.Eszeigt sich,daßbei der UbermittlungderLastinformationendie Caching-StrategiewenigerAufrufe verursacht.Lediglich, wennnur ein Dienstanbieterbei derLastver-teilungin Fragekommt,schneidetdie Polling-Strategie besserab. Falls eineLastver-teilungsstrategie zum Einsatzkame,die mit einerCache-Aktualisierungpro Dienst-nutzungauskommt,ergabesichdiesenFall einGleichstand.Da eineLastverteilungerstbei mindestenszwei Dienstanbieternmoglich ist, kann–falls feststeht,daßnur ein Dienstanbieterin Fragekommt– fur diesenDienstanbieterganzaufdieUbertragungderLastinformationenverzichtetwerden.In derPraxiskanndieseEntscheidungjedochnichtallgemeingultig getroffenwerden,dasichdieMengeder fur die Lastverteilungin FragekommendenDienstanbieterin Abhangigkeit vomgewunschtenDienstobertypvon Import-Anfragezu Import-Anfrageandernkann.Le-diglich eineBetrachtungaller Diensttyp-Relationenkonntein einigenFallenergeben,daßeseinenDienstanbietergibt, derunabhangigvom ObertypseinenDienstalsein-zigeranbietet.Dieseund aller vorherigenUberlegungenverlierenallerdingsihre Gultigkeit, sobaldeinSzenariovorliegt, in demCache-AktualisierungenauchohnevorherigeDienstver-mittlung stattfinden.In diesemFall solltedaherzur MinimierungderentferntenOpe-rationsaufrufeder in Abschnitt 4.2.2.2vorgestellteAutomatismuszur dynamischenUmschaltungzwischenCachingundPollingeingesetztwerden.

5.4 Zusammenfassungder Meßergebnisse

Die BewertungderLastverteilungsgutederverschiedenenLastverteilungsstrategieninAbschnitt5.3.1hatergeben,daßdieVerwendungvonWissendesTradersuberzuruck-liegendeDienstvermittlungennurmoglich ist, wenneinSzenariomit homogenerSer-verleistungundkeinerHintergrundlastvorliegt. Davonkannin einemoffenenDienst-markt nicht ausgegangenwerden.Hierfur werdendynamischeLastverteilungsstrate-gienbenotigt. Eskonntenachgewiesenwerden,daßeinedynamischeLastverteilung,die lediglichdie Warteschlangenlangebetrachtet,in verschiedenstenSzenarienfur ei-ne sehrguteLastverteilungsorgt. WeitergehendesWissenuberdie BedienrateeinesDienstanbietershatzukeinersignifikantbesserenLastverteilunggefuhrt.Die Wahl von Gewichtungsfaktorenfur die Dienstattributguteunddie Lastbewertungkonntenur exemplarischbetrachtetwerden,da die darausresultierendeLastvertei-lung von denjeweiligenSystemparameternabhangt.Eshatsichgezeigt,daßeinezustarke Berucksichtungder Qualitat der Diensteigenschaftenleicht dazufuhrenkann,daßkeineLastverteilungmehrstattfindet.Der VergleichzwischeneuklidischerNorm

5.4.ZusammenfassungderMeßergebnisse 105

und Manhattan-Normhat ergeben,daßdie Manhattan-Normschnellerals die eukli-discheNorm dazuubergeht,weitereDienstanbieterin denzu treffendenKompromißzwischenLast und Dienstgute einzubeziehen.Hierbei werdenschlechtereDienstei-genschaftenin Kauf genommen.DerNutzermußentscheiden,obdieserwunschtist.Bei derBetrachtungdeszusatzlichenAufwands,derdurchdie BerucksichtigungdesLastaspektsbeiderDienstvermittlungentsteht,hatsichergeben,daßdieVerlangerungderDienstvermittlungsdauergeringist,wennzurErmittlungderLastinformationenei-neCaching-Strategieeingesetztwird. Polling-Strategiensolltenvermiedenwerden,dasienebeneinererhohtenDienstvermittlungsdauerim untersuchtenSzenarioaucheinerhohtesNachrichtenaufkommeninnerhalbdesNetzwerksnachsich zogen.Solan-ge vor jederDienstnutzungder Traderbefragtwird, verursachenCaching-StrategieneinengeringerenKommunikationsaufwand.

Kapitel 6

Schlußbemerkungen

Im Rahmender vorliegendenArbeit wurdeein Konzeptentwickelt, um Lastvertei-lungsaspektein dieDienstvermittlungeinesTraderseinzubeziehen.Die Studiein Kapitel 3 hatgezeigt,daßkeinesderexistierendenSystemeein zufrie-denstellendesKonzepthierfur anbietet.Daherwurdeein bestehenderTraderum eineLoad Balancer-Komponenteerweitert.Die Lastverteilungfindetfur denImportertransparentwahrendderDienstvermittlungstatt.Zur ErmittlungderbenotigtendynamischenLastinformationenwurdeeinaufdasMonitoringbeschranktesManagementsystemfur dieKomponentendesVerteiltenSy-stemserstellt.DiesesunterstutztvielfaltigeLastmetriken,sodaßin derLoadBalancer-KomponenteverschiedensteLastverteilungsstrategien benutztwerdenkonnen.Bei-spielhaftwurdenzweidynamischeundzweistatischeLastverteilungsstrategienimple-mentiert.Als Mittler zwischenderTrader- undderLoadBalancer-Komponentekommtein Regelwerk zumEinsatz,dasdie ErgebnismengenderbeidenKomponentenzu ei-nemKompromißzwischenhoherDienstguteundniedrigerLastzusammenfuhrt.Hier-zuwerdenDienstguteundLastalsVektoraufgefaßt,sodaßubereineAbstands-NormderjenigeDienstanbieterausgewahlt werdenkann,der dem theoretischenOptimumamnachstenkommt.Dieses Konzept wurde, wie in Kapitel 4 beschrieben,auf der CORBA-VerteilungsplattformOrbix implementiertundunterLeistungsaspektenbewertet.DieErgebnissewurdenin Kapitel 5 vorgestellt.Eskonntendie folgendenSchlussegezo-genwerden:Ê Die OptimierungderDienstauswahl unterdemAspektderLast ist eineaußerst

lohnenswerteErweiterungeinesTraders.Die Antwortzeitenbei der Nutzungeinesmehrfach angebotenenDiensteskonnenhierdurcherheblichgegenuberderublichen– rein diensteigenschaftsorientierten– Dienstvermittlungreduziertwerden.Hierfur mußjedocheineerhohteDienstvermittlungsdauerin Kauf ge-nommenwerden.BeiVerwendungeinerCaching-StrategiezurUbermittlungderLastinformationenfallt die VerlangerungderDienstvermittlungsdaueraberge-ring aus.

108 6. Schlußbemerkungen

Ê Die Verwendungvon Trader-eigenemWissen– wie die AnzahlderVermittlun-geneinesDienstanbieters– kannnur in einemidealisiertenSzenariozur Last-verteilunggenutztwerden.Im heterogenenUmfeld einesoffenenDienstmark-tessind statischenLastverteilungsstrategienungeeignet.Hierfur werdendyna-mischeLastverteilungstrategienbenotigt. EinfachedynamischeStrategien sinddabeiausreichend.Bereitsdie alleinigeBetrachtungderWarteschlangenlangendereinzelnenDienstanbietergarantierteinesehrguteLastverteilungin verschie-denstenSzenarien.GenaueresWissenuberdieBedienrateeinesDienstanbietersfuhrt demgegenuberzu keinernennenswertenSteigerungder Lastverteilungs-qualitat.Ê Ein KompromißzwischenDiensteigenschaftsguteundLast ist moglich. Dieserfuhrt allerdingsbei zuniedrigerGewichtungdesLastaspektswiederzuentspre-chendschlechtenAntwortzeiten.Die verschiedenenNormen,die im Regelwerkzur Bewertungder Dienstangeboteeingesetztwerdenkonnen,besitzenunter-schiedlicheCharakteristiken. Die Manhattan-Normgeht schnellerdazu uber,Dienstangebotemit niedrigererDienstgute auszuwahlen.Die GewichtungvonLast undDienstguteund die Wahl derzu verwendendenMetrik sindeinesub-jektiveEntscheidungundvomjeweiligenUmfeldabhangig.

TrotzderhervorragendenErgebnisse,dieerzieltwerdenkonnten,ist derAufwandderImplementierungeinessolchenSystemsnicht zu unterschatzen.Die Load Balancer-KomponentesamtMonitoringsystemliegt mit ca.4000Quelltext-Zeilen in der glei-chenGroßenordnungwie der– rechteinfache– Trader, auf demdasentwickelteSy-stembasiert.DasMonitoringsystemmachtdabeiallein die Halfte desUmfangsaus.Eswaredaherwunschenswert,hierfur aufeinerManagementumgebunginnerhalbdesVerteiltenSystemsaufbauenzu konnen.Die UmsetzungderentsprechendenCORBAManagement-Standardserfolgt allerdingsnur langsam,sodaßdaraufnicht zuruckge-griffenwerdenkonnte.Die Idee,einenTraderund einenLoad Balancerzu kombinieren,laßtnochuberdievorgenommeneImplementierunghinausviel Spielraumfur weitereUntersuchungen.HierbeikonnenverschiedensteAspekteweiterverfolgtwerden.In einemgroßenDienstmarktmussenFoderationenvon Traderneingesetztwerden.Hierbei gestaltetsich die Lastverteilungkomplexer. Es werdenRegeln benotigt, an-handdererentschiedenwerdenkann,wannweitereTraderbefragtwerdensollen,fallsdie Dienstanbieterder eigenenDomaneausgelastetsind. Auch die Ermittlung vonLastinformationenist in diesemFall schwieriger, da nicht mehrunmittelbarauf allebenotigtenManagementinformationenzugegegriffenwerdenkann.WeiterhinsolltenMechanismenuntersuchtwerden,mit denenDienstnutzer, die nichtregelmaßigeinenTraderzur Dienstauswahl aufsuchen,dennochzur Neuwahl einesDienstanbietersgezwungenwerdenkonnen.DurchdasLosenvon lang andauerndenBindungenkonnenauchderartigeDienstnutzervonderLastverteilungprofitieren.Stattdesauf einerVektor-Norm basierendenRegelwerkswareesauchdenkbar, Me-thodenausder Fuzzy-Logik oder der KunstlichenIntelligenz einzusetzen,um die

109

Ergebnissevon Traderund Load Balancerzusammenzufuhren.Ob sich die hiervonversprochenebessereKompromißbildunglohnt,mußteangesichtsderzuerwartendenlangerenDienstvermittlungszeitgepruft werden.Schließlichwarees interessant,zu untersuchen,inwiefern eineLastverteilungskom-ponenteeinenlediglich im BinarformatvorliegendenTradereinkapselnkann,um mitdessenHilfe eine Dienstvermittlungmit transparenterLastverteilungvorzunehmen.Dasim Kapitel 4 entwickelte Modell warehierfur einsetzbar, da esnicht zwingendeineVerzahnungvonTraderundLoadBalancervoraussetzt.

Literatur verzeichnis

[APRA98] P. Averkamp, A. Puder, K. Romer, K. Auel: Urbi et ORBi. In: iXMultiuser-Multitasking-Magazin,Heft 10/1998,Heise,S.74-85

[BK96] N. Brown, C. Kindel: DistributedComponentObject Model Protocol –DCOM/1.0. 1996(http://www.microsoft.com)

[Bol89] G. Bolch: Leistungsbewertungvon Rechensystemenmittels analytischerWarteschlangenmodelle. B. G. Teubner, Stuttgart,1989

[BU96] H. Brunne,Th. Uslander:Designof a Monitoring Systemfor CORBA-basedApplications. In: Trendsin Distributed Systems’96 – Industrialand Short PaperProceedings,O. Spaniol,C. Linnhoff-Popien,B. Mey-er (Hrsg.),AachenerBeitragezur Informatik (ABI), Band17, VerlagderAugustinusBuchhandlung,Aachen,1996,S.52-66

[Bur95] C. Burger:Cooperation policiesfor traders. In: OpenDistributedProces-sing– Experienceswith distributedenvironments,K. Raymond,L. Arm-strong(Ed.),Chapman& Hall, 1995,S.208-218

[Bur97] R.Burkhardt:UML – UnifiedModellingLanguage: ObjektorientierteMo-dellierungfur diePraxis. Addison-Wesley-Longman,Bonn,1997

[CFSD90] J.Case,M. Fedor, M. Schoffstall, C. Davin: SimpleNetworkManagementProtocoll. Requestfor Comments1157,1988

[CHY+97] P. E. Chung,Y. Huang,S.Yajnik, D. Liang,J.C. Shih,C.-Y. Wang,Y.-M.Wang:DCOM and CORBA – Sideby Side, Stepby Step,and Layer byLayer. Bell Labs,1997(http://www.bell-labs.com)

[CLR94] Th.H. Cormen,Ch.E.Leiserson,R.L. Rivest:Introductionto Algorithms.11.Auflage,MIT Press,1994

[CPRV96] V. Catania,A. Puliafito,S. Riccobene,L. Vita: Monitoring performancein distributedsystems. In: ComputerCommunications,Band19,Elsevier,1996,S.788-803

112 Literaturverzeichnis

[Del97] T. Delicia: Modelingof SomePlain LoadDistribution Strategiesfor Jobsin a MulticomputerSystem. InformaticsandComputerScience,Vol. 97,No. 1/2,Elsevier / North-Holland,1997,S.35-43

[Die97] S. Dierkes:Load Balancingwith a Fuzzy-DecisionAlgorithm. In: Infor-maticsandComputerScience,Vol. 97,No. 1/2,Elsevier / North-Holland,1997,S.159-177

[EJ91] H. Esser, H. Th. Jongen:Analysisfur Informatiker. Skript zur Vorlesung,1. Auflage,Augustinus,1991

[ELZ86] D. L. Eager, E. D. Lazowska,J. Zahorjan:AdaptiveLoadSharingin Ho-mogenousDistributedSystems. In: IEEE Transactionson SoftwareEngi-neering,Vol. SE-12,No. 5, IEEE,1986,S.662-675

[FS98] M. Fowler, K. Scott: UML konzentriert: die neue Standard-Objektmodellierungssprache anwenden. 2. Auflage, Addison-Wesley-Longman,Bonn,1998

[GGM93] M. A. Goodman,M. Goyal, R. A. Massoudi:SolarisPorting Guide, Sun,1993

[GLL96] W. Golubski,D. Lammers,W. Lippe: Theoretical andEmpirical ResultsonDynamicLoadBalancingin anObject-BasedDistributedEnvironment.In: Proceedingsof the 16th InternationalConferenceon DistributedSy-stems(ICDCS96),1996,S.537-544

[HA93] H.-G. Hegering, S. Abeck: Integriertes Netz- und Systemmanagement.Addison-Wesley, Bonn,1993

[Hav98] B. R. Haverkort: Performanceof ComputerCommunicationSystems:amodel-basedapproach. JohnWiley & Sons,Chichester, 1998

[Hei95] M. Heineken: Leistungsanalyseder Dienstvermittlungin einemODP-Prototypsystemunter besonderer Berucksichtigung der Kommunikation.Diplomarbeit,Lehrstuhlfur Informatik IV, RWTH Aachen,1995

[IDSM93] IDSM/SysMan:IDSM/SysManManagementArchitecture. Herve Barbot(Ed.),1993

[Inp98] Inprise: http://www.inprise.com/visibroker

[ISO84] ISO/IECIS 7498:InformationProcessingSystem– OpenSystemsInter-connection– BasicReferenceModel. 1984

[ISO89] ISO/IECIS 7498-4:InformationProcessingSystem– OpenSystemsInter-connection– BasicReferenceModel– Part 4: ManagementFramework.1989

Literaturverzeichnis 113

[ISO91] ISO/IEC IS 10165-4: Information Technology – Open SystemsInter-connection– Structure of ManagementInformation– Part 4: Guidelinesfor theDefinitionof ManagedObjects. 1991

[ISO94] ISO/IEC13235:Draft ODPTradingFunction. 1994

[ISO95a] ISO/IECIS 10746-1:ODPReferenceModelPart 1: Overview. 1995

[ISO95b] ISO/IECIS 10746-3:ODPReferenceModelPart 3: Architecture. 1995

[ISO96] ISO/IECDIS 13235-1:ODPTradingFunctionPart 1: Overview. 1996

[Ion97a] Iona:Orbix Programmer’sGuide2.3. IONA Technologies,1997

[Ion97b] Iona:Orbix Programmer’sReference2.3. IONA Technologies,1997

[Ion98] Iona:OrbixTraderProgrammer’s GuideandReference. IONA Technolo-gies,1998

[JLS+87] J.Joyce,G. Lomow, K. Slind,B. Unger:MonitoringDistributedSystems.In: ACM TransactionsonComputerSystems,Vol. 5, No. 2, 1987,S.121-150

[Kau92] F.-J. Kauffels: Netzwerk-Management:Probleme, Standards, Strategien.Datacom,Bergheim,1992

[KB95] E. Kovacs,C. Burger:Projektbeschreibung:MELODY– ManagementEn-vironmentfor Large OpenDistributedSystems. Institut fur ParalleleundVerteilteHochstleistungsrechner, UniversitatStuttgart,1995

[Kel93] L. Keller: VomName-ServerzumTrader– ein Uberblick uberTradinginverteiltenSystemen. In: PraxisderInformationsverarbeitungundKommu-nikation(PIK), Band16,K.G. SaurVerlag,Munchen,1993,S.122-133

[KN97] A. Keller, B. Neumair:Using ODP as a Framework for CORBA-basedDistributedApplicationsManagement. In: Proceedingsof the IFIP/IEEEJoint InternationalConferenceon OpenDistributedProcessing(ICODP)andDistributedPlatform(ICDP),Toronto,1997

[Kov94] E. Kovacs:Trading und Managementverteilter Anwendungen: zentraleAufgabenfur zukunftige verteilteSysteme. In: NeueKonzeptefur die Of-feneVerteilteVerarbeitung,C. Popien,B. Meyer (Hrsg.),AachenerBei-tragezurInformatik(ABI), Band7,VerlagderAugustinusBuchhandlung,Aachen,1994,S.57-66


[Kov96] E.Kovacs:AdvancedTradingServicesThroughMobileAgents. In: Trendsin DistributedSystems’96 – IndustrialandShortPaperProceedings,O.Spaniol,C. Linnhoff-Popien,B. Meyer(Hrsg.),AachenerBeitragezur In-formatik (ABI), Band17,VerlagderAugustinusBuchhandlung,Aachen,1996,S.112-113

[KRK94] Th. Koch, G. Rohde,B. Kramer:AdaptiveLoad Balancingin a Distri-butedEnvironment. In: 1st Int. Workshopon Servicesin DistributedandNetworked Environments,IEEE ComputerSocietyPress,Prag,1994,S.115–121

[Kup95] A. Kupper:Untersuchungvon dynamischenAttributierungsansatzenbeider Dienstvermittlungunter ANSAware. Diplomarbeit,Lehrstuhlfur In-formatik IV, RWTH Aachen,1995

[LR96] C. Linnhoff-Popien,P. Reichl: Netzmanagement– Skript zur denVorle-sungen an der RWTH Aachenund der Universitat GH Essen. AachenerBeitragezurInformatik(ABI), Band18,VerlagderAugustinusBuchhand-lung,Aachen,1996

[Mey90] B. Meyer: ObjektorientierteSoftwareentwicklung. Hanser/Prentice-HallInternational,Munchen/London,1990

[MP93] Z. Milosevic, M. Phillips: Somenew performanceconsiderationsin opendistributedenvironments. In: IEEE InternationalConferenceon Commu-nicationsICC’93, IEEE,New York, 1993,S.961-965

[MS93] M. Mansouri-Samani,M. Sloman:Monitoring Distributed systems. In:IEEENetwork, 7. Jg.,Heft 6, November1993,S.20-30

[MTS89] R. Mirchandaney, D. Towsley, J. A. Stankovic: Analysisof the EffectsofDelayson Load Sharing. In: IEEE Transactionson Computers,Vol. 38,No. 11,IEEE,1989,S.1513-1525

[Nag90] M. Nagl: Softwaretechnik: methodisches Programmieren im Großen.Springer, Berlin, 1990

[OMG95a] OMG: The Object Management Architecture Guide. 1995(http://www.omg.org)

[OMG95b] OMG: CORBAfacilities: Common Facilities Architecture. 1995(http://www.omg.org)

[OMG97] OMG: CORBAservices:CommonObject Service Specification. 1997(http://www.omg.org)


[OMG98] OMG: TheCommonObjectRequestBroker: ArchitectureandSpecificati-on– Rev. 2.2. 1998(http://www.omg.org)

[OSF94] OSF:OSFDCE ApplicationDevelopmentGuide. Cambridge,MA., 1994(http://www.osf.org)

[Pop96] C. Popien:VerteilteSysteme– Skript zur denVorlesungenan der RWTHAachenundder Universitat GH Essen. AachenerBeitragezur Informatik(ABI), Band16,VerlagderAugustinusBuchhandlung,Aachen,1996

[PR98] A. Puder, K. Romer:MICO is CORBA. dpunkt,Heidelberg, 1998

[Ray94] K.A. Raymond:ReferenceModelof OpenDistributedProcessing:a Tuto-rial . In: OpenDistributedProcessingII, J.deMeeret.al.,Elsevier / North-Holland,1994,S.3-14

[RBP+93] J.Rumbaugh,M. Blaha,W. Premerlani,F. Eddy, W. Lorensen:Objektori-entiertesModellierenundEntwerfen. Hanser/Prentice-HallInternational,Munchen/London,1993

[Red96] J.-P. Redlich: CORBA 2.0: Praktische Einfuhrung fur C++ und Java.Addison-Wesley, Bonn,1996

[SB97] B. Schiemann,L. Borrmann:A new approach for load balancingin high-performancedecisionsupportsystems. In: FutureGenerationsComputerSystems,No. 12,Elsevier / North-Holland,1997,S.345-355

[Sch91] A. Schill: Verteilte objektorientierteSysteme:Grundlagen und Erweite-rungen. In: Informatik Forschungund Entwicklung, Band 6, Springer,1991,S.14-27

[Sch96a] B. Schiemann:A New Approach for Load Balancing in HeterogenousDistributedSystems. In: Trendsin Distributed Systems’96 – Industrialand Short PaperProceedings,O. Spaniol,C. Linnhoff-Popien,B. Mey-er (Hrsg.),AachenerBeitragezur Informatik (ABI), Band17, VerlagderAugustinusBuchhandlung,Aachen,1996,S.29-39

[Sch96b] B. Schiemann:Specificationof IDL Mechanismsfor SupportingLoadBa-lancing. LYDIA / WP.4 / T4.2/ D6, ESPRITIII P8144,1996

[Sch97a] B. Schiemann:ExploitingInterfaceDefinitionLanguagesfor LoadBalan-cing. In: InformaticsandComputerScience,Vol. 97, No. 1/2, Elsevier /North-Holland,1997,S.221-231

[Sch97b] D. Schafer: Entwurf und Bewertungvon Caching-Strategienbei der An-frageauswertungin Traderfoderationen. Diplomarbeit,Lehrstuhlfur In-formatik IV, RWTH Aachen,1997


[Sei94] J. Seitz:Netzwerkmanagement. InternationalThomsonPublishing,Bonn,1994

[Sem97] M. Semrau:DynamischesLoadBalancingfur replizierteCORBA-Objekte.Diplomarbeit,Lehrstuhlfur Informatik IV, RWTH Aachen,1997

[SF94] O. Spaniol,A. Faßbender:ModellierungundBewertungvonRechensyste-men. SkriptzurVorlesung,2. Auflage,Aachen,1994

[SG94] A. Silberschatz,P. B. Galvin: Operating SystemsConcepts. Addison-Wesley, Reading,1994

[SL94] M. Schuhmann,A. Lobinger: Zeitspiel. In: iX Multiuser-Multitasking-Magazin,Heft 11/1994,Heise,S.168-173

[Slo94] M. Sloman:Network and Distributed SystemsManagement. Addison-Wesley, Reading,1994

[SPM94] O. Spaniol, C. Popien, B. Meyer: Dienste und DienstvermittlunginClient/Server-Systemen. InternationalThomsonPublishing,Bonn,1994

[Sta95] M. Stal:DerZugrollt weiter. In: iX Multiuser-Multitasking-Magazin,Heft5/1995,Heise,S.160-168

[Sto93] H. Stocker: Taschenbuch mathematischer FormelnundmodernerVerfah-ren. 2. Auflage,Harri Deutsch,Frankfurt,1993

[Str92] B. Stroustrup: Die C++-Programmiersprache. 2. Auflage, Addison-Wesley, Bonn,1992

[Tan95] A. S.Tanenbaum:ModerneBetriebssysteme. 2. Auflage,Hanser/Prentice-Hall InternationalEditions,Munchen/London,1995

[Tan96] A. S. Tanenbaum:ComputerNetworks. Prentice-HallInternational,Lon-don,1996

[Thi96] D. Thißen: QoS-basierteOptimierung der Dienstselektionin einemORBIX-Trader. Diplomarbeit,Lehrstuhl fur Informatik IV, RWTH Aa-chen,1996

[WM85] Y.-T. Wang,R.J.T. Morris:LoadSharingin DistributedSystems. In: IEEETransactionsonComputers,Vol. C-34,No. 3, IEEE,1985,S.204-217

[WT93] A. Wolisz, V. Tschammer:Performanceaspectsof trading in opendis-tributedsystems. In: ComputerCommunications,Band16, Butterworth-Heinemann,1993,S.277-287


[YD96] Z. Yang,K. Duddy: CORBA: A Platformfor DistributedObjectCompu-ting. DSTC,Australien,1996

[ZFD93] M. Zimmermann,M. Feldhoffer, O. Drobnik: Verteilte Anwendungen:Entwurf und Realisierung. In: Praxisder InformationsverarbeitungundKommunikation(PIK), Band 16, K.G. SaurVerlag,Munchen,1993,S.62-69

[Zla96] S.Zlatintsis:EntwurfundBewertungeinesTrader-GatewayzwischenAN-SAware und ORB-Systemen. Diplomarbeit,Lehrstuhlfur Informatik IV,RWTH Aachen,1996

Diplomarbeit Optimierung der Dienstauswahl in einem CORBA ... · Rheinisch-Westfalische Technische...

Documents

Transcript of Diplomarbeit Optimierung der Dienstauswahl in einem CORBA ... · Rheinisch-Westfalische Technische...