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 מצדיק פוסט בפני עצמו.