Здравствуйте, коллеги!

Есть веб-приложение (asp.net mvc), хранящее все свои данные в локальных файлах. Допустим для целей и потребностей этого приложения этого достаточно.
Рассматриваем вариант размещения (хостинга) этого приложения в Azure. Как я понял (исходя из документации по Azure) для виртуальной машины в Azure не гарантируется её бесперебойная работа, а наоборот говорится о том что переодически инстансы VM прибиваются и необходимо для хранения долговременного данных использовать только внешние хранилища (sql azure или прочие хранилища).

Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

Здравствуйте, Аноним, Вы писали:

А>Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

А речь идёт про виртуальные машины или сервис? Для первого варианта можно подмонтировать блоб как диск и хранить на нем данные.
А вот сервис по природе stateless и лучше ориентироваться на это в проектировании приложения.

Опять же, вы можете в обоих случаях запустить более одного инстанса. Надо и это учитывать.

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Аноним, Вы писали:

А>>Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

Doc>А речь идёт про виртуальные машины или сервис? Для первого варианта можно подмонтировать блоб как диск и хранить на нем данные.
Это веб-сервис, сделан как asp.net mvc приложение, работает под IIS-ом. Его хочется запустить и хостить на виртуальной машине в ажуре.
Про подмонтировать блоб — понял, спасибо). Но у нас файлов много и они активно используются, наверно при помещении их на подмонтированный блоб — скорость работы с ними заметно просядет. Одна из причина использования локальных файлов — для быстрого доступа.


Doc>А вот сервис по природе stateless и лучше ориентироваться на это в проектировании приложения.
Не понял, у сервиса же всё равно есть данные. В нашем случае для хранения этих данных использованы файлы.


Получается что всё таки саму виртуальную машину в ажуре нельзя использовать для долговременного хранения файлов веб-приложения?
В таком случае что лучше выбрать для надежного/отказоустойчивого хостинга (чтобы не переделывать приложение) ?

Здравствуйте, Аноним, Вы писали:

А>Получается что всё таки саму виртуальную машину в ажуре нельзя использовать для долговременного хранения файлов веб-приложения?
А>В таком случае что лучше выбрать для надежного/отказоустойчивого хостинга (чтобы не переделывать приложение) ?

Саму машину ни в коем случае не следует использовать для долговременного хранения файлов.

В Ажуре, как уже сказали, можно блоб подмонтировать. В AWS для тех же целей есть EBS (с той разницей, что EBS-диск в каждый момент времени монтируется только к одному инстансу).

Да, конечно, виртуальный диск в облаке будет помедленнее локального физического (хотя вот, например, EBS-диски с некоторых пор поддерживают Provisioned IOPS).
Но насколько я представляю архитектуру Вашего приложения — она изначально не рассчитана на высокие нагрузки (раз приложение не масштабируется дальше одного физического сервака). Поэтому сомневаюсь, чтобы Вы заметили существенную разницу при переезде в облако.

Здравствуйте, Аноним, Вы писали:

А>Это веб-сервис, сделан как asp.net mvc приложение, работает под IIS-ом.
А>Его хочется запустить и хостить на виртуальной машине в ажуре.

Под сервисом я понимаю именно Azure PaaS, где создаются специальные Worker и Web роли. Как я понимаю, у вас IaaS — просто поднята VM, где все развернуто.

А>Про подмонтировать блоб — понял, спасибо). Но у нас файлов много и они активно используются, наверно при помещении их на подмонтированный блоб — скорость работы с ними заметно просядет. Одна из причина использования локальных файлов — для быстрого доступа.

Просядет, но как вариант (слышал, но не использовал) — сделать из них рейд. Поищите, вроде такое возможно.

Doc>>А вот сервис по природе stateless и лучше ориентироваться на это в проектировании приложения.
А>Не понял, у сервиса же всё равно есть данные. В нашем случае для хранения этих данных использованы файлы.

Есть блобы, azure sql.

А>Получается что всё таки саму виртуальную машину в ажуре нельзя использовать для долговременного хранения файлов веб-приложения?

Её саму — нет. Именно ввиду её природы — как для надежности, так и для масштабируемости, ведь тогда запросы могут обрабатывать более 1 инстанса приложения или VM.

А>В таком случае что лучше выбрать для надежного/отказоустойчивого хостинга (чтобы не переделывать приложение) ?

Попробуйте поискать по поводу рейда из дисков на блобах. Но в любом случае, если вы хотите получить максимальную отдачу от Azure стоит его переписать под PaaS.

Здравствуйте, scale_tone, Вы писали:

_>В Ажуре, как уже сказали, можно блоб подмонтировать. В AWS для тех же целей есть EBS (с той разницей, что EBS-диск в каждый момент времени монтируется только к одному инстансу).

_>Да, конечно, виртуальный диск в облаке будет помедленнее локального физического (хотя вот, например, EBS-диски с некоторых пор поддерживают Provisioned IOPS).
_>Но насколько я представляю архитектуру Вашего приложения — она изначально не рассчитана на высокие нагрузки (раз приложение не масштабируется дальше одного физического сервака). Поэтому сомневаюсь, чтобы Вы заметили существенную разницу при переезде в облако.

Для ожидаемых нагрузок архитектура вполне устраивает. С нагрузками проблемы нет, за счет чтения данных с локальных файлов удалось обеспечить довольно высокую скорострельность (при отработке запроса могут быть множественные рандомные чтения разных данных).

Есть желание обеспечить именно надежность хранения данных в том числе от отказов железа. Было ожидание что "облачные" виртуальные машины это как-то умеют.

Получается реальные варианты следующие:
— ажуре, +переделка архитектуры доступа к данным, а так как совсем не хочется её усложнять, то вариант видится непривлекательным.
— амазон с EBS. довольно интересный вариант, спасибо , смущает только производительность. какая интересно она в сравнении с локальным диском?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, коллеги!

А>Есть веб-приложение (asp.net mvc), хранящее все свои данные в локальных файлах. Допустим для целей и потребностей этого приложения этого достаточно.
А>Рассматриваем вариант размещения (хостинга) этого приложения в Azure. Как я понял (исходя из документации по Azure) для виртуальной машины в Azure не гарантируется её бесперебойная работа, а наоборот говорится о том что переодически инстансы VM прибиваются и необходимо для хранения долговременного данных использовать только внешние хранилища (sql azure или прочие хранилища).

А>Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

А чего просто сайт в azure не сделать? Бесплатно.

Здравствуйте, gandjustas, Вы писали:

G>А чего просто сайт в azure не сделать? Бесплатно.

А про ограничения не забыли?

Здравствуйте, gandjustas, Вы писали:


А>>Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

G>А чего просто сайт в azure не сделать? Бесплатно.

Вот я и пытаюсь понять, можно ли как-то использовать azure для подобного приложения (без переделки приложения)... пока выходит что нет, тк для локальных файлов не гарантируется надежное хранение.

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

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, gandjustas, Вы писали:

G>>А чего просто сайт в azure не сделать? Бесплатно.

Doc>А про ограничения не забыли?

Какие например?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:


А>>>Подскажите коллеги, получается что для такого веб-приложения неполучится использовать Azure для хостинга? Или я что-то неверно понял про Azure?

G>>А чего просто сайт в azure не сделать? Бесплатно.

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

А>Странно это, на мой взгляд "облачные" виртуальные машины как раз и должны обеспечить надежность именно самой машины и её устройств хранения.
Если ты берешь VHD и загружаешь в облако, то да. НО!
1) Ты платишь за весь VHD в storage, это порядка 10-20 гб, а данных там максимум 1-2 мб
2) Ты платишь за все время работы ВМ, хотя используется 0,001% времени
3) Тебе все равно придется возиться с настройками сети

А>А получается что веб-приложение надо специально изначально прогибать под платформу, что довольно затратно и не всегда имеет смысл.

Ты вполне можешь заменить FileStream на BlobStream и заменить открытие файла на получение блоба. Код почти не поменяется.
Что здесь означает "прогибать"?

Зато ты получаешь отказоустойчивый storage и можешь сайт хостить в бесплатном режиме.

Здравствуйте, gandjustas, Вы писали:

G>Какие например?

На free версии дается 1 час CPU на день. При большой нагрузке сайт просто отключат по этому лимиту. Причем не важно, обслуживал сайт 1 злобный краулер например, или 1000 юзеров.

см. сноску по ссылке
http://www.windowsazure.com/ru-ru/pricing/details/web-sites/

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, gandjustas, Вы писали:

G>>Какие например?

Doc>На free версии дается 1 час CPU на день. При большой нагрузке сайт просто отключат по этому лимиту. Причем не важно, обслуживал сайт 1 злобный краулер например, или 1000 юзеров.

Doc>см. сноску по ссылке
Doc>http://www.windowsazure.com/ru-ru/pricing/details/web-sites/

Во-первых это дофига. Это около миллиона запросов (учитывая что storage — локальные файлы). Даже кравлеры стока не сделают.
Во-вторых, если надо будет больше, то просто переключишь в shared.

Здравствуйте, gandjustas, Вы писали:

G>Во-первых это дофига.

Делать вывод не зная сайта — я бы постеснялся утверждать что это "дофига" (кстати, там не указан интервал тарификации CPU).
Кроме, там кроме CPU лимиты есть (нельзя привязать свой домен итд)

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>Ты вполне можешь заменить FileStream на BlobStream и заменить открытие файла на получение блоба. Код почти не поменяется.
G>Что здесь означает "прогибать"?
к примеру используется локальная БД sqlite, с файлами она работает самостоятельно, просто так не подменить.
вот и придется либо отказываться от неё и думать над другим решением.
и это ведь не просто отказываться. это сильно меняется реализация. тк sqlite, при работе внутри процесса ОЧЕНЬ быстрая при множестве мелких рандомных чтениях, сейчас не приходится заморачиваться за кэширование. а отказавшись — придется, надо будет анализировать сценарии, вводить доп-е кэши, упреждающие чтения, анализировать какие надо данные чтоб сделать один запрос на доставание больших данных. сейчас за это можно не заморачиваться тк чтения с локального файла, практически и так как кэш. производительность на множестве мелких запросов — десятки/сотни в милисекунду.

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

А>Странно это, на мой взгляд "облачные" виртуальные машины как раз и должны обеспечить надежность именно самой машины и её устройств хранения. А получается что веб-приложение надо специально изначально прогибать под платформу, что довольно затратно и не всегда имеет смысл.

Не не. Приложения которые разрабатываются для облака. Делаются таким образом что сервис или сайт(Node) является stateless. Т.е. он ничего у себя не хранит никаких файлов и никаких локальных баз
Делается это для того чтобы иметь возможность динамически подключать или отключать ненужные экземпляры сервиса/сайта в зависимости от нагрузки.
Например те же сессии предполагается насколько я помню хранить в Windows Azure Cache ну и т.п.

Здравствуйте, Аноним, Вы писали:

А>Есть веб-приложение (asp.net mvc), хранящее все свои данные в локальных файлах. Допустим для целей и потребностей этого приложения этого достаточно.

Допустим такое решение не годиться для облака. Облако это в первую очередь возможность оперирования католичеством обслуживающих Node. там самое главное это масштабирование в ширину. т.е. количество запущенных узлов, а не одна максимально мощная VPC. Соответственно отсюда появляются нюансы. Я вам в другой ветке ответил какие.

Приложение ваше просто не готово для портирования в облака. Дизайн кривоват с файлами. Придется переделать его на хранение в BLOB.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, gandjustas, Вы писали:

G>>Ты вполне можешь заменить FileStream на BlobStream и заменить открытие файла на получение блоба. Код почти не поменяется.
G>>Что здесь означает "прогибать"?
А>к примеру используется локальная БД sqlite, с файлами она работает самостоятельно, просто так не подменить.
А>вот и придется либо отказываться от неё и думать над другим решением.
А>и это ведь не просто отказываться. это сильно меняется реализация. тк sqlite, при работе внутри процесса ОЧЕНЬ быстрая при множестве мелких рандомных чтениях, сейчас не приходится заморачиваться за кэширование. а отказавшись — придется, надо будет анализировать сценарии, вводить доп-е кэши, упреждающие чтения, анализировать какие надо данные чтоб сделать один запрос на доставание больших данных. сейчас за это можно не заморачиваться тк чтения с локального файла, практически и так как кэш. производительность на множестве мелких запросов — десятки/сотни в милисекунду.
Если у тебя множество рандомных чтений и мало записей, то проще все в памяти иметь. Пофигу что там данные хранит. Хоть в файл (блоб) сериализуй.
Если тебе нужна масштабируемость при конкурентной работе с данными, то sqlite тебе не поможет.


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

Я перестал понимать что тебе надо вообще. Зачем тебе azure? Ты собираешься масштабировать приложение? Тебе acid гарантии нужны или нет? Отказоустойчивость нужна или нет?

Здравствуйте, Аноним, Вы писали:

Описанная Вами картина однозначно свидетельствует: использовать Azure (AWS etc.) для Вашего приложения без переделки приложения, может быть, и можно, но не нужно. У Вас нет реально высокой нагрузки (иначе SQLite давно пошел бы лесом), у Вас нет реальной потребности в высокой доступности (оффлайн на время поднятия базы из бэкапа для Вас — не проблема) и у Вас уже есть своя железка, на которой сейчас все работает. Т.е. вообще ни одного аргумента за переезд в облако.

Здравствуйте, gandjustas, Вы писали:


G>Если у тебя множество рандомных чтений и мало записей, то проще все в памяти иметь. Пофигу что там данные хранит. Хоть в файл (блоб) сериализуй.
G>Если тебе нужна масштабируемость при конкурентной работе с данными, то sqlite тебе не поможет.
один файл бд может быть сотни мегов. и их много. все в память не поднять. поднимается естественным образом в память то к чему происходят обращения. и этого достаточно. множество конкурентных чтений для sqlite не проблема, одновременные чтения идут параллельно и без проблем. текущей конкурентности на запись в рамках одного файла БД достаточно (при худшем раскладе, ожидаемая нагрузка — единицы изменений в секунду.).


G>Я перестал понимать что тебе надо вообще. Зачем тебе azure? Ты собираешься масштабировать приложение? Тебе acid гарантии нужны или нет? Отказоустойчивость нужна или нет?
мне нужен надежный хостинг с надежным хранением данных. я хочу найти наиболее оптимальный способ это обеспечить.
текущие нагрузочные характеристики приложения устраивают. ищу именно способ обеспечить надежное хранение данных, чтоб приложение по прежнему работало с локальными файлами (тк скорость устраивает), чтоб доступ к локальным файлам был такой же быстрый, но сами файлы за счет передовых облачных технологий хранились надежно, то есть как-то обеспечивалось разруливание сбоев железа..
один из рассматриваемых вариантов — ажур.

по появившемуся понимаю (спасибо всем ) картина для меня сложилась следующая. в ажуре данные нельзя долговременно хранить в локальных файлах, надо использовать специльные сервисы, один из них — блобы. блоб можно подмонтировать как диск к виртуальной машине. всё бы хорошо — но насколько просядет скорость обмена? судя по всему просядет в разы, а это плохо.
переделывать приложение на работу через BlobStream — сильно затратный путь (ибо sqlite впрямую работает с файлами, и не только sqlite — есть ещё другой функционал). и главное непонятно, а будет ли скорость нормальная работы с ним?
возможно мне в моем случае ажур действительно не нужен, тогда какие есть ещё варианты хостингов/платформ чтоб данные в локальных файлах надежно хранились?
спасибо ..