Considérations de haute disponibilité sur AWS et Azure

108845

Created On 09/25/18 15:12 PM - Last Modified 06/15/23 22:35 PM

Resolution

À mesure que les clients commencent à utiliser la série VM pour protéger leurs applications et leurs données critiques dans le cloud public, la question «Supportez-vous la haute disponibilité dans AWS ou Azure» se pose. Le poste de novembre 2016 original (ci-dessous) n'a pas répondu clairement à la question. La réponse est oui, vous pouvez déployer une architecture avec la série VM sur AWS et Azure qui offre une haute disponibilité et une résilience requises pour les déploiements d'applications d'entreprise. Cependant, le diable est dans les détails de mise en œuvre.

VM-Series active-passive haute disponibilité sur AWS

Sur AWS, la série VM prend en charge la haute disponibilité active-passive à l'Aide de deux pare-feu de la série VM (actifs et passifs) déployés dans une seule zone de disponibilité AWS. Si une défaillance se produit, l'ENI AWS qui est lié au pare-feu de la série VM active est déplacé vers le pare-feu passif de la série VM. Le déménagement ENI se fait via un appel API à AWS qui prend généralement jusqu'à 60 secondes, mais parfois plus. Le retard est un sous-produit de la façon dont le tissu AWS fonctionne, et non contrôlée par la VM-Series. Pendant ce temps, certaines sessions peuvent être perdues, mais l'état est maintenu.

L'Utilisation de passif actif de cette manière permet de fournir une haute disponibilité dans la définition traditionnelle. En plus du temps de latence de basculement, cet ha passif actif ne peut pas couvrir plusieurs zones de disponibilité en raison de la limitation AWS de ne pas autoriser les mouvements ENI à span AZS. En outre, les deux licences de la série VM sont actives, tout comme les ressources AWS requises pour les maintenir en cours d'exécution, ce qui entraîne des considérations de dépense.

VM-Series sur la documentation AWS haute disponibilité

VM-Series haute disponibilité sur AWS (entrant à l'Aide de l'intégration Auto Scaling & ELB)

Une autre approche pour fournir le niveau de centre de données haute disponibilité est d'utiliser le tissu Cloud pour construire des HA qui peuvent couvrir plusieurs AZs dans votre déploiement. La mise à l'échelle automatique de la série VM et l'intégration ELB vous permettent d'atteindre cet objectif final pour le trafic entrant.

La mise à l'échelle automatique de la série VM sur AWS déploie plusieurs pare-feu sur deux zones de disponibilité au sein d'un VPC. Si L'un des pare-feu de la série VM échoue, deux choses se produisent: tout d'abord, l'équilibreur de charge AWS détecte l'échec et détourne le trafic vers les pare-feu restants et sains de la série VM-cela se produit généralement en quelques secondes en fonction des paramètres de santé prouver. Deuxièmement, les groupes de mise à l'échelle d'AWS auto supprimeront automatiquement les pare-feu malsains et les remplaceront par de nouveaux pare-feu de la série VM amorcés qui seront entièrement configurés, autorisés et prêts à gérer le trafic.

En fonction de l'équilibre des performances et de la sensibilité aux coûts, les contrôles de santé et les groupes de mise à l'échelle automatique peuvent être réglés pour être très agressifs ou très conservateurs sur la détection et le remplacement des composants défectueux. Cela vous permet de prendre votre propre décision de coûts/avantages lors de la conception de votre déploiement. La VM-Series non seulement automatiquement les échelles d'in et out, il est également auto-guérison fournissant une solution globale, très disponible sur plusieurs zones de disponibilité.

Mise à l'échelle automatique de la série VM sur les ressources de déploiement AWS

Mise à l'échelle automatique de la série VM pour éclairage AWS

VM-Series haute disponibilité sur AWS (Multi-AZ utilisant des fonctions lambda)

Une autre alternative consiste à utiliser une solution basée sur lambda prise en charge par la communauté créée par Cloudticity pour les clients qui ont besoin d'hectares qui couvrent plusieurs zones de disponibilité. Dans ce scénario de déploiement, une fonction lambda surveille l'intégrité de la série VM déployée dans chaque AZ. Chaque AZ dispose d'un pare-feu principal actif pour gérer le trafic. Si un pare-feu de la série VM échoue, une autre fonction lambda redirigera le trafic vers un pare-feu de la série VM secondaire déployé dans un autre AZ.

Solution Multi-AZ HA utilisant des ressources lambda

VM-Series sur Azure haute disponibilité

Pour la série VM sur les déploiements Microsoft Azure, une haute disponibilité est obtenue en utilisant plusieurs instances de la série VM à l'Aide des ressources Azure ci-dessous.

Haute disponibilité de la série VM sur Azure (entrant via application Gateway & load balancer Integration)

La haute disponibilité de la série VM sur Azure peut être obtenue à l'Aide des ensembles de disponibilité Azure combinés avec la passerelle d'Application et l'intégration de l'équilibrage de charge. Les ensembles de disponibilité répondent au besoin de disponibilité élevée et de résilience en minimisant ou en éliminant l'impact négatif qu'une maintenance d'infrastructure Azure ou des erreurs système peuvent avoir sur votre entreprise en distribuant les charges de travail entre différents hôtes. Déployé en tant que sandwich d'équilibrage de charge, la passerelle d'application agit comme l'avant de l'équilibreur de charge externe qui termine l'application tandis que l'équilibreur de charge agit comme mécanisme de distribution du trafic interne, distribuant le trafic à votre application Web.

Le trafic est distribué aux deux pare-feu de la série VM, chacun étant assigné à un ensemble de disponibilité différent. Si un pare-feu de la série VM échoue, le trafic est redirigé vers les autres pare-feu de la série VM en bonne santé par la passerelle d'application Azure. Lorsque la série VM est réparée (par la fonctionnalité Set de disponibilité), le trafic est ensuite redistribué à nouveau. Cette architecture offre non seulement une évolutivité, mais également une résilience et une haute disponibilité grâce à la prise en charge des ensembles de disponibilité Azure.

Évolutivité de la série VM et ressources de déploiement de résilience

Lire l'évolutivité et la résilience de la série VM pour Azure Tech Brief

Haute disponibilité de la série VM sur Azure (entrant et sortant à l'Aide de l'intégration d'Application Gateway & load balancer)

Pour répondre à la nécessité de la haute disponibilité entrante et sortante sur Azure, le modèle de bras basé sur la Communauté peut être utilisé pour déployer des pare-feu à charge équilibrée distincts pour le trafic entrant et sortant. Chaque pare-feu se compose de deux ou plusieurs pare-feu de la série VM dans un jeu de disponibilité afin qu'ils puissent être gérés de manière indépendante et mis à l'échelle dans ou hors pour accueillir la charge. Le trafic entrant de la passerelle d'application est reçu par l'équilibreur de charge entrant qui distribue le chargement à une instance du pare-feu de la série VM entrante. Le pare-feu applique la stratégie de sécurité et achemine le trafic sécurisé vers l'équilibreur de charge backend qui distribue le chargement à une instance de la charge de travail Web backend.

Charges de travail Web sécurisées sur Internet sur les ressources de déploiement Azure

Charges de travail Web sécurisées sur Internet sur le livre blanc Azure

-----------Message original: novembre, 2016-----------

Comme les clients regardent pour déplacer leurs applications et les données au nuage public, il n'est pas rare d'entendre des questions autour des constructions traditionnelles de centre de données telles que la haute disponibilité (ha) se posent. La question est souvent posée comme "Comment pouvez-vous soutenir HA dans AWS ou Azure." Une façon plus centrée sur les nuages de poser la question serait "avons-nous besoin d'HA dans le nuage public?"

Pour répondre à la question, nous devons d'abord définir précisément ce que nous entendons par ha. Si la question est, avons-nous besoin d'une solution entièrement redondante et hautement disponible pour sécuriser les applications cloud public? Alors la réponse est certainement oui. Mais si la question est, avons-nous besoin Pan-OS état de basculement ha tout comme nous l'avons fait dans le cloud privé, alors la réponse n'est probablement pas.

Le cloud public consiste à exploiter des ressources partagées et à déployer des applications qui peuvent survivre à un échec n'importe où dans l'architecture. Cela comprend, mais ne se limite pas à un échec de:

un routeur virtuel
un pare-feu virtuel
un commutateur réseau
une instance d'application
une instance d'équilibrage de charge
un échec de la zone de disponibilité
même l'échec d'une région entière

Les clients sont probablement en utilisant des dizaines ou même des centaines d'applications sur votre ordinateur portable, tablette et smartphone qui utilisent l'infrastructure qui a eu un échec d'un certain type. Et 99% du temps, ils n'ont aucune idée de ce qui s'est passé. Certains équilibreur de charge ou le processus de commutation ou de routage contourné l'échec et l'application silencieusement essayé à nouveau avec peu ou pas d'interruption à l'utilisateur. Ainsi, l'accent pour l'intégration de notre sécurité pare-feu de la série VM dans l'application cloud public doit être sur les services de Cloud natif comme les groupes de mise à l'échelle automatique, l'équilibrage de charge élastique, le routage, etc et non pas sur Pan-os ha.

La VM-Series prend en charge ha pour AWS, mais il n'est généralement pas nécessaire si le client utilise la migration cloud public comme une occasion de mettre à jour leurs applications pour tirer parti des services Cloud natif pour construire une architecture résiliente qui maximise le temps de disponibilité. Beaucoup de clients commenceront leur migration vers le nuage public adhérant à une liste de configuration matérielle traditionnelle de centre de données (commutateurs redondants, routeurs, pare-feu, etc.) qui peuvent limiter la capacité de tirer parti de la puissance du nuage. En utilisant l'exigence de redondance en tant que pilote, puis en tirant parti du Cloud o atteindre, il permettra aux clients de: a) améliorer la disponibilité de l'application et b) réduire les coûts. Je sais que ce n'est pas toujours possible, mais l'essai de laisser ce bagage derrière.

Pour les clients qui n'ont pas d'autre choix que de déplacer une application héritée vers le cloud public, nous avons ha pour AWS et nous enquêtons sur ha pour Azure. Mais ça vient à un prix. Non seulement ils ont besoin d'un pare-feu passif en place et en cours d'exécution à tout moment (et le projet de loi qui va avec cela), mais HA dans le nuage public s'appuie sur les appels API qui peuvent prendre beaucoup plus longtemps que ce que nous pouvons faire dans le matériel sur l'infrastructure réseau dédié. Par exemple, dans AWS, notre solution HA repose sur un appel API pour déplacer les interfaces (ENI) d'un pare-feu défaillant vers le pare-feu passif. Dans la pratique, cela prend 30-45 secondes, mais parfois plus. Il y a de fortes chances que les sessions que l'ap devait sauver devront déjà être rétablies dans ce délai.

Au lieu de cela, se concentrer sur l'équilibrage de charge et le routage dynamique qui peut converger doit plus rapidement et laisser l'application traiter avec la réinstallation de session. Les nuages publics développent de nouveaux modèles architecturaux qui s'alignent bien avec les tendances générales dans les architectures d'applications it:

Utilisation de l'échelle horizontale (alias scale out) pour faire face à de plus grandes charges et la disponibilité.
La croissance des architectures basées sur le Web/http qui sont globalement moins étatiques; toute information d'état comme un cookie de session peut être reconstruite facilement ou est rendue redondante
Utilisation des architectures orientées services (SOA) comme les micro-services, souvent construits sur des conteneurs, pour décomposer le. pile d'application sur plusieurs niveaux qui sont à l'échelle indépendante derrière les équilibreurs de charge.

Dans ces environnements, les données de session sont stockées dans des services de base de données fiables, comme Amazon DynamoDB ou Amazon ElastiCache, et partagées par les serveurs d'applications. Par exemple, dans un service de panier, la session de cookie de l'utilisateur peut être sync'ed/stockée entre des serveurs Web afin que l'échec d'un serveur Web unique n'ait aucun impact sur l'expérience utilisateur. Les nouvelles architectures, dans les clouds publics et les nuages privés locaux, sont axées sur la fiabilité du service et non sur la fiabilité de la session.

Utilisation de la mise à l'échelle automatique pour la série VM sur AWS pour atteindre ha

Comme mentionné ci-dessus, tout déploiement AWS doit être conçu pour la résilience afin d'éliminer l'impact négatif qu'une défaillance de composant d'infrastructure peut avoir. Si une défaillance se produit, la solution doit être capable de détecter et d'acheminer un échec. Cela est également vrai pour la sécurité de la solution. La mise à l'échelle automatique de la série VM sur AWS offre des services ha à l'Aide du service Cloud natif.

La mise à l'échelle automatique de la série VM sur AWS déploie plusieurs pare-feu sur deux ou plusieurs zones de disponibilité au sein d'un VPC. Si L'un des pare-feu de la série VM échoue, deux choses se produisent: tout d'abord, l'équilibreur de charge AWS détecte l'échec et détourne le trafic vers les pare-feu de la série VM restants et sains. Deuxièmement, les groupes de mise à l'échelle automatique AWS supprimeront automatiquement les pare-feu malsains et les remplaceront par de nouveaux pare-feu de la série VM amorcés qui seront entièrement configurés et prêts à gérer le trafic.

En fonction de l'équilibre des performances et de la sensibilité aux coûts, les contrôles de santé et les groupes de mise à l'échelle automatique peuvent être réglés pour être très agressifs ou très conservateurs sur la détection et le remplacement des composants défectueux. Cela vous permet de prendre votre propre décision de coûts/avantages lors de la conception de votre déploiement. La série VM non seulement bascule automatiquement dans et hors, indépendamment des charges de travail, il est également auto-guérison fournissant une solution globale, très disponible sur plusieurs zones de disponibilité.

Utilisation de la passerelle d'Application Azure de la série VM et intégration de load balancer
pour atteindre ha

La série VM vous permet de déployer une solution d'évolutivité managée pour votre trafic de charge d'application Web entrante à l'Aide d'un équilibreur de charge «sandwich». La passerelle d'application agit comme l'équilibreur de charge externe, Front terminant l'application et servant de passerelle Internet pour l'ensemble du service. Il fournit le contrôleur ADC (application Delivery Controller) en tant que service et inclut l'équilibrage de charge de la couche 7 pour http et HTTPS, ainsi que des fonctionnalités telles que le déchargement SSL et le routage basé sur le contenu. Les pare-feu de la série VM déployés derrière la passerelle d'Application fourniront la sécurité complète de prochaine génération qui protégera les déploiements Azure des attaques par des menaces connues et inconnues. Après l'inspection de sécurité par le pare-feu, le trafic est envoyé à l'équilibreur de charge Azure agissant comme l'équilibreur de charge interne, qui distribue le trafic à vos applications Web. Cette architecture offre non seulement une évolutivité, mais aussi une résilience et une haute disponibilité grâce à la prise en charge des ensembles de disponibilité Azure

La passerelle d'application et l'équilibreur de charge traitent toutes les perturbations de trafic, les ensembles de disponibilité offrent une protection contre la maintenance planifiée et non planifiée de l'infrastructure Azure. Cela répond au besoin de résilience et de disponibilité en minimisant ou en supprimant l'impact négatif que la maintenance ou les erreurs système Azure peuvent avoir sur votre entreprise en distribuant les charges de travail entre différents hôtes.

Références

Slide 45-AWS re: inventer 2013- architectures d'Application haute disponibilité dans Amazon VPC (ARC202) |...
Page 11-Amazon Web Services-Architecture pour le Cloud: Best Practices- https://Media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf