I think the disconnect is coming from an understanding of what "distributed" means to Spectrum. This has been interpreted many ways and is actually described well in the docs, but can be difficult to grasp the full concept. If possible, I highly recommend going to CA training because you can play with the concept and work with the trainer to try different scenarios. I have been working with Spectrum for many years and still have to think about the pieces. Now that I am done with that suggestion, I'll try to answer what you have here.
Whenever you have more than one SpectroSERVER that are communicating with each other (other than as a backup), you have a "distributed" setup. The SpectroSERVERs don't forward alarms to each other (except in special situations I won't go into here) it is up to the client applications to get the alarms from the different servers. So OneClick, or in this case AlarmNotifier registers with the SpectroSERVERs to receive alarms from them. You can't setup a daisy chain. It may appear that way if the AlarmNotifier is running on server A1 and is processing alarms from Server A1 and B1, however what AlarmNotifier has done is to actually register to received alarms from both servers and process the requests that come from each SpectroSERVER independently. Now when you add fault tolerance, it gets a little more tricky, but the concept is still the same. With fault tolerance, A1 and A2 both have the same landscape handle but different "precedence" (likewise B1 and B2). Client apps like AlarmNotifier will listen to the server with the lower precedence (A1,B1) unless it looses contact to that server and then will connect to the server with the higher precedence (A2,B2) until it can contact the "primary" server again. Now to try to simplify all that: On A1 you have AlarmNotifier running. AlarmNotifier connects to SpectroSERVERs on A1 and B1 normally. If AlarmNotifier can not contact the SpectroSERVER on A1 it connects to the SpectroSERVER on A2. If AlarmNotifier can not contact the SpectroSERVER on B1 it connects to the SpectroSERVER on B2. It is completely up to AlarmNotifier to handle which server it receives alarms from. The alarms from the SpectroSERVERs on B* are not processing through the SpectroSERVER on A1. Now if you want to have multiple AlarmNotifiers running and feeding NetCool, you will have to build your own logic to remove the duplicate alarms. One suggestion is to have some type of header that indicates which AlarmNotifier the alarm comes from and then use Impact to sort through all that. Hopefully this helps you pull the concepts together. (Note for those not familiar with NetCool - the NetCool probe uses a "captured" AlarmNotifier to gather the alarms) A cheaper suggestion - Investigate CA's new product Event Integration Service as a replacement to NetCool. We are in the process of replacing NetCool with EIS. We were stuck with NetCool due to the need to enrich alarms with data from an external database, but now with EIS we can do that an more. Bill Barnes ________________________________ From: Calvin Lane [mailto:[email protected]] Sent: Tuesday, April 07, 2009 5:58 PM To: spectrum Cc: spectrum Subject: Re: [spectrum] Is this failover scenario feasible? Thanks for the great response Cristi. The 2 SSs will not be configured to be distributed. They will actually be seperate pollers with just one SS fowarding alarms to the other SS (at least this is what the customer is looking for). As a follow up question, can SSs be 'daisychained' in that fashion? What are the various methods for sending alarms between SSs? Also, true the Alarm Notifier is not fault tolerant? But, if you have the same policy/filter configurations on both the primary and secondary, then they should both behave the same when either box is active. Correct? Thanks again. Calvin On Tue, Apr 7, 2009 at 5:02 PM, Mitrana Cristian <[email protected]> wrote: Calvin Lane wrote: Hello everyone, I have a customer that wants to design a failover/fault tolerant soluction such that all SPECTRUM data/events/alarms are funnelled through one primary SpectroServer that forwards alarms over to a Netcool object server. Please refer to the attached diagram and let me know if this conceptual design is feasible. Thanks. Using Spectrum just to send alarms kind of defeats the purpose ... as its primary function is to act as a NFM and not as a NPM. The above scenario implies 2 SS with failover backups (distributed ?). As it was discussed in the past on the list, the Alarm Notifier (which I assume you must be using it to forward alarms to Netcool) is not fault tolerant so you really don't have an option in the proposed scenario. Maybe if you monitor the failover process (from Netcool ?) you could trigger Alarm Notifier start on the failover and then stop it on failback. Look under the 9.0 documents for failover to see how this kind of monitoring could be done. hth, -- Cristi Mitrana --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected] * --To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
