C: \ é para OS, D: \ é para dados?

"Antigamente", sempre separávamos nossas unidades de SO (no Windows) das unidades de dados. No mundo Linux, embora eu esteja muito menos familiarizado com isso, estou ciente de que a sabedoria determina ainda mais volumes definidos e usados ​​em uma configuração de práticas recomendadas.

Agora que é provável que o armazenamento do servidor esteja em uma SAN (onde os recursos de disco são compartilhados por muitos sistemas operacionais e aplicativos individuais), importa realmente mais que as partições de SO e Dados sejam segregadas no nível do volume?

Quais são seus pensamentos?

Existem três drivers principais para manter o sistema operacional e os dados separados por armazenamento.

1. Espaço . Como ErikA aponta, você realmente NÃO quer que o volume do seu sistema operacional fique sem espaço. Todos os tipos de coisas ruins podem acontecer. Separando esses dois métodos de crescimento
2. I / Requisitos O Acesso . O tipo de E / S usado no volume do seu sistema operacional geralmente é muito diferente do tipo usado pelos volumes de dados. Manter seus tipos de E / S separados é uma ótima idéia em vários níveis.
3. Portabilidade de armazenamento . Quando chegar a hora de atualizar o sistema operacional do servidor, você pode controlar o volume do sistema operacional e manter todos os dados. Ou em ambientes SAN ou VM, você pode simplesmente mover o volume de dados para um servidor novo e recém-instalado e economizar tempo com atualizações.

Além disso, alguns sistemas operacionais (o Windows está entre eles) não são muito gentis para redimensionar o volume do sistema operacional, o que significa que você geralmente precisa fornecer o máximo necessário durante a vida útil ao formatar o servidor. Compare isso com os volumes de dados que podem e frequentemente são redimensionados várias vezes durante a vida útil de um servidor. Mesmo em ambientes totalmente virtualizados, onde o SO e o Datavvolumes estão sendo armazenados no mesmo armazenamento real, não conseguir redimensionar o volume do SO pode ser um grande obstáculo. Atualmente, o Windows 2008+ recomenda 30 GB para a unidade C: \ atualmente, muito diferente dos 10 GB que estávamos usando no Server 2003; isso é algo que prenderá muitos administradores do Windows durante a conversão de 2003 para 2008.

Sim, certamente separa o SO dos dados. Eu já vi várias vezes onde, com uma partição compartilhada, a partição acaba se enchendo e tornando impossível corrigir o SO, impossível estender a partição (por vários motivos), etc.

Na IMO, a sobrecarga de gerenciar duas partições é um preço pequeno a pagar pelo isolamento fornecido.

Com relação aos sistemas suportados por SAN a que você se referiu, isso ainda não o protegerá dos dados que preenchem a partição do SO. Com o armazenamento totalmente virtualizado, você não precisa se preocupar tanto em garantir que o SO e os dados funcionem em eixos separados.

Eu diria que depende do que você está fazendo com o sistema. Se você precisar reinstalar o sistema operacional, poderá economizar um pouco de trabalho colocando todos os seus dados em uma partição separada. Caso contrário, não vejo mais a necessidade. Meus dois centavos.

Em princípio, acho que segregar o espaço padrão do sistema operacional (como C :) dos dados (D :) é uma boa idéia, mas também recomendo criar uma partição menor para os arquivos de log (L :) para mantê-los um pouco mais seguro e evita alguns tipos de ataques de negação de serviço.

O Linux é muito bom, pois o sistema de arquivos permanece hierarquicamente sob um diretório raiz, independentemente de quantos discos físicos ou partições virtuais você usa. Definitivamente particionaria o disco, mas não necessariamente para separação de dados versus sistema operacional (já que muitas vezes os dois se misturam).

Eu olhava para:

1. Quais subdiretórios provavelmente preencherão seus discos e causarão problemas de espaço para outros diretórios (por exemplo, particione off / home e / var / log, por exemplo).
2. Se partes diferentes da estrutura de diretórios precisam de sistemas de arquivos diferentes por motivos de desempenho (por exemplo, XFS para estabilidade, Ext3 para uso geral, etc.)
3. Quais diretórios podem precisar ser expandidos no futuro - esses são bons candidatos para particionamento porque você pode simplesmente renomear o diretório, particionar e montar um novo conjunto de espaço em disco no local do diretório e copiar os dados do antigo para o novo localização.

As recomendações históricas de particionamento do Linux (bem, Unix, na verdade) são em parte devido às suas origens como um sistema operacional de servidor de mainframe (em rede), que, por sua vez, suspeito que foi influenciado pela (então) relativa confiabilidade do hardware. Por exemplo, logs e dados temporários eram tipicamente separados porque essas áreas de armazenamento sofriam muito desgaste, mas não era um grande problema se elas fossem perdidas.

Se você está construindo um sistema de desktop, eu iria para a divisão de dados / não-dados / troca. A menos que você esteja construindo um servidor que esteja esperando uma grande ascensão, coisas como / usr / local e / var / tmp separados se tornam uma dor de cabeça na alocação de espaço.

Eu diria que ainda é bom ter - você tem 100Gb de dados (muito pr0n cara :)) e precisa reinstalar o sistema operacional (ou, de acordo com o histórico do Windows, reinstale-o regularmente para remover os arquivos acumulados). é muito simples mantê-lo intacto, do que se estivesse na partição C também.

No entanto, eu diria que há um problema lá, pois o Windows gosta especialmente de encher todos os tipos de coisas nos diretórios da unidade C - não é apenas o diretório 'users', mas todos os dados do aplicativo e vários bits e partes que acabam presos no ProgramData também.

Além disso, há outro fator - além das coisas realmente grandes (sim, que são novamente), existem muitas ferramentas de backup online (ou utilitários de backup local) que executam backups contínuos. Diante disso, não é uma prioridade separar os dados, pois você pode restaurá-los facilmente do local do backup.

Pessoalmente, tento dividir dados + SO. Também tento colocar aplicativos em uma partição diferente também, para que meus backups do sistema operacional sejam muito menores.

Serei o advogado do diabo por uma escola de pensamento diferente.

Suponha que, por motivos de desempenho, seu fornecedor recomende que a partição do SO não seja "esparsa" e deseje que você aloque a partição do SO completa antecipadamente. Isso resulta em 10 GB a 20 GB (ou mais) de espaço não utilizado na unidade SAN.

Isso é bom para uma única VM, mas é provável que você tenha vários servidores "críticos para o desempenho", cada um com seus próprios 10 a 20 GB de espaço em branco. Em nosso ambiente, esse espaço em branco representava 20% do nosso disco SAN. Lembre-se de que existem limites para os quais devemos preencher um disco SAN (mas isso é outra história).

A gerência teve uma escolha

1) Absorva o espaço desperdiçado de 20% na SAN, além de outros requisitos de "espaço em branco" e isole qualquer cenário de "disco cheio" que possa ocorrer

2) Coloque tudo na unidade C: \ e arrisque a unidade se encher devido aos logs do aplicativo.

O que eles fizeram?

Considerando que o Windows 2008R2 pode expandir dinamicamente a unidade C: \ do SO host e pode expandir a unidade quando estiver cheia, o gerenciamento tomou a "economia" de custos e a reinvestiu em ferramentas de monitoramento como o SCOM.

Agora, estamos obtendo mais do que apenas a simples proteção de um preenchimento de unidade C: \, mas temos um monitoramento de sistemas mais completo para resolver outras preocupações antes que isso aconteça.