Pour obtenir une présentation d'AlloyDB Omni, consultez Présentation d'AlloyDB Omni.
Taille et capacité
La taille et la capacité ont un impact direct 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 semblables à 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 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 prévue au fil du temps.
Taux de transactions : déterminez le nombre de transactions par seconde (TPS) attendu, 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 avec plusieurs cœurs de processeur et évolue de manière linéaire, en fonction de la charge de travail. Toutefois, 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.
- Les gains potentiels dus à un changement de génération ou de plate-forme de processeur.
Mémoire : allouez suffisamment de RAM aux tampons partagés d'AlloyDB Omni pour la mise en cache des 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 par 8 Go de RAM par processeur virtuel.
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 de suffisamment d'espace de stockage pour votre volume de données, vos index, votre journal WAL (Write-Ahead Log), vos sauvegardes et votre croissance future.
IOPS : estimez les 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 un objectif IOPS spécifique.
Prérequis pour exécuter AlloyDB Omni
Avant d'exécuter AlloyDB Omni, assurez-vous de respecter les exigences matérielles et logicielles suivantes.
Configuration matérielle requise
La configuration système requise pour la pile de déploiement AlloyDB Omni inclut un nœud préconfiguré pour exécuter différents composants. Le nœud AlloyDB Omni doit disposer d'un disque de données associé configuré avec le système de fichiers ext4/xfs, d'une taille estimée à partir de la taille des données. Les caractéristiques de performances du stockage ont un impact sur les performances d'AlloyDB Omni.
| Nœud | Configuration matérielle minimale | Configuration matérielle recommandée |
|---|---|---|
| AlloyDB Omni |
|
|
- Nous vous recommandons d'utiliser un périphérique de stockage SSD (Solid-State Drive) dédié pour stocker vos données. Si vous utilisez un appareil physique à cet effet, nous vous recommandons de le connecter directement à la machine hôte.
Logiciels requis
| OS/Plate-forme | Logiciel minimal |
|---|---|
| Linux1 |
|
-
AlloyDB Omni suppose que le
policycoreutils-python-utilspackage est installé avant l'installation du package RPM AlloyDB Omni. Cela permet à AlloyDB Omni de configurer la règle SELinux qui autorise l'exécution du service de base de données AlloyDB Omni.
Types de stockage compatibles
AlloyDB Omni est compatible avec les systèmes de fichiers sur les volumes de stockage par 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 le stockage réservé aux instances AlloyDB Omni. En fonction des exigences définies par 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 à partir du même périphérique de disque.
Stockage NVMe local ou SAN
Le stockage NVMe (Non-Volatile Memory Express) local et le stockage SAN (Storage Area Network) offrent des avantages distincts. Le choix de la bonne solution dépend des exigences spécifiques de votre charge de travail, de votre budget et de vos besoins futurs en matière d'évolutivité.
Pour déterminer la meilleure option de stockage, tenez compte des points suivants :
- Pour donner la priorité aux performances absolues, choisissez NVMe local.
- Si vous avez besoin d'un stockage partagé à grande échelle, choisissez SAN.
- Si vous avez besoin d'équilibrer les performances et le partage, envisagez d'utiliser 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 (Solid-State Drive). Pour les applications qui nécessitent un accès rapide aux données, le stockage NVMe local offre les avantages suivants :
- Les disques 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 mettre à l'échelle le stockage NVMe local, vous devez ajouter des disques supplémentaires à des serveurs individuels. Toutefois, l'ajout de disques supplémentaires à des serveurs individuels entraîne une fragmentation des pools de stockage et des complexités de gestion potentielles. 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 serveurs doivent se protéger contre les défaillances de disque à l'aide d'un RAID (Redundant Array of Inexpensive Disks) matériel ou logiciel Redundant Array of Inexpensive Disks (RAID). Sinon, la défaillance d'un seul appareil NVMe entraînera une perte de données.
Stockage sur SAN
SAN est un réseau de stockage dédié qui connecte plusieurs serveurs à un pool partagé de périphériques de stockage, souvent des disques SSD ou un stockage NVMe centralisé. Bien que SAN ne soit pas aussi rapide que NVMe local, les SAN modernes, en particulier ceux qui utilisent NVMe over Fabrics, offrent toujours d'excellentes performances pour la plupart des charges de travail d'entreprise.
Les SAN sont hautement évolutifs. Pour ajouter de la capacité de stockage ou des performances, ajoutez de nouvelles baies de stockage ou mettez à niveau celles existantes. Les SAN offrent une redondance au niveau du stockage, ce qui protège contre les défaillances des supports de stockage.
Les SAN excellent dans le partage de données. Pour les environnements d'entreprise qui nécessitent une haute disponibilité, plusieurs serveurs peuvent accéder aux données stockées sur le SAN et les partager. En cas de défaillance d'un 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.