🥇אחסון ב-Kubernetes: OpenEBS נגד Rook (Ceph) נגד רנצ'ר לונגהורן נגד StorageOS נגד רובין נגד פורטוורקס נגד לינסטור

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

למען האמת, ויתרתי וויתרתי קוברנט (לפחות בינתיים). אני אשתמש Heroku. למה? בגלל אחסון! מי היה מאמין שאתעסק יותר באחסון מאשר עם Kubernetes עצמו. אני משתמש ענן חצנרכי זה לא יקר והביצועים טובים ומרגע ההתחלה אני פורס אשכולות באמצעות חַוַאי. לא ניסיתי שירותי Kubernetes מנוהלים מגוגל/אמזון/מיקרוסופט/DigitalOcean וכו' וכו', כי רציתי ללמוד הכל בעצמי. אני גם חסכן.

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

בדקתי 6-7 פתרונות אחסון:

OpenEBS

כמו שכבר אמרתי בפוסט קודםלאחר שבדקתי את רוב האפשרויות מהרשימה, התפשרתי בתחילה על OpenEBS. OpenEBS קל מאוד להתקנה ולשימוש, אבל למען האמת, לאחר בדיקה עם נתונים אמיתיים תחת עומס, התאכזבתי מהביצועים שלו. זהו קוד פתוח, והמפתחים עומדים בפני עצמם ערוץ רפוי תמיד עוזר מאוד כשהייתי צריך עזרה. לרוע המזל, יש לו ביצועים גרועים מאוד בהשוואה לאפשרויות אחרות, ולכן היה צורך להפעיל מחדש את הבדיקות. ל-OpenEBS יש כרגע 3 מנועי אחסון, אבל אני מפרסם תוצאות בנצ'מרק עבור cStor. עדיין אין לי מספרים עבור Jiva ו-LocalPV.

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

צָרִיחַ

Rook הוא גם קוד פתוח ושונה משאר האפשרויות ברשימה בכך שהוא מתזמר אחסון המבצע משימות ניהול אחסון מורכבות עם backends שונים, למשל. צ'ף, EdgeFS ואחרים, מה שמפשט מאוד את העבודה. היו לי בעיות עם EfgeFS כשניסיתי את זה לפני כמה חודשים, אז בדקתי בעיקר עם Ceph. Ceph מציעה לא רק אחסון בלוק, אלא גם אחסון אובייקטים התואם ל-S3/Swift ולמערכת קבצים מבוזרת. מה שאני אוהב ב-Ceph הוא היכולת לפזר נתוני נפח על פני דיסקים מרובים, כך שאמצעי האחסון יכול לנצל יותר שטח דיסק ממה שיכול להתאים לדיסק בודד. זה נוח. תכונה מגניבה נוספת היא שכאשר אתה מוסיף דיסקים לאשכול, הוא מפיץ מחדש נתונים באופן אוטומטי בין כל הדיסקים.

ל-Ceph יש צילומי מצב, אבל עד כמה שידוע לי, לא ניתן להשתמש בהם ישירות ב-Rook/Kubernetes. נכון, לא נכנסתי לזה לעומק. אבל אין גיבויים מחוץ לאתר, אז תצטרך להשתמש במשהו עם Velero/Restic, אבל יש רק גיבויים ברמת הקובץ, לא צילומי מצב של נקודת זמן. מה שבאמת אהבתי ב-Rook היה כמה קל לעבוד עם Ceph - הוא מסתיר כמעט את כל הדברים המסובכים ומציע כלים לדבר עם Ceph ישירות לצורך פתרון בעיות. לרוע המזל, במהלך מבחן המאמץ של נפחי Ceph, המשכתי להיתקל בבעיות הבעיה הזו, מה שגורם ל-Ceph להיות לא יציב. עדיין לא ברור אם מדובר בבאג ב-Ceph עצמו או בבעיה בדרך שבה Rook מנהל את Ceph. התעסקתי בהגדרות הזיכרון, וזה השתפר, אבל הבעיה לא נפתרה לגמרי. ל-Ceph יש ביצועים נאים, כפי שניתן לראות במדדים למטה. יש לו גם לוח מחוונים טוב.

רנכר לונגהורן

אני מאוד אוהב את לונגהורן. לדעתי זה פתרון מבטיח. נכון, המפתחים עצמם (Rancher Labs) מודים שזה עדיין לא מתאים לסביבת העבודה, וזה מראה. זה קוד פתוח ובעל ביצועים נאותים (למרות שעדיין לא עשו לו אופטימיזציה), אבל לעוצמת הקול לוקח הרבה מאוד זמן להתחבר לפוד, ובמקרים הכי גרועים זה לוקח 15-16 דקות, במיוחד לאחר שחזור גיבוי גדול או שדרוג עומס העבודה. יש לו צילומי מצב וגיבויים מחוץ לאתר של התמונות האלה, אבל הם חלים רק על אמצעי אחסון, כך שעדיין תצטרך משהו כמו Velero כדי לגבות משאבים אחרים. גיבויים ושחזורים אמינים מאוד, אך איטיים בצורה מגונה. ברצינות, פשוט איטי להפליא. השימוש במעבד ועומס המערכת עולה לעתים קרובות כאשר עובדים עם כמות בינונית של נתונים ב-Longhorn. יש לוח מחוונים נוח לניהול Longhorn. כבר אמרתי שאני אוהב את לונגהורן, אבל צריך קצת עבודה.

StorageOS

StorageOS הוא המוצר הראשון בתשלום ברשימה. יש לו גרסת מפתחים עם נפח אחסון מנוהל מוגבל של 500GB, אבל אני לא חושב שיש הגבלה על מספר הצמתים. מחלקת המכירות אמרה לי שהעלות מתחילה ב-$125 לחודש עבור 1 TB, אם אני זוכר נכון. יש לוח מחוונים בסיסי ו-CLI נוח, אבל משהו מוזר קורה עם הביצועים: בכמה מדדים הוא די הגון, אבל במבחן הלחץ על הווליום לא אהבתי את המהירות בכלל. באופן כללי, אני לא יודע מה להגיד. אז לא ממש הבנתי הרבה. אין כאן גיבויים מחוץ לאתר ותצטרך גם להשתמש ב- Velero עם Restic כדי לגבות נפחים. זה מוזר, כי המוצר בתשלום. והמפתחים לא היו להוטים לתקשר ב-Slack.

אדום החזה

למדתי על רובין ב- Reddit מהמנהל הטכני שלהם. מעולם לא שמעתי עליו לפני כן. אולי בגלל שחיפשתי פתרונות חינמיים, אבל רובין מקבל תשלום. יש להם גרסה חינמית די נדיבה עם אחסון של 10TB ושלושה צמתים. בסך הכל, המוצר די הגון ויש לו תכונות נחמדות. יש CLI מעולה, אבל הדבר הכי מגניב הוא שאתה יכול לצלם ולגבות את כל האפליקציה (בבורר המשאבים זה נקרא Helm releases או "flex apps"), כולל אמצעי אחסון ומשאבים אחרים, כך שתוכל להסתדר בלי Velero. והכל יהיה נפלא אלמלא פרט אחד קטן: אם תשחזר (או "ייבא", כפי שזה נקרא ברובין) אפליקציה על אשכול חדש - למשל, במקרה של התאוששות מאסון - השחזור, כמובן, עובד, אבל המשך לגבות את היישום זה אסור. זה פשוט לא אפשרי במהדורה זו, כפי שאישרו המפתחים. זה, בלשון המעטה, מוזר, במיוחד בהתחשב ביתרונות האחרים (למשל, גיבויים ושחזורים מהירים להפליא). המפתחים מבטיחים לתקן הכל עד המהדורה הבאה. הביצועים טובים בדרך כלל, אבל שמתי לב למוזרות: אם אני מריץ את ה-benchmark ישירות על נפח המחובר למארח, מהירות הקריאה מהירה בהרבה מהפעלת אותו נפח מתוך הפוד. כל שאר התוצאות זהות, אבל בתיאוריה לא אמור להיות הבדל. למרות שהם עובדים על זה, הייתי מוטרד מהבעיה בשחזור וגיבוי - חשבתי שסוף סוף מצאתי פתרון מתאים, ואפילו הייתי מוכן לשלם על זה כשאני צריך יותר מקום או יותר שרתים.

פורטורקס

אין לי הרבה מה לומר כאן. זהו מוצר בתשלום, מגניב ויקר לא פחות. הביצוע פשוט מדהים. זהו האינדיקטור הטוב ביותר עד כה. סלאק אמר לי שהתמחור מתחיל ב-$205 לחודש לצומת, כפי שמופיע ב-GKE Marketplace של גוגל. אני לא יודע אם זה יהיה זול יותר אם אתה קונה ישירות. אני לא יכול להרשות לעצמי את זה בכל מקרה, אז מאוד מאוד התאכזבתי מכך שרישיון המפתחים (עד 1 TB ו-3 צמתים) כמעט חסר תועלת עם Kubernetes, אלא אם אתה מסתפק בהקצאה סטטית. קיוויתי שרשיון הנפח ישדרג אוטומטית למפתח בתום תקופת הניסיון, אבל זה לא קרה. ניתן להשתמש ברישיון המפתחים רק ישירות עם Docker, והתצורה ב-Kubernetes היא מאוד מסורבלת ומוגבלת. כמובן, אני מעדיף קוד פתוח, אבל אם היה לי כסף, בהחלט הייתי בוחר בפורטוורקס. עד כה, הביצועים שלו פשוט לא משתווים לאפשרויות אחרות.

לינסטור

הוספתי את הקטע הזה לאחר פרסום הפוסט, כאשר אחד הקוראים הציע לנסות את Linstor. ניסיתי את זה ואהבתי את זה! אבל אנחנו עדיין צריכים לחפור עמוק יותר. עכשיו אני יכול לומר שהביצועים לא רעים (הוספתי את תוצאות ההשוואה למטה). בעיקרון, קיבלתי את אותם ביצועים כמו הדיסק ישירות, ללא כל תקורה. (אל תשאלו למה ל-Portworx יש מספרים טובים יותר מאשר רף הכונן ישירות. אין לי מושג. קסם, אני מניח.) אז לינסטור נראה מאוד יעיל עד כה. זה לא כל כך קשה להתקנה, אבל זה לא קל כמו אפשרויות אחרות. ראשית הייתי צריך להתקין את Linstor (מודול ליבה וכלים/שירותים) ולהגדיר את LVM עבור תמיכה בהקצאה דקה ותמונת מצב מחוץ ל-Kubernetes, ישירות על המארח, ולאחר מכן ליצור את המשאבים הדרושים לשימוש באחסון מ-Kubernetes. לא אהבתי שזה לא עובד על CentOS והייתי צריך להשתמש באובונטו. לא נורא, כמובן, אבל קצת מעצבן, כי התיעוד (שהוא מצוין, אגב) מזכיר כמה חבילות שלא ניתן למצוא במאגרי Epel שצוינו. ל-Linstor יש צילומי מצב, אבל לא גיבויים מחוץ לאתר, אז גם כאן הייתי צריך להשתמש ב- Velero עם Restic כדי לגבות נפחים. אני מעדיף צילומי מצב במקום גיבויים ברמת הקובץ, אבל אפשר לסבול את זה אם הפתרון ביצועי ואמין. Linstor הוא קוד פתוח אך יש לו תמיכה בתשלום. אם אני מבין נכון, ניתן להשתמש בו ללא הגבלות, גם אם אין לכם חוזה תמיכה, אך יש צורך להבהיר זאת. אני לא יודע עד כמה Linstor נבדק עבור Kubernetes, אבל שכבת האחסון עצמה נמצאת מחוץ ל-Kubernetes, וככל הנראה, הפתרון לא הופיע אתמול, כך שהוא כנראה כבר נבדק בתנאים אמיתיים. האם יש כאן פתרון שיגרום לי לשנות את דעתי ולחזור ל-Kubernetes? אני לא יודע. אנחנו עדיין צריכים לחפור עמוק יותר וללמוד שכפול. בוא נראה. אבל הרושם הראשוני טוב. אני בהחלט מעדיף להשתמש באשכולות Kubernetes שלי במקום Heroku כדי לקבל יותר חופש וללמוד דברים חדשים. מכיוון שלינסטור לא קל להתקנה כמו אחרים, אכתוב על זה פוסט בקרוב.

אמות מידה

לצערי, לא שמתי הרבה הערות לגבי ההשוואה כי לא חשבתי שאכתוב עליה. יש לי רק תוצאות ממדדי ה-fio הבסיסיים ורק עבור אשכולות צומת בודדים, אז אין לי עדיין מספרים לתצורות משוכפלות. אבל מהתוצאות האלה אתה יכול לקבל מושג גס למה לצפות מכל אפשרות, מכיוון שהשוויתי אותם באותם שרתי ענן, 4 ליבות, 16 GB של זיכרון RAM, עם דיסק נוסף של 100 GB עבור אמצעי האחסון שנבדקו. הרצתי את המדדים שלוש פעמים עבור כל פתרון וחישבתי את התוצאה הממוצעת, בנוסף איפסתי את הגדרות השרת עבור כל מוצר. כל זה לא מדעי לחלוטין, רק כדי לתת לך מושג כללי. במבחנים אחרים העתקתי 38 ג'יגה-בייט של תמונות וסרטונים מהכרך למבחן קריאה וכתיבה, אבל, אבוי, לא שמרתי את המספרים. בקיצור: Portworkx היה הרבה יותר מהיר.

למבחן הנפח השתמשתי במניפסט הזה:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

תחילה יצרתי נפח עם מחלקת האחסון המתאימה ולאחר מכן רצתי את העבודה עם fio מאחורי הקלעים. לקחתי 1 GB כדי להעריך את הביצועים ולא לחכות יותר מדי זמן. להלן התוצאות:

הדגשתי את הערך הטוב ביותר עבור כל מדד בירוק ואת הגרוע ביותר באדום.

מסקנה

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

מקור: www.habr.com