originally blogged by Tino Rachui
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
- 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)
- 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
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
- 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
- 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
[\*] 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.
That's it for now, a lot of stuff. I hope a could clarify a few things concerning the VDI 3 database integration.
I appreciate the fact that the relevant knowledge was targeted to my limited knowledge. Thank you for the time spent.
I'm currently assembling a large server farm to perform a large scale
demonstration of the VDI technology as my Graduate project at the
University. I'm having some difficulty in the setup, but nothing I can
not figure out.
I'm wondering if in a remote database setup, is it possible to run
with just 1 primary and 1 secondary instead of the 2 secondary servers
am Januar 21, 2010 at 03:27 AM MEZ