هي حصو نيٽ ورڪ اسڪيلنگ تي ڌيان ڏيندو، AWS ۾ سڀ کان وڌيڪ پيچيده سسٽم مان هڪ. فليٽ نيٽ ورڪ کان ورچوئل پرائيويٽ ڪلائوڊ تائين ارتقا ۽ ان جي ڊيزائن، بليڪ فوٽ ۽ هائيپرپلين جون اندروني خدمتون، هڪ شور ڪندڙ پاڙيسري جو مسئلو، ۽ آخر ۾ - نيٽ ورڪ جو پيمانو، پٺيون ۽ جسماني ڪيبل. هن جي باري ۾ سڀ ڪٽ هيٺ.
ڊسڪليمر: هيٺ ڏنل هر شيء واسيلي جي ذاتي راء آهي ۽ شايد Amazon ويب سروسز جي پوزيشن سان ٺهڪندڙ نه هجي.
نيٽ ورڪ اسڪيلنگ
AWS بادل 2006 ۾ شروع ڪيو ويو. هن جو نيٽ ورڪ ڪافي پراڻي هو - هڪ لوڻ جي جوڙجڪ سان. نجي پتي جي حد سڀني بادل نوڪررن لاء عام هئي. جڏهن هڪ نئين ورچوئل مشين شروع ڪري رهيا آهيو، توهان اتفاقي طور تي هن رينج مان هڪ دستياب IP پتو حاصل ڪيو.
اهو طريقو لاڳو ڪرڻ آسان هو، پر بنيادي طور تي بادل جي استعمال کي محدود ڪيو. خاص طور تي، هائبرڊ حل کي ترقي ڪرڻ ڏاڍو ڏکيو هو جيڪو زمين تي ۽ AWS ۾ نجي نيٽ ورڪن کي گڏ ڪري ٿو. سڀ کان عام مسئلو IP پتي جي حدن کي اوورليپ ڪرڻ هو.
ورچوئل پرائيويٽ ڪلائوڊ
بادل جي طلب ٿي وئي. وقت اچي ويو آهي سوچڻ جي صلاحيت بابت ۽ ان جي استعمال جي امڪان کي لکين لکين نوڪررن طرفان. فليٽ نيٽ ورڪ هڪ وڏي رڪاوٽ بڻجي چڪو آهي. تنهن ڪري، اسان سوچيو ته ڪيئن صارفين کي هڪ ٻئي کان نيٽ ورڪ جي سطح تي الڳ ڪرڻ لاء ته جيئن اهي آزاديء سان IP حدون چونڊي سگهن.
پهرين شيء جيڪا ذهن ۾ اچي ٿي جڏهن توهان نيٽ ورڪ جي اڪيلائي بابت سوچيو ٿا؟ يقينن وي ايلان и VRF - ورچوئل روٽنگ ۽ فارورڊنگ.
بدقسمتي سان، اهو ڪم نه ڪيو. VLAN ID صرف 12 بٽ آهي، جيڪا اسان کي صرف 4096 الڳ ٿيل حصا ڏئي ٿي. جيتوڻيڪ سڀ کان وڏو سوئچ استعمال ڪري سگھن ٿا وڌ ۾ وڌ 1-2 هزار VRFs. VRF ۽ VLAN گڏجي استعمال ڪرڻ اسان کي صرف چند ملين سبنيٽس ڏئي ٿو. اهو يقيني طور تي لکين لکين نوڪررن لاءِ ڪافي ناهي، جن مان هر هڪ کي لازمي طور تي گهڻن ذيلي نيٽ استعمال ڪرڻ جي قابل هوندو.
اسان صرف گهربل تعداد ۾ وڏي باڪس خريد ڪرڻ جي متحمل نه آهيون، مثال طور، سسڪو يا جونيپر کان. اتي ٻه سبب آهن: اهو چريو مهانگو آهي، ۽ اسان نٿا چاهيون ته انهن جي ترقي ۽ پيچيدگي جي پاليسين جي رحم ڪرم تي.
اتي رڳو ھڪڙو نتيجو آھي - پنھنجو حل ٺاھيو.
2009 ۾ اسان اعلان ڪيو وي سي سي - ورچوئل پرائيويٽ ڪلائوڊ. نالو پڪڙيو ۽ هاڻي ڪيترائي بادل فراهم ڪندڙ پڻ استعمال ڪن ٿا.
VPC هڪ مجازي نيٽ ورڪ آهي ايس ڊي اين (سافٽ ويئر ڊفائنڊ نيٽ ورڪ). اسان فيصلو ڪيو ته L2 ۽ L3 سطح تي خاص پروٽوڪول ايجاد نه ڪن. نيٽ ورڪ معياري Ethernet ۽ IP تي هلندو آهي. نيٽ ورڪ تي ٽرانسميشن لاء، مجازي مشين ٽرئفڪ اسان جي پنهنجي پروٽوڪول لفافي ۾ ڍڪيل آهي. اهو اشارو ڪري ٿو ID جيڪو نوڪر جي VPC سان تعلق رکي ٿو.
سادو آواز. بهرحال، اتي ڪيترائي سنگين ٽيڪنيڪل چئلينج آھن جن کي ختم ڪرڻ جي ضرورت آھي. مثال طور، ورچوئل MAC/IP ايڊريس، VPC ID ۽ لاڳاپيل جسماني MAC/IP جي نقشي تي ڊيٽا ڪٿي ۽ ڪيئن ذخيرو ڪجي. AWS پيماني تي، هي هڪ وڏو ٽيبل آهي جيڪو ڪم ڪرڻ گهرجي گهٽ ۾ گهٽ پهچ جي دير سان. ان لاءِ ذميوار آهي نقشي سازي جي خدمت، جيڪو سڄي نيٽ ورڪ ۾ هڪ پتلي پرت ۾ پکڙيل آهي.
نئين نسل جي مشينن ۾، هارڊويئر جي سطح تي نائيٽرو ڪارڊ ذريعي انڪپسوليشن ڪئي ويندي آهي. پراڻن مثالن ۾، encapsulation ۽ decapsulation سافٽ ويئر تي ٻڌل آهن.
نقشو ماخذ پتي کي پنھنجي پاڻ سان تبديل ڪري ٿو ۽ ARP فريم کي ميپنگ سروس ڏانھن موڪلي ٿو.
ميپنگ سروس معلومات واپس ڪري ٿي جيڪا L2 فزيڪل نيٽ ورڪ تي ٽرانسميشن لاءِ ضروري آهي.
ARP جواب ۾ نائٽرو ڪارڊ جسماني نيٽ ورڪ تي MAC کي VPC ۾ ايڊريس سان تبديل ڪري ٿو.
ڊيٽا کي منتقل ڪرڻ وقت، اسان منطقي MAC ۽ IP کي وي پي سي ريپر ۾ لپيندا آهيون. اسان مناسب ذريعو ۽ منزل IP نائٽرو ڪارڊ استعمال ڪندي جسماني نيٽ ورڪ تي هي سڀ منتقل ڪريون ٿا.
ميپنگ سروس پنهنجي وسيلن جي مختص ڪرڻ واري ٽيبل کي چيڪ ڪري ٿي ۽ پيڪٽ کي پاس ڪرڻ جي اجازت ڏئي ٿي يا رد ڪري ٿي. سڀني نون مثالن ۾، اضافي تصديق نائٽرو ڪارڊ ۾ شامل ڪئي وئي آهي. ان کي نظرياتي طور تي نظرانداز ڪرڻ ناممڪن آهي. تنهن ڪري، ٻئي وي پي سي ۾ وسيلن ڏانهن ڇڪڻ ڪم نه ڪندو.
ميپنگ سروس پڻ ڪم ڪري ٿي منطقي روٽر لاءِ ڊيٽا کي منتقل ڪرڻ لاءِ مختلف ذيلي نيٽ ورڪن ۾ ورچوئل مشينن جي وچ ۾. هر شي تصوراتي طور تي سادي آهي، مان تفصيل ۾ نه ويندس.
اهو ظاهر ٿئي ٿو ته هر پيٽ کي منتقل ڪرڻ وقت، سرور ميپنگ سروس ڏانهن رخ ڪن ٿا. ناگزير دير سان ڪيئن ڊيل ڪجي؟ ڪيشنگ، بالڪل.
حسن اهو آهي ته توهان کي پوري وڏي ٽيبل کي ڪيش ڪرڻ جي ضرورت ناهي. هڪ جسماني سرور وي پي سي جي نسبتا ننڍڙي تعداد مان ورچوئل مشينن کي ميزباني ڪري ٿو. توهان کي صرف انهن VPCs بابت معلومات کي ڪيش ڪرڻ جي ضرورت آهي. "ڊفالٽ" ترتيب ۾ ٻين VPCs ڏانهن ڊيٽا منتقل ڪرڻ اڃا به جائز ناهي. جيڪڏهن ڪارڪردگي جهڙوڪ VPC-peering استعمال ٿئي ٿي، پوء لاڳاپيل VPCs بابت معلومات اضافي طور تي ڪيش ۾ لوڊ ڪئي وئي آهي.
اسان VPC ڏانهن ڊيٽا جي منتقلي کي ترتيب ڏنو.
بليڪ فوٽ
انهن حالتن ۾ ڇا ڪجي جتي ٽرئفڪ کي ٻاهر منتقل ڪرڻ جي ضرورت آهي، مثال طور انٽرنيٽ تي يا VPN ذريعي زمين تي؟ هتي اسان جي مدد ڪري ٿي بليڪ فوٽ - AWS اندروني خدمت. اهو اسان جي ڏکڻ آفريڪا ٽيم پاران ترقي ڪئي وئي آهي. ان ڪري سروس جو نالو ڏکڻ آفريڪا ۾ رهندڙ هڪ پينگوئن جي نالي تي رکيو ويو آهي.
بليڪ فوٽ ٽرئفڪ کي ختم ڪري ٿو ۽ اهو ڪري ٿو جيڪو ان سان گهربل آهي. ڊيٽا انٽرنيٽ ڏانهن موڪلي وئي آهي جيئن آهي.
جڏهن استعمال ڪندي Direct Connect، ٽرئفڪ کي ٽيگ ڪيو ويو آهي ۽ مناسب VLAN ڏانهن موڪليو ويو آهي.
هائپرپلين
هي هڪ اندروني وهڪري ڪنٽرول سروس آهي. گهڻن نيٽ ورڪ خدمتن جي نگراني جي ضرورت آهي ڊيٽا جي وهڪري جون حالتون. مثال طور، جڏهن NAT استعمال ڪندي، وهڪري جي ڪنٽرول کي يقيني بڻائڻ گهرجي ته هر IP: destination port pair وٽ هڪ منفرد ٻاهر نڪرڻ وارو بندرگاهه آهي. بيلنس جي صورت ۾ اين ايل بي - نيٽ ورڪ لوڊ بيلنس، ڊيٽا جي وهڪري کي ھميشه ھدف واري ورچوئل مشين ڏانھن ھدايت ڪئي وڃي. سيڪيورٽي گروپ هڪ رياستي فائر وال آهي. اهو ايندڙ ٽرئفڪ جي نگراني ڪندو آهي ۽ واضح طور تي ٻاهرئين پيڪٽ جي وهڪري لاءِ بندرگاهن کي کوليندو آهي.
AWS بادل ۾، ٽرانسميشن ويڪرائي گهرجون تمام گهڻيون آهن. هن ڪري هائپرپلين سڄي نيٽ ورڪ جي ڪارڪردگي لاء اهم.
هائپرپلين EC2 ورچوئل مشينن تي ٺهيل آهي. هتي ڪو به جادو ناهي، صرف چالاڪ. چال اها آهي ته اهي مجازي مشينون آهن وڏي رام سان. آپريشن ٽرانزيڪشنل آھن ۽ خاص طور تي ياداشت ۾ انجام ڏنو ويو آھي. هي توهان کي صرف ڏهن مائڪرو سيڪنڊن جي دير حاصل ڪرڻ جي اجازت ڏئي ٿو. ڊسڪ سان ڪم ڪرڻ تمام پيداوار کي ماريندو.
Hyperplane اهڙي EC2 مشينن جي هڪ وڏي تعداد جي هڪ ورهايل نظام آهي. هر ورچوئل مشين وٽ 5 GB/s جي بينڊوڊٿ آهي. سڄي علائقائي نيٽ ورڪ ۾، هي بينڊوڊٿ جي ناقابل اعتماد ٽيرابٽس مهيا ڪري ٿو ۽ پروسيسنگ جي اجازت ڏئي ٿو لکين ڪنيڪشن في سيڪنڊ.
HyperPlane صرف اسٽريمز سان ڪم ڪري ٿو. VPC پيڪيٽ encapsulation ان لاء مڪمل طور تي شفاف آهي. ھن اندروني خدمت ۾ ھڪڙو امڪاني نقصان اڃا تائين وي پي سي جي اڪيلائي کي ٽوڙڻ کان روڪيندو. هيٺيون سطحون سيڪيورٽي جا ذميوار آهن.
شور ڪندڙ پاڙيسري
اڃا به مسئلو آهي شور ڪندڙ پاڙيسري - شور ڪندڙ پاڙيسري. اچو ته فرض ڪريون ته اسان وٽ 8 نوڊس آهن. اهي نوڊس سڀني ڪلائوڊ استعمال ڪندڙن جي وهڪري کي پروسيس ڪندا آهن. هر شي ٺيڪ لڳي ٿي ۽ لوڊ سڀني نوڊس ۾ برابر طور تي ورهايو وڃي. نوڊس تمام طاقتور آهن ۽ انهن کي اوورلوڊ ڪرڻ ڏکيو آهي.
پر اسان پنهنجي فن تعمير کي اڃا به ممڪن منظرن جي بنياد تي ٺاهيندا آهيون.
گھٽ امڪان جو مطلب ناممڪن ناهي.
اسان تصور ڪري سگھون ٿا ھڪڙي صورتحال جنھن ۾ ھڪڙو يا وڌيڪ استعمال ڪندڙ تمام گھڻو لوڊ پيدا ڪندا. سڀ HyperPlane نوڊس هن لوڊ جي پروسيسنگ ۾ ملوث آهن ۽ ٻيا صارف ممڪن طور تي ڪنهن قسم جي ڪارڪردگي جو تجربو ڪري سگھن ٿا. هي بادل جي تصور کي ٽوڙي ٿو، جنهن ۾ نوڪر هڪ ٻئي تي اثر انداز ڪرڻ جي صلاحيت ناهي.
ڪيئن هڪ شور پاڙيسري جو مسئلو حل ڪرڻ لاء؟ پهرين شيء جيڪا ذهن ۾ اچي ٿي اها شيڊنگ آهي. اسان جا 8 نوڊس منطقي طور تي 4 نوڊس جي 2 حصن ۾ ورهايل آھن. هاڻي هڪ شور ڪندڙ پاڙيسري سڀني صارفين جي صرف هڪ چوٿين کي پريشان ڪندو، پر اهو انهن کي تمام گهڻو پريشان ڪندو.
اچو ته مختلف ڪم ڪريون. اسان هر صارف کي صرف 3 نوڊس مختص ڪنداسين.
چال بي ترتيب طور مختلف استعمال ڪندڙن کي نوڊس تفويض ڪرڻ آهي. هيٺ ڏنل تصوير ۾، نيرو استعمال ڪندڙ نوڊس کي ٻئي ٻن استعمال ڪندڙن مان هڪ سان گڏ ڪري ٿو - سائو ۽ نارنگي.
8 نوڊس ۽ 3 استعمال ڪندڙن سان، ھڪڙو شور ڪندڙ پاڙيسري جو امڪان ھڪڙو استعمال ڪندڙ سان گڏ 54٪ آھي. اهو هن امڪان سان آهي ته هڪ نيري استعمال ڪندڙ ٻين نوڪررن کي متاثر ڪندو. ساڳئي وقت، ان جي لوڊ جو صرف هڪ حصو. اسان جي مثال ۾، اهو اثر گهٽ ۾ گهٽ ڪنهن نه ڪنهن طرح هر ڪنهن کي نه، پر سڀني استعمال ڪندڙن جي صرف ٽيون تائين قابل ذڪر هوندو. اهو اڳ ۾ ئي سٺو نتيجو آهي.
استعمال ڪندڙن جو تعداد جيڪي ٽڪرائيندا
سيڪڙو ۾ امڪان
0
18٪
1
54٪
2
26٪
3
2%
اچو ته صورتحال کي حقيقت جي ويجهو آڻيون - اچو ته 100 نوڊس ۽ 5 استعمال ڪندڙ 5 نوڊس تي. انهي صورت ۾، نوڊس مان ڪو به 77٪ جي امڪان سان ٽڪر نه ڪندو.
استعمال ڪندڙن جو تعداد جيڪي ٽڪرائيندا
سيڪڙو ۾ امڪان
0
77٪
1
21٪
2
1,8٪
3
0,06٪
4
0,0006٪
5
0,00000013٪
هڪ حقيقي صورتحال ۾، هائپرپلين نوڊس ۽ استعمال ڪندڙن جي وڏي تعداد سان، ٻين استعمال ڪندڙن تي شور ڪندڙ پاڙيسري جو امڪاني اثر گهٽ ۾ گهٽ آهي. اهو طريقو سڏيو ويندو آهي ملائڻ شارڊنگ - ڦاٽل شارڊنگ. اهو نوڊ ناڪامي جي منفي اثر کي گھٽائي ٿو.
دستيابي زونز ۽ ڊيٽا سينٽر جي وچ ۾ ڪيترائي آپٽيڪل لنڪ آهن. اسان جي وڏين علائقن مان هڪ ۾، 388 چينلز رکيا ويا آهن صرف AZ رابطي لاءِ هڪ ٻئي جي وچ ۾ ۽ مواصلاتي مرڪز ٻين علائقن سان (ٽرانزٽ سينٽرز). مجموعي طور تي هي چريو ڏئي ٿو 5000 Tbit.
Backbone AWS خاص طور تي بادل لاءِ ٺهيل ۽ بهتر ڪئي وئي آهي. اسان ان کي چينل تي ٺاهيندا آهيون 100 GB / s. اسان انهن کي مڪمل طور تي ڪنٽرول ڪريون ٿا، چين جي علائقن جي استثنا سان. ٽرئفڪ ٻين ڪمپنين جي لوڊ سان حصيداري نه ڪئي وئي آهي.
يقينن، اسان صرف بادل فراهم ڪندڙ نه آهيون پرائيويٽ ريبون نيٽ ورڪ سان. وڌيڪ ۽ وڌيڪ وڏيون ڪمپنيون هن رستي تي عمل ڪري رهيا آهن. اها ڳالهه آزاد محققن طرفان تصديق ڪئي وئي آهي، مثال طور ٽيليگرافي.
گراف ڏيکاري ٿو ته مواد فراهم ڪندڙ ۽ بادل فراهم ڪندڙن جو حصو وڌي رهيو آهي. انهي جي ڪري، ريبون فراهم ڪندڙن جي انٽرنيٽ ٽرئفڪ جو حصو مسلسل گهٽجي رهيو آهي.
مان وضاحت ڪندس ته اهو ڇو ٿئي ٿو. اڳي، گهڻيون ويب خدمتون دستياب هيون ۽ سڌو سنئون انٽرنيٽ تان استعمال ڪيون وينديون هيون. اڄڪلهه، وڌيڪ ۽ وڌيڪ سرور ڪلائوڊ ۾ واقع آهن ۽ ان جي ذريعي رسائي لائق آهن سي ڊي اين - مواد جي تقسيم نيٽ ورڪ. وسيلن تائين رسائي حاصل ڪرڻ لاءِ، استعمال ڪندڙ انٽرنيٽ ذريعي صرف ويجھي CDN PoP تائين وڃي ٿو. موجودگي جي نقطي. گهڻو ڪري اهو هڪ ويجهو آهي. پوءِ اهو عوامي انٽرنيٽ ڇڏي ٿو ۽ ائٽلانٽڪ پار هڪ خانگي پس منظر ذريعي اڏامي ٿو، مثال طور، ۽ سڌو سنئون وسيلن ڏانهن وڃي ٿو.
سائنسدان اڃا تائين اهو معلوم نه ڪري سگهيا آهن ته ڪائنات ۾ روشني جي رفتار کي ڪيئن وڌايو وڃي، پر انهن کي نظرياتي فائبر ذريعي منتقل ڪرڻ جي طريقن ۾ وڏي ترقي ڪئي آهي. اسان هن وقت 6912 فائبر ڪيبل استعمال ڪندا آهيون. هي خاص طور تي انهن جي تنصيب جي قيمت کي بهتر ڪرڻ ۾ مدد ڪري ٿي.
ڪجھ علائقن ۾ اسان کي خاص ڪيبل استعمال ڪرڻو پوندو. مثال طور، سڊني واري علائقي ۾ اسان ٽرمائٽس جي خلاف خاص ڪوٽنگ سان ڪيبل استعمال ڪندا آهيون.
ڪو به ماڻهو مصيبتن کان محفوظ ناهي ۽ ڪڏهن ڪڏهن اسان جا چينل خراب ٿي ويندا آهن. ساڄي پاسي واري تصوير آمريڪي علائقن مان هڪ آپٽيڪل ڪيبل ڏيکاري ٿي جيڪي تعميراتي ڪارڪنن طرفان ڦاٽي ويا هئا. حادثي جي نتيجي ۾ صرف 13 ڊيٽا پيڪيٽ گم ٿي ويا، جيڪا حيران ڪندڙ ڳالهه آهي. هڪ ڀيرو ٻيهر - صرف 13! سسٽم لفظي طور تي فوري طور تي بيڪ اپ چينلز ڏانهن تبديل ڪيو ويو - پيماني تي ڪم ڪري رهيو آهي.
اسان ڪجھ Amazon جي ڪلائوڊ سروسز ۽ ٽيڪنالاجيز ذريعي اڳتي وڌو. مون کي اميد آهي ته توهان کي گهٽ ۾ گهٽ ڪجهه خيال آهي ته انهن ڪمن جي پيماني تي جيڪي اسان جي انجنيئرن کي حل ڪرڻ گهرجن. ذاتي طور تي، مون کي اهو تمام دلچسپ آهي.
هي AWS ڊوائيس بابت Vasily Pantyukhin کان تريولوجي جو آخري حصو آهي. IN پهرين حصن کي بيان ڪري ٿو سرور جي اصلاح ۽ ڊيٽابيس اسڪيلنگ، ۽ ۾ ٻيو - بي سرور افعال ۽ فائر ڪريڪر.
تي هاء لوڊ ++ نومبر ۾ Vasily Pantyukhin Amazon ڊوائيس جي نئين تفصيل سان حصيداري ڪندو. هن ٻڌائي سگهان ٿو ناڪامين جي سببن ۽ Amazon تي ورهايل سسٽم جي ڊيزائن بابت. آڪٽوبر 24 اڃا ممڪن آهي بڪ ڪرڻ سٺي قيمت تي ٽڪيٽ، ۽ بعد ۾ ادا ڪريو. اسان توهان جو انتظار ڪري رهيا آهيون HighLoad++ تي، اچو ته ڳالهايون!