Nous avons actuellement une application classique à n niveaux: DB / service web / front-end. Il a d'autres composants, mais c'est la disposition de base.

Nous voulons améliorer la disponibilité des applications pour 3 raisons principales:

1. Notre hôte connaît parfois des pannes (comme ils le font tous), et nous voulons minimiser l'impact sur nos clients, par exemple, ils allumeraient le centre de données B si le centre de données A est en panne.
2. Lorsque nous mettons à jour la version, nous fermons le site pour maintenance, et cela prend généralement quelques heures (scripts de migration, etc.). Nous aimerions que les utilisateurs aient une transition plus transparente, avec un temps d'arrêt aussi minimal que possible (ils utilisent le serveur B pendant la mise à niveau du serveur A).
3. En option, nos clients sont situés dans le monde entier, et nous voulons qu'ils aient la meilleure expérience possible malgré leurs connexions éventuellement nulles (toute personne qui a travaillé avec des développeurs indiens devrait savoir ce que je veux dire). Idéalement, nous aimerions pouvoir brancher un serveur dans leur bureau (ou utiliser un centre de données près de leur ville), et il s'intégrerait parfaitement dans notre architecture.

Nous n'avons pas besoin à distance d'une disponibilité de 99%, pas même de 95%. C'est une application de gestion de documents. Tout le monde s'en fout. Mais comme les migrations peuvent prendre un certain temps et qu'il existe des clients dans le monde, nous empêchons parfois un client de travailler pendant la majeure partie de sa journée.

Pour la partie SQL, même s'il n'y a pas de DBA "corrects", nous connaissons les possibilités SQL : réplication, mise en miroir, etc. Côté DB, il est assez facile de trouver des ressources pour cela. Ce qui est plus difficile, c'est tout le reste: le stockage des sessions, le code, etc. Si mon serveur de services Web tombe en panne, comment mon interface utilisateur sait-elle qu'elle doit changer? Comment mes sessions sont-elles conservées sur tous les serveurs?

Malheureusement, aucun d'entre nous n'a d'expérience dans ce domaine et nous ne savons même pas par où commencer. Existe-t-il des meilleures pratiques pour cela? Modèles de conception? Les bibliothèques (qui devraient être gratuites car nous n'avons pas d'argent)?

Nous utilisons ASP.Net et SQL Server, avec un service Web WCF au milieu. Nous avons un tas de services Windows qui traînent, mais ils ne sont pas essentiels à la mission, et je suppose que les méthodes de traitement du site Web seront applicables aux services.

Je comprends que la plupart des plates-formes cloud fournissent un système intégré pour cela, mais l'hébergement cloud est un pas à cause de notre administrateur système, qui veut tout gérer lui-même et ne compter sur personne.

Vous devez clarifier le type de haute disponibilité que vous recherchez. Il existe des applications hautement disponibles que j'exécute et qui doivent être mises en place 95% du temps. Il y en a d'autres qui doivent fonctionner à 99%. Je peux penser à des scénarios de vie ou de mort qui nécessitent une disponibilité à 100%. Seuls ces trois pays ont des approches et des coûts radicalement différents.

Juste deviner en fonction de vos besoins et d'un SLA de disponibilité de 95 à 99%:

• Les migrations de base de données devraient pouvoir se produire en temps réel pour la plupart des changements. Pratiquez la conception de bases de données évolutives . Pour les changements qui nécessitent un comportement plus invasif, vous avez quelques options. L'une consiste à prendre le temps d'arrêt. Si possible, l'exécution de votre service en mode lecture seule peut fonctionner. Pour une fonctionnalité complète, je voulais essayer ScaleArc depuis un moment. Il ressemble à un outil très simple pour la mise à l'échelle et la résilience dans le monde SQL Server.
• Mettre des serveurs à l'intérieur des sites de vos clients est une recette pour un désastre ingérable à moins que vous n'ayez des stratégies de déploiement de classe mondiale (que, selon votre description de vos migrations, vous n'avez pas encore). Ne pas pousser les services cloud sur site car vous avez des problèmes de performances. Résolvez les problèmes de performances de temps en temps, vous n'aurez pas à vous occuper de ceux plus coûteux sur la route.
• Votre serveur d'état devrait être une base de données quelconque. Suivez leurs directives HA. Vous pouvez utiliser SQL Server pour cela, car vous l'avez déjà à votre disposition.
• En parlant de bases de données, la réplication n'active pas HA. En fait, la réplication SQL vous causera des maux de tête à chaque tour (en parlant d'expérience avec plusieurs scénarios de réplication de nœuds). La mise en miroir peut fonctionner, mais enfin, je me souviens, le clustering SQL prend 1 à 5 minutes pour basculer sur le nouveau serveur. J'ai entendu de bonnes choses à propos de AlwaysOn, mais je suis toujours méfiant étant donné le bilan de Microsoft. Quelque chose comme ScaleArc pourrait être plus utile ici.
• Votre serveur Web doit être apatride. Faites tourner trois ou quatre et mettez-les derrière un équilibreur de charge. Cela résout vos soucis de disponibilité. Comme Frederik l'a mentionné précédemment, vous pouvez également effectuer des déploiements continus de cette façon.
• Votre service Web devrait probablement être apatride. Sinon, voyez si vous pouvez le séparer en bits sans état et avec état. Placer plusieurs instances de celui-ci derrière le même équilibreur de charge résout à nouveau les soucis de disponibilité et permet des scénarios de déploiement plus intéressés (par exemple les déploiements bleu / vert).

Contrairement à Frederik, je n'appellerai pas votre paranoïa cloud injustifiée. Cela dépend de vos besoins de disponibilité. Il est concevable qu'un service doive fonctionner dans plusieurs centres de données exploités par différents fournisseurs dans différents pays pour des raisons de redondance. Compte tenu de votre état actuel, cependant, je conviens qu'AWS, Azure ou similaire sont probablement des paris sûrs pour votre entreprise.

Obtenir un certain niveau de HA sur votre niveau Web et d'application:

1. Idéalement, factorisez n'importe quel état, y compris l'état de session dans des systèmes à état partagé comme une base de données ou un serveur d'état de session en mémoire. Selon la conception de votre application, cela peut entraîner des problèmes de performances en raison de la latence supplémentaire qui obtient une grande quantité d'état.

2. Votre site Web et votre niveau d'application doivent chacun avoir un équilibreur de charge indépendant devant eux. NGINX fera l'affaire, mais IIS peut aussi le faire (ARR).

3. Si une seule base de données ne peut pas gérer la charge, tirez parti du partitionnement de l'état de la session (ou du partage ou du hachage cohérent) pour acheminer une demande particulière vers une boîte de base de données particulière.

Si l'état d'affacturage est trop difficile, vous pouvez utiliser l'affinité du serveur pour l'équilibrage de charge (c'est-à-dire que les utilisateurs sont systématiquement acheminés vers la même boîte, souvent basée sur des cookies). Ce n'est pas aussi hautement disponible qu'une approche à tour de rôle sans état, car une panne de boîte affectera tous les utilisateurs et l'état de cette boîte, mais elle bat une panne complète (en fonction du cas d'utilisation).

Côté mise à niveau:

1. Concevez vos scripts de base de données de manière à ce que les mises à niveau de base de données puissent être effectuées pendant que le système fonctionne, en d'autres termes, maintenez la compatibilité descendante. Un modèle qui fonctionne bien pour cela est "étendre, puis contracter" -> n'effectuer que des modifications additives et rétrocompatibles mais en supprimant les dépendances sur les champs (etc.) dont vous voulez vous débarrasser; puis mettez à niveau tous les clients de la base de données vers v-latest; puis effectuez une autre mise à niveau de base de données pour vous débarrasser des anciens champs (etc.) de la base de données. Cela peut être un processus lent si vous avez une grande base de données et vous devez faire attention à ne pas saboter les performances de votre système.

2. Mettre à niveau votre niveau d'application: puisque vous n'utilisez pas un environnement cloud, je vous recommande de suivre le modèle de déploiement canari: effectuez une mise à niveau progressive de vos boîtes Web et de niveau intermédiaire. Si le déploiement échoue, sortez la boîte de l'équilibreur de charge, comme vous le feriez comme s'il avait échoué.

Avertissement: faire évoluer un système qui n'a pas été conçu pour HA en un qui l'est, peut être un processus long et coûteux. Vous devrez faire des compromis en cours de route (coût vs effort pour atteindre un niveau de disponibilité particulier)

Votre paranoïa dans le cloud est injustifiée - des fournisseurs tels qu'AWS, en collaboration avec les bonnes pratiques de votre part, peuvent contrôler / atténuer la plupart des risques - consultez leur page de conformité pour avoir une idée des réglementations auxquelles ils sont conformes: https: // aws .amazon.com / compliance /

TL; DR: construction redondante, modulaire; tester la disponibilité; surveiller de près.

Après avoir réalisé qu'essayer de saisir une explication peut durer très longtemps, je vais donc noter toutes les observations que j'ai faites.

Questionner la prémisse

Le système cloud est la panacée

Même si vous deviez vous lancer pleinement dans le cloud, avec un fournisseur de cloud de premier plan, vous devrez toujours concevoir votre application pour la résilience, ce qui est le cas. AWS peut remplacer votre machine virtuelle, mais votre application doit pouvoir redémarrer si elle est laissée au milieu du calcul.

Nous ne voulons pas utiliser le système cloud, à cause de x / y / z

À moins que vous ne soyez une organisation de très grande taille, vous avez intérêt à utiliser des systèmes cloud. Les trois principaux systèmes cloud (AWS, MSFT, Google) emploient des milliers d'ingénieurs pour vous offrir les SLA promis et le tableau de bord facile à gérer. C'est en fait une bonne affaire pour les utiliser au lieu de dépenser un centime sur cette maison.

Problèmes de cadrage et de conception

Définir, quantifier puis mesurer en continu la disponibilité d'un service est un défi plus important que d'écrire une solution pour les problèmes de disponibilité.

Définir et mesurer la «disponibilité» est plus difficile que prévu

Plusieurs parties prenantes ont une vision différente de la disponibilité, et ce qui peut arriver, c'est que la définition préférée par une personne avec le salaire le plus élevé l'emporte sur une autre définition. C'est parfois une définition correcte, mais souvent l'écosystème n'est pas construit autour de la mesure de la même chose car cette définition idéale est beaucoup plus délicate à mesurer, et encore moins à surveiller en temps réel. Si vous avez une définition de la disponibilité qui ne peut pas être surveillée en temps réel, vous trouverez encore et encore votre propre projet similaire avec des similitudes étranges. Restez avec quelque chose qui a du sens et quelque chose qui peut être facilement surveillé.

Les gens sous-estiment la complexité du système toujours disponible.

Pour m'adresser à l'éléphant dans la pièce, permettez-moi de dire ceci: "Aucun système multi-ordinateur n'est disponible à 100%, il se peut qu'à l'avenir mais pas avec la technologie actuelle." Ici, par la technologie actuelle, je fais référence à notre incapacité à envoyer des signaux plus rapidement que la vitesse de la lumière et de telles choses. Tous les ingénieurs comp-sci dignes de ce nom connaissent les limites de l'informatique distribuée , et la plupart d'entre eux ne le mentionneront pas lors des réunions, craignant de ressembler à des noobs. Pour compenser tous ceux qui ne mentionnent pas les limitations de l'informatique distribuée, je dirai que c'est compliqué mais ne faites pas toujours confiance aux ordinateurs .

Les gens surestiment leurs capacités d'ingénieur

Malheureusement, la disponibilité tombe dans la catégorie, où vous ne savez pas ce que vous voulez mais vous savez ce que vous ne voulez pas. Il est un peu plus délicat que la catégorie «connaître les besoins» comme l'interface utilisateur. Il faut un peu d'expérience et beaucoup de lecture pour apprendre de l'expérience des autres et encore plus.

Construire un système disponible à partir de zéro

Assurez-vous que vous évangéliserez à chaque équipe d'architecture et de conception la bonne priorité de la disponibilité en tant qu'exigence du système.

Attributs du système favorisant la disponibilité

Les caractéristiques du système suivantes ont montré qu'elles ont contribué à la disponibilité du système:

Redondance

Certains exemples de cela sont de ne jamais avoir qu'une seule machine virtuelle derrière un VIP ou de ne jamais stocker qu'une seule copie de vos données. Ce sont les questions qu'un bon IAAS vous facilitera la tâche, mais vous devrez toujours prendre ces décisions.

Modularité

Un REST modulaire est meilleur qu'un SOA monolithique. Un microservice même modulaire est en fait plus disponible que le HATEOS REST habituel . Le raisonnement peut être trouvé dans la discussion relative au rendement dans la section suivante. Si vous effectuez un traitement par lots, mieux vaut un traitement par lots dans un lot raisonnable de 10 par rapport à un lot de 1 000 000.

Élasticité

"I am always angry"
                    - Hulk

Un système résilient est toujours prêt à récupérer. Cette résilience s'applique à des instances telles que la reconnaissance d'un ACK pour une écriture uniquement après l'écriture sur un disque RAID, et éventuellement sur au moins deux centres de données. Une autre tendance récente consiste à utiliser des structures de données sans conflit , où la structure de données assume la responsabilité de résoudre les conflits lorsqu'elle est présentée avec deux versions différentes. Un système ne peut pas être résilient après coup, il doit être prévu et intégré. Un échec est garanti sur le long terme, nous devons donc toujours être prêts avec un plan de redressement.

Sentier des journaux

C'est techniquement un sous-type de résilience, mais très spécial car il capture toutes les capacités. Malgré tous les efforts, nous ne pouvons peut-être pas prédire le modèle d'indisponibilité. Si possible, conservez suffisamment de journal des activités système pour pouvoir lire les événements système. Cela, à un coût manuel élevé, vous permettra de vous remettre de situations imprévues.

Attributs de disponibilité

La liste d'attributs non exhaustive de la «disponibilité»: Pour la discussion, supposons que la question que l'utilisateur pose est: «Combien d'articles ai-je dans mon panier?»

Exactitude

Avez - vous devez produire la réponse la plus précise possible ou est - ce ok faire des erreurs? Juste pour référence, lorsque vous retirez de l'argent à un guichet automatique, il n'est pas garanti qu'il soit correct. Si la banque découvre qu'elle a fait une erreur, vous pourriez annuler les transactions. Si votre système produit des nombres premiers, alors je suppose que vous voudrez peut-être toujours les bonnes réponses.

rendement

Ignorez ce point, si vous avez toujours répondu correctement à la question précédente. Parfois, la réponse aux questions n'a pas à être précise, par exemple, combien d'amis ai-je sur Facebook en ce moment? Mais la réponse devrait être dans le stade +/- 1 tout le temps. Lorsque vous produisez le résultat attendu, votre rendement est de 100.

Cohérence

Votre réponse peut être correcte à un moment donné, mais au moment où la lumière a quitté l'écran et est entrée dans la rétine de l'observateur, les choses auraient pu changer. Cela rend-il votre réponse fausse? Non, cela rend tout simplement incohérent. La plupart des applications sont finalement cohérentes, mais l'astuce consiste à définir le type de modèle de cohérence que votre application va fournir. Par hasard, votre application peut fonctionner sur un seul ordinateur, vous pouvez ignorer cette belle lecture sur le théorème de CAP .

Coût

Beaucoup dépend de l'impact total des effets à court terme (perte de revenus) et des effets à long terme (mauvaise réputation, fidélisation de la clientèle). Selon le type de client (payant / gratuit, répété / unique, captif) et la disponibilité des ressources, différents niveaux de garanties de disponibilité doivent être intégrés.

Vers l'amélioration de la disponibilité d'un système existant

La gestion opérationnelle des machines individuelles et d'un réseau est si complexe que je suppose que vous l'avez laissé au fournisseur de cloud ou que vous êtes déjà suffisamment expert pour savoir ce que vous faites. Je toucherai d'autres sujets sous disponibilité. Pour la stratégie à long terme, Définir-Mesurer-Analyser-Contrôler est un match paradisiaque, quelque chose que j'ai vu moi-même.

1. Définissez ce qu'est la «disponibilité» pour vos parties prenantes
2. Comment allez-vous mesurer ce que vous avez défini
3. Analyse des causes profondes pour identifier les goulots d'étranglement
4. Tâches d' amélioration
5. Surveillance continue ( contrôle ) du système

Causes de non-disponibilité

Puisque nous avons convenu que la gestion opérationnelle, qui couvrirait toute gestion d'infrastructure physique, devrait être effectuée par des professionnels, je toucherai à d'autres causes d'indisponibilité pour des raisons d'exhaustivité. La disponibilité de l'OMI doit également inclure le manque de comportement attendu, ce qui signifie que si l'utilisateur ne voit pas l'expérience attendue, alors quelque chose n'est pas disponible. Avec cette définition large à l'esprit, les éléments suivants pourraient entraîner une indisponibilité: - Bogues de code - Incidences de sécurité - Problèmes de performances