Migration d'un déploiement Oracle Database sur site vers un système de base de données Bare Metal
Simplifiez vos opérations de provisionnement, de maintenance et de gestion de base de données en déplaçant vos déploiements sur site volumineux d'Oracle Database Enterprise Edition vers Oracle Cloud Infrastructure.
Architecture
Cette architecture présente les ressources et la topologie requises pour migrer un déploiement sur site d'Oracle Database Enterprise Edition vers un système de base de données Bare Metal à noeud unique dans Oracle Cloud Infrastructure.
![Description de l'image migrate-bmdb.png Description de l'image migrate-bmdb.png](img/migrate-bmdb.png)
Description de l'illustration migrate-bmdb.png
L'architecture comporte les composants suivants :
- Déploiement sur site
Le déploiement sur site inclut un serveur d'applications exécuté sur un serveur Intel à deux cœurs et une instance Oracle Database Enterprise Edition sur un serveur Intel à 16 cœurs. Le serveur de base de données est connecté à un périphérique de stockage. Le réseau sur site est connecté à une région Oracle Cloud à l'aide d'Oracle Cloud Infrastructure FastConnect ou d'un VPN IPSec. L'architecture suppose que les serveurs sur site exécutent Oracle Linux.
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes d'autres régions et de grandes distances peuvent les séparer (dans les pays voire les continents).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui assure la tolérance de pannes. Les domaines de disponibilité ne partagent ni infrastructure telle que l'alimentation ou le refroidissement, ni réseau interne. Par conséquent, il est improbable qu'un problème affecte les autres domaines de disponibilité de la région.
- Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable et défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux cloud virtuels traditionnels, vous bénéficiez d'un contrôle total sur votre environnement réseau. Un VCN peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés vers une région ou un domaine de disponibilité. Chaque sous-réseau se compose d'une plage contiguë d'adresses qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
Dans cette architecture, les niveaux base de données et application utilisent des sous-réseaux distincts.
- Tables de routage
Les tables de routage virtuel contiennent des règles permettant d'acheminer le trafic des sous-réseaux vers des destinations situées en dehors d'un VCN, généralement via des passerelles.
Cette architecture utilise une règle de routage pour envoyer le trafic du sous-réseau de base de données à Oracle Cloud Infrastructure Object Storage via la passerelle de service.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés en entrée et en sortie du sous-réseau.
Cette architecture utilise des règles entrantes et sortantes dans les listes de sécurité associées au serveur d'applications et aux sous-réseaux de base de données. Ces règles permettent la connectivité entre l'application et la base de données. Les règles entrantes sont temporairement ajoutées dans les listes de sécurité associées aux sous-réseaux du serveur d'applications et du serveur de base de données lors de la migration, pour le transfert des fichiers d'application, des scripts shell et des données de configuration.
- Passerelle de routage dynamique
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre des réseaux cloud virtuels de la même région, entre un VCN et un réseau extérieur à la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau d'un autre fournisseur cloud.
- Passerelle de service
La passerelle de service fournit l'accès d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic du VCN vers le service Oracle circule sur la structure réseau Oracle et ne parcourt jamais Internet.
- Volume de blocs
Avec les volumes de stockage de blocs, vous pouvez créer, attacher, connecter et déplacer des volumes de stockage, et modifier leurs performances pour répondre à vos exigences en matière de stockage, de performances et d'application. Après avoir attaché et connecté un volume à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également déconnecter un volume et l'associer à une autre instance sans perdre de données.
- Object Storage
Object Storage fournit un accès rapide à d'importantes quantités de données structurées et non structurées de tout type de contenu, y compris des sauvegardes de base de données, des données analytiques et du contenu enrichi tel que des images et des vidéos. Vous pouvez stocker les données, puis les extraire directement à partir d'Internet ou de la plate-forme cloud, et ce, en toute sécurité. Vous pouvez mettre à l'échelle le stockage de manière transparente sans que les performances ou la fiabilité du service ne soient dégradées. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archives pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.
- Système de base de données
La base de données sur site est migrée vers un système de base de données Bare Metal, avec des licences Oracle Database Enterprise Edition activées pour 16 cœurs.
- Serveur d'applications
Le serveur d'applications sur site est migré vers une instance de calcul à deux cœurs.
Recommandations
Vos besoins peuvent être différents de ceux de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- Formes de calcul
Cette architecture utilise une instance de calcul Oracle Linux avec une forme VM.Standard2.4 pour le serveur d'applications. Si l'application a besoin de plus de puissance de traitement, de mémoire ou de bande passante réseau, choisissez une forme plus large.
- volumes de blocs
Cette architecture utilise un volume de blocs de 100 Go pour le serveur d'applications. Vous pouvez utiliser le volume pour installer l'application ou pour stocker des journaux et des données d'application.
- Formes de système de base de données
Cette architecture utilise la forme BM.DenseIO2.52 pour le système de base de données, avec 16 coeurs activés. Si vous avez besoin de plus de puissance de traitement, vous pouvez activer des coeurs supplémentaires.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR compris dans l'espace d'adresse IP privée standard.
Sélectionnez une plage d'adresses qui ne chevauche pas votre réseau sur site afin de pouvoir configurer une connexion entre le VCN et votre réseau sur site à l'aide de FastConnect ou d'un VPN IPSec.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Associez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
- Méthode de migration de la base de donnéesDans cette architecture de référence, Oracle Zero Downtime Migration (ZDM) est utilisé pour migrer le déploiement Oracle Database Enterprise Edition sur site vers Oracle Cloud Infrastructure sans aucun temps d'inactivité minimal. Cette méthode réduit considérablement l'impact de la migration de base de données sur la disponibilité des applications, en particulier si les opérations de sauvegarde et de copie utilisent une connexion avec une bande passante limitée.
Remarque :
Oracle propose plusieurs autres outils pour migrer les déploiements sur site d’Oracle Database vers le cloud. Reportez-vous à la section Informations supplémentaires pour obtenir des liens vers d'autres options.Voici un aperçu du processus de migration :- Vous téléchargez le logiciel ZDM, installez-le sur un serveur Linux 7 autonome (ou supérieur) pour coordonner les migrations et démarrez le processus de migration de base de données à l'aide de la commande
zdmcli migrate database
. - Le moniteur ZDM se connecte aux serveurs de base de données source et cible à l'aide des clés SSH fournies. Il établit ensuite la connectivité entre la base de données source et un bucket dans Oracle Cloud Infrastructure Object Storage.
- Le moniteur ZDM orchestre le transfert des fichiers de sauvegarde de la base de données source vers le bucket Object Storage, démarre une base de données de secours Data Guard dans le cloud à l'aide des fichiers de sauvegarde et synchronise les bases de données source et de secours. Le moniteur ZDM dispose de fonctionnalités spéciales pour fonctionner sur les connexions à faible bande passante et reprendre la transmission des données après les interruptions réseau.
- Cette architecture de référence se concentre sur la migration de base de données lors du déplacement de votre pile d'applications sur site vers Oracle Cloud Infrastructure. Vos applications peuvent utiliser des serveurs de couche middleware et de présentation qui dépendent généralement d'une connectivité à faible latence aux bases de données. Par conséquent, avant de passer au système de base de données Bare Metal dans Oracle Cloud Infrastructure, migrez les serveurs d'applications.
- Lorsque vous êtes prêt à basculer vers le cloud, utilisez ZDM pour effectuer une permutation Data Guard et faire évoluer le rôle des bases de données. La base de données sur site devient la base de données de secours et le système de base de données Bare Metal d'Oracle Cloud Infrastructure devient la base de données principale.
- En tant qu'étape finale du processus de migration, ZDM met fin à la connectivité Data Guard entre les bases de données source et cible et effectue des opérations de nettoyage.
Remarque :
Pour réduire le temps nécessaire à la migration de bases de données volumineuses, utilisez Oracle Cloud Infrastructure FastConnect. - Vous téléchargez le logiciel ZDM, installez-le sur un serveur Linux 7 autonome (ou supérieur) pour coordonner les migrations et démarrez le processus de migration de base de données à l'aide de la commande
Remarques
- Evolutivité
- Niveau Applications
Vous pouvez redimensionner les serveurs d'applications verticalement en modifiant la forme des instances de calcul. Une forme avec un nombre de cœurs plus élevé fournit également plus de mémoire et de bande passante réseau. Si davantage de stockage est nécessaire, augmentez la taille des volumes de blocs attachés au serveur d'applications.
- Niveau base de données
Vous pouvez redimensionner la base de données verticalement en activant des coeurs supplémentaires. La base de données reste disponible pendant le redimensionnement. Si vous augmentez le volume de stockage disponible, vous pouvez migrer vers un système de base de données Exadata.
- Niveau Applications
- Disponibilité
Les domaines de pannes offrent la meilleure résilience pour les charges de travail déployées dans un seul domaine de disponibilité. Cette architecture n'affiche pas les ressources redondantes, car l'accent est mis sur l'approche de migration. Pour une haute disponibilité dans le niveau d'application, déployez les serveurs d'applications dans différents domaines de pannes et utilisez un équilibreur de charge pour distribuer le trafic client sur les serveurs d'applications.
Pour la haute disponibilité du niveau de base de données, envisagez de migrer vers un système de base de données Exadata.
- Coût
- Niveau Applications
Sélectionnez la forme de calcul en fonction des coeurs, de la mémoire et de la bande passante réseau dont votre application a besoin. Vous pouvez commencer par une forme à deux cœurs pour le serveur d'applications. Si vous avez besoin de plus de performances, de mémoire ou de bande passante réseau, vous pouvez passer à une forme plus grande.
- Niveau base de données
Lorsque vous provisionnez un système de base de données Bare Metal, vous obtenez toute la mémoire et le stockage brut associés au serveur Bare Metal, quel que soit le nombre de coeurs que vous activez. Le coût dépend du nombre de coeurs que vous activez, ainsi que des options et des packs de gestion que vous choisissez.
- Niveau Applications
déploiement
Pour déployer cette architecture de référence, créez les ressources requises dans Oracle Cloud Infrastructure, puis migrez la base de données sur site à l'aide d'Oracle Zero Downtime Migration.
Journal des modifications
Ce journal répertorie uniquement les modifications importantes :
26 septembre 2022 |
Mise à jour du diagramme d'architecture. Ajout d'une version téléchargeable du diagramme. |
22 novembre 2020 |
Ajout d'étapes pour déployer les ressources cloud à l'aide d'Oracle Cloud Infrastructure Resource Manager. |