Снапшот сервера как сделать
Снапшот сервера как сделать
Всем привет сегодня хочу затронуть вопрос снапшотов (snapshots) в VMware vSphere. Поговорим, что это такое, из чего состоит, плохо это или хорошо и где применяется. Думаю это актуальный вопрос и многие хотели бы в нем разобраться, да и я освежу это в памяти, и что то может переосмыслить.
Что такое snapshot
Любые данные, которые были доступны для записи на виртуальной машине, становятся доступными только для чтения при создании снимка. Snapshot позволяет вам возвращаться в одно и то же состояние несколько раз. Вы можете сделать снимок, когда виртуальная машина включена, выключена или приостановлена. Избегайте создания снимков, когда приложения на виртуальной машине обмениваются данными с другими компьютерами, особенно в производственных средах. Например, если вы делаете снимок, когда виртуальная машина загружает файл с сервера по сети, и виртуальная машина продолжит загрузку файла после того, как вы сделаете снимок. Если вы вернетесь к к своему снимку, то связь между виртуальной машиной и сервером будет прервана, и передача файла завершится неудачно.
Где применим снапшот
Применяют его чаще всего при резервном копировании виртуальных машин либо в тестовых целях, для тестирования софта или обновления например, чтобы можно было потом быстро откатиться если что то пошло не так.
Как создать снапшот в VMware vSphere
Сама процедура очень простая и сейчас будет описана. Если же вы захотите ее автоматизировать, то советую почитать Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5.
Выбираете любую виртуальную машину, щелкаете по ней правым кликом и из контекстного меню выбираете Snapshot > Take Snapshot
В следующем окне задаем имя snapshot и при желании описание в поле description. Обратите внимание на две возможные галки
Описание параметров снимка
В итоге VMware Tools с помощью VMware Snapshot Provider запускает создание VSS snapshot внутри гостевой ОС. После чего все VSS writers (смотрим их командой «vssadmin list writers«) в гостевой ОС получают запрос и подготавливают соответствующие приложения к бэкапу (происходит запись всех транзакций из памяти на диск). Когда все VSS writers заканчивают работу, они сообщают службе VMware Tools через VMware Snapshot Provider, который, в свою очередь, говорит VMware о том, что снапшот можно снять.
Таким образом все приложения резервного копирования для VMware vSphere используют следующие комбинации при отдании команды на создание снапшота VMware (заметьте, что процесс непосредственно создания снапшота целиком и полностью контролируется самой VMware)
Если делать бэкап без опции Quiesce guest file system, то могут быть большие проблемы при восстановлении контроллера домена или Exchange сервера.
Как создать снимок виртуальной машины через PowerCLI
Тут есть две конструкции, которые вы можете использовать в PowerCLI. В первом примере, мы вызываем виртуальную машину «Terminal», а далее создаем там снапшот с именем «Untill Update».
Во втором примере, мы воспользовались командлетом New-Snapshot, и обратились к виртуальному серверу, где создали снапшот с именем «Untill Update«.
Структура файлов виртуальной машины при снятии Snapshot
Вот как выглядит структура файлов до снятия снапшота в VMware vSphere. Более подробно о форматах esxi файлов читайте по ссылке.
Теперь посмотрим, что изменится после снятия снимка виртуальной машины esxi 5.5. Как видите добавились файлы с форматом vmsn и добавленным в название 000001. Это и есть жесткий диск новых данных после снапшота.
Если посмотреть на эти же файлы в консоли ssh, то этот файл на самом деле состоит из четырех. У меня на скриншоте два снапшота и в сумме они занимают 8 фалов.
файл.vmsd. Это текстовый файл, открыв в редакторе вы увидите все отношения между родительским и дочерними дисками, а также другую интересную информацию
Хочу напомнить, что снапшоты лежат вместе с виртуальной машиной но их расположение можно поменять.
В гостевой ос
Что вы обнаружите например в событиях гостевой системы при создании снапшота без галки Snapshot the virtual machine’s memory и включенной на Quiesce guest file system. Вы в просмотре событий, в журнале Приложения обнаружите ошибку VSS с кодом 12289 (Ошибка теневого копирования тома: Непредвиденная ошибка DeviceIoControl). Можете на нее забить, так как она происходит из за флоппи диска в конфигурации виртуальной машины.
так же если посмотреть через клиента VMware vSphere датастор на котором лежит виртуалка то вы обнаружите файл архив vss_manifests*.zip с конфигами с описанием всех найденных VSS writers в гостевой ОС.
Также стоит добавить некоторые требования к Quiesce guest file system
VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа.
Чем плохи снапшоты
На своей практике могу точно сказать, что минусов в разы больше чем плюсов.
Плюсы снапшотов
Такие снапшоты делаются на небольшой промежуток времени, до суток. Протестировали и удалили.
Минусы снапшотов
Консолидация и удаление снапшотов / Удаление snapshot vmware
И так рассмотрим процедуру удаления снапшота. Выше мы узнали, что это снимки это зло, и вот еще почему. Не совсем понятное поведение снапшота при его удалении и слиянии с основным виртуальным диском vm машины. Для удаления и слияния вам потребуется свободное место на вашем дисковом массиве VMFS, это еще более актуально когда снимков несколько. Выше я привет снапшот как это может выглядеть. Предположим у вас виртуальная машина с тремя снимками вот таких вот размеров.
Вы допустим хотите удалить все снапшоты и нажимаете «Delete All в Snapshot Manager», далее идет вот такая операция Snapshot 3 сливается со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS
В итоге первого шага мы получаем уже 90 гб (60+30). Теперь Snapshot 2 который весит уже 50 гб сливается с Snapshot 1, при этом Snapshot 2 и 3 не удаляются пока. Из этого следует что у нас уже занято 140 гб на хранилище.
Как только результирующий Snaphot 1 в 60 гб сольется с основным виртуальным диском при этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).
так что видите запас нужно всегда иметь, минимум 10 процентов.
Консолидация snapshot vmware
И так consolidation или консолидация, это по сути удаление снапшота со слиянием дисков, чаще всего оставленного каким нибудь средством резервного копирования, например veeam. Процесс consolidation vm я уже описывал, там все просто, но не понятно на сколько это влияет на датастор в плане производительности.
Что влияет на время консолидации в виртуальной машине
Замирание stun виртуальной машины в VMware vSphere
Если вы как и я долго уже работаете с гипервизором Vmware ESXI 5.5, то наверняка обращали внимание, что бывают случаи, что виртуальная машина подвисает на какое то время, или дико тормозит, а потом работает как ни в чем не бывало. За это в vmware отвечает параметр stun или как мы выше смотрели quiescence. Когда это происходит виртуалка не может ничего делать, она чаще всего падает по Ping и недоступна, и перестает отвечать на операции ввода/вывода. Если сказать по простому то ее как будто поставили на паузу, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).
Параметр Stun в виртуальной машины нужен, в большинстве случаев, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше, все зависит от нагрузки хранилища, у меня бывали случаи, что если виртуалка толстая и снапшот здоровый, то время stun доходило и до минуты, что сразу вызывало бурю паники, что у нас все сломалось и что вообще блин происходит, паникеры одним словом, просто не знающие как это работает.
Когда может быть заметен stun виртуальной машины
Как правильно удалить Snapshot в ESXI
У вас существует несколько методов удаления снимков:
Как исключить диски из снимка
Могут быть случаи, когда вы не хотите, чтобы диски виртуальной машины подвергались воздействию моментальных снимков. Для достижения этой цели, вам нужно изменить режим жесткого диска виртуальной машины из «Disk Mode» в «Independent – Persistent или Independent – Nonpersistent. Два варианта немного различаются в соответствии с объяснением VMware:
Как правильно работать со снапшотами виртуальных машин
«Snapshot» в переводе с английского означает «выстрел» или «мгновенный фотоснимок». Снапшот — это своего рода фотоснимок виртуальной машины (ВМ), слепок её конкретного состояния. Виртуальная машина может использоваться для различного рода экспериментов, или в нее могут вноситься изменения, которые затем нужно быстро откатить назад. Именно для того, чтобы каждый раз не мучиться восстановлением предыдущего состояния ВМ и существуют снапшоты, возвращающие ВМ к исходному состоянию. Снапшоты — не такая уж простая операция, во всяком случае, делаться она должна по правилам, о которых мы сегодня и расскажем.
Что такое снапшот?
Снапшот сохраняет состояние виртуальной машины и данные по ней в определенный момент времени.
Лучшие практики
Чтобы получить максимальную пользу от снапшотов, необходимо следовать нескольким правилам, которые позволят использовать снапшоты по максимуму и предотратить возникновение проблем.
Используйте отдельные инструменты для резервного копирования. Делайте снапшот, вносите изменения в виртуальную машину и удаляйте снапшот, как только будет подтверждено ее корректное состояние.
2) Снапшоты образуют цепочки или деревья.
VMware советует делать в одной цепочке только 2–3 снапшота:
a. Большее число снапшотов или снапшоты большого размера могут вызвать уменьшение производительности виртуальной машины и хоста.
b. Создание большого файла снапшота может заполнить доступное пространство хранилища, отключив таким обазом все виртуальные машины до тех пор, пока не будут внесены коррективы. Другими словами, снапшот на каждом отдельно взятом хосте может оказывать влияние на все виртуальные машины, использующее данное устройство хранения.
c. Файл снапшота может оказаться поврежденным.
d. Размер диска снапшотов оказывает непосредственное влияние на продолжительность времени, которое потребуется на удаление снапшота, относящегося к данной виртуальной машине.
Деревья снапшотов на Windows и Linux
3) Не делайте снапшотов памяти виртуальной машины:
a. Продолжительность времени, которое занимает у ESX хоста запись памяти на диск, коррелирует с объемом памяти, на использование которого настроена виртуальная машина. Это может увеличить время на завершение операции, что в свою очередь может замедлить производительность виртуальной машины.
b. Если нет острой потребности в возвращении виртуальной машины к конкретному состоянию памяти, отключите опцию «Память». Состояние памяти редко может потребоваться.
4) Используйте более одного снапшота для промежутка времени в 24–72 часа.
Хотя 2–3 дня — это рекомендуемый период, иногда снапшот хранится 5 дней, а затем автоматически удаляется:
a. Это предотвращает снапшоты от разрастания до такого большого размера, который может вызвать проблемы при удалении его с диска виртуальной машины.
b. Сделайте снапшот и удалите его сразу после того, как внесете необходимые коррективы.
c. Будьте аккуратны со снапшотами высокозагруженных виртуальных машин, таких как серверы баз данных и почтовые серверы. Такие снапшоты могут быстро увеличиваться в размерах, заполняя пространство хранилища. Удаляйте снапшоты с виртуальных машин, как только они перестают быть необходимыми.
5) Виртуальные машины с несколькими дисками:
a. Снапшот может повлиять на дочерний или резервный диск: чем больше операций совершается с диском, тем больше он становится.
b. Требования к свободному пространству дочернего диска дополняют требования к родительскому диску, от которого он зависит.
c. Дочерний диск может вырасти до такого размера, что заполнит все пространство для хранения.
d. Существует правило «Без снапшотов» для дополнительных дисков размером 100 Гб и больше, поскольку есть вероятность заполнения хранилища данных и прекращения работы всех виртуальных машин, которые используют одно и то же хранилище.
e. Дополнительные диски более 100 Гб размером считаются независимыми — это предотвращает переход влияние снапшота с родительского диска на дочерний.
Вместо заключения
Снапшот позволяет запечатлеть состояние виртуальной машины в конкретный момент времени. Снапшоты полезны в том случае, если требуется вернуться к одному состоянию виртуальной машин без необходимости создавать новые.
Снапшот несет следующую информацию:
LVM: использование снапшотов
Введение
В данной статье рассмотрены принципы и методики по применению снапшотов. Для более лучшего понимания материала необходимо знать, что такое LVM на базовом уровне и уметь оперировать с PV, VG, LV.
Назначение и принцип работы снапшотов
Снапшоты отчасти относятся к системам резервного копирования, но по сути не являются бэкапом, а лишь позволяют возвращать данные в исходное состояние на определенный момент времени. Так, когда необходимо сделать полный бэкап (например, сервера с активной базой данных), понадобится останавливать запись на диск и только потом снимать копию, т.к. в противном случае не все данные попадут в копию. Вариант с наличием slave-базы в счёт не берется, т.к. это частный случай ещё одной возможности для создания резервной копии. При больших объемах копирование может занимать несколько часов и более, что недопустимо для production-систем, работающих 24\7 – ведь никто не останавливает боевую базу для снятия дампа.
В таких случаях при необходимости создания полной копии без остановки на запись (почти) и приходят на помощь снапшоты. При создании снапшота происходит моментальный снимок или “заморозка” данных. Процесс создания снимка происходит, как правило, очень быстро – приложение или операционная система на какое-то непродолжительное время приостанавливает запись, и в этот момент создается моментальный снимок текущего состояния данных. Под приостановкой записи подразумевается, что приложение будет работать, но процессы записи на диск осуществляться не будут. Для клиента это может выглядеть как некая кратковременная задержка. Длительность такой задержки будет зависеть от приложения и его размера.
COW (Copy-On-Write)
Итак, разобравшись, что такое снапшот и когда он применяется, необходимо понимать, что происходит с файлами после создания снимка. Снапшот создан, и все старые файлы, т.е. которые не изменялись на момент создания снимка, остались на месте. А вот новые файлы или изменения для существующих уже будут записаны в новое расположение файловой системы на диске. Даже когда модификация данных завершена, старые данные никогда не перезаписываются. По сути будет создан ещё один файл, в котором содержатся все изменения (дельта), которые происходят с исходными данными. Таким образом достигается экономия дискового пространства засчет хранения лишь изменений на диске, а не полной копии данных. Технически происходит следующее: при необходимости изменения старого файла создается reflink и выделяется место под изменения.
Поэтому есть общие рекомендации и напоминания относительно снапшотов:
По большей части со снапшотами приходится сталкиваться при работе с виртуальными машинами. И действительно, очень удобно бывает сделать снимок виртуалки, провести эксперимент и откатиться на снапшот в случае неудачи. Но возможность создания снапшотов также присутствует и в LVM – когда-то давно я описывал базовые принципы работы LVM в своей статье. Теперь же будет рассмотрен дополнительный функционал по работе со снапшотами.
LVM1 vs LVM2
Перед продолжением, стоит кратко упомянуть, что существуют две версии – LVM1, которая имеет несколько отличий от LVM2. Самым главным отличием является следующее:
Под таблицей исключений понимается хеш-таблица, в которой записываются все сопоставления относительно изменений блоков и таблицы CoW. Но это уже глубокие технические подкапотные детали, с которыми можно ознакомиться по ссылке.
В целом обе версии можно использовать, но у второй есть несомненное преимущество в виде возможности изменений в самом снапшоте.
Пример использования
Подготовительные работы
После того, как с теорией разобрались, пора переходить к практике! В качестве лабораторного стенда будет использоваться Centos 7 с установленным пакетом lvm2:
Отличительной особенностью является то, что для создания снапшота в VG должно быть свободное пространство, которое будет использоваться для записи изменений, т.е. это место будут занимать изменяемые данные в исходном томе, которые “доезжают” уже после создания снапшота. Поэтому в качестве примера был создан LV размером 2,5 Гб, а остальное пространство осталось неиспользованным:
Далее LV был смонтирован по пути /mnt, и туда записаны произвольные файлы:
Команда ниже показывается, что в данный момент присутствует только один LV, готовый к работе (в выводе lvs attr есть флаг “о” – open):
Создание снапшота
Для создания снапшота достаточно выполнить команду ниже. Используется lvcreate, т.к. снапшот по сути является LV, но особенностью является то, что необходимо указать размер, куда будут записываться изменения. Для этого должно быть свободное место в VG, в данном случае из доступных 2,5 Гб указывается 1 Гб и наименование снапшота – snap_vg_data:
Т.к. снапшот – это по сути LV, проверить его наличие можно командой ниже:
Как видно из команды выше, у исходного тома и снапшота появились новые атрибуты:
Также можно посмотреть более подробный вывод про LV или снапшот, где вся информация будет в расширенном виде:
Помимо атрибутов, появилось поле Data (Allocated to snapshot в lvdisplay), которое показывает свободное место для снапшота в процентах. На данный момент весь выделенный гигабайт свободен, т.к. в исходный том в /mnt не было записано никаких изменений.
Теперь же в исходный том будут внесены изменения для демонстрации поведения снапшота:
Был создан простой файл, забитый нулями, размером 512 Мб. И в lvs это изменение сразу учитывается:
Ещё одним способом для наглядной проверки использования места снапшотом является утилита dmsetup:
В выводе выше интересны последние три цифры:
При записи на исходный том количество мета секторов будет увеличиваться.
Повреждения снапшота
Может возникнуть логичный вопрос, а что произойдет, если все секторы будут использованы, и отведенный гигабайт исчерпается? Такой снапшот станет непригодным для использования. Так, если создать ещё один файл через dd и после посмотреть статус:
…то можно увидеть, что статус снапшота теперь Inactive в выводе lvs и Invalid в dmsetup.
Такой снепшот непригоден для использования и его остаётся только удалить:
Для предотвращения такой ситуации настоятельно рекомендуется сохранять размер снапшота таким же, как у исходного логического тома, чтобы минимизировать риск повреждения снапшота. Это можно делать в автоматическом режиме, добавив параметры в /etc/lvm/lvm.conf:
Максимальный размер снапшота – 1 Гб. Если его размер превысит 70% от допустимого размера, то есть будет занято 700 Мб, то допустимый размер будет увеличен на 20%, т.е. 1,2 Гб и т.д. Размер моментального снимка LVM будет продолжать увеличиваться до тех пор, пока есть свободное место в VG.
Монтирование снапшота
После повреждения и удаления снапшота, необходимо создать новый уже известной командой:
Но теперь для использования функционала LVM2 можно смонтировать снапшот в отдельную точку /mnt/2:
А в syslog появится сообщение: kernel: XFS (dm-3): Filesystem has duplicate UUID 78db9895-a427-4906-b496-fbd5df8a3ca3 – can’t mount
Причина тому проста: XFS имеет UUID, которые являются уникальными идентификаторами файловой системы. Две файловые системы с одинаковым UUID не могут быть смонтированы на одном сервере. Поскольку снапшоты по сути представляют собой одну и ту же файловую систему, UUID для обоих устройств будут одинаковыми, поэтому и используется ключ nouuid при монтировании.
Теперь имеются две точки монтирования, одна из которых является снапшотом. Для примера можно внести изменения в файлах на /mnt2, а после выполнить слияние с исходным LV.
Слияние (merge) снапшота с исходным LV
Данный функционал очень удобен при выполнении различных экспериментов. Самый простой, для примера: есть софт, который меняет файлы на диске. Перед применением на продакшене, необходимо проверить, что всё будет работать корректно. Смонтированный снапшот продуктивной LV идеально подойдет для проведения эксперимента – в случае его успешности можно будет выполнить слияние с исходным томом или же просто удалить. Исходная файловая система при этом никак не пострадает. Применение данного функционала можно найти в различных случаях.
На снапшоте для некоторых файлов вносятся изменения, после чего необходимо отмонтировать исходный LV и сам снапшот:
lvdisplay должен показывать, что LV том не используется и значение open равно нулю:
Теперь можно запустить слияние всех изменений из снапшота в исходный LV:
Наблюдать за прогрессом изменения секторов можно через dmsetup:
В конечном итоге, если слияние завершилось, атрибуты будут следующие:
Если кажется, что процесс подвис, а в dmsetup не происходит изменений, то нужно убедиться, что LV том не примонтирован. Если попытаться смонтировать том, то будет ошибка Command on LV vglxc/wikisnapshot is invalid on LV with properties: lv_is_merging_cow. В таком случае можно попытаться перезапустить мерж, указав аргументом наименование VG:
Заключение
В статье были рассмотрены теоретические аспекты назначения и применения снапшотов, а также проведены практические проверки на примере LVM2 в Centos 7. Резюмируя, стоит выделить основные моменты, о которых стоит помнить (повторюсь для закрепления):
И ремарка по целесобразности использования снапшотов в прицнипе: конечно, в чистом виде создание снапшотов так или иначе тормозит работу приложения, но по идее всего лишь на несколько секунд плюс-минус. Но в любом случае при наличии критичной highload-системы и высокого SLA, создание снапшота на работающем сервере никто выполнять не будет – как минимум, такие серверы выводят из эксплуатации (методом исключения из балансировки, например), и далее уже выполняют создание снапшота, если это необходимо, или используют иные средства. А на всех же прочих не столь критичных системах вполне допустимо появление кратковременной задержки в пару секунд при создании снапшота опять же, если такой необходимо создать – например, перед обновлением какого-либо софта.
Лично мне не доводилось использовать снапшоты LVM, т.к. обычно я пользуюсь снапшотами, которые предоставляет делать гипервизор для виртуальных машин. Принцип работы такой же, что описан в начале статьи. Но также есть серверы, доступа к которым из консоли гипервизора у меня нет, и вот тут в теории уже можно будет попробовать использовать возможности снапшотов в LVM.