Thanks a lot for your answers. I'm agree: without any application's specifications, it's difficult to define an architecture. To answer to your questions:
1) No reason. We've just started te developpment, only 20% have been done.
2) right now, I know that 3 agents have been created for the application.
The problem is that I don't really have informations on the application (we've asked but still waiting for). What I know, it's that they will have other applications (totally different) using the same Pega Platform.
What I want to know is how do I size the JVM memory at the beginning ? And is it better to have one big instance with 8 GB or two instances with 4 GB each?
But the better answer is to do stress test with differents configurations to see which one is the best way when the application will be installing...
Application server memory requirements The Pega 7 Platform runs in memory (heap) on Java Virtual Machines (JVMs). In general, all activity is distributed over multiple JVMs (nodes) on the application server. l Standard suggested system heap size is 4 - 8 GB based on monitoring of memory usage and garbage collection frequency. l Larger heaps are advisable if your applications allow a high number of concurrent open tasks per session or cache a large collection of transaction or reference data. l Do not deploy the Pega 7 Platform in an environment where the heap size exceeds the vendorspecific effectiveness limit. In current 64-bit JVMs, compression is enabled by default. The host application server memory size must be at least 4 GB larger than the Pega 7 Platform heap size to allow space for the operating system, monitoring tools, operating system network file buffering, and JVM memory size (-XMX option). The minimum host application server memory size is 8 GB: 4 GB heap + 4 GB for native memory, operating system, and buffering If the server does not have enough memory allocated to run the Pega 7 Platform, the system can hang without an error message. The correct memory settings depend on your server hardware, the number of other applications, and the number of users on the server, and might be larger than these recommendations.
Just another question on high availability: can we configured two datasources on Pega instances, the first one for access to primary database instance, and the second one, when the first one crashed, for secondary database instance ?
Thanks but I've found it! PostgreSQL driver can do it:
To support simple connection fail-over it is possible to define multiple endpoints (host and port pairs) in the connection url separated by commas. The driver will try to once connect to each of them in order until the connection succeeds. If none succeed, a normal connection exception is thrown.
The simple connection fail-over is useful when running against a high availability postgres installation that has identical data on each node. For example streaming replication postgres or postgres-xc cluster.
For example an application can create two connection pools. One data source is for writes, another for reads. The write pool limits connections only to master node:
jdbc:postgresql://node1,node2,node3/accounting?targetServerType=master . And read pool balances connections between slaves nodes, but allows connections also to master if no slaves are available: