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'illustration migrate-bmdb.png

migrate-bmdb-oracle.zip

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ées
    Dans 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 :
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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.

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.

  • 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.

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.

  1. Créez les ressources requises dans Oracle Cloud Infrastructure.

    Le code Terraform pour déployer les ressources dans le cloud est disponible sur GitHub. Utilisez le code pour provisionner les ressources réseau, une instance de calcul utilisable comme base ou pour le serveur d'applications et un système de base de données Bare Metal.

    Vous pouvez extraire le code dans Oracle Cloud Infrastructure Resource Manager en un seul clic, créer la pile et la déployer. Vous pouvez également télécharger le code à partir de GitHub sur votre ordinateur, le personnaliser et déployer l'architecture à l'aide de la CLI Terraform.

    • Déployez les ressources cloud à l'aide d'Oracle Cloud Infrastructure Resource Manager :
      1. Cliquez sur Déploiement sur Oracle Cloud.

        Si vous n'êtes pas déjà connecté, entrez les informations d'identification de la location et de l'utilisateur.

      2. Consulter et accepter les conditions générales.
      3. Sélectionnez la région de déploiement de la pile.
      4. Suivez les invites affichées à l'écran et les instructions pour créer la pile.
      5. Après avoir créé la pile, cliquez sur Actions Terraform et sélectionnez Plan.
      6. Attendez que le travail soit terminé et vérifiez le plan.

        Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Exécutez ensuite à nouveau l'action Plan.

      7. Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform et sélectionnez Appliquer.
    • Déployez les ressources cloud à l'aide de l'interface de ligne de commande Terraform :
      1. Accédez à GitHub.
      2. Téléchargez le code sur votre ordinateur local.
      3. Effectuez les étapes prérequises décrites dans le fichier README.
      4. Appliquez la configuration à l'aide de l'interface de ligne de commande Terraform.
  2. Migrez la base de données sur site à l'aide d'Oracle Zero Downtime Migration.

Voir plus

En savoir plus sur la migration de bases de données sur site vers le cloud.

Journal des modifications

Ce journal répertorie uniquement les modifications importantes :