Мне задали этот вопрос в интервью:
У меня есть сервер sql и приложение asp.net. Я хочу, чтобы мое приложение было доступно 24X7 часов, даже если сервер выйдет из строя.
Каковы различные способы достижения этого на уровне кода и на более высоком уровне (то есть не на уровне кода)?
В конечном итоге все сводится к деньгам. За каждую «девятку» из мифических «пяти девяток» (99,999% доступности, 5 минут простоя в год) приходится платить. вполне высокая. Система с доступностью 99,999% стоит миллионы долларов и должна охватывать оборудование, лицензии на программное обеспечение, выделенный высококвалифицированный персонал, обучение, процедуры и т. Д. И т. Д. Вы должны учитывать такие вещи, как обновления системы (исправления ОС и поставщиков), обновления приложений, различные процедуры обслуживания, такие как переиндексация базы данных и т. Д.
Но для очень грубого ответа я бы указал вам на Обзор решений высокой доступности:
Отказоустойчивая кластеризация обеспечивает поддержку высокой доступности для всего экземпляра SQL Server. Отказоустойчивый кластер - это комбинация одного или нескольких узлов или серверов с двумя или более общими дисками. Каждое приложение устанавливается в группу кластеров Microsoft Cluster Service (MSCS), известную как группа ресурсов. В любой момент каждая группа ресурсов принадлежит только одному узлу в кластере. У службы приложения есть виртуальное имя, которое не зависит от имен узлов, и называется именем экземпляра отказоустойчивого кластера. Приложение может подключиться к экземпляру отказоустойчивого кластера, указав имя экземпляра отказоустойчивого кластера. Приложению не обязательно знать, на каком узле находится экземпляр отказоустойчивого кластера.
Зеркальное отображение базы данных - это в первую очередь программное решение для повышения доступности базы данных за счет поддержки почти мгновенного переключения при отказе. Зеркальное отображение базы данных может использоваться для обслуживания единой резервной базы данных или зеркальной базы данных для соответствующей производственной базы данных, которая называется основной базой данных.
Как и зеркальное отображение базы данных, доставка журналов работает на уровне базы данных. Вы можете использовать доставку журналов для обслуживания одной или нескольких баз данных горячего резервирования для соответствующей производственной базы данных, которая называется первичной базой данных. Резервные базы данных также называются вторичными базами данных. Каждая база данных-получатель создается путем восстановления резервной копии базы данных-источника без восстановления или в режиме ожидания. Восстановление в режиме ожидания позволяет использовать полученную вторичную базу данных для ограниченной отчетности.
Репликация использует модель публикации-подписки. Это позволяет первичному серверу, называемому издателем, распространять данные на один или несколько вторичных серверов или подписчиков. Репликация обеспечивает доступность и масштабируемость в реальном времени на этих серверах. Он поддерживает фильтрацию для предоставления подмножества данных подписчикам, а также позволяет выполнять обновления по частям. Подписчики находятся в сети и доступны для отчетов или других функций без восстановления запроса. SQL Server предлагает три типа репликации: моментальный снимок, транзакцию и слияние. Репликация транзакций обеспечивает наименьшую задержку и обычно используется для обеспечения высокой доступности.
Для этого требуется несколько серверов, что для некоторых неприемлемо и может не понадобиться. Однако, если критически важно, чтобы вы достигли почти 100% времени безотказной работы, есть кое-что, известное как Отказоустойчивая кластеризация на уровне сервера, когда ваш сервер выходит из строя по любому количеству причин, один из других ваших серверов "вмешивается" и берет на себя управление.
На уровне кода вы мало что можете сделать: если ваш сервер выйдет из строя, он выйдет из строя. Что касается оборудования, они, вероятно, искали такую фразу, как Отказоустойчивая кластеризация.
Я не думаю, что многие здесь дадут вам ответ на вопрос собеседования, чтобы помочь вам блефовать на своем пути, и я уверен, что вы имели в виду не это, так что вот вам два варианта обучения.
Google "Высокая доступность asp.net". («Высокая доступность» - это термин, который вы ищете)
VMware vSphere with Fault Tolerance (FT) или эквивалент для других продуктов виртуализации. Это решение не ограничивается двумя серверами (один выходит из строя, другой берет на себя нагрузку), но может быть распределено по множеству серверов. Вопрос только в том, сколько вы хотите потратить.
Это полностью не зависит от ОС, что означает, что ваше приложение может работать на Windows Server, а ваша база данных - на Linux RedHat или наоборот.
Размещение вашего приложения asp.net и базы данных на двух отдельных серверах с возможностью горячего падения для обоих серверов обеспечит большую устойчивость. Упрощение кластеризации, как предложено выше, обеспечит это. Но тогда вам также нужно подумать о том, что если сервер базы данных выходит из строя, транзакции ставятся в очередь, а когда база данных восстанавливается, транзакции фиксируются в режиме FIFO.
Вообще говоря, я бы ответил на этот вопрос более подробно, но я согласен с @CXFX, что сделать это полностью на уровне кода невозможно.
В практическом бизнесе я бы посмотрел на:
Но это не относится к Stackoverflow.
Это не быстрый ответ, поскольку требуется много практического обучения, чтобы по-настоящему овладеть высокой доступностью в центре обработки данных, на платформе и на уровне приложений. Вот некоторые вещи, которые следует учитывать на высоком уровне.
Чтобы быть устойчивым к сбоям сервера и исправлениям, вам потребуется балансировка нагрузки на уровне сайта, какое-то решение SQL HA и приложение, которое не привязано к одному серверу.
На уровне сайта существует множество сторонних балансировщиков нагрузки, которые сами по себе являются избыточными. Или решение Microsoft Application Request Routing (ARR) - тоже отличный вариант.
Для SQL Server встроенные параметры кластеризации, зеркалирования или доставки журналов часто отвечают всем требованиям, а такие продукты, как DoubleTake, отлично справляются с этой задачей.
На уровне приложения вам нужно убедиться, что ничего не зависит от одного узла. Состояние сеанса - наиболее распространенная зависимость. Если он используется, его необходимо передать в резервное решение. SQLServer Session State, ScaleOutSoftware и теперь AppFabric - все это варианты, которые следует учитывать.
Истинная избыточность должна быть геоизбыточной в центрах обработки данных, которые должны располагаться достаточно далеко друг от друга, чтобы на них не повлияли какие-либо крупные стихийные бедствия.
И никакая технология не является достаточной без большого количества тестов и отличных процессов и процедур, чтобы знать, как справляться с неожиданными ситуациями как можно более плавно и регулярно тестировать различные избыточные части системы.