Canada में VPS Hosting: क्या यह आवश्यक है?

क्या आपके VPS का Canada में होना आवश्यक है?

Canada में VPS hosting चुनना तब उचित है, जब कोई कानून या contract कहता है कि data Canada की सीमा के भीतर रहना चाहिए। यही एक अनिवार्य कारण है। Toronto के home connection से New York के data centre तक round trip लगभग 18 ms लेता है, जबकि Toronto के data centre तक लगभग 3 ms लगता है। लगभग कोई भी web application यह अंतर पहचान नहीं सकता।

तीन बातें लोगों को Canadian server चुनने के लिए प्रेरित करती हैं। Data residency एक कानूनी obligation है, इसलिए यह अपने-आप निर्णय स्पष्ट कर देती है। Latency को मापा जा सकता है और यह आम तौर पर लोगों की अपेक्षा से कम होती है। Canadian dollars में billing आपके accountant के लिए सुविधाजनक है। किसी अन्य आधार पर विकल्प देखने से पहले निर्धारित करें कि इनमें से पहली बात आप पर लागू होती है या नहीं।

यह post सामान्य रूप से बताती है कि नियम कैसे काम करते हैं। यह कानूनी सलाह नहीं है। यदि कोई privacy law आपके organisation पर लागू होता है, तो इसका उत्तर आपके counsel से मिलेगा।

डेटा का भौगोलिक निवास: एकमात्र कठोर आवश्यकता

PIPEDA (Personal Information Protection and Electronic Documents Act) कनाडा का संघीय निजी-क्षेत्र गोपनीयता कानून है। इसमें व्यक्तिगत जानकारी को देश के भीतर रखने की आवश्यकता नहीं है। इसके अनुसार विदेश में किसी प्रोसेसर को डेटा भेजना प्रोसेसिंग के लिए ट्रांसफर है: आपका संगठन डेटा के लिए जवाबदेह रहता है, प्रोसेसर को उसे तुलनीय सुरक्षा देनी होती है, और आपको लोगों को इस प्रक्रिया के बारे में स्पष्ट जानकारी देनी होती है। Office of the Privacy Commissioner ने 2019 में इन नियमों को कड़ा करने पर परामर्श किया था, लेकिन बाद में अपना मौजूदा रुख ही बनाए रखा। इसलिए यह आम दावा गलत है कि PIPEDA के अनुसार आपका डेटा कनाडा में ही रहना चाहिए, भले ही बहुत-सी hosting सामग्री इसे दोहराती हो।

वास्तविक residency नियम मौजूद हैं। वे अधिक सीमित क्षेत्रों में लागू होते हैं।

• Quebec's Law 25 के अनुसार व्यक्तिगत जानकारी को प्रांत के बाहर भेजने से पहले assessment करना आवश्यक है। जहां जानकारी पहुंचती है, वहां उसे पर्याप्त सुरक्षा भी मिलनी चाहिए। यह प्रावधान September 2023 से लागू है। यह कागजी प्रक्रिया और ऐसा निर्णय है जिसका आपको बचाव करने में सक्षम होना चाहिए, प्रतिबंध नहीं।
• Public-sector नियम public bodies और उनकी सेवा करने वाली कंपनियों पर लागू होते हैं। Nova Scotia's PIIDPA व्यक्तिगत जानकारी को Canada के बाहर store करने पर प्रतिबंध लगाता है। British Columbia's FIPPA में 2021 में amendment होने तक ऐसा ही नियम था; amendment के बाद assessment के आधार पर foreign storage की अनुमति है।
• Federal government के काम में Government of Canada's cloud direction का पालन होता है। इसके अनुसार Protected B और उससे उच्च स्तर के डेटा को Canada में ही रहना चाहिए।
• Provincial health privacy laws में health records को रखने के स्थान पर अपनी शर्तें होती हैं। ये शर्तें प्रत्येक province में अलग-अलग हैं।
• व्यवहार में customer contracts और public tenders सबसे सामान्य कारण होते हैं। यदि किसी security questionnaire में "data at rest in Canada" लिखा है, तो वह आपको statute जितनी ही मजबूती से बाध्य करता है, क्योंकि आपने उस पर हस्ताक्षर किए हैं।

व्यावहारिक परीक्षण सरल है। क्या आप उस clause की ओर संकेत कर सकते हैं? यदि आपके संगठन में कोई भी उस statute या contract का नाम नहीं बता सकता जिसमें Canada की आवश्यकता लिखी है, तो आपका निर्णय latency और price के आधार पर है।

क्या कनाडाई data centre US के कानूनी अधिकार-क्षेत्र से बाहर है?

अपने-आप नहीं। US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) किसी US provider के कब्जे, अभिरक्षा या नियंत्रण में मौजूद data पर लागू होता है, चाहे hardware कहीं भी स्थित हो। इसलिए किसी अमेरिकी कंपनी द्वारा संचालित Toronto region इसके अधिकार-क्षेत्र में आता है। यदि वास्तविक आवश्यकता geography के बजाय विदेशी कानूनी प्रक्रिया से संबंधित है, तो महत्वपूर्ण यह है कि service कौन संचालित करता है और encryption keys किसके पास हैं। भवन पर कनाडाई address होना अपने-आप इसका उत्तर नहीं देता।

Routing दूसरा अप्रत्याशित पहलू है। दो कनाडाई शहरों के बीच traffic अक्सर United States से होकर जाता है, क्योंकि ऐतिहासिक रूप से सस्ती peering वहीं उपलब्ध रही है। Researchers इसे boomerang routing कहते हैं। किसी को यह बताने से पहले कि आपके packets देश से बाहर नहीं जाते, traceroute चलाएँ।

traceroute vps.example.com

Hop names में nyc, chi या ash जैसे city codes होते हैं। ये names केवल संकेत हैं और पुराने हो सकते हैं। इसलिए इन्हें प्रमाण नहीं, बल्कि provider से पूछने का कारण मानें। Transit में मौजूद data के लिए विश्वसनीय उपाय वह encryption है जिसे आप स्वयं नियंत्रित करते हैं, न कि कोई map। यदि आप अपनी machines के बीच private path चाहते हैं, तो self-hosted WireGuard VPN आपको ऐसा path देता है जिसे fibre किस देश से होकर जाता है, इससे कोई फर्क नहीं पड़ता।

विलंबता: इसे मापें, अनुमान न लगाएं

फाइबर में प्रकाश लगभग 200 km प्रति मिलीसेकंड की दर से चलता है। इसलिए उपकरणों को शामिल करने से पहले ही दूरी के प्रत्येक 100 km पर round trip में लगभग 1 ms जुड़ता है। Toronto से Vancouver की सीधी दूरी लगभग 3,400 km है और केबल मार्ग इससे लंबा होता है। इसलिए न्यूनतम विलंबता लगभग 40 ms रहती है। वास्तविक नेटवर्क मार्गों में यह अधिक होती है।

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

ये Toronto में अच्छी तरह जुड़े consumer line के लिए प्रकाशित सामान्य आंकड़े हैं। इन्हें शुरुआती संदर्भ मानें, गारंटी नहीं। आपके वास्तविक आंकड़े access network और provider की peering पर निर्भर करते हैं। ये दिन के समय के अनुसार भी बदलते हैं।

दो पंक्तियों को ध्यान से पढ़ना चाहिए। Toronto से Montreal की विलंबता लगभग 12 ms है। यह इतनी कम है कि अधिकांश उपयोगों में दोनों शहर एक ही region की तरह काम करते हैं। Toronto से Vancouver की विलंबता लगभग 62 ms है। यह Toronto से Northern Virginia की 26 ms विलंबता से अधिक है। Canada में होना आपके users के निकट होने के समान नहीं है।

फिर भी last mile आमतौर पर सबसे अधिक प्रभाव डालता है। Home fibre में कुछ मिलीसेकंड जुड़ते हैं। Line व्यस्त होने पर cable connection में और अधिक विलंबता जुड़ती है। Mobile connection अपने आप में tens of milliseconds जोड़ता है। Toronto में किसी phone user को Toronto server तक 50 ms दिख सकते हैं। उस server को New York ले जाने पर उसके अनुभव में केवल कुछ प्रतिशत बदलाव आता है।

आपके उपयोगकर्ता जहाँ हैं, वहाँ से latency का परीक्षण कैसे करें

पहले पता करें कि आपके उपयोगकर्ता वास्तव में कहाँ हैं। आपके analytics पहले से sessions को city या region के अनुसार विभाजित करते हैं। अपने office के स्थान से अनुमान लगाने के बजाय उसी डेटा को पढ़ें।

फिर वहीं से माप करें। Ottawa की desk से Vancouver latency का परीक्षण नहीं किया जा सकता। लक्षित city में बीस मिनट के लिए hourly VPS किराये पर लें और उसके बाद उसे नष्ट कर दें। किसी colleague या customer से एक command चलाने को कहें। या https://atlas.ripe.net पर उपलब्ध free RIPE Atlas measurement network का उपयोग करें। इसमें Canadian cities में probes हैं और इनके माध्यम से ping चलाए जा सकते हैं।

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

अंतिम दो lines पढ़ें।

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg मुख्य संख्या है। mdev jitter है, यानी packets के बीच का फैलाव। छोटी path पर packet loss दिखे तो उसकी जाँच करना आवश्यक है। High jitter, थोड़ी अधिक average latency की तुलना में voice और games को अधिक प्रभावित करता है, क्योंकि receiver को सामान्य packet के बजाय सबसे धीमे packet के लिए buffer करना पड़ता है।

mtr --report --report-cycles 50 vps.example.com

mtr प्रत्येक hop के लिए loss दिखाता है। यदि यह permission error के साथ exit करे, तो इसे sudo के साथ चलाएँ। Middle hops पर अक्सर ऐसा loss दिखता है जो वास्तविक नहीं होता, क्योंकि routers अपने द्वारा बनाए गए ICMP replies को सबसे कम priority देते हैं। केवल वह loss वास्तविक है जो final line तक बना रहता है और आपके traffic को प्रभावित करता है। पहले bottom row पढ़ें, फिर ऊपर की ओर जाँच करें।

जब ICMP blocked हो या rate limited हो, तो इसके बजाय वास्तविक protocol का समय मापें।

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

प्रत्येक field request की शुरुआत से cumulative seconds दिखाता है। connect में से dns घटाने पर एक TCP round trip मिलता है। tls में से connect घटाने पर handshake का समय मिलता है। ttfb में से tls घटाने पर एक अतिरिक्त round trip और आपके application के response में लगा समय मिलता है। अधिकांश slow sites वास्तव में इसी अंतिम gap में समय खोती हैं। छोटी path पर ttfb का 0.8 s होना application problem है। Server को दूसरी city में ले जाने से यह समस्या दूर नहीं होगी।

Throughput के लिए server को VPS पर और client को उपयोगकर्ता की ओर से चलाएँ। iperf3 TCP 5201 पर listen करता है, इसलिए परीक्षण के लिए ufw से port खोलें और काम पूरा होने पर उसे फिर बंद कर दें।

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R direction को reverse करता है। इससे upload के साथ download भी मापा जाता है। -P 8 आठ parallel streams खोलता है। यदि आठ streams, एक stream की तुलना में बहुत तेज़ हों, तो सीमा link के बजाय लंबी path पर TCP window है, क्योंकि एक stream प्रत्येक round trip में केवल एक window भेज सकती है। Vancouver path पर वही window, New York path की तुलना में प्रति second लगभग एक-तिहाई data भेजती है। Long-haul backups भी इसी तरह काम करते हैं। इसी कारण restic के साथ off-site backups तेज़ line होने पर भी distant target के विरुद्ध slow लगते हैं।

iperf3 के चलने के दौरान दूसरे terminal में ping चलाते रहें। यदि transfer के दौरान round trip 20 ms से बढ़कर 300 ms हो जाए, तो यह आपके अपने access equipment में bufferbloat है। किसी data centre का स्थान बदलने से यह समस्या ठीक नहीं होगी।

एक से अधिक बार माप करें और evening में भी माप करें। 9pm पर congestion वही संख्या है जिसका सामना आपके उपयोगकर्ता करते हैं। 4am की संख्या वह है जिसे sales page दिखाना पसंद करेगा।

आपके कार्यभार के लिए राउंड-ट्रिप समय का अर्थ

ब्राउज़र कुछ भी प्रदर्शित करने से पहले, एक cold page load में चार राउंड ट्रिप लगते हैं।

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

DNS lookup आपके server के बजाय resolver तक जाता है और आमतौर पर cached रहता है, इसलिए warm visit में इसे छोड़ दिया जाता है। End to end गणना करने पर, cold load में New York path पर 72 ms और Vancouver path पर 248 ms की देरी होती है। एक अकेली 400 ms database query की तुलना में दोनों आंकड़े नगण्य हैं। Connection खुलने के बाद, HTTP/2 और HTTP/3 एक ही connection पर कई requests को एक साथ भेजते हैं। इसलिए यह लागत हर file के बजाय केवल एक बार आती है। Static assets को CDN (content delivery network) पर रखें। इससे उन assets के लिए origin का city बिल्कुल मायने नहीं रखता। इसी कारण Toronto तक 98 ms की देरी झेलने वाला European visitor भी fast page प्राप्त कर सकता है।

Real-time multiplayer games इसका उलटा उदाहरण हैं, क्योंकि round trip ही अनुभव का हिस्सा है। Fast action game में लगभग 50 ms से कम समय तत्काल महसूस होता है। Players लगभग 80 ms पर देरी महसूस करना शुरू करते हैं। 120 ms से अधिक होने पर वे server को दोष देते हैं। यहां region वास्तव में तय करता है कि product अच्छा है या नहीं। धीमी गति वाले servers में देरी अधिक आसानी से स्वीकार की जाती है। इसलिए VPS पर Minecraft server चलाना उन दूरियों पर भी ठीक चलता है, जो shooter game को खराब कर देंगी।

Databases के मामले में region का गलत चयन गंभीर नुकसान करता है। Application को एक region में और database को दूसरे region में कभी न रखें। हर query एक round trip होती है। 40 queries भेजने वाला page 40 round trips का समय लेता है। प्रत्येक query में 18 ms लगने पर इसमें लगभग एक सेकंड लगता है। प्रत्येक query में 62 ms लगने पर इसमें दो सेकंड से अधिक लगते हैं। यह उस page पर होता है जिसे database के उसी box पर होने पर 30 ms का समय मिला था। किसी दूसरे region में asynchronous replication read replicas और disaster recovery के लिए ठीक है। लंबे path पर synchronous commit करने से उस path की देरी हर write में जुड़ जाती है।

Interactive sessions इन दोनों के बीच आते हैं। SSH लगभग 100 ms तक आरामदायक रहता है और इसके बाद laggy महसूस होता है, क्योंकि हर keystroke के echo के वापस आने की प्रतीक्षा करनी पड़ती है। mosh स्थानीय रूप से अनुमान लगाता है और इस देरी का अधिकांश भाग छिपा देता है। Webhooks और internal APIs हमेशा उस service के समान region में होने चाहिए जिसे वे call करते हैं।

बिलिंग, मुद्रा और कर

Canadian dollars में भुगतान करने से आपके कार्ड जारीकर्ता द्वारा लिया जाने वाला foreign transaction fee बचता है, जो August 2026 तक आमतौर पर लगभग 2.5% था। इससे आपके लेखे एक ही मुद्रा में रहते हैं। Canadian provider GST या HST के साथ invoice जारी करता है। पंजीकृत business इसे input tax credit के रूप में वापस claim कर सकता है। यह वित्त से जुड़ा प्रश्न है और इसका उत्तर भी वित्तीय है। इससे यह तय नहीं होना चाहिए कि packets किस दिशा में जाएँ। Server की वास्तविक लागत और renewal pricing के प्रभाव से बचते हुए plans की तुलना करने का तरीका जानने के लिए VPS की वास्तविक मासिक लागत पढ़ें।

छोटा बाज़ार आपको क्या कीमत चुकवाता है

संयुक्त राज्य अमेरिका की तुलना में Canada एक छोटा होस्टिंग बाज़ार है, और ईमानदार सलाह में यह बताना भी शामिल है कि आपको क्या छोड़ना पड़ेगा।

• आपके पैसे के लिए प्रतिस्पर्धा करने वाले provider कम होते हैं, इसलिए उसी श्रेणी की मशीन के लिए RAM या disk की प्रति gigabyte कीमत आमतौर पर अधिक होती है।
• क्षमता Toronto और Montreal में केंद्रित है, जबकि Vancouver और Calgary में कम है। Failover के लिए दूसरा Canadian region अक्सर लंबा network path अपनाने या फिर देश से बाहर जाने का अर्थ रखता है।
• कोई छोटा regional host एक ही building को एक या दो upstream carrier के पीछे चला सकता है। पूछें कि कितने carrier हैं और उनमें से किसी एक के विफल होने पर क्या होता है।
• उपलब्ध hardware विकल्प सीमित होते हैं। US region में बड़े instance और GPU machine आसानी से मिल जाते हैं, इसलिए आपके पसंदीदा शहर में आपकी इच्छित size का GPU VPS उपलब्ध न हो।
• छोटे host में support coverage एक वास्तविक प्रश्न है, marketing का विषय नहीं। पूछें कि human support कब उपलब्ध रहता है।

कीमत के मामले में Montreal अपवाद है। Quebec की hydroelectric power सस्ती है और सर्दियों में cooling cost कम होती है, इसलिए Montreal क्षेत्र में बहुत अधिक capacity ऐसी दरों पर उपलब्ध है जो US region से प्रतिस्पर्धा करती हैं। यदि आपकी आवश्यकता Canada है, किसी एक विशेष शहर की नहीं, तो वहीं से शुरू करें।

यदि Canadian VPS tier आपके workload के लिए बहुत छोटे लगते हैं, तो यह तय करने से पहले कि समस्या देश में है, VPS की तुलना dedicated server से करें।

कनाडा में VPS होस्टिंग चुनना कब सही है

1. किसी कानून, अनुबंध या सार्वजनिक क्षेत्र की नीति में Canada का उल्लेख हो। Canada में होस्ट करें। इस पोस्ट की कोई अन्य बात लागू नहीं होगी। आपको प्रदाता से डेटा-रेज़िडेंसी की प्रतिबद्धता लिखित रूप में भी लेनी चाहिए।
2. आपके उपयोगकर्ता किसी एक Canadian महानगरीय क्षेत्र में हों और वर्कलोड latency पर निर्भर हो: multiplayer games, voice, remote desktops या trading। निकटतम शहर में होस्ट करें और किसी भी अनुबंध पर हस्ताक्षर करने से पहले दोनों विकल्पों को मापें।
3. आपके उपयोगकर्ता पूरे देश में फैले हों। Toronto या Montreal आबादी के सबसे बड़े हिस्से को कवर करता है। Static assets के सामने CDN लगाने से Vancouver के उपयोगकर्ता को origin स्थानांतरित करने की तुलना में अधिक लाभ मिलता है।
4. बाकी सभी मामले, जो अधिकांश मामले हैं। कीमत और वास्तविक hardware के आधार पर चुनें। इसके बाद देखें कि 2am पर support कैसा मिलता है। पहले उम्मीदवार का benchmark करें, क्योंकि एक जैसी specification sheet वाली दो plans का performance समान नहीं होता: VPS का सही benchmark कैसे करें।

आप जो भी विकल्प चुनें, निर्णय के साथ उसका कारण लिखें। अगला व्यक्ति, जो पूछे कि इसे Canada में होना चाहिए या नहीं, अनुमान से बेहतर उत्तर का हकदार है। यदि उत्तर कभी किसी अनुबंध की शर्त था, तो किसी को उसे फिर से ढूँढना पड़ेगा। Server उपलब्ध होने के बाद, नए VPS पर पहले दस मिनट उसकी city की तुलना में आपकी security के लिए अधिक महत्वपूर्ण होंगे।

FAQ

क्या PIPEDA के अनुसार मेरा डेटा Canada में ही रहना आवश्यक है?

नहीं। PIPEDA (Personal Information Protection and Electronic Documents Act) में private sector के लिए data residency का कोई नियम नहीं है। किसी अन्य देश में स्थित processor को personal information भेजना processing के लिए transfer माना जाता है। डेटा के लिए जवाबदेही आपकी organisation की बनी रहती है। Processor को तुलनीय स्तर पर उसकी सुरक्षा करनी होगी। आपको लोगों को इस transfer के बारे में स्पष्ट जानकारी देनी होगी। Office of the Privacy Commissioner ने 2019 में इस स्थिति को बदलने पर परामर्श किया था, लेकिन बाद में इसे यथावत रखा। Residency की आवश्यकताएँ अन्य स्रोतों से आती हैं, जैसे Quebec's Law 25 assessment, Nova Scotia's PIIDPA जैसे public-sector acts, Government of Canada cloud direction, या आपके अपने customer contract की कोई clause।

क्या Canada के users को United States में स्थित server का पता चलेगा?

सामान्य web application में नहीं। Toronto से New York तक round trip लगभग 18 ms और Northern Virginia तक लगभग 26 ms है। दोनों, Toronto से Vancouver तक के 62 ms से कम हैं। Users को network के 20 ms अंतर का पता चलने से बहुत पहले server response time और page weight का पता चल जाता है। लेकिन real-time games, voice calls और ऐसी किसी भी स्थिति में उन्हें इसका पता चलता है जहाँ एक व्यक्ति दूसरे व्यक्ति की प्रतिक्रिया पर निर्भर करता है।

क्या Canada का data centre US law के दायरे से बाहर होता है?

स्वचालित रूप से नहीं। US CLOUD Act, US provider के possession, custody या control में मौजूद डेटा पर लागू होता है, चाहे server कहीं भी स्थित हो। इसलिए किसी American company द्वारा संचालित Canadian region भी इसके दायरे में आता है। यदि आपकी वास्तविक चिंता foreign legal process है, तो building के address के बजाय यह देखें कि service कौन संचालित करता है और encryption keys किसके पास हैं। आपके अपने पास मौजूद keys से किया गया encryption, provider द्वारा सौंपे जा सकने वाले डेटा को सीमित करता है।

जिस city में मैं नहीं रहता, वहाँ से latency कैसे मापूँ?

उस city में hourly VPS किराये पर लें। ping -c 20 चलाकर अपने server पर mtr --report --report-cycles 50 चलाएँ, फिर VPS नष्ट कर दें। RIPE Atlas network एक free alternative है, जिसमें Canadian cities में probes मौजूद हैं। यदि ICMP blocked है, तो इसके बजाय वास्तविक request का समय curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ से मापें। इससे TCP round trip और first byte तक का पूरा समय मिलता है।