We are looking into Liferay with multiple tenancy for business reasons for disparate audiences. I have some questions around this. I'd appreciate some insight on the following questions:
From the question/post liferay and more instances, it seems like there are constraints around Portal properties where some are global versus instance specific. Is there any list or insight on what properties are global Liferay scoped versus instance specific?
From the post on Liferay portal instances, it seems like > The preferred way to configure a portal instance is through the Control Panel.
From talking to various people, it also seems like sharding with portal instances has some performance known issues. It is recommended to turn off sharding when using instances. Does anyone know which Liferay properties to use to turn the sharding off or if sharding is off in Liferay 6.2 by default (if so, which properties to review to confirm that sharding is off)?
Is there a limit on how many instances we can use? We may be using atleast 3-4 instances to start with. Any know known issues with number of instances?
Thanks a lot for any information on this.
Here is what I found from another source in case it helps someone:
One of the first and most important things to remember about portal properties is that they are always overridden by any settings made in the Liferay Control Panel. The reason why is that any configuration done in the Control Panel is saved directly to the database and the configuration set in the database is always read after the portal properties have been imported, thus overriding them. Once a configuration has been done in the Control Panel, that setting can never again be modified or altered by a portal property.
This does make one wonder why there are two places to make setting configuration changes and why the Control Panel trumps the portal properties file every time. The reason why this is done is directly related to your first question regarding global and scoped settings.
The portal-ext.properties file is often used to set configuration for that physical bundle of Liferay; every instance of Liferay on that physical bundle will inherit those settings, but those settings will not be automatically inherited by any other Liferay node or bundle of the same instance.
The Control Panel is often used to set configuration for that instance of the Liferay Portal; every node connecting to that instance will inherit these settings and override any values set in the portal properties, but those settings will only be inherited by other nodes connecting to the same instance.
In other words... - The Control Panel settings are used for the Liferay instance. - The portal properties settings are used for the Liferay bundle - The Control Panel settings will always override the portal properties settings
This does allow some control on how to set default properties for the bundle or node, as well as to save configuration for the entire instance. As an example, you will want to use the portal properties to configure cluster settings, the database connection settings, document library connections, as well as other performance/system settings.
However, you will also be given a choice of where to configure settings such as the mail server. If you set it in the portal properties, every instance of Liferay on that node will have those settings automatically, which may not be desirable depending your goals. If you set it in the Control Panel, then ever Liferay node connecting to that instance will get those settings automatically, but the portal properties will not modify those settings again.
Now, there is a way to create an instance specific portal properties file that will have values only read by that instance of Liferay. Please note that this does complicate things even further and it may not be desirable for your goals. The following property and its definition explain how to accomplish this:
#
# Each portal instance can have its own overriden property file following
# the convention portal-companyWebId.properties. To enable this feature, set
# the "company-id-properties" system property to true.
#
# To enable:
#
# java ... -Dcompany-id-properties=true
#
# The read order will now be: portal.properties, then portal-ext.properties,
# and then portal-liferay.com.properties.
#
# Note that not all properties can have different values per company. This
# functionality is only available for legacy reasons. The preferred way to
# configure a portal instance is through the Control Panel.
#
include-and-override=portal-${easyconf:companyId}.properties
include-and-override=${liferay.home}/portal-${easyconf:companyId}.properties
The choice is yours on where you want to configure your portal settings and with the above knowledge I believe you will be able to make the best decision for your goals.
In regards to sharding, sharding is disabled by default and has to be manually configured via portal properties as well as via the database itself. This is a slightly older wiki article on how to enable database sharding support in Liferay, https://www.liferay.com/community/wiki/-/wiki/Main/Database+Sharding. For reference, here are some of the properties that need to altered: ## ## Sharded Databases ##
#
# Set the database that is to be used for the default company and globally
# used tables in a sharded environment.
#
shard.default.name=default
#
# Specify an algorithm for selecting a new shard on portal instance
# creation. Use ManualShardSelector for shard selection via the web
# interface.
#
shard.selector=com.liferay.portal.dao.shard.RoundRobinShardSelector
#shard.selector=com.liferay.portal.dao.shard.ManualShardSelector
##
## Spring
##
#
# Input a list of comma delimited Spring configurations. These will be
# loaded after the bean definitions specified in the contextConfigLocation
# parameter in web.xml.
#
# Note that there is a special case for hibernate-spring.xml and
# jpa-spring.xml. Even though both files are specified, only one will
# actually load at runtime based on the property "persistence.provider".
#
spring.configs=\
META-INF/base-spring.xml,\
\
META-INF/hibernate-spring.xml,\
META-INF/infrastructure-spring.xml,\
META-INF/management-spring.xml,\
\
META-INF/util-spring.xml,\
\
META-INF/jpa-spring.xml,\
\
META-INF/executor-spring.xml,\
\
META-INF/audit-spring.xml,\
META-INF/cluster-spring.xml,\
META-INF/editor-spring.xml,\
META-INF/jcr-spring.xml,\
META-INF/ldap-spring.xml,\
META-INF/messaging-core-spring.xml,\
META-INF/messaging-misc-spring.xml,\
META-INF/mobile-device-spring.xml,\
META-INF/notifications-spring.xml,\
META-INF/poller-spring.xml,\
META-INF/rules-spring.xml,\
META-INF/scheduler-spring.xml,\
META-INF/search-spring.xml,\
META-INF/workflow-spring.xml,\
\
META-INF/counter-spring.xml,\
META-INF/mail-spring.xml,\
META-INF/portal-spring.xml,\
META-INF/portlet-container-spring.xml,\
META-INF/staging-spring.xml,\
META-INF/virtual-layouts-spring.xml,\
\
META-INF/monitoring-spring.xml,\
\
#META-INF/dynamic-data-source-spring.xml,\
#META-INF/shard-data-source-spring.xml,\
#META-INF/memcached-spring.xml,\
\
classpath*:META-INF/ext-spring.xml
You can read more about how to implemenent sharding in the User Guide here, https://www.liferay.com/documentation/liferay-portal/6.2/user-guide/-/ai/liferay-clustering-liferay-portal-6-2-user-guide-20-en, if you are curious.
In regards to the number of instances allowed, there are no hard limits but please note that each instance will be competing for the same amount of resources and performance degradation will likely occur. This does make performance tuning even more important than normal to avoid undesirable performance.
As an FYI - from testing I found that the following properties to configure the Announcement portlet template etc. is only possible via the portal-ext.properties file and not via the control panel. So if the values of the properties are different between instances than you will need a company specific properties file.
Hope this helps!