meetraz has asked for the wisdom of the Perl Monks concerning the following question:

I've been asked to create a system which will gather information and perform tasks on approximately 5000 Win32 servers. The idea is this: a central console can connect to each server, and submit a request. When each server has completed that request, it will report the results back to the central server. The request can be to gather data (How much free space does each of your drives have?) or to perform a task (create a new fileshare with these permissions). The amount of tasks each system will be asked to perform will probably be numerous, so performance will be a concern.

My idea so far is to create an application which runs as a service, on the 5000 remote servers, and on the central reporting server. These services would listen via an open TCP port, and communicate through that.

Would a system like this work reliably? There are those people here who suggest using DCOM, shared pipes, or mailslots instead of a TCP port. My experience with doing client/server systems through TCP on Win32 hasn't been that great, and neither has forking-model servers. And of course, security is a top concern. What would you suggest?

Replies are listed 'Best First'.
Re: Distributed query system
by strider corinth (Friar) on Nov 06, 2002 at 17:35 UTC
    The main concern I see is that you'll have 5,000 connections open from your central server at a time. My suggestion would be a combination between your idea and the concept behind mailslots:

    - Open a connection from the console to each of the hosts, one at a time.
    - Tell them each what to do, get a confirmation that they received the request, and close the connection.
    - Wait for them to open a connection back to the console to report.

    That way, you don't have 5,000 connections open for a long time. If your hosts need to do something before they do their work and report back, that's no problem. If one of them takes too long, the console can check back to see what's up. And the actual reporting will probably not take too long, so the load on your server will be minimized.

    If you wanted to, you could even have the hosts report back by inserting the report data directly into a SQL database, making the data searchable. With a timestamp and a unique id for each mass request the console sends out, your reporting system could become very versatile.

    One final thing I need to mention is security. If these slave systems will be doing things like creating fileshares, the connection required to do that ought to always be encrypted, and need some sort of password authentication. Confirming the host that the request is coming from wouldn't hurt either. You don't want anybody to be able to do the kind of things you're thinking of automating.
    --
    Love justice; desire mercy.
[reply]
Re: Distributed query system
by dash2 (Hermit) on Nov 06, 2002 at 17:38 UTC
    I know nothing about shared pipes, mailslots or DCOM, but you could consider using Frontier or SOAP::Lite as a quick way to do rpc over http. Frontier::Client and Frontier::Daemon use XMLRPC and are very simple. SOAP::Lite uses SOAP, which is a bit more industry standard, but is also fairly simple.

    dave hj~

[reply]
Re: Distributed query system
by fglock (Vicar) on Nov 06, 2002 at 17:08 UTC

    I would use an Apache server on each system. It might be overkill, but it has very good performance, is very reliable and you can make it very secure.

[reply]
Re: Distributed query system
by ehdonhon (Curate) on Nov 06, 2002 at 17:40 UTC

    As much as I like to advocate building open-source solutions to problems, it really sounds to me like you are re-inventing a wheel that has already been around for a long time. Maybe you should consider looking at The MS Systems Management Server package? I believe it will easily handle the types of applications you are describing.

[reply]
      I've been an NT administrator for awhile now, and used SMS through several versions with other companies. We actually do use it in a very limited fashion here as well. But, anybody who has worked with SMS views it as a disaster waiting to happen. It's not really designed to do this type of thing, and even the things it was designed to do, it does very poorly. I could write a book on all the problems with SMS.
[reply]

Back to Seekers of Perl Wisdom