Это третья часть серии кластеров Tomcat . В этом посте мы собираемся обсудить, как настроить репликацию сеанса в среде кластеризации Tomcat. Репликация сессий обеспечивает высокую доступность и полную отказоустойчивость для нашей кластерной среды.
[Проверьте видео ниже для лучшего понимания]
В моем предыдущем посте мы говорили о настройке простого балансировщика нагрузки и о том, как создать концепцию соответствия сеансов .
Как настроить репликацию сеанса в Tomcat
Прежде чем перейти к репликации сессии, нам нужно понять 2 важных понятия
- Multicast
- Диспетчер сеансов в Tomcat
Multicast
Многоадресная передача предназначена для передачи одного сообщения выбранной группе получателей. здесь многоадресная рассылка используется кластером tomcat для идентификации экземпляров этих частей кластера.
Есть 2 типа кластера
- Статический кластер Tomcat
- Динамический кластер Tomcat
В статическом кластере нет необходимости многоадресной рассылки, потому что для каждого кота мы статически определяем / настраиваем другие экземпляры. Но динамический кластер у нас не определен ничем. поэтому каждый кот в этом кластере как-то идентифицировать другие экземпляры кота.
Так что здесь используются многоадресные концепции. Каждый кот сначала присоединяется к одной многоадресной группе . и отправлять сигналы сердцебиения в периодическом интервале. поэтому другие экземпляры tomcat получили эти сигналы и добавили участника в кластер.
Диспетчер сеансов в Tomcat
Диспетчер сеансов используется для создания и управления сеансом от имени приложения. В спецификации сервлета request.getSession (); В строке упоминается, что контейнер (tomcat) отвечает за создание сеанса. здесь Tomcat использует Session Manager для этой цели.
Есть 4 типа диспетчера сессий
- Стандартный менеджер
- Постоянный менеджер
- Delta Manager
- Менеджер резервного копирования
Стандартный менеджер
Это менеджер по умолчанию, используемый tomcat. Хотя в нашем веб-приложении мы не упомянуты, tomcat использует этот менеджер для управления нашей сессией. Если вы хотите настроить этот стандартный менеджер, добавьте тег <Manager> в файл context.xml.
|
1
|
<Manager className=“org.apache.catalina.session.StandardManager” /> |
Здесь org.apache.catalina.session.StandardManager является полностью определенным именем класса стандартного менеджера.
Постоянный Ясли
Этот mnager должен сохранять информацию о сеансе в постоянном месте через некоторый интервал. Здесь доступны два типа магазина.
- Файловый магазин
- JDBC Store
File Store помогает хранить всю информацию о сеансе в отдельных файлах в базовой файловой системе (локальный жесткий диск или общая файловая система, такая как NFS, ..)
JDBC Store помогает хранить информацию о сеансе в реляционной базе данных.
Таким образом, используя Persistent Manager, мы можем создать кластер Tomcat. но его не поменяли местами в режиме реального времени. его толкает информацию через определенный промежуток времени. так что если что-то плохо произойдет (сбой) до этого интервала, то данные сеанса в памяти исчезнут.
Delta Manger
В этом посте мы собираемся использовать этот менеджер. Его копия сеанса для всех других экземпляров. поэтому этот менеджер обычно использует кластерную среду. но не хорошо для большого кластера.
Менеджер резервного копирования
этот менеджер обычно использует кластерную среду. Это как Delta Manger. но он будет реплицирован ровно на один другой экземпляр (резервный экземпляр). Он действовал так, будто один экземпляр является основным, а другой — резервным.
Действия по созданию репликации сеанса в кластеризации Tomcat
Здесь я продолжу с того места, где я оставил сообщение о схожести последнего сеанса . Поэтому проверьте этот пост и убедитесь, что все jumRoute настроены правильно. Так что шаги
- Включить многоадресную маршрутизацию
- Добавьте записи <Cluster> в файл conf / server.xml для всех экземпляров.
- Включить веб-приложение как распространяемое
1. Включите многоадресную маршрутизацию
В среде Linux большая часть ядра системы способна обрабатывать адреса многоадресной рассылки. но нам нужно добавить запись маршрута в таблицу маршрутизации ядра.
|
1
|
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 |
Здесь eth0 — мой интерфейс Ethernet. так что меняйте в соответствии с вашим интерфейсом
В многоадресном адресе принадлежат диапазон адресов класса D (с 224.0.0.0 по 239.255.255.255). поэтому мы сообщаем ядру, если кто-нибудь получит доступ к этим адресам, тогда он будет проходить через интерфейс eth0.
2. Добавьте записи <Cluster> в файл conf / server.xml для всех экземпляров.
Это очень важная часть для кластеризации Tomcat. Нам нужно добавить тег <Cluster> в файл conf / server.xml во всех экземплярах tomcat.
|
1
|
<Cluster className='org.apache.catalina.ha.tcp.SimpleTcpCluster'/> |
Мы можем добавить этот тег <Cluster> либо внутри тега <Engine>, либо в тег <Host>.
Здесь SimpleTcpCluster — это реализация Tomcat Cluster.
Этот тег выглядит как простой, но имеет много внутренних тегов. если мы опускаем, то он принимает значения по умолчанию. если мы хотим выполнить какую-либо обрезку (например, изменить многоадресный адрес, порт получения адреса), нам нужно использовать полный тег <Cluster>
Это полный <Cluster>
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
<Cluster className='org.apache.catalina.ha.tcp.SimpleTcpCluster'channelSendOptions='8'><Manager className='org.apache.catalina.ha.session.DeltaManager'expireSessionsOnShutdown='false'notifyListenersOnReplication='true'/><Channel className='org.apache.catalina.tribes.group.GroupChannel'><Membership className='org.apache.catalina.tribes.membership.McastService'address='228.0.0.4'port='45564'frequency='500'dropTime='3000'/><Sender className='org.apache.catalina.tribes.transport.ReplicationTransmitter'><Transport className='org.apache.catalina.tribes.transport.nio.PooledParallelSender'/></Sender><Receiver className='org.apache.catalina.tribes.transport.nio.NioReceiver'address='auto'port='4000'autoBind='100'selectorTimeout='5000'maxThreads='6'/><InterceptorclassName='org.apache.catalina.tribes.group.interceptors.TcpFailureDetector'/><InterceptorclassName='org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor'/></Channel><Valve className='org.apache.catalina.ha.tcp.ReplicationValve' filter=''/><Valve className='org.apache.catalina.ha.session.JvmRouteBinderValve'/><ClusterListener className='org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener'/><ClusterListener className='org.apache.catalina.ha.session.ClusterSessionListener'/></Cluster> |
Проверьте мой пример файла conf / server.xml (для справки)
Здесь большая часть кода — это код котельной плиты. просто скопируйте и вставьте. если нам нужно, мы можем настроить. например, мы можем изменить адрес мультивещания и номер порта.
|
1
|
<Manager className='org.apache.catalina.ha.session.DeltaManager'/> |
здесь менеджер тега определяет дельта менеджер. Дельта-менеджер означает репликацию на все экземпляры.
|
1
|
<Channel className='org.apache.catalina.tribes.group.GroupChannel'> |
В кластерах Tomcat используется коммуникационная среда Apache Tribes. Эта структура групповой связи отвечает за динамическое членство (с использованием многоадресной рассылки), отправку и получение дельта-информации сеанса с использованием одноадресной передачи (обычное TCP-соединение).
|
1
2
3
4
5
6
7
8
9
|
<Membership className='org.apache.catalina.tribes.membership.McastService'address='228.0.0.4'port='45564'frequency='500'dropTime='3000'/> |
Это определение членства. здесь адрес является адресом многоадресной рассылки. мы можем выбрать любой адрес из диапазона адресов класса D (от 224.0.0.0 до 239.255.255.255) и любой номер порта.
Каждый кот отправляет сигнал сердцебиения на адрес многоадресной рассылки в периодическом ( частотном ) интервале. все другие коты, которые присоединились к многоадресному адресу, могут получать эти сигналы и добавлять членство в кластер. если сигнал теплового удара не возродит какой-то определенный интервал ( dropTime ) от какого-либо из котов, то мы должны учитывать, что кот не справился.
Запись:-
Все экземпляры tomcat, являющиеся частью кластеризации, должны иметь одинаковый адрес многоадресной рассылки и номер порта.
|
1
2
3
4
5
|
<Sender className='org.apache.catalina.tribes.transport.ReplicationTransmitter'><Transport className='org.apache.catalina.tribes.transport.nio.PooledParallelSender'/></Sender> |
В данном случае отправитель использует PooledParallelSender для соединения пулов для одновременной отправки информации о сеансе. так что это ускоряет процесс репликации сеанса.
|
01
02
03
04
05
06
07
08
09
10
11
|
<Receiver className='org.apache.catalina.tribes.transport.nio.NioReceiver'address='auto'port='4000'autoBind='100'selectorTimeout='5000'maxThreads='6'/> |
Здесь мы определяем, какой порт Receiver может связывать и использовать для получения информации о репликации сеанса. здесь важны два свойства. адрес и порт. здесь address — это IP-адрес вашей системы, а port — любой неиспользуемый порт. Здесь address = ‘auto’ автоматически выбирает системный IP-адрес.
У нас есть перехватчик.
TcpFailureDetector -Обеспечивает, что экземпляр мертв. В некоторых случаях многоадресные сообщения задерживаются, все экземпляры tomcat думают, что tomcat мертв. но этот перехватчик, чтобы сделать одноадресную передачу tcp неудачному tomcat и гарантировать, что экземпляры действительно были неудачными или нет
Еще одним важным слушателем является JvmRouteSessionIDBinderListener, о котором мы поговорим позже.
3. Включите веб-приложение как распространяемое
Нам нужно сделать наше веб-приложение распространяемым. это простой тег <распространяемый /> в файле web.xml. В соответствии со спецификацией сервлета тега <distribtable /> в web.xml отметим, что любой контейнер для рассмотрения этого приложения может работать в распределенной среде.
Замечания:
Все сеансы в нашем веб-приложении должны быть сериализуемыми.
Выполните эти шаги для всех экземпляров tomcat и запустите сервер tomcat и httpd. проверьте мою конфигурацию в моем репозитории github или получите как ZIP
Это моя конфигурация. все 3 экземпляра tomcat настроены в delta manager, и я развернул распределенное веб-приложение. все tomcat используют многоадресную рассылку для поддержания членства.
Теперь клиент делает запрос и сначала обрабатывает tomcat и создает сеанс, затем выглядит так
Затем tomcat 1 отвечает за репликацию сеанса с использованием инфраструктуры взаимодействия групп племен Apache для репликации сеанса во все экземпляры.
Теперь все экземпляры tomcat имеют точную копию сеанса. так что если tomcat 1 потерпел крах или завершил работу, любой другой tomcat все еще может обработать запрос [см. видео ниже]
Мы использовали сессионное сходство, как и в предыдущем посте . основанный на том идентификаторе куки содержит имя кота (имя работника). поэтому при первом возвращении tomcat1 идентификатор сеанса заканчивается на tomcat1. но когда tomcat 1 терпит неудачу и tomcat 2 берет на себя ответственность за все дальнейшие запросы. но идентификатор сессии все еще содержит tomcat1. Это затрудняет балансировку нагрузки. потому что tomcat1 не работает. и балансировщик нагрузки выбери любой другой кот. но на самом деле tomcat2 берет на себя ответственность. поэтому мы должны отразить эти изменения в идентификаторе сессии.
JvmRouteSessionIDBinderListener изменяет идентификатор сеанса клиента на tomcat2, когда происходит сбой, поэтому балансировщик нагрузки перенаправляет на tomcat2 без путаницы.
Проверьте git hub на наличие всех файлов конфигурации и доступна настройка кластеризации tomcat. или вы можете скачать как ZIP
Ссылки по теме:
Актерский состав:
http://www.youtube.com/watch?feature=player_embedded&v=cYBdaeNeXbY
Ссылка: Tomcat Clustering Series Часть 3: Репликация сессии от нашего партнера JCG Рамы Кришнана в блоге