RabbitMQ sur Centos: HOW-TO partitionner 2xHDD et 2xSSD

Question

Je viens de recevoir un nouveau serveur et est destiné uniquement à la messagerie; sens qui aura installé RabbitMQ et Redis.

Le serveur a: HDD: 2 unités de disque dur, ~ 500 Go chacun SSD: 2 unités de disque à l'état solide, ~ 700GB chaque MEM: 256 Go de mémoire

j'ai lu que RabbitMQ présente de meilleures performances avec des disques SSD lorsque les applications ont un taux de publication élevé dans RabbitMQ, ce qui sera également le cas avec moi. Le script python du client RabbitMQ va également faire beaucoup de journalisation, de débogage, etc. Le serveur doit être réglé pour les performances. Le pire des cas est de recevoir une rafale de 700 Ko de messages JSON < 1min d'un producteur. Le nombre total de producteurs (de messages) est de 9.

Je voudrais partager mon plan sur la configuration des partitions, et vous demander des commentaires/améliorations à ce sujet.

1. Configurez les disques 2xSSD en tant que bande, RAID0. Appelons-le "sdisk00" avec ~ 1,5 To
2. Configurez les disques 2xHDD comme redondants, RAID1. Appelons-le "hdisk00" avec ~ 1TB.
3. Centos sera installé sur "sdisk00"
4. client Python qui traite les messages RabbitMQ résideront sur "sdisk00" bien sûr, mais écriront enregistre également sur "hdisk00"
5. "sdisk00" cloisonné:/boot = 1G (ext3), échange = 10G (échange),/= reste (ext4),
6. "hdisk00" partitionné:/home = 200G (ext4),/var = 300G (ext4),/usr = 500G (ext4)

qu'en pensez-vous?

Answer 1

Vous demandez des commentaires ou des améliorations, voici ce que je pense. Tout d'abord, j'utiliserais certainement un type de RAID pour éviter de perdre des données et aussi pour la redondance. Plutôt que d'installer RabbitMQ sur ces ressources dédiées exactement comme ça, j'utiliserais plutôt KVM ou n'importe quelle virtualisation à l'aise avec OU utiliser docker pour exécuter plusieurs instances de RabbitMQ. Cela vous permet d'avoir plusieurs serveurs fonctionnant tous sur une seule case, ce qui vous permet d'évoluer facilement et de diviser le trafic. J'étais fan d'avoir d'énormes ressources sur une seule boîte pour assurer de meilleures performances, mais avec le temps et la virtualisation s'améliorait, j'ai trouvé que cela permettrait de mieux partager vos ressources sur VM ou Docker.