В реальности, переназначение приоритетов часто бывает оправдано. Поставить ценой возврата из рейса срочный заказ для постоянного крупного заказчика раньше разового мелкого (если не нарушается договорной срок) — это как раз правильно и хорошо для бизнеса. Скорее всего, шеф этим и занимается, вряд ли у него просто блажь такая. Иначе бы бизнес давно вылетел в трубу.
Хотя шеф виноват по-любому, т.к. держит топ-менеджера, который даже склад комплектующих нормально организовать не способен.
В основном, проблемы случаются не с самим ксеном, а с конкретными версиями паравиртуальных ядер. Самые простые решения — менять ядра, или использовать HVM. Другие проблемы при частном или корпоративном использовании вряд-ли будут пересекаться с нашими, т.к. связаны с тем, что стандартное окружение ксен подготовлено для отдельных серверов, а у нас условия сильно от этого отличаются.
Я написал ровно о том, о чем заявлено — про метод создания консистентных бэкапов. Верификация бэкапа — один из аспектов, ничем не важнее остальных, таких как- среда и место хранения, метод ротации и удаления. У вас были бы основания сказать, что я все это упустил, если бы я заявил, что это учебник о бэкапах от и до.
С LVM скорее всего вам не повезло с конкретным багом и конкретными условиями. Не могу больше ничего сказать про ваш случай. На моих личных десктопах при загрузке автоматически создается снэпшот корня и система потом стартует на этом снэпшоте. Ни разу связанных с этим проблем за пару лет не было.
Скорее всего, это ваш личный негативный опыт. Мы работаем с ксеном 4 года и все решаемо. Баги, конечно, встречаются. Но их можно либо самостоятельно устранять, либо репортить и ждать, когда устранят разработчики.
Про побитый бэкап не понятно кому адресован вопрос. Верифицируйте бэкап тем способом, к которому привыкли.
В чем претензия к снэпшотам LVM? Они приводят к закономерной деградации производительности, в этом нет ничего неожиданного и в статье про это написано. Собственно, как статья и показывает, как минимизировать деградацию.
Тоже за синхронную репликацию СХД. Но нужно всегда учитывать, что и репликация СХД, и репликации ВМ могут оказаться неконсистентными при старте резерва и часть данных окажется неживой. С этой точки зрения репликация ВМ, если выполняется с quiesce и приложения их поддерживают, может оказаться более надежным решением.
как вы планируете в дальнейшем добраться до файлов, расположенных на снимке диска виртуальной машины?
Некоторые утилиты делают бэкап прямо с блочного устройства (dump) без монтирования. А в общем случае, для пофайлового копирования файловую систему можно монтировать в хост-системе, в отдельной виртуальной машине для копирования, экспортировать по iscsi на внешний сервер копирования бэкапов. У нас сейчас используется rsync в хост-системе, но есть планы изолировать копирование в отдельную виртмашину.
Теперь понятно, USN для каждого сервера собственный, я сначала предположил, что он общий для всех. С учетом изложенного вами поведения узлов при встрече с устаревшими USN, получается, что протоколом их взаимного резервирования состояние консистентности распространяется на всю группу.
Т.е. в системе из нескольких приложений, разделяющих между собой данные, возможность восстановления нормального состояния после разрывов связи или сбоев должна быть предусмотрена либо самими приложениемя, либо отдельной программой восстановления. Без их участия резервирование может быть выполнено только при синхронной остановке клонов всех узлов в изолированной сети.
В принипе, можно представить в качестве аналогии приложение, использующее базу данных. Если они находятся на одном сервере и останавливаются одновременно и у них есть стандартная последовательность остановки: приложение сможет закрыть свои внутренние данные, сбросить их в базу, а база сбросить на диск. При шатдауне клона все будет выполнено правильно. Если находятся на разных серверах, то для сохранения консистентности их нужно клонировать и останавливать синхронно, чтобы они выполнили полностью штатные процедуры остановки не теряя связи друг с другом.
На уровне резервного копирования файловой системы решить вопрос конфликта версий узлов с взаимной репликацией невозможно. Думаю, описываемую ситуацию можно свести к такой:
1) Есть серверы, синхронизирующие между собой данные, и имеющие в один и тот же момент одинаковую версию данных.
2) Периодически выполняется резервное копирование снэпшотов файловой системы серверов. Версии данных при этом зависят от времени создания снэпшота и в общем случае у резервных копий, сделанных в одно и то же время, версия данных может не совпадать.
3) Произошел отказ одного сервера. Его восстанавливают из бэкапа за прошлый день, с устаревшей версией данных. Остальные узлы, работавшие без аварии работают с актуальной версией данных.
Проблему конфликта версий в этом случае должно решать только приложение, в данном случае, конроллер домена, т.к. только оно организует репликацию данных. При сохранении снэпшота без шатдауна машины, его данные могут оказаться на диске в неконсистентном состоянии, от него ничего не зависит. Если же у клона был сделан корректный шатдаун, для контроллера домена работающего в клоне, это выглядит как потеря связи с другими контроллерами и потом шатдаун. Если приложение в этом случае не может сохранить свое состояние таким образом, что при последующем запуске у него возникает конфлик версий, то это является недостатоком в работе приложения. Так как любой отказ одного из узлов, например, перезагрузка сервера, должна приводить к такому же конфликту.
Мне трудно допустить, что у контроллера домена такая реакция на перерыв работе может быть нормой. В статье по ссылке описывалось условие, в котором возникла проблема — это был просто снэпшот, и восстановление из этого снэпшота привело к нарушению в работе. Судя по ней, контроллер доменов не поддерживает Quiesce, поэтому не сбрасывает корректно данные на диск перед снэпшотом. Могу предположить, что ни в вашем случае, ни в случае из KB MS, шатдаун клона на снэпшоте не выполнялся.
В принципе, выполнив синхронно снэпшоты всех узлов, занимающихся репликацией, затем запустив их клоны в отдельной виртуальной сети, не пересекающейся с рабочей, и отправив их всех в шатдаун, мы получим консистентное состояние всей системы этих узлов. Но не вижу особой ценности в таком результате, ведь репликация master-master или master-slave нужна для того, чтобы не терять изменения, и при потере какого-то из узлов данные должны востанавливаться не по бэкапу, а из оставшихся узлов. И если мы вместо ресинхронизации узлов просто восстановим из бэкапа все узлы на прошлы день, мы потеряем произошедшие изменения.
Хранить хоть снэпшоты, хоть дедуплицированные копии на том же хранилище, что и оригинал, бессмысленно по причине — если пострадает оригинал, то с высокой вероятностью пострадает и копия. Копии должны находиться максимально далеко и быть независимыми от оригинала.
В принципе, сравнение разных методов хранения копий в тему статьи не входил, т.к. я писал о том как достигнуть консистентности копии, а не как ее лучше хранить. Но в комментариях с удовольствием поговорю о хранение, хотя не могу похвастаться опытом работы с большим числом средств.
Мы почти везде используем rsync и для передачи копий, и для организации нескольких версий. Лет 10 назад кроме него ничего лучшего не было, и сейчас это для большинства наших задач отлично подходит, поэтому нет причин менять. Задачу по сокращению объема передаваемых и сохраняемых данных он решает хорошо. Таких же гибких, простых в эксплуатации и проверенных долгой практикой аналогов, которые были бы для нас лучше, скажем, в аспекте дедупликации, пока не нашел. Наверняка они есть, но предполагаемая дополнительная выгода от их использользования слишком мала, чтобы оправдать переход.
Из современных способов дедупликации мне больше всего нравится дедупликация на блочном уровне, так как у нас становится все больше задач, в которых мы оперируем образами дисков и доступа в файловую систему не имеем и не должны иметь. Но пока «закидываем шапками» — когда необходимо, держим отдельные копии на дешевых дисках.
По поводу конфликтности терминов дедупликация и инкрементность не соглашусь. Путаница — да, есть. Скажем, rsync, сделав хардлинки на одинаковые файлы добился того, что их данные не дублируются. Но rsync называется это incremental backup, а bacula — deduplication.
Дедупликацию удобно организовать непосредственно на хранилище сервера, но тогда теряется смысл в использовании его как резервной копии.
Если дедупликация выполняется средствами хранилища архива, а программа резервного копирования о дедупликации не заботится, то это означает, что в архив необходимо каждый раз передавать полную копию — не оправданный расход ресурсов.
Если дедупликацией занимается программа резервного копирования, в том числе чтобы не передавать лишние данные по сети, то самая простая реализация дедупликации — инкрементное копирование.
Рисков не особо много и они нормально купируются. Другое дело, что провайдеру нужно решить для себя, стоит ли тратить время и менять систему для такой редкой ситуации как эта. Наверное, если разница будет между 1 часом и 6 часами, то стоит.
Децентрализация, конечно, ускоряет значительно — когда у TrueVDS была похожая ситуация с аварийным обесточиванием, на выход в рабочий режим 90% машин потребовалось около 30 минут. Хотя в основом это из-за организации дисковой системы получилось, и это был скорее побочный эффект, так как цель обеспечивать в первую очередь быстрый старт после аварий не ставилась.
Но у вас ведь XCP? У меня было впечатление, что там настройки всех гостей хранятся в децентрализованном сторедже средствами самого XCP. Что должно автоматически решать вопрос и избыточного хранения настроек, и быстрого старта, Или это не так?
С памятью и дисками, безусловно, тоже могут быть. Так как для многих задач вычислительная сложность может снижаться увеличением сложности по памяти, к этому часто прибегают и используют memcached и прочие способы промежуточного кэширования. У таких процессора съедаться будет мало, все будет решаться большим потреблением памяти.
А часто бывает и наоборот: самый легкий способ жечь процессор — это не сайты с большой посещаемостью, а CMS, которые при генерации 1 страницы вместо того, чтобы сохранить в скрипте в переменной какое-нибудь значение, посылают сто sql-запросов в таблицы без индексов. Это зло вечное и неискоренимое.
Однако, в реальных условиях современного хостинга, скорость работы процессора так высока, что процессор — наименее востребованный и самый простаивающий ресурс и в 99% случаев конкуренции за ресурсы вообще не возникает.
Слова про 99% верны только на ранних этапах жизни хостинга, а в повседневной жизни это не так. Основную массу клиентов стартующего хостинга составляют новорожденные проекты с низкой посещаемостью — просто из-за того, что размещать новый проект проще, чем переносить существующий проект с другого хостинга. Когда хостинг проживет достаточно долго, чтобы на него стали переходить клиенты других хостеров, достаточно будет 3-5 форумов или магазинов с большими базами и парой тысяч уников в сутки, чтобы они съели весь процессор и начали жестко за него конкурировать.
Отличный, согласен на все сто. Он, кстати, будет участвовать в ноябрьском конкурс, так что есть высокие шансы. Особенно, после недавнего поста на Хабре :)
Да, уведомление по результатам рассмотрения высылаем. Регламента на обновление списка принятых заявок нет. Предыдущие разы рассмотрение заявок и внесение в список было в последние дни перед началом голосования. В этот раз тоже так.
Дизайнер сказала, что нужно поставить другую иллюстрацию. На картинке сентябрьского конкурса собирают черный виноград, поэтому в итоге должно быть не белое шампанское, а красное вино :)
Хотя шеф виноват по-любому, т.к. держит топ-менеджера, который даже склад комплектующих нормально организовать не способен.
Я написал ровно о том, о чем заявлено — про метод создания консистентных бэкапов. Верификация бэкапа — один из аспектов, ничем не важнее остальных, таких как- среда и место хранения, метод ротации и удаления. У вас были бы основания сказать, что я все это упустил, если бы я заявил, что это учебник о бэкапах от и до.
С LVM скорее всего вам не повезло с конкретным багом и конкретными условиями. Не могу больше ничего сказать про ваш случай. На моих личных десктопах при загрузке автоматически создается снэпшот корня и система потом стартует на этом снэпшоте. Ни разу связанных с этим проблем за пару лет не было.
Про побитый бэкап не понятно кому адресован вопрос. Верифицируйте бэкап тем способом, к которому привыкли.
В чем претензия к снэпшотам LVM? Они приводят к закономерной деградации производительности, в этом нет ничего неожиданного и в статье про это написано. Собственно, как статья и показывает, как минимизировать деградацию.
Некоторые утилиты делают бэкап прямо с блочного устройства (dump) без монтирования. А в общем случае, для пофайлового копирования файловую систему можно монтировать в хост-системе, в отдельной виртуальной машине для копирования, экспортировать по iscsi на внешний сервер копирования бэкапов. У нас сейчас используется rsync в хост-системе, но есть планы изолировать копирование в отдельную виртмашину.
Т.е. в системе из нескольких приложений, разделяющих между собой данные, возможность восстановления нормального состояния после разрывов связи или сбоев должна быть предусмотрена либо самими приложениемя, либо отдельной программой восстановления. Без их участия резервирование может быть выполнено только при синхронной остановке клонов всех узлов в изолированной сети.
В принипе, можно представить в качестве аналогии приложение, использующее базу данных. Если они находятся на одном сервере и останавливаются одновременно и у них есть стандартная последовательность остановки: приложение сможет закрыть свои внутренние данные, сбросить их в базу, а база сбросить на диск. При шатдауне клона все будет выполнено правильно. Если находятся на разных серверах, то для сохранения консистентности их нужно клонировать и останавливать синхронно, чтобы они выполнили полностью штатные процедуры остановки не теряя связи друг с другом.
1) Есть серверы, синхронизирующие между собой данные, и имеющие в один и тот же момент одинаковую версию данных.
2) Периодически выполняется резервное копирование снэпшотов файловой системы серверов. Версии данных при этом зависят от времени создания снэпшота и в общем случае у резервных копий, сделанных в одно и то же время, версия данных может не совпадать.
3) Произошел отказ одного сервера. Его восстанавливают из бэкапа за прошлый день, с устаревшей версией данных. Остальные узлы, работавшие без аварии работают с актуальной версией данных.
Проблему конфликта версий в этом случае должно решать только приложение, в данном случае, конроллер домена, т.к. только оно организует репликацию данных. При сохранении снэпшота без шатдауна машины, его данные могут оказаться на диске в неконсистентном состоянии, от него ничего не зависит. Если же у клона был сделан корректный шатдаун, для контроллера домена работающего в клоне, это выглядит как потеря связи с другими контроллерами и потом шатдаун. Если приложение в этом случае не может сохранить свое состояние таким образом, что при последующем запуске у него возникает конфлик версий, то это является недостатоком в работе приложения. Так как любой отказ одного из узлов, например, перезагрузка сервера, должна приводить к такому же конфликту.
Мне трудно допустить, что у контроллера домена такая реакция на перерыв работе может быть нормой. В статье по ссылке описывалось условие, в котором возникла проблема — это был просто снэпшот, и восстановление из этого снэпшота привело к нарушению в работе. Судя по ней, контроллер доменов не поддерживает Quiesce, поэтому не сбрасывает корректно данные на диск перед снэпшотом. Могу предположить, что ни в вашем случае, ни в случае из KB MS, шатдаун клона на снэпшоте не выполнялся.
В принципе, выполнив синхронно снэпшоты всех узлов, занимающихся репликацией, затем запустив их клоны в отдельной виртуальной сети, не пересекающейся с рабочей, и отправив их всех в шатдаун, мы получим консистентное состояние всей системы этих узлов. Но не вижу особой ценности в таком результате, ведь репликация master-master или master-slave нужна для того, чтобы не терять изменения, и при потере какого-то из узлов данные должны востанавливаться не по бэкапу, а из оставшихся узлов. И если мы вместо ресинхронизации узлов просто восстановим из бэкапа все узлы на прошлы день, мы потеряем произошедшие изменения.
В принципе, сравнение разных методов хранения копий в тему статьи не входил, т.к. я писал о том как достигнуть консистентности копии, а не как ее лучше хранить. Но в комментариях с удовольствием поговорю о хранение, хотя не могу похвастаться опытом работы с большим числом средств.
Мы почти везде используем rsync и для передачи копий, и для организации нескольких версий. Лет 10 назад кроме него ничего лучшего не было, и сейчас это для большинства наших задач отлично подходит, поэтому нет причин менять. Задачу по сокращению объема передаваемых и сохраняемых данных он решает хорошо. Таких же гибких, простых в эксплуатации и проверенных долгой практикой аналогов, которые были бы для нас лучше, скажем, в аспекте дедупликации, пока не нашел. Наверняка они есть, но предполагаемая дополнительная выгода от их использользования слишком мала, чтобы оправдать переход.
Из современных способов дедупликации мне больше всего нравится дедупликация на блочном уровне, так как у нас становится все больше задач, в которых мы оперируем образами дисков и доступа в файловую систему не имеем и не должны иметь. Но пока «закидываем шапками» — когда необходимо, держим отдельные копии на дешевых дисках.
По поводу конфликтности терминов дедупликация и инкрементность не соглашусь. Путаница — да, есть. Скажем, rsync, сделав хардлинки на одинаковые файлы добился того, что их данные не дублируются. Но rsync называется это incremental backup, а bacula — deduplication.
Если дедупликация выполняется средствами хранилища архива, а программа резервного копирования о дедупликации не заботится, то это означает, что в архив необходимо каждый раз передавать полную копию — не оправданный расход ресурсов.
Если дедупликацией занимается программа резервного копирования, в том числе чтобы не передавать лишние данные по сети, то самая простая реализация дедупликации — инкрементное копирование.
Децентрализация, конечно, ускоряет значительно — когда у TrueVDS была похожая ситуация с аварийным обесточиванием, на выход в рабочий режим 90% машин потребовалось около 30 минут. Хотя в основом это из-за организации дисковой системы получилось, и это был скорее побочный эффект, так как цель обеспечивать в первую очередь быстрый старт после аварий не ставилась.
Но у вас ведь XCP? У меня было впечатление, что там настройки всех гостей хранятся в децентрализованном сторедже средствами самого XCP. Что должно автоматически решать вопрос и избыточного хранения настроек, и быстрого старта, Или это не так?
А часто бывает и наоборот: самый легкий способ жечь процессор — это не сайты с большой посещаемостью, а CMS, которые при генерации 1 страницы вместо того, чтобы сохранить в скрипте в переменной какое-нибудь значение, посылают сто sql-запросов в таблицы без индексов. Это зло вечное и неискоренимое.
Слова про 99% верны только на ранних этапах жизни хостинга, а в повседневной жизни это не так. Основную массу клиентов стартующего хостинга составляют новорожденные проекты с низкой посещаемостью — просто из-за того, что размещать новый проект проще, чем переносить существующий проект с другого хостинга. Когда хостинг проживет достаточно долго, чтобы на него стали переходить клиенты других хостеров, достаточно будет 3-5 форумов или магазинов с большими базами и парой тысяч уников в сутки, чтобы они съели весь процессор и начали жестко за него конкурировать.
С другой стороны, сентябрьский грантополучатель nesami.org.ua — яркий пример нейтишности.
Красивый распил по-французски.