Move SAP HANA từ On-Prem lên AWS: khi Cloud Migration không chỉ là chuyện của Cloud

Năm 2023, mình tham gia một project đưa toàn bộ hệ thống SAP HANA từ hạ tầng On-Prem lên AWS cùng đối tác triển khai. Vendor phụ trách phần cloud platform và application stack; mình phụ trách phía Infrastructure/Network — connectivity, security boundary, dependency và validation để hệ thống sau migration thực sự vận hành được.

Có những project nhìn trên sơ đồ khá đơn giản.

Nhưng khi bắt đầu làm thật, phần khó không nằm ở mũi tên.

Nó nằm ở tất cả những thứ đang nối với hệ thống trước khi mũi tên đó được vẽ: network, DNS, firewall, database, middleware, access, monitoring và những dependency mà đôi khi chỉ lộ ra khi một service không còn đi theo đường cũ.

Vai trò của mình trong project

Đây là project có đối tác triển khai. Vì vậy mình không muốn kể lại theo cách làm như thể mình tự tay build toàn bộ EKS, Jenkins, RDS hay Redis.

Vendor phụ trách phần cloud platform và application stack. Phía mình phụ trách Infrastructure/Network, phối hợp những phần liên quan đến connectivity, access path, security boundary, dependency, cutover và validation.

Ranh giới trách nhiệm này khá quan trọng. Vendor có thể nói resource đã tạo xong. Infra có thể nói network đã thông. App team có thể nói process đã chạy.

Nhưng business chỉ nhìn một kết quả: SAP HANA có sử dụng được hay không.

Cloud Migration không bắt đầu ở AWS Console

Trước khi nói tới EKS hay RDS, mình quan tâm tới dependency.

User đang đi vào hệ thống bằng đường nào? Application nào còn gọi resource On-Prem? DNS nào sẽ đổi? Firewall cần cho phép những source/destination nào? Khi một endpoint thay đổi, component nào phía sau còn đang giữ cấu hình cũ?

Tài liệu triển khai lúc đó khá chi tiết ở phía AWS: VPC, public/private subnet, route table, NAT, S3 VPC Endpoint, security group, EKS, RDS, Redis, S3 và CloudWatch đều có trình tự cấu hình riêng. Nhưng từ góc nhìn Infra, các resource đó chỉ thực sự có ý nghĩa khi đặt lại vào service path.

Đó là lý do dependency discovery thường có giá trị hơn việc thuộc vị trí từng menu trong AWS Console.

Hai Availability Zone chưa chắc đã loại bỏ mọi dependency

Kiến trúc cloud thường nhìn rất đẹp khi có hai Availability Zone, public subnet và private subnet tách rõ.

Đó là nền tảng đúng. Nhưng Infra vẫn phải nhìn traffic path phía sau.

Nếu nhiều private subnet vẫn phụ thuộc vào cùng một egress path, nếu database chỉ có một active instance, hoặc một middleware duy nhất vẫn đứng giữa application và dependency khác, thì việc đếm subnet chưa đủ để kết luận về availability.

EKS Active chưa có nghĩa SAP HANA đã sẵn sàng

Phần EKS trong project được triển khai bằng eksctl, có worker node, namespace, EBS CSI và AWS Load Balancer Controller. Front-end, back-end và Jenkins được triển khai lên cluster; ALB và target group được dùng để đưa traffic tới workload.

Nhưng mình không muốn dừng validation ở trạng thái ACTIVE, Ready hay Running.

Pod chạy chưa chắc application đọc được database. ALB tồn tại chưa chắc target healthy. Target healthy chưa chắc user thực hiện được transaction thật.

Một chi tiết mình thấy có giá trị trong tài liệu triển khai là việc kiểm tra target group và health-check path của application sau khi ingress được tạo. Nó nhắc đúng một điều: resource health và service health là hai lớp kiểm chứng khác nhau.

Migration dễ thất bại ở những dependency không nằm trên diagram

Một hệ thống tồn tại đủ lâu thường có những dependency không còn nằm trong architecture diagram mới nhất.

Một endpoint được hard-code. Một firewall rule từ nhiều năm trước. Một batch job chạy ở giờ ít ai để ý. Một middleware vẫn đang gọi sang môi trường cũ. Một DNS record mà mọi người tưởng đã không còn dùng.

Vì vậy mình thích dependency được biến thành checklist có owner và validation method, thay vì để nó nằm trong trí nhớ của từng engineer.

Nếu một dependency chỉ được phát hiện trong cutover window thì lúc đó nó không còn là discovery nữa. Nó đã trở thành downtime.

Vendor triển khai không có nghĩa Infra đứng ngoài

Trong project có vendor, mình thấy dễ có một hiểu nhầm: phần nào vendor triển khai thì Infra chỉ cần chờ bàn giao.

Thực tế thì ngược lại.

Infra phải hiểu đủ kiến trúc để đặt câu hỏi đúng: traffic đi qua đâu, security group/firewall nào đang quyết định kết nối, ALB đang health-check gì, data service nằm private hay public, DNS đổi ở thời điểm nào và nếu validation fail thì service quay về đường cũ bằng cách nào.

IAM và access cũng là một phần của migration

Tài liệu 2023 dùng IAM user, access key, managed policy và inline policy để phục vụ triển khai. Đây là cách làm khá quen thuộc ở thời điểm đó, đặc biệt trong những project cần hoàn thành nhanh và có nhiều công cụ CLI/API tham gia.

Nhưng bài học mình giữ lại không phải tên policy nào đã được gán.

Nó là việc phải tách được quyền của human administrator, automation và application workload. Nếu một pipeline chỉ chạy được sau khi role phía dưới được mở rất rộng, migration có thể thành công nhưng steady-state security lại trở thành việc phải xử lý sau go-live.

Đó là lý do mình xem access review là một phần của handover, không phải một việc hoàn toàn tách khỏi migration.

Database lên chưa có nghĩa SAP HANA đã sẵn sàng

Trong scope cloud, tài liệu triển khai có các data service như RDS PostgreSQL và Redis phục vụ những thành phần ứng dụng liên quan. Mình không xem trạng thái của một resource data layer là bằng chứng rằng toàn bộ SAP HANA đã sẵn sàng.

Trạng thái Available của database chỉ là một tín hiệu.

Mình vẫn cần nhìn tiếp: application resolve đúng endpoint chưa, credential có đúng không, connection tới data service có thông không, data có đủ mới cho cutover không, và sau khi đổi môi trường thì monitoring/backup có quay lại trạng thái bình thường không.

Infrastructure nói “database đã lên” và application nói “SAP HANA chưa chạy” hoàn toàn có thể cùng đúng — vì hai bên đang đo hai layer khác nhau.

Configuration cho migration chưa chắc phù hợp với steady state

Một số lựa chọn trong giai đoạn build hoặc test có thể hợp lý để rút ngắn thời gian triển khai: quyền rộng hơn tạm thời, log giữ lâu để troubleshoot, một số HA/backup control chưa bật ngay, hoặc endpoint được cập nhật thủ công.

Nhưng nếu workload đã chuyển sang production, mình muốn có một vòng review khác.

Câu hỏi lúc đó không còn là “migration có chạy không?” mà là “môi trường mới đã đủ an toàn và đủ dễ vận hành trong nhiều tháng tiếp theo chưa?”.

Cutover không phải khoảnh khắc duy nhất cần chuẩn bị

Mình thường chia migration thành ba đoạn.

Trước cutover: dependency, backup/snapshot, DNS readiness, firewall/routing, access, monitoring, validation checklist và rollback path.

Trong cutover: network reachability, application-to-database connectivity, workload health, ALB target health, DNS, critical transaction và lỗi log.

Sau cutover: user validation, performance, monitoring, backup, security review và theo dõi xem còn dependency nào đang quay về On-Prem.

Và chỉ sau giai đoạn cuối mình mới thấy có cơ sở để trả lời câu hỏi:

Nếu nhìn lại project 2023 hôm nay

Mình không muốn dùng tiêu chuẩn của vài năm sau để nói rằng implementation thời điểm đó “sai”. AWS, Kubernetes và security practice thay đổi khá nhanh.

Điều đáng giữ lại là cách nhìn: mỗi thay đổi platform đều phải đi kèm dependency validation, access review và service validation.

Nếu làm lại một project tương tự, mình sẽ muốn nhiều thành phần được khai báo và kiểm chứng bằng code hơn, ít phụ thuộc vào thao tác console và endpoint thủ công hơn, đồng thời tách rõ identity của human, pipeline và workload.

Nhưng phần không thay đổi vẫn là câu hỏi cũ:

Điều mình giữ lại

Trước những project kiểu này, Cloud Migration dễ được hiểu đơn giản là đưa workload từ A sang B.

Sau project, cách mình nhìn khác đi một chút.

Migration thật sự là di chuyển dependency mà không làm mất service.

Vendor có thể triển khai AWS resource. Application team có thể triển khai code. Infra/Network phải giúp nối những phần đó thành một service path có thể kiểm chứng.

Với mình, migration chỉ kết thúc khi câu hỏi cuối cùng được trả lời bằng validation thay vì cảm giác: