கனடாவில் VPS Hosting தேவைப்படுவது எப்போது?

உங்கள் VPS கனடாவில் இருக்க வேண்டுமா?

தரவு கனடிய நிலப்பரப்பிலேயே இருக்க வேண்டும் என்று சட்டம் அல்லது ஒப்பந்தம் கூறும்போது, கனடாவில் VPS hosting-ஐத் தேர்வு செய்வது பொருத்தமானது. இதுவே ஒரே கட்டாயக் காரணம். Toronto-வில் உள்ள வீட்டு connection-இலிருந்து New York data centre-க்கு round trip சுமார் 18 ms ஆகும். Toronto data centre-க்கு இது சுமார் 3 ms ஆகும். பெரும்பாலான web application-களால் இந்த வேறுபாட்டைக் கண்டறிய முடியாது.

மூன்று காரணங்கள் மக்களை கனடிய server-ஐத் தேர்வு செய்யத் தூண்டுகின்றன. Data residency என்பது சட்டக் கடமை. எனவே, அது மட்டும் போதுமான காரணமாகும். Latency-ஐ அளவிட முடியும். பொதுவாக மக்கள் எதிர்பார்ப்பதைவிட அதன் வேறுபாடு குறைவாக இருக்கும். Canadian dollar-களில் billing செய்வது உங்கள் accountant-க்கு வசதியாக இருக்கும். வேறு எதையும் ஆய்வு செய்வதற்கு முன், முதல் காரணம் உங்களுக்குப் பொருந்துகிறதா என்பதைத் தீர்மானிக்கவும்.

இந்தப் பதிவு விதிகள் பொதுவாக எவ்வாறு செயல்படுகின்றன என்பதை விளக்குகிறது. இது சட்ட ஆலோசனை அல்ல. Privacy law உங்கள் organisation-க்கு பொருந்தினால், பதிலை உங்கள் counsel-இடமிருந்து பெறவும்.

Data residency: ஒரே கடுமையான தேவை

PIPEDA (Personal Information Protection and Electronic Documents Act) என்பது கனடாவின் மத்திய தனியார் துறைத் தனியுரிமைச் சட்டமாகும். தனிப்பட்ட தகவல்கள் நாட்டுக்குள் மட்டுமே இருக்க வேண்டும் என்று இது கட்டாயப்படுத்தாது. வெளிநாட்டில் உள்ள processor-க்கு தரவை அனுப்புவதை, processing-க்கான transfer ஆக இது கருதுகிறது. தரவுக்கான பொறுப்பு உங்கள் organisation-க்கே தொடரும். processor அதற்கு ஒப்பிடத்தக்க பாதுகாப்பை வழங்க வேண்டும். இந்த transfer நடைபெறுகிறது என்பதை மக்களிடம் வெளிப்படையாகத் தெரிவிக்க வேண்டும். Office of the Privacy Commissioner இதை கடுமையாக்குவது குறித்து 2019-ல் ஆலோசனை நடத்தியது. பின்னர் அது தனது நடைமுறையில் இருந்த நிலைப்பாட்டையே தொடர்ந்தது. எனவே PIPEDA காரணமாக உங்கள் data கனடாவில் இருக்க வேண்டும் என்ற பொதுவான கூற்று தவறானது. பல hosting விளம்பர உள்ளடக்கங்கள் அதை மீண்டும் கூறினாலும் இது உண்மை அல்ல.

உண்மையான residency விதிகள் உள்ளன. அவை குறிப்பிட்ட குறுகிய துறைகளில் பொருந்துகின்றன.

• Quebec-ன் Law 25, தனிப்பட்ட தகவல்களை மாகாணத்துக்கு வெளியே அனுப்புவதற்கு முன் assessment நடத்த வேண்டும் என்று கோருகிறது. தகவல் சென்ற இடத்தில் அதற்கு போதுமான பாதுகாப்பு கிடைக்க வேண்டும். இந்த விதி September 2023 முதல் அமலில் உள்ளது. இது நீங்கள் விளக்கி நியாயப்படுத்தக்கூடிய paperwork மற்றும் decision ஆகும்; முழுத் தடை அல்ல.
• Public-sector விதிகள் public bodies மற்றும் அவற்றுக்கு சேவை வழங்கும் companies மீது கட்டுப்பாடுகளை விதிக்கின்றன. Nova Scotia-வின் PIIDPA, தனிப்பட்ட தகவல்களை Canada-க்கு வெளியே சேமிப்பதை கட்டுப்படுத்துகிறது. British Columbia-வின் FIPPA-யிலும் இதேபோன்ற விதி இருந்தது. 2021-ல் செய்யப்பட்ட amendment மூலம் assessment-க்கு பிறகு foreign storage அனுமதிக்கப்பட்டது.
• Federal government பணிகள் Government of Canada's cloud direction-ஐப் பின்பற்றுகின்றன. Protected B மற்றும் அதற்கு மேற்பட்ட data Canada-வில் இருக்க வேண்டும் என்று அது கோருகிறது.
• Provincial health privacy laws, health records எங்கு இருக்கலாம் என்பதற்கு தங்களுக்கான நிபந்தனைகளை விதிக்கின்றன. அவை ஒவ்வொரு province-க்கும் மாறுபடும்.
• நடைமுறையில் customer contracts மற்றும் public tenders ஆகியவையே பொதுவான காரணிகளாக உள்ளன. "data at rest in Canada" என்று security questionnaire-ல் கூறப்பட்டிருந்தால், நீங்கள் அதில் கையெழுத்திட்டதால் அது ஒரு statute அளவுக்கு உங்களை கட்டுப்படுத்தும்.

நடைமுறைச் சோதனை எளிதானது. அந்த clause-ஐ நீங்கள் சுட்டிக்காட்ட முடியுமா? Canada என்று கூறும் statute அல்லது contract-ஐ உங்கள் organisation-ல் யாராலும் குறிப்பிட முடியாவிட்டால், latency மற்றும் price அடிப்படையில் நீங்கள் தேர்வு செய்கிறீர்கள்.

கனடா data centre அமெரிக்க சட்ட வரம்பிற்கு வெளியிலா?

தனியாகப் பார்த்தால் இல்லை. US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) என்பது hardware எங்கு இருந்தாலும், US provider-ன் possession, custody அல்லது control-இல் உள்ள data-க்கு பொருந்தும். ஆகவே, அமெரிக்க நிறுவனம் இயக்கும் Toronto region அதன் சட்ட வரம்பிற்குள் இருக்கும். உண்மையான தேவை geography பற்றியது அல்லாமல், வெளிநாட்டு legal process பற்றியதாக இருந்தால், service-ஐ யார் இயக்குகிறார்கள் மற்றும் encryption keys யாரிடம் உள்ளன என்பதே முக்கியம். கட்டிடம் கனடாவில் உள்ளதற்கான address மட்டும் இதற்குப் பதில் அளிக்காது.

Routing இரண்டாவது எதிர்பாராத அம்சமாகும். இரண்டு Canadian நகரங்களுக்கு இடையிலான traffic, United States வழியாகச் செல்லக்கூடும். காரணம், வரலாற்று ரீதியாக cheap 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 ஒன்றைப் பயன்படுத்தலாம். Fibre எந்த நாட்டின் வழியாகச் செல்கிறது என்பது அதற்கு பொருட்டல்ல.

தாமதம்: அதை அளவிடுங்கள், ஊகிக்க வேண்டாம்

Fibre-இல் ஒளி ஒரு millisecond-க்கு சுமார் 200 km பயணிக்கும். எனவே, எந்த equipment-உம் சேர்க்கப்படுவதற்கு முன்பே, ஒவ்வொரு 100 km தூரமும் round trip-க்கு சுமார் 1 ms தாமதத்தைச் சேர்க்கிறது. Toronto முதல் Vancouver வரை நேர்கோட்டில் சுமார் 3,400 km தூரம் உள்ளது; cable வழித்தடம் இதைவிட நீளமானது. இதனால் குறைந்தபட்ச தாமதம் சுமார் 40 ms ஆகும். நடைமுறை network paths இதைவிட அதிகமாக இருக்கும்.

[
  {
    "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-க்கு அருகில் இருப்பதற்கு சமமல்ல.

எப்படியிருந்தாலும் last mile பெரும்பாலும் முக்கியமான தாமதத்தை உருவாக்குகிறது. Home fibre சில milliseconds தாமதத்தைச் சேர்க்கும். Cable line busy ஆக இருக்கும்போது மேலும் தாமதத்தைச் சேர்க்கும். 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-ஐ சோதிக்க முடியாது. இலக்கு city-யில் ஒரு மணி நேர அடிப்படையிலான VPS-ஐ இருபது நிமிடங்களுக்கு வாடகைக்கு எடுத்து, பின்னர் அதை அழித்துவிடுங்கள். ஒரு colleague அல்லது customer-ஐ ஒரு command இயக்கச் சொல்லுங்கள். அல்லது https://atlas.ripe.net இல் உள்ள இலவச 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

கடைசி இரண்டு வரிகளைப் படியுங்கள்.

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-களுக்கு இடையிலான வேறுபாடு. குறுகிய பாதையில் ஏற்படும் எந்த 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 ஆகும். முதலில் கீழ் வரியைப் படியுங்கள். பின்னர் மேல்நோக்கிச் செல்லுங்கள்.

ICMP தடுக்கப்பட்டிருந்தால் அல்லது 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 தொடங்கிய நேரத்திலிருந்து சேர்க்கப்பட்ட seconds-ஐக் காட்டும். connect இலிருந்து dns-ஐக் கழித்தால் ஒரு TCP round trip கிடைக்கும். tls இலிருந்து connect-ஐக் கழித்தால் handshake நேரம் கிடைக்கும். ttfb இலிருந்து tls-ஐக் கழித்தால் மேலும் ஒரு round trip மற்றும் உங்கள் application பதிலளிக்க எடுத்த நேரம் கிடைக்கும். பெரும்பாலான slow sites உண்மையில் தாமதப்படும் பகுதி இந்தக் கடைசி இடைவெளியாகும். குறுகிய பாதையில் ttfb 0.8 s ஆக இருந்தால், அது application பிரச்சினை. Server-ஐ வேறு city-க்கு மாற்றுவது இதைச் சரிசெய்யாது.

Throughput-ஐ அளவிட, server-ஐ VPS-ல் இயக்கி, client-ஐ பயனரின் பக்கத்திலிருந்து இயக்குங்கள். iperf3 TCP 5201-ல் listen செய்கிறது. எனவே சோதனைக்காக ufw மூலம் port-ஐத் திறக்கவும். முடித்ததும் அதை மீண்டும் 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 திசையை மாற்றுகிறது. இதனால் upload மட்டுமல்லாமல் download-ஐயும் அளவிடலாம். -P 8 எட்டு parallel streams-ஐத் திறக்கும். ஒரு stream-ஐ விட எட்டு streams மிகவும் வேகமாக இருந்தால், வரம்பு link-ல் இல்லை; நீண்ட பாதையில் உள்ள TCP window-ல் உள்ளது. காரணம், ஒரு stream ஒவ்வொரு round trip-க்கும் ஒரு window அளவிலான தரவை மட்டுமே எடுத்துச் செல்ல முடியும். Vancouver பாதையில் உள்ள அதே window, New York பாதையைவிட ஒரு second-க்கு சுமார் மூன்றில் ஒரு பங்கு அளவு data-ஐ மட்டுமே நகர்த்தும். நீண்ட தூர 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 என்பதன் பொருள்

ஒரு cold page load, browser எதையும் வரையத் தொடங்குவதற்கு முன் நான்கு round trip-களைச் செலவிடுகிறது.

[
  {
    "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-க்கு குறைவான தாமதம் உடனடியாகப் பதிலளிப்பது போல இருக்கும். 80 ms அருகில் players தாமதத்தை உணரத் தொடங்குவார்கள். 120 ms-ஐ கடந்தால் அவர்கள் server-ஐக் குறை கூறுவார்கள். இங்கு region தேர்வு உண்மையிலேயே product-ன் தரத்தை நிர்ணயிக்கிறது. மெதுவான வேகத்தில் இயங்கும் servers அதிக தாமதத்தைப் பொறுத்துக்கொள்ளும். எனவே VPS-ல் Minecraft server இயக்குவது shooter game-ஐ பாதிக்கும் தூரங்களையும் சமாளிக்கிறது.

Region தேர்வு உண்மையான பாதிப்பை ஏற்படுத்தும் இடம் databases ஆகும். Application-ஐ ஒரு region-லும் database-ஐ வேறு region-லும் ஒருபோதும் வைக்காதீர்கள். ஒவ்வொரு query-யும் ஒரு round trip ஆகும். ஒரு page 40 queries அனுப்பினால், அவற்றில் 40 round trip-களுக்கான தாமதம் ஏற்படும். ஒவ்வொன்றும் 18 ms என்றால், மொத்தம் கிட்டத்தட்ட ஒரு second ஆகும். ஒவ்வொன்றும் 62 ms என்றால், அது இரண்டு seconds-ஐத் தாண்டும். அதே page-ல் database-ஐ அதே box-ல் வைத்தபோது profile செய்யப்பட்ட தாமதம் 30 ms மட்டுமே. மற்றொரு region-க்கு asynchronous replication செய்வது read replicas மற்றும் disaster recovery-க்கு ஏற்றது. நீண்ட network path முழுவதும் synchronous commit செய்வது, அந்த path-ன் தாமதத்தை ஒவ்வொரு write-க்கும் சேர்க்கிறது.

Interactive sessions நடுநிலையான நிலை. SSH சுமார் 100 ms வரை வசதியாக இருக்கும். அதற்கு மேல் lag உணரப்படும். ஒவ்வொரு keystroke-ன் echo திரும்பி வரும்வரை காத்திருக்க வேண்டியிருப்பதே காரணம். mosh உள்ளூரிலேயே கணித்து, அந்த தாமதத்தின் பெரும்பகுதியை மறைக்கிறது. Webhooks மற்றும் internal APIs, அவை அழைக்கும் service இருக்கும் அதே region-ல் எப்போதும் இருக்க வேண்டும்.

Billing, currency and tax

Canadian dollars செலுத்தினால், உங்கள் card issuer வசூலிக்கும் foreign transaction fee தவிர்க்கப்படுகிறது. August 2026 நிலவரப்படி, இந்தக் கட்டணம் பொதுவாக 2.5% ஆக இருக்கும். மேலும், உங்கள் கணக்குப் பதிவுகள் ஒரே currency-யில் பராமரிக்கப்படுகின்றன. Canadian provider, GST அல்லது HST உடன் invoice வழங்கும். பதிவு செய்யப்பட்ட business, இதை input tax credit ஆக திரும்பக் கோரலாம். இது finance தொடர்பான கேள்வி; அதற்கான பதிலும் finance சார்ந்ததே. 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 ஒன்று, ஒன்று அல்லது இரண்டு upstream carriers-ஐ சார்ந்த ஒரே building-ஐ இயக்கக்கூடும். எத்தனை carriers உள்ளனர் என்று கேளுங்கள். அவர்களில் ஒருவர் செயலிழந்தால் என்ன நடக்கும் என்றும் கேளுங்கள்.
• Hardware தேர்வுகள் குறைவாக இருக்கும். பெரிய instances மற்றும் GPU machines-ஐ US regions-ல் எளிதாகக் காணலாம். எனவே நீங்கள் விரும்பும் நகரத்தில், நீங்கள் விரும்பும் அளவில் GPU VPS கிடைக்காமல் இருக்கலாம்.
• சிறிய host-இல் support coverage உண்மையான கேள்வியாகும்; அது marketing கேள்வி மட்டும் அல்ல. மனித support பணியாளர் எப்போது விழித்திருந்து பணியாற்றுகிறார் என்று கேளுங்கள்.

விலையைப் பொறுத்தவரை Montreal விதிவிலக்காகும். Quebec-இன் hydroelectric power மலிவானது. குளிர்காலம் cooling செலவைக் குறைக்கிறது. எனவே Montreal பகுதி, US regions உடன் போட்டியிடும் rates-ல் அதிக capacity-ஐ வழங்குகிறது. உங்கள் தேவைக்கு Canada போதுமானது; குறிப்பிட்ட ஒரு நகரம் அவசியமில்லை என்றால், முதலில் அந்தப் பகுதியைக் கருத்தில் கொள்ளுங்கள்.

Canadian VPS tiers உங்கள் workload-க்கு மிகவும் சிறியதாகத் தெரிந்தால், நாடுதான் பிரச்சினை என்று முடிவு செய்வதற்கு முன் VPS-ஐ dedicated server உடன் ஒப்பிடுங்கள்.

Canada-ல் VPS hosting தேர்வு செய்வது சரியானதாக இருக்கும் நிலைகள்

1. ஒரு சட்டம், ஒப்பந்தம் அல்லது பொதுத்துறை கொள்கையில் Canada குறிப்பிடப்பட்டிருந்தால், Canada-ல் host செய்யுங்கள். இந்தப் பதிவில் உள்ள வேறு எதுவும் பொருந்தாது. Provider-இடமிருந்து residency commitment-ஐ எழுத்துப்பூர்வமாகவும் பெற வேண்டும்.
2. உங்கள் users ஒரே Canadian metro பகுதியில் உள்ளனர், மேலும் workload latency-ஐ சார்ந்துள்ளது: multiplayer games, voice, remote desktops அல்லது trading. அருகிலுள்ள நகரத்தில் host செய்யுங்கள். எந்த ஒப்பந்தத்திலும் கையெழுத்திடுவதற்கு முன், இரண்டு options-ஐயும் அளவிடுங்கள்.
3. உங்கள் users நாடு முழுவதும் பரவியுள்ளனர். Toronto அல்லது Montreal மக்கள் தொகையின் மிகப்பெரிய பகுதியை உள்ளடக்கும். Static assets-க்கு முன்பாக CDN அமைப்பது, origin-ஐ மாற்றுவதைவிட Vancouver-ல் உள்ள visitor-க்கு அதிக பயன் தரும்.
4. மற்ற எல்லா நிலைகளிலும், அதுவே பெரும்பாலான சந்தர்ப்பங்கள். Price மற்றும் நீங்கள் உண்மையில் பெறும் hardware அடிப்படையில் தேர்வு செய்யுங்கள். பின்னர் 2am நேரத்தில் support எப்படி இருக்கும் என்பதைச் சரிபாருங்கள். Candidate-ஐ முதலில் benchmark செய்யுங்கள். ஒரே specification sheet கொண்ட இரண்டு plans ஒரே செயல்திறனை வழங்காது: VPS-ஐ சரியாக benchmark செய்வது எப்படி.

நீங்கள் எந்தத் தேர்வைச் செய்தாலும், அந்தத் தீர்மானத்துக்கு அருகில் காரணத்தை எழுதிவையுங்கள். இது Canada-ல் இருக்க வேண்டுமா என்று அடுத்ததாகக் கேட்கும் நபருக்கு, ஊகத்தைவிடச் சிறந்த பதில் தேவைப்படும். பதில் எப்போதாவது ஒரு contract clause ஆக இருந்திருந்தால், அதை மீண்டும் யாராவது கண்டுபிடிக்க வேண்டியிருக்கும். Box உருவானதும், புதிய VPS-ல் முதல் பத்து நிமிடங்கள் அதன் city-யைவிட உங்கள் security-க்கு அதிக முக்கியத்துவம் பெறும்.

FAQ

PIPEDA விதிகளின்படி எனது data கனடாவிலேயே இருக்க வேண்டுமா?

இல்லை. PIPEDA (Personal Information Protection and Electronic Documents Act) தனியார் துறைக்கு data residency விதியை விதிக்கவில்லை. மற்றொரு நாட்டில் உள்ள processor-க்கு personal information-ஐ அனுப்புவது processing-க்கான transfer ஆகும். Data-க்கு உங்கள் organisation தொடர்ந்து பொறுப்பாக இருக்கும். Processor ஒப்பிடத்தக்க பாதுகாப்பை வழங்க வேண்டும். இந்த transfer நடைபெறுகிறது என்பதை மக்களிடம் வெளிப்படையாகத் தெரிவிக்க வேண்டும். 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-க்கான round trip சுமார் 26 ms ஆகும். இவை இரண்டும் Toronto-விலிருந்து Vancouver-க்கான 62 ms-ஐவிடக் குறைவு. Users, 20 ms network தாமதத்தை கவனிப்பதற்கு முன்பே server response time மற்றும் page weight-ஐ கவனிப்பார்கள். Real-time games, voice calls, மற்றும் ஒருவர் மற்றொருவரின் செயலுக்கு உடனடியாகப் பதிலளிக்கும் பயன்பாடுகளில் இதை அவர்கள் கவனிப்பார்கள்.

Canadian data centre, US சட்டத்தின் வரம்புக்கு வெளியிலா?

தானாகவே இல்லை. Server எங்கு இருந்தாலும், US CLOUD Act, US provider-ன் possession, custody அல்லது control-இல் உள்ள data-க்கு பொருந்தும். எனவே American company இயக்கும் Canadian region-உம் இந்தச் சட்டத்தின் கீழ் வரும். Foreign legal process தான் உங்கள் உண்மையான கவலை என்றால், கட்டிடத்தின் முகவரியைப் பார்ப்பதைவிட service-ஐ யார் இயக்குகிறார்கள் மற்றும் encryption keys யாரிடம் உள்ளன என்பதைப் பாருங்கள். நீங்கள் தானே வைத்திருக்கும் keys மூலம் encryption செய்வது, provider ஒப்படைக்கக்கூடிய data-வின் அளவை மாற்றுகிறது.

நான் வசிக்காத ஒரு நகரத்திலிருந்து latency-ஐ எவ்வாறு அளப்பது?

அந்த நகரத்தில் hourly VPS-ஐ வாடகைக்கு எடுத்து, உங்கள் சொந்த server-க்கு ping -c 20 மற்றும் mtr --report --report-cycles 50 இயக்குங்கள். பின்னர் அந்த VPS-ஐ அழிக்கவும். Canadian நகரங்களில் probes கொண்ட RIPE Atlas network ஒரு இலவச மாற்று வழியாகும். ICMP தடுக்கப்பட்டிருந்தால், அதற்குப் பதிலாக உண்மையான request-ஐ curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ மூலம் அளவிடுங்கள். இது TCP round trip மற்றும் முதல் byte கிடைக்கும் வரை எடுத்த முழு நேரத்தையும் வழங்கும்.