Hello,Just throwing in my 2 cents. I have been running my gmetad head node and web front separate for the life of our use.
We may be special since we have nfs disks available to our servers, but I simply write to the shared nfs disk from the head node, and read it from the web server that is running the web-front of ganglia.
I think I ran into an issue and found I needed the same version of rrdtool and the exact same date/time across both servers.
What are the advantages of running the system as described below? Would there be better performance (time to load graphs on webpage?)? More/less load?
Thanks, Cassandra Bernard Li wrote:
Dear all: Just to let you know, I've come up with a patch to de-couple the web-frontend from the gmetad server, the patch is available here: http://therealms.org/oss/ganglia/ganglia-web-decouple.patch Patch was done against 3.1.7. Here's how to setup RRD Server and apply the patch: 1) Make sure your version of RRDTool supports running as a server, man rrdtool and look for "RRD Server" 2) Add the rrdsrv entry to /etc/services as indicated in the manpage 3) Create an entry for rrdsrv for inetd, the following can be placed in /etc/inetd.d (or wherever your inetd configuration files are located): service rrdsrv { disable = no socket_type = stream wait = no user = root server = /usr/bin/rrdtool server_args = - /var/lib/ganglia/rrds cps = 100 30 only_from = <ip of your web frontend> } * Put the ip address of your web frontend in "only_from" * Adjust "cps" as necessary 4) Test by telneting to RRD Server at port 13900 Now that the RRD Server is setup, it's time to patch the frontend code: 1) Make a copy of your frontend code, eg. cp /var/www/html/ganglia /var/www/html/ganglia.decouple 2) Download the patch to /var/www/html/ganglia.decouple 3) cd into the directory and run `patch -p0 < ganglia-web-decouple.patch` 4) Edit conf.php and change $ganglia_ip and $rrdserv_port to the IP of your gmetad server and the RRD Server port (13900) respectively 5) Edit gmetad.conf and make sure that the webserver is in "trusted_host" directive 6) Re-load gmetad That should be it! Check your httpd error logs if things don't work properly. For those interested in the technical details, I have created 2 new functions to abstract calls relating to RRDTool: 1) rrdtool_exec() 2) rrd_exists() Please refer to the comments for more information regarding what they do specifically. Again, I must stress that there is NO authentication between the frontend code and the RRD Server, other than the directive only_from which restricts only the frontend IP can communicate with the RRD Server at the specified port, so please only use in a "safe" environment. Comments welcome, even just to say you've tried it and it works. Thanks, Bernard On Wed, Mar 10, 2010 at 11:59 AM, Bernard Li <[email protected]> wrote:Hi Eric: On Wed, Mar 10, 2010 at 7:37 AM, Eric Shubert <[email protected]> wrote:That's great news to me. This was one of the questions I had when I first learned about ganglia. I've recently begun using ganglia to monitor several vmware hosts and guests, and am very much interested in this type of configuration. I would like to keep the data collection on the vmware hosts/guests, but run the frontend on a separate (remote) host. What are the security implications?From the man page of rrdtool for "RRD Server": "NOTE: that there is no authentication with this feature! Do not setup such a port unless you are sure what you are doing." It does run rrdtool in a chroot (usually the root directory where your rrd files are located, i.e. /var/lib/ganglia/rrds), however, since there is no authentication, the port is basically wide open meaning out of the box folks on the network could do things like "ls" and "mkdir" in the root directory. It would be nice if we could add the functionality of restricting certain commands from being executed remotely, much like the -P feature of rrdcached. Cheers, Bernard------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
