Server Virtualization scheme Risks

Server virtualization task risks

It is well known that no task is risk-free. Things can go bad and unfortunately they often go bad. Identification and determination of task risks is a topic with an widespread literature. There are risks that are base to all projects (generic risks), and others that are due to the exact features of the task (specific risks). So for instance, since every task has an end date, every task has the generic risk of not being completed in time. In this record we shall focus on those risks that are specific of server virtualization projects and to the exact features of generic risks in server virtualization projects.

Home Media Server

Performance risks in server sever virtualization projects

In a new application implementation task it is very difficult to size the systems because no workload data is available. On the contrary in a server virtualization task associates have widespread workload data. Unfortunately, not all the time there is the will to secure and analyze them.

There are basically three strategies to mitigate the risk of undersizing systems and therefore of having an excessive response latency:

• Oversizing;
• Extensive experimentation; and
• Data collection and analysis.

Oversizing is a very base strategy. The basic rationale is that Hw is so cheap that it has diminutive sense to spend time to recognize the exact requirements. However, it is important to remember that unless you make experimentations or an in-depth assessment, you do not know either you are no ifs ands or buts oversizing or undersizing the systems. You even do not know either you are virtualizing the right applications. You can adopt an aggressive approach, and then as a consequence have complaints from users about principles performance; or you can adopt a cautious approach, and then have a virtual server farm scope much smaller of what could have been. widespread experimentation is a good but costly alternative. Typically systems are sized agreeing to rule-of-thumbs and generic policies (e.g., Dbmss should not be virtualized) and only those that are supposed to have valuable overheads are no ifs ands or buts tested. Unfortunately rule-of-thumbs are often unreliable and generic policies gloss over the exact features of virtual servers. Data collection and determination is the ideal approach. There are however several important challenges:

• Simultaneous data collection from tens or hundreds or servers.
• Cleaning and determination of workload data containing tens of thousands of data points.
• Identification of the optimal virtual server farm out of the collected data.
• Estimate of the virtualization layer impact on the workloads.

Each of these challenges can be efficiently handled with thorough data collection tools. The Wasfo Data accumulator and Wasfo determination and Optimization tools (see references below) have been advanced and designed exactly with this purpose.

High Availability risks in server virtualization projects

In a non virtual server farms there are very few applications that are classified mission valuable and are protected with High Availability (Ha) clusters. Ha clusters can significantly enhance the assistance availability insofar as Hw and application failures are concerned. Unfortunately they are costly and complicated to maintain. Ha clusters protect against server, Os and application failure but they require:

• Shared warehouse (not all Ha technologies want shared warehouse but those most widely distributed do);
• Ha software;
• Scripts or Dlls that recognize failed applications and shut them down in a quarterly way; and
• Overall certification of the explication to get retain from all the curious vendors.

Hypervisors (also known as Virtual machine Monitors or virtualization layer) thanks to the fact that Virtual Machines images are no ifs ands or buts files hosted on a shared warehouse make it possible to create server farms in which all application instances are protected from server failure. If any server fails, a monitoring assistance will detect the failure and turn on the Vm on another server. Unfortunately these technologies monitor and act at the hypervisor level so they do not deliver any security in case of application failure or freeze. If such a security is required Ha cluster Sw can be used on top of the virtualization layer.

Another important point is that hypervisors, thanks to the fact that Virtual Machines can be moved at runtime with no assistance interruption (live migration), make minimal the impact of planned server outages. If, for instance, a server needs to be rebooted to convert a failed component, the server can be first moved to another server so that the user operation is not interrupted.

Security risks in server virtualization projects

If you crusade Google for "virtualization risk" you will find tens of articles on security risks. That proves that security is the most important concern citizen have as far as virtualization task risks are concerned. citizen are commonly involved about what they do not know well because one of the underlying determinants of human behaviour is the need to have some form of operate of the surrounding environment. Virtualization is not an exception. In these projects a whole new set of products is introduced; and those that already are up and running need to be configured in new ways. So a cautious approach is not only recommended by mandatory.

Since there are so many articles on virtualization and security colse to in the web we shall not spend time here to go through all security concerns. We shall limit ourselves to point out that unless strong operate processes are in places in a virtual server farm it is far easier to create new Os systems. So it is not surprising that citizen after a while examine fullness of Virtual Machines that have been created for development or testing purposes and that are no ifs ands or buts not managed in professional way. They could for instance not have the latest security patches or not being configured agreeing to the business security standards. Strong operate processes may look to be the spoton explication but strong operate significantly diminishes the advantage of increased flexibility we get through virtualization. A great alternative is likely to use a weaker operate process and then periodically start a server farm account to spot possible security holes.

Costs

Project costs all too often exceed expectations and there are thousands of pages written on how to operate the task so that costs do not exceed the budget. Virtualization projects have a exact issues linked to Sw licensing. Depending on the Sw licensing rules the virtualization task can yield valuable savings or cost increases. If the application is licensed agreeing to the amount of bodily cores even when it runs on top of a Virtual machine Monitor the cost will likely increase, looking that virtual servers have typically many more processor cores than those required by any of the hosted Sw applications. If on the contrary the application license takes into account the amount of logical cores or the principles utilization you may realize valuable savings.

Conclusions

There are many risks in server virtualization projects that could offset or even exceed the task benefits. spoton planning and determination are required to mitigate the performance, availability and security risks; as well as to ensure that the expected financial benefits are accrued.

Server Virtualization scheme Risks