AEM 6.4 - Shared datastore for binaryless replication

[a_mn1]

Hello Team, I am trying to set up a shared datastore for multiple aem instances.  We are planning to have a common source of content (AEM assets). there will be multiple channels (Existing AEM applications running on different machines).

I would want each of these instances to be mounted to shared datastore (FileDatastore) and have their individual datastores migrated to the shared filesystems.

Can this be achieved?. My doubt is since datastores follow a particular folder and file naming patterns, will I run into a conflict where 2 different files across different AEM instances will have same name.

My AEM assets is running in 6.4 . One of the channel(AEM sites ) is in 6.4 and another channel(Again AEM sites) is in 6.2.

Regards,

Anand

[Gaurav-Behl]

6.2 uses old version of OAK API than 6.4. In addition to that, 6.2 uses '.cfg' extension for configuration files but 6.4 uses '.config' extension. I doubt that it would work.

Better approach would be to upgrade/migrate 6.2 to 6.4 and then set up shared datastore.

[a_mn1]

Hello Gaurav, that is the plan. We are planning to migrate 6.2 --> 6.4 . And then set up shared datastore between instances. Even in that case, will I have a conflict of data as the structure of datastore folder is as below.

-->  -->

Now the above datastore could be from Channel1. Now If I try to migrate from Channel 2, will it also have a file with same name. I have seen folders with same name(01.1a etc). ?

[Gaurav-Behl]

Not sure but you could set it up from scratch to avoid this. Why would you copy/paste both individual datastore in this shared one?

[a_mn1]

The ask is to set up a central repository of content. But I already have 2 AEM sites application up and running. So the question is how to migrate the existing data so that the new contents can use the binary less feature,

[Gaurav-Behl]

I would setup new instance with binaryless and then use package manager/crx2oak/rsync or a similar tool to port the content/assets to the new instance.

[a_mn1]

Even , I too thought of the same initially. But wanted to see the possibility of dynamic addition of instances.

[Jörg_Hoh]

Hi,

do I understand you correctly, that you have at least 2 already existing AEM instances, and that you want to merge the datastores in order to save disk space? But you don't want to merge the actual repository content?

My assumption is that it should be possible. In that case you need to merge the datastore directories on a file level.

Jörg

[a_mn1]

Hi Jörg, Yes your understanding is correct. Right now i have only 2 AEM instance (1st  running in 6.4 and the 2nd is in 6.2 (this will be upgraded to 6.4 by the end of the year)). I may have more AEM instances coming up . I need to merge all the AEM instances Data store with  the new Central asset repository (AEM Assets 6.4) that we are going to set up.  In near future I don't intend to migrate all the assets in the individual AEM instance to the central repository. However any new content will be published from central repository to each of the AEM instances. And this publish I prefer to have them as Binary less.

So to achieve this .My plan is to do the below steps:

1. Set up an NFS which will be mounted to Central Asset repository (CAR) and AEM 1st instance.

2.  Configure CAR to have its datastore pointed to shared mount.

3. Configure AEM 1st instance to  have its datastore pointed to shared mount.

4. Migrate the existing datastore of AEM 1st instance to  shared mount.

5. Upgrade AEM 2nd instance to 6.4

6  Configure the datastore of  AEM 2nd instance to point to shared mount.

7. Migrate the existing datastore of AEM 2nd instance to  shared mount.

In-fact we have started working on steps 1 to 4. Confusion is in step 7. I doubt if there will be name conflicts when I try to merge the other datastores (Another AEM instance .. in this case AEM 2nd instance )to an existing datastore since the datastore directory structure is as below.

--> -->

Could you please explain how AEM will handle this situation.

[Jörg_Hoh]

The datastore is content-adressed. That means that the name of the blob is a function of the content in the blob. Basically the same blob results in the same name.

To address your concern at step 7: Do you find any name clashes and can you check if the binaries are different?

In any case I would check your approach with Adobe support, because we both might overlook some aspects they might be aware of.

[a_mn1]

Thanks Jorg.

I have not reached step 7. Right now only in step 1-4. Our business wanted this use case and they wanted to see if we can save diskspace. However I didn't  want to end up in a mess by proposing and working on the above mentioned architecture (steps), without getting an understanding and clarity on the functionality.

Regards,

Anand

[Jörg_Hoh]

Your approach makes sense, and I think it's doable. Test your approach before, but I don't expect surprises. But just in case make sure that Adobe supports vets this approach as well.

Jörg

[a_mn1]

Thanks Jorg. .  BTB did you get a chance to check with Adobe support on this.

I too will try to check with Adobe Support

Regards,

Anand

[a_mn1]

Hello Jorg, Unfortunately whatever I doubt has happened it seems. Today  I could see that 2 different files (both across 2 different instance) has the same name and folder structure.

I havent heard anything from Adobe support yet .

Regards,

Anand MN