Description
This documentaion describes about Operations management covers topics on capacity planning, Categorizing Network Traffic , Sizing and Utilization Guidelines,Reporting, capacity Planning for testing websites (Infosys).
OPERATIONS MANAGEMENT
PROJECT ON CAPACITY PLANNING SYSTEMs
Transforming Network Capacity Planning from an Art to a
Science
Cisco IT Case Study / Network Capacity Planning / Cisco IOS NetFlow: This case study describes Cisco IT’s network capacity planning process and its internal deployment of Cisco IOS NetFlow and third-party solutions within the Cisco network, a leading-edge enterprise environment that is one of the largest and most complex in the world. Cisco customers can draw on Cisco IT’s real-world experience in this area to help support similar enterprise needs. “Having tools that allow us to identify the applications consuming bandwidth is absolutely indispensable. A granular view of what’s happening in our network has allowed us to forecast our need for additional WAN links and budget effectively several quarters out.” -- Joe Silver, Cisco IT Project Manager Background Of all the issues faced by enterprise companies in managing their networks, capacity planning is one of the most important. More an art than a science until recently, network capacity planning is all about balancing the need to meet user performance expectations against the realities of capital budgeting. WAN bandwidth is expensive. Many companies—and Cisco Systems® is no exception—attempt to control costs by acquiring the minimum bandwidth necessary to handle traffic on a circuit. Unfortunately, this strategy can lead to congestion and degraded application performance. A WAN circuit running at 80 percent of capacity is too full. Even a circuit that averages 60 percent of capacity may well peak at 95 percent of capacity for several periods during a day, reducing user productivity and negatively affecting business activities. Many IT organizations order new circuits (which can take anywhere from 30 to 90 days to deploy) when a circuit operates at 60 to 80 percent of capacity. As recently as 2000, Cisco® relied almost exclusively on Simple Network Management Protocol (SNMP) to monitor overall WAN bandwidth utilization. Measuring overall traffic, however, does little to characterize network traffic, which is essential to deciding if additional capacity is warranted. Without knowing what types of traffic are using the network, it is impossible to know if quality of service (QoS) parameters for applications such as voice or video support target service levels. Complicating the challenges of traffic characterization is the reality that many new applications use a range of dynamic ports. These dynamic ports may also be used by several different applications within the enterprise.
Challenge Through the late 1990s, Cisco operated only 140 Frame-Relay-based WAN sites in the United States. Bandwidth capacity was sub T-1. However, in 2000, WAN utilization began to increase rapidly, doubling every 12 to 18 months, degrading application performance, and affecting business operations. Driving bandwidth consumption were voice over IP (VoIP, or Internet telephony) and video on demand (VoD), which share the network with more conventional uses, including e-mail, Internet access, and PC backups. Frequently, Cisco IT engineers found that traffic congestion on some network links had significantly reduced user productivity. Though IT knew that traffic was increasing exponentially and that actual usage was not in line with expectations, it did not have access to the level of detail necessary to understand the true nature of problem. This made it almost impossible to make informed decisions about bandwidth upgrades. “Cisco had no clearly established proactive capacity planning process,” says Keith Brumbaugh, Cisco IT Global Network Engineer. “We tended to implement upgrades in reaction to internal customer complaints rather than solid data. And in the early 2000s we were finding ourselves overwhelmed by the traffic from new applications such as voice and video. We were particularly concerned, because VoIP is sensitive to latency and jitter. Poor voice performance in our environment could detract from its business value.” From experience, the network capacity planning team knew that a few applications can consume most of the WAN bandwidth on a given network segment. Further, the team knew that with visibility into the top 10 applications, along with the top 10 traffic pairs, it was possible to accurately identify and characterize 70 percent or more of network traffic. Any one of these top 10 applications can occupy 10 percent or more of a segment’s bandwidth—and when analysis extends beyond these applications, it shows that consumption quickly fades. In fact, any application not in the top 10 probably uses less than one percent of available bandwidth. “Almost half of Cisco IT’s WAN backbone traffic consists of data backup such as database syncs, server-to-server, PC backup, and SnapMirror, which is used to back up engineering data,” says Brumbaugh. QoS: An Aside A surprising number of IT staff at large enterprises believe that networks built with high-capacity switches, multi-gigabit backplanes, and high-speed LAN and WAN links should never need QoS management. They believe that the more bandwidth available, the less QoS is needed. All networks have congestion points where data packets can be dropped—WAN links where a larger trunk funnels data into a smaller one, or a location where several trunks funnel data into fewer outputs (Figure 1). Applying QoS does not create additional bandwidth. Rather, it helps smooth the peaks and valleys of network circuit utilization. QoS provides more consistent network performance from the point of view of users.
Figure 1. Congestion Point Examples
From a capacity planning standpoint, deploying QoS uniformly across the network protects important realtime voice and video applications—guaranteeing bandwidth and/or low latency—from occasional traffic spikes that can affect performance. Because of this measure of protection, Cisco IT planners believe that QoS settings must be deployed globally on all appropriate network devices in order for capacity planning to be fully effective. Cisco planners also discovered that while most capacity planning occurs at the circuit level, it is also desirable where possible to plan within individual classes of service. It is possible to oversubscribe one or more classes of service without reaching utilization levels that would affect a circuit’s overall performance. It is especially important to do this type of planning when using WAN technologies such as Multiprotocol Label Switching (MPLS), virtual private networks (VPNs), or Asynchronous Transfer Mode (ATM). Carriers, in addition to charging for a circuit, also charge for these classes of service. Managing the bandwidth levels of these individual classes of service ensures proper application performance without overspending for a particular class of service. Solution Categorizing Network Traffic Cisco IT began its efforts toward improving the capacity planning process by categorizing network traffic into three types: • Legitimate, business-related traffic – Companies build their networks to accommodate legitimate, business-related traffic. If a link is at capacity and all traffic is legitimate, then a network upgrade may be necessary. A factor influencing this decision is that some legitimate traffic, such as backups, file transfers, or VoD replication, can be scheduled outside of peak utilization hours. The ability to make scheduling changes can often postpone the need for an upgrade. “When we first implemented a new application to back up user PC hard drives across the network, we seriously underestimated the impact it would have on the WAN—especially smaller branch WAN links,” says Joe Silver, Cisco IT Project Manager. “While backups were done incrementally, the initial backup was always large— and when we first deployed the application, they were all initial backups. After looking at the performance problems, and realizing they were created by a legitimate application that would eventually stop needing so much bandwidth, we decided to avoid WAN upgrades. Instead, we asked
the application developers to schedule all initial backups after hours. When they did, the problem was solved.” • Inappropriate traffic – Traffic in this category can include everything from recreational Internet downloads to viruses, worms, or distributed denial of service (DDoS) attacks. Capacity planners have discovered that it is not important or even desirable to eliminate recreational traffic entirely, until it begins to significantly affect bandwidth availability and compete with the top 10 applications. Investigating and eliminating inappropriate traffic may postpone the need for bandwidth upgrades while improving performance for business-related activities. “At one point, one of our larger offices was running into performance problems, which we eventually traced to one person who was uploading and downloading a tremendous number of files at work,” says Brumbaugh. “Because this was not business-related, we talked directly with that individual about Cisco’s policy regarding non-work-related behavior. The performance problems cleared right up.” Unwise traffic – Harder to describe than inappropriate or legitimate traffic, unwise traffic can result from how and where business-related applications are used. Backups or database synchronizations performed at inappropriate times or over inappropriate segments of the network are obvious offenders. Traffic consuming significant bandwidth during peak hours that can be safely moved or rescheduled is unwise traffic. Determining which traffic fits this category is the responsibility of the capacity planning engineer. In many cases, applying standard QoS configurations automatically slows unwise traffic by marking it “scavenger-class” and not allowing it to impinge on other traffic during hours of peak use. Interestingly, unwise traffic is not necessarily scavenger-class traffic. During traffic analysis, capacity planning engineers can choose to reschedule, eliminate, or categorize traffic as scavenger-class. “Clients were complaining about WAN performance between our Irvine office and headquarters in San Jose,” says Silver. “After the analysis, we determined that the circuit was congested with SnapMirror backup traffic. SnapMirror backs up servers in the data center and is not considered mission-critical. Working with the backup team, we decided to categorize backups as scavenger-class, which allowed them to be throttled back during times of congestion. We avoided a bandwidth upgrade, and overall WAN performance improved immediately.”
•
Capacity planning should provide volume and content traffic information to network architects, designers, and operators—making it possible to size the network accurately while meeting business requirements. Capacity planning should also provide management and finance executives with the data required for budgeting and forecasting by pointing out which connections are approaching saturation and will require an upgrade. Sizing and Utilization Guidelines Cisco planners believed it was vital to establish sizing and utilization guidelines to serve as baselines for managing network capacity (Tables 1 and 2). The planning team found that initial sizing guidelines based on headcount were appropriate for most Cisco field sales offices. However, bandwidth generalizations were not always appropriate for some engineering and extranet sites and Internet POP locations. These types of locations required evaluation on a site-by-site basis. Equally important, planners realized that while guidelines were important, they did not eliminate the need for an engineering analysis to ensure that the bandwidth solution was appropriate for each location.
Table 1.
Sample Initial Sizing Chart
Table 2. Sample Utilization Threshold Chart
Headcount 1–10 1.5 11–40 41–100 101–150 151–200 201–500 501+
Primary WAN Secondary WAN Bandwidth Bandwidth Mbps None 1.5 Mbps 3 Mbps 4.5 Mbps 6 Mbps 45 Mbps 155 Mbps
* Percentage Primary/Backup Utilization WAN Bandwidth (Watch/Analyze) *** 100/100 **** 100/50 ***** 50/50 60% 40% 40%
** Percentage Utilization (Upgrade) 80% 50% 50%
1.5 Mbps 3 Mbps 4.5 Mbps 6 Mbps 6 Mbps 45 Mbps
15-minute average threshold exceeded 10 percent or more during local business hours (monthly) **15-minute average threshold exceeded or equaled 20 percent of local business hours (monthly) *** Primary circuit handles 100-percent of the traffic until failure, when the backup takes over **** Primary circuit handles 100-percent of the traffic until failure, when the backup takes over with 50 percent of the capacity of the primary ***** Primary and backup circuits load-share until a failure occurs. Whether provisioning bandwidth at a new location or deciding when to upgrade an existing circuit, Cisco lanners were acutely aware that their decisions must be cost-effective Though established guidelines were usually appropriate, planners found that in some locations, higher-bandwidth circuits were less expensive than lower-bandwidth solutions. In these cases, capacity planners based decisions on cost, rather than the bandwidth actually required.
*
The Tools Cisco characterized, analyzed, and detected anomalies in network traffic flows using Cisco IOS NetFlow technology, including NetQoS ReporterAnalyzer, their selected third-party reporting solution.This solution used the data captured by Cisco IOS NetFlow to report on network traffic.. Cisco IOS NetFlow (Figure 2) has become the primary network accounting and anomaly detection technology in the network industry. In fact, in 2003, Cisco IOS NetFlow Version 9 was chosen for a proposed IETF standard, the IP Flow Information Export (IPFIX). IPFIX defines the format by which IP flow information is transferred from an exporter, such as a Cisco router, to an application that analyzes data. Essentially, we turned on NetFlow with no negative impact to the network,” says Brumbaugh. “It didn’t create CPU or memory problems on routers, and collecting the data didn’t saturate our WAN links. We never used probes—they are intrusive, and there tend to be scalability issues. We selected NetQoS as our capacity planning application largely because it took advantage of the Cisco IOS NetFlow capability present on all our routers.” “NetFlow also saved us time,” adds Silver. “Though the system does require some attention, it is minimal compared to what we had to do five years ago. Back then, our IP accounting system was very hands-on. It could take 20 hours to harvest data—20 very tedious hours—and the results were often poor. Now, we get detailed data in a matter of minutes.” Reporting Cisco regularly performs capacity planning on existing locations, though it is currently not practical to perform detailed ongoing analysis on every circuit. Reports generated by Cisco IOS NetFlow, plus size and utilization guidelines, help planners determine the circuits they must watch and where bandwidth augmentation is necessary. Global capacity planners are alerted proactively when circuits reach established thresholds via daily, weekly, and monthly reports that highlight circuits above the established “watch/analyze” threshold of 60-percent utilization for 10 percent or more of local peak traffic hours.
Results When the capacity planning team determines that bandwidth augmentation is necessary, it provides a recommendation to Cisco IT’s network operations, where it is reviewed by IT network engineers and managers. Once it is determined that an upgrade is necessary, proceeding with the upgrade becomes a business decision. “I’d been seeing a steady increase in bandwidth utilization on our circuit to India over the past 12 months,” says Brumbaugh.“I knew that if it continued at that rate, the link would be saturated quickly.Because I knew at a granular level what the traffic was, I could comfortably help build a business case for increasing bandwidth. It’s great to work with real information.” After going through Cisco IT’s network design process, the architects and engineers in IT decided they needed to begin a major upgrade in the design of the Cisco India WAN and the backbone links connecting India to the rest of the world. In addition to providing business decision makers with hard data and communicating with them more effectively, Cisco capacity planners can now prioritize and manage deployments better—delivering bandwidth before performance deteriorates and productivity decreases. A coherent planning process has also made it easier to understand the impact of application rollouts. The result has been an improved relationship with the application team—both groups can better plan and budget activities that affect each other’s operations. Lessons Learned “We’re guessing that many of the problems we experienced are shared by 99 percent of the enterprises out there,” says Silver. “What we learned, very simply, is that attempts to plan network capacity without appropriate tools are inaccurate and expensive. We knew that we needed to improve both our tools and our processes —and when we did, we realized that the money we spent implementing NetFlow was low in relation to the amount we had been spending without it.” Next Steps The Cisco capacity planning team plans to use Cisco IOS NetFlow technology to develop an even more detailed view of network traffic. In a MPLS environment, where the enterprise pays its bandwidth circuit providers differentially for different classes of service, it is important not to pay for service that is unnecessary. By monitoring and reporting on classes of service at a deeper level, Cisco expects to be able align what it pays for service with what is actually needed, saving significantly going forward.
Capacity Planning for testing web--sites
Ajit Sarangi and Rakesh Agarwal Infosys Technologies Limited, India {ajitsarangi}{rakesh_a}@infy.com Abstract: In the recent times it has been found that many web-based projects are unable to meet the deadline and this is because of their lack of understanding of capacity planning and its implications on system architecture and design. Capacity planning does not only tells us about the space required by each user on the disk (in a server) but it provides us with the correct methodology for network design, reliability and testing considerations. This paper discusses and gives practical examples of how capacity planning is performed for Web site’s server and network hardware. 1. Introduction Maximizing output and minimizing input is the goal of Capacity Planning. Capacity planning[1][2] is the process of measuring a Web site's ability to serve content to its visitors at an acceptable speed. In other words capacity planning is the process of determining the future network resource requirements. Testing a web-site which may in seconds encounter million of hits is a very difficult and tedious method. Capacity planning[3][2] helps in testing by measuring the number of hits to the site which in turn gives the computing resources (CPU, disk space, RAM, and network bandwidth). Testing a web site driven by capacity planning is determined by three factors[2][4]: 1. Number of hits per unit time. The popularity of the site increases the number of accesses made to the site, which in turn leads to performance degradation. 2. Hardware and software configuration. The servers having a better hardware and software configuration will increase the site's capacity. 3. Amount of content. More the contents of a web site (text, picture, graphic, etc) will result in the servers having to do more work per user, thereby lowering the performance of the site.
Capacity planning is important so that web-based application give a better response to the user. Sites that do not have sufficient capacity to serve all of their users will frustrate them with slow response times, timeouts and errors, and broken links[1][4]. There are three factors that provide full potential to a site: Service quality, Content quality and the speed at which the content and service are accessed. Capacity planning[3][4] allows us to make sure that the site delivers quality content to users at a rapid speed. If capacity planning is measured[5] incorrectly, or no action is taken based on the recommendations from the capacity planning reports, then users may choose to go elsewhere to find better service, quality, and speed[6][7].
The process capacity planning which will provide better testing results can be categorized into five major areas[2][3][6][7]: Understanding the existing network configuration Workload Characterization Data sets of different scenarios Required deliverables Statistical analysis and reporting Understanding the existing network configuration Data sets of different scenarios Statistical analysis and reporting
Workload Characterization
Required deliverables Figure 1: Stages in Capacity Planning Figure 1 shows the different stages in capacity planning. Understanding the existing network configuration will provide information about the present network configuration and resource requirements. This analysis describes the current performance of the network. Workload characterization is the process by which the capacity planner will identify the resources that are affecting the required workload. It identifies what users do on the network on average. This will give an analysis of the computing resources required to do those jobs. The Data sets of different scenarios is the store of the collected measurement information. There should be a provision of test cases and the results delivered..
The Required deliverables are the service level agreements that need to be provided to the end user in context of accuracy, timeliness and reliability. These are often determined and driven by the business objectives identified. The Statistical analysis and reporting of capacity planning deals with the analysis of data to project future capacity requirements and management must have timely, accurate information. Various modeling and simulation tools may be employed to perform these tasks. This paper gives an outline of how to do capacity planning of a particular system to achieve better results in testing. A method is given which is based on a real life study for a project. 2. Determinants of performance The essence of performance diagnosis is to determine which factor is creating bottleneck in the system. The corrective solution depends on proper diagnosis
Following are the major key factors that need to be considered before the application’s capacity and performance is evaluated. These factors also play a key role in evaluating the scalability of the application. 1) Hardware (Includes the network) 2) Number of transaction 3) Number of concurrent user 4) Number of graphics Image 5) Complexity of the Architecture 6) System Up time After considering the above factors the goal of the application can be fixed and various methods, as described in the following sections, can be used to achieve the set goal. Thus, the sequences of steps followed are: ? Determine and set the objective. ? Adopt any one of the methods described below to evaluate the architecture decided. ? Fine tune and optimize the architecture to bench mark the results. ? Extrapolate the benchmarked results to arrive at the final capacity of the application. In general the factors that affect the scalability of the server and long-term strategy are tabulated below. These factors also affect the cost per transaction. Determinant Number of Transaction Per cost transaction Number of concurrent user From the metric shown in Figure 2, we can infer the following: 1) With low cost, and without optimization, the performance will be low. 2) With high cost and unplanned implementation, the performance still remains low. 3) With high cost and planned implementation of architecture, performance can be increased easily. 4) With proper planning and capacity optimization, desirable high performance can be achieved at much lower cost. Current Factor X Y z Increase in 3 Yrs. 30% 10% 10%
Published as part of the proceedings of
High
Desirable
Easy
Performance
Low
Initial
Unplanned
Low Cost
High
Figure 2: Cost performance matrix
3. Performance diagnosis in practice Based on the above metric parameter a sophisticated method is needed in actual practice. We will improve performance diagnostic system by making it a more quantifiable technique. Theory of effective Capacity planning – cost optimization
The Total cost can be defined as T = ?iCi + F TC = Total Cost
C
F = Fixed cost of Installation C = Cost of configuration for a specific services
i
i = Number of services in the web server (varies from 1 to number of services) Ci = ? f [j] where f [j] is the function of j, represents the optimized cost at point marked as X in the graph for each component j = number of resources like CPU, RAM, Network, Cache
4. Methods Capacity planning methods can be categorized as follows: ? Primitive Approach ? MBO approach ? Cost Approach 4.1. Primitive Approach The Primitive method is outlined in Figure 3. Since this method is followed at a very early stage, based on previous experiences, the hardware is chosen. After an initial selection of the hardware and development of
Published as part of the proceedings
software, the web site is subjected to the load test using a web load-testing tool. The results obtained by load testing are analyzed and the bottlenecks in the code are identified and resolved. After fine tuning the code for bottlenecks, the web load test is performed again and the results obtained are benchmarked for the hardware configuration and the number of concurrent users. Based on these benchmark results, the results can be extrapolated for changed hardware configuration and users and the capacity and performance of the web site analyzed.
This can be done at system testing stage of the Development Life cycle.
Select sample hardware
Simulate with specific Load
Analyze & Bench Mark the Result
Extrapolate the profile
Figure 3: Primitive approach
4.2. MBO Approach: (Manage by Objective) In the MBO approach the objective is fixed before hand and the tests are performed to determine the optimum hardware requirement. The target load is identified and by iterative methods, the target hardware is determined such that there is optimization of resources and cost.
Define Threshold Load Choose Target Hardware Build Result Set on Load Fine Tune Parameter Extrapolate the profile
Figure 4: MBO approach
After determining the target hardware and fixing the load, web load testing tool is used to analyze the performance and cost of the system and to determine the bottlenecks, if any. . Generic Components of a Testing tool The tool monitors the response time of an Internet or Intranet Web server for the request of the client and stores with configured setting. Tools simulate the activity of a Web server and its many client Web browsers communicating across one or more networks. Primary subsystems for the tools: a server, a client, Some of the offloading tools available a controller and the network. Webload 4 A comprehensive testing and analysis solution to combine scalability, performance and integrity as a single process for testing of Web applications. More information about this tool can be found at http://www.radview.com/products/index.asp LoadRunner : A load testing tool that predicts system behavior and performance and exercises an entire enterprise infrastructure by emulating thousands of users to identif y and isolate problems. It supports multiple environments. Astra Load Test : An interactive automated testing tool for transactional Web applications. It offers the easiest way to test the scalability and performance of Web applications. It emulates the traffic of hundreds or thousands of real users to identify and isolate bottlenecks, optimize performance and overall user experience. WinRunner : An integrated and functional testing tool for entire enterprise. It captures, verifies and replays user interactions automatically. This helps to
identify defects and ensure that business processes, which span across multiple applications and databases. More information about this tool can be found at http://www-heva.mercuryinteractive.com/products/winrunner/ CYRANO WEBTESTER : It is an end-to-end quality assurance provider to its customers, helping them maximize their IT investments and ensure uninterrupted e-business. The tool includes: functional testing, load testing and regression testing. More information about this tool can be found at www.cyrano.com/products/webtester.html e-Load : This gives the fastest and accurate way to test the scalability of Web applications. Companies use it regularly to accurately assess the load capacity of their applications. More information about this tool can be found at http://www.empirix.com/empirix/web+test+monitoring/products/ 7. CONCLUSION Capacity planning is an important aspect of developing good quality websites; proper planning ensures a healthy network that can grow to meet future need s[3]. Many companies depend on web-based applications to simplify business processes so that applications can run efficiently on the networks. The Primitive Approach or the MBO approach or the Cost Approach helps in predicting scalability, reliability and performance issues of an e-business application. This is essential for understanding an application’s limitations. Load testing tools tests system behavior under real-time conditions and converts this data into easy-tous
DSS Case Study Introduction
The DSS, one of the largest telecommunications company in Mexico, the company offers a wide portfolio of telecommunications services to different sized companies from all sectors. It also offers services comprising voice and data transmission to virtual private networks (VPNs), integrated telecommunications packages and managed services. Their demand level changes quite often, and so do their capacity requirements. Thus there was a need of developing a capacity plan so as to make their cost minimum or rather must say optimum. The initial capacity of the network is 128 units of bandwidth and the demand is tabulated and visualised in figure below.
Demand forecast for DSS throughout the year
In our analysis the constant lead time used by the company is reported to be 4 months for their suppliers and 3 types of equipments are available to provide the capacity.
Equipment type Card Capacity per Equipment I II III 5 10 8 Bandwidth Capacity per card 18 6 12 Unit Cost per equipment $1,000.00 $1,500.00 $1,500.00 Unit Cost per card $1,500.00 $1,000.00 $900.00
Table 1:- The Characteristics of the equipments and their costs
Solution
When the problem was being solved; this capacity planning problem with the DSS; at a service level of 85%, the results suggested that two capacity expansions be carried out: the first one in
month 5 and the second one in month 10. The first expansion requires the purchase of 75 units of bandwidth via equipment type III with 7 cards. For the second expansion of 31 units of bandwidth, equipment type I with 2 cards should be bought, incurring cost of $11,800.00 in total.
Results obtained by using the DSS technique for the capacity planning and scheduling A closer look to the solution prescribed by the DSS, will show how the fact that it takes 4 months from the time when a decision is made to expand the network´s capacity to actually having that additional capacity leads to potentially not meeting the demand on two months of the 4. Increasing the service level will certainly not improve the solution here, as it has to do with the suppliers’ lead time. Because varying any of the parameters in the technique applied by DSS will show the results for the capacity expansion schedule in a matter of seconds, using inventory control techniques in this phase of the planning problem dramatically decreases the required analysis time as opposed to solving a mixed integer programming problem. This is especially true considering that many times different demand forecasts must be evaluated to decide if an investment will be made in a capacity expansion. As a final verdict comes through it must be added that the distribution of the DSS throughout the company was extremely easy with the chosen platform. It also took very little effort to the users to become acquainted with the tool. So overall the Capacity planning was giving in a huge advantage to the firm.
It optimized the Inventory management system of the company too.In our analysis the constant lead time used by the company is reported to be 4 months for their suppliers and 3 types of equipments are available to provide the capacity. The characteristics of each equipment are summarized in Table When we solved this capacity expansion problem with the DSS at a service level of 85%, the results suggested that two capacity expansions be carried out: the first one in month 5 and the second one in month 10. The first expansion requires the purchase of 75 units of bandwidth via equipment type III with 7 cards. For the second expansion of 31 units of bandwidth, equipment type I with 2 cards should be bought, incurring cost of $11,800.00 in total. Figure 7 shows us the results obtained by using the DSS for the capacity expansion schedule. CONCLUSION In this work, inventory control techniques were applied in a real capacity planning problem in Telecommunications capitalizing in the similarities between the two problems. The problem of inventory control has been largely studied, however to the best extent of our knowledge, no real life application to capacity planning has been reported in the telecommunications area. Using inventory control models has been shown to give an efficient solution to the original capacity planning problem. The associated equipment selection problem was approached through the use of a typical mathematical programming model. Finally a DSS was developed to integrate the proposed techniques for their actual application in the industry. The results presented in this work underline the importance of establishing similarities among problems of different areas to capitalize in their corresponding solution techniques. In particular, the use of standard industrial engineering techniques in new areas, such as telecommunications, does provide significant development opportunities for the discipline.
doc_206729204.doc
This documentaion describes about Operations management covers topics on capacity planning, Categorizing Network Traffic , Sizing and Utilization Guidelines,Reporting, capacity Planning for testing websites (Infosys).
OPERATIONS MANAGEMENT
PROJECT ON CAPACITY PLANNING SYSTEMs
Transforming Network Capacity Planning from an Art to a
Science
Cisco IT Case Study / Network Capacity Planning / Cisco IOS NetFlow: This case study describes Cisco IT’s network capacity planning process and its internal deployment of Cisco IOS NetFlow and third-party solutions within the Cisco network, a leading-edge enterprise environment that is one of the largest and most complex in the world. Cisco customers can draw on Cisco IT’s real-world experience in this area to help support similar enterprise needs. “Having tools that allow us to identify the applications consuming bandwidth is absolutely indispensable. A granular view of what’s happening in our network has allowed us to forecast our need for additional WAN links and budget effectively several quarters out.” -- Joe Silver, Cisco IT Project Manager Background Of all the issues faced by enterprise companies in managing their networks, capacity planning is one of the most important. More an art than a science until recently, network capacity planning is all about balancing the need to meet user performance expectations against the realities of capital budgeting. WAN bandwidth is expensive. Many companies—and Cisco Systems® is no exception—attempt to control costs by acquiring the minimum bandwidth necessary to handle traffic on a circuit. Unfortunately, this strategy can lead to congestion and degraded application performance. A WAN circuit running at 80 percent of capacity is too full. Even a circuit that averages 60 percent of capacity may well peak at 95 percent of capacity for several periods during a day, reducing user productivity and negatively affecting business activities. Many IT organizations order new circuits (which can take anywhere from 30 to 90 days to deploy) when a circuit operates at 60 to 80 percent of capacity. As recently as 2000, Cisco® relied almost exclusively on Simple Network Management Protocol (SNMP) to monitor overall WAN bandwidth utilization. Measuring overall traffic, however, does little to characterize network traffic, which is essential to deciding if additional capacity is warranted. Without knowing what types of traffic are using the network, it is impossible to know if quality of service (QoS) parameters for applications such as voice or video support target service levels. Complicating the challenges of traffic characterization is the reality that many new applications use a range of dynamic ports. These dynamic ports may also be used by several different applications within the enterprise.
Challenge Through the late 1990s, Cisco operated only 140 Frame-Relay-based WAN sites in the United States. Bandwidth capacity was sub T-1. However, in 2000, WAN utilization began to increase rapidly, doubling every 12 to 18 months, degrading application performance, and affecting business operations. Driving bandwidth consumption were voice over IP (VoIP, or Internet telephony) and video on demand (VoD), which share the network with more conventional uses, including e-mail, Internet access, and PC backups. Frequently, Cisco IT engineers found that traffic congestion on some network links had significantly reduced user productivity. Though IT knew that traffic was increasing exponentially and that actual usage was not in line with expectations, it did not have access to the level of detail necessary to understand the true nature of problem. This made it almost impossible to make informed decisions about bandwidth upgrades. “Cisco had no clearly established proactive capacity planning process,” says Keith Brumbaugh, Cisco IT Global Network Engineer. “We tended to implement upgrades in reaction to internal customer complaints rather than solid data. And in the early 2000s we were finding ourselves overwhelmed by the traffic from new applications such as voice and video. We were particularly concerned, because VoIP is sensitive to latency and jitter. Poor voice performance in our environment could detract from its business value.” From experience, the network capacity planning team knew that a few applications can consume most of the WAN bandwidth on a given network segment. Further, the team knew that with visibility into the top 10 applications, along with the top 10 traffic pairs, it was possible to accurately identify and characterize 70 percent or more of network traffic. Any one of these top 10 applications can occupy 10 percent or more of a segment’s bandwidth—and when analysis extends beyond these applications, it shows that consumption quickly fades. In fact, any application not in the top 10 probably uses less than one percent of available bandwidth. “Almost half of Cisco IT’s WAN backbone traffic consists of data backup such as database syncs, server-to-server, PC backup, and SnapMirror, which is used to back up engineering data,” says Brumbaugh. QoS: An Aside A surprising number of IT staff at large enterprises believe that networks built with high-capacity switches, multi-gigabit backplanes, and high-speed LAN and WAN links should never need QoS management. They believe that the more bandwidth available, the less QoS is needed. All networks have congestion points where data packets can be dropped—WAN links where a larger trunk funnels data into a smaller one, or a location where several trunks funnel data into fewer outputs (Figure 1). Applying QoS does not create additional bandwidth. Rather, it helps smooth the peaks and valleys of network circuit utilization. QoS provides more consistent network performance from the point of view of users.
Figure 1. Congestion Point Examples
From a capacity planning standpoint, deploying QoS uniformly across the network protects important realtime voice and video applications—guaranteeing bandwidth and/or low latency—from occasional traffic spikes that can affect performance. Because of this measure of protection, Cisco IT planners believe that QoS settings must be deployed globally on all appropriate network devices in order for capacity planning to be fully effective. Cisco planners also discovered that while most capacity planning occurs at the circuit level, it is also desirable where possible to plan within individual classes of service. It is possible to oversubscribe one or more classes of service without reaching utilization levels that would affect a circuit’s overall performance. It is especially important to do this type of planning when using WAN technologies such as Multiprotocol Label Switching (MPLS), virtual private networks (VPNs), or Asynchronous Transfer Mode (ATM). Carriers, in addition to charging for a circuit, also charge for these classes of service. Managing the bandwidth levels of these individual classes of service ensures proper application performance without overspending for a particular class of service. Solution Categorizing Network Traffic Cisco IT began its efforts toward improving the capacity planning process by categorizing network traffic into three types: • Legitimate, business-related traffic – Companies build their networks to accommodate legitimate, business-related traffic. If a link is at capacity and all traffic is legitimate, then a network upgrade may be necessary. A factor influencing this decision is that some legitimate traffic, such as backups, file transfers, or VoD replication, can be scheduled outside of peak utilization hours. The ability to make scheduling changes can often postpone the need for an upgrade. “When we first implemented a new application to back up user PC hard drives across the network, we seriously underestimated the impact it would have on the WAN—especially smaller branch WAN links,” says Joe Silver, Cisco IT Project Manager. “While backups were done incrementally, the initial backup was always large— and when we first deployed the application, they were all initial backups. After looking at the performance problems, and realizing they were created by a legitimate application that would eventually stop needing so much bandwidth, we decided to avoid WAN upgrades. Instead, we asked
the application developers to schedule all initial backups after hours. When they did, the problem was solved.” • Inappropriate traffic – Traffic in this category can include everything from recreational Internet downloads to viruses, worms, or distributed denial of service (DDoS) attacks. Capacity planners have discovered that it is not important or even desirable to eliminate recreational traffic entirely, until it begins to significantly affect bandwidth availability and compete with the top 10 applications. Investigating and eliminating inappropriate traffic may postpone the need for bandwidth upgrades while improving performance for business-related activities. “At one point, one of our larger offices was running into performance problems, which we eventually traced to one person who was uploading and downloading a tremendous number of files at work,” says Brumbaugh. “Because this was not business-related, we talked directly with that individual about Cisco’s policy regarding non-work-related behavior. The performance problems cleared right up.” Unwise traffic – Harder to describe than inappropriate or legitimate traffic, unwise traffic can result from how and where business-related applications are used. Backups or database synchronizations performed at inappropriate times or over inappropriate segments of the network are obvious offenders. Traffic consuming significant bandwidth during peak hours that can be safely moved or rescheduled is unwise traffic. Determining which traffic fits this category is the responsibility of the capacity planning engineer. In many cases, applying standard QoS configurations automatically slows unwise traffic by marking it “scavenger-class” and not allowing it to impinge on other traffic during hours of peak use. Interestingly, unwise traffic is not necessarily scavenger-class traffic. During traffic analysis, capacity planning engineers can choose to reschedule, eliminate, or categorize traffic as scavenger-class. “Clients were complaining about WAN performance between our Irvine office and headquarters in San Jose,” says Silver. “After the analysis, we determined that the circuit was congested with SnapMirror backup traffic. SnapMirror backs up servers in the data center and is not considered mission-critical. Working with the backup team, we decided to categorize backups as scavenger-class, which allowed them to be throttled back during times of congestion. We avoided a bandwidth upgrade, and overall WAN performance improved immediately.”
•
Capacity planning should provide volume and content traffic information to network architects, designers, and operators—making it possible to size the network accurately while meeting business requirements. Capacity planning should also provide management and finance executives with the data required for budgeting and forecasting by pointing out which connections are approaching saturation and will require an upgrade. Sizing and Utilization Guidelines Cisco planners believed it was vital to establish sizing and utilization guidelines to serve as baselines for managing network capacity (Tables 1 and 2). The planning team found that initial sizing guidelines based on headcount were appropriate for most Cisco field sales offices. However, bandwidth generalizations were not always appropriate for some engineering and extranet sites and Internet POP locations. These types of locations required evaluation on a site-by-site basis. Equally important, planners realized that while guidelines were important, they did not eliminate the need for an engineering analysis to ensure that the bandwidth solution was appropriate for each location.
Table 1.
Sample Initial Sizing Chart
Table 2. Sample Utilization Threshold Chart
Headcount 1–10 1.5 11–40 41–100 101–150 151–200 201–500 501+
Primary WAN Secondary WAN Bandwidth Bandwidth Mbps None 1.5 Mbps 3 Mbps 4.5 Mbps 6 Mbps 45 Mbps 155 Mbps
* Percentage Primary/Backup Utilization WAN Bandwidth (Watch/Analyze) *** 100/100 **** 100/50 ***** 50/50 60% 40% 40%
** Percentage Utilization (Upgrade) 80% 50% 50%
1.5 Mbps 3 Mbps 4.5 Mbps 6 Mbps 6 Mbps 45 Mbps
15-minute average threshold exceeded 10 percent or more during local business hours (monthly) **15-minute average threshold exceeded or equaled 20 percent of local business hours (monthly) *** Primary circuit handles 100-percent of the traffic until failure, when the backup takes over **** Primary circuit handles 100-percent of the traffic until failure, when the backup takes over with 50 percent of the capacity of the primary ***** Primary and backup circuits load-share until a failure occurs. Whether provisioning bandwidth at a new location or deciding when to upgrade an existing circuit, Cisco lanners were acutely aware that their decisions must be cost-effective Though established guidelines were usually appropriate, planners found that in some locations, higher-bandwidth circuits were less expensive than lower-bandwidth solutions. In these cases, capacity planners based decisions on cost, rather than the bandwidth actually required.
*
The Tools Cisco characterized, analyzed, and detected anomalies in network traffic flows using Cisco IOS NetFlow technology, including NetQoS ReporterAnalyzer, their selected third-party reporting solution.This solution used the data captured by Cisco IOS NetFlow to report on network traffic.. Cisco IOS NetFlow (Figure 2) has become the primary network accounting and anomaly detection technology in the network industry. In fact, in 2003, Cisco IOS NetFlow Version 9 was chosen for a proposed IETF standard, the IP Flow Information Export (IPFIX). IPFIX defines the format by which IP flow information is transferred from an exporter, such as a Cisco router, to an application that analyzes data. Essentially, we turned on NetFlow with no negative impact to the network,” says Brumbaugh. “It didn’t create CPU or memory problems on routers, and collecting the data didn’t saturate our WAN links. We never used probes—they are intrusive, and there tend to be scalability issues. We selected NetQoS as our capacity planning application largely because it took advantage of the Cisco IOS NetFlow capability present on all our routers.” “NetFlow also saved us time,” adds Silver. “Though the system does require some attention, it is minimal compared to what we had to do five years ago. Back then, our IP accounting system was very hands-on. It could take 20 hours to harvest data—20 very tedious hours—and the results were often poor. Now, we get detailed data in a matter of minutes.” Reporting Cisco regularly performs capacity planning on existing locations, though it is currently not practical to perform detailed ongoing analysis on every circuit. Reports generated by Cisco IOS NetFlow, plus size and utilization guidelines, help planners determine the circuits they must watch and where bandwidth augmentation is necessary. Global capacity planners are alerted proactively when circuits reach established thresholds via daily, weekly, and monthly reports that highlight circuits above the established “watch/analyze” threshold of 60-percent utilization for 10 percent or more of local peak traffic hours.
Results When the capacity planning team determines that bandwidth augmentation is necessary, it provides a recommendation to Cisco IT’s network operations, where it is reviewed by IT network engineers and managers. Once it is determined that an upgrade is necessary, proceeding with the upgrade becomes a business decision. “I’d been seeing a steady increase in bandwidth utilization on our circuit to India over the past 12 months,” says Brumbaugh.“I knew that if it continued at that rate, the link would be saturated quickly.Because I knew at a granular level what the traffic was, I could comfortably help build a business case for increasing bandwidth. It’s great to work with real information.” After going through Cisco IT’s network design process, the architects and engineers in IT decided they needed to begin a major upgrade in the design of the Cisco India WAN and the backbone links connecting India to the rest of the world. In addition to providing business decision makers with hard data and communicating with them more effectively, Cisco capacity planners can now prioritize and manage deployments better—delivering bandwidth before performance deteriorates and productivity decreases. A coherent planning process has also made it easier to understand the impact of application rollouts. The result has been an improved relationship with the application team—both groups can better plan and budget activities that affect each other’s operations. Lessons Learned “We’re guessing that many of the problems we experienced are shared by 99 percent of the enterprises out there,” says Silver. “What we learned, very simply, is that attempts to plan network capacity without appropriate tools are inaccurate and expensive. We knew that we needed to improve both our tools and our processes —and when we did, we realized that the money we spent implementing NetFlow was low in relation to the amount we had been spending without it.” Next Steps The Cisco capacity planning team plans to use Cisco IOS NetFlow technology to develop an even more detailed view of network traffic. In a MPLS environment, where the enterprise pays its bandwidth circuit providers differentially for different classes of service, it is important not to pay for service that is unnecessary. By monitoring and reporting on classes of service at a deeper level, Cisco expects to be able align what it pays for service with what is actually needed, saving significantly going forward.
Capacity Planning for testing web--sites
Ajit Sarangi and Rakesh Agarwal Infosys Technologies Limited, India {ajitsarangi}{rakesh_a}@infy.com Abstract: In the recent times it has been found that many web-based projects are unable to meet the deadline and this is because of their lack of understanding of capacity planning and its implications on system architecture and design. Capacity planning does not only tells us about the space required by each user on the disk (in a server) but it provides us with the correct methodology for network design, reliability and testing considerations. This paper discusses and gives practical examples of how capacity planning is performed for Web site’s server and network hardware. 1. Introduction Maximizing output and minimizing input is the goal of Capacity Planning. Capacity planning[1][2] is the process of measuring a Web site's ability to serve content to its visitors at an acceptable speed. In other words capacity planning is the process of determining the future network resource requirements. Testing a web-site which may in seconds encounter million of hits is a very difficult and tedious method. Capacity planning[3][2] helps in testing by measuring the number of hits to the site which in turn gives the computing resources (CPU, disk space, RAM, and network bandwidth). Testing a web site driven by capacity planning is determined by three factors[2][4]: 1. Number of hits per unit time. The popularity of the site increases the number of accesses made to the site, which in turn leads to performance degradation. 2. Hardware and software configuration. The servers having a better hardware and software configuration will increase the site's capacity. 3. Amount of content. More the contents of a web site (text, picture, graphic, etc) will result in the servers having to do more work per user, thereby lowering the performance of the site.
Capacity planning is important so that web-based application give a better response to the user. Sites that do not have sufficient capacity to serve all of their users will frustrate them with slow response times, timeouts and errors, and broken links[1][4]. There are three factors that provide full potential to a site: Service quality, Content quality and the speed at which the content and service are accessed. Capacity planning[3][4] allows us to make sure that the site delivers quality content to users at a rapid speed. If capacity planning is measured[5] incorrectly, or no action is taken based on the recommendations from the capacity planning reports, then users may choose to go elsewhere to find better service, quality, and speed[6][7].
The process capacity planning which will provide better testing results can be categorized into five major areas[2][3][6][7]: Understanding the existing network configuration Workload Characterization Data sets of different scenarios Required deliverables Statistical analysis and reporting Understanding the existing network configuration Data sets of different scenarios Statistical analysis and reporting
Workload Characterization
Required deliverables Figure 1: Stages in Capacity Planning Figure 1 shows the different stages in capacity planning. Understanding the existing network configuration will provide information about the present network configuration and resource requirements. This analysis describes the current performance of the network. Workload characterization is the process by which the capacity planner will identify the resources that are affecting the required workload. It identifies what users do on the network on average. This will give an analysis of the computing resources required to do those jobs. The Data sets of different scenarios is the store of the collected measurement information. There should be a provision of test cases and the results delivered..
The Required deliverables are the service level agreements that need to be provided to the end user in context of accuracy, timeliness and reliability. These are often determined and driven by the business objectives identified. The Statistical analysis and reporting of capacity planning deals with the analysis of data to project future capacity requirements and management must have timely, accurate information. Various modeling and simulation tools may be employed to perform these tasks. This paper gives an outline of how to do capacity planning of a particular system to achieve better results in testing. A method is given which is based on a real life study for a project. 2. Determinants of performance The essence of performance diagnosis is to determine which factor is creating bottleneck in the system. The corrective solution depends on proper diagnosis
Following are the major key factors that need to be considered before the application’s capacity and performance is evaluated. These factors also play a key role in evaluating the scalability of the application. 1) Hardware (Includes the network) 2) Number of transaction 3) Number of concurrent user 4) Number of graphics Image 5) Complexity of the Architecture 6) System Up time After considering the above factors the goal of the application can be fixed and various methods, as described in the following sections, can be used to achieve the set goal. Thus, the sequences of steps followed are: ? Determine and set the objective. ? Adopt any one of the methods described below to evaluate the architecture decided. ? Fine tune and optimize the architecture to bench mark the results. ? Extrapolate the benchmarked results to arrive at the final capacity of the application. In general the factors that affect the scalability of the server and long-term strategy are tabulated below. These factors also affect the cost per transaction. Determinant Number of Transaction Per cost transaction Number of concurrent user From the metric shown in Figure 2, we can infer the following: 1) With low cost, and without optimization, the performance will be low. 2) With high cost and unplanned implementation, the performance still remains low. 3) With high cost and planned implementation of architecture, performance can be increased easily. 4) With proper planning and capacity optimization, desirable high performance can be achieved at much lower cost. Current Factor X Y z Increase in 3 Yrs. 30% 10% 10%
Published as part of the proceedings of
High
Desirable
Easy
Performance
Low
Initial
Unplanned
Low Cost
High
Figure 2: Cost performance matrix
3. Performance diagnosis in practice Based on the above metric parameter a sophisticated method is needed in actual practice. We will improve performance diagnostic system by making it a more quantifiable technique. Theory of effective Capacity planning – cost optimization
The Total cost can be defined as T = ?iCi + F TC = Total Cost
C
F = Fixed cost of Installation C = Cost of configuration for a specific services
i
i = Number of services in the web server (varies from 1 to number of services) Ci = ? f [j] where f [j] is the function of j, represents the optimized cost at point marked as X in the graph for each component j = number of resources like CPU, RAM, Network, Cache
4. Methods Capacity planning methods can be categorized as follows: ? Primitive Approach ? MBO approach ? Cost Approach 4.1. Primitive Approach The Primitive method is outlined in Figure 3. Since this method is followed at a very early stage, based on previous experiences, the hardware is chosen. After an initial selection of the hardware and development of
Published as part of the proceedings
software, the web site is subjected to the load test using a web load-testing tool. The results obtained by load testing are analyzed and the bottlenecks in the code are identified and resolved. After fine tuning the code for bottlenecks, the web load test is performed again and the results obtained are benchmarked for the hardware configuration and the number of concurrent users. Based on these benchmark results, the results can be extrapolated for changed hardware configuration and users and the capacity and performance of the web site analyzed.
This can be done at system testing stage of the Development Life cycle.
Select sample hardware
Simulate with specific Load
Analyze & Bench Mark the Result
Extrapolate the profile
Figure 3: Primitive approach
4.2. MBO Approach: (Manage by Objective) In the MBO approach the objective is fixed before hand and the tests are performed to determine the optimum hardware requirement. The target load is identified and by iterative methods, the target hardware is determined such that there is optimization of resources and cost.
Define Threshold Load Choose Target Hardware Build Result Set on Load Fine Tune Parameter Extrapolate the profile
Figure 4: MBO approach
After determining the target hardware and fixing the load, web load testing tool is used to analyze the performance and cost of the system and to determine the bottlenecks, if any. . Generic Components of a Testing tool The tool monitors the response time of an Internet or Intranet Web server for the request of the client and stores with configured setting. Tools simulate the activity of a Web server and its many client Web browsers communicating across one or more networks. Primary subsystems for the tools: a server, a client, Some of the offloading tools available a controller and the network. Webload 4 A comprehensive testing and analysis solution to combine scalability, performance and integrity as a single process for testing of Web applications. More information about this tool can be found at http://www.radview.com/products/index.asp LoadRunner : A load testing tool that predicts system behavior and performance and exercises an entire enterprise infrastructure by emulating thousands of users to identif y and isolate problems. It supports multiple environments. Astra Load Test : An interactive automated testing tool for transactional Web applications. It offers the easiest way to test the scalability and performance of Web applications. It emulates the traffic of hundreds or thousands of real users to identify and isolate bottlenecks, optimize performance and overall user experience. WinRunner : An integrated and functional testing tool for entire enterprise. It captures, verifies and replays user interactions automatically. This helps to
identify defects and ensure that business processes, which span across multiple applications and databases. More information about this tool can be found at http://www-heva.mercuryinteractive.com/products/winrunner/ CYRANO WEBTESTER : It is an end-to-end quality assurance provider to its customers, helping them maximize their IT investments and ensure uninterrupted e-business. The tool includes: functional testing, load testing and regression testing. More information about this tool can be found at www.cyrano.com/products/webtester.html e-Load : This gives the fastest and accurate way to test the scalability of Web applications. Companies use it regularly to accurately assess the load capacity of their applications. More information about this tool can be found at http://www.empirix.com/empirix/web+test+monitoring/products/ 7. CONCLUSION Capacity planning is an important aspect of developing good quality websites; proper planning ensures a healthy network that can grow to meet future need s[3]. Many companies depend on web-based applications to simplify business processes so that applications can run efficiently on the networks. The Primitive Approach or the MBO approach or the Cost Approach helps in predicting scalability, reliability and performance issues of an e-business application. This is essential for understanding an application’s limitations. Load testing tools tests system behavior under real-time conditions and converts this data into easy-tous
DSS Case Study Introduction
The DSS, one of the largest telecommunications company in Mexico, the company offers a wide portfolio of telecommunications services to different sized companies from all sectors. It also offers services comprising voice and data transmission to virtual private networks (VPNs), integrated telecommunications packages and managed services. Their demand level changes quite often, and so do their capacity requirements. Thus there was a need of developing a capacity plan so as to make their cost minimum or rather must say optimum. The initial capacity of the network is 128 units of bandwidth and the demand is tabulated and visualised in figure below.
Demand forecast for DSS throughout the year
In our analysis the constant lead time used by the company is reported to be 4 months for their suppliers and 3 types of equipments are available to provide the capacity.
Equipment type Card Capacity per Equipment I II III 5 10 8 Bandwidth Capacity per card 18 6 12 Unit Cost per equipment $1,000.00 $1,500.00 $1,500.00 Unit Cost per card $1,500.00 $1,000.00 $900.00
Table 1:- The Characteristics of the equipments and their costs
Solution
When the problem was being solved; this capacity planning problem with the DSS; at a service level of 85%, the results suggested that two capacity expansions be carried out: the first one in
month 5 and the second one in month 10. The first expansion requires the purchase of 75 units of bandwidth via equipment type III with 7 cards. For the second expansion of 31 units of bandwidth, equipment type I with 2 cards should be bought, incurring cost of $11,800.00 in total.
Results obtained by using the DSS technique for the capacity planning and scheduling A closer look to the solution prescribed by the DSS, will show how the fact that it takes 4 months from the time when a decision is made to expand the network´s capacity to actually having that additional capacity leads to potentially not meeting the demand on two months of the 4. Increasing the service level will certainly not improve the solution here, as it has to do with the suppliers’ lead time. Because varying any of the parameters in the technique applied by DSS will show the results for the capacity expansion schedule in a matter of seconds, using inventory control techniques in this phase of the planning problem dramatically decreases the required analysis time as opposed to solving a mixed integer programming problem. This is especially true considering that many times different demand forecasts must be evaluated to decide if an investment will be made in a capacity expansion. As a final verdict comes through it must be added that the distribution of the DSS throughout the company was extremely easy with the chosen platform. It also took very little effort to the users to become acquainted with the tool. So overall the Capacity planning was giving in a huge advantage to the firm.
It optimized the Inventory management system of the company too.In our analysis the constant lead time used by the company is reported to be 4 months for their suppliers and 3 types of equipments are available to provide the capacity. The characteristics of each equipment are summarized in Table When we solved this capacity expansion problem with the DSS at a service level of 85%, the results suggested that two capacity expansions be carried out: the first one in month 5 and the second one in month 10. The first expansion requires the purchase of 75 units of bandwidth via equipment type III with 7 cards. For the second expansion of 31 units of bandwidth, equipment type I with 2 cards should be bought, incurring cost of $11,800.00 in total. Figure 7 shows us the results obtained by using the DSS for the capacity expansion schedule. CONCLUSION In this work, inventory control techniques were applied in a real capacity planning problem in Telecommunications capitalizing in the similarities between the two problems. The problem of inventory control has been largely studied, however to the best extent of our knowledge, no real life application to capacity planning has been reported in the telecommunications area. Using inventory control models has been shown to give an efficient solution to the original capacity planning problem. The associated equipment selection problem was approached through the use of a typical mathematical programming model. Finally a DSS was developed to integrate the proposed techniques for their actual application in the industry. The results presented in this work underline the importance of establishing similarities among problems of different areas to capitalize in their corresponding solution techniques. In particular, the use of standard industrial engineering techniques in new areas, such as telecommunications, does provide significant development opportunities for the discipline.
doc_206729204.doc