Vantagens / Desvantagens de usar uma única letra de volume / unidade para instalações do Windows Server

Question

Nosso ambiente virtual é cortado como uma VM para cada função de trabalho (DNS, DC, System Center CM, servidor de arquivos, agregação de logs, IIS etc.). Se o desempenho do disco não é crítico, é realmente necessário separar logicamente os arquivos do sistema operacional Windows dos arquivos / dados / logs do aplicativo? Como um padrão anterior no Windows 2000/2003 e no NT4 (gasp!), Nossa loja reduziria a carga de trabalho entre as unidades C: e D:, mesmo que fossem atendidas pela mesma matriz de disco subjacente.

Supondo que você não precise de arrays de disco separados para desempenho, como cenários do SQL Server, essa separação ainda é a ideal ou necessária? Quais são as vantagens / desvantagens de dividir seus dados do OS + em diferentes volumes atualmente?

Uma vantagem em que posso pensar em vários volumes é que você pode executar o chkdsk em uma unidade que não seja do sistema interativamente, sem precisar de uma reinicialização (isso me salvou algum tempo de inatividade no passado).

Obrigado pela sua ajuda - temos uma construção pendente de vários novos servidores de utilitários e não queremos fazer engenharia excessiva.

    

Answer 1

Se você está apenas perguntando se você deve ter uma partição de "sistema" e uma partição de "aplicativo" separada, não vejo o valor nela, especialmente agora.

Costumava ser uma convenção fazer isso para sistemas de tipo UNIX porque se o volume do sistema estourasse com dados, você poderia ter situações que o tornassem não inicializável ou inutilizável, então a separação de partições era uma maneira pseudo-física de prevenir , digamos, arquivos de log autônomos de preencher sua partição de inicialização.

Hoje você não deve ver muito benefício se estiver mantendo sistemas corretamente. Você poderia realmente ter problemas agora que as atualizações são enormes e as atualizações do sistema são muito grandes; o que antes estava bem em uma partição de instalação do Windows de 10 gig agora é pequena. Eu também vi problemas por causa da forma como o Windows transfere arquivos pela rede e como downloads temporários, onde ele preenche a partição do sistema e não pode copiar as coisas mais tarde, e aumentou os problemas de fragmentação no sistema de arquivos.

Se você estiver virtualizando esse sistema, nem mesmo argumentará que está obtendo um desempenho melhor, já que a máquina virtual é abstraída da camada de disco físico, independentemente de quantas partições / unidades a VM acha que possui.

Se o seu aplicativo é sensível ao tempo, a ponto de não ser possível baixar o sistema para uma verificação de disco (esperamos que você raramente precise dele), provavelmente você deve ter planos em vigor para suporte de failover, manutenção Windows, e no caso da VM, você provavelmente poderia ter uma maneira de manter a VM em execução enquanto estiver diagnosticando um problema com uma captura instantânea ou cópia em uma sandbox, se necessário. Se a operação for crítica, você já deve ter planos para manter o serviço disponível se a máquina falhar. Isso cria a capacidade de corrigir a caixa virtual sem interromper o serviço. Caso contrário, seus usuários terão que viver com um período de inatividade.

Além disso, o Windows está finalmente ganhando mais flexibilidade (e o Linux já tinha isso) na criação de gerenciamento de volume on-the-fly que pode aumentar e diminuir drives e combiná-los em volumes maiores (como suporte ao Linux LVM). O Windows está se afastando lentamente do modelo centrado na unidade e mais no modelo de gerenciamento de volume nos servidores.

Os serviços que você menciona já têm alguma redundância embutida se você estiver usando o Windows DC, então o tempo para um chkdsk não deve ser um problema para muitos deles.

Em geral, a menos que você tenha uma necessidade direta de criar volumes separados como letras de unidade, eu criaria uma unidade grande e deixaria assim. É mais simples, é mais flexível no futuro e, no geral, é um PITA menor para lidar.

    

Answer 2

Eu não acho que tenha sido um padrão, embora tenha sido uma convenção amplamente implementada. Eu nunca vi o valor em fazer isso e ainda não vejo. Eu entendo o raciocínio por trás de querer separar seus dados de seu sistema operacional por razões de backup / recuperação, mas separar seu sistema operacional de seus aplicativos e dados por razões de desempenho, criando volumes lógicos individuais no mesmo disco físico susbsystem é um esforço errante. Se alguma coisa, você vai induzir mais carga de desempenho na E / S do disco fazendo isso, já que seu sistema operacional e aplicativos estão competindo pelo mesmo disco físico subjacente. Se você precisar separar aplicativos intensivos de E / S de disco do sistema operacional (como SQL ou Exchange), será necessário fazer isso usando discos físicos ou matrizes de disco separados.

    

Answer 3

Certas operações do sistema de arquivos podem ser mais fáceis, como você provavelmente já sabe (chkdsk). Por exemplo, backups, dependendo de como o sistema de backup funciona.

Além disso, o planejamento pode ser mais simples. Se os requisitos de disco do sistema operacional forem constantes, mas os requisitos de seus aplicativos variarem, você poderá ter mais flexibilidade ao implantar VMs se simplesmente anexar um disco de aplicativo a uma VM base modelo.

Tenho certeza de que existem outras vantagens e desvantagens, mas a relevância dependerá do funcionamento de sua organização.

    

Answer 4

Essa prática se origina do tempo venerável em que, no UNIX (sistema V e anterior), você poderia ficar sem inodes no volume de inicialização e conseguir tornar um sistema não inicializável. Nos modernos UNIXs e Windows, isso não é mais o caso. Os administradores do Windows simplesmente imitaram o esquema de particionamento. Os administradores do Windows que eu conheço costumavam ter uma crença equivocada (baseada na antiga prática que eu acho) que separar os dados do sistema operacional significava que você de alguma forma isolaria os dados da corrupção caso o volume de inicialização fosse mal. em qualquer caso, a única razão para separar os dados é portabilidade e expansibilidade. É muito mais fácil expandir uma partição separada do que expandir o volume de inicialização.

    

Answer 5

Embora exista um ganho de desempenho ao executar sistemas operacionais e dados em unidades separadas, há um equívoco surpreendentemente comum de que isso também se aplica a partições separadas para o SO e para os dados (ou aplicativos, ou qualquer outro). Isso não poderia estar mais errado.

Várias partições em uma única unidade física ou matriz causam uma queda de desempenho. O motivo é bem simples. O maior impacto no desempenho resulta do movimento físico da montagem da cabeça. A unidade não pode nem começar a ler ou escrever até que as cabeças cheguem ao local correto e parem de se mover lateralmente. Ao executar várias partições, os chefes precisam se movimentar muito mais do que seriam para uma única partição. A distância média percorrida também é muito maior.

Quando as unidades eram muito pequenas, fazia sentido separar o sistema operacional e os dados, apenas para garantir que houvesse espaço suficiente para cada um. Com as modernas capacidades de direção, isso faz menos sentido, a menos que exista uma razão mais convincente que apenas as separe por fazer isso. É claro que há muitos casos em que a separação faz sentido, desde que você use drives ou arrays fisicamente separados. por exemplo. Um servidor de banco de dados de alta demanda pode exigir unidades dedicadas para poder lidar com isso.

    

Answer 6

Do ponto de vista da limpeza, ainda prefiro ter dados especificamente em outro volume lógico. Isso significa que você pode ter qualquer estrutura de pastas que desejar na raiz do disco sem ter que se preocupar com o que o Windows deseja fazer com ele.

Em um ambiente virtualizado, isso também é benéfico, pois você pode facilmente desanexar o disco rígido virtual que contém os dados e reconectá-lo a outra máquina sem ter que copiar manualmente os arquivos do disco rígido virtual, talvez com flexibilidade nas janelas de manutenção ou interrupções. Você também pode dimensionar facilmente o tamanho desse disco virtual sem que o sistema operacional tenha um colapso mental devido à sua partição do sistema mudar de tamanho de repente.

Quanto aos aplicativos, geralmente sou da opinião (especialmente quando você está usando uma máquina lógica por carga de trabalho) que os binários de um aplicativo dificilmente são preocupantes de uma perspectiva de espaço em disco, portanto você nunca deve se preocupar muito sobre o seu sistema operacional expandindo mais do que o necessário e, portanto, pode ser instalado com segurança ao lado do sistema operacional.

Outro pensamento à prova de futuro é que, se por algum motivo o servidor se tornar muito IO, você pode facilmente pegar seu disco rígido virtual contendo seus dados e movê-lo para um back-end de armazenamento mais rápido, deixando o sistema operacional intacto armazenamento mais lento.