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.
# Planification de la migration
La planification de votre processus de migration est essentielle pour garantir une migration fluide et réussie. Les sections suivantes décrivent comment planifier votre migration, ainsi que les principales considérations à prendre en compte à cet égard.
**Topics**
+ [Décider des éléments à migrer](migration-decision-process.md)
+ [Détartrage de vos configurations](descale-configurations.md)
+ [Choix du type d'instance](instance-choice.md)
+ [Principaux points de décision](key-decision-points.md)
+ [Vue d'ensemble de la migration](high-level-migration-overview.md)
# Décider des éléments à migrer
Lorsque vous migrez, vous devez décider quelles charges de travail sont essentielles, quelles charges de travail sont « agréables à avoir » mais pas essentielles, et quelles charges de travail ne sont pas nécessaires et peuvent être supprimées [une fois la migration terminée](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html).
Une partie importante de votre processus décisionnel impliquera les exigences individuelles que vous avez en matière d'automatisation, d'API, d'outillage et d'autres processus. Vous devrez également tenir compte des exigences fonctionnelles et de performance de votre organisation.
Par exemple, vous avez peut-être utilisé des plateformes matérielles partagées dans un centre de données existant avec des partitions utilisateur. Toutefois, votre migration peut nécessiter que les services s'exécutent sur des systèmes qui ne sont pas aussi largement partagés en raison des limites de performances liées au passage de solutions accélérées par le matériel. Par exemple, les transactions SSL (Secure Sockets Layer) par seconde (TPS) peuvent nécessiter qu'un certain service ne s'exécute pas sur un système partagé.
Après avoir identifié et documenté les applications à migrer ainsi que leurs exigences, vous devez préparer vos systèmes sources en appliquant les meilleures pratiques suivantes.
+ Exécutez la même version de F5 TMOS que celle que vous utiliserez dans le AWS cloud. [La version 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) ou ultérieure est recommandée, mais [la version 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) ou ultérieure peut également être utilisée. Bien que vous puissiez migrer la version [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html), vous pouvez rencontrer des problèmes de sécurité, d'automatisation et de maintenabilité.
+ Disposez de sauvegardes valides de toutes les configurations de chaque appareil. Étant donné que la sauvegarde du serveur d'entreprise Univention (UCS) contient des attributs et des objets spécifiques au centre de données (tels que des adresses IP, des nœuds ou des membres du pool), F5 vous recommande de créer un fichier de commandes shell (SCF) pour modifier et fusionner les configurations.
+ Conservez des copies de sauvegarde de tous les certificats de sécurité pertinents et envisagez de passer du chiffrement RSA au chiffrement ECC pour de meilleures performances.
+ Disposez de mesures de performance détaillées au niveau du serveur virtuel pour la mise à l'échelle et la planification des capacités.
+ Optez pour une solution [F5 Global Server Load Balancing (GSLB)](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) pour le passage du centre de données au cloud. AWS
+ Comprenez l'impact de la migration d'un modèle d'appliance matérielle vers un modèle logiciel et virtualisé en termes de performances, d'évolutivité et de haute disponibilité.
+ Ayez défini les exigences relatives à ce qui sera migré vers le AWS cloud et tenez compte des considérations suivantes.
+ Sachez que toute migration vers le AWS cloud nécessite de décider si des configurations complètes ou partielles seront migrées. Généralement, un déplacement partiel à la fois est plus efficace.
+ Déterminez quels itinéraires et quelles adresses IP seront modifiés.
+ Identifiez les pools SNAT à remplacer par F5 SNAT Automap.
Vous devriez également envisager de consulter [AWS des partenaires](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks) ou l'équipe des services professionnels de F5. Cela contribuera à garantir une forte probabilité de réussite de la migration.
# Détartrage de vos configurations
Le « détartrage » signifie le déplacement d'une configuration F5 BIG-IP vers une configuration inférieure ou plus rentable, en fonction des fonctionnalités ou des mesures requises après vos premières découvertes. Vous devez évaluer soigneusement toutes ces options car elles auront un impact sur l'architecture et le nombre d'instances requises.
Le schéma suivant vous aide à évaluer si le détartrage est adapté à vos besoins et exigences.
![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png)
La migration créera également de nouvelles considérations dans les domaines suivants.
+ **Topologie réseau** : actuellement VLANs, les `802.1q ` balises AWS ne sont pas prises en charge. Le nombre d'interfaces d'instance (moins une pour la gestion) limite le nombre de réseaux qu'une instance peut prendre en charge. Si vous avez besoin d'une topologie spécifique, vous devez l'évaluer par rapport aux différentes instances prises en charge par F5 dans le AWS Cloud.
+ **Performances SSL** — Les appliances et les châssis F5 ont des performances SSL supérieures à ce qui peut être accompli avec. `x86` Vous devez évaluer les exigences SSL agrégées et par serveur virtuel.
+ **Performances du réseau** : vous devez évaluer les caractéristiques agrégées, sortantes et internes du réseau. AWS les types d'instance présentent des caractéristiques de réseau différentes (faible, moyenne, élevée, jusqu'à X ou dédiée) qui doivent être prises en compte. Il existe également des limites quant à la quantité de trafic qu'une instance peut envoyer en provenance ou via une connexion directe.
+ **Densité VIP** — Si vous avez un plus grand nombre d'adresses IP virtuelles (VIPs), vous devez tenir compte de la limite d'instances au nombre d'adresses VIPs pouvant être mappées aux interfaces réseau.
+ **Connexion simultanée** : le nombre maximum de connexions que les instances peuvent prendre en charge est limité.
+ **État de session** : différentes applications utilisent différents types de persistance. Les applications dynamiques et apatrides modifieront les méthodes utilisées pour passer à l'état partagé, ce qui peut avoir un impact sur l'échelle des in/out opérations.
# Choix du type d'instance
F5 prend en charge plusieurs types d'instances et le choix de l'instance à utiliser peut s'avérer une décision complexe. Pour la plupart des migrations, `c5n.2xl` `c5n.4xl` ce seront les choix d'instance les plus courants, car ils offrent une combinaison de performances réseau, de densité du processeur, de densité d'interface et du nombre de ces IPs éléments pouvant être pris en charge sur l'instance. Le schéma suivant fournit des exemples des instances à choisir, en fonction des produits F5 que vous utilisez.
![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png)
# Principaux points de décision
De nombreux aspects de la migration doivent être pris en compte, mais avant de commencer la migration de votre charge de travail F5 BIG-IP, posez-vous les questions suivantes pour clarifier le processus de migration.
**Qui sont les utilisateurs de vos applications ?**
Déterminez s'il s'agit d'utilisateurs internes (ne passant pas par une adresse IP élastique) ou externes (passant par une adresse IP élastique). Si les utilisateurs sont internes, déterminez si l'application peut utiliser le DNS pour faire face à la défaillance d'une zone de disponibilité ou à un déploiement actif. Vous devez également vérifier si vous devez utiliser un autre modèle de conception permettant à un sous-réseau de couvrir plusieurs zones de disponibilité.
**Quelles parties de vos applications seront migrées vers le AWS cloud ?**
Déterminez si l'ensemble de l'application est en cours de déplacement ou uniquement le niveau de présentation. Vous devez également prendre en compte les dépendances supplémentaires liées à la sécurité et à l'espace de noms DNS. Votre évaluation doit déterminer ce qui serait requis à partir de la topologie du réseau. En outre, déterminez les exigences d'un accord de niveau de service (SLA) en cas d'événement survenant au niveau de la zone de disponibilité, du VPC ou de la région. AWS
**Pourquoi l'application migre-t-elle ?**
Vous êtes peut-être en train de migrer votre application parce que vous fermez des centres de données ou parce que vous souhaitez plus d'élasticité. Déterminez si l'application est en train de migrer pour disposer d'une architecture par application, par rapport aux modèles monolithiques partagés courants dans de nombreux centres de données. Il convient également de réfléchir aux efforts de modernisation qui devraient être déployés parallèlement à la migration.
**Où est effectuée la migration de l'application ?**
Déterminez si l'application doit passer à un seul VPC avec une ou deux zones de disponibilité. Déterminez la topologie du VPC homologue ou de transit, ainsi que la nécessité de déploiements multirégionaux. Cela aura un impact sur la conception du modèle de migration.
# Vue d'ensemble de la migration
Avant de commencer la migration, il est utile de définir l'ensemble du processus à partir d'un niveau élevé. Voici un exemple des étapes que vous pouvez suivre pour migrer une charge de travail F5 BIG-IP vers le cloud. AWS Vous trouverez des étapes et des processus plus détaillés pour une migration F5 BIG-IP dans le modèle [Migrer une charge de travail F5 BIG-IP vers F5 BIG-IP VE sur](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.html?did=pg_card&trk=pg_card) le cloud. AWS
1. Déployez le nombre requis VPCs en fonction de vos besoins individuels. Cela peut être manuel ou automatisé via un outil tel que [AWS Landing Zone](https://aws.amazon.com//solutions/implementations/aws-landing-zone/).
1. Évaluez les licences, les utilisations et les configurations F5 actuelles.
1. Évaluez les candidatures publiques et internes.
1. Évaluez les configurations F5 actuelles.
1. Évaluez les exigences en matière de taille et d'adresse IP, puis choisissez le nombre et le type de F5 et d' AWS instances requis.
1. Identifiez la stratégie de migration à déployer. Par exemple, levage et changement de vitesse ; levage, changement de vitesse et modernisation ; ou hybride.
1. Évaluez et identifiez la conception du DNS.
1. Évaluez comment le trafic sera dirigé vers l'application s'il existe à la fois sur site et dans le AWS cloud.
1. Effectuez les déploiements initiaux d'instances F5 à l'aide AWS CloudFormation de modèles.
1. Modifiez les déploiements pour répondre aux exigences topologiques grâce à des interfaces réseau élastiques et à des tables de routage supplémentaires.
1. Alignez les adresses IP élastiques sur celles de vous-même IPs ou de gestion IPs, et planifiez le mappage des adresses IP élastiques vers les adresses IP virtuelles (VIP).
1. Créez des adresses secondaires sur des interfaces réseau élastiques pour VIPs.
1. Appliquez des adresses secondaires dans le AWS cloud.
1. Mappez les adresses IP Elastic à l'adresse secondaire pour VIPs.
1. Extrayez les configurations et compilez une liste d'objets à déplacer.
1. Déployez les configurations sur F5 BIG-IP.
1. Mappez les adresses secondaires à VIPs.
1. Testez le trafic.
1. Testez le basculement.
1. Si vous créez un système hybride, assurez-vous d'intégrer le système dans F5 DNS.
**Important**
L'accès aux points de terminaison de AWS l'API est requis. Les adresses IP NAT ou Elastic sont également requises pour garantir une haute disponibilité au sein des zones de disponibilité ou entre celles-ci.
Le schéma suivant montre le flux de processus de haut niveau pour une migration F5 BIG-IP.
![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png)