1 / 14

Site Maintenance

Site Maintenance. M3 Maintenance Management System. System Upgrade 2009/10. Kevin Farish M3 Technical Manager May 2010. Site Maintenance. Introduction. The M3 system hardware & software were upgraded at the start of 2009 Included upgrade to M3 7.1 Tech, Workplace 5.3.3, and Streamserve v4

emi-mann
Download Presentation

Site Maintenance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Site Maintenance

  2. M3 Maintenance Management System System Upgrade 2009/10 Kevin Farish M3 Technical Manager May 2010 Site Maintenance

  3. Introduction • The M3 system hardware & software were upgraded at the start of 2009 • Included upgrade to M3 7.1 Tech, Workplace 5.3.3, and Streamserve v4 • The M3 development system was upgraded at the start of 2010 • New development system uses virtualised Wintel servers Site Maintenance

  4. Reasons for the upgrade • System installed in 2004 to replace obsolete maintenance management system with a single Sun V480 running the M3 application and the Oracle database • Dedicated Oracle database server (Sun V480) added in 2006 with additional storage capacity • This upgrade designed for a significant increase in user base from ≈ 700 to ≈ 2000; integration into M3 of other obsolete systems; and improved system performance • SAN storage added to cope with increasing data volumes (approx. 2% per month = doubling every 3 years)

  5. M3 System Upgrade • All M3 system servers were replaced (with the exception of the M3 Output Manager) to provide significantly increased computing power • The upgrade added a dedicated SQL database server • Application and Database servers upgraded to Solaris 10 • The core M3 system application software was upgraded to Version 7.1 (Tech). M3 Workplace upgraded to v5.3.3 • M3 databases moved to a SAN (Storage Area Network) for increased performance and reliability • The Oracle database was upgraded from v9 to v10g

  6. M3 System Diagram End Users Data Centre

  7. M3 Production Servers 1. Business Performance Warehouse 2. Lawson Business Intelligence 3. Storage Area Network

  8. Remote Data Centre M3 Production

  9. How the upgrade was managed • New production system installed, commissioned & tested in a separate (on-site) data centre • Two test runs completed for database upgrade (v9 to 10g) prior to final cutover • Cutover completed during a 2 day outage • Previous system left running (but unused) for 1 week as a fallback position in case of unforeseen problems • New development system re-used the previous production M3 Application and M3 Database servers • Original development system software also upgraded as an interim measure whilst new development system built

  10. 4*UltraSparc III 1.2GHz CPU, 16GB 2*UltraSparc III 1.2GHz CPU, 10GB M3 Development VMware ESX Servers

  11. Creating new VMware development environment • New development system Wintel servers all implemented on existing ESX infrastructure • Servers created using a Physical to Virtual (P2V) tool, VMware vCentre Converter, which created a Virtual Machine from an Image of the corresponding Production Servers. • Each VM configured with new IP addresses and server-names.

  12. M3 Application & Database • M3 Application and M3 Database servers re-used the previous production Sun servers • Both servers were cleared down completely and O/S re-installed. • Oracle version 10g installed on database server by DBA • M3 application installed by copying folder structure from production server • System configuration files updated manually by Lawson prior to starting the application

  13. Send in the Clones • The Physical to Virtual (P2V) process produces an exact clone of the real server • This includes embedded server names, IP addresses, port numbers, usernames, passwords etc. • This is ideal for Business Continuity purposes, but problematic if servers are to be in addition to the original • Great care is needed to ensure all relevant parameters are changed prior to application start up to prevent unintended consequences.

  14. And finally . . . Any questions?

More Related