C: \ est pour OS, D: \ est pour Data?

"Back in the day", nous avons toujours séparé nos lecteurs de système d'exploitation (sous Windows) de nos lecteurs de données. Dans le monde Linux, bien que je le connaisse beaucoup moins, je suis conscient que la sagesse dicte encore plus de volumes définis et utilisés dans une configuration conforme aux meilleures pratiques.

Maintenant que le stockage sur serveur est tout aussi susceptible d'être sur un SAN (où les ressources de disque sont partagées par de nombreux systèmes d'exploitation et applications individuels), est-il vraiment plus important que les partitions OS et Data soient séparées au niveau du volume?

Quelles sont vos pensées?

Il existe trois principaux pilotes pour conserver le système d'exploitation et les données séparés en termes de stockage.

1. L'espace . Comme le souligne ErikA, vous ne voulez vraiment PAS vraiment que votre volume de système d'exploitation manque d'espace. Toutes sortes de mauvaises choses peuvent arriver. Séparer ces deux méthodes de croissance
2. I / O Exigences d' accès . Le type d'E / S utilisé sur votre volume de système d'exploitation est généralement très différent de celui utilisé par vos volumes de données. Garder vos types d'E / S séparés est une très bonne idée à plusieurs niveaux.
3. Portabilité du stockage . Lorsque vient le temps de mettre à niveau le système d'exploitation de votre serveur, vous pouvez supprimer le volume du système d'exploitation et conserver toutes les données. Ou dans les environnements SAN ou VM, vous pouvez simplement déplacer le volume de données vers un nouveau serveur fraîchement installé et gagner du temps sur les mises à niveau.

De plus, certains systèmes d'exploitation (Windows en fait partie) ne prennent pas trop de bonté pour redimensionner le volume du système d'exploitation, ce qui signifie que vous devez généralement en donner autant qu'il en aura besoin au cours de sa vie lorsque vous formatez le serveur. Comparez cela aux volumes de données qui peuvent et sont fréquemment redimensionnés plusieurs fois au cours de la durée de vie d'un serveur. Même dans des environnements entièrement virtualisés où le système d'exploitation et les volumes de données eux-mêmes sont hébergés dans le même stockage réel, ne pas pouvoir redimensionner le volume de votre système d'exploitation peut être un handicap majeur. Windows 2008+ recommande maintenant 30 Go pour le lecteur C: \ ces jours-ci, loin des 10 Go que nous utilisions sur Server 2003; c'est quelque chose qui clouera de nombreux administrateurs Windows lors de la conversion de 2003 à 2008.

Oui, séparez certainement le système d'exploitation des données. Je l'ai vu maintes et maintes fois où, avec une partition partagée, la partition finit par se remplir et rend impossible de patcher le système d'exploitation, impossible d'étendre la partition (pour diverses raisons), etc.

OMI, la surcharge de gestion de deux partitions est un petit prix à payer pour l'isolement fourni.

En ce qui concerne les systèmes soutenus par le SAN que vous avez mentionnés, cela ne vous protégera toujours pas contre le remplissage des données de votre partition OS. Avec un stockage entièrement virtualisé, vous n'avez pas à vous soucier autant de garantir que le système d'exploitation et les données vivent sur des broches distinctes.

Je dirais que cela dépend de ce que vous faites avec le système. Si vous devez réinstaller le système d'exploitation, vous pouvez vous épargner quelques tracas en plaçant toutes vos données sur une partition distincte. Sinon, je ne vois plus la nécessité. Mes deux centimes.

En principe, je pense que séparer l'espace du système d'exploitation par défaut (comme C :) des données (D :) est une bonne idée, mais je recommanderais également de créer une plus petite partition pour les fichiers journaux (L :) pour les garder un peu plus sûr et empêcher certains types d'attaques par déni de service.

Linux est très agréable en ce que le système de fichiers reste hiérarchiquement sous un répertoire racine quel que soit le nombre de disques physiques ou de partitions virtuelles que vous utilisez. Je partitionnerais certainement le disque, mais pas nécessairement pour la séparation des données par rapport au système d'exploitation (car très souvent, les deux se mélangent de toute façon).

Je regarderais:

1. Quels sous-répertoires sont susceptibles de remplir leur disque et de provoquer des problèmes d'espace pour d'autres répertoires (par exemple partition hors / home et / var / log par exemple).
2. Si différentes parties de votre structure de répertoires ont besoin de différents systèmes de fichiers pour des raisons de performances (par exemple XFS pour la stabilité, Ext3 pour une utilisation polyvalente, etc.)
3. Quels répertoires pourraient devoir être développés à l'avenir - ce sont de bons candidats pour le partitionnement car vous pouvez simplement renommer le répertoire, partitionner et monter un nouvel ensemble d'espace disque à l'emplacement du répertoire et copier les données de l'ancien vers le nouveau emplacement.

Les recommandations historiques de partitionnement de Linux (enfin, Unix vraiment) sont en partie dues à ses origines en tant que système d'exploitation de serveur mainframe (en réseau), qui à mon tour, je soupçonne d'avoir été influencé par le (peu) relative manque de fiabilité du matériel. Par exemple, les journaux et les données temporaires étaient généralement séparés car ces zones de stockage subissaient beaucoup d'usure, mais ce n'était pas vraiment un problème si elles étaient perdues.

Si vous construisez un système de bureau, je choisirais la répartition données / non-données / swap. À moins que vous ne construisiez un serveur qui s'attend à être sérieusement abandonné, des choses comme / usr / local et / var / tmp séparés deviennent simplement un casse-tête d'allocation d'espace.

Je dirais que c'est toujours agréable d'avoir - vous avez 100 Go de données (trop de mec pr0n :)) et vous devez réinstaller le système d'exploitation (ou, conformément à l'historique Windows, le réinstaller régulièrement pour supprimer les accumulations cruft) alors il est très simple de le garder intact, que s'il se trouvait également sur la partition C.

Cependant, je dirais qu'il y a un problème car Windows aime particulièrement bourrer toutes sortes de choses dans les répertoires sur le lecteur C - ce n'est pas seulement le répertoire `` utilisateurs '', mais toutes les données de l'application et divers morceaux qui finissent par rester coincés dans ProgramData aussi.

En outre, il existe un autre facteur - à part les très gros trucs (yup, ce pr0n à nouveau), il existe de nombreux outils de sauvegarde en ligne (ou utilitaires de sauvegarde locaux) qui effectuent des sauvegardes continues. Compte tenu de ceux-ci, ce n'est pas une telle priorité de séparer les données, car vous pouvez facilement les restaurer à partir de l'emplacement de sauvegarde.

Personnellement, j'essaie de diviser les données + OS. J'essaie également de placer des applications sur une partition différente, de sorte que mes sauvegardes de système d'exploitation soient beaucoup plus petites.

Je serai l'avocat du diable pour une autre école de pensée.

Supposons que pour des raisons de performances, votre fournisseur recommande que la partition du système d'exploitation ne soit pas «clairsemée» et souhaite que vous allouiez la partition complète du système d'exploitation à l'avance. Cela se traduit par 10 Go à 20 Go (ou plus) d'espace inutilisé sur le lecteur SAN.

C'est bien pour une seule machine virtuelle, mais il y a de fortes chances que vous disposiez de plusieurs serveurs "critiques pour les performances", chacun avec ses propres 10 à 20 Go d'espace libre. Dans notre environnement, cet espace blanc représentait 20% de notre disque SAN. Gardez à l'esprit qu'il existe des limites auxquelles nous devons remplir un disque SAN (mais c'est une autre histoire).

La direction avait le choix

1) Absorber l'espace perdu de 20% sur le SAN, qui s'ajoute aux autres exigences de "l'espace blanc", et isoler tout scénario de "disque complet" qui pourrait se produire

2) Mettez tout sur le lecteur C: \ et risquez que le lecteur se remplisse en raison des journaux d'application.

Qu'ont-ils fait?

Étant donné que Windows 2008R2 peut étendre dynamiquement le lecteur C: \ du système d'exploitation hôte et peut étendre le lecteur lorsqu'il est plein, la direction a pris les "économies" de coûts et les a réinvestis dans des outils de surveillance comme SCOM.

Maintenant, nous obtenons plus qu'une simple protection d'un remplissage de lecteur C: \, mais nous avons mis en place une surveillance des systèmes plus complète pour répondre à d'autres problèmes avant qu'il ne se produise.