OpenStack - ענן בקוד פתוח, חלק ב'

בפוסט זה נדבר על שירותי OpenStack (בקיצור: OSK) שאינם שירותי ליבה. בכל זאת - חלקם מאוד שימושיים!

את השירותים אחלק ל-2 קבוצות:

• שירותי אחסון (Swift, Cinder ו Trove)
• שירותים אחרים (Heat ו Ceilometer)

הקשרים בין השירותים השונים של OpenStack

שירותי האחסון (Storage)

כשירות בסיסי, OpenStack מספק 3 צורות אכסון:

• Ephemeral (קצר-טווח, מיושם ע"י Cinder) 
• Block (מיושם ע"י Cinder)
• Object (מיושם ע"י Swift)

להזכיר: Cinder הוא המקביל ל (EBS (Elastic Block Storage של אמזון, ו Swift הוא המקביל של S3.

שירות נוסף שכללי בקטגוריה הוא שירות Trove שהוא בעצם רק storage-related: הוא אחראי על provisioning אוטומטי של instances של בסיסי-נתונים.

Block Storage (שם קוד: Cinder)

משמעות השם Cinder הוא גחלת - פחם שחדל לבעור, אך הוא עדיין חם.

Cinder הוא שירות הפשטה וניהול של Backends של אחסון. בצד אחד הוא מנהל מערכות אחסון נתונים קיימות (כמו netapp או EMC) ומצד שני הוא חושף API של הקצאת שטח אחסון (מופיע כדיסק SCSI) ל VM שרץ על נובה.

ה Ephemeral Storage מוקצה למכונה כ"דיסק מקומי" וזמני. ברגע שה VM "יורד", התוכן שנשמר בבלוק שהוקצה - יימחק.

ה Block Storage גם הוא מוקצה ל VM ספציפי, אולם אם נותק מה VM - הנתונים שעליו עדיין יישמרו. עליו נשמור את הנתונים הייחודיים / בעלי המשמעות במכונה. בדומה ל EBS, ניתן בכל שלב ליצור snapshot של הבלוק, עבור גיבוי או שכפול.

מדוע הוא שימושי?

נניח אנו רוצים לעבור ממכונה m1.small למכונה גדולה יותר m1.large, או בין תמונת-דיסק ("Image") של Padora ל RHEL (הפצות שונות של לינוקס). ברגע שאנו משתמשים ב Block Storage אנו יכולים לנתק אותו מ VM אחד - ולהקצות אותו מיד ל VM חדש, מבלי לבצע העתקה ארוכה. יש בעיות עם RHEL? נקים מחדש VM של Padora ונחזיר אליו את ה Storage.

לסינדר יש דרייברים לספקי אחסון שונים (פתרונות NAS או SAN) התומכים בפיצר'ים השונים, עבור גרסאות שונות של OSK). ניתן למצוא כאן את טבלת הדרייברים הזמינים והיכולות הנתמכות.
ניתן להשתמש במקביל בכמה Storage Backends.

בכל פעם שאנו מבקשים בלוק שיוקצה ל VM, התהליך Cinder-Scheduler מחפש את הבלוק המתאים ביותר הזמין במערכת - ומקצה אותו.

Object Storage (שם קוד: Swift)

בעוד Cinder הוא יחסית פשוט (הוא בעיקר מנהל מערכות Storage חיצוניות), שירות Swift הוא מורכב יותר. לפעמים מריצים את Swift כשירות עצמאי, ללא שימוש ב Stack המלא של OpenStack.
Swift היא הטכנולוגיה מאחורי שירות ה cloud-files, של Rackspace.

Swift היא מערכת מבוזרת, fault-tolerant, אלסטית, ו eventually consistent לאכסון אובייקטים. מלבד העובדה שגודל האובייקטים הוא עד 5GB (ניתן לקונפיגורציה) - היא דיי דומה לכמה בסיסי-נתונים NoSQL מסוג K/V מוכרים.

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

כל התקשורת מול הצרכנים של סוויפט נעשית דרך שרת(י) ה Proxy של סוויפט, בעזרת REST-ful APIs (כלומר: על גבי HTTP). ניתן לחבר ל Proxy שירות Caching (בד"כ Memcached) לטיפול מיידי בבקשות הנפוצות ביותר.

סוויפט הוא multi-tenant בצורה מובנה, וכל tenant מקבל הפרדה מגישה של tenants אחרים. מלבד יכולת (יחסית ייחודית?) של multi-tenancy, סוויפט גם נחשב קל / יעיל מאוד לניהול.

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

סוויפט מחזיק כמה סוגי של שרתי (או תהליכי) consistency לצורך זה:

• Auditors רצים ברקע על כל שרת של סוויפט וסורקים את הדיסקים לוודא את תקינות המידע עליהם. אם יש תקלות - הקובץ מועבר ל quarantine area, ועותק "בריא" של הקובץ (זוכרים? יש יתירות) - מועתק במקומו.
• Updaters מוודאים שה metadata על הקבצים הוא נכון ועקבי. הם גם מנהלים counters על כמות האכסון, ומספר האובייקטים, וכו' ברמות הניהול השונות. בגדול, סוופיט מגדיר accounts (שהם ה tenants), בתוכם ניתן להגדיר containers (כמו תקיות) ובתוכם מנהלים את האובייקטים.
• Replicators מוודאים שיש מספיק יתירות של קבצים במערכת. מספיק? ע"פ הגדרות SLA - כמובן. שמירת היתירות היא משימה עקבית, כי מדי-פעם קבצים מתגלים כשגויים או שסתם שרתים "נופלים".

על סוויפט לבדו, ניתן לכתוב ספר שלם. בעצם... כבר כתבו (ועוד אחד, ועוד אחד)

DBaaS (שם קוד: Trove)

כפי שציינתי, שירות Trove ("אוצר בלום") הוא לא שירות אחסון, אלא שירות הקשור לאחסון. הוא אמור לפשט את המשימה של התקנה של בסיס נתונים. יש המתארים אותו כ "Database as a Service".

מדוע בסיס נתונים הוא שונה מכל VM אחר? הרי ניתן בעזרת נובה ל"הרים" VM עם תמונת-דיסק מוכנה בזמן קצר מאוד - ועליה יכול להיות בסיס נתונים.

מייד אפרט את היתרונות שיש בשירות כמו Trove, אולם הסיבה שאלו דווקא בסיסי נתונים כנראה נעוצה בכך שבסיסי נתונים הם נפוצים מאוד. באותה המידה היה הגיוני לעשות שירות דומה ל Applications Servers. אולי... במידה, זה מה ש PaaS עושה. אז מה Trove מסייע לנו לעשות ב instance של בסיס הנתונים שהוקם?

• ניהול משתמשים בבסיס הנתונים / ניהול הרשאות על אובייקטים בצורה מרכזית.
• Backup / Restore מנוהל בקנה מידה גדול, או Patching.
• ניהול Quota.
• Vertical Scalability פשוט לניהול: שינוי גודל הזיכרון / כח מחשוב / דיסק - ע"פ ה workload באותו הרגע.
• ניטור מצרפי ו diagnostics.

ניתן למצוא היום את Trove בכמה מוצרים בפרודקשן:

• Cloud Databases של Rackspace
• HP DBaaS
• eBay (שימוש פנימי)

כרגע Trove תומך רק ב MySQL ותואמים שלו (MariaDB, Percona), אולם יש תוכניות קונקרטיות לתמוך ב MongoDb, Cassandra, Redis, CouchBase ועוד, וכן לתמוך בקונפיגורציות High Availability של MySQL. יש להזכיר שהוא רק שוחרר בגרסת (IceHouse (2014 - ויש לו עוד הרבה לאן להתפתח.

מקור: Mirantis

שירותים אחרים

OpenStack Orchestration (שם קוד: Heat)

Heat הוא הגרסה של OSK ל CloudFormation של אמזון.
שירות זה דומה במטרתו לשירות תמונות-הדיסק (שם קוד: Glance), אך הרזולוציה שבה הוא עובד היא של landscapes שלמים.
ה landscape הרצוי מתואר בקובץ בפורמט HOT (קיצור של Heat Orchestration Template. נקרא גם בקיצור Template), קובץ שהוא human readable, ושניתן לערוך ידנית.

הנה דוגמה של קובץ HOT בסיסי ביותר, המבקש שירות של nova להרצת image מסוים על מכונה קטנה:

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      key_name: my_key
      image: F18-x86_64-cfntools
      flavor: m1.small

בעוד Glance מדבר ברזולוציה של תמונת-דיסק, Heat מקשר אותה גם לחומרה, רשת, הגדרות משתמשים וקונפיגורציה. בקובץ ה HOT ניתן להשאיר משתנים חסרים - שאותם יתבקש המשתמש למלא בזמן שהוא מבקש הקמה של Landscape ע"י התבנית המדוברת, בכדי להפריד בין הגדרת ה HOT file, לבין הפעלה שלו בוריאציות שונות.

OpenStack Monitoring & Billing (שם קוד: Ceilometer)

ה Ceilometer הוא מכשיר שמודד בעזרת לייזר את גובה העננים (לצורך חזאות). אני מניח שמקור השם משרבב בתוכו את המילה Ceiling (תקרה).
שירות זה הוא מעט יותר SaaS-י באופיו: הוא אוסף את נתוני השימוש של לקוחות (פנימיים או חיצוניים) במשאבי הענן לצורך חיוב. את מידע ה billing ניתן להזין למערכות חיצוניות (למשל: מערכות ERP).

אפילו במקרה של ענן פרטי פנים ארגוני, יש הרבה היגיון ומוטיבציה לחייב את הגופים השונים (שיווק, מכירות, כח-אדם) ע"פ מידת השימוש שלהם במשאבים. Ceilometer מתחבר לשירותים האחרים של OSK שיש להם משמעות של שימוש במשאבים (למשל: נובה או Cinder), ואוסף מהם את נתוני שימוש.

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

שימוש חשוב של Celiometer ו Heat ביחד הוא Auto-Scaling:

• Ceilometer עוקב אחרי ה nodes השונים ומזהה את עומס העבודה שלהם.
• ברגע שיש treshhold מסוים של שימוש - הוא מדווח על כך ל Heat.
• ב HOT file של HEAT יש הוראות כיצד לבצע up/down scaling - ו HEAT פועל ע"פ ההנחיות בכדי להפעיל / לכבות VMs ולהתאים את השירותים הרצים ל Scale הנדרש.

סיכום + הקשר ה PaaS-י

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

• Designate - שירותי DNS (כלומר: Domain Name Server)
• Marconi - שירותי Message Queuing
• Barbican - שירותי Secure Storage
• Sahara - שירותי Data Processing / Big Data מעל Hadoop
• Mistral - שירותי תזמון משימות / Workflows

אתם בוודאי יכולים לזהות דפוס דיי ברור:

מלבד Designate (וביחד עם Trove ואולי גם Ceilometer) - אלו הם בעיקרון שירותים שמתאימים יותר להגדרה של PaaS מאשר IaaS.

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

יכולת מרכזית שחסרה בתמונה, שבלעדיה OpenStack לא יחשב כ PaaS היא הרזולוציה של ה deployment וניהול ה "Compute": הרזולוציה היא עדיין של VM ולא של אפליקציה.

ובכן, OpenStack מריצה ברקע עוד שני פרויקטים Solum ו Murano שעושים ממש את זה: Solum הוא יותר ברמת המפתח שרוצה לעשות Deploy לאפליקציה כלשהי, ו Murano הוא יותר קטלוג של אפליקציות ספציפיות מקונפגות מראש - להן יהיה ניתן לעשות deploy "בלחיצת כפתור".

כרגע הפרויקטים (Solum הוא המשמעותי בין השניים) הם בשלבים ראשוניים, ולא נחשבים לשחקנים חשובים בעולם ה PaaS. מי שרוצה PaaS על גבי OSK משתמש לרוב ב OpenShift או CloudFoundry.

בכל זאת, כאשר משתמשים בפתרונות כמו CloudFoundry או OpenShift יש כפילויות פונקציונלית בין המערכות: 

• Authentication
• DNS & Messaging (בקרוב)
• Load Balancing
• Dashboard & Monitoring
• וכו'

כפילות זו ברורה לכל משתמש עסקי.

מצד שני, בעת הפיתוח של Solum, קהילת OSK לא מוכנה לקבל ב Solum כפילויות מול פונקציונליות שקיימת כבר (+ באינקובציה) ב OSK. להישאר DRY (קרי: Don't Repeat Yourself).
Solum מקבל המון מ OSK, אבל הוא גם נאלץ להשתמש בשירותים שיועדו להיות אופטימליים ל IaaS ולא ל PaaS - וכנראה שלא תמיד כ"כ מתאימים.

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

מה יהיה?
כבר כמה אלפי שנים שאין נביאים בארץ ישראל. נחכה ונראה.


שיהיה בהצלחה!

-----

לינקים מעניינים:

"CloudFoundry ו OpenStack - זיווג מגן-עדן"
"OpenShift ו OpenStack - זיווג מהעננים"

מה עדיף?! עננים או גן-עדן?