[opencms-dev] Can different installations of OpenCms connect to the same db schema?
Edwin Chiu
edwin.chiu at gmail.com
Fri Jan 29 05:55:23 CET 2010
Hi All,
I think most of you would agree that OCEE is worth to pay for the multiple
OpenCms scenario. But it meant that you also have to pay for more money on
DB cluster.
Most of the client using OpenCms is for "Free of Charge" and minimizing the
cost on frontend. So OCEE is meaningless for them.
In my past project, client wants to have load balancing on the website. So,
we had 2 MySQL for serving 2 OpenCms instance in 2 machine. Let see my setup
below.
1. One OpenCms and One MySQL is both on the one machine.
2. We defined the 2 machines as Master machine and Slave machine.
3. Let say OpenCms and MySQL in Master machine be m_OpenCms and m_MySQL. In
Slave machine, that is s_OpenCms and s_MySQL.
4. We set up an one-way replication (it's free!!!) between m_MySQL and
s_MySQL. The replication direction is "m_MySQL -> s_MySQL".
5. m_OpenCms is for authoring and displaying content. s_OpenCms is only for
displaying content. s_OpenCms is not allowed to login into workplace.
6. In MySQL, we created a timetable for store the time of publishing job. If
user publish contents in m_OpenCms, m_OpenCms will update the table, record
down the time of publishing job. Then m_MySQL will replicate this
information to s_MySQL.
Due to the above setup, we have the below treatments regarding to OpenCms
features.
1. Flexcache: We setup a schedule task in s_OpenCms to read the publishing
job timetable. So if m_OpenCms published content, s_OpenCms will know some
content is updated and clear the Flexcache.
2. Search Index: We setup a schedule task and run "Rebuild Index" in
specific time. Assuming that date and time is in sync in Master and Slave
machine.
3. Static Export: At the very beginning, we want it done as Flexcache.
Following code is for purge the static export folder. But we find that
sometimes (or very rarely) it cannot export the files again. So we DISABLE
the static export finally.
CmsStaticExportManager manager = OpenCms.getStaticExportManager();
CmsEvent event = new CmsEvent(I_CmsEventListener.EVENT_UPDATE_EXPORTS,
null);
manager.cmsEvent(event);
My experience maybe not directly related to the topic. But I want to share
it to you all and elaborate the feasibility of getting out OCEE. Of Course,
if clients have lots of money, I will urge her to use OCEE for eliminate the
inconsistence.
Thanks
Edwin
Jordi Martí wrote:
>
> I have never used that scenario, couldn't tell if something out of my
> working scenario could affect you.
>
> Make sure your indexes are also separated by /sites/contentset_X
> (index_X, index_Y, ...).
>
> flexcache works based on a fixed amount... i think the worst that can
> happen is that flexcache wouldn't be balanced across each site (maybe
> one site has much more use of the flexcache, and noone uses that part of
> cache in the site/machine you are), i don't know if I explained well.
>
> I must say I'm not an expert, though; this is all my opinion based on
> experience (in three different implantations), and i don't work in
> Alkacon...
>
> El 28/01/2010 18:10, Shency Revindran escribió:
>> Hi Jordi/Achim,
>>
>> Jordi, That is really useful information for me! Thanks a lot for that.
>>
>> Now considering all your points- (May be stupid, please forgive me - I am
>> too new to opencms)
>>
>> If we make sure that
>>
>> 1) opencms instance_X is dedicated for '/sites/contentset_X'.
>> (I.e., admin console users for this instance will ONLY access
>> '/sites/contentset_X'- using restricted user privileges. And this
>> instance of web application will ONLY serve request for contents under
>> '/sites/contentset_X')
>>
>> AND
>>
>> 2) module change always happens at one opencms instance (keeping all
>> other opencms instance shutdown during that period)
>>
>> -> Here, is it right to assume that indexes/flexcache/locks won't create
>> issues across multiple opencms instances as they work on different sites?
>> Or Am I completely wrong here?
>>
>> Thanks,
>> Shency
>>
>> -----Original Message-----
>> From: opencms-dev-bounces at opencms.org
>> [mailto:opencms-dev-bounces at opencms.org] On Behalf Of Achim Westermann
>> Sent: 28 January 2010 13:23
>> To: The OpenCms mailing list
>> Subject: Re: [opencms-dev] Can different installations of OpenCms connect
>> to the same db schema?
>>
>> Hi Jordi,
>>
>> that's a good description about the functionality that has to be there
>> for clustering OpenCms! And yes: The static export is quite hard, as
>> publishing an exportable resource has to delete the local exported
>> version as well as the versions on the cluster slaves. Some rsync might
>> do the Job. But with a remarkable delay or a remarkable workload for
>> polling while the ocee cluster would actively propagate the action to
>> do to the slaves. Also the solution to nmount the same disk for both
>> systems adds another point of failure / performance loss and somehow
>> transforms the solution to a "virtual Cluster".
>>
>> kind regards,
>>
>> Achim
>>
>> Jordi Martí wrote:
>>
>>> Shency, Achim,
>>>
>>> I'm one of those people Achim talks about, that have tried endlessly to
>>> make two separated instances of opencms work against the same db. I
>>> completetly agree with Achim that IT WORTHS THE MONEY (but I never
>>> tried).
>>>
>>> These are four key aspects I have being fighting against (I wrote in
>>> this list about it time ago). This is based on Opencms 6.2.3 (where I
>>> have two opencms against the same database):
>>>
>>> - Indexes: indexes are built in filesystem. If one instance
>>> indexes
>>> a file, the other one won't do it, or that's what experience tells me.
>>> You should manually reindex in both machines through a external process.
>>> - FlexCache: if publishing happens in one machine, the other one
>>> will not know that a page has been published, and cache won't be
>>> invalidated. That's why I generally use a timeout based cache (cache
>>> property => "timeout=10").
>>> - Config files: for example, if you import a module in one
>>> machine,
>>> the other file "opencms-modules.xml" in the other machine won't be
>>> modified. You could rsync both files or mount that directory or
>>> something like that. There's no problem with filesystem created JSP and
>>> images, because if one instance doesn't have it, it creates in on the
>>> fly, so there's no problem.
>>> - Workplace Locks: locks are built-in memory, not database. If you
>>> use multiple users on same files, it can affect you, and I don't have a
>>> workaround,.
>>>
>>> I don't use static export, so I'm not able to study how it affects
>>> static export further,...
>>>
>>> HIH,
>>>
>>> Jordi
>>>
>>>
>>>
>>> El 28/01/2010 13:28, Achim Westermann escribió:
>>>
>>>> Hi Shency,
>>>>
>>>> the cluster module is definetely worth the money. And I am not saying
>>>> this because I am a former member of Alkacon but because I've seen
>>>> some installations where they tried to hack their own cluster
>>>> functionalities with rsync, cronjobs,.... until they found out that
>>>> there are
>>>> more issues (e.g. caching) and then added another script, another
>>>> request handler... what a waste of money if you count the time spent
>>>> internally.
>>>>
>>>> cheers,
>>>>
>>>> Achim
>>>>
>>>> Shency Revindran wrote:
>>>>
>>>>
>>>>> Hi Achim,
>>>>>
>>>>> Thank you very much for your reply.
>>>>> I am going through the ocee documentation to see how helpful it can be
>>>>> in our case.
>>>>>
>>>>> Thanks,
>>>>> Shency
>>>>>
>>>>> -----Original Message-----
>>>>> From: opencms-dev-bounces at opencms.org
>>>>> [mailto:opencms-dev-bounces at opencms.org] On Behalf Of Achim Westermann
>>>>> Sent: 27 January 2010 13:49
>>>>> To: The OpenCms mailing list
>>>>> Subject: Re: [opencms-dev] Can different installations of OpenCms
>>>>> connect to the same db schema?
>>>>>
>>>>> Hi Shency,
>>>>>
>>>>> regarding point 2: That is not possible I think. One problem is that
>>>>> caches are cleared inside the webapp when something is published. The
>>>>> other opencms instance would not know it. There must not be more than
>>>>> one workplace log in for the same database
>>>>> If you try to scale up your architecture consider using ocee cluster
>>>>> to connect several opencms instances. The database could use ocee
>>>>> replication or mysql cluster.
>>>>>
>>>>> kind regards,
>>>>>
>>>>> Achim
>>>>>
>>>>> shency wrote:
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> We have an OpenCms 6 application.
>>>>>>
>>>>>> Currently there exist multiple installations (using sites/default)
>>>>>> for
>>>>>> different brands, connecting to separate db schema. Now we are
>>>>>> thinking of
>>>>>> using single db schema by using separate sites for each brand (i.e.,
>>>>>> sites/brandA, sites/brandB etc.)
>>>>>>
>>>>>> I can see two options to do this
>>>>>>
>>>>>> 1) Have a single installation connecting to common db schema and keep
>>>>>> the
>>>>>> content under separate sites (i.e., sites/brandA, sites/brandB etc.)
>>>>>> for
>>>>>> each brands. As per the opencms documentation, this is supported.
>>>>>>
>>>>>> 2) Here is my Qn, Is it possible to keep multiple installation of
>>>>>> openCms,
>>>>>> each using its on separate sites for content (i.e., sites/brandA,
>>>>>> sites/brandB etc.) and connect to the same underlying opencms db
>>>>>> schema? If
>>>>>> yes, does the openCms admin console behave consistently across the
>>>>>> installations to support concurrent content customisation of each
>>>>>> site (off
>>>>>> course with controlled user privileges)
>>>>>>
>>>>>> Please let me know If my description is confusing, so that I will try
>>>>>> to be
>>>>>> more clear
>>>>>> Thanks in advance for help in this regard,
>>>>>> Shency
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> This mail is sent to you from the opencms-dev mailing list
>>>>> To change your list options, or to unsubscribe from the list, please
>>>>> visit
>>>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>>>
>>>>> ______________________________________________________________________
>>>>> This email has been scanned by the MessageLabs Email Security System.
>>>>> For more information please visit http://www.messagelabs.com/email
>>>>> ______________________________________________________________________
>>>>>
>>>>> Please note, we have moved. Our new address is Monitise plc, Warnford
>>>>> Court, 29 Throgmorton Street, London EC2N 2AT
>>>>>
>>>>> This message contains confidential and proprietary information of the
>>>>> sender, and is intended only for the person(s) to whom it is
>>>>> addressed. Any use, distribution, copying, disclosure or taking of any
>>>>> action in reliance upon it by any other person is strictly prohibited.
>>>>> If you have received this message in error, please notify the e-mail
>>>>> sender immediately, and delete the original message without making a
>>>>> copy.
>>>>>
>>>>> The Monitise group comprises: Monitise plc (Reg. No. 6011822),
>>>>> Monitise Group Limited (Reg. No. 5590897), Monitise International
>>>>> Limited (Reg. No. 5556711), Monilink Limited (Reg. No. 4831976) and
>>>>> Monitise Business Solutions Limited (Reg. No. 5814266). These
>>>>> companies are registered in England and Wales and their registered
>>>>> office address is: Warnford Court, 29 Throgmorton Street, London, EC2N
>>>>> 2AT United Kingdom.
>>>>>
>>>>> _______________________________________________
>>>>> This mail is sent to you from the opencms-dev mailing list
>>>>> To change your list options, or to unsubscribe from the list, please
>>>>> visit
>>>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> This mail is sent to you from the opencms-dev mailing list
>>>> To change your list options, or to unsubscribe from the list, please
>>>> visit
>>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> This mail is sent to you from the opencms-dev mailing list
>>> To change your list options, or to unsubscribe from the list, please
>>> visit
>>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>>
>>>
>>
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please
>> visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please
>> visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>
>>
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>
>
--
View this message in context: http://old.nabble.com/Can-different-installations-of-OpenCms-connect-to-the-same-db-schema--tp27339201p27366759.html
Sent from the OpenCMS - Dev mailing list archive at Nabble.com.
More information about the opencms-dev
mailing list