您好,登錄后才能下訂單哦!
目錄是一個特殊的數據庫,專門用于搜索和瀏覽,另外也支持基本的查詢和更新功能。
目錄是一個為查詢、瀏覽和搜索而優化的專業分布式數據庫,它呈樹狀結構組織數據,就好象Linux/Unix
系統中的文件目錄一樣。目錄數據庫和關系數據庫不同,它有優異的讀性能,但寫性能差,并且沒有事務
處理、回滾等復雜功能,不適于存儲修改頻繁的數據。所以目錄天生是用來查詢的,就好象它的名字一
樣。
基于X.500 目錄訪問協議,以及基于X.500基礎發展而來的LDAP協議,其【具體實現】有: OpenLDAP, ApacheDS, Active Directory, Red Hat Directory Service, IBM Directory Server。
LDAP是 Lightweight Directory Access Protocol的縮寫, 翻譯為: 輕型目錄訪問協議。國內通常讀作: L-DAP 或者 L-D-A-P。
顧名思義,它是指輕量級目錄訪問協議(這個主要是相對另一目錄訪問協議X.500而言的;LDAP略去了x.500中許多不太常用的功能,且以TCP/IP協議為基礎)。目錄服務和數據庫很類似,但又有著很大的不同之處。數據庫設計為方便讀寫,但目錄服務專門進行了讀優化的設計,因此不太適合于經常有寫操作的數據存儲。同時,LDAP只是一個協議,它沒有涉及到如何存儲這些信息,因此還需要一個后端數據庫組件來實現。這些后端可以是bdb(BerkeleyDB)、ldbm、shell和passwd等。
What kind of information can be stored in the directory? The LDAP information model is based on entries(條目). An entry is a collection of attributes that has a globally-unique Distinguished Name(DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The syntax of values depend on the attribute type.
信息如何組織?
目錄條目以層次型的樹狀結構來組織。傳統上, 這種結構反映地域和組織機構界限。
樹也可以根據互聯網域名(Internet命名)組織。這種命名方式也越來越受歡迎,因為它允許使用DNS為目錄服務定位。
LDAP目錄以樹狀的層次結構來存儲數據(類似于 DNS),最頂層即根稱作“基準DN(base DN)”,形如“dc=mydomain,dc=com”或 “o=mydomain.org”,前一種方式更為靈活也是Windows AD 中使用的方式。在根目錄的下面有很多的文件和目錄,為了把這些大量的數據從邏輯上分開,LDAP像其它的目錄服務協議一樣也使用OU(Organization Unit),可以用來表示公司內部機構,如部門等,也可以用來表示設備、人員等。同時OU還可以有子OU,用來表示更為細致的分類。
How is the information referenced ?
LDAP中每一條記錄都有一個唯一的區別于其它記錄的名字DN(Distinguished Name),其處在“葉子”位置的部分稱作RDN;如 dn:cn=tom,ou=animals,dc=mydomain,dc=org中tom即為RDN; RDN在一個OU中必須是唯一的。
How is the information accessed ?
LDAP定義了查詢和更新目錄操作。提供的操作包括,從目錄中增加和刪除一個條目,變更某個已經存在的條目,以及變更一個條目的名字。盡管,絕大部分時間, LDAP 是用于在目錄中搜索信息. LDAP搜索操作允許目錄的一些部分被搜索以尋找那些滿足搜索過濾器規定的條件的條目. 可以請求每個和要求相匹配的條目的信息。
How does LDAP work ?
LDAP utilizes a Client-Server(C/S)模型。One or more LDAP servers contain the data making up the directory information tree (DIT). The client connects to servers and asks it a question. The server responds with an answer and/or with a pointer to where the client can get additional information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service.
What is the difference between LDAPv2 and LDAPv3 ?
LDAPv3在1990's 末期開發出來用來替代 LDAPv2。LDAPv3 為 LDAP增加了以下功能:
使用SASL實現強驗證和數據安全服務
使用TLS(SSL)實現證書驗證和數據安全服務
使用Unicode編碼實現國際化
轉發和配置
Schema Discovery
擴展性(控制,操作擴展,等等)
LDAPv2 過時了 (RFC3494)。大部分所謂LDAPv2實現(including slapd(8))已經不符合LDAPv2技術規范了,那些聲稱支持LDAPv2的實現之間的互操作性是有限的。由于LDAPv2和LDAPv3顯著的差異, 同時部署LDAPv2和LDAPv3是存在問題的。 應該避免使用LDAPv2。 LDAPv2缺省是被禁用的。
What is slapd and what can it do ?
slapd(Standalone LDAP Daemon) is an LDAP directory server that runs on many different platforms。 slapd 其實就是基于LDAP協議的一個具體開源實現(OpenLDAP Software 2.4), 它實現了輕量級目錄訪問協議版本3(LDAPv3),并支持 IPv4 和 IPv6 (TCP/IP)以及 Unix IPC 網絡協議。
總結:
LDAP是什么?
LDAP是輕量目錄訪問協議(Lightweight Directory Access Protocol)的縮寫【注意:它是協議】。LDAP協議實際上是在X.500標準協議基礎之上產生的一個簡化版本。LDAP是一種開放的Internet標準,LDAP協議是跨平臺的。與X.500不同,LDAP支持TCP/IP(即可以支持分布式部署)。
LDAP幾個特點:
LDAP的數據存儲以層次的樹狀結構,而不是二維表。
LDAP可以高效的查詢,不過在寫方面,就慢很多。
LDAP是Client-Server(C/S)模型。
OpenLDAP是什么?
OpenLDAP 是 LDAPv3 協議的具體實現, 可支持多平臺,以提供目錄服務。其進程為 slapd。
本地目錄服務:
在這種配置中,只為您的本地網域提供目錄服務,它不以任何方式與其他目錄服務器交互。
帶轉發的本地服務:
在這種配置中,為您的本地網域提供目錄服務,并配置它返回轉發到其他能夠處理請求的服務器。
可復制的目錄服務:
OpenLDAP支持同步復制,即所謂的 syncrepl,可用于在多個目錄服務器上維持目錄信息的影子復制。最基本的配置,主服務器作為 syncrepl 供應商, 而一個或多個從服務器是 syncrepl 消費者。
分布式本地目錄服務:
在這種配置中,當地的服務被分割成較小的服務,每個都是可復制的,和上下級粘在一起轉發。
為了提供一個有彈性的企業部署,復制目錄是一個基礎需求。
OpenLDAP 2.3 同步復制問題(網上摘抄,沒有經過測試):
slurpd 守護進程是以推(push)模式操作, 主服務器推送變更數據到從服務器(不可靠)
對replog中記錄的次序極為敏感
很容易失去同步,這時需要手工干預來重新同步從服務器數據庫
如果一個從服務器長時間停機,導致replog可能變得太大以至于slurpd無法處理
需要停止和重新啟動主服務器來新增從服務器
只支持單一主服務器復制(1主對多從)
LDAP syncrepl 同步復制是一個基于對象的復制機制. 當提供者的一個被復制對象中的任何屬性值改變時, 每個消費者在復制過程中擷取并處理完整的變更對象, 包括所有改變和沒改變的屬性值(同步整個條目對象,而不是改變的某個屬性). 這方法的一個好處是當多個變更發生在單一對象上時, 那些變更的精確順序不需要保存; 只有最終狀態是有意義的. 但是當使用模式(匹配的方式)在一次變更中處理很多對象時,這個方法可能有缺點。
例如, 假設你有一個數據庫包含 100,000 對象,每個對象是 1 KB . 進一步, 假設你經常運行一個批處理工作來變更主服務器上的 100,000 對象的每一個對象中的一個兩字節的屬性值. 不算LDAP和TCP/IP協議的開銷, 每次你運行這個工作每個消費者將傳送并處理 1 GB 的數據,只是為了處理這個 200KB 的變更!
在類似這樣的案例中,99.98% 被傳送和處理的數據將是多余的, 因為它們代表那些未變更的值. 這是一個對寶貴的傳輸和處理帶寬的浪費并且可能導致發展出不可接受的復制日志的積壓. 雖然這個情形是一個極端, 但它有助于演示某些LDAP部署的一個非常真實的問題.
Delta-syncrepl, 一個基于變更日志syncrepl變種, 被設計用來處理類似上面所說的情況. Delta-syncrepl通過在提供者一端維護一個可選擇深度的變更日志來起作用. 復制消費者為它需要的變更檢查這個變更日志,只要變更日志包含它需要的變更,消費者就從變更日志擷取這些變更并把它們應用到自己的數據庫. 不過,一個復制(譯者注:指變更日志里的變更)如果離上一次同步的狀態太遠(或消費者根本就是空的), 可以用常規的syncrepl把它(指消費者)恢復到最新的狀態然后復制重新切換到delta-syncrepl模式.
Multi-Master復制是一個使用Syncrepl復制數據到多個提供者(“主服務器”)目錄服務器的復制技術.
如果任何提供者失敗了, 其他提供者將繼續接受更新
避免了單點失效
提供者們可以在不同的物理位置例如跨越全球網絡.
好的自動容錯/高可用性
(這些經常被聲稱是Multi-Master復制的優點但是那些說法是錯誤的):
它不關負載均衡任何事
提供者必須對所有其他的服務器進行寫操作,這意味著分布在所有的服務器上的網絡交通和寫操作負載,和單一主服務器是一樣的。
多服務器的服務器利用率和負載在最好的情況下和單服務器一樣; 最壞的情況下單服務器更優,因為在提供者和消費者之間使用不同的模式的時候索引可以做出不同的優化調整.
MirrorMode是一個混合配置,既提供單主服務器復制的所有一致性保障,也提供多主服務器模式的高可用性. 在 MirrorMode 兩個提供者都被設置成從對方復制(就象一個多主服務器配置), 但是一個額外的前段被用來引導所有的寫操作到僅僅到兩臺服務器中的其中一臺. 第二個提供者將只在第一臺服務器崩潰時進行寫操作, 那時這個前端將切換路徑引導所有的寫操作到第二個提供者. 當一個崩潰的提供者被修復并且重啟動后將自動從正在運行的提供者那里活得任何更新并重新同步.
因為LDAP同步協議同時支持基于“拉”和“推”的復制, “推”模式 (refreshAndPersist) 在提供者開始"推"變更之前仍必須由消費者初始化. 在一些網絡配置中, 特別是防火墻限制了連接的方向時, 一個提供者初始化的推模式是需要的.
這個模式可以被配置成LDAP Backend (Backends and slapd-ldap(8)). 不用在實際的消費者服務器上運行syncrepl引擎, 而是一個slapd-ldap代理設置在靠近(或搭配在)提供者的地方指向消費者, 而這個syncrepl引擎運行在這個代理服務器上.
OpenLDAP 2.4
舊的slurpd機制只操作主服務器初始化的推模式. Slurpd復制被Syncrepl復制取代了并且在OpenLDAP 2.4中被完全移除了.
LDIF文件的通常規則適用于配置信息:以'#'字符開始的注釋行會被忽略。如果一行的開始是一個空格,它被認為是延續前行(即使前行是注釋)并且這個單個的空格會被刪除。條目是由空白行分開的。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。