This repository contains setup scripts and resources for manual and automatic Intrexx Cluster deployments (Steady/Silent Release beginning with 11.0). Please check out the v21.03 or v21.09 branches for older releases.
Warning: The following guides and examples should not be used as is for production deployments. Security and reliability of your cluster is out of scope of this documentation. Use this only for test and demonstration environments.
A clustered Intrexx installation does not differ very much from a standalone Intrexx setup. Actually, you can install Intrexx as usual on one machine (VM, physical machines) and enable cluster mode afterwards by activating cluster configuration and sharing or mounting the portal folder on the other machines. While this is possible but cumbersome, the preferred way of setting up an Intrexx cluster is to prepare the required infrastructure (on premise, datacenter or cloud) and then use the setup scripts provided in this repository to install the Intrexx instances and required dependencies automatically.
As Intrexx uses internally a thin data grid layer to enable communication and data structure sharing between cluster instances, it is very flexible in the way a cluster can be designed, deployed and operated. There are only a few requirements and things you have to consider when migrating from Intrexx standalone to Intrexx distributed. In particular, these points are
- One portal per Intrexx cluster: An Intrexx cluster can only operate one portal. It is not possible to create multiple portals as it is with a Intrexx standalone server.
- Database: You can use a database as a service offer from your cloud provider or setup one of the supported databases on a dedicated machine in your cluster.
- Shared portal folder: A distributed network file system is required in order to share the portal folder between the portal servers. Currently Intrexx works with AWS EFS, NFS, SMB, GlusterFS and Ceph.
- Workflows: You can decide whether timer jobs and workflows will run on a randomly chosen portal server instance in your cluster or on dedicated job scheduler instances. The latter option is recommended if you have many long running jobs or workflows.
- Search engine: A Solr Cloud instance or cluster is required for the whole cluster.
Please keep in mind that the database, shared filesystem, workflow and search services are all single point of failures and could potentially bring your whole cluster down if one of the services crashes. So it is important for production environments to replicate those external services as well. This can be achieved by using cloud provider services (e.g. database as a service, distributed filesystems, etc.) or by using common software components and techniques (e.g. Postgresql/MS SQL Server replication, GlusterFs/Ceph as distributed filesystem instead of NFS, Solr cluster...) to replicate the services on your own.
An Intrexx cluster usually consists of several nodes (virtual machines, Kubernetes pods, physical box):
- At least 3 application server instances for the portal server processes (testing with 2 instances is possible, too).
- One fileserver instance for sharing the portal folder to the application server instances.
- One database server instance (or a cloud provider database as a service) for the portal database.
- Optional: One instance for the workflow engine, otherwise timer processes are triggered on one of the app server nodes.
- Optional: One instance for the Solr Cloud search engine, can otherwise also be installed on the services nodes.
- A Linux provisioning instance to execute the Ansible deployment scripts or to manage the Kubernetes cluster.
Configure your virtual private cloud security group to allow internal traffic on all ports. In order to communicate with the other cluster nodes, Intrexx needs open ports for the internal network depending of the used operating system:
- 1337/8443 (tcp): Tomcat
- 8983 (tcp): Solr
- 47500-47600 (tcp): Internal cluster communication
- 5432 (tcp): Postgresql
- 1433 (tcp): MS SQLServer
- 111 and 2049 (tcp/udp): Linux NFS server
- 445 (tcp): Windows SMB server
- 49152 - 65535 (tcp): Intrexx might need to contact DC LDAP, LDAP GC, Kerberos
CLI scripts and documentation for provisioning of the required infrastructure on Microsoft Azure, Amazon Web Services and Vagrant.
Contains the default CLI install scripts for Azure/AWS on Linux and Windows. Can be used for both providers and OSes and will support further cloud providers in the future. At the moment, it requires to start the Ansible provisioning scripts manually on the provisioning instance.
Consider these scripts as a template for creating your own automatically scaling Intrexx cluster setup.
Documentation and Vagrant configuration for setting up a 2-3 node Intrexx cluster on a local machine (notebook/workstation). VirtualBox and Vagrant must be available on this machine.
Ansible playbooks and resources for installing Intrexx on a Linux cluster. Requires already provided infrastructure (see docs in cloud-provider).
Ansible playbooks and resources for installing Intrexx on a Windows cluster. Requires already provided infrastructure (see docs in cloud-provider). While it is possible to run an Intrexx cluster on Windows, it is not supported and recommended by Intrexx.
Scripts and resources for installing Intrexx on a Kubernetes cluster. Requires already provided Kubernetes infrastructure.
Setup a full stack Intrexx Cloud deployment on AWS or Microsoft Azure with Linux or Windows VM instances.
- Script installer: cloud-provider/installer/docs/README.md
- Collect log files with Logstash/Filebeat: cloud-provider/azure/docs/Logstash.md
Create a Kubernetes cluster on Azure AKS, AWS EKS or on-premise and deploy Intrexx containers.
Build an Intrexx cluster on your local machine. Each node is deployed on a Ubuntu 16.04 server (headless) VirtualBox VM managed by Vagrant. After VM provisioning, Intrexx must be installed with the Ansible playbooks found under /linux or /windows.