Efficient Upgrades Steve Mallam, Sales Engineer
Highly available systems 24/7/365 Service Level Agreements Mission critical operations Time sensitive work $$$£$ Upgrade Considerations
Efficient for the users Not necessarily for you Need to be planned in advance Need to be appropriate for the application Efficient Upgrades
201x In-place installer upgrade Basic Upgrade Process Application is down for the duration
In-place installer upgrade Basic Upgrade Process Application is down for the duration Fall-back can be difficult
2012 Parallel Installation 2013 Install a second system alongside original
2012 In-place installer upgrade Basic Upgrade Process
2012 Parallel Installation 2013 Install a second system alongside original Then cut over
2012 Need to ensure data is up-to-date Parallel Installation 2013 Install a second system alongside original Then cut over
Store data and code in separate databases Separation of Data and Code 2012 D C
2013 C Store data and code in separate databases Separation of Data and Code 2012 D C
2013 Store data and code in separate databases Separation of Data and Code 2012 D C C D
2013 D Store data and code in separate databases Separation of Data and Code 2012 D C C
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
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
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
M2M1 How does this help us…? Upgrade Backup M1MirroringM
M2 How does this help us…? Upgrade Backup Force failover M1MirroringM
M2M1 How does this help us…? Upgrade Backup Force failover Upgrade (original) PrimaryMirroringM
How does this help us…? Upgrade Backup Force failover Upgrade (original) Primary (Optionally) fail back M1M2MirroringM
Introduce one or more Application Servers that execute code D App1 Enterprise Cache Protocol (ECP) App2 Solution for horizontal scaling
Introduce one or more Application Servers that execute code Can keep adding… D App1 Enterprise Cache Protocol (ECP) App2AppN … Solution for horizontal scaling
M1M2 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy
M2M1 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy
M1M2 Enterprise Cache Protocol (ECP) M Connection lost when mirror fails over NB: For more details see “Mirroring for High Availability” academy
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
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
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
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
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
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
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
App1 M1 C M2 C Upgrade App1 Shutdown App1 Upgrade Minimal Downtime Upgrades M App2 Load Balancer CC
App1 M1 C M2 C Upgrade App1 Shutdown App1 Upgrade Switch to new code Restart App1 Minimal Downtime Upgrades M App2 Load Balancer CC
App2App1 M1 C M2 C Repeat for App 2 Shutdown App2 Upgrade Minimal Downtime Upgrades M Load Balancer CC
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
M2 Upgrade Mirrors Prevent failover Upgrade Mirror2 M1 App2 App1 Minimal Downtime Upgrades M Load Balancer CC
M1 Upgrade Mirrors Prevent failover Upgrade Mirror2 Force failover M2 C App2 App1 Minimal Downtime Upgrades M Load Balancer CC
M1 Upgrade Mirrors Prevent failover Upgrade Mirror2 Force failover Prevent failover Upgrade Mirror1 M2 C App2 App1 Minimal Downtime Upgrades M Load Balancer CC
In-place upgrades Parallel installations Separation of code and data Mirroring ECPSummary
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
Understand user needs Determine how you will handle upgrades Design the system to support the approach Speak to us!Recommendations
Mirroring for High Availability 11:00 08:30 Minimum Downtime Upgrades 16:30 08:30 14:00 Follow-On Academies Orlando M Orlando N
Efficient Upgrades Steve Mallam, Sales Engineer