- Ubicloud นำเซิร์ฟเวอร์ AX162 รุ่นใหม่ของ Hetzner มาใช้ เพราะดูดีกว่า AX161 ทั้งด้านประสิทธิภาพและราคา แต่ระหว่างใช้งานกลับพบปัญหาด้านความน่าเชื่อถือ โดยเกิดเหตุขัดข้อง บ่อยกว่า 16 เท่า
- การไล่หาสาเหตุเริ่มจาก system log ที่เหลือ NULL byte แล้วค่อย ๆ ตัดความเป็นไปได้เรื่องโหลด อุณหภูมิ ข้อมูลชิ้นส่วน และการใช้พลังงานออกไป โดยมี
sensors,dmidecodeและpowerstatเป็นเครื่องมือหลัก - จากข้อมูลช่วงแรก AX161 มีเหตุขัดข้อง 11 ครั้งตลอดระยะเวลาให้บริการ 3,784 วัน คิดเป็น AFR 1.06 ขณะที่ AX162 มีเหตุขัดข้อง 34 ครั้งใน 737 วัน และทำสถิติ AFR 16.84
- เซิร์ฟเวอร์ที่เคยล่มหนึ่งครั้งแล้ว 80% จะเจอเหตุขัดข้องครั้งที่สองภายใน 24 ชั่วโมง และ Hetzner แจ้งว่ามี ข้อบกพร่องในล็อตของเมนบอร์ด โดยไม่ได้ยืนยันว่ามีการจำกัดพลังงานหรือไม่
- AX162 -v3 ที่ย้ายไปใช้เมนบอร์ดรุ่นล่าสุด มีค่า AFR ลดลงเหลือ 0.39 หลังติดตามหลายเดือน และบทเรียนคือควรตรวจสอบฮาร์ดแวร์ใหม่แบบค่อยเป็นค่อยไป เริ่มจากงานที่ไม่สำคัญก่อน
AX162 ล่มซ้ำหลังเริ่มนำมาใช้งาน
- Ubicloud พัฒนาซอฟต์แวร์ที่เปลี่ยนผู้ให้บริการ bare metal ให้กลายเป็นคลาวด์แพลตฟอร์ม และใช้ Hetzner มาโดยตลอดในฐานะผู้ให้บริการเซิร์ฟเวอร์ที่ทั้งราคาถูกและเชื่อถือได้
- เซิร์ฟเวอร์สาย AX162 ของ Hetzner ให้ทั้งประสิทธิภาพที่ดีกว่าและราคาที่ต่ำกว่ารุ่นก่อนหน้า AX161 จึงถูกนำมาใช้ได้อย่างรวดเร็ว
- สามสัปดาห์หลังซื้อ AX162 เครื่องแรก เซิร์ฟเวอร์เครื่องหนึ่งก็ล่ม และใน system log มี NULL byte เหลืออยู่
- สิ่งนี้ถูกตีความว่าเป็นสัญญาณของความล้มเหลวแบบฉับพลัน คล้ายการสูญเสียไฟเลี้ยงที่ทำให้ไม่สามารถปิดงานเขียนข้อมูลได้อย่างปกติ
- การตรวจฮาร์ดแวร์ของ Hetzner ในตอนแรกไม่พบความผิดปกติ แต่หนึ่งสัปดาห์ต่อมาก็เกิดการล่มอีก และจากนั้นปัญหาก็เกิดซ้ำภายในเวลาไม่กี่วัน
รูปแบบที่ปัญหาเกิดขึ้น
- การล่มทั้งหมดเกิดขึ้นเฉพาะบน AX162 เท่านั้น
- ปัญหาแบ่งออกได้เป็นสองลักษณะ
- รีสตาร์ตด้วยตนเองแล้วเซิร์ฟเวอร์กลับมาออนไลน์ได้อีกครั้ง
- ไม่ตอบสนองทั้งต่อคำสั่งรีสตาร์ตและโค้ดวินิจฉัยจากวิศวกรของ Hetzner จนต้องเปลี่ยนเครื่อง
- โดยปกติเซิร์ฟเวอร์จะทำงานได้ตามปกติเป็นเวลานาน แต่หลังเกิดการล่มครั้งแรกแล้ว โอกาสที่จะล่มซ้ำจะสูงขึ้นมาก
- ยังพบรูปแบบว่าเมื่อการล่มแบบแรกเกิดซ้ำหลายครั้ง สุดท้ายมักลุกลามไปเป็นแบบที่สองและต้องเปลี่ยนเซิร์ฟเวอร์
ตัดประเด็นโหลดและอุณหภูมิออกก่อน
- AX162 มี 96 vCPU และ Ubicloud ก็มี workload ที่ใช้ทุก vCPU พร้อมกัน
- มีการตรวจสมมติฐานว่าโหลดสูงอาจทำให้อุณหภูมิสูงขึ้นหรือก่อปัญหาที่ไม่คาดคิด แต่ในช่วงที่เครื่องล่มก็พบว่าเหตุขัดข้องเกิดได้แม้มีโหลดต่ำหรือแทบไม่มีโหลดเลย
- เพื่อดูความสัมพันธ์ระหว่างอุณหภูมิกับการล่ม จึงเก็บอุณหภูมิขององค์ประกอบต่าง ๆ ในระบบด้วยคำสั่ง
sensors - มีการตั้ง cron job แบบง่าย ๆ เพื่อเก็บข้อมูลอุณหภูมิ และเมื่อกลับมาตรวจหลังเกิดการล่มอีกครั้ง ก็พบว่าอุณหภูมิไม่ได้สูงกว่าค่าเฉลี่ยอย่างมีนัยสำคัญ
ตรวจข้อมูลชิ้นส่วนและการใช้พลังงาน
- ใช้
lshwและdmidecodeเพื่อตรวจสอบรุ่นและหมายเลขซีเรียลของชิ้นส่วนฮาร์ดแวร์ - เมื่อนำชิ้นส่วนของ AX162 ที่ล่มมาเทียบกับเครื่องที่ไม่ล่ม ก็ไม่พบ ความแตกต่างที่มีนัยสำคัญ
- ยังตรวจลำดับการเพิ่มขึ้นของหมายเลขซีเรียลด้วย เพราะชิ้นส่วนที่เก่ากว่าอาจเสียบ่อยกว่า แต่ก็ยังพบการล่มในเครื่องที่มีหมายเลขซีเรียลใหม่ที่สุด
- ในการขยายดาต้าเซ็นเตอร์ ข้อจำกัดมักเป็นเรื่อง พลังงาน มากกว่าพื้นที่ และผู้ให้บริการอาจกำหนดเพดานการใช้ไฟต่อเครื่องไว้
- Ubicloud ไม่รู้ว่า Hetzner จำกัดการใช้พลังงานหรือไม่ แต่เห็นว่าอาการที่ทำงานได้เสถียรเป็นเวลานานก่อนจะเริ่มล่มซ้ำ สอดคล้องกับลักษณะของฮาร์ดแวร์ที่สึกหรอ
- หลังตัดสมมติฐานอื่นออกทีละข้อ เรื่องการจำกัดพลังงานจึงกลายเป็นสมมติฐานที่หนักแน่นที่สุด
- ใช้
powerstat -Rเพื่อวัดการใช้พลังงานสูงสุดในระยะยาว แล้วนำมาเทียบกับค่าที่โฆษณาไว้- AX161: พลังงานสูงสุดที่โฆษณาไว้ 147W, ค่าสูงสุดที่วัดได้ 168W
- AX162: พลังงานสูงสุดที่โฆษณาไว้ 408W, ค่าสูงสุดที่วัดได้ 266W
- ความต่างนี้ทำให้เกิดข้อสงสัยว่า Hetzner อาจกำลังจำกัดการใช้พลังงานจริง
อัตราความขัดข้องเมื่อดูผ่าน AFR
- ใช้ Annualized Failure Rate (AFR) ในการเปรียบเทียบความน่าเชื่อถือของฮาร์ดแวร์
- แม้ AFR จะมีข้อจำกัด แต่ก็เป็นตัวชี้วัดที่เรียบง่ายและเพียงพอสำหรับใช้เป็นจุดตั้งต้นในการเปรียบเทียบอัตราความขัดข้อง
- ผลวัดเบื้องต้นชี้ว่า AX162 มีอัตราความขัดข้องสูงกว่า AX161 มาก
- AX161: ขัดข้อง 11 ครั้ง, ให้บริการรวม 3,784 วัน, AFR 1.06
- AX162: ขัดข้อง 34 ครั้ง, ให้บริการรวม 737 วัน, AFR 16.84
- ข้อมูลนี้สนับสนุนข้อสังเกตว่า AX162 มีโอกาสเกิดปัญหาสูงกว่ารุ่นอื่น 16 เท่า
- เซิร์ฟเวอร์ที่เคยล่มหนึ่งครั้งมีโอกาสสูงมากที่จะล่มอีก และ 80% ของเซิร์ฟเวอร์ที่เคยล่มหนึ่งครั้งจะล่มซ้ำครั้งที่สองภายใน 24 ชั่วโมง
เปลี่ยนเมนบอร์ดและข้อจำกัดของ v2
- Ubicloud ส่ง support ticket แบบละเอียดให้ Hetzner โดยแนบทั้งข้อสงสัยเรื่องการจำกัดพลังงานและข้อมูล AFR ไปด้วย
- Hetzner ไม่ได้ยืนยันหรือปฏิเสธความเป็นไปได้เรื่องการจำกัดพลังงาน แต่แจ้งว่าพบ ข้อบกพร่องในล็อตของเมนบอร์ด
- Hetzner ได้รับเมนบอร์ดล็อตใหม่แล้ว และแนะนำให้เปลี่ยนเมนบอร์ดของเซิร์ฟเวอร์ที่ได้รับผลกระทบ
- การเปลี่ยนเซิร์ฟเวอร์จำนวนมากอาจกระทบ workload ของลูกค้า แต่เพราะการล่มซ้ำทำให้ก่อนหน้านั้นต้องย้ายงานสำคัญส่วนใหญ่ออกจาก AX162 ไปแล้ว จึงสามารถดำเนินการเปลี่ยนได้
- หลังเปลี่ยนเป็นเมนบอร์ดใหม่ ก็ยังไม่ได้ย้าย workload สำคัญกลับขึ้น AX162 ทันที และยังติดตามผลต่อในระยะยาว
- ช่วงแรกไม่มีการล่ม แต่สองสัปดาห์ต่อมา เซิร์ฟเวอร์ที่ติดตั้งเมนบอร์ดใหม่ก็เริ่มล่มอีก
- AX162 -v2: ขัดข้อง 11 ครั้ง, ให้บริการรวม 758 วัน, AFR 5.30
- v2 ล่มน้อยกว่า AX162 เดิม แต่ก็ยังมีอัตราความขัดข้องที่สูงอยู่ดี
ผลลัพธ์ที่นิ่งขึ้นใน v3
- หลังติดต่อ Hetzner อีกครั้ง จึงทราบว่ายังมี เมนบอร์ดเวอร์ชันล่าสุด ที่ปรับปรุงความน่าเชื่อถือเพิ่มเติม
- จึงย้ายเซิร์ฟเวอร์ไปยังเวอร์ชันล่าสุดและติดตามความน่าเชื่อถือต่อ
- หลังเฝ้าดูเซิร์ฟเวอร์ใหม่เป็นเวลาหลายเดือน จึงสรุปได้ว่าปัญหา AX162 ล่มได้รับการแก้ไขแล้ว
- การเปรียบเทียบ AFR ขั้นสุดท้ายเป็นดังนี้
- AX161: ขัดข้อง 11 ครั้ง, ให้บริการรวม 3,784 วัน, AFR 1.06
- AX162: ขัดข้อง 34 ครั้ง, ให้บริการรวม 737 วัน, AFR 16.84
- AX162 -v2: ขัดข้อง 11 ครั้ง, ให้บริการรวม 758 วัน, AFR 5.30
- AX162 -v3: ขัดข้อง 4 ครั้ง, ให้บริการรวม 3,738 วัน, AFR 0.39
- ค่า AFR ของ AX162 -v3 ยังต่ำกว่า AX161 เสียอีก
ปรับปรุงกระบวนการปฏิบัติการ
- การนำเซิร์ฟเวอร์สายใหม่มาใช้ตั้งแต่ระยะแรกอาจเจอปัญหาที่คาดไม่ถึงได้
- AX162 มีสเปกที่ดึงดูดใจ และการที่ Hetzner ยุติ AX161 ก็ดูเหมือนเป็นสัญญาณว่าสายใหม่พร้อมสำหรับ production แล้ว
- แต่เมื่อมองย้อนกลับไป หากรออีก 6 เดือนก็น่าจะหลีกเลี่ยงปัญหาไปได้มาก
- การเปลี่ยนแปลงต่อจากนี้มีดังนี้
- ทำ การตรวจสอบความถูกต้อง กับเซิร์ฟเวอร์รุ่นใหม่อย่างเข้มงวดยิ่งขึ้น
- นำฮาร์ดแวร์ใหม่มาใช้แบบค่อยเป็นค่อยไป โดยเริ่มจาก workload ที่ไม่สำคัญก่อน
- เพิ่มผู้ให้บริการ bare metal ให้หลากหลายขึ้นเพื่อลดความเสี่ยง
- ตอนนี้ Ubicloud รองรับผู้ให้บริการ bare metal เพิ่มอีกสองรายคือ Leaseweb และ Latitude แล้ว และกำลังเพิ่มผู้ให้บริการรายที่สี่อยู่ด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
รุ่น AX อื่น ๆ (AX42, AX52, AX102) ก็มีปัญหาความน่าเชื่อถือร้ายแรง โดยเสียหลังใช้งานไปไม่กี่เดือน
เนื่องจากใช้ เมนบอร์ด ที่มีข้อบกพร่อง Hetzner จึงต้องเปลี่ยนเมนบอร์ดของเซิร์ฟเวอร์ที่ผลิตก่อนวันที่กำหนดแทบทั้งหมด หรืออาจทั้งหมด ภายใน 12 เดือนข้างหน้า [0]
[0] https://docs.hetzner.com/robot/dedicated-server/general-info...
เครื่องทดแทนล่าสุดดูเหมือนจะทนอยู่ ดังนั้นถ้าดูจากตัวอย่างขนาดเล็ก ก็เหมือนมี อัตราเสีย 50% ตัวเลขจริงคงมีแค่ Hetzner กับ ASRock ที่รู้
ที่บริษัทเก่า ทีม DevOps มักพบว่า พัดลม CPU เสีย ในเครื่องของ Hetzner บ่อย ๆ
เป็นคนละเรื่องกับความเสียหายของ HDD/SSD ที่มักคาดกันได้ และต้องมอนิเตอร์เอง นี่เป็นหนึ่งในเหตุผลที่เซิร์ฟเวอร์แบบไม่ managed ถูกกว่าอินสแตนซ์คลาวด์
วันแรกที่เข้าร่วม Dropbox ผมบอกทีมว่า “ผมหาเครื่องใน fleet ที่วิ่งอยู่ที่ 400MHz ได้” แล้วก็ถูกจริง ๆ คอนโทรลเลอร์ PSU สำรองที่ทำงานผิดพลาดกำลังกด PROCHOT อยู่ พอมีเครื่องจำนวนมาก เรื่องแบบนี้ก็เกิดขึ้นได้
การเป็นเจ้าของ บำรุงรักษา และซ่อมแซมอุปกรณ์จริงอย่างถูกต้องยังคงเป็น ความรับผิดชอบของบริษัทโฮสติ้ง รวมถึงการมอนิเตอร์ด้วย เมื่อก่อนอาจต้องติดตั้งสคริปต์หรือแพ็กเกจเพื่อเชื่อมเข้ากับระบบมอนิเตอร์ แต่ตอนนี้ IPMI และสิ่งที่คล้ายกันเป็นมาตรฐานแล้ว จึงทำได้โดยไม่ต้องอาศัยความช่วยเหลือจากลูกค้า
ถ้าไม่ได้ให้แค่พื้นที่แร็ก ไฟฟ้า และเครือข่าย ขอบเขตความรับผิดชอบก็เป็นเรื่องของสัญญา ถ้า Hetzner จับไม่ได้แม้แต่พัดลม CPU เสียในฮาร์ดแวร์ของตัวเอง และปล่อยระบบใหม่ออกมาโดยไม่ทดสอบให้เพียงพอ ก็เหมือนเป็นหลักฐานว่าพวกเขากำลังพลาดซ้ำ ๆ
เวลาประเมินการซื้อ ถ้าคุณไม่คิดในมุมของอีกฝ่ายเลยแม้แต่นิด เอาแต่กดต้นทุนให้ต่ำและเพิ่มรายได้ให้สูง เว้นแต่จะเป็นธุรกิจขายของน่าสงสัย ก็อยู่ได้ไม่นาน
ฮาร์ดแวร์เซิร์ฟเวอร์นั้นถูกมากจริง ๆ และถ้าเป็นโปรแกรมเมอร์ที่มีฝีมือพอสมควร โปรแกรมส่วนใหญ่ก็รับไหวด้วยเซิร์ฟเวอร์เครื่องเดียวหรือ VM เดียว ควรจ่าย เดือนละ 50 ดอลลาร์ แทนเดือนละ 25 ดอลลาร์ เพื่อให้เขามีมาร์จินบ้าง ถึงอย่างนั้นก็ไม่ได้รับประกันว่าบริษัทนั้นจะไม่ล้ม หรือจะมองคุณเป็นลูกค้าที่มีค่า สุดท้ายก็เหมือนอาศัยโครงสร้างที่กำไรทั้งระบบมาจากลูกค้ารายใหญ่
ถ้าธุรกิจของคุณอยู่ในสหรัฐฯ ก็ควรใช้ผู้ให้บริการโฮสติ้งในสหรัฐฯ
คำแนะนำว่า “ถ้ารอ 6 เดือนก็คงหลีกเลี่ยงปัญหาได้มาก และ early adopter มักเป็นคนพบปัญหาก่อน แล้วค่อยถูกแก้ในภายหลัง” ใช้ได้กับทุกระบบที่ต้องการความเสถียร
ถ้าไม่มีปัญหาด้านความปลอดภัย ก็ควรรอสักหลายเดือน หรือคงสถานะให้ ล้าหลังหนึ่งหรือสองเวอร์ชัน
เช่น ในป่า หมูป่าแก่จะส่งสัญญาณว่าปลอดภัยเพื่อพยายามให้ลูก ๆ เข้าไปในที่โล่งที่ไม่น่าไว้ใจก่อน ถ้าเทียบกับฝั่งเทคโนโลยี ก็คล้ายกับการเขียนบล็อกโพสต์อวยเทคโนโลยีที่ยังไม่พร้อมใช้ใน production
อย่างน้อยก็ดีที่ความลำบากของเราช่วยเผยให้เห็นสาเหตุรากได้เร็วขึ้น
ในบทความไม่ได้เขียนไว้ แต่ต่อไปเราก็เคยพิจารณาวิธีรับเซิร์ฟเวอร์มาแล้วปล่อยทิ้งไว้แบบ idle โดยไม่มี workload ลูกค้าจริงประมาณหนึ่งเดือน ค่าใช้จ่ายจะสูงขึ้น แต่ช่วยหาปัญหาแฝงโดยไม่กระทบผู้ใช้ได้ ในกรณีของเรา crash เริ่มเกิดขึ้น 3 สัปดาห์หลัง deploy เซิร์ฟเวอร์ AX162 เครื่องแรก ดังนั้นต้องมีช่วง buffer อย่างน้อยหนึ่งเดือน หรืออาจนานกว่านั้น
อย่างไรก็ดี นี่จะเป็นครั้งแรกและครั้งสุดท้ายที่ Ubicloud ใช้โมเดลใหม่หรือ tranche การจัดซื้อใหม่โดย ไม่มีการ burn-in ผมก็ทำงานที่นั่นและเป็นผู้ร่วมก่อตั้งด้วย
Dell ก็มีปัญหาแบบนี้เป็นครั้งคราว ตอนที่ได้รับล็อตแรกของเซิร์ฟเวอร์รุ่นก่อน เซิร์ฟเวอร์จะสูญเสียอุปกรณ์ฝั่ง I/O ด้านหลังไปพักหนึ่ง จนต้องเปลี่ยน ส่วน I/O ด้านหลัง ของเมนบอร์ด
เช่น คอนโทรลเลอร์อีเทอร์เน็ต, iDRAC และบางครั้งแม้แต่ BIOS ก็หายไปด้วย หลังจากกำจัดปัญหานี้ได้แล้ว ก็รันได้ดีเกือบ 10 ปี
ช่วงหลังเราเลิกใช้เพราะทุกอย่างสึกตั้งแต่การ์ด RAID ไปจนถึงตัวควบคุมแรงดันไฟฟ้า การรีบูตเซิร์ฟเวอร์ที่รันได้ดีเพราะเปลี่ยนการตั้งค่า แล้วพบว่า electromigration กัดกร่อน trace ภายในโปรเซสเซอร์ RAID จนเสีย การ์ด RAID ไปถาวร เป็นประสบการณ์ที่ทำให้ตาสว่างมาก
ได้ยินว่า Hetzner ไม่ได้ยืนยันหรือปฏิเสธความเป็นไปได้ของการจำกัดพลังงาน เลยสงสัยว่า การจำกัดพลังงาน จะส่งผลอะไร
ในบทความบอกว่าฮาร์ดแวร์อาจเสื่อมเร็วขึ้น แต่ไม่เข้าใจว่าทำไม
จากการที่ Hetzner ไม่ตอบ และค่าที่ UbiCloud วัดได้ ดูเหมือนว่าจะมีการจำกัดพลังงานจริง ๆ เพราะถ้าไม่ใช่ก็น่าจะบอกว่าไม่ใช่
ตรวจสอบได้ด้วยการรัน
cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governorค่าควรเป็นperformanceถ้าไม่ใช่ สามารถตั้งได้ด้วย
echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governorถ้าเป็น workload ที่ใช้ CPU หนัก ๆ จะช่วยได้ พอรีบูตแล้วจะกลับค่าเดิม จึงควรคงค่าไว้ด้วย cron/systemd ฯลฯแน่นอนว่าถ้าจ่ายค่าไฟเองหรือเป็นฮาร์ดแวร์ของตัวเอง ก็ใช้วิจารณญาณเลือก scaling governor ได้เอง แต่ถ้าเป็นเซิร์ฟเวอร์ bare metal ที่เช่ามา
performanceถึงจะเหมาะประเด็นที่ผู้ให้บริการศูนย์ข้อมูลจำกัดการใช้พลังงานต่อเซิร์ฟเวอร์เพื่อเพิ่มจำนวนเครื่องภายใต้ข้อจำกัดด้านพลังงาน และสิ่งนี้อาจทำให้เมนบอร์ดเสื่อมเร็วขึ้นนั้นขัดกับสัญชาตญาณ
จากที่ลองค้นคร่าว ๆ การจำกัดพลังงาน ดูเหมือนจะช่วยยืดอายุการใช้งานจริงของชิ้นส่วนหลายอย่างมากกว่า
ผลการค้นหาที่อ้างตรงกันข้ามมีแค่เรื่องที่ว่าเมื่อเกิด thermal throttling อุณหภูมิการทำงานที่สูงอาจทำให้ชิ้นส่วนอย่างคาปาซิเตอร์เสื่อมเร็วขึ้น แต่ในบทความดูเซ็นเซอร์อุณหภูมิหลายตัวแล้ว และระบุชัดว่าไม่ใช่กรณีนั้น
ความเห็นตอบกลับด้านล่างแชร์ตัวอย่างหนึ่ง และลองค้นดูก็เจอแหล่งข้อมูลเพิ่มอีกสองสามแห่ง [1], [2]
อย่างไรก็ตาม ผมไม่ใช่วิศวกรอิเล็กทรอนิกส์ ความเข้าใจจึงอาจไม่ถูกต้องทั้งหมด อาจเป็นไปได้ว่าความเสื่อมไม่ได้เกิดจากการจำกัดพลังงานโดยตรง แต่เกิดจาก ความผันผวนของพลังงาน หรือมีปัจจัยอื่นร่วมด้วย
[1] https://electronics.stackexchange.com/questions/65837/can-el...
[2] https://superuser.com/questions/1202062/what-happens-when-ha...
แรงดันคือค่าที่บริษัทไฟฟ้าจ่ายมา ส่วนกระแสจะถูกมอนิเตอร์เป็นรายแร็ก ปฏิกิริยาทั่วไปเมื่อกระแสในศูนย์ข้อมูลเกินขีดจำกัดคือฟิวส์ขาด หรือถูกเรียกเก็บเงินเพิ่ม
วิธีเดียวที่จะลดพลังงานที่เซิร์ฟเวอร์ใช้คือ throttling CPU โดยปกติจะ throttling CPU ผ่านระบบปฏิบัติการ จึงต้องอาศัยความร่วมมือ
เดาว่าอาจทำผ่าน lights-out baseband controller ได้โดยไม่ต้องให้ OS เข้ามาเกี่ยวข้อง แต่ถ้าเป็นแบบนั้นก็น่าจะมีโอกาสเห็นใน
/sysถึงอย่างนั้นก็ยังจำกัดเป็นรายแร็ก เพื่อไม่ให้เซิร์ฟเวอร์กำลังสูงไม่กี่เครื่องทำให้ศูนย์ข้อมูลในบริเวณที่กว้างกว่าล่ม
ไม่แน่ใจว่าวิธีจำกัดเป็นแบบไหน แต่เบรกเกอร์ธรรมดาเหมือนที่บ้านอาจเป็นทางออกง่าย ๆ ได้ แบบนั้นถ้าตัดไฟ แร็กก็จะดับ ส่งผลต่อทั้งแร็กและลูกค้าหลายราย จึงไม่เหมาะ
อีกทางเลือกคือ current/power limiter[0] แต่เพราะ P = U * I จึงอาจสร้างปัญหาได้มากขึ้น แรงดัน (U) จะตก ทำให้ทั้งระบบอยู่ในสภาวะ แรงดันต่ำ และเกิด glitch แปลก ๆ นอกจากนี้ยังเป็นวิธีทั่วไปในการข้ามกลไกความปลอดภัยหลายอย่างของชิปด้วย Raspberry Pi ก็เคยจัด challenge[1] เพื่อค้นหาบั๊กแบบนี้ และทดสอบว่าชิปทนต่อการโจมตีต่าง ๆ รวมถึงการโจมตีด้วยแรงดันได้แค่ไหน
[0] - https://en.m.wikipedia.org/wiki/Current_limiting
[1] - https://www.raspberrypi.com/news/security-through-transparen...
โดยทั่วไปวิธีแก้คือมอนิเตอร์อุณหภูมิของชิ้นส่วนอื่นเหล่านั้นด้วย แล้วนำไปเป็นอินพุตของอัลกอริทึมควบคุมความเร็วพัดลม ไม่รู้ว่ากรณีนี้เกิดขึ้นจริงหรือไม่
อาจรู้ไม่ได้แน่ชัด แต่ก็อาจเป็นปัญหาเรื่องพลังงาน·สัญญาณ หรือ VRM ก็ได้
การที่ CPU ไม่ร้อนไม่ได้หมายความว่าอย่างอื่นบนบอร์ดไม่ได้ออกนอกสเปกจนเข้าสู่ความล้มเหลวร้ายแรง
ปัญหาเมนบอร์ดรอบ ๆ พลังงาน·สัญญาณวินิจฉัยได้ยากมาก ภายนอกจะแสดงอาการได้สารพัดเหมือนเป็นปัญหาของชิ้นส่วนอื่น และจากประสบการณ์ RAM initialize ไม่ผ่านกับรีสตาร์ตแบบสุ่มพบได้บ่อยมาก สุดท้ายมักต้องลองเปลี่ยนทุกอย่างจนกว่าจะได้เปลี่ยนเมนบอร์ดจริง ๆ
AX102 ที่ใช้อยู่ตอนนี้ก็เคยมีเหตุการณ์คล้ายกัน และดูเหมือนจะ crash จากปัญหาเกี่ยวกับการ์ดเครือข่าย
โชคดีที่ฝ่ายซัพพอร์ตของ Hetzner จัดการเรื่อง ฮาร์ดแวร์ทดแทน ได้ดี แม้จะปวดหัวพอสมควร แต่ก็เป็นโอกาสที่ดีในการเรียนรู้การแก้ปัญหาฮาร์ดแวร์ และส่วนตัวคิดว่าคุ้มค่า
Hetzner ตรวจหลายครั้งแต่ไม่พบอะไร หรือไม่ก็แค่เปลี่ยนซิลิโคนระบายความร้อน CPU กับคอนเนกเตอร์ PSU ให้ ย้ายไป AX162 แล้วจนถึงตอนนี้ก็ยังปกติดี
มีใครที่มีประสบการณ์ด้านดาต้าเซ็นเตอร์พอจะเดาได้ไหมว่า Hetzner น่าจะหาทางออกเชิงพาณิชย์กับ ซัพพลายเออร์เมนบอร์ด ในกรณีนี้อย่างไร?
ควรมองว่าได้เปลี่ยนเมนบอร์ดทั้งหมดฟรี แถมยังได้รับค่าชดเชยด้วยหรือเปล่า?
ส่วนค่าชดเชยจะเป็นไปได้ก็ต่อเมื่อเจรจาไว้ล่วงหน้าเท่านั้น และในกรณีนั้นก็ต้องจ่ายค่าใช้จ่ายเพิ่มเติมด้วย แทนที่จะพยายามเรียกค่า downtime จากเวนเดอร์ อาจเป็นไปได้มากกว่าว่าควรซื้อ ประกันธุรกิจหยุดชะงัก อะไรทำนองนั้น แม้จะเป็นความผิดของเวนเดอร์ก็ตาม
Hetzner ไม่ใช่ลูกค้าทั่วไป ในฐานะส่วนหนึ่งของการปรับต้นทุนให้ต่ำสุดแบบสุดขั้ว มีความเป็นไปได้สูงว่าจะซื้อชิ้นส่วนที่ถูกที่สุด และอาจเจรจาราคาที่ต่ำลงโดยไม่มีการรับประกันก็ได้ ถ้าเป็นเช่นนั้นก็คงต้องซื้อเมนบอร์ดสำหรับเปลี่ยนเอง
เป็นช่วงที่ฟุตบอลโลกจัดขึ้นในเยอรมนี
เพิ่งเคยได้ยินเป็นครั้งแรกและค่อนข้างประหลาดใจว่า ผู้ให้บริการดาต้าเซ็นเตอร์จำกัดการใช้พลังงานของเซิร์ฟเวอร์แต่ละเครื่องเพราะข้อจำกัดด้านไฟฟ้า และนั่นอาจทำให้เมนบอร์ดเสื่อมเร็วขึ้นได้