MySQLvmware-esxi
What do you think about having MySQLd in vmware VM ? The problem is, we are having MySQL cluster on 2 nodes and it keeps on making the problems (auto-restarting ndbd, ndb_mgmt must be available etc). The performance is not that critical, as it is used mainly by VoIP PBX system.
Could you please give me some pros/cons about having it in the virtual machine that has HA enabled ?
you have a fundamental problem in your cluster design. Mysql clustering needs 3 servers. Suppose the wire connecting the 2 servers is cut but both machines are still running. If they both continue running they will be getting different data and be out of sync.
So with 2 machines they both must shutdown to prevent a split brain scenario where each node in the cluster has different data.
You can add a third machine that runs only the management node (which takes limited resources) that works with the data nodes to decide how to handle a failure. If the management node goes away but both data nodes are still running they will continue to run.
Here are instructions for a 2 data node + 1 management node configuration: http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html
Seriously, most VMware administrators aren't good at this: Poor understanding of resource management, often no Linux knowledge (it helps) and lack of time bandwidth. I find most in-house admins have a difficult time maintaining deep virtualization knowledge.
Luckily, there's a book you can read!
Most VMware environments aren't great: Poor cluster design, bad resource planning, substandard storage (i.e. Synology NAS), misconfigured HA, no monitoring or patching.
VMware as an organization fails us: They are particularly bad at disseminating up-to-date information and promoting best practices. Basic searches for common questions generate results from 2009 and older revisions of VMware, despite the fact that processes and designs have changed over time.
All of these things will work against you.
You should determine the real requirements of your solution. Being able to accurately state that your appliance requires: 2 vCPU, 8GB RAM and 500 IOPs storage performance would go a long way to someone like me.
The other approach is to observe a healthy or ideal environment and extrapolate the metrics from there.
You've described problems with certain deployments. What were the issues and bottlenecks?
An example of a right-sized VM:
An Exchange server for a 300-user organization.
Examples of VM resource monitoring.
Good-ish: - VM is right-sized. - CPU is overcommitted across the cluster, but we're not running into contention.
Bad-ish:
Best Answer
Ok, well you've got a couple of things going on here.
MySQL running in a VM will of course run a little slower than on bare-metal, especially if there's a lot of IO going on - there's no way around that, it's the cost of virtualisation. That said it may not be too bad, maybe only a ~3-5% CPU speed loss, ~3-7% memory speed loss and anywhere between 5% and 25% of IO performance drop based on the load, concurrency with other VMs and disk subsystem setup.
HA makes no difference to this at all, literally none - all HA does is say that if a host goes off line your VMs will restart on another host. But nothing changes until one of your hosts falls over, nothing at all. Now if a host does fall over HA will restart the VMs on the other hosts, not this could mean that the working hosts would then have more load per host and thus the performance could drop overall but only for the time it takes for the failed host to recover and for you to manually or automatically (with DRS) reallocate your VMs across your hosts.
Hope this helps. By the way are you planning on working in your role on an ongoing basis?