תגית: Cloud Computing

AWS: היכרות עם SxS – “השירותים הפשוטים” של אמזון – חלק א’

SxS הוא לא באמת מונח רשמי – “המצאתי” אותו לצורך הפוסט. מה שיש הוא:

  • Simple Notification Service (בקיצור: SNS)
  • Simple Queue Service (בקיצור: SQS)
  • Simple Workflow Service (בקיצור: SWF)
  • Simple Email Service (בקיצור: SES)
כל אחד מהשירותים הללו הוא פשוט למדי וממלא משימה בסיסית אחת, מצד אחד. מצד שני, אלו הן אבני בניין חשובות בבניין מערכות על גבי AWS.

Simple Notification Service

שירות SNS הוא שירות הודעות פשוט, מבוסס סכמה של Publish/Subscriber – כלומר: שליחת הודעת לערוץ מסוים (topic) מצד אחד, ורישום ע”י מנוי אחד או יותר לאותו ה topic – שיקבלו את ההודעות ב push. מנוי HTTP, למשל, יספק את ה endpoint המדויק אליו הוא רוצה לקבל את ההודעה.
מקור: אמזון
דפוס ה Publish/Subscriber בא גם לספק decoupling בין השולח לנמען (הם לא מודעים אחד לשני), וגם לספק שליחה של הודעה פעם אחת, והעברה שלה למספר נמענים, לפעמים בפרוטוקולים או פורמטים שונים של הודעה.
SNS מאפשר לשלוח הודעות בפרוטוקולים שונים, למנויים (Subscribers) שונים. הוא מבוסס push, מה שאומר שהודעות נשלחות למנויים ברגע שההודעה התקבלה (אין polling).
דוגמה נפוצה לשימוש ב SNS היא Monitoring של אירועים אפליקטיביים בשרתים (וריאציה מודרנית: שירותים). כשיש תקלה חמורה אנו יכולים לשלוח הודעה מהשירות שלנו SNS, שהוא מצידו ישלח הודעה לשירות ה monitoring שלנו + מייל + SMS לכונן שזמין באותו הרגע.
מן הסתם ההודעות בפורמט שונה, וכאשר שולחים הודעה ל SNS ניתן להגדיר כיצד תראה עבור מנויים מסוגים שונים.
הרישום של המנויים הוא בלתי תלוי בשירות ששולח את ההודעה, ונעשה ישירות מול SNS. אמזון משתמשת בעצמה ב SNS לתפעול AWS. לדוגמה, ניתן להירשם ב SNS להודעות על auto-scaling, הודעות על איבוד נתונים ב RRS של S3, או אירועים שונים ב RDS (בסיסי נתונים המנוהלים ע”י אמזון).
כלומר: SNS מספק לנו שירותים שליחת הודעות בפרוטוקולים שונים (מייל, SMS, וכו’), בזמינות גבוהה, ובצורה מנותקת מהשירות שלנו. השימוש ב SNS חוסך לנו את ההתעסקות עם הפרוטוקולים ועם ניהול המנויים.
ניתן לשלוח בהודעת ה SNS טקסט שונה לכל פרוטוקול של מנוי
(email-json הוא אימייל שנשלח בפורמט JSON ולא text-based).
SNS יודע לשלוח גם הודעות Push לשירותי מובייל (יכולת שנוספה בשלב מאוחר יותר):
  • Apple Push Notification Service (בקיצור: APNS)
  • Amazon Device Messaging (בקיצור: ADM)
  • Google Cloud Messaging for Android (בקיצור GCM)
  • וכמו כן, לשירותי ההודעות של מייקרוסופט (NPNS ו WNS), ושל Baidu (ענק החיפוש הסיני).
התעריפים של SNS נקבעים ע”פ כמות ההודעות שנשלחו לשירות, וכמות ההודעות שהוא שלח למנויים. התעריפים הם שונים למנויים מסוגים שונים: SMS או מובייל (יקר יותר), אימייל (באמצע), או HTTP/S (זול). הודעות שנשלחות ל SQS הן בחינם.

אמינות ההודעות

מה קורה כאשר נשלחה הודעת SNS ללקוח HTTP שכרגע אינו זמין? אולי השרת בדיוק נפל, או שהייתה תקלת רשת ששיבשה את ההודעה? במובייל ייתכן מצב זמני של ביטול הודעות push / הסרה והתקנה של האפליקציה (“Endpoint is disabled”).
עבור חלק מהודעות SNS (למשל SMS, או אימייל), איבוד של הודעה אחת מתוך אלף היא לא בעיה גדולה. במקרים מסוימים – זו דווקא כן בעיה, ואז נרצה לטפל בה.

ל SNS יש מדיניות שליחה מחדש (“Delivery Retry Policies”), המאפשרת להעלות את רף האמינות של ההודעות שנשלחות. לצורך עניין זה אתמקד בהודעות HTTP/S.

מבחינת SNS, הודעה נכשלה אם:

  • הנמען החזיר קוד HTTP מסדרת 5xx. (כאשר יש 404 או 403, זו לא ממש הצלחה, אבל אין כנראה טעם לנסות לשלוח מחדש את ההודעה).
  • עבר timeout של 15 שניות ללא תגובה מה endpoint.
  • תקלת תקשורת ברורה (תקלה בשליחת ההודעה, SSL certificate לא מתאים, וכו’).
אם ההודעה נכשלה ניתן לקבוע מדיניות של ניסיונות חוזרים לשליחת ההודעה.
סה”כ ייתכנו עד כ 100 ניסיונות, ובטווח של לכל היותר שעה.
ל SNS יש מודל של 4 שלבים של Retries, בכל אחד מהם ניתן לקבוע קצב retries ומספר ניסיונות שונה (“קודם תנסה בעדינות, אח”כ דפוק בפטישים!”). הגמישות היא רבה למדי.
את מדיניות השליחה-מחדש ניתן לקבוע ברזולוציה של מנוי.
קישורים מעניינים

Simple Queue Service

שירות המאפשר לנהל Queues (תורים), לשלוח ולקרוא מהם הודעות. זו צורת תקשורת מעט שונה מ SNS:

ההודעה נשלחת ל Queue, והשירות שמקבל את ההודעה שולף אותה ביזמתו מה Queue. לאחר שסיים לטפל בה – מוחק אותה (סדר זה נקבע בכדי לשמור על Data שלא יאבד). למבנה ה Queue יש כמה יתרונות:

  • איזון עומסים בין חלקים שונים של המערכת: כאשר קצב ההודעות מה Producer מגיע ב peaks – ה Queue יאזן אותם. השירות הצורך את ההודעות קובע את קצב העבודה לו הוא מסוגל להגיב – ולכן לא ייפגע מ Self Denial of Service.
  • מבנה ה Queue מאפשר לנתק, במידה מסוימת, בין זמן שליחת ההודעה – לזמן הטיפול בה. למשל: לשלוח הודעות ל Queue במשך כל היום אך להעלות ה Service  שמטפל בהן, רק למשך שעות הלילה – ואז לטפל בכל ההודעות באצווה.

לצורך שיתוף Queue בין כמה צרכנים (בד”כ מספר instances של אותו ה service) – לכל Queue מוגדר Visibility Timeout (ברירת מחדל = 30 שניות). אם הודעה נשלפה, היא נחשבת ל “in flight” ואז יש לשירות שאסף אותה 30 שניות למחוק אותה, או לבקש הארכה. אם לא עשה זאת – ההנחה היא שהוא “נכשל” בטיפול בה (למשל: קרס, איבד אותה, וכו’) ולאחר 30 שניות היא תהיה זמינה לאיסוף ע”י instance אחר.

ניתן לבצע חלוקת עבודה בין כמה instances, פשוט ע”י שיתוף של Queue ביניהם:

  • ניתן להאזין ל Alert על עומק ה Queue, ואם נראה שהשירות לא עומד בקצב – לייצר לו עוד instances. אם תרצו – אמזון תנהל התנהגות זו עבורכם בעזרת SQS Based Scaling.
  • בכדי לא לבזבז זמן על Polling, ה API של SQS תומך ב “Long Polling”. כלומר: קריאה ש”תתקע” למספר שניות שהוגדר, בהמתנה להודעה שאולי תגיע בזמן הזה – במקום לנסות שוב ושוב לבדוק האם ההודעה הגיעה.
הודעה שנאספה מספר פעמים, אך לא הצליחו לטפל בה – מסומנת כ”הודעה מורעלת” ומועברת ל Dead Letter Queue (אם הוגדרה מדיניות מתאימה).

הנה סיכום של כמה מההבדלים בין SQS ו SNS:

SQS תוכנן להיות אמין, זמין, ולא לאבד הודעות. החלטות התכנון הללו גרמו להעדיף שליחה של הודעה פעמיים, על פני איבוד הודעה. במקרים נדירים הודעה תתקבל מה Queue פעמיים, ועליכם לתכנן את המערכת שלכם שתוכל להתמודד עם מצב שכזה בצורה… חיננית – נקרא לזה.

עבור השגה של ה Scalability, אמזון מציע Soft-FIFO בלבד. כלומר: הודעות יהיו “בערך” First In-First Out, הסבירות שהודעה a תשלף מה Queue לפני הודעה b גדלה ככל שהודעה a נשלחה זמן גדול יותר לפני הודעה b. ערבוב בין הודעות שנשלחו בזמן קרוב מאוד – הוא יחסית צפוי. ערבוב בין פרקי זמן ארוכים יותר (מספר שניות) – הולך והופך נדיר.

גודל ההודעה האפשרי הוא של 256KB.

ההגדרות של Queue, ב SQS

SQS הוא לא שירות יקר, אבל ניתן לחסוך עוד בעלויות ע”י שליחה של אצוות של עד עשר הודעות, במחיר של שליחת הודעה אחת – כל עוד הגודל הכולל של ההודעות באצווה לא גדול ממחסום ה 64KB.
אמזון מספקת ספרייה בשם AmazonSQSBufferedAsync client שמסייעת לנהל את האצוות, כמעט לבד, עבורכם. כרגע היא זמינה (ככל הידוע לי) רק בSDK לג’אווה.

אמזון מציעה מיליון בקשות ל SQS בחודש (לחשבון, בעת כתיבת פוסט זה), קריאה, כתיבה או מחיקה – בחינם. המחיר של כל מליון בקשות נוספות ל SQS הוא כחצי דולר.
אמנם גודל ההודעה המרבי הוא 256KB, אולם אמזון מחשיבה בקשות הגדולות מ 64KB, לצורכי תמחור, כבקשות נוספות. למשל: קבלת הודעה בגודל של 150KB – תחשב בתמחור כ 3 בקשות, למרות שנעשתה קריאת HTTP יחידה.

SQS vs. Kinesis
אמזון הציגה לאחרונה שירות נוסף בשם קינסיס (פירוש השם: “תנועה”) – שגם הוא מספק ניהול Queues, אמין, זמין, היכול לתמוך ב Scale גבוה. קינסיס הוא “חיקוי” של Apache Kafka, עם כמה שינויים קלים.

מצד אחד – באמזון טוענים ש “SQS יכול לעמוד בכל Scale”.
מצד שני – בעוד SQS הוא מנוהל לחלוטין יש לו כמה “כאבי ראש” שיש להתמודד איתם:

  • עליכם לנהל את ה shards אליהם מחולק ה Queue – בכדי להגיע Scale. כל shard מוגבל לטיפול של אלף הודעות בשנייה.
  • קינסיס הוא “פחות realtime-י”: הוא לא יאפשר לתשאל על הודעות חדשות (לכל shard) יותר מ5 פעמים בשנייה (כן, הוא סופר).
  • הנתונים נשמרים על קינסיס כ 24 שעות (מול 14 ימים של SQS).
  • גודל הודעה בקינסיס מוגבל ל 50KB (מול 256KB של SQS),

למה, אם כן, להשתמש בקינסיס ולא SQS?!

על הבדל מהותי אחד, ניתן ללמוד מתוך התמחור של קינסיס:

  • כ 2 סנט לכל שעה בו השירות פעיל, ולכל ~7GB של הודעות שנשלח. כלומר: ~10GB כל שעה, לאורך 24 שעות = 24*2*2 = בערך 1$.
  • כ 3 סנט לכל מיליון פעולות כתיבה ל Queue. כלומר: ~10GB כל שעה, לאורך 24 שעות = בין 15 סנט ל ~7 דולר, תלוי בגודל ההודעות.
  • שימוש ב SQS לתעבורה דומה יעלה בין 10$ ל 360$ (חישוב אצבע, תלוי בגודל ההודעות, שימוש באצוות, וכו’).
הבדל נוסף הוא שבקינסיס לא מוחקים הודעה שהתקבלה. אם משהו השתבש בשלב מאוחר יותר ב flow טיפול ההודעות, ניתן “להחזיר את המצביע” כמה שעות לאחור ולהתחיל את התהליך מחדש. כמובן שיש לתכנן את המשך ה flow באופן שיוכל להתמודד עם מאסה של הודעות שנשלחו שוב.
בקיצור: קינסיס (כמו קפקא) היא תשתית שנכתבה להעביר אצוות גדולות מאוד של הודעות – בצורה יעילה, בד”כ: נתונים ב flow של Data processing. אם אתם שולחים GBs של נתונים, מסביב לשעון, כנראה שגם SQS יוכל לספק את השירות – אבל קינסיס עשויה להיות זולה משמעותית ולהתאים יותר לתהליך.

סיכום

בחנו שני שירותים פשוטים, אך חשובים מאוד של AWS: שירות ההודעות, ושירות ניהול התורים.
בפוסט הבא נבחן את שני השירותים האחרים: שירות הדואר האלקטרוני, ושירות ה workflows.

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

AWS: להכיר את S3 מקרוב

בהמשך לפוסט \”הצצה ראשונית ל AWS\” התחלתי לכתוב פוסט על ה Big Data Stack של AWS, אך מהר מאוד נתקעתי: הבנתי שחסר רקע ב Hadoop, ורקע קצת יותר מקיף על שירותי הבסיס של AWS.

שירותי הבסיס של AWS? מלבד EC2 (שהוא מרכזי מאוד, אבל לא כ\”כ מפתיע), שירות חשוב מאוד הוא S3, ולו החלטתי להקדיש את הפוסט הבא.

S3 (קיצור של Simple Storage Service, להזכיר) הוא שירות האכסון הבסיסי של אמזון, והוא שימושי מאוד בתסריטים רבים. הממשק שלו דומה למערכת קבצים מבוזרת (אם כי הוא קצת יותר מורכב).

את הקבצים מארגנים ב Buckets – שהם סוג של Root Folders, עליו ניתן להגדיר הרשאות ועוד מספר תכונות.
לכל קובץ ניתן לגשת ישירות בעזרת HTTP, בצורה:

s3://bucket/folder/filename

כאשר קבצים יכולים להיות בגודל של עד 5TB.

למרות הממשק הדומה למערכת קבצים, כדאי לזכור שבגישה ל S3 יש latency של רשת + ה latency הפנימי של S3 (שיכול להיות עוד 100-200ms בממוצע). אל תנסו לרוץ בלולאה על קבצים ב S3 בזה אחר זה, כמו שאולי אתם עשויים לעשות עם מערכת קבצים מקומית. להזכיר: זמן גישה חציוני למערכת קבצים מקומית עשויה להיות משהו באזור ה 10ms…, ואין לה את המורכבות הנוספת של הרשת.

Bucket, הסמל של S3

כאשר יוצרים Bucket, ניתן לבחור להגדיר אותו באחת מ2 רמות אמינות קיימות:

  • רמת רגילה, המספקת durability של 99.999999999% (11 תשיעיות, וואהו!)
  • Reduced Durability (נקראת RRS, קיצור של Reduced Redundancy Storage) – המספקת durability של 99.99% בלבד. כלומר: סיכון של 0.01% אחוז, כל שנה, לאבד את המידע. המחיר שלו נמוך ב 15-20% מהתצורה הסטנדרטית. תצורה זו מתאימה למידע לא קריטי / שניתן לשחזר.

בכל מקרה ה availability של s3 הוא 99.99%, כלומר: לעתים לא תוכלו לגשת לקובץ (availability), למרות שהוא עדיין קיים (durability). תוכלו לגשת אליו זמן קצר מאוחר יותר.

מה אני יכול לעשות עם S3?

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

  • הנגשה של תוכן סטטי (קבצי HTML/CSS/תמונות וכו\’, לעתים קבצים JSON או XML עם נתונים) על גבי HTTP. ל S3 ניתן לגשרת ע\”י REST ו/או SOAP.
  • שיתוף של נתונים, בצורה מבוזרת, בין כמה שרתים. לעתים כאשר קצב הקריאה הוא גבוה מאוד.
  • שמירה של כמות גדולה של נתונים סטטיסטיים לא מעובדים / מעובדים קלות – עבור עיבוד עתידי (מה שנקרא \”Data Lake\”)

את הפעולות הבסיסיות ניתן לעשות דרך ה UI של אמזון:

  • יצירת Bucket, וקביעת הגדרות שונות שלו.
  • העלאת קבצים
  • ניהול קבצים
  • וכו\’

ניתן להשתמש ב awscli בכדי לבצע פעולות על s3 מתוך command line:

  • ליצור bucket (פקודת mb), להציג את רשימת הקבצים שנמצאים ב s3 (פקודת ls) או להעתיק קבצים בין s3 למחשב המקומי (פקודת cp), וכו\’…
  • פקודת sync – לסנכרן תיקיה מקומית מול bucket של s3. הפקודה תגרום רק לקבצים חדשים, בעלי גודל שונה, או תאריך עדכון חדש יותר מאשר ב s3 – להיות מועלים ל s3. הפרמטר delete– יגרום לפקודה לנקות מ s3 קבצים שנמחקו מהמחשב המקומי.
דרך שלישית ומקובלת היא להשתמש ב Programmatic APIs.

אם אתם עובדים על \”חלונות\”, יש כלי UI נחמד בשם S3 Browser, המאפשר לראות את ה Bucket ולבצע עליו פעולות בצורה נוחה (משהו כמו כלי FTP נוח).

ה UI של S3

על כל bucket יש מספר תכונות:

  • הרשאות: מי רשאי לגשת לקבצים ב bucket? ניתן לאפשר גישה ציבורית (ע\”י HTTP url). ניתן גם לקבוע הרשאות ברמת הקובץ הבודד.
  • ניהול גרסאות: כל שינוי לקובץ ב bucket ינוהל בגרסה (כולל מחיקה). ריבוי העותקים יגביר את העלויות, וניתן לקבוע מדיניות (\”lifecycle rules\”) מתי ניתן למחוק עותקים ישנים או להעביר אותם ל AWS Glacier (אכסון זול בהרבה, במחיר גישה אטית לקבצים – יכול לקחת גם כמה שעות בכדי לעשות checkout לקובץ).
  • האזנה לאירועים: ניתן להאזין להוספה / מחיקה / עדכון קבצים ב bucket, ולשלוח הודעה לאחד משלושה שירותים של AWS:
    • Simple Notification Service (בקיצור SNS) – שירות ה publish/subscribe של אמזון. מאפשר לכמה לקוחות להירשם ל topic, ושולח את ההודעות ב push (ל HTTP endpoint, דוא\”ל, או SMS).
    • Simple Queue Service (בקיצור SQS) – שירות queues. על הלקוח לשלוף ביוזמתו את ההודעה מה queue, ומרגע זה – ההודעה כבר לא קיימת יותר. לעתים קרובות מחברים את SNS שישלח הודעות למספר SQS queues – אחד לכל נמען.
    • AWS Lambda – בכדי להריץ פונקציה על בסיס השירות.
  • אירוח אתרים סטטיים (Web Hosting) – על בסיס קבצי html/css/javascript שמועלים ל s3, בשילוב עם Route 53 (שירות ה DNS של אמזון).
  • הצפנה (server side encryption): אמזון יכולה להצפין עבורנו את הנתונים הנשמרים ב s3, ע\”פ מפתחות שאנו מספקים לה. אם מישהו פרץ לתשתיות של אמזון (או קיבל צו חיפוש פדרלי בארה\”ב – למשל), הוא מוצא קבצים מוצפנים שאין בהם הרבה שימוש.
  • אינטגרציה ל Cloudfront – שירות ה CDN של אמזון, המאפשר להנגיש קבצים המאוחסנים ב S3 בעלויות נמוכות יותר, ו latency קצר יותר (על חשבון: עד כמה מעודכנים הקבצים שניגשים אליהם).
  • Multipart upload – המאפשר לחתוך קבצים גדולים לכמה parts ולטעון אותם במקבלים על גבי כמה HTTP connections.
  • Logging – שמירת לוג של הפעולות שנעשו על ה Bucket.

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

    היבטים של Landscape

    S3 הוא שירות ברמת ה Region, ובאופן אוטומטי תהיה רפליקציה של הנתונים בין ה Availability Zones השונים. הרפליקציה מתבצעת תוך כדי כתיבה, כך שאם קיבלתם OK על הפעולה – המידע שם ומסונכרן (בניגוד ל offline replication המתבצע מאוחר יותר).

    שם של Bucket צריך להיות ייחודי ברמת כל ה Regions של AWS (כלומר: Globally unique ב Account).
    שם האובייקט משפיע על האופן שבו S3 תעשה partition לנתונים, ולכן אם אתם זקוקים ל tps גבוה – כדאי לדאוג לשמות בעלות שונות גבוהה, ושאינם תלויים בדפוסים שלא מייצגים את דפוסי הגישה (למשל: לא להתחיל שם של אובייקט ב timestamp – כי יהיו קבצים רבים המתחילים באופן דומה). הנה פוסט בנושא, אם הנושא רלוונטי עבורכם.

    Policies

    על Bucket ניתן לקבוע policies, המוגדרים מכמה אלמנטים:

    • Resources – על אילו משאבים (קבצים) ב bucket אנו רוצים להחיל את ה policy.
    • Actions – אלו פעולות על הקבצים אנו רוצים להשפיע (upload, list, delete, וכו\’)
    • Conditions – באלו תנאים יחול ה Policy: שעות פעילות מסוימות, regions של AWS, מצב של הקובץ, וכו\’. בעצם ב conditions נמצא הכוח האמיתי של ה Policy.
    • Effect – משמעות: allow/deny. אם יש סתירה בין policy של deny ל policy של allow – ה deny policy הוא זה שיכריע.
    • Principal – החשבון ב AWS או IAM user עליו חל ה policy.
    Policy לדוגמה יכול להיות הכנסת ססמה לפני מחיקה של קבצים מה Bucket, בכדי לצמצם את הסיכון שמישהו מוחק נתונים קריטיים, בטעות. ה Durability הגבוה של S3 הופך את הגורם האנושי לחלק המסוכן בשמירת המידע.
    את ה policy מגדירים כקובץ json ע\”פ מבנה מסוים, ועושים לו copy-paste לתוך ה UI (ב properties של bucket / הרשאות / policy). אמזון (בצדק) לא יצרו את ה UI המורכב שהיה נדרש בכדי לאפשר להגדיר policies בתוך ה UI של ה bucket. ניתן להשתמש ב AWS Policy Generator בכדי לייצר Policies (אך לא לערוך או למחוק) ואז להדביק את התוצאה ב UI של ה bucket properties.

    Policy לדוגמה. מקור: אמזון

    סיכום

    הנה עברנו בחינה מעמיקה של S3. היא לא הייתה ארוכה, בעיקר בגלל ש S3 הוא באמת… די פשוט.
    S3 הוא מאבני הבניין היסודיות ביותר של AWS – וכדאי להכיר אותו היטב.

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

    —

    לינקים רלונטיים

    FAQ של אמזון על S3
    המחירון של S3
    Data encryption on S3

    Amazon Web Services – הצצה ראשונה

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

    \”מדוע להשכיר אחסון פיסי, אך לא אחסון לוגי?\” – מישהו באמזון שאל.

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

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

    שירותים נוספים היו Simple Queue Services (בקיצור: SQS) ו SimpleDB (בסיס נתונים רלציוני כשירות, עבור כמויות קטנות של נתונים. כיום, נראה שאמזון נמצאת בשלבים להפוך אותו ל deprecated לטובת שירותים חדשים יותר).

    על הבסיס הזה היה ניתן להקים מערכת מבוזרת, High Scale ו Highly Available – ובזול. היה עדיין צריך לעבוד הרבה יותר קשה מהיום בכדי לבנות פתרון על AWS, וכל הרעיון של מחשוב ענן היה עוד חדש – כך שלאחר שנה היו \”רק\” 180 אלף מפתחים רשומים לשירותי AWS.

    היום, מיותר לציין, אמזון היא \”הגורילה\” של שירותי ב IaaS ובדרך המבטיחה להיות גם \”הגורילה\” של שירותי ה PaaS עם AWS Beanstalk. מיקרוסופט, גוגל, יבמ, ו Heroku הצליחו לספק בשנים האחרונות תחרות מוגבלת בלבד.

    מדוע אם כן – אמזון לא מעלה מחירים? מדוע היא כ\”כ אגרסיבית בתמחור של השירותים שלה?

    1. זה עניין תרבותי, כך טוענים. אמזון מתמחרת שירותים בצורה אגרסיבית מיום היווסדה.
    2. קצת יותר מפתיע: עם כל ההצלחה של הענן, כח המחשוב שנמצא היום בענן הוא רק כ 5% עד 10% מכח המחשוב העולמי (המספר המדויק תלוי במי מחשב וכיצד). קרב השליטה בענן עוד נמצא בשלביו המוקדמים.
      חברות הענן לא מתמקדות כרגע ברווחים (הן מוכנות להיות break even לבינתיים) אלא רק בצמיחה ותפיסת נתח גדול יותר מפלח השוק.
    מייקרוסופט, לדוגמה, עשתה חייל בשנה האחרונה: היא העבירה את הפוקוס שלה ממובייל – לענן, והצליחה תוך כך להעביר Enterprises רבים שהם \”Microsoft Shop\” – ל Azure.

    התרשים למעלה הוא מעניין, אבל עלול גם להטעות – ולכן יש לי רגשות אמביבלנטיים לגבי ההוספה שלו.
    אם נראה מהתרשים שמייקרוסופט הולכת להשוות לאמזון תוך כמה שנים – אז חשוב לאזן: מייקרוסופט עושה את הרווחים שלה מ Full Stack של טכנולוגיות, בעוד Amazon רק מהשכבות הנמוכות (בעיקר IaaS). כשאמזון נכנסת עתה לשכבות גבוהות יותר (PaaS, DBaaS, וכו…) – היא צפויה \”לפלוש\” לפלחי שוק גדולים וחדשים עבורה – ולהשיג \”קפיצה\” בהכנסות.

    בידיעה ש 90% מהשוק עוד נותר לכיבוש – ברור שאמזון לא נשארת שאננה, וממשיכה בתחרות עיקשת ובכל המרץ.

    כיום, 8 שנים אחרי ששוחררה לראשונה לקהל הרחב, יש ל AWS עשרות שירותים בענן:

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

    יצירת instance של EC2 – איך זה נראה?

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

    הערה: עם Deployment כל 10 שניות של עדכון למערכות אמזון – הכל יכול להשתנות בכל רגע. אל תניחו שעוד חצי שנה התהליך יראה בדיוק אותו הדבר – אבל הוא כנראה יהיה דומה.

    אמזון מאפשרת מסלול בשם AWS Free Tier בו אתם יכולים להתנסות בשירותים AWS, על חומרה מינימלית (לא הולכים עם חומרה כזו ל production) ותוכנה חופשית – למשך כשנה (!). מכניסים אמנם כרטיס אשראי – שיחויב רק אם \”התפתתם\” לבקש קצת מעבר למינימום שמוצע בתכנית.

    העלויות המורגשות באמזון, בשלבים אלו של פיתוח ראשוני, הם לרוב לא החומרה שבשימוש – אלא החומרה שלקחתם לשימוש ושכחתם להחזיר. איזה שרת בינוני שלקחתם לכמה שעות, אבל נשאר רץ כל סופהשבוע – למשל.

    במהלך ה Wizard למטה תראו אופציות מסוימות המסומנות כ Free tier eligible. המשמעות היא: \”ניתן לבחור באופציה זו ללא חיוב, כחלק מתוכנית ה Free Tier\”. אני אבחר מבין אופציות אלו בלבד.

    בחירת ה AMI

    Amazon Machine Image (בקיצור AMI) הוא הפורמט של אמזון ל VM Image (בעברית: תמונת מכונה-מדומה). אני לא בקיא בפרטי המימוש הפנימי של AMI, אך הפונקציונלית היא כמו זו של קובץ dmg. ב Mac או קובץ ovf. עבור Virtual Box או VMWare.

    את הקובץ ה AMI, אתם לא מנהלים אצלכם – הוא מנוהל על שירות S3 (קיצור של Simple storage service) של אמזון – שירות אמין במיוחד, scalable, לאחסון קבצים בגודל של עד 5TB (נכון לרגע זה). אתם יכולים להשתמש ב AMI מוכן מבית אמזון (הרשימה למעלה), לקנות AMI מצד-שלישי (יש Marketplace שלם, הכולל עלות שימוש לשעה המכילה את החמורה מאמזון + רשיונות התוכנה המתאימים), או פשוט לקחת snapshot מ EC2 instance שבבעלותכם.
    לדוגמה: ליצור instance חדש של Red Hat Linux, להתקין עליו VIM – וכך ליצור AMI חדש \”Red Hat /w VIM\”.

    שווה לציין שאם אתם זקוקים ל Landscape גדול, זו עבודה קצת סיזיפית לייצר instance אחר instance. לשם כך יש שירות של אמזון שנקרא Cloud Formation המאפשר יכולות דומות ל AMI – רק בקנה מידה גדול. במקום הקמה של מכונה בודדת – הקמה של Landscape של מכונות (כל אחת עם ה AMI שהוגדר לה), הגדרות רשת, אבטחה וכו\’ וכו\’.

    בחירת חומרה (וירטואלית)

    השלב המשמעותי הבא הוא לבחור חומרה (וירטואלית, כמובן). חומרת השרתים מסווגת לפי אופן השימוש:

    • כללי / מאוזן – סדרה t או m3
    • CPU intensive – סדרה c3
    • Memory Optimized – סדרה r3
    • Disk optimized – סדרה i2 או hs1
    • וכו\’.
    בתוך כל סדרה יש כמה \”גדלים\” שונים של מכונות (\”T-Shirt Size\”)
    • small
    • medium
    • large
    • xlarge
    • וכו\’.
    אי אפשר לדעת איזו חומרה פיסית תריץ את ה VM שלכם. אם אתם בררניים (למשל: כתבתם קוד ב C בהסתמך על מעבדים מסדרה מסוימת של אינטל) – ההמלצה של אמזון (כפי שאני מכיר אותה, קצת ישנה) היא לבקש instance, לבדוק מה יצא – ואם לא אהבתם \”לזרוק\” ולבקש חדש עד שתהיו מרוצים.

    בחירת Storage





    השרת שלכם זקוק ל Storage. שתי האפשרויות הבסיסיות הן כדלהלן:

    • Ephemeral Storage (אחסון זמני, נקרא גם Instance Storage) – מה שמוקצה כחלק מה VM.
      כשתחזירו את המכונה לרשותה של אמזון – כל המידע יימחק.
      אם ה VM של אמזון קרס (יכול לקרות) – המידע יאבד.
      אולי תוכלו לייצר AMI מהמכונה וכך לשמור עותק של המידע.
    • EBS (קיצור של Elastic Block Store) הוא בעצם סוג של NAS (קיצור של Network Attached Storage) ממנו ניתן להקצות חלקים ולעשות mount ל instance שלכם.
      EBS ממשיך לחיות אחרי שהמכונה הוחזרה / ה VM נפל.
      EBS הוא אמין יותר, ועובר רפליקציה בין Availability zones בתוך ה Region – הכוונה, בין Data Centers (הנקראים Availability Zones) החברים באותו אשכול של Data Centers – שנקרא Region. על כך בהמשך הפוסט.
      הוא עדיין לא אמין כמו S3, ומומלץ לבצע גיבויים למידע – אם הוא חשוב לכם.

    יש לאמזון שירותי Storage נוספים, שזמינים כשירות (כלומר: API) ולא כ mount למערכת ההפעלה:

    Simple Storage Service (בקיצור S3)

    • Key/Object Storage. למה Object ולא Value? – כי לרוב מאחסנים בו \”קבצים\” ולא ערכים קטנים (למשל מחרוזת או מספר).
    • Static files – ניתן לגשת ישירות לקובץ ב HTTP ו/או HTTPS (ואז הוא מוגן בעזרת הרשאות)
    • אמין בצורה יוצאת דופן (durability של 99.999999999% או משהו דומה). יש רק מקרים בודדים מתועדים בהם מידע אבד מ S3, ולרוב זה היה בצורת corruption של נתונים בעקבות באגים של אמזון.
    • שומר אובייקטים בגודל של עד 5TB
    • המידע נשמר מוצפן על השרתים של אמזון (encrypted at rest)
    • זמינות השירות היא גבוהה (99.99%). שימו לב: יכול להיות שהקובץ \”חי וקיים\”, אך אין שרת זמין שיגיש אותו (ולכן הפער בזמינויות).
    • יש לו אינטגרציה ל Glacier – אחסון \”קר\” יותר (קפוא!), וזול יותר.
    • יש לו אינטגרציה ל CloudFront – שירות ה CDN של אמזון, על מנת להגיש את הקבצים ממיקומים קרובים יותר לצרכן.
    • Region-Specific, מסתנכרן בין ה Availability Zones שונים.
    • קל מאוד לשימוש (REST API פשוט).

    Glacier

    • Archival Storage – מיועד לשמירת כמויות מידע, ב offline.
    • לקוח 2-6 שעות לשלוף קובץ (מה שמרמז שהקובץ מאוחסן על קלטות?)
    • זול מאוד (סנט ל GB לחודש, כשליש מ S3). עיקר המחיר הוא בשליפה של הנתונים.
    • הנה השירות הראשון של אמזון שאנו נתקלים בו – שהוא בעל תמחור מורכב:
      אמזון מציעים לכם שירות זול – הכי זול שיש, כנראה.
      אבל… התמחור הוא זול כל עוד אתם מצליחים לעמוד בכמה תנאים. זה לא ניסיון של אמזון להכשיל אתכם, זו הדרך שלהם להציב תנאים בהם הם יכולים להציע מחירים כ\”כ זולים. ואלו תנאים שידרשו מכם מאמץ.
    • למשל: בכדי לצמצם את מחיר השליפה מ Glacier עליכם לקבל (download) את הקובץ בקצב הורדה קבוע לאורך 24 שעות, ויש הנחה אם אתם מורידים קובץ שלם ולא חלק ממנו. פרטים נוספים.
    • אתם אמורים להבין ששירות כזה לא מתאים לסטארט-אפ תפרן בתחילת דרכו (כי הוא עלול להתקשות בתנאי התמחור הזול), אלא לארגון מתופעל היטב שמנסה לצמצם עלויות לרצפה – ומוכן להזיע קצת בשביל זה.

    Security Groups

    כל Instance של EC2 משויך ל Security Group. השם עשוי מעט לבלבל – אולי עדיף היה לקרוא להם Traffic Policy.
    כל קבוצה מכילה מספר EC2 instances וקובעת עבורם איזו תקשורת נכנסת תתאפשר ע\”פ פרוטוקולים, מקור, או ports שהגדרתם.  ההגבלות הן על תקשורת נכנסת בלבד – לא מגבילים תקשורת יוצאת.
    מכירים יכולת שכזו בעולם ה On-Premises? נכון – זה נקרא Firewall.
    בעצם ה Security Groups היא דרך קלה ומהירה להחיל אבטחה בסיסית של Firewall על השרתים שלכם. הריכוז בקבוצות עוזר לנהל מצב בו יש לכם instances רבים.
    באופן מעט מוזר, לא ניתן להזיז instance מרגע שהוגדר – בין Security Groups. אתם יכולים לשנות את ההגדרות של ה Security Group או \”לזרוק\” את ה instance ולהקים אחד חדש ב Security Group אחר.
    החלפת מפתחות

    טוב. ה instance שנמצא באמזון מוכן להתניע – אבל הם מוסרים לכם אותו?
    הרי הוא עכשיו באמזון, ואתם – ובאמצע יש רשת עוינת של האקרים. אז… לשלוח או לא לשלוח את פרטי החיבור (\”Admin\”/\”Admin\”) במייל וזהו?

    הפתרון (הטבעי / הגיוני) של אמזון הוא להשתמש בהצפנה א-סימטרית. אתם יכולים לייצר זוג מפתחות ולשלוח אחד לאמזון, או לבקש שאמזון תיצור זוג מפתחות – ותשלח אחד אליכם (האופציה הזו יותר קלה).
    במקרה זה תורידו (ב https, כמובן) את המפתח שלכם כקובץ perm. ותתבקשו מאוחר יותר להציג אותו בחזרה – כאשר תרצו להתחבר למכונה.
    במכונות עם מערכת ההפעלה \”חלונות\” תעלו את הקובץ ותקבלו ססמה שעליכם לזכור, במכונות לינוקס תדרשו לצרף את הקובץ עצמו ככלי האימות ל ssh בעת חיבור למכונה. אם לינוקס – אז כדאי שתשמרו היטב את הקובץ שלא יאבד (מקסימום – \”זרקו\” את המכונה והקימו חדשה. זהו הקצב באמזון: שרת = disposable).

    קצת על הפריסה של אמזון

    שירותי AWS פזורים על 27 Data Centers ברחבי העולם (AWS Global Infrastructure – לצורך עדכונים במצב)

    Availability Zone (בקיצור AZ) הוא Data Center עצמאי, עם רשת משלו, הספקת חשמל משלו, אבטחה משלו, עמידות בפני שריפות, אסונות טבע (טוב – רובם) משלו וכו\’. הוא אמור להיות חסין לקריסה של Availability Zone אחר.

    ה AZs מקובצים לתוך אשכולות בשם Region – שזה אזור גאוגרפי בעולם. יש בין ה AZs ב Region רשת מהירה, שמאפשרת רפליקציה של נתונים בין ה AZ בכדי ליצור ולשמר יתירות. Region יכול להיות \”מזרח ארה\”ב\” או \”גרמניה\”.

    סה\”כ לאמזון יש כיום 11 Regions ברחבי העולם.

    רבים מהשירותים של אמזון הם זמינים ברמת ה Region. למשל שירות S3 – מסנכרן לבד את הנתונים שלו בין ה AZs ב Region.
    שרתים שלכם (EC2 instances) – הם באחריותכם: כדאי שתפזרו את השרתים ב Region על פני כמה Availability zones שונים, ואם יש צורך בסנכרון – הוא עליכם.

    בהרבה Regions יש שלושה Availability Zones. למה שניים לא מספיקים?

    ראשית – כי 3 זה יותר בטוח מ 2.

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

    נשווה פיזור של אפליקציה בין 3 ל 2 Availability Zones:

    • ברגע הנפילה – ה capacity שלכם ירד ל 67% ולא ל 50%.
    • \”להרים instance זה עניין של כמה דקות ב AWS, נכון?\”
    • נכון – אבל לא בעת אירוע של נפילת Availability Zone. במקרה כזה אלפי לקוחות של אמזון מבקשים ממנה instances חדשים באותו הרגע ממש – מה שאומר שהזמן לקבל instance חדש יהיה ארוך מהרגיל, זמן בו יהיה עליכם להסתפק בקיבולת שנותרה לכם – וכאן ההבדל בין 50% קיבולת ל 67% קיבולת – היא יותר משמעותית.

    נטפליקס, למשל, שהעסקים שלהם מבוססים לגמרי על AWS עשו מעבר לכך: ברגע שנופל AZ הם מורידים את איכות השירות (נאמר: ל 65%) בכדי להמשיך לתת את השירות לכל הלקוחות ללא הפרעה – ומבלי להסתמך על כך שיוכלו להוסיף בזמן קצר עוד EC2 instances מספיקים. שיפורים אלו נעשו מתוך outages שהם חוו בפועל, ולא מתוך \”תכנון מוקדם\”.

    למה אמזון לא מחברת את כל ה Regions שלה אחד לשני?

    1. כי תעבורת הרשת תהיה יקרה מאוד (יש הבדל בין תקשורת מהירה בתוך וירג\’יניה לתקשורת מהירה בין וירג\’יניה לסין)
    2. כי קשר = תלות = פחות disaster tolerance.
    3. כי שירותים מסוימים (לדוגמה VPC) לא יעבדו על פני מרחק גיאוגרפי גדול.

    אחד ה Regions המעניינים הוא GovCloud שנמצא בצפון-מערב ארה\”ב. אחד החסמים של גופים ממשלתיים להשתמש בשירותי הענן של אמזון הוא רגולציה. כל מיני חוקים שמבטיחים שרק אזרחים אמריקאים יהיו מסוגלים לגשת לשרתים ולרשת, חוקים של אבטחת מידע ואחסון ייחודיים (מישהו שמע על ITAR?) וכו\’. מכיוון שהמגזר הציבורי בארה\”ב הוא מספיק גדול להצדיק השקעה שכזו (הממ הממ) – אמזון בנו Region מיוחד רק לגופי ממשלה בארה\”ב שתפור לכללי הרגולציה. המיקום במערב ארה\”ב נקבע בגלל סיבות טקטיות – והוא יורחב גם למזרח ארה\”ב בעתיד (אני מניח שכ Region נוסף).

    שימו לב שלא כל השירותים של אמזון זמינים בכל ה Regions.

    Edge location
    אמזון, כספקית CDN שצריכה להיות \”קרובה\” לכל המשתמשים בעולם, מחזיקה גם אתרים (מה שנקרא לעתים PoP – Point of Presence) רק לצורך Caching של נתונים או שירות ה DNS (נקרא Route 53).

    קצת על אבטחה

    מודל האבטחה של AWS הוא מודל של אחריות משותפת: של אמזון \”בשותף\” עם הלקוח.
    אמזון לוקחת אחריות על כמה תחומים שלה, ומספקת ללקוח מגוון כלים – בציפיה שהוא יהיה אחראי על הצד שלו.

    אחריות הלקוח כוללת:

    ניהול משתמשים והראשות. אמזון מספקת את IAM (קיצור של: Identity and Access Management) שהוא סוג של Repository לניהול משתמשים (כמו Active Directory), הכולל גם יכולות של Federated Identity ו SSO (כמו Active Directory Federation Services – ADFS).

    אמזון מספקת גם יכולת Multi-Factor Authentication. למשל: הכנסת ססמה ב Desktop ובנוסף אימות ה Login מתוך הסמארטפון (על בסיסי ID ייחודי של היצרן – שמוודא שזה אכן הטלפון שלכם) או חומרה ייעודית אחרת (כמו כרטיס RSA  המייצר קוד זמני שהשרת יכול לאמת – למי שמכיר). ייתכן ותרצו לאכוף מנגנון שכזה על גישה של משתמשי מפתחי (Admins למיניהם).

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

    Security Groups – אותם הזכרנו בהקדמה, שזה סוג של Firewall.

    הרשאות שונות (ACLs) – מי יכול לגשת לאיזה שירות (שירותים כמו בסיסי נתונים כשירות, CDN, וכו\’).

    אם אתם רוצים לאבטח את הרשת שלכם יותר מהרמה של Security Groups ו ACLs, אמזון מספקת יכולת בשם Virtual Private Cloud (בקיצור VPC) בה תקבלו רשת נפרדת משאר הענן (ע\”י ויראוליזציה, כמובן) ותהיה לכם יכולת שליטה רבה על הגדרת הרשת וההרשאות שלה – כרצונכם. זו כמובן התעסקות לא קטנה, הדורשת הבנה טובה של הרשת – ושל יכולות ה VPC של אמזון.

    אחריות אמזון כוללת:

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

    אחריות על הגנת הרשת הפנימית של AWS: ניהול ה switches / routers בצורה מאובטחת. אמזון מנטרת את תנועת הרשת מפני חריגות עקרוניות: שרת ששלוח IP Packets ומצהיר על IP שאינו שלו, פעילות של Port scanning וכו\’. אמזון יודיעו לכם אם הם מזהים התנהגות חשודה כלפי ה EC2 Instances שלכם.
    המדיניות של אמזון אוסרת עליכם, למשל, להשתמש ב NMAP או כלי דומה לבצע port scanning לעצמכם. עליכם לסמוך על אמזון. אם אתם רוצים לבצע להריץ Web Scanner על השרתים שלכם – עליכם לתאם זאת עם אמזון מראש ולעשות זאת רק במסגרת הזמן שהוקצב לכם.

    אמזון מבטיחה Multi-tenancy של המערכות שלה (ע\”י Hypervisors, VLANs, או Multi-tenancy ברמת התוכנה, וכו\’) שמבטיח שלקוח אחר, שמשתף אתכם חומרה פיסית – לא יוכל לנצל עובדה זו בכדי לגשת לנתונים שלכם. הפרדה מוחלטת.

    שירותי הגנה מ DDoS (כלומר: Distributed Denial of Service) – התקפה נפוצה, שירות כזה מסופק ע\”י רוב ספקיות ה CDN הגדולות, ואמזון היא אחת מהן.

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

    סיכום

    אחרי שסקרתי את OpenStack (גם חלק שני) – יהיה רק הגיוני לסקור את AWS.
    שילבתי בפוסט לא מעט פרטים – אך הדרך להכיר את AWS היא עוד ארוכה.

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

    להבין Virtualization

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

    וירטואליזציה[א] היא לא טכנולוגיה חדשה: היא זמינה החל משנת 1972, אולם רק בעשור האחרון היא זכתה לאימוץ נרחב. כיום היא אחד מהיסודות החשובים של מחשוב הענן.

    רעיון הוירטואליזציה קיים ברמות הפשטה שונות:

    • זיכרון וירטואלי – הוא מימוש של וירטואליזציה לזיכרון. הוא מבצע multiplexing (חלוקת משאב פיסי אמיתי לכמה תהליכים אורחים במקביל) וגם emulation (בכך שהוא מנהל כתובות מדומות של הזיכרון הוירטואלי עמם התהליכים האורחים עובדים).
    • מנגנון ה LVM של לינוקס (קיצור של Logical Volume Manager) הוא דוגמה לוירטואליזציה של הדיסק. האופי שלו הוא אחר: הוא מבצע aggregation בכך שהוא גורם לכמה דיסקים פיסיים להראות כמו דיסק לוגי יחיד. זו עדיין וירטואליזציה.
    • מנגנון ה NAT (קיצור של Network Address Translation) של פרוטוקול IP, המשמש רכיבי רשת כמו proxy או reverse proxy בכדי להסתיר כתובות רשת אמיתיות של מחשבים – הוא דוגמה לוירטואליזציה של הרשת.
    • X-Server או VNC של לינוקס / Remote Desktop של חלונות – הם דוגמאות לוירטואליציה של ה Desktop. זהו עולם דיי עשיר עם פתרונות כמו App-V של מייקורוסופט ש”מזרים” אפליקציה שרצה בשרת מרוחק – למחשב השולחני המקומי (זו בעצם Application Virtualization).
    בפוסט זה ארצה להתמקד בויאטואליזציה של החומרה כולה (זיכרון, דיסק, רשת, וכו’) – מה שרוב האנשים מכירים פשוט כ “Virtual Machine” או “VM”.

    במהלך הפוסט אנסה לענות על שאלות כגון:

    1. כיצד, בפועל, טכנולוגיות הוירטואליזציה חוסכות לארגון ה IT כסף רב?
    2. מה ההבדל בין hypervisors מ”טיפוס 1″ ל hypervisors מ”טיפוס 2″? וכיצד בוחרים את העדיף לסיטואציה?
    3. מהי Paravirtuallization ומהם Linux Containers (שעושים כ”כ הרבה רעש בשנתיים האחרונות)??
    4. למה לקח כ”כ הרבה זמן לויטרטואליזציה לתפוס מקום מרכזי בתעשייה? אתם יודעים, כמעט 40 שנה?
    5. מי הם Popek ו Goldberg – ומה הקשר שלהם לכל הסיפור?

    מוטיבציה

    אנסה להעביר את המוטיבציה בעזרת סיפור קצר. בסיפור שלנו יהיה ארגון עם Data Center שכולל כמה שרתים שונים:

    • שרת קבצים (shares)
    • שרת ווב
    • שרת e-commerce
    • שרת דואר (Exchange)
    (לצורך פשטות הסיפור אתאר רק 4 שרתים. בסביבה אמיתית סביר שיהיו הרבה יותר).

    במשך השנים נוצר הסטנדרט בו כל שרת רץ על “קופסה” (כלומר: מחשב פיסי) משלו.
    ניסיונות שהיו במשך השנים להריץ כמה תוכנות שרת על אותו שרת פיסי (מה שנקרא “server consolidation”) נגמרו לרוב בחוסר שביעות-רצון של האחראים על תוכנות השרת (גם אם אותו האדם אחראי על שתי מערכות שונות). מדוע?

    • Sandboxing: תקלה בשרת הדואר יכולה לגרום לקריסה של מערכת ההפעלה – ולא רוצים ששרת הווב או המסחר האלקטרוני לא יהיו זמינים בגללו. אולי שרת הדואר דורש עדכון של מערכת ההפעלה שגורם לבעיה חדשה בשרת הקבצים?
    • אמינות: כאשר כל שרת רץ על עותק שלו של מערכת ההפעלה – פשוט יש פחות תקלות. שני שרתים דורשים הגדרות תצורה מעט שונות – שלא אופטימליות או מוכרות עבור תוכנת השרת השנייה.
    המציאות בפועל הייתה שאנשי ה IT דרשו מהארגון “קופסה לכל שרת” כתנאי עבודה בסיסי.
    הקצאה של “קופסה לכל תוכנת שרת” סיפקה את היתרונות המצופים:
    • זמינות: שדרוג / עדכון של תוכנת שרת אחד, לא משפיעה על שרתים אחרים.
    • דרישות סביבה שונות: שרת הדואר רץ על “חלונות”, שרת המסחר על איזו גרסה של UNIX ושאר השרתים רצים על לינוקס בכלל. דרישות חומרה בד”כ אפשר לכנס בקלות רבה יותר.
    • יתרונות אבטחה: קבלת הרשאות root על מחשב אחד, לא משפיעה על הגישה למחשבים האחרים.
    כל זה טוב ויפה – אבל יקר.
    יקר בכלל הכפילות של החומרה שחלק גדול מהזמן נמצאת ב Utilization נמוך. אם שרת הווב, דורש לשעה בחודש כח עיבוד X, יש לספק לו כח עיבוד זה גם אם שאר החודש הוא זקוק לכח עיבוד של X/12 או אפילו X/60.
    בנוסף: כשקונים שרת פיסי עבור תוכנה חדשה – כמה חומרה יש לקנות? האם מתכננים לחודש הראשון של השימוש או לשנה אח”כ? בתעשייה נוצרה פרקטיקה בשם Sizing שמטרתה להעריך כמה חומרה תידרש, פרקטיקה מאוד לא מדויקת בה טעות של עד פי 2 – נחשבת כהצלחה.
    שרתים פיסיים שרוב זמנם עובדים על כ CPU 10% – היו תמונה מקובלת.

    לעלות החומרה יש עלויות נגזרות נוספות:

    • צריכת חשמל + צריכת החשמל של מערכות המיזוג שנגזרת ממנה (עלות משמעותית)
    • שטח אכסון (נדל”ן – עלות משמעותית בערים צפופות)
    • עלות איש ה IT שעליו לנטר את המערכות ולתחזק את החומרה (התקנה, גיבויים, טיפול בתקלות, …)
    עונתיות בשימוש במשאב מחשוב

    הערך של וירטואליזציה

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

    מה קורה כאשר השרת הפיסי כושל? האם לא פגענו בזמינות של השרתים שלנו? ברגע שחומרת המחשב המשותף קורסת – יושבתו מיידית כל ה VMs שרצים עליה!!

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

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

    אתחול של VM הוא מהיר מאתחול של שרת פיסי, מה שמפחית את ה Mean Time To Recover (בקיצור: MTTR) של המערכת. האתחולים המהירים (בעת תקלות תוכנה) מתקזזים עם תקלות החומרה (הנדירות יחסית) של חומרת השרת המשותף – כך שבדרך כלל, וירטואליזציה דווקא מוסיפה לזמינות של כלל המערכת.

    הרצה של תוכנה על וירטואליזציה מספקת יתרונות נוספים:

    • היכולת “להרים” שרתים בקלות מפשטת את עבודת ה IT.
    • בזמן שדרוג, ניתן בקלות להרים VM עם גרסה חדשה יותר של התוכנה, במקביל לגרסה הישנה. ניתן להפעיל את המערכות זמן-מה במקביל ו”לכבות” את הגרסה הישנה רק לאחר שנצפתה עבודה תקינה של הגרסה החדשה.
    • שיפור הזמינות ע”י חלוקה: אם ניקח מערכת שהיא easily scalable, למשל שרת ווב, ובמקום VM אחד נציב שני VMs שלו על אותה מכונה פיסית – נקבל זמינות משופרת. אם VM אחד קרס בשל בעיית תוכנה, ה VM השני יכול להמשיך ולספק שירות. כל זאת – עם אותה החומרה (אבל קצת יותר זיכרון).
    • Checkpoints: טכנולוגיית הוירטואליזציה מאפשרת לקחת snapshot של VM מסוים, ואז לשמור את ההעתק בצד – או לשכפל אותו ל VM נוסף. יכולות אלו מקלות מאוד על עבודת ה IT. יכולות אלו מקלות מאוד גם על פיתוח תוכנה: לבדוק את התוכנה על מערכות הפעלה שונות בגרסאות שונות, או מפתח אחד שמתקין את הגרסה החדשה ביותר – ומשכפל אותה שתהיה זמינה לכל חבריו לצוות.

    איך וירטואליזציה עובדת

    הסביבה שמריצה וירטואליזציה של מכונה נקראת Virtual Machine Monitor (בקיצור: VMM) או Hypervisor. מקור השם Hypervisor טמון בהרשאות מערכת ההפעלה שניתנות לה: בעוד ההרשאות הגבוהות במערכת ההפעלה שייכות למשתמש העל (supervisor) – ל VMM נדרשו הרשאות גבוהות אפילו יותר, דרגה מעל ה supervisor, כלומר hypervisor.

    הציפייה מ Hypervisor היא שהוא ימלא 3 דרישות עיקריות:

    1. Fidelity – התוכנה תרוץ על ה VM בדיוק כפי שהיא רצה על מערכת הפעלה שמותקנת ישירות על החומרה.
    2. Safety – תוכנה שרצה על VM תהיה מבודדת מתוכנה שרצה על VM אחר על אותו מחשב פיסי. פעולות שיעשה VM אחד (ניהול משאבים של מערכת ההפעלה, למשל) – לא יפגע בפעילות התקינה של ה VM השני.
    3. Efficiency – התוכנה על ה VM לא תרוץ “הרבה יותר לאט” מאשר על הרצה ישירות על החומרה הפיסית.

    מקורה של הגדרה זו היא במסמך שפרסמו עוד ב 1974 Popek ו Goldberg – חוקרים אמריקאים שהיו חלוצים בנושא הוירטואליזציה. הם גם הגדירו את התנאים שמאפשרים וירטואליזציה. בגדול הם הגדירו 2 קבוצות של פקודות המעבד (instructions):

    • sensitive – פקודות שמבצעיות פעולות IO.
    • privileged – פקודות שיגרמו ל trap אם נקראו ב user mode.

    כידוע לכם (אני מניח), למעבדים יש 2 מצבי עבודה: user mode ו kernel mode. ה user mode נועד לתוכנות שרצות על מערכת ההפעלה (ולחלקים של מערכת ההפעלה) וה kernel mode נועד ל kernel של מערכת ההפעלה ורק בו ניתן לגשת ל I/O או לזיכרון ישירות. לכל mode יש סט פקודות זמין מעט שונה. אם פעולה של kernel mode נקראת ב user mode מתרחש אירוע בשם trap שגורם למעבד לעבור מצב ל kernel mode ואז להפעיל את הפקודה המבוקשת. מנגנון זה מאפשר לתוכנה לרוץ באופן ישיר על המעבד, בלי מעורבות של מערכת ההפעלה, ועדיין למערכת ההפעלה – לשלוט על כל הגישות לחומרה.

    Popek ו Goldberg הראו ש Fidelity בוירטואליזציה יתרחש רק כאשר הפקודות שהן sensitive הם subset של הפקודות שהן privileged (מצב שלא היה קיים במעבדי אינטל – נושא עליו נדבר בהמשך).

    דרך פשוטה ראשונה למשמש hypervisor היא כ interpreter שיפרשן כל פקודת שפת-מכונה של הקוד שרץ, ויחליט מה “בטוח” ולשלוח למעבד / מערכת ההפעלה – ובמה הוא רוצה להתערב ולשנות אותו. למשל: פקודת INC (כלומר: Increment) היא בטוחה, פקודה להשבתה של interrupt מסוים מהחומרה – היא לא, כי ייתכן שה interrupt הזה נועד ל VM אחר. בעזרת interpreter נוכל להשיג את דרישות הבטיחות והבידוד – אבל הביצועים יהיו גרועים.

    דרך יותר מעשית, והיא בעצם הדרך המקובלת היא להגדיר את ה Hypervisor כ”מערכת ההפעלה של מערכת ההפעלה”:

    הדוגמה הספציפית היא ל type1 hypervisors אבל העקרונות נכונים גם עבור type 2 hypervisors עליהם נדבר בהמשך.
    ה hypervisor “משתלט” על ה kernel mode של המעבד – כי עליו לתפוס את כל הגישות לחומרה, ומריץ את מערכת ההפעלה המתארחת (Guest OS) ב user mode. פנימית עושים הבחנה בין מערכת ההפעלה שזוכה ל virtual kernel mode (כלומר: מדמים לה שהיא רצה ב kernel mode – למרות שהיא לא) ול virtual user mode – מה שמערכת ההפעלה המתארחת מצפה שיהיה user mode.
    הערה: במעבדי אינטל ספציפית יש 4 modes של ריצה שנקראים ring 0 (המקביל ל kernel mode) עד ring 3 (המקביל ל user mode). מימושים רבים של VMM מעל ארכיטקטורת אינטל פשוט משתמשים ב ring 1 בכדי לתאר את ה virtual kernel mode, כאשר virtual user model פשוט נותר ring 3. יש כאלו שמתארים את ה hypervisor כ ring -1 – אבל לא נכנס לפינה הזו בפוסט….
    כאשר הקוד ב virtual kernel mode (שחושב שהוא ב kernel mode) מפעיל פקודה שהיא privileged אזי יש trap שמעביר את השליטה ל hypervisor.
    כאשר הקוד ב virtual kernel mode מפעיל פקודה שהיא sensitive אבל לא privileged (כלומר: לא גורמת ל trap) אזי תהיה שגיאה וסביר שמערכת ההפעלה תקרוס. אאוץ!

    מצב זה (בו יש פקודות sensitive שניגשות לחומרה, אך לא privileged – לא גורמות ל trap) היה קיים בכמה מארכיטקטורות המעבדים הזמינים בעולם, בניהן הארכיטקטורה הנפוצה ביותר בעולם – i386 של אינטל. אחד מהערכים של אינטל הוא תאימות לאחור (שנוכל על המעבד החדש להריץ אותן תוכנות שרצו על מעבדים ישנים) – מה שגרם למצב בו ארכיטקטורה זו שלא מתאימה לוירטואליזציה השתמרה במשך כמעט 30 שנה. ואיפה סביר יותר שתצמח טכנולוגיית הוירטואליזציה – על מחשבים פשוטים וזולים (אינטל) או מערכות מחשבי-ענק של IBM?

    הבעיה נפתרה לבסוף בשנת 2005 כאשר אינטל, בשיתוף פעולה לא-שגרתי עם AMD, הוסיפו סט פקודות למעבד שפותר את המצב. באינטל מעבדים אלו מסומנים כ VT (כלומר: Virtualization Technology) וב AMD השם הוא AMD-V – אבל בעצם זה אותו הדבר.

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

    הערה: אינטל עדיין מוכרת דגמים בודדים של מעבדים ללא VT – אני מניח שעבור מערכות בהן שינוי זה פוגע בתאימות לאחור.

    מה עשו בעולם האינטל עד הופעת ה VT (ספציפית VT-x)?
    חברת VMWare הציעה פתרון וירטואליזציה כבר בשנת 1999. הפתרון של VMWare סרק את קוד המכונה שנטען ל VM ושינה אותו כך שלא יקראו פקודות sensitive ב user space. אולי זה נעשה ע”י הרצת פקודה privileged תפלה קודם לכן – אולי בדרכים אחרות. פתרון נחשב פחות יעיל – אך הוא אפשר להריץ וירטואליזציה על מעבדי אינטל ללא VT (לא היו כאלה ב 1999).

    חלק גדול מפתרונות הוירטואליזציה היום (VMWare, VirtualBox, KVM, וכו’) יודעים לעבוד גם עם VT-x וגם בלי יכולת זו – ואז הם מבצעים fallback של שכתוב קוד המכונה למצב שמאפשר וירטואליזציה.

    הפתרון לשכתב את קוד המכונה לאי-שימוש בפקודות sensitive נחשב (מסיבות הגיונית) לפוגע Efficiency של הקוד הרץ על ה VM.
    אם תשאלו בפורום מקצועי את השאלה: “מה קורה אם אני מריץ את ה VMM שלי ללא VT-x”, סביר שתשובה שתקבלו היא “אז ה VM יזחל כמו עגלה!”.

    שני חבר’ה מ VMWare הראו במאמר שפרסמו ב 2006 שמסקנה זו איננה כ”כ נכונה. לכתוב קוד המכונה לפקודות לא sensitive יש אמנם עלות, אך הוא מפחית את השימוש ב traps במעבד. אירועי ה trap במעבד גורמים ל context switch שמייתר חלק מה caches של המעבד ומשבש חלק ממנגנוני ה prediction, והפחתה שלהם – יכולה להאיץ את הריצה.

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

    אינטל ממשיכה לנסות ולהציג יכולות במעבד שישפרו את ה efficiency של הוירטואליזציה – ונראה שיש עוד הרבה מה לשפר. גישה אחרת לעניין ה Efficiency מגיעה דווקא מצד התוכנה – זוהי גישת ה paravirtualization עליה נדבר בהמשך.

    סוגי Hypervisors

    Goldberg, אותו הזכרנו קודם, הוא גם זה שהגדיר את ההבחנה בין Type 1 Hypervisors ל Type 2 Hypervisors.


    Type 1 Hypervisors משמשים כמעין מערכת הפעלה והם התוכנה היחידה שרצה מעל החומרה / kernel mode. הם פשוטים ובד”כ אמינים יותר ממערכות ההפעלה[ב] (תכונה שנגזרת מכך יש להם הרבה פחות שורות קוד), והמפתחים שלהם יכולים לבצע אופטימיזציות שלא ניתן לעשות ב Type 2 Hypervisors. לרוב נראה אותם בסביבת השרת – היכן שאמינות ויעילות חשובות יותר

    Type 2 Hypervisors הם תוכנה רגילה שרצה על מערכת הפעלה מסוימת (לינוקס, חלונות, וכו’), אולי במקביל לתוכנות אחרות, ועדיין מספקת הפשטה של החומרה למערכת הפעלה המתארחת. Hypervisors אלו תלויים (לטובה, ולעתים כמגבלה) בשירותים שזמינים במערכת ההפעלה המארחת (Host OS). כאשר אנו כמפתחים משתמשים בתוכנת וירטואליזציה כדי להריץ VM – זהו כנראה Type 2 Hypervisors.

    למשל, בעולם של VMWare קל למפות את שני סוגי ה Hypervisors השונים:

    • ESX Server (ה hypervisor של חבילת vSphere) – הוא בעצם Type 1 Hypervisors.
    • VMWare Workstation / Player ו Fusion (למק) – הם בעצם Type 2 Hypervisors.

    באופן דומה ניתן לומר שגם VirtualBox (של סאן, עכשיו אורקל) הוא Type 2 hypervisors ו Hyper-V של מייקורוספט נחשב כ Type 1 hypervisor (הוא משולב במערכת ההפעלה).

    KVM (קיצור של Kernel based Virtual Machine), שהוא VMM בשימוש נרחב בעולם הלינוקס, הוא שנוי-במחלוקת מבחינת ההגדרה. הוא נארז כחבילה במערכת ההפעלה (כמו תוכנה hosted) ומקבל ממנה שירותים, אך יש לו גישה ישירה לחומרה (כמו type 1 hypervisor) – וכנראה שהוא נהנה מיתרונות דומים. ההגדרה, כמו הרבה הגדרות – היא טובה עד נקודה מסוימת.

    Paravirtualization

    עוד סוג של Hypervisors שקיימים הוא Hypervisors של Paravirtualization (“מעבר-לוירטואליזציה”). סוג זה של Hypervisors מנסה לשפר את ה Efficiency של הרצת ה VM, על חשבון מעט מה Fidelity. הרעיון הוא שהתוכנה שרצה על ה VM תהיה מודעת לכך שהיא שרצה בוירטואליזציה. ידע זה יתורגם לכמה קריאות API (נקראות Hypercalls) שבהן היא תשתמש במקרים מסוימים – שיאפשרו תהליך יעיל יותר של ההרצה. לרוב, מי שמודע לכך שהוא מתארח על סביבת ה Paravirtualization הוא מערכת ההפעלה המתארחת (ולא התוכנה שרצה עליה) והיא משתמש ב hypercalls לפעולות כמו עדכון הזיכרון הוירטואלי – פעולות שיכולות להיות פשוטות ומהירות יותר במידה והן נעשות בתיאום עם ה hypervisor.

    עוד נושא שמנסים להתמודד איתו ב Paravirtualization הוא העניין של “זמן אמיתי”. מערכת ההפעלה המתארחת חושבת שהיא רצה על החומרה, ולא מודעת לכך שהיא משתפת את המעבד / I/O עם מערכות הפעלה אחרות – מה שגורם לפער בתפיסת הזמן (time) שלה. אם היא מסנכרת את תפיסת הזמן שלה בעזרת ה API (היעיל) של ה Paravirtualization Hypervisor – בעיה זו יכולה להיפתר.

    Hypervisor ידוע שעובד ב Paravirtualization הוא Xen של חברת Citrix, הזמין גם בגרסה חינמית (אך ללא עדכונים אוטומטיים).

    Operating System-level virtualization

    בנוסף לנושא ה Efficiency של ה VM, שתמיד נמוך מהרצה ישירה על החומרה, עניין שמתסכל את המשתמשים בוירטואליזציה הוא נושא ניצולת המשאבים. הבעיה לא גדולה אם אני מריץ VM אחד על המחשב הפיסי, אך מה אם אני מריץ עשרה?
    נאמר שאני מריץ 10 VMs של לינוקס בגרסה זהה – זה אומר שכל השירותים של מערכת ההפעלה רצים 10 פעמים, הקוד שלהם נטען לזיכרון 10 פעמים, ומבני הנתונים שהם מנהלים – מנוהלים 10 פעמים. זהו מחיר ה isolation בין ה VMs – וזה מחיר יקר.

    VMWare, למשל, בנתה מנגנון שיודע לשתף דפי זיכרון בין VMs. כל עוד תוכן דף הזיכרון זהה – ה hypervisor יספק את אותו הדף לכמה VMs, וברגע שהוא משתנה – יפצל את הניהול וכל VM יקבל את העותק שנכון בשבילו. כפי שאתם מבינים יש כאן חסכון בכפילות משאבים – אך במחיר זמן הריצה.

    את הניסיונות לפתור את בעיית המשאבים – מנסים לפתור ה Linux Containers: להיות משהו יותר רזה מ VMM, אך יותר מקיף מניהול תהליכים במערכת ההפעלה, שה isolation שלהם מוגבל, וחלוקת המשאבים (למשל priority של תהליך) – לא מדויקת.

    המסע ל Linux Containers התחיל במנגנון בשם chroot שהוצג על Unix7 בשנת 1979 (כבר אמרנו בפתיחה שוירטואליזציה היא לא דבר חדש). chroot יצר סביבת ריצה מעט שונה לכל תהליך – והתמקד בשיקולי אבטחה בין תהליכים. הוא בעצם שינה את ה root folder של כל תהליך כך שיראה רק אותו שלו של התיקיות, ולא יוכל להשפיע על תהליכים אחרים (ע”י גישה לקבצים שלהם, למשל). הסביבה שנוצרה לתהליך נקראה chroot jail, שם שליווה עוד פתרונות דומים אחרים (למשל FreeBSD Jail – “כלא BSD החופשי” 🙂 )

    עם השנים, היכולות התפתחו, והמיצוב נעשה ידידותי יותר: לא עוד jail אלא container.
    מערכת ההפעלה לינוקס פיתחה יכולות ברמת הקרנל בכדי לתמוך באותם containers: בהתחלה cgroups (אריזת כמה תהליכים לקבוצה והקצאת משאבים מבוקרת לקבוצה) ולאחרונה LXC (קיצור של LinuX Containers, מבוסס על cgroups).

    ה containers לא מקבלים את רמת ה isolation של VM (“מערכת הפעלה שלמה בשבילי”): הם משתפים את מערכת ההפעלה, הגרסה שלה, הדרייברים שלה עם שאר התהליכים שרצים. אבל הם מקבלים מרחב זיכרון, רשת, ודיסק משלהם וכן מרחב הגדרות של מערכת ההפעלה משלהם (עד כמה שאפשר. נקודה חשובה ליציבות). כמו כן יש הקצאה שוויונית יותר של המשאבים בין ה containers השונים.

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

    תמורת פשרות הללו מקבלים Efficiency כמעט של מערכת ללא וירטואליזציה בכלל, וניצולת משאבים טובה הרבה יותר (דיסק, זיכרון, וכו’) מכיוון שרצה רק מערכת הפעלה אחת. ה mitigation לקריסת מערכת ההפעלה הוא בד”כ להריץ על containers יישומים ב cluster על גבי כמה מחשבים פיסיים שונים, או להריץ תהליכים שה availability שלהם הוא לא קריטי.

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

    Docker

    LXC הוא בסיס טוב ל”וירטואליזציה רזה”, אך הוא עדיין בסיסי לשימוש. מעליו צמחו פתרונות שונים לניהול workflows וניהול שוטף של העבודה. ללא ספק, הכלי שצמח הכי מהר בתחום זה הוא Docker. אם אתם עובדים בסביבת ענן / DevOps ולא שמעתם את השם הזה עד עכשיו – תבדקו את המקורות מהם אתם מתעדכנים.

    הקהילה (development community) של Docker היא מהמתפתחות במהירות הגבוהה ביותר בעולם הקוד הפתוח. בעת כתיבת הפוסט הפרויקט הוא בן משנה וחצי (החל במרס 2013), אך שימו לב לפופולריות שלו ב Github:

    כ Benchmark (הוגן, אני מקווה) בחרתי ב Chef – פרויקט באותו הדומיין פחות או יותר (אוטומציה של ניהול תצורה), פופולרי למדי, ושקיים כבר כ 5 שנים:

    אין דברים כאלו!

    ההתלהבות מ Docker היא קצת מעבר ל Github עצמו:

    • האגדה מספרת, שחברי הפרויקט החלו לעבוד ב Github בצורה ציבורית – ופתאום שמו לב שיש להם עשרות תורמים שהם לא מכירים (לרוב פרויקטי ה Open Source יש תורם משמעותי אחד).
    • יש כבר סטארט-אפים שסובבים סביב Docker: רשימת 10 הסטארט-אפים הטובים ביותר הבנויים מסביב ל Docker.
    • יש כבר כמה חברות שהחליטו לאמץ אותו כרכיב מרכזי בתשתית שלהן (למשל eBay, Rackspace, או Cloudflare).

    Docker קרוי על שם מכולות ההובלה המשמשות (גם/בעיקר) להובלה ימית. מספרים שהמצאת המכולה הסטדנרטית שינתה את ההובלה הימית מקצה לקצה: במקום “התמחות” בתובלה של חפצים מסוג מסוים – כמעט כולם מתמחים בהכל ע”י כך שהם מעבירים רק מכולות. המכולות מכתיבות את מבנה הספינות, את מבנה הנמלים את גודל המשאיות וכו’. הסטנדרט הזה אולי קצת מגביל פה ושם – אבל בעיקר מאוד מועיל: מאז שהופיעו המכולות מחיר ההובלה צנח ותהליכי ההובלה נעשו פשוטים יותר.

    Docker מאפשר:

    • לבנות containers של הקוד שלכם מתוך סקריפט.
    • לנהל את הגרסאות השונות של ה containers ב repositories שונים.
    • לבצע deploy קל container על שרת שהוגדר.
    • להעביר בקלות container רץ משרת אחד לשרת אחר (עבוד Continuous Delivery, פיזור עומסים, או סתם כדי להעביר אותו לסביבה מעודכנת יותר).

    Docker עוזר לנהל כמה מהמגבלות של Linux Containers ולהפוך אותן למגבלות קטנות יותר. סביבות ניהול משוכללות כבר קיימות לפתרונות וירטואליזציה (למשל VMWare vSphere), אך לא כ”כ ל Linux Containers – ובחינם. Docker הוא הבסיס לכזו סביבה, ויש לא מעט סטארט-אפים שמנסים להפוך אותו לסביבת ניהול שלמה. כפי שאמרנו Docker מתבסס היום על LXC, אבל בפרויקט כבר מדברים על אפשור היכולות שלו עבור סביבות וירטואליזציה שונות כגון Xen, KVM, או אפילו Hyper-V (של מייקרוסופט).

    הציפיות מ Docker הן דומות לאלו שהיינו מצפים היו ממכולות התובלה: לשנות את פני ניהול ה Data Center בצורה שתהפוך אותו לדבר שונה ממה שאנו מכירים אותו היום.

    סיכום

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

    אחד היעדים של וירטואליזציה הוא שהיא תהיה “בלתי מורגשת” – כך שאף אחד לא יידע שהאפליקציה רצה בסביבה וירטואלית. למרות הכל, מי שכותב התוכנה, ובעיקר מי שגם מודע ל deployment וה Operations שלה מושפע רבות מטכנולוגיות הוירטואליזציה, מהתכונות שלהן, ומהמורכבויות החדשות שמגיעות בעקבותיהן.

    למרות הדימוי ה”בשל” שיש לטכנולוגיות הוירטואליזציה – יש גם הרבה חידושים. התפר בין וירטואליזציה ל Operations הולך ומתטשטש ויש פתרונות שונים – לצרכים שונים.
    היום בו יהיה VM אחד דומיננטי בו כולם ישתמשו (למשל VMWare) – נראה רחוק מתמיד.

    עוד נושא קרוב, שלא דיברנו עליו בכלל הוא SDN – קיצור של Software Defined Network, תחום שעוסק בוירטואליזציה ואוטומציה של הניהול (המורכב) של הרשת. נשאיר משהו לפוסטים עתידיים.

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

    —

    [א] ע”פ האקדמיה ללשון עברית – הדמיה. אני לא מתחבר לתרגום הזה, ולכן אשאר עם “וירטואליזציה”.

    [ב] מאמר מפורסם בנושא הוא “?Are Virtual Machine Monitors Microkernels Done Right”

    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 בכמה מוצרים בפרודקשן:

    כרגע 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 – זיווג מהעננים\”

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