Оформление
Конфигурация кластера Порты WebSocket
1. Обзор
1.1 Версия
| Версия сервера BI |
|---|
| 5.1 |
1.2 Сценарии применения
В этой статье описывается настройка портов WebSocket в кластерной среде.
Примечание: Для проектов BI 5.1.20 и более поздних версий добавлена новая схема контейнерных сокетов. Рекомендуется сначала проверить доступность этого решения: Container Websocket Solution
Без каких-либо действий со стороны пользователя, без ручной настройки, без открытия дополнительных портов система может автоматически использовать для подключения WebSocket, поставляемый вместе с веб-контейнером, и мультиплексирование портов http.
2. Примеры
2.1 Модификация значений полей
Супер администратор может изменить порт WebSocket через "fine_conf_entity Visual Configuration Plugin". Настройки вступают в силу после перезапуска сервера.
Примечание: Методы изменения значений полей таблиц базы данных FineDB см. в разделе " Модификации полей общих таблиц FineDB ".
| порты | JAR-пакет | ID | значение по умолчанию | Диапазон настройки | Поддерживается ли онаУстановка нескольких значений |
|---|---|---|---|---|---|
| Порт Websocket | - | WebSocketConfig.port | ["48888", "49888"] | Значением параметра является массив портов ["port1", "port2"].порт находятся в интервале (1024,65535] | адъювант |
| Порт переадресации Websocket | До 2019-11-08 | WebSocketConfig.requestPort | 48889 | адъювант | |
| 2019-11-08 и далее | WebSocketConfig.requestPorts | 48889 | поддерживать что-л. |
При установке номеров портов следует учитывать некоторые моменты:
(1) Номер порта может быть установлен в диапазоне 1024~65535, если он имеет более одного значения, формат установки следующий: [номер порта 1, номер порта 2, номер порта 3].
2) Рекомендуется, чтобы значение параметра "WebSocket Forwarding Port" было больше, чем количество узлов кластера, чтобы гарантировать, что каждый узел выберет доступный в данный момент порт, и сервер не сможет запуститься из-за занятости порта.
3) Рекомендуется установить несколько значений для "Порта WebSocket" в качестве резервной копии, чтобы предотвратить развертывание на сервере нескольких проектов и занятие порта.
4) Не устанавливайте номер порта на порт удаленного подключения к серверу 3389.
5) Если проект и балансировка нагрузки nginx находятся в одной среде, не дублируйте номер порта, который является одновременно портом WebSocket и портом переадресации WebSocket.
6) Если после полей WebSocketConfig.port, WebSocketConfig.requestPort, WebSocketConfig.requestPorts стоит пробел, конфигурация не вступит в силу.
7) Если WebSocketConfig.port, WebSocketConfig.requestPort, WebSocketConfig.requestPorts имеют неправильные размеры, конфигурация не вступит в силу.
8) WebSocketConfig.requestPort и WebSocketConfig.requestPorts не могут существовать в таблице fine_conf_entity одновременно, иначе это будет ошибкой.
2.2 Изменение политики переадресации кластера
Настройте политику переадресации для вебсокетов, чтобы они были "липкими" на уровне балансировки нагрузки, подробнее см. в разделе: Руководство по настройке балансировки нагрузки
2.3 Изменение портов прослушивания кластера
В файле nginx.conf порт прослушивания сервера должен совпадать с конфигурацией "WebSocket Forwarding Port", подробнее см. раздел: Установка и настройка системы Linux для Nginx 4.1.
Например, с помощью команды set Websocket forwarding port (WebSocketConfig.requestPort по умолчанию равен 48889) для переадресации Websocket port (WebSocketConfig.port по умолчанию равен 48888)
В следующем примере IP-адрес сервера проекта 192.168.6.171, а IP-адрес сервера Nginx 192.168.6.181, как показано на следующем рисунке:
#Пользователь или группа пользователей по умолчанию nobody #user root; #Разрешенные процессы, рекомендуется установить количество ядер процессора или автоматическое определение, обратите внимание, что на серверах Windows, хотя вы можете запустить более одного процесса, вы будете использовать только один из них worker_ processes
processes auto; #Автоматическая привязка CPU affinity в зависимости от количества CPU, на nginx1.9.10 и выше можно использовать только #worker_cpu_affinity auto; #Место хранения журнала ошибок error_log &
nbsp;logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #
Место хранения PID #pid logs/nginx.pid; # События режима работы и лимита подключений { #Each
Максимальное количество соединений на рабочий_процесс, на серверах Windows только 1024, независимо от того, насколько большое значение задано здесь # Concurrency - это произведение рабочих_процессов и рабочих_соединений worker_connections
connections worker_connections 1024; } http { # Устанавливаем тип mime, который определяется файлом
mime.type файла include mime.types; # Тип файла по умолчанию.
По умолчанию это text/plain default_type application/octet-stream; # Формат журнала & nbsp; log_format main '$remote_addr - $remote_user [$time_local] "$request
" '  
; '$status $body_bytes_sent "$http_referer" '   ; ' "$http_user_agent"
"$http_x_forwarded_for" $upstream_addr'; #access_log определяет, ведет ли Nginx журналы доступа, установка этого значения на off может уменьшить
дисковый ввод-вывод и увеличить скорость. access_log off; #access_log logs/access.log &
nbsp;main; #директива sendfile определяет, будет ли nginx вызывать функцию sendfile (нулевая копия) для вывода файла. & nbsp; #Для обычных приложений директива sendfile используется для вывода файла.
nbsp; #Для обычных приложений должно быть установлено значение on, #Если используется для загрузки и других приложений с интенсивным дисковым вводом-выводом, может быть установлено значение off, #Для баланса дискового и сетевого ввода-вывода, #Баланс дискового и сетевого ввода-вывода.
сбалансировать скорость обработки дискового и сетевого ввода-вывода и уменьшить время работы системы. sendfile on; &
nbsp;#tcp_nopush on; #http длительное соединение (клиент <-> nginx) таймаут, после завершения запроса соединение сохраняется
keepalive_timeout 65s; #Чем меньше types_hash_max_size, тем меньше памяти потребляется, но частота конфликтов хэш-ключа может увеличиться!
types_hash_max_size 2048; #Включить gzip-сжатие #gzip on
; #gzip_disable "MSIE [1-6].
"; #установить буфер запроса client_header_buffer_size 512k; &
nbsp; large_client_header_buffers 4 512k; #Разрешить пользователю максимальный размер загружаемых данных, настроить ограничение на размер загружаемого файла в соответствии с требованиями бизнеса &
nbsp; client_max_body_size 100M; upstream FR.com { & & nbsp; #max_fails=n fail_timeout=m означает, что n неудачных попыток в течение m таймаутов пометят узел как недоступный в течение следующего m времени (после m таймаутов узел будет повторно помечен как доступный, независимо от того, запущен ли он)
(через m времени узел снова будет помечен как доступный, независимо от того, запущен он или нет) # где fail - "неудачная попытка", неудачная попытка определяется директивой proxy_next_upstream в конфигурации сервера ниже.
Директива upstream в следующей конфигурации сервера server 192.168.6.171:8080 max_fails=15 fail_timeout=
300 с; keepalive 300; #прочее
Описание параметров сервера: #down Помечает сервер как неработающий #
backup Резервный сервер, подключается к серверу только в случае недоступности основного сервера (например, 95 и 96 выше); #weight=number weight, по умолчанию 1 &
nbsp; # Встроенные стратегии балансировки нагрузки: ip-хэш, опрос, взвешенный опрос (задайте значение веса сервера)  
; #ip_hash; #↓==================== активная конфигурация модуля проверки здоровья ====================↓#
## interval: интервал между пакетами проверки здоровья, отправляемыми на бэкенд, в мс. ##
fall(fall_count): если количество последовательных сбоев достигает fall_count, сервер считается отключенным ## rise(rise_count):&
nbsp; Если количество последовательных успехов достигает rise_count, сервер считается поднятым. ## timeout: таймаут для запросов здоровья бэкэнда в мс.
## type: тип пакета проверки здоровья, сейчас поддерживаются tcp, udp, http type
#check interval=2000 rise=5 fall=10 timeout=10000 type=http; &# nbsp;# запрос на проверку, в мс.
nbsp; #check request, prior prior to 7-16 persist version, only use /webroot/decision/system/info HTTP; &
nbsp; #check_http_send "GET /webroot/decision/system/health HTTP/1.0\r\n\r\n"; # check_http_send   ; #check_http_expect_alive http_2xx http_3xx; #Эта директива задает статус успешности HTTP-ответа; по умолчанию состояния 2XX и 3XX считаются здоровыми.
#↑ ==================== Конфигурация модуля активной проверки здоровья ====================↑ # } &
nbsp; upstream WBS.com { server 192.168.6.171
:48888 max_fails=15 fail_timeout=300s; # ip_hash должен быть использован здесь &
nbsp;ip_hash; } server { listen&
nbsp; 8123; имя_сервера 192.168
.6.181; #nginx по умолчанию не пересылает заголовки с подчеркиванием, например, если запрос содержит _device_ в заголовке, заголовок будет отброшен по умолчанию при пересылке на сервер нагрузки & nbsp; #nbsp;Вы можете добавить новый заголовок на http-сервер.
nbsp; # Можно добавить атрибут как в контекст http, так и в контекст http -> server &
nbsp; underscores_in_headers on; #charset koi8-r; &
nbsp; #access_log logs/host.access.log main;  
; #↓==================== активная страница мониторинга модуля healthcheck ====================↓ # #location /.
status { # healthcheck_status html; &
nbsp; #} #↑==================== активная страница мониторинга модуля healthcheck ===========
=========↑# # местоположение, куда по умолчанию перенаправляются запросы под root /, т.е. все запросы с указанием порта перенаправляются на следующий обратный прокси  
; location / { # Для HTTP-прокси директива proxy_http_version должна быть установлена в значение "0". Директива version должна быть установлена в значение "1.1", а заголовок "Connection" должен быть очищен (как в proxy_set_header Connection "").
;"") proxy_http_version 1.1; &
nbsp; # Определяем сервер (группу) для пересылки &
nbsp; proxy_pass http://FR.com; # Устанавливаем переадресацию nginx, когда
Условие переадресации на следующий сервер, здесь задается, что неудачный запрос (40x, 50x и т.д., определяемый proxy_next_upstream) будет передан на следующий шаг для обработки   ; # Неудачные попытки Примечание: 50x и 429 рассматриваются как неудачи в этой конфигурации, ошибка, таймаут и invalid_header считаются неудачами независимо от конфигурации, http_403 и http_404 не являются неудачами с или без конфигурации http_404.
и http_404 не считаются отказами. # error:Ошибки, возникающие при установлении соединения с внутренним сервером, передаче запроса или чтении заголовка запроса & nbsp; # timeout:Таймаут для установления соединения с внутренним сервером, передачи запроса, чтения заголовка запроса, устанавливается в параметрах proxy_next_upstream_.
timeout и proxy_next_upstream_tries (по умолчанию оба значения равны 0) # invalid_
заголовок:Сервер вернул недопустимый или пустой proxy_next_upstream http_500 http_502 http_503 http_504 http_403 http_404 http_429 error timeout invalid_header
non_idempotent; #proxy_next_upstream_timeout 0; &
nbsp; #proxy_next_upstream_tries 0; &
nbsp; #redirect, параметр off отключит все директивы proxy_redirect в этом поле &
nbsp; proxy_redirect off; # некоторые настройки в заголовке запроса.
Синтаксис proxy_set_header [field] [value]; #$host - хост запроса
имя запрашивающего хоста (т.е. прокси-сервера nginx), $server_port - порт хоста (т.е. порт nginx), если есть экстранет-маппинг, то его нужно переписать сюда Адрес экстранета: форма порта экстранета (без протокола) &
nbsp; proxy_set_header Host $host:$server_port; &
nbsp; #Здесь $remote_addr ip-адрес клиента proxy_set_header
set_header X-Real-IP $remote_addr; #здесь $proxy_add_
x_forwarded_for - это уровень прокси, если по многоуровневому прокси, то здесь пишем client, proxy1, proxy2, здесь должен быть client, что ip клиента  
; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
; # Соединение с внутренним сервером поддерживать не нужно proxy_set_header Connection &
quot;"; # NGINX буферизирует ответы от прокси-серверов. Ответ хранится во внутреннем буфере и не отправляется клиенту до тех пор, пока не будет получен весь ответ.
# Буферизация помогает оптимизировать производительность для медленных клиентов, которые тратили бы время прокси-сервера, если бы ответы доставлялись от NGINX к клиенту синхронно.
#Однако, когда буферизация включена, NGINX позволяет прокси-серверу быстро обрабатывать ответы, и NGINX хранит ответы в течение того же времени, которое требуется клиенту для их загрузки.
То же самое #Включить ли кэширование, по умолчанию включено &
nbsp; #proxy_buffering off; #Установите
размер буфера на размер #proxy_buffer_size  
;64k; #Устанавливаем количество и размер буферов на соединение proxy_buffers [number] [
size]; #proxy_buffers 32 64k; #proxy_buffers 32 64k;
nbsp; 32 64k; #Когда включена буферизация ответов, буфер записи достигает определенного размера, когда не все ответы прочитаны.
Когда буфер достигает определенного размера, nginx будет отправлять ответ клиенту до тех пор, пока буфер не станет меньше этого значения #proxy_busy_buffers_
size 64k; #connect to proxy server timeout, default 60s, not more than 75s  
; #Не слишком долго и не слишком коротко, с настройками max_fails и fail_timeout  
nbsp; # Concurrency высокий случай, давление сервера слишком легко таймаута, вы можете рассмотреть max_fails и fail_timeout установить немного больше, чтобы уменьшить ошибку nginx выгнали из узла шансов #.
nbsp; proxy_connect_timeout 75;   ; # Таймаут чтения, по умолчанию 60s, если сервер не возвращает никаких данных в течение периода таймаута, это считается таймаутом. Если нет большого количества данных для расчета или экспорта шаблона, рекомендуется, чтобы конфигурация не превышала 100 с, если есть большое количество данных для расчета или экспорта шаблона, то в соответствии с наиболее длительным временем шаблона, чтобы настроить.
proxy_read_timeout &
nbsp;400; # Таймаут записи, по умолчанию 60s, если сервер не получает данные в течение периода таймаута, это означает таймаут, считается таймаутом. Если нет большого количества данных для расчета или экспорта шаблона, рекомендуется настраивать не более 100 с, если есть большой объем данных для расчета или экспорта шаблона, то настраивается исходя из самого длительного времени шаблона.
proxy_send_timeout &
nbsp;400; } #define 404 page & nbsp; #error_page 404 &
nbsp; /404.md; # перенаправляет страницы ошибок сервера
на статическую страницу /50x.md #define page 50x &
nbsp; error_page 500 502 503 504 /50x.md; &
nbsp; location = /50x.md { & nbsp; root html; }
nbsp; root html; } }
server { # здесь указывается порт websocket, если это кластерное развертывание, то для проекта FineReport - 38889, для проекта FineBI - 48889
listen 48889; &
nbsp; имя_сервера 192.168.6.181;
location / { proxy_http_version
1.1; proxy_pass http://WBS.com;  
nbsp; proxy_connect_timeout 75; proxy_read_timeout 75;  
nbsp; proxy_read_timeout 400;  
nbsp; proxy_send_timeout 400; &
nbsp; # целью обновления для значения $http_upgrade на самом деле является websocket &
nbsp; proxy_set_header Upgrade $http_upgrade; &
nbsp; #Соединение настроено на обновление proxy_set_header Connection "upgrade"; &
nbsp; } }2.4 Открытые порты
- Закройте брандмауэр, если он включен, или откройте порт отдельно.
- Если на облачном сервере есть группа безопасности или что-то подобное, вам нужно установить порт, чтобы он был открыт для внешнего мира.
2.5 Возобновление работ
Перезапустите проекты nginx и FineBI.
При перезапуске проекта необходимо убить процессы, запущенные в проекте, и подождать 2 минуты, пока порт не будет освобожден, иначе перезапуск может закончиться неудачей.
2.6 Предварительный просмотр эффектов
Следуйте порядку пересылки WebSocket port >> WebSocket port, т.е. если вы используете порт по умолчанию, попробуйте слушать в порядке "48889, 48888, 49888".
- Если один порт успешно прослушивается, другие порты не пытаются это сделать.
- Если все порты не могут установить прослушивание с сервером системы, откроется страница Deployment Wizard, на которой вам будет предложено изменить список прослушиваемых портов, что повлияет на работу соответствующих функций.
