Лучшая практика: использование Asp.net и Microsoft SQL 2005 как наилучший способ балансировки нагрузки / достижения высокой доступности на двух физических сайтах?

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

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

Как насчет балансировки нагрузки на EC2, будет ли это стоить меньше второго центра обработки данных?

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

Иногда такую ​​настройку, как «admin.example.com», можно использовать на одном сервере / одном сервере sql для всех обновлений - особенно в сценарии, когда у вас есть база клиентов, которая выполняет обновления, и база «пользователей», которая в основном просматривает все опубликованные клиенты (например, в списках недвижимости, эта модель вполне подходит).

Что касается выделенного канала вместо VPN - если вы находитесь в двух хорошо связанных центрах обработки данных, вероятно, мало беспокойства по поводу трафика между ними - и этот трафик будет меньше, чем выделенный канал. Но вы увидите значительное снижение производительности при использовании VPN-соединения вместо LAN, особенно если у вас «болтливое» sql-приложение (много мелких запросов). У выделенных и VPN-сервисов это уменьшение будет, хотя VPN, как правило, используют TCP вместо UDP, что примерно вдвое увеличивает задержку.

Что касается DNS: настройте DNS-серверы в каждом месте, чтобы у вас был избыточный DNS, вы можете иметь каждую точку DNS только на локальные серверы, а не на Round Robin (таким образом, если один DNS-сервер не может быть достигнут, вы предполагаете, что веб-сервер находится в это место тоже не работает). В противном случае, используя простой круговой алгоритм, вы можете сообщить о записи «А» для нижнего местоположения.

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

У нас есть несколько лучших вариантов, когда мы разделяем клиента между двумя зданиями в одном районе (в Equinix Ashburn (DC) есть несколько зданий). Мы запускаем наши магистральные соединения, разделенные между зданиями, что дает нам возможность переключения при отказе между зданиями, но все преимущества локальной сети для планирования. Если вам просто нужно 2-8 серверов, найдите кого-нибудь вроде нас, чтобы настроить его, и помощь в планировании будет намного дешевле, чем пытаться сделать это самостоятельно.

Разделение центров обработки данных на восточном и западном побережье почти всегда не под силу людям с бюджетом / сложностью 4-8 серверов.

Удачи.