Hi Dynamox

If your replication is already running using a profile then the step 3) on the target is not necessary. You only need to grant the c (and d if you need) capability from the newapp pool to the replicatin profile.
Please issue a sho repl det on the source to find out if the profile used for replication is really called replication. It may be called differently.

What you are exactly doing is the following. By using a profile on the source to connect to the target for replication you can disable the anonymous profile. The replication profile used should be an access profile and have c (and d) capability in all replicated pools.

I personally prefer bi-directionally replicated environments as it removes handish work after a disaster situation where an application may write content to the target system.

Your command 3 on the target won't work. it's either create pool or create profile. I normally take care to have the replication profile have the default as it's home pool but with no capabilities (provided that all applications are using their own pools and no writes to the default pool are made). Then grant c and d to the replication profile for all replicated pools so that the replication profile only has capabilities in the replicated pools. With this you can add a pool to the replication accidentally and no content will get replicated as no capabilities available.

Best regards, Holger

On the source cluster
1) Create the pool
2) update pool replication
3) Create the profile - Set the profile to use the new pool as its home pool
4) Create a pea file
5) export poolprofilesetup

On the replica
1) import poolprofilesetup - import the new pool and profile
2) Create a pea file for the imported profile
3) set grants
where profile name = the replication profile (show replication detail on the source)
and pool name = the new pool
grant 'ced' rights to the pool

Merge PEA Files

This procedure explains how to merge two or more PEA files generated on different clusters into one PEA file to support replication and application failover.

1.

Launch a text editor on your local machine and open the PEA file of the profile that was generated on the source cluster. The content of this file should be similar to:

<.pea version=¿1.0.0¿>





MyApplicationSecret









MySpecialApplicationSecretForClusterA







2.

Open the PEA file that was generated on the target cluster for the same profile and copy everything from the ... section, including the profile-cluster information, from the second file into the first one:





MySpecialApplicationSecretForClusterB







The merged PEA file would then look like this:


<.pea version=¿1.0.0¿>





MyApplicationSecret









MySpecialApplicationSecretForClusterA









MySpecialApplicationSecretForClusterB







3.

Repeat step 2 for each PEA file that has been created for the same profile on a different cluster.
4.

Close all PEA files and save the merged PEA file.
5.

Copy the merged PEA file to the application server and configure the server to use the new pea file

Thank you Holger and Dennis,

I am going to dissect Dennis instructions to make sure i understand what i am doing

On source:

1) Make sense, i will use command:

create pool NewApp

2) when you say "update pool replication", in this instance replication simply means we are modifying replication functionality, there is no such pool as replication ? So i would enter:

update pool replication NewApp

We are just simply enabling replication functionality for NewApp pool ?

3) Makes sense, i will select NewApp as my home pool.

create profile NewApp

4) I will create PEA file during step 3.

5) I will export pool information and profile information just for NewApp


On the replica

1) I will import pool and profile information that was created in step 5 on source

import poolprofilesetup

2) I will create PEA file during step 1

3) Here comes the confusing part

this is output from "show replication detail" on source

Replicate Delete:                             yes
Replicate incoming replicated Objects:        no
Replicated Pools:                             default,
                                              mail-dev,
                                              mail-dev-dr,
                                              email-arc,
                                              app-01,
                                              app-02,
                                              app-03
Profile Name:                                 replication
 
Number of Blob Writes to be replicated:                   N/A
Number of MB to be replicated:                            N/A
Number of C-Clip Deletes to be replicated:                2,459
Number of C-Clip Event and Hold Updates to be replicated: 0
Number of Parked Entries:                                 320

So in my case replication profile is actually called "replication" ? My command would look like this:

set grants NewApp replication

So what are we saying here ? Profile "replication" that exists on source can write to pool NewApp on replica ? How does replica know about existence of profile "replication" on target ?

Thank you so much

On source:

1) Make sense, i will use command:

create pool NewApp



2) when you say "update pool replication", in this instance replication simply means we are modifying replication functionality, there is no such pool as replication ? So i would enter:

update pool replication NewApp

We are just simply enabling replication functionality for NewApp pool ?



3) Makes sense, i will select NewApp as my home pool.

create profile NewApp



4) I will create PEA file during step 3.


Do the same on the replica calling it something like C:\temp\newapp-target.pea
then you merge these two into a single pea file per previous instructions.

5) I will export pool information and profile information just for NewApp



On the replica

1) I will import pool and profile information that was created in step 5 on source

import poolprofilesetup



2) I will create PEA file during step 1



3) Here comes the confusing part

this is output from "show replication detail" on source

Replicate Delete:                             yes
Replicate incoming replicated Objects:        no
Replicated Pools:                             default,
                                              mail-dev,
                                              mail-dev-dr,
                                              email-arc,
                                              app-01,
                                              app-02,
                                              app-03
Profile Name:                                 replication
 
Number of Blob Writes to be replicated:                   N/A
Number of MB to be replicated:                            N/A
Number of C-Clip Deletes to be replicated:                2,459
Number of C-Clip Event and Hold Updates to be replicated: 0
Number of Parked Entries:                                 320

So in my case replication profile is actually called "replication" ? My command would look like this:

set grants NewApp replication



So what are we saying here ? Profile "replication" that exists on source can write to pool NewApp on replica ? How does replica know about existence of profile "replication" on target ?

Dennis,

when i run "show profile list" on source and target Centera, they both list:

Profile Name              Home Pool       Enabled  Configured Usage
-----------------------------------------------------------------------------
 
replication               default         yes      Data Access

what does it mean ? Is "replication" profile supposed to exist on both source and replica ?

Thank you very much for your time

The profile is only needed on the replica cluster unless you have bi-directional replication enabled. In this case, you will need it on both sides.

Dennis

ok, so i'll assume it was created by EMC thinking we would be doing bi-direction replication which we never did, we only have uni-directional.

So we have this "replication" profile on target Centera. How does replication process work? In step 2 on source we did:

update pool replication NewApp

1) So now Source Centera knows that NewApp pool needs to be replicated, it starts sending data to remote Centera and remote Centera uses profile "replication" to write data coming from source Centera to pool NewApp ?

2) Since we have only one "replication" profile, how does target Centera know which pool incoming writes need to go to ?

Thank you for your patience Dennis.

1) So now Source Centera knows that NewApp pool needs to be replicated, it starts sending data to remote Centera and remote Centera uses profile "replication" to write data coming from source Centera to pool NewApp ?


2) Since we have only one "replication" profile, how does target Centera know which pool incoming writes need to go to ?

The pool information is stored in the clip on the source. Replication just copies this existing clip to the replica. It does not change anything (if it did, the content address would change).

Thank you Dennis.