Якщо ви працюєте з віртуальними інфраструктурами, це лише питання часу, коли ви задасте собі те саме питання: Що мені робити з усіма цими знімками, які постійно накопичуються на машинах? У деяких ІТ-командах філософія полягає в тому, щоб зберігати їх «про всяк випадок», тоді як в інших нормою є видалення їх якомога швидше. Реальність така, що неправильне використання знімків не лише не покращує безпеку, але й... Це може збільшити споживання пам'яті, знизити продуктивність і навіть пошкодити віртуальну машину..
Щоб приймати правильні рішення, вам потрібно розуміти, що таке знімок, чим він не є, як він працює «під капотом» та Які найкращі методи запобігання пошкодженню машин або вашого дискового корпусу?Давайте подивимося на це спокійно, але з технічною експертизою та твердо стоїмо на місці, як це робиться у справжніх центрах обробки даних.
Що насправді є знімком (і чим він не є)
Знімок, незалежно від того, чи він знаходиться у VMware, Hyper-V чи системах зберігання даних, – це знімок стану віртуальної машини або тома в певний момент часуВін заморожує ситуацію: стан диска, а також, за бажанням, пам'яті та програми, щоб ви могли повернутися до цієї точки, якщо щось піде не так.
Ключовим є те Це не повна, окрема копія данихЗнімок виконує роль «логічного фото» базового диска, а потім записує зміни, що відбуваються з цього моменту. Це дозволяє дуже швидко відновлювати дані, оскільки вимагає лише перенаправлення покажчиків, без переміщення терабайтів даних.
У багатьох середовищах помилково ставляться до знімків як до резервної системи. Ця плутанина небезпечна.Знімок залежить від оригінального диска, масиву сховища та всього ланцюжка диференціальних дисків. Якщо щось у цьому ланцюжку виникне збій, можливо, ні знімок, ні віртуальна машина не завантажаться.
На таких платформах, як VMware, розрізняють знімки пам'яті (які також зберігають вміст оперативної пам'яті та точний стан виконання) та знімки з беззвучним або узгодженим з програмами способом, які Вони забезпечують узгоджений стан файлової системи та певних програм. використання таких інструментів, як VMware Tools.
Як працює знімок на рівні блоків та дисків
Щоб зрозуміти, чому надмірне використання знімків може пошкодити машини або знизити продуктивність, корисно візуалізувати, що відбувається з блоками диска. Уявіть собі віртуальну машину з одним віртуальним диском, що складається з блоків A, B, C, D та E. Поки немає знімків, будь-які зміни записуються безпосередньо на цей диск.Якщо блок A модифікується, він стає A', а якщо ми додаємо новий блок F, диск збільшується.
Під час створення першого знімка оригінальний диск «заморожується» як доступний лише для читання. З цього моменту Усі зміни перенаправляються на новий диск з різницями. (наприклад, додатковий VMDK у VMware). Знімок не дублює всі дані; він лише починає зберігати змінені блоки на цьому дочірньому диску.
Якщо після першого знімка ви зміните A' та B і додасте новий блок G, A, B, C, D, E та F залишаться на базовому диску, тоді як A'' (новий A), B' та G зберігатимуться на диференціальному диску. Фактичний логічний розмір віртуальної машини тепер становитиме 7 блоків, але У сховищі даних ви вже займаєте 9 блоків між базовим та диференціальнимОсь тут і починається вечірка тихого зростання.
Якщо ви створюєте ще один знімок, поточний диференціальний диск також заморожується, і створюється другий диференціальний диск, на якому будуть збережені нові зміни (A''', D', E', H тощо). Результатом є ланцюжок пов'язаних дисків, де кожен з них залежить від попередньогоУ прикладі з оригінальним контентом базовий диск займає 6 блоків, а диференціали вже становлять 7, тому загальна віртуальна машина споживає 13 блоків у сховищі даних, що більше місця у знімках, ніж оригінальний розмір диска.
Ця архітектура має й іншу сторону: продуктивність. Коли системі потрібно прочитати блок, наприклад, C, Спочатку подивіться на найновіший диск диференціала.Якщо його там немає, він переходить на наступний диск у ланцюжку і так далі, доки не досягне базового диска. У довгих ланцюжках кожне зчитування включає кілька переходів, що призводить до більших затримок і повільніших операцій, особливо з механічними дисками та дуже активними віртуальними машинами.
Копіювання під час запису, перенаправлення під час запису та їхній вплив
Реалізація знімків зазвичай спирається на два основні методи: Копіювання під час запису (COW) та перенаправлення під час запису (ROW)Обидва прагнуть досягти однієї й тієї ж мети (збереження попереднього стану), але з різними компромісами між продуктивністю та фрагментацією.
У системах на основі копіювання під час запису, коли ви змінюєте існуючий блок, система спочатку копіює старий блок в область знімка, а потім записує нові дані в його початкове положення. Це зберігає попередню версію, але штрафує кожен запис.тому що це стає послідовністю читання-копіювання-запису.
Підхід Redirect-On-Write, який використовується в багатьох сучасних системах, деяких NAS та розширених файлових системах, працює у зворотному порядку: Старі дані залишаються там, де вони є, а нові дані записуються в інше фізичне місце.Знімки вказують на «старі» блоки, а активний том оновлює свої вказівники на нові. Продуктивність запису значно краща, але це відбувається за рахунок збільшення фрагментації.
Ця фрагментація зазвичай не є драматичною для повністю флеш-сховищ, але в класичних або гібридних масивах жорстких дисків, Велика кількість знімків та постійних змін може знизити швидкість читання.Ось чому багато виробників рекомендують поєднувати ці технології з системами автоматичної реорганізації або просто обирати флеш-пам'ять, якщо потрібно працювати з багатьма моментами часу.
Чому знімки НЕ є резервними копіями
Одне з найважливіших повідомлень полягає в тому, що, якими б комфортними вони не були, Знімки екрана не замінюють традиційні резервні копіїТехнічно вони не виконують ту саму роль і не пропонують такого ж рівня захисту від стихійних лих.
Повне резервне копіювання створює репліку даних на іншому носії: іншому масиві сховища, іншому сховищі даних, стрічці, хмарі тощо. Для мінімізації ризиків можна застосувати правило 3-2-1 (три копії, два різних носії, одна поза межами об'єкта). Якщо центр обробки даних згорить, шафа зламається або хтось зітре том, копія все ще там залишиться. бо він живе деінде.
З іншого боку, знімок залежить від того самого обладнання та того самого пулу сховищ. Якщо масив сховища виходить з ладу, якщо сховище даних пошкоджується або якщо атака знищує том, всі знімки летять з нимКрім того, як ми вже бачили, у багатьох реалізаціях усі знімки залежать від ланцюжка дисків; якщо одна ланка в цьому ланцюжку пошкодиться, ви можете втратити всі пов'язані версії.
Вони також не є еквівалентними, коли йдеться про відновлення окремих елементів. Знімок зазвичай призначений для повернути повну віртуальну машину до певного моменту часуЦе не для детального відновлення окремого файлу, таблиці бази даних чи поштової скриньки. Цю можливість пропонують рішення для резервного копіювання, які працюють з агентами, інтеграціями програм або браузерами резервного копіювання.
У серйозних середовищах обидва підходи необхідно поєднувати: створювати знімки пункти швидкого та короткострокового відновленнята резервні копії для забезпечення історії, тривалого зберігання, позасмугового захисту та детального відновлення.
Найкращі практики використання знімків, щоб уникнути пошкодження машин
Якщо припустити, що знімок не є резервною копією, наступне питання полягає в тому, як безпечно їх використовувати. Існує низка рекомендацій, якими поділилися такі виробники, як VMware, Microsoft та постачальники сховищ даних, які Вони допомагають уникнути проблем, пов'язаних з пошкодженням, неконтрольованим простором та падінням продуктивності..
Перше правило — це здоровий глузд: Не накопичуйте старі знімки, якщо не збираєтеся до них повертатися.Якщо ви знаєте, що не зможете відновити критично важливу віртуальну машину до певного моменту часу, що був кілька місяців тому (оскільки стан її даних більше не буде актуальним), цей знімок непотрібний і лише додає ризику. Розумним рішенням буде його видалити.
Виробники зазвичай рекомендують зберігати кожен знімок протягом обмеженого часу. Наприклад, у VMware суворо не рекомендується зберігати один знімок більше 72 годин, оскільки файл diff зростатиме в міру внесення змін віртуальною машиною. Чим довше воно служить, тим більшим стає і тим дорожчим буде його укріплення..
Ще однією очевидною гарною практикою є обмежити кількість одночасних знімків на машиніХоча технічно ви можете створити десятки (у VMware теоретичний максимум становить близько 32), на практиці найкраще дотримуватися 2 або щонайбільше 3. Більше точок означає довші ланцюжки, вищу затримку читання та складнішу консолідацію.
Наполегливо рекомендується створювати знімки, коли віртуальна машина не зазнає дуже високих піків вводу/виводу. Створення знімка прямо посеред шквалу записів може призвести до помилок у його створенні. або залишати систему в нестабільному стані. У критично важливих базах даних або програмах найкраще координувати роботу з періодами низької активності або використовувати знімки, узгоджені з програмами.
Як довго їх зберігати, скільки використовувати та як з ними доглядати
Керування знімками – це не просто натискання кнопки «зробити знімок» і забуття про це. Потрібна чітка політика щодо створення, використання та утилізації.особливо в середовищах з десятками або сотнями віртуальних машин.
У продакшені найрозумнішим підходом є створення знімків безпосередньо перед певними операціями: змінами конфігурації, оновленнями системи, патчами програм, внутрішніми міграціями тощо. Після того, як все буде перевірено на правильність роботи, Рекомендація — видалити знімок без зволікання.Чим менше ланцюгів, тим менша ймовірність зіпсувати ситуацію.
Також доцільно доповнити ручне керування автоматичними механізмами очищення. У менеджерах vCenter або Hyper-V можна періодично переглядати дерево знімків, бачити, які знімки активні, їхній розмір і вік, а також усунути ті, що перевищили максимальний час, встановлений у внутрішній політиці.
Вкрай важливо завжди видаляти знімки за допомогою офіційних інструментів (vSphere, Hyper-V Manager, інтерфейсу командного рядка виробника масиву зберігання даних тощо) та дозволяти системі самостійно виконувати консолідацію. Видалення знімків будь-яким іншим способом або переривання процесу консолідації призведе до проблеми. Це може призвести до нестабільного стану дисків і навіть до пошкодження віртуальної машини..
Щодо кількості, збалансований підхід полягає в роботі максимум з однією або двома активними точками в чутливих середовищах та більш розслаблений підхід (трьома або чотирма) в лабораторних умовах, де ризик нижчий, а гнучкість цінується більше, ніж екстремальна продуктивність.
Вплив на продуктивність, простір та консолідацію дисків
Окрім ризику пошкодження, найпоширенішим побічним ефектом зловживання знімками є низька продуктивність. Щоразу, коли ви додаєте новий диск різниці, ви також додаєте ще один стрибок у ланцюжок читання.Це особливо помітно у віртуальних машинах з багатьма випадковими операціями з диском, таких як бази даних або файлові сервери.
Під час операцій читання гіпервізор або масив сховища має шукати запитуваний блок, починаючи з останнього знімка та рухаючись у зворотному напрямку до базового диска. З двома знімками вплив може бути невеликим, але Через довгі ланцюжки та високу фрагментацію дисків, користувацький досвід може бути складним..
У сфері сховища реальні приклади є ілюстративними. Досить часто можна знайти віртуальні машини, логічний диск яких, наприклад, має розмір 2 ТБ, але які Сховище даних займає 4 або 5 ТБ через забуті знімки. Роками. Кожна щоденна зміна в базі даних, кожен файл, який надходить або видаляється, збільшує диски відмінностей, і ніхто цього не помічає, доки в масиві сховища не закінчиться місце.
Коли настає час видаляти старі знімки, процес консолідації може бути тривалим і делікатним. Консолідація включає Об'єднати всі зміни, що зберігаються на дисках-різницях, з їхнім батьківським дискомОдин за одним, доки весь ланцюжок не буде інтегровано в базовий диск. На віртуальних машинах з великим обсягом даних та роками змін це призводить до годин інтенсивних операцій читання/запису.
Ця тривала консолідація впливає не лише на продуктивність, але й Будь-яке переривання або помилка посеред процесу може призвести до нестабільного стану машини.Звідси важливо не допускати нескінченного зростання знімків та планувати завдання консолідації в періоди низького навантаження та з належним моніторингом.
Знімки, програми-вимагачі та кіберстійкість
В останні роки програми-вимагачі додали ще один рівень складності до проблеми. Зловмисники більше не задовольняються простим шифруванням файлів користувачів: Вони шукають облікові дані адміністратора, знаходять резервні копії, видаляють знімки та намагаються залишити вас без чистої точки для повернення..
Це підкреслює обмеження моделей, заснованих виключно на традиційних резервних копіях без додаткового захисту. Якщо резервні копії доступні за допомогою тих самих скомпрометованих облікових даних, або якщо знімки можна легко видалити з панелі адміністрування, Зловмисник може залишити середовище без захисної сітки за лічені хвилини..
У цьому контексті багато виробників сховищ обирають незмінні знімки, інтегровані в сам масив сховища. Ці моменти часу, після створення та блокування, Їх не можна змінювати або видаляти протягом періоду зберігання, навіть обліковим записам з максимальними правами.Це свого роду WORM (Write Once, Read Many - запис одного разу, читання багато разів), що застосовується до знімків.
Незмінність забезпечує дуже потужний захист: навіть якщо зловмисник отримає адміністративний доступ, Ви не зможете видалити захищені знімки, доки не закінчиться термін їх блокування.Це гарантує, що у вас буде принаймні один набір чистих точок відновлення для перебудови систем після атаки.
Окрім незмінності, деякі просунуті системи використовують ентропійний аналіз та штучний інтелект для блоків, що записуються в виявлення типових шаблонів масового шифруванняКоли вони виявляють аномальний сплеск випадкового запису та різкі зміни ентропії, вони можуть автоматично ініціювати створення захищених знімків або навіть відрізати доступ до запису для підозрілого клієнта.
Знімки сховища порівняно з знімками операційної системи
Знімок, яким керують на гіпервізорі або в масиві сховища, не є тим самим, що тіньові копії томів операційної системи (наприклад, VSS у Windows). Ця відмінність також актуальна у сценаріях із програмами-вимагачами.
Багато сучасних шкідливих програм, проникаючи на сервер Windows, Вони виконують команди для видалення всіх тіньових копій і запобігти відновленню самої системи до попереднього стану за допомогою її власних інструментів. Це позбавляє користувача простої можливості «відновити попередню версію».
Однак, знімки, якими керують на NAS або SAN, зазвичай не залежать від операційної системи. Вони контролюються поза мережею, безпосередньо із самого сховища. Навіть якщо зловмисник видалить VSS у Windows, ці знімки масиву сховища залишаться недоторканими.І доки у нас є чітко визначена процедура відновлення, ми можемо повернутися до попереднього пункту.
Ось чому сучасна архітектура передбачає подвійний рівень захисту: знімки у сховищі для стійкості до атак операційної системита зовнішні резервні копії, з незмінністю та логічним розділенням, для покриття сценарію фізичної катастрофи або глибокого компрометування.
У будь-якому разі, слід наголосити: навіть найскладніші знімки сховища все ще залежать від системи, в якій вони зберігаються. Якщо кабіна пілота втрачена або повністю пошкоджена, її знімки також втрачаються.Це ще раз підкреслює необхідність підтримувати політики резервного копіювання, що відповідають принципу 3-2-1, а в критичних середовищах навіть працювати з копіями з обмеженим доступом.
Знімки в тестовому, розробницькому та виробничому середовищах
Не всі середовища отримують однакову користь від знімків, і не всі вони повинні керуватися однаково. У лабораторіях та середовищах розробки знімки – це чисте золото.оскільки вони дозволяють тестувати агресивні зміни, розгортати експериментальні версії програмного забезпечення або симулювати збої та повертатися до початкової точки за лічені секунди.
У таких сценаріях зазвичай менший тиск на продуктивність і більша толерантність до ризику. Навіть попри це, це все ще розумно. обмежити надмірно довгі рядки та очистити старі знімки щоб не заповнювати салон технічним мотлохом, який ніхто не пам'ятає, для чого він був.
У продакшені філософія має бути набагато консервативнішою. Тут знімки слід використовувати як... тимчасова система безпеки навколо контрольованих змінПеред великим патчем, оновленням бази даних, конфіденційною зміною конфігурації тощо. Після перевірки стабільності знімок видаляється, а захист залишається на системі резервного копіювання.
Сервери застосунків з кількома залежностями (зовнішні бази даних, веб-інтерфейси, LDAP тощо) потребують особливої уваги. Повернення лише одного з вузлів до старого знімка може призвести до неузгодженого стану набору.Перш ніж використовувати знімки в такому типі архітектури, необхідно оцінити, чи підтримує програма цей тип часткового відкату, чи краще використовувати точніші відновлення.
Зрештою, у критично важливих системах з високою доступністю та дуже суворими вимогами до RTO багато організацій поєднують незмінні знімки у флеш-сховищі з механізмами для Миттєве відновлення з резервних копійЦе досягає балансу між дуже короткими термінами виконання робіт та надійним захистом від масштабних катастроф.
Ефективне керування знімками передбачає розуміння того, що вони є потужним інструментом, але з однією умовою: При неправильному використанні вони збільшують споживання дискового простору, знижують продуктивність і можуть залишити вас без робочої віртуальної машини саме тоді, коли вона вам найбільше потрібна.За умови розумного використання, з політикою короткого зберігання, короткими ланцюжками, плановими консолідаціями та постійною підтримкою належної системи резервного копіювання (в ідеалі з незмінністю та логічним розділенням), вони стають ключовим союзником у боротьбі з людськими помилками, ризикованими змінами та атаками програм-вимагачів, не пошкоджуючи машини та не порушуючи стабільність середовища.
