Azure Cloud Services vs VM для существующего сайта Asp.Net

Question

Я видел вариации этого вопроса, но не смог найти ни одного, что касалось нашего конкретного сценария.

У нас есть существующий сайт aps.net, который ссылается на базу данных SQL Server. База данных имеет пользовательские типы clr, поэтому ее можно разместить только в Azure VM, поскольку Cloud Services не поддерживают указанные типы.

Мы изначально хотели использовать виртуальную машину для базы данных и облачного сервиса для переднего конца, но возникли тогда некоторые вопросы:

1. Мы используем StateServer для хранения государства, но Azure не поддерживает это. Нам нужно будет настроить хранилище таблиц, базы данных SQL или роль рабочего, предназначенную для управления государством (новая рабочая роль является дополнительной стоимостью). Хранение таблиц не будет идеальным из-за производительности. Другие 2 варианта предпочтительнее, но они приводят к недостаткам в стоимости или сокращении приложений.
2. Мы используем SimpleMembership для управления пользователями. Нам нужно будет перенести таблицы членства из нашего SQL-сервера экземпляров vm в базы данных SQL Azure. Это неудобство, поскольку мы хотим сохранить все наши таблицы в одной и той же базе данных, а разделение на 2 может потребовать внесения некоторых изменений кода.

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

Вопросы:

• Если мы просто пойти маршрут VM для хостинга все?
• Есть ли какое-либо экономическое преимущество при использовании экземпляра виртуальной машины (для сервера sql) и экземпляра облачной службы (для интерфейса)?
• Кажется, что каждый добавленный «фоновый процесс» для облачной службы потребует новой рабочей роли. Например, если мы хотим включить smtp для почтовых служб, для этого потребуется новая роль и, следовательно, более высокая стоимость. Это верно?

Answer 1

Для запуска SQL Server с CLR и т. Д. Вам нужно запустить SQL Server на виртуальной машине.

Для веб-уровня есть преимущества для облачных сервисов (веб-роли), так как они stateless - очень легко масштабировать/не беспокоиться о настройке ОС. Настройка приложения выполняется с помощью сценариев запуска при загрузке. Если вы можете разместить свой контент сеанса соответствующим образом, модель без учета состояния будет проще масштабировать и поддерживать. Однако: если у вас есть какие-либо сложные установки для выполнения, которые требуют времени (или ручное вмешательство), тогда виртуальная машина действительно может быть лучшим маршрутом, поскольку вы можете построить VM, а затем создать главное изображение с этой виртуальной машины , У вас по-прежнему будут проблемы с управлением ОС и приложениями, с которыми вы столкнулись, как и в локальной среде.

Позвольте мне исправить вас на вашей третьей пуле в отношении фоновых процессов. Роль веб-роли облачного сервиса (или роли сотрудника) - это просто виртуальные машины Windows Server с некоторым кодом для запуска и мониторинга процесса. Вам не нужна отдельная роль для каждого. Не стесняйтесь запускать все приложение на одной веб-роли и масштабировать; вы просто будете масштабироваться на очень грубом зерне.

Answer 2

Некоторые вещи, которые следует учитывать ...

Если вы хотите быть дешевым, вы можете иметь свою роль в сети/работнике совместно использовать один и тот же код на одной машине, добавив RoleEntryPoint. Вот пост, который на самом деле показывает, как сделать то, что вы пытаетесь сделать с отправки электронной почты: управление Session http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx

мучительно медленно в SQL Azure DB, я хотел бы использовать Azure Cache, если вы can..it быстро ,

SQL Server с виртуальными машинами вызовет для вас проблемы, так как вам также понадобится создать виртуальную сеть между этим и любыми облачными сервисами. Это действительно глупо, но если вы разворачиваете облачный сервис и виртуальную машину, они обмениваются сообщениями с БАЛАНСИРОВАНИЕМ ОБЩЕСТВЕННОЙ НАГРУЗКИ, что вызывает потенциальную проблему безопасности и латентность сети. Таким образом, сначала вам необходимо виртуальную сеть (что является дополнительной стоимостью) .. тогда вам также потребуется разместить DNS-сервер для обращения к виртуальной машине SQL Server. Да, это действительно глупо, если вы не в порядке с вашим веб/ролей рабочих сообщающихся с SQL Server через Интернет :)

EDIT: изменил «общественный интернет» на «общественный балансировки нагрузки» (и отметил, латентность)

EDIT: приведенная выше информация является на 100% правильной вопреки комментарию Дэвида ниже. Пожалуйста, прочитайте руководство от Microsoft здесь:

http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario

НАПРЯМУЮ ОТ MICROSOFT РЕГЛАМЕНТИРУЮЩИЕ говоря о кросс связи Cloud Service (VM-> Веб/рабочие роли):

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

С сегодняшнего дня (8/29/2013) Azure VM и рабочие/веб-роли развертываются в РАЗЛИЧНЫХ «облачных сервисах». Поэтому связь между ними должна быть обеспечена через виртуальную сеть, которая предоставляет частные IP-адреса между экземплярами.

Чтобы следить за пунктом Давида ниже, это о добавлении ACL. Вы по-прежнему отправляете пакеты через Интернет, используя TDS (протокол SQL Server). Это можно зашифровать, но никакое здравомыслящее управление архитектурой/корпоративным управлением и безопасностью не позволит «разрешить» этот сценарий в рабочей среде.