Хорошо, давайте начнем с нескольких слов. Я пришел к этому, настроив все таким образом, и был предпринят ряд (неизвестных) шагов, чтобы добраться до этого момента, чтобы в первую очередь повысить надежность и во вторую очередь производительность.
Теперь у нас проблемы с обоими.
Факты:
Что нам нужно сделать, так это взять под контроль весь этот беспорядок, лучше использовать имеющиеся у нас ресурсы и, если возможно, как можно быстрее улучшить балансировку этого приложения.
В идеале, я думаю, нам нужно перейти к многосерверной ситуации с правильным балансировщиком нагрузки и сервером состояния ASP.NET. У нас есть доступ к серверу состояний, который мы можем использовать сейчас, поэтому, если есть какие-то преимущества в использовании его в рабочих процессах, мы можем это сделать. Также хочу отметить, что добавление сервера (даже виртуального) - это не быстрый процесс (минимум 6 недель от начала до конца для новой виртуальной машины), и компания оценивает переход в новый центр обработки данных, поэтому они будут сопротивляться настройке чего-либо. новое, особенно если это была физическая система.
У нас есть доступ администратора к серверу, и мы можем делать все, что нам нужно как разработчик / архитектор, кроме перезагрузки сервера. Что мы должны получить специальное разрешение / уведомить команду мониторинга сервера о перезагрузке.
Я признаю, что это выходит за рамки моих знаний, и нам нужны некоторые рекомендации. Пожалуйста, задавайте столько вопросов, сколько считаете необходимым, чтобы лучше понять, что у нас происходит. Также полезны любые передовые практики или общие предложения.
При необходимости я могу предоставить более подробную информацию о взаимодействии между веб-службами и т. Д.
Изменить 1: Я должен объяснить общую «синхронизацию». Пользователь A подключается к серверу платформы для аутентификации / ведения журнала. Затем подключается к каждой веб-службе приложения по мере необходимости. Данные собираются из набора источников (сторонние базы данных WS, Oracle и SQL, общие файловые ресурсы и т. Д.), А затем передаются клиенту с использованием наборов данных. Существуют различные шаги (каждый вызов службы приложения для выполнения работы и вызов службы инфраструктуры для ведения журнала) в каждой синхронизации, и каждый является уникальным для приложения.
Похоже, что проблемы с масштабируемостью находятся на сервере приложений, а не на сервере базы данных. Поэтому лучше всего сбалансировать нагрузку на серверы приложений.
Балансировка нагрузки довольно проста и может выполняться на уровне сети. Это позволяет разместить X физических или виртуальных машин за VIP и распределять нагрузку между машинами в одностороннем порядке. Данный пользователь будет обращаться к разным машинам по каждому запросу.
При балансировке нагрузки лучше избегать информации о состоянии сеанса. Однако, если вы не можете этого избежать, потребуется сервер состояния сеанса, к которому могут подключаться все машины. В .NET это довольно тривиально, поскольку провайдеры состояния сеанса могут быть легко подключены с помощью Web.config. Это позволяет самим серверам приложений не иметь состояния, и поэтому VIP может направлять входящий трафик на любой сервер, который он хочет.
Балансировка нагрузки также позволит вывести машину из строя, если она станет проблемной или потребуется развернуть обслуживание. Это также пригодится во время развертывания, так как вы можете вывести половину машин из строя и выполнить развертывание, а затем поменять их местами. Это предотвращает одновременное выполнение двух версий кода приложения.