- Given a scenario, gather and analyze application requirements
This is what would be included in your current-state analysis For example we have a scenario where we have been told to virtualise all exchange servers. we would:
- Capture baseline performance metrics including average and peak loads, using tools like perfmon or Cap planner
- Identify any unique scenarios or non standard implementations of the application
- identify reusable hardware
- what if any service rely on the application of if this application relys on another service to run.(Application dependencies)
- Decided on virtualisation candidates and non virtualisation candidates.
- Given a set of applications within a physical environment, determine the requirements for virtualization.
This is very similar to the above scenario every application needs to be taken into account. Data should be collected for a minimum of 1 month, the longer usage/peaks/averages are collected the more accurate the baselines are.
General rule of thumb for the average application:
- If the application runs on JAVA, RAM will need to be reserved
- Does the application make use of Large Paging tables
- What is the IO requirement for the application
- What storage mode is needed
Then you can break off into individual known application requirements like:
- Oracle
- Use Large Memory Pages – In the case of using large memory pages you must be aware that this will hinder the use of Transparent Page Sharing for the VMs memory.
- Use Oracle Automatic Storage Management
- Set Memory Reservations equal to size of Oracle SGA
- Exchange
- RDMs can be used as a migration strategy from a physical to virtual world.
- Use the Microsoft Exchanges Servie Profile Analyzer to estimate workloads.
- SQL
- Use Large Memory Pages
- MSCS
- Uses RDM’s in physical compatibility mode and SCSI bus sharing in Physical mode
- Gather information needed in order to identify application dependencies.
gathering the application dependencies requires allot of Du diligence and would require either a very well documented application diagrams or tools like RUM (real user monitoring) or VIN (vmware infrastructure navigator) these will map out applications and what they talk to.
Make sure workload is collected, the longer these collections can run the better, as this will identify the peak workloads more accurately I have found that sometimes you just have to make a best guess, The company i work for has a peak time of year and unless its running for a full 12 months you would never get an accurate view of the environment and that is just not practical for most people.
- Given one or more application requirements, determine the impact of the requirements on the design.
This is very application specific, but for an example if a client had a large volume of JAVA based applications, this would impact the ability to over commit memory which then in turn will impact the requirements of the design. like resource pools, reservations and how much RAM is available is more needed etc.