מדריך זה דן ברשתות תקשורת נתונים רחבות ומקומיות (LAN/WAN) ובשילוב ביניהן. הנחיות המדריך, במרכזן תיק המערכת, אינן מוגבלות להקמת מערכות תקשורת חדשות. ניתן להשתמש במדריך זה גם להרחבות ושינויים במערכות תקשורת קיימות.
רשת תקשורת נתונים משולבת (WAN/LAN) היא כל רשת תקשורת המחברת לקוחות (משתמשים) באתרים שונים: קרובים ורחוקים. הרשת המקומית (LAN) מקשרת את המשתמשים בתוך האתרים שהם בשליטת הארגון והרשת הרחבה (WAN) מקשרת בין הרשתות המקומיות שאין אפשרות להקים ביניהם תשתית תקשורת פרטית בבעלות הגורם המקים את הרשת, אלא יש צורך לרכוש קוים אלו מספק קווי תקשורת כגון בזק. הנחיות פרק זה, במרכזן תיק המערכת, אינן מוגבלות להקמת מערכות תקשורת חדשות. ניתן להשתמש בפרק זה גם להרחבות ושינויים במערכות תקשורת קיימות. אין בפרק זה גלופות לכל שלבי מחזור החיים. תיק המערכת נכתב ב"עיניים של אפיון", אך ניתן לעשות בו שימוש מושכל גם לשלבים האחרים.
פרויקטים בהם משולבת רשת תקשורת יכולים להיות מהסוגים הבאים:
1. הקמת תשתית תקשורת מהמסד או שינויים והרחבות של תשתית תקשורת קיימת לצורך הרחבת הפריסה של מערכות מידע קיימות לאתרים נוספים. במקרים אלה, לא נדרש כל פיתוח או הרחבה ביישום עצמו, והפרויקט כולל אך ורק מערכות תקשורת. דוגמא קיצונית לפרויקט מסוג זה היא החלפת מודמים או העלאת מהירות הקווים.
2. הקמת יישום שאמור לפעול על תשתית תקשורת קיימת. במקרים אלה הפרויקט כולל בעיקר היבטים יישומיים וכמעט ואינו כולל מערכות תקשורת. דוגמא לפרויקט כזה היא הוספת דואר אלקטרוני למשתמשים קיימים, ברשת נתונה.
סוגים אלה הם מקרי קצה. במציאות, רוב הפרויקטים יהיו "באמצע" ויכילו מרכיבים משני הסוגים הנ"ל. בהתאם לסיווג הפרויקטים יושם דגש על רכיב הטכנולוגיה (סוג 1 לעיל) או על רכיב היישום (סוג 2 לעיל). תיק המערכת שלהלן מיועד לשמש את שני הסוגים ואי לכך הוא מכיל מידע פרטני הן ברכיב 3 - טכנולוגיה והן ברכיב 2 - יישום. בפועל, כל פרויקט ירחיב או יקצר ברכיבים הרלוונטיים בהתאם לאופיו וצרכיו. אם במהלך אפיון הרשת משתנה הסיווג, למשל, אם מתברר שעיקר הפרויקט הוא מערכת מידע שתפעל מעל הרשת, ולא הרשת עצמה, ניתן, בכל רגע, לעבור להשתמש במסמך (תיק) האפיון הכללי למערכות מידע. תיק זה מסועף באופן זהה לסיעוף עץ המערכת האוניברסלי של מפת"ח, ולכן המעבר אינו דורש שכתוב כלשהו.
מטרת פרק זה לסייע בהגדרת הדרישות של מערכת מידע ברכיבים תקשורת מקומית - 3.30 ותקשורת רחבה - 3.31. זאת, במקרים בהם מדובר ברשת פשוטה, או הרחבות לרשת קיימת.
במונח תקשורת נתונים, הכוונה לאמצעי המאפשר תקשורת ברמת בניין או אוסף בניינים בחצר אחת (קמפוס) - רשת LAN (Local Area Network) וקישור בין רשתות LAN שונות ע"י קישורים ציבוריים (קווי בזק, לווין, סיבים אופטיים שכורים וכו') - או רשת WAN (Wide Area Network). לתשומת לב, קישור לרשתות ציבוריות (דוגמת Internet) מכוסה ע"י סעיף 3.32.
בדומה לרכיבים אחרים בסעיף הטכנולוגיה, אפשר להשתמש לנושא זה באחת משתי רשימות תיוג:
· רשימה תקנית המכילה אזכור קצר של תקנים ו"כתב כמויות" קצר
· רשימה מפורטת יותר המיועדת למקרים מיוחדים, או כ"השלמה" לסעיף הקודם, אם בנוסף לתקן, נדרש גם הסבר מילולי.
בכל מקרה, רשימות אלה מתייחסות להיבטים הטכניים בלבד. לכך יש תמיד להוסיף מאפיינים כמותיים לוגיסטיים וארגוניים, כמפורט בתיקי העבודה השונים
ראה סעיף זה בקיט האפיון בכרך יסודות / מחזור חיים.
1. התאמה למודל 7 השכבות הכללי של OSI
2. התבססות על תקני תקשורת בתחום ה- LAN:
· ATM
· Ethernet, Fast Ethernet
· Token-Ring
· FDDI
3. התבססות על תקני תקשורת בתחום ה- WAN:
· ATM
· Frame Relay
· X.25
· PSTN
· ספרנת
· ISDN
4. התבססות על תקנים מרמה נמוכה יותר:
· RS423 (RS232-c)
· X21
5. כמויות נדרשות:
· תחנות קצה
· תעבורה
· קצבים.
6. ניתוב פרוטוקולים:
· TCP/IP
· DECnet
· SNA
· IPX וכו'.
1. תיאור וארכיטקטורה כלליים
· שם, יצרן, זיהוי וגרסה מדויקים, הפניה לספרות
· תקנים
· ארכיטקטורת הרשת (ניתוב, מיתוג, נתיבים חליפיים, קישורים מהירים).
2. סוגי ציוד נתמכים
· תחנות עבודה, מחשבים מרכזיים (Servers) - וצורת חיבורם לרשת
· ציוד קצה (היקפי): מסופים, מדפסות
· ציוד אחר (מיוחד).
3. סוגי שירות שהמערכת מספקת (נדרשת לספק)
· קישור מסוף/מחשב
· בסיס נתונים (מילון) מרכזי
· מאגר תוכנות מרכזי
· העברות קבצים (נתונים, גרפיקה, תמונות, קול ווידאו)
· קשר Application-to-Application
· שילוב קול ו- Video Conference
· אחר.
4. טופולוגיה ובקרה
· צורת חיבור ופריסה לוגית: מבנה, גיבויים, היררכיה וכו'
· מבנה רשת רחבה
· מבנה BackBone לרשתות המקומיות.
5. הערוץ הפיסי
· כבל Coax
· Twisted Pair
· סיב אופטי וכו'.
6. פרוטוקולי ומשטרי תקשורת
7. רכיבי (כרטיסי) התקשורת
· ביחידת קצה
· ברשת עצמה
· במחשב(י) היעד
· סוג ואיכות מודמים נדרשים.
8. מהירויות וקיבולת (capacity)
· לכל סוג קישור ברשת המקומית והרחבה
· קישור שרתים
· עם/בלי דחיסת נתונים.
9. אבטחת נתונים ומידע
· אבטחה פיזית
· בכניסה לרשת
· במהלך השימוש
· רישום ומעקב
· הצפנת נתונים
· Firewall
· אבטחה בהעברת מידע בין כל זוג משתמשים.
10. Gateways
· יציאה לרשת רחבה (WAN)
· יציאה לרשת אזורית (MAN)
· יציאה לרשת ציבורית
· יציאה לרשת מקומית אחרת.
11. תוכנת הרשת
12. שליטה וניהול התפעול
· מעקב ביצועים ותקלות בזמן אמת
· התגברות על תקלות בזמן אמת
· סטטיסטיקות וניתוח התנהגות הרשת לטווח ארוך
· תכנון קיבולת (Capacity Planning).
גלופות הלימוד והעבודה של תיק המערכת בלשונית "תוצרים" בקיט יכולות לשמש בסיס טוב למסמך ייזום. עם זאת, יש לשם לב גם לקיט ייזום מערכת/פרויקט בכרך מחזור חיים.
ראה גלופת לימוד ועבודה המצורפות לקיט זה.
במעבר משלב האפיון לשלב בקשה להצעות, אם קיים, יהפוך תיק האפיון למפרט (RFP). פרק המנהלה יוחלף בפרק המנהלה הסטנדרטי של בקשה להצעות ופרקים 5-1 יהפכו לחלק הטכני של המפרט. בנוסף יש להכין את המפ"ל! ראה הסבר מלא בקיט בקשה להצעות - RFP בכרך מחזור חיים.
עיצוב רשת תקשורת נתונים מחייב התמודדות עם מספר דרישות אשר סותרות לעתים אחת את רעותה. הדרישות הן: מענה מיטבי לצרכים ידועים, מתן מענה לדרישות עתידיות, קלות ופשטות בניהול ואחזקה ויחס עלות תועלת סביר.
על מנת להשיג את האיזון בין הדרישות על המתכנן לצאת בראש ובראשונה ממבנה מערך המידע בארגון וללמוד אותו היטב תוך התייחסות לנקודות הבאות:
· מיקום שרתים, שירותים מרכזיים, המשתמשים בהם ואופי העבודה מול השרת - יש לבדוק את מיקום השרתים (מבוזר, מרכזי בכל רשת LAN, מרכזי על ה- WAN), מיקום המשתמשים (קבוצת עבודה על השרת שלה, כל אתר על שרתיו, כל משתמש לכל שרת).
· מבנה פיזי של אתרי הארגון ותשתית הכבילה (אם קיימת) - מספר ריכוזים, סוגי כבילה בין הריכוז למשתמשים ובין הריכוזים לבין עצמם, סוג שקעי הקצה, טופוגרפית תשתית התקשורת (קישור למרכז אחד או ביזור), מקום פנוי בארונות התקשורת וכו'.
· אופי העברת הנתונים ע"ג הרשת מבחינת נפחים, רגישות לעיכובים (Delays), התפלגות התעבורה.
· צרכי גיבוי ושרידות הן ברמת נתיבים חלופיים (קווי גיבוי) והן מבחינת גיבוי ציוד תקשורת.
· פרוטוקולים אשר מועברים ע"ג הרשת, תמיכה בהמרות פרוטוקולים (SNA Gateway לדוגמא), סינון וכו'.
· דרישות אבטחת המידע הן ברמת LAN (Filtering, VLANs, Access Lists) והן ברמת WAN (הצפנת קווים, הרשאות וכו') - יש לשים דגש על האבטחה הפיזית של ציודי ותווכי התקשורת.
· אופי ניהול הרשת- מרכזי, מבוזר, שילוב של שתי השיטות.
· משאבי ניהול הרשת הקיימים (כ"א, הכשרה, התפלגות, אמצעים פיזיים, עמדות שו"ב וכו')
· ניתוח כיוונים עתידיים של צרכי התקשורת של הארגון מבחינת הרחבת כמות תחנות, אתרים, קצבי תעבורה וכו'.
לאחר איסוף הנתונים וניתוחם יש לתכנן את המערכת בשני שלבים:
· בשלב ראשון - תכנון מערך ה- WAN בין האתרים תוך בניית מודלים לפי סוגי אתרים ותפקוד (סניף גדול, סניף קטן, מרכז אזורי, מרכז מחוזי וכו') ובניית היררכית הקשרים בין האתרים כפי שנגזר מאופי היישום.
· בשלב שני - תכנון רשתות ה- LAN בכל אתר וגם כאן תוך בניית מודלים לפי סוגי אתרים ותפקוד (סניף גדול, סניף קטן, מרכז אזורי, מרכז מחוזי וכו').
במהלך תכנון השלבים יש לשים דגש על הנושאים הבאים:
· קלות תפעול וניהול הרשת. מחקרים מראים שרוב עלויות המחשוב באות ממקטע הניהול והתמיכה ועל כן יש לשאוף לרשת "שטוחה" ופשוטה ככל הניתן. לדוגמא: מומלצת רשת ממותגת בה כל התחנות יכולות להגיע אל השרתים המרכזיים במידה שווה, ע"י עורקים מהירים, ואין צורך בניהול הקשרים בין המשתמשים לשרתים. אפשרות זו מועדפת לעומת פתרון "חסכוני" בו יש צורך בביצוע אופטימיזציה של מיקום השרת יחסית למיקום המשתמשים ונוצרות בעיות במקרה של תזוזת/העתקת משתמשים.
· שיקולי גיבוי ושרידות - יש להגן על עורקי ה- WAN מפני נפילת קווים ע"י שימוש בקו גיבוי מטכנולוגיה אחרת (אין טעם בשני קווי סיפרנת לגיבוי הדדי אלא אם הם עוברים דרך צמתים ומרכזיות שונים). זאת, משום שנפילות קווים נובעות בד"כ מתקלות ציוד אשר משבית את כל הקווים הפועלים בטכנולוגיה זו. טכנולוגית הגיבוי תיגזר מצרכי העברת הנתונים בשעת משבר, בד"כ קווי ISDN יספקו פתרון הולם לרוב הצרכים (מספקים מהירות של 128Kbps) תוך עלות אחזקה נמוכה. יש להיות מודעים ל- Single Points of Failure של קווי התקשורת החיצוניים, קוים ראשיים וקווי גיבוי, שהשבתתם בנקודה אחת יכולה להשבית את הרשת. דוגמאות ל- Single Points of Failure: תעלת תקשורת בכביש שדחפור עלול לקרוע את הכבלים בתוכו, תיבת חיבור של בזק בבניין, וכו. ידע זה חשוב גם במקרים בהם הסיכון (ראה קיט ניהול סיכונים) הכרוך הוא ידוע ומקובל. יש לשים דגש לכמות המבואות (Ports) המוקצית לקווי הגיבוי באתר המרכזי. מומלץ על יחס של 1:5. ברשתות קריטיות מומלץ להפריד בין ציוד הקצה הפועל מול עורקי ה- WAN לציוד הגיבוי על מנת למנוע נתק עקב נפילת ציוד הקצה.
· שרידות רשת ה- LAN - יש לבצע מיפוי של צרכנים ורמות השרידות הנדרשות מהרשת. גיבוי הרשת יכול להתבצע ברמות שונות החל מגיבוי קר לציוד המרכזי וכלה בגיבוי חם עד לרמת תחנת הקצה.
· התאמה לעומסים קיימים ועתידיים - עקב העלויות ההולכות ויורדות של ציודי המיתוג, מומלץ לבנות את הרשת כך שתחנות הקצה ימשיכו לפעול בטכנולוגיות הקיימות (Ethernet) תוך הקצאת סגמנט פרטי לכל תחנה, ואילו ריכוזי המשנה והשרתים יקושרו בטכנולוגיות מהירות יותר כגון Fast Ethernet/ATM.
· פרוטוקולים - מומלץ מעבר הדרגתי לעבודה בפרוטוקול TCP/IP.
· קישור ל- Mainframe - רוב נתבי התקשורת מאפשרים ניתוב של פרוטוקולי SNA כך שניתן לקשר בין תחנות ברשת לבין ה- Mainframe דרך רשת ה- WAN הסטנדרטית.
· שליטה ובקרה - מומלץ להקים עמדת שו"ב מרכזית שתנהל את כל רשת התקשורת הרחבה ורשתות התקשורת באתרים. במקרה של רשת בעלת אתרי משנה (LAN) גדולים, ניתן להקים עמדה קטנה יותר בכל אתר גדול לניהול מקומי של ציוד ה- LAN תוך שמירה על הניהול המרכזי. מומלץ כי ציוד הקצה יתמוך בפרוטוקול RMON ברמה הגבוהה ביותר (9 קבוצות) על מנת לאפשר לצוות ניהול מרכזי לבצע ניטור של כל סגמנט ברשת גם אם הוא באתר אחר.
· אבטחת מידע - מקומה המרכזי של הרשת בתפקוד הארגון מחייב שימת דגש רב על קיום דרישות אבטחת המידע הן בכל ציוד קצה, קישור ותחנה והן בהיבט הכולל של רשת התקשורת.
· VLANs - מומלץ לאפיין ציוד התומך ב VLANs מעל פני הרשת (Over The Network) לפי Mac Address, Port, IP Address.
בשלב זה "תופעל" תכנית הבדיקה שהוגדרה ברכיב 4.8 בתיק האפיון. ז"א בדיקת עמידת כל פריט ציוד לדרישות כפי שהוגדרו ובנוסף, בדיקת פעולת המערכת כולה כמקשה אחת (יש להתנות סיום בדיקות קבלה בגמר ההקמה) ועמידתה בדרישות התפעוליות (שליטה ובקרה, שרידות, עמידה בעומסים, אינטגרציה בין מוצרים, קישור למערכות אחרות וזמני תגובה). זאת על מנת למנוע מצב בו כל רכיב עונה לנדרש אולם הרשת כולה כמערכת תפעולית אינה מקיימת את הדרישות.
התקנת המערכת תעשה בד"כ בשלבים. בשלב הראשון מומלץ להקים את מרכז הרשת ועמדת השליטה והבקרה, ולאחר מכן לצמוח בפריסת רשתות ה- LAN בפרויקט. עם סיום הקמת רשתות ה- LAN יבוצע קישורן למרכז רשת ה- WAN (אם מתוכנן כזה). אופי הקמה זה יאפשר רמת שליטה מרבית על הקמת הפרויקט, פעולת מערכות החל מרגע גמר ההתקנות באתר (ללא צורך בהמתנה לגמר התקנה באתר אחר) ושליטה מרכזית על הרשת החל מהרגע הראשון.
בהגדרות התחזוקה יש לברר היטב מהן הדרישות האמיתיות לרמת התחזוקה הנדרשת (תוספת שעות פעילות פירושה הרבה כסף). על דרישות התחזוקה לקחת בחשבון את הגורמים הבאים:
· סיווג המערכות לקריטיות ולא קריטיות,
· השעות בהן יוזמן השירות,
· זמן התגובה המקסימאלי להגעת טכנאי,
· הזמן המרבי לתיקון,
· ציוד חליפי,
· תחזוקה מונעת,
· עדכון גרסאות תוכנה,
· נהלי תחזוקה נדרשים,
· מתן אפשרות לתחזוקה מרחוק (ע"י מודם, נל"ן, VPN)
תוצר התיעוד המרכזי של המערכת הוא תיק מערכת "מתגלגל" לאורך מחזור החיים: מסמך ייזום, תיק אפיון, בקשה להצעות (אם יש פנייה לספקים), תיק עיצוב וכו'. תיק המערכת בנוי על בסיס עץ מערכת ייחודי (מתמחה) אשר מותאם למערכות תקשורת. עץ מערכת מתמחה זה מבוסס מצידו על עץ המערכת האוניברסלי של מפת"ח ומכיל רק תוספות ודגשים מיוחדים. לפני העיון בעץ המערכת יש אפוא לעיין היטב בקיט עץ מערכת אוניברסלי (בכרך יסודות) ובפרט בגלופת עץ מערכת רמה 3 שם. בכל סעיף בעץ המערכת המתמחה בו אין שינוי לעומת עץ המערכת האוניברסלי נשאר שם הסעיף בלבד ללא פרוט נוסף. רכיב שאינו רלוונטי לרשת המוקמת, יש לפסוח עליו, אך להיצמד למספור של מפת"ח.
רשתות תקשורת מחשבים הן מרכיב מרכזי במערך המידע והייצור של ארגונים רבים וכתוצאה מכך, גדלה והולכת הדרישה:
· להקטנת עלויות הקמה ותחזוקת הרשתות,
· להרחבה ושיפור השירותים הניתנים ע"י הרשת,
· לבניית הרשת באופן שיתאפשר שילוב טכנולוגיות חדשות
תקנים, בייחוד אלה המקובלים על קבוצה גדולה של ארגונים בארץ ובחו"ל, הם אמצעי מרכזי ביותר להשגת מטרות אלה, בשל הסיבות הבאות:
· תקנים מפשטים את ההגדרה של תכונות המוצר הנדרש ומאפשרים ליצרנים לספק את דרישות הלקוחות באופן פשוט ובייצור סדרתי, דבר המשפר באופן ניכר את עלות/תועלת המוצרים. קביעה זו נכונה בפרט בתקני/מוצרי תקשורת.
· תקנים מאפשרים הגדרת מבדקים קבועים ומוסכמים לעמידת המוצרים בדרישות.
· תקנים מבטיחים יכולת הידברות של מערכות שונות, ללא צורך בהמרה מסביבה אחת לאחרת.
· תקנים מאפשרים החלפת חלקים מהמערכת הכוללת ללא שינוי בחלקים האחרים.
עם זאת, נושא התקינה ברשתות תקשורת הוא סבוך ביותר וקשה להגדיר תקנים קבועים בשל הסיבות הבאות:
· שינויים טכנולוגיים תדירים
· בעיות בתמיכה בשפה העברית
· כמות התקנים
אי לכך, הגישה שננקטה במפת"ח היא להשאיר את נושא התקינה לרמה הפרטנית של הגדרת תיק האפיון, בהתאם לדרישות הארגון הספציפי ולמומחיות המקצועית המלווה את הפרויקט. שים לב שברכיבים רבים בתיק המפורט יש הפניות ואזכורים לתקנים ברמה הפרטנית (ראה רכיב 3.12 למשל).