ISP համակարգ, ներիր և հրաժեշտ: Ինչու և ինչպես ենք գրել մեր սերվերի կառավարման վահանակը

Բարեւ Ձեզ! Մենք «Հոսթինգ տեխնոլոգիաներ» ենք և 5 տարի առաջ գործարկեցինք VDSina — առաջին vds հոստինգը, որը ստեղծվել է հատուկ մշակողների համար: Մենք ձգտում ենք այն դարձնել հարմար, ինչպես DigitalOcean-ը, բայց ռուսական աջակցությամբ, վճարման եղանակներով և սերվերներով Ռուսաստանում: Բայց DigitalOcean-ը ոչ միայն հուսալիության և գնի, այլև սպասարկման մասին է:

ISPsystem-ի ծրագրակազմը պարզվեց, որ պարան է, որը կապում է մեր ձեռքերը հիանալի ծառայության ճանապարհին: Երեք տարի առաջ մենք օգտագործեցինք Billmanager billing-ը և VMmanager սերվերի կառավարման վահանակը և արագ հասկացանք, որ գրեթե անհնար է լավ ծառայություն մատուցել առանց մեր սեփական վահանակի:

Ինչպես ISP համակարգը սպանեց հարմարավետությունը

Սխալներ

Մենք չկարողացանք ինքներս շտկել սխալը, ամեն անգամ, երբ ստիպված էինք լինում գրել ուրիշի աջակցությանը և սպասել: Ցանկացած խնդրի լուծումը պահանջում էր պատասխան երրորդ կողմի ընկերության կողմից:

ISP համակարգի աջակցությունը նորմալ արձագանքեց, բայց շտկումները եկան միայն մի քանի թողարկումներից հետո, և ոչ միշտ և ոչ բոլորը: Երբեմն կրիտիկական սխալները շտկելու համար պահանջվում էր մի քանի շաբաթ: Մենք ստիպված էինք հանգստացնել հաճախորդներին, ներողություն խնդրել և սպասել, որ ISP համակարգը շտկի սխալը:

Դադարեցման սպառնալիք

Թարմացումները կարող են առաջացնել անկանխատեսելի խափանումներ, ինչը նոր սխալներ է առաջացրել:

Յուրաքանչյուր թարմացում վիճակախաղ էր. մենք պետք է ծածկեինք բիլինգը և զոհեր գնայինք թարմացումների աստվածներին. մի քանի անգամ թարմացումը 10-15 րոպեով խափանում էր: Այս պահին մեր ադմինները մոխրագույն էին դառնում մեր աչքի առաջ. մենք երբեք չգիտեինք, թե որքան երկար է տևելու անգործությունը և չէինք կարող կանխատեսել, թե երբ ISP համակարգը կորոշի թողարկել նոր թարմացում:

Billmanager-ը լավացավ հինգերորդ սերնդի վրա, բայց անհրաժեշտ հնարավորություններին հասանելիություն ստանալու համար ես ստիպված էի տեղադրել բետա, որն արդեն թարմացվում էր ամեն շաբաթ: Եթե ​​ինչ-որ բան կոտրվեց, դուք պետք է մուտք գործեք այլ մշակողների, որպեսզի նրանք կարողանան ինչ-որ բան ուղղել:

Վահանակի անհարմար ինտերֆեյս

Ամեն ինչ բաժանված էր տարբեր վահանակների և վերահսկվում տարբեր վայրերից։ Օրինակ, հաճախորդները վճարում էին Billmanager-ի միջոցով, բայց նրանք ստիպված էին վերագործարկել կամ նորից տեղադրել VDS-ը VMManager-ում: Մեր աշխատակիցները նաև ստիպված էին անցնել պատուհանների միջև՝ հաճախորդին օգնելու, նրանց սերվերի բեռնվածությունը ստուգելու կամ տեսնելու, թե ինչ ՕՀ են նրանք օգտագործում:

Նման ինտերֆեյսը ժամանակ է պահանջում՝ և՛ մերը, և՛ մեր հաճախորդներին: Նման իրավիճակում DigitalOcean-ի նման հարմարության մասին խոսք չկա։

Կարճ կյանքի ցիկլեր API-ի հաճախակի թարմացումներով

Մենք գրել ենք մեր սեփական պլագինները, օրինակ՝ հավելյալ վճարման եղանակներով հավելված, որոնք հասանելի չեն VMManager-ում:

Վերջին տարիներին VMManager-ն ուներ համեմատաբար կարճ կյանքի ցիկլ, և նոր տարբերակները կարող էին պատահականորեն փոխել փոփոխականների կամ գործառույթների անունները API-ում, ինչը կոտրեց մեր պլագինները: Ավելի հին տարբերակների աջակցությունն արագորեն դադարեցվեց, և անհրաժեշտ էր թարմացնել:

Հնարավոր չէ փոփոխել

Ավելի ճիշտ՝ հնարավոր է, բայց ծայրահեղ անարդյունավետ։ Լիցենզիայի սահմանափակումները թույլ չեն տալիս փոփոխություններ կատարել սկզբնաղբյուրում, կարող եք գրել միայն պլագիններ: Առավելագույն պլագիններ - ընտրացանկի որոշ տարրեր, քայլ առ քայլ հրաշագործ: ISP համակարգը նախատեսված է բազմակողմանիության համար, սակայն մեզ անհրաժեշտ էին մասնագիտացված լուծումներ:

Այսպիսով, իմ սեփական վահանակը գրելու որոշումը հասունացել էր: Մենք նպատակներ ենք դրել.

• Արագ արձագանքեք սխալներին և սխալներին և կարողանաք ինքնուրույն շտկել դրանք՝ առանց հաճախորդին սպասեցնելու:
• Ազատորեն փոփոխեք ինտերֆեյսը հաճախորդի աշխատանքային գործընթացներին և կարիքներին համապատասխան:
• Բարելավեք օգտագործելիությունը մաքուր և հստակ դիզայնով:

Եվ մենք սկսեցինք զարգացումը:

Նոր վահանակի ճարտարապետությունը

Մենք ունենք ինքնաբավ զարգացման թիմ, ուստի մենք ինքներս ենք գրել վահանակը:
Հիմնական աշխատանքը կատարել են երեք ինժեներներ. տեխնիկական տնօրեն Սերգեյը մտավ ճարտարապետությունը և գրեց սերվերի գործակալին, Ալեքսեյը կատարեց բիլինգը, իսկ ճակատը հավաքեց մեր ֆրոնտենտ Արտիշը:

Քայլ 1. Սերվերի գործակալ

Սերվերի գործակալը Python վեբ սերվեր է, որը կառավարում է գրադարանը գրադարան, որն իր հերթին վերահսկում է hypervisor Qemu-kvm.

Գործակալը կառավարում է սերվերի բոլոր ծառայությունները՝ ստեղծել, դադարեցնել, ջնջել vds, տեղադրել օպերացիոն համակարգեր, փոխել պարամետրերը և այլն libvirt գրադարանի միջոցով: Այս հոդվածի հրապարակման պահին դրանք ավելի քան քառասուն տարբեր գործառույթներ են, որոնք մենք ավելացնում ենք՝ կախված հաճախորդի առաջադրանքից և կարիքներից:

Տեսականորեն, libvirt-ը կարող էր ուղղակիորեն կառավարվել բիլինգից, բայց դա պահանջում էր չափազանց շատ լրացուցիչ կոդ, և մենք որոշեցինք բաժանել այս գործառույթները գործակալի և բիլինգի միջև. billing-ը պարզապես հարցումներ է կատարում գործակալին JSON API-ի միջոցով:

Գործակալը առաջինն էր, ինչ մենք արեցինք, քանի որ այն չէր պահանջում որևէ ինտերֆեյս և կարող էր փորձարկվել անմիջապես սերվերի վահանակից:

Ինչ է մեզ տվել սերվերի գործակալը. Հայտնվել է մի շերտ, որը հեշտացնում է կյանքը բոլորի համար. բիլինգը պետք չէ ուղարկել հրամանների մի ամբողջ փունջ, այլ միայն կատարել հարցում: Իսկ գործակալը կանի այն ամենը, ինչ անհրաժեշտ է՝ օրինակ՝ տեղաբաշխել սկավառակի տարածք և օպերատիվ հիշողություն:

Քայլ 2. Վճարում

Մեր ծրագրավորող Ալեքսի համար սա առաջին կառավարման վահանակը չէր. Ալեքսը երկար ժամանակ հոսթինգ էր անում, ուստի նա ընդհանուր առմամբ հասկանում էր, թե ինչ է պետք հաճախորդին և ինչ է պետք հոսթերին:

Բիլլինգը մենք անվանում ենք «կառավարման վահանակ». այն պարունակում է ոչ միայն փող և ծառայություններ, այլև դրանց կառավարում, հաճախորդների աջակցություն և շատ ավելին:

ISPSystem ծրագրաշարից անցնելու համար անհրաժեշտ էր, որ հաճախորդները ամբողջությամբ պահպանեին նախկին ֆունկցիոնալությունը, փոխանցեին օգտատերերի բոլոր ֆինանսական գործողությունները հին բիլինգից նորին, ինչպես նաև բոլոր ծառայություններն ու կապերը նրանց միջև: Մենք ուսումնասիրեցինք, թե ինչ կա ներկա արտադրանքի մեջ, ապա մրցակիցների լուծումները, հիմնականում DO և Vultr: Մենք դիտարկեցինք թերություններն ու առավելությունները, հավաքեցինք կարծիքներ այն մարդկանցից, ովքեր աշխատում էին ISP համակարգի հին արտադրանքների հետ:

Նոր բիլինգն օգտագործել է երկու ստեկ՝ դասական PHP, MySQL (և ապագայում նախատեսվում է անցնել PostgreSQL-ին), Yii2՝ որպես ֆրեյմուք՝ հետին մասում և VueJS՝ առջևում։ Դույները գործում են միմյանցից անկախ, մշակվում են տարբեր մարդկանց կողմից և հաղորդակցվում են JSON API-ի միջոցով: Զարգացման համար այն ժամանակ և հիմա մենք օգտագործում ենք PHPS փոթորիկ и վեբփոթորիկ JetBrains-ից և շատ սիրեք նրանց (հեյ տղաներ):

Վահանակը նախագծված է մոդուլային հիմունքներով՝ վճարային համակարգի մոդուլներ, տիրույթի գրանցման մոդուլ կամ, օրինակ, SSL վկայագրերի մոդուլ: Դուք կարող եք հեշտությամբ ավելացնել նոր գործառույթ կամ հեռացնել հինը: Ընդլայնման հիմքը դրված է ճարտարապետական ​​առումով, այդ թվում՝ հակառակ ուղղությամբ՝ «դեպի սարքավորում»։

Ինչ ստացանքԿառավարման վահանակ, որի վրա մենք լիովին վերահսկում ենք: Այժմ սխալները շտկվում են ժամերով, ոչ թե շաբաթներով, և նոր գործառույթներն իրականացվում են հաճախորդների խնդրանքով, այլ ոչ թե ISPSystem-ի խնդրանքով:

Քայլ 3. Ինտերֆեյս

Ինտերֆեյսը մեր թիմի մտահղացումն է:

Նախ, մենք նայեցինք, թե ինչ կլիներ, եթե հավելում ստեղծեինք ISPsystem API-ին՝ առանց ինտերֆեյսում որևէ բան հիմնովին փոխելու: Այնպես ստացվեց, և մենք որոշեցինք ամեն ինչ անել զրոյից:

Մենք հավատում էինք, որ գլխավորը ինտերֆեյսը տրամաբանական դարձնելն է՝ մաքուր և մինիմալիստական ​​դիզայնով, այնուհետև կստանանք գեղեցիկ վահանակ։ Էլեմենտների դասավորությունը քննարկվել է Megaplan-ում և աստիճանաբար կծնվի ինտերֆեյսը, որն այժմ տեսնում են օգտատերերը կառավարման վահանակում:

Բիլինգային էջի ձևավորումն առաջինն էր, քանի որ մենք արդեն պատրաստել էինք վճարային հավելումներ ISP համակարգի համար:

Դիմային մաս

Նրանք որոշեցին վահանակը դարձնել SPA հավելված՝ ռեսուրսների առումով ոչ պահանջկոտ և տվյալների արագ բեռնումով: Մեր ֆրոնտենդեր Արտիշը որոշեց գրել այն Vue-ում, այն ժամանակ Vue-ն նոր էր հայտնվել։ Մենք ենթադրում էինք, որ շրջանակը դինամիկ կերպով կզարգանա, ինչպես React-ը, և որոշ ժամանակ անց Vue համայնքը կաճի և կհայտնվի գրադարանների ծով։ Մենք ընտրեցինք Vue-ն և չզղջացինք դրա համար. այժմ նոր գործառույթներ ավելացնելը, որոնք արդեն ծրագրավորված էին հետնամասում, քիչ ժամանակ է պահանջում: Առանձին հոդվածում մենք ձեզ ավելին կպատմենք ճակատային վահանակների մասին:

Կապը ճակատի և հետնամասի միջև

Frontend-ը միացված էր հետին մասի հետ push ծանուցումների միջոցով: Ես ստիպված էի քրտնաջան աշխատել և գրել իմ սեփական մշակողը, բայց այժմ էջի տեղեկատվությունը թարմացվում է գրեթե ակնթարթորեն:

Ինչ է պատահել: Վահանակի ինտերֆեյսը դարձել է ավելի պարզ: Մենք այն դարձրել ենք հարմարվողական, և արագ բեռնումը թույլ է տալիս այն օգտագործել նույնիսկ բջջային հեռախոսներից թռիչքից առաջ վերջին րոպեներին՝ առանց վահանակի հետ աշխատելու առանձին հավելված տեղադրելու։

Քայլ 4. Փորձարկման և միգրացիայի սխեման

Երբ ամեն ինչ սկսվեց և անցան առաջին թեստերը, ծագեց միգրացիայի հարցը։ Առաջին հերթին մենք տեղադրեցինք բիլինգը և սկսեցինք փորձարկել դրա աշխատանքը սերվերի գործակալի հետ:

Այնուհետև մենք գրեցինք մի պարզ սցենար, որը տվյալների բազան տեղափոխում է հին բիլինգային համակարգից նորը:

Մենք ստիպված էինք ստուգել և կրկնակի ստուգել բառացիորեն ամեն ինչ, քանի որ տվյալները միաձուլվել են մեկ նոր տվյալների բազայի մեջ երեք հին տվյալներից՝ Billmanager, VMmanager և IPmanager մենեջեր: Թերևս թեստային միգրացիաներն ամենադժվար բանն են, որին մենք հանդիպեցինք նոր վահանակի մշակման գործընթացում:

Կրկնակի ստուգումներից հետո մենք փակեցինք հին հաշիվը: Վերջնական տվյալների միգրացիան շատ մտահոգիչ պահ էր, բայց, փառք Աստծո, այն ավարտվեց մի քանի րոպեում և առանց նկատելի խնդիրների։ Կային աննշան սխալներ, որոնք մենք շտկեցինք մեկ շաբաթվա ընթացքում: Ժամանակի մեծ մասը ծախսվել է կատարվածի փորձարկման վրա:

Այնուհետև մենք հաճախորդներին նամակներ ուղարկեցինք նոր վահանակի հասցեով և բիլինգով և կատարեցինք վերահղում:

In Summary: ԱՅՆ ՈՂՋ Է!

Երջանիկ ավարտ

Մեր ծրագրաշարի հետ աշխատելու առաջին ժամերից մենք զգացինք անցման բոլոր հրճվանքները: Կոդն ամբողջությամբ մերն էր և ուներ հարմար ճարտարապետություն, իսկ ինտերֆեյսը մաքուր և տրամաբանական էր։

Առաջին ակնարկը նոր վահանակի գործարկումից հետո

Մենք անցումային գործընթացը սկսել ենք դեկտեմբերին՝ 2017 թվականի Ամանորի նախօրեին, երբ կար նվազագույն ծանրաբեռնվածություն, որպեսզի հեշտացնենք անցումը հաճախորդների համար՝ տոների նախօրեին գրեթե ոչ ոք չի աշխատում։

Հիմնական բանը, որ մենք ստացանք մեր համակարգին անցնելիս (բացի ընդհանուր հուսալիությունից և հարմարավետությունից), հիմնական հաճախորդների համար ֆունկցիոնալությունը արագ ավելացնելու հնարավորությունն էր՝ լինել նրանց դեմքը, ոչ թե հետույքը:

Ինչ հաջորդ?

Մենք աճում ենք, աճում է տվյալների, հաճախորդների, հաճախորդների տվյալների քանակը: Հետին պլանում մենք պետք է ավելացնեինք Memcached սերվեր և երկու հերթերի կառավարիչներ՝ տարբեր առաջադրանքներով: Frontend-ն ունի քեշավորում և իր սեփական հերթերը:

Իհարկե, մենք դեռևս ունեցանք արկածներ, քանի որ արտադրանքը զարգացավ և ավելի բարդացավ, օրինակ, երբ ավելացրինք HighLoad-ը:

Հաջորդ հոդվածում մենք ձեզ կպատմենք, թե ինչպես գործարկեցինք Hi-CPU սակագինը. ապարատային, ծրագրային ապահովում, ինչ խնդիրներ լուծեցինք և ինչի հասանք:

Source: www.habr.com