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.
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 is pushing data to
sanfrancisco. You must generate a cross-cluster ticket on
sanfrancisco. You will then use the cross-cluster ticket on
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 is pulling data from
hyderabad, so you must generate a cross-cluster ticket on
hyderabad. You will then use the cross-cluster ticket on
To add a cross-cluster ticket to a secure cluster:
- 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
/tmpdirectory 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
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
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
maprserverticketto the directory
/opt/mapr/conf/on all other CLDB nodes within cluster B.
If you move CLDBs to other nodes in the future, remember to copy this
maprserverticketto those nodes. To avoid problems that might arise if you forget to do this, you might consider copying the
maprserverticketnow to all nodes in the cluster.