web-dev-qa-db-ja.com

openldapは大規模な本番環境に適していますか？

約1年間、openldapサーバー_10.04LTS_でubuntuを使用して約20人のITユーザーを認証し、すべてが正常に実行されています（LDAPサーバーでの操作は基本的に制限されていました） Apache directory studio ）を使用してユーザーを作成/削除します。

最近（6か月前）、外部CMSから新しいプラットフォームに移行するWebサイトの外部認証システムとしてopenldap（openldap-24.21/debian）の実装も開始しました。 _Drupal CMS_を使用して社内で再開発します。 45Kユーザーのデータベースがあり、状況はまったく順調に進んでいません。私たちが抱えていた問題は次のとおりです。
- バックアップの復元後にLDAPがクラッシュし、回復する必要があります 。
- LDAP回復ツールがLDAPデータベースを回復できない場合があります
-ウェブサイトで認証アクティビティがないときに100％のCPUを消費するslapd。

内部のリソースと知識が不足しているため、これまでに行ったのは、これらの問題を実際に調査せずにLDAPを実行し続ける方法を見つけることだけです（クラッシュ時にmonitを使用して再起動します。_db_recover_は必要に応じてデータベースを回復し、slapcatは_db_recover_が失敗したときにデータベースを最初から再作成します。

最近、さまざまなインフラストラクチャのすべてを支援するシニアインフラストラクチャエンジニアを雇うための一連のインタビューがありました。私たちが直面している問題。何人かの候補者は、大規模な本番環境でopenldapの問題を経験したか聞いたことがあることを確認し、単一の安定したスタンドアロンopenldapサーバーを思い付くことができず、代わりに冗長な展開を考え出す必要がありました。 （レプリケーション、負荷分散、自動回復/再起動ルーチン）ldapの実行を維持します。一部の候補者は、openldapは実稼働環境には適さず、代わりに_Novel eDirectory_などの代替手段を使用する必要があるとさえ言っていました。

Q：数千人のユーザーがいる本番環境でLDAPを扱った経験がある場合、openldapがそのような設定では実際に不安定であることを証明する傾向がある共有する事実がありますか？そして、他のLDAPサーバーを使用することをお勧めしますか？

ubuntuldapopenldap
3
Max

私はOpenLDAPを使用して、1日を通してすべてを信頼している約10,000人のアクティブユーザーのユーザーベースをサポートしています。問題はまれです。多くのサービスは、認証などのためにこれに依存しています。

ただし、ロードバランサー、非表示マスター、およびホットスタンバイマスターの背後に4つの読み取り専用レプリカ（スレーブ/コンシューマー）があります。以前は2台のフロントエンドサーバーでしたが、特定のピーク時にロードの問題が発生しました（4,000人ほどのユーザーが同じ秒で必死にサーバーにアクセスしようとしたとき）。 LDAPへのすべての書き込みアクセスは、コードを介して行われます。

その機器とOSはすべて古いものであり、2つのレプリカ（他の多くのことを行っていない）と、マスターのペア間の「ミラーモード」レプリケーションに戻る新しいセットアップに置き換える作業を行っています。 HA構成。繰り返しますが、問題はまれです。

以前はレプリケーションが失敗するという問題がいくつかありましたが、それは主にsyncreplの代わりにslurpdを使用していたときからです。また、サーバーのクリーンでないシャットダウンはデータを破壊する可能性があります。

私の経験では、大規模な実稼働環境でOpenLDAPを実行するための鍵：

  1. LDAPとOpenLDAPを理解している人よく。できれば複数の誰か。
  2. インフラストラクチャの他のすべての直接関連する部分をよく理解している人。
  3. OpenLDAPレプリケーションの仕組みを理解している人。
  4. デフォルトが完全に正しくないため、BerkeleyDBオプション（または使用しているバックエンド）の合理的な理解。
  5. 高可用性スレーブ。 1以上。より良い：本当に負荷分散されています。
  6. **アクティブ-パッシブマスター（アクティブ-アクティブマスターレプリケーションは本質的に注意が必要です）
  7. LDAPデータを1時間ごとのLDIFにバックアップし、数日分のデータをディスクに保存します。 （サーバー全体が毎晩バックアップされます）
  8. スクリプトすばやく壊れたスレーブを元に戻す現在のデータレプリカをクリーンにする
  9. スクリプトすばやく壊れたマスターを復元する LDIFバックアップから（slapadd経由）
  10. スタンバイマスターにすばやく切り替えることができます。 （スクリプト）
  11. レプリケーション接続が有効であることを監視します
  12. レプリケーションIDがすべてのスレーブで最新であることを監視します
  13. スレーブの内容全体がマスターと一致することを（それほど頻繁ではありませんが）監視します。

ただし、基本的に、それがインフラストラクチャの重要な部分である場合は、チームの誰かがそれを本当によく理解している必要があります。

補遺：リクエストにより、DB_CONFIG私のopenldapDBディレクトリからのファイル。詳細については、 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
8
freiheit