Adding Cross-Cluster Tickets to Secure Clusters

Describes how to add cross-cluster tickets to secure clusters that push and pull data.

About this task

Cross-cluster tickets are required on secure clusters that need to push data to another secure cluster and on secure clusters that need to pull data from another secure cluster.

NOTE:

For instructions on creating cross-cluster tickets for mirroring volumes across secure clusters, see the section “Generating a Cross-cluster Ticket” in the topic Using Promotable Mirrors.

For example, suppose you have the two secure clusters newyork and sanfrancisco. newyork is pushing data to sanfrancisco. You must generate a cross-cluster ticket on sanfrancisco. You will then use the cross-cluster ticket on newyork.

table replication involving secure clusters is an example of this type of situation. In this case, table replication requires the secure source cluster to have a cross-cluster ticket for every secure destination cluster that the source cluster replicates to. In situations such as bi-directional table replication or multi-master table replication involving secure clusters, both clusters act as source clusters; therefore, both clusters must have a cross-cluster ticket that was generated on the other cluster.

As another example, suppose you have the two secure clusters tokyo and hyderabad. tokyo is pulling data from hyderabad, so you must generate a cross-cluster ticket on hyderabad. You will then use the cross-cluster ticket on tokyo.

To add a cross-cluster ticket to a secure cluster:

Procedure

Decide which of two secure clusters needs the cross-cluster ticket. In the remaining steps, the secure cluster on which you generate the cross-cluster ticket is referred to as cluster A and the other secure cluster is referred to as cluster B.
On cluster A, generate a cross-cluster ticket.
```
maprlogin generateticket -type crosscluster -out 
<path and filename for the cross-cluster ticket> -duration <lifetime of the ticket>
```
For example, if you wanted to save the ticket in the /tmp directory as sanfrancisco-clusterticket and you wanted the ticket to last for ten years, you would run this command:
```
maprlogin generateticket -type crosscluster -out 
/tmp/sanfrancisco-clusterticket -duration 3650:0:0
```
NOTE: It is critical to specify an appropriate value for the duration. After the ticket expires, communication between the clusters will stop. In this example, the duration of ten years is given for convenience of explanation. Use a value that is consistent with your security policies.
Provide the cross-cluster ticket to the administrator of the cluster B.
On a CLDB node of cluster B, append the cross-cluster ticket to maprserverticket:
```
cat <path and filename for the cross-cluster ticket> >> /opt/mapr/conf/maprserverticket
```
For example, if you copied the cross-cluster ticket into cluster B as /tmp/sanfrancisco-clusterticket, you would run this command:
```
cat /tmp/sanfrancisco-clusterticket >> /opt/mapr/conf/maprserverticket
```
Copy maprserverticket to the directory /opt/mapr/conf/ on all other CLDB nodes within cluster B.

NOTE: If you move CLDBs to other nodes in the future, remember to copy this maprserverticket to those nodes. To avoid problems that might arise if you forget to do this, you might consider copying the maprserverticket now to all nodes in the cluster.