Прискорення резервного копіювання БД

1. Скорочення часу резервного копіювання
2. Паралельне використання декількох дисків і файлів.
3. Використання декількох мережевих плат
4. Рекомендації за загальною кількістю використовуваних файлів
5. Додаткові способи оптимізації та рекомендації
6. великі фрейми
7. BLOCKSIZE
8. BUFFERCOUNT і MAXTRANSFERSIZE
9. Стиснення резервної копії
10. Рекомендації по апаратних засобів файлових серверів, призначених для зберігання копій
11. Налаштування RAID-контролера
12. Налаштування HBA
13. Системи на основі NUMA
14. Обчислення часу, необхідного для резервного копіювання та відновлення бази даних
15. Висновок

Копіювання двотерабайтний бази даних на локальні жорсткі диски і потім її відновлення задовольняє сучасним вимогам на відновлення нашої системи SQL Server. Однак, цей простий процес не може забезпечити адекватний захист від сценаріїв повної відмови, формалізованих в угоді SLA. З іншого боку, копіювання бази даних по мережі в віддалене сховище захист від повної відмови забезпечити може. Проблему може створити обмеження, що накладаються пропускною здатністю мережі, яке зазвичай не перевищує зазвичай 1 гігабіта в секунду (Gbps). Коли ми вивчали цю ситуацію, основним критерієм для порівняння продуктивності було копіювання даних по мережі 1-Gbps на відстань в 10 миль в інший центр даних. Цей процес займав більше 24-х годин, що було абсолютно неприйнятно. Необхідно було знайти таке рішення, яке давало б можливість створити резервну копію в рамках того вікна часу відновлення, яке було зазначено в SLA.
Всебічно переосмисливши всі грані проблеми резервування по мережі і провівши безліч випробувань, ми змогли скоротити резервне копіювання бази в 2Тб до 36 хвилин. Рішення, яке ми назвали "багатопотоковим резервуванням по мережі" (в оригіналі: "multistreamed backups over the network"), використовувало вісім здійснювати підключення до мережі, по 1-Gbps кожне. Збільшений до гігантського розмір фрейма було вказано в налаштуваннях кожної мережевої плати, і кожна мережева плата була з'єднана з задублірованним по другому рівню комутатором лінією 10GE (10Gbit Ethernet), яка простяглася до другого сайту. Саме резервне копіювання зайняло 2 години 25 хвилин. Що з'явилося в SQL Server 2008 стиснення резервних копій дозволило ще скоротити цей час до 36 хвилин. База даних складалася з 32 файлів даних і одного файлу журналу транзакцій, які займали приблизно 2,5 Терабайта на 9 логічних дисках (файли даних розміщувалися на дисковому сховищі корпоративного класу - SAN, а журнал транзакцій на локальних дисках - DAS). У таблиці нижче показано тривалість резервного копіювання звичайним способом і два найбільш швидких підходу до резервування по мережі. Детальний опис кожної з реалізацій наведено нижче.

Спроба Мережа Тривалість Звичайним способом Одна 1Gbps мережева плата, конфігурація за замовчуванням> 24 годин Багатопотокове резервування по мережі 8x1Gbps мережевих плат, гігантський фрейм 2 години 25 хвилин Багатопотокове резервування по мережі зі стисненням 8x1Gbps мережевих плат, гігантський фрейм 36 хвилин

Таблиця 1: Тривалість резервування 2Tб на сервер в 10 милях по мережі

Скорочення часу резервного копіювання

Є два способи підвищення швидкості виконання резервування: оптимізація та розпаралелювання.
Спочатку давайте розглянемо внутрішній устрій резервного копіювання. Число потоків, які обслуговують резервне копіювання, залежить від числа логічних дисків - томів, які використовуються для файлів бази даних, і від числа пристроїв резервування. Це - дуже важливо знати, тому що цей факт дозволяє управляти ступенем паралелізму резервного копіювання. До сих пір ми спиралися на ту схему розміщення файлів, яка показана на малюнку нижче. Одним із способів підвищення продуктивності цієї схеми є збільшення числа дисків і розміщуються на різних дисках файлів, як це буде описано в наступному розділі.

Паралельне використання декількох дисків і файлів.

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

Нижче показана команда, яка виконує резервне копіювання в два файли.

BACKUP DATABASE MyVLDB

TO DISK = '\\ BAK01 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ BAK01 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, INIT;

Таке використання команди резервного копіювання призводить до деякого виграшу в продуктивності, але не до чотириразового її збільшення, яке можна було б очікувати (подвійний виграш при читанні плюс подвійний виграш на записи). Щоб повністю уявити собі можливий виграш, потрібно врахувати пропускну здатність мережі.

Використання декількох мережевих плат

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

Багато виробників мережевого устаткування пропонують сьогодні рішення, що дозволяють об'єднувати кілька мережевих плат в один логічний мережевий інтерфейс. Це рішення добре працює на серверах, що мають сотні клієнтських підключень з мережі, це рішення дозволяє використовувати алгоритми балансування навантаження, в залежності від того, які клієнти працюють з сервером. У нашому випадку потрібно збільшити швидкість між двома вузькоспеціалізованими серверами. Для цього ми використовували поділ мережі на логічні підмережі. У таблиці нижче показані підмережі для кожної мережевої плати двох серверів.

Мережева плата Сервер SQL01 Сервер BAK01 Access 192.168.1.1 маска 255.255.255.0 192.168.1.2 маска 255.255.255.0 Backup 01 192.168.2.1 маска 255.255.255.0 192.168.2.2 маска 255.255.255.0 Backup 02 192.168.3.1 маска 255.255.255.0 192.168.3.2 маска 255.255.255.0

Таблиця 2: Підмережі

Кожна мережева плата знаходиться в своїй підмережі (192.168.1.0/24, 192.168.3. 0/24). Тепер можна внести невеликі зміни в команду резервного копіювання, вказавши там IP - адреси замість імен серверів. Таким способом стає легко управляти тим, яка підмережа, а, отже, і яка мережева плата буде використовуватися для транспортування даних. Той факт, що всі логічні підмережі будуть перебувати на одному і тому ж другому фізичному рівні мережі, не матиме ніякого негативного впливу на це рішення.

BACKUP DATABASE MyVLDB

TO DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, INIT;

У разі відновлення, це працює за тією ж схемою.

RESTORE DATABASE MyVLDB

FROM DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak'

WITH CHECKSUM, NORECOVERY;

Точно також все буде працювати і з великим числом мережевих плат. В описуваних в статті експериментах перевірялася паралельна робота 16 мережевих плат.

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

BACKUP DATABASE MyVLDB

TO DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_1.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_2.bak',

DISK = '\\ 192.168.2.2 \ backup \ MyVLDB00000001_3.bak',

DISK = '\\ 192.168.3.2 \ backup \ MyVLDB00000001_4.bak'

WITH CHECKSUM, INIT;

Емпіричним шляхом було показано, що в залежності від продуктивності використовуваних ресурсів (головним чином серверів і мережевих плат), від двох до чотирьох файлів через одну мережеву плату передаються досить добре. Однак, тільки тести в конкретних умовах замовника можуть допомогти знайти оптимальне число переданих через мережеву плату файлів.

Рекомендації за загальною кількістю використовуваних файлів

На підставі результатів безлічі експериментів, були вироблені рекомендації щодо оптимізації резервного копіювання. Підспудно було також з'ясовано, що резервне копіювання працювало краще в тих випадках, коли всі ресурси завантажувалися рівномірно. Для досягнення оптимального результату, всі представлені нижче рівності повинні витримуватися. Рівняння перераховані в порядку їх значимості, з поданням рекомендованих значень для n, які виділені жирним шрифтом.

Файли бази даних повинні бути рівномірно розподілені по логічним дискам, а файли резервних копій повинні рівномірно розподілятися між мережевими платами.
У Таблиці 3 показані приклади збалансованого розміщення файлів і використання дисків, які забезпечують хорошу продуктивність резервного копіювання. Ці значення оптимальні тільки для підвищення продуктивності резервного копіювання. Подібного збільшення продуктивності вводу-виводу звичайної бази даних не відбудеться, якщо замість чотирьох файлів даних, на одних і тих же логічних дисках буде розміщено вісім файлів даних.
У контексті наведених вище формул, можна виділити кілька прикладів хороших поєднань процесорних ядер, файлів, логічних дисків і мережевих плат.

процессов
сміттєві
ядра Логічні
диски
для
файлів
даних Мережеві
плати
для
резервного
копіювання Файли
даних Файли
резервних
копій 2 1 1 2 2 4 2 2 2 4 4 4 2 4 4 8 2 2 2 8 8 4 2 4 8 16 2 2 8 8 16 4 4 8 8 16 4 4 16 16 16 8 4 16 16 32 8 4 16 16 32 8 8 16 32 32 16 8 16 32 64 16 8 32 32 64 32 16 32 64

Таблиця 3: Збалансоване розподіл файлів по дискам

Додаткові способи оптимізації та рекомендації

Поділ мереж для резервного копіювання та загального доступу

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

великі фрейми

Максимальний розмір пакета мережі Ethernet в нормальних умовах становить 15000 байт (дорівнює розміру фрейму). Це означає те, що для передачі по мережі 1 Мегабайта, його доведеться розбити на 700 пакетів, які будуть передані один за іншим.
Сьогодні можна придбати такі мережеві плати і комутатори, які підтримують пакети Ethernet з великими розмірами фрейма. Для таких фреймів мережевих плат і комутаторів навіть існує спеціальну назву - "jumbo frames".
Чим більше розмір фрейма, тим швидше передача даних, тому що для обміну між серверами буде потрібно менше ітерацій.
Найбільш поширеними розмірами великих фреймів є величини близько 4088 і 9016 Байт (включаючи заголовки Ethernet і великого фрейму). Наприклад, якщо розмір фрейма буде 9016 Байт, тоді для передачі 1 Мегабайта знадобиться всього 117 пакетів.
Емпіричні дослідження показали, що при збільшенні розміру рамки до 9016 Байт, продуктивність мережі практично подвоюється.

BLOCKSIZE

Параметр, який задає використовуваний командою BACKUP розмір блоку, повинен відповідати розміру блоку записи пристроїв довгострокового зберігання. Коли запис здійснюється на окремий диск, буде працювати досить добре навіть використовується за умовчанням для розміру блоку значення рівне 512. Якщо ж запис спрямована на RAID - масив або на SAN, варто переконатися в тому, що використовується за умовчанням значення не опиниться менше, ніж, наприклад, 65536.
Під час резервного копіювання по мережі потрібно підібрати таке значення, яке б дозволило заповнювати мережеві пакети найбільш щільно. Майте також на увазі, що розбиття даних на пакети працює в обох напрямках. Вибір в якості розміру блоку 512 Байт призведе до того, що в мережевий пакет буде міститися два блоки (беручи до уваги те, що розмір фрейму Ethernet дорівнює 1500 байт). Т.ч. для передачі однієї сторінки бази даних знадобиться 8 мережевих пакетів. З іншого боку, запис блоками по 4096 байт буде міститися в 3 мережевих пакету, а для передачі однієї сторінки бази даних знадобиться 6 мережевих пакетів.
Можна навести ще додаткові приклади, отримані в результаті проведених при написанні цієї статті тестів; при використанні великих фреймів розміром 9016 Байт найкращі результати виходять при розмірі блоку 8192 байт, а при використанні великих фреймів розміром 4088 Байт, найкращі результати виходять при розмірі блоку 65536 Байт.

BUFFERCOUNT і MAXTRANSFERSIZE

З параметрів команди BACKUP можна виділити такі, які також дуже сильно впливають на продуктивність резервного копіювання, це параметри BUFFERCOUNT і MAXTRANSFERSIZE. На жаль, навіть тижні тестів не змогли допомогти скласти правило підбору оптимальних значень для цих параметрів, тому Вам також необхідно буде з'ясовувати оптимальні значення тестуванням у Вашій середовищі. Як ради. для значення параметра MAXTRANSFERSIZE якщо у Вас система x64 або IA64 з достатнім об'ємом оперативної пам'яті, можна почати тестування з значення максимального розміру буфера 4 Мб (4194304). Для отримання більш докладної інформації про параметр BUFFERCOUNT і про інших оптимізують параметрах, зверніться до рекомендацій по налаштуванню продуктивності стиснення резервних копій в технічній статті: Tuning the Performance of Backup Compression in SQL Server 2008
У деяких випадках, при проведенні тестів для цієї статті, кращі результати виходять при значно менших значеннях параметрів, але вибір значень був непередбачуваний. Для промислового застосування варто виконати всебічне тестування різних варіантів, і переконатися, що кращі результати добре відтворюються. Якщо ж немає можливості провести таку роботу - краще зберегти параметри за замовчуванням.

Стиснення резервної копії

Стиснення резервних копій (нова функція, що з'явилася в SQL Server 2008) надає можливість збільшити продуктивність резервування і в той же час істотно скоротити спожите копією дисковий простір, яке виділено для зберігання резервних копій. Для включення стиснення резервної копії, в команді BACKUP потрібно додати опцію WITH COMPRESSION.
У представленому нижче прикладі запиту показано, як включити стиск резервної копії.

BACKUP DATABASE MyVLDB

TO DISK = '\\ BAK01 \ backup \ MyVLDB.bak'

WITH CHECKSUM, INIT, COMPRESSION;

Ступінь стиснення в дійсності залежить від даних, які зберігаються в базі. Для більшості баз даних (цифрова інформація, грошово-кредитні операції, дата і час, простий текст), коефіцієнт стиснення буде перебувати між 1: 4 і 1: 6. Для баз даних містять деякі інші типи даних, наприклад, картинки, які вже в стислому форматі, можна очікувати результати гірше. Для отримання більш докладної інформації про використання стиснення з різними типами даних, дивіться статтю в SQL Server Books Online: Стиснення резервних копій .

У проведених для цієї статті тестах, спостерігалося скорочення часу резервного копіювання з 125 до 36 хвилин, при стисненні файлу на 20 відсотків від початкового розміру.
У стиснення даних є один недолік-підвищення утилізації процесорних ресурсів.
SQL Server проізводітт стиснення в одному потоці, який пише дані в файл резервної копії, так що число файлів резервних копій визначається числом процесорних ядер, які будуть виконувати стиснення паралельно. Щоб обмежити використання процесорів для резервного копіювання, можна використовувати Регулятор Ресурсів (Resource Governor), за допомогою якого можна віддавати іншим підключень більше ресурсів.
Якщо використовується прозоре шифрування бази даних (TDE), не слід намагатися використовувати для шіфруемий бази ще й стиснення, тому що зашифровані дані стискатися досить погано. Якщо вказівка ​​опції стиснення при формуванні кожної команди резервного копіювання незручно, можна за допомогою системної збереженої процедури sp_configure встановити автоматичне стиснення при створенні всі резервні копії на сервері:

sp _ configure 'backup compression default', 1

reconfigure

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

Рекомендації по апаратних засобів файлових серверів, призначених для зберігання копій

дискові пристрої

До дисків, що використовуються для зберігання і перевірки восстанавливаемости файлів резервних копій, не застосовуються такі ж високі вимоги, як до дисків промислових серверів. Так відбувається тому, що у них майже всі операції введення-виведення виконуються послідовно і не носять випадковий характер. Тому SATA диски в більшості випадків дуже добре підходять для цих цілей.

Налаштування RAID-контролера

Для создания масівів логічніх дисків, на якіх вірішено зберігаті файли резервних Копій, Варто вібрато великий розмір сегмента (64 Кб, 128 Кб, 256 Кб и вищє). Такоже, Варто Встановити повне кешування запису, а кешування читання можна Повністю відключіті. Можна ще актівізуваті кеш запису окремий шпінделів, так як если во время резервного Копіювання будут перебої з харчування, резервна копія так и так стані непригодна, и в такому випадка НЕ ​​має значення, чи були Втрачені будь-які байти в кеші запису чи ні.
Для тих логічніх дисків, Які будут задіяні в пробному відновленні бази з копії, розмір сегмента встановлюється в 64 Кб, застосовується політика 100-процентного кешування запису, а кешування читання віставляється на 0 відсотків.
Вибір рівня RAID (1, 10, 5, 6 ...) залежить від можливостей використовуваного RAID-контролера або використовуваної системи сховища. Оскільки навантаження на файловому сервері при резервному копіюванні / відновленні є послідовною записом і читанням даних, контролер буде кешувати дані, поки він не закінчить запис всього Страйп цілком, в цьому випадку можна використовувати будь-який рівень RAID. Якщо контролер поводиться по-іншому, і продуктивність є критичним параметром, масиви RAID1 або RAID10 будуть єдиним можливим варіантом.

Налаштування HBA

Якщо в якості дисків для файлів резервних копій використовується дискова підсистема типу SAN, максимальну глибину черзі для адаптерів, які використовуються в підключенні SAN, потрібно збільшити настільки, наскільки це можливо. Значення за замовчуванням становить 32, але резервне копіювання і відновлення працюватимуть набагато краще при значеннях близьких до 256. Більш детальну інформацію можна знайти в статті Налаштування Windows Server 2008/2003 x64 для обслуговування SQL Server 2008 , В розділі "NumberOfRequests і MaximumSGList".

Мережеві плати

Слід дуже розбірливо підходити до вибору мережевих плат, які будуть використовуватися на серверах. Число портів ще не гарантує адекватну продуктивність введення-виведення для всіх цих портів в один і той же час. Буває так, що два чотирьохпортовий адаптера можуть виявитися більш продуктивними, ніж один адаптер з чотирма портами. Кількість процесорного часу, використовуваного драйвером мережевого інтерфейсу, також дуже важливо. Бувають такі мережеві плати, які використовують до 50 відсотків ресурсів одного процесора, і в той же час є інші, які використовують всього 3 - 5 відсотків.
Якщо для резервного копіювання використовується кілька мережевих плат, дуже важливо, щоб вони використовували різні процесори, тобто щоб їх переривання були прив'язані до різних процесорним ядрам.

Системи на основі NUMA

Якщо сервер використовує архітектуру з неоднорідним доступом до пам'яті (NUMA), необхідно переконається в тому, що всі адаптери вводу-виводу (наприклад, NIC, RAID і HBA) розподілені між усіма NUMA - вузлами системи.

Обчислення часу, необхідного для резервного копіювання та відновлення бази даних

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

Далі, потрібно визначити максимальну тривалість паралельного, послідовного читання і запису використовуваних дискових підсистем. Для того щоб виміряти ці значення при тестуванні резервного копіювання та відновлення, можна використовувати системну утиліту Performance Monitor (відому ще в деяких версіях операційної системи Windows як System Monitor).
В результаті, повинно вийти 5 значень. За наявності кількох логічних дисків і мережевих плат, ці значення можуть відрізнятися, і завжди потрібно використовувати найгірші результати обчислень.

1. Продуктивність мережевого адаптера (МБ / сек);
2. Продуктивність логічного диска сховища копій при послідовному читанні (МБ / сек);
3. Продуктивність логічного диска сховища копій при послідовній запису (МБ / сек);
4. Продуктивність логічного диска файлу бази даних при послідовному читанні (МБ / сек);
5. Продуктивність логічного диска файлу бази даних при послідовній запису (МБ / сек).

Після цього, спираючись на дані про кількість логічних дисків для паралельної роботи з файлами бази даних, на число логічних дисків, що використовуються для паралельної роботи з файлами резервних копій і число використовуваних мережевих плат. Якщо стиснення не використовується, це призведе до того, що коефіцієнт стиснення стане таким: CompressionFactor = 1.

У більшості випадків, без стиснення резервної копії продуктивність мережі буде найменшою в порівнянні з продуктивністю дискового читання і запису, але коли стиснення включено, основним обмеженням може стати читання з бази: DatabaseReadPerformance, або інші, не враховані поки компоненти, такі як завантажені стисненням процесорні ядра .

Обчислення для розрахунку часу відновлення будуть складнішими. Спочатку потрібно дізнатися, чи підтримує використовувана система миттєву ініціалізацію файлів. Ця можливість дозволяє SQL Server створювати файли даних на томах NTFS без обнулення займаного файлами місця під час створення або розширення файлу. Оскільки у цього механізму існують пов'язані з безпекою ризики, такою можливістю можна скористатися, тільки якщо облікового запису, під якою працює служба SQL Server надати в локальних політиках право "Perform Volume Maintenance". Якщо обліковий запис користувача входить в групу локальних адміністраторів, це право їй буде надано за замовчуванням (Примітка: час ініціалізації файлу журналу транзакцій може обмежувати продуктивність, так як займане цим файлом місце не може не заповнюватися нулями).

У разі якщо RestoreTime або BackupTime вище заданих SLA значень, можна скористатися викладеними раніше рекомендаціями щодо зменшення цих значень. Розпаралелювання операцій зазвичай прискорює процес більше ніж спроба прискорити роботу одного з компонент у всьому ланцюжку. У сценаріях з дуже високою продуктивністю варто задуматися про застосування обох підходів.

Зверніть увагу: на виконання команди CHECKBD може знадобитися більше часу, ніж час, який необхідно для читання з диска. Воно залежить від складності схеми бази даних, і воно точно не буде менше часу читання.

Висновок

Microsoft і, безпосередньо команда SQL Server постійно вдосконалюють технології забезпечення живучості систем, які покликані допомогти клієнтам і партнерам вирішувати завдання резервного копіювання та відновлення в масштабах підприємства. SQL Server 2008 забезпечений для цих завдань всім необхідним функціоналом, на який можуть покластися фахівці і який допомагає успішно справлятися з притаманними сьогоднішнього дня вимогами з управління і захисту даних. За рахунок удосконалень в ключових областях, SQL Server 2008 став надійною платформою для обслуговування дуже великих баз даних.
Ця технічна стаття надає тільки короткий огляд можливостей резервного копіювання та відновлення, а також деяких функціональних можливостей SQL Server 2008.