Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Exemple de cas d'utilisation automobile chez Example Corp.
Cette section du livre blanc explique comment les considérations, les questions de définition des exigences et les arbres de décision sont utilisés pour vous aider à choisir la conception optimale du réseau hybride. Il est important d'identifier et de saisir les exigences, car elles sont utilisées comme entrée dans les arbres de décision. La saisie des exigences dès le départ permet d'éviter de nouvelles itérations de conception. L'interruption complète d'un projet si la conception doit être revue et la mise en attente de ressources précieuses peuvent être minimisées et, idéalement, évitées lorsque les exigences sont comprises dès le départ.
Example Corp. Automotive sera utilisé tout au long de cette section en tant que client indicatif. Ils cherchent à déployer dans un premier temps leur premier projet d'analyse surAWS. Le projet d'analyse est axé sur l'analyse des données des voitures fabriquées par l'entreprise et d'autres ensembles de données qui existent déjà dans les centres de données de l'entreprise. Dans un premier temps, le groupe d'architecture de l'entreprise pense avoir besoin d'un Compte AWS Amazon VPC et de quelques sous-réseaux pour héberger les environnements de production et de développement. L'équipe du projet est impatiente de commencer et a demandé l'accès à l'environnement de développement dès que possible. Leur objectif est d'entrer en production dans trois mois.
Example Corp. Automotive prévoit également de l'utiliser AWS pour plusieurs autres projets, tels que la migration de ses systèmes ERP, de son infrastructure de bureau virtuel (VDI) et de 20 autres applications depuis ses installations sur site au AWS cours des 6 prochains mois. Certaines exigences relatives à des projets supplémentaires sont encore en cours de définition, mais il est clair que leur AWS Cloud utilisation va augmenter.
L'équipe d'architecture a décidé de tirer parti de l'approche décrite dans ce livre blanc. Ils ont utilisé les questions de définition des exigences décrites sous chaque considération pour saisir les entrées nécessaires à la prise de décisions de conception.
Ils commencent par les exigences liées au type de connectivité, qui sont résumées dans le tableau suivant.
Tableau 4 — Exemples d'entrées de fiabilité d'Automotive Corp
| Considérations relatives au choix du type de connectivité | Questions relatives à la définition des exigences | Réponses |
|---|---|---|
| Il est temps de déployer | Quel est le calendrier requis pour le déploiement ? Des heures, des jours, des semaines ou des mois ? |
|
| Sécurité | Vos exigences et politiques de sécurité autorisent-elles l'utilisation de connexions chiffrées sur Internet pour vous connecter AWS ou imposent-elles l'utilisation de connexions à un réseau privé ? |
|
| Lorsque vous utilisez des connexions réseau privées, la couche réseau doit-elle fournir un chiffrement en transit ? | Non, le chiffrement de la couche application sera utilisé. | |
| SLA | Un contrat de niveau de service de connectivité hybride assorti de crédits de service est-il requis ? |
|
| Quel est l'objectif de disponibilité ? |
|
|
| L'ensemble du réseau hybride respecte-t-il l'objectif de disponibilité ? |
|
|
| Performances | Quel est le débit requis ? |
|
| Quelle est la latence maximale acceptable entre un réseau local AWS et un réseau local ? |
|
|
| Quelle est la gigue maximale acceptable sur le réseau ? |
|
|
| Coût | À quelle quantité de données enverriez-vous AWS par mois ? |
|
| À partir de quelle quantité de données enverriez-vous AWS par mois ? |
|
|
| Cette connectivité est-elle permanente ? | Oui |
Sur la base des exigences reçues, l'équipe d'architecture a suivi l'arbre de décision relatif au type de connectivité illustré à la figure 9. Cela a permis à l'équipe d'architecture de décider du type de connectivité pour les environnements de développement, de test et de production. En ce qui concerne l'environnement de production, ils ont pris en compte les exigences immédiates et à venir. Pour le développement et les tests, Example Corp. Automotive établira un site-to-site VPN sur Internet. Pour la production, ils travailleront avec un fournisseur de services auquel ils connecteront leur réseau d'entrepriseAWS Direct Connect. Example Corp. Automotive a initialement envisagé d'utiliser une connexion hébergée Direct Connect, mais en raison des exigences d'un SLA AWS fourni
Après avoir choisi le type de connectivité, l'étape suivante consiste à identifier les exigences qui ont une incidence sur le choix de la conception de connectivité. Cela est lié à la conception logique, notamment à la manière dont les connexions sont configurées et AWS aux services à utiliser pour répondre aux exigences commerciales et techniques.
Pour saisir les exigences en matière d'évolutivité et de modèle de communication, l'équipe d'architecture a utilisé les questions de définition des exigences figurant dans les sections associées de ce livre blanc. Les exigences liées à ces deux considérations sont résumées dans le tableau suivant.
Tableau 5 — Questions relatives à la définition des exigences
| Considérations relatives au choix du design de connectivité | Questions relatives à la définition des exigences | Réponses |
|---|---|---|
| Scalabilité | Quel est le nombre actuel ou prévu de VPC nécessitant une connectivité à des sites sur site ? | 2 au départ, passant à 30 en 6 mois |
| Ces VPC sont-ils déployés dans une Région AWS ou plusieurs régions ? | Région unique | |
| À combien de sites locaux faut-il se connecter ? AWS | 2 centres de données | |
| Combien de dispositifs de passerelle client avez-vous, par site, auxquels vous devez vous connecter AWS ? | 2 routeurs par centre de données | |
| Combien de routes devraient être annoncées aux AWS VPC ainsi que le nombre de routes attendues depuis le côté ? AWS |
|
|
| Est-il prévu d'envisager une augmentation de la bande passante de la connexion AWS dans un futur proche ? |
|
|
| Modèles de conception de connectivité | L'activation de la communication entre VPC est-elle obligatoire (au sein d'une région et/ou entre régions) ? | Oui, dans un Région AWS |
| Est-il obligatoire d'accéder aux services de points de terminaison AWS publics directement depuis les locaux ? | Oui | |
| Est-il nécessaire d'accéder aux AWS services à l'aide de points de terminaison VPC sur site ? | Non |
Sur la base des contributions, l'équipe d'architecture a suivi l'arbre de décision de la section Conception de la connectivité. Après avoir prévu que le nombre de VPC passerait de 2 à 30 au cours des 6 prochains mois, l'équipe d'architecture a décidé de les utiliser AWS Transit Gateway comme passerelle de terminaison pour la connexion et pour le routage inter-VPC. Independent AWS Transit Gateway s mettra fin à la connexion VPN utilisée pour le développement et les tests, ainsi que pour la connectivité de production avecAWS Direct Connect. L'utilisation de AWS Transit Gateway s séparés simplifie la gestion des modifications et fournit une démarcation claire entre les environnements de développement/test et de production. Pour la production, une AWS Direct Connect passerelle est requise en raison deAWS Transit Gateway. Un VIF public sera utilisé pour accéder aux services de point de terminaison AWS publics. La figure 14 illustre le chemin emprunté dans l'arbre de décision en fonction des exigences collectées.
Figure 14 — Arbre décisionnel relatif à la conception des connexions automobiles de Example Corp.
Après avoir choisi la solution répondant aux exigences d'évolutivité et de modèle de communication, l'étape suivante consiste à identifier les exigences associées à la fiabilité. Cela est lié au niveau de disponibilité et de résilience requis.
Pour définir les exigences de fiabilité, l'équipe d'architecture a utilisé les questions de définition des exigences figurant dans la section associée de ce livre blanc. Les exigences sont résumées dans le tableau suivant.
Tableau 6 — Questions relatives aux exigences de fiabilité
| Considérations relatives au choix du design de connectivité | Questions relatives à la définition des exigences | Réponses |
|---|---|---|
| Fiabilité | Quelle est l'ampleur de l'impact sur l'entreprise en cas de panne de connectivité AWS ? |
|
| D'un point de vue commercial, le coût lié à une panne de connectivité est-il supérieur au AWS coût du déploiement d'un modèle de connectivité hautement fiable pour ? AWS |
|
Sur la base des contributions reçues, l'équipe chargée de l'architecture a suivi l'arbre décisionnel décrit dans les sections sur les considérations de fiabilité abordées précédemment dans ce livre blanc. Après avoir pris en compte l'objectif de disponibilité de 99,99 % pour la connectivité de production et l'impact commercial élevé en cas d'interruption de service, l'équipe d'architecture a décidé d'utiliser 2 sites Direct Connect et de disposer de 2 liens entre chaque centre de données sur site et chaque site Direct Connect (4 liens au total). La connectivité VPN utilisée pour le développement et les tests utilisera également deux connexions VPN pour une redondance supplémentaire. À l'aide des techniques d'ingénierie des routes décrites dans la section sur la fiabilité, la connectivité sera configurée comme suit :
-
Pour le développement et les tests, le trafic sera équilibré à l'aide de l'ECMP sur les 2 tunnels destinés au centre de données principal. Cela permet un débit plus élevé. Les tunnels destinés au centre de données secondaire seront utilisés en cas de défaillance des tunnels principaux.
-
Pour la production, la latence entre les sites sur site et AWS sur l'un ou l'autre des sites Direct Connect est très similaire. Dans ce cas, il a été décidé d'équilibrer la charge du trafic entre AWS et sur site sur les deux connexions destinées au centre de données principal pour les systèmes sur site déployés dans le centre de données principal. De même, pour les systèmes sur site exécutés dans le centre de données secondaire, le trafic sera équilibré entre les deux connexions au centre de données secondaire. En cas d'échec des connexions, le BGP facilitera un basculement automatique.
La figure 15 illustre le chemin emprunté dans l'arbre de décision en fonction des exigences collectées.
Figure 15 — Arbre décisionnel relatif à la fiabilité du secteur automobile d'Example Corp.
