On 08 Jul 2015, at 18:01, Pierre Bellemain pierre.bellemain@enpc.fr wrote:
Salut,
Dans ma mission actuelle je dois mettre en place un outil de type syslog concentrator avec du Logstash / Elasticsearch et Kibana. Ma machine a été livré avec 1 seul disque vmware venant du san.
De mon expérience personnelle, j'ai toujours eu et ou fait des VM de prod avec au minimum 2 disques 1 pour le system et 1 pour les datas. Je le faisais ainsi ou bien le demandais et on me le fournissais sans aucune contrainte. Je poussais même le vice à demande disque lent pour le système (SATA) et du SAS pour les data (SSD pouvait être aussi demandé).
A mon sens, 2 partitions sont utiles dans le sens où si ton appli (aller, pour citer un exemple, un serveur de mail qui se fait spammer et qui spool) consomme tout l'espace disque, tu ne plante pas ton système, seulement ta partition et ton appli. Par contre, je ne sais pas si 2 disques sont vraiment indispensables, juste les partitions devraient suffire.
A la limite, si je vais plus loin dans le raisonnement, tu peux mettre 2 disques pour te faciliter la vie lors d'un redimensionnement. Mais tu peux résoudre cela en mettant du LVM.
J'ai comme contrainte les IO que les machines vont générés que le concentrateur va recevoir et stocker. Est-ce que certains d'entre vous ont des retours d'expérience qui ont amené à devoir splitter les disques afin d'augmenter les perfs ? Sachant que mon client ne fait pas de tiering pour les VM.
Je suis sur une archi de virtu (VMWare/Netapp en mode NAS-NFS) avec plus de 200 VM, et très sincèrement, je ne crois pas que ce soit utile de séparer le système des datas au niveau des perfs disque. A mon sens, le système ne consomme de base pas beaucoup d'IO, a la limite pour les logs... Et encore... Personnellement, j'applique comme suis: Si pas besoin de grosse perfs, ou ne consomme pas trop d'IO -> VM entière sur disques lents (SATA). Si besoin de grosse perfs ou consomme énormément d'IO (afin de ne pas exploser les perfs des disques SATA) -> VM entière sur disques rapides (SAS)
Dans job-1 on procédait ainsi : System sur SATA Data sur SAS si besoin de perf sinon SATA.
Car le stockage coûtait cher (emc) et on approchait le Po de stockage. Mes collègues sysadmin solaris avait pour habitude de demande sur SAS pour l'OS parce qu'il voulait pas se prendre la tete.
Le soucis c'est que je n'ai pas non plus la vue sur le nombre de controlleur FC qu'ils ont ni ethernet. Il est vrai que cela ne me regarde pas mais pour faire le design de l'archi je pense qu'ignorer sur quoi cela va tourner risque de me peter à la %$%$$%$% Et comme j'ai vu la tête du monitoring qui est fait j'ai peur...
On a auditd qui tourne et qui log un tas d'info, j'ai eu le cas ou un process faisait tellement d'opération qu'auditd bossait comme un dingue. La volumetrie de log était sympa et je pense que les IO sur ce disque aussi. Si mon systeme s'emballe pour x raison je ne souhaite pas que les IO du disque système pénalise les IO data.
Je me fait peut être un film catastrophe mais la centralisation des logs va devenir obligatoire et sensible. Le poc nous donnera quelques indicateurs et on avisera alors. Un petit ioburn sur les disques et les cartes réseaux nous donneras peut être tort/raison sur des points.
Affaire à suivre.
Merci à tous pour vos retour.
La centralisation des log devient de plu en plus important à mesure que le besoin de sécurité et la taille de l'Infra augmente
Cela vas de pair avec le monitoring, les ids et les siem
Cordialement Alexis Le 8 juil. 2015 7:06 PM, "Nicolas GORALSKI" nicolas+ml.frsag@goralski.fr a écrit :
On 08 Jul 2015, at 18:01, Pierre Bellemain pierre.bellemain@enpc.fr wrote:
Salut,
Dans ma mission actuelle je dois mettre en place un outil de type syslog concentrator avec du Logstash / Elasticsearch et Kibana. Ma machine a été livré avec 1 seul disque vmware venant du san.
De mon expérience personnelle, j'ai toujours eu et ou fait des VM de
prod
avec au minimum 2 disques 1 pour le system et 1 pour les datas. Je le faisais ainsi ou bien le demandais et on me le fournissais sans aucune contrainte. Je poussais même le vice à demande disque lent pour le système (SATA)
et du
SAS pour les data (SSD pouvait être aussi demandé).
A mon sens, 2 partitions sont utiles dans le sens où si ton appli
(aller, pour citer un exemple, un serveur de mail qui se fait spammer et qui spool) consomme tout l'espace disque, tu ne plante pas ton système, seulement ta partition et ton appli.
Par contre, je ne sais pas si 2 disques sont vraiment indispensables,
juste les partitions devraient suffire.
A la limite, si je vais plus loin dans le raisonnement, tu peux mettre 2
disques pour te faciliter la vie lors d'un redimensionnement. Mais tu peux résoudre cela en mettant du LVM.
J'ai comme contrainte les IO que les machines vont générés que le concentrateur va recevoir et stocker. Est-ce que certains d'entre vous ont des retours d'expérience qui ont
amené à
devoir splitter les disques afin d'augmenter les perfs ? Sachant que mon client ne fait pas de tiering pour les VM.
Je suis sur une archi de virtu (VMWare/Netapp en mode NAS-NFS) avec plus
de 200 VM, et très sincèrement, je ne crois pas que ce soit utile de séparer le système des datas au niveau des perfs disque. A mon sens, le système ne consomme de base pas beaucoup d'IO, a la limite pour les logs... Et encore...
Personnellement, j'applique comme suis: Si pas besoin de grosse perfs, ou ne consomme pas trop d'IO -> VM
entière sur disques lents (SATA).
Si besoin de grosse perfs ou consomme énormément d'IO (afin de ne pas
exploser les perfs des disques SATA) -> VM entière sur disques rapides (SAS)
Dans job-1 on procédait ainsi : System sur SATA Data sur SAS si besoin de perf sinon SATA.
Car le stockage coûtait cher (emc) et on approchait le Po de stockage. Mes collègues sysadmin solaris avait pour habitude de demande sur SAS pour l'OS parce qu'il voulait pas se prendre la tete.
Le soucis c'est que je n'ai pas non plus la vue sur le nombre de controlleur FC qu'ils ont ni ethernet. Il est vrai que cela ne me regarde pas mais pour faire le design de l'archi je pense qu'ignorer sur quoi cela va tourner risque de me peter à la %$%$$%$% Et comme j'ai vu la tête du monitoring qui est fait j'ai peur...
On a auditd qui tourne et qui log un tas d'info, j'ai eu le cas ou un process faisait tellement d'opération qu'auditd bossait comme un dingue. La volumetrie de log était sympa et je pense que les IO sur ce disque aussi. Si mon systeme s'emballe pour x raison je ne souhaite pas que les IO du disque système pénalise les IO data.
Je me fait peut être un film catastrophe mais la centralisation des logs va devenir obligatoire et sensible. Le poc nous donnera quelques indicateurs et on avisera alors. Un petit ioburn sur les disques et les cartes réseaux nous donneras peut être tort/raison sur des points.
Affaire à suivre.
Merci à tous pour vos retour. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Alexis Lameire -
Nicolas GORALSKI