Комментарии 88
Молодцы, лучше долго, но качественно, чем быстро, и не пойми как.
Написанно аргументированно, понятно, без лишней «воды» и фанатизма
Селектел твердо решил стать лучшим хостером России.
Вызывает удивление.
Если хостер начал думать нестандартно — стоит, однако, обратить внимание на него.
Вы только людей, которые в этом всем копались не отпускайте. Лелейте )
Если хостер начал думать нестандартно — стоит, однако, обратить внимание на него.
Вы только людей, которые в этом всем копались не отпускайте. Лелейте )
В Linux нет разделения на системное и прикладное ПО, все конфиги хранятся в общем каталоге /etc/ или разбросаны по файловой системе — отсюда все проблемы с клонированием.
Для FreeBSD достаточно быстро можно сдампить (клонировать) основную систему. Правкой нескольких конфигов в /etc/ можно кастомизировать её. Затем установить ПО из заранее собранных бинарных пакетов для обеспечения дополнительной функциональности (для устанавливаемого ПО есть собственный каталог конфигурации — /usr/local/etc/).
Для FreeBSD достаточно быстро можно сдампить (клонировать) основную систему. Правкой нескольких конфигов в /etc/ можно кастомизировать её. Затем установить ПО из заранее собранных бинарных пакетов для обеспечения дополнительной функциональности (для устанавливаемого ПО есть собственный каталог конфигурации — /usr/local/etc/).
Это, кстати, не решит остальных проблем: отсутствии актуальных логов установки и даты модификации файлов.
Логи установки и даты модификации системных файлов для вас и ваших клиентов несут какую-то полезную информацию? Какую?
Простейший пример — выяснение, что не так. Например, у меня вызвал подозрение какой-то пакет. Вопрос, он был поставлен сейчас или раньше? Если речь идёт не про компрометацию системы, то журнал вполне покажет, что происходило с машиной. А главное, эти цифры (время) будет иметь смысл — у файлов время соответствует времени в логах.
При условии, конечно, что с ней обращались как с линуксом, а не как с бздёй (то есть ставили пакеты, а не make install, а то и cp/mv).
При условии, конечно, что с ней обращались как с линуксом, а не как с бздёй (то есть ставили пакеты, а не make install, а то и cp/mv).
find / -exec touch -c {} \;
Это будет САМАЯ дурацкая вещь, какую только можно сделать. Похерятся все даты conf-файлов, у всех бинарников эти даты станут одинаковыми.
Hint: внутри dpkg обычный tar, который сохраняет даты.
Hint: внутри dpkg обычный tar, который сохраняет даты.
А что, у вас при чистой установке даты не одинаковые (плюс-минус несколько минут), что ли?
Нет, даты соответствуют дате компиляции файла. А вот у конфигурационных файлов, изменённых в инсталлятором (или созданных им) даты соответствуют моменту установки. Или выполнения update и т.д.
Так что когда я говорил про «сохранение дат» я говорил именно про сохранение дат у conf-файлов и файлов, которые были изменены.
Так что когда я говорил про «сохранение дат» я говорил именно про сохранение дат у conf-файлов и файлов, которые были изменены.
[Пожимая плечами] Ни разу за свою практику не помню, чтобы была необходимость в просмотре дат файлов установки с такой точностью.
С какой «такой»? Разница может быть в пару месяцев, а то и пол-года.
Мы друг друга, похоже, не понимаем.
Чистая установка системы — для всех файлов датой создания ставим дату установки.
Установка апдейтов, апдейтов и прочая — даты изменённых файлов должны, соответственно, быть датами этих установок.
Какой смысл в ваших извращениях с датами файлов, которые сохраняются при распаковке из кем-то когда-то запакованных dpkg, я не понимаю абсолютно. Запутать самих себя, пытаясь понять откуда у вас в системе взялись файлы старее, чем дата установки?
Чистая установка системы — для всех файлов датой создания ставим дату установки.
Установка апдейтов, апдейтов и прочая — даты изменённых файлов должны, соответственно, быть датами этих установок.
Какой смысл в ваших извращениях с датами файлов, которые сохраняются при распаковке из кем-то когда-то запакованных dpkg, я не понимаю абсолютно. Запутать самих себя, пытаясь понять откуда у вас в системе взялись файлы старее, чем дата установки?
Если выставить для файлов дату установки, то невозможно будет по дате понять, как соотносятся «не тронутый конфиг» (то есть конфиг, который пришёл из deb'а и не был редактирован), конфиг, который был выставлен во время установки, и конфиг, который трогали после установки.
И я ещё раз повторю, в данном случае аргумент не «это нужно кровь из носа», а «так задумано создателями дистрибутива, и я не считаю себя умнее их».
И я ещё раз повторю, в данном случае аргумент не «это нужно кровь из носа», а «так задумано создателями дистрибутива, и я не считаю себя умнее их».
Другими словами вы хотите сказать, что простым изменением даты создания/модификации файла какого-нибудь конфига можно поставить систему раком?! Только линуксятникам может придти в голову настолько идиотская идея, как датировать файлы системы и апдейтов не датой установки, а датой сборки пакета. Большего идиотизма просто не слышал.
Не надо мне приписывать слова, которые я не говорил, а потом называть их идиотизом.
Я написал, что эта информация может быть нужна пользователю для выяснения источника проблем (который может быть как в пакете, так и в действиях инсталлятора, или даже пользователя).
И идея в том, что дата файла равна дате его создания очень разумная. По-крайней мере мне представляется куда более логичным, что при переустановке пакета у меня дата файлов внезапно не упыгает далеко вперёд. Если у файла новая дата, то это новый файл или его кто-то зачем-то touch.
Я написал, что эта информация может быть нужна пользователю для выяснения источника проблем (который может быть как в пакете, так и в действиях инсталлятора, или даже пользователя).
И идея в том, что дата файла равна дате его создания очень разумная. По-крайней мере мне представляется куда более логичным, что при переустановке пакета у меня дата файлов внезапно не упыгает далеко вперёд. Если у файла новая дата, то это новый файл или его кто-то зачем-то touch.
amarao, вы меня упорно отказываетесь понимать. Идею «если у файла новая дата, то это новый файл или его кто-то зачем-то touch» не отрицает никто. Вы логику-то включите, подумайте как следует. Давайте по шагам:
1. За «нулевую», «стартовую» дату очевидным образом необходимо принимать дату установки системы. find / -exec touch -c {} \; при установке.
2. При установке апдейтов даты изменяемых файлов должны изменяться.
2.1. При изменении даты она не должна становится меньшей, чем нулевая «дата»
2.2. Новой датой изменённых датов должна стать дата установки данного апдейта или пакета, а не та, что вздумалась разработчику.
При таких условиях у вас всегда будет система, в которой по дате файла можно будет определить когда он менялся (а не просто факт того, что он менялся, раз даты не совпадают).
И вообще говоря, чем больше я читаю, тем больше мне кажется, что в Debian так и обстоят дела, и никаких дат созданий файлов tar не вытаскивает, а если и вытаскивает, то уж никак потом не полагается на них при определении версий файлов.
1. За «нулевую», «стартовую» дату очевидным образом необходимо принимать дату установки системы. find / -exec touch -c {} \; при установке.
2. При установке апдейтов даты изменяемых файлов должны изменяться.
2.1. При изменении даты она не должна становится меньшей, чем нулевая «дата»
2.2. Новой датой изменённых датов должна стать дата установки данного апдейта или пакета, а не та, что вздумалась разработчику.
При таких условиях у вас всегда будет система, в которой по дате файла можно будет определить когда он менялся (а не просто факт того, что он менялся, раз даты не совпадают).
И вообще говоря, чем больше я читаю, тем больше мне кажется, что в Debian так и обстоят дела, и никаких дат созданий файлов tar не вытаскивает, а если и вытаскивает, то уж никак потом не полагается на них при определении версий файлов.
Обычно прикладное ПО запускается от юзера, и конфиги хранятся в хоумдире.
ну еще например мне будет не очень притятно осозновать, что в «голой» системе до меня кто-то уже копался и что-то дастраивал, доустанавливал.
получая «девственную» систему, сразу после инсталлятора, можно быть уверенным, что она идентична тому, что я получаю поставив ее с диска в любом другом месте.
получая «девственную» систему, сразу после инсталлятора, можно быть уверенным, что она идентична тому, что я получаю поставив ее с диска в любом другом месте.
Для FreeBSD, кстати, тоже можно создать файл с конфигом установщика.
Ну вот и настало время глянуть на тест вашего облака.
Виртуальная машина с центосом x64, память от 128 мб до 512 мб.
На установку центоса потратилось менее 10 рублей
Память, сейчас: 375.54 Mb
Диск 12 гб.
Данные за месяц.
Машинное время 4,87 руб. / 4.870 час.
Потребление памяти 117,49 руб. / 236.491 Гб * час.
Диск: запросов на чтение 3,11 руб. / 0.933 млн. шт.
Диск: запросов на запись 23,54 руб. / 7.062 млн. шт.
Диск: прочитанный объём 1,76 руб. / 17.600 Гб
Диск: записанный объём 6,78 руб. / 67.800 Гб
Диск: хранение 43,96 руб. / 8.797 Тб * час
Сеть: получено 0,35 руб. / 1.750 Гб
Сеть: отправлено 0,51 руб. / 0.510 Гб
Итого 202,37 руб в месяц за не нагруженную машину.
Машина ни разу не перезапускалась за 5 недель, то есть эпикфайлов не было.
Память слишком дорога все таки, с учетом того как упали цены на 4гб модули памяти то есть потенция к удешевлению её в облаке.
Проц наверно самый дешевый ресурс, но так ли будет при нагрузке?
Хранение дисков тоже не айс по цене, в многократное резервирование я не особо верю, так что копию всегда храню в другом месте, а вернее в двух.
С диском на чтение запись пока не разобрался так как нагрузки нет, насколько цена обоснована/завышена/занижена.
Для сети дороговато выходит если проект нагруженный, хотелось бы иметь вариант, чтобы не платить за сеть, а иметь 10 мегабитный порт анлимный.
Виртуальная машина с центосом x64, память от 128 мб до 512 мб.
На установку центоса потратилось менее 10 рублей
Память, сейчас: 375.54 Mb
Диск 12 гб.
Данные за месяц.
Машинное время 4,87 руб. / 4.870 час.
Потребление памяти 117,49 руб. / 236.491 Гб * час.
Диск: запросов на чтение 3,11 руб. / 0.933 млн. шт.
Диск: запросов на запись 23,54 руб. / 7.062 млн. шт.
Диск: прочитанный объём 1,76 руб. / 17.600 Гб
Диск: записанный объём 6,78 руб. / 67.800 Гб
Диск: хранение 43,96 руб. / 8.797 Тб * час
Сеть: получено 0,35 руб. / 1.750 Гб
Сеть: отправлено 0,51 руб. / 0.510 Гб
Итого 202,37 руб в месяц за не нагруженную машину.
Машина ни разу не перезапускалась за 5 недель, то есть эпикфайлов не было.
Память слишком дорога все таки, с учетом того как упали цены на 4гб модули памяти то есть потенция к удешевлению её в облаке.
Проц наверно самый дешевый ресурс, но так ли будет при нагрузке?
Хранение дисков тоже не айс по цене, в многократное резервирование я не особо верю, так что копию всегда храню в другом месте, а вернее в двух.
С диском на чтение запись пока не разобрался так как нагрузки нет, насколько цена обоснована/завышена/занижена.
Для сети дороговато выходит если проект нагруженный, хотелось бы иметь вариант, чтобы не платить за сеть, а иметь 10 мегабитный порт анлимный.
Насчёт анлимного инета — работаем. Хранение дисков… Я пытаюсь лоббировать дешёвые хранилища с RAID1 для клиентов, которые знают, на что идут, но всё утыкается в существование клиентов, которые не понимают, на что идут.
Так а удешевления памяти ждать не стоит? Диск дороговат, но ИМХО память еще более дороговата. Ну конкретизирую вопрос: обсуждается ли вообще удешевление памяти. Если нет — то и ждать не стоит… В прочем я все равно останусь с вами. Раньше уже писал, что экономия после переезда составила более 50%.
Статистика за вчера (сервер под относительно небольшой нагрузкой):
Машинное время 1,04 руб. / 1.040 час.
Потребление памяти 6,10 руб. / 12.278 Гб * час.
Диск: запросов на чтение 0,10 руб. / 0.030 млн. шт.
Диск: запросов на запись 0,69 руб. / 0.207 млн. шт.
Диск: прочитанный объём 0,03 руб. / 0.300 Гб
Диск: записанный объём 0,16 руб. / 1.600 Гб
Диск: хранение 0,96 руб. / 0.192 Тб * час
Сеть: получено 0,02 руб. / 0.100 Гб
Сеть: отправлено 0,27 руб. / 0.270 Гб
Итого 9,37 руб.
Статистика за вчера (сервер под относительно небольшой нагрузкой):
Машинное время 1,04 руб. / 1.040 час.
Потребление памяти 6,10 руб. / 12.278 Гб * час.
Диск: запросов на чтение 0,10 руб. / 0.030 млн. шт.
Диск: запросов на запись 0,69 руб. / 0.207 млн. шт.
Диск: прочитанный объём 0,03 руб. / 0.300 Гб
Диск: записанный объём 0,16 руб. / 1.600 Гб
Диск: хранение 0,96 руб. / 0.192 Тб * час
Сеть: получено 0,02 руб. / 0.100 Гб
Сеть: отправлено 0,27 руб. / 0.270 Гб
Итого 9,37 руб.
а что на ней висит, и сколько посещений, если не секрет
Да, по распределению расходов я в ближайшие дни опубликую статистику (на что сколько уходит).
По поводу процессора вставлю свои пять копеек. Если сравнивать например Selectel и Clodo, то у первого проц гораздо дешевле. На Clodo у меня за сутки набегало 1-1.5 рублей, в то время как на Селектеле за месяц выходило всего около 6 рублей. Если сравнивать по всем параметрам, то виртуальная машина на Clodo поедала примерно столько же денег что и у Селектела — примерно 5.5 рублей в стуки, правда у Селектела был заказан диска на 2Гб, а у Clodo на 5Гб. Это результаты по одним и тем же сайтам с общей посещаемостью около 250-300 хостов и чуть больше 1000 просмотров в сутки.
Еще кстати замечу, что странички сайтов на Селектеле генерируются немного быстрее. Например на одном из сайтов на MODX Revo Селектел генерирует страницу в среднем за 0.5-0.55сек, а Clodo ту же страницу за 0.7-0.9сек. Wordpress у Селектела тоже работает чуть быстрее, особенно это заметно в админке. Исключение составил лишь сайт на Joomla — Clodo отдавал страницу примерно на 100-200мс быстрее.
Еще кстати замечу, что странички сайтов на Селектеле генерируются немного быстрее. Например на одном из сайтов на MODX Revo Селектел генерирует страницу в среднем за 0.5-0.55сек, а Clodo ту же страницу за 0.7-0.9сек. Wordpress у Селектела тоже работает чуть быстрее, особенно это заметно в админке. Исключение составил лишь сайт на Joomla — Clodo отдавал страницу примерно на 100-200мс быстрее.
Клонирование это халтура по большому счету, бонусы от нее очень сомнительны.
В существующих версиях blktap (дисковый драйвер в XCP) — да. В параллелсовой реализации контейнеров определённый профит есть — т.к. есть возможность обновлять образы всех систем одновременно.
Чисто теоретически, клонирование методом снапшотов может слегка уменьшить число ИОПСов на хранилище за счёт общих кусков кода. Но на практике это едва заметно (т.к. в реальных условиях на системные файлы приходится очень мало иопсов по сравнению с данными пользователей). Скорее, это может быть важно для всякого рода virtual desktop, у которых загрузка ПО занимает большую долю операций.
Второй момент, где это интересно — это амазоновские «инстансы», то есть образы, которые может клонировать клиент. Но это полностью сохраняет все вопросы про получившиеся образы…
Чисто теоретически, клонирование методом снапшотов может слегка уменьшить число ИОПСов на хранилище за счёт общих кусков кода. Но на практике это едва заметно (т.к. в реальных условиях на системные файлы приходится очень мало иопсов по сравнению с данными пользователей). Скорее, это может быть важно для всякого рода virtual desktop, у которых загрузка ПО занимает большую долю операций.
Второй момент, где это интересно — это амазоновские «инстансы», то есть образы, которые может клонировать клиент. Но это полностью сохраняет все вопросы про получившиеся образы…
Почему бы не использовать для debian/ubuntu механизм debootstrap?
Для шапки и центоси, кажется, есть похожий инструмент.
Для шапки и центоси, кажется, есть похожий инструмент.
Все, кто пользовались debootstap знают, что после этого его ещё надо долго конфигурировать, раз, два, это мало отличается от процесса обычной установки по сути.
На самом деле есть ещё третья причина, но я её скромно умолчал — в XCP относительно сложно из dom0 получить доступ к VDI клиента. Можно, но только обходными путями. Так что с точки зрения простоты скормить домену свой initrd проще, чем покопаться в его VDI.
На самом деле есть ещё третья причина, но я её скромно умолчал — в XCP относительно сложно из dom0 получить доступ к VDI клиента. Можно, но только обходными путями. Так что с точки зрения простоты скормить домену свой initrd проще, чем покопаться в его VDI.
Кстати, пока не планируете в Москве запускать? Это так, на всякий случай спрашиваю… Особо не надеясь)
Не раньше второй половины 2011.
Кстати, а чем так Москва интересна? Там разница в пинге — порядка 15мс. А саппорт априори будет лучше в Питере, потому что в очень аварийном случае я пешком дойду до сервера за минуты, а в Москве нужно будет химичить с инженерами поддержки и IP-KVM.
Кстати, а чем так Москва интересна? Там разница в пинге — порядка 15мс. А саппорт априори будет лучше в Питере, потому что в очень аварийном случае я пешком дойду до сервера за минуты, а в Москве нужно будет химичить с инженерами поддержки и IP-KVM.
Что происходит с виртуалками, когда физический сервер выходит из строя?
Ребут. То есть с точки зрения VM это выглядит как внезапный shutdown без предупреждения и старт на другом хосте.
Физические сервера не хранят на себе ничего ценного, кроме логов для отладки и копии распределённой БД xapi.
Физические сервера не хранят на себе ничего ценного, кроме логов для отладки и копии распределённой БД xapi.
Xen позволяет сделать высокодоступные виртуалки?
Когда при выходе из строя одного физического сервера, активизировалась бы копия vm вместе с ram на другом физическом сервере, где она постоянно синхронизиловась бы с первой vm.
Когда при выходе из строя одного физического сервера, активизировалась бы копия vm вместе с ram на другом физическом сервере, где она постоянно синхронизиловась бы с первой vm.
Xen такое позволяет, но… хм… не совсем стабильно (Remus/Xen4). Так что пока на нашем уровне стабильности, единственный HA — это restart on failure.
У Зена вообще очень много вкусных вещей, но не все они готовы для продакта. Я чуть ли не два месяца угробил, гоняясь за ними. Пока строго остаёмся на Xen 3.4, у которого я за всё время не видел ни одного зависания или падения гипервизора (в сравнении с Xen4, у которого таки-видел).
У Зена вообще очень много вкусных вещей, но не все они готовы для продакта. Я чуть ли не два месяца угробил, гоняясь за ними. Пока строго остаёмся на Xen 3.4, у которого я за всё время не видел ни одного зависания или падения гипервизора (в сравнении с Xen4, у которого таки-видел).
А вы планируете предоставлять облачный сторедж аля Amazon S3? Было бы актуальненько.
А что с виндой? Ее клонировать тоже небезопасно?
Чур-чур-чур. Мы, конечно, запустили виндовые VDS, но меня миновала чаша их настраивать и разбираться что там к чему.
У нас чистый PV, и поскольку майкрософт запретила публиковать паравиртуализированную Windows (такая была в природе, но с запретом на дистрибуцию), то в облаке Windows не предвидится.
Пускать в Xen HVM машины — рисовать безопасностью всего облака. Так что нет.
У нас чистый PV, и поскольку майкрософт запретила публиковать паравиртуализированную Windows (такая была в природе, но с запретом на дистрибуцию), то в облаке Windows не предвидится.
Пускать в Xen HVM машины — рисовать безопасностью всего облака. Так что нет.
Простите, я не сильно в курсе вашей архитектуры. Вопрос был теоретический — являются ли проблемы клонирования, описанные в статье, общими для Windows гостей.
Извините. Я просто очень не люблю MS и винды.
По сути — «безопасно» в том смысле, что оно как-то работать будет. По сути — MS явно заявляет, что копипастить можно винды только после sysprep. После — под собственную ответственность. В свою бытность виндовым админом я наблюдал жуткие глюки при клонировании рабочих станций, в районе имени my documents у разных пользователей. Плюс, кажется, у меня слетал при клонировании WSUS.
По сути — «безопасно» в том смысле, что оно как-то работать будет. По сути — MS явно заявляет, что копипастить можно винды только после sysprep. После — под собственную ответственность. В свою бытность виндовым админом я наблюдал жуткие глюки при клонировании рабочих станций, в районе имени my documents у разных пользователей. Плюс, кажется, у меня слетал при клонировании WSUS.
Проблема при клонировании в Винде та же. SID машины в винде будет неуникальный, потому при попытке добавить две такие машины в домен получите ошибку(ну и возможны другие проблемы с правами). Лечится запуском sysprep перед началом исспользования клона. Процес не быстрый около 15-20 мин обычно и одна перезагрузка.
Ошибку не получите, ибо «Дублирование SID не является проблемой в среде на основе доменов, так как учетные записи домена получают SID, основанные на SID домена. „
См. technet.microsoft.com/ru-ru/sysinternals/bb897418
См. technet.microsoft.com/ru-ru/sysinternals/bb897418
Насчёт SID не знаю, но я лично наблюдал my documents с названием otheruser's documents вместо user documents в эксплорере.
И WSUS ломается-таки. Это я по опыту 2003/XP говорю, дальше я с МС не дружил.
И WSUS ломается-таки. Это я по опыту 2003/XP говорю, дальше я с МС не дружил.
Прежде чим ссылаться на статью прочитайте примечание к ней справа
и пройдите по ссылке.
blogs.technet.com/b/mark_russinovich/archive/2009/11/15/3293962.aspx
Во вторых проблему вы 100% получите, если например склонируете два Windows 2008 R2 Server один сделаете контролером домена, а второй попробуете завести в домен и гарантировано получите на второй машине те же сиды что и у контролера, а потом будете долго медитировать над EventLog что за виртуалки вам админы наразвёртывали что ничего не работает.
и пройдите по ссылке.
blogs.technet.com/b/mark_russinovich/archive/2009/11/15/3293962.aspx
Во вторых проблему вы 100% получите, если например склонируете два Windows 2008 R2 Server один сделаете контролером домена, а второй попробуете завести в домен и гарантировано получите на второй машине те же сиды что и у контролера, а потом будете долго медитировать над EventLog что за виртуалки вам админы наразвёртывали что ничего не работает.
Перезагрузок там… ммм, дай бог памяти… 4 штуки. Минимальное время установки — 10 минут.
Планируется ли возможность клонирования уже созданной машины и будут ли доступны манипуляции с ней через апи?
Как продвигаются дела с возможностью более тонкой настройки памяти (пороги изменения выделеной памяти)?
а также с доступом к xvc0.
а также с доступом к xvc0.
Вот что я могу точно пообещать в ближайшем апдейте — это самую охрененную консоль по сравнению со всем, что я видел у конкурентов.
С MOD — будет третья версия с адаптивными алгоритмами (уже продуманы на бумаге, вопрос в реализации и отладке).
Т.к. алгоритм поменяет ключевые коэффициенты, то мне не кажется разумным сейчас делать их в панельке, долго объяснять что к чему, а потом всё рубить и делать по новой.
Если не нравятся настройки на текущей машине — можете написать тикет, я отвечу, выставлю руками нужные.
С MOD — будет третья версия с адаптивными алгоритмами (уже продуманы на бумаге, вопрос в реализации и отладке).
Т.к. алгоритм поменяет ключевые коэффициенты, то мне не кажется разумным сейчас делать их в панельке, долго объяснять что к чему, а потом всё рубить и делать по новой.
Если не нравятся настройки на текущей машине — можете написать тикет, я отвечу, выставлю руками нужные.
А когда намечается этот ближайший апдейт?
Что ж вы такие каверзные вопросы-то задаёте, а?
Работаем. С учётом, что часть работы связана не с «надо сделать», а «надо разобраться, придумать и сделать», сроки назвать не могу.
Сначала думали небольшие обновления делать, потом, в какой-то момент, оказалось, что у нас половина кода scapi переписана, плюс интерфейс переделан, плюс куча идеологических изменений разной степени заметности, плюс на горизонте XCP1.0 (я думаю, что обновление будет-таки до принятия 1.0 в продакт).
Работаем. Когда сделаем, я это анонсирую с подробным чейнжлогом.
Работаем. С учётом, что часть работы связана не с «надо сделать», а «надо разобраться, придумать и сделать», сроки назвать не могу.
Сначала думали небольшие обновления делать, потом, в какой-то момент, оказалось, что у нас половина кода scapi переписана, плюс интерфейс переделан, плюс куча идеологических изменений разной степени заметности, плюс на горизонте XCP1.0 (я думаю, что обновление будет-таки до принятия 1.0 в продакт).
Работаем. Когда сделаем, я это анонсирую с подробным чейнжлогом.
«xapi — scapi», круто придумали ;)
Кстати, scapi уже устарело и скоро будет выпилено. На его место пришёл SCT (selectel cloud toolstack).
Отлично, долгих лет.
Кстати, вы что-нибудь знаете и/или можете сказать про облачный toolstack от КРОКа? Я случайно общался с их продажниками — говорят, что «взяли и написали» с нуля за 2 года, якобы полная совместимость с ec2tools, и как минимум реализованные аналоги ec2 (по-моему, тоже Xen) и s3. Но на сайте конкретики и тарифов нет :)
Кстати, вы что-нибудь знаете и/или можете сказать про облачный toolstack от КРОКа? Я случайно общался с их продажниками — говорят, что «взяли и написали» с нуля за 2 года, якобы полная совместимость с ec2tools, и как минимум реализованные аналоги ec2 (по-моему, тоже Xen) и s3. Но на сайте конкретики и тарифов нет :)
Когда-нибудь я все-таки дождусь возможности изменения размеров разделов и на вас перееду :)
Вы уже сейчас можете добавлять и удалять дополнительные разделы (не системный). И если развернуть на них LVM, то можно самостоятельно изменять объем раздела на LVM =) Если же вы про плавное изменение разделов да еще и на ходу, то это наверно еще не скоро появится.
это комментарий для kemko
Если смотреть с точки зрения моей лени, а так же с учетом того, что с LVM я раньше почти не сталкивался — все это несколько сложнее, чем просто выставить в панели ползунок на нужное мне сейчас количество гигабайт, а потом смотреть как у меня автоматически меняется размер раздела.
Вообще мы можем произвольно изменять размеры блочных устройств, однако сами ОС зачастую к этому не готовы. Как вы думаете как поведет себя ваша ОС если ваш HDD внезапно прибавит пару гигабайт? а если уменьшится? =)
Выполнить resize2fs, а потом подкрутить ползунок в панели — это все-таки проще, чем играться в LVM. Ну а в случае с Clodo они как-то автоматизировали процесс: выставляешь ползунок как надо, жмешь Ok, далее сервер автоматически перезагружается и на начальной стадии загрузки включается некий клодовский сприпт, который делает fsck, resize2fs и прочее необходимое.
Насчёт авторесайза клиентских файловых систем я думал но дело в том, что это всё шаманство и может запросто напороться на нестандартную конфигурацию.
Необязательно авторесайз. Можно и ручной ресайз. Была бы возможность изменить размер образа и подключить его к одной из ВМ.
Полностью автоматизированный процесс, и действительно, не обязателен совершенно. Достаточно, когда нужны какие-то действия в клиентской системе выводить их список и просить сделать их самостоятельно. Ну и сделать какой-нибудь текст а-ля «если вы используете что-то нестандартное, мы за результат не отвечаем, все это работает только в таком-то случае, если у вас по-другому — прикидывайте сами, как модифицировать команды».
Конечно можно создать новый раздел нужной длины, переместить нужное туда и подмонтировать на место старого, но все-таки больше дополнительных действий. Хотя может быть я просто зажрался.
Конечно можно создать новый раздел нужной длины, переместить нужное туда и подмонтировать на место старого, но все-таки больше дополнительных действий. Хотя может быть я просто зажрался.
Вот ещё новость: Открыт код системы управления развертыванием приложений Galaxy.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Облако: Клонирование дисков VS установка