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.fr...@goralski.fr> a écrit : > > On 08 Jul 2015, at 18:01, Pierre Bellemain <pierre.bellem...@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/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
