Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Le 02/12/20 à 16h41, Yann Pretot a écrit : > Hello Daniel, > > AWS fait ça dans Glacier avec les Vault Locks. Tu peux définir une > politique de conservation pour une durée donnée, et tant qu’elle n’expire > pas, rien ni personne ne peut supprimer le contenu de tes archives. > > La FAQ donne un bon premier aperçu du fonctionnement : > https://aws.amazon.com/glacier/faqs/?nc1=h_ls#Vault_Lock Merci Yann. À voir comment implémenter ça coté client, mais ça semble pas si compliqué - créer un coffre-fort https://docs.aws.amazon.com/amazonglacier/latest/dev/creating-vaults-cli.html - envoyer dedans des fichiers chiffrés https://docs.aws.amazon.com/cli/latest/reference/glacier/upload-archive.html - verrouiller le coffre-fort https://docs.aws.amazon.com/cli/latest/reference/glacier/initiate-vault-lock.html https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-access-policy.html https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock-policy.html https://docs.aws.amazon.com/cli/latest/reference/glacier/complete-vault-lock.html Reste à voir la gestion de la durée de vie, pas vu si on devait mettre le TTL sur le vault ou sur chaque archive qu'on envoie dedans, mais ça doit pas être si compliqué (dans les exemple trouvés on interdit l'effacement pendant une durée mais ensuite faut le lancer). Sur https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html et https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock-policy.html ils expliquent comment verrouiller les droits d'accès du vault, mais ça parle pas d'expiration et suppression automatique. Par ailleurs, d'après ce que je comprends, si le propio du compte aws arrête de payer ça supprime tout (mais ça c'est le cas partout). Reste à demander à ceux qui se disent "S3 compliant" s'ils implémentent tout ça (pas sûr, S3 ≠ S3 glacier), et choisir le presta. -- Daniel L’arithmétique, c’est être capable de compter jusqu’à vingt sans enlever ses chaussures. Walt Disney ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Le 02/12/20 à 17h11, Rémy Dernat a écrit : > Bonjour, > > Dans le genre vraiment pas cher, vous avez aussi mega.nz : > https://mega.nz/pro > > De mon point de vue, pas vraiment pro, mais si tu chiffres bien, ça ne > devrait pas poser problème... Oui, de toute façon c'est chiffré (je ne fais pas confiance non plus à Google ou Amazon), mais ici ça semble prévu pour de la synchro façon dropbox, je vois pas où est le coté immutable que je cherchais. J'ai raté un truc ? -- Daniel La paresse c'est se lever à six heures du matin, pour avoir plus de temps à ne rien faire. Tristan Bernard ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Bonjour, Dans le genre vraiment pas cher, vous avez aussi mega.nz : https://mega.nz/pro De mon point de vue, pas vraiment pro, mais si tu chiffres bien, ça ne devrait pas poser problème... Cdlmt Le 02/12/2020 à 16:53, Daniel Caillibaud a écrit : Le 02/12/20 à 9h03, Joël DEREFINKO a écrit : Pour du pur backup, il y a rsync.net qui a une offre qui semble correspondre au besoin (de mémoire : WORM) https://rsync.net/ Transfert des datas vers leur « cloud » avec les outils standards (rsync, sftp, scp, rclone, …) Ça c'est cool, car mon client de prédilection c'est justement rsync, c'est l'avantage du block storage. Mais avec cette solution seuls les snapshots sont immutables (donc max j-7 si < 10To, et j-21 si > 10To). Depuis mon host de backup, je voudrais chaque mois - archivage (avec tar + compression + chiffrement), probablement N archives pas trop grosses plutôt qu'une seule de 2To - envoi vers un stockage immutable en précisant un TTL de 3 à 6 mois, si ça peut être fait avec rsync directement c'est un gros plus (vs api et object storage) Par défaut rsync.net propose les 7 snapshots daily et 4 weekly, mais on peut en ajouter (moyennant de payer alors l'espace occupé). Ça semble le plus adapté à mon besoin, et le plus simple à mettre en place (un rsync mensuel qui va écraser le précédent, les backups des mois précédents sont dans des snapshots custom). Pour du stockage block le tarif est pas choquant (ovh block storage est 2× plus cher), mais pour ce que j'en fait ça fait quand même cher : 20$/To/mois Avec 3.3To envoyés par mois à conserver 3mois, ça fait 10To de stockage en permanence (et 3.3To de trafic entrant), ce qui donne les tarifs mensuels - rsync.net 200$ [1] - GCS (coldline) 40$ [2] - backblaze b2: 50$ [3] - AWS S3 glacier 40$ [4] - wasabi 60$ [5] Et des solutions plus bancales : - scaleway C14 cold storage:20€ [6] - ovh cold storage: 50€ [7] (20€ stockage + 30€ dépôt) À voir à quel point c'est bancal, mais on dirait qu'il faut bidouiller pour rendre ça immutable, par ex avec des droits provisoires à gérer manuellement avant chaque envoi. Et dans tous les cas c'est pas vraiment immutable, car le proprio du service peut toujours supprimer les contenus. Je suis d'ailleurs étonné que personne ne propose de vrai immutable, on paie lors du dépôt pour toute la durée de conservation voulue et ça peut plus jamais être modifié (même si le proprio voulait, ou s'il oublie de renouveler le service). Les tarifs [1] https://www.rsync.net/pricing.html [2] https://cloud.google.com/storage/pricing?hl=fr#storage-pricing [3] https://www.backblaze.com/b2/cloud-storage-pricing.html [4] https://aws.amazon.com/fr/s3/pricing/ [5] https://wasabi.com/cloud-storage-pricing/ [6] https://www.scaleway.com/fr/tarifs/#c14-cold-storage [7] https://www.ovhcloud.com/fr/public-cloud/prices/#473 Suivant les solutions y'a un coût +/- élevé pour récupérer les datas, mais vu la très faible proba d'en avoir un jour besoin j'ai ignoré cet aspect (c'est du backup de backup). ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Le 02/12/20 à 9h03, Joël DEREFINKO a écrit : > Pour du pur backup, il y a rsync.net qui a une offre qui semble > correspondre au besoin (de mémoire : WORM) https://rsync.net/ > > Transfert des datas vers leur « cloud » avec les outils standards (rsync, > sftp, scp, rclone, …) Ça c'est cool, car mon client de prédilection c'est justement rsync, c'est l'avantage du block storage. Mais avec cette solution seuls les snapshots sont immutables (donc max j-7 si < 10To, et j-21 si > 10To). Depuis mon host de backup, je voudrais chaque mois - archivage (avec tar + compression + chiffrement), probablement N archives pas trop grosses plutôt qu'une seule de 2To - envoi vers un stockage immutable en précisant un TTL de 3 à 6 mois, si ça peut être fait avec rsync directement c'est un gros plus (vs api et object storage) Par défaut rsync.net propose les 7 snapshots daily et 4 weekly, mais on peut en ajouter (moyennant de payer alors l'espace occupé). Ça semble le plus adapté à mon besoin, et le plus simple à mettre en place (un rsync mensuel qui va écraser le précédent, les backups des mois précédents sont dans des snapshots custom). Pour du stockage block le tarif est pas choquant (ovh block storage est 2× plus cher), mais pour ce que j'en fait ça fait quand même cher : 20$/To/mois Avec 3.3To envoyés par mois à conserver 3mois, ça fait 10To de stockage en permanence (et 3.3To de trafic entrant), ce qui donne les tarifs mensuels - rsync.net 200$ [1] - GCS (coldline) 40$ [2] - backblaze b2: 50$ [3] - AWS S3 glacier 40$ [4] - wasabi 60$ [5] Et des solutions plus bancales : - scaleway C14 cold storage:20€ [6] - ovh cold storage: 50€ [7] (20€ stockage + 30€ dépôt) À voir à quel point c'est bancal, mais on dirait qu'il faut bidouiller pour rendre ça immutable, par ex avec des droits provisoires à gérer manuellement avant chaque envoi. Et dans tous les cas c'est pas vraiment immutable, car le proprio du service peut toujours supprimer les contenus. Je suis d'ailleurs étonné que personne ne propose de vrai immutable, on paie lors du dépôt pour toute la durée de conservation voulue et ça peut plus jamais être modifié (même si le proprio voulait, ou s'il oublie de renouveler le service). Les tarifs [1] https://www.rsync.net/pricing.html [2] https://cloud.google.com/storage/pricing?hl=fr#storage-pricing [3] https://www.backblaze.com/b2/cloud-storage-pricing.html [4] https://aws.amazon.com/fr/s3/pricing/ [5] https://wasabi.com/cloud-storage-pricing/ [6] https://www.scaleway.com/fr/tarifs/#c14-cold-storage [7] https://www.ovhcloud.com/fr/public-cloud/prices/#473 Suivant les solutions y'a un coût +/- élevé pour récupérer les datas, mais vu la très faible proba d'en avoir un jour besoin j'ai ignoré cet aspect (c'est du backup de backup). -- Daniel L'argent aide a supporter la pauvreté. Alphonse Allais ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
> Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas exactement 33% > des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on > se retrouve potentiellement avec des écritures bloquées sur une partie > du cluster. Il y a peut être des cas particuliers avec la configuration, mais je n'ai jamais vu cette situation. Que ce soit en coupant 1 osd d'un cluster de 3 osd, ou un rack d'un cluster de trois racks. En effet un serveur aura plus ou moins d'un tiers des PG, mais tous les PG auront 2 copies donc le cluster acceptera les lectures/écritures. > On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui > démarre à froid (coupure courant de nuit dans une entreprise malgré > l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort > (l'équipe sur place faisait une maintenance sur les disques la veille) > refuse de démarrer et donc tu ne peux pas faire repartir. Difficile à analyser sans avoir les logs, mais si le cluster était en bonne santé au moment de l'arrêt ce n'est pas normal. Mais il arrive que Ceph fasse des choses surprenantes. Étienne ‐‐‐ Original Message ‐‐‐ On Wednesday, December 2nd, 2020 at 4:05 PM, Stéphane Rivière wrote: > > Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément > > nécessaires, ni une bonne idée. > > Je n'utilise pas CEPH. Voilà le notes que j'avais pris à l'époque. > > Aucune idée de la pertinence. Ces colistiers ont du vécu :) Leurs > > messages m'ont semblé assez clairs. > > J'en avais conclu que c'était super mais nécessitait une certaine > > "aisance" et, qu'en attendant, on continuerai avec DRBD... > > Laissé les emails : les archives sont publiques et ça permet de les > > contacter pour des précisions... > > 1 Architecture > > rich...@demongeot.biz : CEPH étant (massivement) distribué, il devient > > de plus en plus performant avec le volume de disques que tu lui > > affectes. Selon la documentation, le minimum préconisé est de faire "3 > > copies", sur "3 machines différentes". > > CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de > > raid sur les disques. > > Setup standard CEPH : > > +--+ +--+ +--+ > > | Hôte1 | | Hôte2 | | Hôte3 | > > | HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 | > > +--+ +--+ +--+ > > Ton premier bloc sera sur les disques 1, 3 et 5; > > Ton second sur les disques 2, 4 et 5; > > Etc. CEPH s’amusera à les placer différemment à chaque fois. > > Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la > > fragmentation va te faire perdre en performance vis à vis de DRBD. > > Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va > > pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu > > rajoutes de disque, plus ta performance s'améliore :). > > 2 Algorithme > > frsag@frsag.org : Question de précision de l'algorithme de répartition > > des blocs de données (PG en langage ceph). Le manque de précision est du > > a une optimisation pour trouver plus rapidement le lieu ou est stocké le > > PG, du coup il y a une variation de quelques pourcents (voir dizaine) > > entre la quantité de données sur chaque disque. > > Les paramètres recommandés sont : 3 replicas, 2 nécessaires pour activer > > les écritures. > > Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas exactement 33% > > des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on > > se retrouve potentiellement avec des écritures bloquées sur une partie > > du cluster. > > D’où le 4 pour avoir une marge de manœuvre. > > 3 Incident > > wall...@morkitu.org : Ceph sur trois noeuds dans le moule Proxmox, ça > > marche quand tout est ok. Si tu perds un nœud le quorum en prend un coup > > comme pour Proxmox mais ça passe. > > On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui > > démarre à froid (coupure courant de nuit dans une entreprise malgré > > l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort > > (l'équipe sur place faisait une maintenance sur les disques la veille) > > refuse de démarrer et donc tu ne peux pas faire repartir. > > Proxmox dans ce cas on peut toujours dire tel host a un point plus grand > > pour le quorum et/ou baisser le nombre de voix de chaque membre ça passe. > > Ceph on a pas trouvé et la seule façon a été de reconfigurer le cluster > > pour demander une réplication sur 2 noeuds au lieu de 3. Du coup gros > > travail de Ceph qui a bien saturé ses liens pendant 3 jours mettant des > > perfs assez faibles pour les vms. > > >
Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Le 01/12/20 à 21h48, Benoit Garcia a écrit : > > J'ai regardé toutes les offres de type glacier, y'a rien qui répond à > > ça, le proprio du service ou celui qui a les droits en écriture peut > > toujours effacer le contenu. > > > > Vous connaissez qq chose qui répondrait à ce besoin ? > AWS S3 supporte le versionning de fichiers. > A chaque fois qu'un fichier est écrit, S3 écrit une nouvelle version. > Lorsque un fichier est effacé, les anciennes versions sont conservées. > Pour effacer entièrement un fichier, il faut commencer par suspendre le > versionning avant la suppression. > Un utilisateur peut avoir des droits en écritures, sans avoir les droits > de suspendre le versionning. > > Si Scaleway supporte cette fonctionnalité, est-ce que cela ne pourrait pas > te suffire? Si, ça pourrait, mais j'ai pas vu comment faire ça chez eux. Je vais poser la question au support, leur doc est vraiment minimaliste. Pour backblaze, ça semble possible de générer une clé qui n'aurait que le droit writeFiles sur un seul bucket, et apparemment envoyer de nouveau le même fichier créerait une nouvelle version https://www.backblaze.com/b2/docs/application_keys.html En fixant un TTL sur chaque fichier à l'envoi, je suppose que ça s'applique à la version créée et que les anciennes versions expirent toute seule (sinon faudra que j'ajoute un suffixe unique par fichier) Dans ce cas le seul moyen d'effacer qqchose est de passer par le compte proprio du service (si on pouvait blinder ça aussi ce serait mieux mais c'est déjà pas mal). -- Daniel Ce n'est pas en continuant de faire ce que l'on connait que l'on pourra faire ce que l'on ne connait pas. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
> Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? C'est principalement pour avoir moins de chances de perdre des données. Mais également, le problème de n'avoir que 2 fois la donnée c'est qu'en cas d'inconsistance ( si l'une des copie de l'objet change) tu ne sauras pas dire quelle version est la bonne. Tu vas devoir corriger en espérant que ce soit bien la primaire qui soit correcte. Au passage si c'est pour des raisons de coûts, si tu as beaucoup de disques tu peux tester l'erasure coding, ça fonctionne aussi sur rbd et cephfs depuis quelques versions. > En fait, cela dépend fortement de l'interconnexion entre les nœuds : si > ils sont répartis par deux dans deux racks différents avec interco > simple, le risque de perdre le quorum est très important. Il vaut mieux > en avoir 3 dans ce cas. > En revanche, dans un même rack avec deux switchs différents en > redondance, trois ou quatre ne change rien, si ce n'est dans la > provision des disques pour éviter d'arriver à 100% d'occupation en cas > de rebalance à la suite de la perte d'un nœud. Même pour les monitors je pense que 2 est une prise de risque, on ne sait jamais ce qui peut arriver. Étienne ‐‐‐ Original Message ‐‐‐ On Wednesday, December 2nd, 2020 at 3:51 PM, Julien Escario wrote: > Le 02/12/2020 à 15:20, Etienne Menguy a écrit : > > > Hello, > > > > Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te > > conseille d'avoir 3 OSD (sur 3 disques différents) et la triple réplication. > > > > Ca permettra d'assurer la consistance des données et de ne pas en perdre. > > Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? Ou alors c'est > > simplement le même argument que pour le RAID6 vs RAID5 : plus de > > redondance, c'est plus de sécurité. > > Parce qu'avec un "size=2" sur trois disques, la perte d'un OSD (aka un > > disque) n'est pas un soucis tant que le rebalance peut se faire. > > J'essaie juste de faire le tour des contraintes, histoire de savoir dans > > quoi je m'embarque si je pousse une idée aussi farfelue en prod un jour. > > > D'un point de vue technique ça fonctionnera sans problème, ceph se moque de > > savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs. > > > > Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé > > pour. > > > > Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément > > nécessaires, ni une bonne idée. > > En fait, cela dépend fortement de l'interconnexion entre les nœuds : si > > ils sont répartis par deux dans deux racks différents avec interco > > simple, le risque de perdre le quorum est très important. Il vaut mieux > > en avoir 3 dans ce cas. > > En revanche, dans un même rack avec deux switchs différents en > > redondance, trois ou quatre ne change rien, si ce n'est dans la > > provision des disques pour éviter d'arriver à 100% d'occupation en cas > > de rebalance à la suite de la perte d'un nœud. > > Merci ! > > Julien > > Liste de diffusion du FRsAG > > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
> Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément > nécessaires, ni une bonne idée. Je n'utilise pas CEPH. Voilà le notes que j'avais pris à l'époque. Aucune idée de la pertinence. Ces colistiers ont du vécu :) Leurs messages m'ont semblé assez clairs. J'en avais conclu que c'était super mais nécessitait une certaine "aisance" et, qu'en attendant, on continuerai avec DRBD... Laissé les emails : les archives sont publiques et ça permet de les contacter pour des précisions... 1Architecture rich...@demongeot.biz : CEPH étant (massivement) distribué, il devient de plus en plus performant avec le volume de disques que tu lui affectes. Selon la documentation, le minimum préconisé est de faire "3 copies", sur "3 machines différentes". CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de raid sur les disques. Setup standard CEPH : +--+ +--+ +--+ | Hôte1| | Hôte2| | Hôte3| | HDD1HDD2 | | HDD3HDD4 | | HDD5HDD6 | +--+ +--+ +--+ Ton premier bloc sera sur les disques 1, 3 et 5; Ton second sur les disques 2, 4 et 5; Etc. CEPH s’amusera à les placer différemment à chaque fois. Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la fragmentation va te faire perdre en performance vis à vis de DRBD. Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu rajoutes de disque, plus ta performance s'améliore :). 2Algorithme frsag@frsag.org : Question de précision de l'algorithme de répartition des blocs de données (PG en langage ceph). Le manque de précision est du a une optimisation pour trouver plus rapidement le lieu ou est stocké le PG, du coup il y a une variation de quelques pourcents (voir dizaine) entre la quantité de données sur chaque disque. Les paramètres recommandés sont : 3 replicas, 2 nécessaires pour activer les écritures. Si on n'a que 3 noeuds et qu'on en perd un, on n'a pas *exactement* 33% des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu’on se retrouve potentiellement avec des écritures bloquées sur une partie du cluster. D’où le 4 pour avoir une marge de manœuvre. 3Incident wall...@morkitu.org : Ceph sur trois noeuds dans le moule Proxmox, ça marche quand tout est ok. Si tu perds un nœud le quorum en prend un coup comme pour Proxmox mais ça passe. On a découvert avec douleur qu'un cluster Proxmox trois nœuds qui démarre à froid (coupure courant de nuit dans une entreprise malgré l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un nœud ceph mort (l'équipe sur place faisait une maintenance sur les disques la veille) refuse de démarrer et donc tu ne peux pas faire repartir. Proxmox dans ce cas on peut toujours dire tel host a un point plus grand pour le quorum et/ou baisser le nombre de voix de chaque membre ça passe. Ceph on a pas trouvé et la seule façon a été de reconfigurer le cluster pour demander une réplication sur 2 noeuds au lieu de 3. Du coup gros travail de Ceph qui a bien saturé ses liens pendant 3 jours mettant des perfs assez faibles pour les vms. -- Be Seeing You Number Six ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
> Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou > est-ce que c'est réellement viable ? (en dehors du fait que c'est un > gros hack par rapport à ce pourquoi Ceph est prévu). Aucune idée. Mais SPOF sur le node... mais j'imagine que dans certains cas, ça doit être bien :) DRBD a au moins le mérite de proposer de la migration à chaud, du n TIERS, etc. avec une mise en œuvre qui doit être rigoureuse mais quiest peu coûteuse... -- Be Seeing You Number Six ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
Le 02/12/2020 à 15:20, Etienne Menguy a écrit : > Hello, > > Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te conseille > d'avoir 3 OSD (sur 3 disques différents) et la triple réplication. > Ca permettra d'assurer la consistance des données et de ne pas en perdre. Ah ? Intéressant, tu pourrais ajouter du détail sur ça ? Ou alors c'est simplement le même argument que pour le RAID6 vs RAID5 : plus de redondance, c'est plus de sécurité. Parce qu'avec un "size=2" sur trois disques, la perte d'un OSD (aka un disque) n'est pas un soucis tant que le rebalance peut se faire. J'essaie juste de faire le tour des contraintes, histoire de savoir dans quoi je m'embarque si je pousse une idée aussi farfelue en prod un jour. > D'un point de vue technique ça fonctionnera sans problème, ceph se moque de > savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs. > Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé > pour. > > Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément > nécessaires, ni une bonne idée. En fait, cela dépend fortement de l'interconnexion entre les nœuds : si ils sont répartis par deux dans deux racks différents avec interco simple, le risque de perdre le quorum est très important. Il vaut mieux en avoir 3 dans ce cas. En revanche, dans un même rack avec deux switchs différents en redondance, trois ou quatre ne change rien, si ce n'est dans la provision des disques pour éviter d'arriver à 100% d'occupation en cas de rebalance à la suite de la perte d'un nœud. Merci ! Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
Hello, Si tu veux faire vraiment faire du Ceph sur un seul serveur, je te conseille d'avoir 3 OSD (sur 3 disques différents) et la triple réplication. Ca permettra d'assurer la consistance des données et de ne pas en perdre. D'un point de vue technique ça fonctionnera sans problème, ceph se moque de savoir si tu as 1 ou 50 racks, 1 ou 300 serveurs. Mais c'est forcément une utilisation peu courante et ca n'a pas été pensé pour. Au passage, je ne vois pas pourquoi 4 serveurs seraient forcément nécessaires, ni une bonne idée. Étienne ‐‐‐ Original Message ‐‐‐ On Wednesday, December 2nd, 2020 at 3:10 PM, Julien Escario wrote: > Le 02/12/2020 à 11:33, Stéphane Rivière a écrit : > > > > Pour ma part, je suis encore en mono-server sans HA et j'ai cru > > > > > > comprendre que Ceph sous Proxmox répondait également à ce besoin. Je > > > > CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 > > > > bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud > > > > sur ça par "les gens qui savent" : 3 ne seraient pas assez... > > > > Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très > > > > bien en plus. Mais CEPH est à un autre niveau :) > > Alors, justement. J'ai fais un bout de lab ces derniers jours et Ceph en > > single node, pourquoi pas ? > > Je me suis inspiré de la doc ici pour construire une crushmap adéquate : > > https://linoxide.com/linux-how-to/hwto-configure-single-node-ceph-cluster/ > > Et ça fonctionne. > > Maintenant, on peut s'interroger sur l'intérêt. Mon use-case était de > > pouvoir mettre en place une réplication asynchrone avec rbd-mirror. Pas > > grand chose de plus que ce qu'offrirait un zfs send/receive finalement. > > Mais on peut trouver beaucoup d'autres avantages : accès à cephfs, rados > > gateway (S3), rbd-diff pour le backup, le dashboard/export prometheus de > > ceph-mgr, etc ... > > Et il reste toujours la possibilité d'évoluer vers plus cossu dans le > > futur (en évitant soigneusement d'avoir un cluster à deux nœuds, il faut > > passer tout de suite à 3). > > En réalité, on est dans un cas de RAID en userspace avec une tonne de > > fonctionnalités additionnelles. Le système survivra sans problème à la > > perte d'un disque et le fonctionnement de Ceph intègre nativement la > > notion de hot-spare, pas toujours trivial à faire avec mdadm. > > Bref, on est pas dans un scénario de haute-dispo mais l'apport en > > fonctionnalités de Ceph est quand même un gros plus par rapport à mdadm > > ou ZFS. > > Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou > > est-ce que c'est réellement viable ? (en dehors du fait que c'est un > > gros hack par rapport à ce pourquoi Ceph est prévu). > > Merci, > > Julien > > Liste de diffusion du FRsAG > > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Single node Ceph (Was: Re: Proxmox 6.3-2 et Pool LVM-Thin)
Le 02/12/2020 à 11:33, Stéphane Rivière a écrit : >> Pour ma part, je suis encore en mono-server sans HA et j'ai cru >> comprendre que Ceph sous Proxmox répondait également à ce besoin. Je > > CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 > bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud > sur ça par "les gens qui savent" : 3 ne seraient pas assez... > > Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très > bien en plus. Mais CEPH est à un autre niveau :) Alors, justement. J'ai fais un bout de lab ces derniers jours et Ceph en single node, pourquoi pas ? Je me suis inspiré de la doc ici pour construire une crushmap adéquate : https://linoxide.com/linux-how-to/hwto-configure-single-node-ceph-cluster/ Et ça fonctionne. Maintenant, on peut s'interroger sur l'intérêt. Mon use-case était de pouvoir mettre en place une réplication asynchrone avec rbd-mirror. Pas grand chose de plus que ce qu'offrirait un zfs send/receive finalement. Mais on peut trouver beaucoup d'autres avantages : accès à cephfs, rados gateway (S3), rbd-diff pour le backup, le dashboard/export prometheus de ceph-mgr, etc ... Et il reste toujours la possibilité d'évoluer vers plus cossu dans le futur (en évitant soigneusement d'avoir un cluster à deux nœuds, il faut passer tout de suite à 3). En réalité, on est dans un cas de RAID en userspace avec une tonne de fonctionnalités additionnelles. Le système survivra sans problème à la perte d'un disque et le fonctionnement de Ceph intègre nativement la notion de hot-spare, pas toujours trivial à faire avec mdadm. Bref, on est pas dans un scénario de haute-dispo mais l'apport en fonctionnalités de Ceph est quand même un gros plus par rapport à mdadm ou ZFS. Maintenant, est-ce que d'après vous j'ai loupé un truc dans le setup ou est-ce que c'est réellement viable ? (en dehors du fait que c'est un gros hack par rapport à ce pourquoi Ceph est prévu). Merci, Julien ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?
Le 01/12/20 à 21h53, Kevin LABECOT a écrit : > De mon côté la même mais avec Backblaze et niveau tarif il n’y a pas > mieux pour moi. Pour du backup/archivage c’est le must à mon sens. Sauf que pour l'immutable il faut utiliser un client veam, c'est visiblement la seule solution. -- Daniel Il est intéressant de voir que les gens qui se moquent de la science fiction se fient à la météo et aux économistes Kevin Throop III ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Effectivement, bon faut que je cible une sacrée réussite alors :D Voici ce que j'ai fait (uniquement sur data2cold pour l'instant) : - Augmenter encore la taille du metadata : lvextend --poolmetadatasize +224M v2cold/data2cold - Eteindre toutes les VM et containers utilisant le Thinpool - Désactiver le pool : lvchange -an v2cold/data2cold - Désactiver les Thin de ce pool : lvchange -an /dev/v2cold/* - Effectuer ensuite un "lvconvert --repair v2cold/data2cold" - Réactiver le pool : lvchange -ay v2cold/data2cold - Réactiver les Thin de ce pool : lvchange -ay v2cold - Redémarrer les VM et containers correspondants A priori, tout fonctionne ! \o/ Je vais attendre quelques jours avant d'attaquer les deux autres pool (soit le prochain full backup + weekend pour gérer l'interruption de service) Bonus PROXMOX : Pour identifier les anciens LV entre proxmox et les VM (oui j'ai oublié de les identifiés et avec deux LV de même taille, je ne savais plus lequel supprimer ^^), j'ai fait dans la VM : lsblk -o +SERIAL Cela renvoie en SERIAL par défaut : drive- (ex : drive-scsi2) Oui ! Proxmox rajoute un serial par défaut sur chaque disque... pratique non ? (moi je viens tout juste de le découvrir ^^) Encore merci pour vos aides ! Pidroid ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
> @Stéphane > > Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il > s'agissait) Imho, ce fut génial, ça l'est encore dans certains cas. Pas pour notre use-case. > C'est intéressant comme approche votre gestionnaire de cluster (et ca > m'éclaire un peu plus sur le fonctionnement et rôle des metas) Ben dès que t'as du DRBD, mais que tu veux laisser l'humain en priorité et refuser l'automagie "pacemaker/corosync"... Pas trop le choix. Sinon des scripts pour monter et descendre proprement les nodes (ce qu'on faisait jusqu'à présent)... Et laisser l'humain faire le reste. Ganeti nous a inspiré. Ce que l'on code est mille fois plus simple à utiliser mais limité à notre use-case GNU/Linux Debian Xen LVM DRBD. > Pour ma part, je suis encore en mono-server sans HA et j'ai cru > comprendre que Ceph sous Proxmox répondait également à ce besoin. Je CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud sur ça par "les gens qui savent" : 3 ne seraient pas assez... Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très bien en plus. Mais CEPH est à un autre niveau :) -- Be Seeing You Number Six ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Salut, Merci pour ces retours ainsi que toutes ces explications ! Ça me rassure énormément :) @Johann > Tu as une solution pour résoudre le soucis du pmspare qui n'a plus la bonne taille : > - Éteint toute tes VM utilisant le thinpool > - Démonte tout ce qui tape dedans > - Effectue ensuite un "lvconvert --repair v2cold/data2cold" > > [...] Elle est top cette procédure et les explications qui vont avec aussi :) Merci ! Je vais faire progressivement mes 3 thinpool en commencant par le moins sensible : data2cold > > augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold > Je pense que c'était superflu, d'après ton lvs -a, tu n'utilise que ~52% de data sur les 11.3T que tu as maintenant. > Sauf si ce message était dû au fait que tu as réservé plus que les 11T sur l'ensemble des LV thin de tes VM? > Si c'est le cas, à toi de voir, si tu ne penses jamais utiliser tous les disques au maximum... Après si tu préfères la sécurité et que ta la capacité disponible! Effectivement, n'étant pas trop sûr de ce que je faisais, j'ai laissé les anciens LV Thin au cas où... Bien que je n'utilise que ~52%, j'ai probablement dépassé les 11T de provisionné. Vais pouvoir attaquer le ménage bientôt :) > > J'ai tenté de calculer la taille des metadata avec la formule / * 64 > Effectivement c'est une bonne technique, j'avais dû la voir à une époque mais elle m'était sortie de la tête. > Même si avec ces calculs je trouve le double de ceux que j'aurais en vrai si je suis mon utilisation actuelle. > Je ne sais pas si je suis fatigué et raté quelque chose, possible... Soit un détail m'échappe dans le calcul. Après ça vaut mieux trop que pas assez. > Mais n'oublie pas que cela serait les valeurs maximum théorique utilisées et pas l'utilisation actuelle. Mais tu tombes comme moi sur une valeur supérieure à la réalité. Arf... j'aurai du rajouter la visu pour data0hot et data1middle dans le "lvs -a" et ce dernier est d'ailleurs réalisé a posteriori de la "réparation" (j'aurai du le préciser) data0hot (taille 930G, chunk 512K) : - calculé : 122 Mo - constaté : 120 Mo avec pour usage Data%=64.23 et Meta%=88.02% data1middle (taille 1,64T, chunk 1M) : - calculé : 111 Mo - constaté : 108 Mo avec pour usage Data%=3,02% et Meta%=11,93% Je me suis peut être trompé dans mes calculs. Mais comme tu le précises bien, autant voir large surtout qu'on n'est pas sur les mêmes ordres de grandeur entre Data et Meta > > J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...) > J'ai testé, cela marche pas trop mal, si tu dépasse le thin_pool_autoextend_threshold% d'utilisation des meta, cela augmente de thin_pool_autoextend_percent% celui-ci. > Mais je me suis retrouvé avec un cas étrange où cela augmente le tmeta mais pas le pmspare. > Je ne sais pas si c'est volontaire, un bug, un souci de configuration de mon côté. Ah ok, du coup j'élimine cette option. Merci. > Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais. Avec l'absence de backup hors-site, j'ai actuellement 3 duplication de backups sur site (ressource2cold... pas top ^^, un sur SoC et un autre sur mon LAB) et je refuse tout crash de météorite, inondation ou incendie sur ces prochains jours (et ceux d'après aussi :P ) @Stéphane Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il s'agissait) C'est intéressant comme approche votre gestionnaire de cluster (et ca m'éclaire un peu plus sur le fonctionnement et rôle des metas) Pour ma part, je suis encore en mono-server sans HA et j'ai cru comprendre que Ceph sous Proxmox répondait également à ce besoin. Je m'orienterai probablement vers ce dernier si l'occasion (donc la réussite ^^) se présente. Encore merci à vous, c'est un grand soulagement de savoir que cet incident sera très prochainement clôturé et que j'en ressors grandi... A+ Pidroid ___ Liste de diffusion du FRsAG http://www.frsag.org/
