Unidades vs. Pontos de montagem?

O DBA sênior anterior configurou pontos de montagem para todas as nossas unidades em todos os SQL Server em toda a empresa. O novo DBA Sênior está horrorizado com os pontos de montagem que querem mudar nosso padrão (principalmente, acho, porque ele não tem experiência com eles).

Com base nos resultados de inúmeras pesquisas na Internet, não consigo encontrar nenhum motivo (pós-SQL Server 2000) para não usar pontos de montagem.

Alguém está ciente das limitações do sistema operacional Windows em relação a este tópico?

• Ultimamente, tenho ouvido a alegação de que "o sistema operacional não reconhece pontos de montagem". (Falso, com base em minha pesquisa sobre as versões do Windows Server que usamos).

Existe algum motivo baseado em evidências ou na experiência para NÃO usar pontos de montagem com o SQL Server?

• Suponha que ficar sem letras de unidade não é um problema para nós.

Entendo que os pontos de montagem são incrivelmente úteis para segregar cargas de trabalho.

Alguém pode confirmar ou refutar meu entendimento de que os pontos de montagem realmente segregam / isolam cargas de trabalho dos diferentes tipos de arquivos de dados e log (arquivos de banco de dados do sistema, arquivos de banco de dados do usuário, tempDB) com mais eficiência do que uma unidade para arquivos de dados, arquivos de log e tempdb ?

Depende do que está do outro lado do ponto de montagem. Se todas as montagens forem LUNS espalhadas pelas mesmas unidades físicas, não haverá ganhos. Se os LUNS estiverem em um canal iSCSI compartilhado e lento, talvez não haja ganhos. Se os LUNS estiverem todos sob 1 controlador ... você verá quantas variáveis ​​estão em jogo. Não há uma resposta.

Para determinar a configuração dos pontos de montagem, consulte Localizando pontos de montagem usando o PowerShell do Boe Prox.

O SQL Server não tem nenhum problema com pontos de montagem. Eles são definidos no nível do sistema operacional e o SQL Server "não sabe ¹ ", não possui o mesmo volume que a unidade em que parece estar montado.

Algumas ferramentas de monitoramento podem fornecer informações ruins com base nessa última frase.

Por exemplo, se você tiver três pontos de montagem como

1. C:\SQLData\SQL_Data onde todos os seus arquivos .MDB são armazenados
2. C:\SQLData\SQL_Logs onde todos os seus arquivos .LDF são armazenados
3. C:\SQLData\SQL_Backups onde todos os seus arquivos de backup .BAK e .TRN estão armazenados

O SQL Server funcionará sem problemas. Mas se você executar algum tipo de ferramenta que avisa quando os discos estão com pouco espaço, ele pode verificar o C: e não os volumes montados abaixo dele ; portanto, talvez você não saiba quando esses pontos de montagem estão com pouco espaço em disco. Além disso, várias consultas de "práticas recomendadas" emitem avisos falsos, informando que você não deve ter seus dados, logs e backups no mesmo disco, porque o SQL Server acredita que eles estão no mesmo disco. Esses são sinalizadores falsos e podem ser ignorados.

Mas você basicamente deseja configurar algumas etapas adicionais no monitoramento do servidor para garantir que a unidade C: tenha espaço suficiente e que cada ponto de montagem também.

As vezes em que usei pontos de montagem no SQL Server, esse foi o único problema que encontrei: relatórios de integridade do sistema do SQL Server que fornecem dados falsos sobre espaço livre disponível e erros falsos dizendo que você não deve ter todos os seus dados na mesma unidade. Como você sabe que esses são erros falsos, eles são fáceis de ignorar.

^{1 O} SQL Server possui dados que o tornam ciente do ponto de montagem, mas do ponto de vista do uso prático, não há diferença de comportamento. "Funciona", confiando no sistema operacional para lidar com os detalhes. Assim como confia no sistema operacional para lidar com as especificidades dos LUNs iSCSI conectados como unidades locais.

Além do CM_Dayton resposta e de Sean Gallardy resposta , uma questão ainda não identificado com pontos de montagem está relacionado à segurança. Para citar as Diretrizes para definir permissões SQL em pastas do ponto de montagem :

Embora as pastas raiz do ponto de montagem possam parecer pastas comuns e sejam acessadas da mesma maneira que as pastas, elas não são pastas regulares. Como resultado, quando você define permissões em uma pasta raiz do ponto de montagem, as permissões não são herdadas do “volume pai” da mesma maneira que as pastas comuns. De fato, eles não são herdados. Isso ocorre porque, embora pareça que o volume montado seja filho do "volume pai", não é. Você está simplesmente acessando o volume montado através de um caminho a partir do "volume pai".

Em poucas palavras, você deve atribuir permissões para montar pastas de maneira diferente se desejar utilizar a pasta raiz do ponto de montagem. Em vez de atribuir permissões como você faria com uma pasta normal, você deve atribuir permissão no volume. Novamente, a partir desse mesmo artigo (o destaque é da Microsoft):

Pegadinhas

Infelizmente, ainda é possível definir / exibir permissões na pasta raiz do ponto de montagem via Windows Explorer, o que pode levar a resultados inesperados porque as permissões da pasta raiz do ponto de montagem podem parecer válidas e você pode ver permissões herdadas "apropriadas" , no entanto, essas não são as permissões aplicadas ao volume montado.

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

Diretrizes

1. É recomendável que você não coloque nenhum arquivo diretamente na pasta raiz do ponto de montagem . Isso tornará o gerenciamento de permissões muito mais simples, porque a tendência é sempre verificar as permissões da pasta, o que, neste caso, é enganoso. Em vez disso, crie uma subpasta na pasta raiz do ponto de montagem e defina as permissões apropriadas para essa subpasta . Como a subpasta é uma pasta comum, as permissões de pasta que você observa e define são de fato as permissões que estão sendo aplicadas. Portanto, usando o exemplo anterior, você desejaria criar uma nova pasta: D: \ FolderForVol3 ** SubfolderXYZ **. Agora, defina suas permissões de pasta para a nova pasta SubfolderXYZ como faria normalmente.
2. Se você absolutamente precisar colocar itens diretamente na pasta raiz do ponto de montagem (não é a abordagem recomendada), será necessário definir permissões de volume, não permissões de pasta. Lembre-se de que isso ocorre porque as permissões da pasta raiz do ponto de montagem não são as permissões que realmente serão definidas no volume montado (porque a pasta raiz do ponto de montagem não é uma pasta real). Você pode definir permissões de volume da seguinte maneira:
   • Iniciar-> executar-> diskmgmt.msc (Exibir as propriedades de um volume http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Selecione a guia volume-> Propriedades-> Segurança
3. Se você estiver adicionando uma nova pasta para o SQL usar, esteja ciente das permissões necessárias para o acesso ao SQL:
   • A partir do SQL Server 2012, as permissões são atribuídas ao SID por serviço para cada um de seus serviços. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Configurar contas de serviço e permissões do Windows http://msdn.microsoft.com/en-us/library/ms143504.aspx

Se você não deseja aninhar tudo em uma subpasta sob o Ponto de montagem, como recomenda a MS, a maneira como acho mais fácil atribuir permissões é através do cacls.exeutilitário. Instruções detalhadas para isso podem ser encontradas em Você não pode aplicar permissões ao diretório raiz de um volume do sistema de arquivos NTFS no Windows Server 2003 .

Eu não acho que seja uma questão totalmente resolvida ainda. Esta pergunta recente que a instalação do FCI do SQL Server com problemas de permissão de ponto de montagem mostra que ainda pode acontecer no Windows 2012 com SQL Server 2016.

Dependendo da segurança que você deseja atribuir, o comando pode variar, mas o teste é a chave para o sucesso. Portanto, familiarize-se com o comando antes de executá-lo em um ponto de montagem ativo, pois você pode rapidamente usar a segurança se esquecer algo tão simples quanto o \Esinalizador.

Com base nos resultados de inúmeras pesquisas na Internet, não consigo encontrar nenhum motivo (pós-SQL Server 2000) para não usar pontos de montagem.

O principal motivo é que alguém teve uma experiência ruim com eles (ou, inversamente, nenhuma experiência com eles) e os excitou completamente ... para sempre. Isso também é conhecido como preferência pessoal.

Agora, há são algumas razões que você não pode usá-los. A principal razão pela qual consigo pensar é que um driver ou aplicativo / ferramenta de terceiros (por exemplo, driver de filtro, replicação de disco etc.) não é compatível. Um exemplo rápido disso é uma ferramenta de replicação de disco em nível de bloco que não suportava nada além de NTFS, com apenas tamanhos de cluster específicos e não podia ir acima de 2 TB para nenhum volume específico.

Alguém está ciente das limitações do sistema operacional Windows em relação a este tópico?

Não. Você pode fazer muitos, muitos pontos de montagem. De fato, você geralmente terá um problema com as interfaces do dispositivo antes de atingir qualquer limite apreciável dentro do Windows Server (supondo que você não esteja usando uma versão do Windows Server com mais de 17 anos ...).

Ultimamente, tenho ouvido a alegação de "o sistema operacional não reconhece pontos de montagem". (Falso, com base em minha pesquisa sobre as versões do Windows Server que usamos).

Se o sistema operacional não reconhecesse pontos de montagem, como ele deixaria você usar um ponto de montagem? Isso simplesmente não faz sentido.

Se o sistema operacional não reconhecer pontos de montagem, por que os rastrearia e consultaria seus metadados ? Além disso, observe que um ponto de montagem é uma construção do sistema de arquivos que um sistema operacional pode ou não suportar. Nem todos os sistemas de arquivos que você encontra podem oferecer suporte a pontos de montagem, no entanto, o sistema de arquivos mais comum no Windows Server é o NTFS, que de fato suporta pontos de montagem e já existe há algum tempo.

Apenas para trazer esse item falso para casa ainda mais; O Clustering do Windows tem algo chamado CSVs (Volumes Compartilhados de Cluster) que realmente usam pontos de montagem para os volumes ... esse é um item nativo usando a tecnologia. Devo dizer que quem lhe disse isso precisa ser educado na questão.

Existe algum motivo baseado em evidências ou na experiência para NÃO usar pontos de montagem com o SQL Server?

Sim, sempre há um servidor executando o Windows NT 4 ... não o use lá. Convém também verificar se você está executando uma versão suportada do Windows Server e se mantém atualizado com as atualizações.

No entanto, como descrevi acima, pode haver itens de terceiros que não são suportados ou não funcionam corretamente com eles. Eu diria que largue esse provedor e encontre um novo.

Entendo que os pontos de montagem são incrivelmente úteis para segregar cargas de trabalho.

Os pontos de montagem são incrivelmente úteis. Existem muitas maneiras de usá-las, a mais comum é contornar as limitações da letra da unidade (como no caso, existem muitas) do Windows. O próximo uso mais comum é ter unidades menores de tamanho gerenciável (pense em LUNs, disco virtual [VMDK, VHDX]) para ajudar a evitar volumes monolíticos insanamente grandes e raramente gerenciáveis ​​(é realmente um problema gerenciar unidades na faixa de 10 TB, pois um único LUN, disco virtual etc.), especialmente em versões mais antigas do NTFS, em que a implementação era menor do que o uso possível ... por exemplo, em versões mais antigas do Windows, o tamanho máximo do NTFS era de 2 TB.

A segregação da carga de trabalho é outro ótimo uso. Você pode ver definitivamente, existem muitos usos e isso depende do seu caso de uso individual. Também existem maneiras impróprias de usá-lo ... como fazer uma declaração geral de que tudo precisa ser um ponto de montagem. Isso é apenas uma sobrecarga administrativa louca nesse ponto.

Os pontos de montagem são o caminho a seguir para servidores que possuem aplicativos compartilhados ou para fatiar dados em mais do que apenas os volumes DZ típicos.

Por exemplo, você pode instalar todos os dados de um aplicativo, arquivos de log e temporários na e:unidade, por exemplo. E:/MP_1pode ter arquivos de dados para o Business A, E:/MP_2os arquivos de log E:/mp_3podem ter arquivos temporários para o Business A e assim por diante. Então você tem o negócio B nos pontos de montagem no F:Drive. Cada ponto de montagem possui seu próprio espaço.

O SO não tem absolutamente nenhum problema com os MPs. Clusters e Always On não têm problemas com MPs. Eu trabalhei para um banco muito conhecido que tinha a maioria de seus SQL Servers instalados em MPs. Uma vez que o DBA os use e compreenda os conceitos, ele os impulsionará a soluções mais fáceis nas lojas que precisam dele.

Foi mencionado para não instalar nada na raiz do MP. Isso está certo. Nada na raiz do MP, assim como você não instalaria nada na raiz do D como exemplo.

Soluções de auditoria e monitoramento como Foglight, Guardiam, EMS e PBM também não têm problemas com pontos de montagem.