1. Efficient Upgrades Steve Mallam, Sales Engineer

2. Highly available systems 24/7/365 Service Level Agreements Mission critical operations Time sensitive work $$$£$ Upgrade Considerations

3. Efficient for the users Not necessarily for you Need to be planned in advance Need to be appropriate for the application Efficient Upgrades

4. 201x In-place installer upgrade Basic Upgrade Process Application is down for the duration

5. 20122013 In-place installer upgrade Basic Upgrade Process Application is down for the duration Fall-back can be difficult

6. 2012 Parallel Installation 2013 Install a second system alongside original

7. 2012 In-place installer upgrade Basic Upgrade Process

8. 2012 Parallel Installation 2013 Install a second system alongside original Then cut over

9. 2012 Need to ensure data is up-to-date Parallel Installation 2013 Install a second system alongside original Then cut over

10. Store data and code in separate databases Separation of Data and Code 2012 D C

11. 2013 C Store data and code in separate databases Separation of Data and Code 2012 D C

12. 2013 Store data and code in separate databases Separation of Data and Code 2012 D C C D

13. 2013 D Store data and code in separate databases Separation of Data and Code 2012 D C C

14. M2M1 InterSystems’ High-Availability solutionMirroringM Clients connect to virtual IP Updates replicated across both instance NB: For more details see “Mirroring for High Availability” academy

15. M2M1 InterSystems’ High-Availability solutionMirroringM Clients connect to virtual IP Updates replicated across both instances If M1 fails… NB: For more details see “Mirroring for High Availability” academy

16. M1M2 InterSystems’ High-Availability solutionMirroringM Clients connect to virtual IP Updates replicated across both instances If M1 fails… … M2 can take over NB: For more details see “Mirroring for High Availability” academy

17. M2M1 How does this help us…? Upgrade Backup M1MirroringM

18. M2 How does this help us…? Upgrade Backup Force failover M1MirroringM

19. M2M1 How does this help us…? Upgrade Backup Force failover Upgrade (original) PrimaryMirroringM

20. How does this help us…? Upgrade Backup Force failover Upgrade (original) Primary (Optionally) fail back M1M2MirroringM

21. Introduce one or more Application Servers that execute code D App1 Enterprise Cache Protocol (ECP) App2 Solution for horizontal scaling

22. Introduce one or more Application Servers that execute code Can keep adding… D App1 Enterprise Cache Protocol (ECP) App2AppN … Solution for horizontal scaling

23. M1M2 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy

24. M2M1 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy

25. M1M2 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy

26. M1M2 App1 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over Introduce ECP NB: For more details see “Mirroring for High Availability” academy

27. M2M1 App1 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over Introduce ECP When mirror fails NB: For more details see “Mirroring for High Availability” academy

28. M1M2 App1 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over Introduce ECP When mirror fails ECP maintains connection NB: For more details see “Mirroring for High Availability” academy

29. M1M2 App1 Still need to upgrade the Application Server… Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over Introduce ECP When mirror fails ECP maintains connection NB: For more details see “Mirroring for High Availability” academy

30. S M1 C M2 C A truly robust solution Mount code in separate instance Minimal Downtime Upgrades App1 M App2 Load Balancer C NB: For full details of this process see “Minimal Downtime Upgrades” academy

31. S C M1 C M2 C A truly robust solution Mount code in separate instance Recompile Minimal Downtime Upgrades App1 M App2 Load Balancer NB: For full details of this process see “Minimal Downtime Upgrades” academy

32. S C M1 C M2 C A truly robust solution Mount code in separate instance Recompile Mount on both mirror servers Minimal Downtime Upgrades App1 M App2 Load Balancer CC NB: For full details of this process see “Minimal Downtime Upgrades” academy

33. App1 M1 C M2 C Upgrade App1 Shutdown App1 Upgrade Minimal Downtime Upgrades M App2 Load Balancer CC

34. App1 M1 C M2 C Upgrade App1 Shutdown App1 Upgrade Switch to new code Restart App1 Minimal Downtime Upgrades M App2 Load Balancer CC

35. App2App1 M1 C M2 C Repeat for App 2 Shutdown App2 Upgrade Minimal Downtime Upgrades M Load Balancer CC

36. Repeat for App 2 Shutdown App2 Upgrade Switch to new code Restart App2 App2 App1 M1 M2 C Minimal Downtime Upgrades M Load Balancer CC

37. M2 Upgrade Mirrors Prevent failover Upgrade Mirror2 M1 App2 App1 Minimal Downtime Upgrades M Load Balancer CC

38. M1 Upgrade Mirrors Prevent failover Upgrade Mirror2 Force failover M2 C App2 App1 Minimal Downtime Upgrades M Load Balancer CC

39. M1 Upgrade Mirrors Prevent failover Upgrade Mirror2 Force failover Prevent failover Upgrade Mirror1 M2 C App2 App1 Minimal Downtime Upgrades M Load Balancer CC

40. In-place upgrades Parallel installations Separation of code and data Mirroring ECPSummary

41. Upgrade Mirrors Prevent failover Upgrade Mirror2 Force failover Prevent failover Upgrade Mirror1 (Optionally) fail back to Mirror 1 Application has NEVER been down! M2 M1 App2 App1 Minimal Downtime Upgrades M Load Balancer CC

42. Understand user needs Determine how you will handle upgrades Design the system to support the approach Speak to us!Recommendations

43. Mirroring for High Availability Tuesday @ 11:00 Wednesday @ 08:30 Minimum Downtime Upgrades Monday @ 16:30 Tuesday @ 08:30 Wednesday @ 14:00 Follow-On Academies Orlando M Orlando N

44. Efficient Upgrades Steve Mallam, Sales Engineer