Comments 7
Есть к вам пара вопросов.
Во-первых, не пугает ли вас, что делая снапшоты каждого диска в raid10, вы получаете 8 дисков, забитых мусором и бесполезных поодиночке? Понимаете ли вы, что при потере пары снапшотов из одной зеркальной пары восстановить массив не удастся, и придется откатываться к более ранним копиям?
Во-вторых, если вы используете нативный механизм снапшотов в ec2, это означает, что вы не сможете получить к снапшотам доступ в случае падения всего региона, пусть даже они и бакапятся внутри самого амазона в один или несколько регионов. Кроме того, будет довольно проблематично использовать полученные снапшоты где-то еще кроме амазона.
Рассматривали ли вы вариант с LVM поверх raid, самостоятельными снапшотами и бакапами прямо на S3, откуда их можно слить без особых проблем?
Во-первых, не пугает ли вас, что делая снапшоты каждого диска в raid10, вы получаете 8 дисков, забитых мусором и бесполезных поодиночке? Понимаете ли вы, что при потере пары снапшотов из одной зеркальной пары восстановить массив не удастся, и придется откатываться к более ранним копиям?
Во-вторых, если вы используете нативный механизм снапшотов в ec2, это означает, что вы не сможете получить к снапшотам доступ в случае падения всего региона, пусть даже они и бакапятся внутри самого амазона в один или несколько регионов. Кроме того, будет довольно проблематично использовать полученные снапшоты где-то еще кроме амазона.
Рассматривали ли вы вариант с LVM поверх raid, самостоятельными снапшотами и бакапами прямо на S3, откуда их можно слить без особых проблем?
1) А что делать, если на рейде бизнес-данные, их много, и нужно обеспечить их инкрементальное копирование с возможностью отката назад на короткое время. ФС фризится и в результате многочисленных тестов ФС с рейдом поднималась без проигрывания журнала.
2) На регион амазона SLA — 99,95%, однако даже 4 часового простоя региона за последние 2 года (и насколько знаю и больше) у них не было. ДЦ — лежали сутками, было, а вот регион максимум разок тупил полчаса. У них вся архитектура спланирована вокруг того, что регион «неубиваем». Ну мы планируем снепшоты их использовать для восстановления машин в другом ДЦ этого же региона.
На всяких случай мы храним снепшоты в нескольких копиях, т.к. у них был косяк при аварии летом прошлого года, когда некоторые снепшоты(!) забэкапленные побились.
3) Нет, LVM не рассматривали пока. Удобно, что это встроено в их API.
Спасибо за коммент.
2) На регион амазона SLA — 99,95%, однако даже 4 часового простоя региона за последние 2 года (и насколько знаю и больше) у них не было. ДЦ — лежали сутками, было, а вот регион максимум разок тупил полчаса. У них вся архитектура спланирована вокруг того, что регион «неубиваем». Ну мы планируем снепшоты их использовать для восстановления машин в другом ДЦ этого же региона.
На всяких случай мы храним снепшоты в нескольких копиях, т.к. у них был косяк при аварии летом прошлого года, когда некоторые снепшоты(!) забэкапленные побились.
3) Нет, LVM не рассматривали пока. Удобно, что это встроено в их API.
Спасибо за коммент.
Мы эксперементировали с instance-store («технология локальных блочных устройств»). Поскольку у него есть «фишка» умирать вместе с остановкой машины, то в случае падения (или отключения ssh), машина выходит из-под контроля (это не решается даже через сапорт амазона). Он полезен, когда надо открыть несколько клонов одного сервера (из одной AMI), на которых не хранится нчего, кроме кеша (ресурсы хранятся на s3/cloudfront, БД и почта на отдельных серверах).
Я слышал, что у коллег, держащих данные на instance-store при известной аварии EBS-контроллера амазона в штатах все продолжало крутиться :-)
В связи с неоднократно замеченными фактами внезапной перезагрузки машин амазона (раз и ребут, без сообщения о kernel-panic) — мы стараемся все данные хранить в EBS. В вирджинии не ребутятся и надежно работают машины типа c1.xlarge, другие, более слабые и равные по мощности типы периодически внезапно ребутились.
В связи с неоднократно замеченными фактами внезапной перезагрузки машин амазона (раз и ребут, без сообщения о kernel-panic) — мы стараемся все данные хранить в EBS. В вирджинии не ребутятся и надежно работают машины типа c1.xlarge, другие, более слабые и равные по мощности типы периодически внезапно ребутились.
У нас случай внезапного выхода сервера из строя был только один раз (не связано с молнией). Обычно, в преддверии хардварных проблем, Амазон присылает письмо, мол «так и так, скоро ваша инстанция сдохнет, чтобы она переоткрылась на другом железе сделайте рестарт или разверните новую AMI». Конечно, хранить на instance-store нодах нельзя ничего, кроме кешей, временных файлов и локальных логов. Это должны быть чистые application-сервера, которые можно без последствий создавать, когда требуются мощности и убивать когда уже не требуются.
Прекрасная статья, с удовольствием не раз ещё перечитаю. Большое спасибо автору!
Столько полезного материала, собранного в одном месте, не встречал и на английском.
Столько полезного материала, собранного в одном месте, не встречал и на английском.
Sign up to leave a comment.
Как бэкапить данные и MySQL в Amazon Web Services