Concepts de l’API bare metal

Un service bare metal est un serveur physique attribué à votre organisation. L’objet décrit la machine (hardware : CPU, memoryGb, disques et capabilities), son emplacement (region : code du datacenter, ville, installation et rack), ses ports réseau (interfaces), ses adresses (primaryIpv4, primaryIpv6), le dernier système installé (operatingSystem), son bootMode et le quota mensuel de trafic (bandwidth.includedEgressGb). Obtenir un service bare metal renvoie tout cela avec l’operation en cours et la dernière terminée dans lastOperation. Lister les services bare metal renvoie les services de l’organisation par page, sans interfaces, state ni opérations ; ?datacenter= limite la liste à un datacenter nommé par un code comme ams1 ou son ID. Modifier un service bare metal change name, que le déploiement suivant utilise aussi comme nom d’hôte.

États

Pour les commandes de verrouillage de la console et leur portée, consultez Verrouiller et déverrouiller un serveur.

state répond à une question : le serveur peut-il accepter une nouvelle opération maintenant ?

Lorsque plusieurs états s’appliquent, DELETING prime, puis SUSPENDED, puis OPERATION_IN_PROGRESS.

isLocked accompagne l’état sans le modifier. Verrouiller et déverrouiller l’activent et le désactivent ; les deux nécessitent organization.baremetal.lock et répondent 204. Un serveur verrouillé refuse déploiements, tests matériels, annulation de ces opérations, commandes d’alimentation, réinitialisations BMC, changements de segments, rattachements et détachements de réseaux virtuels et sa propre suppression, avec 422 SERVICE_LOCKED. Le renommage, iPXE et le mode de démarrage, les sessions console et les supports virtuels restent utilisables.

isSuspended devient vrai lorsque le service est suspendu. Un serveur suspendu refuse les déploiements, tests, annulations, commandes d’alimentation, réinitialisations BMC, changements de segments et rattachements réseau refusés par un serveur verrouillé, ainsi que le renommage, les modifications iPXE et de démarrage, les sessions console, les supports virtuels, les mesures matérielles et les listes d’images et applications à déployer. Chaque appel répond 422 SERVICE_SUSPENDED jusqu’au rétablissement. Un serveur à DELETING refuse le même ensemble avec 422 SERVICE_DELETING.

Opérations

L’installation, l’effacement et les tests s’exécutent comme opérations de type DEPLOYMENT, WIPE ou TEST. Une seule opération s’exécute par serveur : en lancer une seconde répond 409 avec OPERATION_IN_PROGRESS. Seul notre personnel lance les effacements, qui n’apparaissent pas dans l’historique des opérations.

Un déploiement installe un système issu de Lister les images système. La requête de déploiement le nomme dans image, par son id ou slug, et accepte sshKeyIds ou un password (avec un username facultatif), un raidVariant (NONE, RAID0, RAID1, RAID5, RAID6 ou RAID10 ; choisissez une valeur des raidVariants de l’image) et un document cloudInit facultatif. Les niveaux RAID pour serveurs dédiés comparent RAID 0, 1, 5 et 10 selon la capacité utilisable et la tolérance aux pannes. Un déploiement peut installer une application plutôt qu’une image simple : application, un id ou slug de Lister les applications, remplace image ; envoyer les deux ou aucun donne un détail DEPLOY_SELECTION_INVALID. applicationMetadata est un objet JSON contenant les paramètres décrits par le metadataSchema de l’application. Déployer votre premier serveur présente les autres vérifications requises.

Un test matériel sollicite la machine sans installation et sans destruction, en conservant les données sur les disques. Exécuter un test matériel exige quatre interrupteurs : isCpuIncluded, isMemoryIncluded, isDiskIncluded et isSmartIncluded. Des paramètres facultatifs règlent les étapes : cpuDurationSeconds, memoryDurationSeconds, diskDurationSeconds (10 à 1800 chacun), cpuWorkers (1 à 1024), memoryPercent (1 à 95), diskBlockSize (512 octets à 16m, par pas de 512, en octets ou avec suffixe k ou m) et diskIoDepth (1 à 256). Un paramètre omis conserve la valeur par défaut de l’outil ; hors plage, il donne 400 VALIDATION_ERROR. Le résultat final est details.report dans Obtenir une opération : isPassed pour l’ensemble et chaque étape, avec le débit disque en octets par seconde.

Un déploiement affiche CREATED, puis WAITING_FOR_PXE_BOOT, puis CHECKED_IN lorsque le programme d’installation s’est signalé, et se termine par COMPLETED, FAILED ou CANCELLED. Un déploiement d’application passe aussi par IN_PROGRESS après l’étape du système. Traitez tout état autre que ces trois états finaux comme en cours et suivez progress et lastProgressMessage. Lister les opérations fournit l’historique du serveur, du plus récent au plus ancien ; Obtenir une opération renvoie une exécution avec tous ses rapports de progression.

Annuler une opération arrête un déploiement ou test en cours nommé par son id et répond 204. Une opération déjà terminée, ou qui se termine pendant l’enregistrement de l’annulation, répond 422 ENTITY_STATE_INVALID. Un ID ne désignant aucun déploiement ou test de ce serveur donne 404.

Alimentation et mesures matérielles

Envoyer une commande d’alimentation accepte ON, FORCE_OFF, GRACEFUL_SHUTDOWN, FORCE_RESTART et GRACEFUL_RESTART. Les commandes normales demandent au système de s’arrêter ; les forcées agissent directement sur l’alimentation. L’état actuel est powerState dans Obtenir l’état du service. Le contrôleur de gestion fournit aussi l’état des alimentations, les capteurs thermiques et la consommation ; Réinitialiser le BMC redémarre le contrôleur lorsqu’il ne répond plus. Alimentation et accès distant détaille chaque appel.

Accès distant

Une session console ouvre l’écran et le clavier du serveur dans un navigateur, pour un système qui ne répond pas sur le réseau ou un réglage BIOS. Les supports virtuels montent une ISO de votre bibliothèque ISO comme lecteur sur le serveur, pour démarrer un programme d’installation absent des images. Tous les contrôleurs de gestion ne proposent pas tout ; hardware.capabilities indique les possibilités du serveur :

Un appel non pris en charge par le contrôleur répond 422 OPERATION_NOT_SUPPORTED_PLATFORM et la console désactive l’onglet.

Mode de démarrage et iPXE

bootMode vaut LOCAL_DISK ou PXE. Il détermine les réseaux portés par les ports ; Définir le mode de démarrage est donc une modification réseau : l’appel répond 202 pendant la reconfiguration des commutateurs, suivie par networkChange dans l’état du service jusqu’à son application. Lorsqu’un serveur en mode PXE démarre depuis le réseau, le provisionnement recherche la MAC du port de démarrage et fournit le script iPXE enregistré sur ce service. Les scripts iPXE personnalisés présentent les appels.

Ports réseau

interfaces répertorie les segments du serveur. Un segment est un port réseau, ou deux ports agrégés en LACP (bondMode LACP), et porte les réseaux virtuels rattachés. Son name est le nom d’interface écrit sur l’hôte par un déploiement : nom du port lui-même, ou bond0, bond1, etc. pour un bond. Son segmentId est l’ID utilisé par les appels de segment, rattachement et adresse ; chaque port dans physicalInterfaces porte le même segmentId.

Obtenir les capacités réseau liste chaque port et son segmentId, ainsi que les groupes d’agrégation, un par paire de commutateurs, avec les interfaceIds des ports câblés à cette paire et leur nombre dans maxBondSize. Créer un segment accepte interfaceIds : un port crée un segment simple, deux un bond. Les deux ports d’un bond doivent appartenir au même groupe, se trouver sur des commutateurs différents de la paire et utiliser le même numéro de port ; trois ports ou plus, ou deux ne respectant pas ces règles, donnent 422 avec un détail BOND_INVALID. Un port déjà dans un segment donne 409 INTERFACE_IN_USE ; supprimez ce segment d’abord. Les deux appels mettent une modification de commutateur en file et sont refusés si une opération ou une autre modification réseau est en cours. Le rattachement des réseaux aux segments figure dans Configurer les réseaux virtuels.

Trafic

bandwidth.includedEgressGb est le quota mensuel du service ; null signifie illimité. Seul le trafic sortant compte, en gigaoctets décimaux de 10^9 octets. Le trafic au-delà n’est pas limité. Sur un abonnement horaire, chaque Go dépassant le quota de l’offre est facturé.

Le trafic est mesuré sur les ports des commutateurs dès la création du service. Obtenir l’usage de bande passante couvre les 30 derniers jours, de periodStart à periodEnd : egressBytes et ingressBytes pour toute la fenêtre et par jour sous daily, avec le quota dans includedEgressBytes. Obtenir la série temporelle de bande passante renvoie les débits en bits par seconde, pour le serveur et par port, entre start et end (les dernières 24 heures par défaut), avec stepSeconds d’au moins 60. Un pas générant trop de points pour la fenêtre répond 422 avec un détail BANDWIDTH_STEP_INVALID. Dans les deux cas, null signifie qu’aucune mesure n’existe pour ce jour ou pas ; 0 est une valeur mesurée.

Supprimer un service

Supprimer un service bare metal exige organization.billing.subscriptions.manage et répond 202 sans corps. La facturation du serveur s’arrête immédiatement. Le serveur affiche ensuite state à DELETING pendant son arrêt et le retrait des réseaux ; une fois terminé, Obtenir un service bare metal répond 404. Renvoyer la suppression pendant DELETING ne change rien. Lorsque le serveur est le dernier de son abonnement (Obtenir l’abonnement du service l’indique), les blocs d’adresses de l’abonnement sont libérés après son retrait ; la facturation détaille les abonnements.

Une suppression est refusée dans les cas suivants :

Une fois le serveur retiré, ses disques sont effacés de manière sécurisée ; la machine n’est proposée à personne d’autre avant la réussite de cet effacement. Aucune route n’annule une suppression : copiez les données nécessaires avant de l’envoyer.