Khi Data Center không còn là đáp án: từ DC Proposal đến Infrastructure Consolidation

Một case thực tế về Capacity Planning, TCO, Proxmox/PBS và cách một architecture thay đổi trước khi đi vào production.

Có những project bắt đầu bằng một câu hỏi kỹ thuật nhưng kết thúc bằng một quyết định kiến trúc hoàn toàn khác so với giả định ban đầu.

Project này là một trường hợp như vậy.

Ở thời điểm bắt đầu, bài toán có vẻ khá rõ: hạ tầng hiện hữu cần được đánh giá lại về capacity, khả năng mở rộng, backup/recovery và rủi ro vận hành. Một số workload đang chạy trên virtualization, một số workload khác vẫn phụ thuộc vào các máy vật lý riêng lẻ. Storage tiếp tục tăng, dependency giữa Data platform, network và backup ngày càng nhiều hơn, trong khi location hiện hữu không còn là một câu trả lời đủ tốt cho hướng phát triển tiếp theo.

Phương án đầu tiên là đưa workload sang một external Data Center với dedicated infrastructure, network connectivity và một migration plan được chuẩn bị khá sâu.

Nhưng càng đi vào sizing, commercial scope và cách hệ thống sẽ thực sự được vận hành sau migration, câu hỏi quan trọng nhất lại thay đổi.

Đó là điểm project chuyển từ một bài toán relocation sang một bài toán architecture decision.

Bài toán bắt đầu từ workload, không bắt đầu từ catalog phần cứng

Điều đầu tiên mình không muốn làm là chọn server trước rồi cố gắng nhét workload vào cấu hình đã chọn.

Với một platform có nhiều thành phần như database, Airflow, Spark, Kafka, MinIO, ingestion/processing workers và các service phụ trợ khác, cách tiếp cận hợp lý hơn là đi ngược từ workload.

Mỗi workload cần được nhìn theo một số câu hỏi rất cơ bản nhưng có ảnh hưởng trực tiếp đến kiến trúc:

Đây cũng là lúc những máy vật lý đang đóng vai trò worker được xem lại. Nếu một workload có thể chạy tốt dưới dạng VM và không có dependency đặc biệt với phần cứng, việc tiếp tục duy trì một PC vật lý riêng cho nó không nhất thiết còn là lựa chọn hợp lý.

Một migration vì thế không chỉ là cơ hội để đổi location. Nó còn là cơ hội để đặt lại câu hỏi:

Workload nào nên move nguyên trạng? Workload nào nên rebuild? Workload nào nên consolidate? Và workload nào không còn lý do để tiếp tục tồn tại theo cách cũ?

External Data Center là một phương án thật, không phải một ý tưởng trên slide

Phương án external Data Center đã được chuẩn bị ở mức đủ sâu để có thể triển khai nếu được chọn.

Architecture ban đầu bao gồm dedicated infrastructure, rack, network connectivity, public addressing, monitoring/support và migration method. Commercial scope cũng đã được làm việc đến mức có hợp đồng và phụ lục liên quan đến thiết bị, Data Center service và đường truyền.

Điều đó quan trọng vì nó cho thấy quyết định cuối cùng không đến từ việc “chưa kịp làm DC” hay “ý tưởng bị bỏ giữa chừng”. External DC đã vượt qua một phần lớn của technical feasibility assessment.

Đây là một trong những bài học mình giữ lại khá rõ từ project này: technical feasibility không phải là tiêu chí duy nhất để chọn architecture.

Ba lựa chọn, ba cách trả lời khác nhau cho cùng một nhu cầu

Trong quá trình assessment, các lựa chọn được đặt cạnh nhau theo hướng purchase, lease-to-buy và dedicated infrastructure/service. Purchase cho ownership rõ ràng nhưng đưa CapEx lên sớm; lease-to-buy trải chi phí theo thời gian; còn dedicated/colocation giảm một phần gánh nặng facility nhưng tạo recurring cost và dependency với external provider/network.

Khi thêm rack, power, cooling, DIA, support, remote hands, recurring fee và khả năng tái sử dụng hạ tầng hiện có vào bài toán CPU/RAM/storage, bức tranh TCO bắt đầu khác đáng kể.

Khi target architecture thay đổi

Sau khi cân lại cost/value, phương án cuối cùng không tiếp tục theo hướng đặt toàn bộ target platform ở external Data Center.

Phần Data Center recurring service và DIA không đi vào production. Thay vào đó, phần hardware investment còn phù hợp được giữ lại và target location chuyển về một internal server room tại site mới.

Đây là điểm mình thấy project trở nên thú vị hơn nhiều so với một migration thông thường.

Architecture thay đổi, nhưng phần engineering work đã làm trước đó không biến mất.

Workload inventory vẫn còn giá trị. Capacity assessment vẫn còn giá trị. Proxmox sizing vẫn còn giá trị. PBS migration strategy, network segmentation, rollback, physical move plan và cutover checklist vẫn còn giá trị.

Thứ thay đổi chủ yếu là target location và operating model.

Architecture Decision Matrix: nhìn trade-off thay vì tìm một phương án “thắng tuyệt đối”

Để nhìn quyết định này rõ hơn, mình thường tách các tiêu chí thành những trade-off có thể so sánh. Bảng dưới đây cố ý dùng đánh giá định tính thay vì công bố số liệu thương mại nội bộ. Nó không phải một scoring model tuyệt đối; mục đích là cho thấy vì sao hai architecture có thể cùng technically viable nhưng lại tạo ra operating model rất khác nhau.

Điểm mình muốn giữ ở đây là: phương án không được chọn không đồng nghĩa với phương án kém. External DC mạnh hơn ở facility resilience và giảm bớt một số trách nhiệm vật lý; internal consolidation lại cho quyền kiểm soát cao hơn, tận dụng tốt hơn phần investment đã có và giảm một số recurring dependency.

TCO không chỉ là giá mua server

Mình không đưa contract value hay chi phí vendor thực tế lên một bài public. Nhưng về mặt decision-making, TCO được nhìn rộng hơn rất nhiều so với hardware acquisition.

Các cost driver cần đặt cùng nhau gồm CapEx cho infrastructure, recurring facility/service fee, DIA/connectivity, power & cooling, support/remote hands, vận hành và khả năng tái sử dụng asset hiện hữu. Một architecture có initial cost thấp hơn chưa chắc có lifecycle cost thấp hơn; ngược lại, một phương án cần đầu tư facility nội bộ nhiều hơn có thể giảm recurring external cost trong operating horizon dài hơn.

Từ “move DC” thành Infrastructure Consolidation

Khi target chuyển về internal server room, project không còn đơn thuần là Data Center relocation. Nó trở thành một bài toán lớn hơn:

Physical site migration + network redesign + compute consolidation + storage/backup integration + service validation.

Ở tầng network, target được tổ chức lại theo các lớp rõ ràng hơn: firewall/edge, Layer-3 core, distribution cho server farm, compute, storage và management.

Physical port mapping, rack layout, uplink và LACP được document trước khi cutover. Việc này nghe có vẻ nhỏ, nhưng trong một maintenance window có nhiều thiết bị, một port mapping không rõ ràng có thể biến thành hàng chục phút troubleshooting không cần thiết.

Mình luôn thích một nguyên tắc khá đơn giản:

Nếu một kết nối quan trọng chỉ tồn tại trong trí nhớ của một người, nó chưa phải là một thiết kế vận hành tốt.

Proxmox không chỉ là nơi đặt VM

Một phần quan trọng của consolidation là đưa nhiều workload về một virtualization platform có thể quản lý, backup và khôi phục nhất quán hơn.

Trong project này, Proxmox VE không được nhìn chỉ như hypervisor. Đi cùng nó là storage design, PBS, template, Cloud-Init, network bridge, SSH access và cách chuẩn hóa VM provisioning.

Với workload cần giữ state, migration strategy phù hợp hơn là giữ nguyên dữ liệu và trạng thái qua backup/restore:

Full backup/seed → incremental delta → validate restore → workload freeze → final sync → restore → service validation.

Với workload stateless hoặc có thể dựng lại sạch, cách tiếp cận khác hiệu quả hơn:

Golden template → clone → Cloud-Init → network/SSH baseline → application/data sync.

Hai cách này không mâu thuẫn. Chúng trả lời hai loại workload khác nhau.

Backup chỉ có ý nghĩa khi restore path tồn tại

PBS trở thành một phần quan trọng không chỉ vì cần một bản backup trước khi move.

Trong một physical migration, backup còn đóng vai trò tạo ra một recovery path độc lập với thiết bị đang được di chuyển. Nếu một host gặp vấn đề sau transport, nếu storage không activate như kỳ vọng hoặc nếu VM không lên đúng trạng thái, team vẫn cần một điểm quay lại có thể kiểm chứng được.

Điều mình quan tâm không phải chỉ là trạng thái “Backup: Successful”. Những câu hỏi quan trọng hơn là:

Restore ở đâu? Restore mất bao lâu? Storage target đã sẵn sàng chưa? Network mapping sau restore là gì? Và service nào phải được kiểm tra trước khi nói VM đã phục hồi?

Đó cũng là lý do restore validation và operational recovery nên được xem như một phần của architecture, không phải một việc làm thêm của backup team.

Recovery objective: đừng tạo một con số đẹp nếu project không định nghĩa nó

RTO/RPO là những chỉ số hữu ích, nhưng chỉ có ý nghĩa khi chúng thực sự được định nghĩa, gắn với workload và được kiểm chứng. Trong bộ evidence của project này, mình không có cơ sở đủ chắc để công bố một formal target kiểu “RTO = X giờ” hay “RPO = Y phút”, nên mình không tạo ra các con số đó chỉ để bài trông định lượng hơn.

Thay vào đó, migration được thiết kế theo recoverability: giảm data exposure bằng incremental/final synchronization trước cutover, giữ PBS như một recovery path độc lập, xác nhận storage/network target và chỉ xem recovery hoàn tất sau khi service-level validation đạt yêu cầu.

Nếu sau này một workload có formal RTO/RPO, chính restore testing mới là nơi chứng minh objective đó khả thi. Với project này, điều có thể khẳng định chắc hơn là: backup success không được dùng thay cho recovery evidence.

Power readiness cũng là một dependency của Infrastructure

Khi target chuyển về internal server room, một phần công việc không còn nằm thuần trong network hay virtualization. Nguồn điện, phân tải, UPS và cooling cũng trở thành dependency trực tiếp của platform.

Thay vì cố kéo runtime UPS thật dài, thiết kế thực tế tập trung vào việc phân tải nguồn 3 pha hợp lý, tận dụng dual PSU của thiết bị và dùng UPS như một bridge ngắn hạn. Khi mất điện lưới, UPS giữ critical IT load trong khoảng chuyển tiếp ngắn để máy phát điện khởi động và ổn định; generator mới là nguồn dự phòng dài hạn.

Với thiết bị dual-power, hai PSU không nên bị xem như hai dây nguồn giống nhau. Một feed đi qua UPS-backed power, feed còn lại đi theo utility/generator path giúp giảm single point of failure và linh hoạt hơn khi bảo trì.

Physical Move không phải phần khó nhất, nhưng là nơi mọi dependency gặp nhau

Asset move plan cho project được tách theo nhóm thiết bị, priority và bring-up sequence.

Trước khi move, cần biết thiết bị nào phải shutdown trước, thiết bị nào phụ thuộc storage, thiết bị nào phải lên trước để network có thể phục hồi, và thiết bị nào có thể để sau vì không nằm trên critical path.

Sequence thực tế vì vậy không phải:

“Đem hết qua chỗ mới rồi bật lên.”

Nó gần hơn với:

Backup → label → shutdown → transport → rack/power → core/distribution → firewall/WAN → storage → compute → management/OOB → service validation.

Chính thứ tự này giúp giảm một kiểu troubleshooting rất phổ biến: application chưa lên nhưng team lại đang kiểm tra ở Layer 7 trong khi storage hoặc routing bên dưới vẫn chưa sẵn sàng.

Infrastructure Green vẫn chưa đủ

Đây là điểm project này nối khá tự nhiên với nhiều migration khác mình từng làm.

Một Core Switch có thể UP. LACP có thể bundled. Firewall có thể healthy. WAN có thể reachable. Proxmox node có thể online.

Nhưng những trạng thái đó chỉ cho biết từng component đang hoạt động.

Chúng chưa chứng minh business service đã trở lại.

Vì vậy cutover checklist được tách thành hai tầng tư duy:

Một migration chỉ thực sự thành công khi tầng service phía trên chứng minh được rằng các dependency phía dưới đang phối hợp đúng.

Rollback phải được thiết kế khi mọi thứ còn đang bình thường

Rollback trong project này cũng không được xem như một nút “Undo”.

Mỗi failure domain cần một recovery path riêng.

Nếu LACP giữa core và distribution không lên, team phải biết kiểm tra member, cabling, configuration và khi nào cần fallback sang standalone uplink. Nếu WAN có vấn đề, cần phân biệt lỗi physical/ISP với routing/SD-WAN. Nếu VPN không lên, underlay phải được xác nhận trước khi mất thời gian với tunnel. Nếu OOB chưa sẵn sàng, phải biết console/local recovery path nằm ở đâu.

Điều này làm mình ngày càng tin vào một nguyên tắc:

Rollback không nên được nghĩ ra khi migration bắt đầu thất bại. Nó phải tồn tại trước khi thiết bị đầu tiên được shutdown.

Giai đoạn sau cutover mới cho thấy platform có thực sự vận hành được hay không

Đóng maintenance window không có nghĩa project đã kết thúc.

Sau move, một số việc mang tính operationalization mới thực sự bắt đầu: kiểm tra storage activation, chuẩn hóa VM provisioning, cập nhật SSH key, validate network settings, kiểm tra backup job, baseline monitoring và làm sạch những temporary workaround đã dùng trong cutover.

Trong phần Proxmox, mình còn giữ lại một SOP nhỏ cho việc clone Ubuntu VM từ golden template bằng qm clone và Cloud-Init. Script được dùng để giữ baseline nhất quán, provisioning nhanh hơn và phục vụ workload ingest/migration mà không phải dựng tay từng VM.

Những note troubleshooting như validate sshd, xử lý host key, set network từ Proxmox host hay recover LVM khi PV còn nhưng VG chưa active có vẻ rất nhỏ khi đứng riêng lẻ.

Nhưng đó chính là “last mile” của infrastructure engineering.

Một architecture đẹp trên diagram chưa mang nhiều giá trị nếu platform sau đó khó support, khó provision và chỉ một vài người biết cách phục hồi.

Điều đáng nhớ nhất không phải là việc Data Center đã không được chọn

External DC không phải một phương án sai. Nó giải quyết tốt một số vấn đề về facility, physical security, power, cooling và support. Nhưng khi đặt cạnh workload profile, hardware investment, recurring cost, network dependency và operating model thực tế, một phương án khác tạo ra balance phù hợp hơn ở thời điểm đó.

Quyết định có giá trị không nằm ở việc chọn “DC” hay “on-prem”, mà nằm ở việc team có đủ dữ liệu để biết tại sao mình chọn.

Nhìn lại project

Project đi từ workload inventory và capacity assessment đến external DC design, TCO review, rồi chuyển thành physical migration, network redesign, Proxmox/PBS consolidation, backup/restore, power readiness, cutover và operationalization.

Điều mình giữ lại không phải tên server, model switch hay số lượng VM, mà là cách câu hỏi thay đổi: từ “Hạ tầng cần bao nhiêu CPU, RAM và storage?”, sang “Architecture nào đáp ứng capacity và availability?”, và cuối cùng là “Architecture nào đáp ứng những requirement đó với operational model và TCO hợp lý nhất?”

Với mình, đó là khoảng cách giữa infrastructure implementation và infrastructure engineering.

Infrastructure Engineering không phải là triển khai công nghệ. Đó là quá trình cân bằng giữa Capacity, Risk, Recoverability, Operations và Economics/TCO để tạo ra một kiến trúc phù hợp nhất ở thời điểm ra quyết định.

Architecture không chỉ là nơi workload sẽ chạy. Architecture là quyết định về cách hệ thống sẽ được vận hành, phục hồi và trả chi phí trong nhiều năm sau đó.