कॅनडामधील VPS Hosting कधी आवश्यक असते?

तुमचा VPS कॅनडामध्ये असणे आवश्यक आहे का?

कायद्यात किंवा करारात डेटा कॅनडाच्या हद्दीतच ठेवणे आवश्यक असल्यास, कॅनडामधील VPS hosting निवडणे योग्य ठरते. हेच एकमेव ठोस कारण आहे. टोरोंटोमधील घरच्या इंटरनेट कनेक्शनपासून न्यूयॉर्कमधील data centre पर्यंतचा round trip साधारण 18 ms असतो. टोरोंटोमधील data centre पर्यंत तो अंदाजे 3 ms असतो. जवळजवळ कोणताही web application हा फरक ओळखू शकत नाही.

लोक कॅनडामधील server निवडण्यामागे तीन कारणे असतात. Data residency ही कायदेशीर सक्ती असल्यास प्रश्न तिथेच सुटतो. Latency मोजता येते आणि ती सहसा लोकांच्या अपेक्षेपेक्षा कमी असते. Canadian dollars मध्ये billing करणे accountant साठी सोयीचे असते. इतर कोणत्याही निकषावर विचार करण्यापूर्वी यापैकी पहिले कारण तुम्हाला लागू होते का ते ठरवा.

हा लेख नियम सर्वसाधारणपणे कसे लागू होतात हे स्पष्ट करतो. हा कायदेशीर सल्ला नाही. गोपनीयतेचा कायदा तुमच्या संस्थेला लागू असल्यास, उत्तर तुमच्या कायदेशीर सल्लागाराकडून घ्या.

डेटा residency: एकमेव कठोर आवश्यकता

PIPEDA (Personal Information Protection and Electronic Documents Act) हा कॅनडाचा संघीय खासगी क्षेत्रातील गोपनीयता कायदा आहे. वैयक्तिक माहिती देशातच राहिली पाहिजे, अशी त्याची अट नाही. परदेशातील processor कडे डेटा पाठवणे ही प्रक्रिया करण्यासाठी केलेली हस्तांतरण कृती मानली जाते. डेटासाठी जबाबदारी तुमच्या संस्थेकडेच राहते. Processor ने तुलनात्मक संरक्षण देणे आवश्यक आहे. ही प्रक्रिया होत असल्याचे लोकांना स्पष्टपणे सांगणेही आवश्यक आहे. Office of the Privacy Commissioner ने 2019 मध्ये ही अट कडक करण्याबाबत सल्लामसलत केली. त्यानंतर त्याने विद्यमान भूमिका कायम ठेवली. त्यामुळे PIPEDA मुळे तुमचा डेटा कॅनडातच साठवला पाहिजे, हा सामान्य दावा चुकीचा आहे. अनेक hosting संदर्भांमध्ये तो पुन्हा पुन्हा दिला जात असला तरीही तो चुकीचाच आहे.

प्रत्यक्ष data residency नियम अस्तित्वात आहेत. ते अधिक मर्यादित क्षेत्रांमध्ये लागू होतात.

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

व्यावहारिक चाचणी सोपी आहे. तुम्ही संबंधित clause दाखवू शकता का? तुमच्या संस्थेतील कोणीही Canada अशी अट सांगणारा statute किंवा contract दाखवू शकत नसेल, तर तुम्ही latency आणि किंमत यांवर आधारित निवड करत आहात.

कॅनडामधील डेटा सेंटर अमेरिकेच्या कायदेशीर अधिकारक्षेत्राबाहेर आहे का?

स्वतःहून नाही. US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) अंतर्गत US provider च्या ताब्यात, देखरेखीखाली किंवा नियंत्रणाखाली असलेला डेटा हार्डवेअर कुठेही असला तरी येतो. त्यामुळे American कंपनी चालवत असलेला Toronto region त्याच्या कक्षेत येतो. खरा प्रश्न भौगोलिक स्थानाऐवजी परदेशी कायदेशीर प्रक्रियेबद्दल असेल, तर सेवा कोण चालवते आणि encryption keys कोणाकडे आहेत हे महत्त्वाचे ठरते. इमारतीचा Canadian पत्ता याचे स्वतःहून उत्तर देत नाही.

Routing हा दुसरा अनपेक्षित मुद्दा आहे. दोन Canadian शहरांमधील network traffic अनेकदा United States मधून जाते, कारण स्वस्त peering ऐतिहासिकदृष्ट्या तिथे उपलब्ध आहे. संशोधक याला boomerang routing म्हणतात. तुमचे packets देशाबाहेर कधीही जात नाहीत असे कोणालाही सांगण्यापूर्वी traceroute चालवा.

traceroute vps.example.com

Hop names मध्ये nyc, chi किंवा ash यांसारखे city codes असतात. ही नावे केवळ संकेत असतात आणि कालांतराने जुनी होतात. त्यामुळे त्यांना पुरावा न मानता provider ला प्रश्न विचारण्याचे कारण म्हणून वापरा. Data in transit साठी विश्वसनीय उपाय नकाशा नव्हे, तर तुमच्या नियंत्रणाखालील encryption आहे. तुमच्या स्वतःच्या machines दरम्यान private path हवा असल्यास, self-hosted WireGuard VPN असा मार्ग देते, जो 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 मधील चांगल्या प्रकारे connected consumer line साठी ही प्रकाशित केलेली सामान्य आकडेवारी आहे. हे सुरुवातीचे अंदाज आहेत; हमी नाही. तुमचे प्रत्यक्ष आकडे access network आणि provider च्या peering वर अवलंबून असतात. दिवसाच्या वेळेनुसार त्यात बदल होतात.

दोन ओळी पुन्हा काळजीपूर्वक वाचण्यासारख्या आहेत. Toronto ते Montreal सुमारे 12 ms आहे. हे अंतर इतके कमी आहे की बहुतेक वापरांसाठी ही दोन्ही शहरे एकाच region प्रमाणे वागतात. Toronto ते Vancouver सुमारे 62 ms आहे. हे Toronto ते Northern Virginia या 26 ms पेक्षा अधिक आहे. Canada मध्ये असणे म्हणजे तुमच्या वापरकर्त्यांच्या जवळ असणे नव्हे.

असो, last mile चा परिणाम बहुतेक वेळा सर्वाधिक असतो. Home fibre मुळे काही मिलिसेकंद वाढतात. Line व्यस्त असताना cable मुळे विलंबता आणखी वाढते. Mobile connection मुळे स्वतंत्रपणेच दहा-दहा मिलिसेकंदांची वाढ होते. Toronto मधील एखाद्या phone user ला Toronto server पर्यंत 50 ms दिसू शकतात. तो server New York येथे हलवल्यास त्यांच्या अनुभवात केवळ काही टक्के बदल होतो.

तुमचे वापरकर्ते ज्या ठिकाणाहून येतात तेथून latency कशी तपासावी

तुमचे वापरकर्ते प्रत्यक्षात कुठे आहेत हे आधी शोधा. तुमच्या analytics मध्ये sessions चे city किंवा region नुसार आधीच विभाजन केलेले असते. तुमचे office कुठे आहे यावरून अंदाज बांधण्याऐवजी ही माहिती वापरा.

त्यानंतर त्याच ठिकाणाहून मोजमाप करा. Ottawa मधील desk वरून Vancouver ची latency तपासता येत नाही. लक्ष्य शहरात hourly VPS वीस मिनिटांसाठी भाड्याने घ्या आणि काम झाल्यावर तो नष्ट करा. एखाद्या सहकाऱ्याला किंवा ग्राहकाला एक command चालवायला सांगा. किंवा https://atlas.ripe.net वरील विनामूल्य RIPE Atlas measurement network वापरा. त्यामध्ये Canadian शहरांमध्ये probes आहेत आणि त्यांच्याकडून ping चालवता येतात.

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

शेवटच्या दोन ओळी वाचा.

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 आहे. सरासरी latency थोडी जास्त असण्यापेक्षा जास्त jitter मुळे voice आणि games वर अधिक परिणाम होतो, कारण 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 एवढाच तुमच्या traffic वर परिणाम करणारा loss असतो. आधी 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 वर ttfb 0.8 s असल्यास ही application ची समस्या आहे; server दुसऱ्या शहरात हलवल्याने त्यावर परिणाम होणार नाही.

Throughput साठी VPS वर server आणि वापरकर्त्याच्या बाजूने 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 उलटते. त्यामुळे upload सोबत download देखील मोजता येतो. -P 8 आठ parallel streams उघडते. आठ streams एकापेक्षा खूप जलद असल्यास मर्यादा link मध्ये नसून लांब path वरील TCP window मध्ये आहे, कारण एका stream मधून प्रत्येक round trip मध्ये फक्त एक window वाहून नेता येते. Vancouver path वरील हीच window New York path च्या तुलनेत प्रति सेकंद साधारण एक-तृतीयांश data वाहून नेते. Long-haul backups मध्येही हेच घडते. त्यामुळे वेगवान line असूनही दूरच्या target विरुद्ध restic सह off-site backups धीमे वाटतात.

iperf3 चालू असताना दुसऱ्या terminal मध्ये ping सुरू ठेवा. Transfer दरम्यान round trip 20 ms वरून 300 ms पर्यंत वाढल्यास तुमच्या access equipment मध्ये bufferbloat आहे. कोणतेही data centre location ते दूर करू शकत नाही.

एकापेक्षा जास्त वेळा मोजमाप करा आणि संध्याकाळीही मोजा. 9pm वरील congestion ही तुमचे वापरकर्ते प्रत्यक्ष अनुभवत असलेली संख्या आहे. 4am वरील संख्या sales page वर दाखवणे अधिक सोयीचे असते.

तुमच्या workload साठी round-trip time चा अर्थ

ब्राउझरला काहीही render करता येण्यापूर्वी cold page load मध्ये चार round trips लागतात.

[
  {
    "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 मध्ये हा टप्पा वगळला जातो. End to end मोजल्यास, cold load मध्ये New York path वर 72 ms आणि Vancouver path वर 248 ms इतका विलंब येतो. एकच 400 ms database query असल्यास या दोन्ही आकड्यांचा प्रभाव नगण्य ठरतो. Connection उघडल्यानंतर HTTP/2 आणि HTTP/3 त्यावर एकाच वेळी अनेक requests पाठवतात. त्यामुळे हा खर्च प्रत्येक file साठी नव्हे, तर एकदाच होतो. Static assets CDN (content delivery network) वर ठेवल्यास त्यांच्यासाठी origin चे city महत्त्वाचे राहत नाही. म्हणून Toronto पर्यंत 98 ms round-trip time असलेल्या European visitor लाही page जलद मिळू शकते.

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

Database च्या बाबतीत चुकीची region निवड मोठे नुकसान करते. Application एका region मध्ये आणि database दुसऱ्या region मध्ये कधीही ठेवू नका. प्रत्येक query हा एक round trip असतो. एखाद्या page वर 40 queries असल्यास त्यासाठी 40 round trips लागतात. प्रत्येक query साठी 18 ms असल्यास जवळजवळ एक सेकंद लागतो. प्रत्येक query साठी 62 ms असल्यास दोन सेकंदांपेक्षा जास्त लागतात. Database त्याच box वर असताना त्या page चा profiling time 30 ms होता. दुसऱ्या region मधील read replicas आणि disaster recovery साठी asynchronous replication योग्य आहे. मात्र लांब path वर synchronous commit केल्यास प्रत्येक write मध्ये त्या path चा विलंब जोडला जातो.

Interactive sessions या दोन्हींच्या मधल्या प्रकारात येतात. SSH साधारण 100 ms पर्यंत आरामदायक राहते. त्यापेक्षा जास्त विलंब असल्यास ते laggy वाटते, कारण प्रत्येक keystroke चा echo परत येईपर्यंत थांबावे लागते. mosh स्थानिक पातळीवर अंदाज बांधते आणि या विलंबाचा मोठा भाग लपवते. Webhooks आणि internal APIs नेहमी ज्या service ला ते call करतात त्याच region मध्ये असावेत.

बिलिंग, चलन आणि कर

कॅनेडियन डॉलरमध्ये पेमेंट केल्याने तुमचा card issuer आकारत असलेले foreign transaction fee टाळता येते. August 2026 पर्यंत हे शुल्क सामान्यतः 2.5% इतके असते. तसेच तुमचे accounting एकाच चलनात ठेवता येते. कॅनेडियन provider GST किंवा HST सहित invoice देतो. नोंदणीकृत व्यवसाय हा कर input tax credit म्हणून परत दावा करू शकतो. हा finance विषय आहे आणि त्याचे उत्तरही finance विषयाशी संबंधित आहे. packets कुठे पाठवायचे हे त्यावर कधीही ठरवू नये. सर्व्हरचा वास्तविक खर्च किती येतो आणि renewal pricing मुळे अडचणीत न येता plans ची तुलना कशी करावी, यासाठी VPS चा प्रत्यक्ष मासिक खर्च किती असतो हे वाचा.

लहान बाजारपेठेमुळे होणारे तोटे

कॅनडा ही अमेरिकेच्या तुलनेत लहान hosting बाजारपेठ आहे. त्यामुळे काही गोष्टी सोडाव्या लागतात.

• तुमच्या व्यवसायासाठी कमी providers स्पर्धा करतात. त्यामुळे समान श्रेणीच्या मशीनसाठी RAM किंवा disk च्या प्रत्येक gigabyte ची किंमत सहसा जास्त असते.
• क्षमता प्रामुख्याने Toronto आणि Montreal येथे केंद्रित आहे. Vancouver आणि Calgary येथे ती कमी आहे. Failover साठी दुसरा Canadian region निवडताना अनेकदा मोठा network path स्वीकारावा लागतो किंवा देशाबाहेरील region वापरावा लागतो.
• एखादा लहान regional host एकाच इमारतीतून, एक किंवा दोन upstream carriers वर अवलंबून सेवा चालवत असू शकतो. किती carriers आहेत हे विचारा. त्यापैकी एखादा carrier अयशस्वी झाल्यास काय होते हेही विचारा.
• उपलब्ध hardware पर्याय कमी असतात. US regions मध्ये मोठ्या instances आणि GPU machines सहज मिळतात. त्यामुळे तुम्हाला हव्या त्या शहरात, हव्या त्या आकाराचा GPU VPS उपलब्ध नसेल.
• लहान host कडे support coverage हा marketing चा मुद्दा नसून प्रत्यक्ष तपासण्याचा प्रश्न आहे. मानवी support कर्मचारी कोणत्या वेळी उपलब्ध असतो हे विचारा.

किंमतीच्या बाबतीत Montreal हा अपवाद आहे. Quebec मधील जलविद्युत स्वस्त आहे आणि हिवाळ्यामुळे cooling costs कमी होतात. त्यामुळे Montreal परिसरात मोठी capacity उपलब्ध असून तिचे rates US regions शी स्पर्धा करतात. तुमची गरज Canada मधील कोणताही region अशी असेल आणि एखादे विशिष्ट शहर आवश्यक नसेल, तर तिथून सुरुवात करा.

Canadian VPS tiers तुमच्या workload साठी खूप लहान वाटत असतील, तर देशाला दोष देण्यापूर्वी VPS आणि dedicated server ची तुलना करा.

कॅनडामध्ये VPS होस्टिंग निवडणे योग्य ठरणाऱ्या परिस्थिती

1. एखादा कायदा, करार किंवा सार्वजनिक क्षेत्रातील धोरण कॅनडाचे नाव स्पष्टपणे नमूद करत असेल, तर होस्टिंग कॅनडामध्ये करा. या पोस्टमधील इतर कोणतीही बाब लागू होत नाही. तसेच, प्रदात्याकडून residency commitment लेखी स्वरूपात घ्या.
2. तुमचे वापरकर्ते कॅनडातील एका महानगरात असतील आणि workload latency वर अवलंबून असेल, जसे multiplayer games, voice, remote desktops किंवा trading, तर होस्टिंग जवळच्या शहरात करा. कोणताही करार करण्यापूर्वी दोन्ही पर्यायांचे मोजमाप करा.
3. तुमचे वापरकर्ते संपूर्ण देशात पसरलेले असतील, तर Toronto किंवा Montreal लोकसंख्येतील सर्वात मोठा भाग कव्हर करतात. Static assets च्या पुढे CDN ठेवल्याने Vancouver मधील वापरकर्त्यासाठी origin हलवण्यापेक्षा अधिक फायदा होतो.
4. इतर सर्व परिस्थितींमध्ये, म्हणजे बहुतेक वेळा, किंमत आणि प्रत्यक्ष मिळणाऱ्या hardware वर आधारित निवड करा. त्यानंतर रात्री 2 वाजता support कसा मिळतो ते तपासा. उमेदवार VPS ची आधी benchmark चाचणी घ्या, कारण specification sheet सारखीच असलेल्या दोन plans ची कामगिरी सारखी असेलच असे नाही: VPS चे योग्य benchmark कसे करावे.

तुम्ही कोणताही पर्याय निवडला तरी निर्णयामागील कारण त्याच्याजवळ लिहून ठेवा. हे कॅनडामध्ये असावे का, असा प्रश्न पुढील व्यक्तीने विचारल्यास तिला अंदाजापेक्षा अधिक ठोस माहिती मिळायला हवी. आणि उत्तर कधी करारातील अट असेल, तर ती पुन्हा शोधावी लागेल. VPS तयार झाल्यानंतर नवीन VPS वरील पहिली दहा मिनिटे त्याच्या शहरापेक्षा तुमच्या सुरक्षेसाठी अधिक महत्त्वाची असतात.

FAQ

PIPEDA नुसार माझा डेटा कॅनडामध्येच ठेवणे आवश्यक आहे का?

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

अमेरिकेतील server कॅनेडियन users ना जाणवेल का?

सामान्य web application साठी नाही. Toronto ते New York round trip सुमारे 18 ms आणि Northern Virginia पर्यंत सुमारे 26 ms असतो. दोन्ही वेळा Toronto ते Vancouverच्या 62 ms पेक्षा कमी आहेत. Network मधील 20 ms चा फरक जाणवण्यापूर्वीच users ना server response time आणि page weight जाणवतात. मात्र real-time games, voice calls आणि एका व्यक्तीची प्रतिक्रिया दुसऱ्या व्यक्तीच्या कृतीवर अवलंबून असलेल्या कोणत्याही कामात हा फरक जाणवतो.

कॅनडाबाहेरील Canadian data centre US law च्या कक्षेबाहेर असतो का?

आपोआप नाही. Server कुठे आहे याची पर्वा न करता US CLOUD Act हा US provider च्या possession, custody किंवा control मधील डेटाला लागू होतो. त्यामुळे American company चालवत असलेला Canadian region देखील त्याच्या कक्षेत येतो. Foreign legal process ही तुमची वास्तविक चिंता असल्यास इमारतीच्या पत्त्याऐवजी service कोण चालवते आणि encryption keys कोणाकडे आहेत हे तपासा. तुम्ही स्वतःकडे ठेवलेल्या keys ने केलेले encryption provider कडून काय हस्तांतरित करता येते यावर मर्यादा आणते.

मी राहत नसलेल्या शहरातून latency कशी मोजू?

त्या शहरात hourly VPS भाड्याने घ्या. तुमच्या स्वतःच्या server कडे ping -c 20 आणि mtr --report --report-cycles 50 चालवा. त्यानंतर VPS नष्ट करा. RIPE Atlas network हा Canadian cities मधील probes असलेला विनामूल्य पर्याय आहे. ICMP blocked असल्यास, त्याऐवजी curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ वापरून वास्तविक request ची वेळ मोजा. यामुळे TCP round trip आणि first byte पर्यंतचा पूर्ण वेळ मिळतो.