Exclusive access to the entire computer’s computing resources
Using physical hosts as resource boundaries, plan dedicated resources for continuous computing, memory-intensive, or I/O-intensive services.
BARE METALExclusive hardware resources
Bare Metal Servers
Exclusive hardware resources
Carrying critical loads
Use exclusive physical computing resources to carry services focusing on hardware access, performance and delivery management.
Bare Metal ServersResource architecture
- 01business layerDatabase · Computing tasks · Business clusters
- 02System layerOperating system · Direct access to hardware
- 03Resource layerExclusive CPU · Memory · Storage resources
Suitable for teams that require exclusive physical resources but also focus on cloud delivery methods.
PRODUCT OVERVIEW
What is a bare metal server?
- Exclusive physical resources
- Hardware direct access
- key business
Bare metal servers host workloads on dedicated physical hosts, usually combined with cloud platform delivery and management methods. Ideal for applications that focus on hardware access, resource isolation, and sustained compute or storage loads.
What to evaluate
Bare metal is the physical server itself. It is suitable for workloads that require the boundaries of the entire machine's resources, but the performance benefits must still be proven by hardware configuration, software behavior, and actual measurement results.
Reduce virtualization layer constraints
Suitable for workloads that require direct use of hardware capabilities, specific system environments, or underlying performance tuning. Specific compatibility is confirmed based on the model.
Connect to cloud delivery process
Organize deployment by combining the network and management capabilities provided by the platform. Activation, reinstallation, private network and interface support are subject to the actual capabilities of the selected product.
INSIDE THE ARCHITECTURE
How to cooperate with overall machine resources and cloud delivery
Bare metal provides a physical computing environment that directly runs the operating system. When understanding it, you should look at the business operation path and the management process of resource delivery and maintenance separately.
- 01
Delivery and initialization
Check the overall machine configuration, system version, network and access method to form a repeatable initialization record.
- 02
operating system scheduling
The kernel schedules application threads and manages memory. Whether the program can be parallelized is still determined by code and data dependencies.
- 03
hardware access
The CPU processes data through memory and I/O paths, and device capabilities and topology affect sustained performance.
- 04
life cycle management
Deployment, monitoring, maintenance and recycling revolve around the entire device, and fault recovery requires preparation of alternative paths in advance.
Cloudification changes the delivery process without changing the nature of physical machines
Cloud-based bare metal usually integrates the registration, system deployment and life cycle management of physical devices into a unified process, and the business operating system still runs on the physical server. The difference between it and traditional physical machine rental mainly lies in resource orchestration, network access and management methods. It cannot be inferred that there is instant expansion, hot migration or arbitrary self-service reinstallation capabilities just from the name "bare metal".
Single-core capability and multi-core throughput should be evaluated separately
Serial calculations, the main thread, and some transaction paths rely on single-core processing speed; only batch processing or multi-request services that can be parallelized have the opportunity to utilize more cores. As the number of cores increases, lock contention, cache contention, and memory bandwidth may become new bottlenecks. Exclusive machine ownership helps clarify resource boundaries, but newer cloud instances may also perform better on certain types of tasks.
NUMA and I/O determine how far data travels
In a system with a NUMA topology, the cost of accessing local and remote memory may differ between CPUs. If a multi-threaded program frequently fetches data across nodes, the wait will increase; disk and network card paths also need to be evaluated based on actual equipment. First observe the topology, memory distribution and business delay, and then decide whether to adjust threads and memory affinity to avoid blindly tying cores.
The following are common architecture and operation and maintenance examples. WAF.PRO's hardware model, complete machine resource scope, management permissions, cloud delivery capabilities and maintenance methods are subject to the specific plan and delivery list; the reference document is only used to understand the technical principles.
PERFORMANCE & CAPACITY
Use metrics to locate the bottleneck
The same business version and data should be used for acceptance to test single tasks, multi-concurrency and long-term loads respectively, while recording the power consumption strategy, software version and test conditions.
| Metric | Application impact | How to assess |
|---|---|---|
| Single core processing power | Serial hotspots determine single request latency, and more cores cannot automatically shorten this path. | It is time-consuming to use representative single tasks, and then analyze the hotspot functions and waiting reasons. |
| Multi-core expansion efficiency | As concurrency increases, lock contention, shared cache, and memory bandwidth can drive down benefits. | Gradually increase the number of threads or processes and record the changes in throughput and tail latency. |
| NUMA and memory | Remote memory access and uneven node allocation can increase latency or limit throughput. | Check the system topology and process memory distribution, and verify the business performance before and after adjustments. |
| Disks and data paths | The media, controller, read and write modes, and simultaneous write requirements all determine storage performance. | Test with actual block size versus read-write ratio, and observe throughput, queuing, and sustained latency. |
| Network and interrupt load | Small packets, high connection numbers, or network processing overhead may reach bottlenecks before network port bandwidth. | Test connection and transmission based on actual protocols, and correlate CPU, retransmission and packet loss indicators. |
Metrics and terminology
- NUMA
- Non-uniform memory access: The processor may have different costs for accessing different memory areas, and scheduling and data location can affect performance.
- Thread and memory affinity
- To bias thread or memory allocation to a specific processor or node arrangement, the effect needs to be verified through load testing.
- I/O
- Data input and output between the system and storage, network and other equipment may become a waiting point outside of computing.
- tail delay
- The time consumption of the slower part of a batch of requests can be observed using high-quantile indicators such as P95 and P99.
BEFORE YOU CHOOSE
Define requirements before choosing resources
Bring these four types of information to make the selection discussion more concrete.
- Hardware and compatibility
- CPU architecture, core count, memory capacity, and system and application compatibility requirements.
- Disk and performance
- Storage type, capacity, read and write performance and data redundancy scheme.
- Cloud Networking and Management
- Private network access, activation methods, system reinstallation and management interface support range.
- Delivery and recovery
- Lead times, hardware failure handling, data recovery and maintenance windows.
APPLICATION SCENARIOS
Workloads to start with
core database
Used for database services that require high memory capacity, disk response, and sustained read and write performance.
Continuous calculation and analysis
Host batch processing, data analysis and long-running computing tasks, selecting processors and storage based on workload.
Dedicated business cluster
Deploy self-managed containers or application clusters, plan node resources, network isolation and system configuration.
DEPLOYMENT PLAYBOOK
Deployment examples for continuous computing or databases
First make the entire machine operation observable and replicable, and then consider optimizing the hardware. Databases and computing tasks can be laid out differently, but both require a clear recovery path after a failure.
- 01
Identify resource needs
Distinguish between single-core latency, multi-core throughput, memory capacity and I/O requirements; list the sustained load, allowed interruption time and data recovery targets to form the basis for acceptance.
- 02
Establish a system baseline
Check CPU, memory and device information, record kernel, driver and configuration; deploy access control, logs and monitoring, and then perform continuous business load testing.
- 03
Validate data layout
Plan storage according to the access patterns of logs, data, and temporary files to avoid unintentional sharing of hotspots; perform small-step optimization when there is evidence that NUMA affects performance.
- 04
Prepare for failure
Select backup nodes, data replication or backup recovery based on the business; practice takeover and reconstruction after shutdown, and confirm that alternative resources can cooperate with data recovery steps.
Deployment trade-offs
Concentrating multiple components on a large machine can reduce cross-machine communication and management objects, and also expand the impact of a single machine failure. Splitting into multiple machines can disperse failures, but introduces replication, network communication and consistency costs. The choice should be based on business recovery objectives.
OPERATE WITH CONFIDENCE
From launch to ongoing operations
Save repeatable baselines
Record the system, driver, application version and key parameters, and retest with the same set of business loads after each upgrade. Save test conditions along with performance changes to avoid mistaking data size, cache hotness, or concurrency differences for changes in hardware performance.
Verify tuning benefits item by item
First locate the main wait in CPU, memory or I/O, then adjust one parameter at a time. There may be trade-offs in thread affinity, memory allocation, and queue configuration; retain the baseline and fallback methods, and recognize benefits in terms of business throughput and tail latency.
Incorporate maintenance windows into the design
Hardware maintenance, kernel or driver updates may require a reboot. Organize the business shutdown sequence, connection draining, data checking and startup dependencies in advance, and confirm alternative nodes or recovery methods to avoid discovering that the service cannot be stopped safely on the day of maintenance.
Restoration must cover the entire machine failure
Data disk redundancy does not replace independent backup, nor does it eliminate host failure. Incorporate configurations, key recovery methods, and business data into the recovery list, practice reconstruction in another operating environment, and verify data integrity and the time it takes to reach a serviceable state.
CHOICES & TRADE-OFFS
Compare product advantages under real conditions
When your business is
Long-term stable high load and clear isolation requirements for the whole machine
Suitable for focused evaluation of bare metal
Clear resource boundaries make it easy to establish continuous performance baselines and capacity planning around fixed hardware.
When your business is
Low utilization, short bursts or frequent changes in resource size
First compare resource granularity and delivery process
The capacity of the entire machine may be idle for a long time. Capacity expansion also involves equipment supply and deployment, and actual usage costs need to be calculated.
When your business is
Extremely sensitive to downtime, but only plan to deploy one
Complete redundancy and recovery solutions first
Exclusive physical resources do not eliminate equipment failures, and business availability still relies on multiple nodes or verifiable recovery processes.
Three judgments that are easily overlooked
Bare metal is definitely faster than cloud servers
Hardware generations, single-core capabilities, storage, and application architecture all change results, and business performance should be compared under the same conditions.
The more cores, the faster a single task
Only the parallelizable portion can take advantage of the additional cores; serial paths, locks, and memory accesses limit speedup.
The whole machine is exclusive and comes with high availability
Exclusivity describes resource usage boundaries, and high availability also requires fault detection, spare capacity, data protection, and switching mechanisms.
QUESTIONS & ANSWERS
Questions before you choose
What is the difference between bare metal and physical servers?+
Both can provide exclusive physical hosting. It is mainly distinguished by delivery and management methods: bare metal focuses on cloud delivery and platform collaboration, while physical servers focus on full machine rental and hardware solutions. In the end, specific configurations and service content still need to be compared.
Can bare metal scale like cloud instances?+
Physical resource adjustments typically involve model, inventory, or hardware replacement and scale differently than regular cloud instances. Multi-node deployment can be planned in advance. Please confirm the specific adjustment process and shutdown impact during model selection.
Can I deploy my own virtualization or container environment?+
It needs to be evaluated in conjunction with the operating system, hardware virtualization capabilities, network configuration, and licensing requirements. Please provide the system and software version you plan to use to verify the scope of support.
After having exclusive use of the entire machine, do I still need to manage resource competition between processes?+
Needed. Applications, databases, backups, and batch processing still share the machine's CPU, memory, and I/O. Resource budgets and task periods should be set according to online business priorities to avoid internal contention.
Should I do NUMA core binding from the beginning?+
You should not bind just because there are multiple nodes. First observe the business and memory distribution, and conduct comparative tests if necessary; inappropriate binding may limit available resources and reduce performance.
What is the most important thing to verify before migrating to bare metal?+
First check the system and driver compatibility, data migration time and real load performance, and then practice recovery and rollback; at the same time, confirm how the maintenance window and alternative resources are implemented.
YOUR NEXT STEP
Decide on your bare metal server plan together
Provide business type, access area, peak load, data size and recovery objectives, and work with technical consultants to evaluate configuration, network and delivery solutions.