Reprise du message précédent :
:troiz

bonjour,

Koin El Barbu

T'as poussé le jeunot des 40T à la dépression je crois

En même temps, 40T en LVM/DM, faut espérer pour lui que son RH ou la DRI de sa boite rince gratis au xanax.

Par curiosité, pourquoi ? LVM ça sait pas gérer des « grosses » capacités

Je tiens à préciser : LVM est une solution très pertinente en DAS sur des stations, qui apporte souplesse et performances relativement proches du bare metal, à la condition de pas dépasser quelques T en volumétrie. Là, on commence quand même à toucher à quelque chose d'assez gros, d'autant plus qu'il avait prévu des SSD (?) pour faire du tiered cache ou équivalent. Mais soyons sérieux, 40T sur des serveurs pour de la DB ?
 

 
Pour le détail : 2000iops/disque SAS à condition de pas prendre des disques avec beaucoup de plateau et avec un encodage 140/128 * 6 en lecture (agrégat de 6 grappes R1 en R0).
 
Il prend des 4T, se qui limite le type de disques disponibles a une poignée de référence, surtout chez fujitsu, à moins de passer par un intégrateur, de mémoire, HGST en 5 plateaux, qui n'ont pas les 2k iops (on est au mieux a 1200/1300 iops). En lecture continue on monte a 200-250m/secondes  par disques.
Je ne parle pas de l'écriture. Si il arrive à différer l'écriture, avec du tiered, il peut avoir la capacité maxi de ses disques qui lui serviront de cache, chose qui, vu sa solution est douteux. LVMcache étant pas conseillé en prod, et bcache est une plaie à mettre en place.
 
Rajouter le raid de bas niveau par dessus, les volumes MDraid faut vraiment avoir du matériel choisi pour ça, avoir batterie et gros cache pour la volumétrie demandée (4G sur la carte vue le volume de disques raw, soit faire un 1Gram/4Gcarte/400Gcache/40T)
 
Non définitivement pas sérieux du tout sans connaissance sur du LVM pour de la DB.

agree  

 
moi je ne fais pas de LVM sur les DB (ou autre, genre ES/Lucene), juste sur les parties système. et puis de toute façon pour les DB c'est fusionIO

Qu'elle est la limitation derrière le fait qu'en volumétrique de plus de quelques TiB c'est pas bon LVM ? Je veux dire, qu'est-ce qui explique ça

Je défend pas LVM hein, j'essaie de comprendre Perso je suis plus stockage fichier que block moi de toute façon (du point de vue de l'hyperviseur)

perso, les DB si j'ai pas de contraintes qui m'en empêche, j'aime bien les mettre sur du raw (quoiqu'il arrive, je teste a minima plusieurs solutions avant de me décider).
bon, les merdes d'oracle, je laisse ASM.

ah, et je suis allé vous apporter mon soutien plein et entier sur l'autre topic

 
Plus tu rajoute de couches, plus tu rajoute d'encodes, plus tu merde tes IO. Ca fait longtemps (10 ans+) que le volume de lecture n'est plus le problème pour les DB, mais les IO.
Donc, plus tu rajoute de couches, plus tu chie sur tes IO.
En natif les disques sont passés en 140/128 pour cette raison : au lieu d'avoir 20% d'overhead (10/8) t'en a 8%. Mais vient s'ajouter l'overhead PCI-E (140/128), donc pour passer une commande soit t'as du natif qui va passer directement une commande NVM ou sata/SAS au disque, soit faut passer une commande PCI-E en 140/128, la passer dans le buffer du contrôleur et en envoyer 2 en 140/128 aux disques = rajout d'une latence, et ça, ça peut être très très très aléatoire suivant le contrôleur et, en rajoutant LVM par dessus qui s'en bat littéralement les couilles de comment est fait l'archi sous-jacente tu peux avoir des comportements ultra funky en DB (allant de latences de l'ordre de la 100e de ms jusqu'à des commandes qui passent dans un ordre aléatoire sur une même seconde, suivant les flush des caches et, oh joie, comment les contrôleurs se permettent de réorganiser les commandes)
 
Vue sa volumétrie, c'pas du mariadb de papa qu'il va installer, stocker sa DB en mode FS c'est de la connerie sur du LVM. Raw avec un contrôleur à quelques milliers de brouzouf ou ZFS ou autre FS "bare". Micron automata, SQream, Netezza, Swarm64, BlazzingDB, Kinetica, Ryft pour ne citer que ceux là en cartes.
 
Sinon, et si la volumétrie est compatible parce que dépassé la barre des 10T de DB, la volumétrie et le TCO font que les cartes a quelques milliers de brouzouf deviennent rentable, c'est du full flash aray.
 
Les DB sont un domaine que nous n'avons jamais touché chez nous, trop chiant, trop touchy, trop de cas d'usages à prendre en compte.

 
épouse moi

 
Non.

c'est quand mème la réponse que j’espérais ...    

 
Et la tête ?
 

 
Toi tu as changé, t'as pas déjà demandé quelqu'un en épousaille ?    
 
 
Saluch !

 
elle va bien, j'ai pas exagéré non plus ...
 

sisi ...    

 
Et les petits LUN vous aez prévue de les faire les petit LUN ?    

ah non, ça serait déjà fait depuis longtemps si on avait voulu ça ... on se contente des petits de nos frères et sœurs respectifs de temps à autre ...

Bonsoir,

preums

Deu'z

troiz'

catz'  

bonjour,

Alors, les sous-nerdz on installe buntu 18.04 ?

t'as qu'a pas être pauv, achète toi un mac comme tout le monde

Bonsoir,

Latex + beamer  

Preum's

Preum's

fake !

Hop, dern's!

non

Preums

Deuz'

bonjour,