Model-Based Monitoring in Large-Scale Distributed Systems

Transcription

1 Model-Based Monioring in Large-Scale Disribued Sysems Diploma Thesis Carsen Reimann Chemniz Universiy of Technology Faculy of Compuer Science Operaing Sysem Group Advisors: Prof. Dr. Winfried Kalfa Dr. Sven Graupner

2 Model-Based Monioring in Large-Scale Disribued Sysems Reimann, Carsen p. Chemniz Universiy of Technology, Faculy of Compuer Science, Operaion Sysem Group Diploma Thesis By: Carsen Reimann Born 05/07/1978 in Zwickau, Germany Issued: 03/01/2002 Published: 05/31/2002

3 Task The goal of his work is o define a model descripion of a chosen disribued applicaion running in he CLIC environmen, represen his model wih is elemens and parameers in he daabase buil in he previous projec and build a monioring infrasrucure which allows o consanly calibrae model parameers such ha a any ime a realisic picure of he applicaion s behavior can be obained. Anoher goal is o collec saisics (races) of how model parameers have evolved over ime. Experimens conclude he work demonsraing he concep and implemenaion. Following seps are proposed: 1. Choosing a disribued applicaion environmen 2. Idenifying componens and links wih associaed parameers represening he behavior of ha applicaion 3. Idenifying appropriae merics o express behavioral characerisics 4. Mapping he model ino a daabase schema 5. Exernal presenaion of model informaion 6. Sensor infrasrucure 7. Experimenaion in he CLIC

4

5 Absrac Monioring remains an imporan problem in compuer science. This hesis describes which monior informaion is needed o analyze disribued service environmens. This hesis also describes how o ge hese informaion and how o sore hem in a monioring daabase. The resuling model is used o describe a disribued media conen environmen and a simulaion sysem ha runs on he CLIC helps o generae measuremens as in real sysems.

6

7 7 Conens 1 Inroducion Scenario Goal Precursory Work Daa Srucure Inerface Browser Adaper Overview Modeling Services Inroducion Basic Services Characerisic Parameers of Basic Services Disribued Services Characerisic Parameers of Disribued Services Summary Geing Characerisic Parameers Measuremens Evaluaing Service Parameers Geing Measuremens Measuremen Failure Sensors Locaion Aciviy Daabase Sorage XML Represenaion Curren Sae Trace Disribued Media Conen Overview Sysem Model Sysem Characerisics Cusomer Behavior Sysem Srucure Typical Parameers of Media Conens...31

8 8 Conens Typical Cusomer Behavior Service Models Sensor Summary Daabase Sorage XML Represenaion Simulaion wih Service Models Inroducion Model Srucure Policy Requiremens Mehods Synchronizaion Implemenaion Simulaion Processes Configuraion Browser Adaper Overview XML-Message Examples A Cause for Media Ceners Service Model Configuraion Resuls Conclusion Preloading Media Conen Service Model Configuraion Resuls Conclusion Conclusion Possibiliies for he Fuure Relaed Work Acronyms Figures Bibliography...71

9 9 1 Inroducion 1.1 Scenario Monioring remains an imporan problem in compuer sysems. Research a HP Labs anicipaes ha compuer sysems and heir managemen sysems will become much larger in fuure. Exising monioring echniques such as hose used in producs like HP OpenView are assumed o reach heir limis for several reasons. They collec oo fine-grained daa such as uilizaion of neworks, machines, sorage and oher hardware componens. The goal of a projec a HP Labs called self-organizing services is o beer undersand sysem behavior a higher-order sofware and service layers. Since hardware infrasrucure is shared among differen applicaions and services, i is hard o derive applicaion- and service-level behavior from he colleced monioring daa. Though echniques have been developed for deriving and condensing applicaion shares from aggregaed load in a boom-up fashion, hese approaches are complicaed and only applicable in cerain areas. 1.2 Goal The goal of his work is o define a model a applicaion layer of disribued sysems. I aemps o find ou which merics can be idenified for individual services ha characerize heir behavior and how hese merics can be obained from monioring a real sysem. These monioring daa should be sored ino he daabase buil in he previous projec [XMDB]. Therefore he model mus be mapped ino a daabase schema o enable adjusmen of model parameers by consanly monioring hem laer in he real applicaion sysem. The measured values need o be analyzed in wo ways. Firs, he saisical curren model descripion wih a se of model parameer obained by measures in he real sysem. Second, i conains saisical races showing how model parameers have changed over ime. The daabase schemaa for he model and for he hisory races should be exposed in form of separae downloadable XML [XML] documens ouside he daabase allowing he discoverabiliy of he daa srucure. The model informaion mus be made exernally accessible by defining queries over hese daa ses. The exising XML and browser inerface of he daabase should be used for his purpose and possibly be exended.

10 10 1 Inroducion Anoher goal is o use he model by choosing a disribued applicaion for monioring. The applicaion should use muliple componens ha communicae among each oher.

11 11 2 Precursory Work The precursory work was a daabase build by Koenig, R. and Reimann, C. I allows o sore monioring daa ino hierarchically srucured measuremen ables. The daabase operaes wih an XML-inerface for daa access and daa manipulaion. I uses HTTP for communicaion and is accessible by sandard browsers like Inerne-Explorer and Nescape Communicaor. The previous work is compleely described in [XMDB]. 2.1 Daa Srucure All monioring daa can be srucured hierarchically for sorage in he daabase. This srucure is comparable o he organizaion of file sysems. There are folders o organize he srucure and here are parameer ables as conainers for measured values. A simple example of heir use is shown in Figure 2-1. I conains he organizaion of he CLIC ( Chemnizer Linux Cluser ): There are differen machines (e.g. clic2f23 ) and hey each have daa ables for measuring values, in his example memory and cpu. CLIC folder +clic2f23 folder +memory daa able +cpu daa able +clic3i31 folder +memory daa able +cpu daa able Figure 2-1: Simple srucure in daabase Every iem in he ree srucure has a parameer ha shows is acual sae. There are 3 differen possible saes: - Acive The daa able is ready for measuremen values - Inacive The daa able is emporarily no ready for measuremen values - Closed Measuremen is complee and only reading access is possible Measuremen daa o be sored ino a daa able consis of wo values. One is he imesamp and he oher is he dedicaed daa value. The daabase is able o sore differen daa ypes ino he daa ables. Possible ypes are Ineger-, Floa- and Sring-Values. A few ypical examples are shown in Figure 2-2.

12 12 2 Precursory Work Real-values: Time Value :21: :21: :21: :21: :21: :21: Sring-values: Time Value :32:41 WAIT :32:43 RECEIVE :32:44 COMPUTE :32:45 WAIT :32:46 WAIT :32:48 SEND Figure 2-2: Parameer able examples 2.2 Inerface All communicaions wih he daabase (e.g. inser records or manipulae ree srucure) are hough XML. Tha means ha all commands o he daabase are in he form of XMLdocumens. The exchange of hese documens is realized wih he servle echnology and uses HTTP as ranspor proocol. HP Labs offered his messaging sysem. There are 3 ypes of command messages: - Queries Used for geing sored daa values - Manipulaions Used for inserion, changing or deleion of daa values - Managemen Used o manage he hierarchical srucure (e.g. creae ables) Figure 2-3 shows a sample message for a daa query from he cpu -measuremens of he clic2f23 machine in he CLIC. All oher command messages are buil similarly. <?xml version="1.0" encoding="utf-8"?> <body> <daaquery> <ableselec> <sub name="roo" /> <sub name="clic" /> <sub name="clic2f23" /> <sub name="cpu" /> </ableselec> <inerval> <begin daetime=" :00:00" /> <end daetime=" :30:00" /> </inerval> </daaquery> </body Figure 2-3: Message for daa query

13 2.3 Browser Adaper Browser Adaper The daabase also offers a user inerface, which can be used wih sandard browsers. This inerface, a so-called Browser Adaper, communicaes hrough he XML inerface described in secion 2.2 and is also based on servle echnology. This user inerface offers a comforable use of he daabase and presenaion of monioring daa. The presenaion of monioring daa can be exual and also graphical by using SVG, a language o describe wo-dimensional graphics in XML. 2.4 Overview Figure 2-4 shows he main componens of he daabase and how hey cooperae. Tomca 3.3 is used as a HTTP-server and servle engine. And PosgreSQL is used as a relaional daabase. HTTP- Server Browser- Adaper XML-Inerface DB Figure 2-4: Main componens of he daabase

14

15 15 3 Modeling Services 3.1 Inroducion Typical disribued sysems consis of differen aciviies, which are communicaing wih each oher [MVS]. For he analysis of disribued sysems we need a model ha represens he whole sysem. The model should suppor performance analysis of he sysem. Tha means o find ou: Where are he bolenecks? And, which componens are rarely used? Quasi: Analyze a sysem for an opimizaion. A curren performance model of disribued sysems is he queuing nework model. I suppors he needed analysis of disribued sysems. Therefore his model is he fundamen of he following service model. 3.2 Basic Services Services are aciviies, which process cerain jobs. They are hosed on an infrasrucure called server, his may be a simple compuer, a muli processor machine, a cluser sysem and he like. Several services can be hosed on such a server: Server Services Figure 3-1: Services on a server The general procedure of a service process is: Waiing for a job, receiving job informaion from a clien, processing he job, sending he resul of he job back o he clien and waiing for nex job. The clien is anoher process, which is hosed on he same server or on a remoe sysem (see chaper 3.4.) Jobs can be e.g. ransacions on a daabase, HTML-requess o a web-server or media requess o a media conen server in a VoD sysem.

16 16 3 Modeling Services Waiing for jobs Complee (send resuls) Receive job Processing Job Figure 3-2: The general saes of a service process If we look a a web-server on a Linux machine, he server will be he compuer on which he web-server process (e.g. Apache [AWS]) runs. The service process will be he web-server process. The saes of his service process are shown in Figure 3-3. The web-server sleeps unil a clien requess a HTML-page. Afer he reques he server provides he requesed HTML-page and he web-server sends i hen o he clien. Waiing for HTTP-requess Complee (send HTML-page) Receive HTTP-requess Geing HTML-page Figure 3-3: Saes of a web-server service process 3.3 Characerisic Parameers of Basic Services A basic service can be reaed like a single queuing saion in a queuing nework [PCCS], [MLR]. Imporan quesions are: How many jobs can he service process? How many jobs ges he service? These are parameers, which depends on a period of ime: ime We can define he following parameers: Figure 3-4: Period of ime for he parameers λ (, ) : The number of incoming jobs per second (reques rae) in a paricular ime period

17 3.4 Disribued Services 17 µ (, ) : The mean number of jobs per second, which he service is able o process 1 : The mean ime o process one job µ (, ) λ(, ) ρ (, ) = : The uilizaion of a service a a special ime period µ (, ) λ = 5 1 s µ = s λ p = = 0,05 µ Figure 3-5: A simple example of characerisic parameers 3.4 Disribued Services In he previous chaper we analyzed basic services. In pracice, many sysems consis of muliple, disribued services [MDS]. Disribued services means ha here are differen services on differen servers. These services depend on each oher; one service needs oher services for he compleion of a job. Services are in relaion wih each oher, hey form a kind of nework. Disribuion also means ha several services, on differen servers, offer he same scope of funcion. Which service is used can be chosen by he clien or a disribuing aciviy. This needs a sligh change in he service sae model: Waiing for jobs Complee (send resuls) Receive job Processing Job Receive resuls Reques remoe job Waiing for remoe job Figure 3-6: Saes of disribued service processes

18 18 3 Modeling Services 3.5 Characerisic Parameers of Disribued Services Le us ake a look a a simple scenario on Figure 3-7, which consiss of hree service processes on hree servers. A LAN connecs hem. Service process 1 is a web-server, which ges jobs (HTTP-requess) from web-browsers. Service processes 2 and 3 are daabase processes he webserver accesses. The sequence may be: The web-server ges a reques from a web-browser, reads values from a daabase and sends he resul back o he web-browser. The web-server ges requess wih rae λ 0, 1 and needs daa from service process 2 wih rae λ 1, 2 and from service process 3 wih rae λ 1, 3. I mus be poined ou ha all raes depend on a special ime period (, ) λ 0,1 λ 1, λ 1,2 2 Figure 3-7: Scenario for disribued services The nework creaed by disribued services can be analyzed wih queuing neworks [ALVS], [ICPE], [MLR], [PCCS]. Thus we can generally define he following parameers for disribued services: λ (, ) : Reques rae o service process n from an exernal clien 0, n λ (, ) : Reques rae from service process n o service process m n, m µ (, ) : Capaciy of a service process n n 1 : Mean ime o process one job a service process n µ n (, ) ρ (, ) = n λm, n (, ) : Uilizaion of service process n µ (, ) m n

19 3.6 Summary 19 Addiionally, i mus be noed ha requess o remoe services ake ime and generae nework load. This ime resuls from he summaed ime for communicaion and he ime waiing for he resul. Thus we can addiionally define he following parameers: ω (, ) : Mean ime one reques akes from service process n o service process m n, m η (, ) : Mean nework load in KB caused by one reques from service process n n, m o service process m 3.6 Summary We use a kind of queuing neworks for he analysis of disribued service environmens. Wih he queuing neworks we have a model o describe he behavior of disribued services wih sochasic parameers. Queuing neworks do no conain any parameers of communicaion expanse. Tha is why we added he parameers ω (, ) and η (, ). How all named n, m parameers of his model can be measured is described in chaper 3.7. n, m 3.7 Geing Characerisic Parameers Measuremens In his secion he measuremens are defined, which can be derived from real services o evaluae he service parameers [MLR]: : Period of ime he measuremen runs r n ( ) : Number of requess o service process n in period u n ( ) : Time used for processing all requess a service process n in period his includes he waiing ime for oher service processes ( ) w n, m n, ( ) : Number of requess from service process n o service process m in r m period n, ( ) : Time service process n wais for service process m in period w m

20 20 3 Modeling Services ) (, n m n : Summaed nework load produced by requess from service process n o service process m in period Evaluaing Service Parameers For evaluaing characerisic service parameers, he following formulas can be used: : Time when measuremen period ends r n n = ) ( ), ( λ ) ( ) ( ), ( 1 r u n n n = µ r m n m n = ) ( ), (,, λ ) ( ) ( ), (,,, r w m n m n m n = ω ) ( ) ( ), (,,, r n m n m n m n = η Geing Measuremens In order o ge he measuremens we need a kind of sensor ha collecs he daa. This sensor could be embedded ino he service process or in he environmen of he service process. In any even, he daa he sensor collecs are he same. Le us review he behavior of a service (Figure 3-6): The service is waiing for jobs, processes jobs and sends jobs o oher services. The sensor could ake noe of every sae ransiion and couns he received and sen byes.

21 3.8 Sensors 21 Waiing for jobs Complee (Send resuls) Receive job Noed by sensor Receive resuls Processing Job Reques remoe job Sensor Waiing for remoe job Figure 3-8: evens logged by he sensor For jobs he service receives by iself, he sensor does no have o coun he received and sen byes, because he sensor of he service, which sends he job, will do ha already Measuremen Failure A sensor is an aciviy, hus i needs resources like processor ime or nework capaciy for communicaing wih he daabase. So he sensor falsifies he measuremens, e.g. he processing ime of a reques or somehing else. We assume ha his influence is very sligh, hus we will no include i in our consideraions. The oher kind of measuremen failures is ha some requess are sill in process when a measuremen period is already finished. Thus here will be a failure in he processing ime measures. This influence is also very lowly, because he measuremen period is usually much longer han a reques processing ime. Therefore, hose influences will no be apar of our consideraions, eiher. 3.8 Sensors Locaion The locaion of he sensor may vary, i can be: - Inegraed in he service process - Anoher process on he same server - Anoher process on a server nex o he service process

22 22 3 Modeling Services The firs locaion, inegraed in he service process, is very suiable, because you direc have access o all informaion you will need. You can do his by changing he source code of he service process or by changing libraries used by he service. If he locaion is anoher process hosed by he same server, i mus be a process ha has access o he process conrol in order o ge needed informaion. Tha means he process needs sysem privileges provided he hos operaing sysem suppors process privileges. Alernaively, he sensor could read log-files from he service process o ge he informaion. For oher processes on a differen server he only way o ge he informaion i needs is o ap he communicaion beween service processes from he communicaion media. This creaes many problems in idenifying service processes if here are more han one hosed by he server. Bu you do no need o change any source code and you can have measures wihou influence of an inernal sensor (see 3.7.4) Aciviy The sensor ges he informaion of he ransiion evens. This includes he ime of he ransiion and he new sae of he service. The sensor ges also informaion abou he expense of communicaion. The informaion sequence will be: Sae<Waiing for jobs> Even<Incoming job> Even<Job complee> Sae<processing job> Even<Remoe job> Even<Remoe job complee> Sae<Waiing for compleion> Even<Receive/Send n byes> Figure 3-9: Informaion sequence of he sensors The colleced informaion could be compleely sored or summarized. By soring every single even he sorage space of he sensor will overflow quickly provided he even rae is very high. So i is absoluely necessary ha he informaion mus be summarized. This can be easily

23 3.9 Daabase Sorage 23 realized by couning every even ype using a separae variable. The number of remoe job evens mus be separaed for each remoe service, which is used. Now we have all needed measuremens: = Time since he couning variables were zeroed r n ( ) = Number of Even<Incoming job> u n ( ) = Summaed ime beween Even<Incoming job> and Even<Job complee> r m n, ( ) = Number of Evens<Remoe job> by using service m w m n, ( ) = Summaed ime beween Even<Remoe job> and Even<Remoe job complee> by using service m n m n, ( ) = Number of byes ransmied o and from service m The measured daa should be sored in he daabase. This can be realized by insering all colleced values ino he daabase afer a ime period. Afer ha, all variables will be zeroed for he nex period. Every sensor is direcly conneced o he daabase and works independenly from all oher sensors. So we do no need a cenral insance for daabase access. This disribuion of sensors has an imporan disadvanage: Every measuremen value depends on a poin of ime. Bu he ime in such a sysem may differ from uni o uni. So here is a need for synchronizaion. Time synchronizaion is a known problem in disribued sysems and here are some possible soluions like Crisian s Algorihm or he Berkeley-Algorihm hey are described in [MBS]. 3.9 Daabase Sorage The daabase is able o sore srucures and also measuremen values. So we can sore he srucure of he disribued service environmen wih all measured daa a once. To sore he srucure of he service environmen you mus know heir componens. I consiss of differen servers wih a link for communicaion and every server is a hos for muliple services. Firsly, we sar wih idenifying he whole environmen by a folder in he daabase. This should be he opfolder. The nex sep is o presen every server by a folder wih he environmen-folder as

24 24 3 Modeling Services faher. The same procedure needs o be done wih all services. The resul of hese seps may be as shown in Figure Bu here are also oher hierarchies possible, e.g. which conain subnes or he like Measuremen +Server1 +Service1 +Server2 +Service2 +Server3 +Service3 Figure 3-10: Possible daabase srucure Now we can inegrae he measuremen value ables. There are wo measuremens ha only belong o he service iself and should be direcly sored in he service folder: r n ( ) and u n ( ). The oher values are relaed o oher (remoe) services and should be associaed wih hem. The resuling able srucure is shown in Figure Measuremen +Server1 +Service1 +reques +process +Remoe +Service2 +reques +wai +nework +Service3 +reques +wai +nework +Server2 +Service2 +reques +process +Server3 +Service3 +reques +process Figure 3-11: Possible represenaion of he hree-server sysem 3.10 XML Represenaion The XML forma should be used for exernal represenaion (see 1.2). I should be possible o exrac he curren sae and also a sae race. There are differen XML srucures possible. You can describe all componens separaely and han describe all connecion wih a lis of links. One possible srucure is shown in Figure 3-12 (noe: I is he srucure scenario picured in Figure 3-11). The measuremen daa can be sored ino he ags of services or links.

25 3.10 XML Represenaion 25 <Server1> <Service1 /> </Server1> <Server2> <Service2 /> </Server2> <Server3> <Service3 /> </Server3> <Links> <Link from= Service1 o= Service2 /> <Link from= Service1 o= Service3 /> </Links> Figure 3-12: XML represenaion 1 Anoher possibiliy is o use he able srucure of he daabase for soring he informaion ino an XML-file. The scenario shown in Figure 3-11 may look like he following: <Server1> <Service1> <Remoe> <Service2 /> <Service3 /> </Remoe> </Service1> </Server1> <Server2> <Service2 /> </Server2> <Server3> <Service3 /> </Server3> Figure 3-13: XML represenaion 2 Of course here are more possibiliies bu he second represenaion is used in his work because i reflecs he used daabase srucure and his is useful when searching for paricular measuremens or he like Curren Sae The curren sae depends on he measuremen period (, ), hus here is ime informaion needed in he XML represenaion. This could be a simple ag, which conains he poin of ime, when he period ends and he duraion of he period in seconds. If we use global ime informaion we do no need o sore he ime wih any value. Tha way sorage space for he XML-file can be reduced. The nex sep is o sore he measuremens in he XML-file. This can

26 26 3 Modeling Services be realized by using he able srucure described in chaper Thus he resuling srucure will be: <Time value= :23:20 duraion= 300 /> <Server1> <Service1> <reques> </reques> <process> </process> <Remoe> <Service2> <reques> </reques> <process> </process> </Service2> </Remoe> </Service1> </Server1> Figure 3-14: Curren sae XML represenaion The values of he measuremens can be sored ino ag <Value>. The resuling XML-file will have he following srucure: <Time value= :23:20 duraion= 300 /> <Server1> <Service1> <reques> <Value>12</Value> </reques> <process> <Value>0.412</Value> </process> <Remoe> <Service2> <reques> <Value>3</Value> </reques> <process> <Value>1.04</Value> </process> </Service2> </Remoe> </Service1> </Server1> Figure 3-15: Curren sae

27 3.10 XML Represenaion Trace The srucure of curren sae represenaion can be used for he race represenaion. The difference is ha here are more values of measuremen and he duraion propery is no needed any more. A simple way o realize his is o use a sequence of <Time> -ags by giving hem a sequenial number. The same should be done wih he <Value> -ag. Thus we have global ime informaion abou he race and all values in one XML-file. <Time number= 1 value= :23:20 /> <Time number= 2 value= :23:25 /> <Time number= 3 value= :23:30 /> <Server1> <Service1> <reques> <Value number= 1 >12</Value> <Value number= 2 >2</Value> <Value number= 3 >4</Value> </reques> </Service1> </Server1> Figure 3-16: Trace represenaion

28

29 29 4 Disribued Media Conen 4.1 Overview Media-on-demand has become popular, especially video-on-demand bu also music-on-demand. There are differen sysem srucures possible, bu here we use he following: A media-ondemand sysem has hree componens: Cliens (Cusomer), a nework and media archive servers. Differen media archive server will be disribued worldwide o provide cliens wih media conen. Media archive servers are classified o conen provider and media cener. Media cener are minor media archives, which are placed in each housing area. Cliens will send all requess direcly o hese media ceners and are direcly conneced o hem. If he conen a clien asks for is no sored on he media cener, he media cener will ask a neighboring media cener or a conen provider. They funcion as a local cache for media conen. Conen providers are cenralized servers, which disribue he media conen o he media ceners. The conen on providers may vary beween differen regions. Conen provider Nework Media cener Cusomer Figure 4-1: Disribued media conen scenario 4.2 Sysem Model To describe he scenario here are wo caegories of parameers: Sysem characerisics and cusomer behavior [LTRA], [TFIC], [IMA] Sysem Characerisics Characerisic parameers, which describe he sysem capaciy, are for example: - Number of simulaneous media sreams a media server can suppor

30 30 4 Disribued Media Conen - Sorage capaciy of a media server - Available media conen - Sysem srucure - Nework bandwidh of he connecions beween separae media servers - Number of cusomers conneced o a media server - Policy of geing media conen - Processing ime of a reques Cusomer Behavior For cusomer we can define he following parameers in order o describe heir behavior: - The reques arrival paern or workload a he server - Media conen selecion paerns Sysem Srucure The disribued media conen sysem is srucured hierarchically. The upper hierarchy consiss of he conen provider, he nex hierarchy consiss of he media cener and he boom hierarchy consiss of he cusomers. Cusomers are conneced o one media cener and media ceners are conneced o several conen providers and also o media ceners in heir neighborhood. The sysem srucure is shown in Figure 4-2. We can assume ha abou 100 o 1000 cusomers are conneced o a media cener and basically every media cener o every conen provider. Media ceners are also conneced o media ceners in heir neighborhood o compensae failures on single media ceners by using he neighboring media cener s services.

31 4.2 Sysem Model 31 Conen provider Media cener Cusomer Figure 4-2: Sysem srucure Typical Parameers of Media Conens If we assume ha movies are compressed wih he MPEG-1 echnology [MPG] a movie ransmission will have a rae of 1.5 Mbps [OVD]. Wih a ypical lengh of abou 105 o 135 minues a movie needs beween 1.1 GB and 1.4 GB of sorage capaciy. Music daa wihou compression has a rae of 1.4 Mbps (44.1 khz, 2 channels wih 16 Bi), by using compression like MP3 or similar here are raes of 128 kbps possible. Thus a whole CD of audio daa needs approximaely 60 MB of sorage capaciy Typical Cusomer Behavior Cusomers have a ypical reques paern by using media conen: There is a prime-ime during he day, which is characerized by high workload on he server because several cusomers wan o see a movie. The res of he day cusomers may only lisen o music or he workload is low because people work or sleep. This prime ime depends on he region of counry (e.g. Germany: 9:00 p.m. or Spain: 10:30 p.m. [TSOV]). Finally we can classify hree phases of cusomer behavior: Sleeping ime, prime ime and he remaining ime. A he prime ime everybody wans o see a movie, and so here are high raes of movie requess a he media ceners. The sleeping ime is a period when nobody wans o see a movie or lisen o any music. The reques rae on media ceners is very low a his ime. A he remaining ime people only lisen o music and someimes wach a movie. The simplified behavior of a cusomer is shown in Figure 4-3.

32 32 4 Disribued Media Conen Requess rae Music Movies Remaining ime Prime ime Day ime Figure 4-3: Simplified cusomer behavior Cusomers do no choose he conen compleely randomly. There are some movies or music conens cusomers ofen wan o see or lisen o i. These are curren conens like new movies or new songs. 4.3 Service Models The goal of monioring a disribued media conen environmen and is service model is o ge informaion abou he uilizaion of special media server, he relaions beween differen media ceners and he used nework capaciies. The model described in chaper 3 delivers all hese informaion, hus we can compleely use his model for he monioring of disribued media conen environmens. Services are he paricular media server (media cener and conen provider) and cusomers are creaing requess o media servers Sensor The sensors are measuring he parameers of disribued services as described in Excepions are he parameer u n ( ) and w n, m ( ). Normally hey would represen he ime in which a service complees is work; here his would nearly (processing delays) be he movie lengh or he music duraion because he service is complee if he sream is ransmied. More imporan for his scenario is o measure he processing ime, which is needed before a sream begins. So u n ( ) is he summaed ime beween he incoming reques and he sar of ransmission. Wih w n, m ( ) i is similar. Afer he measuring period he sensor sends he parameer o he daabase. The daabase srucure is described in The adjused sensor noaion is shown in Figure 4-4. Basically, i is he same as in Figure 3-8, bu for beer undersanding he process saes are renamed.