Ce document explique comment vous préparer à exécuter AlloyDB Omni dans n'importe quel environnement Linux compatible avec les environnements d'exécution de conteneurs.
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 testé suffisamment 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 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.
CPU : AlloyDB Omni bénéficie des systèmes dotés de plusieurs cœurs de processeur et s'adapte 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.
- Tous les gains qui pourraient être présents en raison d'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 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 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 savoir 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 exigences 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 disque dur 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 | Logiciel minimum | Logiciels recommandés |
|---|---|---|
| Linux1 |
|
|
| macOS |
|
|
- AlloyDB Omni suppose que SELinux, lorsqu'il est présent, est configuré sur l'hôte pour permettre au conteneur de s'exécuter, y compris l'accès au système de fichiers (ou que SELinux est défini sur "permissive").
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 un 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 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 ou SAN local
Le stockage local Non-Volatile Memory Express (NVMe) et le stockage Storage Area Network (SAN) offrent des avantages distincts. Le choix de la solution appropriée dépend de vos besoins spécifiques en termes de charge de travail, de budget et d'évolutivité future.
Pour déterminer la meilleure option de stockage, tenez compte des points suivants :
- Pour privilégier les performances absolues, choisissez NVMe local.
- Si vous avez besoin d'un stockage partagé à grande échelle, choisissez SAN.
- Si vous devez équilibrer les performances et le partage, envisagez d'utiliser un réseau 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 ont besoin d'un accès rapide aux données, le stockage NVMe local offre les avantages suivants :
- Les SSD NVMe se connectent directement au bus Peripheral Component Interconnect Express (PCIe) 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 à des serveurs individuels. Toutefois, l'ajout de disques supplémentaires à 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 périphérique 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é 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 NVMe over 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 baies de stockage ou mettez à niveau celles existantes. Les SAN offrent une 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 sont excellents pour 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.