Canada में VPS Hosting: क्या सच में ज़रूरी है?

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

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

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

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

डेटा रेजिडेंसी: एकमात्र अनिवार्य आवश्यकता

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

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

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

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

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

अपने-आप नहीं। US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) उस data पर लागू होता है जो किसी US provider के possession, custody या control में हो, चाहे hardware कहीं भी स्थित हो। इसलिए किसी अमेरिकी company द्वारा संचालित Toronto region भी इसके अधिकार-क्षेत्र में आता है। यदि वास्तविक आवश्यकता geography के बजाय foreign legal process से संबंधित है, तो महत्वपूर्ण यह है कि 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 केवल संकेत हैं और पुराने हो सकते हैं। इसलिए इन्हें proof के बजाय provider से प्रश्न पूछने का कारण मानें। Transit में data के लिए विश्वसनीय उपाय वह encryption है जिसे आप स्वयं नियंत्रित करते हैं, न कि कोई map। यदि आप अपनी machines के बीच private path चाहते हैं, तो self-hosted WireGuard VPN ऐसा path देता है जिसे fibre किस देश से होकर गुजरती है, इससे कोई फर्क नहीं पड़ता।

Latency: इसे मापें, अनुमान न लगाएँ

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

[
  {
    "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 में अच्छी तरह connected consumer line के लिए प्रकाशित सामान्य आंकड़े हैं। इन्हें शुरुआती संदर्भ मानें, गारंटी नहीं। आपके वास्तविक आंकड़े आपके access network और provider की peering पर निर्भर करते हैं। ये दिन के समय के अनुसार भी बदलते हैं।

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

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

अपने उपयोगकर्ताओं के स्थान से लेटेंसी का परीक्षण कैसे करें

पहले पता करें कि आपके उपयोगकर्ता वास्तव में कहाँ हैं। आपके 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 हैं और आप उनसे pings चला सकते हैं।

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 ऐसी fault है जिसकी जाँच करनी चाहिए। High jitter voice और games को slightly higher average से अधिक प्रभावित करता है, क्योंकि receiver को सामान्य packet के बजाय सबसे देर से आने वाले packet के लिए buffer करना पड़ता है।

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

mtr प्रत्येक hop के लिए loss दिखाता है। यदि यह permission error के साथ समाप्त हो, तो इसे 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 के उत्तर देने में लगा समय मिलता है। अधिकांश slow sites इसी अंतिम gap में अपना समय खोती हैं। छोटी path पर 0.8 s का ttfb application problem है। Server को किसी अन्य city में ले जाने से यह समस्या दूर नहीं होगी।

Throughput के लिए server को VPS पर चलाएँ और client को उपयोगकर्ता की ओर से चलाएँ। iperf3 TCP 5201 पर सुनता है, इसलिए परीक्षण के लिए 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 करता है, इसलिए आप download और upload दोनों को मापते हैं। -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 fast line पर भी distant target के विरुद्ध slow लगते हैं।

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

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

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

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

[
  {
    "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 तक जाता है और आम तौर पर cache किया जाता है, इसलिए warm visit में यह चरण छूट जाता है। एंड-टू-एंड गणना में, cold load में New York path पर 72 ms और Vancouver path पर 248 ms की देरी होती है। एक single 400 ms database query की तुलना में दोनों आंकड़े नगण्य हैं। Connection खुलने के बाद, HTTP/2 और HTTP/3 एक ही connection पर कई requests एक साथ भेजते हैं। इसलिए यह लागत हर file के लिए नहीं, केवल एक बार लगती है। Static assets को CDN (content delivery network) पर रखें। इससे उन assets के लिए origin का शहर बिल्कुल महत्वपूर्ण नहीं रहता। इसी कारण Toronto तक 98 ms की देरी वाला European visitor भी fast page पा सकता है।

रीयल-टाइम multiplayer games इसका उलटा उदाहरण हैं, क्योंकि round trip ही अनुभव का हिस्सा है। तेज़ 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 लगने पर कुल समय लगभग एक second होता है। प्रत्येक query पर 62 ms लगने पर समय दो seconds से अधिक हो जाता है। यह उस page पर होता है जो database के उसी box पर होने पर 30 ms में profile हुआ था। दूसरे region में read replicas और disaster recovery के लिए asynchronous replication ठीक है। लंबी path पर synchronous commit करने से हर write में उस path की देरी जुड़ जाती है।

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

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

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

छोटे बाज़ार की लागत

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

• आपके पैसे के लिए प्रतिस्पर्धा करने वाले providers कम हैं। इसलिए समान श्रेणी की machine के लिए RAM या disk के प्रति gigabyte की कीमत आमतौर पर अधिक होती है।
• Capacity Toronto और Montreal में केंद्रित है। Vancouver और Calgary में यह कम है। Failover के लिए दूसरा Canadian region चुनने पर अक्सर network path लंबा होगा या आपको देश से बाहर जाना पड़ेगा।
• कोई छोटा regional host एक building को एक या दो upstream carriers के पीछे चला सकता है। पूछें कि कितने carriers हैं और उनमें से किसी एक के विफल होने पर क्या होता है।
• Hardware का विकल्प सीमित होता है। US regions में बड़े instances और GPU machines आसानी से मिलती हैं। इसलिए आपकी पसंद के शहर में आपकी पसंद के आकार का GPU VPS उपलब्ध न हो सकता है।
• छोटे host में support coverage वास्तविक प्रश्न है, marketing का नहीं। पूछें कि human support कब उपलब्ध रहता है।

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

यदि Canadian VPS tiers 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 में होना चाहिए या नहीं, अनुमान से बेहतर उत्तर का हकदार है। यदि उत्तर कभी किसी contract clause में था, तो किसी को उसे फिर से ढूंढना होगा। Box उपलब्ध होने के बाद, नए VPS पर पहले दस मिनट उसकी 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 requirements अन्य स्रोतों से आती हैं: Quebec का Law 25 assessment, Nova Scotia के 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 और ऐसी किसी भी स्थिति में उन्हें इसका पता चलता है जहां एक व्यक्ति दूसरे व्यक्ति की प्रतिक्रिया पर प्रतिक्रिया दे रहा हो।

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

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