Bonjour à tous,
Je dois installer rapidement un serveur sous Linux (Suse 10.1), et je ne sais pas trop comment partitionner efficacement les disques.
Je n'ai jamais utilisé de serveur à proprement parler (à part un serveur perso, mais tellement peu sollicité que ça ne compte pas ici), et d'habitude je me contente de séparer le /home, donc je suis un peu dans le flou sur ce coup-là.
J'ai posté sur Léa Linux, mais apparemment dans une rubrique peu visitée, et comme je dois choisir très vite, je me permet de faire un petit lien, au risque de me faire taper dessus :D :
http://lea-linux.org/pho/read/1/295806#debut
(Oui oui, je sais, c'est un peu la misère au niveau des disques...) ;-)
Merci d'avance pour vos suggestions :-)
Forum Linux.général Petit serveur interne sous Linux : partitionnement efficace et plus sûr ?
13
juin
2006
# liens
Posté par zeanmi . Évalué à 2.
norme :
http://www.pathname.com/fhs/pub/fhs-2.3.html
howto :
http://www.tldp.org/HOWTO/Filesystems-HOWTO.html
install debian :
http://www.debian.org/doc/manuals/reference/ch-install.fr.ht(...)
sécurisation :
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.(...)
[^] # Re: liens
Posté par Yohm . Évalué à 1.
Enfin merci pour les liens, je vais potasser ça un peu plus en détail et les mettre en bookmark, ça peut re-servir... ;-)
(j'ai mal aux yeux rien que d'y penser, toutefois) :D
Le guide Debian securing-debian-howto est pas mal (quoique des fois un peu vieux), je l'avais déjà téléchargé (pavé bien dense), mais j'y avais vraiment pas pensé sur ce coup-là. (trop axé partitions et suse-securing howto) ;-)
Un de mes problèmes, c'est que j'ai trouvé pas mal de sites qui étaient pas vraiment mis à jour, avec des données qui n'étaient en partie plus valables (genre problèmes de sécurité qui ont été corrigés depuis longtemps, tailles disques d'il y a 20 ans et avec bien moins de paquets à l'époque, ...), donc ça aide pas toujours...
Au niveau répartition sur les disques, vu que c'est un serveur, je suis aussi assez préoccupé par les performances : genre est-ce que ça ralentit le système de séparer /var et /usr de / sur une autre partition ou un autre disque, en disque maître ou esclave sur un même nappe, ce genre de choses ? Idem avec le swap ?
Vu que je dois utiliser les disques IDE plutôt que les vieux SCSI pour des raisons de fiabilité (on aura tout vu...), autant éviter les goulots d'étranglements au maximum.
Une idée à ce sujet ?
En tous cas, merci encore pour ton aide. ;-)
[^] # Re: liens
Posté par khan . Évalué à 1.
AU niveau des partitions, il est evident que si tu sépare sur different disque cela ira plus vite. La tete de chaque disque etant sur une zone propre.
Ensuite pour /var, il est FORTEMENT conseillé de justement ne pas le fusionner avec le reste du systeme. En effet, tes logs peuvent subitement devenir tres gros et risque de remplir ton systeme. La séparation de /var permet d'eviter ce genre de probleme, ou les logs ne peuvent plus s'ecrire mais tu conserve la main (fort lent, certes).
Pense a bien mettre en place tes logrotate sur cette partition.
Ton swap devrait etre physiquement sur la partie la plus rapide de ton DD, au centre. Si tu as l'opportunité de le mettre sur un autre disque, qui ne ferait que ca, c'est aussi l'ideal.
Khan
[^] # Re: liens
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Donc les repertoire ou il y a bcp d'acces notament en ecriture sont a séparer du reste.
Apres a toi de voir la finesse de separation.
[^] # Re: liens
Posté par Yohm . Évalué à 1.
Je pensais bien mettre /var sur une partition à part, mais la taille dépend de si je laisse les données mysql et les logs avec /var ou plus à part.
Par rapport au lien vers le guide d'install Debian, les partitions en ext2 c'est pour pouvoir utiliser des outils de récupération, pour les performances ou parce que l'ext3 existait pas encore !? :D
Pour l'histoire de logrotate, je connaissais que vaguement de nom, je vais étudier ça. :D
Donc pour l'instant, ça donne :
IDE 1
/boot ; 100Mo ; ext3
/ ; le reste ; reiser
/home ; 5 Go ; reiser
IDE 2
/var ; 30 Go ; reiser
/usr ; 5 Go ; reiser
/srv ; 5 Go ; reiser
SCSI 2
/var/log ; 10 Go ; reiser
swap ; 2 Go ; sw => swap ~ centre
/tmp ; 5 Go ; reiser
SCSI 1 (needs stability testing on a long run)
swap ; 5 Go ; sw
/something ; 30 Go ? ; somefs
Je ré-agencerais au besoin si les performances devenaient mauvaises.
Je vais maintenant m'occuper d'étudier plus en détail les options (read only, noexec, ...) et ACL pour ces partitions.
Dans un topic sur Léa Linux, je crois me rappeler qu'un gars avait conseillé de monter le /tmp avec noexec. Enfin ce genre de trucs, quoi. ;-)
Encore merci encore pour vos conseils, je vous tiens au courant. ;-)
[^] # Re: liens
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Est ce que cela vaut le coup de faire un raid quelqu'onque pour la securité du systeme, des données?
Tu fait ou tes sauvegardes?
Moi je verais bien ca (c'est sans raison particuliere pour les FS, c'est juste ce que j'utilise)
IDE 1
/boot ; 100Mo ; ext2
/ ; le reste ; ext3
/home ; 5 Go ; ext3
IDE 2
/var ; 10 Go ; ext3
/usr ; 10 Go ; ext3
/tmp ; 5 Go ; ext3
SCSI 2
/var/lib/mysql ; 10 Go ; ext3
swap ; 2 Go ; sw => swap ~ centre
/srv ; 5 Go ; ext3
SCSI 1 (needs stability testing on a long run)
swap ; 5 Go ; sw
/var/lib/mysql ; 10 Go ; ext3
/srv ; 5 Go ; ext3
Avec donc un mirroir logique pour contituer /var/lib/mysql et un autre pour /srv
A la limite je degagerais bien les swap sur les ide sachant que normalement faut pas que la machine swap de toute maniere.
[^] # Re: liens
Posté par Yohm . Évalué à 1.
Mais mon gros problème est que pour l'instant, je fais moyennement confiance au SCSI (pas tout frais, et pas les moyens d'acheter d'autres disques SCSI, sinon j'aurais mis les db et le www sur des disques en RAID matériel)
Le SCSI 1 a des fois fait des reset ou arrêté de fonctionner, rarement, mais j'ai pas assez confiance pour y mettre des données importantes, même en RAID. ;-)
L'avantage du swap sur les SCSI, c'est que les accès disques sont bien plus rapides. Car avec 512MB de RAM, un site intranet, les db et un serveur X et KDE (oui, je sais, c'est un serveur, mais vnc et d'autres softs sont plus pratiques en graphique), ça m'étonnerait beaucoup que le serveur ne swap pas des fois. ;-)
Pour le /usr, j'ai regardé sur 2 PC, et j'ai 2,8 Go max, c'est pour ça que j'ai réduit de 10 à 5 Go.
Dans le /var, j'utilise surtout les logs et les db. Qui plus est, IDE2 est un 40 Go, donc j'utilise la place au maximum. ;-)
Pour le moment, j'ai séparé /var/log, car ça génère des accès fréquents aussi, et en production, ça peut vite prendre de la place, donc vu que j'ai du rab sur le 17Go (SCSI 2), c'est pour ça que je l'ai séparé du var, tout en gardant plein de place pour les bases de données. ;-)
Au pire, je taillerais encore dans le /var pour retirer ce qui prend beaucoup d'accès disques.
A la limite, est-ce que je peux avoir :
IDE 2
/var ; 30 Go
SCSI 2
/var/lib/mysql ; ? Go
Avec un RAID logique sur les db ? Bien que ça doit être crados au niveau perfs entre un IDE et un SCSI + RAID logiciel !?
En fait, à terme, on devrait acheter une carte contrôleur RAID S-ATA et on migrera les données dessus. Au niveau sauvegardes, je suis pas encore sûr. A priori, une copie sur le serveur de fichiers (tar, cron, cpio, images, dumps sql, ... je vais tester, je connais pas bien), pas sur un des disques du serveur, ou du moins pas uniquement.
Pour le choix du reiser, c'est ce que Yast met par défaut, je lui fait confiance pour ça. ;-)
Et de toutes façons les outils de récupération marchent pas tellement avec l'ext3 non plus, et au niveau journalisation, le reiser est sensé être plutôt optimisé d'après un des liens ci-dessus.
Au niveau compatibilité avec les livecd, ça ne semble pas poser pb (sur la 9.3).
[^] # Re: liens
Posté par Yohm . Évalué à 1.
J'hésite encore un peu entre le reiser de Suse et l'ext3 mieux configuré.
Car j'ai déjà eu des problèmes de récupération de données avec les 2 (ext3 et Fedora 2, reiser et Suse 9.3), mais j'avais jamais touché à la journalisation par défaut. Du coup les coupures de courant et les crashs avec reboot brutal, mes distribs avaient avaient pas aimé...
Apparemment pour éviter ce genre de désagrément, il vaut mieux, avec l'ext3, activer le dir_index et le journal en data=ordered ou journal. (et data=journal avec le reiserfs)
Apparement, l'ext3 serait plus pratique à récupérer en cas de crash majeur !? (fsck vs resiserfscheck (ou un truc du genre), montage en ext2 possible si le journal déconne (est-ce que ça arrive vraiment si souvent ?), meilleure compatibilité entre distribs, ...)
Une possibilité est de mettre certaines partitions en reiser (avec beaucoup de petits fichiers), d'autres en ext3 (ceux qui contiennent les données critiques) ? Plus que 2 fs serait un gâchis de modules chargés...
Au niveau journalisation, je pense donc mettre en mode "journal" au lieu de "ordered", pour la sécurité des données en cas de crash, surtout pour les partitions sensibles : /var, /srv, / et /home ? Pour /usr, est-ce vraiment la peine ? Un logiciel, au pire ça se réinstalle... :-D
Au niveau performances, ça risque de craindre, par contre...
Pour l'ext3, le mode ordered suffit soit-disant (http://lwn.net/2001/0802/a/ext3-modes.php3), mais bon, en pratique ça n'a pas toujours très bien marché...
[^] # Re: liens
Posté par Yohm . Évalué à 1.
Tout d'abord, quelques liens supplémentaires :
http://www.gentoo.org/doc/fr/security/shb-mounting.xml?glang(...)
http://www.gentoo.fr/install/configuration-systeme.htm
http://www.futuremark.com/forum/showthread.php?t=6283 (about which fs for which partition)
http://clx.anet.fr/spip/article.php?id_article=32
Donc ça donne :
[option] = option qui sera testée après installation
IDE 1 ("20Go")
/boot ; ~100 Mo (12 cyl) ; ext3 ; [noauto], noatime [?] 2 ; data=ordered
J'aurais pu utiliser ext2, mais je ne sais pas si cela nécessite un module à charger en plus, et puis bon, j'en suis pas non plus à quelques ms près.
Pour noauto, Suse me sort un message d'avertissement quand je l'active, donc je testerai ça plus tard, si ça vaut vraiment le coup.
Au niveau du dump, je sais pas encore.
/home ; 5 Go ; reiser ; noatime, notail, nodev [?] 0 ; data=ordered
En général petits fichiers, données pas critiques au point d'avoir besoin d'être journalisées en mode data=journal.
swap ; 1.5 Go ; swap ; priority = 1
Histoire d'avoir un swap ailleurs que sur les SCSI, vu que j'ai reçu la recommendation de ne rien y mettre d'important voire rien du tout...
/ ; l'espace restant (12 Go) ; reiser ; [noatime], [notail] [?] 1 ; data=journal
Les options noatime et notail devraient compenser un peu la baisse de performances du mode data=journal au lieu de ordered ?
Apparement, il vaut mieux que je ne mettre rien d'important sur les SCSI, qui sont apparemment très vieux (dommage, ça fait de la place et des gains en vitesse en moins).
Du coup, l'IDE 2 va être plus chargé (le disque le plus récent et avec la plus grande capacité)
IDE 2 ("40 Go")
/tmp ; 5 Go ; reiser ; [noatime, nodev, nosuid, noexec] 0 0 ; data=ordered
Apparemment, le noexec peut être utile pour des raisons de sécurité, mais peut empêcher des scripts de fonctionner, à tester...
/usr ; 5 Go ; reiser ; [notail, noatime, nodev, ro] 0 0 ; data=ordered|journal ?
Faut que je trouve plus d'infos sur les récupérations en ordered et journal. Est-ce qu'il y a un risque de corruption des données même sans accès en écriture avec reiserfs ?
/srv ; 5 Go ; reiser ; [params ?] [dump?] [fsck?] ; data=journal ?
data=journal pour éviter de perdre l'intranet en cas de coupure de courant ?
/var ; 25 Go ; ext3/reiserfs ? ; ? [?] [?] ; data=journal
Vu que les bases des données et les logs sont dessus, autant limiter les risques.
Pour ce qui est d'ext3 ou de reiser, je doute que les écarts de performances soient si énormes, y'a un peu de tout au niveau tailles.
Quant au temps de montage, c'est dérisoire sur de si petites capacités.
J'aurais tendance à dire quand même ext3 avec le dir_index...
J'aurais bien été tenté de mettre un /var/log distinct, mais cela nécessiterait une partition étendue.
Au pire, sur le SCSI 2...
/var/log ; 5 Go ; ext3 ; [noatime, ?] [?] [?] ; data=ordered ?
J'ai pas encore grande idée sur les options, mais ça doit pouvoir attendre un peu... !?
SCSI 2 (17 Go)
On verra...
SCSI 1 (34 Go)
On verra...
Au niveau sauvegarde, je vais essayer sans le RAID logiciel pour commencer. Des sauvegardes régulières devraient suffir.
Encore merci aux personnes qui ont pris le temps de m'aider. ;-)
[^] # Re: liens
Posté par zeanmi . Évalué à 1.
[^] # Re: liens
Posté par Yohm . Évalué à 1.
Tes liens m'ont pas mal servi aussi. ;-)
Ce qui est "marrant", c'est qu'au bout du compte (j'en ai eu un peu marre de tourner en rond), j'ai quasiment tout mis en Reiserfs avec données journalisées, car : je suis pas fan des mix de données entre fichiers, et l'optimization ext3, vu que je sais pas faire et que j'ai plus le temps, ça attendra encore un peu.
On verra pour les performances ce que ça donnera...
Par contre, avec le Reiserfs, je ne pourrai apparemment pas faire de grep sur les fichiers de périphériques en cas de bavure. :-D
Pour les histoires de journalisation et les options genre noatime et compagnie, soit j'ai mal/pas assez cherché, soit au niveau doc c'est très épars... Dommage, c'est plutôt important comme sujet...
[^] # Re: liens
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[^] # Re: liens
Posté par Yohm . Évalué à 1.
http://lists.debian.org/debian-user-french/2006/01/msg00241.(...)
http://zgp.org/linux-elitists/20010329123619.A12565@zgp.org.(...)
http://assistance.dedibox.fr/nntp/article.php?id=457&gro(...)
http://www.hesit.be/lamp/html/c253.html
http://www.cyberciti.biz/nixcraft/vivek/blogger/2005/10/impo(...)
# les tailles des partions n'ont aucune importances !!!
Posté par Fulup !GizKoz . Évalué à 1.
1) vous ne comprenez rien, dans ce cas vous laissez faire l'utilitaire d'install. SuSE est si simple a installer que meme une belle mère y arriverais. Par defautl il va tout mettre dans la meme partition.
2) vous etes un pro et vous voulez voir claire dans vos installs. Pour cela le plus simple est d'utiliser LVM qui vous permet de changer la taille de vos partitions par la suite en fonction de vos besoins.
Pour une Install avec LVM, c'est tres simple en dans le cas de SuSE entierement integré au system. Sauf cas particulier je ne conseille a personne de mettre "/" et/ou "/usr" dans un LVM, en cas demarage en single user ca complique pas mal la tache et pour le disque rescue c'est encore pire.
Si pour installer un LVM. Au moment de l'install
1) dans le menu partition de SuSE
- faire une partition "/" (5 Giga c'est assez, 7G c'est kool)
- faire un swap (depends de vos applis, disons entre 1/2 et 1G)
- mettre tout le reste du disque en LVM et ne pas le partitionner.
2) cliquer sur LVM
- ajouter la partition LVM dans le pool
- creer des partitions dans le pool en general en leur donnant des petites
taille /var, /opt, /usr/src, /home, ....
Quand une partition est trop petite, par example "/var" deborde, vous allez dans YaST, et vous agrandissez la partition, le tout online sans meme avoir a rebouter. A noter que sur les serveurs c'est une bonne idée d'avoir un /var/log dans une partition separée.
Si joint le "df -h" d'une de mes machine en SuSE 10.1
> Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
> /dev/sda1 6,6G 3,6G 3,0G 54% /
> /dev/mapper/skouarn--sata-skouarn--space
> 100G 32G 69G 32% /export/space
>/dev/mapper/skouarn--sata-skouarn--src
> 2,0G 33M 2,0G 2% /usr/src
>/dev/mapper/skouarn--sata-skouarn--var
> 1,0G 315M 710M 31% /var
[^] # Re: les tailles des partitions n'ont aucune importance !!!
Posté par Yohm . Évalué à 1.
En ce qui concerne le partitionneur auto, je ne connais certes pas tout, mais il me fait que de la m... avec le matériel dispo, et ça j'en suis sûr. ;-)
En tous cas, merci pour tes précisions sur LVM.
En fait, je ne l'ai jamais utilisé,et je ne sais pas à quel point cela complique effectivement la récupération de la partition et des données en cas de crash par exemple.
/var/log en LVM ne servirait donc pas à grand chose non plus si LVM flanchait d'une façon ou d'une autre, et pour les bases de données, je ne fais pas confiance pour les mêmes raisons.
Et qui plus est, tout comme le RAID logiciel, cela doit rajouter une couche de gestion logicielle, donc ralentir le tout, et vu que la machine n'est pas une foudre de guerre, est-ce que cela en vaut la peine...
M'enfin c'est vrai que le redimensionnement en direct est intéressant...
Ce sera probablement pour une autre fois. ;-)
En fait, en ce moment je suis surtout préoccupé par le dépannage de la machine... ;-) (crash matériel, logiciel ou les deux !?)
[^] # Re: les tailles des partions n'ont aucune importances !!!
Posté par Yohm . Évalué à 1.
La suse 10.1 est trop instable sur cette machine, je suis passé à Ubuntu server, et j'ai suivi tes conseils pour LVM.
Pour le moment, aucun problème.
Merci encore pour m'avoir aidé à franchir le pas. ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.