במאמר הקודם, דיברתי על נושא של איתור תקלות ברשתות ארגוניות. הפעם אני רוצה לכתוב כמה מילים על נושא תכנון הרשת הארגונית, וכמו שאומרים, תכנון טוב, יכול בהרבה מאוד מקרים למנוע את הצורך באיתור תקלות. מה שאביא כאן זה כמובן לא את כל התורה (ויש הרבה פרקים…), אלא מספר כללים בסיסיים לתכנון רשת שיחסוך הרבה צרות (וכסף) בהמשך.
במאמר זה, אני מעוניין לדבר על מספר נושאי תכנון:
- מבנה וצרכים של מערכת מידע ארגונית
- תהליך התכנון (Design Process)
- ניתוח דרישות (Requirement analysis)
- תכנון תנועה וקיבולות (Traffic engineering and capacity planning)
בפרקים הבאים, נדבר לעומק על:
- תכנון הרשת המקומית (LAN)
- תכנון הרשתות המרחביות (WAN)
- תכנון רשת ה- IP, כולל כתובות ופרוטוקולי ניתוב
- תכנון אבטחת מידע ברשת
- תכנון התחזוקה והניהול (Management, control and operations)
- תכנון שרידות וזמינות הרשת (High Availability Design)
אז בואו ניכנס לפרטים.
- מבנה וצרכים של מערכת מידע ארגונית
אז על מה אנחנו מדברים? על תכנון התשתיות למערכות הארגוניות, באופן שהתשתית תהיה שקופה למשתמש, ובכל יישום שהוא יעבוד, מול כל שרת או תוכנה, המשתמש לא יתלונן על "איטיות", "ניתוקים" ושאר צרות. וכדי לעשות כן, קודם כל חשוב להבין שמערכת מידע מורכבת מ- 3 מרכיבים:
- תוכנות ויישומים – כאשר כל תוכנה וכל יישום צריכים דברים מסויימים מהרשת (ועל כך נדון בהמשך(
- חומרה – תחנות עבודה ושרתים שונים, שלכל אחד הנתונים והמאפיינים שלו
- רשת התקשורת, המורכבת מרכיבי LAN, WAN, אבטחת מידע (FWs וכד'), ועוד
המטרה שלנו תהיה לתכנן את הרשת באופן שכל משתמש, יקבל את מה שהוא צריך מהרשת, מול כל שרת או שרות שהוא עובד מולם.
מהן התכונות שאותן נצטרך לקבל מרשת/קווי תקשורת? 4 תכונות שאיתם נוכל לאפיין כל קו הינן:
- רוחב פס (Bandwidth), – שאותו נמדוד ב- bps (bit per second). רוחב פס חשוב ביישומים כמו העברות קבצים, דוא"ל וכד. חשוב כמובן לתכנן האם הקו יהיה סימטרי או אסימטרי, מה כיוון התנועה וכד'. כאן אני רואה טעויות תכנון רבות של לקוחות שעובדים ביישומים אסימטריים מובהקים (כמו Terminal או Citrix) שמשלמים הרבה כסף עבור קווים סימטריים, לקוחות שלוקחים קווים רחבים מאוד עבור מצלמות, בעוד שמה שצריך זה קווי ADSL הפוכים וכד. חשוב להבדיל בין רוחב פס כולל (Bandwidth) שאותו אנו רוכשים מספק התקשורת, לעומת רוחב פס אפקטיבי (Throughput) שאומר מה האפליקציה מעבירה בפועל.
- השהיה (Delay/Latency) – שאומרת כמה זמן ייקח למנות להגיע מקצה לקצה. בד"כ אנו מודדים ערך זה בבדיקה פשוטה של Ping והערך שנקבל הינו עבור הלוך-חזור (RTT – Round Trip Time) ערך זה חייב להיות נמוך ככל האפשר. ברשת מקומית יהיה מספר מיקרו-שניות, בקווי WAN מילי-שניות בודדים, בקווי WAN חדשים (MPLS, תמסורת וכד') מספר מילי-שניות, ברשתות סלולאריות חדשות 60-80 מילי-שניות וכד'. ביישומים שרגישים ל- Delay, למשל בסיסי נתונים, VoIP אינטראקטיבי וכד', יש לקחת בחשבון גורם זה.
- שינויים ב- Delay, או Jitter, נמדדים באחוזים (בדיקת PING פשוטה תראה לנו נתון זה) וקריטי ברשתות של Voice. כמובן ש- Delay נמוך מאוד עם שינויים גדולים יעבוד בסדר גמור, אולם Delay של 150mS (האופייני לקווים בינלאומיים), עם Jitter של 100%, יהפוך אפילו את פאברוטי לברווז…
- וכמובן – Packet Loss. כאן חשוב להדגיש – Packet Loss הוא לא אסון. במקרים מסוימים, למשל ב- FTP או ב- HTTP, עד רמה של אחוזים בודדים כמעט ולא נרגיש הבדל בביצועים (בעתיד אפרסם כאן את נושא הביצועים של TCPIP ונראה למה), בעוד במערכות Video Conference יכול לגרום לניתוקים, וגם כאן תלוי ביצרן המערכת.
- תהליך התכנון (Design Process)
כמו שאנו רואים בתמונה, תהליך התכנון כולל את השלבים הבאים:
שלב ראשון – ניתוח רשת (Network Analysis) – בשלב זה, אנו באים לרשת החדשה (או כזאת שאנחנו כבר מכירים), וצריכים לזהות מספר פרמטרים, בינהם:
- מצב הרשת ובעיות קיימות – האם הרשת עובדת באופן תקין? האם ניתן להשתמש במשאבים קיימים (ציוד למשל), האם יש צורך בהרחבות בלבד, או דרוש לבנות הכול מחדש?
- מטרות התכנון – האם המטרה היא התרחבות וגידול? טיפול בבעיות קיימות? חסכון בכסף? איחוד עם רשתות אחרות (למשל עם חברת אם/בת? קישור לסניפים בחו"ל (שכאן אילוצי המחיר הם הקריטיים בד"כ) או סיבות אחרות.
התוצרים של שלב זה יהיו תאור דרישות הרשת – קיבולת רשת דרושה, תרשימי תנועה (Traffic Flows) – נושא בעל חשיבות רבה שעוד נדון בו בהמשך, וכמובן היכן נמצאים משאבי החומרה והתוכנה, שכן לפיהם אנחנו מתכננים את הרשת.
שלב שני – תכנון ברמה גבוהה (High-Level Design) – שלב זה, שאליו אנו מקבלים כ- Input את תוצרי השלב הראשון, הינו שלב חשוב מאוד, שבו אנו נחליט בין היתר גם על:
- ארכיטקטורת הרשת
- סוגי קווי תקשורת
- רכיבי רשת (האם למשל להשתמש במתגי STACK או מודולאריים(
- איזו רמת שרידות נדרשת (קווי תקשורת כפולים, ציוד תקשורת כפול, רשת שרידות בין שרתים וכד'
התוצרים של שלב זה יהיו קווים מנחים לתכנון המפורט שעליו נחליט בשלב הבא.
שלב שלישי – תכנון מפורט (Detailed Design) – בשלב זה, נתכנן את הרשת לפרטיה, כולל הפרטים הבאים:
- תכנון רשת מקומית – סוגי מתגים, L2 או L3, כמה היררכיות ברשת (בד"כ 2 או 3), סוגי ציוד וכד'
- תכנון רשתות WAN – רוחבי פס, נקודות קצה וכד'
- תכנון רשת IP, כולל תחומי כתובות, פרוטוקולי ניתוב וכד'
- תכנון אבטחת מידע, ביציאה לאינטרנט, ברמת המשתמשים, NAC, הצפנות וכד'
- שרידות וזמינות – שרתים כפולים, כרטיסי רשת כפולים, מתגים ונתבים כפולים (HSRP/VRRP), חלוקת עומסים (Load Balancers) וכד'
- ניתוח דרישות (Requirement analysis)
ניתוח הדרישות הינו השלב שבו ננסה להבין, בצורה שיטתית ומסודרת, מה בעצם אנחנו צריכים. נשמע פשוט? זה נכון – זה פשוט, אבל רק אם נעבוד באופן מסודר ושיטתי. והגישה פשוטה – בואו ננסה להבין מה כל משאב צריך מהרשת.
קודם כל, צריך להגדיר, מה בעצם קריטי ומה לא. ובמילים פשוטות, ייתכן שנורא נחמד לקבל רוחב פס גבוה מאוד בין הסניפים, אבל זה עולה כסף. שיקול אחר יהיה מה בעצם אנחנו רוצים להשיג. לדוגמא, לפני שנים, בתכנון מערכת מידע בארגון בינוני (כ- 500 תחנות קצה), נשאלה השאלה איזה תוכנה לבחור לעבודה מול השרתים – Microsoft Terminal Server או CITRIX (Meta Frame). ההחלטה הייתה לעבוד בצורה של טרמינלים, אבל נשאלה השאלה – האם לבחור ב- MS-TS שעלותו הייתה אפס כי היה כבר כלול במחיר הרישיון של התחנות באתר, או ב- CITRIX, שעלותו הייתה אז כ- 400$ לתחנה, כלומר 200,000$ לכל החברה (שהיה אז משהו כמו מיליון ₪.
בבדיקה פונקציונאלית, תוכנת המייקרוסופט עשתה את העבודה. בבדיקת עומסים גם לא היה הבדל. לאחר בדקה זו, המנמ"ר באותו ארגון בחר ב- CITRIX שעלה לו כמיליון ש"ח, לעומת אפס שהיה עולה לו מייקרוסופט. למה??? השיקול היה פשוט – בחברת האם, שהייתה חברה של כמה אלפי משתמשים, עבדו ב- CITRIX. השיקול היה פשוט – בפרוייקט ERP של כמה מיליוני דולרים, אף אחד לא מדד מאתיים אלף דולר נוספים. לעומת זאת, אם היה המנמ"ר בוחר ב- MS-TS ומשהו לא היה עובד, כולם היו באים אליו בטענות למה לא הלך לפי המדיניות של חברת האם (ואולי היה מאבד את עבודתן). אבל כאן אנחנו כבר נכנסים לשיקולים בקבלת החלטות, שזהו נושא מעניין בפני עצמו ….
ולעניין – קודם כל, נדרג את הדרישות לפי 3 רמות:
- דרישה הכרחית (Must/Required) – דרישה הכרחית, וקריטית לעבודה סדירה של החברה. למשל ניתן להגדיר שרידות באתרים מסוימים, למשל מפעלי ייצור, כקריטית, וכל השאר לא.
- דרישה מומלצת (Recommended) – דרישה שהיא ברמת המלצה למנמ"ר, אולם נבחר בא רק בעדיפות שנייה. כך למשל, שרידות ברמה גבוהה לסוכנויות מכירה – נחמד שיהיה, אבל אם חנות (שרשימת המלאי נמצאת אצלה בקופה) תוציא חשבוניות ידניות במקרה של תקלה הקוראת פעם בשנה – לא נורא.
- דרישה ברמה נמוכה (Optional) – לא ניקח בחשבון, או נשקלל ברמה נמוכה בתוך השיקולים שלנו. למשל דוא"ל – אם יעבוד קצת לאט לא נורא, בעיקר אם עולה לנו כסף.
בנוסף לכך, יהיה עלינו להבין את הדרישות של כל אחד ממרכיבי המערכת – החל ממה צריכים המשתמשים (זמינות, מהירות עבודה), היישומים (כל יישום צריך דברים שונים מהרשת), רכיבי הרשת (שרתים, מדפסות, מצלמות אבטחה וכד'), והרשת עצמה (תנועה של פרוטוקולי ניתוב, מערכות שליטה ובקרה וכד')
תהליך התכנון:
ומה לגבי תהליך התכנון? בשרטוט אנו רואים בקצרה את תהליך התכנון.
השלבים הם:
שלב ראשון – איסוף הדרישות – סוג הפרויקט, מטרת הפרויקט ושאלות ראשוניות. בשלב זה נגדיר את מטרות הפרויקט:
- האם זו רשת חדשה, שינויים לרשת קיימת, שיוניים בעקבות תקלות/בעיות רשת, האם מתבצע איחוד רשתות, שינוי לוירטואליזציה וכד'
- הגדרת מטרות הפרויקט – שיפור ביצועים, הוזלת עלויות, תמיכה במשתמשים ו/או יישומים חדשים, שיפור רמת אבטחה ברשת, איחוד רשתות וכד'
2.שלב שני – מטריקות למדידה (Metrics) – שרידות, רוחב פס, Delay, ושאר המטריקות אותן אנו רוצים למדוד ולתכנן לפיהן:
- מה רמת השרידות הנדרשת? מה רמת הזמינות הנדרשת?
- איזה נתוני תקשורת נדרשים (רוחב פס, DELAY וכד'), ומה קורה במידה ולא יסופקו.
3. לפי המטריקות שהגדרנו, נוכל להתחיל ולאפיין את התנהגות הרשת, לדוגמא:
- דפוס עבודה של משתמשים (מתי עובדים ומה עושים)
- דפוס עבודה של יישומים
בפרקים הבאים נרחיב בנושאים אלו.
- תכנון תנועה וקיבולות (Traffic engineering and capacity planning)
בתכנון תנועה וקיבולות נדרשות ברשת,יש לקחת חשבון את הפרמטרים הבאים:
- סוג התנועה – האם התנועה מורכבת מהעברת קבצים (כולל דוא"ל), וידאו, מצלמות אבטחה, שיחות טלפון וכד'
- זמני התנועה – מתי התנועה עוברת, והאם צפויות הפרעות בין סוגי תנועה שונים. כך למשל, אם מבצעים שיחת ועידה ב- HD מעל קווים של 2Mbps בזמן זה יש לצפות להאטה ברשת
כדי לקבל את הנתונים המדויקים של כל יישום יש כמובן לבצע בדיקת רשת קצרה לפני התכנון, אולם בגדול אפשר לומר כי יישומים יצטרכו מהרשת את הנתונים הבאים:
כך למשל עבור העברת קבצים (כולל דוא"ל שהינו גם העברת קבצים) ככל שניקח רוחב פס גבוה יותר נקבל ביצועים טובים יותר, בעוד שאר הפרמטרים כמעט ולא חשובים (כמובן שב- Packet loss גבוה נקבל ביצועים איטיים, אבל Packet Loss של מספר אחוזים בד"כ לא יקרה). ב- VoIP למשל נצטרך רוחב פס נמוך (מקסימום 100Kbps, תלוי בסוג ה- Codec) אבל נושא ה- Delay ובמיוחד ה- Jitter קריטיים וכד'.
ומה לגבי תכנון התנועה? כאן חשוב להזכיר מונח חשוב -Traffic Flow . זהו מונח המציין הינו תנועה המיוצרת על ידי זוג משתמשים, העובדים ביישום אחד. למשל, TF יכול להיות משתמש הגולש באינטרנט, משתמש המתחבר לשרת DB עבור עבודה מול לקוחות, שרת השולח הדפסות למדפסת מרוחקת, שרתים המעבירים הודעות מסוג כלשהו בינהם וכד'. כך למשל, כאשר נרצה לחשב את כל התנועה העוברת ביו אתרים, נחשב את סכום כל ה- TF העוברים בין אותם אתרים. עבודה ביישום מסוים יכולה לגרום ל- TF בודד, למשל העברת קובץ מתחנה לשרת, ולעומת זאת, יכולים להיות יישומים מורכבים, שיגרמו למספר TFs, למשל Citrix Client שמתחבר לשרת, שעליו מותקן ה- DB Client שמתחבר לשרת DB. משלוח הודעת SMS או חיוג ברשת GSM יכול לגרום למספר רב של TFs, ועלינו לדאוג שהרשת תאפשר מעבר לכולם.
בתמונה הבאה, אנחנו רואים את ההשפעה של הוספת מערכת דוא"ל בארגון, כאשר את ה- TFs שלה אנחנו רואים בצהוב.