<
יום שבת , ינואר 20 2018
מבזקים
דף הבית > חומרות > מערכות וציודים אחרים > אחסון בעידן הענן: אל תינטשו את בסיס האם

אחסון בעידן הענן: אל תינטשו את בסיס האם

storage_ILLUSTRATIONאני כנראה מסגיר את גילי המופלג כאשר אני מספר על הימים שמכרתי דיסקים קשיחים (Winchester קראו להם) במחיר המפתה של אלף לדולר למגהבייט (כן, מגהבייט, לא טרה-בייט ואפילו לא גיגהבייט) והפיתוי היה, תאמינו או לא, המחיר. אצל המתחרה  IBM הוא היה גבוה פי 3. והמחיר הנ"ל לא כלל בקר, ממשק סטנדרטי או תוכנה. זה היה כונן OEM בנפח 5 מגהבייט מזווד במארז 4U-19" במיוחד ליצרני מערכות "מיני" של תחילת שנות ה-80.

היצרנים אוכלים את האבק

מאז עברו כ-35 שנים וחוק מור עשה שמות בעסקי הכוננים. 90% מהיצרנים "השליכו את המגבת לזירה", כפי שאומרים מאמני האגרוף, והשאר למדו להסתפק בשולי רווח דקים כפרוסת ג'אמבון בסנדוויץ פריזאי. מצד שני, המחיר למגהבייט ירד ב-7 סדרי גודל; גודל הכונן הצטמק לבערך 4 פרומיל מהכונן "הקומפקטי" שנחטף על ידי יצרנים של מערכות "ניידות" (כמו מצלמות גרעיניות); הביצועים הואצו פי 20 והאמינות שופרה פי 200 (כפי שמודד הפרמטר MTBF). לאור זאת, מה הפלא שהיום מאגרי הנתונים של ארגונים ופרטיים מכילים בעיקר Junk שלאף אחד אין זמן וחשק למיין ולזרוק את המיותר? המנמ"רים התרגלו לקנות, מנהל הכספים לשלם והטכנאים להעמיס עוד ועוד כוננים לארונות ה-SAN. מה שהיה פעם "אבזר היקפי" צמוד למחשב הפך לחגורת שומן המקיפה את חדר השרתים באלפי דיסקים, הסובבים ללא הרף וזוללים חשמל בלי בושה.

בחברה גדולה בה ביקרתי לאחרונה הסביר לי המנמ"ר את האתגרים של אחזקת מחסן נתונים בנפח של 20 פטה-בייט. "מדובר ב-5,000 דיסקים שממלאים מעל 20 ארונות, צורכים 200 קילוואט חשמל ועושים רעש של מנסרת עצים", הוא התחיל. "אבל מה שגרוע עוד יותר הוא קצב הקריסות. למרות שכל כונן בפני עצמו יכול להתפאר ב-MTBF של רבע מיליון שעות (30 שנות עבודה רצופה), ההסתברות שביום מסוים לפחות אחד מהם יקרוס היא כ-40% (תרגיל לחובבי ההסתברות: כמה זה 0.9999 בחזקת 5,000?). זה מחייב אותנו להשתמש בתצורת RAID מורכבת במיוחד, שתורמת גם היא להוספת כוננים ולצריכת הספק. שלא לדבר על אתר ההמשכיות העסקית, בו שמור העתק כמעט מלא של סביבת ה- Production, ועל מערכת הגיבוי שמבוססת גם היא על דיסקים כקו ההגנה הקדמי. בסך הכל, אני חתום על יותר מ-10,000 כוננים, מתחזק רשת תשתית (ה-Fabric) שמזכירה לי את דיאגרמת החיווט של נושאות מטוסים (20 שנה ב-Navy האמריקאי) ועל מחויבות בלתי אפשרית לספק שירות "חמש תשיעיות" (99.999% זמינות). העמידה בדרישות SLA  כבר אפילו אינה עניין של כסף. הדבר הטוב ביותר שאני יכול להציע להנהלה זה Graceful Degradation, מושג שאני לא חושב שקיים בעברית".

קיצור תולדות האחסון

הדרך מה-Winchester של שנות ה-70' למפלצות האחסון הנוכחיות עברה במספר תחנות ראשיות. החשובות שבהן, למיטב זכרוני, היו:

  • Downsizing – מעבר מכוננים ענקיים, מונוליטיים ויקרים להפליא למערכי RAID, ראשי תיבות שפירושם "מערך דיסקים זולים בתצורת יתירות". במקום לקנות דיסק יחיד בגודל מכונת כביסה, בו סובבים 10 או יותר תקליטים בקוטר 11 עד 14 אינטש, חסכנו כסף בקניה של 5 עד 9 כוננים קטנים (5.25 או 3.5 אינטש) ובקר חכם, שידע להפעיל אותם כתזמורת מסונכרנת היטב.
  • Farming – מעבר מחיבור ישיר של הדיסקים לשרת (תצורת Direct Attachment) לתצורת "רשת אחסון", SAN, בה בקר חכם מטפל בכל המורכבות של פיצול מערכת הקבצים בין כל הכוננים ב"חוות הדיסקים" – כך שהשרת (ה-Host) רואה "דיסק וירטואלי" יחיד עם נפח גדול מאוד, למעשה נפח "נזיל" שמשתנה דינמית ככל שמוסיפים כוננים ל-SAN.
  • Networking – פיתוח הקונספציה של "אחסון רשת", NAS, בה הדיסקים צמודים ל"מכשירים" (Appliances) המשמשים כשרתי אחסון אוטונומיים ומחוברים לרשת תקשורת מקומית. זה פתרון זול יותר מ-SAN אבל המחיר הוא ירידה מסוימת בביצועים. הבדל לא פחות משמעותי הוא, ששרתי עיבוד הנתונים לא רואים "דיסק וירטואלי" אחד אלא מערך שירות קבצים מבוזר, שדומה במקצת לצורת האחסון ברשת האינטרנט.
  • Flash – הכניסה של כונני מצב מוצק (SSD), בהם רכיבי זיכרון מסוג Flash מחליפים את הדיסקים המגנטיים עדיין בעיצומה. מאחר והגישה לזיכרון מצב מוצק היא "אקראית" (כלומר לא צריך לחכות עד שהתקליט יסתובב והראש יגיח למסלול הנכון), הביצועים של SSD יכולים לחולל מהפך בביצועי יישומים הדורשים גישות אקראיות תכופות לפיסות מידע בדידות המפוזרות בהרבה קבצים על פני מערכת האחסון. דוגמה קלאסית ליישומים כאלה הם אלה שנופלים בקטגורית Big Data. המחיר למגהבייט SSD עדיין גבוה ביחס לדיסק שמסתובב – ולכן משתמשים בטכנולוגיה בעיקר כדי להנגיש מידע עבור מערכות זמן אמת, כ"מטמון" (Cache) למערכות Production עמוסות, וביישומים שדורשים עמידות בתנאי סביבה קשים, כמו רעידות, חבטות, אבק ונוזלים.
  • Online Backup – היציאה לפנסיה של אחסון בטייפים מגנטיים. אלה שימשו בעבר בעיקר לגיבוי וארכוב, אבל עם הזמן התברר שכל הקונספציה התיישנה. עצם המושג Offline Storage יצא משימוש כאשר פער המחיר בין קלטת טייפ לדיסק זול עם נפח דומה הצטמצם מאוד. גורם נוסף היה האמינות המפוקפקת והביצועים המקרטעים של רובוט הטייפים. ביותר מדי מקרים התברר (באיחור, אחרי שהאסון כבר הלם בארגון) שהשחזור של מערכת שקרסה מהטייפ לא מצליח ב-100 אחוז או נמשך זמן רב מדי; שהזמן החסר, בין הגיבוי האחרון עד הקריסה, ארוך מדי (כי גיבוי מלא היה אפשרי רק מחוץ לשעות העבודה, רצוי סופשבוע); או שטייפ שהוקלט על כונן אחד אינו בר קריאה על אחר. הארגונים החלו לדרוש גיבוי רצוף – ללא חלונות זמן בהם המערכת מושבתת – ואפשרות לחזור אחורה למספר נקודות זמן במקרה ומתגלה צורך בשחזור (למשל לאתר את נקודת הזמן האחרונה לפני שווירוס החל להשתלט על המערכת). הפתרון לדרישות החדשות ניתן בשיטה הנקראת "הבזקי צילום" (Snapshot), העתקת "תמונת מצב" רגעית של האחסון מהכוננים הראשיים לכונני גיבוי, בדרך כלל לדיסקים זולים בעלי קיבול גדול ודרישות אנרגיה נמוכות. במערכות מסוימות אפשר לשמור גם חצי תריסר תמונות הבזק כאלה, שנלקחו במחזוריות של שעתיים-שלוש לכ אורך יום העבודה.
  • SDS – אחסון מוגדר תוכנה, Software Defined Storage, הוא מהלך השואב את השראתו ממגמת הווירטואליזציה של שרתים, שכבשה את ה- Data Centerבמאה ה-21. מבחינה טכנית הדגש הוא על החלפת רכיבי חומרה בפונקציות תוכנה, כך שתכונות המערכת נקבעו על ידי התוכנה שרצה על השרתים (מערכת ההפעלה) במקום הקוד הצרוב בבקרים (ה-Firmware של המתגים והנתבים). אחסון מוגדר תוכנה משחרר את ארכיטקטורת האחסון ממגבלות של הומוגניות וסקלאביליות ומאפשר גמישות רבה בעיצוב תצורת המערכת וזריזות בביצוע התאמות לצרכים משתנים. הוא גם עוזר למנמ"ר להתגבר על המחסור הכרוני בכוח אדם טכני, משום שכמעט כל השינויים ניתנים לביצוע מקונסולת הניהול המרכזי – לפעמים גם באופן אוטומטי.
  • Storage in the Cloud, אחסון בענן – הרעיון, לאחסן את המידע במערכת האחסון של ספק שירות באינטרנט במקום ב-SAN או NAS מקומי, מניח כמובן שהיתרון לגודל של הספק יותר ממפצה כלכלית על החסרונות התפעוליים של תקורת תקשורת משמעותית. גם אם השקעתם הון בחיבור סיב אופטי מה-ISP עד ה-Datacenter שלכם, רוחב הפס האפקטיבי של תקשורת אינטרנטית נופל בשני סדרי גודל מרוחב הפס האופייני של Fabric חדיש ב-SAN מקומי. עם זאת, השימוש המתפשט בשירותי "פלטפורמה", PaaS, יוצר צורך באחזקת לפחות חלק מהנתונים בקרבת שרתי הפלטפורמה, כלומר בענן. האתגר הוא, אם כך, איך למנוע מצב בו מיקום האחסון מגביל את האפשרויות לבחור ספק פלטפורמה או ספק יישומים מנוהלים (SaaS) בחופשיות. מבחינה מעשית זה אומר, שרצוי לבחור ספק שירותי אחסון המחזיק מספר גדול יחסית של חיבורים ישירים מהירים מאוד לספקי פלטפורמות שונים – בהחלט לא דבר שקל למצוא היום. לחילופין, צריך למקם את מערכת הגיבוי אצל ספק שירות אחסון אחר, כך שבשעת הצורך זו תשמש "ראש גשר" להעברת הפעילות בין ספקי פלטפורמות.

מאבדים שליטה ומבזבזים כסף

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

תוך זמן קצר מגייס הקיסר השאפתן "עוזר אישי לנושאי IT", בדרך כלל צוציק שעוד לא הפנים את המציאות מחוץ ל"יחידה המובחרת" בה הוא רכש את מיומנותו המקצועית, והבחור לא מהסס לפתוח את כל הסכרים נגד הצפת מידע ובזבוז משאבים שמיסדנו מאז שנות ה-80'. היום, כשאני מסתכל על משאבי האחסון עליהם מתבזבז רוב התקציב, אני רואה כפילויות פראיות. לכל אימפריה כזאת צמודה מערכת אחסון מנופחת, בה נשמרים העתקים של כל אלמנט תוכן דיגיטלי שעבר ברשת הארגונית בשנתיים האחרונות. כולל תמונות מיום הכיף וסרטים שהופצו על ידי עובדים משועממים. עשרות העתקים כאלה, משום שאף "עוזר אישי" לא חושב שבאחריותו לסנן משהו במתודת Dedup. כשאני מעלה את הנושא בישיבות הנהלה, מסתכלים עלי ברחמים, "עוד לא למד, המסכן, לא לבלבל את המוח שלנו עם מושגים מיושנים של המאה ה-20. תזרום, אל תחפור!".

ראיתי מנמ"רים מאושרים

לא כל המנמ"רים מיואשים. למעשה פגשנו מנמ"רים מאושרים גם בארגונים שהחליטו להזיז כל מה שאפשר לענן. "צריך להבין כי לפחות בעתיד הקרוב מחשוב ענן אינו שחרור מוחלט מהצורך להחזיק Data Center פרטי, בשליטה ישירה של מחלקת ה-IT, ובמרכז המחשבים הזה תתפוס מערכת האחסון מקום מרכזי", אומר צ'רלי קרטר, אחד היועצים הידועים לניהול תשתיות מידע. "אין בעיה להוציא לענן את מרבית היישומים, את עיבוד הנתונים ואת ביצוע התהליכים העסקיים. אלה דברים עם "טביעת עקבות" (Footprint) רדודה, פעילות רגעית שקל לנייד אותה בין ספקים שונים. אבל האחסון הוא מאגר הזיכרון הארגוני, המקום בו נשמרים נתונים בעלי ערך עומד, שאי אפשר להתחיל יום עבודה חדש בלעדיהם. הרבה יועצים מדברים על כך שאת "יישומי הליבה" צריך להשאיר "בענן פרטי" – ואני מדגיש שהאחסון הוא יישום הליבה החשוב ביותר. גם אם זו תהייה המערכת האחרונה לשכון ב-Data Center שהתרוקן משרתים, אני לא אוותר על מערכת אחסון מגובשת, מאוחדת, מנוהלת במקצועיות וממוקמת מאחורי חומות האש של הארגון. יכול להיות שזו תהייה בסך הכל "צומת מסילות ברזל" או "מרכז לוגיסטי" לנתונים שיידרשו על ידי משתמשים שונים בעננים שונים, אבל זה יהיה בשליטתי. גם לא אכפת לי אם במקום לקרוא לי מנמ"ר יקראו לי מנמא"ר, "מנהל מערכות אחסון ראשי", ובלבד שלא יפרקו את התחום לרסיסים ויחזירו אותנו אחורה 50 שנה, לימים של תיוק ידני, כאשר אף מנהל לא ידע מה שמור בקלסרים של מחלקה אחרת. אז דיוני הנהלה קריטים רבים הפכו לוויכוחים חסרי תכלית, הנתונים של מי נכונים יותר. לא זו ההבטחה של מחשוב ענן".

הרגולציה, שמחייבת את הארגונים לשמור מידע מסוים גם אם אין לו יותר ערך אקטואלי מבחינה עסקית, מוסיפה רובד של מורכבות לנושא האחסון בענן – במיוחד בתחומים שמחייבים גידור גיאוגרפי של אתר האחסון. מנמ"ר גרמני אמר לי שהתקנות בנושא הפרטיות של מידע רפואי מכפילות את עלויות האחסון שלו. "אני חייב לוודא שהמידע לא יוצא מעבר לגבולות המדינה, למרות שמבחינה כלכלית כדאי לי מאוד לבנות Data Center בפולין או בצ'כיה", הוא אומר. " למזלי, בשטח שהיה פעם מזרח גרמניה עדיין אפשר למצוא משרדים בזול ועובדים שמוכנים לעבוד בשכר הגיוני. מצד שני, אני מחויב באסטרטגית המשכיות עסקית והתאוששות מאסונות שכוללות יתירות כפולה. לא רק מערכת Production חסינה במושגים של רגולטור גרמני, גם שני העתקים של כל מה שחיוני לצורך רציפות השירות. הצורה בה אנו עובדים משקפת את מלוא חומרת הבעיה. במרכז החברה, בפרנקפורט, ממוקמת מערכת ה-Production, הכוללת שתי תמונות הבזק מתחלפות בגיבוי "פינג-פונג". כשהאחת נגמרת מתחיל הצילום לשנייה. התמונות האלה מועתקות, בפינג-פונג המתרחש ברקע, ב-Background, לשתי מערכות הגיבוי המרוחקות, אחת בברלין והשנייה בפלייפציג. במילים אחרות, כל קובץ שמור אצלנו ב-5 עותקים, עם חותמות זמן בהפרש של כשעה. אי אפשר לקצר את זמן המחזור, כי זה הזמן שנדרש להעתיק תמונה מפרנקפורט ללייפציג. קשה לי לחשוב על סכמת עבודה שמבזבזת יותר משאבים".

 

הבעיות של עמיתנו הגרמני לא יפתרו בהברקה טכנית – משום שהן מושרשות בתפיסת עולם רגולטורית, קרי פוליטית. בגרמניה לא מעגלים פינות ולא מקצרים תהליכים, כי סדר חייב להיות (Ordnung muss sein, בשפת המקור).אבל אפשר ללמוד מהנחישות שלו להגן על המידע לדורות, גם הרבה אחרי שהוא יצא לפנסיה. לא לחינם מודפס על נייר המכתבים של החברה, "נוסדה ב-1872".

אודות יהודה אלידע

עורך ראשי. במהלך חצי יובל השנים האחרונות ביסס יהודה אלידע את מעמדו המוביל בין העורכים והפרשנים של טכנולוגיות מידע בישראל, הודות לרקע מדעי (MSc בפיזיקה ממכון ויצמן), ניסיון ניהולי (15 שנה בשיווק וניהול חברות בישראל ובחו"ל), גישה אנליטית ומחויבות לעיתונאות אחראית. יהודה אלידע ייסד, ניהל וערך את המהדורה הישראלית של PC Magazine ואת NET Magazine וב-12 השנים האחרונות הוא העורך הראשי של IT מגזין, מוסף המחשבים של גלובס, בנוסף לאחריותו על התכנים המקצועיים של פורטל IT News.
נגישות