Installer Debian Squeeze en RAID1 logiciel avec des volumes logiques chiffrés

HDD-10mbPourquoi ? Pourquoi avoir recours à une telle gestion des disques sur notre serveur/poste de travail. Tout simplement car un collègue m’a récemment demandé conseil sur l’infrastructure informatique à mettre en place pour la création d’une TPE/petite-PME. Je lui ai donc répondu que les rats quittaient le navire, que de la part de … ça ne m’aurait pas étonné, mais toi, toi ! Disparais céans ou je te flagelle à coup de RJ45, fumier. Il a répliqué qu’il s’agissait d’un ami à lui qui heu, voulait heu, enfin tu vois, se lancer dans une activité heu, dans le tertiaire, voilà c’est ça, le tertiaire. Pleinement soulagé et rassuré quant à la loyauté et la droiture du collègue, je me confondais en excuse et lui promettais de réfléchir rapidement à la question, d’autant que son ami semblait pressé. Le sujet étant vaste et néanmoins bougrement intéressant, je m’arrête dans cet article à la problématique du stockage sur un serveur GNU/Linux, nul besoin d’un Windows pour cela, le but étant ici d’allier fiabilité (RAID1), flexibilité (LVM2) et sécurité (chiffrement LUKS).

Je précise d’emblée aux esprits chagrins que le but ici n’est pas de discourir sur la pertinence d’une solution donnée par rapport à une autre (RAID1 vs RAID5, NAS vs serveur multi-rôles, etc). L’idée est uniquement de détailler la procédure de partitionnement (même si le terme est un poil galvaudé) lors de l’installation de l’OS car contre toute attente, ce fut un peu laborieux. Je me heurtais systématiquement à un message d’erreur indiquant que GRUB ne pouvait s’installer sur /dev/sda (ni même sur /dev/sdb ou encore hd0). Soupçonnant une quelconque erreur dans ma méthode, j’ai testé différentes procédures (RAID1 + LVM, RAID1 + Chiffrement global, LVM + Chiffrement global et même RAID1 + LVM + Chiffrement séparé de chaque volume logique) sans le moindre problème. Ce n’est qu’en recommençant une n-ième fois que je me suis finalement rendu compte que la configuration de la partition /boot disparaissait au cours de la procédure…

Pré-requis :

  • Un serveur GNU/Linux (ici Debian Squeeze 64 bits)
  • 2 disques durs de même capacité (ici 8,6 Gio)

Conventions :

  • prompt : # commande : exécuter la commande sous le compte root ou précédée de la commande « sudo »
  • prompt : $ commande : exécuter la commande sous le compte utilisateur

En avant pour la visité guidée (je n’ai pas lésiné sur les captures d’écran, je vous préviens). Notez que les captures suivantes ont été réalisée sur une machines virtuelle KVM sous Proxmox mais ça ne change rien à l’affaire.

– Choisir le partitionnement manuel et créer au début de chaque disque une partition primaire de 256 Mio qui aura comme point de montage /boot. La partition de démarrage ne pouvant être chiffrée, on la traite à part.

Partitionnement manuelCréer une nouvelle table de partitionCréer partitionPartition de 256 Mio

Partition primaireCréer la partition au début du disque




















– Configurer ces 2 partitions en tant que volumes physiques pour RAID, valider les changements puis configurer le RAID logiciel. Créer un volume multi-disques RAID1 de 2 disques, sans disque de secours, puis sélectionner les 2 partitions des 256 Mio. Faire de même avec les 2 partitions restantes et valider la configuration du RAID1.

Configurer les partitions en tant que volumes physiques pour RAIDConfigurer le RAIDCréer un volume multidisqueRAID1

Utiliser 2 disquesPas de disque de rechangeSélectionner les partitions de 256 Mio

Faire de même avec les 2 autres partitionsValider la configuration RAID1






























– Sélectionner le volume RAID1 de 256 Mio et le formater en Ext3 avec /boot comme point de montage :
Sélectionner la partition RAID1 de 256 Mio Formater en Ext3 et point de montage /boot










– Chiffrer la partition RAID1 de 8,3 Gio, rien de spécial à signaler ici, il suffit de suivre les captures d’écran. Notez qu’il faut bien sûr accepter d’écrire des données aléatoires sur tous les secteurs de la partition mais que cela peut prendre beaucoup de temps, en fonction de la taille de cette partition. On remarquera que sur la première capture d’écran ci-dessous, la partition RAID1 de 256 Mio est bien configurée avec comme point de montage /boot.

Configurer le chiffrementValider les changementsCréer un volume chiffréChoisir le volume RAID1 de 8,3 Gio

Paramètres de chiffrementFinir la procédure de chiffrementEcrire des données aléatoires sur l'ensemble de la partition

Choisir un mot de passe solide





























– Après le chiffrement de la partition de 8,3 Gio, on constate sur la première capture d’écran ci-dessous que la partition RAID1 de 256 Mio n’a plus de point de montage (il faudra donc penser à reconfigurer cette partition avant de poursuivre l’installation de l’OS sous peine de se retrouver avec un chargeur d’amorçage incapable de s’installer correctement). On passe maintenant à la configuration des volumes logiques. Après avoir créé un groupe de volume logique (VG) dans la partition chiffrée, créer les volumes logiques désirés (ici vg-root, vg-swap et vg-home) et terminer la procédure.

Configurer les volumes logiques Confirmer le formatage en Ext3Créer un groupe de volumes logiquesNommer le groupe de volumes logiquesSélectionner le volume chiffréConfirmer le schéma des partitions Créer un volume logiqueSélectionner le groupe de volumes logiques précédemment crééNommer le volume logiqueSaisir la taille du volume logiqueCréer les volumes logiques supplémentairesTerminer la procédure de création des volumes logiques







































– Configurer le formatage et le point de montage de chaque volume logique :

Sélectionner le volume logique "vg-home"Configurer le volume logiqueSélectionner le volume logique "vg-root"Configurer le volume logiqueSélectionner le volume logique "vg-swap"Configurer le volume logique



















– Reconfigurer le point de montage (/boot) de la partition RAID1 de 256 Mio et finir la procédure de configuration des disques :
Reconfigurer la partition de 256 MioTerminer la procédure de partitionnementConfirmer la configuration des partitions et volumes logiques










– Une fois l’installation achevée et le système redémarré, il ne reste plus qu’à installer GRUB2 sur /dev/sdb (il s’installe sur /dev/sda par défaut) afin de pouvoir démarrer sur les 2 disques :

# grub-install "/dev/sdb"

Installer GRUB2 sur /dev/sdb












Vérifier que Grub est bien installé sur les 2 disques en débranchant chaque disque alternativement et en démarrant le système. That’s all folks !

20 commentaires

  1. Bonjour DocGreen, d’abord félicitations pour cette article clair et détaillé. Comme toi je mets en place sur mon poste de travail du RAID1 + LUKS + LVM . Mais a l’époque ou j’ai commencé à faire ça l’installateur de Debian ne permettait pas de gérer le cryptage, donc je faisais ça à la main ainsi que le LVM. La particularité est que je lisais sur plusieurs tuto que le kernel ne pouvait pas « fonctionner » sur une partition mirroré (RAID), donc j’ai toujours laissé les 1ers partitions de chaque disque (sda1 et sdb1) tel quel, en copiant le MBR de sda sur sdb avec la commande dd, et en parametrant un rsync dans le crontab pour synchroniser leurs données ttes les 5min (sachant que /boot ne change pas très souvent en soi). Bref, je suis étonné et content à la fois de voir dans ton article que le kernel peut apparemment fonctionner sur une partition RAID car ça m’évitera quelques manipulations dans mes futurs installations. Aurais-tu une idée du pourquoi j’ai pu avoir l’occasion de lire cette incompatibilité entre kernel et RAID auparavant ? Librement

  2. Bonjour et merci pour ton commentaire.
    C’est assez drôle parce que j’avais lu pour ma part que Debian Lenny (et GNU/Linux en général) maîtrisait très bien le RAID1 logiciel. Un des serveurs que j’administre est toujours sous Debian Lenny et fonctionne parfaitement bien en RAID1. A l’époque j’avais consulté pas mal de tutoriels et celui-ci montrait que l’usage de RAID1 + LUKS + LVM était possible même si c’était assez laborieux à mettre en place. Pour les versions antérieures, je n’ai pas d’infos.
    Le but de l’article est d’avoir une méthode claire, qui signale l’écrasement potentiel de la configuration de /boot (potentiel, car cela n’arrive pas lorsqu’on configure cette partition en dernier) et qui fonctionne.
    J’ai aussi souri à la lecture de ta technique de réplication de /boot (dd + rsync), ingénieux ! Heureusement qu’on est plus obligé de passer par là aujourd’hui…

    La seule « faiblesse » de sécurité de cette méthode concerne la partition /boot qui ne peut être chiffrée, il reviendrait alors au BIOS/UEFI de la déchiffrer pour continuer la procédure de démarrage, il me semble avoir lu quelque chose là dessus il y a plusieurs mois mais rien depuis…

    Je serai curieux de connaître la version de Debian que tu utilisais.

  3. Re-Salut DocGreen,

    J’ai bien suivi tes conseils pour la gestion des espaces et je t’en remercie. J’ai par contre un blocage à la fin de l’installation de ma distribution, au niveau de Grub. Pas moyen de l’installer dans /dev/sda : j’ai le message d’erreur suivant « Impossible d’installer Grub dans /dev/sda

    Dans les logs de l’installation, j’ai ces lignes :

    /usr/sbin/grub-setup : warn this GPT partition has no boot partition; embedding won’t be possible
    /usr/sbin/grub-setup : error : embedding is not possible, but this is required when the root device is on a raid array or LVM volume
    /usr/sbin/grub-setup : Running grub-install –no-floppy –force « /dev/sda » failed.

    Aurais-tu une idée ?

    En attendant, je vais tenter un installation de Grub sur chacun des disques avec le mode Rescue du CD et en débranchant un à un les disques durs (J’ai trouvé l’info ici >> http://www.debian-fr.org/installation-en-raid1-t36125.html#p364542)

    Je reviens après ici en cas de réponse positive ou négative …

    @+

    Aleks.

  4. Salut,

    je pense tu eu as le même problème que moi à savoir que la configuration de la partition /boot « sautait » lors de la configuration des autres partitions.

    Vérifie donc que /boot est bien configuré à la fin de la procédure de partitionnement (comme sur les 3 avant-derniers screenshots).

    Doc.

    1. Salut,

      Petit retour d’expérience : après quelques jours passés (assez laborieux =)) pour trouver d’où venait ce problème d’installation de Grub, j’ai découvert sur d’autres forums que ce problème apparaissait sur des cartes mères équipées d’un bios EFI (mon cas).

      Pour contourner ce problème, il suffit de créer une nouvelle partition en fat32 d’une centaine de Mo avec le drapeau « bios-grub » au début de chaque disque (ne surtout pas toucher ou monter cette partition depuis le CD d’install de Debian) . Par contre, pour créer ces partitions, obligation d’utiliser un liveCD Gparted car c’est impossible de créer ce fameux drapeau avec partman du cd d’installation de Debian.

      Ensuite il suffit de créer les autre partitions avec le cd d’install de Debian et à la fin, au moment où l’assistant propose d’installer Grub automatiquement, il faut répondre « non » et choisir manuellement l’emplacement : /dev/sda. Je sais que par défaut il l’installe dans cet emplacement mais dès que je l’utilise, ça me fait sauter la 1ere partition bios-grub créée au début).

      Ensuite, installer Grub dans /dev/sdb comme indiqué dans le tuto

      Ça marche enfin ^^

      Aleks..

      1. salut,

        content que tu ais enfin finalisé ton installation !

        Je ne connaissais pas le problème des cartes-mère EFI, merci de ton retour d’expérience, ça pourra aider des personnes dans le même cas.

        A l’occasion, je testerai la manip et compléterai le tuto. Espérons que tout ça sera pris en charge par la future version de Debian.

        Doc

        1. Re-salut,

          J’ai parlé un peu trop vite… après avoir testé si le 2e disque dur bootait bien si le premier est débranché, Grub bug et reboot indéfiniment au moment où il charge.

          J’ai trouvé des infos sur internet qui disent de modifier la configuration de Grub et notamment ajouter/modifier

          insmod raid
          set root=(md0)

          (source http://www.developpez.net/forums/d1147703/systemes/linux/systeme/probleme-grub2-debian-squeeze-raid-1-a/#post6328242)

          J’ai donc ajouté ces lignes dans /etc/default/grub (source https://wiki.archlinux.org/index.php/GRUB2#Raid)

          Mais quand je fais un update-grub, j’ai un message d’erreur en retour : « insmod: can’t read ‘raid’: No such file or directory »

          Je pense que je ne dois pas modifier au bon endroit (surement une erreur de débutant).

          Aurais-tu une piste à explorer ?

          Aleks

      2. Bonjour,

        Même problème Aleks2a, impossible d’installer grub sur /dev/sda lors de l’install de debian.
        J’ai créé une partition de 100M au début de chaque disque avec Gparted, en fat32 avec le drapeau « bios-grub ». Plus d’erreur lors de l’install au moment d’installer grub sur /dev/sda. Par contre le système ne trouve pas de disque bootable. J’ai ensuite re-vérifié avec GParted, et les partitions sont bien toujours là, avec le drapeau.

        Auriez-vous une piste à explorer ?

        1. Hello !

          Essais de débrancher un de tes disques dur pour arriver à booter sur l’un ou l’autre. Une fois ton serveur booté, tu identifies le disque dur surlequel tu arrives à booter, tu éteints tout et tu branches en master le disque dur qui boote, et l’autre en slave.

          Normalement, si tu redémarres, tu devrais arriver à booter (y aura juste ton raid à resynchroniser que tu pourras faire plus tard). Il te reste plus qu’à installer Grub en ligne de commande sur le disque dur qui boot pas.

          Ensuite, test le boot de chacun des tes disques en les débranchant.

          En espérant t’avoir aidé.

          1. Merci pour cette réponse, mais malheureusement j’avais bien essayé de booter sur chaque disque et rien à faire, ça ne démarre pas. Aucun des deux disque ne semble bootable. Je vais supprimer toute mes partitions avec GParted et recommencer depuis le début. J’ai peut-être loupé quelque chose quelque part.

            Je reviendrai donner le résultat ici.

          2. Après de nombreuses recherches, j’ai trouvé d’où venait le problème.

            Les deux disques en RAID ont des capacités de 3TB, il fallait donc activer dans le bios, section boot, l’option « Enable UEFI », ET désactiver tous les autres périphériques sur lesquels booter (USB, optique, LAN…).
            Il s’agit d’une carte mère Intel, je ne sais pas si les autres cartes mères ont ce type de comportement avec des disques > 2TB, mais en tout cas, maintenant ca fonctionne chez moi.

            En tout cas, merci pour cet article très clair et les commentaires bien utiles

  5. Hello,

    Merci pour ce super tuto.

    Je voudrais savoir au cas l’un des deux disques crash, s’il était assez aisé (et de manière fiable) de reconstruire le RAID à l’identique avec un disque neuf ?

  6. Salut Matthieu,

    effectivement, il est très simple de reconstruire le RAID, le changement de disque est même faisable à chaud s’ils sont en SATA.
    Il faut utiliser un disque de taille supérieure ou égale.
    J’ai effectué la manip plusieurs fois sur mes serveurs sans aucun soucis.

    Tout se passe avec la commande mdadm.

    Prenons un cas simple :
    RAID1 de 2 disques (sda et sdb) avec 3 partitions /boot, / et swap (donc 3 arrays)

    – Typiquement, en cas de disque HS (disons le disque /dev/sda), on retire les partitions de ce disque des arrays correspondants :
    # mdadm –remove /dev/md0 /dev/sda1
    # mdadm –remove /dev/md1 /dev/sda2
    # mdadm –remove /dev/md2 /dev/sda3

    – On remplace le disque physiquement (à chaud ou pas) et on recopie la table de partition du disque sain (sdb) sur le nouveau disque (sda) :
    # sfdisk -d /dev/sdb | sfdisk /dev/sda

    – On ajoute les partitions du nouveau disque dans les arrays correspondants :
    # mdadm -a /dev/md0 /dev/sda1
    # mdadm -a /dev/md1 /dev/sda2
    # mdadm -a /dev/md2 /dev/sda3

    – La reconstruction se fait array par array, on peut suivre l’évolution de l’array mdX avec la commande :
    # mdadm –detail /dev/mdX | grep « Rebuild Status »

    – Après la reconstruction du RAID 1, il faut rendre le nouveau disque bootable avec GRUB (en supposant que ce disque soit hd0 et que la partition de démarrage soit la première – hd0,0) :
    # grub
    root (hd0,0)
    setup (hd0)
    root (hd1,0)
    setup (hd1)
    quit

    – Vérifier que GRUB est bien installé sur les 2 disques :
    # grub
    find /boot/grub/stage1

    Le résultat doit être du type :
    (hd0,0)
    (hd1,0)

    J’espère que ça répond à ta question 😉

    A+

    Doc

    1. Super merci pour la réponse, tout cela m’a l’air ultra industriel et fiable : )

      En revanche je m’interroge suite aux commentaires de mes camarades et de leur embrouilles avec la partition FAT lié au bios uefi. Je ne sais pas trop quel est l’état de la compatibilité avec debian 7.1 mais ça me semble un peu complexe surtout s’il faut remonter un disque on est un peu loin du plug et reconstruit …

      Sinon sais-tu si ZFS Linux est mature/stable sur Wheezy je suis très intéressé par ce FS et sa gestion native du RAID.

      Pour l’instant je suis sur un vieux troublon qui me sert de serveur samba fichier et héberge ma galerie photo (du genre P4 qui consomme à mort … j’ose même pas mesurer à la prise) sans système de RAID et un Western Digital qui va bientôt taper les 10 ans gloups .. avec comme sauvegarde une réplication Rsync chez un tiers.

      Je pense changer ma conf vers un système plus 2013 et surtout plus green (genre Pentuim G sur carte mère ITX et deux beaux disques Constellation, d’expérience je les recommande fortement niveau fiabilité bien meilleur que les séries RED de chez WD).

      J’aimerais bien mettre en place un système Debian / ZFS / RAID 1.

      Pour me servir de ZFS couplé à des VM au boulot pour certain clients je dois dire que c’est de la bombe, le système de snapshot lié à de la VM permet de restaurer les anciens fichiers sans problème à la volé en montant simplement un snap dans un FS (bon en même temps l’architecture est pas la même que sur un serveur personnel ).

      Or je me tate encore mettre le système directement sur le RAID comme tu le fais (à voir comment ZFS se comportera ..) ou bien dédier tout le système sur un plus petit disque hybride et ZFS uniquement pour la paire de disque .. et à voir comment il se comportera en cas de crash d’un des deux disques, si c’est la croix et la bannière pour remonter tout ça … ou encore laisser tomber et prendre un Qnap ….hum tout cela n’est pas simple …

      1. – Je ne suis pas au courant de cette histoire de partition fat / UEFI, tu peux développer ?

        – Concernant ZFS, c’est vrai que c’est un chouette FS, son seul « problème » étant de ne pas avoir d’implémentation native dans le noyau GNU/Linux. Il faut utiliser Fuse pour s’en servir et du coup niveau perf, ça prend une claque. La rumeur d’une implémentation revient de temps à autre mais avec le rachat de Sun par Oracle et la maturation de btrFS (qui est censé être avoir les même fonctionnalités et être aussi bon voire meilleur) ça me parait compromis.
        J’avais un peu utilisé Nexenta et c’est vrai que ZFS est réellement pratique à utiliser. Elle a été remplacé par Illumian donc si tu veux un OS avec du ZFS natif ainsi que des fonctionnalités Debian (APT) c’est ça qu’il te faut.

        – Pour ma part sur mon serveur perso, j’utilise Proxmox comme hyperviseur, c’est vraiment sympa. Tu peux créer des VMs avec KVM ou dans des conteneurs openVZ. Il utilise LVM pour faire les snapshots et ça marche bien. Il est possible de l’installer en RAID1 après l’installation (y’a pleins de tutos sur le net).

        – Concernant la partie hardware, merci de l’info pour les Constellation. Sinon privilégie un CPU AMD si tu veux faire des VMs et avoir un serveur écolo et pas trop cher. Pas vraiment pour une question de performance/conso mais plutôt pour bénéficier des instructions AMD-v dédiées à la virtualisation. AMD les propose sur presque tous ses CPU contrairement à Intel où il faut monter (très) haut en gamme. J’avais acquis un HP Proliant Microserver à vil prix équipé d’un Turion N40L, j’avais des craintes niveau perf mais c’est très acceptable pour un homeserver

        1. – Pour la question UEFI / FAT32 je ne faisais que me référer à l’un des commentaires ci dessus : @Aleks2a qui avait rencontrer des petits problèmes (résolus avec un peu de bricolage).

          – Pour le matos merci de l’info pour le HP Proliant Microserver, effectivement j’en ai trouvé à très bas prix avec les proc AMD permettant la Virtu je suis super tenté 😛

          – Je viens de tester Proxmox sur VirtualBox avec la mise en place d’un raid 1 logiciel en effet ça à l’air de bien marcher : ) Super comme outil en effet je ne m’en étais jamais servis !! En revanche je n’ai pas crée de conteneur OpenVZ ni démarré de services dessous ni joué avec les partitions ni avec LVM … tout ça.

          En fait mon but et d’avoir un conteneur qui fait Samba (pour mon partage de fichier local) et une machine pour la partie hébergement (lighttpd / php / mysql).

          Donc dans un cas concret , le HP Proliant semble être livré avec un disque de 250 Go .
          Est-ce faisable selon toi d’utiliser deux disques (2*250 Go) en RAID 1 pour la partie OS Promox et mettre un conteneur openVZ qui lui ferra également un RAID 1 sur deux autres gros disques indépendant ( uniquement pour mes datas ) je ne sais pas trop si tu vois ce que je veux dire, mais cela te semble t-il réalisable ?

          Ha et sais-tu s’il est faisable de remonter un Promox qui a crashé non monté en RAID (du genre conteneurs alloués sur d’autres disques) OS Promox sur simple disque > disque OS qui claque > réinstallation Promox sur disque neuf >> Importation des VM précédemment dumpées (par snapshot ou autre) ? Je n’ai pas trouvé cette option … parce que mettre mes datas en RAID c’est cool mais si l’host claque et impossible de le remonter sans reformater et obligé repatir avec des guest « neufs » bon pas cool.

          Désolé ça fait beaucoup de questions … et je ne sais pas trop si je me fais bien comprendre j’aimerais simplement éviter de partir sur une solution bancale (en plus je suis chiant je veux un système de NAS qui fait en même temps Httpd), l’aspect cloisonement de OpenVZ me plait bien niveau securité (j’ai cru comprendre qu’avec la 7.1 le produit passait en deprecated dans les dépot …) … je sens que ça va se finir sur une BSD avec des jails ça ^^

  7. – Ouais l’UEFI, c’est assez casse-bonbon. Heureusement, mes serveurs persos ne sont pas concernés même si ça sera le cas un jour forcéement (le HP a un bon vieux BIOS à l’ancienne !).

    – En fait, les VMs/conteneurs/templates/ISOs sont par défaut placés sur le même disque que Proxmox (dans /var/lib/…), du coup si tu installes ton Proxmox en RAID1, les VM seront dupliquées. Attention, elles ne seront pas elles-même en RAID1 mais ce n’est pas un problème, la continuité de service devrait être assurée.

    Pour la restauration sur un autre Proxmox, c’est totalement possible (et c’est un peu le but aussi) mais ça nécessite de faire des backups sur un autre disque que celui de l’hyperviseur, ça parait évident mais on voit de ces choses parfois…
    J’ai déjà restauré sans problème dans un Proxmox installé dans Virtualbox, des snapshots openVZ qui provenaient de mon HP Microserver.

    De toutes façons, tu n’auras pas d’autres choix que de martyriser ton installation afin d’être sûr de savoir ce qu’il faut faire en cas de problème (reconstruire le RAID, restaurer les VMs dans un autre Proxmox…). Y’a rien de mieux pour être sûr de la fiabilité de son installation, le RAID1, les VMs, les backups, ça apporte beaucoup de sécurité mais il faut être sûr que le jour J tout se passe comme prévu !

    – Pour ton installation si tu prends le HP, prévoit de prendre 4 ou 8 Gio de RAM (2 Gio peut être assez vite limitant) ainsi que 2 HDD (1 pour le RAID1 et 1 pour le backup). Il faut aussi savoir que le serveur ne supporte pas le branchement/débranchement de disque à chaud, c’est possible mais le disque ne sera pas détecté sauf s’il s’agit du même modèle exactement, ça vaut donc peut-être le coup d’acheter 3 disques (2 pour le RAID1; 1 de rechange à chaud) et de garder celui fournit pour les sauvegardes. Ça commence à chiffrer, mais bizarrement les gens s’en veulent toujours de ne pas avoir investit dans une solution de rechange le jour où il y en a besoin 😉

    Pour finir la bible du microserver : http://forum.hardware.fr/hfr/Hardware/minipc/unique-proliant-microserver-sujet_908322_1.htm

  8. Pour ce qui est d’openVZ, c’est vrai que ce n’est plus supporté officiellement par le noyau Debian, c’est pour ça qu’un noyau CentOS est utilisé, mais ça fonctionne bien, pas de soucis à avoir pour l’avenir le support étant assuré par Proxmox. De toute façon, un jour ou l’autre, il faudra migrer vers LXC ou un autre système mais ça ne sera pas brutal et on aura le temps de voir venir.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.