List, yesterday I was able to do some testing in a lab environment. My DFS specialist migrated a volume I was monitoring from one hardware to the other, and it seems to have worked as expected.
In Layman's terms: Model your physical servers by IP (or name) Manually model your cluster volumes using Model Type Host_Device and their respective IPs Don't worry about the "Duplicate models" alarms Using one volume model's System Resources View, configure a file system monitor for (e.g.) File System "J:\ Label:Vol-FS05-DAT05 Serial Number 687e7d8", which results in a model named "j:\" (which, in conjunction with its server parent, represents the specific file system in this constellation), disable "Alarm if offline" and configure thresholds for utilization Thresholds work as expected and trigger an event and/or alarm if violated If the volume migrates to another physical server, its respective IP address is also switched which leads, as I expeced, SPECTRUM to communicating with the new physical server (distinguishable by the volume model's "System Name" attribute) - the connection between "volume model" and file system model persists as the drive letter remains the same! - and seemlessly continuing management. For the operator, the migration is totally invisible except for - under ideal conditions - some events that state a short loss of contact to the resources in question. However, monitoring availability or even migration events is not what we want to do, thus: job done. Under lab circumstances, it worked as a charm except for the "duplicate model" alarms which are totally reasonable and must be cleared manually. I will try to deploy this in production and, if I come across something worth noticing, I'll keep you updated. 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 c.fie...@mainova.de Internet http://www.mainova.de ----- Weitergeleitet von Christian Fieres/M3-ST/MAINOVA/DE am 07.03.2014 10:32 ----- Von: "Christian Fieres" <c.fie...@mainova.de> An: "spectrum" <spectrum@listserv.unc.edu>, Datum: 06.03.2014 12:51 Betreff: Antwort: AW: [spectrum] Monitoring distributed file systems Raphael, thanks for your hints! Switching the file systems to all servers just to see them once in the table is out of question ;-), the monitoring rule style seems reasonable, especially because "alarm if offline" is not used in our environment and always set to disabled. One obstacle: I need to find out if the file systems' name is the same on every server. Maybe our fileservices folks have a lab installation to test that. (I assume name equality is essential for the deployment of a moniroting rule.) One thoght: This (deployment via monitoring rule) surely is necessary when sticking to my four physical servers as four single dedicated models only. I *do* have the chance to model those cluster servers by using the volumes' respective IP addresses, this should allow me to have one single file system monitor model per volume. Do you know how SPECTRUM behaves in this case? The relationship between the file system monitor and the server model would exist, and in my opinion the failover to another physical server should be working from a management point of view because even if this meant SPECTRUM should have to kind of re-assign the connection between server and volume (though I think it would persist!), it is comparable to the solution you posted because *there* I do not have a real volume on three of the servers in the first place. Am I thinking right? 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 c.fie...@mainova.de Internet http://www.mainova.de Von: "Franck, Raphael" <raphael.fra...@computacenter.com> An: "spectrum" <spectrum@listserv.unc.edu>, Datum: 06.03.2014 12:03 Betreff: AW: [spectrum] Monitoring distributed file systems 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: raphael.fra...@computacenter.com WWW: www.computacenter.de Von: Christian Fieres [mailto:c.fie...@mainova.de] 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 c.fie...@mainova.de 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 lists...@unc.edu with the body: unsubscribe spectrum raphael.fra...@computacenter.com ----------------------------------- 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 lists...@unc.edu with the body: unsubscribe spectrum c.fie...@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 lists...@unc.edu with the body: unsubscribe spectrum c.fie...@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 lists...@unc.edu with the body: unsubscribe spectrum arch...@mail-archive.com
