การแชร์ไฟล์ในสำนักงานกับแอปจองบริการสาธารณะต้องใช้เครื่อง งบประมาณ และแผนกู้คืนต่างกัน การตัดสินใจว่าจะสร้างเซิร์ฟเวอร์อย่างไรเริ่มจากงานที่ต้องให้ทำงานต่อเนื่อง การสร้างตั้งแต่ต้นคือการเลือกและประกอบชิ้นส่วนที่เข้ากันได้ จากนั้นติดตั้งระบบปฏิบัติการและกำหนดค่าบริการให้ใช้งานได้จริง
สำหรับเอกสารในพื้นที่ การซื้อเครื่องทาวเวอร์เสียงเบาอาจเหมาะสม สำหรับแอปที่เปิดให้อินเทอร์เน็ตเข้าถึง การเช่าอาจช่วยลดงานด้านอุปกรณ์และสถานที่ ทั้งสองทางต้องมีผู้รับผิดชอบสิทธิ์เข้าถึง การอัปเดต และการกู้คืน
ก่อนจับฮาร์ดแวร์ เตรียมคู่มือชิ้นส่วน โต๊ะทำงานที่โล่ง และมาตรการป้องกันไฟฟ้าสถิตตามคำแนะนำผู้ผลิต สำหรับการตั้งค่า ต้องมีเครือข่ายแบบสาย USB ติดตั้ง คีย์บอร์ดและจอในพื้นที่ บัญชีผู้ดูแลรายบุคคล และคอมพิวเตอร์อีกเครื่องสำหรับทดสอบ คัดลอกข้อมูลเดิมไปที่อื่นก่อนเปลี่ยนผังดิสก์
กำหนดงานธุรกิจก่อนเลือกฮาร์ดแวร์
โฟลเดอร์แชร์ใบแจ้งหนี้ต้องมีความจุและการเข้าถึงไฟล์ที่เชื่อถือได้ ส่วนแอปสาธารณะเพิ่มความต้องการการเชื่อมต่อภายนอกและการดูแลแอป เขียนงานให้ชัดก่อนเลือกฮาร์ดแวร์เซิร์ฟเวอร์จากโปรโมชัน CPU หรือ RAM
ใช้แบบฟอร์มความต้องการสั้น ๆ:
- ระบุชื่อบริการและแอปที่จะใช้บริการนั้น เขียนกิจกรรมที่เกิดพร้อมกัน เช่น เปิดเอกสารขณะสำรองข้อมูล
- วัดข้อมูลปัจจุบัน การเติบโตที่คาด และเวอร์ชันที่เก็บไว้ แยกพื้นที่ใช้ได้จริงที่ธุรกิจต้องการออกจากผลรวมความจุบนฉลากไดรฟ์
- ระบุว่าจำกัดการเข้าถึงในสำนักงานหรือเปิดสาธารณะ รวมสแกนเนอร์ เครื่องพิมพ์ และอุปกรณ์ในพื้นที่ที่ต้องเข้าถึงด้วย
- กำหนดช่วงข้อมูลสูญหายที่ยอมรับได้ เรียกว่าเป้าหมายจุดกู้คืน (RPO) และระยะเวลากู้บริการที่ยอมรับได้ เรียกว่าเป้าหมายเวลากู้คืน (RTO)
- แต่งตั้งผู้ดูแลและผู้แทนเมื่อไม่อยู่ บันทึกงบซื้อและงบดำเนินงานประจำ
จำนวนพนักงานเพียงอย่างเดียวบอกความจุไม่ได้ ชุดไฟล์ตัวแทนและงานที่ทำพร้อมกันเหมาะกับการทดสอบรับมอบมากกว่า
เปรียบเทียบการประกอบ ซื้อ และเช่า
เครื่องทาวเวอร์ข้างสวิตช์สำนักงานให้โอนไฟล์ในพื้นที่ได้แม้อินเทอร์เน็ตล่ม ตราบใดที่เครือข่ายท้องถิ่นและไฟฟ้ายังทำงาน เซิร์ฟเวอร์เช่าย้ายอุปกรณ์ไปที่อื่น ทำให้การเข้าถึงจากสำนักงานขึ้นกับ WAN ความรับผิดชอบของแต่ละทางแบ่งดังนี้
| แนวทาง | การประกอบและกรรมสิทธิ์ | สถานที่และสาธารณูปโภค | การเชื่อมระบบและการสนับสนุน | OS แอป การเข้าถึง และการกู้คืน |
|---|---|---|---|---|
| เลือกชิ้นส่วนประกอบเอง | คุณเลือก ประกอบ และเป็นเจ้าของชิ้นส่วน | คุณจัดหาไฟฟ้า การระบายความร้อน และเครือข่าย | คุณแก้ความเข้ากันได้ การรับประกันแยกตามชิ้นส่วน | คุณดูแลและสำรองข้อมูลบริการ |
| ซื้อเครื่องสำเร็จรูปหรือปรับสภาพ | ผู้จำหน่ายประกอบ คุณเป็นเจ้าของเครื่อง | คุณจัดหาสถานที่และเครือข่าย | การสนับสนุนระบบขึ้นกับการรับประกันและสัญญาจริง | คุณดูแลเอง เว้นแต่มีบริการอื่นครอบคลุม |
| เช่าเซิร์ฟเวอร์เฉพาะ | ผู้ให้บริการจัดหาเซิร์ฟเวอร์จริงทั้งเครื่อง | ผู้ให้บริการดำเนินงานสถานที่โฮสต์ | การเปลี่ยนฮาร์ดแวร์และการตอบสนองขึ้นกับสัญญา | OS แอป และการกู้คืนแบบดูแลเองยังเป็นหน้าที่คุณ |
| เช่า VPS | ผู้ให้บริการจัดสรรทรัพยากรบนโฮสต์ | ผู้ให้บริการดูแลโครงสร้างพื้นฐานจริง | การสนับสนุนโฮสต์ต่างจากการสนับสนุนภายใน VPS | OS เกสต์ แอป และการกู้คืนแบบดูแลเองยังเป็นหน้าที่คุณ |
เลือกประกอบเองเมื่อความยืดหยุ่นในการเลือกชิ้นส่วนมีประโยชน์และมีคนวิเคราะห์ปัญหาทั้งเครื่องได้ เลือกเครื่องสำเร็จรูปที่มีการสนับสนุนเมื่อกระบวนการซ่อมจากผู้จำหน่ายรายเดียวคุ้มกับเงินซื้อที่เพิ่มขึ้น สำหรับเครื่องปรับสภาพ ตรวจการสนับสนุนเฟิร์มแวร์ การสึกหรอไดรฟ์ ถาดและสายที่ให้มา เสียง กำลังไฟ และการรับประกันเป็นลายลักษณ์อักษรก่อนจ่ายเงิน
สำหรับการเช่า การเลือก VPS เทียบกับฮาร์ดแวร์เฉพาะ เป็นเรื่องทรัพยากรและการแยกสภาพแวดล้อม แอปเล็กอาจเหมาะกับ VPS ส่วนความต้องการต่อเนื่องหรือการควบคุมฮาร์ดแวร์อาจทำให้เซิร์ฟเวอร์เฉพาะคุ้มกว่า คอร์จริงกับ vCPU ของ VPS ไม่ใช่คำรับรองความสามารถที่ใช้แทนกันได้
พิจารณา VPS ก่อนตัดสินใจประกอบเซิร์ฟเวอร์เอง

การซื้อฮาร์ดแวร์คือการลงทุนก่อนรู้ว่าภาระงานจริงจะเป็นอย่างไร การประกอบเองเพิ่มงานตรวจความเข้ากันได้และงานประกอบ เครื่องสำเร็จรูปตัดขั้นตอนนั้น แต่ยังต้องมีพื้นที่ ไฟฟ้า การระบายความร้อน และแผนรับมือฮาร์ดแวร์เสีย สำหรับเว็บไซต์ แอป หรือสภาพแวดล้อมทดสอบที่ไม่ต้องทำงานในสำนักงาน การเช่าช่วยให้เริ่มได้เร็วและเรียนรู้ความต้องการจริง
แพ็กเกจ Linux VPS ของเรามี RAM DDR5 สตอเรจ NVMe ที่รวดเร็ว และการเชื่อมต่อผ่านอัปลิงก์โฮสต์ 40 Gbps สำหรับงานที่ต้องใช้กำลัง vCPU แบบเฉพาะ แพ็กเกจ High Performance จะสำรองกำลังนั้นให้เซิร์ฟเวอร์เสมือนของคุณ ใช้โครงสร้างพื้นฐานที่มีประสิทธิภาพได้โดยไม่ต้องซื้อฮาร์ดแวร์หรือโฮสต์บริการสาธารณะผ่านอินเทอร์เน็ตสำนักงาน
คุณยังควบคุมซอฟต์แวร์ได้ VPS ของเราเป็นแบบไม่จัดการ พร้อม สิทธิ์ root เต็มรูปแบบผ่าน SSH คุณเลือกระบบปฏิบัติการ ติดตั้งแอป และตั้งค่าบริการเอง การอัปเดต ความปลอดภัย และการสำรองข้อมูลยังเป็นความรับผิดชอบของคุณ จึงได้ประสบการณ์จริงของงานดูแลที่เซิร์ฟเวอร์ของคุณต้องใช้
การคิดค่าบริการรายชั่วโมงช่วยให้เริ่มจากทรัพยากรไม่มากได้ ในแพ็กเกจ PAYG คุณ ปรับขนาดจากแดชบอร์ด ได้เมื่อความต้องการเปลี่ยน ส่วนการตรวจทรัพยากรฟรีช่วยติดตามการใช้งาน การรับประกันคืนเงิน 14 วัน ให้ลูกค้าใหม่มีเวลาสองสัปดาห์ประเมินบริการและขอคืนเงินตามเงื่อนไขหากไม่เหมาะสม
การเช่ายังเปิดทางให้เป็นเจ้าของในอนาคต หากภายหลังสร้างเซิร์ฟเวอร์ Linux จริง คุณติดตั้งชุดซอฟต์แวร์ใหม่ โอนไฟล์และข้อมูลส่งออกฐานข้อมูล ปรับการตั้งค่า และทดสอบทุกอย่างก่อนสลับใช้งานได้ ประสบการณ์ดูแล VPS นำมาใช้ในการย้ายครั้งนั้นได้
จับคู่การตั้งค่ากับภาระงาน
ไฟล์สำนักงานและเอกสารร่วมกัน
สมมติว่ามีเอกสารทั่วไปประมาณ 2 TB เข้าถึงในพื้นที่ผ่าน Ethernet แบบสาย เริ่มวางแผนจากทาวเวอร์เสียงเบาที่มี CPU สมัยใหม่ 4–6 คอร์ RAM ที่รองรับ 32 GB SSD บูต 500 GB และ HDD 4 TB สองลูกเป็นมิเรอร์ข้อมูล Linux software RAID1 มิเรอร์มีความจุดิบประมาณไดรฟ์ 4 TB หนึ่งลูกก่อนหักส่วนเกินระบบไฟล์และพื้นที่สำรอง SSD บูตยังเป็นจุดล้มเหลวเดียว
ใช้ gigabit Ethernet ตลอดเซิร์ฟเวอร์ สวิตช์ และไคลเอนต์ พร้อม UPS ที่เข้ากันได้ จัดดิสก์สำรองถอดได้ 8 TB แยกต่างหากและสำเนานอกสถานที่ที่ป้องกันอย่างเป็นอิสระ เวอร์ชันและไฟล์ที่เพิ่มอาจเกินดิสก์ จึงต้องวัดปริมาณการเปลี่ยนแปลงและขนาดสำรองที่เก็บไว้ แบบนี้ไม่ได้รับรองอัตรารับส่งสำหรับตัดต่อวิดีโอ
งบตัวอย่าง 1,200–1,800 ดอลลาร์สหรัฐครอบคลุมฮาร์ดแวร์ UPS และอุปกรณ์สำรองในพื้นที่ ไม่รวมภาษี แรงงาน ใบอนุญาต และค่านอกสถานที่ การติดตั้งด้านล่างทำตามสถานการณ์ไฟล์สำนักงานนี้
เว็บไซต์สาธารณะหรือแอปขนาดเบา
สมมติฐานข้อมูลเล็กและสื่อไม่มาก โดยข้อมูลทำงานเริ่มต้นต่ำกว่า 20 GB ประเมินการเช่าทั่วไปที่ 2–4 vCPU RAM 4–8 GB และ SSD 80–160 GB โดยเหลือที่ให้ OS บันทึก และการเติบโต ต้องทดสอบโหลดเฉพาะแอป การจัดสรรนี้ไม่ได้บอกจำนวนผู้เข้าชมที่รองรับ
ทางเลือกเครื่องจริงอาจใช้ CPU สมัยใหม่ 4–6 คอร์ RAM 16 GB และ SSD 500 GB หนึ่งลูก หลังฟอร์แมตและ OS พื้นที่จะน้อยกว่าฉลาก และไม่มีดิสก์สำรองซ้ำซ้อน รวมการเชื่อมต่อแบบสาย UPS และเป้าหมายสำรองอิสระในงบฮาร์ดแวร์สมมติ 800–1,400 ดอลลาร์สหรัฐ โดยมีรายการไม่รวมเหมือนข้างต้น
การโฮสต์สาธารณะจากสำนักงานยังต้องมีแบนด์วิดท์อัปโหลด ที่อยู่ และเงื่อนไขผู้ให้บริการเหมาะสม วางแผนแพตช์ ความพร้อมไฟฟ้า และการดูแลแอป นี่เป็นการตัดสินใจติดตั้งแยกต่างหาก การตั้งค่าแชร์ไฟล์ด้านล่างไม่ติดตั้งชุดเว็บสาธารณะ
บริการภายในและสภาพแวดล้อมทดสอบที่แยกกัน
สมมติบริการแยกหลายตัวมีข้อมูลใช้งานรวมต่ำกว่า 400 GB โฮสต์ตัวอย่างมี CPU สมัยใหม่ 8 คอร์ RAM ที่เข้ากันได้ 64 GB และ SSD 1 TB แบบมิเรอร์ พร้อมอุปกรณ์บูตแยกหากแพลตฟอร์มกำหนด จึงมีข้อมูลดิบประมาณ 1 TB ก่อนหักส่วนเกิน ทุกดิสก์เกสต์ใช้พูลร่วมนี้
จัด RAM เกสต์เป็น 8 + 8 + 16 GB และให้โฮสต์กับสตอเรจ 8 GB รวมจัดสรร 40 GB เหลือ 24 GB วิธีนี้ตามการนับโฮสต์รวมเกสต์ใน ข้อกำหนด Proxmox แต่ไม่ได้พิสูจน์ประสิทธิภาพ CPU หรือความหนาแน่นเกสต์ที่รองรับ ตรวจ VT/AMD-V ไดรเวอร์ และใบอนุญาตเกสต์ การส่งผ่านอุปกรณ์ต้องพิจารณา IOMMU ด้วย อย่าใช้ ZFS บน hardware RAID
ใช้เครือข่ายแบบสาย UPS และการสำรองเกสต์อิสระ งบสมมติ 1,800–3,000 ดอลลาร์สหรัฐรวมฮาร์ดแวร์ UPS และอุปกรณ์สำรองในพื้นที่ ไม่รวมภาษี ใบอนุญาต แรงงาน และค่านอกสถานที่ การจำลองเสมือนเซิร์ฟเวอร์ แยกสภาพแวดล้อมเกสต์ แต่โฮสต์จริงตัวเดียวยังเป็นจุดล้มเหลวเดียว
เลือกชิ้นส่วนเซิร์ฟเวอร์ที่เข้ากันได้

โปรเซสเซอร์อาจใส่ซ็อกเก็ตได้แต่ยังต้องใช้ BIOS รุ่นอื่นก่อนบอร์ดบูต สร้างตารางความเข้ากันได้ตามรุ่นเมนบอร์ดที่แน่นอน แล้วตรวจชิ้นส่วนที่เชื่อมต่อทุกชิ้นกับคู่มือ การตรวจนี้ใช้กับการตั้งค่าข้างต้นด้วย แต่ไม่มีชุดใดเป็นรายการซื้อที่ผ่านการตรวจรับรอง
CPU
เลือกกำลังประมวลผลตามแอป งานที่ติดข้อจำกัดจากเธรดเดียวที่ยุ่งได้ประโยชน์ต่างจากซอฟต์แวร์กระจายงานข้ามคอร์ การให้บริการไฟล์ยังขึ้นกับดิสก์และเครือข่าย CPU ราคาแพงจึงอาจไม่แก้คอขวดเดิม
จับคู่ซ็อกเก็ตและชิปเซ็ต แล้วหาชื่อโปรเซสเซอร์ตรงรุ่นในรายการ CPU ที่บอร์ดรองรับและจด BIOS ที่ต้องใช้ ขั้นตอนตรวจความเข้ากันได้ CPU และหน่วยความจำ ของ ASUS บอกตำแหน่งรายการเหล่านั้น ถามผู้ขายว่า BIOS ที่ให้มาบูต CPU ที่เลือกได้หรือไม่ และตรวจว่าการติดตั้งต้องใช้กราฟิกในตัวหรือจอการจัดการบอร์ดหรือไม่
RAM
ความจุต้องพอสำหรับ OS และแอปที่ทำงานพร้อมกันพร้อมเผื่อการเติบโต ตรวจรุ่น DDR ที่รองรับ ความจุสูงสุด จำนวนสล็อต และลำดับใส่ตามคู่มือ การซื้อชุดเริ่มต้นทั้งชุดจากรายการหน่วยความจำที่บอร์ดรับรองลดจำนวนชุดผสมที่คุณต้องแก้เอง
UDIMM คือหน่วยความจำไม่บัฟเฟอร์ ส่วน RDIMM คือหน่วยความจำแบบลงทะเบียน เป็นโมดูลคนละประเภท และ ECC อย่างเดียวไม่ได้ยืนยันความเข้ากันได้ คำถามพบบ่อยเรื่องความเข้ากันได้ของหน่วยความจำลงทะเบียน ของ Supermicro ระบุชัดว่าตระกูล X11SCA ที่กล่าวถึงไม่รองรับ DIMM ลงทะเบียน หากต้องการ ECC ให้ยืนยันทั้ง CPU บอร์ด และโมดูล รักษาทางขยายที่ไม่ต้องทิ้งโมดูลที่ติดตั้งทั้งหมด
พื้นที่จัดเก็บ
แยกอุปกรณ์ OS ออกจากข้อมูลธุรกิจหากทำให้การซ่อมและกู้คืนชัดเจนขึ้น SSD เหมาะกับงานไวต่อการตอบสนองสตอเรจ ส่วน HDD ให้พื้นที่สำหรับเอกสารทั่วไป ทั้งสองแบบควรตรวจงานที่ไดรฟ์ออกแบบไว้ การรับประกัน ข้อมูลความทน และอะไหล่ทดแทนก่อนเลือกจากความจุเพียงอย่างเดียว
RAID1 เก็บข้อมูลมิเรอร์บนไดรฟ์คู่ ทนการเสียของสมาชิกหนึ่งลูกได้ แต่การลบ แรนซัมแวร์ และการสูญเสียสถานที่ยังต้องใช้แบ็กอัปอิสระ ยืนยันความจุหลังฟอร์แมตและเหลือพื้นที่เติบโต จับคู่อินเทอร์เฟซ SATA หรือ NVMe ขนาดไดรฟ์ เบย์ และสาย ตรวจว่าการใช้สล็อต M.2 ปิดพอร์ต SATA ที่ดิสก์ข้อมูลต้องใช้หรือไม่
เมนบอร์ด
เมื่อบันทึกความเข้ากันได้ CPU/BIOS และรายการผู้ขายหน่วยความจำที่ผ่านการรับรอง (QVL) แล้ว ตรวจ Linux รองรับเครือข่ายและตัวควบคุมสตอเรจบนบอร์ด โดยเฉพาะแพลตฟอร์มใหม่
นับขั้ว SATA ซ็อกเก็ต M.2 สล็อต PCIe และหัวต่อพัดลมที่จะใช้ อ่านตารางแชร์เลน เพราะ SSD หรือการ์ดขยายที่ติดตั้งอาจลดการเชื่อมต่อของอีกสล็อต จับคู่ฟอร์มแฟกเตอร์และรูยึดบอร์ดกับเคส การจัดการระยะไกลช่วยเมื่อไม่มีจอใกล้เครื่อง แต่ต้องมีทางเข้าที่ป้องกันและการบำรุงเฟิร์มแวร์ด้วย
อินเทอร์เฟซเครือข่าย
การ์ดเครือข่ายเร็วขึ้นไม่ทำให้สวิตช์ การเชื่อมต่อไคลเอนต์ หรือสตอเรจที่ช้ากว่าเร็วขึ้น ตรวจเส้นทางทั้งหมดก่อนจ่ายอัปเกรด ใช้ลิงก์ gigabit ในตัวอย่างไฟล์สำนักงานเป็นทางเลือกวางแผน แล้วทดสอบคัดลอกพร้อมกันด้วยไฟล์ตัวแทน
ยืนยันว่ามีไดรเวอร์อินเทอร์เฟซสำหรับ Linux รุ่นที่เลือก การ์ดเพิ่มต้องมีสล็อต PCIe ช่องว่าง และการเชื่อมต่อที่รองรับ รวมพอร์ตสวิตช์และสายในการตรวจซื้อ เพราะมีผลต่อการตัดสินใจอัตรารับส่งร่วมกับ NIC เซิร์ฟเวอร์
แหล่งจ่ายไฟ
เลือก PSU ที่พอดีเคสและจ่ายไฟให้เมนบอร์ด CPU และไดรฟ์ผ่านขั้วที่ต้องใช้ ประเมินโหลดรวมความต้องการขณะเริ่มและการขยายตามแผน เผื่อกำลังตามคำแนะนำผู้ผลิตชิ้นส่วน ตัวเลขวัตต์สูงอย่างเดียวบอกความเหมาะสมได้น้อย
ตรวจขั้วไฟหลักและ CPU ของบอร์ด ปลั๊กไฟไดรฟ์ และระยะสาย สำหรับ PSU แบบโมดูลาร์ ใช้สายที่ให้มาหรืออนุมัติชัดเจนสำหรับรุ่นนั้นเท่านั้น ตรวจอะไหล่ทดแทนหากเคสใช้แหล่งจ่ายไฟเฉพาะ
การทำความเย็น
จับคู่คูลเลอร์ CPU กับซ็อกเก็ต ขีดจำกัดกำลังโปรเซสเซอร์ และช่องว่างเคส โมดูลหน่วยความจำสูงอาจชนคูลเลอร์ด้วย ยืนยันว่ามีชุดติดตั้ง และทำตามคำแนะนำเรื่องสารนำความร้อนและลำดับขัน
วางทางลมโล่งผ่านบริเวณไดรฟ์และเคส เพิ่มพัดลมไม่แก้ทางลมอุดตันหรือตู้ที่กักลมร้อน ตรวจพิกัดหัวต่อพัดลมและค่าควบคุมในคู่มือ หลังประกอบ ตรวจอุณหภูมิระหว่างงานตัวแทนและปรับการระบายความร้อนก่อนใช้งานจริง
เคส
ทาวเวอร์เสียงเบาวางในสำนักงานง่ายกว่าอุปกรณ์สำหรับห้องเครื่องแยก ตรวจขนาดบอร์ด ความสูงคูลเลอร์ เบย์ไดรฟ์ และความยาวการ์ดขยาย นับเบย์สำหรับอุปกรณ์บูต ดิสก์ข้อมูลเริ่มต้น และแผนเปลี่ยนหรือขยายที่เป็นจริง
ตรวจว่ามีถาดไดรฟ์ สกรู และสายหรือไม่ เหลือพื้นที่เปลี่ยนดิสก์โดยไม่รื้อเครื่อง วางเคสให้ทำความสะอาดและซ่อมได้สะดวก ช่องลมไม่ถูกบัง และป้องกันการชนหรือสายหลุดโดยบังเอิญ
UPS
UPS ให้เวลาเซิร์ฟเวอร์ปิดอย่างถูกต้องเมื่อไฟดับ เลือกตามโหลดคาดการณ์ ข้อมูลระยะทำงานผู้ผลิต และการสื่อสารสั่งปิดที่เข้ากับ Linux พิกัดวัตต์กับเวลาสำรองแบตเตอรี่ตอบคนละคำถาม
รวมสวิตช์เครือข่ายหากต้องรักษาการเชื่อมต่อในพื้นที่ขณะไฟดับ วางแผนเปลี่ยนแบตเตอรี่และทดสอบปิดอย่างถูกต้องตามขั้นตอนผู้ผลิต อย่าคิดว่า UPS จะทำให้สำนักงานทำงานผ่านไฟดับยาวได้ งานเหล่านี้ไม่ต้องใช้ GPU เว้นแต่มีแอปเฉพาะกำหนด
ก่อนสั่งซื้อ บันทึกหลักฐานข้างชิ้นส่วนที่วางแผนไว้:
| ตรวจสอบ | บันทึกก่อนซื้อ |
|---|---|
| CPU และ RAM | รายการรองรับ ข้อกำหนด BIOS ประเภทโมดูล และลำดับสล็อต |
| สตอเรจและการขยาย | พอร์ตและเบย์ที่มี และข้อจำกัดแชร์เลน |
| ความพอดีเชิงกล | รูบอร์ด ความสูงคูลเลอร์ และช่องว่างการ์ด |
| ไฟฟ้าและการกู้คืน | ขั้วถูกต้อง การรองรับสั่งปิดจาก UPS และเป้าหมายแบ็กอัป |
ประกอบและตรวจฮาร์ดแวร์
สแตนด์ออฟผิดตำแหน่งอาจแตะหลังบอร์ดจนเสียหาย ทำตามคู่มือรุ่นนั้นขณะถอดไฟ ลำดับด้านล่างเป็นการประกอบทั่วไป ไม่แทนภาพในคู่มือ
- ตรวจนับชิ้นส่วนและเครื่องมือ ยืนยัน CPU ที่รองรับและ BIOS ก่อนเปิดซ็อกเก็ต เก็บบรรจุภัณฑ์และหมายเลขประจำเครื่องไว้เคลมประกัน
- เตรียมเคส ใส่เฉพาะสแตนด์ออฟตรงรูบอร์ดและถอดตัวเกิน คำแนะนำติดตั้งเมนบอร์ด ของ ASUS อธิบายอันตรายจากสแตนด์ออฟเกิน ใส่แผ่น I/O แยกหากบอร์ดต้องใช้
- ติดตั้ง CPU ตามเครื่องหมายตรงแนวโดยไม่ฝืน ทำตามกลไกล็อกซ็อกเก็ต คำแนะนำติดตั้ง CPU ของผู้ผลิตกำหนดให้ถอดสายไฟระบบก่อน ติดคูลเลอร์ตามสารและวิธียึดที่กำหนด แล้วต่อพัดลม CPU
- ใส่ RAM ในสล็อตเริ่มต้นตามคู่มือจนกลไกยึดเข้าที่ ติดตั้ง M.2 ก่อนเข้าถึงได้ยาก
- ยึดเมนบอร์ดและ PSU ติดไดรฟ์บูตและข้อมูล แล้วต่อสายข้อมูลและไฟ ติดการ์ดเครือข่ายที่ต้องใช้
- ต่อไฟเมนบอร์ด/CPU พัดลมเคส และสายแผงหน้าตามคู่มือ จัดสายให้พ้นพัดลม ตรวจสกรูหลวม สายไม่ยึด และขั้วเสียบไม่สุดก่อนจ่ายไฟ
เมื่อเปิดครั้งแรก รอการทดสอบตนเองตอนเปิด (POST) จบ เข้า UEFI ตรวจ CPU ที่พบ หน่วยความจำรวม ทุกไดรฟ์ พัดลม และอุณหภูมิ แก้อุปกรณ์หายหรือความร้อนผิดปกติก่อนติดซอฟต์แวร์ หากต้องอัปเดตเฟิร์มแวร์ ทำตามขั้นตอนผู้ผลิตบอร์ดอย่างเคร่งครัดด้วยไฟฟ้าที่เสถียร
รันการวินิจฉัยฮาร์ดแวร์ที่ผู้ขายมีและทดสอบหน่วยความจำเหมาะกับแพลตฟอร์ม หลังติดตั้ง คัดลอกเอกสารตัวแทนและทดลองงานปกติพร้อมกัน บันทึกข้อผิดพลาด อุณหภูมิ และเวลาจบเป็นหลักฐานรับมอบของคุณ เบนช์มาร์กเครื่องว่างไม่บอกว่างานสำนักงานจะทำได้จริง
ติดตั้ง Ubuntu และเปิดบริการแชร์ไฟล์
การตั้งค่าไฟล์สำนักงานจะเปิดแชร์แบบยืนยันตัวตนชื่อ business หนึ่งรายการบน LAN ใช้ Ubuntu Server 24.04 LTS amd64 บนฮาร์ดแวร์ที่รองรับ บันทึกประจำรุ่น ระบุการบำรุงรักษาถึงพฤษภาคม 2029 เตรียมคอนโซลในพื้นที่ไว้ระหว่างเปลี่ยนเครือข่าย
ติดตั้ง OS และเมานต์สตอเรจข้อมูล

ดาวน์โหลดอิมเมจติดตั้งเซิร์ฟเวอร์ 24.04 ปัจจุบันจาก Ubuntu และทำตาม ขั้นตอนตรวจอิมเมจที่มีลายเซ็น ของ Canonical ก่อนสร้าง USB ขั้นตอนนี้ตรวจทั้งลายเซ็นเช็กซัมและเช็กซัมอิมเมจ อย่าคัดลอกแฮชจากการดาวน์โหลดอื่นที่ไม่เกี่ยวข้อง
ถอดดิสก์แบ็กอัปอิสระไว้ บูตตัวติดตั้งและระบุดิสก์ภายในจากรุ่น ซีเรียล และความจุ ใน custom storage วางพาร์ทิชันบูต EFI และระบบไฟล์ราก OS บน SSD บูต ใช้ HDD ข้อมูลว่างสองลูกสร้าง software MD RAID1 ฟอร์แมต ext4 และเมานต์ที่ /srv/business คำแนะนำตั้งค่าสตอเรจ ของ Canonical ครอบคลุมการสร้างและเมานต์อุปกรณ์ MD
ตรวจผังสุดท้ายก่อนยืนยันลบ SSD บูตควรมี OS อุปกรณ์ข้อมูลมิเรอร์ควรมี /srv/business และต้องไม่เห็นดิสก์แบ็กอัป สร้างผู้ดูแลรายบุคคลระหว่างติดตั้ง หลังรีบูตตรวจผัง:
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
findmnt --mountpoint /srv/business
cat /proc/mdstat
ยืนยันว่า /srv/business เป็น ext4 ที่เมานต์บน MD ที่ตั้งใจ และสมาชิกมิเรอร์ทั้งสองอยู่ครบและปกติ รอซิงก์แรกจบก่อนทดสอบรับมอบ หยุดหากไม่ได้เมานต์ ไม่เช่นนั้นการสร้างไดเรกทอรีตรงนั้นจะวางไฟล์ธุรกิจบนระบบไฟล์บูต
จำกัดการดูแลและการเข้าถึงเครือข่าย
จองที่อยู่เซิร์ฟเวอร์ใน DHCP ของเราเตอร์ ตัวอย่างใช้เซิร์ฟเวอร์ 192.168.10.10 ซับเน็ตสำนักงาน 192.168.10.0/24 และไคลเอนต์ผู้ดูแล 192.168.10.20 เปลี่ยนเป็นค่าของคุณ ตรวจ LAN เราเตอร์และที่อยู่/เน็ตมาสก์ไคลเอนต์ /24 อธิบายช่วงที่อยู่ของตัวอย่าง ไม่ใช่ทุกเครือข่ายสำนักงาน การเข้าถึงไฟล์ในพื้นที่ไม่ต้องใช้ IP สาธารณะหรือ DNS ที่ซื้อ
อัปเดตและติดตั้งแพ็กเกจ:
sudo apt update
sudo apt upgrade
sudo apt install samba smbclient restic ufw
หากต้องดูแลระยะไกล ติดตั้ง openssh-server ตั้งคีย์ SSH ผู้ดูแล และพิสูจน์ว่าใช้ได้ในเซสชันที่สอง เก็บล็อกอินแรกไว้ คำแนะนำ OpenSSH ของ Canonical มีการตั้งคีย์และตรวจการตั้งค่า รัน sudo sshd -t หลังแก้ SSH ทุกครั้ง และคงทางเข้ารหัสผ่านไว้จนล็อกอินด้วยคีย์ใหม่ได้
หากใช้ SSH เปลี่ยนที่อยู่และพอร์ต SSH จริงในกฎอนุญาตแรกก่อนเปิด UFW ถ้าดูแลผ่านคอนโซลเท่านั้น ให้ละกฎนั้น คำแนะนำไฟร์วอลล์ ของ Canonical ครอบคลุมการจำกัดตามต้นทาง:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 192.168.10.20 to any port 22
sudo ufw allow proto tcp from 192.168.10.0/24 to any port 445
sudo ufw enable
sudo ufw status verbose
ทดสอบการเชื่อมต่อผู้ดูแลอีกครั้ง พอร์ต 445 ใช้สำหรับไฟล์ SMB นี้ อย่าฟอร์เวิร์ดผ่านเราเตอร์อินเทอร์เน็ต ให้ Wi-Fi แขกอยู่บนเครือข่ายแยกที่เข้าบริการสำนักงานไม่ได้ กฎอนุญาตซับเน็ตแยกพนักงานที่ไว้ใจกับแขกบนซับเน็ตเดียวกันไม่ได้
สร้างแชร์ไฟล์แบบยืนยันตัวตน
ให้พนักงานทุกคนมีตัวตน Linux และข้อมูลรับรอง Samba แยกกัน คำแนะนำควบคุมสิทธิ์ Samba ของ Ubuntu กำหนดให้มีบัญชี Linux ก่อนลงทะเบียน สำหรับบัญชีพนักงานใหม่ใช้ไฟล์อย่างเดียวชื่อ alex รัน:
sudo addgroup officefiles
sudo adduser --disabled-password --shell /usr/sbin/nologin alex
sudo adduser alex officefiles
sudo smbpasswd -a alex
sudo mkdir -p /srv/business/team
sudo chown root:officefiles /srv/business/team
sudo chmod 2770 /srv/business/team
sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.before-business
sudoedit /etc/samba/smb.conf
กรอกรหัสผ่าน Samba ของ Alex เมื่อถาม รหัสผ่าน Linux ที่ปิดและเชลล์ nologin แยกบัญชีจากการล็อกอินผู้ดูแล อย่าเพิ่มใน sudo ทำขั้นตอนบัญชี สมาชิกกลุ่ม และ Samba ซ้ำสำหรับแต่ละคน สร้าง officefiles เพียงครั้งเดียว
โหมด 2770 อนุญาตเจ้าของและกลุ่ม ปฏิเสธผู้อื่น และตั้ง setgid เพื่อให้รายการใหม่สืบทอดกลุ่มไดเรกทอรี กฎ Samba และสิทธิ์ระบบไฟล์ Linux ต้องอนุญาตทั้งคู่ คงการตั้งค่ารวมและเพิ่มแชร์นี้รายการเดียว:
[business]
path = /srv/business/team
browseable = yes
guest ok = no
read only = no
valid users = @officefiles
force group = officefiles
create mask = 0660
force create mode = 0660
directory mask = 2770
force directory mode = 2770
@officefiles จำกัดสิทธิ์เฉพาะสมาชิกกลุ่ม force group ทำให้การทำงานแชร์อยู่ในกลุ่มนั้น mask จำกัดสิทธิ์ไฟล์/ไดเรกทอรีใหม่ตาม เอกสารอ้างอิงตั้งค่า Samba ของ Ubuntu ตรวจและเปิดบริการ:
sudo testparm -s
sudo systemctl restart smbd
sudo systemctl status smbd --no-pager
แก้ข้อผิดพลาดการตั้งค่าก่อนรีสตาร์ต การตรวจไวยากรณ์ยืนยันว่า Samba โหลดค่าได้ ส่วนการทดสอบไคลเอนต์ถัดไปยืนยันว่าบริการใช้ได้จริง
ตรวจสอบจากไคลเอนต์
บน Windows อีกเครื่องใน LAN ที่อนุญาต เปิด \\192.168.10.10\business ใน File Explorer เข้าด้วย alex และรหัส Samba สร้าง acceptance.txt เขียนประโยคสั้น ปิดแล้วเปิดใหม่ ลงทะเบียนพนักงานอีกคนและยืนยันว่าข้อมูลรับรองของเขาแก้ไฟล์ทดสอบทีมได้
จาก Linux ไคลเอนต์ที่ติดตั้ง smbclient เชื่อมต่อได้ด้วย:
smbclient //192.168.10.10/business -U alex
กรอกรหัสผ่านเมื่อถาม ทดสอบด้วยข้อมูลรับรองผิดและแขกไม่ยืนยันตัวตน ทั้งสองต้องอ่านหรือสร้างไฟล์ไม่ได้ บน Windows ให้ตัดการเชื่อมต่อแชร์เดิมและล้างข้อมูลรับรองแคชก่อนทดสอบตัวตนที่ควรถูกปฏิเสธ มิฉะนั้นอาจยังใช้เซสชันที่เข้าได้
ถ้าเชื่อมต่อหมดเวลา ยืนยันที่อยู่เซิร์ฟเวอร์และเส้นทาง LAN ตรวจต้นทาง/พอร์ต UFW และสถานะ smbd ถ้ายืนยันตัวตนหรือเขียนไม่ได้ ตรวจการลงทะเบียน Samba, id alex และ ls -ld /srv/business/team ยืนยันสมาชิกกลุ่มและเจ้าของไดเรกทอรี คงการปิดแขกไว้ และอย่าเปิดเขียนให้ทุกคนเพื่อแก้ปัญหาลัด
งบประมาณสำหรับการเป็นเจ้าของและการเช่า
สมมติเริ่มเป็นเจ้าของด้วยเซิร์ฟเวอร์ 1,500 ดอลลาร์ UPS 200 ดอลลาร์ และอุปกรณ์แบ็กอัปในพื้นที่ 300 ดอลลาร์ นี่เป็นข้อมูลโมเดลแยก ไม่ใช่รายละเอียดงบสถานการณ์ก่อนหน้า สมมติกำลังเฉลี่ยจากปลั๊ก 100 W และไฟฟ้า 0.15 ดอลลาร์/kWh:
100 / 1000 × 24 × 365 × 3 × 0.15 = $394.20
ทั้งกำลังไฟและอัตราไม่ใช่ค่าที่วัด จัดงานผู้ดูแลให้ทั้งสองแบบดูแลเองเดือนละ 2 ชั่วโมง ชั่วโมงละ 25 ดอลลาร์ และแบ็กอัปนอกสถานที่อิสระเดือนละ 10 ดอลลาร์:
| ค่าใช้จ่ายสมมติ 36 เดือน | เป็นเจ้าของ | เช่า |
|---|---|---|
| ฮาร์ดแวร์ UPS และอุปกรณ์แบ็กอัปในพื้นที่ | $2,000.00 | สมมติใช้ฮาร์ดแวร์และสถานที่ผู้ให้บริการ |
| ค่าเช่า | – | $1,080.00 |
| ค่าไฟเซิร์ฟเวอร์ในพื้นที่ | $394.20 | รวมในค่าเช่าสมมติ |
| แบ็กอัปนอกสถานที่อิสระ | $360.00 | $360.00 |
| รวมย่อยเงินสด | $2,754.20 | $1,440.00 |
| ค่าดูแลที่คิดรวม | $1,800.00 | $1,800.00 |
| รวมค่าแรงที่จัดสรร | $4,554.20 | $3,240.00 |
ฝั่งเช่าไม่ได้สมมติอุปกรณ์แบ็กอัปในพื้นที่แยก แบ็กอัปนอกสถานที่อิสระมีบรรทัดของตนในทั้งสองแบบ
สำรอง กู้คืน และส่งมอบบริการ
กู้ acceptance.txt และการตั้งค่า Samba ก่อนนำไฟล์ธุรกิจใช้งาน ใช้ดิสก์ภายนอกที่เมานต์แยก มีระบบไฟล์เดิมและพื้นที่ว่างพอ แล้วเก็บสำเนาที่สองนอกสถานที่ซึ่งป้องกันอิสระ คำสั่งต่อไปนี้ไม่เตรียมหรือลบดิสก์
เมานต์ดิสก์สำรองที่ /media/business-backup ตรวจ findmnt และ lsblk ว่าเป็นอุปกรณ์ภายนอกที่ตั้งใจ ไม่ใช่ไดเรกทอรีบนสตอเรจภายใน เริ่มเชลล์สิทธิ์สูงเพื่อให้ restic อ่านแชร์และการตั้งค่า:
sudo -i
findmnt --mountpoint /media/business-backup
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
หลังยืนยันอุปกรณ์ เริ่มคลังและสำรอง ลำดับ && หยุดเมื่อขั้นตอนล้มเหลว รวมถึงไม่มีการเมานต์:
findmnt --mountpoint /media/business-backup &&
restic -r /media/business-backup/restic init &&
restic -r /media/business-backup/restic backup /srv/business /etc/samba &&
restic -r /media/business-backup/restic snapshots &&
restic -r /media/business-backup/restic check
เริ่มคลังใหม่เพียงครั้งเดียว Restic ถามรหัสผ่านคลัง ให้เก็บแยกในที่เก็บข้อมูลรับรองธุรกิจ ขั้นตอนเริ่มใช้งาน ของ Restic ครอบคลุมงานคลังเหล่านี้ ถ้าตรวจเมานต์ไม่ผ่าน ให้หยุดแทนการปล่อยให้สร้างคลังบนดิสก์โฮสต์
อย่าเปลี่ยนเอกสารทดสอบระหว่างฝึก ในเชลล์ root เดิม กู้เฉพาะไฟล์นั้นและการตั้งค่า Samba ไปยังไดเรกทอรี /srv/restore-check ใหม่ที่ว่าง ให้มีพื้นที่เพียงพอกับรายการที่เลือก:
mkdir /srv/restore-check &&
restic -r /media/business-backup/restic restore latest --target /srv/restore-check --include /srv/business/team/acceptance.txt --include /etc/samba &&
cmp /srv/business/team/acceptance.txt /srv/restore-check/srv/business/team/acceptance.txt &&
cat /srv/restore-check/srv/business/team/acceptance.txt &&
testparm -s /srv/restore-check/etc/samba/smb.conf
exit
คำแนะนำกู้คืน ของ Restic อธิบายพาธเป้าหมายและการเขียนทับ cmp ควรไม่พบความต่าง ข้อความกู้คืนควรอ่านได้ และ testparm ควรยอมรับการตั้งค่ากู้คืน นี่ตรวจการกู้ไฟล์และการตั้งค่า ไม่ใช่การกู้ภัยพิบัติทั้งหมด
กำหนดสำรองทุกคืนหลังปิดไฟล์ เก็บสแนปช็อตรายวันเจ็ดชุดและรายสัปดาห์สี่ชุด ตรวจคลังทุกสัปดาห์และฝึกกู้ทุกเดือน การสำรองรายคืนเสี่ยงสูญเสียการเปลี่ยนแปลงราวหนึ่งวัน วัดเวลากู้ระหว่างฝึก ขั้นตอนเก็บรักษา ของ Restic ให้ตรวจการลบก่อนด้วย forget --keep-daily 7 --keep-weekly 4 --dry-run forget ลบการอ้างอิงสแนปช็อต ส่วน prune ลบข้อมูลสำรองที่ไม่ต้องใช้ ตรวจ dry-run ก่อนลบจริงทั้งสองแบบ สแนปช็อตที่เก็บไม่ได้พิสูจน์ว่างานที่พลาดเคยรัน
สำหรับอัตโนมัติ ป้องกันข้อมูลรับรองในไฟล์รหัสผ่านอ่านได้เฉพาะ root หรือคลังข้อมูลรับรอง ตรวจเมานต์ในงาน และเตือนผู้รับผิดชอบเมื่อล้มเหลว การหมุนเวียนดิสก์ต้องต่อดิสก์ถูกก่อนงาน ถอดภายหลัง และดูแลสำเนานอกสถานที่อิสระ
บันทึก ID บัญชี/กลุ่มและขั้นตอนลงทะเบียนพนักงาน โฮสต์ทดแทนต้องสร้างตัวตน Linux/Samba ใหม่ รักษาหรือแก้เจ้าของ กู้ไฟล์/การตั้งค่า และทดสอบไคลเอนต์อีกครั้ง สำรอง /etc/samba อย่างเดียวไม่คืนสถานะข้อมูลรับรองแยกของ Samba
ส่งมอบผู้รับผิดชอบและผู้แทน ช่วงอัปเดต/รีบูต ขั้นตอน UPS สั่งปิด และการตรวจพื้นที่ว่าง สุขภาพมิเรอร์ บันทึกบริการ และผลสำรอง บันทึกการกู้ไฟล์ที่สำเร็จและเวลาที่ใช้ในเอกสารส่งมอบก่อนรับบริการ
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา