Drives vs. Mount Points?

Il precedente DBA senior ha impostato i punti di montaggio per tutte le nostre unità su ogni SQL Server in tutta l'azienda. Il nuovo DBA Senior è inorridito dai mount points che vogliono cambiare il nostro standard (principalmente, penso, perché non ha esperienza con loro).

Sulla base dei risultati di numerose ricerche su Internet, non riesco a trovare alcun motivo (post-SQL Server 2000) per non utilizzare i punti di montaggio.

Qualcuno è a conoscenza delle limitazioni del sistema operativo Windows relative a questo argomento?

• Ultimamente ho sentito l'affermazione "il sistema operativo non riconosce i mount points". (Falso, in base alla mia ricerca sulle versioni di Windows Server che utilizziamo).

Esiste un motivo basato sull'evidenza o sull'esperienza per NON utilizzare i mount point con SQL Server?

• Supponiamo che a corto di lettere di unità non sia un problema per noi.

Comprendo che i punti di montaggio sono incredibilmente utili per separare i carichi di lavoro.

Qualcuno può confermare o confutare la mia comprensione del fatto che i mount point effettivamente separano / isolano i carichi di lavoro dei diversi tipi di dati e file di registro (file di database di sistema, file di database utente, tempDB) in modo più efficiente di un'unità per file di dati, file di registro e tempdb ?

Dipende da cosa si trova all'altra estremità del punto di montaggio. Se i mount sono tutti LUN distribuiti sulle stesse unità fisiche, allora nessun guadagno. Se i LUN sono su un canale iSCSI condiviso, lento, forse nessun guadagno. Se i LUN sono tutti sotto 1 controller ... vedi quante variabili sono in gioco. Non c'è una risposta.

Per determinare la configurazione dei punti di montaggio, vedere Individuazione dei punti di montaggio mediante PowerShell di Boe Prox.

SQL Server non ha problemi con i punti di montaggio. Questi sono definiti a livello di sistema operativo e SQL Server "non sa ¹ " non è lo stesso volume dell'unità in cui sembrano essere montati.

Tuttavia, alcuni strumenti di monitoraggio potrebbero fornire informazioni errate sulla base di quest'ultima frase.

Ad esempio se hai tre punti di montaggio come

1. C:\SQLData\SQL_Data dove sono memorizzati tutti i tuoi file .MDB
2. C:\SQLData\SQL_Logs dove sono memorizzati tutti i tuoi file .LDF
3. C:\SQLData\SQL_Backups dove sono memorizzati tutti i file di backup .BAK e .TRN

Quindi SQL Server funzionerà senza problemi. Ma se esegui una sorta di strumento che ti avvisa quando i dischi sono a corto di spazio, potrebbe controllare C: e non i volumi montati sotto di esso , quindi potresti non sapere quando quei punti di montaggio hanno poco spazio su disco. Inoltre, varie query "best practice" genereranno falsi avvisi che indicano che non si dovrebbero avere dati, registri e backup tutti sullo stesso disco perché SQL Server ritiene che si trovino sullo stesso disco. Quelle sono false flag e possono essere ignorate.

Ma in pratica vorresti impostare alcuni passaggi aggiuntivi nel monitoraggio del tuo server per assicurarti che l'unità C: disponga di spazio sufficiente e che anche ogni punto di montaggio lo faccia.

Le volte che ho usato i mount point in SQL Server, è stato l'unico problema in cui mi sono imbattuto: rapporti sullo stato del sistema di SQL Server che forniscono dati falsi sullo spazio libero disponibile e falsi errori che dicono che non dovresti avere tutti i tuoi dati sulla stessa unità. Dato che sai che si tratta di falsi errori, sono abbastanza facili da ignorare.

¹ SQL Server contiene dati che lo rendono consapevole del punto di montaggio, ma da un punto di vista pratico, non c'è differenza nel comportamento. "Funziona", affidandosi al sistema operativo per gestire le specifiche. Proprio come confida nel sistema operativo per gestire le specifiche per i LUN iSCSI collegati come unità locali.

Oltre al di CM_Dayton risposta e di Sean Gallardy risposta , una questione non ancora identificato con punti di montaggio è legato alla sicurezza. Per citare le linee guida per l'impostazione delle autorizzazioni SQL sulle cartelle dei punti di montaggio :

Sebbene le cartelle radice del punto di montaggio possano apparire come normali cartelle e vi si acceda nello stesso modo in cui si accede alle cartelle, non sono cartelle normali. Di conseguenza, quando si impostano le autorizzazioni su una cartella principale del punto di montaggio, le autorizzazioni non vengono ereditate dal "volume principale" allo stesso modo delle normali cartelle. In realtà, non sono affatto ereditati. Questo perché anche se sembra che il volume montato sia figlio del "volume principale", non lo è. Stai semplicemente accedendo al volume montato tramite un percorso dal "volume principale".

In poche parole, è necessario assegnare le autorizzazioni alle cartelle di montaggio in modo diverso se si desidera utilizzare la cartella principale del punto di montaggio. Invece di assegnare le autorizzazioni come faresti con una cartella normale, devi assegnare le autorizzazioni al volume. Ancora una volta, dallo stesso articolo (l'evidenziazione è di Microsoft):

Trabocchetti

Sfortunatamente, è ancora possibile impostare / visualizzare le autorizzazioni sulla cartella principale del punto di montaggio tramite Esplora risorse, il che può portare a risultati imprevisti perché le autorizzazioni della cartella principale del punto di montaggio possono sembrare valide e puoi vedere le autorizzazioni ereditate "appropriate" , tuttavia queste non sono le autorizzazioni applicate al volume montato.

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

Linee guida

1. Si consiglia di non inserire alcun file direttamente nella cartella principale del punto di montaggio . Ciò renderà la gestione delle autorizzazioni molto più semplice, poiché la tendenza è quella di controllare sempre le autorizzazioni della cartella, che in questo caso è fuorviante. Invece, creare una sottocartella nella cartella principale del punto di montaggio e impostare le autorizzazioni appropriate per quella sottocartella . Poiché la sottocartella è una cartella normale, le autorizzazioni per le cartelle osservate e impostate sono effettivamente le autorizzazioni applicate. Quindi, usando l'esempio precedente, vorrai creare una nuova cartella: D: \ FolderForVol3 ** SottocartellaXYZ **. Ora, imposta i permessi delle tue cartelle su quella nuova sottocartellaXYZ come faresti normalmente.
2. Se è assolutamente necessario posizionare gli elementi direttamente nella cartella principale del punto di montaggio (Non l'approccio consigliato), sarà necessario impostare le autorizzazioni del volume, non le autorizzazioni della cartella. Ricordiamo che ciò è dovuto al fatto che le autorizzazioni della cartella principale del punto di montaggio non sono le autorizzazioni che verranno effettivamente impostate sul volume montato (poiché la cartella principale del punto di montaggio non è una cartella reale). È possibile impostare le autorizzazioni per il volume come segue:
   • Start-> run-> diskmgmt.msc (Visualizza le proprietà di un volume http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Seleziona il volume-> Proprietà-> scheda Sicurezza
3. Se si sta aggiungendo una nuova cartella da utilizzare per SQL, tenere presente le autorizzazioni necessarie per l'accesso SQL:
   • A partire dalle autorizzazioni di SQL Server 2012 vengono assegnate al SID per servizio per ciascuno dei suoi servizi. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Configurare account e autorizzazioni del servizio Windows http://msdn.microsoft.com/en-us/library/ms143504.aspx

Se non si desidera nidificare tutto in una sottocartella sotto Mount Point come MS consiglia, il modo in cui trovo più semplice assegnare le autorizzazioni è tramite l' cacls.exeutilità. Istruzioni dettagliate sono disponibili in Non è possibile applicare le autorizzazioni alla directory principale di un volume del file system NTFS in Windows Server 2003 .

Non penso che sia ancora un problema completamente risolto. Questa recente domanda sull'installazione di SQL Server FCI con problemi di autorizzazioni Mount Point mostra che può ancora verificarsi su Windows 2012 con SQL Server 2016.

A seconda della sicurezza che si desidera assegnare, il comando può variare, ma il test è la chiave del successo, quindi familiarizzare con il comando prima di eseguirlo su un punto di montaggio attivo in quanto è possibile eseguire rapidamente la sicurezza se si dimentica qualcosa di semplice come la \Ebandiera.

Sulla base dei risultati di numerose ricerche su Internet non riesco a trovare alcun motivo (post-SQL Server 2000) per non utilizzare i punti di montaggio.

Il motivo principale è che qualcuno ha avuto una brutta esperienza con loro (o, al contrario, nessuna esperienza con loro) e li ha completamente respinti ... per sempre. Questo è altrimenti noto come preferenza personale.

Ora, ci sono alcuni motivi per cui non puoi usarli. Il motivo principale per cui riesco a pensare è che un driver o un'applicazione / strumento di terze parti (pensa al driver del filtro, alla replica del disco, ecc.) Non lo supporta. Un rapido esempio di ciò è uno strumento di replica del disco a livello di blocco che non supportava nulla diverso da NTFS, con solo dimensioni di cluster specifici e non poteva andare oltre 2 TB per qualsiasi volume specifico.

Qualcuno è a conoscenza delle limitazioni del sistema operativo Windows relative a questo argomento?

No. puoi fare molti, molti punti di montaggio. In effetti, in genere avrai un problema con le interfacce del tuo dispositivo prima di raggiungere un limite apprezzabile all'interno di Windows Server (Supponendo che non stai utilizzando una versione di Windows Server che ha più di 17 anni ...).

• Recentemente ho sentito l'affermazione "il sistema operativo non riconosce i punti di montaggio". (Falso, in base alla mia ricerca sulle versioni di Windows Server che utilizziamo).

Se il sistema operativo non riconoscesse i punti di montaggio, come ti permetterebbe di utilizzare un punto di montaggio? Non ha proprio senso.

Se il sistema operativo non riconosce i mount point, perché li dovrebbe tracciare e interrogare i loro metadati ? Inoltre, si noti che un mount point è un costrutto del filesystem che un sistema operativo può o meno supportare. Non tutti i filesystem che trovi possono supportare i mount point, tuttavia il filesystem più comune in Windows Server è NTFS che in realtà supporta i mount point e lo ha da un po 'di tempo.

Solo per portare questo oggetto falso a casa ancora di più; Il clustering di Windows ha qualcosa chiamato Cluster Shared Volumes (CSVs) che attualmente utilizza punti di montaggio per i volumi ... è un elemento nativo che utilizza la tecnologia. Devo dire che chiunque ti ha detto che questo deve essere istruito sulla questione.

Esiste un motivo basato sull'evidenza o sull'esperienza per NON utilizzare i mount point con SQL Server?

Sì, c'è sempre quel server che esegue Windows NT 4 ... non usarlo lì. Puoi anche assicurarti di eseguire una versione supportata di Windows Server e di rimanere aggiornato con gli aggiornamenti.

Tuttavia, come ho descritto sopra, potrebbero esserci elementi di terze parti che non sono supportati o che non funzionano correttamente con essi. Direi di abbandonare quel provider e trovarne uno nuovo.

Comprendo che i punti di montaggio sono incredibilmente utili per separare i carichi di lavoro.

I punti di mount sono incredibilmente utili. Esistono molti modi per usarli, il più comune è aggirare le limitazioni delle lettere di unità (come in, ce ne sono solo così tante) di Windows. Il prossimo uso più comune è quello di avere unità di dimensioni più piccole gestibili (pensa a LUN, disco virtuale [VMDK, VHDX]) per aiutare a liberarsi da volumi di monoliti follemente grandi e raramente gestibili (diventa davvero un problema gestire le unità nella gamma di 10 TB come un singolo LUN, disco virtuale, ecc.) in particolare su versioni precedenti di NTFS in cui l'implementazione era inferiore al possibile utilizzo ... ad esempio, nelle versioni precedenti di Windows la dimensione massima di NTFS era di 2 TB.

La segregazione del carico di lavoro è un altro grande uso. Puoi sicuramente vedere, ci sono molti usi e dipende dal tuo caso d'uso individuale. Ci sono anche modi impropri per usarlo ... come fare una dichiarazione generale che tutto deve essere un punto di montaggio. A quel punto è solo un folle sovraccarico amministrativo.

I mountpoint sono la strada da percorrere per i server che hanno applicazioni condivise o per suddividere i dati in più dei normali volumi DZ.

Ad esempio, è possibile installare tutti i dati delle applicazioni, i file di registro e temporanei e:sull'unità, ad esempio. E:/MP_1può avere file di dati per Business A, E:/MP_2può avere file di registro E:/mp_3può avere file temporanei per Business A e così via. Quindi hai Business B sui punti di mount sull'unità F:. Ogni punto di mount ha il suo spazio.

Il sistema operativo non ha assolutamente problemi con i parlamentari. I cluster e Always On non hanno problemi con i parlamentari. Ho lavorato per una banca molto nota che aveva la maggior parte dei loro server SQL installati su MP. Una volta che il DBA li utilizza e comprende i concetti, li spinge a soluzioni più semplici nei negozi che ne hanno bisogno.

Si è detto di non installare nulla sulla radice MP. È giusto. Nulla su root MP come te non installerebbe nulla sulla root di D come esempio.

Anche le soluzioni di controllo e monitoraggio come Foglight, Guardiam, EMS e PBM non hanno problemi con i mount point.