Kiến trúc HAProxy Multi-Cloud: Định tuyến chéo phòng tránh thảm họa sập Region (2026)

Tháng 10 năm 2025 có lẽ là thời điểm ám ảnh đối với nhiều Solutions Architect và DevOps Engineer. Lỗi tự động hóa DNS tại us-east-1 của AWS đã kéo theo sự sụp đổ dây chuyền của hàng loạt dịch vụ phụ thuộc trên toàn cầu, khiến hàng ngàn nền tảng SaaS tê liệt. Cùng thời điểm, sự cố cấu hình tại tầng điều khiển Azure Front Door đã lan truyền nhanh chóng, làm ngưng trệ nhiều dịch vụ Microsoft 365. Trước đó vào tháng 06/2025, Google Cloud cũng nếm trái đắng khi dữ liệu chính sách quota bị lỗi đồng bộ toàn cầu, gây ra tình trạng trả về mã lỗi 503 trên 54 dịch vụ GCP.

Điểm chung của những thảm họa này là gì? Đó là các doanh nghiệp đã quá tin tưởng vào tính sẵn sàng của một nhà cung cấp đám mây đơn lẻ. Khi API bị rate-limit, IP bị block, hoặc Control Plane của Cloud ngừng hoạt động, toàn bộ cấu hình định tuyến của bạn sẽ bị đóng băng, bất kể bạn có chạy bao nhiêu Node hay trải rộng ra bao nhiêu Availability Zone (AZ).

Để thoát khỏi rủi ro Vendor Lock-in và nắm quyền kiểm soát hoàn toàn luồng traffic khi có biến cố, giới kỹ sư hạ tầng đang chuyển dịch mạnh mẽ sang kiến trúc HAProxy Multi-Cloud. Bài viết này sẽ đi sâu vào kỹ thuật thiết lập định tuyến chéo (Cross-routing) trên các VPS độc lập, từ giải pháp cấu hình linh hoạt cho bản Community đến cơ chế chuyển vùng (failover) siêu tốc chuẩn Enterprise.

Bạn đã sẵn sàng để xây dựng một hệ thống định tuyến thực chiến, miễn nhiễm với thảm họa mạng chưa?

Tại sao Load Balancer mặc định của Cloud lại dễ trở thành tử huyệt?

Nhiều kỹ sư hạ tầng lầm tưởng rằng chỉ cần bật tính năng Multi-Region trên AWS ALB hoặc GCP Load Balancing là hệ thống đã được an toàn. Thực tế, chiến lược này vẫn tồn tại rủi ro Single Point of Failure (SPOF, Điểm lỗi đơn lẻ) xuất phát từ bản chất kiến trúc của các nhà cung cấp đám mây.

Ranh giới mong manh giữa Control Plane và Data Plane

Các nhà cung cấp Cloud phân chia hạ tầng thành hai mặt phẳng: Control Plane (quản lý, khởi tạo, kiểm tra chính sách API/IAM) và Data Plane (định tuyến, chuyển tiếp gói tin thực tế). Về mặt lý thuyết, khi Control Plane ngừng hoạt động, Data Plane vẫn tiếp tục chuyển tiếp lưu lượng hiện có.

Tuy nhiên, sự cố ở Control Plane sẽ ngay lập tức gây ra trạng thái tê liệt khả năng quản lý (Management Paralysis). Bạn không thể tạo Load Balancer mới, không thể thay đổi rules, cập nhật Target Group hay cấu hình chứng chỉ SSL. Kỹ sư vận hành bị khóa hoàn toàn khỏi Bảng điều khiển quản trị (Management Console) và các API điều hành, dẫn đến mất khả năng can thiệp thủ công để điều hướng lưu lượng khẩn cấp.

Tác động dây chuyền từ các hệ thống dùng chung

Việc triển khai Multi-Region trong cùng một Cloud chỉ phân tán được lớp Data Plane, trong khi lớp Control Plane, hệ thống DNS và IAM thường là các tài nguyên dùng chung ở cấp độ toàn cục (Global).

• Tự động hóa toàn cục: Khi một bản cập nhật phần mềm (hoặc file cấu hình) bị lỗi, hệ thống điều khiển sẽ đẩy cấu hình sai lệch này ra toàn bộ các Region trên toàn cầu gần như đồng thời.
• Phụ thuộc hạ tầng xác thực (IAM): Các Region đều phụ thuộc vào một hệ thống xác thực trung tâm. Nếu IAM gặp sự cố (như lỗi xoay khóa mã hóa), các API ở mọi Region sẽ bị đóng băng.
• Gián đoạn hệ thống Health Check: Native Load Balancer phụ thuộc vào Control Plane để cập nhật danh sách instance. Nếu cơ chế này gián đoạn, Load Balancer có thể tiếp tục gửi lưu lượng đến các node backend đã lỗi.

Thiết kế định tuyến độc lập trên các VPS giúp hệ thống tránh được rủi ro lỗi dây chuyền từ Control Plane của nhà cung cấp.

Giải phẫu 3 lớp định tuyến trong kiến trúc HAProxy Multi-Cloud

Để cô lập lỗi (fault isolation) và tránh phụ thuộc vào một Control Plane tập trung, kiến trúc HAProxy Multi-Cloud chia nhỏ nhiệm vụ định tuyến thành 3 lớp riêng biệt. Sự phân tách này giúp thu hẹp bán kính ảnh hưởng (Blast Radius); một lỗi nghẽn ở tầng ứng dụng sẽ không kéo theo hệ thống mạng toàn cầu ngừng hoạt động.

Tầng 1: Global Layer (mặt phẳng định tuyến toàn cầu)

Đây là lớp ngoài biên (Edge), chịu trách nhiệm định tuyến traffic từ người dùng Internet đến đúng Data Center hoặc Region phù hợp.

• Cơ chế: Sử dụng DNS-based GSLB (như Route 53, Cloudflare) kết hợp định tuyến theo vị trí địa lý (Geolocation) hoặc độ trễ (Latency), hoặc triển khai giao thức BGP Anycast kết hợp Route Health Injection (RHI).
• Tính độc lập: Tầng này chỉ theo dõi trạng thái khả dụng vĩ mô của toàn bộ Region (thông qua endpoint tổng) thay vì quản lý từng server con bên trong. Khi một Region gặp sự cố mạng diện rộng, tầng Global chủ động rút IP hoặc cập nhật DNS để chuyển hướng toàn bộ traffic sang Region dự phòng.

Tầng 2: Regional Layer (mặt phẳng định tuyến vùng)

Lớp này tiếp nhận traffic khi đi vào một Region cụ thể và phân phối đến các cụm ứng dụng L7 đặt trên nhiều Availability Zone nội vùng.

• Cơ chế: Hoạt động ở Layer 4 (Transport Layer), xử lý gói tin dạng không trạng thái (stateless) qua cấu hình HAProxy mode TCP.
• Tính độc lập: Do không giải mã SSL/TLS và không đọc nội dung HTTP (Header, Cookie), lớp này xử lý gói tin ở tốc độ đường truyền (line rate) với chi phí CPU cực thấp. Nếu một node L7 bên dưới bị mất kết nối, Regional Layer sẽ phát hiện thông qua TCP check và gạt node đó khỏi vòng xoay ngay lập tức.

Tầng 3: Application Layer (mặt phẳng định tuyến ứng dụng)

Tầng này giải mã gói tin và điều hướng sâu dựa trên logic nghiệp vụ của hệ thống.

• Cơ chế: Sử dụng HAProxy mode HTTP (Layer 7) để chấm dứt kết nối SSL/TLS (SSL Termination), điều hướng theo URL path, duy trì Sticky Sessions và thực thi các quy tắc WAF/Rate Limiting.
• Tính độc lập: Quản lý sức khỏe chi tiết từng instance qua Active HTTP check. Tầng này có khả năng tự động điều hướng sang Backup Server cục bộ hoặc trả về Sorry Page khi ứng dụng quá tải, đảm bảo không làm gián đoạn luồng định tuyến mạng của tầng L4.

Phân tách 3 lớp định tuyến mạng giúp cô lập lỗi hiệu quả và tối ưu hóa tài nguyên xử lý dữ liệu.

Kỹ thuật cấu hình HAProxy Cross-Region thực chiến

Khi triển khai Kiến trúc HAProxy Multi-Cloud trên các VPS độc lập (ví dụ: kết hợp AWS, GCP và một nhà cung cấp VPS thuần túy như Linode hay Vultr), nhiệm vụ trọng tâm là cấu hình để HAProxy nhận biết trạng thái thực tế của hệ thống và kích hoạt định tuyến chéo khi cần thiết.

Giải pháp Community: Định tuyến chéo và Health Check biết nói thật

Ở cấp độ cơ bản, bạn có thể thiết lập các máy chủ khác vùng làm phương án dự phòng trực tiếp trong HAProxy. Bằng việc sử dụng từ khóa backup, HAProxy sẽ ưu tiên 100% traffic cho các máy chủ nội vùng (local) và chỉ đẩy traffic sang máy chủ khác vùng (remote) khi toàn bộ cụm local gặp sự cố.

Một vấn đề kỹ thuật thường gặp khi tích hợp HAProxy với các dịch vụ GSLB bên ngoài là hiện tượng Health Check nói dối. Nếu bạn chỉ cấu hình monitor-uri /health, HAProxy sẽ trả về mã 200 OK miễn là tiến trình (process) HAProxy còn chạy, bất chấp việc toàn bộ backend phía sau đã ngừng hoạt động. Hệ quả là GSLB vẫn tiếp tục đổ traffic vào Region lỗi, gây ra tình trạng rớt request diện rộng.

Để khắc phục tình trạng này, hãy kết hợp hàm đếm máy chủ khả dụng nbsrv() và chỉ thị ép trả lỗi monitor fail:

frontend fe_global_ingress
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/app.pem
    mode http

    # Intercept URI dành riêng cho hệ thống DNS Probe từ bên ngoài
    monitor-uri /health

    # Kiểm tra số lượng máy chủ khả dụng trong cụm backend be_app_local
    # Nếu không còn máy chủ nào đang hoạt động (eq 0), ACL này sẽ được kích hoạt
    acl local_cluster_dead nbsrv(be_app_local) eq 0

    # Ép HAProxy trả về lỗi 503 Service Unavailable thay vì 200 OK
    monitor fail if local_cluster_dead

    default_backend be_app_local

backend be_app_local
    mode http
    balance roundrobin
    
    # Bắt buộc phải cấu hình active health check để hàm nbsrv() đếm được trạng thái
    option httpchk GET /api/ready
    http-check expect status 200
    
    # Các máy chủ nội vùng (Primary)
    server local-01 10.0.1.10:8080 check inter 2s fall 3 rise 2
    server local-02 10.0.1.11:8080 check inter 2s fall 3 rise 2
    
    # Các máy chủ khác vùng làm backup trực tiếp
    server remote-01 20.0.1.10:8080 check inter 2s fall 3 rise 2 backup
    server remote-02 20.0.1.11:8080 check inter 2s fall 3 rise 2 backup

Lưu ý về độ trễ DNS: Giải pháp dùng monitor fail để báo hiệu cho GSLB đổi bản ghi DNS vẫn tồn tại độ trễ do phụ thuộc vào DNS TTL (thường mất từ vài chục giây đến vài phút để các ISP và trình duyệt cập nhật IP mới).

Giải pháp Enterprise: Chuyển vùng siêu tốc với BGP Anycast & Route Health Injection (RHI)

Đối với các hệ thống yêu cầu RTO (Recovery Time Objective) tính bằng mili-giây (như tài chính, giao dịch thời gian thực), việc chờ đợi DNS TTL là một rào cản lớn. Hạ tầng HAProxy hiện đại cung cấp giải pháp tích hợp trực tiếp với hạ tầng định tuyến mạng (Network Routing) để loại bỏ hoàn toàn độ trễ DNS.

• Route Health Injection (RHI) & BFD: Các phiên bản Enterprise của HAProxy có khả năng giao tiếp trực tiếp với các router biên thông qua giao thức BGP (Border Gateway Protocol). Khi cụm backend ứng dụng phía sau gặp sự cố, tính năng RHI sẽ lập tức ngưng quảng bá (withdraw) dải IP Anycast của Region đó. Kết hợp với giao thức BFD (Bidirectional Forwarding Detection), quá trình phát hiện lỗi mạng và tự động chuyển hướng lưu lượng sang Region dự phòng diễn ra ở tốc độ cực cao, thường dưới 100 mili-giây (milliseconds). Toàn bộ quá trình chuyển đổi hoàn toàn trong suốt với người dùng cuối.
• HAProxy GSLB Native: Trong trường hợp hạ tầng bắt buộc phải dùng định tuyến qua DNS, module Global Server Load Balancing (GSLB) nội tại của HAProxy sẽ đóng vai trò là Authoritative DNS Server. Nó phân phối lưu lượng đa khu vực dựa trên vị trí địa lý hoặc trạng thái sức khỏe theo thời gian thực mà không cần phụ thuộc vào một nhà cung cấp DNS thứ ba.

PRO-TIP (Mẹo chuyên gia): Kỹ thuật AS-Path Prepend xử lý Traffic Flapping

Khi triển khai kiến trúc Active-Active BGP đa vùng, các kỹ sư thường gặp hiện tượng Traffic Flapping (chập chờn luồng dữ liệu), nơi router liên tục đổi đường dẫn giữa hai Region do định tuyến mạng thiếu ổn định. Để khắc phục, bạn có thể áp dụng kỹ thuật AS-Path Prepend. Bằng cách chủ động cấu hình nối dài (prepend) thêm các số hiệu AS vào thông số đường đi quảng bá từ Region dự phòng, router sẽ đánh giá tuyến dự phòng này xa hơn và luôn ưu tiên giữ traffic ở Region chính. Khi cụm chính thực sự ngừng hoạt động và ngưng quảng bá BGP hoàn toàn, router mới định tuyến mượt mà sang Region dự phòng, loại bỏ triệt để hiện tượng chập chờn.

Giao thức BGP kết hợp Route Health Injection hỗ trợ chuyển hướng lưu lượng nhanh chóng, giải quyết vấn đề độ trễ của DNS TTL.

Tránh sập bẫy Split-brain: Cẩn trọng khi dùng peers qua mạng WAN

Trong nỗ lực duy trì tính đồng nhất dữ liệu, nhiều quản trị viên sử dụng giao thức peers của HAProxy để đồng bộ dữ liệu phiên làm việc (Session) hoặc bộ đếm giới hạn truy cập (Rate-limit) xuyên suốt giữa các Region qua mạng WAN. Kỹ thuật này ẩn chứa những rủi ro kiến trúc nghiêm trọng.

Mạng WAN giữa các Data Center cách xa nhau luôn có mức độ trễ (latency) đáng kể và dễ xảy ra tình trạng đứt kết nối tạm thời (network partition).

• Hiện tượng Split-brain: Khi đường truyền đứt gãy, cụm HAProxy ở hai Region bị cô lập và tự động rẽ nhánh dữ liệu trạng thái. Mỗi bên sẽ tự đánh giá tình hình và đếm rate-limit một cách độc lập.
• Ghi đè không cộng gộp (Overwrite without Aggregation): Giao thức peers hoạt động theo cơ chế đẩy và ghi đè trực tiếp. Khi kết nối WAN được phục hồi, dữ liệu trạng thái từ Region này có thể ghi đè và xóa mất session hợp lệ ở Region kia, dẫn đến hệ quả người dùng bị đăng xuất đột ngột hoặc cấu hình chặn tấn công (Anti-DDoS) bị vô hiệu hóa.
• Tắc nghẽn tài nguyên (CPU Spikes): Việc truyền tải một lượng lớn dữ liệu stick-table tồn đọng khi khôi phục mạng đòi hỏi các thao tác khóa bộ nhớ (locking), dễ gây nghẽn CPU và làm tăng độ trễ xử lý request mới.

Hướng giải quyết hiệu quả: Thay vì ép Load Balancer thực hiện việc đồng bộ trạng thái qua mạng WAN, hãy thiết kế kiến trúc ứng dụng theo hướng Stateless (sử dụng JWT token). Đối với các hệ thống bắt buộc phải lưu trữ Session state, việc sử dụng cụm Database hoặc Redis Cluster có cơ chế Geo-Replication nội tại chuyên dụng sẽ an toàn và đáng tin cậy hơn rất nhiều.

Quản trị quy mô lớn: Chuyển đổi từ SSH sang Infrastructure as Code

Việc duy trì các file cấu hình phân mảnh trên hàng chục cụm VPS bằng phương pháp truy cập SSH và chỉnh sửa thủ công (bằng vi/nano) mang lại rủi ro vận hành. Để đáp ứng tiêu chuẩn Multi-Cloud, hệ thống cần được quản lý tập trung và tự động hóa toàn diện.

Tự động hóa với HAProxy Data Plane API

HAProxy cung cấp giải pháp Data Plane API, cho phép các nhóm DevOps định cấu hình và quản lý Load Balancer thông qua lệnh gọi REST API hiện đại.

Thay vì phải đăng nhập vào từng server để khởi động lại tiến trình (reload) thủ công, bạn có thể tích hợp API này vào các luồng CI/CD (như Terraform, Ansible). Đội ngũ có thể thao tác thêm, sửa, xóa các backend, frontend, điều chỉnh trọng số (weight) hay kích hoạt máy chủ dự phòng thông qua mã nguồn (Infrastructure as Code). Các thay đổi qua API được thực thi linh hoạt trong bộ nhớ (in-memory) và lưu trữ an toàn mà không làm rớt các kết nối hiện hành của người dùng.

Tập trung hóa bằng HAProxy Fusion Control Plane

Khi quy mô hệ thống mở rộng trên đa nền tảng (kết hợp AWS, Azure, GCP và On-premise VPS), việc giám sát từng node phân tán trở thành một gánh nặng lớn. HAProxy Fusion Control Plane mang đến một giao diện điều khiển tập trung, cung cấp khả năng hiển thị toàn cảnh.

Công cụ này cho phép theo dõi lưu lượng truy cập xuyên cloud, quản lý vòng đời chứng chỉ SSL tự động, đẩy cấu hình đồng loạt tới hàng ngàn node HAProxy, và thiết lập các cảnh báo sớm để phát hiện dấu hiệu quá tải trước khi chúng leo thang thành sự cố ngừng hoạt động Region.

Kịch bản kiểm thử (Chaos Drill) để đo lường RTO

Một hệ thống High Availability (HA) chưa từng được kiểm thử thực tế đồng nghĩa với việc bạn đang vận hành dựa trên hy vọng thay vì dữ liệu. Quy trình diễn tập mô phỏng lỗi Region (Chaos Drill) là phương pháp thực chứng bắt buộc để đo lường RTO (Recovery Time Objective) của kiến trúc.

Quy trình chuẩn hóa để diễn tập bao gồm 5 mốc quan trọng:

1. Chuẩn bị (Pre-Drill): Thiết lập các tập lệnh kiểm thử tự động (Synthetic monitoring) gửi request liên tục tới endpoint để ghi nhận thời gian phản hồi theo mili-giây. Đảm bảo dữ liệu nền tảng giữa Region chính và dự phòng đang đồng bộ hoàn chỉnh.
2. Bơm sự cố Giả lập lỗi (T0): Đánh dấu mốc thời gian kích hoạt sự cố. Sử dụng các công cụ Chaos Engineering để ngắt toàn bộ quy tắc tường lửa (Iptables/Security Group), chặn lưu lượng giữa HAProxy và cụm ứng dụng, mô phỏng tình trạng Network Partition diện rộng.
3. Phát hiện & chuyển vùng (T1 -> T2):
   • Tại tầng mạng: Hệ thống BGP Anycast hoặc GSLB phát hiện HAProxy ngưng phản hồi hoặc báo lỗi 503 (T1), lập tức chuyển hướng traffic sang Region dự phòng (T2).
   • Tại tầng ứng dụng: Các quy trình tự động hóa kích hoạt các máy chủ ảo dự phòng (Standby VMs) và gắn ổ đĩa dữ liệu (Storage takeover).
4. Xác minh phục hồi (T3): Ghi nhận chính xác thời điểm các request kiểm thử tự động trả về kết quả thành công (HTTP 200 OK) và dữ liệu đọc/ghi đồng nhất. Công thức tính RTO thực tế = T3 – T0.
5. Đồng bộ ngược (Fallback & Post-Mortem): Khi cụm Region chính hoạt động ổn định trở lại, tiến hành đồng bộ dữ liệu phát sinh từ vùng dự phòng về vùng chính (Reverse Replication). Chuyển traffic có kiểm soát về hạ tầng ban đầu và tiến hành họp đánh giá (Post-mortem) để cải thiện quy trình vận hành.

Đo lường RTO qua quy trình Chaos Drill chuẩn hóa giúp kỹ sư đánh giá năng lực phục hồi thực tế của kiến trúc hạ tầng.

1. HAProxy Multi-Cloud khác gì với Cloud Load Balancer mặc định?

Tính độc lập. Native Load Balancer bị trói buộc vào Control Plane của nhà cung cấp. Kiến trúc HAProxy trên VPS độc lập giúp bạn tự chủ luồng traffic, tránh thảm họa lỗi dây chuyền khi Cloud provider gặp sự cố diện rộng.

2. BGP Anycast kết hợp RHI ưu việt hơn DNS Failover ở điểm nào?

Tốc độ chuyển vùng (Failover). DNS Failover luôn bị trễ do phụ thuộc vào bộ nhớ đệm (TTL) của ISP. BGP Anycast can thiệp trực tiếp vào định tuyến mạng, giúp chuyển traffic sang Region dự phòng chỉ trong dưới 100 mili-giây, hoàn toàn trong suốt với người dùng.

3. Tại sao không nên dùng tính năng peers của HAProxy qua mạng WAN?

Rủi ro Split-brain và độ trễ. Khi mạng chập chờn, hai node rẽ nhánh dữ liệu. Lúc kết nối lại, chúng ghi đè session lên nhau gây lỗi và làm nghẽn CPU. Hãy xử lý đồng bộ session ở tầng Database hoặc dùng Redis Cluster có Geo-Replication.

4. Cần VPS cấu hình bao nhiêu để chạy HAProxy hiệu quả?

HAProxy tiêu tốn cực ít tài nguyên. Một VPS cấu hình cơ bản (2 vCPU, 4GB RAM) đã có thể xử lý hàng chục nghìn connection đồng thời. Khi chọn VPS, hãy ưu tiên băng thông mạng (Network Throughput) và độ ổn định đường truyền thay vì CPU hay cấu hình RAM cao.

5. Có nên đặt HAProxy ở Cloud A và Backend ở Cloud B không?

Có thể, nhưng cần cẩn trọng với chi phí băng thông chiều ra (Egress Cost) và độ trễ (Latency). Mô hình tối ưu là mỗi Cloud/Region triển khai trọn vẹn một cụm HAProxy + Backend độc lập và để tầng Global phân tải giữa các cụm này.

6. Hiện tượng Health Check nói dối là gì?

Là khi HAProxy trả về mã 200 OK chỉ vì bản thân nó đang hoạt động, mặc dù toàn bộ server ứng dụng phía sau đã ngừng hoạt động. Cách khắc phục: Dùng hàm nbsrv() kết hợp monitor fail để ép HAProxy trả lỗi 503 khi backend mất kết nối.

Kết luận

Việc xây dựng kiến trúc HAProxy Multi-Cloud đòi hỏi một tư duy kỹ thuật vượt ra khỏi ranh giới của một hệ thống cân bằng tải truyền thống. Nó yêu cầu khả năng phân tách rõ ràng giữa lớp mạng và lớp ứng dụng, kết hợp với việc loại bỏ triệt để rủi ro từ Control Plane của các nhà cung cấp đám mây.

Bằng việc tích hợp các kỹ thuật thực chiến như thiết lập Health Check biết nói thật, cấu hình failover BGP kết hợp AS-Path Prepend, cùng phương thức quản trị bằng Data Plane API, doanh nghiệp có thể nắm quyền tự chủ hoàn toàn đối với hạ tầng định tuyến. Khi một Region hoặc toàn bộ một Cloud Provider gặp sự cố bất ngờ, kiến trúc này sẽ tự động nhận diện và điều hướng lưu lượng mượt mà, giữ cho hệ thống luôn hoạt động bền bỉ.

Hãy rà soát lại kiến trúc Load Balancing hiện tại của đội ngũ và lên kế hoạch thực hiện một buổi Chaos Drill ngay trong thời gian tới để chuẩn bị sẵn sàng cho mọi tình huống!

Tài liệu tham khảo

• Global server load balancing | HAProxy Enterprise
• Active/Active clustering | HAProxy Enterprise
• HAProxy version 3.4.4-55 – Configuration Manual
• Annual Outage Analysis 2024 – Executive summary – Uptime Institute
• Anatomy of a Cloud Outage: What 12 Months of Incidents Teach About Resilience – Data Storage
• HA and DR Solutions on PowerVS