ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಒಂದು ಸರ್ವರ್‌ನ ಶಕ್ತಿಯು ಸಾಕಾಗದಿದ್ದರೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ತಯಾರಕರು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಒದಗಿಸದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು? ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಖರೀದಿಸುವುದರಿಂದ ಹಿಡಿದು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವವರೆಗೆ ಹಲವು ಆಯ್ಕೆಗಳಿವೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಪರಿಸ್ಥಿತಿಯಿಂದ ಯಾವುದು ಸರಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು. ನಿಮ್ಮ ಬಜೆಟ್ ಸೀಮಿತವಾಗಿದ್ದರೆ ಮತ್ತು ನೀವು ಉಚಿತ ಸರ್ವರ್ ಹೊಂದಿದ್ದರೆ ನೀವು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ.

ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ವ್ಯವಸ್ಥೆಯಾಗಿ, ನಾವು InfoWatch ನಿಂದ DLP (ಮಾಹಿತಿ ಸೋರಿಕೆ ತಡೆಗಟ್ಟುವ ವ್ಯವಸ್ಥೆ) ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಬ್ಯಾಲೆನ್ಸರ್ ಕಾರ್ಯವನ್ನು "ಯುದ್ಧ" ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇರಿಸುವುದು.

ನಾವು ಎದುರಿಸಿದ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದು ಮೂಲ NAT (SNAT) ಅನ್ನು ಬಳಸಲು ಅಸಮರ್ಥತೆಯಾಗಿದೆ. ಇದು ಏಕೆ ಬೇಕು ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಲಾಗಿದೆ, ನಾವು ಮತ್ತಷ್ಟು ವಿವರಿಸುತ್ತೇವೆ.

ಆದ್ದರಿಂದ, ಆರಂಭದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಯ ತಾರ್ಕಿಕ ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ICAP ಟ್ರಾಫಿಕ್, SMTP, ಬಳಕೆದಾರರ ಕಂಪ್ಯೂಟರ್‌ಗಳಿಂದ ಈವೆಂಟ್‌ಗಳನ್ನು ಟ್ರಾಫಿಕ್ ಮಾನಿಟರ್ (TM) ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ TM ನಲ್ಲಿ ಈವೆಂಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ ಲೋಡ್ ಅನ್ನು ಸುಲಭವಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ, ಆದರೆ TM ನಲ್ಲಿನ ಹೊರೆ ಭಾರವಾಗಿರುತ್ತದೆ. ಡಿವೈಸ್ ಮಾನಿಟರ್ (ಡಿಎಮ್) ಸರ್ವರ್‌ನಲ್ಲಿನ ಸಂದೇಶ ಸರದಿಯ ಗೋಚರಿಸುವಿಕೆಯಿಂದ, ಹಾಗೆಯೇ TM ನಲ್ಲಿನ CPU ಮತ್ತು ಮೆಮೊರಿ ಲೋಡ್‌ನಿಂದ ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಮೊದಲ ನೋಟದಲ್ಲಿ, ನಾವು ಈ ಯೋಜನೆಗೆ ಮತ್ತೊಂದು TM ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸಿದರೆ, ನಂತರ ICAP ಅಥವಾ DM ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ ಕಡಿಮೆಯಾದ ಕಾರಣ ನಾವು ಈ ವಿಧಾನವನ್ನು ಬಳಸದಿರಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಪರಿಹಾರದ ವಿವರಣೆ

ಸೂಕ್ತವಾದ ಪರಿಹಾರವನ್ನು ಹುಡುಕುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಾವು ಮುಕ್ತವಾಗಿ ವಿತರಿಸಿದ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ ಉಳಿಸಿಕೊಳ್ಳಲಾಗಿದೆ ಜೊತೆಗೂಡಿ LVS. ಏಕೆಂದರೆ Keepalived ವಿಫಲವಾದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು LVS ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸಹ ನಿರ್ವಹಿಸಬಹುದು.

ನಾವು ಸಾಧಿಸಲು ಬಯಸಿದ್ದನ್ನು (ಟಿಎಮ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಮಟ್ಟದ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಿ) ಈ ಕೆಳಗಿನ ಯೋಜನೆಯ ಪ್ರಕಾರ ಕೆಲಸ ಮಾಡಿರಬೇಕು:

ಕಾರ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಕಸ್ಟಮ್ RedHat ಅಸೆಂಬ್ಲಿ SNAT ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಮತ್ತು ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಒಂದೇ IP ವಿಳಾಸದಿಂದ ಕಳುಹಿಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು SNAT ಅನ್ನು ಬಳಸಲು ಯೋಜಿಸಿದ್ದೇವೆ, ಇಲ್ಲದಿದ್ದರೆ ನಾವು ಈ ಕೆಳಗಿನ ಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವರ್ಚುವಲ್ ಐಪಿ (ವಿಐಪಿ) ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದ ನಂತರ, ವಿಐಪಿಯಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಬ್ಯಾಕ್‌ಅಪ್‌ಗೆ ಕಳುಹಿಸಲಾದ ಸೆಷನ್‌ಗಳಿಗಾಗಿ ಇದು ಐಪಿ 2 ನಿಂದ ಬರುತ್ತದೆ. ಒಂದು ಪರಿಹಾರ ಕಂಡುಬಂದಿದೆ: ಕೆಳಗೆ ತೋರಿಸಿರುವಂತೆ ಬ್ಯಾಕ್‌ಅಪ್‌ನಲ್ಲಿ ಮತ್ತೊಂದು ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಎರಡು TM ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ನೆಟ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು:

ಸೆಟ್ಟಿಂಗ್ಗಳು

ನಾವು ICAP, SMTP, TCP 9100 ಸೇವೆಗಳೊಂದಿಗೆ ಎರಡು ಸರ್ವರ್‌ಗಳ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ.

ನಾವು ಎರಡು RHEL6 ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇವುಗಳಿಂದ ಪ್ರಮಾಣಿತ ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ಕೆಲವು ಪ್ಯಾಕೇಜುಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ.

ನಾವು ಸಮತೋಲನಗೊಳಿಸಬೇಕಾದ ಸೇವೆಗಳು:

• ICAP - tcp 1344;

• SMTP – tcp 25.

DM ನಿಂದ ಟ್ರಾಫಿಕ್ ಟ್ರಾನ್ಸ್ಮಿಷನ್ ಸೇವೆ - tcp 9100.

ಮೊದಲಿಗೆ, ನಾವು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಯೋಜಿಸಬೇಕಾಗಿದೆ.

ವರ್ಚುವಲ್ ಐಪಿ ವಿಳಾಸ (ವಿಐಪಿ):

• IP: 10.20.20.105.

ಸರ್ವರ್ TM6_1:

• ಬಾಹ್ಯ IP: 10.20.20.101;

• ಆಂತರಿಕ IP: 192.168.1.101.

ಸರ್ವರ್ TM6_2:

• ಬಾಹ್ಯ IP: 10.20.20.102;

• ಆಂತರಿಕ IP: 192.168.1.102.

ನಂತರ ನಾವು ಎರಡು TM ಸರ್ವರ್‌ಗಳಲ್ಲಿ IP ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ. ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು RedHat ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ ಇಲ್ಲಿ.

ನಾವು ಹೊಂದಿರುವ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ ಮತ್ತು ಯಾವುದು ಬ್ಯಾಕಪ್ ಆಗಿರಬೇಕು ಎಂಬುದನ್ನು ನಾವು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ಮಾಸ್ಟರ್ TM6_1 ಆಗಿರಲಿ, ಬ್ಯಾಕಪ್ TM6_2 ಆಗಿರಲಿ.

ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ ನಾವು ಹೊಸ ಬ್ಯಾಲೆನ್ಸರ್ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಮತ್ತು ರೂಟಿಂಗ್ ನಿಯಮಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ:

[root@tm6_2 ~]echo 101 balancer >> /etc/iproute2/rt_tables
[root@tm6_2 ~]ip rule add from 192.168.1.102 table balancer
[root@tm6_2 ~]ip route add default via 192.168.1.101 table balancer

ಸಿಸ್ಟಮ್ ರೀಬೂಟ್ ಆಗುವವರೆಗೆ ಮೇಲಿನ ಆಜ್ಞೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ ಮಾರ್ಗಗಳನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನೀವು ಅವುಗಳನ್ನು ನಮೂದಿಸಬಹುದು /etc/rc.d/rc.local, ಆದರೆ ಸೆಟ್ಟಿಂಗ್ಸ್ ಫೈಲ್ ಮೂಲಕ ಉತ್ತಮವಾಗಿದೆ /etc/sysconfig/network-scripts/route-eth1 (ಗಮನಿಸಿ: ವಿಭಿನ್ನ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಇಲ್ಲಿ ಬಳಸಲಾಗಿದೆ).

ಎರಡೂ TM ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕೀಪ್‌ಅಲೈವ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ. ನಾವು rpmfind.net ಅನ್ನು ವಿತರಣಾ ಮೂಲವಾಗಿ ಬಳಸಿದ್ದೇವೆ:

[root@tm6_1 ~]#yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/keepalived-1.2.13-5.el6_6.x86_64.rpm

ಕೀಪ್ಲೈವ್ಡ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ, ನಾವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾಸ್ಟರ್‌ನಂತೆ, ಇನ್ನೊಂದನ್ನು ಬ್ಯಾಕಪ್‌ನಂತೆ ನಿಯೋಜಿಸುತ್ತೇವೆ. ನಂತರ ನಾವು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ಗಾಗಿ ವಿಐಪಿ ಮತ್ತು ಸೇವೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ. ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿ ಇದೆ: /etc/keepalived/keepalived.conf.

TM1 ಸರ್ವರ್‌ಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state MASTER 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 151 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

virtual_server 10.20.20.105 1344 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 1344 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 1344
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 25 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 25 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 25
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

virtual_server 10.20.20.105 9100 {
    delay_loop 6
    lb_algo wrr 
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.101 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }

    real_server 192.168.1.102 9100 {
        weight 1
        TCP_CHECK { 
                connect_timeout 3 
            connect_port 9100
        nb_get_retry 3
        delay_before_retry 3
        }
    }
}

TM2 ಸರ್ವರ್‌ಗಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು

vrrp_sync_group VG1 { 
   group { 
      VI_1 
   } 
} 
vrrp_instance VI_1 { 
        state BACKUP 
        interface eth0 

        lvs_sync_daemon_inteface eth0 
        virtual_router_id 51 
        priority 100 
        advert_int 1 
        authentication { 
                auth_type PASS 
                auth_pass example 
        } 

        virtual_ipaddress { 
                10.20.20.105 
        } 
}

ನಾವು ಮಾಸ್ಟರ್‌ನಲ್ಲಿ LVS ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ, ಅದು ಸಂಚಾರವನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತದೆ. ಎರಡನೇ ಸರ್ವರ್‌ಗೆ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಕೇವಲ ಎರಡು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

[root@tm6_1 ~]##yum install https://rpmfind.net/linux/centos/6.10/os/x86_64/Packages/ipvsadm-1.26-4.el6.x86_64.rpm

ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಕೀಪಲೈವ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ನಾವು ಈಗಾಗಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ.

ಚಿತ್ರವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು, ಎರಡೂ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸ್ವಯಂಪ್ರಾರಂಭಕ್ಕೆ ಕೀಪಲೈವ್ ಅನ್ನು ಸೇರಿಸೋಣ:

[root@tm6_1 ~]#chkconfig keepalived on

ತೀರ್ಮಾನಕ್ಕೆ

ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ

ಎರಡೂ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕೀಪ್‌ಅಲೈಡ್‌ನಲ್ಲಿ ರನ್ ಮಾಡೋಣ:

service keepalived start

VRRP ವರ್ಚುವಲ್ ವಿಳಾಸದ ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ

ವಿಐಪಿ ಮಾಸ್ಟರ್‌ನಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳೋಣ:

ಮತ್ತು ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ ಯಾವುದೇ ವಿಐಪಿ ಇಲ್ಲ:

ಪಿಂಗ್ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ವಿಐಪಿ ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

ಈಗ ನೀವು ಮಾಸ್ಟರ್ ಅನ್ನು ಮುಚ್ಚಬಹುದು ಮತ್ತು ಆಜ್ಞೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಬಹುದು ping.

ಫಲಿತಾಂಶವು ಒಂದೇ ಆಗಿರಬೇಕು ಮತ್ತು ಬ್ಯಾಕಪ್‌ನಲ್ಲಿ ನಾವು ವಿಐಪಿಯನ್ನು ನೋಡುತ್ತೇವೆ:

ಸೇವೆಯ ಸಮತೋಲನವನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ

ಉದಾಹರಣೆಗೆ SMTP ತೆಗೆದುಕೊಳ್ಳೋಣ. 10.20.20.105 ಗೆ ಎರಡು ಸಂಪರ್ಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರಾರಂಭಿಸೋಣ:

telnet 10.20.20.105 25

ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಎರಡೂ ಸಂಪರ್ಕಗಳು ಸಕ್ರಿಯವಾಗಿವೆ ಮತ್ತು ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಗೊಂಡಿವೆ ಎಂದು ನಾವು ನೋಡಬೇಕು:

[root@tm6_1 ~]#watch ipvsadm –Ln

ಹೀಗಾಗಿ, ನಾವು TM ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮೂಲಕ TM ಸೇವೆಗಳ ದೋಷ-ಸಹಿಷ್ಣು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಾಗಿ, ಇದು TM ಮೇಲಿನ ಲೋಡ್ ಅನ್ನು ಅರ್ಧದಷ್ಟು ಕಡಿಮೆಗೊಳಿಸಿತು, ಇದು ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಕೊರತೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಈ ಪರಿಹಾರವನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಹೆಚ್ಚುವರಿ ವೆಚ್ಚವಿಲ್ಲದೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಸಂರಚನೆಯಲ್ಲಿ ಹಲವಾರು ಮಿತಿಗಳು ಮತ್ತು ತೊಂದರೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, UDP ದಟ್ಟಣೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುವಾಗ.

ಮೂಲ: www.habr.com