จะทำอย่างไรถ้าพลังของเซิร์ฟเวอร์เดียวไม่เพียงพอที่จะประมวลผลคำขอทั้งหมด และผู้ผลิตซอฟต์แวร์ไม่ได้จัดให้มีการทำโหลดบาลานซ์ มีตัวเลือกมากมาย ตั้งแต่การซื้อโหลดบาลานเซอร์ไปจนถึงการจำกัดจำนวนคำขอ อันไหนถูกต้องต้องพิจารณาจากสถานการณ์โดยคำนึงถึงเงื่อนไขที่มีอยู่ด้วย ในบทความนี้ เราจะบอกคุณว่าคุณสามารถทำอะไรได้บ้างหากมีงบประมาณจำกัดและคุณมีเซิร์ฟเวอร์ฟรี

เนื่องจากเป็นระบบที่จำเป็นในการลดภาระบนเซิร์ฟเวอร์ตัวใดตัวหนึ่ง เราจึงเลือก DLP (ระบบป้องกันการรั่วไหลของข้อมูล) จาก InfoWatch คุณลักษณะของการนำไปใช้งานคือการวางฟังก์ชันบาลานเซอร์บนเซิร์ฟเวอร์ "การต่อสู้" ตัวใดตัวหนึ่ง

ปัญหาหนึ่งที่เราพบคือการไม่สามารถใช้ Source NAT (SNAT) ได้ เหตุใดจึงจำเป็นและวิธีแก้ปัญหาเราจะอธิบายเพิ่มเติม

ดังนั้น ในตอนแรก แผนภาพลอจิคัลของระบบที่มีอยู่มีลักษณะดังนี้:

การรับส่งข้อมูล ICAP, SMTP, เหตุการณ์จากคอมพิวเตอร์ของผู้ใช้ได้รับการประมวลผลบนเซิร์ฟเวอร์ Traffic Monitor (TM) ในเวลาเดียวกัน เซิร์ฟเวอร์ฐานข้อมูลสามารถรับมือกับโหลดได้อย่างง่ายดายหลังจากประมวลผลเหตุการณ์บน TM แต่โหลดบน TM เองก็มีปริมาณมาก สิ่งนี้เห็นได้จากลักษณะของคิวข้อความบนเซิร์ฟเวอร์ Device Monitor (DM) รวมถึงจากโหลด CPU และหน่วยความจำบน TM

เมื่อมองแวบแรก ถ้าเราเพิ่มเซิร์ฟเวอร์ TM อื่นในโครงการนี้ ก็สามารถเปลี่ยน ICAP หรือ DM ไปเป็นเซิร์ฟเวอร์ดังกล่าวได้ แต่เราตัดสินใจว่าจะไม่ใช้วิธีนี้ เนื่องจากความทนทานต่อข้อผิดพลาดลดลง

คำอธิบายของโซลูชัน

ในกระบวนการค้นหาโซลูชันที่เหมาะสม เราได้ตัดสินใจเลือกซอฟต์แวร์ที่เผยแพร่อย่างเสรี รักษาชีวิต ร่วมกับ LVS. เนื่องจาก Keepalived แก้ปัญหาในการสร้างคลัสเตอร์ Failover และยังสามารถจัดการ LVS Balancer ได้อีกด้วย

สิ่งที่เราต้องการบรรลุผล (ลดภาระบน TM และรักษาระดับความทนทานต่อข้อผิดพลาดในปัจจุบัน) ควรใช้งานได้ตามรูปแบบต่อไปนี้:

เมื่อตรวจสอบฟังก์ชันการทำงานปรากฎว่าชุดประกอบ RedHat แบบกำหนดเองที่ติดตั้งบนเซิร์ฟเวอร์ไม่รองรับ SNAT ในกรณีของเรา เราวางแผนที่จะใช้ SNAT เพื่อให้แน่ใจว่าแพ็กเก็ตขาเข้าและการตอบกลับจะถูกส่งจากที่อยู่ IP เดียวกัน มิฉะนั้น เราจะได้ภาพต่อไปนี้:

นี่เป็นที่ยอมรับไม่ได้ ตัวอย่างเช่น พร็อกซีเซิร์ฟเวอร์ที่ส่งแพ็กเก็ตไปยังที่อยู่ IP เสมือน (VIP) จะคาดหวังการตอบกลับจาก VIP แต่ในกรณีนี้จะมาจาก IP2 สำหรับเซสชันที่ส่งไปยังการสำรองข้อมูล พบวิธีแก้ปัญหา: จำเป็นต้องสร้างตารางเส้นทางอื่นในการสำรองข้อมูลและเชื่อมต่อเซิร์ฟเวอร์ TM สองตัวกับเครือข่ายที่แยกจากกัน ดังที่แสดงด้านล่าง:

การตั้งค่า

เราจะใช้โครงร่างของเซิร์ฟเวอร์สองตัวที่มีบริการ ICAP, SMTP, TCP 9100 และติดตั้งโหลดบาลานเซอร์ไว้ในหนึ่งในนั้น

เรามีเซิร์ฟเวอร์ RHEL6 สองเครื่อง ซึ่งพื้นที่เก็บข้อมูลมาตรฐานและแพ็คเกจบางส่วนได้ถูกลบออกไปแล้ว

บริการที่เราต้องสร้างสมดุล:

• ไอแคป – TCP 1344;

• SMTP – TCP 25

บริการส่งสัญญาณจราจรจาก DM – tcp 9100

ขั้นแรกเราต้องวางแผนเครือข่าย

ที่อยู่ IP เสมือน (วีไอพี):

• 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/เครือข่ายสคริปต์/เส้นทาง-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

ข้อสรุป

ตรวจสอบผลลัพธ์

มาเรียกใช้ Keepalive บนเซิร์ฟเวอร์ทั้งสองกัน:

service keepalived start

การตรวจสอบความพร้อมใช้งานของที่อยู่เสมือน VRRP

มาตรวจสอบให้แน่ใจว่า 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

ที่มา: will.com