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.