Selectel dedicated: setup from bare metal to production

Selectel dedicated: why production hits a hardware ceiling

A virtual machine almost always shares resources with neighbors: the I/O channel and disk array run on a shared pool, so at peak hours someone else's traffic turns into your latency.

Averaged graphs in the panel look calm, but on production workload response spikes appear — and there is no way to link them to a specific node.

Degradation under load here comes not from the CPU ceiling, but from uncontrolled resource distribution. The disk sags when someone else's write is happening nearby, and the network interface hits the provider's limit before the application's capabilities.

It is almost impossible to check this from the tenant side: metrics are blurred, the hardware is outside your perimeter, and hypervisor settings are closed.

VM limits are set at creation and do not move to fit your task. When the database outgrows the allocated I/O or the write queue becomes longer than reasonable, what helps is not query tuning but moving the workload.

Hence failures exactly at peak: the replica cannot catch up, the scheduler cannot keep up, reporting competes with order intake.

Selectel dedicated removes the most unpleasant layer of this uncertainty: CPU, memory and disks of a dedicated server are not shared with other tenants, so your workload is not mixed with anything.

Next we break down how to move a service from a virtual machine to dedicated hardware without getting a new infrastructure bottleneck already at the deployment stage.

What changes after moving to a dedicated server

Moving to a dedicated server changes not average metrics, but service behavior at peak and during failure. On shared virtualization, the resource is divided with other workloads, so response time fluctuates and one tenant's incident affects everyone.

Below is a checklist of what we measure on Selectel before and after the move so the effect is confirmed by numbers, not promises.

• Stable response time. The 95th and 99th percentiles stay in the same corridor both during the day and at evening peak — the spread between fast and slow requests narrows.
• Performance at peak. CPU, disks and network are not shared with other workloads: growth in concurrent sessions does not turn into a queue.
• Elimination of neighbor-induced failure classes. Disk subsystem dips and network spikes from someone else's activity are no longer reproduced.
• Reduced downtime. Scheduled maintenance uses switchover to a standby node rather than stopping the service for users.
• Fault tolerance. Redundant power, disks and network ports on site plus hot standby for critical roles.
• Data redundancy. Scheduled disk snapshots and a recovery procedure with time measured during a training exercise.

We verify the result of the move by measurements: response time, share of successful requests, recovery time. If there is no difference on some point, we say so directly.

Placement formats on Selectel dedicated and their limitations

The placement form factor is chosen not by peak capacity, but by the acceptable failure class in production. A single dedicated server gives full control over the kernel and disk stack, but replacing hardware or a disk means stopping the service.

A cluster of servers removes this limitation at the cost of complexity: balancing, state replication and taking a node out of service without losing requests are required.

A hybrid scheme adds a standby perimeter in the cloud — it does not carry constant load, but takes traffic when the primary site degrades. Below are the options actually chosen between at the start.

The form factor is changed as growth happens: a single server moves into a cluster, the cluster gains a standby perimeter. Addressing scheme, backups and configuration roles should be designed so that transition between options does not turn into a separate project.

Stages of moving infrastructure to a dedicated server

Moving to a dedicated server is not a one-time migration, but a sequence with checkpoints. A skipped stage does not disappear: it surfaces in production as a failure that costs more than designing the scheme anew.

Therefore the work follows strict steps, and each is closed with an artifact — a scheme, configuration or verification report.

Sequence of work

1. Infrastructure audit. We collect a map of services and dependencies, load profile by hours and peaks, requirements for disk, network and redundancy. The output is a list of bottlenecks and limitations that cannot be moved "as is".
2. Placement scheme. We distribute node roles, segment the network, plan storage, backup outside the site and failure points. The scheme is approved before purchasing the configuration.
3. Hardware and site preparation. Disk layout and RAID levels, file system, remote access, network settings and traffic filtering rules. We record the baseline state of each node.
4. Deployment automation. We describe infrastructure declaratively, keep configurations in a version control system, and perform deployment repeatably — the same scheme is reproduced from scratch without manual edits.
5. Deployment and staging verification. We move the load, restore services from copies, simulate node failure and measure recovery time. Scheme edits are made only based on measurement results.
6. Acceptance checks. We run the checklist: data recovery, failure behavior, monitoring and alerts, access separation, event logs. We eliminate discrepancies before moving into production, according to an individual calculationTransfer to operation. We hand over documentation, maintenance procedures and access roles, and train the on-call team. We support the first update cycles until the processes become routine.

Configurations, network schemes and operation procedures

The handover package is not an archive with logs, but a set of working documents by which the infrastructure can be operated without the authors of the work.

We assemble it in parallel with setup on dedicated Selectel servers: each item is checked during a training failure before handover. Below is what remains with the customer after acceptance.

• Server configuration — hardware composition, disk layout, boot parameters, list of services and their settings: the node is reproduced anew from the description, without taking apart a running one.
• Network scheme — addressing, segments and routes between them, traffic filtering rules, connection points for external channels.
• Access policies — roles and permissions, key issuance and revocation, secret storage, separate accounts for people and for services.
• Recovery procedure — what is copied and how often, retention periods, step-by-step recovery order and the time it was verified against during a training failure.
• Monitoring and alerts — list of checks, trigger thresholds, notification routes, who responds and within what time.
• On-call instructions — typical operations: restarting a service, replacing a disk, key rotation, taking a node out for maintenance.
• Infrastructure passport — node map, dependencies between services, change log.

We hand over documents to the customer's knowledge base, not to personal notes: edits go through normal approval, and if the contractor changes, the package can be read without us.

Case: how we removed downtime on a loaded service

The original scheme looked workable: one dedicated server, a daily database dump to a separate disk and manual switchover according to instructions.

Under peak load the service remained alive but responded with delay, and failure of a disk or network channel stopped production entirely. Recovery from a copy took hours, and all that time users saw an error — monitoring recorded the fact of the crash, but not its cause.

What was changed

We moved the load to two bare metal sites at Selectel with synchronous data replication and a separate node for backups.

Traffic is distributed by a load balancer with active health checks: a node that does not respond is automatically removed from rotation, without an on-call engineer.

Copies became incremental every 15 minutes, we added regular recovery verification on a test perimeter and lifecycle rules for snapshots so storage would not grow uncontrollably.

We separately configured degradation alerts — growth in response time, replication errors, disk filling — before a user notices it.

What was achieved

Recovery time decreased from 4-6 hours to 10-15 minutes, and in most scenarios switchover happens without manual intervention. Service availability grew from 99.2% to 99.95% over the observation period.

The failure class changed: instead of full unavailability — degradation of a separate node that the user does not notice. Eight out of ten incidents are closed by automation; the on-call engineer gets involved only in those requiring manual diagnostics.

How a dedicated server differs from a virtual machine

The difference starts at the level of access to hardware.

A virtual machine receives resources through a virtualization layer and shares the physical host with other tenants, while a dedicated server is given entirely to one customer — there is no intermediary between the operating system and the processor.

Resource isolation is the main practical dividing line. On a shared host, someone else's load spike takes CPU cache and disk bandwidth, so service response time "floats" precisely during peak hours, when it costs the most.

On a dedicated node, response variance narrows, and heavy operations stop affecting neighboring services.

Load predictability is critical for databases, queues and batch processing: what matters there is behavior at peak, not the average metric.

Manageability also differs by nature — a virtual machine is faster to replicate and move, a physical server gives control over the kernel, scheduler and storage settings.

The choice is rarely binary. Virtual machines remain for the web layer and test environments, while physical nodes are used for databases, message brokers and data processing; in Selectel, both live in the same network and under common monitoring.

Technical doubts: what is clarified before the start

Moving to dedicated hardware almost always runs into the same doubts: how to migrate without a downtime window, what happens if a node fails, how to add resources later and where the boundary of responsibility lies between us and the customer's team. Below are short answers on how this is closed in practice within the Selectel perimeter.

What happens if equipment fails?

Failure of a disk, power supply or an entire node does not turn into an outage: metrics collection and alerts record degradation before users notice it, load goes to the standby node, and configuration is reproduced from the infrastructure description rather than assembled manually from memory. Replacing hardware on the site side is neither our nor your area.

How to scale when load grows?

Vertically — we add resources to the node; horizontally — we introduce new servers and include them in balancing. The scheme is described in advance, so load growth does not require redesign: connecting a new node takes hours, not weeks of approvals.

Where does your responsibility end?

We are responsible for hardware, network, operating system, monitoring, updates and backups. The application, its settings and the data inside are the customer team's area.

The boundary is fixed in writing before the start so that during an incident no one has to look for someone to blame.

How is backup arranged?

Snapshots and logical dumps on a schedule, storage in a separate perimeter, rotation by policy. The key thing is regular recovery verification: a backup that has not been restored does not count as a backup.

Let's discuss your task and come back with a plan

Task analysis proceeds in several steps: you describe what you need to get from dedicated hardware at Selectel, we clarify what is missing with questions and come back with a task assessment and work plan.

A ready technical specification is not required — context is enough, we will pull out the rest ourselves. The analysis procedure is the same for any scale: first boundaries, then load, then scheme.

To make the assessment accurate, send the set of source data — point by point:

• scheme of the current perimeter: what already works, where it is located, what is moving and what remains in place;
• load profile: peak values, daily and seasonal fluctuations, behavior during spikes;
• availability requirements: acceptable downtime, target recovery time, backup points;
• list of services and their dependencies: databases, queues, load balancers, external integrations;
• network requirements: segmentation, public addresses, engineer access, secure channels;
• restrictions on work: maintenance windows, access and logging procedures.

After the scheme is approved, you receive a work plan with stages, responsibility zones and checkpoints: before the start it is clear what we do, in what order, and where your participation is needed. Describe the task — we will come back with an assessment and plan.