কানাডায় VPS Hosting: আসলে কী গুরুত্বপূর্ণ?

আপনার 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 dollar-এ billing করা accountant-এর জন্য সুবিধাজনক। অন্য কোনো বিষয় বিবেচনা করার আগে প্রথম কারণটি আপনার ক্ষেত্রে প্রযোজ্য কি না নির্ধারণ করুন।

এই পোস্টে সাধারণভাবে নিয়মগুলো কীভাবে কাজ করে তা ব্যাখ্যা করা হয়েছে। এটি legal advice নয়। কোনো privacy law আপনার প্রতিষ্ঠানের ক্ষেত্রে প্রযোজ্য হলে উত্তরটি আপনার legal counsel-এর কাছ থেকে নিন।

ডেটা কোথায় থাকবে: একমাত্র কঠোর শর্ত

PIPEDA (Personal Information Protection and Electronic Documents Act) কানাডার ফেডারেল private-sector privacy law। এটি personal information দেশের ভেতরে রাখার শর্ত দেয় না। বিদেশের কোনো processor-কে data পাঠানোকে এটি processing-এর জন্য transfer হিসেবে বিবেচনা করে: data-এর জন্য দায়বদ্ধতা আপনার organisation-এর কাছেই থাকে, processor-কে comparable protection দিতে হয়, এবং এমনটি ঘটছে—এ কথা মানুষকে স্পষ্টভাবে জানাতে হয়। Office of the Privacy Commissioner 2019 সালে এই নিয়ম কঠোর করার বিষয়ে পরামর্শ নিয়েছিল, কিন্তু পরে বিদ্যমান অবস্থানই বজায় রাখে। PIPEDA-এর private-sector rules বদলে নতুন Protecting Privacy and Consumer Data Act চালু করার জন্য June 2026-এ Bill C-36 উত্থাপন করা হয়েছিল। October 2026 পর্যন্ত এটি second reading-এ পৌঁছায়নি। তাই প্রযোজ্য আইন এখনও PIPEDA। ফলে PIPEDA অনুযায়ী আপনার data অবশ্যই Canada-তে থাকতে হবে—এই প্রচলিত দাবি ভুল, যদিও অনেক hosting copy-তে তা বারবার লেখা হয়।

বাস্তব residency rules অবশ্যই আছে। তবে সেগুলো নির্দিষ্ট কিছু ক্ষেত্রে প্রযোজ্য।

• Quebec-এর Law 25 অনুযায়ী personal information province-এর বাইরে পাঠানোর আগে assessment করতে হয় এবং তথ্য যেখানে পৌঁছাবে, সেখানে adequate protection পেতে হবে। এই বিধান September 2023 থেকে কার্যকর। এটি paperwork এবং এমন একটি সিদ্ধান্ত, যেটি আপনাকে যুক্তিসহ ব্যাখ্যা করতে সক্ষম হতে হবে; এটি নিষেধাজ্ঞা নয়।
• Public-sector rules public bodies এবং তাদের সেবা দেওয়া companies-কে বাধ্য করে। Nova Scotia-এর PIIDPA Canada-এর বাইরে personal information সংরক্ষণ সীমিত করে। October 2025-এ পাস হওয়া নতুন Freedom of Information and Protection of Privacy Act 1 April 2027-এ এটি প্রতিস্থাপন করবে। 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। কোনো security questionnaire-এ যদি "data at rest in Canada" লেখা থাকে, তাহলে সেটি statute-এর মতোই আপনাকে বাধ্য করে, কারণ আপনি তাতে স্বাক্ষর করেছেন।

ব্যবহারিক পরীক্ষাটি সহজ। আপনি কি সংশ্লিষ্ট clause দেখাতে পারেন? আপনার organisation-এর কেউ যদি Canada-র শর্ত দেওয়া statute বা contract-এর নাম বলতে না পারেন, তাহলে আপনি latency এবং price-এর ভিত্তিতে সিদ্ধান্ত নিচ্ছেন।

কানাডার data centre কি US-এর আইনগত আওতার বাইরে?

নিজে থেকে নয়। US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) কোনো US provider-এর দখল, হেফাজত বা নিয়ন্ত্রণে থাকা data-এর ক্ষেত্রে প্রযোজ্য, hardware যেখানেই থাকুক না কেন। তাই কোনো American company পরিচালিত Toronto region এই আইনের আওতায় পড়ে। প্রকৃত প্রয়োজন যদি ভৌগোলিক অবস্থানের বদলে বিদেশি আইনগত প্রক্রিয়া নিয়ে হয়, তাহলে গুরুত্বপূর্ণ বিষয় হলো service কে পরিচালনা করে এবং encryption key কার নিয়ন্ত্রণে আছে। ভবনটি কানাডায় অবস্থিত—এই তথ্য একাই প্রশ্নটির উত্তর দেয় না।

Routing দ্বিতীয় অপ্রত্যাশিত বিষয়। দুটি Canadian শহরের মধ্যে traffic প্রায়ই United States-এর মধ্য দিয়ে যায়, কারণ ঐতিহাসিকভাবে সস্তা peering সেখানেই বেশি ছিল। গবেষকেরা এটিকে boomerang routing বলেন। আপনার packet কখনও দেশের বাইরে যায় না—এমন দাবি করার আগে traceroute চালান।

traceroute vps.example.com

Hop-এর নামগুলিতে nyc, chi বা ash-এর মতো city code থাকতে পারে। এই নামগুলো ইঙ্গিতমাত্র এবং সময়ের সঙ্গে পুরোনো হয়ে যায়। তাই এগুলোকে প্রমাণ হিসেবে নয়, provider-কে প্রশ্ন করার কারণ হিসেবে বিবেচনা করুন। Transit অবস্থায় থাকা data-এর জন্য নির্ভরযোগ্য সমাধান হলো আপনার নিয়ন্ত্রণে থাকা encryption, কোনো মানচিত্র নয়। নিজের machine-গুলোর মধ্যে private path চাইলে নিজে পরিচালিত WireGuard VPN ব্যবহার করতে পারেন। Fibre কোন দেশের মধ্য দিয়ে গেছে, সেটি এতে গুরুত্বপূর্ণ নয়।

Latency: মাপুন, অনুমান করবেন না

Fibre-এর ভেতর আলো প্রতি millisecond-এ প্রায় 200 km অতিক্রম করে। তাই equipment বিবেচনায় নেওয়ার আগেই প্রতি 100 km দূরত্বে round trip-এ প্রায় 1 ms যোগ হয়। Toronto থেকে Vancouver সরলরেখায় প্রায় 3,400 km দূরে, আর cable route আরও দীর্ঘ। ফলে সর্বনিম্ন latency প্রায় 40 ms-এর কাছাকাছি। বাস্তব path-এ মান আরও বেশি হয়।

[
  {
    "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-এর ওপর নির্ভর করে। দিনের সময় অনুযায়ী এগুলো পরিবর্তিতও হয়।

দুটি row দুবার পড়ার মতো। Toronto থেকে Montreal প্রায় 12 ms, যা যথেষ্ট কম; বেশিরভাগ ব্যবহারে দুই শহরকে একটি region হিসেবে ধরা যায়। Toronto থেকে Vancouver প্রায় 62 ms, যা Toronto থেকে Northern Virginia-এর 26 ms-এর চেয়ে বেশি। Canada-তে থাকা মানেই আপনার users-এর কাছাকাছি থাকা নয়।

যাই হোক, সাধারণত last mile-ই বেশি প্রভাব ফেলে। Home fibre কয়েক millisecond যোগ করে। Line ব্যস্ত থাকলে cable আরও বেশি latency যোগ করে। Mobile connection নিজেই কয়েক দশক millisecond যোগ করতে পারে। Toronto-র কোনো phone user Toronto server-এ 50 ms দেখতে পারেন। Server-টি New York-এ সরালে path-এ সবার জন্য প্রায় একই 15 ms যোগ হবে। মোট latency হবে প্রায় 65 ms। তবু ওই user-এর অপেক্ষার অধিকাংশ সময় radio link-এই ব্যয় হবে।

আপনার ব্যবহারকারীরা যেখান থেকে সংযোগ করেন, সেখান থেকে latency কীভাবে পরীক্ষা করবেন

প্রথমে নির্ধারণ করুন আপনার ব্যবহারকারীরা আসলে কোথায় আছেন। আপনার analytics ইতিমধ্যে session-গুলোকে city বা region অনুযায়ী ভাগ করে। আপনার office কোথায়, তা ধরে অনুমান না করে এই তথ্য ব্যবহার করুন।

এরপর সেই স্থান থেকেই মাপ নিন। Ottawa-এর desk থেকে Vancouver-এর latency পরীক্ষা করা যায় না। লক্ষ্য city-তে 20 মিনিটের জন্য hourly VPS ভাড়া নিন এবং কাজ শেষে সেটি মুছে ফেলুন। কোনো colleague বা customer-কে একটি command চালাতে বলুন। অথবা https://atlas.ripe.net-এ বিনামূল্যের RIPE Atlas measurement network ব্যবহার করুন। এই network-এর Canadian city-গুলোতে probe আছে এবং সেগুলো থেকে ping চালানো যায়।

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

শেষের দুইটি line পড়ুন।

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, অর্থাৎ packet-গুলোর মধ্যে ব্যবধানের পরিবর্তন। ছোট path-এ যেকোনো packet loss এমন একটি fault, যা অনুসন্ধান করা উচিত। গড় latency সামান্য বেশি হওয়ার চেয়ে high jitter voice ও game-এর ক্ষতি বেশি করে, কারণ receiver-কে সাধারণ packet-এর জন্য নয়, সবচেয়ে দেরিতে আসা packet-এর জন্য buffer করতে হয়।

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

mtr প্রতিটি hop-এর loss দেখায়। এটি permission error দিয়ে শেষ হলে sudo দিয়ে চালান। মাঝের hop-গুলোতে প্রায়ই এমন loss দেখা যায়, যা প্রকৃত loss নয়, কারণ router নিজে তৈরি করা ICMP reply-কে সর্বনিম্ন priority দেয়। শুধু final line পর্যন্ত অব্যাহত থাকা loss-ই আপনার traffic-এ প্রভাব ফেলে। প্রথমে নিচের 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 শুরুর সময় থেকে জমা হওয়া seconds। connect থেকে dns বাদ দিলে একটি TCP round trip পাওয়া যায়। tls থেকে connect বাদ দিলে handshake-এর সময় পাওয়া যায়। ttfb থেকে tls বাদ দিলে আরও একটি round trip এবং application-এর উত্তর দিতে যত সময় লেগেছে, তা পাওয়া যায়। অধিকাংশ slow site মূলত এই শেষ ব্যবধানেই সময় হারায়। ছোট path-এ ttfb যদি 0.8 s হয়, তবে এটি application-এর সমস্যা। Server অন্য city-তে সরালে এর সমাধান হবে না।

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 stream খোলে। আটটি stream একটি stream-এর চেয়ে অনেক দ্রুত হলে, সীমাটি link নিজে নয়; দীর্ঘ path-এ TCP window-ই সীমা তৈরি করছে। কারণ একটি stream প্রতি round trip-এ কেবল একটি window বহন করতে পারে। Vancouver path-এ একই window New York path-এর তুলনায় প্রতি second-এ প্রায় এক-তৃতীয়াংশ data বহন করে। Long-haul backup-ও একইভাবে কাজ করে। তাই fast line থাকলেও distant target-এর বিরুদ্ধে restic দিয়ে off-site backup ধীর মনে হয়।

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-এ যায় এবং সাধারণত cached থাকে। তাই warm visit-এ এটি বাদ যায়। End to end হিসাব করলে, একটি cold load New York path-এ 72 ms এবং Vancouver path-এ 248 ms পিছিয়ে শুরু হয়। একটি 400 ms database query-এর তুলনায় New York-এর মানটি ছোট। Vancouver-এর মানটি ছোট নয়: এটি ওই query-এর অর্ধেকের বেশি, এবং cold visitor সত্যিই এই latency বহন করে। Connection খোলা হলে HTTP/2 এবং HTTP/3 একই connection-এর ওপর একসঙ্গে অনেক request বহন করে। তাই প্রতি file-এর জন্য নয়, এই খরচ একবারই দিতে হয়। Static asset একটি CDN (content delivery network)-এ রাখলে সেগুলোর ক্ষেত্রে origin-এর শহর আর গুরুত্বপূর্ণ থাকে না। এ কারণেই Toronto-তে 98 ms latency-র মুখোমুখি হওয়া European visitor-ও একটি fast page পেতে পারে।

Real-time multiplayer game এর বিপরীত উদাহরণ। এখানে round trip-ই experience। Fast action game-এ roughly 50 ms-এর নিচে তা তাৎক্ষণিক মনে হয়, প্রায় 80 ms-এ player তা লক্ষ্য করতে শুরু করে, এবং 120 ms পেরোলে server-কে দোষ দেয়। এখানে region সত্যিই product ভালো কি না তা নির্ধারণ করে। ধীরগতির server অনেক বেশি সহনশীল। তাই VPS-এ Minecraft server চালানো এমন দূরত্বও সামলাতে পারে, যা shooter game নষ্ট করে দিত।

Database-এর ক্ষেত্রে region বেছে নেওয়ার ভুলে প্রকৃত ক্ষতি হয়। Application একটি region-এ এবং database অন্য region-এ কখনও রাখবেন না। প্রতিটি query একটি round trip। 40টি query পাঠানো একটি page-এ 40টি round trip-এর খরচ হয়: প্রতিটির latency 18 ms হলে তা এক second-এর বেশিরভাগ সময়, আর প্রতিটির latency 62 ms হলে তা দুই second-এর বেশি; অথচ একই box-এ database থাকলে profiling-এ page-টির সময় ছিল 30 ms। অন্য region-এ asynchronous replication read replica এবং disaster recovery-এর জন্য উপযোগী। দীর্ঘ path জুড়ে synchronous commit করলে প্রতিটি write-এর সঙ্গে সেই path-এর latency যুক্ত হয়।

Interactive session মাঝামাঝি অবস্থানে থাকে। SSH প্রায় 100 ms পর্যন্ত স্বাচ্ছন্দ্যদায়ক থাকে এবং এর ওপরে laggy মনে হয়, কারণ প্রতিটি keystroke-এর echo ফিরে আসা পর্যন্ত অপেক্ষা করতে হয়। mosh locally পূর্বাভাস দেয় এবং এর বেশিরভাগ প্রভাব আড়াল করে। Webhook এবং internal API সবসময় যে service-কে call করে, তার একই region-এ থাকা উচিত।

বিলিং, মুদ্রা ও কর

Canadian dollar-এ অর্থ পরিশোধ করলে আপনার card issuer-এর নেওয়া foreign transaction fee এড়ানো যায়। August 2026 অনুযায়ী এই ফি সাধারণত প্রায় 2.5%। একই সঙ্গে আপনার হিসাব একটিমাত্র মুদ্রায় রাখা যায়। Canadian provider GST বা HST-সহ invoice দেয়। নিবন্ধিত business এই অর্থ input tax credit হিসেবে ফেরত দাবি করতে পারে। এটি finance-সংক্রান্ত প্রশ্ন, তাই এর উত্তরও finance-সংক্রান্ত। কোন network packet কোন পথে যাবে, এই সিদ্ধান্ত কখনো এর ওপর নির্ভর করা উচিত নয়। একটি server-এর প্রকৃত খরচ কত এবং renewal pricing-এর কারণে অতিরিক্ত খরচে না পড়ে plan কীভাবে তুলনা করবেন, তা জানতে পড়ুন একটি VPS-এর প্রকৃত মাসিক খরচ কত।

ছোট বাজারের খরচ

যুক্তরাষ্ট্রের তুলনায় Canada একটি ছোট hosting market। তাই সৎ পরামর্শের অংশ হিসেবে আপনাকে কী ছাড়তে হবে, সেটিও বিবেচনা করতে হবে।

• আপনার অর্থের জন্য প্রতিদ্বন্দ্বিতা করা provider-এর সংখ্যা কম। তাই একই শ্রেণির machine-এর ক্ষেত্রে RAM বা disk-এর প্রতি gigabyte-এর দাম সাধারণত বেশি হয়।
• Capacity মূলত Toronto ও Montreal-এ কেন্দ্রীভূত। Vancouver ও Calgary-তে capacity কম। Failover-এর জন্য দ্বিতীয় Canadian region নিতে গেলে প্রায়ই দীর্ঘ network path ব্যবহার করতে হয়, অথবা শেষ পর্যন্ত দেশ ছাড়তে হয়।
• একটি ছোট regional host এক বা দুইটি upstream carrier-এর মাধ্যমে একটি building চালাতে পারে। কতটি carrier আছে, তা জিজ্ঞাসা করুন। তাদের একটি ব্যর্থ হলে কী ঘটে, সেটিও জিজ্ঞাসা করুন।
• Hardware menu সীমিত। US region-এ বড় instance ও GPU machine সহজে পাওয়া যায়। তাই আপনার পছন্দের শহরে আপনার প্রয়োজনীয় আকারের GPU VPS নাও থাকতে পারে।
• ছোট host-এর support coverage বাস্তবেই যাচাই করার বিষয়। এটি marketing-এর প্রশ্ন নয়। কখন কোনো মানুষ support দিচ্ছেন, তা জিজ্ঞাসা করুন।

দামের ক্ষেত্রে Montreal ব্যতিক্রম। Quebec-এর hydroelectric power সস্তা। শীতকালে cooling cost-ও কম থাকে। তাই Montreal area-তে প্রচুর capacity এমন দামে পাওয়া যায়, যা US region-এর দামের সঙ্গে প্রতিযোগিতা করতে পারে। আপনার requirement যদি Canada হয়, নির্দিষ্ট কোনো city না হয়, তাহলে সেখানে শুরু করুন।

Canadian VPS tier-গুলো workload-এর জন্য খুব ছোট মনে হলে, দেশটিকেই সমস্যার কারণ মনে করার আগে একটি VPS ও dedicated server-এর তুলনা করুন।

কানাডায় VPS hosting বেছে নেওয়া কখন সঠিক সিদ্ধান্ত

1. কোনো আইন, চুক্তি বা সরকারি খাতের নীতিতে কানাডার নাম উল্লেখ থাকলে কানাডায় host করুন। এই পোস্টের অন্য কোনো বিষয় তখন প্রযোজ্য নয়। Provider-এর কাছ থেকে residency commitment লিখিতভাবেও নিন।
2. আপনার ব্যবহারকারীরা কানাডার একটি metropolitan এলাকায় অবস্থান করেন এবং workload latency-এর ওপর নির্ভরশীল হলে—যেমন multiplayer games, voice, remote desktops বা trading—নিকটতম শহরে host করুন। কোনো চুক্তি স্বাক্ষর করার আগে দুটি option-এর latency মেপে দেখুন।
3. আপনার ব্যবহারকারীরা সারা দেশে ছড়িয়ে থাকলে Toronto বা Montreal জনসংখ্যার সবচেয়ে বড় অংশকে কভার করে। Static asset-এর সামনে একটি CDN ব্যবহার করলে Vancouver-এর কোনো visitor-এর জন্য origin সরানোর চেয়ে বেশি সুবিধা পাওয়া যায়।
4. বাকি সব ক্ষেত্রে, যা অধিকাংশ ক্ষেত্রেই প্রযোজ্য, মূল্য এবং বাস্তবে পাওয়া hardware-এর ভিত্তিতে বেছে নিন। এরপর রাত 2am-এ support কেমন পাওয়া যায় তা পরীক্ষা করুন। প্রার্থী option আগে benchmark করুন, কারণ একই specification sheet থাকা দুটি plan একই performance দেয় না: VPS সঠিকভাবে benchmark করার পদ্ধতি।

আপনি যে সিদ্ধান্তই নিন, সিদ্ধান্তটির পাশে কারণটি লিখে রাখুন। পরের যে ব্যক্তি জানতে চাইবেন এটি কানাডায় থাকা উচিত কি না, তিনি অনুমানের চেয়ে ভালো তথ্য পাওয়ার অধিকারী। আর কারণটি যদি কখনও contract clause হয়ে থাকে, তাহলে পরে কাউকে সেটি আবার খুঁজে বের করতে হবে। Server চালু হয়ে গেলে, নতুন VPS-এ প্রথম দশ মিনিট তার শহরের চেয়ে আপনার security-এর জন্য বেশি গুরুত্বপূর্ণ হবে।

FAQ

PIPEDA কি আমার ডেটা কানাডায় রাখার বাধ্যবাধকতা তৈরি করে?

না। PIPEDA (Personal Information Protection and Electronic Documents Act)-তে private sector-এর জন্য data residency সংক্রান্ত কোনো rule নেই। অন্য দেশের কোনো processor-এর কাছে personal information পাঠানো processing-এর জন্য transfer হিসেবে গণ্য হয়। আপনার organisation ডেটার জন্য দায়বদ্ধ থাকে, processor-কে তুলনীয় সুরক্ষা দিতে হয়, এবং এই স্থানান্তর ঘটে—তা মানুষকে স্পষ্টভাবে জানাতে হয়। Office of the Privacy Commissioner 2019 সালে এই অবস্থান পরিবর্তনের বিষয়ে পরামর্শ নিয়েছিল, কিন্তু পরে সেটিই বহাল রাখে। Residency requirement অন্য উৎস থেকে আসতে পারে, যেমন Quebec-এর Law 25 assessment, Nova Scotia-এর PIIDPA-এর মতো public-sector act, Government of Canada-এর cloud direction, অথবা আপনার নিজের customer contract-এর কোনো clause।

কানাডীয় ব্যবহারকারীরা কি United States-এ থাকা server টের পাবেন?

সাধারণ web application-এর ক্ষেত্রে না। Toronto থেকে New York পর্যন্ত একটি round trip প্রায় 18 ms এবং Northern Virginia পর্যন্ত প্রায় 26 ms, যা Toronto থেকে Vancouver-এর 62 ms-এর চেয়ে দুটিই কম। ব্যবহারকারীরা network-এর 20 ms latency টের পাওয়ার অনেক আগেই server response time এবং page weight টের পান। তবে real-time game, voice call এবং এমন যেকোনো ক্ষেত্রে তারা এটি টের পান যেখানে একজন ব্যক্তি অন্য ব্যক্তির প্রতিক্রিয়ার সঙ্গে সঙ্গে প্রতিক্রিয়া জানাচ্ছেন।

কানাডীয় data centre কি US law-এর আওতার বাইরে?

স্বয়ংক্রিয়ভাবে নয়। Server যেখানেই থাকুক, US CLOUD Act কোনো US provider-এর possession, custody বা control-এ থাকা ডেটার ক্ষেত্রে প্রযোজ্য। তাই কোনো American company পরিচালিত Canadian region-ও এর আওতায় থাকে। আপনার প্রকৃত উদ্বেগ যদি foreign legal process হয়, তাহলে building-এর ঠিকানার বদলে কে service পরিচালনা করে এবং encryption key কার নিয়ন্ত্রণে থাকে, তা দেখুন। আপনার নিজের নিয়ন্ত্রণে থাকা key দিয়ে encryption করলে provider কী হস্তান্তর করতে সক্ষম, তা পরিবর্তিত হয়।

আমি যেখানে থাকি না, এমন কোনো শহর থেকে latency কীভাবে মাপব?

সেই শহরে ঘণ্টাভিত্তিক VPS ভাড়া নিন, নিজের server-এ ফিরে ping -c 20 এবং mtr --report --report-cycles 50 চালান, তারপর VPS-টি ধ্বংস করুন। কানাডীয় শহরগুলোতে probe থাকা RIPE Atlas network একটি বিনামূল্যের বিকল্প। ICMP blocked থাকলে পরিবর্তে curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ দিয়ে প্রকৃত request-এর সময় মাপুন। এটি TCP round trip এবং first byte পাওয়া পর্যন্ত মোট সময় দেখায়।