Discussion
Managing High Available Applications
Hi Team
In this course we learnt "Pega qualifies a server as High Availability if it is available for 99.99% of the time. This means that the system should be down for a maximum of 53 minutes over a year. What does the 53 minutes include? This includes any unplanned outages due to a system crash and all planned outages for upgrading the system."
The shared storage in the below image store the rules and data for different vm's/physical machines? or it is the database. If database, lets take an example we have a Hotfix from Pega support where we need might need to bring DB down (specifically).
Do we really need to bring the DB down (incase suggested in a hotfix)/ or do we need to switch to a failover DB?
In this scenario my application will go down for sometime, if this happens sometimes in a year, the system will not be highly availble enterprise application. Please correct me if my understanding is not correct.
Hi Bernving
Thank you for response.
Qq: What does Shared storage in the image refer to, a DB/Filesystem. Could you please elaborate.
Thank you
Sam
Shared storage could be a database or a NFS (Network File System) on unix or a shared network drive on windows. For a file system share you might want to store some files common to all nodes in a cluster in one place. Think about configuration files, executable files and other that must be the same for each instance of the running application. Pros are all files are shared and you only need to update on one place. Cons are you might need to bring down ALL nodes before you can do an update of certain files. If there are configuration files and you have them in a database or on a shared file system you might just tell one node at the time to go initialize itself. When it comes to a database all Pega Work Items and all Pega rules can be stored in different databases. This is also a shared storage but here each instance might need to coordinate access. I.e. one user on one node have opened a work item the system needs to lock the workitem so no one else can open it otherwise one user can destroy updates of another user, but all nodes can read the rule tables without problem. Same is also true for a file system share. Windows handle this from the OS level, in Linux you have to implament file locking yourself to coordinate updates to shared files (see http://en.wikipedia.org/wiki/File_locking)
Conceptual there is no difference between a database or a shared file system, but implementation and usage have big differences.
To elaborate a bit more. In earlier version of Pega we had a lot of configuration located in files. The drawback of that is that you mostly need to restart the software after changes. more and more of our configuration is now moved to the database making it more dynamic to change. Hence less need for shared configuration files. The picture can mean both Database and Shared (NFS) file systems.
That helps!! Yeah we have moved to Vtable's starting v7. Thank you :)
Hi,
As you hinted the shared storage can be a database or shared file storage. Indeed when planning for high availability we need to take many components into account. As an example we could think about:
All of these components have a failure rate where some are wel known (i.e. hardware) and have taken measurements to minimize downtime (hot swappable hard ware components, clusters, distributed databases etc.) At Pega we can only take responcibility for our own components. This means even if Pega have created components where we can upgrade one node at a time and have users seamless diverted to other systems to minimize downtime the whole systems high availability is dependent on all components. If the shared storage is made in a way it has to be brought down for a hotfix, yes your system might not be available 99.99% of the year.
A Pega hotfix involving such canges to your database or file system that you need to restart it is very rare, but if, you are correct.