בכל שנה לקראת החגים (בעיקר ראש השנה ופסח), אנו בתור מנהלי מערכות מחשוב נתקלים בפקקי תנועה ועומסים חריגים על שרתי הדואר וחיבורים לאינטרנט, שגורמים לתקלות ואף השבתות שלהם לפרקי זמן ארוכים.
כמו כן אנו נתקלים בהרבה ברכות שבחלקן הגדול לא מייצגות כוונה אמיתית או חשיבה של השולח על הנמען – למשל כשמקבלים ברכה שמתחילה ב
FW FW FW FW
אז אפשר להבין איך היא התגלגלה אלינו וכמה תשומת לב הושקעה בה.
כנ"ל במקרה שמקבלים את אותה מצגת מדהימה מאנשים שונים.
במאמר זה ברצוני לפרט מהם הגורמים לבעיות, ועל פעולות שאני ממליץ כדי לצמצם אותן ולהימנע מהן.
המלצות אלו מתאימות לכלל ימות השנה ויכולות למנוע גם בעיות ועומסים שלא קשורים לחגים.
תיאור הבעיה:
משתמשים רבים שולחים ברכות לחג, שכוללות קבצי מולטימדיה מצורפים (תמונות, סרטונים, מצגות וכו').
הקבצים האלו הם גדולים יחסית – בדרך כלל בין 1MB ל 10MB .
במקביל הברכות נשלחות לתפוצה גדולה – המשתמשים בהרבה מקרים ינסו לשלוח לכל ספר הכתובות שלהם.
נניח שמשתמש מסויים שולח הודעה בגודל של 5mb לתפוצה של 200 נמענים, דרך שרת הדואר של הארגון. במצב הרגיל השרת צריך לשלוח כ 1000mb מידע החוצה, דרך ה UPLOAD של החיבור לאינטרנט.
אם מדובר למשל על חיבור במהירות 5000/500kbps , אז הודעה כזו אמורה להעמיס את ה UPLOAD למשך כ 4.5 שעות (!)
להלן הנוסחה לחישוב למי שרוצה:
Message size in MB * 1000 * 8 * Number of recipients
_____________________________________________
Upload speed in KBPS * 3600
עכשיו תעשו חשבון מה קורה כש 10 או 100 משתמשים או יותר שולחים ברכות לחג באותו יום או אפילו באותו שבוע – למשל 10 משתמשים ששולחים בממוצע הודעה אחת של 5mb ל 200 משתמשים, עלולים להעמיס קו של upload 500kbps למשך כמעט 48 שעות רצוף(!)
הבעיה הזו מופיעה באופן יותר משמעותי אצל ספקי האינטרנט, לכן גם אם אצלנו ברשת הכל שקט – ייתכנו שיבושים בחיבורי אינטרנט ותעבורת דואר בגלל העומס אצל הספקים בתקופה של כשבועיים לפני החג.
המלצות – איך להימנע או לצמצם את הבעיות:
כעת נעבור על רשימת פעולות שאני ממליץ לבצע כדי לצמצם את הבעיה.
מי שרוצה להוסיף – מוזמן לרשום תגובה למאמר עם הטיפים שלו.
1. הגברת מודעות ושיתוף פעולה עם המשתמשים
כמו בהרבה דברים אחרים שקשורים לניהול מערכת המחשוב, אחת הפעולות הראשונות והחשובות היא לשתף את המשתמשים בבעיה ובפתרון.
הגברת המודעות של המשתמשים למה שקורה היא תמיד דבר טוב – וככל שהם מבינים יותר כך תעלה רמת שיתוף הפעולה, וזה נכון גם במקרה הזו וגם בנושאים אחרים כמו למשל ענייני אבטחה והגנה מוירוסים/טרויאנים.
כדאי להוציא מכתב קצר למשתמשים שמסביר על הבעיה, ונותן להם טיפים איך להימנע ממנה.
להלן כמה דברים שאפשר להסביר ולבקש מהמשתמשים בארגון:
א. אין צורך שכל משתמש בארגון ישלח ברכות לחג לכל אנשי הקשר שלו.
במקום זה – מי שרוצה וחושב שזה מועיל שישלח ברכה לרשימת אנשי קשר מצומצמת שרק קשורים אליו, ואם רוצים ברכה ארגונית אז שמישהו אחד ישלח בשם כלל הארגון, בתיאום עם מנהל המערכת כדי לבדוק איך לבצע את זה מבחינה טכנית.
כלומר – שהמשתמש ידע לא לשלוח סתם לכל ספר הכתובות שלו, אלא רק לאנשי קשר שהוא בוחר באופן סלקטיבי. או שלא ישלח בכלל.
ב. כששולחים הודעת דואר, במיוחד לרשימת תפוצה, יש לשים לב לגודל הקבצים המצורפים.
הודעה גדולה גורמת לעומס בהתאם.
לכן יש להקפיד לשלוח ברכה שכוללת טקסט בלבד, למשל מספר חרוזים קצרים או ברכה אישית שיוצאת באמת ממה שכתב אותה.
אם רוצים לצרף קובץ אז לבדוק היטב את הגודל שלו – שיהיה לא יותר מ 200kb .
ג. מערכת הדואר של הארגון מיועדת לענייני עבודה – מי שרוצה לשלוח קבצים גדולים לקרובים שלו, מתבקש להשתמש בדואר הפרטי שלו בבית.
ד. אפשר להפנות את המשתמשים למאמר הזה, או מאמר אחר בנושא שאתם או מישהו אחר כתב.
ה. יש להנחות את המשתמשים למחוק את הברכות שהם קיבלו עם קובץ מצורף – על מנת שלא יתפסו מקום על השרתים.
ו. לסיכום – יש להדגיש למשתמשים שלכל הודעת דואר שהם שולחים או מקבלים יש מחיר - גם אם לא משלמים אותו באותו רגע במזומן. המחיר נקבע בעיקר לפי גודל ההודעה ומספר הנמענים.
2. פעולות ברמת מנהל המערכת:
בתור מנהלי מערכת המחשוב, יש מספר פעולות שכדאי לעשות בשרתי הדואר וציוד תקשורת, על מנת למנוע את המצב שבו חיבור האינטרנט של הארגון מושבת או משובש לזמן ארוך בגלל הברכות לחג.
אני אתייחס בעיקר לשרתי EXCHANGE במאמר הזה, אבל העקרונות מתאימים גם לשרתי דואר אחרים כגון SENDMAIL .
א. הגבלת גודל ומספר נמענים ברמת השרת.
במרבית שרתי הדואר אפשר ורצוי להגביל את המשתמשים על מנת שלא ישלחו בטעות (או במתכוון) הודעות שיגרמו לעומס גדול מדיי.
ההגבלות מתחלקות ל:
הגבלת גודל ההודעה.
הגבלת מספר הנמענים.
בשרתי EXCHANGE 2000/2003 ההגדרות העיקריות נמצאות ב:
System Manager
Global Settings
Message Delivery – Properties
Defaults
כמו כן אנו נתקלים בהרבה ברכות שבחלקן הגדול לא מייצגות כוונה אמיתית או חשיבה של השולח על הנמען – למשל כשמקבלים ברכה שמתחילה ב
FW FW FW FW
אז אפשר להבין איך היא התגלגלה אלינו וכמה תשומת לב הושקעה בה.
כנ"ל במקרה שמקבלים את אותה מצגת מדהימה מאנשים שונים.
במאמר זה ברצוני לפרט מהם הגורמים לבעיות, ועל פעולות שאני ממליץ כדי לצמצם אותן ולהימנע מהן.
המלצות אלו מתאימות לכלל ימות השנה ויכולות למנוע גם בעיות ועומסים שלא קשורים לחגים.
תיאור הבעיה:
משתמשים רבים שולחים ברכות לחג, שכוללות קבצי מולטימדיה מצורפים (תמונות, סרטונים, מצגות וכו').
הקבצים האלו הם גדולים יחסית – בדרך כלל בין 1MB ל 10MB .
במקביל הברכות נשלחות לתפוצה גדולה – המשתמשים בהרבה מקרים ינסו לשלוח לכל ספר הכתובות שלהם.
נניח שמשתמש מסויים שולח הודעה בגודל של 5mb לתפוצה של 200 נמענים, דרך שרת הדואר של הארגון. במצב הרגיל השרת צריך לשלוח כ 1000mb מידע החוצה, דרך ה UPLOAD של החיבור לאינטרנט.
אם מדובר למשל על חיבור במהירות 5000/500kbps , אז הודעה כזו אמורה להעמיס את ה UPLOAD למשך כ 4.5 שעות (!)
להלן הנוסחה לחישוב למי שרוצה:
Message size in MB * 1000 * 8 * Number of recipients
_____________________________________________
Upload speed in KBPS * 3600
עכשיו תעשו חשבון מה קורה כש 10 או 100 משתמשים או יותר שולחים ברכות לחג באותו יום או אפילו באותו שבוע – למשל 10 משתמשים ששולחים בממוצע הודעה אחת של 5mb ל 200 משתמשים, עלולים להעמיס קו של upload 500kbps למשך כמעט 48 שעות רצוף(!)
הבעיה הזו מופיעה באופן יותר משמעותי אצל ספקי האינטרנט, לכן גם אם אצלנו ברשת הכל שקט – ייתכנו שיבושים בחיבורי אינטרנט ותעבורת דואר בגלל העומס אצל הספקים בתקופה של כשבועיים לפני החג.
המלצות – איך להימנע או לצמצם את הבעיות:
כעת נעבור על רשימת פעולות שאני ממליץ לבצע כדי לצמצם את הבעיה.
מי שרוצה להוסיף – מוזמן לרשום תגובה למאמר עם הטיפים שלו.
1. הגברת מודעות ושיתוף פעולה עם המשתמשים
כמו בהרבה דברים אחרים שקשורים לניהול מערכת המחשוב, אחת הפעולות הראשונות והחשובות היא לשתף את המשתמשים בבעיה ובפתרון.
הגברת המודעות של המשתמשים למה שקורה היא תמיד דבר טוב – וככל שהם מבינים יותר כך תעלה רמת שיתוף הפעולה, וזה נכון גם במקרה הזו וגם בנושאים אחרים כמו למשל ענייני אבטחה והגנה מוירוסים/טרויאנים.
כדאי להוציא מכתב קצר למשתמשים שמסביר על הבעיה, ונותן להם טיפים איך להימנע ממנה.
להלן כמה דברים שאפשר להסביר ולבקש מהמשתמשים בארגון:
א. אין צורך שכל משתמש בארגון ישלח ברכות לחג לכל אנשי הקשר שלו.
במקום זה – מי שרוצה וחושב שזה מועיל שישלח ברכה לרשימת אנשי קשר מצומצמת שרק קשורים אליו, ואם רוצים ברכה ארגונית אז שמישהו אחד ישלח בשם כלל הארגון, בתיאום עם מנהל המערכת כדי לבדוק איך לבצע את זה מבחינה טכנית.
כלומר – שהמשתמש ידע לא לשלוח סתם לכל ספר הכתובות שלו, אלא רק לאנשי קשר שהוא בוחר באופן סלקטיבי. או שלא ישלח בכלל.
ב. כששולחים הודעת דואר, במיוחד לרשימת תפוצה, יש לשים לב לגודל הקבצים המצורפים.
הודעה גדולה גורמת לעומס בהתאם.
לכן יש להקפיד לשלוח ברכה שכוללת טקסט בלבד, למשל מספר חרוזים קצרים או ברכה אישית שיוצאת באמת ממה שכתב אותה.
אם רוצים לצרף קובץ אז לבדוק היטב את הגודל שלו – שיהיה לא יותר מ 200kb .
ג. מערכת הדואר של הארגון מיועדת לענייני עבודה – מי שרוצה לשלוח קבצים גדולים לקרובים שלו, מתבקש להשתמש בדואר הפרטי שלו בבית.
ד. אפשר להפנות את המשתמשים למאמר הזה, או מאמר אחר בנושא שאתם או מישהו אחר כתב.
ה. יש להנחות את המשתמשים למחוק את הברכות שהם קיבלו עם קובץ מצורף – על מנת שלא יתפסו מקום על השרתים.
ו. לסיכום – יש להדגיש למשתמשים שלכל הודעת דואר שהם שולחים או מקבלים יש מחיר - גם אם לא משלמים אותו באותו רגע במזומן. המחיר נקבע בעיקר לפי גודל ההודעה ומספר הנמענים.
2. פעולות ברמת מנהל המערכת:
בתור מנהלי מערכת המחשוב, יש מספר פעולות שכדאי לעשות בשרתי הדואר וציוד תקשורת, על מנת למנוע את המצב שבו חיבור האינטרנט של הארגון מושבת או משובש לזמן ארוך בגלל הברכות לחג.
אני אתייחס בעיקר לשרתי EXCHANGE במאמר הזה, אבל העקרונות מתאימים גם לשרתי דואר אחרים כגון SENDMAIL .
א. הגבלת גודל ומספר נמענים ברמת השרת.
במרבית שרתי הדואר אפשר ורצוי להגביל את המשתמשים על מנת שלא ישלחו בטעות (או במתכוון) הודעות שיגרמו לעומס גדול מדיי.
ההגבלות מתחלקות ל:
הגבלת גודל ההודעה.
הגבלת מספר הנמענים.
בשרתי EXCHANGE 2000/2003 ההגדרות העיקריות נמצאות ב:
System Manager
Global Settings
Message Delivery – Properties
Defaults
אני ממליץ באופן כללי על הערכים הבאים:
Sending Message Size = 10000
Receiving Message Size = 20000 (שלא יהיה קטן יותר ממה שה MAIL RELAY מקבל במידה ויש כזה).
Recipient Limits = 20
כמובן שההמלצות שלי אינן מתאימות לכולם – העיקר שתהיה מגבלה סבירה כלשהי.
יש גם מקומות נוספים שאפשר להגביל, אך אני ממליץ על שימוש ב GLOBAL SETTINGS.
אם יש משתמש מסויים שצריך הגבלה שונה – אפשר להגדיר לו משהו נפרד דרך AD USERS AND COMPUTERS – ב PROPERITES של אותו משתמש.
Sending Message Size = 10000
Receiving Message Size = 20000 (שלא יהיה קטן יותר ממה שה MAIL RELAY מקבל במידה ויש כזה).
Recipient Limits = 20
כמובן שההמלצות שלי אינן מתאימות לכולם – העיקר שתהיה מגבלה סבירה כלשהי.
יש גם מקומות נוספים שאפשר להגביל, אך אני ממליץ על שימוש ב GLOBAL SETTINGS.
אם יש משתמש מסויים שצריך הגבלה שונה – אפשר להגדיר לו משהו נפרד דרך AD USERS AND COMPUTERS – ב PROPERITES של אותו משתמש.
אפשר לקראת החגים להציב הגבלות מחמירות יחסית, ואחרי החגים לשחרר קצת את הרסן.
בשרתי EXCHANGE 2007 SP1, ההגדרות נמצאות ב:
Exchange Management Console
Organization Configuration
Hub Transport
Global Settings
Transport Settings
בשרתי EXCHANGE 2007 SP1, ההגדרות נמצאות ב:
Exchange Management Console
Organization Configuration
Hub Transport
Global Settings
Transport Settings
ההמלצות שלי הן בדומה למה שכתבתי קודם לגבי EXCHANGE 2000/2003 .
גם כאן אפשר כמובן להגדיר הגבלות שונות למשתמש מסויים, ההגדרה נמצאת במאפיינים של התיבה תחת Recipient Configuration כפי שניתן לראות בתמונה:
ב. שימוש ב SMART HOST של ה ISP .
אני ממליץ – לפחות בתקופה של לפני החגים, שדואר יוצא מהשרת יישלח דרך שרת של ה ISP, ולא ישירות.
המשמעות של הגדרה כזו היא שאם נשלחת הודעה לתפוצה של 20 נמענים – ההודעה יוצאת פעם אחת בלבד דרך ה UPLOAD של חיבור האינטרנט שלך, ומתפצלת אצל ספק האינטרנט במקום אצלך.
כך אפשר להפחית באופן משמעותי את העומס על החיבור לאינטרנט.
לפני שמגדירים שליחה דרך הספק – יש להתייעץ עם התמיכה שלהם, ולשאול את השאלות הבאות:
מה המגבלות על נפח ומספר נמענים? (בהתאם להגבלות האלו תגדיר גם את השרת שלך).
דרך איזה שרת אפשר לשלוח?
האם יש צורך ב SMTP AUTHENTICATION ? מרבית הספקים דורשים הגדרת שם וסיסמא בדואר יוצא.
את ההגדרות עושים ב SMTP CONNECTOR – להלן צילומי מסך:
הגדרת SEND CONNECTOR ב EXCHANGE 2003:
הגדרת SEND CONNECTOR ב EXCHANGE 2007:
ג. הגבלת או חלוקת רוחב פס בציוד תקשורת.
יש מספר פעולות נוספות שאפשר לבצע בשביל להגדיל את רוחב הפס לאינטרנט, ולמנוע או לצמצם מצבים שבהם תעבורה של הדואר תוקעת את כל השאר לזמן ארוך.
להלן חלק מהפעולות שאפשר לשקול:
1. הגדלת רוחב הפס, לפחות של ה UPLOAD.
למשל – לעבור מקו ADSL 2000/200 לקו מהיר יותר, או לטכנולוגיה אחרת כמו ATM, קווי תמסורת וכו'.
2. שימוש בשני קווי אינטרנט במקביל, כאשר הדואר עובר דרך אחד מהם.
אפשר לבדוק את האופציה הזו יחד עם ספק האינטרנט ומי שמנהל אצלך את ה FIREWALL - יש שיטות שונות שמאפשרות חיבור של שני קווים לאינטרנט, אבל במאמר זה לא ניכנס לפרוט שלהן.
3. הגדרות QOS שנותן עדיפות נמוכה לדואר, או משהו דומה שמגביל את תעבורת הדואר רק לחלק מרוחב הפס, וכך לאפשר לשאר הנתונים לזרום.
לסיכום – כדאי להיות מודעים לבעיות הצפויות לקראת החג, כאשר הפעולות העיקריות שאפשר לבצע הן:
* שיתוף פעולה עם המשתמשים על ידי הסברה, הדרכה, ויצירת מודעות לבעיה.
* קביעת הגבלות שימנעו מהמשתמשים לשלוח בטעות דואר גדול לתפוצה רחבה.
* שליחת דואר דרך ספק האינטרנט (בתיאום איתם), שתצמצם את העומס על קו האינטרנט שלכם.
* וכמובן – שנה טובה ומוצלחת לכל מי שהצליח לקרוא עד כאן.
נכתב על ידי יזהר הורביץ
לקראת ראש השנה תשס"ט...
2 תגובות:
חג שמח
אחלה מאמר.
תענוג לקרוא,אני כל פעם נהנה מחדש.
נהנתי לקרוא !
האמת שאצלנו חושבים עכשיו לשלוח איזו ברכה לחג, אני אראה את ההודעה הזו למי שצריך.
הוסף רשומת תגובה