د عصري معلوماتو مرکزونه په سلګونو فعال وسایل نصب شوي، چې د څارنې مختلف ډولونه پوښل شوي. مګر حتی یو مثالی انجنیر په لاس کې د کامل نظارت سره به وکولی شي یوازې په څو دقیقو کې د شبکې ناکامۍ ته په سمه توګه ځواب ووایی. د نیکسټ هپ 2020 کنفرانس کې په یوه راپور کې ، ما د DC شبکې ډیزاین میتودولوژي وړاندې کړه ، کوم چې یو ځانګړی ځانګړتیا لري - د ډیټا مرکز پخپله په ملی ثانیو کې روغ کیږي. په دقیق ډول، انجنیر په آرامۍ سره ستونزه حل کوي، پداسې حال کې چې خدمتونه په ساده ډول دا نه ګوري.
د ډیری شبکې انجنیرانو لپاره، د معلوماتو مرکز شبکه پیل کیږي، البته، د ToR سره، په ریک کې د سویچ سره. ToR معمولا دوه ډوله اړیکې لري. کوچني سرورونو ته ځي ، نور - د دوی څخه N ځله ډیر دي - د لومړۍ درجې نخاعې ته ځي ، دا د دې اپلینکس ته. اپلنکونه معمولا مساوي ګڼل کیږي، او د اپلنکونو تر منځ ترافیک د 5-ټوپل څخه د هش پراساس متوازن دی چې پکې پروټو، src_ip، dst_ip، src_port، dst_port شامل دي. دلته هیڅ حیرانتیا نشته.
بل، د پلان جوړښت څه ډول ښکاري؟ د لومړۍ درجې نخاعې یو له بل سره نه تړل کیږي، مګر د سپر سپینونو له لارې تړل کیږي. د X خط به د سپر اسپینونو لپاره مسؤل وي؛ دا تقریبا د کراس پیوستون په څیر دی.
او دا روښانه ده چې له بلې خوا، توري د لومړۍ درجې ټولو نخاعو سره تړلي دي. په دې انځور کې څه مهم دي؟ که موږ د ریک دننه تعامل ولرو، نو بیا تعامل، البته، د ToR له لارې ځي. که تعامل د ماډل دننه واقع کیږي، نو بیا تعامل د لومړۍ درجې نخاعې له لارې واقع کیږي. که تعامل انټرموډولر وي - لکه دلته ، ToR 1 او ToR 2 - نو تعامل به د لومړۍ او دوهمې کچې د نخاع څخه تیریږي.
په تیوري کې، دا ډول جوړښت په اسانۍ سره د توزیع وړ دی. که موږ د بندر ظرفیت ولرو، د معلوماتو مرکز کې اضافي ځای او مخکې ایښودل شوي فایبر، نو د لینونو شمیر تل لوړ کیدی شي، په دې توګه د سیسټم ټول ظرفیت لوړیږي. دا په کاغذ باندې ترسره کول خورا اسانه دي. په ژوند کې به داسې وي. مګر د نن ورځ کیسه د دې په اړه نه ده.
زه غواړم چې سمې پایلې ته ورسیږم. موږ د معلوماتو مرکز دننه ډیری لارې لرو. دوی په مشروط ډول خپلواک دي. د معلوماتو مرکز دننه یوه لاره یوازې د ToR دننه ممکنه ده. د ماډل دننه، موږ د لارو شمیر د لینونو شمیر سره مساوي لرو. د ماډلونو تر مینځ د لارو شمیر د الوتکو شمیر او په هره الوتکه کې د سپر سپینونو شمیر سره مساوي دی. د دې روښانه کولو لپاره ، د پیمانې احساس ترلاسه کولو لپاره ، زه به هغه شمیرې ورکړم چې د Yandex ډیټا مرکزونو څخه یو لپاره اعتبار لري.
اته الوتکې لري، هره الوتکه 32 سپر سپین لري. د پایلې په توګه، دا معلومه شوه چې د ماډل دننه اته لارې شتون لري، او د انټرموډول تعامل سره لا دمخه د دوی 256 شتون لري.
دا دی، که موږ د کوک بک ته وده ورکوو، هڅه کوو چې زده کړو چې څنګه د غلطۍ زغمونکي ډیټا مرکزونه جوړ کړو چې خپل ځان روغ کړي، بیا پلانر جوړښت سم انتخاب دی. دا د اندازه کولو ستونزه حل کوي، او په تیوري کې دا اسانه ده. ډیری خپلواکې لارې شتون لري. پوښتنه پاتې ده: دا ډول جوړښت څنګه له ناکامیو څخه ژوندی پاتې کیږي؟ مختلف ناکامۍ شتون لري. او موږ به اوس پدې اړه بحث وکړو.
اجازه راکړئ زموږ یو سپر سپین "ناروغ شي". دلته زه د دوه الوتکو جوړښت ته راستون شوم. موږ به د دې سره د مثال په توګه پاتې شو ځکه چې دا به په اسانۍ سره وګورو چې د لږو خوځنده برخو سره څه پیښیږي. اجازه راکړئ چې X11 ناروغ شي. دا به څنګه په خدماتو اغیزه وکړي چې د معلوماتو مرکزونو کې ژوند کوي؟ ډیری پدې پورې اړه لري چې ناکامي واقعیا څه ډول ښکاري.
که ناکامي ښه وي، دا د ورته BFD د اتوماتیک کچې کې نیول کیږي، اتوماتیک په خوښۍ سره ستونزې پیدا کوي او ستونزه جلا کوي، بیا هرڅه سم دي. موږ ډیری لارې لرو، ټرافيک په سمدستي توګه بدیل لارو ته لیږدول کیږي، او خدمات به هیڅ پام ونه کړي. دا یو ښه سکریپټ دی.
یو بد سناریو هغه ده که چیرې موږ دوامداره زیانونه ولرو، او اتومات ستونزه نه ګوري. د دې لپاره چې پوه شي چې دا څنګه په غوښتنلیک اغیزه کوي، موږ باید لږ وخت په دې بحث وکړو چې TCP څنګه کار کوي.
زه امید لرم چې زه د دې معلوماتو سره هیڅوک حیران نه کړم: TCP د لیږد تصدیق پروتوکول دی. دا، په ساده حالت کې، لیږونکی دوه کڅوړې لیږي او په دوی باندې مجموعي اکک ترلاسه کوي: "ما دوه پاکټونه ترلاسه کړل."
له هغې وروسته، هغه به دوه نور کڅوړې واستوي، او وضعیت به تکرار شي. زه د یو څه ساده کولو لپاره دمخه بخښنه غواړم. دا سناریو سمه ده که کړکۍ (په الوتنه کې د کڅوړو شمیر) دوه وي. البته، په عمومي صورت کې دا ضروري نه ده. مګر د کړکۍ اندازه د پاکټ فارورډ کولو شرایطو اغیزه نه کوي.
څه پیښیږي که چیرې موږ پیکټ 3 له لاسه ورکړو؟ په دې حالت کې، ترلاسه کوونکی به 1، 2 او 4 کڅوړې ترلاسه کړي. او هغه به په ښکاره ډول د SACK اختیار په کارولو سره لیږونکي ته ووایي: "تاسو پوهیږئ، درې رسیدلي، مګر منځنی ورک شوی." هغه وايي، "اک 2، ساک 4."
پدې شیبه کې ، لیږونکی پرته له کومې ستونزې څخه هغه پاکټ تکراروي چې ورک شوی و.
مګر که په کړکۍ کې وروستی کڅوړه له لاسه ورکړي، وضعیت به په بشپړ ډول توپیر وګوري.
ترلاسه کونکی لومړی درې کڅوړې ترلاسه کوي او لومړی یې انتظار پیل کوي. د لینکس کرنل په TCP سټیک کې د ځینې اصلاح کولو څخه مننه ، دا به د جوړه شوي کڅوړې انتظار وکړي پرته لدې چې بیرغونه په څرګنده توګه په ګوته کړي چې دا وروستی پاکټ دی یا ورته ورته. دا به تر هغه وخته پورې انتظار وکړي چې د ACK ځنډیدلي وخت پای ته ورسیږي او بیا به په لومړیو دریو کڅوړو کې اعتراف واستوي. مګر اوس به لیږونکي انتظار وکړي. هغه نه پوهیږي چې څلورم کڅوړه ورکه شوې یا د رسیدو په حال کې ده. او د دې لپاره چې شبکه له اندازې زیاته نه شي، دا به هڅه وکړي چې د یوې څرګندې نښې انتظار وکړي چې پاکټ ورک شوی، یا د RTO وخت پای ته رسیدو لپاره.
د RTO وخت پای څه شی دی؟ دا د RTT اعظمي حد دی چې د TCP سټیک لخوا محاسبه کیږي او ځینې ثابت. دا کوم ډول ثابت دی، موږ به اوس بحث وکړو.
مګر مهمه خبره دا ده چې که موږ بیا بدبخته شو او څلورم پیکټ بیا ورک شو نو RTO دوه چنده کیږي. دا دی، هره ناکامه هڅه د وخت پای دوه چنده کولو معنی لري.
اوس راځئ وګورو چې دا اساس څه شی دی. په ډیفالټ کې، لږترلږه RTO 200 ms دی. دا د ډیټا کڅوړو لپاره لږترلږه RTO دی. د SYN پاکټونو لپاره دا توپیر لري، 1 ثانیه. لکه څنګه چې تاسو لیدلی شئ ، حتی د پاکټونو د بیا لیږلو لومړۍ هڅه به د ډیټا مرکز دننه د RTT څخه 100 ځله ډیر وخت ونیسي.
اوس راځو خپل سناریو ته. د خدمت سره څه تیریږي؟ خدمت د کڅوړو له لاسه ورکولو پیل کوي. اجازه راکړئ چې خدمت په لومړي سر کې په مشروط ډول خوشحاله وي او د کړکۍ په مینځ کې یو څه له لاسه ورکړي، بیا دا یو SACK ترلاسه کوي او هغه پاکټونه بیرته راولي چې ورک شوي.
مګر که بد قسمت خپل ځان تکرار کړي، نو موږ یو RTO لرو. دلته څه مهم دي؟ هو، موږ زموږ په شبکه کې ډیری لارې لرو. مګر د یو ځانګړي TCP پیوستون د TCP ترافیک به د ورته مات شوي سټیک څخه تیریږي. د بسته بندۍ ضایعات، په دې شرط چې زموږ دا جادویی X11 پخپله بهر نه ځي، هغه سیمو ته د ټرافیک جریان لامل نه کوي چې ستونزې نلري. موږ هڅه کوو چې د ورته مات شوي سټیک له لارې کڅوړه وړاندې کړو. دا د کیسکیډینګ ناکامۍ لامل کیږي: د ډیټا سنټر د متقابل غوښتنلیکونو سیټ دی ، او د دې ټولو غوښتنلیکونو ځینې TCP اړیکې خرابیدل پیل کوي - ځکه چې سپر سپین ټول هغه غوښتنلیکونه اغیزه کوي چې د ډیټا مرکز دننه شتون لري. لکه څنګه چې متل دی: که تاسو په آس بوټ نه وای اچولی، آس به لنګ شو. آس لنګ شو - راپور ندی ورکړل شوی؛ راپور نه دی سپارل شوی - موږ جګړه له لاسه ورکړه. یوازې دلته شمیرنه په ثانیو کې ده له هغه شیبې څخه چې ستونزه د تخریب مرحلې ته رامینځته کیږي چې خدمات یې احساس کوي. دا پدې مانا ده چې کاروونکي ممکن یو څه له لاسه ورکړي.
دوه کلاسیک حلونه شتون لري چې یو بل بشپړوي. لومړی هغه خدمتونه دي چې هڅه کوي ډډونه دننه کړي او دا ستونزه حل کړي: "راځئ چې په TCP سټیک کې یو څه ټیک کړو. راځئ چې د داخلي روغتیا چکونو سره د غوښتنلیک په کچه یا د اوږدمهاله TCP ناستې وخت پای ته ورسوو. ستونزه دا ده چې دا ډول حلونه: الف) په هیڅ ډول اندازه نه کوي؛ b) په خورا کمزوري توګه چک شوي. دا دی ، حتی که چیرې خدمت په ناڅاپي ډول د TCP سټیک په داسې طریقه تنظیم کړي چې دا غوره کړي ، لومړی ، دا امکان نلري چې د ټولو غوښتنلیکونو او ټولو ډیټا مرکزونو لپاره پلي شي ، او دوهم ، ډیری احتمال ، دا به نه پوهیږي چې دا ترسره شوی. په سمه توګه، او څه نه. دا دی، دا کار کوي، مګر دا خراب کار کوي او اندازه نه کوي. او که چیرې د شبکې ستونزه وي، څوک یې ملامت دی؟ البته، NOC. NOC څه کوي؟
ډیری خدمتونه پدې باور دي چې د NOC کار کې داسې څه پیښیږي. مګر د ریښتیني کیدو لپاره ، نه یوازې دا.
په کلاسیک سکیم کې NOC د ډیری څارنې سیسټمونو په پراختیا کې بوخت دی. دا دواړه تور بکس او سپین بکس نظارت دي. د تور بکس د نخاعې څارنې د مثال په اړه الکساندر کلیمینکو په وروستي راتلونکي هپ کې. په هرصورت، دا څارنه کار کوي. مګر حتی مثالی څارنه به د وخت ځنډ ولري. معمولا دا څو دقیقې وي. وروسته له دې چې دا له مینځه ولاړه، انجنیران وخت ته اړتیا لري چې خپل عملیات دوه ځله وګوري، ستونزه محلي کړي او بیا د ستونزې ساحه وژني. په دې توګه، په غوره حالت کې، د ستونزې درملنه 5 دقیقې وخت نیسي، په بدترین حالت کې، 20 دقیقې، که دا سمدستي څرګنده نه وي چې زیانونه چیرته پیښیږي. دا روښانه ده چې دا ټول وخت - 5 یا 20 دقیقې - زموږ خدمات به زیان ته دوام ورکړي، کوم چې شاید ښه نه وي.
تاسو واقعیا څه ترلاسه کول غواړئ؟ موږ ډیری لارې لرو. او ستونزې په دقیق ډول رامینځته کیږي ځکه چې د TCP جریان چې بدبخته دي د ورته لارې کارولو ته دوام ورکوي. موږ یو څه ته اړتیا لرو چې موږ ته اجازه راکوي چې په یو واحد TCP اتصال کې ډیری لارې وکاروو. داسې ښکاري چې موږ د حل لاره لرو. دلته TCP شتون لري، کوم چې د ملټي پاټ TCP په نوم یادیږي، دا د څو لارو لپاره TCP دی. ریښتیا ، دا د بشپړ مختلف کار لپاره رامینځته شوی - د سمارټ فونونو لپاره چې ډیری شبکې وسیلې لري. د لیږد اعظمي کولو یا لومړني / بیک اپ حالت رامینځته کولو لپاره ، یو میکانیزم رامینځته شوی چې غوښتنلیک ته په شفاف ډول ډیری تارونه (غونډې) رامینځته کوي او تاسو ته اجازه درکوي د ناکامۍ په صورت کې د دوی ترمینځ تیر کړئ. یا، لکه څنګه چې ما وویل، سلسله اعظمي کړئ.
مګر دلته یو اهمیت شتون لري. د پوهیدو لپاره چې دا څه دي، موږ باید وګورو چې تارونه څنګه تاسیس شوي.
تارونه په ترتیب سره نصب شوي. لومړی تار لومړی نصب شوی. ورپسې تارونه بیا د کوکي په کارولو سره تنظیم شوي چې دمخه یې په دې تار کې موافقه شوې. او دلته ستونزه ده.
ستونزه دا ده چې که لومړی تار ځان جوړ نه کړي، دویمه او دریمه موضوع به هیڅکله هم رامنځته نشي. دا دی، ملټيپټ TCP په لومړي جریان کې د SYN پاکټ ضایع حل نه کوي. او که SYN ورک شي، ملټي پاټ TCP په منظم TCP بدلیږي. دا پدې مانا ده چې د ډیټا مرکز چاپیریال کې دا به موږ سره په فابریکه کې د زیانونو ستونزې حل کولو کې مرسته ونکړي او د ناکامۍ په صورت کې د ډیری لارو کارول زده کړي.
څه شی زموږ سره مرسته کولی شي؟ ستاسو څخه ځینو دمخه د سرلیک څخه اټکل کړی چې زموږ په راتلونکي کیسه کې یو مهم ساحه به د IPv6 فلو لیبل سرلیک ساحه وي. په حقیقت کې، دا هغه ساحه ده چې په v6 کې ښکاري، دا په v4 کې نه ده، دا 20 بټونه نیسي، او د اوږدې مودې لپاره د دې کارولو په اړه جنجال شتون لري. دا خورا په زړه پوری دی - شخړې شتون درلود ، یو څه په RFC کې ټاکل شوي و ، او په ورته وخت کې د لینکس کرنل کې پلي کول څرګند شوي ، کوم چې هیڅ ځای نه و مستند شوی.
زه تاسو ته بلنه درکوم چې زما سره لږ تحقیق وکړئ. راځئ یو نظر وګورو چې په تیرو څو کلونو کې د لینکس کرنل کې څه پیښیږي.
کال 2014 د یو لوی او درناوي شرکت انجینر د لینکس کرنل فعالیت ته د ساکټ هش کې د جریان لیبل ارزښت انحصار اضافه کوي. دوی دلته د څه کولو هڅه کوله؟ دا د RFC 6438 پورې اړه لري، کوم چې لاندې مسلې بحث کړی. د معلوماتو مرکز دننه، IPv4 ډیری وختونه د IPv6 پاکټونو کې پوښل کیږي، ځکه چې فابریکه پخپله IPv6 ده، مګر IPv4 باید په یو ډول بهر ورکړل شي. د اوږدې مودې لپاره د سویچونو سره ستونزې وې چې نشي کولی TCP یا UDP ته د رسیدو لپاره د دوه IP سرلیکونو لاندې وګوري او هلته src_ports ، dst_ports ومومي. دا معلومه شوه چې هش، که تاسو لومړی دوه IP سرلیکونه وګورئ، تقریبا ثابت شوي. د دې څخه د مخنیوي لپاره، د دې لپاره چې د دې پوښل شوي ټرافیک توازن په سمه توګه کار وکړي، وړاندیز شوی و چې د 5-tuple encapsulated پاکټ هش د فلو لیبل ساحې ارزښت ته اضافه کړي. نږدې ورته شی د نورو انکیپسولیشن سکیمونو لپاره ترسره شوي ، د UDP لپاره ، د GRE لپاره ، وروستی د GRE کلیدي ساحه کارولې. یو ډول یا بل، دلته اهداف روښانه دي. او لږترلږه په هغه وخت کې دوی ګټور وو.
په 2015 کې، یو نوی پیچ د ورته درناوي انجنیر څخه راځي. هغه ډیر په زړه پوری دی. دا لاندې وايي - موږ به د منفي روټینګ پیښې په صورت کې هش تصادفي کړو. د منفي روټینګ پیښه څه ده؟ دا هغه RTO دی چې موږ دمخه بحث وکړ، دا د کړکۍ د پای له لاسه ورکول یوه پیښه ده چې واقعیا منفي ده. ریښتیا، دا نسبتا ستونزمنه ده چې اټکل وکړو چې دا دی.
2016، یو بل نامتو شرکت، هم لوی. دا وروستي کرچونه جلا کوي او داسې جوړوي چې هش، کوم چې موږ مخکې تصادفي جوړ کړی و، اوس د هر SYN بیا لیږد لپاره او د هر RTO وخت پای ته رسیدو وروسته بدلیږي. او په دې لیک کې، د لومړي او وروستي ځل لپاره، وروستی هدف بیان شوی - د دې لپاره چې ډاډ ترلاسه شي چې ټرافيک د ضایعاتو یا چینل کنجشن په صورت کې د دې وړتیا لري چې په نرمه توګه بیرته راستانه شي او ډیری لارې وکاروي. البته، له دې وروسته ډیری خپرونې وې، تاسو کولی شئ په اسانۍ سره ومومئ.
که څه هم نه، تاسو نشئ کولی، ځکه چې پدې موضوع کې هیڅ یوه خپرونه نه ده شوې. مګر موږ پوهیږو!
او که تاسو په بشپړ ډول نه پوهیږئ چې څه شوي، زه به تاسو ته اوس ووایم.
څه وشول، د لینکس کرنل کې کوم فعالیت اضافه شو؟ txhash د هرې RTO پیښې وروسته تصادفي ارزښت ته بدلون ورکوي. دا د روټ کولو خورا منفي پایله ده. هش په دې txhash پورې اړه لري، او د جریان لیبل د skb هش پورې اړه لري. دلته د دندو په اړه ځینې محاسبې شتون لري؛ ټول توضیحات په یو سلایډ کې نشي کیدی. که څوک لیواله وي، تاسو کولی شئ د کرنل کوډ له لارې لاړ شئ او وګورئ.
دلته څه مهم دي؟ د جریان لیبل ساحې ارزښت د هر RTO وروسته تصادفي شمیر ته بدلیږي. دا څنګه زموږ بدبختانه TCP جریان اغیزه کوي؟
که چیرې SACK واقع شي، هیڅ شی نه بدلیږي ځکه چې موږ هڅه کوو چې یو ورک شوی پیکټ بیا واستوو. تر دې دمه ډیر ښه.
مګر د RTO په حالت کې، په دې شرط چې موږ په ToR کې د هش فنکشن ته د جریان لیبل اضافه کړي، ټرافیک ممکن بله لاره ونیسي. او هرڅومره چې لاینونه ډیر وي ، د دې چانس ډیر دی چې دا به یوه لاره ومومي چې په ځانګړي وسیله کې د ناکامۍ لخوا اغیزه ونلري.
یوه ستونزه پاتې ده - RTO. البته، بله لاره شتون لري، مګر په دې کې ډیر وخت ضایع کیږي. 200 ms ډیر دی. یوه ثانیه په بشپړه توګه وحشي ده. مخکې، ما د وخت په اړه خبرې وکړې چې خدمتونه ترتیب شوي. نو ، یوه ثانیه د وخت پای دی ، کوم چې معمولا د غوښتنلیک په کچه د خدماتو لخوا تنظیم شوی ، او پدې کې به خدمت حتی نسبتا سم وي. سربیره پردې ، زه تکراروم ، د عصري ډیټا مرکز دننه اصلي RTT شاوخوا 1 ملی ثانیه دی.
تاسو د RTO مهال ویش سره څه کولی شئ؟ مهال ویش، کوم چې د ډیټا پاکټونو له لاسه ورکولو په صورت کې د RTO لپاره مسؤل دی، د کاروونکي ځای څخه نسبتا په اسانۍ سره تنظیم کیدی شي: د IP کارونې شتون لري، او د هغې یو پیرامیټر ورته rto_min لري. د RTO په پام کې نیولو سره، البته، باید په نړیواله کچه نه تنظیم شي، مګر د ورکړل شوي مخکینیو لپاره، دا ډول میکانیزم د کار وړ ښکاري.
ریښتیا، د SYN_RTO سره هرڅه یو څه خراب دي. دا په طبيعي توګه په نخښه شوی دی. دانه د 1 ثانیې ثابت ارزښت لري، او دا دی. تاسو نشئ کولی د کارونکي ځای څخه هلته ورسیږئ. یوازې یوه لاره ده.
eBPF د ژغورنې لپاره راځي. د ساده کولو لپاره، دا کوچني C پروګرامونه دي، دوی د کرنل سټیک او TCP سټیک په اجرا کولو کې په مختلفو ځایونو کې په هکونو کې داخل کیدی شي، چې تاسو کولی شئ ډیر لوی شمیر ترتیبات بدل کړئ. په عموم کې، eBPF یو اوږد مهاله رجحان دی. د لسګونو نوي sysctl پیرامیټونو د پرې کولو او د IP افادیت پراخولو پرځای، حرکت د eBPF په لور روان دی او خپل فعالیت پراخوي. د eBPF په کارولو سره، تاسو کولی شئ په متحرک ډول د کنجشن کنټرولونه او نور مختلف TCP ترتیبات بدل کړئ.
مګر دا زموږ لپاره مهم دی چې دا د SYN_RTO ارزښتونو بدلولو لپاره کارول کیدی شي. برسېره پر دې، په عامه توګه ځړول شوي مثال شتون لري: . دلته څه شوي دي؟ مثال کار کوي، مګر پخپله خورا سخت دی. دلته داسې انګیرل کیږي چې د ډیټا مرکز دننه موږ لومړی 44 بټونه پرتله کوو؛ که دوی سره سمون ولري، نو موږ د ډیټا مرکز دننه یو. او پدې حالت کې موږ د SYN_RTO وخت پای ارزښت 4ms ته بدلوو. ورته کار په ډیر ښه ډول ترسره کیدی شي. مګر دا ساده مثال ښیي چې دا یو) ممکن دی؛ ب) نسبتا ساده.
موږ لا دمخه څه پوهیږو؟ دا حقیقت چې د الوتکې جوړښت د اندازه کولو لپاره اجازه ورکوي، دا زموږ لپاره خورا ګټور وي کله چې موږ په ToR کې د جریان لیبل فعال کړو او د ستونزې ساحې شاوخوا جریان کولو وړتیا ترلاسه کړو. د RTO او SYN-RTO ارزښتونو کمولو غوره لاره د eBPF پروګرامونو کارول دي. پوښتنه پاتې ده: ایا د توازن لپاره د جریان لیبل کارول خوندي دي؟ او دلته یو اهمیت شتون لري.
فرض کړئ چې تاسو په خپل شبکه کې یو خدمت لرئ چې په هر کاسټ کې ژوند کوي. له بده مرغه، زه وخت نلرم چې د کوم کاسټ په اړه توضیحاتو ته لاړ شم، مګر دا د ورته IP پتې له لارې د لاسرسي مختلف فزیکي سرورونو سره ویشل شوی خدمت دی. او دلته یو احتمالي ستونزه ده: د RTO پیښه نه یوازې هغه وخت رامینځته کیدی شي کله چې ترافیک د جامو له لارې تیریږي. دا د TOR بفر په کچه هم پیښ کیدی شي: کله چې د انکاسټ پیښه پیښیږي ، دا حتی په کوربه کې پیښ کیدی شي کله چې کوربه یو څه توزیع کړي. کله چې د RTO پیښه پیښیږي او دا د جریان لیبل بدلوي. په دې حالت کې، ټرافیک کولی شي بل هر ډول مثال ته لاړ شي. راځئ فرض کړو چې دا یو دولتي هر کاسټ دی، دا د ارتباط حالت لري - دا کیدای شي د L3 بیلانسر یا کوم بل خدمت وي. بیا یوه ستونزه رامینځته کیږي ، ځکه چې د RTO وروسته د TCP کنیکشن سرور ته راځي ، کوم چې د دې TCP اتصال په اړه هیڅ نه پوهیږي. او که موږ د کوم کاسټ سرورونو ترمینځ دولتي شریک نه لرو ، نو دا ډول ترافیک به راټیټ شي او د TCP پیوستون به مات شي.
تاسو دلته څه کولی شئ؟ ستاسو په کنټرول شوي چاپیریال کې ، چیرې چې تاسو د جریان لیبل توازن فعال کوئ ، تاسو اړتیا لرئ د جریان لیبل ارزښت ثبت کړئ کله چې کوم کاسټ سرورونو ته لاسرسی ومومئ. ترټولو اسانه لاره دا ده چې دا د ورته eBPF برنامې له لارې ترسره کړئ. مګر دلته یو خورا مهم ټکی دی - څه باید وکړئ که تاسو د ډیټا سنټر شبکه نه چلوئ ، مګر د مخابراتو آپریټر یاست؟ دا ستاسو ستونزه هم ده: د جونیپر او اریسټا ځینې نسخو سره پیل کول ، دوی د ډیفالټ په واسطه د دوی د هش افعالو کې د جریان لیبل شاملوي - په ریښتیا ، د هغه دلیل لپاره چې ما ته روښانه نده. دا ممکن تاسو ته د دې لامل شي چې ستاسو له شبکې څخه تیریدونکي کاروونکو څخه د TCP اړیکې پریږدي. نو زه په کلکه وړاندیز کوم چې دلته ستاسو د راوټر تنظیمات چیک کړئ.
په یوه لاره یا بل ډول، داسې ښکاري چې موږ چمتو یو چې تجربو ته لاړ شو.
کله چې موږ په ToR کې د جریان لیبل فعال کړ، د eBPF اجنټ یې چمتو کړ، کوم چې اوس په کوربه کې ژوند کوي، موږ پریکړه وکړه چې راتلونکي لوی ناکامۍ ته انتظار ونه کړو، مګر کنټرول شوي چاودنې ترسره کړو. موږ ToR واخیست، کوم چې څلور اپلنکونه لري، او په یوه کې یې ډراپونه ترتیب کړل. دوی یو قاعده جوړه کړه او ویې ویل - اوس تاسو ټول کڅوړې له لاسه ورکوئ. لکه څنګه چې تاسو په ښي خوا کې لیدلی شئ، موږ د هر پاکټ څارنه لرو، کوم چې 75٪ ته راټیټ شوی، دا د 25٪ پاکټونه ورک شوي. په ښي خوا کې د خدماتو ګرافونه د دې ToR شاته ژوند کوي. په لازمي ډول ، دا د ریک دننه سرورونو سره د انٹرفیس ترافیک ګرافونه دي. لکه څنګه چې تاسو لیدلی شئ، دوی حتی ښکته ډوب شوي. ولې دوی ټیټ شوي - د 25٪ لخوا نه، مګر په ځینو مواردو کې 3-4 ځله؟ که د TCP پیوستون بدمرغه وي، دا د مات شوي جنکشن له لارې د رسیدو هڅه کوي. دا په DC کې دننه د خدماتو د عادي چلند لخوا خرابیږي - د یو کارونکي غوښتنې لپاره ، داخلي خدماتو ته N غوښتنې رامینځته کیږي ، او ځواب به کارونکي ته لاړ شي یا به کله چې ټولې ډیټا سرچینې ځواب ورکړي ، یا کله چې په غوښتنلیک کې وخت پای ته ورسیږي. کچه، کوم چې لاهم تنظیم کولو ته اړتیا لري. يعنې هر څه ډېر، ډېر بد دي.
اوس ورته تجربه، مګر د جریان لیبل ارزښت سره فعال شوی. لکه څنګه چې تاسو لیدلی شئ ، په ښي خوا کې زموږ د بیچ نظارت د ورته 25٪ لخوا راټیټ شوی. دا په بشپړ ډول سم دی، ځکه چې دا د بیا لیږدولو په اړه هیڅ نه پوهیږي، دا پاکټونه لیږي او په ساده ډول د سپارل شوي او ورک شوي کڅوړو شمیر تناسب حسابوي.
او په ښي خوا کې د خدماتو مهال ویش دی. تاسو به دلته د ستونزې لرونکي ګډ اغیز ونه مومئ. په ورته ملی ثانیو کې، ټرافيک د ستونزې له ساحې څخه درې پاتې اپلنکونو ته تیریږي چې د ستونزې له امله اغیزمن شوي ندي. موږ یوه شبکه لرو چې پخپله درملنه کوي.
دا زما وروستی سلایډ دی، د لنډیز کولو وخت. اوس، زه امید لرم چې تاسو پوهیږئ چې څنګه د ځان شفاهي معلوماتو مرکز شبکه جوړه کړئ. تاسو اړتیا نلرئ د لینکس کرنل آرشیف ته لاړشئ او هلته ځانګړي پیچونه وګورئ؛ تاسو پوهیږئ چې پدې قضیه کې د فلو لیبل ستونزه حل کوي ، مګر تاسو اړتیا لرئ دې میکانیزم ته په دقت سره مراجعه وکړئ. او زه یوځل بیا ټینګار کوم چې که تاسو د مخابراتو آپریټر یاست ، نو تاسو باید د فلو لیبل د هش فنکشن په توګه ونه کاروئ ، که نه نو تاسو به د خپلو کاروونکو ناستې ګډوډ کړئ.
د شبکې انجینران باید د مفهوم بدلون څخه تیر شي: شبکه د ToR سره نه پیل کیږي، نه د شبکې وسیله سره، مګر د کوربه سره. د پام وړ مثال دا دی چې څنګه موږ د RTO بدلولو او د هر کاسټ خدماتو په لور د جریان لیبل حل کولو لپاره دواړه eBPF کاروو.
د جریان لیبل میخانیکونه یقینا د کنټرول شوي اداري برخې کې د نورو غوښتنلیکونو لپاره مناسب دي. دا کیدی شي د ډیټا مرکزونو ترمینځ ترافیک وي ، یا تاسو کولی شئ دا ډول میکانیکونه په ځانګړي ډول د وتلو ترافیک اداره کولو لپاره وکاروئ. مګر زه به تاسو ته پدې اړه ووایم، زه هیله لرم، بل ځل. ستاسو د پاملرنې څخه ډیره مننه.
سرچینه: www.habr.com