כמה מילים על אחסון גיבוי בענן (חלק 1/2)

הערת עריכה
הטקסט במאמר זה מדבר אך ורק על אחסון גיבוי ולא על שרות גיבוי

cloud backup

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

יתרון גדול שיש בימים אלו לתחרות – הוא המחיר הנמוך שאתה יכול להשיג אחסון לגבות את התוכן שלך. גוגל, לדוגמא, מציעה תמורת 10$ לחודש – 1 טרהבייט אחסון (במסגרת Google Drive). גם מיקרוסופט, Dropbox ואחרים חתכו מחירים וניתן לראות טבלה מעודכנת כאן.

כל אותן חברות מציעות Client ידידותי למשתמש שברגע שאתה מתקין, הוא מיד מתחיל להעתיק את כל התמונות, מסמכים ומוסיקה שלך לענן ולבצע בעצם סינכרון. כך הן מנסות "לנעול" את המשתמש (במיוחד מיקרוסופט עם Windows 8 ו-OneDrive). עוד לא הגענו לשלב שבו שרות אחת חוסם שרות מתחרה על אותו מחשב, אבל אני לא אתפלא אם זה יצוץ "במקרה" בעתיד. (הערה: בשרות הזה אני בהחלט ממליץ להשתמש כדי לגבות דברים אישיים שלך כמו מסמכים, תמונות, מוסיקה, ותכנים אישיים שנמצאים ב-My Documents שלך. המאמר כלל אינו מכוון לאחסון גיבויים כאלו או בשיטה שאותם שרותים משתמשים).

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

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

מנסיוני, אני דווקא מציע לבצע גיבויים לא לאחסונים הללו, אלא לאחסון היותר "עסקי" – גיבוי בענן  בטכנולוגיה כמו S3 של אמזון או Cloud Storage של גוגל או Azure Block Blob Storage של מיקרוסופט (הם כולם אותה טכנולוגיה), וזאת ממספר סיבות:

  1. מבחינת מחירים – אינך משלם מחיר FIXED לאחסון שאתה לא משתמש ברובו אלא הינך משלם רק על מה שאתה משתמש בפועל.
  2. ישנם הרבה יותר כלים מקצועיים לגיבוי גם ב-Windows וגם ב-Linux/BSD לאחסונים אלו
  3. אתה יכול לאחסן עם אותו כלי גיבוי (לפחות בלינוקס) לשרותים שונים ולאזורים גיאוגרפיים שונים, אם לדוגמא אינך רוצה לאחסן באזור של הדוד סם
  4. באחסון כמו Cloud Storage של גוגל, ניתן לקבל קישור ישיר פשוט (שלא עובר דרך JS כדי להסתיר את המקור) של הקובץ. כך לדוגמא ניתן לשתף קישור של קובץ ISO וניתן אפילו לעשות Boot ב-IPMI עם קישור כזה (תאר לעצמך מצב שאתה צריך ISO דחוף עכשיו כדי להפעיל שרת…)
  5. אינך מוגבל בגודל האחסון, כך שסקריפט/אפליקציית גיבוי שלך לא יכשל לפתע רק כי נגמרה לך החבילה.
  6. זה זול. גוגל לדוגמא גובה 0.026$ פר ג'יגהבייט, אמזון גובה 0.030$ פר ג'יגהבייט, ושוב – התשלום באחסון הוא על הכמות שאתה מנצל.
  7. עלויות תעבורה – מכיוון שאנחנו מדברים על גיבויים, אין לנו עלות ממשית על תעבורה כי הכל יוצא מהשרת שלנו אל הענן ועל תעבורה נכנסת – לא משלמים.
  8. שרידות הרבה יותר גבוהה.

כפי שאתם שמים לב, אני מתייחס רק לאחסון גיבוי בענן שנמצא בחו"ל ולא בארץ והסיבה לכך פשוטה: מה שכאן מוצע בארץ הוא שרות שמבחינה טכנית הוא הרבה יותר נחות בהשוואה למה שמוצע בחו"ל. כאן בארץ שמים שרתים ודיסקים עם RAID או קופסת NETAPP, גובים מחירים מטורפים – וזה האחסון שתקבל. מה יקרה אם מחר נופלת התקשורת לאותו Data Center? יבטיחו לך שיש שרידות, אולם כמו שראינו רק לפני חודשים ספורים – הבטחות לחוד ומציאות לחוד. לעומת זאת, כל הטכנולוגיה של S3 מדברת על Multiple Data Center ועל כך שהחומר נמצא במספר מקומות במקביל, ולכן אינני ממליץ על האחסון ה"עסקי" של בזק או ספקים מקומיים אחרים.

בחלק הבא אסביר לגבי אסטרטגיה מומלצת לגבי אחסון גיבוי דרך מערכת לינוקס, מה מומלץ ומה לא.

היכן השרתים מבוססי ARM?

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

תחשבו על כל אתר שיש לו כמה אלפי משתמשים ומעלה. יש שרתי DB ויש שרתים שמריצים את האפליקציות. שרתים אלו ימשיכו לרוץ עם מעבדי Xeon כי המעבדים האלו נותנים תוצאות מעולות מבחינת ביצועים, אולם יש גם שרתי Front End, אלו מגישים בד"כ לדפדפני הגולשים תוכן שהוא כבר מעובד – תמונות, JS, HTML וכו', כלומר שרתים אלו אינם מריצים עיבודים רציניים וכל העיבודים הרציניים נעשים על ה-Back End. היתרון בתצורה כזו היא שאתה חוסך גם בחשמל בצורה ניכרת וגם בקירור (עם ARM בד"כ תצטרך קירור פאסיבי או מאוורר קטן או 2, תלוי כמובן מה הציוד שיש באותו שרת).

נשמע טוב, אז מדוע אין שרתים כאלו?

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

ARM כבר שחררו מפרט ארכיטקטורה למעבדי 64 ביט (ARMv8-A) וגם מפרט ל-2 מעבדים: ה-A57 ו-A53. שוב, אלו אינם מעבדים שלקוחות יכולים לרכוש אלא רק תכנונים ומפרטים שחברות יצרני חומרה רוכשים רשיון, מוסיפים דברים משלהם למעבד (אם בכלל) ומשלבים בציוד שאותו בסוף הם מוכרים ללקוחות.

ואז מתחילה בעיה רצינית שהיתה קיימת לפחות בשנתיים האחרונות.

תסתכלו בכל שרת שיש לכם, ותגלו שלמרות השינויים בין יצרן אחד למשנהו, השרתים הם די זהים ברמת המאקרו. לכולם יש ACPI, לכולם יש BIOS (החדשים כבר מגיעים עם UEFI), ויש פורט רשת לניהול השרת (IPMI). החברות כמובן בונות דברים מסביב כדי לייחד את השרתים שלהם, בין אם זה שילוב ב-AD שקיים ב-Corporate, מערכת ניהול אחידה לכל השרתים ודיווח על תקלות חומרה ועוד, אבל בסופו של יום, התקנת מערכת הפעלה וחיבור השרת נעשה בצורה זהה על כל השרתים, כך שאפילו טכנאי מתחיל יכול להרים שרת בצורה די קלה (טוב, חוץ מההגדרות הפנימיות, ששם עדיף שאיש סיסטם יגדיר).

בעולם ה-ARM לעומת זאת, לא היה שום דבר מהדברים הללו. כל יצרן עם הקושחה הסגורה שלו, אפילו ה-BOOT היה במקרים רבים שונה בין יצרן ליצרן ומבחינת מיפוי חומרה, כתובות וכו', כל חברה לקחה את זה בכיוון אחר, כך שלא היה שום מכנה משותף. בעולם הסמארטפונים והטאבלטים, כל חברה שרצתה לייצר מכשיר אנדרואיד, היתה צריכה לעבוד עם המפרטים והסטנדרטים שגוגל יחד עם חברי ה-Open Handset Alliance קבעו, כך שכיום ציודים כאלו מבחינת רכיבים די זהים אחד לשני (למעט מעבדים ומסכים שונים אך תואמים לסטנדרט)

מי שנכנסו לתמונה הם ארגון Linaro שמורכב מיצרני חומרה ומפתחי מערכות הפעלה. הם החלו לעבוד עם היצרנים. בהתחלה עם AMD ובהמשך חברות אחרות יצאו ממסך הסודיות ויחשפו מוצרים.

המסמך הראשון שיצא ליצרנים הוא מסמך ה-SBSA (ר"ת Server Based System Architecture) והמסמך מתאר את הארכיקטורה ומה יצרנים צריכים להכניס בצ'יפ ויותר חשוב – בלוח אם. אין יותר הגדרות יחודיות פר יצרן.

המסמך השני שיצא שבוע שעבר הוא מסמך ה-SBBR (ר"ת Server Based Boot Requirement) ובו נקבעו החלקי תוכנה והמפרט קישוריות בין החומרה לתוכנה כחובה. דברים כמו UEFI (גירסה 2.4, לשמחת מיקרוסופט), ה-ACPI שמלווה את ה-PC יובא אל מערכות ARM (גירסה 5.1), ה-SMBIOS ולבסוף גם הוסיפו את החלק של תמיכת במספר מעבדי ARM על לוח אחד. בדרך מחקו כבר תאימות ל-16/32 ביט מהסטנדרטים הללו.

מערכת ההפעלה הראשונה שתתמוך ב-ARM לשרתים היא … פדורה 21. הלוח הראשון שיכלול מעבד מבוסס ARM הוא לוח של AMD עם מעבד Opteron A1100. הלוח נראה כך:

 

A1100

בשלב זה הלוח הנ"ל אינו מיועד להכנסה לטסטים או פרודקשן והוא מיועד כרגע לחברות המפתחות אפליקציות. מחירו – אינו זול (3000$) והוא מוגדר כ-Development Kit והואע יגיע עם Fedora 21. (כך שבשלב זה אפשר להזמין דרך AMD אבל הלוח לא יצא לשוק עד כמעט סוף השנה הנוכחית).

בשנה הבאה חברות שמשתתפות בפרויקט יתחילו להוציא שרתים כאלו (גם HP וגם DELL נמצאים בבדיקות סופיות של הלוחות יחד עם Red Hat), ויש כבר התעניינות גוברת מצד מיקרוסופט (שבהתחלה לא רצתה להיכנס לזה) להוציא Windows Server ל-ARM. גירסת RHEL ל-ARM תצא כפי הנראה בחצי השני של שנה הבאה.

כמובן שבשוק הזה, אינטל לא רואה בעין יפה את המאמצים של ARM להיכנס לשוק הזה, לפיכך צפויה להיות תחרות עזה (ונראה כמה הפעם אינטל לא תשתמש בטריקים של שוחד כדי "לעודד" יצרנים לייצר כמה שפחות לוחות כאלו (כמו שהם עשו ל-AMD עם ה-Opteron, מה שכמעט נגמר במשפט ובסוף אינטל שילמה רק קנס וצחקה כל הדרך לכיבוש שוק השרתים)). סביר להניח שנראה את אינטל שוב חוזרת עם מעבדי ATOM לשרתים (ה-C2758 לא ראה עדכון כבר שנה ומחירו יקר – 208$ למעבד לבד עבור יצרן הלוחות, הצ'יפ לא ניתן לרכישה ללקוח סופי).

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