C: \ es para OS, D: \ es para datos?

"En el pasado" siempre separamos nuestras unidades de sistema operativo (en Windows) de nuestras unidades de datos. En el mundo de Linux, aunque estoy mucho menos familiarizado con él, soy consciente de que la sabiduría dicta aún más volúmenes definidos y utilizados en una configuración de mejores prácticas.

Ahora que es probable que el almacenamiento del servidor esté en una SAN (donde los recursos de disco son compartidos por muchos sistemas operativos y aplicaciones individuales), ¿realmente importa que el SO y las particiones de datos estén segregadas a nivel de volumen?

¿Cuáles son tus pensamientos?

Hay tres controladores principales para mantener el sistema operativo y los datos separados en cuanto al almacenamiento.

1. Espacio . Como señala ErikA, REALMENTE no desea que el volumen de su sistema operativo se quede sin espacio. Todo tipo de cosas malas pueden suceder. Separando estos dos métodos de crecimiento
2. I / O Requisitos de acceso . El tipo de E / S utilizado en el volumen de su sistema operativo generalmente es muy diferente del tipo utilizado por sus volúmenes de datos. Mantener sus tipos de E / S separados es una muy buena idea en muchos niveles.
3. Portabilidad de almacenamiento . Cuando llegue el momento de actualizar el sistema operativo del servidor, puede bombardear el volumen del sistema operativo y conservar todos los datos. O bien, en entornos SAN o VM, puede mover el volumen de datos a un servidor nuevo y recién instalado y ahorrar tiempo en las actualizaciones.

Además, algunos sistemas operativos (Windows se encuentra entre ellos) no se toman demasiado amablemente para cambiar el tamaño del volumen del sistema operativo, lo que significa que generalmente debe dar tanto como necesitará durante su vida útil cuando formatee el servidor. Contraste esto con los volúmenes de datos que pueden y frecuentemente cambian de tamaño muchas veces durante la vida útil de un servidor. Incluso en entornos totalmente virtualizados donde el sistema operativo y los volúmenes de datos se alojan en el mismo almacenamiento real, no poder cambiar el tamaño del volumen del sistema operativo puede ser una gran desventaja. Windows 2008+ ahora recomienda 30GB para la unidad C: \ en estos días, muy lejos de los 10GB que estábamos usando en Server 2003; Esto es algo que atrapará a muchos administradores de Windows a medida que realizan la conversión de 2003 a 2008.

Sí, seguramente separe el sistema operativo de los datos. Lo he visto una y otra vez donde, con una partición compartida, la partición termina llenándose y haciendo que sea imposible parchear el sistema operativo, imposible extender la partición (debido a varias razones), etc.

En mi opinión, la sobrecarga de administrar dos particiones es un pequeño precio a pagar por el aislamiento proporcionado.

Con respecto a los sistemas respaldados por SAN a los que se refirió, eso aún no lo protegerá de los datos que llenan su partición del sistema operativo. Con el almacenamiento totalmente virtualizado, no necesita preocuparse tanto por garantizar que el sistema operativo y los datos vivan en ejes separados.

Diría que depende de lo que esté haciendo con el sistema. Si necesita reinstalar el sistema operativo, puede ahorrarse algunos problemas colocando todos sus datos en una partición separada. De lo contrario, ya no veo la necesidad. Mis dos centavos.

En principio general, creo que es una buena idea segregar el espacio predeterminado del sistema operativo (como C :) de los Datos (D :), pero también recomendaría crear una partición más pequeña para los archivos de registro (L :) para mantenerlos un poco más seguro y evita algunos tipos de ataques de denegación de servicio.

Linux es muy bueno porque el sistema de archivos permanece jerárquicamente bajo un directorio raíz sin importar cuántos discos físicos o particiones virtuales use. Definitivamente, particionaría el disco, pero no necesariamente para la separación de datos versus sistema operativo (ya que a menudo los dos se mezclan de todos modos).

Yo miraría a:

1. Qué subdirectorios pueden llenar su disco y causar problemas de espacio para otros directorios (es decir, partición desactivada / home y / var / log, por ejemplo).
2. Si diferentes partes de la estructura de su directorio necesitan diferentes sistemas de archivos por razones de rendimiento (es decir, XFS para estabilidad, Ext3 para uso general, etc.)
3. ¿Qué directorios podrían necesitar expandirse en el futuro? Estos son buenos candidatos para la partición porque simplemente puede cambiar el nombre del directorio, particionar y montar un nuevo conjunto de espacio en disco en la ubicación del directorio, y copiar los datos del antiguo al nuevo ubicación.

Las recomendaciones históricas de particionamiento de Linux (bueno, Unix realmente) se deben en parte a sus orígenes como un sistema operativo de servidor mainframe (en red), que a su vez sospecho que fue influenciado por la (entonces) relativa falta de confiabilidad del hardware. Por ejemplo, los registros y los datos temporales generalmente se separaron porque esas áreas de almacenamiento se desgastaron mucho, pero no fue un gran problema si se perdieran.

Si está creando un sistema de escritorio, optaría por la división de datos / no datos / intercambio. A menos que esté construyendo un servidor que espera tomar una decisión seria, cosas como separar / usr / local y / var / tmp simplemente se convierten en un dolor de cabeza de asignación de espacio.

Yo diría que todavía es bueno tenerlo: tienes 100 Gb de datos (demasiados amigos) y necesitas reinstalar el sistema operativo (o, de acuerdo con el historial de Windows, reinstalarlo regularmente para eliminar la acumulación) cruft), entonces es muy simple mantenerlo intacto, que si también estuviera en la partición C.

Sin embargo, diría que hay un problema allí, ya que a Windows le gusta especialmente rellenar todo tipo de cosas en directorios en la unidad C, no es solo el directorio de 'usuarios', sino todos los datos de la aplicación y varios bits y piezas que terminan atascados en ProgramData también.

Además, hay otro factor: además de las cosas realmente grandes (sí, eso es lo que sucede de nuevo), hay muchas herramientas de respaldo en línea (o utilidades de respaldo locales) que realizan respaldos continuos. Dado esto, no es una prioridad separar los datos, ya que puede restaurarlos fácilmente desde la ubicación de la copia de seguridad.

Personalmente, trato de dividir datos + SO. También trato de poner aplicaciones en una partición diferente, para que las copias de seguridad de mi sistema operativo sean mucho más pequeñas.

Seré el defensor del diablo para una escuela de pensamiento diferente.

Supongamos que, por razones de rendimiento, su proveedor recomienda que la partición del sistema operativo no sea "escasa" y desea que asigne la partición completa del sistema operativo por adelantado. Esto da como resultado 10 Gb a 20 Gb (o más) de espacio no utilizado en la unidad SAN.

Esto está bien para una sola VM, pero es probable que tenga varios servidores "críticos para el rendimiento", cada uno con su propia sobrecarga de espacio en blanco de 10 a 20 Gb. En nuestro entorno, este espacio en blanco representaba el 20% de nuestro disco SAN. Tenga en cuenta que hay límites a los que debemos llenar un disco SAN (pero esa es otra historia).

La gerencia tuvo una opción

1) Absorba el 20% de espacio desperdiciado en la SAN, que se suma a otros requisitos de "espacio en blanco", y aísle cualquier escenario de "disco completo" que pueda ocurrir

2) Coloque todo en la unidad C: \ y corra el riesgo de que la unidad se llene debido a los registros de la aplicación.

¿Que hicieron?

Teniendo en cuenta que Windows 2008R2 puede expandir dinámicamente la unidad C: \ del sistema operativo host, y puede expandir la unidad cuando está completa, la administración tomó el "ahorro" de costos y lo reinvirtió en herramientas de monitoreo como SCOM.

Ahora estamos obteniendo más que una simple protección de un relleno de unidad C: \, pero tenemos una supervisión de sistemas más completa para abordar otras preocupaciones antes de que suceda.