რა უნდა გააკეთოს, თუ ერთი სერვერის სიმძლავრე არ არის საკმარისი ყველა მოთხოვნის დასამუშავებლად და პროგრამული უზრუნველყოფის მწარმოებელი არ უზრუნველყოფს დატვირთვის დაბალანსებას? ბევრი ვარიანტია, დატვირთვის ბალანსერის შეძენიდან მოთხოვნის რაოდენობის შეზღუდვამდე. რომელია სწორი, სიტუაციით უნდა დადგინდეს არსებული პირობების გათვალისწინებით. ამ სტატიაში ჩვენ გეტყვით რა შეგიძლიათ გააკეთოთ, თუ თქვენი ბიუჯეტი შეზღუდულია და გაქვთ უფასო სერვერი.

როგორც სისტემა, რომლისთვისაც საჭირო იყო ერთ-ერთ სერვერზე დატვირთვის შემცირება, InfoWatch-დან ავირჩიეთ DLP (ინფორმაციის გაჟონვის პრევენციის სისტემა). განხორციელების მახასიათებელი იყო ბალანსის ფუნქციის განთავსება ერთ-ერთ "საბრძოლო" სერვერზე.

ერთ-ერთი პრობლემა, რომელიც შეგვხვდა, იყო Source NAT-ის (SNAT) გამოყენების შეუძლებლობა. რატომ იყო ეს საჭირო და როგორ მოგვარდა პრობლემა, შემდგომში განვიხილავთ.

ასე რომ, თავდაპირველად არსებული სისტემის ლოგიკური დიაგრამა ასე გამოიყურებოდა:

ICAP ტრაფიკი, SMTP, მოვლენები მომხმარებლის კომპიუტერებიდან დამუშავდა Traffic Monitor (TM) სერვერზე. ამავდროულად, მონაცემთა ბაზის სერვერი ადვილად უმკლავდებოდა დატვირთვას TM-ზე მოვლენების დამუშავების შემდეგ, მაგრამ დატვირთვა თავად TM-ზე იყო მძიმე. ეს აშკარა იყო მოწყობილობის მონიტორის (DM) სერვერზე შეტყობინებების რიგის გამოჩენიდან, ასევე TM-ზე CPU და მეხსიერების დატვირთვიდან.

ერთი შეხედვით, თუ ამ სქემას დავამატებთ სხვა TM სერვერს, მასზე შეიძლება გადაერთოთ ან ICAP ან DM, მაგრამ გადავწყვიტეთ არ გამოგვეყენებინა ეს მეთოდი, რადგან შემცირდა შეცდომის ტოლერანტობა.

ხსნარის აღწერა

შესაბამისი გადაწყვეტის ძიების პროცესში ჩვენ თავისუფლად გავრცელებულ პროგრამულ უზრუნველყოფაზე დავბინავდით ინახება ერთად LVS. იმის გამო, რომ keepalived აგვარებს ფაილვერის კლასტერის შექმნის პრობლემას და ასევე შეუძლია მართოს LVS ბალანსერი.

რისი მიღწევა გვინდოდა (TM-ზე დატვირთვის შემცირება და ხარვეზების ტოლერანტობის მიმდინარე დონის შენარჩუნება) უნდა გვემუშავა შემდეგი სქემის მიხედვით:

ფუნქციონირების შემოწმებისას აღმოჩნდა, რომ სერვერებზე დაყენებული მორგებული RedHat ასამბლეა არ უჭერს მხარს SNAT-ს. ჩვენს შემთხვევაში, ჩვენ ვგეგმავდით SNAT-ის გამოყენებას იმის უზრუნველსაყოფად, რომ შემომავალი პაკეტები და მათზე პასუხები იგზავნება იმავე IP მისამართიდან, წინააღმდეგ შემთხვევაში მივიღებდით შემდეგ სურათს:

ეს მიუღებელია. მაგალითად, პროქსი სერვერი, რომელმაც გაგზავნა პაკეტები ვირტუალურ IP (VIP) მისამართზე, მოელის პასუხს VIP-ისგან, მაგრამ ამ შემთხვევაში ის მოდის IP2-დან სარეზერვო ასლისთვის გაგზავნილი სესიებისთვის. იპოვეს გამოსავალი: საჭირო იყო სარეზერვო ასლის სხვა მარშრუტიზაციის ცხრილის შექმნა და ორი TM სერვერის დაკავშირება ცალკე ქსელთან, როგორც ეს ნაჩვენებია ქვემოთ:

პარამეტრები

ჩვენ განვახორციელებთ ორი სერვერის სქემას ICAP, SMTP, TCP 9100 სერვისებით და ერთ-ერთ მათგანზე დაინსტალირებული დატვირთვის ბალანსერით.

ჩვენ გვაქვს ორი RHEL6 სერვერი, საიდანაც ამოღებულია სტანდარტული საცავი და ზოგიერთი პაკეტი.

სერვისები, რომელთა დაბალანსება გვჭირდება:

• ICAP – tcp 1344;

• SMTP – tcp 25.

სატრანსპორტო გადაცემის სერვისი DM-დან – tcp 9100.

პირველ რიგში, ჩვენ უნდა დავგეგმოთ ქსელი.

ვირტუალური IP მისამართი (VIP):

• 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.

შემდეგ ჩვენ ვააქტიურებთ IP გადამისამართებას ორ TM სერვერზე. როგორ გავაკეთოთ ეს აღწერილია 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 (შენიშვნა: აქ გამოყენებულია სხვადასხვა სინტაქსი).

დააინსტალირეთ keepalived ორივე 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

Keepalived პარამეტრებში ჩვენ ერთ სერვერს ვანიჭებთ მთავარს, მეორეს სარეზერვო ასლს. შემდეგ დავაყენეთ VIP და სერვისები დატვირთვის დაბალანსებისთვის. პარამეტრების ფაილი ჩვეულებრივ მდებარეობს აქ: /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

ბალანსერს მართავს keepalived, რომელიც ჩვენ უკვე დავაკონფიგურირეთ.

სურათის დასასრულებლად, მოდით დავამატოთ keepalived ავტომატურ დაწყებას ორივე სერვერზე:

[root@tm6_1 ~]#chkconfig keepalived on

დასკვნა

შედეგების შემოწმება

მოდით გავუშვათ keepalived ორივე სერვერზე:

service keepalived start

VRRP ვირტუალური მისამართის ხელმისაწვდომობის შემოწმება

მოდით დავრწმუნდეთ, რომ VIP არის მასტერზე:

და არ არის VIP სარეზერვო ასლი:

ping ბრძანების გამოყენებით, ჩვენ შევამოწმებთ VIP-ის ხელმისაწვდომობას:

ახლა თქვენ შეგიძლიათ გამორთოთ მასტერი და კვლავ გაუშვათ ბრძანება ping.

შედეგი იგივე უნდა დარჩეს და სარეზერვო ასლის შემთხვევაში ვიხილავთ VIP-ს:

სერვისის ბალანსის შემოწმება

ავიღოთ მაგალითად SMTP. მოდით გავუშვათ ორი კავშირი ერთდროულად 10.20.20.105-თან:

telnet 10.20.20.105 25

მასტერზე უნდა დავინახოთ, რომ ორივე კავშირი აქტიურია და დაკავშირებულია სხვადასხვა სერვერებთან:

[root@tm6_1 ~]#watch ipvsadm –Ln

ამრიგად, ჩვენ განვახორციელეთ TM სერვისების შეცდომის ტოლერანტული კონფიგურაცია ერთ-ერთ TM სერვერზე ბალანსერის დაყენებით. ჩვენი სისტემისთვის ამან შეამცირა TM-ზე დატვირთვა ნახევრად, რამაც შესაძლებელი გახადა სისტემის გამოყენებით ჰორიზონტალური სკალირების ნაკლებობის პრობლემის მოგვარება.

უმეტეს შემთხვევაში, ეს გამოსავალი ხორციელდება სწრაფად და დამატებითი ხარჯების გარეშე, მაგრამ ზოგჯერ არსებობს მთელი რიგი შეზღუდვები და სირთულეები კონფიგურაციაში, მაგალითად, UDP ტრაფიკის დაბალანსებისას.

წყარო: www.habr.com