Store-Level Survivability and Showback on a GreenLake Private Cloud
Meridian Retail runs 120 stores and a central private cloud on HPE GreenLake. Store systems include point-of-sale, inventory, and a new video-analytics workload. The central platform team supports VMs and Kubernetes, but chargeback is a monthly spreadsheet. Store connectivity varies: 18 stores have 20 Mbps MPLS, the rest use broadband. A recent promotion caused the inventory service to saturate central internet egress, and POS latency rose to 4 seconds. Finance wants showback by store and workload; operations wants POS to survive a central outage; security wants cardholder data to stay in a PCI zone. The DR plan uses Zerto and has never been tested at store level. The team is evaluating workload placement changes but has no agreed service tiers.
1. How would you place POS, inventory, video analytics, and PCI data across store and central tiers? Justify each placement with latency, survivability, and compliance reasoning.
Read the worked answer
Place the POS transaction path and a local store controller at the store, with a local queue and offline authorization rules, because a 4-second central round trip already violates checkout expectations and the store must survive a central outage. Keep inventory authoritative centrally but give each store a read cache and a write queue for receipts and stock movements; do not make store checkout depend on synchronous inventory calls. Process video analytics at the edge or upload only events and sampled clips, because 20 Mbps MPLS stores cannot backhaul continuous camera streams and central egress is already a bottleneck. Keep cardholder data and tokenization in the central PCI zone, with the store sending only tokenized or encrypted transaction data; do not replicate the cardholder data environment to stores unless the PCI scope is deliberately extended. Define service tiers first: checkout latency, offline duration, recovery point, and video retention. Placement without tiers will recreate the promotion incident.
2. Design a showback model that Finance will trust and that changes behavior. What dimensions, allocations, and data-quality controls would you use?
Read the worked answer
Build showback from consumed resources and service tiers, not from a flat per-store split. For VMs, charge CPU and memory reservations plus actual usage, storage capacity and IOPS, backup retention, and DR replication. For Kubernetes, charge requested and used CPU/memory, persistent storage, and ingress/egress. Add network egress by store and workload, because the promotion incident was an egress problem. Allocate shared platform costs such as control plane, monitoring, and security by a documented driver, and separate fixed platform fees from variable consumption. Require every workload and store to carry tags for owner, cost center, service tier, and PCI scope; reject untagged resources from production. Publish a monthly reconciliation between the invoice and the showback, and give teams a forecast view before the next promotion. Finance will trust the model only if it reconciles to actual GreenLake charges and if the allocation rules are stable, documented, and approved.
3. The DR plan uses Zerto but has never been tested at store level. What sequence would you use for a store-level DR test, and what would you validate before declaring success?
Read the worked answer
Start with a single low-risk store and a defined failure scenario: loss of central connectivity, not loss of the whole data center. Validate that POS enters offline mode, queues transactions, and later reconciles without duplicates. Then test central service failover for inventory and the store controller, including DNS, identity, and time synchronization. Next test a regional group of stores to expose shared dependencies such as the central egress or the PCI zone. Only then test a full central failover. Before declaring success, verify RTO and RPO per service, transaction integrity after reconciliation, PCI scope during failover, and that store staff received clear operating instructions. Zerto protects virtual machines, but it does not validate store networking, local caching, or payment terminal behavior. Record every manual step and convert the top three into automation or runbooks. A DR test that restores VMs but leaves checkout unable to process payments is a failed test.