מה לעשות אם כוחו של שרת אחד אינו מספיק לעיבוד כל הבקשות, ויצרן התוכנה אינו מספק איזון עומסים? ישנן אפשרויות רבות, החל מרכישת מאזן עומסים ועד הגבלת מספר הבקשות. מי מהם נכון חייב להיקבע לפי המצב, תוך התחשבות בתנאים הקיימים. במאמר זה נספר לכם מה תוכלו לעשות אם התקציב שלכם מוגבל ויש לכם שרת חינמי.

כמערכת שעבורה היה צורך להפחית את העומס על אחד השרתים, בחרנו ב-DLP (מערכת למניעת דליפת מידע) מבית InfoWatch. מאפיין של היישום היה מיקום פונקציית האיזון באחד משרתי ה"קרב".

אחת הבעיות שנתקלנו בהן הייתה חוסר היכולת להשתמש במקור NAT (SNAT). מדוע היה צורך בכך וכיצד נפתרה הבעיה, נתאר בהמשך.

אז בתחילה התרשים הלוגי של המערכת הקיימת נראה כך:

תעבורת ICAP, SMTP, אירועים ממחשבי משתמש עובדו בשרת Traffic Monitor (TM). יחד עם זאת, שרת מסד הנתונים התמודד בקלות עם העומס לאחר עיבוד אירועים ב-TM, אך העומס על ה-TM עצמו היה כבד. זה היה ברור מהופעת תור הודעות בשרת Device Monitor (DM), כמו גם מעומס המעבד והזיכרון ב-TM.

במבט ראשון, אם נוסיף שרת TM נוסף לסכימה זו, ניתן יהיה להחליף אליו ICAP או DM, אך החלטנו לא להשתמש בשיטה זו, מכיוון שסובלנות התקלות הופחתה.

תיאור הפתרון

בתהליך חיפוש אחר פתרון מתאים, הסתפקנו בתוכנה המופצת בחופשיות כל הזמן עם LVS. כי Keepalived פותר את הבעיה של יצירת אשכול failover ויכול גם לנהל את איזון 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 (הערה: כאן נעשה שימוש בתחביר שונה).

התקן את Keepalive בשני שרתי ה-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

בהגדרות Keepalive, אנו מקצים את אחד השרתים כמאסטר, את השני כגיבוי. לאחר מכן הגדרנו VIP ושירותים לאיזון עומסים. קובץ ההגדרות נמצא בדרך כלל כאן: /etc/keepalived/keepalived.conf.

הגדרות עבור TM1 Server

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 Server

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

האיזון ינוהל על ידי keepalved, שכבר הגדרנו.

כדי להשלים את התמונה, בואו נוסיף Keepalved להפעלה אוטומטית בשני השרתים:

[root@tm6_1 ~]#chkconfig keepalived on

מסקנה

בודק את התוצאות

בואו נריץ Keepalive בשני השרתים:

service keepalived start

בדיקת הזמינות של כתובת וירטואלית VRRP

בואו נוודא שה-VIP נמצא במאסטר:

ואין VIP בגיבוי:

באמצעות פקודת ping, נבדוק את זמינות ה-VIP:

כעת אתה יכול לכבות את מאסטר ולהפעיל את הפקודה שוב ping.

התוצאה צריכה להישאר זהה, ובגיבוי נראה VIP:

בדיקת איזון שירות

ניקח לדוגמא SMTP. בואו נשיק שני חיבורים ל-10.20.20.105 בו זמנית:

telnet 10.20.20.105 25

ב-master אנחנו אמורים לראות ששני החיבורים פעילים ומחוברים לשרתים שונים:

[root@tm6_1 ~]#watch ipvsadm –Ln

לפיכך, הטמענו תצורה סובלנית לתקלות של שירותי TM על ידי התקנת איזון באחד משרתי ה-TM. עבור המערכת שלנו, זה הפחית את העומס על TM בחצי, מה שאפשר לפתור את בעיית היעדר קנה מידה אופקי באמצעות המערכת.

ברוב המקרים פתרון זה מיושם במהירות וללא עלויות נוספות, אך לעיתים ישנן מספר מגבלות וקשיים בתצורה, למשל בעת איזון תעבורת UDP.

מקור: www.habr.com