동적 라우팅의 라우팅 규칙 기능을 사용하여 요청 정보를 기반으로 특수 라우팅 작동에 대한 요청을 선택할 수 있습니다.
시작하기 전에
집합체 제어기에서 동적 라우팅을 사용으로 설정하십시오. Liberty 집합체의 동적 라우팅 설정의 단계를 완료하십시오.
팁: 라우팅 규칙을 사용하여 여러 집합체로 라우팅하려면 각각의 집합체가 서로 다른 이름을 가져야 합니다.
집합체의 이름을 지정하려면
collective create 명령을 실행할 때
--collectiveName 옵션을 사용하십시오.
집합체가 이미 작성된 경우에는
<dynamicRouting> XML 요소의
connectorClusterName 특성으로 집합체의 논리 이름을 제공할 수 있습니다.
connectorClusterName 특성이 지정된 경우,
값은
--collectiveName 옵션으로 지정된
collectiveName에 우선합니다.
다중 Liberty 집합체의 동적 라우팅 설정의 내용을 참조하십시오.
이 태스크 정보
기본적으로, 동적 라우팅은 요청을 처리할 수 있는 모든 서버 간에 요청 로드를 밸런싱합니다.
라우팅 규칙이 요청을 특정 서버 자원으로 라우팅하고 요청을 경로 재지정하거나 요청을 거부할 수 있도록,
기본 작동을 대체하는 라우팅 규칙을 구성하십시오.
참고: 집합체의 모든 집합체 제어기는 동적 라우팅 서비스를 통해 동일한 라우팅 규칙 세트를 제공해야 합니다.
모든 제어기가 동일한 라우팅 규칙을 사용할 수 있도록, 라우팅 규칙이 포함된
.xml 파일을
제어기 중 하나의
configDropins/defaults 디렉토리에 추가하십시오. 추가 정보는
복제본 사이에서 자동으로 구성 공유의 내용을 참조하십시오.
프로시저
- 제어기 server.xml 파일에서
<dynamicRouting> 요소의 하위로서 <routingRules> 요소를 추가하십시오.
<routingRules> 요소의 webServers 속성을 지정하십시오.
각각의 <routingRules> 요소는 규칙이 공개되는 적용 가능한 웹 서버 세트를 정의할 수 있습니다.
웹 서버가 DynamicRouting 서비스에 연결되는 경우, 서비스는 규칙을 해당 웹 서버에 전달합니다.
웹 서버가 지정되지 않은 경우, 서비스는 규칙을 연결된 모든 웹 서버에 전달합니다.
둘 이상의 웹 서버를 지정하는 경우에는 구분 기호로서 쉼표(,)를 사용하십시오.
*의 webServers 속성 값으로 지정된 모든 규칙이 모든 웹 서버에 전달됩니다. 다음 예를 참조하십시오.
<dynamicRouting>
<routingRules webServers="webserver1,webserver2">
...
</routingRules>
</dynamicRouting>
<routingRules> 요소의
overrideAffinity 속성을 지정하십시오.
요청이 선호도 서버가 대상으로서 포함되지 않은 라우팅 규칙과 일치하는 경우에도,
기본적으로는 특정 서버에 대한 선호도가 있는 요청이 해당 서버에 전송됩니다.
overrideAffinity 특성이
true로 설정된 경우에는
일치된 규칙에 있는 대상 선택이 선호도 서버 선택에 우선합니다. 선호도 서버가 일치된 규칙을 충족하는 경우에는
선호도 서버가 엔드포인트의 장애 복구 세트에 있어도 선호도 서버가 선택됩니다.
overrideAffinity 특성은 모든 라우팅 규칙에 적용되며, 개별 규칙에는 설정될 수 없습니다.
<dynamicRouting>
<routingRules webServers="webserver1"
overrideAffinity=”true”>
...
</routingRules>
</dynamicRouting>
- <routingRules> 요소의 하위로서 <routingRule> 요소를 추가하십시오.
- 라우팅 규칙에 대해 order 속성을 지정하고 이를 정수로 설정하십시오.
order 속성은 필수입니다. 규칙은 최하위 순서에서 최상위 순서로 평가됩니다.
둘 이상의 규칙이 동일한 order 속성에 지정된 경우에는
발견된 첫 번째 규칙이 공개되며 동일한 순서 속성의 기타 모든 규칙은 버려집니다.
규칙의 순서 번호 간에 갭을 두어서 향후 규칙을 위한 공간을 마련하도록 권장합니다.
- 라우팅 규칙에 대해 matchExpression 속성을 지정하십시오.
일치하는 수신 요청을 찾을 수 있는 표현식으로 이를 설정하십시오. 일치 표현식은 고정된 피연산자 세트를 연산자와 결합합니다.
AND 및 OR 연산자를 사용하여 피연산자 세트 및 연산자를 결합할 수 있습니다.
<dynamicRouting>
<routingRules webServers="webserver1,webserver2">
<routingRule order="100" matchExpression="URI LIKE'/myapp%'">
...
</routingRule>
</routingRules>
</dynamicRouting>
표 1. matchExpression 피연산자. matchExpression 정의에 피연산자를 포함합니다. 피연산자 |
구문 |
설명 |
클라이언트 IPV4 |
clientipv4 |
n.n.n.n의 IPv4(Internet Protocol 버전 4) 점분리 4개 주소 유형을 사용하는 클라이언트의 IP 주소입니다. |
클라이언트 IPV6 |
clientipv6 |
클라이언트 컴퓨터의 RFC 1924(Request for Comments 1924)를 따르는
x:x:x:x:x:x:x:x의 IPv6(Internet Protocol 버전 6) 128비트 주소 유형입니다. |
쿠키 이름 |
cookie$name |
쿠키 이름. 예를 들어, 표현식 cookie$My_Cookie_Name='My_Cookie_Value'는
My_Cookie_Value 값으로 이름 지정된 My_Cookie_Name인 쿠키를 포함하는지
여부를 파악하는 요청을 테스트합니다. 특정 쿠키의 존재 여부를 테스트하려면 다음 표현식 중 하나를
사용하십시오.
cookie$MyCookieName IS NOT NULL
cookie$MyCookieName IS NULL
|
헤더 이름 |
header$name |
헤더 이름 및 값. 예를 들어, 표현식 header$Host='localhost'는
locahost 값의 HTTP 호스트 헤더를 포함하는지 여부를 파악하는 요청을 테스트합니다. 호스트 헤더의 존재 여부를 테스트하려면 다음 표현식 중 하나를 사용하십시오.
header$Host IS NOT NULL
header$Host IS NULL
|
백분율 |
percentage$val |
백분율 피연산자는 시간의 일부 백분율을 true로 평가합니다. 예를 들어, percentage$50은 시간의 평균 50%에 대해 true를 평가합니다.
|
조회 매개변수 |
queryparm$name |
조회 매개변수 이름 및 값입니다. 예를 들어, 표현식 queryparm$timezone='EST'는
EST 값으로 이름 지정된 timezone인 HTTP 조회 매개변수를 요청이 포함하는지 파악하는 요청을 테스트합니다.
조회 매개변수의 존재 여부를 테스트하려면 다음 양식 중 하나를 사용하십시오.
queryparm$timezone IS NOT NULL
queryparm$timezone IS NULL
|
URI |
uri |
URI(Uniform Resource Identifier) |
가상 호스트 |
virtualhost |
요청의 가상 호스트 대상 |
가상 포트 |
numeric |
요청의 가상 포트 대상 |
표 2. matchExpression 연산자. 필요에 따라 matchExpression 정의에 연산자를 포함합니다. 연산자 |
구문 |
설명 |
같음 |
= |
같음 연산자는 대소문자 구분 일치를 표현합니다. |
같음(대소문자 구분 안 함) |
EQUALSIGNORECASE |
문자열의 대소문자가 무시되는 것을 제외하면 'String = String'과 같습니다.
예를 들어, 'ABC' EQUALSIGNORECASE 'abc'는 true로 평가되며
('ABC' = 'abc')는 false로 평가됩니다. |
IN |
IN |
단일 표현식에 다중 값이 있는 피연산자를 표현합니다. 예를 들어, port라고 하는
피연산자에 대해 port 값이 임의의 또는 모든 9080, 9090 및 9091 정수일 수 있음을
표시하려면 표현식 단편은 port IN (9080,9090,9091)입니다. 소괄호 내의 값이 표시되는 방법은 데이터 유형에 따라 다릅니다.
예를 들어, port가 정수인 경우에 올바른 구문은 따옴표 없는 값입니다.
port가 문자열인 경우, 올바른 구문은 port IN
('9080','9090','9091')입니다.
|
null이 아님 |
IS NOT NULL |
지정된 피연산자가 존재하면 true로 평가됩니다. |
null임 |
IS NULL |
지정된 피연산자가 존재하지 않으면 true로 평가됩니다. |
유사 |
LIKE |
문자열 피연산자 값에 대한 패턴 일치를 표현합니다.
값에는 패턴 일치가 시작하는 위치에 와일드카드 문자 백분율 부호(%)가 포함되어야 합니다. 예:
- host LIKE %blanca 표현식은 blanca 단어나 blanca로 끝나는 다른 단어와 일치됩니다.
- host LIKE blanca% 표현식은 blanca 단어나 blanca로 시작되는 다른 단어와 일치됩니다.
- host LIKE %blanca% 표현식은 blanca 단어나 blanca가 포함된 단어와 일치됩니다.
|
유사(대소문자 구분 안 함) |
LIKEIGNORECASE |
문자열의 대소문자가 무시되는 것을 제외하면 'string LIKE string'과 같습니다. |
LIKE IN |
LIKEIN |
문자열이 문자열 목록에 존재하는지 여부를 평가합니다. 예를 들어, string likein
(string1%, string2%, string3%, etc.)는 string이
소괄호의 문자열 중 하나 이상과 일치하는 경우에 true로 평가됩니다.
이 예제에서 소괄호에는 3개의 string 값이 포함되어 있습니다. |
- 라우팅 규칙의 조치 유형을 지정하십시오.
세 개의 가능한 조치 유형은 permitAction,
redirectAction 또는 rejectAction입니다. 각각의 라우팅 규칙에 대해 세 조치 유형 중 하나만 지정하십시오.
- 요청을 식별된 엔드포인트로 라우팅하려면 permitAction 조치를 지정하십시오.
- <permitAction> 요소를 <routingRule> 요소에 추가하십시오.
- 선택사항으로,, allowMaintenanceModeServers 속성을
<permitAction> 요소에 추가하여 규칙과 일치하는 요청이
유지보수 모드의 서버로 전송되는지 여부를 지정하십시오. 이 속성의 기본값은 false입니다.
이 속성이 true로 설정된 경우에는 이 규칙과 일치하는 요청이 유지보수 모드인 서버로 전송될 수 있습니다.
- <permitAction> 요소에 하나 이상의 <loadBalanceEndPoints> 요소를 추가하십시오.
<permitAction> 요소에 둘 이상의 <loadBalanceEndPoints> 요소가 있는 경우,
첫 번째 <loadBalanceEndPoints> 요소는 기본 대상 세트로서 작동합니다.
모든 후속 <loadBalanceEndPoints> 요소는 장애 복구 대상으로서 작동합니다.
<loadBalanceEndPoints> 요소가 정의되는 순서는 장애 복구 우선순위를 결정합니다.
- 각 <loadBalanceEndPoints> 요소에 하나 이상의 <endpoint> 요소를 추가하십시오.
- 각 <endpoint> 요소에 destination 속성을 추가하십시오.
destination 속성을 서버 유형 또는 클러스터 유형으로 설정하십시오.
서버 유형 엔드포인트를 지정하려면, server= 및 각 파트가 쉼표로 구분된
네 파트의 서버 스펙을 차례로 지정하십시오.
<endpoint destination="server=collective_name,host_name,wlp.user.dir,server_name"/>
- collective_name은 서버가 멤버인 집합체의 이름입니다.
- host_name은 호스트 주소입니다.
- wlp.user.dir은 서버가 정의된 호스트 시스템의 Liberty 사용자 디렉토리입니다.
여기서 ${wlp.user.dir} 변수를 사용할 수 있지만, 이는 적합하지 않을 수 있습니다.
이 server.xml이 평가되는 경우, ${wlp.user.dir}의 값은 제어기 서버가 정의된 디렉토리입니다.
이는 멤버 서버가 정의된 동일한 디렉토리가 아닐 수 있습니다.
- server_name은 서버 이름입니다.
클러스터 유형 엔드포인트를 지정하려면
cluster=과 각 파트가 쉼표로 구분된 두 파트로 된 서버 스펙을 차례로
지정하십시오.
<endpoint destination="cluster=collective_name,cluster_name"/>
- collective_name은 클러스터가 정의된 집합체의 이름입니다.
- cluster_name은 클러스터 이름입니다.
서버 또는 클러스터 대상 스펙의 모든 파트는 문자열 일치를 위해 와일드카드 문자(*)를 사용할 수 있습니다.
라우팅 규칙을 사용하여 여러 집합체로 라우팅하려면 각각의 집합체가 서로 다른 이름을 가져야 합니다.
<dynamicRouting> 요소의 connectorClusterName 속성이 지정된 경우,
집합체 이름은 connectorClusterName 속성의 값입니다.
<dynamicRouting>의 connectorClusterName 속성이 지정되지 않은 경우,
집합체 이름은 collective create 명령을 실행할 때 --collectiveName 옵션에 사용된 값입니다.
connectorClusterName 속성이 지정되지 않았으며
--collectiveName 옵션이 사용되지 않은 경우, 집합체 이름은 defaultCollective입니다.
다음 예제는 서버 유형 엔드포인트의 <permitAction> 요소를 보여줍니다.
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,myhost,/opt/IBM/liberty/wlp/usr,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
</routingRules>
</dynamicRouting>
- 요청을 다른 위치로 라우팅하도록 redirectAction 조치 유형을 지정하십시오.
- <redirectAction> 요소를 <routingRule> 요소에 추가하십시오.
- location 속성을 <redirectAction> 요소에 추가하십시오.
location 속성을 요청의 새 대상으로 설정하십시오.
다음 예제는 <redirectAction> 요소를 보여줍니다.
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="200" matchExpression="URI LIKE '/myapp%'">
<redirectAction location="http://some.other.destination" />
</routingRule>
</routingRules>
</dynamicRouting>
- 특정 응답 코드로 요청을 거부하도록 rejectAction 조치 유형을 지정하십시오.
- <rejectAction> 요소를 <routingRule> 요소에 추가하십시오.
- code 속성을 <rejectAction> 요소에 추가하십시오.
code 속성을 요청이 규칙과 일치할 때 사용할 HTTP 응답 코드로 설정하십시오.
코드는 웹 서버가 지원하는 오류 코드여야 합니다.
다음 예제는 <rejectAction> 요소를 보여줍니다.
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="300" matchExpression="URI LIKE '/myapp%'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
결과
규칙이 정의된 후에는 웹 서버가 동적 라우팅 서비스에 연결할 때
해당 웹 서버와 연관된 규칙과 모든 웹 서버와 연관된 규칙이 전달됩니다. 웹
서버는 규칙에서 발견된 일치 표현식에 대해 요청을 일치시킵니다. 표현식은
규칙 순서에 따라 최하위 순서에서 최상위 순서로 평가됩니다. 일치하는
표현식의 첫 번째 규칙이 사용됩니다. 규칙과 연관된 조치는 요청이 처리되는 방법을 판별합니다.
일치하는 규칙이 없는 경우, 해당 요청을 처리할 수 있는 모든 서버 간에 요청의 로드가 밸런싱됩니다.
기본적으로, 요청에 세션 선호도가 있을 때는 선호도를 기반으로 서버가 선택됩니다.
선호도 서버를 찾으면 해당 서버가 선택되며 라우팅 규칙이 평가되지 않습니다.
라우팅 규칙을 사용하여 선호도 선택사항을 대체할 수 있도록 overrideAffinity 속성이
server.xml 파일의 <routingRules> 요소에 추가될 수 있습니다.
예
다음 예제는 여러 규칙을 결합합니다.
<dynamicRouting>
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,*,*,member1"/>
</loadBalanceEndPoints>
<loadBalanceEndPoints>
<endpoint destination="server=collective2,*,*,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="200" matchExpression="uri like '/AppX%' AND queryparm$test = 'true'">
<permitAction allowMaintenanceModeServers="true">
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterB"/>
<endpoint destination="cluster=collective2,clusterB"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="300" matchExpression=" uri like '/AppX%' ">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterA"/>
<endpoint destination="cluster=collective2,clusterA"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="400" matchExpression="URI LIKE '/myoldapp'">
<redirectAction location="http://mysite/mynewapp" />
</routingRule>
<routingRule order="500" matchExpression="URI LIKE '/myveryoldapp'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
-order 100의 라우팅 규칙은
/AppX에 대한 요청이 두 개의 집합체 간에 두 개의 특정 클러스터로 라우팅되는 대상을 제한합니다.
–order 200의 라우팅 규칙은
하나의 엔드포인트 세트에서 다른 엔드포인트 세트로 장애 복구를 사용하는 방법을 표시합니다.
규칙 200은 표현식과 일치하는 모든 요청을 collective1의 요청을 처리할 수 있는 서버로 라우팅합니다.
collective1의 요청을 처리할 수 있는 모든 서버를 사용할 수 없는 경우에는
collective2의 요청을 처리할 수 있는 서버가 규칙 표현식과 일치하는 요청을 위해 선택됩니다.
–order 300의 라우팅 규칙은 유지보수 모드인 서버로 테스트 요청을 라우팅하는 예제를 표시합니다.
test=true가 조회 매개변수로서 추가되는 경우, 해당 서버가 유지보수 모드인 경우에도
해당 요청이 collective1의 server1로 전송됩니다.
–order 400의 라우팅 규칙은 경로 재지정 규칙의 예제를 표시합니다.
–order 500의 라우팅 규칙은 거부 규칙의 예제를 표시합니다.