Guide de mise à niveau vers Data Center
Chaque organisation est unique, comme votre parcours de migration. Suivez notre guide de mise à niveau pas-à-pas pour assurer une transition fluide d'Atlassian Server vers Data Center.
Évaluer
Chaque organisation a des besoins et des exigences uniques. Il est donc important de comprendre vos choix afin de planifier une mise à niveau réussie.
Comprendre les exigences de votre architecture et de votre infrastructure
Vous optez pour Data Center ? Vous devez vous familiariser avec l'architecture Data Center et les configurations de déploiement prises en charge.
Vous pouvez déployer Data Center de deux manières : hors cluster et en cluster. Ces deux types de déploiement vous permettent de tirer parti des fonctionnalités et des capacités Enterprise, mais chaque option nécessite des considérations différentes. Voici un tableau qui décrit les différences entre les architectures hors cluster et en cluster :
Hors cluster Recommandé
Exigences en matière d'infrastructure
Une architecture hors cluster vous permet de mettre à niveau vers Data Center sur votre infrastructure existante, de sorte que vous n'avez pas besoin de modifier l'infrastructure.
Cas d'usage recommandés
Nous recommandons à tous les clients de passer à Data Center en utilisant le chemin de mise à niveau hors cluster. Les clients peuvent implémenter une architecture en cluster après leur passage à Data Center si nécessaire.
Avantages
Débloquez les fonctionnalités Enterprise qui ne nécessitent pas de clustering :
Les mises à niveau hors cluster permettent généralement à de nombreux clients de commencer leur parcours vers Data Center. Nous vous recommandons de profiter de cette mise à niveau de 2 minutes pour vous assurer une transition en douceur.
En cluster
Nous recommandons à tous les clients de commencer par passer à Data Center en utilisant le chemin de mise à niveau hors cluster. Une fois la mise à niveau vers Data Center effectuée, les clients peuvent implémenter une architecture en cluster si nécessaire.
Exigences en matière d'infrastructure
Vous aurez besoin des composants suivants pour mettre à niveau vers Data Center en cluster :
- Équilibreur de charge
- Nœuds applicatifs
- Système de fichiers accessible par tous les nœuds applicatifs
- Nœud Elasticsearch (Bitbucket)
Cas d'usage recommandés
- Vous avez besoin d'une haute disponibilité
- Vous souhaitez effectuer une mise à niveau sans temps d'arrêt
- Vous vous attendez à passer à très grande échelle à court terme
Avantages
Débloquez les fonctionnalités métier apportées par la mise en cluster :
- Fonctionnalités et capacités Enterprise
- Haute disponibilité et basculement : si un nœud de votre cluster d'apps tombe en panne, les autres prennent la relève, ce qui garantit à vos utilisateurs un accès ininterrompu au produit.
- Évolutivité instantanée : ajoutez de nouveaux nœuds à votre cluster sans temps d'arrêt ni frais de licence supplémentaires. Les index et les apps sont automatiquement synchronisés.
- Reprise d'activité : déployez un système de reprise d'activité hors site pour assurer la continuité de l'activité, même en cas de panne complète du système. Les index de produits partagés vous permettent d'accélérer la remise en service.
Planifiez et préparez
Maintenant que vous avez choisi votre parcours de migration vers Data Center, vous êtes prêt à commencer à créer un plan de mise à niveau détaillé.
Définissez un calendrier Requis
Voici les délais de base que vous pouvez utiliser pour évaluer la durée de votre mise à niveau.
| | Hors cluster | En cluster |
|---|---|---|
| Planification | Hors cluster 0 à 2 semaines | En cluster Plus d'1 mois |
| Dry-run | Hors cluster 0 à 1 semaine | En cluster 3 à 6 mois |
| Lancement | Hors cluster 0 à 1 semaine | En cluster Environ 6 à 9 mois |
Les délais indiqués sont basés sur un certain nombre de nos clients qui ont mis à niveau vers Data Center avec succès. Toutefois, il est important de noter que le délai réel variera en fonction de facteurs propres à votre environnement, y compris, mais sans s'y limiter, la taille, la complexité et le degré de préparation de l'environnement.
Définissez votre environnement Data Center Requis
Couche applicative
Instances et emplacements
- Souhaitez-vous fédérer ou consolider vos instances ?
- Comment voyez-vous votre croissance future ?
- Avez-vous besoin d'isoler des données ?
- De combien d'environnements (notamment de staging ou de production) votre équipe dispose-t-elle ?
Profils de l'instance
- Combien de personnes vont accéder à votre instance ?
- Où vos équipes seront-elles situées ?
- Quel volume de données se trouve actuellement dans votre instance et quel volume prévoyez-vous d'ajouter à cette dernière ?
Apps, intégrations et personnalisations
Avez-vous besoin de tous ces éléments ou est-ce le moment de simplifier ?
Couche d'infrastructure
Taille de l'instance
- Comment voyez-vous votre croissance future ?
- Les niveaux de trafic utilisateur sont-ils plus faibles par moments ?
Pour en savoir plus, consultez notre présentation sur le dimensionnement des nœuds.
Structure des comptes
- Sur quels comptes votre environnement doit-il être déployé ?
- Souhaitez-vous associer différents comptes à chacun de vos environnements ?
- Souhaitez-vous que vos produits Data Center utilisent le même compte que vos autres outils de CI/CD ou de collaboration ?
Modèle de gouvernance
- À quoi ressemble votre modèle de gouvernance ?
- Quelles sont les normes minimales de votre système ?
- Utilisez-vous une journalisation centralisée ?
- Quels sont vos besoins en matière de gestion des utilisateurs ?
Pensez à utiliser AWS Landing Zone et AWS System Manager dans le cadre de votre modèle de gouvernance.
Cloud privé virtuel (VPC)
-
Voulez-vous utiliser un nouveau VPC ?
Que vous souhaitiez déployer dans un nouveau VPC ou utiliser un VPC existant, vous pouvez utiliser le modèle d'infrastructure Atlassian standard (ASI).
- Souhaitez-vous modifier certains principes réseau, tels que la limitation de l'accès Internet public et de l'adressage IP interne pour le routage de réseaux de bureau et VPN ?
- Devriez-vous utiliser des certificats TLS ?
Région
-
Si vous utilisez un VPC existant, avez-vous mis au point un plan d'accès aux réseaux de bureau et VPN ?
Nous vous recommandons d'autoriser l'accès à partir de tous les bureaux et VPN, car vos produits seront probablement de plus en plus utilisés au fil du temps.
Connexion directe
- Souhaitez-vous utiliser une connexion directe pour améliorer les performances et la sécurité ?
- Quel volume de données devez-vous migrer de votre instance Server vers Data Center ?
Vous pouvez envisager la gamme AWS Snow si vous migrez des volumes importants de données.
Continuité de l'activité et reprise d'activité
Sauvegarde
À quoi ressemble votre stratégie de sauvegarde ?
Nous vous recommandons de combiner votre stratégie de sauvegarde existante et les fonctionnalités de sauvegarde intégrées à AWS. Pour en savoir plus, cliquez sur les liens suivants :
AWS fournit des services d'infrastructure moins sujets aux pannes uniques.
Basculement de la région
Avez-vous besoin d'implémenter des sites en cold, warm ou hot standby dans différentes régions ?
En règle générale, vos besoins en matière de reprise d'activité sont satisfaits en exécutant vos services dans plusieurs zones de disponibilité, mais vous pouvez également avoir besoin de limiter les pannes régionales. Lorsque vous décidez d'implémenter ou non ces sites dans différentes régions, tenez compte de ce qui suit :
- Coût de l'infrastructure et du transfert de données
- Rapidité de reprise par rapport à AWS
- Temps consacré à la gestion et au test du site de reprise
- Coût de fonctionnement du site
Mettre à niveau vers Data Center (hors cluster) Recommandé
Nous recommandons à tous les clients de passer à Data Center en utilisant l'architecture hors cluster. Les mises à niveau hors cluster sont une option de mise à niveau plus rapide et plus simplifiée, qui permet d'accéder plus rapidement aux fonctionnalités de sécurité, de support et d'entreprise de Data Center.
Mettre à niveau vers Data Center (en cluster) Non recommandé
Nous ne recommandons pas les mises à niveau initiales de Data Center sur une architecture en cluster en raison de la complexité de la mise à niveau. Nous recommandons à tous les clients de commencer par passer à Data Center en utilisant le chemin de mise à niveau hors cluster. Ensuite, les clients qui ont besoin d'une architecture en cluster peuvent lancer leur implémentation.
Après votre migration vers Data Center sur une architecture hors cluster, vous pourrez implémenter une architecture en cluster si vous avez besoin d'une haute disponibilité.
Obtenez l'infrastructure dont vous avez besoin pour votre cluster
Pour déployer Data Center en cluster, vous aurez besoin des composants suivants :
- Base de données
- Équilibreur de charge
- Nœuds applicatifs
- Système de fichiers partagé
- Nœud Elasticsearch (Bitbucket)
Équilibreur de charge
L'équilibreur de charge est le premier élément concerné par les demandes de vos utilisateurs si vous avez effectué votre déploiement dans un cluster. Les demandes arrivent dans l'équilibreur de charge et celui-ci distribue ensuite chaque demande aux nœuds applicatifs. Vous pouvez utiliser un équilibreur de charge matériel ou logiciel. Tant pour les solutions logicielles que matérielles, l'équilibreur de charge doit être lié au cluster d'apps à l'aide d'une connexion LAN à haut débit afin de garantir une bande passante élevée et une faible latence. Tous les équilibreurs de charge logiciels doivent être exécutés sur des machines dédiées.
Les produits Data Center supposent que la demande de chaque utilisateur sera transmise au même nœud pendant une session. Si les demandes sont envoyées à des nœuds différents, les utilisateurs peuvent être déconnectés de manière inattendue, et ils peuvent même perdre les informations stockées dans leur session. Il est donc nécessaire de lier une session au même nœud en activant les « sticky sessions » (ou affinités de session) basées sur des cookies dans l'équilibreur de charge. Avec les « sticky sessions » basées sur des cookies, vous pouvez utiliser le cookie émis par le produit ou un cookie généré par l'équilibreur de charge.
Ajoutez une couche de protection supplémentaire et évitez que l'équilibreur de charge ne devienne un point de défaillance unique en intégrant une redondance à votre solution d'équilibrage de charge. Pour cela, vous pouvez configurer deux équilibreurs de charge dans une configuration actif-passif, en utilisant une adresse IP virtuelle sur les deux équilibreurs de charge. Si l'équilibreur de charge actif tombe en panne, il basculera sur l'équilibreur de charge passif.
Pour en savoir plus, consultez nos options de configuration de l'équilibreur de charge.
Nœuds applicatifs
Les nœuds applicatifs hébergent le produit proprement dit. Chaque nœud de votre cluster Data Center doit fonctionner sur la même version du produit et se situer au même emplacement pour limiter au maximum la latence. Cependant, vous pouvez activer un réseau de distribution de contenu (CDN) pour soutenir les performances de vos équipes géographiquement distribuées. Ces nœuds doivent être configurés en cluster, agissant comme un nœud unique, pour fournir le produit à vos utilisateurs. Le nombre de nœuds dans votre cluster dépend de vos besoins et de la façon dont vous configurez votre produit. Généralement, nous constatons que deux à quatre nœuds suffisent pour la plupart des clusters, mais n'hésitez pas à utiliser nos guides de dimensionnement des nœuds pour vous aider à prendre la bonne décision.
Bitbucket nécessite un nœud applicatif supplémentaire spécifiquement dédié à ElasticSearch, qui permet la recherche dans le code.
Système de fichiers partagé
Le système de fichiers partagé est l'emplacement de stockage des données qui doivent être accessibles depuis n'importe quel nœud applicatif, comme les fichiers joints et les dépôts Git.
Dans un environnement Data Center, vous devez configurer votre système de fichiers partagés comme son propre nœud. Vous pouvez utiliser n'importe quel programme NAS ou SAN basé sur NFS pour votre système de fichiers partagé, mais nous recommandons NFS3 pour maintenir vos performances. Veillez simplement à éviter les protocoles distribués comme DFS, car ils ne sont pas pris en charge.
Créez un environnement de staging
Pour réussir la mise à niveau vers un environnement multinœud, nous recommandons de créer un environnement de staging pour tester Data Center avant la mise en production.
Votre environnement de staging doit reproduire fidèlement votre environnement de production, y compris tout proxy inverse, toute configuration SSL ou tout équilibreur de charge. Vous pouvez décider d'utiliser un serveur physique différent ou une solution virtualisée. L'essentiel est de vous assurer qu'il s'agit d'une réplique appropriée de votre environnement de production.
Pour obtenir plus d'instructions, consultez :
Discutez avec un expert
Vous avez une question relative à vos options ou à votre parcours de migration ? Obtenez des conseils avisés de notre équipe de spécialistes de la migration.