openldap은 대규모 프로덕션 배포에 적합합니까?

openldap은 대규모 프로덕션 배포에 적합합니까?

약 1년 동안 우리는 약 20명의 IT 사용자를 인증하기 위해 서버 openldap를 사용해 왔으며 모든 것이 잘 실행되었습니다. (LDAP 서버의 작업은 기본적으로 다음을 사용하여 사용자를 생성/제거하는 것으로 제한되었습니다.ubuntu10.04LTS아파치 디렉토리 스튜디오).

최근(6개월 전) 우리는 openldap외부 CMS에서 Drupal CMS. 우리는 45,000명의 사용자 데이터베이스를 보유하고 있는데 모든 일이 순조롭게 진행되지 않았습니다. 우리가 겪었던 문제는 다음과 같습니다:
-백업 복원 후 LDAP가 충돌하여 복구가 필요함.
-어떤 경우에는 LDAP 복구 도구가 LDAP 데이터베이스를 복구할 수 없습니다
-웹사이트에서 인증 활동이 없는 동안 CPU를 100% 소모했습니다.

내부적으로 리소스와 지식이 부족하기 때문에 지금까지 우리가 한 일은 이러한 문제를 실제로 조사하지 않고 LDAP를 계속 실행하는 방법을 찾는 것뿐입니다( monit충돌 시 다시 시작하고 db_recover필요한 경우 DB를 복구하고 slapcat다시 생성하는 데 사용). 실패 시 DB를 처음부터 다시 작성 db_recover).

최근 우리는 다양한 인프라를 모두 지원해 줄 수석 인프라 엔지니어를 고용하기 위해 여러 차례의 인터뷰를 가졌습니다. 우리가 겪고 있는 문제입니다. 몇몇 지원자는 대규모 프로덕션 환경에서 문제가 발생했거나 이에 대해 들어본 적이 openldap있으며 안정적인 단일 독립 실행형 서버를 마련하지 못했지만 openldap대신 중복 배포(복제, 로드 밸런싱, 자동 복구/다시 시작 루틴)를 마련해야 했음을 확인했습니다. ) LDAP를 계속 실행합니다. 일부 후보자는 openldap프로덕션 환경에 적합하지 않으며 대신 대안을 사용하는 것이 Novel eDirectory필요하다고 말하기도 했습니다.

openldapQ: 수천 명의 사용자가 있는 프로덕션 환경에서 LDAP를 처리한 경험이 있는 경우 그러한 설정이 실제로 불안정하고 다른 LDAP 서버를 사용하는 것이 실제로 권장된다는 사실을 입증하는 공유할 사실이 있습니까 ?

답변1

저는 하루 종일 모든 일에 OpenLDAP를 사용하는 약 10,000명의 활성 사용자 기반을 지원하는 OpenLDAP를 사용합니다. 문제는 거의 없습니다. 많은 서비스가 인증 및 기타 사항을 위해 이에 의존합니다.

그러나 로드 밸런서, 숨겨진 마스터 및 상시 대기 마스터 뒤에는 4개의 읽기 전용 복제본(슬레이브/소비자)이 있습니다. 예전에는 2개의 프런트엔드 서버였지만 특정 피크 시간(4,000명 정도의 사용자가 같은 순간에 필사적으로 서버를 공격하려고 시도했을 때)에 로드 문제가 있었습니다. LDAP에 대한 모든 쓰기 액세스는 우리 코드를 통해 이루어집니다.

해당 장비와 OS는 모두 오래되었으며 우리는 이를 2개의 복제본(다른 작업을 많이 수행하지 않음)과 한 쌍의 마스터 간의 "미러 모드" 복제로만 돌아가는 새로운 설정으로 교체하기 위해 노력하고 있습니다. HA 구성. 다시 말하지만 문제는 거의 없습니다.

우리는 복제 실패로 인해 몇 가지 문제를 겪었지만 대부분 syncrepl 대신 slurpd를 사용할 때 발생했습니다. 또한 서버를 비정상적으로 종료하면 데이터가 손상될 수 있습니다.

내 경험에 따르면 대규모 프로덕션 환경에서 OpenLDAP를 실행하는 핵심은 다음과 같습니다.

  1. LDAP 및 OpenLDAP를 이해하는 사람잘. 바람직하게는 한 명 이상입니다.
  2. 인프라의 직접적으로 관련된 다른 모든 부분을 잘 이해하는 사람.
  3. 방법을 이해하는 사람OpenLDAP 복제공장.
  4. 에 대한 합리적인 이해버클리DB 옵션(또는 사용 중인 백엔드가 무엇이든) 기본값이 정확하지 않기 때문입니다.
  5. 가용성이 높은 슬레이브. 1개 이상. 더 좋음: 로드 밸런싱이 매우 잘 이루어졌습니다.
  6. **액티브-패시브 마스터(액티브-액티브 마스터 복제는 본질적으로 까다롭습니다)
  7. LDAP 데이터를 다음에 백업합니다.LDIF 매시간며칠 분량의 데이터를 디스크에 보관하세요. (전체 서버는 밤마다 백업됩니다)
  8. 우리는스크립트빨리부서진 노예를 다시 데려오세요깨끗한 현재 데이터 복제본으로
  9. 우리는스크립트빨리망가진 마스터를 복원하다LDIF 백업에서(slapadd를 통해)
  10. 우리는 빠르게 다음으로 전환할 수 있습니다.대기 마스터. (스크립트)
  11. 복제 연결이 활성화되어 있는지 모니터링합니다.
  12. 모든 슬레이브에서 복제 ID가 최신 상태인지 모니터링합니다.
  13. 우리는 슬레이브의 전체 내용이 마스터와 일치하는지 (덜 자주) 모니터링합니다.

그러나 기본적으로 그것이 인프라의 핵심 부분이라면 팀의 누군가는 이를 잘 이해해야 합니다.

부록: 요청에 따라 DB_CONFIG내 openldap DB 디렉터리의 파일입니다. 보다http://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.html자세한 내용은.

set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728

관련 정보