[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Partitionnement d'un serveur web



Le jeu. 17 janv. 2019 23:44, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> Le 16/01/19 à 22:10, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :
>> Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour
>> la disponibilité. Si l'objectif est que le système continue à
>> fonctionner malgré la perte d'un disque, alors un swap sans redondance
>> ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si
>> l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1
>> ni pour le swap ni pour le reste.
>
> Je suis pas tout à fait d'accord, on peut vouloir du raid1 pour la sécurité
> des datas

Le RAID ne sert pas à ça. Ce n'est pas une sauvegarde.

Le miroring ne serait pas une sauvegarde ? J'avoue avoir du mal à comprendre. Qu'il ne remplace pas une sauvegarde externe, OK, mais à mon sens il minimise quand même pas mal la perte de donnée si seul un disque est détruit, et non toute la machine. 

> mais vouloir du swap aussi rapide que possible, quitte à risquer
> un crash système si un disque lâche pendant l'utilisation du swap.

Le RAID 0 n'est plus rapide que le RAID 1 qu'en écriture et en lecture
séquentielle. En lecture aléatoire, le RAID 1 utilise tous les disques
en parallèle. L'usage typique du swap fait-il plutôt des accès
séquentiels ou aléatoires ? Si l'utilisation le justifie, on peut
augmenter la vitesse en lecture séquentielle sans sacrifier la
redondance avec du RAID 10.

> Dans mes usages, quand ça commence à swapper ça sent mauvais, si c'est
> juste une surcharge passagère ça passe (un gros batch bien goinfre,
> plusieurs VMs qui consomment plus que leur moyenne simultanément mais pas
> trop longtemps), mais sinon ça part vite en vrille (effet domino, ça swap
> car le serveur arrive pas à fournir => les requêtes sont plus lentes =>
> elles s'empile davantage => le serveur arrive encore moins à fournir).
>
> C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
> les oomkill arrivent dès que ça sature sans attendre l'agonie du système
> (même si ça devrait jamais arriver, avec un dimensionnement correct en
> amont).

Avec deux inconvénients non négligeables : le système ne tolère pas les
surcharges passagères, et on ne choisit pas les processus à tuer, on
doit faire confiance à l'OOM killer.


Reply to: