מבוא #

בין ארבעת הסוגים של תרגום כתובות רשת (NAT) הנתמכים ב RELIANOID ADC, יש לנו מקור NAT (NAT), דינמי NAT(DNAT), החזרת שרת ישיר (DSR), ו DNAT חסר מדינהבמאמר זה, נעמיק במורכבויות של החזרת שרת ישירה (DSR), נבחן את הארכיטקטורה שלה, יתרונותיה ומכשולים פוטנציאליים. בנוסף, נגדיר DSR ב- Relianoid ADC.

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

זרימת תקשורת DSR #

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

אינטראקציה עם מאזן העומסים: עם קבלת הבקשה, Relianoid לא משנה את תוכן הבקשה מלבד כתובת ה-MAC של היעד . כתובת ה-MAC שאליה משתנה היא כתובת השרת האחורי לעיבוד הבקשה. מאזן העומסים מעביר את הבקשה לשרת האחורי המתאים בהתבסס על אלגוריתם איזון העומסים שנקבע.

שרת יישומי Backend: עם קבלת הבקשה, שרת ה-backend מעבד את הבקשה ומייצר תגובה.

תגובה ישירה: שרת ה-backend שולח את התגובה ישירות למכשיר הלקוח, ומשלים את לולאת התקשורת.

הערה חשובה

1. Relianoid בדרך כלל מגיב לבקשות ARP מטעם שרתי ה-backend כדי לשמר את התקשורת המקורית בין לקוח לשרת. לכן, תצורות ARP נכונות הן קריטיות כדי להבטיח ניתוב תקין של חבילות.
2. יש לתכנן בקפידה את סכימת כתובת ה-IP כדי למנוע התנגשויות ולהבטיח תקשורת תקינה בין לקוחות לשרתי קצה. בדרך כלל אנו מגדירים את שרתי הקצה האחוריים כך שיהיו להם כתובות IP דומות ל-IP הוירטואלי (VIP) המשמש את חוות L4xNAT, אך ייתכן שהמחלקים האחוריים לא יכריזו על כך בשיחות ARP כדי למנוע התנגשויות.

למה להשתמש ב-DSR עבור תשתית הרשת שלך #

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

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

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

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

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

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

תצורות Relianoid עבור שרתי backend של לינוקס ו-Windows #

כדי להפעיל DSR, ראשית, עליך להגדיר שרת וירטואלי בשכבה 4 או חוות L4xNAT. קרא מאמר זה כדי ליצור אחד כזה.

דרישות ל DSR: #

1. השמיים IP וירטואלי והקצה האחורי חייב להיות באותה רשת.
2. השמיים יציאה וירטואלית ויציאות Backend חייבות להיות זהות.
3. יש להגדיר את הקצה האחורי לולאה חוזרת מתממשק עם אותה כתובת IP כמו ה-VIP שהוגדר במאזן העומס והשבת ARP בממשק הזה.

שרתי קצה אחוריים של לינוקס #

# ifconfig lo:0 192.168.0.99 מסיכת רשת 255.255.255.255 -arp up

בעזרת פקודה זו, אנו יוצרים ממשק רשת וירטואלי lo:0 עם כתובת ה-IP 192.168.0.99 ומסיכת רשת משנה של 255.255.255.255.

הדגל -arp משבית את פרוטוקול רזולוציית הכתובות (ARP) בממשק זה.

השבתת תגובות ARP לא חוקיות ב-backend. #

# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

פקודה זו מגדירה את הערך של arp_ignore ל -1 בקובץ /proc/sys/net/ipv4/conf/all . פרמטר זה קובע כיצד הליבה מגיבה לבקשות ARP. הגדרתו ל-1 פירושה שהמערכת צריכה להתעלם מבקשות ARP עבור כתובות IP שלא הוגדרו בממשק הרשת.

# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

פקודה זו משנה את הפרמטר arp_announce בשרתי הקצה האחורי. בתצורות DSR, הגדרת arp_announce ל -2 מבטיחה שכאשר שרתי הקצה האחורי מגיבים לבקשות ARP, הם משתמשים בכתובת ה-IP של היעד של הבקשה ככתובת ה-IP של המקור בתשובת ה-ARP. פעולה זו שומרת על תקשורת תקינה בין שרתי הקצה האחורי ללקוח, מכיוון שהלקוח מצפה לקבל את התגובה מכתובת ה-IP שאליה שלח את הבקשה.

שרתי קצה אחוריים של Windows #

1. הַתחָלָה->הגדרות->לוח בקרה->חיבורי רשת וחיוג.
2. לחץ לחיצה ימנית על מתאם הרשת שלך ולחץ פרויקטים.
3. רק פרוטוקול אינטרנט יש לבחור (בטל את הבחירה של "Client for MS Networks" ו"שיתוף קבצים ומדפסות")
4. מאפייני TCP/IP-> הזן את כתובת ה-IP של ה-VIP בחוות ADC של Relianoid. שער ברירת המחדל הוא אופציונלי. הזן את המסכה 255.255.255.255
5. הגדר את מדד ממשק ל 254. תצורה זו נדרשת כדי להפסיק להשיב לכל תגובת ARP ל-VIP
6. חדשות ועדכונים OK ושמור את השינויים.

לאחר מכן, הגדר את מודל אבטחת המארח לקבל תעבורה מ-Relianoid ADC בממשק ה-NIC. בנוסף, אפשר ל-Relianoid ADC לשלוח ולקבל תעבורה דרך ממשק ה-NIC המוגדר כברירת מחדל. פתח את CMD כמנהל מערכת והפעל את שלוש הפקודות שסופקו.

netsh interface ipv4 set interface NIC weakhostreceive=enabled netsh interface ipv4 set interface loopback weakhostreceive=enabled netsh interface ipv4 set interface loopback weakhostsend=enabled

הערה חשובה
שנה את ה-NIC והלולאה חזרה לשמות ממשק ברירת המחדל של מחשב Windows שלך.

אתגרים של שימוש ב-DSR #

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

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

תאימות שרתים: לא כל השרתים יתמכו ב-DSR עם כל סוגי היישומים. לדוגמה, ייתכן שנבצע DSR רק עם שרתי לינוקס או חלונות בעת שימוש ב-Relianoid.

פעולות בעלות מצב: עבור פעולות בעלות מצב המסתמכות על שמירה על מידע הפעלה, DSR יכול להוות אתגרים. בעת שימוש בסוגי NAT ​​אחרים, מאזני עומסים מטפלים בכל צורות השמירה על הפעלה, אך עם DSR, הניתוב הישיר עוקף מתווכים אלה. דרך אחת לעקוף זאת היא להשתמש בכתובת IP מקורית בשכבה 4 וב-Cookie Insert בשכבה 7 לצורך שמירה על הפעלה.

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

מורכבות פריסה: יישום DSR עשוי להכניס מורכבות נוספת במהלך הפריסה והתצורה. תכנון, עיצוב ובדיקות נכונים הם קריטיים להבטחת יישום חלק. לדוגמה, ייתכן שתצטרכו להגדיר כל שרת backend לבצע פריקת SSL ורישום.

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

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

סיכום #

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

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

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

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