How to Seamlessly Migrate Business Workloads to a Virtualized Environment

正文

Virtualization projects should follow a stable, incremental process to ensure reliable migration of services to a virtual environment.

(1) Business performance assessment and pressure model creation

At project start, determine the appropriate virtualization ratio (e.g., 1:5 or 1:7) and host specifications based on data‑driven analysis. Collect existing workload pressure data to build a pressure model, which then guides ratio and host selection.

(2) Test‑environment testing

After fixing the virtualization ratio and host specs, conduct both system‑level and application‑level tests. System tests identify host and VM bottlenecks, while functional and performance tests verify that services run correctly and determine maximum load (e.g., concurrent users for games, connections for web/database services).

Testing yields stability insights and the maximum load each service can sustain on a VM.

(3) Small‑scale deployment

With successful test results, deploy a limited set of services in production for 2 weeks to a month. Start with low‑load VMs, then gradually move higher‑load workloads after validation.

(4) Full deployment

After confirming small‑scale stability, proceed with a phased, comprehensive migration of all services to the virtual environment.

业务压力模型构建方法

After committing to virtualization, the next challenge is determining the ratio and host/VM specifications based on a pressure model derived from long‑term monitoring data and peak‑period measurements.

Collect at least 60 days of monitoring metrics for each server; if the fleet is large, sample the most stressed machines. During peak hours, use scripts to capture high‑frequency data (5‑30 s intervals) via tools such as sar, iostat, and vmstat.

Aggregate the data to extract a business pressure model, which then informs the virtualization ratio and hardware sizing.

Game‑business pressure model characteristics

Game workloads are typically divided into two models:

GS (Game Server) – CPU‑intensive, high CPU, memory, and network usage, low disk I/O.

DB (Database) – I/O‑intensive, low CPU and memory, high network and disk I/O.

Additional I/O characteristics for games:

Network I/O consists of small packets; focus on packets‑per‑second (pps).

Disk I/O is random small‑block writes; focus on IOPS.

Other industries can adapt these principles to their specific workloads.