View
4
Download
0
Category
Preview:
Citation preview
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
6 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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].
2.1.VerteilteSysteme 7
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
8 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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
2.1.VerteilteSysteme 9
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.
10 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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.VerteilteSysteme 11
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
12 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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
2.1.VerteilteSysteme 13
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
14 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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.VerteilteSysteme 15
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
16 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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.
2.1.VerteilteSysteme 17
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.
18 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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
20 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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-
22 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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
2.3.Lastverteilung 23
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.
24 2. DienstvermittlungundLastbalancierungin VerteiltenSystemen
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
2.3.Lastverteilung 25
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.
30 3. OptimierungderDienstauswahldurchLastbalancierung
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-
32 3. OptimierungderDienstauswahldurchLastbalancierung
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
34 3. OptimierungderDienstauswahldurchLastbalancierung
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
36 3. OptimierungderDienstauswahldurchLastbalancierung
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.Verbesserungsmoglichkeiten 37
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.
38 3. OptimierungderDienstauswahldurchLastbalancierung
� 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.
3.4.Verbesserungsmoglichkeiten 39
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
40 3. OptimierungderDienstauswahldurchLastbalancierung
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
3.4.Verbesserungsmoglichkeiten 41
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
42 3. OptimierungderDienstauswahldurchLastbalancierung
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
3.4.Verbesserungsmoglichkeiten 43
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
48 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.1.ModellierungdesTradingsundderLastbalancierung 49
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.
50 4. RealisierungeinesTradingsystemszurLastbalancierung
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-
4.1.ModellierungdesTradingsundderLastbalancierung 51
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.
52 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.1.ModellierungdesTradingsundderLastbalancierung 53
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
54 4. RealisierungeinesTradingsystemszurLastbalancierung
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.
4.1.ModellierungdesTradingsundderLastbalancierung 55
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
56 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.1.ModellierungdesTradingsundderLastbalancierung 57
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-
58 4. RealisierungeinesTradingsystemszurLastbalancierung
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.
60 4. RealisierungeinesTradingsystemszurLastbalancierung
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.
4.2.ImplementierungdesModells 61
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:
62 4. RealisierungeinesTradingsystemszurLastbalancierung
& 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
4.2.ImplementierungdesModells 63
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
64 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.2.ImplementierungdesModells 65
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
66 4. RealisierungeinesTradingsystemszurLastbalancierung
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.
4.2.ImplementierungdesModells 67
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
68 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.2.ImplementierungdesModells 69
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
70 4. RealisierungeinesTradingsystemszurLastbalancierung
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-
4.2.ImplementierungdesModells 71
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-
72 4. RealisierungeinesTradingsystemszurLastbalancierung
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.
4.2.ImplementierungdesModells 73
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
74 4. RealisierungeinesTradingsystemszurLastbalancierung
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
4.2.ImplementierungdesModells 75
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
76 4. RealisierungeinesTradingsystemszurLastbalancierung
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
80 5. BewertungdesAnsatzes
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
82 5. BewertungdesAnsatzes
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
84 5. BewertungdesAnsatzes
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
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.3:LastandeneinzelnenServern(homogenesSystem)
0
10
20
30
40
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.4:AnfragenproServer (homogenesSystem)
Last die Verteilungder Anfragenungleichmaßigist, bedeutetdies jedochnicht, daßdies auchzu schlechtenAntwortzeitenfuhrt. Die Ungleichverteilungtritt nur dann
5.3.Meßergebnisse 85
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
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
00.5
11.5
22.5
33.5
44.5
5
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
00.5
11.5
22.5
33.5
44.5
5
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
00.5
11.5
22.5
33.5
44.5
5
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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).
86 5. BewertungdesAnsatzes
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
RandomUsage_CountQueuelength
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.
5.3.Meßergebnisse 87
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
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.
88 5. BewertungdesAnsatzes
0
10
20
30
40
50
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r¿
Gesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.8:AnfragenproServer (inhomogenesSystem)
0
1
2
3
4
5
6
7
8
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
8
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
8
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
8
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.9:Auftrageim SystemproServer (inhomogenesSystem)
Bezuglich derAuftrage,die sichgleichzeitigim Server-Warteschlangensystembefin-den,spiegelt sich bei niedrigerAuslastung– wie zu erwarten– die Last wieder. Bei
5.3.Meßergebnisse 89
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-
90 5. BewertungdesAnsatzes
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
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.
5.3.Meßergebnisse 91
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=AoxomoxoaO=OstgoteT=TitanicV=Voltaire
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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-
92 5. BewertungdesAnsatzes
0
10
20
30
40
50
60
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r¿
Gesamtlast 0.3Random
Usage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A H I V A H I V A H I V A H I V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.12:AnfragenproServer (homogenesSystemmit Anfrageklassen)
0
1
2
3
4
5
6
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.5
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
A H I V A H I V A H I V A H I V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.13:Auftrageim SystemproServer(homogenesSystemmit Anfrageklas-sen)
5.3.Meßergebnisse 93
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
RandomUsage_CountQueuelength
Estimated_Time_To_Work
Abbildung5.14:Antwortzeitenfur reineLastbalancierung(inhomogenesSystemmitAnfrageklassen)
94 5. BewertungdesAnsatzes
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
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=AoxomoxoaH=HauptquartierI=IntensivstationV=Voltaire
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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
5.3.Meßergebnisse 95
der Abbildung 5.16zeigt vielmehr, daßdie beidenRechnerTitanic und Voltaire beiQueuelengthin etwagleichoft genutztwurden.
0
10
20
30
40
50
60
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
10
20
30
40
50
60
A O T V A O T V A O T V A O T V
Anf
rage
n pr
o S
erve
r
¿Gesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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
96 5. BewertungdesAnsatzes
0
1
2
3
4
5
6
7
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
rÀ
Gesamtlast 0.3
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.7
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.8
RandomUsage_CountQueuelength
Estimated_Time_To_Work
0
1
2
3
4
5
6
7
A O T V A O T V A O T V A O T V
#Gle
ichz
eitig
e A
uftr
aege
im S
erve
r
ÀGesamtlast 0.9
RandomUsage_CountQueuelength
Estimated_Time_To_Work
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
5.3.Meßergebnisse 97
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)
Usage_CountQueuelength
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-
98 5. BewertungdesAnsatzes
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
Gewichtung: 50% Last, 50% Dienstattribut (Euklidische Norm)
Usage_CountQueuelength
Estimated_Time_To_WorkReine Lastbalancierung (Usage_Count)
Abbildung 5.19: Antwortzeiten bei Gewichtung von 50%:50% furLast/Dienstattributgutemit euklidischerNorm(homogenesSystem)
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
5.3.Meßergebnisse 99
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)
Usage_CountQueuelength
Estimated_Time_To_WorkReine Lastbalancierung (Usage_Count)
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.
100 5. BewertungdesAnsatzes
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
Gewichtung: 25% Last, 75% Dienstattribut (Euklidische Norm)
Usage_CountQueuelength
Estimated_Time_To_WorkReine Lastbalancierung (Usage_Count)
Abbildung 5.22: Antwortzeiten bei Gewichtung von 50%:50% furLast/Dienstattributgutemit euklidischerNorm(homogenesSystem)
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.Meßergebnisse 101
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-
102 5. BewertungdesAnsatzes
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-
5.3.Meßergebnisse 103
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
Anzahl vermittelter Dienstangebote
Polling
0
100
200
300
400
500
600
1 2 3 4 5 6Anz
ahl e
ntfe
rnte
r O
pera
tions
aufr
ufe
Anzahl vermittelter Dienstangebote
Caching
Abbildung5.24:AnzahlderentferntenOperationsaufrufebeiderLastubermittlungperCachingundPolling (100Import-Anfragenund100Dienstnutzungen)
Die ausdiesemSzenarioresultierendenErgebnissesindin Abbildung5.24aufgefuhrt.Es zeigt sich,daßmit steigenderAnzahlder Dienstanbieter, die vom Load Balancer
104 5. BewertungdesAnsatzes
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
114 Literaturverzeichnis
[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)
Literaturverzeichnis 115
[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
116 Literaturverzeichnis
[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
Literaturverzeichnis 117
[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
Recommended