1 / 44

Efficient Upgrades

Efficient Upgrades. Steve Mallam, Sales Engineer. Upgrade Considerations. Highly available systems 24/7/365 Service Level Agreements Mission critical operations Time sensitive work $$$£$. Efficient Upgrades. Efficient for the users Not necessarily for you

lore
Download Presentation

Efficient Upgrades

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. Efficient Upgrades Steve Mallam, Sales Engineer

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

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

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

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

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

  7. Basic Upgrade Process • In-place installer upgrade 2012

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

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

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

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

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

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

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

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

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

  17. Mirroring How does this help us…? • Upgrade Backup M2 M1 M1 M

  18. Mirroring How does this help us…? • Upgrade Backup • Force failover M2 M1 M

  19. Mirroring How does this help us…? • Upgrade Backup • Force failover • Upgrade (original) Primary M2 M1 M

  20. Mirroring How does this help us…? • Upgrade Backup • Force failover • Upgrade (original) Primary • (Optionally) fail back M1 M2 M

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  40. Summary • In-place upgrades • Parallel installations • Separation of code and data • Mirroring • ECP

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

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

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

  44. Efficient Upgrades Steve Mallam, Sales Engineer

More Related