Диски проти очок Маунт?


12

Попередній Senior DBA встановлював точки монтажу для всіх наших дисків на кожному SQL Server у всій компанії. Новий старший DBA жахнувся точками кріплення, хоче змінити наш стандарт (головним чином, я думаю, тому що він не має з ними досвіду).

На основі результатів численних пошуків в Інтернеті я не можу знайти жодної причини (після SQL Server 2000), щоб не використовувати точки монтажу.

Хтось знає обмеження ОС Windows щодо цієї теми?

  • Останнім часом я чую твердження, що "ОС не розпізнає точки кріплення". (Неправда, ґрунтуючись на моєму дослідженні використовуваних нами версій Windows Server).

Чи є причина, що ґрунтується на доказах чи досвіді, НЕ використовувати точки монтажу з SQL Server?

  • Припустимо, що закінчення букв на диску не є проблемою для нас.

Я розумію, що точки монтажу неймовірно корисні для розмежування навантажень.

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


Фізичне зберігання значною мірою абстрагується, коли використовується 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 навколо точок монтажу в корені диска, але, напевно, варто вставити їх у папку монтажних точок на всякий випадок. Приклад: C: \ SQLMountPoints \ SQL_Data, C: \ SQLMountPoints \ SQL_Log
Nic

Правда. Коли я зробив це таким чином, у мене була папка "SQLDATA", потім "дані", "Журнал" та "резервне копіювання" під цим пунктом кріплення. Або щось для цього.
CaM

8

У доповненні до CM_Dayton в відповідь і Шон Gallardy в відповідь , одне питання ще не визначений з точкою монтування пов'язаний з безпекою. Процитуйте Правила щодо встановлення дозволів SQL для папок Mount Mount :

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

У двох словах, ви повинні призначити дозволи на папки Монтажу по-різному, якщо ви хочете використовувати кореневу папку точки монтажу. Замість призначення дозволів, як ви робили зі звичайною папкою, вам потрібно призначити дозвіл на гучність. Знову ж із тієї самої статті (виділення - це Microsoft):

Gotchas

На жаль, все ще можливо встановити / переглянути дозволи в кореневій папці точки монтування за допомогою Провідника Windows, що може призвести до несподіваних результатів, оскільки дозволи кореневої папки точки монтажу можуть здатися дійсними, і ви можете побачити "належні" успадковані дозволи однак це не дозволи, застосовані до встановленого тому.

Керівні принципи

  1. Рекомендується не розміщувати жодних файлів безпосередньо в кореневій папці точки монтажу . Це зробить управління дозволами набагато простішим, оскільки тенденція полягає у тому, щоб завжди перевіряти права доступу до папок, що в цьому випадку вводить в оману. Натомість створіть підпапку в кореневій папці точки монтажу та встановіть для неї відповідну дозволу . Оскільки підпапка є звичайною папкою, дозволи, які ви спостерігаєте та встановлюєте, дійсно є дозволами, які застосовуються. Отже, використовуючи попередній приклад, ви хочете створити нову папку: D: \ FolderForVol3 ** ПідпапкаXYZ **. Тепер встановіть дозволи вашої папки відповідно до нової папки SubfolderXYZ, як зазвичай.
  2. Якщо ви обов'язково повинні розміщувати елементи безпосередньо в кореневій папці точки монтажу (Не рекомендується підхід), тоді вам потрібно буде встановити дозволи гучності, а не дозволи на папки. Нагадаємо, це тому, що дозволи кореневої папки точки монтажу не є дозволами, які фактично будуть встановлені на встановленому томі (оскільки коренева папка точки монтажу не є реальною папкою). Ви можете встановити дозволи на гучність так:
  3. Якщо ви додаєте нову папку для використання SQL, пам’ятайте про необхідні дозволи для доступу до SQL:

Якщо ви не хочете вкладати все в папку під Mount Point, як рекомендує MS, я вважаю, що найпростіше призначити дозволи через cacls.exeслужбову програму. Детальну інструкцію щодо цього можна знайти в розділі Ви не можете застосовувати дозволи до кореневого каталогу тома файлової системи NTFS в Windows Server 2003 .

Я не думаю, що це ще повністю вирішене питання. Це нещодавнє питання встановлення FCI SQL Server із проблемами дозволів Mount Point показує, що це все ще може відбуватися в Windows 2012 із SQL Server 2016

Залежно від того, яку безпеку ви хочете призначити, команда може змінюватись, але тестування є ключовим для успіху, тому ознайомтеся з командою перед тим, як запустити її на точку монтажу в реальному часі, оскільки ви швидко зможете захистити безпеку, якщо забудете щось таке просте, як \Eпрапор.


Попередній старший DBA не знав про цю проблему безпеки (ну!), І я не був до цього часу. Я збираюся скласти CMS-запит, щоб знайти всі пошкоджені файли db. Cacls здається гарним маршрутом (хоча я збираюся шукати щось на базі PoSh). @JohnEisbrener - у вас виникли проблеми з налаштуванням ACL-файлів на db-файли, коли вони були заблоковані в ексклюзивному використанні? Якщо так, то який наступний крок?
SQL_Underworld

1
@SQL_Underworld, я б рекомендував робити що-небудь з cacls під час вікна технічного обслуговування, під час якого ви можете взяти екземпляр бази даних в автономному режимі. Хоча це, мабуть, не є необхідним , це зменшить кількість змінних, які можуть статися.
Джон Ейсбренер

8

На основі результатів численних пошуків в Інтернеті я не можу знайти жодної причини (після SQL Server 2000), щоб не використовувати точки монтажу.

Основна причина - хтось із ними поганий досвід (або, навпаки, з ними немає досвіду) і повністю позбавив їх… назавжди. Це інакше відоме як особисті переваги.

Тепер є деякі причини, що ви не можете їх використовувати. Причиною номер один, про яку я можу подумати, є те, що драйвер або програма / інструмент сторонніх виробників (драйвер фільтру, реплікація диска тощо) не підтримують його. Швидкий приклад цього - інструмент реплікації дискового рівня на рівні блоку, який не підтримував нічого, крім NTFS, лише з певними розмірами кластерів і не міг перевищувати 2 ТБ для будь-якого конкретного обсягу.

Хтось знає обмеження ОС Windows щодо цієї теми?

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

• Останнім часом я чую твердження, що "ОС не розпізнає точки кріплення". (Неправда, ґрунтуючись на моєму дослідженні використовуваних нами версій Windows Server).

Якщо ОС не розпізнавала точки монтажу, то як би вона навіть дозволила вам використовувати точку монтування? Це просто не має сенсу.

Якщо ОС не розпізнає точки монтажу, чому б вона відстежувала їх і запитувала їх метадані ? Також врахуйте, що точка монтування - це конструкція файлової системи, яку ОС може підтримувати або не підтримувати. Не всі файлові системи, на які ви стикаєтеся, можуть підтримувати точки монтажу, проте найпоширенішою файловою системою в Windows Server є NTFS, яка насправді підтримує точки монтажу, і вона має деякий час.

Тільки щоб ще більше принести цей неправдивий предмет додому; У Windows Clustering є щось, що називається Cluster Shared Volumes (CSVs), яке фактично використовує точки монтажу для томів ... це рідний елемент з використанням технології. Я мушу сказати, хто б вам не говорив, про це потрібно ознайомитись із цим питанням.

Чи є причина, що ґрунтується на доказах чи досвіді, НЕ використовувати точки монтажу з SQL Server?

Так, завжди є один сервер під управлінням Windows NT 4 ... не використовуйте його там. Ви також можете переконатися, що ви підтримуєте підтримувану версію Windows Server і залишаєтеся в курсі оновлень.

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

Я розумію, що точки монтажу неймовірно корисні для розмежування навантажень.

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

Сегрегація робочого навантаження - ще одне чудове використання. Ви, звичайно, можете побачити, що використання багато, і це залежить від вашого індивідуального випадку використання. Існують також неправильні способи його використання ... наприклад, зробити ковдру, що все має бути точкою монтажу. Це просто божевільні адміністративні витрати на той момент.


3

Точки горі - це шлях для серверів, які мають спільні додатки, або для нарізання даних більше, ніж просто типових томів DZ.

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

У ОС абсолютно немає проблем з депутатами. Кластери та Завжди увімкнені не мають проблем з депутатами. Я працював у дуже відомому банку, який мав більшість своїх SQL-серверів, встановлених на MP. Як тільки DBA їх використовуватиме і розбирається з концепціями, це підштовхне їх до більш легких рішень у магазинах, які цього потребують.

Згадувалося, що нічого не встановлювати на корінь MP. Це правильно. Нічого в корені MP так само, як ви б нічого не встановлювали в корінь D як приклад.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.