Garantir une haute disponibilité pour les applications bancaires basées sur le cloud

Garantir une haute disponibilité pour les applications bancaires basées sur le cloud

Il est tentant de penser qu'un fournisseur de services cloud assurera la haute disponibilité de vos applications bancaires critiques basées sur le cloud. Le problème est qu'ils ne le font vraiment pas.

Assurer la haute disponibilité des applications bancaires basées sur le cloud PlatoBlockchain Data Intelligence. Recherche verticale. Aï.Assurer la haute disponibilité des applications bancaires basées sur le cloud PlatoBlockchain Data Intelligence. Recherche verticale. Aï.
Todd Doane, architecte de solutions, technologie SIOS

Votre fournisseur de cloud peut vous avoir aidé à configurer un cluster de machines virtuelles (VM) fonctionnant à partir de plusieurs centres de données ou zones de disponibilité (AZ). Il peut avoir implémenté un système de basculement automatisé pour garantir qu'une machine virtuelle de secours dans la configuration peut prendre le relais immédiatement si la machine virtuelle principale se déconnecte soudainement. Tout cela semble devoir offrir une haute disponibilité, n'est-ce pas ?

Mais regardez attentivement le contrat de niveau de service (SLA) décrivant la haute disponibilité : le SLA garantit qu'au moins une des machines virtuelles de votre système sera accessible au moins 99.9 %, voire 99.99 % du temps. Mais ce n'est pas une garantie de disponibilité des applications ou des données. Si la machine virtuelle restante ne peut pas accéder à l'infrastructure de stockage où résident vos applications et données bancaires, vos applications critiques sont effectivement hors ligne.

Garantir l'accessibilité au cloud

Comment pouvez-vous garantir que vos applications et données bancaires critiques restent hautement accessibles dans le cloud ou dans une configuration hybride sur site/cloud, si la configuration de la technologie sous-jacente pour le basculement automatisé sur plusieurs AZ est insuffisante ?

Commençons par dire que la répartition des machines virtuelles en cluster sur plusieurs AZ est essentielle pour garantir la haute disponibilité (HA) de vos applications et données clés. Cependant, ce dont vous avez besoin en plus, c'est d'une stratégie pour vous assurer que chacune de ces machines virtuelles a accès aux applications et aux données critiques que vous souhaitez continuer à exécuter. C'est là que les approches traditionnelles de la haute disponibilité divergent lorsqu'il s'agit du cloud.

Dans une configuration HA traditionnelle, c'est-à-dire sur site, vous pouvez créer un cluster de basculement composé de plusieurs serveurs ou machines virtuelles et d'un réseau de stockage (SAN), où résident vos applications et vos données. N'importe quel serveur ou machine virtuelle du cluster pourrait interagir avec les applications et les données du SAN, donc si la machine virtuelle exécutant activement une application clé se déconnectait soudainement, le cluster basculerait automatiquement vers une autre machine virtuelle qui pourrait interagir avec le SAN et commencer à exécuter le l'application et la mise à jour de la même base de données que la machine précédente utilisait.

Configuration pour le cloud

Dans le cloud, cependant, il n'y a pas vraiment d'option pour créer un SAN partagé. Il existe certaines options de stockage partagé, mais elles ne sont pas conçues pour fournir les performances ou les niveaux de haute disponibilité dont vos applications bancaires critiques ont besoin. Au lieu de cela, les configurations HA basées sur le cloud dépendent d'un stockage hautes performances attaché à chacune des machines virtuelles du cluster. Lorsqu'une machine virtuelle donnée exécute une application, elle interagit avec des données stockées dans une base de données qui réside dans le stockage attaché à cette machine virtuelle.

La clé de la haute disponibilité pour les applications bancaires basées sur le cloud est donc de s'assurer que chaque machine virtuelle de votre cluster dispose toujours des mêmes applications et des mêmes données. De cette façon, si la machine virtuelle principale du cluster s'éteint soudainement, le cluster peut automatiquement basculer vers une machine virtuelle de secours, chacune d'entre elles pouvant commencer à exécuter l'application et interagir avec les données immédiatement car une copie de l'application et des données réside dans son propre stockage attaché.

Votre fournisseur de cloud peut facilement configurer les machines virtuelles qui fourniront les niveaux de performances et de disponibilité exigés par vos applications critiques. Il peut également attacher des systèmes de stockage hautes performances à ces machines virtuelles et configurer votre cluster pour un basculement automatique sur plusieurs AZ. Ensuite, vous devez déployer un mécanisme qui automatise la réplication synchrone des données entre tous les systèmes de stockage attachés aux machines virtuelles de votre cluster de basculement.

Solutions de réplication de données

Vous avez un certain nombre de choix en matière de solutions de réplication de données.

Si votre cluster est basé sur Windows et que vous utilisez Microsoft SQL Server, vous pouvez utiliser la fonction de groupes de disponibilité (AG) intégrée de SQL Server, qui répliquera automatiquement les bases de données SQL nommées par l'utilisateur sur chacun des nœuds de votre cluster. L'inconvénient de cette approche est qu'elle réplique uniquement les bases de données SQL, plutôt que chaque bloc de données en stockage. La réplication de plusieurs bases de données SQL Server sur plusieurs machines virtuelles de secours peut devenir très coûteuse car vous devrez utiliser SQL Server Enterprise Edition pour répliquer plusieurs bases de données ou pour répliquer des bases de données sur plusieurs machines virtuelles, même si vos applications fonctionnent parfaitement avec SQL Server Standard Edition. .

Vous pouvez également utiliser une solution de clustering sans SAN, qui fournit une réplication automatisée au niveau des blocs des données de la machine virtuelle principale active vers chacune des machines virtuelles secondaires d'un cluster. L'avantage d'utiliser une solution de clustering sans SAN est qu'elle est indépendante des applications et des bases de données ; il réplique simplement des blocs de données d'un système de stockage à un autre, garantissant que toutes les données de votre système de stockage principal sont répliquées sur chacune des autres machines virtuelles. L'inconvénient d'une approche de clustering sans SAN est qu'il existe encore un autre logiciel pour votre équipe informatique à acquérir et à apprendre, ce qui peut sembler onéreux si vous pouvez utiliser la fonctionnalité AG de SQL Server sans frais supplémentaires.

La réplication des données est la clé pour assurer la haute disponibilité des systèmes bancaires basés sur le cloud, que vous utilisiez la fonctionnalité intégrée à une solution telle que SQL Server ou la fonctionnalité fournie par une solution de clustering sans SAN indépendante.

Votre fournisseur de cloud peut fournir l'infrastructure hautes performances exigée par vos applications, mais vous devez vous assurer que les données et les applications disponibles pour chacune des machines virtuelles de ce cluster sont à jour si votre solution HA doit fonctionner comme prévu lorsque vous en avez besoin. le faire.

Todd Doane est architecte de solutions chez SIOS Technology. Il a passé plus de 20 ans, principalement dans le monde des services financiers, à créer des architectures de référence à haute disponibilité et des modèles et principes de conception spécifiques aux applications.

Horodatage:

Plus de Innovation bancaire