Concepts

The IaaS (Infrastructure as a Service) offering from Cloud Temple is designed to meet the critical requirements for business continuity and disaster recovery, with a particular focus on demanding sectors such as industry, banking, and insurance. Built on cutting-edge technologies, this infrastructure ensures maximum availability and optimal performance for your critical workloads.

A trusted technology platform

The Cloud Temple IaaS platform is built on internationally recognized technology partners:

• Compute: CISCO UCS.
• Storage: IBM Spectrum Virtualize, IBM FlashSystem for block storage.
• Networking: JUNIPER.
• Virtualization: VMware, providing a reliable and proven foundation for managing your cloud environments.
• Backup: IBM Spectrum Protect Plus, for orchestration and storage of backups.

This architecture is based on the VersaStack model, a collaboration between Cisco and IBM, ensuring broad compatibility with leading software vendors.

A dedicated and automated infrastructure

Although fully automated via APIs and a Terraform provider, Cloud Temple's IaaS offering provides a unique infrastructure:

• Dedicated resources: Compute blades, storage volumes, and software stacks (virtualization, backup, firewalling, etc.) are never shared among clients.
• Maximum predictability: You have full control over virtualization rates, IOPS pressure on storage, and benefit from clear, consumption-based monthly billing.

The platform is certified SecNumCloud by the ANSSI, ensuring a high level of automation and security.

Hauptfunktionen

• Dedicated und on-demand Rechenressourcen (CPU, RAM).
• On-demand Speicher (mehrere Klassen verfügbar).
• Netzwerkressourcen (Internet, private Netzwerke).
• Kreuzsicherungen mit konfigurierbarer Aufbewahrungszeit.
• Asynchrone Replikation für Speicher oder virtuelle Maschinen.
• Steuerung über die Console oder im Infrastructure-as-Code-Modus über APIs und den Terraform-Provider.

Vorteile

Vorteil	Beschreibung
Digitale Vertrauenswürdigkeit	Speicherung von Daten in Frankreich und Einhaltung der DSGVO.
Sicherheit	Hochsichere Plattform, zertifiziert SecNumCloud, HDS (Hébergement des Données de Santé), ISO 27001 und ISAE 3402 Typ II.
Hohe Verfügbarkeit	Plattformverfügbarkeit von 99,99 %, monatlich gemessen, inklusive Wartungszeiträume.
Resilienz	Implementierung von Kontinuitäts- oder Wiederherstellungsplänen je nach Bedarf.
Automatisierung	Vollständig automatisierte Plattform, entwickelt für die Integration in ein digitales Transformationsprogramm.
On-Demand	Ressourcen sind nach Bedarf verfügbar.

Regions and Availability Zones

The VMware IaaS product is deployed within an availability zone.
An availability zone is part of a region.

This deployment model allows you to select the location of clusters and distribute them across different availability zones (AZs).
It enables better load distribution, maximizes redundancy, and simplifies the implementation of a disaster recovery plan (DRP) in case of an incident.

Computing

The blades provided by Cloud Temple are of type CISCO UCS B200 or CISCO UCS X210c. They are fully managed by Cloud Temple (firmware, OS version, etc.) via the Cloud Temple console.

Several categories of computing blades are available in the catalog to support your workloads (virtualization, containerization, ...). These blades feature different characteristics and performance levels to best meet your needs. The computing blade catalog is regularly updated.

When using the virtualization offering, a hypervisor cluster must consist exclusively of blades of the same type (mixing different blade types within a single cluster is not allowed).

Reference	RAM (1)	Frequency (2)	Number of Cores / Threads	Connectivity (3)	GPU (4)	SKU for VMware Offering
ECO v3 Blade	384 GB	2.20/3.0 GHz (Silver 4114 or equivalent)	20 / 40 threads	2 × 10 Gbit/s		csp:fr1:iaas:vmware:eco:v3
STANDARD v3 Blade	384 GB	2.40/3.4 GHz (Silver 4314 or equivalent)	32 / 64 threads	2 × 25 Gbit/s		csp:fr1:iaas:vmware:standard:v3
ADVANCE v3 Blade	768 GB	2.80/3.5 GHz (Gold 6342 or equivalent)	48 / 96 threads	2 × 25 Gbit/s		csp:fr1:iaas:vmware:advance:v3
PERFORMANCE 1 v3 Blade	384 GB	3.20/3.6 GHz (Xeon E-53I5Y or equivalent)	16 / 32 threads	2 × 25 Gbit/s		csp:fr1:iaas:vmware:perf1:v3
PERFORMANCE 2 v3 Blade	768 GB	3.00/3.6 GHz (Gold 6354 or equivalent)	36 / 72 threads	2 × 25 Gbit/s		csp:fr1:iaas:vmware:perf2:v3
PERFORMANCE 3 v3 Blade	1536 GB	2.60/3.5 GHz (Gold 6348 or equivalent)	56 / 112 threads	2 × 25 Gbit/s		csp:fr1:iaas:vmware:perf3:v3
PERFORMANCE 4 v3 Blade	512 GB	2.50/4.1 GHz (Intel 6426Y or equivalent)	32 / 64 threads	2 × 25 Gbit/s	2 × NVIDIA L40S 48 GB	csp:fr1:iaas:vmware:perf4:v3

Notes:

• (1) The memory amount delivered corresponds to the physically available memory on the blades. It is not possible to change the physical memory capacity of a blade.

• (2) Minimum base frequency / turbo frequency, expressed in GHz. By default, processors are configured in the BIOS for maximum performance.

• (3) Physical connectivity is shared between network and block storage access, as the underlying Cisco platform is converged.

• (4) The available GPU offering is continuously evolving. As of May 1, 2024, the offering is based on NVIDIA LOVELACE L40S GPUs. By default, the PERF4 blade is delivered with two 48 GB L40S GPUs. Contact support for further details if needed.

The computing offering availability is 99.99%, calculated monthly, including maintenance windows. Eligibility for SLA non-compliance claims requires the creation of an incident ticket. You must also have at least two hosts per cluster and enable the High Availability (HA) feature.
This feature allows your architecture to automatically restart your virtual machines on the second hypervisor in case of failure. If a zone of availability contains only one hypervisor, automatic restart is not possible.

Network

The networking service on Cloud Temple's IaaS platform is based on a VPLS technology infrastructure, providing flexible and high-performance segmentation to meet client requirements for connectivity and network isolation.

Layer-2 VLANs

The VLANs provided in the IaaS offering are of layer 2 type, offering complete network isolation and adaptable configuration according to requirements.

Hauptkonzepte

• VLAN-Teilung zwischen Clustern und Verfügbarkeitszonen (AZ):
  • VLANs können zwischen verschiedenen AZs und verschiedenen Clustern, die demselben Tenant gehören, gemeinsam genutzt werden.
• Inter-Tenant-Propagation:
  • VLANs können zwischen mehreren Teneants einer Organisation propagiert werden, was interne Kommunikation vereinfacht.

Netzwerkleistung

Die Netzwerkinfrastruktur gewährleistet eine geringe Latenz für optimale Leistung:

• Intra-AZ-Latenz: Unter 3 ms.
• Inter-AZ-Latenz: Unter 5 ms.

Schlüsselpunkte

1. Flexibilität: VLANs können so konfiguriert werden, dass sie sich an Multi-Cluster- und Multi-Tenant-Umgebungen anpassen.
2. Hohe Leistung: Eine minimale Latenz gewährleistet eine schnelle und effiziente Kommunikation zwischen Verfügbarkeitszonen.
3. Isolation und Sicherheit: Layer-2-VLANs bieten eine strenge Netzwerksegmentierung zur Sicherung von Daten und Datenflüssen.

Block Storage

Cloud Temple offers several classes of storage based on the IBM FlashSystem and IBM SVC technologies.

The IBM SVC technology enables delivering the required performance levels for our clients' environments through the large amount of embedded memory cache in the controllers and the ability to distribute a server's total IOPS across multiple SANs.

It is also used to enable replication of your block storage LUNs across availability zones or to facilitate maintenance operations on storage arrays.

The storage is primarily NVMe flash storage dedicated to professional workloads. The drives are utilized by the storage arrays in 'Distributed RAID 6'.

Storage Block Security and Encryption

To ensure the confidentiality of your data at rest, our entire block storage infrastructure integrates robust hardware-based encryption.

• Encryption Type: Data is encrypted directly on the disks (Data At Rest) using the XTS-AES 256 algorithm.
• Compliance: This encryption method complies with the FIPS 140-2 standard, ensuring a high level of validated security.
• Operation: Encryption is applied at the time data is written to the physical storage medium.

Attention regarding replication

It is important to note that this encryption protects data stored on disks. It is not active "on-the-fly", meaning data is not encrypted during storage replication operations between availability zones. Security of transfers is ensured through dedicated and secure communication channels.

The 'Mass Storage' storage class offers mechanical disks for archival needs in an economically efficient context. Several performance tiers are available:

Reference	Unit	SKU
FLASH - Essential - 500 IOPS/To	1 GiB	csp:(region):iaas:storage:bloc:live:v1
FLASH - Standard - 1500 IOPS/To	1 GiB	csp:(region):iaas:storage:bloc:medium:v1
FLASH - Premium - 3000 IOPS/To	1 GiB	csp:(region):iaas:storage:bloc:premium:v1
FLASH - Enterprise - 7500 IOPS/To	1 GiB	csp:(region):iaas:storage:bloc:enterprise:v1
FLASH - Ultra - 15000 IOPS/To	1 GiB	csp:(region):iaas:storage:bloc:ultra:v1
MASS STORAGE - Archival	1 TiB	csp:(region):iaas:storage:bloc:mass:v1

Note:

• Actual performance for a storage class is tied to the volume actually ordered, based on the "IOPS/To" metric, meaning "maximum IOPS per allocated terabyte",

Thus, a 0.5 To volume in the 'Standard' performance class will have an IOPS limit capped at 750 IOPS,
Similarly, a 10 To volume in the 'Ultra' performance class will have an IOPS limit of 150,000 IOPS,

• The IOPS limit is applied per volume, thus per datastore in a VMware environment,
• Storage availability is 99.99% measured monthly, including maintenance windows,
• There are no restrictions or quotas on read or write operations,
• There is no billing based on IOPS,
• No performance commitment is provided for the 'Mass Storage' class,
• The minimum size for a storage LUN is 500 GiB,
• When using storage replication, performance must be identical across both availability zones,
• No intelligent optimization mechanisms such as compression or deduplication are implemented: when you reserve 10 TiB of storage, you physically have 10 TiB of usable storage deployed on IBM machines,
• Storage LUNs are dedicated to the client environment.

Usage within the VMware Compute Offering

Within the context of using block storage in the form of a datastore in Cloud Temple’s VMware compute offering, you must take several important considerations into account:

1. Swap file (.VSWP) creation during virtual machine startup: When a virtual machine starts up, it creates a .VSWP file equal in size to its allocated memory on disk. Therefore, to successfully start your virtual machines, you must always have free space in your datastore equivalent to the total memory size of all your virtual machines. For example, if your datastore has 1 TiB of block storage and you want to start 10 virtual machines each with 64 GiB of memory, you will need 640 GiB of free disk space. Without sufficient space, virtual machine startup will be limited by the available capacity to create swap files.

2. Free space required for backup snapshots: The backup service uses instant snapshots. You must therefore always have sufficient free space to allow the creation of a snapshot during a virtual machine backup. The size of the snapshot depends on the amount of write activity from the virtual machine and the time required to perform the backup. Generally, it is recommended to maintain at least 10 % of free space for this operation.

3. Management of dynamic disks: Exercise caution when using dynamic disks. If you do not properly manage their growth, a lack of physical space can result in the virtual machine freezing (in the best case), or crashing with data corruption (in the worst case). It is crucial to closely monitor available space on your datastores when using this type of disk.

Proactive disk space management is essential to ensure the proper operation of your virtual machines and the reliability of backups. Always ensure you have sufficient space available for swap files, snapshots, and dynamic disk growth.

Backup Storage

Der von der Plattform automatisch bereitgestellte Speicher für die Sicherung Ihrer virtuellen Maschinen wird im Rahmen des bestellten Quotas bereitgestellt.

Referenz	Einheit	SKU
MASS STORAGE - Archivage	1 Tio	csp:(region):iaas:storage:bloc:backup:v1

Block Storage Replication

Principles

To enable the implementation of your business continuity plans, when it is not possible to maintain business continuity using application-level mechanisms and virtual machine replication is not suitable, Cloud Temple offers block-level storage replication mechanisms between availability zones within a region.

These replication mechanisms are applied to the storage LUNs of your environments, complementing backup solutions. The decision to use a replication mechanism for a given environment depends on various factors, including its criticality, acceptable data loss, and performance requirements for the application.

Cloud Temple provides two types of replication mechanisms deployed in an active/passive configuration:

• Asynchronous replication (or 'Global Mirror'): The 'Global Mirror' function provides an asynchronous copy process. When a host writes to the primary volume, the confirmation of the I/O completion is received before the write operation finishes on the secondary volume. If a failover operation is initiated, the application must recover and apply all updates that were not confirmed on the secondary volume. If I/O operations on the primary volume are paused briefly, the secondary volume can become an exact match of the primary volume. This function is comparable to a continuous backup process in which the latest updates are always missing. When using Global Mirror for disaster recovery purposes, you must consider how you intend to handle these missing updates.

• Synchronous replication (or 'Metro Mirror'): The 'Metro Mirror' function is a type of remote copy that creates a synchronous copy of data from a primary volume to a secondary volume. With synchronous copies, host applications write to the primary volume but do not receive confirmation that the write operation is complete until the data has been written to the secondary volume. This ensures that both volumes contain identical data once the copy operation is complete. After the initial copy operation finishes, the Metro Mirror function continuously maintains a fully synchronized copy of the source data at the target site. As of January 1, 2024, the 'Metro Mirror' function is no longer available for sale.

A site is then designated as "active" (or "primary") and another as "passive" (or "standby"). The business continuity plan is activated in the event of a disaster or during a PRA test. The passive site then takes over from the active site.

Asynchrone Replikation

Wenn Ihre Workloads kurze Wiederherstellungszeiten erfordern und die Verwendung von Anwendungsreplikationen oder VM-Replikationen nicht akzeptabel oder geeignet ist, können Sie eine SAN-Speicher-LUN zwischen zwei Verfügbarkeitszonen derselben Region replizieren.

Diese Lösung ermöglicht ein RPO von 15 Minuten und ein RTO unter 4 Stunden. Sie ermöglicht eine deutlich schnellere Wiederinbetriebnahme im Vergleich zur Durchführung einer Sicherungs-Wiederherstellung.

Bei einem in asynchroner Replikation betriebenen Speichervolume („Global Mirror“) arbeiten die SAN-Virtualisierungscontroller beider Verfügbarkeitszonen gemeinsam, um Schreibvorgänge auf beiden Standorten durchzuführen. Der primäre Standort wartet nicht auf die Bestätigung der Schreiboperation am sekundären Standort.

Die Schritte eines Schreibvorgangs sind wie folgt:

1. Ein Hypervisor möchte eine Schreiboperation auf einem Global-Mirror-Volumen durchführen: Er sendet die Anfrage an den SAN-Controller seiner Verfügbarkeitszone,
2. Der lokale SAN-Controller fordert den SAN-Controller der entfernten Zone auf, die Schreiboperation durchzuführen,
3. Der lokale SAN-Controller wartet nicht auf die Bestätigung des entfernten SAN-Controllers und führt die Schreiboperation stattdessen lokal durch,
4. Er gibt die Bestätigung an den Hypervisor zurück, der die Anfrage initiiert hat,
5. Die Hypervisoren am entfernten Standort greifen nicht direkt auf die Global-Mirror-LUN zu: Eine Dienstanforderung ist erforderlich.

SLA	Beschreibung
RPO 15 Min	Im Falle eines Ausfalls im primären Rechenzentrum entspricht die maximal verlorene Datenmenge maximal den letzten 15 Minuten der Schreibvorgänge
RTO < 4 Std	Im Falle eines Ausfalls im primären Rechenzentrum ist die Wiederinbetriebnahme innerhalb von 4 Stunden garantiert, abhängig von der Komplexität der Umgebung.

Im Falle der Aktivierung des Wiederherstellungsplans (PRA) führt das Cloud Temple-Team eine Präsentation der LUN 'Global Mirror' an die entfernten Hypervisoren durch, damit diese auf die Daten zugreifen können. Die Implementierung dieser Lösung erfordert daher, dass auf dem 'Standby'-Standort bereits Rechenressourcen und RAM reserviert sind, um im Falle eines Ausfalls die Aktivität wieder aufnehmen zu können.

Die Nutzung dieser Technologie erfordert zudem eine Verdoppelung des Speicherplatzes: Es ist notwendig, dass der entfernte Standort exakt denselben Speicherplatz wie der lokale Standort bereitstellt.

Die Nutzung dieses Mechanismus kann die Leistung der Anwendung bis zu 10 % beeinträchtigen. Nur die Speicherklassen 500 IOPS/To, 1500 IOPS/To und 3000 IOPS/To sind kompatibel.

Referenz	Einheit	SKU
STORAGE - Global Replication SAN	1 TiB	csp:(region):iaas:storage:licence:globalmirror:v1

Hinweis:

• Da die Angebote asynchron sind, besteht bei einem Ausfall die Möglichkeit, dass bestimmte Datenträgeroperationen nicht auf dem entfernten Standort geschrieben wurden. Es kann daher ein Risiko für die Datenkonsistenz bestehen, das im Risikoanalyse-Teil des Wiederherstellungsplans berücksichtigt werden muss.
• Die Block-basierte Speicherreplikation erfolgt für virtuelle Maschinen und Anwendungen transparent und wird nicht sichtbar.
• Daher ist es wichtig, Replikations-Szenarien auf Anwendungsebene oder gegebenenfalls VM-Replikationen vorzuziehen.
• Berechnungsressourcen und Arbeitsspeicher am Wiederherstellungsstandort können reduziert werden, um die Kosten zu optimieren, sofern eine eingeschränkte Leistung für das Geschäft während der Wiederherstellung akzeptabel ist.

VMware Virtualization

The VMware Cloud Temple offering qualified SecNumCloud is based on the VMware vSphere technology.

The platform is managed automatically by Cloud Temple (security compliance maintenance, operational readiness maintenance, ...).
It can be controlled via the graphical interface of the Console or through the associated APIs.

Note: For security reasons related to the SecNumCloud qualification,
the customer is not allowed to access the VMware virtualization platform directly (no direct access to vCenter, for example).
Indeed, the SecNumCloud qualification requires complete segregation between the technical asset management interfaces and the customer's interface (the Console).

• The implemented products are VMware ESXi, VMware vCenter, and VMware Replication.
• The virtualization offering's network does not use VMware NSX technology, but is instead managed physically using Juniper technology and the VPLS protocol.
• The storage does not use VMware vSAN technology, but exclusively IBM SANs via 32G Fiber Channel.
• No hidden optimization techniques are applied (compression, deduplication, ...).

Definition of a Compute Node Cluster ('Cpool')

The 'Cpool' is a grouping of VMware ESXi hypervisors, also known as an 'ESX cluster'.

All hosts within a __'Cpool'* belong to the same tenant and the same availability zone (AZ). They must necessarily have the same instance type:
It is not possible to mix different compute node models within the same cluster.

Since all compute nodes are delivered with the maximum physical memory, a software-level RAM usage limit is enforced at the cluster level to ensure it matches the billed RAM.

By default, each compute node has 128 GB of memory enabled within the __'Cpool'*.

A __'Cpool'* can contain a maximum of 32 hypervisors. Beyond this limit, a second cluster must be created.

Storage can be shared among __'Cpool'* clusters.

Memory Allocation for a 'Cpool'

Memory reservation is configurable per cluster. You can reduce or increase the amount of RAM to match your cluster-wide requirements.

Be careful not to exceed an average memory usage of 85% per compute node. Indeed, VMware's technology uses a compression-based optimization method that can significantly impact the performance of your workloads and complicate diagnostics. Similarly, excessive memory pressure on your compute nodes will force the hypervisor to offload part of its memory to disk to meet the needs of virtual machines.

This situation, known as 'Ballooning', severely impacts the performance of all virtual machines located on the affected datastore. Diagnosis becomes complicated in this context, as your monitoring will detect issues at the CPU level rather than at the memory or storage level. Also keep in mind that the first action the hypervisor performs when starting a virtual machine is to create a memory swap file (.vswap) on disk, with a size equal to the virtual machine's memory allocation. You must take this into account when sizing your storage.

Each compute node is delivered with 128 GB of memory enabled at the 'Cpool' level, but physically has access to the full amount of allocatable memory.

For example, in a cluster of three hosts of type vmware:standard:v2, the RAM reservation upon activation of the 'Cpool' will be 3 × 128 GB = 384 GB of RAM. You can extend it up to a maximum of 3 × 384 GB = 1,152 GB of memory.

Minimum memory for a 'Cpool' = number of hosts × 128 GB of memory
Maximum memory for a 'Cpool' = number of hosts × physical memory capacity per compute node

Cloud Temple Virtual Machine Catalogs

Cloud Temple provides you with a catalog of Templates that is regularly enriched and updated by our teams.
To date, it includes dozens of Templates and images ready to be deployed on your virtual machines.

Updating Hypervisors

Cloud Temple regularly provides updates for hypervisors to ensure security patches are applied.
However, updating hypervisors remains your responsibility, as we do not have visibility into your business constraints.

The update process is fully automated. To ensure service continuity, a minimum of two hypervisors is required per cluster during the update. Make sure you have the necessary permissions to perform these actions.

VM Affinity Management

Affinity and anti-affinity rules allow you to control the placement of virtual machines (VMs) across your hypervisors.
They can be used to manage resource utilization within your 'Cpool'.
For example, they help balance workloads across servers or isolate resource-intensive workloads.
In a 'Cpool' environment based on VMware, these rules are frequently used to manage VM behavior during vMotion operations.
vMotion enables the migration of virtual machines from one host to another without service interruption.

You can configure the following rules via the rule management interface:

• Affinity Rules: These rules ensure that certain virtual machines run on the same physical host.
  They are used to improve performance by keeping VMs that communicate frequently together on the same server, thereby reducing network latency.
  Affinity rules are particularly useful in scenarios where performance is critical—such as database systems or applications requiring fast inter-server communication.

• Anti-Affinity Rules: Conversely, these rules ensure that certain virtual machines do not run on the same physical host.
  They are essential for availability and resilience—for instance, to prevent all critical VMs from being affected in the event of a single host failure.
  Anti-affinity rules are crucial for high-availability applications, such as in production environments where fault tolerance is a top priority.
  For example, you would not want both of your Active Directory servers located on the same hypervisor.

When creating a rule, you define:

• The rule type (affinity / anti-affinity),
• The rule name,
• The activation status ('Status'),
• And the VMs involved within your hypervisor cluster.

Note: The affinity/anti-affinity rules available in the console are rules between virtual machines (not between hypervisors and VMs).

Asynchronous replication of your virtual machines in a VMware environment

Asynchronous replication of your virtual machines is a mechanism that pushes write operations from the source hypervisor to the standby site at regular intervals.

After an initial hot copy of all active storage to the standby site, only write operations are pushed at regular intervals to the dormant site.
The interval depends on the volume of writes (ranging from every hour to every 24 hours).

VM replication relies on the hypervisor’s snapshot mechanism. As such, this solution shares the same drawbacks, particularly sensitivity to the VM’s write volume, since the snapshot process is recursive and requires closing the snapshot.

A typical example of a machine that does not support VM replication is an FTP server receiving real-time video streams from surveillance cameras. The machine is constantly writing data and will not be able to close a snapshot without pausing the operating system for a significant period (several tens of minutes). If the hypervisor fails to close the snapshot, it will proceed to do so anyway—without the possibility of intervention, unless the virtual machine becomes corrupted.

SLA	Description
RPO of 1H to 24H	In the event of a disaster at the primary datacenter, the maximum amount of data lost corresponds to the last write push to the standby site.
RTO < 15 min	Virtual machine startup operation on the remote site after stopping the VM at the primary site.

In case of need or failure of a machine at the primary site, the mirrored machine at the standby site is activated.
Recovery requires reserving compute and RAM capacity at the standby site. It is also necessary to have the same storage space available at the passive site as at the active site.

Reference	Unit	SKU
PRA - VMware replication inter-AZ	1 VM	csp:(region):iaas:vmware:licence:replication:v1

Note: The minimum RPO must be defined based on the rate of change on the virtual machine.

Virtual Machine Backup

Cloud Temple offers a native, non-optional cross-architecture backup solution (mandatory for the French secnumcloud certification).

Backups are stored in a different availability zone and on a physically separate datacenter from the one hosting the virtual machine. They are encrypted using the AES 256-bit symmetric key algorithm (cipher mode xts-plain64) to ensure data confidentiality.

This setup protects against major failures in the production datacenter and enables restoration on a secondary datacenter (e.g., in case of fire).

The solution includes:

• Hot off-site backup of all disks,
• Instant presentation and booting of a virtual machine from the mass storage infrastructure, followed by hot reloading onto the production SAN,
• Partial file restoration from backup,
• Retention limited solely by allocated mass storage space.

This backup infrastructure is based on the IBM Spectrum Protect Plus solution — a no-agent architecture, easy to use, enabling automation of backup processes and optimization of mass storage space.

Backup and restore speeds depend on the change rate within the environments.
Backup policies are configurable per virtual machine via the Cloud Temple Console.

Note:

Some virtual machines are incompatible with this backup technology, which relies on the hypervisor’s snapshot mechanisms. These are typically machines with constant disk write workloads. The hypervisor cannot close the snapshot, forcing the virtual machine to be frozen to complete the closure operation. This freeze can last several hours and cannot be stopped.

In such cases, the recommended solution is to exclude the disk subject to continuous writes and back up the data using an alternative method.

Reference	Unit	SKU
BACKUP - Access to IBM Spectrum Protect Plus service	1 VM	csp:(region):iaas:backup:vm:v1

Create a backup policy

To create a new backup policy, you must submit a request to support. Support is accessible via the buoy icon in the top-right corner of the window.

Creating a new backup policy is done through a service request specifying:

Your Organization's name A contact person's name, email address, and phone number to finalize the configuration The tenant name The backup policy name The retention characteristics (x days, y weeks, z months, ...)

Advanced Data Protection (HSM/KMS)

Cloud Temple offers a advanced virtual machine encryption solution based on hardware security modules (HSM) and a key management service (KMS). This feature enhances the protection of sensitive data through centralized and secure key management, seamlessly integrated into the SecNumCloud environment.

Technische Architektur

Die Lösung basiert auf einer robusten Sicherheitsinfrastruktur, die folgende Komponenten umfasst:

• HSM (Hardware Security Module) : Module Thales Luna S790, zertifiziert nach FIPS 140-3 Level 3
• KMS (Key Management System) : Thales CipherTrust Manager zur zentralen Schlüsselverwaltung
• VMware-Integration : Kommunikation über das Protokoll KMIP (Key Management Interoperability Protocol)

High Availability Deployment

The HSM infrastructure is deployed across three availability zones in the FR1 region:

• PAR7S
• TH3S
• AZ07

This distribution ensures maximum high availability and resilience of the encryption service.

Operation and Key Hierarchy

The system uses a cryptographic key hierarchy to ensure data security:

Level	Key Type	Description	Location
1	Root of Trust (RoT)	Master key managed by KMS	HSM Luna
2	Domain Key (DK)	Domain key per client (multi-tenant isolation)	HSM Luna
3	Key Encryption Key (KEK)	Key encryption key per VM	CipherTrust Manager
4	Data Encryption Key (DEK)	Data encryption key per VM	VMware ESXi

Verschlüsselungsprozess

1. Generierung: VMware ESXi generiert eine eindeutige DEK für jede virtuelle Maschine
2. Schutz: Die DEK wird durch die KEK verschlüsselt, die in CipherTrust Manager gespeichert ist
3. Sicherung: Die KEK wird ihrerseits durch die HSM-Schlüsselhierarchie geschützt
4. Speicherung: Die verschlüsselte DEK wird zusammen mit den VM-Konfigurationsdateien gespeichert

Security and Compliance

Certifications

• FIPS 140-3 Level 3 : Highest level certification for HSMs
• Common Criteria EAL4+ : Advanced security evaluation
• SecNumCloud : ANSSI qualification integrated into the Cloud Temple environment

Multi-tenant Isolation

• Cryptographic separation: Each client has an isolated KMS domain
• Dedicated keys: A specific Domain Key per client
• Audit and traceability: Full logging of actions per domain

Activation and Usage

VM encryption can be activated with a single click from the Console.

For a detailed step-by-step guide with screenshots, see the VM Encryption Tutorial.

Voraussetzungen

• Konfigurierter Schlüsselanbieter: Ein HSM-/KMS-Anbieter muss auf der vStack aktiviert sein
• Deaktivierte virtuelle Maschine: Die VM muss heruntergefahren sein, bevor die Verschlüsselung durchgeführt wird
• Keine aktive Replikation: Die VM darf nicht repliziert werden (nicht kompatibel mit Global Mirror)
• Kein Snapshot: Es darf kein Momentaufnahme vorhanden sein
• Abonnement für den Dienst: Der erweiterte Schutzdienst muss abonniert sein

Hinweis: Für weitere Informationen zu den Voraussetzungen und dem vollständigen Prozess siehe den Leitfaden zur VM-Verschlüsselung.

Limitations and considerations

Compatibility

• Global Mirror : Encrypted virtual machines are not compatible with Global Mirror replication
• Restore : Backups of encrypted VMs retain their cryptographic protection
• Export : Exporting encrypted VMs requires specific procedures

Leistung

• Minimaler Einfluss: Die Hardware-Verschlüsselung gewährleistet optimale Leistung
• Transparenz: Kein Einfluss auf das Verhalten der Anwendungen

Recommended Use Cases

This advanced protection solution is particularly suitable for:

• Sensitive Data: Personal information, financial data, trade secrets
• Regulatory Compliance: GDPR, HIPAA, PCI-DSS, ISO 27001, PDIS requirements
• Critical Sectors: Banking, insurance, healthcare, defense
• Digital Sovereignty: Protection against unauthorized access, even in case of compromise

Reference	Unit	SKU
ADVANCED PROTECTION - VM Encryption via HSM/KMS	1 VM	csp:(region):iaas:vmware:encryption:hsm:v1

Note:

• The service requires a specific subscription and is not included in the standard IaaS offering
• Key management remains fully under Cloud Temple’s control within the SecNumCloud environment
• Encryption keys never leave the French, sovereign infrastructure