Formation DevOps | Formation AWS Services : 9- Service RDS

www.itgalaxy.io

Introduction à Amazon Relational Database Service (RDS)
  • Bases de données relationnelles « as a service »
  • SLA 99,95 %
  • Capacitéextensible
  • Produits disponibles : MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Aurora

Introduction

  • Capacité extensible
    » Upgrade des instances (élasticité verticale)
    » Ajout d’instance (élasticité horizontale)
    ○ Read replicas (MySQL, MariaDB,PostgreSQL)

  • Facturation à l’utilisation
    » Attention : pas de stop / start
    » Une DB Instance est facturée pendant toute ladurée de son existence (jusqu’auterminate)

RDS : partage des responsabilités

  • Ce qui est géré par AWS
    » Déploiement des instances
    » Paramétrage en standalone ou en clusterMulti-AZs
    » Sauvegardes
    » Correctifs logiciels
    » Détection des pannes
    » Reprise automatique

  • Pas d’accès shell à l’OS sous-jacent

  • Certaines tables ou procédures stockées sont à accès restreints

  • Ce qui est géré par l’utilisateur
    » User / password d’accès à la BDD
    ○ spécifié par l’utilisateur à la création del’instance
    » Création du schéma
    » Gestion des permissions et comptesutilisateurs
    » Variables d’environnement BDD (max sessions, etc.)
    » Définition de la stratégie desauvegarde
    » Définition des fenêtre demaintenance

  • Accès distant sur le port applicatif (MySQL 3306, Oracle 1521, etc.)

DB Instances vs EC2 Instances

  • Similaires aux instances EC2
    » Coûts et caractéristiquesdifférentes
    » Dépend du type d’instance et du moteur deBDD
  • Dédiées à un seul moteur et version de BDD
  • De 5GB à 6 TB de stockage
  • Différentes classes de stockages (EBS)

DB Instances et sous-réseaux

  • Sélectionner un ou plusieurs sous-réseaux dans
    lesquels déployer les DB instances

  • Subnet group : définition d’un ensemble de sous- réseau
    (template)
    » Subnet group pour les DB instances qu’on doitexposer
    sur Internet, un autre pour les DB Instances de back- end

DB Instances et AZs

  • 2 modes de déploiement
    » SingleAZ
    ○ Une instance dans unsous-réseau
    » Multi-AZ
    ○ Plusieurs instances déployées dans des sous-réseaux appartenant à des AZs
    distinctes
    ○ Réduit le risque de coupure deservice
    » Possibilité de migrer une DB Instance Single-AZ vers un cluster multi-AZ

  • Haute-disponibilité et reprise sur incident

  • Principe : maintenir une instance en stand-by sur une autre AZ,
    synchronisée avec l’instance primaire
    » Différent d’un Read Replica qui peut êtreactif

  • Synchronisation entre les nœuds : technologies AWS sauf pour SQL
    Server (Mirroring)

DB Instances : Multi-AZ

  • En cas de panne
    » Le FQDN du « primary endpoint » est modifié pour pointer vers l’instance de
    standby
    ○ Réalisé parAWS
    » Bascule entre 60 et 120 secondes
    » Eventuellement rafraîchir le cache côté client (Java)
  • La bascule peut se produire également en cas de maintenance

DB Instances : Multi-AZ

  • Impact possible sur les performances en écriture et latence (du fait de la
    synchronisation)
    » En production chargée, prévoir des instanceslarges
    avec stockage typeio1
  • Licences en mode BYOL (Oracle, SQL Serveur) à provisionner pour toutes
    les instances (standby y compris)

Sécurité : chiffrement

  • Chiffrement des communications applicatives
    » Certificat SSL précisé lors de la création de l’instance
    » Utilisation de la clé privée pour se connecter sur le port
    applicatif
  • Chiffrement du stockage en AES- 256
    » Utilisation de KMS
    » Mêmes limitations que pour le chiffrementEBS

Sécurité : filtrage

  • Opérations sur les ressources RDS
    » Permissions IAM : filtrage des requêtes APIs de manipulation des DB
    Instances
    ○ $ aws rds …
  • Accès en TCP/IP : 3 types de security groups
    » Security Group : uniquement pour les DB instances qui ne sont pas dans un VPC
    (EC2-Classic)
    » VPC Security Group : DB instance dans un VPC
    » EC2 Security Group : security group d’une instance EC2, utilisable également
    pour une DBinstance

Sécurité

  • Exemple : accès à une instance RDS depuis un
    serveur frontal

DB Instances : sauvegardes

  • 2 méthodes
    » Backups automatiques
    » Snapshots à la demande

DB Instances : Backups automatiques

  • Réalisés par AWS
  • S’exécute une fois par jour pendant la fenêtrede backup (à définir par le client)
  • Rétention entre 1 et 35 jours
  • Pas de coupure de service
  • Conserve les « change log »
    » Possibilité de restaurer à une date et heureprécise

DB Instances : Snapshots

  • S’exécute à la demande par le client (API)
    » $ aws rds create-snapshot…
  • Est proposé systématiquement à chaque suppression d’une DB
    Instance

DB Instances : paramètres moteurs BDD

  • DB Parameter Group
    » Configuration du moteur de BDD
    ○ Variables d’exécution du moteur (max sessions,etc.)
    » S’applique sur un même type de DBinstance
    ○ Par exemple un même DB Parameter Group pour toutes les instances Oracle avec la
    même version dumoteur
  • DB Option Group
    » Gestion des options des moteurs de BDD spécifique à certains moteurs
    ○ Oracle, MySQL, SQLServer

DB Instances : maintenance

  • AWS applique les patches OS et BDD
    » Possibilité de désactiver les mises à niveau du moteur deBDD

  • Fenêtre de maintenance à définir par le client

  • Maintenance Status : état des actions de maintenance
    » Visible dans la consoleRDS

Monitoring

  • DB Instance status : état de l’instance
    » Available, backing-up, creating, deleting, failed, maintenance, rebooting,
    renaming, restore-error, storage-full, upgrading, incompatible-parameter, etc.

  • DB Event subscriptions
    » Notification SNS d’événements (failover, backup, stockage saturé,…)
    » Events visualisables depuis la consoleRDS

  • +20 métriques CloudWatch
    » ReplicaLag, BinLogDiskUsage, CPU*, DatabaseConnections, IOPS, Network,
    Throughput,

  • Enhanced monitoring
    » Métriques collectées par un agent sur l’OS
    » Plusieurs dizaines de métriques
    ○ maxFiles, CPU load average, mémoire, process list, etc.
    » Métriques visualisables depuis la consoleRDS

  • Log files
    » Téléchargeables et visualisables depuis la consoleRDS

Bonnes pratiques

✓ Monitorer la mémoire, CPU et stockage
✓ Ne pas attendre la saturation pour upgrader
✓ Activer le backup automatisé et sélectionner une fenêtre avec faible trafic en écritures I/O
✓ Attention au cache DNS côté client en cas de bascule du cluster sur un autre nœud
✓ Multi-AZ & environnement de production : utiliser le stockage io1
✓ Tagger les DB instances





Decouvrez plus d’Offres de la plateform ItGalaxy.io :

Découvrez notre gamme complète de services et formations pour accélérer votre carrière.

1. Nous contactez

  • Description: Besoin de Formation et des Solutions cloud complètes pour vos applications
  • Links:

2. Infra as a Service

  • Description: Infrastructure cloud évolutive et sécurisée
  • Links:

3. Projets Développeurs

4. Développeurs

5. Formations Complètes

6. Marketplace

7. Blogs

This website is powered by ItGalaxy.io