அனைத்து கோரிக்கைகளையும் செயல்படுத்த ஒரு சேவையகத்தின் சக்தி போதுமானதாக இல்லாவிட்டால், மென்பொருள் உற்பத்தியாளர் சுமை சமநிலையை வழங்கவில்லை என்றால் என்ன செய்வது? சுமை பேலன்சரை வாங்குவது முதல் கோரிக்கைகளின் எண்ணிக்கையைக் கட்டுப்படுத்துவது வரை பல விருப்பங்கள் உள்ளன. எது சரியானது என்பதை, தற்போதுள்ள நிலைமைகளை கணக்கில் எடுத்துக்கொண்டு, சூழ்நிலையால் தீர்மானிக்கப்பட வேண்டும். உங்கள் பட்ஜெட் குறைவாகவும், இலவச சர்வர் இருந்தால் என்ன செய்ய முடியும் என்பதை இந்தக் கட்டுரையில் கூறுவோம்.

ஒரு சேவையகத்தின் சுமையைக் குறைக்க வேண்டிய ஒரு அமைப்பாக, InfoWatch இலிருந்து DLP (தகவல் கசிவு தடுப்பு அமைப்பு) ஐத் தேர்ந்தெடுத்தோம். செயல்படுத்தலின் ஒரு அம்சம் "போர்" சேவையகங்களில் ஒன்றில் பேலன்சர் செயல்பாட்டை வைப்பதாகும்.

நாங்கள் சந்தித்த பிரச்சனைகளில் ஒன்று, Source NAT (SNAT) ஐப் பயன்படுத்த இயலாமை. இது ஏன் தேவைப்பட்டது மற்றும் பிரச்சனை எவ்வாறு தீர்க்கப்பட்டது, மேலும் விவரிப்போம்.

எனவே, ஆரம்பத்தில் இருக்கும் அமைப்பின் தருக்க வரைபடம் இப்படி இருந்தது:

ICAP ட்ராஃபிக், SMTP, பயனர் கணினிகளில் இருந்து நிகழ்வுகள் டிராஃபிக் மானிட்டர் (TM) சர்வரில் செயலாக்கப்பட்டன. அதே நேரத்தில், தரவுத்தள சேவையகம் TM இல் நிகழ்வுகளைச் செயலாக்கிய பிறகு சுமைகளை எளிதில் சமாளித்தது, ஆனால் TM இல் சுமை அதிகமாக இருந்தது. டிவைஸ் மானிட்டர் (டிஎம்) சர்வரில் ஒரு செய்தி வரிசையின் தோற்றம் மற்றும் TM இல் உள்ள CPU மற்றும் மெமரி லோட் ஆகியவற்றிலிருந்து இது தெளிவாகத் தெரிகிறது.

முதல் பார்வையில், இந்த திட்டத்தில் மற்றொரு TM சேவையகத்தைச் சேர்த்தால், ICAP அல்லது DM ஐ அதற்கு மாற்றலாம், ஆனால் தவறு சகிப்புத்தன்மை குறைக்கப்பட்டதால், இந்த முறையைப் பயன்படுத்த வேண்டாம் என்று முடிவு செய்தோம்.

தீர்வு விளக்கம்

பொருத்தமான தீர்வைத் தேடும் செயல்பாட்டில், நாங்கள் இலவசமாக விநியோகிக்கப்பட்ட மென்பொருளில் குடியேறினோம் உயிருடன் ஒன்றாக எல்.வி.எஸ். ஏனெனில் Keepalived ஒரு ஃபெயில்ஓவர் கிளஸ்டரை உருவாக்கும் சிக்கலை தீர்க்கிறது மற்றும் LVS பேலன்சரையும் நிர்வகிக்க முடியும்.

நாம் எதை அடைய விரும்பினோம் (டிஎம்மில் சுமையைக் குறைத்து, தற்போதைய தவறு சகிப்புத்தன்மையை பராமரிக்கவும்) பின்வரும் திட்டத்தின்படி செயல்பட்டிருக்க வேண்டும்:

செயல்பாட்டைச் சரிபார்க்கும்போது, ​​சேவையகங்களில் நிறுவப்பட்ட தனிப்பயன் RedHat அசெம்பிளி SNAT ஐ ஆதரிக்கவில்லை என்று மாறியது. எங்கள் விஷயத்தில், உள்வரும் பாக்கெட்டுகள் மற்றும் அவற்றுக்கான பதில்கள் ஒரே ஐபி முகவரியிலிருந்து அனுப்பப்படுவதை உறுதிசெய்ய SNAT ஐப் பயன்படுத்த திட்டமிட்டுள்ளோம், இல்லையெனில் பின்வரும் படத்தைப் பெறுவோம்:

இது ஏற்றுக்கொள்ள முடியாதது. எடுத்துக்காட்டாக, விர்ச்சுவல் ஐபி (விஐபி) முகவரிக்கு பாக்கெட்டுகளை அனுப்பிய ப்ராக்ஸி சேவையகம், விஐபியிடமிருந்து பதிலை எதிர்பார்க்கும், ஆனால் இந்தச் சந்தர்ப்பத்தில் காப்புப்பிரதிக்கு அனுப்பப்படும் அமர்வுகளுக்கு IP2 இலிருந்து வரும். ஒரு தீர்வு காணப்பட்டது: காப்புப்பிரதியில் மற்றொரு ரூட்டிங் அட்டவணையை உருவாக்குவது மற்றும் கீழே காட்டப்பட்டுள்ளபடி இரண்டு டிஎம் சேவையகங்களை தனி நெட்வொர்க்குடன் இணைக்க வேண்டியது அவசியம்:

அமைப்புகளை

ICAP, SMTP, TCP 9100 சேவைகள் மற்றும் அவற்றில் ஒன்றில் நிறுவப்பட்ட லோட் பேலன்சர் கொண்ட இரண்டு சேவையகங்களின் திட்டத்தை நாங்கள் செயல்படுத்துவோம்.

எங்களிடம் இரண்டு RHEL6 சேவையகங்கள் உள்ளன, அதில் இருந்து நிலையான களஞ்சியங்கள் மற்றும் சில தொகுப்புகள் அகற்றப்பட்டுள்ளன.

நாம் சமநிலைப்படுத்த வேண்டிய சேவைகள்:

• ICAP - tcp 1344;

• SMTP – tcp 25.

DM - tcp 9100 இலிருந்து போக்குவரத்து பரிமாற்ற சேவை.

முதலில், நாம் பிணையத்தை திட்டமிட வேண்டும்.

மெய்நிகர் ஐபி முகவரி (விஐபி):

• ஐபி: 10.20.20.105.

சர்வர் TM6_1:

• வெளிப்புற ஐபி: 10.20.20.101;

• உள் ஐபி: 192.168.1.101.

சர்வர் TM6_2:

• வெளிப்புற ஐபி: 10.20.20.102;

• உள் ஐபி: 192.168.1.102.

இரண்டு டிஎம் சேவையகங்களில் ஐபி பகிர்தலை இயக்குகிறோம். இதை எப்படி செய்வது என்பது 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 சேவையகங்களிலும் Keepalived ஐ நிறுவவும். விநியோக ஆதாரமாக 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

Keepalived அமைப்புகளில், சேவையகங்களில் ஒன்றை முதன்மையாகவும், மற்றொன்றை காப்புப்பிரதியாகவும் ஒதுக்குகிறோம். சுமை சமநிலைக்கு விஐபி மற்றும் சேவைகளை அமைக்கிறோம். அமைப்புகள் கோப்பு பொதுவாக இங்கே அமைந்துள்ளது: /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 
        } 
}

ட்ராஃபிக்கை சமன் செய்யும் மாஸ்டரில் எல்விஎஸ் நிறுவுகிறோம். எங்களிடம் உள்ளமைவில் இரண்டு சேவையகங்கள் மட்டுமே இருப்பதால், இரண்டாவது சேவையகத்திற்கான பேலன்சரை நிறுவுவதில் அர்த்தமில்லை.

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

நாம் ஏற்கனவே கட்டமைத்த கீப்பாலைவ் மூலம் பேலன்சர் நிர்வகிக்கப்படும்.

படத்தை முடிக்க, இரண்டு சர்வர்களிலும் ஆட்டோஸ்டார்ட்டில் Keepalived ஐ சேர்ப்போம்:

[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