Laufwerke vs. Mount Points?

Der vorherige Senior DBA hat Bereitstellungspunkte für alle unsere Laufwerke auf jedem SQL Server im gesamten Unternehmen eingerichtet. Der neue Senior DBA ist entsetzt über Mount Points , die unseren Standard ändern wollen (hauptsächlich denke ich, weil er keine Erfahrung mit ihnen hat).

Aufgrund der Ergebnisse zahlreicher Internetsuchen kann ich keinen (nach SQL Server 2000) Grund finden, Mount-Punkte nicht zu verwenden.

Kennt jemand Einschränkungen des Windows-Betriebssystems in Bezug auf dieses Thema?

• Ich habe in letzter Zeit oft die Behauptung gehört, dass das Betriebssystem Mount-Punkte nicht erkennt. (Nicht wahr, basierend auf meinen Recherchen zu den Versionen von Windows Server, die wir verwenden).

Gibt es einen evidenz- oder erfahrungsbasierten Grund, Mount-Punkte NICHT mit SQL Server zu verwenden?

• Nehmen wir an, dass es für uns kein Problem ist, keine Laufwerksbuchstaben mehr zu haben.

Ich verstehe, dass Bereitstellungspunkte unglaublich nützlich sind, um Workloads zu trennen.

Kann jemand mein Verständnis bestätigen oder widerlegen, dass Bereitstellungspunkte Workloads der verschiedenen Arten von Daten und Protokolldateien (Systemdatenbankdateien, Benutzerdatenbankdateien, tempDB) effizienter trennen / isolieren als jeweils ein Laufwerk für Datendateien, Protokolldateien und tempdb? ?

Dies hängt davon ab, was sich am anderen Ende des Einhängepunkts befindet. Wenn die Bereitstellungen alle LUNS sind, die auf die gleichen physischen Laufwerke verteilt sind, werden keine Gewinne erzielt. Wenn sich die LUNs auf einem gemeinsam genutzten, langsamen iSCSI-Kanal befinden, sind möglicherweise keine Gewinne zu verzeichnen. Wenn die LUNS alle unter 1 Controller sind ... sehen Sie, wie viele Variablen im Spiel sind. Es gibt keine Antwort.

Informationen zum Ermitteln der Konfiguration der Bereitstellungspunkte finden Sie unter Ermitteln der Bereitstellungspunkte mithilfe von PowerShell von Boe Prox.

SQL Server hat kein Problem mit Einhängepunkten. Diese werden auf Betriebssystemebene definiert, und SQL Server "weiß nicht ¹ " hat nicht dasselbe Volume wie das Laufwerk, auf dem sie anscheinend bereitgestellt sind.

Einige Überwachungstools geben Ihnen jedoch möglicherweise schlechte Informationen basierend auf diesem letzten Satz.

Zum Beispiel, wenn Sie drei Einhängepunkte wie haben

1. C:\SQLData\SQL_Data wo alle Ihre .MDB-Dateien gespeichert sind
2. C:\SQLData\SQL_Logs wo alle Ihre .LDF-Dateien gespeichert sind
3. C:\SQLData\SQL_Backups Hier werden alle Ihre .BAK- und .TRN-Sicherungsdateien gespeichert

Dann funktioniert SQL Server ohne Probleme. Wenn Sie jedoch ein Tool ausführen, das Sie warnt, wenn der Speicherplatz auf den Datenträgern knapp wird, wird möglicherweise das C: und nicht die bereitgestellten Volumes darunter überprüft , sodass Sie möglicherweise nicht wissen, wann diese Bereitstellungspunkte nur noch wenig Speicherplatz haben. Außerdem werden bei verschiedenen "Best Practices" -Abfragen falsche Warnungen ausgegeben, die Sie darauf hinweisen, dass sich Ihre Daten, Protokolle und Sicherungen nicht auf demselben Datenträger befinden sollten, da SQL Server denkt, dass sie sich auf demselben Datenträger befinden. Das sind falsche Flags und können ignoriert werden.

Grundsätzlich sollten Sie jedoch einige zusätzliche Schritte für die Serverüberwachung einrichten, um sicherzustellen, dass auf dem Laufwerk C: genügend Speicherplatz vorhanden ist und jeder Bereitstellungspunkt dies auch tut.

Die Zeiten, in denen ich Bereitstellungspunkte in SQL Server verwendet habe, waren das einzige Problem, auf das ich gestoßen bin: SQL Server-Systemzustandsberichte, die falsche Daten über den verfügbaren Speicherplatz und falsche Fehler enthalten, die besagen, dass Sie nicht alle Daten haben sollten auf dem gleichen Laufwerk. Da Sie wissen, dass es sich um falsche Fehler handelt, können Sie diese leicht ignorieren.

¹ SQL Server verfügt über Daten, die ihn auf den Bereitstellungspunkt aufmerksam machen, aber aus praktischer Sicht gibt es keinen Unterschied im Verhalten. Es "funktioniert einfach" und vertraut darauf, dass das Betriebssystem mit den Besonderheiten fertig wird. Genauso wie es dem Betriebssystem vertraut, um die Besonderheiten für iSCSI-LUNs zu behandeln, die als lokale Laufwerke verbunden sind.

Zusätzlich zu CM_Daytons Antwort und Sean Gallardys Antwort bezieht sich ein Problem, das noch nicht mit Mount Points identifiziert wurde, auf die Sicherheit. So zitieren Sie Richtlinien zum Festlegen von SQL-Berechtigungen für Bereitstellungspunktordner :

Obwohl die Mount-Point-Stammordner wie normale Ordner aussehen und auf die gleiche Weise wie auf Ordner zugegriffen wird, handelt es sich nicht um normale Ordner. Wenn Sie Berechtigungen für einen Mount-Point-Stammordner festlegen, werden Berechtigungen daher nicht auf dieselbe Weise wie für normale Ordner vom übergeordneten Volume geerbt. Tatsächlich werden sie überhaupt nicht vererbt. Dies liegt daran, dass es sich bei dem bereitgestellten Volume anscheinend um ein untergeordnetes Volume des übergeordneten Volume handelt, dies jedoch nicht. Sie greifen einfach über einen Pfad vom übergeordneten Volume auf das bereitgestellte Volume zu.

Kurz gesagt, müssen Sie Mount-Ordnern Berechtigungen auf andere Weise zuweisen, wenn Sie den Mount-Point-Stammordner verwenden möchten. Anstatt Berechtigungen wie in einem normalen Ordner zuzuweisen, müssen Sie Berechtigungen für das Volume zuweisen. Aus demselben Artikel (Hervorhebung von Microsoft):

Fallstricke

Leider ist es immer noch möglich, Berechtigungen für den Mount-Point-Stammordner über Windows Explorer festzulegen / anzuzeigen. Dies kann zu unerwarteten Ergebnissen führen, da die Berechtigungen des Mount-Point-Stammordners möglicherweise gültig erscheinen und Sie "richtige" geerbte Berechtigungen sehen können Dies sind jedoch nicht die Berechtigungen, die auf das bereitgestellte Volume angewendet werden.

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

Richtlinien

1. Es wird empfohlen, keine Dateien direkt im Einhängepunkt-Stammordner abzulegen . Dies vereinfacht die Berechtigungsverwaltung erheblich, da die Ordnerberechtigungen in der Regel immer überprüft werden, was in diesem Fall irreführend ist. Erstellen Sie stattdessen einen Unterordner unter dem Einhängepunkt-Stammordner und legen Sie die entsprechenden Berechtigungen für diesen Unterordner fest . Da es sich bei dem Unterordner um einen normalen Ordner handelt, werden die von Ihnen beobachteten und festgelegten Ordnerberechtigungen tatsächlich angewendet. Wenn Sie also das vorherige Beispiel verwenden, möchten Sie einen neuen Ordner erstellen: D: \ FolderForVol3 ** SubfolderXYZ **. Stellen Sie nun Ihre Ordnerberechtigungen wie gewohnt für diesen neuen Unterordner XYZ ein .
2. Wenn Sie Elemente unbedingt direkt im Einhängepunkt-Stammordner ablegen müssen (nicht die empfohlene Vorgehensweise), müssen Sie Volume-Berechtigungen und keine Ordnerberechtigungen festlegen. Denken Sie daran, dass dies darauf zurückzuführen ist, dass die Berechtigungen für den Mount-Point-Stammordner nicht die Berechtigungen sind, die tatsächlich für das gemountete Volume festgelegt werden (da der Mount-Point-Stammordner kein echter Ordner ist). Sie können Volume-Berechtigungen wie folgt festlegen:
   • Start-> run-> diskmgmt.msc (Anzeigen der Eigenschaften eines Volumes http://technet.microsoft.com/en-us/library/cc740097.aspx )
   • Wählen Sie die Registerkarte Volume-> Properties-> Security
3. Wenn Sie einen neuen Ordner für SQL hinzufügen, müssen Sie die erforderlichen Berechtigungen für den SQL-Zugriff kennen:
   • Ab SQL Server 2012 werden Berechtigungen für jeden seiner Dienste der SID pro Dienst zugewiesen. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Konfigurieren Sie Windows-Dienstkonten und -Berechtigungen http://msdn.microsoft.com/en-us/library/ms143504.aspx

Wenn Sie nicht, wie von MS empfohlen, alles in einem Unterordner unter dem Mount Point verschachteln möchten, lassen sich die Berechtigungen meiner Meinung nach am einfachsten über das cacls.exeDienstprogramm zuweisen . Detaillierte Anweisungen hierzu finden Sie unter Sie können keine Berechtigungen für das Stammverzeichnis eines NTFS-Dateisystemvolumes in Windows Server 2003 anwenden .

Ich denke, es ist noch kein vollständig gelöstes Problem. Diese kürzlich gestellte Frage zur Installation von SQL Server FCI mit Problemen mit Mount Point-Berechtigungen zeigt, dass dies unter Windows 2012 mit SQL Server 2016 weiterhin möglich ist.

Abhängig von der Sicherheit, die Sie zuweisen möchten, kann der Befehl variieren. Das Testen ist jedoch der Schlüssel zum Erfolg. Machen Sie sich mit dem Befehl vertraut, bevor Sie ihn auf einem aktiven Mount-Punkt ausführen \E.

Aufgrund der Ergebnisse zahlreicher Internetsuchen kann ich keinen (nach SQL Server 2000) Grund finden, Mount-Punkte nicht zu verwenden.

Der Hauptgrund ist, dass jemand eine schlechte Erfahrung mit ihnen gemacht hat (oder umgekehrt keine Erfahrung mit ihnen) und sie komplett weggeritten hat ... für immer. Dies wird ansonsten als persönliche Präferenz bezeichnet.

Es gibt einige Gründe, aus denen Sie sie nicht verwenden konnten. Der Hauptgrund, an den ich denken kann, ist, dass ein Treiber oder eine Anwendung / ein Tool von Drittanbietern (z. B. Filtertreiber, Festplattenreplikation usw.) dies nicht unterstützt. Ein kurzes Beispiel hierfür ist ein Festplattenreplikationstool auf Blockebene, das nichts anderes als NTFS mit nur bestimmten Clustergrößen unterstützte und für kein bestimmtes Volume mehr als 2 TB erreichen konnte.

Kennt jemand Einschränkungen des Windows-Betriebssystems in Bezug auf dieses Thema?

Nein, Sie können viele, viele Einhängepunkte machen. Tatsächlich treten in der Regel Probleme mit den Geräteschnittstellen auf, bevor Sie innerhalb von Windows Server eine nennenswerte Grenze erreichen (vorausgesetzt, Sie verwenden keine Version von Windows Server, die älter als 17 Jahre ist ...).

• Ich habe in letzter Zeit häufig die Behauptung gehört, dass das Betriebssystem Mount-Punkte nicht erkennt. (Nicht wahr, basierend auf meinen Recherchen zu den Versionen von Windows Server, die wir verwenden).

Wenn das Betriebssystem Mount-Punkte nicht erkennt, wie können Sie dann überhaupt einen Mount-Punkt verwenden? Das macht einfach keinen Sinn.

Wenn das Betriebssystem Mount-Punkte nicht erkennt, warum sollte es sie dann verfolgen und ihre Metadaten abfragen ? Beachten Sie auch, dass ein Mount-Punkt ein Konstrukt des Dateisystems ist, das ein Betriebssystem möglicherweise unterstützt oder nicht. Möglicherweise unterstützen nicht alle Dateisysteme, auf die Sie stoßen, Bereitstellungspunkte. Das häufigste Dateisystem in Windows Server ist jedoch NTFS, das tatsächlich Bereitstellungspunkte unterstützt und dies schon seit einiger Zeit tut .

Nur um diesen unwahren Gegenstand noch weiter nach Hause zu bringen; Windows Clustering verfügt über so genannte Cluster Shared Volumes (CSVs), die tatsächlich Bereitstellungspunkte für die Volumes verwenden. Dies ist ein systemeigenes Element, das Technologie verwendet. Ich muss sagen, wer auch immer Ihnen das gesagt hat, muss in der Ausgabe erzogen werden.

Gibt es einen evidenz- oder erfahrungsbasierten Grund, Mount-Punkte NICHT mit SQL Server zu verwenden?

Ja, es gibt immer einen Server, auf dem Windows NT 4 ausgeführt wird. Verwenden Sie ihn dort nicht. Möglicherweise möchten Sie auch sicherstellen, dass Sie eine unterstützte Version von Windows Server ausführen und mit Updates auf dem neuesten Stand sind.

Wie oben beschrieben, gibt es jedoch möglicherweise Elemente von Drittanbietern, die nicht unterstützt werden oder nicht ordnungsgemäß mit ihnen funktionieren. Ich würde sagen, lass den Anbieter fallen und finde einen neuen.

Ich verstehe, dass Bereitstellungspunkte unglaublich nützlich sind, um Workloads zu trennen.

Einhängepunkte sind einfach unglaublich nützlich. Es gibt viele Möglichkeiten, sie zu verwenden. Die häufigste besteht darin, die Laufwerksbuchstabenbeschränkungen (wie es nur so viele gibt) von Windows zu umgehen. Die zweithäufigste Verwendung ist die Verwendung kleinerer Laufwerke (z. B. LUNs, virtueller Datenträger [VMDK, VHDX]), um von wahnsinnig großen und selten verwaltbaren Monolith-Volumes Abstand zu gewinnen (die Verwaltung von Laufwerken im Bereich von 10 TB wird zu einem echten Problem) eine einzelne LUN, ein virtuelles Laufwerk usw.), insbesondere bei älteren Versionen von NTFS, bei denen die Implementierung geringer war als die mögliche Nutzung. In älteren Windows-Versionen betrug die maximale NTFS-Größe beispielsweise 2 TB.

Die Trennung der Arbeitsbelastung ist eine weitere nützliche Funktion. Sie können definitiv sehen, dass es viele Verwendungen gibt und dies von Ihrem individuellen Anwendungsfall abhängt. Es gibt auch unangemessene Verwendungsmöglichkeiten ... z. B. die pauschale Aussage, dass alles ein Mountpunkt sein muss. Das ist zu diesem Zeitpunkt nur verrückter Verwaltungsaufwand.

Mountpunkte sind der Weg zu Servern mit gemeinsam genutzten Anwendungen oder zum Aufteilen von Daten auf mehr als nur die typischen DZ-Volumes.

Beispielsweise können Sie alle Anwendungsdaten, Protokoll- und temporären Dateien auf dem e:Laufwerk installieren . E:/MP_1Kann Datendateien für Business A haben, E:/MP_2kann die Protokolldateien haben, E:/mp_3kann temporäre Dateien für Business A haben und so weiter. Dann befindet sich Business B auf den Einhängepunkten des F:Laufwerks. Jeder Einhängepunkt verfügt über einen eigenen Bereich.

Das Betriebssystem hat absolut keine Probleme mit MPs. Cluster und Always On haben keine Probleme mit MPs. Ich arbeitete für eine sehr bekannte Bank, bei der der Großteil ihrer SQL Server auf MPs installiert war. Sobald der DBA sie verwendet und die Konzepte verstanden hat, werden sie zu einfacheren Lösungen in Geschäften geführt, die sie benötigen.

Es wurde erwähnt, nichts auf dem MP-Root zu installieren. Das ist richtig. Nichts auf MP root, so wie Sie nichts als Beispiel auf dem Root von D installieren würden.

Prüf- und Überwachungslösungen wie Foglight, Guardiam, EMS und PBM haben ebenfalls keine Probleme mit Einhängepunkten.