IaaS (ورچوئل ڊيٽا سينٽر) خدمتون مهيا ڪرڻ لاءِ، اسان اسان هڪ تجارتي آرڪيسٽرٽر استعمال ڪندا آهيون (FCO). ھن حل ۾ ھڪڙو منفرد فن تعمير آھي، جيڪو ان کي Openstack ۽ CloudStack کان ڌار ڪري ٿو، عام عوام لاء سڃاتل آھي.
KVM، VmWare، Xen، Virtuozzo6/7، گڏوگڏ ساڳي Virtuozzo کان ڪنٽينرز کي ڪمپيوٽ نوڊ هائپر وائزر طور سپورٽ ڪيو ويو آهي. سپورٽ ٿيل اسٽوريج اختيارن ۾ مقامي، NFS، Ceph ۽ Virtuozzo Storage شامل آهن.
FCO ھڪڙي انٽرفيس مان گھڻن ڪلسترن جي ٺاھڻ ۽ انتظام کي سپورٽ ڪري ٿو. اهو آهي، توهان منظم ڪري سگهو ٿا هڪ Virtuozzo ڪلستر ۽ هڪ KVM + Ceph ڪلستر انهن جي وچ ۾ مائوس جي ڪلڪ سان سوئچ ڪندي.
ان جي بنيادي طور تي، FCO ڪلائوڊ فراهم ڪندڙن لاءِ هڪ جامع حل آهي، جنهن ۾، آرڪيسٽريشن کان علاوه، بلنگ پڻ شامل آهي، سڀني سيٽنگن سان، ادائگي جي پلگ ان، انوائس، نوٽيفڪيشن، ريليررز، ٽريف، وغيره. تنهن هوندي به، بلنگ حصو سڀني روسي nuances کي ڍڪي ڪرڻ جي قابل نه آهي، تنهنڪري اسان ان جي استعمال کي هڪ ٻئي حل جي حق ۾ ڇڏي ڏنو.
مان تمام خوش آهيان لچڪدار سسٽم سان حق ورهائڻ لاءِ سڀني ڪلائوڊ وسيلن تي: تصويرون، ڊسڪ، پروڊڪٽس، سرورز، فائر والز - هي سڀ ”شيئر“ ڪري سگھجن ٿا ۽ حق ڏنا ويا صارفين جي وچ ۾، ۽ حتي مختلف ڪلائنٽ جي استعمال ڪندڙن جي وچ ۾. هر ڪلائنٽ پنهنجي ڪلائوڊ ۾ ڪيترائي آزاد ڊيٽا مرڪز ٺاهي سگهن ٿا ۽ انهن کي هڪ ڪنٽرول پينل مان منظم ڪري سگهن ٿا.
تعميراتي طور تي، FCO ڪيترن ئي حصن تي مشتمل آهي، جن مان هر هڪ کي پنهنجو آزاد ڪوڊ آهي، ۽ ڪجهه پنهنجو ڊيٽابيس آهي.
اوج - منتظم ۽ يوزر انٽرفيس
Jade - ڪاروباري منطق، بلنگ، ڪم جو انتظام
خوشگوار - سروس ڪوآرڊينيٽر، ڪاروباري منطق ۽ ڪلستر جي وچ ۾ معلومات جي تبادلي کي منظم ۽ منظم ڪري ٿو.
XVP مئنيجر - ڪلستر عناصر جو انتظام: نوڊس، اسٽوريج، نيٽورڪ ۽ ورچوئل مشينون.
XVPAgent - ايڪس وي پي مئنيجر سان رابطو ڪرڻ لاءِ نوڊس تي نصب ٿيل ايجنٽ
اسان مضمونن جي سلسلي ۾ هر جزو جي فن تعمير بابت تفصيلي ڪهاڻي شامل ڪرڻ جو ارادو ڪيو، جيڪڏهن، يقينا، موضوع دلچسپي پيدا ڪري ٿي.
FCO جو بنيادي فائدو ان جي "باڪس" فطرت مان نڪرندو آهي. سادگي ۽ minimalism توهان جي خدمت ۾ آهن. ڪنٽرول نوڊ لاء، Ubuntu تي هڪ مجازي مشين مختص ڪئي وئي آهي، جنهن ۾ سڀني ضروري پيڪيجز نصب ٿيل آهن. سڀئي سيٽنگون ترتيب واري فائلن ۾ رکيل آھن متغير-قدر جي صورت ۾:
# 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 هڪ انتهائي حسب ضرورت سسٽم آهي. اهو ڪم فلو کي تبديل ڪرڻ لاء سيٽنگون ۽ داخلا پوائنٽن جو وڏو تعداد آهي:
- ڪسٽم پلگ ان جي مدد ڪئي وئي آهي، مثال طور، توهان لکي سگهو ٿا پنهنجو بلنگ جو طريقو يا پنهنجو خارجي وسيلو استعمال ڪندڙ کي مهيا ڪرڻ لاءِ
- خاص واقعن لاءِ ڪسٽم ٽريگرز سپورٽ آهن، مثال طور، پهرين ورچوئل مشين کي ڪلائنٽ ۾ شامل ڪرڻ جڏهن اها ٺاهي وئي آهي
- انٽرفيس ۾ ڪسٽم ويجٽ کي سپورٽ ڪيو ويو آهي، مثال طور، يوٽيوب وڊيو کي سڌو سنئون يوزر انٽرفيس ۾ شامل ڪرڻ.
سڀ ڪسٽمائيزيشن FDL ۾ لکيل آهي، جيڪا لوا تي ٻڌل آهي. جيڪڏهن توهان لوا کي ڄاڻو ٿا، 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 پتو في ڪلاڪ، هڪ اضافي GB ڊسڪ في ڪلاڪ، يا صرف هڪ سرور.
ڪي خاص وسيلن کي نشانو بڻائڻ لاءِ استعمال ڪري سگھجن ٿا انھن سان ڪم ڪرڻ جي منطق کي تبديل ڪرڻ لاءِ. مثال طور، اسان ٽن فزيڪل نوڊس کي Weight key سان نشان لڳائي سگھون ٿا، ۽ ڪجھ ڪلائنٽ کي ساڳي ڪيئي سان نشانو بڻائي سگھون ٿا، اھڙي طرح انھن نوڊس کي ذاتي طور تي انھن ڪلائنٽ کي مختص ڪري سگھون ٿا. اسان هي ميکانيزم استعمال ڪندا آهيون VIP گراهڪن لاءِ جيڪي پاڙيسرين کي پسند نٿا ڪن انهن جي وي ايم جي اڳيان. ڪارڪردگي پاڻ کي وڌيڪ وڏي پيماني تي استعمال ڪري سگهجي ٿو.
لائسنس واري ماڊل ۾ شامل آهي ادا ڪرڻ هر پروسيسر ڪور جي جسماني نوڊ جي. قيمت پڻ ڪلستر جي قسمن جي تعداد کان متاثر ٿئي ٿي. جيڪڏهن توهان KVM ۽ VMware گڏ ڪرڻ جو منصوبو ٺاهيو ٿا، مثال طور، لائسنس جي قيمت وڌندي.
FCO هڪ مڪمل پراڊڪٽ آهي، ان جي ڪارڪردگي تمام گهڻي آهي، تنهنڪري اسان نيٽ ورڪ جي ڪم جي تفصيلي وضاحت سان گڏ هڪ ئي وقت ۾ ڪيترائي مضمون تيار ڪرڻ جو منصوبو ٺاهيو.
ڪيترن ئي سالن تائين هن آرڪيسٽرٽر سان ڪم ڪيو، اسان ان کي تمام مناسب طور تي نشان لڳايو. افسوس، پيداوار بغير بغير ناهي:
- اسان کي ڊيٽابيس کي بهتر ڪرڻو پيو ڇو ته سوالن کي سست ڪرڻ شروع ڪيو جيئن انهن ۾ ڊيٽا جي مقدار ۾ اضافو ٿيو؛
- ھڪڙي حادثي کان پوء، بحالي واري ميڪانيزم ھڪڙي بگ جي ڪري ڪم نه ڪيو، ۽ اسان کي پنھنجي اسڪرپٽ جي پنھنجي سيٽ کي استعمال ڪندي بدقسمتي گراهڪن جي ڪارن کي بحال ڪرڻو پيو.
- نوڊ جي دستيابي کي ڳولڻ جو ميکانيزم ڪوڊ ۾ سخت آهي ۽ ترتيب نه ٿو ڏئي سگهجي. اهو آهي، اسان هڪ نوڊ جي غير موجودگي کي طئي ڪرڻ لاء اسان جي پنهنجي پاليسين ٺاهي نٿا سگهون.
- لاگنگ هميشه تفصيلي نه آهي. ڪڏهن ڪڏهن، جڏهن توهان کي ڪنهن خاص مسئلي کي سمجهڻ لاءِ تمام گهٽ سطح تي وڃڻو پوندو، ته توهان وٽ ڪافي سورس ڪوڊ نه هوندو آهي ڪجهه حصن لاءِ اهو سمجهڻ لاءِ ڇو؛
TOTAL: عام طور تي، پيداوار جا تاثر سٺا آهن. اسان آرڪيسٽرٽر ڊولپرز سان مسلسل رابطي ۾ آهيون. ماڻهو تعميري تعاون لاءِ تيار آهن.
ان جي سادگي جي باوجود، FCO وسيع ڪارڪردگي آهي. مستقبل جي مضمونن ۾ اسان هيٺ ڏنل عنوانن ۾ وڌيڪ تفصيل سان غور ڪرڻ جو ارادو ڪيو آهي:
- FCO تي نيٽ ورڪنگ
- لائيو بحالي ۽ FQP پروٽوڪول مهيا ڪرڻ
- توهان جي پنهنجي پلگ ان ۽ ويجٽ لکڻ
- اضافي خدمتن کي ڳنڍڻ جهڙوڪ لوڊ بيلنسر ۽ Acronis
- بيڪ اپ
- نوڊس کي ترتيب ڏيڻ ۽ ترتيب ڏيڻ لاء متحد ميڪانيزم
- پروسيسنگ ورچوئل مشين ميٽا ڊيٽا
ZY تبصرن ۾ لکو جيڪڏهن توهان ٻين حصن ۾ دلچسپي رکو ٿا. ڏسندا رهو!
جو ذريعو: www.habr.com