16
Revision Created On 2.0 November 28, 2004 Project Lead Project Lead __________________________________ ____________________________________ ___________________________________ ____________________________________ Dr. Lynn DeNoia Phil Wu IT BUSINESS PROPOSAL UPGRADING EXISTING NETWORK TO MEET FUTURE NEEDS OF YOUR BUSINESS Part 2 Mapping the New Technology Infrastructure to Business Requirements

IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

  • Upload
    phil-wu

  • View
    708

  • Download
    0

Embed Size (px)

DESCRIPTION

IT Business Proposal for upgrading existing network infrastructure to meet the growing business needs of a small to medium-sized company. Proposal is supported by actual OPNET simulation data. Part 2 discusses exactly how the new network infrastructure will successfully accommodate current and future business needs.

Citation preview

Page 1: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Revision Created On 2.0 November 28, 2004 Project Lead Project Lead __________________________________ ____________________________________ ___________________________________ ____________________________________

Dr. Lynn DeNoia Phil Wu

IT BUSINESS PROPOSAL UPGRADING EXISTING NETWORK TO

MEET FUTURE NEEDS OF YOUR BUSINESS

Part 2

Mapping the New Technology Infrastructure

to Business Requirements

Page 2: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 2

PART 2 Suitability of Existing Network to Videoconferencing Services

Further consultation with the TEC liaison revealed the following: • TEC still prefers to dedicate one server to each application. • TEC’s IT group performed an application analysis on the TEC network and discovered differences from the previously predicted application parameters (highlighted in the MP2 problem description). • The Director of Engineering wants to install a videoconference service for use within TEC and the CEO is very interested in exploring the potential for such videoconferencing services. This addendum is basically an analysis of the following: 1.) Feasibility of videoconferencing services over existing 10BaseT buliding LANS. 2.) Feasibility of videoconferencing services through TEC's backbone network. Baseline Model 2 - new application parameters Adjustments were made to the previous baseline model to reflect differences from previously predicted application parameters (highlighted in the MP2 problem description). This model was used as a new baseline model. All constraints and assumptions from the previous model still apply (they are highlighted again below for completeness in the same table containing new assumptions (Table ????). Detailed model descriptions and their attributes can be found in the Appendix.

Baseline Model 2 - Network Traffic and Usage Characteristics and Assumptions Model characteristic (input parameters) Assumptions/Reason/Usage Patterns 50% of the database (light) traffic being generated from the Administration Department for Sales and Marketing is directed towards the Order Provisioning Server while the other 50% is directed towards the Customer Information Server.

It was assumed that Sales and Marketing personnel will access order information to help them assess sales numbers and develop better marketing strategies (half the time). It is likely that they will also need to look at some corresponding customer information associated with each order (half the time).

50% of the web (light) traffic being generated from the Computing Center towards the Web and Email Server while other 50% is directed towards the Network Management Server.

It was assumed that Computing Center employees will spend half their time managing the network and require access to web based network management tools.

20% of database (light) traffic being generated by the Garage is directed towards the Customer Information Server where Trouble Ticket information resides, 80% directed towards Order Provisioning Server.

It was assumed that Garage personnel will be spending 20% of their database time servicing Trouble Tickets and require Trouble Ticket information from the database. The 80% of their database time will be spent

An Exponential Distribution to model a Poisson Distribution for all inter-arrival times

For modeling purposes, it was sufficient to model all network traffic using a Poisson Distribution. It was assumed that the Poisson Distribution was adequate for modeling the "overall" network traffic that would be observed in a real enterprise setting. It was assumed that most kinds of network traffic would be bursty and fairly randomized (number of videoconferences in any given unit of time, number of customer service events in any given unit of time..etc...). It was noted that certain kinds of network traffic can be characterized by certain types of probability distributions. certain types of network traffic produced by certain

Page 3: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 3

applications were modeled using specific probability distributions. However, this report is not a study on how well certain probability distributions reflect certain kinds of network traffic patterns.

Table ????

Baseline Model 2 - Application Characteristics and Assumptions

Application Profile Configuration Assumptions in relation to application

characteristics and network usage Heavy FTP • Inter-request times between

heavy file transfers = exponential distribution, 60 seconds • File sizes = normal distribution, 20000 bytes with a variance of 5000 bytes

• It was assumed that file transfers occur more frequently during heavy file transfer usage than initially predicted and can be adequately modeled with 60 second inter-request times. (modeled with an exponential distribution with the assumption that most requests are serviced under 60 seconds). • It was assumed that most of the file transfers will involve files containing maps and detailed cabling diagrams, most of which are roughly 20000 bytes in size (but can be as high as 25000 bytes depending on the images)

Light DB • Inter-request times between light database transacations = exponential distribution, 20 seconds • File sizes = normal distribution, 100 bytes with a variance of 50 bytes

• It was assumed that database requests occur more frequently during light database usage than initially predicted and can be adequately modeled with 20 second inter-request times. (this was modeled with an exponential distribution with the assumption that most requests are serviced under 20 seconds). • It was assumed that most light database queries will return relatively brief recordsets contain customer information, order information, and inventory information, most of which should be ~100 bytes.

Heavy DB • Inter-request times between heavy database transactions = exponential distribution, 10 seconds • File sizes = normal distribution, 1000 bytes with a variance of 200 bytes

• It was assumed that database requests occur more frequently during heavy database usage than initially predicted and can be adequately modeled with 10 second inter-request times. (this was modeled with an exponential distribution with the assumption that most requests are serviced under 10 seconds). • It was assumed that most light database queries will return detailed recordsets containing extensive customer information, order information, inventory information, trouble ticket information, most of which shouldn't be more than ~1000 bytes.

Light FTP • Inter-request times between light file transfers = exponential distribution, 120 seconds • File sizes = normal distribution, 20000 bytes with a variance of 5000 bytes

• It was assumed that light file transfers occur more frequently during light file transfer usage than initially predicted and can be adequately modeled with 120 second inter-request times. (modeled with an exponential distribution with the assumption that most requests are serviced under 120 seconds). • It was assumed that most of the file transfers will involve files containing maps and detailed cabling diagrams, most of which are roughly 20000 bytes in size (but can be as high as 25000 bytes depending on the images)

Light Email • Time between emails • It was assumed that this is the time used in SMTP by

Page 4: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 4

received/transmitted = 180 seconds • Send queue = 1 emails • Receive queue = 5 emails • Email size = normal distribution, 10000 bytes with variance of 5000 byte

default for time between receiving and transmitting emails. • It was assumed that most employees will receive more emails than they send. • It was assumed that most emails that are sent are roughly ~10000 bytes but can vary greatly (modeled by variance of 5000 bytes) depending on attachments.

Light Web • Inter-request times between page requests = exponential distribution, 30 seconds • Web objects size = Uniform_int Distribution with a range of 700-1000 bytes

• It was assumed that 30 seconds is an appropriate estimate for the time between selecting pages. • It is assumed that all web objects consistently fall within the range of 700-1000 bytes

Table ????

Model V - added server based videoconferencing services Baseline Model 2 was modified to include server-based videoconferencing services with the following additions:

• Added new server configured to support the videoconferencing application to the central server farm.

• Configured the Engineering LAN object (40 workstations) to generate videoconferencing traffic and direct that traffic to the videoconferencing server.

• An additional test workstation external to the LAN object used to analyze the feasibility of videoconferencing services over existing 10BaseT building LANS. In particular, the link capacity of the link between this test workstation and the LAN object was measured to assess how well existing 10BaseT links handle videoconferencing traffic. • Changed the number workstations in the Eng LAN object to 39 to account for the external workstation.

This model was used to analyze the impact of deploying and supporting videoconferencing services within the existing TEC network.

Model V - Network Traffic and Usage Characteristics and Assumptions • Same as Baseline Model 2 from above.

Baseline Model 2 - Application Characteristics and Assumptions • Same as Baseline Model 2 from above with the following additions: Application Profile Configuration Assumptions pertaining to application characteristics

and type of traffic Video Conferencing (light)

• Exponential distribution to model Poisson distribution

• It was assumed that video traffic is bursty • It was assumed that multiple independent full duplex video streams are occurring simultaneously with random inter-arrival times (video conferencing sessions are random) • "light" was chosen because video quality is heavily dependent upon compression schemes/techniques and algorithms and not so much on network capacity (therefore, "light" is more than adequate for our modeling purposes)

Page 5: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 5

Table ????

• Identify any potential single points of failure. Describe measures you would take to reduce risks associated with your findings. • Your assessment of the suitability of the existing technologies to handle growth in use of existing applications as well as the videoconferencing. • Your high-level recommendations for what TEC should do next. • Selected simulation results to support your assessment and recommendations. Baseline 2 Model Simulation Results Baseline 2 Backbone Switch Performance The performance of the backbone switch to which all servers and LANs are connected was analyzed. The simulation results are summarized below. Baseline 2 Backbone Switch Performance (refer to , Appendix B) Packets dropped 0

Table ?? - Baseline 2 Backbone Switch Performance Data • The switch appears to have no problems be handling the current volume of traffic from all the LANS and servers as no packets were dropped over the duration of the simulation for all models. Baseline 2 Server Load and Utilization The simulation results for the load and utilization of each server for each model above are summarized below. Geographic

Info Server Order Provisioning; Facilities and Equipment Inventory Server

Customer Database; billing; accounting; trouble tickets Server

Web and email Server

Network Mgt Server

Avg. CPU Utilization (%) for Each Server (refer to Figure ????, Appendix B)

~1.41 ~0.026 ~0.127 ~3.01 ~0.129

Peak Server CPU Utilization (%) (refer to Figure ????, Appendix B)

~3.35 ~0.034 ~0.173 ~13.5 ~0.233

Avg. Server Load (requests/sec) (refer to Figure ????, Appendix B)

~0.720 ~2.56 ~1.430 ~14.42 ~4.51

Peak Server Load (requests/sec) (refer to Figure ????, Appendix B)

~1.79 ~3.30 ~2.07 ~26.57 ~7.62

Table ?? - Baseline 2 Server Load and Utilization Data

Page 6: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 6

• CPU utilization and load across all servers were well within acceptable tolerances. • All observed peaks were well within tolerances and were not areas of concern. Baseline 2 Network Capacity and Utilization (Refer to Figure ????, Figure ????, Figure ????, Appendix B) Avg. Link Utilization - All Links (%)

very low: avg. << 1.0 % across all links

Peak Link Utilization - All Links (%)

very low: 1.24 max link utilization from web server to backbone switch, max << 1.0 for all other links

Table ?? - Baseline 2 Network Capacity and Utilization Data

• All links were being lightly utilized. • All observed peaks were well within tolerances and were not areas of concern. Model V Simulation Results Model V Backbone Switch Performance The performance of the backbone switch to which all servers and LANs are connected was analyzed. The simulation results are summarized below. Model V Backbone Switch Performance (refer to , Appendix B) Packets dropped 0

Table ?? - Model V Backbone Switch Performance Data • The addition of server based videoconferencing seems to have little effect on the performance of the backbone switch. • The switch appears to have no problems be handling the current volume of traffic from all the LANS and servers as no packets were dropped over the duration of the simulation for all models. Model V Server Load and Utilization The simulation results for the load and utilization of each server for each model above are summarized below. Geographic

Info Server Order Prov; Facilities and Equipment Inventory Server

Customer Database; billing; accounting; trouble tickets Server

Web and email Server

Network Mgt Server

Videoconf Server

Avg. CPU Utilization (%) for Each Server (refer to Figure ????, Appendix B)

~1.43 ~0.026 ~0.126 ~3.02 ~0.120 0.0

Peak Server CPU Utilization (%) (refer to Figure ????, Appendix B)

~5.10 ~0.049 ~0.200 ~20.3 ~0.320 0.0

Avg. Server Load ~0.728 ~2.52 ~1.38 ~13.9 ~4.18 0.0

Page 7: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 7

(requests/sec) (refer to Figure ????, Appendix B) Peak Server Load (requests/sec) (refer to Figure ????, Appendix B)

~2.67 ~4.83 ~2.28 ~40.8 ~10.7 0.0

Table ?? - Model V Server Load and Utilization Data

• No observed peaks were areas of concern. • It is worth noting, however, the addition of videoconferencing appears to slightly increase the overall load and CPU utilization across all servers, most notably the web and email server. Potential problems with server load as a result of future expansion will likely occur first with the web and email server. • It was noted the videoconferencing server had practically no load and zero CPU utilization which seems to be consistent with the idea that the server essentially acts as a facilitator that allows videoconferencing to take place between workstations. In essense, it can be thought of as a pass thru that directs video traffic from one workstation to another and differentiates between multiple sessions of videoconferencing that could be taking place at any given time. Therefore, the amount of server CPU utilization and load will be minimal. Of course, it reality, the server would need some minimum CPU time and utilization to accomplish this task. Other videoconferencing tasks such video processing and compression takes place on the client workstations. Model V Network Capacity and Utilization (Refer to Figure ????, Figure ????, Figure ????, Appendix B) Avg. Link Utilization (%) Eng LAN to/from backbone switch ~54.0% Backbone switch to/from videoconf server ~54.0% test workstation to/from Eng LAN (10BaseT link) ~13.4% all other links avg. << 1.0% Peak Link Utilization - (%) Eng LAN to/from backbone switch ~58.0 Backbone switch to/from videoconf server ~57.0 test workstation to/from Eng LAN (10BaseT link) ~14.5% all other links avg. << 1.0%

Table ?? - Model V Network Capacity and Utilization Data • Link utilization on the 10BaseT link between two workstations during videoconferencing sessions are well within acceptable tolerances. • It is assumed that there are multiple videoconferencing sessions in progress so that link utilization from the Eng LAN object and the backbone switch should reflect the aggregate traffic that is directed from 40 workstations to the videoconferencing server. Likewise, the link between the backbone switch and the videoconferencing server should be the same (traffic on the first link continues on to through the bridge to the link to the videoconferencing server).

Page 8: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 8

Recommended actions to be taken by TEC and concluding remarks

Appendix A: Model Descriptions

Page 9: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 9

Appendix B: Supporting Simulation Results and Statistics

SIMULATION RESULTS - Baseline Model 2

Figure A1 Baseline 2 Backbone Switch Packets Dropped

Figure A2 Baseline 2 CPU Utilization (%) of Each Server

Figure A3

Page 10: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 10

Baseline 2 Load (requests/sec) on Each Server

Figure A4 Baseline 2 Server Load (request/sec) by Application - Database (heavy, light)

Figure A5 Baseline 2 Server Load by Application - Email (light)

Figure A6 Baseline 2 Server Load by Application - FTP (light, heavy)

Figure A7 Baseline 2 Server Load by Application - HTTP (light)

Page 11: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 11

Figure A8 Baseline 2 Link Utilization - point to point (%) Across all Links

Figure A9 Baseline 2 Link Utilization - point to point (%) Across All Links 2

Page 12: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 12

SIMULATION RESULTS - Model V

Figure B1 Model V Backbone Switch Packets Dropped

Figure B2 Model V CPU Utilization (%) of Each Server

Figure B3 Model V Load (requests/sec) on Each Server

Figure B4 Model V Server Load (request/sec) by Application - Database (heavy, light)

Page 13: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 13

Figure B5 Model V Server Load by Application - Email (light)

Figure B6 Model V Server Load by Application - FTP (light, heavy)

Figure B7 Model V Server Load by Application - HTTP (light)

Figure B8 Model V Link Utilization - point to point (%) Across all Links

Page 14: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 14

Figure B9 Model V Link Utilization - point to point (%) Across All Links 2

Model V - Modified with 1000BaseX (Gigabit Ethernet) Links

Figure C1 Model V - Modified Link Utilization (%) - point to point across all links

Page 15: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 15

Page 16: IT Business Proposal Part 2 - Mapping the New Network to Business Requirements

Page 16