Tài liệu MIDDLEWARE NETWORKS- P8 doc

326 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT Figure 9 - 16 Multiple Layers Integrates Standards - Based Transports to the client using existing switch technologies. Content flows subsequently, with suit - able usage records collected through standard open APIs. Consider the following detailed steps: 1. Bilateral Authentication by Service and Client (see Figure 9 - 17) 1.1. Service nodes authenticate to network 1.2. Service nodes start and announce video selection and content streaming ser - vices 1.3. Client node authenticates to network Figure 9 - 17: One - Time Secure Authentication Allows Client to Request Content TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. P ROGRAMMABLE I NTERFACES FOR N ETWORKS (PIN) 327 2. Client node visits URL and requests content 3. Service Delivery through Managed Transport (see Figure 9 - 18) 3.1. Service node receives request and submits usage record 3.2. Network elements negotiate connection to the client • The negotiated connection provides the appropriate Quality of Ser - vice (QoS) in keeping with the level service agreements between cli - ent, network and service • In this example this defines an ATM connection at a bandwidth that corresponds to the detail level requested by the client 3.3. Content streams to client 4. Stream completes or connection - termination event is generated by an end point or 5. QoS connection terminates 6. Service node submits total usage records These capabilities are harnessed, for example, to securely establish a client identity and then provide an ATM session that streams video to the client. an administrative component Figure 9 - 18: Client IP - Based Request with Delivery over High - speed Transport 9.5.3 Distributed Network Element – DNE To address such issues we devised an edge gateway architecture that is based on a Dis - tributed Network Element (DNE). The defining feature of a DNE is the flow separation. Flow separation allows the small - volume control flows to be routed through the gate and the proxies, and the large - volume data flows to be routed directly through the ele - ments. Flow separation can lead to a significant performance improvement while TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 328 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT keeping the improved control over the network traffic expected in a service network The DNE can be configured as a logical extension of the gate architecture, thereby enhancing the scalability and efficiency. Within the network node (i.e., the gate), the Network Element Adaptation Layer pro - vides a uniform abstraction of the Network Element. This defines, for example, the buffers, policies, and other behaviors that are enforced by the switches outside the SNodes. In general, any gate process should be able to access and control the network element. A client program may access and control the DNE through an API layer, known as the DNE Control Daemon (DNECD). The DNECD implements methods that communicate with the network elements using well - defined control protocols, and interacts with the access daemon (AccessD) and the load balance daemon (LoadBalD), and thereby defines routing policies. The sup - ported features include the network layer resource allocation and scheduling, and this allows the development of highly efficient components. The lowest layer consists of a driver that is implemented as a dynamically loadable module. The module implements methods that communicate with the network elements using well - defined control pro - tocols, and interacts with gate functions such as access control and load balancing, and thereby defines routing policies. It is implemented as a dynamically loadable mod - ule running as a user layer process running on any host machine with a valid TCP/IP stack. Figure 9 - 19: Access Control and Load Balancing through DNE and Network Elements In addition to DNECD, the Network Development APIs (DNEAPI) support increased integration of the software - defined gate architecture as it interacts with the DNE hard - ware and switch - defined network infrastructures. The DNEAPI is provided in C++, CORBA and Java; there is also a GMMS interface for relatively static management and monitoring of the DNE. Its functionality includes: • Quality of Service • Routing/Address remapping • Packet Filter TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. P ROGRAMMABLE I NTERFACES FOR N ETWORKS (PIN) 329 • Firewall/Security • Control and Management • Flow Separation • Monitoring The API obtains the requisite functionality through underlying data structures. These describe flows and rules. Flows are stored in FlowDB, a hashtable keyed on the 5 - tuple (source IP, source Port, destination IP, destination Port, protocol ID). The table describes all specific flows, and does not have any flow with wildcard attributes. RuleDB contains general rules. It has the same structure as FlowDB, but supports wildcards in the Flowspec. Access - policy objects describe the composite flows, flow - bundles, listener addresses, and actions, shown below. FLOW a, b,c; a.ACTION=PASS; a.SPEC={*,*,135.197.25.94,*,*); FLOWBUNDLE X ; a.BUNDLE=x; x.SETBUNDLE; b.ACTION=PASS; b.SPEC={135.197.25.94,*,*,*,*); By establishing a privileged control plane to modify these two DBs, the DNE provides highly secure network control. The RuleDB structure defines network - layer access controls and paths, forming the basis of secur - able IP networks. Data flows can be enabled or stopped through the defi - nitions in FlowDB and RuleDB. The Network Element Adaptation Figure 9 - 20: DNE Data and Control Structures Layer provides a uniform abstraction of the Network Element. This architecture is highly scalable for multimedia applica - tions and avoids an important bottleneck for high bandwidth traffic – the network node. The dual system containing the network node and element behaves like a single virtual network element but with its functionality implemented in a distributed man - ner. It promotes a new concept through which using open and dynamic API and stan - dard protocols, the network elements and nodes constitute a tightly coupled dual system. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 330 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT 9.6 Summary This chapter presented a wide range of mechanisms that support reusable software in a distributed environment. The idea has been to “factor out” the common features and form a standardized “substrate” that supports the development of new and varied components. These components can easily obtain services from the substrate through the common APIs, including authentication, access control, extensibility and security. These APIs allow development of reusable software components that draw upon these middleware - enabled capabilities. The mechanisms are network - aware and enforce the platform principles. This sup - ports standard behaviors that leverage the network as a source of managed capabili - ties. Thus, internationalization happens at the client SNode easing the entry of a service to new markets. Security is customized and adjustable in accordance with the safety of the physical connectivity and demands of the application. These activities all occur in a managed framework. This management system is the topic of the following chapter. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. C HAPTER 10 Systems Management and Monitoring A given cloud based on an IP service platform is a distributed system with hardware components such as servers and routers and software components seen as processes that function as proxies, relays, monitors and servers. From the operational viewpoint all these components need to be constantly monitored and managed to maintain a smoothly running cloud. In this chapter, we look at how these hardware and software components are moni - tored and managed. We base the software management on the GeoPlex Management and Monitoring System (GMMS). We base the hardware and network management on some third party SNMP - based tool (NMS). This chapter offers a detailed look at GMMS and offers a detailed view of its event notification and alerting system that have proven useful for operations, accounting and maintenance (OA&M). When confronted with a combined software and hardware management challenge, most operators resort to an SNMP - based solution for the hardware and network man - agement as well as a solution for the software management. This well developed solu - tion is appropriate in a hardware and network - oriented operation in which the software components are light and easily managed. In a software - oriented environ - ment, such as a cloud relying heavily on an IP service platform, this is not such a great solution; here, the software management part can greatly benefit from the GMMS approach where only the hardware and network components are left to the third party network management system, while the software components are managed by GMMS. Additionally, GMMS ties the entire system together into a single managed space as seen by the system administrators. This provides greater resistance to difficulties inherent in SNMP, including its separation from the specific service requirements, as well as sometimes creating network problems 1 . It also eliminates much of the inherent complexity of attempting to overload SNMP with general software management tasks for which it does not offer an elegant, simple, and general solution. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 332 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT Lets look at two well - known commercial products, one from SUN, called the Enter - prise Management System (Sun EM); and the other from HP, called OpenView/ITO (HP IT/O). Both have two parts. One is related to hardware (SNMP compliant). The other is related to software. The software processes are managed with non - SNMP methods based on Remote Procedure Calls (RPC). For SUN it is EMS using ONC - RPC (Open Network Computing); for HP it is DCE - RCP (a version taken by Microsoft and bolted onto NT). In either case, the software parts are not SNMP compliant and they are too complicated and cumbersome (a similar fate plaguing RPC in general). SNMP - 2.0 was supposed to solve this problem, but with too many companies adding their requirements, it got way out of hand, leading to a nonstandard set of competing products. In the case of HP, SNMP was scrapped and replaced by a pure RPC control. Consequently, to run HP IT/O, one needs HP machines and a special version of Oracle to get the entire OpenView/ITO operational. Furthermore it offers authentication, in the form of Kerberos, a security system used by DCE - RPC. Although this is a viable solution in itself, its use would require a complete bypass of the clouds authentication method if implemented without Kerberos. Again, to integrate the two authentication methods this would require additional effort and could even eliminate the single - sign - on feature offered by a cloud. Interestingly, even if the cloud was to add SNMP - capable MIBs for all its software com - ponents, it would still require the implementation of agents as well as GUI manage - ment applications using the third party vendor APIs. This would lead to the vendor specific implementation. While this may not be a bad solution for any one particular deployment of a cloud, it is not a viable solution in general. Each cloud’s management and monitoring system would subsequently have to customized for the underlying net - work infrastructure and its supporting third party NMS. As such, our approach is to leverage any third party network management solution such as the HP IT/O or SUN’ S EM to monitor and control the health of hardware and network infrastructure, including any of the third party software middleware compo - nents that are SNMP compliant. However, for monitoring and managing the software components that make up the cloud’s IP service platform, we require a general solu - tion that is third party NMS independent. For this, we propose a system such as our GMMS. This dual approach offers the great - est flexibility for the cloud operators that may want to use their third party NMS tools, yet require the complete control over the IP service platform. By offering the platform with an inherent ability to monitor and manage itself, it becomes a simple matter to tie the software platform and the underlying hardware infrastructure together. Without the inherent self - management and monitoring of the software platform, having to inte - 1. Cite “Network Storms” in Distributed Systems. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 333 grate the management of the software components into the third party NMS could be extremely costly if not outright impossible. From the software management point of view, a cloud consists of many interdependent processes running on gates, core, and store machines, interconnected over both the internal and the external networks Fundamentally, GMMS is a hierarchical distributed event system with embedded agents (as shown in Figure 10 - 1). The GMMS architecture consists of a single system monitor (SM), subsystem monitors (SSM) and management agents (GeoMAs). These logically form a tree with the SM as the root, the SSMs as the internal nodes, and the agents as the leaves. The nodes communicate with simple text - based protocol that allows the recipient (SM, SSM, or GeoMa) to execute commands described by a simple text - based command line syntax. The syntax originated from an early interpretation of these commands in the Tcl language. The protocols also allows for general text - based replies and alerts. The whole system is then accessed from web - based GUIs running on remove peers or consoles connected directly to the core machine. Figure 10 - 1: GMMS Web GUIs for Remote Management of All Components. There is a GeoMA for the Java language, and also for C/C++. Gate components such as the control daemon, the data daemon, the cache, the usage daemon, and the active user directory are linked to GMMS through their GeoMAs. This offers system level log - ging, and built - in commands such as manipulating the log level, measuring cpu and memory usage, or obtaining version numbers. In addition, control commands can be issued directly to these daemons through the GMMS console. TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 334 M IDDLEWARE N ETWORKS: C ONCEPT, D ESIGN AND D EPLOYMENT 10.1 Third - party Network Management System Given that it is essential to support third party NMS for the hardware and network infrastructure, it has always been a controversial issue as to where to place it in rela - tion to the cloud. Placing the management station (of an HP IT/O, as an example) inside the cloud security domain raises the issue of allowing access to operators in a secure manner across the firewall. Also, devices such as routers and modem racks that are outside the cloud have to be accessed for monitoring and management. Recall that using a system like HP IT/O uses SNMP and RPC. Here, opening up the cloud’s firewall for SNMP and RPC traffic raises security issues. Figure 10 - 2 highlights the problem of managing external SNMP enabled devices from inside the cloud, if this requires that the administration open a number of permitted connections through the cloud fire - wall for SNMP traffic. Figure 10 - 2: Security Problems of SNMP/RPC Traffic Traversing Firewall. On the other hand, having the management station outside the cloud raises the issue of effective, secure access to the managed components inside. From security point of view, this is a less desirable solution as everything in the cloud including the bordering edge gateways need to be secured. Putting the station outside is like placing the king outside the castle to conduct the battle. Although this may be a preferred configuration in certain deployments, a general rec - ommended and tested configuration is to place the NMS station inside the cloud and then solve the issue of how to manage components outside and how to offer remote monitoring. The solution to the problem is to have an intelligent firewall and an SNMP proxy at the gates. The proxies filter SNMP traffic according to the policies and rules of the cloud. Alarms can be raised and automatic intrusion - prevention mechanisms TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. T HIRD-PARTY N ETWORK M ANAGEMENT S YSTEM 335 Figure 10 - 3: Firewall/SNMP - Proxy Solution imposed if certain configured thresholds are reached. This solution is shown in Figure 10 - 3. This is a general solution that can be used for other services and legacy systems. The whole nature of the platform, as based on the design principles, offers a general mechanism for mediating protocols; in this case SNMP. NMS Managed Resources Figure 10 - 4: GMMS and NMS Integrate Application Management With GMMS in place it can be easily integrated with the infrastructure NMS, such as HP IT/O, as shown in Figure 10 - 4. GMMS feeds alert messages into the NMS from the system monitor by mapping GMMS alerts to OPC messages via an OPC agent. This also TEAM LinG - Live, Informative, Non-cost and Genuine! Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... different kinds of middleware at work Every system has some middleware even though this fact may not be advertised All vendors – from network to ISV to ISP and Telco – have heard the jest: Nowdays, someone’s middleware lies above and others’ lie below; one industry’s middleware is someone else’s underware and someone else’s outerware TEAM LinG - Live, Informative, Non-cost and Genuine! 352 MIDDLEWARE NETWORKS:... through a required semester project using shared computing facilities, somewhat in contrast to the usual Industry model The students completed design, prototypes, documentation and demonstration, but did not fully integrate their work with the middleware infrastructure Virtually all the students immediately understood the advantages of common APIs on a managed network-integrated platform The resulting... 346 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT TABLE 11: Student Projects during Fall 1999 Developed Innovative Services Category Project Summary Portal for sales in a virtual shopping mall Workflow service for student registrations More KidsVille Extended a network-enabled “virtual world” Interpeer Communications Secure and reliable inter-peer communication through a secure channel in the middleware. .. chat features, including an Audience list for displaying active users of the channel The students extended KidsVille by addition of the chat room and other middleware services Whereas chat servers traditionally maintain their own client list, the middleware network provides an authenticated user registry (AUR) and an authenticated TEAM LinG - Live, Informative, Non-cost and Genuine! KIDSVILLE 349 Figure... TEAM LinG - Live, Informative, Non-cost and Genuine! 350 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT connection table (ACT) These improve the ability to monitor and maintain the chat service Likewise, service features such as notification (“Tell me when Marshall enters the room”) can be provisioned through the event mechanisms common to the middleware, rather than specializations unique to a particular... Informative, Non-cost and Genuine! CHAPTER 11 Sample Consumer Services Middleware service platforms are about services, and in particular ones that offer concrete value to the end users As mentioned in the introduction, this book does not discuss any AT&T consumer-oriented services We discuss instead a number of original and innovative middleware services and extensions designed by the graduate students... the luxury to ignore the details of the software applications, hardware platforms and the underlying middleware technologies, and instead focus on the business values This is one hard lesson that the telecommunication industry has recently learned: customers do not want to know nor do they care about middleware and platforms – but the industry does indeed care, in as far as it forges an enabling infrastructure... communication services Driven by such compelling business reasons, NSPs deployed vastly increased capacity, and sought to manage this resource exceedingly well Integrated middleware functionality satisfied these requirements, placing middleware directly into the network This trend continues Businesses now outsource many data and communication items For example, messaging, office automation and sales... with a login screen (Figure 11-2) through which the client enters login credentials The client and cloud negotiate their bilateral authentication, TEAM LinG - Live, Informative, Non-cost and Genuine! 348 MIDDLEWARE NETWORKS: CONCEPT, DESIGN AND DEPLOYMENT Figure 11-2: KidsVille-II Login Screen and the client’s machine then shows the image of a HomeRoom This achieves a network login that enters the client... the first three rooms are active To check electronic mail the user clicks on the mailbox (see Figure 11-3), and thereby activates the Java code for the appropriate mail server, such as a POP3 mailer The middleware only allows authorized users to access the electronic mail service, and all access can be subject to usage records The display of message headers and contents imposes a graphic appearance through . students completed design, prototypes, documentation and demonstration, but did not fully integrate their work with the middleware infra - structure. Virtually. hardware and network infrastructure, including any of the third party software middleware compo - nents that are SNMP compliant. However, for monitoring and