שירשור שאלות לאריה

[antidot]

../images/Emo45.gif המון תודה לאריה ../images/Emo51.gif

המון תודה לאריה על הזמן שהקדיש לנו.

 

[jumpgate]

../images/Emo45.gif../images/Emo51.gif

 

[פוֹלי]

../images/Emo45.gif

 

[ezaton]

שלום אריה

ישנן מספר שיטות לישום multi-channel-routing, או "חבירה" של מספר קווי תקשורת לכדי רוחב פס ריאלי גדול יותר (בשאיפה, סכימת רוחבי הפס הקיימים). בקשתי, אם תוכל, לפרט אודות השיטות הנפוצות יותר, בתלות בספק השירות (לדומא multi-PPP), ושיטות שאינן תלויות בספק השירות (load balancing אחר). אם תוכל להפנות אותי למאמרים טובים בנוגע ל"חבירת" קווים, או בקצה לסקור את היתרונות והחסרונות, הן בישום, והן טכנולוגית, של שיטות שונות, ותלותן בצד השני , אודה לך מאוד. אגב, מצטער על האיחור

 

[ariev]

האם אתה יכול למקד קצת את השאלה

למה שמעניין אותך בדיוק? השאלה די רחבה...

 

[ezaton]

אני יודע שזאת שאלה רחבה

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

 

[ariev]

בא נראה על מה אני יכול לחשוב באופן

מיידי... אז ככה: 1. Multi-link-PPP - איחוד של מספר קווי WAN לקו לוגי אחד שמקיץ PPP - בד"כ מכביד על ה-CPU של הנתב ומחייב שכל הקווים יהיו בדיוק בין 2 נתבים 2. equal cost routing - ניתוב ב-equal cost, כלומר 2 (או יותר) קווים שאותה הרשת מנותבת דרכם - שוב, ברוב המקרים מחייב ש-2 הקווים יגיעו לאותו הנתב (לא חובה, אבל מאוד קשה ליישום אם לא, בעיקר ברשתות גדולות). בעיה נוספת שיש לשים אליה לב זה שנתבים בד"כ לא עושים per-packet loadbalancing אלא per-flow, כדי להמנע מבעיות של פאקטים שלא מגיעים בסדר הנכון וכד' (יש אפליקציות שמאוד לא אוהבות את זה). מה שזה עלול לגרום, בעיקר בסביבות VPN ששם יש רק "flow" אחד, שהקווים לא יהיו מאוזנים. ניתן תמיד לעבור ל-per-packet, אבל יש לזה פוטנציאל לבעיות (בעיקר אם הקווים לא שווים בדיוק בפרמטרים שלהם - בעיקר ב-delay) 3. חלוקת כתובות בין קווים - דואגים שחלק מהכתובות ינותבו ממקום אחד, והשאר ממקום אחר (ואם יש נפילה אז מגבים אחד את השני) - צריך להתעסק בניהול של זה מדי פעם, אבל בד"כ הכי קל ליישום (מנקודת מבט של ספקי שרותים), ונותן את היכולות הכי טובות לגיבוי (קווים שמגיעים לאתרים שונים וכד') בכל המקרים יש תלות ביכולות הספק ובמה שהוא מוכן לעשות...

 

[ariev]

אגב, יש עוד אפשרות

בשימוש במוצר של חברת RADWARE שנקרא LINKPROOF

 

[ezaton]

תודה רבה!

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

 

[antidot]

שאלה שצצה

המצב: חדר תקשורת שבו מציבים 2 core switch-ים עבור שרידות מכל core זורקים סיב לworkgroup switch (למעשה מגיעים 2 סיבים לכל wg) כל wg צריך להיות scalable, ז"א המתגים של WG חייבים להיות stackable עם bus סביר ביניהם והמתג חייב להיות עם פורטים 100/1000 RJ45 (חיווט קצה הוא ג'יגה נחושת) עד כאן הכל יפה ונפילת core switch אחד מגובה ע"י השני ע"י RSTP. השאלה היא האם אפשר לבצע load balance בין 2 הcore-ים במקום שאחד ישב בצד בחוסר מעש ? כל core חייב לתמוך בכ-50 פורטים של GBIC. כל WG חייב 24 או 48 של 100/1000 נחושת ו-2 פורטים של GBIC עבור חיבור לשני הcore-ים. יש המלצות ? עבור wg הסדרה של 3750G נראת מתאימה. עבור הcore, ה4500. אני בכיוון ? חברות אחרות אולי חוץ מסיסקו ? (אם הגעתי למצב שאלה הסוגיות שעולות על בירות ביום שישי, המצב כנראה קשה...)

 

[ariev]

אני מתמצא בעיקר בסביבת CISCO

כך שלא ממש אוכל לתת הצעות של חברות אחרות... בכל מקרה, סדרה 3750 נראית מתאימה ל-WG, וה-4500 או אולי אפילו 6500 ל-CORE מבחינת גיבוי ו-load balance ישנן 2 שיטות: 1. להפוך את מתגי ה-WG למתגים Layer3, ולהפעיל OSPF (לדוגמה) ברשת. בצורה זו ניתן לנצל מסלולים מקבילים ברמת ה-routing, והגיבוי יתבצע במהירות. החיסרון הוא שלא ניתן "לפרוס" VLAN לכמה מקומות (כי כל VLAN זה SUBNET), וזה משהו שלעתים רוצים שאפשר יהיה לעשות. כמו כן הניהול של העניין קצת יותר מורכב, וצריך להכיר routing 2. לעבוד עם RSTP, ועם spanning tree per vlan, כך שניתן לכל VLAN על כל פורט UPLINK לקבוע priority שונה של spanning tree לכל VLAN, וכך חלק מה-VLANים עובר מצד אחד והשאר מצד שני (כמובן שכקו אחד נופל, הכל יעבור לקו השני כמו ב-RSTP רגיל) אני מניח שרשת בסדר גודל כזה, כדאי שתעבור תחת עינו של מישהו שעשה כזה דבר בעבר לפני שמזמינים ציוד...

 

[antidot]

תודה על הכיוון

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