편집자 주: 이 주제에 대해 많이 알고 있습니까? 전문 지식을 공유하길 원합니까? IBM Lotus 소프트웨어 wiki 프로그램에 지금 참여하십시오.
| Lotus iNotes wiki |
|---|
메일은 중요한 기업 애플리케이션이며 사용자와 관리자는 1년 365일 언제라도 메일을 사용할 수 있을 것으로 기대한다. IBM Lotus Notes®와 Lotus Domino를 사용하면 Lotus Domino 클러스터링 및 메일 파일 복제본을 활용하여 고가용성을 얻을 수 있다. Lotus Notes 클라이언트에는 통신 중이던 Lotus Domino 서버가 중단된 시나리오에 대처하기 위한 명시적인 코드가 있다.
약간의 지연 후(시도된 연결 또는 통신이 완료될 때까지 기다리기 때문) Lotus Notes 클라이언트는 사용자에게 서버가 더 이상 사용할 수 없게 되었음을 알린 후 알려져 있는 다른 복제본 서버로 전환할지 묻는다.
하지만 Lotus iNotes를 사용하여 고가용성을 얻기 위해서는 ADC(Application Delivery Controller)와 같은 추가 인프라의 도움이 필요하다. ADC는 데이터 센터에서 다음을 비롯한 수많은 장점을 제공한다.
- 애플리케이션 신뢰성 향상(애플리케이션 모니터링 및 로드 밸런싱을 통해)
- 보안(애플리케이션 방화벽) 및 가속 기능(TCP 및 HTTP 최적화) 강화
- 많은 계산이 필요한 태스크 중 일부 태스크의 로드를 여러 서버로 분산(예: SSL(Secure Sockets Layer) 암호화)
Lotus Domino에는 애플리케이션의 초기 URL을 여러 백엔드 메일 서버 중 하나로 리디렉트할 수 있는 Internet Cluster Manager라는 기술이 있다. 하지만 세션이 시작된 후 실제 메일 서버가 사용할 수 없게 되면 메일 파일의 복제본이 있는 다른 가용 서버로 복원 및 전환할 수 있는 메커니즘이 없다.
올바르게 구성된 경우 로드 밸런서는 끊김 없는 장애 복구 기능을 제공할 수 있다. 사용자가 통신 중이었던 원래 서버가 더 이상 사용할 수 없게 되었다는 것을 모르는 상태에서 로드 밸런서가 이 상황을 감지하여 다른 적절한 서버에게 요청을 보낸다.
이 기능을 제공하는 소프트웨어 기반 로드 밸런서와 특화된 하드웨어(예: ADC)가 있다. 하드웨어의 경우에는 일반적으로 약간 비싸기는 하지만 성능이 좋고 뛰어난 기능을 제공하는 동시에 백엔드 서버 자원에 대한 절약 효과가 높다.
이 기사에서는 Lotus iNotes의 로드를 적절하게 분산시키는 작업과 관련된 몇 가지 과제를 설명하고 우수한 F5 Networks BIG-IP LTM(Local Traffic Manager) Advanced ADC를 활용한 예를 살펴본다.
또한 대부분의 Lotus iNotes 메일 전개를 지원하는 범용 BIG-IP LTM 구성을 작성하는 과정을 설명한 다음 BIG-IP LTM을 사용하여 실현할 수 있는 Lotus Domino 서버 및 사용자 성능에 대해서도 살펴본다.
Lotus Domino 메일 파일에는 일반적으로 서브디렉토리(예: mail)와 파일
이름(예: juser.nsf)이 있다. 로드 밸런싱을 위해 메일 파일의 경로는
복제본이 있는 각 서버 내에서 동일해야 하며 로드 밸런서에 도달한 메일 파일의 전체 경로는 모호하지
않고 고유해야 한다.
이제 고가용성을 위해 사용할 수 있는 몇 가지 구성 시나리오를 살펴보자.
이 첫 번째 구성 시나리오는 가장 단순하다. 완전히 미러링 및 클러스터링된 서버 세트이며 모든 메일 파일이 이 하나의 클러스터에 있다. 두세 개의 서버가 동일한 디렉토리 구조와 메일 파일 세트를 가지고 있으며 이러한 서버 사이에서 클러스터 복제가 사용된다(그림 1 참조).
그림 1. 클러스터 A에 있는 두 개의 미러링된 서버
이 시나리오의 경우에는 로드 밸런서에서 Lotus iNotes 관련 요청을 클러스터에 있는 모든 서버에 전달할 수 있다.
조금 더 복잡한 두 번째 구성에서는 구성 1과 유사한 여러 개의 Lotus Domino 메일 클러스터가 있고 로드 밸런서가 수신된 요청을 동일한 클러스터에 있는 적합한 백엔드 서버 세트로 보내야 한다.
이 구성은 여러 가지 방법으로 수행할 수 있다.
- 첫 번째 방법의 경우에는 각 클러스터에서 메일 파일이 저장되어 있는 고유한 이름의 서브디렉토리를
사용한다. 이는 일반적인 URL에 클러스터를 명확하게 식별하는 세그먼트가 포함되어 있음을 뜻한다(그림 2
참조). 그런 다음 로드 밸런서의 규칙이 이러한 이름에 맞춰 적절한 백엔드 서버에 연관시킬 수 있도록
업데이트된다.
그림 2. 클러스터별로 고유 서브디렉토리가 있는 두 개의 클러스터에 있는 두 개의 서버
하드코딩된 고유 클러스터 서브디렉토리 이름 및 백엔드 Lotus Domino 서버 목록은 지속적으로 업데이트되면서 서버 클러스터의 변경 사항을 반영해야 한다. - 두 번째 방법의 경우에는 Lotus iNotes 리디렉터 애플리케이션이 서버에 있는 Lotus DNS(Domain Name System)의
홈 메일 서버 호스트 이름 부분을 메일 파일에 대한 URL의 추가 세그먼트(경로 바로 앞)로 리턴하도록 구성된다. 그런
다음 로드 밸런서가 이 추가 세그먼트를 사용하여 Lotus Domino 클러스터 및 연관된 백엔드 서버를 조회한다.
이 방법과 관련된 한 가지 문제점은 Lotus iNotes에서 생성되는 후속 URL에 해당 세그먼트 이름이 없을 수 있다는 것이다. 따라서 세그먼트가 없을 경우 로드 밸런서가 이 값을 조회할 수 있도록 클러스터 ID를 쿠키 내에 저장해야 한다. - 세 번째 시나리오에서는 로드 밸런서 보조 에이전트가 Lotus Domino 서버에 추가되며, 로드 밸런서가 쿼리를
수행하여 이 메일 파일의 복제본이 포함된 적합한 Lotus Domino 서버 목록을 동적으로 생성한다(그림 3 참조).
그림 3. 서로 다른 클러스터에 있는 두 개의 서버
이 시나리오의 경우에는 로드 밸런서 규칙 내에서 특정 클러스터 이름 또는 백엔드 Lotus Domino 서버 IP 주소를 하드코딩하지 않아도 된다.
조금 더 복잡해진 세 번째 구성의 시나리오에서는 Lotus Domino 클러스터에 여러 서버가 있지만 해당 클러스터의 모든 서버에 일부 메일 파일만 있다. 대신 사용자 메일 파일이 클러스터 내의 서버 서브세트에 낮은 밀도로 분포되어 있다.
이 시나리오는 로드 밸런서와 관련하여 적절하게 지원할 수 있는 가장 복잡한 구성이지만 일반적으로 전개되는 Lotus Domino 구성이기도 하다. 이 구성은 몇 가지 방법으로 수행할 수 있다.
- 특정 메일 파일이 있는 고유한 각 서버 조합이 메일 파일이 있는 고유 서브디렉토리 이름 내에서
반영된다(그림 4 참조). 이 조합은 일반적인 URL이 실제로 메일 파일이 있는 클러스터 및 클러스터 내의
서버 서브세트를 식별한다는 것을 의미한다.
로드 밸런스는 이 정보를 사용하여 요청을 적합한 서버 서브세트에 전달한다.
그림 4. 클러스터 A에 있는 미러링되지 않은 세 개의 서버
- 또한 로드 밸런서 보조 에이전트가 Lotus Domino 서버에 추가되며, 로드 밸런서가 쿼리를 수행하여
이 메일 파일의 복제본이 포함된 적합한 Lotus Domino 서버 목록을 동적으로 생성한다(그림 5 참조).
그림 5. 리디렉터가 포함된 클러스터 A에 있는 미러링되지 않은 세 개의 서버
지금까지 살펴본 것처럼 가장 다재다능한 솔루션에서는 특별한 경로 이름을 사용하여 관련 장애 복구 정보를 통신하지 않는다. 그 대신 Lotus Domino 서버를 활용하여 현재 수신된 요청에 대한 로드를 분산시키기 위한 동적 풀을 작성하는 데 사용할 수 있는 백엔드 서버에 대한 정보를 통신한다.
이제 이 솔루션을 구현하기 위한 범용 서비스를 작성하는 방법에 대해 자세히 살펴보자. 또한 로드 밸런서가 동적 쿼리를 수행하고 그 결과를 사용할 수 있어야 한다.
F5 Networks BIG-IP LTM은 iRule을 작성하는 데 사용할 수 있는 TCL(Tool Command Language) 기반의 정교한 스크립트 언어를 제공한다. 배우기 쉬운 스크립트 구문을 사용하는 iRule은 BIG-IP LTM에서 인바운드 또는 아웃바운드 애플리케이션 트래픽을 인터셉트, 검사, 변환 및 전송하는 방법을 사용자 정의하는 데 사용된다.
이 방법을 사용하면 HTTP 트래픽을 올바른 Lotus Domino 서버로 라우트할 수 있는 지능적인 로드 밸런스 환경이 갖추어진다.
Lotus Domino는 특정 클러스터 내의 고유 NSF 파일에 대한 정보를 클러스터 데이터베이스 디렉토리(cldbdir.nsf)에 저장한다. 하지만 이 데이터베이스는 특정 클러스터 내에서만 고유하다. 동일한 도메인 내의 다른 클러스터에 있는 클러스터 디렉토리 데이터베이스에는 완전히 다른 정보가 있다.
고유 NSF 파일이 특정 클러스터에 있는지 여부를 확인하는 한 가지 방법은 요청이 처음 수신된 서버의 클러스터 디렉토리를 조사하여 해당 경로가 있는지 여부를 확인하는 것이다. 해당 경로가 있으면 모든 것이 정상이다. 적합한 서버 세트가 리턴될 수 있으며 사용자의 홈 서버가 기본 설정이라는 의미로 리턴된 목록의 맨 앞에 있을 수 있다.
하지만 서버의 클러스터 디렉토리에 해당 경로가 없을 경우에는 로드 밸런서가 다른 클러스터에 있는 서버를 쿼리해야 한다. 적합한 클러스터에 요청을 보낼 수 있도록 Lotus Domino 디렉토리 names.nsf 내의 정보를 조회하여 현재 사용자의 메일 파일이 있는 클러스터에 속한 서버 세트를 찾는다.
이 쿼리를 수행하기 위해 서비스는 인증된 현재 사용자의 홈 메일 서버를 조회한 다음 이 서버가 속해 있는 ClusterName을 조회한다. 그런 다음 ($Clusters) 보기에서 해당 클러스터를 조회하여 클러스터에 속한 서버를 확인할 수 있다.
필자는 Notes Formula Language를 사용하여 보조 서비스를 작성하고 Lotus iNotes 리디렉터 템플리트의 ServersLookup 양식 내에 키 코드를 배치했다. 로드 밸런서의 요청이 발생하면 ServersLookup 양식이 두 HTTP 응답 헤더 중 하나를 X-Domino-xxxxx 형식으로 리턴하며, 각 헤더에는 쉼표로 구분된 서버 목록이 있다.
서비스가 고유 클러스터 내에서 관련 경로를 찾으면 X-Domino-ReplicaServers는 리턴되는 반면 메일 서버가 다른 클러스터에 있을 경우에는 X-Domino-ClusterServers가 리턴된다.
이 기사에서는 ServersLookup 양식을 제공한다(부록 A 참조). 이후의 성능 관련 주제에서는 이 보조 에이전트를 사용하지 않으며 구성 1만 살펴본다.
서버 사이에 복제본이 있는 두 개의 클러스터링된 Lotus Domino 메일 서버에 대해 DWA85 워크로드를 실행했다. Microsoft® Windows® 64비트 운영 체제와 32비트 버전의 Lotus Domino 8.5.1이 설치된 각 서버에서 총 4000명의 동시 사용자를 실행했으며, 그 중에서 2000명이 활성 사용자였다.
모든 테스트는 서버에 있는 각 Lotus Domino 디렉토리에 4000명의 사용자가 정의되어 있는 것으로 설정했다. 테스트를 시작하는 단계에서 각 사용자에게는 약 256MB의 압축되지 않은 문서인 메일 파일과 3000개의 메시지가 포함된 Inbox 폴더가 있다.
이러한 테스트에서는 Lotus Domino 트랜잭션 로깅을 Favor Runtime 설정과 함께 사용했으며 모든 메시지를 로컬로 저널링하도록 Mail Journaling을 설정했다. 메시징 및 서버 운영 체제를 위해 DDM(Domino Domain Monitoring) 프로브를 사용했으며 모든 사용자에게는 테스트와 무관한 10명의 사용자 메일을 차단하는 메일 규칙이 있다.
Lotus Domino 8.5.1을 사용하여 메일 데이터베이스의 문서를 압축했으며 결과적으로 약 250MB에서 약 170MB로 문서 크기를 줄였다. 또한 일부 테스트에서 DAOS(Domino Attachment and Object Store) 데이터베이스 특성을 사용했으며, 메일 데이터베이스를 작성한 후에는 편지함 및 메일 저널 데이터베이스에서도 DAOS를 사용했다.
첫 번째 테스트에서는 클라이언트와 서버 사이에 BIG-IP LTM 프록시를 사용하지 않은 채로 SSL 포트를 통해 두 개의 Lotus Domino 메일 서버에 대해 시뮬레이트된 4000명의 NotesBench DWA85 사용자를 실행했다. 이 테스트에서는 각 서버에 2000명의 활성 DWA 사용자가 있다.
두 번째 테스트에서는 BIG-IP LTM 프록시를 통해 메일 서버에 액세스하는 시뮬레이트된 4000명의 NotesBench DWA85 사용자를 실행했다. 이 테스트에서는 다음과 같은 Notes.ini 설정을 사용하여 Lotus Domino 메일 서버의 응답 캐싱 및 GZIP 압축을 사용하지 않도록 설정했다.
Notes_wa_GZIP_Disable=1
HTTPDisableUrlCache=1
또한 Lotus Domino 디렉토리의 서버 문서에 있는 HTTP 서버에 대해서도 SSL 포트를 사용하지 않도록 설정했다. 이러한 테스트 동안 BIG-IP LTM 프록시 서버가 캐싱, GZIP 압축 및 SSL 암호화를 처리했다.
표 1-3에 모든 하드웨어 스펙이 요약되어 있다.
표 1. 서버 1의 하드웨어 구성
| 하드웨어 | 스펙 |
|---|---|
| 모델 | Intel 64비트 플랫폼 |
| 테스트용 프로세서/속도 | 2 쿼드 코어 프로세서로 구성된 Intel® Xeon MP/3.67GHz |
| 메모리 | 8GB |
| 활성 실제 드라이브 | 42 |
| 활성 논리적 볼륨 | 3 |
| 운영 체제 | Microsoft Windows 2003 X64 |
| Lotus Domino 버전 | Lotus Domino 8.5.1 32비트 애플리케이션 |
| BIG-IP LTM이 SSL/gzip을 오프로드할 때 사용된 Notes.ini 설정 | iNotes_wa_GZIP_Disable=1 HTTPDisableUrlCache=1 |
표 2. 서버 2의 하드웨어 구성
| 하드웨어 | 스펙 |
|---|---|
| 모델 | Intel 64비트 플랫폼 |
| 테스트용 프로세서/속도 | 2 쿼드 코어 프로세서로 구성된 Intel® Xeon MP/3.06GHz |
| 메모리 | 12GB |
| 활성 실제 드라이브 | 42 |
| 활성 논리적 볼륨 | 3 |
| 운영 체제 | Microsoft Windows 2003 X64 |
| Lotus Domino 버전 | Lotus Domino 8.5.1 32비트 애플리케이션 |
| BIG-IP LTM이 SSL/gzip을 오프로드할 때 사용된 Notes.ini 설정 | iNotes_wa_GZIP_Disable=1 HTTPDisableUrlCache=1 |
표 3. 서버 3의 하드웨어 구성
| 하드웨어 | 스펙 |
|---|---|
| 모델 | 6900 |
| 2x 듀얼 코어 | |
| 메모리 | 8GB |
| 활성 플래시 드라이브 | 8GB |
| 활성 하드 드라이브 | 2 x 320GB |
| 운영 체제 | 10.1 |
그림 6에서는 기본 구성을 보여 준다.
그림 6. 기본 구성
이 테스트에서는 두 개의 3.6GHz Xeon 프로세서와 8GB의 실제 메모리가 장착된 두 개의 IBM 3850s를 사용했으며, 각 서버에는 42개의 광섬유 디스크가 포함된 DS4300과 Microsoft Windows 2003 Server Enterprise 64비트 에디션 운영 체제가 있었다(그림 7 참조). NotesBench 로드 드라이버 시스템은 시뮬레이트된 최대 4000명의 사용자를 처리할 수 있는 Linux® 서버였다.
그림 7. BIG-IP LTM 6900을 이용한 성능 테스트 구성
다음은 BIG-IP LTM의 설정이다.
- SNAT: Automap으로 설정
- Nagle: 사용 안함
- SSL: 사용함
- 송신 버퍼: 262144
- 수신 버퍼: 262144
- HTTP 프로파일:
- http-wan-optimized-compression-caching의 기본값
- 압축: 사용함
- 압축 GZIP 레벨: 5
- RAM 캐시 크기: 200MB
Lotus Notes 설정은 다음과 같다.
- SSL: 사용 안함
- HTTP 캐싱: 사용 안함
- GZIP: 사용 안함
표 4에서는 두 구성에 대해 측정된 주요 값을 보여 준다.
표 4. 주요 결과
| 테스트 | 기준 | BIP-IP LTM | 향상 비율 |
|---|---|---|---|
| 트랜잭션/분 | 6028 | 6044 | -0.27% |
| 응답 시간(초) | 0.338 | 0.083 | 75.44% |
| 프로세서 사용률 | 29.4 | 20.9 | 28.91% |
| 디스크 I/O 작업/초 | 525 | 530 | -0.95% |
| 디스크 KB/초 | 4406 | 4308 | 2.22% |
상당한 차이를 보여 준 값은 Lotus Domino 서버의 개별 요청 응답 시간과 프로세스 사용률이었다. BIGIP ADC를 대신 사용할 경우, 평균 응답 시간이 75% 향상되었다(그림 8 참조).
다시 말해서 장치를 통과하는 응답 시간이 Lotus Domino 서버로 직접 갈 때보다 4배 더 빨랐다. 이러한 향상을 보여 주는 한 가지 이유는 ADC가 Lotus Domino 서버 연결을 영구적으로 열린 상태로 유지하므로 후속 요청에서 이러한 채널을 더욱 효율적으로 사용할 수 있기 때문이다.
또한 Lotus Domino 서버의 프로세서 사용률이 ADC를 사용하지 않았을 때보다 28% 낮다. 프로세서 사용률이 낮으므로 Lotus Domino 서버가 더 많은 수의 동시 사용자를 유지할 수 있다.
그림 8. 성능 향상률(%)
참고: 메일 클라이언트와의 일부 주요 상호 작용에 대해서도 속도가 느린 연결을 시뮬레이트하여 클라이언트 응답 시간을 측정하려고 시도했다. 대역폭이 주요 제한 요인이었기 때문에 주요 사용자 작업에서 중요한 향상 결과가 측정되지 않았다.
Lotus iNotes의 가용성을 향상시키기 위해서는 소프트웨어 로드 밸런서 또는 하드웨어 ADC를 미러링된 구성과 스파스 클러스터를 포함할 토폴로지인 Lotus Domino 클러스터링과 함께 사용해야 한다.
완전 미러링된 클러스터를 지원하기는 비교적 간단하지만 스파스 클러스터를 올바르게 사용하기는 좀 더 복잡하다. 이 기사에서는 스파스 클러스터 토폴로지를 사용하는 데 도움이 되는 몇 가지 새로운 서버측 논리를 소개했다.
스파스 클러스터는 클러스터에 있는 서버 중 하나가 중단될 경우 클러스터의 나머지 서버에 로드를 고르게 분배할 수 있으므로 클러스터의 모든 서버에서 클러스터 내의 모든 사용자에 대한 복제본 메일 파일을 유지하지 않아도 된다.
또한 성능 분석 결과를 보면 ADC를 전개했을 때 Lotus Domino 서버에서 상당한 프로세서 절약 효과를 얻을 수 있다는 것을 알 수 있다. 게다가 테스트를 통해 다양한 요청에 대한 응답 시간의 상당한 향상을 확인할 수 있었으며 이는 곧 합리적인 대역폭을 사용하여 연결할 경우 사용자 응답 시간을 향상시킬 수 있음을 의미한다.
웹 중심적 솔루션을 채택하려는 조직의 경우, 소프트웨어 로드 밸런서 또는 하드웨어 ADC에 대한 투자를 통해 사용자 응답 시간을 크게 향상시키고 전면에 위치한 Lotus Domino 메일 서버의 프로세서 로드를 줄일 수 있다.
ServersLookup 양식에는 "표시를 위해 계산된" 필드이며 텍스트 유형인 $$HTMLHead 필드가 있다. 이 필드에는 다음과 같은 공식이 들어 있다. 디버그 문이 추가되어 있으므로 브라우저에서 이 양식을 수동으로 열면 공식의 결과를 볼 수 있다.
양식을 수동으로 열려면 다음 요청을 실행한다.
http://mail.acme.ibm.com/iwaredir.nsf/ServersLookup?OpenForm&nsfpath=mail\jsmith.nsf
tmpDebug := "";
tmpNSFPath := @ReplaceSubstring(@URLDecode
( "Domino"; @UrlQueryString("nsfpath") );"/";"\\");
tmpServers := @DbLookup( "":"" ; "":"cldbdir.nsf" ; "($Pathname)" ;
tmpNSFPath; "CanonicalServername");
tmpServers:=@If(@IsError(tmpServers);"";tmpServers);
REM {Lookup home mail server };
tmpHomeServer:=@Name([Canonicalize];@NameLookup( [NoUpdate];
@UserName; "MailServer" ));
REM {Is Home Mail server in list of servers, then move this up to
the front of the list};
tmpServers := @If(@IsMember(tmpHomeServer;tmpServers);
tmpHomeServer : @Transform(tmpServers;"x";@If(x=tmpHomeServer;@Nothing;x))
;tmpServers);
tmpDebug := tmpDebug + "ReplicaServers:" + @Implode(tmpServers;",");
tmpDNSNames := "";
tmpClusterName := "";
tmpClusterServers := "";
REM {If no servers found, then db is in a different cluster, return list of cluster
servers, with home server in front of list};
tmpServers := @If(tmpServers="" | @Elements(tmpServers)=0;
@Do(
tmpDebug := tmpDebug + "Looking for cluster servers;";
tmpClusterName := @Subset(@DbLookup("":""; "":"names.nsf"; "($ServersLookup)";
tmpHomeServer; "ClusterName"); 1);
tmpClusterServers := @DbLookup( "":""; "":"names.nsf"; "($Clusters)";
tmpClusterName; "$0");
tmpClusterServers := @Transform(tmpClusterServers;"x";
@If(x=tmpHomeServer;@Nothing;@Name([Canonicalize];x)));
tmpClusterServers := @If(@IsMember(tmpHomeServer;tmpClusterServers);
tmpHomeServer : @Transform(tmpClusterServers;"x";
@If(x=tmpHomeServer;@Nothing;x));tmpClusterServers);
tmpClusterServers);
tmpServers);
tmpLimit:=@Elements(tmpServers)+1;
@For(n:=1;
n<tmpLimit;
n:=n+1;
tmpHTTPHostNameALT:=@Subset(@DbLookup( "":"" ; "":"names.nsf" ;
"($ServersLookup)" ; tmpServers[n] ; "HTTP_Hostname");1);
tmpServerFQDN:=@Subset(@DbLookup( "":"" ; "":"names.nsf" ; "($ServersLookup)" ;
tmpServers[n] ; "SMTPFullHostDomain");1);
tmpString:=tmpString+@Text(n)+tmpHTTPHostNameAlt+tmpServerFQDN;
tmpDNSNames := @If(@Length(tmpDNSNames)>0;tmpDNSNames+",";"") +
@LowerCase(@If (tmpHTTPHostNameALT!="";tmpHTTPHostNameALT;tmpServerFQDN))
);
@If(tmpClusterName="";@SetHTTPHeader("X-Domino-ReplicaServers";tmpDNSNames);
@SetHTTPHeader("X-Domino-ClusterServers";tmpDNSNames));
@SetHTTPHeader("Cache-control";"no-store");
@If(tmpDebug="";"";"<script>"+tmpDebug+"</script>")
|
이 iRule은 서버 조회를 실행하여 도메인 내의 사용자 메일 파일을 찾는다. DominoServers는 Big IP 장치에서 샘플로 사용하고 있는 서버 풀이다.
######
when CLIENT_ACCEPTED {
#set the status - 'needs server' 1 or 0.
log local0. "got initial connect - needs a lookup."
set needs_server 0
}
when HTTP_REQUEST {
#capture original request - destined for a real server.
if { ([HTTP::uri]ends_with ".nsf") and not ([HTTP::uri] contains "names.nsf")}{
set original_request [HTTP::request]
set needs_server 1
set nsf "[substr [HTTP::uri] 1 ".nsf"].nsf"
HTTP::uri/iwaredir.nsf/ServersLookup?OpenForm&nsfpath=$nsf
} else {
set needs_server 0
}
#check to see if we need a server.Else, send to our dest. pool
if { $needs_server == 1 } {
#dummyServer is our ?mapping? server to query against.
It returns the header and its values.
pool DominoServers
} else {
pool DominoServers
}
}
when HTTP_RESPONSE {
if { $needs_server == 1 } {
set server_list [split [HTTP::headerX-Domino-ClusterServers], ,]
HTTP::collect[HTTP::headerContent-Length]
}
}
when HTTP_RESPONSE_DATA {
foreach {svr} $server_list {
if { "" ne $svr }{
set dest [findclass [string trim $svr] ::NSREPLICASERVERS " "]
log local0. "Servername is [string trim $svr]"
log local0. "$dest"
#TEST.ONE.TWO.COM 10.100.100.80:8080
#set node_addr [getfield [findclass $svr domino-servers " "] ":" 1]
#set node_port [getfield [findclass $svr domino-servers " "] ":" 2]
log local0. "server is: $node_addr on $node_port...issuing HTTP::collect"
if { [LB::status pool DominoServers member $dest 80 ] eq "up" } {
log local0. "Selecting $node_addr:$node_port"
pool IrisServers member $dest
HTTP::retry$original_request
break
}
}
}
set needs_server 0
}
####
|
필자는 고가용성에 대한 이 기사를 집필하는 데 도움을 준 John Fortier(IBM), James Powers(IBM), Mark Oslowski(IBM), Matt Cauthorn(F5 Networks) 및 John Alam(F5 Networks)에게 감사의 뜻을 전한다.
- 포럼에 참여하기.
-
developerWorks® Lotus 기사, "New features
in IBM Lotus iNotes 8.5: Ultra-light mode and the Lotus iNotes redirector"를 읽어보자.
-
developerWorks Lotus 기사, "New features in
IBM Lotus iNotes 8.5: Administration policies and lite mode"를 읽어보자.
-
developerWorks Lotus 기사, "New features in
IBM Lotus iNotes 8.5: Full mode"를 읽어보자.
-
IBM Redbooks® 서적, "iNotes Web Access: Deployment and Administration"을 읽어보자.
-
Lotus iNotes wiki를 살펴보자.
Vinod Seraphin은 Senior Technical Staff Member이자 Lotus iNotes의 책임 아키텍트이며, Lotus iNotes는 브라우저 내에서 사용할 수 있는 뛰어난 PIM(Personal Information Manager)을 개발하려는 Vinod의 프로토타입을 기반으로 "탄생"했다. 1991년부터 IBM에서 근무하고 있으며 Lotus Domino Web Access 업무를 맡기 전에는 Lotus Organizer®의 Software Architect로 활동했다.
Jack Ciejek은 Advisory Software Engineer이며 Lotus iNotes 제품 관련 개발자로 활동하고 있다. 1988년부터 IBM에서 근무하고 있는 그는 Lotus 제품(Lotus SmartSuite for OS/2 포함) 관련 업무를 맡기 전까지 다양한 IBM 메인프레임 운영 체제 관련 업무를 수행했다.
Rahul Garg는 Staff Software Engineer이며 iNotes 팀의 소프트웨어 엔지니어로 복합 구성 및 고객 전개 업무를 주로 맡고 있다. 2005년부터 IBM에서 근무하고 있다.