Здравствуйте, Аноним, Вы писали:
А>нагрузные характеристики приложения (в текущей архитектуре) нас устраивают. есть потребность обеспечить более высокую доступность (не 24*7*365, а скажем 99,7%). оффлайн в рабочее время (в обычном понимании времени) — нежелателен. Да, есть железка (арендуем в датацентре VDS), делаются переодически бакапы, пока (тьфу тьфу) сбоев по причине отказа железа HDD небыло. но вероятность же есть. и если такой факап реализуется, то будем какое-то время офлайн (пару часов), это плохо. вот и пытаюсь понять как можно обеспечить более высокую доступность, за счет использование надежного хранения файлов.
Ну так вот и считайте сами: если по статистике жесткие диски Вашего провайдера летят не чаще раза в год и если Вы в состоянии поднять базу из бэкапа за, скажем, пол-дня (остальные пол-дня оставляем на проблемы с сетью) — значит, Вы в шоколаде, и делать ничего не надо. В противном случае — придется менять СУБД на поддерживающую зеркалирование. И вот тогда уже, заодно, можно подумать о переезде в облако. А там уже есть: SQL Azure, Amazon RDS etc. etc.
А>облако в архитектуре — масштабирование вширь front-end-ов, но сидящих на одном (облачном надежном) back-end (в смысле бд/storage), нам не надо. тк фронт-енды почти не работают, основная нагрузка на бд — много рандомных чтений. интересен "облачный HDD" подключаемый к VDS, чтоб был такой же быстрый как локальный и надежный как "облачный" (хостер, как-то бы обеспечивал устойчивость от сбоев железа). такое бывает?...
А>если такого небывает, то надо думать над путем — постоянной асинхронной репликации вносимых изменений в облачное хранилище. это можно — но путь через "облачный HDD" более прост, если конечно есть такие сервисы, хотя я не вижу принципиальных причин почему бы им не быть, но пока незнаю их...
Есть одна причина.
CAP-теорема, называется
.
Есть, правда, ее расширение на граничный случай, которое можно сформулировать так: все три буквы аббревиатуры CAP все-таки можно заполучить в одной и той же точке пространства-времени, но это будет стоить о-очень много денег.
И этот граничный случай — пока не Ваш
.
В тех
редких случаях, когда действительно требуется быстрое и при этом высокодоступное (отказоустойчивое) хранилище блочных данных — применяется
SAN (возможно, Ваш провайдер даже готов продать Вам кусочек такой железки). Для операционки на сервере диск на SAN-сторадже выглядит как обычный (очень быстрый) жесткий диск, при этом никогда не ломающийся. Но SAN-стораджи стоят настолько много денег, что в подавляющем большинстве случаев дешевле обеспечить аналогичные показатели программными средствами: зеркалированием БД, репликацией и пр.
Я знаю только один случай, когда без SAN-а никак не обойтись: когда поднимают MSMQ на Windows Failover Cluster. Других не знаю.
Amazon EBS — это, кстати, и есть SAN. Только из-за большого числа юзеров на каждого юзера налагается throttling, поэтому реальная скорость EBS-диска не дотягивает до скоростей физической железки.
