A Business Case for Windows And Linux
Executive Summary
To accomplish a fair economic or Total Cost of Ownership (TCO) assessment of Windows and Linux one needs to see how Windows and Linux will impact the major cost categories of an IT deployment, such as:
For this report each of these cost categories has been examined in great detail using CIOview's TCOnow! for Windows and Linux. This platform analysis software allows a consistent evaluation approach to be in place and, perhaps most importantly, ensures different model scenarios can be easily tested under a variety of "what-if" scenarios. For example, one can see rapidly how migrating existing IT functions, such as Firewalls and Print/File functions can result in the need for fewer boxes and a corresponding reduction in IT staff. Then you can proceed to drill down on the major cost categories to review and possibly change the underlying assumptions. All cost categories have at least two levels of detail that can be examined and subsequently changed. In fact, you can drill down to the level of changing the cost of power to reflect your local electricity costs as a factor in determining facilities costs.
Irrespective of whether you utilize a software product, sophisticated spreadsheets or a “stubby pencil”, to appreciate the potential economic consequences of Windows and Linux, the very same factors have to be taken into account.
Just the facts ...
Ultimately, the cost of a Windows versus Linux decision will run into the millions if not tens of millions of dollars for many companies. Unless you can take all of the issues discussed here and many more and model them appropriately, there is simply no way to know whether Linux or Windows is a better fit for your company.
TCOnow! for Windows and Linux is designed to help you carry out just this type of analysis. For example, you can specify a variety of consolidation and migration strategies, such as:
CIOview’s TCOnow! software also allows you to run all of these different scenarios and include all of your IT shop’s particular nuances. You can then balance the costs and risks of each strategy and determine whether Linux or Windows Server 2003 is right for you.
Workloads
The type or make-up of the workload being migrated to Windows and Linux not only will have a large impact on the hardware resources needed, it also will impact the possible economics of reduced personnel resources. Therefore it is key to identify workloads accurately as early on in the process as possible. The classic environments typically slated for migration to Windows and Linux are:
Financial Results
Given the information input into TCOnow! your financial costs of deploying Windows and Linux would be as follows:
Chart 1: Total Cost of Ownership over Time
Chart 1 above shows the TCO of Windows compared to that of Linux over the investment time horizon selected within TCOnow! Your TCO is based upon the following assumptions as detailed in Table 1.
Table 1: Total Cost of Ownership (TCO) Assumptions
TCO Assumptions | ||
Primary application | ||
Level of RAID desired |
| |
Hours of Operations |
| |
Size for current or future needs |
| |
Consolidation Strategy |
| |
The assumptions in Table 1 are the key in refining the server configuration, helping to generate the costs associated with downtime and accounting for anticipated growth, or not, as the case may be.
The cost categories selected for this analysis are detailed in Table 2:
Table 2: Cost Categories Selected for Inclusion
Cost Category | Included? |
Servers | |
Software | |
Storage | |
Network | |
Services | |
Training | |
Facilities | |
Personnel | |
Downtime | |
Support and Maintenance |
The comparative costs of deploying your workload using the
Table 3: Comparative Costs Table
Cost Category | Delta | ||
Servers | |||
Software | |||
Storage | |||
Network | |||
Services | |||
Training | |||
Facilities | |||
Personnel | |||
Downtime | |||
Support and Maintenance | |||
Total Cost of Ownership |
Table 3 shows the cost for each solution in each major cost category. It is important to recognize that many of the cost categories feed into each other. As a result, making changes to one category will tend to ripple throughout the entire TCO model. Attaining the lowest TCO tends to an iterative process requiring a great deal of “what-if” analysis. The financial rewards of such an effort can be substantial and in many cases point to other IT endeavors that could benefit from a similar approach.
Table 4 presents the recommended configuration for the two platforms being examined in this analysis. Since the server configuration effectively represents the keystone to TCO, getting the server configuration right is fundamental to an accurate TCO analysis.
Table 4: Recommended Platform Configuration
Category | Vendor 1: | Vendor 2: |
Mixed workload servers and mainframes (z/OS) | ||
File and print application servers | ||
Email application servers | ||
Database application servers | ||
Web application servers | ||
Test and Development Servers | ||
QA Servers | ||
Backup Servers | ||
Other Servers | ||
Mainframe Linux Processors (IFL) |
In turn, Table 5 compares the key system metrics and Total Cost of Ownership (TCO) for your chosen solutions. Table 5 represents a summary method to review the basic TCO assumptions and ensures there is no single item that has been misrepresented.
Table 5: Key Implementation Metrics
Category | Vendor 1: | Vendor 2: |
Number of pre-existing production and non-production servers | ||
Number of new production servers or IFL | ||
Number of new test, QA, & backup servers or virtual machines | ||
Storage dollar cost/megabyte | ||
Number of IT staff | ||
Estimated system-wide availability | ||
Total Cost of Ownership |
The results of this analysis are based on the workloads you specified, your current midrange environment, your current environment, and your personnel assessment. Tables 6A-C summarize your consolidation needs.
Table 6A: Consolidation Model
Category | Value |
Operating System Platform 1 | |
Operating System Platform 2 | |
New Hardware Vendor for Platform 1 | |
New Hardware Vendor for Platform 2 | |
Number of end-users involved in project? | |
Consolidation Model |
Table 6B: Consolidation Requirements
Category | Value |
Assuming no change to your storage infrastructure, how much of your existing storage do you expect to be able to still use if you migrate or consolidate? | |
Storage (GB) | |
RAID level you need on your storage | |
Will you implement network attached storage (NAS) or a storage area network (SAN)? | |
Your hours of operation | |
If your current application runs on more than one server, what would be the impact to your application if one of those servers were to become unavailable? | |
If a production server system component fails and causes a production server failure, what is the maximum allowable wait for a replacement part? | |
Which of your chosen workloads is used most by your IT and business departments to estimate and cost system-wide availability (you may only choose one type of workload)? |
Table 6C: Consolidation Requirements Over Time
Category | Requirement |
Annual average user growth rate for your application | |
Annual average storage growth rate | |
Will you size your servers for your initial needs or to account for all of your expected growth? |
The decision whether to size a system for current requirements or to include the growth requirements envisioned for the investment period is an important question. In sizing for future growth acquisition costs will obviously be higher and in the early years support, software and perhaps even downtime will add to the TCO. However the advantage is no interruption or large scale hardware additions will be required. This is a question that is ripe for “what-if” analysis and is a good example that the beauty of TCO lies in the details.
Over time, the costs associated with your two competing platforms can also be compared. For your first selection,
Table 8: Allocated Cost Summary (Linux )
Initial | Year 1 | Year 2 | Year 3 | Year 4 | Year 5 | |
Servers | ||||||
Software | ||||||
Storage | ||||||
Network | ||||||
Services | ||||||
Training | ||||||
Facilities | ||||||
Personnel | ||||||
Downtime | ||||||
Support and Maint. | ||||||
Total By Year |
Chart 2: Total Cost % by Category (Linux )
The costs over time for the second platform,
Table 9: Allocated Cost Summary (Windows Server 2003 )
Initial | Year 1 | Year 2 | Year 3 | Year 4 | Year 5 | |
Servers | ||||||
Software | ||||||
Storage | ||||||
Network | ||||||
Services | ||||||
Training | ||||||
Facilities | ||||||
Personnel | ||||||
Downtime | ||||||
Support and Maint. | ||||||
Total By Year |
Chart 3: Total Cost % by Category (Windows Server 2003 )
Conclusion
CIOview’s TCOnow! software also allows you to run many different scenarios and include all of your IT shop’s particular nuances. You can then balance the costs and risks of each strategy and determine whether Linux or Windows Server 2003 is right for you. You can also do a very sophisticated “what if” analysis and see how changes to your underlying system design affect your TCO for Linux as compared to Windows. With CIOview’s TCOnow! for Windows and Linux, it becomes easy to see the correct decision, as well as the reasoning behind it.
Introduction
Part and parcel of the economics of Linux and Windows is the central idea that server consolidation also is likely to take place at the same time. As a result, to be able to compare Linux to Windows, there must be an accurate way to identify the optimal server configuration. Determining the optimal server configuration requires a thorough understanding of the workload(s) that are being reviewed for migration, the major factors affecting server configuration and the selection of the appropriate server performance benckmark(s). Unless this can be accomplished in an accurate fashion it is impossible to know what the TCO is for either Linux or Windows.
The Basics
One has to recognize that server requirements largely will be driven by:
In other words, there are a great number of factors that must be taken into account when configuring servers. However, in much the same way that the horsepower of an automobile ultimately determines the performance of a car it is reasonable to expect that a similar measure will be available for servers. For non-car buffs, horsepower is simply one measure of the power output of an engine and usually determines much of a car’s performance up to 100 miles per hour when aerodynamics kick in as a larger factor. There are some pretty simple performance metrics that can be applied across the automobile industry in general that allow a customer to look at a few stats and get a pretty good buyer’s comparison. Since many servers cost several times the cost of even the most exotic car one can surmise that the same type of comparison shopping data will be available for configuring a computer system.
The performance tests or benchmarks that commonly are used for servers include:
TPC
SPEC
SAP
Oracle
Notes
LINPACK
iCOMP
All of these different benchmarks can be extremely useful. However, when vendors report public results one has to bear in mind that the results:
Server Sizes
Benchmarks differ based on how output changes as the size of the server changes. Server size can be thought of as the number of processors, namely:
In a perfect world, growth in server size would relate directly to growth in server output. In other words switching from 2-way to a 4-way would result in a doubling of output. Likewise switching from a 2-way to a 16-way would mean an eight-fold increase in output.
Server Scaling
In a simplified example of server scaling a 1-processor server would produce 1000 units of output at top performance. A 2-processor server would output 2000 units of performance and a 72-processor server would come it at 72,000 units of output. In other words, there is an expectation that performance grows directly with the number of processors on a 1:1 ratio. However, in the real world no server scales at 1:1 or in a perfectly linear fashion. Each new processor added to your server gives only a partial increase in performance. Most commercial IT workloadsshow a scaling curve. In contrast to a single scaling factor, a scaling curve is a collection of scaling factors. As you keep adding new processors, the scaling factor decreases. In other words, adding new processors always runs into the problem of diminishing returns.
Imagine a second workload that shows diminishing returns:
The scaling factors in this workload change substantially as the number of processors increases. The scaling factor from 1-way to 2-way is .97 but the scaling factor from 1-way to 72-way is only .36.
If we create a graph of our first workload showing the output per server related to the number of processors, we would see:
 |
If we create a graph of our second workload showing the output per server related to the number of processors, we would see:
 |
The key point to remember is that the different benchmarks have different scaling curves. As a result if you select the wrong benchmark for configuration purposes it is a foregone conclusion that you either will severely under- or over-configure your servers.
Why does scaling vary?
The ability of a workload to scale depends largely on two factors:
Workloads by definition carry out a very specific type of transaction, e.g.,online purchases, file serving, loan approvals etc. A particular transaction typically can be described as CPU-intense or input-output (IO)-intense. A CPU-intense transaction is limited by the amount and power of the processors on your server. In other words, the transaction mostly involves processing happening in the CPU. Therefore, the number/speed of transactions will grow as soon as you add new CPU power. However,the CPU needs information to do its calculation and it needs to return an answer. After all, there is no point to carrying out an activity that has no input or output. To return to our automobile analogy for a moment, a CPU-only application would be like having an exotic sports car with no wheels, no steering, and no brakes. Excellent examples of CPU-intensive workloads would include:
The two most common CPU-intense benchmarks are SPECint2000 and SPECfp2000. However, before applying these benchmarks to your workload it is worth recalling that each benchmark is designed for specific applications.
SPECint2000 simulates:
Meanwhile SPECfp2000 simulates:
The common characteristics of all these seemingly disparate applications are:
 |
All of these characteristics ultimately translate into a very parallel computing environment. The chart below details the scaling associated with a truly parallel application.
How CPU Intensive is your workload?
Answering that question goes a long way in being able to select which benchmark one should be using for server evaluation purposes. Your workload will become less CPU intensive, as you require:
As your workload involves more data sharing, data locking, and sequential work, your processing performance becomes limited by the ability of the CPU to retrieve and distribute information.
Once your application is constrained by data transfer considerations, it becomes input/output (I/O) intensive. An I/O intense workload is limited by the ability of the CPU to get access to the data necessary to carry out its calculation. In other words, the transaction involves very little processing happening in the CPU. Instead, the transaction involves moving information back and forth.
How I/O Intensive is your workload?
I/O intensive transactions suffer from diminishing CPU returns. In fact I/O workloads exhibit the traits of:
I/O intense applications largely move and manage data. Examples include:
An I/O intense transaction can be described as a serial transaction. In other words, each step happens one after the other instead of in parallel. Serial transactions require internal server bandwidth and large local RAM memory to move data around. Serial transactions are common when your data is unstructured–ad-hoc queries, online bank account access, etc.
The most common published benchmark, TPC-C, is of a relatively I/O intense OLTP workload. TPC-C simulates a warehouse system and includes:
It is characterized by:
Serial workloads by nature have a large need for hard disk access since the transaction involves searching, processing, and manipulating information stored in outside tables. There tends to be a large amount of shared data since each CPU needs to access and manipulate the same exact piece of data, which means that the CPU needs to wait until a different CPU is done. Data locking is required since each transaction must have a number of verification steps (did the transaction finish, is this the right account, etc) that must take place before another CPU can work on the same piece of data. As a result, in a very heterogeneous server environment not only must each CPU wait for information, but your server must also gather data from and return results to a relatively unstructured back-end database or transaction monitor. The chart below depicts the scaling efficiencies associated with a highly serial application.
 |
What does all this mean?
Intellectually interesting as all this may be, how does it translate into sizing a server? In order for us to size our servers correctly, we need to determine how CPU intense versus how I/O intense our application is. Once we know our application characteristics, we then can turn our application requirements (number of users, Web pages per second, etc) into infrastructure requirements (number and size of servers).
The discussion of CPU-intense versus I/O intense easily can become complicated and never-ending. Imagine instead that we have a range of CPU-intense and I/O intense workloads. They can be ordered by degree of CPU-intensity. Doing so also will reveal what applications are very parallel and what applications are very serial.
Let’s create a range of 1 to 25, with 1 equaling very CPU-intense and 25 equaling very I/O-intense. We then can use this scale to rate our application, by examining the following questions:
You then can use your application rating to place yourself on a performance curve. For simplicity purposes, CIOview uses two performance curves to bound our performance estimations. One curve is very CPU-intense and represents our estimate of scaling for a very technical computing workload. This curve represents an application rating of 1. The second curve is very I/O-intense and represents our estimate of scaling for a workload bound almost entirely by I/O considerations. This curve represents an application rating of 25. Your application rating will place you somewhere between these two curves.
 |
Once you estimate where you fall between a CPU-intense performance curve and an I/O-intense performance curve, you can determine the best size of server to deploy (2-way, 4-way, etc). You typically would choose a server size that shows good scaling for your workload. To determine the output of your server you could use a 1-processor server as a reference to determine the potential output of your chosen server. And then finally, you would know the number of servers necessary.
Knowing the characteristics of the workload you are going to deploy is key. One then needs to identify where that workload falls on the serial/parallel continuum. Having done that one must select the performance benchmark most appropriate to your workload, take into consideration how your application scales and then size accordingly.
Software Performance
One of the perceived attractions of Linux is that since the operating system is based on UNIX, it must be technologically superior to Microsoft Windows. Often, the comparison is made to Windows NT4, which had limited flexibility. Or, the comparison is made to a mainframe running Linux, with a whole discussion of the technical merits of a mainframe and of the z/VM virtualization operating system. In many cases, Windows NT4 is not very sophisticated compared to Linux and especially compared to Linux on a mainframe. Just look at the frequency of operating system outages for a single server. While a Linux instance may fail once every 5 years, a Windows NT4 instance will typically fail every 4 months.
But as we all know from other things, such as the stock market, that past performance is no predictor of future returns. Microsoft Windows Server 2003 provides a number of technological features that put it either on par with or, in some cases significantly ahead of, most Linux distributions. These include:
SMP Support-One of the biggest differences between Windows Server 2003 and Linux concerns multi-processor support. Intel Linux is really designed for 1-4 CPU servers (or 1-4 CPU virtual machines on a mainframe), while Windows Server 2003 provides support for up to 8 CPUs with Enterprise Edition and even scales to 32-way servers with Datacenter Edition. This allows Windows Server 2003 to take advantage of larger servers and substantially reduce the number of operating system images necessary.
RAM address ability- Greater RAM address ability compared to Windows NT4 means that each server can access 4GB of RAM per processor, similar to Linux. Using more RAM can improve performance. As a general rule of thumb, doubling RAM per processor will improve overall performance by 10%.
Availability-Windows 2000 Server and Windows Server 2003 are 3 times more reliable than Windows NT4. This substantially reduces the number of actual failures you might expect to experience. Furthermore, Windows Server 2003 provides Microsoft Cluster Service to run 2, 4, and 8-node high availability clusters. In contrast, Linux clustering requires purchasing 3rd party software such as SteelEye LifeKeeper at a cost of roughly $6,000 per server for the license and three years of support and maintenance.
Distributed File System-Of course, running a 2-node 4 or 8-CPU cluster is quite a lot of overkill for a departmental file server or email system. But new technology in Windows Server 2003 is designed to allow Windows applications to take advantage of higher performance servers by consolidating operating system instances. For example, you can use a Distributed File System to encompass all of your existing file and print root targets. Instead of needing a separate Windows NT4 server for each workgroup and root target, you can use a pair of clustered servers to run your entire file system. In contrast, if you run Samba on Linux, you cannot consolidate root targets and you are forced to manage a very distributed file system.
Improved backup and recovery-Instead of maintaining adequate backup time by running a separate Windows NT4 server for each email database, you can now run multiple databases on one Microsoft Windows Server 2003 and Exchange Server 2003 instance. This means that all of your different service levels can be handled on one server cluster instead of on a whole host of distributed machines. In contrast, Linux email systems do not allow this sort of consolidation and keep you in a multiple server, small workload mode.
Even if you run Linux on a mainframe, you will typically need to create a separate virtual machine instance with its own Linux operating system for each file server, email server, Web server, etc. While the mainframe itself can handle capacity management between instances very effectively, you still are faced with the complexity of managing dozens of Linux images compared to two Windows images joined in a cluster.
Servers
One of the simplest ways to determine server needs is to complete an inventory or assessment of what is currently deployed. Table 10 lists the servers in use and their respective average utilization rates.
Table 10a: Hardware Assessment
Item | Workload | Qty | Model | Utilization Rate | |
1. | Production Server 1 | ||||
2. | Production Server 2 | ||||
3. | Production Server 3 | ||||
4. | Production Server 4 | ||||
5. | Production Server 5 | ||||
6. | Test Server | ||||
7. | Development Server | ||||
8. | QA Server | ||||
9. | Backup Server | ||||
10. | Other Server |
In order to assess the financial impact of running your application on a zSeries, TCOnow! needs to know about your current mainframe infrastructure. If you already have an existing mainframe, you may be able to simply add incremental capacity or upgrade to a newer model. Similarly, if you already have mainframe systems management and operations staff in-house, your incremental cost to add new capacity may be quite low. This table inventories your existing mainframe resources, if any.
Table 10b: Current Mainframe Environment
Item | Value | |
1. | What type of mainframe do you have? | |
2. | How many MIPS are on the existing mainframe you wish to include in your new application analysis (Note: this is not the number of MIPS required for your application)? | |
3. | What percentage of your mainframe's processing capacity is already allocated to existing workloads? | |
4. | What is your mainframe's average prime shift utilization rate? | |
5. | What is your average hardware cost per MIPS? | |
6. | What is your annual IBM software cost per MIPS? | |
7. | What is your annual independent software vendor (ISV) ISV software cost per MIPS? | |
8. | How many IT personnel are responsible for managing your mainframe? |
Each of your individual server layers has unique properties that have important implications for your new environment. The tables below contain the assumptions that have been built in to the server sizing process:
File and Print Server - Users
Item | Workload | |
1. | Number of Users | |
2. | How many unique file and print application instances do you currently have? | |
3. | How many users currently access your largest file and print application instance (if you have only 1 unique instance then this should equal the total number of file and print users)? | |
4. | How many unique Windows file and print application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
5. | How many users do you expect to access your largest Windows file and print application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? | |
6. | How many unique Linux Samba file and print application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
7. | How many users do you expect to access your largest Linux Samba file and print application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? |
File and Print Server – New Server Requirements
Item | Workload | |
1. | If a file and print server component fails and causes an outage, what is the maximum allowable wait for a replacement part? | |
2. | How do you wish to set up your new Linux file and print infrastructure? | |
3. | What is the size, in CPUs, of the largest Linux server that can run your application without a reduction in scaling? | |
4. | How do you wish to set up your Windows file and print application images? | |
5. | What is the size, in CPUs, of the largest Windows server that can run your application without a reduction in scaling? | |
6. | How do you wish to add new images to your Current Environment? |
eMail Server - Users
Item | Workload | |
1. | Number of Users | |
2. | How many unique eMail application instances do you currently have? | |
3. | How many users currently access your largest eMail application instance (if you have only 1 unique instance then this should equal the total number of eMail users)? | |
4. | How many unique Windows eMail application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
5. | How many users do you expect to access your largest Windows eMail application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? | |
6. | How many unique Linux Samba eMail application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
7. | How many users do you expect to access your largest Linux Samba eMail application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? |
eMail Server – New Server Requirements
Item | Workload | |
1. | If an eMail server component fails and causes an outage, what is the maximum allowable wait for a replacement part? | |
2. | How do you wish to set up your new Linux eMail infrastructure? | |
3. | What is the size, in CPUs, of the largest Linux server that can run your application without a reduction in scaling? | |
4. | How do you wish to set up your Windows eMail application images? | |
5. | What is the size, in CPUs, of the largest Windows server that can run your application without a reduction in scaling? | |
6. | How do you wish to add new images to your Current Environment? |
Database Server - Users
Item | Workload | |
1. | Number of Users | |
2. | How many unique database application instances do you currently have? | |
3. | How many users currently access your largest database application instance (if you have only 1 unique instance then this should equal the total number of database users)? | |
4. | How many unique Windows database application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
5. | How many users do you expect to access your largest Windows database application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? | |
6. | How many unique Linux Samba database application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
7. | How many users do you expect to access your largest Linux Samba database application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? |
Database Server – New Server Requirements
Item | Workload | |
1. | If a database server component fails and causes an outage, what is the maximum allowable wait for a replacement part? | |
2. | How do you wish to set up your new Linux database infrastructure? | |
3. | What is the size, in CPUs, of the largest Linux server that can run your application without a reduction in scaling? | |
4. | How do you wish to set up your Windows database application images? | |
5. | What is the size, in CPUs, of the largest Windows server that can run your application without a reduction in scaling? | |
6. | How do you wish to add new images to your Current Environment? |
Web Server - Users
Item | Workload | |
1. | Number of Users | |
2. | How many unique web application instances do you currently have? | |
3. | How many users currently access your largest web application instance (if you have only 1 unique instance then this should equal the total number of web users)? | |
4. | How many unique Windows web application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
5. | How many users do you expect to access your largest Windows web application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? | |
6. | How many unique Linux Samba web application instances do you expect to have after any sort of application consolidation (leave the same as above if you are not consolidating applications)? | |
7. | How many users do you expect to access your largest Linux Samba web application instance after migration or consolidation (if you are not consolidating applications then this should equal the answer to question 3)? |
web Server – New Server Requirements
Item | Workload | |
1. | If a web server component fails and causes an outage, what is the maximum allowable wait for a replacement part? | |
2. | How do you wish to set up your new Linux web infrastructure? | |
3. | What is the size, in CPUs, of the largest Linux server that can run your application without a reduction in scaling? | |
4. | How do you wish to set up your Windows web application images? | |
5. | What is the size, in CPUs, of the largest Windows server that can run your application without a reduction in scaling? | |
6. | How do you wish to add new images to your Current Environment? |
Your existing non-production environment is an important influence on your new non-production environment. Displayed below are the characteristics of your existing non-production environment, as well as the assumptions built in to the server sizing for your new environment:
Existing Non-Production Environment
Server | Prime Shift Utilization Rate | Number of Images | |
1. | Test server | ||
2. | Development server | ||
3. | QA server | ||
4. | Backup server |
New Non-Production Environment: Test and Development
New Non-Production Environment: QA and Backup
Table 11 lists the servers that would be required for the server consolidation effort to be undertaken. The server requirements are very much driven by the type of workload that is being migrated, as well as the average utilization rate of the existing and new servers.
Table 11: Servers
Item | Cost Differential | |||
1 | ||||
2 | ||||
3 | ||||
4 | ||||
5 | ||||
6 | ||||
7 | ||||
8 | ||||
9 | ||||
10 | ||||
11 | ||||
12 | ||||
13 | ||||
14 | ||||
15 | ||||
16 | ||||
17 | ||||
18 | ||||
19 | ||||
20 |
Table 12 showcases the utilization rate, quantity and the cost associated with each server that would be required to be purchased for the first solution.
Table 12: Linux Server Costs
Total server cost | |
Percent of server cost you want to allocate | |
Percent of total allocated server cost |
| Item | Utilization Rate | Quantity | Price | Total Cost |
1 | |||||
2 | |||||
3 | |||||
4 | |||||
5 | |||||
6 | |||||
7 | |||||
8 | |||||
9 | |||||
10 | |||||
11 | |||||
12 | |||||
13 | |||||
14 | |||||
15 | |||||
16 | |||||
17 | |||||
18 | |||||
19 | |||||
20 |
Table 13 showcases the utilization rate, quantity and the cost associated with each server that would be required to be purchased for the second solution.
Table 13: Windows Server 2003 Server Costs
Total server cost | |
Percent of server cost you want to allocate | |
Percent of total allocated server cost |
| Item | Utilization Rate | Quantity | Price | Total Cost |
1 | |||||
2 | |||||
3 | |||||
4 | |||||
5 | |||||
6 | |||||
7 | |||||
8 |