VDI 3 is out for quite a few days meanwhile and the feedback we've got so far reaches from positive to total excitement. That's a nice and really satisfying fee for all the hard work necessary to get this product done in the given time frame. Several things have been written already about VDI 3 and How it all came together so I don't want to repeat such general information here. I'd like to rather concentrate on a specific aspect of VDI 3 namely the MySQL database integration. Why I want to do that?
- I'm the responsible engineer for the MySQL database integration (you now have somebody to directly blame for any shortcomings in this particular area ;))
- Feedback we've got so far on various tech and feedback aliases suggests there are a few questions open around this area and a few misunderstandings exist as well (apparently the VDI 3 documentation has still some gaps to be filled in this regard).
VDI 3 has a far more sophisticated data model than his predecessor VDI 2. This data model almost naturally fits into a relational data model hence we changed the path from using the Sun Ray or Sun SGD data store (both LDAP databases) and decided to use a relational database instead. Around the time of this decision Sun announced to acquire MySQL. Given this turn of events and the reputation of MySQL it was not exactly difficult to choose a specific relational database for VDI 3. Besides that what other requirements influenced the VDI 3 database design?
- No single point of failure (SPOF). As VDI 3 is a system destined to serve hundreds of users 24x7 hours the system shouldn't have a SPOF.
- No MySQL knowledge required to get started with VDI 3. People should be enabled to get started with VDI 3 in production without the requirement to learn about relational databases in general and MySQL in particular and yet be able to quickly setup a high available (HA) system.
- Flexibility. VDI 3 is supposed to serve small to large deployments. What will be optimal for smaller deployments will most likely not be optimal for larger deployments too. So VDI 3 should offer the flexibility to satisfy a broad range of deployment scenarios.
All three are important requirements but as so often in life you cannot treat everything as equally important but have to prioritize. For us 1. was the most important requirement leading our initial choice of a particular MySQL version to use for VDI 3. To make a long story short we've chosen MySQL Cluster which is a "...high-availability, high-redundancy version of MySQL adapted for the distributed computing environment...". While this choice perfectly satisfies requirement 1 it doesn't help (rather contradicts) a solution for requirement 2 because setting up MySQL Cluster, though the MySQL folks tried hard to make it as easy as possible, requires quite some knowledge and experience. To compensate this disadvantage we have invested a lot of energy and effort into the VDI 3 installation process. The result is that now with VDI 3 if you choose to use the embedded database a complete, high available MySQL Cluster will be automatically configured for you. You don't need to know anything about the details and theory behind it. There is one noticeable implication of using MySQL Cluster: You need a minimum of three physical hosts to configure a HA MySQL Cluster. This is the recommended deployment option for the embedded VDI database scenario. Why it is necessary to have three physical hosts will be answered here.
Feedback we've got from the field so far reveals that this is a particularly painful implication. A lot of customers want to start small and cheap. Requiring a minimum of three physical VDI hosts if you only want to run a handful of virtual desktops can be hard to explain to somebody. How to escape this dilemma? I will show some possibilities below.
But first let me say something about the third requirement "Flexibility". The embedded VDI database is fine for a lot of smaller to medium deployments but it might not be the perfect match for each and every situation or customer. So we've added the possibility to make use of an existing MySQL database known as the remote database option in the VDI 3 configuration. This hopefully satisfies requirement 3. Here are two of the most likely reasons making the remote database option the better choice:
- People have a MySQL database running already and want VDI to integrate into that database.
- People need more freedom in setting up the MySQL database for a variety of reasons e.g. performance, security etc.
So now on to the deployment options and what you can do about the requirement of three physical VDI hosts. I will enumerate a couple of supported scenarios. First of all you can choose the remote database option. This allows you to either use MySQL Server >= version 5.0 with InnoDB or MySQL Cluster version >= 6.2.15 in whatever way is supported by MySQL. One minimal setup enabled by this option is the following one:
- All in one host scenario [*]. In this scenario you will run everything on one physical host. Everything means Sun VDI 3, VirtualBox and the storage. Please note that the requirement for this deployment options is to run Solaris 10 >= update 7 on this host. Concerning the database you would have a locally installed MySQL Server and connect to it selecting the remote database option during VDI 3 configuration. It should be pretty clear however that this kind of deployment offers zero redundancy meaning it is one big SPOF (the cheapest one though :)). Furthermore you would have to buy a separate MySQL support contract if you need this part of the solution to be supported formally.
[*] Requires VDI 3 patch 1, soon to be released!
- Shared VirtualBox, VDI Primary host. In this scenario the Sun VDI 3 Primary and one of your VirtualBox hosts share one physical machine. Make sure the shared host has enough capacity to deal with these two roles at the same time.
- Running the VDI 3 Primary in a virtual machine. This option is useful when you are using VMware as virtualization platform. Running MySQL Cluster completely in a virtualized environment is not supported see MySQL FAQs. Given the fact that the MySQL Cluster management node requires only little resources the MySQL folks have agreed that it is an acceptable and supported scenario to run it in a virtual machine. The two VDI 3 secondary hosts running the MySQL Cluster data nodes nevertheless need to run on bare metal.
