Hello Christian, list, a rfc2790 based monitored filesystem within Spectrum is represented by a distinct model within the SSdb which has relations to the parent device model. The relation type presumably is limited to a 1-to-1 situation. Additionally there is the option to "alarm if filesystem is offline", what actually does what it says. I guess in your case, a filesystem would become offline on a particular server, if it is switched over to another cluster member. You probably do not want to get an alarm each time here.
You might try to establish a corresponding filesystem monitor on each of the physical cluster members leaving the "alarm if filesystem is offline" off. To get there, you need to manually switch the filesystem to each member, to see it within the rfc2790 filesystem table or add that filesystem to all cluster nodes using a rfc2790 monitoring rule. If needed, you could monitor the DFS virtual IP reachability using SPM tests. Mit freundlichen Gruessen - Yours sincerely Raphael Franck Consultant Global Infrastructure Operations Computacenter AG & Co oHG Services & Solutions Europaring 34-40, 50170 Kerpen, Germany E-Mail: [email protected] WWW: www.computacenter.de Von: Christian Fieres [mailto:[email protected]] Gesendet: Donnerstag, 6. März 2014 10:39 An: spectrum Betreff: [spectrum] Monitoring distributed file systems 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] ----------------------------------- Computacenter AG & Co. oHG, mit Sitz in Kerpen (Amtsgericht Köln HRA 18096) Vertretungsberechtigte Gesellschafter: Computacenter Aktiengesellschaft, mit Sitz in Köln (Amtsgericht Köln HRB 28384) Vorstand: Tony Conophy Aufsichtsrat: Michael Norris (Vorsitzender) Computacenter Management GmbH, mit Sitz in Köln (Amtsgericht Köln HRB 28284) Geschäftsführer: Dr. Karsten Freihube, Dr. Christine Haupt, Reiner Louis, Thomas Jescheck, Nils Scheller Visit us on the Internet: http://www.computacenter.de Visit our Online-Shop: https://shop.computacenter.de This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this mail in error, please tell us immediately by return email and delete the document. ----------------------------------- --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
