Applying a patch without downtime, but there is Redeploy and Restart steps
Hi All,
I have checked Applying a patch without downtime in this link:
https://docs-previous.pega.com/keeping-current-pega/86/applying-patch-without-downtime
https://docs-previous.pega.com/keeping-current-pega/86/red-hat-jboss-eap-redeploying-pega-platform
But, there are steps to Redeploy the application and Restart the application server. Do you know what means Applying a patch without downtime/zero-downtime?
Thank you
***Edited by Moderator Marije to add Capability tags***
Pegasystems Inc.
US
Hi @OdiS9903, thanks for reaching out. Zero-downtime means that users will not experience disruption while performing the patch update. The documents you linked to describe Pega's best practices for on-premise deployments.
Pegasystems Inc.
US
hi @OdiS9903
for the latest patch content, use this link>https://docs.pega.com/bundle/platform-88/page/platform/deployment/patch-update-84-later-intro-1.html
I'm updating the restart instruction to indicate the process invokes a rolling restart so the patch restart doesn't involve downtime.
ASD
ID
Hi @Brodie @Thomas Aciukewicz, thanks for your response.
- I still don’t understand. In this link, there is a step to stop prweb.war and remove/undeploy applications. This means it applications will downtime and the web app (prweb) can't be accessed right?https://docs.pega.com/bundle/platform-88/page/platform/deployment/redeploy-app-serv-new-rules-1.html
- I check on this link, there is “Patches are reversible”. Can you tell me step by step how to reversible the patch?https://docs.pega.com/bundle/platform-88/page/platform/deployment/patch-update-84-later-intro-1.html
Thank you.
LTIMindtree
SA
Hello Odis,
There are 2 approaches of Deployements.
1. In-House Deployment which needs Downtime of the Application
2. Out-of-the-House Deployment
Out-of-The-House Deployment:
1. Bring one DB Server UP by Synchronizing the existing DB (which will be go through for Upgrade process)
2. All the Rulesets will be locked before performing the Synchronization
3. Load Balancing URL's and Configurations will be updated to the new DB
4. Existing Applications connectivity to Old DB needs to undergo for upgrade activity will be cut off from Load Balancer URL's
5. Un-deploy the Application
6. Run the Upgrade Script (Major, Minor or Patch) over Old DB Schemas
7. Once Script Execution is completed, Switch back all the Application and Load balancing Configurations to the DB (OLD) which undergone with Pega Upgrade and Open the enviornment for End-User again
By Performing all the above steps, Pega Admin, Middleware Team is enforcing that Application Zero Down time for End User since they have brought up one parallel DB for end user. Let me know if you still have any further queries.
Note: Please mark the input as Accepted Solution, if your query is answered.
ASD
ID
Hi @KishoreSanagapalli,
Thanks for your response.
If we have 16 servers, is it possible to do patching on one server for all servers? or should to patching one by one server?
LTIMindtree
SA
Keeping the volume of servers, Out of the House upgrade process takes lot of time consumption. If we have the enough timeline for application downtime, Once all the necessary backup taken for both application side and DB side, We can perform the upgrade on the actual DB schema's directly.
CBA
AU
@Kishore Sanagapalli I can understand the out-of-place "RULES" upgrade without downtime, ie you clone the rules schema into a new rules schema, and update this new rules schema. This new rule schema will be the to-be rules schema after the upgrade which the app will point to. But when it comes to the data schema, I still cannot comprehend how the data with high DB operations in the only Data schema not risking of data being corrupted ie if we are doing data upgrade or in-place upgrade without bring the system down.
LTIMindtree
SA
Forget about In-place or out-of-place upgrade for sometime.
On-Prem:
1. Application Jar file / Pega Platform downloaded zip file will contain all the code about the application
2. all the Schemas like Rules, Data and Customer Schemas will go through the upgrade process anyway during the upgrade.
3. The logic is that in On-Prem Upgrades, From DB side, upgrade script will do necessary changes in rules / data / customer schemas etc....On Application layer, The Pega Platform jar file we use to download from Pega website which usually holds web components like prweb.war file, Pegawebear.war files etc.... which use to have application side changes.
Containerization:
as per 3rd point in On-Prem method, instead of .war files / .jar files, we will be working with Docker Images along with Helm charts for application side code changes / new features addition in the application. Rest all is the same.
Forget about In-place or out-of-place upgrade for sometime.
On-Prem:
1. Application Jar file / Pega Platform downloaded zip file will contain all the code about the application
2. all the Schemas like Rules, Data and Customer Schemas will go through the upgrade process anyway during the upgrade.
3. The logic is that in On-Prem Upgrades, From DB side, upgrade script will do necessary changes in rules / data / customer schemas etc....On Application layer, The Pega Platform jar file we use to download from Pega website which usually holds web components like prweb.war file, Pegawebear.war files etc.... which use to have application side changes.
Containerization:
as per 3rd point in On-Prem method, instead of .war files / .jar files, we will be working with Docker Images along with Helm charts for application side code changes / new features addition in the application. Rest all is the same.
One major difference is that between On-Prem and Containerization, The Application deployment sequence / structure is defined to follow as Centralized Deployment (i.e one by one node types will be put together (Startup Sequence is 1. Stream, Batch & Search, WebUser) in Hazel Cast Clustering Technique) but Containerization Deployment follows the De-Centralized deployment approach which has no dependancy (Only Search POD will come UP first) on the each components / services / nodetypes has dependancy on each other etc..
Note: Please mark the solution as accepted since all your queries are answered.
ASD
ID
Hi @KishoreSanagapalli @aciut,
Can you share script to create a new blank rules schema and a new temporary database schema in existing database on step in this link https://docs.pega.com/bundle/platform-88/page/platform/deployment/update-prepare-create-new-schemas-1.html?