ඇමසන් වෙබ් සේවා ජාලයේ පරිමාණය කලාප 69ක ලොව පුරා කලාප 22කි: ඇමරිකා එක්සත් ජනපදය, යුරෝපය, ආසියාව, අප්‍රිකාව සහ ඕස්ට්‍රේලියාව. සෑම කලාපයකම දත්ත මධ්‍යස්ථාන 8ක් දක්වා අඩංගු වේ - දත්ත සැකසුම් මධ්‍යස්ථාන. සෑම දත්ත මධ්‍යස්ථානයකම සේවාදායකයන් දහස් ගණනක් හෝ සිය දහස් ගණනක් ඇත. ජාලය සැලසුම් කර ඇත්තේ සිදුවිය නොහැකි සියලුම අක්‍රිය අවස්ථා සැලකිල්ලට ගන්නා ආකාරයටය. උදාහරණයක් ලෙස, සියලුම කලාප එකිනෙකින් හුදකලා වී ඇති අතර, ප්‍රවේශ්‍යතා කලාප කිලෝමීටර් කිහිපයක් දුරින් වෙන් කර ඇත. ඔබ කේබලය කපා ගත්තද, පද්ධතිය උපස්ථ නාලිකා වෙත මාරු වන අතර, තොරතුරු අහිමි වීම දත්ත පැකට් කිහිපයක් දක්වා ඇත. Vasily Pantyukhin ජාලය ගොඩනඟා ඇති වෙනත් මූලධර්ම මොනවාද සහ එය සකස් කර ඇති ආකාරය ගැන කතා කරනු ඇත.
Vasily Pantyukhin .ru සමාගම්වල Unix පරිපාලකයෙකු ලෙස ආරම්භ කර, වසර 6ක් විශාල Sun Microsystem දෘඪාංග මත වැඩ කර, EMC හි වසර 11ක් දත්ත කේන්ද්‍රීය ලෝකයක් දේශනා කළේය. එය ස්වභාවිකවම පුද්ගලික වලාකුළු බවට පරිණාමය වී, පසුව පොදු ඒවා වෙත මාරු විය. දැන්, Amazon Web Services ගෘහ නිර්මාණ ශිල්පියෙකු ලෙස, ඔහු AWS වලාකුළෙහි ජීවත් වීමට සහ සංවර්ධනය කිරීමට තාක්ෂණික උපදෙස් සපයයි.
AWS ත්‍රිත්වයේ පෙර කොටසේදී, Vasily භෞතික සේවාදායකයන් සහ දත්ත සමුදා පරිමාණය සැලසුම් කිරීම පිළිබඳව සොයා බැලුවා. නයිට්‍රෝ කාඩ්පත්, අභිරුචි KVM-පාදක හයිපර්වයිසර්, Amazon Aurora දත්ත සමුදාය - මේ සියල්ල ගැන තොරතුරු "" සන්දර්භය සඳහා කියවන්න හෝ නැරඹීම කතා
මෙම කොටස AWS හි වඩාත් සංකීර්ණ පද්ධති වලින් එකක් වන ජාල පරිමාණය කෙරෙහි අවධානය යොමු කරනු ඇත. පැතලි ජාලයකින් අතථ්‍ය පුද්ගලික වලාකුළක් දක්වා පරිණාමය වීම සහ එහි සැලසුම, Blackfoot සහ HyperPlane හි අභ්යන්තර සේවා, ඝෝෂාකාරී අසල්වැසියෙකුගේ ගැටලුව සහ අවසානයේ - ජාලයේ පරිමාණය, කොඳු ඇට පෙළ සහ භෞතික කේබල්. කප්පාදුව යටතේ මේ සියල්ල ගැන.
වියාචනය: පහත සෑම දෙයක්ම Vasily ගේ පෞද්ගලික මතය වන අතර Amazon වෙබ් සේවා වල තත්ත්වය සමග සමපාත නොවිය හැක.
ජාල පරිමාණය
AWS වලාකුළු 2006 දී දියත් කරන ලදී. ඔහුගේ ජාලය තරමක් ප්‍රාථමික විය - පැතලි ව්‍යුහයක් සමඟ. පුද්ගලික ලිපින පරාසය සියලුම වලාකුළු කුලී නිවැසියන්ට පොදු විය. නව අතථ්‍ය යන්ත්‍රයක් ආරම්භ කරන විට, ඔබට අහම්බෙන් මෙම පරාසයෙන් ලබාගත හැකි IP ලිපිනයක් ලැබුණි.
මෙම ප්රවේශය ක්රියාත්මක කිරීමට පහසු විය, නමුත් වලාකුළු භාවිතය මූලික වශයෙන් සීමා විය. විශේෂයෙන්, භූමියේ සහ AWS හි පුද්ගලික ජාල ඒකාබද්ධ කරන දෙමුහුන් විසඳුම් සංවර්ධනය කිරීම තරමක් අපහසු විය. වඩාත් පොදු ගැටළුව වූයේ IP ලිපින පරාසයන් අතිච්ඡාදනය වීමයි.
අතථ්‍ය පුද්ගලික වලාකුළු
වලාකුළට ඉල්ලුමක් ඇති විය. මිලියන ගණනක් කුලී නිවැසියන් විසින් පරිමාණය සහ එය භාවිතා කිරීමේ හැකියාව ගැන සිතීමට කාලය පැමිණ තිබේ. පැතලි ජාලය විශාල බාධාවක් වී ඇත. එබැවින්, ස්වාධීනව IP පරාසයන් තෝරා ගැනීමට හැකි වන පරිදි ජාල මට්ටමින් පරිශීලකයින් එකිනෙකාගෙන් හුදකලා කරන්නේ කෙසේදැයි අපි සිතුවෙමු.
ජාල හුදකලා කිරීම ගැන ඔබ සිතන විට මතකයට එන පළමු දෙය කුමක්ද? නිසැකවම VLANs и VRF - අතථ්‍ය මාර්ගගත කිරීම සහ ඉදිරියට යැවීම.
අවාසනාවට, එය වැඩ කළේ නැත. VLAN හැඳුනුම්පත බිටු 12 ක් පමණි, එය අපට ලබා දෙන්නේ හුදකලා කොටස් 4096 ක් පමණි. විශාලතම ස්විචයන් පවා උපරිම VRF 1-2 දහසක් භාවිතා කළ හැකිය. VRF සහ VLAN එකට භාවිතා කිරීමෙන් අපට ලැබෙන්නේ උපජාල මිලියන කිහිපයක් පමණි. මිලියන ගණනක් කුලී නිවැසියන් සඳහා මෙය නියත වශයෙන්ම ප්‍රමාණවත් නොවේ, ඒ සෑම එකක්ම බහු අනුජාල භාවිතා කිරීමට හැකි විය යුතුය.
අපට අවශ්ය විශාල පෙට්ටි ප්‍රමාණය මිලදී ගැනීමට ද අපට හැකියාවක් නැත, උදාහරණයක් ලෙස, සිස්කෝ හෝ ජුනිපර් වෙතින්. හේතු දෙකක් තිබේ: එය පිස්සු මිල අධික වන අතර, ඔවුන්ගේ සංවර්ධන සහ පැච් ප්‍රතිපත්තිවලට අනුකම්පා කිරීමට අපට අවශ්ය නැත.
ඇත්තේ එක් නිගමනයක් පමණි - ඔබේම විසඳුමක් සාදන්න.
2009 දී අපි නිවේදනය කළා වීපීසී - අතථ්‍ය පුද්ගලික වලාකුළු. නම සිරවී ඇති අතර දැන් බොහෝ ක්ලවුඩ් සපයන්නන් ද එය භාවිතා කරයි.
VPC යනු අතථ්‍ය ජාලයකි SDN (මෘදුකාංග නිර්වචනය කළ ජාලය). L2 සහ L3 මට්ටම්වල විශේෂ ප්‍රොටෝකෝල නිර්මාණය නොකිරීමට අපි තීරණය කළෙමු. ජාලය සම්මත ඊතර්නෙට් සහ IP මත ධාවනය වේ. ජාලය හරහා සම්ප්රේෂණය කිරීම සඳහා, අතථ්‍ය යන්ත්‍ර ගමනාගමනය අපගේම ප්‍රොටෝකෝලය ඔතා ඇත. එය කුලී නිවැසියාගේ VPC ට අයත් හැඳුනුම්පත දක්වයි.
සරලයි වගේ. කෙසේ වෙතත්, ජයගත යුතු බරපතල තාක්ෂණික අභියෝග කිහිපයක් තිබේ. උදාහරණයක් ලෙස, අතථ්‍ය MAC/IP ලිපින සිතියම්ගත කිරීමේදී දත්ත ගබඩා කරන්නේ කොහේද සහ කෙසේද, VPC ID සහ අනුරූප භෞතික MAC/IP. AWS පරිමාණයෙන්, මෙය අවම ප්රවේශ ප්‍රමාදයන් සමඟ ක්‍රියා කළ යුතු විශාල වගුවකි. මේ සඳහා වගකිව යුතුය සිතියම්කරණ සේවාව, ජාලය පුරා තුනී ස්ථරයක් තුළ පැතිර ඇත.
නව පරම්පරාවේ යන්ත්‍රවල, දෘඪාංග මට්ටමින් නයිට්‍රෝ කාඩ්පත් මගින් එන්කැප්සුලේෂන් සිදු කරයි. පැරණි අවස්ථා වලදී, කැප්සියුලේෂන් සහ ඩෙකැප්සුලේෂන් මෘදුකාංග පදනම් වේ.
පොදුවේ ගත් කල, එය ක්‍රියා කරන ආකාරය සොයා බලමු. අපි L2 මට්ටමෙන් පටන් ගනිමු. 10.0.0.2 භෞතික සේවාදායකයක IP 192.168.0.3 සහිත අතථ්‍ය යන්ත්‍රයක් අප සතුව ඇතැයි උපකල්පනය කරමු. එය 10.0.0.3 මත ජීවත් වන අතථ්‍ය යන්ත්‍ර 192.168.1.4 වෙත දත්ත යවයි. ARP ඉල්ලීමක් උත්පාදනය කර ජාල නයිට්‍රෝ කාඩ්පතට යවනු ලැබේ. සරල බව සඳහා, අථත්ය යන්ත්‍ර දෙකම එකම "නිල්" VPC තුළ ජීවත් වන බව අපි උපකල්පනය කරමු.
සිතියම මූලාශ්‍ර ලිපිනය තමන්ගේම ලිපිනයකින් ප්‍රතිස්ථාපනය කර ARP රාමුව සිතියම්ගත කිරීමේ සේවාව වෙත යොමු කරයි.
සිතියම්කරණ සේවාව L2 භෞතික ජාලය හරහා සම්ප්රේෂණය කිරීමට අවශ්ය තොරතුරු ලබා දෙයි.
ARP ප්‍රතිචාරයේ ඇති Nitro කාඩ්පත VPC හි ලිපිනයක් සමඟ භෞතික ජාලයේ MAC ප්‍රතිස්ථාපනය කරයි.
දත්ත මාරු කිරීමේදී, අපි තාර්කික MAC සහ IP VPC එතුමක ඔතා. සුදුසු මූලාශ්‍ර සහ ගමනාන්ත IP Nitro කාඩ්පත් භාවිතයෙන් අපි මේ සියල්ල භෞතික ජාලය හරහා සම්ප්රේෂණය කරමු.
පැකේජය නියම කර ඇති භෞතික යන්ත්රය චෙක්පත සිදු කරයි. ලිපිනය වංචා කිරීමේ හැකියාව වැළැක්වීම සඳහා මෙය අවශ්ය වේ. යන්ත්රය සිතියම්කරණ සේවාවට විශේෂ ඉල්ලීමක් යවා අසයි: “භෞතික යන්ත්‍ර 192.168.0.3 වෙතින් මට නිල් VPC හි 10.0.0.3 සඳහා අදහස් කරන ලද පැකට්ටුවක් ලැබුණි. ඔහු නීත්‍යානුකූලද?
සිතියම්ගත කිරීමේ සේවාව එහි සම්පත් වෙන් කිරීමේ වගුව පරීක්ෂා කරන අතර පැකට්ටුව හරහා යාමට ඉඩ දීම හෝ ප්‍රතික්ෂේප කිරීම. සියලුම නව අවස්ථා වලදී, අතිරේක වලංගු කිරීම් නයිට්‍රෝ කාඩ්පත් තුළ අන්තර්ගත වේ. එය න්‍යායාත්මකව පවා මග හැරිය නොහැක. එබැවින්, වෙනත් VPC හි සම්පත්වලට වංචා කිරීම ක්‍රියා නොකරනු ඇත.
ඊළඟට, දත්ත එය අදහස් කරන අථත්ය යන්ත්රය වෙත යවනු ලැබේ.
සිතියම්කරණ සේවාව විවිධ උපජාලවල අථත්ය යන්ත්‍ර අතර දත්ත මාරු කිරීම සඳහා තාර්කික රවුටරයක් ලෙසද ක්‍රියා කරයි. සෑම දෙයක්ම සංකල්පමය වශයෙන් සරලයි, මම විස්තරාත්මකව නොකියමි.
එක් එක් පැකට්ටුව සම්ප්රේෂණය කරන විට, සේවාදායකයන් සිතියම්ගත කිරීමේ සේවාව වෙත හැරෙන බව පෙනී යයි. නොවැළැක්විය හැකි ප්‍රමාදයන් සමඟ කටයුතු කරන්නේ කෙසේද? හැඹිලිගත කිරීම, ඇත්ත වශයෙන්.
අලංකාරය නම් ඔබට මුළු විශාල මේසයම කෑෂ් කිරීමට අවශ්ය නොවීමයි. භෞතික සේවාදායකයක් සාපේක්ෂව කුඩා VPC සංඛ්‍යාවකින් අතථ්‍ය යන්ත්‍ර සත්කාරකත්වය සපයයි. ඔබට අවශ්ය වන්නේ මෙම VPC පිළිබඳ තොරතුරු හැඹිලිගත කිරීම පමණි. "පෙරනිමි" වින්‍යාසය තුළ වෙනත් VPC වෙත දත්ත මාරු කිරීම තවමත් නීත්‍යානුකූල නොවේ. VPC-peering වැනි ක්‍රියාකාරීත්වය භාවිතා කරන්නේ නම්, අනුරූප VPCs පිළිබඳ තොරතුරු අතිරේකව හැඹිලිය තුළට පටවනු ලැබේ.
අපි VPC වෙත දත්ත මාරු කිරීම වර්ග කළෙමු.
බ්ලැක්ෆුට්
ගමනාගමනය පිටත සම්ප්රේෂණය කිරීමට අවශ්ය අවස්ථාවන්හිදී කුමක් කළ යුතුද, උදාහරණයක් ලෙස අන්තර්ජාලයට හෝ VPN හරහා බිමට? මෙතනින් අපිට උදව් කරනවා බ්ලැක්ෆුට් - AWS අභ්යන්තර සේවය. එය අපේ දකුණු අප්‍රිකානු කණ්ඩායම විසින් සංවර්ධනය කරන ලදී. දකුණු අප්‍රිකාවේ වෙසෙන පෙන්ගුයින් සතෙකුගේ නමින් මෙම සේවාව නම් කර ඇත්තේ එබැවිනි.
බ්ලැක්ෆුට් ගමනාගමනය ඉවත් කර එය සමඟ අවශ්ය දේ කරයි. දත්ත එලෙසම අන්තර්ජාලයට යවනු ලැබේ.
VPN භාවිතා කරන විට දත්ත IPsec වලින් වෙන් කර නැවත ඔතා ඇත.
Direct Connect භාවිතා කරන විට, ගමනාගමනය ටැග් කර සුදුසු VLAN වෙත යවනු ලැබේ.
හයිපර් ප්ලේන්
මෙය අභ්යන්තර ප්රවාහ පාලන සේවාවකි. බොහෝ ජාල සේවාවන් නිරීක්ෂණය කිරීම අවශ්ය වේ දත්ත ප්රවාහ තත්වයන්. උදාහරණයක් ලෙස, NAT භාවිතා කරන විට, ප්රවාහ පාලනය එක් එක් IP:destination port යුගලයට අනන්‍ය පිටතට යන වරායක් ඇති බව සහතික කළ යුතුය. සමතුලිතතාවයේ දී NLB - ජාල පැටවුම් ශේෂය, දත්ත ප්‍රවාහය සෑම විටම එකම ඉලක්කගත අථත්ය යන්ත්රය වෙත යොමු කළ යුතුය. ආරක්ෂක කණ්ඩායම් යනු රාජ්‍ය ෆයර්වෝලයකි. එය පැමිණෙන ගමනාගමනය නිරීක්ෂණය කරන අතර පිටතට යන පැකට් ප්‍රවාහය සඳහා වරායන් ව්‍යංගයෙන් විවෘත කරයි.
AWS වලාකුළෙහි, සම්ප්‍රේෂණ ප්‍රමාද අවශ්‍යතා අතිශයින් ඉහළ ය. ඒක තමයි හයිපර් ප්ලේන් සමස්ත ජාලයේ කාර්ය සාධනය සඳහා ඉතා වැදගත් වේ.
හයිපර්ප්ලේන් EC2 අතථ්‍ය යන්ත්‍ර මත ගොඩනගා ඇත. මෙහි මැජික් නැත, කපටිකම පමණි. උපක්‍රමය නම් මේවා විශාල RAM සහිත අථත්ය යන්ත්‍ර වීමයි. මෙහෙයුම් ගනුදෙනු වන අතර මතකයේ පමණක් සිදු කෙරේ. මෙය ඔබට මයික්‍රො තත්පර දහයක ප්‍රමාදයන් ලබා ගැනීමට ඉඩ සලසයි. තැටිය සමඟ වැඩ කිරීම සියලු ඵලදායිතාව විනාශ කරයි.
හයිපර්ප්ලේන් යනු එවැනි EC2 යන්ත්‍ර විශාල සංඛ්‍යාවක බෙදා හරින ලද පද්ධතියකි. සෑම අතථ්‍ය යන්ත්‍රයකම 5 GB/s කලාප පළලක් ඇත. සමස්ත ප්‍රාදේශීය ජාලය හරහා, මෙය ඇදහිය නොහැකි තරම් කලාප පළලක් සපයන අතර සැකසීමට ඉඩ සලසයි. තත්පරයකට සම්බන්ධතා මිලියන ගණනක්.
HyperPlane ක්‍රියා කරන්නේ ප්රවාහ සමඟ පමණි. VPC පැකට් කැප්සියුලේෂන් ඒ සඳහා සම්පූර්ණයෙන්ම විනිවිද පෙනෙන වේ. මෙම අභ්යන්තර සේවයේ ඇති විය හැකි අවදානමක් තවමත් VPC හුදකලාව බිඳී යාම වලක්වනු ඇත. පහත මට්ටම් ආරක්ෂාව සඳහා වගකිව යුතුය.
ඝෝෂාකාරී අසල්වැසියා
තාම ප්‍රශ්නයක් තියෙනවා ඝෝෂාකාරී අසල්වැසියා - ඝෝෂාකාරී අසල්වැසියා. අපි හිතමු අපිට නෝඩ් 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%
සැබෑ තත්වයක් තුළ, HyperPlane නෝඩ් සහ පරිශීලකයින් විශාල සංඛ්‍යාවක් සමඟ, අනෙකුත් පරිශීලකයින්ට ඝෝෂාකාරී අසල්වැසියෙකුගේ විභව බලපෑම අවම වේ. මෙම ක්රමය හැඳින්වේ මිශ්ර කිරීම shading - ෂෆල් ෂර්ඩිං. එය නෝඩ් අසමත් වීමේ ඍණාත්මක බලපෑම අවම කරයි.
බොහෝ සේවාවන් HyperPlane පදනම මත ගොඩනගා ඇත: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
ජාල පරිමාණය
දැන් අපි ජාලයේ පරිමාණය ගැන කතා කරමු. 2019 ඔක්තෝබර් සඳහා AWS එහි සේවාවන් සපයයි කලාප 22 ක්, සහ තවත් 9 ක් සැලසුම් කර ඇත.
- සෑම කලාපයකම ලබා ගත හැකි කලාප කිහිපයක් අඩංගු වේ. ඔවුන්ගෙන් 69 දෙනෙක් ලොව පුරා සිටිති.
- එක් එක් AZ දත්ත සැකසුම් මධ්‍යස්ථාන වලින් සමන්විත වේ. මුළු ඒවායින් 8 කට වඩා නැත.
- දත්ත මධ්‍යස්ථානයේ විශාල සේවාදායක සංඛ්‍යාවක් ඇත, සමහරක් 300 දක්වා ඇත.
දැන් අපි මේ සියල්ල සාමාන්‍ය කරමු, ගුණ කර පිළිබිඹු කරන ආකර්ෂණීය රූපයක් ලබා ගනිමු ඇමසන් වලාකුළු පරිමාණය.
ලබා ගත හැකි කලාප සහ දත්ත මධ්‍යස්ථානය අතර බොහෝ දෘශ්‍ය සබැඳි ඇත. අපගේ විශාලතම කලාපයක, එකිනෙකා අතර AZ සන්නිවේදනය සහ අනෙකුත් කලාප සමඟ සන්නිවේදන මධ්‍යස්ථාන (සංක්‍රමණ මධ්‍යස්ථාන) සඳහා පමණක් නාලිකා 388 ක් තබා ඇත. සමස්තයක් වශයෙන් මෙය පිස්සුවක් ලබා දෙයි 5000 Tbit.
Backbone AWS වලාකුළ සඳහා විශේෂයෙන් ගොඩනගා ඇති අතර එය ප්රශස්ත කර ඇත. අපි එය නාලිකා මත ගොඩනඟමු 100 GB / s. චීනයේ කලාප හැරුණු විට අපි ඒවා සම්පූර්ණයෙන්ම පාලනය කරමු. වෙනත් සමාගම්වල බර සමඟ ගමනාගමනය බෙදා නොගනී.
ඇත්ත වශයෙන්ම, අපි පුද්ගලික කොඳු නාරටිය ජාලයක් ඇති එකම වලාකුළු සපයන්නා නොවේ. වැඩි වැඩියෙන් විශාල සමාගම් මෙම මාර්ගය අනුගමනය කරයි. මෙය ස්වාධීන පර්යේෂකයන් විසින් සනාථ කරනු ලැබේ, උදාහරණයක් ලෙස .
ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ අන්තර්ගත සපයන්නන්ගේ සහ වලාකුළු සපයන්නන්ගේ කොටස වර්ධනය වන බවයි. මේ නිසා, කොඳු නාරටිය සපයන්නන්ගේ අන්තර්ජාල ගමනාගමනයේ කොටස නිරන්තරයෙන් අඩු වේ.
මෙය සිදුවන්නේ මන්දැයි මම පැහැදිලි කරමි. මීට පෙර, බොහෝ වෙබ් සේවාවන් අන්තර්ජාලයෙන් සෘජුවම ප්රවේශ විය හැකි අතර පරිභෝජනය කරන ලදී. වර්තමානයේ, වැඩි වැඩියෙන් සේවාදායකයන් වලාකුළු තුළ පිහිටා ඇති අතර ඒවා හරහා ප්රවේශ විය හැකිය සීඩීඑන් - අන්තර්ගත බෙදා හැරීමේ ජාලය. සම්පතකට ප්රවේශ වීමට, පරිශීලකයා අන්තර්ජාලය හරහා යන්නේ ළඟම ඇති CDN PoP වෙත පමණි - පැමිණීමේ ලක්ෂ්යය. බොහෝ විට එය අසල කොහේ හරි. එවිට එය පොදු අන්තර්ජාලයෙන් ඉවත් වී අත්ලාන්තික් සාගරය හරහා පුද්ගලික කොඳු නාරටිය හරහා පියාසර කරයි, උදාහරණයක් ලෙස, සහ කෙලින්ම සම්පත වෙත පැමිණේ.
මෙම ප්‍රවණතාවය දිගටම පැවතුනහොත් වසර 10 කින් අන්තර්ජාලය වෙනස් වන්නේ කෙසේදැයි මම කල්පනා කරමි?
භෞතික නාලිකා
විශ්වයේ ආලෝකයේ වේගය වැඩි කරන්නේ කෙසේදැයි විද්‍යාඥයින් තවමත් සොයාගෙන නැත, නමුත් ඔප්ටිකල් ෆයිබර් හරහා එය සම්ප්රේෂණය කිරීමේ ක්‍රමවල විශාල ප්‍රගතියක් ලබා ඇත. අපි දැනට ෆයිබර් කේබල් 6912ක් භාවිතා කරනවා. මෙය ඔවුන්ගේ ස්ථාපනය කිරීමේ පිරිවැය සැලකිය යුතු ලෙස ප්රශස්ත කිරීමට උපකාරී වේ.
සමහර කලාපවල අපට විශේෂ කේබල් භාවිතා කිරීමට සිදු වේ. උදාහරණයක් ලෙස, සිඩ්නි කලාපයේ අපි වේයන්ට එරෙහිව විශේෂ ආලේපනයක් සහිත කේබල් භාවිතා කරමු.
කිසිවෙකු කරදරවලින් නිදහස් නොවන අතර සමහර විට අපගේ නාලිකා වලට හානි සිදු වේ. දකුණු පස ඇති ඡායාරූපය ඉදිකිරීම් කම්කරුවන් විසින් ඉරා දැමූ එක් ඇමරිකානු කලාපයක දෘශ්‍ය කේබල් පෙන්වයි. අනතුර හේතුවෙන් දත්ත පැකට් 13ක් පමණක් නැතිවී යාම පුදුමයට කරුණකි. නැවත වරක් - 13 ක් පමණි! පද්ධතිය වචනාර්ථයෙන් උපස්ථ නාලිකා වෙත මාරු විය - පරිමාණය ක්රියාත්මක වේ.
අපි Amazon හි සමහර ක්ලවුඩ් සේවා සහ තාක්ෂණයන් හරහා ගමන් කළෙමු. අපගේ ඉංජිනේරුවන්ට විසඳිය යුතු කාර්යයන්හි පරිමාණය පිළිබඳව ඔබට අවම වශයෙන් යම් අදහසක් ඇතැයි මම බලාපොරොත්තු වෙමි. පුද්ගලිකව, මම මෙය ඉතා උද්යෝගිමත් ලෙස සලකමි.
AWS උපාංගය ගැන Vasily Pantyukhin ගේ ත්‍රිත්වයේ අවසාන කොටස මෙයයි. තුල කොටස් සේවාදායක ප්‍රශස්තකරණය සහ දත්ත සමුදා පරිමාණය විස්තර කරයි, සහ in - serverless functions සහ Firecracker.
මත නොවැම්බර් මාසයේදී Vasily Pantyukhin විසින් Amazon උපාංගයේ නව තොරතුරු බෙදාගනු ඇත. ඔහු අසාර්ථක වීමට හේතු සහ Amazon හි බෙදා හරින ලද පද්ධති සැලසුම් කිරීම ගැන. ඔක්තෝබර් 24 තවමත් හැකි ය ටිකට් හොඳ මිලකට, පසුව ගෙවන්න. අපි ඔබ එනතුරු HighLoad++ හි බලා සිටිමු, පැමිණ කතාබස් කරමු!
මූලාශ්රය: www.habr.com