Yandex.Cloud میں نیٹ ورک لوڈ بیلنسر کا فن تعمیر

ہیلو، میں سرگئی ایلانتسیف ہوں، میں ترقی کرتا ہوں۔ نیٹ ورک لوڈ بیلنسر Yandex.Cloud میں۔ اس سے پہلے، میں نے Yandex پورٹل کے لیے L7 بیلنسر کی ترقی کی قیادت کی تھی - ساتھیوں نے مذاق کیا کہ میں جو بھی کرتا ہوں، یہ ایک بیلنسر ثابت ہوتا ہے۔ میں Habr کے قارئین کو بتاؤں گا کہ کلاؤڈ پلیٹ فارم میں بوجھ کو کیسے منظم کیا جائے، ہم اس مقصد کو حاصل کرنے کے لیے مثالی ٹول کے طور پر کیا دیکھتے ہیں، اور ہم اس ٹول کی تعمیر کی طرف کیسے بڑھ رہے ہیں۔

سب سے پہلے، آئیے کچھ اصطلاحات متعارف کراتے ہیں:

• VIP (ورچوئل آئی پی) - بیلنسر آئی پی ایڈریس
• سرور، بیک اینڈ، مثال - ایک ایپلیکیشن چلانے والی ایک ورچوئل مشین
• RIP (Real IP) - سرور IP ایڈریس
• ہیلتھ چیک - سرور کی تیاری کی جانچ کرنا
• دستیابی زون، AZ - ڈیٹا سینٹر میں الگ تھلگ انفراسٹرکچر
• علاقہ - مختلف AZs کی یونین

لوڈ بیلنسرز تین اہم کاموں کو حل کرتے ہیں: وہ توازن خود انجام دیتے ہیں، سروس کی غلطی برداشت کو بہتر بناتے ہیں، اور اسکیلنگ کو آسان بناتے ہیں۔ خودکار ٹریفک مینجمنٹ کے ذریعے غلطی کی رواداری کو یقینی بنایا جاتا ہے: بیلنسر ایپلی کیشن کی حالت پر نظر رکھتا ہے اور بیلنسنگ مثالوں سے خارج ہوتا ہے جو لائیونس چیک کو پاس نہیں کرتے ہیں۔ اسکیلنگ کو تمام مثالوں میں بوجھ کو یکساں طور پر تقسیم کرنے کے ساتھ ساتھ فلائی پر مثالوں کی فہرست کو اپ ڈیٹ کرکے یقینی بنایا جاتا ہے۔ اگر توازن کافی حد تک یکساں نہیں ہے، تو کچھ مثالوں کو ایک بوجھ ملے گا جو ان کی صلاحیت کی حد سے زیادہ ہے، اور سروس کم قابل اعتماد ہو جائے گی۔

لوڈ بیلنس کو اکثر OSI ماڈل کی پروٹوکول پرت کے ذریعہ درجہ بندی کیا جاتا ہے جس پر یہ چلتا ہے۔ کلاؤڈ بیلنسر TCP سطح پر کام کرتا ہے، جو چوتھی تہہ، L4 سے مساوی ہے۔

آئیے کلاؤڈ بیلنس آرکیٹیکچر کے ایک جائزہ پر چلتے ہیں۔ ہم آہستہ آہستہ تفصیل کی سطح میں اضافہ کریں گے۔ ہم بیلنس کے اجزاء کو تین طبقات میں تقسیم کرتے ہیں۔ کنفگ پلین کلاس صارف کے تعامل کے لیے ذمہ دار ہے اور سسٹم کی ہدف حالت کو اسٹور کرتی ہے۔ کنٹرول طیارہ سسٹم کی موجودہ حالت کو اسٹور کرتا ہے اور ڈیٹا پلین کلاس سے سسٹمز کا انتظام کرتا ہے، جو کلائنٹس سے آپ کی مثالوں تک ٹریفک پہنچانے کے لیے براہ راست ذمہ دار ہیں۔

ڈیٹا ہوائی جہاز

ٹریفک کا اختتام مہنگے آلات پر ہوتا ہے جنہیں بارڈر روٹرز کہتے ہیں۔ غلطی کی برداشت کو بڑھانے کے لیے، اس طرح کے کئی آلات ایک ڈیٹا سینٹر میں بیک وقت کام کرتے ہیں۔ اس کے بعد، ٹریفک بیلنسرز کو جاتا ہے، جو کلائنٹس کے لیے BGP کے ذریعے تمام AZs کو کسی بھی کاسٹ آئی پی ایڈریس کا اعلان کرتے ہیں۔ 

ٹریفک ECMP کے ذریعے منتقل کیا جاتا ہے - یہ ایک روٹنگ حکمت عملی ہے جس کے مطابق ہدف تک کئی یکساں اچھے راستے ہوسکتے ہیں (ہمارے معاملے میں، ہدف منزل کا IP پتہ ہوگا) اور پیکٹ ان میں سے کسی کے ساتھ بھیجا جا سکتا ہے۔ ہم مندرجہ ذیل اسکیم کے مطابق کئی دستیابی زونز میں کام کی حمایت کرتے ہیں: ہم ہر زون میں ایک پتے کی تشہیر کرتے ہیں، ٹریفک قریب ترین تک جاتی ہے اور اپنی حدود سے باہر نہیں جاتی ہے۔ بعد میں پوسٹ میں ہم مزید تفصیل سے دیکھیں گے کہ ٹریفک کا کیا ہوتا ہے۔

ترتیب طیارہ

 
کنفگ پلین کا کلیدی جزو API ہے، جس کے ذریعے بیلنسرز کے ساتھ بنیادی آپریشن کیے جاتے ہیں: مثالوں کی تشکیل، حذف، تبدیلی، صحت کی جانچ کے نتائج حاصل کرنا، وغیرہ۔ ایک طرف، یہ ایک REST API ہے، اور دوسری طرف دوسرے، ہم کلاؤڈ میں اکثر فریم ورک gRPC استعمال کرتے ہیں، لہذا ہم REST کو gRPC میں "ترجمہ" کرتے ہیں اور پھر صرف gRPC استعمال کرتے ہیں۔ کوئی بھی درخواست غیر مطابقت پذیر ٹاسک کی ایک سیریز کی تخلیق کا باعث بنتی ہے جو Yandex.Cloud کارکنوں کے مشترکہ پول پر انجام دیے جاتے ہیں۔ کام اس طرح لکھے جاتے ہیں کہ انہیں کسی بھی وقت معطل کیا جا سکتا ہے اور پھر دوبارہ شروع کیا جا سکتا ہے۔ یہ اسکیل ایبلٹی، ریپیٹ ایبلٹی اور آپریشنز کی لاگنگ کو یقینی بناتا ہے۔

نتیجے کے طور پر، API سے کام بیلنسر سروس کنٹرولر سے درخواست کرے گا، جو Go میں لکھا ہوا ہے۔ یہ بیلنسرز کو شامل اور ہٹا سکتا ہے، بیک اینڈ اور سیٹنگز کی تشکیل کو تبدیل کر سکتا ہے۔ 

سروس اپنی حالت Yandex ڈیٹا بیس میں اسٹور کرتی ہے، ایک تقسیم شدہ منظم ڈیٹا بیس جسے آپ جلد ہی استعمال کر سکیں گے۔ Yandex.Cloud میں، جیسا کہ ہم پہلے ہی ہیں۔ کہا، کتے کے کھانے کا تصور لاگو ہوتا ہے: اگر ہم خود اپنی خدمات استعمال کرتے ہیں، تو ہمارے کلائنٹس بھی انہیں استعمال کرنے میں خوش ہوں گے۔ Yandex ڈیٹا بیس اس طرح کے تصور کے نفاذ کی ایک مثال ہے۔ ہم اپنا تمام ڈیٹا YDB میں اسٹور کرتے ہیں، اور ہمیں ڈیٹا بیس کو برقرار رکھنے اور اسکیل کرنے کے بارے میں سوچنے کی ضرورت نہیں ہے: یہ مسائل ہمارے لیے حل ہو گئے ہیں، ہم ڈیٹا بیس کو بطور سروس استعمال کرتے ہیں۔

آئیے بیلنس کنٹرولر پر واپس آتے ہیں۔ اس کا کام بیلنسر کے بارے میں معلومات کو محفوظ کرنا اور ورچوئل مشین کی تیاری کو ہیلتھ چیک کنٹرولر کو بھیجنا ہے۔

ہیلتھ چیک کنٹرولر

یہ چیک کے قوانین کو تبدیل کرنے کی درخواستیں وصول کرتا ہے، انہیں YDB میں محفوظ کرتا ہے، کاموں کو ہیلچیک نوڈس کے درمیان تقسیم کرتا ہے اور نتائج کو جمع کرتا ہے، جو پھر ڈیٹا بیس میں محفوظ کیے جاتے ہیں اور لوڈ بیلنسر کنٹرولر کو بھیجے جاتے ہیں۔ یہ، بدلے میں، ڈیٹا جہاز میں کلسٹر کی ساخت کو لوڈ بیلنسر نوڈ میں تبدیل کرنے کی درخواست بھیجتا ہے، جس پر میں ذیل میں بات کروں گا۔

آئیے صحت کی جانچ کے بارے میں مزید بات کرتے ہیں۔ انہیں کئی طبقات میں تقسیم کیا جا سکتا ہے۔ آڈٹس میں کامیابی کے مختلف معیار ہوتے ہیں۔ TCP چیکوں کو ایک مقررہ وقت کے اندر کامیابی سے کنکشن قائم کرنے کی ضرورت ہے۔ HTTP چیک کے لیے ایک کامیاب کنکشن اور 200 اسٹیٹس کوڈ کے ساتھ جواب دونوں کی ضرورت ہوتی ہے۔

اس کے علاوہ، چیک عمل کی کلاس میں مختلف ہیں - وہ فعال اور غیر فعال ہیں. غیر فعال چیک بغیر کسی خاص کارروائی کے ٹریفک کے ساتھ کیا ہو رہا ہے اس کی نگرانی کرتے ہیں۔ یہ L4 پر بہت اچھا کام نہیں کرتا کیونکہ یہ اعلیٰ سطح کے پروٹوکول کی منطق پر منحصر ہے: L4 پر اس بارے میں کوئی معلومات نہیں ہے کہ آپریشن میں کتنا وقت لگا یا کنکشن کی تکمیل اچھی تھی یا بری۔ فعال چیک کے لیے بیلنسر کو ہر سرور مثال کے لیے درخواستیں بھیجنے کی ضرورت ہوتی ہے۔

زیادہ تر لوڈ بیلنسرز خود لائیونس چیک کرتے ہیں۔ کلاؤڈ پر، ہم نے سکیل ایبلٹی بڑھانے کے لیے سسٹم کے ان حصوں کو الگ کرنے کا فیصلہ کیا۔ یہ نقطہ نظر ہمیں سروس میں ہیلتھ چیک کی درخواستوں کی تعداد کو برقرار رکھتے ہوئے بیلنسرز کی تعداد میں اضافہ کرنے کی اجازت دے گا۔ چیک الگ الگ ہیلتھ چیک نوڈس کے ذریعے کیے جاتے ہیں، جن میں چیک کے اہداف کو شارڈ اور نقل کیا جاتا ہے۔ آپ ایک میزبان سے چیک نہیں کر سکتے، کیونکہ یہ ناکام ہو سکتا ہے۔ پھر ہمیں ان واقعات کی حالت نہیں ملے گی جن کی اس نے جانچ کی۔ ہم کم از کم تین ہیلتھ چیک نوڈس سے کسی بھی صورت میں چیک کرتے ہیں۔ ہم مسلسل ہیشنگ الگورتھم کا استعمال کرتے ہوئے نوڈس کے درمیان چیک کے مقاصد کو کم کرتے ہیں۔

توازن اور صحت کی جانچ کو الگ کرنا مسائل کا باعث بن سکتا ہے۔ اگر ہیلتھ چیک نوڈ بیلنسر (جو فی الحال ٹریفک کی خدمت نہیں کر رہا ہے) کو نظرانداز کرتے ہوئے مثال کے طور پر درخواست کرتا ہے، تو ایک عجیب صورت حال پیدا ہوتی ہے: ایسا لگتا ہے کہ وسائل زندہ ہیں، لیکن ٹریفک اس تک نہیں پہنچے گی۔ ہم اس مسئلے کو اس طرح حل کرتے ہیں: ہم بیلنسرز کے ذریعے ہیلتھ چیک ٹریفک شروع کرنے کی ضمانت دیتے ہیں۔ دوسرے لفظوں میں، کلائنٹس اور ہیلتھ چیکس سے ٹریفک کے ساتھ پیکٹوں کو منتقل کرنے کی اسکیم میں کم سے کم فرق ہے: دونوں صورتوں میں، پیکٹ بیلنسرز تک پہنچیں گے، جو انہیں ہدف کے وسائل تک پہنچائیں گے۔

فرق یہ ہے کہ کلائنٹ VIP سے درخواستیں کرتے ہیں، جبکہ ہیلتھ چیک ہر فرد RIP سے درخواستیں کرتے ہیں۔ یہاں ایک دلچسپ مسئلہ پیدا ہوتا ہے: ہم اپنے صارفین کو سرمئی IP نیٹ ورکس میں وسائل پیدا کرنے کا موقع دیتے ہیں۔ آئیے تصور کریں کہ دو مختلف کلاؤڈ مالکان ہیں جنہوں نے اپنی خدمات کو بیلنسرز کے پیچھے چھپا رکھا ہے۔ ان میں سے ہر ایک کے پاس 10.0.0.1/24 سب نیٹ میں ایک جیسے ایڈریس کے ساتھ وسائل ہیں۔ آپ کو کسی نہ کسی طرح ان میں فرق کرنے کے قابل ہونے کی ضرورت ہے، اور یہاں آپ کو Yandex.Cloud ورچوئل نیٹ ورک کی ساخت میں غوطہ لگانے کی ضرورت ہے۔ اس میں مزید تفصیلات جاننا بہتر ہے۔ کے بارے میں ویڈیو:کلاؤڈ ایونٹہمارے لیے اب یہ اہم ہے کہ نیٹ ورک کثیر پرتوں والا ہے اور اس میں سرنگیں ہیں جنہیں سب نیٹ آئی ڈی سے پہچانا جا سکتا ہے۔

ہیلتھ چیک نوڈس نام نہاد نیم IPv6 پتوں کا استعمال کرتے ہوئے بیلنسرز سے رابطہ کرتے ہیں۔ ایک نیم پتہ ایک IPv6 پتہ ہوتا ہے جس میں IPv4 پتہ اور صارف سب نیٹ آئی ڈی اس کے اندر سرایت کرتا ہے۔ ٹریفک بیلنسر تک پہنچ جاتا ہے، جو اس سے IPv4 ریسورس ایڈریس نکالتا ہے، IPv6 کو IPv4 سے بدل دیتا ہے اور پیکٹ کو صارف کے نیٹ ورک پر بھیجتا ہے۔

ریورس ٹریفک اسی طرح جاتا ہے: بیلنسر دیکھتا ہے کہ منزل صحت کی جانچ کرنے والوں کا ایک گرے نیٹ ورک ہے، اور IPv4 کو IPv6 میں تبدیل کرتا ہے۔

VPP - ڈیٹا ہوائی جہاز کا دل

بیلنسر کو ویکٹر پیکٹ پروسیسنگ (VPP) ٹیکنالوجی کا استعمال کرتے ہوئے لاگو کیا جاتا ہے، جو نیٹ ورک ٹریفک کی بیچ پروسیسنگ کے لیے سسکو کا ایک فریم ورک ہے۔ ہمارے معاملے میں، فریم ورک یوزر اسپیس نیٹ ورک ڈیوائس مینجمنٹ لائبریری - ڈیٹا پلین ڈیولپمنٹ کٹ (DPDK) کے اوپر کام کرتا ہے۔ یہ اعلی پیکٹ پروسیسنگ کارکردگی کو یقینی بناتا ہے: کرنل میں بہت کم رکاوٹیں واقع ہوتی ہیں، اور کرنل اسپیس اور یوزر اسپیس کے درمیان کوئی سیاق و سباق سوئچ نہیں ہوتا ہے۔ 

VPP اور بھی آگے جاتا ہے اور پیکجوں کو بیچوں میں جوڑ کر سسٹم سے اور بھی زیادہ کارکردگی کو نچوڑ دیتا ہے۔ کارکردگی کے فوائد جدید پروسیسرز پر کیچز کے جارحانہ استعمال سے حاصل ہوتے ہیں۔ دونوں ڈیٹا کیچز کا استعمال کیا جاتا ہے (پیکٹوں کو "ویکٹرز" میں پروسیس کیا جاتا ہے، ڈیٹا ایک دوسرے کے قریب ہوتا ہے) اور انسٹرکشن کیچز: VPP میں، پیکٹ پروسیسنگ ایک گراف کی پیروی کرتی ہے، جس کے نوڈس میں ایسے فنکشن ہوتے ہیں جو ایک ہی کام انجام دیتے ہیں۔

مثال کے طور پر، VPP میں IP پیکٹوں کی پروسیسنگ مندرجہ ذیل ترتیب میں ہوتی ہے: پہلے، پیکٹ ہیڈر کو پارس کرنے والے نوڈ میں پارس کیا جاتا ہے، اور پھر انہیں نوڈ پر بھیجا جاتا ہے، جو روٹنگ ٹیبلز کے مطابق پیکٹوں کو مزید آگے بڑھاتا ہے۔

تھوڑا کٹر۔ وی پی پی کے مصنفین پروسیسر کیچز کے استعمال میں سمجھوتہ برداشت نہیں کرتے، اس لیے پیکٹس کے ویکٹر پر کارروائی کرنے کے لیے عام کوڈ مینوئل ویکٹرائزیشن پر مشتمل ہوتا ہے: ایک پروسیسنگ لوپ ہوتا ہے جس میں "ہمارے پاس قطار میں چار پیکٹ ہیں" جیسی صورت حال ہوتی ہے، پھر دو کے لیے ایک ہی، پھر - ایک کے لیے۔ پریفچ ہدایات اکثر ڈیٹا کو کیشز میں لوڈ کرنے کے لیے استعمال کی جاتی ہیں تاکہ بعد کے تکرار میں ان تک رسائی کو تیز کیا جا سکے۔

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

لہذا، ہیلتھ چیک IPv6 پر VPP سے بات کرتے ہیں، جو انہیں IPv4 میں بدل دیتا ہے۔ یہ گراف میں ایک نوڈ کے ذریعے کیا جاتا ہے، جسے ہم الگورتھم NAT کہتے ہیں۔ ریورس ٹریفک کے لیے (اور IPv6 سے IPv4 میں تبدیلی) ایک ہی الگورتھمک NAT نوڈ ہے۔

بیلنس کلائنٹس سے براہ راست ٹریفک گراف نوڈس سے گزرتی ہے، جو خود ہی بیلنسنگ کو انجام دیتی ہے۔ 

پہلا نوڈ چپچپا سیشن ہے۔ یہ ہیش کو ذخیرہ کرتا ہے۔ 5-ٹپل قائم سیشن کے لئے. 5-tuple میں کلائنٹ کا ایڈریس اور پورٹ شامل ہوتا ہے جہاں سے معلومات کی ترسیل ہوتی ہے، ٹریفک حاصل کرنے کے لیے دستیاب وسائل کی ایڈریس اور بندرگاہیں، نیز نیٹ ورک پروٹوکول۔ 

5-ٹپل ہیش ہمیں بعد میں مسلسل ہیشنگ نوڈ میں کم حساب کتاب کرنے میں مدد کرتا ہے، نیز بیلنسر کے پیچھے ریسورس لسٹ کی تبدیلیوں کو بہتر طریقے سے ہینڈل کرتا ہے۔ جب ایک پیکٹ جس کے لیے کوئی سیشن نہیں ہے بیلنسر پر آتا ہے، تو اسے مسلسل ہیشنگ نوڈ پر بھیجا جاتا ہے۔ یہ وہ جگہ ہے جہاں مسلسل ہیشنگ کا استعمال کرتے ہوئے توازن پیدا ہوتا ہے: ہم دستیاب "لائیو" وسائل کی فہرست سے ایک وسیلہ منتخب کرتے ہیں۔ اس کے بعد، پیکٹ NAT نوڈ پر بھیجے جاتے ہیں، جو اصل میں منزل کے پتے کی جگہ لے لیتا ہے اور چیکسم کا دوبارہ حساب لگاتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، ہم VPP کے اصولوں پر عمل کرتے ہیں - پسند کرنا، پروسیسر کیچز کی کارکردگی کو بڑھانے کے لیے اسی طرح کے حسابات کو گروپ کرنا۔

مسلسل ہیشنگ

ہم نے اسے کیوں منتخب کیا اور یہ کیا ہے؟ سب سے پہلے، آئیے پچھلے کام پر غور کریں - فہرست سے وسائل کا انتخاب۔ 

متضاد ہیشنگ کے ساتھ، آنے والے پیکٹ کی ہیش کا حساب لگایا جاتا ہے، اور اس ہیش کو وسائل کی تعداد سے تقسیم کرنے کے بعد فہرست سے ایک وسائل کا انتخاب کیا جاتا ہے۔ جب تک فہرست میں کوئی تبدیلی نہیں ہوتی، یہ اسکیم اچھی طرح کام کرتی ہے: ہم ہمیشہ ایک ہی مثال پر ایک ہی 5-ٹپل والے پیکٹ بھیجتے ہیں۔ اگر، مثال کے طور پر، کچھ وسائل نے ہیلتھ چیکس کا جواب دینا بند کر دیا، تو ہیش کے ایک اہم حصے کے لیے انتخاب بدل جائے گا۔ کلائنٹ کے TCP کنکشن ٹوٹ جائیں گے: ایک پیکٹ جو پہلے مثال A تک پہنچ گیا تھا، مثال B تک پہنچنا شروع ہو سکتا ہے، جو اس پیکٹ کے سیشن سے واقف نہیں ہے۔

مسلسل ہیشنگ بیان کردہ مسئلہ کو حل کرتی ہے۔ اس تصور کی وضاحت کرنے کا سب سے آسان طریقہ یہ ہے: تصور کریں کہ آپ کے پاس ایک انگوٹھی ہے جس میں آپ وسائل کو ہیش کے ذریعے تقسیم کرتے ہیں (مثال کے طور پر، آئی پی:پورٹ کے ذریعے)۔ وسائل کا انتخاب پہیے کو زاویہ سے موڑنا ہے، جس کا تعین پیکٹ کے ہیش سے ہوتا ہے۔

جب وسائل کی تشکیل میں تبدیلی آتی ہے تو یہ ٹریفک کی دوبارہ تقسیم کو کم کرتا ہے۔ کسی وسیلہ کو حذف کرنے سے صرف مسلسل ہیشنگ رنگ کے اس حصے پر اثر پڑے گا جس میں وسیلہ واقع تھا۔ وسائل کو شامل کرنے سے تقسیم بھی بدل جاتی ہے، لیکن ہمارے پاس ایک چسپاں سیشن نوڈ ہے، جو ہمیں پہلے سے قائم سیشنز کو نئے وسائل میں تبدیل نہیں کرنے دیتا ہے۔

ہم نے دیکھا کہ بیلنسر اور وسائل کے درمیان براہ راست ٹریفک کا کیا ہوتا ہے۔ اب آتے ہیں واپسی کی ٹریفک پر۔ یہ اسی پیٹرن کی پیروی کرتا ہے جیسے ٹریفک چیک کریں - الگورتھمک NAT کے ذریعے، یعنی کلائنٹ ٹریفک کے لیے ریورس NAT 44 کے ذریعے اور ہیلتھ چیک ٹریفک کے لیے NAT 46 کے ذریعے۔ ہم اپنی اسکیم پر عمل پیرا ہیں: ہم صحت کی جانچ کی ٹریفک اور حقیقی صارف ٹریفک کو یکجا کرتے ہیں۔

لوڈ بیلنسر نوڈ اور جمع شدہ اجزاء

VPP میں بیلنسرز اور وسائل کی تشکیل مقامی سروس - loadbalancer-node کے ذریعہ رپورٹ کی جاتی ہے۔ یہ loadbalancer-controller سے واقعات کے سلسلے کو سبسکرائب کرتا ہے اور موجودہ VPP ریاست اور کنٹرولر سے موصول ہونے والی ہدف ریاست کے درمیان فرق کو پلاٹ کرنے کے قابل ہے۔ ہمیں ایک بند نظام ملتا ہے: API سے واقعات بیلنسر کنٹرولر کے پاس آتے ہیں، جو ہیلتھ چیک کنٹرولر کو وسائل کی "جاندار" جانچنے کے لیے کام تفویض کرتا ہے۔ یہ، بدلے میں، ہیلتھ چیک نوڈ کو کام تفویض کرتا ہے اور نتائج کو جمع کرتا ہے، جس کے بعد یہ انہیں بیلنس کنٹرولر کو واپس بھیج دیتا ہے۔ Loadbalancer-node کنٹرولر سے واقعات کو سبسکرائب کرتا ہے اور VPP کی حالت کو تبدیل کرتا ہے۔ اس طرح کے نظام میں، ہر سروس صرف یہ جانتی ہے کہ پڑوسی خدمات کے بارے میں کیا ضروری ہے۔ کنکشنز کی تعداد محدود ہے اور ہمارے پاس آزادانہ طور پر مختلف حصوں کو چلانے اور اسکیل کرنے کی صلاحیت ہے۔

کن مسائل سے گریز کیا گیا؟

کنٹرول ہوائی جہاز میں ہماری تمام خدمات Go میں لکھی گئی ہیں اور اسکیلنگ اور قابل اعتماد خصوصیات اچھی ہیں۔ گو کے پاس تقسیم شدہ نظاموں کی تعمیر کے لیے کئی اوپن سورس لائبریریاں ہیں۔ ہم فعال طور پر GRPC کا استعمال کرتے ہیں، تمام اجزاء میں سروس کی دریافت کا ایک اوپن سورس نفاذ ہوتا ہے - ہماری سروسز ایک دوسرے کی کارکردگی پر نظر رکھتی ہیں، ان کی ساخت کو متحرک طور پر تبدیل کر سکتی ہیں، اور ہم نے اسے GRPC توازن سے جوڑ دیا ہے۔ میٹرکس کے لیے، ہم اوپن سورس حل بھی استعمال کرتے ہیں۔ ڈیٹا پلین میں، ہمیں اچھی کارکردگی اور وسائل کا ایک بڑا ذخیرہ ملا: ایسا اسٹینڈ اکٹھا کرنا بہت مشکل تھا جس پر ہم لوہے کے نیٹ ورک کارڈ کے بجائے VPP کی کارکردگی پر بھروسہ کر سکیں۔

مسائل اور حل

کیا اتنا اچھا کام نہیں کیا؟ گو میں خودکار میموری کا انتظام ہے، لیکن میموری لیک اب بھی ہوتی ہے۔ ان سے نمٹنے کا سب سے آسان طریقہ یہ ہے کہ گوروٹینز چلائیں اور انہیں ختم کرنا یاد رکھیں۔ ٹیک وے: اپنے گو پروگرامز کی میموری کی کھپت دیکھیں۔ اکثر ایک اچھا اشارے goroutines کی تعداد ہے. اس کہانی میں ایک پلس ہے: گو میں رن ٹائم ڈیٹا حاصل کرنا آسان ہے - میموری کی کھپت، چلنے والے گوروٹینز کی تعداد، اور بہت سے دوسرے پیرامیٹرز۔

اس کے علاوہ، گو فنکشنل ٹیسٹ کے لیے بہترین انتخاب نہیں ہو سکتا۔ وہ کافی لفظی ہیں، اور "سی آئی میں ہر چیز کو بیچ میں چلانے" کا معیاری طریقہ ان کے لیے زیادہ موزوں نہیں ہے۔ حقیقت یہ ہے کہ فنکشنل ٹیسٹ زیادہ وسائل کی طلب کرتے ہیں اور حقیقی ٹائم آؤٹ کا سبب بنتے ہیں۔ اس کی وجہ سے، ٹیسٹ ناکام ہو سکتے ہیں کیونکہ CPU یونٹ ٹیسٹ میں مصروف ہے۔ نتیجہ: اگر ممکن ہو تو، یونٹ ٹیسٹوں سے الگ "بھاری" ٹیسٹ کریں۔ 

مائیکرو سروس ایونٹ کا فن تعمیر یک سنگی سے زیادہ پیچیدہ ہے: درجنوں مختلف مشینوں پر لاگ جمع کرنا زیادہ آسان نہیں ہے۔ نتیجہ: اگر آپ مائیکرو سروسز بناتے ہیں تو فوری طور پر ٹریسنگ کے بارے میں سوچیں۔

ہمارے منصوبے

ہم ایک انٹرنل بیلنسر، ایک IPv6 بیلنسر لانچ کریں گے، Kubernetes اسکرپٹس کے لیے سپورٹ شامل کریں گے، اپنی سروسز کو تیز کرنا جاری رکھیں گے (فی الحال صرف ہیلتھ چیک نوڈ اور ہیلتھ چیک-ctrl کو شارڈ کیا گیا ہے)، نئے ہیلتھ چیک شامل کریں گے، اور چیکوں کی سمارٹ ایگریگیشن کو بھی لاگو کریں گے۔ ہم اپنی خدمات کو مزید خود مختار بنانے کے امکان پر غور کر رہے ہیں - تاکہ وہ ایک دوسرے کے ساتھ براہ راست نہیں بلکہ پیغام کی قطار کا استعمال کر سکیں۔ ایک SQS سے مطابقت رکھنے والی سروس حال ہی میں کلاؤڈ میں نمودار ہوئی ہے۔ Yandex پیغام کی قطار.

حال ہی میں، Yandex لوڈ بیلنسر کی عوامی ریلیز ہوئی. دریافت کریں۔ دستاویزات سروس کے لیے، آپ کے لیے آسان طریقے سے بیلنسرز کا نظم کریں اور اپنے پروجیکٹس کی غلطی کو برداشت کریں!

ماخذ: www.habr.com