A propos de la modernisation du stockage avec Oracle Cloud Infrastructure Object Storage
Ce guide pratique vous aidera à comprendre comment concevoir et exécuter la migration du stockage à long terme de systèmes de fichiers NFS ou locaux vers Oracle Cloud Infrastructure Object Storage (OCI Object Storage). Une telle solution peut aider à réduire les coûts, ainsi qu'à appliquer la conservation, les règles de cycle de vie et les demandes pré-authentifiées en tant que fonctionnalités supplémentaires.
Dans ce manuel de solutions, nous utilisons un cas d'utilisation client pour mettre en évidence le point de départ pour mettre en œuvre un effort de modernisation réussi.
Nous parlons souvent de la migration et de la modernisation du cloud dans la même conversation, en passant par toutes les méthodes, tous les services et toutes les offres disponibles. La conversation implique souvent de faire une approche progressive, où tout un centre de données est systématiquement déplacé vers le cloud, levé et déplacé tel quel, puis tout le reste suit.
Une fois la phase initiale terminée, la modernisation des applications perd souvent de son importance par rapport aux problèmes de sécurité, de surveillance, d'intégration actuels et en cours. Il met également en évidence le passage du travail que les équipes d'infrastructure peuvent effectuer à celui des équipes d'applications. Les budgets, le calendrier et d'autres priorités sont prioritaires et les applications restent donc exécutées telles quelles dans le cloud. Afin de réaliser les véritables économies potentielles que le cloud peut offrir, les entreprises doivent se tourner vers des technologies telles que le stockage d'objets afin d'économiser sur les coûts.
Les archives de fichiers sont un bon point de départ, car elles peuvent passer de NFS à OCI Object Storage avec un minimum de travail et de tests de développement. L'implémentation d'une telle solution peut permettre d'économiser de l'ordre de 10 à 50x sur le stockage, selon le cas d'utilisation. Les entreprises se sont rendu compte que les centres de données opérationnels deviennent de plus en plus une responsabilité et pourraient entraîner des coûts supplémentaires invisibles, le nombre croissant d'attaques potentielles, de pertes de service et de concurrents innovant constamment.
Cela devrait faire de l'utilisation de services cloud natifs tels qu'OCI Object Storage une priorité, pour économiser sur les coûts, protéger l'entreprise, partager la charge d'exploitation d'un large éventail de workloads disparates avec un hyperscaler, et plus encore.
Comprendre les défis postérieurs à la migration
La clé ici était de se concentrer sur un point douloureux post-migration et de redessiner un morceau assez grand de l'application pour être percutant, mais assez petit pour aborder dans un seul sprint de conception. De cette façon, l'entreprise réalise à la fois des économies et une tranquillité d'esprit, tout en maintenant les coûts de développement et de test faibles.
Pour le cas d'utilisation de ce manuel de solutions, le coût du stockage de fichiers partagé (NFS) est devenu un problème dans le cloud, et la conception originale de l'application est devenue la raison pour laquelle il n'était pas si facile à modifier. Au cours du projet de migration on-premise vers le cloud, nous avons évoqué Object Storage comme une alternative moins chère et plus fiable à File Storage, et nous avons présenté sur papier les économies réalisées grâce à 10x. Ajout de sauvegardes et de réplication, 10x est probablement plus élevé. Des fonctionnalités efficaces telles que la réplication inter-région, le verrouillage de conservation et les stratégies de cycle de vie peuvent toutes fonctionner ensemble pour qu'Object Storage constitue la base d'un système économique, fiable et sécurisé sur lequel stocker des documents importants. Cependant, lorsque l'application est conçue autour du système de fichiers NFS pour le stockage de documents et s'attend à une sémantique POSIX, les choses deviennent plus difficiles.
L'application qui a été modernisée dans ce cas d'utilisation est une application standard à 3 niveaux, mais avec plusieurs composants externes qui doivent exécuter un processus coordonné et intense pour générer des factures client, les publier dans une structure d'annuaire organisée et les cataloguer pour le téléchargement et le stockage à long terme. Ces fichiers PDF et autres ont été stockés sur un grand système de fichiers NFS avec un modèle de nommage de fichier très spécifique, afin d'être accessible par un chemin généré. Une autre application a été construite autour du serveur Apache HTTP, en utilisant la zone de stockage à long terme de ce partage NFS comme racine de document, de sorte que les URL générées de l'application peuvent être utilisées pour télécharger des fichiers à partir de n'importe quel point au cours des 2 dernières années. Enfin, les fichiers de plus d'un certain âge pourraient être retirés de l'archive en ligne, mais pourraient toujours être demandés par les auditeurs qui cherchent des dossiers.
Ainsi, tous les fichiers jusqu'à 10 ans devaient être conservés sur le système de fichiers NFS, ce qui coûtait essentiellement plus d'argent à l'entreprise chaque jour où de nouveaux fichiers étaient générés. Le problème existait dans plusieurs applications différentes, de sorte que le problème des coûts ne ferait qu'empirer avec le temps.
Exploiter le stockage d'objets OCI
Object Storage est parfait pour les fichiers qui ne changent pas fréquemment. Cela contraste avec NFS, qui se concentre sur le stockage partagé à usage mixte.
En tirant parti de plusieurs éléments de conception Object Storage et de certaines fonctionnalités spécifiques d'OCI Object Storage Service, nous pouvons augmenter la disponibilité et réduire les coûts pour les charges de travail appropriées.
Dans ce cas d'utilisation, les fichiers créés pour l'accès à moyen terme et l'archivage à long terme conviennent parfaitement. Ces fichiers sont probablement écrits une fois, et ont besoin d'être stockés pendant des mois ou des années sans changement. En fait, l'entreprise peut vouloir assurer qu'elles sont immuables pendant un certain temps.
Dans l'ensemble, voici les raisons pour lesquelles Object Storage présente des avantages par rapport au stockage de fichiers traditionnel pour ces types de fichier.
- Disponibilité : Object Storage est un service régional, ce qui signifie qu'il n'est pas lié à un seul domaine de disponibilité.
- Rechercher : l'utilisation de métadonnées d'objet est probablement plus utile que de s'appuyer uniquement sur des noms de fichier et des commandes de recherche de type POSIX.
- Règles de conservation : vous pouvez vous assurer que tout un bucket ne change pas une fois les objets écrits pour garantir une conformité immédiate.
- Niveaux de stockage : la hiérarchisation du stockage d'objets (automatique ou manuelle) entraîne une réduction considérable du coût pour les objets de conservation rarement consultés ou requis par les règles métier.
- Stratégies de cycle de vie : le réglage du déplacement entre les niveaux de stockage et la suppression automatique (nettoyage) après la conservation permet d'économiser sur le stockage et l'administration.
- Réplication : la réplication facile et automatique d'un bucket entier vers une autre région peut augmenter la disponibilité et l'accès aux données.
- Coût : le stockage d'objets correctement construit et maintenu coûte beaucoup moins cher que les systèmes de fichiers NFS dupliqués et encombrés.
NFS est toujours utile pour les applications qui nécessitent un système de fichiers monté, partagé et de type POSIX. Le client avait toujours besoin de NFS pour le stockage partagé, mais son utilisation était limitée aux fichiers "opérationnels", par opposition aux fichiers "archivés". La solution décrite ici explique comment configurer Object Storage et y accéder, et comment l'application a été modifiée pour utiliser à la fois le stockage NFS et la nouvelle archive Object Storage créée pour le stockage à long terme.
Architecture
Cette architecture présente la conception et l'exécution permettant de déplacer le stockage à long terme vers OCI Object Storage, ce qui permet de réduire les coûts et d'appliquer la conservation, les règles de cycle de vie et les demandes pré-authentifiées en tant que fonctionnalités ajoutées.
Les images suivantes décrivent l'implémentation de l'architecture "avant" et "après". Oracle File System Service (FSS) est utilisé pour un système de fichiers partagé volumineux. Sur ce système de fichiers, qui a été migré à partir d'un centre de données sur site, les composants d'application utilisent le traitement par lots pour générer des fichiers d'archive en continu. Par conséquent, le même système de fichiers NFS contient à la fois les éléments d'application requis pour effectuer le traitement intermédiaire (scripts, fichiers temporaires, etc.) et l'archive de fichier réelle, stockée dans une hiérarchie qui doit être maintenue jusqu'à 10 ans, selon les besoins de l'entreprise.
Une fois configurés, les buckets OCI Object Storage sont utilisés pour héberger la partie archive de l'opération NFS. Les droits d'accès pour la lecture et l'écriture du bucket sont définis de manière étroite, et des règles de conservation et de cycle de vie sont établies, afin d'être préparées pour un afflux important de données. La grande hiérarchie des fichiers d'archive est copiée dans OCI Object Storage et le traitement par lots est refactorisé pour placer de nouvelles archives sur le nouveau bucket d'objet. Les mécanismes d'accès ont également été légèrement remaniés afin d'accéder aux fichiers à partir du stockage d'objets, ce qui a empêché le reste de l'application et les clients finaux d'avoir à apporter des modifications à la façon dont ils accèdent à ces archives.
Le schéma suivant illustre l'architecture avant l'implémentation :
oci-object-storage-modernization-arch-oracle1.zip
Le schéma suivant illustre l'architecture après l'implémentation :
oci-object-storage-modernization-arch-oracle.zip
- Administrateurs de location - Accès complet
- Administrateurs d'application - Accès limité sans lecture d'objet
- Lecture seule - Inspection de bucket sans lecture d'objet
- Instructions ajoutées par groupe dynamique
- Défini de manière étroite pour des ressources spécifiques
- Liste des OCID d'instance
- OCID de compartiment d'instance
- 3650 jours (10 ans)
- verrouillé
e : Règles de cycle de vie :
- Après 90 jours - Stockage peu fréquent
- Après 180 jours - Archive storage
- Après 3651 jours - Supprimer
Cette architecture prend en charge les composants suivants :
- Object Storage
Oracle Cloud Infrastructure Object Storage fournit un accès rapide à de grandes quantités de données, structurées ou non, 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 redimensionner le stockage sans dégradation des performances ni de la fiabilité des services. Utilisez le stockage standard pour le stockage "à chaud" auquel vous devez accéder rapidement, immédiatement et fréquemment. Utilisez le stockage d'archive pour le stockage "à froid" que vous conservez pendant de longues périodes et auquel vous accédez rarement.
- Stockage de fichier
Le service Oracle Cloud Infrastructure File Storage offre un système de fichiers réseau durable, évolutif, sécurisé et adapté à l'entreprise. Vous pouvez vous connecter à un système de fichiers de service File Storage à partir de n'importe quelle instance Bare Metal, de machine virtuelle ou de conteneur dans un VCN. Vous pouvez également accéder à un système de fichiers à partir de l'extérieur du VCN à l'aide d'Oracle Cloud Infrastructure FastConnect et du VPN IPSec.
- Identity and Access Management (IAM)
Oracle Cloud Infrastructure Identity and Access Management (IAM) est le plan de contrôle d'accès pour Oracle Cloud Infrastructure (OCI) et Oracle Cloud Applications. L'API IAM et l'interface utilisateur vous permettent de gérer les domaines d'identité et les ressources au sein du domaine d'identité. Chaque domaine d'identité OCI IAM représente une solution autonome de gestion des identités et des accès ou une population d'utilisateurs différente.
Remarques concernant la gestion des identités
L'utilisation de buckets de stockage d'objets privés implique de configurer des droits d'accès appropriés pour leur utilisation. Par défaut, les groupes d'utilisateurs et les groupes dynamiques ne bénéficient généralement pas d'un accès à des ensembles de droits d'accès étendus, tels que object-family, sauf s'ils sont ciblés sur un compartiment.
Avant de vous lancer dans cette solution, assurez-vous que seuls les groupes auxquels vous souhaitez accéder au stockage d'objets disposent de droits d'accès. Une chose qui est extrêmement utile ici est de suivre la méthodologie de zone de renvoi SIC pour restreindre l'accès. Lors de l'implémentation de cette solution, nous discutons de la création de groupes dynamiques. Il est donc utile de comprendre à la fois la structure de compartiment de votre location et les concepts abordés dans la zone de renvoi. Il est également utile de lire la syntaxe de stratégie OCI, notamment la définition étroite d'un groupe dynamique et d'une instruction de stratégie.
Bien que RCLONE et OCIFS prennent en charge les clés d'API OCI standard en tant que mécanisme d'authentification, nous avons choisi les ID instance et les groupes dynamiques pour l'authentification. Cela améliore l'état de sécurité global. Il n'est pas nécessaire de créer, de distribuer ou de faire pivoter les clés. Au lieu de cela, des groupes dynamiques distincts sont utilisés afin de garantir les autorisations les plus étroites possibles pour chaque groupe dynamique. Par exemple, l'autorisation de la création de bucket peut être autorisée par la stratégie pour le groupe dynamique RCLONE, alors que seule la lecture d'objet est autorisée pour le groupe dynamique Apache.
Remarques concernant Archive Storage
Pour réduire les coûts et utiliser le niveau de coût le plus bas d'OCI Object Storage, cette solution a implémenté des règles de cycle de vie, qui déplacent les objets vers le niveau Peu fréquent, puis vers le niveau Archive après une période de temps après leur création.
Une fois les objets archivés, ils ne peuvent pas être reclassés directement au niveau Standard. En raison de la nature hors ligne du stockage d'objets archivé, un processus doit être développé pour demander un audit (processus métier), extraire certains fichiers de l'archive, puis les rendre accessibles pendant une période donnée.
Encore une fois, à l'aide des fonctionnalités inhérentes au stockage d'objets, les fichiers peuvent être rappelés temporairement, copiés vers un emplacement temporaire (autre que pour les buckets) et exposés en externe à l'aide de demandes pré-authentifiées. Il s'agit d'URL obscures (sécurité par obscurité) qui permettent d'accéder à des fichiers spécifiques dans un bucket et peuvent expirer après un laps de temps défini, révoquant l'accès.
Pendant la période de rappel, les fichiers peuvent être copiés vers de nouveaux buckets de niveau standard, puis ils reviennent automatiquement en mode Archive, et aucune maintenance n'est nécessaire. L'interface de ligne de commande RCLONE et OCI, Java, REST ou Python peuvent être utilisés de la même manière pour la solution principale, à nouveau avec accès à un bucket d'audit spécifique.