>>What about the fact that there are two SS now purging their locally stored events to the same ArchMgr at the same time?
>Normally, only the ArchiveManager on the primary SpectroServer should run. There is no need to enable the ArchiveManager on the Backup���� system. >So only the SrachiveManager on the primary system will be use. That was never doubted. :-) What I didn't have in mind was that there is always the possibility to start ArchMgr on the primary SS without starting the SS itself. That is, I let my secondary SS dump its stored event and stats records into my r9 ArchMgr before running the post-Install scripts on the primary SS (for which the SS had to be started at least in 8.1 times...) Thanks a lot for the cookbook, that sounds reliable! Freundliche Gr��ße / Best regards Christian Fieres Mainova AG Planung und Betrieb Infrastruktur (M3-ON2) Service Operation Center Solmsstra��e 38 60623 Frankfurt Telefon / Phone (069) 2 13-2 36 17 Mobil / Mobile (0170) 5 60 15 63 Telefax / Facsimile (069) 2 13-9 62 36 17 E-Mail [email protected] Mainova Aktiengesellschaft - Solmsstra��e 38 - D-60623 Frankfurt am Main Vorsitzende des Aufsichtsrates: Ober���rgermeisterin Dr. h. c. Petra Roth - Vorstand: Dr. Constantin H. Alsheimer (Vorsitzender), Lothar Herbst, Joachim Zientek Sitz der Aktiengesellschaft: Frankfurt am Main - Amtsgericht Frankfurt HRB 7173 - USt-ID-Nr. DE 114184034 "Ke��ler, Christoph" <[email protected]> 17.07.2009 08:55 An "Fieres, Christian" <[email protected]>, "spectrum" <[email protected]> Kopie Thema RE: Re: Antwort: [spectrum] Spectrum upgrade - best practice Hello, Normal way to upgrade an FT environment without Downtime/Gaps is: 1. Check, if the secondary SS can store enough Events in the SSdb (.vnmrc - max_event_records= ; increase the number, is necessary) 2. Archive Manager should not run on secondary SS 3. Shut down the primary SS including the ArchiveManager 4. Upgrade the primary System���� in that time, the secondary System would store all events into the SSdb 5. After Upgrade, start the ArchiveManager on SS primary SS (important: only the ArchiveManager���� not the SpectroServer !!) 6. Wait until the secondary SS moved all stored events to the primary System (you can watch this in OneClic����� VNM Model���� SpectroServer Contro����� Event Log Information) 7. After storing all Events into DDMdb, start the SpectroServer on the primary System 8. Shut down the secondary System and upgrade > When I turn on my ArchMgr to prepare secondary shutdown for r9.0 update, do *both* SS hand their locally stored records to my r9.0 ArchMgr? When you upgrade the primary SpectroServer, the secondary system will store the events into his local SSdb. On this system no ArchiveManger should run. > Does an r9.0 ArchMgr receive 8.1SP2 events and stores them? Yes. Not official supported, but a 8.1 system will send the events to a 9.0 system. I tested this with several upgrades on customer side. >What about the fact that there are two SS now purging their locally stored events to the same ArchMgr at the same time? Normally, only the ArchiveManager on the primary SpectroServer should run. There is no need to enable the ArchiveManager on the Backup���� system. So only the SrachiveManager on the primary system will be use. Hope this helps Best regards -- Christoph Ke��ler E-Mail: [email protected] amasol AG, Elsenheimerstr���e 7, 80687 M��nchen, Germany Phone: +49 89 1894743-24 Fax: +49 89 1894743-99 amasol Aktiengesellschaft ���r Informations- und Kommunikationstechnologie Aufsichtsrat: Dr. Stephan Kaiser (Vorsitzender) Vorstand: Wolfgang Bachmann, Stefan Deml, Thomas Dirsch, Johann Maurer Amtsgericht ���nchen HRB 128327, Sitz der Gesellschaft��ünchen From: Christian Fieres [mailto:[email protected]] Sent: Friday, July 17, 2009 7:45 AM To: spectrum Subject: WG: Re: Antwort: [spectrum] Spectrum upgrade - best practice Omar, list, does anyone know (or even has done it already) whether gapless event monitoring and logging is ensured during this process, and if yes, how it can be accomplished? Say I turn down my primary SS and my ArchMgr on my primary machine to do the upgrade to r9.0. My secondary takes over, monitors and stores its events in its SSdb. During migration, I have to switch my SS on to run post-install-scripts. At that time, ArchMgr is still down, my secondary has SSdb-side stored events and switches function over to my (now r9.0) primary. My primary generates alarms and stores it also in its SSdb. At that time, I have to "running" SS'es, one 8.1SP2, one r9.0, both have locally stores events (and stats, that is). When I turn on my ArchMgr to prepare secondary shutdown for r9.0 update, do *both* SS hand their locally stored records to my r9.0 ArchMgr? Does an r9.0 ArchMgr receive 8.1SP2 events and stores them? What about the fact that there are two SS now purging their locally stored events to the same ArchMgr at the same time? They should be unique, thus there should be no duplicate events, but their timestamps are presumably mixed up and everything. I will surely test this excessively before even touching my production, but can anyone clarify this in any way? Freundliche Gr��e / Best regards Christian Fieres Mainova AG Planung und Betrieb Infrastruktur (M3-ON2) Service Operation Center Solmsstre 38 60623 Frankfurt Telefon / Phone (069) 2 13-2 36 17 Mobil / Mobile (0170) 5 60 15 63 Telefax / Facsimile (069) 2 13-9 62 36 17 E-Mail [email protected] Mainova Aktiengesellschaft - Solmsstre 38 - D-60623 Frankfurt am Main Vorsitzende des Aufsichtsrates: Oberbrgermeisterin Dr. h. c. Petra Roth - Vorstand: Dr. Constantin H. Alsheimer (Vorsitzender), Lothar Herbst, Joachim Zientek Sitz der Aktiengesellschaft: Frankfurt am Main - Amtsgericht Frankfurt HRB 7173 - USt-ID-Nr. DE 114184034 [email protected] 30.06.2009 12:53 An Christian Fieres <[email protected]> Kopie Thema Re: Antwort: [spectrum] Spectrum upgrade - best practice Hi Christian, I've opened a case with CA support regarding this issue and they told me best practice would be as follows: 1. Upgrade the Primary SpectroSERVER first, to minimize downtime you can use fault tolerant server as Primary during this process. 2. Upgrade the Report Manager / BOXI and OneClick server (no more SpectroGraph). Be sure to read and follow the BOXI R2 upgrade instructions carefully as this is a complicated upgrade. Rerun the ServiceDesk and eHealth integrations. 3. Upgrade the Fault Tolerant SpectroSERVER 4. Once everything is back up and operational test for Fault Tolerance Be sure to read through the migration process documentation carefully as its a complex procedure. I've upgraded primary SS and installation was successful but when I tried to start Spectrum Control Panel, Java error was displayed and SCP could not be started. I've attached screenshot of the error. I've also upgraded Java to version 1.6.0_14 but it didn't help. Any suggestions? Srdaan pozdrav / Kind regards, ___________________ Omar Izetbego�� Sedam IT d.o.o. HR - 10 000 Zagreb Borongajska cesta 81a Tel: +385 1 2353 738 Fax: +385 1 2353 707 Mob: +385 91 2353 738 www.sedamIT.hr ---------------------------------- Christian Fieres <[email protected]> 16.06.2009 16:13 Please respond to Christian Fieres <[email protected]> To "spectrum" <[email protected]> cc Subject Antwort: [spectrum] Spectrum upgrade - best practice Omar, what I plan to do is pretty much the same, but I have four servers of which two are a fault tolerant SS environment (DDMdb and Archive Manager only active on #1) and OneClick resides on the two others (1:1 copy of each other). Last time, when I upgraded from 7.1SP3 to 8.1H12, I migrated the hardware, so it was a bit easier. In my case, there is no SD or EHealth integration, but we have to look after certain tools built around SPECTRUM in terms of Web Fault Management and Port Security, so this isn't going to be straightforward, either. :-( I intend to test customizations et.al. in my test lab until I know a way to rebuild them in my live environment. First step in real life would be upgrading my secondary server. Since half of my customizations reside in the SSdb and the other half is synchronized by ftp'ing the respective ascii files from my primary to my secondary via a cronjob, there is nothing more to do here except make sure my .vnmrc knows everything important for fault tolerance (wait_active=yes and everything that ensures gapless event creation). I intend to install a temporary OC in a Solaris Container for visualization purposes during update since SG is dead... you might do the same with an old Windows box or a VM session. After my secondary works well and is "running" (i.e., waiting to become active), I pray to the Gods of 0xbeef that there is nothing that prevents a 9.0 secondary from becoming active when its 8.1 neighbor goes down... that worked well when upgrading from 7.1 to 8.1, that is. According to Radio Eriwan, my newly installed secondary should thus become the master as soon as I stop the SS on my primary box. Remember to ensure that it temporarily stores event and statistic logs. As far as the secondary SS is concerned, its primary Archive Manager version should be irrelevant - and the SSdb should have been converted as if it was on a standalone system, I hope. This is something that I intend to test to the ground in my lab. Next do a DDM backup (just in case), upgrade to 9.x, rebuild your customizations and make sure ArchMgr starts only on your manually given "Go" to prevent DDM corruption. A final SSdb backup for knowledge base and modelling catalog sync is important, in my case also a sync in terms of ascii customizations (see above). That way there should be no gap in regards to event logging - which is what we need. Getting a maintenance window for Fault Management is easy, but in terms of SLA monitoring, availability logging is of #1 importance and gaps are a total no-go. If anyone can add anything that may contribute to my plans, please let me know so that myself and Omar do not run into a disaster. Thanks a lot! Freundliche Ge / Best regards Christian Fieres Mainova AG Planung und Betrieb Infrastruktur (M3-ON2) Service Operation Center Solmsst��e 38 60623 Frankfurt Telefon / Phone (069) 2 13-2 36 17 Mobil / Mobile (0170) 5 60 15 63 Telefax / Facsimile (069) 2 13-9 62 36 17 E-Mail [email protected] Mainova Aktiengesellschaft - Solmss���e 38 - D-60623 Frankfurt am Main Vorsitzende des Aufsichtsrates: Oberrgermeisterin Dr. h. c. Petra Roth - Vorstand: Dr. Constantin H. Alsheimer (Vorsitzender), Lothar Herbst, Joachim Zientek Sitz der Aktiengesellschaft: Frankfurt am Main - Amtsgericht Frankfurt HRB 7173 - USt-ID-Nr. DE 114184034 [email protected] 16.06.2009 15:49 Bitte antworten an [email protected] An "spectrum" <[email protected]> Kopie Thema [spectrum] Spectrum upgrade - best practice Hi everyone, I have Spectrum 8.1 installed on 3 Windows 2003 servers in a fault tolerant environment and plan to upgrade to v9.0 and then maybe on 9.1. On primary server I've got SpectroServer installed. On secondary server I've got SpectroServer, SpectroGraph and OneClick. On third server I have OneClick, SpectroGraph and Report Manager installed. Spectrum is integrated with eHealth and Service Desk. Which is the best way to make the upgrade and to have minimum system downtime? In which order should I upgrade servers? I'm aware that there are many problems around the corner regarding customizations and integrations so I'm asking you to give me some advices and tips&tricks, something to look after. Do I need to upgrade BOXI also? Are customizations I've made available after ugrade? Many thanks! Srdan pozdrav / Kind regards, ___________________ Omar Izetbegovi Sedam IT d.o.o. HR - 10 000 Zagreb Borongajska cesta 81a Tel: +385 1 2353 738 Fax: +385 1 2353 707 Mob: +385 91 2353 738 www.sedamIT.hr ---------------------------------- Napomena: Ova poruka sadrzi podatke povjerljive prirode, iskljucivo namijenjene osobama oznacenima kao primateljima te se pristup od strane bilo koje druge osobe smatra neovlastenim. Ukoliko niste oznaceni primatelj, svaka distribucija, kopiranje, umnozavanje ili otkrivanje sadrzaja trecim osobama je strogo zabranjeno i smatra se protuzakonitim. Ukoliko ste dobili ovu poruku, a niste oznaceni primatelj, molimo Vas da sto prije obavijestite posiljatelja poruke i unistite sve postojece kopije. Ova napomena takodjer potvrdjuje da je ova elektronicka poruka testirana na postojanje racunalnih virusa. Disclaimer: The information in this email is confidential and it is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any distribution, copying, duplication or disclosure is prohibited and may be unlawful. If you have received this email in error, please notify the sender immediately and destroy it, and all copies of it. This footnote also confirms that this email message has been swept for the presence of computer viruses. --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] Napomena: Ova poruka sadrzi podatke povjerljive prirode, iskljucivo namijenjene osobama oznacenima kao primateljima te se pristup od strane bilo koje druge osobe smatra neovlastenim. Ukoliko niste oznaceni primatelj, svaka distribucija, kopiranje, umnozavanje ili otkrivanje sadrzaja trecim osobama je strogo zabranjeno i smatra se protuzakonitim. Ukoliko ste dobili ovu poruku, a niste oznaceni primatelj, molimo Vas da sto prije obavijestite posiljatelja poruke i unistite sve postojece kopije. Ova napomena takodjer potvrdjuje da je ova elektronicka poruka testirana na postojanje racunalnih virusa. Disclaimer: The information in this email is confidential and it is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any distribution, copying, duplication or disclosure is prohibited and may be unlawful. If you have received this email in error, please notify the sender immediately and destroy it, and all copies of it. This footnote also confirms that this email message has been swept for the presence of computer viruses. --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]
