Habang nagtatrabaho ka sa IT, nagsisimula kang mapansin na ang mga system ay may sariling katangian. Maaari silang maging flexible, tahimik, sira-sira, at mahigpit. Maaari silang maakit o maitaboy. Sa isang paraan o iba pa, kailangan mong "makipag-ayos" sa kanila, maniobra sa pagitan ng "mga pitfalls" at bumuo ng mga kadena ng kanilang pakikipag-ugnayan.
Kaya nagkaroon kami ng karangalan na bumuo ng cloud platform, at para dito kailangan naming "hikayatin" ang isang pares ng mga subsystem na magtrabaho sa amin. Sa kabutihang palad, mayroon kaming "wika ng API", direktang mga kamay at maraming sigasig.
Ang artikulong ito ay hindi magiging technically hardcore, ngunit ilalarawan ang mga problemang naranasan namin habang ginagawa ang cloud. Nagpasya akong ilarawan ang aming landas sa anyo ng isang magaan na teknikal na pantasya tungkol sa kung paano namin hinanap ang isang karaniwang wika na may mga system at kung ano ang lumabas mula dito.
Maligayang pagdating sa pusa.
Simula ng isang paglalakbay
Ilang oras na ang nakalipas, ang aming koponan ay naatasang maglunsad ng cloud platform para sa aming mga kliyente. Nagkaroon kami ng suporta sa pamamahala, mapagkukunan, hardware stack at kalayaan sa pagpili ng mga teknolohiya para ipatupad ang software na bahagi ng serbisyo.
Mayroon ding ilang mga kinakailangan:
- ang serbisyo ay nangangailangan ng isang maginhawang personal na account;
- ang platform ay dapat na isinama sa umiiral na sistema ng pagsingil;
- software at hardware: OpenStack + Tungsten Fabric (Open Contrail), na natutunan ng aming mga inhinyero na "magluto" nang maayos.
Sasabihin namin sa iyo sa ibang pagkakataon ang tungkol sa kung paano binuo ang koponan, binuo ang interface ng personal na account at ginawa ang mga desisyon sa disenyo, kung interesado ang komunidad ng Habra.
Ang mga tool na napagpasyahan naming gamitin:
- Python + Flask + Swagger + SQLAlchemy - isang ganap na karaniwang set ng Python;
- Vue.js para sa frontend;
- Nagpasya kaming gawin ang pakikipag-ugnayan sa pagitan ng mga bahagi at serbisyo gamit ang Celery sa AMQP.
Inaasahan ang mga tanong tungkol sa pagpili ng Python, ipapaliwanag ko. Ang wika ay natagpuan ang angkop na lugar nito sa aming kumpanya at isang maliit, ngunit pa rin ang kultura, ay nabuo sa paligid nito. Samakatuwid, napagpasyahan na simulan ang pagbuo ng serbisyo dito. Bukod dito, ang bilis ng pag-unlad sa gayong mga problema ay madalas na mapagpasyahan.
Kaya, simulan na natin ang ating pagkakakilala.
Silent Bill - pagsingil
Matagal na naming kilala ang lalaking ito. Palagi siyang nakaupo sa tabi ko at tahimik na nagbibilang ng kung ano. Minsan ipinapasa niya ang mga kahilingan ng user sa amin, nagbigay ng mga invoice ng kliyente, at pinamamahalaang mga serbisyo. Isang ordinaryong masipag na tao. Totoo, may mga kahirapan. Siya ay tahimik, kung minsan ay nag-iisip at madalas sa kanyang sariling isip.
Ang pagsingil ay ang unang sistema na sinubukan naming makipagkaibigan. At ang unang hirap na naranasan namin ay kapag nagpoproseso ng mga serbisyo.
Halimbawa, kapag ginawa o tinanggal, ang isang gawain ay mapupunta sa panloob na pila ng pagsingil. Kaya, ang isang sistema ng asynchronous na trabaho sa mga serbisyo ay ipinatupad. Upang maproseso ang aming mga uri ng serbisyo, kailangan naming "ilagay" ang aming mga gawain sa pila na ito. At narito kami ay nagkaroon ng problema: kakulangan ng dokumentasyon.
Sa paghusga sa pamamagitan ng paglalarawan ng software API, posible pa ring malutas ang problemang ito, ngunit wala kaming oras upang gawin ang reverse engineering, kaya kinuha namin ang lohika sa labas at inayos ang isang pila ng gawain sa tuktok ng RabbitMQ. Ang isang operasyon sa isang serbisyo ay pinasimulan ng kliyente mula sa kanyang personal na account, nagiging isang "gawain" ng Celery sa backend at ginagawa sa panig ng pagsingil at OpenStack. Ginagawang medyo maginhawa ang kintsay upang pamahalaan ang mga gawain, ayusin ang mga pag-uulit at subaybayan ang katayuan. Maaari kang magbasa nang higit pa tungkol sa "celery", halimbawa, .
Gayundin, hindi napigilan ng pagsingil ang isang proyektong naubusan ng pera. Sa pakikipag-usap sa mga developer, nalaman namin na kapag kinakalkula ang mga istatistika (at kailangan naming ipatupad nang eksakto ang ganitong uri ng lohika), mayroong isang kumplikadong pagkakaugnay ng mga panuntunan sa pagtigil. Ngunit ang mga modelong ito ay hindi angkop sa ating mga katotohanan. Ipinatupad din namin ito sa pamamagitan ng mga gawain sa Celery, na dinadala ang lohika ng pamamahala ng serbisyo sa backend side.
Ang parehong mga problema sa itaas ay humantong sa ang code ay naging medyo namamaga at sa hinaharap ay kailangan nating refactor upang ilipat ang lohika para sa pagtatrabaho sa mga gawain sa isang hiwalay na serbisyo. Kailangan din naming mag-imbak ng ilang impormasyon tungkol sa mga user at kanilang mga serbisyo sa aming mga talahanayan upang suportahan ang lohika na ito.
Ang isa pang problema ay ang katahimikan.
Tahimik na sinasagot ni Billy ang "Ok" sa ilang kahilingan sa API. Ganito ang kaso, halimbawa, noong nagbayad kami ng mga ipinangakong pagbabayad sa panahon ng pagsubok (higit pa tungkol doon sa ibang pagkakataon). Ang mga kahilingan ay naisakatuparan nang tama at wala kaming nakitang anumang mga error.
Kinailangan kong pag-aralan ang mga log habang nagtatrabaho sa system sa pamamagitan ng UI. Lumalabas na ang pagsingil mismo ay nagsasagawa ng mga katulad na kahilingan, binabago ang saklaw sa isang partikular na user, halimbawa, admin, na ipinapasa ito sa su parameter.
Sa pangkalahatan, sa kabila ng mga gaps sa dokumentasyon at mga menor de edad na flaws ng API, naging maayos ang lahat. Maaaring basahin ang mga log kahit na sa ilalim ng mabigat na pagkarga kung nauunawaan mo kung paano nakaayos ang mga ito at kung ano ang hahanapin. Ang istraktura ng database ay gayak, ngunit medyo lohikal at sa ilang mga paraan kahit na kaakit-akit.
Kaya, bilang buod, ang mga pangunahing problema na nakatagpo namin sa yugto ng pakikipag-ugnayan ay nauugnay sa mga tampok ng pagpapatupad ng isang partikular na system:
- hindi dokumentadong "mga tampok" na nakaapekto sa amin sa isang paraan o iba pa;
- closed source (nakasulat ang pagsingil sa C++), bilang isang resulta - imposibleng malutas ang problema 1 sa anumang paraan maliban sa "pagsubok at error".
Sa kabutihang palad, ang produkto ay may medyo malawak na API at isinama namin ang mga sumusunod na subsystem sa aming personal na account:
- module ng teknikal na suporta - ang mga kahilingan mula sa iyong personal na account ay "proxied" sa malinaw na pagsingil para sa mga kliyente ng serbisyo;
- financial module - nagbibigay-daan sa iyo na mag-isyu ng mga invoice sa kasalukuyang mga kliyente, gumawa ng mga write-off at bumuo ng mga dokumento sa pagbabayad;
- service control module - para dito kailangan naming ipatupad ang aming sariling handler. Ang pagpapalawak ng system ay naglaro sa aming mga kamay at "itinuro" namin kay Billy ang isang bagong uri ng serbisyo.
Medyo hassle, pero one way or another, I think magkakasundo kami ni Billy.
Naglalakad sa mga tungsten field β Tungsten Fabric
Tungsten field na may tuldok-tuldok na daan-daang mga wire, na nagpapasa ng libu-libong piraso ng impormasyon sa kanila. Ang impormasyon ay kinokolekta sa "packet", na-parse, bumubuo ng mga kumplikadong ruta, na parang sa pamamagitan ng magic.
Ito ang domain ng pangalawang sistema kung saan kailangan naming makipagkaibigan - Tungsten Fabric (TF), dating OpenContrail. Ang gawain nito ay upang pamahalaan ang mga kagamitan sa network, na nagbibigay ng abstraction ng software sa amin bilang mga gumagamit. TF - SDN, encapsulates ang kumplikadong lohika ng pagtatrabaho sa network equipment. Mayroong isang magandang artikulo tungkol sa teknolohiya mismo, halimbawa, .
Ang system ay isinama sa OpenStack (tinalakay sa ibaba) sa pamamagitan ng Neutron plugin.
Pakikipag-ugnayan ng mga serbisyo ng OpenStack.
Ipinakilala kami ng mga lalaki mula sa departamento ng pagpapatakbo sa sistemang ito. Ginagamit namin ang API ng system upang pamahalaan ang network stack ng aming mga serbisyo. Hindi pa ito nagdulot sa amin ng anumang seryosong problema o abala (hindi ako makapagsalita para sa mga lalaki mula sa OE), ngunit may ilang mga kakaiba sa pakikipag-ugnayan.
Ang una ay ganito ang hitsura: mga utos na nangangailangan ng pag-output ng isang malaking halaga ng data sa instance console kapag kumokonekta sa pamamagitan ng SSH ay "binaba" lang ang koneksyon, habang sa pamamagitan ng VNC lahat ay gumana nang tama.
Para sa mga hindi pamilyar sa problema, mukhang nakakatawa ito: gumagana nang tama ang ls /root, habang, halimbawa, ganap na "nag-freeze" ang tuktok. Sa kabutihang palad, nakatagpo kami ng mga katulad na problema dati. Napagpasyahan ito sa pamamagitan ng pag-tune ng MTU sa ruta mula sa mga compute node hanggang sa mga router. By the way, hindi ito problema sa TF.
Ang susunod na problema ay malapit na. Sa isang "maganda" na sandali, ang mahika ng pagruruta ay nawala, ganoon na lang. Huminto ang TF sa pamamahala ng pagruruta sa kagamitan.
Nakipagtulungan kami sa Openstack mula sa antas ng admin at pagkatapos noon ay lumipat sa kinakailangang antas ng user. Lumilitaw na "hijack" ng SDN ang saklaw ng user kung saan isinasagawa ang mga aksyon. Ang katotohanan ay ang parehong admin account ay ginagamit upang ikonekta ang TF at OpenStack. Sa hakbang ng paglipat sa gumagamit, nawala ang "magic". Napagpasyahan na lumikha ng isang hiwalay na account upang gumana sa system. Nagbigay-daan ito sa amin na magtrabaho nang hindi sinisira ang functionality ng integration.
Silicon Lifeforms - OpenStack
Isang kakaibang hugis silicone na nilalang ang nakatira malapit sa mga tungsten field. Higit sa lahat, para itong batang sobra-sobra na kaya kaming durugin sa isang indayog, ngunit walang halatang aggression na nanggagaling sa kanya. Hindi ito nagdudulot ng takot, ngunit ang laki nito ay nagbibigay inspirasyon sa takot. Pati ang pagiging kumplikado ng mga nangyayari sa paligid.
Ang OpenStack ay ang core ng aming platform.
Ang OpenStack ay may ilang mga subsystem, kung saan kasalukuyang ginagamit namin ang Nova, Glance at Cinder na pinakaaktibo. Ang bawat isa sa kanila ay may sariling API. Ang Nova ay responsable para sa mga mapagkukunan ng pag-compute at ang paglikha ng mga pagkakataon, si Cinder ay responsable para sa pamamahala ng mga volume at ang kanilang mga snapshot, ang Glance ay isang serbisyo ng imahe na namamahala sa mga template ng OS at metainformation sa mga ito.
Ang bawat serbisyo ay tumatakbo sa isang lalagyan, at ang broker ng mensahe ay ang "puting kuneho" - RabbitMQ.
Ang sistemang ito ay nagbigay sa amin ng pinaka hindi inaasahang problema.
At hindi nagtagal dumating ang unang problema nang sinubukan naming ikonekta ang karagdagang dami sa server. Ang Cinder API ay tahasang tumanggi na gawin ang gawaing ito. Mas tiyak, kung naniniwala ka mismo sa OpenStack, ang koneksyon ay itinatag, ngunit walang disk device sa loob ng virtual server.
Nagpasya kaming lumihis at humiling ng parehong aksyon mula sa Nova API. Ang resulta ay ang aparato ay kumokonekta nang tama at naa-access sa loob ng server. Lumilitaw na ang problema ay nangyayari kapag ang block-storage ay hindi tumugon sa Cinder.
Isa pang kahirapan ang naghihintay sa amin kapag nagtatrabaho sa mga disk. Ang dami ng system ay hindi ma-disconnect mula sa server.
Muli, ang OpenStack mismo ay "sumusumpa" na sinira nito ang koneksyon at ngayon ay maaari mong maayos na magtrabaho nang hiwalay sa volume. Ngunit ang API ay tiyak na hindi nais na magsagawa ng mga operasyon sa disk.
Dito namin napagpasyahan na huwag lumaban lalo na, ngunit baguhin ang aming pananaw sa lohika ng serbisyo. Kung mayroong isang halimbawa, dapat ding mayroong dami ng system. Samakatuwid, hindi pa maalis o hindi paganahin ng user ang "disk" ng system nang hindi tinatanggal ang "server".
Ang OpenStack ay isang medyo kumplikadong hanay ng mga system na may sarili nitong logic sa pakikipag-ugnayan at ornate na API. Tinutulungan tayo ng medyo detalyadong dokumentasyon at, siyempre, trial and error (saan tayo kung wala ito).
Test run
Nagsagawa kami ng test launch noong Disyembre noong nakaraang taon. Ang pangunahing gawain ay upang subukan ang aming proyekto sa combat mode mula sa teknikal na bahagi at mula sa UX side. Ang madla ay piling iniimbitahan at ang pagsubok ay isinara. Gayunpaman, iniwan din namin ang opsyon na humiling ng access sa pagsubok sa aming website.
Ang pagsubok mismo, siyempre, ay hindi walang mga nakakatawang sandali, dahil dito pa lang nagsisimula ang ating mga pakikipagsapalaran.
Una, medyo hindi namin nasuri ang interes sa proyekto at kinailangan naming mabilis na magdagdag ng mga compute node sa panahon ng pagsubok. Isang karaniwang kaso para sa isang kumpol, ngunit may ilang mga nuances din dito. Ang dokumentasyon para sa isang partikular na bersyon ng TF ay nagpapahiwatig ng partikular na bersyon ng kernel kung saan nasubok ang trabaho sa vRouter. Nagpasya kaming maglunsad ng mga node na may mas kamakailang mga kernel. Bilang resulta, hindi nakatanggap ang TF ng mga ruta mula sa mga node. Kinailangan kong mapilit na ibalik ang mga butil.
Ang isa pang pag-usisa ay nauugnay sa pag-andar ng pindutan ng "palitan ang password" sa iyong personal na account.
Nagpasya kaming gamitin ang JWT para ayusin ang access sa aming personal na account para hindi gumana sa mga session. Dahil ang mga system ay magkakaiba at malawak na nakakalat, pinamamahalaan namin ang aming sariling token, kung saan kami ay "nagbabalot" ng mga session mula sa pagsingil at isang token mula sa OpenStack. Kapag binago ang password, ang token, siyempre, ay "mawawala", dahil ang data ng user ay hindi na wasto at kailangan itong muling ibigay.
Nakalimutan namin ang puntong ito, at walang sapat na mapagkukunan para mabilis na tapusin ang bahaging ito. Kinailangan naming putulin ang pag-andar bago ilunsad ang pagsubok.
Kasalukuyan kaming nag-logout sa user kung nabago ang password.
Sa kabila ng mga nuances na ito, naging maayos ang pagsubok. Sa loob ng ilang linggo, humigit-kumulang 300 tao ang dumaan. Nagawa naming tingnan ang produkto sa pamamagitan ng mga mata ng mga user, subukan ito sa pagkilos at mangolekta ng mataas na kalidad na feedback.
Itutuloy
Para sa marami sa atin, ito ang unang proyekto ng sukat na ito. Natutunan namin ang ilang mahahalagang aral tungkol sa kung paano magtrabaho bilang isang koponan at gumawa ng mga desisyon sa arkitektura at disenyo. Paano isama ang mga kumplikadong system na may kaunting mapagkukunan at i-roll ang mga ito sa produksyon.
Siyempre, mayroong isang bagay upang gumana sa parehong sa mga tuntunin ng code at sa mga interface ng system integration. Ang proyekto ay medyo bata pa, ngunit kami ay puno ng mga ambisyon na palaguin ito sa isang maaasahan at maginhawang serbisyo.
Nagawa na naming akitin ang mga sistema. Masunuring pinangangasiwaan ni Bill ang pagbibilang, pagsingil, at mga kahilingan ng user sa kanyang aparador. Ang "magic" ng mga tungsten field ay nagbibigay sa amin ng matatag na komunikasyon. At ang OpenStack lang kung minsan ay nagiging pabagu-bago, sumisigaw ng tulad ng "'Hindi pa inihahanda ng WSREP ang node para sa paggamit ng application." Ngunit iyon ay isang ganap na naiibang kuwento ...
Inilunsad namin kamakailan ang serbisyo.
Maaari mong malaman ang lahat ng mga detalye sa aming .
CLO Development Team
Kapaki-pakinabang na mga link
OpenStack
Tela ng Tungsten
Pinagmulan: www.habr.com