Secure High-Performance SOA Management with Intel SOA Expressway

Transcription

1 Secure High-Performance SOA Management with Intel SOA Expressway A Report from SAP Co-Innovation Lab Intel: Blake Dournaee, William Jorns SAP: Canyang Kevin Liu, Joerg Nalik, Siva Gopal Modadugula April,

2 Table of Contents 1. OVERVIEW THE TEST LANDSCAPE IN SAP CO-INNOVATION LAB INSTALLATION OF INTEL SOA EXPRESSWAY AT SAP CO-INNOVATION LAB INTEL SOA EXPRESSWAY CONCEPTS AND ARCHITECTURAL OVERVIEW INTEL SOA EXPRESSWAY KEY COMPONENTS CONFIGURATION FOR INTEL SOA EXPRESSWAY COMPONENTS VERIFICATIONS OF SOA EXPRESSWAY FEATURES FUNCTIONAL CORRECTNESS POLICY DEVELOPMENT AND ENFORCEMENT PERFORMANCE AND STRESS-TESTING RESULTS RESPONSE-TIME IMPACT STRESS-TESTING RESULTS CONCLUSIONS REFERENCES... 18

3 1. Overview Service-oriented architecture (SOA) and Web-service technologies have become a standard part of IT infrastructure of many enterprises. SOA offers flexibility, agility, and standardsbased integrations. While these new SOA-based technologies allow businesses to build applications more efficiently, there is also a clear need for appropriate governance, risk, and compliance management. SAP has embraced SOA and offers its customers the very best in both SOA and management solutions. With thousands of packaged, high-quality enterprise services delivered by SAP, customers can immediately reap the benefits of SAP s proven design-time governance, which focuses on building alignment between SOA infrastructure and key business processes. Once customers decide to put these enterprise services into production in their own SOA landscape, they can immediately take advantage of the SAP Solution Manager application management solution and SAP NetWeaver Administrator tool as the cornerstones for runtime management of these enterprise services. In addition to the SOA management capabilities provided by SAP Solution Manager and SAP NetWeaver Administrator, SAP works closely with partners offering integrated management solutions that can effectively secure, manage, and monitor the many third-party applications found in today s heterogeneous enterprise environments. The cooperation between SAP and leading SOA management vendors gives SAP customers the added flexibility and insight needed to effectively manage their heterogeneous infrastructure. This paper offers a summary of the integrated SOA management solution developed and validated in SAP Co-Innovation Lab by SAP and Intel. The SOA Expressway appliance from Intel was designed specifically to address the challenges of managing SOA environments. While many features are offered by the Intel SOA Expressway appliance, the testing in the coinnovation lab mainly focused on two areas: How the appliance can be easily deployed into an SAP software landscape in order to manage and secure SAP enterprise services without changing the SAP components How much performance overhead the appliance may introduce to the managed SAP applications 2. The Test Landscape in SAP Co-Innovation Lab The test landscape chosen for this project is shown in Figure 1 below. The landscape includes: The SAP NetWeaver Enterprise Portal component, version 7.0 SAP NetWeaver Composition Environment (SAP NetWeaver CE) offering, version 7.10 service pack 3

4 An emulated SAP ERP Central Component (SAP ECC), version 6.0 as the back end All those SAP components are deployed in virtual machines. In the case of SAP ECC, two instances are deployed in one single virtual machine. The HP LoadRunner is used to emulate end users and generate load for testing. Figure 1: Reference Landscape in SAP Co-Innovation Lab A commercial application delivery solution ( Load Balancer ) is used in the test landscape to provide the following services: A virtual server proxy end point for the two instances of the SAP ERP application component and load-balanced routing of network traffic to the component instances Termination of incoming secure socket layer (SSL) connection and decryption of such traffic from SAP NetWeaver CE to the back end On top of the above landscape, the lab also provides a simple test scenario that leverages all the key components above. The SAP NetWeaver Portal component allows a salesperson user to log in to the portal and look up a list of customers, and get order and quote history for a selected customer. This business scenario is commonly referred to as a customer fact sheet (CFS) scenario. Shown below in Figures 2 and 3 are the essential screens for the CFS scenario as a user would see them in the portal. In the first step, an end user enters a string to search for customers.

5 In the second step, a click on a customer in the returned list retrieves all historical quote and order information for this customer. Figures 2 and 3: Customer Fact Sheets

6 In both steps, Web-services calls are made behind the scenes from SAP NetWeaver Portal to the SAP NetWeaver Composition Environment server where a set of compound Web services are deployed. The compound Web services at the SAP NetWeaver CE server in turn call SAP enterprise services deployed in SAP ERP. The test application also includes a servlet deployed at the SAP NetWeaver CE server. The servlet essentially performs the same tasks as the second step of the CFS application described above without involving any UI components. It simply invokes the same compound Web service in SAP NetWeaver CE, which in turn calls the back-end SAP enterprise services. The whole scenario can be simulated using load-testing tools, in this case, HP LoadRunner. 3. Installation of Intel SOA Expressway at SAP Co- Innovation Lab 3.1 Intel SOA Expressway Concepts and Architectural Overview 1 Intel SOA Expressway is a software appliance designed to simplify SOA architecture on premise or in the cloud. It expedites deployments by addressing common SOA bottlenecks, accelerating, securing, integrating, and routing XML, Web services, and legacy data in a single, easy-to-manage software appliance form factor. Figure 4 below shows a conceptual deployment diagram for Intel SOA Expressway: Figure 4: Conceptual Deployment Diagram of SOA Expressway In general, Intel SOA Expressway is used at the edge of the enterprise to provide acceleration, routing, runtime governance, transformation, and security for distributed applications based on XML, REST, or SOA. The service gateway acts as a point of entry for large applications that cross domains within an enterprise or from the enterprise to the cloud. Some of the key capabilities of SOA Expressway include the following: 1 This section contains a general overview of the Intel SOA Expressway solution provided by Intel. Please note that not all the features described in this section are covered in the SAP Co-Innovation Lab project.

7 Protocol agnostic It can support all commonly deployed protocols across REST, SOAP, XML, non-xml and custom application environments. Performance It uses an efficient software acceleration layer for XML processing that operates on a compiled binary stream for optimum performance of XML parsing, schema validation, XSLT (1.0/2.0), XPath, XML Security, and SOAP security. Hardened security SOA Expressway supports security proxy capabilities for SOAP or REST services; authentication, authorization, and access control for message-level identities with integration into identity management systems; and protection against XML threats, such as SQL injection, XPath injection, or XML-based denial-of-service attacks. It also has credential-mapping capabilities that are useful at the network edge, such as user name/password to SAML mapping. Flexibility Policies are constructed using a declarative XML-based interpreted scripting language that allows logical conditionals, looping, and flexible data flows for simple proxy applications or more complex distributed application logic. No programming SOA Expressway policies are constructed using an Eclipse-based design environment based on a visual whiteboard data flow with no specialized programming requirements. A screen shot of a basic policy definition in the design environment is shown below in Figure 5: Figure 5: Basic Policy Definition in the Design Environment

8 3.2 Intel SOA Expressway Key Components Intel SOA Expressway is a software service gateway deployed in three different ways: As software on standard operating systems and Intel Multi-Core servers On a virtual server, such as VMWare On a tamper-proof appliance Tests at SAP Co-Innovation Lab used the third form factor. The main components of SOA Expressway include the following: Product runtime The appliance runtime itself, which processes traffic received from clients, service consumers, servers, or service producers Intel Services Designer Eclipse-based policy design tool geared toward the SOA or security architect to create policies based on service policies using a point-and-click interface Web interface Browser-based tool intended for the operational administrator to monitor and manage global service policies, real-time statistics, and cluster-based statistics The most relevant component to be added to the SAP Co-Innovation Lab landscape is Intel SOA Expressway Runtime, which provides virtual Web-service end points and routes Webservice requests to multiple physical Web-service end points after applying policies and load balancing. When high availability is a concern, the recommended deployment model for SOA Expressway is two clustered units running identical policies working behind a standard application-level load balancer. In the event of a failure of one unit, the remaining member of the SOA Expressway cluster can continue processing traffic. For the test in SAP Co-Innovation Lab, only one unit was deployed to simplify the testing, which did not exercise the high-availability requirement. The appliance configuration was as follows: Appliance Configuration Chassis 1-U server appliance chassis with tamper-proof features Processor Dual Intel X5570 Xeon Processors, 2.93 GHz 8 M cache, 6.40 GT/s, QPI, Turbo HT Memory 16 GB RAM, 1066 MHz dual-ranked RDIMMs Hard Drive 64 GB solid-state disk drive SOA Expressway Intel SOA Expressway 64-bit version for RedHat Enterprise Linux AS5, version R2.3

9 Network Additional Boards 8 10/100/1000 network ports Cryptographic accelerator board (used only for PKI and crypto processing offload) As described in Figure 6 below, we determined that the best Intel SOA Expressway deployment pattern for the co-innovation lab landscape was to put it in front of the two backend instances. In addition to the SOA management role, the appliance also took over the role for SSL termination and load balancing. Figure 6: Intel SOA Expressway in the SAP Co-Innovation Lab Landscape For the SOA Expressway proxy to function, a design-time console called Intel Services Designer is also deployed to provide policy management and design capability. In Figure 6, a dotted line is shown from Intel Services Designer to Intel SOA Expressway to represent the policy design environment, which is not part of the runtime architecture but is used during the design phase. Runtime monitoring is done through a Web-based interface on the SOA Expressway runtime itself. Additional servers or software are not required for runtime monitoring of traffic performance, alarms, alerts, and statistics. 3.3 Configuration for Intel SOA Expressway Components The following steps are required to introduce SOA Expressway into the architecture as a Webservice proxy. 1. Configure the proper network address and related networking information on the same physical network as the SAP infrastructure, including information such as IP address, host name, and DNS settings. 2. Retrieve the Web Services Description Language (WSDL) for each of the Web-service end points in SAP ECC. 3. Import each WSDL into Intel Services Designer and configure the appropriate faulthandling and content-attack prevention policies.

10 4. Instruct the calling clients to use the IP address of Intel SOA Expressway for the Webservice end points rather than the IP address of the original Web-service end points in SAP ECC. 4. Verifications of SOA Expressway Features The main focus of the SAP Co-Innovation Lab project was to integrate the SOA Expressway components into the SAP software landscape and to validate their performance impact. Though it s not a goal to thoroughly examine all the SOA management capabilities offered by the Intel solution, we share here a subset of working features we observed in the process of setting up the component and carrying out the test cases. 4.1 Functional Correctness The baseline landscape in the lab runs a WebDynpro development environment as the portal. End users can search for customers by name. When a list of matching customers is returned, the end user can select one of the customers to see more detail, basic data, quotes, and order history of that customer. The application is carefully designed to engage Web-services communications among the portal, SAP NetWeaver Composition Environment, and SAP ECC. The addition of the Intel components to the SAP software landscape should not comprise how the existing applications function. After the installation of the Intel appliance as described in Section 3, we reconfigured the SAP components hosted in SAP NetWeaver CE such that any calls to SAP ECC point to the proxies hosted by Intel SOA Expressway, instead of talking to SAP ECC clusters directly. After the reconfiguration, we manually verified the behavior of all the components in the SAP application. The application continues to function as expected with the inclusion of SOA Expressway runtime in the calling path. 4.2 Policy Development and Enforcement Intel SOA Expressway provides an Eclipse-based design tool for use in policy development, testing, and deployment. Using Intel Services Designer, the application architect can import services and configure threat and trust policies such as content validation, XML attack protection, size checking, regular expression scanning, or message-level security policies such as signing, encryption, or delegated AAA actions. Once the policy has been written, it can be sent to the SOA Expressway runtime directly from Services Designer or exported into an archive that can be applied through the product s Web interface. As part of the load testing, a heavy policy was configured, which required parsing through the response message of the called Web services and searching for the customer ID value. When a particular customer ID such as a badguy is detected, the whole message is logged and an alert created, and a SOAP fault is returned to the caller.

11 To configure this content checking, a so-called content-attack prevention (CAP) policy was created in Intel Services Designer. A CAP policy specifies generic behavior for XML-based content attack such as: Whether or not to write details to the transaction log Whether document type definitions (DTDs) are allowed Maximum XML structural limits Whether SQL injection or XPath Injection checking is turned on Whether or not the content will be filtered for specific words or regular expressions In the lab testing, a regular expression to catch instances of the word badguy was created in the CAP policy. The CAP policy was executed on the content received from SAP ECC and the policy was configured to log the message and return a SOAP fault to the caller when a policy violation has been detected. 5. Performance and Stress-Testing Results This section documents the findings from the set of tests run with Intel SOA Expressway runtime sitting in between SAP NetWeaver CE and SAP ECC, as described in Section 3 Figure Response-Time Impact To measure the response-time impact of Intel SOA Expressway Runtime, our test case focuses only on Web-services traffic between SAP NetWeaver CE and SAP ECC without UI components involved. Figure 7 below provides a brief description of how Web services were used in this test scenario. Intel SOA Expressway was used to proxy and monitor Web services running in the back end system. HP LoadRunner was used to emulate the servlet to call a set of SAP ECC services to get customer basic data, quote history, and order history.

12 Figure 7: Test Case for Response-Time Measurements In order to measure the response-time impact for different sizes of Web-service calls managed by SOA Expressway, SAP ECC was configured to increase the response message size from call to call linearly. In this scenario, one user is used. With the first servlet call, the response message contains 200 sales-order line items and 200 quote-history line items (message size around 80 KB). With the second call, a response message contains 40 additional line items of orders and quotes, so on so forth; with each of the following calls, the response message contains 40 more items. After 50 calls, the response message contains 2,200 line items of orders and quotes, and the message size reaches more than 8 MB; then the response message is reset back to 200 line items, and the increasing cycle starts again. To measure the consistency of the impact, the test contains three cycles of message-size ramping up. The exact same test was run twice: one with the baseline landscape without SOA Expressway Runtime as described in Section 2 Figure 4, and the second with the SOA Expressway Runtime integrated as described in Section 3 Figure 6. In the test with SOA Expressway Runtime, a heavy Web-service policy was enforced, which required parsing through all the response messages from SAP ECC and searching for the customer ID value. When a badguy is detected, the whole response message is logged and a SOAP fault is returned. The test is designed so that badguy response occurs in every 1 of 6 calls to a service (around 17%).

13 Figure 8 below shows the results of the two tests. The blue line shows the result with SOA Expressway Runtime enforcing the badguy policy, performing SSL termination and load balancing to SAP ECC. The red line shows the result with the lab baseline with exactly the same configuration, except that another commercial load balancer performed SSL termination and load balancing to SAP ECC. Legend: blue line Intel; red line lab baseline Figure 8 Response Time Impact of Intel SOA Expressway Runtime We are glad to note that the response-time measurement with Intel SOA Expressway appears to be even a bit faster than with the baseline. A few factors seem to have contributed to the observed acceleration effects. Most noticeably, the message size is reduced from SOA Expressway to the servlet when a badguy is detected. For 17% of all the calls when badguy was detected, instead of returning the whole message (which might be about 8 MB) back to the servlet, SOA Expressway by design logged the message and returned a simple SOAP fault message (which is a few KB). The performance improvement due to transporting smaller messages between SOA Expressway and the servlet appears to be bigger than the overhead added by SOA Expressway enforcing the badguy policy, which required parsing all the response messages. Also note that the 17% errors also results in a faster completion of the test cycles as shown in the shorter blue line in Figure 8. A few more findings are noteworthy with the result with SOA Expressway runtime shown in Figure 8.

14 As with the baseline, the response time follows a clear linear increase as the load increases from 80 KB to around 8 MB in each of the 3 cycles. The response-time fluctuation is small with SOA Expressway. Fluctuation in the diagram is mainly due to the garbage collection activities in the Java stacks in the landscape. It is not unusual for Java applications to occasionally have longer response times due to garbage collection short time holds of the Java virtual machines. In this measurement there were synchronous calls from SAP NetWeaver CE to the SOA Expressway and then to SAP ECC. Hops through Java-based components increase the likelihood of more response time from Java garbage collection, in particular for calls with larger Web-service content sizes. Given the results above, we can conclude that the Intel SOA Expressway runtime Web-service policy enforcement comes with no detectable response-time degradation in our test landscape. 5.2 Stress-Testing Results In this test, the full CFS application scenario was simulated by HP LoadRunner. The sequence diagram in Figure 9 provides a detailed description on how Web services are used in this test scenario.

15 Figure 9: Test Case Stress Test The purple box in Figure 9 above marks a transaction getmoredata, which involves sending a Web-service call to SAP NetWeaver CE, which in turn sends three Web-service calls to the back end. Intel SOA Expressway was deployed between SAP NetWeaver CE and the back end to proxy and monitor Web services running in the back-end system. In addition, it plays the following roles: o SSL termination and load balancing to the back end o Deployment of heavy XML parsing policies o Constant message sizes of 100 line items, with the largest response from Webservice call about 300 KB The stress test checked the stability and reliability of the whole system. The number of users working in SAP NetWeaver Portal was linearly increased from 1 user to 200 in about an hour, followed by a 5-hour period of constant high load with 200 concurrent users working on the system.

16 Figure 10 below shows the response time of the getmoredata transaction. The blue line is the response time with Intel SOA Expressway runtime enforcing a heavy processing policy, which forced parsing all the response messages from the back end. The red line is the response time with the baseline. Over the 6-hour testing period, the response time of the getmoredata transaction is very stable with or without SOA Expressway runtime in the calling path of the services, and the result with SOA Expressway is slightly better than the one without. (Notice that the report from HP LoadRunner shows the time as mm:ss; it s actually hh:mm.) The occasional spikes may be due to Java garbage collections in the back-end servers. Figure 10: Response Time With and Without Intel SOA Expressway Runtime in Stress Test Legend: blue line with Intel appliance; red line without Intel appliance In the stress test, we also looked into any application error that might be introduced by the SOA Expressway appliance. HP LoadRunner reported 2 failed transactions out of 670,663 transactions processed an error rate less than %. Another important factor to check for the load testing is resource consumption of the SOA Expressway appliance under load. Below is the CPU utilization data reported by the SOA Expressway appliance during the test. Over the period of the 6 hours when the load testing was running, the appliance reported that 94% 99% of its CPU was idle. In other words, under 6% CPU usage is observed for the whole test period, and only 1% CPU is used for most of the time. In the table below, CPU usage is reported in 15-minute time intervals. Count is the instantaneous measure of the percentage of the CPU idle at the beginning of the 15-minute time interval; low is the lowest percentage of the CPU idle in the time interval; and average is the average over the interval.

17 Time Percent CPU idle Count Low Average 3/25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : /25/ : Given the results above, we can conclude that under load, the response time of the SAP application is fairly stable with the Intel SOA Expressway runtime, and only a small fraction of the CPU of the appliance is used during the test. In other words, the appliance should be able to handle much bigger load than required by our test application. 6. Conclusions Based on the testing performed at SAP Co-Innovation Lab with our specific landscape and test scenarios, we can conclude that no performance degradation with the Intel SOA Expressway appliance could be detected in our response-time tests. We can also conclude from a 6-plus-hour stress test at SAP Co-Innovation Lab that no detectable latency was added by the Intel SOA Expressway appliance while performing policy

18 enforcement for a group of SAP enterprise services. The appliance CPU utilization of the appliance was consistently under 6%. 7. References SAP Co-Innovation Lab: Intel SOA Expressway: