د تیر کال په پای کې، د روسیې د PostgreSQL ټولنې بل ژوندۍ خپرونه ترسره شوه په دې ترڅ کې چې د دې شریک بنسټ ایښودونکي نیکولای سموخوالوف د فلانټ تخنیکي رییس دیمیتري سټولیاروف سره د دې DBMS په اړه د Kubernetes په اړه خبرې وکړې.
موږ د دې بحث اصلي برخه یو نقل خپروو، او په بشپړه ویډیو خپره شوې:
ډیټابیسونه او کبرنیټس
NS: موږ به نن د ویکیوم او چیک پوائنټونو په اړه خبرې ونه کړو. موږ غواړو د Kubernetes په اړه وغږیږو. زه پوهیږم چې تاسو د ډیرو کلونو تجربه لرئ. ما ستاسو ویډیوګانې لیدلي او حتی ځینې یې بیا لیدلي ... راځئ چې مستقیم ټکي ته ورسیږو: ولې پوسټګریس یا مای ایس کیو ایل په K8s کې بالکل؟
د: د دې پوښتنې لپاره دقیق ځواب شتون نلري او شتون نلري. مګر په عموم کې، دا سادگي او اسانتیا ده ... احتمالي. هرڅوک اداره شوي خدمات غواړي.
NS: څنګه یوازې په کور کې؟
د: هو: د RDS په څیر، هرچیرې.
NS: "هرچیرې" یو ښه ټکی دی. په لویو شرکتونو کې، هر څه په مختلفو ځایونو کې موقعیت لري. بیا ولې، که دا یو لوی شرکت وي، چمتو شوي حل نه اخلي؟ د مثال په توګه، Nutanix خپل پرمختګونه لري، نور شرکتونه (VMware...) ورته "RDS، یوازې په کور کې."
د: مګر موږ د جلا پلي کولو په اړه خبرې کوو چې یوازې د ځانګړو شرایطو لاندې کار کوي. او که موږ د Kubernetes په اړه وغږیږو، نو د زیربنا خورا لوی ډول شتون لري (کوم چې په K8s کې کیدی شي). په لازمي ډول دا بادل ته د APIs لپاره معیار دی ...
NS: دا هم وړيا ده!
د: دا دومره مهمه نه ده. آزادي د بازار د یوې لویې برخې لپاره مهمه ده. یو څه بل مهم دی ... تاسو شاید راپور په یاد ولرئ "؟
NS: هو.
د: زه پوهیدم چې دا خورا مبهم ترلاسه شوی. ځینې خلک فکر کاوه چې زه وایم: "هلکانو، راځئ چې ټول ډیټابیسونه کوبرنیټس ته ورسوو!"، پداسې حال کې چې نورو پریکړه وکړه چې دا ټول ډارونکي بایسکلونه دي. مګر ما غوښتل یو څه بل څه ووایم: "وګورئ چې څه پیښیږي، کومې ستونزې شتون لري او څنګه حل کیدی شي. ایا موږ باید اوس د Kubernetes ډیټابیسونه وکاروو؟ تولید؟ ښه، یوازې که تاسو غواړئ ... ځینې شیان ترسره کړئ. مګر د یو دیو لپاره ، زه کولی شم ووایم چې زه یې وړاندیز کوم. د یو دیو لپاره، د چاپیریال رامینځته کولو / حذف کولو تحرک خورا مهم دی.
NS: د دیو په واسطه، ایا تاسو ټول هغه چاپیریالونه بولئ چې تولید نه وي؟ سټینګ، QA…
د: که موږ د پرف سټینډونو په اړه وغږیږو، نو شاید نه، ځکه چې هلته اړتیاوې مشخصې دي. که موږ د ځانګړو قضیو په اړه وغږیږو چیرې چې د سټینګ کولو لپاره خورا لوی ډیټابیس ته اړتیا وي ، نو شاید نه ... که دا یو جامد ، اوږدمهاله چاپیریال وي نو بیا په K8s کې د ډیټابیس درلودل څه ګټه لري؟
NS: هیڅ نه. مګر موږ جامد چاپیریال چیرته ګورو؟ یو جامد چاپیریال به سبا ناپاک شي.
د: سټیج کول جامد کیدی شي. موږ مشتریان لرو ...
NS: هو، زه هم لرم. دا یوه لویه ستونزه ده که تاسو د 10 TB ډیټابیس او 200 GB سټینګ ولرئ ...
د: زه ډیره ښه قضیه لرم! په سټیج کې د محصول ډیټابیس شتون لري چې پکې بدلونونه رامینځته کیږي. او دلته یو تڼۍ شتون لري: "تولید ته راوتل". دا بدلونونه - ډیلټا - اضافه شوي (داسې ښکاري چې دوی په ساده ډول د API له لارې همغږي شوي) په تولید کې. دا یو ډیر بهرني انتخاب دی.
NS: ما په دره کې هغه پیلونه لیدلي چې په RDS یا حتی په هیروکو کې ناست دي - دا د 2-3 کاله دمخه کیسې دي - او دوی خپل لپ ټاپ ته ډمپ ډاونلوډ کوي. ځکه چې ډیټابیس لاهم یوازې 80 GB دی، او په لپ ټاپ کې ځای شتون لري. بیا دوی د هرچا لپاره اضافي ډیسکونه اخلي ترڅو دوی د مختلف پرمختګونو ترسره کولو لپاره 3 ډیټابیسونه ولري. همداسې هم کیږي. ما دا هم ولیدل چې دوی په سټینګ کې د پروډ کاپي کولو څخه ویره نلري - دا خورا په شرکت پورې اړه لري. مګر ما دا هم ولیدل چې دوی ډیر ویره لري، او دا چې دوی ډیری وختونه کافي وخت او لاسونه نلري. مګر مخکې لدې چې موږ دې موضوع ته لاړ شو ، زه غواړم د کبرنیټس په اړه واورم. ایا زه په سمه توګه پوهیږم چې هیڅوک لاهم په تولید کې ندي؟
د: موږ په تولید کې کوچني ډیټابیسونه لرو. موږ د لسګونو ګیګابایټ حجمونو او غیر جدي خدماتو په اړه وغږیږو د کوم لپاره چې موږ د عکسونو په جوړولو کې ډیر سست وو (او داسې اړتیا نشته). او په دې شرط چې د Kubernetes لاندې نورمال ذخیره شتون ولري. دا ډیټابیس په مجازی ماشین کې کار کاوه - په شرطي ډول په VMware کې، د ذخیره کولو سیسټم په سر کې. موږ یې دننه کړل او اوس موږ کولی شو دا له ماشین څخه ماشین ته انتقال کړو.
NS: د دې اندازې ډیټابیسونه، تر 100 GB پورې، په څو دقیقو کې په ښه ډیسکونو او ښه شبکه کې لیږدول کیدی شي، سمه ده؟ په هر ثانیه کې د 1 GB سرعت نور بهرني ندي.
د: هو، د خطي عملیاتو لپاره دا کومه ستونزه نده.
NS: ښه، موږ باید د محصول په اړه فکر وکړو. او که موږ د غیر تولید چاپیریال لپاره کبرنیټس په پام کې ونیسو، موږ باید څه وکړو؟ زه دا په ځلانډو کې ګورم , په Crunchy ، ځینې نور اختیارونه شتون لري. او شته - دا زموږ د هسپانیې څخه الوارو ښه ملګری دی: هغه څه چې دوی یې کوي اساسا یوازې ندي او ټوله توزیع ()، په کوم کې چې پخپله د پوسټګریس سربیره، دوی هم پریکړه وکړه چې یو بیک اپ ډک کړي، د سفیر پراکسي ...
د: سفیر د څه لپاره؟ په ځانګړي ډول د پوسټګریس ترافیک توازن کول؟
NS: هو. دا دی ، دوی دا داسې ګوري: که تاسو د لینکس توزیع او کرنل واخلئ ، نو منظم PostgreSQL دانه ده ، او دوی غواړي داسې توزیع رامینځته کړي چې د بادل سره دوستانه وي او په کوبرنیټس کې پرمخ ځي. دوی برخې (بیک اپ، او نور) سره یوځای کوي او دوی ډیبګ کوي ترڅو دوی ښه کار وکړي.
د: ډیر ښه! په لازمي ډول دا ستاسو خپل اداره شوي پوسټګریس رامینځته کولو لپاره سافټویر دی.
NS: د لینکس توزیع ابدي ستونزې لري: څنګه ډرایورونه رامینځته کړئ ترڅو ټول هارډویر ملاتړ شي. او دوی دا نظر لري چې دوی به په کبرنیټس کې کار وکړي. زه پوهیږم چې په Zalando آپریټر کې موږ پدې وروستیو کې د AWS سره اړیکه ولیدله او دا نور ډیر ښه ندي. دلته باید د یو ځانګړي زیربنا سره اړیکه ونلري - نو بیا څه شی دی؟
د: زه دقیقا نه پوهیږم چې زیلانډو په کوم حالت کې راغلی ، مګر په کوبرنیټس ذخیره کې اوس په داسې ډول رامینځته شوی چې د عمومي میتود په کارولو سره د ډیسک بیک اپ اخیستل ناممکن دي. په دې وروستیو کې معیاري - په وروستي نسخه کې - موږ سنیپ شاټونه ممکن کړي، مګر دا چیرته پلي کیږي؟ په ریښتیا، هرڅه لاهم خام دي ... موږ د AWS، GCE، Azure، vSphere په سر کې CSI هڅه کوو، مګر هرڅومره ژر چې تاسو یې کارول پیل کړئ، تاسو وګورئ چې دا لاهم چمتو نه دی.
NS: له همدې امله موږ ځینې وختونه باید په زیربنا تکیه وکړو. زه فکر کوم چې دا لاهم یو ابتدايي مرحله ده - د درد وده. پوښتنه: تاسو نویو ته څه مشوره ورکوئ څوک چې غواړي په K8s کې PgSQL هڅه وکړي؟ کوم چلوونکی شاید؟
د: ستونزه دا ده چې پوسټګریس زموږ لپاره 3٪ دی. موږ په کوبرنیټس کې د مختلف سافټویر خورا لوی لیست هم لرو ، زه به حتی هرڅه لیست نه کړم. د مثال په توګه، Elasticsearch. ډیری چلونکي شتون لري: ځینې یې په فعاله توګه وده کوي، نور یې ندي. موږ د ځان لپاره اړتیاوې چمتو کړي دي چې یو آپریټر باید څه شی ولري ترڅو موږ یې په جدي توګه ونیسو. په یو آپریټر کې په ځانګړي توګه د کبرنیټس لپاره - نه په "آپریټر کې چې د ایمیزون شرایطو کې یو څه وکړي" ... په حقیقت کې ، موږ په پراخه کچه (= نږدې ټول پیرودونکي) یو واحد آپریټر کاروو - (موږ به ډیر ژر د هغه په اړه مقاله خپره کړو).
NS: او نه هم د MySQL لپاره؟ زه پوهیږم چې Percona ... ځکه چې دوی اوس په MySQL، MongoDB، او Postgres کې کار کوي، دوی باید یو ډول نړیوال حل رامینځته کړي: د ټولو ډیټابیسونو لپاره، د ټولو کلاوډ چمتو کونکو لپاره.
د: موږ وخت نه درلود چې د MySQL لپاره آپریټرانو ته وګورو. دا اوس زموږ اصلي تمرکز نه دی. MySQL په سټنډرډ کې ښه کار کوي. ولې یو آپریټر وکاروئ که تاسو یوازې ډیټابیس لانچ کولی شئ ... تاسو کولی شئ د پوسټرجس سره د ډاکر کانټینر لانچ کړئ ، یا تاسو کولی شئ دا په ساده ډول لانچ کړئ.
NS: په دې اړه هم یوه پوښتنه وه. هیڅ آپریټر نشته؟
د: هو، زموږ څخه 100٪ PostgreSQL پرته له آپریټر چلوي. تر اوسه پورې. موږ په فعاله توګه د Prometheus او Redis لپاره آپریټر کاروو. موږ پلان لرو چې د Elasticsearch لپاره یو آپریټر ومومئ - دا هغه یو دی چې خورا "اور" دی ، ځکه چې موږ غواړو دا په 100٪ قضیو کې په کبرنیټس کې نصب کړو. لکه څنګه چې موږ غواړو ډاډ ترلاسه کړو چې MongoDB هم تل په Kubernetes کې نصب شوی. دلته ځینې هیلې څرګندیږي - داسې احساس شتون لري چې پدې حالت کې یو څه ترسره کیدی شي. او موږ حتی پوسټګریس ته نه ګورو. البته، موږ پوهیږو چې مختلف انتخابونه شتون لري، مګر په حقیقت کې موږ یو واحد یو.
په کوبرنیټس کې د ازموینې لپاره DB
NS: راځئ چې د ازموینې موضوع ته لاړ شو. ډیټابیس ته د بدلونونو رامینځته کولو څرنګوالی - د DevOps لید څخه. مایکرو خدمتونه شتون لري، ډیری ډیټابیسونه، یو څه هر وخت بدلیږي. څنګه د نورمال CI/CD ډاډ ترلاسه کړئ ترڅو هرڅه د DBMS لید څخه په ترتیب سره وي. ستاسو تګلاره څه ده؟
د: یو ځواب نه شي کېدای. ډیری اختیارونه شتون لري. لومړی د بیس اندازه ده چې موږ یې غواړو راوباسئ. تاسو پخپله یادونه وکړه چې شرکتونه په دیو او سټیج کې د پروډ ډیټابیس کاپي کولو په اړه مختلف چلند لري.
NS: او د GDPR شرایطو لاندې، زه فکر کوم چې دوی ډیر احتیاط کوي ... زه کولی شم ووایم چې په اروپا کې دوی دمخه د جریمې لګول پیل کړي دي.
د: مګر ډیری وختونه تاسو کولی شئ داسې سافټویر ولیکئ چې د تولید څخه ډمپ اخلي او هغه یې پټوي. د پروډ ډیټا ترلاسه کیږي (سنیپ شاټ ، ډمپ ، بائنری کاپي ...) ، مګر دا نامعلوم دی. پرځای یې، د نسل سکریپټونه کیدی شي: دا کیدای شي فکسچر وي یا یوازې یو سکریپټ وي چې لوی ډیټابیس تولیدوي. ستونزه دا ده: د بیس عکس رامینځته کولو لپاره څومره وخت نیسي؟ او په مطلوب چاپیریال کې یې ځای پرځای کول څومره وخت نیسي؟
موږ یوې سکیم ته راغلو: که چیرې پیرودونکي ثابت ډیټا سیټ ولري (د ډیټابیس لږترلږه نسخه) ، نو موږ یې په ډیفالټ کاروو. که موږ د بیاکتنې چاپیریال په اړه وغږیږو، کله چې موږ یوه څانګه جوړه کړه، موږ د غوښتنلیک یوه بیلګه ځای پرځای کړه - موږ هلته یو کوچنی ډیټابیس جوړوو. مګر دا ښه وګرځید ، کله چې موږ په ورځ کې یو ځل (شپه کې) له تولید څخه ډمپ اخلو او د دې پراساس د دې بار شوي ډیټا سره د PostgreSQL او MySQL سره د ډاکر کانټینر جوړوو. که تاسو اړتیا لرئ د دې عکس څخه 50 ځله ډیټابیس پراخه کړئ ، دا خورا ساده او ګړندي ترسره کیږي.
NS: د ساده کاپي کولو له لارې؟
د: ډاټا په مستقیم ډول د ډاکر عکس کې زیرمه کیږي. هغوی. موږ یو چمتو شوی عکس لرو، که څه هم 100 GB. په ډاکر کې د پرتونو څخه مننه ، موږ کولی شو دا عکس ژر تر ژره څو ځله ځای په ځای کړو څومره چې موږ ورته اړتیا لرو. میتود احمق دی، مګر دا ښه کار کوي.
NS: بیا، کله چې تاسو ازموینه وکړئ، دا د ډاکر دننه سم بدلیږي، سمه ده؟ د ډاکر دننه کاپي لیک - دا یې وغورځوئ او بیا لاړ شئ، هرڅه سم دي. ټولګي! او ایا تاسو دمخه دا په بشپړ ډول کاروئ؟
د: د اوږد مهال لپاره.
NS: موږ ډېر ورته کارونه کوو. یوازې موږ د ډاکر کاپي آن لیکل نه کاروو ، مګر یو بل.
د: دا عمومي نه ده. او ډاکر هرچیرې کار کوي.
NS: په تیوري کې، هو. مګر موږ هلته ماډلونه هم لرو، تاسو کولی شئ مختلف ماډلونه جوړ کړئ او د مختلف فایل سیسټمونو سره کار وکړئ. دلته څه شیبه ده. د پوسټګریس اړخ څخه، موږ دا ټول په بل ډول ګورو. اوس ما د ډاکر اړخ څخه وکتل او ولیدل چې هرڅه ستاسو لپاره کار کوي. مګر که ډیټابیس خورا لوی وي ، د مثال په توګه ، 1 TB ، نو دا ټول ډیر وخت نیسي: د شپې عملیات ، او هرڅه په ډاکر کې ډکول ... او که 5 TB په ډاکر کې ډک شي ... یا هرڅه سم دي؟
د: څه توپیر دی: دا بلبونه دي، یوازې بټونه او بایټونه.
NS: توپیر دا دی: ایا تاسو دا د ډمپ او بیا رغولو له لارې کوئ؟
د: هیڅ اړتیا نشته. د دې انځور د جوړولو طریقې کیدای شي مختلف وي.
NS: د ځینو پیرودونکو لپاره، موږ دا جوړ کړی دی چې په منظمه توګه د بیس عکس رامینځته کولو پرځای، موږ دا په دوامداره توګه تازه ساتو. دا په اصل کې یو نقل دی، مګر دا ډاټا په مستقیم ډول د ماسټر څخه نه، مګر د آرشیف له لارې ترلاسه کوي. یو بائنری آرشیف چیرې چې WALs هره ورځ ډاونلوډ کیږي ، چیرې چې بیک اپ اخیستل کیږي ... دا WALs بیا د لږ ځنډ سره اساس عکس ته رسیږي (په لفظي ډول 1-2 ثانیې). موږ له دې څخه په هر ډول کلون کوو - اوس موږ په ډیفالټ ZFS لرو.
د: مګر د ZFS سره تاسو په یو نوډ پورې محدود یاست.
NS: هو. مګر ZFS هم یو جادو لري : د دې سره تاسو کولی شئ یو سنیپ شاټ واستوئ او حتی (ما تراوسه دا واقعیا نه ده ازمولې ، مګر ...) تاسو کولی شئ د دوه ترمینځ ډیلټا ولیږئ PGDATA. په حقیقت کې ، موږ یو بل وسیله لرو چې موږ واقعیا د داسې کارونو لپاره په پام کې نه دي نیولي. PostgreSQL لري ، کوم چې د "سمارټ" rsync په څیر کار کوي ، ډیری هغه څه پریږدي چې تاسو یې لیدلو ته اړتیا نلرئ ، ځکه چې هلته هیڅ شی نه دی بدل شوی. موږ کولی شو د دوه سرورونو تر مینځ ګړندي همغږي وکړو او په ورته ډول بیرته راونډ کړو.
نو ، له دې څخه ، د DBA ډیر اړخ ته ، موږ هڅه کوو داسې وسیله رامینځته کړو چې موږ ته اجازه راکوي هغه څه ترسره کړو چې تاسو وویل: موږ یو ډیټابیس لرو ، مګر موږ غواړو یو څه 50 ځله ازموینه وکړو ، نږدې په ورته وخت کې.
د: 50 ځله پدې معنی چې تاسو اړتیا لرئ د 50 سپاټ مثالونو امر وکړئ.
NS: نه، موږ هر څه په یوه ماشین کې کوو.
د: مګر تاسو به څنګه 50 ځله پراخ کړئ که دا یو ډیټابیس وي، ووایه، ټیرابایټ. ډیری احتمال هغه مشروط 256 GB رام ته اړتیا لري؟
NS: هو، ځینې وختونه تاسو ډیرې حافظې ته اړتیا لرئ - دا عادي خبره ده. مګر دا د ژوند څخه یو مثال دی. د تولید ماشین 96 کورونه او 600 GB لري. په ورته وخت کې، د ډیټابیس لپاره 32 کورونه (حتی اوس ځینې وختونه 16 کورونه) او 100-120 GB حافظه کارول کیږي.
د: او هلته 50 نقلونه مناسب دي؟
NS: نو دلته یوازې یوه کاپي شتون لري، بیا د کاپي پر لیکلو (ZFS) کار کوي ... زه به تاسو ته په تفصیل سره ووایم.
د مثال په توګه، موږ د 10 TB ډیټابیس لرو. دوی د دې لپاره یو ډیسک جوړ کړ، ZFS هم د هغې اندازه د 30-40 سلنې لخوا فشار کړې. له هغه ځایه چې موږ د بار ازموینه نه کوو ، د ځواب دقیق وخت زموږ لپاره مهم ندي: اجازه راکړئ چې دا تر 2 ځله ورو وي - دا سمه ده.
موږ پروګرام کونکو ته فرصت ورکوو، QA، DBA، او نور. په 1-2 تارونو کې ازموینه ترسره کړئ. د مثال په توګه، دوی ممکن یو ډول مهاجرت پرمخ بوځي. دا په یوځل کې 10 کور ته اړتیا نلري - دا د 1 پوسټګریس پس منظر ، 1 کور ته اړتیا لري. مهاجرت به پیل شي - شاید بیا به پیل شي، بیا دویم کور به وکارول شي. موږ 16-32 کورونه تخصیص شوي، نو 10 کسان کولی شي په ورته وخت کې کار وکړي، کومه ستونزه نشته.
ځکه چې په فزیکي توګه PGDATA ورته ، دا معلومه شوه چې موږ واقعیا پوسټګریس ته دوکه ورکوو. چال دا دی: د مثال په توګه ، 10 پوسټګریس په ورته وخت کې پیل شوي. معمولا ستونزه څه ده؟ دوی واچول ، راځئ چې ووایو 25٪. په دې اساس، دا 200 GB دی. تاسو به نشئ کولی له دې دریو څخه ډیر پیل کړئ ، ځکه چې حافظه به پای ته ورسیږي.
مګر په یو وخت کې موږ پوه شو چې دا اړین نه و: موږ شریک شوي_بفرونه 2 GB ته تنظیم کړل. PostgreSQL لري ، او په حقیقت کې دا یوازینی دی چې اغیزه کوي . موږ دا 0,5 TB ته تنظیم کړه. او دا حتی مهمه نده چې دوی واقعیا شتون نلري: هغه پلانونه جوړوي لکه څنګه چې شتون لري.
په دې اساس، کله چې موږ د مهاجرت یو ډول ازموینه کوو، موږ کولی شو ټول پلانونه راټول کړو - موږ به وګورو چې دا به په تولید کې څنګه پیښ شي. ثانیې به مختلف وي (ورو) ، مګر هغه معلومات چې موږ واقعیا لوستلو ، او پخپله پلانونه (کوم چې دلته شامل دي ، او داسې نور) په بشپړ ډول د تولید په څیر وګرځي. او تاسو کولی شئ په یو ماشین کې په موازي ډول ډیری داسې چیکونه پرمخ بوځي.
د: تاسو فکر نه کوئ چې دلته یو څو ستونزې شتون لري؟ لومړی یو حل دی چې یوازې په PostgreSQL کې کار کوي. دا طریقه ډیره شخصي ده، دا عمومي نه ده. دوهم دا چې Kubernetes (او هر هغه څه چې د کلاوډ ټیکنالوژي اوس پرمخ ځي) ډیری نوډونه لري، او دا نوډونه لنډمهاله دي. او ستاسو په قضیه کې دا یو ثابت، دوامداره نوډ دی. دا شیان ما شخړه کوي.
NS: لومړی، زه موافق یم، دا په بشپړه توګه د پوسټګریس کیسه ده. زه فکر کوم که موږ د نږدې ټولو حافظې لپاره یو ډول مستقیم IO او بفر حوض ولرو، دا طریقه به کار ونکړي - پالنونه به مختلف وي. مګر د اوس لپاره موږ یوازې د پوسټګریس سره کار کوو، موږ د نورو په اړه فکر نه کوو.
د Kubernetes په اړه. تاسو پخپله موږ ته په هر ځای کې ووایاست چې موږ دوامداره ډیټابیس لرو. که مثال ناکام شي، اصلي شی د ډیسک خوندي کول دي. دلته موږ په Kubernetes کې ټول پلیټ فارم هم لرو، او د پوسټګریس سره برخه جلا ده (که څه هم دا به یوه ورځ وي). له همدې امله ، هرڅه داسې دي: مثال راوتلی ، مګر موږ یې PV خوندي کړ او په ساده ډول یې له بل (نوي) مثال سره وصل کړ ، لکه څنګه چې هیڅ پیښ شوي ندي.
د: زما له نظره، موږ په Kubernetes کې پوډونه جوړوو. K8s - لچکدار: غوټۍ د اړتیا سره سم ترتیب شوي. دنده په ساده ډول یو پوډ رامینځته کول دي او ووایه چې دا د X مقدار سرچینو ته اړتیا لري ، او بیا K8s به دا پخپله وپیژني. مګر په کوبرنیټس کې د ذخیره کولو ملاتړ لاهم بې ثباته دی: په (دا خپرونه خپره شوه недели مخکې) دا ځانګړتیاوې یوازې بیټا کیږي.
له شپږو میاشتو څخه تر یو کال پورې به تیریږي - دا به ډیر یا لږ باثباته شي ، یا لږترلږه دا به ورته اعلان شي. بیا د سنیپ شاټونو امکان او بیا اندازه کول ستاسو ستونزه په بشپړ ډول حل کوي. ځکه چې تاسو یو بنسټ لرئ. هو، دا ممکن خورا ګړندی نه وي ، مګر سرعت په هغه څه پورې اړه لري چې "د هود لاندې" دی ، ځکه چې ځینې پلي کونکي کولی شي د ډیسک فرعي سیسټم په کچه کاپي او کاپي لیکي.
NS: دا د ټولو انجنونو (Amazon، Google...) لپاره هم اړینه ده چې د دې نسخې ملاتړ پیل کړي - دا هم یو څه وخت نیسي.
د: موږ یې تر اوسه نه کاروو. موږ خپل کاروو.
د Kubernetes لپاره سیمه ایز پرمختګ
NS: ایا تاسو داسې هیله لرئ کله چې تاسو اړتیا لرئ ټول پوډونه په یوه ماشین کې نصب کړئ او داسې کوچنۍ ازموینه وکړئ. د ژر تر ژره د مفهوم ثبوت ترلاسه کولو لپاره ، وګورئ چې غوښتنلیک په کوبرنیټس کې پرمخ ځي ، پرته لدې چې د دې لپاره د ماشینونو یوه ډله وقف کړي. مینیکیوب شته، سمه ده؟
د: ماته داسې ښکاري چې دا قضیه - په یوه نوډ کې ځای پرځای شوې - په ځانګړې توګه د محلي پراختیا په اړه ده. یا د داسې نمونې ځینې څرګندونې. خوړل ، دلته ده , . موږ په ډاکر کې د کبرنیټس کارولو په لور روان یو. اوس موږ د دې سره د ازموینو لپاره کار پیل کړ.
NS: ما فکر کاوه چې دا یوه هڅه وه چې ټول پوډونه په یوه ډاکر عکس کې وتړئ. مګر دا معلومه شوه چې دا په بشپړ ډول مختلف دی. په هرصورت، دلته جلا کانټینرونه، جلا پوډونه شتون لري - یوازې په ډاکر کې.
د: هو. او دلته یو په زړه پورې تقلید رامینځته شوی ، مګر معنی دا ده ... موږ د ځای په ځای کولو لپاره یو ګټور کار لرو - . موږ غواړو دا یو مشروط حالت جوړ کړو werf up: "ما ته ځایی کبرنیټ ترلاسه کړئ." او بیا هلته مشروط چلوي werf follow. بیا پراختیا کونکی به وکولی شي IDE ترمیم کړي ، او په سیسټم کې به یوه پروسه پیل شي چې بدلونونه ګوري او عکسونه بیا رغوي ، محلي K8s ته یې بیا ځای په ځای کوي. په دې توګه موږ غواړو د محلي پراختیا د ستونزې د حل لپاره هڅه وکړو.
په K8s حقیقت کې سنیپ شاټونه او ډیټابیس کلونینګ
NS: که موږ د کاپي پر لیکلو ته راستون شو. ما ولیدل چې ورېځې هم عکسونه لري. دوی په بل ډول کار کوي. د مثال په توګه، په GCP کې: تاسو د متحده ایالاتو په ختیځ ساحل کې د څو ټیرابایټ مثال لرئ. تاسو وخت په وخت عکسونه اخلئ. تاسو په لویدیز ساحل کې د ډیسک یوه کاپي د سنیپ شاټ څخه واخلئ - په څو دقیقو کې هرڅه چمتو دي ، دا خورا ګړندي کار کوي ، یوازې زیرمه باید په حافظه کې ډکه شي. مګر دا کلونونه (سنیپ شاټونه) د نوي حجم 'وړاندې کولو' لپاره دي. دا ښه دی کله چې تاسو اړتیا لرئ ډیری مثالونه رامینځته کړئ.
مګر د ازموینو لپاره ، ماته داسې ښکاري چې سنیپ شاټونه ، کوم چې تاسو په ډاکر کې خبرې کوئ یا زه په ZFS ، btrfs او حتی LVM کې خبرې کوم ... - دوی تاسو ته اجازه درکوي په یوه ماشین کې واقعیا نوي ډیټا رامینځته نه کړئ. په بادل کې ، تاسو به لاهم د دوی لپاره هر ځل تادیه وکړئ او ثانیې نه ، مګر دقیقې انتظار وکړئ (او په قضیه کې ، احتمالا یو ساعت).
پرځای یې ، تاسو کولی شئ دا معلومات په یوه یا دوه ثانیو کې ترلاسه کړئ ، ازموینه پرمخ وړئ او لرې یې کړئ. دا عکسونه مختلف ستونزې حل کوي. په لومړي حالت کې - اندازه کول او نوي نقلونه ترلاسه کول، او په دویم کې - د ازموینو لپاره.
د: زه موافق نه یم. د حجم کلونینګ کار په سمه توګه کول د بادل دنده ده. ما د دوی پلي کولو ته نه دی کتلی، مګر زه پوهیږم چې موږ دا په هارډویر کې څنګه کوو. موږ Ceph لرو، دا هر فزیکي حجم ته اجازه ورکوي () ووایه د ورايټۍ او په لسګونو ملی ثانیو کې د ورته ځانګړتیاو سره دوهم حجم ترلاسه کړئ، ami، etc. تاسو اړتیا لرئ پوه شئ چې دننه د لیکلو یو ستونزمن کاپي شتون لري. ولې بادل باید ورته کار ونه کړي؟ زه ډاډه یم چې دوی هڅه کوي دا یو یا بل ډول ترسره کړي.
NS: مګر دا به بیا هم دوی ثانیې ونیسي، لسګونه ثانیې د مثال په توګه پورته کړي، ډاکر هلته راوړي، او داسې نور.
د: ولې دا اړینه ده چې ټول مثال پورته کړئ؟ موږ د 32 کورونو سره یو مثال لرو، 16 ... او دا کولی شي پدې کې فټ شي - د بیلګې په توګه، څلور. کله چې موږ پنځم امر وکړو، مثال به لا دمخه پورته شي، او بیا به حذف شي.
NS: هو، په زړه پورې، Kubernetes یوه بله کیسه ده. زموږ ډیټابیس په K8s کې نه دی، او موږ یو مثال لرو. مګر د څو ټیرابایټ ډیټابیس کلون کول له دوه ثانیو څخه ډیر وخت نه نیسي.
د: دا عالي ده. مګر زما لومړنی ټکی دا دی چې دا یو عام حل ندی. هو ، دا ښه دی ، مګر دا یوازې د پوسټګریس لپاره مناسب دی او یوازې په یو نوډ کې.
NS: دا نه یوازې د پوسټګریس لپاره مناسب دی: دا پلانونه، لکه څنګه چې ما تشریح کړل، یوازې به په دې کې کار وکړي. مګر که موږ د پلانونو په اړه فکر نه کوو، او موږ یوازې د فعالې ازموینې لپاره ټول ډیټا ته اړتیا لرو، نو دا د هر ډول DBMS لپاره مناسب دی.
د: ډیری کاله دمخه موږ په LVM سنیپ شاټونو کې ورته یو څه وکړل. دا یو کلاسیک دی. دا طریقه خورا فعاله کارول شوې وه. دولتي نوډونه یوازې یو درد دی. ځکه چې تاسو باید دوی ونه غورځوئ، تاسو باید تل په یاد ولرئ ...
NS: ایا تاسو دلته د هایبرډ کوم امکان ګورئ؟ راځئ چې ووایو Stateful یو ډول پوډ دی، دا د څو خلکو (ډیری ازموینو) لپاره کار کوي. موږ یو حجم لرو، مګر د فایل سیسټم څخه مننه، کلون محلي دي. که پوډ راښکته شي، مګر ډیسک پاتې شي، پوډ به پورته شي، د ټولو کلونونو په اړه معلومات حساب کړي، هر څه بیا پورته کړئ او ووایاست: "دا ستاسو کلونونه په دې بندرونو کې روان دي، دوی سره کار ته دوام ورکړئ."
د: په تخنیکي توګه دا پدې مانا ده چې په کوبرنیټس کې دا یو پوډ دی چې دننه موږ ډیری پوسټګریس چلوو.
NS: هو. هغه یو حد لري: راځئ چې ووایو له 10 څخه ډیر خلک په ورته وخت کې له هغه سره کار نه کوي. که تاسو 20 ته اړتیا لرئ، موږ به یو بل داسې پوډ پیل کړو. موږ به دا په بشپړه توګه کلون کړو، د دویم بشپړ حجم ترلاسه کولو سره، دا به ورته 10 "پتلی" کلونونه ولري. ایا تاسو دا فرصت نه ګورئ؟
د: موږ باید دلته امنیتي مسایل اضافه کړو. دا ډول تنظیم پدې معنی دی چې دا پوډ لوړ امتیازات (وړتیاوې) لري، ځکه چې دا کولی شي د فایل سیسټم غیر معیاري عملیات ترسره کړي ... مګر زه بیا تکراروم: زه باور لرم چې دوی به په منځنۍ موده کې په کوبرنیټس کې ذخیره تنظیم کړي، او بادل به دوی ټوله کیسه د حجمونو سره حل کړي - هرڅه به "یوازې کار وکړي". بیا اندازه کول، کلونینګ به وي ... یو حجم شتون لري - موږ وایو: "د دې پر بنسټ یو نوی جوړ کړئ" او د یوې نیمې ثانیې وروسته موږ هغه څه ترلاسه کوو چې موږ ورته اړتیا لرو.
NS: زه د ډیرو ټیرابایټ لپاره په یو نیم ثانیو باور نه لرم. په سیف کې تاسو دا پخپله کوئ، مګر تاسو د ورېځو په اړه خبرې کوئ. بادل ته لاړ شئ، په EC2 کې د څو ټیرابایټ EBS حجم کلون جوړ کړئ او وګورئ چې فعالیت به څه وي. دا به څو ثانیې ونه نیسي. زه ډیره علاقه لرم چې دوی به کله دې کچې ته ورسیږي. زه پوهیږم چې تاسو څه وایئ، مګر زه د توپیر غوښتنه کوم.
د: سمه ده، خو ما په منځ مهاله کې وویل، لنډ مهاله نه. د څو کلونو لپاره.
د Zalando څخه د PostgreSQL لپاره د آپریټر په اړه
د دې غونډې په مینځ کې، الیکسي کلوکین، د زیلانډو پخوانی پراختیا کونکی، هم ګډون وکړ او د PostgreSQL آپریټر تاریخ په اړه یې خبرې وکړې:
دا خورا ښه ده چې دا موضوع په عمومي ډول په ګوته کیږي: دواړه پوسټګریس او کوبرنیټس. کله چې موږ په 2017 کې په Zalando کې دا کار پیل کړ، دا یوه موضوع وه چې هرڅوک یې کول غوښتل، مګر هیڅوک یې ونه کړل. هرڅوک دمخه Kubernetes درلودل، مګر کله چې دوی وپوښتل چې د ډیټابیس سره څه وکړي، حتی خلک خوښوي ، چا چې د K8s تبلیغ کاوه ، داسې یو څه وویل:
"منظم شوي خدماتو ته لاړشئ او وکاروئ ، په کوبرنیټس کې ډیټابیس مه چلوئ. که نه نو، ستاسو K8s به پریکړه وکړي، د بیلګې په توګه، د نوي کولو لپاره، ټول نوډونه بند کړئ، او ستاسو ډاټا به ډیر لیرې پرواز وکړي.
موږ پریکړه وکړه چې یو آپریټر جوړ کړو چې د دې مشورې برخلاف به په کوبرنیټس کې د پوسټګریس ډیټابیس پیل کړي. او موږ یو ښه دلیل درلود - . دا د PostgreSQL لپاره یو اتوماتیک ناکام دی، په سمه توګه ترسره شوی، د بیلګې په توګه. د کلستر په اړه د معلوماتو ذخیره کولو په توګه د etcd، قونصل یا ZooKeeper کارول. دا ډول ذخیره چې هرچا ته به یې ورکوي چې پوښتنه وکړي، د بیلګې په توګه، اوسنی مشر څه شی دی، ورته معلومات - سره له دې چې موږ هر څه ویشلي دي - نو د دماغ ویش شتون نلري. پلس موږ درلود دهغه لپاره.
په عموم کې ، د آټو ناکامۍ لپاره د شرکت اړتیا د داخلي هارډویر ډیټا مرکز څخه کلاوډ ته له مهاجرت وروسته ښکاره شوه. بادل د ملکیت PaaS (د خدمت په توګه د پلیټ فارم) حل پراساس و. دا خلاص سرچینه ده، مګر د دې پورته کولو او چلولو لپاره یې ډیر کار واخیست. دا بلل کیده .
په پیل کې، هیڅ Kubernetes شتون نه درلود. په دقیق ډول ، کله چې زموږ خپل حل ځای په ځای شوی و ، K8s دمخه شتون درلود ، مګر دا دومره خام و چې د تولید لپاره مناسب نه و. دا زما په اند، 2015 یا 2016 وه. په 2017 کې، Kubernetes لږ یا لږ بالغ شوي وو - هلته مهاجرت ته اړتیا وه.
او موږ دمخه د ډاکر کانټینر درلود. یو PaaS و چې ډاکر یې کارولی و. ولې د K8s هڅه نه کوئ؟ ولې خپل چلونکی نه لیکئ؟ مرات کابلوف، چې موږ ته له Avito څخه راغلی، دا په خپل نوښت د یوې پروژې په توګه پیل کړه - "لوبې کول" - او پروژه "پیل شوه."
مګر په عمومي توګه، زه غواړم د AWS په اړه خبرې وکړم. ولې د AWS اړوند تاریخي کوډ شتون درلود ...
کله چې تاسو په Kubernetes کې یو څه پرمخ وړئ، تاسو اړتیا لرئ پوه شئ چې K8s دا ډول کار په پرمختګ کې دی. دا په دوامداره توګه وده کوي، وده کوي او حتی د وخت په تیریدو سره ماتیږي. تاسو اړتیا لرئ په کوبرنیټس کې ټولو بدلونونو ته نږدې نظر وساتئ ، تاسو اړتیا لرئ چمتو اوسئ که چیرې یو څه پیښ شي پدې کې ډوب شئ او زده کړئ چې دا څنګه په تفصیل سره کار کوي - شاید ستاسو څخه ډیر څه چې تاسو یې غواړئ. دا، په اصل کې، په هر هغه پلیټ فارم باندې تطبیق کیږي چې تاسو یې خپل ډیټابیس چلوئ ...
نو، کله چې موږ بیان وکړ، موږ پوسټګریس درلود چې په بهرني حجم کې روان وو (په دې قضیه کې EBS، ځکه چې موږ په AWS کې کار کاوه). ډیټابیس وده وکړه، په ځینو وختونو کې دا اړینه وه چې د هغې اندازه کول: د مثال په توګه، د EBS لومړنۍ اندازه 100 TB وه، ډیټابیس دې ته وده ورکړه، اوس موږ غواړو چې EBS 200 TB جوړ کړو. هغه څنګه؟ راځئ چې ووایو تاسو کولی شئ په یوه نوي مثال کې ډمپ / بیا رغونه وکړئ ، مګر دا به ډیر وخت ونیسي او د وخت وخت پکې شامل وي.
له همدې امله ، ما یو اندازه بدلول غوښتل چې د EBS برخې پراخه کړي او بیا د فایل سیسټم ته ووایی چې نوی ځای وکاروي. او موږ دا وکړل، مګر په هغه وخت کې Kubernetes د بیا اندازې عملیاتو لپاره هیڅ API نلري. څرنګه چې موږ په AWS کې کار کاوه، موږ د دې API لپاره کوډ لیکلی.
هیڅوک تاسو د نورو پلیټ فارمونو لپاره د ورته کولو مخه نه نیسي. په بیان کې هیڅ اشاره نشته چې دا یوازې په AWS کې پرمخ وړل کیدی شي، او دا به په نورو ټولو شیانو کار ونکړي. په عموم کې ، دا د خلاصې سرچینې پروژه ده: که څوک غواړي د نوي API کارولو رامینځته کیدو ګړندی کړي ، تاسو ښه راغلاست یاست. خوړل د غوښتنې غوښتنه - د Zalando ټیم هڅه کوي په چټکۍ سره دوی ته ځواب ووايي او آپریټر ته وده ورکړي. تر هغه ځایه چې زه پوهیږم، پروژه په ګوګل سمر آف کوډ کې او ځینې نور ورته نوښتونه. ځلانډو په دې اړه خورا فعال کار کوي.
PS بونس!
که تاسو د PostgreSQL او Kubernetes موضوع سره علاقه لرئ ، نو مهرباني وکړئ دا هم په یاد ولرئ چې راتلونکی پوسټګریس سه شنبه تیره اونۍ ترسره شو ، چیرې چې ما د نیکولای سره خبرې وکړې الکساندر کوکوشکن د زیلاندو څخه. له هغه څخه ویډیو شتون لري .
پی پی ایس
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- «".
سرچینه: www.habr.com