🥇ارکستراتور ابر انعطاف پذیر: با چه چیزی بخوریم

برای ارائه خدمات IaaS (مرکز داده مجازی)، ما روسونیکس ما از یک ارکستراتور تجاری استفاده می کنیم ارکستراتور ابر انعطاف پذیر (FCO). این راه حل دارای معماری نسبتاً منحصر به فردی است که آن را از Openstack و CloudStack که برای عموم شناخته شده است متمایز می کند.

KVM، VmWare، Xen، Virtuozzo6/7، و همچنین کانتینرهایی از همان Virtuozzo به عنوان هایپروایزر گره محاسباتی پشتیبانی می شوند. گزینه های ذخیره سازی پشتیبانی شده شامل محلی، NFS، Ceph و Virtuozzo Storage است.

FCO از ایجاد و مدیریت چندین خوشه از یک رابط پشتیبانی می کند. به این معنا که می‌توانید یک خوشه Virtuozzo و یک خوشه KVM + Ceph را با جابجایی بین آنها با کلیک ماوس مدیریت کنید.

در هسته خود، FCO یک راه حل جامع برای ارائه دهندگان ابری است که علاوه بر هماهنگی، شامل صورتحساب، با تمام تنظیمات، پلاگین های پرداخت، فاکتورها، اعلان ها، فروشندگان، تعرفه ها و غیره است. با این حال، بخش صورتحساب قادر به پوشش تمام تفاوت های ظریف روسی نیست، بنابراین ما استفاده از آن را به نفع راه حل دیگری رها کردیم.

من از سیستم منعطف برای توزیع حقوق برای همه منابع ابری بسیار خوشحالم: تصاویر، دیسک ها، محصولات، سرورها، فایروال ها - همه اینها را می توان بین کاربران و حتی بین کاربران مشتریان مختلف "به اشتراک گذاشت" و حقوق اعطا کرد. هر مشتری می تواند چندین مرکز داده مستقل را در فضای ابری خود ایجاد کند و آنها را از یک کنترل پنل مدیریت کند.

از نظر معماری، FCO از چندین بخش تشکیل شده است که هر کدام کد مستقل خود را دارند و برخی نیز پایگاه داده خود را دارند.

افق مریی – مدیریت و رابط کاربری
یشم - منطق کسب و کار، صورتحساب، مدیریت وظایف
تایگرلی - هماهنگ کننده خدمات، تبادل اطلاعات بین منطق تجاری و خوشه ها را مدیریت و هماهنگ می کند.
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 یک سیستم بسیار قابل تنظیم است. تعداد زیادی تنظیمات و نقاط ورودی برای تغییر گردش کار دارد:

افزونه های سفارشی پشتیبانی می شوند، به عنوان مثال، می توانید روش صورتحساب خود یا منبع خارجی خود را بنویسید تا به کاربر ارائه دهید
تریگرهای سفارشی برای رویدادهای خاص پشتیبانی می شوند، به عنوان مثال، اضافه کردن اولین ماشین مجازی به یک کلاینت هنگام ایجاد آن
ویجت های سفارشی در رابط پشتیبانی می شوند، به عنوان مثال، جاسازی یک ویدیوی YouTube به طور مستقیم در رابط کاربری.

تمام سفارشی سازی ها با 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" این تابع متن فراخوانی را ذخیره می کند و اولین باری که فراخوانی می شود خالی (nil) خواهد بود. که به ما امکان می دهد ماشه خود را ثبت کنیم. در triggerType نشان می‌دهیم که تریگر قبل از عملیات انتشار فراخوانی شده است و فقط بر کاربران تأثیر می‌گذارد. البته ما به مدیران سیستم اجازه می دهیم همه چیز را منتشر کنند. در triggerOptions عملیاتی را که تریگر برای آنها فعال می شود را به تفصیل شرح می دهیم.

و نکته اصلی بازگشت {exitState = "CANCEL"} است، به همین دلیل است که ماشه توسعه یافته است. هنگامی که کاربر سعی می کند تصویر خود را در کنترل پنل به اشتراک بگذارد، خرابی را برمی گرداند.

در معماری FCO، هر شی (دیسک، سرور، تصویر، شبکه، آداپتور شبکه و غیره) به عنوان یک موجودیت منبع نشان داده می شود که دارای پارامترهای مشترک است:

UUID منبع
نام منبع
نوع منبع
UUID مالک منبع
وضعیت منبع (فعال، غیرفعال)
ابرداده منابع
کلیدهای منبع
UUID محصولی که صاحب منبع است
منبع VDC

هنگامی که با استفاده از یک API کار می کنید، زمانی که همه منابع بر اساس یک اصل کار می کنند، این بسیار راحت است. محصولات توسط ارائه دهنده پیکربندی و توسط مشتری سفارش داده می شوند. از آنجایی که صورتحساب ما در کنار است، مشتری می تواند آزادانه هر محصولی را از پنل سفارش دهد. بعداً در صورتحساب محاسبه می شود. محصول می تواند یک آدرس IP در ساعت، یک گیگابایت دیسک اضافی در ساعت یا فقط یک سرور باشد.

از کلیدها می توان برای علامت گذاری منابع خاصی برای تغییر منطق کار با آنها استفاده کرد. به عنوان مثال، می‌توانیم سه گره فیزیکی را با کلید Weight علامت‌گذاری کنیم و برخی از کلاینت‌ها را با همان کلید علامت‌گذاری کنیم و بدین ترتیب این گره‌ها را شخصاً به این کلاینت‌ها اختصاص دهیم. ما از این مکانیسم برای مشتریان VIP استفاده می کنیم که همسایگان را در کنار ماشین های مجازی خود دوست ندارند. خود عملکرد می تواند به طور گسترده تری مورد استفاده قرار گیرد.

مدل مجوز شامل پرداخت برای هر هسته پردازنده یک گره فیزیکی است. هزینه نیز تحت تأثیر تعداد انواع خوشه است. به عنوان مثال، اگر قصد دارید از KVM و VMware با هم استفاده کنید، هزینه مجوز افزایش می یابد.

FCO یک محصول تمام عیار است، عملکرد آن بسیار غنی است، بنابراین ما قصد داریم چندین مقاله را به طور همزمان با شرح دقیق عملکرد بخش شبکه آماده کنیم.

با چندین سال کار با این ارکستراتور می توانیم آن را بسیار مناسب بدانیم. افسوس، محصول بدون نقص نیست:

ما مجبور شدیم پایگاه داده را بهینه سازی کنیم، زیرا با افزایش حجم داده ها، کوئری ها شروع به کند شدن کردند.
پس از یک تصادف، مکانیسم بازیابی به دلیل یک اشکال کار نکرد و ما مجبور شدیم با استفاده از مجموعه ای از اسکریپت های خود، اتومبیل های مشتریان بدبخت را بازیابی کنیم.
مکانیزم برای تشخیص در دسترس نبودن گره ها به کد متصل است و نمی توان آن را سفارشی کرد. یعنی ما نمی‌توانیم سیاست‌های خود را برای تعیین در دسترس نبودن یک گره ایجاد کنیم.
ورود به سیستم همیشه با جزئیات نیست. گاهی اوقات، زمانی که برای درک یک مشکل خاص نیاز به پایین آمدن سطح بسیار پایین دارید، کد منبع کافی برای برخی از مؤلفه‌ها برای درک دلیل آن ندارید.

کل TOTAL: به طور کلی، برداشت از محصول خوب است. ما دائماً با سازندگان ارکستر در تماس هستیم. بچه ها تمایل به همکاری سازنده دارند.

علیرغم سادگی، FCO دارای عملکرد گسترده ای است. در مقالات آتی قصد داریم بیشتر به موضوعات زیر بپردازیم:

شبکه در FCO
ارائه زنده بازیابی و پروتکل FQP
پلاگین ها و ویجت های خود را بنویسید
اتصال خدمات اضافی مانند Load Balancer و Acronis
پشتیبان گیری
مکانیزم یکپارچه برای پیکربندی و پیکربندی گره ها
پردازش ابرداده ماشین مجازی

Z.Y. اگر به جنبه های دیگر علاقه دارید در نظرات بنویسید. گوش به زنگ باشید!

منبع: www.habr.com

Flexiant Cloud Orchestrator: با چه چیزی همراه است

اضافه کردن نظر انصراف از پاسخ