Com meu equipamento de TI, temos modelos para implantar servidores com uma unidade / partição C dactos (10 GB) e uma unidade / partição D maior. Por que fazer isso? O Windows ( pelo menos até recentemente e minimamente ) não tem nenhum uso real de pontos de montagem dinâmicos em implantações gerais de servidores.
Editar
Então, com muitos dos comentários abaixo, uma sinopse:
Além do # 3 ( que, na minha opinião, é um argumento contra partições ), ainda não vejo razão para ter partições separadas. Se você quiser proteger seus dados, não basta colocá-los em outro conjunto de discos reais ou virtuais ou mapear para um recurso compartilhado em algum outro lugar (NAS, SAN, etc.)?
Para interromper o preenchimento do volume do sistema operacional e a falha do servidor.
Os servidores de arquivos beneficiam-se de volumes separados se você usar cotas, pois elas geralmente são definidas por volume. (por exemplo, colocar os diretórios pessoais do usuário em um volume, perfis em outro, dados da empresa em outro, etc.)
p.s. 10Gb parece muito pequeno para um volume do sistema. Após vários anos de atualizações do Windows e service packs, que serão preenchidos em breve.
A restauração a partir do backup fica mais fácil quando os arquivos de programa / dados são separados da instalação do sistema operacional. Eu gosto de dar pelo menos 25GB para a partição do sistema operacional, mas o ponto permanece o mesmo.
Normalmente, não encontro vantagem em fazer partições.
Aplicativos (Microsoft e outros) são notórios por demandar espaço em% SystemDrive%, mesmo se eles permitem que você escolha um diretório de destino. Com a incapacidade de fazer com que o serviço Atualizações automatizadas do Windows Update opte por não salvar backups de arquivos corrigidos, o tamanho dos diretórios "$ Desinstalar $" em% SystemRoot% cresce e aumenta. Ter um% SystemDrive% artificialmente limitado não tem sido nada além de trabalho para mim.
Normalmente, coloco diretórios e dados compartilhados em um único subdiretório de nível de raiz. Isso satisfaz minhas necessidades para manter aplicativos e dados separados.
Tendo dito tudo isso, geralmente esta é uma questão "religiosa" e eu não discuto com as pessoas sobre isso. Faça o que quiser com seus servidores. Não ter partições "de dados" me serviu bem.(Agora, ter volumes / fusos físicos separados ... isso é outra história.)
Parte do motivo pelo qual fazemos isso é que, se você tiver algum tipo de processo de fuga que preenche a unidade, o Windows não trava no chão quando o disco fica sem espaço.
A segunda razão pela qual fazemos isso é permitir unidades de tamanhos diferentes / níveis de invasão diferentes para nosso sistema operacional e partições de dados. Por exemplo, nós obteríamos (eu estou arredondando números e puxando-os para fora do ar aqui) 2 x drives SAS de 100GB para uma partição OS Mirror e, em seguida, drives SAS 6x700GB para uma partição de dados RAID 10. fazer isso poderia facilmente economizar US $ 1000 sobre o custo do sistema no final do dia.
A terceira razão é realmente muito simples, quem construiu o servidor com o CD da Dell não estava prestando atenção e, por padrão, cria uma unidade de sistema operacional de 10GB (20 em versões mais recentes, eu acredito).
Agora, como Evan disse, essa é uma preferência pessoal que faz fronteira com a crença "religiosa". Honestamente com o tamanho das unidades de hoje, de qualquer forma vai funcionar bem. Faça o que você está confortável com ... ou o que seus padrões corporativos ditam.
EDIT (baseado no autor original trazendo a virtualização) :.
O pensamento da virtualização traz um tópico interessante. Como Evan apontou, a maior parte do que eu tinha a dizer estava falando sobre o contêiner RAID diferente. No entanto, no meu ambiente VMWare eu tenho um modelo base de 20 GB. Agora a parte interessante vem aqui, todos os meus servidores estão hospedados em uma SAN e eu tenho dois volumes apresentados.
a unidade de 20 GB que faz parte do meu modelo e
um tamanho de dados variável Unidade de dados que eu anexo de acordo com os requisitos dos sistemas.
90% do tempo em que esses dois discos estão no mesmo conjunto de RAID, mas são dois drives "físicos" diferentes para a máquina. Como de costume, a virtualização traz uma camada de obscuridade para o processo de pensamento de TI "padrão".
Eu não tenho uma resposta exata para a sua pergunta, mas eu tenho várias anedotas que você pode achar útil para projetar sua configuração de unidade / partição.
(1) O NTFS corrompido
Eu tinha um servidor com duas partições, uma para o sistema operacional e outra para dados. Em algum momento, ao longo dos anos, algo deu errado com a partição de dados, e um único arquivo aninhado a cerca de 6 níveis de profundidade se tornou impossível de excluir ou renomear. No final, a única solução foi limpar a partição e recarregar os dados novamente. Obviamente, teria sido muito mais doloroso sem partições.
(2) A partição de dados completa
O mesmo servidor acima, em outro momento de sua vida, conseguiu acabar com uma partição de dados completamente completa, enquanto havia dezenas de GB disponíveis na partição do sistema operacional. Como uma medida de intervalo, usei um ponto de junção para armazenar temporariamente os dados na partição do sistema operacional até que o novo servidor chegasse. Era feio, mas funcionou. Evitar partições significaria evitar correções feias.
(3) O Server 2008 UAC
Em um servidor mais recente, descobri que você pode ter problemas para administrar qualquer unidade, exceto a unidade C:, a menos que você seja o administrador local ou o administrador do domínio. Estar no grupo Administradores não é suficiente. Isto é devido a uma estranheza com o UAC, que eu tenho desativado por enquanto.
(4) A cópia de sombra de volume
A Cópia de Sombra (também conhecida como Versões Anteriores) é ativada / desativada por partição. Se você não quer perder espaço armazenando versões anteriores para um determinado conjunto de dados, as partições são o seu melhor aliado.
O meu curso de ação preferido é separar completamente o SO e os Dados, tendo um array RAID 1 separado apenas para o sistema operacional. Isso permite uma grande flexibilidade. Por exemplo, eu poderia atualizar todos os discos rígidos usados para armazenamento de dados sem precisar alterar a instalação do SO.
Usamos várias partições em nossos servidores com a unidade C: dedicada ao SO. Nossas outras partições que usamos principalmente para armazenamento de dados, como bancos de dados, arquivos / pastas de usuários, arquivos / pastas compartilhados, etc.
Depende do serviço, é claro, mas há valor nisso. Como mencionado em outros lugares, diferentes partições podem ter diferentes características de armazenamento subjacentes. Assim, diferentes letras de unidades devem representar diferentes unidades de disco em vez de partições. Era uma vez uma decisão sensata de colocar seu arquivo Swap em sua própria partição, mas isso não é mais tão benéfico quanto antes. Caso contrário, mantenha sua unidade C: para o sistema operacional e aplicativos obstrutivos que se recusam a ir para qualquer outro lugar e aplicativos relocáveis em outro lugar.
Com a virtualização, você pode ter sua unidade C: armazenada em arquivo e ainda ter suas unidades D :, E :, F :, etc. realmente como apresentações diretas NPIV de armazenamento em nível de bloco. Ou a sua unidade do sistema operacional deve ser o par espelhado de discos (que pode ter 72 GB ou 144 GB) e as unidades que não são do sistema operacional são um conjunto RAID10 ou até mesmo algo totalmente diferente.
Ao executar um servidor IIS do Windows, nós separamos a unidade do sistema operacional de onde você colocou os arquivos do site hospedado para evitar travessias de diretório.
Este era um problema do Windows 2000, principalmente.
Se a partição do sistema for pequena, levará menos tempo para executar diagnósticos e reparos nessa partição, resultando em menos tempo de inatividade. Por exemplo, se você tiver um problema inesperado de disco ou sistema de arquivos e precisar reinicializar para executar o chkdsk em um sistema combinado de 2 TB + partição de dados, talvez o servidor não fique on-line até amanhã. Se essa partição tiver apenas 20 GB, você poderá voltar a operar em menos de meia hora. Você também pode fazer backup ou criar imagens da partição em menos tempo.
Dito isto, o limite de 10 GB que você mencionou parece alarmantemente pequeno, já que você consumirá rapidamente esse espaço com service packs e hotfixes. 20 a 30 GB seria mais adequado.
Eu não vi nenhuma menção ao Short Stroking, então vou adicioná-lo aqui.
Volumes / partições menores em unidades mecânicas reduzem o tempo de acesso / latência. Isso pode aumentar sensivelmente o desempenho em alguns casos.
As partições de boot de 10 GB parecem excessivamente pequenas nos dias de hoje. Os volumes de 25 a 80 GB parecem mais confortáveis para mim. Não importa o tamanho real, não formato unidades em sua capacidade total por vários motivos, a maioria dos quais remonta a problemas de desempenho.
Se a partição D na mesma unidade física for algo para dados raramente usados ou apenas para situações de emergência, então C: ainda obtém o benefício do efeito de curso curto. A chave é impedir que outras pessoas usem esse espaço como se fosse o armazenamento primário. Qualquer uso regular da partição secundária desperdiça essa vantagem.
Também gostaria de acrescentar que pequenas partições podem permitir que você use uma unidade sobressalente de 36 GB ou 73 GB como sobressalente para um RAID 1 degradado, em vez de ter que deixar a matriz degradada até que uma nova unidade chegue. Você também pode usar SSDs que podem estar no lado menor para assumir uma pequena partição se você não tiver se dimensionado dessa opção.
Não se esqueça da fragmentação de arquivos também, uma unidade de dados em um servidor normalmente seria preenchida com arquivos de log e bancos de dados em constante expansão. A partição do sistema também sofre o mesmo problema com atualizações e logs internos para janelas. Mas um problema de fragmentação na partição do sistema interromperá todo o sistema, enquanto o mesmo problema em uma unidade de dados afetará apenas o desempenho do aplicativo.
Há também o problema da tabela de partições do disco, e embora seja um pequeno ponto, quanto maior a tabela, mais lenta será a capacidade de indexar e pesquisar, especialmente se você tiver grandes quantidades de arquivos.
Na minha experiência, o ponto mais importante são os blocos ruins e o scandisk: você realmente não quer ver um volume de 10 TB ficando com blocos ruins e precisando de um scandisk, especialmente em um servidor importante, pois pode levar vários (ou muitas!) horas para terminar, enquanto os utilizadores pedem primeiro os seus ficheiros, depois culpam as coisas de TI e, finalmente, gritam consigo.
Se você tiver partições, os blocos defeituosos estarão em uma pequena unidade (pelo menos, aqueles que impedem o servidor de funcionar), que serão escaneados e corrigidos com rapidez suficiente para que os usuários não gritem com você (porque, vamos encarar eles ainda culpam as coisas de TI).
Atualização / recuperação
Ao executar uma atualização ou recuperar o sistema operacional, é muito mais fácil e mais limpo quando o sistema operacional reside em um volume dedicado. Em ambientes virtuais, pode-se simplesmente copiar os dados ".VHD" para um novo servidor para restaurar / atualizar o serviço.
Serviço de cópias de sombra de volume
Essa funcionalidade só pode ser ativada / desativada por volume. É mais eficiente dedicar um volume separado, já que essa tecnologia funciona alocando pontos de restauração com base no espaço livre disponível. Quanto mais espaço livre disponível, mais para trás pode-se realizar uma restauração. A unidade do sistema operacional consumirá espaço para atualizações instaladas, arquivos de programas temporários, etc. Alocar a versão anterior significa que os pontos de restauração serão encurtados e não serão um bom uso da tecnologia.
Compressão vs EFS
Apenas uma dessas tecnologias pode ser usada em um volume, portanto, o uso de volumes dedicados evita conflitos.
Administração
Isso é mais uma preferência do que uma razão técnica, pois é muito mais fácil para mim navegar para um volume diferente, em contraste com uma subpasta aninhada no volume do sistema operacional.
O mesmo acontece com a aplicação de permissões, pois é mais fácil gerenciá-las por volume, em vez de subpastas aninhadas.
Volume do sistema operacional - 0 espaço livre
Isso não aconteceu comigo há algum tempo, mas quando aconteceu, coisas muito estranhas aconteceram. Se os usuários tiverem permissão para modificar o conteúdo no volume do sistema operacional (por meio de um compartilhamento de arquivos, carregar arquivos grandes em um banco de dados etc.), você obterá um cenário de negação de serviço. A resolução é muito mais fácil quando isso acontece com um volume diferente daquele em que o sistema operacional reside.