เปรียบเทียบรูปแบบโฮสติ้งผ่านความรับผิดชอบด้านการดำเนินงานที่มอบหมายและสถาปัตยกรรมที่เปิดทางให้ ขนาดของคลาวด์ เครื่องเสมือน และฮาร์ดแวร์เฉพาะอธิบายแง่มุมที่แตกต่างกันของระบบ ไม่มีสิ่งใดเพียงอย่างเดียวพิสูจน์ความเป็นส่วนตัว ต้นทุน หรือพฤติกรรมการกู้คืนได้
เริ่มจากงานที่คุณต้องการให้มีผู้รับผิดชอบ
การตัดสินใจเรื่องโฮสติ้งมอบหมายงานด้านการดำเนินงานรวมทั้งทรัพยากรคอมพิวติ้ง โครงการหนึ่งต้องการบัญชีที่รันเว็บไซต์ทั่วไป อีกโครงการต้องการควบคุมแพ็กเกจระบบปฏิบัติการและกระบวนการเบื้องหลัง โครงการที่สามต้องการแพลตฟอร์มฐานข้อมูลที่การบำรุงรักษาดำเนินการภายใต้สัญญาบริการเฉพาะ ระบุความรับผิดชอบเหล่านั้นก่อน พร้อมกับบุคลากรที่มีอยู่เพื่อดูแลรักษา
โฮสติ้งแบบแชร์มักเปิดเผยสภาพแวดล้อมระดับบัญชี VPS เปิดเผยระบบปฏิบัติการของ guest ขณะที่ฮาร์ดแวร์เฉพาะย้ายขอบเขตเครื่องไปยังเซิร์ฟเวอร์กายภาพ ส่วน managed เป็นคำถามแยกต่างหาก ป้ายกำกับผลิตภัณฑ์ไม่ได้บอกคุณว่าใครติดตั้งแพตช์ กู้คืนข้อมูล หรือสอบสวนเหตุการณ์ ขอขอบเขตการจัดการและกระบวนการกู้คืนแทนที่จะถือว่าเป็นคุณสมบัติสากล
ทำความเข้าใจว่าคลาวด์เพิ่มอะไรในการเปรียบเทียบ
NIST อธิบายคลาวด์คอมพิวติ้งผ่านคุณลักษณะต่าง ๆ เช่น การเข้าถึงตามต้องการ การรวมทรัพยากร ความยืดหยุ่น และบริการที่วัดปริมาณได้ เครื่องเสมือนอาจเป็นองค์ประกอบหนึ่งของแพลตฟอร์มคลาวด์ ดังนั้น VPS และคลาวด์จึงไม่ใช่เทคโนโลยีที่แยกจากกันโดยสิ้นเชิง การเปรียบเทียบที่มีประโยชน์คือระหว่างบริการเฉพาะที่เสนอให้: เครื่องเสมือนแบบคงที่ กลุ่มทรัพยากรที่ยืดหยุ่น หรือแอปพลิเคชันที่สร้างขึ้นรอบบริการแบบ managed
Hyperscaler เป็นคำในอุตสาหกรรมสำหรับผู้ให้บริการที่ดำเนินงานโครงสร้างพื้นฐานและแพลตฟอร์มบริการในขนาดใหญ่มาก ขนาดนั้นอาจเสนอเครื่องมือปรับใช้และตัวเลือกทางภูมิศาสตร์ที่หลากหลาย แต่ไม่ได้บอกว่าสถาปัตยกรรมเฉพาะตรงกับความต้องการของคุณหรือไม่ ประเมินภูมิภาค สิ่งที่บริการต้องพึ่งพา แบบจำลองตัวตน และสัญญาของแต่ละองค์ประกอบ ผู้ให้บริการรายเล็กและแพลตฟอร์มขนาดใหญ่ต่างต้องมีคำอธิบายชัดเจนว่าข้อมูลไปที่ใด
| รูปแบบการดำเนินงาน | การควบคุมที่โครงการมี | คำถามก่อนเลือก |
|---|---|---|
| บัญชีโฮสติ้งแบบแชร์ | การตั้งค่าไซต์ภายในขอบเขตบัญชี | รันไทม์เข้ากับแอปพลิเคชันหรือไม่? |
| เครื่องเสมือน | ระบบปฏิบัติการ guest และบริการที่ติดตั้ง | ใครดูแลรักษาและกู้คืน guest? |
| เครื่องเฉพาะ | ขอบเขตเซิร์ฟเวอร์กายภาพ | ภาระงานสมเหตุสมผลกับขอบเขตนี้หรือไม่? |
| บริการคลาวด์แบบ managed | API ของบริการและการตั้งค่าที่รองรับ | อะไรยังคงเป็นความรับผิดชอบของลูกค้า? |
เลือกสถาปัตยกรรมที่กู้คืนได้
เครื่องเดียวอาจเป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับแอปพลิเคชันขนาดเล็ก เมื่อข้อกำหนดการกู้คืนอนุญาตให้กู้คืนหรือมีช่วงบำรุงรักษาตามแผน การเพิ่มโหนดแอปพลิเคชันที่สองเปลี่ยนการออกแบบก็ต่อเมื่อการกำหนดเส้นทางทราฟฟิก เซสชัน และข้อมูลถาวรทำงานถูกต้องทั้งสองโหนด เซิร์ฟเวอร์สองเครื่องที่ใช้แผนกู้คืนที่ไม่สมบูรณ์เหมือนกันก็ยังเป็นแผนกู้คืนที่ไม่สมบูรณ์
ที่จัดเก็บแบบกระจายแสดงให้เห็นความแตกต่างนี้ ซอฟต์แวร์เช่น Ceph กระจายงานจัดเก็บทั่วคลัสเตอร์และเสนออินเทอร์เฟซแบบ object, block และ file การทำสำเนาหรือ erasure coding อาจช่วยทนต่อความล้มเหลวของฮาร์ดแวร์บางกรณี แต่คลัสเตอร์ยังต้องมีความจุสำหรับการกู้คืนและการปรับสมดุล สำเนาสดแบบกระจายไม่แทนที่การสำรองข้อมูลอิสระ ตัดสินใจว่าการเขียนมีพฤติกรรมอย่างไรระหว่างการแยกเครือข่าย และทดสอบกรณีความล้มเหลวที่เกี่ยวข้องกับสิ่งที่คุณนำไปใช้
เปรียบเทียบงบประมาณการดำเนินงานทั้งหมด
เขียนงบประมาณเป็นภาระงาน: ทราฟฟิกปกติ ช่วงเวลาที่ใช้งานหนัก ข้อมูลที่จัดเก็บ การเก็บรักษาข้อมูลสำรอง และการรับส่งที่จำเป็นสำหรับการกู้คืน รวมซอฟต์แวร์ที่ต้องจ่ายเงิน API ภายนอก เวลาดูแลระบบ และค่าใช้จ่ายในการย้ายข้อมูลอีกครั้ง ตัวเลขรายเดือนเริ่มต้นและการประเมินตามการใช้งานตอบคำถามที่แตกต่างกัน เปรียบเทียบในช่วงเวลาเดียวกันและเก็บสมมติฐานไว้ข้างผลลัพธ์
สำหรับแพลตฟอร์มคลาวด์ขนาดใหญ่ ระบุทุกบริการที่จำเป็นเพื่อให้แอปพลิเคชันทำงานต่อไป สำหรับ VPS ให้รวมงานที่บริการแบบ managed จะรับไปแทน ทั้งสองแนวทางไม่ได้ถูกกว่าโดยอัตโนมัติ เริ่มจากการปรับใช้ตัวแทนขนาดเล็กหรือใบเสนอราคาที่จัดทำเป็นเอกสาร แล้วตรวจสอบบิลจริงเทียบกับแบบจำลอง เผื่อที่สำหรับทราฟฟิกกู้คืนและความจุย้ายข้อมูลชั่วคราว แทนที่จะตั้งงบประมาณเฉพาะสภาวะคงที่
มองความเป็นส่วนตัวเป็นแผนผังสิ่งที่ต้องพึ่งพา
ภูมิภาคของเครื่องเป็นเพียงรายการหนึ่งในแผนผังที่กว้างขึ้น การพิสูจน์ตัวตน การตรวจสอบ เครื่องมือสนับสนุน ข้อมูลสำรอง และ API ของโมเดลอาจทำงานผ่านบริการแยกต่างหาก บันทึกว่าแต่ละบริการได้รับอะไร ใครเข้าถึงได้ และเก็บไว้นานเท่าใด แบบจำลองความรับผิดชอบร่วมของ AWS เป็นตัวอย่างหนึ่งของผู้ให้บริการที่แยกหน้าที่ด้านโครงสร้างพื้นฐานออกจากหน้าที่ของลูกค้าอย่างชัดเจน ขอบเขตเปลี่ยนไปตามบริการ
ใช้ความแตกต่างนั้นเมื่อเปรียบเทียบผู้ให้บริการ โดยไม่นำภาระผูกพันของผู้ให้บริการรายหนึ่งไปใส่ในสัญญาอีกราย การกำหนดค่า SwissOctet อธิบายตำแหน่งโฮสติ้งและทรัพยากรที่ระบุไว้ ไม่ได้กำหนดตำแหน่งของการเชื่อมต่อที่คุณเพิ่มภายหลัง ลดข้อมูลที่แต่ละสิ่งที่ต้องพึ่งพาได้รับให้เหลือน้อยที่สุด รักษาความปลอดภัยของการดูแลระบบ และยืนยันปลายทางสำรองข้อมูลก่อนกล่าวถึงเส้นทางข้อมูลของแอปพลิเคชันคุณเอง
ใช้เส้นทางการย้ายเป็นส่วนหนึ่งของการตัดสินใจ
ตรวจสอบว่าคุณส่งออกข้อมูลแอปพลิเคชัน การกำหนดค่า และตัวตนได้อย่างไร แอปพลิเคชันทั่วไปบนเครื่องเสมือนอาจย้ายได้ตรงไปตรงมา ขณะที่ฐานข้อมูลหรือระบบเหตุการณ์เฉพาะบริการอาจต้องปรับเปลี่ยน ความสามารถในการย้ายยังขึ้นอยู่กับความรู้ด้านการดำเนินงาน: ข้อมูลสำรองที่ไม่มีใครรู้วิธีกู้คืนเป็นแผนออกที่อ่อนแอ แม้รูปแบบจะเปิดก็ตาม
สำหรับรายการตัวเลือก SwissOctet ครั้งแรก เปรียบเทียบ Canvas เมื่อสภาพแวดล้อมเว็บระดับบัญชีเหมาะสม Vector สำหรับการควบคุมระบบปฏิบัติการ guest และช่วง Metal เมื่อขอบเขตกายภาพสำคัญ ตัวเลือกที่เน้นที่จัดเก็บรองรับคำถามด้านความจุที่แตกต่างออกไป และไม่ควรอธิบายว่าเป็นคลัสเตอร์กระจายแบบ managed รักษาสถาปัตยกรรมให้เล็กพอที่จะดำเนินงานได้ และเพิ่มความซับซ้อนของแพลตฟอร์มเมื่อตอบสนองข้อกำหนดที่ผ่านการทดสอบ ไม่ใช่ขนาดในอนาคตที่จินตนาการไว้
รายการตรวจสอบปฏิบัติของคุณ
- มอบหมายความเป็นเจ้าของด้านการดูแลระบบและการกู้คืน
- แยกความแตกต่างระหว่าง VM กับแพลตฟอร์มคลาวด์ที่กว้างกว่า
- จัดงบประมาณสำหรับสิ่งที่ต้องพึ่งพา การรับส่ง และการบำรุงรักษา
- ทดสอบขอบเขตความล้มเหลวก่อนเพิ่มโหนด
- บันทึกเส้นทางส่งออกและย้ายข้อมูลที่ใช้งานได้
รายละเอียดที่สำคัญ
VPS เป็นส่วนหนึ่งของแพลตฟอร์มคลาวด์ได้หรือไม่?+
ได้ เครื่องเสมือนเป็นบริการคลาวด์ได้ เปรียบเทียบทรัพยากร แบบจำลองการขยาย และการจัดการจริง แทนที่จะถือว่าชื่อต่าง ๆ อธิบายเทคโนโลยีที่แยกจากกัน
ที่จัดเก็บแบบกระจายแทนที่ข้อมูลสำรองหรือไม่?+
ไม่ ความซ้ำซ้อนแบบสดจัดการความล้มเหลวขององค์ประกอบที่เลือกไว้ การสำรองข้อมูลอิสระและการทดสอบกู้คืนจัดการความล้มเหลวอื่น ๆ เช่นการลบและข้อมูลแอปพลิเคชันที่เสียหาย
คลาวด์ขนาดใหญ่เป็นตัวเลือกความเป็นส่วนตัวที่ไม่ดีเสมอไปหรือไม่?+
ไม่ ประเมินบริการเฉพาะ เส้นทางข้อมูล และมาตรการควบคุมตามสัญญา ขนาดของผู้ให้บริการเพียงอย่างเดียวไม่ได้กำหนดความเหมาะสมของสถาปัตยกรรม
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- NIST SP 800-145: คำจำกัดความของคลาวด์คอมพิวติ้ง nvlpubs.nist.gov
- AWS: แบบจำลองความรับผิดชอบร่วม aws.amazon.com
- Ceph: สถาปัตยกรรมที่จัดเก็บ docs.ceph.com
- Ceph: Erasure coding docs.ceph.com
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก