Canada VPS Hosting: काय खरोखर महत्त्वाचे?

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

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

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

हे post नियम सर्वसाधारणपणे कसे लागू होतात हे स्पष्ट करते. हा legal advice नाही. Privacy law तुमच्या organisation ला बांधील करत असल्यास, उत्तर तुमच्या counsel कडून घ्या.

डेटा-स्थानिकता: एकमेव कठोर आवश्यकता

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

प्रत्यक्षात डेटा-स्थानिकतेचे नियम अस्तित्वात आहेत. ते अधिक मर्यादित क्षेत्रांमध्ये लागू होतात.

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

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

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

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

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

traceroute vps.example.com

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

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

अखेरीचा mile बहुतेक वेळा तरीही सर्वाधिक परिणाम करतो. Home fibre मुळे काही millisecond वाढतात. Line व्यस्त असताना cable मुळे त्यापेक्षा अधिक विलंब वाढतो. 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 तपासता येत नाही. लक्ष्य शहरात hourly VPS वीस मिनिटांसाठी भाड्याने घ्या आणि काम झाल्यावर ते नष्ट करा. एखाद्या colleague किंवा customer ला एक command चालवायला सांगा. किंवा https://atlas.ripe.net येथील free RIPE Atlas measurement network वापरा. या network मध्ये Canadian cities मध्ये probes आहेत आणि त्यांच्याकडून pings चालवता येतात.

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 मधील फरक. Short path वर होणारे कोणतेही packet loss तपासणे आवश्यक असते. किंचित जास्त average पेक्षा जास्त 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 देतात. Final line पर्यंत सुरू राहणारे lossच तुमच्या traffic वर परिणाम करणारे loss असते. प्रथम bottom row वाचा, त्यानंतर वरच्या दिशेने तपासा.

ICMP block केलेले असेल किंवा 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 चा वेळ जातो. Short path वर ttfb 0.8 s असल्यास ही application ची समस्या आहे. Server दुसऱ्या city मध्ये हलवल्याने ती सुटणार नाही.

Throughput साठी VPS वर server चालवा आणि user च्या बाजूने client चालवा. iperf3 TCP 5201 वर listens करते. त्यामुळे test साठी 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 मध्ये नसून long path वरील TCP window मध्ये आहे, कारण एक stream प्रत्येक round trip मध्ये फक्त एक window वाहून नेऊ शकते. Vancouver path वरील तीच window New York path वरील तुलनेत प्रति सेकंद साधारण एक-तृतीयांश 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 हाच तुमचे users प्रत्यक्ष अनुभवतात तो आकडा आहे. 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 तुमच्या सर्व्हरऐवजी resolver कडे जाते आणि ती सहसा cache केलेली असते. त्यामुळे उबदार भेटीत ती पायरी वगळली जाते. सुरुवातीपासून शेवटपर्यंत मोजल्यास, थंड लोडमध्ये New York मार्गावर 72 ms आणि Vancouver मार्गावर 248 ms इतका विलंब येतो. एकच 400 ms database query असल्यास, या दोन्ही वेळा त्याच्या तुलनेत नगण्य ठरतात. Connection उघडल्यानंतर HTTP/2 आणि HTTP/3 त्यावर एकाच वेळी अनेक requests पाठवतात. त्यामुळे हा खर्च प्रत्येक file साठी नव्हे, तर एकदाच होतो. Static assets CDN (content delivery network) वर ठेवल्यास त्यांच्यासाठी origin चे शहर अजिबात महत्त्वाचे राहत नाही. म्हणून Toronto पर्यंत 98 ms विलंब असलेला European visitor देखील जलद पृष्ठ मिळवू शकतो.

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

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

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

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

कॅनेडियन डॉलरमध्ये पैसे भरल्यास तुमचा कार्ड जारीकर्ता आकारत असलेले परकीय व्यवहार शुल्क टाळता येते. ऑगस्ट 2026 पर्यंत हे शुल्क साधारणपणे 2.5% असते. तसेच तुमच्या लेखांकनात एकच चलन ठेवता येते. कॅनेडियन प्रदाता GST किंवा HST आकारून बीजक जारी करतो. नोंदणीकृत व्यवसाय हे शुल्क इनपुट करसवलत म्हणून परत मिळवू शकतो. हा वित्तविषयक प्रश्न आहे आणि त्याचे उत्तरही वित्तविषयकच आहे. पॅकेट्स कुठे पाठवायचे हे यावरून कधीही ठरवू नये. सर्व्हरचा प्रत्यक्ष खर्च किती असतो आणि नूतनीकरणाच्या किंमतीमुळे फसवले जाणे टाळून योजनांची तुलना कशी करावी, यासाठी VPS चा प्रतिमहिना प्रत्यक्ष खर्च वाचा.

लहान बाजारपेठेमुळे होणारा खर्च

युनायटेड स्टेट्सच्या तुलनेत Canada ही लहान hosting बाजारपेठ आहे. त्यामुळे तुम्ही काय गमावता, हेही स्पष्टपणे सांगणे आवश्यक आहे.

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

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

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

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

1. एखादा कायदा, करार किंवा सार्वजनिक क्षेत्रातील धोरण कॅनडाचा स्पष्ट उल्लेख करत असल्यास, होस्टिंग कॅनडामध्ये करा. या पोस्टमधील इतर कोणतीही बाब लागू होत नाही. तसेच, प्रदात्याकडून डेटा कॅनडामध्येच राहील याची हमी लेखी स्वरूपात घ्या.
2. तुमचे वापरकर्ते कॅनडातील एका महानगरीय भागात असतील आणि वर्कलोड विलंबावर अवलंबून असेल, जसे की 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) मध्ये खासगी क्षेत्रासाठी डेटा ठेवण्याचे स्थान निश्चित करणारा नियम नाही. दुसऱ्या देशातील processor कडे personal information पाठवणे ही processing साठी transfer असते. तुमची organisation त्या डेटासाठी जबाबदार राहते. Processor ने त्याचे तुलनात्मक पातळीवर संरक्षण करणे आवश्यक आहे. ही प्रक्रिया होत असल्याचे तुम्ही लोकांना स्पष्टपणे सांगणे आवश्यक आहे. Office of the Privacy Commissioner ने 2019 मध्ये ही भूमिका बदलण्याबाबत सल्लामसलत केली आणि त्यानंतर तीच भूमिका कायम ठेवली. डेटा ठेवण्याच्या स्थानासंबंधीच्या आवश्यकता इतर ठिकाणांहून येतात. उदाहरणार्थ, Quebec's Law 25 assessment, Nova Scotia's PIIDPA सारखे public-sector acts, Government of Canada cloud direction किंवा तुमच्या स्वतःच्या customer contract मधील clause.

United States मधील server कॅनेडियन users ना जाणवेल का?

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

Canadian data centre US कायद्याच्या कक्षेबाहेर असतो का?

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

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

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