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 <b>m_OpenCms</b> and <b>m_MySQL</b>. In Slave machine, that is <b>s_OpenCms</b> and <b>s_MySQL</b>.
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 <b>DISABLE</b>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
<blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Isaac R. Higgins wrote:</div>
<div class="quote-message">
I have 4 servers that all share the same database. I added scheduled tasks to clear the cache on interval (which was not really a problem because the cache expires by default anyway). The bigger problem was the search index which I also added a scheduled task to update nightly. There's only 1 workplace server that the users use, but I have been successful using the workplace on all of the other servers.
-----Original Message-----
From: opencms-dev-bounces@opencms.org on behalf of Achim Westermann
Sent: Thu 1/28/2010 1:02 PM
To: The OpenCms mailing list
Subject: Re: [opencms-dev] Can different installations of OpenCms connect to the same db schema?
Hi Shency,
you also had to ensure that content from /sites/contentset_X is only served from the very same server (because of flex caching) -> No
clustering.
Regardless of the fact that I don't understand why you would use a setup with two OpenCms instances that share the same database but actions
would be taken to ensure that no data is shared (and in this case I'd rather recommend to use two databases ;-)) you also had to ensure that
content from /sites/contentset_X will only be serverd from the exact very server: No appserver clustering because of the flexcache allowed.
HTH,
Achim
Shency Revindran wrote:
> 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@opencms.org [mailto:opencms-dev-bounces@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@opencms.org [mailto:opencms-dev-bounces@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
_______________________________________________
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
</div>
</div></blockquote>
<br><hr align="left" width="300">
View this message in context: <a href="http://old.nabble.com/Can-different-installations-of-OpenCms-connect-to-the-same-db-schema--tp27339201p27366758.html">Re: Can different installations of OpenCms connect to the same db schema?</a><br>
Sent from the <a href="http://old.nabble.com/OpenCMS---Dev-f654.html">OpenCMS - Dev mailing list archive</a> at Nabble.com.<br>