Mise à l'échelle élastique : ajouter et retirer des serveurs Zaris sans interruption

La capacité n'est jamais juste longtemps. Le trafic augmente, un lancement a lieu, une saison se termine — et le store que vous avez dimensionné le trimestre dernier est soit saturé, soit à moitié inactif. La question qui décide si c'est une corvée ou une crise est simple : pouvez-vous changer la taille d'un store en cours d'exécution sans l'arrêter ?

Pour Zaris la réponse est oui, avec une asymétrie importante qu'il vaut la peine d'avouer d'emblée. La mise à l'échelle horizontale — ajouter des serveurs — est la direction facile, sûre et sans perte, et elle se produit en direct pendant que le store continue de servir. La réduction d'échelle — retirer des serveurs — est également prise en charge, mais c'est une opération délibérée et surveillée, car les données du serveur qui part doivent d'abord aller quelque part.

Cet article parcourt les deux directions : agrandir un store avec Add-ZrServer, le réduire avec Remove-ZrServer, pourquoi la réduction nécessite un drain, et où s'insère la console web.

Le store a une forme désirée

Sous la mise à l'échelle élastique se trouve une idée : la forme d'un store Zaris est décrite par une StoreDefinition canonique — l'ensemble désiré de serveurs et de partitions que le store est censé avoir. C'est la source de vérité de ce à quoi le cluster devrait ressembler, et non un décompte courant de ce à quoi il ressemble en ce moment.

Zaris s'exécute sous un modèle de superviseur : le superviseur possède cette définition canonique et pilote en continu les instances en cours d'exécution vers elle. La mise à l'échelle n'est donc pas un tas d'étapes manuelles que vous séquencez à la main — vous changez la forme désirée, et le superviseur réconcilie le cluster en direct pour qu'il corresponde. Add-ZrServer et Remove-ZrServer sont la façon dont un opérateur édite cette forme désirée, et le superviseur fait le travail pour y parvenir.

Mise à l'échelle horizontale : en direct et sans perte

Ajouter de la capacité tient en une seule cmdlet. Vous la pointez vers le store et lui donnez le nouveau serveur :

# Grow the store by adding a server to its definition
Add-ZrServer -Store orders -Server zaris-c.example.com:7861

# Check the resulting set
Get-ZrServer -Store orders

Lorsque vous faites cela, le store se repartitionne en direct. Les partitions se redistribuent pour que le nouveau serveur prenne sa part, les données migrent vers leurs nouveaux propriétaires, et le store continue de servir les lectures et les écritures tout du long — il n'y a pas de fenêtre d'arrêt total. Lors de nos tests, nous avons agrandi un store de 6 partitions à 8 de cette manière tandis qu'il restait en ligne.

La garantie qui compte ici : la mise à l'échelle horizontale est sans perte. Aucune écriture acquittée n'est perdue pendant la migration. Les données se déplacent vers les nouveaux propriétaires, la propriété bascule, et une écriture dont le store a dit au client qu'elle était validée est toujours là de l'autre côté de la repartition. C'est ce qui fait de l'ajout de capacité une opération de routine — vous pouvez réagir à la charge en agrandissant le store pendant le trafic, et non pendant une fenêtre de maintenance.

Réduction d'échelle : drainer, puis retirer

Retirer un serveur est là où l'asymétrie apparaît, et c'est de la physique, pas une limitation que vous pourriez contourner par un drapeau. Un serveur qui part détient des données — sa part des partitions. S'il disparaissait simplement, ces données disparaîtraient avec lui.

La réduction d'échelle est donc une opération drain-puis-retrait, pas une mise à mort instantanée. Avant qu'un serveur sur le départ ne parte, ses partitions doivent migrer leurs données vers les serveurs qui restent. Ce n'est qu'une fois ce drain du plan de données terminé que le serveur sur le départ a réellement transmis tout ce dont il était responsable, et c'est seulement alors qu'il est sûr pour lui de partir.

# Remove a server from the store's definition — this initiates the drain
Remove-ZrServer -Store orders -Server zaris-c.example.com:7861

Remove-ZrServer édite la forme désirée pour exclure ce serveur, et le superviseur fait avancer le store vers la nouvelle définition en déplaçant les partitions du serveur sur le départ vers les serveurs restants avant qu'il ne sorte. Le modèle mental à garder est : l'augmentation de capacité est instantanée et sûre ; la diminution de capacité est une migration contrôlée. Traitez une réduction d'échelle comme une opération délibérée et surveillée — lancez-la, observez la progression du drain, et confirmez que les données ont bien atterri sur les serveurs restants avant de considérer le serveur comme parti. Arracher un serveur sans le laisser drainer est la façon de perdre les données qu'il détenait.

L'observer depuis la console

Vous n'avez pas à faire tout cela à l'aveugle. La console web dispose d'une vue Serveurs qui montre l'ensemble actuel des serveurs qui soutiennent un store et vous permet de le gérer. C'est l'endroit naturel pour :

• Voir l'ensemble en direct — quels serveurs sont dans le store en ce moment, par rapport à la définition désirée vers laquelle le superviseur réconcilie.
• Observer l'atterrissage d'une mise à l'échelle horizontale — confirmer qu'un serveur nouvellement ajouté a repris ses partitions et sert.
• Surveiller le drain d'une réduction d'échelle — suivre la migration des partitions d'un serveur sur le départ avant qu'il ne parte, afin de savoir que le drain est terminé plutôt que de le deviner.

Pour la réduction d'échelle en particulier, cette visibilité est tout l'intérêt. Un drain est un véritable déplacement de données avec un début et une fin, et la vue Serveurs est la façon de faire la différence.

Le résumé honnête

La mise à l'échelle élastique dans Zaris se résume à éditer une forme désirée et à laisser le superviseur réconcilier le store en cours d'exécution vers elle :

• La mise à l'échelle horizontale (Add-ZrServer) est la direction facile et sûre — en direct, repartitionnant sur place, et sans perte. Agrandissez-vous selon la charge chaque fois que vous en avez besoin.
• La réduction d'échelle (Remove-ZrServer) est prise en charge et sûre quand vous la laissez drainer — les données du serveur sur le départ migrent d'abord vers les survivants, alors planifiez la diminution de capacité comme une opération délibérée et surveillée plutôt qu'une mise à mort instantanée.

Dimensionnez pour le trafic que vous avez, pas pour le trafic que vous craigniez, et changez d'avis plus tard — à la hausse sans cérémonie, à la baisse avec soin.