תוכן
מבוא
A שרת proxy ניתן לתאר כמכשיר או יישום שרתים אשר מבצעים תיווך לבקשות של לקוחות או לקוחות המנסים לחפש משאבים מכמה שרתים המספקים את אלה. לפי ההסבר, פירוש הדבר ששרת proxy פועל בשמו של הלקוח או הלקוח כאשר מתבקש השירות, ואולי מסתיר את המקור האמיתי או מקור הבקשה לשרת.
התהליך הוא שהלקוח מגיש את הבקשה ישירות לשרת ה- proxy, במקום להתחבר רק לשרת קונקרטי שיכול לספק משאב מבוקש, כמו קבצים או קורים, ואז שרת ה- proxy מעריך את הבקשה הזו ומפתח את הרשת המתאימה והנדרשת עסקאות. זוהי דרך להפוך את מורכבות הבקשה לפשוטה או מבוקרת יותר, וחוץ מזה היא מספקת יתרונות אחרים כגון אבטחה, האצת תוכן או פרטיות. פרוקסי מתוכננים להכיל ולבנות את המערכות המבוזרות הקיימות. חלק מסמכני הניווט באינטרנט הנפוצים ביותר הם דְיוֹנוֹן, פרטיוקסי, או SwiperProxy.
לפעמים שרת proxy אינו מספיק בכדי לנהל את מספר המשתמשים במקביל או ש- proxy עצמו הוא a נקודת כשל יחידה שצריך לטפל בזה, כאשר ADC נדרש לחלוטין.
המאמר הבא מתאר דרך ליצור זמינות גבוהה ומדרגיות עבור שירות proxy ניווט, במקרה שאחד משרתי ה- Proxy נכשל אז מאזן העומסים, המיושם באמצעות בקר ZEVENET Application Delivery, יזהה את הכשל וה- proxy יושבת. מאגר זמין, בנוסף, הלקוח ינותב ל- proxy ניווט זמין אחר מבלי להשפיע על חיבורי התנועה.
ארכיטקטורת רשת פרוקסי
מתוך רעיון לגרום לקורא להבין טוב יותר את התצורה, אנו רוצים להגיע לתרשים הבא המתאר את הארכיטקטורה.
לקוחות שונים (מחשבים ניידים, מחשבים ניידים וטאבלטים) מגדירים את דפדפן הניווט המצביע על ה- proxy התאגידי, למשל https://proxy.company.com:3128. כל החיבורים מהלקוחות לפרוקסי הניווט באינטרנט בפשטות HTTP or SSL יהיה TCP מבוסס, כך שזה ישמש לבניית החווה שלנו לאיזון עומסים.
רזולוציית ה- IP עבור proxy.company.com הוא IP וירטואלי כבר מוגדר במאזן העומסים. בבקר מסירת היישומים של ZEVENET, יש חווה מעל IP וירטואלי כזה, למשל 192.168.103.34 ונמל וירטואלי 3128 in NAT מצב עבור TCP פרוטוקול.
החווה מוגדרת עם כל התומכים הבונים את מאגר ה- proxy לניווט, בדוגמה שלנו 192.168.103.253 ו 192.168.103.254 דרך יציאת TCP 3128. ברגע שהלקוח ינסה להתחבר לפרוקסי שהוגדר, ה- ADC יקבל את החיבור והוא יופנה לאחד ממוקדי הניווט הזמינים בבריכה שישתף את המשתמשים בין כל שרתי ה- proxy של backend הזמינים.
הסעיף הבא מתאר את הליך התצורה במטרה ליצור תצורה נכונה עבור מאפייני ניווט באיזון עומסים במאזן עומסים של ZEVENET.
ראשית, צור בדיקת בריאות לשימוש בחווה לאיזון עומסים אותה אנו עומדים ליצור בשורות הבאות. מטרת בדיקת הבריאות החדשה הזו היא לוודא כי יציאת ה- TCP במוקדי ה- backend מופעלת.
עבור לקטע פיקוח> אפוטרופוס החווה, צור שומר חווה חדש עם שם check_tcp_navigation_proxy ולהעתיק מ check_tcp ובצע כמה שינויים קטנים בפסקי הזמן כפי שמוצג להלן:
ב פיקוד שדה הוסף את הדגל -5, זה פסק הזמן לכל backend על מנת להגיב לחיבור TCP ממאזנת העומס. ה הפסקה שדה מוגדר לערך של 11, 5 שניות לכל backend + שנייה נוספת אחת כדי למנוע רקורסיה. אנו ממליצים להשתמש בנוסחה הבאה כדי להגדיר את האופטימלי הפסקה ערך.
(number of backends * timeout seconds per backend (-t) ) + 1
ואז, צור א LSLB> L4xNAT חוות, למשל עם השם ניווט_פרוקסי, ובכלל זה IP וירטואלי ו יציאה וירטואלית כפי שצוין בתרשים הקודם. ברגע שהוא נוצר, עבור לערוך ב- מתקדם מצב וודא זאת סוג פרוטוקול מוגדר ב TCP ו סוג NAT מוגדר ב NAT מצב.
על מנת להגדיר את התנהגות השירות הווירטואלי, עבור לכרטיסייה שירותים והגדר את אלגוריתם איזון העומס ב- מִשׁקָל (כברירת מחדל). אנא התאם ערך זה למתאים ביותר לסביבתך ולהתנהגות הרצויה.
ואז, באותו חלק, עבור לשולחן Backends והוסף את שרתי ה- proxy האמיתיים לניווט באינטרנט שינהל את חיבורי המשתמש.
לבסוף, בחר את בדיקת הבריאות שכבר נוצרה בשלב הקודם ששמו check_tcp_navigation_proxy על מנת לוודא שה- TCP יציאת backend כבר נפתחה.
כעת ניתן לבדוק את השירות הווירטואלי המאוזן לפני הגדרת הלקוחות.
תצורת הלקוחות
השלב האחרון הוא להגדיר את הגדרות ה- proxy בדפדפן האינטרנט של הלקוח המפנות אל ה- IP וירטואלי ו יציאה וירטואלית משמש לאיזון עומסים, או להציג את IP וירטואלי בקואופרטיב DNS והשתמש ב- שם במקום אצל הלקוחות, בדוגמה שלנו proxy.example.com הוא הצביע על ה- IP הווירטואלי 192.168.103.34).
לבסוף, תיהנו מפרוקסי ניווט אתרים מאוזן בעומס עם זמינות גבוהה!