Architecture d'un déploiement OpenStack virtuel (Juju / MAAS) avec 1 nœud physique
Je voudrais montrer certaines des fonctionnalités OpenStacks HA/FT (surtout la migration en direct et la réplication de stockage). Pour cela, j'ai une machine avec 32 Go RAM et un Xeon e3v2 avec 4 cœurs (8 threads). Jusqu'à présent, j'ai réussi à faire fonctionner MAAS et Juju, mais Je ne suis pas sûr du nombre de nœuds virtuels que je peux déployer en toute sécurité (et du ratio de surcharge/CPU/RAM), bien que j'aie lu quelque part que le CPU physique peut gérer la surcharge avec 1-vcpu -machines assez bien).
Actuellement, le VM qui exécute MAAS utilise 1 vCPU et 8 Go de RAM, Juju fonctionne sur l'hôte. Cela me laisse avec 7 vCPU et 24 Go RAM sans surengagement de ressources. Ce que j'ai trouvé est le suivant:
1 nœud de contrôleur: 2vCPU, 4 Go RAM - RabbitMQ, mysql, keystone, tableau de bord, cinder, nova-cloud-controller et coup d'œil dans les conteneurs lxc
2 nœuds Ceph: 1 vCPU, 4 Go RAM chacun - ceph
2 nœuds de calcul: 2 vCPU, 8 Go RAM chacun - nova-compute
1 nœud de réseau: 1 vCPU, 2 Go RAM - passerelle quantique
Plus l'hôte MAAS: 1 processeur virtuel, 8 Go de RAM
Cela se traduirait par un total de 38 Go RAM et 10 vCPU, donc je suis un peu trop engagé.
Ma vraie question est de savoir si quelqu'un a une meilleure architecture en tête. J'ai vraiment l'intention de montrer quelques fonctionnalités d'OpenStack (ou des Clouds en général).
J'ai une configuration similaire et permettez-moi de suggérer à votre configuration:
- Réduisez la quantité de RAM affectée à MAAS, environ 2 Go suffiront.
- Ajoutez un autre nœud ceph, cela vous aidera à démontrer la résilience lorsque vous utilisez ceph et 1 nœud tombe en panne.
- La surcharge du processeur n'est pas si mauvaise, mais vous ne voulez pas surcharger en mémoire, car le système commencera à échanger et tout obtiendra des performances inutilisables.
- Quelque chose que vous ne mentionnez pas, ce sont les disques que vous avez, c'est un énorme goulot d'étranglement pour moi, j'ai 2 disques à 7200 tr/min avec btrfs (raid0), mais ce n'est pas suffisant pendant le déploiement du juju.
- Vous pouvez également utiliser juju-deployer et Tweak la ligne de commande que vous utilisez pour déployer, en particulier les modificateurs de temporisation et les "-s", qui est un délai entre chaque appel "juju deploy".
J'espère que ça aide.
Felipe,
Je vous suggère de le vider s'il fonctionne toujours et d'utiliser LXD. Vous ne devriez avoir aucun problème déployer ceci sans MaaS et juste exécuter Juju avec le contrôle local de votre LXD local comme décrit ici. Votre machine devrait être capable de l'exécuter sans trop transpirer . Si vous avez besoin de MaaS pour le démontrer (c'est vraiment génial. Vous devriez essayer de consulter les roadshows Openstack que Canonical fait si on vient à proximité ...) alors cela devient un peu plus compliqué.
Cette référence montre configuration sur 3 machines , mais vous pouvez devenir sournois et déployer Juju et MaaS sur la même autre machine si vous en avez vraiment besoin. Si votre deuxième machine exécutait MaaS et JuJu sous LXD avec le pont connecté à votre LAN de laboratoire et que votre trafic PXE pouvait passer, vous devriez pouvoir tout exécuter dans des conteneurs sur deux machines. J'essaie de faire quelque chose de similaire avec les machines virtuelles VMWare Fusion sur mon ordinateur portable où j'ai ponté le réseau interne vers un Thunderbolt NIC pour permettre aux machines MaaS et Juju d'orchestrer Raspberry Pi et NUC appareils.
Je n'ai pas d'expérience avec juju pour l'orchestration openstack, mais d'après l'expérience avec ceph et openstack, à des fins de démonstration, vous pouvez exécuter ceph sur des machines de 2 Go sans problème et je pense que l'hôte maas peut également être configuré avec 6 Go au lieu de 8.
Je ne sais pas si juju vous permet de combiner différents rôles dans la même machine virtuelle, dans nos déploiements (non juju), nous combinons le contrôleur et les rôles réseau sur le même VM (sans utiliser de conteneurs) ).
Lorsque vous utilisez des nœuds physiques dans un petit cluster, en particulier des éléments de type test-lab, un raccourci typique consiste à combiner les nœuds ceph avec vos nœuds de calcul. Voir cet ensemble de ceph-0.48-époque de instructions pour debian , ou ce plus moderne configuration de laboratoire pour proxmox VE .
En utilisant les chiffres que vous avez fournis et les suggestions de diminutions de RAM plus triple-céph dans les autres réponses, peut-être quelque chose comme ceci:
- 3vCpu + 8 Go == RabbitMQ/keystone/glance/etc + cephMon1/Osd1
- 2vCpu + 10 Go == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
- 2vCpu + 10gb == novaComp3/Net3 + cephMon3/Osd3
- 1vCpu + 2gb == novaQuantum4
- 1vCpu + 3gb == MAAS_Host5
Je travaille actuellement sur une configuration à un nœud de cette nature moi-même, mais j'ai moins RAM disponible, et seulement quatre disques à consacrer (cephOsd est meilleur avec plusieurs disques). Je ne peux pas confirmer la les chiffres ci-dessus fonctionneront pour vous avec des performances adéquates, n'ayant pas essayé ce schéma moi-même, mais l'idée de base de fusionner des nœuds quelque peu orthogonaux pour être parcimonieux avec vCpu & ram peut vous donner suffisamment de traction pour arriver où vous voulez aller.
p.s. Voir aussi les documents d'aide semi-officiels pour OpenStack dans un nœud physique avec une VM, plus le OpenStack plus pertinent sur un tutoriel de boîte dédiée, sur devstack.org