🥇 د کلاوډ خدمت رامینځته کولو تاریخ ، د سایبر پنک سره خوندور

لکه څنګه چې تاسو په IT کې کار کوئ، تاسو په یاد ولرئ چې سیسټمونه خپل ځانګړتیا لري. دوی کولی شي انعطاف وړ، خاموش، سنکی، او سخت وي. دوی کولی شي جذب یا بیرته راوباسي. په یوه یا بله لاره کې، تاسو باید د دوی سره "مذاکرات" وکړئ، د "ننګونو" تر مینځ چل او د دوی د متقابل عمل سلسله جوړه کړئ.

نو موږ د کلاوډ پلیټ فارم جوړولو ویاړ درلود ، او د دې لپاره موږ اړتیا لرو چې زموږ سره کار کولو لپاره یو څو فرعي سیسټمونه "قانع کړو". خوشبختانه، موږ د "API ژبه" لرو، مستقیم لاسونه او ډیر لیوالتیا لرو.

دا مقاله به تخنیکي پلوه سخته نه وي، مګر هغه ستونزې به بیان کړي چې موږ د کلاوډ جوړولو پرمهال ورسره مخ شوي یو. ما پریکړه وکړه چې زموږ لاره د روښانه تخنیکي تصور په بڼه تشریح کړم چې څنګه موږ د سیسټمونو سره د یوې ګډې ژبې په لټه کې یو او له هغې څخه څه راوتلي.

بلی ته ښه راغلاست.

د سفر پیل

یو څه وخت دمخه ، زموږ ټیم ته دنده ورکړل شوې وه چې زموږ د پیرودونکو لپاره د کلاوډ پلیټ فارم په لاره واچوي. موږ د خدماتو سافټویر برخې پلي کولو لپاره د ټیکنالوژیو غوره کولو کې مدیریت ملاتړ ، سرچینې ، هارډویر سټیک او آزادي درلوده.

یو شمیر اړتیاوې هم شتون درلود:

خدمت یو مناسب شخصي حساب ته اړتیا لري؛
پلیټ فارم باید په موجوده بلینګ سیسټم کې مدغم شي؛
سافټویر او هارډویر: OpenStack + Tungsten Fabric (Open Contrail)، کوم چې زموږ انجنیرانو په ښه توګه "پخولو" زده کړي.

موږ به تاسو ته بل وخت ووایو چې ټیم څنګه راټول شوی و، د شخصي حساب انٹرفیس رامینځته شوی و او ډیزاین پریکړې شوې وې، که د هابرا ټولنه علاقه ولري.
هغه وسایل چې موږ یې د کارولو پریکړه وکړه:

Python + Flask + Swagger + SQLAlchemy - یو بشپړ معیاري پایتون سیټ؛
Vue.js for frontend;
موږ پریکړه وکړه چې د اجزاو او خدماتو ترمینځ تعامل د AMQP په اړه د سیلری په کارولو سره ترسره کړو.

د Python غوره کولو په اړه د پوښتنو اټکل کول، زه به تشریح کړم. ژبې زموږ په شرکت کې خپل ځای موندلی او یو کوچنی، مګر لاهم کلتور د هغې شاوخوا وده کړې. له همدې امله، پریکړه وشوه چې په دې باندې د خدماتو جوړول پیل کړي. سربیره پردې، په داسې ستونزو کې د پرمختګ سرعت اکثرا پریکړه کونکی وي.

نو، راځئ چې خپل پیژندنه پیل کړو.

خاموش بل - بل کول

موږ دا سړی د اوږدې مودې لپاره پیژنو. هغه تل زما څنګ ته ناست و او په خاموشۍ سره یو څه شمیرل. ځینې وختونه هغه موږ ته د کاروونکي غوښتنې لیږلي، د پیرودونکي رسیدونه یې صادر کړي، او اداره شوي خدمات. یو عادي سخت کار سړی. ریښتیا، ستونزې شتون درلود. هغه خاموش دی، کله ناکله فکر کوي او ډیری وختونه په خپل ذهن کې.

بلینګ لومړی سیسټم دی چې موږ یې هڅه کوله ملګري پیدا کړو. او لومړی مشکل چې موږ ورسره مخ شو د خدماتو پروسس کولو پرمهال.

د مثال په توګه، کله چې جوړ یا حذف شي، یو کار د داخلي بلینګ کتار ته ځي. پدې توګه ، د خدماتو سره د غیر متمرکز کار سیسټم پلي کیږي. زموږ د خدماتو ډولونو پروسس کولو لپاره، موږ اړتیا لرو چې خپلې دندې په دې کتار کې واچوو. او دلته موږ له یوې ستونزې سره مخ شو: د اسنادو نشتوالی.

د سافټویر API توضیحاتو قضاوت کول ، دا لاهم امکان لري چې دا ستونزه حل کړئ ، مګر موږ د ریورس انجینرۍ کولو لپاره وخت نه درلود ، نو موږ منطق بهر واخیست او د RabbitMQ په سر کې یې د کاري کتار تنظیم کړ. په یوه خدمت کې عملیات د پیرودونکي لخوا د هغه شخصي حساب څخه پیل کیږي ، په شاتنۍ برخه کې د سیلري "ټاسک" بدلیږي او د بلینګ او اوپن سټیک اړخ کې ترسره کیږي. سیلري د دندو اداره کولو ، تکرار تنظیم کولو او وضعیت نظارت کولو لپاره خورا اسانه کوي. تاسو کولی شئ د "اجیر" په اړه نور ولولئ، د بیلګې په توګه، دلته.

همچنان، بلینګ د یوې پروژې مخه ونه نیوله چې پیسې یې ختمې شوې. د پراختیا کونکو سره په اړیکه کې ، موږ وموندله چې کله د احصایې محاسبه کول (او موږ اړتیا لرو په سمه توګه دا ډول منطق پلي کړو) ، د ودریدو قواعدو پیچلې اړیکه شتون لري. مګر دا ماډلونه زموږ د واقعیتونو سره سم ندي. موږ دا په سیلري کې د دندو له لارې هم پلي کړې ، د خدماتو مدیریت منطق شاته اړخ ته راوړو.

پورتنۍ دواړه ستونزې د دې لامل شوي چې کوډ یو څه غوړ شوی وي او په راتلونکي کې به موږ د دندو سره د کار کولو لپاره منطق په جلا خدمت کې حرکت کولو لپاره ریفاکتور وکړو. موږ اړتیا لرو چې د دې منطق ملاتړ کولو لپاره زموږ په میزونو کې د کاروونکو او د دوی خدماتو په اړه ځینې معلومات ذخیره کړو.

بله ستونزه خاموشي ده.

بلی په خاموشۍ سره د API ځینې غوښتنو ته "ښه" ځواب ورکوي. دا قضیه وه، د بیلګې په توګه، کله چې موږ د ازموینې په جریان کې د ژمنې تادیاتو تادیه کړې (په دې اړه نور وروسته). غوښتنې په سمه توګه اجرا شوي او موږ هیڅ غلطی ونه لید.

زه باید د UI له لارې د سیسټم سره کار کولو پرمهال لاګ مطالعه کړم. دا معلومه شوه چې بلینګ پخپله ورته غوښتنې ترسره کوي، یو ځانګړي کاروونکي ته د ساحې بدلول، د بیلګې په توګه، مدیر، دا په su پیرامیټر کې تیریږي.

په عموم کې، په اسنادو کې د تشو او کوچني API نیمګړتیاوو سره سره، هرڅه خورا ښه پرمخ تللي. لاګز حتی د دروند بار لاندې لوستل کیدی شي که تاسو پوهیږئ چې دوی څنګه جوړښت شوي او د څه لپاره باید وګوري. د ډیټابیس جوړښت آرائشی دی، مګر خورا منطقي او په ځینو لارو کې حتی زړه راښکونکی دی.

نو، د لنډیز لپاره، اصلي ستونزې چې موږ د متقابل عمل په مرحله کې ورسره مخ شوي یو د ځانګړي سیسټم پلي کولو ځانګړتیاوو پورې اړه لري:

غیر مستند شوي "ځانګړتیاوې" چې موږ یې په یو یا بل ډول اغیزمن کړي؛
تړل شوې سرچینه (بلینګ په C++ کې لیکل شوی)، د پایلې په توګه - د "محاکمې او تېروتنې" پرته په بل ډول د 1 ستونزې حل کول ناممکن دي.

خوشبختانه، محصول خورا پراخه API لري او موږ لاندې فرعي سیسټمونه زموږ په شخصي حساب کې مدغم کړي دي:

د تخنیکي ملاتړ ماډل - ستاسو د شخصي حساب څخه غوښتنې د خدماتو پیرودونکو لپاره په شفاف ډول د بل کولو لپاره "پراکسي" دي؛
مالي ماډل - تاسو ته اجازه درکوي اوسني پیرودونکو ته رسیدونه صادر کړئ، د لیکلو بندونه وکړئ او د تادیاتو اسناد تولید کړئ؛
د خدماتو کنټرول ماډل - د دې لپاره موږ باید خپل ځان سمبالونکی پلي کړو. د سیسټم پراخوالی زموږ په لاسونو کې لوبیدلی او موږ بلی ته د نوي ډول خدمت "درس ورکړ".
دا یو څه ستونزه وه، مګر یوه لاره یا بله، زه فکر کوم چې بیلی او زه به یوځای شو.

د ټنګسټن ساحو له لارې تګ - ټنګسټن فابریک

د ټنګسټن ساحې په سلګونو تارونو سره تړل شوي، د دوی له لارې په زرګونو معلومات تیریږي. معلومات په "پاکټو" کې راټول شوي، تحلیل شوي، پیچلې لارې جوړوي، لکه څنګه چې د جادو په واسطه.

دا د دویم سیسټم ډومین دی چې ورسره موږ باید ملګري جوړ کړو - ټنګسټن فیبریک (TF)، پخوانی OpenContrail. د دې دنده د شبکې تجهیزاتو اداره کول دي ، د کاروونکو په توګه موږ ته د سافټویر خلاصون چمتو کول. TF - SDN، د شبکې تجهیزاتو سره د کار کولو پیچلي منطق پوښي. پخپله د ټیکنالوژۍ په اړه یو ښه مقاله شتون لري، د بیلګې په توګه، دلته.

سیسټم د نیوټرون پلگ ان له لارې د OpenStack (لاندې بحث شوی) سره مدغم شوی.

د OpenStack خدماتو تعامل.

د عملیاتي څانګې هلکانو موږ دې سیسټم ته معرفي کړل. موږ د خپلو خدماتو د شبکې سټیک اداره کولو لپاره د سیسټم API کاروو. دا موږ ته تراوسه کومه جدي ستونزې یا ناخوالې ندي رامینځته کړي (زه نشم کولی د OE هلکانو لپاره خبرې وکړم) ، مګر په متقابل عمل کې ځینې توپیرونه شتون لري.

لومړی داسې ښکاریده: هغه قوماندې چې اړتیا لري د مثال کنسول ته د ډیټا لوی مقدار تولید کړي کله چې د SSH له لارې وصل کیږي په ساده ډول پیوستون "ځړول" ، پداسې حال کې چې د VNC له لارې هرڅه سم کار کوي.

د هغو کسانو لپاره چې له ستونزې سره بلد نه دي، دا خورا مسخره ښکاري: ls /root په سمه توګه کار کوي، پداسې حال کې چې د مثال په توګه، په بشپړه توګه پورته "یخیږي". خوشبختانه، موږ مخکې له ورته ستونزو سره مخ شوي یو. دا د کمپیوټر نوډونو څخه راوټرونو ته په لاره کې د MTU د ټون کولو سره پریکړه شوې وه. په هرصورت، دا د TF ستونزه نده.

بله ستونزه یوازې د کونج شاوخوا وه. په یوه "ښکلي" شیبه کې، د لارې جادو ورک شو، لکه څنګه چې. TF په تجهیزاتو کې د روټینګ اداره کول بند کړي.

موږ د اډمین کچې څخه د Openstack سره کار وکړ او له هغې وروسته اړین کارونکي کچې ته لاړ. SDN داسې ښکاري چې د هغه کارونکي ساحه "هیجیک" کوي چې د چا لخوا عملونه ترسره کیږي. حقیقت دا دی چې ورته اډمین حساب د TF او OpenStack سره وصل کولو لپاره کارول کیږي. د کارونکي ته د بدلولو په مرحله کې، "جادو" ورک شو. پریکړه وشوه چې د سیسټم سره کار کولو لپاره جلا حساب جوړ کړئ. دې موږ ته اجازه راکړه چې د ادغام فعالیت ماتولو پرته کار وکړو.

د سیلیکون لایففارمونه - OpenStack

یو عجیب شکل سیلیکون مخلوق د ټنګسټن کروندو ته نږدې ژوند کوي. تر ټولو ډیر، دا د یو لوی شوي ماشوم په څیر ښکاري چې کولی شي موږ په یو ځړول کې راوباسي، مګر د هغه څخه هیڅ ښکاره تیري شتون نلري. دا د ویرې لامل نه کیږي، مګر د هغې اندازه ویره هڅوي. لکه څنګه چې شاوخوا څه پیښیږي پیچلتیا.

OpenStack زموږ د پلیټ فارم اصلي دی.

OpenStack ډیری فرعي سیسټمونه لري، چې موږ یې اوس مهال په خورا فعال ډول نووا، ګالنس او سنډر کاروو. هر یو یې خپل API لري. نووا د سرچینو محاسبه کولو او د مثالونو رامینځته کولو مسؤل دی ، سنډر د حجمونو او د دوی سنیپ شاټونو اداره کولو مسؤل دی ، ګالنس د عکس خدمت دی چې د OS ټیمپلیټونه او په دوی باندې میټین معلومات اداره کوي.

هر خدمت په کانټینر کې پرمخ ځي، او د پیغام بروکر "سپینه خرگوش" دی - RabbitMQ.

دا سیسټم موږ ته خورا غیر متوقع مصیبت راکړ.

او لومړۍ ستونزه په راتلو کې اوږده نه وه کله چې موږ هڅه وکړه چې سرور ته اضافي حجم وصل کړو. Cinder API په کلکه د دې دندې ترسره کولو څخه انکار وکړ. په دقیقه توګه، که تاسو پخپله OpenStack باور لرئ، پیوستون تاسیس شوی، مګر په مجازی سرور کې د ډیسک وسیله شتون نلري.

موږ پریکړه وکړه چې یو چکر واخلو او د نووا API څخه د ورته عمل غوښتنه وکړو. پایله دا ده چې وسیله په سمه توګه وصل کیږي او په سرور کې د لاسرسي وړ دی. داسې ښکاري چې ستونزه هغه وخت رامینځته کیږي کله چې د بلاک ذخیره Cinder ته ځواب نه ورکوي.

بله ستونزه موږ ته انتظار وه کله چې د ډیسکونو سره کار وکړو. د سیسټم حجم نشي کولی له سرور څخه منحل شي.

یوځل بیا ، OpenStack پخپله "قسم" کوي چې دا اړیکه یې ویجاړه کړې او اوس تاسو کولی شئ په جلا توګه د حجم سره په سمه توګه کار وکړئ. مګر API په کلکه نه غوښتل چې په ډیسک کې عملیات ترسره کړي.

دلته موږ پریکړه وکړه چې په ځانګړې توګه جګړه ونه کړو، مګر د خدمت د منطق په اړه زموږ نظر بدل کړو. که چیرې یو مثال شتون ولري، باید د سیسټم حجم هم وي. له همدې امله ، کارونکي لاهم نشي کولی د "سرور" حذف کولو پرته سیسټم "ډیسک" لرې یا غیر فعال کړي.

OpenStack د خپل متقابل منطق او زینت API سره د سیسټمونو خورا پیچلي سیټ دی. موږ سره د کافي تفصيلي اسنادو او البته د محاکمې او تېروتنې له لارې مرسته کیږي (موږ به له دې پرته چیرته یو).

ټیسټ چلول

موږ د تیر کال په ډسمبر کې د ازموینې پیل ترسره کړ. اصلي دنده دا وه چې زموږ پروژه په جنګي حالت کې له تخنیکي اړخ او د UX اړخ څخه وازموئ. لیدونکي په انتخابي ډول رابلل شوي او ازموینه بنده شوې وه. په هرصورت، موږ دا اختیار هم پریښود چې زموږ په ویب پاڼه کې ازموینې ته د لاسرسي غوښتنه وکړو.

پخپله ازموینه، البته، د هغې په زړه پورې شیبو پرته نه وه، ځکه چې دا هغه ځای دی چې زموږ سفر یوازې پیل کیږي.

لومړی، موږ په پروژه کې دلچسپي یو څه ناسمه ارزولې او باید د ازموینې په جریان کې سمدستي د کمپیوټر نوډونه اضافه کړو. د کلستر لپاره یو عام قضیه، مګر دلته یو څه باریکونه هم وو. د TF د یوې ځانګړې نسخې لپاره اسناد د کرنل ځانګړي نسخه په ګوته کوي چې په کوم کې د vRouter سره کار ازمول شوی و. موږ پریکړه وکړه چې د نورو وروستي کرنلونو سره نوډونه پیل کړو. د پایلې په توګه، TF د نوډونو څخه لارې نه ترلاسه کړې. زه باید ژر تر ژره دانه بیرته راوګرځوم.

بل تجسس ستاسو په شخصي حساب کې د "بدلون پټنوم" تڼۍ فعالیت پورې اړه لري.

موږ پریکړه وکړه چې زموږ شخصي حساب ته د لاسرسي تنظیم کولو لپاره JWT وکاروو ترڅو د غونډو سره کار ونه کړو. څرنګه چې سیسټمونه متفاوت او په پراخه کچه ویشل شوي، موږ خپل خپل نښه اداره کوو، په کوم کې چې موږ د بلینګ څخه ناستې "لغولو" او د OpenStack څخه نښه. کله چې پاسورډ بدل شي، نو نښه، البته، "خراب کیږي"، ځکه چې د کاروونکي ډاټا نور اعتبار نلري او دا باید بیا خپور شي.

موږ د دې ټکي نظر له لاسه ورکړ، او په ساده ډول دومره سرچینې نه وې چې دا ټوټه ژر تر ژره پای ته ورسوي. موږ باید د ازموینې پیل کولو دمخه فعالیت قطع کړو.
اوس مهال موږ کاروونکي لاګ آوټ کوو که چیرې پټنوم بدل شوی وي.

د دې باریکیو سره سره، ازموینه ښه پرمخ تللې. په څو اونیو کې شاوخوا 300 خلک ودریدل. موږ وکولی شو د کاروونکو د سترګو له لارې محصول وګورو، په عمل کې یې ازموینه وکړو او د لوړ کیفیت فیډبیک راټول کړو.

دوام ته دوام ورکول

زموږ د ډیری لپاره، دا د دې پیمانه لومړۍ پروژه ده. موږ د ټیم په توګه د کار کولو او د معمارۍ او ډیزاین پریکړې کولو څرنګوالي په اړه یو شمیر ارزښتناک درسونه زده کړل. څنګه پیچلي سیسټمونه د لږو سرچینو سره یوځای کړئ او په تولید کې یې رول کړئ.

البته، د کوډ شرایطو او د سیسټم ادغام انٹرفیسونو کې د کار کولو لپاره یو څه شتون لري. پروژه خورا ځوانه ده، مګر موږ د دې لپاره د باور وړ او مناسب خدمت ته وده ورکولو لپاره د هیلو څخه ډک یو.

موږ لا دمخه توانیدلي یو چې سیسټمونه قانع کړو. بل په دقت سره په خپل المارۍ کې د شمیرنې ، بل کولو ، او کارونکي غوښتنې اداره کوي. د ټنګسټن ساحو "جادو" موږ ته باثباته ارتباط چمتو کوي. او یوازې OpenStack ځینې وختونه زړه راښکونکي کیږي، یو څه چیغې کوي لکه "'WSREP تراوسه د غوښتنلیک کارولو لپاره نوډ نه دی چمتو کړی." مګر دا یو بشپړ مختلف کیسه ده ...

موږ پدې وروستیو کې خدمت پیل کړ.
تاسو کولی شئ زموږ ټول توضیحات ومومئ سایټ.

د CLO پرمختیا ټیم

ګټور لینکونه

OpenStack

ټنګسټن پارچه

سرچینه: www.habr.com

د کلاوډ خدمت رامینځته کولو تاریخ ، د سایبرپنک سره خوندور