OVH ex5 est un serveur dédié de la gamme Advance d'OVHcloud, conçu pour absorber des charges de travail professionnelles exigeantes. Sa configuration correcte, depuis le choix des protocoles jusqu'au durcissement de la sécurité, conditionne directement les performances et la résilience de l'infrastructure. Ce guide couvre l'essentiel pour passer d'une installation brute à un environnement production-ready.
L'OVH ex5 s'est imposé comme une référence dans les gammes de serveurs dédiés d'entrée-milieu de gamme pour les entreprises qui ne peuvent pas se permettre de sous-dimensionner leur infrastructure, mais qui refusent de payer pour de la capacité inutilisée. Avec son processeur Intel Xeon E-2386G (6 cœurs, 12 threads, jusqu'à 4,7 GHz en boost), ses 64 Go de RAM DDR4 ECC et ses options de stockage NVMe, il couvre un spectre large : hébergement web haute densité, bases de données transactionnelles, environnements de développement et de staging, ou encore VPN d'entreprise.
Mais un serveur livré par OVHcloud, c'est une ardoise quasi-vierge. L'OS est installé, le réseau est actif, et c'est à peu près tout. Ce que vous en faites ensuite, la façon dont vous configurez les protocoles, durcissez l'accès, et calibrez les performances, c'est ce qui sépare une infrastructure professionnelle d'un serveur qui tourne "à peu près".
Ce que vous allez apprendre
Ce guide détaille, dans l'ordre logique d'une mise en production, comment configurer un serveur OVH ex5 : protocoles réseau et de communication, configuration initiale post-installation, sécurisation de l'environnement, optimisation des performances, et diagnostic des problèmes courants.
Étape 1 : Comprendre l'architecture et les protocoles disponibles sur OVH ex5
Avant de toucher à la moindre configuration, comprendre ce que le serveur OVH ex5 expose nativement et quels protocoles sont pertinents pour un usage professionnel est une étape non négociable.
Protocoles réseau de base : IPv4, IPv6 et le VLAN OVHcloud
L'OVH ex5 est livré avec une adresse IPv4 publique dédiée et une adresse IPv6 par défaut. OVHcloud propose également le service vRack (Virtual Rack), qui permet de connecter plusieurs serveurs dédiés dans un réseau privé isolé via des VLANs 802.1Q. Pour une architecture multi-serveurs (web, base de données, cache), le vRack est la bonne approche : les échanges entre serveurs passent par un réseau privé à faible latence, sans transiter par l'internet public.
La configuration réseau de base sous Linux (Debian/Ubuntu) passe par le fichier /etc/network/interfaces ou, sur les distributions plus récentes, via Netplan (/etc/netplan/*.yaml). OVHcloud fournit des templates dans son manager, mais les adapter à une topologie custom reste à la charge de l'administrateur.
Protocoles applicatifs : HTTP/2, HTTPS, FTP/SFTP, SMTP
Le choix des protocoles applicatifs dépend directement de l'usage. Pour un hébergement web, HTTP/2 avec TLS 1.3 est le standard actuel. HTTP/2 réduit la latence par multiplexage des requêtes, et TLS 1.3 élimine un aller-retour dans la négociation cryptographique par rapport à TLS 1.2.
Le FTP non chiffré n'a plus sa place en production. Utilisez SFTP (SSH File Transfer Protocol) ou FTPS (FTP over SSL). SFTP est préférable car il s'appuie sur le démon SSH déjà présent sur le serveur, sans ouvrir de ports supplémentaires.
Pour les serveurs qui gèrent de l'envoi d'e-mails transactionnels, SMTP avec STARTTLS ou SMTPS sur le port 465 est le minimum. OVHcloud bloque par défaut le port 25 sortant sur ses serveurs dédiés pour limiter le spam. Vous devrez passer par un relais SMTP externe (Mailgun, Brevo, Postmark) ou demander le déblocage via le manager OVH.
Le port 25 sortant est bloqué par défaut sur les serveurs dédiés OVHcloud. Si votre application doit envoyer des e-mails directement, anticipez cette contrainte dès la phase d’architecture et prévoyez un relais SMTP tiers ou une demande de déblocage via le support OVH.
SSH et les protocoles d'administration à distance
SSH sur le port 22 est le vecteur d'accès principal à votre serveur OVH ex5. C'est aussi la première cible des scanners automatisés. La configuration par défaut d'OpenSSH est fonctionnelle mais loin d'être durcie. Ce point sera approfondi dans la section sécurité, mais retenez dès maintenant : changer le port par défaut, désactiver l'authentification par mot de passe et imposer les clés SSH sont les trois premières actions à effectuer après la livraison du serveur.
Étape 2 : Configuration initiale du serveur OVH ex5
La livraison du serveur se fait via le manager OVHcloud (interface web). L'installation de l'OS s'effectue depuis cet espace client, avec un choix entre plusieurs distributions Linux (Debian, Ubuntu, AlmaLinux, Rocky Linux) et Windows Server.
Installation de l'OS et accès initial
Depuis le manager, sélectionnez votre serveur dans la section "Bare Metal Cloud", puis "Serveurs dédiés". L'onglet "Système d'exploitation" permet de lancer une réinstallation avec les templates OVH ou une image personnalisée. Pour un usage professionnel, Debian 12 ou Ubuntu 22.04 LTS sont les choix les plus courants, avec un excellent support logiciel et une documentation abondante.
Après installation, OVH envoie les identifiants par e-mail. La première connexion se fait en SSH avec l'utilisateur root ou un compte administrateur selon le template. Changez immédiatement le mot de passe root et créez un compte utilisateur dédié avec les droits sudo.
Configuration réseau post-installation
Vérifiez la configuration réseau avec ip addr et ip route. Assurez-vous que la passerelle par défaut est correcte (généralement la première IP du bloc réseau OVH). Si vous utilisez le vRack, une interface secondaire doit être configurée pour le réseau privé, sans passerelle par défaut sur cette interface pour éviter les conflits de routage.
Le serveur DNS recommandé par OVHcloud est 213.186.33.99, mais pour un usage professionnel, configurer des résolveurs redondants (par exemple 1.1.1.1 de Cloudflare en complément) améliore la résilience.
Mise à jour système et installation des paquets de base
apt update && apt upgrade -y
apt install -y curl wget git ufw fail2ban unattended-upgrades
Activez les mises à jour automatiques de sécurité via unattended-upgrades. Sur un serveur de production, les mises à jour mineures de sécurité doivent s'appliquer sans intervention manuelle. Les mises à jour majeures, en revanche, doivent être testées en staging avant déploiement.
Étape 3 : Sécuriser votre environnement OVH ex5
La sécurité d'un serveur dédié est entièrement à la charge de l'exploitant. OVHcloud fournit une protection anti-DDoS en bordure de réseau (VAC, pour "Vacuum Anti-DDoS"), mais la sécurité applicative et système reste votre responsabilité.
Durcissement SSH et gestion des accès
Éditez /etc/ssh/sshd_config pour appliquer les paramètres suivants :
Port 2222(ou tout port non standard entre 1024 et 65535)PermitRootLogin noPasswordAuthentication noPubkeyAuthentication yesMaxAuthTries 3
Générez une paire de clés SSH sur votre poste client (ssh-keygen -t ed25519), copiez la clé publique sur le serveur (ssh-copy-id), puis redémarrez le service SSH. Testez la connexion avec la nouvelle configuration avant de fermer votre session active.
Pare-feu : UFW et le firewall OVHcloud
UFW (Uncomplicated Firewall) est la couche pare-feu au niveau du système d'exploitation. Configurez-le pour n'autoriser que les ports strictement nécessaires :
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp # SSH sur nouveau port
ufw allow 80/tcp # HTTP
ufw allow 443/tcp # HTTPS
ufw enable
OVHcloud propose également un pare-feu réseau configurable depuis le manager, en amont du serveur. Ce pare-feu matériel peut bloquer les attaques avant même qu'elles atteignent votre OS. Combiner les deux niveaux de protection est la bonne pratique.
Fail2ban complète le dispositif en bannissant automatiquement les IP qui génèrent trop d'échecs d'authentification. Configurez-le pour surveiller SSH, mais aussi Nginx ou Apache si vous hébergez des services web.
Le pare-feu réseau OVHcloud et UFW opèrent sur deux couches distinctes. Le premier filtre le trafic avant qu’il n’atteigne votre serveur, le second contrôle ce qui entre dans l’OS. Activer les deux en parallèle n’entraîne aucun conflit et renforce significativement la surface de protection.
Gestion des certificats TLS et HTTPS
Pour les services web, Let's Encrypt via Certbot reste la solution la plus simple et gratuite pour obtenir des certificats TLS valides. Sur Nginx :
apt install certbot python3-certbot-nginx
certbot --nginx -d votre-domaine.com
Le renouvellement automatique est configuré par défaut via un timer systemd. Vérifiez qu'il fonctionne avec systemctl status certbot.timer.
Étape 4 : Optimisation des performances du serveur OVH ex5
Un serveur correctement dimensionné mais mal configuré peut délivrer des performances bien en dessous de son potentiel. L'optimisation passe par plusieurs niveaux : système, réseau, et applicatif.

Paramétrage du noyau Linux pour les charges réseau
Pour les serveurs à fort trafic réseau (proxies inverses, serveurs web haute densité), ajustez les paramètres du noyau via /etc/sysctl.conf :
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
net.core.netdev_max_backlog = 65536
vm.swappiness = 10
La valeur vm.swappiness = 10 réduit l'utilisation du swap, ce qui améliore les temps de réponse sur les serveurs disposant de suffisamment de RAM (ce qui est le cas avec 64 Go).
Optimisation du stockage NVMe
L'OVH ex5 peut être configuré avec des disques NVMe, dont les performances d'entrée-sortie dépassent largement les SSD SATA. Pour exploiter pleinement ces disques, vérifiez que le scheduler d'I/O utilisé est none ou mq-deadline (adapté aux NVMe) plutôt que cfq ou deadline hérités des disques rotatifs :
cat /sys/block/nvme0n1/queue/scheduler
Pour les bases de données comme PostgreSQL ou MySQL/MariaDB, configurez les paramètres de cache en mémoire en cohérence avec la RAM disponible. Sur 64 Go de RAM, shared_buffers de PostgreSQL peut monter à 16 Go, et effective_cache_size à 48 Go.
Sur un serveur OVH ex5 avec NVMe, le gain de performance le plus rapide à obtenir est souvent côté base de données : augmenter les buffers en mémoire réduit les accès disque et peut diviser par 2 ou 3 les temps de requête sur des charges transactionnelles moyennes.
Monitoring et métriques de performance
Sans monitoring, l'optimisation est aveugle. Déployez au minimum un agent Netdata ou Prometheus + Grafana pour suivre en temps réel l'utilisation CPU, RAM, I/O disque et bande passante réseau. OVHcloud propose aussi son propre service de monitoring basique depuis le manager, mais il manque de granularité pour un usage professionnel.
Pourquoi configurer le vRack plutôt qu'utiliser l'IP publique pour les communications inter-serveurs ?
Le vRack isole le trafic interne dans un réseau privé dédié, ce qui élimine l'exposition sur l'internet public, réduit la latence entre serveurs du même datacenter, et supprime la facturation de la bande passante pour les échanges internes. Pour toute architecture multi-serveurs, c'est la seule approche viable en production.
Au-delà de la sécurité, les performances sont mesurables : la latence entre deux serveurs OVH connectés via vRack dans le même datacenter descend en dessous de la milliseconde, contre plusieurs dizaines de millisecondes via l'internet public.
Étape 5 : Dépannage et résolution des problèmes courants
Même avec une configuration soignée, certains problèmes reviennent régulièrement sur les serveurs OVH ex5.
Problèmes de connectivité réseau
Si le serveur devient inaccessible après une modification réseau, le KVM over IP (ou IPMI) d'OVHcloud permet d'accéder à la console du serveur directement depuis le manager, sans passer par le réseau de production. C'est le filet de sécurité indispensable avant toute modification de la configuration réseau ou SSH.
Le mode rescue d'OVHcloud est une autre ressource précieuse : il démarre le serveur sur un OS temporaire en RAM, permettant de monter les disques de production et de corriger une configuration défaillante (fichier /etc/network/interfaces corrompu, règles UFW trop restrictives, etc.).
Saturation des ressources et identification des processus gourmands
top, htop, iotop et nethogs sont les outils de diagnostic de base. Pour une analyse plus fine des goulets d'étranglement I/O, iostat (paquet sysstat) fournit des métriques détaillées par disque. Un iowait CPU élevé (au-dessus de 20-30%) signale généralement un problème de configuration du stockage ou une requête SQL non optimisée.
Quel est le délai de support OVHcloud pour les serveurs dédiés ?
Le support OVHcloud pour les serveurs dédiés varie selon le niveau de service souscrit. En support standard (inclus), les incidents matériels sont traités sous 4 heures en moyenne pour les interventions datacenter, mais le support technique applicatif est limité. Les offres Business et Enterprise Support réduisent les délais et ouvrent l'accès à un support téléphonique dédié.
Pour les problèmes matériels (disque défaillant, RAM en erreur), OVHcloud dispose de techniciens sur site dans ses datacenters et peut remplacer un composant défaillant sans frais supplémentaires dans le cadre de la garantie hardware incluse avec les serveurs dédiés.
Les incidents réseau et les maintenances planifiées sont communiqués via le status.ovhcloud.com et par e-mail. S'abonner aux notifications pour votre datacenter est une bonne habitude à prendre dès la mise en service.
- Performances prévisibles grâce aux ressources dédiées (pas de voisins bruyants)
- Protection anti-DDoS VAC incluse sans surcoût
- vRack pour architectures multi-serveurs sécurisées
- Mode rescue et KVM over IP pour le dépannage à distance
- Remplacement matériel inclus dans la garantie
- Administration système entièrement à la charge de l’exploitant
- Port 25 bloqué par défaut, contraignant pour les serveurs mail
- Support applicatif limité en offre standard
- Pas de snapshots natifs sur les serveurs dédiés (contrairement aux VPS)
Récapitulatif des étapes clés
- Identifier les protocoles nécessaires à votre usage avant de commencer (HTTP/2, SFTP, SMTP via relais, SSH)
- Installer l'OS depuis le manager OVHcloud et effectuer la mise à jour système immédiatement
- Durcir SSH (port non standard, clés uniquement, root désactivé) et activer UFW + le pare-feu réseau OVHcloud
- Configurer TLS 1.3 et obtenir des certificats Let's Encrypt pour tous les services web exposés
- Ajuster les paramètres noyau et les buffers applicatifs en fonction de la charge attendue
- Déployer un outil de monitoring avant la mise en production, pas après
- Tester le mode rescue et l'accès KVM over IP avant d'en avoir besoin en urgence





