მოქნილი ღრუბლის ორკესტრი: რა მოყვება მას

IaaS (ვირტუალური მონაცემთა ცენტრის) სერვისების უზრუნველსაყოფად, ჩვენ რუსონიქსი ჩვენ ვიყენებთ კომერციულ ორკესტრატორს მოქნილი ღრუბელი ორკესტრი (FCO). ამ გადაწყვეტას აქვს საკმაოდ უნიკალური არქიტექტურა, რაც განასხვავებს მას ფართო საზოგადოებისთვის ცნობილი Openstack-ისა და CloudStack-ისგან.

KVM, VmWare, Xen, Virtuozzo6/7, ისევე როგორც კონტეინერები იმავე Virtuozzo-დან, მხარდაჭერილია როგორც გამოთვლითი კვანძების ჰიპერვიზორები. მხარდაჭერილი შენახვის პარამეტრები მოიცავს ადგილობრივ, NFS, Ceph და Virtuozzo Storage.

FCO მხარს უჭერს მრავალი კლასტერის შექმნას და მართვას ერთი ინტერფეისიდან. ანუ, თქვენ შეგიძლიათ მართოთ Virtuozzo კლასტერი და KVM + Ceph კლასტერი მათ შორის მაუსის დაწკაპუნებით.

თავის არსში, FCO არის ყოვლისმომცველი გადაწყვეტა ღრუბლოვანი პროვაიდერებისთვის, რომელიც, გარდა ორკესტრირებისა, ასევე მოიცავს ბილინგის ყველა პარამეტრს, გადახდის დანამატებს, ინვოისებს, შეტყობინებებს, გადამყიდველებს, ტარიფებს და ა.შ. თუმცა, ბილინგის ნაწილს არ შეუძლია დაფაროს ყველა რუსული ნიუანსი, ამიტომ ჩვენ მივატოვეთ მისი გამოყენება სხვა გადაწყვეტის სასარგებლოდ.

მე ძალიან კმაყოფილი ვარ ყველა ღრუბლის რესურსზე უფლებების განაწილების მოქნილი სისტემით: სურათებზე, დისკებზე, პროდუქტებზე, სერვერებზე, ფეიერვოლებზე - ამ ყველაფრის „გაზიარება“ და უფლებების მინიჭება მომხმარებლებს შორის და თუნდაც სხვადასხვა კლიენტების მომხმარებლებს შორის. თითოეულ კლიენტს შეუძლია შექმნას რამდენიმე დამოუკიდებელი მონაცემთა ცენტრი თავის ღრუბელში და მართოს ისინი ერთი მართვის პანელიდან.

არქიტექტურულად, FCO შედგება რამდენიმე ნაწილისგან, რომელთაგან თითოეულს აქვს საკუთარი დამოუკიდებელი კოდი და ზოგიერთს აქვს საკუთარი მონაცემთა ბაზა.

Skyline - ადმინისტრატორი და მომხმარებლის ინტერფეისი
Jade - ბიზნეს ლოგიკა, ბილინგი, დავალების მართვა
ვეფხვი – სერვისის კოორდინატორი, მართავს და კოორდინაციას უწევს ინფორმაციის გაცვლას ბიზნეს ლოგიკასა და კლასტერებს შორის.
XVPM მენეჯერი – კლასტერული ელემენტების მართვა: კვანძები, საცავი, ქსელი და ვირტუალური მანქანები.
XVPAgent – კვანძებზე დაინსტალირებული აგენტი XVPManager-თან ურთიერთობისთვის

თითოეული კომპონენტის არქიტექტურის შესახებ დეტალური სიუჟეტის ჩართვას ვგეგმავთ სტატიების სერიაში, თუ, რა თქმა უნდა, თემა იწვევს ინტერესს.

FCO-ს მთავარი უპირატესობა მისი „ყუთიანი“ ბუნებიდან გამომდინარეობს. სიმარტივე და მინიმალიზმი თქვენს სამსახურშია. საკონტროლო კვანძისთვის გამოყოფილია ერთი ვირტუალური მანქანა 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 არის უაღრესად კონფიგურირებადი სისტემა. მას აქვს უამრავი პარამეტრი და შესვლის წერტილები სამუშაო ნაკადის შესაცვლელად:

1. მორგებული დანამატები მხარდაჭერილია, მაგალითად, შეგიძლიათ დაწეროთ თქვენი საკუთარი ბილინგის მეთოდი ან თქვენი საკუთარი გარე რესურსი მომხმარებლისთვის
2. მხარდაჭერილია გარკვეული მოვლენების მორგებული ტრიგერები, მაგალითად, პირველი ვირტუალური მანქანის დამატება კლიენტს, როდესაც ის შეიქმნა
3. ინტერფეისში მორგებული ვიჯეტები მხარდაჭერილია, მაგალითად, YouTube ვიდეოს პირდაპირ მომხმარებლის ინტერფეისში ჩასმა.

ყველა პერსონალიზაცია დაწერილია FDL-ში, რომელიც დაფუძნებულია 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 მისამართი საათში, დამატებითი GB დისკი საათში ან უბრალოდ სერვერი.

გასაღებები შეიძლება გამოყენებულ იქნას გარკვეული რესურსების აღსანიშნავად, რათა შეცვალოს მათთან მუშაობის ლოგიკა. მაგალითად, ჩვენ შეგვიძლია მოვნიშნოთ სამი ფიზიკური კვანძი Weight კლავიშით, ხოლო ზოგიერთი კლიენტი იმავე გასაღებით მოვნიშნოთ, რითაც ეს კვანძები პირადად ამ კლიენტებს გავანაწილოთ. ჩვენ ვიყენებთ ამ მექანიზმს VIP კლიენტებისთვის, რომლებსაც არ მოსწონთ მეზობლები თავიანთი VM-ების გვერდით. თავად ფუნქციონირება შეიძლება ბევრად უფრო ფართოდ იქნას გამოყენებული.

ლიცენზირების მოდელი გულისხმობს ფიზიკური კვანძის თითოეული პროცესორის ბირთვის გადახდას. ღირებულებაზე ასევე გავლენას ახდენს კლასტერის ტიპების რაოდენობა. თუ თქვენ გეგმავთ KVM-ისა და VMware-ის ერთად გამოყენებას, მაგალითად, ლიცენზიის ღირებულება გაიზრდება.

FCO არის სრულფასოვანი პროდუქტი, მისი ფუნქციონირება ძალიან მდიდარია, ამიტომ ვგეგმავთ ერთდროულად მოვამზადოთ რამდენიმე სტატია ქსელის ნაწილის ფუნქციონირების დეტალური აღწერით.

ამ ორკესტრატორთან რამდენიმე წელი ვიმუშავეთ, შეგვიძლია აღვნიშნოთ, როგორც ძალიან შესაფერისად. სამწუხაროდ, პროდუქტი არ არის ხარვეზების გარეშე:

• ჩვენ მოგვიწია მონაცემთა ბაზის ოპტიმიზაცია, რადგან შეკითხვებმა დაიწყო შენელება, რადგან მათში მონაცემთა რაოდენობა გაიზარდა;
• ერთი ავარიის შემდეგ, აღდგენის მექანიზმმა არ იმუშავა შეცდომის გამო და ჩვენ მოგვიწია უბედური კლიენტების მანქანების აღდგენა ჩვენი სკრიპტების გამოყენებით;
• კვანძის მიუწვდომლობის გამოვლენის მექანიზმი ჩართულია კოდში და მისი მორგება შეუძლებელია. ანუ, ჩვენ არ შეგვიძლია შევქმნათ საკუთარი პოლიტიკა კვანძის მიუწვდომლობის დასადგენად.
• შესვლა ყოველთვის არ არის დეტალური. ხანდახან, როცა კონკრეტული პრობლემის გასაგებად ძალიან დაბალ საფეხურზე დაწევა გჭირდებათ, არ გაქვთ საკმარისი კოდი, რომ ზოგიერთი კომპონენტი გაიგოთ რატომ;

სულ: ზოგადად, პროდუქტის შთაბეჭდილებები კარგია. ჩვენ მუდმივ კონტაქტში ვართ ორკესტრატორ დეველოპერებთან. ბიჭები კონსტრუქციული თანამშრომლობისკენ არიან განწყობილნი.

მიუხედავად მისი სიმარტივისა, FCO-ს აქვს ფართო ფუნქციონირება. მომავალ სტატიებში ჩვენ ვგეგმავთ უფრო ღრმად ჩავუღრმავდეთ შემდეგ თემებს:

• ქსელი FCO-ში
• ცოცხალი აღდგენისა და FQP პროტოკოლის უზრუნველყოფა
• საკუთარი დანამატებისა და ვიჯეტების დაწერა
• დამატებითი სერვისების დაკავშირება, როგორიცაა Load Balancer და Acronis
• სარეზერვო
• კვანძების კონფიგურაციისა და კონფიგურაციის ერთიანი მექანიზმი
• ვირტუალური მანქანის მეტამონაცემების დამუშავება

ZY თუ სხვა ასპექტები გაინტერესებთ, დაწერეთ კომენტარებში. Ადევნეთ თვალყური!

წყარო: www.habr.com