Диски против точек крепления?

12

Предыдущий старший администратор баз данных настраивал точки монтирования для всех наших дисков на всех серверах SQL в компании. Новый старший администратор базы данных в ужасе от точек монтирования хочет изменить наш стандарт (в основном, я думаю, потому что у него нет опыта работы с ними).

Основываясь на результатах многочисленных поисков в Интернете, я не могу найти ни одной (после SQL Server 2000) причины не использовать точки монтирования.

Кто-нибудь знает об ограничениях ОС Windows по этой теме?

  • В последнее время я часто слышал утверждение «ОС не распознает точки монтирования». (Неверно, основываясь на моих исследованиях версий Windows Server, которые мы используем).

Есть ли какая-либо основанная на доказательствах или опыте причина НЕ использовать точки монтирования с SQL Server?

  • Предположим, что нехватка букв дисков не является проблемой для нас.

Насколько я понимаю, точки монтирования невероятно полезны для разделения рабочих нагрузок.

Может ли кто-нибудь подтвердить или опровергнуть мое понимание того, что точки монтирования фактически разделяют / изолируют рабочие нагрузки различных типов данных и файлов журналов (файлов системной базы данных, файлов пользовательских баз данных, tempDB) более эффективно, чем один диск для файлов данных, файлов журналов и базы данных tempdb ?

SQL_Underworld
источник
Физическое хранилище в значительной степени абстрагируется, когда используется SAN. Независимо от того, используете ли вы букву диска или точку монтирования, вам нужно работать с администраторами хранилища, чтобы предоставить LUN необходимые характеристики. Ни SQL Server, ни ОС не будут знать о базовой конфигурации, хотя вы можете установить инструменты поставщика, чтобы обеспечить наглядность.
Дан Гузман

Ответы:

13

Это зависит от того, что находится на другом конце точки монтирования. Если монтируются все LUNS, распределенные по одним и тем же физическим дискам, выигрыша нет. Если LUNS расположены на общем медленном канале iSCSI, возможно, нет усиления. Если LUNS все под 1 контроллером ... вы видите, сколько переменных в игре. Там нет одного ответа.

Чтобы определить конфигурацию точек монтирования, см. Раздел « Определение точек монтирования с помощью PowerShell» от Boe Prox.


SQL Server не имеет проблем с точками монтирования. Они определены на уровне ОС, и SQL Server «не знает 1 », они не совпадают с томом, на котором они монтируются.

Однако некоторые инструменты мониторинга могут дать вам неверную информацию, основанную на последнем предложении.

Например, если у вас есть три точки монтирования, такие как

  1. C:\SQLData\SQL_Data где хранятся все ваши файлы .MDB
  2. C:\SQLData\SQL_Logs где хранятся все ваши файлы .LDF
  3. C:\SQLData\SQL_Backups где хранятся все ваши резервные файлы .BAK и .TRN

Тогда SQL Server будет работать без проблем. Но если вы запускаете какой-то инструмент, который предупреждает вас, когда дисков недостаточно, он может проверить C: а не смонтированные тома под ним , поэтому вы можете не знать, когда этим точкам монтирования мало места на диске. Кроме того, различные запросы «передового опыта» будут выдавать ложные предупреждения о том, что вы не должны хранить свои данные, журналы и резервные копии на одном диске, поскольку SQL Server считает, что они находятся на одном диске. Это ложные флаги, и их можно игнорировать.

Но вы, в основном, захотите настроить некоторые дополнительные шаги в мониторинге вашего сервера, чтобы убедиться, что на диске C: достаточно места и что каждая точка монтирования также имеет место.

Когда я использовал точки монтирования в SQL Server, это была единственная проблема, с которой я сталкивался: отчеты о работоспособности системы SQL Server, которые дают ложные данные о доступном свободном пространстве, и ложные ошибки о том, что у вас не должно быть всех ваших данных на том же диске. Поскольку вы знаете, что это ложные ошибки, их достаточно легко игнорировать.


1 В SQL Server есть данные, которые информируют его о точке монтирования, но с точки зрения практического использования нет различий в поведении. Он «просто работает», доверяя ОС справиться со спецификой. Так же, как она доверяет ОС для обработки спецификаций для iSCSI LUN, которые подключены как локальные диски.

СаМ
источник
2
Не уверен, что проблема с установкой SQL и ACL вокруг точек монтирования в корне диска все еще существует, но на всякий случай, вероятно, стоит поместить их в папку mountpoints. Пример: C: \ SQLMountPoints \ SQL_Data, C: \ SQLMountPoints \ SQL_Log
Nic
Правда. Однажды, когда я сделал это таким образом, у меня была папка «SQLDATA», а затем точки монтирования «data», «Log» и «backup». Или что-то в этом роде.
СаМ
8

В дополнении к CM_Dayton в ответ и Шон Gallardy в ответ , один вопрос еще не определен с точкой монтирования связан с безопасностью. Чтобы процитировать Рекомендации по установке разрешений SQL для папок точек монтирования :

Хотя корневые папки точки монтирования могут выглядеть как обычные папки и доступны так же, как и папки, они не являются обычными папками. В результате, когда вы устанавливаете разрешения для корневой папки точки монтирования, разрешения не наследуются от «родительского тома» так же, как обычные папки. На самом деле они вообще не наследуются. Это потому, что, хотя кажется, что подключенный том является дочерним по отношению к «родительскому тому», это не так. Вы просто получаете доступ к подключенному тому через путь от «родительского тома».

Короче говоря, вы должны назначить разрешения для папок монтирования по-разному, если вы хотите использовать корневую папку точки монтирования. Вместо того, чтобы назначать разрешения, как вы делаете с обычной папкой, вы должны назначить разрешение для тома. Опять же, из той же статьи (выделение от Microsoft):

Gotchas

К сожалению, все еще возможно устанавливать / просматривать разрешения для корневой папки точки монтирования через проводник Windows, что может привести к неожиданным результатам, поскольку разрешения для корневой папки точки монтирования могут показаться действительными, и вы можете увидеть «правильные» унаследованные разрешения однако это не те разрешения, которые применяются к подключенному тому.

Методические рекомендации

  1. Не рекомендуется размещать какие-либо файлы непосредственно в корневой папке точки монтирования . Это значительно упростит управление разрешениями, поскольку существует тенденция всегда проверять разрешения для папок, что в данном случае вводит в заблуждение. Вместо этого создайте подпапку в корневой папке точки монтирования и установите соответствующие разрешения для этой подпапки . Поскольку подпапка является обычной папкой, разрешения для папок, которые вы наблюдаете и устанавливаете, действительно применяются. Поэтому, используя предыдущий пример, вы захотите создать новую папку: D: \ FolderForVol3 ** SubfolderXYZ **. Теперь установите разрешения для вашей папки для этой новой папки SubfolderXYZ, как обычно.
  2. Если вам абсолютно необходимо поместить элементы непосредственно в корневую папку точки монтирования (не рекомендуется), то вам нужно будет установить разрешения для тома, а не для папки. Напомним, что это потому, что разрешения для корневой папки точки монтирования не являются разрешениями, которые фактически будут установлены на подключенном томе (поскольку корневая папка точки монтирования не является реальной папкой). Вы можете установить разрешения для тома следующим образом:
  3. Если вы добавляете новую папку для использования SQL, помните о необходимых разрешениях для доступа SQL:

Если вы не хотите вкладывать все в подпапку в точке монтирования, как рекомендует MS, я считаю, что проще всего назначать разрешения через cacls.exeутилиту. Подробные инструкции по этому вопросу можно найти в разделе Вы не можете применить разрешения к корневому каталогу тома файловой системы NTFS в Windows Server 2003 .

Я не думаю, что это полностью решенный вопрос. Этот недавний вопрос установки SQL Server FCI с проблемами разрешений точки монтирования показывает, что это все еще может произойти в Windows 2012 с SQL Server 2016.

В зависимости от того, какую защиту вы хотите назначить, команда может отличаться, но тестирование является ключом к успеху, поэтому ознакомьтесь с этой командой, прежде чем запускать ее для точки живого монтирования, поскольку вы можете быстро отключить защиту, если вы забудете что-то столь же простое, как \Eфлаг.

Джон Айсбренер
источник
Предыдущий старший администратор БД не знал об этой проблеме безопасности (ack!), И я не был ни до этого поста. Я собираюсь собрать запрос CMS, чтобы найти все затронутые файлы БД. Cacls кажется хорошим маршрутом (хотя я собираюсь искать что-нибудь на основе PoSh). @JohnEisbrener - у вас были проблемы с настройкой списков ACL для файлов БД, когда они заблокированы для исключительного использования? Если так, каков следующий шаг?
SQL_Underworld
1
@SQL_Underworld, я бы порекомендовал сделать что-нибудь с cacls во время окна обслуживания, во время которого вы можете перевести экземпляр базы данных в автономный режим. Хотя, вероятно, в этом нет необходимости , это уменьшит количество переменных, которые могут произойти.
Джон Эйсбренер,
8

На основании результатов многочисленных поисков в Интернете я не могу найти ни одной (после SQL Server 2000) причины не использовать точки монтирования.

Основная причина в том, что у кого-то был плохой опыт с ними (или, наоборот, никакого опыта с ними), и он полностью изгнал их ... навсегда. Это также известно как личные предпочтения.

Теперь, есть есть некоторые причины , по которым вы не могли бы использовать их. Причина, по которой я могу придумать, заключается в том, что сторонний драйвер или приложение / инструмент (например, драйвер фильтра, репликация диска и т. Д.) Не поддерживают его. В качестве примера можно привести средство репликации дисков на уровне блоков, которое не поддерживало ничего, кроме NTFS, только с определенными размерами кластеров и не могло превышать 2 ТБ для любого конкретного тома.

Кто-нибудь знает об ограничениях ОС Windows по этой теме?

Нет, вы можете сделать много, много точек монтирования. На самом деле, у вас, как правило, будут проблемы с интерфейсами вашего устройства, прежде чем вы достигнете какого-либо заметного предела внутри Windows Server (при условии, что вы не используете версию Windows Server старше 17 лет ...).

• В последнее время я часто слышал утверждение «ОС не распознает точки монтирования». (Неверно, основываясь на моих исследованиях версий Windows Server, которые мы используем).

Если ОС не распознает точки монтирования, то как она вообще позволит вам использовать точку монтирования? Это просто не имеет смысла.

Если ОС не распознает точки монтирования, почему она отслеживает их и запрашивает их метаданные ? Также обратите внимание, что точка монтирования - это структура файловой системы, которую ОС может поддерживать или не поддерживать. Не все файловые системы, с которыми вы сталкиваетесь, могут поддерживать точки монтирования, однако наиболее распространенной файловой системой в Windows Server является NTFS, которая на самом деле поддерживает точки монтирования, и это имеет некоторое время.

Просто, чтобы принести этот ложный предмет домой еще дальше; В кластеризации Windows есть нечто, называемое общими томами кластера (CSV), которые на самом деле используют точки монтирования для томов ... это встроенный элемент, использующий технологию. Я должен сказать, кто бы вам ни сказал, это нужно прояснить.

Есть ли какая-либо основанная на доказательствах или опыте причина НЕ использовать точки монтирования с SQL Server?

Да, всегда есть один сервер под управлением Windows NT 4 ... не используйте его там. Вы также можете убедиться, что вы используете поддерживаемую версию Windows Server и постоянно обновляетесь.

Однако, как я описал выше, могут быть сторонние элементы, которые не поддерживаются или не работают с ними должным образом. Я бы сказал, что брось этого провайдера и найди нового.

Насколько я понимаю, точки монтирования невероятно полезны для разделения рабочих нагрузок.

Точки крепления просто невероятно полезны. Есть много способов их использования, самый распространенный - обойти ограничения буквы диска (как, например, в Windows). Следующее наиболее распространенное использование - иметь диски меньшего размера, которыми можно управлять (например, логические устройства, виртуальные диски [VMDK, VHDX]), чтобы помочь избавиться от безумно больших и редко управляемых монолитных томов (действительно становится проблемой управлять дисками в диапазоне 10 ТБ, поскольку один LUN, виртуальный диск и т. д.), особенно в старых версиях NTFS, где реализация была меньше возможного использования ... например, в старых версиях Windows максимальный размер NTFS составлял 2 ТБ.

Разделение рабочей нагрузки - еще одно полезное применение. Вы можете определенно увидеть, что есть много вариантов использования, и это зависит от вашего индивидуального варианта использования. Существуют также неподходящие способы его использования ... например, общее утверждение, что все должно быть точкой монтирования. Это просто сумасшедшие административные издержки на тот момент.

Шон Галларди
источник
3

Точки монтирования - это способ использовать серверы с общими приложениями или разделять данные на более чем обычные тома DZ.

Например, вы можете установить все данные приложений, журналы и временные файлы, например, на e:диск. E:/MP_1может иметь файлы данных для Business A, E:/MP_2может иметь файлы журнала, E:/mp_3может иметь временные файлы для Business A и так далее. Тогда у вас есть Business B в точках монтирования на F:диске. Каждая точка монтирования имеет свое собственное пространство.

У ОС абсолютно нет проблем с депутатами. Кластеры и Always On не имеют проблем с депутатами. Я работал в очень известном банке, в котором большинство их SQL-серверов были установлены на MP. Как только администратор базы данных использует их и понимает концепции, он будет предлагать им более простые решения в тех магазинах, которые в этом нуждаются.

Было упомянуто, чтобы ничего не устанавливать в корне MP. Это верно. Ничто в MP root, как вы не установили бы ничего в корень D в качестве примера.

Решения для аудита и мониторинга, такие как Foglight, Guardiam, EMS и PBM, также не имеют проблем с точками монтирования.

Shellz
источник