Préserver des données serveur

Bonjour bonjour !

Dans la lignée “Comment ça se passe chez les autres ?”, je me pose actuellement la question de la préservation des données sur un serveur debian.
La combinaison qui m’intéresse pour le moment est de mettre en place un système de snapshots avec butterfs comme système de fichiers (en cas de mauvaise manip’ par exemple) et un rsync vers un support de stockage distant. Pas prévu pour le moment de faire une redondance du serveur entier, ça viendra peut-être plus tard.
Avez-vous des suggestions, pistes à proposer ? Quelle est votre recette favorite ?
Quid également des isolations type conteneurs LXC ? Dans quels cas vous paraissent-elles indiquées pour un serveur ?

Bien à vous chers débianistes !

Avec ça, ça va être gras, essai putôt BTRFS (better fs).

Tu entends quoi par la ? du service en failover ou carrément de la haute disponibilité ?

De façon personnelle et parce que j’ai du matériel et des connaissances j’ai mon propre Cloud à la maison (bientôt finit de remettre en place les dernières briques de mon Openstack perso).
Pour ce qui est des services j’utilise de la Docker machine avec du Swarm + stack/compose.
Pour la donnée j’ai du Swift et du Ceph pour le stockage froid et chaud de mon cloud, sur lequel de l’OMV (remplace Freenas qui ne supporte décidément mal la virtualisation, et finalement très peu d’intérêt de mettre du ZFS sur du Swift ou du Ceph ).

Pour ce qui est de la protection j’ai de l’Opensense en tête de réseau juste derrière une box d’origine.

Finalité j’ai de la domotique à la maison + différents services utiles et une grosse plateforme pour le dev perso.

C’est totalement overkill pour mes besoins réels mais tellement jouissif à monter et maintenir quand tout va bien, par contre c’est très vite l’enfer lorsque tu cherche à faire du debug et que t’a pas le temps :confused:

1 J'aime

Bonjour,

Personnellement je fais une sauvegarde sur HubiC et une autre chez moi. Ayant moyennement confiance dans le premier, j’utilise le chiffrement de rclone.

Je dispose d’un serveur Kimsufi sur lequel je fais tourner Proxmox. Je ne sauvegarde absolument pas l’hôte.

Je commence à abandonner LXC parce que j’ai quelques petits soucis de stabilité et qu’au final, une VM n’est pas beaucoup plus gourmande. J’ai fait le choix de la virtualisation parce que je suis un grand bricoleur et que cela simplifie les sauvegardes.

Puisque la question concerne les sauvegarde, la virtualisation te permet de sauvegarder un système invité complet. En gros, même en cas de problème matériel, je peux prendre n’importe quel autre serveur et redéployer mes CT/VM dessus. Au pire, j’aurais un peu de configuration réseau à faire.

Arf, à chacun sa phonétique !^^ En fait, il semblerait que ça veuille dire “B-Tree filesystem”.

L’un ou l’autre, je ne vise pas à maintenir un mastodonte non plus (enfin, je ne crois pas^^) mais je cherche à faire ça bien, quitte à exagérer un brin, histoire de gagner en compétences au passage. Si jamais ça se présente à l’avenir, je commencerai sûrement par du failover.

Tu veux dire que la copie-sur-écriture ne te sert à rien compte tenu que Swift et Ceph tournent sur tes machines ?

Oui, alors c’est vrai que c’est hyper intéressant tout ça mais nous allons être au moins deux à administrer le serveur et on est déjà pris sur d’autres projets donc on va essayer de commencer plus simple ! :rofl:

Merci pour l’info, je ne connaissais pas. Je vais potasser.

Pourrais-tu développer ? Donner des exemples peut-être ?

En Proxmox du coup ?

Quelqu’un a-t-il d’autres retours concernant le système de fichiers beurré ? Il semble pouvoir poser des soucis aux VM car il fragmente beaucoup… et RedHat l’a viré de ses versions, apparemment parce qu’il n’apporte plus grand-chose en termes de fonctionnalités/performances.

Merci pour vos retours !

Je viens récemment d’expérimenter des conteneurs avec plusieurs interfaces réseau et ça ne se passe pas très bien. Une fois sur deux, lorsque je redémarre le conteneur, lxc crash. Heureusement, ce qui tourne continue de tourner, mais je ne peux plus gérer mes conteneurs ; obligé de redémarrer l’hôte.

Oui, je ne fais que du Proxmox à titre perso. On a du VMware vSphere au boulot, mais j’aime pas ça.

La seule chose qui m’intéresse avec le BTRFS c’est le RAID6 et comme la fonctionnalité est buguée… En terme de performances, c’est pas probant non plus, donc bon.

1 J'aime

A quoi bon vouloir utiliser du ZFS (enfin ces features) alors que les technos de Swift et de Ceph font le taff.
De plus la virtualisation m’amène franchement rien de bon sur pour du ZFS, tout comme la surcouche du carte raid sur du ZFS.
Je pense que d’ailleurs ce doit être la même côté perf pour le btrfs, reste sur de l’extend4 ça marche très bien et c’est passe partout.

Sinon le xfs est pas mal pour du stockage à forte densité de petits fichiers.

Pour la redondance si tu ne dépasse pas le cadre de trois serveurs et que tu cherche à faire de l’actif/passif alors du drdb sera sans doute une solution efficace pour s’occuper de la redondance des données.

Après LXC franchement je trouvé ça moche comparer à des jails sous BSD, mais depuis que j’ai goûter à du Docker et du Kubernetes, franchement j’y reviendrai pas.

du KVM pour la virtualisation d’un système complet (rare et très spécifique) et du docker pour du service, voilà la recette chez moi.

1 J'aime

Un grand merci pour vos réponses. Ça me fait pas mal de grain à moudre.

@Clochette
Si tu as le temps, je suis curieux de savoir dans quels cas tu privilégies Swarm, stack, compose et/ou Kubernetes pour tes dockers. Je ne suis pas spécialiste mais il me semble avoir des fonctions relativement proches…

Concernant la solution drbd, y rajouter Heartbeat/Pacemaker (dans un schéma actif/passif à deux serveurs seulement) semble donner une solution complète de relative haute disponibilité. Qu’en pensez-vous ?

Si d’autres ont des éléments à partager, je suis bien entendu tout ouïe. :slight_smile:

Oui c’est assez proche tout dépendra ou tu sera le plus à l’aise, je n’utilise pas de Kubernetes à la maison mais au boulot oui, pour ce qui est de pourquoi préférer Docker que du LXC ou autre joyeuseté, c’est la facilité de maintenir le tout avec un CI (chaque reconstruction réussi de mes containers poussera une nouvelle version vers la prod et un simple redémarrage du container te me voilà à jour.
Et je n’aborde pas la joie d’écrire une stack et de la lancer avec un appel d’une ligne :wink:

Pour de l’actif/passif oui, pour de l’actif/actif ce la nécessitera bien plus de travail et d’investissement pour un besoin pas forcément …

Bonjour,

Je suis la personne qui travaille avec Leobo sur notre projet de serveur, pas trop actif sur les forum c’est lui qui m’a encourager à m’inscrire à a participer ici.

L’idée de l’utilisation de LXC couplé à Btrfs vient à la base de moi et ne repose pas uniquement sur le besoin de préserver les données des serveur. Je me dit que j’aurais peut être du créer un autre poste avec un titre plus précis mais je peut pas… (nouveau membre ?)

Je veux utiliser LXC car nous aurons sûrement besoin à l’avenir de disposer de plusieurs système sur une même machine physique au ressource matériel limités notamment en mémoire vive (un des objectif est de tenter l’expérience de proposer des hébergement local dans un cadre associatif). De plus j’aimerais que cette solution puisse aussi fonctionner sur des nano-ordinateur (une des idée derrière est que comme nous avons peut de moyens financier nous pourrions peut être envisager des serveur sous forme de cluster de nano ordinateur que nous pourrions faire croître sellons nos besoin). Donc je pense que les solution de virtualisation hvm type kvm ne serons pas adaptés. Pour ce qui est de Docker, je n’ai pas encore eu l’occasion de travailler avec mais il faut que je m’y colle sous peut, cependant je ne pense pas l’utiliser dans ce cadre car il me semble qu’il ne soit pas adapté à la conteneurisation de système complet mais plutôt à l’isolement applicatif et ici nous aurions besoin de fournir des “système isolé” complet qui puisse éventuellement disposer chacun de leur propre admin. Je teste LXC sous Debian stable sur mon système pour me monter des petit serveur de test, je n’ai rencontré aucun problème jusque là, mais il faut prendre en compte que ce n’est pas un usage intensif ni en prod. Je note les problème de sk4hr sur les conteneur à plusieurs interface réseau. Il me semble que les conteneur LXC privilégié peuvent poser quelques problème de sécurités, c’est pour cela que je compte mettre en palace des conteneurs non privilégiés chacun avec un avec leur propre plage de subuid. Pour le reste les outil en ligne de commande lxc, simple est efficace me convient parfaitement, mais mon expérience fait que je n’ai pas grande référence au quels les comparer. Perso, pour le moment, je préfère me retrouver à la tête que quelques outil “rustiques” mais maîtrise plutôt qu’a la tête d’un usine à gas que j’aurais du mal à gérer.

Pour ce qui est de Btrfs, je suis très intéresser par les fonctionnalités qu’il propose. Couplé à LXC, c’est assez efficace pour la copie et le snapshot des conteneur. Je suis surtout intéressé par la copie (au sens LXC, pour Btrfs dans tout les cas c’est des snapshot) que je me voit utiliser surtout dans deux cas bien particulier :

  • La sauvegarde, ou je peut faire un snapshot Btrfs du conteneur et lancer tranquillement la sauvegarde du snapshot tandis que l’original continus de fonctionner normalement (c’est une technique que j’utilise déjà sur mon serveur actuel utilisant cette fois Xen et LVM, les performance en lectures son mauvaise et la sauvegarde très longue, j’ai mis sa sur le dos du *Copy On Write" de LVM et pense obtenir de meilleur performance avec le “Redirect On Write” implémenté par Btrfs).
  • Disposer d’environnement de test, snapshotant un conteneur et en expérimentant directement dans la copie, ainsi je ne perd pas de temps à recrée un environnement de test à peut près identique.

D’autres fonctions Btrfs m’intéresse comme les qgroup qui permettent de placer des quotas d’utilisation sur des sous volumes, les cgroup me permettent de limiter l’utilisation de mémoire, réseau et CPU des conteneur mais pas de leur espace disque, avec Btrfs je peut le faire (par contre en testant j’ai déjà rencontré des problème de calcul d’espace disponible). Je vois souvent des personnes se plaindre de problème de performance lié à Btrfs, j’ai fait mes propres test avec phoronix test tools :

Les performance sqlite3 sont bel est bien dégueux avec Btrfs mais on ne vise pas non plus à disposer de base de donnée super performante.

Bon je m’arrête la ça fait déjà beaucoup mais il fallait bien planté le contexte pour le quel ces outil on été choisis. Du coup voici maintenant les question à 2 Pessos et demis, l’approche utiliser pour choisir ces outils vous parait t’elle correcte ? Leur choix est t’il pertinent ? Faut t’il aborder ça différemment ?

Je n’ai à l’esprit aucun projet d’importance significative qui utilise du btrfs … ,pour ce qui est de LXC c’est une solution qui ne parviens pas à se développer en dehors de projet comme Proxmox (ne me parlez pas de LXD de Canonical :D) …

En bref pour du sérieux j’irai sur autre chose pour la gestion des sauvegardes que le simple espoir que les instantanées btrfs se fasse correctement et soit exploitable.

Pour de l’associatif je ne comprends pas pourquoi ne pas proposer du docker vous pourriez justement proposer du container prêt à l’usage
De bénéficier de l’usage de cgroup et autre mécanisme tel que ulimit
D’utiliser du NAS pour le stockage des données (permettant de jouer sur la scalabilité des containers et la disponibilité des volumes persistant).
Et rien n’empêche de faire tourner un système complet dans du docker ça n’a juste pas de sens de vouloir reproduire l’échec de OpenVZ ^^

Au moins je vois mieux le projet final, je pense aussi que l’utilisation d’un cluster de micro ordinateur est une bonne idée tant que les projets hébergés reste light.

Un cluster de 10 rock64 doit pouvoir faire tourner confortablement un paquet de container applicatifs.
Le plus compliquer sera sans doute de proposer votre interface pour de la mise à disposition de ressources à la demande.

Pour ce qui est des tests de performances sur du stockage dans les nuages nous sommes (dans mon entreprise) repartis sur de l’xfs pour ces réels capacités à se dépêtrer de multitudes de petits fichiers.
Les test de performances sont bien mais dépendent à la fois du matériel mais aussi de la capacité à utiliser les outils à disposition pour gérer les cas de pannes … et là-dessus btrfs ne fait clairement pas l’unanimité surtout dès que l’on cherche à effectuer un snapshot en cours d’utilisation sur de gros volumes.

A la limite du ZFS qui à le mérite d’être pus stable ou encore peut-être du HammerFS dans sa version 2 qui doit gérer le copy on write mais qui reste très jeune.

C’est pas non plus pour rien que RH a abandonné son support de base pour sa release en version 7.

Après ce n’est que mon avis, mais une partie admin bien ficelé en x86 pilotant une flottille de nano PC en ARM n’est pas une mauvaise idée en soit, attention juste au montage du cluster, si ce n’est pas fais maison ça va vous coûter plus cher que de faire du cluster en x86.

Si si ça fait partie du plan.

Moi aussi ! Ahah.

Oui c’est ce type de matériel qui nous intéresse.

Ce sera fait maison. :innocent:

Dsl, je suis pas toujours très claire… en plus on a souvent tendance a partir un peut dans tout les sens.

Le post était déjà bien long du coup j’ai essayer de rester concis et n’ai pas aborder non plus toutes les applications prévus. On ne recherche pas à disposer d’installation puissantes dont le but serait de répondre à des millier de connexion par minutes mais plutôt d’installation facilement maintenable et réplicables. Du coup on est pas vraiment dans le même contexte que celui de ton entreprise et n’envisageons pas de gérer de lourd services. Pour ce qui est de ces hébergement locaux associatif évoqué précédemment, il y en aurais au moins déjà deux sur de projet distinct. Un autre but est aussi d’être capable au besoin de proposer des solutions d’auto hébergement pour association, Indépendant et TPE (cette fois ci dans un cadre pro), ici pas de cluster de machine un simple nano-ordinateur devrais suffire. J’envisage donc de faire plusieurs de ces installations sans trop de travail de maintenance derrière, elle devrons donc la plus part du temps vivre leur vie seul et ce mettre à jours sans trop de problème (un coup d’œil de temps en temps quant même pour vérifier que tout va bien).

ZFS me fait un peut peur à ce niveau car vu que le module ne fait pas partis des sources du noyau Linux il faudra qu’il recompile à chaque mise à jour du noyau (ce qui normalement ne devrais pas poser problème au vu de l’existence du paquet zfs-dkms mais ça me gène tout de même). De plus pas de problème pour booter une partissions racine en ZFS (je suis plus très sur j’ai du voir passer un truc la dessus un jours) ? Je me sert aussi de BTRFS sur des poste client ou j’utilise la compression de donnée LZO, les optimisation SSD quant il y en as et ou je remplace l’usage de partition par des sous volumes (que je peut utiliser sur une partition LUKS si il y a besoin de chiffré de DD, dans ce cas je fait la swap compressé en ram via zram, alors oui ça peut paraître bizrad mais je fonctionne avec depuis plusieurs mois sans rencontrer le moindre problème). Je me sert aussi aussi des snapshot pour faire des point de restauration et pouvoir retourné facilement retrouver un système dans un état fonctionnel en cas d’erreur. Bon voila pour résumer, alors certes BTRFS n’est pas le plus performant des système de fichier mais il possède pas mal de fonctionnalités intéressantes. Il y a aussi un aspect fainéant dans son utilisation car au vu de sa polyvalence je peut envisager de l’utiliser partout, du coup je peut me concentré sur sa bonne maîtrise au lieux d’essayer de faire des équivalent avec plusieurs autres outils moins bien compris. On peut toujours envisager d’autres solution que BTRFS mais il faut replacer le tout relativement à nos besoin, les problème de performance de BTRFS sont ils important dans notre contexte ? J’ai pus voir des article ou de gros soucis apparaissait mais ils disposait de millier de snapshot, ce ne sera pas notre cas. Je me suis mal expliqué précédemment, je ne fait pas de sauvegarde avec des snapshot BTRFS mais je m’en sert uniquement pour obtenir un état “figé” du système de fichier durant la sauvegarde (qui elle est envoyé sur un autre périphérique), une fois celle-ci faites, le snapshot n’est pas conservé bien que l’on puisse envisager de la faire. J’avais vu des exemple d’utilisation de BTRFS en entreprise, je sait plus ou sont les article, le retour d’utilisateur sons plus ou moins heureux. A noté que OpenSuze l’a adopté comme système de fichier par défaut (mais que RedHat l’a rejeté)… c’est difficle de faire un vrais avis sans tester soit même. En tout cas si on doit abandonné l’utilisation de BTRFS (mais je pense qu’il nous faille tout de même pousser un peut les test avant de prendre la décision) je lui voit comme remplaçant LVM/ext4. (ptin1 c’est long pour pas dire grand chose)

Il y a cette série d’article qui m’on fait découvrir BTRFS sur linux-fr.org : https://linuxfr.org/users/ar7/journaux/btrfs-et-opensuse-episode-0-l-ex-fs-du-futur

Un peut de détailles sur la solution de nano-ordinateur envisagés, il s’agit d’un pine64-lts, ce qui m’intéresse beaucoup sur ce modèle c’est la possibilités de luis adjoindre des module de mémoire emmc de 64Gb, et la encore j’envisage l’utilisation de BTRFS et des optimisation pour SSD.

Par contre je suis bien plus convaincus par l’utilisation de Docker qui semble posséder des fonctionnalités très intéressantes comme le Swarm mode que tu semble utilisé. Par contre on aurrai besoin en effet de faire tourné des système complet, pour par exemple proposer des machine qui soit indépendantes pour chaque asso ou alors des instance séparé de Yunohost par exemple. Que veut tu dire par ne pas reproduire l’echec d’OpenVz ? En quoi ce type d’usage de Docker serait à évité ?

Bonjour @im_a_teapot,

Je ne sais pas comment fonctionne Docker à ce niveau là, mais l’isolation LXC n’est pas totale, contrairement à celle de KVM. Un exemple simple, en LXC, l’hyperviseur voit l’intégralité des processus des conteneurs.

En ce qui concerne le reste de ton poste, je vous invite à jeter un oeil à Proxmox VE et les volume lvm thin. Cela semble répondre à tous vos besoins. Proxmox VE à toutefois des pré-requis…

J’arrête ma propagande ici et vous souhaites bon courage dans votre projet :wink:

Bah ta propagande est pas mal, pour répondra a ta question l’isolation via docker est bien plus poussée que du côté de LXC en effet, mais reste un ton en dessous d’une virtualisation complète d’un système.

Ce que je voyais à mon sens c’est plus une flottille de nano pc avec du docker dessus permettant ainsi de fournir des services divers facilement et de façon unifié, la partie administration serait sans doute sur une machine un cran au dessus niveau puissance (et encore que :P) et une batterie de nas de type syno ou autre permettant du provisionning via un connecteur iscsi ou nfs pour les volumes permanent et les instances lancé dans docker.

Après tout comme toi cela reste du partage d’idée.

ZFS sous linux faut oublier à moins de tourner sur du Proxmox ou une base Ubuntu et Suse ( un module est disponible chez debian via dkms ^^ il me semble donc qu’il doit être disponible un peu partout maintenant) qui il me semble ont un module ZFS dispo, c’est surtout que BTRFS ne fait clairement plus l’unanimité dans les projet pro.

Merci de ta réponse :smiley:

Ce dont je parle ne va effectivement pas avec la notion de “nano pc” :confused:

Justement, Proxmox VE permet l’hyperconvergeance dès lors que tu as trois noeuds :

  • cluster HA de systèmes invités (LXC ou KVM)
  • cluster de stockage (Ceph)

Comme je le disais tout à l’heure, ça nécessite des serveurs un peu plus costauds, mais ça permet d’être vraiment peinard.

Pour résumer en quelques mot Ceph : mirroring de blocks à travers le réseau via multicast.

Alors attention, Ceph oui Cephfs c’est droit dans le mur pour ma part, et pour faire du Ceph faut bien préparer son truc, la façon dont Proxmox empaquette le cadeau n’est clairement pas super safe en cas de crash, c’est tout ce que je dit.

Demandez à OVH ce qu’il pense d’un crash des serveurs de journaux sur un gros nœud Ceph :zipper_mouth_face:

En fait j’ai vu le fait que l’hyperviseur puisse voir l’intégralité des processus conteneur comme un avantage qui me perméterais d’avoir une vision global de l’état de la consomation des ressources sur la machine et de faire du monitoring à l’échel de tout les système.

J’ai lu en digonal (j’approndirais plus tard pas trop le temp la) mais il est bien sujet de la possibilité d’utiliser proxmox sur de l’ARM, certain semble avoir pour projet de faire des truc avec des Odroid : https://forum.proxmox.com/threads/arm-future-of-proxmox.37991/ . A envisager avec LXC si proxmox n’est pas trop grourmand en ressource.

La ça m’interaisse beaucoup, j’ai pas eu le temps de trop me documenté car je travail actuellement sur autres chose mais si je ne me trompe pas, c’est le Swarm mode de Docker qui permet cela ? Niveau puissance un Pine64-lts sufirair pour géré l’éssaim ? On a pas des besoin un puissance ni en stockage élevé et de toutes façon nous disposons de peut de moyens pour le moment. Ici pas de gros cloud, de toutes façons les seul connections internet que nous pouvons éspérer disposer se sont des connection ADSL avec environs du 8Mbit/s un upload. Pour le stockage je comptais sur un module emmc 64bit sur un pine64-lts comme celuis ci http://files.pine64.org/doc/datasheet/pine64/FORESEE_eMMC_NCEMBSF9-xxG%20SPEC%20A0%2020150730.pdf, ainsi chaque nouveau pine64 ajouté augmanterais la cappacité de stockage en même temps que la quantité de services hébergable (en vrais je supose beaucoup de chose car dans le fait je n’ai à ce point la pas trop concience de ce que cela impliquerait). Il fait aussi limité la conssomation éléctrique du tout affin que nous puission disposer d’un système d’ailimentation sans intéruption qui tienne le coup sans nous ruinner (de ce coté un NAS avec 2 HHD en raid1 serais vraiement un PB ?).

Que veut tu dire par la ?

Oui en effet, je pense aussi que c’est du aux nombreux fails des début du système de fichier, mais il continus d’évoluer et faut bien en faire l’expérience de temps en temps voir s’il en vaut le coup.

Je connais pas Ceph, mais ça semble un peut disproportionné pour notre projet non ?

En tout cas merci pour ces quelques piste de réflexion a travaillé.

Attention à la confidentialité…

A mon avis, il faudrait déjà pouvoir acheter/louer des serveurs ARM à titre personnel avant de voir arriver cette version.

Proxmox en lui-même ne consomme pas grand chose, voir rien du tout.

Disons qu’il est loin de pouvoir remplacer ZFS pour le moment et pourtant c’est son unique intérêt.

Ça coute du disque dur, mais de toute façon, il faut bien stocker les données quelque part… C’est une solution simple et pas cher de regrouper puissance de calcul et stockage tout en ayant une tolérance de panne.

1 J'aime

Oui je suis d’accord. Ce serait bien de trouver une autre solution.

Message d’un des développeurs de Proxmox sur leur forum dédié :

"We have already an ARM version of Proxmox VE.
One reason why we did not publish it yet, is the limited availability of suitable server hardware and the use case." (9 novembre 2017)

Quelqu’un a-t-il une idée de sa gourmandise en ressources ? J’avais trouvé cette solution très intéressante mais je n’ai pas encore trouvé d’infos claires sur sa conso.

1 J'aime