Hi Taco,
> What virtualization technology are you using ? OpenVZ ? Xen ? Something
> else.
We looked at a couple of them. Brian has extensive experience with VMware, I
used to use Xen for a bit and also briefly experimented with Linux-VServer.
To us OpenVZ offered a couple of advantages outright for the intended purpose
(i.e.: hosting). OpenVZ's stability, its mature code and the license terms
made it an easy choice.
So we use OpenVZ for the virtualization and DRBD and Heartbeat for the
clustering. The "master node" uses CentOS as base OS.
> > It'll be a commercial product, available from NuOnce Networks and
> > Solarspeed.net directly, or from various selected vendors. Sorry, guys,
> > but after countless weeks of development we can't release this for free.
>
> I can imagine, although a 'fork' from BlueQuartz is certainly not something
> I like.
Yeah, I can understand that, Taco. But we sort of had to fork it. After all,
the OS of the master node is entirely separate from the "virtualized" CentOS
+ BlueQuartz instances that you might want to install as VPS's. Even that is
optional as you could instead just entirely populate the server with VPS's
that run Fedora Core and Plesk. Keeping the codebase "mergeable" therefore
wouldn't have offered much of a benefit. Also, it's desirable to run as few
services and tasks on the master node as possible. We wanted it "lean and
mean" and trimmed a lot of "fat".
So we forked the Sausalito code tree, removed all bits and pieces that we
didn't need and renamed the packages from "base-*" to "vz-* to avoid
confusion.
There are even changes to the codebase of Sausalito which runs in the VPS's.
Like base-wizard, base-network, base-time, base-vsite and a few more. That is
mostly minor stuff like changing handlers or php pages dealing with the
network interfaces to match the virtualized environment (i.e.: "venet0"
instead of "eth0"), or removing no longer needed configuration options. For
instance the network settings of the "virtualized" BlueQuartz are configured
in the GUI of the master node, so there is no need to allow the end user to
change them inside the VPS as that won't have any effect anyways. Those
changes can of course be merged back into the original BlueQuartz codebase at
one time or another.
To cover the odds and ends of these changes we increased the version number of
the modified original Sausalito RPMs by a few notches and provide them from
an extra repository. Right now this of course requires some extra work on our
end, because we have to port updates and code changes between the official
BlueQuartz code tree and the virtualized one.
> Any idea on the pricepoint ? I am just starting integration of BQ with
> OpenVZ and if your product is not too pricy I want to wait for this.
Yeah, we have some rough ideas and are going to release around six differently
priced variants. Price will depend on if you need clustering or not and how
many VPS's you want to support. There should be something suiteable for every
budget.
The virtualization itself opens a couple of new interesting possibilities. In
the past people tended to cram as many sites and users onto the same
"physical" server. But now - as you could simply create a VPS for each
customer - adding stuff like a reseller interface would no longer be such a
pressing need for the BlueQuartz project itself.
Or look at the whole deal with adding "third party software" to an
"appliance". Sure, people will still need web based email, maybe an updated
PHP and/or MySQL and similar bits and pieces. But the more sophisticated
stuff that is really difficult to integrate without breaking things on CentOS
+ BlueQuartz can be installed into separate VPS's or even onto a different
brand of Linux - one that doesn't have to run BlueQuartz. In the past one
often had the evil choice of installing something inferior - but which worked
without breaking things on Cobalt or BlueQuartz - or installing something
more sophisticated which bent the Cobalt or BlueQuartz so far out of specs
that future updates could be problematic. That can now be avoided.
Even the simple things gets easier: Some clients need PHP4, others insist on
PHP5? No problem. One VPS uses the latest PHP4 and those customers that need
PHP5 get moved to a VPS with PHP5 instead. Or all the "bad apples" that
require "safe_mode = Off" and "register_globals = On" get moved to their own
VPS, which you can even name hackerbait.company.com if you like. If that VPS
gets hacked as expected, the other VPS's are still safe.
OpenVZ uses "canned" operating systems. They're like a large tarball that
contains a ready to use OS, which is then used as template for the operating
system when you create a new VPS. So far templates are available for CentOS,
Debian, Fedora Core, OpenSuSE, Gentoo and Ubuntu. Add the "CentOS +
BlueQuartz" OS template to the list that Brian and I rolled up based on the
latest codebase. In a year from now there will be a lot more specialized OS
templates available to cater every need. Sort of like what rPath offers
through rBuilder. Which will also somewhat change the delivery method of
third party software. If it's small and unproblematic to install and to
remove, then provide it as PKG. If it's more complex, ship an OS template
where the extra software is already pre-installed and ready to run.
> > Release date ... well, let's just say: "Soon!". Probably a few more
> > weeks.
>
> A few more weeks ... let say April 1st ?
Hahaha ... I think that's one of the few dates that we'd want to avoid. The
last somewhat official release date for the non clustering version was mid
December, so I'd rather not make any promises in that regards. :o)
--
With best regards,
Michael Stauber