కెనడాలో VPS Hosting అవసరమా? PIPEDA, Latency కొలత

మీ VPS కెనడాలో ఉండాల్సిన అవసరం ఉందా?

ఒక చట్టం లేదా ఒప్పందం డేటా కెనడా భూభాగంలోనే ఉండాలని నిర్దేశిస్తే, కెనడాలో VPS hosting ఎంచుకోవడం సముచితం. ఇదే ఏకైక తప్పనిసరి కారణం. Torontoలోని home 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కు సౌకర్యంగా ఉంటుంది. మిగతా అంశాలను పరిశీలించే ముందు మొదటి కారణం మీకు వర్తిస్తుందో లేదో నిర్ధారించండి.

ఈ పోస్ట్ నియమాలు సాధారణంగా ఎలా పనిచేస్తాయో వివరిస్తుంది. ఇది న్యాయ సలహా కాదు. Privacy law మీ సంస్థకు వర్తిస్తే, సమాధానం మీ న్యాయ సలహాదారు నుంచి పొందాలి.

డేటా residency: ఒకటే కఠినమైన అవసరం

PIPEDA (Personal Information Protection and Electronic Documents Act) కెనడా సమాఖ్య ప్రైవేట్-రంగ గోప్యతా చట్టం. వ్యక్తిగత సమాచారాన్ని దేశంలోనే ఉంచాలని ఇది కోరదు. విదేశాల్లోని processor కు డేటాను పంపడాన్ని processing కోసం transfer గా పరిగణిస్తుంది. డేటాపై బాధ్యత మీ సంస్థదే కొనసాగుతుంది. Processor దానికి సమానమైన రక్షణ ఇవ్వాలి. ఈ ప్రక్రియ జరుగుతుందని వ్యక్తులకు స్పష్టంగా తెలియజేయాలి. 2019లో Office of the Privacy Commissioner ఈ నియమాన్ని కఠినతరం చేయడంపై సంప్రదింపులు జరిపింది. తరువాత అది తన ప్రస్తుత వైఖరినే కొనసాగించింది. అందువల్ల PIPEDA ప్రకారం మీ డేటా కెనడాలోనే ఉండాలి అనే సాధారణ వాదన తప్పు. అనేక hosting ప్రచార పాఠ్యాలు దాన్ని పదేపదే చెబుతున్నప్పటికీ, అది నిజం కాదు.

నిజమైన residency నియమాలు ఉన్నాయి. అవి మరింత పరిమితమైన సందర్భాల్లో వర్తిస్తాయి.

• Quebec's Law 25 ప్రకారం వ్యక్తిగత సమాచారాన్ని province వెలుపలకు పంపే ముందు assessment చేయాలి. అది చేరే ప్రదేశంలో ఆ సమాచారానికి తగిన రక్షణ ఉండాలి. ఈ నిబంధన September 2023 నుంచి అమల్లో ఉంది. ఇది మీరు సమర్థించగలగాల్సిన paperwork మరియు నిర్ణయం. ఇది ban కాదు.
• Public-sector నియమాలు public bodies కు, వాటికి సేవలు అందించే companies కు వర్తిస్తాయి. Nova Scotia's PIIDPA వ్యక్తిగత సమాచారాన్ని Canada వెలుపల నిల్వ చేయడాన్ని పరిమితం చేస్తుంది. British Columbia's FIPPA లో కూడా ఇలాంటి నియమం ఉండేది. 2021లో చేసిన amendment తరువాత assessment తర్వాత foreign storage కు అనుమతి ఇచ్చింది.
• Federal government పని Government of Canada's cloud direction ను అనుసరిస్తుంది. దాని ప్రకారం Protected B మరియు అంతకంటే ఎక్కువ స్థాయి data Canada లోనే ఉండాలి.
• Provincial health privacy laws ఆరోగ్య records ఎక్కడ ఉండవచ్చనే దానిపై తమ స్వంత షరతులను విధిస్తాయి. ఈ షరతులు province ను బట్టి మారుతాయి.
• ఆచరణలో ఎక్కువగా ప్రభావం చూపేది customer contracts మరియు public tenders. "data at rest in Canada" అని security questionnaire లో ఉంటే, మీరు దానిపై సంతకం చేసినందున అది statute మాదిరిగానే మిమ్మల్ని కట్టుబరుస్తుంది.

ఆచరణాత్మక పరీక్ష సులభం. ఆ clause ను మీరు చూపించగలరా? Canada అని చెప్పే statute లేదా contract పేరును మీ సంస్థలో ఎవరూ చెప్పలేకపోతే, మీరు latency మరియు ధర ఆధారంగా ఎంపిక చేస్తున్నారు.

కెనడాలోని data centre అమెరికా చట్టపరమైన పరిధికి వెలుపల ఉంటుందా?

దానంతట అదే కాదు. US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) ప్రకారం US provider ఆధీనంలో, సంరక్షణలో లేదా నియంత్రణలో ఉన్న data, hardware ఎక్కడ ఉన్నా, ఆ చట్ట పరిధిలోకి వస్తుంది. అందువల్ల అమెరికన్ కంపెనీ నిర్వహించే Toronto region కూడా దాని పరిధిలో ఉంటుంది. వాస్తవ అవసరం భౌగోళిక స్థానం గురించి కాకుండా విదేశీ చట్టపరమైన ప్రక్రియ గురించి అయితే, service ను ఎవరు నిర్వహిస్తున్నారు మరియు encryption keys ఎవరి వద్ద ఉన్నాయి అనేవే ముఖ్యమైనవి. భవనం ఉన్న address కెనడాలో ఉందనే విషయం ఒక్కటే దీనికి సమాధానం కాదు.

Routing రెండవ ఆశ్చర్యకరమైన అంశం. రెండు Canadian నగరాల మధ్య network traffic తరచుగా United States గుండా వెళ్తుంది. తక్కువ ఖర్చుతో కూడిన peering చారిత్రకంగా అక్కడే ఉండటమే దీనికి కారణం. పరిశోధకులు దీనిని boomerang routing అని పిలుస్తారు. మీ packets దేశం వెలుపలికి ఎప్పుడూ వెళ్లవని ఎవరికైనా చెప్పే ముందు traceroute అమలు చేయండి.

traceroute vps.example.com

Hop పేర్లలో nyc, chi లేదా ash వంటి city codes ఉంటాయి. ఆ పేర్లు కేవలం సూచనలు మాత్రమే; అవి పాతబడిపోవచ్చు. కాబట్టి వాటిని ఆధారంగా చేసుకుని provider ను ప్రశ్నించండి, కానీ అవే ఖచ్చితమైన రుజువుగా భావించవద్దు. Transit లో ఉన్న data కోసం నమ్మదగిన సమాధానం మీరు నియంత్రించే encryption, map కాదు. మీ స్వంత machines మధ్య private path కావాలంటే, మీరు స్వయంగా నిర్వహించే WireGuard VPN ఉపయోగించండి. fibre ఏ దేశం గుండా వెళ్తుందనేది దానికి సంబంధం ఉండదు.

Latency: కొలవండి, ఊహించవద్దు

Fibreలోని కాంతి ప్రతి millisecondకు సుమారు 200 km ప్రయాణిస్తుంది. అందువల్ల పరికరాలను పరిగణనలోకి తీసుకోకముందే, ప్రతి 100 km దూరానికి round tripలో సుమారు 1 ms latency జతవుతుంది. Toronto నుంచి Vancouver వరకు నేరుగా సుమారు 3,400 km ఉంటుంది; cable మార్గం ఇంకా పొడవుగా ఉంటుంది. అందువల్ల కనిష్ఠ latency సుమారు 40 msకు చేరుతుంది. వాస్తవ మార్గాల్లో 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లో మంచి connectivity ఉన్న consumer lineకు సాధారణంగా ప్రచురించే గణాంకాలు. ఇవి ప్రారంభ అంచనాలు మాత్రమే, హామీ కాదు. మీ access network మరియు provider యొక్క peering ఆధారంగా మీ గణాంకాలు మారుతాయి. రోజులోని సమయాన్ని బట్టి కూడా అవి మారుతాయి.

రెండు వరుసలను మరోసారి జాగ్రత్తగా పరిశీలించాలి. Toronto నుంచి Montreal వరకు సుమారు 12 ms ఉంటుంది. ఈ latency తక్కువగా ఉండటంతో, చాలా సందర్భాల్లో ఈ రెండు నగరాలు ఒకే regionలా పనిచేస్తాయి. Toronto నుంచి Vancouver వరకు సుమారు 62 ms ఉంటుంది. ఇది Toronto నుంచి Northern Virginia వరకు ఉన్న 26 ms కంటే ఎక్కువ. Canadaలో ఉండటం అంటే మీ usersకు సమీపంలో ఉండటం కాదు.

ఏమైనప్పటికీ last mile సాధారణంగా latencyలో ప్రధాన భాగం అవుతుంది. Home fibre కొన్ని milliseconds జతచేస్తుంది. Line busyగా ఉన్నప్పుడు cable connection మరింత latencyను జతచేస్తుంది. Mobile connection స్వయంగా tens of milliseconds latencyను జతచేస్తుంది. Torontoలోని phone user, Toronto serverకు 50 ms latencyని చూడవచ్చు. ఆ serverను New Yorkకు మార్చినప్పుడు వారి అనుభవంలో కొన్ని శాతం మాత్రమే మార్పు కనిపించవచ్చు.

మీ వినియోగదారులు ఉన్న ప్రదేశం నుంచి latency ను ఎలా పరీక్షించాలి

ముందుగా మీ వినియోగదారులు వాస్తవంగా ఎక్కడ ఉన్నారో తెలుసుకోండి. మీ analytics ఇప్పటికే sessions ను city లేదా region ఆధారంగా విభజిస్తాయి. మీ కార్యాలయం ఉన్న ప్రదేశాన్ని బట్టి ఊహించకుండా, ఆ సమాచారాన్ని ఉపయోగించండి.

తర్వాత ఆ ప్రదేశం నుంచి కొలవండి. Ottawa లోని desk నుంచి Vancouver latency ను పరీక్షించలేరు. లక్ష్య నగరంలో hourly VPS ను 20 minutes కు rent చేసి, తర్వాత దాన్ని destroy చేయండి. ఒక colleague లేదా customer ను ఒక command run చేయమని అడగండి. లేదా https://atlas.ripe.net వద్ద ఉచిత RIPE Atlas measurement network ను ఉపయోగించండి. ఇందులో Canadian cities లో probes ఉంటాయి. వాటి నుంచి pings run చేయవచ్చు.

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 కనిపిస్తే, దాన్ని తప్పక పరిశీలించాలి. సగటు latency కొద్దిగా ఎక్కువగా ఉండటంకన్నా అధిక jitter voice మరియు games పై ఎక్కువ ప్రభావం చూపుతుంది. కారణం, receiver సాధారణ packet కోసం కాకుండా అత్యంత ఆలస్యమైన packet కోసం buffer చేయాల్సి రావడమే.

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

mtr ప్రతి hop కు loss ను చూపిస్తుంది. Permission error తో ఇది ముగిస్తే, sudo తో run చేయండి. Middle hops లో కనిపించే loss తరచుగా వాస్తవమైనది కాదు. ఎందుకంటే routers తాము సృష్టించే ICMP replies కు అత్యల్ప ప్రాధాన్యత ఇస్తాయి. 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 ఎక్కువ సమయం కోల్పోయేది సాధారణంగా ఈ చివరి gap లోనే. చిన్న path లో ttfb 0.8 s ఉంటే అది application సమస్య. Server ను మరొక నగరానికి తరలించడం వల్ల అది పరిష్కారం కాదు.

Throughput కోసం server ను VPS పై, client ను వినియోగదారుడి ప్రదేశం నుంచి run చేయండి. iperf3 TCP 5201 పై listen చేస్తుంది. అందువల్ల పరీక్ష కోసం ufw తో port ను open చేయండి. పూర్తయ్యాక దాన్ని మళ్లీ close చేయండి.

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 ను open చేస్తుంది. ఒక stream కంటే ఎనిమిది streams చాలా వేగంగా ఉంటే, పరిమితి link లో కాకుండా long path పై TCP window లో ఉంది. ఎందుకంటే ఒక stream ప్రతి round trip కు ఒక window మాత్రమే carry చేయగలదు. Vancouver path పై అదే window, New York path పై కంటే ప్రతి second కు సుమారు మూడో వంతు data మాత్రమే పంపుతుంది. Long-haul backups కూడా ఇదే విధంగా పనిచేస్తాయి. అందుకే వేగవంతమైన line ఉన్నప్పటికీ, దూరంలోని target కు restic తో off-site backups నెమ్మదిగా అనిపిస్తాయి.

iperf3 పనిచేస్తున్నప్పుడు రెండో terminal లో ping ను నిరంతరం run చేయండి. Transfer సమయంలో round trip 20 ms నుంచి 300 ms కు పెరిగితే, అది మీ స్వంత access equipment లోని bufferbloat. ఏ data centre location కూడా దాన్ని పరిష్కరించదు.

ఒకసారి కంటే ఎక్కువ కొలవండి. సాయంత్రం కూడా కొలవండి. 9pm సమయంలోని congestion నే మీ వినియోగదారులు వాస్తవంగా ఎదుర్కొంటారు. 4am కొలతను sales page చూపించడానికి ఇష్టపడుతుంది.

మీ workload కోసం round-trip time అర్థం

ఒక cold page load లో browser ఏదైనా render చేయడానికి ముందు నాలుగు 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 మార్గం 72 ms వెనుకబడి ప్రారంభమవుతుంది. Vancouver మార్గంలో అది 248 ms. ఒక్క 400 ms database queryతో పోలిస్తే ఈ రెండు విలువలు చాలా తక్కువ. Connection తెరిచిన తర్వాత HTTP/2 మరియు HTTP/3 అనేక requestsను ఒకేసారి అదే connectionపై పంపుతాయి. అందువల్ల ఈ ఖర్చు ప్రతి fileకు కాకుండా ఒక్కసారి మాత్రమే వస్తుంది. Static assetsను CDN (content delivery network)పై ఉంచితే వాటికి origin ఏ నగరంలో ఉందో అసలు ప్రభావం ఉండదు. అందుకే Torontoకు 98 ms దూరంలో ఉన్న European visitorకు కూడా page వేగంగా అందవచ్చు.

Real-time multiplayer games దీనికి విరుద్ధమైన సందర్భం. ఎందుకంటే round tripనే వినియోగ అనుభవం. వేగవంతమైన action gameలో సుమారు 50 ms కంటే తక్కువ latency తక్షణ స్పందనలా అనిపిస్తుంది. 80 ms దాటితే players గమనించడం ప్రారంభిస్తారు. 120 ms దాటిన తర్వాత వారు serverనే కారణంగా భావిస్తారు. ఇక్కడ region ఎంపిక product నాణ్యతను నిజంగా నిర్ణయిస్తుంది. నెమ్మదిగా సాగే gamesకు serversపై దూరం ప్రభావం చాలా తక్కువ. అందువల్ల shooterను పాడుచేసే దూరాన్ని VPSపై Minecraft server నడపడం తట్టుకోగలదు.

Region ఎంపిక వల్ల database పనితీరుపై అత్యధిక ప్రభావం ఉంటుంది. Applicationను ఒక regionలో, databaseను మరో regionలో ఎప్పుడూ ఉంచవద్దు. ప్రతి query ఒక round trip. ఒక page 40 queries పంపితే 40 round trips పడతాయి. ఒక్కోటి 18 ms అయితే దాదాపు ఒక సెకను పడుతుంది. ఒక్కోటి 62 ms అయితే రెండు సెకన్లకంటే ఎక్కువ పడుతుంది. Database అదే machineలో ఉన్నప్పుడు ఈ pageను 30 msగా profile చేశారు. మరో regionలోని read replicas మరియు disaster recovery కోసం asynchronous replication సరిపోతుంది. పొడవైన network pathపై synchronous commit చేస్తే, ప్రతి writeకు ఆ path latency జతవుతుంది.

Interactive sessions మధ్యస్థ సందర్భం. SSH సుమారు 100 ms వరకు సౌకర్యంగా ఉంటుంది. దాని కంటే ఎక్కువైతే lag అనిపిస్తుంది, ఎందుకంటే ప్రతి keystroke echo తిరిగి వచ్చే వరకు వేచి ఉండాలి. mosh స్థానికంగా ముందుగానే అంచనా వేసి, ఆ ఆలస్యాన్ని ఎక్కువగా దాచిపెడుతుంది. Webhooks మరియు internal APIs, అవి పిలిచే service ఉన్న అదే regionలోనే ఎల్లప్పుడూ ఉండాలి.

బిల్లింగ్, కరెన్సీ మరియు పన్ను

Canadian dollars లో చెల్లించడం వల్ల మీ card issuer వసూలు చేసే foreign transaction fee తప్పుతుంది. August 2026 నాటికి ఈ రుసుము సాధారణంగా 2.5% ఉంటుంది. అలాగే మీ లెక్కలు ఒకే కరెన్సీలో నిర్వహించవచ్చు. Canadian provider GST లేదా HSTతో invoice జారీ చేస్తుంది. Registered business ఈ మొత్తాన్ని input tax creditగా తిరిగి క్లెయిమ్ చేయవచ్చు. ఇది financeకు సంబంధించిన ప్రశ్న. దీనికి finance పరమైన సమాధానమే ఉంటుంది. Packets ఎక్కడికి వెళ్లాలో ఈ విషయం ఎప్పుడూ నిర్ణయించకూడదు. Serverకు వాస్తవంగా ఎంత ఖర్చవుతుంది, renewal pricing వల్ల ప్రభావితంకాకుండా plansను ఎలా పోల్చాలి అనే విషయాల కోసం VPSకు నెలకు వాస్తవంగా ఎంత ఖర్చవుతుంది చదవండి.

చిన్న మార్కెట్ వల్ల కలిగే వ్యయం

అమెరికాతో పోలిస్తే కెనడా చిన్న hosting మార్కెట్. అందువల్ల మీరు వదులుకునే అంశాలను కూడా పరిగణనలోకి తీసుకోవాలి.

• మీ కోసం పోటీ పడే providers తక్కువగా ఉంటారు. అందువల్ల అదే తరగతి machine కు RAM లేదా disk యొక్క gigabyteకు ధర సాధారణంగా ఎక్కువగా ఉంటుంది.
• Capacity Toronto మరియు Montreal నగరాల్లో కేంద్రీకృతమై ఉంటుంది. Vancouver మరియు Calgaryలో అది తక్కువగా ఉంటుంది. Failover కోసం రెండో Canadian region కావాలంటే మార్గం చాలా పొడవుగా ఉండవచ్చు లేదా మీరు దేశం వెలుపలికి వెళ్లాల్సి రావచ్చు.
• చిన్న regional host ఒకటి లేదా రెండు upstream carriersపై ఆధారపడి ఒకే buildingను నడిపి ఉండవచ్చు. ఎన్ని carriers ఉన్నాయో అడగండి. వాటిలో ఒకటి విఫలమైతే ఏమి జరుగుతుందో కూడా అడగండి.
• అందుబాటులో ఉన్న hardware ఎంపికలు తక్కువగా ఉంటాయి. US regionsలో పెద్ద instances మరియు GPU machines సులభంగా లభిస్తాయి. అందువల్ల మీరు కోరుకున్న నగరంలో, కోరుకున్న పరిమాణంలో GPU VPS ఉండకపోవచ్చు.
• చిన్న host వద్ద support coverage నిజమైన ప్రశ్న. అది marketing ప్రశ్న కాదు. మానవ support సిబ్బంది ఎప్పుడు అందుబాటులో ఉంటారో అడగండి.

ధర విషయంలో Montreal మినహాయింపు. Quebecలో hydroelectric power చవకగా ఉంటుంది. శీతాకాలం cooling costsను తగ్గిస్తుంది. అందువల్ల Montreal ప్రాంతంలో US regionsతో పోటీ పడే ratesకు పెద్ద capacity అందుబాటులో ఉంటుంది. మీ అవసరం కెనడాలో ఉండటమే కానీ నిర్దిష్ట నగరం కాదు అనుకుంటే, ముందుగా అక్కడి optionsను పరిశీలించండి.

Canadian VPS tiers మీ workloadకు చాలా చిన్నగా కనిపిస్తే, దేశమే సమస్య అని నిర్ణయించుకునే ముందు VPSను dedicated serverతో పోల్చండి.

కెనడాలో VPS hosting ఎంచుకోవడం సరైన నిర్ణయం అయ్యే సందర్భాలు

1. ఏదైనా చట్టం, ఒప్పందం లేదా ప్రభుత్వ రంగ విధానం కెనడాను నిర్దేశిస్తే, కెనడాలో host చేయండి. ఈ post లోని మిగతా అంశాలు ఏవీ వర్తించవు. Provider నుంచి data residency హామీని కూడా లిఖితపూర్వకంగా పొందండి.
2. మీ users అందరూ ఒకే Canadian metro ప్రాంతంలో ఉండి, workload latency పై ఆధారపడితే — multiplayer games, voice, remote desktops లేదా trading వంటి సందర్భాల్లో — సమీప నగరంలో host చేయండి. ఏదైనా ఒప్పందంపై సంతకం చేసే ముందు రెండు ఎంపికలను కొలవండి.
3. మీ users దేశమంతటా విస్తరించి ఉంటే, Toronto లేదా Montreal జనాభాలో అతిపెద్ద భాగాన్ని కవర్ చేస్తాయి. Static assets ముందు CDN ఉంచడం, origin server ను మార్చడం కంటే Vancouver లోని user కు ఎక్కువ ప్రయోజనం ఇస్తుంది.
4. మిగతా అన్ని సందర్భాల్లో, అంటే ఎక్కువ సందర్భాల్లో, ధర మరియు వాస్తవంగా లభించే hardware ఆధారంగా ఎంచుకోండి. తరువాత 2am సమయంలో support ఎలా ఉంటుందో పరిశీలించండి. ముందుగా అభ్యర్థి ఎంపికలను benchmark చేయండి, ఎందుకంటే ఒకే specification sheet ఉన్న రెండు plans ఒకే విధంగా పనిచేయవు: VPS ను సరిగ్గా benchmark చేయడం ఎలా.

మీరు ఏ ఎంపిక చేసినా, ఆ నిర్ణయం పక్కన కారణాన్ని రాసి ఉంచండి. ఇది కెనడాలో ఉండాలా అని తరువాత అడిగే వ్యక్తికి ఊహాగానం కంటే మెరుగైన ఆధారం అవసరం. కారణం ఎప్పుడైనా contract clause అయి ఉంటే, దాన్ని మళ్లీ ఎవరో కనుగొనాల్సి ఉంటుంది. Server సిద్ధమైన తర్వాత, కొత్త VPS లో మొదటి పది నిమిషాలు దాని నగరం కంటే మీ security కి ఎక్కువ ప్రాధాన్యం కలిగి ఉంటాయి.

FAQ

PIPEDA ప్రకారం నా డేటా కెనడాలోనే ఉండాలా?

లేదు. PIPEDA (Personal Information Protection and Electronic Documents Act) ప్రైవేట్ రంగానికి డేటా residency నియమాన్ని నిర్దేశించదు. వ్యక్తిగత సమాచారాన్ని మరో దేశంలోని processor కు పంపడం 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.

United States లో ఉన్న server ను Canadian 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 provider స్వాధీనం, custody లేదా control లో ఉన్న data పై US CLOUD Act వర్తిస్తుంది. అందువల్ల American company నిర్వహించే Canadian region కూడా దాని పరిధిలోనే ఉంటుంది. విదేశీ legal process మీ అసలు ఆందోళన అయితే, building address ను కాకుండా service ను ఎవరు నిర్వహిస్తున్నారు, encryption keys ఎవరి వద్ద ఉన్నాయి అన్నదాన్ని పరిశీలించండి. మీరు స్వయంగా కలిగి ఉన్న keys తో encryption చేస్తే, provider అప్పగించగల డేటా పరిమాణం మారుతుంది.

నేను నివసించని city నుంచి latency ను ఎలా కొలవాలి?

ఆ city లో hourly VPS ను అద్దెకు తీసుకుని, మీ స్వంత server కు తిరిగి ping -c 20 మరియు mtr --report --report-cycles 50 ను అమలు చేసి, తరువాత దాన్ని తొలగించండి. Canadian cities లో probes కలిగిన ఉచిత ప్రత్యామ్నాయం RIPE Atlas network. ICMP నిరోధించబడితే, దాని బదులు నిజమైన request సమయాన్ని curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ తో కొలవండి. ఇది TCP round trip మరియు first byte వరకు పట్టే మొత్తం సమయాన్ని చూపిస్తుంది.