מאמרים

[הזחל הכחול]

סוף סוף../images/Emo70.gif חברה גדולה החליטה ליישם Z/Linux

אחת מחברות המחשוב הגדולות בעולם הכריזה לאחרונה על ביצוע קונסולידציה ל-4000 שרתי linux הממוקמים ב-6 אתרים שונים אל תוך 30 שרתי Z שיריצו Z/linux החברה צופה חסכון של כ-250 מיליון דולר בתהליך.... רוצים לדעת מי

 

[kayoram]

ניטור תקלות במערכות מחשב מרכזיות

להל"ן link למאמר העוסק בנושא בקרת רמת השרות של מערכות IT בארגון: מהן הבעיות וכיצד לחצי הארגון מוטלים על כתפי הממונים על הטיפול בנושאי תקלות ומניעתן. המאמר מציע גם דרך טכנית לשיפור משמעותי בטיפול ומניעת התקלות. ......הנחת המוצא שלנו היא שכולנו מקצועיים, כולנו רוצים לפתור את הבעיות ולכולנו יש סיבות מצוינות, עסקיות ואישיות לכך שכל התקלות יפתרו. אולם, לאמיתו של דבר, לרובינו אין מתודולוגיה מסודרת לטיפול בתקלות!........... כותב המאמר הינו יורם קריב, מנכ"ל חברת ConicIT - www.conicit.biz www.conicit.biz/Heb_IT_Manager_s_Nightmare.pdf

 

[הזחל הכחול]

מאמרים

שרשרו כאן מאמרים בנושאים הרלוונטים לתחום....

 

[הזחל הכחול]

הכרזה ../images/Emo70.gif

היטאצ'י ודטה איסלנדיה משיקים שירות מיקור חוץ לאירכוב נתונים הידידותי ביותר לסביבה

שימוש באנרגיה גיאותרמית והידרואלקטרית - שמירת איכות הסביבה

התמודדות עם נפחי נתונים ענקיים

מדיניות מתוחכמת לניהול מחזור חיי הנתונים

טיפול בסיכונים

סקלביליות ברמת פטה-בייט

חסכון בשטח, הספק ומיזוג בחדרי המחשב

שימוש מושכל במשאבים מצ"ב קובץ המתאר את תמצית ההכרזה (בעברית) כפי שהופצה ע"י חברת HDS ישראל

 

[גלעד פרץ]

זה ממש נהייה הטרנד

החדש כל הירוק הזה... הדגם הבא של IBM לאחר ה-Z9 (כחול) יהיה כנראה ירוק (-:

 

[הזחל הכחול]

MainFrame חדש - יש דבר כזה ../images/Emo70.gif

יבמ התקינה מחשב מרכזי חדש במשרד השיכון ... http://www.pc.co.il/Index.asp?CategoryID=72#art17686

 

[idanliraz]

היום כולם יורדים מזה אבל לא?

עוברים ל-JAVA ORACLE משהו כזה לא? או לפחות יוניקס

 

[הזחל הכחול]

מי לא היה רוצה $300M

IBM קונה את חברת XIV... http://www.ynet.co.il/articles/0,7340,L-3489429,00.html בגדול מה שעושה החברה הזו הוא לייצר מערכת גיבויים חכמה - בהערכה גסה כ-80% מהמידע בגיבויים שמבוצעים מידי יום במערכות המחשוב של הארגון זהים לגיבויים שבוצעו בתקופות קודמות המערכת שפותחה ע"י החברה מאפשרת שמירה רק של המידע שהשתנה ובכך מקטינה את נפח הגיבוי והמידע המיוצר ע"י הארגון.....

 

[diskman]

זה אחסון מתקדם

חברת XIV מיצרת מערכות אחסון כאשר הרעיון המרכזי שלהם זה שימוש בדיסקי SATA ועל ידי כך להוזיל את עליות האחסון וליתר את נושא ה ILM בעולם האחסון שלכם DISKMAN

 

[גלעד פרץ]

זה לא מסוכן?

לאחסן מידע של MF על דיסקי SATA?

 

[צליל קסום]

SATA, ILM

אשמח להסבר על המושגים.

 

[הזחל הכחול]

תיקון ה-LINK

 

[צליל קסום]

זו הבעיה איתם.

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

 

[צליל קסום]

בקרת רמת שירות \ ניבוי עומסים

סליחה על דברי הכפירה, אבל על הבעיה הזו כבר מדברים יותר מעשרים שנה. אחת לכמה זמן יש פרסומים על מתודולוגיה לפתרון הבעיה ועל מוצרים שעוזרים לפתור את הבעיה, אבל הבעיה לא נעלמת. אבל היי, זה לא אומר שהיא לא תיפתר בעתיד, צריך להיות אופטימיים. בכל זאת, במבט לאחור, נדמה לי שהדרך האפקטיבית היחידה להתמודדות עם לקוחות זועמים היא להוזיל את עלות המשאבים כך שלארגון לא תהיה בעיה להצטייד ברזרבות גדולות מאד ביחס לצרכים, בלי שזה יעיק יותר מדי על תקציבו. תסתכל על התחרות שהייתה על שוק התקשורת המקומית. Token Ring ו-ATM היו פרוטוקולים נורא מתוחכמים, אבל Ethernet יכולת לקבל הרבה ובזול. כולנו יודעים מי ניצח.

 

[גלעד פרץ]

זה לא כ"כ נכון

ישנם ארגונים בעולם שבאופן מוצהר אומרים אנחנו לא מתעסקים בניהול ביצועים יש חוסר במשאבים - נוציא את הארנק - נקנה עוד CPU, עוד זכרון נחזק את המחשב... האם ארגונים אלו לא עומדים בסוף מול שוקת שבורה? נראה שכן, כי ישנם מצבים שבהם לא משנה כמה משאבים יש לך במקרה שמסלול ל-DB2 נבחר בצורה לא נכונה כי מישהו עשה Rebind ומיליוני הפעלות של ה-package בדקה גורמים לעצירת המערכת אז יקח עוד 5 דקות עד שהמחשב יעצר כי יש יותר משאבים... אבל בסוף המחשב ייעצר... החוכמה היא לדעת לזהות את המגמות האלה ולהתריע לאנשי הסיסטם (או בדוגמא שלי ל-DBA) בשלב מוקדם של התהליך ע"מ שניתן יהיה למנוע את התקלה... ואז הלקוח יקבל את השרות, אתר הארגון יהיה זמין וכ'...

 

[kayoram]

בקרת ביצועים - תגובה לתגובה

השלמה/תגובה לגלעד באופן עניני נושא הרכישות הוא נכון, אולם בד"כ התקלות אינם נובעות מחומרה אלא מכשלים לוגיים. כתבת כי מישהו בחר מסלול db2 לא אופטימאלי ואז יש חשש לדגרדציה בביצועים ולכשל כולל, זה ממש נכון אולם ההידרדרות לא מתרחשת ב 5 דקות אלא ב 10 שניות. נסה לדמיין אפליקציה ב db2 שנועלת טבלה מאוד שימושית ואז, במערכות גדולות הבעיה (נעילה) מתרחבת לבעיית זיכרון (פעילויות לא מסתיימות) ונגמרת ב CPU נמוך. כל זה במספר שניות בלבד. בשלב זה קורה שהנעילה משתחררת ואנו רואים תקיעה שנובעת מ"בעיות זיכרון/CPU נמוך". זה די קשה לפענח בזמן אמת, ובמבט היסטורי רוב המידע הלוגי שמתייחס ביחסים של "בין המשאבים" איננו מצוי בקבצי LOG כך שזה לא ממש עוזר לנו. הרבה ארגונים גדולים כיום כבר לא נמצאים במצב אפשרי של "יש זמן לטפל בבעיה" ומכיון שכך, נוצר קונפליקט בין הצורך העסקי לבין יכולות ומטדולוגיות ברורות לפענוח וריפוי , וכמובן בין סיבוביות התשתיות (כגון ריבוי שרתים) שהולך מסתבך כל יום. לסיכום ברצוני לסיים בכך שאחר מעשה ובאותם מקרים שהצלחנו בפענוח התקלה, הסיפוק הוא גדול, אולם, נודה על האמת, התקלות בהרבה מקרים הן פשוטות אולם לפענח אותם בכדאי להבין שהן פשוטות זהו כבר סיפור אחר.

 

[גלעד פרץ]

לא הבנתי אז מה

בעצם אתה אומר? הרי כאשר אנחנו נתקלים בתקלה - בד"כ אנו נתקלים כבר בסימפטומים ומורידים מעלים מה שנראה קשור.. כדי להחזיר את המערכות לאוויר בהקדם האפשרי... התהליך לאחר מכן הוא לנסות לחקור דרך ה-LOG, LOGREC וכ'... ולנסות לאתר את תחילת התקלה ולזהות את המקור שלה.. לאחר מכן אם אין ברירה מתחילים לנתח SMF ולהוציא מידע מכלים כמו EPILOG וכ'... האם יש דרך אחרת לעשות את זה (מלבד להקצות צוות אנשי סיסטם שיושבים מהבוקר עד הערב ובוהים ב-SYSVIEW או דומיו?)

 

[zBigBlue]

בקרת ביצועים מול מחיר

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

 

[צליל קסום]

מסכים איתך בנוגע לתקלות.

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

 

[zBigBlue]

תמחור מול משאבים

ידידי, לכל דבר יש מתודולוגיה, השאלה היא מה בוחרים ואיך מיישמים ואוכפים. ישנם כלי בקרת תצורה (MF ו-OPEN) אשר מכילים פרמטרים קשיחים אשר אמורים לבלום התפתחות לרעה של זמני תגובה של טרנזקציות למיניהם (CICS, DB2 וכיו"ב). למניעת חוסר במשאבים כתוצאה מגידול בלתי צפוי מתבססים היום מרבית הארגונים המתוקשבים המסחריים בעולם בכ-30% גידול במשאבי עיבוד מבחינת תכנון קבולת שנתי (חברת "מרקורי" בעבר עשתה מזה הרבה כסף מטכנולוגיית What-IF). מסכים שישנם מצבים שמתודולוגיה לא תעזור, אך בחירות נכונות ואכיפה יצמצמו התקלות לכמעט אפס. לדוגמא, בניית סביבת דמוי ייצור או דומה לה, שבה כל שינוי בייצור עובר דרכה ואישורה. אלה שיטענו שסביבה כזו יקרה ומסרבלת, ימשכו את טענותיהם בתקלה הראשונה שתכלול נזקים כספיים ועסקיים. הנושא רחב מאוד, וכולל בתוכו טכנולוגיות רבות של QA ו- CMMI וכלים רבים לבדיקות תוכנה שמתפתחים מיום ליום ואשר יצרו תפקידים חדשים כמו בודקי תוכנה וחברות מתמחות. לצערי, קצת מסוכן לסמוך על תכניתנים על כל נסיונם, אשר עובדים היום בלו"ז צפוף ומורכב.