Intégration de fichiers hybrides sur AWS

Introduction

Au fur et à mesure que nous déplaçons/migratons des applications sur site vers le cloud, certaines des principales décisions d’architecture concernant l’intégration hybride font référence au partage de fichiers entre le cloud et les systèmes/utilisateurs sur site.

Lorsqu’une partie de l’écosystème passe au cloud, il est important que le partage de fichiers soit transparent, efficace et performant tout en étant rentable, grâce à une approche de solution cloud native.

La décision d’utiliser une solution cible pour FileShare varie selon le cas d’utilisation. Ce document donne un aperçu de divers cas d’utilisation de l’intégration basée sur des fichiers, des services proposés par AWS, de la dette technique potentielle et des approches de solution. La dette technique dont il est question ici est liée à la présence d’un composant de la solution dans le centre de données sur site. La suppression de ces dettes techniques est essentielle à la fermeture du centre de données ainsi qu’aux frais de licence très élevés et aux coûts d’infrastructure associés aux ressources.

Les cas d’utilisation sont principalement classés dans les catégories suivantes :

• Utilisateur vers/depuis le système à l’aide de FileShare
• Système vers/depuis le système à l’aide de FileShare

Impact utilisateur et opérationnel

Il convient de noter qu’il peut y avoir des changements opérationnels dans les scénarios de la façon dont les utilisateurs téléchargeaient/téléchargeaient des fichiers sans compromettre l’authentification/autorisation ou l’accès lié à la sécurité. Un manuel des opérations utilisateur est créé pour ces modèles de solution et les utilisateurs ont été formés à l’environnement Sandbox. Ces utilisateurs sont des utilisateurs professionnels, et les modèles de solution et les changements opérationnels sont convenus avec eux avant la conception et la mise en œuvre.

Présentation — Intégration basée sur des fichiers et options de solution AWS

S3 FileGateway : comment ça marche

• AWS S3 FileGateway a besoin d’une appliance sur site (VM). Il agit en tant que serveur S3 FileGateway (FG)
• Les systèmes/utilisateurs sur site créent un partage de fichiers SMB avec les dossiers spécifiques de ce serveur
• Le serveur FileGateway, d’un autre côté, s’intègre à S3. En interne, il y a une réplication qui se produit entre les fourrages configurés de FG Server et S3.
• L’application hébergée par AWS envoie/reçoit des données de S3 à l’aide du SDK s3sync/s3copy.
• Il s’agit des détails du service géré AWS de l’intégration entre S3 et le serveur FileGateway, la réplication, etc., sont gérés par AWS.

Serveur FsX : Comment ça marche

• Utilisé lorsqu’un transfert de fichiers volumineux à grande vitesse est requis sans latence
• AWS FsX Server a besoin d’une appliance sur site (VM). Il agit comme un client FsX FileGateway.
• Le système/l’utilisateur sur site crée un partage de fichiers SMB avec les dossiers spécifiques de ce serveur.
• D’un autre côté, FsX Server est provisionné dans un sous-réseau du VPC d’application.
• Les serveurs d’applications/instances EC2 ont un partage SMB avec FsX Server

Contraintes de la solution

• Dette technique critique : cette appliance hébergeant FileGateway/Fsx FileGateway Server est une infrastructure supplémentaire sur le centre de données — a des coûts/maintenance supplémentaires et une dette technique lorsqu’un client veut fermer le canter de données.
• Pour les passerelles S3, il existe une latence de x minutes pour la réplication entre S3 et SharedFolder sur le serveur FileGateway.
• La solution basée sur FsX FileServer est une solution coûteuse – par conséquent, à considérer avec soin.

Vous trouverez ci-dessous la liste des cas d’utilisation détaillés et des approches de solution :