Ce livre blanc est fourni à titre de référence historique uniquement. Certains contenus sont peut-être périmés et certains liens ne sont peut-être pas disponibles.
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.
# Architecture axée sur la sécurité et les performances
Que vous choisissiez d'exécuter Oracle Database sur Amazon RDS ou Amazon EC2, l'optimisation de chaque composant de l'infrastructure améliorera la sécurité, les performances et la fiabilité. Dans les sections suivantes, les meilleures pratiques pour optimiser la configuration réseau, le type d'instance et le stockage de base de données dans le cadre d'une implémentation de base de données Oracle AWS sont abordées.
**Topics**
+ [Configuration réseau](network-configuration.md)
+ [Type d' EC2 instance Amazon](amazon-ec2-instance-type.md)
+ [stockage de base de données](database-storage.md)
# Configuration réseau
Avec Amazon Virtual Private Cloud (Amazon VPC), vous pouvez mettre en service une section isolée de manière logique dédiée à votre compte. AWS Cloud Vous avez le contrôle total de votre environnement réseau virtuel, y compris la sélection de votre propre plage d'adresses IP, la création de sous-réseaux, les paramètres de sécurité et la configuration des tables de routage et des passerelles réseau.
Un *sous-réseau* est une plage d'adresses IP dans votre Amazon VPC. Vous pouvez lancer des ressources AWS dans un sous-réseau de votre choix. Utilisez un sous-réseau public pour les ressources qui doivent être connectées à Internet et un sous-réseau privé pour les ressources qui ne doivent pas l'être connectées.
Pour protéger les AWS ressources de chaque sous-réseau, vous pouvez utiliser plusieurs niveaux de sécurité, notamment des groupes de sécurité et des listes de contrôle d'accès réseau (ACLs).
Le tableau suivant décrit les principales différences entre les groupes de sécurité et le réseau ACLs.
| **Groupe de sécurité** | **ACL réseau** |
| --- | --- |
| Fonctionne au niveau instance (première couche de défense) | Fonctionne au niveau sous-réseau (seconde couche de défense) |
| Supporte uniquement les règles d'autorisation | Supporte les règles d'autorisation et les règles de refus |
| Stateful : le trafic de retour est automatiquement autorisé, quelles que soient les règles | Est sans état : le trafic de retour doit être explicitement autorisé par des règles |
| Evalue toutes les règles avant de décider si le trafic doit être autorisé | Traite les règles par ordre numérique pour décider si le trafic doit être autorisé |
| S'applique à une instance uniquement si quelqu'un indique le groupe de sécurité lors du lancement de l'instance, ou associe ultérieurement le groupe de sécurité à l'instance | S'applique automatiquement à toutes les instances dans sous-réseaux auxquels il est associé (couche de défense de secours, de sorte que vous n'avez pas à compter sur quelqu'un qui indique le groupe de sécurité) |
Amazon VPC assure l'isolation, renforce la sécurité, permet de séparer les EC2 instances Amazon en sous-réseaux et autorise l'utilisation d'adresses IP privées. Tous ces éléments sont importants pour la mise en œuvre des bases de données.
Déployez l'instance de base de données Oracle dans un sous-réseau privé et autorisez uniquement les serveurs d'applications au sein d'Amazon VPC, ou un hôte bastion au sein d'Amazon VPC, à accéder à l'instance de base de données.
Créez des groupes de sécurité appropriés qui autorisent l'accès uniquement à des adresses IP spécifiques via les ports désignés. Ces recommandations s'appliquent à Oracle Database, que vous utilisiez Amazon RDS ou Amazon EC2.
![\[Base de données Oracle dans le sous-réseau privé d'un Amazon VPC\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)
Base de données Oracle dans le sous-réseau privé d'un Amazon VPC
# Type d' EC2 instance Amazon
AWS propose un grand nombre de types d' EC2 instances Amazon. Vous pouvez donc choisir le type d'instance le mieux adapté à votre charge de travail. Cependant, tous les types d'instances disponibles ne conviennent pas parfaitement à l'exécution d'Oracle Database.
Si vous utilisez Amazon RDS pour votre base de données Oracle, il AWS filtre certains types d'instances en fonction des meilleures pratiques et vous propose différentes options pour les instances de classe T, de classe M et de classe R. AWS vous recommande de choisir des instances Amazon RDS basées sur db.m ou r pour toutes les charges de travail de base de données d'entreprise. Les instances R5 sont parfaitement adaptées aux applications gourmandes en mémoire telles que les bases de données hautes performances.
Pour obtenir les dernières informations sur les instances RDS, consultez la page de tarification d'[Amazon RDS for Oracle Database](https://aws.amazon.com/rds/oracle/pricing/). Votre choix du type d'instance Amazon RDS doit être basé sur la charge de travail de la base de données et les licences de base de données Oracle disponibles.
Si vous utilisez votre base de données autogérée sur Amazon EC2, de nombreuses autres options s'offrent à vous pour le type d' EC2 instance Amazon. C'est souvent l'une des raisons pour lesquelles les utilisateurs choisissent d'exécuter Oracle Database sur Amazon EC2 au lieu d'utiliser Amazon RDS.
Les très petits types d'instances ne conviennent pas car Oracle Database consomme beaucoup de ressources en termes d'utilisation du processeur. Les instances dont l'encombrement mémoire est plus important contribuent à améliorer les performances de la base de données en fournissant une meilleure mise en cache et une plus grande surface globale du système (SGA). AWS recommande de choisir des instances présentant un bon équilibre entre mémoire et processeur.
Choisissez le type d'instance qui correspond aux licences de base de données Oracle que vous prévoyez d'utiliser et à l'architecture que vous prévoyez de mettre en œuvre. Pour connaître les architectures les mieux adaptées aux besoins de votre entreprise, consultez le livre blanc [Advanced Architectures for Oracle Database on Amazon](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf). EC2
Oracle Database utilise beaucoup le stockage sur disque pour read/write ses opérations. Il AWS est donc vivement recommandé de n'utiliser que des instances optimisées pour Amazon Elastic Block Store (Amazon EBS). Les instances optimisées pour Amazon EBS fournissent un débit dédié entre Amazon et EC2 Amazon EBS. La bande passante et le débit du sous-système de stockage sont essentiels pour de bonnes performances de base de données. Choisissez des instances offrant de meilleures performances réseau pour de meilleures performances de base de données.
Les familles d'instances suivantes sont parfaitement adaptées à l'exécution d'Oracle Database sur Amazon EC2.
| **Famille d'instances** | **Fonctions** |
| --- | --- |
| Famille M | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Famille X | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Famille R | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Famille I | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Famille Z1d | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
# stockage de base de données
La plupart des utilisateurs utilisent généralement Amazon EBS pour le stockage de bases de données. Pour certaines architectures à très hautes performances, vous pouvez utiliser le stockage d'instance SSDs, mais il convient d'y ajouter le stockage Amazon EBS pour une persistance fiable.
Pour des performances d'IOPS et de base de données élevées et cohérentes, AWS recommande vivement d'utiliser des volumes à usage général (GP2) ou des volumes d'IOPS provisionnés (PIOPS). GP2 et les volumes PIOPS sont disponibles pour Amazon EC2 et Amazon RDS. Reportez-vous au [stockage d'instance de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) pour connaître les dernières limites d'IOPS par volume pour les deux types de volume GP2 et pour les types de volumes PIOPS. GP2 les volumes offrent un excellent équilibre entre prix et performances pour répondre à la plupart des besoins des bases de données. Lorsque votre base de données nécessite des IOPS supérieures à ce que GP2 vous pouvez fournir, les volumes PIOPS sont le bon choix.
Pour les volumes PIOPS, vous spécifiez un taux d'IOPS lorsque vous créez le volume, et Amazon EBS fournit dans les 10 % des performances d'IOPS provisionnées 99,9 % du temps au cours d'une année donnée. Le rapport entre les IOPS provisionnées et la taille du volume demandé peut être de 30 au maximum. Par exemple, pour obtenir 3 000 IOPS, la taille de votre volume doit être d'au moins 100 Go.
Tout comme les volumes PIOPS, les GP2 volumes sont également basés sur des SSD, mais les IOPS que vous obtenez des GP2 volumes peuvent varier entre un nombre d'IOPS de base et un maximum de 3 000 IOPS par volume. Cela fonctionne très bien pour la plupart des charges de travail de base de données, car les performances IOPS nécessaires à la base de données varient de nombreuses fois au cours d'une période donnée en fonction de la taille de la charge et du nombre de requêtes exécutées.
Les performances d'un volume à usage général (SSD) sont régies par la taille du volume, qui détermine le niveau de performance de base du volume et la rapidité avec laquelle il accumule des crédits I/O . Les volumes plus importants offrent des niveaux de performance de base plus élevés et accumulent I/O des crédits plus rapidement.
I/O les crédits représentent la bande passante disponible que votre volume à usage général (SSD) peut utiliser pour exploiter de grandes quantités de bande passante I/O lorsque les performances requises sont supérieures aux performances de base. Plus votre volume dispose de crédits pour les E/S, plus il peut dépasser son niveau de performance de base pendant longtemps et meilleures sont ses performances lorsque des performances supplémentaires sont nécessaires.
Les volumes HDD optimisés (st1) offrent des volumes HDD à faible coût conçus pour les charges de travail intensives nécessitant moins d'IOPS mais un débit élevé. Les bases de données Oracle utilisées pour les entrepôts de données et à des fins d'analyse de données peuvent exploiter les volumes ST1.
Toutes les zones de traitement des journaux ou de stockage de données, telles que les tables externes Oracle ou le stockage BLOB externe nécessitant un débit élevé, peuvent exploiter les volumes st1. Les volumes à débit optimisé (st1) peuvent gérer un maximum de 500 IOPS par volume.
Les volumes Cold HDD (sc1) conviennent à la gestion des systèmes existants, qui sont conservés à des fins de référence ou d'archivage occasionnelles. Ces systèmes sont utilisés moins fréquemment et quelques scans sont effectués par jour sur le volume.
Une bonne approche consiste à estimer la quantité d'IOPS constamment nécessaire pour votre base de données et à allouer suffisamment de GP2 stockage pour obtenir ce nombre d'IOPS. Toutes les IOPS supplémentaires nécessaires pour les pics périodiques doivent être couvertes par les performances en rafale sur la base des crédits disponibles.
Pour plus d'informations sur les méthodes d'estimation que vous pouvez utiliser pour déterminer les besoins en IOPS de votre base de données Oracle, reportez-vous au livre [blanc Déterminer les besoins en IOPS d'Oracle Database sur AWS](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html).
La durée de rafale d'un volume dépend de sa taille, des IOPS de rafale nécessaires et du solde de crédits au début de la rafale. Si vous remarquez que les performances de votre volume sont souvent limitées au niveau de base (en raison d'un solde I/O créditeur vide), vous devriez envisager d'utiliser un volume à usage général (SSD) plus important (avec un niveau de performance de base supérieur) ou de passer à un volume d'IOPS provisionnées (SSD) pour les charges de travail nécessitant des performances d'IOPS soutenues supérieures à 10 000 IOPS. Pour plus d'informations sur GP2 les volumes, consultez les [types de volumes Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html).
Pour Amazon RDS, le stockage à usage général (SSD) fournit une base de référence constante de 3 IOPS par Go provisionné et permet d'atteindre 3 000 IOPS en rafale. Si vous utilisez déjà le stockage magnétique pour Amazon RDS, vous pouvez le convertir en stockage à usage général (SSD), mais cela aura un impact sur la disponibilité à court terme. À l'aide des IOPS provisionnées, vous pouvez provisionner jusqu'à la limite de stockage maximale actuelle et jusqu'au maximum d'IOPS par instance de base de données.
Le nombre réel d'IOPS réalisé peut varier par rapport au montant que vous avez provisionné en fonction de la charge de travail de votre base de données, du type d'instance et du moteur de base de données. Pour plus d'informations, reportez-vous à la section [Facteurs influant sur les taux d'IOPS réalisés dans le guide de l'*utilisateur Amazon RDS.*](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)
Pour Oracle Database sur Amazon EC2, regroupez plusieurs volumes pour augmenter le nombre d'IOPS et augmenter la capacité. Vous pouvez utiliser plusieurs volumes Amazon EBS individuellement pour différents fichiers de données, mais le fait de les regrouper permet un meilleur équilibrage et une meilleure évolutivité.
Oracle Automatic Storage Management (ASM) peut être utilisé pour le striping. Conservez les fichiers de données, les fichiers journaux et les fichiers binaires sur des volumes Amazon EBS distincts, et prenez régulièrement des instantanés des volumes de fichiers journaux. Le choix d'un type d'instance avec stockage SSD local vous permet d'améliorer les performances de la base de données en utilisant Smart Flash Cache (si le système d'exploitation est Oracle Linux) et en utilisant le stockage local pour les fichiers temporaires et les espaces de table.
Pour Oracle Database on VMware Cloud on AWS, vSAN fournit le stockage virtualisé nécessaire réparti sur les hôtes bare metal. La capacité de stockage virtualisé vSAN peut être utilisée dans Oracle RAC pour un stockage partagé hautes performances.
Les fichiers VMDK (disque de machine virtuelle) créés pour Oracle RAC doivent être provisionnés pour une épaisseur nulle et le drapeau multi-écriture doit être activé. VMware a publié une [étude de performance détaillée](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf) pour les bases de données Oracle sur VMware Cloud on AWS.