a question about Liferay configuration..
I have found it:
If you want to expose multiple websites with different domain names from the same portal installation then you will have to create multiple portal instances.
Portal instance can be created from liferay control panel.
The data for all the instances resides on the same database. Every table in liferay has a column - companyId. For each portal instance there is a unique companyID. This id is ued to distinguish data for multiple websites. You can use sharding technique if we want to physically store data for different instances into different databases.
Is possible to create many Liferay instances with separate - data and users data (for login) shared in all liferay instances?
If I understand correctly you are saying you want to have some Users and some data which will be visible in all the Companies or Portal Instances, for eg:
There are 3 portal instances: C1, C2 & C3
Each instance has users: C1U1, C1U2, C2U1, C2U2, C2U3, C3U2 & so on. These users will be able to login to their respective instances only.
So now you want to create few users like U1, U2, U3 etc which can login to all the 3 liferay instances? That is they would be shared between all the 3 liferay instances or would be independent of the 3 instances?
In the same sense do you want to have Blogs, Wikis etc created that would be visible to users of all 3 liferay instances?
Solution
If the above is what you want, then as far as I know there is currently no feature to support sharing among Portal Instances. Sharing data among Sites we have Global scope, but we can't have shared users or data among Portal Instances.
All the instances are separated by companyId, this companyId is present in all the database tables of Liferay to separate the data among portal instances.
As per the documentation for Portal Instances:
Data for each portal instance are kept separate from every other portal instance. All portal data, however, is kept in the same database.
So the very philosophy is to have the data separate it seems.
Related
Currently I am facing a technological decision to be made and personally am not able to find the solution myself.
I am currently in progress to develop a multiple-tenant database.
The structure would be the following:
There is one core database which saves data and relations about specific tenants
There are multiple tenant database instances(from a query in the core database, it is determined which tenant id I should be connecting to)
Each tenant is on a separate database instance(on a separate server)
Each tenant has specific data which should not be accessible by none of other tenants
Each database would preferably be in mySQL(but if there are better options, I am open to suggestions)
Backend is written in koa framework
The database models are different in the core database and tenant databases
Each tenant database's largest table could be around 1 mil records(without auditing)
Optimistically the amount of tenants could grow up to 50
Additional data about the project:
All of project's data is available for the owner
Each client will have data available for their own tenant
Each tenant will have their own website
Database structure remains the same for each tenant
Project is mainly a logistics service, which's data is segregated for each different region
The question:
Is this the correct approach to design a multi-tenant architecture or should there be a redesign in the architecture?
If multi-tenant with multiple servers are possible - is there a preferable tool/technology stack that should be done? (Would love to know more specifically about this)
It would be preferred to use an ORM. I am currently trying to use Sequelize but i am facing problems already at early stage(Multiple databases can't share the same models, management of multiple connections).
The ideal goal would be the possibility of adding additional tenants without much additional configuration.
EDIT:
- The databases would be currently hosted in Azure, but we'd prefer the option that they can be migrated away if it becomes a requirement
Exists some ways to architect a data structure in a multi tenant architecture.
It's so hard to say what is the better choice, but I will try to help you with my little knowledge.
First Options:
Segregate your database in distributed servers, for example each tenancy has your own data base server totally isolated.
It could be good because we have a lot of security with tenancy data, we can ensure that other tenancy never see the other tenancy data.
I see some problems in this case, thinking about cost we can increase a lot it because we need a machine to each client and perhaps software license, depends what is your environment. Thinking about devops, we will need a complex strategy to create and deploy a new instance for every new tenancy.
Second Options
Separate Data Bases, we have one server where we create separated databases to each tenancy.
This is often used if you need to provide isolation for each customer, because we can associate different logins, permissions and so on to each database.
Some other cons: A different connection pool is required per database, updates must be replicated across all the databases, there is no resource sharing (unless using Elastic Database Pools) and you need multiple backup strategies across all the databases, and a complex devops strategy to deploy and create new tenancies.
Third Option:
Separate Schemas, It's a good strategy to implement a multi-tenancy architecture, we can share some resources since everything is inside the same database, but the schemas used are different, having a separate schema for each tenant. That allows you to even customize a specific tenant without affecting others. And you save costs by only paying for one database.
Some of the cons: You need to replicate all the database objects in every schema, so the number of objects can increase indefinitely, updates must be replicated across all the schemas, the connection pool for the database must maintain a different connection per tenant (or set of credentials), a different user is required per tenant (which is stored at server level) and you have to backup that user independently.
Fourth Option
Row Isolation.
Everything is shared in this options, server, database and schema, All data for the tenants are in the same tables in the same database. The only way they are differentiated is based on a TenantId or some other column that exists on the table level.
Other good point is that you will not need a devops complex strategy, and if you are using SQL Server, I know that, there exists a resource called Row Level Security to you get only the data that logged user has permission.
But in this case if you have thousands of users who will be hitting the database at the same time you will need some approach for a good scalability.
So you need to think about your case and how your system will be growing up, to choose the better option.
It seems quite fine for me.
Where I see a bottleneck is having every tenant on a separate DB server or DB instance. It would mean that you need to hold a separate connection pool for every tenant or to create a new connection for every request depending on the tenant. Try using any concept where you can have one DB connection for all the tenants (namespaces, schemas or just prefixing tenant table names with some tenant-specific prefix)
But if you need to have the tenants DBs separate eg. because of different backup policies, resource limits etc. you can't do this and will have to manage separate connection pool for every tenant. It also depends on how many tenants will you have. Tens, thousands?
I would also suggest you to cache the tenant->DB mapping somewhere in the app instead of querying it every time from the core database.
I have 2 web roles. Each maintains a Concurrent Dictionary which it updates. Is there a way to make sure that changes made by one is visible to others.
Or in other words, for N number of web role instances there should be only 1 copy of data (Collection or Object not DB Table).
Each instance of a web role is a separate VM. So... whatever technique you'd use between two computers would be viable with two VMs.
You mentioned no databases, so that rules out quite a bit. You simply cannot share collections or objects because, again, you're talking about synchronization across two completely separate VMs.
Note that Cloud Services have a Cache Role as well, which you can consider for sharing content between your instances (and this is certainly not the ultimate answer; I'm simply pointing out what Cloud Services provide out-of-the-box).
I have in development a multi tenant application that I am deploying to azure.
I would like to take advantage of the windows azure cache service as it looks like it will be a great performance improvement vs hitting the database for each call.
Lets say I have 2 tables . Businesses and Customers. A business can have multiple customers and the business table contains details about the business.
Business details don't change often but customer information is changing constantly for each of the different tenants.
I assume I need 2 named instances (1 for business details and 1 for customers)
Is 2 named caches enough or do I need separate these for each of the tenants? I think 2 would be ok as if I have to create separate for each it will get expensive pretty quickly.
Thank you.
Using different named caches is interesting if you have different cache requirements (Expiry policy, default TTL, Notifications, High Availability, ...).
In you case you could simply look at using different Regions per tenant:
Windows Azure Cache supports the creation and use of user-defined regions. A region is a subgroup for cached items. Regions also support the annotation of cached items with additional descriptive strings called tags. Regions support the ability to perform search operations on any tagged items in that region.
This would allow you to split your named cache (you would only need one), in regions per tenant holding the businesses and customers for that tenant. And if the businesses don't change that often, you can simple change the TTL for those items to 1, 2, .. hours.
1) I need help in setting up the liferay portal instance with multiple domains.
I have one portal instance with multiple organizations ( for example: abc org, xyz org, etc)
I want to map these organizations to different domains (for example: abc.com, xyz.com, etc)
I know that multiple portal instances with different company name (different companyId's) can be mapped through admin login in liferay,
BUT
need help with the above mentioned setup: one instance-multiple org-mapped to multiple domains
2) If I use multiple instances, will this make performance issue in liferay?
Considering if we go with 1000 organizations with their respective domains mapped.
1st question, checkout Virtual Hosting on Liferay's web site.
2nd question, from my points of view, running 1000 micro websites on a single portal instances will definitely hit performance.
We created a custom Liferay application that enables a company to sell products to customers. These customers also have access to whatever they bought via Liferay. A customer can have multiple users that access the portal through this customer account. So we tried adding an organization in Liferay for each customer, but this soon proved to be a very big performance hit. Liferay is able to handle 10's and maybe 100's of organizations, but 1000's and 10000's is too much. So I guess you'll possibly need multiple Liferay servers to handle 1000 mini-sites.
We are trying to create a SaS based portal using Liferay 6 for multiple (non related) organizations. And we want to go for a approach where we can generate these organization setup automatically based on user information.
We may require to have separate domains/websites for each organization.
As of now I have thought about two options for this
Portal Instance
Organizations
As per my understanding, i think this can be achieved by both of the above approaches. I would like to know your experience on both of these approaches on following points.
Which one would be easy to administer in long run
Which one can be easily programmed to create new setup automatically.
What about data security related to keeping in one portal instance vs multiple instance (is there any such thing?? not sure)
Any other approach to this?
Simple answer would be Portal Instances, since it was built for multi-tenancy.
Benefits to this approach would be that there would be segregation of data. Each instance maintains its own collection of users, communities, blog entries, etc.
Administration wise, there will be 1 account, the omni-admin, that can access all of these instances. On top that, each instance could have its own administrator that admins that particular instance.
Also, I don't believe using organizations will allow you to have separate domains for them.
Also going forward in Liferay 6.1, Organizations don't have pages only Sites have them, though we can mimic the behaviour with Sites.
Hope this helps.
I'm using Organizations for multiple sites, none of them sees each other, each one have their own users, roles, sections and communities.
Apache and Liferay virtual hosts url's makes the proper redirects to each organization home page.
For the admin I think is easier because in one control panel you can manage everything, or just the "scope" you want.
About using Instances, check the procedure to configurate them and see if you find it possible to create new ones automatically. Not very sure about that for organizations either, but having to touch portal-ext.properties may be worse towards automatization.
Regards