שאלה מחבר שלי:

נתון:

1. AD על 2003
2. שרת קבצים X
3. שרת קבצים Y
4. שיתוף בשם share על שרתים X ו-Y שהוא זהה על ידי מנגנון עצמאי (לא replication של מיקרוסופט)
5. הוגדר DFS בשם "dfsroot" על הדומיין, ובתוכו הוגדר target שנקרא share1 אל השיתוף share בשני השרתים.
6. נבדק סטטוס, שני השרתים מחזירים Okay
7. שונה זמן ה-cache של ה DFS ל 5 שניות גם ב Root וגם ב Target
8. שני שרתי הקבצים נמצאים באותו סגמנט, ויש אליהם את אותו TTL (כלומר אותו מספר hop-ים) וגם אותו זמן פינג (למקרה שמישהו יטען שזה site-awareness...)
9. הכל מחובר דרך מתגים של 100mbps full duplex, כאשר שרת ה-AD אינו מקושר ישירות, אלא דרך נתב בסגמנט אחר.

הבעייה: כניסה אל השיתוף (domain\dfsroot\share1\\) מגיעה תמיד אל אותו שרת קבצים, גם אחרי שסוגרים את החלון וממתינים את זמן התוקף של ה-cache של ה DFS. אם מפילים את שרת הקבצים שאליו הלקוח תמיד מגיע, מתבצעת קפיצה אל השרת השני (כלומר fail-over יש). אם מחזירים את השרת הישן לפעולה, מחכים לזמן רענון, הלקוח ימשיך להגיע אל השרת השני. כלומר הבעייה היא שהוא פשוט לא בודק אלא אם כן הוא לחלוטין לא מצליח להיכנס.

לסיכום: איך גורמים ל load balancing לעבוד, אם זה בכלל אפשרי...

נמאס לכם לזכור סיסמאות? לחצו כאן!

למיטב ידיעתי זה עובד בסגנון round-robin כאשר משתמש מסוים תמיד יגיע לאותו שרת (זיהוי לפי כתובת IP).
תבקש מחבר שלך לנסות להתחבר ממספר מחשבים שונים לשיתוף.

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

כלומר, הראשון שעונה לך הוא זה שמשרת אותך, אין load balancing אמיתי בנושא הזה בDFS.
אם אתה רוצה load balancing אמיתי ואתה לא משתמש ביכולות של הDFS אז למה שלא תעבוד עם NLB?
זה נשמע לי יותר מתאים לך

בגלל שהוא משתמש ב NetBIOS Names, ואתה לא יכול להגדיר שם NetBios שמפנה לשני כתובות IP (בתיאוריה כן, רק חלונות לא ייתן לך לגשת אליו )

אבל זה כן אפשרי אם הוא ייעבוד עם web share
או שאפאצ'י לא תומך בזה?

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

הצורך הוא לעבוד ספציפית דרך NetBIOS.

נמאס לכם לזכור סיסמאות? לחצו כאן!

ואז משתמשים בVLAN מסוים יפנו לשרת שנמצא בVLAN שלהם באמצעות אותו שם.

גם-כך כאשר אחד השרתים יהיה "עמוס" (עד כמה שהוא יהיה כזה) השרת השני יענה לקריאות והעומס ייתחלק.

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

(=לא מבין מה זה מחשב )

תודה לכולם על התגובות לבינתיים, אם ימצא איזשהוא משהו מעניין, נשתדל לעדכן

נמאס לכם לזכור סיסמאות? לחצו כאן!

אבל זה כבר יקר

אצלנו יש כ50 משתמשים בLAN ושרתי הקבצים לא עמוסים בכלל...

זה לא משנה (אבל הרבה יותר). העקרון הוא יותר דרך הפעולה (מבחינת "מחקר אקדמי").

בכל אופן, המסקנות שהתקבלו עד עכשיו:

1. יש אקראיות שמבוססת ככל הנראה דווקא על משהו אצל הלקוח (וכנראה לא ה-IP משום מה?)
2. הלקוח נעול חזק מאוד ברגע שהוא תופס שרת, וקשה מאוד להזיז אותו משם (כולל באמצעות ניקוי cache עם dfsutil)
3. נראה ש-failover עובד בסדר
4. ניתן לבחור באמצעים ידניים (סקריפטים/רג'יסטרי/GP) רפליקה רצוייה
5. ניתן להגביל לשימוש ברפליקות באתר שלך בלבד (אתר לא על פי פיזיקה-רשתית אלא עם פי הגדרת Site ב AD)
6. ניתן להחליט מה ה"עלות" לגישה לרפליקה בהתאם ל-site, ולחפש בעלות הנמוכה ביותר, ולאט לאט לעלות ככל שלא נמצאות רפליקות תקינות (*תקף ב 2003 בלבד)

זהו בערך, אני חושב

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

המשך שבוע נעים

נמאס לכם לזכור סיסמאות? לחצו כאן!

בעקרון לא מפתיעים הפיצ'רים, ראיתי את חלקם הגדול עובד.
רק אני רוצה להוסיף בשבילך 2 תוספות לעמודת המינוסים, אני בטוח שלא תתנגד:
1. אם אתה רוצה לפתח תוכנה שיוצרת קובץ חדש באיזושהי רפליקה כאשר המחשב עדיין לא בחר אחת (לא נכנסת ידנית לתיקייה עדיין) התוכנית שלך תיפול (כנראה בגלל זה הוא לא מוכן לשחרר למרות ניסיונות ניקויי cache שלך) על שגיאה של "לא מצאתי את התיקייה".
הנושא נבדק על .aspx בלבד, אבל סביר להניח שתיתקל בשגיאות כאלו ואחרות גם בכלי פיתוח מיקרוסופטים אחרים.
2. אם אתה רוצה להפעיל רפליקצייה בין 2 תיקיות שנמצאות על שרתי cluster (כל אחד באתר אחר), ברגע שתעשה failover לשרת השני באחד האתרים לפחות ההעתקה תיכשל כי הרפליקציית מתבצעת אך ורק לפי השם הnetbios שלהם.
בעייה ידועה ב2000, טוענים שטיפלו בה ב2003, אבל כל עוד לא בדקתי אני די סקפטי.

חוץ מזה, כלי מגניב, אני אוהב אותו

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

אם זה לא היה מובן, אין שימוש בשירותי ה replication של מיקרוסופט, אלא במנגנון אמין הרבה יותר...

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

קיים בresource kit של 2003 כלי שמדמה את הsymbolic link (ln של לינוקס)
הDFS נותן לך קצת יותר מזה.

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

וזה כן היה מובן, אבל יש פתגם עתיק שאומר "כל אחד בוכה מאיפה שכואב לו", מכיר?

ועובדה שזה קיים כבר איזה 30 ומשהו שנה... (אני חושב. זה היה קיים כשהתחלתי עם לינוקס לפני 8 שנים...)

לגבי ה InSite - זה מנגנון שהוא Redundant. הרי ממילא רשת מרובת אתרים תשתמש בהגדרות של אתרים, אז למה לא להשתמש ב SiteCosting וזהו? ה-InSite פשוט מיותר. כל חסימה שניתן לבצע ברמת רשת, עדיף לבצע ברמת רשת. אחרת המשתמשים שאינם טפשים (תמיד יש מישהו כזה בארגון, לא?), יעלו על זה שאפשר לגשת לסניף המרכזי ישירות, ויספרו לכולם, תוך כדי התעלמות מוחלטת ממנגנון ה DFS.

נמאס לכם לזכור סיסמאות? לחצו כאן!

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

וד"א, אני חייב לדבר איתך דחוף הסופ"ש הזה

עזוב את זה שבחרתם להשתמש בDFS.
מה הצורך תכלס? תיקייה מסויימת שהמשתמשים יגשו אליה דרך LB כלשהו?
מה גודל התיקייה? איפה היא יושבת? בכמה משתמשים מדובר?

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

לא עדיף לך להשתמש בLB חומרתי במקרה כזה?

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

וNLB לא יכול לעזור לך במקרה הזה כיוון שהוא עובד עם NETBIOS.

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

למה, אם כל השרתים מוגדרים לאותו שם, והמחשבים מקבלים IP של ה NLB מה-DNS (נניח), ומאחורי ה NLB יושבים השרתים בפועל, וה NLB מבצע חלוקת עומסים (נניח על פי sessions), זה לא נשמע לי כמו בעייה.

אבל חפיף, הובן כבר ש DFS כן מחלק איכשהוא את המשתמשים, שבינתיים זה מספיק למי ששאל אותי את השאלה...

נמאס לכם לזכור סיסמאות? לחצו כאן!

כאשר השם הזה יפנה למספר כתובות IP.
את זה NLB לא יכול לעשות...

בדקת את כל ה NLB-ים בעולם?

נמאס לכם לזכור סיסמאות? לחצו כאן!

נמאס לכם לזכור סיסמאות? לחצו כאן!

אני בכלל מתפלא שאתה משתמש בתשתית של מיקרוסופט לדבר כזה.

נמאס לכם לזכור סיסמאות? לחצו כאן!