Frankfurt में VPS hosting का चुनाव कैसे करें

Frankfurt में VPS hosting किसके लिए है

Frankfurt में VPS hosting उन projects के लिए उपयुक्त है जिनके users जर्मनी में, व्यापक जर्मन-भाषी बाज़ार में, या पूरे European Union में फैले हुए हैं। Frankfurt उन स्थानों में से एक है जहाँ European networks आपस में मिलते हैं और सीधे एक-दूसरे को traffic सौंपते हैं, इसलिए वहाँ स्थित सर्वर महाद्वीप के अधिकांश हिस्सों तक कुछ ही milliseconds में पहुँच जाता है। यदि आपके users मुख्य रूप से North America में हैं, तो European सर्वर उन्हें धीमा महसूस होगा, चाहे मशीन कितनी भी तेज़ क्यों न हो, क्योंकि दूरी एक ऐसी सीमा तय करती है जिसे tuning से दूर नहीं किया जा सकता।

दो अलग-अलग प्रश्न किसी स्थान का निर्णय करते हैं, और उन्हें आपस में मिला देने से ही गलत चुनाव होते हैं। पहला यह है कि आपके users कहाँ हैं, जो दूरी और round-trip time के बारे में एक प्रश्न है। दूसरा यह है कि आपका data कहाँ रहने की अनुमति है, जो एक कानूनी और संविदात्मक प्रश्न है। Frankfurt European दर्शकों के लिए पहले प्रश्न का एक सशक्त उत्तर देता है। दूसरे प्रश्न के लिए, यह एक विशिष्ट समस्या को दूर करता है और बाकी किसी चीज़ का समाधान नहीं करता।

Frankfurt इतना अच्छी तरह से कनेक्टेड क्यों है?

Frankfurt में DE-CIX (Deutsche Commercial Internet Exchange) स्थित है, जो एक IXP (internet exchange point) है। यह पीक ट्रैफिक और कनेक्टेड नेटवर्क्स की संख्या के मामले में दुनिया के सबसे बड़े IXPs में से एक है। IXP एक डेटा सेंटर के भीतर एक साझा स्विचिंग फैब्रिक होता है, जहाँ स्वतंत्र नेटवर्क एक-दूसरे से जुड़ते हैं, बजाय इसके कि वे अपने बीच ट्रैफिक ले जाने के लिए किसी बड़े नेटवर्क को भुगतान करें। DE-CIX अपने वर्तमान ट्रैफिक आँकड़े अपनी साइट पर प्रकाशित करता है। चूँकि ये आँकड़े बदलते रहते हैं, इसलिए किसी लेख में कॉपी किए गए आंकड़ों पर भरोसा करने के बजाय उन्हें वहीं देखें।

इसका व्यावहारिक प्रभाव कुल आंकड़ों के बारे में नहीं, बल्कि रास्तों (paths) के बारे में है। जब आपके प्रदाता का नेटवर्क और आपके विज़िटर का ISP (internet service provider) दोनों एक ही एक्सचेंज पर कनेक्ट होते हैं, तो उनके बीच का ट्रैफिक उस एक्सचेंज पर एक ही राउटेड हॉप (routed hop) पार करता है। जब वे स्थानीय रूप से पीयर (peer) नहीं करते हैं, तो ट्रैफिक को किसी तीसरे नेटवर्क तक पहुँचना पड़ता है जो उन दोनों को ले जाता है, और उस नेटवर्क का निकटतम हैंडओवर पॉइंट किसी दूसरे देश में हो सकता है। Amsterdam या London के माध्यम से ट्रैफिक का आदान-प्रदान करने वाले दो जर्मन नेटवर्क अतिरिक्त दूरी का भुगतान दो बार करते हैं, हर दिशा में एक बार। नेटवर्क इंजीनियर इसे tromboning कहते हैं, और यही वह सामान्य कारण है जिससे पास का सर्वर दूर दिखाई देता है।

आप इसे मान लेने के बजाय देख सकते हैं। जिस नेटवर्क की आप जाँच करना चाहते हैं, उससे अपने सर्वर के विरुद्ध mtr चलाएँ और रिवर्स DNS में हॉप के नाम पढ़ें। राउटर के होस्टनाम में आमतौर पर IATA एयरपोर्ट कोड शामिल होते हैं, इसलिए हॉप नाम में fra का मतलब Frankfurt, ams का मतलब Amsterdam और lhr का मतलब London होता है। एक जर्मन उपभोक्ता कनेक्शन से जर्मन सर्वर तक का रास्ता, जो बीच में lhr दिखाता है, आपको स्पष्ट रूप से बता रहा है कि अतिरिक्त मिलीसेकंड कहाँ खर्च हुए।

Frankfurt आपके उपयोगकर्ताओं से कितनी दूर है?

फाइबर में प्रकाश की गति निर्वात (vacuum) में उसकी गति की लगभग दो-तिहाई, यानी 200,000 किलोमीटर प्रति सेकंड के करीब होती है। एक राउंड ट्रिप में रास्ता दो बार तय होता है, इसलिए d किलोमीटर की दूरी पर सबसे तेज़ संभव राउंड ट्रिप d/100 मिलीसेकंड की होती है। यह एक न्यूनतम सीमा (floor) है, और यह उपयोगी है क्योंकि भौतिकी के नियमों के अनुसार इससे तेज़ कुछ भी नहीं हो सकता।

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

इनकी गणना सीधी रेखा की दूरी से की गई है, न कि मापी गई है। अंतिम कॉलम को उस सर्वोत्तम स्थिति के रूप में पढ़ें जिसकी भौतिकी अनुमति देती है। वास्तविक माप आमतौर पर इस न्यूनतम सीमा के 1.5 से 2 गुना के बीच होते हैं, क्योंकि फाइबर केबल ग्रेट सर्कल के बजाय सड़कों और नदी की घाटियों का अनुसरण करती हैं, और रास्ते में आने वाला प्रत्येक राउटर फॉरवर्डिंग और कतारबद्ध होने (queuing) में थोड़ा विलंब जोड़ता है।

Berlin, Frankfurt से 424 किमी दूर है, जिसकी न्यूनतम सीमा 4.2 ms है। Madrid यहाँ से 1,419 किमी दूर है, जिसकी न्यूनतम सीमा 14.2 ms है, और यह यहाँ से EU का सबसे दूर का कोना है। New York 6,206 किमी दूर है जिसकी न्यूनतम सीमा 62.1 ms है, यही कारण है कि ट्रांसअटलांटिक दर्शकों के लिए सेवा देना एक स्थान संबंधी निर्णय है, न कि ट्यूनिंग की समस्या।

एक धीमा round trip पेज लोड की लागत को कैसे प्रभावित करता है?

एक round trip का अर्थ शायद ही कभी केवल एक round trip होता है। एक HTTPS connection खोलने में TCP (transmission control protocol) handshake के लिए एक round trip और TLS (transport layer security) 1.3 handshake के लिए एक और round trip की लागत आती है। इसके बाद, response का पहला byte वापस आने से पहले एक तीसरा round trip लगता है। TLS 1.2 इसमें एक चौथा round trip और जोड़ देता है। यदि DNS (domain name system) lookup पहले से cached नहीं है, तो यह कम से कम एक और round trip जोड़ता है, जो कि एक अलग सर्वर पर होता है।

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

यहाँ round-trip कॉलम Frankfurt सर्वर तक के एक संभावित path के बारे में एक अनुमान है, और दूसरा कॉलम उस पर की गई गणना है: पहले byte के आने से पहले तीन round trips। Frankfurt में बैठा एक user 15 ms प्रतीक्षा करता है। Singapore में बैठा एक user, 170 ms के round-trip समय पर, उसी response के लिए 510 ms प्रतीक्षा करता है, इससे पहले कि browser कुछ भी render कर सके।

यह multiplier ही मुख्य बिंदु है। RTT (round-trip time) का प्रत्येक अतिरिक्त millisecond पहले byte के आने से पहले लगभग तीन milliseconds की लागत जोड़ता है, और यह लागत बढ़ती रहती है। HTML एक stylesheet का नाम बताता है, stylesheet एक font का नाम बताती है, और इनमें से प्रत्येक discovery उसी connection पर एक और round trip है। दूरी के कुछ सौ milliseconds जोड़ने से एक ऐसा पेज जो तुरंत लोड होता हुआ महसूस होता था, वह धीमा महसूस होने लगता है, जबकि सर्वर बिल्कुल वही काम बिल्कुल उतने ही समय में कर रहा होता है।

यह उस सीमा को भी निर्धारित करता है जिसे एक CDN (content delivery network) ठीक कर सकता है। user के पास cache से serve की गई static files लंबी दूरी को पार करने से बच जाती हैं। एक logged-in dashboard जिसे आपके database से कोई प्रश्न पूछना है, वह ऐसा नहीं कर सकता: वह request अभी भी पूरी दूरी को दो बार तय करती है। origin सर्वर को उन लोगों के पास रखना जो login करते हैं, वह काम है जो कोई भी cache आपके लिए नहीं कर सकता।

मैं इसे अपने उपयोगकर्ताओं के स्थान से कैसे मापूँ?

इन्हें उस नेटवर्क पर स्थित मशीन से चलाएँ जिसकी आप परवाह करते हैं, आदर्श रूप से उस देश के घर या कार्यालय के कनेक्शन से जहाँ आप सेवा प्रदान करते हैं। किसी अन्य डेटा सेंटर में स्थित सर्वर से मापना आपको डेटा सेंटर के रास्तों के बारे में बताता है, न कि आपके उपयोगकर्ताओं के बारे में। नीचे दिए गए कमांड स्वयं चलाने के उदाहरण हैं: केवल वही लेटेंसी आंकड़े कार्रवाई के योग्य हैं जिन्हें आपने स्वयं मापा है।

ping -c 20 your-server.example.com

सारांश पंक्ति rtt min/avg/max/mdev = ... को दर्शाती है। सामान्य स्थिति के लिए avg और जिटर (पैकेट के बीच का अंतर) के लिए mdev पढ़ें। एक सामान्य avg के साथ उच्च mdev का अर्थ है कि रास्ता अस्थिर है, और यह SSH या वॉयस जैसे इंटरैक्टिव कार्यों को थोड़े अधिक औसत लेटेंसी की तुलना में अधिक प्रभावित करता है।

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r लाइव डिस्प्ले के बजाय एक रिपोर्ट प्रिंट करता है, -w लंबे होस्टनामों को बरकरार रखता है, -z प्रत्येक हॉप का AS (ऑटोनॉमस सिस्टम) नंबर दिखाता है, और -c 50 पचास चक्र भेजता है। एक मध्य हॉप पर दिखाई देने वाला लॉस, यदि अंतिम हॉप पर कोई लॉस नहीं है, तो यह सामान्य है और कोई खराबी नहीं है: कई राउटर स्वयं के लिए उत्पन्न ICMP रिप्लाई को रेट-लिमिट करते हैं जबकि बाकी सब कुछ ठीक से फॉरवर्ड करते हैं। जो लॉस एक हॉप से शुरू होकर उसके बाद के हर हॉप तक जारी रहता है, वह वास्तविक लॉस है।

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

प्रत्येक फ़ील्ड अनुरोध शुरू होने के बाद से संचयी सेकंड है, इसलिए आप इसे घटाकर पढ़ते हैं। time_namelookup DNS है। time_connect में से उसे घटाने पर TCP हैंडशेक मिलता है, जो लगभग एक राउंड ट्रिप के बराबर है। time_appconnect में से time_connect घटाने पर TLS हैंडशेक मिलता है। time_starttransfer में से time_appconnect घटाने पर आपके एप्लिकेशन का अपना सोचने का समय और एक अतिरिक्त राउंड ट्रिप मिलता है। यदि अंतराल छोटे हैं और total अभी भी बड़ा है, तो समस्या आपके कोड में है, शहर में नहीं।

लेटेंसी के बजाय थ्रूपुट के लिए, VPS पर iperf3 -s चलाएँ, फ़ायरवॉल पर उसका पोर्ट खोलें, और डाउनलोड दिशा का परीक्षण करने के लिए क्लाइंट से iperf3 -c your-server.example.com -R चलाएँ। उन स्थानों से मापने के लिए जहाँ आपके पास मशीन नहीं है, RIPE Atlas आपको पूरे यूरोप में प्रोब प्रदान करता है। जब आप दो नेटवर्क के बजाय दो सर्वरों की तुलना करते हैं, तो एकमुश्त संख्याओं के बजाय एक निश्चित विधि का उपयोग करें, जिसके लिए एक दोहराने योग्य VPS बेंचमार्क है।

क्या Frankfurt में स्थित सर्वर मेरे प्रोजेक्ट को GDPR compliant बनाता है?

नहीं, और इसका कारण स्पष्ट रूप से समझना आवश्यक है। GDPR (General Data Protection Regulation) इस आधार पर लागू होता है कि आप किसका व्यक्तिगत डेटा प्रोसेस कर रहे हैं और आपका संगठन कहाँ स्थापित है, न कि इस पर कि हार्डवेयर किस देश में स्थित है। सर्वर को Frankfurt ले जाने से compliance सुनिश्चित नहीं होता, और EU के बाहर सर्वर चलाने से यह स्वतः ही भंग नहीं हो जाता। स्थान केवल कई कारकों में से एक है।

EU या व्यापक EEA (European Economic Area) के भीतर होस्टिंग करने से जो समस्या दूर होती है, वह है अंतरराष्ट्रीय डेटा ट्रांसफर का प्रश्न। इस विनियमन में EEA के बाहर व्यक्तिगत डेटा भेजने पर एक पूरा अध्याय है, जिसके लिए adequacy decision या standard contractual clauses जैसे कानूनी साधन की आवश्यकता होती है। Frankfurt में रहने वाला डेटा ट्रांसफर नहीं हो रहा है, इसलिए वह अध्याय उस चरण पर लागू नहीं होता। यह एक वास्तविक सरलीकरण है, और लाभ का यही सही दायरा है।

बाकी सब कुछ आपकी जिम्मेदारी है। आपको अभी भी प्रत्येक उद्देश्य के लिए एक कानूनी आधार, अपने डेटाबेस में मौजूद लोगों के लिए कार्यशील एक्सेस और हटाने के अधिकार, एक retention limit जिसे आप वास्तव में लागू करते हैं, जोखिम के अनुरूप सुरक्षा उपाय, और व्यक्तिगत डेटा breach की जानकारी होने के 72 घंटों के भीतर पर्यवेक्षी प्राधिकरण को रिपोर्ट करने की आवश्यकता है। आपको अपने होस्टिंग प्रदाता के साथ एक processor agreement की भी आवश्यकता है, जिसे जर्मनी में Auftragsverarbeitungsvertrag या AVV के रूप में जाना जाता है। यह भी ध्यान रखें कि Frankfurt में स्थित सर्वर में भी डेटा ट्रांसफर शामिल हो सकता है यदि EEA के बाहर के सपोर्ट स्टाफ के पास इसका एक्सेस हो, इसलिए जाँचें कि keys किसके पास हैं।

जर्मनी इसके ऊपर अपनी एक परत जोड़ता है: संघीय BDSG (Bundesdatenschutzgesetz) राष्ट्रीय नियमों के साथ विनियमन का पूरक है, और कर्मचारी डेटा वह क्षेत्र है जो लोगों को सबसे अधिक आश्चर्यचकित करता है। यह अनुभाग सामान्य पृष्ठभूमि है, कानूनी सलाह नहीं। European Data Protection Board आधिकारिक दिशानिर्देश edpb.europa.eu पर प्रकाशित करता है, और कोई भी ऐसी बात जिसके वास्तविक परिणाम हों, उसके लिए ट्यूटोरियल के बजाय एक योग्य सलाहकार की आवश्यकता होती है।

सर्वर पर मुझे क्या बदलना चाहिए?

सिस्टम क्लॉक को UTC (coordinated universal time) पर रखें और अपने एप्लिकेशन में टाइमस्टैम्प को फॉर्मेट करें। जर्मनी में daylight saving का पालन किया जाता है, इसलिए स्थानीय समय साल में दो बार एक घंटे बदलता है, और अक्टूबर के अंत में एक घंटा दोबारा आता है। स्थानीय समय में लिखे गए लॉग्स में उस रात 02:30 की दो प्रविष्टियाँ होती हैं, और विभिन्न क्षेत्रों में उनका मिलान करना अनुमान लगाने जैसा हो जाता है। यदि आप अभी भी सर्वर पर स्थानीय समय चाहते हैं, तो इसे स्पष्ट रूप से सेट करें और जाँचें:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

आउटपुट में गर्मियों में Time zone: Europe/Berlin (CEST, +0200) और सर्दियों में +0100 दिखना चाहिए।

डिफ़ॉल्ट C locale के तहत जर्मन टेक्स्ट गलत तरीके से सॉर्ट होता है, क्योंकि C सॉर्टिंग रॉ बाइट्स की तुलना करती है। Locale जनरेट करें और अंतर देखें:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

पहली सॉर्टिंग Äpfel को Zebra के बाद रखती है, क्योंकि UTF-8 में इसका पहला बाइट किसी भी ASCII अक्षर से अधिक होता है। दूसरी सॉर्टिंग इसे Apfel के बगल में रखती है, जहाँ एक जर्मन पाठक इसकी अपेक्षा करता है। यह दिखने से कहीं अधिक महत्वपूर्ण है, क्योंकि PostgreSQL और MySQL डेटाबेस बनाते समय collation तय कर लेते हैं, और बाद में इसे बदलने का मतलब है इंडेक्स को फिर से बनाना। डेटा लोड करने से पहले ही निर्णय लें।

जर्मन पैकेज मिरर apt रन को छोटा कर देता है। Ubuntu 24.04 पर सोर्स /etc/apt/sources.list.d/ubuntu.sources में deb822 फॉर्मेट में होते हैं, इसलिए दूसरी फ़ाइल जोड़ने के बजाय URIs: लाइन को http://de.archive.ubuntu.com/ubuntu/ में बदलें। एक और फ़ाइल जोड़ने से आपको Target Packages ... is configured multiple times मिलेगा, जो deb822 डुप्लिकेट सोर्स एरर है और जब तक आप इसे ठीक नहीं करते, तब तक अपडेट रोक देता है।

AAAA रिकॉर्ड पब्लिश करें। कुछ जर्मन ISP उपभोक्ता कनेक्शनों को DS-Lite (dual-stack lite) सेटअप देते हैं, जहाँ ग्राहक के पास कोई सार्वजनिक IPv4 पता नहीं होता और उनका IPv4 ट्रैफ़िक कैरियर के ट्रांसलेशन गेटवे से होकर गुजरता है। वह गेटवे लेटेंसी बढ़ाता है और पीक आवर्स के दौरान कंजेशन पैदा करता है, जबकि IPv6 ट्रैफ़िक सीधे बाहर जाता है। रिकॉर्ड सेट करने के बाद दोनों रास्तों की जाँच करें:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

दूसरे कमांड से 200 का मतलब है कि IPv6 एंड-टू-एंड काम कर रहा है। Could not resolve host या कनेक्शन एरर का मतलब है कि रिकॉर्ड या लिसनर गायब है, और आपके DS-Lite विज़िटर धीमे रास्ते का उपयोग कर रहे हैं।

जब Frankfurt सही विकल्प न हो

• आपके उपयोगकर्ता संयुक्त राज्य अमेरिका में हैं। उन्हें वहीं से सेवा दें: Dallas में एक VPS देश के केंद्र के निकट है, और New York में VPS hosting पूर्वी तट और अटलांटिक पार करने वाले ट्रैफ़िक के लिए छोटा मार्ग है।
• आपके उपयोगकर्ता लैटिन अमेरिका में हैं। Frankfurt, São Paulo से New York की तुलना में अधिक दूर है, इसलिए उस दर्शक वर्ग के लिए Brazil में एक VPS ही सही विकल्प है।
• आपका डेटा EU के बाहर किसी विशिष्ट देश के भीतर रहना अनिवार्य है। कनाडाई सार्वजनिक क्षेत्र का कार्य इसका एक सामान्य उदाहरण है, और Canadian VPS hosting के लिए वास्तव में क्या मायने रखता है इस विषय पर जानकारी प्रदान करता है।
• आप एक game server चलाते हैं। खिलाड़ी round-trip time के हर मिलीसेकंड को महसूस करते हैं, इसलिए उनके निकट होना अन्य सभी विनिर्देशों से अधिक महत्वपूर्ण है: game servers के लिए VPS चुनना इस प्रक्रिया को स्पष्ट करता है।

कई देशों में फैले यूरोपीय दर्शकों के लिए, Frankfurt एक सुरक्षित एकल विकल्प है, और जैसे-जैसे आप बढ़ते हैं, यह सुरक्षित बना रहता है, क्योंकि जिन नेटवर्कों तक आपको पहुँचना है वे पहले से ही exchange पर मौजूद हैं। स्थानांतरित करने से पहले और बाद में अपने उपयोगकर्ताओं की स्थिति से मापें, और दोनों आँकड़ों को सुरक्षित रखें।

FAQ

क्या पूरे यूरोप के लिए Frankfurt में एक VPS पर्याप्त है?

अधिकांश प्रोजेक्ट्स के लिए, हाँ। सीधी दूरी के आधार पर Stockholm के लिए 12.0 ms और Madrid के लिए 14.2 ms का न्यूनतम समय लगता है। वास्तविक नेटवर्क पाथ इस न्यूनतम समय से 1.5 से 2 गुना अधिक होते हैं, इसलिए लगभग पूरा EU एक Frankfurt सर्वर से कुछ ही मिलीसेकंड की दूरी पर रहता है। दूसरा लोकेशन तब जोड़ें जब आपको किसी विशिष्ट देश से वास्तविक शिकायत मिले, या जब आपको गति के बजाय failover की आवश्यकता हो।

क्या Frankfurt में होस्टिंग करने से मेरा प्रोजेक्ट GDPR compliant हो जाता है?

नहीं। GDPR इस पर लागू होता है कि आप किसका व्यक्तिगत डेटा प्रोसेस कर रहे हैं और आप कहाँ स्थित हैं, न कि इस पर कि सर्वर कहाँ है। EU में होस्टिंग करने से उस हॉप के लिए अंतरराष्ट्रीय ट्रांसफर का प्रश्न समाप्त हो जाता है, जो एक वास्तविक सरलीकरण है और यही इसका एकमात्र लाभ है। आपको अभी भी एक वैध आधार, डेटा विषय अधिकारों की कार्यप्रणाली, रिटेंशन लिमिट, सुरक्षा उपाय, 72 घंटों के भीतर breach की रिपोर्टिंग और अपने प्रदाता के साथ एक प्रोसेसर एग्रीमेंट (जर्मनी में इसे AVV कहा जाता है) की आवश्यकता होगी। यह सामान्य जानकारी है, कानूनी सलाह नहीं।

Frankfurt और Berlin के बीच मुझे कितनी latency की अपेक्षा करनी चाहिए?

ये दोनों शहर 424 km दूर हैं, जो 4.2 ms का न्यूनतम round-trip time निर्धारित करता है। एक अच्छी तरह से पीयर किए गए पाथ में आमतौर पर न्यूनतम समय का 1.5 से 2 गुना समय लगता है। इसे Berlin के एक कनेक्शन से ping -c 20 your-server.example.com के साथ सत्यापित करें और rtt min/avg/max/mdev लाइन में avg मान देखें। यदि परिणाम इस रेंज से काफी अधिक है, तो इसका मतलब है कि ट्रैफिक जर्मनी से बाहर जाकर वापस आया है, जिसे mtr -rwzc 50 हॉप नामों में दिखा देगा।

क्या मुझे अपने Frankfurt सर्वर का timezone Europe/Berlin पर सेट करना चाहिए?

आमतौर पर नहीं। सिस्टम को UTC पर रखें ताकि लॉग्स की तुलना करना आसान रहे और कोई भी timestamp अस्पष्ट न हो। जर्मनी में वसंत ऋतु में CEST और शरद ऋतु में CET का उपयोग होता है। शरद ऋतु की रात को एक स्थानीय घंटा दो बार आता है, जिससे दो अलग-अलग घटनाओं का स्थानीय timestamp एक ही हो सकता है। समय को अपने एप्लिकेशन में स्थानीय ज़ोन के अनुसार फॉर्मेट करें, जहाँ आपके पास इसे सही ढंग से करने का संदर्भ होता है। यदि आप पूरे सर्वर को स्थानीय समय पर रखना चाहते हैं, तो sudo timedatectl set-timezone Europe/Berlin चलाएँ और timedatectl के साथ सत्यापित करें।

क्या केवल IPv4 वाला सर्वर जर्मन विजिटर्स के लिए समस्या पैदा करेगा?

यह काम करेगा, लेकिन उनमें से कुछ के लिए यह धीमा होगा। कई जर्मन ISPs उपभोक्ता कनेक्शनों को बिना पब्लिक IPv4 एड्रेस वाला DS-Lite सेटअप देते हैं। ऐसे ग्राहक केवल IPv4 वाले सर्वर तक कैरियर के ट्रांसलेशन गेटवे के माध्यम से पहुँचते हैं, जिससे latency बढ़ती है और व्यस्त समय में congestion होता है। एक AAAA रिकॉर्ड पब्लिश करने और IPv6 पर लिसन करने से उन्हें सीधा पाथ मिलता है। इसे dig AAAA your-server.example.com +short और curl -6 रिक्वेस्ट के साथ टेस्ट करें, और दोनों एड्रेस फैमिली से HTTP 200 रिस्पॉन्स की अपेक्षा रखें।