1. Caché backup: батарейки в комплекті?
2. Що необхідно враховувати при зовнішньому резервне копіювання?
3. Варіанти резервного копіювання
4. Рекомендоване рішення для резервного копіювання: зовнішнє резервне копіювання
5. Знімок стану VMware
6. Особливості Caché для знімків стану системи
7. Замороження і відтавання Caché
8. Тестування заморозки і відтавання
9. Завмірання віртуальної машини
10. Дізнаємося час завмирання з журналів VMware
11. Приклад завантаження файлів vmware.log
12. підсумок

У цій статті я розгляну стратегії резервного копіювання Caché з використанням систем зовнішнього резервного копіювання та приведу приклади інтеграції з рішеннями на основі знімків стану віртуальної машини (VM snapshot, снапшот). Більшість рішень, з якими я стикаюся сьогодні, розгорнуті на базі Linux і VMware, тому я приведу приклади рішень саме з використанням снапшотов VMware.

Для кращого розуміння даної статті вам слід також ознайомитися з керівництвом щодо створення резервної копії та відновлення в онлайн-документації Caché.

Caché backup: батарейки в комплекті?

Вбудоване гаряче резервне копіювання (Caché online backup) поставляється разом з Caché «з коробки» і призначене для резервного копіювання баз даних Caché без зупинки системи. Однак існують і більш ефективні рішення для резервного копіювання, про які варто знати в ті моменти, коли ви плануєте масштабування великої системи. Зовнішнє резервне копіювання (External Backup) з використанням технологій створення знімків - рекомендований мною рішення для резервного копіювання систем, в тому числі, що використовують бази даних Caché.

Що необхідно враховувати при зовнішньому резервне копіювання?

В онлайн документації InterSystems, присвяченій зовнішньому резервного копіювання , Можна знайти все, що цікавлять деталі. Відзначимо лише ключовий момент:

«Для забезпечення цілісності знімка файлової системи Caché надає можливості для заморозки (freeze) записи в бази даних в момент створення знімка. Заморожування піддаються тільки спроби фізичного запису в файли бази даних, що дозволяє призначеним для користувача процесів продовжувати безперебійно виконувати оновлення бази даних в пам'яті ».

Важливо також зазначити, що частина процесу створення знімка в віртуалізованих системах викликає невелику паузу в роботі віртуальної машини, яку прийнято називати завмиранням (stun). Зазвичай завмирання триває менше секунди, тому його не помічають користувачі і воно не робить впливу на роботу системи, проте в деяких випадках завмирання може тривати і довше. Якщо завмирання триває довше, ніж таймаут QoS (Quality of service, показник якості обслуговування) віддзеркалення бази даних Caché, то резервний вузол дзеркала вирішить, що стався збій в основній системі, і зробить перемикання дзеркала. Пізніше в цій статті я розповім як можна заміряти час завмирання на той випадок, якщо вам потрібно буде внести зміни в налаштування часу очікування QoS для віддзеркалення.

Варіанти резервного копіювання

Мінімалістичне рішення для резервного копіювання - вбудоване резервне копіювання (Caché Online Backup)

Якщо у вас немає можливості використовувати інші засоби, залишається цей старий добрий спосіб, який входить в комплект поставки з платформами InterSystems. Врахуйте, що Caché online backup створює резервні копії тільки для файлів баз даних Caché, зберігаючи всі непусті блоки в базах даних, записуючи їх послідовно в файл. Caché Online Backup підтримує накопичувальне (cumulative) і інкрементне (incremental) резервне копіювання.

В контексті VMware, Caché Online Backup виконується на гостьовий машині. Подібно до інших аналогічних рішень, операції, що виконуються Caché Online Backup, однакові незалежно від того, віртуалізувати чи додаток або виконується безпосередньо на фізичному сервері. Відповідно, копії, отримані Caché Online Backup повинні бути переміщені на резервний носій разом з усіма іншими файлами, якими користується ваш додаток. Під час резервного копіювання системи необхідно пам'ятати про каталозі додатки, переважно і альтернативному каталогах журналу БД, і будь-яких інших каталогах, що містять файли, які використовуються додатком.

Caché Online Backup слід розглядати або як підхід початкового рівня для невеликих проектів, які бажають реалізувати недороге рішення для «гарячого» резервного копіювання баз даних, або для створення разових резервних копій. Наприклад, створення подібних копій дуже корисно під час першого налаштування віддзеркалення. Однак, оскільки бази даних збільшуються в розмірах і оскільки бази даних Caché зазвичай є лише частиною клієнтського набору даних, зовнішні резервні копії в поєднанні з технологією створення моментальних знімків при використанні сторонніх утиліт рекомендуються як найкраще рішення з такими перевагами, як можливість включати в резервну копію файли , відмінних від файлів бази даних, зменшений час відновлення, можливість контролю даних в масштабах всієї організації і доступність поліпшених інструментів для каталог зації і управління.

Рекомендоване рішення для резервного копіювання: зовнішнє резервне копіювання

Розглянемо його на прикладі VMware. Використання VMware для віртуалізації додає нові функції і можливості для захисту віртуальних машин в цілому. Віртуалізація рішення призводить систему (включаючи операційну систему) до ефективної інкапсуляції вашого застосування зі всіма даними усередині одного файлу vmdk (і кількох інших файлів). При необхідності цими файлами можна дуже легко маніпулювати, і вони можуть використовуватися для швидкого відновлення цілої системи. Це сильно відрізняється від відновлення працездатності вашого застосування на голому залозі, де ви повинні відновити і налаштувати кожен компонент окремо - операційну систему, драйвери, сторонні додатки, СУБД і файли баз даних і т.д.

Знімок стану VMware

VMware vSphere Data Protection (VDP) та інші сторонні рішення для резервного копіювання віртуальних машин, такі як Veeam або Commvault, використовують функції знімків стану (snapshot) віртуальних машин VMware для створення резервних копій. Нижче наведено короткий пояснення механізму роботи знімків VMware. Для отримання більш детальної інформації зверніться до документації.

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

Самі по собі знімки VMware не є резервними копіями!

Знімки дозволяють використовувати ПО для резервного копіювання та зробити резервні копії, але вони не є резервними копіями самі по собі.

VDP і інші сторонні рішення використовують процес створення знімків стану VMware в поєднанні з будь-яким додатком для управління виробництвом і, що дуже важливо, видаленням знімків. Коротенько послідовність подій для створення зовнішньої резервної копії за допомогою знімків VMware виглядає наступним чином:

• Стороннє програмне забезпечення для резервного копіювання запитує у хоста ESXi виконання знімка стану VMware.
• Файли .vmdk віртуальної машини переводяться в режим «тільки для читання» і для кожного файлу .vmdk кожної віртуальної машини створюється дочірній .vmdk дельта-файл.
• Будь-який запис на диск відбувається в дельта файл віртуальної машини. Будь-які операції читання виконуються спочатку з дельта-файлу.
• Програмне забезпечення резервного копіювання виконує резервне копіювання батьківських .vmdk-файлів, що знаходяться в режимі «тільки для читання»
• Після завершення резервного копіювання, знімок зливається з вихідним файлом (диски віртуальної машини стають доступними для запису і оновлені блоки з дельта-файлів дописують до батьківських файлів).
• Знімки VMware видаляються.

Рішення для резервного копіювання також містять спеціальні можливості, як наприклад відстеження змінених блоків (Changed Block Tracking, CBT), щоб виконувати інкрементне або накопичувальне резервне копіювання максимально швидко і ефективно (що особливо важливо для економії місця). Подібні рішення зазвичай також додають інші корисні і важливі функції, такі як стиснення даних, організація роботи за розкладом, відновлення віртуальних машин з іншим IP-адресою для перевірки цілісності, відновлення як всієї віртуальної машини, так і окремих файлів з неї, управління каталогом резервних копій і т.д.

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

Слід дуже добре подумати, перш ніж робити знімки стану вручну на основному сервері баз даних. Навіщо ви це робите? Що станеться, якщо ви повернетеся в минуле до того моменту, коли створювали знімок? Що відбувається з усіма транзакціями між створенням знімка і відкотом змін?

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

Особливості Caché для знімків стану системи

Перед виконанням знімка база даних повинна бути стабілізована (quiesced): всі записи в файли повинні бути завершені і файли баз даних повинні бути в коректному стані. Caché надає методи і API для завершення, а потім заморожування (freeze) записи в бази даних на короткий період створення знімка. Заморожування під час створення знімка піддаються тільки спроби фізичного запису в файли бази даних, що дозволяє призначеним для користувача процесів продовжувати виконувати поновлення в пам'яті безперебійно. Після того як знімок був зроблений, можливість запису в базу даних відновлюється, база даних «відтає» (thaw), і резервна копія продовжує копіюватися на резервний носій. Час між заморожуванням і розморожуванням має бути невеликим (не більше кількох секунд).

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

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

Зверніть увагу на короткий час між заморожуванням і розморожуванням - це час тільки на створення знімка, а не час, який потрібен на копіювання всього батьківського об'єкта в резервну копію.

Замороження і відтавання Caché

vSphere дозволяє автоматично викликати скрипти до і після створення знімка: це і є ті самі моменти, які називаються заморожуванням і розморожуванням Caché. Примітка: для правильної роботи цього функціоналу ESXi хост запитує у гостьовій операційної системи заморозку дисків через VMware Tools.

У гостьовій операційній системі повинні бути встановлені Інструменти VMware. Скрипти повинні дотримуватися суворі вимоги до імені та місця перебування. Необхідно також призначити коректні права на файли. Імена скриптів для VMware на Linux:

Нижче наведені приклади скриптів заморожування і відтавання, які наша команда використовує для резервного копіювання за допомогою Veeam в наших внутрішніх тестових лабораторіях. Ці скрипти також повинні підійти для роботи і з використанням інших продуктів. Приклади були протестовані і використовувалися на vSphere 6 і Red Hat 7.

Хоча ці сценарії можуть використовуватися в якості прикладів і є ілюстрацією до описуваного методу, ви повинні переконатися в їх правильності для вашої власної середовища!

Приклад скрипта заморозки:

Приклад скрипта відтавання:

Не забудьте встановити права на файли:

Тестування заморозки і відтавання

Щоб перевірити роботу наведених сценаріїв, ви можете вручну запустити виконання знімка на віртуальній машині і перевірити що виведе сценарій. На наступному скріншоті показаний діалог «Take VM Snapshot» і його опції.

Скиньте прапорець "Snapshot the virtual machine's memory" (Зберегти оперативну пам'ять віртуальної машини)
Відзначте прапорець "Quiesce guest file system (Needs VMware Tools installed)" (Стабілізувати гостьову файлову систему). Це призведе до припинення запущених процесів в гостьовій операційній системі і скидання буферів, щоб вміст файлової системи знаходилося у відомому несуперечливому стані при виконанні знімка.

Важливо! Після тесту не забудьте видалити зроблений знімок!

Якщо прапорець стабілізації (quiescing) відзначений і віртуальна машина працює в той момент, коли робиться знімок, для стабілізації файлової системи віртуальної машини буде використовуватися VMware Tools. Стабілізація файлової системи являє собою процес приведення даних на диску в стан "готовий до резервного копіювання". Цей процес може включати в себе такі операції, як очищення заповнених буферів між кешем операційної системи в пам'яті і диском.

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

Wed Jan 4 16:30:35 EST 2017: Pre freeze script started
Wed Jan 4 16:30:35 EST 2017: Attempting to freeze H20152
Wed Jan 4 16:30:36 EST 2017: H20152 IS FROZEN
Wed Jan 4 16:30:36 EST 2017: Completed freeze of H20152
Wed Jan 4 16:30:36 EST 2017: Pre freeze script finished

Wed Jan 4 16:30:41 EST 2017: Post thaw script started
Wed Jan 4 16:30:41 EST 2017: Attempting to thaw H20152
Wed Jan 4 16:30:42 EST 2017: H20152 IS THAWED
Wed Jan 4 16:30:42 EST 2017: Completed thaw of H20152
Wed Jan 4 16:30:42 EST 2017: Post thaw script finished

На цьому прикладі видно, що час між заморожуванням і розморожуванням становить 6 секунд (16:30:36 - 16:30:42). Протягом цього періоду робота користувачів НЕ переривається. Вам потрібно буде зібрати статистику з ваших власних систем, але для інформації відзначимо, що даний приклад був запущений під час тестування продуктивності додатка на системі без «вузьких місць» в системі вводу / виводу, в середньому виконувала більше 2 мільйонів операцій читання БД в секунду ( Glorefs / sec), 170 000 операцій запису БД в секунду (Gloupds / sec) і в середньому 1100 фізичних операцій читання диска в секунду і 3000 записів за цикл демона записи БД (write daemon cycle).

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

Для додаткового захисту даних, зміна журналу може також виконуватися сама по собі, супроводжувана резервним копіюванням або репликацией журналу, наприклад, щогодини.
Нижче наведено вміст $ LOGFILE з прикладу заморозки / відтавання, наведеного вище, в якому показані подробиці журналу для знімка.

01/04/2017 16:30:35: Backup.General.ExternalFreeze: Suspending system

Journal file switched to:
/trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: /trak/jnl/jrnpri/h20152/H20152_20170104.011

Journal marker set at
offset 197192 of /trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:36: Backup.General.ExternalFreeze: System suspended
01/04/2017 16:30:41: Backup.General.ExternalThaw: Resuming system
01/04/2017 16:30:42: Backup.General.ExternalThaw: System resumed

Завмірання віртуальної машини

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

Витяг зі статті: «Щоб створити знімок віртуальної машини, віртуальна машина« завмирає », щоб (i) серіалізовать стан пристрою на диск і (ii) закрити поточний працює диск і створити точку початку знімка ... При злитті дельта-файлів віртуальна машина« завмирає » , щоб закрити диски для запису і перевести їх в стан, придатне для злиття. »

Час завмирання зазвичай становить близько 100 мілісекунд, однак, при дуже високій активності записи на диск, під час фази злиття дельта-файлів завмирання може тривати до декількох секунд.

Якщо віртуальна машина є основним або резервним учасником зеркалирования Caché, і час завмирання більше, ніж таймаут QoS для віддзеркалення, дзеркало може помилково повідомити про збій основний віртуальної машини і ініціювати перехоплення дзеркала резервною системою.

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

Як зазначалося вище, при створенні знімка є кілька опцій, які можна вказати. Одна з опцій дозволяє включати збереження оперативної пам'яті в знімку. Пам'ятайте, що збереження оперативної пам'яті не потрібно для резервного копіювання бази даних Caché. Якщо встановлений прапор збереження пам'яті, дамп внутрішнього стану віртуальної машини буде входити в знімок. Виконання знімка з пам'яттю займає набагато більше часу. Знімки пам'яті використовуються для повернення до такого стану віртуальної машини, яка була на момент виконання знімка. Цього НЕ потрібно для резервного копіювання файлів бази даних.

Коли робиться знімок оперативної пам'яті, стан всієї віртуальної машини буде заморожено на невизначений час.

Як вже зазначалося раніше, для резервних копій прапорець «узгодженість» (quiesce) повинен бути відзначений, щоб гарантувати цілісне і успішне резервне копіювання.

Дізнаємося час завмирання з журналів VMware

Починаючи з ESXi 5.0 час завмирання реєструється в файлі журналу кожної віртуальної машини (vmware.log) повідомленнями, схожими на такі:

2017-01-04T22: 15: 58.846Z | vcpu-0 | I125: Checkpoint_Unstun: vm stopped for 38123 us

Час завмирання вказується в мікросекундах, тому в прикладі вище 38123 us це 38123 / 1,000,000 секунд або 0.038 секунди.

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

Приклад завантаження файлів vmware.log

Існує кілька способів скачати журнали, в тому числі шляхом створення пакету підтримки (support bundle) VMware через консоль управління vSphere або з командного рядка хоста ESXi. Зверніться до документації VMware за всіма подробицями, а нижче наведено простий спосіб створення і збору мінімального пакету журналів підтримки, який включає в себе файл vmware.log, що дозволяє дізнатися тривалість завмирання.

Вам знадобиться довге ім'я каталогу, де розташовані файли віртуальної машини. Зайдіть по ssh на той хост ESXi, де запущена віртуальна машина з базою даних і виконайте команду vim-cmd vmsvc / getallvms для отримання списку vmx файлів і пов'язаних з ними унікальних довгих імен.

Приклад довгого імені для бази даних віртуальної машини, згадується в цій статті, буде виглядати так:

26 vsan-tc2016-db1 [vsanDatastore] e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0 / vsan-tc2016-db1.vmx rhel7_64Guest vmx-11

Далі виконайте команду для збору файлів журналу:

vm-support -a VirtualMachines: logs

Команда відобразить розташування створеного пакету підтримки, наприклад:

To see the files collected, check '/ vmfs / volumes / datastore1 (3) /esx-esxvsan4.iscinternal.com-2016-12-30--07.19-9235879.tgz'

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

<Bundle name> / vmfs / volumes / <host long name> / e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0.

Там ви побачите кілька пронумерованих лог-файлів. Самий останній файл номера не має, це vmware.log. Журнал може бути не більше 100 КБ, але при цьому буде містити дуже багато інформації. Оскільки ми просто шукаємо моменти початку і кінця завмирання, їх досить легко знайти за допомогою утиліти grep, наприклад:

У прикладі ми бачимо дві групи замираний. Перша складається з моменту створення знімків, а друга - через 45 хвилин для кожного диска при завершенні об'єднання знімка (наприклад, після того, як програмне забезпечення для резервного копіювання завершило копіювання основного vmx файлу). У наведеному вище прикладі ми можемо бачити, що більшість замираний вищими за секунди, хоча початкова завмирання становить трохи більше однієї секунди.

Коротке завмирання непомітно для кінцевого користувача. Проте, системні процеси, такі як, наприклад, віддзеркалення Caché, постійно контролюють, чи є база «живий». Якщо час завмирання перевищує таймаут QoS для віддзеркалення, то вузол може бути визнаний неконтактним і «мертвим», і станеться обробка аварійної ситуації.

Порада: для огляду всіх журналів або пошуку несправностей зручно використовувати команду grep щоб знайти всі часи замираний і потім відформатувати їх за допомогою утиліти awk і впорядкувати, як в наступному прикладі:

підсумок

Ви повинні регулярно контролювати свою систему під час нормальної роботи, щоб знати і розуміти величину часу завмирання і то, як вона може вплинути на засоби забезпечення високої доступності, наприклад, віддзеркалення. Як вже зазначалося раніше, стратегії, спрямовані на те, щоб звести до мінімуму час завмирання, включають запуск резервних копій, коли активність бази даних і сховища низька і коли продуктивність сховища максимальна. Для постійного моніторингу журнали можуть оброблятися за допомогою VMware Log insight або інших інструментів.

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

Примітка перекладача: оскільки ми працюємо з автором в одному офісі, я можу передати йому ваші питання і переслати сюди його відповіді. Також обговорення англійською є в оригіналі статті на InterSystems Developer Community.

оригінал статті