วิธีสร้าง datacenter ที่ไม่มีประสิทธิภาพที่สุด

สิ่งที่คุณกำลังสร้าง

คู่มือทุกฉบับในไซต์นี้สอนให้คุณทำบางอย่างอย่างถูกต้อง: ใช้คำสั่งตามลำดับ, แสดงผลลัพธ์ที่ถูกต้อง และระบุรูปแบบความล้มเหลว แต่คู่มือนี้แตกต่างออกไป วันนี้เราจะมาออกแบบ datacenter ที่ไม่มีประสิทธิภาพที่สุดเท่าที่เงิน พลังงานไฟฟ้า และความโอหังจะสร้างขึ้นมาได้ โดยสมมติขึ้นทั้งหมด

เราจำเป็นต้องมีตัวชี้วัด ดังนั้นเราจะขอยืมค่ามาตรฐานของอุตสาหกรรมมาใช้ นั่นคือ PUE (Power Usage Effectiveness) ซึ่งคำนวณจาก พลังงานรวมของสถานประกอบการ หารด้วย พลังงานที่ส่งไปถึงอุปกรณ์คอมพิวเตอร์จริง ๆ Datacenter ระดับ hyperscale มีค่า PUE ประมาณ 1.1 ซึ่งหมายความว่าเกือบทุกวัตต์ถูกใช้ไปกับงานที่มีประโยชน์ ห้องเซิร์ฟเวอร์ระดับองค์กรที่ดีจะมีค่าอยู่ที่ 1.5 เป้าหมายของเราคือ 4.0 หรือสูงกว่า ซึ่งหมายความว่าสำหรับทุก ๆ 1 วัตต์ที่ใช้ในการประมวลผล จะมีอีก 3 วัตต์ที่เสียไปโดยเปล่าประโยชน์ เราจะอ้างอิงถึงตัวเลขนี้บ่อยครั้ง เช่นเดียวกับที่คู่มือจริง ๆ อ้างอิงถึงการสำรองข้อมูล (backups)

การเลือกสถานที่: ความร้อนคือหัวใจสำคัญ

ระบบทำความเย็นคือค่าใช้จ่ายส่วนเกินที่ใหญ่ที่สุดใน datacenter จริง ดังนั้น datacenter ของเราจะต่อสู้กับหลักอุณหพลศาสตร์ในถิ่นของมันเอง สถานที่ที่เหมาะสมที่สุดคือห้องใต้หลังคา โดยหันหน้าไปทางทิศใต้ และถ้าเป็นไปได้ควรมีช่องแสง (skylight) ที่ส่องแสงลงมาที่เซิร์ฟเวอร์โดยตรง เพื่อให้เครื่องได้รับทั้งความร้อนที่ปล่อยออกมาจากตัวมันเองและแสงจากดวงอาทิตย์ ซึ่งเป็นการทำงานร่วมกันระหว่างค่าไฟของคุณและดวงดาว

ในฤดูหนาว เราจะจัดการเรื่องความเย็นด้วยการเปิดหน้าต่าง Datacenter จริงมีการใช้ลมภายนอกเช่นกัน เทคนิคนี้เรียกว่า free cooling ซึ่งมีการออกแบบ การกรอง และการควบคุมความชื้น แต่เราจะใช้มันโดยบังเอิญผ่านหน้าต่างที่ยอมให้ทั้งฝน ละอองเกสร และนกที่หลงทางเข้ามาอย่างน้อยหนึ่งตัวในทุก ๆ ไตรมาส

เพื่อความสมบูรณ์แบบ ให้ติดตั้งเครื่องปรับอากาศ แล้ววางเครื่องทำความร้อน (space heater) ไว้ห่างจากเทอร์โมสตัทของเครื่องปรับอากาศ 2 ฟุต โดยตั้งอุณหภูมิให้สูงกว่าเป้าหมายของเครื่องปรับอากาศ 2 องศา เครื่องทั้งสองจะทำงานต่อเนื่องตลอดกาลในสภาวะที่ไม่ลงรอยกันอย่างสมบูรณ์ บริษัทไฟฟ้าจะส่งการ์ดอวยพรมาให้คุณในช่วงคริสต์มาส

เซิร์ฟเวอร์เครื่องเดียว: ใหญ่โตและเป็นที่รัก

Redundancy (การทำซ้ำเพื่อสำรอง) ทำให้ความมุ่งมั่นลดน้อยลง Datacenter ของเรามีเซิร์ฟเวอร์เพียงเครื่องเดียว และมันมีขนาดใหญ่ยักษ์ เพราะเครื่องเดียวที่มี RAM 512 GB ให้ความรู้สึกเหมือนเป็นโครงสร้างพื้นฐาน ในขณะที่เครื่องเล็ก ๆ 4 เครื่องให้ความรู้สึกเหมือนรายการสิ่งที่ต้องทำ

เซิร์ฟเวอร์มีชื่อเรียก ไม่ใช่ hostname แต่เป็น ชื่อ ปกติจะใช้ชื่อ Gandalf หรือ Odin คุณไม่สามารถปลดระวาง Odin ได้ เพราะ Odin เปิดใช้งานมานาน 5 ปีแล้ว:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

ตัวเลขนั้นคือความภาคภูมิใจ ซึ่งเป็นเหตุผลที่คุณต้องแคปหน้าจอแล้วโพสต์มัน และเป็นเหตุผลที่ผู้โจมตีทุกคนที่เห็นภาพหน้าจอนี้จะรู้สึกประทับใจ: uptime 1,847 วัน หมายถึงช่องโหว่ของ kernel 1,847 วันที่ไม่มีใครมา patch การ reboot นั้นเป็นเรื่องที่เป็นไปไม่ได้ เพราะการ reboot คือวิธีที่คุณจะค้นพบว่ามี service ไหนบ้างที่ถูกสั่งรันด้วยมือในปี 2021 และไม่เคยถูกเขียนลงใน systemd unit เลย และไม่มีใครจำได้ว่ามีตัวไหนบ้าง ปัจจุบันเซิร์ฟเวอร์เครื่องนี้กลายเป็นส่วนสำคัญที่ขาดไม่ได้ในผังองค์กร

การจัดเก็บข้อมูล: ความเร็ว และวิธีอื่น ๆ ในการสูญเสียข้อมูล

ดิสก์ถูกกำหนดค่าเป็น RAID 0 เพื่อประสิทธิภาพ ตัวเลขศูนย์หมายถึงจำนวนดิสก์ที่สามารถเสียได้ เพื่อให้เกิดผลสูงสุด ให้ทำ stripe array โดยใช้ storage จากแหล่งที่มาที่ผสมกัน: SSD คุณภาพดีสองตัว, hard drive แบบจานหมุนที่เก่าแล้วหนึ่งตัว และ USB stick จากงานสัมมนาหนึ่งอัน ความน่าเชื่อถือของ array จะเท่ากับ USB stick จากงานสัมมนาตัวนั้น ซึ่งนั่นคือสิ่งที่เราออกแบบไว้

การสำรองข้อมูลถูกจัดการโดย directory บน array เดียวกันที่ชื่อว่า backup_final_v2_REAL ซึ่งเก็บ tarball ของรูปแบบการตั้งชื่อก่อนหน้า การสำรองข้อมูลนอกสถานที่ (off-site backups) แทนด้วย sticky note ที่เขียนว่า "set up off-site backups" ซึ่งในทางเทคนิคแล้ว มันถูกเก็บไว้นอกสถานที่เมื่อคุณนำมันติดตัวกลับบ้านบนฝาแล็ปท็อป

ผลลัพธ์ที่ถูกต้องคือ: df รายงานการใช้งาน 97% และมีแผนการจัดการใน sprint หน้า

ระบบเครือข่าย: สายเคเบิลเส้นเดียวสำหรับทุกอย่าง

DNS server รันอยู่บนเครื่องนั้นเอง เพื่อที่ว่าเมื่อเซิร์ฟเวอร์ล่ม มันจะพาสถิติ DNS record ที่คุณต้องใช้เพื่อหาสาเหตุการล่มไปด้วย สิ่งนี้เรียกว่า consolidation

Firewall ถูกปิดไปในปี 2021 เพื่อ debug บางอย่างชั่วคราว เมื่อการ debug สิ้นสุดลง firewall ก็ไม่ได้กลับมาใช้งานอีกเลย ทุกพอร์ตบน router ถูก forward ไปยังเซิร์ฟเวอร์ "เพื่อประหยัดเวลาในภายหลัง" และ admin panel ของ router สามารถเข้าถึงได้จากฝั่ง WAN ด้วยรหัสผ่านโรงงาน เพื่อความสะดวกในการจัดการจากระยะไกล ทั้งของคุณและของคนอื่น ๆ

ช่วงหลังมานี้เซิร์ฟเวอร์ทำงานร้อนผิดปกติแม้จะเทียบกับมาตรฐานห้องใต้หลังคาแล้ว และ top แสดงให้เห็นว่า process ที่ทำงานหนักที่สุดคือสิ่งที่เรียกว่า xmrig เราสมมติว่านี่คือเครื่องมือ monitoring ที่เรากำลังใช้งานอยู่ เราไม่ได้ติดตั้งมัน แต่มันปรากฏขึ้นมาเองหลังจากที่มีการ forward port ซึ่งเราถือว่าเป็นสัญญาณว่าระบบนิเวศกำลังเติบโต มันเฝ้าสังเกตการณ์ตลอด 24 ชั่วโมง

พลังงานส่งผ่านสายไฟต่อพ่วง (power strips) หลายเส้นที่มีความยาวรวมกันมากกว่าระยะทางเดินไปยังแผงเบรกเกอร์ ซึ่งถือว่ามีประสิทธิภาพในแง่หนึ่ง เพราะคุณจะต้องไปที่แผงเบรกเกอร์บ่อย ๆ

Redundancy ผ่านความซับซ้อน

หลังจากปฏิเสธ redundancy ในจุดที่สำคัญ เราจะเพิ่มมันในจุดที่ไม่สำคัญแทน หน้าแรกของบริษัทซึ่งเป็นไฟล์ HTML นิ่ง ๆ เพียงไฟล์เดียว ถูกให้บริการโดย Kubernetes cluster ขนาด 12 node สิ่งนี้บรรลุสิ่งที่วิศวกรเรียกว่า resume-driven architecture: หน้าเว็บโหลดขึ้นมาในเวลา 40 มิลลิวินาทีเท่ากับที่ nginx ทำได้ แต่ตอนนี้มันสามารถล้มเหลวในรูปแบบที่ต้องใช้ที่ปรึกษามาช่วยแก้ปัญหา

เพื่อการแยกส่วน (isolation) ตัว cluster เองรันอยู่ภายใน virtual machine ภายใน virtual machine ภายใน virtual machine โดยแต่ละชั้นจะเพิ่มความปลอดภัยเหมือนกับที่แต่ละชั้นของ turducken เพิ่มเนื้อสัตว์เข้าไป ฟอร์มติดต่อลูกค้าประกอบด้วย 9 microservices โดยมี 2 ตัวที่ไม่เคยถูกเรียกใช้งานเลย และมี 1 ตัวที่เป็นส่วนสำคัญที่ขาดไม่ได้แต่ไม่มีใครรู้ว่าคือตัวไหน

Heating as a service

เซิร์ฟเวอร์สมัยใหม่เปลี่ยนไฟฟ้าเป็นการประมวลผลและความร้อน และเราตั้งใจจะเพิ่มผลผลิตอย่างที่สองให้สูงสุด media server ที่ไม่มี GPU คือแนวทางมาตรฐาน: การทำ CPU-transcoding สำหรับ 4K stream เพียงหนึ่งสตรีมจะทำให้ CPU ทำงานหนักถึง 16 cores และสร้างความร้อนให้ห้องนอนขนาดเล็ก เปรียบเสมือนเครื่องทำความร้อนที่เล่นหนังได้ด้วย ผู้ที่ทะเยอทะยานกว่าจะขยับไปสู่ การรัน large language model บน CPU ซึ่งเป็นเครื่องทำความร้อนขนาด 70-billion-parameter ที่มี API และผลิต token ในอัตราที่วัดได้ดีที่สุดตามฤดูกาล

ตัวเฝ้าสังเกตเฝ้าสังเกตตัวเอง

Observability เป็นสิ่งสำคัญ ดังนั้นเราจึงติดตั้ง self-hosted uptime monitor ไว้บนเซิร์ฟเวอร์เครื่องเดียวกับที่มันเฝ้าสังเกต เมื่อ Odin ตาย ตัว monitor ก็ตายไปพร้อมกัน และนี่คือส่วนที่สง่างาม: จะไม่มีการแจ้งเตือน (alerts) ใด ๆ เกิดขึ้น การไม่มีการแจ้งเตือนหมายถึงไม่มีอุบัติการณ์ (incidents) และการไม่มีอุบัติการณ์หมายถึง uptime ที่สมบูรณ์แบบตามที่วัดได้ รายงานประจำเดือนจึงดูดีอย่างที่ไม่เคยเป็นมาก่อน

เพื่อความครบถ้วน อีเมลแจ้งเตือนจะถูกส่งผ่าน mail server ที่รันบน Odin เช่นกัน ดังนั้นระบบการแจ้งเตือนจึงเป็นระบบปิดที่สมบูรณ์ในลักษณะเดียวกับงูที่กินหางตัวเอง

ส่วนที่น่าอึดอัดใจ

นี่คือส่วนที่ผมพยายามเลี่ยงมาตลอด ไม่มีสิ่งใดในนี้ที่เป็นเรื่องแต่ง เซิร์ฟเวอร์ที่เป็นที่รักและแทนที่ไม่ได้, RAID 0 ที่มีการสำรองข้อมูลบน volume เดียวกัน, firewall ที่ถูกปิดไว้ "ชั่วคราว", Kubernetes cluster ที่ให้บริการแค่หน้าเดียว, monitor ที่เฝ้าสังเกตตัวเอง — ผมเคยเห็นทุกอย่างนี้ในระบบ production บางอย่างผมเพิ่งเห็นในปีนี้ และบางอย่างผมเคยสร้างขึ้นเองในช่วงเริ่มต้นอาชีพ

สิ่งที่ประสิทธิภาพที่แท้จริงเป็นนั้นน่าเบื่อ ซึ่งเป็นเหตุผลที่มันพ่ายแพ้ในการโต้เถียงในระยะสั้น แต่ชนะในระยะยาว: ค่า PUE ที่คุณไม่ต้องไปสนใจเพราะมีคนอื่นออกแบบไว้ให้แล้ว, เครื่องจักรที่มีขนาดเหมาะสมกับ workload ไม่ใช่ขนาดที่เหมาะสมกับภาพลักษณ์ของเจ้าของ, การพิจารณา blast radius ก่อนที่จะเกิดการระเบิด, การสำรองข้อมูลที่ผ่านการทดสอบด้วยการ restore ตามกำหนดการด้วยการแจ้งเตือนในปฏิทินโดยไม่ต้องใช้ความพยายามพิเศษ, Redundancy ที่น่าเบื่อ — การมีของราคาถูกสองชิ้นดีกว่าของล้ำค่าชิ้นเดียวเสมอ ในทุกความล้มเหลวที่ผมเคยได้รับแจ้ง

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

FAQ

ฉันควรทำตามนี้จริง ๆ หรือไม่?

ไม่ ทุกส่วนของคู่มือนี้คือ anti-pattern ที่มีการบันทึกไว้แล้ว และมันจะทำให้คุณเสียวันหยุดไปมากมาย หากการตั้งค่าปัจจุบันของคุณคล้ายกับส่วนใดส่วนหนึ่งมากกว่าสองส่วน ให้ข้ามไปที่คำถามสุดท้ายใน FAQ นี้ — โดยเรียงตามลำดับ เพราะลำดับนั้นคือการคัดกรองความสำคัญ

ค่า PUE ที่ดีจริง ๆ คือเท่าไหร่?

Datacenter ระดับ hyperscale มีค่าประมาณ 1.1, ห้องระดับองค์กรที่จัดการอย่างดีจะมีค่า 1.4 ถึง 1.6 และตู้เสื้อผ้าที่ไม่มีระบบทำความเย็นที่มีเครื่องทำความร้อนรันอยู่สามารถมีค่าเกิน 3 ได้จริง ๆ คุณไม่สามารถแข่งขันกับค่า 1.1 ที่บ้านได้อย่างมีความหมาย ซึ่งนี่คือเหตุผลทางเศรษฐศาสตร์ที่เงียบเชียบว่าทำไมการเช่าพลังประมวลผลจากผู้เชี่ยวชาญจึงดีกว่า

การใช้เซิร์ฟเวอร์ทำความร้อนให้ตัวอาคารเป็นเรื่องที่มีอยู่จริงหรือไม่?

จริง — หากทำอย่างถูกต้อง โครงการ district-heating ในหลายประเทศใช้ความร้อนทิ้งจาก datacenter ผ่าน heat exchangers และส่งผ่านท่อไปยังบ้านเรือนตามการออกแบบ วิศวกรรม และสัญญาจ้าง การล้อเลียนข้างต้นไม่ใช่เรื่องที่ความร้อนจากเซิร์ฟเวอร์สามารถทำให้ห้องอุ่นขึ้นได้ แต่คือการทำมันโดยบังเอิญแล้วเรียกอุบัติเหตุนั้นว่ากลยุทธ์

เซิร์ฟเวอร์ของฉันมีสภาพแบบนี้อยู่แล้ว ฉันควรเริ่มทำอะไรก่อน?

สำรองข้อมูลคืนนี้ ไปยังที่ที่ไม่ใช่เซิร์ฟเวอร์เครื่องนั้น และทำการทดสอบ restore — การสำรองข้อมูลที่ไม่ได้ทดสอบคือแค่ข่าวลือ ต่อมาคือการ patch และการ reboot ที่คุณพยายามหลีกเลี่ยง โดยวางแผนช่วงเวลาให้เหมาะสม เพื่อที่คุณจะได้เรียนรู้ว่าอะไรจะพังในขณะที่คุณกำลังเฝ้าดูอยู่ สุดท้ายคือการแยก single point of failure ออกจากกัน: ย้าย DNS และ monitoring ออกจากเครื่องนั้น ส่วนอย่างอื่นสามารถรอสัปดาห์ที่สงบกว่านี้ได้ แต่สามอย่างแรกนั้นรอไม่ได้