เครื่องดูปกติดี ค่าโหลดเฉลี่ยสมเหตุสมผล หน่วยความจำยังไม่หมด ดิสก์ยังมีที่ว่าง แต่แอปพลิเคชันยังช้าตอน 9 โมงเช้าของทุกวันทำงาน และไม่มีใครบอกได้ว่าเพราะอะไร หรือไม่ก็มีคนยื่นประโยคหนึ่งให้แทนตัวเลข: "งานนี้คุณต้องใช้ฮาร์ดแวร์เฉพาะ"
คำถามว่าจะเลือก VPS หรือเซิร์ฟเวอร์เฉพาะ ตัดสินด้วยสัญญาณจำนวนไม่มากที่คุณวัดได้ จากประสบการณ์ของผม เวิร์กโหลดส่วนใหญ่ที่มาถึงจุดนี้ไม่เข้าข่ายสักข้อ ทั้งสองทางเลือกล้วนสมเหตุสมผล และเซิร์ฟเวอร์เฉพาะคือคำตอบที่ถูกต้องเมื่อเงื่อนไขบางอย่างเป็นจริง
เวอร์ชันสั้น
- การย้ายไปใช้ฮาร์ดแวร์เฉพาะมีเหตุผลเมื่อสัญญาณที่ชัดเจนถูกจุดขึ้น ไม่ใช่เพราะเครื่องแค่รู้สึกช้า
- สัญญาณเชิงปฏิบัติการที่สำคัญมีสามข้อ: การใช้ CPU สูงต่อเนื่องจนไม่เหลือช่องว่าง, CPU steal time หรือ IO wait ที่ค้างอยู่ตลอด และเวิร์กโหลดที่โตเกินอินสแตนซ์ใหญ่สุดที่ผู้ให้บริการขาย
- สองในสามข้อนี้มักเกิดจากผู้ให้บริการหรือแพ็กเกจ ไม่ใช่จากการทำเวอร์ชวลไลเซชัน ทดสอบให้แน่ก่อนจะจ่ายเงิน
- PCI DSS และ HIPAA Security Rule ระบุผลลัพธ์ด้านการแยกส่วนและการควบคุม ไม่ได้ระบุรูปแบบของฮาร์ดแวร์ และไม่มีข้อใดที่ลำพังตัวมันเองบังคับให้ต้องใช้เครื่องจริง
- ฮาร์ดแวร์เฉพาะจะได้เปรียบด้านต้นทุนก็ต่อเมื่อใช้งานสูงอย่างต่อเนื่องเท่านั้น ต่ำกว่านั้นคุณกำลังจ่ายค่าฮาร์ดแวร์ขั้นต่ำที่ตายตัวโดยไม่ได้ใช้
อะไรที่ต่างกันระหว่าง VPS กับเซิร์ฟเวอร์เฉพาะ
ลองดูแพ็กเกจที่โฆษณาว่ามี 4 vCPU บนเซิร์ฟเวอร์เฉพาะ สี่คอร์นั้นเป็นของคุณไม่ว่าจะใช้หรือไม่ก็ตาม แต่บน VPS สี่ vCPU คือคำสัญญาเรื่องการจัดคิว: ไฮเปอร์ไวเซอร์แสดงโปรเซสเซอร์เสมือนสี่ตัวให้เคอร์เนลของคุณ แล้วจัดสรรเวลาบนคอร์จริงตามนโยบายของมันและภาระของโฮสต์ในขณะนั้น
ในสภาวะปกติทั้งสองทำงานเหมือนกัน แต่เมื่อเกิดการแย่งทรัพยากรจะไม่เหมือนกัน
ความต่างไม่ได้อยู่ที่เสมือนกับกายภาพ แต่อยู่ที่สิ่งที่ถูกรับประกันให้คุณ กับสิ่งที่แค่ถูกจัดสรรให้คุณ
โมเดลการแยกส่วนก็แบ่งตามเส้นเดียวกัน VPS ถูกแยกในเชิงตรรกะโดยไฮเปอร์ไวเซอร์: เคอร์เนลแยก พื้นที่หน่วยความจำแยก ดิสก์เสมือนแยก ทั้งหมดบังคับใช้ด้วยซอฟต์แวร์ที่รันอยู่บนซิลิคอนร่วมกัน ความต่างระหว่าง VPS กับ bare metal อยู่ที่ตำแหน่งของเส้นแบ่งนั้น ไม่ใช่ว่ามีเส้นแบ่งหรือไม่
ทั้งสองแบบคือการแยกส่วนจริง ๆ แต่ล้มเหลวคนละแบบและถูกตรวจสอบคนละแบบ ซึ่งเป็นเรื่องสำคัญในหัวข้อการปฏิบัติตามข้อกำหนดด้านล่าง
โอเวอร์เฮดของไฮเปอร์ไวเซอร์แทบไม่ใช่ประเด็นอีกต่อไป บน KVM รุ่นใหม่ที่มีส่วนขยายเวอร์ชวลไลเซชันระดับฮาร์ดแวร์และไดรเวอร์แบบพาราเวอร์ชวลไลซ์ ผมไม่เคยเจอว่าไฮเปอร์ไวเซอร์คือสาเหตุที่แอปพลิเคชันช้า
ถ้า VPS ทำงานได้ต่ำกว่าที่ควร สาเหตุตามปกติคือการแย่งทรัพยากรหรือขนาดที่เลือกไว้
ตัวแปรที่น่าสนใจอยู่ในเรื่องการแย่งทรัพยากร และนั่นคือนโยบายของผู้ให้บริการ ไม่ใช่คุณสมบัติของการทำเวอร์ชวลไลเซชัน การขายเกิน (oversubscription) คือการขาย vCPU, IOPS หรือหน่วยความจำรวมกันทุกเกสต์มากกว่าที่โฮสต์มีอยู่จริง โดยตั้งสมมติฐานว่าไม่ใช่ทุกคนจะพีคพร้อมกัน ผู้ให้บริการบางรายแทบไม่ทำ บางรายทำอย่างหนัก
ข้อสรุปนี้ไม่น่าฟังนักสำหรับคนที่เลือกซื้อโดยดูแค่ประเภทบริการ VPS ที่ขายเกินอย่างหนักกับ VPS ที่บริหารดี ห่างกันในเชิงพฤติกรรมมากกว่า VPS ที่บริหารดีกับเซิร์ฟเวอร์เฉพาะเสียอีก
โฮสติ้งแบบแชร์ไม่อยู่ในการเปรียบเทียบนี้: ไม่มีสิทธิ์ root และไม่มีการรับประกันทรัพยากรที่คงที่ และ คู่มือของเราอธิบายว่าควรอัปเกรดจากโฮสติ้งแบบแชร์ไปเป็น VPS เมื่อไร หากขั้นนั้นมาก่อนสำหรับคุณ ส่วนโคโลเคชันอยู่นอกขอบเขต เพราะคุณซื้อและเป็นเจ้าของฮาร์ดแวร์เอง ซึ่งเป็นรูปแบบการจัดหาที่ต่างออกไป มีสัญญาต่างกันและมีเรื่องราวตอนอุปกรณ์เสียที่ต่างกัน
| เกณฑ์ | VPS | เซิร์ฟเวอร์เฉพาะ |
|---|---|---|
| การแยกทรัพยากร | เชิงตรรกะ บังคับใช้โดยไฮเปอร์ไวเซอร์ | เชิงกายภาพ ผู้เช่ารายเดียว |
| การจัดสรร CPU | vCPU ถูกจัดคิวลงบนคอร์จริงที่ใช้ร่วมกัน | คอร์จริง เป็นของคุณผู้เดียว |
| การแย่ง IO | พูลสตอเรจร่วม; ค่าหน่วงแปรผันตามภาระของโฮสต์ | ดิสก์ในเครื่อง ไม่มีการแย่งจากภายนอก |
| การแย่งแบนด์วิดท์เครือข่าย | อัปลิงก์ที่ใช้ร่วมกัน | NIC และพอร์ตเฉพาะของคุณ |
| การควบคุมฮาร์ดแวร์ | ไม่มี ผู้ให้บริการเป็นคนเลือกแพลตฟอร์ม | เต็มที่ ทั้งรุ่นของ CPU การจัดวางดิสก์ และ RAID |
สัญญาณที่บอกว่าคุณโตเกิน VPS แล้ว
นี่คือการตรวจสอบกับข้อมูลเทเลเมทรีของคุณเอง ไม่ใช่กฎคร่าว ๆ เกี่ยวกับอุตสาหกรรมของคุณ มีเงื่อนไขเดียวที่ครอบคลุมทั้งสามข้อ: สัญญาณจะนับก็ต่อเมื่อมันเกิดต่อเนื่อง
เครื่องที่ CPU ค้างอยู่ที่ 95% ระหว่างช่วงสำรองข้อมูลตอนกลางคืนถือว่าทำงานถูกต้อง แต่เครื่องที่ค้างอยู่ที่ 95% ติดต่อกันสองสัปดาห์กำลังบอกอะไรบางอย่างกับคุณ
การใช้ CPU สูงต่อเนื่องจนไม่เหลือช่องว่าง
เงื่อนไขที่ต้องเฝ้าดูคือค่าเฉลี่ยเคลื่อนที่ตลอดหลายวันหรือหลายสัปดาห์ ที่ไม่เหลือที่ว่างให้รองรับทราฟฟิกพุ่ง โปรเซสที่หลุดการควบคุม หรือ dependency ที่ช้า ไม่ใช่ค่าพีคครั้งเดียว เมื่อถึงจุดนั้น เวลาตอบสนองจะแย่ลงแบบไม่เป็นเชิงเส้นแทนที่จะค่อย ๆ ลด และเหตุการณ์ถัดไปก็ไม่เหลือที่ให้ไป
รูปแบบของเวิร์กโหลดขยับเส้นนี้ ตัวบริโภคคิวที่ทำงานสม่ำเสมอและอยู่ใกล้เพดานของมัน เสี่ยงกว่าเว็บเทียร์แบบพุ่งเป็นช่วงที่พีควันละสองครั้งแล้วว่างที่เหลือ อ่านกราฟของคุณเอง อย่าอ่านตัวเลขจากหน้าเว็บของผู้ขาย
การติดคอขวดที่ CPU ไม่เท่ากับการต้องใช้ฮาร์ดแวร์เฉพาะ อย่างแรกมักแก้ได้ภายในเวอร์ชวลไลเซชัน: อินสแตนซ์ที่ใหญ่ขึ้น หรืออินสแตนซ์ที่สัญญาณนาฬิกาสูงขึ้นเมื่อเวิร์กโหลดเป็นเธรดเดียวและไวต่อค่าหน่วง
ยืนยันให้แน่ก่อนว่าคุณเจอแบบไหน ก่อนจะไปตีราคาเครื่องจริง แอปพลิเคชันแบบเธรดเดียวไม่ได้เร็วขึ้นบน 32 คอร์
Steal time และ IO wait
CPU steal time คือเปอร์เซ็นต์ของเวลาที่โปรเซสเซอร์เสมือนของคุณพร้อมทำงาน แต่ไฮเปอร์ไวเซอร์ยกคอร์จริงให้คนอื่นไป มันคือตัวเลขที่แยกระหว่างเวิร์กโหลดที่ใหญ่เกินไป กับโฮสต์ที่แน่นเกินไป
อย่าใช้ตัวเลขเปอร์เซ็นต์ steal time ค่าใดค่าหนึ่งเป็นเส้นตัดสิน ให้ดูแนวโน้มบนเครื่องของคุณเอง ใกล้ศูนย์และกระตุกเป็นครั้งคราวคือปกติ แต่ถ้าไม่เป็นศูนย์ตลอดและไต่ขึ้นเรื่อย ๆ แปลว่าโฮสต์กำลังแออัด
ถ้าค่าสูงและค้างอยู่บนเวิร์กโหลดที่ไวต่อค่าหน่วง แปลว่าคุณกำลังถูกข้ามในการจัดคิว และแอปพลิเคชันเป็นฝ่ายจ่ายราคานั้น
เคล็ดลับ: รัน vmstat 1 30 แล้วดูคอลัมน์ st ในบล็อก CPU ส่วน top ก็รายงานตัวเลขเดียวกันในชื่อ %st อ่านค่าช่วงชั่วโมงพีคจริงของคุณ ไม่ใช่ครั้งเดียวตอนเที่ยงคืน โฮสต์ที่แข็งแรงจะหน้าตาแบบนี้:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 412332 84120 1932144 0 0 0 12 842 1503 21 4 75 0 0
2 0 0 411980 84120 1932148 0 0 0 0 901 1622 24 5 71 0 0ส่วนโฮสต์ที่แออัดจะหน้าตาแบบนี้ และเวลาที่หายไปอยู่ในคอลัมน์สุดท้าย:
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 0 288104 61228 1104996 0 0 8 140 1502 2210 31 6 45 1 17
5 0 0 287960 61228 1105004 0 0 0 0 1610 2388 29 7 44 2 18steal time สูงแปลว่าโฮสต์นี้ถูกขายเกิน นั่นเป็นข้อความเกี่ยวกับผู้ให้บริการและแพ็กเกจของคุณ ไม่ใช่เกี่ยวกับเวอร์ชวลไลเซชัน การตอบสนองแรกที่ถูกต้องคือย้ายไปโฮสต์ที่จัดสรรทรัพยากรดีกว่า หรือแพ็กเกจที่มี vCPU เฉพาะ การออกจากเวอร์ชวลไลเซชันมาทีหลัง ไม่ใช่มาแทน
ถ้าสิ่งที่คุณเจอคือ steal time การวินิจฉัยเรื่องการขายเกิน คือเส้นด้ายเส้นแรกที่ควรดึง
ผมย้ายเวิร์กโหลดสองตัวออกจาก VPS ด้วยเหตุผลนี้ ทั้งคู่ไม่ได้ติดคอขวดที่ CPU ทั้งคู่อยู่บนโฮสต์ที่ถูกขายเกินกำลัง และหนึ่งในนั้นแค่ต้องการผู้ให้บริการรายอื่นเท่านั้น
เพดานของการขยายขนาด
คุณชนเพดานเมื่ออินสแตนซ์ใหญ่ที่สุดที่ผู้ให้บริการขายไม่พอสำหรับเวิร์กโหลดอีกต่อไป หรือเมื่อการขยายแนวตั้งครั้งล่าสุดให้ผลดีขึ้นน้อยกว่าครั้งก่อนอย่างเห็นได้ชัด ข้อหลังมองข้ามได้ง่าย ถ้าเพิ่มขนาดอินสแตนซ์เป็นสองเท่าแล้วได้ดีขึ้นแค่ 20% แปลว่าคอขวดย้ายไปอยู่ที่ที่ vCPU เพิ่มเท่าไรก็ไปไม่ถึง
ตัวกระตุ้นฝั่งสตอเรจคือสิ่งที่ผมเห็นว่ารอดจากการตรวจสอบบ่อยที่สุด และมักมาในคราบของฐานข้อมูล ข้อจำกัดแทบไม่เคยอยู่ที่ตัวเอนจิน แต่อยู่ที่ random IO ที่ต่อเนื่องบนพูลที่คุณใช้ร่วมกับคนแปลกหน้า
เวิร์กโหลดใดก็ตามที่อ่านและเขียนบล็อกเล็ก ๆ อย่างต่อเนื่อง (ฐานข้อมูลที่ทำงานหนัก คิวที่เก็บข้อมูลถาวร บริการที่เขียนล็อกเยอะ) จะกดพูลนั้นด้วยรูปแบบที่มันรับมือได้แย่ที่สุด
เฝ้าดู %wa และค่าเปอร์เซ็นไทล์ของค่าหน่วงของคุณเองในช่วงพีคจริง ถ้าค่าหน่วงแกว่งในแบบที่ภาระของคุณเองอธิบายไม่ได้ แปลว่าคุณกำลังต่อคิวอยู่หลังผู้เช่ารายอื่น และทางแก้ที่เชื่อถือได้คือดิสก์ที่เป็นของคุณเอง
สองในสามสัญญาณนี้มักแก้ได้โดยไม่ต้องออกจากเวอร์ชวลไลเซชัน และการทดสอบเรื่องนี้ถูกกว่าการซื้อฮาร์ดแวร์
เมื่อไรที่การปฏิบัติตามข้อกำหนดบังคับให้ใช้ฮาร์ดแวร์เฉพาะ
ผู้ตรวจสอบเขียนว่า "สภาพแวดล้อมข้อมูลผู้ถือบัตรต้องทำงานบนฮาร์ดแวร์เฉพาะ" ประโยคนี้ทำหน้าที่ต่างกันสองแบบขึ้นกับว่าใครเป็นคนอ่าน สำหรับมืออาชีพด้านการปฏิบัติตามข้อกำหนด มันมักหมายถึงสภาพแวดล้อมที่แยกจากเวิร์กโหลดอื่นและกำหนดขอบเขตไว้แคบ แต่สำหรับคนที่กำลังเลือกซื้อโฮสติ้ง มันดูเหมือนชื่อหมวดสินค้า
ช่องว่างระหว่างสองการตีความนี้คือจุดที่งบประมาณถูกใช้ไปโดยไม่ได้การควบคุมเพิ่มขึ้นเลย
ทั้ง PCI DSS และ HIPAA Security Rule ต่างระบุผลลัพธ์ด้านการแยกส่วนและการควบคุม ไม่ใช่รูปแบบของฮาร์ดแวร์ ถ้าข้อกำหนดของคุณคือให้ระบบชุดหนึ่งถูกแบ่งส่วน ควบคุมการเข้าถึง เก็บบันทึก และประเมินได้อย่างอิสระ สภาพแวดล้อมเสมือนที่แบ่งส่วนอย่างถูกต้องก็ตอบโจทย์ได้ แต่ถ้าข้อกำหนดของคุณคือห้ามมีโค้ดของผู้เช่ารายอื่นรันบนซิลิคอนเดียวกัน มีแต่ฮาร์ดแวร์จริงเท่านั้นที่ตอบได้
ก่อนจะไปตีราคาอะไรก็ตาม จงระบุให้ชัดว่าประโยคที่คุณได้รับมาคือแบบไหน
สำหรับ PCI DSS แนวคิดที่ใช้งานจริงคือขอบเขต โดย แนวทางของ Security Standards Council เรื่องการกำหนดขอบเขตและการแบ่งส่วนเครือข่าย วางจุดยืนตั้งต้นว่าทุกอย่างอยู่ในขอบเขตจนกว่าจะพิสูจน์เป็นอย่างอื่น และอธิบายการแบ่งส่วนว่าเป็นวิธีหนึ่งที่ช่วยลดจำนวนคอมโพเนนต์ของระบบที่อยู่ในขอบเขตได้ เอกสารเสริมฉบับนั้นไม่ได้ระบุรูปแบบฮาร์ดแวร์ใด ๆ ไว้เลยตลอดทั้งเนื้อความ
สภาพแวดล้อมเสมือนที่แบ่งส่วนไม่ดีก็ยังลากสแตกของคุณเข้ามาอยู่ในขอบเขตได้มากกว่าที่ตั้งงบไว้มาก นั่นคือต้นทุนของการทำแบบลวก ๆ ไม่ใช่เหตุผลที่จะไม่ทำ
HIPAA ระบุชัดเจนกว่าว่าตัวเองอิงกับการควบคุม ตัวบทของข้อกำหนดเรื่องความยืดหยุ่นในแนวทางของ HIPAA Security Rule ตามที่ Cornell Law School เผยแพร่ ระบุว่า หน่วยงานที่อยู่ภายใต้กฎและคู่ค้าทางธุรกิจสามารถใช้มาตรการความปลอดภัยใดก็ได้ที่ทำให้พวกเขาปฏิบัติตามมาตรฐานได้อย่างสมเหตุสมผลและเหมาะสม การเลือกจะถูกตัดสินโดยเทียบกับขนาดขององค์กร โครงสร้างพื้นฐานทางเทคนิค ต้นทุน และความเสี่ยง นั่นคือการทดสอบความเหมาะสม ไม่ใช่การกำหนดสเปกอุปกรณ์
สำหรับการติดตั้งแบบโฮสต์ ข้อกำหนดที่มีผลจริงมักเป็นเรื่องสัญญา ตัวบท 45 CFR § 164.308(b)(1) ที่ Cornell Law School เผยแพร่ ระบุว่าหน่วยงานที่อยู่ภายใต้กฎจะให้คู่ค้าทางธุรกิจจัดการข้อมูลสุขภาพที่ได้รับการคุ้มครองในรูปแบบอิเล็กทรอนิกส์ได้ก็ต่อเมื่อได้รับหลักประกันที่น่าพอใจแล้วว่าข้อมูลนั้นจะถูกคุ้มครองอย่างเหมาะสม ผู้ให้บริการที่ไม่ยอมเซ็นข้อตกลงคู่ค้าทางธุรกิจก็ตัดสิทธิ์ตัวเองไปแล้ว ไม่ว่าฮาร์ดแวร์จะหน้าตาอย่างไร
บางกรณีต้องเป็นเซิร์ฟเวอร์เฉพาะเท่านั้น เช่น สัญญากับลูกค้าที่ระบุการแยกทางกายภาพไว้เป็นลายลักษณ์อักษร
อีกกรณีคือมาตรการควบคุมที่ทำไม่ได้เลยถ้าไม่มีสิทธิ์เข้าถึงฮาร์ดแวร์ เช่น การเข้ารหัสทั้งดิสก์ด้วยกุญแจที่คุณเก็บไว้ใน TPM ที่คุณควบคุมเอง, secure boot ที่ตรวจสอบได้ หรือเบสไลน์เฟิร์มแวร์ที่คุณรับรองด้วยตัวเอง ในกรณีเหล่านี้ ซื้อฮาร์ดแวร์ไปเลย แล้วเลิกเปรียบเทียบได้
เคล็ดลับ: ก่อนจะยอมรับคำว่า "ฮาร์ดแวร์เฉพาะ" เป็นข้อกำหนด ให้ถามคนที่เขียนมันว่ามันบังคับใช้มาตรการควบคุมข้อไหน และใช้กับระบบใดบ้าง คำตอบมักจะเป็นสภาพแวดล้อมที่แยกออกมาและจำกัดขอบเขตไว้ที่สภาพแวดล้อมข้อมูลผู้ถือบัตร ไม่ใช่ตัวสินค้าที่ชื่อว่าเซิร์ฟเวอร์เฉพาะ ซึ่งสองอย่างนี้ราคาต่างกันมาก
ผลลัพธ์ด้านการปฏิบัติตามข้อกำหนดขึ้นกับผู้ประเมินของคุณและขอบเขตเฉพาะของคุณ บทความนี้ให้คำถามที่ถูกต้องไว้ถามพวกเขา ไม่ใช่คำวินิจฉัยที่คุณจะยกไปโต้กลับ
จุดที่เส้นโค้งต้นทุนตัดกัน
Dedicated hardware looks cheap per core, and at sufficient scale it is. Across providers publishing public bare metal pricing, entry configurations in the 6-core, 32 GB class typically start from around $150 to $200 per month, while 24-core, 256 GB machines with multi-terabyte NVMe commonly start from $450 and up.
Those are typical list-price ranges as of August 2026, not a market average. Price your own shortlist.
ให้ดูรูปทรงของกราฟแทนที่จะดูตัวเลขสัมบูรณ์ ราคาของ VPS แปรผันเกือบเป็นเส้นตรงตามทรัพยากรที่จัดสรร และแทบไม่มีค่าขั้นต่ำ นั่นคือเหตุผลที่อินสแตนซ์ 1 GB ราคาไม่กี่ดอลลาร์ ส่วนราคาของเซิร์ฟเวอร์เฉพาะเริ่มต้นที่ราคาของเครื่องจริงทั้งเครื่อง แล้วค่อย ๆ ไต่ขึ้นช้า ๆ เพราะต้นทุนส่วนเพิ่มของการใส่คอร์เพิ่มในตัวเครื่องที่คุณเช่าอยู่แล้วนั้นต่ำ
เส้นตรงสองเส้นที่มีความชันต่างกันและจุดตัดแกนต่างกัน จะตัดกันที่จุดเดียว
อัตราการใช้งานเป็นตัวตัดสินว่าคุณอยู่ฝั่งไหนของจุดตัดนั้น เส้นของเซิร์ฟเวอร์เฉพาะเป็นเส้นคงที่: คุณจ่ายค่า 24 คอร์ ไม่ว่าจะใช้ 24 หรือ 4
เครื่องเฉพาะที่ใช้งานอยู่ 20% มีต้นทุนต่อหน่วยงานที่ทำเสร็จสูงกว่า VPS ที่ปรับขนาดพอดี ต่อให้ใบแจ้งหนี้ต่อคอร์จะถูกกว่าก็ตาม ตัวส่วนคือสิ่งที่คุณใช้ไปจริง ไม่ใช่สิ่งที่ถูกขายให้คุณ
จุดตัดไม่ใช่ "เกิน N คอร์" แต่คือ "เกิน N คอร์ที่คุณใช้งานอยู่จริง ๆ"
มีต้นทุนสามอย่างที่ไม่ปรากฏบนใบแจ้งหนี้ฝั่งไหนเลย แต่ควรอยู่ในการเปรียบเทียบ:
- เวลาในการจัดเตรียมเครื่อง VPS พร้อมใช้ภายในไม่กี่นาที ส่วนฮาร์ดแวร์จริงต้องสั่งซื้อ ติดตั้งเข้าแร็ก และส่งมอบภายในหลายชั่วโมงหรือหลายวัน ความล่าช้านั้นเป็นข้อจำกัดในการวางแผนกำลังการรองรับ ไม่ใช่ความไม่สะดวกครั้งเดียวจบ
- ลดขนาดลงไม่ได้ หลังเหตุการณ์ทราฟฟิกพุ่ง คุณย่อ VPS กลับลงได้ ส่วนเซิร์ฟเวอร์เฉพาะคือข้อผูกพันรายเดือนที่ขนาดเต็มจนกว่าสัญญาจะครบกำหนด
- ฮาร์ดแวร์เสีย เมื่อโฮสต์ใต้คุณล่มบน VPS ผู้ให้บริการจะย้ายหรือกู้คืนให้ แต่เมื่อดิสก์หรือพาวเวอร์ซัพพลายในเครื่องเฉพาะของคุณเสีย เส้นทางกู้คืนคือการเปิดตั๋วซัพพอร์ตและกู้จากแบ็กอัป โดยเวลาที่ระบบล่มถูกนับอยู่ใน SLA ของคุณเอง
เมื่อไรที่ VPS ยังคงเป็นคำตอบที่ถูกต้อง
ไม่มีสัญญาณข้อไหนถูกจุดขึ้นเลย การใช้งานยังมีช่องว่าง steal time ราบเรียบ เพดานขนาดอินสแตนซ์ยังอีกไกล ไม่มีสัญญาบังคับให้แยกทางกายภาพ และปริมาณการใช้ของคุณก็ยังห่างจากจุดตัดต้นทุนมาก อยู่กับเวอร์ชวลไลเซชันต่อไปเถอะ
นั่นคือความสามารถ ไม่ใช่รางวัลปลอบใจ สแนปช็อตทำให้การอัปเกรดย้อนกลับได้ และทำให้การย้ายระบบที่เสี่ยงทดสอบได้ อินสแตนซ์เล็ก ๆ แยกกันให้การแบ่งแยกสภาพแวดล้อมในราคาที่ทำให้การมี staging คุ้มค่า
และฮาร์ดแวร์ที่พังตอนตีสามก็เป็นเรื่องของคนอื่น ซึ่งสำหรับทีมเล็ก ๆ มีค่ามากกว่าตัวเลขเบนช์มาร์กที่ต่างกันนิดหน่อย
ช่องว่างแคบลงแล้ว และนั่นคือความเปลี่ยนแปลงของเทคโนโลยี ไม่ใช่คำโฆษณา แพ็กเกจ vCPU เฉพาะ, NVMe ที่กลายเป็นค่าเริ่มต้น และไดรเวอร์พาราเวอร์ชวลไลซ์ที่สุกงอมแล้ว ได้ลบระยะห่างด้านประสิทธิภาพในทางปฏิบัติออกไปเกือบหมดสำหรับเวิร์กโหลดทั่วไป
อายุของผู้ให้บริการควรอยู่ในรายชื่อตัวเลือกเคียงข้างสเปก แพ็กเกจ VPS ที่คุณย้ายออกได้ในบ่ายเดียว มีความเสี่ยงด้านผู้ขายน้อยกว่าสัญญาฮาร์ดแวร์สิบสองเดือน แต่ข้อนี้จริงก็ต่อเมื่อผู้ให้บริการยังอยู่และยังตอบตั๋วในเดือนที่เก้า ลองตรวจดูว่าเขาเปิดดำเนินการมานานแค่ไหน เผยแพร่ประวัติเหตุขัดข้องอย่างไร และฝ่ายซัพพอร์ตตอบสนองอย่างไรในตอนที่ยังไม่ล่ม ไม่ใช่ตอนล่มแล้ว
โฮสติ้งเซิร์ฟเวอร์เฉพาะแบบมีผู้ดูแลก็มีอยู่ โดยแลกการควบคุมฮาร์ดแวร์กับภาระด้านปฏิบัติการที่น้อยลง ซึ่งอยู่บนแกนเดียวกับ การตัดสินใจระหว่างแบบมีผู้ดูแลกับไม่มีผู้ดูแล ที่อยู่ต่ำลงไปหนึ่งชั้น
การอยู่กับ VPS ต่อไปเป็นการตัดสินใจเชิงรุกที่มีเส้นทางขยับขยายของตัวเอง ไม่ใช่ค่าตั้งต้นที่คุณตกไปอยู่เพราะไม่ได้เลือกอะไรเลย
ถ้าผลวินิจฉัยของคุณคือการแย่งทรัพยากร ไม่ใช่กำลังการรองรับ สิ่งที่คุณควรซื้อคือ VPS ไม่ใช่ตัวเครื่องทั้งเครื่อง และสิ่งที่คุณต้องการจากมันคืออิสระที่จะย่อกลับลงหลังเหตุการณ์ที่ผลักคุณมาถึงจุดนี้ นั่นคือกรณีที่เราสร้างขึ้นมาเพื่อรองรับ: Linux VPS ทำงานบนสตอเรจ NVMe พร้อม SLA อัปไทม์ 99.95% และคิดค่าบริการรายชั่วโมง การทดลองอินสแตนซ์ที่ใหญ่ขึ้นหรือสัญญาณนาฬิกาสูงขึ้นเสียเวลาคุณแค่บ่ายเดียว ไม่ใช่ทั้งสัญญา ปรับขนาดตามเกณฑ์ข้างต้น ลองรันผ่านช่วงพีคจริงของคุณ แล้วกลับไปดูค่า steal time อีกครั้ง
พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC
ดูแพ็กเกจ Linuxคำถามที่พบบ่อย
เซิร์ฟเวอร์เฉพาะเร็วกว่า VPS แค่ไหน?
ขึ้นอยู่กับว่าคุณกำลังแย่งทรัพยากรตัวไหน บนเวอร์ชวลไลเซชันสมัยใหม่ ช่องว่างด้าน CPU บนโฮสต์ที่จัดสรรทรัพยากรดีนั้นเล็กมาก เพราะโอเวอร์เฮดของไฮเปอร์ไวเซอร์แทบไม่มีเมื่อมีส่วนขยายเวอร์ชวลไลเซชันระดับฮาร์ดแวร์ ความต่างที่เชื่อถือได้คือการไม่มีการแย่ง IO และการแย่งเครือข่าย ซึ่งแสดงออกมาเป็นความสม่ำเสมอของค่าหน่วงมากกว่าความเร็วดิบ ถ้าเวิร์กโหลดของคุณไม่เคยแย่งดิสก์หรือเครือข่ายในช่วงพีค ให้คาดว่าช่องว่างจะเล็กพอจนไม่เป็นตัวตัดสินการซื้อ
VPS ดีพอสำหรับฐานข้อมูลบนโปรดักชันไหม?
สำหรับฐานข้อมูลโปรดักชันส่วนใหญ่ ใช่ ข้อจำกัดที่ผูกมัดจริงมักคือ random IO ที่ต่อเนื่องบนสตอเรจร่วม ไม่ใช่ตัวเอนจินฐานข้อมูล ฐานข้อมูลที่อ่านเขียนบล็อกเล็ก ๆ ตลอดเวลาจะชนขีดจำกัดของพูลร่วมก่อนจะชนขีดจำกัดของเอนจินอยู่มาก ดิสก์เฉพาะช่วยเอาขีดจำกัดนั้นออกไป ส่วนอินสแตนซ์ที่ใหญ่ขึ้นไม่ช่วย
PCI DSS บังคับให้ต้องใช้เซิร์ฟเวอร์เฉพาะหรือไม่?
ไม่ ไม่ใช่กฎเหมารวม PCI DSS ระบุข้อกำหนดด้านการแยกส่วนและการควบคุมที่ผูกกับสภาพแวดล้อมข้อมูลผู้ถือบัตร ไม่ใช่รูปแบบของฮาร์ดแวร์ แนวทางการกำหนดขอบเขตของ Security Standards Council ถือว่าทุกอย่างอยู่ในขอบเขตจนกว่าจะพิสูจน์เป็นอย่างอื่น และอธิบายการแบ่งส่วนเครือข่ายว่าเป็นวิธีลดจำนวนระบบที่อยู่ในขอบเขต สภาพแวดล้อมเสมือนที่แบ่งส่วนอย่างถูกต้องตอบโจทย์นี้ได้ ส่วนที่แบ่งส่วนไม่ดีจะดึงสแตกของคุณเข้ามาอยู่ในขอบเขตมากกว่าเดิมมาก
จะรู้ได้อย่างไรว่า VPS ของฉันเจอปัญหาเพื่อนบ้านเสียงดัง?
อาการคือประสิทธิภาพที่ไม่คงเส้นคงวาในช่วงพีค บนเครื่องที่จริง ๆ ก็ไม่ได้ยุ่งอะไร: เวลาตอบสนองแกว่งไปมาในขณะที่ภาระ หน่วยความจำ และการใช้ดิสก์ของคุณเองยังราบเรียบและไม่มีอะไรผิดปกติ ช่วงเวลาที่คนน้อยดูปกติดี ซึ่งเป็นเหตุผลว่าทำไมปัญหานี้จึงอยู่รอดโดยไม่ถูกวินิจฉัยนานขนาดนั้น ต้นเหตุอยู่ที่โฮสต์จริงที่คุณใช้ร่วมกับคนอื่น ทางแก้จึงคือแพ็กเกจที่จัดสรรทรัพยากรดีกว่าหรือผู้ให้บริการรายอื่น ไม่ใช่การเขียนแอปพลิเคชันใหม่
ควรอัปเกรดจาก VPS ไปเป็นเซิร์ฟเวอร์เฉพาะเมื่อไร?
Upgrade when at least one of these holds: CPU utilization sits at a rolling-average level that leaves no headroom for a traffic event; steal time or IO wait stays high after you have already tried a better-provisioned plan; the workload has outgrown the largest instance your provider sells; a contract or a control genuinely requires physical isolation; or sustained utilization is high enough that a fixed hardware cost beats per-resource pricing.
