پېژندنه

څه موده وړاندې ما ته د ناکامۍ کلستر د جوړولو دنده ورکړل شوه پوسټری ایس ایس ایل، په یو ښار کې د نظری فایبر لخوا وصل شوي ډیری ډیټا مرکزونو کې فعالیت کوي ، او د یو ډیټا مرکز ناکامۍ (د مثال په توګه ، بلیک آوټ) سره د مقاومت کولو وړ دی. د سافټویر په توګه چې د خطا زغم مسؤلیت لري، ما غوره کړه pacemakerځکه چې دا د ناکامۍ کلسترونو رامینځته کولو لپاره د RedHat څخه رسمي حل دی. دا ښه دی ځکه چې RedHat د دې لپاره ملاتړ چمتو کوي، او ځکه چې دا حل نړیوال (ماډولر) دی. د دې په مرسته، دا به ممکنه وي چې نه یوازې د PostgreSQL، بلکې د نورو خدماتو د غلطۍ زغم ډاډمن کړي، یا د معیاري ماډلونو په کارولو سره یا د ځانګړو اړتیاو لپاره رامینځته کول.

دې پریکړې یوه معقوله پوښتنه راپورته کړه: د ناکامۍ کلستر به څومره د خطا زغمونکی وي؟ د دې تحقیق کولو لپاره ، ما د ازموینې بینچ رامینځته کړی چې په کلسټر نوډونو کې مختلف ناکامۍ سمولیټ کوي ، د خدماتو بیا رغولو ته انتظار باسي ، ناکامه نوډ بیرته ترلاسه کوي ، او په لوپ کې ازموینې ته دوام ورکوي. دا پروژه په اصل کې د hapgsql په نوم یادیدله، مګر د وخت په تیریدو سره زه د نوم څخه ستړی شوم، کوم چې یوازې یو سر درلود. له همدې امله ، ما د غلطۍ زغمونکي ډیټابیسونو غږ کول پیل کړل (او فلوټ IP دوی ته په ګوته کوي) krogan (د کمپیوټر لوبې یو کرکټر چې ټول مهم ارګانونه نقل شوي دي) او نوډونه، کلسترونه او پروژه پخپله ده tuchanka (هغه سیاره چیرې چې کروګان ژوند کوي).

اوس مدیریت اجازه ورکړې ده پروژه د خلاصې سرچینې ټولنې ته د MIT جواز لاندې خلاص کړئ. README به ډیر ژر په انګلیسي کې وژباړل شي (ځکه تمه کیږي چې اصلي مصرف کونکي به د Pacemaker او PostgreSQL پراختیا کونکي وي) ، او ما پریکړه وکړه چې د دې مقالې په بڼه د README پخوانی روسی نسخه (په جزوي توګه) وړاندې کړم.

کلسترونه په مجازی ماشینونو کې ځای پرځای شوي دي ویډیو. ټول 12 مجازی ماشینونه (په مجموع کې 36GiB) به ځای په ځای شي، کوم چې د 4 غلطی زغمونکي کلسترونه (مختلف اختیارونه) جوړوي. لومړی دوه کلسترونه د دوه PostgreSQL سرورونو څخه جوړ دي، کوم چې په مختلفو ډیټا مرکزونو کې موقعیت لري، او یو عام سرور شاهد c د کورم وسیله (په دریم ډیټا مرکز کې په ارزانه مجازی ماشین کې کوربه شوی) ، کوم چې ناڅرګندتیا حل کوي 50٪ / 50٪، خپله رایه کوم یو ګوند ته ورکړئ. په دریو ډیټا مرکزونو کې دریم کلستر: یو بادار، دوه غلامان، نه د کورم وسیله. څلورم کلستر د څلورو PostgreSQL سرورونو څخه جوړ دی، دوه په هر ډیټا مرکز کې: یو ماسټر، پاتې نقلونه، او هم کاروي شاهد c د کورم وسیله. څلورم کولی شي د دوه سرورونو یا یو ډیټا مرکز ناکامۍ سره مقاومت وکړي. دا حل د اړتیا په صورت کې لوی شمیر نقلونو ته اندازه کیدی شي.

دقیق وخت خدمت ntpd د غلطۍ زغم لپاره هم تنظیم شوی، مګر دا پخپله طریقه کاروي ntpd (د یتیم حالت). شریک شوی سرور شاهد د مرکزي NTP سرور په توګه کار کوي، خپل وخت ټولو کلسترونو ته ویشي، په دې توګه ټول سرورونه د یو بل سره همغږي کوي. که شاهد ناکامیږي یا جلا کیږي، نو د کلستر سرورونو څخه یو (د کلستر دننه) به د خپل وخت ویش پیل کړي. مرستندویه کیشینګ HTTP پراکسي ته هم پورته شوه شاهد، د دې په مرسته ، نور مجازی ماشینونه د یوم ذخیره کولو ته لاسرسی لري. په واقعیت کې، خدمتونه لکه دقیق وخت او پراکسي به ډیری احتمال په وقف شوي سرورونو کې کوربه شي، مګر په بوت کې دوی کوربه شوي دي. شاهد یوازې د مجازی ماشینونو شمیر او ځای خوندي کولو لپاره.

نسخې

v0. په VirtualBox 7 کې د CentOS 11 او PostgreSQL 6.1 سره کار کوي.

د کلستر جوړښت

ټول کلسترونه د دې لپاره ډیزاین شوي چې په ډیری ډیټا مرکزونو کې موقعیت ولري ، په یوه فلیټ شبکه کې یوځای شوي او باید د یو واحد ډیټا مرکز ناکامي یا د شبکې جلا کیدو سره مقاومت وکړي. د همدې لپاره ناممکن دی د ساتنې لپاره کارول ویشل شوی مغز معیاري Pacemaker ټیکنالوژي نومیږي سټونیت (په سر کې نور نوډ ډزې وکړئ) یا جریمه. د دې جوهر: که چیرې په کلستر کې نوډونه په دې شک پیل کړي چې د ځینې نوډ سره یو څه غلط دی ، دا ځواب نه ورکوي یا غلط چلند کوي ، نو دوی په زوره د "بهرني" وسیلو له لارې بندوي ، د مثال په توګه ، د IPMI یا UPS کنټرول کارت. . مګر دا به یوازې په هغه قضیو کې کار وکړي چیرې چې د یوې ناکامۍ په صورت کې د IPMI یا UPS سرور کار ته دوام ورکوي. دلته موږ پلان لرو چې د خورا ډیر ناورین ناکامۍ پروړاندې ساتنه وکړو ، کله چې د معلوماتو ټول مرکز ناکام شي (د مثال په توګه ، بریښنا له لاسه ورکوي). او د داسې انکار سره، هرڅه سټونیت- وسايل (IPMI، UPS، او نور) به کار ونکړي.

پرځای یې، سیسټم د نصاب د نظریې پر بنسټ ولاړ دی. ټول نوډونه غږ لري، او یوازې هغه څوک چې د ټولو نوډونو نیمایي څخه ډیر لیدلی شي کار کولی شي. دې مقدار ته "نیم + 1" ویل کیږي کورم. که چیرې نصاب نه وي رسیدلی، نو نوډ پریکړه کوي چې دا د شبکې په انزوا کې دی او باید خپلې سرچینې بندې کړي، د بیلګې په توګه. دا هغه څه دي چې دا دي د سپیټ دماغ محافظت. که چیرې هغه سافټویر چې د دې چلند لپاره مسؤل دی کار ونکړي، نو بیا یو څارونکی، د بیلګې په توګه، د IPMI پر بنسټ، باید کار وکړي.

که د نوډونو شمیر هم وي (په دوه ډیټا مرکزونو کې کلستر) ، نو بیا نامتو ناڅرګندتیا رامینځته کیدی شي 50٪ / 50٪ (پنځوس پنځوس) کله چې د شبکې جلا کول کلستر په نیمایي کې تقسیموي. له همدې امله، د حتی د نوډونو لپاره، موږ اضافه کوو د کورم وسیله یو غیر مطلوب ډیمون دی چې په دریم ډیټا مرکز کې ترټولو ارزانه مجازی ماشین کې پیل کیدی شي. هغه خپله رایه یوې برخې ته ورکوي (کوم چې هغه ګوري) او په دې توګه د 50٪ / 50٪ ناڅرګندتیا حل کوي. ما هغه سرور نوم کړ په کوم کې چې د کورم وسیله به پیل شي شاهد (د repmg څخه اصطلاحات، ما دا خوښ کړ).

سرچینې له یو ځای څخه بل ځای ته لیږدول کیدی شي، د بیلګې په توګه، له غلط سرورونو څخه صحي سرورونو ته، یا د سیسټم مدیرانو په امر. نو د دې لپاره چې پیرودونکي پوه شي چیرې چې سرچینې ورته اړتیا لري موقعیت لري (چیرې وصل شي؟) تیر شوی IP (فلوټ IP). دا IPs دي چې Pacemaker کولی شي د نوډونو شاوخوا حرکت وکړي (هر څه په فلیټ شبکه کې دي). هر یو یې د سرچینې (خدمت) سمبول دی او دا به موقعیت ولري چیرې چې تاسو اړتیا لرئ دې خدمت ته د لاسرسي لپاره وصل شئ (زموږ په قضیه کې ډیټابیس).

Tuchanka1 (د کمپکشن سره سرکټ)

جوړښت

نظر دا و چې موږ د ټیټ بار سره ډیری کوچني ډیټابیسونه لرو ، د کوم لپاره چې یوازې د لوستلو لیږدونو لپاره په ګرم سټینډ بای حالت کې د وقف شوي غلام سرور ساتل ګټور ندي (د سرچینو دومره ضایع کیدو ته اړتیا نشته).

هر ډیټا مرکز یو سرور لري. هر سرور دوه د PostgreSQL مثالونه لري (د PostgreSQL په اصطلاح کې دوی کلستر ویل کیږي، مګر د ګډوډۍ څخه مخنیوي لپاره زه به دوی ته مثالونه ووایم (د نورو ډیټابیسونو سره د انډول په واسطه)، او زه به یوازې د Pacemaker کلستر کلسترونه ووایم). یو مثال په ماسټر حالت کې کار کوي، او یوازې دا خدمتونه وړاندې کوي (یوازې فلوټ IP دې ته لار هواروي). دوهم مثال د دویم ډیټا مرکز لپاره د غلام په توګه کار کوي، او خدمتونه به یوازې هغه وخت چمتو کړي چې مالک یې ناکام شي. ځکه چې ډیری وخت له دوه څخه یوازې یوه بیلګه (ماسټر) به خدمتونه وړاندې کړي (غوښتنې ترسره کړي)، د سرور ټولې سرچینې د ماسټر لپاره غوره شوي (یادونه د شریک شوي_بفرز کیچ لپاره تخصیص شوي، او داسې نور)، مګر دا چې دویمه بیلګه کافي سرچینې هم لري (که څه هم د فایل سیسټم کیچ له لارې د فرعي غوره عملیاتو لپاره) د ډیټا مرکزونو څخه د یوې ناکامۍ په صورت کې. غلام د کلستر د نورمال عملیاتو په جریان کې خدمات نه وړاندې کوي (یوازې لوستل غوښتنې نه ترسره کوي) ، نو په ورته ماشین کې د ماسټر سره د سرچینو لپاره جګړه شتون نلري.

د دوه نوډونو په حالت کې، د غلطۍ زغم یوازې د غیر متناسب نقل سره ممکن دی، ځکه چې د همغږي نقل سره، د غلام ناکامي به د مالک د بندیدو لامل شي.

په شاهدۍ کې ناکامي

په شاهدۍ کې پاتې راتلل (د کورم وسیله) زه به یوازې د Tuchanka1 کلستر لپاره په پام کې ونیسم، د نورو ټولو سره به ورته کیسه وي. که شاهد ناکام شي، د کلستر په جوړښت کې به هیڅ بدلون ونلري، هرڅه به په ورته ډول کار ته دوام ورکړي. مګر نصاب به له 2 څخه 3 شي، او له همدې امله هر ډول راتلونکی ناکامي به د کلستر لپاره وژونکي وي. دا به لاهم په بیړنۍ توګه تنظیم شي.

Tuchanka1 انکار

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

Tuchanka2 (کلاسیک)

جوړښت

د دوه نوډونو کلاسیک سکیم. بادار په یوه کار کوي، غلام په دویم. دواړه کولی شي غوښتنې پلي کړي (غلام یوازې لوستل کیږي) ، نو دواړه د فلوټ IP لخوا په ګوته شوي: krogan2 ماسټر دی ، krogan2s1 غلام دی. بادار او غلام دواړه به د خطا زغم ولري.

د دوه نوډونو په حالت کې، د غلطۍ زغم یوازې د غیر متناسب نقل سره ممکن دی، ځکه چې د همغږي نقل سره، د غلام ناکامي به د مالک د بندیدو لامل شي.

Tuchanka2 انکار

که یو د معلوماتو مرکزونه ناکام شي شاهد دوهم ته رایه ورکوي. په یوازینی کاري ډیټا مرکز کې، ماسټر به پورته شي، او دواړه فلوټ IPs به ورته اشاره وکړي: ماسټر او غلام. البته، مثال باید په داسې ډول تنظیم شي چې دا کافي سرچینې ولري (د پیوستون محدودیتونه، او نور) په ورته وخت کې د ماسټر او غلام فلوټ IP څخه ټولې اړیکې او غوښتنې ومني. دا دی، د نورمال عملیاتو په جریان کې دا باید په کافي اندازه محدودیت ولري.

Tuchanka4 (ډیری غلامان)

جوړښت

لا دمخه یو بل انتها. داسې ډیټابیسونه شتون لري چې یوازې د لوستلو ډیری غوښتنې ترلاسه کوي (د لوړ بار سایټ یوه عادي قضیه). Tuchanka4 یو داسې حالت دی چیرې چې ممکن د ورته غوښتنو اداره کولو لپاره درې یا ډیر غلامان شتون ولري، مګر بیا هم ډیر نه وي. د ډیری لوی شمیر غلامانو سره، دا به اړین وي چې د درجه بندي نقل سیسټم ایجاد شي. په لږترلږه قضیه کې (په انځور کې)، د دوو معلوماتو مرکزونو هر یو دوه سرورونه لري، هر یو د PostgreSQL مثال سره.

د دې سکیم بله ځانګړتیا دا ده چې دا دمخه ممکنه ده چې یو همغږي نقل تنظیم کړئ. دا د ماسټر په څیر د ورته ډیټا مرکز کې د نقل کولو پرځای د امکان په صورت کې بل ډیټا مرکز ته د نقل کولو لپاره ترتیب شوی. ماسټر او هر غلام د فلوټ IP لخوا په ګوته شوي. خوشبختانه، د غلامانو تر منځ به دا اړینه وي چې غوښتنې په یو ډول توازن کړي sql پراکسيد مثال په توګه، د پیرودونکي لوري ته. د پیرودونکو مختلف ډولونه ممکن مختلف ډولونو ته اړتیا ولري sql پراکسي، او یوازې د پیرودونکي پراختیا کونکي پوهیږي چې څوک ورته اړتیا لري. دا فعالیت یا هم د بهرني ډیمون لخوا یا د پیرودونکي کتابتون (د پیوستون حوض) لخوا پلي کیدی شي. دا ټول د ناکامۍ ډیټابیس کلستر (ناکامۍ SQL پراکسي په خپلواکه توګه پلي کیدی شي، د پیرودونکي غلطی زغم سره یوځای).

Tuchanka4 انکار

که د معلوماتو یو مرکز (لکه دوه سرورونه) ناکام شي، د دویم لپاره د رایو شاهدان. د پایلې په توګه، دوه سرورونه په دویم ډیټا مرکز کې روان دي: یو یې ماسټر چلوي، او ماسټر فلوټ IP ورته اشاره کوي (د لوستلو لیکلو غوښتنو ترلاسه کولو لپاره)؛ او په دوهم سرور کې یو غلام شتون لري چې د همغږي نقل سره پرمخ ځي، او یو د غلام فلوټ IPs ورته اشاره کوي (یوازې د لوستلو غوښتنو لپاره).

د یادولو وړ لومړی شی دا دی چې ټول غلام فلوټ IPs به کارګران نه وي، مګر یوازې یو. او د دې سره په سمه توګه کار کولو لپاره دا به اړین وي sql پراکسي ټولې غوښتنې یوازې پاتې فلوټ IP ته لیږل شوي؛ او که sql پراکسي نه، بیا تاسو کولی شئ ټول فلوټ IP غلامان لیست کړئ چې د کوما لخوا جلا شوي د پیوستون URL کې. په دې حالت کې، سره libpq اړیکه به د لومړي کاري IP سره وي، دا د اتوماتیک ازموینې سیسټم کې ترسره کیږي. شاید په نورو کتابتونونو کې، د بیلګې په توګه، JDBC، دا به کار ونکړي او اړین وي sql پراکسي. دا ترسره کیږي ځکه چې د غلامانو لپاره فلوټ IPs په یو سرور کې په ورته وخت کې راپورته کیدو څخه منع دي ، ترڅو دوی په مساوي ډول د غلام سرورونو ترمینځ توزیع شي که چیرې ډیری یې روان وي.

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

Tuchanka3 (3 د معلوماتو مرکزونه)

جوړښت

دا د داسې وضعیت لپاره کلستر دی چیرې چې درې بشپړ فعالیت کونکي ډیټا مرکزونه شتون لري ، چې هر یو یې په بشپړ ډول فعال ډیټابیس سرور لري. په دې صورت کې د کورم وسیله اړتیا نشته یو د معلوماتو مرکز د ماسټر لخوا کارکونکی دی، نور دوه د غلامانو لخوا کارکونکي دي. نقل کول همغږي دي، ANY ټایپ کړئ (غلام 1، غلام 2)، دا دی، پیرودونکي به د ژمنې تصدیق ترلاسه کړي کله چې کوم غلام لومړی ځواب ووايي چې هغه ژمنه منلې ده. سرچینې د یو فلوټ IP لخوا د ماسټر لپاره او دوه د غلامانو لپاره ښودل شوي. د Tuchanka4 برعکس، ټول درې فلوټ IPs د غلطۍ زغمونکي دي. یوازې د لوستلو SQL پوښتنو توازن لپاره چې تاسو یې کارولی شئ sql پراکسي (د جلا غلطۍ زغم سره)، یا د یو غلام فلوټ IP نیمایي مشتریانو ته، او نیم یې دویم ته ورکړئ.

Tuchanka3 انکار

که د معلوماتو مرکزونو څخه یو ناکام شي، دوه پاتې دي. په یوه کې، د ماسټر څخه ماسټر او فلوټ IP پورته کیږي، په دویمه کې - غلام او دواړه غلام فلوټ IPs (د مثال په توګه باید د سرچینو دوه برابره ذخیره ولري ترڅو د دواړو غلام فلوټ IPs څخه ټولې اړیکې ومني). د بادارانو او غلامانو ترمنځ همغږي نقل. همدارنګه، کلستر به د دوه ډیټا مرکزونو د ویجاړولو په صورت کې د ژمنو او تایید شویو معاملو په اړه معلومات خوندي کړي (د معلوماتو له لاسه ورکول به نه وي) (که دوی په یو وخت کې ویجاړ شوي نه وي).

ما پریکړه وکړه چې د فایل جوړښت او ځای پرځای کولو تفصیلي توضیحات شامل نه کړم. هرڅوک چې غواړي شاوخوا لوبې وکړي کولی شي دا ټول په README کې ولولي. زه یوازې د اتوماتیک ازموینې توضیحات وړاندې کوم.

د اتوماتیک ازموینې سیسټم

د مختلف غلطیو سمولو له لارې د کلسترونو د خطا زغم ازموینې لپاره ، د اتوماتیک ازموینې سیسټم رامینځته شوی. د سکریپټ لخوا پیل شوی test/failure. سکریپټ کولی شي د پیرامیټونو په توګه د کلسترونو شمیره واخلي چې تاسو یې ازموینه غواړئ. د مثال په توګه دا حکم:

test/failure 2 3

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

ټرمینل په کالمونو ویشل شوی د کلسترونو شمیر سره سم چې ازمول کیږي؛ په ډیفالټ (په سکرین شاټ کې) څلور شتون لري. زه به د Tuchanka2 مثال په کارولو سره د کالم مینځپانګې تشریح کړم. په سکرین شاټ کې پینلونه شمیرل شوي دي:

1. د ازموینې احصایې دلته ښودل شوي. کالمونه:
   • ناکامي - د ازموینې نوم (په سکریپټ کې فعالیت) چې خطا تقلید کوي.
   • غبرګون - د ریاضي اوسط وخت په ثانیو کې چې کلستر خپل فعالیت بیرته ترلاسه کړ. دا د سکریپټ له پیل څخه اندازه کیږي چې د خطا تقلید کوي تر هغه وخته پورې چې کلستر خپل فعالیت بیرته راولي او د خدماتو چمتو کولو ته دوام ورکړي. که وخت خورا لنډ وي، د بیلګې په توګه، شپږ ثانیې (دا په کلسترونو کې د څو غلامانو (Tuchanka3 او Tuchanka4) سره پیښیږي)، دا پدې مانا ده چې غلطي د غیر متمرکز غلام وه او په هیڅ ډول یې په فعالیت اغیزه نه وه کړې؛ هیڅ شتون نلري. د کلستر حالت سویچ.
   • انحراف - د ارزښت خپریدل (دقت) ښیې غبرګون د معیاري انحراف میتود کارول.
   • حساب - دا ازموینه څو ځله ترسره شوې.
2. یو لنډ لاګ تاسو ته اجازه درکوي ارزونه وکړئ چې کلستر اوس څه کوي. د تکرار (ازموینې) شمیره، مهال ویش او د عملیاتو نوم ښودل کیږي. ډیر اوږد چلول (> 5 دقیقې) ستونزه په ګوته کوي.
3. هرات (زړه) - اوسنی وخت. د فعالیت بصری ارزونې لپاره ماسټرې اوسنی وخت په دوامداره توګه د فلوټ IP ماسټر په کارولو سره خپل میز ته لیکل کیږي. که بریالی وي، پایله به په دې پینل کې ښکاره شي.
4. ته ماتې ورکړه (نبض) - "اوسنی وخت"، کوم چې مخکې د سکریپټ لخوا ثبت شوی و هرات د ماسټرۍ لپاره، اوس له دې څخه ولولئ غلام د خپل فلوټ IP له لارې. تاسو ته اجازه درکوي په لید کې د غلام او نقل فعالیت ارزونه وکړئ. په Tuchanka1 کې د فلوټ IP سره هیڅ غلام شتون نلري (هیڅ غلام خدمتونه نه وړاندې کوي)، مګر دوه مثالونه (DBs) شتون لري، نو دا به دلته ونه ښودل شي ته ماتې ورکړهاو هرات دوهم مثال.
5. د کارونې په کارولو سره د کلستر روغتیا څارنه pcs mon. جوړښت، په نوډونو کې د سرچینو ویش او نور ګټور معلومات ښیې.
6. په کلستر کې د هر مجازی ماشین څخه د سیسټم څارنه دلته ښودل کیږي. ممکن نور داسې پینلونه وي چې پدې پورې اړه لري چې کلستر څومره مجازی ماشینونه لري. دوه ګرافونه د CPU بار (مجازی ماشینونه دوه پروسیسرونه لري)، د مجازی ماشین نوم، د سیسټم بار (د لوډ اوسط نومول شوی ځکه چې دا په اوسط ډول د 5، 10 او 15 دقیقو څخه زیات دی)، د پروسس ډاټا او د حافظې تخصیص.
7. د سکریپټ ټریس د ازموینې ترسره کول. د خرابۍ په حالت کې - د عملیاتو ناڅاپي مداخله یا د انتظار نه ختمیدونکي دورې - دلته تاسو د دې چلند دلیل لیدلی شئ.

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

هره ازموینه د لاندې عملیاتو څخه جوړه ده:

1. یو فنکشن پیل کړئ چې د غلطۍ تقلید کوي.
2. ته چمتو دی؟ - د کلستر بیا رغولو ته انتظار کول (کله چې ټول خدمتونه چمتو شي).
3. د کلستر د بیا رغولو وخت ښیي (غبرګون).
4. سمه - کلستر "ترمیم" کیږي. له هغې وروسته دا باید په بشپړ ډول عملیاتي حالت ته راستون شي او د راتلونکي خرابوالي لپاره چمتو وي.

دلته د ازموینو لیست دی چې د هغه څه تشریح سره چې دوی یې کوي:

• فورک بم: د فورک بم په کارولو سره "د حافظې څخه بهر" رامینځته کوي.
• د فضا څخه بهر: هارډ ډرایو ډک دی. مګر ازموینه بلکه سمبولیک دی؛ د پام وړ بار سره چې د ازموینې پرمهال رامینځته کیږي ، PostgreSQL معمولا ناکام نه کیږي کله چې هارډ ډرایو ډک وي.
• Postgres-KILL: د قوماندې سره PostgreSQL وژني killall -KILL postgres.
• Postgres-STOP: د PostgreSQL کمانډ ځړول killall -STOP postgres.
• بندول: د کمانډ سره مجازی ماشین "ډیر انرژی" کوي VBoxManage controlvm "виртуалка" poweroff.
• Reset: د کمانډ سره مجازی ماشین ډیریږي VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: د امر سره د SBD شیطان وځنډوي killall -STOP sbd.
• بندول: د SSH له لارې مجازی ماشین ته کمانډ لیږي systemctl poweroff، سیسټم په ښه توګه بندیږي.
• بې لینک: د شبکې جلا کول، قومانده VBoxManage controlvm "виртуалка" setlinkstate1 off.

د ازموینې بشپړول یا د معیاري tmux کمانډ "kill-window" په کارولو سره Ctrl-b &, یا د "detach-client" کمانډ Ctrl-b د: پدې مرحله کې ازموینه پای ته رسیږي، tmux بندیږي، مجازی ماشینونه بند شوي.

د ازموینې په جریان کې پیژندل شوي ستونزې

• په همدې شیبه کې څارندوی شیطان sbd د مشاهده شوي ډیمونونو په بندولو کار کوي ، مګر د یخولو نه. او، د پایلې په توګه، نیمګړتیاوې چې یوازې د یخولو لامل کیږي Corosync и pacemakerخو ځوړند نه دی sbd... د چک لپاره Corosync مخکې لري PR#83 (په GitHub کې sbd)، تار ته ومنل شو د بادار. دوی ژمنه وکړه (په PR # 83 کې) چې د Pacemaker لپاره به ورته یو څه وي، زه هیله لرم چې له خوا ریډ هټ 8 به وکړي. مګر دا ډول "خرابي" قیاس دي او په اسانۍ سره په مصنوعي توګه کارول کیدی شي، د بیلګې په توګه، killall -STOP corosync، مګر هیڅکله په ریښتیني ژوند کې مه ګورئ.

• У pacemaker لپاره په نسخه کې CentOS 7 په غلطه توګه تنظیم شوی sync_timeout у د کورم وسیله، په پایله کښې که یو نوډ ناکام شو، د یو څه احتمال سره دویم نوډ هم بیا پیل شو، کوم چې ماسټر باید حرکت وکړي. د پراخیدو په واسطه درملنه کیږي sync_timeout у د کورم وسیله د ګمارنې پرمهال (په سکریپټ کې setup/setup1). دا تعدیل د پراختیا کونکو لخوا ونه منل شو pacemaker، پرځای یې دوی ژمنه وکړه چې زیربنا به په داسې ډول ډیزاین کړي (په یو څه نامعلوم راتلونکي کې) چې دا وخت به په اوتومات ډول محاسبه شي.

• که د ډیټابیس ترتیب دا مشخص کړي LC_MESSAGES (متن پیغامونه) یونیکوډ کارول کیدی شي، د بیلګې په توګه ru_RU.UTF-8، بیا په پیل کې پوسته په داسې چاپیریال کې چیرې چې ځای UTF-8 نه وي، په خالي چاپیریال کې ووایاست (دلته تېز جوړونکی+pgsqlms(paf) منډې کوي پوسته) ، بیا لاګ به د UTF-8 لیکونو پرځای د پوښتنې نښه ولري. د PostgreSQL پراختیا کونکي موافق ندي چې پدې قضیه کې څه وکړي. دا لګښت لري، تاسو باید نصب کړئ LC_MESSAGES=en_US.UTF-8 کله چې د ډیټابیس مثال تنظیم کول (جوړول)

• که د wal_receiver_timeout ټاکل شوی وي (د ډیفالټ له مخې دا 60s دی) ، نو د پوسټګری ایس کیو ایل - STOP ازموینې په جریان کې په ماسټر کې په tuchanka3 او tuchanka4 کلسترونو کې نقل کول د نوي ماسټر سره بیا نه نښلي. نقل هلته همغږي دی، نو نه یوازې غلام ودریږي، بلکې نوی بادار هم. د wal_receiver_timeout=0 په ترتیب کولو سره شاوخوا کار کوي کله چې د PostgreSQL تنظیم کول.

• ځینې ​​​​وختونه ما د فورک بومب ازموینې (د حافظې ډیر جریان) کې په PostgreSQL کې د نقل کنګل کول ولیدل. د فورک بومب وروسته ، ځینې وختونه غلامان ممکن له نوي ماسټر سره وصل نشي. ما دا یوازې په tuchanka3 او tuchanka4 کلسترونو کې لیدلی، چیرې چې ماسټر د همغږي نقل له امله کنګل شوی. ستونزه د اوږدې مودې (شاوخوا دوه ساعته) وروسته په خپله لاړه. د دې سمولو لپاره نورې څیړنې ته اړتیا ده. نښې نښانې د پخوانۍ بګ سره ورته دي، کوم چې د بل دلیل له امله رامنځته کیږي، مګر د ورته پایلو سره.

د کروګان عکس اخیستل شوی خرافاتي Art د لیکوال په اجازه:

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