В настоящее время у нас есть веб-приложение на основе Java, которое работает в WebSphere и обращается к SQL Server 2008.
Приложение требует частых изменений кода и файлов, поэтому мы обновляем файлы EAR в WebSphere не реже одного раза в месяц, но обычно чаще. Это приложение, интенсивно использующее базы данных.
Простои обходятся нам очень дорого, и сейчас мы стараемся делать это в часы наименьшей нагрузки (около 3 часов ночи в будние дни). Забегая вперед, похоже, что это не вариант (особенно с учетом частых обновлений нашего приложения), и мы ищем лучшую настройку хостинга, например кластер. Мы надеемся решить некоторые из наших проблем также с помощью новой настройки (для которой до сих пор мы прибегали к обходным путям).
Мы имеем в виду многоузловой кластер. Я понимаю кластеры примитивно, поэтому, если какое-либо предположение ниже неверно, дайте мне знать.
Вот наши новые требования:
Вот несколько вопросов, которые у меня есть:
Похоже, вам нужно два кластера. Вам понадобится кластер с балансировкой нагрузки для веб-приложения с балансировщиком нагрузки перед веб-серверами, чтобы сбалансировать веб-трафик, чтобы в случае отказа одного сервера другой обрабатывал нагрузку. Таким образом, вы можете извлечь одну машину из кластера, обновить ее, внести изменения в базу данных, затем удалить машину со старой версией и вставить машину с новой версией.
На стороне базы данных вам понадобится активный / пассивный кластер. Это позволит перезапустить службу в течение нескольких секунд в случае аппаратного сбоя на ноте, на которой запущен экземпляр SQL. Это не поможет предотвратить сбои в работе в случае плохого выпуска или если процесс выпуска базы данных блокирует объекты базы данных. Это также не повлияет на масштабирование нагрузки базы данных между двумя (или более) узлами кластера. Кластеры SQL запускают экземпляр SQL на одном физическом узле в любой момент времени.
Это, вероятно, само собой разумеется, но не забывайте, что все, что вы полагаетесь на синхронизацию JVM или единичные / глобальные данные, больше не будет безопасно для кластерных серверов WebSphere.
Я не могу ничего сказать об использовании JVM с поддержкой кластеров с WebSphere. Я знаю, что WebSphere обычно не поддерживает работу на каких-либо JVM, кроме своей собственной, но Google указывает, что некоторые люди комбинируют эти продукты.
С WebSphere вы также хотите подумать о том, что у вас есть перед сервером приложений для поддержания привязки сеанса к определенному члену кластера и для поддержки переключения при отказе, когда член кластера не работает. Обычно это выполняется подключаемым модулем WebSphere. для конкретного веб-сервера, такого как IBM HTTP Server или Microsoft IIS.
И если вам нужно переключение сеанса при отказе (IMO, необязательно), вы должны также настроить диспетчер сеансов для распределенных сеансов (либо через хранилище базы данных, либо через репликацию сеанса из памяти в память). Что также накладывает дополнительные ограничения на то, что вы храните в сеансе, поскольку его содержимое теперь должно быть сериализуемым. И вам нужно будет выбрать одну из доступных стратегий для принятия решения, когда хранить или реплицировать данные из памяти в распределенное место.