Hành trình Railway tự xây dựng trung tâm dữ liệu riêng
(blog.railway.com)- Railway nhận thấy hạ tầng compute dựa trên GCP đang hạn chế giá cả, hỗ trợ và phát triển tính năng, nên đã khởi động Railway Metal, một hạ tầng vật lý cho phép kiểm soát trực tiếp hơn
- Sau khi bắt đầu vào tháng 1/2024, Railway mất 5 tháng để kết nối máy chủ đầu tiên và thêm 3 tháng nữa trước khi đưa workload của người dùng lên; sau 9 tháng, site đầu tiên tại California đi vào hoạt động
- Ràng buộc lớn hơn chi phí thuê mặt bằng là điện năng và làm mát; thay vì Greenfield hay thuê theo từng rack, Railway chọn Cage Colocation
- Về mạng, họ triển khai tối thiểu 2 ISP cho mỗi khu vực, nhận toàn bộ bảng định tuyến Internet, chọn tuyến theo từng IP prefix và thiết kế nhiều zone để phòng ngừa sự cố ở một trung tâm dữ liệu đơn lẻ
- Họ phải tự xử lý từ bố trí rack, tài liệu cáp, PDU, switch reverse airflow, Redfish API, PXE, FRR đến SONiC; việc xây dựng cloud riêng giống xây nhà hơn là triển khai bằng Terraform
Vì sao chuyển từ GCP sang Railway Metal
- Compute của Railway ngay từ đầu được xây dựng trên Google Cloud Platform
- GCP hữu ích cho giai đoạn tăng trưởng ban đầu, nhưng khi quy mô vận hành lớn lên thì bắt đầu bộc lộ giới hạn trong việc cung cấp nền tảng mà khách hàng mong muốn
- Vận hành trên hyperscaler trực tiếp giới hạn mức giá, cấp độ dịch vụ và phạm vi phát triển tính năng mà Railway có thể cung cấp
- phí egress ảnh hưởng đến giá
- ngay cả khi xảy ra sự cố ở tầng hạ tầng phía trên, hiếm khi hiểu được nguyên nhân gốc rễ
- theo đánh giá của họ, dù chi hàng triệu USD mỗi năm thì mức hỗ trợ nhận được cũng không khác nhiều so với việc chỉ chi 100 USD
- Để đối phó, Railway đã khởi động dự án Railway Metal vào năm 2024
- 9 tháng sau, site đầu tiên tại California đi vào hoạt động
- họ tự thiết kế, xác định cấu hình và triển khai mọi thứ từ cáp quang trong cage đến hợp đồng với ISP
- đồng thời đang bật thêm 3 region trung tâm dữ liệu khác
Lựa chọn không gian đầu tiên: cage trong trung tâm dữ liệu
- Dự án Railway Metal bắt đầu vào tháng 1/2024 và mất 5 tháng để kết nối máy chủ đầu tiên
- Sau đó cần thêm 3 tháng nữa trước khi họ tin rằng phần cứng đã sẵn sàng để chạy workload của người dùng
- Hạ tầng riêng đòi hỏi không gian để đặt máy chủ, nguồn điện ổn định và khả năng làm mát đủ lớn
- Có ba lựa chọn chính
- Greenfield buildout: mua hoặc thuê cả trung tâm dữ liệu
- Cage Colocation: có một không gian riêng được bao quanh bằng vách lưới bên trong trung tâm dữ liệu của nhà cung cấp
- Rack colocation: thuê từng rack riêng lẻ hoặc một phần rack trong trung tâm dữ liệu colocation
- Railway chọn Cage Colocation để có được một không gian trống với bốn bức tường, cửa bảo mật và khả năng tự thiết kế phần còn lại
- Chi phí bản thân không gian không quá lớn, nhưng điện năng và chi phí làm mát đi kèm mới là phần tốn kém nhất
- chi phí theo kW khác nhau đáng kể tùy khu vực
- ở bờ Tây nước Mỹ, mức giá có thể chưa tới một nửa so với Singapore
- điện được thanh toán theo cam kết hàng tháng để đảm bảo khả năng sẵn sàng on-demand, bất kể mức sử dụng thực tế
Thiết kế điện và PDU
- Railway trước tiên xác định số lượng vCPU, GB RAM và TB NVMe mục tiêu để tương ứng với dung lượng họ từng dùng trên GCP
- Dựa trên các con số đó, họ chọn máy chủ và CPU
- Biến số cốt lõi là mật độ điện năng: đưa được mật độ compute mong muốn vào trong một mức tiêu thụ điện cụ thể
- Việc tính toán điện năng không chỉ là cộng watt, đặc biệt với nguồn điện 3 pha thì còn phức tạp hơn
- bài viết giới thiệu về điện 3 pha và PDU của Cloudflare nói về chủ đề này
- Trong trung tâm dữ liệu, điện là tài nguyên quan trọng nhất và một sự cố mất điện có thể cần thời gian rất dài để khôi phục
- Mỗi rack cần 2 đường cấp điện hoàn toàn độc lập
- trong điều kiện bình thường, hai đường cấp sẽ chia tải
- hệ thống vẫn phải chịu được khi một đường cấp bị mất
- Để cấp điện tới máy chủ, cần có Power Distribution Unit
- PDU cơ bản gần như chỉ là ổ cắm điện kéo dài dạng mở rộng
- các PDU mà Railway triển khai cho phép điều khiển và đo lường từng ổ cắm riêng lẻ
- mỗi PDU đều có thể truy cập qua mạng để đo lường và điều khiển từ xa từng ổ cắm
Mạng: ISP, định tuyến và đường đi theo từng khu vực
- Máy trong cloud không tồn tại độc lập, nên mạng đóng vai trò cốt lõi
- Railway tìm kiếm các cơ sở trung tâm dữ liệu có kết nối mạnh mẽ ra thế giới bên ngoài để đảm bảo độ trễ thấp
- Các điều kiện ưu tiên gồm
- kết nối on-network với Tier 1 ISP
- có mặt trong các Internet Exchange
- có cáp quang kết nối tới các trung tâm dữ liệu lân cận
- Ứng dụng triển khai trên Railway giao tiếp với nhiều loại endpoint khác nhau
- người dùng Internet dân dụng ở Sydney
- API được host trên máy chủ AWS tại Mỹ
- Để có độ trễ thấp và chi phí băng thông thấp, Railway ký hợp đồng với nhiều nhà cung cấp Internet khác nhau, tối ưu theo từng use case
- ISP được chọn dựa trên độ trưởng thành của mạng tại khu vực mục tiêu
- làm việc với ISP không phù hợp có thể tạo thêm network hop tới thị trường mục tiêu và làm tăng độ trễ
- trong trường hợp xấu nhất, có thể hình thành những tuyến mạng vòng vèo phức tạp
- tại mỗi khu vực, họ chọn tối thiểu 2 mạng riêng biệt dựa trên footprint địa phương
- Sau khi kết nối, họ nhận toàn bộ bảng định tuyến Internet từ mỗi ISP rồi hợp nhất trên switch mạng để quyết định đường đi tối ưu theo từng IP prefix
- nếu người dùng ở Úc truy cập một ứng dụng triển khai tại Singapore, gói tin nhiều khả năng sẽ được chuyển qua Telstra
- nếu cùng ứng dụng đó gửi gói tin tới người dùng hoặc máy chủ ở Nhật, nhiều khả năng sẽ chuyển qua PCCW
- Thông tin peering là công khai và có thể xem mối liên kết giữa các mạng tại bgp.tools
- Để dự phòng, Railway xây nhiều zone trong mỗi region và xem mở rộng liên kết giữa các site là yếu tố quan trọng
- họ cân nhắc các công cụ như dark fiber hoặc wavelength service
- mục tiêu là ứng dụng không cảm nhận được khác biệt giữa việc cơ sở dữ liệu ở cùng một phòng hay ở tòa nhà cách đó 4 dãy phố
- đây là thiết kế để tăng khả năng phục hồi trước sự cố của từng trung tâm dữ liệu riêng lẻ
Rack, lối đi, làm mát và đường đi của cáp
- Trong trung tâm dữ liệu, các rack được xếp thành hàng và khoảng không giữa các rack được dùng cho luồng khí
- Ở Cold Aisle, không khí lạnh từ cơ sở hạ tầng được đưa vào; máy chủ hút luồng khí này rồi thải ra phía sau vào Hot Aisle
- Để tăng hiệu quả, không khí giữa Cold Aisle và Hot Aisle không nên bị trộn lẫn
- Dù dùng thiết bị chuẩn rộng 19 inch, rack vẫn có thể được chọn chiều cao, chiều rộng và chiều sâu theo yêu cầu của thiết bị và cáp
- Phần lớn thiết bị máy chủ có thể kéo ra phía trước trên ray để bảo trì, nên kích thước cage phải cho phép điều đó
- Cáp và việc quản lý cáp cũng cần không gian, tạo ra sự đánh đổi giữa việc xếp rack dày đặc đến đâu và có thể đặt bao nhiêu rack trong cage
- Theo kinh nghiệm của Railway, điện năng và làm mát thường là ràng buộc lớn hơn diện tích thực tế
- Ở các site mới, họ chọn rack rộng 800mm để cải thiện airflow bằng cách đưa cáp ra khỏi đường thoát khí
- Ngoài rack, còn cần hạ tầng và máng cáp phía trên để truyền điện và dữ liệu
- cáp quang được kéo từ rìa cage tới từng rack
- cáp giữa các rack cũng cần được định tuyến
- các hạng mục này đôi khi được đơn vị vận hành trung tâm dữ liệu đưa vào báo giá cage
- Railway mua switch reverse airflow vì mật độ cáp quang từ switch tới server trên mỗi rack rất cao
- đây là loại switch thổi khí nóng ra phía có các cổng mạng
- họ căn chỉnh cable tray để toàn bộ hệ thống cáp đi ở một bên rack
- nhờ đó tránh tình huống cáp ngoằn ngoèo qua lại giữa mặt trước và mặt sau rack
Tài liệu lắp đặt và rack-and-stack
- Railway ban đầu tự thử đi dây, nhưng kết quả không đồng đều nên đã phải nhờ chuyên gia để lắp đặt đúng chuẩn
- Cần có một bộ tài liệu đầy đủ để đội lắp đặt biết chính xác phải đặt gì ở đâu
- Tài liệu thông thường có hai loại
- Cabling matrix: xác định vị trí thiết bị ở hai đầu mỗi sợi cáp, cổng kết nối, cấu hình cáp, loại cáp quang, chiều dài, v.v.
- Rack elevation: thể hiện trực quan vị trí và hướng của từng thiết bị trong rack
- Mỗi giai đoạn lắp đặt của Railway bao gồm hơn 60 thiết bị, hơn 300 sợi cáp riêng lẻ và hàng chục chi tiết nhỏ
- Các đặc tả bằng văn bản và bảng tính làm nền tảng cho việc lắp đặt và nghiệm thu đều được tạo thủ công
- Sau khi vật tư đến hiện trường, mất khoảng 6–14 ngày để hoàn tất toàn bộ việc lắp đặt
- Về sau, Railway đã tạo công cụ nội bộ để tự động hóa việc sinh build specification
- Xây dựng cage trong trung tâm dữ liệu rất xa với việc triển khai stack phần mềm, DevOps hay Terraform thông thường; nó giống xây nhà hơn
- Giữa các cơ sở trung tâm dữ liệu, nhà thầu và vendor, cách làm có thể khác nhau đôi chút ngay cả trong cùng một tổ chức, nên vận hành đòi hỏi mức độ chú ý rất chi tiết
Những ngoại lệ và vấn đề vật lý tại hiện trường
- Ở một site, PDU bị lắp ngược, khiến nguồn điện đi từ phía sàn lên và số thứ tự ổ cắm so với kế hoạch bị đảo ngược
- Tại Amsterdam, có cơ sở hạ tầng đưa đường cáp quang bên ngoài trực tiếp vào một hộp trong rack thay vì qua demarcation point riêng
- Một số cơ sở khác những site còn lại ở chỗ ổ cắm điện được đi dây theo kiểu phase-to-neutral, trong khi nơi khác lại là phase-to-phase
- Có trường hợp nhà thầu không biết thiết bị mạng dùng reverse airflow nên định lắp theo hướng ngược lại và kết luận rằng cáp dữ liệu quá ngắn
- Việc một số cáp không lên link hóa ra là do lỗi polarity của cáp quang; cũng từ đó Railway biết đến khái niệm “rolling fibre cables”
- tức là tháo đầu cắm của LC connector rồi đổi chéo chúng cho nhau
- Khoảng 24 PDU của một vendor gặp lỗi ổ cắm khiến phích điện không gắn chặt được, và ngay cả dùng lực vật lý mạnh cũng không khắc phục được
Công việc phần mềm sau khi hoàn tất lắp đặt vật lý
- Khi phần cứng đã vào vị trí, công việc chuyển sang mảng phần mềm quen thuộc hơn
- Các hạng mục cần làm gồm
- cấu hình BGP
- cài đặt OS
- thiết lập monitoring
- cấu hình thiết bị mạng
- viết cấu hình router
- cập nhật hồ sơ tại RIR, tức regional internet registry
- Họ dùng Redfish APIs để truy cập các controller chuyên dụng của máy chủ và PDU
- Họ dùng PXE để khởi động máy chủ qua mạng
- Thiết kế mạng của Railway sử dụng các whitebox network switch chạy FRR và SONiC
- Thiết kế này cho phép xây dựng một mạng điều khiển bằng phần mềm chỉ L3, tích hợp sâu với Railway control plane
- Trong vài tháng gần đây, Railway đã tạo ra các công cụ phần mềm mới là Railyard và MetalCP
- thiết kế cage mới
- theo dõi và trực quan hóa cáp
- cài đặt OS cho máy chủ
- là các công cụ giúp biến cả quá trình kết nối máy chủ với Internet thành trải nghiệm có thể thực hiện chỉ bằng vài cú nhấp chuột
- Trong các bài viết tiếp theo, họ sẽ nói về cách biến một cụm máy chủ trong phòng thành một Railway zone hoạt động đầy đủ
1 bình luận
Ý kiến trên Hacker News
Theo kinh nghiệm của tôi và qua những bài như thế này, Google dường như ghét việc có khách hàng
Có vẻ như ai đó đã quyết định rằng “phải làm public cloud” nên họ xây nó, nhưng lại có cảm giác họ muốn đẩy khách hàng ra xa bằng cây sào dài 3 mét
Tôi tin 100% rằng người phụ trách tài khoản bên AWS là kiểu người sẵn sàng lăn xuống bùn cùng mình nếu cần. Khi có khủng hoảng mà nhờ giúp, họ sẽ ngủ dưới sàn cùng mình
Ngược lại, nhìn những người phụ trách Google Cloud lại thấy buồn. Vì có thể thấy họ cũng được yêu quý và được hỗ trợ trong nội bộ Google còn ít hơn cả chúng ta. Thật đáng tiếc khi nhìn những người phải cố thuyết phục chính công ty mình bán hàng và cung cấp dịch vụ cho tử tế, như thể họ được sắp đặt để thất bại
Người bên Microsoft thì cứng như áo giáp, bán hàng giỏi, cung cấp dịch vụ cũng giỏi, và hút sạch tiền khỏi túi tôi mà vẫn khiến tôi sống chết tin rằng đó là điều tốt cho mình. Chỉ là cloud của họ là một thứ rất kỳ lạ… gì đó
Việc Railway chuyển sang bare metal thì, với người đã làm chừng 15 năm như tôi, là thứ tôi tuyệt đối, tuyệt đối, tuyệt đối không muốn quay lại. Không đáng chút nào. Nhưng chắc phải tự mình trải qua mới hiểu, vốn dĩ con đường này là vậy
Rồi sớm muộn cũng sẽ hiểu vì sao Google lại khổ sở đến thế. Chỉ cần thật sự có quyết tâm bán dịch vụ cho con người thay vì xây Borg hay bộ não nhân tạo, thì có thể làm tốt hơn Google gấp 100 lần
Dù vậy tôi vẫn không nghĩ họ sẽ lăn xuống bùn cùng mình, nên điều đó cũng hơi bất ngờ. Không biết phải chi bao nhiêu mới vào tới cấp độ “đồng hành dưới bùn”
Toàn bộ dịch vụ cloud này cho cảm giác như được thiết kế bởi người hoàn toàn không hiểu cloud computing mà chỉ biết mỗi “thuê máy chủ bare metal”. Nó đúng là cloud computing, nhưng theo cách phá hỏng chính khái niệm cloud computing
Công cụ dòng lệnh GCP là
gcloudcũng cho cảm giác được thiết kế tốt hơnNhư vậy đã có thể tiết kiệm được vài tháng thời gian chuẩn bị trước
Theo trải nghiệm cá nhân, hỗ trợ Google Cloud đối với một đội nhỏ 3 người chi rất ít tiền vẫn khá ổn, và ở công ty khác thì Microsoft cũng đối xử rất tốt. Chỉ là quy mô chi tiêu lúc đó có lẽ đủ lớn để lần theo cả qua hệ thống giám sát lưới điện của trung tâm dữ liệu
Còn AWS thì đã nói dối về tính năng, rồi cuối cùng không trả lời đến cùng
Những người phụ trách tài khoản đang bàn với lãnh đạo cấp cao về các hợp đồng AWS trị giá hàng triệu USD mang tính sống còn dường như rất biết cách phải nói gì với những lãnh đạo đó
Nhưng khi đến giai đoạn thực sự phát triển và cung cấp sản phẩm cho người khác, thì chúng tôi lại bị bỏ mặc trong bụi bặm
Điều buồn cười hơn nữa là tính năng bị nói dối đó lại chính là tính năng được chào bán như yếu tố then chốt để tạo ra trải nghiệm người dùng cuối cực kỳ xuất sắc
Tôi đã trả lời lại ticket hỗ trợ nhưng không có phản hồi, và cũng đã gửi email cho hai người phụ trách AWS nhưng vẫn không nhận được trả lời
Nhớ lại thời Rackspace ngày xưa. Đúng là có rất nhiều chuyện như chiến trường thật sự
Người của EMC đến lắp thiết bị lưu trữ để thử nghiệm, rồi vướng chân vào nhau và làm đổ nguyên cả một rack máy chủ như trong phim hài. Tất nhiên là họ không giành được hợp đồng
Có lần một tài xế xe tải bị đau tim, và vụ tai nạn khiến trung tâm dữ liệu DFW bị offline. Có bollard để ngăn chuyện này, nhưng lúc đó chúng vẫn chưa được đổ bê tông
Có thời điểm người ta còn bắn băng thông bằng laser sang tòa nhà bên kia đường để làm kết nối tạm
Có ngày máy chủ bắt đầu bốc cháy theo đúng nghĩa đen, nên phải đập vỡ cửa sổ và đi mua quạt hộp về
Kỹ thuật trung tâm dữ liệu đã tiến bộ khá nhiều so với thời kỳ đầu. Khi đó tôi đã làm OpenCompute Project cùng Facebook, và vào thời điểm ấy đã có những khái niệm hạ tầng rất đi trước thời đại
Liên kết microwave cốt lõi liên tục rớt, kèm lỗi gói tin ngắt quãng ở rất sâu trong tầng liên kết dữ liệu. Điều tra ra mới biết cây bên kia đường đang ra lá, và cành cây đung đưa vào đúng đường ngắm của thiết bị trên tòa nhà chúng tôi. Một cái thang, một cái cưa, và 10 phút là khôi phục được kết nối
Router BGP chính đi ra ngoài trung tâm dữ liệu cứ khởi động lại liên tục. Không có thiết bị dự phòng. Kiểm tra thì thấy nhiệt độ trung tâm dữ liệu quá cao, làm mát quá tệ, nên không khí ở phía quạt hút đã vượt quá 60°C. Tạm thời dựng quạt chĩa vào đó
Vài tuần sau, điều hòa ở phòng khác cũng hỏng và bắt đầu phun nước lên trên con Nortel DMS-100. Đó là một ISP dial-up có tổng đài riêng. Tôi không hề muốn giúp lau dọn vì nghĩ nước có thể đang dẫn điện, nhưng cuối cùng vẫn phải làm
Sau đó tôi còn làm việc ở một hòn đảo nhỏ hẻo lánh, nơi đường truyền Internet chính là liên kết 1MB/s qua vệ tinh GS, với ping hơn 500ms. Người dân địa phương quay số qua mạng điện thoại microwave được xếp hạng 9600 baud, nhưng bằng cách nào đó modem 56k vẫn hoạt động
Có ngày tôi phát hiện một
.soquan trọng bị thiếu trên một máy Solaris, mà không có backup cục bộ hay bộ cài đặt. Tôi phải gọi cho một người bạn ở Anh nhờ tải bản sao lên một máy chủ FTP, rồi mới cứu được cái máy đó lên lại onlineVài năm sau, tôi còn lắp một liên kết laser băng qua Oxford Road ở Manchester, tuyến xe buýt đông nhất châu Âu lúc bấy giờ, để nối văn phòng với khuôn viên trường đại học. Đúng là một thời kỳ vui nhộn
Tất cả đều rất vui, nhưng giờ gần như chỉ làm phần mềm thôi nên đúng là may mắn thật
Dù máy chủ không bốc cháy theo đúng nghĩa đen, chuyện mở cửa sổ và dùng quạt vẫn xảy ra ở trung tâm dữ liệu Equinix CH1 tại Chicago vào tháng 1 năm 2024. Azure ExpressRoute đã bị sập
Tôi nghe nói trời lạnh quá mức nên CRAC không chịu nổi. Họ đã mở tất cả cửa ra vào và cửa sổ để cố giữ cho đủ lạnh, nhưng cuối cùng vẫn thất bại. Khi CRAC đi thì máy chủ cũng đi theo
Cái switch đó chắc chắn bị nguyền rủa. Cuối tuần đó, trên chính thiết bị cùng loại lại xảy ra lỗi cấu hình spanning tree, làm LINX ngừng hoạt động trong vài tiếng và một nửa số phiên peering của các ISP ở Anh rơi vào hỗn loạn tạm thời. Những người khác liên quan tới dự án đó cũng đều qua đời trong vòng 2 năm
Vài năm sau tôi quay lại thăm cơ sở đó, và cái xác cháy đen vẫn còn nằm trên mặt đất phía dưới
Đoạn trong bài nói rằng “dù chi hàng triệu đô mỗi năm thì cũng chỉ nhận được mức hỗ trợ như người chi 100 đô” thật sự quá đau. Đây là một vấn đề khá lớn với Google
Bài này đặc biệt thú vị với tôi vì khi xây dựng hạ tầng cho Blekko, chúng tôi cũng đã trải qua những cuộc phiêu lưu tương tự
Với những công ty như Blekko, nơi lưu lượng giữa các rack — tức east-west traffic — lớn hơn lưu lượng đi và đến từ Internet, thì việc các dịch vụ được colocate về mặt vật lý không phải tranh chấp băng thông với các máy chủ khác là điều bắt buộc, và như vậy kinh tế hơn rất nhiều so với việc trả tiền cho trường hợp đặc thù này trên SoftLayer, tức đám mây khóa chặt của IBM
Cũng có những công ty rất hay chuyên làm enclosure bao quanh hành lang lạnh. Về cơ bản, chúng bảo đảm toàn bộ luồng khí lạnh đi lên từ sàn sẽ đi vào phía sau máy chủ thay vì rò rỉ ra chỗ khác
Đồng thời cũng ngăn không cho luồng khí kém lạnh hơn từ bên hông cuộn vào máy chủ
Việc tính toán công suất HVAC CRAC của trung tâm dữ liệu cũng rất thú vị. Ở cơ sở colocation đầu tiên của chúng tôi, chúng tôi có quyền ưu tiên từ chối trước đối với phần diện tích sàn bên cạnh cage của mình, nhưng tới lúc thực sự muốn mở rộng thì cơ sở đó không còn dư công suất làm mát nữa, nên quyền đó hoàn toàn vô nghĩa
Sau khi tự mình trải qua quá trình này, bạn sẽ hiểu giải pháp của 0xide hơn rất nhiều
Đây là cách để xây dựng một công ty thống trị. Làm tốt lắm khi phớt lờ thứ lối nghĩ than vãn rằng phải bị trói chặt vào hyperscaler
Nếu là công ty hạ tầng, bạn phải tự sở hữu chính phần bare metal mà mình bán. Nếu không thì bạn chỉ là một nhà môi giới cloud, và lúc nào cũng có nguy cơ bị đối thủ bare metal với chi phí egress bằng 0 đè bẹp về giá
Chính vì colocation và peering có thể đưa chi phí egress về 0 nên Cloudflare mới có thể cung cấp gói miễn phí, và người mới tham gia thị trường không thể cạnh tranh với Cloudflare chỉ bằng cách bán lại dịch vụ cloud
Thực ra, việc hyperscaler chặt chém băng thông không chỉ là một nguồn doanh thu mà còn là hào kinh tế. Nó ngăn không cho ai xây dựng AWS tiếp theo trên chính AWS, đồng thời tạo ra một phân khúc thị trường hoàn toàn mới và yếu thế hơn về chiến lược mang tên “PaaS” ở phía trên IaaS
Việc này có thể cắt một nửa khoản chi đó, đồng thời giảm chi phí lưu trữ và loại bỏ luôn kiểu định giá “theo số ghế”
Thật sự rất háo hức
Đây là một bài viết khá ổn. Một điều nảy ra là tại sao họ lại tự làm công cụ nội bộ để quản lý rack. NetBox đã có sẵn rồi
NetBox rất tuyệt, và hồi giữa những năm 2000 khi phải quản lý hơn 50 rack thì tôi đã ước gì có nó
https://github.com/netbox-community/netbox
Nhưng lý do công cụ chúng tôi làm, Railyard, phù hợp là vì nó được tích hợp sâu với toàn bộ stack phần mềm, phần cứng và orchestration của chúng tôi
Vấn đề của các công cụ mã nguồn mở là chúng quá tổng quát. Thay vì giải quyết vấn đề, bạn lại phải uốn vấn đề cho khớp với mô hình dữ liệu của công cụ đó
Cuối cùng khả năng cao là công cụ này sẽ được tích hợp vào chính Railway. Nếu muốn chạy on-premises thì chỉ cần bấm nút là có từ thiết kế phần cứng, commissioning, triển khai cho tới trải nghiệm nhà phát triển. Tương tự như cách Oxide làm, nhưng tiếp cận từ phía ngược lại
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox muốn trở thành “source of truth” cho hạ tầng mạng
Tùy từng tình huống mà điều quan trọng sẽ khác nhau, nhưng nếu NetBox nhắm tới việc làm kho lưu trữ trung tâm thay vì khăng khăng rằng với một số mục nào đó thì không hệ thống nào khác được phép là nguồn sự thật, thì có lẽ câu chuyện đã khác
Tôi đã học được rằng những nỗ lực tập trung hóa độ phức tạp và quyền kiểm soát thì không hiệu quả. Gần như ngay sau khi Clinger-Cohen Act được thông qua người ta đã biết vậy, và giờ ITIL cùng TOGAF cũng nói rất rõ điều này. Có lẽ trong vài năm tới các consultant sẽ khai thác điểm này khá nhiều
Vẫn cần một cách nhất quán ở trung tâm để tìm trạng thái. Mục đích là để không còn phải băn khoăn nên tìm thông tin có thẩm quyền ở đâu
Nhưng nếu muốn mở rộng, tăng trưởng hoặc thích nghi với thay đổi mới thì nên tránh các hệ thống mang tính quy chuẩn kiểu hộp thần trung tâm như thế này
Không phải loại phần mềm dùng mà thấy đáng công lắm
Đây là ví dụ điển hình của kiểu “chúng ta cần X và Y làm được X”, nhưng lại bỏ qua việc Y còn làm cả Z, M, Q và cả rửa bát, trong khi mình chẳng cần những thứ đó
Đôi khi giải pháp dễ nhất là chỉ làm đúng thứ mình cần. Nhất là khi thứ cần chỉ là CRUD trước một cơ sở dữ liệu
Thực tế chỉ là mở rộng phạm vi ra thôi. NetBox là điểm khởi đầu ổn nếu bạn bắt đầu từ đó và sẵn sàng chỉnh toàn bộ hệ thống xoay quanh nó
Nhưng nếu bạn đã có hệ thống sẵn, hoặc cần làm những việc không khớp với logic của NetBox, thì khả năng cao là cứ mở rộng hệ thống hiện có sẽ tốt hơn
Trong trường hợp này Railway phải quan tâm tới nhiều thông tin bổ sung hơn rất nhiều, vượt ra ngoài rack, địa chỉ IP và máy chủ vật lý
Tôi từng làm tự động hóa sửa chữa thiết bị ở một công ty công nghệ lớn. Theo tôi sửa chữa là một trong những việc bị đánh giá thấp nhưng lại khó xử lý hơn cả
Khi chạy trên AWS thì gần như không phải bận tâm về phần cứng hỏng. Đa phần nó tự được sửa ổn thỏa
Còn khi tự vận hành thì không có sự xa xỉ đó. Bạn cần linh kiện dự phòng, kỹ thuật viên để sửa, quy trình rút workload khỏi host rồi đưa vào lại, test suite, công cụ giám sát phần cứng và 1001 thứ khác nữa
Ở quy mô nhỏ có thể tạm bỏ qua một số thứ, nhưng sớm muộn gì cũng phải trả giá. Mà đây mới chỉ là câu chuyện máy chủ thôi
Thiết bị mạng lại là một chùm vấn đề thú vị khác, và nếu nó lỗi thì có thể làm cả rack ngừng hoạt động. Bạn tin tới mức nào rằng nhà cung cấp colocation sẽ không mất điện đúng lúc tải đỉnh? Mong là bạn có diễn tập khôi phục thảm họa cho những tình huống đó
Chúc đội này may mắn. Trông khá vui đấy
Nó làm tôi nhớ tới vài ngày tháng trong sự nghiệp. Từ 2003 đến 2010 tôi phải triển khai hàng chục nghìn máy chủ và đã học được khá nhiều điều thú vị về trung tâm dữ liệu
Quản lý cáp và tiêu chuẩn hóa là cực kỳ quan trọng. Với những thực hành bừa bộn thì không thể trụ nổi
Ở nơi mỗi tuần triển khai hàng trăm máy chủ, có một menu để operator chọn khi máy chủ khác với một trong các cụm chính. Về cơ bản có 2 loại chassis: máy chủ đĩa dung lượng lớn 2U hoặc pizza box 1U. Ổ đĩa có thể chọn SCSI 9/36/146GB
Tất cả đều là CPU kép dùng cùng một loại bộ xử lý, và ở đáy rack chúng tôi đặt khoảng 10 máy 2U, phần còn lại là hơn 20 máy 1U
Nếu nhớ không nhầm thì chúng tôi được giá điện rất tốt, có lẽ vì dùng rack của cơ sở trong cage. Hình như dùng rack đó thì được miễn phí 2 mạch 30A 240V đầu tiên
Đó là hợp đồng 10 năm và không đo đếm riêng, nên chúng tôi nhồi mỗi rack dày nhất có thể. Một bên có hai đường 30A, bên kia có hai đường 20A
Nghĩ tới lượng nhiệt và điện năng chúng tôi tiêu thụ, có lẽ trung tâm dữ liệu đó gần như chỉ hòa vốn. Có thể họ bù lại bằng chi phí kết nối hoặc peering
Tôi không còn nhớ rõ chi tiết nên phải hỏi lại một người bạn từng làm ở đó thời ấy
Có những nơi phù hợp ở trên cloud, và cũng có những nơi không. Ví dụ điển hình nhất là các ứng dụng băng thông cao hoặc dùng rất nhiều đĩa
Nhìn vào Netflix thì gần như mọi thứ đều ở trên cloud, nhưng việc truyền video thực tế lại chạy trên phần cứng riêng. Ngay cả ở quy mô của Netflix, tôi cũng không chắc nếu trả tiền cho bên khác làm việc này thì có khả thi về mặt kinh tế không
Sửa nhẹ một con số hay gặp: 20PB egress với giá 0,02 USD mỗi GB thì là 400.000 USD mỗi tháng
20PB tương đương khoảng 67Gbps theo mức bách phân vị 95
Không khó để tìm đường truyền flat-rate 100Gbps với giá 5.000 USD mỗi tháng
Tất nhiên đây là phép tính đơn giản hóa quá mức, và thực tế còn nhiều yếu tố hơn rất nhiều. Dù vậy khoảng chênh lệch vẫn rất lớn
Với công ty này thì 4,68 triệu USD mỗi năm có thể chẳng đáng gì, nhưng với công ty khác đó có thể là số tiền quyết định sống còn
Giá mà có nhiều chi tiết hơn nữa. Phần WTF là hay nhất.
Có vẻ thiết bị cần những nhãn kiểu “hãy chĩa mặt này về phía kẻ địch”, hoặc những affordance phù hợp để chỉ có thể lắp theo một hướng
Có chuẩn hóa layout ở mức rack không? Đã đưa vào những quy trình poka-yoke nào để ngăn sai sót?
Stack từ bare metal đến lúc boot trông như thế nào?
Tôi đã làm ở hai nhà cung cấp cloud khác nhau và từng tự xây cloud nội bộ với host PXE boot, nên mấy chi tiết này thực sự rất thú vị
Khi khởi động một data center mới, tốt nhất là tận dụng tối đa để thử mọi kịch bản lỗi có thể nghĩ ra, và cả những kịch bản chưa nghĩ tới bằng cách tiêm lỗi ngẫu nhiên
Giờ thì chúng tôi có chuẩn hóa layout ở mức rack. Phải đến sau site thứ hai mới nhận ra điều đó. Nhờ vậy việc kiểm chứng dễ hơn rất nhiều
Việc kiểm chứng rất khó, và đến giờ vẫn làm thủ công. Tôi muốn thử lấy dữ liệu LLDP, nhưng stack phần mềm switch đang có bug
Đây vẫn là một quá trình liên tục tiến hóa. Càng làm việc với nhiều nhà thầu thi công khác nhau, chúng tôi càng phát hiện và phản ánh thêm nhiều tình huống ngoại lệ
Cải tiến lớn nhất là xây một DCIM nội bộ để biến thiết kế rack thành template, rồi xuất cho kỹ thuật viên hiện trường một “trình khám phá đi dây” tương tác. Trong đó cũng có các sơ đồ chú thích chi tiết của thiết bị, hiển thị tên cổng các thứ. Ảnh chụp màn hình mặt đứng rack trong bài là một phần của công cụ đó
Phần từ bare metal đến boot thì chúng tôi có một thứ tự chế bằng cách hack trên https://github.com/danderson/netboot/tree/main/pixiecore. Nó cung cấp Debian netboot và file preseed
Chúng tôi cũng có một Temporal worker tùy biến kết nối với Redfish API của BMC để điều khiển thiết bị này. Sau đó một host agent tùy biến sẽ provision QEMU VM, rồi dùng FRR trên host để quảng bá IP được gán qua BGP
Về các kịch bản lỗi cho data center mới, chúng tôi đã thử bằng cách làm nhảy aptomat, và nhờ đó phát hiện sự mất cân bằng pha. Ở site khác thì chúng tôi mang cả camera nhiệt vào
Tuần tới site AMS sẽ lên, mục tiêu là xem có thể đẩy một switch fabric được lấp đầy hoàn toàn đi xa tới mức nào
Bài hay. Khi cần tốc độ 100G, Google thực sự tính giá rất gắt. Gần như xúc phạm luôn.
Ví dụ, Dedicated Interconnect 100G có dự phòng rơi vào khoảng 35.000 USD mỗi tháng, mà còn chưa tính VLAN attachment, chi phí cross-connect ở colocation, transit, v.v. Thêm nữa, VLAN attachment tối đa chỉ 50G
Nếu so chi phí này ra thì với từng ấy tiền có thể mua được 2 switch Arista 100G 32 cổng mới
Ở Bắc Mỹ, có thể kiếm được đường truyền WAN 100G, tức Wavelength được quản lý, với giá dưới 5.000 USD/tháng. Nếu là metro nội vùng thì còn có thể lấy dark fiber rẻ hơn và chạy ở tốc độ mình muốn