เรื่องราวการสร้างดาต้าเซ็นเตอร์ของ Railway เอง
(blog.railway.com)- Railway มองว่าการประมวลผลบน GCP เป็นข้อจำกัดด้าน ราคา·การสนับสนุน·การพัฒนาฟีเจอร์ จึงเริ่มทำ Railway Metal ซึ่งเป็นโครงสร้างพื้นฐานทางกายภาพที่ควบคุมได้โดยตรงมากขึ้น
- หลังเริ่มในเดือนมกราคม 2024 ใช้เวลา 5 เดือนจนเชื่อมต่อเซิร์ฟเวอร์เครื่องแรกได้ และใช้อีก 3 เดือนกว่าจะนำ workload ของผู้ใช้ขึ้นไปรันได้ จากนั้น 9 เดือนต่อมา ไซต์แรกในแคลิฟอร์เนีย ก็เริ่มทำงาน
- ข้อจำกัดที่ใหญ่กว่าการเช่าพื้นที่คือ ไฟฟ้าและการระบายความร้อน และ Railway เลือก Cage Colocation แทน Greenfield หรือการเช่าระดับแร็ก
- เครือข่ายออกแบบให้มี ISP อย่างน้อย 2 รายต่อภูมิภาค, ตาราง routing ของอินเทอร์เน็ตทั้งหมด, การเลือกเส้นทางตาม IP prefix และหลาย zone เพื่อรับมือ ความขัดข้องของดาต้าเซ็นเตอร์เดียว
- ต้องลงมือจัดการเองตั้งแต่การวางแร็ก, เอกสารสายเคเบิล, PDU, สวิตช์ reverse airflow, Redfish API, PXE, FRR ไปจนถึง SONiC และการสร้างคลาวด์เองนั้นใกล้เคียงกับ การสร้างบ้าน มากกว่าการ deploy ด้วย Terraform
เหตุผลที่ย้ายจาก GCP ไปยัง Railway Metal
- ระบบประมวลผลของ Railway ถูกสร้างบน Google Cloud Platform มาตั้งแต่ช่วงแรก
- GCP ช่วยการเติบโตในช่วงแรกได้ แต่เมื่อการดำเนินงานใหญ่ขึ้น ก็เริ่มมีข้อจำกัดในการให้แพลตฟอร์มตามที่ต้องการแก่ลูกค้า
- การดำเนินงานบน hyperscaler จำกัด ราคา, ระดับบริการ และขอบเขตการพัฒนาฟีเจอร์ที่ Railway สามารถเสนอได้โดยตรง
- ค่า egress fee ส่งผลต่อราคา
- แม้เกิดปัญหาในโครงสร้างพื้นฐานชั้นบน ก็มักแทบไม่เข้าใจสาเหตุ
- Railway ประเมินว่าแม้ใช้จ่ายปีละหลายล้านดอลลาร์ ระดับการสนับสนุนก็ไม่ได้ต่างจากการใช้ 100 ดอลลาร์มากนัก
- เพื่อตอบสนองต่อเรื่องนี้ Railway จึงเริ่มโครงการ Railway Metal ในปี 2024
- 9 เดือนต่อมาเปิดใช้งานไซต์แรกในแคลิฟอร์เนีย
- ดำเนินการเองตั้งแต่การออกแบบ กำหนดสเปก และติดตั้ง ตั้งแต่สายไฟเบอร์ออปติกใน cage ไปจนถึงสัญญากับ ISP
- กำลังเปิดใช้งาน region ของดาต้าเซ็นเตอร์เพิ่มอีก 3 แห่ง
การเลือกพื้นที่แรก: cage ในดาต้าเซ็นเตอร์
- โครงการ Railway Metal เริ่มในเดือนมกราคม 2024 และใช้เวลา 5 เดือนกว่าจะเชื่อมต่อเซิร์ฟเวอร์เครื่องแรกได้
- ต้องใช้อีก 3 เดือนจึงมั่นใจว่าสามารถนำ workload ของผู้ใช้ขึ้นบนฮาร์ดแวร์ได้
- โครงสร้างพื้นฐานของตัวเองต้องมีพื้นที่วางเซิร์ฟเวอร์ ไฟฟ้าที่เสถียร และการระบายความร้อนที่เพียงพอ
- ตัวเลือกหลักมีสามแบบ
- Greenfield buildout: ซื้อหรือเช่าดาต้าเซ็นเตอร์
- Cage Colocation: ได้พื้นที่เฉพาะภายในดาต้าเซ็นเตอร์ของผู้ให้บริการ โดยล้อมด้วยผนังตาข่าย
- Rack colocation: เช่าแร็กทั้งตู้หรือบางส่วนของแร็กในดาต้าเซ็นเตอร์แบบ colocation
- Railway เลือก Cage Colocation เพื่อให้ได้พื้นที่ว่างที่มีผนังสี่ด้าน ประตูรักษาความปลอดภัย และสามารถออกแบบส่วนที่เหลือเองได้
- ค่าใช้จ่ายของพื้นที่เองไม่สูงมาก แต่ไฟฟ้าและค่าระบายความร้อนที่ตามมาถือว่าสูงที่สุด
- ค่าใช้จ่ายต่อ kW แตกต่างกันมากตามภูมิภาค
- ในฝั่งตะวันตกของสหรัฐฯ อาจจ่ายต่ำกว่าสิงคโปร์ได้มากกว่าครึ่ง
- ค่าไฟจ่ายเป็น commit รายเดือนเพื่อรับประกันความพร้อมใช้งานแบบ on-demand โดยไม่ขึ้นกับปริมาณการใช้งานจริง
การออกแบบไฟฟ้าและ PDU
- Railway กำหนดเป้าหมาย จำนวน vCPU, RAM GB และ NVMe TB ให้สอดคล้องกับ capacity ที่เคยใช้บน GCP ก่อน
- จากตัวเลขเหล่านี้จึงเลือกเซิร์ฟเวอร์และ CPU
- ตัวแปรสำคัญคือ ความหนาแน่นของพลังงาน หรือการอัด capacity ประมวลผลที่ต้องการให้อยู่ภายในการใช้ไฟฟ้าที่กำหนด
- การคำนวณไฟฟ้าไม่ได้จบแค่การบวกรวมวัตต์ โดยเฉพาะไฟฟ้า 3 เฟสจะซับซ้อนกว่า
- บทความของ Cloudflare เรื่อง แนะนำไฟฟ้า 3 เฟสและ PDU อธิบายประเด็นที่เกี่ยวข้องไว้
- ในดาต้าเซ็นเตอร์ ไฟฟ้าเป็นทรัพยากรที่สำคัญที่สุด และไฟดับอาจใช้เวลากู้คืนนานมาก
- แต่ละแร็กต้องมี power feed ที่เป็นอิสระจากกันอย่างสมบูรณ์ 2 ชุด
- ในภาวะปกติ feed ทั้งสองจะแบ่งโหลดกัน
- ต้องทนได้แม้ feed ใด feed หนึ่งล่ม
- การส่งไฟฟ้าไปยังเซิร์ฟเวอร์ต้องใช้ Power Distribution Unit
- PDU พื้นฐานแทบจะเหมือนปลั๊กพ่วงขยายช่อง
- PDU ที่ Railway นำไปใช้งานสามารถควบคุมและวัดค่ารายเต้ารับได้
- PDU แต่ละตัวเข้าถึงผ่านเครือข่ายได้ และสามารถวัดค่า·ควบคุมเต้ารับแต่ละช่องจากระยะไกลได้
เครือข่าย: ISP, routing, เส้นทางรายภูมิภาค
- เครื่องบนคลาวด์ไม่ได้อยู่โดดเดี่ยว เครือข่ายจึงมีบทบาทสำคัญ
- Railway มองหาสถานที่ดาต้าเซ็นเตอร์ที่เชื่อมต่อกับโลกภายนอกได้อย่างแข็งแกร่ง เพื่อให้ได้ latency ต่ำ
- เงื่อนไขที่ต้องการมีดังนี้
- อยู่ในสถานะ on-network กับ Tier 1 ISP
- อยู่ใน Internet Exchange
- มีไฟเบอร์ออปติกที่เชื่อมต่อไปยังดาต้าเซ็นเตอร์ใกล้เคียงอื่นได้
- แอปพลิเคชันที่ deploy บน Railway สื่อสารกับ endpoint หลากหลายรูปแบบ
- ผู้ใช้อินเทอร์เน็ตบ้านในซิดนีย์
- API ที่โฮสต์บนเซิร์ฟเวอร์ AWS ในสหรัฐฯ
- เพื่อให้ได้ latency ต่ำและต้นทุน bandwidth ต่ำ Railway ทำสัญญากับผู้ให้บริการอินเทอร์เน็ตหลายรายที่เหมาะกับแต่ละ use case
- เลือก ISP ตามความพร้อมของเครือข่ายในภูมิภาคเป้าหมาย
- หากร่วมงานกับ ISP ผิดราย อาจเกิด network hop เพิ่มไปยังตลาดเป้าหมายบางแห่ง ทำให้ latency สูงขึ้น
- ในกรณีแย่ที่สุด อาจเกิดเส้นทางเครือข่ายที่ซับซ้อนคดเคี้ยว
- ในแต่ละภูมิภาค เลือกเครือข่ายแยกกันอย่างน้อย 2 เครือข่ายตาม footprint ในพื้นที่
- หลังเชื่อมต่อแล้ว จะรับตาราง routing ของอินเทอร์เน็ตทั้งหมดจาก ISP แต่ละราย และรวมเข้าที่สวิตช์เครือข่ายเพื่อกำหนดเส้นทางที่ดีที่สุดตาม IP prefix
- หากผู้ใช้ในออสเตรเลียเข้าถึงแอปที่ deploy ในสิงคโปร์ มีโอกาสสูงที่จะส่งแพ็กเก็ตต่อให้ Telstra
- หากแอปเดียวกันส่งแพ็กเก็ตไปยังผู้ใช้หรือเซิร์ฟเวอร์ในญี่ปุ่น มีโอกาสสูงที่จะส่งต่อให้ PCCW
- ข้อมูล peering เป็นข้อมูลสาธารณะ และสามารถดูการเชื่อมต่อระหว่างเครือข่ายได้ที่ bgp.tools
- เพื่อ redundancy จึงสร้างหลาย zone ภายในแต่ละ region และการเชื่อมต่อข้ามไซต์ก็สำคัญต่อการขยาย
- พิจารณาเครื่องมืออย่าง dark fiber หรือ wavelength service
- เป้าหมายคือให้แอปไม่รู้สึกถึงความแตกต่าง ไม่ว่าฐานข้อมูลจะอยู่ในห้องเดียวกันหรืออาคารข้างเคียงที่ห่างไป 4 บล็อก
- เป็นการออกแบบเพื่อเพิ่ม resilience ต่อความขัดข้องของดาต้าเซ็นเตอร์แต่ละแห่ง
แร็ก, ทางเดิน, การระบายความร้อน, เส้นทางสายเคเบิล
- ในดาต้าเซ็นเตอร์จะจัดวางแร็กเป็นแถว และใช้ทางเดินระหว่างแร็กเป็นเส้นทางไหลของอากาศ
- ใน Cold Aisle อากาศเย็นจากสถานที่จะเข้ามา เซิร์ฟเวอร์จะดูดอากาศนี้เข้าไปแล้วปล่อยออกทางด้านหลังไปยัง Hot Aisle
- เพื่อเพิ่มประสิทธิภาพ อากาศระหว่าง Cold Aisle และ Hot Aisle ไม่ควรผสมกัน
- แม้แร็กจะใช้อุปกรณ์กว้าง 19 นิ้ว แต่สามารถเลือกความสูง ความกว้าง และความลึกให้เหมาะกับข้อกำหนดของอุปกรณ์และสายเคเบิลได้
- อุปกรณ์เซิร์ฟเวอร์ส่วนใหญ่สามารถดึงออกมาด้านหน้าบนรางเพื่อบำรุงรักษาได้ ดังนั้นขนาดของ cage ต้องรองรับเรื่องนี้
- สายเคเบิลและการจัดการสายก็ต้องใช้พื้นที่ ทำให้ต้อง trade-off ระหว่างการยัดแร็กให้แน่นเพียงใดกับจำนวนแร็กที่จะใส่ใน cage
- จากประสบการณ์ของ Railway ไฟฟ้าและการระบายความร้อน กลายเป็นข้อจำกัดบ่อยกว่าพื้นที่จริง
- ในไซต์ใหม่ เลือกใช้แร็กที่กว้างขึ้น 800mm เพื่อย้ายสายเคเบิลออกจากเส้นทางระบายอากาศและปรับปรุง airflow
- นอกจากแร็กแล้ว ยังต้องมีโครงสร้างพื้นฐานเหนือศีรษะและถาดสำหรับส่งไฟฟ้าและข้อมูล
- เดินไฟเบอร์ออปติกจากขอบ cage ไปยังแต่ละแร็ก
- เดินสายระหว่างแร็กด้วย
- รายการเหล่านี้บางครั้งผู้ให้บริการดาต้าเซ็นเตอร์จะรวมไว้ในใบเสนอราคาของ cage
- Railway ซื้อ reverse airflow switch ที่พอร์ตหันไปด้านหลังแร็ก เพราะแต่ละแร็กมีความหนาแน่นของสายไฟเบอร์ออปติกแบบ switch-to-server สูง
- เป็นสวิตช์ที่ระบายอากาศออกทางด้านที่มีพอร์ตเครือข่าย
- จัดถาดสายให้การเดินสายทั้งหมดเกิดขึ้นที่ด้านเดียวของแร็ก
- หลีกเลี่ยงสถานการณ์ที่สายเคเบิลวิ่งซิกแซ็กไปมาระหว่างด้านหน้าและด้านหลังของแร็ก
เอกสารติดตั้งและ rack-and-stack
- ตอนแรก Railway ลองเดินสายเอง แต่ผลลัพธ์ไม่สม่ำเสมอ จึงนำผู้เชี่ยวชาญเข้ามาเพื่อให้ติดตั้งได้ถูกต้อง
- ต้องมี ชุดเอกสาร ที่ครอบคลุม เพื่อให้ผู้เชี่ยวชาญด้านการติดตั้งรู้ว่าต้องติดตั้งอะไรไว้ที่ไหน
- เอกสารทั่วไปมีสองแบบ
- Cabling matrix: ระบุตำแหน่งอุปกรณ์ พอร์ต สเปกสายเคเบิล ชนิดไฟเบอร์ออปติก ความยาว ฯลฯ ของปลายสายทั้งสองด้าน
- Rack elevation: แสดงตำแหน่งและทิศทางของอุปกรณ์แต่ละชิ้นในแร็กแบบภาพ
- การติดตั้งแต่ละรอบของ Railway มีอุปกรณ์มากกว่า 60 ชิ้น สายเคเบิลแยกกันมากกว่า 300 เส้น และรายละเอียดปลีกย่อยอีกหลายสิบรายการ
- สเปกและสเปรดชีตที่เป็นพื้นฐานของการติดตั้งและ commissioning ถูกสร้างขึ้นด้วยมือ
- หลังวัสดุมาถึงหน้างานแล้ว การติดตั้งทั้งหมดใช้เวลาประมาณ 6~14 วัน
- ต่อมา Railway สร้างเครื่องมือภายในเพื่อทำให้การสร้าง build specification เป็นอัตโนมัติ
- การสร้าง cage ในดาต้าเซ็นเตอร์ห่างไกลจากการ deploy สแต็กแบบซอฟต์แวร์ทั่วไป, DevOps หรือ Terraform และใกล้เคียงกับ งานสร้างบ้าน มากกว่า
- สถานที่ดาต้าเซ็นเตอร์ ผู้รับเหมา และ vendor แต่ละรายมีวิธีทำงานต่างกันเล็กน้อย แม้อยู่ในองค์กรเดียวกัน จึงต้องใส่ใจรายละเอียดในการปฏิบัติการอย่างมาก
เคสยกเว้นและปัญหาทางกายภาพที่เจอหน้างาน
- ในไซต์หนึ่ง PDU ถูกติดตั้งกลับหัว และไฟเข้าจากพื้น ทำให้หมายเลขเต้ารับตามแผนกลับด้าน
- ที่ไซต์ Amsterdam มีรูปแบบสถานที่ที่ลิงก์ไฟเบอร์ออปติกภายนอกเข้ามาในกล่องภายในแร็กโดยตรง แทนที่จะมี demarcation point เฉพาะ
- บางสถานที่เดินสายเต้ารับไฟฟ้าแบบ phase-to-neutral ซึ่งต่างจากไซต์อื่น ขณะที่บางแห่งเป็นแบบ phase-to-phase
- มีกรณีที่ผู้รับเหมาไม่รู้ว่าอุปกรณ์เครือข่ายเป็น reverse airflow จึงพยายามติดตั้งกลับทิศ และสรุปว่าสายข้อมูลสั้นเกินไป
- สาเหตุที่ link ไม่ขึ้นในสายบางเส้นคือ polarity ของไฟเบอร์ออปติกผิด และตอนนั้น Railway จึงได้รู้จัก “rolling fibre cables”
- เป็นวิธีถอดปลั๊กของ LC connector แล้วสลับกัน
- PDU ประมาณ 24 ตัวจาก vendor รายหนึ่งมีข้อบกพร่องที่เต้ารับ ทำให้ปลั๊กไฟเสียบไม่เข้าล็อกอย่างถูกต้อง และแม้ใช้แรงทางกายภาพมากก็แก้ไม่ได้
งานซอฟต์แวร์หลังการติดตั้งทางกายภาพ
- หลังฮาร์ดแวร์เข้าที่แล้ว งานจะย้ายไปสู่ขอบเขตซอฟต์แวร์ที่คุ้นเคยกว่า
- งานที่จำเป็นมีดังนี้
- ตั้งค่า BGP
- ติดตั้ง OS
- ตั้งค่า monitoring
- ตั้งค่าอุปกรณ์เครือข่าย
- เขียนการตั้งค่า router
- อัปเดตบันทึกของ RIR หรือ Regional Internet Registry
- ใช้ Redfish APIs เพื่อเข้าถึงคอนโทรลเลอร์เฉพาะของเซิร์ฟเวอร์และ PDU
- ใช้ PXE เพื่อบูตเซิร์ฟเวอร์ผ่านเครือข่าย
- การออกแบบเครือข่ายของ Railway ใช้ whitebox network switch ที่รัน FRR และ SONiC
- ด้วยการออกแบบนี้ Railway สร้าง เครือข่ายขับเคลื่อนด้วยซอฟต์แวร์แบบ L3-only ที่ผสานกับ Railway control plane อย่างลึกซึ้ง
- ในช่วงไม่กี่เดือนที่ผ่านมา Railway ได้สร้างเครื่องมือซอฟต์แวร์ใหม่ชื่อ Railyard และ MetalCP
- ออกแบบ cage ใหม่
- ติดตามและแสดงภาพสายเคเบิล
- ติดตั้ง OS บนเซิร์ฟเวอร์
- เป็นเครื่องมือที่ทำให้กระบวนการเชื่อมต่อเซิร์ฟเวอร์เข้ากับอินเทอร์เน็ตทำได้แบบกดปุ่ม
- บทความถัดไปจะกล่าวถึงกระบวนการเปลี่ยนชุดเซิร์ฟเวอร์ในห้องหนึ่งให้กลายเป็น Railway zone ที่ใช้งานได้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
จากประสบการณ์ของผมและบทความแบบนี้ ผมรู้สึกว่า Google ไม่ชอบการมีลูกค้า
เหมือนมีใครสักคนตัดสินใจว่า “ต้องทำ public cloud” ก็เลยทำขึ้นมา แต่กลับรู้สึกว่าอยากผลักลูกค้าออกไปด้วยไม้ยาว 3 เมตร
ผมมั่นใจ 100% ว่าผู้ดูแลบัญชีของ AWS เป็นคนที่จะลงไปคลุกโคลนด้วยกันถ้าจำเป็น ถ้าเกิดวิกฤตแล้วขอร้อง เขาก็เป็นคนที่จะนอนบนพื้นไปด้วยกัน
แต่พอเห็นผู้ดูแลฝั่ง Google Cloud แล้วก็เศร้า เพราะเห็นได้ว่าพวกเขาเองก็ได้รับความรักและการสนับสนุนจากภายใน Google น้อยกว่าพวกเราเสียอีก การเห็นคนที่พยายามโน้มน้าวบริษัทตัวเองให้ขายและให้บริการอย่างจริงจังนั้นน่าเห็นใจ และเหมือนถูกตั้งค่าให้ล้มเหลวตั้งแต่แรก
คนฝั่ง Microsoft นั้นแข็งแกร่งเหมือนกันกระสุน ขายเก่ง ให้บริการดี รีดเงินจากกระเป๋าผมจนหมด แต่ก็ยังทำให้ผมเชื่อสุดใจว่านั่นเป็นเรื่องดีสำหรับผมได้ เพียงแต่ว่า cloud ของเขาเป็นอะไรที่… แปลกมาก
เรื่องที่ Railway จะไปใช้ bare metal นั้น จากมุมมองของคนที่ทำมา 15 ปี ผมไม่อยากกลับไปอีกเด็ดขาด ไม่เด็ดขาด และไม่มีทางเด็ดขาด มันไม่คุ้มเลย แต่คงต้องเจอเองถึงจะรู้ และเส้นทางมันก็เป็นแบบนั้นแหละ
อีกไม่นานก็จะเข้าใจว่า Google ลำบากขนาดนั้นไปทำไม เพียงแต่ถ้ามีใจอยากขายบริการให้ผู้คนจริง ๆ มากกว่าการสร้าง Borg หรือสมองกล ก็สามารถทำได้ดีกว่า Google ถึง 100 เท่า
ถึงอย่างนั้นก็ไม่น่าจะถึงขั้นลงไปคลุกโคลนด้วยกันได้ ซึ่งก็น่าประหลาดใจอยู่เหมือนกัน เลยสงสัยว่าต้องใช้เงินเท่าไรถึงจะเข้าสู่ระดับ “ไปคลุกโคลนด้วยกัน” ได้
บริการ cloud ทั้งหมดให้ความรู้สึกเหมือนถูกออกแบบโดยคนที่ไม่รู้อะไรเกี่ยวกับ cloud computing เลย และรู้จักแค่ “การเช่าเซิร์ฟเวอร์ bare metal” เท่านั้น มันก็เป็น cloud computing อยู่หรอก แต่เป็นวิธีที่ ทำลายแนวคิดของ cloud computing เอง
เครื่องมือ command line ของ GCP อย่าง
gcloudก็รู้สึกว่าออกแบบมาดีกว่าแบบนั้นเราคงประหยัดเวลาทำงานล่วงหน้าไปได้หลายเดือน
จากประสบการณ์ส่วนตัว support ของ Google Cloud ปฏิบัติกับทีมเล็ก ๆ 3 คนที่ใช้เงินน้อยมากได้ค่อนข้างดี และที่บริษัทอื่น Microsoft ก็ปฏิบัติดีมากเช่นกัน เพียงแต่ตอนนั้นระดับการใช้จ่ายคงมากพอที่จะติดตามได้จากการเฝ้าดูโครงข่ายไฟฟ้าของ data center เลยทีเดียว
ในทางกลับกัน AWS โกหกเรื่องฟีเจอร์ และสุดท้ายก็ไม่ตอบอะไรเลยจนจบ
ผู้ดูแลบัญชีที่คุยเรื่องสัญญา AWS มูลค่าหลายล้านดอลลาร์ที่จำเป็นกับผู้บริหารระดับสูง ดูเหมือนจะรู้ดีว่าควรพูดกับผู้บริหารเหล่านั้นอย่างไร
แต่พอมาถึงขั้นตอนพัฒนาและส่งมอบผลิตภัณฑ์เพื่อผู้อื่นจริง ๆ กลับมีแต่พวกเราที่ถูกทิ้งไว้ในฝุ่น
ที่ตลกยิ่งกว่านั้นคือ ฟีเจอร์ที่โกหกนั้นถูกขายว่าเป็นหัวใจสำคัญที่จะทำให้ประสบการณ์ของผู้ใช้ปลายทางยอดเยี่ยมมาก
ผมตอบกลับใน ticket support แล้ว แต่ไม่มีการตอบกลับ และส่งอีเมลไปหาผู้รับผิดชอบของ AWS สองคน ก็ยังไม่มีคำตอบเช่นกัน
นึกถึงสมัย Rackspace เมื่อก่อนเลย มีเรื่องที่เหมือนสงครามจริง ๆ เยอะมาก
คนจาก EMC มาติดตั้งอุปกรณ์สตอเรจสำหรับทดสอบ แล้วดันสะดุดขากันเองจนดึงแร็กเซิร์ฟเวอร์ทั้งแร็กลงมาเหมือนฉากตลก แน่นอนว่าไม่ได้สัญญาไป
คนขับรถบรรทุกคนหนึ่งเกิดหัวใจวาย และอุบัติเหตุนั้นทำให้ดาต้าเซ็นเตอร์ DFW ออฟไลน์ มีเสากั้นรถไว้เพื่อป้องกันสถานการณ์แบบนี้ แต่ตอนนั้นยังไม่ได้เทปูนลงไป
ครั้งหนึ่งเคยเชื่อมต่อชั่วคราวด้วยการยิงแบนด์วิดท์ด้วยเลเซอร์ไปยังอาคารอีกฝั่งถนน
วันหนึ่งเซิร์ฟเวอร์เริ่มลุกไหม้จริง ๆ จนต้องทุบหน้าต่างแล้วไปซื้อพัดลมกล่องมา
วิศวกรรมดาต้าเซ็นเตอร์พัฒนาขึ้นมากเมื่อเทียบกับยุคแรก ๆ ตอนนั้นเราทำ OpenCompute Project ร่วมกับ Facebook ซึ่งมีแนวคิดด้านอินฟราสตรักเจอร์ที่ล้ำหน้ามากสำหรับเวลานั้น
ลิงก์ไมโครเวฟหลักหลุดอยู่เรื่อย ๆ พร้อมกับแพ็กเก็ตผิดพลาดเป็นครั้งคราวลึกลงไปในชั้น data link พอสืบดูพบว่าต้นไม้ฝั่งตรงข้ามถนนผลิใบ และกิ่งไม้แกว่งเข้ามาอยู่ในแนวสายตาของอุปกรณ์บนอาคารเรา ใช้บันได เลื่อย และเวลา 10 นาที ก็คืนการเชื่อมต่อได้
เราเตอร์ BGP หลักที่ออกจากดาต้าเซ็นเตอร์รีบูตอยู่ตลอด ไม่มีอุปกรณ์สำรองซ้ำซ้อน ตรวจดูแล้วพบว่าอุณหภูมิในดาต้าเซ็นเตอร์สูงเกินไปและระบบทำความเย็นแย่มาก จนอากาศฝั่งพัดลมดูดเข้าเกิน 60°C เลยตั้งพัดลมเป่าเล็งไว้ชั่วคราว
ไม่กี่สัปดาห์ต่อมา แอร์ในอีกห้องก็พังและเริ่มพ่นน้ำลงบน Nortel DMS-100 มันเป็น ISP แบบไดอัลอัปที่มีสวิตช์ของตัวเอง ผมคิดว่าน้ำอาจมีกระแสไฟ เลยไม่อยากช่วยเช็ด แต่ก็เลี่ยงไม่ได้
หลังจากนั้นผมยังทำงานบนเกาะเล็ก ๆ ห่างไกลแห่งหนึ่งด้วย ลิงก์อินเทอร์เน็ตหลักเป็นลิงก์ 1MB/s ผ่านดาวเทียม GS และ ping เกิน 500ms คนท้องถิ่นไดอัลอัปผ่านเครือข่ายโทรศัพท์ไมโครเวฟที่จัดเรตไว้ที่ 9600 baud แต่ไม่รู้ทำไมโมเด็ม 56k ถึงใช้งานได้
วันหนึ่งพบว่าในเครื่อง Solaris ขาด
.soสำคัญไป แต่ไม่มีทั้งแบ็กอัปในเครื่องและสื่อสำหรับติดตั้ง เลยโทรหาเพื่อนที่อังกฤษให้ช่วยอัปโหลดสำเนาไปยังเซิร์ฟเวอร์ FTP แล้วทำให้เครื่องนั้นกลับมาออนไลน์ได้ไม่กี่ปีต่อมา ยังเคยติดตั้ง ลิงก์เลเซอร์ เหนือ Oxford Road ใน Manchester ซึ่งตอนนั้นเป็นเส้นทางรถบัสที่พลุกพล่านที่สุดในยุโรป เพื่อเชื่อมสำนักงานกับแคมปัสมหาวิทยาลัยด้วย เป็นช่วงเวลาที่สนุกดี
ทั้งหมดนั้นสนุกมาก แต่ตอนนี้ดีใจจริง ๆ ที่แทบทำแต่ซอฟต์แวร์อย่างเดียว
แม้เซิร์ฟเวอร์จะไม่ได้ลุกไหม้จริง ๆ แต่การเปิดหน้าต่างแล้วใช้พัดลมยังเกิดขึ้นที่ ดาต้าเซ็นเตอร์ Equinix CH1 ใน Chicago เมื่อเดือนมกราคม 2024 ด้วย Azure ExpressRoute ล่ม
ได้ยินมาว่าอาจหนาวเกินไปจน CRAC เอาไม่อยู่ เขาว่ากันว่าเปิดประตูและหน้าต่างทั้งหมดไว้เพื่อพยายามรักษาความเย็นให้พอ แต่สุดท้ายก็ล้มเหลว ถ้า CRAC ไป เซิร์ฟเวอร์ก็ไปด้วย
สวิตช์ตัวนั้นต้องถูกสาปแน่ ๆ ช่วงท้ายสัปดาห์เดียวกัน อุปกรณ์ตัวเดิมเกิดตั้งค่า spanning tree ผิด ทำให้ LINX หยุดไปหลายชั่วโมง และครึ่งหนึ่งของการ peering ของ ISP ในอังกฤษตกอยู่ในความวุ่นวายชั่วคราว คนอื่น ๆ ที่เกี่ยวข้องกับโปรเจ็กต์นั้นก็เสียชีวิตกันหมดภายใน 2 ปี
หลายปีต่อมาไปเดินดูสถานที่นั้น ซากที่ถูกย่างยังคงอยู่บนพื้นข้างล่าง
ประโยคในบทความที่ว่า “แม้จะจ่ายปีละหลายล้านดอลลาร์ ก็ยังได้การซัพพอร์ตเท่ากับคนที่จ่าย 100 ดอลลาร์” นี่เจ็บแปลบเลย เป็นปัญหาใหญ่พอสมควรของ Google
ที่บทความนี้น่าสนใจเป็นพิเศษ เพราะตอนสร้างอินฟราสตรักเจอร์ของ Blekko เราก็ผจญภัยคล้าย ๆ กัน
สำหรับบริษัทอย่าง Blekko ที่มีทราฟฟิกระหว่างแร็ก หรือ ทราฟฟิกตะวันออก-ตะวันตก มากกว่าทราฟฟิกเข้าออกอินเทอร์เน็ต การที่บริการซึ่งวางอยู่ร่วมกันทางกายภาพไม่ต้องแย่งแบนด์วิดท์กับเซิร์ฟเวอร์อื่นเป็นสิ่งจำเป็น และประหยัดกว่าการจ่ายต้นทุนกรณีพิเศษแบบนี้บน SoftLayer หรือก็คือคลาวด์ลูกของ IBM มาก
ยังมีบริษัทที่ทำ enclosure ครอบ cold aisle ได้ค่อนข้างเจ๋ง โดยพื้นฐานแล้วช่วยให้ลมเย็นทั้งหมดที่ออกจากพื้นไหลเข้าไปด้านหลังเซิร์ฟเวอร์ และไม่รั่วไปที่อื่น ทั้งยังป้องกันไม่ให้อากาศที่เย็นน้อยกว่าจากด้านข้างถูกดูดม้วนเข้าไปในเซิร์ฟเวอร์
การคำนวณความจุ HVAC CRAC ของดาต้าเซ็นเตอร์ก็น่าสนใจเหมือนกัน ในสถานที่โคโลเคชันแห่งแรก เรามีสิทธิ์ปฏิเสธก่อนสำหรับการขยายไปยังพื้นที่บนพื้นข้างเคจของเรา แต่พอถึงเวลาขยายจริง สถานที่นั้นไม่เหลือความจุทำความเย็นแล้ว จึงไม่มีความหมายอะไรเลย
ถ้าได้ผ่านกระบวนการแบบนี้มาแล้ว จะเข้าใจ โซลูชัน 0xide ได้ดีขึ้นมาก
ต้องทำแบบนี้ถึงจะสร้าง บริษัทที่ครองตลาด ได้ ดีแล้วที่ไม่สนใจสามัญสำนึกแบบคร่ำครวญที่ทำให้ติดอยู่กับ hyperscaler
ถ้าเป็นบริษัทอินฟราสตรักเจอร์ ก็ควรเป็นเจ้าของ bare metal ที่ขายเอง ไม่อย่างนั้นก็เป็นแค่นายหน้าคลาวด์ และเสี่ยงจะถูกคู่แข่ง bare metal ที่มีต้นทุน egress 0 ดอลลาร์กดราคาตลอดเวลา
เพราะสามารถทำให้ต้นทุน egress เป็น 0 ดอลลาร์ได้ด้วยโคโลเคชันและ peering Cloudflare จึงเสนอแพ็กเกจฟรีได้ และผู้เล่นหน้าใหม่ที่เอาบริการคลาวด์มาขายต่อก็ไม่สามารถแข่งกับ Cloudflare ได้
จริง ๆ แล้ว สำหรับ hyperscaler การคิดค่าแบนด์วิดท์แพงเกินจริงไม่ใช่แค่แหล่งรายได้ แต่เป็น คูเมือง ด้วย มันทำให้ไม่สามารถสร้าง AWS ถัดไปบน AWS ได้ และสร้างเซกเมนต์ตลาดใหม่ที่เรียกว่า “PaaS” บน IaaS ซึ่งอ่อนแอกว่าในเชิงกลยุทธ์โดยสิ้นเชิง
ด้วยวิธีนี้ เราจะลดต้นทุนนั้นลงครึ่งหนึ่ง ลดต้นทุนสตอเรจ และยังเลิกคิดราคา “ต่อที่นั่ง” ได้ด้วย
ตั้งตารอจริง ๆ
เป็นบทความที่ค่อนข้างดี สิ่งหนึ่งที่ผุดขึ้นมาคือ ทำไมถึงสร้างเครื่องมือภายในสำหรับจัดการแร็กเอง ทั้งที่มี NetBox อยู่แล้ว
NetBox เป็นของที่ยอดเยี่ยม และถ้ามีมันตอนที่ผมต้องจัดการแร็กมากกว่า 50 แร็กช่วงกลางยุค 2000 ก็คงดีมาก
https://github.com/netbox-community/netbox
แต่เหตุผลที่เครื่องมือที่เราสร้างเองอย่าง Railyard เข้ากันได้ดี ก็เพราะมันผสานรวมลึกกับทั้งสแต็กซอฟต์แวร์ ฮาร์ดแวร์ และ orchestration ของเรา
ปัญหาของเครื่องมือโอเพนซอร์สคือมันทั่วไปเกินไป แทนที่จะแก้ปัญหา กลายเป็นต้องบิดปัญหาให้เข้ากับ data model ของเครื่องมือนั้น
ท้ายที่สุดแล้ว มีความเป็นไปได้สูงที่เราจะผสานเครื่องมือนี้เข้าไปใน Railway เอง ถ้าคุณอยากไปทาง on-premise ก็ให้บริการตั้งแต่การออกแบบฮาร์ดแวร์ การ commissioning การ deploy ไปจนถึง developer experience ได้ด้วยการคลิกปุ่ม แนวคล้ายกับสิ่งที่ Oxide ทำ แต่เข้าหาจากอีกด้านหนึ่ง
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox พยายามจะเป็น “แหล่งความจริง (source of truth) ของโครงสร้างพื้นฐานเครือข่าย”
สิ่งที่สำคัญย่อมต่างกันไปตามแต่ละสถานการณ์ แต่ถ้า NetBox ตั้งเป้าเป็นคลังกลาง โดยไม่ยืนกรานว่าบางรายการห้ามมีระบบอื่นเป็นแหล่งความจริง เรื่องอาจต่างออกไป
เราได้เรียนรู้แล้วว่าความพยายามจะรวมความซับซ้อนและการควบคุมไว้ที่ศูนย์กลางนั้นใช้ไม่ได้ หลังจาก Clinger-Cohen Act ผ่านได้ไม่นานก็แทบจะรู้กันแล้ว และตอนนี้ ITIL กับ TOGAF ก็พูดถึงเรื่องนี้อย่างชัดเจนด้วย คิดว่าอีกไม่กี่ปีข้างหน้า เหล่าที่ปรึกษาน่าจะหยิบประเด็นนี้ไปเล่นกันมาก
สิ่งที่จำเป็นคือวิธีที่สอดคล้องกันจากส่วนกลางในการค้นหาสถานะ เพื่อไม่ให้มีคำถามว่าควรไปหาข้อมูลที่เชื่อถือได้จากที่ไหน
แต่ถ้าต้องการขยาย เติบโต หรือปรับตัวรับการเปลี่ยนแปลงใหม่ ๆ ก็ควรหลีกเลี่ยงระบบเชิงบังคับแบบ กล่องเทพแบบรวมศูนย์ เช่นนี้
ไม่ใช่ซอฟต์แวร์ที่ใช้งานแล้วรู้สึกคุ้มค่านัก
เป็นตัวอย่างที่พบบ่อยของ “เราต้องการ X และ Y ทำ X ได้” โดยมองข้ามไปว่า Y ยังทำ Z, M, Q และล้างจานได้ด้วย ทั้งที่เราไม่ได้ต้องการสิ่งเหล่านั้น
บางครั้งวิธีที่ง่ายที่สุดคือสร้างเฉพาะสิ่งที่ต้องการ โดยเฉพาะถ้าสิ่งที่ต้องการเป็นแค่ CRUD หน้า database
ในความเป็นจริงมันเป็นแค่การขยายขอบเขตเท่านั้น NetBox เป็นจุดเริ่มต้นที่ดีถ้าคุณเริ่มจากตรงนั้นและยินดีจะปรับระบบให้ล้อมรอบมัน
แต่ถ้าคุณมีระบบอยู่แล้ว หรือจำเป็นต้องทำสิ่งที่ไม่เข้ากับตรรกะของ NetBox ก็มีแนวโน้มว่าการขยายระบบเดิมจะดีกว่า
ในกรณีนี้ Railway ต้องใส่ใจกับข้อมูลเพิ่มเติมอีกมาก นอกเหนือจากแร็ก, IP address และเซิร์ฟเวอร์จริง
ผมเคยทำ automation สำหรับซ่อมอุปกรณ์ ในบริษัทเทคโนโลยีขนาดใหญ่ งานซ่อมมักถูกประเมินค่าต่ำไป แต่ผมมองว่าเป็นหนึ่งในงานที่จัดการยากกว่าอย่างอื่น
เวลารันบน AWS แทบไม่ต้องสนใจฮาร์ดแวร์ที่เสีย เพราะโดยมากมันจะถูกซ่อมเอง
ถ้าดำเนินการเองก็ไม่มีความหรูหราแบบนั้น ต้องมีอะไหล่สำรอง ช่างเทคนิคที่จะซ่อม ขั้นตอนถอดงานออกจาก host แล้วใส่กลับเข้าไป test suite เครื่องมือ monitoring ฮาร์ดแวร์ และอื่น ๆ อีก 1001 อย่าง
ในสเกลเล็ก ๆ อาจพอปล่อยผ่านบางส่วนแบบลวก ๆ ได้ แต่สุดท้ายก็จะโดนมันเล่นงาน นี่พูดถึงแค่เรื่องเซิร์ฟเวอร์เท่านั้น
อุปกรณ์เครือข่ายก็มีชุดปัญหาสนุก ๆ อีกต่างหาก และถ้าล้มเหลวก็อาจทำให้ทั้งแร็กล่มได้ คุณเชื่อได้แค่ไหนว่า colocation provider จะไม่ไฟดับระหว่างโหลดพีก? หวังว่าจะมีการทำ disaster recovery drill เตรียมรับสถานการณ์แบบนี้
ขอให้ทีมนี้โชคดี ดูน่าสนุกดี
ทำให้นึกถึงบางวันในเส้นทางอาชีพของผม ช่วงปี 2003~2010 ต้อง deploy เซิร์ฟเวอร์หลายหมื่นเครื่อง และได้เรียนรู้เรื่องที่น่าสนใจเกี่ยวกับ data center ไม่น้อย
การจัดการสายเคเบิลและการทำมาตรฐาน สำคัญอย่างยิ่งยวด แนวปฏิบัติที่เละเทะเอาตัวไม่รอด
ในที่ที่ deploy เซิร์ฟเวอร์หลายร้อยเครื่องต่อสัปดาห์ ถ้าเซิร์ฟเวอร์แตกต่างจากคลัสเตอร์หลัก ๆ ตัวหนึ่ง operator จะมีเมนูให้เลือก โดยพื้นฐานแล้ว chassis มี 2 แบบ คือเซิร์ฟเวอร์ดิสก์ความจุสูง 2U หรือกล่องพิซซ่า 1U ส่วนดิสก์เลือกได้ระหว่าง SCSI 9/36/146GB
ทั้งหมดเป็น dual-processor ที่ใช้โปรเซสเซอร์รุ่นเดียวกัน และด้านล่างของแร็กจะใส่กล่อง 2U ราว 10 เครื่อง ที่เหลือเติมด้วยกล่อง 1U มากกว่า 20 เครื่อง
ถ้าจำไม่ผิด เราได้ราคาค่าไฟในเงื่อนไขดีมาก ซึ่งน่าจะเป็นเพราะใช้แร็กของ facility ภายใน cage ถ้าใช้แร็กนั้น เหมือนว่าจะได้วงจร 30A 240V สองวงจรแรกฟรี
เป็นสัญญา 10 ปี และไม่มีการวัดมิเตอร์ เราเลยอัดแต่ละแร็กให้แน่นที่สุด ด้านหนึ่งใส่ 30A สองวงจร อีกด้านใส่ 20A สองวงจร
เมื่อคิดถึงความร้อนและการใช้ไฟที่เราปล่อยออกไป data center น่าจะเกือบถึงจุดคุ้มทุนพอดี บางทีอาจชดเชยด้วยค่าการเชื่อมต่อหรือ peering
จำรายละเอียดไม่ค่อยได้แล้ว คงต้องไปถามเพื่อนที่ทำงานที่นั่นในสมัยนั้นเพื่อยืนยัน
มีบางที่ที่ควรอยู่บนคลาวด์ และบางที่ที่ไม่ควรอยู่ ตัวอย่างที่ดีที่สุดคือแอปพลิเคชันที่ใช้ แบนด์วิดท์สูง หรือใช้ดิสก์เยอะ
ดู Netflix แทบทุกอย่างอยู่บนคลาวด์ แต่การส่งวิดีโอจริงทำด้วยฮาร์ดแวร์ของตัวเอง แม้ในสเกลของ Netflix ก็ยังน่าสงสัยว่าถ้าจ่ายเงินให้คนอื่นทำสิ่งนี้จะคุ้มในเชิงเศรษฐศาสตร์หรือไม่
ถ้าลองปรับตัวเลขที่เห็นบ่อย ๆ เล็กน้อย การส่งออก 20PB ที่ GB ละ 0.02 ดอลลาร์ จะเป็น 400,000 ดอลลาร์ต่อเดือน
20PB เทียบคร่าว ๆ ได้กับ 67Gbps ที่ประมาณ 95th percentile
วงจร 100Gbps แบบเหมาจ่ายนั้นหาได้ไม่ยากแม้ราคา 5,000 ดอลลาร์ต่อเดือน
แน่นอนว่านี่เป็นการคำนวณที่เรียบง่ายเกินไป และในความเป็นจริงมีปัจจัยอีกมาก แต่ส่วนต่างก็ยังใหญ่อยู่ดี
สำหรับบางบริษัท ปีละ 4.68 ล้านดอลลาร์อาจไม่ใช่เรื่องใหญ่อะไร แต่สำหรับบางบริษัทอาจเป็นเงินที่ชี้เป็นชี้ตายได้
ถ้ามีรายละเอียดมากกว่านี้อีกเยอะ ๆ ก็คงดี ส่วน WTF ชอบที่สุด
อุปกรณ์น่าจะต้องมีป้ายประมาณว่า “หันด้านนี้เข้าหาศัตรู” หรือ affordance ที่เหมาะสมให้เสียบเข้าได้ทางเดียวเท่านั้น
ได้ทำเลย์เอาต์ให้เป็นมาตรฐานในระดับแร็กไหม? ใส่ ขั้นตอน poka-yoke แบบไหนไว้เพื่อป้องกันความผิดพลาดบ้าง?
สแตกตั้งแต่ bare metal ไปจนถึงการบูตหน้าตาเป็นอย่างไร?
ในฐานะคนที่เคยทำงานกับผู้ให้บริการคลาวด์ต่างกันสองราย และเคยสร้างคลาวด์ภายในเองด้วยโฮสต์ PXE boot เรื่องแบบนี้น่าสนใจมากจริง ๆ
ตอนเริ่มดาต้าเซ็นเตอร์ใหม่ ควรใช้โอกาสให้เต็มที่เพื่อทดสอบทุกสถานการณ์ความล้มเหลวที่นึกออก และรวมถึงสถานการณ์ที่นึกไม่ถึงด้วยการฉีดความขัดข้องแบบสุ่ม
ตอนนี้เรากำลังทำมาตรฐานเลย์เอาต์ระดับแร็กอยู่ เพิ่งมารู้ตัวหลังไซต์ที่สองนี่เอง ทำให้การตรวจสอบง่ายขึ้นมาก
การตรวจสอบทำได้ยาก และจนถึงตอนนี้ยังทำแบบแมนนวลอยู่ อยากลองดึงข้อมูล LLDP ออกมา แต่สแตกซอฟต์แวร์ของสวิตช์มีบั๊ก
มันเป็นกระบวนการที่พัฒนาไปเรื่อย ๆ ยิ่งทำงานกับผู้รับเหมางานติดตั้งต่างรายกัน ก็ยิ่งเจอและนำกรณีพิเศษเข้ามารองรับมากขึ้น
การปรับปรุงที่ใหญ่ที่สุดคือการสร้าง DCIM ภายในเพื่อทำให้การออกแบบแร็กเป็นเทมเพลต และส่งออก “ตัวสำรวจการเดินสาย” แบบอินเทอร์แอกทีฟให้ช่างเทคนิคหน้างานใช้ รวมถึงไดอะแกรมอุปกรณ์ที่ใส่คำอธิบายละเอียด เช่น ชื่อพอร์ตต่าง ๆ ด้วย ภาพหน้าจอแผนผังระดับความสูงของแร็กในบทความก็เป็นส่วนหนึ่งของเครื่องมือนั้น
ตั้งแต่ bare metal ไปจนถึงการบูต เรามีของที่แฮ็กทำขึ้นบน https://github.com/danderson/netboot/tree/main/pixiecore โดยให้บริการ Debian netboot และไฟล์ preseed
ยังมี Temporal worker แบบคัสตอมที่เชื่อมต่อกับ Redfish API ของ BMC เพื่อควบคุมอุปกรณ์นี้ด้วย จากนั้นเอเจนต์โฮสต์แบบคัสตอมจะ provision QEMU VM และบนโฮสต์จะใช้ FRR เพื่อประกาศ IP ที่ถูกจัดสรรผ่าน BGP
เรื่องสถานการณ์ความล้มเหลวของดาต้าเซ็นเตอร์ใหม่ เราเคยทดสอบด้วยการทำให้เบรกเกอร์ทริปแล้ว และจากนั้นก็พบว่า phase balancing เพี้ยนไป ที่อีกไซต์หนึ่ง เราเอากล้องถ่ายภาพความร้อนเข้าไปด้วย
สัปดาห์หน้าไซต์ AMS จะขึ้นมา เป้าหมายคือดูว่าเราจะดันสวิตช์แฟบริกที่ใส่เต็มแล้วไปได้ไกลแค่ไหน
บทความดีมาก เมื่อจำเป็นต้องใช้ ความเร็ว 100G Google คิดราคาหนักจริง ๆ แทบจะเหมือนดูหมิ่นกันเลย
ตัวอย่างเช่น Dedicated Interconnect 100G แบบทำซ้ำเพื่อความทนทานมีค่าใช้จ่ายราว 35,000 ดอลลาร์ต่อเดือน และยังไม่รวม VLAN attachment, ค่า cross-connect ในโคโลเคชัน, transit ฯลฯ แถม VLAN attachment ยังสูงสุดแค่ 50G
ถ้าเทียบค่าใช้จ่ายนี้ เงินเท่ากันสามารถซื้อสวิตช์ Arista 100G รุ่นใหม่แบบ 32 พอร์ตได้ 2 ตัว
ในอเมริกาเหนือ สามารถหา circuit 100G WAN หรือก็คือ managed Wavelength ได้ในราคาต่ำกว่า 5,000 ดอลลาร์ต่อเดือน ถ้าเป็นเมโทรในพื้นที่ ก็อาจหา dark fiber ได้ถูกกว่าแล้วรันที่ความเร็วตามต้องการได้ด้วย