Transient Fault Handling sous Azure

azure_dbLes environnements Multi-tenant, tels Windows Azure, sont lorsqu’ils sont bien conçus, soumis à des problématiques de « throttling » qui peuvent gêner les utilisateurs de l’infrastructure. Heureusement, des solutions simples existent, c’est ce que nous allons étudier ici.

Qu’est ce que le Throttling?

Pour faire simple, le throttling est la limitation de l’accès aux ressources d’une machine pour un client de cette machine.

Pourquoi y’a t’il du throttling?

Windows Azure est un environnement multi-tenant. A ce titre, plusieurs clients partagent sans le savoir les ressources d’une même machine.

Lorsqu’un des clients requiert une quantité trop importante de ressources, il peut lui arriver de mettre à mal le serveur hébergeur. Pour « survivre » à cet assaut, ce dernier applique un « throttling », c’est à dire une limitation de l’accès aux ressources.

Cette limitation est transitoire, elle est appliquée dans un temps limité, le temps que le serveur retrouve ses esprits. C’est pourquoi la gestion de ces erreurs est appelée le Transient Fault Handling.

Quels sont les types de throttling?

Le Soft Throttling

La limitation logicielle (soft throttling) limite les activités d’un sous-ensemble des systèmes hébergés par le serveur, et qui consomme la plupart des ressources.

Le Hard Throttling

La limitation matérielle (hard throttling) est l’étape finale. Aucune connexion n’est plus autorisée jusqu’à ce que les ressources utilisées  soient libérées.

Un exemple sur Azure Sql Database

Sur Azure Sql Database, les erreurs « Transient » se manifestent par un code d’erreur précis: 40501.

Le message d’erreur est le suivant:

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

Cette erreur étant clairement identifiable, il est possible de la gérer finement.

Quelles sont les solutions?

Entity Framework

Depuis la version 6, Entity Framework dispose de la « Connection Resiliency ». Cette implémentation permet au framework d’obtenir le comportement d’un Retry Pattern sur les connexions et les requêtes effectuées par l’ORM.

Pour en savoir plus: Entity Framework Connection Resiliency

Enterprise Library 5.0 Integration Pack for Windows Azure

Enterprise Library 6.0 ou Enterprise Library 5.0 avec le pack Azure contiennent également une implémentation de Retry Pattern pour gérer les erreurs de throttling sur Windows Azure. Cette partie de la librairie s’appelle le « Transient Fault Handling Application Block« 

Pour en savoir plus: The Transient Fault Handling Application Block

Plus d’argent: Sql Database Premium

La Sql Database en version Premium permet d’obtenir une capacité réservée de performances. Ainsi, on obtient des limites minimales de I/O par secondes par exemple, dans lesquelles il est garanti que l’on n’aura pas de throttling de ressources.

Pour en savoir plus: Premium Preview for SQL Database Guidance

Deep Dive into Transient Fault Handling

On va regarder d’un peu plus près, le Transient Fault Handling Application Block, et en particulier la méthode ExecuteAction<T> de la RetryPolicy:

tfh_retrypolicy1

Vous pouvez cliquer l’image pour mieux voir. Nous allons nous intéresser aux parties numérotées, le reste étant assez explicite.

En 1, on récupère notre stratégie de retry. C’est elle qui va nous donner par exemple le nombre de fois que l’on est prêt à réessayer en cas d’erreur transient.

En 2, on voit que les exceptions (Attention, à éviter dans son propre code, le Catch(Exception ex) trop général) sont attrapées et re-throw dans le cas où le nombre de retry a été dépassé ou que l’erreur n’est pas une erreur transitoire (revoir plus haut le code spécifique des erreurs transient). Dans le cas du re-throw, cela signifie qu’on n’a finalement pas réussi à se dépêtrer des erreurs transient, ou que d’autres erreurs se sont produites. C’est donc à gérer dans votre propre stack d’appels.

En 3, les abonnés de l’événement Retrying sont exécutés. Cet événement est à privilégier pour logger des warnings indiquant que des erreurs transient se sont produites. Cela vous permettra à terme d’envisager un redimensionnement de vos serveurs par exemple…

S’il y a des personnes intéressées, je pourrai montrer dans un prochain article comment gérer les erreurs Transient avec un TransactionScope et Entity Framework, avec en prime, rien que pour votre plaisir, un intercepteur de transaction…

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s