Why put a database server on a virtual machine?

Question

Database

A database course began at the university, at the first pair they were faced with the fact that MS SQL Server would be on a virtual machine, without really explaining the reasons - it was just necessary. I also read articles on Habré, where people also deal with virtual machines, especially on the web. But after all, in real projects, it is unlikely that database servers are installed on virtual machines, but I want to start understanding all this right away, as it should be in reality.
Please explain why this is needed, what is good or bad about this method, why not just put the server on a computer? thank.

Answer 1

If we are talking about the fact that the DBMS will run on university PCs, then there can be only one goal - not to clog the main OS. Imagine you sat down, installed a DBMS on the host OS, created some kind of database, filled a couple of tables with information, etc.
The first reason is the DBMS installation time. I do not know how for MS SQL, but, for example, Oracle 10g takes about 50 minutes, which is half a pair. And the installation process is not particularly remarkable, you just sit and stick a bar on the screen into the process ...
The second reason.
OK, you installed the DBMS, you start configuring it. Everything rests on the root password, without which, for example, Oracle cannot be demolished at all (although I could be wrong). Of course, it is possible to agree that there is only one pass, but one of the painfully "smart" students will set their password and then the audience operator with a tambourine will have to dance over this PC with a tambourine for a couple of hours or look for who put that ill-fated pass ... And this is all the time , for which the learning machine drops out of the learning process.
The third reason
Someone killed the DBMS with clumsy settings. How much will it take to dance with a tambourine to cut out the killed DBMS from the host OS? It depends on how they were killed, but it is clear that at this time the university machine again falls out of the educational process.
And now estimate that the DBMS is under the virtual machine and there is somewhere an image with a default configuration. Deploying a virtual machine based on a ready-made image is a matter of 5-10 minutes. To demolish a virtual machine or replace it - again, it will not cause big problems.
At the same time, as noted above, in the settings of your application, the difference will be only in 1 line - the server address. For local localhost, for any other - ip address

Answer 2

Perhaps for migrating a virtual machine between failover cluster nodes, for a full backup with all settings and deployment on another hardware in case of failure.

Answer 3

No need to be nervous :), people completely transfer their working environment inside a virtual machine, for example:
habrahabr.ru/post/178797
And all the difference from the fact that the Base will be on a virtual machine or not, this is in 1 place during the connection setup. And so - even on the moon, all the same, tasks for performance at a university are unlikely to be taught.

Answer 4

Now everything is put on virtual machines, as they solve the problem of migration to other hardware and can provide high availability

Answer 5

Virtualka is easier to restore, clone.
And there is almost no difference.

Answer 6

1. The database has been virtualized for a long time. Virtualize even telecom billing. Read guides and best practices of vendors (vmware, Microsoft, oracle).
2. In the classroom, you can take snapshots, you can take and copy vm and finish at home what you didn’t have time at the institute. For educational purposes, virtualization, that's it.

Answer 7

The educational application of virtualization is one thing. Yes, it's very convenient - put the VM file in, run it - you're done! Each student works with his own virtual machine, no one will interfere with anyone, it will not affect the work of another. The lab ran out, the file slammed and that's it. Quite another - production. Not everything is convenient to virtualize. Partly due to virtualization "overhead" losses, partly due to additional licenses for virtual servers.
I installed virtual servers under Debian on libvirt. Conducted tests, losses on io of a hard drive virtualized in a file are approximately 5-10% of a similar real one. The performance loss of a virtualized processor is similar. Here are the conclusions I came to:
Cons of virtualization on libvirt:
- decrease in io performance
- decrease in processor performance
- virtual server "eats" up to 100MB of RAM
- need for lvm for snapshots (never configured, I hate lvm)
- processor cores with HyperTrading support are visible as "real" processors
- some "heavy" operations inside the VM cause severe braking of the entire virtual server
- you should not use disk arrays other than raid1 for storing VMs
- additional "sorcerers" are required for the virtual server to correctly shut down VMs with Windows server platforms, similar to turning off the power of Windows Server using the power button
Advantages of virtualization to libvirt:
- easy change "iron" when the server fails
- easy administration from any platform via rdp, if you install xrdp and virt-manager
- easy use of hardware or software raids for storing VMs
- the ability to use local files|disks, remote nfs resources, etc. as VM disks.
Subtleties of virtualization on libvirt:
Set up a virtual server. The size of the server itself is less than 10GB. There are two screws, on both a swap of a couple of GB. Raid soft, on it the system, the rest of the space on the screws - soft raid1. How to use it - two options. You can create a file system and mount it to the standard libvirt pool: /var/lib/libvirt (or elsewhere) and place the required disk and VM images there. You can place disk images in /var/lib/libvirt in the root partition of the system, and leave the soft raid without a file system and connect it completely as a VM "disk", specifying its name, for example, /dev/md1.
The advantage of soft raid1 under Linux is that you can connect at least 10 disks, unlike hardware raid controllers or soft ones under Windows.
In general, the use of a soft raid gives a significant increase in data reading, for example, a soft raid1 of 6 disks has a read speed comparable to a 6-disk raid0.
If the database server is virtual, and works more on fetching than on updating | adding, this advantage can simply be incredibly beneficial to you :)