À propos de la modernisation du service de stockage avec Oracle Cloud Infrastructure Object Storage
Ce livre de jeu de solution vous aidera à comprendre comment concevoir et exécuter la migration du stockage à long terme à partir de systèmes de fichiers locaux ou NFS vers Oracle Cloud Infrastructure Object Storage (OCI Object Storage). Une telle solution peut contribuer à réduire les coûts ainsi qu'à appliquer des règles de conservation, de cycle de vie et des demandes préauthentifiées à titre de fonctions supplémentaires.
Dans ce livre de jeu sur les solutions, nous utilisons un cas d'utilisation client pour mettre en évidence le point de départ d'un effort de modernisation réussi.
Nous parlons souvent de migration et de modernisation du nuage 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 nuage, levé et déplacé tel quel, puis tout le reste suit l'exemple.
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 actuelle et continue. Il met également en évidence un passage du travail que les équipes d'infrastructure peuvent effectuer à celui des équipes d'applications. Les budgets, le calendrier et d'autres priorités ont priorité et les applications doivent donc être exécutées telles quelles dans le nuage. Afin de réaliser les véritables économies potentielles que le nuage peut offrir, les entreprises doivent se tourner vers des technologies telles que le stockage d'objets pour réduire les coûts.
Les archives de fichiers sont un excellent point de départ, car elles peuvent être transférées de NFS au stockage d'objets OCI avec un minimum de travail et de tests de développement. La mise en œuvre d'une telle solution peut économiser de l'ordre de 10-50x sur le stockage, selon le cas d'utilisation. Les entreprises se sont rendues compte que les centres de données d'exploitation deviennent de plus en plus responsables et pourraient entraîner des coûts supplémentaires invisibles, avec le nombre croissant d'attaques potentielles, la perte de service et les concurrents qui innovent constamment.
L'utilisation de services en nuage natifs tels que le stockage d'objets OCI doit donc être une priorité, pour économiser sur les coûts, protéger l'entreprise, partager le fardeau de l'exploitation d'un large éventail de charges de travail disparates avec un hyperscaler, etc.
Comprendre les défis postérieurs à la migration
La clé ici était de se concentrer sur un point douloureux post-migration et de reconcevoir un morceau assez grand de l'application pour être percutant, mais assez petit pour s'attaquer 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 réduisant les coûts de développement et de test.
Pour le cas d'utilisation de cette solution playbook, le coût du stockage de fichiers partagés (NFS) est devenu un problème dans le nuage, et la conception originale de l'application est devenue la raison pour laquelle il n'était pas si facile de changer. Au cours du projet de migration des solutions sur place vers le nuage, nous avons parlé du stockage d'objets comme d'une alternative moins chère et plus fiable au stockage de fichiers, sur papier à propos des économies réalisées sur 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 politiques de cycle de vie peuvent toutes fonctionner ensemble pour faire du stockage d'objets la base d'un système rentable, 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 intensif d'UC pour générer des factures de client, les reporter dans une structure de répertoires 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 dénomination de fichier très spécifique, afin d'être accessibles 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 à partir de l'application pourraient ê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 âgés de plus d'un certain âge pourraient être retirés de l'archive en ligne, mais pourraient toujours être demandés par les auditeurs à la recherche de documents.
Ainsi, tous les fichiers jusqu'à 10 ans devaient être conservés dans le système de fichiers NFS, ce qui coûtait essentiellement à l'entreprise plus d'argent chaque jour que de nouveaux fichiers étaient générés. Le problème existait dans plusieurs applications différentes, de sorte que le problème de coût ne ferait qu'empirer avec le temps.
Exploiter le stockage d'objets OCI
Le stockage d'objets 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 du service de stockage d'objets et de certaines fonctions spécifiques du service de stockage d'objets d'OCI, nous pouvons augmenter la disponibilité et réduire les coûts pour des 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 seule fois, et doivent être stockés pendant des mois ou des années sans changement. En fait, l'entreprise peut garantir qu'elle n'est pas mutable pendant un certain temps.
Dans l'ensemble, voici une liste des raisons de base pour lesquelles le service de stockage d'objets présente des avantages par rapport au service de stockage de fichiers traditionnel pour ces types de fichiers.
- Disponibilité : Le service de stockage d'objets est un service régional, c'est-à-dire qu'il n'est pas lié à un seul domaine de disponibilité.
- Recherche : L'utilisation des 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 : Il est possible de s'assurer qu'un seau entier ne change pas une fois les objets écrits pour assurer une conformité immédiate.
- Niveaux de stockage : La définition des niveaux de stockage d'objets (automatique ou manuel) entraîne une réduction considérable des coûts pour les objets de conservation rarement utilisés ou requis pour les règles d'affaires.
- Politiques de cycle de vie : Le réglage du déplacement entre les niveaux de stockage et la suppression automatique (nettoyage) après conservation enregistrera le stockage et l'administration.
- Réplication : La réplication simple et automatique d'un seau entier vers une autre région peut accroître la disponibilité des données et leur accès.
- Coût : Le stockage d'objets construit et entretenu correctement coûte beaucoup moins cher que les systèmes de fichiers NFS en double et encombré.
NFS est toujours utile pour les applications qui nécessitent un système de fichiers monté, partagé et de style 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 "archivage". La solution décrite ici explique comment configurer le stockage d'objets et y accéder, et comment l'application a été modifiée pour utiliser à la fois le stockage NFS et la nouvelle archive de stockage d'objets 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 le stockage d'objets OCI, ce qui contribue à réduire les coûts et à appliquer la conservation, les règles de cycle de vie et les demandes préauthentifiées en tant que fonctions ajoutées.
Les images suivantes représentent l'architecture "avant" et "après". Le service FSS (Oracle File System Service) est utilisé pour un système de fichiers partagé volumineux. Dans ce système de fichiers, qui avait été migré à partir d'un centre de données sur place, les composants d'application utilisent un traitement par lots pour générer des fichiers d'archive sur une base continue. Ainsi, 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 fichiers réelle, stockée dans une hiérarchie qui doit être tenue à jour jusqu'à 10 ans, selon les besoins d'affaires.
Une fois configurés, les seaux de stockage d'objets OCI sont utilisés pour héberger la partie archive de ce que faisait NFS. Les autorisations pour lire et écrire le compartiment sont définies 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'archives est copiée dans le stockage d'objets OCI et le traitement par lots est refactorisé pour placer de nouvelles archives sur le nouveau seau d'objets. 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 à modifier la façon dont ils accèdent à ces archives.
Le diagramme suivant illustre l'architecture avant la mise en oeuvre :
oci-object-storage-modernization-arch-oracle1.zip
Le diagramme suivant illustre l'architecture après la mise en oeuvre :
oci-object-storage-modernization-arch-oracle.zip
- Administrateurs de la location - Accès complet
- Administrateurs d'application - Accès limité sans lecture d'objet
- Lecture seule - Inspection de seau sans lecture d'objet
- Énoncés ajoutés par groupe dynamique
- Définition étroite pour des ressources spécifiques
- Liste des OCID d'instance
- OCID du compartiment de l'instance
- 3650 jours (10 ans)
- verrouillée
e : Règles de cycle de vie :
- Après 90 jours - Stockage peu fréquent
- Après 180 jours - Stockage d'archives
- Après 3651 jours - Supprimer
Cette architecture prend en charge les composants suivants :
- Stockage d'objets
Le service de stockage d'objets pour Oracle Cloud Infrastructure offre un accès rapide à de grandes quantités de données structurées et non structurées de tous types, notamment des sauvegardes de base de données, des données analytiques et du contenu riche, comme des images et des vidéos. Vous pouvez stocker des données en toute sécurité, puis les extraire directement à partir d'Internet ou de la plate-forme en nuage. Vous pouvez adapter le stockage sans que la performance ou la fiabilité des services soit affectée. 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 retenez pendant de longues périodes et auquel vous accédez rarement.
- Stockage de fichiers
Le service de stockage de fichiers pour Oracle Cloud Infrastructure fournit un système de fichiers de réseau durable, évolutif, sécurisé et de niveau entreprise. Vous pouvez vous connecter à un système de fichiers du service de stockage de fichiers à partir de toute instance sans système d'exploitation, sur machine virtuelle ou en conteneur d'un VCN. Vous pouvez également accéder à un système de fichiers depuis l'extérieur du réseau VCN à l'aide d'Oracle Cloud Infrastructure FastConnect et du RPV IPSec.
- Service de gestion des identités et des accès (GIA)
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 du domaine d'identité. Chaque domaine d'identité IAM OCI représente une solution autonome de gestion des identités et des accès ou une population d'utilisateurs différente.
Considérations relatives à la gestion des identités
L'utilisation de seaux de stockage d'objets privés implique la configuration d'autorisations d'utilisation appropriées. Par défaut, les groupes d'utilisateurs et les groupes dynamiques ne sont généralement pas autorisés à accéder à des jeux d'autorisations étendus, tels que object-family, sauf s'il s'agit d'un compartiment.
Avant de vous lancer dans cette solution, il est important de vous assurer que seuls les groupes auxquels vous voulez avoir accès au stockage d'objets disposent des autorisations nécessaires. Une chose qui est extrêmement utile ici est de suivre la méthodologie de la zone d'atterrissage CIS pour restreindre l'accès. Lors de la mise en oeuvre 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 traités par la zone d'atterrissage. Il convient également de lire la syntaxe de la politique OCI, notamment la définition étroite d'un groupe dynamique et d'un énoncé de politique.
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 principaux d'instance et les groupes dynamiques pour l'authentification. Cela améliore la sécurité globale - il n'est pas nécessaire de créer, de distribuer ou de faire pivoter des 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, autoriser la création de seau peut être autorisé par une politique pour le groupe dynamique RCLONE, alors que seule la lecture d'objet est autorisée pour le groupe dynamique Apache.
Considérations relatives au stockage d'archives
Pour réduire les coûts et utiliser le niveau de coût le plus bas du stockage d'objets OCI, cette solution a mis en oeuvre des règles de cycle de vie, qui déplacent les objets vers le niveau peu fréquent, puis vers le niveau d'archives après une période de temps après la création.
Une fois les objets archivés, ils ne peuvent pas être reclassés directement dans le niveau standard. En raison de la nature hors ligne du stockage d'objets archivé, un processus doit être développé dans lequel un audit (processus d'affaires) peut être demandé, certains fichiers extraits de l'archive, puis les fichiers deviennent accessibles pendant une période limitée dans le temps.
Encore une fois, à l'aide des fonctions inhérentes au stockage d'objets, les fichiers peuvent être rappelés temporairement, copiés vers un emplacement temporaire (un autre compartiment) et exposés en externe à l'aide de demandes préauthentifiées. Il s'agit d'URL obscures (sécurité par obscurité) qui permettent l'accès à des fichiers spécifiques dans un seau et peuvent expirer après un certain temps, révoquant l'accès.
Pendant la période de rappel, les fichiers peuvent être copiés vers de nouveaux intervalles de niveau standard, puis ils reviennent automatiquement en mode d'archivage et aucune maintenance n'est nécessaire. RCLONE et l'interface de ligne de commande OCI, Java, REST ou Python peuvent être utilisés de la même façon pour la solution principale, avec un accès à nouveau à un seau de vérification spécifique.