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:

• The Hardware (Intel, X86, Spark, IBM z architecture etc. )
• the OS (Solaris, Red Hat Linux, z/OS, Windows)
• the database (Oracle, DB2, SQL-Server, Postgresql)
• the Pega PRPC application
• Other software (JBoss, Tomcat, WebSpehere)

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.

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 :)