Techno-economische studie voor het uitrollen van interactieve multimedia Thin Client diensten

Techno-economische studie voor het uitrollen van interactieve multimedia Thin Client diensten Maarten De Groote

Promotoren: prof. dr. Mario Pickavet, prof. dr. ir. Bart Dhoedt Begeleiders: Pieter Simoens, Jan Van Ooteghem Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

Voorwoord

Een scriptie kan nooit het werk zijn van één persoon. Daarom zou ik graag allen, die een bijdrage hebben geleverd bij het tot stand komen van dit werk, bedanken. Vooreerst gaat mijn oprechte dank naar mijn begeleiders. Lien Deboosere, Pieter Simoens en Jan Van Ooteghem hebben mij met raad en daad bijgestaan in de vervolmaking van deze scriptie. Tevens wens ik ook mijn promotoren te bedanken voor hun vertrouwen en de geboden kans. Vervolgens wil ik de volledige vakgroep IBCN danken voor o.a. het ter beschikking stellen van een server waarop gewerkt kon worden. Mensen voor wie geen dank te veel kan zijn, zijn mijn ouders. Zij hebben mij in de loop der jaren alle kansen gegeven die ik maar wou en mij ten volle gesteund in mijn keuzes. Zij hebben mij de mogelijkheden gegeven om te staan waar ik nu sta, om mij te verdiepen in mijn interesses, mij te ontplooien, en uiteraard ook om enkele jaren goed te kunnen genieten in Gent. Verder wil ik nog een aantal mensen bedanken die hier niet bij naam vermeld zijn maar toch op een of andere manier voor mij een uitlaatklep geweest zijn en mij gesteund hebben. Bedankt.

Maarten De Groote, juni 2008

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Maarten De Groote, juni 2008

Techno-economische studie voor het uitrollen van interactieve multimedia Thin Client diensten door Maarten De Groote Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen Academiejaar 2007–2008 Promotoren: Prof. Dr. Ir. M. Pickavet, Prof. Dr. Ir. B. Dhoedt Scriptiebegeleiders: Ir. P. Simoens, Lic. J. Van Ooteghem, Ir. L. Deboosere Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting Het doel van de scriptie is een grondige techno-economische studie uit te voeren van thin client systemen. In eerste instantie zal er onderzocht worden wat de technische vereisten zijn: welke bandbreedte is vereist, hoe gebeurt de server dimensionering, maximale delay, enz. Een case wordt uitgewerkt waarbij we een netwerk beschouwen waarin servers worden geplaatst. Vertrekkende van het scenario model, zal het aantal servers, de plaatsing ervan, alsook de vereiste bandbreedte worden in kaart gebracht. Een economische analyse zal worden opgesteld waarbij de kost per gebruiker zal berekend worden, en dit voor een meerjaren analyse.

Trefwoorden Thin Client - Techno-economisch - haalbaarheidsstudie

Techno-economic study on the roll out of interactive multimedia Thin Client services Supervisor(s): Mario Pickavet, Bart Dhoedt, Pieter Simoens, Jan Van Ooteghem, Lien Deboosere Abstract—This article explains a techno-economic study on the roll out of interactive multimedia thin client services. Starting with a scenario model we dimension the network followed by an economic analysis. It is shown that placing servers deeper in the network is the most viable solution in terms of economic savings, but not in terms of user Quality of Experience. Keywords—Thin client, techno-economic, feasibility study

I. I NTRODUCTION

I

N thin client computing , applications are executed on backend centralized application servers, instead of locally on the end user’s device. Every client event (key strokes, mouse movements) is transmitted over the network towards an application server, which processes the commands, renders the appropriate graphical output and sends the images back to the client. The client only decodes the received stream and can thus be made as ‘thin’ as possible. To make a good economic study it’s important to have a good model to dimension the network. For this reason we’ve built a simulator to run several different scenarios. After a simulation, we know the needed server capacity and link capacity. It is also possible to limit several server farms to investigate the influences of the established limitations. With this output and the cost model we can calculate the cumulative cost of the service and can compute the cost per user. In this abstract, we will first describe the technical and economic model of the simulations. Then we will discuss the simulator with its functionalities, followed by the results of the most important simulations. Finally we draw some conclusions. II. T ECHNICAL AND ECONOMIC MODEL Here we present the used technical parameters, scenario model, cost parameters and the economic model. This model is used in every scenario. A. Technological parameters The network topology is based on the Belgian model. It contains the typical topology of a DSL access network. The highest layer is the backbone network with the BRAS nodes, then there is a layer with the LEX nodes and finally the lowest layer with the DSLAM nodes. To dimension the network correctly, we defined a couple of application parameters for the four types of applications. The typical applications are office, browsing, video streaming and gaming. The most important parameters of these applications are the bandwidth, the maximum allowable latency and the memory footprint per application.

B. Scenario model We defined two types of users: the business user and the residential user. They both have their typical profile. The adoption is calculated with a Gompertz curve for every rate of business users [2]. The two types have their own arriving distribution, average online time, distribution over the network and user profile. C. Cost parameters We quantified a couple of capital expenditures (CapEx) and operating expenditures (OpEx) to calculate the cumulative cost of the system. The most important costs are the server costs, the network costs and the license costs. D. Economic model We defined three cost drivers to divide the total cost between the two types of users. First there is the amount of users that determines the cost. Second you have the network capacity. And finally you have the server capacity which determines the cost. For the last two we calculate two distribution keys to estimate the cost for each type of user. These keys are based on the average network bandwidth and memory usage during peak load. We also perform a net present value (NPV) analysis for each scenario. To calculate the revenues we estimate a subscription fee of 30 e a month for a business user and 35 e a month for a residential user. III. T HE SIMULATOR A. General Information It is the goal of the simulator to monitor the dimensioning of the network in a couple of scenarios. The most important outputs are the server farm capacities, the link capacities and the number of unserved users due to insufficient server capacity. On each network node we can install a server farm where we can install some application servers. The TRS (Telecom Research Software) library has been used to design the network topology [3]. When a user comes online, a server will be selected through a server selection algorithm. B. Functionalities In [1], an algorithm is presented to determine the suboptimal server farm locations. This is used to locate the suboptimal server farm locations in function of the maximum latency of the applications. To select a server farm, there are three different server selection algorithms: • Standard algorithm: Search a server from the highest layer in the network to the lowest in the same branch.

Advanced algorithm: First search a server from the highest layer in the network to the lowest in the same branch and then search a free server in an other branch on the lowest level. • More advanced algorithm: First search a server in the highest layers and then search a server in the lowest with the smallest workload.

•

IV. S IMULATIONS We distinguish four different scenarios: the basic scenario, a scenario with limitation of the server capacity, a scenario with different selection algorithms and a scenario with changes in the user profile.

D. Without gaming After investigating the best strategy to place servers, we explore the influences of several profile changes. The most interesting is the comparison to roll out the service with or without gaming. You can see the difference in NPV values in figure 2. All values are already positive in the fourth year. The amount of the revenues are the same so there is a reduction in the total costs.

A. Basic scenario The basic scenario uses the standard selection algorithm. This scenario is used to compare to the other ones. It resulted in a lot of server capacity and network capacity. In the first years the CapEx are bigger than the OpEx, but that changed to the opposite situation in the last years. B. Limitation of the server capacity Here we investigate the omission of the server farms at a certain layer in the network. It was more efficient to leave the BRAS nodes empty, due to the high network costs. If all servers are placed on the DSLAM layer, it leads to a high investment cost and a low capacity load of the servers. You need a lot of extra capacity to ensure the Quality of Service because of the uncertain distribution of the users over the network. C. Different selection algorithms If servers are needed on the DSLAM layer, the best way is to place them on the DSLAM and the LEX layer, the servers on the LEX layer are needed to centralize better the capacity. In this scenario we try to use the server capacity more efficiently by using other selection algorithms. If there is just enough capacity in the network, all users can be served if an efficient selection algorithm is used. The performances of the more advanced algorithm were the best. We also made an optimization of this algorithm to reduce the extra network costs. The NPV analysis of this algorithm is shown in figure 1. The NPV value of 80% is doubled in comparison with the basic scenario. There is a clear difference between both.

Fig. 2. NPV analysis for the situation without 3D-gaming.

In table I the cost per user is calculated for different scenarios. The costs are given per user and per year. In optimized (1) the extra costs for the gaming application are divided between all users. In optimized (2) the extra costs are assigned to the residential users. There is a big difference between both situations. TABLE I C OST DIVISION BETWEEN BUSINESS AND RESIDENTIAL USER .

Ratio 80% business users Whithout gaming Optimized with gaming (1) Optimized with gaming (2)

Cost/Bus. [e] 255 277 255

Cost/Res. [e] 255 277 435

V. C ONCLUSIONS It’s a feasible situation to roll out a thin client service, although maybe not from the beginning with all services. A good market investigation is also an added value to be sure that the market potential is as good as we thought. There is an economic trade-off between the placing of servers deeper in the network and the extra network costs. R EFERENCES

Fig. 1. NPV analysis for the situation with the optimized server selection algorithm.

[1] L. Deboosere, P. Simoens, D. De Winter, F. De Turck, B. Dhoedt, P. Demeester, “Dimensioning a Wide-Area Thin Client Computing Network supporting Mobile Users,” the Proceedings of the International Conference on Networking and Services (ICNS), July 2006. [2] J. V. Gregg, C. H. Hossel, , J. T. Richardson, “Mathematical trend curves: An aid to forecasting,” Edinburgh: Oliver and Boyd, 1964. [3] K. Casier, S. Verbrugghe, D. Colle, M. Pickavet and P. Demeester, “Using Aspect-Oriented Programming for Event-Handling in a Telecom Research Software Library,” In Poster presentation at ICSR-8, the 8th International Conference on Software Reuse, Spain, 2004.

INHOUDSOPGAVE

vii

Inhoudsopgave Extended abstract Gebruikte afkortingen

v xi

1 Inleiding

1

2 Thin Client architectuur

3

2.1

Definitie van Thin Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Client/server architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3

De werking van een Thin Client/Server systeem . . . . . . . . . . . . . . . .

5

2.4

Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.1

Beheersbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.2

Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.3

Beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.4

Besparingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.5

Beperkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.6

Mogelijke verschijningsvormen . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.6.1

Server-based computing . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.6.2

Virtual Desktop Infrastructure . . . . . . . . . . . . . . . . . . . . . 10

2.7

2.8

Thin Client protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7.1

Independent Computing Architecture (ICA) . . . . . . . . . . . . . . 11

2.7.2

Remote Desktop Protocol (RDP) . . . . . . . . . . . . . . . . . . . . 11

2.7.3

Virtual Network Computing (VNC) . . . . . . . . . . . . . . . . . . 12

2.7.4

Hybrid Thin-Client protocol . . . . . . . . . . . . . . . . . . . . . . . 13

Heuristieken voor serverplaatsing . . . . . . . . . . . . . . . . . . . . . . . . 13

INHOUDSOPGAVE

viii

2.8.1

Centraal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8.2

Decentraal

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 De simulator

15

3.1

Architectuur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2

Functionaliteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1

Server farm locatie bepaling . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2

Server selectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3

Type gebeurtenissen . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.4

Chronologie van de gebeurtenissen . . . . . . . . . . . . . . . . . . . 21

3.2.5

Output van een simulatie . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.6

Verwerking gegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Technisch en economisch model 4.1

4.2

24

Technologische parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1

Netwerktopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2

Applicatie parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Scenario model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1

Populatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2

Adoptie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.3

Aankomstdistributie van de gebruikers in de tijd . . . . . . . . . . . 32

4.2.4

Online tijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.5

Verdeling van de gebruikers over het netwerk . . . . . . . . . . . . . 33

4.2.6

Gebruikersprofiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3

Kost parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4

Economisch model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5

Variabele parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5.1

Servercapaciteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.2

Server selectie algoritme . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.3

Gebruikersprofiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Simulaties 5.1

42

Basisscenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

INHOUDSOPGAVE

5.2

ix

Scenario met beperking van de servercapaciteit . . . . . . . . . . . . . . . . 46 5.2.1

Geen servercapaciteit op LEX niveau . . . . . . . . . . . . . . . . . . 46

5.2.2

Geen servercapaciteit op BRAS niveau . . . . . . . . . . . . . . . . . 49

5.2.3

Geen servercapaciteit op BRAS en LEX niveau . . . . . . . . . . . . 52

5.2.4

Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.5 5.3

5.4

5.5

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Intelligentere server selectie algoritmes . . . . . . . . . . . . . . . . . . . . . 59 5.3.1

Gevorderd algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3.2

Geavanceerd algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.3

Geoptimaliseerd algoritme . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.4

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Wijzigen van het gebruikersprofiel . . . . . . . . . . . . . . . . . . . . . . . 67 5.4.1

Wijzigen van het Business profiel . . . . . . . . . . . . . . . . . . . . 68

5.4.2

Wijzigen online tijd residentiële gebruiker . . . . . . . . . . . . . . . 71

5.4.3

Weglaten van de spel applicatie . . . . . . . . . . . . . . . . . . . . . 73

5.4.4

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 Besluit en toekomstperspectieven

80

A Adoptie waarden

83

B De totale servercapaciteit

85

C Kost per gebruiker

89

D Net Present Value

95

D.1 Basisscenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 D.2 Scenario met beperking van de servercapaciteit . . . . . . . . . . . . . . . . 96 D.2.1 Geen servercapaciteit op LEX niveau . . . . . . . . . . . . . . . . . . 96 D.2.2 Geen servercapaciteit op BRAS niveau . . . . . . . . . . . . . . . . . 96 D.2.3 Geen servercapaciteit op BRAS en LEX niveau . . . . . . . . . . . . 97

INHOUDSOPGAVE

x

D.2.4 Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 D.3 Intelligentere server selectie algoritmes . . . . . . . . . . . . . . . . . . . . . 98 D.3.1 Gevorderd algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 D.3.2 Geavanceerd algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . 99 D.3.3 Geoptimaliseerd algoritme . . . . . . . . . . . . . . . . . . . . . . . . 100 D.4 Wijzigen van het gebruikersprofiel . . . . . . . . . . . . . . . . . . . . . . . 100 D.4.1 Wijzigen van het Business profiel . . . . . . . . . . . . . . . . . . . . 100 D.4.2 Wijzigen online tijd residentiële gebruiker . . . . . . . . . . . . . . . 101 D.4.3 Weglaten van de spel applicatie . . . . . . . . . . . . . . . . . . . . . 101 E Inhoud van de DVD

102

Bibliografie

103

Lijst van figuren

106

Lijst van tabellen

109

GEBRUIKTE AFKORTINGEN

xi

Gebruikte afkortingen BRAS

Broadband Remote Access Server

CapEx

Capital Expenditures

DSL

Digital Subscriber Line

DSLAM

DSL Access Multiplexer

FTE

Full Time Equivalent

FTP

File Transfer Protocol

ICA

Independent Computing Architecture

LEX

Local Exchange

Mbps

Mega bit per seconde

NPV

Net Present Value

OpEx

Operational Expenditures

PDA

Personal Digital Assistant

RFB

Remote Frame Buffer

RAM

Random Access Memory

TCO

Total Cost of Ownership

VNC

Virtual Network Computing

VoIP

Voice over Internet Protocol

WAN

Wide Area Network

WWW

World Wide Web

INLEIDING

1

Hoofdstuk 1

Inleiding Thin Clients zijn al jaren een hot topic. Een heel gamma aan toestellen kan als thin client gebruikt worden zoals desktop computers, laptops, PDA’s, smartphones. De meerderheid wordt gekenmerkt door hun minimale rekenkracht. Alle applicaties en data bevinden zich op servers in het netwerk. Dit leidt tot een verhoogd gebruiksgemak, aangezien de server administrators instaan voor de installatie, configuratie en het onderhoud van de applicaties. Een thin client kan steeds gebruik maken van de nieuwste applicaties, ongeacht hun vereisten qua beschikbare schijfruimte, processorsnelheid en geheugen. De continue (draadloze) verbinding, de vereiste bandbreedte en de beperkte delay stellen hoge eisen aan het netwerk. Willen we thin clients aan het grote publiek aanbieden, dan moet het netwerk goed gedimensioneerd worden. Verder moet er voldoende rekencapaciteit in het netwerk aanwezig zijn om alle gebruikers zo efficiënt mogelijk te bedienen. Een correcte dimensionering van de applicatieservers is dus van groot belang. Het doel van de scriptie is een grondige techno-economische studie uit te voeren van thin client systemen. In eerste instantie zal er onderzocht worden wat de technische vereisten zijn: welke bandbreedte is vereist, hoe gebeurt de server dimensionering, maximale delay, enz. Een case wordt uitgewerkt waarbij we een netwerk beschouwen waarin servers worden geplaatst. Vertrekkende van het scenario model, zal het aantal servers, de plaatsing ervan, alsook de vereiste bandbreedte worden in kaart gebracht. Een economische analyse zal worden opgesteld waarbij de kost per gebruiker zal berekend worden, en dit voor een meerjaren analyse.

INLEIDING

2

In deze scriptie wordt een techno-economische studie uitgevoerd. Hiervoor worden eerst de technische vereisten in kaart gebracht. Deze vereisten zijn nodig om het thin client netwerk correct te dimensioneren. Ook wordt een economisch kostenmodel opgesteld waarmee de cumulatieve kost van de aangeboden dienst kan berekend worden. Vervolgens is er een applicatie ontwikkeld die in staat is om een basisscenario te simuleren. Na het uitvoeren van deze simulaties verkrijgen we de dimensionering van het netwerk. Met behulp van deze output en het economisch kostenmodel kan een kosten/opbrengsten analyse uitgevoerd worden. Vertrekkende van het basisscenario wordt via een strategie de suboptimale oplossing gezocht. De invloeden van het weglaten van servercapaciteit op een niveau, het server selcetie algoritme, het wijzigen van het gebruikersprofiel worden onderzocht. Tevens wordt er onderzocht wat de invloed is van de wijziging van een aantal parameters op de cumulatieve kost. Bij aanvang van deze scriptie werd er een literatuur- en architectuurstudie gedaan over de mogelijke technologieën. De belangrijkste bemerkingen zijn beschreven in hoofdstuk 2. De architectuur en de belangrijkste functionaliteiten van de simulator zijn na te lezen in hoofdstuk 3. In hoofdstuk 4 wordt het volledige model toegelicht. De vaste input parameters, van technische en economische aard, van het model worden hier gedefinieerd. Vervolgens komt ook het scenario model en het economisch model aan bod. Het hoofdstuk wordt afgesloten met een lijst van de gevarieerde parameters. In hoofdstuk 5 zijn een aantal scenario’s uitgewerkt waarbij de invloed van het wijzigen van een aantal parameters onderzocht worden voor het uitrollen van een thin client dienst. Hier worden de belangrijkste output gegevens met de daarbij horende conclusies gegeven. Tot slot eindigen we in hoofdstuk 6 met de algemene conclusies en de toekomstperspectieven.

THIN CLIENT ARCHITECTUUR

3

Hoofdstuk 2

Thin Client architectuur 2.1

Definitie van Thin Clients

Veel hedendaagse netwerkproducten krijgen de naam “Thin Client”. Dit kan tot verwarring leiden omdat zowel hardware als software de term “Thin Client” krijgen. Enkele voorbeelden van hardware zijn NetPC’s [1], Wyse [2] en JackPC [3]. Men kan de term ook gebruiken voor software producten, dit is een programma die een thin client protocol implementeert bijvoorbeeld: Cult [4], BeTwin [5] en SoThin [6]. In de literatuur verwijst men met de term “Thin Client” vooral naar het thin client toestel. Binnen de thin client markt speelt de typische hardware slechts een beperkte rol. In veel situaties gebruikt men zelfs standaard hardware die men configureert als een thin client door middel van software. Een definitie van “Thin Client” is: “A server-centric computing model in which the application software, data, and CPU power resides on a network server rather than on the client computer.’ ’ [7] Deze definitie geeft de essentie van thin client computing weer. Dit model maakt gebruik van een client/server architectuur waarbij de applicatie, de data en de rekenkracht zich aan de kant van de server bevinden. Dit principe is weergegeven in figuur 2.1.

2.2 Client/server architectuur

4

Figuur 2.1: Thin clients en servers

2.2

Client/server architectuur

Om thin client computing beter te kunnen situeren volgt er eerst een korte uiteenzetting over client/server architectuur. Wanneer de ene partij een dienst vraagt aan de andere, dan is de eerste partij de client en de tweede de server. Het is zelfs mogelijk dat de server een dienst vraagt aan een andere server, op dit ogenblik is de eerste server de client en de tweede de server. Om een betere kijk te krijgen op de mogelijke diensten die een server kan uitvoeren volgt eerst een bespreking van de traditionele architectuur van een applicatie. Een applicatie bestaat meestal uit volgende drie lagen: 1. Presentatielaag: Deze laag is verantwoordelijk voor de gebruikersinterface van de applicatie. 2. Applicatielaag: Deze laag coördineert de applicatie, voert logische bewerkingen uit en verplaatst data tussen de presentatielaag en de datalaag. 3. Datalaag: Deze laag krijgt de data van de applicatielaag en zendt die naar de database of ontvangt de data van de database en zendt het naar de applicatielaag. Elke laag kan uitgevoerd worden op: de server, de client of de beide. In figuur 2.2 is weergegeven welke modellen we kunnen onderscheiden. Thin clients maken vooral gebruik van distributed presentation(zoals bij ICA en RDP) of remote presentation (zoals bij browser gebaseerde technologieën), waar de data- en applicatielaag zich op de server bevindt. De presentatielaag kan zich volledig aan de client zijde situeren, zoals bij remote presentation, of aan beide zijden bevinden, zoals bij distributed presentation [8, 9]. In deze scriptie wordt gebruik gemaakt van distributed presentation wegens de beperkt applicatie ondersteuning bij remote presentation.

2.3 De werking van een Thin Client/Server systeem

5

Figuur 2.2: De verschillende client/server architecturen

2.3

De werking van een Thin Client/Server systeem

Om te zien hoe het systeem echt werkt kan best eerst de server zijde bekeken worden. Aan deze zijde worden alle applicaties en data uitgerold, beheerd en onderhouden. De applicatie wordt hier volledig uitgevoerd. De typische client/server architectuur die hier gebruikt wordt is het distributed presentation model. Dit betekent dat enkel scherm updates, muisklikken en toetsaanslagen over het netwerk reizen. Een schematische voorstelling is te vinden in figuur 2.3.

Figuur 2.3: Thin Client werking

2.4 Voordelen

2.4

6

Voordelen

De voordelen van een thin client architectuur t.o.v. een klassiek desktop model kunnen in vier categorieën ingedeeld worden: beheersbaarheid, schaalbaarheid, beveiliging en de kost van het systeem.

2.4.1

Beheersbaarheid

Het installeren en upgraden van software is aanzienlijk eenvoudiger in een thin client architectuur. Enkel de software op de server dient aangepast te worden en het is niet meer nodig om de software op elke computer te installeren. Om het volledige systeem te monitoren is het niet meer noodzakelijk om alle machines te bekijken maar enkel de centrale server. Het management van een thin client systeem kan dus veel efficiënter verlopen dan in een traditioneel desktop systeem [10].

2.4.2

Schaalbaarheid

In sterk groeiende of zeer dynamische bedrijven is schaalbaarheid van groot belang. Indien in een bepaalde afdeling van het bedrijf het aantal werknemers sterk toeneemt, is het operationeel maken van deze extra computers een grote taak voor het IT-personeel. Bij thin clients kan het toestel eenvoudig verbonden worden met het netwerk. Lokaal op de client is er geen extra software nodig. De volledige configuratie kan via de server gebeuren. De systeembronnen worden ook efficiënter beheerd. Als er te weinig capaciteit aanwezig is, dient enkel de server farm ge¨ upgraded worden. In het klassiek desktop model zou dit leiden tot een upgrade of een vervanging van alle systemen [10].

2.4.3

Beveiliging

Gezien de evolutie van het Internet speelt beveiliging een steeds grotere rol. In een thin client systeem zijn er veel minder punten waar beveiligingsproblemen kunnen ontstaan. Als het onmogelijk is om software op de thin client te installeren kan er ook geen kwaadaardige software ge¨ınstalleerd worden. De applicaties worden uitgevoerd op één centraal punt, zo dient alleen daar de nodige beveiliging toegebracht te worden. Als er veel met mobiele toestellen gewerkt wordt, is de kans groter dat het toestel verloren

2.5 Beperkingen

7

gaat. Verlies van vertrouwelijke informatie kan grote gevolgen hebben voor de gebruiker of de onderneming. Thin client systemen zijn hier een oplossing voor. In geval van diefstal of verlies van het toestel kan de data niet verloren gaan of in verkeerde handen komen. Alle data bevindt zich namelijk op de applicatieservers. De servers kunnen met behulp van allerhande alarmsystemen beveiligd worden [10].

2.4.4

Besparingen

Een thin client heeft minder hoge systeemvereisten dan een gewone PC waardoor de hardware vaak goedkoper is. De client heeft vaak minder componenten door het weglaten van een harde schijf, optisch leesstation, enz. Hierdoor is de client robuuster en minder gevoelig voor schade. Er is ook reeds aangehaald dat de client minder upgrades nodig heeft. De grootste kost in IT is het systeemonderhoud. In een thin client systeem kan ook hier bespaard worden. Dit komt omdat de configuratie van gebruikers en beveiliging op een centraal punt gebeuren. Hierdoor zijn er minder systemen om te onderhouden en moet het IT-personeel minder van locatie veranderen. Tegenwoordig wordt meer en meer rekening gehouden met het energieverbruik. Ook hier bieden thin clients een oplossing. Het vermogen van een thin client terminal ligt tussen de 10 en 50 Watt en voor een desktop computer tussen de 150 en 350 Watt. Indien de onderneming over veel toestellen beschikt, kan dit een flinke besparing opleveren [11]. De totale servercapaciteit zal verhoogd moeten worden waardoor een deel van de energiebesparingen teniet worden gedaan. Door de vermindering van de rekenkracht aan de client kan dit leiden tot een langere gebruiksduur van de batterij.

2.5

Beperkingen

Thin client systemen hebben echter ook een aantal beperkingen. De belangrijkste worden hier opgesomd. Indien de server faalt, kan de gebruiker bepaalde applicaties niet meer uitvoeren.

Dit probleem kan deels opgelost worden door redundante servers toe te voegen.

2.6 Mogelijke verschijningsvormen

8

Thin clients staan bekend voor hun beperkte multimedia capaciteiten. Omdat een

groot deel van de presentielaag uitgevoerd wordt op de server en de gebruikersinterface op periodieke momenten wordt doorgestuurd, is het niet evident om een hoge frame rate van beelden met een hoge kwaliteit te krijgen aan de clientzijde. Tegenwoordig wordt onderzoek gedaan om deze beperking te verhelpen. Om multimedia en gaming applicaties beter te ondersteunen is het gebruik van een hybrid thin-client protocol aangewezen. Het hybrid thin client protocol zal automatisch bepalen of de grafische output aan de hand van een klassiek thin client protocol of via desktopstreaming wordt doorgestuurd naar de client. Meer informatie over deze manier van werken kan gelezen worden in [12].

2.6

Mogelijke verschijningsvormen

In deze sectie worden een aantal belangrijke toepassingen binnen de thin client wereld besproken. In eerste instantie zal het principe van server-based computing uitgelegd worden. Enkele voorbeelden hiervan zijn: Citrix (Presentation Server of XenApp) en Microsoft Terminal Services. Vervolgens volgt een beschrijving van Virtual Desktop Infrastructure. Hierbij wordt het volledige besturingssysteem virtueel gemaakt en beschikbaar gesteld voor de client. Enkele voorbeelden hiervan zijn: VMware VDI en Citrix XenDesktop.

2.6.1

Server-based computing

Server-based computing bestaat uit een server en een client toestel. De server en de client zijn via een netwerk met elkaar verbonden. De server staat in voor het uitrollen, beheren, ondersteunen en uitvoeren van de volledige applicatie. Deze technologie gebruikt een multi user besturingssysteem zodat meerdere client sessies gelijktijdig ondersteund worden. Dit principe is te zien in figuur 2.4. Citrix was één van de pioniers op het vlak van server-based computing [13].


9

Figuur 2.4: Server-based computing [13]

Citrix Systems Citrix Systems is een Amerikaans bedrijf dat gespecialiseerd is in het ontwikkelen van software en diensten voor thin clients en remote access. De hoofdtaak bestaat uit het aanbieden van applicaties over een lokaal netwerk of het Internet. De software hiervoor nodig is XenApp. Het stelt de gebruiker in staat om gebruik te maken van applicaties die beschikbaar zijn vanaf centrale servers. De gebruiker kan met behulp van een client programma een verbinding opzetten met de server en gebruik maken van de aangeboden applicaties. XenApp is ontwikkeld op de Independent Computing Architecture (ICA). Dit is een protocol ontwikkeld door Citrix dat verder toegelicht wordt in paragraaf 2.7.1. Een typische Citrix configuratie is weergegeven in figuur 2.5 [14].

Figuur 2.5: Citrix configuratie [14]


2.6.2

10

Virtual Desktop Infrastructure

Virtual Desktop Infrastructure is een ge¨ıntegreerde oplossing voor desktop virtualisatie. Virtualisatie is een techniek voor het verbergen van fysieke karakteristieken van computerbronnen voor de manier waarop andere systemen, applicaties of eindgebruikers met deze bronnen communiceren [7]. Men komt tot een situatie waar er meerdere besturingssystemen tegelijkertijd op één computer draaien. De architectuur bestaat uit een server farm die alle virtuele desktops onderhoudt. De client kan dan inloggen via een manager server die dan toegang verleent tot de client zijn eigen desktop omgeving. VMware VDI VMware VDI maakt gebruik van VMware Infrastructure 3 op de server farm waar zich de virtuele desktops bevinden. Tussen client en data center bevindt zich een desktop management server, die de gebruiker verbindt met de gepaste virtuele desktop. De client kan een thin client, laptop, desktop computer of een PDA zijn, zie figuur 2.6. De client beschikt hier over zijn eigen virtuele besturingssysteem. Indien er hier een fout optreedt, heeft dit geen gevolg voor de andere gebruikers.

Figuur 2.6: Virtual Desktop Infrastructure [16]

2.7 Thin Client protocollen

11

Binnen het bedrijfsleven neemt de belangstelling voor virtualisatie steeds toe. Virtualisatie van servers heeft al de voordelen van virtualisatie aangetoond. Enkele voordelen zijn het samenvoegen van servers, optimalisatie van de infrastuctuur, hogere operationele flexibiliteit en verhoogde beschikbaarheid van applicaties. Deze trend heeft zich nog niet volledig doorgezet naar de desktop markt. Enkele typische voordelen zijn een verhoogde beveiliging, beter management en verminderde kost. Hewlett-Packard is een belangrijke leverancier van VDI. HP voorziet de hardware, de software en eventueel ook de nodige ondersteuning [16].

2.7

Thin Client protocollen

In deze paragraaf worden een aantal communicatieprotocollen beschreven die gebruikt worden in thin client systemen. De drie meest populaire zijn ICA, RDP en VNC. Tot slot volgt een beschrijving van een hybrid thin client protocol. Dit protocol is speciaal ontworpen om ook multimedia streaming en interactieve 3D applicaties te ondersteunen.

2.7.1

Independent Computing Architecture (ICA)

Het ICA protocol zendt enkel toetsaanslagen, muisklikken, scherm updates en geluid over het netwerk. Op de server wordt de volledige applicatie uigevoerd en wordt de grafische output van een applicatie opgevangen, geëncodeerd en vervolgens via een thin client protocol doorgestuurd naar de client. Dit principe is reeds uitgelegd in paragraaf 2.3. Volgens Citrix is de gemiddelde bandbreedte van het ICA protocol 20 kbps [14]. Bij kantoortoepassingen kan dit pieken tot meer dan 300 kbps [17]. Indien er gebruik gemaakt wordt van multimedia gegevens kan dit zelfs oplopen tot boven de 3000 kbps [17]. Aan de server zijde is een extra applicatie laag nodig tussen het besturingssysteem en het ICA protocol. Dit pakket is al een aantal keren van naam veranderd, namelijk van MetaFrame naar Presentation Server en vervolgens naar XenServer [14].

2.7.2

Remote Desktop Protocol (RDP)

RDP is ontwikkeld door Microsoft om de client in staat te stellen om te communiceren met de Terminal Server van Microsoft. Het protocol is gebaseerd op het T.120 protocol van

2.7 Thin Client protocollen

12

International Telecommunications Union (ITU). RDP is een meerdere kanalen protocol en ondersteunt virtuele kanalen waardoor het nieuwe data types kan ondersteunen zoals muis en toetsenbord data. Een aantal belangrijke functionaliteiten zijn: Encryptie: RDP gebruikt de stroom versleuteling RC4. Kleuren: Het ondersteunt 32-bit kleurweergave. Geluid: Geluiden worden ook doorgestuurd. Klembord: De mogelijk bestaat om data te kopiëren van de remote desktop naar de

client. Poort gebruik: De applicatie die draait binnen de terminal sessie kan toegang hebben

tot lokale seriële en parallelle poorten. RDP haalt ook voordeel uit Network Load Balancing (NLB), beschikbaar in de Windows server familie. NLB stelt de client in staat om met een verzameling van servers te verbinden die allen Terminal Services draaien. Op deze manier is er redundantie toegevoegd aan het systeem [15].

2.7.3

Virtual Network Computing (VNC)

Het grote verschil met de vorige protocollen is dat VNC een open-source thin client architectuur is. Het maakt gebruik van het open-source Remote Frame Buffer (RFB) protocol om van op afstand toegang te krijgen tot displays. Er bestaan een aantal versies van het RFB protocol, het ene is al beter geschikt om te gebruiken bij lage bandbreedte dan het andere [17]. Een verbeterde versie van VNC is bijvoorbeeld TightVNC [18]. Deze versie bevat een aantal nieuwe functies, verbeteringen en bugfixes t.o.v. de originele VNC versie. TightVNC is nog steeds gratis, inzetbaar tussen verschillende platformen en compatibel met de standaard VNC. Een aantal extra functies in TightVNC zijn: Bestandsoverdracht in Windows versies. Aanpassen van de grootte van de remote desktop. Het is mogelijk om de volledige

remote desktop te zien op een scherm met kleinere resolutie. Efficiëntere encodering met optionele JPEG compressie [19].

2.8 Heuristieken voor serverplaatsing

2.7.4

13

Hybrid Thin-Client protocol

Huidige thin client systemen zijn ideaal voor klassieke kantoortoepassingen. Wanneer we gebruik willen maken van multimedia en games zijn die systemen vaak niet meer voldoende. Het vereist een veel grotere bandbreedte en rekenkracht. Om dit probleem op te lossen is er binnen de vakgroep onderzoek gedaan naar een hybrid thin client protocol. Dit protocol kan dynamisch switchen tussen een klassiek thin client protocol en realtime desktopstreaming. Zo is het protocol in staat om het beste van beide te combineren. De desktop streamer verzamelt eerst de frames, encodeert die vervolgens waarna de output in pakketten wordt geplaatst. Deze pakketten worden nu doorgestuurd naar de client waarna de stream gebufferd wordt, gedecodeerd en vervolgens weergegeven wordt op het scherm van de thin client [12].

2.8

Heuristieken voor serverplaatsing

Voor het plaatsen van thin client servers in een netwerktopologie bestaan verschillende strategieën. De netwerktopologie van een toegangsnetwerk bestaat typisch uit verschillende niveaus. De mogelijke heuristieken hangen af van de plaatsting van de servers in het netwerk.

2.8.1

Centraal

Bij deze heuristiek worden de servers zo veel mogelijk gegroepeerd en zo diep mogelijk in het netwerk geplaatst. Als de netwerktopologie uit verschillende niveaus bestaat worden de servers op een zo hoog mogelijk niveau geplaatst, zie figuur 2.7. Dit zal leiden tot minder nodige locaties en een kleinere overcapaciteit. De gebruiker ondervindt hier de grootste delay bij het uitvoeren van een applicatie.

2.8 Heuristieken voor serverplaatsing

14

Figuur 2.7: Centrale serverplaatsing

2.8.2

Decentraal

Deze heuristiek heeft een volledig tegenovergestelde strategie. Hier gebeurt de plaatsing van de servers zo dicht mogelijk bij de gebruiker. De servers worden dus aan de rand van het netwerk geplaatst. Bij een netwerktopologie met verschillende niveaus is dit het laagste niveau. Door het toepassen van deze heuristiek gaan er zich op veel meer locaties servers moeten bevinden. Om een voldoende dienstverlening te garanderen moet er op elke locatie een voldoende capaciteit voorzien worden, waardoor de totale servercapaciteit veel hoger zal liggen. Een gebruiker ondervindt nu de kleinste delay.

Figuur 2.8: Decentrale serverplaatsing

DE SIMULATOR

15

Hoofdstuk 3

De simulator In dit hoofdstuk volgt een bespreking van de architectuur en de functionaliteiten van de simulator. De simulator moet in staat zijn een aantal scenario’s te simuleren. Een simulatie moet het gedrag van de gebruikers kunnen nabootsen en de netwerksituatie kunnen monitoren. Een gebruiker bevindt zich op een locatie met de naam van een netwerkknooppunt van het laagste niveau en voert een type applicatie uit. Aan alle knooppunten moet het mogelijk zijn om een server farm toe te voegen en aan de netwerktakken een linkcapaciteit. Wanneer een gebruiker online komt, wordt die verbonden met een beschikbare server farm. De gebruiker wordt dan toegevoegd aan de server farm en het geheugen en cpu gebruik wordt toegevoegd. Vervolgens wordt de gebruikte linkcapaciteit ook toegevoegd. Gedurende de simulatie schrijven we gegevens weg zoals geheugencapaciteiten, linkcapaciteiten, niet bediende gebruikers, enz. De simulator kan gebruik maken van verschillende server selectie algoritmes, elk met hun specifieke kenmerken. Om een aantal strategieën van servercapaciteitsbeperkingen uit te voeren, is het belangrijk de server farm capaciteiten van een bepaald niveau te kunnen beperken of op nul te zetten. Hiermee kunnen de heuristieken uit paragraaf 2.8 bestudeerd worden.

3.1

Architectuur

Alle klassen en belangrijkste attributen van de simulator zijn weergegeven in figuur 3.1. Het programma maakt gebruik van een aantal bibliotheken. De belangrijkste is de TRS (Telecom Research Software) bibliotheek [20]. Deze bibliotheek is ontwikkeld binnen de vakgroep. Met deze bibliotheek kunnen we het netwerk voorstellen. Het is mogelijk

3.1 Architectuur

16

om netwerkknopen en verbindingen toe te voegen. Na het definiëren van het netwerk kunnen we aan de netwerkknopen en de netwerktakken attributen toevoegen. Hiermee kunnen we bijvoorbeeld aan elke netwerkknoop een server farm object toekennen. De linkcapaciteiten worden als attribuut aan de netwerktakken toegevoegd. Zo zijn we in staat om de capaciteiten van alle links bij te houden. Voor het simuleren van een scenario wordt gebruik gemaakt van discrete events. Het principe is dat er in eerste instantie events worden toegevoegd aan een lijst, elk event heeft een tijdstip. Na het toevoegen van alle initiële events wordt de simulatie gestart. De events worden nu volgens tijdstip afgehandeld. Zo kunnen we specifieke events genereren die dan chronologisch worden afgehandeld. De belangrijkste functionaliteit is om gebruikers actief te maken en die vervolgens weer te deactiveren. De specifieke events zijn een overerving van de klasse SimEvent. Alle events worden dan toegevoegd in een data set van de klasse Simulation waarna ze tijdens de simulatie uitgevoerd worden. Bepaalde events kunnen ook een nieuw event genereren. Wanneer er een gebruiker wordt toegevoegd wordt ook het event aangemaakt wanneer de gebruiker offline gaat. De simulator maakt gebruik van een centrale statische klasse, namelijk de NetworkManager. Tijdens de simulatie voorziet deze klasse alle functionaliteiten die nodig zijn. Wanneer een gebruiker toegevoegd wordt, zoekt het server selectie algoritme de geschikte server farm. Gegevens zoals het aantal niet bediende gebruikers, het netwerk, de mapping van de server farms en het totaal aantal hops worden hier ook bijgehouden tijdens de simulatie. De simulator bevat ook de algemene klassen User en Application. Van deze klassen erven een aantal andere klassen over, bijvoorbeeld de klassen BusinessUser en ResidentialUser. De type applicaties erven over van de klasse Application. Elk type applicatie heeft volgende attributen: bandbreedte, latency, cpu gebruik, geheugen en het type, zie figuur 3.1.

3.1 Architectuur

17

Figuur 3.1: Architectuur van de simulator

De klasse Algorithm bevat het algoritme om de suboptimale server farm locaties te bepalen in functie van de toegestane latency van de applicaties [21]. Dit algoritme wordt gebruikt om in eerste instantie de suboptimale locaties te bepalen. Met elke mogelijke locatie wordt er vervolgens een object van de klasse ServerFarm mee verbonden. Dit wordt gerealiseerd door een object van de klasse AttributeMapping (gedefinieerd in TRS) te maken. Zo kan met elke node een server farm verbonden worden. Na het actief worden van een gebruiker wordt die toegevoegd aan de server farm en de attributen van memory en cpuUsage worden verhoogd. Een server farm kan ook in capaciteit beperkt worden.

3.2 Functionaliteiten

3.2

18

Functionaliteiten

In volgende sectie volgt een beschrijving van de belangrijkste functionaliteiten van de simulator. De algemene structuur is reeds uitgelegd in paragraaf 3.1. Hier volgt de bespreking van een aantal specifieke functionaliteiten die zullen gebruikt worden tijdens de simulaties.

3.2.1

Server farm locatie bepaling

In [21] is er een algoritme ontwikkeld om de suboptimale locaties te bepalen van de server farms. De locaties worden bepaald aan de hand van de maximaal toelaatbare latency van de applicatie. Indien de toelaatbare latency hoger is zal dit leiden tot een minder aantal locaties. Dit komt omdat servers dan dieper in het netwerk kunnen geplaatst worden en beter gegroepeerd op minder locaties. Het algoritme houdt er rekening mee dat het mogelijk is om alle gebruikers te bedienen binnen de maximale latency. De latency wordt steeds in het aantal hops tussen de gebruiker en de thin client server uitgedrukt. Wanneer een gebruiker een maximale latency heeft van drie hops mag de applicatieserver op maximum drie hops van de gebruiker verwijderd zijn. Bij dit algoritme wordt er slechts rekening gehouden met één maximale latency. Indien de latency afhangt van het type applicatie waarvan de gebruiker gebruik maakt en er kunnen meerdere applicaties uitgevoerd worden met elk hun specifieke latency zal het algoritme meermaals uitgevoerd moeten worden. Vervolgens worden alle mogelijke locaties in een lijst geplaatst.

3.2.2

Server selectie

Bij het actief worden van een gebruiker wordt er steeds een server toegewezen. Dit kan gebeuren volgens verschillende algoritmes. Er zijn drie verschillende algoritmes gedefinieerd: een standaard, een gevorderd en een geavanceerd algoritme. Standaard algoritme Het standaard algoritme tracht elke gebruiker te verbinden met een server zo diep mogelijk in het netwerk afhankelijk van de maximaal toelaatbare latency van de applicatie. Indien een server farm beperkt is in capaciteit kan die volzet zijn. Als dit gebeurt, wordt op een niveau lager gekeken of er nog capaciteit vrij is. De manier van werken is weergegeven in figuur 3.2.


19

Figuur 3.2: Server toewijzing bij standaard algoritme

Gevorderd algoritme Dit algoritme is een uitbreiding van het standaard algoritme. Als er genoeg capaciteit is op elke locatie zal dit hetzelfde resultaat geven als het standaard algoritme. Iedere gebruiker wordt dan met een server verbonden op zijn maximaal toelaatbaar aantal hops. Als er geen capaciteit meer vrij is op de servers in dezelfde tak in de netwerk boom zal gekeken worden naar de servers in de zijtakken. Dit is enkel mogelijk als het toelaatbaar aantal hops minimaal drie bedraagt. Deze situatie wordt ge¨ıllustreerd in figuur 3.3.

Figuur 3.3: Server toewijzing bij gevorderd algoritme


20

Geavanceerd algoritme Dit algoritme heeft tot doel een gelijkmatige verdeling van de servercapaciteit op niveau 3 te bekomen. Indien er na het controleren van niveau 1 en niveau 2 geen capaciteit beschikbaar is, zal het algoritme een server zoeken op het laagste niveau die het minst belast is. Zo zal de server op niveau 3 in dezelfde netwerkttak niet direct overbelast worden. Anders bestaat de mogelijkheid dat gebruikers waarvan de maximale latency kleiner is dan drie hops niet bediend kunnen worden. De wijze van toewijzing wordt getoond in figuur 3.4

Figuur 3.4: Server toewijzing bij geavanceerd algoritme

3.2.3

Type gebeurtenissen

Om een scenario te simuleren gebruikt het programma discrete events. Hiervoor zijn een aantal specifieke events gedefinieerd, zoals voor het online komen van een gebruiker bestaan er twee type events. Dit komt omdat we gebruik maken van twee type gebruikers. Het scenario model wordt nauwkeuriger beschreven in paragraaf 4.2. Nadat een gebruiker online is gekomen, dient hij ook weer offline te kunnen gaan. Dit wordt verwezenlijkt door het ChangeStatus event. Tot slot hebben we ook nog het basis object namelijk SimEvent. Dit event zal gebruikt worden om op bepaalde tijdstippen de data weg te schrijven naar een output bestand.


21

AddBusinessUser Dit event heeft als attributen een gebruiker en een tijdstip. Wanneer dit event optreedt, zal de gebruiker via het ingestelde server selectie algoritme verbonden worden met de gekozen server farm. Vervolgens worden de netwerkvereisten, zoals server farm capaciteit en linkcapaciteit voor de gebruiker, toegevoegd. Bij het optreden van dit event wordt steeds een nieuw event aangemaakt, namelijk wanneer de gebruiker offline zal gaan. De online tijd wordt bepaald door een normale verdeling. Een gebruiker blijft dus niet steeds een zelfde tijd online. AddResidentialUser Dit event heeft dezelfde werking als AddBusinessUser. Het verschil is dat er nu een residentiële gebruiker online komt en bij het optreden van dit event kan de online tijd door een andere normale verdeling bepaald worden. Meer uitleg over dit scenario model is terug te vinden in paragraaf 4.2. ChangeStatus ChangeStatus heeft als attributen een gebruiker, een bepaald tijdstip en een boolean. De boolean wordt op false gezet wanneer de gebruiker offline gaat. Als dit event optreedt worden de toegewezen bronnen van het netwerk en de servers weer vrijgegeven. Deze kunnen dan gebruikt worden voor het bedienen van andere gebruikers. SimEvent Gedurende een simulatie wordt heel wat data gegenereerd. Met behulp van dit event kan op bepaalde tijdstippen de data weggeschreven worden naar een output bestand. Met deze gegevens kan er dan een verdere analyse gedaan worden van een scenario.

3.2.4

Chronologie van de gebeurtenissen

Zoals uitgelegd in paragraaf 3.2.3, werkt de simulator met discrete gebeurtenissen. De simulator zal twee dagen simuleren omdat gebruikers online kunnen zijn tussen dag één en twee. Gedurende de dag kunnen er op 48 tijdstippen events gegenereerd worden. Deze events worden geordend op tijdstip en events op hetzelfde tijdstip worden geordend


22

op id, zodat een gebeurtenis die eerder is aangemaakt eerder uitgevoerd wordt. Het aantal gebruikers dat we toevoegen op een bepaald tijdstip wordt bepaald door het aantal gebruikers dat dat jaar actief kunnen worden en de distributie in de tijd. Deze distributie is bepaald in sectie 4.2.3. De volgorde van het optreden van de gebeurtenissen is weergegeven in figuur 3.5.

Figuur 3.5: Volgorde van de gegenereerde gebeurtenissen

3.2.5

Output van een simulatie

Tijdens iedere simulatie wordt de output ieder uur weggeschreven in een Excel-bestand en gebruikt voor de berekening van het economisch kostenmodel. De gegevens die worden weggeschreven zijn: Server farm capaciteit [MB]

Tijdens een simulatie wordt ieder uur de gebruikte capaciteit in een server farm weggeschreven. Met behulp van deze waarden kunnen we dan berekenen hoeveel servers we moeten plaatsen. Linkcapaciteit [kbps]

Wanneer een gebruiker een verbinding opzet met een server wordt de gebruikte link capaciteit op die link verhoogd. Ieder uur worden de vereiste link capaciteiten weggeschreven naar het Excel-bestand. Dit is altijd de worse case situatie door de chronologie van de events worden eerst de gebruikers toegevoegd, vervolgens gebeurt de output en dan pas gaan de gebruikers offline. Niet bediende gebruikers [%]

Indien sommige server farms beperkt worden in capaciteit bestaat de mogelijk dat


23

er gebruikers niet bediend kunnen worden. Dit zal een belangrijke parameter zijn bij het beoordelen van een bepaalde strategie. Eventueel kan er ook een kost aan verbonden worden per gebruiker die niet bediend is. Het totaal aantal hops

Telkens een gebruiker online komt, wordt de hop count teller vermeerderd met het aantal hops. Wanneer we dan op het einde het totaal aantal hops delen door het aantal gebruikers verkrijgen we het gemiddeld aantal hops. Deze waarde geeft weer hoe ver een server zich gemiddeld in het netwerk bevindt. In eerste instantie is die waarde afhankelijk van het type applicatie dat uitgevoerd wordt. Als de gemiddelde waarde daalt wijst dit erop dat sommige gebruikers met een server dichter bij de rand van het netwerk verbinden.

3.2.6

Verwerking gegevens

Bij het begin van een simulatie wordt een Excel-bestand ingelezen. Dit bestand bevat reeds het kostenmodel en de nodige analyses die uitgevoerd worden aan de hand van de data die tijdens de simulatie wordt weggeschreven. Zo bekomen we een automatische output waardoor we de verschillende simulaties efficiënter met elkaar kunnen vergelijken.

TECHNISCH EN ECONOMISCH MODEL

24

Hoofdstuk 4

Technisch en economisch model In hoofdstuk 3 zijn de belangrijkste functionaliteiten en de werking van de simulator verduidelijkt. De hoofdtaak van de simulator is voor een bepaald scenario een aantal simulaties uit te voeren en de gewenste output bij te houden. Voor een correcte dimensionering van het netwerk zijn een aantal technologische parameters nodig. De bepaling hiervan gebeurt in sectie 4.1. Het gaat hier over de netwerktopologie en de applicatie parameters. Een aantal belangrijke applicatie parameters zijn: gemiddelde bandbreedte, maximale latency en gemiddeld geheugengebruik. Cpu gebruik wordt hier buiten beschouwing gelaten, wegens de moeilijke kwantificatie van deze parameter en het niet lineare verloop. Indien er voldoende rekencapaciteit aanwezig is kan het geheugen als bottlneck gebruikt worden. Elke simulatie maakt gebruik van eenzelfde scenariomodel. Het model is beschreven in sectie 4.2. Naast de technische eigenschappen in kaart te brengen, is het van belang een economische analyse uit te voeren voor de verschillende simulaties. Voor het bepalen van deze analyses is een kostenmodel opgesteld, zie sectie 4.3. Hoe de economische output verder wordt berekend is beschreven in het economisch model, zie sectie 4.4. Tot slot wordt nog verduidelijkt welke parameters gevarieerd zullen worden tijdens de simulaties. Zo kan door het aanpassen van bepaalde parameters tot een betere situatie gekomen worden. Tevens kan onderzocht worden wat de invloed is van het wijzigen van een parameter op de dimensionering van het netwerk.

4.1 Technologische parameters

4.1

25

Technologische parameters

4.1.1

Netwerktopologie

Als netwerktopologie wordt het Belgische model gebruikt. De topologie van het netwerk is ge¨ınspireerd op het toegangsnetwerk van Belgacom. Dit model bestaat uit een backbone netwerk, dat verschillende BRAS nodes bevat. Iedere BRAS node is verbonden met een aantal LEX nodes en iedere LEX node is op zijn beurt verbonden met een aantal DSLAM nodes. De gebruiker kan dan via de DSLAM node toegang krijgen tot het netwerk. De netwerktopologie bestaat uit: Backbone netwerk met 9 BRAS nodes die met elkaar verbonden zijn in een mesh

structuur. 10 LEX nodes per BRAS 50 DSLAM nodes per LEX

De topologie van dit toegangsnetwerk bestaat uit verschillende niveaus. In dit netwerk kunnen er op elke niveau servers geplaatst worden bij de verschillende nodes. We hebben het niveau met de DSLAM nodes die zich het dichtst bij de gebruiker bevinden en het niveau met de BRAS nodes die zich het verst van de gebruiker bevinden. Per DSLAM kunnen er maximaal 1000 gebruikers actief zijn. Alle links binnen het netwerk zijn bidirectioneel. De verhoudingen van het aantal nodes zijn gekozen op basis van informatie die binnen de vakgroep IBCN beschikbaar was. Er is geopteerd voor het Belgische model omdat hiermee de beheersbaarheid van de simulaties beter te handhaven was.


26

Figuur 4.1: Netwerktopologie

4.1.2

Applicatie parameters

In een thin client systeem hangen de technische vereisten sterk af van het type applicatie. Om deze reden hebben we de applicaties in vier verschillende categorieën verdeeld. Een bepaald type gebruiker maakt volgens een ingesteld percentage gebruik van dit type applicatie. De vier type applicaties zijn: Kantoortoepassingen: bv. Word, Excel Surfen op internet: bv. Firefox, Internet Explorer Video bekijken: bv. VLC [22] Spel: bv. Age of Empires [23], SWAT 3 [24]

In de volgende puntjes worden de gemiddelde bandbreedte, de maximale latency en het gemiddeld geheugengebruik per type applicatie gedefinieerd.


27

A. Bandbreedte Eén van de belangrijkste parameters voor de dimensionering van het netwerk is de vereiste bandbreedte per type applicatie. Deze parameter is moeilijk te kwantificeren. De bandbreedte van een type applicatie is namelijk niet constant en tevens afhankelijk van het gebruikte protocol. Het is wel mogelijk om een gemiddelde richtwaarde te bepalen. Tussen de verschillende protocollen bestaat er een verschil in gebruikte bandbreedte. Toch moet bij het beoordelen van de protocollen steeds de kwaliteit van de multimedia output in rekening gebracht worden. In tabel 4.1 zijn de waarden weergegeven. Spel kan door bepaalde protocollen niet uitgevoerd worden of had een te lage kwaliteit om de applicatie te ondersteunen. Tabel 4.1: Nodige bandbreedte in kbps per gebruiker, resolutie van 1280x1024

Type applicatie

Citrix ICA [17]

VNC turbo [17]

RDP [17]

Hybrid protocol [12]

kbps

kbps

kbps

kbps

Kantoortoepassingen

550

355

800

1851

Surfen

3.000

5.500

4.500

1151

Video bekijken

2.120

36.050

36.0002

3.0003

Spel

/

30.2001

/

2.0001

Tijdens de simulaties heeft elk type applicatie een nodige bandbreedte. De waarden die hiervoor zijn gebruikt zijn weergegeven in tabel 4.2 Tabel 4.2: Input parameters voor de bandbreedte

1

Type applicatie

Ingestelde bandbreedte

Kantoortoepassingen

550 kbps

Surfen

3.000 kbps

Video bekijken

3.000 kbps

Spel

5.000 kbps

resolutie van 1024x768 resolutie van 512x304 3 resolutie van 640x480 2


28

B. Latency Latency is een expressie voor de duurtijd om een data pakket van het ene naar het andere punt te sturen. Vaak wordt dit ook uitgedrukt in de round-trip-time, de tijd van zender naar ontvanger en terug. Hier zullen we gebruik maken van de round-trip betekenis. In figuur 4.3 worden een aantal waarden binnen een WAN topologie weergegeven [25]. Tabel 4.3: WAN latency gegevens [25]

Oorsprong - bestemming

Latency in milliseconden

Regionale round-trips binnen Europa

≤ 30ms

Tussen Japan

≤ 30ms

Regionale round-trips binnen Noord-Amerika

≤ 45ms

Trans-Atlantische round-trips

≤ 90ms

Tussen Asia-Pacific

125ms

Transpacific round-trips

≤ 160ms

UK naar Korea

470ms1

De latency hangt af van de snelheid binnen het transmissie medium (bv. koperkabel, optische vezel of radiogolven), vertragingen veroorzaakt door netwerkapparaten, WAN topologie (bv. ster, ring, mesh) en de afstand tussen zender en ontvanger. Omdat een thin client systeem interactief is, zal de latency voldoende laag moeten zijn. Indien de latency meer dan 150 ms bedraagt zal de gebruiker daar hinder van ondervinden [26]. In bepaalde applicaties zal de latency nog kritischer worden, zoals bij gaming. Tabel 4.4 toont de toelaatbare latency voor enkele typische toepassingen. De latency van WWW moet wel in de context bekeken worden. Het gaat hier om de tijd dat de gebruiker bereid is om te wachten bij het surfen. Het weergeven van een pagina in een thin client systeem mag dus ook zo lang duren maar de bediening van de browser moet wel sneller gaan. 1

Hoogste latency tussen twee landen


29

Tabel 4.4: Toelaatbare latency [25]

Applicatie

Latency (ms)

Jitter (ms)

Pakket verlies (%)

SAP

100-300

niet van toepassing

1-3

VoIP

50-150

40-80

0-1

WWW

200-1000

niet van toepassing

1-5

FTP

niet van toepassing

niet van toepassing

1-10

E-mail

niet van toepassing

niet van toepassing

1-10

De simulator rekent niet in het aantal milliseconden maar in het aantal hops tussen client en server. De input waarden zijn weergegeven in tabel 4.5. Omdat spel de kleinste maximale latency heeft wordt in functie van die latency het aantal hops op 1 ingesteld. Dit komt erop neer dat een spel applicatie op een server op DSLAM niveau zal uitgevoerd worden. Er moet rekening gehouden worden met de round trip tijd tussen gebruiker en DSLAM server en met de verwerkingstijd op de server. Het bekijken van video is minder kritisch waardoor het maximaal aantal hops op 2 wordt geplaatst. Bij kantoortoepassingen en surfen mag de latency ook niet te hoog worden of de bediening van de applicatie zou ondermaats zijn. We stellen hier het maximaal aantal hops in op 3. Tabel 4.5: Maximaal toelaatbare latency

Type applicatie

Toelaatbare latency

Aantal hops

Kantoortoepassingen

100 - 300 ms

3

Surfen

100 - 200 ms

3

Video bekijken

150 ms

2

Spel

50 - 100 ms

1

C. Geheugengebruik per type applicatie Het geheugen per type applicatie is noodzakelijk om een correcte dimensionering van de servers te doen. Voor kantoortoepassingen, surfen en video bekijken is een gemiddelde waarde van het geheugen gebruik genomen [27]. In [27] is er geen onderzoek gedaan naar geheugengebruik bij gaming. Het geheugengebruik zal sterk afhangen van het spel aanbod. We hebben een aantal spellen gekozen waaronder Age of Empires [23] en SWAT

4.2 Scenario model

30

3 [24] waarvan het gemiddelde geheugengebruik 60 MB bedraagt, bepaald uit de systeemvereisten en getest door uitvoering. Indien het aanbod zou veranderen kunnen we deze parameter altijd wijzigen. De gebruikte waarden zijn weergegeven in tabel 4.6. Tabel 4.6: Geheugen gebruik per type applicatie

4.2 4.2.1

Type applicatie

Geheugen gebruik

Kantoortoepassingen

34 MB

Surfen

39 MB

Video bekijken

51 MB

Spel

60 MB

Scenario model Populatie

De populatie die telkens gebruikt zal worden bij het simuleren van een scenario bestaat uit business gebruikers en residentiële gebruikers. Dit wordt gedefinieerd in een verhouding van het aantal business gebruikers tot de totale populatie. Bijvoorbeeld een verhouding van 40% betekent dat er 40% business gebruikers zijn en 60% residentiële gebruikers. In totaal houden we rekening met elf verhoudingen, van 0% tot en met 100%. De populatie wordt in deze case op maximum 500.000 gebruikers ingesteld. In realiteit is dit niet de populatie van het eerste jaar. Dit aantal wordt bepaald door de gedefinieerde adoptie curve.

4.2.2

Adoptie

Om het aantal actieve gebruikers te bepalen in een jaar zijn er twee adoptie curven opgesteld. De business gebruikers volgen een andere adoptie dan de residentiële gebruikers. De modulatie gebeurt aan de hand van een Gompertz curve [28]. −b(t−a)

S(t) = m.e−e S = Aantal gebruikers m = Maximum markt potentieel a = Punt waar een adoptie van 37% is

4.2 Scenario model

31

b = Tempo van de adoptie t = Tijd

De parameter m wordt berekend aan de hand van de verhouding tussen business en residentiële gebruikers. Bijvoorbeeld bij 80% zal m voor de adoptie van de business gebruikers 400.000 bedragen en voor de residentiële gebruikers 100.000. De waarden voor parameters a en b zijn weergegeven in tabel 4.7. We verwachten dat de adoptie van de business gebruikers sneller zal gaan dan van de residentiële gebruikers. Dit vermoeden we omdat thin clients op dit moment meer van toepassing zijn in het professionele leven. De business gebruiker zal dan ook sneller te overhalen zijn voor deze dienst. Daarom is de parameter b groter bij business, hierdoor heeft de curve een hoger stijgingspercentage. De adoptie curves bij een verhouding van 40% en 80% business gebruikers zijn ge¨ıllustreerd in figuren 4.2 en 4.3. Tabel 4.7: Adoptie parameters

Parameter

Business

Residentieel

a

2008,5

2010

b

0,9

0,6

m

400.000

100.000

Figuur 4.2: Adoptie curves bij 40% business gebruikers

4.2 Scenario model

32

Figuur 4.3: Adoptie curves bij 80% business gebruikers

4.2.3

Aankomstdistributie van de gebruikers in de tijd

Nu weten we hoeveel actieve gebruikers het systeem zal hebben. Deze aantallen zijn weergegeven in tabellen A.1 en A.2 in de bijlage. Al deze gebruikers komen natuurlijk niet op hetzelfde moment online. Om een reële situatie te simuleren is er een model opgesteld wanneer de type gebruikers online komen. Business gebruikers komen gedurende de ochtend online, namelijk tussen 5u en 12u [29]. De percentages zijn gebaseerd op de aankomsttijd van de werknemers in België. Voor de residentiële klanten hebben we de cijfers van Nielsen gebruikt [30]. Daarbij veronderstellen we een distributie die piekt naar de avond, maar waarbij de hele dag gebruikers kunnen toegevoegd worden. In figuur 4.4 zijn deze twee distributies weergegeven.

4.2 Scenario model

33

Figuur 4.4: Aankomstdistributie van de gebruikers in % van de populatie

4.2.4

Online tijd

In vorig puntje is er bepaald wanneer de gebruikers online komen. Nu kunnen we de tijd bepalen hoe lang een gebruiker het systeem zal gebruiken. Een business gebruiker blijft gemiddeld 8 uur actief, met variaties van een uur. Een residentiële gebruiker blijft gemiddeld 1 uur online, met variaties van een half uur. De gemiddelde online tijd ligt dan tussen de 30 en 90 min. Zoals reeds vermeld worden er 48 tijdstippen gebruikt om een dag te simuleren dus om het half uur een event. We maken gebruik van een normale verdeling zodat er 68% kans is op één uur, 16% kans op 30 min en 16% kans op 90 min. Bij de business gebruikers bekomen we een zelfde situatie maar de online tijden liggen nu tussen 7 en 9 uur.

4.2.5

Verdeling van de gebruikers over het netwerk

Het netwerk bevat 4500 DSLAMs waarmee gebruikers zich kunnen verbinden. We kunnen de gebruikers bijvoorbeeld uniform verdelen over het netwerk maar voor bepaalde profielen is dit echter geen reële situatie. Business gebruikers hebben juist het kenmerk om zich te groeperen, bijvoorbeeld in kantoren. Via bepaalde DSLAMs zullen er dus meer business gebruikers verbonden worden. We stellen in dat een business gebruiker 80% kans heeft om met 1/3 van de DSLAMs te verbinden en 20% kans met de overige. Voor residentiële

4.2 Scenario model

34

gebruikers kunnen we wel een uniforme verdeling gebruiken. Residentiële gebruikers verbinden namelijk van thuis en groeperen zich niet op enkele DSLAMs zoals dit bij business gebruikers gebeurt. (zie figuur 4.5)

Figuur 4.5: Verdeling van de gebruikers over het netwerk

4.2.6

Gebruikersprofiel

In de paragraaf 4.1.2 over de technische parameters zijn reeds vier type applicaties gedefinieerd. Een type gebruiker zal dus volgens een bepaald percentage gebruik maken van deze applicaties. De percentages voor business -en residentiële gebruikers zijn weergegeven in tabel 4.8. Tabel 4.8: Gebruikersprofielen

Type Gebruiker

Kantoortoepassingen

Surfen

Video bekijken

Spel

Business gebruiker

75%

20%

5%

0%

Residentiële gebruiker

20%

40%

30%

10%

4.3 Kost parameters

4.3

35

Kost parameters

De economische parameters worden gedefinieerd in het input bestand. De waarden die gebruikt zijn om het model door te rekenen zijn in tabel 4.10 weergegeven. De kosten kunnen we in twee categorieën verdelen. Ten eerste hebben we de investeringskosten of “capital expenditures” (Capex) genoemd. Een tweede categorie bestaat uit operationele kosten, die ieder jaar terug komen, ook wel “operating expenditures” (Opex) genoemd. Er wordt een onderscheid gemaakt tussen vijf types servers. De verschillen tussen de types zijn weergegeven in tabel 4.9. Elk type server heeft een bepaalde hoeveelheid geheugen. Van de totale capaciteit kan slecht een deel gebruikt worden voor het uitvoeren van de thin client applicaties. Het totale geheugen wordt eerst verminderd met de capaciteit nodig voor het draaien van het besturingssysteem. Dit wordt bepaald door een factor die afhankelijk is van het type server. Voor type vijf is dit 1 keer 128 MB, voor type vier 2 keer 128 MB, voor type drie 4 keer 128 MB enzoverder. Deze factor is bepaald in functie van het aanwezige geheugen. Het is niet aangewezen om alle overige capaciteit te gebruiken voor het uitvoeren van de thin client applicaties daarom wordt er een fractie van genomen. Als percentage wordt hier 80% gebruikt [31]. De bekomen waarden zijn terug te vinden in tabel 4.9 in de kolom “RAM voor thin client”. De prijzen van de type servers zijn bepaald aan de hand van de prijzen van HP [32]. Tijdens de simulaties is het geheugen de bottleneck. Tabel 4.9: Dimensionering van de type servers [32]

Type server

Type server

Processor

RAM [GB]

RAM voor thin client [MB]

Type 1

DL580 G5

4 × quad core

32

25.000

Type 2

DL580 G5

2 × quad core

16

12.000

Type 3

DL380 G5

2 × quad core

8

6.000

Type 4

DL380 G5

1 × quad core

4

3.000

Type 5

DL380 G5

1 × dual core

2

1.500

Een rack kan enkel geplaatst worden op LEX of BRAS niveau. Op DSLAM niveau kunnen we dus slechts één server plaatsen van een bepaald type. De capaciteit van een rack is beperkt tot 12 servers [33]. In het model houden we ook rekening met een vervangings-

4.3 Kost parameters

36

termijn van drie jaar voor de infrastructuur. We houden rekening met twee type licenties, één voor de thin client architectuur en één voor het aanbieden van Office. Bij deze laatste gebruiken we een volume licentie, de prijs per licentie daalt naarmate het volume toeneemt. Nu gebeurt dit in stappen van 50.000 gebruikers en een vermindering van 20 ¤ per licentie per stap, vandaar de notatie 400 → 220 ¤. Bij het uitrollen van een thin client dienst zijn er ook veel operationele kosten. Het is belangrijk om die zo correct mogelijk te definiëren in het model. De energiekosten worden berekend per server. De berekening is: 408 Wh x 0,09 ¤ per KWh = 0,04 ¤ per uur per server. Voor de help desk en het operationeel houden van de servers is een bepaalde personeelssterkte nodig. Dit wordt uitgedrukt in fulltime-equivalent (FTE). De kost van één werkkracht gedurende één jaar is 40.000 ¤. Voor het bepalen van de kost van de help desk wordt rekening gehouden met het aantal oproepen van een klant per jaar en van de duur om een oproep af te handelen. De totale kost zal dus sterk afhangen van het aantal gebruikers. Voor het operationeel houden van de servers zijn een aantal werknemers nodig. We rekenen in ons model met één werknemer per 40 servers. Voor onderhoudskosten wordt 10% genomen van de totale investering. In het model wordt ook al een deel marketing in rekening gebracht. Dit komt op 10 ¤ per klant. Een laatste categorie zijn de netwerkkosten. In het model is de prijs per km per jaar voor een 2,5 Gbps connectie in rekening gebracht. Vervolgens is er een schatting gemaakt van de totale lengte van een type link. Nu kan de prijs van een 2,5 Gbps connectie berekend worden. Om de prijs van een connectie per kbps te bekomen, dienen we die prijs te delen door 2,5 miljoen. Als we dan de nodige bandbreedte weten uit de simulaties, kunnen we de kostprijs bepalen. De totale lengte van de BRAS-LEX connecties wordt geschat op 40 km (gemiddelde lengte) x 9 (aantal BRASsen) x 10 (aantal LEXen per BRAS) = 3.600 km. De totale lengte van de LEX-DSLAM connecties wordt geschat op 6 km (gemiddelde lengte) x 90 (aantal LEXen) x 50 (aantal DSLAMs per LEX) = 27.000 km.

4.3 Kost parameters

37

Tabel 4.10: Het kostenmodel

Investeringskost Kost per type server Type 1 [32]

24.000 ¤

Type 2 [32]

12.000 ¤

Type 3 [32]

6.000 ¤

Type 4 [32]

3.000 ¤

Type 5 [32]

1.500 ¤

Kost per rack [33] Thin client licentie kost [33] Office licenties

5.280 ¤ 290,40 ¤ 400 → 220 ¤

Jaarlijkse kost voor infrastructuur Kost van bedrading per rack (per jaar) [33] Huur kost per rack (per jaar) [33]

198 ¤ 3.564 ¤

Operationele kosten Energie kosten per server (per uur) [33] Full time equivalent (FTE) kost [33] Aantal help desk oproepen per jaar per klant [33]

0,04 ¤ 40.000 ¤ 5

Gemiddelde tijd per incident (in minuten) [33]

34

Maximum aantal servers per FTE voor operationeel te houden

40

Onderhoud servers

10 %

Marketing (per klant)

10 ¤

Netwerkkosten

1

Fiber connectie tussen BRAS-LEX

1.500 ¤1

Fiber connectie tussen LEX-DSLAM

1.500 ¤1

per km per jaar voor 2,5 Gbps connectie

4.4 Economisch model

4.4

38

Economisch model

Aan de hand van de output van een simulatie, de economische input parameters en het aantal actieve gebruikers kunnen we de cumulatieve kost van de dienst berekenen. Door de random generatie van gebruikerslocatie en type applicatie is de output van de simulatie steeds verschillend. Op LEX niveau hebben we dus in elke server farm een verschillende capaciteit nodig. Deze verschillen zijn echter vrij beperkt. Om een correcte berekening van het aantal servers op een bepaald niveau te bepalen wordt hier de maximale servercapaciteit gebruikt. Het is ook belangrijk dat er per drie jaar eenzelfde type server wordt gebruikt. Na drie jaar is de server afgeschreven en dient die vervangen te worden. Indien er in een volgend jaar meer capaciteit nodig is, kunnen we servers bij plaatsen. Een aantal kosten zijn afhankelijk van het aantal servers, zoals de bepaling van het aantal racks. Dit aantal hangt af van het aantal servers die nodig zijn in een locatie. Indien we dit aantal weten kunnen we de kost van de racks berekenen. De jaarlijkse kosten voor infrastructuur zijn afhankelijk van het aantal racks. De operationele kost voor het energieverbruik wordt berekend aan de hand van het totaal aantal servers. De operationele kosten voor de servers zijn ook afhankelijk van dit aantal. In de economische input parameters is gedefinieerd dat er één werknemer nodig is per 40 servers. Met behulp van de gebruikte linkcapaciteit kunnen we de operationele netwerkkosten berekenen. Voor een bepaald type link wordt de maximale bandbreedte berekend. Aan de hand van deze bandbreedte berekenen we dan de kost om bijvoorbeeld de BRASLEX verbindingen te voorzien. Door gebruik te maken van een gevorderd server selectie algoritme kan er verbonden worden met een DSLAM-server in een andere tak. Hierdoor is er extra capaciteit nodig tussen die DSLAM en de LEX. Deze extra kost brengen we bij die scenario’s dan ook in rekening. Tot slot zijn er nog een aantal kosten die afhankelijk zijn van het aantal actieve gebruikers. Dit aantal is bepaald in de adoptie en ook te zien in tabellen A.1 en A.2. De licentie kost is bijvoorbeeld afhankelijk van het aantal gebruikers. De kost van de help desk wordt berekend met een formule die ook afhankelijk is van het aantal gebruikers. Na het berekenen van al deze kosten kunnen we de gezamenlijke cumulatieve kost berekenen. Er is ook geopteerd om deze kost te verdelen over de twee type gebruikers. Dit is niet

4.4 Economisch model

39

zo’n eenvoudige taak omdat bepaalde kosten moeilijk te verdelen zijn onder de twee types. We kunnen vaststellen dat er drie cost drivers zijn: de servercapaciteit, de linkcapaciteit en het aantal gebruikers. De kosten die afhankelijk zijn van het aantal gebruikers kunnen direct verdeeld worden onder de twee types. Voor de andere is er een verdeelsleutel nodig. De verdeelsleutel voor de servercapaciteit wordt bepaald door het gemiddeld geheugengebruik van een type gebruiker en afhankelijk van het percentage dat actief is tijdens piekbelasting.

Voor residentiële gebruikers: Factor geheugen gebruik2 =

20%×34M B+40%×39M B+30%×51M B+10%×60M B 75%×34M B+20%×39M B+5%×51M B

= 1, 22

Percentage actief tijdens piekbelasting = 10% Aantal residentiële gebruikers = r Aantal business gebruikers = b

Verdeelsleutel: (r × 10%) × 1, 22 (r × 10%) × 1, 22 + b Voor de verdeelsleutel op basis van de linkcapaciteit gebruiken we een analoge formule maar in plaats van een factor geheugengebruik gebruiken we nu een factor bandbreedte gebruik. Die is gelijk aan 1,9 bij residentiële gebruikers.

Factor bandbreedte gebruik3 =

Verdeelsleutel:

20%×550kbps+40%×3000kbps+30%×3000kbps 75%×550kbps+20%×3000kbps+5%×3000kbps

= 1, 9

(r × 10%) × 1, 9 (r × 10%) × 1, 9 + b

Wanneer we de cumulatieve kost hebben voor een type gebruiker kan de kost voor dat type gebruiker bepaald worden. Dit bekomen we door de cumulatieve kost te delen door het cumulatief aantal gebruikers gedurende die vijf jaar. De bekomen kosten uit de simulaties zijn weergegeven in bijlage C. 2 3

De percentages komen uit tabel 4.8 en de geheugencapaciteiten uit tabel 4.6. De percentages komen uit tabel 4.8 en de bandbreedtes uit tabel 4.2.

4.5 Variabele parameters

40

In een laatste stadium bereken we de Net Present Value (NPV). Hiermee kan een grondige economische analyse uitgevoerd worden. Voor het berekenen van de NPV worden alle CapEx en OpEx cashflows verdisconteerd naar het huidige tijdstip. Als rente wordt hier 10% gebruikt. Bij een NPV analyse dienen ook de voorziene inkomsten in rekening gebracht worden. De directe inkomsten komen vooral uit het abonnementsgeld. Als input parameter wordt hier voor een business abonnement 30 ¤ per maand en voor een residentieel abonnement 35 ¤ per maand genomen. Deze prijzen zijn bepaald aan de hand van wat de gebruiker voor de dienst zou willen betalen. Bij residentiële gebruikers is dit iets hoger omdat er een betere multimedia service wordt aangeboden inclusief gaming. De output van het economisch model wordt getoond bij iedere simulatie, zie hoofdstuk 5.

4.5

Variabele parameters

In paragraaf 4.2 is reeds beschreven hoe het algemeen model van een scenario eruit ziet. Door het wijzigen van een aantal parameters bekijken we de invloed op de dimensionering en de cumulatieve kost van het systeem. De parameters die gewijzigd zullen worden binnen de simulaties zijn: de servercapaciteit, het server selectie algoritme en het gebruikersprofiel.

4.5.1

Servercapaciteit

De totale server farm capaciteit binnen het netwerk kunnen we wijzigen. De server farms op ieder niveau kunnen beperkt worden en zelfs op nul gezet worden. We kunnen vier types server farm locaties instellen, namelijk op BRAS niveau, LEX niveau, DSLAM lage belasting en DSLAM hoge belasting. Na de simulatie kunnen we beoordelen welke strategie het beste resultaat geeft. De DSLAM met hoge belasting is de DSLAM waar de business gebruiker 80% kans heeft om toegang te krijgen tot het netwerk. We merken op dat 1/3 van DSLAMs een hoge belasting heeft en 2/3 een lage belasting, zie paragraaf 4.2.5.

4.5.2

Server selectie algoritme

In de simulator zijn een aantal server selectie algoritmes gedefinieerd (zie paragraaf 3.2.2). Door het gebruik van een gepast selectie algoritme kan de aanwezige servercapaciteit beter benut worden. We kunnen dan bijvoorbeeld met eenzelfde kost meer gebruikers bedienen.

4.5 Variabele parameters

4.5.3

41

Gebruikersprofiel

Indien we een wijziging aanbrengen aan het gebruikersprofiel kan dit gevolgen hebben voor de dimensionering van het systeem. We kunnen bijvoorbeeld de applicatie distributie van een type gebruiker wijzigen. Een belangrijk facet is het al dan niet aanbieden van de gaming applicatie. De mogelijkheid bestaat ook om de online tijd te wijzigen en de gevolgen daarvan te bekijken.

SIMULATIES

42

Hoofdstuk 5

Simulaties In voorgaand hoofdstuk is het gebruikte technisch en economisch model uitvoerig besproken. Aan de hand van dit model zijn een aantal scenario’s gedefinieerd. Bepaalde scenario’s laten een parameter variëren. Het doel van deze variaties is een economisch gunstigere situatie te bekomen. In ieder scenario wordt de cumulatieve kost, procent niet bediende gebruikers, gemiddeld aantal hops, server bezetting, kost per gebruiker en de NPV bepaald. Op basis van het procent niet bediende gebruikers en het gemiddeld aantal hops kunnen we de kwaliteit van de dienst van de verschillende scenario’s met elkaar vergelijken. Via de NPV analyse krijgen we een kijk op de economische haalbaarheid van de dienst. Om het hoofdstuk overzichtelijk te houden worden de details van de berekende kosten per gebruiker weergegeven in bijlage C. We starten met het uitrekenen van het basisscenario. Vervolgens gaan we door het beperken van de server farm capaciteit zoeken naar een betere oplossing. In een volgend scenario bekijken we de invloed van drie aangepaste server selectie algoritmes. Tot slot bestuderen we nog de effecten van het wijzigen van het profiel. Onze aandacht gaat hier vooral naar het effect van het weglaten van de spel applicatie. In een laatste puntje worden de belangrijkste conclusies gegeven.

5.1

Basisscenario

In dit scenario maken we gebruik van het gedefinieerde model in het vorige hoofdstuk. Voor de server toewijzing maken we gebruik van het standaard selectie algoritme. Hierbij wordt elke gebruiker verbonden met de server op het aantal hops bepaald door het type applicatie. Enkel de servers op dezelfde tak in de netwerkboom worden bekeken. Dit

5.1 Basisscenario

43

betekent van DSLAM naar LEX en van LEX naar BRAS niveau, zie paragraaf 3.2.2 en figuur 4.1. In het basisscenario worden er geen beperkingen in servercapaciteit opgelegd. Cumulatieve kost In figuur 5.1 is de cumulatieve kost van het systeem weergegeven. Uit de figuur kunnen we afleiden dat de kost van de dienst toeneemt van 0% tot 100% business gebruikers. Dit kan verklaard worden omdat de business gebruiker vooral invloed heeft op de piekbelasting en naarmate het aantal stijgt zal de nodige capaciteit ook toenemen. Alle business gebruikers komen in de ochtend online en blijven gemiddeld 8 uur online. Bij residentiële gebruikers is dit gedistribueerd over de volledige dag. De daling bij 100% is toe te schrijven aan het wegvallen van de residentiële gebruikers met daarbij ook de kans op het voorkomen van de spel applicatie. De DSLAM servers zijn nu niet meer noodzakelijk waardoor een daling van de kost ontstaat.

Figuur 5.1: De cumulatieve kost van het systeem

Procent niet bediende gebruikers en gemiddeld aantal hops Het procent niet bediende gebruikers was 0%, dit is te wijten aan de oneindige server farm capaciteit. Bij de berekening van het gemiddeld aantal hops bekomen we hier de maximale waarde. Dit komt omdat de gebruiker met de server op het maximaal aantal hops verbonden wordt. Deze waarde is wel afhankelijk van de verhouding business gebruikers. Bij een business gebruiker is het gemiddeld aantal hops 2,95 en bij een residentiële is het

5.1 Basisscenario

44

2,5. Serverbezetting

Figuur 5.2: De totale serverbezetting

We bemerken hier geen optimale server bezetting. Dit komt vooral door het feit dat er 4500 DSLAM servers nodig zijn die enkel gebruikt worden voor de spel applicatie. Bij 80% in 2010 komt dit overeen met 36,7% van de totale servercapaciteit. Slechts 0,4% van die capaciteit wordt benut. Net present value analyse In figuur 5.3 bemerken we een vrij groot verschil in NPV waarde tussen 100% en 80% business gebruikers. Dit is deels te wijten door de kleinere cumulatieve kost bij 100% business gebruikers. In deze situatie moet er namelijk geen capaciteit voorzien worden ter hoogte van de DSLAMs. Een andere oorzaak is dat de adoptie van de business gebruikers sneller verloopt. Hierdoor zijn er over de vijf jaar meer gebruikers actief. De inkomsten worden per gebruiker berekend waardoor er bij 100% meer inkomsten zijn. Naarmate de verhouding verkleint, is de NPV in de eerste jaren minder negatief, behalve bij 100%. Bij het vergelijken van verhouding 60% en 40% merken we dat de NPV hoger is bij 40%, de kostenvermindering is sterker dan de inkomstenvermindering. Hierdoor stijgt de NPV waarde.

5.1 Basisscenario

45

Figuur 5.3: NPV analyse

In figuur 5.4 wordt de evolutie van de verhouding CapEx en OpEx getoond. In de eerste jaren is duidelijk te zien dat de CapEx kosten het zwaarst doorwegen. In 2012 bekomen we een omgekeerde situatie waar OpEx kosten het grootste deel zijn. Bij het uitrollen van de dienst zijn er grote investeringen nodig maar zijn de operationele kosten nog beperkt door het klein aantal gebruikers. Naarmate de adoptie stijgt zal de operationele kost stijgen.

Figuur 5.4: CapEx en OpEx evolutie bij 100% business gebruikers

5.2 Scenario met beperking van de servercapaciteit

5.2

46

Scenario met beperking van de servercapaciteit

In dit scenario bestuderen we de invloed van de beperking van de servercapaciteit op de economische haalbaarheid van het project. Er wordt nog steeds gebruik gemaakt van het standaard selectie algoritme. Indien er nu geen capaciteit aanwezig is of de server farm volzet is op een bepaald niveau, wordt de gebruiker met een server op het niveau lager verbonden. Door op bepaalde locaties geen servers te plaatsen kunnen we kosten besparen. Als we de capaciteit op een niveau beperken, zullen er meer gebruikers verbonden worden met de overblijvende servers. Hierdoor wordt de servercapaciteit beter benut. We proberen aan de hand van een strategie naar een optimale situatie te komen.

5.2.1

Geen servercapaciteit op LEX niveau

Bij deze strategie bestuderen we de invloed van het weglaten van servercapaciteit op LEX niveau. Wanneer een gebruiker een applicatie van maximaal twee hops wil uitvoeren, zal de gebruiker verbonden worden met een server op DSLAM niveau. De ingestelde capaciteiten zijn te zien in tabel 5.1. Tabel 5.1: Maximale servercapaciteit

Periode

BRAS

LEX

DSLAM

2008-2012

geen beperking

/

1500 MB

Cumulatieve kost Een verschil met figuur 5.1 is dat hier geen daling is bij 100% business gebruikers, zie figuur 5.5. Dit kan verklaard worden omdat de applicatie video bekijken nu niet op LEX niveau maar op DSLAM niveau wordt uitgevoerd. Bij de andere verhoudingen merken we een lichte daling van de cumulatieve kost. Een verklaring hiervoor is dat de bandbreedte nodig voor de video applicatie niet meer nodig is op de LEX-DSLAM link. Een vermindering van het aantal server farms levert ook een besparing van de kosten.


47


Procent niet bediende gebruikers en gemiddeld aantal hops Wegens de onbeperkte servercapaciteit op BRAS niveau en de voldoende capaciteit op DSLAM niveau kunnen alle gebruikers bediend worden. Het gemiddeld aantal hops daalt omdat de video applicatie nu op DSLAM niveau wordt uitgevoerd. Het gemiddeld aantal hops is gemiddeld 2,9 voor business gebruikers en 2,2 voor residentiële gebruikers. Serverbezetting In vergelijking met het basisscenario stijgt de serverbezetting met ongeveer 5% bij een verhouding van 80% business gebruikers in 2010. In deze situatie zijn er geen extra servers nodig op LEX niveau maar wordt de video applicatie ook op DSLAM niveau uitgevoerd. Hierdoor worden de DSLAM servers beter benut en kan er geen ongebruikte capaciteit zijn op LEX niveau.


48


Net present value analyse De grafische voorstelling van de NPV analyse is weergegeven in figuur 5.7. Bij een verhouding van 100% bemerken we een minder gunstige situatie door de extra kost van de servers op DSLAM niveau. Bij de andere percentages krijgen we een lichte verbetering van de NPV waarden t.o.v. het basisscenario. Dit kunnnen we verklaren door een gedaalde cumulatieve kost, door het weglaten van de servers op LEX niveau met de daarbij behorende netwerkkosten en onderhoudskosten.


49


5.2.2

Geen servercapaciteit op BRAS niveau

Een andere strategie is om geen servercapaciteit te voorzien op BRAS niveau. We trachten hiermee de linkcapaciteiten te beperken en onderzoeken wat de invloed is op de cumulatieve kost van het systeem. Een groot deel van de applicaties zal nu op een server dichter bij de gebruiker uitgevoerd worden. De toegekende servercapaciteit per niveau wordt getoond in tabel 5.2. Tabel 5.2: Maximale servercapaciteit

Periode

BRAS

LEX

DSLAM

2008-2012

/

geen beperking

1500 MB

Cumulatieve kost De cumulatieve kost van alle verhoudingen is weergegeven in figuur 5.8. We bemerken hier een daling van de cumulatieve kost bij een verhouding 100%. De oorzaak is analoog als die van het basisscenario, namelijk door het wegvallen van de residentiële gebruikers wordt de spel applicatie niet meer uitgevoerd, waardoor geen servers nodig zijn op DSLAM niveau. We kunnen ook besluiten dat er een algemene daling is van de kost voor alle verhoudingen.


50

De belangrijkste oorzaak hiervan is het wegvallen van de netwerkkosten tussen BRAS en LEX niveau.


Procent niet bediende gebruikers en gemiddeld aantal hops Door de oneindige capaciteit op LEX niveau en de voldoende capaciteit op DSLAM niveau voor het uitvoeren van de spel applicatie kunnen bij deze dimensionering alle gebruikers bediend worden. Indien we de capaciteit van de LEX server farms zouden beperken, kan dit leiden tot niet bediende gebruikers. Het gemiddeld aantal hops daalt hier in vergelijking met vorige strategie. In deze situatie wordt de gebruiker ofwel met een server op LEX of op DSLAM niveau verbonden. Het gemiddeld aantal hops bij 100% business gebruikers is 2 en bij 0% is het 1,9. Serverbezetting Door het weglaten van de servercapaciteit op BRAS niveau daalt de totale serverbezetting. De oorzaak hiervan is dat de grootste capapciteit nu niet meer gegroepeerd zit op 9 BRAS locaties maar op 90 LEX locaties. Hierdoor wordt er op 90 locaties wat extra capaciteit voorzien en omdat er gebruik gemaakt wordt van het server type 1, zie tabel 4.9, is de beschikbare server farm capaciteit een veelvoud van 25.000. Deze overcapaciteit kan verminderd worden door de capaciteit effectief te beperken. Die strategie wordt nog verder bestudeerd in het scenario met intelligentere server selectie algoritmes.


51


Net present value analyse Door een dalende cumulatieve kost bekomen we een gunstigere NPV analyse. Als we deze waarden vergelijken met voorgaande strategie bemerken we bij alle verhoudingen een stijging van de NPV waarde. Deze verbetering kan vooral verklaard worden door het verminderen van de operationele kosten.



5.2.3

52

Geen servercapaciteit op BRAS en LEX niveau

Na het beperken van eerst de LEX en vervolgens de BRAS capaciteit wordt nu de invloed bestudeerd van het beperken van beide. Het gevolg hiervan is dat de servers zich enkel op DSLAM niveau kunnen bevinden. Het gemiddeld aantal hops tussen gebruiker en server zal dus één bedragen. Doordat de servers zich nu aan de rand van het toegangsnetwerk bevinden is er geen netwerkcapaciteit meer nodig in het netwerk. We maken de veronderstelling dat op een DSLAM locatie slechts één server kan geplaatst worden. Wegens praktische redenen is het niet mogelijk om een volledig rack op DSLAM niveau te plaatsen. Hierdoor kiezen we best voor een bepaald type server die we eventueel na drie jaar kunnen vervangen in een ander type server. De gekozen capaciteiten zijn te zien in tabel 5.3. Tabel 5.3: Maximale servercapaciteit per periode

Periode

BRAS

LEX

DSLAM

2008-2010

/

/

6.000 MB

2011-2012

/

/

12.000 MB

Cumulatieve kost De sprong tussen 50% en 60% is te verklaren omdat voor de verhouding van 0% tot en met 50% in de tweede periode nog steeds de server van type drie volstaat. Boven de 50% wordt in die periode een server van het type twee geplaatst die een extra kost met zich meebrengt. Ondanks de besparingen op netwerkkosten bekomen we toch een grotere cumulatieve kost bij alle verhoudingen.


53


Procent niet bediende gebruikers en gemiddeld aantal hops In de grafiek van het aantal niet bediende gebruikers, zie figuur 5.12, is te zien dat bij een verhouding boven de 80% een groot deel van de gebruikers niet bediend kunnen worden. Dit komt omdat de business gebruikers niet uniform verdeeld zijn over het netwerk. Hierdoor worden bepaalde DSLAMs meer belast dan andere waardoor hun capaciteit sneller opgebruikt zal zijn. Het is dus niet efficiënt om op elke DSLAM een zelfde capaciteit te plaatsen.

Figuur 5.12: Procent niet bediende gebruikers


54

Serverbezetting In figuur 5.13 wordt de totale serverbezetting bij een verhouding van 80% getoond. Alhoewel er in deze periode een deel van de gebruikers niet bediend is, is er slechts een bezetting van 40%. Zoals reeds aangehaald, is dit te wijten door de niet uniforme verdeling van de business gebruikers. De distributies van de type gebruikers zijn ge¨ıllustreerd in paragraaf 4.2.5. Bij een verhouding van 80% in 2010 zal 1/3 van de servers een workload hebben van meer dan 95%. De overige servers hebben slechts een workload van ongeveer 10%.


Net present value analyse De NPV waarde daalt hier in vergelijking met de vorige strategieën. Dit kan verklaard worden door de hogere investeringskost van de servers. Deze kost valt dan in het eerste jaar en in het vierde jaar, begin tweede periode. Door die grote kost in het eerste jaar is de NPV van het eerste jaar negatiever dan die van de andere scenario’s.


55


5.2.4

Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau

Uit vorige strategie is gebleken dat een uniforme verdeling van de servercapaciteit op DSLAM niveau niet de gewenste resultaten opleverde. Om deze tekortkoming op te lossen verdelen we de DSLAM nodes in twee categorieën. Door de verdeling van de gebruikers over het netwerk, zie paragraaf 4.2.5, verbinden er zich via 1/3 van de DSLAMs meer gebruikers. Hierdoor worden deze DSLAMs meer belast dan de overige. Het idee is nu om bij de hoog belaste DSLAMs meer capaciteit te voorzien. De servercapaciteit die ingesteld wordt, is getoond in tabel 5.4. Bij alle verhoudingen wordt deze capaciteit voorzien. Tabel 5.4: Maximale servercapaciteit

Periode

2008-2012

BRAS

/

LEX

/

DSLAM

DSLAM

hoge belasting

lage belasting

12.000 MB

1.500 MB


56

Cumulatieve kost Deze strategie leidt tot een daling van de cumulatieve kosten t.o.v de vorige strategie. De totale kost kan nog verminderd worden voor de verhoudingen van 0% tot en met 40%. Bij deze verhoudingen kan men opteren voor een capaciteit van 6.000 MB bij de hoog belaste DSLAMs. Als we figuur 5.15 vergelijken met figuur 5.8 bemerken we dat hier de cumulatieve kost bij 100% hoger is dan in de strategie zonder BRAS niveau. De kost bij de verhoudingen van 70% tot en met 90% liggen hier lager dan bij de andere strategieën.


Procent niet bediende gebruikers en gemiddeld aantal hops Het gemiddeld aantal hops zal hier één bedragen. Het nadeel van enkel servers te plaatsen op DSLAM niveau is dat bij een werkbelasting van 100% de gebruiker niet meer bediend kan worden. Door de random generatie van de locatie van de gebruiker kan een bepaalde DSLAM iets meer belast worden dan een andere. Hierdoor kunnen bij de verhoudingen vanaf 70% enkele gebruikers niet bediend worden. De capaciteit van 1500 MB is dus maar net voldoende. Bij een verhouding van 100% in 2012 kan dit oplopen tot 0,09% van de gebruikers die niet bediend kunnen worden. Serverbezetting In figuur 5.16 zien we een maximale serverbezetting van 50% in 2010. Het is reeds verbeterd in vergelijking met een uniforme verdeling van de capaciteit. Toch leidt deze situatie tot


57

een onefficiënt gebruik van de servercapaciteit. Bij een verhouding van 100% kan de serverbezetting nog stijgen tot 60%.


Net present value analyse Uit de NPV analyse kunnen we besluiten dat deze strategie duidelijk tot een beter resultaat leidt dan de vorige strategie. Door het onderscheid te maken tussen hoog en laag belaste DSLAM servers kan een vermindering van de investeringskost bekomen worden. Door deze vermindering daalt de onderhoudskost ook, omdat dit berekend wordt op basis van de investeringskost.


58


5.2.5

Besluit

De strategie, optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau, biedt bij de hoge verhoudingen een verbetering t.o.v de andere strategieën. Toch zijn er een aantal beperkingen. Indien men deze strategie wil toepassen moet men perfect weten waar zich de DSLAMs met hoge belasting bevinden. De kostenbesparing van de netwerkkosten wordt soms overtroffen door de extra servercapaciteit die nodig is om een zelfde dienstverlening aan te bieden. Alleen servers plaatsen op DSLAM niveau is ook een minder flexibele oplossing. Wanneer men de dienst wil uitrollen, moet reeds de volledige capaciteit voorzien worden vanaf de eerste dag. Bij het groeperen van servers op LEX niveau kan men het volgend jaar gemakkelijk servers bijplaatsen indien dit nodig is. Uit de toegepaste strategieën is gebleken dat het efficiënter is om de server farm locaties op BRAS niveau weg te laten dan die op LEX niveau. De situatie waar de servers op BRAS niveau zijn weggelaten, kan nog verder geoptimaliseerd worden. Hier is de capaciteit op LEX niveau namelijk onbeperkt waardoor er na de simulatie op elke LEX locatie de maximaal nodige capaciteit wordt geplaatst. Indien we de capaciteit in dit scenario zouden beperken zou dit leiden tot een groot aantal niet bediende gebruikers. Om dit te verbeteren

5.3 Intelligentere server selectie algoritmes

59

trachten we in volgend scenario door het aanpassen van het server selectie algoritme deze situatie te verbeteren.

5.3

Intelligentere server selectie algoritmes

In vorig scenario werd enkel de server farm capaciteit van bepaalde niveaus beperkt. In volgend scenario wordt nu met behulp van de beste strategie van vorig scenario de invloed van het server selectie algoritme onderzocht. We trachten hier door de LEX capaciteit te beperken een betere situatie te bekomen. Bij een eerste strategie zal het gevorderd algoritme gebruikt worden. Vervolgens wordt de invloed van het geavanceerd algoritme onderzocht, voor meer informatie over de algoritmes zie paragraaf 3.2.2.

5.3.1

Gevorderd algoritme

Er is reeds aangehaald dat de nodige servercapaciteit op DSLAM niveau niet uniform verdeeld is. De mogelijkheid bestaat dus dat een een server volzet is en een gebruiker niet bediend kan worden. Indien de applicatie een maximale latency van drie hops kan hebben, is het mogelijk om die applicatie op een DSLAM server in een andere tak van het netwerk uit te voeren. De ingestelde maximale servercapaciteiten worden getoond in tabel 5.5. We merken hier wel op dat bij deze beperkingen er weinig verschil zal optreden bij de kleinere verhoudingen doordat de capaciteitsbeperking op LEX niveau te hoog is. Tabel 5.5: Maximale servercapaciteit per periode

Periode

BRAS

LEX

DSLAM

2008-2010

/

100.000 MB

1500 MB

2011-2012

/

125.000 MB

1500 MB

Cumulatieve kost Uit de grafiek met de cumulatieve kost kunnen we reeds besluiten dat deze strategie niet optimaal is bij een verhouding van 100%. Bij deze verhouding is het interessanter om geen capaciteit te plaatsen op DSLAM niveau. Bij de verhoudingen waar de capaciteitsbeperking zijn werk doet, bemerken we een daling van de cumulatieve kost t.o.v. de strategie waar er geen capaciteit was op het BRAS niveau.


60


Procent niet bediende gebruikers en gemiddeld aantal hops In figuur 5.19 is op te merken dat bij de hogere percentages wel kans is op niet bediende gebruikers. Dit kan verklaard worden omdat het selectie algoritme de gebruiker eerst zal proberen te verbinden met een server in zijn eigen tak. De servers aan de DSLAMs met hoge belasting zullen eerst volzet zijn. Indien een gebruiker dan een applicatie wil uitvoeren met een maximaal aantal hops kleiner dan drie zal die niet bediend kunnen worden. In onze situatie zal het gaan over de applicaties video bekijken en gaming.



61

Het gemiddeld aantal hops heeft een speciaal verloop waar de beperking van de servercapaciteit zijn effect heeft. In eerste instantie zal het gemiddeld aantal hops afnemen omdat er eerst zal verbonden worden met de DSLAM server op één hop van de gebruiker. Wanneer de DSLAM servers met hoge belasting volzet zijn, zal het gemiddeld aantal hops weer stijgen. Bijvoorbeeld bij 100% gaat dit van gemiddeld 2 hops in 2008 naar 1,9 hops in 2010 naar 1,97 hops in 2012. Serverbezetting De totale serverbezetting is duidelijk efficiënter dan bij de strategie zonder servercapaciteit op BRAS niveau, zie figuren 5.20 en 5.9. Door de servercapaciteitsbeperking op LEX niveau en het gevorderd server selctie algoritme wordt de servercapaciteit op LEX niveau voor 100% gebruikt en wordt de beschikbare capaciteit op DSLAM niveau beter benut.


Net present value analyse In vergelijking met het basisscenario bekomen we hier een betere NPV voor alle verhoudingen. In vergelijking met het scenario zonder BRAS capaciteit is er bij een verhouding van 100% een daling van de NPV waarde, door de capaciteitsbeperking is er nu wel capaciteit nodig op DSLAM niveau. Door de capaciteitsbeperking kunnen we bij een verhouding van 80% een kostenbesparing realiseren waardoor een hogere NPV waarde bekomen wordt.


62


5.3.2

Geavanceerd algoritme

Er is gebleken uit vorig scenario dat het niet efficiënt is om bepaalde DSLAM locaties meer te belasten. Wanneer een gebruiker via deze node een applicatie wil uitvoeren die een lagere latency vereist zal die niet bediend kunnen worden. Omwille van deze reden onderzoeken we nu het geavanceerd algoritme dat de DSLAM servers gelijkmatig belast. Het zal tot een beter bediening van de gebruikers leiden. De capaciteitsbeperkingen zijn weergegeven in tabel 5.6. Tabel 5.6: Maximale servercapapciteit per periode

Periode

BRAS

LEX

DSLAM

2008-2010

/

100.000 MB

1500 MB

2011-2012

/

125.000 MB

1500 MB

Cumulatieve kost Als we figuren 5.22 en 5.18 met elkaar vergelijken bemerken we een zelfde trend in het verloop. Bij het geavanceerd algoritme ligt de cumulatieve kost telkens iets hoger dan bij het gevorderd algoritme. Dit kan verklaard worden omdat er meer gebruikers verbonden


63

zullen worden met een server in een zijtak. Hierdoor ontstaat er meer netwerkverkeer waardoor de operationele kost stijgt.


Procent niet bediende gebruikers en gemiddeld aantal hops Door de aanpassing van het server selectie algoritme kunnen nu alle gebruikers bij alle verhoudingen bediend worden. Het zal nu niet meer gebeuren dat er vroegtijdig een DSLAM server volzet is en dat er dan geen gebruikers meer bediend kunnen worden, die een applicatie willen uitvoeren die maximaal twee of één hop kan hebben. Door deze aanpassing zal het gemiddeld aantal hops wel toenemen. Het selectie algoritme zoekt namelijk de server met de laagste werkbelasting. Hier zal het gemiddeld aantal hops niet eerst dalen zoals dit het geval was bij het gevorderd algoritme. Bijvoorbeeld bij 100% gaat dit van gemiddeld 2 hops naar 2,31 hops. Serverbezetting De serverbezetting kan bij bepaalde percentages een beetje stijgen t.o.v. het gevorderd algoritme omdat nu alle gebruikers bediend kunnen worden. In andere gevallen levert dit dezelfde serverbezetting op wegens eenzelfde dimensionering. We merken hier op dat de servercapaciteit zelf nog meer beperkt kan worden omdat de totale serverbezetting nu 71% bedraagt. De totale serverbezetting bij 100% business gebruikers bedraagt 87% in 2010 en dit zonder één niet bediende gebruiker.


64

Net present value analyse De NPV analyse in figuur 5.23 is een beetje gedaald in vergelijking met het gevorderd algoritme. Dit wordt veroorzaakt door de extra netwerkkost.


Optimalisatie We merkten op dat de serverbezetting bij een verhouding van 80% nog niet optimaal was, daarom is er nog een verdere capaciteitsbeperking toegepast op LEX niveau, zie tabel 5.7. Tabel 5.7: Maximale servercapapciteit per periode

Periode

BRAS

LEX

DSLAM

2008-2010

/

75.000 MB

1500 MB

2011-2012

/

100.000 MB

1500 MB

De NPV analyse voor 100% wordt niet weergegeven omdat er meer dan 8% niet bediend kunnen worden. Bij een verhouding van 80% kunnen alle gebruikers bediend worden. We bekomen dan een serverbezetting van 82% in het jaar 2010. Dit is een duidelijke verbetering t.o.v. vorige situatie. Wanneer de servercapaciteit op LEX niveau volzet is zal het gemiddeld aantal hops stijgen. Bij een verhouding van 80% gaat dit van gemiddeld 2


65

hops in 2008, naar 2,31 hops in 2010 en naar 2,25 hops in 2012. De daling in 2012 is te wijten aan de extra capaciteit op LEX niveau in 2012. Door de extra capaciteitsbeperking krijgen we ook een kostenbesparing. Dit vertaalt zich in een gunstigere NPV waarde, zie tabel D.15. we bekomen bij een verhouding van 80% een NPV van 80 miljoen ¤ in vergelijking met 76 miljoen ¤ in vorige situatie.

5.3.3

Geoptimaliseerd algoritme

Door de extra capaciteitsbeperking wordt de servercapaciteit nu goed benut. We constateren nu wel een hogere netwerkkost. Dit wordt veroorzaakt omdat een gebruiker meer kans heeft om met een server in een zijtak te verbinden. Om dit probleem te beperken is er een kleine optimalisatie van het geavanceerd algoritme gedaan. In plaats van direct naar de server met de laagste werkbelasting te zoeken wordt de server in dezelfde tak van de netwerkboom eerst tot een karakteristieke werkbelasting belast, hier gebruiken we 70%. Dit is een parameter die ingesteld kan worden. Daarna wordt pas naar de server met de kleinste werkbelasting gezocht. Deze werkwijze leidt tot een besparing van de netwerkkosten. Een tweede voordeel is een daling van het gemiddeld aantal hops. De gebruiker zal zo een hogere Quality of Service krijgen. Bij deze strategie worden dezelfde maximale servercapaciteiten gebruikt als in de vorige strategie, zie tabel 5.7. Procent niet bediende gebruikers en gemiddeld aantal hops Het procent niet bediende gebruikers verloopt analoog als bij het geavanceerd algoritme. Bij een verhouding van 80% kunnen ook alle gebruikers bediend worden. Het gemiddeld aantal hops is hier wel sterk verschillend. De evolutie in het aantal hops is gelijkaardig als bij het gevorderd algoritme. Bij een verhouding van 80% gaat dit van gemiddeld 2 hops, naar 1,9 hops naar 1,94 hops. Serverbezetting De serverbezetting bij 80% in 2010 is maximaal 82%, zie figuur 5.24. In 2012 gaat dit naar 88% totale serverbezetting. Zelfs bij deze bezetting kunnen nog alle gebruikers bediend worden.


66


Net present value analyse In figuur 5.25 wordt de NPV analyse weergegeven. Hieruit blijkt dat er inderdaad een verbetering is bekomen in vergelijking met vorige strategie. Door de manier van werken hebben we de extra netwerkkosten kunnen beperken. De NPV analyse bij 100% is hier niet relevant omdat door de extra servercapaciteitsbeperking zoals in voorgaande situatie er meer dan 8% niet bediend kunnen worden.

5.4 Wijzigen van het gebruikersprofiel

67


5.3.4

Besluit

Door gebruik te maken van het gevorderd selectie algoritme kon de LEX capaciteit beperkt worden zonder het aantal niet bediende gebruikers de hoogte in te jagen. Het is wel mogelijk dat er een aantal DSLAM servers vroegtijdig volzet raken door de niet uniforme verdeling van de serverbelasting op DSLAM niveau. Het geavanceerd algoritme biedt hier een oplossing voor. Door een betere capaciteitsspreiding over de DSLAMs kan men gaan naar een hogere serverbezetting zonder het laten dalen van de bedieningsgraad. Dit leidde wel tot een hoger netwerkbelasting. In een volgende strategie is hier nog een optimalisatie voor bedacht. Dit leidde tot een zelfde bedieningsgraad, met beperkte extra netwerkkosten. De Quality of Service steeg door een daling van het gemiddeld aantal hops.

5.4

Wijzigen van het gebruikersprofiel

In vorig scenario is er naar een optimale strategie gezocht. In dit scenario wordt eerst onderzocht wat de invloed is van een wijziging in het business profiel op de gekozen dimensionering. In een volgend puntje wordt de invloed van de online tijd van een residentiële gebruiker onderzocht. Tot slot bespreken we de gevolgen van het al dan niet aanbieden van de spel applicatie.


5.4.1

68

Wijzigen van het Business profiel

Als strategie voor het dimensioneren van het netwerk wordt gebruik gemaakt van het geoptimaliseerd algoritme zoals gedefinieerd in paragraaf 5.3.3. Het karakteristieke percentage van de werkbelasting is hier 70%. De nieuwe percentages van het profiel zijn weergegeven in tabel 5.8. We bepalen hier een profielwijziging waarin de gebruiker meer interactieve multimedia applicaties gaat uitvoeren zoals surfen en video bekijken. Tabel 5.8: Aangepast business profiel

Kantoortoepassingen

Surfen

Video bekijken

Spel

Oorspronkelijk

75%

20%

5%

0%

Gewijzigd

50%

35%

15%

0%

Procent niet bediende gebruikers en gemiddeld aantal hops In figuur 5.26 wordt het percentage van niet bediende gebruikers weergegeven. We kunnen hieruit afleiden dat er bij een verhouding van 80% wel niet bediende gebruikers zijn. In het jaar 2010 is dat 0,3% en in 2012 is dat 0,5%. Dit kan verklaard worden door het extra geheugengebruik omwille van het nieuwe profiel. Als we de output in meer detail bekijken, merken we op dat het vooral gebruikers zijn die van video of gaming gebruik willen maken. De verklaring hiervoor is dat de ingestelde parameter van de karakteristiek werkbelasting van het geoptimaliseerd algoritme te hoog is ingesteld. In een volgend puntje Verbetering zal de invloed van de wijziging van deze parameter bestudeerd worden.


69


Serverbezetting In vergelijking met het geoptimaliseerd algoritme bekomen we nu een totale serverbezetting van 88% in 2010, dit is een stijging van 6%. In 2012 loopt dit op tot 94%. De stijging in serverbezetting is te verklaren door de stijging van de nodige servercapaciteit. Net present value analyse De oorzaak van de daling van de NPV waarde is te verklaren door een stijgende operationele kost. Door het gewijzigde profiel wordt er meer gesurft en video bekeken waardoor de netwerkbelasting stijgt.


70


Verbetering Door de toename van het aantal video gebruikers, zijn er nu minder gebruikers die kunnen verbonden worden met een DSLAM server in een zijtak. Hierdoor is de karakteristieke werkbelastingsparameter te hoog ingesteld. Nu wordt die verlaagd van 70% naar 50%. In figuur 5.28 wordt het percentage niet bediende gebruikers getoond. We constateren hier een daling bij een verhouding van 80%. Het gaat van 0,3% naar 0,02% in 2010 en van 0,5% naar 0,08% in 2012. De serverbezetting is hier iets hoger omdat er nu een aantal gebruikers meer bediend kunnen worden. Het gemiddeld aantal hops neemt toe omdat er nu meer gebruikers verbinden met een server in een zijtak.


71


De NPV is nu ook iets lager maar de kwaliteit van de dienst is gestegen door een hogere bedieningsgraad.

5.4.2

Wijzigen online tijd residenti¨ ele gebruiker

In het scenario model is vastgelegd dat een residentiële gebruiker gemiddeld één uur actief is. Hierna bestuderen we de invloed van de wijziging van deze tijd. We maken opnieuw gebruik van de strategie beschreven in paragraaf 5.3.3. We kijken nu wat de invloed is van het wijzigen van de gemiddelde tijd naar drie uur. Capaciteitsverschil Door het verlengen van de online tijd gaan er nu op bepaalde ogenblikken meer gebruikers actief zijn. Hierdoor gaat er meer servercapaciteit nodig zijn. In tabel 5.9 wordt ge¨ıllustreerd hoeveel extra capaciteit er nodig is door de profielwijziging. Enkel bij zeer lage verhoudingen heeft de wijziging een grote invloed.


72

Tabel 5.9: De stijging van de nodige capaciteit

Verhouding

Procentuele stijging

0%

96,6%

20%

15,8%

80%

1,15%

De invloed blijft beperkt door de distributie van de aankomstfrequenties van de residentiële gebruiker. Elk uur komt er een klein percentage van de residentiële gebruikers actief. Bij de business gebruikers gebeurt dit eerder geconcentreerd in de morgen. Procent niet bediende gebruikers en gemiddeld aantal hops Bij een verhouding van 80% geeft dit geen grote verschillen met de situatie gebruikmakend van het geoptimaliseerd algoritme, zie paragraaf 5.3.3. Net present value analyse Uit de NPV analyse in figuur 5.29 volgt dat de situatie bij alle verhoudingen ongeveer gelijk is als de beginsituatie met het geoptimaliseerd algoritme.



5.4.3

73

Weglaten van de spel applicatie

Een belangrijke vraag die moet gesteld worden is het al dan niet aanbieden van de gaming dienst. Als de dienst dan wordt aangeboden is er ook de vraag over wie de meerkost zal moeten dragen. Om deze vragen te beantwoorden zal er eerst een simulatie uitgevoerd worden zonder de gaming dienst. Dit bekomen we door het percentage van de spel applicatie op nul te stellen en de andere percentages te herschalen. Door het weglaten van deze dienst zijn er geen servers meer nodig op DSLAM niveau. Uit voorgaande simulaties is gebleken dat het weglaten van de BRAS capaciteit de beste resultaten oplevert. Deze strategie wordt dan ook toegepast. Indien de capaciteit zou beperkt worden zou dit leiden tot een groot aantal niet bediende gebruikers omdat er geen capaciteit meer aanwezig is op DSLAM niveau. We opteren dus voor geen capaciteitsbeperking en dimensioneren de capaciteit volgens de maximaal nodige capaciteit op LEX niveau. Cumulatieve kost Het valt direct op dat de cumulatieve kosten bij de verschillende verhoudingen een heel stuk lager liggen. Bij een verhouding van 100% bekomen we hetzelfde resultaat als bij de strategie zonder BRAS capaciteit. Dit komt omdat business gebruikers geen gebruik maken van de spel applicatie.



74

Procent niet bediende gebruikers en gemiddeld aantal hops Alle gebruikers kunnen hier bediend worden omdat er een oneindige capaciteit is op het LEX niveau en de minimale toelaatbare latency van de aangeboden applicaties bedraagt twee hops. Alle servers bevinden zich op LEX niveau dus zal het gemiddeld aantal hops steeds twee zijn. Serverbezetting Omdat er op elke LEX locatie de maximaal nodige capaciteit voorzien wordt, zal er steeds wat overcapaciteit zijn. We merken wel op dat als we figuren 5.31 en 5.24 met elkaar vergelijken, we een zelfde serverbezetting bekomen. De extra capaciteit nodig op het LEX niveau wordt hier gecompenseerd door het weglaten van de capaciteit op DSLAM niveau. We constateren hier wel een hogere serverbezetting in het eerste jaar. Hier worden enkel servers geplaatst op LEX niveau, de servers zijn dus beter gegroepeerd, dit leidt tot een gelijkmatigere uitbreiding van het netwerk met minder overcapaciteit.


Net present value analyse Door het weglaten van de spel applicatie is het niet meer noodzakelijk om servercapaciteit te voorzien op DSLAM niveau. Deze weglating leidt tot een kostenbesparing wat zich vertaalt in een gunstigere NPV analyse.


75


Kostenanalyse In tabel C.10 is de kost per gebruiker van dit scenario voorgesteld. We kunnen deze kosten nu vergelijken met de kosten met het geoptimaliseerd algoritme, zie tabel C.9. Bij een verhouding van 80% bekomen we respectievelijk een kost van 255 ¤ en een kost van 277 ¤ per gebruiker per jaar. Vervolgens gaan we drie verschillende strategieën gebruiken voor de kostentoewijzing. In een eerste situatie verdelen we de extra kost onder alle gebruikers. In een tweede situatie verdelen we de kost enkel onder de residentiële gebruikers. Tot slot bekijken we de gaming dienst als een extra dienst waarop een deel van de residentiële gebruikers zich kan abonneren. 1. Onder alle gebruikers: Het gemiddelde verschil in kosten per gebruiker tussen het al dan niet aanbieden van de dienst is hier boven reeds vermeld. Het gaat hier om een extra kost van 22 ¤ en een gemiddelde kostprijs van 277 ¤. 2. Onder alle residentiële gebruikers: De dienst voor de business gebruikers kost 255 ¤ omdat zij geen gebruik maken van de spel applicatie. De extra kost van 22 ¤ per gebruiker zal nu gedragen moeten


76

worden door de residentiële gebruikers. Als gebruikersaantallen nemen we het cumulatieve aantal bij een verhouding van 80%, zie tabel A.1 en A.2. We bekomen dan een kost per residentiële gebruiker van 435 ¤1 per jaar. 3. Gaming apart abonnement: We veronderstellen dat er 30% van de residentiële gebruikers een gaming abonnement gaan nemen. De kost van een business gebruiker en van een residentiële zonder gaming abonnement zal terug 255 ¤ bedragen. De kost van het gaming abonnement wordt analoog berekend als in voorgaand puntje, alleen met andere gebruikersaantallen. We bekomen een kost van 853 ¤2 per jaar.

5.4.4

Besluit

In vorige sectie zijn de kosten voor een bepaald type gebruiker bepaald. Om te onderzoeken of deze kosten gerechtvaardigd zijn, wordt berekend welke kosten de gebruiker kan uitsparen bij het abonneren op een thin client dienst. Tabel 5.10: Kosten die wegvallen door een thin client dienst

Type kost

Business gebruiker

Residentiële gebruiker

gaming gebruiker

Office pakket3

186 ¤

186 ¤

186 ¤

Apparatuur

60 ¤

60 ¤

60 ¤

Energie

28 ¤

28 ¤

28 ¤

spel platform

0¤

0¤

100 ¤

spel dienst4

0¤

0¤

60 ¤

274 ¤

274 ¤

434 ¤

Totaal

De kost voor Office per jaar is berekend op basis van de aankoopprijs en een levensduur van 1

277 +

22 × 1346639 188328

2

277 +

3 4

http://www.hcw.be http://www.xbox.com/live

22 × (1346639 + 70% × 188328) 30% × 188328


77

drie jaar. Als er gebruik kan gemaakt worden van een thin client dienst kan er bespaard worden op de apparatuur. We schatten dit op 180 ¤ per toestel met een gebruiksduur van drie jaar. Hier is een basis thin client toestel vergeleken met een basis desktop model [32]. Door het gebruik van een thin client toestel kan er op energie bespaard worden. Als de spel applicatie nu niet meer op het toestel van de gebruiker moet uitgevoerd worden kan de gebruiker ook op speciale game apparatuur besparen. De extra prestatie die nodig zou zijn wordt geschat op 300 ¤ en dit ook voor drie jaar. Er kan ook gebruik gemaakt worden van een spel community zoals dit wordt aangeboden door Xbox Live. We concluderen dat voor een gebruiker zonder gaming ondersteuning de kost van de thin client dienst op hetzelfde niveau ligt als de kosten die hij kan besparen. Dit wijst op een haalbare situatie voor het uitrollen van de dienst. Er zijn ook nog een aantal moeilijk te kwantificeren voordelen die niet zijn opgenomen bij de berekening, zoals: De beheerskosten van de infrastructuur die nu niet meer voor eigen rekening zijn. De applicaties die virusvrij worden aangeboden. Het overal toegang hebben tot vertrouwde applicaties.

Als alle kosten van de gaming dienst worden toegewezen aan de gamer bekomen we een ongunstigere situatie. In deze situatie is de kost voor de thin client dienst hoger dan de kosten die de gebruiker uitspaart. Hierdoor zal het zeer moeilijk zijn om de gebruiker te overtuigen. Als de kost door alle gebruikers of residentiële gebruikers wordt gedragen is de situatie wel haalbaar. Door gebruik te maken van de strategie met het geoptimaliseerd algoritme kan een profielwijziging goed opgevangen worden. De gebruikers konden nog steeds bediend worden. In de nieuwe situatie was er wel meer bandbreedte nodig waardoor de netwerkkosten stegen. Dit had zijn effect op de NPV analyse. De online tijd van een residentiële gebruiker heeft niet zoveel effect op de dimensionering van het systeem. Dit komt door de sterk verdeelde aankomst frequenties van de residentiële gebruikers. Bij business gebruikers zijn de aankomst frequenties geconcentreerd in de ochtend waardoor kort na de middag een piekbelasting kan ontstaan wanneer alle gebruikers actief zijn. In het geval bij residentiële gebruikers is dit bijna onmogelijk omdat

5.5 Conclusie

78

een gebruiker 24 uur online zou moeten zijn eer een piekbelasting kan ontstaan wanneer iedereen online is.

5.5

Conclusie

Het basisscenario gaf een eerste kijk op het totale kostenplaatje voor het uitrollen van de thin client dienst. Er werd een eerste NPV analyse berekend die bij alle verhoudingen positief was. De verhouding tussen de CapEx en de OpEx werd ook in kaart gebracht. Er werd besloten dat de CapEX de eerste jaren hoger is dan de Opex maar na verloop van tijd de OpEx het grootste deel inneemt. In het scenario met beperking van servercapaciteit werd de invloed onderzocht van het weglaten van servercapaciteit op een netwerkniveau. Het groeperen van de servers op niveau 2 resulteerde in een beter resultaat dan alle servers op het laagste niveau te plaatsen. Dit was vooral te wijten aan de niet uniforme verdeling van de gebruikers. Uit simulaties bleek dat er weinig winst was om de servers tot op BRAS niveau te plaatsen. De extra netwerkcapaciteit was hier niet te verantwoorden. De meest efficiënte wijze was om de servers op LEX en DSLAM niveau te plaatsen. Dit leidde niet tot een optimale serverbezetting. Enkel indien de servercapaciteit op LEX en DSLAM niveau zou beperkt worden, zou dit leiden tot niet bediende gebruikers. Om dit te verhelpen is er gezocht naar betere server selectie algoritmes. Door het toepassen van betere selectie algoritmes kon de servercapaciteit in het netwerk verminderd worden zonder de Quality of Service van de dienst te veranderen. Bij het gevorderd algoritme constateerden we dat het niet gunstig was om bepaalde servers op het laagste niveau volledig te belasten. Hierdoor kunnen andere gebruikers niet meer bediend worden. Het geavanceerd algoritme gaf hier een oplossing voor. Dit leidde tot een betere bediening van de gebruikers, alleen de netwerkbelasting en het gemiddeld aantal hops steeg. Om deze beperkingen weg te werken, werd een kleine aanpassing gedaan waardoor de netwerkbelasting en het gemiddeld aantal hops daalde, dit bracht ons tot het geoptimaliseerd algoritme. In een volgend scenario werd de invloed van de wijziging van het profiel onderzocht. De gekozen dimensionering met het geoptimaliseerd algoritme kon de wijziging in het business

5.5 Conclusie

79

profiel goed opvangen. Door de profielwijziging was er wel extra netwerkcapaciteit nodig waardoor de operationele kosten stegen. Vervolgens werd ook nog de invloed van de online tijd van de residentiële gebruiker bekeken. De invloed daalde sterk bij een kleine toename van de verhouding business gebruikers. Bij een gemiddelde online tijd van 3 uur was er bijna tweemaal zoveel servercapaciteit nodig bij 100% residentiële gebruikers. Tot slot werd de invloed van het weglaten van de spel applicatie bestudeerd. Als de extra kost voor het aanbieden van deze dienst gedragen moet worden door de gamer kan deze dienst niet rendabel zijn. Als er op LEX en DSLAM niveau servers voorzien worden en de kost wordt onder alle gebruikers verdeeld kan de spel applicatie wel aangeboden worden.

BESLUIT EN TOEKOMSTPERSPECTIEVEN

80

Hoofdstuk 6

Besluit en toekomstperspectieven In dit werk werd een model opgesteld voor de dimensionering van een thin client netwerk. Om een correcte dimensionering te bekomen werd een simulator ontwikkeld. Met deze tool konden we een aantal specifieke scenario’s uitvoeren. Om de realiteit zo goed mogelijk te simuleren werden een aantal parameters gedefinieerd, zoals de bandbreedte, het geheugengebruik, toegelaten latency en netwerktopologie. Het scenariomodel bevatte de populatie, de aankomstfrequenties, de adoptie, de online tijd, de distributie over het netwerk en het gebruikersprofiel. Na het dimensioneren van het netwerk werd een economische analyse uitgevoerd. Aan de hand van de output van de simulator, het gedefinieerde kostenmodel en het economisch model kon een meerjaren analyse berekend worden. Via deze analyse waren we in staat de verschillende strategieën met elkaar te vergelijken. Via het scenario met beperking van de servercapaciteit konden we onderzoeken welke strategie het best presteerde. Hier concludeerden we dat het economisch minder interessant was om veel capaciteit op BRAS niveau te plaatsen. De netwerkkosten liepen hier te hoog op. Het was interessanter om de servers te groeperen op LEX niveau. Indien men applicaties wil aanbieden met een maximale latency van 1 hop is het wel nodig om ook de servers op DSLAM niveau te plaatsen. Alleen servers op DSLAM niveau plaatsen leidt echter tot een te hoge servercapaciteit met daardoor een te hoge investeringskost. Indien bij het basisscenario de capaciteit op LEX niveau te veel werd beperkt, had dit een lage bedieningsgraad tot gevolg. In het scenario met intelligentere server selectie algoritmes onderzochten we of de dimen-


81

sionering verbeterd kon worden in functie van de economische haalbaarheid. Door middel van een efficiënt selectie algoritme kon de capaciteit op LEX niveau beperkt worden om zo een betere serverbezetting te bereiken. In het laatste scenario werden een aantal profielwijzigingen toegepast en de invloed op de dimensionering bestudeerd. Indien het business profiel evolueert naar meer multimedia intensievere applicaties zal dit vooral een hogere netwerkkost tot gevolg hebben. De nodige servercapaciteit werd minder be¨ınvloed. Bij het wijzigen van het profiel ging de aandacht vooral naar het wel of niet aanbieden van de spel applicatie. Door het niet aanbieden van deze dienst kon een serieuze kost bespaard worden. Na verdere analyse bleek dat indien de extra kost verdeeld werd onder alle gebruikers de case nog haalbaar was. Indien de kosten enkel door de gebruikers van de extra dienst gedragen werd, leidde dit tot een economisch onverantwoorde situatie. De kost per gebruiker was namelijk beduidend hoger dan de kostenvermindering die de gebruiker kon bereiken door gebruik te maken van die dienst. Een aanvulling op deze scriptie kan een technisch onderzoek zijn over het quantificeren van de cpu parameter voor verschillende applicaties. Op basis van deze parameter kunnen de selectie algoritmes soms een andere beslissing nemen. Voor bepaalde applicaties zal deze parameter echter moeilijk te bepalen zijn. Dit komt door de variaties in de tijd en doordat sommige applicaties alle systeembronnen gebruiken die beschikbaar zijn. Er moet dan onderzocht worden hoeveel applicaties er parallel uitgevoerd kunnen worden. Indien de cpu parameter dan beter bepaald is kan er onderzocht worden wat de invloed is van het aanbieden van meer performante games. Dit zijn typische applicaties waar het cpu gebruik de belangrijkste parameter zal zijn bij de dimensionering van het systeem. Om tot een beter gefundeerde conclusie te komen is het interessant om de economische studie aan te vullen met een uitgebreid marktonderzoek. Aan de hand van de bepaalde populatie kan misschien wel besloten worden dat het een haalbaar project is maar als de markt er niet klaar voor is zou het toch gedoemd zijn te mislukken. Het scenariomodel bevat reeds een typische verdeling van de gebruikers over het netwerk voor de verschillende types. Deze ingevoerde vorm van mobiliteit is nogal statisch. Dit kan uitgebreid worden naar een volledige portabiliteit van het toestel. Dan is het van belang dat de dienst ondersteund kan worden tijdens de verplaatsing van de gebruiker.


82

Om dit te ondersteunen zijn er bewegingspatronen nodig die moeilijk te bepalen zijn. Het netwerk zal ook applicatie emigratie moeten ondersteunen voor een betere dienstverlening naar de gebruiker toe.

ADOPTIE WAARDEN

83

Bijlage A

Adoptie waarden Tabel A.1: Adoptie waarden voor business gebruiker

Business gebruiker 2008

2009

2010

2011

2012

0

0

0

0

0

10%

10.420

26.427

38.582

44.998

47.903

20%

20.840

52.854

77.164

89.997

95.805

30%

31.259

79.282

115.746

134.995

143.708

40%

41.679

105.709

154.328

179.993

191.611

50%

52.099

132.136

192.909

224.991

239.513

60%

62.519

158.563

231.491

269.990

287.416

70%

72.939

184.991

270.073

314.988

335.319

80%

83.359

211.418

308.655

359.986

383.221

90%

93.778

237.845

347.237

404.984

431.124

100%

104.198

264.272

385.819

449.983

479.027

0%

ADOPTIE WAARDEN

84

Tabel A.2: Adoptie waarden voor Residentiële gebruiker

Residenti¨ ele gebruiker 2008

2009

2010

2011

2012

100%

18.074

80.841

183.940

288.818

369.967

90%

16.267

72.757

165.546

259.936

332.970

80%

14.459

64.673

147.152

231.054

295.974

70%

12.652

56.589

128.758

202.173

258.977

60%

10.845

48.505

110.364

173.291

221.980

50%

9.037

40.421

91.970

144.409

184.984

40%

7.230

32.337

73.576

115.527

147.987

30%

5.422

24.252

55.182

86.645

110.990

20%

3.615

16.168

36.788

57.764

73.993

10%

1.807

8.084

18.394

28.882

36.997

0

0

0

0

0

0%

DE TOTALE SERVERCAPACITEIT

Bijlage B

De totale servercapaciteit

Figuur B.1: De totale servercapacitiet gedurende een dag bij 0% businness gebruikers

85




86




87



88

KOST PER GEBRUIKER

89

Bijlage C

Kost per gebruiker Tabel C.1: De kost per gebruiker per jaar in het basis scenario

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

351

0

351

10%

341

503

309

20%

338

448

289

30%

327

410

263

40%

324

385

251

50%

321

368

238

60%

319

352

228

70%

316

339

219

80%

309

323

203

90%

307

314

196

100%

277

277

0

KOST PER GEBRUIKER

90

Tabel C.2: De kost per gebruiker per jaar in het scenario zonder LEX capaciteit

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

345

0

345

10%

336

485

306

20%

332

435

286

30%

321

399

261

40%

319

377

249

50%

315

360

236

60%

313

345

226

70%

310

332

217

80%

302

316

200

90%

301

307

194

100%

299

299

0

Tabel C.3: De kost per gebruiker per jaar in het scenario zonder BRAS capaciteit

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

346

0

346

10%

336

490

305

20%

330

432

284

30%

314

387

258

40%

308

360

245

50%

304

344

233

60%

300

329

222

70%

295

315

214

80%

285

297

197

90%

281

287

190

100%

250

250

0

KOST PER GEBRUIKER

91

Tabel C.4: De kost per gebruiker per jaar in het scenario zonder BRAS en LEX capaciteit

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

388

0

388

10%

370

645

316

20%

355

506

288

30%

335

434

259

40%

324

390

245

50%

314

360

231

60%

328

367

224

70%

319

344

214

80%

304

319

196

90%

297

304

189

100%

290

290

0

Tabel C.5: De kost per gebruiker per jaar in het scenario met hoge en lage DSLAM capaciteit

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

376

0

376

10%

359

597

312

20%

345

478

285

30%

325

414

258

40%

315

374

243

50%

305

347

230

60%

296

326

219

70%

289

308

210

80%

276

288

192

90%

270

275

185

100%

264

264

0

KOST PER GEBRUIKER

92

Tabel C.6: De kost per gebruiker per jaar in het scenario met gevorderd algoritme

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

349

0

349

10%

336

489

305

20%

330

433

284

30%

314

388

258

40%

308

360

245

50%

304

344

233

60%

298

326

222

70%

292

311

213

80%

281

293

196

90%

276

281

188

100%

267

267

0

Tabel C.7: De kost per gebruiker per jaar in het scenario met geavanceerd algoritme

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

349

0

349

10%

336

489

305

20%

330

432

284

30%

314

387

258

40%

308

360

245

50%

304

344

233

60%

298

326

222

70%

293

313

213

80%

282

294

196

90%

277

282

189

100%

269

269

0

KOST PER GEBRUIKER

93

Tabel C.8: De kost per gebruiker per jaar in het scenario met geavanceerd algoritme en extra beperking

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

349

0

349

10%

336

490

305

20%

330

432

284

30%

314

387

258

40%

308

360

245

50%

302

342

232

60%

296

324

221

70%

290

309

213

80%

279

290

195

90%

274

280

188

100%

265

265

0

Tabel C.9: De kost per gebruiker per jaar in het scenario met geoptimaliseerd algoritme

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

349

0

349

10%

336

491

306

20%

330

433

284

30%

314

387

258

40%

308

360

245

50%

302

341

232

60%

295

322

221

70%

289

307

212

80%

277

289

195

90%

272

277

188

100%

264

264

0

KOST PER GEBRUIKER

94

Tabel C.10: De kost per gebruiker per jaar in het scenario zonder 3D-spel

Kost/Gebruiker

Kost/Business

Kost/Residentiële

[¤]

[¤]

[¤]

0%

300

0

300

10%

290

380

272

20%

288

357

256

30%

274

328

233

40%

270

311

222

50%

269

301

212

60%

266

290

203

70%

263

280

195

80%

255

266

179

90%

252

257

173

100%

251

251

0

NET PRESENT VALUE

95

Bijlage D

Net Present Value D.1

Basisscenario Tabel D.1: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

72.337

13.025

85.362

37.511

-47.850

2009

94.075

31.088

125.162

95.138

-75.145

2010

60.534

44.519

105.052

138.895

-47.176

2011

32.520

51.254

83.774

161.994

11.591

2012

12.682

54.979

67.661

172.450

83.163

Tabel D.2: De totale NPV bij 80% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

68.975

17.347

86.322

31.527

-54.795

2009

85.033

32.813

117.846

82.901

-86.563

2010

61.680

45.301

106.981

126.567

-70.377

2011

36.677

52.813

89.490

153.856

-22.018

2012

16.810

56.304

73.114

169.037

43.499

D.2 Scenario met beperking van de servercapaciteit

D.2 D.2.1

96

Scenario met beperking van de servercapaciteit Geen servercapaciteit op LEX niveau Tabel D.3: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

78.072

18.727

96.799

37.511

-59.287

2009

93.535

36.224

129.759

95.138

-90.761

2010

60.264

49.529

109.793

138.895

-66.709

2011

38.730

56.293

95.023

161.994

-16.393

2012

11.872

59.549

71.422

172.450

52.610


D.2.2

CapEx

OpEx

Total

Revenues

NPV

2008

67.960

16.654

84.614

31.527

-53.086

2009

84.763

31.655

116.418

82.901

-83.556

2010

61.410

43.539

104.949

126.567

-65.690

2011

35.867

50.887

86.754

153.856

-15.275

2012

16.540

54.220

70.760

169.037

51.849

Geen servercapaciteit op BRAS niveau Tabel D.5: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

72.566

9.908

82.474

37.511

-44.962

2009

94.736

23.589

118.325

95.138

-66.042

2010

60.648

34.036

94.684

138.895

-29.504

2011

32.796

39.335

72.131

161.994

38.011

2012

12.304

41.734

54.038

172.450

118.888

D.2 Scenario met beperking van de servercapaciteit

97


D.2.3

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

15.015

84.867

31.527

-53.340

2009

84.932

26.985

111.917

82.901

-79.718

2010

62.442

36.593

99.036

126.567

-56.965

2011

37.764

42.544

80.307

153.856

-1.707

2012

16.108

45.406

61.514

169.037

71.732

Geen servercapaciteit op BRAS en LEX niveau Tabel D.7: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

94.771

15.749

110.520

37.511

-73.009

2009

88.256

26.630

114.886

95.138

-90.961

2010

56.328

34.846

91.174

138.895

-51.523

2011

80.316

41.907

122.223

161.994

-21.643

2012

5.824

43.878

49.702

172.450

62.195


CapEx

OpEx

Total

Revenues

NPV

2008

85.307

14.577

99.884

31.527

-68.357

2009

80.612

24.103

104.715

82.901

-88.188

2010

58.122

32.122

90.244

126.567

-58.169

2011

78.534

39.705

118.239

153.856

-31.409

2012

11.788

42.380

54.168

169.037

47.048

D.3 Intelligentere server selectie algoritmes

D.2.4

98

Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau Tabel D.9: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

90.271

15.299

105.570

37.511

-68.059

2009

88.256

26.180

114.436

95.138

-85.602

2010

56.328

34.396

90.724

138.895

-45.792

2011

48.816

38.757

87.573

161.994

10.121

2012

5.824

40.728

46.552

172.450

96.111


D.3 D.3.1

CapEx

OpEx

Total

Revenues

NPV

2008

80.807

14.127

94.934

31.527

-63.407

2009

80.612

23.653

104.265

82.901

-82.829

2010

58.122

31.672

89.794

126.567

-52.438

2011

47.034

36.555

83.589

153.856

355

2012

11.788

39.230

51.018

169.037

80.963

Intelligentere server selectie algoritmes Gevorderd algoritme Tabel D.11: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

72.566

9.864

82.430

37.511

-44.919

2009

99.326

29.777

129.103

95.138

-75.796

2010

56.328

39.607

95.935

138.895

-40.292

2011

32.796

45.058

77.854

161.994

22.923

2012

16.894

47.435

64.330

172.450

96.771

D.3 Intelligentere server selectie algoritmes

99


D.3.2

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

14.913

84.765

31.527

-53.238

2009

84.932

26.865

111.796

82.901

-79.506

2010

58.122

35.642

93.764

126.567

-52.397

2011

37.764

41.725

79.489

153.856

3.476

2012

16.108

45.109

61.217

169.037

77.119

Geavanceerd algoritme Tabel D.13: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

72.566

9.881

82.447

37.511

-44.936

2009

99.326

30.198

129.523

95.138

-76.195

2010

56.328

40.239

96.567

138.895

-41.213

2011

32.796

45.894

78.690

161.994

21.374

2012

16.894

47.977

64.871

172.450

94.851


CapEx

OpEx

Total

Revenues

NPV

2008

69.852

15.041

84.893

31.527

-53.366

2009

84.932

26.959

111.890

82.901

-79.719

2010

58.122

36.639

94.761

126.567

-53.434

2011

37.764

42.115

79.878

153.856

2.146

2012

16.108

45.506

61.614

169.037

75.517

D.4 Wijzigen van het gebruikersprofiel

100

Optimalisatie door extra capaciteitsbeperking


D.3.3

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

13.202

84.832

31.527

-53.304

2009

82.772

23.093

109.490

82.901

-77.476

2010

58.122

31.112

94.449

126.567

-50.933

2011

37.764

36.320

79.860

153.856

4.661

2012

13.948

38.994

59.038

169.037

79.791

Geoptimaliseerd algoritme Tabel D.16: De totale NPV bij 80% business gebruikers in duizend ¤

D.4 D.4.1

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

15.051

84.903

31.527

-53.375

2009

82.772

26.119

108.891

82.901

-77.003

2010

58.122

35.679

93.801

126.567

-49.923

2011

37.764

41.430

79.194

153.856

6.171

2012

13.948

44.549

58.497

169.037

81.671

Wijzigen van het gebruikersprofiel Wijzigen van het Business profiel Tabel D.17: De totale NPV bij 80% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

15.699

85.551

31.527

-54.023

2009

82.772

27.558

110.329

82.901

-78.958

2010

58.122

37.266

95.388

126.567

-53.191

2011

37.764

43.497

81.261

153.856

1.351

2012

13.948

46.772

60.720

169.037

75.332

D.4 Wijzigen van het gebruikersprofiel

D.4.2

101

Wijzigen online tijd residenti¨ ele gebruiker Tabel D.18: De totale NPV bij 80% business gebruikers in duizend ¤

D.4.3

CapEx

OpEx

Total

Revenues

NPV

2008

69.852

14.918

84.770

31.527

-53.243

2009

82.772

26.388

109.160

82.901

-77.114

2010

58.122

35.832

93.955

126.567

-50.162

2011

37.764

41.454

79.217

153.856

5.915

2012

13.948

44.623

58.571

169.037

81.365

Weglaten van de spel applicatie Tabel D.19: De totale NPV bij 100% business gebruikers in duizend ¤

CapEx

OpEx

Total

Revenues

NPV

2008

72.566

9.828

82.393

37.511

-44.882

2009

94.736

23.717

118.452

95.138

-66.077

2010

60.648

34.162

94.811

138.895

-29.644

2011

32.796

39.245

72.041

161.994

37.939

2012

12.304

41.734

54.038

172.450

118.815


CapEx

OpEx

Total

Revenues

NPV

2008

63.102

8.536

71.638

31.527

-40.110

2009

84.932

20.147

105.078

82.901

-60.272

2010

62.442

30.159

92.601

126.567

-32.201

2011

31.014

36.067

67.081

153.856

32.995

2012

16.108

39.038

55.146

169.037

110.784

INHOUD VAN DE DVD

Bijlage E

Inhoud van de DVD De simulator Het scriptieboek De broncode van het scriptieboek De output van de simulaties

102

BIBLIOGRAFIE

103

Bibliografie [1] “NetPC,” http://www.computable.nl/artikel/nieuws/207613/250449/ intel-en-microsoft-specificeren-netpc.html [2] “Wyse,” http://www.wyse.com/ [3] “JackPC,” http://www.jadeintegration.com/jackpc.php [4] “BeTwin,” http://www.thinsoftinc.com/ [5] “Cult,” http://cult-thinclient.sourceforge.net/ [6] “SoThin,” http://www.sothin.net [7] “Wikipedia,” http://en.wikipedia.org/. [8] “Client/server architectuur,” http://www.rdbprime.com/Oracle/Oracle Docs/ Oracle9iDB Server/server.920/a96524/c07dstpr.htm. [9] W. Stallings, “Operating Systems,” Prentice-Hall, pp. 576-586, 2003. [10] “Thin client networking,” http://foi.becta.org.uk/content files/corporate/resources/ technology and education research/thin client.pdf, Becta, 2005. [11] “Thin Client: energie besparing,” http://weblog.infoworld.com/sustainableit/archives/ 2008/03/lower energy bi.html?source=rss [12] D. De Winter, P. Simoens, L. Deboosere, F. De Turck, J. Moreau, B. Dhoedt, P. Demeester, “A Hybrid Thin-Client protocol for Multimedia Streaming and Interactive Gaming Applications,” the Proceedings of NOSSDAV2006 2006. [13] A. Volchkov, March 2002.

“Server-Based Computing Opportunities,”

in IT Pro, pp. 18-23,

BIBLIOGRAFIE

104

[14] “Citrix,” http://www.citrix.com. [15] “Windows Remote Desktop Protocol (RDP),”

http://msdn2.microsoft.com/en-

us/library/aa383015.aspx. [16] “Virtual Desktop Infrastructure,” http://www.vmware.com/products/vdi [17] L. Deboosere, J. De Wachter, P. Simoens, F. De Turck, B. Dhoedt, P. Demeester, “Thin Client Computing Solutions in Low- and High-Motion Scenarios,” the Proceedings of the International Conference on Networking and Services (ICNS), 2007. [18] T. Richardson, Q. Stafford-Fraser, K. R. Wood, A. Hopper, “Virtual Network Computing,” IEEE Internet Computing, vol. 2, no. 1, pp. 33-38, Jan/Feb 1998. [19] “TightVNC,” http://www.tightvnc.com/intro.html [20] K. Casier, S. Verbrugghe, D. Colle, M. Pickavet and P. Demeester, “Using AspectOriented Programming for Event-Handling in a Telecom Research Software Library,” In Poster presentation at ICSR-8, the 8th International Conference on Software Reuse, Spain, 2004. [21] L. Deboosere, P. Simoens, D. De Winter, F. De Turck, B. Dhoedt, P. Demeester, “Dimensioning a Wide-Area Thin Client Computing Network supporting Mobile Users,” the Proceedings of the International Conference on Networking and Services (ICNS), July 2006. [22] “VLC media player,” http://videolan.org/ [23] “Age of Empires: The Age of Kings,” http://www.microsoft.com/games/age2/ features.htm [24] “SWAT 3,” http://www.swat3.com/overview/main.html [25] “WAN monitoring whitepaper,” http://manageengine.adventnet.com/products/ opmanager/wan-white-paper.pdf [26] “Maximum latency bij thin clients,” http://www.msterminalservices.org/articles/PoorBandwidth-Latency.html

BIBLIOGRAFIE

105

[27] B. Vankeirsbilck, “Comparison of XRDP and other existing thin client protocols,” Mobithin, WP 3, Action point 3.6, Jan 2008. [28] J. V. Gregg, C. H. Hossel, , J. T. Richardson, “Mathematical trend curves: An aid to forecasting,” Edinburgh: Oliver and Boyd, 1964. [29] “Aankomst -en vertrektijden van werknemers,” http://www.mobilit.fgov.be/data/ mobil/rapportWWVn.pdf [30] “Media consumption study,” http://www.online-publishers.org/media/ 142 W opa media consumption study may03.pdf [31] “Microsoft Office 2003 Application Scalability Analysis,” http://www.netvoyager.co.uk/pdf/Office Scalability Analysis Citrix.pdf [32] “Hewlett-Packard (HP),” http://www.hp.be [33] “TCO model voor thin clients,” http://www.principledtechnologies.com/Clients/ Reports/Intel/ComputeModelTCOCalc1107.xls [34] R. A. Baratto, L. N. Kim, J. Nieh, “Thinc: A Virtual Display Architecture for Thin-Client Computing,” in Twentieth ACM symposium on operating system, 2005. [35] J. Nieh, A. M. Lai, “On the Performance of Wide-Area Thin-Client Computing,” in ACM Transactions on Computer Systems (TOCS), vol. 24, pp. 175-209, 2006.

LIJST VAN FIGUREN

106

Lijst van figuren 2.1

Thin clients en servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

De verschillende client/server architecturen . . . . . . . . . . . . . . . . . .

5

2.3

Thin Client werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4

Server-based computing [13] . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.5

Citrix configuratie [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.6

Virtual Desktop Infrastructure [16] . . . . . . . . . . . . . . . . . . . . . . . 10

2.7

Centrale serverplaatsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.8

Decentrale serverplaatsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1

Architectuur van de simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2

Server toewijzing bij standaard algoritme . . . . . . . . . . . . . . . . . . . 19

3.3

Server toewijzing bij gevorderd algoritme . . . . . . . . . . . . . . . . . . . 19

3.4

Server toewijzing bij geavanceerd algoritme . . . . . . . . . . . . . . . . . . 20

3.5

Volgorde van de gegenereerde gebeurtenissen . . . . . . . . . . . . . . . . . 22

4.1

Netwerktopologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2

Adoptie curves bij 40% business gebruikers . . . . . . . . . . . . . . . . . . 31

4.3

Adoptie curves bij 80% business gebruikers . . . . . . . . . . . . . . . . . . 32

4.4

Aankomstdistributie van de gebruikers in % van de populatie . . . . . . . . 33

4.5

Verdeling van de gebruikers over het netwerk . . . . . . . . . . . . . . . . . 34

5.1

De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 43

5.2

De totale serverbezetting

5.3

NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4

CapEx en OpEx evolutie bij 100% business gebruikers . . . . . . . . . . . . 45

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

LIJST VAN FIGUREN

107

5.5


5.6


5.7

NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.8


5.9


. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.10 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.11 De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 53 5.12 Procent niet bediende gebruikers . . . . . . . . . . . . . . . . . . . . . . . . 53 5.13 De totale serverbezetting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.14 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.15 De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 56 5.16 De totale serverbezetting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.17 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.18 De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 60 5.19 Procent niet bediende gebruikers . . . . . . . . . . . . . . . . . . . . . . . . 60 5.20 De totale serverbezetting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.21 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.22 De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 63 5.23 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.24 De totale serverbezetting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.25 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.26 Procent niet bediende gebruikers . . . . . . . . . . . . . . . . . . . . . . . . 69 5.27 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.28 Procent niet bediende gebruikers . . . . . . . . . . . . . . . . . . . . . . . . 71 5.29 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.30 De cumulatieve kost van het systeem . . . . . . . . . . . . . . . . . . . . . . 73 5.31 De totale serverbezetting

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.32 NPV analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 B.1 De totale servercapacitiet gedurende een dag bij 0% businness gebruikers

. 85

B.2 De totale servercapacitiet gedurende een dag bij 20% businness gebruikers . 86 B.3 De totale servercapacitiet gedurende een dag bij 40% businness gebruikers . 86 B.4 De totale servercapacitiet gedurende een dag bij 60% businness gebruikers . 87

LIJST VAN FIGUREN

108

B.5 De totale servercapacitiet gedurende een dag bij 80% businness gebruikers . 87 B.6 De totale servercapacitiet gedurende een dag bij 100% businness gebruikers

88

LIJST VAN TABELLEN

109

Lijst van tabellen 4.1

Nodige bandbreedte in kbps per gebruiker, resolutie van 1280x1024 . . . . . 27

4.2

Input parameters voor de bandbreedte . . . . . . . . . . . . . . . . . . . . . 27

4.3

WAN latency gegevens [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4

Toelaatbare latency [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5

Maximaal toelaatbare latency . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6

Geheugen gebruik per type applicatie

4.7

Adoptie parameters

4.8

Gebruikersprofielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.9

Dimensionering van de type servers [32] . . . . . . . . . . . . . . . . . . . . 35

. . . . . . . . . . . . . . . . . . . . . 30

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.10 Het kostenmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1

Maximale servercapaciteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2


5.3

Maximale servercapaciteit per periode . . . . . . . . . . . . . . . . . . . . . 52

5.4


5.5

Maximale servercapaciteit per periode . . . . . . . . . . . . . . . . . . . . . 59

5.6

Maximale servercapapciteit per periode . . . . . . . . . . . . . . . . . . . . 62

5.7

Maximale servercapapciteit per periode . . . . . . . . . . . . . . . . . . . . 64

5.8

Aangepast business profiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.9

De stijging van de nodige capaciteit . . . . . . . . . . . . . . . . . . . . . . 72

5.10 Kosten die wegvallen door een thin client dienst . . . . . . . . . . . . . . . . 76 A.1 Adoptie waarden voor business gebruiker

. . . . . . . . . . . . . . . . . . . 83

A.2 Adoptie waarden voor Residentiële gebruiker . . . . . . . . . . . . . . . . . 84

LIJST VAN TABELLEN

110

C.1 De kost per gebruiker per jaar in het basis scenario . . . . . . . . . . . . . . 89 C.2 De kost per gebruiker per jaar in het scenario zonder LEX capaciteit . . . . 90 C.3 De kost per gebruiker per jaar in het scenario zonder BRAS capaciteit . . . 90 C.4 De kost per gebruiker per jaar in het scenario zonder BRAS en LEX capaciteit 91 C.5 De kost per gebruiker per jaar in het scenario met hoge en lage DSLAM capaciteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 C.6 De kost per gebruiker per jaar in het scenario met gevorderd algoritme . . . 92 C.7 De kost per gebruiker per jaar in het scenario met geavanceerd algoritme

. 92

C.8 De kost per gebruiker per jaar in het scenario met geavanceerd algoritme en extra beperking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 C.9 De kost per gebruiker per jaar in het scenario met geoptimaliseerd algoritme 93 C.10 De kost per gebruiker per jaar in het scenario zonder 3D-spel . . . . . . . . 94 D.1 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 95 D.2 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 95 D.3 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 96 D.4 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 96 D.5 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 96 D.6 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 97 D.7 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 97 D.8 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 97 D.9 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 98 D.10 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 98 D.11 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 98 D.12 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 99 D.13 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 99 D.14 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 99 D.15 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 100 D.16 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 100 D.17 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 100 D.18 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 101 D.19 De totale NPV bij 100% business gebruikers in duizend ¤ . . . . . . . . . . 101 D.20 De totale NPV bij 80% business gebruikers in duizend ¤ . . . . . . . . . . . 101

Techno-economische studie voor het uitrollen van interactieve multimedia Thin Client diensten

Recommend Documents