Adding Cross-Cluster Tickets to Secure Clusters

Introduces the cross-cluster ticket generation process on a secure cluster.

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.
  • Table and streams replication is a push operation. The table or stream data is pushed from the source cluster to the destination cluster. Because the source cluster is performing the operation, the source cluster receives a ticket that is generated on the destination cluster.
  • Volume mirroring is a pull operation. The volume data is pulled by the destination cluster from the source cluster. Because the destination cluster is performing the operation, the destination cluster receives a ticket that is generated on the source 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 the two secure clusters newyork and sanfrancisco. newyork are 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 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, decide which of two secure clusters needs the cross-cluster ticket. In the following 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.
  1. 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 the following command.
    Note: For crosscluster and service tickets, the default value is LIFETIME.
    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.
  2. On a CLDB node of cluster B, append the cross-cluster ticket to the maprserverticket file.
    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
  3. Copy the maprserverticket file 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.