కెనడాలో VPS Hosting ఎప్పుడు అవసరం?

మీ VPS కెనడాలో ఉండాలా?

డేటా కెనడా భూభాగంలోనే ఉండాలని చట్టం లేదా ఒప్పందం నిర్దేశించినప్పుడు కెనడాలో VPS hosting ఎంచుకోవడం సముచితం. అదే ఏకైక తప్పనిసరి కారణం. Torontoలోని ఇంటి కనెక్షన్ నుంచి New York data centreకి వెళ్లి తిరిగి రావడానికి సుమారు 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) కెనడా సమాఖ్య ప్రైవేట్ రంగ గోప్యతా చట్టం. వ్యక్తిగత సమాచారం దేశంలోనే ఉండాలని ఇది నిర్దేశించదు. విదేశాల్లోని ప్రాసెసర్‌కు డేటాను పంపడాన్ని ప్రాసెసింగ్ కోసం బదిలీగా ఇది పరిగణిస్తుంది. డేటాకు బాధ్యత మీ సంస్థపైనే ఉంటుంది. ప్రాసెసర్ సమాన స్థాయి రక్షణ కల్పించాలి. ఈ ప్రక్రియ జరుగుతుందని వ్యక్తులకు పారదర్శకంగా తెలియజేయాలి. Office of the Privacy Commissioner దీనిని కఠినతరం చేయడంపై 2019లో సంప్రదింపులు జరిపింది. అనంతరం అది తన ప్రస్తుత వైఖరినే కొనసాగించింది. అందువల్ల PIPEDA ప్రకారం మీ డేటా కెనడాలోనే ఉండాలి అనే సాధారణ వాదన తప్పు. అనేక hosting కాపీల్లో అది పునరావృతమైనా ఈ విషయం మారదు.

నిజమైన డేటా-నివాస నియమాలు ఉన్నాయి. అవి మరింత పరిమిత పరిధి ఉన్న సందర్భాల్లో వర్తిస్తాయి.

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

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

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

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

Routing రెండవ ఆశ్చర్యకరమైన అంశం. రెండు Canadian నగరాల మధ్య 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: కొలవండి, ఊహించవద్దు

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

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

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

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

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

తర్వాత అదే ప్రదేశం నుంచి కొలవండి. Ottawa లోని desk నుంచి Vancouver latency ను పరీక్షించలేరు. లక్ష్య city లో ఒక గంటకు VPS ను ఇరవై నిమిషాల పాటు 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 కనిపిస్తే, దాని కారణాన్ని తప్పక పరిశీలించాలి. కొద్దిగా ఎక్కువ average 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 తాము generate చేసే ICMP replies కు అతి తక్కువ priority ఇస్తాయి. Final line వరకు కొనసాగుతున్న 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 ను మరో city కి మార్చడం వల్ల అది పరిష్కారం కాదు.

Throughput కోసం, VPS పై server ను run చేయండి. User వైపు నుంచి client ను run చేయండి. iperf3 TCP 5201 పై listen చేస్తుంది. అందువల్ల test కోసం 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 ను మాత్రమే మోయగలదు. Vancouver path పై అదే window, New York path తో పోలిస్తే, ప్రతి second కు సుమారు మూడో వంతు data మాత్రమే తరలిస్తుంది. Long-haul backups కూడా ఇదే విధంగా పనిచేస్తాయి. అందుకే fast 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 చూపించడానికి ఎక్కువగా ఇష్టపడుతుంది.

మీ పనిభారానికి round-trip time అర్థం

బ్రౌజర్ ఏదైనా గీయడానికి ముందు, ఒక 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 మార్గంలో 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 కూడా fast page పొందగలరు.

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

Databases విషయంలో region ఎంపిక తీవ్రమైన ప్రభావం చూపుతుంది. Application ను ఒక region లో, database ను మరొక region లో ఎప్పుడూ ఉంచవద్దు. ప్రతి query ఒక round trip. 40 queries పంపే page వాటి కోసం 40 round trips చెల్లిస్తుంది. ఒక్కోటి 18 ms అయితే దాదాపు ఒక second పడుతుంది. ఒక్కోటి 62 ms అయితే రెండు seconds కంటే ఎక్కువ పడుతుంది. ఇదే page లో database అదే box పై ఉన్నప్పుడు profiling ఫలితం 30 ms మాత్రమే. మరో region కు asynchronous replication ను read replicas మరియు disaster recovery కోసం ఉపయోగించవచ్చు. పొడవైన మార్గంలో synchronous commit చేస్తే, ఆ మార్గపు ఆలస్యం ప్రతి write కు చేరుతుంది.

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

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

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

చిన్న మార్కెట్ మీపై మోపే ఖర్చు

యునైటెడ్ స్టేట్స్‌తో పోలిస్తే Canada చిన్న hosting మార్కెట్. మీరు వదులుకునే విషయాలను కూడా నిజాయితీగా పరిగణించాలి.

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

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

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

కెనడాలో VPS hosting ఎప్పుడు సరైన ఎంపిక

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

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

FAQ

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

లేదు. PIPEDA (Personal Information Protection and Electronic Documents Act)లో private sector కోసం data residency నియమం లేదు. Personal informationను మరో దేశంలోని processorకు పంపడం processing కోసం transferగా పరిగణించబడుతుంది: డేటాకు మీ organisationనే బాధ్యత వహిస్తుంది, 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 కంటే తక్కువ. Users 20 ms network latencyను గమనించేలోపే server response time మరియు page weightను గమనిస్తారు. అయితే real-time games, voice calls, అలాగే ఒక వ్యక్తి మరొక వ్యక్తి ప్రతిస్పందనకు అనుగుణంగా స్పందించే సందర్భాల్లో దీన్ని గమనిస్తారు.

Canadian data centre US law పరిధికి బయట ఉంటుందా?

తప్పనిసరిగా కాదు. Server ఎక్కడ ఉన్నా, US CLOUD Act ఒక US provider ఆధీనంలో, సంరక్షణలో లేదా నియంత్రణలో ఉన్న dataకు వర్తిస్తుంది. అందువల్ల American company నిర్వహించే Canadian region కూడా దాని పరిధిలో ఉంటుంది. విదేశీ legal process మీ అసలు ఆందోళన అయితే, భవనం చిరునామా కంటే serviceను ఎవరు నిర్వహిస్తున్నారు, encryption keys ఎవరి వద్ద ఉన్నాయి అనే విషయాలను పరిశీలించండి. మీరు స్వయంగా ఉంచుకునే keysతో encryption చేయడం వల్ల provider అప్పగించగల సమాచార పరిధి మారుతుంది.

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

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