TamTam - BigData : résilience à la panne des systèmes distribués

Systèmes distribués et corruption du système de fichiers

Après les tests qui mettaient à mal la résistance au partitionnement réseau de certaines solutions Big Data (https://jepsen.io/), voici un autre test tout aussi inquiétant : https://github.com/aganesan4/CORDS.

Le but étant cette fois-ci de tester la résistance d’un cluster à la corruption du système de fichiers sur un des nœuds. Selon ces tests, les solutions les plus populaires comme ZooKeeper, MongoDB, Redis, Kafka ou Cassandra présentent toutes un risque. Si l’indisponibilité, la perte de données sur le nœud concerné ne sont pas si étonnantes, la corruption de données est également possible et confirmée dans le cas de Cassandra ou de Redis. C’est-à-dire qu’une donnée locale corrompue peut s’étendre à tout le cluster.

Faut-il s’inquiéter ?

Pas forcément quand on regarde en détail chaque système et ce qui est mis en cause. Tout d’abord, dans la plupart des cas le système va crasher, ce qui certes n’est pas l’idéal en termes de disponibilité mais permet une action de maintenance. Dans le cadre de Cassandra, la corruption de données n’est possible que si la compression est désactivée (ce qui est loin d’être une recommandation). MongoDB ou Zookeeper peuvent même s’auto-réparer dans certains cas.

Comment s’en prémunir ?

En utilisant certains systèmes de fichiers qui appliquent un contrôle de type checksum comme ZFS. En monitorant les indicateurs S.M.A.R.T. des disques qui permettent de faire un diagnostic selon plusieurs indicateurs de fiabilité dans le but d’anticiper les erreurs. Et évidemment d’attendre que ces risques soient pris en compte par les développeurs afin d’améliorer la résilience de leur solution (de nombreux tickets existent déjà).

Liens