Не звертайте уваги на той SAN за завісою

Колись я будував власні SQL-сервери та мав контроль над конфігурацією накопичувача, рівнями RAID тощо. Традиційні поради щодо розділення даних, журналів, tempdb, резервного копіювання (залежно від бюджету!) Завжди були досить важливою частиною процесу проектування сервера SQL.

Тепер із SAN на рівні підприємства я просто запитую певну кількість дискового простору для нового SQL-сервера, розділеного на логічні диски для даних, резервного копіювання та файлообміну. Звичайно, моя робота легша, але є частина мене, яка не відчуває себе повністю комфортно, що я не можу по-справжньому зазирнути "за завісу", щоб побачити, що насправді відбувається там.

Я розумію, що команда SAN не налаштовує різні "типи" накопичувачів по-різному (оптимізуючи накопичувачі даних для випадкового доступу проти журналів для потокового запису). Частина цього може залежати від самого продукту SAN (у нас є HP XP12000 та HP XP24000), але я був впевнений, що програмне забезпечення HP робить всілякі конфігурації динамічної продуктивності (перегляд точок доступу IO та перенастроювання на ходу для оптимізуйте ці LUN), так що командам додатків та DBA не потрібно турбуватися про будь-який із цих матеріалів. Щось про "розповсюдження навантаження всіх серверів на величезну кількість шпинделів" чи щось подібне.

Мої запитання / обговорення:

1. Як не робити ворогів у команді SAN, як я можу запевнити себе та розробників додатків, що наші сервери SQL не страждають від погано налаштованого сховища? Просто використовувати статистику perfmon? Інші орієнтири, такі як sqlio?

2. Якщо я завантажую тест на ці накопичувачі SAN, чи справді це дає мені надійну, повторювану міру того, що я побачу, коли ми продовжимо жити? (припускаючи, що програмне забезпечення SAN може "динамічно конфігуруватися" по-різному в різні моменти часу.)

3. Чи впливає важкий IO в одній частині SAN (скажімо, сервер Exchange) на мої сервери SQL? (якщо припустити, що вони не дають виділених дисків кожному серверу, що мені сказали, що вони не є)

4. Чи допоможе тут запит на розділення логічних накопичувачів для різних функцій логічних накопичувачів (data vs log vs tempdb)? Чи бачила б SAN різну активність вводу-виводу на них і оптимально налаштовувала їх по-різному?

5. Зараз ми трохи в просторі. Командам додатків пропонують обробляти архіви даних тощо. Чи можуть проблеми з простором спричинити команду SAN приймати різні рішення про те, як вони налаштовують внутрішнє сховище (рівні RAID тощо), що може вплинути на роботу мого сервера?

Дякуємо за ваші думки (подібна тема коротко обговорена в цьому питанні SF )

Як не створювати ворогів команді SAN, як я можу запевнити себе та розробників додатків, що наші сервери SQL не страждають від погано налаштованого сховища? Просто використовувати статистику perfmon? Інші орієнтири, такі як sqlio?

Коротше кажучи, напевно немає способу бути справді впевненим. Що б я сказав (я адміністратор SAN), це те, що якщо ваші програми відповідають вашим очікуванням, не переживайте про це. Якщо ви почнете бачити проблеми з продуктивністю, які, на вашу думку, можуть бути пов'язані з виконанням SAN / Disk IO, то, можливо, було б цікаво запитати. Я не використовую багато пам’яті HP, як ви, але у світі IBM / NetApp я можу сказати з досвіду, що існує не так багато варіантів, які дозволять вам налаштувати його «погано». Більшість корпоративних сховищ сьогодні вимагає багато здогадок про створення рейдових масивів, і насправді це не дозволяє вам робити це неправильно. Якщо вони не змішують швидкість та потужність приводу в межах однієї групи рейдів, ви можете бути впевнені в більшості випадків, що ваш диск працює нормально.

Якщо я завантажую тест на ці накопичувачі SAN, чи справді це дає мені надійну, повторювану міру того, що я побачу, коли ми продовжимо жити? (припускаючи, що програмне забезпечення SAN може "динамічно конфігуруватися" по-різному в різні моменти часу.)

Тестування навантаження має бути достатньо надійним. Просто майте на увазі, що, коли ви завантажуєте тестування одного вікна, на перебування в спільному SAN / Disk масиві, що на його продуктивність можуть (і будуть) впливати інші системи, що використовують ті ж сховища.

Чи впливає важкий IO в одній частині SAN (скажімо, сервер Exchange) на мої сервери SQL? (якщо припустити, що вони не дають виділених дисків кожному серверу, що мені сказали, що вони не є)

Це може. Справа не в тому, що стосується дисків чи тих дисків, на яких серверах. Усі дані подаються через контролер диска, а потім комутатор SAN. Продуктивність, яку ви побачите, значно залежить від того, як підключений дисковий контролер до відповідних полиць дисків і відповідних SAN. Якщо весь масив підключиться до магістральної SAN на одній ланцюжку волокна 4 Гбіт / с, то явно це вплине на продуктивність. Якщо масив підключений через два надлишкових SAN, які врівноважені навантаженням, використовуючи усічені посилання, тоді обмін неможливо здійснити лише для того, щоб забрати занадто велику пропускну здатність. Ще одна річ, яку потрібно врахувати, - це скільки МО / сек здатний масив. Поки масив і SAN, до яких він підключений, масштабуються правильно,

Чи допоможе тут запит на розділення логічних накопичувачів для різних функцій логічних накопичувачів (data vs log vs tempdb)? Чи бачила б SAN різну активність вводу-виводу на них і оптимально налаштовувала їх по-різному?

Це, мабуть, питання переваги, а також дуже залежить від того, як налаштовують його адміністратори пам’яті. Вони можуть дати вам три LUN в одному масиві чи томі, і в цьому випадку все одно все одно. Якщо вони давали вам окремі LUN на різних масивах, в різних обсягах (фізично різні диски), то, можливо, вам варто їх розділити.

Зараз ми трохи в просторі. Командам додатків пропонують обробляти архіви даних тощо. Чи можуть проблеми з простором спричинити команду SAN приймати різні рішення про те, як вони налаштовують внутрішнє сховище (рівні RAID тощо), що може вплинути на роботу мого сервера?

Я не думаю, що ваш адміністратор пам’яті змінить рівень рейду, щоб звільнити місце. Якби він хотів, то, мабуть, його слід звільнити. Космічні проблеми можуть призвести до того, що речі можуть бути налаштовані інакше, але зазвичай не впливають на продуктивність. Вони можуть просто стати трохи більш чіткими щодо того, скільки місця вам дають. Вони можуть включати такі функції, як дедуплікація даних (якщо масив підтримує їх), які можуть перешкоджати продуктивності масиву під час запуску процесу, але не цілодобово.

Команда SAN повинна мати інструменти, які допоможуть вам розкрити, чи працює ваш додаток. Очевидно, вам слід також стежити і вимірювати свої результати.

Більшість мого досвіду є з EMC так YMMV. Але наступне має стосуватися більшості обладнання SAN.

У масив йде лише стільки портів. Іноді між ними є перемикач SAN, який дозволяє визначити зони. Тільки тому, що масив - це, по суті, великий пул пам’яті, не означає, що ви не повинні турбуватися про продуктивність IO.

Тож якщо ви відчуваєте, що у вас проблеми з ІО, вам потрібно звузити місце, де знаходиться вузьке місце. Якщо він знаходиться десь між HBA і масивом, ви можете з'ясувати, чи HBA максимізовано або порт SAN на стороні комутатора / масиву переписаний. Крім того, ви повинні мати команду SAN для моніторингу моделей доступу до вашої програми, як з холодного запуску, так і з гарячого.

Очевидно, що базове сховище має значення: скажімо, повільний великий RAID5 проти швидкого RAID10, оскільки вам в якийсь момент доведеться натискати на диск незалежно від різних рівнів кешу.

HTH. Ви можете надіслати мені повідомлення в режимі офлайн, якщо у вас є конкретні проблеми, оскільки це може зайняти деякий час, щоб пройти пошук.

Як не створювати ворогів команді SAN, як я можу запевнити себе та розробників додатків, що наші сервери SQL не страждають від погано налаштованого сховища? Просто використовувати статистику perfmon? Інші орієнтири, такі як sqlio?

Перше, що вам потрібно знати, перш ніж робити якийсь тест-бенчмаркінг, - це те, на яку толерантність потрібно виконувати ваше власне навантаження. Тому орієнтуйте свої речі перед тим, як перевірити нову систему. Таким чином, якщо ви виявите, що ви піднімаєте максимум 56 Мб / с під час пікових навантажень (резервного копіювання?), З'ясувавши, що приєднаний до SAN масив диска "тільки" підштовхує 110 Мб / с при імітованих пікових навантаженнях, ви можете бути запевнив, що обмеження не буде каналом вводу / виводу.

Перевіряючи новий дисковий масив, я провів таке тестування продуктивності. Новий масив використовував диски SATA замість накопичувачів волоконно-канальних (SCSI), і мені потрібно було запевнити себе, що він буде працювати в нашому середовищі. Я був глибоко сумнівним. Але після характеристики я з’ясував, що нова система мала достатньо накладних входів / виходів під піком, щоб не відставати від вимірюваного піку на більш надійних дисках. Це мене здивувало.

Якщо я завантажую тест на ці накопичувачі SAN, чи справді це дає мені надійну, повторювану міру того, що я побачу, коли ми продовжимо жити? (припускаючи, що програмне забезпечення SAN може "динамічно конфігуруватися" по-різному в різні моменти часу.)

Через спільну природу дискових масивів, приєднаних до SAN, продуктивність змінюється протягом тижня. Якщо ви вже знаєте, коли ваша пікова навантаження вводу / виводу, зробіть ряд тестів навантаження протягом доби, коли ваше пікове навантаження вводу / виводу. Таким чином ви зможете краще охарактеризувати, який тип накладних входів / виходів доступний у періоди, які вас найбільше цікавлять. Навантажувальні тести у не пікові часи дадуть вам відчуття того, як ви отримаєте «спритні» речі, але пікове тестування буде перевірити справжні межі.

Чи впливає важкий IO в одній частині SAN (скажімо, сервер Exchange) на мої сервери SQL? (якщо припустити, що вони не дають виділених дисків кожному серверу, що мені сказали, що вони не є)

Якщо обмінні LUN-диски обмінюються дисками з вашими LQL-SQL, вони абсолютно будуть. Ми використовуємо HP EVA, а не XP, але я думаю, що вони використовують ту саму термінологію "групи диска". LUN в одній і тій же групі дисків діляться дисками, і тому претендують на введення / виведення на цих фізичних пристроях. Чим більше дисків ви помістите в групу дисків, тим більше маніпуляцій у маніпуляції має перемикати введення-виведення. Масиви (принаймні, EVA роблять це, і я вважаю, що дорожчі XP роблять те саме) поширюють логічні блоки LUN по фізичних дисках не послідовно. Це дозволяє йому робити те, що ви пропонуєте, а це динамічно розподіляти групи часто доступних блоків на різні фізичні пристрої, щоб збільшити паралелізм та зменшити суперечності вводу / виводу на рівні диска.

Поставити запитання - скільки бюджету вводу / виводу має ця група дисків та чи додатки, які використовують ці LUN, переплачені для вводу / виводу. Це питання, за яким адміністратори сховища повинні будуть відслідковувати. Можливо, пік вводу-виводу для Exchange (можливо, під час резервного копіювання) може не збігатися з навантаженнями SQL, і обидві системи можуть співіснувати щасливо.

Чи допоможе тут запит на розділення логічних накопичувачів для різних функцій логічних накопичувачів (data vs log vs tempdb)? Чи бачила б SAN різну активність вводу-виводу на них і оптимально налаштовувала їх по-різному?

Для масивів HP вам потрібно буде розмістити різні шаблони вводу-виводу в різні групи дисків, а не LUN. Шаблони вводу / виводу бази даних не повинні існувати, наприклад, з шаблонами доступу до веб-сервісу. Різні LUN помітно не покращують вашу ефективність, якщо вони не знаходяться в різних групах дисків. Якщо вони в одній диску-групі, єдиною реальною перевагою є операційна система, де вона може робити планування вводу-виводу в ядрі, щоб поліпшити паралелізм дискової підсистеми. Це сказало ...

Наскільки я розумію, масиви HP знають про різні схеми доступу до LUN, але пильну увагу приділяють фактичним логічним блокам. Якщо розмістити журнали на іншому LUN, це пов'язує логічні блоки, які отримають такий трафік вводу-виводу, і це полегшить завдання правильного сортування логічних блоків на фізичних дисках.

Зараз ми трохи в просторі. Командам додатків пропонують обробляти архіви даних тощо. Чи можуть проблеми з простором спричинити команду SAN приймати різні рішення про те, як вони налаштовують внутрішнє сховище (рівні RAID тощо), що може вплинути на роботу мого сервера?

Безумовно. Якщо місця недостатньо, ви не збираєтеся отримувати виділені групи дисків для свого вводу-виводу (якщо тільки ваше середовище зберігання не є достатньо великим, щоб виправдати виділення 7ТБ фізичного диска для виключного використання. Тоді це може бути саме так ). Дебати Raid5 / Raid10 значною мірою залежать від політики організації, а просити вас найкраще.

Я пропоную відкрити діалог зі своєю командою SAN та продавцем, щоб вирішити ваші проблеми. Однією з проблем, з якою ви матимете запуск власних орієнтирів, є те, що ваші тести можуть не мати стосунку до того, що відбувається у виробництві, особливо при пікових навантаженнях. Більшість SAN мають безліч кеш-пам'яті, що в багатьох випадках (особливо коли ви використовуєте синтетичні орієнтири) означає, що ви пишете в оперативну пам’ять і отримуєте продуктивність.

Залежно від вашого оточення та рішення, яке ви використовуєте, якийсь постачальник CE може тільки що ввійшов і налаштувати SAN на будь-який стандарт, якому він віддає перевагу. Це відбувається більше, ніж ти думаєш. Вам доведеться відірватися від оболонки "Команда SAN знає все", поки не будете впевнені, що рішення відповідає вашим вимогам.

Удачі.

Одного разу я був на конференції Oracle з розмовою на цю тему - здоровий SAN для баз даних.

Суть розмови доступна у цьому PDF-файлі або на веб-сайті авторів тут