מחשבות, מחשבים, ושאר דברי בלע

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

• EC2 – הענן האלסטי של אמזון, שמאפשר להקצות מכונות וירטואליות על פי דרישה, שמריצות מה שבא לכם.
• S3 – שרות אחסון הנתונים הוותיק של אמזון
• RDS – שרותי בסיס נתונים, למעשה מכונת MySQL בניהול של אמזון, שכולל גם שרותי גיבוי, Read replica, סנאפ-שוטים של הנתונים ועוד.

מכונה וירטואלית בEC2 כוללת שטח אכסון מקומי (הרדיסקים לצורך העניין).
בעבר – מערכת הקבצים של המכונה ישבה על הדיסקים האלו. הImage של מערכות בשיטה הזו נקרא Instance store image, ואוכסנו בS3 – שרות איכסון הנתונים של אמזון.

אחת התכונות של הדיסקים המקומיים היא שכשהמכונה מוקצה מקבלים דיסקים ריקים, וכשהמכונה משוחררת (Terminated) המידע על הדיסקים האלו אובד לתמיד.
הדבר הזה גרם לקשיים אמיתיים להריץ בסיס נתונים על EC2, עד שאמזון פיתחו את הEBS (Elastic block store):
הEBS דומה במהות שלו למערכת איכסון מרכזית שמקצה דיסקים למכונות קצה, ולכן ביצועי הקריאה/כתיבה שלו תלויים בעומס עליו. במילים אחרות – אתם עשויים לסבול מביצועי קריאה/כתיבה ירודים כי משתמשים אחרים מתפרעים.
אם חשובים לכם ביצועי הIO, ואתם מוכנים לספוג אובדן של הנתונים אם המכונה משוחררת, שווה לההשתמש בדיסקים המקומיים, תקבלו ביצועיי IO צפויים יותר ובנוסף לא יהיה לכם תשלום לפי נפח הIO שאתם מבצעים (בניגוד לשימוש בEBS).
אפשר כמובן להגדיר אותם בתצורת  RAID-0 כדי לשפר את הביצועים

היתרון המרכזי ביותר לVolume של EBS הוא שמחזור החיים שלו נפרד מזה של המכונה אליה הוא מחובר: אם המכונה שאליה הוא מחובר משוחררת, הוא ממשיך להתקיים בנפרד ואפשר לחבר אותו למכונה אחרת (אבל רק לאחת בו זמנית כמובן).

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

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

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

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

כל המכונות הוירטואליות שלי מבוססות על אותו IMAGE, למרות שהן מסוגים שונים ומשונים, יש לי שם:

• מכונות DNS
• מכונות Memcached
• מכונות WEB
• מכונות Gearman
• מכונת HAProxy
• ועוד

אז איך יתכן שכל המכונות מבוססות על אותו IMAGE?
כאמור, כשאני מקצה מכונה אני מעביר לה את ה"סוג" שלה בUSER-DATA.
כשהמכונה עולה, היא מעבירה את הסוג שלה לשרת תצורה מרכזי מסוג Puppet, שאומר למכונה מה לעשות כדי להפוך למה שהיא אמורה להפוך.
אפשר למלא כמה פוסטים רק על Puppet (ואפילו כתבתי עליו כבר פעם), אבל הפעם אני לא ארחיב.

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

פתרון אלטרנטיבי הוא להשתמש במערכת Marionette collective:
קונספטואלית, mcollective  היא נטולת שרת מרכזי.
יש שרת הודעות כללי (Message queue) מסוג ActiveMQ שמשמש לתקשורת בין המכונות. פלאגינים מיוחדים בשם Agents רצים על המכונות, ומאפשרים ביצוע פעולות שונות ומשונות עליהם.
הפעולות יכולות להיות מסוננות לפי "עובדות" שהמכונות יודעות על עצמן, במילים אחרות – מכונת WEB, שיודעת היא מכונת WEB, לא תבצע פעולה שמיועדת למכונת Gearman.
ההתקנה של MCollective היא לא מאוד מסובכת, ומה שיפה זה שהActiveMQ עובד, כל מכונה שעולה אוטומטית זמינה דרך הMCollective (כמובן – היא צריכה להריץ את השרת של MCollective, אבל כל זה חלק מהIMAGE הבסיסי.
שווה מאוד לראות את הסרטונים באתר של Mcollective כדי להבין במה מדובר.

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

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