No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor 9000 V300R006C00 File System Feature Guide 12

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Working Principle

Working Principle

This section provides the background information about key concepts of InfoEqualizer by analyzing performance bottlenecks and service reliability during client access. This section also explains the process for clients to access the OceanStor 9000 to help you understand the working principle of InfoEqualizer.

Background

This section provides the background information about key InfoEqualizer concepts such as domain name resolution and node failover by analyzing performance bottlenecks and service reliability during client access.

Performance Bottlenecks

As shown in Figure 2-2, before InfoEqualizer is used, all clients access a node using the static IP addresses of the node, and the client connection load cannot be detected or evenly distributed across nodes. As a result, nodes that have a heavy client connection load are prone to performance bottlenecks.

Figure 2-2  Performance bottlenecks

InfoEqualizer provides countermeasures against performance bottlenecks. Table 2-3 describes the countermeasures.

Table 2-3  Countermeasures against performance bottlenecks

No.

Problem

Countermeasure

1

The client connection load cannot be detected and evenly distributed among nodes.

Employs a load detection mechanism that can allocate access requests based on load balancing policies.

2

Access requests initiated by clients using nodes' static IP addresses cannot be evenly distributed among nodes based on load balancing policies.

Employs a domain name resolution mechanism that can dynamically allocate access requests initiated by clients using domain names to target nodes based on load balancing policies.

3

Client access requests cannot be sent to a group of nodes (with an independent load balancing policy).

Introduces the concept of zone and subnet. A zone corresponds to a group of nodes and can have its own domain name and load balancing policy. Clients can send access requests to nodes in a specific zone using the domain name of the zone.

Service Reliability

As shown in Figure 2-3, before InfoEqualizer is used, all clients access a node using the static IP address of the node. If the node becomes faulty, client services are interrupted and the access request is not initiated again.

Figure 2-3  Service reliability

InfoEqualizer provides countermeasures against unreliable services. Table 2-4 describes the countermeasures.

Table 2-4  Countermeasures against unreliable services

No.

Problem

Countermeasure

1

Clients cannot initiate access requests to a node again after the node becomes faulty.

Employs a node failover mechanism that can detect a faulty node and forward access requests from the faulty node to other nodes.

2

Access requests initiated by clients using a node's static IP address cannot be forwarded to another node after node failover.

Employs a domain name resolution mechanism that can dynamically allocate access requests initiated by clients using domain names to other nodes after node failover.

3

Online services on clients connected to a node are interrupted when the node becomes faulty.

Introduces the concept of dynamic IP address. A dynamic IP address corresponds to a dynamic domain name. If domain names are not resolved, when clients access a node using the node's IP address and the node becomes faulty later, this IP address can automatically "float" to another node.

Domain Name Resolution

This section describes domain name resolution and node failover of the InfoEqualizer feature.

Changing Dynamic and Static Front-end IP Addresses

By default, each front-end service network port is assigned one dynamic front-end service IP address. If the number of clients of the NFS share service is large, the client administrator can log in to the CLI and run change infoequalizer business_iface_min_dynip to change the value. Each front-end service network port can be assigned multiple dynamic IP addresses. Once the value is changed, the system will automatically assign IP addresses based on the number of nodes and available IP addresses in the dynamic IP address pool.

  • If there are sufficient available dynamic IP addresses in the dynamic IP address pool, the front-end service port of each node can be assigned sufficient dynamic IP addresses.
  • If there are not sufficient available dynamic IP addresses in the dynamic IP address pool, each node can be assigned one dynamic IP address at least.

After a node is migrated to a newly created zone, change the static service IP address of the node to subnet IP address of the zone.

IP Address
IP protocols supported by the front-end service network

The front-end service network of InfoEqualizer supports IPv4 and IPv6. Table 2-6 lists the two types of IP addresses.

Table 2-6  IPv4 and IPv6

Name

IPv4 Address

IPv6 Address

IP address bit

32-bit

128-bit

IP address format

The value is in dotted decimal notation, for example, xxx.xxx.xxx.xxx.

The value is in colon hexadecimal notation with zero compression, for example, xxxx:xxxx::xxxx.

Network representation

The subnet mask and the prefix can be used for representation. However, this feature supports only the subnet mask, for example, 255.255.0.0.

Only the prefix is used for representation, for example, 64.

One node can only be added to one subnet. Therefore, the IP address type of a node can only be IPv4 or IPv6. In addition, the dynamic and static front-end service IP addresses of one node must be of the same type, that is, the IP addresses must both be IPv4 or IPv6.

An InfoEqualizer DNS IP address with the IPv4 protocol is different from that with the IPv6 protocol. The same works for a dynamic front-end service IP address and a static front-end service IP address. For better description, the following uses IPv4 addresses as examples. For details about IPv6 addresses, see Application Example 3 (IPv6).

Changing Dynamic and Static Front-end IP Addresses

By default, each front-end service network port is assigned one dynamic front-end service IP address. If the number of clients of the NFS share service is large, the client administrator can log in to the CLI and run change infoequalizer business_iface_min_dynip to change the value. Each front-end service network port can be assigned multiple dynamic IP addresses. Once the value is changed, the system will automatically assign IP addresses based on the number of nodes and available IP addresses in the dynamic IP address pool.

  • If there are sufficient available dynamic IP addresses in the dynamic IP address pool, the front-end service port of each node can be assigned sufficient dynamic IP addresses.
  • If there are not sufficient available dynamic IP addresses in the dynamic IP address pool, each node can be assigned one dynamic IP address at least.

After a node is migrated to a newly created zone, change the static service IP address of the node to subnet IP address of the zone.

Node Failover

This section describes node failover of the InfoEqualizer feature.

Table 2-7 describes the service status on clients that access a node after node failover.

Table 2-7  Service status on clients using different protocols after node failover

Service Type

Recommended Access Methoda

Online Service Statusb

Service Status After Reconnection

NFS file sharing

Dynamic domain name

Conditional Uninterruptedc

Uninterrupted

CIFS file sharing

Static domain name

Conditional Uninterruptedd

Uninterrupted

FTP File Sharing

Dynamic domain name

Interrupted

Uninterrupted

a: In addition to dynamic and static domain names, dynamic and static front-end service IP addresses can also be used to access services. If non-recommended methods are adopted for service access, service performance and reliability may be compromised.

b: Online services refer to data read and write services initiated after clients connect to nodes.

c: Online services are uninterrupted on clients when clients use NFSv3. The uninterrupted function is not supported by NFSv4.

d: Online services are uninterrupted on clients when clients use SMB3.0 (such like Windows Server 2012 or Windows 8) and the clients use static domain names to access nodes.

Node Failover Process When Dynamic Domain Names are Used for Node Access

Figure 2-5 shows the node failover process when dynamic domain names are used for node access.

Figure 2-5  Node failover process when dynamic domain names are used for node access

The node failover process is as follows:

  1. Node 1 to which the client connects becomes faulty.
  2. The OceanStor 9000 immediately reclaims dynamic service IP address A from node 1 to the dynamic IP address pool, and switches services from node 1 to node 2.

  3. Online services are not interrupted on the client. The client uses dynamic service IP address A to access services on node 2.

    After node 1 returns to normal, the OceanStor 9000 assigns a dynamic IP address to node 1 from the dynamic IP address pool(manual mode by default). Node 1 can receive access requests initiated by new clients.

    There is two strategy to assign service IP address for recover nodes which newly join in the system. manual: assign IP address from IP address pool preferentially. auto: assign IP address from other node preferentially. The default strategy is manual.

NOTE:
When a node fails, the dynamic IP addresses assigned to each service network port on the node will be evenly assigned to normal nodes to prevent unbalanced workloads.
Node Failover Process When Static Domain Names are Used for Node Access

Figure 2-6 shows the node failover process when static domain names are used for node access.

Figure 2-6  Node failover process when static domain names are used for node access

The node failover process is as follows:

  1. Node 1 to which the client connects becomes faulty. Online services are interrupted on the client.
  2. The client uses the static domain name to initiate an access request again.
  3. The OceanStor 9000 detects the status of node 1 and returns static service IP address 2 of node 2.
  4. The client uses static service IP address 2 to initiate an access request.

    After node 1 returns to normal, the OceanStor 9000 detects node 1 as a normal node. Node 1 can receive access requests initiated by new clients.

Zones and Subnets

This section describes zones and subnets of InfoEqualizer and their functions.

Zones

A zone refers to a node's area that provides different services separately. In a zone, there are groups of nodes that have the same dynamic domain name, static domain name, and load balancing policy. The system has a default zone root. This zone contains all system nodes. You can create new zones and add nodes to them.

Figure 2-7 shows example zones.

Figure 2-7  Example zones

Zones enable load balancing policies to be flexibly configured for nodes carrying different types of client services, improving service performance. In addition, each client can access a specific zone for fault isolation.

The OceanStor 9000 assigns load balancing policies based on zones. The supported load balancing policies include Round-robin, CPU usage, Node connections, Node throughput, and Comprehensive node load. Table 2-8 shows the policies for reference.

Table 2-8  Load balancing policies for reference

Name

Description

Advantages

Disadvantages

Round-robin

When clients access the OceanStor 9000 using domain names, nodes are selected in the sequence recorded in the cache to process client services.

Data on which the domain name server (DNS) depends is cache data, ensuring accurate and reliable node selection.

  • When the dynamic IP address of the selected node is switched, cache data is cleared. As a result, a new node will be selected from the start point.
  • If any DNS domain name requests (such as ping, nslookup, showmount commands) time out or authentication of service connections fails, load balancing is affected.

CPU usage

When clients access the OceanStor 9000 by using domain names, nodes with the lowest CPU usage are selected to process client services.

Data on which the DNS depends is CPU usage. The nodes with the lowest CPU usage are selected to process client services.

  • Within a performance data update period, all client services are allocated to the nodes with the lowest CPU usage.
  • CPU usage changes significantly only after nodes carry services, delaying load balancing. Mounted clients must run services first so that load balancing can be achieved based on the CPU usage.

Node connections

When clients access the OceanStor 9000 by using domain names, nodes with the least number of connections are selected to process client services.

Data on which the DNS depends is the number of node connections. Nodes with the least number of connections are selected to process client services.

  • The number of node connections is not real-time performance data, affecting client load balancing.
  • If a mounted NFS service has no packet interaction within 6 minutes, the corresponding node clears the related connection information. However, the mount point still exists. New clients will be mounted to the same node based on node connections. As a result, the node has multiple mount points and carries multiple services, affecting load balancing.

Node throughput

When clients access the OceanStor 9000 by using domain names, nodes with the lowest throughput are selected to process client services.

Data on which the DNS depends is the throughput. Nodes with the lowest throughput are selected to process client services.

  • Within a performance data update period, all client services are allocated to the nodes with the lowest throughput.
  • The throughput changes significantly only after nodes carry services, delaying load balancing. Mounted clients must run services first so that load balancing can be achieved based on the throughput.

Comprehensive node load

When clients access the OceanStor 9000 by using domain names, nodes are selected to process client services based on comprehensive node loads. OceanStor 9000 calculates comprehensive node loads based on CPU usage and throughput. Less loaded nodes are more likely to be selected.
  • Comprehensive node loads are calculated based on CPU usage and throughput. The least loaded nodes are selected to carry client services.
  • Client services are not allocated only to the least loaded nodes. Less loaded nodes also carry services as much as possible, gradually achieving system load balancing.

Comprehensive node loads change significantly only after nodes carry services, delaying load balancing. Mounted clients must run services first so that load balancing can be achieved based on the comprehensive node loads.

Subnets

In some scenarios, clients residing on different subnets need to be connected to nodes whose IP addresses reside on the same subnet. In this situation, you can define a subnet that contains one or multiple zones in the OceanStor 9000, configure a DNS service IP address for this subnet, and reassign a static service IP address for all nodes on this subnet and a dynamic IP address pool for this subnet.

Figure 2-8 shows example subnets.

The OceanStor 9000 can be divided into subnets using IPv4 and IPv6 protocols. For each subnet, only one IP address type is acceptable. After a subnet is created successfully, its protocol cannot be changed.

Figure 2-8  Example subnets

Process for Clients to Access Nodes (External DNS Server Is Used)

This section describes the process for clients to access nodes using dynamic and static domain names when the external DNS server is used and the DNS config of clients is set as the external DNS server IP address.

Process for Clients to Access Nodes using static domain names

Figure 2-9 shows this process.

Figure 2-9  Process for Clients to Access Nodes using static domain names (external DNS server is used)

Table 2-9 describes the process.

Table 2-9  Process for Clients to Access Nodes using static domain names (external DNS server is used)
Service Type Process

Accessing a node using the static domain name (for example, zone1.example2.com)

1. The client sends a DNS resolution request to the DNS server to resolve the IP address corresponding to zone1.example2.com.

2. The DNS server forwards this resolution request to the InfoEqualizer DNS IP address of the OceanStor 9000.

3. The OceanStor 9000 returns the static service IP address of a node (for example, 192.168.0.30) based on the load balancing policy.

4. The DNS server returns 192.168.0.30 to the client.

5. The client sends a service access request to node 1 using the returned IP address.

6. Node 1 responds to the client's service access request.

Process for Clients to Access Nodes using dynamic domain names

Figure 2-10 shows this process.

Figure 2-10  Process for Clients to Access Nodes using dynamic domain names (external DNS server is used)

Table 2-10 describes the process.

Table 2-10  Process for Clients to Access Nodes using dynamic domain names (external DNS server is used)
Service Type Process

Accessing a node using the dynamic domain name (for example, zone1.example1.com)

1. The client queries the DNS server for the IP address corresponding to zone1.example1.com.

2. The DNS server forwards this query request to the OceanStor 9000 using the InfoEqualizer DNS IP address.

3. The OceanStor 9000 returns the dynamic service IP address of a node (for example, 192.168.0.52) based on the load balancing policy.

4. The DNS server returns 192.168.0.52 to the client.

5. The client sends a service access request to node 3 using the returned IP address.

6. Node 3 responds to the client's service access request.

Process for Clients to Access Nodes (External DNS Server Is Not Used)

This section describes the process for clients to access nodes using dynamic and static domain names when the external DNS server is not used and the DNS config of clients is set as the InfoEqualizer DNS IP address or zone DNS IP address.

Process for Clients to Access Nodes using static domain names

Figure 2-11 shows this process.

Figure 2-11  Process for Clients to Access Nodes using static domain names (external DNS server is not used)

Table 2-11 describes the process.

Table 2-11  Process for Clients to Access Nodes using static domain names (external DNS server is not used)

Service Type

Process

Accessing a node using the static domain name (for example, zone1.example2.com)

1. The client sends a DNS resolution request to the InfoEqualizer DNS IP address of the OceanStor 9000 to resolve the IP address corresponding to zone1.example2.com.

2. The OceanStor 9000 returns the static service IP address of a node (for example, 192.168.0.30) based on the load balancing policy.

3. The client sends a service access request to node 1 using the returned IP address.

4. Node 1 responds to the client's service access request.

Process for Clients to Access Nodes using dynamic domain names

Figure 2-12 shows this process.

Figure 2-12  Process for Clients to Access Nodes using dynamic domain names (external DNS server is not used)

Table 2-12 describes the process.

Table 2-12  Process for Clients to Access Nodes using dynamic domain names (external DNS server is not used)

Service Type

Process

Accessing a node using the dynamic domain name (for example, zone1.example1.com)

1. The client sends a DNS resolution request to the InfoEqualizer DNS IP address of the OceanStor 9000 to resolve the IP address corresponding to zone1.example1.com.

2. The OceanStor 9000 returns the dynamic service IP address of a node (for example, 192.168.0.52) based on the load balancing policy.

3. The client sends a service access request to node 3 using the returned IP address.

4. Node 3 responds to the client's service access request.

Translation
Download
Updated: 2019-06-27

Document ID: EDOC1000122519

Views: 74780

Downloads: 145

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next