Знімки (snapshots)

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

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

Налаштування знімків виконується через адміністративну панель керування, розділ Управління знімками.

Серед налаштувань користувачу доступні такі параметри:

• перегляд списку створених знімків з можливістю завантаження з обраного знімка чи його видалення;
• створення знімка вручну — кнопка Створити;
• час автоматичного створення знімка — у розділі Налаштувати;
• дія при створенні знімка — у розділі Налаштувати, детальніше далі.

Дія при створенні знімка. Цей параметр дозволяє обрати дію щодо стану сервера при створенні знімка. Стосується як автоматичного, так і ручного створення знімка. Доступні такі варіанти:

• не змінювати стан сервера
• заморозити файлову систему
• перезавантажити сервер

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

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

При обранні опції заморозити файлову систему віртуальний сервер отримує повідомлення про підготовку снапшота, і ядро системи налаштовує відповідним чином файлову систему (скидає буфер/кеш, заморожує ввід/вивід). Це дозволяє з більшою долею вірогідності отримати знімок, що працює повноцінно. Для роботи цієї опції на сервері має бути встановлений і запущений qemu-guest-agent.

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

Знімки (snapshots) фізично знаходяться на тому самому сховищі, що і віртуальний дисковий пристрій VDS.

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

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

В нас є послуга місце для резервних копій, однак просимо зауважити, що для клієнтів в середовищі віртуалізації OpenStack ми НЕ надаємо резервне копіювання як сервіс – бо на рівні середовища віртуалізації немає загальноприйнятих стандартних засобів для забезпечення такого функціоналу. А резервне копіювання на рівні окремого VDS неможливо уніфікувати, позаяк ми дозволяємо використання будь-яких операційних систем – однак кожна операційна система потребує своїх власних засобів для резервного копіювання.

Технічно знімок – це сукупність всіх блоків файлової системи, які містять інформацію на момент створення знімка.

При цьому будь-який блок існує на сховищі в єдиному екземплярі – тобто при створенні знімка нічого не копіюється, це один той самий блок для всіх знімків, у яких він наявний.

Кожен наступний знімок включає в себе всі блоки файлової системи, змінені протягом доби. Практика показує, що це нестабільна величина. Крім того, навіть зсередини ОС не завжди очевидний характер даних, які споживають дисковий простір, бо це можуть бути приховані службові файли, тимчасові файли та інші подібні дані, які ОС і ПЗ можуть створювати в процесі свого функціонування. Виходячи з цього, ми не можемо дати відповіді на питання «Як розрахувати, який саме відсоток під знімки потрібен для конкретного VDS?» Єдиний дієвий спобіб визначити цю величину – це експериментальне визначення методом проб і помилок.

Ось кілька прикладів того, як споживається дисковий простір при створенні знімків.

Припустимо, у вашого VDS диск 200 гігабайт. При замовленні послуги знімків до вашої квоти на сховищі додається певний відсоток від обсягу диску, наприклад 20%. Таким чином, загальний доступний обсяг на сховищі становить 200 + (200 * 20%) = 200 + 40 = 240 ГБ. І в цей обсяг входять як дані на диску вашого VDS, так і всі наявні знімки.

Припустимо, у вас на диску VDS зайнято 100 ГБ. Після створення першого знімку на сховищі загалом буде зайнято все так же 100 ГБ, позаяк блоки з даними не копіюються, тобто перший знімок не займає додаткового простору, допоки дані на диску не змінилися.

Припустимо, ви видалили великий файл обсягом 10 ГБ. Позаяк блоки даних від цього файлу присутні у попередньому знімку – вони лишилися на сховищі. Таким чином, після створення наступного знімку на сховищі буде зайнято ті самі 100 ГБ – хоча з точки зору вашої операційної системи на диску додалося 10 ГБ вільного простору.

Припустимо, ви записали на диск новий великий файл обсягом 10 ГБ. Таким чином, він потрапить до наступного знімку, і після створення цього знімку на сховищі буде зайнято 110 ГБ.

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

На рівні середовища віртуалізації існує суттєве обмеження в роботі з дисковим сховищем – OpenStack не підтримує операції TRIM для того типу сховища, який ми використовуємо. Тобто, якщо ви видаляєте з диска VDS якийсь файл – з точки зору вашої ОС блоки файлової системи, які містили цей файл, стають вільними. Але при цьому ОС вашого VDS не має засобів відправити сховищу відповідну низькорівневу команду на звільнення блоків. Тому з точки зору дискового сховища один раз записаний блок продовжує вважатися зайнятим і відповідно включатися до всіх знімків.

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

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

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

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