যদি একটি সার্ভারের শক্তি সমস্ত অনুরোধ প্রক্রিয়া করার জন্য যথেষ্ট না হয় এবং সফ্টওয়্যার প্রস্তুতকারক লোড ব্যালেন্সিং প্রদান না করে তবে কী করবেন? একটি লোড ব্যালেন্সার কেনা থেকে শুরু করে অনুরোধের সংখ্যা সীমিত করার জন্য অনেকগুলি বিকল্প রয়েছে৷ কোনটি সঠিক তা অবশ্যই বিদ্যমান পরিস্থিতি বিবেচনা করে পরিস্থিতি দ্বারা নির্ধারণ করা উচিত। এই নিবন্ধে আমরা আপনাকে বলব যে আপনার বাজেট সীমিত হলে এবং আপনার একটি বিনামূল্যে সার্ভার থাকলে আপনি কী করতে পারেন।

একটি সিস্টেম হিসাবে যার জন্য সার্ভারগুলির একটিতে লোড হ্রাস করা প্রয়োজন ছিল, আমরা InfoWatch থেকে DLP (তথ্য ফুটো প্রতিরোধ ব্যবস্থা) বেছে নিয়েছি। বাস্তবায়নের একটি বৈশিষ্ট্য ছিল "যুদ্ধ" সার্ভারগুলির একটিতে ব্যালেন্সার ফাংশন স্থাপন করা।

আমরা যে সমস্যার সম্মুখীন হয়েছিলাম তার মধ্যে একটি হল সোর্স NAT (SNAT) ব্যবহার করতে না পারা। কেন এটি প্রয়োজন ছিল এবং কীভাবে সমস্যাটি সমাধান করা হয়েছিল, আমরা আরও বর্ণনা করব।

সুতরাং, প্রাথমিকভাবে বিদ্যমান সিস্টেমের লজিক্যাল ডায়াগ্রামটি এইরকম দেখায়:

ICAP ট্র্যাফিক, SMTP, ব্যবহারকারী কম্পিউটার থেকে ইভেন্টগুলি ট্র্যাফিক মনিটর (TM) সার্ভারে প্রক্রিয়া করা হয়েছিল। একই সময়ে, ডাটাবেস সার্ভার টিএম-এ ইভেন্টগুলি প্রক্রিয়া করার পরে লোডের সাথে সহজেই মোকাবিলা করেছিল, তবে TM-তে লোড নিজেই ভারী ছিল। এটি ডিভাইস মনিটর (DM) সার্ভারে একটি বার্তা সারির উপস্থিতি, সেইসাথে TM-এ CPU এবং মেমরি লোড থেকে স্পষ্ট ছিল।

প্রথম নজরে, যদি আমরা এই স্কিমে অন্য TM সার্ভার যোগ করি, তাহলে হয় ICAP বা DM-এ স্যুইচ করা যেতে পারে, কিন্তু আমরা এই পদ্ধতিটি ব্যবহার না করার সিদ্ধান্ত নিয়েছি, যেহেতু ত্রুটি সহনশীলতা হ্রাস পেয়েছে৷

সমাধান বিবরণ

একটি উপযুক্ত সমাধান অনুসন্ধানের প্রক্রিয়ার মধ্যে, আমরা অবাধে বিতরণ করা সফ্টওয়্যারের উপর স্থির হয়েছি জীবিত রাখা একসাথে এলভিএস. কারণ Keepalived একটি ফেইলওভার ক্লাস্টার তৈরির সমস্যার সমাধান করে এবং LVS ব্যালেন্সার পরিচালনা করতে পারে।

আমরা যা অর্জন করতে চেয়েছিলাম (TM-এর উপর লোড কমাতে এবং ত্রুটি সহনশীলতার বর্তমান স্তর বজায় রাখতে) নিম্নলিখিত স্কিম অনুযায়ী কাজ করা উচিত ছিল:

কার্যকারিতা পরীক্ষা করার সময়, দেখা গেল যে সার্ভারে ইনস্টল করা কাস্টম RedHat সমাবেশ SNAT সমর্থন করে না। আমাদের ক্ষেত্রে, আগত প্যাকেট এবং তাদের প্রতিক্রিয়া একই IP ঠিকানা থেকে পাঠানো হয় তা নিশ্চিত করতে আমরা SNAT ব্যবহার করার পরিকল্পনা করেছি, অন্যথায় আমরা নিম্নলিখিত ছবি পাব:

এটা অগ্রহণযোগ্য. উদাহরণস্বরূপ, একটি প্রক্সি সার্ভার, একটি ভার্চুয়াল আইপি (ভিআইপি) ঠিকানায় প্যাকেট পাঠানোর পরে, ভিআইপি থেকে একটি প্রতিক্রিয়া আশা করবে, তবে এই ক্ষেত্রে এটি ব্যাকআপে পাঠানো সেশনগুলির জন্য আইপি2 থেকে আসবে৷ একটি সমাধান পাওয়া গেছে: ব্যাকআপে আরেকটি রাউটিং টেবিল তৈরি করা এবং দুটি টিএম সার্ভারকে একটি পৃথক নেটওয়ার্কের সাথে সংযুক্ত করা প্রয়োজন, যেমনটি নীচে দেখানো হয়েছে:

সেটিংস

আমরা 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।

তারপর আমরা দুটি টিএম সার্ভারে আইপি ফরওয়ার্ডিং সক্ষম করি। এটি কীভাবে করবেন তা রেডহ্যাটে বর্ণিত আছে এখানে.

আমরা স্থির করি যে আমাদের কাছে কোন সার্ভার থাকবে তা প্রধান এবং কোনটি ব্যাকআপ হবে। মাস্টারকে 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 ইনস্টল করুন। আমরা বিতরণ উত্স হিসাবে 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

ব্যালেন্সারটি Keepalived দ্বারা পরিচালিত হবে, যা আমরা ইতিমধ্যেই কনফিগার করেছি।

ছবি সম্পূর্ণ করতে, উভয় সার্ভারে অটোস্টার্টে Keepalived যোগ করা যাক:

[root@tm6_1 ~]#chkconfig keepalived on

উপসংহার

ফলাফল পরীক্ষা করা হচ্ছে

আসুন উভয় সার্ভারে Keepalived চালাই:

service keepalived start

একটি VRRP ভার্চুয়াল ঠিকানার উপলব্ধতা পরীক্ষা করা হচ্ছে

আসুন নিশ্চিত করি যে ভিআইপি মাস্টারে আছেন:

এবং ব্যাকআপে কোন ভিআইপি নেই:

পিং কমান্ড ব্যবহার করে, আমরা ভিআইপির উপলব্ধতা পরীক্ষা করব:

এখন আপনি মাস্টার বন্ধ করে আবার কমান্ড চালাতে পারেন ping.

ফলাফল একই থাকা উচিত, এবং ব্যাকআপে আমরা ভিআইপি দেখতে পাব:

পরিষেবার ভারসাম্য পরীক্ষা করা হচ্ছে

উদাহরণ স্বরূপ SMTP ধরা যাক। চলুন একসাথে 10.20.20.105 এ দুটি সংযোগ চালু করি:

telnet 10.20.20.105 25

মাস্টারে আমাদের দেখতে হবে যে উভয় সংযোগই সক্রিয় এবং বিভিন্ন সার্ভারের সাথে সংযুক্ত রয়েছে:

[root@tm6_1 ~]#watch ipvsadm –Ln

এইভাবে, আমরা TM সার্ভারগুলির একটিতে একটি ব্যালেন্সার ইনস্টল করে TM পরিষেবাগুলির একটি ত্রুটি-সহনশীল কনফিগারেশন বাস্তবায়ন করেছি৷ আমাদের সিস্টেমের জন্য, এটি টিএম-এর উপর অর্ধেক লোড কমিয়েছে, যা সিস্টেমটি ব্যবহার করে অনুভূমিক স্কেলিং এর অভাবের সমস্যা সমাধান করা সম্ভব করেছে।

বেশিরভাগ ক্ষেত্রে, এই সমাধানটি দ্রুত এবং অতিরিক্ত খরচ ছাড়াই প্রয়োগ করা হয়, তবে কখনও কখনও কনফিগারেশনে বেশ কয়েকটি সীমাবদ্ধতা এবং অসুবিধা রয়েছে, উদাহরণস্বরূপ, যখন UDP ট্র্যাফিকের ভারসাম্য বজায় রাখা হয়।

উত্স: www.habr.com