by November 17, 2005 0 comments

The last mantra talked about how you could setup ways to figure out what on a system was causing problems. In our previous issues too, we’ve talked about various types of monitoring and how to set them up. However, it doesn’t always work the way you want it to and things are still mystifyingly untraceable when something bad happens.

Which management standard?
Till sometime back, SNMP ruled the roost as far as network management was concerned. It was the default protocol when it came to monitoring and alerting network-related problems. But you can’t rely on SNMP for all your management tasks. One of the reasons is that vendors don’t let everything in their devices to be managed with SNMP. You need to purchase a proprietary-management solution from the vendor for the rest. Nevertheless, you still need SNMP today to keep a close watch of your critical equipment. But that’s not all. With an expanding infrastructure, remote-management services have become a must, because you don’t want to be hopping all over the place to manage everything. E-mail-based alerting and paging over cellphones is the other key technology that’s become very popular. You basically need a mix of various technologies to ensure minimum downtime across all your equipment, whether servers or network equipment.

Desktop firewalls don’t help
Almost every advisory out there implores you to run one firewall or the other, and atleast one anti virus. The tough part in following that advice is that a firewall (and the firewall part of an anti virus) is meant to keep out unknown traffic from that system. To allow a monitoring software to do its job, you need to punch a hole in this firewall by opening the relevant ports-unless well documented or that vendor provides support for this, it is quite a difficult task. This is more relevant for small to medium enterprises. Large enterprises are anyways expected to run network level firewalls. 

Single or multiple vendors?
If you have a heterogeneous, multi-vendor environment, then it can cause configuration and compatibility problems. The ‘one-vendor’ route, ties you down to their technologies and products, some of which could be proprietary; and the vendor can charge you a bomb for the support. 

In a multi-vendor scenario, the usual route taken by tech support is to point the finger at the other vendor’s products and disown responsibility for downtimes. Both options have to be weighed carefully. Whatever you choose, two things become very important. One is how you fix your SLAs with the vendor, and two how well do you establish your equations with them. 
What’s needed here is tactful dealing rather than a fair and to-the-point one. If you hold a gun on a vendor’s head for not meeting something in the SLA, then the vendor may return the courtesy by not going out of the way to support you in the future. Often we’ve heard stories from IT heads on how a vendor came to the rescue even when a server went down in the middle of the night. Treat vendors as partners is the advice we’ve heard from the experienced, and that’s what we’d also suggest.

Till recently, the chant was ‘standardize’. The question today is ‘standardize on what?’ Three immediate things come to mind-platform, equipment and technology. Then there’s the classic debate of ‘open or closed’ standards. Standardizing on one platform or equipment from one vendor could bring the old ‘single or multiple vendors’ debate back. 

On the technology front, go for something that’s widely accepted, and is going to be around for a long time. TCP/IP and XML for instance has become the de-facto standard on all networks today, because every networking vendor and software support them.The open vs closed standards debate is beyond the scope of this article.

When going for standardization on any of the above, just keep the cost of maintaining it in mind. What’s the loss to your organization for not conforming to a particular standard? Are you paying heavily through downtime because you’ve not standardized? To take a simple case, we’ve seen an organization that standardized all desktops to Windows XP Professional. 
Earlier they were using multiple OSs, which was causing too many hassles in terms of application incompatibility, interoperability issues and desktop inventory control. Standardizing on one platform helped the organization reduce its maintenance operations and improve the overall productivity.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.