1 Directory Services
2 Distributed Directory Services: requirements Requirements to the name structure: • multi-stage names („schill@inf. tu-dresden. de“) • attribute names („host_x: CPU=Pentium, PRT=Ipr, LOC=rz“) • group names („Arbeitsgruppe_1“ => „meier, müller, schmidt“) Requirements to the Directory Service: • distributed, decentralized name management (for example, one server per department of a company) • replication of name tables (efficiency, fault tolerance) • transparent distributed handling of name queries /name interpretation (internal forwarding between the servers)
3 Distributed Directory Services: requirements Examples of name usage: • selection of a printer server via logical name • search for e-mail-address of a colleague via name or company/department • selection of a computer node with special CPU-capacity (attribute) ==> mapping of logical names or attributes to the addresses necessary ==> special system support required => distributed Directory Services
Distributed Directory Services: requirements Example of some name structure: Document. Editor Printer Server 1 #134 Select. Server(„Printer“) => #137 Directory Service Printer Server 2 #137 4
5 Name management: basic terms Address: explicit, „physical“ object notation („#346“) Name: logical object notation, mostly location independent („printer“) Interpretation: name mapping to an address Context: area/scope/space of interpretation of a component of some multi-stage name (for instance, set of computer names for „schill@host_X“) Name area/space: set of contexts (for instance, „<user>@<computer-node>“) Relative names: interpretation depends on outgoing (issuance) context (for instance, interpretation of „schill“ otherwise by context „host_X“ than by „host_Y“) Absolute names: context independent
Types of name areas/scopes Hierarchy name space: Context: „root“ Example (Unix, NFS): „usr/src/file. c“ Context: „usr“ Context: „bin“ Context: „src“ Routing-oriented name space: Context „computer names“ Context „host 1, route 1“ Context „host 2, route 2“ Context „host 2, route 1“ Context „host 1, route 2“ Flat name area/scope: Context „user names“ Example (local operating system): „schill“ 6
7 Context and name interpretation Example: interpretation of the name „schill@host_X“ Context R (computer name) Address of host_X Context B „schill“ Context B (user names in the space of host_X) User identification
8 Context and name interpretation Approach to interpretation: • interpretation of each name component via related context • Result: mapping of components on an address + a new context • assignment of separate contexts to different name servers possible ==> decentralized, distributed interpretation
9 Directory Service: implementation Basic conceptions: • hierarchical names spaces • assignment of one or several contexts to each name server • each name server knows the sub-ordinate and superordinate servers • distributed interaction of the name servers for processing of a name interpretation – no expensive broadcast necessary – name servers are relatively autonomous
Directory Service: implementation 10 Example of a name area with related name servers: Name Server S 1: Context „Firm_Names“ Name Server S 2: Context „Dept_Firm_A“ Name Server S 4: Context „Design_ Firm_A“ Name Server S 3: Context „Dept_Firm_B“ Name Server S 5: Context „Fabrication_ Firm_A“ Queries processing: „Firm_A : Fabrication : Meier“ • In Firm_A: S 4 -> S 2 -> S 5 or directly via S 5 • In Firm_B: S 6 -> S 3 -> S 1 -> S 2 -> S 5 Name Server S 6: Context „Fabrication_ Firm_B“
11 Optimization: Caching Goals and approaches: • Performance improvement via re-use of precedent query results • Caching via clients of the Directory Service: – parts of an interpreted name and address of the interpreting name server of subordinate level – example of a cache-record: („Firm_A: Fabrication“, „S 5“) – then direct querying of the lowest subordinate server possible (here „S 5“) • Caching via name server directly: – records: name context and addresses of all servers on the same level – thereby, reduction of one level
12 Caching: example Name Server S 1: Context „Firm_names“ Server Cache: „Firm_B“, „S 3“ Name Server S 2: Context „Dept_Firm_A“ Name Server S 4: Context „Design_ Firm_A“ Name Server S 3: Context „Dept_Firm_B“ Name Server S 5: Context „Fabrication_ Firm_A“ Clients Cache: „Firm_A : Fabrication“, „S 5“ Server Cache: „Firm_A“, „S 2“ Name Server S 6: Context „Fabrication_ Firm_B“
13 Context replication Goal: Fault tolerance and locality of queries Approach: • Implementation of a context via several name servers • Selection of an alternative server after termination of a timeout by a query • Estimation of the alternative servers via simple cost function => optimization • Change management of the Name Directories via a special replication method (relatively expensive but robust in comparison with error cases) • Use of replication, especially in very error-critical environments (CIM etc. )
14 Replication: example Name Server S 1: Context „Firm_ names“ Name Server S 2: Contexts „Dept_Firm_A“ „Dept_Firm_B“ Name Server S 4: Context „Design_ Firm_A“ Name Server S 3: Contexts „ Dept_Firm_B“ „Dept_Firm_A“ Name Server S 5: Context „Fabrication_ Firm_A“ Name Server S 6: Context „Fabrication_ Firm_B“
Internal tasks: details • Mapping of names onto the name records, i. e. onto computer addresses or other data • Name structure: hierarchical (for large systems) (for instance, “iioploc: //www. firm_x. de/Department_1/WS_5/printserver”) • Name records: Attributes and attribute values (for instance, <Address, 130. 13. 3. 56>; <Phone, 0351/46338261>) • Query operations: According to name and partially also according to attributes • In any case several distributed Directory Servers (fault tolerance) 15
Internal implementation techniques • Caching: Storage of query results for later re-use Efficiency • Replication: Redundant storage of names on several servers Server 1 / Fault tolerance, efficiency Administration area Server 2 / Server 3 / /Dept 1/WS_1/. . . /Dept 1/WS_5/. . . /Dept 2/. . 16
System administration • Relatively extensive administration tasks • • • Installation of server processes Definition of name space structure Setting of access control mechanisms Replication control of name records Re-configuration of name spaces • Tools • Simple command interface • Vendor-specific tools (also Remote Management) • Examples create replica /hosts clearinghouse /t 500 m 0_ch set directory /hosts Convergence = high 17
18 Existing systems • • • Novell Directory Service Microsoft Active Directory Domain Name System DCE Cell Directory Service X. 500 - Products
Name and address mapping in ISO/OSI Principle: • 7 -layer-Structure, mapping layer-wise • logical, hierarchical names only on layer 7 • Skipping of layers for the mapping Application-Level name Layer 5 -7 Layer 4 Transport address Network address Inter-network route (Gateway 1, Gateway 2, . . . ) Layer 3 c Layer 3 a, b Subnet address Subnet route (Computer 1, Computer 2, . . . ) Address of the channel layer Layer 2 Physical address Layer 1 Physical transmission 19
ISO/OSI – name structure Basic concepts: • Hierarchical name area • Attributed names Standards: • ISO-9594 respectively CCITT X. 500 • Detail aspects: ISO-9594 -1 up to 9594 -8 respectively CCITT X. 500 up to X. 521 Name attributes: • Standard attributes: country code, organizational unit, department, person, postal address etc. • Additionally freely defined attributes • Multi-valued attributes => group names • Optional attributes • Inheritance hierarchy of attributes 20
21 ISO/OSI – name interpretation Basic concepts: • Mapping of contexts on distributed name servers • Decentralized name interpretation Alternative interpretation approach: • Hierarchical processing (according to the precedent examples) • Multicast-queries for different name servers (for instance, relevant for Ethernet) • Interpretation via a sequence of RPCs for servers with decreasing accuracy of contexts Communication protocols: • Directory System Protocol (DSP) between servers • Directory Access Protocol (DAP) between client and server
22 Lightweight Directory Access Protocol (LDAP) • de Facto-Standard for access to Directory Services, wide spread vendor support • Simplified variant of X. 500 Directory Access Protocol (DAP), implementation over TCP/IP • Front-End for heterogeneous Directory Servers (for instance, X. 500, NIS, MS Active Directory, CDS, Novell NDS etc. ) • Typical operations for name search and name manipulation: -> Search, Compare, Add, Delete, Modify
23 LDAP: Directory Structure root de dfn uk tu-dresden informatik xxx mathnat yyy Replication and Distribution possible fr Country (C) Organisation (O) Organisational Unit (OU) Individuals
24 Special properties of LDAP • Simplified protocol elements in comparison to X. 500 • Optimization of access functions • Automatic forwarding of queries between Directory Servers with distributed information repositories („referral“ without involving of client application) • Improvements regarding to authentication, encryption, and integrity for Directory Accesses
25 Novell Directory Service (NDS) • widely used system decision • relatively scalable (name properties managed) • distributed architecture • support of X. 500 and LDAP • integrated security functions • integrated programming interfaces for applications (for instance, Java) • however proprietary administration functions • Platforms: Windows, Linux, Solaris, OS/390 among others
26 NDS: security functions and trustiness • Central authentication for each administration area, based on RSA • Authorizing of Directory access • Rights awarding also on the basis of partial Directory-trees as well as in reference to user groups • Record replication -> fault tolerance • Automatic re-configuration mechanisms in error case
27 NDS: scalability and performance optimization • Replication of name records -> local authentication and local resource access frequently possible • Load distribution of queries on numerous different servers • Implementation of multi-threaded servers => parallelism • Flexible adaptation of Directory Server configuration to actual query and update profiles possible
Internet Directory Services 28 Name structure: • Hierarchical names • Allowed components on the highest hierarchy level – in USA: . com/. edu/. gov/. net etc. – otherwise: country identifier (. de etc. ) • generally 3 -4 name components Address structure: • Internet-addresses with length of 4 Bytes • Example: 129. 13. 3. 57 • Different address classes: – Class A for large organizations: 24 bit for sub-networks and hosts – Class B for medium organizations: 16 bit for sub-networks and hosts – Class C for small organizations: 8 bit for sub-networks and hosts
29 Name interpretation in the Internet Principle: • Distribution of contexts on the name servers • Replication of contexts on the superior levels of the name space • Each name server knows at least one server from superior levels => direct forwarding of queries • Interpretation of relative names possible Optimizations: • Caching of query results via clients as well as via servers of the lower levels • Automatic deletion of Cache-records after expiration of a timeout (so called „time to live“, „TTL“)
Summary Distributed Directory Services: • Mapping of names on addresses • Structured name areas • Multi-level mapping of names • Implementation via distributed name servers Important Standards and Quasi-Standards: • ISO/OSI 9594 / CCITT X. 500 • OSF Distributed Computing Environment • Internet Domain Name System • CORBA Naming Service • Novell Directory Service • Microsoft Active Directory 30
Скачать презентацию 1 Directory Services 2 Distributed Directory Services
60d61da6a0fe92823c7c8819997ef144.ppt