The requirements for deploying WSO2 products can change based on the deployment scenario and pattern used. The recommendations in this topic are for general production use, assuming moderate load conditions. For situations where a high volume of traffic is expected and larger deployments, these guidelines may not be sufficient. See Troubleshooting in Production Environments for information on how to obtain and analyze information to solve production issues. The following are the topics addressed in this section.
...
Info |
---|
Note: When using SUSE Linux, it ignores |
...
Guideline | Details | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Default credentials | Once you have installed the product, it is a good practice to change the default passwords. All WSO2 products have an administrator account set to “admin” as username and password. You can change it in the user management section of the Management Console.
| |||||||||||||||
Secure Sockets Layer (SSL) keys | WSO2 products by default come with a self-signed SSL key. Since these keys are public, it is recommended to configure your own keys for security purposes.
| |||||||||||||||
JVM version | The recommended version is JDK 1.6.24 or later/1.7.*. Set the appropriate Heap and Permgen values for JVM based on your deployment scenario. These can be set in the
| |||||||||||||||
Host name | By default, WSO2 products identify the host name of the current machine through the Java API. However, this value sometimes yields erroneous results on some environments. Therefore, users are recommended to configure the host name by setting the
To configure host names for WSDLs and endpoints, users are recommended to add the following parameter in the <transportReceiver> section in the
| |||||||||||||||
Managing logs | It is recommended to configure logging using the management console.
| |||||||||||||||
Registry and governance | All WSO2 products make use of an instance of a registry to store configurations. The registry uses a database as the persistent storage. By default, the registry uses an embedded H2 database. This embedded database might yield a lower performance and is less reliable compared to a standard database like MySQL when there are large number of deployed artifacts. Hence you should look at associated trade-offs, and we recommend that you switch to a database like Oracle, MySQL or MSSQL. Moreover, it is worth noting that
As the default setup does not include database backup procedures. The , the production setup should obviously need to have regular database backup procedures configured. When the registry database is pointed to a remote database, multiple running instance of the same product can boot up and run against the same configuration stored in the registry. This, in turn, helps with governance.
| |||||||||||||||
User stores | WSO2 products offer three choices to store user details:
The default is to use the embedded H2 database, with the user store schema. Like in the case of the registry database, you can switch to a database like Oracle, MySQL or MSSQL. You can point to an existing LDAP or an Active Directory to make use of existing user bases and grant access privileges for WSO2 products based on those user stores.
| |||||||||||||||
Monitoring with JMX | WSO2 Products support JMX for monitoring. By default, JMX uses port 9999. You can configure this to a desired port by setting the JMX port parameter in the
| |||||||||||||||
Tuning WSO2 products | There are performance tuning guidelines for all products. Check these in their respective product documentation. | |||||||||||||||
Securing plain-text passwords | WSO2 products use a tool called “Secure Vault” to secure the plain-text passwords in configuration files. With this tool, you can encrypt the passwords.
| |||||||||||||||
Firewalls | The following ports must be accessed when operating within a firewall.
| |||||||||||||||
Proxy servers | If the product is hosted behind a proxy such as Apache HTTPD, users can configure products to use the proxy server by providing the following system properties at the start-up.
Alternatively, this can be done by adding the following configurations in the
| |||||||||||||||
High availability | For high availability, WSO2 products must run on a cluster. This enables the WSO2 products to still work in the case of failover. Databases used for the repository, user management and business activity monitoring can also be configured in a cluster or can use replication management provided by the RDBMS.
| |||||||||||||||
Data backup and archiving | For data backup and for archiving of data, use the functionality provided by the RDBMS. | |||||||||||||||
Feature management | Compatible features can be installed on any WSO2 product using the WSO2 Carbon Feature Manager that comes with the product. The feature manager is powered by Equinox P2 and allows you to connect to a remote or local P2 repository and get any compatible WSO2 feature installed into the product's runtime.
| |||||||||||||||
Spooling and log rotation | Ensure that you have a relevant log rotation scheme to manage logs. Log4J properties for WSO2 products can be configured in the To roll the wso2carbon.log based on size, the following configurations can be used.
|