...
Grouper requires an SQL database to store group and subject data. The quick start comes with an HSQL database which is fully functional, but not considered production quality as it lacks essential functionality in areas such as maintenance and backup. If possible, you should use one of the following supported databases as they are tested with Grouper:
- MySql
- Postgres (preferred)
- OracleMicrosoft SQL server
- MySql (has performance issues)
Other databases supported by Hibernate may work, but it is likely that you will need to edit the SQL generated for creation of the schema. A list of databases supported by hibernate can be found at http://community.jboss.org/wiki/SupportedDatabases.cannot be used
Each database is equal as far as Grouper is concerned, with no functionality tied to, or excluded from, any specific database. You choice will be based on factors such as:
- Which database you are most experienced in/familiar with?
- Does your institution have a preference?
- Do you have existing maintenance/backup procedures in place for any of the databases?
- Do you require high availability? Different databases have different ways of achieving this
- If you are installing a database from scratch, and have no existing preference, then do you prefer open source (MySQL and Postgres) or commercial (Oracle and SQL Server)?
Grouper does not require a dedicated database server. It is quite happy to coexist on a server with other databases, however, you will need to consider capacity requirements of all the databases. Should this be your approach you will need to build in testing and monitoring specifically for this.
...
Host to run the Grouper Daemon
From Grouper 1.5, a typical Grouper installation includes a process which runs in the background all the time. In *nix terminology this is called a daemon; in Windows terminology it's called a serviceGrouper requires a daemon container. The code that runs (regardless of how it is started), is written in Java and requires a Java virtual machine in which to run. You will therefore need a server-type machine which will always be on (this could be a virtual machine), with Java installed on it. The load placed on the machine by Grouper will depend on the number of groups and memberships you have, the frequency with which they change and how often they are queried. This should also form a key part of your testing. As a rule-of-thumb, the daemon/API requires fewer resources than the database. You can have multiple daemons and they scale linearly (the database needs to support it though).
Application server
If Grouper requires you intend to run the User Interface (UI), then you will need an application server in which to run it. Development and testing is done using Apache Tomcat, so it is recommended that this should be your default choice in the absence of other factors. Factors which may cause you to use an alternative include:
- Organisational policy - are you standardised on a certain server?
- Familiarity with or preference for a server
- Support considerations
If you do choose to use and alternative application server, it must support the Java Servlet APIUI container. This should be separate from the daemon container and WS container. The WS container is optional though most institutions run the WS container. The UI and WS can have multiple and they scale linearly. You need a sticky load balancer for the UI and any load balancer (round robin is recommended) for the WS.
Data sources
Grouper stores data about groups in its database (called the registry). It also stores references to subjects which have privileges within groups (such as membership). In the quick start the subjects which represent people are also stored in the registry, but this is only for demonstration purposes. Grouper is designed to reference subjects in external data sources. Normally this will be an existing data source storing data about your users. The data stored will include a unique, unchanging identifier and fields that can be searched when looking for a user. Grouper supports any data source which can be queried using JDBC on JNDI. These include networked databases which listen on a port, directories which support Lightweight Directory Access Protocol (LDAP), NIS and DNS servers. Once commonly used database which is not properly query-able is Microsoft Access. This is not a networked database as a file must be opened in order to access the database, rather than a connection made to a service listening on a port.
...