Snapshot виртуальной машины что это
Snapshot виртуальной машины что это
Всем привет сегодня хочу затронуть вопрос снапшотов (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:
Использование моментальных снимков (Snapshots) в Hyper-V
Моментальные снимки: сложно о простом
Наверняка многие знакомы с достаточно полезной функцией многих продуктов виртуализации – моментальными снимками, в простонародье – «снапшоты» (snapshots). Снапшот виртуальной машины – это как сохранение в игре: в случае, если где-то сильно накосячил (патч Бармина применил, например) – можно вернуться назад и повторить все заново. В этой статье я попытаюсь более-менее подробно рассказать о работе моментальных снимках и о некоторых нюансах их применения. В статье речь пойдет о Microsoft Hyper-V, но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).
Прежде, чем продолжать – вспомним, из каких компонентов состоит виртуальная машина:
Файл конфигурации – основа виртуальной машины, хранит все настройки, касающиеся виртуалки. Представляет собой XML-файл, имеющий, как ни странно, расширение XML. В VirtualPC/Virtual Server этот файл имел расширение VMC.
Файл виртуального диска. Обычно в качестве жесткого диска виртуальные машины используют специальные файлы-образы, имеющие расширение VHD. Этот формат, изначально разработанный фирмой Connectix, после приобретения ее корпорацией Microsoft стал использоваться в продуктах виртуализации, и не только в них: в частности, они используются в Microsoft Software iSCSI Target, а в ОС Windows 7 и Windows Server 2008 R2 с VHD-дисками можно работать на уровне ОС, вплоть до загрузки с них самой операционки.
Дифференциальные диски – основа технологии снапшотов. При создании снапшота запись в VHD-файл прекращается, и все последующие изменения записываются в отдельный файл, имеющий расширение VHD.
Сохранение состояния (Save State) – одна из полезных функций системы виртуализации. При сохранении состояния все содержимое памяти виртуальной машины, регистров процессора и т.д. сохраняется в специальные файлы, и виртуалка переходит в состояние «Выключено». После этого можно делать все что угодно, вплоть до перезагрузки хостовой машины, а потом снова запустить виртуалку – и она будет работать, как ни в чем не бывало, ровно в том же состоянии, в каком она была до сохранения. Примерно так же работает функция Hibernate в Microsoft Windows с единственным лишь отличием – сохранение состояния происходит на уровне самой виртуальной машины, а не на уровне гостевой ОС. В VirtualPC и Virtual Server для сохранения содержимого памяти использовался файл с расширением VSV, в Hyper-V же их стало аж целых два – BIN и VSV.
Файл экспорта. Если виртуальную машину Hyper-V нужно склонировать, или же перенести на другой хост – необходимо произвести операцию экспорта, а затем импорта. При экспорте конфигурационный XML-файл преобразуется в файл с расширением EXP. В VirtualPC и Virtual Server для этого достаточно просто скопировать файлы виртуальной машины, а в Hyper-V придумали импорт/экспорт – как они сами говорят, в целях безопасности.
Различают два типа моментальных снимков: онлайновый и оффлайновый. Онлайновым называют снапшот, сделанный на виртуальной машине с запущенной гостевой ОС. Соответственно, если виртуальная машина была в состоянии «выключено» — то снапшот будет называться оффлайновым. Для пользователя нет абсолютно никаких различий между онлайновыми и оффлайновыми снапшотами. Различаются они только по составу файлов, потому что при создании снапшота на запущенной виртуалке происходит операция Save State, и данные Save State включаются в состав снапшота
Что можно и что нельзя делать с моментальными снимками?
Как уже было сказано, снапшоты виртуальных машин – это то же самое, что и сохранение в игре. И единственное их назначение – обеспечение точки возврата на случай возможных ошибок. Снапшоты – это не бэкап, и использовать их для аварийного восстановления не получится. Использовать моментальные снимки в production-среде не рекомендуется, потому что это может привести к падению производительности, почему это так – будет понятно далее из статьи. Если необходимо часто создавать резервные копии для защиты от ошибок пользователей – необходимо использовать другие средства, к примеру – инкрементные бэкапы или журналы транзакций, если речь идет о базах данных.
Помимо этого, необходимо помнить, что управлять снапшотами можно и нужно только через стандартные средства Hyper-V (оснастка MMC Hyper-V Manager, WMI-провайдеры, командлеты PowerShell) и сторонний софт, использующий такие средства – например Microsoft SystemCenter Virtual Machine Manager.
Ну и теперь скажу несколько слов в заключение.
Во-первых – как я уже говорил, нужно помнить про «Delete means Apply, Apply means Delete», и думать перед нажатием кнопки, дабы не потерять ничего.
Во-вторых, если виртуальная машина содержит онлайновые снапшоты – ее крайне не рекомендуется экспортировать и переносить на другой сервер. Дело в том, что онлайновый снапшот содержит состояние регистров процессора и содержимое памяти, и применение такого снапшота в другом аппаратном окружении может привести к краху гостевой ОС.
В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде. Наверняка вам известно, что для продакшна рекомендуется использовать виртуальные диски фиксированного размера – для того, чтобы избавиться от фрагментации VHD-файла. Создавая же снапшоты, мы искусственно делим наш виртуальный диск на отдельные файлы – VHD и множество AVHD. На высоконагруженных системах это может привести к некоторому падению производительности. Кроме этого, при удалении снапшотов происходит операция объединения, которая тоже может сказаться на общей производительности системы, а к тому же может повысить время простоя при перезагрузках виртуальной машины. К примеру, если вы удалили один или несколько снапшотов на виртуальной машине, а потом потребовалось ее перезагрузить (к примеру – при установке апдейтов), то загрузка ОС не начнется, пока не завершится полностью операция объединения. Поэтому снапшоты можно использовать перед вводом в продакшн, для экономии времени при установке ПО и начальной настройке. После этого все снапшоты нужно удалить, дождаться окончания объединения, и только затем вводить в продакшн.
Еще один небольшой момент: в настройках Hyper-V можно задавать отдельно путь для размещения файлов виртуальных машин и путь для размещения VHD. По умолчанию и то и другое хранится на диске C:. Если для хранения VHD планируется использовать, к примеру, высокоскоростной RAID-массив – необходимо хранить на нем не только VHD, но и файлы виртуальных машин. Дело в том, что при создании снапшотов файлы AVHD будут храниться именно в том месте, которое было выбрано для хранения виртуальных машин. И может получиться так, что сам VHD будет храниться на отдельном дисковом массиве, а куча AVHD будет на диске С:, что не есть хорошо.
На этом я закончу этот пост, и без того уже большой. Прошу прощения за некоторый сумбур, тема при кажущейся простоте немного нетривиальна для объяснения. Для лучшего понимания советую посмотреть скринкаст, с анимированной презентацией и демонстрацией: www.techdays.ru/videos/1490.html
Если хаброобщественность не будет возражать – я могу дать ссылки на другие свои скринкасты и статьи про Hyper-V, дабы не кросспостить и не копипастить. Надеюсь, кого-то моя статья заинтересовала, в любом случае – спасибо заранее.
Снапшоты для виртуальных машин в облаке
Summary: Пост рассказывает о том, что такое снапшоты в облаке, как их использовать, и как они устроены.
Одна из самых заметных новых фич в облаке, появившаяся в этом году — снапшоты. Всё, что мы делаем, делится на три категории — то, что полезно нам (биллинг, сервисные утилиты и т. д.), то, что полезно клиентам, но визуально не заметно (например, СХД, смена версий гипервизора, уже ранее запущенных серверов), и то, что полезно клиентам и визуально заметно — и вот снапшоты как раз из этой третьей категории).
Хочу предупредить, что статья будет очень сложная. Я сначала расскажу про простые вещи — как с этим работать и какая от этого польза, а потом расскажу как это устроено внутри. И если с удобством и понятностью на «пользовательском» уровне мы, я надеюсь, справились, то вот с описанием устройства… Так сказать, мужайтесь или пропускайте.
Как использовать снапшоты?
Самым типовым применением снапшотов является создание резервных копий на случай ошибки в настройке машины. Сразу хочу предупредить, это важно: снапшоты хранятся там же, где и диски. Это означает, что если на нас упадёт метеорит или придёт другое стихийное бедствие федерального значения, то снапшоты будут утеряны одновременно с дисками, то есть для полноценных резервных копий следует использовать другое, географически от нас удалённое, место хранения. Мы совершенно не планируем терять диски клиентов или допускать стихийные бедствия в серверную, но предупредить я всё-таки обязан. 
Снапшот может быть выполнен в любой момент времени, на включенной или выключенной машине. В момент выполнения снапшотов дисковая активность машины слегка приостанавливается (речь идёт о чём-то порядка секунды), после чего продолжается «как ни в чём ни бывало». Методов сделать снапшот два: в свойствах диска на странице с виртуальными машинами (там же есть кнопка «откатиться на предыдущий снапшот») и в списке снапшотов на странице с дисками. Там же есть список всех снапшотов диска. Заметим, для виртуальной машины мы обычно не даём возможности создать снапшот во время установки. Особо пронырли внимательные клиенты могут найти, что кнопка «создать снапшот» на странице дисков всё-таки активна (и работает). Ничего интересного (кроме полу-установившегося линукса) в таком снапшоте не будет, но мы решили не забирать у людей возможность стрелять себе в ногу делать то, что они хотят со своими машинами.
Итак, созданный снапшот содержит в себе копию диска на момент создания. По размеру он чаще всего значительно меньше, чем диск. Если кому-то интересно, как высчитывается размер снапшота — смотрите вторую часть. Снапшоты образуют цепочку (если снапшоты делаются подряд) или дерево (как такое получается — см. раздел про откат на снапшот). Если удалить снапшот, то он начинает «растворяться» — объединяться с соседними (при этом общий объём снапшотов уменьшается). Процесс довольно быстрый (несколько минут — и снапшота нет).
Самой «вкусной» функцией снапшотов лично я считаю возможность подключить снапшот как диск. Подключается он в режиме read only (только для чтения), и позволяет посмотреть на «предыдущее» состояние диска. Никто не мешает сделать у диска 10 снапшотов и подключить все 10 к одной и той же машине — в этом случае диски будут представлять из себя хронологию «основного» диска.
Более того, снапшот можно подключать к любому количеству машин одновременно. (Сразу отвечаю на вопрос — можно ли грузиться с снапшота — формально, да, фактически файловая система очень нервничает от read only на root’е — мы работаем над этим вопросом).
Второй по важности функцией является откат диска на снапшот, то есть восстановление состояния диска. При этом изменения теряются, так что лучше перед откатом на старый снапшот сделать новый. В этом случае диск можно будет «переключать» между снапшотами (откатывать туда/обратно). У процесса отката на снапшот есть некоторые мелкие неудобства — становится недоступна статистика по дисковым операциям и неправильно показывается потребление машины в прошлом. Общее потребление по акаунту при этом высчитывается правильно, но так как образовывается новый VBD (блочное устройство), то данные для VM показываются для нового VBD. (Мы знаем про эту не очень очевидную особенность нашего биллинга и планируем его поменять на более удобную в обозримом времени).
Для удобства использования в последние несколько дней перед анонсом мы добавили «последний штрих» — если диск откатывается из снапшота, то у него появляется поле reverted_at (то есть «восстановлен из снапшота»). Мелочь, но полезная. Это поле будет преследовать диск до самой его смерти (и после, хе-хе, мы данные об объектах не удаляем).
Важный момент: каждый раз, когда делается или откатывается снапшот, наблюдается синдром «COW» (copy-on-write) — первая запись будет медленнее последующих. Так что на очень нагруженных серверах с большим количеством записи с созданию снапшотов следует относиться аккуратно.
Если сделать у диска несколько снапшотов, потом откатить диск на снапшот в «середине», потом сделать несколько снапшотов, потом откатить его на другой снапшот, потом снова откатить его, то образуется дерево снапшотов. Мы храним в нашей БД отношения — какой снапшот чьим является. К сожалению, визуализация пока в работе (программисты сильно протестуют, получив задачу «нарисовать дерево на JS», и пусть им будет стыдно при чтении этого поста).
Лимиты. К сожалению, вся эта роскошь не безгранична. Наши ограничения: длина цепочки снапшотов не более 20 дисков, максимальное количество снапшотов в дереве (с учётом ветвлений) — не более 60 шт. По нашим оценкам этого более чем достаточно для нормальной работы.
На странице «дисков» у каждого диска есть вкладка «снапшоты», где приводится список всех снапшотов диска. Снапшоты можно называть и давать им многострочное описание (но все ленивые, да, я тоже люблю, когда эти поля заполнены, но заполнять их обычно очень лень). В любом случае снапшот может быть уникально идентифицирован по абсолютно бесполезному номеру (англ. universally useless ID, uuid) и (частично) по дате создания.
Немного о поле «итого». В силу некоторых особенностей работы системы информация о снапшотах обновляется неравномерно — список снапшотов обновляется сразу после создания снапшотов, а вот поле «итого» может запаздывать некоторое время — до двух минут. В отличие от остальных ресурсов, которые мы обсчитываем в реальном времени, диски и снапшоты учитываются с (примерно) двухминутным интервалом. Поле «итого» высчитывается в момент вычисления объёма потребления, так что «итого» сразу после создания снапшота будет некорректным (но точно придёт в норму к следующему тику списания).
Как это устроено?
(просьба убрать от экранов несовершеннолетних детей и лиц с повышенной восприимчивостью, сейчас будет хардкор).
Наши снапшоты (как и диски) основываются на VHD-формате, который был придуман microsoft, отдан в публичное пользование и использован citrix. Он поддерживает очень эффективные снапшоты (они много эффективнее, чем снапшоты LVM, которые увеличивают количество записей пропорционально числу снапшотов). Когда выстраивается цепочка снапшотов, там неявным образом подразумевается «нулевой» снапшот, относительно которого фиксируются изменения всех остальных (без этого «нулевого» снапшота становится не понятно — что за «изменения» хранятся в первом снапшоте). Нулевой снапшот, разумеется, не оплачивается (т.к. физически места на диске не занимает).
При записи в «дырявый» блок этот блок копируется из «старого» снапшота в текущий диск (та часть, которую записали, заменяется, остальное берётся в предыдущей копии). После записи в текущем диске становится на одну дырку меньше и чтение этого места в дальнейшем идёт с «текущего» диска. Дисковые операции для дисков с снапшотами стоят столько же, сколько и обычные дисковые операции (лично я не уверен, насколько операции над снапшотами оказываются тяжелее обычных для наших СХД, так что решили эту область не трогать).
Что происходит при создании снапшота? (Техническая часть).
Текущий диск объявляется так называемым ‘base copy’, то есть read only копией состояния машины. Так как у диска могли быть предшественники в цепочке снапшотов, то base copy ссылается на другие base copy (заметим, base copy всегда ссылается только на base copy). Кроме этого делается ещё «снапшот» — это read/write копия текущего состояния (то есть отличия снапшота от base copy). В общем случае в снапшоты можно писать, но мы это запрещаем, так как в этом случае получится thin provision, а мы не можем его допустить из соображений гарантированности зарезервированного пространства (см раздел ниже). Но даже «незаписанный» снапшот содержит в себе 8Мб мета-данных. Таким образом, каждый снапшот состоит из двух половинок: метаданных (8Мб) и содержимого base copy. Диск ссылается одним видом ссылок на base copy предыдущего снапшота, а вторым видом ссылок на «снапшот». Когда происходит откат диска, то снапшот клонируется (не копируется — отсюда и нюансы с COW), ссылаясь на тот же самый base copy, на который ссылался снапшот, который был клонирован.
Если же кто-то два-три раза подряд сделает снапшот (без изменений данных), то получится одна base copy и три снапшота с мета-данными.
Когда снапшот удаляется (из середины), то происходит следующее: сам снапшот (метаданные) удаляется сразу, а вот base copy начинает расформировываться — данные переносятся либо в «предыдущее» состояние, либо в «будущее», либо вообще выкидываются (если есть альтернативное состояние и в прошлом, и в будущем). Этот процесс и есть «таяние» снапшота, которое происходит не мгновенно. Нужно сказать, что данные фактически не копируются, а всего лишь «перемаркируются» в рамках LVM (LE перекидываются между разными LV), либо удаляются (если в предыдущей копии есть другая версия блока).
Немного о thin provision
Один из вопросов, который нам задают по СХД, связан с thin provision. Что такое thin provision? Это когда потребителю декларируется некоторый объём места, а реально занятое место меньше — и увеличивается по мере фактической записи. Это отлично ложится на нашу модель с снапшотами, COW из «пустого места», да и в XCP реализовано отлично. Фактически, thin provision — это «запись в снапшот», то есть запись в «пустое место», которое от этого начинает занимать место в реальности.
Однако, thin provision опасен. Обратная сторона thin provision — overselling (он же oversubscription). Грубо говоря, есть у нас 100Тб места. Мы разрешили создать на таком хранилище 200 дисков по 1Тб. Фактический размер дисков в начале — гигабайт по 30-50, так что свободного места вволю. Но, вдруг, клиенты начинают писать на диски. Диски-то им уже выделены. Проходит немного времени, и… да, среднее заполнение дисков подползает к 500Гб. А потом… Потом кто-то хочет записать очередной гигабайт, но получает ошибку. Потому что место закончилось.
Мы не властны над дисками клиентов, и если мы им предоставили ресурсы — эти ресурсы их, и не наше дело говорить «сейчас можно, а сейчас нет». Если в отношении других ресурсов может быть компромисс (кому-то 3% процессора не дали, кого-то мигрировали на другой хост, чтобы обеспечить запас производительности), то есть незначительная «недопоставка» просто не ощутима, то в отношении дискового пространства такое не получится. Не дали записать хотя бы один сектор — по всему блочному устройству фиксируется ошибка.
Так что по здравому размышлению мы решили так не делать.
Из-за того, что снапшоты делаются в R/O, а после создания только уменьшаются, мы можем отказать в создании нового снапшота (всякое бывает — может и место внезапно кончиться), но мы точно не откажем в работе уже созданных дисков и снапшотов.