Normativa regulatoria ambiental

In this scenario, we consider a number of possible failure scenarios. This includes the failure of the following elements:

DataPower appliance

Single execution group

Individual broker

WebSphere Message Broker server

DataPower Appliance outage

If any of the DataPower appliances experiences a failure, the network load balancer detects that a device is unavailable and removes the failed device from its active list of devices. It checks for its availability periodically. During the failover, all traffic is redirected to the remaining active appliances in the environment. A device failure causes all in-flight transactions to be lost. Client applications might be required to re-submit the request in case of HTTP-based

Component Description

Network load balancer The network load balancer intercepts all inbound requests and load balances them to the available DataPower devices using a round robin algorithm.

DataPower XI50 Appliances DataPower XI50 appliances are configured as Web services gateways to proxy Web services to the consuming application using SOAP/HTTP. For application-level load balancing to the service endpoint, Load Balancer Group objects are used to route inbound requests dynamically to the WebSphere Message Broker servers. This provides seamless transition of requests to any of the available back-end endpoints.

WebSphere Message Broker servers (saw001-sys3 and saw001-sys4)

These two servers host the WebSphere Message Broker message flows. In this scenario there is a single message flow that exposes a Web service using a SOAPInput node. WebSphere Message Broker is configured with two brokers on each of the application servers making a total of four brokers. Each broker contains two execution groups. Our message flow is deployed to each of these execution groups making a total of eight instances of the message flow. WebSphere Application Server

servers (saw001-sys2 and saw001-sys5)

These two servers host WebSphere Application Server. A cluster of application servers, one on each host, have been defined. The message driven bean is deployed to the cluster.

Service failure

If the DataPower device® is unable to reach the specified back-end service endpoint, the log entry shown in Figure 7-3 is raised in the system log. System logs are available to view in the DataPower control panel under Status View

logs System logs.

Figure 7-3 DataPower: Error alerts in the system log

Assuming a load balancer group object is used for application-level load balancing and one of the member servers becomes unavailable, DataPower automatically attempts to connect to other member servers and seamlessly route the request to an available member. If none of the back-end servers are

available, a SOAP fault is sent to the calling application. This SOAP fault can be customized. Errors relating to member servers availability are not visible in the system log and can only be viewed by selecting Network Load Balancer

Group object_name View Log hyperlink. Figure 7-4 contains a snippet of the log error entries.

Figure 7-4 Load Balancer Group error entry

Most modern network load balancers can be configured to test DataPower device and service availability in the following way:

1. Test device availability by sending ICMP (ping) requests to the device. If network route and connectivity exists, a successful reply is received. 2. Test service port availability by sending a TCP SYN at the DataPower front

side handler (only applies to push-based protocols such as HTTP). If the DataPower front side handler object is up, a TCP ACK is received. 3. Test DataPower service by sending a dummy request to the device and

analyzing the response received. An HTTP 500 - SoapFault generally indicates that the device is successfully responding to invalid requests. 4. Test the end-to-end environment by sending a valid request and analyzing the

If a DataPower device is unavailable or is not accepting any requests from the load balancer, the network load balancer black-lists the DataPower device for a configurable amount of time while retrying connections in the background. When the device becomes available, it becomes an active member group and load balancer starts to load balance requests again.

Most organizations have an enterprise monitoring suite to monitor hardware and messaging-level alerts in the infrastructure. DataPower provides a

standards-based integration with existing monitoring suites and a flexible configuration mechanism to configure the types of alerts and objects to be monitored. This allows organizations to separate concerns and create various monitoring groups with specific responsibilities. For example, a hardware monitoring group might monitor power supplies, network connectivity,

temperature, CPU/ Memory use, and so forth, and a business monitoring group might monitor transactions that failed validation, authentication failures, breach of SLAs, and so on. Extensive monitoring options might be configurable using the Log Target page shown in Figure 7-5. The Log Target page can be viewed by navigating to Objects Logging Configuration Log Target.

The Target Type list offers mechanism to integrate with the target monitoring system. Depending on the option selected, the user sees further options to configure the remote target. Figure 7-6 illustrates the point that certain targets can choose the type of alerts they receive. For example, the Event Filters tab allows the user to subscribe or suppress certain types of events. As a hardware monitoring target, this configuration sends alerts to the remote system of any critical hardware failures using SNMP.

Figure 7-6 Configuring DataPower Log Target

This configuration can be further optimized, tuned for specific errors, and set priorities and objects that raise alerts in other tabs available on this page.

Execution group not responsive

If one of the execution groups stops responding either due to an application error or for another reason, the DataPower appliance does not receive a SOAP Reply in the maximum timeout wait period. DataPower therefore blacklists this endpoint and routes traffic to the remaining execution groups (URL s).

Broker is unavailable

If one of the brokers is shutdown or stops responding, the DataPower appliance does not receive a SOAP Reply within the maximum timeout wait period. DataPower therefore blacklists the endpoints for the broker and routes traffic to the endpoints of the remaining brokers.

DataPower periodically polls the endpoints performing a health check. If they are available they are removed from the blacklist.

The Message Broker Server is unavailable

If one of the servers is down or un-reachable, the DataPower appliance detects this and blacklists the endpoints of the server. All traffic is routed to the endpoints of the remaining server.

DataPower periodically checks to see if the server is back up. If the server comes back online and the endpoints are available they are removed from the blacklist.