Gestion du reboot de vos serveurs avec la fonctionnalité OVHcloud Link Aggregation

Objectif

Ce guide a pour but de vous accompagner pour déployer tous les composants et services nécessaires au bon redémarrage de vos solutions OVHcloud en environnement entièrement privé.
Profitez d'une infrastructure privée sans avoir modifié la configuration par défaut de vos serveurs dédiés OVHcloud.

Les serveurs dédiés OVHcloud vous permettent de configurer/déclarer vos propres réseaux.
Chaque serveur est muni au minimum de 2 interfaces réseaux, fonctionnant en réalité en liens agrégés et assurant la redondance en cas de panne.
Vous avez donc la possiblité d'utiliser/déclarer vos réseaux publics et privés en passant par notre solution vRack.

Nous allons présenter le cas de serveur(s) dédié(s) configuré(s) en mode OLA, c'est-à-dire possédant uniquement des réseaux privés. Ce choix propose à votre infrastructure la meilleure isolation/protection possible pour votre service hébergé.
La seule différence majeure notable est que les réseaux privés n'ont donc pas accès à tout ce qui n'appartient pas à votre infrastructure.
Par conséquent, un serveur isolé de par son réseau privé empêche le mecanisme de démarrage. C'est à dire que lorsque les systèmes sont démarrés via le méthode Netboot (Network Boot), ces derniers s'appuient sur le réseau interne d'OVHcloud et ses services mutualisés.

Présentation rapide d'un démarrage en Netboot

Un composant majeur existe en 2 versions :

• PXE : utilisant un environnement standardisé client/serveur, basé sur les protocoles BOOTP/DHCP/TFTP, afin de permettre un démarrage/déploiement via le réseau du système client.
  
• iPXE : utilisant un environnement standardisé client/serveur plus évolué, basé sur les protocoles HTTP, iSCSI, AoE, FCoE, Wi-Fi afin de permettre un démarrage/déploiement via le réseau du système client.

Présentation rapide d'un démarrage en Netboot chez OVHcloud

Liste des composants intervenants lors du démarrage :

• Un serveur DHCP : attribue une configuration réseau (bail avec adresse IP) pour une machine cliente qui tente de démarrer.
• Un service TFTP : ressources disponibles à travers le réseau et qui seront interrogées/requêtées par PXE et iXPE.
• La solution rEFInd, sous forme de BootLoader, a été retenue car parfaitement adaptée. Elle permettra la recherche de secteurs d'amorçage des machines clientes : disque local, USB, etc...

Voici un schéma (logique) de démarrage Netboot :

Prérequis

• Posséder au moins un serveur dédié ayant un système d'exploitation déjà installé.
• Un serveur dédié supplémentaire avec les interfaces réseau configurées par défaut, à savoir un accès au réseau public et privé. Ce serveur hébergera tous les services (DHCP et TFTP). Le système d'exploitation sera celui de votre choix.
• Avoir toutes les interfaces réseau de ce serveur en mode privé, ce qui sous-entend que vous avez préalablement configuré notre fonctionnalité OLA.
  

Accès à l'espace client OVHcloud

• Lien direct : Serveurs dédiés
• Pour accéder à vos services : Bare Metal Cloud > Serveurs dédiés > Sélectionnez votre serveur

Sélectionnez votre serveur et vérifiez son éligibilité à OLA: OVHcloud Link Aggregation dans l'onglet Interfaces réseau.

En pratique

Déployer vos services DHCP et TFTP

1. Installez les packages pour les services DHCP/TFTP.
2. Effectuez la configuration basique pour chaque service.
3. Mettez en marche votre serveur.

Ci-dessous un exemple d'infrastructure privée basique (schéma layer 2) :

Exemple :

• Services hébergés/mutualisés sur Node 0.
• Une seule machine cliente Node 1 avec OLA actif.

Le service DHCP

Retrouvez ci-dessous un exemple de fichier de configuration pour votre service DHCP.
Selon votre distribution, l'arborescence peut être différente (kea-dhcp4.conf).

En règle générale, il suffit de :

• déclarer une interface réseau pour l'écoute (en attente de requêtes) ;
• renseigner un fichier de configuration principale (à titre d'exemple, cf fichier ci-dessous).

{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "eth1" ]
    },

    "control-socket": {
        "socket-type": "unix",
        "socket-name": "kea4-ctrl-socket"
    },

    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600
    },

    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },

    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 3600,

    "client-classes": [
        {
            "name": "iPXE script",
            "test": "option[user-class].exists and substring(option[user-class].hex,0,4) == 'iPXE' and option[client-system].hex == 0x0007", # Détermine le type d'architecture, ici 64bits
            "next-server": "192.168.1.1", # Détermine l'IP de votre serveur tftp
            "boot-file-name": "refind.pxe", # Détermine le script appelé par le binaire iPXE
        },
        {
            "name": "PXE UEFI",
            "test": "not option[user-class].exists and option[client-system].hex == 0x0007", # Détermine le type d'architecture, ici 64bits
            "next-server": "192.168.1.1", # Détermine l'IP de votre serveur tftp
            "boot-file-name": "ipxe.efi" # Détermine le binaire iPXE
        },
    ],

    "subnet4": [
        {
            "id": 1,
            "subnet": "192.168.1.0/28",
            "pools": [ { "pool": "192.168.1.2 - 192.168.1.14" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "192.168.1.1"
                },
            ],
        }
    ],

    "loggers": [
    {
        "name": "kea-dhcp4",
        "output-options": [
            {
                "output": "stdout",
                "pattern": "%-5p %m\n",
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

Détails :

• réseau privé (ex: 192.168.1.0/28)
• subnet_mask : 255.255.255.240
• broadcast_address : 192.168.1.15
• dns_servers : cf chapitre optionnel
• ntp_servers : cf chapitre optionnel
• default_router : 192.168.1.1
• next-server : 192.168.1.1
• host : nom machine cliente
• hardware ethernet : adresse matérielle (MAC) machine cliente
• server-name : hostname machine cliente

Le service TFTP

Selon votre distribution, il existe plusieurs paquets réalisant la fonction de serveur TFTP.
Par exemple : tftp-server, tftpd, tftpd-hpa ou encore atftpd.

Ce qu'il faut savoir :

• Ce service utilise le port 69 (UDP).
• Il est obligatoire de déclarer un répertoire « cible », correspondant à une arborescence locale qui sera utilisée pour la réception et le téléchargement des fichiers.

Exemple de configuration avec le logiciel tftpd-hpa :

# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="TFTP_server_address:69"
TFTP_OPTIONS="--secure"

Nous utiliserons comme exemple le chemin /srv/tftp, et y déposerons les fichiers nécessaires :

root@node_0:/srv/tftp# tree
.
|-- ipxe.efi
|-- refind.conf
|-- refind.pxe
`-- refind_x64.efi

Le bootloader rEFInd

• Contenu du fichier refind.pxe :

#!ipxe

echo Boot to local disk

iseq ${platform} efi && goto is_efi_x86_64 || goto end

:is_efi_x86_64
echo EFI boot mode

# Récuperer le fichier de configuration
imgfetch --name refind.conf tftp://${next-server}/refind.conf

# Charger le binaire rEFIND
imgfetch --name refind tftp://${next-server}/refind_x64.efi
chain refind

:end
echo Chain on hard drive failed
sleep 10
exit 1

• Contenu du fichier refind.conf :

Il s'agit d'intégrer les directives minimales pour une bonne intégration au SI d'OVHcloud.

timeout 1
default_selection 1
hideui hwtest
hideui hints
banner_scale noscale
textonly
scanfor internal
uefi_deep_legacy_scan
scan_delay 0

Mise en marche

Ci-dessous un aperçu de ce que l'on obtient à l'affichage lors d'un Netboot UEFI (par défaut) :
Correspond aux étapes 1 à 8.

Correspond au résultat des étapes 8 et 9.

Ci-dessus, nous avons le bootloader rEFInd chargé sur une machine avec un système debian installé.

Vous trouverez sur ce lien les ressources qui ont servi à élaborer nos tests et exemples présents tout au long de cette présentation. Ils pourront servir de template selon vos besoins.

Optionnel

Il est également recommandé de déployer les services DNS et NTP.

Ceux-ci ne sont pas nécessaires pour les phases de démarrage des systèmes, donc pas imposés dans cette procédure. Ils font néanmoins partie des services importants par la suite, principalement pour la stabilité de votre infrastructure.

Service DNS

Vous pouvez utiliser la table locale de chaque Node, à savoir le fichier /etc/hosts, ou bien utiliser un service tel que dnsmasq.

Service NTP

Il est fortement conseillé d'utiliser un service NTP, surtout si votre infrastructure comprend plusieurs machines.

• Liste des ports à autoriser dans votre firewall local (de la machine hébergeant les services) :
  • NTP port 123
  • DNS port 53

Aller plus loin

Comprendre et/ou personnaliser votre service DHCP.
Comprendre et/ou personnaliser votre service iPXE.
Comprendre et/ou personnaliser votre service rEFInd.
Comprendre ou découvrir NTP.
Comprendre ou découvrir Dnsmasq.

Échangez avec notre communauté d'utilisateurs.