Задать вопрос
@32e26c4c
Интересующийся

Аналог дифференцированных виртуальных дисков в Linux?

Добрый день,

В Windows Server 2016 (роль iSCSI Target) есть интересная функция:
С помощью разностных виртуальных жестких дисков (VHD) можно использовать один образ операционной системы (the "главный образ") для загрузки до 256 компьютеров. Например, предположим, что вы развернули Windows Server с образом операционной системы размером примерно 20ГБ, а в качестве загрузочного тома использовали два зеркальных диска. Для загрузки 256 компьютеров потребуется примерно 10 ТБ памяти — только для образа операционной системы. Но при загрузке с помощью сервера цели iSCSI используется 40 ГБ для базового образа операционной системы и 2 ГБ для разностных виртуальных жестких дисков на экземпляр сервера, что в сумме составляет 552 ГБ для образов операционной системы. Это позволяет сэкономить более 90% памяти только для образов операционной системы.


Ссылка на docs.microsoft.com

Есть ли что-то подобное в Linux?

Пересмотрел таргеты (LIO, istgt, STGT, IET, SCST), но ничего похожего не увидел...
Может в Linux это реализуется не сервисом iscsi, а на уровне файловой системы ?

Подскажите, пожалуйста, в какую сторону копать...
  • Вопрос задан
  • 488 просмотров
Подписаться 1 Средний 3 комментария
Пригласить эксперта
Ответы на вопрос 6
@Wexter
Предположу что под капотом оно подключает два диска, один на ОС, второй на пользовательские данные.
В теории в линуксе можно организовать подобное
Ответ написан
Комментировать
@Vitsliputsli
Если я правильно понял, есть базовый неизменный образ который используют все машины, а изменения характерные для каждой машины хранятся отдельно? Если так, то почитайте про AUFS и UnionFS, эти файловые системы давно появились, так что может уже и еще чтото новое есть.
Ответ написан
Комментировать
mikes
@mikes
Есть ли что-то подобное в Linux?

смотря что понимать под словом линукс
в proxmox такое есть (linked clone)

А вообще есть хранение в LVM когда нет "образов" дисков, а есть и дедупликация на уровне FS (ZFS)
но нужно понимать, что это не будет бесплатно в плане производительности.. равно как и в MS.
Ответ написан
Комментировать
@pfg21
ex-турист
если идти чисто от файла с образом системного корня на разделе с zfs.
то сделать копии оригинального readonly файла (вместо полного копирования должен создаться новый inode с указателями на блоки данных оригинального файла).
а потом использовать.
при изменении в копию запишутся только измененные блоки данных и в иноде ссылки поменяются. а все неизменное так и будет указывать на блоки данных оригинала. CoW однако :)
данные оригинального файла не изменятся.
будет лежать куча больших файлов, которые в сумме будут занимать не сильно больше оригинала.
Ответ написан
Комментировать
@MechanID
Админ хостинг провайдера
Подобное можно реализывать при помощи LVM thin или ZFS - с оригинального образа делается нужно кол-во снапшотов которые потом используются для запуска виртуалок или контейнеров, например proxmox такое умеет в бесплатной версии прямо из коробки. https://pve.proxmox.com/wiki/VM_Templates_and_Clones вам нужно linked Clone
Ответ написан
Комментировать
@rPman
unix way - не пытайтесь найти готовый комбаин, собирайте ваше решение из кирпичиков. Пусть за iscsi отвечает тот же istgt а за снапшоты - btrfs.

Если закрыть глаза именно на iscsi (мало ли вы виртуальные машины через них подключаете локально, видел я такие конструкции) У qemu/kvm есть опции когда можно подключить диск но все изменения пишутся в отдельный файл. То же самое есть у всех крупных систем виртуализации, правда называется везде по разному.

Если универсально, то исторически lvm позволяет делать снапшоты на блочных устройствах, но за счет значительного понижения производительности, т.е. вы можете создать 100500 снапшотов на основе вашего базового диска, и каждый отдать в свою отдельную машину. Не рекомендую для вашего случая 256 активных снапшотов это будет фейл.

Вы можете воспользоваться copy on write файловыми системами например btrfs или zfs (хуже в linux работает), в них создание снапшота не понижает производительность (т.е. за это не приходится платить), правда сами файловые системы менее шустрые, так как сильно фрагментируют контент, но если сравнивать с lvm то на порядок эффективнее.

p.s. windows машины очень активно пишут при обновлениях, гигабайтами, наступит момент, когда весь этот сыр бор будет создавать больше проблем чем пользы.
btrfs и zfs имеют фичу - дедупликация, т.е. вы просто рядом складываете все копии ваших контейнеров а система сама находит одинаковые блоки и оптимизирует, правда в зачаточном уровне, btrfs только offline (это относительно новая фича, почти нет нормальных утилит, но если ставить самую свежую версию из исходников, там много что добавили вкусного) а у zfs под linux жутко низкая производительность (я игрался на десктопном железе, не рекомендуется для hdd только ssd), причем ничем не оправданная, и дикое потребление оперативной памяти (70 байт на блок, т.е. для 4кб блоков 1тб hdd будет кушать 18гб ram, правда никто не делает 4к блоки, 16 или 32 да), она будет оправдана в вашем случае и автоматически сократит занятое место одинаковыми машинами.

p.p.s. только что установленный windows со включенным сжатием zfs занимает на диске 8гб места, btrfs чуть больше... через год использования место, занимаемое контейнером (никаких программ не установлено, это машина была исключительно для запуска google chrome) - 26гб (внутри контейнера 46гб).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы