Ce document explique comment préparer l'exécution d'AlloyDB Omni dans n'importe quel environnement Linux compatible avec les environnements d'exécution de conteneurs.
Pour en savoir plus sur AlloyDB Omni, consultez la présentation d'AlloyDB Omni.
Taille et capacité
La taille et la capacité ont une incidence directe sur les performances, la fiabilité et la rentabilité de votre instance AlloyDB Omni. Lorsque vous migrez une base de données existante, les ressources de processeur et de mémoire requises sont similaires à celles du système de base de données source.
Prévoyez de commencer par un déploiement utilisant des ressources de processeur, de RAM et de disque correspondantes, et utilisez la configuration du système source comme configuration de référence d'AlloyDB Omni. Vous pourrez peut-être réduire votre consommation de ressources après avoir effectué suffisamment de tests sur votre instance AlloyDB Omni.
Le dimensionnement d'un environnement AlloyDB Omni comprend les étapes suivantes :
Définissez votre charge de travail.
Volume de données : estimez la quantité totale de données que vous stockerez dans AlloyDB Omni. Tenez compte des données actuelles et de la croissance projetée au fil du temps.
Taux de transactions : déterminez le nombre attendu de transactions par seconde (TPS), y compris les lectures, les écritures, les mises à jour et les suppressions.
Simultanéité : estimez le nombre d'utilisateurs ou de connexions simultanés accédant à la base de données.
Exigences de performances : définissez les temps de réponse acceptables pour différents types de requêtes et d'opérations.
Assurez-vous que votre matériel est compatible avec les exigences de dimensionnement.
Processeur : AlloyDB Omni bénéficie de systèmes dotés de plusieurs cœurs de processeur, et AlloyDB Omni évolue de manière linéaire, en fonction de la charge de travail. Cependant, PostgreSQL Open Source ne bénéficie généralement pas de plus de 16 processeurs virtuels. Tenez compte des points suivants :
- Le nombre de cœurs en fonction de la simultanéité de la charge de travail et des besoins de calcul.
- Tous les gains pouvant être présents en raison d'un changement de génération ou de plate-forme de processeur.
Mémoire : allouez suffisamment de RAM pour les tampons partagés d'AlloyDB Omni afin de mettre en cache les données et la mémoire de travail pour le traitement des requêtes. L'exigence exacte dépend de la charge de travail. Commencez avec 8 Go de RAM par vCPU.
Stockage
Type : en fonction de vos besoins, choisissez entre le stockage NVMe local pour les performances ou le stockage SAN pour l'évolutivité et le partage de données.
Capacité : assurez-vous de disposer d'un espace de stockage suffisant pour votre volume de données, vos index, votre journal WAL (Write-Ahead Log), vos sauvegardes et votre croissance future.
IOPS : estimez le nombre d'opérations d'entrée/de sortie par seconde (IOPS) requises en fonction des modèles de lecture et d'écriture de votre charge de travail. Lorsque vous exécutez AlloyDB Omni dans un cloud public, tenez compte des caractéristiques de performances de votre type de stockage pour déterminer si vous devez augmenter la capacité de stockage afin d'atteindre une cible d'IOPS spécifique.
Prérequis pour exécuter AlloyDB Omni
Avant d'exécuter AlloyDB Omni, assurez-vous de respecter les conditions matérielles et logicielles suivantes.
Configuration matérielle requise
| OS/Plate-forme | Configuration matérielle minimale | Matériel recommandé |
|---|---|---|
| Linux |
|
|
| macOS |
|
|
- Nous vous recommandons d'utiliser un périphérique de stockage SSD dédié pour stocker vos données. Si vous utilisez un appareil physique à cette fin, nous vous recommandons de le connecter directement à la machine hôte.
Logiciels requis
| OS/Plate-forme | Configuration logicielle minimale | Logiciels recommandés |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni suppose que SELinux, s'il est présent, est configuré sur l'hôte pour permettre l'exécution du conteneur, y compris l'accès au système de fichiers (ou que SELinux est défini sur "permissif").
Types de stockage compatibles
AlloyDB Omni est compatible avec les systèmes de fichiers sur les volumes de stockage de blocs dans les instances de base de données. Pour les systèmes de développement ou d'essai plus petits, utilisez le système de fichiers local de l'hôte sur lequel le conteneur est exécuté. Pour les charges de travail d'entreprise, utilisez un espace de stockage réservé aux instances AlloyDB Omni. En fonction des exigences de votre charge de travail de base de données, configurez vos périphériques de stockage dans une configuration singleton avec un périphérique de disque pour chaque conteneur, ou dans une configuration consolidée où plusieurs conteneurs lisent et écrivent sur le même périphérique de disque.
Stockage NVMe ou SAN local
Le stockage NVMe (Non-Volatile Memory Express) local et le stockage SAN (Storage Area Network) offrent tous deux des avantages distincts. Le choix de la solution appropriée dépend des exigences spécifiques de votre charge de travail, de votre budget et de vos besoins d'évolutivité futurs.
Pour déterminer la meilleure option de stockage, tenez compte des éléments suivants :
- Pour privilégier les performances absolues, choisissez NVMe local.
- Si vous avez besoin d'un stockage partagé à grande échelle, choisissez un SAN.
- Si vous devez trouver un équilibre entre performances et partage, envisagez d'utiliser un SAN avec NVMe over Fabrics pour un accès plus rapide.
Stockage NVMe local
NVMe est un protocole hautes performances conçu pour les disques SSD. Pour les applications nécessitant un accès rapide aux données, le stockage NVMe local offre les avantages suivants :
- Les SSD NVMe se connectent directement au bus PCIe (Peripheral Component Interconnect Express) pour offrir des vitesses de lecture et d'écriture rapides.
- Le stockage NVMe local offre la latence la plus faible.
- Le stockage NVMe local offre le débit le plus élevé.
Pour faire évoluer le stockage NVMe local, il faut ajouter des disques aux serveurs individuels. Cependant, l'ajout de disques à des serveurs individuels entraîne la fragmentation des pools de stockage et peut compliquer la gestion. Le stockage NVMe local n'est pas conçu pour le partage de données entre plusieurs serveurs. Étant donné que le stockage NVMe local est local, les administrateurs de serveur doivent se protéger contre les défaillances de disque à l'aide d'un RAID (Redundant Array of Inexpensive Disks) matériel ou logiciel. Sinon, la défaillance d'un seul appareil NVMe entraînera une perte de données.
Stockage sur SAN
Un SAN est un réseau de stockage dédié qui connecte plusieurs serveurs à un pool partagé de périphériques de stockage, souvent des SSD ou un stockage NVMe centralisé. Bien que le SAN ne soit pas aussi rapide que le NVMe local, les SAN modernes, en particulier ceux qui utilisent le NVMe over Fabrics, offrent toujours d'excellentes performances pour la plupart des charges de travail d'entreprise.
Les SAN sont hautement évolutifs. Pour augmenter la capacité de stockage ou les performances, ajoutez des baies de stockage ou mettez à niveau celles existantes. Les SAN assurent la redondance au niveau de la couche de stockage, ce qui protège contre les défaillances des supports de stockage.
Les SAN sont parfaits pour le partage de données. Pour les environnements d'entreprise nécessitant une haute disponibilité, plusieurs serveurs peuvent accéder aux données stockées sur le SAN et les partager. En cas de défaillance du serveur, vous pouvez présenter le stockage SAN à un autre serveur du centre de données, ce qui permet une récupération plus rapide.