Installers can elect how this instance of Pyramid will be installed - either to a single server or across two or more servers.
- Single Server - quick and simple; perfect for personal or small deployments, testing and POC's.
- Multi Server - more advanced for more complex, larger multi-user deployments where performance, load balancing and fail over are considerations
This is the quickest and simplest option where all components of Pyramid are installed onto a single machine (including virtual). This usually includes:
- Internal Web server
- Router service
- Run Time Engine
- Task Engine
- Augmented Analytics Server
- Windows Connector Service (Windows only)
- Data Repository
- In-memory database
Everything is installed to run without any other considerations and acts as a self-contained unit.
This approach allows users to hand pick which tiers in the solution are installed on any given machine. Ultimately, this provides for a more sophisticated roll-out, where different servers with different hardware profiles can be used for the different application servers and services as appropriate.
To enable a multi-server deployment, users simply choose the "multi-server" option during the installation process. This will both indicate to the host machine that the servers and services will be installed on a custom basis and allow the user to pick from a list of components to install.
The different tiers can be deployed on separate machines, or in any combination on several machines as needed. Importantly, each server needs to be installed on at least one machine in the cluster to enable the platform.
Prior to a multi-server installation make sure your servers can communicate with each other.
If you have firewalls setup, either temporarily turn them off, or open specific ports to enable the Pyramid services to communicate with each other.
These are the default Ports the product uses for each service - if any of them is already in use, the installation will try to look for an available one instead:
- 8181 - Web server
- 12100 - Run Time Engine
- 12110 - Task engine
- 12120 – Router
- 12130 – PostgreSQL
- 12140 – Windows Connector ("DNC")
- 12150 - File Server
- 12170 - In-memory Database ("IMDB")
- 12200 - Augmented Analytics server ("AI")
12190 – Agent
You will need to enter a password for IMDB, and for PostgreSQL if using the built-in PostgreSQL option. The default password for both IMDB and PostgreSQL is "pyramid."
There are 2 entry points for subsequently adding or removing services in a multi-server deployment:
- Services can be added by rerunning the installer - which will trigger the upgrade engine and offer the user an opportunity to add new services to an existing host.
- Services can be removed by running the uninstaller - which will allow users to either uninstall the entire product on a host or select specific services to remove.
More details on these steps can be found here.
Server name: the name of the sever on which the In Memory server was installed.
Built-In PostgreSQL Database
Users can select the built-in PostgreSQL database when installing Pyramid as a multi server deployment. Both the username and password to connect to the PostgreSQL database is "pyramid", which must be entered when adding the second (and successive) server(s) to your deployment.
Note regarding Pulse: for the Pulse client to work, it needs to be able to connect to your Pyramid website. If your internet is restricted, please allow access to your Pyramid website.
All tiers in the platform "stack" can be installed multiple times across multiple servers to provide horizontal load balancing and fail over. In almost all cases, the servers will act in active-active mode, with the platform self-balancing requests as needed, with only these exceptions:
- Web Servers - these are not load balanced by the application. Multi web servers need to be load balanced by an external load balancing technology.
Note that the Pyramid platform is designed to eliminate the need for 'sticky' sessions or persistence in the web load balancing strategy
- Router Services - these servers act in active-passive mode, where only a single router is actively managing all the tiers in the cluster at any given time. Secondary routers will assume control if the primary router becomes inoperable.
When installing the services on different machines, they must all use a common database repository. Without this, the services will not be able to join the cluster and act as a single platform. See here for more.