मैं यह कैसे निर्धारित कर सकता हूं कि किसी विशेष क्षेत्र के ग्राहकों को सेवा देने के लिए कौन सा AWS स्थान सर्वश्रेष्ठ है?

Question

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

मैं एक एप्लिकेशन विकसित कर रहा हूं जो मुख्य रूप से भारतीय ग्राहकों के लिए लक्षित है। इसलिए, मैं सिंगापुर या टोक्यो को एक विकल्प के रूप में मान रहा हूं।

Answer 1

कस्टम उपयोग के लिए न्यूनतम विलंबता AWS स्थान निर्धारित करना

टर्नकी लिनक्स के स्मार्ट और इनोवेटिव लोगों ने हाल ही में आपकी समस्या के समाधान के लिए अपना पक्ष रखा है, GHHub पर AWS क्षेत्रीय डेटा केंद्रों की मैपिंग देखें :

इस परियोजना का उपयोग किसी उपयोगकर्ता के लिए निकटतम AWS डेटा सेंटर को खोजने के लिए टर्नकी हब द्वारा उपयोग किए गए अनुक्रमित (और संदर्भ के लिए दृश्य मानचित्र ) को उत्पन्न करने के लिए किया जाता है । [जोर मेरा]

जियोआईपी और इंडेक्सिंग का उपयोग करके निकटतम डेटा सेंटर को खोजने के साथ-साथ अनुवर्ती पोस्ट में जियोआईपी और इंडेक्सिंग का उपयोग करके निकटतम एपीटी पैकेज संग्रह को खोजने के लिए उपयोग में एल्गोरिथ्म आगे विस्तृत है ।

थोड़ा सा नौटंकी करते समय, दृश्य गंभीरता से शांत होता है और सम्मान की पुष्टि करता है। प्रथम दृष्टया आश्चर्यजनक तथ्य पर जोश का कारण बताता है , जो कि ऑस्ट्रेलिया में पहले से ही उल्लेखित है , जो कि वर्तमान में ऑस्ट्रेलिया में उपयोगकर्ताओं को एशिया प्रशांत (सिंगापुर / एपी-दक्षिण-पूर्व) के बजाय यूएस वेस्ट (उत्तरी कैलिफोर्निया / यूएस-पश्चिम -1) के माध्यम से बेहतर विलंबता देते हैं। -1) क्षेत्र। ( टिप : निचले दाएं कोने पर फ्यूचर केबल्स की जाँच से पता चलता है कि यह बदलने की संभावना है, जो ग्रेग के केबल मैप में और विस्तृत है , जो इंगित करता है कि ऑस्ट्रेलिया आने वाले वर्षों में दोनों AWS स्थानों के बीच कूद सकता है;)

अमेज़ॅन रूट 53 के माध्यम से स्वचालित रूप से निम्नतम विलंबता AWS स्थान का उपयोग करना

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

इससे भी महत्वपूर्ण बात है, हालांकि, एडब्ल्यूएस सिर्फ भौगोलिक डीएनएस समर्थन Jahufar की घोषणा की है उल्लेख किया पहले से ही देख परिचयात्मक पोस्ट मल्टी क्षेत्र विलंबता आधारित रूटिंग अब एडब्ल्यूएस के लिए उपलब्ध है, जो उपलब्ध है कि शक्तियों ही विलंबता आधारित रूटिंग प्रौद्योगिकी बना रही है अमेज़न CloudFront के उपयोगकर्ताओं के लिए अमेज़न EC2 , इलास्टिक लोड संतुलन , और अधिक।

तो यदि आपका वातावरण पहले से ही एक ऑटो स्केलिंग EC2 इंस्टेंस आर्किटेक्चर से युक्त है, तो बस इस विलंबता आधारित रूटिंग को लागू करने से आपकी समस्या का समाधान स्वचालित रूप से हो जाना चाहिए।

हालांकि उपयोग का मामला स्पष्ट रूप से कई एडब्ल्यूएस क्षेत्रों में घूमने वाले प्रसाद को लक्षित करता है, लेटेंसी आधारित रूटिंग और भारित राउंड रॉबिन रिकॉर्ड सेट्स के आसपास की परिष्कृत विशेषताएं आपको वांछित जानकारी को और भी आसानी से निर्धारित करने की अनुमति दे सकती हैं।

Answer 2

Cloudping.info की कोशिश करें

यह आपके ब्राउज़र से प्रत्येक AWS क्षेत्र में HTTP पिंग करेगा।

Region  Latency
US-East (Virginia)  28 ms
US-West (California)    100 ms
US-West (Oregon)    110 ms
Europe (Ireland)    100 ms
Europe (Frankfurt)  119 ms
Asia Pacific (Singapore)    269 ms
Asia Pacific (Sydney)   239 ms
Asia Pacific (Japan)    209 ms
South America (Brazil)  147 ms

SO व्यवस्थापक के लिए नोट : मैं इस सेवा से संबद्ध नहीं हूं। मुझे यह AWS प्रमाणीकरण के लिए मिलते समय मिला।

Comments

यह उपयोगी था। टोक्यो से किसी कारण के लिए, बीजिंग सबसे अधिक विलंबता वाला क्षेत्र है।

— एंटोनियो वैल

मैं कुछ सेकंड के भीतर विलंबता प्राप्त करने में सक्षम था।

— नागेश

Answer 3

गति परीक्षण के लिए एक वेबसाइट भी है: https://cloudharmony.com/speedtest यदि आप आसानी से जांचना चाहते हैं कि आपके लिए कौन सा क्षेत्र सबसे अच्छा है।

Answer 4

यहाँ एक कंसोल टूल है जो निकटतम aws क्षेत्र दिखाता है:

• https://github.com/ekalinin/awsping

यह गोलंग में लिखा है और उपयोग करने के लिए बहुत आसान है:

➥ ./awsping --verbose 1
      Code            Region                                      Latency
    0 eu-central-1    Europe (Frankfurt)                         36.97 ms
    1 eu-west-1       Europe (Ireland)                           63.18 ms
    2 us-east-1       US-East (Virginia)                        126.52 ms
    3 ap-south-1      Asia Pacific (Mumbai)                     156.98 ms
    4 us-west-1       US-West (California)                      192.92 ms
    5 us-west-2       US-West (Oregon)                          226.23 ms
    6 sa-east-1       South America (São Paulo)                 247.74 ms
    7 ap-northeast-1  Asia Pacific (Tokyo)                      312.22 ms
    8 ap-northeast-2  Asia Pacific (Seoul)                      329.54 ms
    9 ap-southeast-2  Asia Pacific (Sydney)                     337.84 ms
   10 ap-southeast-1  Asia Pacific (Singapore)                  395.73 ms

क्षेत्रों को विलंबता द्वारा आदेश दिया जाता है।

आप इसे किसी भी सर्वर पर चला सकते हैं और आपके लिए निकटतम क्षेत्र निर्धारित कर सकते हैं।

Answer 5

विभिन्न क्षेत्रों में विलंबता का परीक्षण स्पष्ट रूप से उचित है! मैं ऑस्ट्रेलिया में स्थित हूं और यहां कई उपयोगकर्ता सिंगापुर की तुलना में यूएस पश्चिम में बेहतर विलंबता प्राप्त करते हैं - भाग में यह स्थानीय आईएसपी सहकर्मी और अंतर्राष्ट्रीय कनेक्टिविटी के लिए नीचे आता है। यदि आप जिस क्षेत्र को लक्षित कर रहे हैं, उसमें आपके उपयोगकर्ता हैं तो यह परीक्षण करना अपेक्षाकृत सरल है।

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

जैसा कि आप पहले से ही S3 और EC2 को सेवाओं के रूप में ध्यान में रखते हैं, जिसे आप उपयोग करना चाहते हैं और वे दोनों निकट क्षेत्रों में उपलब्ध हैं, मूल्यांकन करें कि क्या AWS की नई वेब सेवाएँ तुरंत महत्वपूर्ण हैं - यदि नहीं, तो कुछ (विलंबता) को बंद करके शूट करें।

Answer 6

अमेज़ॅन अब न्यूनतम अंत-उपयोगकर्ता विलंबता के आधार पर डेटासेंटर को रूट करने की क्षमता प्रदान कर रहा है। यह रूट 53 का नया "लेटेंसी आधारित रूटिंग" है!

http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html

Comments

क्या AWS S3 के लिए समान अवधारणा का उपयोग करने का कोई तरीका है?

— parsley72

Answer 7

हमारी लोकेशन से लेटेंसी चेक करने के लिए अच्छा टूल / साइट

http://www.cloudwatch.in/

Comments

यह समाधान विश्वसनीय नहीं है। यह विलंबता की रिपोर्ट करता है जो पिंग का उपयोग करके एक टर्मिनल से मेरे द्वारा मापे जाने की तुलना में बहुत अलग है। यह इस बात को भी प्रदर्शित नहीं करता है कि किस क्षेत्र के बीच कोठरी है और कौन सी फर्स्ट है।

— user1942586

Answer 8

EDIT: मार्क त्सई के जवाब को देखें। यह जाने का मार्ग है (जब मैंने यह लिखा था तो मार्ग 53 मौजूद नहीं था)

यह शायद ServerFault में है, लेकिन यहाँ जाता है:

जो आप मूल रूप से पूछ रहे हैं वह जियो डीएनएस है।

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

तब तक, आप Zerigo जैसे 3 पार्टी समाधानों में देख सकते हैं जो आपको जियो DNS सुविधा प्रदान करेंगे।

या यदि आप कट्टर हैं तो आप IP2Location के साथ BIND को कॉन्फ़िगर करके अपना रोल कर सकते हैं

EDIT: सर्वरफॉल्ट पर एक पोस्ट है जो जियो DNS प्रदाताओं के बारे में बात करता है

प्रदर्शन और AWS विश्वसनीयता के बारे में आपके प्रश्न के लिए: आपको अपने उपयोगकर्ता से निकटतम AZ से अपनी साइट की सेवा करने पर विचार करना चाहिए - यह गति के संदर्भ में सही समझ में आता है और आपके सभी उदाहरण एक ही AZ में नहीं है। आप एक सामान्य विचार प्राप्त करने के लिए AWS सेवा स्वास्थ्य डैशबोर्ड की जांच कर सकते हैं कि विभिन्न AZ में अमेजन की सेवाएं कितनी विश्वसनीय हैं। ध्यान दें कि यह डेटा सीधे अमेज़ॅन से है - मैंने कहीं और कोई स्वतंत्र आँकड़े नहीं देखे हैं।

Answer 9

http://blog.datapath.io/aws-network-latency-map इस जानकारी को प्राप्त करने के लिए एक वाणिज्यिक पेशकश पर चर्चा करता है। यह आपके द्वारा निर्दिष्ट स्थान से विलंबता समय दिखाता है, आपके द्वारा निर्दिष्ट AWS सेवा पर, एक मानचित्र पर।