Комментарии 52
НЛО прилетело и опубликовало эту надпись здесь
Это вообще-то была шутка относительно «universally unique ID».
НЛО прилетело и опубликовало эту надпись здесь
Вы бы с моё с ними поработали, оценили бы её чуть лучше. В процессе наладки их десятками приходится копировать/указывать. И не дай бог кого-то с кем-то перепутать.
НЛО прилетело и опубликовало эту надпись здесь
Не пользователей, а администраторов. У нас регламент ввода пула в эксплуатацию включает в себя около 20 операций выставления правильных значений (чтобы не перепутать с тестингом, настроить шаблоны и т.д.).
Пользователи uuid'ы видят только для информационных целей (если будут какие-то сложные операции со сменой владельца — uuid единственное, что сохранится).
Пользователи uuid'ы видят только для информационных целей (если будут какие-то сложные операции со сменой владельца — uuid единственное, что сохранится).
Вы в начале говорите про VHD, а затем про LVM. На основе чего же реализованы снапшоты?
Снапшоты делаются средствами VHD. А вот сами VHD хранятся в LV на LVM. У нас используется SM lvmoiscsi для всех SR с дисками клиентов.
Такой подход позволяет получить все плюсы VHD и не получить минусов файловой системы (как было бы в случае использования file-based storage).
Такой подход позволяет получить все плюсы VHD и не получить минусов файловой системы (как было бы в случае использования file-based storage).
Всё равно не понял. Какое ПО управляет LE на LV в формате VHD?
/opt/xensource/sm/ISCSI* /opt/xensource/sm/LVM*
LVM — контейнер для VHD. Ниже я давал ссылку на сырцы snapwatchd, там рядом и все остальные элементы storage manager'а.
LVM — контейнер для VHD. Ниже я давал ссылку на сырцы snapwatchd, там рядом и все остальные элементы storage manager'а.
ммм, получается, это что-то специфичное для XEN?
Нет. Xen — гипервизор, он вообще ничего о блочных устройствах не знает.
Это специфично для драйвера blktap и поддержки VHD. Поскольку VHD вообще говоря кросс-платформенный стандарт, то всё, что есть в снапшотах у нас — это (теоретически) возможности формата. При этом XCP использует специфичный LVM (весьма серьёзно патченный, для поддержки кластеризации хранилища).
Весь 'storage manager' для XCP — набор питоновских программ, которые собирают в правильном порядке компоненты тулстека.
(Упреждая вопрос: нет, вытащить за пределы XCP малой кровью не получится, оно очень 'tightly build').
Это специфично для драйвера blktap и поддержки VHD. Поскольку VHD вообще говоря кросс-платформенный стандарт, то всё, что есть в снапшотах у нас — это (теоретически) возможности формата. При этом XCP использует специфичный LVM (весьма серьёзно патченный, для поддержки кластеризации хранилища).
Весь 'storage manager' для XCP — набор питоновских программ, которые собирают в правильном порядке компоненты тулстека.
(Упреждая вопрос: нет, вытащить за пределы XCP малой кровью не получится, оно очень 'tightly build').
Ну, я понимаю, что storage от виртуализации не зависит, так что спасибо за ответ на упреждающий вопрос.
А то как раз недавно вылезли проблемы на пустом месте из использования lvm-снапшотов. То, что они одноуровневые я смирился. Но вылезла проблема с зависанием (дедлок где-то) при удалении снапшота — вот эту проблему я сам не решу. Ваша статья вышла как раз вовремя. Жаль, что не удастся задейстовать этот механизм для KVM+LVM
А то как раз недавно вылезли проблемы на пустом месте из использования lvm-снапшотов. То, что они одноуровневые я смирился. Но вылезла проблема с зависанием (дедлок где-то) при удалении снапшота — вот эту проблему я сам не решу. Ваша статья вышла как раз вовремя. Жаль, что не удастся задейстовать этот механизм для KVM+LVM
Вот все бы ничего, и цены устраивают но пользоваться 10мбит/сек совсем не хочется.
А если канал делать более 10мбит/сек то цены у вас слишком кусачие видимо станут да?
Сейчас пользуюсь Rackspace Cloud + мощный сервер на ovh.co.uk(тут у меня 1gbps).
С удовольствием бы еще в России облачко взял но 10мбит/с сильно отталкивают.
А если канал делать более 10мбит/сек то цены у вас слишком кусачие видимо станут да?
Сейчас пользуюсь Rackspace Cloud + мощный сервер на ovh.co.uk(тут у меня 1gbps).
С удовольствием бы еще в России облачко взял но 10мбит/с сильно отталкивают.
Мне казалось что в облаке нет ограничений по трафику
При оплате по трафику мы предоставляем скорость в 1 гигабит без лимитов и соотношений — и вы сможете обеспечить и 50Мб/с в часы пик, и экономить деньги в моменты затишья из-за практически нулевой оплаты (нагрузка в 10 кб/с за месяц даст трафик чуть больше 3 Гб и сумму около 3 рублей).
В облачном сервере канал 1Гбит и тарификация по трафику. Ну а ВПС да, там оплата по мегабитам.
Но кто ж мешает то создать инстанс в облаке и платить по реальному потреблению?
Но кто ж мешает то создать инстанс в облаке и платить по реальному потреблению?
Мне нужно стабильно знать ширину канала и чтобы она не плавала.
к примеру в настройках радиосервера максимальное кол-во слушателей = ширина канала/битрейт потока
на сайте я увидел только 10мбит/сек а если поднимать то за каждый 1мбит/сек +100руб в мес.
Где вы увидели про 1Гбит?
к примеру в настройках радиосервера максимальное кол-во слушателей = ширина канала/битрейт потока
на сайте я увидел только 10мбит/сек а если поднимать то за каждый 1мбит/сек +100руб в мес.
Где вы увидели про 1Гбит?
Вы, судя по всему, используете услугу Виртуальный Linux Сервер, есть еще услуга Вычислительные ресурсы облака.
Вот во второй услуге вы также получаете VDS с linux на борту, только платите не фиксированную сумму за фиксированный конфиг, а самомасштабируемый сервер с оплатой за реально потребляемые ресурсы. Вот в этом случае вам дают Гигабитный канал а платите вы за трафик так как именно он определяет какую часть канала вы реально использовали.
Вот во второй услуге вы также получаете VDS с linux на борту, только платите не фиксированную сумму за фиксированный конфиг, а самомасштабируемый сервер с оплатой за реально потребляемые ресурсы. Вот в этом случае вам дают Гигабитный канал а платите вы за трафик так как именно он определяет какую часть канала вы реально использовали.
Ок, наверное дождусь как появится ubuntu 12.04 LTS и закажу да и посмотрю насколько удобно и выгодно.
У меня она на ноуте стоит, и я хочу сказать, что её сейчас к серверу на километр подпускать нельзя. То одно отвалится, то другое. Я думаю, мы после выхода 12.04 подождём хотя бы месяц, перед тем, как запускать в продакт (ubuntu любит выпустить, а потом срочно начать фиксить по мотивам недовольных клиентов, обнаруживших, что stable, это такой testing из debian'а).
У меня она с первых дней альфы еще стоит на моем компе.
В плане сервера ваще ничего не отваливалось. Какие-то рюшечки пользовательского интерфейса раньше чуток тупили но их нет в серверной оси.
В плане сервера ваще ничего не отваливалось. Какие-то рюшечки пользовательского интерфейса раньше чуток тупили но их нет в серверной оси.
А историю с «выходом» linux-3.2 задолго до появления релиза на kernel.org вы не заметили? Было ОЧЕНЬ смешно. На kernel.org/github'е — 3.2-rc5, а в бубунте во всю 3.2, типа релизнутый. От этой кривой зависимости они так и не избавились, пока нормальный 3.2 не прорелизили.
Несколько раз у них фигня в районе udev'а была. А udev — это уже очень серьёзно.
Несколько раз у них фигня в районе udev'а была. А udev — это уже очень серьёзно.
Мы только что сделали рассылку по клиентам — в эти выходные апгрейд внешних каналов до облака до 10G. Так что про 10Мб/с — это вы с какими-то другими услугами перепутали.
НЛО прилетело и опубликовало эту надпись здесь
Насколько я понял, снапшот снимается с работающей машины. Как обстоит тогда дело с дисковыми буферами гостевой ОС? Они сбрасываются на диск при создании снапшота?
И, опять же, в рамках моего понимания, снапшот самой виртуальной машины (xm save -c ) не производится? То есть данные, которые работавшая программа держала в памяти так и остаются в памяти?
И, опять же, в рамках моего понимания, снапшот самой виртуальной машины (xm save -c ) не производится? То есть данные, которые работавшая программа держала в памяти так и остаются в памяти?
Снапшот памяти нет. Нужно оно или нет — не знаю. Будут запросы, будем делать.
Снапшот не консистентен, да, увы. В Linux нет общего метода сделать консистентный снапшот.
ЗЫ У нас не используется xm :)
Снапшот не консистентен, да, увы. В Linux нет общего метода сделать консистентный снапшот.
ЗЫ У нас не используется xm :)
Да, я в курсе про xe. :)
Очень печально, что нельзя делать save с paused домена. Не понимаю, правда, почему, может расскажете? Ведь пауза для domU — это только прекращение выделения ему времени на CPU, так?
А то бы был красивый такой алгоритм:
Так бы мы получили неконсистентый снэпшот диска, ну да и ладно — вся память-то тоже в резерве есть.
Очень печально, что нельзя делать save с paused домена. Не понимаю, правда, почему, может расскажете? Ведь пауза для domU — это только прекращение выделения ему времени на CPU, так?
А то бы был красивый такой алгоритм:
- ставим на паузу, снимаем снэпшот диска
- снимаем снэпшот памяти
- снимаем с паузы
Так бы мы получили неконсистентый снэпшот диска, ну да и ладно — вся память-то тоже в резерве есть.
xe — это всего лишь утилита для работы с XenAPI. Внутри там часть делается xapi, а часть — libxl, то есть xl вполне себе работает.
Suspend машин в XCP есть, он требует отдельного SR для сохранения. Если нам его реализовывать (с аккаунтингом и прочими прелестями), то это примерно недели две работы. Будут запросы — сделаем.
Идея совмещать suspend копию машины с снапшотом диска… Спасибо, я подумаю.
ЗЫ На паузу ставить не обязательно, т.к. для памяти так же возможны мгновенные снапшоты (так работает миграция — сначала мигрируется память, потом изменения в памяти).
Suspend машин в XCP есть, он требует отдельного SR для сохранения. Если нам его реализовывать (с аккаунтингом и прочими прелестями), то это примерно недели две работы. Будут запросы — сделаем.
Идея совмещать suspend копию машины с снапшотом диска… Спасибо, я подумаю.
ЗЫ На паузу ставить не обязательно, т.к. для памяти так же возможны мгновенные снапшоты (так работает миграция — сначала мигрируется память, потом изменения в памяти).
Но если не поставить домен на паузу, то не понятно, в какой момент надо снимать снапшот с диска.
Была ещё кривая идея. С использованием XFS в гостевых доменах. Есть там такая штука как xfs_freeze: сбрасывает все буферы и блокирует FS на запись. Однако, понятно, что в условиях public cloud это неприменимо, так как нужен доступ к гостевой ОС (да ещё и с root-правами). А так, думаю, понятно:
Была ещё кривая идея. С использованием XFS в гостевых доменах. Есть там такая штука как xfs_freeze: сбрасывает все буферы и блокирует FS на запись. Однако, понятно, что в условиях public cloud это неприменимо, так как нужен доступ к гостевой ОС (да ещё и с root-правами). А так, думаю, понятно:
Сорри, задел не ту кнопку. :)
- xm console «xfs_freeze»
- снапшот диска
- снапшот памяти
- xm console «xfs_unfreeze»
Дело-то не в файловой системе. Проблема консистентных снапшотов много более общая — у майкрософта для этого есть механизм shadow copy, который посылает всем подписавшимся на информацию приложениям сообщение о том, что нужно создать консистентное состояние, и после этого делает freeze.
Просто sync'ом эту проблему не решить.
… А по моим наблюдениям, любая прилично журналируемая FS (ext3, ext4, xfs) после выполнения «внезапной» остановки (что есть эквивалент снапшота и отката на него) остаётся в консистентном (на уровне FS) состоянии.
Просто sync'ом эту проблему не решить.
… А по моим наблюдениям, любая прилично журналируемая FS (ext3, ext4, xfs) после выполнения «внезапной» остановки (что есть эквивалент снапшота и отката на него) остаётся в консистентном (на уровне FS) состоянии.
Согласен. FS, вероятнее всего, будет в норме (можно даже сразу после снапшота прогонять fsck). Но получается всё равно не универсально — приложения должны работать так, чтобы отключение питания не приводило к повреждению данных и была возможность восстановления работоспособности. Не все приложения таковы, к сожалению.
А вот про shadow copy я не знал. Но, в любом случае, универсальностью тут и не пахнет — пока разработчик windows-приложения не имплементирует обработку этого сообщения, это работать не будет.
А вот про shadow copy я не знал. Но, в любом случае, универсальностью тут и не пахнет — пока разработчик windows-приложения не имплементирует обработку этого сообщения, это работать не будет.
А кто занимается созданием и удалением (размазыванием) снапшотов? Ведь операция (особенно удаления) не атомарная и растянутая во времени, а запросы к виртуальному диску идти будут, причем и на запись — тоже. И необходимо обеспечить консистентность данных (в т.ч. и метаданных).
Запросы на запись идут только на «диск», снапшоты, а тем паче, base copy, намертво в RO. Запросы на чтение обрабатываются и base copy тоже, но эта операция очень простая: мы сначала переносим блок из удаляемого base copy, а потом меняем ссылку на него. Если на этот блок непрерывно идут запросы на чтение, то их часть пойдёт на старый блок, а часть на новый (но содержимое-то одинаково, так что никаких отличий не будет).
«Размазывает» base copy цитриксовский сервис по имени snapwatchd.
Сырцы всего этого дела публично доступны:
xenbits.xen.org/hg/XCP/1.1/xen-sm.hg/file/8f037812b8ed/snapwatchd/snapwatchd
«Размазывает» base copy цитриксовский сервис по имени snapwatchd.
Сырцы всего этого дела публично доступны:
xenbits.xen.org/hg/XCP/1.1/xen-sm.hg/file/8f037812b8ed/snapwatchd/snapwatchd
Если у кого-то (как и у меня) возникли сложности с пониманием работы снапшотов, вот мое переизложение:
1) при создании снапшота на самом деле «копия» диска не создается! Просто текущий диск замораживается и становится этим самым снапшотом.
2) на место текущего состояния диска мы подсовываем «пустой диск» и создаем новую таблицу сопоставления данных.
3) при записи (изменении данных) мы пишем в новый пустой диск, снапшот не трогаем.
4) не измененные данные берутся (читаются) напрямую из предыдущего состояния диска. Измененные данные читаются из нового диска.
5) в метаданных как раз и хранится таблица в которой описано какие блоки данных изменились и их надо читать из «текущего диска», а какие не менялись и их надо читать из снапшота («старого диска»).
6) при создании следующих снапшотов мы снова замораживаем текушее состояние диска и создаем очередную пустышку. Не измененные блоки данных могут ссылаться на предыдущие снапшоты вплоть до самого первого, где они реально хранятся.
7) вы платите за хранение только измененных данных в снапшотах. Например, был диск в 10Гб, вы сделали 2 снапшота, в первом изменений было на 100Мб, а во втором на 1Гб, вы будете платить за хранение 11,1Гб данных.
8) При удалении промежуточного снапшота его данные удаляются, попутно «вливаясь» в соседние снапшоты. Например, если удалить первый снапшот из предыдущего пункта, то вы уже будете платить только за хранение 11Гб данных, и откатиться можно будет только на самое первое состояние диска или на последний снапшот. Хммм, тут может возникнуть путаница с нумерацией снапшотов %)
Все это очень схоже с работой снапшотов в ZFS. Надеюсь, для кого-то хоть чуть-чуть прояснил топик.
1) при создании снапшота на самом деле «копия» диска не создается! Просто текущий диск замораживается и становится этим самым снапшотом.
2) на место текущего состояния диска мы подсовываем «пустой диск» и создаем новую таблицу сопоставления данных.
3) при записи (изменении данных) мы пишем в новый пустой диск, снапшот не трогаем.
4) не измененные данные берутся (читаются) напрямую из предыдущего состояния диска. Измененные данные читаются из нового диска.
5) в метаданных как раз и хранится таблица в которой описано какие блоки данных изменились и их надо читать из «текущего диска», а какие не менялись и их надо читать из снапшота («старого диска»).
6) при создании следующих снапшотов мы снова замораживаем текушее состояние диска и создаем очередную пустышку. Не измененные блоки данных могут ссылаться на предыдущие снапшоты вплоть до самого первого, где они реально хранятся.
7) вы платите за хранение только измененных данных в снапшотах. Например, был диск в 10Гб, вы сделали 2 снапшота, в первом изменений было на 100Мб, а во втором на 1Гб, вы будете платить за хранение 11,1Гб данных.
8) При удалении промежуточного снапшота его данные удаляются, попутно «вливаясь» в соседние снапшоты. Например, если удалить первый снапшот из предыдущего пункта, то вы уже будете платить только за хранение 11Гб данных, и откатиться можно будет только на самое первое состояние диска или на последний снапшот. Хммм, тут может возникнуть путаница с нумерацией снапшотов %)
Все это очень схоже с работой снапшотов в ZFS. Надеюсь, для кого-то хоть чуть-чуть прояснил топик.
А вот это очень понятно и доступно, спасибо.
Только что закончил перенос со старого облака на новое. Заметил, что денег кушается меньше на 10%-20%.
Либо я лучше настроил сервер, либо все эти инновации позволяют более эффективно расходовать ресурсы. А скорее всего — и то и другое вместе.
Только что закончил перенос со старого облака на новое. Заметил, что денег кушается меньше на 10%-20%.
Либо я лучше настроил сервер, либо все эти инновации позволяют более эффективно расходовать ресурсы. А скорее всего — и то и другое вместе.
Скорее всего уменьшились расходы на RAM за счет включенного overcommit'а, в первом пуле он был выключен по техническим причинам.
А можно поподробноее пояснить «overcommit RAM»? Важный нюанс.
memory overcommit — обычный режим работы linux. Для 2.6.34 пришлось его отключить, потому что там были неприятные проблемы с oom killer'ом, усиливаемые присутствием xen'а.
(На всякий случай) к оверселлу в openvz и подобным вещам не имеет никакого отношения, это фича исключительно и только самого ядра linux в отношении своих собственных процессов.
(На всякий случай) к оверселлу в openvz и подобным вещам не имеет никакого отношения, это фича исключительно и только самого ядра linux в отношении своих собственных процессов.
goo.gl/43nN3 как я уже написал в старом пуле по умолчанию overcommit выключен (иначе ВМ вываливались в Kernel Panic), в новом пуле с новыми ядрами ВМ overcommit включен.
А вот у меня вопрос, наверняка глупый.
Можно ли как то сделать из снапшотов подобие резервного копирования? Например, автоматическое создание нового шота каждые сутки и затирание старых?
Догадываюсь, что все не просто, но может кто-то прояснит?..
Можно ли как то сделать из снапшотов подобие резервного копирования? Например, автоматическое создание нового шота каждые сутки и затирание старых?
Догадываюсь, что все не просто, но может кто-то прояснит?..
Вполне можно, но пока не опубликовано клиентское API, вам придется делать это вручную через клиентскую панель, или мудрить с http запросами (будет очень не удобно, особенно, удалять старые снапшоты). Для бэкапов пока лучше использовать второй сервер или подождите немного, у нас кое-что уже почти готово ;)
В планах есть, но чуть позже.
Побаловался со снапшотами — прикольно. Использовал для создания копии сервера перед обновлениес ОС, на всякий случай.
3 дня назад удалил их, а в билинге до сих пор уходят деньги.
Задал вопрос в ТП и получил потрясающий ответ:
amarao, можете прокомментировать? У меня нет желания выключать 2 сервера на полчаса. Даже на 5 минут нет.
С другой стороны платить лишних 3 рубля в сутки за неиспользуемую услугу тоже как-то не хочется.
Да и что получается, для подстраховки использовать снапщоты нельзя, ибо придется потом машину выключать?
3 дня назад удалил их, а в билинге до сих пор уходят деньги.
Задал вопрос в ТП и получил потрясающий ответ:
По техническим причинам для полного исключения информации о снапшотах требуется на 20-30 минут
выключить виртуальную машину. В течении нескольких часов после включения машины объем снапшотов
в статистике должен снизиться до нуля.
Если после выполнения данной операции вид статистики по снапшотам не изменится,
пожалуйста, уведомите нас.
amarao, можете прокомментировать? У меня нет желания выключать 2 сервера на полчаса. Даже на 5 минут нет.
С другой стороны платить лишних 3 рубля в сутки за неиспользуемую услугу тоже как-то не хочется.
Да и что получается, для подстраховки использовать снапщоты нельзя, ибо придется потом машину выключать?
Снапшотов уже нет, а статья есть, непорядок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Снапшоты для виртуальных машин в облаке