company_banner

Снапшоты для виртуальных машин в облаке

    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, а после создания только уменьшаются, мы можем отказать в создании нового снапшота (всякое бывает — может и место внезапно кончиться), но мы точно не откажем в работе уже созданных дисков и снапшотов.
    Selectel
    IT-инфраструктура для бизнеса

    Comments 52

      –1
      По теме сказать нечего, но сама статья, это что-то с чем-то. Unversally Useless ID — это пять! Ни русский, ни английский, а какая-то каша.
        +8
        Это вообще-то была шутка относительно «universally unique ID».
          0
          Тонкий юмор.
            0
            Вы бы с моё с ними поработали, оценили бы её чуть лучше. В процессе наладки их десятками приходится копировать/указывать. И не дай бог кого-то с кем-то перепутать.
              0
              Трудно оценить как программисту, т.к. если пользователей заставляют копировать руками UUID — разработчикам системы надо отрубать руки.
                0
                Не пользователей, а администраторов. У нас регламент ввода пула в эксплуатацию включает в себя около 20 операций выставления правильных значений (чтобы не перепутать с тестингом, настроить шаблоны и т.д.).

                Пользователи uuid'ы видят только для информационных целей (если будут какие-то сложные операции со сменой владельца — uuid единственное, что сохранится).
        0
        Вы в начале говорите про VHD, а затем про LVM. На основе чего же реализованы снапшоты?
          +3
          Снапшоты делаются средствами VHD. А вот сами VHD хранятся в LV на LVM. У нас используется SM lvmoiscsi для всех SR с дисками клиентов.

          Такой подход позволяет получить все плюсы VHD и не получить минусов файловой системы (как было бы в случае использования file-based storage).
            0
            Всё равно не понял. Какое ПО управляет LE на LV в формате VHD?
              +1
              /opt/xensource/sm/ISCSI* /opt/xensource/sm/LVM*

              LVM — контейнер для VHD. Ниже я давал ссылку на сырцы snapwatchd, там рядом и все остальные элементы storage manager'а.
                0
                ммм, получается, это что-то специфичное для XEN?
                  +1
                  Нет. Xen — гипервизор, он вообще ничего о блочных устройствах не знает.

                  Это специфично для драйвера blktap и поддержки VHD. Поскольку VHD вообще говоря кросс-платформенный стандарт, то всё, что есть в снапшотах у нас — это (теоретически) возможности формата. При этом XCP использует специфичный LVM (весьма серьёзно патченный, для поддержки кластеризации хранилища).

                  Весь 'storage manager' для XCP — набор питоновских программ, которые собирают в правильном порядке компоненты тулстека.

                  (Упреждая вопрос: нет, вытащить за пределы XCP малой кровью не получится, оно очень 'tightly build').
                    0
                    Ну, я понимаю, что storage от виртуализации не зависит, так что спасибо за ответ на упреждающий вопрос.

                    А то как раз недавно вылезли проблемы на пустом месте из использования lvm-снапшотов. То, что они одноуровневые я смирился. Но вылезла проблема с зависанием (дедлок где-то) при удалении снапшота — вот эту проблему я сам не решу. Ваша статья вышла как раз вовремя. Жаль, что не удастся задейстовать этот механизм для KVM+LVM
                      +2
                      Снапшоты LVM — зло. Не используйте их. В новых версиях ядра пилят альтернативную модель для device mapper, но явно предупреждают «не подпускайте это к продакту».

                      Надеюсь, что когда они допилят, LVM-снапшоты будут не хуже, чем netapp'овские.
                        0
                        Где ж вы раньше были ) Я верил в LVM ) А пару недель назад возникла необходимость в них — я и задействовал. А теперь вылезли проблемы. Если не пропадут — прийдётся переехать на QCOW2.
          –1
          Вот все бы ничего, и цены устраивают но пользоваться 10мбит/сек совсем не хочется.
          А если канал делать более 10мбит/сек то цены у вас слишком кусачие видимо станут да?
          Сейчас пользуюсь Rackspace Cloud + мощный сервер на ovh.co.uk(тут у меня 1gbps).
          С удовольствием бы еще в России облачко взял но 10мбит/с сильно отталкивают.
            +2
            Мне казалось что в облаке нет ограничений по трафику
            При оплате по трафику мы предоставляем скорость в 1 гигабит без лимитов и соотношений — и вы сможете обеспечить и 50Мб/с в часы пик, и экономить деньги в моменты затишья из-за практически нулевой оплаты (нагрузка в 10 кб/с за месяц даст трафик чуть больше 3 Гб и сумму около 3 рублей).
              +2
              В облачном сервере канал 1Гбит и тарификация по трафику. Ну а ВПС да, там оплата по мегабитам.
              Но кто ж мешает то создать инстанс в облаке и платить по реальному потреблению?
                –1
                Мне нужно стабильно знать ширину канала и чтобы она не плавала.
                к примеру в настройках радиосервера максимальное кол-во слушателей = ширина канала/битрейт потока
                на сайте я увидел только 10мбит/сек а если поднимать то за каждый 1мбит/сек +100руб в мес.
                Где вы увидели про 1Гбит?
                  +2
                  Вы, судя по всему, используете услугу Виртуальный Linux Сервер, есть еще услуга Вычислительные ресурсы облака.
                  Вот во второй услуге вы также получаете VDS с linux на борту, только платите не фиксированную сумму за фиксированный конфиг, а самомасштабируемый сервер с оплатой за реально потребляемые ресурсы. Вот в этом случае вам дают Гигабитный канал а платите вы за трафик так как именно он определяет какую часть канала вы реально использовали.
                    0
                    Ок, наверное дождусь как появится ubuntu 12.04 LTS и закажу да и посмотрю насколько удобно и выгодно.
                      0
                      У меня она на ноуте стоит, и я хочу сказать, что её сейчас к серверу на километр подпускать нельзя. То одно отвалится, то другое. Я думаю, мы после выхода 12.04 подождём хотя бы месяц, перед тем, как запускать в продакт (ubuntu любит выпустить, а потом срочно начать фиксить по мотивам недовольных клиентов, обнаруживших, что stable, это такой testing из debian'а).
                        0
                        У меня она с первых дней альфы еще стоит на моем компе.
                        В плане сервера ваще ничего не отваливалось. Какие-то рюшечки пользовательского интерфейса раньше чуток тупили но их нет в серверной оси.
                          0
                          А историю с «выходом» linux-3.2 задолго до появления релиза на kernel.org вы не заметили? Было ОЧЕНЬ смешно. На kernel.org/github'е — 3.2-rc5, а в бубунте во всю 3.2, типа релизнутый. От этой кривой зависимости они так и не избавились, пока нормальный 3.2 не прорелизили.

                          Несколько раз у них фигня в районе udev'а была. А udev — это уже очень серьёзно.
                +1
                Мы только что сделали рассылку по клиентам — в эти выходные апгрейд внешних каналов до облака до 10G. Так что про 10Мб/с — это вы с какими-то другими услугами перепутали.
                +1
                А объясните, пожалуйста, вот это. Я не нашёл в топике ни одной весомой причины ввести подобные ограничения.
                Наши ограничения: длина цепочки снапшотов не более 20 дисков, максимальное количество снапшотов в дереве (с учётом ветвлений) — не более 60 шт
                  0
                  lookup таблицы обрабатывать медленно.
                  0
                  Насколько я понял, снапшот снимается с работающей машины. Как обстоит тогда дело с дисковыми буферами гостевой ОС? Они сбрасываются на диск при создании снапшота?
                  И, опять же, в рамках моего понимания, снапшот самой виртуальной машины (xm save -c ) не производится? То есть данные, которые работавшая программа держала в памяти так и остаются в памяти?
                    0
                    Снапшот памяти нет. Нужно оно или нет — не знаю. Будут запросы, будем делать.

                    Снапшот не консистентен, да, увы. В Linux нет общего метода сделать консистентный снапшот.

                    ЗЫ У нас не используется xm :)
                      0
                      Да, я в курсе про xe. :)
                      Очень печально, что нельзя делать save с paused домена. Не понимаю, правда, почему, может расскажете? Ведь пауза для domU — это только прекращение выделения ему времени на CPU, так?

                      А то бы был красивый такой алгоритм:
                      • ставим на паузу, снимаем снэпшот диска
                      • снимаем снэпшот памяти
                      • снимаем с паузы

                      Так бы мы получили неконсистентый снэпшот диска, ну да и ладно — вся память-то тоже в резерве есть.
                        0
                        xe — это всего лишь утилита для работы с XenAPI. Внутри там часть делается xapi, а часть — libxl, то есть xl вполне себе работает.

                        Suspend машин в XCP есть, он требует отдельного SR для сохранения. Если нам его реализовывать (с аккаунтингом и прочими прелестями), то это примерно недели две работы. Будут запросы — сделаем.

                        Идея совмещать suspend копию машины с снапшотом диска… Спасибо, я подумаю.

                        ЗЫ На паузу ставить не обязательно, т.к. для памяти так же возможны мгновенные снапшоты (так работает миграция — сначала мигрируется память, потом изменения в памяти).
                          0
                          Но если не поставить домен на паузу, то не понятно, в какой момент надо снимать снапшот с диска.

                          Была ещё кривая идея. С использованием XFS в гостевых доменах. Есть там такая штука как xfs_freeze: сбрасывает все буферы и блокирует FS на запись. Однако, понятно, что в условиях public cloud это неприменимо, так как нужен доступ к гостевой ОС (да ещё и с root-правами). А так, думаю, понятно:
                            0
                            Сорри, задел не ту кнопку. :)
                            • xm console «xfs_freeze»
                            • снапшот диска
                            • снапшот памяти
                            • xm console «xfs_unfreeze»
                              0
                              Дело-то не в файловой системе. Проблема консистентных снапшотов много более общая — у майкрософта для этого есть механизм shadow copy, который посылает всем подписавшимся на информацию приложениям сообщение о том, что нужно создать консистентное состояние, и после этого делает freeze.

                              Просто sync'ом эту проблему не решить.

                              … А по моим наблюдениям, любая прилично журналируемая FS (ext3, ext4, xfs) после выполнения «внезапной» остановки (что есть эквивалент снапшота и отката на него) остаётся в консистентном (на уровне FS) состоянии.
                                0
                                Согласен. FS, вероятнее всего, будет в норме (можно даже сразу после снапшота прогонять fsck). Но получается всё равно не универсально — приложения должны работать так, чтобы отключение питания не приводило к повреждению данных и была возможность восстановления работоспособности. Не все приложения таковы, к сожалению.
                                А вот про shadow copy я не знал. Но, в любом случае, универсальностью тут и не пахнет — пока разработчик windows-приложения не имплементирует обработку этого сообщения, это работать не будет.
                                  0
                                  Ну, у майкрософта, надо признать, все крупные серверные приложения эти сервисы поддерживают (и у сторонних разработчиков тоже).

                                  А вообще, все уважающие себя СУБД так и работают, чтобы на диске была консистентная копия.
                    0
                    А кто занимается созданием и удалением (размазыванием) снапшотов? Ведь операция (особенно удаления) не атомарная и растянутая во времени, а запросы к виртуальному диску идти будут, причем и на запись — тоже. И необходимо обеспечить консистентность данных (в т.ч. и метаданных).
                      0
                      Запросы на запись идут только на «диск», снапшоты, а тем паче, base copy, намертво в RO. Запросы на чтение обрабатываются и base copy тоже, но эта операция очень простая: мы сначала переносим блок из удаляемого base copy, а потом меняем ссылку на него. Если на этот блок непрерывно идут запросы на чтение, то их часть пойдёт на старый блок, а часть на новый (но содержимое-то одинаково, так что никаких отличий не будет).

                      «Размазывает» base copy цитриксовский сервис по имени snapwatchd.

                      Сырцы всего этого дела публично доступны:

                      xenbits.xen.org/hg/XCP/1.1/xen-sm.hg/file/8f037812b8ed/snapwatchd/snapwatchd
                      +2
                      Если у кого-то (как и у меня) возникли сложности с пониманием работы снапшотов, вот мое переизложение:
                      1) при создании снапшота на самом деле «копия» диска не создается! Просто текущий диск замораживается и становится этим самым снапшотом.
                      2) на место текущего состояния диска мы подсовываем «пустой диск» и создаем новую таблицу сопоставления данных.
                      3) при записи (изменении данных) мы пишем в новый пустой диск, снапшот не трогаем.
                      4) не измененные данные берутся (читаются) напрямую из предыдущего состояния диска. Измененные данные читаются из нового диска.
                      5) в метаданных как раз и хранится таблица в которой описано какие блоки данных изменились и их надо читать из «текущего диска», а какие не менялись и их надо читать из снапшота («старого диска»).
                      6) при создании следующих снапшотов мы снова замораживаем текушее состояние диска и создаем очередную пустышку. Не измененные блоки данных могут ссылаться на предыдущие снапшоты вплоть до самого первого, где они реально хранятся.
                      7) вы платите за хранение только измененных данных в снапшотах. Например, был диск в 10Гб, вы сделали 2 снапшота, в первом изменений было на 100Мб, а во втором на 1Гб, вы будете платить за хранение 11,1Гб данных.
                      8) При удалении промежуточного снапшота его данные удаляются, попутно «вливаясь» в соседние снапшоты. Например, если удалить первый снапшот из предыдущего пункта, то вы уже будете платить только за хранение 11Гб данных, и откатиться можно будет только на самое первое состояние диска или на последний снапшот. Хммм, тут может возникнуть путаница с нумерацией снапшотов %)

                      Все это очень схоже с работой снапшотов в ZFS. Надеюсь, для кого-то хоть чуть-чуть прояснил топик.
                        0
                        А вот это очень понятно и доступно, спасибо.

                        Только что закончил перенос со старого облака на новое. Заметил, что денег кушается меньше на 10%-20%.

                        Либо я лучше настроил сервер, либо все эти инновации позволяют более эффективно расходовать ресурсы. А скорее всего — и то и другое вместе.
                          0
                          Скорее всего уменьшились расходы на RAM за счет включенного overcommit'а, в первом пуле он был выключен по техническим причинам.
                            0
                            А можно поподробноее пояснить «overcommit RAM»? Важный нюанс.
                              +1
                              memory overcommit — обычный режим работы linux. Для 2.6.34 пришлось его отключить, потому что там были неприятные проблемы с oom killer'ом, усиливаемые присутствием xen'а.

                              (На всякий случай) к оверселлу в openvz и подобным вещам не имеет никакого отношения, это фича исключительно и только самого ядра linux в отношении своих собственных процессов.
                                +1
                                Окей. Режим паники отключён.
                                0
                                goo.gl/43nN3 как я уже написал в старом пуле по умолчанию overcommit выключен (иначе ВМ вываливались в Kernel Panic), в новом пуле с новыми ядрами ВМ overcommit включен.
                          0
                          А вот у меня вопрос, наверняка глупый.

                          Можно ли как то сделать из снапшотов подобие резервного копирования? Например, автоматическое создание нового шота каждые сутки и затирание старых?

                          Догадываюсь, что все не просто, но может кто-то прояснит?..
                            0
                            Вполне можно, но пока не опубликовано клиентское API, вам придется делать это вручную через клиентскую панель, или мудрить с http запросами (будет очень не удобно, особенно, удалять старые снапшоты). Для бэкапов пока лучше использовать второй сервер или подождите немного, у нас кое-что уже почти готово ;)
                              0
                              Конечно подожду. Сейчас все бэкапится своим скриптом и сливается на домашний сервер, а оттуда на dropbox.

                              Но чем больше бэкапов — тем лучше! Тем более, со снапшотами откат будет гораздо быстрее и приятнее, чем распаковка из архива.
                              0
                              В планах есть, но чуть позже.
                              0
                              Побаловался со снапшотами — прикольно. Использовал для создания копии сервера перед обновлениес ОС, на всякий случай.

                              3 дня назад удалил их, а в билинге до сих пор уходят деньги.

                              Задал вопрос в ТП и получил потрясающий ответ:
                              По техническим причинам для полного исключения информации о снапшотах требуется на 20-30 минут
                              выключить виртуальную машину. В течении нескольких часов после включения машины объем снапшотов
                              в статистике должен снизиться до нуля.

                              Если после выполнения данной операции вид статистики по снапшотам не изменится,
                              пожалуйста, уведомите нас.

                              amarao, можете прокомментировать? У меня нет желания выключать 2 сервера на полчаса. Даже на 5 минут нет.

                              С другой стороны платить лишних 3 рубля в сутки за неиспользуемую услугу тоже как-то не хочется.

                              Да и что получается, для подстраховки использовать снапщоты нельзя, ибо придется потом машину выключать?
                                0
                                Есть такая проблема. coalesing (особенно последнего base copy) очень ленивый. В планах попытаться сделать его шустнее.
                                0
                                Снапшотов уже нет, а статья есть, непорядок.

                                Only users with full accounts can post comments. Log in, please.