פיצוח האניגמה שנקראת אמזון EBS

השבוע מלאו ל”חץ ביז” שנתיים במזל טוב (כתבתי פוסט על כך כאן), לא היה קל, אבל בהחלט כיף.

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

בעסקי ה-Hosting, בניגוד למצבים שחברות צריכות להתמודד, הדברים שונים. חברה רוכשת לדוגמא שרתים ו-Storage מתוך ידיעה שיש צורך בציודים וההשקעה מחזירה את עצמה בכל מיני דרכים, בחסכונות פה ושם, קונסולידציית שרתים, איחוד ציודים ועוד. ב-Hosting לעומת זאת, הדברים שונים לחלוטין. אתה לא יכול לרכוש פתרון של Netapp או EMC ולצפות שהלקוחות ישלמו לך כמה דולרים פר ג’יגהבייט, כי אף אחד לא ישלם לך את המחיר הזה, וגם חברות גדולות כמו Softlayer לומדות את הלקח הזה על בשרן (הם הכניסו SAN גדול, הלקוחות לא קופצים על זה, כך לפחות נאמר לי ע”י אחד המנהלים הישראליים שם).

לאמזון יש דבר שנקרא EBS, זהו פתרון Storage אשר מתחבר לך לשרתים שלך שאתה שוכר באמזון (EC2) וכך אם נהרסת לך המכונה, הנתונים נשמרים. הפתרון כמובן חיוני אם אתה מפעיל מספר שרתים בתצורות כמו Load Balancing ועוד.

המחיר שאמזון מוכרת את שרותי ה-EBS גרם לאנשים רבים (כולל עבדכם הנאמן) לגרד בפדחתם ולנסות להבין איך הם מצליחים לתת שרות כזה ולמכור אותו במחיר רצפה של 10 סנט לג’יגהבייט!

רבים שאלו את אמזון מה המערכת שעומדת מאחורי ה-EBS מבחינת מפרט ברזלים, תוכנות וכו’, ועד היום, אמזון לא מגלה מאומה. על שאר השרותים כמו EC2, או S3 והשאר, כולם יודעים איך להקים דברים כאלו, אבל EBS… אניגמה.

ידוע לנו שהמחיר הוא 10 סנט, מה שמביא לתובנות הבאות:

  • אין דיסקים SAS – לא חשוב כמה אמזון תהיה הדארלינג של יצרני הדיסקים הקשיחים, אם זה היה דיסקים עם חיבור SAS ומהירות גבוהה (10000 או 15000 RPM) המחירים היו טסים למינימום 1-2 דולר לג’יגהבייט.
  • אין בקרי RAID משוכללים, כי הבקרים הללו לא זולים. סביר להניח שיש על לוח האם חיבור SAS עם מפצלים ל-SATA. סביר להניח שמוגדר RAID-5 או RAID-1 (על כל דיסק, דיסק נוסף משמש כ-Mirror). צריך לזכור: השרתים הללו לא מריצים שום וירטואליזציה או דברים כבדים אחרים.
  • הדיסקים הם דיסקים “ביתיים”, הווה אומר דיסקים SATA גדולים במהירות 7200 RPM או פחות מכך.

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

מכאן נעבור לרשת של EBS.

EBS בעקרון אינו דבר מהיר כל כך. כל פתרון SAN חומרתי עוקף כל EBS בקלילות מכיוון ש-EBS נותן בתיאוריה מהירות מקסימלית של 1 ג’יגהביט (128 מגהבייט) לשניה. המהירות כמובן צונחת אם גם השכן שלך מחליט להשתמש ב-EBS שנמצא על אותו שרת פיזי (אפשר לקרוא בהרחבה על כך כאן).

השאלה היא מהו החיבור בין שרתי ה-EBS לשרתי ה-EC2. אני מניח שמדובר בחיבורי Ethernet של 10 ג’יגהביט פר שרת עם CAT 6A וסוויצ’ים שכל פורט מגיע עד 10 ג’יגהביט, אבל הבעיה בהנחה הזו שהמחיר הוא מאוד גבוה. סוויצ’ שיכול להעביר 240 ג’יגהביט (24 חיבורים של 10 ג’יגהביט כל אחד) הוא מאוד מאוד יקר, גם אם הוא יהיה בהוזלה משמעותית עבור אמזון, מה שמייקר מאוד את פתרון ה-EBS, כך שאני לא בטוח אם זה הפתרון שהם משתמשים. פתרון אחר הוא Bonding של מספר יציאות 1 ג’יגהביט מהשרת (כמו עם כרטיסי 4 פורטים) מה שנותן בתיאוריה רוחב פס של 4 ג’יגהביט, אבל גם זה לא נראה לי שהפתרון נכון.

מהרשת נעבור לבעיה הכי מהותית: איזו תוכנה יודעת לבצע RAIN אך גם לייצא לך החוצה Block Devices כך שתוכל להקים דיסקים של EBS? מי שמכיר את אקליפטוס (Eucalyptus) ויסתכל על הפתרון שלהם, השיטה שלהם היא שימוש ב-iSCSI הרגיל שקיים בלינוקס (או אם תחבר SAN, תצטרך להשתמש בפתרון iSCSI מתוך קופסת ה-SAN שלך עם הכלי של יצרן ה-SAN). יש פתרון Cluster של Red Hat שאפשר לראות אותו כאן, אך אני בספק אם זהו פתרון שיכול להתאים.

מה דעתכם? אם אתם הייתם צריכים להקים משהו כמו EBS עם ערימת שרתים בלי SAN ולתת throughput של 1 ג’יגה, מה אתם הייתם מכניסים? איזה כלים הייתם משתמשים?

מדוע כרום Frame הוא כן רעיון טוב

רבים מכירים את הדפדפן של גוגל, הלא הוא דפדפן כרום שמצטיין בביצועים מהירים, קוד קטן (יחסית), תמיכה ב-Threads ועוד. גוגל שחררה לאחרונה גם “אח” קטן לכרום, הלא הוא ה-Chrome Frame.

הכרום Frame תפקידו הוא בעצם משהו אחד: להיות מעין “תוסף” שמתממשק לאינטרנט אקספלורר (6,7,8) ולתת לאדם חוויה של גלישה מהירה עם אבטחה, כאשר מבחינה חיצונית בתפריטים של אקספלורר, לא רואים שום שינוי, כלומר מבחינת המשתמש: התוסף שקוף.

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

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

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

מי שמכיר חברות גדולות, בנקים, חברות ביטוח ואחרות (כאשר יש בכל אחת מהחברות מס’ אלפי מחשבים) יכול לראות בקלות מה קורה במחשב של משתמש ממוצע: אקספלורר מותקן ומציג את האפליקציות הפנימיות שמחלקת הפיתוח כתבה עם כלים שונים. התצוגה נכתבה באפליקציה עם מחשבה על אקספלורר (ולפעמים על אקספלורר מסוים). רבים ממוצרי מיקרוסופט מייצרים בעצמם קוד דינמי שעובד מעולה על אקספלורר אך לא על דפדפנים אחרים (המצב השתפר מאז 2007, אבל עדיין אתרים דינמיים פנימיים שמוצגים עם דברים כמו SharePoint נראים יותר טוב באקספלורר מאשר על השועל. מנסיון.). הצצה בקוד של האקספלורר (אני מדבר על View Source מתוך הדפדפן) מציג קוד שזה יהיה נס משמיים אם דפדפן אחר יצליח להציג. רוצים להתנסות? בשמחה! התקינו וורד 2003, ייבאו מסמך וורד ובקשו לשמור את הקובץ לאחר מכן כקובץ HTML. פתחו את קובץ ה-HTML שנוצר והביטו בקוד. מומלץ לקחת שקית הקאה לפני הניסוי.

מכאן יוצא כי חברות רבות משתמשות בכלים של מיקרוסופט ומס’ כלים אחרים כדי לתכנת אפליקציות שיוצגו מעולה על אקספלורר, אך עקב “סיבות שונות” אין הן מוצגות טוב על השועל או דפדפנים אחרים. לשם שיפור העניין, יש צורך בשינוי מאסיבי שלא מקבל בד”כ תקצוב ובכך המפתחים לא עובדים על כך שהאפליקציה תוצג טוב בדפדפנים אחרים.

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

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

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

כך בעצם אותה חברה שתשתמש בכרום Frame לא רק שתגן על השקעתה, אלא שהתקנת הכרום Frame תתן להם גם אפשרות להתקדם קדימה מבלי שהמשתמשים יאלצו ללמוד דפדפן חדש וערימת בעיות חדשה.

מי אמר שלא ניתן לרקוד על 2 חתונות במכה אחת? 🙂