Some performance, security or compatibility improvements to the underlying OpenStack platform may only be fully applied to running servers after they have been restarted.

Where Zen advises that platform maintenance has included changes to the compute, networking or storage layer, we recommend that you restart your servers at the earliest suitable maintenance window.

In most cases, a graceful operating system restart is sufficient. However, where Zen specifically advises a full instance power cycle, the instance should be stopped and started from the CloudFlex portal rather than only rebooted from within the guest operating system.

This helps ensure the instance is restarted cleanly on the updated platform components and can take advantage of any relevant improvements.

It is good practice to keep the relevant guest tools and agents up to date within your servers.

For Linux servers, this commonly includes:

• cloud-init

• QEMU guest agent, where installed and supported

• VirtIO drivers, where applicable

• distribution updates and kernel updates

For Windows servers, this commonly includes:

• Cloudbase-Init, where used

• VirtIO drivers

• Windows updates

• any required monitoring, backup or management agents

These tools help improve compatibility, performance, management and automation of servers running on the CloudFlex platform.

Where images are provided by Zen, they will usually include the required base components. However, customers are responsible for keeping the operating system and guest-level tools up to date throughout the lifecycle of the instance.

Servers should be built from current, supported operating system images wherever possible.

Using up-to-date images helps ensure that servers benefit from current security updates, driver support, cloud-init or Cloudbase-Init compatibility, and platform integration improvements.

Where older operating systems are required for application compatibility, customers should ensure that they remain patched, supported by the vendor where possible, and protected with appropriate security controls.

We recommend avoiding the creation of new production servers from outdated or unmaintained images unless there is a specific business or application requirement.

When making changes to an instance, for example during patching, application upgrades or maintenance, you may wish to take a snapshot to provide a point-in-time rollback option.

Snapshots are intended for short-term use and should be removed once the maintenance activity has been completed and the instance has been confirmed as working correctly.

Snapshots are not a replacement for a managed backup service.

Leaving snapshots in place for extended periods can increase storage usage, complicate recovery, and may impact backup or restore operations depending on the storage backend and workload behaviour.

Zen may contact you regarding snapshots that remain in your account for a prolonged period to discuss removal and any associated risks.

For production servers, we recommend using persistent volumes for operating system and application data wherever appropriate.

A typical production instance may use:

Separating operating system and data volumes can make resizing, restoring and managing storage easier.

Where an instance contains important data, customers should ensure that the relevant volumes are included in their backup policy.

Where different storage tiers or volume types are available, customers should select the appropriate type for the workload.

Performance-sensitive workloads, such as SQL Server, MySQL, PostgreSQL, application databases, high-traffic websites or transactional systems, should use a suitable high-performance volume type where available.

For database workloads, we recommend placing database data, logs and temporary files on appropriately sized and performant volumes. This helps reduce the risk of storage latency or IOPS limits affecting application performance.

To help improve performance, manageability and restore times, we recommend keeping individual volumes to a sensible size.

Where very large storage requirements exist, consider using multiple volumes rather than a single very large disk, especially where the workload allows data to be split logically.

As a general recommendation, avoid creating individual volumes larger than 2 TB unless there is a specific technical requirement to do so.

Larger volumes may take longer to back up, restore, migrate, snapshot or replicate, depending on the storage backend and protection method in use.

Security groups control network access to servers and should be configured using a least-privilege approach.

Only required ports should be open, and management access such as SSH, RDP or WinRM should be restricted to trusted source IP addresses, VPN ranges or management networks.

We recommend avoiding broad rules such as:

• Allow SSH from 0.0.0.0/0
• Allow RDP from 0.0.0.0/0
• Allow all inbound traffic

Where possible, use role-based security groups such as:

This helps reduce the attack surface of your environment.

Servers should be placed on private tenant networks, with public access provided only where required.

Where internet access or inbound public access is needed, this should be provided using a router and floating IP address.

A typical deployment model is:

Avoid placing servers directly onto public or provider networks unless there is a specific requirement to do so.

This approach provides better isolation and gives more control over routing, firewalling and public exposure.

Where multiple servers provide the same service, we recommend using soft affinity / anti-affinity or suitable placement policies.

This helps ensure that related servers are placed on separate compute hosts, reducing the risk of a single host issue affecting all servers in a service.

Where multiple Locations are available, customers should consider spreading critical workloads across them.

Locations help improve resilience by separating workloads across different physical centers.

An instance flavor defines the amount of CPU, memory and boot disk allocated to an instance.

Customers should select a flavor that is appropriate for the workload and avoid significantly over-sizing or under-sizing servers.

Over-sized servers may consume unnecessary quota and increase cost and have performance issues due to co-scheduling, while under-sized servers may experience general poor performance.

Servers should not be given public access unless required.

Before assigning a floating IP or opening inbound firewall rules, consider whether access can instead be provided through:

• VPN access

• a management network

• a bastion host

• a load balancer

• restricted source IP ranges

• private inter-server communication

This is particularly important for management services such as SSH, RDP, database ports and administrative web interfaces.

Customers should ensure that all production workloads are protected by an appropriate backup policy.

Snapshots should not be considered a replacement for backups.

Backup requirements should be reviewed based on:

Customers remain responsible for the operating system, applications and data running inside their servers.

We recommend that all production servers have:

• regular operating system patching

• application patching

• vulnerability management

• anti-virus or EDR where appropriate

• monitoring and alerting

• log management

• backup monitoring

This helps maintain the security, stability and supportability of the environment.

Consistent naming makes environments easier to manage, support and troubleshoot.

We recommend using names that identify the customer, environment, role and instance number.

For example:

customer-prod-w01
customer-prod-s01
customer-dev-app01
customer-prod-dc01

Where multiple servers or environments are required, customers should consider using automation rather than manual deployment.

CloudFlex works well with:

Automation helps make deployments more consistent, repeatable and easier to recover.