Чтобы упростить нашу среду, на самом атомарном уровне у нас есть веб-сайт .NET, работающий на IIS 6 на одном сервере, и этот веб-сайт зависит от данных из базы данных MS SQL 2005 на другом сервере.
Мы продублировали эту инфраструктуру на географически удаленном участке для целей аварийного восстановления. Мы синхронизируем файлы кода .NET с удаленным сервером IIS. Мы регистрируем отправку наших данных SQL на удаленный сервер SQL.
Кажется, что мы могли бы сделать что-то подобное в облаке Amazon. Используйте машины EC2, поддерживаемые томами EBS. Преимущество состоит в том, что мы могли использовать машины меньшего размера с меньшими затратами до тех пор, пока у нас действительно не возникнет потребность в аварийном переключении, и в этом случае мы могли бы развернуть гораздо более крупные машины, чтобы справиться с нагрузкой и присоединить уже существующие тома EBS.
Этот проект находится только на стадии открытия / исследования, и мы могли бы извлечь пользу из некоторого опыта ветеранов сообщества, использующего Amazon AWS. Что сразу приходит в голову как полезное:
Есть ли у кого-нибудь опыт работы с MS SQL Server 2005 в AWS? Производительность неизбежно пострадает от нагрузок OLTP, подобных той, которая создается веб-сайтами, управляемыми базами данных, но где ваш виртуальный SQL-сервер работал и выходил из строя (т.е. дисковый ввод-вывод был дерьмом ... мы могли обрабатывать ~ 5 тыс. Транзакций в секунду на нашем физическом сервере и с такой же виртуальной машиной наша емкость была уменьшена вдвое).
Сэкономили ли вы в долгосрочной перспективе после всех непредвиденных затрат на использование решения аварийного восстановления в облаке? Где были скрытые расходы?
Если бы вы перемещали данные на Amazon автоматически, как вы с этим справлялись? Плоские файлы - это просто, но если вы используете SQL или Exchange, меня особенно интересует, какие инструменты вы использовали.
Есть ли способ писать напрямую в том EBS, или вам приходится подключать тома EBS к экземплярам EC2 и работать с ОС?
Если вам пришлось переключиться на AWS, чтобы справиться с производственной нагрузкой, как это работало в качестве решения аварийного восстановления? Очевидно, что цели восстановления у всех разные, поэтому я думаю, мне просто интересно, где AWS был довольно элегантным / выгодным, а где он просто не выдержал для вас
Приветствуются другие идеи и проверки реальности. TIA за то, что нашли время поделиться своими знаниями с сообществом и со мной.