Accès et vérification des disques

Pour accéder au serveur dédié, commencez par vérifier sa livraison

Avant de mettre en service le stockage de fichiers et les sauvegardes, vérifiez l’adresse, le système et les disques connectés directement. Une fois le serveur livré, son adresse IP et ses identifiants de connexion sont disponibles dans sa fiche, dans le portail.

Vérifier les informations de livraison dans OnuCloud Consulter les méthodes de connexion OnuCloud

Le paiement ne vaut pas confirmation de livraison. Attendez que le serveur soit prêt, puis connectez-vous avec les informations de sa fiche.

Systèmes Linux
SSH
Windows Server
RDP
Adresse de gestion à distance
Première IPv4
Vérifier avant de se connecter

Les informations de livraison sont le point de départ

Le paiement de la commande, la préparation du serveur et la connexion à distance sont trois étapes distinctes. Avant toute connexion, fiez-vous à l’état indiqué dans le portail. Ne déduisez pas l’adresse du nom de la commande et ne réutilisez pas les identifiants enregistrés pour un autre serveur.

  1. 01

    Identifier le bon serveur

    Connectez-vous au portail OnuCloud, ouvrez la fiche du serveur associé à la commande et vérifiez la configuration mémoire ainsi que le système choisi. Si plusieurs serveurs sont gérés, confirmez d’abord que la fiche ouverte correspond bien à l’équipement concerné avant de copier les informations de connexion. Vous éviterez ainsi d’appliquer une sauvegarde ou une opération sur un autre disque au mauvais serveur.

  2. 02

    Lire tous les paramètres de connexion

    Relevez dans la fiche du serveur l’adresse IP, le compte de connexion, le mot de passe et les autres paramètres communiqués. Ne devinez ni le port ni le nom d’utilisateur à partir des valeurs courantes : ce guide ne fournit ni compte générique ni port fixe. Les paramètres de la fiche de livraison font foi.

  3. 03

    Choisir le client adapté au système

    SSH est utilisé avec Linux, FreeBSD et Proxmox VE ; Windows Server utilise RDP. Vérifiez les anciennes adresses, les anciens comptes et les mots de passe enregistrés dans l’outil de connexion. Si la livraison du serveur n’est pas terminée, consultez son état au lieu de multiplier les tentatives avec des paramètres non vérifiés.

Les mots de passe, clés privées et identifiants complets ne doivent pas figurer dans des captures d’écran publiques, l’historique des commandes ou le corps d’un e-mail ordinaire. Pour le diagnostic, conservez le message d’erreur et masquez les champs sensibles sur les captures d’écran.

Linux et systèmes de type Unix

Première connexion SSH : vérifier l’identité avant de modifier l’authentification

AlmaLinux, CentOS Stream, Debian, Ubuntu Server, FreeBSD et Proxmox VE se connectent via SSH. Les méthodes d’administration varient selon le système, mais les paramètres de connexion proviennent tous des mêmes informations de livraison.

Établir la première connexion

Dans le client SSH local, indiquez la première adresse IPv4, le compte fourni et le port réel, puis connectez-vous avec la méthode d’authentification précisée dans la fiche. À la première connexion, si une alerte sur l’identité de l’hôte s’affiche, vérifiez le serveur visé et les informations d’identité disponibles. Ne considérez pas cette confirmation comme une étape à ignorer systématiquement.

Si la même adresse a déjà servi avec un autre système, le client peut signaler un changement d’identité de l’hôte. Vérifiez d’abord si le système a été réinstallé ou si la destination a changé, puis mettez à jour les données enregistrées localement. N’ignorez pas le contrôle d’identité simplement pour faire disparaître l’alerte.

Vérifier la nouvelle authentification avant de fermer l’ancienne session

Après la première connexion, il est recommandé de modifier le mot de passe et de configurer les clés SSH selon les comptes et les permissions du système choisi. La clé privée reste sur le poste d’administration et la clé publique est ajoutée à la configuration des clés autorisées du compte cible. Ces deux clés ne sont pas interchangeables.

Avant de modifier l’authentification ou le pare-feu, gardez la session en cours et ouvrez-en une autre pour tester les nouveaux paramètres. Une fois la connexion confirmée dans cette nouvelle session, fermez l’ancienne. Vous éviterez qu’une modification coupe toutes les voies d’administration à la fois.

Les commandes Linux d’inspection des disques ne s’appliquent pas directement à FreeBSD. SSH fournit le mode d’accès ; les opérations de stockage et de gestion des permissions doivent suivre les outils propres à chaque système.

Windows Server

Se connecter en RDP avec le compte de livraison

Les serveurs équipés de Windows Server sont accessibles via le protocole Bureau à distance (RDP). Ouvrez le client Bureau à distance local et établissez une session avec la première adresse IPv4 et les identifiants indiqués dans le portail. Ne réutilisez pas les identifiants enregistrés d’un autre serveur.

  1. 01

    Vérifier la destination et le compte

    Contrôlez l’adresse de l’ordinateur, le champ du compte et les paramètres de connexion utilisés par le client, en particulier les anciens comptes remplis automatiquement. Vérifiez les alertes de certificat ou d’identité à l’aide des informations de livraison : l’utilisation du Bureau à distance ne dispense pas de confirmer la destination.

  2. 02

    Vérifier la saisie et la langue du système

    Si le mot de passe est refusé, vérifiez d’abord la disposition du clavier, la casse et les espaces ajoutés lors du copier-coller. La langue de Windows Server peut être l’anglais, le chinois traditionnel ou le chinois simplifié. Elle ne modifie ni le compte fourni ni la règle d’utilisation de la première adresse IPv4.

  3. 03

    Conserver une voie d’administration rétablissable

    Une fois sur le bureau, modifiez les stratégies de compte, les permissions du Bureau à distance et le pare-feu. Après chaque changement, vérifiez le résultat avec une nouvelle session. Fermer le client ne constitue pas une sauvegarde des données : les fichiers importants et l’état des services doivent être contrôlés séparément.

Rôle des adresses

La première adresse IPv4 sert à l’administration à distance

Si le serveur dispose de plusieurs adresses IPv4, SSH et RDP utilisent la première de la liste. Les autres adresses sont destinées aux services du système ou à la planification des machines virtuelles. Leur présence dans les informations de livraison n’en fait pas automatiquement des points d’accès de gestion.

Définissez d’abord le rôle des adresses, puis configurez le système et les services.
Rôle de l’adresseUsageVérifications avant l’opération
Première IPv4Administration à distance via SSH ou RDPVérifiez-la à l’identique dans la fiche du serveur et utilisez le compte et les identifiants de ce serveur.
Autres IPv4À attribuer aux services ou aux machines virtuelles depuis le systèmeVérifiez l’attribution des adresses, la configuration réseau du système et les interfaces d’écoute des services afin d’éviter les doublons.

La modification du réseau de l’hôte et l’attribution d’adresses aux machines virtuelles relèvent de la configuration système. Notez les paramètres fonctionnels, puis vérifiez les changements étape par étape. Évitez de modifier simultanément l’adresse de gestion, le routage et l’authentification afin de pouvoir identifier l’origine d’un changement de connexion.

À vérifier avant la première connexion pour gérer le stockage

Deux NVMe indépendants : les identifier avant de créer un pool

Les serveurs dédiés AMD sont équipés de série de 2 × 1TB NVMe, connectés séparément, sans RAID matériel. Pouvoir se connecter au système confirme uniquement que l’accès d’administration fonctionne. Avant de mettre en service le stockage de fichiers, vérifiez aussi les disques, l’espace occupé par le système et le niveau de redondance souhaité.

Associer d’abord chaque disque à son emplacement et à son usage

Notez l’identifiant du disque, sa capacité, ses partitions existantes et ses points de montage. Distinguez le disque système de celui prévu pour les données. Si des disques supplémentaires ont été commandés, consignez-les séparément et ne déduisez pas leur emplacement physique de l’ordre d’énumération des périphériques.

Les commandes ci-dessous sont destinées à Linux. Elles lisent uniquement les informations sur les périphériques bloc et les systèmes de fichiers : elles ne créent pas de RAID et ne formatent rien. Les noms des périphériques dépendent du résultat réel. Sur FreeBSD, utilisez les outils d’inspection du stockage propres au système.

Linux · Vérification en lecture seule

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt

Examinez d’abord les résultats, puis déterminez la cible de l’opération. Si l’usage d’un périphérique n’est pas certain, n’exécutez aucune commande d’effacement, de partitionnement ou de création de pool.

Utilisation indépendante : capacité et tolérance aux pannes sont distinctes

La capacité brute nominale de deux disques de 1TB totalise 2TB, mais ne correspond pas à l’espace final disponible dans le système de fichiers. Les partitions, l’espace utilisé par le système et le formatage réduisent la capacité utile. Les données d’un disque ne sont pas automatiquement copiées sur l’autre.

Cette configuration convient aux usages répartis clairement entre les disques, mais deux disques ne constituent pas à eux seuls une solution de redondance.

Utilisation en miroir : redondance et sauvegardes sont distinctes

Avec deux disques de 1TB configurés en miroir ZFS ou logiciel, prévoyez une capacité nominale d’environ la moitié. L’espace disponible réel dépend aussi de la place occupée par le système et le système de fichiers. Avant de créer le pool, définissez où iront les données et transférez d’abord celles qui se trouvent sur des partitions existantes.

Un miroir protège contre la panne d’un disque, mais ne remplace pas une copie permettant de récupérer des données supprimées ou écrasées par erreur, ni de faire face à un problème système. Les sauvegardes hors site doivent être configurées séparément.

Une fois le stockage prêt, configurez les sauvegardes en définissant clairement le répertoire source, la destination, la politique de conservation et la méthode d’authentification. Commencez par un transfert de petite taille et testez la restauration. Un statut « terminé » ne prouve pas qu’une restauration est possible : récupérez réellement des fichiers et vérifiez leur contenu et leurs permissions.

Localiser le problème étape par étape

En cas d’échec, distinguer l’adresse, l’authentification et le réseau

Un délai d’attente dépassé, une connexion refusée et un échec d’authentification correspondent à des problèmes différents. Conservez le message d’erreur original du client et suivez les étapes ci-dessous. Cela permet de cibler la cause plus efficacement que de modifier à répétition les mots de passe et le pare-feu.

  1. 01

    Vérifier l’état de livraison et la première adresse

    Rouvrez la fiche du serveur et confirmez qu’il s’agit du bon équipement, vérifiez son système et son état actuel. Assurez-vous de ne pas utiliser une adresse IPv4 supplémentaire et que le client n’a pas conservé l’adresse d’un ancien serveur. Tant que la livraison n’est pas confirmée, ne concluez pas à une panne du système sur la seule base d’un échec de connexion.

  2. 02

    Distinguer une erreur d’authentification d’une absence de connexion

    En cas d’échec d’authentification, vérifiez le compte, la méthode utilisée, la saisie du mot de passe et la correspondance des clés. Si la connexion expire ou est refusée, notez le message et évitez de modifier immédiatement les stratégies de compte. Le problème peut aussi venir du réseau ou des règles des services système.

  3. 03

    Vérifier les règles réseau des deux côtés

    Examinez le réseau local, les restrictions de sortie et les paramètres du client, puis vérifiez le pare-feu du serveur et les règles relatives à SSH ou RDP. L’absence de réponse à un type de test ne suffit pas à prouver que la connexion à distance est impossible : tenez compte du résultat obtenu avec le client utilisé.

  4. 04

    Décrire le problème dans un ticket

    Si la connexion reste impossible, connectez-vous au portail et ouvrez un ticket en indiquant la référence de commande, le système, le protocole utilisé, le texte exact de l’erreur, l’heure du problème et les modifications de configuration déjà effectuées. Précisez si une connexion a déjà fonctionné et les vérifications réalisées. Ne copiez pas plusieurs fois un mot de passe complet ou une clé privée dans le ticket.

Ouvrir un ticket de diagnostic d’accès dans OnuCloud
Rétablir l’accès après une erreur de configuration

Un accès de secours ne remplace pas l’administration à distance au quotidien

Après une erreur de configuration réseau ou d’authentification, la session graphique accessible dans le navigateur du portail sert uniquement au dépannage. Elle n’est pas destinée à fournir un mode de connexion public. Pour l’administration quotidienne, continuez à utiliser SSH ou RDP.

Pour rétablir l’accès, commencez par examiner les dernières modifications du pare-feu, du réseau ou des comptes. Évitez de réinstaller le système sans connaître l’état des données. Pour obtenir de l’aide, décrivez les opérations effectuées dans un ticket du portail. Avant toute réinstallation, transférez les données à conserver : une réinstallation n’est pas une méthode de diagnostic sans perte.

Accès au DGX Spark

Ouvrir une session d’administration sur DGX OS via SSH

Les identifiants de livraison du DGX Spark sont également disponibles dans le portail OnuCloud. Ouvrez la fiche du serveur concerné, relevez l’adresse et les informations du compte, puis connectez-vous à DGX OS via SSH. N’appliquez pas les choix de système ni les plans de stockage des serveurs dédiés AMD.

Se fier aux informations propres à cette machine

Utilisez l’adresse et les identifiants de la fiche. Ne devinez ni le compte ni le port par défaut. Après la première connexion, vérifiez la session SSH et les permissions du compte avant de modifier les clés ou le pare-feu. Après toute modification, gardez la session en cours et ouvrez une autre connexion pour tester les nouveaux paramètres d’authentification.

Une fois la connexion établie, préparez l’environnement des modèles et des applications. La connexion SSH ne confirme pas que les dépendances des applications sont prêtes : la configuration de l’environnement et les données métier restent à gérer séparément.

Redémarrage forcé et réinstallation via ticket

Le DGX Spark ne dispose pas de BMC / IPMI. Pour demander un redémarrage forcé ou une réinstallation du système, ouvrez un ticket dans le portail en précisant l’identifiant de la machine, le problème rencontré et les opérations déjà effectuées. N’essayez pas d’utiliser une méthode de gestion hors bande conçue pour un autre type d’équipement.

Avant de demander une réinstallation, transférez les fichiers à conserver et confirmez la machine concernée. La restauration de l’environnement et la conservation des données sont deux sujets distincts.

Consulter les conditions d’utilisation du DGX Spark sur OnuCloud

Poursuivre à partir de la fiche du bon serveur

Pour un serveur livré, vérifiez d’abord sa fiche et ses identifiants. Pour un stockage encore à planifier, définissez d’abord l’emplacement des disques et la redondance souhaitée avant de passer à la configuration.

Ouvrir la fiche du serveur dans OnuCloud Configurer un serveur dédié OnuCloud