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 - זיווג מהעננים"

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

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

בפוסט זה אדבר על פרויקט OpenStack, פרויקט ה IaaS (קיצור של Infrastructure as a Service) הפופולרי.
(אם אין לכם מושג מה זה PaaS או IaaS - הנה הפוסט בשבילכם)

בעולם ה IaaS, אמזון נמצאת עם AWS בערך במקום בו הייתה מייקרוסופט לפני 20 שנה עם Windows NT 4.0: במיקום אסטרטגי לכיבוש השוק. אין לה מתחרים ביכולות, בפריסה או במידת שביעות הרצון של לקוחותיה.

OpenStack (בקיצור: OSK) מנסה להיות "הלינוקס של ה IaaS": חינמי, חופשי, פתוח, ומפותח ע"י קהילה. האם יקח גם לו כ 10 שנים לסגור את הפער? (אנשי לינוקס - אל תתרגזו. זו דעתי האישית).

ל OpenStack בהקשר זה יש גם אתגרים: הפרויקט כנראה נולד כצעד הגנתי של חברות IT שעיקר הרווח שלהן הוא בעולם ה On-Premises (קרי: לא בענן) כנגד AWS, גוגל (GAE) או Azure. קבלת החלטות שיטיבו עם OSK אבל יפגעו ברווחים של השותפות המרכזיות - הוא בעייתי. כמו כן, החברות ב OSK מצד אחד אמורות לתרום לפרויקט, מצד שני רבות מהן מוכרות שירותי OSK, ולכן רוצות לשמור יכולות מסוימות שפותחו - רק לעצמן.
אולי בגלל כל צפיפות האינטרסים האלו, קשה למצוא דיונים ביקורתיים ב OSK שנובעים מתוך הקהילה: רוב מה שתשמעו מהחברות הללו הוא PR שבא להאדיר את OSK. חסך בדיונים שכאלו עשוי לפגוע בפרויקט בטווח הארוך.

בהקשר זה כדאי להזכיר גם את פרויקט CloudFoundry (בקיצור: CF), שמנסה להיות ה"לינוקס של ה PaaS" (שכבת ה Platform as a Service). אין עדיין שחקן בולט במיוחד בעולם ה PaaS, אם כי BeanStalk של אמזון מתקדם לשם בצעדי-ענק, וגם MS Azure ו Google AppEngine (בקיצור: GAE) נראים כשחקנים משמעותיים [א].
ל CF יש עדיין מתחרה משמעותית בעולם הקוד הפתוח: OpenShift של Red Hat.אמנם CF זכתה להרבה מומנטום בחודשים האחרונים בצורת חברות שהתייצבו מאחוריה - אולם הקרב עדיין לא הוכרע.


הפוסט מניח שאתם יודעים קצת על:

• טכנולוגיות ענן (עסקתי בהם גם בפוסט2, פוסט3). כדאי גם להכיר מעט על וירטואליזציה.
• מושג כללי אודות שירותי middleware - כגון Authentication & Authorization או Message Queuing.

מקורות 

OSK הוקם ע"י שיתוף פעולה של נאס"א ו Rackspace (חברת server hosting גדולה): שתיהן פתחו תשתיות ענן שנראו דומות - וב 2010 החליטו לשלב כוחות. OSK, כמעט כולו, כתוב בשפת פייטון (Python).

ב 2011 אובונטו (הפצת לינוקס) החליטה לשלב את OSK באסטרטגיה שלה להפוך להפצת הלינוקס הבולטת בענן.

ב 2012 הוקם ל OSK ארגון ניהול ללא מטרת רווח בשם "The Open Stack Foundation" שנועד לקדם את הפלטפורמה, תוך כדי שמירה על עקרונות של פלטפורמה פתוחה המפותחת ע"י שתוף פעולה של קהילה רחבה.
הארגון מורכב מ:

• קהילת מומחים (technical committee) מצומצמת שמתווה את הכיוון הטכנולוגי.
• מועצת מנהלים (24 נציגים, 8 עצמאיים ועוד 16 מחברות תומכות).
• קהילת משתמשים פעילה, הכוללת אלפי תורמי קוד ותיעוד.

ניתן למצוא בוויקיפדיה את רשימת החברים ב2 הפורומים הראשונים.

מאז הצטרפו לפרויקט כ 200 חברות. אפשר לציין את AT&T, AMD, EMC, IBM, HP, Intel ו SAP (החברה בה אני עובד). פרויקט OSK גבר על כמה מתחרים - וכיום הוא פרויקט הקוד הפתוח הבולט ביותר בעולם ה IaaS, ואחד מפתרונות ה IaaS היחידים בעלי הסיכוי להתחרות ב AWS של אמזון.

OpenStack, תומך ב API "תואם אמזון" - כך שבתיאוריה ניתן להריץ אפליקציה שנכתבה עבור AWS (בפועל: בהתבסס על שירותים מאוד מסוימים) על OSK - עם שינויים קלים בלבד.

הגרסאות של OpenStack ששוחררו עד היום. שמותיהן על שמות ערים בעולם - בסדר עולה של ה ABC.

מבנה הפרויקט

OSK בנוי בצורה מודולרית, ומחולקת לשירותים (Services) עצמאיים, סוג של macro-services. רבים מהשירותים ניתנים להחלפה ע"י שירותים חיצוניים - מה שמוכיח את טענת המודולריות.
כל שירות של OSK מנוהל כפרויקט (כמעט) עצמאי, והוא מורכב בד"כ מכמה תתי פרויקטים משלו.
בדומה לפרויקטי קוד פתוח אחרים, פיצ'רים גדולים חדשים מתחילים ב Incubation projects ורק כאשר צוברים תאוצה - מצטרפים כפרויקטים מהמניין. מייד נעבור על השירותים / פרויקטים של OpenStack.

הארכיטקטורה של OpenStack. הסברים בהמשך. מקור: OpenStack documentation

התקנה:

בכדי להתקין OpenStack צריך:

• host OS (בד"כ לינוקס).
• בסיס נתונים (בד"כ משתמשים ב MySQL. אפשר גם PostgreSQL או אפילו SQLLite3 - אך לא בסביבת production)
• Message Queuing Service, בד"כ מתקינים RabbitMQ.

אפשר להתקין את OSK גם על VM ולא ישירות "על הברזלים".

שירותים:

כפי שציינתי, ל OpenStack יש 5 שירותי ליבה, שנדרשים ל(כמעט) כל תצורה:

• Identity Services (שם קוד: KeyStone)
• Compute Services - מה שמריץ את ה VMs. (שם קוד: Nova)
• Image Services - כלומר Images של VMs. (שם קוד: Glance)
• Networking Services - (שם קוד: Nova Networking או Neutron)
• Dashboard (שם קוד: Horizon)

בנוסף יש עוד כמה שירותים שהם extended / אופציונליים - ומותקנים רק במידה והשירותים שלהם מתבקשים. אותם אכסה בחלק השני של הפוסט.

כנראה אחד הדברים שמעניינים הם הקבלה ל Amazon Web Services, שלא יכלו שלא לשמש השראה ל OpenStack:

• Nova דומה מאוד ל EC2, וכפי שציינתי יש לו API תואם EC2 בו ניתן להשתמש.
• Glance דומה מאוד ל AMI Catalog של אמזון
• Cinder (עליו נדבר בהמשך) דומה ל EBS (כלומר: Elastic Block Store) של אמזון.
• Swift (עליו נדבר בהמשך) דומה ל S3, וגם הוא מממש חלקים מה S3 APIs.

אחוזי ההשתפות ב OpenStack, מתוך האתר הרשמי.

שירותי הליבה של OpenStack

Keystone 
זהו שירות ה Authentication & Authorization של OpenStack.
השירות נקרא Keystone מכיוון שהוא חיוני לכל פעילות של OpenStack. הוא מנהל הרשאות של:

• משתמשי-קצה
• שירותים
• Endpoints של שירותים (כלומר: יישות שדרכה צורכים את השירות)

לאחר שמשתמש מבצע login / עובר authentication ראשוני, הוא מקבל מהשירות token שיזהה אותו ולא ידרוש זיהוי מחדש לאורך ה login session הנוכחי.
Keystone תומך במודל של Role-Based Authorization, אותו הסברתי בפוסט הזה.

ניתן לחבר את Keystone לשירותי LDAP חיצוניים ולשירותי Federated Identity כמו SAML (עליהם כתבתי בפוסט הזה). OAuth, עד כמה שידוע לי, עדיין לא נתמך - אך התמיכה בו היא כרגע בפיתוח.

Nova 
נובה היא שירות ה compute של OSK, המנהל את מחזור חיי המכונות (הפעלה / השבתה / התאוששות) בענן של OpenStack. נובה הוא השירות הגדול והמורכב ביותר ב OSK.
שירות נובה לא כולל יכולות Virtualization עצמאיות (כלומר: hypervisor או container[ב]), אלא רק ניהול שירותי VM של צד-שלישי: KVM, Xen VSphere, Hyper-V וכו'.


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

בנובה מגדירים:

• Region (אזור גאוגרפי): התקנה מלאה של OSK, המכילה כמה Availability Zones.
• Availability Zone:  מיקומים שונים שנבנו ברמת ה data center כך שכשל של אחד (שריפה, ניתוק התקשורת, וכו') לא ישפיע על האחר.
• Host) Aggregates): קבוצות לוגיות של מכונות מרוכזות ע"י תכונות, למשל: כמות מסוימת של זכרון (נאמר 128GB), רשת 10G, חומרה מיוחדת, וכו'. קבוצות אלו משמשות ל Queries ולניהול הפריטים בקבוצה יחדיו.

Availability Zones שונים באותו ה Region משתפים את שירותי ה keystone וה Horizon שלהם - לצורך פשטות העבודה של שירותים אלו. 

Nova-Networking

Nova-Networking הוא תת שירות של נובה, המספק (בצורה וירטואלית) שירותי רשת ל VMs שרצים בנובה:

• VLANs ("שכבה 2")
• הגדרת רשתות IP למחשבים ("שכבה 3") - בכמה אסטרטגיות שונות.

VLAN

דבר שעשוי להיות לא ברור הוא הצורך / משמעות ה VLAN:
"אני מכיר VPN, או הפשטות שונות של רשת, אבל מה ההיגיון ב LAN וירטואלי? האם LAN הוא לא הרכיב הבסיסי ביותר עליו עושים את וירטואוליזציית הרשת?!" - אתם עשויים לשאול

בארגונים נהוג לחלק את הרשת הפיסית לתתי רשתות, משיקולי ביצועים (או בעצם SLA של תתי רשתות ספציפיות) ושיקולי אבטחה. למרות שבאוניברסיטה מלמדים עליהם, כבר לא משתמשים היום ב Hubs, Bridges או Repeaters (תרגיל: נסו לקנות bridge של Cisco או HP) - בעצם משתמשים רק ב Switches ("שכבה 2") או Routers ("שכבה 3") שהם חכמים יותר ויודעים למלא תפקידים של Bridge, Hub או Repeater (ע"י Switch) או Proxy ותפקידים אחרים (ה Router). בעוד ש switch ביתי הוא דבר זול מאוד (בערך 100 שקל?), הסוויצ'ים בהם משתמשים בארגונים יכולים לעלות אלפי שקלים. מדוע? בגלל אמינות, ביצועים, ויכולות שליטה ובקרה מתקדמות (SNMP, קנפוג מרחוק, וכו'). תוספת עלות נוספת לארגונים הוא התפעול / תחזוקה של ה swtiches הללו ע"י אנשי IT.

הרעיון של VLAN הוא פשוט מאוד: מחברים את כל המחשבים ברשת הארגונית ל switch יחיד (או מערך משורשר של switches - כשיש יותר מ~50 מחשבים, אולי מחזיקים עותק נוסף עבור redundancy) ואת כל תת-הרשתות מגדירים ע"י קונפיגורציה של ה switch ולא ע"י חיווט ידני. יש לכך תקן - תקן 802.1Q (נקרא בע"פ: "דוט וואן קיו") המוסיף ל header של Ethernet frame שדה חדש בשם VLAN: ערך מספרי בין 0-4095. לכל פורט (חיבור פיסי לכבל) של ה switch - כזה שמחובר למחשב כלשהו, מוגדר VLAN אליו הוא שייך. המחשב עצמו לא אמור לדעת שהוא נמצא ב VLAN - רק ציוד התקשורת (שאלו בעצם ה switches) מודע לשדה זה. כל הודעת Ethernet שנכנסת מהמחשב ל switch דרך הפורט תסומן בתגית עם מספר ה VLAN שהוגדר (נאמר VLAN מס' 3). כל הודעה שיוצאת מה siwtch דרך הפורט למחשב כלשהו - תוסר ממנה תגית ה VLAN (כי המחשב לא אמור להכיר אותה). תגיות אלו משמשות רק בתוך ה switch ובין switches שמחוברים זה לזה דרך "Trunk Ports".

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

ממשק ניהול של Enterprise Switch, לא גן ילדים

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

לגבי הגדרות IP למחשבים ("שכבה 3"), nova-networking תומכת בכמה מודלים:

• Flat Networking - המחשבים מקבלים IP בזמן ה boot. ייתכן ש tenents שונים יקבלו כתובות IP עוקבות, זה לא אמור לשנות.
• Flat DHCP - המחשבים מקבלים כתובות IP ע"י שירות ה DHCP של OPK (הדרך הנפוצה יותר). 
• VLAN Manager - ה Tenant הוא זה שמספק למחשב את ה VLAN וכתובת ה IP המתאימה ביחד.
• Flat and Private: המחשב מקבל כתובת בתוך הענן במודל Flat Networking ועוד כתובת לרשת פנימית שייחודית רק עבור ה Tenant אליו הוא שייך.
• גישה אחרת הנקראת "Provider Router" מגדירה לכל tenant "רשת-על" משלו, שהיא מחוברת לתת-רשתות פנימיות שה tenant הגדיר. וכו'.

הרבה פעמים מחברים כל מחשב בענן ל2 רשתות: רשת פנימית לצריכת שירותי ענן / תקשורת עם nodes אחרים, ורשת נפרדת לתקשורת עם האינטרנט. יש כמה וכמה גישות, וכמה trade-offs שיש לשקול בכל גישה. אלו עניינים ברמת תכנון ה landscape וה Operations.

Project Neutron (לשעבר Quantum).

שירות נובה של OpenStack הלך ונהיה מורכב, ולאורך הגרסאות התחילו להתפצל ממנו שירותים נפרדים. למשל: nova-volume שדאג להקצות שטח דיסק (וירטואלי כמובן, בפועל האכסון נעשה על NAS או פתרון דומה) לכל מחשב, השתכלל לשירות Cinder עליו נדבר בהמשך. ה APIs של nova-volume עדיין עובדים - הם פשוט קוראים היום ל Cinder.

גם שירות ה nova-network נהיה מורכב, מצד אחד, ולא מספיק גמיש - מצד שני.
Open Stack Foundation החליט להקים את פרוייקט Quantum (שהיו בעיות על זכויות השם, ולכן שמו שונה ל Neutron) שיהיה שירות ה Next-Generation של הגדרת וניהול רשתות ב OpenStack. הוא מאפשר:

• להתמודד עם scales ש nova-networking התקשה להתמודד איתם. כנראה זה אזור של יותר מכמה מאות nodes במערכת.
• Software Define Networking - הגדרת רשתות ו SLAs מעשיים, בצורה כמעט וגמישה לחלוטין. (SDN הוא באזז בימנו. שווה פוסט).
• תמיכה בתקנים משופרים (יותר מ 4095 VLANS, תמיכה ב IPv6, וכו')
• תמיכה במודלים נוספים (למשך GRE או VXLAN)
• מבנה מודולרי יותר, המאפשר הרחבה ב plugins. רשתות הוא נושא מורכב, וכמעט תמיד יהיה צורך לפלח שוק מסוים בפנוקציונליות נוספת: או תמיכה בחומרה ייעודית (למשל: Cisco) או תוכנה ייעודית (למשל VMWare) ייעודית בצורה טובה יותר, או תמיכה בפרדיגמות שונות לניהול הרשת. 

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

Glance
Glance ("מבט חטוף") הוא שירות שמאחסן images (תמונת-כונן) של VMs.

Glance מאכסן תמונות-כונן ברמת ה Tenant או ברמה הגלובאלית (זמינות לכולם) + מאפשר שליטה נוספת בהרשאות כמו: מי יכול לעדכן תמונת-כונן, מי יכול להשתמש בה וכו'.

תמונות-הכונן עצמן יכולות להשמר בכמה מקורות אחסון שונים:

• Cinder או Swift - שירותי האכסון של OSK עליהם נדבר בהמשך.
• מערכת הקבצים המקומית (לא מומלץ)
• כל שירות חיצוני שמאפשר לקרוא אותם אח"כ דרך HTTP, למשל: S3 של אמזון.

תת שירות של glance הוא glance-registry המאכסן metadata כל תמונות-הכונן השונות. ה metadata מאוכסן בנפרד מתמונות-הכונן, מה שמאפשר לבצע עליו חיפושים וחיתוכים שונים ביעילות.

כפי שהזכרנו קודם לכן, OSK אינו כולל את טכנולוגיות ה VM - הוא משתמש לשם כך בפתרונות צד-שלישי. בהתאמה: תמונות-הכונן שהוא שומר יכולות להיות בפורמטים שונים, ע"פ ה VMs השונים שבשימוש. ניתן להשתמש ב OSK במקביל בכמה סוגי VM (למשל: VMWare ו Virtual Box).

Horizon

Horizon הוא ה Dashboard של OpenStack אליו מתנקזים נתונים מכל השירותים השונים.
חשוב להבין ש Horizon הוא קודם כל שירות שאוסף ומארגן את הנתונים, ורק אח"כ - שכבת ה Presentation שהיא ה Dashboard הויזואלי שכולם רואים.

ל Dashboard ("לוח הזינוק"?) של OSK יש בעצם 2 גרסאות עקריות:

• Dashboard ל Admin - מנהל המערכת, נקרא System Dashboard
• Dashboard למתשמש - לאו דווקא משתמש קצה, אלא בעל האפליקציה, נקרא User Dashboard. בעיקרון, Dashboard זה הוא subset של ה Dashboard של ה Admin.

ה Dashboard עצמו (נקרא גם "OpenStack Dashboard") הוא אפליקציית Django (ספריית פייטון מאוד פופולרית ל Web UI), שבנויה בצורה מודולרית (ניתן להרחיב) ו Brandable (ניתן לשנות צבעים ולוגו בכדי לשקף את זהות מיישם ה OpenStack הנוכחי באותו הרגע).

את כל הפעולות שניתן לעשות ב Dashboard ניתן לעשות גם בצורה פרוגרמטית, בעזרת APIs.

System Dashboard עם מיתוג של OpenStack

User Dashboard עם מיתוג של Redhat

סיכום

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





---

[א] הנה סקירה מעניינת (ומעט מוטה לטובת CF), של השחקנים בעולם ה PaaS.

[ב] מן מכונות וירטואליות רזות שמשתפות בניהן תהליכים של מערכת ההפעלה - וכך צורכות הרבה פחות זכרון או דיסק, ומאפשרות אתחול מהיר במיוחד => MTTR נמוך מאוד. נושא ה Linux Containers מצדיק פוסט בפני עצמו.

Techkiz - לחשוף סטודנטים לעולם

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

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

• אלו קורסים יותר ואלו קורסים פחות אפקטיביים למטרה זו?
• האם הכשרת עובדים היא מטרתה של אוניברסיטה?
• כמה חשובה מתמטיקה גבוהה לכלל מהנדסי התוכנה?

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

מפגש הפתיחה של הקורס, במעבדות סאפ

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

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

במסגרת הקורס נבחרו 40 סטודנטים (מתוך כמאתיים שנרשמו) לשבוע במעבדות SAP. איך נבחרו? כנראה על בסיס ציונים, נכונות להשקיע וכו'.

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

• איך מתפקדת חברת תוכנה
• איך מוכרים תוכנה
• מערכות ווב
• בסיסי נתונים
• טכנולוגיות ענן
• מתודולוגיות פיתוח
• תהליכי תוכנה (build, delivery, version control וכו')
• איך להתמודד עם ראיונות עבודה
• ניהול קריירה
• יזמות
• וכו'

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

אני סיימתי את התואר שלי לפני 11 שנה בערך. העולם המקצועי השתנה לא מעט, ואני מקווה שהתארים גם השתנו - בהתאם [א]. גם המדיה ואמצעי הלמידה השתנו - ונראה לי שסטודנטים של היום הרבה יותר מודעים למה שמתרחש סביבה (כמעט כולם שמעו על Big Data, ענן או Hadoop. מעטים מאוד הבינו במה מדובר)

בימי, הדרכים הכי טובות שמצאתי להתעדכן במה שמתרחש בעולם היה לשוטט בספריה בחיפוש אחרי ספרים חדשים, לקרוא PC Magazine (האא... הוא חוזר על עצמו מתישהו), או לקרוא בצמא את c2 wiki.

היום יש את Hacker News, גיקטיים, StackOverflow וכו' - שהרבה יותר סטודנטים נחשפים אליהם מאלו שנחשפו למקורות שלי - בזמני. בעצם: נראה לי שאני הייתי היחידי, במחלקה אם לא באוניברסיטה :).

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

טוב שכך.

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

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

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

אני אישית העברתי כמה הרצאות:

ארכיטקטורת תוכנה + ארכיטקטורה של מערכות ווב (לבסוף איחדתי את 2 ההרצאות להרצאה אחת ארוכה).

שם ליווינו סיפור דמיוני על אתר מהפכני שתכננתי, בשם "ספר-פנים", שמתחיל כקובץ HTML פשוט, אך גדל בהדרגה להיות אפליקציית ווב, ואח"כ מערכת ווב שלמה (בסיס נתונים, Load Balancer, multi-tier Architecture, צד שרת וצד לקוח, וכ'ו).

שפות תכנות של העולם 

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

בהרצה זו הצגתי את הייחודיות והשימושים של 4 שפות תכנות שונות מהעולם האמיתי:

ג'אווהסקריפט, פייטון, גו, וסוויפט (Swift - החדשה של אפל). לרוב הסטודנטים כל ארבעת השפות היו חדשות.

מתודולוגיות פיתוח

שם הצגתי כיצד עבדו פעם (Waterfall, בעצם משהו יותר כמו RUP) ואיך עובדים בסקראם (תמונות מחיי היומיום).

אח"כ חזרתי לשורשים הפילוסופיים של כל זן מתודולוגיות (טיילור ל RUP ו TPS של טויוטה ל Agile) - והעקרונות / רעיונות שעומדים מאחוריהן.

לבסוף סקרתי כמה פרקטיקות מ 3 מתודולוגיות אג'יליות מודרניות: XP, סקראם ו Lean Startup.

זהו.

היה דיי מרגש. אני חושב שזה היה קורס טוב, למרות שבטוח שיש גם מה לשפר.

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

ליאור

----

אתר הקורס

אתר הפייסבוק של מעבדת SAP בארץ - שם יש עוד כמה פרטים על הקורס

----

[א] קיבלתי לעיון את כל חומר הלימודים מסטודנט שיסיים לאחרונה תואר זהה לשלי - והשינוי שם היה דיי מתון. אני חושב שרוב הקורסים לא השתנו משמעותית (עדכונים קלים בלבד), וגם התכנית בכלל - רק השתנתה במעט. 11 שנה בעולם התוכנה - זה דור.