Його стандартна практика розділяти файли журналів та даних для відокремлення дисків від ОС (також tempdb, резервного копіювання та файлу swap) Чи має ця логіка все-таки сенс, коли ваші накопичувачі базуються на SAN, а ваші LUNS не вирізані з певних наборів дисків чи рейдів - вони є лише частиною x кількості накопичувачів SAN, а LUN - просто розподіл місця
Відповіді:
Журнали та накопичувачі даних мають різні шаблони доступу до даних, які конфліктують між собою (принаймні теоретично), коли вони поділяють диск.
Журнал записів
Доступ до журналу складається з дуже великої кількості невеликих послідовних записів. Дещо спрощено, журнали БД - це буферні дзвінки, що містять перелік інструкцій для запису елементів даних у певні місця на диску. Шаблон доступу складається з великої кількості невеликих послідовних записів, які повинні бути гарантовано виконані - тому вони виписуються на диск.
В ідеалі журнали повинні бути тихими (тобто не поділятися ні з чим іншим) RAID-1 або RAID-10. За логікою ви можете розглядати процес як основну СУБД, що виписує записи журналу, і один або кілька потоків зчитування журналів, які споживають журнали та записують зміни на диски даних (на практиці процес оптимізований таким чином, що записи даних записуються негайно, де можливо). Якщо на журнальних дисках є інший трафік, голови переміщуються цими іншими доступами, і послідовне записування журналу стає випадковим записом журналу. Вони набагато повільніше, тому зайняті диски журналу можуть створити точку доступу, яка є вузьким місцем для всієї системи.
Дані записує
(оновлено) Запис у журнал повинен бути заповнений на диск (званий стабільним носієм), щоб транзакція була дійсною та прийнятна для здійснення. Логічно можна розглядати це як записи журналу, які записуються, а потім використовуються як інструкції для виписування сторінок даних на диск асинхронним процесом. На практиці записи сторінок диска фактично готуються і буферуються під час внесення запису в журнал, але їх не потрібно писати негайно для здійснення транзакції. Дискові буфери виписуються на стабільні носії (диск) за допомогою процесу Lazy Writer (спасибі Полу Рандалу, що вказав на це), про який у цій статті Technet йдеться більш докладно.
Це дуже випадковий шаблон доступу, тому обмін одними і тими ж фізичними дисками з журналами може створити штучне вузьке місце щодо продуктивності системи. Записи журналу повинні бути записані для здійснення транзакції, тому випадкове прагнення уповільнити цей процес (випадковий введення / виведення набагато повільніше, ніж послідовний вхід / вивід журналу) перетворить журнал із послідовного в пристрій випадкового доступу. Це створює серйозні вузькі місця в навантаженій системі, і цього слід уникати. Те саме стосується спільного використання тимчасових областей з томами журналів.
Роль кешування
Контролери SAN, як правило, мають великі кеші оперативної пам'яті, які можуть певною мірою поглинати трафік випадкового доступу. Однак для цілісності транзакцій бажано мати записи з диска з СУБД, гарантовано завершені. Якщо контролер встановлений для кешування зворотного запису, брудні блоки кешуються, а виклик вводу / виводу повідомляється хостом.
Це може згладити безліч суперечок, оскільки кеш може поглинути багато вводу-виводу, який інакше вийшов би на фізичний диск. Він також може оптимізувати паритет читання та запису для RAID-5, що зменшує вплив на продуктивність, яку мають томи RAID-5.
Це характеристики, які зумовлюють школу думки "Нехай САН займається цим", хоча ця думка має деякі обмеження:
Кешування зворотного запису все ще має режими відмов, які можуть втрачати дані, і контролер перейшов до СУБД, кажучи, що блоки були записані на диск, де насправді їх немає. З цієї причини ви, можливо, не захочете використовувати кешування зворотного запису для транзакційного додатку, зокрема, щось, що містить важливі для фінансових даних або фінансові дані, коли проблеми цілісності даних можуть мати серйозні наслідки для бізнесу.
SQL Server (зокрема) використовує введення / виведення в режимі, коли прапор (званий FUA або примусовий доступ до оновлення) змушує фізичне записування на диск до повернення дзвінка. Microsoft має сертифікаційну програму, і багато постачальників SAN виробляють обладнання, яке шанує цю семантику ( тут викладені вимоги ). У цьому випадку ніякого кількості кеш-пам'яті не буде оптимізувати записи на диск, який означає , що журнал трафік буде трешем , якщо він сидить на зайнятої роздільний обсязі.
Якщо програма генерує багато дискового трафіку, її робочий набір може перевиконати кеш, що також спричинить проблеми з суперечливістю запису.
Якщо SAN поділяється з іншими програмами (особливо на тому ж диску), трафік інших програм може генерувати вузькі місця журналу.
Деякі програми (наприклад, сховища даних) генерують великі перехідні сплески навантаження, що робить їх досить антисоціальними для SAN.
Навіть для великих SAN окремі томи журналів все ще рекомендуються практикою. Ви можете уникнути, не турбуючись про макет на злегка використовуваному додатку. У дійсно великих програмах ви навіть можете отримати перевагу від декількох контролерів SAN. Oracle публікує серію кейсів сховища даних, де деякі більші конфігурації включають кілька контролерів.
Покладіть відповідальність за продуктивність там, де вона належить
Що стосується великих обсягів або коли продуктивність може бути проблемою, зробіть команду SAN відповідальною за виконання програми. Якщо вони ігнорують ваші рекомендації щодо конфігурації, то переконайтесь, що керівництво знає про це і що відповідальність за продуктивність системи лежить у відповідному місці. Зокрема, встановіть прийнятні вказівки для ключових статистичних даних про виконання БД, як-от очікування вводу-виводу або очікування засувки сторінки або прийнятне домовлене угоди про введення-виведення.
Зауважте, що відповідальність за продуктивність, розбиту на декілька команд, створює стимул для точкового введення та передачі долара іншій команді. Це відомий антидіапазон управління та формула проблем, які тягнуться місяцями або роками, і ніколи не вирішуються. В ідеалі повинен бути єдиний архітектор, який має повноваження визначати додаток, базу даних та зміни конфігурації SAN.
Крім того, орієнтуйте систему на навантаження. Якщо ви можете домовитись про це, на Ebay можна придбати сервіси б / у та прямі вкладення масивів прямо. Якщо ви встановите подібне вікно з одним або двома дисковими масивами, ви можете фрігувати з конфігурацією фізичного диска та вимірювати вплив на продуктивність.
Як приклад, я провів порівняння між додатком, що працює на великому SAN (IBM Shark), і коробкою з двома розетками з прямим приєднанням масиву U320. У цьому випадку апаратне забезпечення, яке було придбано на ebay, становить 3 000 фунтів стерлінгів, перевищило 1 мільйон фунтов стерлінгового SAN в два рази - на хості з приблизно еквівалентною конфігурацією процесора та пам'яті.
З цього конкретного інциденту можна стверджувати, що щось подібне лежати - це дуже хороший спосіб сумління адміністраторів SAN.
Я припускаю, що тег Equallogic та зміст запиту означає, що ви говорите про Equallogic SAN. Далі йде конкретно про Equallogic, і це не стосується інших типів SAN.
З рівнями Equallogic конкретні диски, які використовуються для томів, не можуть бути визначені так точно, як це можливо, наприклад, з масивами EMC Clariion, тому підхід має бути трохи іншим.
Еквалогічна архітектура дуже автоматизована та динамічна. Його основний будівельний блок - це блок масиву, а не пакети RAID \ груп у масиві, як це спостерігається в інших SAN. Кожен масив повністю налаштований для RAID 5, 6, 10 або 50, хоча це не означає, що існує лише одна група RAID на масив, ви просто ніколи не приймаєте рішення або взаємодіяти з ними на цьому рівні. Ви розміщуєте масиви в сховищах для зберігання, а ваші пули потім належать до групи зберігання. У Storage Group є кластерна \ віртуальна ip-адреса, яку ви використовуєте в якості цілі iSCSI Discovery для всіх томів цієї групи - програмне забезпечення для управління групою EQL та стека MPIO хостів обробляє переадресацію рівня ip, необхідну для фактичного маршрутування до найбільш відповідного порту на окремі масиви, коли запитують блоки даних, але це те, що ви мало або взагалі не маєте можливості контролювати.
Обсяги зберігання призначаються із загального вільного місця у кожному басейні. Усі обсяги в пулі розподіляються по всіх масивах у цьому пулі (добре до максимуму 4 окремих масивів), щоб розподілити мережевий IO по загальній кількості мережевих інтерфейсів (2-4 на масив Eql залежно від моделі) та IO через якомога більше контролерів. Програмне забезпечення Equallogic для управління відстежує продуктивність обсягу \ масиву з часом та динамічно оптимізує розподіл блоків по масивам членів. Загалом, якщо ви не знаєте, чим займаєтесь, ви повинні помістити всі масиви в єдиний пул і нехай це зробить, просто пам’ятайте, що ви конфігуруєте свої високошвидкісні диски (SAS 10k \ 15k) з RAID 10, середня швидкість з RAID 50 або 5 для того, щоб переконатися, що процес оптимізації фактично вибирає реальні диски високої продуктивності.
До приблизного наближення у вас буде десь 2500-5000 IOP на масив PS залежно від типу накопичувача та RAID. Якщо ви забезпечите достатню кількість загальних ІОП, то автоматичний процес управління в кінцевому підсумку повинен дати вам хороші показники, навіть якщо ви просто згрупуєте всі обсяги в один пул.
Однак якщо ви хочете гарантувати, що ваші журнали, бази даних, тимчасові сховища, диски ОС тощо є насправді ізольованими один від одного, ви можете зробити пару речей. По-перше, ви можете визначити перевагу RAID для тома, який гарантуватиме, що певний том завжди зберігається лише на масивах цього типу RAID (якщо вони є в пулі, якому належить обсяг). По-друге, ви можете визначити багаторівневі пули пам’яті, які містять лише масиви, які забезпечують різні типи продуктивності, необхідні для цього конкретного рівня, а потім розподілити обсяги у відповідних пулах. Попередження про стан здоров'я, що поставляється з таким підходом, полягає в тому, що для цього ви, як правило, потребуватимете велику кількість масивів для покращення загальної продуктивності - це може бути для вас менш важливим, ніж гарантування продуктивності в критичних обсягах, хоча це часто все ще найкраще вибір. Довідкова архітектура Dell для DB Oracle використовує один пул з 2 масивами RAID 10 для даних, диск для голосування та OCR, а також окремий пул з одним масивом RAID 5 для області відновлення Flash.
У будь-який момент часу з Equallogic ви повинні запитати себе, чи будуть рішення, які ви приймаєте щодо примусового розподілу, забезпечити кращу сукупну продуктивність для ваших обсягів з точки зору доступних мережевих інтерфейсів, дискових шпинделів та контролерів. Якщо ви не можете відповісти на це, тоді виберіть мінімальну кількість басейнів і залиште його обробляти деталі або зверніться до фахівця з рівних питань, щоб зробити справжній дизайн. Якщо у вас є лише один масив, ви нічого не можете зробити в частині розділення томів.
Ми зберігаємо наші БД в одиночних коробках SAN, але з окремими даними, журналами та резервними LUN-кодами, кожен на різних групах дисків, розрізнених за швидкістю - з нашими журналами на RAID 10 15Krpm LUN, даними про RAID 1 10 / 15krpm LUN та резервним копією на RAID 5 7.2кр / хв. Ми також представляємо журнали та дані через різні контролери одного і того ж SAN.
Чудове запитання!
Спочатку погляньте на дискусію Брента Озара "Блог сталевої клітки" з цього питання.
У нашій компанії для більшості серверів ми ставимо дані та журнали на один і той же привід SAN і залишаємо їх команді SAN, щоб переконатися, що все працює правильно.
Я починаю вважати, що це не найкраща стратегія, особливо для серверів більшого обсягу. Основна проблема полягає в тому, що я справді не маю можливості перевірити, що команда SAN насправді робить щось більше, ніж плескати разом достатню кількість дисків для потрібного нам простору. Ми не запускаємо орієнтири вводу-виведення проти SAN-накопичувачів з нашої сторони чи що-небудь, ми начебто просто припускаємо, що вони «виконують свою роботу» (підлаштовуючи ефективність та простор), що, мабуть, трохи наївно.
Моя інша думка полягає в тому, що тип доступу, який потребують дані проти журналів, відрізняється. Я спробую знайти статтю, яку я прочитав нещодавно, в якій говорилося про те, як реально оптимізувати два різні типи накопичувачів (я думаю, одному потрібна оптимізація для послідовних записів, іншому потрібна оптимізація для випадкових зчитувань, щось подібне .)
Якщо коротко, так, ви створили б окремі томи для файлів даних SQL Server, файлів журналів, а також файлів даних і журналів TempDB.
Оскільки ви позначили своє запитання Equallogic, ознайомтесь із безкоштовним керівництвом щодо архітектури Dell Reference: Розгортання Microsoft® SQL Server® за допомогою масивів зберігання Dell ™ EqualLogic ™ PS5000 (необхідна реєстрація), перш ніж розробляти рішення. Часто ви виявите, що вказівки щодо конкретних конфігурацій можуть суттєво відрізнятися від загальних порад .
Я б погодився з BradC (+1) щодо продуктивності. Як правило, хороший SAN матиме більше сирого вводу / виводу, ніж можна було очікувати.
Все ще гарна ідея відокремити ваші резервні копії від живої системи (очевидно, що я знаю, але якби у мене був 1 фунт за кожен раз, коли я бачу це ...)
Також рекомендується зберігати tempdb подалі від файлів журналів. Намет хлопця SAN перекинеться на вас, коли ви хочете бачити "різні відра" (технічний термін) для журналів, даних та темпу, але якщо ви скажете їм, то ви зможете оцінити різну кількість IO даних, що надходять до кожної області та змусити їх показати вам свої фантазійні графіки продуктивності!
Просто двічі / двічі перевірте, що хлопець SAN встановив це саме для вас. Якщо ви хочете, щоб RAID 10, тоді наполягайте на цьому (я це робив), хоча вони продовжували говорити, що їхній RAID 5 не має штрафу за ефективність.
(Для операцій, що базуються на файлах, RAID 5. чудово. Для інтенсивного запису, як тільки ви заповнюєте буфер запису, на який накрутили шуруп!)
Будьте в курсі всього змішування термінів тут.
Загалом і дуже основні:
Ви можете мати кілька томів в одному масиві, про що варто пам’ятати, коли ви робите повноцінні оптимізації, обговорені в цій темі.
Ключовим моментом є те, що кілька інших людей згадували (не забувайте це), відокремлюйте дані / журнал / резервну копію на різних шпинделях приводу, а не лише на окремі томи.
Редагувати: і Гельвік вище дав вам -знаку відповідь про рівних САН!