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

আপনার VPS কি কানাডায় থাকা প্রয়োজন?

কোনও আইন বা চুক্তিতে ডেটা কানাডার ভূখণ্ডে রাখার শর্ত থাকলে কানাডায় VPS হোস্টিং বেছে নেওয়া যুক্তিযুক্ত। এটিই একমাত্র বাধ্যতামূলক কারণ। Toronto-এর কোনও বাসার সংযোগ থেকে New York-এর ডেটা সেন্টারে রাউন্ড-ট্রিপ সময় প্রায় 18 ms, আর Toronto-এর ডেটা সেন্টারে প্রায় 3 ms। প্রায় কোনও web application এই পার্থক্য শনাক্ত করতে পারে না।

তিনটি কারণে মানুষ কানাডার server বেছে নেন। Data residency আইনগত বাধ্যবাধকতা হলে সেটিই একাই সিদ্ধান্ত নির্ধারণ করে। Latency পরিমাপযোগ্য, এবং সাধারণত মানুষের প্রত্যাশার চেয়ে কম। Canadian dollar-এ billing করা আপনার হিসাবরক্ষকের জন্য সুবিধাজনক। অন্য কিছু বিবেচনা করার আগে প্রথম কারণটি আপনার ক্ষেত্রে প্রযোজ্য কি না নির্ধারণ করুন।

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

ডেটা অবস্থান: একমাত্র কঠোর শর্ত

PIPEDA (Personal Information Protection and Electronic Documents Act) হলো কানাডার ফেডারেল বেসরকারি খাতের গোপনীয়তা আইন। এই আইন অনুযায়ী ব্যক্তিগত তথ্য কানাডায় থাকতেই হবে—এমন কোনো বাধ্যবাধকতা নেই। বিদেশের কোনো processor-এর কাছে ডেটা পাঠানোকে এটি processing-এর জন্য transfer হিসেবে বিবেচনা করে। ডেটার জন্য দায়বদ্ধতা আপনার organisation-এর কাছেই থাকে। Processor-কে ডেটার জন্য তুলনীয় সুরক্ষা দিতে হয়। এই transfer ঘটছে—এ বিষয়েও আপনাকে ব্যক্তিদের স্বচ্ছভাবে জানাতে হয়। Office of the Privacy Commissioner 2019 সালে এই নিয়ম কঠোর করার বিষয়ে পরামর্শ নিয়েছিল। পরে তারা তাদের বিদ্যমান অবস্থানই বজায় রাখে। তাই PIPEDA অনুযায়ী আপনার ডেটা কানাডায় থাকতেই হবে—এই প্রচলিত দাবি ভুল, যদিও অনেক hosting-এর প্রচারমূলক লেখায় তা বারবার বলা হয়।

বাস্তব অবস্থান-সংক্রান্ত নিয়ম অবশ্যই আছে। তবে সেগুলো আরও নির্দিষ্ট ক্ষেত্রে প্রযোজ্য।

• Quebec-এর Law 25 অনুযায়ী ব্যক্তিগত তথ্য province-এর বাইরে পাঠানোর আগে assessment করতে হয়। তথ্য যেখানে পাঠানো হবে, সেখানে পর্যাপ্ত সুরক্ষা পেতে হবে। এই বিধান September 2023 থেকে কার্যকর। এটি paperwork এবং এমন একটি সিদ্ধান্ত, যার পক্ষে আপনাকে যুক্তি দিতে সক্ষম হতে হবে; এটি কোনো নিষেধাজ্ঞা নয়।
• Public-sector-এর নিয়ম public bodies এবং তাদের সেবা প্রদানকারী companies-এর ওপর বাধ্যতামূলক। Nova Scotia-এর PIIDPA কানাডার বাইরে ব্যক্তিগত তথ্য সংরক্ষণ সীমাবদ্ধ করে। British Columbia-এর FIPPA-তেও অনুরূপ নিয়ম ছিল। 2021 সালে amendment-এর মাধ্যমে assessment-এর পর বিদেশে storage-এর অনুমতি দেওয়া হয়।
• Federal government-এর কাজ Government of Canada's cloud direction অনুসরণ করে। এই direction অনুযায়ী Protected B এবং তার চেয়ে উচ্চ স্তরের ডেটা কানাডায় থাকতে হবে।
• Provincial health privacy laws স্বাস্থ্য রেকর্ড কোথায় সংরক্ষণ করা যাবে, সে বিষয়ে নিজস্ব শর্ত যোগ করে। এসব শর্ত 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 কার নিয়ন্ত্রণে থাকে। ভবনের ঠিকানা Canadian হলেই এর উত্তর মেলে না।

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

traceroute vps.example.com

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

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

ফাইবারে আলো প্রতি মিলিসেকেন্ডে প্রায় 200 km অতিক্রম করে। তাই কোনো সরঞ্জাম যুক্ত হওয়ার আগেই দূরত্বের প্রতি 100 km রাউন্ড-ট্রিপে প্রায় 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, যা 26 ms দূরের Northern Virginia-এর তুলনায় বেশি। Canada-তে থাকা মানেই আপনার users-এর কাছাকাছি থাকা নয়।

যাই হোক, সাধারণত last mile-ই প্রধান প্রভাব ফেলে। Home fibre কয়েক মিলিসেকেন্ড যোগ করে। লাইন ব্যস্ত থাকলে cable আরও বেশি বিলম্ব যোগ করে। Mobile connection নিজেই কয়েক দশক মিলিসেকেন্ড যোগ করে। Toronto-র কোনো phone user Toronto server-এ 50 ms দেখতে পারেন। সেই server New York-এ সরালে তাঁর অভিজ্ঞতা কয়েক শতাংশ পরিবর্তিত হয়।

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

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

এরপর সেখান থেকেই মাপুন। Ottawa-র একটি desk থেকে Vancouver-এর latency পরীক্ষা করা যায় না। লক্ষ্য city-তে প্রতি ঘণ্টাভিত্তিক একটি 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। সামান্য বেশি average-এর তুলনায় বেশি jitter voice call এবং game-এ বেশি সমস্যা তৈরি করে। কারণ receiver-কে সাধারণ packet-এর পরিবর্তে সবচেয়ে দেরিতে আসা packet অনুযায়ী buffer করতে হয়।

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

mtr প্রতিটি hop-এর জন্য loss দেখায়। permission error দিয়ে এটি বন্ধ হলে sudo দিয়ে চালান। মাঝের hop-গুলোতে প্রায়ই এমন loss দেখা যায় যা বাস্তব নয়। কারণ router নিজে তৈরি করা ICMP reply-কে সর্বনিম্ন 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-এর reply দিতে যত সময় লেগেছে, তা পাওয়া যায়। বেশিরভাগ ধীর site আসলে এই শেষ ব্যবধানেই সময় হারায়। একটি ছোট path-এ ttfb যদি 0.8 s হয়, তবে এটি application-এর সমস্যা। server-কে অন্য city-তে সরালে এর সমাধান হবে না।

throughput মাপতে VPS-এ server এবং ব্যবহারকারীর দিক থেকে client চালান। iperf3 TCP 5201 port-এ 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 দিক উল্টে দেয়। ফলে upload-এর পাশাপাশি download-ও মাপতে পারেন। -P 8 আটটি parallel stream খোলে। আটটি stream যদি একটি stream-এর তুলনায় অনেক দ্রুত হয়, তবে সীমাবদ্ধতা link-এ নয়, দীর্ঘ path-এ TCP window-তে। কারণ একটি stream প্রতি round trip-এ কেবল একটি window বহন করতে পারে। Vancouver path-এ একই window New York path-এর তুলনায় প্রতি second-এ প্রায় এক-তৃতীয়াংশ data বহন করে। দীর্ঘ দূরত্বের backup-ও একইভাবে প্রভাবিত হয়। তাই দ্রুত line থাকা সত্ত্বেও দূরের target-এ restic দিয়ে off-site backup ধীর মনে হয়।

iperf3 চলার সময় দ্বিতীয় terminal-এ ping চালু রাখুন। Transfer চলাকালে round trip যদি 20 ms থেকে 300 ms-এ বেড়ে যায়, তবে আপনার নিজস্ব access equipment-এ bufferbloat রয়েছে। কোনো data centre-এর অবস্থান পরিবর্তন করলে এর সমাধান হবে না।

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

Real-time multiplayer game বিপরীত উদাহরণ। কারণ round trip-ই সেখানে ব্যবহারকারীর অভিজ্ঞতার অংশ। দ্রুতগতির action game-এ প্রায় 50 ms-এর নিচের latency তাৎক্ষণিক মনে হয়। প্রায় 80 ms থেকে players তা বুঝতে শুরু করে। 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 লাগে। প্রতিটির সময় 18 ms হলে মোট সময় প্রায় এক সেকেন্ডের কাছাকাছি হয়। প্রতিটির সময় 62 ms হলে সময় দুই সেকেন্ডের বেশি হয়। অথচ একই box-এ database থাকলে profiling-এ page-টির সময় ছিল 30 ms। অন্য region-এ asynchronous replication read replica এবং disaster recovery-এর জন্য উপযুক্ত। দীর্ঘ network path জুড়ে synchronous commit করলে প্রতিটি write-এর সঙ্গে সেই path-এর latency যোগ হয়।

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

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

কানাডীয় ডলারে অর্থ পরিশোধ করলে আপনার কার্ড প্রদানকারী যে বৈদেশিক লেনদেনের ফি নেয়, তা এড়ানো যায়। August 2026 অনুযায়ী এই ফি সাধারণত 2.5%। এতে আপনার হিসাবও একটিমাত্র মুদ্রায় থাকে। কানাডীয় কোনো provider GST বা HST-সহ invoice দেয়। নিবন্ধিত ব্যবসা এটিকে input tax credit হিসেবে ফেরত দাবি করতে পারে। এটি অর্থসংক্রান্ত প্রশ্ন, তাই এর উত্তরও অর্থসংক্রান্ত। কোন পথে packets যাবে, এই সিদ্ধান্ত কখনোই এর ওপর নির্ভর করা উচিত নয়। একটি server-এর প্রকৃত খরচ এবং renewal pricing-এর ফাঁদে না পড়ে plan তুলনা করার পদ্ধতি জানতে প্রতি মাসে একটি VPS-এর প্রকৃত খরচ পড়ুন।

একটি ছোট বাজারে আপনার খরচ

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

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

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

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

কানাডায় VPS hosting বেছে নেওয়া কখন যুক্তিযুক্ত

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

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

FAQ

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

না। PIPEDA (Personal Information Protection and Electronic Documents Act)-তে private sector-এর জন্য data residency-এর কোনো নিয়ম নেই। অন্য কোনো দেশে থাকা processor-এর কাছে personal information পাঠানো processing-এর উদ্দেশ্যে transfer হিসেবে গণ্য হয়। আপনার organisation ডেটার জন্য দায়বদ্ধ থাকে। Processor-কে তুলনীয় নিরাপত্তায় ডেটা সুরক্ষিত রাখতে হয়। এই প্রক্রিয়া ঘটবে—এ কথা আপনাকে মানুষকে স্পষ্টভাবে জানাতে হয়। Office of the Privacy Commissioner 2019 সালে এই অবস্থান পরিবর্তনের বিষয়ে পরামর্শ নিয়েছিল, কিন্তু পরে একই অবস্থান বজায় রাখে। Residency-এর শর্ত অন্য উৎস থেকে আসতে পারে: Quebec's Law 25 assessment, Nova Scotia's PIIDPA-এর মতো public-sector আইন, Government of Canada-এর cloud নির্দেশনা, অথবা আপনার নিজস্ব 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 আইনের আওতার বাইরে?

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

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

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