Sunday, September 2, 2007
More Progress...
The following modules for the management are pretty well done: open-iscsi, OCFS2, rAA interface, and Shell Access (via SSHTerm). I'm working on the VMware module, and I'm trying a new approach - a class-based approach. It's proving to be a bit more difficult and require more thought than the open-iscsi module - for a few reasons. First, there are multiple commands that need to be run to manage VMware effectively, and that doesn't even cover all the basis (networking configuration is still lacking), and second the VM management is a lot more complicated than the open-iscsi management - there are host-level settings, VMware Server-level settings, and VM-level settings. Hopefully I'll be able to work some on it tomorrow - maybe get the basic class interface hacked out.
Wednesday, August 29, 2007
Status Update - August 2007
Well, it's been a while since I've had a chance to work on this much, but I finally got back to some development work last night. I started to hack away at some more of the web-based management interface. I've got most of the open-iSCSI management done in PHP - it was really easy because most everything is done in a fairly simple fashion through the iscsiadm command, so interfacing that with PHP was pretty easy. I doubt everything else will be quite so easy, especially when it comes to things like parsing config files and stuff like that.
I'm also trying to develop the sudoers file as a go - the web server is going to need sudo access to quite a few commands, but I certainly don't want to give the user full sudo access, so I have to keep track of what commands will need sudo access.
I released version 1.0.2 yesterday, which doesn't really have a lot of changes - I just re-cooked the groups, created new builds, and another release. This should ensure that it has the latest sets of packages from rPath Linux.
Oh, and I seem to actually be getting some downloads of the tool off rpath.org! Not sure who's downloading it, but I hope you're finding it useful!
I'm also trying to develop the sudoers file as a go - the web server is going to need sudo access to quite a few commands, but I certainly don't want to give the user full sudo access, so I have to keep track of what commands will need sudo access.
I released version 1.0.2 yesterday, which doesn't really have a lot of changes - I just re-cooked the groups, created new builds, and another release. This should ensure that it has the latest sets of packages from rPath Linux.
Oh, and I seem to actually be getting some downloads of the tool off rpath.org! Not sure who's downloading it, but I hope you're finding it useful!
Monday, July 2, 2007
Status - 2007/07/02
Here's a quick rundown of the current status of this project...
I've created the base platform with the minimal services necessary for the things that will be running on the host. This includes xinetd (for VMware Server), httpd (for management), rPath Appliance Agent (for updates and basic server management), open-iscsi for shared block device connectivity, and the rest of the basic services (udev, hal, ssh, etc.).
I've started work on the heartbeat portion of the configuration, as well. I'm trying to decide whether to use heartbeat 1.x configuration style, which actually seems easier to me, or heartbeat 2.x configuration style, which would require parsing XML files. I'm actually leaning to 2.x, just because there are some nice things that 2.x configuration brings with it, but if it proves to be too difficult I won't spend too much time on it.
Other than that, I have a lot of work to do. Once I get some basic configurations nailed down on my test systems here I'll starting working on the web interface for easy management - not a task I'm looking forward to doing. I'll need to start by creating a basic user interface template - something to define how the page will be laid out, what fonts will be used, etc. - then I'll need to create a class for management functions. After that it will be a matter of implementing each component of the interface - parsing configuration files, creating new files, etc. I might use sudo to accomplish the tasks that need to be run as root (much the way Openfiler works), but I also might look at the suexec module for Apache and try to run things as the user who actually logs in to the interface. We'll see...
Anyway, that's today's status - I'm going to try to work on some of this today, but tomorrow's status may be the same...
I've created the base platform with the minimal services necessary for the things that will be running on the host. This includes xinetd (for VMware Server), httpd (for management), rPath Appliance Agent (for updates and basic server management), open-iscsi for shared block device connectivity, and the rest of the basic services (udev, hal, ssh, etc.).
I've started work on the heartbeat portion of the configuration, as well. I'm trying to decide whether to use heartbeat 1.x configuration style, which actually seems easier to me, or heartbeat 2.x configuration style, which would require parsing XML files. I'm actually leaning to 2.x, just because there are some nice things that 2.x configuration brings with it, but if it proves to be too difficult I won't spend too much time on it.
Other than that, I have a lot of work to do. Once I get some basic configurations nailed down on my test systems here I'll starting working on the web interface for easy management - not a task I'm looking forward to doing. I'll need to start by creating a basic user interface template - something to define how the page will be laid out, what fonts will be used, etc. - then I'll need to create a class for management functions. After that it will be a matter of implementing each component of the interface - parsing configuration files, creating new files, etc. I might use sudo to accomplish the tasks that need to be run as root (much the way Openfiler works), but I also might look at the suexec module for Apache and try to run things as the user who actually logs in to the interface. We'll see...
Anyway, that's today's status - I'm going to try to work on some of this today, but tomorrow's status may be the same...
Saturday, June 30, 2007
The vmHA Project
Welcome to my blog for the vmHA project. The purpose of this project is to create a Linux-based platform for hosting virtual machines that provides high availability services for those VMs. Right now I'm basing the project on VMware's Server product (formerly GSX Server). I'm most familiar with the VMware Server VM format and the tools used for it, so I'm going to start with that and then hopefully expand out to Xen and some of the other virtualization products. I'm attempting to build this as an alternative to expensive enterprise products, like VMware's ESX Server. Don't get me wrong - I'm a HUGE ESX fan, but not everyone can afford ESX and I'd like to be able to create some sort of alternative for those people that is still very easy to manage and still provides high availability for virtual machines.
Among the things I'll be attempting to implement are a shared/cluster filesystem for storing the VMs, a heartbeat/LinuxHA setup for virtual machines so that VMs running on a server will be automatically restarted on another server in the cluster if one of the servers fails, an easy-to-use web-based management interface, and quick moving of a VM from one server to another via suspend/resume of the VM.
For the base platform I've chosen rPath linux, mainly due to the ease and speed of updates, rollback capabilities, ease of package management and building new packets, and the rPath appliance agent for managing the server. I've already built quite a few packages for this distribution that are missing from the main repositories.
I've decided on OCFS2 as the cluster filesystem that I'll support in this project, at least initially. OCFS2 was one of two choices - GFS2 being the other choice. I initially chose these two filesystems due to their ease of configuration. There are other cluster filesystems out there, but many of them are very conviluted in their configuration, which is especially inappropriate when ease-of-configuration is one of my goals. I eventually chose OCFS2 because GFS2 is currently unstable in the current Linux 2.6 kernels, at least the kernel versions that are considered stable, anyway, and the ones supported by VMware Server. This is unfortunate because I like the fact that GFS2 supports ACLs and extended attributes, but for now OCFS2 is going to have to work.
The heartbeat setup will allow the operator to choose the method(s) of hearbeat communications - serial port, dedicated ethernet port, or unicast over an existing ethernet port. Obviously the operator must provide the right type of cable. When users create VMs via the web interface they will be given the option of making the VM an "HA" VM, in which case a heartbeat configuration will be created for that VM. The heartbeat configuration will allow heartbeat to monitor the status of the VM and the VM host machine periodically and start the VM on a different machine if something should happen to it.
Well, that's about all I can think of for the initial post. I'm sure I'll think of other things, later, and I'll make some additional posts. If you'd like to see what I've done so far on the project, visit the rBuilder project page at http://www.rpath.org/rbuilder/project/vmware-ha/.
Among the things I'll be attempting to implement are a shared/cluster filesystem for storing the VMs, a heartbeat/LinuxHA setup for virtual machines so that VMs running on a server will be automatically restarted on another server in the cluster if one of the servers fails, an easy-to-use web-based management interface, and quick moving of a VM from one server to another via suspend/resume of the VM.
For the base platform I've chosen rPath linux, mainly due to the ease and speed of updates, rollback capabilities, ease of package management and building new packets, and the rPath appliance agent for managing the server. I've already built quite a few packages for this distribution that are missing from the main repositories.
I've decided on OCFS2 as the cluster filesystem that I'll support in this project, at least initially. OCFS2 was one of two choices - GFS2 being the other choice. I initially chose these two filesystems due to their ease of configuration. There are other cluster filesystems out there, but many of them are very conviluted in their configuration, which is especially inappropriate when ease-of-configuration is one of my goals. I eventually chose OCFS2 because GFS2 is currently unstable in the current Linux 2.6 kernels, at least the kernel versions that are considered stable, anyway, and the ones supported by VMware Server. This is unfortunate because I like the fact that GFS2 supports ACLs and extended attributes, but for now OCFS2 is going to have to work.
The heartbeat setup will allow the operator to choose the method(s) of hearbeat communications - serial port, dedicated ethernet port, or unicast over an existing ethernet port. Obviously the operator must provide the right type of cable. When users create VMs via the web interface they will be given the option of making the VM an "HA" VM, in which case a heartbeat configuration will be created for that VM. The heartbeat configuration will allow heartbeat to monitor the status of the VM and the VM host machine periodically and start the VM on a different machine if something should happen to it.
Well, that's about all I can think of for the initial post. I'm sure I'll think of other things, later, and I'll make some additional posts. If you'd like to see what I've done so far on the project, visit the rBuilder project page at http://www.rpath.org/rbuilder/project/vmware-ha/.
Subscribe to:
Posts (Atom)