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 conteneur.
Pour en savoir plus sur AlloyDB Omni, consultez la présentation d'AlloyDB Omni.
Taille et capacité
La taille et la capacité ont un impact direct sur les performances, la fiabilité et l'efficacité 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 aux exigences 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 correspondant, 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.
Pour dimensionner un environnement AlloyDB Omni, procédez comme suit:
Définissez votre charge de travail.
Volume de données: estimez la quantité totale de données que vous allez stocker dans AlloyDB Omni. Tenez compte à la fois des données actuelles et de la croissance projetée au fil du temps.
Taux de transaction: déterminez le nombre de transactions par seconde (TPS) attendu, y compris les lectures, les écritures, les mises à jour et les suppressions.
Concurrency (concurrency) : 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.
CPU: AlloyDB Omni bénéficie de plusieurs cœurs de processeur qui évoluent de manière linéaire jusqu'à 64 cœurs. Toutefois, PostgreSQL Open Source ne bénéficie généralement pas de plus de 16 CPU virtuels. Tenez compte du nombre de cœurs en fonction des besoins de calcul et de simultanéité de votre charge de travail. Tenez compte des gains potentiels liés à 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 d'avoir suffisamment d'espace de stockage pour votre volume de données, vos index, votre journal d'écriture anticipée (WAL), vos sauvegardes et votre croissance future.
IOPS: estimez les opérations d'entrée/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 d'IOPS spécifique.
Conditions préalables 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 appareil 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.
Configuration logicielle requise
| OS/Plate-forme | Logiciels minimum | Logiciels recommandés |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni suppose que SELinux, lorsqu'il est présent, est configuré sur l'hôte pour autoriser l'exécution du conteneur, y compris l'accès au système de fichiers (ou que SELinux est défini sur "permissive").
Types de stockage compatibles
AlloyDB Omni prend en charge les systèmes de fichiers sur les volumes de stockage en 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 s'exécute. Pour les charges de travail d'entreprise, utilisez l'espace de 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 appareils de stockage dans une configuration singleton avec un seul appareil de disque pour chaque conteneur ou dans une configuration consolidée où plusieurs conteneurs lisent et écrivent à partir du même appareil de disque.
Stockage NVMe ou SAN local
Le stockage NVMe (Non-Volatile Memory Express) local et le stockage SAN (Storage Area Network) offrent des avantages distincts. Le choix de la solution appropriée dépend de vos exigences spécifiques en termes de charge de travail, de votre budget et de vos futurs besoins en é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 un SAN.
- Si vous devez équilibrer les performances et le partage, envisagez d'utiliser un SAN avec NVMe sur 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 qui nécessitent 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, vous devez ajouter des disques à des serveurs individuels. Toutefois, l'ajout de disques à 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 pannes 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 SAN
Un SAN est un réseau de stockage dédié qui connecte plusieurs serveurs à un pool partagé d'appareils de stockage, souvent des SSD ou un stockage NVMe centralisé. Bien que les SAN ne soient pas aussi rapides que les NVMe locaux, les SAN modernes, en particulier ceux qui utilisent NVMe sur Fabrics, offrent toujours d'excellentes performances pour la plupart des charges de travail d'entreprise.
Les SAN sont très évolutifs. Pour augmenter la capacité de stockage ou les performances, ajoutez des arrays de stockage ou mettez à niveau les existants. Les SAN fournissent de la redondance au niveau de la couche de stockage, ce qui permet de se protéger contre les défaillances des supports de stockage.
Les SAN excellent dans le partage de données. Dans 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.