Aujourd'hui, j'aimerais parler de la résilience à l'échec, qui est un thème majeur d'un le récent brevet Qumulo a été attribué.
Dans le système distribué de Qumulo, nous avons deux ressources d'importance critique pour stocker de manière fiable les fichiers de nos utilisateurs. Tout d'abord, les supports de stockage. Il peut s'agir d'un SSD, d'un disque dur ou même d'un stockage cloud blob. Pour mes besoins ici, nous appellerons simplement toute unité de stockage indépendamment adressable et indépendamment défaillante un disque. Ensuite, nous avons besoin d'un serveur connecté au réseau (calcul), que nous utilisons pour exécuter notre logiciel, ainsi que pour adresser à la fois l'utilisateur et les disques. Il peut s'agir d'une machine physique dans un centre de données ou d'une machine virtuelle dans le cloud public. Ensemble, nous appelons tous les serveurs et le stockage disponibles pour notre logiciel le cluster.
Tout le matériel tombe en panne et tous les services peuvent perdre des données. Il est de la responsabilité de Qumulo de maintenir une opérabilité totale malgré toute combinaison raisonnable de pannes et de ne jamais perdre de données client. Pour chaque cluster, nous définissons des pannes simultanées de serveur et de disque, que nous devons prendre en charge en fonction des besoins du client. Nous utilisons ensuite une technique connue sous le nom de codage d'effacement pour protéger les clients contre les pannes de serveur et de disque. Je vous recommande vivement de lire notre poste sur le codage d'effacement si ce n'est pas le cas, mais je résumerai ici les points les plus importants.
Un concept clé dans les systèmes de fichiers redondants tolérants aux pannes comme Qumulo est "l'efficacité". Il s'agit de la quantité de données qu'un client peut stocker sur le cluster après réduction de l'espace requis par le logiciel du système de fichiers. Sur site, les disques sont toujours connectés aux serveurs, et donc si le serveur n'était pas disponible, les données l'étaient aussi. Cela limite l'efficacité maximale de tout schéma basé sur l'encodage utilisé pour protéger les données. Par exemple, un cluster de quatre serveurs ne peut avoir des données encodées avec une efficacité de 75 % que si le client souhaite continuer à fonctionner avec un accès en lecture seule à toutes les données avec 1 serveur hors ligne. Si nous voulons écrire dans une fraction du stockage hors ligne, nous devenons limités à l'encodage avec une efficacité maximale de 66 %.
À des échelles modérées, un cluster de huit serveurs autorisant deux pannes de serveur simultanées a les mêmes restrictions d'efficacité de codage que le cluster de quatre serveurs autorisant une panne de serveur. Vous pouvez extrapoler proportionnellement cet argument à des tailles de cluster de plus en plus grandes.
Notre solution à ce problème consistait à modéliser soigneusement le délai moyen de perte de données (MTTDL) avec diverses combinaisons de pannes de serveur et de disque, puis à n'autoriser que les configurations dépassant un seuil très élevé. Sur les grands clusters, l'efficacité de l'encodage peut atteindre 90 %.
Cette solution est aussi proche que possible de l'optimum sur site, mais nous pouvons faire mieux dans le cloud. Dans le nuage, Qumulo utilise le stockage à distance. Qumulo sur Azure en tant que service utilise Stockage d'objets blob Azure pour ses besoins de stockage. Étant donné que le stockage de Qumulo n'est pas physiquement sur le serveur, notre service peut appliquer la même logique ci-dessus aux disques à la place. Parce qu'il y a proportionnellement beaucoup plus de disques que de serveurs dans un cluster typique, notre service peut atteindre une efficacité beaucoup plus élevée à petite échelle. Nous pourrions théoriquement atteindre ce marqueur d'efficacité de 90 % sur notre cluster Azure à plus petite échelle. Sur les clouds avec des supports de stockage fiables comme Azure, nous pouvons même atteindre 95 % d'efficacité.
NOTRE équipe d'ingénierie a récemment livré une amélioration de produit tirant parti de cette approche brevetée. Les "disques flottants" permettent à Qumulo en tant que service de réaffecter le stockage distant à un autre serveur si le serveur qui l'hébergeait auparavant se déconnecte. Cela nous permettra de prendre en charge moins de 50 % des serveurs défaillants simultanément, tout en nous permettant d'être beaucoup plus efficaces à petite échelle. Voici à quoi ressemble la création d'un véritable service de stockage cloud natif.
En savoir plus sur les mises à niveau non perturbatrices ici
