[technique] Incident cluster openstack dimanche 29 septembre 19h / migration xfs => btrfs

Laurent GUERBY laurent at guerby.net
Lun 13 Oct 10:55:39 CEST 2014


Bonjour

Nous sommes malheureusement tombé sur un bug BTRFS
et le bug OVS n'est pas reproduit/corrigé, nous allons
faire un petit point d'ici demain et voir si on passe
au bon vieux EXT4.

Pas de perte de donnée a ce jour mais des blocages de VM.

Sincèrement,

Laurent

* bug XFS
http://oss.sgi.com/archives/xfs/2014-05/msg00311.html
* bug OVS
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763428
* bug BTRFS
https://linuxfr.org/news/sortie-de-linux-3-17#btrfs
http://tracker.ceph.com/issues/9740
http://www.spinics.net/lists/ceph-devel/msg03800.html

* bug EXT4 ?
http://tracker.ceph.com/issues/8818


Le Monday 06 October 2014 à 17:21 +0200, Laurent GUERBY a écrit :
> Bonjour,
> 
> Comme ni le bug xfs 3.14.2 ni le bug OVS 3.16 ne sont fixés
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763428
> nous avons décidé de passer de xfs a btrfs comme
> file system sous-jacent a ceph dans notre cluster.
> 
> http://ceph.com/docs/master/rados/configuration/filesystem-recommendations/
> <<
> Note We currently recommend XFS for production deployments. We recommend
> btrfs for testing, development, and any non-critical deployments. We
> believe that btrfs has the correct feature set and roadmap to serve Ceph
> in the long-term, but XFS and ext4 provide the necessary stability for
> today’s deployments. btrfs development is proceeding rapidly: users
> should be comfortable installing the latest released upstream kernels
> and be able to track development activity for critical bug fixes.
> >>
> 
> Comme nous avons deja des kernels avancés le risque btrfs semble
> gérable vs la situation instable actuelle, et cela semble aller
> dans le long terme visé par le projet ceph.
> 
> Cela fait aussi un bon test des procedures de migration : 
> destruction d'un OSD (le gestionnaire d'un disque) xfs puis
> creation d'un neuf btrfs sur le meme disque, avec
> ceph qui reequilibre au fur et a mesure pour retablir
> la situation initiale en redondance triple apres
> un passage en redondance double (comme nous sommes
> dans le cas particulier ou redondance = nombre de machine = 3).
> 
> A priori pas d'impact sur les VM adherents a part
> une plus faible performance en I/O le temps que
> ceph migre les données.
> 
> Sincèrement,
> 
> Laurent
> 





Plus d'informations sur la liste de diffusion technique