Slashdot Mirror
Goodbye SNMP? Hello, WS-Management
Laoping writes "News.com has a story about a new Web services management specification designed to simplify network administration across a wide range of devices. A bunch of a big tech companies developed it together (Microsoft, Intel, AMD, Dell and Sun). Microsoft will build support for WS-Management into an update to Windows Server, which is due late next year, and in the version of its Microsoft Operations Manager management software due in 2006. The .PDF release, that makes it clear that it is meant to be a Simple Network Management Protocol killer. Now I am all for a replacement for SNMP, but is this the way go?"
me... i will concider it when there is an OS version available.
It's interesting to see such diverse companies developing a standard such as this: I can see Microsoft, Intel, and AMD working on something like this, possibly Dell, but why Sun Microsystems?
The real power of snmp is what you can achieve through scripting it - queries and updates etc.
That becomes nigh-on impossible with this WS-Management craziness.
Typical Microsoft - always thinking there is some pleb click-clicking away.
Imagine you have to change some rmon threshold on 400+ devices, or integrate this with the corporate asset database.
Now you get the picture.
CIM is a fine, object-oriented replacement for SNMP, is mature and has XML-based communications over HTTP.
.PDF doesn't even reference CIM.
http://www.dmtf.org/standards/cim/
Microsoft already has a CIMOM implementation in its WMI service, although it uses DCOM to implement RPCs. Sun also has a CIMOM implementation for Solaris.
I find it very strange that the WS-Management
Using webservices for something like this seems like an enormous bandwidth waste to me. Whatever happened to optimization?
I don't mean to pooh pooh this idea just because it's somewhat Windows specific but the only real advantage I see to this over snmp is that the delivery modes are more sophisticated and the data can be organized hierarchally. So why not just add builtin event notification to snmp? Otherwise using XML for something that should be a low-cost service seems wrong to me. System monitoring should be as small and SIMPLE as possible to reduce the possibility for exploits as it will likely be running with a high level of anonymous access on almost every workstation, server, and router in the organization. The whole thing smells of XML pixie dust designed to drive up requirements and thus sell servers and new software to go with. If you have a problem with snmp then fix it. Don't reinvent it with techniques that are expensive in clock cyles and exploits.
I can totally see this standard easily integrating with the 1000+ network element monitoring and statistics gathering software package that I use right now. /sarcasm
It was a PITA enough just to get all of the devices reporting to the same polling engines. I can't even imagine going through and changing it all to some halfassed XML implementation. If they really want it to be an "SNMP replacement", they should just improve on what's already available. Make it compatible with SNMP but more powerful.
-Randy
People are more likely to adopt standards that they can implement without getting sued or shelling out large quantities of money to be allowed to adhere to. Despite the comments about the protocol being heavier than SNMP (TCP based, SOAP envelopes, etc.) I think there are cases where a richer, more extensible XML-based syntax would be nice for this kind of application. Or maybe SNMP is "good enough" that adoption will be limited (hard to say without reading the whole spec and comparing), but I don't think crapping on it just because it's Microsoft is fair, at least during those rare moments when they are playing well with others.
I agree, SNMPv3 is awesome. I'm using SNMP to both poll and manage hundreds of devices using but a single Debian box. The network overhead is practically nothing, and it "just works".
Without companies such as Cisco, Novell, HP, etc. coming on board, this WS-Management thing will likely just be another flash-in-the-pan.
I wonder if you could use XMPP (Jabber) to monitor devices. Each device connects to the server like a person IMing. It can easily send a message when something bad/good happens. You can have a roster (buddy list) of the devices you want to monitor.
I agree completely - however, I do wish to point out that ASN.1 and BER are a pain to code & maintain. XML is definitely an improvement, but I would argue its flexibility is what is going to fracture it. This is not putting down XML or its use, but on the so-called 'partners' who are involved in this 'deal' have an established pattern of adding their own 'extensions' which defeat interoperability and serve to enforce market share and not true integration.
If I were doing this, I would take the strenghts of SNMP (e.g., nice simple interface of get/set/walk etc). and make a HTTP style language for it. Extend the language for specific needs but don't make them optional. Keep the data and its overheads small and clean. And lest I forget, add a proper layer of security that may not have been important when SNMP came along but today is indispensible.
when a piece of metal needs to be monitored from something that further than a piece or two of cat5 away, being forced into UDP can make SNMP borderline useless. did the packet drop, or is the network down? hmm.. ill use SNMP to see if its the network. hmmm, negative. did the packet drop, or is ... rinse, repeat.
add the lack of error protection, and SNMP can be very very frustrating. and sure, UDP will make it *most* of the time, but there are a lot of applications for SNMP where most just isnt good enough.
SNMPv3 does largely mitigate the problems by allowing TCP instead of just UDP. but, the reason for not replacing SNMP also holds SNMP back: a lot of the massive instaled base is in big iron, that does not support SNMPv3 over TCP.
basically, the more ive worked with SNMP, the more ive realized that the "S" is the key letter. it is fantastic for some quick chores ona local reliable network, but just plain doesn't scale. there is a vast array of management and monitoring problems that just arent simple enough for SNMP to handle well.
If it guarantees delivery it would be much better. SNMP is udp and there is no way to know if the trap was recieved.
I've seen systems that are snmp based, where a cluster is used, and if the system has a fail-over many old traps are read again and alerted on. I think if the sending application can get an acknowledgement from the central app (netiq, netcool, compaq insight manager, tivoli, hp openview, etc) these type of false alerts would go away. When the sender can see the alert as a transaction it eliminates a lot of problems.
-Joe4
Silly Rabbit: tricks are for kids.
I think the idea is a good one, however it is prone to a security risk. A website has a domain name, these can easily be remembered and found by using a search engine. Now lets say you have this WS Management software, what good is it if it is run on a domain to control systems, because it could be searched and found out easily, this would mean that blackhat hackers would have an easy time finding out where to access the management software, and then they could proceed to gain access to it through exploitative penetration.