কানাডায় 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) কানাডার ফেডারেল বেসরকারি খাতের গোপনীয়তা আইন। এই আইন ব্যক্তিগত তথ্য কানাডার সীমানার মধ্যে রাখার বাধ্যবাধকতা দেয় না। বিদেশে কোনো processor-এর কাছে ডেটা পাঠানোকে এটি processing-এর জন্য transfer হিসেবে বিবেচনা করে। ডেটার জন্য দায়বদ্ধতা আপনার organisation-এর কাছেই থাকে। processor-কে তুলনীয় সুরক্ষা দিতে হয়। এই স্থানান্তর ঘটছে—এ বিষয়েও আপনাকে ব্যক্তিদের স্পষ্টভাবে জানাতে হয়। Office of the Privacy Commissioner 2019 সালে এই নিয়ম কঠোর করার বিষয়ে পরামর্শ নিয়েছিল। পরে তারা আগের অবস্থানই বজায় রাখে। তাই PIPEDA অনুযায়ী আপনার ডেটা অবশ্যই কানাডায় থাকতে হবে—এই প্রচলিত দাবি ভুল, যদিও অনেক hosting প্রচারসামগ্রীতে তা বারবার বলা হয়।

বাস্তব data residency-এর নিয়ম আছে। এগুলো আরও নির্দিষ্ট কিছু ক্ষেত্রে প্রযোজ্য।

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

ফাইবারে আলো প্রতি মিলিসেকেন্ডে প্রায় 200 km অতিক্রম করে। তাই কোনো equipment যুক্ত হওয়ার আগেই প্রতি 100 km দূরত্বে round trip-এ আনুমানিক 1 ms যোগ হয়। Toronto থেকে Vancouver-এর সরলরেখার দূরত্ব প্রায় 3,400 km এবং cable route আরও দীর্ঘ। ফলে সর্বনিম্ন latency প্রায় 40 ms-এর কাছাকাছি হয়। বাস্তব network path-এ 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-এ ভালোভাবে সংযুক্ত consumer line-এর জন্য এগুলো সাধারণত প্রকাশিত পরিসংখ্যান। এগুলো একটি প্রাথমিক ধারণা, নিশ্চয়তা নয়। আপনার প্রকৃত সংখ্যা access network এবং provider-এর peering-এর ওপর নির্ভর করে। দিনের সময়ের সঙ্গেও এগুলো পরিবর্তিত হয়।

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

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

আপনার ব্যবহারকারীরা যেখান থেকে সংযোগ করেন, সেখান থেকে 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-এ উদ্ধৃত করাই বেশি সুবিধাজনক।

আপনার কাজের ক্ষেত্রে 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 path-এ শুরুতেই 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-এর নিচে প্রতিক্রিয়া তাৎক্ষণিক মনে হয়। প্রায় 80 ms-এ খেলোয়াড়েরা বিলম্ব বুঝতে শুরু করেন। 120 ms পেরোলে তারা server-কে দোষ দেন। এখানে region সত্যিই product-এর মান নির্ধারণ করে। ধীরগতির game server অনেক বেশি সহনশীল। তাই VPS-এ Minecraft server চালানো এমন দূরত্বও সামলাতে পারে, যা shooter game নষ্ট করে দিত।

Database-এর ক্ষেত্রে region বেছে নেওয়ার ভুলে সবচেয়ে বেশি ক্ষতি হয়। Application-কে এক region-এ এবং database-কে অন্য region-এ রাখবেন না। প্রতিটি query একটি round trip। কোনো page-এ 40টি query থাকলে 40টি round trip-এর খরচ দিতে হয়। প্রতিটিতে 18 ms লাগলে মোট সময় প্রায় এক সেকেন্ডের কাছাকাছি হয়। প্রতিটিতে 62 ms লাগলে সময় দুই সেকেন্ডের বেশি হয়। অথচ একই machine-এ 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 locally prediction করে এবং এই বিলম্বের বেশিরভাগ আড়াল করে। 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 পাওয়া পর্যন্ত মোট সময় দেখায়।