이 문제는 RadWare AppDirector를 사용하거나 아래 설명에서 훌륭한 발견에 따라 Apache mod_security를 사용하여 (완전하게) 해결할 수 있습니다.
AppDirector 솔루션의 경우 동일한 백엔드 서버에 두 개의 팜을 매핑하는 것이 가능하다고 생각합니다. 이 팜에는 서로 다른 기준과 운영 조건이 적용될 수 있습니다. 한 팜은 "기본"이고 다른 팜은 "세션"으로 정의한 URI :에 응답합니다. 후자는로드 밸런서에서 허용하는 세션 수에 제한을받습니다.
지금부터 두 가지 이유로 "로그인"이라는 "세션"용어를 대신 사용하려고합니다.
- 사용자가 인증되는 원하는 상태를 명확하게 정의하므로 모호성을 피합니다.
- AppDirector 사용 설명서와 GUI는 "연결"이라는 용어를 재정 의하여 "세션"과 동일한 모든 실제적인 목적에 대한 의미를 갖습니다 (아래 참조). 이것은 우리가 피하려고하는 혼란을 더합니다.
"로그인 된"팜이 선택한 연결 제한에 도달 한 경우 죄송한 페이지를 표시 할 수도 있습니다.
방법에 도달하기 전에 AppDirector 제품에 대한 운영 경험이 없다고 명확하게 진술해야하지만 경쟁적이고 약간 덜 진보 된로드 밸런서를 매일 관리해야합니다. 내가 사용하는 제품은 바로이 시나리오를 수행 할 수 있습니다. AppDirector 사용 설명서와 사용 가능한 온라인 설명서 중 AppDirector에 해당하는 정보를 찾았습니다. 그러나 개념은 비슷하지만 용어가 다릅니다. 나는 단순히 어리 석음이없는 모론이되지 않으면서도 옳은 일을하기를 바라면서 말로 표현할 때 로마에서 행동을하고 있습니다.
가장 큰 장애물은 매뉴얼에 대한 액세스 권한을 얻는 것이 었습니다. 인터넷 검색을 통해 구식 버전이 너무 오래되지 않았기 때문에 몇 가지 기술 자료 기사 와이 링크를 찾았습니다. Radware AppDirector – 구성 : 기본 응용 프로그램 .
다음은 주로 사용자 안내서를 통해 해석 된 솔루션 초안입니다.
로드 밸런서에 대한 클라이언트 항목은 "기본"세션과 "로그인 된 세션"을 모두 연결하는 데 사용되는 VIP를 통해 수행됩니다. 이는 사용 설명서의 p.99에 따라 L4 정책을 통해 달성됩니다.
"When AppDirector receives the first packet of a session destined to a
Virtual IP address, it searches for a Layer 4 Policy that matches the
Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this
information, AppDirector selects the farm allocated to this service and
the best server for the task from that farm, and forwards the packet to
that server.
L4 정책은 적합한 팜을 선택하는 데 사용되는 L7 정책과 연결될 수 있습니다. L7 정책 프로세스는 사용자 안내서 p.104에 설명되어 있습니다.
"The Layer 7 content aware decision making mechanism allows you to have
a single point of entry to the site, and provides differentiated service
for different user groups.
A Layer 7 decision is made using a mechanism called Delayed Binding.
When Delayed Binding is used, AppDirector first performs a TCP handshake
with the client to receive the HTTP request. AppDirector parses the HTTP
request’s data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server.
Lastly, AppDirector initiates a TCP handshake with the server and
forwards the traffic to it
[...]
When Layer 7 Policies are used, farm selection is based on matching the
request data with a list of Layer 7 Policies defining the Layer 7
parameters differentiating the service. The process of server selection
within the farm can also be content-based, using a third Layer 7
parameter."
L7 동작을 정의하는 데 사용할 수있는 방법은 106 페이지에 설명되어 있습니다.이 중 "기본"팜이 아닌 "로그인 된"팜으로 라우팅을 선택할 수있는 적절한 방법을 선택할 수 있습니다.
"Methods are the basic building blocks for Layer 7 service selection.
They define content by which traffic is differentiated. You can use
the same Method to select one or more services. The following Method
Types are available:
- URL: Looks for a specified host name and/or path in the HTTP request.
- File Type: Looks for a specified File Type in the HTTP request.
- Header Field: Looks for a specified Header Field in the HTTP request.
- Cookie: Looks for a specified Cookie in the HTTP request.
- Regular Expression: Looks for a regular expression anywhere in the
HTTP request. AppDirector supports Posix 1002.3 regular expressions;
the string can be up to 80 characters.
- Text: Looks for a text string anywhere in the HTTP request."
기본 애플리케이션 링크 에서 볼 수 있듯이 다른 팜으로 라우팅하기위한 URI 패턴을 평가하는 L7 정책을 만들 수 있습니다. 구성된 URI 패턴 '^ / login? = true'및 '^ / loggedin'은 "로그인 된"팜으로 라우팅 될 수 있습니다. 구성 패턴 '^ / logout'(및 기타 모든 URI :)도 마찬가지로 "기본"팜으로 라우팅 될 수 있습니다.
팜은 사용자 안내서 p.121에 정의되어 있습니다. "AppDirector 팜은 동일한 서비스를 제공하는 네트워크 서버 그룹입니다. [...] 여러 서비스를 제공하는 서버를 여러 팜에서 사용할 수 있습니다."
서버는 백엔드 서버의 정의를 서버의 IP 주소를 나타내는 '물리 서버'객체 계층과 하나 이상의 물리적 서버에서 실행되는 서비스를 나타내는 '팜 서버'객체 계층으로 분리함으로써 더욱 차별화됩니다. .
팜에 대한 세션 제한은 'AppDirector 사용 설명서'에 따라 물리적 서버 개체 외에 팜에 대해 정의 된 각 팜 서버 개체 (및 다른 방법을 통해)에 따라 수행 될 수 있습니다. 이것은 p.137의 다른 곳에서 설명됩니다 :
"The Connection Limit is the maximum number of users that can be directed
to a server for a service provided by the farm. The number of users allowed
depends on the Sessions mode selected because it determines the number of
active entries in the Client Table for sessions destined to the specific server.
When the Entry Per Session or Server Per Session modes are selected, the number
of active entries destined to the same server is higher than in the Regular
mode (see Regular, page 153).
When the Regular mode is selected, all requests from a single client IP destined
to the same server are reflected by a single entry in the Client Table (see
Client Table Views, page 164).
The default value for the Connection Limit parameter is 0. When it is configured
to 0, it is disabled for this server and there is no user number limit."
클라이언트 테이블 및 해당 '일반 모드'는 153 페이지에 정의되어 있습니다.
"The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency.
This table contains information about the server selected for each client
(Source IP address) in each farm, and it allows AppDirector to select a
server for a new session.
[...]
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode,
each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server"
기본 응용 프로그램 페이지 의 서버 정의 창의 스크린 샷 에서 서버 연결 제한 상자는 bandwith limit 상자 옆에 표시됩니다.
따라서 구성에 따라 다르지만이 답변의 목적을 위해 클라이언트 테이블을 통해 정의 된 '연결'과 사용자가 정의 한 '세션'은 본질적으로 동일한 것입니다. 팜의 서버 개체마다 해당 효과에 대한 제한이 적용될 수 있습니다.
AppDirector는 물리적 서버와 팜 서버를 구분하므로 Apache 물리적 서버 개체에 매핑되는 두 개의 팜 서버를 정의 할 수 있습니다. 하나는 연결 제한이 낮습니다.
그러나 Apache는 두 팜 서버 객체 (예 : 각 팜 / 팜 서버) 콤보에서 사용되는 두 개의 개별 포트 또는 IP 주소에서 호출되는 방식으로 두 팜 서버 객체 모두의 호출에 응답해야합니다. 그러면 두 응용 프로그램 서버 진입 점을 정의 할 수 있습니까? 즉, 두 개의 포트 또는 IP 주소 (팜당 하나)에 응답하기 위해 Apache 프론트 엔드 응용 프로그램 (/ vhost?)을 장비 할 수 있습니까? 매뉴얼에 너무 많은 시간을 보내고 싶지 않기 때문에 약간의 추측 작업이 필요하지만 실제로 AppDirector GUI와 Apache를 볼 때 상당히 우아하게 해결할 수 있다고 확신합니다.
연결 제한을 설정하는 데 약간의 문제가 있습니다. 물리적 서버에서 연결 제한 p.140 :
"Connection Limit
Maximum number of Client Table entries that can run simultaneously on
the physical server. This depends on the farm’s Sessions mode (see
Sessions Modes, page 150). When the limit is reached, new requests are
no longer directed to this server. All open sessions are continued.
When the Connection Limit parameter is configured to 0 (default), this
mechanism is disabled for this physical server and there is no user
number limit.
Note: When configuring the physical server, ensure that the Connection
Limit in the farm servers with the same Server Name is lower than or
equal to the Connection Limit in the physical server. Total number of
active sessions that run simultaneously on the farm servers must not
be higher than the Connection Limit value defined on the physical server."
따라서 제한되지 않은 "기본"팜 서버에 대해 매우 높은 연결 제한 (사용자 기반을 통해 가능한 최대 수의 여백으로)을 정의하고 "로그인 된"팜 서버에 대한 연결 제한을 다음과 같이 설정해야합니다. 당신이해야 할만 큼 낮습니다. 물리적 서버 정의는 원하는 세션 제한을 활성화하기위한 전제 조건으로 연결 제한으로 2의 합계를 가져야합니다.
귀하의 질문에 다음 요구 사항이 있습니다.
After the specified session limit has been reached, the next user should be
directed to a custom error page.
이것은 사용 설명서, p.134에서 'HTTP 서비스 페이지 없음'이라고합니다.
When all servers belonging to a farm cannot be used for a specific
session, AppDirector can reply to a Web request (destined to port 80)
with a simple Web page, indicating that the service is currently not
available. Servers that cannot be used for a session include servers
in Not In Service or in No New Sessions mode. No HTTP Service Page is
configured for each farm. Each Web page is limited to 1K of HTML code.
모니터링 부분에 대해 나는 철저한 연구를하지 않았지만 여기에 내가 생각하는 것이 있습니다.
track the current number of sessions for monitoring purposes
AppDirector에 MIB가있는 것 같습니다. 아마도 올바른 OID를 찾는 데 어려움이 있을지 모르지만 아마도 선택한 도구로 숨길 수 있습니다.
whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.
이것은 창의적인 사고가 필요할 수 있습니다. AppDirector에 바로 사용할 수있는 템플릿이 포함되어 있지 않다고 가정하면 어떻습니까?
- "로그인 된"팜 외부의 URI는 세션 제한의 영향을받지 않습니다. 어쨌든 동일한 백엔드 서버입니다.
- 대신 AppDirector 상태 확인을 사용하면 부과 한 세션 제한에 포함되지 않습니다. 모니터링 서버에 경고를 전달하는 방법을 찾으십시오 :-)
- 상태 확인을 통과하는 세 번째 팜을 설정하십시오. 지저분하지만 작동합니다.