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

Maat: px
Weergave met pagina beginnen:

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

Transcriptie

1 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

2 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

3 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

4 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 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

5 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. INTRODUCTION IN 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. TECHNICAL 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. A. General Information III. THE SIMULATOR 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.

6 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. SIMULATIONS 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. 1. NPV analysis for the situation with the optimized server selection algorithm. 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 COST DIVISION BETWEEN BUSINESS AND RESIDENTIAL USER. Ratio 80% Cost/Bus. Cost/Res. business users [e] [e] Whithout gaming Optimized with gaming (1) Optimized with gaming (2) V. CONCLUSIONS 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. REFERENCES [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 [2] J. V. Gregg, C. H. Hossel,, J. T. Richardson, Mathematical trend curves: An aid to forecasting, Edinburgh: Oliver and Boyd, [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.

7 INHOUDSOPGAVE vii Inhoudsopgave Extended abstract Gebruikte afkortingen v xi 1 Inleiding 1 2 Thin Client architectuur Definitie van Thin Clients Client/server architectuur De werking van een Thin Client/Server systeem Voordelen Beheersbaarheid Schaalbaarheid Beveiliging Besparingen Beperkingen Mogelijke verschijningsvormen Server-based computing Virtual Desktop Infrastructure Thin Client protocollen Independent Computing Architecture (ICA) Remote Desktop Protocol (RDP) Virtual Network Computing (VNC) Hybrid Thin-Client protocol Heuristieken voor serverplaatsing

8 INHOUDSOPGAVE viii Centraal Decentraal De simulator Architectuur Functionaliteiten Server farm locatie bepaling Server selectie Type gebeurtenissen Chronologie van de gebeurtenissen Output van een simulatie Verwerking gegevens Technisch en economisch model Technologische parameters Netwerktopologie Applicatie parameters Scenario model Populatie Adoptie Aankomstdistributie van de gebruikers in de tijd Online tijd Verdeling van de gebruikers over het netwerk Gebruikersprofiel Kost parameters Economisch model Variabele parameters Servercapaciteit Server selectie algoritme Gebruikersprofiel Simulaties Basisscenario

9 INHOUDSOPGAVE ix 5.2 Scenario met beperking van de servercapaciteit Geen servercapaciteit op LEX niveau Geen servercapaciteit op BRAS niveau Geen servercapaciteit op BRAS en LEX niveau Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau Besluit Intelligentere server selectie algoritmes Gevorderd algoritme Geavanceerd algoritme Geoptimaliseerd algoritme Besluit Wijzigen van het gebruikersprofiel Wijzigen van het Business profiel Wijzigen online tijd residentiële gebruiker Weglaten van de spel applicatie Besluit Conclusie 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 D.2 Scenario met beperking van de servercapaciteit D.2.1 Geen servercapaciteit op LEX niveau D.2.2 Geen servercapaciteit op BRAS niveau D.2.3 Geen servercapaciteit op BRAS en LEX niveau

10 INHOUDSOPGAVE x D.2.4 Optimalisatie van het scenario geen servercapaciteit op BRAS en LEX niveau D.3 Intelligentere server selectie algoritmes D.3.1 Gevorderd algoritme D.3.2 Geavanceerd algoritme D.3.3 Geoptimaliseerd algoritme D.4 Wijzigen van het gebruikersprofiel D.4.1 Wijzigen van het Business profiel D.4.2 Wijzigen online tijd residentiële gebruiker D.4.3 Weglaten van de spel applicatie E Inhoud van de DVD 102 Bibliografie 103 Lijst van figuren 106 Lijst van tabellen 109

11 GEBRUIKTE AFKORTINGEN xi Gebruikte afkortingen BRAS CapEx DSL DSLAM FTE FTP ICA LEX Mbps NPV OpEx PDA RFB RAM TCO VNC VoIP WAN WWW Broadband Remote Access Server Capital Expenditures Digital Subscriber Line DSL Access Multiplexer Full Time Equivalent File Transfer Protocol Independent Computing Architecture Local Exchange Mega bit per seconde Net Present Value Operational Expenditures Personal Digital Assistant Remote Frame Buffer Random Access Memory Total Cost of Ownership Virtual Network Computing Voice over Internet Protocol Wide Area Network World Wide Web

12 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.

13 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.

14 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.

15 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.

16 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

17 2.4 Voordelen 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 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] 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üpgraded worden. In het klassiek desktop model zou dit leiden tot een upgrade of een vervanging van alle systemen [10] 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

18 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] 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.

19 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 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].

20 2.6 Mogelijke verschijningsvormen 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 Een typische Citrix configuratie is weergegeven in figuur 2.5 [14]. Figuur 2.5: Citrix configuratie [14]

21 2.6 Mogelijke verschijningsvormen 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]

22 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 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] 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

23 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] 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].

24 2.8 Heuristieken voor serverplaatsing 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 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.

25 2.8 Heuristieken voor serverplaatsing 14 Figuur 2.7: Centrale serverplaatsing 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

26 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

27 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.

28 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.

29 3.2 Functionaliteiten 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 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 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.

30 3.2 Functionaliteiten 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

31 3.2 Functionaliteiten 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 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.

32 3.2 Functionaliteiten 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. kunnen dan gebruikt worden voor het bedienen van andere gebruikers. Deze 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. deze gegevens kan er dan een verdere analyse gedaan worden van een scenario. Met 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

33 3.2 Functionaliteiten 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 De volgorde van het optreden van de gebeurtenissen is weergegeven in figuur 3.5. Figuur 3.5: Volgorde van de gegenereerde gebeurtenissen 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

34 3.2 Functionaliteiten 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 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.

35 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.

36 4.1 Technologische parameters Technologische parameters 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.

37 4.1 Technologische parameters 26 Figuur 4.1: Netwerktopologie 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.

38 4.1 Technologische parameters 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 Surfen Video bekijken Spel / / 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 Type applicatie Ingestelde bandbreedte Kantoortoepassingen Surfen Video bekijken Spel 550 kbps kbps kbps kbps 1 resolutie van 1024x768 2 resolutie van 512x304 3 resolutie van 640x480

39 4.1 Technologische parameters 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 470ms 1 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

40 4.1 Technologische parameters 29 Tabel 4.4: Toelaatbare latency [25] Applicatie Latency (ms) Jitter (ms) Pakket verlies (%) SAP niet van toepassing 1-3 VoIP WWW niet van toepassing 1-5 FTP niet van toepassing niet van toepassing 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 ms 3 Surfen ms 3 Video bekijken 150 ms 2 Spel 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

41 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 Type applicatie Geheugen gebruik Kantoortoepassingen Surfen Video bekijken Spel 34 MB 39 MB 51 MB 60 MB 4.2 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 gebruikers ingesteld. In realiteit is dit niet de populatie van het eerste jaar. curve. Dit aantal wordt bepaald door de gedefinieerde adoptie 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]. S(t) = m.e e b(t a) S = Aantal gebruikers m = Maximum markt potentieel a = Punt waar een adoptie van 37% is

42 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 bedragen en voor de residentiële gebruikers 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, b 0,9 0,6 m Figuur 4.2: Adoptie curves bij 40% business gebruikers

43 4.2 Scenario model 32 Figuur 4.3: Adoptie curves bij 80% business gebruikers 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.

44 4.2 Scenario model 33 Figuur 4.4: Aankomstdistributie van de gebruikers in % van de populatie 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 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

45 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 Gebruikersprofiel In de paragraaf 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%

46 4.3 Kost parameters 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 Type 2 DL580 G5 2 quad core Type 3 DL380 G5 2 quad core Type 4 DL380 G5 1 quad core Type 5 DL380 G5 1 dual core 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-

47 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 gebruikers en een vermindering van 20 per licentie per stap, vandaar de notatie 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 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) = 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) = km.

48 4.3 Kost parameters 37 Investeringskost Tabel 4.10: Het kostenmodel Kost per type server Type 1 [32] Type 2 [32] Type 3 [32] Type 4 [32] Type 5 [32] Kost per rack [33] Thin client licentie kost [33] 290,40 Office licenties Jaarlijkse kost voor infrastructuur Kost van bedrading per rack (per jaar) [33] 198 Huur kost per rack (per jaar) [33] Operationele kosten Energie kosten per server (per uur) [33] 0,04 Full time equivalent (FTE) kost [33] Aantal help desk oproepen per jaar per klant [33] 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 Fiber connectie tussen BRAS-LEX Fiber connectie tussen LEX-DSLAM per km per jaar voor 2,5 Gbps connectie

49 4.4 Economisch model 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 BRAS- LEX 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

50 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 gebruik 2 = 20% 34MB+40% 39MB+30% 51MB+10% 60MB 75% 34MB+20% 39MB+5% 51MB = 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 gebruik 3 = 20% 550kbps+40% 3000kbps+30% 3000kbps 75% 550kbps+20% 3000kbps+5% 3000kbps = 1, 9 Verdeelsleutel: (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 De percentages komen uit tabel 4.8 en de geheugencapaciteiten uit tabel De percentages komen uit tabel 4.8 en de bandbreedtes uit tabel 4.2.

51 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 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 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 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.

52 4.5 Variabele parameters 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.

53 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

54 5.1 Basisscenario 43 betekent van DSLAM naar LEX en van LEX naar BRAS niveau, zie paragraaf 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

55 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.

56 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

57 5.2 Scenario met beperking van de servercapaciteit 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 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 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.

58 5.2 Scenario met beperking van de servercapaciteit 47 Figuur 5.5: De cumulatieve kost van het systeem 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 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.

59 5.2 Scenario met beperking van de servercapaciteit 48 Figuur 5.6: De totale serverbezetting 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.

60 5.2 Scenario met beperking van de servercapaciteit 49 Figuur 5.7: NPV analyse 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 / 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.

61 5.2 Scenario met beperking van de servercapaciteit 50 De belangrijkste oorzaak hiervan is het wegvallen van de netwerkkosten tussen BRAS en LEX niveau. Figuur 5.8: De cumulatieve kost van het systeem 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 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.

62 5.2 Scenario met beperking van de servercapaciteit 51 Figuur 5.9: De totale serverbezetting 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. Figuur 5.10: NPV analyse

63 5.2 Scenario met beperking van de servercapaciteit 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 / / MB / / 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.

64 5.2 Scenario met beperking van de servercapaciteit 53 Figuur 5.11: De cumulatieve kost van het systeem 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

65 5.2 Scenario met beperking van de servercapaciteit 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 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%. Figuur 5.13: De totale serverbezetting 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.

66 5.2 Scenario met beperking van de servercapaciteit 55 Figuur 5.14: NPV analyse 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 BRAS LEX DSLAM DSLAM hoge belasting lage belasting / / MB MB

67 5.2 Scenario met beperking van de servercapaciteit 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 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. Figuur 5.15: De cumulatieve kost van het systeem 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 Het is reeds verbeterd in vergelijking met een uniforme verdeling van de capaciteit. Toch leidt deze situatie tot

68 5.2 Scenario met beperking van de servercapaciteit 57 een onefficiënt gebruik van de servercapaciteit. serverbezetting nog stijgen tot 60%. Bij een verhouding van 100% kan de Figuur 5.16: De totale serverbezetting 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.

69 5.2 Scenario met beperking van de servercapaciteit 58 Figuur 5.17: NPV analyse 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

70 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 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 / MB 1500 MB / 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.

71 5.3 Intelligentere server selectie algoritmes 60 Figuur 5.18: De cumulatieve kost van het systeem 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. Figuur 5.19: Procent niet bediende gebruikers

72 5.3 Intelligentere server selectie algoritmes 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 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. Figuur 5.20: De totale serverbezetting 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.

73 5.3 Intelligentere server selectie algoritmes 62 Figuur 5.21: NPV analyse 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 / MB 1500 MB / 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

74 5.3 Intelligentere server selectie algoritmes 63 zullen worden met een server in een zijtak. waardoor de operationele kost stijgt. Hierdoor ontstaat er meer netwerkverkeer Figuur 5.22: De cumulatieve kost van het systeem 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.

75 5.3 Intelligentere server selectie algoritmes 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. Figuur 5.23: NPV analyse 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 / MB 1500 MB / 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 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

76 5.3 Intelligentere server selectie algoritmes 65 hops in 2008, naar 2,31 hops in 2010 en naar 2,25 hops in De daling in 2012 is te wijten aan de extra capaciteit op LEX niveau in 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 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 In 2012 gaat dit naar 88% totale serverbezetting. Zelfs bij deze bezetting kunnen nog alle gebruikers bediend worden.

77 5.3 Intelligentere server selectie algoritmes 66 Figuur 5.24: De totale serverbezetting 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.

78 5.4 Wijzigen van het gebruikersprofiel 67 Figuur 5.25: NPV analyse 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.

79 5.4 Wijzigen van het gebruikersprofiel Wijzigen van het Business profiel Als strategie voor het dimensioneren van het netwerk wordt gebruik gemaakt van het geoptimaliseerd algoritme zoals gedefinieerd in paragraaf 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.

80 5.4 Wijzigen van het gebruikersprofiel 69 Figuur 5.26: Procent niet bediende gebruikers 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.

81 5.4 Wijzigen van het gebruikersprofiel 70 Figuur 5.27: NPV analyse 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 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.

82 5.4 Wijzigen van het gebruikersprofiel 71 Figuur 5.28: Procent niet bediende gebruikers De NPV is nu ook iets lager maar de kwaliteit van de dienst is gestegen door een hogere bedieningsgraad Wijzigen online tijd residentiële 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 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.

83 5.4 Wijzigen van het gebruikersprofiel 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 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. Figuur 5.29: NPV analyse

84 5.4 Wijzigen van het gebruikersprofiel 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. Figuur 5.30: De cumulatieve kost van het systeem

Welkom bij IT-Workz. Etten-Leur, 16 november 2010. Altijd en overal werken en leren. Applicatie en Desktop Delivery met Quest vworkspace

Welkom bij IT-Workz. Etten-Leur, 16 november 2010. Altijd en overal werken en leren. Applicatie en Desktop Delivery met Quest vworkspace Welkom bij IT-Workz Altijd en overal werken en leren Applicatie en Desktop Delivery met Quest vworkspace Etten-Leur, 16 november 2010 IT-Workz is de verzelfstandigde Dienst ICT van het ROC West-Brabant.

Nadere informatie

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 8 februari 2010

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 8 februari 2010 FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE Toets Inleiding Kansrekening 1 8 februari 2010 Voeg aan het antwoord van een opgave altijd het bewijs, de berekening of de argumentatie toe. Als je een onderdeel

Nadere informatie

VDI WORKSPACE. 3D CAD virtualisatie & Next Gen. Grafische werkplek. PTC Userdag 2017

VDI WORKSPACE. 3D CAD virtualisatie & Next Gen. Grafische werkplek. PTC Userdag 2017 VDI WORKSPACE 3D CAD virtualisatie & Next Gen. Grafische werkplek PTC Userdag 2017 CSN Groep & Portfolio Cloud Ecosysteem VDI Workspace Business drivers VDI GPU Powered VDI Voordelen Referenties Onze aanpak

Nadere informatie

Werkplekvisie. Hans van Zonneveld Senior Consultant Winvision

Werkplekvisie. Hans van Zonneveld Senior Consultant Winvision Werkplekvisie Hans van Zonneveld Senior Consultant Winvision De essentie De gebruiker centraal Verschillende doelgroepen Verschillende toepassingen Verschillende locaties Het beschikbaar

Nadere informatie

WWW.EMINENT-ONLINE.COM

WWW.EMINENT-ONLINE.COM WWW.EMINENT-OINE.COM HNDLEIDING USERS MNUL EM1016 HNDLEIDING EM1016 USB NR SERIEEL CONVERTER INHOUDSOPGVE: PGIN 1.0 Introductie.... 2 1.1 Functies en kenmerken.... 2 1.2 Inhoud van de verpakking.... 2

Nadere informatie

Virtual Desktop Infrastructure Een alternatief SBC concept? Jacco Bezemer

Virtual Desktop Infrastructure Een alternatief SBC concept? Jacco Bezemer Virtual Desktop Infrastructure Een alternatief SBC concept? Jacco Bezemer Wat ga ik behandelen? Wat is VDI? Voordelen van SBC? VDI versus SBC De voor- en nadelen van VDI De techniek De componenten Use-cases

Nadere informatie

SYSTEEMEISEN VOOR FACET FEBR. 2013

SYSTEEMEISEN VOOR FACET FEBR. 2013 SYSTEEMEISEN VOOR FACET FEBR. 2013 Het nieuwe computerexamensysteem Facet kan zowel offline als online gebruikt worden. Bij een online-afname worden de opgaven rechtstreeks ingelezen via het internet van

Nadere informatie

Functionele beschrijving: scannen naar Exact Globe.

Functionele beschrijving: scannen naar Exact Globe. Functionele beschrijving: scannen naar Exact Globe. Algemeen Met de KYOCERA scannen naar Exact Globe beschikt u over een efficiënte oplossing om uw documenten te scannen naar Exact Globe. Met deze oplossing

Nadere informatie

SuperOffice Systeemvereisten

SuperOffice Systeemvereisten Minimale systeemvereisten voor SuperOffice CRM De minimale systeemvereisten voor SuperOffice CRM zijn tevens afhankelijk van het besturingssysteem en de services/applicaties die op het systeem actief zijn.

Nadere informatie

Technische Productlijn

Technische Productlijn Technische Productlijn Serversoftware Citrix Datum laatste bijwerking: oktober 2006 Cevi NV 2006 Inhoud 1 Kernfuncties 2 Aanvullende functies 3 Geïntegreerde modules 1 Kernfuncties Server Based Computing

Nadere informatie

Multi user Setup. Firebird database op een windows (server)

Multi user Setup. Firebird database op een windows (server) Multi user Setup Firebird database op een windows (server) Inhoudsopgave osfinancials multi user setup...3 Installeeren van de firebird database...3 Testing van de connectie met FlameRobin...5 Instellen

Nadere informatie

Systeemeisen Exact Compact product update 406

Systeemeisen Exact Compact product update 406 1 van 6 08-10-2013 12:07 Exact Compact Systeemeisen Exact Compact product update 406 Een pressionele administratie moet bedrijfszeker zijn. U moet er in het dagelijks gebruik snel en zonder onderbrekingen

Nadere informatie

SAMPLE 11 = + 11 = + + Exploring Combinations of Ten + + = = + + = + = = + = = 11. Step Up. Step Ahead

SAMPLE 11 = + 11 = + + Exploring Combinations of Ten + + = = + + = + = = + = = 11. Step Up. Step Ahead 7.1 Exploring Combinations of Ten Look at these cubes. 2. Color some of the cubes to make three parts. Then write a matching sentence. 10 What addition sentence matches the picture? How else could you

Nadere informatie

MobiDM App Handleiding voor Windows Mobile Standard en Pro

MobiDM App Handleiding voor Windows Mobile Standard en Pro MobiDM App Handleiding voor Windows Mobile Standard en Pro Deze handleiding beschrijft de installatie en gebruik van de MobiDM App voor Windows Mobile Version: x.x Pagina 1 Index 1. WELKOM IN MOBIDM...

Nadere informatie

Handleiding Zuludesk Parent

Handleiding Zuludesk Parent Handleiding Zuludesk Parent Handleiding Zuludesk Parent Met Zuludesk Parent kunt u buiten schooltijden de ipad van uw kind beheren. Hieronder vind u een korte handleiding met de mogelijkheden. Gebruik

Nadere informatie

Handleiding Installatie ADS

Handleiding Installatie ADS Handleiding Installatie ADS Versie: 1.0 Versiedatum: 19-03-2014 Inleiding Deze handleiding helpt u met de installatie van Advantage Database Server. Zorg ervoor dat u bij de aanvang van de installatie

Nadere informatie

Virtual Enterprise Centralized Desktop

Virtual Enterprise Centralized Desktop Virtual Enterprise Centralized Desktop Het gebruik van virtuele desktops en de licensering daarvan Bastiaan de Wilde, Solution Specialist Microsoft Nederland Aanleiding Steeds meer gebruik van Virtuele

Nadere informatie

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 22 februari 2013

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 22 februari 2013 FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE Toets Inleiding Kansrekening 1 22 februari 2013 Voeg aan het antwoord van een opgave altijd het bewijs, de berekening of de argumentatie toe. Als je een onderdeel

Nadere informatie

z x 1 x 2 x 3 x 4 s 1 s 2 s 3 rij rij rij rij

z x 1 x 2 x 3 x 4 s 1 s 2 s 3 rij rij rij rij ENGLISH VERSION SEE PAGE 3 Tentamen Lineaire Optimalisering, 0 januari 0, tijdsduur 3 uur. Het gebruik van een eenvoudige rekenmachine is toegestaan. Geef bij elk antwoord een duidelijke toelichting. Als

Nadere informatie

Settings for the C100BRS4 MAC Address Spoofing with cable Internet.

Settings for the C100BRS4 MAC Address Spoofing with cable Internet. Settings for the C100BRS4 MAC Address Spoofing with cable Internet. General: Please use the latest firmware for the router. The firmware is available on http://www.conceptronic.net! Use Firmware version

Nadere informatie

Introductie in flowcharts

Introductie in flowcharts Introductie in flowcharts Flow Charts Een flow chart kan gebruikt worden om: Processen definieren en analyseren. Een beeld vormen van een proces voor analyse, discussie of communicatie. Het definieren,

Nadere informatie

Compaq Desktop Wallpaper

Compaq Desktop Wallpaper Compaq Desktop Wallpaper Thank you for reading. As you may know, people have search numerous times for their chosen books like this, but end up in infectious downloads. Rather than reading a good book

Nadere informatie

TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica. Examination 2DL04 Friday 16 november 2007, hours.

TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica. Examination 2DL04 Friday 16 november 2007, hours. TECHNISCHE UNIVERSITEIT EINDHOVEN Faculteit Wiskunde en Informatica Examination 2DL04 Friday 16 november 2007, 14.00-17.00 hours. De uitwerkingen van de opgaven dienen duidelijk geformuleerd en overzichtelijk

Nadere informatie

EM6250 Firmware update V030507

EM6250 Firmware update V030507 EM6250 Firmware update V030507 EM6250 Firmware update 2 NEDERLANDS/ENGLISH Table of contents 1.0 (NL) Introductie... 3 2.0 (NL) Firmware installeren... 3 3.0 (NL) Release notes:... 5 1.0 (UK) Introduction...

Nadere informatie

Add the standing fingers to get the tens and multiply the closed fingers to get the units.

Add the standing fingers to get the tens and multiply the closed fingers to get the units. Digit work Here's a useful system of finger reckoning from the Middle Ages. To multiply $6 \times 9$, hold up one finger to represent the difference between the five fingers on that hand and the first

Nadere informatie

Desktop Delivery: een zakelijke afweging

Desktop Delivery: een zakelijke afweging Desktop Delivery: een zakelijke afweging Client - Server, SBC, virtuele desktops, virtuele applicaties of een virtueel besturingssysteem? Er zijn genoeg mogelijkheden om desktop functionaliteit aan de

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 DocumentManager

Functionele beschrijving: scannen naar UNIT4 DocumentManager Functionele beschrijving: scannen naar UNIT4 DocumentManager Algemeen Met de KYOCERA Scannen naar UNIT4 DocumentManager beschikt u over een efficiënte oplossing om uw documenten te scannen naar UNIT4 DocumentManager

Nadere informatie

DE IT-OMGEVING VAN DE TOEKOMST STAP AF VAN DURE, BEHEERINTENSIEVE ADHOC-OPLOSSINGEN EN GA VOOR KOSTENBESPARENDE EENVOUD MET HYPER-CONVERGED

DE IT-OMGEVING VAN DE TOEKOMST STAP AF VAN DURE, BEHEERINTENSIEVE ADHOC-OPLOSSINGEN EN GA VOOR KOSTENBESPARENDE EENVOUD MET HYPER-CONVERGED IT MANAGEMENT & OPTIMIZATION DE IT-OMGEVING VAN DE TOEKOMST STAP AF VAN DURE, BEHEERINTENSIEVE ADHOC-OPLOSSINGEN EN GA VOOR KOSTENBESPARENDE EENVOUD MET HYPER-CONVERGED POWERED BY Recent onderzoek toont

Nadere informatie

Welk datacenterconsumptiemodel past het best bij uw visie?

Welk datacenterconsumptiemodel past het best bij uw visie? Welk datacenterconsumptiemodel past het best bij uw visie? THE BOTH-AND DIGITAL ATTITUDE TECHNOLOGY Wanneer we het het minst verwachten stelt het leven ons op de proef, om onze moed en onze bereidheid

Nadere informatie

Functionele beschrijving: scannen naar van Brug software.

Functionele beschrijving: scannen naar van Brug software. Functionele beschrijving: scannen naar van Brug software. Algemeen Met de KYOCERA scannen naar van Brug Software beschikt u over een efficiënte oplossing om uw documenten te scannen naar het Notarieel

Nadere informatie

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE Tentamen Bewijzen en Technieken 1 7 januari 211, duur 3 uur. Voeg aan het antwoord van een opgave altijd het bewijs, de berekening of de argumentatie toe.

Nadere informatie

Werken zonder zorgen met uw ICT bij u op locatie

Werken zonder zorgen met uw ICT bij u op locatie Werken zonder zorgen met uw ICT bij u op locatie Naast de mogelijkheden om uw programmatuur en gegevens bij Drie-O via Evy 2.0 in de cloud te hosten hebt u ook de mogelijkheid om uw ICT omgeving bij u

Nadere informatie

De Digitale Transformatie en de impact op IT. Capgemini Edwin Leinse

De Digitale Transformatie en de impact op IT. Capgemini Edwin Leinse De Digitale Transformatie en de impact op IT Capgemini Edwin Leinse 40+ countries and 120+ nationalities (As of December 31, 2015) North America 16 034 Latin America 9 363 Europe 62 301 Middle-East & Africa

Nadere informatie

MyDHL+ Van Non-Corporate naar Corporate

MyDHL+ Van Non-Corporate naar Corporate MyDHL+ Van Non-Corporate naar Corporate Van Non-Corporate naar Corporate In MyDHL+ is het mogelijk om meerdere gebruikers aan uw set-up toe te voegen. Wanneer er bijvoorbeeld meerdere collega s van dezelfde

Nadere informatie

Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO

Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO Handleiding/Manual Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO Inhoudsopgave / Table of Contents 1 Verbinden met het gebruik van

Nadere informatie

TALIS. Systeemeisen. Versie 1 CREATED WITH

TALIS. Systeemeisen. Versie 1 CREATED WITH Systeemeisen Versie 1 Aangemaakt op: 12-2-2017 17:37:39 Status: Approved CREATED WITH Inhoudsopgave 1. Inleiding 4 1.1 Netwerk 4 1.2 en Microsoft Office 2007/2010/2013 4 1.3 Virtualisatie 4 2. 5 2.1 Stand-alone

Nadere informatie

CareConnect Fin Pre-requirements

CareConnect Fin Pre-requirements Pre-requirements Inhoudstafel A. Algemeen... 3 B. Type installaties... 3 C. Hardware en software vereisten... 4 1. PC Clients... 4 2. Terminal Server Clients (Thin Clients)... 4 3. Server... 4 D. Operating

Nadere informatie

Verantwoord rapporteren. Karin Schut

Verantwoord rapporteren. Karin Schut Verantwoord rapporteren Karin Schut Verantwoord rapporteren Documentatie Definities resultaattypen Rapportageregels Beschikbare variabelen Documentatie op Vinex Reken en rapportageregels Definitie van

Nadere informatie

Technische architectuur Beschrijving

Technische architectuur Beschrijving A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie

Nadere informatie

Veel gestelde vragen nieuwe webloginpagina

Veel gestelde vragen nieuwe webloginpagina Veel gestelde vragen nieuwe webloginpagina Op deze pagina treft u een aantal veel gestelde vragen aan over het opstarten van de nieuwe webloginpagina http://weblogin.tudelft.nl: 1. Ik krijg de melding

Nadere informatie

Functionele beschrijving: Scannen naar AFAS Profit.

Functionele beschrijving: Scannen naar AFAS Profit. Functionele beschrijving: Scannen naar AFAS Profit. Algemeen Met de Kyocera Scannen naar AFAS Profit beschikt u over een efficiënte oplossing om uw documenten te scannen naar AFAS Profit. Met deze oplossing

Nadere informatie

Classification of triangles

Classification of triangles Classification of triangles A triangle is a geometrical shape that is formed when 3 non-collinear points are joined. The joining line segments are the sides of the triangle. The angles in between the sides

Nadere informatie

Een startersgids voor Citrix XenApp Architecturen. Wilco van Bragt

Een startersgids voor Citrix XenApp Architecturen. Wilco van Bragt Een startersgids voor Citrix XenApp Architecturen Wilco van Bragt Introductie Wilco van Bragt Freelance Senior Consultant/Architect Nederland/Belgium VanBragt.Net Consultancy Oprichter van VanBragt.Net

Nadere informatie

NSi Output Manager Veelgestelde vragen. Version 3.2

NSi Output Manager Veelgestelde vragen. Version 3.2 NSi Output Manager Veelgestelde vragen Version 3.2 I. Algemene productinformatie 1. Wat is nieuw in Output Manager 3.2? NSi Output Manager 3.2 bevat diverse verbeteringen aan serverzijde, waarbij de meest

Nadere informatie

TALIS. Systeemeisen Basis. Versie 3.0 Approved CREATED WITH

TALIS. Systeemeisen Basis. Versie 3.0 Approved CREATED WITH Systeemeisen Basis Versie 3.0 Approved Aangemaakt op: 28-7-2015 16:19:16 Auteur TANS CREATED WITH Inhoudsopgave 1. Inleiding 3 2. 4 2.1 Stand-alone 4 2.2 server en werkstations 4 2.3 Remote 5 1. Inleiding

Nadere informatie

ICARUS Illumina E653BK on Windows 8 (upgraded) how to install USB drivers

ICARUS Illumina E653BK on Windows 8 (upgraded) how to install USB drivers ICARUS Illumina E653BK on Windows 8 (upgraded) how to install USB drivers English Instructions Windows 8 out-of-the-box supports the ICARUS Illumina (E653) e-reader. However, when users upgrade their Windows

Nadere informatie

EVO:RAIL VDI AANPAK Plaveit VMware EVO:RAIL de weg voor VDI?

EVO:RAIL VDI AANPAK Plaveit VMware EVO:RAIL de weg voor VDI? EVO:RAIL VDI AANPAK Plaveit VMware EVO:RAIL de weg voor VDI? APRIL 8, 2015 SLIDE 1 #Name: Verloigne Geert #Function: Technical Consultant #Email: geert.verloigne@realdolmen.com #UC: +32 2 801 51 81 Company:

Nadere informatie

1 Client/Server. 2 Geschiedenis. 3 Toekomst

1 Client/Server. 2 Geschiedenis. 3 Toekomst Deel 1 Inleiding 1 Client/Server 2 Geschiedenis 3 Toekomst Het client-server model is een model voor de samenwerking tussen twee of meer programma's, die zich op verschillende computers kunnen bevinden.

Nadere informatie

VMware View 4.5 een overview. Eline Klooster Technical Trainer e.klooster@xtg.nl

VMware View 4.5 een overview. Eline Klooster Technical Trainer e.klooster@xtg.nl VMware View 4.5 een overview Eline Klooster Technical Trainer e.klooster@xtg.nl Eline Klooster Xpert Training Group VMware Authorized Training Center Citrix Authorized Learning Center Microsoft CPLS Eigen

Nadere informatie

DALISOFT. 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool. Connect the TDS20620V2. Start DALISOFT

DALISOFT. 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool. Connect the TDS20620V2. Start DALISOFT TELETASK Handbook Multiple DoIP Central units DALISOFT 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool Connect the TDS20620V2 If there is a TDS13620 connected to the DALI-bus, remove it first.

Nadere informatie

Virtualizatie bij SIN

Virtualizatie bij SIN Virtualizatie bij SIN Inhoud 1 Waarom...2 2 Mogelijkheden:...2 3 Features:...2 3.1 Xen server...2 3.2 HyperV...3 3.3 ESXi...3 4 Pros Cons voor SIN:...3 4.1 Xen Server...3 4.2 HyperV...3 4.3 ESXi...3 5

Nadere informatie

Four-card problem. Input

Four-card problem. Input Four-card problem The four-card problem (also known as the Wason selection task) is a logic puzzle devised by Peter Cathcart Wason in 1966. It is one of the most famous tasks in the study of deductive

Nadere informatie

XTREMIO WAT IS HET OORDEEL VAN DE GEBRUIKER?

XTREMIO WAT IS HET OORDEEL VAN DE GEBRUIKER? WAT IS HET OORDEEL VAN DE GEBRUIKER? POWERED BY INHOUDSOPGAVE Inleiding 02 Wat zijn de redenen tot aanschaf? 03 Wat levert XtremIO organisaties in de praktijk op? 03 Voor welke bedrijfskritische applicaties

Nadere informatie

Cerussa FIN Pre-requirements

Cerussa FIN Pre-requirements Pre-requirements Inhoudstafel A. Algemeen... 3 B. Type installaties... 3 C. Hardware en software vereisten... 4 1. PC Clients... 4 2. Terminal Server Clients (Thin Clients)... 4 3. Server... 4 D. Operating

Nadere informatie

CTI SUITE TSP DETAILS

CTI SUITE TSP DETAILS CTI SUITE TSP DETAILS TAPI allows an application to access telephony services provided by a telecom PABX. In order to implement its access to ETRADEAL, a TAPI interface has been developed by Etrali. As

Nadere informatie

Van Virtualisatie naar Cloud Computing De roadmap voor de toekomst?

Van Virtualisatie naar Cloud Computing De roadmap voor de toekomst? Van Virtualisatie naar Cloud Computing De roadmap voor de toekomst? Louis Joosse Principal Consultant Alle intellectuele eigendomsrechten met betrekking tot de inhoud van of voortvloeiende uit dit document

Nadere informatie

LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series

LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series Tiptel b.v. Camerastraat 2 1322 BC Almere tel.: +31-36-5366650 fax.: +31-36-5367881 info@tiptel.nl Versie 1.2.0 (09022016) Nederlands: De LDAP server

Nadere informatie

Three Ships CDS opschalingsdocument Overzicht server configuratie voor Three Ships CDS

Three Ships CDS opschalingsdocument Overzicht server configuratie voor Three Ships CDS CDS opschalingsdocument Overzicht server configuratie voor CDS 1. Algemeen Dit document geeft een overzicht van een aantal mogelijke hardware configuraties voor het inrichten van een serveromgeving voor

Nadere informatie

Cloud Computing. Bart van Dijk

Cloud Computing. Bart van Dijk Cloud Computing Bart van Dijk (b.van.dijk@hccnet.nl) Cloud Computing Wat is Cloud Computing, en waarom Geschiedenis Cloud Computing Techologie Service modellen Voor en nadelen Cloud Computing voor consumenten

Nadere informatie

Activant Prophet 21. Prophet 21 Version 12.0 Upgrade Information

Activant Prophet 21. Prophet 21 Version 12.0 Upgrade Information Activant Prophet 21 Prophet 21 Version 12.0 Upgrade Information This class is designed for Customers interested in upgrading to version 12.0 IT staff responsible for the managing of the Prophet 21 system

Nadere informatie

Interactief, real time security management

Interactief, real time security management P2000 en P2000LE SECURITY MANAGEMENT SYSTEEM Interactief, real time security management P2000 Security Management Systeem Schaalbaar, intuïtief en eenvoudig in gebruik Het Johnson Controls P2000 security

Nadere informatie

Enterprise Portfolio Management

Enterprise Portfolio Management Enterprise Portfolio Management Strategische besluitvorming vanuit integraal overzicht op alle portfolio s 22 Mei 2014 Jan-Willem Boere Vind goud in uw organisatie met Enterprise Portfolio Management 2

Nadere informatie

TALIS. Basis systeemeisen. Versie 3 Approved CREATED WITH

TALIS. Basis systeemeisen. Versie 3 Approved CREATED WITH Basis systeemeisen Versie 3 Approved Aangemaakt op: 16-2-2016 9:34:43 Auteur TANS CREATED WITH Inhoudsopgave 1. Inleiding 3 2. 4 2.1 Stand-alone 4 2.2 client-server 5 2.3 Remote 6 1. Inleiding Deze systeemeisen

Nadere informatie

Mitel User Group. Mitel-licentiestructuur. Jan Jansen. Account Director april 2015

Mitel User Group. Mitel-licentiestructuur. Jan Jansen. Account Director april 2015 Mitel User Group Mitel-licentiestructuur Jan Jansen Account Director april 2015 De concrete vraag Kan iemand van Mitel de licentiestructuur uitleggen? 2 Agenda Waarom licenties Basis Mitel-licentiestructuur

Nadere informatie

RECEPTEERKUNDE: PRODUCTZORG EN BEREIDING VAN GENEESMIDDELEN (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM

RECEPTEERKUNDE: PRODUCTZORG EN BEREIDING VAN GENEESMIDDELEN (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM Read Online and Download Ebook RECEPTEERKUNDE: PRODUCTZORG EN BEREIDING VAN GENEESMIDDELEN (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM DOWNLOAD EBOOK : RECEPTEERKUNDE: PRODUCTZORG EN BEREIDING VAN STAFLEU

Nadere informatie

Agenda 26-4-2009. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie.

Agenda 26-4-2009. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie. John Lieberwerth Agenda Even voorstellen Cloud Computing De tien Plagen Gebruikersorganisatie en ICT

Nadere informatie

Rent+ Pre-requirements

Rent+ Pre-requirements Pre-requirements Inhoudstafel A. Algemeen... 3 B. Type installaties... 3 C. Hardware en software vereisten... 4 1. PC Clients... 4 2. Terminal Server Clients (Thin Clients)... 4 3. Server... 4 D. Operating

Nadere informatie

GERACC.net suite Systeemsoftware- en hardwarevereisten

GERACC.net suite Systeemsoftware- en hardwarevereisten suite 1. Hardware/Software eisen voor de installatie van de suite 1.1 PC Clients Processor: Processor snelheid: Dual Core 2.4 GHz of sneller Besturingssysteem: Windows XP SP3 of hoger (let op: raadpleeg

Nadere informatie

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE Tentamen Analyse 6 januari 203, duur 3 uur. Voeg aan het antwoord van een opgave altijd het bewijs, de berekening of de argumentatie toe. Als je een onderdeel

Nadere informatie

Functioneren van een Kind met Autisme. M.I. Willems. Open Universiteit

Functioneren van een Kind met Autisme. M.I. Willems. Open Universiteit Onderzoek naar het Effect van de Aanwezigheid van een Hond op het Alledaags Functioneren van een Kind met Autisme M.I. Willems Open Universiteit Naam student: Marijke Willems Postcode en Woonplaats: 6691

Nadere informatie

Windows 7 juist nu! Frank Spuls v-fspuls@microsoft.com 11 november 2009

Windows 7 juist nu! Frank Spuls v-fspuls@microsoft.com 11 november 2009 juist nu! Frank Spuls v-fspuls@microsoft.com 11 november 2009 Inspelen op veranderingen Hoofdkantoor Werkenop afstand Mobiele en flexibele medewerkers Bijkantoren 2 Slide 3 Voornaamste conclusies Er is

Nadere informatie

EM7680 Firmware Update by OTA

EM7680 Firmware Update by OTA EM7680 Firmware Update by OTA 2 NEDERLANDS/ENGLISH EM7680 Firmware update by OTA Table of contents 1.0 (NL) Introductie... 3 2.0 (NL) Firmware installeren... 3 3.0 (NL) Release notes:... 3 4.0 (NL) Overige

Nadere informatie

Functionele beschrijving: scannen naar Trivium FORTUNA.

Functionele beschrijving: scannen naar Trivium FORTUNA. Functionele beschrijving: scannen naar Trivium FORTUNA. Algemeen Met KYOCERA scannen naar Trivium FORTUNA beschikt u over een efficiënte oplossing om uw documenten te scannen naar Trivium FORTUNA. Met

Nadere informatie

TALIS. Basis systeemeisen. Versie 3.4 Approved CREATED WITH

TALIS. Basis systeemeisen. Versie 3.4 Approved CREATED WITH Basis systeemeisen Versie 3.4 Approved Aangemaakt op: 28-10-2015 8:11:01 Auteur TANS CREATED WITH Inhoudsopgave 1. Inleiding 3 2. 4 2.1 Stand-alone 4 2.2 server en werkstations 4 2.3 Remote 5 1. Inleiding

Nadere informatie

End to End Virtualisation

End to End Virtualisation End to End Virtualisation Virtualisatie in een Citrix wereld Edwin van den Broek Valid ICT Uiteindelijk willen we allemaal hetzelfde De DSM visie Applicaties transparant aan gebruikers aanbieden, ongeacht

Nadere informatie

Datum 15 juni 2006 Versie 1.0.6. Exchange Online. Handleiding voor gebruiker Release 1.0

Datum 15 juni 2006 Versie 1.0.6. Exchange Online. Handleiding voor gebruiker Release 1.0 Datum 1.0.6 Exchange Online Handleiding voor gebruiker Release 1.0 1.0.6 Inhoudsopgave 1 Instellingen e-mail clients 2 1.1 Gebruik via Outlook 2003 2 1.2 Gebruik via ActiveSync 15 1.3 Gebruik via andere

Nadere informatie

CHROMA STANDAARDREEKS

CHROMA STANDAARDREEKS CHROMA STANDAARDREEKS Chroma-onderzoeken Een chroma geeft een beeld over de kwaliteit van bijvoorbeeld een bodem of compost. Een chroma bestaat uit 4 zones. Uit elke zone is een bepaald kwaliteitsaspect

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement.

Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement. Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement. Algemeen Met KYOCERA scannen naar UNIT4 Cura Documentmanagement beschikt u over een efficiënte oplossing om uw documenten te scannen

Nadere informatie

VMware ThinApp. Application Virtualization Platform that enables complex software to be delivered as self-contained EXE files

VMware ThinApp. Application Virtualization Platform that enables complex software to be delivered as self-contained EXE files VMware ThinApp Application Virtualization Platform that enables complex software to be delivered as self-contained EXE files Edwin Friesen Senior Solution Consultant @ Ictivity B.V. edwin.friesen@ictivity.nl

Nadere informatie

Internet of Things in perspectief geplaatst. Herman Tuininga. Oktober 10, 2017

Internet of Things in perspectief geplaatst. Herman Tuininga. Oktober 10, 2017 Internet of Things in perspectief geplaatst Herman Tuininga Oktober 10, 2017 1 Achtergrond Meer dan 20 jaar ervaring in IoT 30 medewerkers IoT Lab Zwolle Connecting your things 2 IoT is een container begrip

Nadere informatie

L.Net s88sd16-n aansluitingen en programmering.

L.Net s88sd16-n aansluitingen en programmering. De L.Net s88sd16-n wordt via één van de L.Net aansluitingen aangesloten op de LocoNet aansluiting van de centrale, bij een Intellibox of Twin-Center is dat de LocoNet-T aansluiting. L.Net s88sd16-n aansluitingen

Nadere informatie

Connect.Me. meten = weten!.eu

Connect.Me. meten = weten!.eu meten = weten!.eu Inhoud Connected Waarom? 3 Connected Hoe? 4 Connected Waar? 6 Connected Wat? 7 Connected Wie? 8 Menu Home > Machines 9 Menu Home > Machines > Machine Info / Machine Properties / Machine

Nadere informatie

Stap 1: Registreer via de link op de G-schijf beschikbaar na inloggen met de teken-account, verzend via Submit. Nadien krijg je een bevestiging op

Stap 1: Registreer via de link op de G-schijf beschikbaar na inloggen met de teken-account, verzend via Submit. Nadien krijg je een bevestiging op Stap 1: Registreer via de link op de G-schijf beschikbaar na inloggen met de teken-account, verzend via Submit. Nadien krijg je een bevestiging op het scherm met de melding dat de registratie compleet

Nadere informatie

AE1103 Statics. 25 January h h. Answer sheets. Last name and initials:

AE1103 Statics. 25 January h h. Answer sheets. Last name and initials: Space above not to be filled in by the student AE1103 Statics 09.00h - 12.00h Answer sheets Last name and initials: Student no.: Only hand in the answer sheets! Other sheets will not be accepted Write

Nadere informatie

Gerust aan het werk MET ALLE INFORMATIE OVER ONZE CLOUD WERKPLEK.

Gerust aan het werk MET ALLE INFORMATIE OVER ONZE CLOUD WERKPLEK. Gerust aan het werk MET ALLE INFORMATIE OVER ONZE CLOUD WERKPLEK. Cloud werkplek Wat is het? De cloudwerkplek van Hupra is een Windows 8.1. desktop die altijd en overal via het internet toegankelijk is.

Nadere informatie

Cerussa HR Pre-requirements

Cerussa HR Pre-requirements Pre-requirements Inhoudstafel A. Algemeen... 3 B. Type installaties... 3 C. Hardware en software vereisten... 4 1. PC Clients... 4 2. Terminal Server Clients (Thin Clients)... 4 3. Server... 4 D. Operating

Nadere informatie

Het Effect van Verschil in Sociale Invloed van Ouders en Vrienden op het Alcoholgebruik van Adolescenten.

Het Effect van Verschil in Sociale Invloed van Ouders en Vrienden op het Alcoholgebruik van Adolescenten. Het Effect van Verschil in Sociale Invloed van Ouders en Vrienden op het Alcoholgebruik van Adolescenten. The Effect of Difference in Peer and Parent Social Influences on Adolescent Alcohol Use. Nadine

Nadere informatie

Vervang uw verouderde hardware

Vervang uw verouderde hardware Whitepaper Vervang uw verouderde hardware Dedicated of Cloud? Alles over virtualisatie. Wat is het, hoe werkt het en wat zijn de voordelen? INHOUD» Wat is virtualisatie?» Wat is een Virtual Server?» Besparen

Nadere informatie

Meer mogelijkheden voor mobiele medewerkers met secure app delivery

Meer mogelijkheden voor mobiele medewerkers met secure app delivery Meer mogelijkheden voor mobiele medewerkers met secure app delivery Werken met Windows-applicaties op alle mogelijke devices, met volledige security. Om gemakkelijk en productief te werken, willen veel

Nadere informatie

CAD supersnel laten draaien

CAD supersnel laten draaien CAD supersnel laten draaien Tra sfor atie a de grafis he erkplek IT met impact PTC User Event Agenda Over ITON De grafische werkplek anno 2014 Wat zijn de voordelen Voor wie o der de otorkap, es hik are

Nadere informatie

CAD IN THE CLOUD & AUGMENTED REALITY. Gebruik de (reken)kracht van het Datacenter

CAD IN THE CLOUD & AUGMENTED REALITY. Gebruik de (reken)kracht van het Datacenter CAD IN THE CLOUD & AUGMENTED REALITY Gebruik de (reken)kracht van het Datacenter EVEN VOORSTELLEN Michiel van Bergen van der Grijp Business developer CSN Groep Opgegroeid in Rotterdam 48 jaar Werktuigbouwkunde

Nadere informatie

1 Dienstbeschrijving Datacenter in a BOX

1 Dienstbeschrijving Datacenter in a BOX 1 Dienstbeschrijving Datacenter in a BOX Lancom Automatisering heeft jarenlang ervaring opgedaan in het ontwerpen, implementeren en beheren van ICT infrastructuren bij het MKB (+). Met deze informatie

Nadere informatie

Dit is een greep uit mijn stageverslag. 4. Citrix migratie

Dit is een greep uit mijn stageverslag. 4. Citrix migratie Dit is een greep uit mijn stageverslag 4. Citrix migratie Tijdens de eerste weken van mijn stage ben ik bezig geweest met het migreren van computer on wheels(cow s). Daarnaast heb ik ook de gebruikers

Nadere informatie

ALGORITMIEK: answers exercise class 7

ALGORITMIEK: answers exercise class 7 Problem 1. See slides 2 4 of lecture 8. Problem 2. See slides 4 6 of lecture 8. ALGORITMIEK: answers exercise class 7 Problem 5. a. Als we twee negatieve (< 0) getallen bij elkaar optellen is het antwoord

Nadere informatie

DE PRIVATE CLOUD. Johan Bos & Erik de Meijer

DE PRIVATE CLOUD. Johan Bos & Erik de Meijer DE PRIVATE CLOUD Johan Bos & Erik de Meijer Agenda Wat is Cloud? Waarom Private Cloud? Wanneer Private Cloud? Een stappenplan Vragen Quiz Ga naar www.kahoot.it of download de app Gefeliciteerd! 2017 EXACT

Nadere informatie

Windows Basics. yvan vander sanden. 22 februari 2015

Windows Basics. yvan vander sanden. 22 februari 2015 Windows Basics yvan vander sanden 22 februari 2015 Windows is nog altijd een veel gebruikt operating system. Als technicus moet je bekend zijn met het Windows operating system om gebruikers te kunnen helpen,

Nadere informatie

NETWORK CHARTER. #ResourceEfficiency

NETWORK CHARTER. #ResourceEfficiency NETWORK CHARTER 1 WHAT IS THE EREK NETWORK? EREK stands for the European Resource Efficiency Knowledge Centre, a vibrant platform to enable and reinforce businesses and especially small and medium sized

Nadere informatie

Technische data. Versie dec

Technische data. Versie dec Technische data Versie dec.2016 www.mobilea.nl Mobiléa Infrastructuur: Pagina 1 Pagina 2 Specificaties: Het platform van Mobiléa valt op te splitsen in een aantal technische componenten, te weten: De webapplicatie

Nadere informatie

PUBLICATIE INFORMATIE TRIMBLE ACCESS SOFTWARE. Versie 2013.41 Revisie A December 2013

PUBLICATIE INFORMATIE TRIMBLE ACCESS SOFTWARE. Versie 2013.41 Revisie A December 2013 PUBLICATIE INFORMATIE TRIMBLE ACCESS SOFTWARE 1 Versie 2013.41 Revisie A December 2013 Legal Information Trimble Navigation Limited Engineering Construction Group 935 Stewart Drive Sunnyvale, California

Nadere informatie

OPEN TRAINING. Onderhandelingen met leveranciers voor aankopers. Zeker stellen dat je goed voorbereid aan de onderhandelingstafel komt.

OPEN TRAINING. Onderhandelingen met leveranciers voor aankopers. Zeker stellen dat je goed voorbereid aan de onderhandelingstafel komt. OPEN TRAINING Onderhandelingen met leveranciers voor aankopers Zeker stellen dat je goed voorbereid aan de onderhandelingstafel komt. Philip Meyers Making sure to come well prepared at the negotiation

Nadere informatie