Требования разные бывают. Причин, по которым нельзя задерживать сервер БД для бэкапа совсем мало, и у многих таких причин нет. Ночью, как правило, сервер простаивает и задержка в работе БД никого не побеспокоит. Тем более, лок делается только на запись, а чтение выполняется как обычно.
А держать слейв ради бэкапов — это хоть и мелкая, но деградация производительности мастера, дополнительные затраты на еще один сервер и его обслуживание, плюс обеспечение не только того, чтобы бэкапы делались правильно, но и того, чтобы мастер-слейв корректно реплицировался и не разваливался. Для всех (ну хорошо, большинства :) такая морока не оправдана.
1. На мой взгяд, вы должны понимать, что так как и dm (LVM), и md являются блочными устройствами, буферы ядра работают выше уровнем и сбрасываются абсолютно одинаково. Напримет, тем же самым sync.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
1. Нет разной сложности сброса кэшей, кэши находятся выше блочного устройства хоть md, хоть dm для LVM, и сбрасываются одинаково. Далее тоже сложности нет — выполнить по одной команде — mdadm -f или lvcreate -s.
Вы пока так и не написали, чем конкретно md или что в нем нужно доводить.
2. В буферы ОС он пишет всегда (если не указана прямая запись на диск), как раз их потом fsync и должен сбросить. Но дальше водятся драконы. Скажем, может вызываться не fsync, а fdatasync, который не обновляет мета-данные. Скорее всего есть и другие причины или баги из-за которых в буферах что-то остается. Вы можете для эксперимента в своем скрипте после flush tables и перед lvcreate посмотреть, что будет в Dirty и Writeback в /proc/meminfo. Я всегда вижу какие-то данные.
Еще давайте представим, что у вас либо в памяти держится несколько сотен Мб несброшенных данных, либо какой-нибудь тяжелый селект выполняется и flush tables будет ждать несколько минут его завершение. А в это время в системе пришутся какие-то другие файлы — и до диска что-то доходит, а что-то не доходит.
Не захотелось еще перенести sync на правильное место?
В целом хорошая подборка, но по поводу копирования устройств есть неточности и ошибки:
1. Неправильно противопоставлять md raid1 и drbd как ненадежный способ, а lvm snapshot, как надежный. На самом деле, условия копирование дисков через mdraid, drbd или lvm snapshot одинаковы. Полную консистентность без кооперации с операционной системой и приложениями не гарантирует ни один из них. А при сбрасывании данных приложений и буферов ОС, все эти способы обеспечат одинаковую консистентность файловой системы.
Вы порекомендовали flush table только для lvm, хотя это точно так же полезно и для md/drbd.
Отключение slave-диска из RAID mirror идентично созданию в этот момент lvm снэпшота — содержание и mirror slave, и снэпшота будет одинаково.
2. В приведенном вами коде
$ sudo sync
$ sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
$ sudo mysql -e 'FLUSH LOGS;'
$ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s
$ sudo mysql -e 'UNLOCK TABLES;'
sync должна быть последней командой перед lvcreate. А в данном сценарии будут сначала сброшены на диск буферы ядра, потом mysqld сбросит из своих буферов данные в буферы ядра, но они еще не будут записаны на диск в тот момент, когда вызван lvcreate.
Это просто предупреждение с акцентом на то, что данные из этой клавиатуры могут утечь. Других пермишнов, кроме BIND_INPUT_METHOD, для работы виртуальной клавиатуры не дается.
Было бы, конечно, замечательно, если бы можно было как-то отделять такие опасные данные и давать клавиатуре возможность не предлагать себя для их ввода.
Но на практике это было бы не реально — и если о паролях инфомрация в IME передается и клавиатура можем сама понять, что не стоит такие данные отдавать «в облако», то понять, что вводится номер кредитки в форму на сайте клавиатура никак не сможет.
Могу предположить, что Swift здравомысляще и не будет пытаться шарить в словарях числа и, следовательно, номера кредиток будут. Но какие-нибудь пароли, вводимые открытым текстом, наверняка окажутся в облаке.
1) Легко пока не сделали. По ряду вещей, привлекательных с точки зрения удобства пользователей, пиара и повышения продаж, мы себя сознательно ограничиваем. Мы понимаем, что не сможем одновременно качественно реализовать и обеспечить это качество, занимаясь параллельно большим числом в чем-то даже протиповоложных направлений. И при этом безболезненно переварить слишком быстрый рост числа пользователей нам будет тоже невозможно.
В чем-то это даже постоянный источник внутреннего неудовольствия, когда видишь, что у конкурентов внедрено то и это. Думаешь, что могли сделать так же давным давно за неделю, но потом пару лет расхлебывали бы возникающие каждый месяц связанные с этим проблемы, простои серверов и потери данных пользователей. Латали бы на скорую руку с очередными производными проблемами. Кроме минуса в карму из-за пренебрежения интересами пользователей и минуса в бюджет из-за больших затрат на компенсацию за нарушение SLA, имели бы постоянный стресс и отнимали время от доведения до ума базовых, инфраструктурных вещей.
Слишком много вещей быстро хорошо не сделать. Либо для этого нужны чрезмерно большие финансовые затраты и какой-то другой способ организации внутренних процессов.
2) Удешевление планок памяти в несколько раз, к сожалению, не приводит к удешевлению услуги на столько же. Существующие процессоры и чипсеты не способны поддерживать в 4 раза больше памяти, новые с такими возможностями стоят дороже, и их замента также является существенными затратами.
Примерно год назад мы как раз ввели новые тарифы с увеличенным в два раза объемом памяти. По приведенным выше причинам увеличить память еще в 2-4 раза на стандартных тарифах в ближайшее время малореально, хотя это бывает при разовых акциях. И не могу согласиться полностью по поводу дороговизны — при оплате за год цены у нас меньше, чем у Linode, и даже достаточно близки к эталону дешевизны — Hetzner. А с школьниками или с виртуализацией с оверселлингом памяти конкурировать нереально — они всегда победят :)
Если под облаком понимается XCP, то нет, на XCP мы не переходили. А по поводу «облака», у нас с самого начала была похожая своя реализация из xen + xend и собственного софта для работы с пулами серверов и SAN.
Раньше в XCP было слишком много багов для того, чтобы брать его в production. Сейчас XCP как отчуждаемый продукт, конечно, намного универсальнее нашего, но именно в силу своей ориентированности на универсальность он нам не подходит и сейчас. У нас имеется достаточно управляемая инфраструктура, и эта управляемость также активно используется в организации работы виртуальных машин. Например, сегментирование SAN на зоны независимого отказа, назначение серверов кластера на конкретные профили задач и управление загрузкой этих серверов, пул серверов горячего резерва — все это доступно и используется в системе управления виртуальными машинами.
Таким образом, у нас нет многих вещей, которые есть в XCP, но нам не нужны, и при этом используется более низкоуровневая информация о доступном оборудовании, чем в XCP и используется много специфичных для нашей архитектуры вещей, что дает нам более простое и надежное управление облаком.
Возвращать в xen в этой ситуации даже особо нечего — в XCP без существенных изменений и без использования такого же API для работы с SAN, наши наработки не применить. Для xen hypervisor пока существенного ничего не делали. Была попытка когда-то live snapshot в xend включить, но похоже, у коммюнити основной интерес сейчас в XCP.
Работаю в СерверСнабе. Занимаюсь архитектурой аппаратного облака BitFabric и работающим поверх него с 2008 г частным облаком TrueVDS — публичным хостингом виртуальных машин Xen PV/Xen HVM. Главным образом, используется Xen 4 и Linux с собственными разработками.
Основная специализация: автоматизация управления оборудованием, отказоусточивость сети хранения данных и вычислительной сети, QoS дисков и вычислительных ресурсов, консультации по оптимальной настройке виртуальных машин для партнерских и клиентских проектов.
По отказоустойчивости можно сказать, достигнуты неплохие успехи — для той части пользователей, которые сталкивались с неработоспособностью в нашей зоне ответственности, за последние пару лет средний простой составил около 30 минут за 1 год.
Debian что-то тормозят с обновлением, а в апстрим патч уже вошел. В xen-devel еще несколько патчей по более мелким уязвимостям выложены. Мы патч посмотрели, ни с чем debian-specific он не кофликтует, а собираем мы все-равно с своими доделками из deb-src. Так что для нас нет большого смысла ждать, пока не появится родной дебиановский апдейт.
Уязвимость серьезная. Сейчас пока публичного эксплоита еще не видна, но, судя по патчу, это вопрос малого времени. Я, конечно, считаю, что большинство клиентов — люди благоразумные и не начнут его применять из спортивного интереса. Но нет никаких гарантий от того, что у кого-то из них не взломана машина, через которую было бы удобно поломать и соседей.
Хотя там чуть изменений в коде гипервизора, в api ничего не меняется, версии не меняются. Так что формально, можно было бы обойтись и без перезагрузки — обновлять поочередно хосты и мигрировать виртмашины на обновленные.
В больших масштабах, правда, чревато разными непредвиденными глюками, так что мы лишний раз рисковать не будем и всех мягко зашатдауним.
Уязвимость, в первую очередь, Интела — в разделении доступа между кольцами привилегий. А далее по цепочке уже оказались уязвимыми системы, которые используют этот механизм для разграничения досупа — Xen PV, MS Windows, FreeBSD.
Ну ничего, бывает. Патчи уже есть, сегодня накатим.
Вы перечислили несколько аспектов, которые присущи в равной же степени большинству современным VDS. Можно даже сказать, что openvz или jail в freebsd предоставляют еще более гибкий механизм распределения оперативной памяти и процессора, чем xen/kvm/hyper-v/vmware, хотя этот гибкий механизм уже гибок излишне и чаще приносит больше вреда. Тем не менее, одна виртуальная машина, будь это openvz или xen с баллоном, облаком не является. Как минимум из-за того, что имеется достаточно низко ограниченный предел масштабирования.
На внутренней стороне облако работает и работало в том или ином виде еще до того, как термин пошел в массы, практических у всех хостеров. По простой причине — так легче организовать управление большим числом однотипных серверов. Использовать облако во внутренней инфраструктуре насколько же банально, насколько использовать VLAN или менеджеры пакетов. Вытаскивает ли хостер этот невидимый клиенту пазл или нет, зависит от его маркетологов.
Кто-то вытаскивает и говорит, да, у нас облачный сервис, потому что внутри паззла есть облако. Не имею ничего против маркетологов, это их работа. Но такие утверждения не перестают быть добротным образцом маркетингового буллшита.
Вот у Amazon с этим все чисто: заявляют, что продают облака, и клиенты эти облака со всеми функциями управления облаком получают.
Назвать облаком метод нарезки ресурсов и оплаты — это ваша собственная интерпретация, и это, действительно, маркетинговая махинация для продвижения с помощью модного термина. С общеупотребимыми значениями и стандартом определения NIST ваше определение малосвязано.
Кстати, у родоначальников жанра, LoudCloud и Amazon, облако является не нарезкой ресурсов сервера, а абстракцией некоего числа серверов, унифицированное управление большим количеством различных компьютерных ресурсов.
Обратите внимание, разница и в масштабах, и в целях — резать один сервер на кусочки и называть это облаком, или объединять много серверов в один ресурс и называть это облаком.
Покупая румынские, черногорские, болгарские гигабиты нужно учитывать, что чаще всего эти гигабиты заканчиваются на ближайшей местной точке обмена, а в остальную Европу просачиваются мегабиты.
А от внедрения системы планирования, кстати, может появится побочный полезный эффект. Во время внедрения при моделировании процессов выявятся неоптимальные участки. Потом, при работе, этапы, где план нарушается часще всего, очевидно становятся кандидатами на реорганизацию.
А держать слейв ради бэкапов — это хоть и мелкая, но деградация производительности мастера, дополнительные затраты на еще один сервер и его обслуживание, плюс обеспечение не только того, чтобы бэкапы делались правильно, но и того, чтобы мастер-слейв корректно реплицировался и не разваливался. Для всех (ну хорошо, большинства :) такая морока не оправдана.
2. У вас ошибка в схеме бэкапа. Если вы не осознаете эту ошибку и после того, что я написал, остается только надеяться, что проекты, которые вы администрируете, не связаны с медициной, космосом или чем-то другим важным.
Качество вашей работы пусть оценивают ваши коллеги и руководство, это ваше личное дело. Но здесь в публичном техническом блоге в виде готовой рекомендации вы даете заведомо ошибочное и вредное решение, и не пытаетесь его проверить и исправить. Это в высшей степени непорядочно.
Вы пока так и не написали, чем конкретно md или что в нем нужно доводить.
2. В буферы ОС он пишет всегда (если не указана прямая запись на диск), как раз их потом fsync и должен сбросить. Но дальше водятся драконы. Скажем, может вызываться не fsync, а fdatasync, который не обновляет мета-данные. Скорее всего есть и другие причины или баги из-за которых в буферах что-то остается. Вы можете для эксперимента в своем скрипте после flush tables и перед lvcreate посмотреть, что будет в Dirty и Writeback в /proc/meminfo. Я всегда вижу какие-то данные.
Еще давайте представим, что у вас либо в памяти держится несколько сотен Мб несброшенных данных, либо какой-нибудь тяжелый селект выполняется и flush tables будет ждать несколько минут его завершение. А в это время в системе пришутся какие-то другие файлы — и до диска что-то доходит, а что-то не доходит.
Не захотелось еще перенести sync на правильное место?
1. Неправильно противопоставлять md raid1 и drbd как ненадежный способ, а lvm snapshot, как надежный. На самом деле, условия копирование дисков через mdraid, drbd или lvm snapshot одинаковы. Полную консистентность без кооперации с операционной системой и приложениями не гарантирует ни один из них. А при сбрасывании данных приложений и буферов ОС, все эти способы обеспечат одинаковую консистентность файловой системы.
Вы порекомендовали flush table только для lvm, хотя это точно так же полезно и для md/drbd.
Отключение slave-диска из RAID mirror идентично созданию в этот момент lvm снэпшота — содержание и mirror slave, и снэпшота будет одинаково.
2. В приведенном вами коде
sync должна быть последней командой перед lvcreate. А в данном сценарии будут сначала сброшены на диск буферы ядра, потом mysqld сбросит из своих буферов данные в буферы ядра, но они еще не будут записаны на диск в тот момент, когда вызван lvcreate.
Было бы, конечно, замечательно, если бы можно было как-то отделять такие опасные данные и давать клавиатуре возможность не предлагать себя для их ввода.
Но на практике это было бы не реально — и если о паролях инфомрация в IME передается и клавиатура можем сама понять, что не стоит такие данные отдавать «в облако», то понять, что вводится номер кредитки в форму на сайте клавиатура никак не сможет.
Могу предположить, что Swift здравомысляще и не будет пытаться шарить в словарях числа и, следовательно, номера кредиток будут. Но какие-нибудь пароли, вводимые открытым текстом, наверняка окажутся в облаке.
В чем-то это даже постоянный источник внутреннего неудовольствия, когда видишь, что у конкурентов внедрено то и это. Думаешь, что могли сделать так же давным давно за неделю, но потом пару лет расхлебывали бы возникающие каждый месяц связанные с этим проблемы, простои серверов и потери данных пользователей. Латали бы на скорую руку с очередными производными проблемами. Кроме минуса в карму из-за пренебрежения интересами пользователей и минуса в бюджет из-за больших затрат на компенсацию за нарушение SLA, имели бы постоянный стресс и отнимали время от доведения до ума базовых, инфраструктурных вещей.
Слишком много вещей быстро хорошо не сделать. Либо для этого нужны чрезмерно большие финансовые затраты и какой-то другой способ организации внутренних процессов.
2) Удешевление планок памяти в несколько раз, к сожалению, не приводит к удешевлению услуги на столько же. Существующие процессоры и чипсеты не способны поддерживать в 4 раза больше памяти, новые с такими возможностями стоят дороже, и их замента также является существенными затратами.
Примерно год назад мы как раз ввели новые тарифы с увеличенным в два раза объемом памяти. По приведенным выше причинам увеличить память еще в 2-4 раза на стандартных тарифах в ближайшее время малореально, хотя это бывает при разовых акциях. И не могу согласиться полностью по поводу дороговизны — при оплате за год цены у нас меньше, чем у Linode, и даже достаточно близки к эталону дешевизны — Hetzner. А с школьниками или с виртуализацией с оверселлингом памяти конкурировать нереально — они всегда победят :)
Раньше в XCP было слишком много багов для того, чтобы брать его в production. Сейчас XCP как отчуждаемый продукт, конечно, намного универсальнее нашего, но именно в силу своей ориентированности на универсальность он нам не подходит и сейчас. У нас имеется достаточно управляемая инфраструктура, и эта управляемость также активно используется в организации работы виртуальных машин. Например, сегментирование SAN на зоны независимого отказа, назначение серверов кластера на конкретные профили задач и управление загрузкой этих серверов, пул серверов горячего резерва — все это доступно и используется в системе управления виртуальными машинами.
Таким образом, у нас нет многих вещей, которые есть в XCP, но нам не нужны, и при этом используется более низкоуровневая информация о доступном оборудовании, чем в XCP и используется много специфичных для нашей архитектуры вещей, что дает нам более простое и надежное управление облаком.
Возвращать в xen в этой ситуации даже особо нечего — в XCP без существенных изменений и без использования такого же API для работы с SAN, наши наработки не применить. Для xen hypervisor пока существенного ничего не делали. Была попытка когда-то live snapshot в xend включить, но похоже, у коммюнити основной интерес сейчас в XCP.
Основная специализация: автоматизация управления оборудованием, отказоусточивость сети хранения данных и вычислительной сети, QoS дисков и вычислительных ресурсов, консультации по оптимальной настройке виртуальных машин для партнерских и клиентских проектов.
По отказоустойчивости можно сказать, достигнуты неплохие успехи — для той части пользователей, которые сталкивались с неработоспособностью в нашей зоне ответственности, за последние пару лет средний простой составил около 30 минут за 1 год.
Уязвимость серьезная. Сейчас пока публичного эксплоита еще не видна, но, судя по патчу, это вопрос малого времени. Я, конечно, считаю, что большинство клиентов — люди благоразумные и не начнут его применять из спортивного интереса. Но нет никаких гарантий от того, что у кого-то из них не взломана машина, через которую было бы удобно поломать и соседей.
В больших масштабах, правда, чревато разными непредвиденными глюками, так что мы лишний раз рисковать не будем и всех мягко зашатдауним.
Ну ничего, бывает. Патчи уже есть, сегодня накатим.
На внутренней стороне облако работает и работало в том или ином виде еще до того, как термин пошел в массы, практических у всех хостеров. По простой причине — так легче организовать управление большим числом однотипных серверов. Использовать облако во внутренней инфраструктуре насколько же банально, насколько использовать VLAN или менеджеры пакетов. Вытаскивает ли хостер этот невидимый клиенту пазл или нет, зависит от его маркетологов.
Кто-то вытаскивает и говорит, да, у нас облачный сервис, потому что внутри паззла есть облако. Не имею ничего против маркетологов, это их работа. Но такие утверждения не перестают быть добротным образцом маркетингового буллшита.
Вот у Amazon с этим все чисто: заявляют, что продают облака, и клиенты эти облака со всеми функциями управления облаком получают.
Кстати, у родоначальников жанра, LoudCloud и Amazon, облако является не нарезкой ресурсов сервера, а абстракцией некоего числа серверов, унифицированное управление большим количеством различных компьютерных ресурсов.
Обратите внимание, разница и в масштабах, и в целях — резать один сервер на кусочки и называть это облаком, или объединять много серверов в один ресурс и называть это облаком.