Decision on virtualisation
Virtual Infrastructure discussion
Recommendation Virtualisation should not be included at this time
There are a number of widely recognised advantages that can be realised using virtualisation. Industry wide the top 5 key advantages include
- Cost Reduction, reduced numbers of physical infrastructure to manage and you can reduce hardware maintenance costs because of a lower number of physical servers.
- Consolidation, you can increase the space utilization efficiency in your data center and move resources to where they can most do the work.
- Containment, by having each application within its own "virtual server" you can prevent one application from impacting another application when upgrades or changes are made.
- Consistency, you can develop a standard virtual server build that can be easily duplicated which will speed up server deployment.
- Capability, you can deploy multiple operating system technologies on a single hardware platform (i.e. Windows Server 2003, Linux, Windows 2000, etc).
Cost Reduction This project proposes use of x86 infrastructure irrespective of whether virtualisation is adopted. This infrastructure will be purchased with 5 year maintenance already accounted for. Typically x86 infrastructure can be purchased at a lower price point while at the same time outperforms sparc. Past experience has also shown that adoption of Sparc has resulted in a very restricted upgrade potential and upgrade costs are prohibitively expensive even for relatively modest increases. An example of this is where we have expanded memory in a sparc infrastructure only to find that the costs of such an upgrade are many times more expensive and poorer performing than memory for x86 infrastructure. We have concluded that Virtualisation would not significantly reduce costs further in this case simply because the model proposed will require approximately 10 individual servers to implement regardless.
Consolidation Virtualisation technologies typically allow infrastructure to be presented as small Virtual Machines hosted within a larger infrastructure. Small machines can then be moved from physical server to physical server thus balancing load across the server real estate. This makes it possible to maximise the performance of the datacentre and also balance the load to ensure that under peak workload periods, like the start of term, the infrastructure is working to its maximum potential and there are no hot spots. Reports have been received however that in the existing virtual infrastructure problems have been observed migrating larger VMs with large footprints over to more lightly loaded infrastructure. The service UniDesk uses a virtualised database infrastructure and this has refused to migrate after having been set to do so. It is not possible to compare the configuration of the TopDesk database with an Oracle database as the underlying technology is quite different but it is possible to appreciate that it is likely that a database behaving with high levels of IO might suffer the same effects. This would mean that during periods of stress the database may well not be possible to migrate to another infrastructure. Given these existing observations there is a considerable risk that with even more heavily loaded infrastructure these issues may well present
Containment Containment prevents one infrastructure from affecting another. This can be achieved in virtual infrastructure by creating virtual machines with defined limits on resource that can be consumed. This is particularly useful for services that have very dynamic memory or cpu demands. Database services tend to be more well behaved and it is unlikely that we would implement a 1-1 relationship between databases and Operating systems or VMs. Given the role of this infrastructure to primarily handle the Oracle Database infrastructure we can assume that it will behave well and limits on resource consumption can be defined on a database by database level. Because of this it is unlikely and possibly unnecessary to take advantage of this capability.
Consistency It is possible to rapidly deploy consistent virtual machines using templates to enable rapid provisioning. This is idea in ensuring that servers are built using a known standard. Time is invested early on in defining the templates and from there on the time required to create a VM based on the template can be significant reduced. This is particularly the case is many VMs need to be build. The model proposed will require an Operating System for each of the hosts. Existing provisioning technologies will be applicable in this case. Virtualisation would not significantly improve the existing processes given the small number of Operating Systems required.
Capability The initial requirements of the project will require only that we have the capability to run Linux on the server infrastructure. At this time we have no intention of running multiple operating systems within the same physical infrastructure. It is therefore not currently a requirement that we can meet this as a requirement
Additional points for consideration
- Currently support for Oracle on VMWare is problematic at best and if necessary to pursue a support issue Oracle could require us to move services from a virtual infrastructure to a physical. Oracle offers its own virtualisation technology Oracle VM, this is the technology they will support.
- Costs for 5 years have been estimated at ~200K to implement VMWare, the backup agents and maintenance. This would not offer root cause resolution, (Martin can you estimate costs for this?)
- Adoption of Virtualisation that need be taken at this time albeit a good opportunity to review the advantages it might be able to offer. Implementation could be carried out at any time quite transparently and P-V migrations carried out.
The design will make use of both physical DataCentres at Kings Buildings and Appleton Tower, both sites being considered active.
Databases will be replicated and mirrored across sites using Oracle DataGuard. The relationship will allow bi directional replication but each database pair will be configued in a Master/Slave configuration
Database status will be assessed using an observer server located in Old College