Сегодняшний пост должен был быть про обзор архитектуры Solaris COMSTAR и примерах его работы для построения FC-target. Однако требуется поставить точку в истории с таким продуктом как XenServer. Начало тут, тут и тут. Краткое содержание для тех кому лень кликать по ссылкам — при определенных операциях, например снапшотах DomU, хранилища дисков засираются непонятными «base copies» и со временем место заканчивается совсем. Мой пытливый ум всё-таки выяснил причину такого неудобства.

Как работают обычные snapshot-системы: LVM, ZFS (тут вообще отдельная песня правда но принцип тот же) и прочие-прочие

У нас есть диск в текущий момент (Dcurrent_real), мы заказали снапшот. Снапшот создаётся моментально т.к.
Снапшот(delta) призван хранить изменения, произошедшие с момента его создания.
При этом физически существует только диск Dcurrent_real ну и где-то там пишется delta
Диск на момент снапшота получается по схеме DpastVirtual = Dcurrent_real — delta
Соответственно поскольку мы имеем Dcurrent_real и он именно real, delta мы можем грохнуть как только в ней отпадёт необходимость

Как работают спроектированные любителями господа Говинды ихнего, снапшоты в XenServer

Мы заказываем снапшот диска Dcurrent_real. С этого момента он просто перестаёт существовать ибо переименовывается в ту самую 'base copy'
Снапшот (delta) так же призван хранить изменения, но изменения в диаметрально противоположном времени, т.е. не от текущего состояния диска в прошлое а от прошлого состояния в текущее.
При этом физически существует диск Dpast_real (та самая base copy) + пишется снапшот delta.
Диск на момент снапшота есть сразу — вот он, Dpast_real. А вот диск на текущий момент получается объеденением Dcurrent_virtual = Dpast_real + delta.
На самом деле на практике это не сильно тормозит, поскольку системе по большому счёту всё равно приходится лазить за данными в delta в обоих случаях для записи, а для чтения — разобраться читать нам из delta или из base copy, по сути всё равно.
Но возникает вопрос что же собственно делать с delta — мы не можем его убить т.к. Dcurrent_virtual просто перестанет существовать. А он живёт, работает и дарит миру данные через DomU.
Опомнившись, друзья выпускают тулзу coalesce-leaf, которая призванна хотя бы временно облегчить страдания, объеденяя Dpast_real и delta, однако для этого нужно минимально отправить DomU в suspend или даже выключить. А так же чешут репу в плане как бы всё-таки делать это находу.

Но почему? Ведь LVM поддерживает те самые правильные снапшоты… А всё потому что тенденция у друзей такова: постепенно перевести пользователей XenServer на Hyper-V. Что попало в Citrix, то скоро попадёт в M$, это всем давно известно. В результате сначала диски поменяли формат на Microsoft VHD а потом появились советы что эти самые диски хранить мол лучше на local file repository в виде файлов а не в виде разделов LVM. Видимо чтоб было проще скопировать в Hyper-V. В результате такой схемы нужно было реализовать систему снапшотов на хранилищах в виде файлов, а поскольку готового ничего не было, пытливый ум предложил вариант №2 — дибильный.

На этом история заканчивается и начинается переход на Solaris XVM, для чего даже был куплен на пробу суппорт план, о последствиях буду держать в курсе. По сути если не считать бага 6882364, на который я постоянно натыкаюсь, XVM стабилен и вполне готов для продакшна. Спасибо за внимание.

p.s. а ведь если бы Индия не была колонией Британии, всё могло быть совсем иначе…

Citrix XenServer — окончание истории