Re: Openmosix and LTSP concerns?

Hello,

  I don't know about your oM->LTSP version matching, but if you
want to improve the shutdown cleanup, then you can setup
acpid to monitor the button event for power.  This will give you
a maximum of 8 seconds (if the BIOS is setup right) to tell oM
to send all remote processes home from this node, and to bring
all local processes back home to this node .. before losing 
power.  You will need to tune your shutdown scripts (/etc/init.d/*)
appropriately (don't waste time shutting down X for example).





----- Original Message -----
>From: "Sean Harbour" <[email protected]>
>To: <openmosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>Subject:  [openMosix-general] Openmosix and LTSP concerns?
>Date: Mon, 23 Apr 2007 16:31:26 -0700
>
> Hey guys, this discussion just popped up again on our K12LTSP mailing list. Can anyone 
give us any insight to using Mosix with a modern version of LTSP, or at least tell us who to 
talk to that you might know of that has been working with this lately?
> 
> Sorry if this is a common question, we haven't had much time to investigate this, so I figured 
I'd cut to the chase and ask around before we started re-inventing the wheel.
> 
> When I looked at this a few years ago, the big problem with running Openmosix in an LTSP 
thick client cluster was the high frequency of people randomly powering off their clients. 
Assuming we can't retrain the people, is there a solution that minimizes the impact this would 
cause to the cluster? I'm thinking it would probably be ideal if there was some way to limit 
thread migration so that users would only kill their own threads if they powered off their local 
workstation. I realize this would limit the effectiveness of Openmosix, but even a 20 percent 
increase in the number of supportable clients per LTSP server would make it worth it.
> 
> Thanks,
> 
> Sean Harbour
> Portland, OR
> 
> 
> 
> >James P. Kinney III wrote:
> >> The direction that RedHat/Fedora is gearing up for is "Stateless Linux".
> >> http://fedoraproject.org/wiki/StatelessLinuxHOWTO
> 
> >> I _don't_ see most
> >> schools going "COOL! Now we can roll our own custom environment!"
> >> anytime soon. It's a beast of a process.
> 
> >I've always thought the right way to handle this would be a slight
> >variation of openmosix where you could designate one or more dedicated
> >servers that could run applications for anyone but in addition, your own
> >applications would have the option of running on your local machine
> >(only - not other clients)if it offers a reasonable amount of CPU and
> >RAM capacity.   However I don't know enough about openmosix to know if
> >it actually has any concepts to associate users and their local
> >machines. You probably don't want your jobs running on some other client
> >that might be rebooted or unplugged at any time.  Something like this
> >could automatically balance out the differences between thin and fat
> >clients without much custom tweaking.
> 
> >--
> >   Les Mikesell
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> openMosix-general mailing list
> openMosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/openmosix-general
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/