La donnée, une responsabilité conjointe entre vous et nous : considérations de design et recommandations.

Lorsque vous construisez vos infrastructures chez Scaleway, il est important de prendre en compte quelques règles simples, visant à limiter les risques de perte de données, quelle qu'en soit la raison. La donnée est une responsabilité conjointe entre vous et nous.

Ces raisons peuvent provenir, par exemple, d’une défaillance de matériel, d’une panne réseau, d’un piratage, d’un acte de malveillance ou encore de la destruction des infrastructures physiques.

En fonction du type de produit, à savoir purement bare metal, Infrastructure as a Service ou Platform as a Service, certaines précautions doivent être mises en œuvre.

Pour toujours plus de transparence, nous souhaitons clarifier et expliciter les moyens mis en œuvre par Scaleway : nos recommandations de design et la responsabilité de chacun vis-à-vis des données stockées et traitées chez nous.

Région et AZ

Concernant la localisation de la donnée, il est important de faire la distinction entre trois notions clés du cloud public : la région, la zone de disponibilité et le datacenter.

• Une région regroupe plusieurs zones de disponibilités (AZ), dans l’idéal trois à l’intérieur d’une zone géographique d'environ 200 km. Une région est aussi un réseau unique qui est dissocié (non interconnecté) des autres régions, à l’exception d’Amsterdam qui pour des raisons historiques est aussi un lieu de peering pour la région Paris. Chez Scaleway, Paris, Amsterdam ou Warsaw sont des régions.
• Une zone de disponibilité (AZ) est constituée d’un ou plusieurs datacenters situés dans une zone géographique d'environ 5 km avec une latence interne maximale de 1.4 ms et à minimum 50 km d’une autre zone de disponibilité de la même région. Chez Scaleway la zone de disponibilité fr-par-1 est constituée des datacenters DC2 et de DC3 et la zone de disponibilité fr-par-2 est constituée du datacenter DC5. La zone de disponibilité fr-par-3 sera constituée du datacenter DC4 et mis en service très prochainement.
• Un datacenter (DC) est une des localisations physiques d’une zone de disponibilité.

Concernant les produits d’infrastructure (IaaS) : lorsque le client commande la ressource, il a la possibilité de choisir la région et la zone de disponibilité. Le domaine de panne physique correspond à la zone de disponibilité et le domaine de panne réseau à la région.

La redondance et la gestion des services qui fonctionnent au-dessus sont sous la responsabilité du client. Le niveau de redondance le plus élevé est obtenu en développant son applicatif sur plusieurs régions distinctes.

Concernant les produits de plateforme (PaaS) : lorsque le client commande la ressource, il peut uniquement choisir la région. Le domaine de panne correspond à la région et est donc essentiellement lié au réseau. La redondance et la gestion du service sont sous la responsabilité de Scaleway. Autrement dit, le fournisseur de cloud opère les services de type PaaS dans plusieurs AZ d’une même région, sous sa responsabilité.

C’est pour cette raison simple que le design cloud public idéal s’appuie généralement sur trois zones de disponibilité dans une même région. À ce titre, nous nous inscrivons pleinement dans cette logique. En effet, avec trois zones de disponibilité, la distribution d’un produit PaaS au travers des différentes AZ permet d’avoir un niveau de redondance et de disponibilité élevé.

Soyons clairs : nous avons un point non optimal dans cette logique idéale du cloud public.

À ce jour, nos régions ne sont pas toutes constituées de trois zones de disponibilité. Ceci n’a aucun impact sur les produits IaaS. Pour les produits PaaS, le niveau de disponibilité et la résistance à un sinistre ainsi obtenu n’est pas aussi optimal qu’avec un design à trois zones de disponibilité. Ce point à été identifié depuis longtemps mais nous avons toujours refusé catégoriquement le compromis qui consiste à avoir plusieurs zones de disponibilité, cluster ou datacenter virtuel dans le même datacenter physique.

Pour éviter d’induire nos clients en erreur, nous leur recommandons systématiquement de construire leurs infrastructures sur plusieurs régions, ce qui est la solution la plus élégante pour avoir un service redondé et haute disponibilité.

Les investissements sont déjà validés depuis le début d’année, avec l’ouverture en 2021, de trois nouvelles zones de disponibilité additionnelles sur nos trois régions actuelles. Notre stack logicielle PaaS est conçue dans cette optique et sera redéployée en conséquence d’ici la fin d'année.

Bare Metal

Sur les produits Bare Metal, nous n’avons pas et ne pouvons pas avoir la main sur vos infrastructures et vos données.

Voici néanmoins nos recommandations pour minimiser le risque :

Un stockage en “RAID” n'est pas une sauvegarde ou une garantie de durabilité de la donnée. Scaleway n’assure aucune sauvegarde de vos données et ne peut même pas physiquement le faire à votre place.

A minima, vous devez impérativement mettre en place un dispositif de sauvegarde à distance, conformément aux règles élémentaires de l’informatique. Plus encore, nous recommandons fortement à nos clients de répartir leurs données sensibles sur plusieurs serveurs localisés dans des datacenters différents, voire des fournisseurs différents et avec une logique de PRA (Plan de Reprise d’Activité) ou de PCA (Plan de Continuité d’Activité).

Comment sauvegarder ?

• Solution 1 : nous proposons un service de sauvegarde FTP Dedibackup pour tous les clients de ces produits. Il existe deux versions : la première avec 100 Go de stockage inclus gratuitement avec chaque serveur et la deuxième avec 750 Go pour 4,99€ HT / mois. Côté Scaleway, ces données sont stockées dans Scaleway Object Storage, avec un niveau de redondance et de durabilité élevé (voir chapitre Object Storage). Cependant, il s’agit d’un produit très limité en fonctionnalités et en sécurité, qui est à considérer technologiquement comme dépassé en 2021.
• Solution 2 : nous recommandons fortement l’utilisation d'Object Storage croisé au niveau régional avec un archivage longue durée sur C14 Cold Storage. Par exemple, si votre serveur est localisé à DC3 (Paris), nous vous recommandons de stocker vos jeux de sauvegarde sur Object Storage de la région Amsterdam ou Warsaw. Cette solution est peu coûteuse, facile à mettre en œuvre et présente une durabilité extrêmement élevée.
• Solution 3 : la solution parfaite dans une logique multi-cloud est de stocker vos jeux de sauvegarde chez un prestataire autre que Scaleway, dans une localisation géographique suffisamment éloignée de votre serveur.

Considérations importantes de design :

• Le produit Dedibackup est basé sur Scaleway Object Storage. Bien que Object Storage soit un produit régional, compte tenu de l’absence de trois zones de disponibilité sur la région Paris, les données sont actuellement essentiellement stockées dans la zone de disponibilité fr-par-2 (DC5). Si votre serveur Bare Metal est situé à DC5, nous vous recommandons d’utiliser la solution 2. D’ailleurs, pour les clients Bare Metal de DC5, nous allons très rapidement vous proposer de choisir la région de stockage de votre Dedibackup.
• La localisation physique de votre serveur dans nos datacenters est disponible dans la console de gestion de compte et sur simple demande à l’assistance technique.

Point spécifique à RPN-SAN

RPN-SAN est une solution de Block Storage clé en main, managée par Scaleway et à destination des serveurs Bare Metal Dedibox fonctionnant sur le réseau privé RPN. Le produit est disponible en deux versions : une version “Basic” et une version “Haute-Disponibilité”.

Considérations importantes de design :

• Le produit RPN-SAN “Basic” ne dispose d’aucune redondance et est réservé à des clients avertis pour un usage spécifique. Les données sont enregistrées sur un seul serveur, sur une grappe de disque dur RAID. Ce stockage doit être considéré comme éphémère et n’être utilisé que comme tel. Les données ne sont pas dupliquées sur plusieurs serveurs, ni sur plusieurs datacenters et ne disposent d’aucune sauvegarde côté Scaleway.
• Le produit RPN-SAN “Haute-Disponibilité” dispose d’une redondance géographique. Les données sont réparties sur deux datacenters différents, en mode synchrone et disposent d’un réseau de fibre optique dédié pour ces synchronisations.

Comment sauvegarder ?

• Le produit RPN-SAN doit être sauvegardé comme un serveur Bare Metal, côté serveur, suivant une des trois méthodes décrites ci-dessus.
• Même dans sa version Haute-Disponibilité, bien que peu probable, les données stockées peuvent être irrémédiablement perdues et doivent donc être sauvegardées au même titre que le stockage local d’un serveur Bare Metal.

Produits Elements IaaS

Instances Scaleway Elements et Block Storage

Les instances Scaleway Elements disposent d’un stockage local et peuvent aussi bénéficier d’un stockage distant optionnel avec le produit Block Storage.

Depuis longtemps, il existe une certaine confusion sur le produit Instances. Nous souhaitons éclaircir ce point afin d’éviter des incidents que nous voyons bien trop souvent.

Le produit Instances n’est pas et ne sera jamais un produit dit de “VPS” (Virtual Private Server - un serveur dédié virtualisé), il ne fonctionne pas de la même façon et le stockage des données ne suit pas la même logique. Rappelons qu’une infrastructure cliente en Cloud Public conçue dans les règles de l’art doit normalement être conçue pour scaler horizontalement, sur un grand nombre d’instances, chaque instance ayant une durée de vie limitée, dont le nombre fonctionnant simultanément est calquée sur l’usage de l’application. Les données persistantes trouvent normalement leur place principalement dans de l’Object Storage mais aussi dans du Block Storage.

Pour les applications monolithiques et non distribuées, le cloud public n’est pas adapté et seuls les produits de serveurs Bare Metal ou le cloud privé répondent correctement à ce besoin.

Cette confusion sur le niveau de service des instances est entretenue (de longue date) dans le monde du cloud, mais on peut, avec un peu d'effort, mieux comprendre la différence avec les anciens modèles (VPS) :

Traduisons-le : 74,40 heures d'indisponibilité potentielle sur 1 mois.

Pour en savoir plus, consultez ce lien.

Considérations importantes de design :

• Le stockage dit local est un stockage éphémère. Ce stockage à la même durée de vie que l’instance et est optionnellement déplacé par Scaleway dans Scaleway Object Storage pour une utilisation future à la destruction de l’instance au choix du client (fonctionnalité “Power-Off” / “Stop”). Ce stockage local peut être sauvegardé sous forme d’un “Snapshot” et dupliqué autant de fois que vous le souhaitez. Il est constitué de SSD et de NVMe en grappe RAID à haute performance qui ont, par définition, une durée de vie et un taux d’écriture limité. Il n’est ni redondé, ni sauvegardé par Scaleway et ne doit en aucun cas être utilisé pour stocker de la donnée persistante et/ou importante.

• Ce stockage local est donc … local, attaché physiquement à l’hyperviseur qui abrite l’instance, sans aucune couche d’abstraction. Nous ne savons pas faire de migration à chaud sur ce type de stockage. La donnée est donc potentiellement définitivement perdue en cas de maintenance ou d’incident logiciel/matériel sur l’hyperviseur.

• Le stockage dit Block Storage est un stockage persistant haute disponibilité et haute performance. Il est constitué de multiples clusters redondants offrant une triple réplication de vos données. C’est un produit Iaas : son usage, sa résilience et sa durée de vie sont encadrés par une zone de disponibilité. Il en va de même pour l’instance.

• Il n’est pas possible d’utiliser le Block Storage d’une autre zone de disponibilité que l’instance pour des questions de latence.

Les bonnes pratiques et techniques de sauvegarde :

Règle d’or : à chaque type de stockage son usage.

• Le stockage local doit être utilisé pour le système d’exploitation (l’image), les logs, les données transactionnelles temporaires, les fichiers temporaires et les jeux de données nécessitant des calculs à haute performance.
• Le Block Storage pour le stockage des données utilisateur, les bases de données et les contenus.
• L’Object Storage pour toutes les données à délivrer et persistantes.
• Si le stockage local contient des données non éphémères, bien que fortement déconseillé, il faut à minima réaliser régulièrement un snapshot et le sauvegarder dans l’Object Storage d’une autre région et le conserver dans le stockage à froid C14.
• De même, pour le Block Storage, même si ce dernier est redondé et répliqué trois fois, il est hébergé physiquement dans la même zone de disponibilité que l’instance. C’est pourquoi il est fortement recommandé de réaliser régulièrement des snapshots et de créer un jeu de données dans l’Object Storage d’une autre région et dans le stockage à froid C14 Cold Storage.

Note sur les snapshots:

• Les snapshots des volumes locaux sont conservés par Scaleway dans l’Object Storage Scaleway. Les snapshots des volumes Block sont conservés dans le même cluster.
• Nous prévoyons à très court terme de donner accès à nos clients à ces snapshots directement via un bucket Object Storage afin de leur faciliter les actions de sauvegarde ou de lifecycle.

Produits Elements PaaS

Object Storage Scaleway Elements

Object storage est un système de stockage de données, compatible S3, qui offre un haut niveau de fonctionnalité et de résilience. C’est un produit entièrement managé par Scaleway, qui a donc l’entière responsabilité de la durabilité de la donnée.

Considérations importantes de design :

• Le produit Object Storage est actuellement disponible sur nos trois régions. Nous recommandons d’utiliser ce produit en stockage primaire pour vos applications dans le cloud.
• Notre plateforme utilise l’algorithme d’erasure-coding avec un ratio de 6:3.
• Nos régions ne sont actuellement pas constituées des trois zones de disponibilité nécessaires à une résilience maximale. Autrement dit, la disponibilité de la donnée peut être impactée en cas de destruction totale d’une zone de disponibilité. Avec la mise en service très prochainement de la zone de disponibilité fr-par-3, Object Storage sera résistant à la destruction totale d'une quelconque zone de disponibilité de la même région.
• Notre produit gère les cycles de vie de la donnée ainsi que les classes de service, notamment la classe Glacier. Les données stockées peuvent être transférées très facilement et rapidement vers notre produit C14 Cold Storage à des coûts extrêmement faibles.
• Le produit C14 Cold Storage est physiquement hébergé à l’écart des autres zones de disponibilité, dans le Datacenter DC4 (abri anti-atomique), qui bénéficie de protections physiques et incendie extrêmement pointues. Il est actuellement disponible uniquement sur la région Paris.

Les bonnes pratiques et techniques de sauvegarde :

• Dans l’idéal, vos applications doivent être conçues pour enregistrer les données dans l’Object Storage de deux régions différentes simultanément. Il s’agit par ailleurs de la seule solution technique permettant d’offrir une redondance vis-à-vis du réseau de la région. Ce raisonnement est valable quel que soit le fournisseur de Cloud Public. C’est une solution élégante qui nécessite peu de travail lors du développement de votre application et qui offre une fiabilité extrême tant sur le taux de disponibilité que sur la durabilité.
• Dans une logique multi-cloud, la première solution est à étendre avec la région d’un autre fournisseur de Cloud Public, compatible avec le protocole S3 et suffisamment éloigné de la région Scaleway que vous avez choisi.
• Si la solution de double région ou de multi-cloud ne peut être implémentée, nous recommandons tout simplement de sauvegarder régulièrement vos buckets. Avec Scaleway, rien de plus simple : il suffit de créer une règle de cycle de vie dupliquant vos buckets S3 dans C14 Cold Storage.
• C14 Cold Storage est le produit le plus fiable et le plus résilient du marché pour vos sauvegardes. Il est proposé avec les standards les plus élevés du marché à un prix très faible. Nous offrons les premiers 75 Go chaque mois, et les gigaoctets supplémentaires sont facturés moins de 0,002€ par mois. Une fois la donnée écrite, le média physique est électriquement déconnecté, mettant à l’abri vos données de potentielles défaillances logicielles ou humaines.

Database as a Service (DBaaS) Scaleway Elements

Le produit de base de données managé s’appuie sur les instances Scaleway Elements. Comme tous les acteurs du marché, il a donc le même scope que les Instances, et repose donc sur la même zone de disponibilité.

Considérations importantes de design :

• En version standard, les produits DBaaS disposent de fonctionnalités de Backup/Restore et d’export de base de données au travers de Scaleway Object Storage.
• En version HA (mode haute-disponibilité), les deux nodes composant votre cluster de base de données sont répartis dans des baies différentes, sur des hyperviseurs différents mais dans la même zone de disponibilité. Cette option permet de rendre votre base de données insensible au crash de l’hyperviseur ou d’une instance.
• Par défaut, nous réalisons des sauvegardes croisées entre régions. Les DBaaS de Paris sont sauvegardées à Amsterdam, celles d’Amsterdam à Paris et celles de Varsovie à Paris également. L’accès à ces sauvegardes est possible pour l’utilisateur via la console ou l’API au travers d’un pre-signed link valable 24h.

Les bonnes pratiques et techniques de sauvegarde :

• Dans l’idéal, et dans une logique de multi-cloud, nous recommandons l’usage simultané ou en failover de plusieurs clusters de base de données, dans plusieurs régions ou fournisseurs de cloud différents. Néanmoins, en pratique, ceci est presque impossible à mettre en place avec des bases de données relationnelles.
• Une bonne pratique consiste à toujours avoir un cluster DBaaS en standby, configuré et prêt à l’emploi dans une autre région et prêt à recevoir le dernier dump du cluster principal. Pensez à utiliser des noms FQDN avec un TTL faible (60 secondes) depuis le service Scaleway Domains pour changer facilement et rapidement le cluster destination de vos applications.
• N’oubliez pas d’archiver régulièrement (plusieurs fois par jour) dans C14 Cold Storage des dump de vos bases de données DBaaS.

Kubernetes Kapsule Scaleway Elements

Kapsule est un orchestrateur d’instances. A ce titre, il a le même scope que des Instances, et repose donc sur la zone de disponibilité.

Les recommandations sont identiques à celles des Instances Scaleway Elements. Dans l’idéal, nous vous recommandons d’avoir deux clusters Kubernetes dans deux régions différentes, voir deux fournisseurs de cloud distincts, et d’utiliser notre produit de load-balancing multi-cloud vers vos différents clusters.