Help Center/ MapReduce Service/ User Guide (Kuala Lumpur Region)/ FusionInsight Manager Operation Guide (Applicable to 3.x)/ Cluster Management/ Managing Mutual Trust Relationships Between Managers/ Configuring Cross-Manager Cluster Mutual Trust Relationships
Updated on 2022-12-14 GMT+08:00
View PDF
Share

Configuring Cross-Manager Cluster Mutual Trust Relationships

Scenario

When two clusters in different security modes need to access each other's resources, the administrator can set up a mutual trust system so that users of external systems can use the system.

The usage range of users in each system is called a domain. Each Manager system must have a unique domain name. Cross-Manager access means users to be used across domains.

A maximum of 500 mutual trust clusters can be configured.

Impact on the System

  • After cross-Cluster mutual trust is configured, users of an external system can be used in the local system. The system administrator needs to periodically check the user rights in the Manager system based on enterprise service and security requirements.
  • When configuring cross-cluster mutual trust, you need to stop all clusters, which interrupts services.
  • After cross-Cluster mutual trust is configured, each of the clusters trusting each other can add Kerberos internal users "krbtgt/local cluster domain name@external cluster domain name" and "krbtgt/external cluster domain name@local cluster domain name". The two users cannot be deleted. Based on enterprise service and security requirements, the system administrator needs to change the password periodically. The passwords of the four users in the two systems trusting each other must be the same. For details, see Changing the Password for a Component Running User. Connections of cross-Manager service applications may be affected during the password change.
  • After configuring the cross-Cluster mutual trust relationship, download and install the client again for each cluster.
  • After cross-Cluster mutual trust is configured, verify services. For information about how to access the resources in the remote system by using users in the local system, see Assigning User Permissions After Cross-Cluster Mutual Trust Is Configured.

Prerequisites

  • The system administrator has specified service requirements and planned domain names for the systems. A domain name can contain only uppercase letters, digits, dots (.), and underscores (_), and must start with a letter or a digit.
  • Before configuring cross-Cluster mutual trust, ensure that the domain names of the two Manager systems are different. When an ECS or BMS cluster is created on MRS, a unique system domain name is randomly generated. Generally, you do not need to change the system domain name.
  • Before cross-Cluster mutual trust is configured, ensure that the two systems do not have the same host name or the same IP address.
  • Time of two systems configured trust relationships must be consistent and the Network Time Protocol (NTP) service in the two systems must use the same time source.
  • Running Status of all services in the Manager clusters is Normal.
  • The acl.compare.shortName parameter of the ZooKeeper service of all clusters in the Manager must be set to the default value true. Otherwise, change the value to true and restart the ZooKeeper service.

Procedure

  1. Log in to the FusionInsight Manager of one of the two systems to be configured with mutual trust.

    Click > Stop next to the cluster to be operated. Enter the administrator password. In the Stop Cluster dialog box that is displayed, click OK. Wait until the cluster is stopped.

  2. Stop all clusters on the home page.
  3. Choose System > Permission > Domain and Mutual Trust.
  4. Change the Peer Mutual Trust Domain parameter

    Table 1 Related Parameters

    Parameters

    Description

    realm_name

    Set the value to the domain name of the peer system.

    ip_port

    Set the value to the KDC address of the peer system.

    The parameter value format is IP address of the node where the Kerberos service of the mutual trust cluster is to be configured in the peer system:port.

    • In dual-plane networking, you need to enter the service IP address.
    • If an IPv6 address is used, the IP address must be enclosed in square brackets ([]).
    • Use a comma to separate the KDC addresses of the active and standby Kerberos services or multiple clusters in the peer system need to establish mutual trust with the local system.
    • You can obtain the port number by viewing the kdc_ports parameter of the KrbServer service. The default value is 21732. You can obtain the IP address of the node where the service is deployed by clicking the Instances tab on the KrbServer service page and viewing the Service IP Address of the KerberosServer role.

      For example, if the Kerberos service is deployed on 10.0.0.1 and 10.0.0.2, to establish mutual trust with the local system, the corresponding parameter value is 10.0.0.1:21732,10.0.0.2:21732.

    If you need to configure trust relationships for multiple Manager systems, click to add a new project and set parameters. A maximum of 16 systems can be mutually trusted. Click to delete redundant configurations.

  5. Click OK.
  6. Log in to the active management node using the active management IP address as user omm. Run the following command to update domain configuration:

    sh ${BIGDATA_HOME}/om-server/om/sbin/restart-RealmConfig.sh

    The command is run successfully if the following information is displayed:

    Modify realm successfully. Use the new password to log into FusionInsight again.

    After restart, some hosts and services cannot be accessed and an alarm is generated. This problem can be automatically resolved in about 1 minute after restart-RealmConfig.sh is run.

  7. Log in to the FusionInsight Manager and start all clusters.

    Click > Start next to the cluster to be operated. In the Start Cluster dialog box that is displayed, click OK. Wait until the cluster is started.

  8. Log in to FusionInsight Manager of the other system and repeat the preceding operations.