<p dir="ltr">Plantages des VM. <br>
Et question sur OS pour routeur Ubiquti EdgeRouter 8.</p>
<p dir="ltr">Il y avait quoi comme outils de travaux utilisés. </p>
<p dir="ltr">Si ce sont des perceuses, des foreuse et autres super-perturbateurs, ce n'est plus la loi de Murphy à prendre en compte, mais la loi du génocide des VM. <br>
😁</p>
<p dir="ltr">Sinon, je découvre tout ce qu'on peut faire avec mon petit routeur d'ubiqiti EdgeRouter 8.<br>
La base Linux créée par Ubiquti est assez intéressante. <br>
Je suppose qu'elle est bien optimisée. </p>
<p dir="ltr">Mais, quand je regarde l'interface et tout ce qui a été déjà fait avec OpenWRT, je dois avouer que j'hésite. </p>
<p dir="ltr">Le top pour moi serait d'y faire passer deux accès Internet ADSL en bounding et un accès Internet via Tetaneutral (pour un usage plus domestique, l'accès Tetaneutral). <br>
Pour le bounding, il faut un serveur loué dans un data-center, je n'ai pas encore choisi chez qui louer un petit serveur pour y monter un VPN bounding entre mon routeur Ubiquti et le serveur loué en passant par les deux liens ADSL. </p>
<p dir="ltr">J'aimerais connaître vos avis car je ne suis pas trop habitué avec de genre de montage. </p>
<p dir="ltr">Bon Week-end ! </p>
<p dir="ltr">Synclinal <br>
</p>
<div class="gmail_quote">Le 30 oct. 2015 12:00 PM, <<a href="mailto:technique-request@lists.tetaneutral.net">technique-request@lists.tetaneutral.net</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Envoyez vos messages pour la liste technique à<br>
<a href="mailto:technique@lists.tetaneutral.net">technique@lists.tetaneutral.net</a><br>
<br>
Pour vous (dés)abonner par le web, consultez<br>
<a href="http://lists.tetaneutral.net/listinfo/technique" rel="noreferrer" target="_blank">http://lists.tetaneutral.net/listinfo/technique</a><br>
<br>
ou, par email, envoyez un message avec 'help' dans le corps ou dans le<br>
sujet à<br>
<a href="mailto:technique-request@lists.tetaneutral.net">technique-request@lists.tetaneutral.net</a><br>
<br>
Vous pouvez contacter l'administrateur de la liste à l'adresse<br>
<a href="mailto:technique-owner@lists.tetaneutral.net">technique-owner@lists.tetaneutral.net</a><br>
<br>
Si vous répondez, n'oubliez pas de changer l'objet du message afin<br>
qu'il soit plus spécifique que "Re: Contenu du digest de<br>
technique..."<br>
<br>
<br>
Thèmes du jour :<br>
<br>
1. Re: INCIDENT: upgrade ceph+downgrade kernel / perte de deux<br>
machines physiques du cluster g2 et stri 20151026 / cluster down<br>
(Laurent GUERBY)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 29 Oct 2015 14:05:39 +0100<br>
From: Laurent GUERBY <<a href="mailto:laurent@guerby.net">laurent@guerby.net</a>><br>
To: "<a href="mailto:technique@lists.tetaneutral.net">technique@lists.tetaneutral.net</a>"<br>
<<a href="mailto:technique@lists.tetaneutral.net">technique@lists.tetaneutral.net</a>><br>
Subject: Re: [technique] INCIDENT: upgrade ceph+downgrade kernel /<br>
perte de deux machines physiques du cluster g2 et stri 20151026 /<br>
cluster down<br>
Message-ID: <<a href="mailto:1446123939.2019.234.camel@guerby.net">1446123939.2019.234.camel@guerby.net</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Bonjour,<br>
<br>
Le cluster n'etant toujours pas stable nous avons migré<br>
ceph en 0.94.5 ce qui a permis de recuperer nos OSD<br>
qui ne voulait pas demarrer.<br>
<br>
Nous avons aussi remplacé un disque dur defaillant,<br>
et ajouté un SSD au cluster le temps de remplacer<br>
les deux autres SSD defaillants.<br>
<br>
Avec un ecran nous avons pu observer sur deux machines differentes<br>
des "BUG: softlockup - CPU#12 stuck for 22s! [ceph-osd:xxx" et<br>
la console ne repondait plus vraiment.<br>
<br>
En regardant en detail il y a une correlation entre<br>
la version du kernel et l'uptime des machines :<br>
<br>
g1 === 10:52:14 up 3 days, 2:44, 2 users, load average: 5.90, 6.56, 7.21<br>
g2 === 10:52:14 up 1 day, 2:16, 0 users, load average: 5.64, 5.79, 5.84<br>
g3 === 10:52:14 up 11:25, 0 users, load average: 5.48, 5.87, 6.27<br>
g4 === 10:52:14 up 55 min, 1 user, load average: 38.11, 17.31, 12.59<br>
g5 === 10:52:15 up 148 days, 12:54, 0 users, load average: 6.41, 6.01, 5.95<br>
g6 === 10:52:15 up 36 min, 0 users, load average: 7.59, 7.37, 6.41<br>
n7 === 10:52:15 up 149 days, 21:14, 2 users, load average: 12.56, 10.58, 10.13<br>
g8 === 10:52:15 up 17:12, 0 users, load average: 12.00, 10.85, 10.55<br>
g9 === 10:52:15 up 21:56, 0 users, load average: 8.37, 8.21, 8.06<br>
g10 === 10:52:15 up 1 min, 0 users, load average: 4.11, 1.28, 0.45<br>
stri === 10:52:15 up 1:34, 0 users, load average: 5.74, 6.40, 5.77<br>
<br>
g1 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
g2 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
g3 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
g4 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
g5 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)<br>
g6 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
n7 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)<br>
g8 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
g9 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19)<br>
g10 === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19)<br>
stri === Linux version 3.16.0-4-amd64 (<a href="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</a>) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)<br>
<br>
g5 et n7 avaient 148+ jours d'uptime avec le kernel 3.16.7-ckt9-3~deb8u1<br>
nous avons donc downgradé toutes les autres machines de ckt11-1+deb8u3 a<br>
3.16.7-ckt9-3~deb8u1.<br>
<br>
Meme avec cela ce matin il y a encore eu un reboot mais rien sur<br>
l'ecran : il est possible que les travaux en cours a TLS00 perturbent<br>
notre alimentation car les ouvriers sont sur le meme tableau que nous.<br>
La partie decoupe et percussion s'est terminee ce matin, il reste<br>
cependant de la soudure dans les jours qui viennent (d'apres google la<br>
norme EN 61000-3-12 est censé fixer les limites d'harmoniques d'un<br>
poste a souder a l'arc).<br>
<br>
20 VM ne sont pas reparties a cause d'erreur dans la base openstack,<br>
Mehdi va regarder depuis Tokyo, 103 VM sont a priori fonctionnelles.<br>
<br>
Si le taux de plantage de machine physique ne diminue pas nous<br>
installerons un onduleur a double conversion 3kVA en amont<br>
des machines.<br>
<br>
Sincèrement,<br>
<br>
Laurent<br>
<br>
On Tue, 2015-10-27 at 23:45 +0100, Laurent GUERBY wrote:<br>
> Bonsoir,<br>
><br>
> Dans la suite des aventures au pays de Murphy la machine g4 a planté<br>
> plusieurs fois dans la journée, comme c'est probablement un probleme<br>
> materiel je l'ai remplacée par une machine donnée par l'association ISF<br>
> <a href="http://www.isf.cc/" rel="noreferrer" target="_blank">http://www.isf.cc/</a> a <a href="http://tetaneutral.net" rel="noreferrer" target="_blank">tetaneutral.net</a> la semaine derniere. En transvasant<br>
> les disques cela a l'air de fonctionner depuis un peu plus d'une heure.<br>
><br>
> J'ai envoyé une requete sur la liste des utilisateurs ceph<br>
> et notre probleme d'OSD qui ne demarre pas semble<br>
> etre corrigé en 0.94.4 (on est en 0.94.2) :<br>
><br>
> <a href="http://tracker.ceph.com/issues/13060" rel="noreferrer" target="_blank">http://tracker.ceph.com/issues/13060</a><br>
> <a href="http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-October/005727.html" rel="noreferrer" target="_blank">http://lists.ceph.com/pipermail/ceph-users-ceph.com/2015-October/005727.html</a><br>
><br>
> On ne peut pas utiliser directement 0.94.4 a cause d'un bug ceph/KVM<br>
> deja identifié sur ceph-users :<br>
><br>
> <a href="https://www.mail-archive.com/ceph-users@lists.ceph.com/msg24339.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/ceph-users@lists.ceph.com/msg24339.html</a><br>
> <a href="http://tracker.ceph.com/issues/13559" rel="noreferrer" target="_blank">http://tracker.ceph.com/issues/13559</a><br>
><br>
> Et d'un autre bug qu'on a reporté il y a un moment et dont le fix a eté<br>
> commité seulement apres 0.94.4 :<br>
><br>
> <a href="http://tracker.ceph.com/issues/10399" rel="noreferrer" target="_blank">http://tracker.ceph.com/issues/10399</a><br>
><br>
> 0.94 est une release LTS de ceph, reste a voir si on package une<br>
> 0.94.4 + fix qui nous interessent (probable).<br>
><br>
> Sincèrement,<br>
><br>
> Laurent<br>
><br>
> On Mon, 2015-10-26 at 22:53 +0100, Laurent GUERBY wrote:<br>
> > Bonsoir,<br>
> ><br>
> > Le cluster est toujours en recovery mais ca n'impacte plus trop les VM<br>
> > visiblement.<br>
> ><br>
> > Il reste 3 VM adherents down (ilico, phoeneeks, uind) que je ne peux pas<br>
> > redemarrer a cause d'un etat openstack incoherent ("cannot xxx while it<br>
> > is in task_state powering-off"), il faudra que Mehdi jette un oeil<br>
> > depuis Tokyo :).<br>
> ><br>
> > Sincèrement,<br>
> ><br>
> > Laurent<br>
> ><br>
> > On Mon, 2015-10-26 at 12:48 +0100, Laurent GUERBY wrote:<br>
> > > Bonjour,<br>
> > ><br>
> > > Le cluster est toujours en recovery :<br>
> > ><br>
> > > 102 requests are blocked > 32 sec<br>
> > > recovery 2954723/65811225 objects degraded (4.490%)<br>
> > > recovery 2587563/65811225 objects misplaced (3.932%)<br>
> > > recovery 13/10406629 unfound (0.000%)<br>
> > ><br>
> > > pg 87.16 is active+recovery_wait+undersized+degraded+remapped, acting<br>
> > > [30,8,16,25,18,2147483647,1,14,39,9], 7 unfound<br>
> > > pg 87.7b is active+recovery_wait+undersized+degraded+remapped, acting<br>
> > > [17,30,15,2147483647,25,1,9,35,39,16], 6 unfound<br>
> > ><br>
> > ><br>
> > > Les "unfound" sont sur un pool utilisé par une seule VM, a priori<br>
> > > il n'y aura pas de perte de donnée malgré la perte de 3 disques (2 dans<br>
> > > le pool SSD qui est en redondance triple, et 1 dans le pool HDD qui est<br>
> > > soit triple soit 4+1 en cours de migration vers 4+2) mais la recovery<br>
> > > risque de durer encore une journee.<br>
> > ><br>
> > > Une fois la recovery finie nous ajouterons quelques disques<br>
> > > SSD neufs et proposerons une migration des petits disques systeme<br>
> > > (20G) sur le pool ceph SSD : les VMs qui sont sur le pool ceph SSD sont<br>
> > > deja revenues en ligne.<br>
> > ><br>
> > > Sincèrement,<br>
> > ><br>
> > > Laurent<br>
> > ><br>
> > > On Mon, 2015-10-26 at 08:31 +0100, Laurent GUERBY wrote:<br>
> > > > Bonjour,<br>
> > > ><br>
> > > > A 23h04 dimanche 20151025 la machine physique "stri" du cluster a planté<br>
> > > > et ce lundi 20151026 a 5h17 la machine "g2" du cluster a aussi planté.<br>
> > > ><br>
> > > > Avec IPMI j'ai redemarré stri et la machine est revenue, avec vPro<br>
> > > > sur g2 j'ai fait un fsck manuel sur sda2 puis la machine est<br>
> > > > revenue.<br>
> > > ><br>
> > > > Pendant le redemarrage g1 a 7h56 a aussi disparu, la aussi<br>
> > > > redemarrage au vPro.<br>
> > > ><br>
> > > > Apres ces redemarrages il y a actuellement 3 OSD avec un soucis :<br>
> > > ><br>
> > > > osd.0 hdd sur g1 refuse de demarrer sur un ASSERT :<br>
> > > > <a href="http://tracker.ceph.com/issues/13594" rel="noreferrer" target="_blank">http://tracker.ceph.com/issues/13594</a><br>
> > > ><br>
> > > > osd.12 SSD n'existe plus (?) sur stri<br>
> > > > root@stri:/var/log/ceph# /etc/init.d/ceph start osd.12<br>
> > > > /etc/init.d/ceph: osd.12 not found (/etc/ceph/ceph.conf defines osd.14<br>
> > > > osd.13 osd.15 , /var/lib/ceph defines osd.14 osd.13 osd.15)<br>
> > > ><br>
> > > > osd.4 SSD sur g2 pareil :<br>
> > > > root@g2:/var/log/ceph# /etc/init.d/ceph start osd.4<br>
> > > > /etc/init.d/ceph: osd.4 not found (/etc/ceph/ceph.conf defines mon.g2<br>
> > > > osd.1 osd.21 osd.7 , /var/lib/ceph defines mon.g2 osd.1 osd.21 osd.7)<br>
> > > ><br>
> > > > Probablement un probleme puppet, j'attend le retour de Mehdi.<br>
> > > ><br>
> > > > En l'etat actuel les VM sont quasiment toutes down.<br>
> > > ><br>
> > > > Sincèrement,<br>
> > > ><br>
> > > > Laurent<br>
> > ><br>
> ><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Pied de page des remises groupées<br>
<br>
_______________________________________________<br>
technique mailing list<br>
<a href="mailto:technique@lists.tetaneutral.net">technique@lists.tetaneutral.net</a><br>
<a href="http://lists.tetaneutral.net/listinfo/technique" rel="noreferrer" target="_blank">http://lists.tetaneutral.net/listinfo/technique</a><br>
<br>
<br>
------------------------------<br>
<br>
Fin de Lot technique, Vol 52, Parution 20<br>
*****************************************<br>
</blockquote></div>