VPS ในแคนาดาจำเป็นหรือไม่ ตรวจ PIPEDA และ Latency

VPS ของคุณจำเป็นต้องอยู่ในแคนาดาหรือไม่?

การเลือก VPS hosting ในแคนาดามีความเหมาะสมเมื่อกฎหมายหรือสัญญากำหนดให้ข้อมูลต้องจัดเก็บอยู่ในแคนาดา นี่คือเหตุผลสำคัญเพียงข้อเดียว เวลาไปกลับจากการเชื่อมต่อภายในบ้านใน Toronto ไปยังศูนย์ข้อมูลใน New York อยู่ที่ประมาณ 18 ms เทียบกับประมาณ 3 ms ไปยังศูนย์ข้อมูลใน Toronto และแทบไม่มี web application ใดแยกความแตกต่างนี้ได้

มี 3 ปัจจัยที่ทำให้ผู้ใช้เลือก server ในแคนาดา การจัดเก็บข้อมูลภายในประเทศเป็นข้อผูกพันทางกฎหมาย จึงเพียงพอที่จะตัดสินใจได้ด้วยตัวเอง Latency สามารถวัดได้ และโดยทั่วไปมีค่าน้อยกว่าที่หลายคนคาดไว้ การเรียกเก็บเงินเป็นดอลลาร์แคนาดาช่วยให้ฝ่ายบัญชีดำเนินการได้สะดวก ควรตรวจสอบก่อนว่าปัจจัยข้อแรกมีผลกับคุณหรือไม่ ก่อนพิจารณาปัจจัยอื่น

บทความนี้อธิบายหลักการทำงานของกฎเกณฑ์โดยทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากกฎหมายคุ้มครองความเป็นส่วนตัวมีผลผูกพันองค์กรของคุณ ควรขอคำตอบจากที่ปรึกษากฎหมายขององค์กร

ถิ่นที่อยู่ของข้อมูล: ข้อกำหนดที่เข้มงวดเพียงข้อเดียว

PIPEDA (Personal Information Protection and Electronic Documents Act) เป็นกฎหมายคุ้มครองความเป็นส่วนตัวของภาคเอกชนระดับสหพันธรัฐของแคนาดา และไม่ได้กำหนดให้ข้อมูลส่วนบุคคลต้องอยู่ภายในประเทศ กฎหมายถือว่าการส่งข้อมูลไปยังผู้ประมวลผลในต่างประเทศเป็นการโอนข้อมูลเพื่อประมวลผล องค์กรของคุณยังคงต้องรับผิดชอบต่อข้อมูล ผู้ประมวลผลต้องให้การคุ้มครองในระดับเทียบเท่า และคุณต้องแจ้งให้บุคคลที่เกี่ยวข้องทราบอย่างเปิดเผยว่ามีการดำเนินการดังกล่าว Office of the Privacy Commissioner ได้หารือเกี่ยวกับการทำให้ข้อกำหนดนี้เข้มงวดขึ้นในปี 2019 และยังคงจุดยืนเดิม ดังนั้น ข้อกล่าวอ้างทั่วไปที่ว่า PIPEDA กำหนดให้ข้อมูลของคุณต้องอยู่ในแคนาดาจึงไม่ถูกต้อง แม้ข้อความโฆษณาบริการโฮสติ้งจำนวนมากจะกล่าวซ้ำเช่นนั้น

ข้อกำหนดด้านถิ่นที่อยู่ของข้อมูลมีอยู่จริง แต่ใช้ในขอบเขตที่จำกัดกว่า

• Law 25 ของ Quebec กำหนดให้ต้องประเมินก่อนส่งข้อมูลส่วนบุคคลออกนอกจังหวัด และข้อมูลต้องได้รับการคุ้มครองอย่างเพียงพอในสถานที่ปลายทาง ข้อกำหนดนี้มีผลบังคับใช้ตั้งแต่ September 2023 นี่เป็นกระบวนการด้านเอกสารและการตัดสินใจที่คุณต้องสามารถชี้แจงเหตุผลได้ ไม่ใช่การห้าม
• ข้อกำหนดสำหรับภาครัฐมีผลผูกพันหน่วยงานของรัฐและบริษัทที่ให้บริการแก่หน่วยงานเหล่านั้น PIIDPA ของ Nova Scotia จำกัดการจัดเก็บข้อมูลส่วนบุคคลนอกแคนาดา FIPPA ของ British Columbia เคยมีกฎในลักษณะเดียวกัน จนมีการแก้ไขในปี 2021 เพื่ออนุญาตให้จัดเก็บข้อมูลในต่างประเทศได้หลังจากผ่านการประเมิน
• งานของรัฐบาลกลางต้องปฏิบัติตามแนวทางคลาวด์ของ Government of Canada ซึ่งกำหนดให้ข้อมูลระดับ Protected B และสูงกว่าต้องอยู่ในแคนาดา
• กฎหมายคุ้มครองความเป็นส่วนตัวของข้อมูลสุขภาพระดับจังหวัดกำหนดเงื่อนไขเพิ่มเติมเกี่ยวกับสถานที่จัดเก็บเวชระเบียน และข้อกำหนดแตกต่างกันไปในแต่ละจังหวัด
• ในทางปฏิบัติ สัญญากับลูกค้าและข้อกำหนดในการประมูลภาครัฐเป็นปัจจัยที่พบได้บ่อยที่สุด แบบสอบถามด้านความปลอดภัยที่ระบุว่า "data at rest in Canada" มีผลผูกพันคุณไม่ต่างจากกฎหมาย เพราะคุณเป็นผู้ลงนาม

การตรวจสอบในทางปฏิบัตินั้นทำได้ง่าย คุณสามารถชี้ไปยังข้อกำหนดดังกล่าวได้หรือไม่ หากไม่มีใครในองค์กรของคุณระบุชื่อกฎหมายหรือสัญญาที่กำหนดให้ข้อมูลอยู่ในแคนาดาได้ แสดงว่าคุณกำลังตัดสินใจโดยพิจารณาจาก latency และราคา

ศูนย์ข้อมูลในแคนาดาอยู่นอกขอบเขตอำนาจตามกฎหมายของสหรัฐฯ หรือไม่

ไม่ใช่โดยตัวมันเอง US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) ครอบคลุมข้อมูลที่อยู่ในความครอบครอง การดูแล หรือการควบคุมของผู้ให้บริการในสหรัฐฯ ไม่ว่าฮาร์ดแวร์จะตั้งอยู่ที่ใด ดังนั้น region ใน Toronto ที่ดำเนินงานโดยบริษัทอเมริกันจึงอยู่ภายใต้ขอบเขตอำนาจของกฎหมายนี้ หากข้อกำหนดที่แท้จริงเกี่ยวข้องกับกระบวนการทางกฎหมายของต่างประเทศ ไม่ใช่ที่ตั้งทางภูมิศาสตร์ สิ่งสำคัญคือผู้ใดดำเนินงานบริการ และผู้ใดถือ encryption keys ที่อยู่ในแคนาดาบนอาคารไม่ได้ตอบคำถามนี้โดยตัวมันเอง

การกำหนดเส้นทางเป็นประเด็นที่สร้างความประหลาดใจประการที่สอง Traffic ระหว่างเมือง 2 แห่งในแคนาดามักผ่านสหรัฐฯ เนื่องจากในอดีตมีการเชื่อมต่อ peering ที่มีต้นทุนต่ำอยู่ที่นั่น นักวิจัยเรียกการกำหนดเส้นทางลักษณะนี้ว่า boomerang routing ให้เรียกใช้ traceroute ก่อนแจ้งแก่ผู้อื่นว่า packets ของคุณไม่เคยออกนอกประเทศ

traceroute vps.example.com

ชื่อ hop มีรหัสเมือง เช่น nyc, chi หรือ ash ชื่อเหล่านี้เป็นเพียงข้อบ่งชี้และอาจล้าสมัยได้ ดังนั้นให้ใช้เป็นเหตุผลในการสอบถาม provider ไม่ใช่ใช้เป็นหลักฐาน สำหรับข้อมูลระหว่างการส่ง คำตอบที่เชื่อถือได้คือการใช้ encryption ที่คุณควบคุม ไม่ใช่แผนที่ หากต้องการเส้นทางส่วนตัวระหว่างเครื่องของคุณเอง VPN WireGuard ที่โฮสต์ด้วยตนเอง จะจัดเตรียมเส้นทางดังกล่าวให้ โดยไม่ขึ้นกับว่า fibre วิ่งผ่านประเทศใด

เวลาแฝง: ต้องวัด ไม่ควรคาดเดา

สัญญาณแสงในสายไฟเบอร์เดินทางได้ประมาณ 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 ที่เชื่อมต่อกับเครือข่ายอื่นได้ดี ตัวเลขเหล่านี้ใช้เป็นจุดเริ่มต้น ไม่ใช่ค่าที่รับประกัน ค่าของคุณเองขึ้นอยู่กับเครือข่ายการเข้าถึงและการเชื่อมต่อระหว่างเครือข่ายของผู้ให้บริการ และเปลี่ยนแปลงตามช่วงเวลาของวัน

มีข้อมูล 2 แถวที่ควรอ่านอย่างละเอียด Toronto ถึง Montreal มีค่าประมาณ 12 ms ซึ่งใกล้กันมากจนโดยทั่วไปทั้งสองเมืองทำงานเสมือนเป็นภูมิภาคเดียวกัน Toronto ถึง Vancouver มีค่าประมาณ 62 ms ซึ่งไกลกว่า Toronto ถึง Northern Virginia ที่มีค่า 26 ms การอยู่ใน Canada ไม่ได้หมายความว่าจะอยู่ใกล้ผู้ใช้ของคุณ

ช่วงเชื่อมต่อระยะสุดท้ายมักเป็นปัจจัยหลักอยู่ดี การเชื่อมต่อไฟเบอร์ในบ้านเพิ่มเวลาอีกไม่กี่มิลลิวินาที การเชื่อมต่อผ่านสายเคเบิลเพิ่มเวลามากขึ้นเมื่อเครือข่ายมีการใช้งานสูง การเชื่อมต่อผ่านเครือข่ายมือถือเพิ่มเวลาเองอีกหลายสิบมิลลิวินาที ผู้ใช้โทรศัพท์ใน Toronto อาจเห็นค่า 50 ms เมื่อเชื่อมต่อไปยังเซิร์ฟเวอร์ใน Toronto และการย้ายเซิร์ฟเวอร์นั้นไปยัง New York อาจเปลี่ยนประสบการณ์ใช้งานได้เพียงไม่กี่เปอร์เซ็นต์

วิธีทดสอบค่า latency จากตำแหน่งของผู้ใช้

ขั้นแรก ให้ตรวจสอบว่าผู้ใช้ของคุณอยู่ที่ใดจริง ๆ ระบบวิเคราะห์ของคุณจะแยก session ตามเมืองหรือภูมิภาคอยู่แล้ว ให้ใช้ข้อมูลนั้นแทนการคาดเดาจากตำแหน่งสำนักงานของคุณ

จากนั้นให้วัดค่าจากตำแหน่งนั้น คุณไม่สามารถทดสอบค่า latency ของ Vancouver จากโต๊ะทำงานใน Ottawa ได้ เช่า VPS แบบคิดค่าบริการรายชั่วโมงในเมืองเป้าหมายเป็นเวลา 20 นาที แล้วทำลาย VPS หลังจากนั้น ขอให้เพื่อนร่วมงานหรือลูกค้าเรียกใช้คำสั่งหนึ่งคำสั่ง หรือใช้เครือข่ายการวัดผล RIPE Atlas ที่ไม่มีค่าใช้จ่ายได้ที่ https://atlas.ripe.net ซึ่งมี probe ในเมืองต่าง ๆ ของแคนาดาและให้คุณเรียกใช้ ping จาก probe เหล่านั้นได้

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

อ่าน 2 บรรทัดสุดท้าย

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 การสูญเสีย packet บนเส้นทางสั้น ๆ เป็นข้อผิดพลาดที่ควรตรวจสอบ การมี jitter สูงส่งผลต่อเสียงและเกมมากกว่าค่าเฉลี่ยที่สูงขึ้นเล็กน้อย เนื่องจากเครื่องรับต้อง buffer ตาม packet ที่ใช้เวลานานที่สุด ไม่ใช่ตาม packet ทั่วไป

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

mtr แสดงการสูญเสียของทุก hop หากคำสั่งจบลงด้วยข้อผิดพลาดด้านสิทธิ์ ให้เรียกใช้พร้อม sudo hop ตรงกลางมักแสดงการสูญเสียที่ไม่ได้เกิดขึ้นจริง เนื่องจาก router จะให้ความสำคัญกับ ICMP reply ที่สร้างขึ้นเองต่ำที่สุด การสูญเสียที่เกิดขึ้นต่อเนื่องจนถึงบรรทัดสุดท้ายเท่านั้น จึงเป็นการสูญเสียที่ network traffic ของคุณได้รับ ให้เริ่มอ่านแถวล่างสุดก่อน แล้วจึงตรวจสอบย้อนขึ้นไป

เมื่อ ICMP ถูกบล็อกหรือถูกจำกัดอัตรา ให้จับเวลาของ 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 connect ลบด้วย dns คือ TCP round trip 1 ครั้ง tls ลบด้วย connect คือ handshake ttfb ลบด้วย tls คือ round trip เพิ่มอีก 1 ครั้ง รวมกับเวลาที่ application ใช้ตอบกลับ ช่องว่างสุดท้ายนั้นเป็นจุดที่เว็บไซต์ช้าส่วนใหญ่สูญเสียเวลา ค่า ttfb ที่ 0.8 s บนเส้นทางสั้น ๆ เป็นปัญหาของ application และการย้าย server ไปยังเมืองอื่นจะไม่ช่วยแก้ปัญหานี้

สำหรับ throughput ให้เรียกใช้ server บน VPS และเรียกใช้ client จากฝั่งผู้ใช้ iperf3 รับฟังบน TCP 5201 ดังนั้น เปิด port ด้วย 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 สลับทิศทาง เพื่อให้คุณวัด download รวมถึง upload ได้ -P 8 เปิด stream แบบขนาน 8 รายการ หาก 8 stream เร็วกว่า 1 stream มาก ข้อจำกัดอยู่ที่ TCP window บนเส้นทางไกล ไม่ใช่ที่ link เอง เนื่องจาก stream เดียวสามารถส่งข้อมูลได้เพียง 1 window ต่อ round trip เท่านั้น window ขนาดเดียวกันบนเส้นทางไป Vancouver จะส่งข้อมูลต่อวินาทีได้ประมาณ 1 ใน 3 ของเส้นทางไป New York การสำรองข้อมูลระยะไกลมีลักษณะเดียวกัน นี่จึงเป็นเหตุผลที่ การสำรองข้อมูลนอกสถานที่ด้วย restic ดูช้าเมื่อใช้กับ target ที่อยู่ไกล แม้จะมี line ความเร็วสูงก็ตาม

ให้เรียกใช้ ping ต่อเนื่องใน terminal อีกหน้าต่างหนึ่งขณะที่ iperf3 ทำงาน หาก round trip เพิ่มจาก 20 ms เป็น 300 ms ระหว่างการถ่ายโอน นั่นคือ bufferbloat ในอุปกรณ์ access ของคุณเอง และการเปลี่ยนตำแหน่ง data centre จะไม่ช่วยแก้ปัญหา

วัดมากกว่า 1 ครั้ง และวัดในช่วงเย็น congestion เวลา 9pm คือค่าที่ผู้ใช้ของคุณต้องเผชิญจริง ส่วนค่าเวลา 4am คือค่าที่หน้า sales อยากนำมาแสดงมากกว่า

เวลาไป-กลับมีความหมายต่องานของคุณอย่างไร

การโหลดหน้าเว็บครั้งแรกใช้เวลาไป-กลับ 4 รอบก่อนที่เบราว์เซอร์จะแสดงผลใด ๆ ได้

[
  {
    "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 ไปยัง resolver ไม่ใช่เซิร์ฟเวอร์ของคุณ และโดยปกติมีการแคชไว้แล้ว ดังนั้นการเข้าชมครั้งต่อไปจึงไม่ต้องทำขั้นตอนนี้ เมื่อวัดตั้งแต่ต้นทางถึงปลายทาง การโหลดครั้งแรกจะช้าลง 72 ms บนเส้นทางไป New York และ 248 ms บนเส้นทางไป Vancouver ทั้งสองค่าน้อยมากเมื่อเทียบกับคำขอฐานข้อมูลเพียงครั้งเดียวที่ใช้เวลา 400 ms เมื่อเปิดการเชื่อมต่อแล้ว HTTP/2 และ HTTP/3 จะส่งคำขอจำนวนมากผ่านการเชื่อมต่อเดียวกันพร้อมกัน จึงเสียต้นทุนนี้เพียงครั้งเดียวแทนที่จะเสียต่อไฟล์ วาง static assets ไว้บน CDN (content delivery network) แล้วเมืองที่เป็นที่ตั้งของ origin จะไม่ส่งผลต่อ static assets เหล่านั้นอีกต่อไป นี่คือเหตุผลที่ผู้ใช้ในยุโรปซึ่งมีค่าเวลาไป-กลับไปยัง Toronto 98 ms ยังสามารถเปิดหน้าเว็บได้รวดเร็ว

เกมผู้เล่นหลายคนแบบเรียลไทม์เป็นกรณีตรงกันข้าม เพราะเวลาไป-กลับคือประสบการณ์ของผู้เล่น ต่ำกว่าประมาณ 50 ms จะรู้สึกตอบสนองทันทีในเกมแอ็กชันที่ดำเนินเร็ว ผู้เล่นจะเริ่มสังเกตเห็นความหน่วงที่ประมาณ 80 ms และเมื่อเกิน 120 ms จะโทษเซิร์ฟเวอร์ ในกรณีนี้ region มีผลโดยตรงต่อคุณภาพของผลิตภัณฑ์ เซิร์ฟเวอร์ที่ดำเนินเกมช้ากว่าจะยอมรับความหน่วงได้มากกว่า ดังนั้น การรันเซิร์ฟเวอร์ Minecraft บน VPS จึงยังรองรับระยะทางที่อาจทำให้เกมยิงเสียประสบการณ์ได้

ฐานข้อมูลเป็นส่วนที่การเลือก region ส่งผลเสียอย่างชัดเจน อย่าวางแอปพลิเคชันไว้ใน region หนึ่งและฐานข้อมูลไว้อีก region หนึ่ง ทุก query ต้องใช้เวลาไป-กลับ หน้าเว็บที่ส่ง query 40 รายการจะต้องเสียเวลาไป-กลับ 40 ครั้ง หากแต่ละครั้งใช้เวลา 18 ms จะกินเวลาเกือบ 1 วินาที และหากแต่ละครั้งใช้เวลา 62 ms จะกินเวลามากกว่า 2 วินาที ทั้งที่หน้าเว็บนี้ใช้เวลาเพียง 30 ms จากการทำ profiling เมื่อฐานข้อมูลอยู่บนเครื่องเดียวกัน การทำ asynchronous replication ไปยังอีก region เหมาะสำหรับ read replicas และการกู้คืนจากภัยพิบัติ แต่ synchronous commit ข้ามเส้นทางที่มีระยะทางไกลจะเพิ่มเวลาในเส้นทางนั้นให้กับทุก write

เซสชันแบบโต้ตอบอยู่ระหว่างสองกรณีนี้ SSH ยังคงใช้งานได้สะดวกเมื่อมีเวลาไป-กลับประมาณ 100 ms และจะรู้สึกหน่วงเมื่อสูงกว่านั้น เพราะแต่ละการกดแป้นพิมพ์ต้องรอ echo กลับมา mosh จะคาดการณ์ภายในเครื่องและซ่อนความหน่วงส่วนใหญ่ไว้ Webhooks และ internal APIs ควรอยู่ใน region เดียวกับ service ที่เรียกใช้งานเสมอ

การเรียกเก็บเงิน สกุลเงิน และภาษี

การชำระเงินเป็นดอลลาร์แคนาดาช่วยหลีกเลี่ยงค่าธรรมเนียมธุรกรรมต่างประเทศที่ผู้ออกบัตรเรียกเก็บ ซึ่งโดยทั่วไปอยู่ที่ประมาณ 2.5% ณ เดือนสิงหาคม 2026 และช่วยให้บันทึกบัญชีใช้สกุลเงินเดียว ผู้ให้บริการในแคนาดาจะออกใบแจ้งหนี้ที่รวม GST หรือ HST ซึ่งธุรกิจที่จดทะเบียนสามารถขอคืนเป็นเครดิตภาษีซื้อได้ นี่เป็นคำถามด้านการเงินและควรใช้คำตอบด้านการเงิน และไม่ควรใช้เป็นปัจจัยตัดสินว่าแพ็กเก็ตจะถูกส่งไปที่ใด หากต้องการทราบต้นทุนจริงของเซิร์ฟเวอร์และวิธีเปรียบเทียบแผนโดยไม่ถูกเรียกเก็บค่าบริการตามราคาต่ออายุ โปรดอ่าน เซิร์ฟเวอร์ VPS มีค่าใช้จ่ายจริงต่อเดือนเท่าใด.

สิ่งที่คุณต้องแลกกับตลาดขนาดเล็ก

แคนาดาเป็นตลาด hosting ขนาดเล็กเมื่อเทียบกับสหรัฐอเมริกา ดังนั้นคำแนะนำที่ตรงไปตรงมาต้องระบุสิ่งที่คุณต้องแลกด้วย

• มีผู้ให้บริการแข่งขันเพื่อเงินของคุณน้อยกว่า ราคาต่อ gigabyte ของ RAM หรือ disk จึงมักสูงกว่าสำหรับเครื่องในระดับเดียวกัน
• ความจุกระจุกตัวอยู่ใน Toronto และ Montreal โดยมีน้อยกว่าใน Vancouver และ Calgary การมีภูมิภาคที่สองในแคนาดาสำหรับ failover มักหมายถึงเส้นทางเครือข่ายที่ยาว หรือไม่เช่นนั้นก็ต้องออกนอกประเทศ
• ผู้ให้บริการระดับภูมิภาคขนาดเล็กอาจใช้อาคารเพียงแห่งเดียวซึ่งเชื่อมต่อผ่าน upstream carrier หนึ่งหรือสองราย ให้สอบถามว่ามี carrier กี่ราย และสอบถามว่าจะเกิดอะไรขึ้นเมื่อรายใดรายหนึ่งขัดข้อง
• ตัวเลือก hardware มีจำกัดกว่า การหา instance ขนาดใหญ่และเครื่อง GPU ในภูมิภาคของสหรัฐอเมริกาทำได้ง่ายกว่า ดังนั้น GPU VPS อาจไม่มีในขนาดที่คุณต้องการและเมืองที่คุณต้องการ
• ขอบเขตการให้บริการ support ของผู้ให้บริการขนาดเล็กเป็นคำถามที่ต้องถามจริง ไม่ใช่เพียงเรื่องการตลาด ให้สอบถามว่ามนุษย์พร้อมให้บริการในช่วงเวลาใด

Montreal เป็นข้อยกเว้นด้านราคา ไฟฟ้าพลังน้ำของ Quebec มีราคาถูก และฤดูหนาวช่วยลดต้นทุนการทำความเย็น ดังนั้นพื้นที่ Montreal จึงรองรับ capacity จำนวนมากในอัตราที่แข่งขันกับภูมิภาคของสหรัฐอเมริกาได้ หากข้อกำหนดของคุณคือการใช้งานในแคนาดา ไม่ใช่เมืองใดเมืองหนึ่งโดยเฉพาะ ให้เริ่มพิจารณาที่นั่น

หากระดับ VPS ของแคนาดามีขนาดเล็กเกินไปสำหรับ workload ให้เปรียบเทียบ VPS กับ dedicated server ก่อนตัดสินใจว่าปัญหาอยู่ที่ประเทศ nicolai

เมื่อการโฮสต์ VPS ในแคนาดาเป็นตัวเลือกที่เหมาะสม

1. กฎหมาย สัญญา หรือนโยบายของหน่วยงานภาครัฐระบุให้ใช้แคนาดา ให้โฮสต์ในแคนาดา ข้อกำหนดอื่นในบทความนี้ไม่เกี่ยวข้อง และคุณควรขอให้ผู้ให้บริการยืนยันข้อผูกพันด้านถิ่นที่อยู่ของข้อมูลเป็นลายลักษณ์อักษรด้วย
2. ผู้ใช้ของคุณอยู่ในเขตเมืองแห่งใดแห่งหนึ่งของแคนาดา และเวิร์กโหลดมีข้อจำกัดด้านเวลาแฝง เช่น เกมแบบผู้เล่นหลายคน ระบบเสียง เดสก์ท็อประยะไกล หรือการซื้อขาย ให้โฮสต์ในเมืองที่ใกล้ที่สุด และวัดประสิทธิภาพทั้งสองตัวเลือกก่อนลงนามในสัญญา
3. ผู้ใช้ของคุณกระจายอยู่ทั่วประเทศ Toronto หรือ Montreal ครอบคลุมประชากรส่วนใหญ่ และการใช้ CDN ไว้ด้านหน้า static assets ช่วยผู้เข้าชมจาก Vancouver ได้มากกว่าการย้าย origin
4. กรณีอื่นทั้งหมด ซึ่งครอบคลุมสถานการณ์ส่วนใหญ่ ให้เลือกจากราคาและฮาร์ดแวร์ที่คุณได้รับจริง จากนั้นตรวจสอบว่าการสนับสนุนเป็นอย่างไรในเวลา 2am ให้ทดสอบประสิทธิภาพผู้สมัครก่อน เพราะแผน 2 รายการที่มีข้อมูลจำเพาะเหมือนกันไม่ได้ให้ประสิทธิภาพเท่ากัน: วิธีทดสอบประสิทธิภาพ VPS อย่างถูกต้อง

ไม่ว่าคุณจะเลือกแนวทางใด ให้บันทึกเหตุผลไว้ข้างการตัดสินใจ บุคคลถัดไปที่ถามว่าควรโฮสต์ในแคนาดาหรือไม่ควรได้รับคำตอบที่ดีกว่าการคาดเดา และหากคำตอบเคยเป็นข้อกำหนดในสัญญา ก็จะต้องมีผู้ค้นหาข้อกำหนดนั้นอีกครั้ง เมื่อมีเครื่องพร้อมใช้งานแล้ว 10 นาทีแรกบน VPS ใหม่ มีความสำคัญต่อความปลอดภัยของคุณมากกว่าเมืองที่ตั้งเครื่องเสียอีก

FAQ

PIPEDA กำหนดให้ข้อมูลของฉันต้องอยู่ในแคนาดาหรือไม่

ไม่ PIPEDA (Personal Information Protection and Electronic Documents Act) ไม่มีกฎกำหนดถิ่นที่อยู่ของข้อมูลสำหรับภาคเอกชน การส่งข้อมูลส่วนบุคคลไปยังผู้ประมวลผลในประเทศอื่นถือเป็นการโอนข้อมูลเพื่อประมวลผล องค์กรของคุณยังคงมีหน้าที่รับผิดชอบต่อข้อมูล ผู้ประมวลผลต้องปกป้องข้อมูลในระดับที่เทียบเท่ากัน และคุณต้องแจ้งให้บุคคลที่เกี่ยวข้องทราบอย่างเปิดเผยว่ามีการดำเนินการดังกล่าว Office of the Privacy Commissioner ได้ปรึกษาหารือเกี่ยวกับการเปลี่ยนแปลงแนวทางนี้ในปี 2019 และยังคงแนวทางเดิมไว้ ข้อกำหนดด้านถิ่นที่อยู่ของข้อมูลมาจากแหล่งอื่น เช่น การประเมินตาม Law 25 ของ Quebec กฎหมายภาครัฐ เช่น PIIDPA ของ Nova Scotia แนวทางด้าน cloud ของ Government of Canada หรือข้อกำหนดในสัญญากับลูกค้าของคุณเอง

ผู้ใช้ในแคนาดาจะสังเกตได้หรือไม่ว่า server อยู่ในสหรัฐอเมริกา

สำหรับ web application ทั่วไป ผู้ใช้จะไม่สังเกตเห็น การรับส่งข้อมูลไปกลับจาก Toronto ไป New York ใช้เวลาประมาณ 18 ms และไป Northern Virginia ประมาณ 26 ms ซึ่งทั้งสองเส้นทางสั้นกว่าการรับส่งข้อมูลจาก Toronto ไป Vancouver ที่ 62 ms ผู้ใช้จะสังเกตเห็นเวลาตอบสนองของ server และขนาดหน้าเว็บก่อนที่จะสังเกตเห็น network latency 20 ms อย่างไรก็ตาม ผู้ใช้จะสังเกตเห็นความแตกต่างนี้ในเกมแบบ real-time การสนทนาด้วยเสียง และงานที่บุคคลหนึ่งต้องตอบสนองต่ออีกบุคคลหนึ่ง

data centre ในแคนาดาอยู่นอกขอบเขตของกฎหมายสหรัฐอเมริกาหรือไม่

ไม่เสมอไป US CLOUD Act ครอบคลุมข้อมูลที่อยู่ในความครอบครอง การดูแล หรือการควบคุมของผู้ให้บริการในสหรัฐอเมริกา ไม่ว่า server จะตั้งอยู่ที่ใด ดังนั้น region ในแคนาดาที่ดำเนินการโดยบริษัทอเมริกันก็ยังอยู่ภายใต้กฎหมายนี้ หากข้อกังวลที่แท้จริงของคุณคือกระบวนการทางกฎหมายจากต่างประเทศ ให้พิจารณาว่าใครเป็นผู้ดำเนินการ service และใครเป็นผู้ถือ encryption keys แทนการพิจารณาที่อยู่ของอาคาร การเข้ารหัสด้วย keys ที่คุณถือไว้เองจะเปลี่ยนแปลงขอบเขตข้อมูลที่ผู้ให้บริการสามารถส่งมอบได้

ฉันจะวัด latency จากเมืองที่ฉันไม่ได้อาศัยอยู่ได้อย่างไร

เช่า VPS แบบคิดค่าบริการรายชั่วโมงในเมืองนั้น เรียกใช้ ping -c 20 และ mtr --report --report-cycles 50 กลับไปยัง server ของคุณเอง แล้วทำลาย VPS ดังกล่าว RIPE Atlas เป็นทางเลือกฟรีที่มี probes ในเมืองต่างๆ ของแคนาดา หากมีการบล็อก ICMP ให้จับเวลาคำขอจริงแทนด้วย curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ ซึ่งจะแสดงทั้งเวลา TCP round trip และเวลาทั้งหมดจนถึงไบต์แรก