Re: Stateless install within Xen environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the quick response Jeffrey.

On Tue, 16 Jan 2007 10:35:03 -0700
Jeffrey Law <law@xxxxxxxxxx> wrote:

> On Tue, 2007-01-16 at 10:33 -0500, G Perry wrote:
> > Hello,
> > 
> > I am currently researching Stateless Linux as a mechanism for managing a cluster application, and I have a few questions that hopefully a list member can answer.
> We'll do our best.
> 
> > The current project we are working on is a grid/cluster environment built on top of Amazon EC2, which is a new service offered by Amazon to be used in tandem with their S3 wide area storage network.  We have an application that will eventually be comprised of tens if not hundreds of Xen domU instances, each of which has the exact same architecture as the master domU.  The idea would be to scale and bring up additional EC2 domU instances as load requires, and that's where I am looking at Stateless as a potential mechanism for keeping the operating system synchronized across all of the instances, which would include the various Yum updates and security patches which are issued from the Fedora project on a regular basis.
> That mirrors reasonably closely some of the usage scenarios I've envisioned,
> except for the problem of total non-persistency of the instances.
> 
> > The problem with EC2 is that Xen instances are non-persistent; any shutdown of the instance and the filesystem goes away; that's where S3 comes into play, any information you need to save gets stored on S3.  As a result, there is not really a way to boot a CD or ISO image within EC2, the cached Stateless client must be a fairly complete install image that can talk to the network, get a DHCP lease etc.
> This is going to be a problem -- we're moving away from using raw ext3
> images for stateless.  The fundamental problem with using image is that
> we want stateless to work with other systems management initiatives 
> which are based more on instantiating and updating systems based on
> metadata.
> 
> The non-persistence of instances also means that you can't just use
> the metadata and reinstantiate the client anytime it boots -- 
> instantiation of the client fires off anaconda and anaconda reboots
> the client when its done, which would throw away all the work done
> by anaconda.
> 
> Given the constraints of your system, I don't see a good way to make it
> work with the new direction stateless has taken.  You might be able to
> make the old stateless model work, but you'd be very much on your own
> as far as tools to manage the stateless systems.
> 
> 
> 
>  
> > Whenever Stateless updates a binary that is in use, say for example Apache httpd, how does Stateless restart that binary and deal with any configuration changes?  Or is that outside of the scope of what Stateless manages?
> Our stateless models have always had deferred updates for binaries, more
> specifically updates aren't exposed until a system reboot.  We're
> pushing that model for configuration updates as well, though our 
> system for doing configuration updates (puppet) _may_ be able to handle
> on-the-fly updates depending on the exact circumstances.
> 
> To handle an on-the-fly configuration update you have to stop the 
> affected service, unmount any bind mounts for the configuration
> files, update the configuration files and finally restart the service.
> 
> There's no guarantee that you'll be able to unmount the bind mounts
> (the files might be open by some other process).  Worse yet, if you
> have multiple configuration files for the service, then you may be
> able to unmount some, but not others.  Hence we're really not
> recommending on-the-fly configuration updates.
> 
> Jeff
> 


[Index of Archives]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux