Le Sat, 14 Aug 2010 09:35:14 +0200,
Cyril Bellot a écrit :
> Le bottleneck restait DRBD (les IO disques en l'occurence) et pas
> l'iSCSI. On pouvait monter à pleine capacité réseau quand ça générait
> peu d'IOs (pour des opérations sur des gros blocs par exemple)
Les I/O disques sur DBRD ou le
Le Sat, 14 Aug 2010 10:30:50 +0200,
Arnaud Launay a écrit :
> ainsi que sur le tcpoffload, ça m'intéresserait beaucoup,
J'ai oublié çà ...
En fait il arrive que sur les NICs qui font du TCP offloading on ait
soit des bugs (corruption des paquets TCP), soit des pbs de
performances. Il est par c
Hello,
Le 14 août 2010 à 10:39, Greg a écrit :
>
> Je ne suis pas d'accord, les candidats idéaux à de la virtualisation
> sont les deux extrèmes (serveur qui ne fout rien, serveur qui
> travaille beaucoup) car, justement, les moyens des uns font les moyens
> des autres et, ainsi, tu peux mutuali
Il est préférable d'avoir 10 petites machines indépendantes qui font leur
taff dans leur coin, qu'une grosse qui risque plus de planter. L'archi a
donc été concue (par mon prédécésseur) dans ce sens là. Quelques paires de
serveurs hôtes redondées, des serveurs virtuels par dessus.
Ca dépend vrai
Le 14/08/2010 13:23, Jérôme Nicolle a écrit :
Vous en connaissez des perles comme ça ?
Sur le sujet du mail, assez complet (ca a ete ma base pour mon premier
setup perso serieux) :
http://www.unixgarden.com/index.php/administration-systeme/mise-en-oeuvre-d%E2%80%99une-plate-forme-mail-av
Le Sat, 14 Aug 2010 10:30:50 +0200,
Arnaud Launay a écrit :
>
> Si tu as une doc sur le tuning de drdb, de ses cache, ainsi que
> sur le tcpoffload, ça m'intéresserait beaucoup, et je pense ne
> pas être le seul ici...
>
Tu as tjs la doc de linbit mais elle expose surtout les tunables
importa
Il est préférable d'avoir 10 petites machines indépendantes qui font leur
taff dans leur coin, qu'une grosse qui risque plus de planter. L'archi a
donc été concue (par mon prédécésseur) dans ce sens là. Quelques
paires de
serveurs hôtes redondées, des serveurs virtuels par dessus.
Ca dépend vr
Je tique un peu sur la possibilité de faire de la DB en virtualisé
(quand je parle de DB c'est pas pour le Spip de mémé) vu les temps d'accès.
La dernière fois qu'on en avait parlé, tu me disais que le temps d'accès
n'était plus un problème grâce aux nouvelles technos de ouf, que les
débits éta
On Sat, 14 Aug 2010 18:26:01 +0200, Benjamin Billon
wrote:
> Je tique un peu sur la possibilité de faire de la DB en virtualisé
> (quand je parle de DB c'est pas pour le Spip de mémé) vu les temps
d'accès.
> La dernière fois qu'on en avait parlé, tu me disais que le temps d'accès
> n'était plus
Le 14/08/10 12:52, eberkut a écrit :
>
> Le 14 août 2010 à 10:40, Greg a écrit :
>>>
>>> Ca pourrait être pas mal d'ajouter tout ça sur le site ouaib de FRsaG non ?
>>>
>>>
>> Sur le site, ou sur un site de bookmarks en ligne communautaire à la
>> Delicious, Google Bookmark, et co ?
>
> Et en par
Le 14 août 2010 à 10:40, Greg a écrit :
>>
>> Ca pourrait être pas mal d'ajouter tout ça sur le site ouaib de FRsaG non ?
>>
>>
> Sur le site, ou sur un site de bookmarks en ligne communautaire à la
> Delicious, Google Bookmark, et co ?
Et en parlant de delicious, il y a celui de GCU qui vaut
Le 14 août 2010 à 10:39, Greg a écrit :
>> Je ne suis pas d'accord, les candidats idéaux à de la virtualisation
>> sont les deux extrèmes (serveur qui ne fout rien, serveur qui
>> travaille beaucoup) car, justement, les moyens des uns font les moyens
>> des autres et, ainsi, tu peux mutualiser pl
>
> Ca pourrait être pas mal d'ajouter tout ça sur le site ouaib de FRsaG non ?
>
>
Sur le site, ou sur un site de bookmarks en ligne communautaire à la
Delicious, Google Bookmark, et co ?
--
Greg
___
FRsaG mailing list
FRsaG@frsag.org
http://www.frsag.
> Je ne suis pas d'accord, les candidats idéaux à de la virtualisation
> sont les deux extrèmes (serveur qui ne fout rien, serveur qui
> travaille beaucoup) car, justement, les moyens des uns font les moyens
> des autres et, ainsi, tu peux mutualiser plus avant tes serveurs.
>
>
Dans le second cas,
Le Sat, Aug 14, 2010 at 12:03:19AM +0200, Jerome Benoit a écrit:
> Sur un DRBD correctement tuné, le bottleneck n'est ni les PPS de
> ton réseau, ni les MIPS de ton CPU, c'est la bande passante de tes
> disques et/ou de ton contrôleur.
Si tu as une doc sur le tuning de drdb, de ses cache, ainsi qu
Le 14 août 2010 10:06, Pierre-Henry Muller a écrit :
>
> Je module un peu ta phrase, on ne virtualise pas de machine qui occupent 50%
> ou plus des ressources d'un serveur physique.
> Pour les base de données ca dépend encore de la charge, même avec de grosses
> bases si les ressources mem, io néc
Le 9 août 2010 à 20:52, Raphael Mazelier a écrit :
>
> Reste un conseil d'ordre général sur la virtualisation. La virtualisation
> c'est bien, mais pas pour tout, et il faut bien réfléchir a ce que l'on veut
> faire tourner dessus. (exemple débile : pas de bases de données :)
Je module un peu
On 14/08, Jerome Benoit wrote:
> Le Fri, 6 Aug 2010 19:47:49 +0200,
> Cyril Bellot a écrit :
> > Ici, nous avons tourné quelques temps sur une plate-forme similaire :
> > 2 machines en DRBD master/master offrant en partage iscsi des volumes
> > montés par des dom0 sur d'autres machines et faisant
18 matches
Mail list logo
