วิธีออกแบบศูนย์ข้อมูลให้ไร้ประสิทธิภาพที่สุดในโลก

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

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

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

การเลือกสถานที่: ความร้อนคือประเด็นสำคัญ

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

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

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

เซิร์ฟเวอร์หนึ่งเครื่อง ขนาดใหญ่ และเป็นที่รัก

ความซ้ำซ้อนทำให้ความมุ่งมั่นลดน้อยลง ศูนย์ข้อมูลของเรามีเซิร์ฟเวอร์เพียงเครื่องเดียวและมันมีขนาดใหญ่มาก เพราะเครื่องเดียวที่มี 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 วันที่ไม่มีใครแพตช์ การรีบูตเป็นเรื่องที่ทำไม่ได้อยู่แล้ว เพราะการรีบูตคือวิธีที่คุณจะได้รู้ว่ามีบริการใดบ้างที่ถูกเริ่มด้วยมือในปี 2021 และไม่เคยถูกเขียนลงใน systemd unit ไม่มีใครจำได้ว่ามีบริการอะไรบ้าง ขณะนี้เซิร์ฟเวอร์เครื่องนี้กลายเป็นส่วนสำคัญที่แบกรับภาระงานในผังองค์กรไปแล้ว

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

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

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

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

ระบบเครือข่าย: จุดรวมศูนย์ของทุกสิ่ง

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

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

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

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

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

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

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

การทำความร้อนในรูปแบบบริการ (Heating as a service)

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

ระบบตรวจสอบที่เฝ้าดูตัวเอง

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

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

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

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

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

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

FAQ

ฉันควรทำตามคำแนะนำเหล่านี้จริงหรือ?

ไม่ควรทำ ทุกส่วนของคู่มือนี้เป็นรูปแบบการทำงานที่ผิด (anti-pattern) ซึ่งสร้างความเสียหายให้กับวันหยุดสุดสัปดาห์ของผู้ดูแลระบบมานับไม่ถ้วน หากการตั้งค่าปัจจุบันของคุณมีลักษณะตรงกับเนื้อหามากกว่าสองส่วน ให้ข้ามไปอ่านคำถามสุดท้ายใน FAQ นี้ตามลำดับที่ระบุไว้ เนื่องจากลำดับดังกล่าวคือการจัดลำดับความสำคัญในการแก้ไขปัญหา

ค่า PUE ที่ดีควรเป็นเท่าใด?

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

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

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

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

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