Re: Amazon EC2

[Ilya L]

On 9/28/11 2:03 PM, Sol Windborn wrote:
> Sol Windborn wrote:
>
>> Вот если, скажем, взять micro instance ($0.02/hour), то это, вроде
>> ~$15/month.
>>
>> Как оно для хостения своего Web сервера, почты и прочего?
>>
>
> Ну что, неужели никто? Если посмотреть на job sites все хотят cloud
> experience.
>
> Кстати, Илья, там внутри у Амазона таки VMWare?
>

Нет. Xen hypervisor и свой proprietary management layer.


Там такое дело, значит....

AMI это image, из которого делается EC2 instance/VM. AMI сохранен в S3,
который cloud storage с HTTP GET/PUT/POST semantics.

Изнутри EC2 instance содержимое AMI менять нельзя. В том смысле что все
writes, которые идут в /etc, /var и проч. будут wiped out clean при
рестарте инстанса. Uptime инстанса не гарантируется.

Чтобы внутри инстанса сохранять изменения, есть два подхода:

1. Поменять программу на то, чтобы она вместо файла на файловой системе
писала в Amazon S3 через GET/PUT/POST. Либо использовать готовую
Амазонскую DB, которая это уже делает. Но нужно чтобы софт это
поддерживал или надо менять софт.

2. В дополнении к EC2 купить еще Elastic Block Store (EBS) Volume и
attach его к твоему инстансу. С точки зрения VM EBS Volume выглядит как
block device, который можно отформатировать под ext3.
В отличии от /etc, модификации EBS volume are persistent across EC2
instance restarts. Т.е. их можно использовать для сохранения данных.
Гарантии на сохранность данных в EBS volume не очень высоки (сравнимо с
physical disk). Но ты можешь делать периодические снапшоты EBS volume и
сохранять их в S3, где гарантии уже намного выше.
Performance-wise EBS volume хуже, чем non-persistent root volume.
Насколько хуже, я уже не помню и оно меняется.

За EBS Volume и S3 snapshots надо платить extra. IMHOН, как за capacity
так и за IO. Не много, но может быть сравнимо с ценой собственно инстанса.

А так - классно работает, куча народа пользует. Выдадут тебе client-side
ssh cert и вперед, ssh root@ip.

--
ilya

[Ilya L]

On 9/28/11 2:56 PM, Sol Windborn wrote:
> Спасибо, понятно.
>
> Смотрим, кстати, в сторону старика Кубушина: к вопросу о том, что софт
> не нужно ставить из packages и нужно разносить ОС и прикладной софт. Вот
> то, что там ниже написано, как раз энфорсит это дело.
>
> Нужно идти читать дальше.
>
> P.S. Так они используют стандартный Linux kernel, или таки Xen kernel?
>

xenified paravirtualized kernel.

В принципе, ты можешь сделать свой image (c xenified kernel) и upload
его в S3 как AMI. Но легче выбрать уже существующий image с нужным тебе
дистром из имеющихся в наличии в public repository.

Еще совет - создай другой account для EC2, отличный от того, который ты
используешь для шоппинга на амазоне.

ilya

[Ilya L]

On 9/28/11 2:58 PM, Ilya L wrote:
> On 9/28/11 2:56 PM, Sol Windborn wrote:
>> Спасибо, понятно.
>>
>> Смотрим, кстати, в сторону старика Кубушина: к вопросу о том, что софт
>> не нужно ставить из packages и нужно разносить ОС и прикладной софт. Вот
>> то, что там ниже написано, как раз энфорсит это дело.

Not quite, кстати. Я немного невнятно объяснил.

Ты можешь создать instance из стадартного ubuntu AMI, скажем.
Залогиниться вовнутрь и поставить в /usr, /etc и прочий root file system
все нужные тебе приложения. После этого скриптами, имеющимися внутри
этого инстанса, создать из модифицированной VM другой AMI и зааплоадить
его в S3.

Из нового AMI ты можешь создать другой инстанс, в котором в root file
system будут стоять твои приложения.

Разносить надо данные и binaries, а не ОС и прикладной софт. Данные
должны быть сохраны на другой FS, которая хранится на EBS volume.

илья

[Ivan Krivyakov]

"Sol Windborn" <ro...@earth.solarsystem.milkyway.universe> wrote in message
news:j601u9

>
>> Вот если, скажем, взять micro instance ($0.02/hour), то это, вроде
>> ~$15/month.
>>
>> Как оно для хостения своего Web сервера, почты и прочего?
>>
>
> Ну что, неужели никто? Если посмотреть на job sites все хотят cloud
> experience.
>

Я игрался. Но чисто поиграться. Советы давать не могу. Веб сайт у меня в
чулане :)

Иван

[Ivan Krivyakov]

"Ilya L" <lvi...@yahoo.com> wrote:
>
> Еще совет - создай другой account для EC2, отличный от того, который ты
> используешь для шоппинга на амазоне.
>

Почему? Пользователей клауда активно хачат?

Иван

[Ilya L]

Нет. EC2/S3 биллинг как свет от далекой звезды. Ты уже закончил с ним
играться, а всякие мелкие charges все еще идут.

Я с Амазона много чего покупаю и в общем аккаунте cloud charges пропускаю.

--
ilya

[VS]

On 9/28/11 2:03 PM, Sol Windborn wrote:
> Sol Windborn wrote:
>

>> Вот если, скажем, взять micro instance ($0.02/hour), то это, вроде
>> ~$15/month.
>>
>> Как оно для хостения своего Web сервера, почты и прочего?
>>
>
> Ну что, неужели никто? Если посмотреть на job sites все хотят cloud
> experience.

Типа "умение пользоваться интернетом"? :)

Давеча интервьюировали такого, ну расскажи что же у тебя там с клаудом
за отношения, а позиция у него текущая в резюме типа "member of cloud
team" или что-то в этом духе. Манагеры коих у нас на пятерых аж трое -
губы раскатали, вот жеж повезло так повезло. Оказалось - он логи собирал
и парсил, даже ему самому непонятно то-ли с esx'ов, то-ли с guests. Что
это вообще за аббревиатуры такие и чем они отличаются - ни в зуб ногой,
а на вопрос "а что такое клауд" отвечает "это когда я на машине что-то
читал, ушел, потом вернулся, а оно меня ждет". Но cloud experience
несомненно имеет.

[Danil Smirnov]

28.09.2011 23:42, Sol Windborn пишет:

> Вот если, скажем, взять micro instance ($0.02/hour), то это, вроде
> ~$15/month.
>
> Как оно для хостения своего Web сервера, почты и прочего?
>

Пробовал, у меня вышло $30. За такие деньжищи у меня целый отдельный
сервер в Hetzner есть.

[Alex Mizrahi]

> Вот если, скажем, взять micro instance ($0.02/hour), то это, вроде
> ~$15/month.

> Как оно для хостения своего Web сервера, почты и прочего?

Хуёво, не предназначено оно для этого. Это просто вычислительная нода,
локальный диск нужно рассматривать как кэш. Нода может перегрузиться в
любой момент, и тогда содержимое утеряно. (*)

Продукты амазона предполагается использовать в комплекте -- лоад
балансер, несколько EC2 нод для аппсеревера и отдельно хранилище -- S3,
блок сторож или готовые базы данных.

Если масштабируемость не нужна куда проще и дешевле взять VPS для
хостинга предназначенный.

*: Была, кстати, хохма -- чувачок захостил сайта обмена биткоинов на
EC2. И там wallet хранился, в котором все деньги... И работало оно
несколько месяцев, как ни странно, пока не захотелось ему памяти
увеличить. Увеличил, оно перегрузилось, данные пропали, естественно.
Штук десять баксов в пересчёте, а может и под сотню пропало
безвозвратно, саппорт амазона естественно послал нахуй насчёт
восстановления.
Вот спрашивается, если человек вообще не понимает что такое "клауд",
зачем им пользоваться?

[Ilya L]

http://aws.amazon.com/ebs/

--
ilya

[Alex Mizrahi]

>> Продукты амазона предполагается использовать в комплекте -- лоад
>> балансер, несколько EC2 нод для аппсеревера и отдельно хранилище -- S3,
>> блок сторож или готовые базы данных.

> http://aws.amazon.com/ebs/

http://blog.reddit.com/2011/03/why-reddit-was-down-for-6-of-last-24.html

И подробнее:

http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l6ykx

I don't work for reddit anymore (as of about a week ago, although I
didn't get as much fanfare as raldi did), but I can tell you that
they're giving Amazon too much credit here. Amazon's EBSs are a barrel
of laughs in terms of performance and reliability and are a constant
(and the single largest) source of failure across reddit. reddit's been
in talks with Amazon all the way up to CIOs about ways to fix them for
nearly a year and they've constantly been making promises that they
haven't been keeping, passing us to new people (that "will finally be
able to fix it"), and variously otherwise been desperately trying to
keep reddit while not actually earning it.

reddit's been trying very hard to avoid bad-mouthing Amazon in public
(in fact I was fascinated to see that jedberg was willing to see them
mentioned at all here) but the fact is that their EBS product alone
accounts for probably 80% of reddit's downtime. Note that with 80% of
reddit's downtime removed, they'd be on par with services of a similar
size.

The root of the problem is that EBSs are too slow to use single EBSs for
a database machine servicing as many requests as reddit's are. So you
have to RAID them together. But that increases your surface-area for
risk in failure. Couple that with ridiculously high variability in their
actual performance (one will all-of-a-sudden slow down 10x to 100x,
often across a large quantity of disks). This tarpits any requests sent
to that DB (for the query timeout plus the detection period until we can
route around it), causing many many micro-downtimes throughout the day,
accounting for the vast majority of the "you broke reddit" pages. More
recently we also discovered that these disks will also frequently report
that a disk transaction has been committed to hardware but are flat-out
lying. So after the wave of slowness passes we find that the data on a
machine may be physically corrupted. That's bad. If it's a slave, you
have to re-replicate the whole slave (which hurts the master as well as
the other slaves as they pick up his slack). If it's a master, you have
a crapload of manual data cleanup to do.

http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l7vy1

I work at Amazon EC2 and I can tell you what's going on (thanks to this
handy throwaway account). What's happening is the EBS team gets
inundated with support tickets due to their half-assed product. Here's
the hilarious part: whenever we've asked them why they don't fix the
main issue, they keep telling us that they're too busy with tickets.

[Alex Mizrahi]

> http://aws.amazon.com/ebs/

Я так понимаю, судя по отзывам, что то что у них сейчас есть нифига не
highly available и даже не durable, т.к. записываемые данные хранятся в
одной копии, и если машина ответственная за неё падает то всё.
Может даже физически данные где-то и лежат, но не будут же все ждать
пока они не достанут диск и поставят в другую машину?

И вообще я плохо представляю как вообще можно реализовать это в h.a.
варианте на обычном железе -- дублирование вручную выльется в нефиговый
оверхед.

А если это делать на специализированном железе с аппаратным
дублированием то оно стоить будет совсем другие деньги. Не?

$0.10 per allocated GB per month Amazon EBS also charges $0.10 per 1
million I/O requests you make to your volume

Я сомневаюсь что этого хватит на 15k диски, не говоря уже об SSD и
прочих "излишествах".

[Nikita Belenki]

"Alex Mizrahi" <alex.m...@gmail.com> wrote in message
news:j61gsd$6vm$1...@speranza.aioe.org...
>> http://aws.amazon.com/ebs/

> И вообще я плохо представляю как вообще можно реализовать это в h.a.
> варианте на обычном железе -- дублирование вручную выльется в нефиговый
> оверхед.
> А если это делать на специализированном железе с аппаратным дублированием
> то оно стоить будет совсем другие деньги. Не?
> $0.10 per allocated GB per month Amazon EBS also charges $0.10 per 1
> million I/O requests you make to your volume
> Я сомневаюсь что этого хватит на 15k диски, не говоря уже об SSD и прочих
> "излишествах".

А зачем для дублирования нужны 15k диски и SSD?

Kit.

[Const]

VS <v...@z1.org> wrote:
> team" или что-то в этом духе. Манагеры коих у нас на пятерых аж трое -
> губы раскатали, вот жеж повезло так повезло. Оказалось - он логи собирал
> и парсил, даже ему самому непонятно то-ли с esx'ов, то-ли с guests. Что
> это вообще за аббревиатуры такие и чем они отличаются - ни в зуб ногой,
> а на вопрос "а что такое клауд" отвечает "это когда я на машине что-то
> читал, ушел, потом вернулся, а оно меня ждет". Но cloud experience
> несомненно имеет.

Nice.

---
Const

[Const]

А это ты сам в ЮАР или просто любишь приключения ?

---
Const

[Alex Mizrahi]

> А зачем для дублирования нужны 15k диски и SSD?

Не нужны, конечно; это я в том плане что едва ли они купили готовое SAN
решение в котором HA должно работать.

А решение "на коленке", из подручных материалов едва ли будет работать
хорошо (что и наблюдается), либо разработка обойдётся безумного много денег.

Как правило такие вещи решаются на более высоком уровне -- fs или db --
а на уровне block device делать слишком смело IMHO.

[VS]

On 9/29/11 2:49 AM, Alex Mizrahi wrote:
>>> Продукты амазона предполагается использовать в комплекте -- лоад
>>> балансер, несколько EC2 нод для аппсеревера и отдельно хранилище -- S3,
>>> блок сторож или готовые базы данных.
>
>> http://aws.amazon.com/ebs/
>
> http://blog.reddit.com/2011/03/why-reddit-was-down-for-6-of-last-24.html
>
> И подробнее:
>
> http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l6ykx
>
>

[....]

>
> http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l7vy1
>
>
> I work at Amazon EC2 and I can tell you what's going on (thanks to this
> handy throwaway account). What's happening is the EBS team gets
> inundated with support tickets due to their half-assed product. Here's
> the hilarious part: whenever we've asked them why they don't fix the
> main issue, they keep telling us that they're too busy with tickets.

На какие только приманки народ не идет чтобы денег не платить за
собственное железо и собственный саппорт.

Ну заплатив по 10 центов в м-ц за гигабайт они за эти деньги получают
ровно то что должны были бы получить - 0.001% внимания хорошо если еще
американского специалиста, очень может статься что это китайцы или
индусы по ночам работают.

В Амазоне сидят либо гении по части людской психологии либо сами оуевают
"ну надо же"

[VS]

Естественно это не физические диски, а скорее всего nas'ы и очень дешевые.
Покупать что-то приличное типа нетаппа и отключать при этом все функции
redundancy и сохранения данных = выброс денег на ветер.

[Ilya L]

On 9/29/11 3:22 AM, Alex Mizrahi wrote:

>> http://aws.amazon.com/ebs/
>
> Я так понимаю, судя по отзывам, что то что у них сейчас есть нифига не
> highly available и даже не durable, т.к. записываемые данные хранятся в
> одной копии, и если машина ответственная за неё падает то всё.
> Может даже физически данные где-то и лежат, но не будут же все ждать
> пока они не достанут диск и поставят в другую машину?

Никто никуда ничего не будет доставать и ставить. VM instance может
слечь в любой момент и availability EBS volume не гарантируется.

Говорил же, надо делать кроном регулярные снапшоты и класть их в S3. S3
- highly available. Provisioning нового EBS volume из снапшона
происходит достаточно быстно.

Для домашнего сервера ежедневный снапшот и 24-часовое RPO вполне
acceptable. Все равно в чулане лучше не получится.

Про performance я тоже предупреждал. Но, опять же, для домашнего
сервера оно OK.

> И вообще я плохо представляю как вообще можно реализовать это в h.a.
> варианте на обычном железе -- дублирование вручную выльется в нефиговый
> оверхед.

Если хотя бы 15 minutes RPO acceptable, то можно дешево и сердито. У
нас есть vSphere Replication. У Амазона нет. Но мне их модель со
снапшотами в S3 больше нравится.

Если нужно sync replication и 0 RPO, то нефиговый оверхеад и/или
толстый линк и не сильно далеко, up to 100 miles. И дорого. В соседний
ящик реплицировать особого смысла нет. RAID 6 у Амазона есть, я думаю.

> А если это делать на специализированном железе с аппаратным
> дублированием то оно стоить будет совсем другие деньги. Не?

Это как интересоваться из чего сделана колбаса. Меньше знаешь лучше
спишь. :-)

--
ilya

[Alex Mizrahi]

> Никто никуда ничего не будет доставать и ставить. VM instance может
> слечь в любой момент и availability EBS volume не гарантируется.

> Говорил же, надо делать кроном регулярные снапшоты и класть их в S3.

Я очень редко встречаю такие применений, чтобы данные за последние
часы/дни были вообще не нужны. Уж лучше подождать пока поднимется. Или
они могут просрать вообще навсегда?

> Для домашнего сервера ежедневный снапшот и 24-часовое RPO вполне
> acceptable. Все равно в чулане лучше не получится.
> Про performance я тоже предупреждал. Но, опять же, для домашнего сервера
> оно OK.

Для домашнего сервера куда проще купить нормальный VPS и не парить мозг
с EBS. Если посчитать сумму EC2 + S3 + EBS + IP/DNS так выйдет что и
выделенный сервер с raid1 и бэкапами арендовать можно.

>> И вообще я плохо представляю как вообще можно реализовать это в h.a.
>> варианте на обычном железе -- дублирование вручную выльется в нефиговый
>> оверхед.
>
> Если хотя бы 15 minutes RPO acceptable, то можно дешево и сердито.

С полноценным durability, то есть если база данных транзакцию
закоммитила, то она восстановится?
Или за 15 минут восстановится вчерашний снапшот?

> Но мне их модель со снапшотами в S3 больше нравится.

Для каких применений?

[Alex Mizrahi]

> На какие только приманки народ не идет чтобы денег не платить за
> собственное железо и собственный саппорт.

В случае с реддитом всё просто -- владеющая корпорация не давала им
расширить штат, там всего 4 человека работали на то время, и то не все
технического профиля. А с другой стороны им нужно справляться с трафиком
в миллиарды посещений в месяц, причём вычислительно страницы довольно
сложные.

80 Server Instances
388 Virtual Cores
815 GB of RAM
24.3 TB of storage

28 c1.xlarge
23 m1.large
29 m1.xlarge

И с третьей стороны, дело это вообще не шибко прибыльное.
И с четвёртой. мега-надёжности от развлекательных сервисов никто не ждёт.

Так что EBS бы проканал, если бы он нормально работал.

[Alex Mizrahi]

> Естественно это не физические диски, а скорее всего nas'ы и очень дешевые.

А в nas'ах не физические диски стоят? Чем nas от писюка отличается, по
сути?

[VS]

Да собственно а что сегодня за малым исключением не писюк?
NASы используют физические диски естественно, но в рейдах.
Тип этого рейда, возможнсть делать снапшоты, возможность давать клиентам
виртуальные LUNs по iscsi или san и другие фичи зависят от
навороченности и поэтому цены девайса.
Пойнт был в том, что покупая дорогой nas который все это умеет делать и
не использовать эти фичи - деньги на ветер, проще купить самый дешевый
или вообще собирать из деталей купленых во фрайзе.

[Captain Obvious]

SW> Это нормально и привычно. Я как по работе имею дело с Linux images,
SW> которые вообще без локального диска (tftp boot), нормально!

Так здесь ты за каждую хрень платишь дополнительно, что выливается в
копеечку.

IMHO EC2 имеет смысл в том случае если:

1. одного сервера не хватает
2. нагрузка неравномерна, так что имеет смысл изменять выч. мощность,
наращивая её во время пика

Или

3. временно нужны вычислительные мощности, например, для какого-то
эксперимента

[Ilya L]

On 9/30/11 5:52 AM, Alex Mizrahi wrote:
>> Никто никуда ничего не будет доставать и ставить. VM instance может
>> слечь в любой момент и availability EBS volume не гарантируется.
>
>> Говорил же, надо делать кроном регулярные снапшоты и класть их в S3.
>
> Я очень редко встречаю такие применений, чтобы данные за последние
> часы/дни были вообще не нужны. Уж лучше подождать пока поднимется. Или
> они могут просрать вообще навсегда?
>

Могут безусловно.

Любое применение, допускающее форканье update logs позволяет deal with
data loss. Exchange, Oracle...

>> Для домашнего сервера ежедневный снапшот и 24-часовое RPO вполне
>> acceptable. Все равно в чулане лучше не получится.
>> Про performance я тоже предупреждал. Но, опять же, для домашнего сервера
>> оно OK.
>
> Для домашнего сервера куда проще купить нормальный VPS и не парить мозг
> с EBS. Если посчитать сумму EC2 + S3 + EBS + IP/DNS так выйдет что и
> выделенный сервер с raid1 и бэкапами арендовать можно.
>

Я думаю что Амазон будет намного дешевле чем выделенный сервер.
"Нормальный VPS" будет иметь те же проблемы и не иметь амазонских решений.

>>> И вообще я плохо представляю как вообще можно реализовать это в h.a.
>>> варианте на обычном железе -- дублирование вручную выльется в нефиговый
>>> оверхед.
>>
>> Если хотя бы 15 minutes RPO acceptable, то можно дешево и сердито.
>
> С полноценным durability, то есть если база данных транзакцию
> закоммитила, то она восстановится?
> Или за 15 минут восстановится вчерашний снапшот?

Определение RPO implies the former. На Винде еще и application
consistency будет если app VSS поддерживает.

>> Но мне их модель со снапшотами в S3 больше нравится.
>
> Для каких применений?

Вот для домашних как раз. И вообще, концептуально, с позиции
девелопера, разрабатывающего как раз вот это самое фуфло ;-)

--
ilya

[Alex Mizrahi]

>> О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
>> О©╫О©╫О©╫О©╫/О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫
>> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?

> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ update logs О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ deal with
> data loss. Exchange, Oracle...

О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫
cloud О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ block device, О©╫О©╫О©╫ О©╫О©╫ О©╫сё О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫...

> О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫ О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ $25 О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ micro instance О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

> "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ VPS" О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ -- О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫сё
О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫.

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ VPS О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫ 100% О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫сё О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (S3 О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ 8 О©╫О©╫О©╫О©╫О©╫, EBS -- О©╫О©╫ 6 О©╫О©╫О©╫О©╫О©╫, +О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫), О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ $25/mo О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ 3 О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫
О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. VPS О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ лёО©╫ О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ vps О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ linode,
О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ -- О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫дёО©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ -- О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ VPS
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫.О©╫.

>> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ durability, О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
>> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?
>> О©╫О©╫О©╫ О©╫О©╫ 15 О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫?

> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ RPO implies the former.

The former О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫?

> О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫ application
> consistency О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ app VSS О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫чёО©╫ О©╫О©╫О©╫О©╫? О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, VSS О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ VSS О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

> О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫.

О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, IMHO. О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫... О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "crash consistent" О©╫О©╫О©╫О©╫О©╫О©╫...

> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ ;-)

О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫-О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
-- О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫/О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫: О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ (О©╫О©╫) О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

О©╫, О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫" О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, VSS О©╫ О©╫.О©╫.
О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫.О©╫. О©╫ О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫,
О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

[Ilya L]

On 10/3/11 1:26 AM, Alex Mizrahi wrote:
>>> С полноценным durability, то есть если база данных транзакцию
>>> закоммитила, то она восстановится?
>>> Или за 15 минут восстановится вчерашний снапшот?
>

>> Определение RPO implies the former.
>
> The former эквивалентно синхронной репликации. Ты это имел в виду?
>

RPO - recovery point objective или сколько данных теряется после
failover/restore, 15 минут в данном случае.
RTO - recovery time objective или сколько занимает процесс
failover/restore.

>> На Винде еще и application

>> consistency будет если app VSS поддерживаете.
>
> Засчёт чего? Насколько мне известно, VSS предназначен для бэкапов, и
> поддержка VSS со стороны приложения заключается в том, чтобы к моменту
> создания снапшота ФС дописать до консистентной точки и временно
> прекратить запись пока не сделают снапшот.

+ flush FS. А что по твоему включает в себя application consistency?

> А для репликации нужно писать непрерывно, остановка приложения не поможет.
>

Ты зачем-то путаешь synchronous replication со всем остальным. В
storage arrays sync достаточно узкая ниша по сравнению с async
replication типа SRDF / async SnapMirror.

Я sync vs. async вижу, наверное в 10%. В основном в европах. Проблема в
том что sync работает только в радиусе 100км из-за latency.

Внутри storage array для high availability достаточно RAIDs, для
inter-campus достаточно sync replication и active-active cluster, для
East Coast - West Coast disaster recovery protection нужен async
replication.

У Амазона не все из этого есть, но идея та же. EBS volume snapshots,
сохраняемые в S3 с точки зрения high availability это средство для
митигации site failures.

>> Вот для домашних как раз.
>

> Для домашних достаточно обычных бэкапов, IMHO. Впрочем, может через
> снапшоты их проще делать... Но тогда получаешь "crash consistent" данные...

>
>> И вообще, концептуально, с позиции девелопера,
>> разрабатывающего как раз вот это самое фуфло ;-)
>

> Странная позиция, честно говоря.

Это был disclaimer. Я не пользователь и знаю как это пользуется только
от product managers и customer meetings.

> По-моему от этих снапшотов вреда больше
> -- юзеры считают их простым способом организовать репликацию/бэкапы, но
> на самом деле они не являются заменой ни того, ни другого: репликацию и
> бэкап лучше организовать средствами приложения (бд) и учитывая специфику.

На самом деле в non-virtual world бэкапы тоже делаются снапшотами
LUN-ов в storage array.

Разница между async replication и бэкапом в RTO (см above :-). С async
replication через 20 минут после начала failover появляется online DB
instance, которая 15 minutes behind относительно начала процесса
failover. Replay 15 minutes worth of transaction logs занимает
достаточно мало времени. Сравни с backup restore для 1TB DB. Exchange
вообще можно поднять сразу и процессить логи in background.

EBS snapshots подсасывают в этом контексте потому что provisioning из
S3 в EC2 занимает некоторое ненулевое время. У нас это практически instant.

--
ilya

[Alex Mizrahi]

>>> Определение RPO implies the former.
>>
>> The former эквивалентно синхронной репликации. Ты это имел в виду?

> RPO - recovery point objective или сколько данных теряется после
> failover/restore, 15 минут в данном случае.
> RTO - recovery time objective или сколько занимает процесс
> failover/restore.

Ааа, понятно. Попутал, sorry...

В общем, мне как пользователю хочется RPO в районе нуля, а RTO уже как
получится (в пределах разумного), и подешевле =)

>> Засчёт чего? Насколько мне известно, VSS предназначен для бэкапов, и
>> поддержка VSS со стороны приложения заключается в том, чтобы к моменту
>> создания снапшота ФС дописать до консистентной точки и временно
>> прекратить запись пока не сделают снапшот.

> + flush FS. А что по твоему включает в себя application consistency?

То есть оно стопорит приложение каждые 15 минут и это нормально? Не
думал что vss так хорошо работает.

> Ты зачем-то путаешь synchronous replication со всем остальным.

Ну это идеальный вариант, хотя если не мега-важное приложение async
вполне пройдёт.

> В storage arrays sync достаточно узкая ниша по сравнению с async replication типа
> SRDF / async SnapMirror.

А как оно, кстати, взаимодействует с командами синхронизации (FLUSH)
уровня block dev? Если, к примеру, обычные операции записи не ждут
подтверждения от удалённой стороны, а во время FLUSH подтверждение
ожидается -- это уже sync или считается за отдельный промежуточный вариант?
Или на эти команды просто забивают?

> Внутри storage array для high availability достаточно RAIDs,

А если электроника или сетевая часть сгорит? Я понимаю что вендор
старается всё дублировать и всё такое, но мне было бы спокойнее если
рядом стояли бы две не очень навороченные железяки и синхронно
реплицировали.

>> По-моему от этих снапшотов вреда больше
>> -- юзеры считают их простым способом организовать репликацию/бэкапы, но
>> на самом деле они не являются заменой ни того, ни другого: репликацию и
>> бэкап лучше организовать средствами приложения (бд) и учитывая специфику.

> На самом деле в non-virtual world бэкапы тоже делаются снапшотами LUN-ов
> в storage array.

Да понятно что админам удобнее не разбираться что там внутри, но бд
бэкапить её собственными средствами IMHO правильнее.

> Разница между async replication и бэкапом в RTO (см above :-). С async
> replication через 20 минут после начала failover появляется online DB
> instance,

Что-ж оно делает-то эти 20 минут?
Или ты в том плане что софт тормозной, а на уровне хранилища оно мгновенно?

которая 15 minutes behind относительно начала процесса
> failover. Replay 15 minutes worth of transaction logs занимает
> достаточно мало времени. Сравни с backup restore для 1TB DB. Exchange
> вообще можно поднять сразу и процессить логи in background.

Оно, конечно, быстрее разворачивания бэкапа, но бд как правило умеют
warm/hot standby, которые поднимаются куда быстрее. Так что не совсем
понятно зачем оно вообще нужно.

> EBS snapshots подсасывают в этом контексте потому что provisioning из S3
> в EC2 занимает некоторое ненулевое время. У нас это практически instant.

А ещё если проблема с EBS накрыла сразу нескольких клиентов...

[Alex Mizrahi]

> А что вместо и за сколько?

Обычные VPS.

Например:

http://www.linode.com/

Linode 512MB -- $20/mo
Linode 768MB -- $30/mo

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

Для джедаев есть дешевле: http://prgmr.com/xen/

$9.6 512MiB 12GiB 80GiB
$16 1024MiB 24GiB 160GiB

Ещё дешевле можно найти на virtuozzo вместо xen.