מבוא #

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

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

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

המאמר הבא מתאר דרך ליצירת זמינות גבוהה ומדרגיות עבור שירות פרוקסי ניווט. במקרה שאחד משרתי הפרוקסי נכשל, מאזן העומסים, הממומש באמצעות Relianoid Application Delivery Controller, יזהה את הכשל והפרוקסי יושבת במאגר הזמין. בנוסף, הלקוח ינותב לפרוקסי ניווט זמין אחר מבלי להשפיע על חיבורי התעבורה.

ארכיטקטורת רשת פרוקסי #

מתוך רעיון לגרום לקורא להבין טוב יותר את התצורה, אנו רוצים להגיע לתרשים הבא המתאר את הארכיטקטורה.

לקוחות שונים (מחשבים ניידים, מחשבים ניידים וטאבלטים) מגדירים את דפדפן הניווט כך שיפנה לפרוקסי התאגידי, לדוגמה https://proxy.company.com:3128 . כל החיבורים מהלקוחות לפרוקסי הניווט באינטרנט ב- HTTP או SSL רגילים יהיו מבוססי TCP , כך שזה ישמש לבניית חוות איזון העומסים שלנו.

רזולוציית ה-IP עבור proxy.company.com היא IP וירטואלי שכבר הוגדר במאזן העומסים. בבקר אספקת היישומים של Relianoid, יש חווה מעל IP וירטואלי כזה, לדוגמה 192.168.103.34 ופורט וירטואלי 3128 במצב NAT עבור פרוטוקול TCP.

החווה מוגדרת עם כל שרתי ה-backend שבונים את מאגר שרת ה-proxy של הניווט, בדוגמה שלנו 192.168.103.253 ו -192.168.103.254 דרך יציאת TCP 3128. ברגע שהלקוח ינסה להתחבר ל-proxy שהוגדר, ה-ADC יקבל את החיבור והוא ינותב לאחד משרתי ה-proxy של הניווט הזמינים במאגר, תוך שיתוף המשתמשים בין כל שרתי ה-backend הזמינים.

תצורת זמינות גבוהה של proxy לניווט אינטרנט #

הסעיף הבא מתאר את הליך התצורה על מנת ליצור תצורה מתאימה עבור שרתים פרוקסי ניווט של איזון עומסים במאזן העומסים של Relianoid.

בדיקת בריאות proxy לניווט אינטרנט #

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

עבור אל סעיף ניטור > שומר חווה , צור שומר חווה חדש עם השם check_tcp_navigation_proxy והעתק מ- check_tcp ובצע כמה שינויים קטנים בזמני הקצוב כפי שמוצג להלן:

בשדה הפקודה הוסיפו את הדגל -t 5 , זהו הזמן הקצוב לכל backend על מנת להגיב לחיבור ה-TCP ממאזן העומסים. שדה Interval מוגדר לערך של 11, 5 שניות לכל backend + שנייה נוספת אחת כדי למנוע רקורסיה. אנו ממליצים להשתמש בנוסחה הבאה כדי להגדיר את ערך Interval האופטימלי.

(מספר הקצה האחורי * שניות פסק זמן לכל קצה העורפי (-t) ) + 1

שירות וירטואלי של פרוקסי ניווט באינטרנט #

לאחר מכן, צרו חוות LSLB > L4xNAT , למשל בשם navigation_proxy , הכוללת את כתובת ה-IP הווירטואלית והפורט הווירטואלי כפי שמצוין בתרשים הקודם. לאחר יצירתה, גשו לעריכה במצב מתקדם וודאו שסוג הפרוטוקול מוגדר ב- TCP וסוג NAT מוגדר במצב NAT.

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

לאחר מכן, באותו מקטע, עבור לטבלה Backends והוסף את שרתי ה-proxy האמיתיים לניווט באינטרנט שינהלו את חיבורי המשתמש.

לבסוף, בחר את בדיקת התקינות שכבר נוצרה בשלב הקודם בשם check_tcp_navigation_proxy על מנת לוודא שפורט ה- TCP backend כבר פתוח.

כעת ניתן לבדוק את השירות הווירטואלי המאוזן לפני הגדרת הלקוחות.

תצורת הלקוחות #

השלב האחרון הוא להגדיר את הגדרות ה-proxy בדפדפן האינטרנט של הלקוח כך שיפנו לכתובת ה- IP הווירטואלית וליציאה הווירטואלית המשמשים במאזן העומסים, או להכניס את כתובת ה- IP הווירטואלית ב- DNS השיתופי ולהשתמש בשם במקום זאת בלקוחות. בדוגמה שלנו, proxy.example.com מופנה לכתובת ה-IP הווירטואלית 192.168.103.34.

לבסוף, תיהנו מפרוקסי ניווט אתרים מאוזן בעומס עם זמינות גבוהה!