Hi all, in advance to an upcoming brainstorming meeting to clarify possible ways of migrating a Windows based volume space check to our SPECTRUM environment, the following question crossed my mind. This is to be accomplished with SPECTRUM 9.2.2H9 on Solaris. There is a possibility of using a set of two Cisco IPSLA test hosts and two SystemEdge test hosts, if that is of any help to the case.
Say I have a MS Windows 2008 DFS installation with a number of volumes existing on a cluster of four physical servers. (I am *not* a Windows kind of person, so please excuse possible stupidities in the following terminology.) Each volume has an IP address assigned to it which, this much seems to logic to me, leads to one of the four physical servers, depending on the one holding the volume right now. Modelling by hand and accepting all "multiple IP address" alarms, I am ending up having a number of coexisting SNMP capable models that support the HOST MIB as a part of the Microsof SNMP agent - one model per volume. In old days, having one physical server representing a set of partitions, I would start by navigating into the System Resources subview, open the File Systems Folder, choose the RFC2790 subview and ... monitor the file systems. Case closed. Whenever a volume's occupied space exceeds X gigabytes, an event triggers an alarm. Goal. This might work in the distributed world, it might not. What annoys me is that there is no durable connection between server and volume. I tried to point my finger on the one attribute that links the file system monitor model to the actual file system represented in the corresponding MIB table and found no index, no anything. There is simply no value that doesn't change no matter what part of accessible names and descriptions of the model I alter (name/description etc.). So I have no clue whether SPECTRUM would be able to handle a failover of this specific volume from one physical server to the other. What happens whan a failover occurs? I can only guess; I would expect the SNMP agent responding to a poll onto the file systems' IP address to change from one physical server to the other - that much seems pretty clear. The question is: How does SPECTRUM handle this change in regards to the file system monitor? Am I in danger of losing the cnnection between my file system model and the actual volume on - now - another server reachable by the same old IP address, but being a completely different hardware, possibly using a different volume name for the same volume? One thing that bothers me is that the physical servers seem to map the volumes onto local disk letters, as I currently have descriptions like "I:\ Label:Vol-FS04-DAT04 Serial Number 665a9c99" (those values can be seen in the File Systems' table "File System Name" field and default for the Description attribute whan launching the "Monitor file system" dialogue). I have no idea, neither whether this description changes in the case of a failover, nor if that question is of any importance to the case. Maybe this is all not that much of a problem, but I can't test it actually. So is there anyone out there who has already been there? Freundliche Grüße / Best regards Christian Fieres Mainova AG Netz- und Infrastruktur (M3-ST4) Solmsstraße 38 60623 Frankfurt am Main Telefon / Phone 069 213 23617 Mobil / Mobile 0170 5601563 Telefax / Facsimile 069 213 9623617 E-Mail [email protected] Internet http://www.mainova.de Mainova Aktiengesellschaft Solmsstraße 38 D-60623 Frankfurt am Main Vorsitzender des Aufsichtsrates: Stadtkämmerer Uwe Becker Vorstand: Dr. Constantin H. Alsheimer (Vorsitzender), Prof. Dr.-Ing. Peter Birkner, Norbert Breidenbach, Lothar Herbst Sitz der Aktiengesellschaft: Frankfurt am Main Amtsgericht Frankfurt HRB 7173 USt-ID-Nr. DE 114184034 Mainova steht für besten Service, faire Verträge und top Preise für Ihre Energie - mit Auszeichnung! Mehr Infos unter: http://www.mainova.de/auszeichnung --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
