Re: [FRsAG] cold backup, vous connaissez du "vrai" glacier ?

[alexandre derumier]

Pour du stockage object, en opensource, ceph supporte le worm sur sa 
gateway rados (protocol s3),

depuis la version ceph nautilus

https://www.youtube.com/watch?v=syLFh3JAbJ4


j'en suis pas certain à 100%, mais il me semble que scaleway utilise 
ceph pour son stockage objet également

https://www.scaleway.com/en/docs/s3-object-lock/


On 01/12/2020 17:50, Daniel Caillibaud wrote:

Salut,

Je rebondis sur le post de pidroid qui parle de la fin de vie de C14.

Je suis aussi affecté par cette suppression de service que le "remplaçant"
ne remplace pas :-/

Je cherche une solution de stockage avec "quand un fichier est écrit (avec
un TTL) il n'est plus jamais modifiable" (même par le proprio du service).

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 ?

Merci




PS: la version longue du besoin

J'ai
- des hosts de prod
- un host de backup

Le backup peut lire la prod, certaines vm de prod peuvent lire le backup,
mais personne peut écrire chez l'autre.

Le seul point faible c'est moi :
- même avec des clés ssh distinctes, j'ai quand même accès aux deux (et
   peut donc potentiellement tout effacer)
- c'est le même nic-ovh pour tout le monde (parce que c'était plus simple,
   et séparer ne suffisait pas à sécuriser à cause du point précédent)

J'utilisais donc C14 comme backup "write only", le host de backup pouvait
écrire sur C14 mais ensuite il ne pouvait plus modifier ce qu'il avait
déjà écrit, donc en cas de corruption de la prod ET du backup on
avait encore accès à un backup clean (le dernier push vers C14 avant
corruption).

C'était pas génial, car ça demandait à une tierce personne de m'ouvrir
manuellement un conteneur sur C14 avant chaque push, mais au moins ça
sécurisait un peu.

La nouvelle offre online ne fonctionne plus de la même manière, si on peut
écrire on peut aussi effacer.

Y'a eu une annonce d'Octave disant qu'Ovh allait proposer ça pour sept
2021 : tu envoie un zip en cold backup avec telle durée de vie et une fois
stocké il est plus jamais modifiable jusqu'à ce qu'il soit automatiquement
effacé en fin de vie.

C'est exactement ce qu'il me faut, mais ça m'ennuie de tourner 9 mois
(voire plus si la date est repoussée) avec ceinture mais sans bretelle.



___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Quel orchestrateur KVM choisir ?

[alexandre derumier]

On 13/11/2020 19:15, Daniel Caillibaud wrote:

- proxmox : la doc est pas mal, commandes cli claires, j'ai une vm qui boot
   mais je réalise qu'avec un storage lvm-thin je peux pas monter son
   filesystem sur le host, je me suis arrêté là.

Le montage du lvm sur le host, c'est ce qui me permet du backup incrémental
avec plein de snapshots sur le serveur de backup (j-1, j-2, …,
month-12, merci btrfs), ne pas avoir ça serait une vraie galère (doubler
toute la procédure de backup/snapshots, car j'ai encore des hosts en
stretch/lxc2).


proxmox vient de sortir une nouvelle solution de backup (proxmox backup 
server = pbs)


https://pbs.proxmox.com/wiki/index.php/Main_Page

nouveauté, les incrementales pour qemu (sans snapshots disques, ca track 
un bitmap dans le process qemu directement, donc ca marche avec 
n'importe quel stockage), et lxc également.


c'est vraiment bien foutu, un seul backup full, et des incrementales à 
vies. (ensuite, dans pbs, il  a un systeme de tracking de block, de  
purge automatique, checkum des backups, etc...)




___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox avec gros uptime = problèmes ?

[Alexandre DERUMIER]

>>(ce qui arrivait au bout 
>>d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne). 

497 jours d'uptime, fixé dan la version 3.2 ^_^

https://git.proxmox.com/?p=pve-common.git;a=commit;h=19cec2309dad9487a2fc0a679c1a2b9d9995c4ba


- Mail original -
De: "Julien Escario" 
À: "French SysAdmin Group" 
Envoyé: Lundi 28 Septembre 2020 09:14:48
Objet: Re: [FRsAG]  Proxmox avec gros uptime = problèmes ?

Le 25/09/2020 à 19:53, Wallace a écrit : 
> On est vendredi je me permet, tu insinues que la méthode DDR (Dans le 
> Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D 

On est lundi mais je confirme : notamment pour la fameux bug qui 
empêchait les timestamp des tasks sur X bytes (ce qui arrivait au bout 
d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne). 

La solution, c'était bien DDR (ou patch du bout de code Perl qui gérait 
ça + restart pvemanager). 

Julien 
___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox avec gros uptime = problèmes ?

[Alexandre DERUMIER]

>>En quoi le quorum est-il critique dans ce cas ?

tu as besoin du quorum pour les moniteurs. (3 moniteurs donc).

size = 2, min size = 1  -> c'est pour les osd uniquement.


en gros, avec 2 monitor, si tu en as un qui est down, tu perd le quorum : le 
cluster passe en readonly

c'est pour eviter les split-brains.

les clients, ainsi que les osd sont connectés en permanence aux monitors pour 
voir l'etat du cluster, 
avoir la map avec les osd down/up, pour injecter tout ca dans l'algo crush pour 
savoir où lire et ecrire.  
Imagine le bordel si la moitié des clients/osd voient 1 monitor, et l'autre 
moitié l'autre monitor.





- Mail original -
De: "Julien Escario" 
À: "French SysAdmin Group" 
Envoyé: Dimanche 20 Septembre 2020 21:49:40
Objet: Re: [FRsAG]  Proxmox avec gros uptime = problèmes ?

Le 18/09/2020 à 11:22, Grosjean Cyril a écrit : 
> Le ven. 18 sept. 2020 à 11:11, Pierre DOLIDON  > a écrit : 
> 
> de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un 
> cluster... quorum toussa toussa). 
> 
> 
> ll faut 3 noeuds pour les monitors/managers, mais ton 3ème noeud pour 
> les monitors/manager peuvent être sur un autre site, en standalone (un 
> peu comme un arbitre dans un SAN bi-site synchrone). 
> Le cluster d'OSD, si bien configuré peut supporter la perte d'un noeud. 

Pas mal de retours intéressants sur cette question de Ceph avec deux 
noeuds. Je voulais justement faire un lab pour voir ce que ca donne en 
remplacement d'un cluster DRBD avec deux noeuds. 

En 'théorie', avec deux nodes, quatre OSD (deux sur chaque node), deux 
mon+mgr (un sur chaque node), size = 2, min size = 1. 

En gros, un RAID over Ethernet puisque chaque PG sera sur chaque node. 

Si on perd TOTALEMENT un node : pas d'impact, et rebalance au 
redémarrage du node H.S 

Si on perd le réseau entre les deux (c'est toujours le scenario 
stressant) : il se passe quoi exactement ? 

En partant du principe que chaque VM a ses propres objects (aka blocks) 
: je ne vois pas pourquoi il y aurait plus grave comme soucis qu'un 
resync au moment où le réseau revient ? 
En quoi le quorum est-il critique dans ce cas ? 

Je n'ai pas osé le test encore, je suis peut être complètement à côté de 
la plaque ... 

Merci de vos lumières, 
Julien 
___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox avec gros uptime = problèmes ?

[Alexandre DERUMIER]

>>D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : 
>>il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid 
>>pour les intrépides). 

tu es certain ?

https://git.proxmox.com/?p=pve-installer.git;a=commit;h=e1b490865f750e08f6c9c6b7e162e7def9dcc411

- Mail original -
De: "Julien Escario" 
À: "French SysAdmin Group" 
Envoyé: Dimanche 20 Septembre 2020 21:41:16
Objet: Re: [FRsAG]  Proxmox avec gros uptime = problèmes ?

Le 18/09/2020 à 20:49, David Ponzone a écrit : 
> Au passage, j’ai découvert un truc important aujourd’hui: ne JAMAIS ajouter 
> de devices à un zPool en utilisant le /dev/sdX. 
> La numérotation peut être modifiée au reboot, et là ZFS s’y perd (j’avais un 
> HD UNAVAIL et l’autre FAULTED, heureusement que je suis en Raidz2….). 
> J’ai pu nettoyer avec un zpool offline, zpool export, puis zpool online. 
> Il utilise maintenant les ID des HD. 

RTFM : c'est dans la doc ça ;-) 

D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : 
il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid 
pour les intrépides). 

Julien 
___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox avec gros uptime = problèmes ?

[Alexandre DERUMIER]

>>Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph.
>>Ma vie a changée depuis que j'ai fait ça.

+1. sur ceph depuis 5ans, 0 downtime :)

- Mail original -
De: "Julien Escario" 
À: "French SysAdmin Group" 
Envoyé: Vendredi 18 Septembre 2020 09:35:53
Objet: Re: [FRsAG]  Proxmox avec gros uptime = problèmes ?

Le 18/09/2020 à 09:01, Pierre DOLIDON a écrit : 
> t'as pas une sandbox pour mettre a jour ? 
> 
> chez nous on upgrade régulièrement, donc pas trop de soucis, mais il fut 
> un temps où on upgradait pas les proxmox. on c'est lancé, on a upgrade 
> de debian7 à 10 (en étapes successives bien sur), et c'est passé comme 
> une lettre à la poste (sauf le cluster, bien sur, mais ça c'est 
> documenté par proxmox). 

Idem, mes plus vieilles machines dans mon cluster ont été installées en 
Proxmox 4. Tout ce petit monde est en 6.2 actuellement. 

> Seul bémol, on a quelques couple de proxmox qui tournent avec un socle 
> DRBD. comme proxmox a retiré ses packages de ses repository (problème de 
> licence avec linbit...) ben le module drbd kernel de debian8 (fourni par 
> proxmox) a une version supérieure à celui fourni par debian9/10. j'ai du 
> compiler à la mano (c'est pas la panacée...) 

Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. 
Ma vie a changée depuis que j'ai fait ça. 

Julien 
___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Proxmox avec gros uptime = problèmes ?

[Alexandre DERUMIER]

Difficile à dire, 

mais au piff, ca pourrait être de la fragmentation mémoire. (ce qui est 
possible avec un uptime si elevé)

tu as essayé de faire une migration des vms sur un autre noeud, reboot du 
serveur, et remigration  pour comparer ?


- Mail original -
De: "David Ponzone" 
À: "French SysAdmin Group" 
Envoyé: Jeudi 17 Septembre 2020 20:03:01
Objet: [FRsAG] Proxmox avec gros uptime = problèmes ?

Aux utilisateurs de Promox. 

Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans 
? 
Type de problème: certaines VM semblent avoir des problèmes de ressources CPU 
comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors 
qu’elles sont à 30-50% de CPU. 
La charge globale de l’hôte est autour de 50-60%. 
Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux 
limites de l’hôte, mais ce n’est pas le cas. 
J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème 
mais son uptime est de 8 mois seulement. 

Merci de vos retours. 


David Ponzone 


___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] [TECH] Cluster proxmox hyper convergé

[Alexandre DERUMIER]

Hello, 

>>Je test actuellement un cluster Proxmox 6.4 

6.4 ? 6.2 plutot ? ou 5.4 ? 

>>Ma préoccupation principale est de réussir à migrer mes VMs sans interruption 
>>de service si le nœuds qui exécute se voit brutalement stoppé. 

quand tu dit, le noeud est brutalement stoppé, tu veux dire crash,poweroff ? 
Parce que dans ce cas, les vms sont coupées également. (et la HA les redémarre 
sur un autre noeud, au bout de 1 à 2min). 

il n'y a pas de fault-tolerence dans proxmox. (où la vm mémoire de la vm est 
repliquée en permanence sur un autre noeud, et permet de basculer sans 
coupure). 
Ca existe dans qemu en beta-alpha (projet COLO: [ 
https://wiki.qemu.org/Features/COLO | https://wiki.qemu.org/Features/COLO ] ), 
mais pas encore implémenté dans proxmox. (et même dans qemu, je ne sais pas si 
c'est déjà stable) 

>>Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, 
>>l'interruption est bien trop longue pour des services en production. 
>>Existe il un moyen de palier ce problème ? 

Pas moyen de baisser le timeout, principalement pour de stabilité du cluster, 
pour ne pas killer les noeuds trop vite en cas de flap réseau. 



De: "Racamier Stéphane"  
À: "French SysAdmin Group"  
Envoyé: Mardi 16 Juin 2020 22:55:11 
Objet: [FRsAG] [TECH] Cluster proxmox hyper convergé 

Bonsoir le groupe, 

Je test actuellement un cluster Proxmox 6.4 avec un stockage hyper convergé 
ceph composé de 3x6 osd (HDD) avec deux carte gigabit en protocole LACP actif, 
1 carte sur le ring0 et 1 sur le ring1. 

La plateforme de test utilisé des HP proliant dl380 g7. 

Ma préoccupation principale est de réussir à migrer mes VMs sans interruption 
de service si le nœuds qui exécute se voit brutalement stoppé. Pour simuler 
cette panne je débranche l'interface ring0 et 1. 

Petit problème mes VMs se voient stoppé brutalement au décompte du watchdog, 
l'interruption est bien trop longue pour des services en production. 

Existe il un moyen de palier ce problème ? 

Cdlt. 

___ 
Liste de diffusion du FRsAG 
http://www.frsag.org/ 
___
Liste de diffusion du FRsAG
http://www.frsag.org/