Fwd: [Beowulf] Configuration change monitoring

[Gerry Creager]

Walid wrote:
> ---------- Forwarded message ----------
> From: *Walid* <walid.shaari at gmail.com <mailto:walid.shaari at gmail.com>>
> Date: Aug 30, 2007 9:22 PM
> Subject: Re: [Beowulf] Configuration change monitoring
> To: "Robert G. Brown" <rgb at phy.duke.edu <mailto:rgb at phy.duke.edu>>
> 
> Hi Robert
> 
> On 8/30/07, *Robert G. Brown * <rgb at phy.duke.edu 
> <mailto:rgb at phy.duke.edu>> wrote:
> 
>     To amplify Mark's remark a bit -- linux in general already has many
>     fairly powerful tools for DOING monitoring, updates, and so on.  For
>     example, one can use e.g. yum, kickstart, apt, and more to install a
>     "canned" node configuration and keep it up to date.  It is so totally
>     automatic that there is basically no need to "check for inconsistencies"
>     on a node. Warewulf and several other tools also permit one to have
>     rigorous control over node configuration.
> 
> 
> Some of the inconsistencies we see is usually when one of the admin 
> choses the easy routes, and does changes manually to a set of nodes, and 
> does not update the installation files (our installations are rpm 
> kickstart based), others are becuase we manage quite a large variants 
> and by mistake or intention configurations files that are not supposed 
> to be on cluster A appears on Cluster B.
> 
>     Monitoring tools abound, of course, ranging from things like syslog-ng
>     for centralized monitoring/logging of LAN systems activity to nightly
>     ... ...
>     Is there something else one needs to do?  Well, most cluster admins tend
>     to be fairly skilled linux administrators and good at shell script magic
>     or even real programming.  So if one has an edge-case need that isn't
>     directly met by one of the available tools, it is usually a fairly
>     simple matter to hack out a script to accomplish it. 
> 
> 
> That is one reason why they want  to push some commercial tools, They 
> want to minimize the amount of customizations that are done locally by 
> the team, as some writes in bash, another writes in Perl, and the other 
> prefers Python, in the long run there is an issue of maintaining the 
> scripts, and knowing which set of scripts belongs to which cluster, and 
> what kind of modifications are needed for new clusters,.etc all of which 
> is documented, but that is another story

More than likely you'll end up with commercial "solutions" that preclude 
a rapid response to a problem and take your system down.  A good admin 
team communicates and you don't see confusion at the level you are 
describing.

gerry
-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.862.3982 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843