The same as with the current virtualisation of desktop applications, servers or storage, the operation of databases on virtual machines also offer some undeniable advantages. In addition to the optimal utilisation of the hardware employed, the resulting savings in electricity, avoidance or limitation of purchases of new equipment and a simplification in the management of the database solution, virtualisation provides still more advantages. Particularly in the case of very resource-hungry database systems, such as data mining for CRM, ERP or BI. Further advantages include:
- Virtual databases can be ‘live migrated’ from one physical server to another without service interruption in case of hardware issues
- Cost-effective and easy implementation of high-availability solutions
- Flexible, dynamic and automated deployment of new system instances and resources when needed (scalability)
- The possibility of agile database development, such as the use of different virtual machines with different database systems or versions promotes the development or testing of agile software development within the try-and-error principle. Systems with different degrees of updating can be adjusted, changed or deleted, without risking to compromise “functional” databases.
- Improved availability by separating virtual machines from each other, in case of issues with one VM, the rest of the VMs can continue operating without any sacrifices in performance.
It is no wonder that the virtualisation of databases is increasing. But despite these advantages, it can also lead to problems should their implementation be carried out too fast and without sufficient planning. Because there are several things to consider when implementing them. Problems can occur especially in case of:
- Databases generally require a lot of resources, whether in a real or a virtualised system. Virtualised database systems based on Microsoft SQL Server and similar, need powerful processors, lots of memory and above all great storage capacity, so that any data can be quickly processed by the system, just like real databases. Without sufficient hardware, the database will most likely suffer a significant degradation in performance.
- In some cases, such as old Oracle databases, previous database licences cannot be transferred 1:1 to a virtualised system, as the fees are related to the (potential) performance of the system and not to what is actually used. It is therefore important before starting a transition to consider first how many instances and processors are to be actually used, in order to get a comparison between the cost of a physically existing database server and its virtual counterparts.
- Databases are by nature complex, and virtualisation changes nothing in this, which is why it is critical to have skilled and knowledgeable staff to operate them. And with virtualisation, database administrators (DBAs) have to face a new technology level which further adds to the complexity. Thus, if no distinction is made by the company between IT admins who are responsible for virtualisation, and DBAs, then it falls to one type of employee to learn two complex disciplines.
- Lack of exchanges or cooperation between IT Admins and DBAs often causes problems as many database administrators have no real access to the depths of the virtualisation layer, as this is managed by IT administrators. In case of problems with the database caused by an anomaly in the VM or virtual system, there are often long delays in resolving the issue.
This last point is especially something that can be improved, as we have seen in our data recovery experience. As with normal failures of virtual systems, the reasons for the disappearance of virtualised databases are mainly:
- reformatted VMware Datastore volumes,
- damaged VMFS datastore volumes,
- damaged guest file systems,
- corrupt virtual files (VMDK/VHD) or
- accidentally deleted file systems (VMDK or VHD).
Thus it is not exclusively hardware failures or defects that lead to the failure or disappearance of virtual data or databases, but in many cases this is due to human error. And very often, the responsible DBA appears to be simply overwhelmed when something unexpected happens.
But what should you decide now: virtualise your databases or not? In the second part of this article we provide the answer to this question and also important clues on what to watch out for when considering database virtualisation.
Image credit: Windorias / pixelio.de