Modèle de conception de service partagé de technologie Fujitsu K5 – Haute disponibilité

2017-01-13

Machine-translated — the English original is authoritative.

Le modèle de conception suivant est un exemple de la manière dont une plateforme de service partagé technologique pourrait être implémentée sur K5. La différence entre cette architecture et le blog précédent sur les services partagés est que j’ai inclus nos connecteurs Inter-Disponibilité-Zone pour fournir un lien interne à haute vitesse entre les sous-réseaux dans les différentes Zones de Disponibilité (AZ). Il est désormais possible de s’assurer que vos applications de style traditionnel ou vos applications cloud native puissent être facilement distribuées sur les deux AZ. Le trafic réseau ne traverse pas Internet. L’ensemble de l’architecture présentée ci-dessous peut être déployé automatiquement avec un effort minimal grâce aux piles HEAT, le projet d’orchestration d’infrastructure K5/OpenStack.

Note pour les utilisateurs natifs d’OpenStack : Les liens InterProjet et InterZone de Disponibilité discutés ici sont des améliorations que Fujitsu a apportées à l’API Neutron d’OpenStack pour une utilisation dans le cloud public.

DMZ

Le projet DMZ est utilisé pour acheminer le trafic entrant et sortant de la solution. Un serveur proxy pourrait être utilisé pour fournir/contrôler l’accès Internet aux autres projets. Un serveur terminal https tel que Guacamole pourrait être installé dans chaque DMZ pour fournir un accès redondant aux consoles des serveurs.

Deux routeurs virtuels sont installés dans chaque AZ. L’un gère tout le routage inter-projets et le second est utilisé conjointement avec le FWaaS pour contrôler l’accès à la frontière Internet. Une instance LBaaS facultative orientée publique pourrait être utilisée ici pour fournir une HA pour le service Guacamole.

Services partagés

Ce projet serait utilisé pour héberger tous les services partagés que vous souhaitez fournir à vos autres projets, tels que l’e-mail (bien que n’oubliez pas que K5 propose également cette offre en tant que PaaS), le partage de fichiers, les dépôts git, etc. Un connecteur réseau est utilisé pour relier les sous-réseaux de services partagés entre les zones de disponibilité, ce qui facilite la synchronisation rapide des données entre les services critiques. Un LBaaS orienté interne pourrait également être utilisé ici si nécessaire. Par conception, ces sous-réseaux n’ont ni capacité de DNAT ni de SNAT. Il serait nécessaire d’exploiter un service proxy dans le DMZ (non inclus dans K5) pour y parvenir. L’alternative consisterait à relier ce sous-réseau directement à Internet via un autre routeur virtuel, ce qui briserait le modèle requis 🙂

Département A/B/C…etc

Il s’agit des projets que les utilisateurs finaux consommeraient. Ils peuvent bénéficier des mêmes fonctionnalités HA exposées que celles du projet Services partagés. Ce modèle permet un déploiement, une destruction et un redéploiement rapides et faciles pour répondre aux demandes tout en conservant les services principaux intacts.

Les groupes de sécurité sont utilisés tout au long du processus pour également fournir une couche supplémentaire de sécurité réseau pour tous les hôtes.

Résumé

Le modèle complet de services partagés peut être déployé rapidement et de manière cohérente à maintes reprises en utilisant les modèles HEAT d’Infrastructure as Code (IaC) de K5. De plus en plus de clients exploitent des modèles tels que celui-ci pour les aider dans leurs parcours d’Intégration Continue et de Déploiement Continu (CI/CD). Si cela vous intéresse, je vous recommande également de vous pencher sur Cloud Foundry pour le développement d’applications rapide – K5 propose également une plateforme Cloud Foundry.

Happy Stacking.

withk5youcan

Originally published on allthingscloud.eu (2017-01-13).