

Amazon FSx File Gateway n'est plus disponible pour les nouveaux clients. Les clients existants de FSx File Gateway peuvent continuer à utiliser le service normalement. Pour des fonctionnalités similaires à FSx File Gateway, consultez [ce billet de blog](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/).

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Performances et optimisation
<a name="Performance"></a>

Cette section décrit les conseils et les meilleures pratiques pour optimiser les performances de File Gateway.

**Topics**
+ [Conseils de performance de base pour File Gateway](#performance-fgw)
+ [Optimisation des performances de la passerelle](#Optimizing-common)
+ [Optimisation du débit de la passerelle de fichiers S3](Performance-Throughput.md)
+ [Optimisation de la passerelle de fichiers S3 pour les sauvegardes de bases de données SQL Server](SQL-Backup-Best-Practices.md)

## Conseils de performance de base pour File Gateway
<a name="performance-fgw"></a>

Dans cette section, vous trouverez des conseils pour le provisionnement du matériel pour votre machine virtuelle FSx File Gateway. Les configurations d'instance répertoriées dans le tableau sont des exemples et sont fournies à titre de référence.

Pour obtenir les meilleures performances, la taille du disque de cache doit être adaptée à la taille de l'ensemble de travail actif. L'utilisation de plusieurs disques locaux pour le cache améliore les performances en écriture en mettant en parallèle l'accès aux données, ce qui entraîne une augmentation du nombre d'IOPS.

**Note**  
Nous vous déconseillons d'utiliser le stockage éphémère. Pour de plus amples informations sur l'utilisation du stockage éphémère, veuillez consulter [Utilisation du stockage éphémère avec les passerelles EC2](ephemeral-disk-cache.md).  
La limite de taille suggérée pour les répertoires individuels des systèmes de fichiers que vous connectez à File Gateway est de 10 000 fichiers par répertoire. Vous pouvez utiliser File Gateway avec des répertoires contenant plus de 10 000 fichiers, mais les performances peuvent être affectées.

Dans les tableaux suivants, les opérations de *lecture par accès au cache* sont lues à partir des données de fichier servies depuis le cache. Les opérations de lecture *manquante du cache* sont des lectures à partir des données de fichiers fournies par le serveur de fichiers Amazon FSx pour Windows.

Le tableau suivant présente un exemple de configuration de passerelle de FSx fichiers.

### FSx Performances de la passerelle de fichiers sur les clients Windows
<a name="performance-fgw-fsx-windows"></a>

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/filegateway/latest/filefsxw/Performance.html)

**Note**  
Vos performances peuvent varier en fonction de la configuration de votre plateforme hôte et de la bande passante réseau. Les performances du débit d'écriture diminuent avec la taille du fichier, le débit le plus élevé possible pour les petits fichiers (moins de 32 Mo) étant de 16 fichiers par seconde.

## Optimisation des performances de la passerelle
<a name="Optimizing-common"></a>

Vous trouverez ci-après des informations sur l'optimisation des performances de votre passerelle. Le conseil repose sur l'ajout de ressources à votre passerelle et l'ajout de ressources à votre serveur d'application. 

### Ajouter des ressources à la passerelle
<a name="Optimizing-vtl-add-resources-common"></a>

 Vous pouvez optimiser les performances de la passerelle en ajoutant des ressources à votre passerelle à l’aide de plusieurs façons.

**Utiliser des disques hautes performances**  
Pour optimiser les performances de la passerelle, vous pouvez ajouter des disques hautes performances tels que des disques SSD (SSDs) et un NVMe contrôleur. Vous pouvez également attacher des disques virtuels directement à la machine virtuelle à partir d’un réseau SAN au lieu d’avoir recours au système NTFS Microsoft Hyper-V. L'amélioration des performances du disque se traduit généralement par un meilleur débit et un plus grand nombre d' input/output opérations par seconde (IOPS). Pour plus d'informations sur l'ajout de disques, consultez[Configuration d'un stockage de cache supplémentaire](ConfiguringLocalDiskStorage.md).  
Pour mesurer le débit, utilisez les métriques `ReadBytes` et `WriteBytes` avec la statistique Amazon CloudWatch `Samples`. Par exemple, la statistique `Samples` de la métrique `ReadBytes` pendant 5 minutes divisée par 300 secondes vous donne les IOPS. En règle générale, lorsque vous examinez ces métriques pour une passerelle, recherchez un débit faible et de faibles tendances IOPS pour indiquer les goulots d’étranglement liés aux disques.   
CloudWatch les métriques ne sont pas disponibles pour toutes les passerelles. Pour obtenir des informations sur les métriques de passerelle, consultez [Surveillance de votre passerelle de ](monitoring-file-gateway.md).

**Ajouter des ressources de processeur à votre hôte de passerelle**  
Un serveur hôte de passerelle doit avoir au moins quatre processeurs virtuels. Afin d'optimiser les performances de la passerelle, vérifiez que les quatre processeurs virtuels attribués à la machine virtuelle de la passerelle sont soutenus par quatre cœurs. Vérifiez également que vous n'êtes pas en train de surabonner le CPUs serveur hôte.   
Lorsque vous ajoutez des éléments supplémentaires CPUs à votre serveur hôte de passerelle, vous augmentez la capacité de traitement de la passerelle. Cela permet à votre passerelle de gérer, en parallèle, à la fois le stockage des données de votre application vers votre stockage local et le téléchargement de ces données pour Windows File Server. Cela permet CPUs également de garantir que votre passerelle dispose de suffisamment de ressources CPU lorsque l'hôte est partagé avec d'autres VMs. La présence d’une quantité suffisante de ressources de processeur permet généralement d’améliorer le débit.  
Storage Gateway prend en charge l'utilisation CPUs de 24 sur votre serveur hôte de passerelle. Vous pouvez utiliser 24 CPUs pour améliorer de manière significative les performances de votre passerelle. Nous vous recommandons la configuration de passerelle suivante pour votre serveur hôte de passerelle :  
+ 24 CPUs. 
+ 16 Gio de RAM réservée pour les passerelles de fichiers
  + 16 Gio de RAM réservée pour les passerelles avec une taille de cache maximale de 16 Tio
  + 32 Gio de RAM réservée pour les passerelles avec une taille de cache de 16 à 32 Tio
  + 48 Gio de RAM réservée pour les passerelles avec une taille de cache de 32 à 64 Tio
+ Disque 1 attaché au contrôleur paravirtuel 1, à utiliser comme cache de passerelle de la façon suivante :
  + SSD utilisant un NVMe contrôleur. 
+ Carte réseau 1 configurée sur le réseau de machine virtuelle 1 :
  + Utilisez le réseau VM 1 et ajoutez VMXnet3 (10 Gbit/s) à utiliser pour l'ingestion.
+ Carte réseau 2 configurée sur le réseau de machine virtuelle 2 :
  + Utilisez le réseau VM 2 et ajoutez un VMXnet3 (10 Gbit/s) à utiliser pour vous connecter AWS.

 **Soutenir les disques virtuels de la passerelle avec des disques physiques distincts**  
Lorsque vous provisionnez des disques de passerelle, nous vous recommandons vivement de ne pas provisionner de disques locaux pour le stockage local qui utilisent le même disque de stockage physique sous-jacent. Par exemple, pour VMware ESXi, les ressources de stockage physiques sous-jacentes sont représentées sous la forme d'un magasin de données. Lorsque vous déployez la machine virtuelle de la passerelle, vous choisissez une banque de données sur laquelle stocker les fichiers de la machine virtuelle. Lorsque vous mettez en service un disque virtuel (par exemple, en tant que tampon de chargement), vous pouvez stocker le disque virtuel dans la même banque de données en tant que machine virtuelle ou dans une banque de données différente.   
Si vous avez plusieurs banques de données, nous vous recommandons vivement de choisir une banque de données pour chaque type de stockage local que vous créez. Un magasin de données soutenu par un seul disque physique sous-jacent peut entraîner des performances médiocres. Par exemple, lorsque vous utilisez un nouveau disque pour soutenir à la fois le stockage de cache et le tampon de chargement dans une configuration de passerelle. De la même façon, un magasin de données soutenu par une configuration RAID moins performante, comme RAID 1, peut entraîner des performances médiocres.

### Ajouter des ressources à votre environnement d’application
<a name="Optimizing-vtl-add-resources-app-common"></a>

**Augmenter la bande passante entre le serveur d’application et la passerelle**  
Afin d’optimiser les performances de la passerelle, vérifiez que la bande passante réseau entre votre application et la passerelle peut supporter les besoins de votre application. Vous pouvez utiliser les `WriteBytes` métriques `ReadBytes` et de la passerelle pour mesurer le débit total de données.   
Pour votre application, comparez le débit mesuré avec le débit souhaité. Si le débit mesuré est inférieur au débit souhaité, l’augmentation de la bande passante entre votre application et la passerelle peut améliorer les performances si le réseau est le goulot d’étranglement. De même, vous pouvez augmenter la bande passante entre la machine virtuelle et les disques locaux, s’ils ne sont pas attachés directement.

**Ajouter des ressources de processeur à votre environnement d’application**  
Si votre application peut utiliser des ressources CPU supplémentaires, l'ajout de ressources supplémentaires CPUs peut l'aider à augmenter sa I/O charge.  
Certaines opérations sur les fichiers sur la passerelle de FSx fichiers, telles que le changement de nom de dossiers de niveau supérieur ou la modification des autorisations, peuvent entraîner plusieurs opérations sur les fichiers qui entraînent une I/O charge importante sur votre système FSx de fichiers Windows File Server. Si votre système de fichiers ne dispose pas de ressources de performance suffisantes pour votre charge de travail, il est possible qu'il supprime les clichés instantanés[, car il](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html) donne la priorité à la disponibilité permanente I/O plutôt qu'à la conservation historique des clichés instantanés.  
Dans la FSx console Amazon, consultez la page **Surveillance et performances** pour voir si votre système de fichiers est sous-approvisionné. Si tel est le cas, vous pouvez passer au stockage SSD, augmenter la capacité de débit ou augmenter le nombre d'IOPS du SSD pour gérer votre charge de travail.

# Optimisation du débit de la passerelle de fichiers S3
<a name="Performance-Throughput"></a>

Les sections suivantes décrivent les meilleures pratiques pour optimiser le débit entre vos clients NFS et SMB, S3 File Gateway et Amazon S3. Les conseils fournis dans chaque section contribuent progressivement à améliorer le débit global. Bien qu'aucune de ces recommandations ne soit requise et qu'elles ne soient pas interdépendantes, elles ont été sélectionnées et ordonnées d'une manière logique qui permet de tester et d'ajuster les Support implémentations de S3 File Gateway. Lorsque vous implémentez et testez ces suggestions, gardez à l'esprit que chaque déploiement de S3 File Gateway est unique et que les résultats peuvent donc varier.

S3 File Gateway fournit une interface de fichiers permettant de stocker et de récupérer des objets Amazon S3 à l'aide des protocoles de fichiers NFS ou SMB standard, avec un mappage 1:1 natif entre le fichier et l'objet. Vous déployez S3 File Gateway en tant que machine virtuelle soit sur site dans votre VMware environnement KVM Microsoft Hyper-V ou Linux, soit dans le AWS cloud en tant qu'instance Amazon EC2. S3 File Gateway n'est pas conçu pour remplacer complètement le NAS d'entreprise. S3 File Gateway émule un système de fichiers, mais il ne s'agit pas d'un système de fichiers. L'utilisation d'Amazon S3 comme stockage dorsal durable entraîne une surcharge supplémentaire pour chaque I/O opération. L'évaluation des performances de S3 File Gateway par rapport à celles d'un NAS ou d'un serveur de fichiers existant ne constitue donc pas une comparaison équivalente.

## Déployez votre passerelle au même endroit que vos clients
<a name="Throughput-Location"></a>

Nous vous recommandons de déployer votre dispositif virtuel S3 File Gateway dans un emplacement physique avec une latence réseau aussi faible que possible entre celui-ci et vos clients NFS ou SMB. Lorsque vous choisissez un emplacement pour votre passerelle, tenez compte des points suivants :
+ La réduction de la latence réseau vers la passerelle peut contribuer à améliorer les performances des clients NFS ou SMB.
+ La passerelle de fichiers S3 est conçue pour tolérer une latence réseau plus élevée entre la passerelle et Amazon S3 qu'entre la passerelle et les clients.
+ Pour les instances de passerelle de fichiers S3 déployées dans Amazon EC2, nous recommandons de conserver la passerelle et les clients NFS ou SMB dans le même groupe de placement. Pour plus d'informations, consultez la section [Groupes de placement pour vos instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) dans le guide de l'utilisateur d'Amazon Elastic Compute Cloud.

## Réduisez les goulots d'étranglement causés par la lenteur des disques
<a name="Throughput-Slow-Disks"></a>

Nous vous recommandons de surveiller la `IoWaitPercent` CloudWatch métrique afin d'identifier les problèmes de performances pouvant résulter de la lenteur des disques de stockage sur votre passerelle de fichiers S3. Lorsque vous essayez d'optimiser les problèmes de performances liés au disque, tenez compte des points suivants :
+ `IoWaitPercent`indique le pourcentage de temps pendant lequel le processeur attend une réponse de la racine ou des disques de cache.
+ Lorsqu'il `IoWaitPercent` est supérieur à 5 à 10 %, cela indique généralement un goulot d'étranglement des performances de la passerelle dû à des disques peu performants. Cette métrique doit être aussi proche que possible de 0 %, ce qui signifie que la passerelle n'attend jamais sur le disque, ce qui permet d'optimiser les ressources du processeur.
+ Vous pouvez consulter l'`IoWaitPercent`onglet **Monitoring** de la console Storage Gateway ou configurer des CloudWatch alarmes recommandées pour vous avertir automatiquement si la métrique dépasse un seuil spécifique. Pour plus d'informations, consultez la section [Création d' CloudWatch alarmes recommandées pour votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html).
+ Nous vous recommandons d'utiliser l' NVMe un ou l'autre SSD pour les disques racine et de cache de votre passerelle afin de minimiser`IoWaitPercent`.

## Ajuster l'allocation des ressources des machines virtuelles pour le processeur, la RAM et les disques de cache
<a name="Throughput-Resource-Allocation"></a>

Lorsque vous essayez d'optimiser le débit de votre passerelle de fichiers S3, il est important d'allouer suffisamment de ressources à la machine virtuelle de passerelle, notamment le processeur, la RAM et les disques de cache. Les exigences minimales en matière de ressources virtuelles de 4 CPUs, 16 Go de RAM et 150 Go de stockage de cache ne conviennent généralement qu'aux petites charges de travail. Lorsque vous allouez des ressources virtuelles pour des charges de travail plus importantes, nous recommandons ce qui suit :
+ Augmentez le nombre CPUs alloué entre 16 et 48, en fonction de l'utilisation typique du processeur générée par votre passerelle de fichiers S3. Vous pouvez surveiller l'utilisation du processeur à l'aide de la `UserCpuPercent` métrique. Pour plus d'informations, consultez la section [Comprendre les métriques de passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ Augmentez la RAM allouée entre 32 et 64 Go.
**Note**  
S3 File Gateway ne peut pas utiliser plus de 64 Go de RAM.
+ Utilisez NVMe un SSD pour les disques racine et le disque de cache, et dimensionnez vos disques de cache en fonction de l'ensemble de données de travail maximal que vous prévoyez d'écrire sur la passerelle. Pour plus d'informations, consultez les [meilleures pratiques en matière de dimensionnement du cache de S3 File Gateway](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) sur le YouTube canal officiel Amazon Web Services.
+ Ajoutez au moins 4 disques de cache virtuels à la passerelle, plutôt que d'utiliser un seul grand disque. Plusieurs disques virtuels peuvent améliorer les performances même s'ils partagent le même disque physique sous-jacent, mais les améliorations sont généralement plus importantes lorsque les disques virtuels sont situés sur des disques physiques sous-jacents différents.

  Par exemple, si vous souhaitez déployer 12 To de cache, vous pouvez utiliser l'une des configurations suivantes :
  + 4 disques de cache de 3 To
  + 8 disques de cache de 1,5 To
  + 12 disques de cache de 1 To

  Outre les performances, cela permet une gestion plus efficace de la machine virtuelle au fil du temps. À mesure que votre charge de travail évolue, vous pouvez augmenter progressivement le nombre de disques de cache et votre capacité de cache globale, tout en conservant la taille initiale de chaque disque virtuel afin de préserver l'intégrité de la passerelle.

  Pour plus d'informations, voir [Déterminer la quantité de stockage sur disque local](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).

Lorsque vous déployez S3 File Gateway en tant qu'instance Amazon EC2, tenez compte des points suivants :
+ Le type d'instance que vous choisissez peut avoir un impact significatif sur les performances de la passerelle. Amazon EC2 offre une grande flexibilité pour ajuster l'allocation des ressources pour votre instance de passerelle de fichiers S3.
+ Pour connaître les types d'instances Amazon EC2 recommandés pour la passerelle de fichiers S3, consultez la section [Exigences relatives aux types d'instances Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Vous pouvez modifier le type d'instance Amazon EC2 qui héberge une passerelle de fichiers S3 active. Cela vous permet d'ajuster facilement la génération de matériel Amazon EC2 et l'allocation des ressources pour trouver le ratio idéal price-to-performance. Pour modifier le type d'instance, suivez la procédure suivante dans la console Amazon EC2 :

  1. Arrêtez l'instance Amazon EC2.

  1. Modifiez le type d'instance Amazon EC2.

  1. Allumez l'instance Amazon EC2.
**Note**  
L'arrêt d'une instance hébergeant une passerelle de fichiers S3 perturbera temporairement l'accès au partage de fichiers. Assurez-vous de planifier une fenêtre de maintenance si nécessaire.
+ Le price-to-performance ratio d'une instance Amazon EC2 fait référence à la puissance de calcul que vous obtenez pour le prix que vous payez. Généralement, les instances Amazon EC2 de nouvelle génération offrent le meilleur price-to-performance ratio, avec du matériel plus récent et des performances améliorées à un coût relativement inférieur à celui des anciennes générations. Des facteurs tels que le type d'instance, la région et les modèles d'utilisation ont une incidence sur ce ratio. Il est donc important de sélectionner l'instance adaptée à votre charge de travail spécifique afin d'optimiser la rentabilité.

## Régler le niveau de sécurité des PME
<a name="Throughput-Security-Level"></a>

Le SMBv3 protocole permet à la fois la signature SMB et le chiffrement SMB, ce qui présente certains compromis en termes de performances et de sécurité. Pour optimiser le débit, vous pouvez ajuster le niveau de sécurité SMB de votre passerelle afin de spécifier quelles fonctionnalités de sécurité sont appliquées aux connexions client. Pour plus d'informations, voir [Définir un niveau de sécurité pour votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).

Lorsque vous ajustez le niveau de sécurité SMB, tenez compte des points suivants :
+ Le niveau de sécurité par défaut pour S3 File Gateway est **Appliquer le chiffrement**. Ce paramètre applique à la fois le chiffrement et la signature pour les connexions des clients SMB aux partages de fichiers de passerelle, ce qui signifie que tout le trafic entre le client et la passerelle est chiffré. Ce paramètre n'affecte pas le trafic en provenance de la passerelle AWS, qui est toujours chiffré.

  La passerelle limite chaque connexion client chiffrée à un seul vCPU. Par exemple, si vous n'avez qu'un seul client chiffré, ce client sera limité à un seul vCPU, même si 4 vCPU ou plus CPUs sont alloués à la passerelle. De ce fait, le débit des connexions chiffrées entre un seul client et S3 File Gateway est généralement limité entre 40 et 60 Mo/s.
+ Si vos exigences en matière de sécurité vous permettent d'adopter une posture plus souple, vous pouvez modifier le niveau de sécurité sur **Négocié par le client**, ce qui désactivera le chiffrement SMB et appliquera uniquement la signature SMB. Avec ce paramètre, les connexions client à la passerelle peuvent utiliser plusieurs vCPUs, ce qui se traduit généralement par une augmentation des performances de débit.
**Note**  
Après avoir modifié le niveau de sécurité SMB de votre passerelle de fichiers S3, vous devez attendre que le statut du partage de fichiers passe de **Updating** à **Available** dans la console Storage Gateway, puis déconnecter et reconnecter vos clients SMB pour que le nouveau paramètre prenne effet.

## Utiliser plusieurs threads et clients pour paralléliser les opérations d'écriture
<a name="Throughput-Parallel-Writes"></a>

Il est difficile d'atteindre des performances de débit maximales avec une passerelle de fichiers S3 qui n'utilise qu'un seul client NFS ou SMB pour écrire un fichier à la fois, car l'écriture séquentielle à partir d'un seul client est une opération à thread unique. Nous recommandons plutôt d'utiliser plusieurs threads provenant de chaque client NFS ou SMB pour écrire plusieurs fichiers en parallèle, et d'utiliser plusieurs clients NFS ou SMB simultanément sur votre passerelle de fichiers S3 afin d'optimiser le débit de la passerelle.

L'utilisation de plusieurs threads peut améliorer considérablement les performances. Cependant, l'utilisation d'un plus grand nombre de threads nécessite davantage de ressources système, ce qui peut avoir un impact négatif sur les performances si la taille de la passerelle n'est pas adaptée à l'augmentation de la charge. Dans un déploiement classique, vous pouvez vous attendre à obtenir de meilleures performances de débit à mesure que vous ajoutez de nouveaux threads et clients, jusqu'à ce que vous atteigniez les limites matérielles et de bande passante maximales pour votre passerelle. Nous vous recommandons d'essayer différents nombres de threads afin de trouver l'équilibre optimal entre vitesse et utilisation des ressources système pour votre configuration matérielle et réseau spécifique.

Tenez compte des informations suivantes concernant les outils courants qui peuvent vous aider à tester la configuration de votre thread et de votre client :
+ Vous pouvez tester les performances d'écriture multithread en utilisant des outils tels que Robocopy pour copier un ensemble de fichiers vers un partage de fichiers sur votre passerelle. Par défaut, Robocopy utilise 8 fils lors de la copie de fichiers, mais vous pouvez spécifier jusqu'à 128 fils.

  Pour utiliser plusieurs threads avec Robocopy, ajoutez le `/MT:n` commutateur à votre commande, où `n` est le nombre de threads que vous souhaitez utiliser. Par exemple :

  `robocopy C:\source D:\destination /MT:64`

  Cette commande utilisera 64 threads pour l'opération de copie.
**Note**  
Nous ne recommandons pas d'utiliser l'Explorateur Windows pour glisser-déposer des fichiers lors des tests de débit maximal, car cette méthode est limitée à un seul thread et copie les fichiers de manière séquentielle.

  Pour plus d'informations, consultez [Robocopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy) sur le site Web de Microsoft Learn.
+ Vous pouvez également effectuer des tests à l'aide d'outils d'analyse comparative du stockage courants tels que DISKSPD ou FIO. Ces outils proposent des options permettant d'ajuster le nombre de threads, la profondeur d'E/S et d'autres paramètres en fonction de vos exigences de charge de travail spécifiques.

  DiskSpd vous permet de contrôler le nombre de threads à l'aide du `-t` paramètre. Par exemple :

  `diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat`

  Cet exemple de commande effectue les opérations suivantes :
  + Crée un fichier de test de 10 Go () `-c1G`
  + Fonctionne pendant 300 secondes (`-d300`)
  + Effectue un I/O test aléatoire avec 50 % de lectures, 50 % d'écritures (`-r -w50`)
  + Utilise 64 fils (s`-t64`)
  + Définit la profondeur de la file d'attente à 32 par thread (`-o32`)
  + Utilise une taille de bloc de 1 Mo () `-b1M`
  + Désactive la mise en cache matérielle et logicielle () `-h -L`

  Pour plus d'informations, voir [Utiliser DISKSPD pour tester les performances de stockage des charges de travail sur le site Web](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113) de Microsoft Learn.
+ FIO utilise le `numjobs` paramètre pour contrôler le nombre de threads parallèles. Par exemple :

  `fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting`

  Cet exemple de commande effectue les opérations suivantes :
  + Effectue un I/O test aléatoire (`--rw=randrw`)
  + Effectue 70 % de lectures et 30 % d'écritures (`--rwmixread=70`)
  + Utilise une taille de bloc de 1 Mo () `--bs=1M`
  + Règle la I/O profondeur à 64 (`--iodepth=64`)
  + Tests sur un fichier de 10 Go (`--size=10G`)
  + Fonctionne pendant 5 minutes (`--runtime=300`)
  + Crée 64 tâches parallèles (threads) (`--numjobs=64`)
  + Utilise un I/O moteur asynchrone () `--ioengine=libaio`
  + Regroupe les résultats pour faciliter l'analyse (`--group_reporting`)

  Pour plus d'informations, consultez la page de [manuel fio](https://linux.die.net/man/1/fio) Linux.

## Désactiver l'actualisation automatique du cache
<a name="Throughput-Cache-Refresh"></a>

La fonctionnalité d'actualisation automatique du cache permet à votre passerelle de fichiers S3 d'actualiser automatiquement ses métadonnées, ce qui permet de capturer les modifications apportées par les utilisateurs ou les applications à votre ensemble de fichiers en écrivant directement dans le compartiment Amazon S3, plutôt que par le biais de la passerelle. Pour plus d'informations, consultez [Actualisation du cache d'objets du compartiment Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).

Pour optimiser le débit de la passerelle, nous recommandons de désactiver cette fonctionnalité dans les déploiements où toutes les lectures et écritures dans le compartiment Amazon S3 seront effectuées via votre passerelle de fichiers S3.

Lorsque vous configurez l'actualisation automatique du cache, tenez compte des points suivants :
+ Si vous devez utiliser l'actualisation automatique du cache parce que des utilisateurs ou des applications de votre déploiement écrivent parfois directement sur Amazon S3, nous vous recommandons de configurer l'intervalle de temps le plus long possible entre les actualisations, ce qui est toujours pratique pour les besoins de votre entreprise. Un intervalle d'actualisation du cache plus long permet de réduire le nombre d'opérations de métadonnées que la passerelle doit effectuer lors de la navigation dans les répertoires ou de la modification de fichiers. 

  Par exemple : définissez l'actualisation automatique du cache sur 24 heures, au lieu de 5 minutes, si cela est acceptable pour votre charge de travail.
+ L'intervalle de temps minimum est de 5 minutes. L'intervalle maximal est de 30 jours.
+ Si vous choisissez de définir un intervalle d'actualisation du cache très court, nous vous recommandons de tester l'expérience de navigation dans les annuaires pour vos clients NFS et SMB. Le temps nécessaire pour actualiser le cache de la passerelle peut augmenter considérablement en fonction du nombre de fichiers et de sous-répertoires contenus dans votre compartiment Amazon S3.

## Augmenter le nombre de threads de téléchargement sur Amazon S3
<a name="Throughput-Uploader-Threads"></a>

Par défaut, S3 File Gateway ouvre 8 threads pour le téléchargement de données Amazon S3, ce qui fournit une capacité de téléchargement suffisante pour la plupart des déploiements classiques. Cependant, il est possible qu'une passerelle reçoive des données de clients NFS et SMB à un débit supérieur à celui qu'elle peut charger sur Amazon S3 avec la capacité standard de 8 threads, ce qui peut amener le cache local à atteindre sa limite de stockage.

Dans certaines circonstances, Support cela peut augmenter le nombre de threads de téléchargement Amazon S3 pour votre passerelle de 8 à 40, ce qui permet de charger davantage de données en parallèle. En fonction de la bande passante et d'autres facteurs spécifiques à votre déploiement, cela peut augmenter considérablement les performances de téléchargement et contribuer à réduire la quantité de stockage en cache nécessaire pour prendre en charge votre charge de travail.

Nous vous recommandons d'utiliser cette `CachePercentDirty` CloudWatch métrique pour surveiller la quantité de données stockées sur les disques de cache de la passerelle locale qui n'ont pas encore été chargées vers Amazon S3, et de contacter Support pour déterminer si l'augmentation du nombre de threads de téléchargement peut améliorer le débit de votre passerelle de fichiers S3. Pour plus d'informations, consultez la section [Comprendre les métriques de passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).

**Note**  
Ce paramètre consomme des ressources supplémentaires du processeur de la passerelle. Nous recommandons de surveiller l'utilisation du processeur de la passerelle et d'augmenter les ressources du processeur allouées si nécessaire.

## Augmenter les paramètres de délai d'expiration des PME
<a name="Throughput-SMB-Timeout"></a>

Lorsque S3 File Gateway copie des fichiers volumineux vers un partage de fichiers SMB, la connexion du client SMB peut être interrompue après une période prolongée.

Nous vous recommandons d'étendre le délai d'expiration de session SMB pour vos clients SMB à 20 minutes ou plus, en fonction de la taille des fichiers et de la vitesse d'écriture de votre passerelle. La valeur par défaut est de 300 secondes ou 5 minutes. Pour plus d'informations, consultez la section [Votre tâche de sauvegarde de passerelle échoue ou des erreurs se produisent lors de l'écriture sur votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).

## Activez le verrouillage opportuniste pour les applications compatibles
<a name="Throughput-Opportunistic-Locking"></a>

Le verrouillage opportuniste, ou « oplocks », est activé par défaut pour chaque nouvelle passerelle de fichiers S3. Lorsqu'il utilise des oplocks avec des applications compatibles, le client regroupe plusieurs petites opérations en opérations plus importantes, ce qui est plus efficace pour le client, la passerelle et le réseau. Nous vous recommandons de conserver le verrouillage opportuniste activé si vous utilisez des applications qui exploitent la mise en cache locale côté client, telles que Microsoft Office, Adobe Suite et bien d'autres, car cela peut améliorer considérablement les performances. 

Si vous désactivez le verrouillage opportuniste, les applications qui prennent en charge les oplocks ouvriront généralement les fichiers volumineux (50 Mo ou plus) beaucoup plus lentement. Ce délai est dû au fait que la passerelle envoie des données par parties de 4 Ko, ce qui se traduit par un débit élevé I/O ou faible.

## Ajustez la capacité de la passerelle en fonction de la taille de l'ensemble de fichiers de travail
<a name="Throughput-Gateway-Capacity"></a>

Le paramètre de capacité de la passerelle indique le nombre maximal de fichiers pour lesquels votre passerelle stockera les métadonnées dans son cache local. Par défaut, la capacité de la passerelle est définie sur **Petite**, ce qui signifie que la passerelle stocke les métadonnées d'un maximum de 5 millions de fichiers. Le paramètre par défaut fonctionne bien pour la plupart des charges de travail, même s'il y a des centaines de millions, voire des milliards d'objets dans Amazon S3, car seul un petit sous-ensemble de fichiers est activement accessible à un moment donné dans un déploiement classique. Ce groupe de fichiers est appelé « ensemble de travail ».

Si votre charge de travail accède régulièrement à un ensemble de fichiers de plus de 5 millions, votre passerelle devra effectuer de fréquentes expulsions du cache, c'est-à-dire de petites opérations d'E/S stockées dans la RAM et conservées sur le disque racine. Cela peut avoir un impact négatif sur les performances de la passerelle, car celle-ci récupère de nouvelles données depuis Amazon S3.

Vous pouvez surveiller la `IndexEvictions` métrique pour déterminer le nombre de fichiers dont les métadonnées ont été supprimées du cache pour faire de la place à de nouvelles entrées. Pour plus d'informations, consultez la section [Comprendre les métriques de passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).

Nous vous recommandons d'utiliser l'action `UpdateGatewayInformation` API pour augmenter la capacité de la passerelle afin qu'elle corresponde au nombre de fichiers de votre ensemble de travail habituel. Pour de plus amples informations, veuillez consulter [UpdateGatewayInformation](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html).

**Note**  
L'augmentation de la capacité de la passerelle nécessite de la RAM et de la capacité du disque racine supplémentaires.  
Les fichiers de petite taille (5 millions de fichiers) nécessitent au moins 16 Go de RAM et 80 Go de disque racine.
Le format moyen (10 millions de fichiers) nécessite au moins 32 Go de RAM et 160 Go de disque racine.
Les fichiers volumineux (20 millions de fichiers) nécessitent 64 Go de RAM et 240 Go de disque racine.

**Important**  
La capacité de la passerelle ne peut pas être diminuée.

## Déployez plusieurs passerelles pour des charges de travail plus importantes
<a name="Throughput-Multiple-Gateways"></a>

Nous vous recommandons de répartir votre charge de travail sur plusieurs passerelles lorsque cela est possible, plutôt que de consolider de nombreux partages de fichiers sur une seule grande passerelle. Par exemple, vous pouvez isoler un partage de fichiers très utilisé sur une passerelle, tout en regroupant les partages de fichiers les moins fréquemment utilisés sur une autre passerelle.

Lorsque vous planifiez un déploiement avec plusieurs passerelles et partages de fichiers, tenez compte des points suivants :
+ Le nombre maximum de partages de fichiers sur une passerelle unique est de 50, mais le nombre de partages de fichiers gérés par une passerelle peut avoir un impact sur les performances de la passerelle. Pour plus d'informations, consultez la section [Conseils de performance pour les passerelles comportant plusieurs partages de fichiers](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares).
+ Les ressources de chaque passerelle de fichiers S3 sont partagées entre tous les partages de fichiers, sans partitionnement.
+ Un partage de fichiers unique très utilisé peut avoir un impact sur les performances des autres partages de fichiers sur la passerelle.

**Note**  
Il est déconseillé de créer plusieurs partages de fichiers mappés vers le même emplacement Amazon S3 à partir de plusieurs passerelles, sauf si au moins l'un d'entre eux est en lecture seule.  
Les écritures simultanées sur le même fichier à partir de plusieurs passerelles sont considérées comme un scénario à écritures multiples, ce qui peut entraîner des problèmes d'intégrité des données.

# Optimisation de la passerelle de fichiers S3 pour les sauvegardes de bases de données SQL Server
<a name="SQL-Backup-Best-Practices"></a>

Les sauvegardes de base de données constituent un cas d'utilisation courant et recommandé pour S3 File Gateway, qui assure une conservation rentable à court et à long terme en stockant les sauvegardes de base de données dans Amazon S3, avec la possibilité d'effectuer un cycle de vie afin de réduire les coûts des niveaux de stockage selon les besoins. Grâce à cette solution, vous pouvez réduire le besoin d'applications de sauvegarde d'entreprise à l'aide d'outils intégrés tels que SQL Server Management Studio et Oracle RMAN.

Les sections suivantes décrivent les meilleures pratiques pour optimiser le déploiement de votre passerelle de fichiers S3 afin d'optimiser les performances et de prendre en charge de manière rentable des centaines de téraoctets de sauvegardes de bases de données SQL. Les conseils fournis dans chaque section contribuent progressivement à améliorer le débit global. Bien qu'aucune de ces recommandations ne soit requise et qu'elles ne soient pas interdépendantes, elles ont été sélectionnées et ordonnées d'une manière logique qui permet de tester et d'ajuster les Support implémentations de S3 File Gateway. Lorsque vous implémentez et testez ces suggestions, gardez à l'esprit que chaque déploiement de S3 File Gateway est unique et que les résultats peuvent donc varier.

S3 File Gateway fournit une interface de fichiers permettant de stocker et de récupérer des objets Amazon S3 à l'aide des protocoles de fichiers NFS ou SMB standard, avec un mappage 1:1 natif entre le fichier et l'objet. Vous déployez S3 File Gateway en tant que machine virtuelle soit sur site dans votre VMware environnement KVM Microsoft Hyper-V ou Linux, soit dans le AWS cloud en tant qu'instance Amazon EC2. S3 File Gateway n'est pas conçu pour remplacer complètement le NAS d'entreprise. S3 File Gateway émule un système de fichiers, mais il ne s'agit pas d'un système de fichiers. L'utilisation d'Amazon S3 comme stockage dorsal durable entraîne une surcharge supplémentaire pour chaque I/O opération. L'évaluation des performances de S3 File Gateway par rapport à celles d'un NAS ou d'un serveur de fichiers existant ne constitue donc pas une comparaison équivalente.

## Déployez votre passerelle au même endroit que vos serveurs SQL
<a name="SQL-Backup-Location"></a>

Nous vous recommandons de déployer votre dispositif virtuel S3 File Gateway dans un emplacement physique avec une latence réseau aussi faible que possible entre celui-ci et vos serveurs SQL. Lorsque vous choisissez un emplacement pour votre passerelle, tenez compte des points suivants :
+ La réduction de la latence réseau vers la passerelle peut contribuer à améliorer les performances des clients PME, tels que les serveurs SQL.
+ La passerelle de fichiers S3 est conçue pour tolérer une latence réseau plus élevée entre la passerelle et Amazon S3 qu'entre la passerelle et les clients.
+ Pour les instances de passerelle de fichiers S3 déployées dans Amazon EC2, nous recommandons de conserver la passerelle et les serveurs SQL dans le même groupe de placement. Pour plus d'informations, consultez la section [Groupes de placement pour vos instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) dans le guide de l'utilisateur d'Amazon Elastic Compute Cloud.

## Réduisez les goulots d'étranglement causés par la lenteur des disques
<a name="SQL-Backup-IoWaitPercent"></a>

Nous vous recommandons de surveiller la `IoWaitPercent` CloudWatch métrique afin d'identifier les problèmes de performances pouvant résulter de la lenteur des disques de stockage sur votre passerelle de fichiers S3. Lorsque vous essayez d'optimiser les problèmes de performances liés au disque, tenez compte des points suivants :
+ `IoWaitPercent`indique le pourcentage de temps pendant lequel le processeur attend une réponse de la racine ou des disques de cache.
+ Lorsqu'il `IoWaitPercent` est supérieur à 5 à 10 %, cela indique généralement un goulot d'étranglement des performances de la passerelle dû à des disques peu performants. Cette métrique doit être aussi proche que possible de 0 %, ce qui signifie que la passerelle n'attend jamais sur le disque, ce qui permet d'optimiser les ressources du processeur.
+ Vous pouvez consulter l'`IoWaitPercent`onglet **Monitoring** de la console Storage Gateway ou configurer des CloudWatch alarmes recommandées pour vous avertir automatiquement si la métrique dépasse un seuil spécifique. Pour plus d'informations, consultez la section [Création d' CloudWatch alarmes recommandées pour votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html).
+ Nous vous recommandons d'utiliser l' NVMe un ou l'autre SSD pour les disques racine et de cache de votre passerelle afin de minimiser`IoWaitPercent`.

## Ajuster l'allocation des ressources de la machine virtuelle S3 File Gateway pour le processeur, la RAM et les disques de cache
<a name="SQL-Backup-Resource-Allocation"></a>

Lorsque vous essayez d'optimiser le débit de votre passerelle de fichiers S3, il est important d'allouer suffisamment de ressources à la machine virtuelle de passerelle, notamment le processeur, la RAM et les disques de cache. Les exigences minimales en matière de ressources virtuelles de 4 CPUs, 16 Go de RAM et 150 Go de stockage de cache ne conviennent généralement qu'aux petites charges de travail. Lorsque vous allouez des ressources virtuelles pour des charges de travail plus importantes, nous recommandons ce qui suit :
+ Augmentez le nombre CPUs alloué entre 16 et 48, en fonction de l'utilisation typique du processeur générée par votre passerelle de fichiers S3. Vous pouvez surveiller l'utilisation du processeur à l'aide de la `UserCpuPercent` métrique. Pour plus d'informations, consultez la section [Comprendre les métriques de passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ Augmentez la RAM allouée entre 32 et 64 Go.
**Note**  
S3 File Gateway ne peut pas utiliser plus de 64 Go de RAM.
+ Utilisez NVMe un SSD pour les disques racine et le disque de cache, et dimensionnez vos disques de cache en fonction de l'ensemble de données de travail maximal que vous prévoyez d'écrire sur la passerelle. Pour plus d'informations, consultez les [meilleures pratiques en matière de dimensionnement du cache de S3 File Gateway](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) sur le YouTube canal officiel Amazon Web Services.
+ Ajoutez au moins 4 disques de cache virtuels à la passerelle, plutôt que d'utiliser un seul grand disque. Plusieurs disques virtuels peuvent améliorer les performances même s'ils partagent le même disque physique sous-jacent, mais les améliorations sont généralement plus importantes lorsque les disques virtuels sont situés sur des disques physiques sous-jacents différents.

  Par exemple, si vous souhaitez déployer 12 To de cache, vous pouvez utiliser l'une des configurations suivantes :
  + 4 disques de cache de 3 To
  + 8 disques de cache de 1,5 To
  + 12 disques de cache de 1 To

  Outre les performances, cela permet une gestion plus efficace de la machine virtuelle au fil du temps. À mesure que votre charge de travail évolue, vous pouvez augmenter progressivement le nombre de disques de cache et votre capacité de cache globale, tout en conservant la taille initiale de chaque disque virtuel afin de préserver l'intégrité de la passerelle.

  Pour plus d'informations, voir [Déterminer la quantité de stockage sur disque local](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).

Lorsque vous déployez S3 File Gateway en tant qu'instance Amazon EC2, tenez compte des points suivants :
+ Le type d'instance que vous choisissez peut avoir un impact significatif sur les performances de la passerelle. Amazon EC2 offre une grande flexibilité pour ajuster l'allocation des ressources pour votre instance de passerelle de fichiers S3.
+ Pour connaître les types d'instances Amazon EC2 recommandés pour la passerelle de fichiers S3, consultez la section [Exigences relatives aux types d'instances Amazon EC2](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2).
+ Vous pouvez modifier le type d'instance Amazon EC2 qui héberge une passerelle de fichiers S3 active. Cela vous permet d'ajuster facilement la génération de matériel Amazon EC2 et l'allocation des ressources pour trouver le ratio idéal price-to-performance. Pour modifier le type d'instance, suivez la procédure suivante dans la console Amazon EC2 :

  1. Arrêtez l'instance Amazon EC2.

  1. Modifiez le type d'instance Amazon EC2.

  1. Allumez l'instance Amazon EC2.
**Note**  
L'arrêt d'une instance hébergeant une passerelle de fichiers S3 perturbera temporairement l'accès au partage de fichiers. Assurez-vous de planifier une fenêtre de maintenance si nécessaire.
+ Le price-to-performance ratio d'une instance Amazon EC2 fait référence à la puissance de calcul que vous obtenez pour le prix que vous payez. Généralement, les instances Amazon EC2 de nouvelle génération offrent le meilleur price-to-performance ratio, avec du matériel plus récent et des performances améliorées à un coût relativement inférieur à celui des anciennes générations. Des facteurs tels que le type d'instance, la région et les modèles d'utilisation ont une incidence sur ce ratio. Il est donc important de sélectionner l'instance adaptée à votre charge de travail spécifique afin d'optimiser la rentabilité.

## Améliorez le débit des clients des PME en ajustant le niveau de sécurité de votre passerelle de fichiers S3
<a name="SQL-Backup-Security-Level"></a>

Le SMBv3 protocole permet à la fois la signature SMB et le chiffrement SMB, ce qui présente certains compromis en termes de performances et de sécurité. Pour optimiser le débit, vous pouvez ajuster le niveau de sécurité SMB de votre passerelle afin de spécifier quelles fonctionnalités de sécurité sont appliquées aux connexions client. Pour plus d'informations, voir [Définir un niveau de sécurité pour votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).

Lorsque vous ajustez le niveau de sécurité SMB, tenez compte des points suivants :
+ Le niveau de sécurité par défaut pour S3 File Gateway est **Appliquer le chiffrement**. Ce paramètre applique à la fois le chiffrement et la signature pour les connexions des clients SMB aux partages de fichiers de passerelle, ce qui signifie que tout le trafic entre le client et la passerelle est chiffré. Ce paramètre n'affecte pas le trafic en provenance de la passerelle AWS, qui est toujours chiffré.

  La passerelle limite chaque connexion client chiffrée à un seul vCPU. Par exemple, si vous n'avez qu'un seul client chiffré, ce client sera limité à un seul vCPU, même si 4 vCPU ou plus CPUs sont alloués à la passerelle. De ce fait, le débit des connexions chiffrées entre un seul client et S3 File Gateway est généralement limité entre 40 et 60 Mo/s.
+ Si vos exigences en matière de sécurité vous permettent d'adopter une posture plus souple, vous pouvez modifier le niveau de sécurité sur **Négocié par le client**, ce qui désactivera le chiffrement SMB et appliquera uniquement la signature SMB. Avec ce paramètre, les connexions client à la passerelle peuvent utiliser plusieurs vCPUs, ce qui se traduit généralement par une augmentation des performances de débit.
**Note**  
Après avoir modifié le niveau de sécurité SMB de votre passerelle de fichiers S3, vous devez attendre que le statut du partage de fichiers passe de **Updating** à **Available** dans la console Storage Gateway, puis déconnecter et reconnecter vos clients SMB pour que le nouveau paramètre prenne effet.

## Améliorez le débit des clients PME en divisant les sauvegardes SQL en plusieurs fichiers
<a name="SQL-Backup-Multiple-Files"></a>
+ Il est difficile d'atteindre des performances de débit maximales avec une passerelle de fichiers S3 qui permet à un seul serveur SQL d'écrire un fichier à la fois, car l'écriture séquentielle à partir d'un seul serveur SQL est une opération à thread unique. Nous vous recommandons plutôt d'utiliser plusieurs threads de chaque serveur SQL pour écrire plusieurs fichiers en parallèle, et d'utiliser plusieurs serveurs SQL simultanément sur votre passerelle de fichiers S3 afin d'optimiser le débit de la passerelle. Avec les sauvegardes SQL, la division des sauvegardes en plusieurs fichiers permet à chaque fichier d'utiliser un thread distinct, qui écrira plusieurs fichiers simultanément sur le partage de fichiers S3 File Gateway. Plus vous avez de threads, plus vous pouvez atteindre un débit élevé, dans les limites de la passerelle.
+ SQL Server prend en charge l'écriture simultanée dans plusieurs fichiers au cours d'une seule opération de sauvegarde. Par exemple, vous pouvez spécifier plusieurs destinations de fichiers à l'aide des commandes T-SQL ou de SQL Server Management Studio (SSMS). Chaque fichier utilise un thread distinct pour envoyer les données du serveur SQL au partage de fichiers de la passerelle. Cette approche permet d'améliorer le I/O débit, ce qui peut améliorer considérablement la vitesse et l'efficacité des sauvegardes.

Lorsque vous configurez vos sauvegardes SQL Server, tenez compte des points suivants :
+ En divisant les sauvegardes en plusieurs fichiers, les administrateurs de SQL Server peuvent optimiser les temps de sauvegarde et gérer plus efficacement les sauvegardes de bases de données volumineuses.
+ Le nombre de fichiers utilisés dépend de la configuration de stockage du serveur et des exigences en matière de performances. Pour les bases de données volumineuses, nous recommandons de diviser les sauvegardes en plusieurs fichiers plus petits de 10 Go à 20 Go chacun.
+ Il n'existe aucune limite stricte quant au nombre de fichiers dans lesquels SQL Server peut écrire pendant une sauvegarde, mais des considérations pratiques telles que l'architecture de stockage et la bande passante réseau devraient guider ce choix.

Pour en savoir plus, consultez :
+ [Sauvegardez SQL Server 43 à 67 % plus rapidement en écrivant dans plusieurs fichiers](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [Stockez facilement vos sauvegardes SQL Server dans Amazon S3 à l'aide de File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)

## Empêchez les échecs de copie de fichiers volumineux en augmentant les paramètres de délai d'expiration SMB
<a name="SQL-Backup-SMB-Timeout"></a>

Lorsque S3 File Gateway copie des fichiers de sauvegarde SQL volumineux vers un partage de fichiers SMB, la connexion du client SMB peut être interrompue après une période prolongée. Nous vous recommandons d'étendre le délai d'expiration de session SMB pour vos clients SMB SQL Server à 20 minutes ou plus, en fonction de la taille des fichiers et de la vitesse d'écriture de votre passerelle. La valeur par défaut est de 300 secondes ou 5 minutes. Pour plus d'informations, consultez la section [Votre tâche de sauvegarde de passerelle échoue ou des erreurs se produisent lors de l'écriture sur votre passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).

## Augmenter le nombre de threads de téléchargement sur Amazon S3
<a name="SQL-Backup-Uploader-Threads"></a>

Par défaut, S3 File Gateway ouvre 8 threads pour le téléchargement de données Amazon S3, ce qui fournit une capacité de téléchargement suffisante pour la plupart des déploiements classiques. Cependant, il est possible qu'une passerelle reçoive des données en provenance de serveurs SQL à un débit supérieur à celui qu'elle peut télécharger sur Amazon S3 avec la capacité standard de 8 threads, ce qui peut amener le cache local à atteindre sa limite de stockage.

Dans certaines circonstances, Support cela peut augmenter le nombre de threads de téléchargement Amazon S3 pour votre passerelle de 8 à 40, ce qui permet de charger davantage de données en parallèle. En fonction de la bande passante et d'autres facteurs spécifiques à votre déploiement, cela peut augmenter considérablement les performances de téléchargement et contribuer à réduire la quantité de stockage en cache nécessaire pour prendre en charge votre charge de travail.

Nous vous recommandons d'utiliser cette `CachePercentDirty` CloudWatch métrique pour surveiller la quantité de données stockées sur les disques de cache de la passerelle locale qui n'ont pas encore été chargées vers Amazon S3, et de contacter Support pour déterminer si l'augmentation du nombre de threads de téléchargement peut améliorer le débit de votre passerelle de fichiers S3. Pour plus d'informations, consultez la section [Comprendre les métriques de passerelle](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).

**Note**  
Ce paramètre consomme des ressources supplémentaires du processeur de la passerelle. Nous recommandons de surveiller l'utilisation du processeur de la passerelle et d'augmenter les ressources du processeur allouées si nécessaire.

## Désactiver l'actualisation automatique du cache
<a name="SQL-Backup-Cache-Refresh"></a>

La fonctionnalité d'actualisation automatique du cache permet à votre passerelle de fichiers S3 d'actualiser automatiquement ses métadonnées, ce qui permet de capturer les modifications apportées par les utilisateurs ou les applications à votre ensemble de fichiers en écrivant directement dans le compartiment Amazon S3, plutôt que par le biais de la passerelle. Pour plus d'informations, consultez [Actualisation du cache d'objets du compartiment Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).

Pour optimiser le débit de la passerelle, nous recommandons de désactiver cette fonctionnalité dans les déploiements où toutes les lectures et écritures dans le compartiment Amazon S3 seront effectuées via votre passerelle de fichiers S3.

Lorsque vous configurez l'actualisation automatique du cache, tenez compte des points suivants :
+ Si vous devez utiliser l'actualisation automatique du cache parce que des utilisateurs ou des applications de votre déploiement écrivent parfois directement sur Amazon S3, nous vous recommandons de configurer l'intervalle de temps le plus long possible entre les actualisations, ce qui est toujours pratique pour les besoins de votre entreprise. Un intervalle d'actualisation du cache plus long permet de réduire le nombre d'opérations de métadonnées que la passerelle doit effectuer lors de la navigation dans les répertoires ou de la modification de fichiers. 

  Par exemple : définissez l'actualisation automatique du cache sur 24 heures, au lieu de 5 minutes, si cela est acceptable pour votre charge de travail.
+ L'intervalle de temps minimum est de 5 minutes. L'intervalle maximal est de 30 jours.
+ Si vous choisissez de définir un intervalle d'actualisation du cache très court, nous vous recommandons de tester l'expérience de navigation dans les annuaires pour vos serveurs SQL. Le temps nécessaire pour actualiser le cache de la passerelle peut augmenter considérablement en fonction du nombre de fichiers et de sous-répertoires contenus dans votre compartiment Amazon S3.

## Déployez plusieurs passerelles pour prendre en charge la charge de travail
<a name="SQL-Backup-Multiple-Gateways"></a>

Storage Gateway peut prendre en charge les sauvegardes SQL pour les environnements de grande taille comprenant des centaines de bases de données SQL, plusieurs serveurs SQL et des centaines de téraoctets de données de sauvegarde en répartissant la charge de travail sur plusieurs passerelles.

Lorsque vous planifiez un déploiement avec plusieurs passerelles et serveurs SQL, tenez compte des points suivants :
+ Une passerelle unique peut généralement télécharger jusqu'à 20 To par jour, avec des ressources matérielles et une bande passante suffisantes. Vous pouvez augmenter cette limite jusqu'à 40 To par jour en [augmentant le nombre de threads de téléchargement Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads).
+ Nous vous recommandons d'effectuer un proof-of-concept test pour mesurer les performances et prendre en compte toutes les variables de votre déploiement. Après avoir déterminé le débit maximal de votre charge de travail de sauvegarde SQL, vous pouvez adapter le nombre de passerelles en fonction de vos besoins.
+ Nous vous recommandons de concevoir votre solution en tenant compte de la croissance, car le nombre et la taille des bases de données peuvent augmenter au fil du temps. Pour continuer à évoluer et à prendre en charge une charge de travail croissante, vous pouvez déployer des passerelles supplémentaires selon vos besoins.

## Ressources supplémentaires pour les charges de travail de sauvegarde des bases de données
<a name="SQL-Backup-Additional-Resources"></a>
+ [Stockez les sauvegardes SQL Server dans Amazon S3 à l'aide de AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [Stockez facilement vos sauvegardes SQL Server dans Amazon S3 à l'aide de File Gateway](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [Utilisation AWS Storage Gateway pour stocker des sauvegardes de bases de données Oracle dans Amazon S3](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Sauvegarde de bases de données Oracle sur Amazon S3 à grande échelle](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [Intégrez une base de données SAP ASE à Amazon S3 à l'aide de AWS Storage Gateway](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [Comment One AWS Hero l'utilise AWS Storage Gateway pour la sauvegarde dans le cloud](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [Meilleures pratiques en matière de dimensionnement du cache de S3 File Gateway](https://www.youtube.com/watch?v=-ibL1eEcROI)