Репликация сессий “по памяти” – Memory-to-memory replication

Введение

Сессия – последовательность запросов к сервлету от одного пользователя из одного браузера. У каждой сессии есть свой ID. Идентификатор сессии генерится сервером при первом запросе пользователя и возвращается назад, в браузер.

Примером веб-приложения, использующего сессии, может служить интернет магазин, где в сессии хранятся данные о покупках пользователя.

Plug-in веб-сервера (IBM HTTP server) управляет “привязкой” сессий, т.е. он отправляет все запросы с одним ID сессии на тот сервер приложений в кластере, где эта сессия была создана. Если сервер приложений, обрабатывающий запросы в рамках сессии упал, то запросы пользователя пойдут на другой сервер приложений в кластере, при этом будет создана новая сессия, а данные из старой сессии будут потеряны. Например, в интернет магазине пользователь выбирает товары и  откладывает их в корзину, в этот момент сервер приложений, обрабатывающий запросы пользователя, падает. Пользователь нажимает “Оформить заказ”, но его корзина оказывается пуста, так как его запрос попал на другой сервер приложений, где нет информации о выбранных пользователем товарах. Такое явление называется “Эффект пустой корзины”. Для решения подобных проблем и повышения отказоустойчивости, данные сессий сохраняют во внешнем хранилище – базе данных или памяти другого сервера приложений. Отсюда два вида репликации сессий – БД (database) и “по памяти” (memory-to-memory, M2M).

Преимущества репликации сессий “по памяти”:

  • Гибкая настройка, топологии “peer-to-peer” и “client/server” (будут рассмотрены далее)
  • Отсутствие единой точки отказа
  • Передача данных сессий между серверами в зашифрованном виде
  • Отсутствие накладных расходов на внедрение и сопровождение БД
Репликация сессий “по памяти”

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

В WebSphere Application Server существует встроенный механизм для репликации данных – Data Replication Service (DRS). DRS определяется доменом репликации, т.е. группой серверов приложений, участвующих в репликации данных. Обычно домен репликации это кластер.

При использовании репликации “по памяти”, сервер приложений может быть настроен в одном из режимов:

  1. Client (клиент) – сервер отправляет копии сессий, владельцем которых он является, серверам работающим в режиме “Server” и получает от них, при необходимости, копии сессий других серверов, работающих в режиме “Client”;
  2. Server (сервер) – сервер принимает и хранит копии сессий от серверов работающих в режиме “Client”, а так же отправляет им копии сессий;
  3. Both mode (двойной режим) – сервер отправляет копии сессий другим серверам, а так же принимает и хранит у себя в памяти копии сессий других серверов. То есть используются оба режима, как “Client”, так и “Server”.

На основе этих трех режимов существует две различные топологии данного вида репликации:

  • Peer-to-Peer” – каждый сервер в кластере функционирует в двойном режиме.
    • Наилучший эффект при использовании этой топологии достигается тогда, когда каждый узел имеет одинаковые ресурсы (память, процессор и т.п.) и одинаковый объем работ;
    • Для данной топологии, начиная с 6-й версии WAS, доступна возможность “Hot Failover”. Это когда plug-in веб сервера знает, на каком сервере приложений находится резервная копия данных (реплика) и в случае сбоя переключает запросы на этот сервер. Таким образом устраняется дополнительная нагрузка, необходимая для получения резервной копии сессии;
    • Преимуществом этой топологии является то, что для ее реализации не требуется никаких дополнительных расходов на ПО, а так же временных затрат, необходимых для внедрения и сопровождения этого ПО;
    • Недостатком этой топологии является чрезмерное потребление памяти при очень большом количестве пользователей, что может привести к снижению производительности;
  • Client/Server” – часть серверов в кластере функционирует в режиме клиента, часть – в режиме сервера.
    • Сервера, функционирующие в режиме “Server”, не обрабатывают запросы пользователей, на них не могут быть размещены приложения, они представляют из себя хранилище данных для резервных копий сессий. Такие сервера только получают, хранят копии сессий и предоставляют их серверам-клиентам, которые обрабатывают запросы пользователей;
    • Резервные копии сессий находятся в изолированной JVM;
    • Сервера приложений, настроенные в режиме “Server”, должны быть запущены перед серверами, настроенными в режиме “Client”;
    • Данную топологию хорошо использовать в случае, когда узлы WAS отличаются по конфигурации ресурсов (память, процессор и т.п.);
    • Преимущества:
      • При использовании данной топологии снижается потребление памяти на каждом сервере;
      • Лучшая производительность;
      • Возможность перезапуска серверов, функционирующих в режиме “Server”, без ущерба для процесса обработки запросов;
    • Недостатки:
      • Накладные расходы на содержание дополнительных серверов приложений, которые не участвуют в процессе взаимодействия с пользователем;
      • Необходимо иметь несколько серверов, функционирующих в режиме “Server”, что бы избежать появления единой точки отказа.
Чек-лист по настройке репликации сессий M2M
  1. General information:
  2. Topology:
  3. Configuring memory-to-memory replication:
  4. HTTP Server tuning:
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Метки: , , , ,
Опубликовано в WebSphere Application Server, Тюнинг

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: