कसरी AWS ले यसको लोचदार सेवाहरू पकाउँछ। नेटवर्क स्केलिंग

Amazon Web Services नेटवर्कको स्केल 69 क्षेत्रहरूमा विश्वभर 22 क्षेत्रहरू छन्: संयुक्त राज्य अमेरिका, युरोप, एशिया, अफ्रिका र अष्ट्रेलिया। प्रत्येक जोनले 8 डाटा केन्द्रहरू सम्म समावेश गर्दछ - डाटा प्रशोधन केन्द्रहरू। प्रत्येक डाटा केन्द्रमा हजारौं वा सयौं हजार सर्भरहरू छन्। नेटवर्क यस्तो तरिकाले डिजाइन गरिएको छ कि सबै सम्भावित आउटेज परिदृश्यहरूलाई ध्यानमा राखिएको छ। उदाहरणका लागि, सबै क्षेत्रहरू एकअर्काबाट अलग छन्, र पहुँच क्षेत्रहरू धेरै किलोमिटरको दूरीमा विभाजित छन्। यदि तपाईंले केबल काट्नु भयो भने पनि, प्रणालीले ब्याकअप च्यानलहरूमा स्विच गर्नेछ, र जानकारीको हानि केही डेटा प्याकेटहरूमा हुनेछ। Vasily Pantyukhin नेटवर्क कुन अन्य सिद्धान्तहरूमा बनाइएको छ र यो कसरी संरचित छ भन्ने बारे कुरा गर्नेछ।

Vasily Pantyukhin .ru कम्पनीहरूमा युनिक्स प्रशासकको रूपमा सुरु भयो, 6 वर्षसम्म ठूलो सन माइक्रोसिस्टम हार्डवेयरमा काम गर्नुभयो, र EMC मा 11 वर्षसम्म डाटा-केन्द्रित संसारको प्रचार गर्नुभयो। यो स्वाभाविक रूपमा निजी क्लाउडहरूमा विकसित भयो, त्यसपछि सार्वजनिकमा सारियो। अब, एक Amazon Web Services आर्किटेक्टको रूपमा, उहाँले AWS क्लाउडमा लाइभ र विकास गर्न मद्दत गर्न प्राविधिक सल्लाह प्रदान गर्नुहुन्छ।

AWS त्रयी को अघिल्लो भाग मा, Vasily भौतिक सर्भर र डाटाबेस स्केलिंग को डिजाइन मा delved। नाइट्रो कार्डहरू, अनुकूलन KVM-आधारित हाइपरवाइजर, Amazon Aurora डाटाबेस - सामग्रीमा यी सबैको बारेमाकसरी AWS ले यसको लोचदार सेवाहरू पकाउँछ। स्केलिंग सर्भर र डाटाबेस" सन्दर्भ वा हेर्नको लागि पढ्नुहोस् भिडियो टेप भाषणहरू।

यस भागले नेटवर्क स्केलिंगमा ध्यान केन्द्रित गर्नेछ, AWS मा सबैभन्दा जटिल प्रणालीहरू मध्ये एक। फ्ल्याट नेटवर्कबाट भर्चुअल प्राइभेट क्लाउडमा भएको विकास र यसको डिजाइन, ब्ल्याकफुट र हाइपरप्लेनको आन्तरिक सेवाहरू, शोरयुक्त छिमेकीको समस्या, र अन्तमा - नेटवर्कको स्केल, ब्याकबोन र भौतिक केबलहरू। काट अन्तर्गत यो सबै बारे।

अस्वीकरण: तलका सबै कुरा Vasily को व्यक्तिगत विचार हो र Amazon Web Services को स्थिति संग मेल खाँदैन।

नेटवर्क स्केलिंग

AWS क्लाउड 2006 मा सुरु भएको थियो। उनको नेटवर्क एकदम आदिम थियो - एक समतल संरचना संग। निजी ठेगानाहरूको दायरा सबै क्लाउड भाडामा लिनेहरूका लागि सामान्य थियो। नयाँ भर्चुअल मेसिन सुरु गर्दा, तपाईंले गल्तिले यस दायराबाट उपलब्ध IP ठेगाना प्राप्त गर्नुभयो।

यो दृष्टिकोण लागू गर्न सजिलो थियो, तर मौलिक रूपमा क्लाउडको प्रयोग सीमित थियो। विशेष गरी, हाइब्रिड समाधानहरू विकास गर्न धेरै गाह्रो थियो जुन जमीनमा र AWS मा निजी नेटवर्कहरू संयोजन गर्दछ। सबैभन्दा सामान्य समस्या IP ठेगाना दायराहरू ओभरल्यापिंग थियो।

भर्चुअल निजी बादल

बादलको माग थियो। स्केलेबिलिटी र लाखौं भाडामा लिनेहरू द्वारा यसको प्रयोगको सम्भावनाको बारेमा सोच्ने समय आएको छ। समतल सञ्जाल प्रमुख अवरोध बनेको छ। त्यसकारण, हामीले प्रयोगकर्ताहरूलाई नेटवर्क स्तरमा कसरी एकअर्काबाट अलग्गै राख्ने भनेर सोच्यौं ताकि उनीहरूले स्वतन्त्र रूपमा IP दायराहरू छनौट गर्न सकून्।

जब तपाइँ नेटवर्क अलगावको बारेमा सोच्नुहुन्छ दिमागमा आउने पहिलो कुरा के हो? पक्कै पनि VLANs и VRF - भर्चुअल रूटिङ र फर्वार्डिङ.

दुर्भाग्यवश, यसले काम गरेन। VLAN ID केवल 12 बिट हो, जसले हामीलाई 4096 पृथक खण्डहरू मात्र दिन्छ। सबैभन्दा ठूला स्विचहरूले पनि अधिकतम 1-2 हजार VRFs प्रयोग गर्न सक्छन्। VRF र VLAN सँगै प्रयोग गर्दा हामीलाई केही मिलियन सबनेटहरू मात्र दिन्छ। यो निश्चित रूपमा लाखौं भाडामा लिनेहरूका लागि पर्याप्त छैन, जसमध्ये प्रत्येकले धेरै सबनेटहरू प्रयोग गर्न सक्षम हुनुपर्दछ।

हामी पनि आवश्यक संख्यामा ठूला बक्सहरू किन्न सक्दैनौं, उदाहरणका लागि, सिस्को वा जुनिपरबाट। त्यहाँ दुई कारणहरू छन्: यो पागल महँगो छ, र हामी तिनीहरूको विकास र प्याचिंग नीतिहरूको दयामा हुन चाहँदैनौं।

त्यहाँ एक मात्र निष्कर्ष छ - आफ्नै समाधान बनाउनुहोस्।

2009 मा हामीले घोषणा गर्‍यौं VPC - भर्चुअल निजी बादल। नाम अड्कियो र अब धेरै क्लाउड प्रदायकहरूले पनि यसलाई प्रयोग गर्छन्।

VPC एक भर्चुअल नेटवर्क हो SDN (सफ्टवेयर परिभाषित नेटवर्क)। हामीले L2 र L3 स्तरहरूमा विशेष प्रोटोकलहरू आविष्कार नगर्ने निर्णय गर्यौं। नेटवर्क मानक इथरनेट र IP मा चल्छ। नेटवर्कमा प्रसारणको लागि, भर्चुअल मेसिन ट्राफिक हाम्रो आफ्नै प्रोटोकल र्यापरमा इन्क्याप्सुलेटेड छ। यसले भाडामा लिने व्यक्तिको VPC सँग सम्बन्धित ID संकेत गर्छ।

साधारण सुनिन्छ। यद्यपि, त्यहाँ धेरै गम्भीर प्राविधिक चुनौतीहरू छन् जुन पार गर्न आवश्यक छ। उदाहरणका लागि, भर्चुअल MAC/IP ठेगानाहरू, VPC ID र सम्बन्धित भौतिक MAC/IP म्यापिङ गर्दा डाटा कहाँ र कसरी भण्डार गर्ने। AWS मापनमा, यो एक विशाल तालिका हो जुन न्यूनतम पहुँच ढिलाइ संग काम गर्नुपर्छ। यसका लागि जिम्मेवार म्यापिङ सेवा, जुन पातलो तहमा नेटवर्क भर फैलिएको छ।

नयाँ पुस्ताका मेसिनहरूमा, हार्डवेयर स्तरमा नाइट्रो कार्डहरूद्वारा इन्क्याप्सुलेशन गरिन्छ। पुरानो उदाहरणहरूमा, encapsulation र decapsulation सफ्टवेयर आधारित छन्। 

यो सामान्य सर्तहरूमा कसरी काम गर्छ भनेर पत्ता लगाउनुहोस्। L2 स्तर संग सुरु गरौं। मानौं कि हामीसँग आईपी 10.0.0.2 को साथ एक भौतिक सर्भर 192.168.0.3 मा भर्चुअल मेसिन छ। यसले भर्चुअल मेसिन 10.0.0.3 मा डाटा पठाउँछ, जुन 192.168.1.4 मा रहन्छ। ARP अनुरोध उत्पन्न गरी नेटवर्क नाइट्रो कार्डमा पठाइन्छ। सरलताको लागि, हामी मान्दछौं कि दुबै भर्चुअल मेसिनहरू एउटै "निलो" VPC मा बस्छन्।

नक्साले स्रोत ठेगानालाई आफ्नैसँग प्रतिस्थापन गर्छ र ARP फ्रेमलाई म्यापिङ सेवामा फर्वार्ड गर्छ।

म्यापिङ सेवाले L2 भौतिक नेटवर्कमा प्रसारणको लागि आवश्यक जानकारी फिर्ता गर्छ।

ARP प्रतिक्रियामा नाइट्रो कार्डले भौतिक नेटवर्कमा MAC लाई VPC मा ठेगानासँग बदल्छ।

डेटा स्थानान्तरण गर्दा, हामी तार्किक MAC र IP लाई VPC र्यापरमा लपेट्छौं। हामी यी सबैलाई उपयुक्त स्रोत र गन्तव्य IP नाइट्रो कार्डहरू प्रयोग गरेर भौतिक नेटवर्कमा प्रसारण गर्छौं।

भौतिक मेसिन जसमा प्याकेज गन्तव्यमा छ जाँच गर्दछ। ठेगाना स्पूफिङको सम्भावनालाई रोक्न यो आवश्यक छ। मेसिनले म्यापिङ सेवालाई विशेष अनुरोध पठाउँछ र सोध्छ: “भौतिक मेसिन 192.168.0.3 बाट मैले नीलो VPC मा 10.0.0.3 को लागि लक्षित प्याकेट प्राप्त गरें। के ऊ वैध छ? 

म्यापिङ सेवाले यसको स्रोत आवंटन तालिका जाँच गर्दछ र प्याकेटलाई पास गर्न अनुमति दिन्छ वा अस्वीकार गर्दछ। सबै नयाँ उदाहरणहरूमा, नाइट्रो कार्डहरूमा थप प्रमाणीकरण इम्बेड गरिएको छ। यसलाई सैद्धान्तिक रूपमा पनि बाइपास गर्न असम्भव छ। त्यसकारण, अर्को VPC मा संसाधनहरूमा स्पुफिङले काम गर्दैन।

अर्को, डाटा भर्चुअल मेसिनमा पठाइन्छ जसको लागि यो अभिप्रेत छ। 

म्यापिङ सेवाले विभिन्न सबनेटहरूमा भर्चुअल मेसिनहरू बीच डाटा स्थानान्तरणको लागि तार्किक राउटरको रूपमा पनि काम गर्दछ। सबै कुरा अवधारणात्मक रूपमा सरल छ, म विस्तारमा जानेछैन।

यो बाहिर जान्छ कि प्रत्येक प्याकेट प्रसारण गर्दा, सर्भरहरू म्यापिङ सेवामा फर्कन्छ। अपरिहार्य ढिलाइ कसरी व्यवहार गर्ने? क्यासिङअवश्य पनि।

सुन्दरता यो हो कि तपाइँ सम्पूर्ण विशाल तालिका क्यास गर्न आवश्यक छैन। भौतिक सर्भरले अपेक्षाकृत सानो संख्या VPC बाट भर्चुअल मेसिनहरू होस्ट गर्दछ। तपाईंले केवल यी VPC हरू बारे जानकारी क्यास गर्न आवश्यक छ। "पूर्वनिर्धारित" कन्फिगरेसनमा अन्य VPC हरूमा डेटा स्थानान्तरण अझै पनि वैध छैन। यदि VPC-peering जस्ता कार्यक्षमता प्रयोग गरिन्छ भने, सम्बन्धित VPC हरू बारे जानकारी थप रूपमा क्यासमा लोड गरिन्छ। 

हामीले VPC मा डाटा स्थानान्तरण क्रमबद्ध गर्यौं।

ब्ल्याकफुट

ट्राफिक बाहिर पठाउनु पर्ने अवस्थाहरूमा के गर्ने, उदाहरणका लागि इन्टरनेटमा वा VPN मार्फत जमीनमा? हामीलाई यहाँ मद्दत गर्छ ब्ल्याकफुट - AWS आन्तरिक सेवा। यो हाम्रो दक्षिण अफ्रिकी टोली द्वारा विकसित गरिएको हो। त्यसैले यो सेवा दक्षिण अफ्रिकामा बस्ने पेंगुइनको नाममा राखिएको हो।

ब्ल्याकफुटले ट्राफिकलाई डिक्याप्सुलेट गर्छ र यसको साथ के आवश्यक छ। डाटा जसरी इन्टरनेटमा पठाइन्छ।

VPN प्रयोग गर्दा डाटा डिक्याप्सुलेटेड र IPsec मा पुन: बेरिएको छ।

प्रत्यक्ष जडान प्रयोग गर्दा, ट्राफिक ट्याग गरी उपयुक्त VLAN मा पठाइन्छ।

हाइपरप्लेन

यो आन्तरिक प्रवाह नियन्त्रण सेवा हो। धेरै नेटवर्क सेवाहरू निगरानी आवश्यक छ डाटा प्रवाह अवस्था। उदाहरणका लागि, NAT प्रयोग गर्दा, प्रवाह नियन्त्रणले प्रत्येक IP:गन्तव्य पोर्ट जोडीमा एक अद्वितीय बाहिर जाने पोर्ट छ भनी सुनिश्चित गर्नुपर्छ। ब्यालेन्सर को मामला मा NLB - नेटवर्क लोड ब्यालेन्सर, डाटा प्रवाह सधैं एउटै लक्ष्य भर्चुअल मेसिनमा निर्देशित हुनुपर्छ। सुरक्षा समूह एक राज्य फायरवाल हो। यसले आगमन ट्राफिकलाई निगरानी गर्दछ र बाहिर जाने प्याकेट प्रवाहको लागि स्पष्ट रूपमा पोर्टहरू खोल्छ।

AWS क्लाउडमा, प्रसारण विलम्बता आवश्यकताहरू अत्यन्त उच्च छन्। त्यसैले होला हाइपरप्लेन सम्पूर्ण नेटवर्कको प्रदर्शनको लागि महत्वपूर्ण।

हाइपरप्लेन EC2 भर्चुअल मेसिनहरूमा बनाइएको छ। यहाँ कुनै जादू छैन, केवल चालाक। चाल यो हो कि यी ठूलो र्याम संग भर्चुअल मिसिन हो। सञ्चालनहरू लेनदेन हुन् र मेमोरीमा विशेष रूपमा प्रदर्शन गरिन्छ। यसले तपाईंलाई केवल दसौं माइक्रोसेकेन्डको ढिलाइ प्राप्त गर्न अनुमति दिन्छ। डिस्कसँग काम गर्दा सबै उत्पादकता नष्ट हुनेछ। 

हाइपरप्लेन यस्तो EC2 मेसिनहरूको एक ठूलो संख्याको वितरण प्रणाली हो। प्रत्येक भर्चुअल मेसिनमा 5 GB/s को ब्यान्डविथ हुन्छ। सम्पूर्ण क्षेत्रीय नेटवर्कमा, यसले ब्यान्डविथको अविश्वसनीय टेराबिट्स प्रदान गर्दछ र प्रशोधन गर्न अनुमति दिन्छ। प्रति सेकेन्ड लाखौं जडानहरू.

हाइपरप्लेनले स्ट्रिमहरूसँग मात्र काम गर्दछ। VPC प्याकेट encapsulation यसको लागि पूर्ण रूपमा पारदर्शी छ। यस आन्तरिक सेवामा सम्भावित जोखिमले अझै पनि VPC अलगावलाई तोड्नबाट रोक्न सक्छ। तलका स्तरहरू सुरक्षाको लागि जिम्मेवार छन्।

कोलाहल छिमेकी

अझै पनि समस्या छ कोलाहल छिमेकी - कोलाहल छिमेकी। मानौं हामीसँग 8 नोडहरू छन्। यी नोडहरूले सबै क्लाउड प्रयोगकर्ताहरूको प्रवाह प्रक्रिया गर्दछ। सबै कुरा ठीक देखिन्छ र लोड सबै नोडहरूमा समान रूपमा वितरित हुनुपर्छ। नोडहरू धेरै शक्तिशाली छन् र तिनीहरूलाई ओभरलोड गर्न गाह्रो छ।

तर हामी सम्भावित परिदृश्यहरूमा आधारित हाम्रो वास्तुकला निर्माण गर्छौं। 

कम सम्भावना भनेको असम्भव भन्ने होइन।

हामी एक वा धेरै प्रयोगकर्ताहरूले धेरै लोड उत्पन्न गर्ने अवस्थाको कल्पना गर्न सक्छौं। सबै हाइपरप्लेन नोडहरू यो लोड प्रशोधनमा संलग्न छन् र अन्य प्रयोगकर्ताहरूले सम्भावित रूपमा कुनै प्रकारको प्रदर्शन हिटको अनुभव गर्न सक्छन्। यसले क्लाउडको अवधारणालाई तोड्छ, जसमा भाडामा लिनेहरूसँग एकअर्कालाई प्रभाव पार्ने क्षमता हुँदैन।

शोर छिमेकीको समस्या कसरी समाधान गर्ने? दिमागमा आउने पहिलो कुरा शार्डिंग हो। हाम्रा 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%

वास्तविक अवस्थामा, हाइपरप्लेन नोडहरू र प्रयोगकर्ताहरूको ठूलो संख्याको साथ, अन्य प्रयोगकर्ताहरूमा एक शोर छिमेकीको सम्भावित प्रभाव न्यूनतम छ। यो विधि भनिन्छ मिक्सिङ शेर्डिङ - शफल शेर्डिङ। यसले नोड विफलताको नकारात्मक प्रभावलाई कम गर्छ।

धेरै सेवाहरू हाइपरप्लेनको आधारमा बनाइएका छन्: नेटवर्क लोड ब्यालेन्सर, NAT गेटवे, Amazon EFS, AWS PrivateLink, AWS ट्रान्जिट गेटवे।

नेटवर्क स्केल

अब नेटवर्क को स्केल को बारे मा कुरा गरौं। अक्टोबर 2019 को लागि AWS ले यसको सेवाहरू प्रदान गर्दछ 22 क्षेत्रहरू, र 9 थप योजना छन्।

• प्रत्येक क्षेत्रले धेरै उपलब्धता क्षेत्रहरू समावेश गर्दछ। तिनीहरूमध्ये 69 संसारभर छन्।
• प्रत्येक AZ मा डेटा प्रशोधन केन्द्रहरू हुन्छन्। त्यहाँ जम्मा 8 भन्दा बढी छैन।
• डाटा सेन्टरमा ठूलो संख्यामा सर्भरहरू छन्, केही 300 सम्म।

अब यी सबैको औसत गरौं, गुणन गरौं र प्रतिबिम्बित गर्ने प्रभावशाली आकृति प्राप्त गरौं अमेजन क्लाउड स्केल.

त्यहाँ उपलब्धता क्षेत्र र डाटा केन्द्र बीच धेरै अप्टिकल लिङ्कहरू छन्। हाम्रो सबैभन्दा ठूलो क्षेत्रहरू मध्ये एकमा, 388 च्यानलहरू एकअर्का र अन्य क्षेत्रहरू (ट्रान्जिट केन्द्रहरू) सँग सञ्चार केन्द्रहरू बीच AZ सञ्चारको लागि मात्र राखिएको छ। कुल मिलाएर यो पागलपन दिन्छ 5000 Tbit.

ब्याकबोन AWS विशेष गरी क्लाउडको लागि बनाइएको र अप्टिमाइज गरिएको हो। हामी यसलाई च्यानलहरूमा निर्माण गर्छौं 100 जीबी / एस। हामी तिनीहरूलाई पूर्ण रूपमा नियन्त्रण गर्छौं, चीनका क्षेत्रहरू बाहेक। ट्राफिक अन्य कम्पनीहरूको भारसँग साझेदारी गरिएको छैन।

अवश्य पनि, हामी निजी ब्याकबोन नेटवर्कको साथ मात्र क्लाउड प्रदायक होइनौं। अधिक र अधिक ठूला कम्पनीहरू यो बाटो पछ्याउँदै छन्। यो स्वतन्त्र अनुसन्धानकर्ताहरु द्वारा पुष्टि गरिएको छ, उदाहरण को लागी टेलिजियोग्राफी.

ग्राफले सामग्री प्रदायक र क्लाउड प्रदायकहरूको साझेदारी बढ्दै गएको देखाउँछ। यस कारण, ब्याकबोन प्रदायकहरूको इन्टरनेट ट्राफिकको अंश लगातार घट्दै गएको छ।

म व्याख्या गर्नेछु किन यो हुन्छ। पहिले, धेरैजसो वेब सेवाहरू पहुँचयोग्य थिए र सीधा इन्टरनेटबाट खपत हुन्थ्यो। आजकल, अधिक र अधिक सर्भरहरू क्लाउडमा अवस्थित छन् र मार्फत पहुँचयोग्य छन् CDN - सामग्री वितरण नेटवर्क। स्रोत पहुँच गर्न, प्रयोगकर्ता इन्टरनेट मार्फत मात्र नजिकको CDN PoP मा जान्छ - उपस्थितिको बिन्दु। प्रायः यो नजिकै छ। त्यसपछि यसले सार्वजनिक इन्टरनेट छोड्छ र एट्लान्टिक पार एक निजी ब्याकबोन मार्फत उड्छ, उदाहरणका लागि, र सीधा स्रोतमा पुग्छ।

म सोच्दछु कि यदि यो प्रवृत्ति जारी रह्यो भने 10 वर्षमा इन्टरनेट कसरी परिवर्तन हुन्छ?

भौतिक च्यानलहरू

ब्रह्माण्डमा प्रकाशको गति कसरी बढाउने भनेर वैज्ञानिकहरूले अहिलेसम्म पत्ता लगाउन सकेका छैनन्, तर अप्टिकल फाइबर मार्फत प्रसारण गर्ने तरिकामा उनीहरूले ठूलो प्रगति गरेका छन्। हामी हाल 6912 फाइबर केबलहरू प्रयोग गर्दछौं। यसले महत्त्वपूर्ण रूपमा तिनीहरूको स्थापनाको लागत अनुकूलन गर्न मद्दत गर्दछ।

केही क्षेत्रहरूमा हामीले विशेष केबलहरू प्रयोग गर्नुपर्छ। उदाहरणका लागि, सिड्नी क्षेत्रमा हामी दीमकहरू विरुद्ध विशेष कोटिंग भएको केबलहरू प्रयोग गर्छौं। 

समस्याहरूबाट कोही पनि सुरक्षित छैनन् र कहिलेकाहीँ हाम्रा च्यानलहरू क्षतिग्रस्त हुन्छन्। दायाँको तस्बिरले अमेरिकी क्षेत्रहरू मध्ये एकमा अप्टिकल केबलहरू देखाउँदछ जुन निर्माण कार्यकर्ताहरूले च्यातिएको थियो। दुर्घटनाका कारण १३ वटा डाटा प्याकेट मात्र हराएका छन्, जुन अचम्मको कुरा हो । एक पटक फेरि - केवल 13! प्रणाली शाब्दिक रूपमा ब्याकअप च्यानलहरूमा स्विच गरियो - स्केल काम गरिरहेको छ।

हामीले Amazon का केही क्लाउड सेवाहरू र प्रविधिहरू मार्फत अगाडि बढ्यौं। म आशा गर्छु कि तपाईलाई हाम्रा ईन्जिनियरहरूले समाधान गर्ने कार्यहरूको स्केलको बारेमा कम्तिमा केही विचार छ। व्यक्तिगत रूपमा, मलाई यो धेरै रोमाञ्चक लाग्छ। 

यो AWS यन्त्रको बारेमा Vasily Pantyukhin बाट त्रयीको अन्तिम भाग हो। IN पहिलो भागहरूले सर्भर अप्टिमाइजेसन र डाटाबेस स्केलिंग, र मा वर्णन गर्दछ दोस्रो - सर्भर रहित कार्यहरू र फायरक्रेकर।

मा हाईलोड++ नोभेम्बरमा Vasily Pantyukhin ले Amazon उपकरणको नयाँ विवरण साझा गर्नेछ। उहाँले भन्नेछौ असफलता को कारणहरु र Amazon मा वितरित प्रणाली को डिजाइन को बारे मा। अक्टोबर 24 अझै सम्भव छ बुक गर्न राम्रो मूल्यमा टिकट, र पछि तिर्नुहोस्। हामी HighLoad++ मा तपाईंको लागि पर्खिरहेका छौं, आउनुहोस् र च्याट गरौं!

स्रोत: www.habr.com