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