Synology et secours à chaud

20 novembre 2021 Lionel IT

J'utilise plusieurs gros NAS Synology dont certains dans un data center. De fait pas facilement accessibles, même si chez Scaleway il existe un support de proximité ou l'on peut demander à deux heures du matin au technicien d'astreinte d'aller redémarrer une machine, débrancher un câble ou sortir un disque...

En pleine nuit je me suis retrouvé avec un RS2414RP+ injoignable. Moment d'angoisse assuré. Je demande donc au technicien de le redémarrer. Et s'il a bien démarré, c'est avec un disque en panne. C'est probablement ce redémarrage sauvage qui a provoqué cette panne sur un disque qui devait déjà être fatigué. Quant à savoir pourquoi ce NAS qui tourne depuis des années s'est planté, mystère, les logs étant peu loquaces

Sur ce NAS il y a 12 disques en RAID SHR répartis dans deux groupes de stockage. Chaque groupe utilise 5 disques (4 + 1 en parité) et sur l'ensemble je dispose de 2 disques de secours à chaud (hotspare).

Je pensais naïvement qu'en cas de panne, un des disques configurés en secours à chaud allait prendre automatiquement le relais comme cela se fait sur certains serveurs. Mais il n'en était rien. J'ai alors pensé que ce relais se ferait quand la longue vérification des volumes serait terminée, mais niet.

Le stress montant j'ai alors commencé à fouiller le net sans pour autant trouver l'information idoine. En fait la seule information trouvée étant l'explication d'un utilisateur à qui le support Synology aurait répondu que pour qu'un disque de secours prenne le relais, il faut retirer physiquement le disque du NAS. Peu pratique à distance, même si j'ai pensé un temps demander au technicien d'astreinte de le faire pour moi.

En parcourant les menus j'ai remarqué que l'on pouvait désactiver un disque et au fond d'un forum un utilisateur explique que c'est la procédure pour retirer un disque proprement. Je me suis donc dit que si le disque était désactivé logiquement, le disque de secours devrait prendre le relais. J'ai donc tenté, et c'est visiblement ce qu'il convient de faire car un de mes disques de secours a alors été affecté automatiquement à mon groupe de stockage et la reconstruction est en cours.

Synology a très certainement de bonnes raisons de faire ainsi, mais je trouve leur documentation un peu légère sur ce point et quelques lignes d'explications plus claires m'auraient permises de gagner un peu de temps et de moins stresser. Avoir le choix entre cette façon d efaire et un mode automatique serait bien sur souhaitable ! J'espère donc que ces quelques lignes en aideront certains.

 

Exploiter un serveur dédié chez Online

28 septembre 2019 Lionel IP & Co, IT

Je dispose depuis des années, entre autres, d’un serveur dédié sur Online / Scaleway. Pourquoi eux ? Pour le service toujours très réactif, ils répondent au téléphone tout de suite, et par exemple hier soir j’ouvre un ticket à 3 heures du matin et en 5 minutes j’avais ma réponse. Bref, on n’est pas chez OVH ! A l’occasion d’une promo je commande un nouveau serveur avec une belle remise, je me trompe en en choisissant un sans RAID hardware, un coup de fil et c’est réglé et remboursé et je n’ai plus qu’à recommander le bon serveur, avec du RAID car je veux faire de l’ESX.

Vous allez me demander pourquoi je ne prends pas simplement des instance cloud, simplement parce que c'est bien plus coûteux et surtout j'aime bien avoir la main sur toute la chaîne.

Installer un hyperviseur sur ce genre de serveur permet de mutualiser plusieurs VM dont j’aurais besoin. Pour accéder à ces VM Online propose des IP Failover facturées en sus, que l’on affecte généralement à chaque VM, qui seront de fait exposée sur le net avec leur IP. Cela pose deux problèmes, outre le coût (1.99 € / mois par IP) qui n’est pas le plus important, la sécurité du serveur hébergé sur la VM n’est assurée que par le firewall de l’O/S, ce qui reste léger et potentiellement vulnérable.

J’ai donc fait le choix cette fois de ne pas exposer mes VM et d’installer une VM frontale qui servira de reverse proxy et qui sera la seule vue de l’extérieur, donc je n’aurais besoin que d’une seule IP Failover. Il existe plusieurs solutions pour faire ça, Traefik, Ngnix par exemple, j’ai choisi pfSense avec le plugin HAProxy qui est simple à déployer et qui en plus gère très bien les certificats Lets Encrypt via le plugin Acme.

Dans la pratique on installe ESX en quelques clics via la console Online, ensuite on crée sur ESX un LAN qui n’est connecté à aucune carte réseau (on doit pouvoir utiliser le même swich virtuel que pour le WAN avec un VLAN, mais ce serait se compliquer la vie). Dans la console Online on achète une IP Failover, on l’associe au serveur dédié et on lui attribue une adresse MAC que l’on reportera sur le WAN de la VM pfSense. (je trouve le client vSphère plus intuitif que la version web pour faire ce genre de réglages).

On installe pfSense à partir d’une ISO dans une VM avec une patte WAN (sans oublier d'y reporter la MAC adresse de l'IP Faiover), et une patte LAN. Pour ces deux interfaces on prend une carte réseau VMXNet3 pour de meilleures performances.

Une fois l’installation terminée, depuis la console ont défini VMX0 sur le WAN et VMX1 sur le LAN et on configure les adresses IP correspondantes, l’IP Failover sur le WAN (SANS GATEWAY, c’est important) et une IP LAN, 192.168.x.1 par exemple et sans passerelle puisque c’est le LAN. On n’active pas le serveur DHCP.

Ensuite on passe dans le shell de la console (ce n’est pas du Linux mais du FreeBSD) et c’est là qu’il y a une particularité qui est propre à certains hébergeurs, ici pour Online, mais il y a une variante OVH par exemple. pfSense ne permet pas d’avoir une passerelle en dehors du masque de son IP WAN, il va donc falloir ruser en la définissant via le shell :

route del default (pour retirer les passerelles existantes)
route add -net 62.210.0.1/32 -iface vmx0
route add default 62.210.0.1

A partir de là on peut se connecter à pfSense avec un navigateur et se laisser guider par le wizard. On confirmera l’IP Failover mais toujours sans passerelle (ni MAC). On teste avec les diag en faisant un ping vers 1.1.1.1 et on crée une règle pour autoriser le trafic sortant depuis notre LAN. Pour la suite de la configuration cherchez vous un tuto sur pfSense !

Voilà, il ne reste plus qu’à installer nos VM et les publier via HAProxy dans pfSense.

Bonus

  • Mettre des ACL sur le firewall d’ESX pour limiter l’admin uniquement depuis certaines IP
  • Rendre l'accès à la configuration pfSense accessible uniquement depuis le LAN
  • Installer une VM Zerotier site-to-site afin de pouvoir accéder aux VM (en RDP ou SSH par exemple) ainsi qu'à l’admin de pfSense qui ne sera exposée que sur le LAN.
  • Sur pfSense installer le package Open-VM-Tools
  • Sur pfSense installer le package Shellcmd afin de figer les routes spécifiques exposées ci-dessus.

J’ai fait ça sur un serveur un peu costaud, mais c’est jouable sur les petits serveurs Avoton d'entrée de gamme qui étaient soldés à 4 € avec 16 GO…

Sources