מבוא

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

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

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

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

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

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

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

הערה חשובה

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

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

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

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

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

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

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

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

ZEVENET תצורות עבור שרתי קצה אחוריים של לינוקס ו-Windows

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

דרישות ל DSR:

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

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

# ifconfig lo:0 192.168.0.99 netmask 255.255.255.255 -arp up

עם פקודה זו, אנו יוצרים ממשק רשת וירטואלי ל: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 בחוות ZEVENET ADC. שער ברירת המחדל הוא אופציונלי. היכנסו למסכה 255.255.255.255
5. הגדר את מדד ממשק ל 254. תצורה זו נדרשת כדי להפסיק להשיב לכל תגובת ARP ל-VIP
6. חדשות ועדכונים OK ושמור את השינויים.

לאחר מכן, הגדר את מודל האבטחה המארח לקבל תעבורה מ-ZEVENET ADC בממשק ה-NIC. בנוסף, אפשר ל-ZEVENET 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 רק עם שרתי Linux או Windows בעת שימוש בZEVENET.

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

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

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

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

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

סיכום

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

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

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

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