Назад | Перейти на главную страницу

Конфигурация серверов для повышения производительности и обеспечения избыточности для сайта ASP.NET с SQL Server

Я администрирую довольно большой веб-сайт (в настоящее время около 300 тысяч просмотров страниц в день), который, как ожидается, будет быстро расти. В настоящее время IIS и SQL Server работают на четырехъядерном сервере с жесткими дисками RAID 10 SAS и 32 ГБ ОЗУ. Менее мощный сервер настроен как холодное резервное копирование. Базы данных синхронизируются ежедневно, а также файлы сайта ежедневно перемещаются на сервер резервного копирования. Если основной сервер выйдет из строя, сайт может снова заработать через несколько часов, но это не идеально. Я ищу решение, которое предложит:

Также решение должно включать аварийное восстановление. Если центр обработки данных загорится, нам понадобится решение, которое вернется к сети менее чем за один день (мы думаем сохранить копию данных и сайта на наших локальных серверах, но нам понадобится способ сделать процесс максимально автоматическим. Основной сервер размещен в центре обработки данных в Германии).

База данных составляет 50 ГБ +, а веб-приложение довольно мало.

Все это звучит довольно стандартно. Я собираюсь использовать SQL Server 2008 R2 или SQL Server 2012 для части базы данных.

Первое, что вам нужно сделать, - это снять IIS с SQL Server и поместить его на собственный компьютер. Вам также понадобится какой-то балансировщик нагрузки, который будет размещен перед веб-фермой. Я бы порекомендовал что-то вроде F5 или Cisco, хотя вы можете использовать балансировщик нагрузки на базе Linux, если у вас есть специалист по Linux. После того, как вы установили балансировщик нагрузки, вам нужно расширить веб-ферму, сделать это довольно просто. Вы просто покупаете еще один сервер, настраиваете его как обычно и добавляете в ферму в балансировщике нагрузки.

Что касается SQL HA, вы, вероятно, захотите взглянуть на зеркальное отображение базы данных SQL Server. Это даст вам два сервера в локальном центре обработки данных (хотя вы можете разместить их в разных центрах обработки данных) с автоматическим переключением при отказе, если у вас есть Enterprise Edition SQL Server.

Настроить резервные копии для копирования из центра обработки данных в офис не так уж и сложно. Просто настройте сайт на сайт VPN и скопируйте файлы по сети. Пропускная способность и задержка становятся единственной проблемой на этом этапе.

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

На сайте веб-сервера DR легко. Просто укажите DNS-серверы на общедоступный IP-адрес на сайте аварийного восстановления.

Что касается SQL Server, то вы, вероятно, захотите посмотреть на доставку журналов транзакций с первичного сайта на сайт аварийного восстановления. Если вам нужна более простая конфигурация, посмотрите группы доступности AlwaysOn SQL Server 2012. Они будут выполнять автоматическое переключение при отказе, синхронизацию и асинхронную репликацию данных и т. Д. Группы доступности AlwaysOn действительно требуют домена Active Directory, поэтому вам нужно сначала изучить эту настройку.

Если вы еще не заметили, DR не дешево и не просто.

Подробнее о SQL Server:

М.С. опубликовал много бесплатных книг, одна из которых называется Руководство по решениям Microsoft SQL Server AlwaysOn для обеспечения высокой доступности и аварийного восстановления .

Вы найдете больше технических рекомендаций Вот.

Также оказывается, что бэкап на Windows не так просто, как в Linux.


Высокая доступность

Обычно для веб-сайтов вы можете делать следующее:

  • Пусть ваши сети будут без гражданства; они не должны использовать состояние сеанса или состояние просмотра - это усложняет масштабируемость. Вместо этого позвольте URL-адресу решать, что показывать; избегая общего состояния, вы можете эффективно использовать кеши, такие как NGINX впереди, который поддерживает кросс-платформенный HTTP:
  • Кэширование с использованием HTTP - НЕ с использованием memcached, varnish или MS Velocity - потому что вам не нужен кеш приложения, если вы можете его избежать - это костыль. Однако для правильного кэширования с использованием HTTP вам нужны заголовки ETags или Last-Modified, и вам нужно исправить, чтобы ASP.Net правильно возвращал 304 Not Changed для динамических страниц, которые фактически не изменились - это может потребовать некоторого корректирующего программирования. .
  • Если вам ДЕЙСТВИТЕЛЬНО нужно состояние по причинам, связанным с наследием или по другим причинам, подумайте о написании поставщик настраиваемого состояния. Я могу порекомендовать иметь хранилище NoSQL-ключ-значение в качестве бэкэнда, которое поддерживает как аварийное переключение / отказ узла, так и истечение срока действия ключа. Рекомендую отличный Риак с такими функциями, как этот. Если вы затем добавите больше приложений, которые не говорят на Microsoft, вы все равно сможете использовать HTTP-интерфейсы Riak. Не забудьте сериализовать с помощью чего-то всемирно известного, например BSON или MessagePack. Выполняя таким образом общее состояние, вы все равно можете масштабировать свои веб-сайты при распределении всего состояния сеанса.

Как правило, для данных можно делать следующее:

  • Начните разделять монолитные большие приложения на отдельные приложения с индивидуальными хранилищами - таким образом вы сможете сделать более осознанный выбор того, как перемещать эти данные в центры обработки данных или на серверы с резервированием.
  • Вы можете адаптировать очень легко распределенный способ программирования, такой как использование стиля CQRS для написания логики предметной области с событиями и источником событий для сущностей. Однако это требует некоторых от ваших программистов.
  • Начните с асинхронной репликации (см. Самый верхний раздел) в этом ответе.
  • Начните писать саги для устранения несоответствий, возникающих из нескольких источников истины (например, в случае разделения сети или отдельных чтений в одной и той же строке версии в БД)
  • Начните двигаться к хранилищу данных, которое более легко реализует HA - например, Риак или Кассандра.

Удачи!