Flexiant Cloud Orchestrator: עם מה זה מגיע

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

KVM, VmWare, Xen, Virtuozzo6/7, וכן קונטיינרים מאותו Virtuozzo נתמכים כ-Hypervisors של צומת מחשוב. אפשרויות האחסון הנתמכות כוללות אחסון מקומי, NFS, Ceph ו-Virtuozzo.

FCO תומך ביצירה וניהול של אשכולות מרובים מממשק אחד. כלומר, ניתן לנהל אשכול Virtuozzo ומקבץ KVM + Ceph על ידי מעבר ביניהם בלחיצת עכבר.

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

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

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

קו רקיע - ממשק מנהל וממשק משתמש
יַרקָן - היגיון עסקי, חיוב, ניהול משימות
Tigerlily – רכז שירות, מנהל ומתאם את חילופי המידע בין ההיגיון העסקי לאשכולות.
XVPManager – ניהול רכיבי אשכול: צמתים, אחסון, רשת ומכונות וירטואליות.
XVPAgent – סוכן המותקן בצמתים לאינטראקציה עם XVPManager

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

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

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

התצורה כולה נערכת בתחילה בתבניות, ואז המחולל מופעל
#build-config אשר יפיק קובץ vars ויורה לשירותים לקרוא מחדש את התצורה. ממשק המשתמש נחמד וניתן למיתוג בקלות.

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

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

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

כל ההתאמה האישית כתובה ב-FDL, המבוססת על Lua. אם אתה מכיר את Lua, לא יהיו בעיות עם FDL.

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

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

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

והעיקר הוא לחזור {exitState = “CANCEL”}, ובגלל זה פותח הטריגר. זה יחזיר כשל כאשר המשתמש ינסה לשתף את התמונה שלו בלוח הבקרה.

בארכיטקטורת FCO, כל אובייקט (דיסק, שרת, תמונה, רשת, מתאם רשת וכו') מיוצג כישות משאב, שיש לה פרמטרים משותפים:

• משאב UUID
• שם המשאב
• סוג משאב
• UUID של בעל המשאב
• מצב משאב (פעיל, לא פעיל)
• מטא נתונים של משאבים
• מפתחות משאבים
• UUID של המוצר שבבעלותו המשאב
• משאב VDC

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

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

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

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

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

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

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

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

• נטוורקינג ב-FCO
• מתן שחזור חי ופרוטוקול FQP
• כתיבת תוספים ווידג'טים משלך
• חיבור שירותים נוספים כגון Load Balancer ו-Acronis
• גיבוי
• מנגנון מאוחד לקביעת תצורה והגדרת צמתים
• עיבוד מטא נתונים של מכונות וירטואליות

ZY כתבו בתגובות אם אתם מתעניינים בהיבטים נוספים. המשך לעקוב!

מקור: www.habr.com