Dépannage d’un VPS ARM pour des services dédiés

Pourquoi cette note existe

Cette note documente le processus de dépannage autour de l'hébergement de services dédiés sur un VPS basé sur ARM.

L'environnement a utilisé un exemple de cloud ARM/Ampere pour l'hébergement de serveurs légers. L'objectif était d'exécuter des services dédiés, y compris des déploiements compatibles avec l'extension sans payer pour un plus grand x86 VPS traditionnel.

La partie utile du projet n'était pas seulement l'obtention d'un service dédié en ligne. C'était apprendre à déboguer la pile complète quand quelque chose casse:

• État de l' instance du nuage
• volume de démarrage
• Accès SSH
• Limites des fournisseurs
• pare-feu/règles de sécurité
• Compatibilité ARM contre x86
• Architecture d'image Docker
• bibliothèques natives d'exécution
• registres des processus de service dédiés
• comportement de redémarrage du service

Cela fait de la note une pièce de dépannage d'infrastructure, pas seulement une note de configuration de service dédié.

Contexte du projet

L'environnement serveur était un VPS ARM utilisé pour l'hébergement et l'expérimentation de services.

Les principales charges de travail étaient les suivantes :

• Hébergement de serveur de service hébergé
• Hébergement de serveur de service hébergé
• ExtensionDéploiement rapide
• Essais de Docker
• débogage d'exécution spécifique à l'architecture
• Gestion des services Linux
• administration SSH à distance

Le VPS a été attrayant parce que les instances de cloud ARM peuvent fournir des ressources solides pour une utilisation à bas coût ou de style de niveau libre, mais ARM ajoute également des problèmes de compatibilité lorsque le logiciel suppose x86.

Ce que cette note veut prouver

• les serveurs cloud peuvent échouer à différentes couches
• L'échec de SSH ne signifie pas toujours que le serveur est supprimé
• l'état de l'instance, le volume de démarrage et les règles du réseau doivent être vérifiés séparément
• Les serveurs ARM sont utiles mais nécessitent une sensibilisation à l'architecture
• Les images Docker doivent correspondre à l'architecture du CPU sauf si l'émulation est utilisée
• Les services dédiés dépendent souvent des bibliothèques natives et des hypothèses d'exécution
• les journaux comptent plus que de deviner
• une liste de contrôle de récupération prévient la panique lorsqu'un serveur disparaît ou cesse de répondre

Pioche et outils utilisés

Calque Cloud

• ARM/Ampère VPS
• tableau de bord de l'instance cloud
• volume de démarrage
• interface réseau virtuel
• IP publique
• Règles de sécurité/pare-feu
• direction d'accès série/console
• instance stop/start/reboot checks

Couche système d'exploitation

• Linux
• SSH
• accès shell
• registres du système
• contrôle des processus
• Contrôles de stockage
• Contrôle des pare-feu
• commandes de démarrage de service

Calque de service dédiée

• serveur de service hébergé
• Extension Direction du serveur Loader
• serveur de service hébergé
• ExtensionRuntime
• .NET temps d'exécution
• fichiers de configuration du serveur
• sortie des journaux et consoles

Couche du contenant

• Coq
• sélection de plate-forme/architecture
• compatibilité avec l'image
• comportement ARM vs amd64
• container logs
• montures de volume

Construction prévue

La construction prévue était un VPS ARM stable utilisé pour accueillir de petits services dédiés.

Un environnement fini devrait soutenir:

• Accès SSH
• fichiers de service dédiés persistants
• commandes de démarrage prévisibles
• ports publics accessibles
• sauvegardes
• journaux
• processus de redémarrage
• binaires/images compatibles avec l'architecture
• étapes de récupération claires lorsque l'instance échoue

La configuration n'a pas besoin d'être de niveau entreprise. Elle doit être compréhensible et récupérable.

Les principales catégories de problèmes

La plupart des questions relèvent de l'un de ces groupes :

1. Cloud/provider issue
2. Instance boot issue
3. Network/security rule issue
4. SSH/authentication issue
5. OS/runtime issue
6. Architecture compatibility issue
7. Dedicated service config issue
8. Docker/container issue

Traiter chaque défaillance comme le serveur est cassé.

La bonne question est la suivante :

Which layer is failing?

Contrôles par l'État de l'instance

La première étape consiste à vérifier l'état de l'instance dans le tableau de bord du cloud.

États importants:

running
stopped
stopping
starting
terminated
unavailable

Si l'instance est arrêtée, SSH échouera même si les fichiers existent encore.

Si l'instance est en cours mais inaccessible, le problème peut être :

• problème de démarrage
• règle du pare-feu
• problème de propriété intellectuelle publique
• Problème de service SSH
• Défaut de niveau OS
• problème d'interface réseau

Si l'instance est terminée, la question suivante est de savoir si le volume de démarrage existe encore.

Contrôles du volume de démarrage

Une instance arrêtée ou non disponible ne signifie pas toujours que les données ont disparu.

Le volume de démarrage peut encore exister.

Le chemin de récupération peut être:

check boot volume
attach boot volume to another instance if needed
mount it
recover service data files/configs
copy backups
rebuild server

Pour les services spécialisés, les données les plus importantes sont généralement:

• fichiers de données de service
• fichiers de configuration
• fichiers d'extension
• fichiers whitelist/ops/admin
• scripts de service
• archives de sauvegarde

L'instance de calcul est remplaçable. Les données de service sont l'actif.

L'échec de la SSH ne signifie pas une seule chose

SSH peut échouer pour de nombreuses raisons.

Causes possibles:

• instance est désactivée
• changement de propriété intellectuelle publique
• règles de sécurité bloque port 22
• OS pare-feu bloque SSH
• Démon SSH ne fonctionne pas
• le disque est plein
• CPU/RAM épuisé
• mauvais nom d'utilisateur
• Mauvaise clé
• problème d'itinéraire réseau
• problème du côté du fournisseur
• défaillance du démarrage

Un bon ordre de contrôle est:

instance state
public IP
security rules
ping/reachability if allowed
SSH port test
serial/console output
boot logs

Ne présumez pas que la clé SSH est incorrecte tant que la couche d'infrastructure n'est pas cochée.

Règles de propriété intellectuelle et de sécurité publiques

Pour les services dédiés, deux types de ports comptent:

management port
dedicated service ports

Gestion :

22/tcp → SSH

exemples de services:

hosted service → TCP port depending on server config
hosted service  → TCP port depending on server config

La liste de sécurité du cloud/firewall doit permettre le trafic entrant prévu.

Le pare-feu Linux doit également l'autoriser si configuré.

Un port peut être ouvert dans le panneau cloud mais bloqué dans le système d'exploitation, ou ouvert dans le système d'exploitation, mais bloqué par les règles du réseau cloud.

Les deux couches de matière.

Vérification des services locaux d'écoute

Avant de blâmer le pare-feu cloud, vérifiez si le service écoute localement.

Exemple :

ss -tulpn

ou:

netstat -tulpn

Cela vous indique si le service dédié ou le démon SSH est réellement à l'écoute.

Si le service n'écoute pas localement, les règles du pare-feu public n'aideront pas.

Vérification des journaux

Les journaux sont le moyen le plus rapide pour arrêter de deviner.

Contrôles utiles:

journalctl -xe

dmesg | tail -100

df -h

free -h

ps aux | grep java

ps aux | grep ExtensionRuntime

Pour Docker:

docker ps -a

docker logs --tail 100 <container-name>

Pour un service dédié, vérifiez également le propre dossier journal du serveur.

Compatibilité ARM contre x86

L'hébergement VPS ARM présente une différence majeure par rapport à l'hébergement normal x86:

not every binary or Docker image supports ARM

Un échec commun ressemble à:

exec format error

Cela signifie généralement que le binaire à l'intérieur du conteneur ou de l'outil téléchargé est pour la mauvaise architecture CPU.

Exemple :

amd64 binary running on arm64 server

La correction doit être utilisée:

• binaire compatible ARM
• image Docker multi-arch
• sélection correcte de la plateforme
• émulation si acceptable
• méthode d'installation différente
• paquet serveur natif si possible

Problèmes d'architecture Docker

Docker ne fait pas disparaître les problèmes d'architecture par magie.

Si une image Docker contient des binaires x86 et que l'hôte est ARM, elle peut échouer.

Erreur typique & #160;:

exec /entrypoint.sh: exec format error

ou:

cannot execute binary file

Contrôles utiles:

uname -m

docker image inspect <image-name>

docker run --rm <image-name> uname -m

Si l'hôte affiche :

aarch64

alors c'est ARM64.

Le conteneur/image doit supporter ARM64 sauf si l'émulation est configurée.

Utilisation des images amd64 sur ARM

Parfois, une image amd64 peut être forcée avec :

docker run --platform linux/amd64 ...

Mais cela nécessite généralement un support d'émulation et peut être plus lent ou moins fiable.

Il peut être utile pour les tests, mais il n'est pas toujours la solution la plus propre à long terme.

Pour les services dédiés, la performance et la stabilité.

Préférez une configuration compatible ARM native lorsque c'est possible.

Questions relatives à la gestion des risques et à la gestion des risques

Certains workflows de service dédiés dépendent de SteamCMD.

SteamCMD et quelques binaires de serveur dédiés peuvent supposer x86/x86_64.

Sur les serveurs ARM, cela peut créer des problèmes :

• Mauvaise adéquation de l'architecture binaire de SteamCMD
• service dédié binaire non disponible pour ARM
• L'image Docker utilise uniquement amd64
• émulation nécessaire
• bibliothèques manquantes
• Le script de démarrage échoue avant l'exécution du service

La leçon importante:

The VPS can be strong enough, but the software must support its CPU architecture.

Prolongation Problèmes de durée d'exécution

Les services hébergés avec une configuration ExtensionRuntime avaient ses propres problèmes d'exécution.

Catégories de problèmes possibles:

• Désaccord d'exécution de .NET
• bibliothèque native manquante
• hypothèses du script de lancement
• inadéquation de l'architecture
• problème de chemin de configuration du serveur
• erreur de construction d'extension
• dépendance manquante
• mauvais répertoire de travail

Une erreur d'exécution/de bibliothèque native est différente d'une erreur de code d'extension.

Par exemple:

FNA3D.so missing

n'est pas le même type de problème que:

C# override method signature is wrong

Séparer les erreurs d'environnement/d'exécution des erreurs de compilation d'extension.

ExtensionRuntime Build Direction

Une commande de construction d'extension personnalisée avait une forme comme:

dotnet ExtensionRuntime.dll -build SurfaceProtection -tmlsavedirectory /home/opc/tml-arm/ExtensionRuntime

Les problèmes peuvent venir de:

• mauvais répertoire
• mauvaise exécution de .NET
• bibliothèque native manquante
• mauvaise version ExtensionRuntime
• source d'extension cassée
• Inadéquation de l'API
• mauvaise signature de l'option

Une erreur de construction doit être lue littéralement en premier. Le compilateur pointe souvent directement sur le fichier et la ligne défaillants.

Direction du serveur hébergé

Le service hébergé sur ARM est souvent plus facile que d'autres services dédiés parce que Java prend bien en charge ARM lorsque l'exécution Java correcte est installée.

Principaux contrôles:

• corriger la version Java
• serveur jar existe
• assez de RAM
• corriger le port
• EULA accepté
• extensions correspondent à la version du serveur
• ExtensionLes versions Loader/loader correspondent
• service commence dans un répertoire correct
• pare-feu permet le port de service
• des sauvegardes existent

Les problèmes de service hébergés sont plus souvent des problèmes de configuration/extension/version que des problèmes d'architecture CPU, même si les extensions natives ou les wrappers peuvent encore compter.

Service dédié Conservation des données

Pour l'hébergement de services, les annuaires importants doivent être faciles à identifier.

Exemples:

/srv/dedicated-service/

/home/opc/tml-arm/ExtensionRuntime/

ou quel que soit le répertoire:

• données persistantes
• extensions
• configs
• journaux
• sauvegardes
• scripts du serveur

Une bonne mise en page du serveur facilite la récupération.

Si le VPS devient indisponible, vous devez savoir exactement ce qui doit être copié à partir du volume de démarrage.

Direction de sauvegarde

Les sauvegardes comptent plus que la taille de l'instance.

Un plan de sauvegarde de base devrait comprendre:

service data files
config files
extension list
service scripts
environment files without public sharing
important logs if needed

Les sauvegardes doivent être stockées en dehors de l'instance si les données du service sont importantes.

Au minimum:

local copy
separate volume
object storage
another server

Un VPS gratuit ou bon marché peut disparaître, échouer ou être arrêté. Les données ne devraient pas exister en un seul endroit.

Limites pour les fournisseurs et risque plus élevé

L'hébergement en nuage gratuit ou peu coûteux peut être utile, mais il comporte des risques :

• pénuries de capacités
• remise en état des ressources
• restrictions de compte
• messages de facturation/de type gratuit non clairs
• instances arrêtées
• volume de démarrage encore présent mais calcul indisponible
• changements dans la disponibilité des régions
• création accidentelle de ressources rémunérées

Pour une note de portefeuille, le cadre important ne se plaint pas du fournisseur.

Le cadre utile est:

designing recovery and verification steps for a low-cost ARM VPS environment

Cela montre la maturité de l'infrastructure.

Éviter les ressources payées par accident

Lors de l'utilisation des ressources de style libre de cloud, consultez :

• forme de l'instance
• OCPU/RAM
• Taille du volume de démarrage
• volumes de blocs
• type de propriété intellectuelle publique
• balanceurs de charge
• instantanés / sauvegardes
• stockage des objets
• bande passante sortante
• limites régionales

La règle pratique:

Know which resources cost money before creating them.

Pour les petits services spécialisés, évitez d'ajouter des services gérés aléatoirement, sauf si nécessaire.

Console série / Console de récupération Direction

Si SSH échoue mais que l'instance est toujours en cours d'exécution, l'accès à la console peut aider.

Une console série/récupération peut révéler:

• Erreurs de démarrage
• problèmes de disque complet
• services défaillants
• erreurs de configuration du réseau
• invites de connexion
• messages du noyau
• processus de démarrage bloqué

Ceci est utile car SSH dépend du démarrage de l'OS assez loin et le travail en réseau.

L'accès à la console vérifie le serveur plus près du niveau de la machine.

Problèmes de disque complet

Un disque complet peut casser beaucoup de choses:

• Connexion SSH
• le paquet installe
• service dédié économise
• journaux
• Coq
• constructions d'extension
• sauvegardes de données de service

Vérification :

df -h

Docker peut consommer de l'espace avec de vieilles images/conteneurs.

Vérification :

docker system df

Pour les services dédiés, les sauvegardes de données de service et les journaux peuvent croître au fil du temps.

Pression RAM et processeur

Les services dédiés peuvent geler ou s'écraser si les ressources sont épuisées.

Vérification :

free -h

top

uptime

Pour le service Java / hôte, les drapeaux de mémoire comptent.

Pour ExtensionRuntime / service hébergé, le compte de prolongation et l'activité de données de service comptent.

Pour Docker, les limites de contenants peuvent aider à empêcher un service de tout consommer.

Pare-feu et essais portuaires

Un service nécessite trois choses :

process listening
OS firewall allows it
cloud firewall allows it

Séquence d'essai:

check local listening
check OS firewall
check cloud security rules
test from outside
check server logs during test

Un contrôle de port seul n'est pas suffisant. Les journaux du serveur confirment si le trafic a atteint l'application.

Gestion des services

Les services dédiés ne devraient pas reposer uniquement sur une session SSH interactive.

Meilleures options:

• service systémique
• écran/tmux pour les essais manuels
• Docker conteneur avec politique de redémarrage
• script de démarrage avec journaux
• commandes de démarrage/arrêt documentées

Pour les serveurs à long terme, un gestionnaire de services est plus propre que le démarrage manuel du processus après chaque redémarrage.

Erreurs fréquentes

En supposant que plus de ressources signifie moins de problèmes

Les instances ARM peuvent avoir un bon CPU/RAM, mais la compatibilité reste importante.

Traiter Docker comme Architecture-Neutral

Les images Docker contiennent toujours des binaires spécifiques à l'architecture.

Service de débogage Config avant de vérifier le pare-feu

Si aucune connexion n'arrive au serveur, vérifiez d'abord le chemin réseau.

Penser que l'échec de SSH signifie que les données sont perdues

Le volume de démarrage peut encore être récupérable.

Tout tourner manuellement

Les commandes manuelles sont bonnes pour la configuration. L'hébergement stable nécessite des flux de travail répétables start/restart/log.

Pas de sauvegarde des données persistantes

les fichiers de données de service sont la partie la plus précieuse du service dédié.

Flux de dépannage pratique

Un flux utile:

1. Is the cloud instance running?
2. Does it still have the expected public IP?
3. Are cloud security rules correct?
4. Does SSH port respond?
5. If SSH fails, check console/boot logs.
6. If SSH works, check disk/RAM/CPU.
7. Check whether the service endpoint is listening.
8. Check service logs.
9. Check architecture compatibility.
10. Test from outside.
11. Backup important data before risky changes.

Cela évite de sauter au hasard entre des correctifs indépendants.

Vérifications pratiques en une seule ligne

Architecture :

uname -m

Disque & #160;:

df -h

Mémoire :

free -h

Ports d'écoute :

ss -tulpn

Récipients Docker:

docker ps -a

Registres récents du système:

journalctl -xe --no-pager | tail -100

Registres Docker :

docker logs --tail 100 <container-name>

Trouver de grands fichiers & #160;:

du -h /home /srv /var 2>/dev/null | sort -h | tail -50

Vérifiez Java & #160;:

java -version

Vérifier le processus fil / service:

ps aux | grep -E 'java|hosted service|ExtensionRuntime'

Décisions pratiques

Préférez l'ARM natif si possible

Les constructions ARM autochtones sont plus propres que de forcer l'émulation amd64.

Conserver les données persistantes sauvegardées

Le VPS peut être reconstruit. Les données de service ne doivent pas être jetables.

Séparer les problèmes du fournisseur des problèmes du serveur

L'état de l'instance Cloud, le volume de démarrage et les règles réseau sont différents calques.

Vérifier les journaux avant de changer beaucoup de choses

Les journaux réduisent généralement le problème plus rapidement que de deviner.

Commandes de démarrage de document

Si le serveur a besoin d'une commande spéciale, écrivez-la.

Utiliser les gestionnaires de services

Un redémarrage ne devrait pas nécessiter de se souvenir d'une longue commande manuelle.

Ce qu'une configuration terminée devrait montrer

Une configuration de service dédié ARM VPS solide devrait montrer:

• forme et architecture de l'instance documentées
• mise en page du répertoire du serveur
• commande de démarrage de service dédiée
• gestionnaire de services ou commande Docker run
• pare-feu/liste des règles de sécurité
• chemin de sauvegarde
• Plan de redressement
• notes de compatibilité architecture
• emplacement des journaux
• instructions de redémarrage
• emplacement des fichiers de données de service
• limitations connues

Preuves à retenir

Voici quelques éléments de preuve utiles à cette note :

• Sortie uname -m
• Erreur d'architecture Docker
• Conteneur compatible avec ARM ou fonctionnement natif réussi
• capture d'écran d'état d'une instance de nuage avec des données sensibles cachées
• screenshot de la règle de sécurité
• ss -tulpn montrant le port de service
• console de service dédiée en ligne
• connexion externe réussie
• ExtensionRuntime build sortie
• liste des répertoires de sauvegarde
• liste de contrôle pour le recouvrement

Hypothèses techniques

Cette note suppose que le serveur est un VPS ARM64 utilisé pour un petit hébergement dédié.

Il suppose que l'opérateur a accès à SSH lorsque l'instance est saine.

Il suppose que le serveur peut être utilisé pour des services dédiés, ExtensionRuntime, ou des petits services similaires.

Il suppose également que le comportement du fournisseur de cloud, les limites de free-tier et la disponibilité d'instances devraient être traités comme des risques opérationnels plutôt que ignorés.

Principaux risques

• Mauvaise architecture CPU pour l'image Docker
• bibliothèques d'exécution natives manquantes
• Pas de sauvegarde
• volume de démarrage existe mais l'instance n'est pas disponible
• règles de sécurité en nuage bloquer les ports de service
• OS pare-feu bloquant le trafic
• SSH non disponible car l'instance n'a pas démarré
• disque plein de logs/backups/Docker images
• service démarré manuellement et perdu après le redémarrage
• Erreurs d'extension/de construction confondues avec les erreurs d'infrastructure
• ports publics ouverts sans comprendre ce qui les écoute

État actuel

Cette note représente le dépannage et les leçons d'exploitation de l'utilisation d'un VPS ARM pour l'hébergement de service dédié.

La valeur la plus forte est l'approche de débogage en couches:

cloud layer
network layer
OS layer
runtime layer
container layer
dedicated service layer
extension/plugin layer

Chaque couche peut échouer indépendamment.

Ce que la présente note ne prétend pas

Cette note ne prétend pas que l'hébergement ARM VPS est toujours meilleur que l'hébergement x86.

Il ne prétend pas que chaque service dédié fonctionne bien sur ARM.

Il ne prétend pas que les ressources de niveau libre du cloud sont suffisamment fiables pour chaque charge de production.

Il documente le dépannage pratique pour l'hébergement de service dédié ARM à faible coût où la compatibilité, la récupération et les sauvegardes comptent.

À emporter pratique

La leçon utile est:

Sur un VPS ARM, le serveur ne fonctionne pas.

Cela pourrait être :

provider state
boot failure
SSH/network issue
firewall rule
wrong architecture
missing runtime
Docker mismatch
service config error
extension build error
resource exhaustion

La correction est de déboguer par couche, de préserver les fichiers de données de service, et de garder le déploiement récupérable.