Configuring Cross-Cluster Mutual Trust Relationships
Scenario
If cluster A needs to access the resources of cluster B, the mutual trust relationship must be configured between these two clusters.
If no trust relationship is configured, resources of a cluster are available only for users in this cluster. MRS automatically assigns a unique domain name for each cluster to define the scope of resources for users.
![](https://support.huaweicloud.com/intl/en-us/eu-west-0-usermanual-mrs/public_sys-resources/note_3.0-en-us.png)
The operations described in this section apply only to clusters of versions earlier than MRS 3.x.
For clusters of MRS 3.x or later, see Configuring Cross-Manager Mutual Trust Between Clusters.
Impact on the System
- After cross-cluster mutual trust is configured, resources of a cluster become available for users in other cluster. User permission in the clusters must be regularly checked based on service and security requirements.
- After cross-cluster mutual trust is configured, the KrbServer service needs to be restarted and the cluster becomes unavailable during the restart.
- After cross-cluster mutual trust is configured, internal users krbtgt/Local cluster domain name@External cluster domain name and krbtgt/External cluster domain name@Local cluster domain name are added to the two clusters. The internal users cannot be deleted. The default password is Crossrealm@123.
Procedure
- On the MRS management console, query all security groups of the two clusters.
- On the VPC management console, add rules for each security group.
Set Protocol to ANY, Transfer Direction to Inbound,
and Source to Security Group. The source is the security group of the peer cluster.
- For cluster A, add inbound rules to the security group, set Source to the security groups of cluster B (the peer cluster of cluster A).
- For cluster B, add inbound rules to the security group, set Source to the security groups of cluster A (the peer cluster of cluster B).
- Log in to MRS Manager of the two clusters separately. For details, see Accessing MRS Manager MRS 2.x or Earlier). Click Service and check whether the Health Status of all components is Good.
- If yes, go to 4.
- If no, contact technical support personnel for troubleshooting.
- Query configuration information.
- On MRS Manager of the two clusters, choose OM IP Address of the two KerberosServer hosts. . Query the
- Click Service Configuration. Set Type to All. Choose in the navigation tree on the left. Query the value of kdc_ports. The default value is 21732.
- Click Realm and query the value of default_realm.
- On MRS Manager of either cluster, modify the peer_realms parameter.
Table 1 Parameter description Parameter
Description
realm_name
Domain name of the mutual-trust cluster, that is, the value of default_realm obtained in step 4.
ip_port
KDC address of the peer cluster. Format: IP address of a KerberosServer node in the peer cluster:kdc_port
The addresses of the two KerberosServer nodes are separated by a comma. For example, if the IP addresses of the KerberosServer nodes are 10.0.0.1 and 10.0.0.2 respectively, the value of this parameter is 10.0.0.1:21732,10.0.0.2:21732.
- To deploy trust relationships with multiple clusters, click
to add items and specify relevant parameters. To delete an item, click
.
- A cluster can have trust relationships with a maximum of 16 clusters. By default, no trust relationship exists between different clusters that are trusted by a local cluster.
- To deploy trust relationships with multiple clusters, click
- Click Save Configuration. In the dialog box that is displayed, select Restart the affected services or instances and click OK. If you do not select Restart the affected services or instances, manually restart the affected services or instances.
After Operation successful is displayed, click Finish.
- Exit MRS Manager and log in to it again. If the login is successful, the configurations are valid.
- Log in to MRS Manager of the other cluster and repeat step 5 to 7.
Follow-up Operations
After cross-cluster mutual trust is configured, the service configuration parameters are modified on MRS Manager and the service is restarted. Therefore, you need to prepare the client configuration file again and update the client.
Scenario 1:
Cluster A and cluster B (peer cluster and mutually trusted cluster) are the same type, for example, analysis cluster or streaming cluster. Follow instructions in Updating a Client (Versions Earlier Than 3.x) to update the client configuration files of cluster A and B respectively.
- Update the client configuration file of cluster A.
- Update the client configuration file of cluster B.
Scenario 2:
Cluster A and cluster B (peer cluster and mutually trusted cluster) are the different type. Perform the following steps to update the configuration files.
- Update the client configuration file of cluster A to cluster B.
- Update the client configuration file of cluster B to cluster A.
- Update the client configuration file of cluster A.
- Update the client configuration file of cluster B.
- Log in to MRS Manager of cluster A.
- Click Services, and then Download Client.
- Set Client Type to Only configuration files.
- Set Download to to Remote host.
- Set Host IP Address to the IP address of the active Master node of cluster B, Host Port to 22, and Save Path to /tmp.
- If the default port 22 for logging in to cluster B using SSH is changed, set Host Port to a new port.
- The value of Save Path contains a maximum of 256 characters.
- Set Login User to root.
If another user is used, ensure that the user has permissions to read, write, and execute the save path.
- Click OK to generate a client file.
If the following information is displayed, the client file is saved. Click Close.
Client files downloaded to the remote host successfully.
If the following information is displayed, check the username, password, and security group configurations of the remote host. Ensure that the username and password are correct and an inbound rule of the SSH (22) port has been added to the security group of the remote host. And then, go to 2 to download the client again.
Failed to connect to the server. Please check the network connection or parameter settings.
- Log in to the ECS of cluster B using VNC. For details, see
in the Elastic Cloud Server User Guide
Log in to the ECS. For details, see Login Using an SSH Key. Set the ECS password and log in to the ECS in VNC mode.
- Run the following command to switch to the client directory, for example, /opt/Bigdata/client:
cd /opt/Bigdata/client
- Run the following command to update the client configuration of cluster A to cluster B:
sh refreshConfig.sh Client installation directory Full path of the client configuration file package
For example, run the following command:
sh refreshConfig.sh /opt/Bigdata/client /tmp/MRS_Services_Client.tar
If the following information is displayed, the configurations have been updated successfully.
ReFresh components client config is complete. Succeed to refresh components client config.
You can also refer to method 2 in Updating a Client (Versions Earlier Than 3.x) to perform operations in 1 to 10.
- Repeat step 1 to 10 to update the client configuration file of cluster B to cluster A.
- Follow instructions in Updating a Client (Versions Earlier Than 3.x) to update the client configuration file of the local cluster.
- Update the client configuration file of cluster A.
- Update the client configuration file of cluster B.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot